TL;DR : This post is the result of my experiments on Active Directory monitoring. I describe the ideas I got about how hardening an AD forest & AD security also lives through active monitoring. I list the different honeypot ideas I got, how they work, and how to deploy them. ![[you_just_activated_my_trapcard.png]] # I : Honeypots ? Honeypots are a kind of very interesting objects in cybersecurity. The idea behind them is very simple, and you probably heard about it before even though you don't actively use them. A **honeypot** is a decoy computer system, network, service or object designed to attract and trap malicious actors. It is intentionally created to look like a legitimate and vulnerable target, luring attackers into a controlled environment where their activities can be monitored and analyzed without risk to an organization's actual network. The fundamental principle behind it is **deception**. By presenting an easy target, security teams can study the tools, techniques, and procedures (TTPs) used by adversaries. This intelligence is invaluable for strengthening real-world defenses and understanding emerging threats. Beside the obvious advantage of analyzing the opponent's methods while it is exploiting a fake vulnerable configuration, honeypots also act as tripwires that can instantly alert security teams on the presence of an attacker in the organization's environment so that the org's IT can trigger investigation and Incident Response before its too late. For those objects to be useful, an extensive knowledge and experience about the way attackers think and how exploiting vulnerable components translates in reality is required. What make honeypots fascinating items is the fact they perfectly embody the idea that securing an infrastructure also relies on knowing offensive security, the same way that EDRs and AVs only improve because malicious actors learn how to bypass them. As [CrowdStrike](https://www.crowdstrike.com/en-au/cybersecurity-101/exposure-management/honeypots/#:~:text=A%20honeypot%20is%20a%20cybersecurity,methods%20and%20motivations%20of%20adversaries.) describes it, the efficiency of honeypots depends on the time attacker are likely to spend exploiting them before realizing they are traps : >[!QUOTE] >A low-interaction honeypot uses relatively few resources and collects basic information about the attacker. These honeypots are relatively easy to set up and maintain and **most production honeypots are considered low-interaction honeypots**. > >Because they are fairly unsophisticated, they are unlikely to hold the attention of an attacker for very long. This means they are unlikely to be a particularly effective decoy and will only produce limited intelligence about the adversary. Given the growing sophistication of many adversaries, some advanced attackers can spot low-level decoys and avoid them or even exploit them by feeding them misinformation. Honeypots are easy to understand, but harder to conceptualize as they must act as high-fidelity alerting objects. Since no legitimate user should ever interact with it, any traffic or activity directed at the honeypot is, by definition, suspicious or malicious. But creating too obvious traps or ineffective (hard to maintain, generates too many false positives alerts ...) honeypots will distract security teams. # II : Honeypots applied to Active Directory I researched some ideas that I gathered over the years to create some Active Directory-oriented honeypot objects. They have been tested and deployed in labs, but they will only work when combined with active detection rule sets and SIEM usage : ### ASREP-Roast This one pretty standard. The corresponding function in the main script deploys a new user account in the domain. You can chose the name as well as the destination OU. The script then sets up the new account by disabling the pre-auth phase for Kerberos authentication. Without going over the details of the consequence of this behaviour (ASREP-Roasting is a well documented attack), attackers in the domain can request Kerberos authentication tickets (without knowing the account's password) in order to try and crack the hash that was used to cypher the ticket. The attacker's interest in such configuration lies in the fact an initial access to the AD domain is actually not required. But worry not, ASREP-Roasting constitutes a great opportunity for detection. As a matter of fact, monitoring an ASREP-Roastable account enables for high fidelity alerting, as only an attacker interested in taking over this account (that does not require providing a timestamp cyphered with its hash as a pre-authentication phase) would try requesting a TGT for it. Monitoring any TGT request event (4768) or Kerberos successful logon (4624) for this vulnerable account will reveal any attempt to retrieve authentication tickets. Authenticating events coming from this account, especially 4768 (A Kerberos authentication ticket (TGT) was requested) are to be considered as security incidents, as this account is not supposed to request TGTs. ### Kerberoast Still in the realm of Kerberos abuse, Kerberoasting is another very famous attack that offers great opportunities for deception and detection. The main script deploys a new user account in the domain and associates a specific Service Principal Name to it. This means that any account in the domain can now asks for a Kerberos Service Tickets for this specific service. Such configuration also implies an attacker with an initial access to request STs for the deployed service as well. Monitoring 4769 events (Kerberos service ticket request) on Domain Controllers is invaluable for checking any Kerberoasting attempt on the honeypot account. ### User Account A very simple domain user account that is not supposed to interact with any other objects in the domain Indeed, this user account has been set up with the `PasswordNotRequired` flag, which means an attacker enumerating potential misconfigurations on user accounts might find this honey user very interesting Any interaction coming from this user account is to be treated as a security incident, such as : NTLM authentication, Kerberos ticket request or authentication success or failure, object access (share access, user enumeration, LDAP interaction, ...). Another possibility for this account could be to add its password in the user description so that an attacker reading it could try to authenticate. To avoid exposing the rest of the domain to enumeration, the deployed account is prevented from reading and doing anything in the domain. A full `Deny` is applied for the account on the domain object itself, in order to override the `Authenticated Users` read permission. Failure auditing is then configured on the user object itself ![[password_not_required_trap.png]] ### Pre2K Machine Account This one relies on the Pre2K machine account attack. Any computer account created with the "Pre-Windows 2000 compatible account" is given a password that is equals to its computer name. Until a computer with the same name is added to the domain in order to use it, the computer account remains unused, but still able to authenticate. This configuration allows attackers to retrieve the full computer list in the domain and trying to authenticate to each computer with their name or by guessing computer names from the current nomenclature of available machines. The corresponding function deploys an honeypot computer account that is added in the "Pre-Windows 2000 compatible". The script specifically sets up the password as equal to its computer name. The account is then unable to enumerate any other objects in the domain by performing the same Deny & audit operations than for the previous functions. ### Autologon This functions create a new GPO object to be linked to an existing OU, that will embark credentials. An attacker enumerating GPOs in the domain will likely finds the cleartext username and password. However, the twist here is that the specified account which password appears in the GPO ... does not exist. Analysts only has to monitor any authenticating attempts events containing the honeypot user account name, and consider any event with this event as a security incident. ### Group Policy Object This function creates a new GPO in the domain, then links it to the root domain object. The GPO does not actually enforce any parameter to the OU and computers it will applies to. This GPO has no other purpose than to be enumerated and read by a potential attacker. Indeed, pentesters & attackers tools tend to read all GPOs in the domain at the same time, making it easier for defenders to start investigations on GPO enumeration. ![[Its_an_ad_trap.png]] ### Enable-AllGpoAuditing This functions simply apply an audit rule to every GPO in the domain. This can generate a great amount of security events, so be careful. # III : Deploying AD objects to monitor AD attacks ![[lamy_AD.png]] As previously explained, the goal of the tool is to deploy honeypots in the domain to help defenders and analysts trigger security events with high-fidelity honey objects. However, it is to be noted that deploying those objects alone will not necessarily increase the security level of your domain. Those honeypots needs to be monitored and work in synergy with active SIEM detection rule and real analysts. Again, PowerShell automation comes in handy as its versatility not only allows for easy objects creation, but also auditing rules on the deployed objects. ADHD simply needs to be imported on a Domain Controller, and its functions called with the right values for its parameters (account names, OUs, computer names etc) Code is available [here](https://github.com/y00ga-sec/ADHD), and thanks for reading !