Skip to main content
Lantern Home
 
 
Splunk Lantern

Enabling an audit trail from Active Directory

  1. Last updated
  2. Save as PDF

 

Extracting an audit trail from Active Directory is more challenging than ingesting typical logs from a Windows environment. You need to ensure the following three configurations:

  1. All necessary audit policies are implemented.
  2. The necessary System Access Control Lists (SACLs) are in place for the types of activities you are tracking.
  3. Your Splunk platform deployment is ingesting events that match your target codes.

If you are working in a mature environment, you might be tempted to focus on specific event codes initially and only go backward if needed. However, it's smart to double-check the SACLs and Group Policy Objects (GPOs), especially when setting up an SACL to monitor computer object activity, which isn't often covered in online SACL configuration tutorials.

Enterprise Security Content Update (ESCU) has numerous detections across the analytic stories Sneaky Active Directory Persistence Tricks and Active Directory Discovery which use these event codes to find potential exploits or catch administrative activities that attackers could misuse or that might result from misconfigurations. 

Applying required Windows audit group policies

The first step is to ensure the Windows audit policies are configured to write directory services (active directory) access and change events to the wineventlog. Ensure the following audit policies are applied to the domain controllers. 

Audit Directory Service Access

  • Device Scope: Domain Controllers
  • Logging Condition: Success & Failure
  • Event Codes: 4661, 4662

Audit Directory Service Changes

  • Device Scope: Domain Controllers
  • Logging Condition: Success
  • Event Codes: 5136, 5137, 5138, 5139, 5141

Applying Active Directory audit SACLs

After the audit policies are in place, you need to tell Active Directory what access and change events to audit. These audit settings are defined using SACLs, which apply granular control over logging within active directory environment. There are two required SACLs to implement, one for each principal listed below.

  • Select Principal: Everyone, Domain Computers
  • Type: All
  • Applies To: This object and all descendant objects
  • Permissions: Write all properties, Modify owner, Modify permissions

To apply these SACLs to Active Directory:

  1. Open Active Directory with Domain Admin privileges.
  2. Open dsa.msc > View > Advanced features.

    clipboard_e439b9eac8d0de1e1682d2d65bac9112e.png

  3. Right click the domain (in this example, the domain is called attackrange.local), and click Properties.

    clipboard_ed4a4f0fb09bf85bdb358b7d653942b6e.png

  4. Under the Security tab, click Advanced.

    clipboard_e30efd9d8d422d0e21ebec9887e3cd782.png

  5. Click the Auditing tab then click Add.
    Only make this change on the Auditing tab, not on the Permissions tab.

    clipboard_e5353305434cb05b8dd5f6f2d1cf76bbb.png

  6. Add a new auditing entry for the principal Everyone.
    1. Select Principal: Everyone
    2. Type: All
    3. Applies To: This object and all descendant objects
    4. Add the Permissions:
      1. Write all properties
      2. Modify owner
      3. Modify permissions
    5. Do not untick the default permissions, and leave the rest of the permissions as they are.

      clipboard_e82f19623a64005e6d8c6672dda2294d3.png

  7. Add a new auditing entry for the principal Domain Computers.
    1. Select Principal: Domain Computers
    2. Type: All
    3. Applies To: This object and all descendant objects
    4. Add the Permissions:
      1. Write all properties
      2. Modify owner
      3. Modify permissions
    5. Do not untick the default permissions, and leave the rest of the permissions as they are.

    clipboard_e5bced4a4fb0bab63c81abe11d5e40dee.png

Active Directory audit event codes

Lastly, affter GPOs and SACLs are configured, you need to configure your Splunk instance to ingest the following Windows security event codes. Ensure these event codes are added to the allow list or removed from a deny list within inputs.conf under the stanza [WinEventLog://Security]:

  • 4662 - An operation was performed on an object
  • 5136 - A directory service object was modified
  • 5137 - A directory service object was created
  • 5138 - A directory service object was undeleted
  • 5139 - A directory service object was moved
  • 5141 - A directory service object was deleted

4662 can be quite noisy and is disabled in the default Splunk inputs.conf configuration. While it might be tempting to only ingest event code 4662 featuring write activity (defined by access mask), read events also hold a lot of value for detecting Active Directory enumeration. You can see an example of this in the Windows AD Abnormal Object Access Activity detection. The best approach to tuning this event code is to tune out the known service accounts which perpetually query Active Directory. Below is an example using the deny list inputs.conf configuration to exclude ingesting read events performed by the ldap_svc account:

blacklist1 = $XmlRegex="(?ms)<EventID>4662<\/EventID>.*<Data Name='SubjectUserName'>ldap_svc</Data>.*<Data Name='AccessMask'>(0x4|0x10|0x20000)<"

Next steps

These resources might help you understand and implement this guidance:

Splunk OnDemand Services: Use these credit-based services for direct access to Splunk technical consultants with a variety of technical services from a pre-defined catalog. Most customers have OnDemand Services per their license support plan. Engage the ODS team at ondemand@splunk.com if you require assistance.