Active Directory: A canary under your hat – Part 2

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 (coming soon)

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 observations on some in-production deployment we conducted.

Part 2: AD Canaries & DACL backdoors

In the first part of this blog post, we focused on Active Directory enumeration and the potential value for blue teamers to improve its detection: catching bad guys on their firsts steps of their intrusion. 

Although the presented exploratory work was not exhaustive, we identified several issues that defenders might face when trying to effectively detect Active Directory enumeration:

• Audit policy management
• Volume of event (telemetry) to be stored & processed
• High volume of false positive and potential difficulty to identify malicious behaviors among legitimate enumerations

This blog part will be focusing on Active Directory Canaries, a detection primitive inspired by both TrustWave’s “Digital Canaries in a Coal Mine: Detecting Enumeration with DNS and AD” and SpecterOps research on DACL backdoors “An ACE Up the Sleeve”. 

DACL Backdoors – An ACE Up the Sleeve 2017 (Specter Ops)

Ahead of detailing what AD Canaries are and how they can detect Active Directory enumeration, a little digression on the aforementioned DACL backdoors is needed.

Side note: If you are already familiar with this research and the stealth primitive mechanism, you can skip to the next section: Solving DS Access event verbosity issue with backdoor stealth primitive

Disclaimer: this is but my understanding of the work of Will Shroeder, Lee Christensen and Andy Robins. For more details and a better explanation of the presented backdoors please refer to their paper and presentation at BlackHat 2017. 

Figure 1 - An ACE Up the Sleeve - cover page

In this paper, the researchers designed AD security-descriptor-based backdoors that could hide in plain sight within Active Directory, remaining almost invisible even for privileged accounts. Additionally, this would provide offensive operators a persistent path to escalate and takeover the AD environment.

To avoid any confusion, one must clarify that the use of “backdoor” does not refer to any sort of malware or any sort of malicious code execution. This terminology only aims at highlighting the stealth and persistence capabilities of these primitives, that are solely based on Active Directory control-relationships.

DACL, or Discretionary Access Control List, is a complicated acronym to refer to the set of permissions associated to any Windows object allowing specific access to a security principal or a security group:

Figure 2 - Microsoft documentation definition of DACLs and ACEs

An ACE, or Access Control Entry, is but a simple entry in the DACL associated to a specific object. 

DACL backdoors are permission sets that offensive operators could deploy in order to hide a “secret” access and associated escalation path within the environment.

Deployment of such backdoors requires adversaries to have already gained privileged access to Active Directory – equivalent to Domain Admins. This type of action can be qualified as Domain Dominance and can occur at the end of an adversary KillChain, and aims at multiplying and maintaining elevated accesses to the infrastructure. After deployment, use of such backdoors will only require network access to the victim AD infrastructure.

Described backdoors can be divided in two separate parts: 

• The stealth primitive: one or more ACE (Access Control Entries) designed to hide a malicious account from defenders
• The backdoor primitive: one or more ACE designed to provide an escalation path for domain takeover

Stealth primitive mechanism:

This primitive abuse the order of evaluation of the different ACE within the DACL of an object to hide malicious accounts in Active Directory (even from privileged accounts) and maintain an easy path to privileged access in AD. This evaluation is made by the Kernel-Mode Security Reference Monitor (SRM) whenever access is requested in Windows and Active Directory.

The evaluation order of the ACE is: 

• Explicitly defined DENY ACEs.

1. Explicitly defined ALLOW ACEs.
2. Inherited DENY ACEs.
3. Inherited ALLOW ACEs.

Because explicit denies take precedence over explicit allows and inheritance, it is possible to prevent enumeration of malicious AD object even by elevated accounts. In other words, explicitly denying all type of accesses to the group “Everyone” allows privileged adversaries to hide malicious objects inside of Active Directory, even from the members of this group: “all interactive, network, dial-up, and authenticated users”.

However, the domain administrator can implicitly change the owner of any AD object, and this owner has then an implicit complete control over the object allowing him/her to view and remediate the security descriptor. Meaning that privileged users on the environment are still able to remove these malicious objects when detected in the environment.

Figure 3 - Stealth primitive – Hiding the principal

/!\ DIGRESSION /!\ Side note (yes once again, but hear me out): AD Canaries only rely on the stealth primitive mechanism, if you do not wish to further digress on DACL backdoors skip to the next section: Solving DS Access event verbosity issue with backdoor stealth primitive

Backdoor primitive mechanism:

The backdoor primitives consist in one or more malicious ACE that will provide the aforementioned hidden account a persistent path to escalate privileges within Active Directory and takeover once more the targeted domain.

Figure 4 – [Digression] Backdoor primitive

The complexity of these primitives varies from a simple ACE placed on critical AD objects (such as AdminSDHolder or DCSync permissions) to trickier scenarios abusing LAPS cmdlets inaccurate results or even Kerberos Constrained Delegation elevation path via GPO.

You might have noticed that I like digressions. And as I had the chance to work on this research paper 

for detection purposes, here is a custom illustration of my personal favorite backdoor amongst the one presented: “Abusing GPOs and Constrained Delegation”:

Figure 5 - [Digression] GPO and Constrained Delegation based DACL backdoor schema

This schema highlights two separate operation phases: 

• the deployment of the DACL backdoor in the AD environment in YELLOW
• the trigger of the DACL backdoor to recover full compromise of the environment in RED

Deployment phase – using Domain Admins privilege to persist: 

1. The offensive operator needs to create the account that will be used as backdoor in the environment, preferably in an obscure container in the AD arborescence.
2. The operator gives Full Control (GenericAll) to his/her backdoor account over a wisely targeted proxy-user (an already existing account, that should not be audited cautiously)
3. The operator gives the permission to Change Permissions (WriteDacl) to the proxy-account over the critical Group Policy “Default Domain Controllers” (or any other GPO that applies on domain controllers).
4. The operator hides the backdoor account using one of the aforementioned stealth primitives

Now the offensive actor has a deployed backdoor, he/she can retrieve full control over the AD environment with but an internal access to the environment (i.e. a foothold).

To illustrate a bit, imagine an intrusion example where adversary has gained access using spear phishing and used the infamous offensive framework “Cobalt Strike” to maintain access, elevate privileges, gather credentials and lateralize in the environment, compromised the domain and then deployed the aforementioned DACL backdoors.

Let’s say now that after a while, this actor was “eradicated” from the deployed accesses in the environment (here Cobalt Strike beacons connecting to the malicious infrastructure). Because his/her infrastructure was detected and the actor now decides to lay low. 

Picture now that blue team did not find any evidence of full domain compromise or simply could not afford a complete rebuild of the AD environment. Either way, the opponent was kicked out but the backdoor remained! After some time, he/she gains a new access to the environment – for example a secondary infrastructure for which he/she deployed long-periodic scheduled tasks (not found during incident response) – and is now able to fully compromise the domain within minutes!

Trigger phase – taking over the domain once again: 

1. Operator Logs on using the backdoor account, then Force-Resets the password of the proxy-account and logs on using proxy account. Using the proxy account, he/she changes permissions to give the proxy-account Full Control (GenericAll) over the targeted GPO.
2. These permissions propagate to the filesystem in SYSVOL, and operator can then directly add the backdoor-user to the list of account that are authorized to enable Kerberos delegation: SeEnableDelegationPrivilege. 
3. Using this privilege from the backdoor-user, the operator then configures Kerberos constrained delegation (with protocol transition) on the proxy-user account for the LDAP service on a targeted domain controller. To do so, he/she sets a value to the msds-allowedtodelegateto attribute and activates TRUSTED_TO_AUTH_FOR_DELEGATION on the account.
4. Everything is in order; the operator now only needs to abuse the configured Kerberos delegation. Starting with requesting a TGT (ticket granting ticket) to the KDC for the proxy-user.
5. Using this TGT, he/she requests a service ticket (ST) for itself as a configured service (S4U2Self) while impersonating a privileged account (Domain\Administrator for example). This service ticket is forwardable thanks to protocol transition in the configured Kerberos constrained delegation. Now using both TGT and ST, he/she is able to request a service ticket for LDAP service on the previously targeted domain controller as the impersonated privileged user (S4U2Proxy). This step would not work if this account was set sensitive for delegation or was part of “Protected Users” group. For more detailed explanations on Kerberos delegation abuses and tricks I’ll refer to the amazing paper of Elad Shamir in 2019 and the presentation of RCBD abuses by Charlie Bromberg in 2022.
6. Anyways, the offensive operator has now a obtained a service ticket that can be used for the LDAP service on a domain controller as a privileged user. The domain is basically owned, this ticket can simply be used in a DCSync attack to steal domain accounts NTLM hashes; He/she can then do all kind of Identity attacks, such as (non-exhaustive list):

