Archive

Case of the Disappearing Objects: How to Audit Who Deleted What in Active Directory

I often get asked how to audit the deletion of objects in Active Directory. It’s pretty easy to do this with the Windows Security Log – especially for tracking deletion of users and groups which I’ll show you first. All you have to do is enable “Audit user accounts” and “Audit security group management” in the Default Domain Controllers Policy GPO. You’ll find these 2 policies under Security Settings\Advanced Audit Policy Configuration. Make sure you also enable the Security Option named “Audit: force audit policy subcategories to override…”; this option ensures that the latter settings actually take effect.

Within a few minutes all your domain controllers will begin auditing changes to domain users and groups – including deletions. The events to look for are

4730 – A security-enabled global group was deleted
4734 – A security-enabled local group was deleted
4758 – A security-enabled universal group was deleted
4726 – A user account was deleted

Here’s an example of event ID 4726:

A user account was deleted.

Subject:

Security ID: WIN-R9H529RIO4Y\Administrator

Account Name: Administrator

Account Domain: WIN-R9H529RIO4Y

Logon ID: 0x1fd23

Target Account:

Security ID: WIN-R9H529RIO4Y\bob

Account Name: bob

Account Domain: WIN-R9H529RIO4Y

Additional Information:

Privileges –

As you can see there’s a different event ID for each scope of group which I’ve indicated by underlining above. The fields under Subject, as always, tell you who deleted the group and under Deleted Group you’ll see the name and domain of the group that was removed. Then of course there’s 4726 for the deletion of user accounts. Interpreting this event is easy; the Subject fields identify who did the deleting and the Target fields indicate the user account that is now gone.

Monitoring deletions of organizational units (OUs) and group policy objects (GPOs) requires a few more steps. First you need to enable “Audit directory service changes” in the same GPO as above. But Active Directory doesn’t automatically start auditing deletions of OUs and GPOS yet. Next you need to open Active Directory Users and Computers. Select and right-click on the root of the domain and select Properties. Click the Security tab, then Advanced and then the Audit tab. Now you are looking at the object level audit policy for the root of the domain which automatically propagates down to child objects. Here you need to add 2 entries that audit the successful use of Delete permission for organizationalUnit and groupPolicyContainer objects as shown below.

advanced-security-settings

Within a few minutes your domain controllers should start logging event ID 5141 whenever either type of object is deleted. To determine what kind of object was deleted look at the Class field which will be either organizationalUnit or groupPolicyContainer. The other fields under Object: and Directory Service provide the name a domain of the object deleted and of course the Subject tells us who deleted the object. Here’s an example of a deleted GPO. Notice that the GUID of the GPO is listed instead of is more friendly Display Name. That’s because the GPOs are identified in their official Distinguished Name by GUID.

A directory service object was deleted.

Subject:

Security ID: ACME\administrator

Account Name: administrator

Account Domain: ACME

Logon ID: 0x30999

Directory Service:

Name: acme.com

Type: Active Directory Domain Services

Object:

DN: CN={8F8DF4A9-5B21-4A27-9BA6- 1AECC663E843},CN=Policies,CN=System,DC=acme,DC=com

GUID: CN={8F8DF4A9-5B21-4A27-9BA6-1AECC663E843}\0ADEL:291d5001- 782a-4b3c-a319-87c060621b0e,CN=Deleted Objects,DC=acme,DC=com

Class: groupPolicyContainer

Operation:

Tree Delete: No

Correlation ID: {140c9cef-8dc1-48f4-8b4a-de79230731a6}

Application Correlation ID: –

Going back to users and groups for a moment, remember that the method described above also results in all other changes to users and groups to be audited as well which I think is important to do. But if you really only want to track deletions you can actually use the same method just described for OUs and GPOs for users and groups too. All you need to do is add audit entries to the root of the domain for user and group objects. Then Active Directory will start recording 5141 for user and group deletions too.

Practical ways to analyze login and pre-authentication failures

Nikunj Shah, team lead of EventTracker SIEM Simplified team provides some practical tips on analyzing login and pre-authentication failures:

1) Learn and know how to identify login events and their descriptions. A great resource to find event IDs is here: http://technet.microsoft.com/en-us/library/cc787567(v=ws.10).aspx.

2) Identify and look into the event description. To analyze events efficiently and effectively you must analyze the event description. Within the login failure description, paying attention to the details like: failure reason, user name, logon type, workstation name and source network address are critical to your investigation and analysis. By identifying the description and knowing what to pay attention to, you will easily eliminate the noise.

When using a system like EventTracker, the display of the required fields used to showcase eliminates the noise and show you the immediate error results. EventTracker will provide a summary based on the total number of events for each failure type and user name to demonstrate the automation of your systems’ critical information.

Using IDS will help your enterprise run more efficiently and effectively with the analysis of traditional reports for the hundreds of events that happen every day. Doing this without the help of a management and a monitoring tool is nearly impossible.

Please reference here for detailed charts.

Simplify SIEM with Services

To support security, compliance and operational requirements, specific and fast answers to the 4 W questions (Who, What, When, Where) are very desirable. These requirements drive the need to Security Information Event Management (SIEM) solutions that provide detailed and one-pain-of-glass visibility into this data, which is constantly generated within your information ecosystem. This visibility and the attendant effectiveness are made possibly by centralizing the collection, analysis and storage of log and other security data from sources throughout the enterprise network.

To obtain value from your SIEM solution, it must be watered and fed. This is an eternal commitment, whether your team chooses to do-it yourself or get someone to do it for you. This new white paper from EventTracker examines the pros and cons of using a specialist external service provider.

“Think about this for a second: a lot more people will engage professional services to help them RUN, not just DEPLOY, a SIEM. However, this is not the same as managed services, as those organization will continue to own their SIEM tools.” –Anton Chuvakin, Gartner Analyst

Known knowns, Unknown unknowns

“There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know. ”
–Donald Rumsfeld, Secretary of Defense

In SIEM world, the known knowns are alerts. We configure rules to look at security data for threats/problems that we find to be interesting and bring them to the operators’ attention. This is a huge step up in the SIEM maturity scale from log ignorance. The Department of Homeland Security refers to this as “If you see something, say something.” What do you do when you see something? You “do something,” better known as alert-driven workflow. In the early stages of a SIEM implementation there is a lot of time spent refining alert definitions in order to reduce “noise.”

While this approach addresses the “known knowns”, it does nothing for the “unknown unknowns”. To identify the unknown, you must stop waiting for alerts and instead search for the insights. This approach starts with a question rather than a reaction to an alert. Notice that often enough, it’s non IT persons asking the questions e.g., Who changed this file? Which systems did “Susan” access on Saturday?

This approach results in interactive investigation rather than the traditional drill down. For example:
– Show me all successful login’s over the weekend
– Filter these to show only those on server3
– Why did “Susan” login here? Show all “Susan” activity over the weekend…

This form of active data exploration requires a certain degree of expertise in log management tools, with experience and knowledge of the data set to review a thread that looks out of place. Once you get used to the idea, it is incredible to see how visible these patterns become to you. This is essential to “running a tight ship” and being aware of out of the ordinary patterns given the baseline. When staffing technical persons for the EventTracker SIEM Simplified service team, we are constantly looking for “insight hunters” instead of mere “alert responders.”  Alert responding is so 2013…