Notes - Active Directory and Kerberos Attacks Summary
intro
There are many attacks against Active Directory and Kerberos and they can get very confusing over a pentest engagement. IRed Team has done a great job in the each case study here https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse. Yet, reading through all of the posts can be time consuming and sometimes, it’d be easier to have a reference to refer to. Below is an attempt to summarize these post so that people can refer to the table to understand what’s the condition for each exploit scenario and what are the expected steps to take.
Attack Technique | Conditions Required | Exploit Steps | Tools | Link |
---|---|---|---|---|
Child Domain DA to EA in Parent Domain | Access to a DA account in a child domain and knowledge of a valid user account in the parent domain | 1. Create a malicious SPN in the child domain using a valid user account in the parent domain 2. Use the DA account in the child domain to request a TGS ticket for the malicious SPN 3. Use the TGS ticket to obtain a referral TGT for the parent domain 4. Use the referral TGT to request a TGS ticket for an EA account in the parent domain | Rubeus | Link |
Kerberoasting | A domain user account with the “SeTcbPrivilege” privilege and knowledge of valid user accounts with SPNs set in Active Directory | 1. Identify valid user accounts with SPNs set in Active Directory 2. Request a TGS ticket for the SPN using the domain user account with “SeTcbPrivilege” 3. Use a tool like “tgsrepcrack” to crack the password hash in the TGS ticket | Rubeus, tgsrepcrack | Link |
Kerberos Golden Tickets | Knowledge of the domain’s KRBTGT account password hash | 1. Use Mimikatz to extract the KRBTGT account password hash from memory or a domain controller 2. Use the password hash to create a forged TGT with a ticket-granting service (TGS) for any user account or service in the domain 3. Use the forged TGT to gain access to any resource in the domain as the impersonated user or service | Mimikatz | Link |
Kerberos Silver Tickets | Knowledge of a user’s NTLM hash | 1. Use Mimikatz to extract the user’s NTLM hash from memory or a domain controller 2. Use the hash to create a forged TGS for a service account in the domain 3. Use the forged TGS to gain access to the service as the user | Mimikatz | Link |
AS-REP Roasting | A domain user account without the “Pre-Authentication Required” flag set and knowledge of valid user accounts in Active Directory | 1. Identify valid user accounts without the “Pre-Authentication Required” flag set in Active Directory 2. Use a tool like Rubeus to request an AS-REP for each user account 3. Use a tool like Hashcat to crack the password hash in the AS-REP | Rubeus, Hashcat | Link |
Kerberoasting (RC4 Encrypted TGS) | Valid domain user account and the ability to connect to a domain controller over LDAP or RPC | 1. Identify user accounts in the domain that are allowed to request Kerberos Ticket-Granting Tickets (TGTs) 2. Use a tool like GetUserSPNs in Impacket or Rubeus to request Service Principal Names (SPNs) for user accounts that are allowed to request Kerberos TGTs 3. Use a tool like GetUserSPNs in Impacket or Rubeus to request Kerberos TGSs for each SPN 4. Use a tool like Hashcat to crack the password hash in the TGS | GetUserSPNs, Rubeus, Hashcat | Link |
Domain Compromise via Unrestricted Kerberos Delegation | A domain user account with the “Trust this user for delegation to any service (Kerberos only)” user right or a computer account with the “Trust this computer for delegation to any service (Kerberos only)” computer right | 1. Identify user or computer accounts with the “Trust this user/computer for delegation to any service (Kerberos only)” right 2. Use a tool like BloodHound or PowerView to identify services to which the accounts are trusted to delegate 3. Use a tool like Rubeus to request a TGS for the target service with delegation enabled 4. Use the TGS to authenticate to the target service as the trusted user or computer | BloodHound, PowerView, Rubeus | Link |
Abusing Kerberos Constrained Delegation | A domain user account with the “Trust this user for delegation to specified services only” user right or a computer account with the “Trust this computer for delegation to specified services only” computer right | 1. Identify user or computer accounts with the “Trust this user/computer for delegation to specified services only” right 2. Use a tool like BloodHound or PowerView to identify services to which the accounts are trusted to delegate 3. Use a tool like Rubeus to request a TGS for the target service with constrained delegation enabled 4. Use the TGS to authenticate to the target service as the trusted user or computer | BloodHound, PowerView, Rubeus | Link |
Resource-Based Constrained Delegation: AD Computer Object Take Over and Privileged Code Execution | A domain user account with the “Write” permission on the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of a computer object | 1. Identify computer objects with the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute set 2. Identify user accounts with the “Write” permission on the attribute 3. Use a tool like PowerView to dump the password hash of the computer object 4. Use the password hash to authenticate as the computer object 5. Request a TGS for a service with resource-based constrained delegation enabled and “msDS-AllowedToActOnBehalfOfOtherIdentity” set to the target user or computer 6. Use the TGS to authenticate to the target service as the target user or computer with privileged code execution | PowerView | Link |
Domain Compromise via DC Print Server and Kerberos Delegation | A domain user account with the “Validated write to DNS host name” permission on the computer object of the DC print server and the “Printer Admins” or “Print Operators” group membership on the print server | 1. Identify the DC print server 2. Identify user accounts with the “Validated write to DNS host name” permission on the computer object of the DC print server 3. Identify user accounts with the “Printer Admins” or “Print Operators” group membership on the print server 4. Use a tool like PowerSploit’s “GetST” to request a TGS for the DC with the “cifs” and “host” SPNs 5. Use the TGS to authenticate as the DC 6. Dump the NTLM hash of the KRBTGT account and use it to create Golden Tickets | PowerSploit | Link |
Creating Rogue Domain Controllers with DCShadow | Access to a domain-joined machine or a machine with a network connection to a domain controller and the required permissions to create a new domain controller object | 1. Create a new domain controller object in Active Directory using the “DCShadow” technique 2. Add the newly created DC to the “krbtgt” SPN’s “msds-allowedtodelegateto” attribute 3. Use a tool like Mimikatz to extract the NTLM hash of the KRBTGT account from the newly created DC 4. Use the NTLM hash to create Golden Tickets | DCShadow, Mimikatz | Link |
Dump Password Hashes from Domain Controller with DCSync | High-level domain privileges or domain admin access | 1. Use a tool like Mimikatz to obtain domain admin or high-level domain privileges 2. Request password hashes from a domain controller using the DCSync technique 3. Dump password hashes | Mimikatz | Link |
Active Directory Enumeration with PowerView | Access to a domain-joined machine or a machine with a network connection to a domain controller and the appropriate permissions to query Active Directory | 1. Use the PowerView tool to gather information about the domain’s users, groups, computers, and domain controllers 2. Use gathered information to identify potential attack vectors and targets | PowerView | Link |
Abusing Active Directory ACLs/ACEs | Access to a domain-joined machine or a machine with a network connection to a domain controller and the appropriate permissions to query Active Directory | 1. Identify weak or misconfigured ACLs/ACEs in Active Directory 2. Use a tool like BloodHound to map the network and identify potential attack paths 3. Use gathered information to identify potential targets and attack vectors | BloodHound | Link |
Privileged Accounts and Token Privileges | Access to a domain-joined machine or a machine with a network connection to a domain controller and a domain user account with administrative privileges | 1. Use tools like BloodHound and PowerView to identify privileged accounts and groups 2. Identify the token privileges of the identified accounts and groups 3. Elevate privileges by manipulating token privileges or creating a new access token with the desired privileges | BloodHound, PowerView | Link |
From DNSAdmins to SYSTEM to Domain Compromise | Access to a domain-joined machine with a DNS Server role installed and a domain user account with DNSAdmins group membership | 1. Use the DNS Server service to create a new AD-integrated DNS zone 2. Add a new DNS record with a script for execution 3. Trigger the DNS Server to load the script and execute it under the SYSTEM account 4. Use the SYSTEM-level access to dump password hashes or create a new domain user account with administrative privileges | None specified | Link |
Pass-the-Hash with Machine Accounts | Target machine account access, hash extraction | 1. Extract machine account hash 2. Generate an SPN for target machine 3. Request a TGS for the SPN with extracted hash | Mimikatz, Rubeus | Link |
BloodHound Attack Graph | Domain connectivity, read access to Active Directory | Collect data using PowerShell scripts, analyze with BloodHound | BloodHound, PowerShell | Link |
Abusing and Backdooring AdminSDHolder | - Domain user account - Active Directory Domain - Schema admin privileges (optional) | 1. Identify high-privileged accounts that are members of AdminSDHolder protected group 2. Add a backdoor to an object’s adminCount attribute 3. Wait for the backdoor object to be granted domain admin rights via AdminSDHolder mechanism | BloodHound, Active Directory Users and Computers, ADSIEdit | Link |
Active Directory Enumeration | Access to AD Module or Remote Server Administration | 1. Import ActiveDirectory module in PowerShell. 2. Connect to the domain with the Connect-ADService cmdlet.3. Use the Get-ADComputer cmdlet to enumerate computers in the domain.4. Use the Get-ADUser cmdlet to enumerate users in the domain.5. Use the Get-ADGroup cmdlet to enumerate groups in the domain.6. Use the Get-ADGroupMember cmdlet to enumerate group memberships in the domain.7. Use the Get-ADObject cmdlet to search for additional information in the domain. | PowerShell and AD Module, and/or RSAT tools | Link |
Using Dsacls to Check AD Object Permissions | User access to a domain-joined workstation | 1. Open a Command Prompt or PowerShell window as the user. 2. Type dsacls "<AD Object>" and press Enter to check the permissions for the AD object. | Dsacls.exe | Link |
Password Spraying | Valid Usernames | 1. Identify valid usernames 2. Generate list of passwords 3. Use a tool to spray passwords against the domain 4. Collect results and identify successful logins | 1. Spraykatz 2. Ruler 3. Sprayhound 4. Others | Link |
NTLM Relay Attack with PetitPotam | Access to network and victim machine | 1. Install needed tools 2. Conduct a nmap scan to find target 3. Start NTLM relay attack 4. Request and capture TGS tickets 5. Crack the captured tickets | - Responder - PetitPotam - Nmap - Hashcat | Link |
Misconfigured Certificate Template | Misconfigured Certificate Template | 1. Identify the misconfigured certificate template and determine the ACLs associated with it 2. Generate a certificate using the misconfigured template and ensure it is enrolled in the target user or machine 3. Perform a Certificate Services DCOM relay attack to elevate privileges | Mimikatz, Rubeus, Impacket, Evil-WinRM | Link |
Shadow Credentials | User with a password hash and local admin access to a workstation | 1. Retrieve the ntds.dit and SYSTEM hive files from the Domain Controller. 2. Extract password hashes using tools such as Mimikatz or secretsdump.py. 3. Pass the hash of a privileged user to gain access to resources on the domain. | Mimikatz, secretsdump.py | Link |
Abusing Trust AccountUSD | Access to a user account in a trusting domain | 1. Identify a domain with trust relationships 2. Create a user in the trusted domain with the same name as a user in the trusting domain 3. Map the victim user’s SID to the new user in the trusted domain 4. Use the trust relationship to access resources in the trusting domain | Link |