Critical Control 11: Account Monitoring and Control

Published: 2011-10-17
Last Updated: 2011-10-18 02:36:14 UTC
by Rob VandenBrink (Version: 2)
2 comment(s)

Both Account Monitoring and Account Control are things that "slide by" in many organizations, and come up over and over (and over) again in security assessments.
Things that get often missed or overlooked:

Too many Administrative Accounts. 
All to often, we see everyone in the IT group has "Administrator" equivalent rights in Active Directory.  If you are an application developer, you don't need Admin (every).  If you mainly reset passwords, you also do not need Admin rights.

Using the Administrator or Root Account directly.  To add to the first point, everyone who needs admin rights should have a named account that has those rights.  So, for instance, Jane Doe might have an account "jdoe" for day-to-day application use, but and admin account of "admin.jdoe".  If people use the administrator accounts directly, then there is no way of ever finding out "who did what" in the event that you need that information (and believe me, someday you will need that information).  If you can do this with a single admin account for multiple platforms (for instance, an Active Directory account) , it also means that when an admin leaves the company, you can revoke their access by deactivating their account from a single location.

Using an Admin level account for day-to-day tasks.  Let's paint a scenario - if you check your email with an admin level account, and some malware gets past your SPAM filter (like that doesn't happen every day), the malware now has admin rights in your domain.  If it's a keylogger, and you now SSH to a router or fire up vCenter to admin your VMware Infrastructure, they've now got credentials and access to a whole lot more of your Datacenter.  Really, use sudo or su in Linux, or use "run as administrator" in Windows to flip back and forth.  Or if you really need admin, keep a VM running that has that right so you can flip back and forth easily!

Work with HR for account creation and deletion.  In all too many cases we see dozens of accounts (sometimes hundreds) that haven't been used in months, only to find that people have left the organization and the IT group wasn't told.  Even if their account data needs to be kept around, create a "data transition procedure" to move data to the person who needs it next after someone leaves.

Shared accounts are EVIL (really). 
Too many times we see clerical accounts that are shared between dozens of people in a group.  These folks generally have direct access to customer information and to data input that affects prices.  I've seen one example where a temp wasn't sure what a field was, so they put "1" in to close out orders.  Unfortunately, it was the "dollars per square foot" value for the material selected - it took accounting weeks to untangle that mess!  Without named accounts, it would have been impossible to figure out who was making this error !  Shared email accounts can create similar problems with accountability.

Password Complexity is a must-have anymore.  While we can have a flame-fest about if complex passwords or passphrases are better (I'd lean towards passphrases, but it's not workable in every environment), you simply can't have people use "password", or their kid's names anymore for access - it's simply too easy to crack. 

Account Lockout is a must have. 
If someone is trying to brute-force your CEO's webmail account, yes, you do want the account locked until you can speak with them.  Better they lose access for an evening, as opposed to having their account compromised and confidential information be disclosed (next years products, mergers or acquisitions, salaries etc).

If you don't have a Password Policy (or have it covered in your Acceptable Use Policy), it's probably time that you put one together that covers all of these issues, as well as enforcement of periodic changes.  Make sure that whatever is in the policy, that you can enforce your policy it in the OS (it's not a bad thing to mirror the default Windows Password Complexity setup, that way enforcement and audit are built into the OS)

While you are at it, try to put one-way encryption into your password policy.  We recently had a lively discussion about user passwords for an application being stored in a database, "in case someone needed it".  You should never need a user's password.  If you do, you need to revisit how your application is being written.  If you keep users' passwords, they immediately have deniability for anything that happens.  This could mean that system administrators could then be suspected or found liable in the case of illegal activity.  So, really, get with the 90's and use the OS passwords wherever possible, or, second choice, use hashes and salts to govern your app accounts.

You can and enforce and monitor for all of this with issues with native logging and controls in the Operating System of most popular OS's (Windows, Linux, Unix).  If you have a legacy system that does not do this, it's probably a system that should be revisited.

As always, any tools you might use, solutions you may have found or "war stories" you'd like to share are welcomed - please use our comment form !

PS - a handy "su" for Windows is shown below (if you have a neater "su" or "sudo" solution, please share via our comment form):

Update:  Reader Stefan noted (correctly) that as a best practice, the path should be fully specified for both RUNAS and for CMD.EXE in our "SU.CMD batch file.  Also, it's important to fully spell out the file name and extension (you can for instance execute a file named "cmd" with no extension on it).    These updates are reflected in the script below.

While this is indeed a best practice, if you suspect that your machine is compromised, it's files like RUNAS.EXE and  especially CMD.EXE that are popular targets.  If you suspect that your machine is compromised, it's best to execute files from trusted read-only media, or, better yet, boot from optical and run your investigation from there.  

If you need to do true forensics (as in "admissible in court"), a whole entire other methodology is required (image the machine, only work with copies of the data, maintain chain of custody, the works).  SANS SEC408 and SEC508 are both good courses to consider if you want to get your feet wet with forensics.

========== su.cmd ==============

@echo off
if "%1" == "" goto HELP
if "%1" == "?" goto HELP
%SystemRoot%\System32\runas.exe /env /user:%1 "%SystemRoot%\System32\Cmd.Exe"
echo ===========================================================
echo SU.CMD - start a shell as another user (usually admin)
echo Usage:   su USERID
echo Where USERID is the target user
echo It is recommended that you do NOT SU to or login as native
echo Administrator accounts
echo ===========================================================



Rob VandenBrink

2 comment(s)
ISC StormCast for Monday, October 17th 2011


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives