Security, et al

Randy's Blog on Infosec and Other Stuff

«  Catching Hackers Living o... | Anatomy of a Hack Disrupt... »

How to Detect Low Level Permission Changes in Active Directory

Wed, 16 Dec 2015 09:26:50 GMT

We hear a lot about tracking privileged access today because privileged users like Domain Admins can do a lot of damage but more importantly if there accounts are compromised the attacker gets full control of your environment.

In line with this concern, many security standards and compliance documents recommend tracking changes to privileged groups like Administrators, Domain Admins and Enterprise Admins in Windows and related groups and roles in other applications and platforms.

But in some systems you can also granularly delegate privileged access – ultimately giving someone the same level of authority as a Domain Admins but “underneath the radar”. This is especially true in AD. This capability is a double edged sword because it’s necessary if you are going to implement least privilege but it also creates a way for privileged access to be granted inadvertently or even maliciously in such a way that will go unnoticed unless you are specifically looking for it. Here’s how:

First you need to enable “Audit Directory Service Changes” on your domain controllers – probably using the Default Domain Controllers Policy GPO.

Then open Active Directory Users and Computers and enable Advanced Features under View. Next select the root of the domain and open Properties. Navigate the Audit tab of the domain’s Advanced Security Settings dialog shown below.


Add an entry for Everyone that audits “Modify permissions” on all objects like the entry highlighted above. At this point domain controllers will record Event ID 5136 whenever someone delegates authority of any object in the domain – whether an entire OU or a single user account. Here’s an example event:

A directory service object was modified.

Subject:

     Security ID:         MTG\pad-rsmith

     Account Name:        pad-rsmith

     Account Domain:      MTG

     Logon ID:       0x5061582

Directory Service:

     Name: mtg.local

     Type: Active Directory Domain Services

Object:

     DN:  OU=scratch,DC=mtg,DC=local

     GUID: OU=scratch,DC=mtg,DC=local

     Class:     organizationalUnit

Attribute:

     LDAP Display Name:   nTSecurityDescriptor

     Syntax (OID):   2.5.5.15

     Value:    

Operation:

     Type: Value Added

     Correlation ID: {29fbbb83-5567-4935-9593-73496cc98461}

     Application Correlation ID:     -

This event tells you that a MTG\pad-rsmith (that’s me) modified the permissions on the Scratch organizational unit in the MTG.local domain. nTSecurityDescriptor and “Value Added” tell us it was a permissions change. The Class field tells the type of object and DN gives us the distinguished name of the object whose permissions were changed. Subject tells us who made the change. I removed the lengthy text for Attribute Value because it’s too long to display and it’s in SDDL format which isn’t really human readable without a significant amount of effort. Technically it does provide you with the full content of the OU’s new access control list (aka Security Descriptor) but it’s just not practical to try to decode it. It’s probably going to be faster to actually find the object in Active Directory Users and Computers and view its security settings dialog via the GUI.

So the Security Log isn’t perfect but this method does give you a comprehensive audit trail of all permission changes and delegation within Active Directory. If you combine this with group membership auditing you’ll have a full picture of all changes that could impact privileged access in AD which is a key part of security and compliance.

email this digg reddit dzone
comments (0)references (0)

Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond

Comments disabled

powered by Bloget™

Search


Categories
Recent Blogs
Archive


 

Additional Resources