• Logging in as any account using the NTLM hash: Pass the Hash
• Using the key of any account to retrieve a Kerberos TGT: Over Pass the Hash / Pass the Key
• Using krbtgt NTLM hash to forge Golden, Diamond or Saphire tickets
• Using any critical service NTLM hash to forge Silver tickets

Well, this a long, but hopefully interesting, digression into the backdoor primitives presented by Specter Ops researchers. We will now come back to our original subject: Active Directory enumeration and more specifically ADCanaries.

Solving DS Access event verbosity issue with backdoor stealth primitive

As I found myself quite stuck on this subject, I realized that stealth primitives presented by SpecterOps researchers could solve the verbosity issue when detecting AD enumeration through Directory Access event logs (4662) – using failed access events on explicitly denied objects.

If logging read success on AD objects on a production environment was an issue, it would not be the same for read access failures. It would however require world-non-readable objects – which is the exact use case of the presented stealth primitives!

Using the canary idea presented by Trustwave, it was then obvious to design a “DACL based canary” in Active Directory, relying only on Directory Service Access audit failures:

Figure 6 - AD Canary: DS Access failure mechanism

As opposed to Trustwave DNS canary, this object would not need DNS registration in the domain, and would only need to be a standard user or machine account that has no reality in the environment – disabled and protected for security measures.

After deploying part of the “hiding the principal” stealth primitive on the account, all access would trigger a failure on this object – even from elevated access. Which means any large enumeration mechanism on the domain would attempt an access on this account and trigger a 4662 event with access failure.

Even more importantly, the audit configuration required to monitor the canary is the exact recommendation from Microsoft for the audit of DS Access on domain controllers:

Figure 7 - Microsoft recommendations on Audit Directory Service Access

Another effect of using the stealth primitive on the AD Canary object is that as access attempts are denied: adversaries will not see the account in the result of their enumeration tool. Thus, this detection is transparent and will not be easily visible by attackers.

Finally, the elevated deployment of the DENY ACE positioned on the AD Canary account (which is disabled) is a way to prevent malicious use of the deployed account: only domain admin accounts (or equivalent) will have enough privileges to remove the DENY ACE and enable the account. 

In short: the deployed objects are isolated from the environment and are not subject to any sort of control relationship abuse as they are unprivileged and restricted in the environment. Exploiting such objects would require privileges equivalent to Domain Administrators, thus the deployment of this primitive does not increase Active Directory attack surface.

Lab implementation & results 

To effectively implement this detection primitive in my lab, I developed a simple deployment / clean up PowerShell script taking its inputs from a JSON configuration file.

Because 4662 events that were collected did not translate accessed objects name from the GUID (which might be caused by the deny all access). I also added capabilities to generate a CSV file that provided a lookup of the generated objects name and their GUIDs.

Figure 8 - ADCanaries.ps1 - v1

Figure 9 - ADCanaries GUID Lookup from CSV in Splunk

The detection query is then quite simple to write, using 4662 events and pivoting on our LookupTable in Splunk :

index=main source="xmlwineventlog:security" EventCode=4662 host="activedirectory"

| eval ObjectName=replace(mvindex(split(ObjectName,"{"),1),"}","")

| lookup CanaryADObjectsLookup CanaryGUID as ObjectName OUTPUTNEW CanaryName as CanaryObjectName

