ATA Auditing (AuditPol, Advanced Audit Settings Enforcement, Lightweight Gateway Service discovery)

This blog is updated at https://ciberesponce.com

 

NOTE: This blog and code was updated to include a new targeting feature so only 1 domain/child-domain can be targeted for assessment.  This will still discover all DCs in the Forest, however, only the DCs in the targeted domain will be assessed.

 

Advanced Threat Analytics (ATA) v1.8 added new capabilities to monitor suspicious and anomalous activity within an Active Directory domain. This increased the number of Event ID's ATA requires.

Customizing the Domain Controller's Audit Settings could stop the Domain Controller from auditing activities required by ATA. This customization is common in many organizations and can have a negative impact on ATA. Additionally, many Cyber shops are not aware of their Domain Controller's current audit policy settings nor the level of effort (LOE) changes in ATA v1.8 with Gateways vs. Lightweight Gateways (LWGWs).

Starting in ATA 1.8 the LWGWs' event ID's are automatically read and required data is extracted. Meanwhile for Gateways, event IDs still must manually be forwarded or sent to the ATA Gateway.

In previous versions of ATA, the only event required was event ID 4776. In ATA v1.8, ATA requires the following event IDs 4732, 4733, 4728, 4729, 4756, 4757 in addition to 4776.

This script will help make sense of the above variables to ensure you are in good status.

About the script

First off, the script is located here: https://aka.ms/AtaAuditing

In this script, we:

1. Discover all Domain Controllers (DC)
2. Via WMI, enumerate if Audit Policy settings are enforced (a Microsoft best practice; on by default)
3. Via WMI, enumerate the Audit Policy settings per DC
4. Via WMI, discover if the DC has the ATA Lightweight Gateway (LWGW) installed or not
5. Compares the outputs above and provides a high-level status

We chose WMI since it is always on for Domain Controllers and is a much more reliable method than Windows Remote Management (WinRM). In addition, just like the ATA Sizing Tool, it is very light weight. Further, this allows you, our customer, to test that ATA v1.8 can detect WMI Execution against the Domain Controller 😊. Eventually, we will push this script into the ATA Sizing Tool script, which uses the same WMI protocol. The script will be officially "supported" by Microsoft when it is merged into the ATA sizing Tool. In the meantime, we didn't want to wait – so we decided to publish early!

Running the script

The script requires Domain Admin (or equivalent) privileges to execute. This can be done from the Domain Controller itself or from an admin workstation where such credentials can be exposed (i.e. "Admin Workstation"). If running from a Domain Controller, the script ensures that we only query 10 other DCs at a time, thus throttling the script.

To run the script, simply download the script and its supporting files and execute from the path ".\Measure-AtaDeployment.ps1". Again, by default, this will throttle the script to 10 DCs at one time, and will assess the environment against ATA v1.8 requirements. If you have multiple Domains in a single Forest, ensure the script is executed with Enterprise Admin (or equivalent) privileges.

However, if you are running this from a non-DC, or don't want to be limited by the built-in throttling, you can execute the script using the "RunJobsThrottle" parameter:

And, for whatever reason you are still on ATA v1.7, use the "AtaVersion" parameter to set this to "1.7":

To target just a particular domain/child-domain, use the "Fqdn" parameter.  In this example, we will only target the "child.contoso.com" domain.  Note that the script will still discover all domain controllers in the Forest, but it will only do the assessment against the DCs in the provided domain.  In addition, this parameter is not required and thus, by default, the assessment will be at the Forest and all respective Domain Controllers.

Results

The results are provided back in both the PowerShell console and exported as CSV, in a "Results" folder in the same location as where the script is when executed. Because we believe in "run once, use many", we decided to preserve the raw Audit Policy results for each DC. If you have no other use-case for these, simply ignore them and only look at the "Assessment-{date}" file. However, you might find other great information in those files…

The Assessment Results are in a CSV file and will nicely show you which DCs are LWGW, which have the right policy settings, and if something failed, it will show you where it failed:

Fixing Issues

If advanced audit setting policies are enforced, remediation of any issues is trivial.

However, if issues are identified, use the following resources to help remediate:

• For more information on Force audit policy subcategories: https://technet.microsoft.com/en-us/library/dd772710(v=ws.10).aspx
• For enabling a audit policy subcategory: /en-us/windows/device-security/auditing/advanced-security-audit-policy-settings

What about that WMI Code Execution detection in ATA v1.8?

In the above example, we can see each DC's FQDN, their overall Status and the specific assessment results. You can see that even if all the assessment results come back good, we make a friendly reminder for all non-LWGWs to ensure events are manually being forwarded to the ATA Center. For more on that, please refer here; note that we support Windows Event Forwarding (WEF) and Windows Event Collector (WEC); instructions here.

And, as promised, ATA v1.8 detects WMI Execution against the DC. Since this script is doing just that, executing very specific commands on the DCs via the WMI protocol, ATA detects this. In my lab environment, thanks to ATA, you know exactly from where the Post Deployment script was ran (and by who).

To further test ATA's detection capabilities, we recommend you head to the ATA SA Playbook.

Getting Help

Until this fully merges into the ATA Sizing tool, any issues or questions can be sent to aharri@microsoft.com and askcesec@microsoft.com. If having issues, please do attach the transcript, located in the "Transcript" folder.

Happy hunting!

Andrew (@cibereponce)

 

Reviewers:
Gershon (@gman4626)
Marie (@mariegroover)

Comments

• Anonymous
  August 18, 2017
  Wow, this is really helpful! Thanks for sharing these awesome tools to help with ATA deployment and management.
  • Anonymous
    August 22, 2017
    Let us know how it goes with using it. We added the ability to target a specific domain in the last 48 hours. In addition, we fixed a bug when running the code from PowerShell.exe (vs ISE or VS-Code); apparently they treat passed variables in a scriptblock differently :|
• Anonymous
  July 11, 2018
  Is every single Subcategory listed for the Audit logs are required from the domain controllers ? For Ex: My DC's report no auditing for these sub-categories: "File System, Non Sensitive Privilege Use, Other Privilege Use Events" - Are they required ?