Active Directory Methodology
Last updated
Was this helpful?
Last updated
Was this helpful?
Do you use Hacktricks every day? Did you find the book very useful? Would you like to receive extra help with cybersecurity questions? Would you like to find more and higher quality content on Hacktricks? so we can dedicate more time to it and also get access to the Hacktricks private group where you will get the help you need and much more!
If you want to know about my latest modifications/additions or you have any suggestion for HackTricks or PEASS, join the , or follow me on Twitter . If you want to share some tricks with the community you can also submit pull requests to that will be reflected in this book and don't forget to give ⭐ on github to motivate me to continue developing this book.
Active Directory allows network administrators to create and manage domains, users, and objects within a network. For example, an admin can create a group of users and give them specific access privileges to certain directories on the server. As a network grows, Active Directory provides a way to organize a large number of users into logical groups and subgroups, while providing access control at each level.
The Active Directory structure includes three main tiers: 1) domains, 2) trees, and 3) forests. Several objects (users or devices) that all use the same database may be grouped in to a single domain. Multiple domains can be combined into a single group called a tree. Multiple trees may be grouped into a collection called a forest. Each one of these levels can be assigned specific access rights and communication privileges.
Main concepts of an Active Directory:
Directory – Contains all the information about the objects of the Active directory
Object – An object references almost anything inside the directory (a user, group, shared folder...)
Domain – The objects of the directory are contained inside the domain. Inside a "forest" more than one domain can exist and each of them will have their own objects collection.
Tree – Group of domains with the same root. Example: dom.local, email.dom.local, www.dom.local
Forest – The forest is the highest level of the organization hierarchy and is composed by a group of trees. The trees are connected by trust relationships.
Active Directory provides several different services, which fall under the umbrella of "Active Directory Domain Services," or AD DS. These services include:
Domain Services – stores centralized data and manages communication between users and domains; includes login authentication and search functionality
Certificate Services – creates, distributes, and manages secure certificates
Lightweight Directory Services – supports directory-enabled applications using the open (LDAP) protocol
Directory Federation Services – provides single-sign-on (SSO) to authenticate a user in multiple web applications in a single session
Rights Management – protects copyrighted information by preventing unauthorized use and distribution of digital content
DNS Service – Used to resolve domain names.
If you just have access to an AD environment but you don't have any credentials/sessions you could:
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 //
Enumerate Ldap:
nmap -n -sV --script "ldap* and not brute" -p 389 <DC IP>
Poison the network
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.
You could also use the impacket script of ASREPRoast to enumerate valid usernames.
Ok, so you know you have already a valid username but no passwords...Then try:
For this phase you need to have compromised the credentials or a session of a valid domain account.
Having compromised an account is a big step to start compromising the whole domain, because you are going to be able to start the Active Directory Enumeration:
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.
For the following techniques a regular domain user is not enough, you need some special privileges/credentials to perform these attacks.
Once you get Domain Admin privileges, you can dump all the domain database.
A valid TGT as any user can be created using the NTLM hash of the krbtgt AD account. The advantage of forging a TGT instead of TGS is being able to access any service (or machine) in the domain ad the impersonated user.
Microsoft considers that the domain isn't a Security Boundary, the Forest is the security Boundary. This means that if you compromise a domain inside a Forest you are going to be able to compromise the entire Forest.
Essentially, all a trust does is linking up the authentication systems of two domains and allowing authentication traffic to flow between them through a system of referrals. When 2 domains trust each other they exchange keys, these keys are going to be saved in the DCs of each domains (1 key per trust direction) and the keys will be the base of the trust.
When a user tries to access a service on the trusting domain it will request an inter-realm TGT to the DC of its domain. The DC wills serve the client this TGT which would be encrypted/signed with the inter-realm key (the key both domains exchanged). Then, the client will access the DC of the other domain and will request a TGS for the service using the inter-realm TGT. The DC of the trusting domain will check the key used, if it's ok, it will trust everything in that ticket and will serve the TGS to the client.
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.
A trust relationship can also be transitive (A trust B, B trust C, then A trust C) or non-transitive.
Different trusting relationships:
Parent/Child – part of the same forest – a child domain retains an implicit two-way transitive trust with its parent. This is probably the most common type of trust that you’ll encounter.
Cross-link – aka a “shortcut trust” between child domains to improve referral times. Normally referrals in a complex forest have to filter up to the forest root and then back down to the target domain, so for a geographically spread out scenario, cross-links can make sense to cut down on authentication times.
Forest – a transitive trust between one forest root domain and another forest root domain. Forest trusts also enforce SID filtering.
Enumerate the trusting relationships
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).
kerberoast in this case could be another option.
Compromise the accounts which can pivot through domains.
There are three main ways that security principals (users/groups/computer) from one domain can have access into resources in another foreign/trusting domain:
They can be added to local groups on individual machines, i.e. the local “Administrators” group on a server.
They can be added to groups in the foreign domain. There are some caveats depending on trust type and group scope, described shortly.
Also, notice that there are 2 trusted keys, one for Child --> Parent and another one for Parent --> Child.
For finding the SID of the "Enterprise Admins" group you can find the SID of the root domain and set it in S-1-5-21root domain-519. For example, from root domain SID S-1-5-21-280534878-1496970234-700767426 the "Enterprise Admins"group SID is S-1-5-21-280534878-1496970234-700767426-519
Escalate to DA of root or Enterprise admin using the KRBTGT hash of the compromised domain:
In this case you can sign with the trusted key a TGT impersonating the Administrator user of the current domain. In this case you won't always get Domain Admins privileges in the external domain, but only the privileges the Administrator user of your current domain was given in the external domain.
SID Filtering:
Avoid attacks which abuse SID history attribute across forest trust.
Enabled by default on all inter-forest trusts. Intra-forest trusts are assumed secured by default (MS considers forest and not the domain to be a security boundary).
But, since SID filtering has potential to break applications and user access, it is often disabled.
Selective Authentication
In an inter-forest trust, if Selective Authentication is configured, users between the trusts will not be automatically authenticated. Individual access to domains and servers in the trusting domain/forest should be given.
Not allow Domain Admins to login on any other hosts apart from Domain Controllers
Never run a service with DA privileges
If you need domain admin privileges, limit the time: Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)
Password does not expire
Trusted for Delegation
Users with SPN
Password in description
Users who are members of high privilege groups
Users with ACL rights over other users, groups or containers
Computer objects
...
Create-DecoyUser -UserFirstName user -UserLastName manager-uncommon -Password Pass@123 | DeployUserDeception -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose
For user objects:
ObjectSID (different from the domain)
lastLogon, lastlogontimestamp
Logoncount (very low number is suspicious)
whenCreated
Badpwdcount (very low number is suspicious)
General:
Some solutions fill with information in all the possible attributes. For example, compare the attributes of a computer object with the attribute of a 100% real computer object like DC. Or users against the RID 500 (default admin).
Check if something is too good to be true
ATA only complains when you try to enumerate sessions in the DC, so if you don't look for sessions in the DC but in the rest of the hosts, you probably won't get detected.
Always create the tickets using the aes keys also because what ATA identifies as malicious is the degradation to NTLM.
If you don't execute this from a Domain Controller, ATA is going to catch you, sorry.
AD DS is included with Windows Server (including Windows Server 10) and is designed to manage client systems. While systems running the regular version of Windows do not have the administrative features of AD DS, they do support Active Directory. This means any Windows computer can connect to a Windows workgroup, provided the user has the correct login credentials. From:
To learn how to attack an AD you need to understand really good the Kerberos authentication process.
You can take a lot to to have a quick view of which commands you can run to enumerate/exploit an AD.
Pentest the network: Scan the network, find machines and open ports and try to exploit vulnerabilities or extract credentials from them (for example, . Take a look to the General to find more information about how to do this.
Gather credentials
Access host by ****
Gather credentials exposing
OSINT: Try to extract possible usernames from services (mainly web) inside the domain environments and also from the publicly available web pages of the company. If you find the complete names of company workers, you could try different AD username conventions (). 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). You could also try statistically most used usernames: Read the following Username enumeration section to learn how to find if a username is valid or not.
: 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.
: 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)
A final option if the accounts cannot be locked is the ****
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.
Regarding you can now find every possible vulnerable user, and regarding you can get a list of all the usernames and try the password of the compromised account (if you know it). It's very easy to obtain all the domain usernames from Windows (net user /domain ,Get-DomainUseror wmic useraccount get name,sid). In* linux\* you can use: GetADUsers.py -all -dc-ip 10.10.10.110 domain.com/username
You could use some, but using will probably be stealthier, and you could even to extract more detailed information. Always learn what a CMD or powershell/powerview command does before executing it, this way you will know how stealth are you being.
Another amazing tool for recon in an active directory is . 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.
If you are using Linux, you could also .
You could also try
The goal of Kerberoasting is to harvest TGS tickets for services that run on behalf of user accounts in the AD, not computer accounts. Thus, part of these TGS tickets are encrypted with keys derived from user passwords. As a consequence, their credentials could be cracked offline. You can know that a user account is being used as a service because the property "ServicePrincipalName" is not null. Find more information about this attack .
If you have compromised credentials or a session as a regular domain user and you have access with this user to any machine in the domain you should try to find your way to escalate privileges locally. This is because only with admin privileges you will be able to dump hashes of other users in memory (LSASS) and locally (SAM). There is a complete page in this book about and a . Also, don't forget to use .
Once you have obtained some credentials you could check if you have access to any machine using the win-rm service.
Hopefully you have managed to compromise some local admin account using , , , , , ... or . Then, its time to dump all the hashes in memory and locally.
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. .
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.
This attack is similar to Pass the Key, but instead of using hashes to request a ticket, the ticket itself is stolen and used to authenticate as its owner. .
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). Also, if a MSSQL instance is trusted (database link) by a different MSSQL instance. If the user has privileges over the trusted database, he is going to be able to use the trust relationship to execute queries also in the other instance. These trusts can be chained and at some point the user might be able to find a misconfigured database where he can execute commands. The links between databases work even across forest trusts.
If you find any Computer object with the attribute 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 . Thanks to constrained delegation you could even automatically compromise a Print Server (hopefully it will be a DC).
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.
The compromised user could have some interesting privileges over some domain objects that could let you move laterally/escalate privileges.
If you can find any Spool service listening inside the domain, you may be able to abuse is to obtain new credentials and escalate privileges.
More information about . More information about.
Some of the techniques discussed before can be used for persistence. For example you could make a user vulnerable to or to .
The Silver ticket attack is based on crafting a valid TGS for a service once the NTLM hash of service is owned (like the PC account hash). Thus, it is possible to gain access to that service by forging a custom TGS as any user (like privileged access to a computer).
The Access Control List (ACL) of the AdminSDHolder object is used as a template to copy permissions to all “protected groups” in Active Directory and their members. Protected groups include privileged groups such as Domain Admins, Administrators, Enterprise Admins, and Schema Admins. By default, the ACL of this group is copied inside all the "protected groups". This is done to avoid intentional or accidental changes to these critical groups. However, if an attacker modifies the ACL of the group AdminSDHolder for example, giving full permissions to a regular user, this user will have full permissions on all the groups inside the protected group (in an hour). And if someone tries to delete this user from the Domain Admins (for example) in an hour or less, the user will be back in the group. .
There is a local administrator account inside each DC. Having admin privileges in this machine, you can use mimikatz to dump the local Administrator hash. Then, modifying a registry to activate this password so you can remotely access to this local Administrator user. ****
You could give some special permissions to a user over some specific domain objects that will let the user escalate privileges in the future.
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. .
Modify LSASS in memory to create a master password that will work for any account in the domain.
You can create you own SSP to capture in clear text the credentials used to access the machine. .
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. ****
At a high level, a establishes the ability for users in one domain to authenticate to resources or act as a in another domain.
External – an implicitly non-transitive trust created between disparate domains. “” External trusts enforce SID filtering, a security protection covered later in this post.
Tree-root – an implicit two-way transitive trust between the forest root domain and the new tree root you’re adding. I haven’t encountered tree-root trusts too often, but from the , they’re created when you when you create a new domain tree in a forest. These are intra-forest trusts, and they while allowing the tree to have a separate domain name (instead of child.parent.com).
MIT – a trust with a non-Windows Kerberos domain. I hope to dive more into MIT trusts in the future.
They can be added as principals in an access control list, most interesting for us as principals in ACEs in a DACL. For more background on ACLs/DACLs/ACEs, check out the “” whitepaper.
Please, find some migrations against each technique in the description of the technique.
