Cybersecurity Using AD DACL backdoors as a detection primitive for AD enumeration
Foreword:
This three-part blog article series focuses on some research work on how to detect effectively Active Directory enumeration in a SOC environment. To help you through this quite long journey, grab a cup of hot beverage of your liking, and use this short reference:
Part 1: about detecting AD enumeration
This first part explains what Active Directory enumeration is, how it is leveraged by adversaries during their offensive operations, and digs into how detecting such activities. It aims at highlighting issues on both efficiency and cost of common detection primitives that detects AD enumeration.
Part 2: AD Canaries & DACL backdoors
This second part will first quickly explain what are DACL backdoors – “An ACE Up the Sleeve”¹ published in 2017 by already famous Specter Ops researchers Andy Robbins, Lee Christensen and Will Schroeder. And will then detail the detection primitive AD Canaries mechanism, along with some lab implementation and results.
Part 3: Making it useable – improvements and in-production deployment results
This last part will cover some exploratory work that aimed at making this detection primitive useable for SOC operations; improving enrichment and identifying how to effectively exclude on recurrent false positives. It will then analyze results and observat ions on some in-production deployment we conducted.
Part 1: about AD enumeration & DACL backdoors
AD enumeration: detecting intrusion on their early stages
Active Directory enumeration (or Active Directory reconnaissance) can be defined as the process of exhaustively listing Active Directory objects (computers, users, groups, OUs …) in order to find AD attack paths in these objects’ control relationships.
AD enumeration can be leveraged on multiple steps of an offensive operation, whenever adversaries pivot or elevate privileges in the AD environment – as they might have gain access or visibility to new assets in the environment.
Figure 1 – AD Kill Chain https://github.com/infosecn1nja/AD-Attack-Defense
This type of activity is mapped to the Discovery Tactic² in the MITRE ATT&CK matrix, and numerous techniques and tools have been developed focusing on AD enumeration to facilitate offensive activities, such as BloodHound³, ADfind or ADRecon⁴.
Most modern Offensive Ops toolkits beacon or agents such as Cobalt Strike⁵, Sliver or even Metasploit implement AD enumeration functionalities. Which allows adversaries to leverage AD attack path within minutes after gaining an initial foothold on the AD environment; without any need of additional tool deployment on the beachhead.
Since AD reconnaissance mainly relies on standard use of LDAP, DNS, Kerberos and other Active Directory protocols, Living Off the Lands⁶ will always be an option for offensive operators – using built-in Windows executables such as “net.exe” or “dsquery.exe”.
Although usage of such tools and techniques have been documented for years in multiple DFIR reports⁷, detection of this type of activity can still be complicated and costly. Even when detected, such behavior mostly triggers low severity alerts and incidents with lots of false positives, making it tedious for SOC analysts to identify active threats hidden in the noise.
Side note: Some more advanced detection mechanism such as Identity Protection agents can provide more reliable alert on AD enumeration, however these tools often rely on external agent deployment on critical assets such as domain controllers. Thus, this type of solutions was not part of the scope of the research.
The DFIR report published on October 31st 2022 describing Follina exploitation in June 2022 highlights enumeration activity occurring minutes after initial access and implant deployment on infected endpoints:
² https://attack.mitre.org/tactics/TA0007/
³ https://github.com/BloodHoundAD/BloodHound
https://thedfirreport.com/2020/04/30/tricky-pyxie/
⁴ https://github.com/sense-of-security/ADRecon
⁶ https://lolbas-project.github.io/#
⁷ https://thedfirreport.com/2020/05/08/adfind-recon/
Figure 2- DFIR report example: Follina exploitation June 2022
Because AD enumeration occurs within the first stages of an intrusion and throughout its evolution, improvements on Active Directory reconnaissance could bring defenders means to detect and eradicate intrusions in their early stages. Giving them time to assess the situation, effectively contain and eradicate the identified threat on the network.
Detecting AD enumeration
Side note: This section will focus on the exploration of available detection paths, which lead me to develop the AD canary detection primitive. It details a personal approach on network-based and siem-based detection and their limitations and costs – it might contain opinions or imprecisions feel free to reach out.
Reading this section is not a hard requirement to understand the concept of ADCanaries and how it enables efficient Active Directory detection for blue teamers. As such, feel free to skip to the Part 2 of this blog:
Part 2: AD Canaries & DACL backdoors
Active Directory enumeration involves network traffic from a client to the domain controller over several protocols such as LDAP, DNS or MS-RPC. To effectively detect such activity, there are but three opportunities that are server generated logs, client generated logs and network traffic capture & analysis:
Figure 3 – Detection opportunities for Active Directory enumeration
Now let’s dive into two of these opportunities, and assess in a non-exhaustive way some issues that might prevent us defenders to effectively detect malicious enumeration patterns.
Side note: I chose not to dive into client application detection as the available telemetry related to AD enumeration should be almost identical, and maintaining audit policy required for such detection would be easier if done on domain controllers rather than endpoints. Additionally, malicious AD enumeration coming from an endpoint implies that it might be controlled by an adversary who might already be able to alter audit policies – which makes relying on server’s log a better approach, in my opinion.
Network capture & analysis-based detection
As already said, Active Directory enumeration relies on network interaction with the domain controller through protocols such as LDAP, DNS or MS-RPC. These protocols are of course used by users and machine accounts during their normal activities to enumerate AD resources and access them. Thus, detection of abnormal spikes of requests could cause false positives and alert regularly on legitimate activities.
On the other hand, network analysis of Active Directory enumeration can be made by identifying signatures of strange requests sent by enumeration tools while gathering AD information.
Side note: Enumeration is often leveraged by adversaries to identify weaknesses and attack patterns within AD objects relationships and attributes, which requires using LDAP protocol to access the AD directory itself. Which is why a huge focus is made on LDAP among the identified protocols.
This type of detection requires both to gather network activity telemetry (i.e. deployment of NIDS / NSM / NDR solution) and to parse LDAP metadata by the deployed sensors.
During my research, I only investigated Suricata NIDS capabilities on network detection. Unfortunately, this NIDS do not provide metadata extraction capabilities for LDAP protocol. And I did not investigate capabilities of tools such as Zeek or any NDR solution at the time.
Side note: at the time of writing LDAP support for Suricata NIDS is identified as issue 1199 created 8 years ago and might be presented at Suricon 2022.
Figure 4 – Update on LDAP support issue for Suricata NIDS (14/11/2022)
Another issue of this type of detection is its cost, as it would require the deployment of one or more NIDS equipment and the ingestion of the network telemetry – which might produce an incredible amount of data – in a SIEM or XDR solution to run detection rule against the network metadata.
Server generated events-based detection
Another way to gather and analyze Active Directory enumeration can be to activate and collect application detailed activities for LDAP and DNS services on the domain controllers. However, the amount of data gathered and ingested in a SIEM or XDR solution would still be impactful from a cost perspective. An example of this approach was Trustwave’s “DNS canaries” that inspired me into creating AD canaries.
Trustwave DNS canary concept
While I was still digging on this subject, I found an interesting concept detailed by Trustwave in their article “Digital Canaries in a Coal Mine: Detecting Enumeration with DNS and AD” published in September 2016 by Stephan Borosh. The idea was to deploy fake AD objects leading adversaries into designed attack paths when enumerating DNS or SMB/SAMR sessions.
In short, the DNS canary deployed was a fake fileserver machine account registered in the DNS service in the AD ¹⁰ environment. An additional fake user account is deployed and its home directory is set to point to the fake server. When using tools such as PowerView to locate users on the network, adversaries will generate DNS queries to resolve this fake server IP – alerting the defense team.
¹⁰ https://lolbas-project.github.io/#
Figure 5 – Entry for the canary DNS
Although I found this detection concept particularly interesting, it relied on activation of DNS detailed logging, which can be impactful from a cost perspective. And it also required creation of multiple active accounts in the active directory environment. This implies some additional work with IT admin teams to deploy these accounts and assess the potential impact on AD attack surface.
Figure 6 – Activation of DNS detailed logging
Even more importantly, FQDN resolution over DNS is not a requirement for effective Active Directory enumeration. Several tools and specifically LOLBAS6 don’t automate naming resolution during the crawling of the AD arborescence, making this detection primitive specific to some tool’s behavior such as PowerView’s.
Directory Service Access Security Events
Yet another noisy way to monitor (and then detect using a SIEM) Active Directory enumeration is to activate audit for Active Directory access on objects in the advanced audit policy on domain controllers (via GPO): Audit Directory Service Access (Success, Failure).
Figure 7 – DS Access audit activation
Then, deploying SACLs (System Access Control List) for the group “Everyone” on the access “ReadProperty” on objects we want to monitor. Enumeration of these objects will then generate 4662 Security events on every read access on the objects: be it user accounts, machines, groups, …
Figure 8- 4662 Security event example
However, as for previous detections methods, activating this audit will generate a 4662 event for every read access – even if legitimate – on the AD objects with deployed SACLs on ReadProperty – making it way too noisy and costly for a reliable AD enumeration detection method.
To highlight the effective cost versus detection efficiency for this Directory Service access audit, we can compare it with a similar event used for detecting Active Directory attack techniques: 5136 – A directory service object was modified. 5136 events allow defenders to monitor for critical assets modifications, such as Domain Administrators or Group Policy objects.
Now, let’s compare the number of events generated per day on a real perimeter, will you!
On a SOC client environment of about 650 endpoints, where both audits were configured to gather 4662 (audited for other detection needs) and 5136 events, we managed to gather the following results:
Figure 9 – Comparison between 4662 & 5136 events per day on a SOC perimeter
Side note: both of these events rely on SACL positioning for effective audit to occur, I cannot get into client’s deployment details here. The point is mainly to show the extreme gap between the two audits for a quite similar purpose: detecting AD related malicious activities. It is also worth mentioning that only 4662 with ObjectServer “DS” were counted in the above chart.
We see that 5136 events tends to generate about 2000 to 4000 events per day, whereas 4662 events generate usually more than 35 000 events per day – which makes it close to 15 times costlier to deploy (given that you need to store and compute events for detection and investigation activity).
Part 1: Conclusion
Active Directory enumeration is a common technique leveraged in multiple phases of modern intrusions to identify and exploit weaknesses in directory object relationships and configurations. Because it is often used during the first steps of an attack, efficient detection methods can bring defenders means to detect and even eradicate adversaries within the first steps of their intrusion.
However, detection Active Directory enumeration is not that simple. Because such enumeration behavior should occur on a live environment, gathering enumeration related can be relatively costly and identifying threats might still be difficult even with the right data in hand.
In the next part of this blog, we will focus on Active Directory canaries, a detection primitive designed to tackle this problem and provide low-cost and efficient detection for Active Directory enumeration.
Thanks and shout outs:
Specter Ops researchers Andy Robbins, Lee Christensen and Will Schroeder who published “An ACE Up the Sleeve”
Marie Mion – who was an amazing internship tutor and help me during my research in 2021.
Samir Meghraoua – who helped me a lot while deploying AD Canaries in production in 2022-2023.
Alexandra Toussaint – who pushed me into writing this and helped me throughout the whole process.
Vincent Le Bastard, Nicolas Audiot and all A irbus SOC team.