| where CanaryObjectName!=""

| convert ctime(_time) as Time

| stats values(CanaryObjectName) as Canaries, values(Time) as Time, values(SubjectLogonId) as LogonIds by SubjectUserName,SubjectDomainName

And upon testing with several Active Directory enumeration tools the results were good:

Figure 10 - Detection tests results

Figure 11 – user1: ADFind.exe - 3:45 | 3:47 PM UTC+02

Figure 12 - user2: Sharphound.ps1 - 3:49 PM UTC+02

Figure 13 - user3: ADRecon.ps1 - 4:45 PM UTC+02

The three tested tools were instantly detected, and no false positives were generated in the lab environment, which was expected as no production related AD enumeration was deployed. 

More importantly when looking at the number of logs generated by the audit configuration that was implemented (i.e. amount of 4662 events collected), only suspicious events were generated in the lab – with a more than reasonable quantity of around 40 events per enumeration:

Figure 14 - Amount of 4662 events through time

These tests were of course not exhaustive nor representative of the real impact of the audit configuration in a production environment. However, they were promising, and impact on production environment would be expected to be minimal. 

Comparison with similar detection primitive: Honeypot accounts – Sean Metcalf 

Upon redaction of this blog post, I discovered that the presented detection primitive had, at least partly, a similar approach to the “honeypots accounts” introduced by Sean Metcalf in 2020. However, I believe the philosophy of implementation and the limitations differs between these two detection primitives. So, let’s compare and identify what AD canaries might bring to the table!

In his blog post – that I really recommend reading, Sean Metcalf details what AD enumeration – or AD recon – is from the attacker perspective, and how to build honeypot accounts that would trick attackers into getting detected. Honeypot accounts are bait accounts deployed in the environment placed to appear among real users and look tempting to adversaries. The blog post contains multiple means to deploy effective honeypots and considerations on how to “make them realistic” and on security exposure of such accounts.

Although AD canaries and honeypot accounts both intends to detect malicious AD enumeration on the environment, detection approaches differ strongly. Whereas honeypots focus on baiting the adversary with visible and tempting assets, AD canaries are hidden from the adversary (and from everyone in the environment). Moreover, detection of adversary activity is made by observing adversary interaction with deployed honeypots accounts (Kerberoast attempt, AS-REP roast attempt) but does not detect Active Directory enumeration per-say, as opposed to AD canaries. 

Another important difference is that AD canaries will always trigger upon Active Directory enumeration (if not targeting a specific list of users), whereas honeypot accounts can be evaded if the adversary does not take the bait and focuses on another attack path.

Finally, AD canaries are not designed specifically for the environment, they can be deployed as is and will provide detection capabilities, with no potential impact on AD attack paths (which is a problem to consider when deploying honeypots).

Important side note: Don’t get this wrong, Sean Metcalf’s honeypots is an awesome way to detect adversaries inside your networks; focus is made here on where AD canaries differs and might offer a new solution to the same kind of problem.

Part 2: Conclusion

Offensive research is a pillar for improving both red and blue team’s understanding on many security subjects. Understanding and reading about offensive techniques is an important part of defender’s job and helps identify new techniques, exploitations and abuses to build detection for. It also contributes to nurturing creativity, which is particularly useful when searching for new detection mechanisms. I hope that AD canaries’ misuse of DACL backdoors is a good example of offensive research inspiring and giving new ideas to defenders.

This – quite long – blog section detailed AD canaries’ detection mechanism and lab implementation results. And, comparison with existing similar approaches helped identifying what this detection primitive brings to the table in matter of detecting adversary abuses of AD attack paths in our environments.

Although AD canaries seem to effectively solve some of the issues that were identified in the previous part of this blog series, these were only lab results and no focus was made on operational use of this primitive in a SOC environment. As this is not a trivial task, the next and final section of this blog post will cover both the exploratory work that aimed at making it useable for SOC operations, and the results of the deployment of AD canaries in a real in-production environment. 

Coming soon: Part 3: Making it useable – improvements and in-production deployment results

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 Protect SOC team.

• Share