One Night to Domain Admin in a Two-Domain Forest
You have plaintext credentials for a helpdesk account, hdesk_07, in the child domain corp.local of a forest whose root is holding.local. The forest has 8 domain controllers, 4,200 users, and a 3-tier admin model. BloodHound shows hdesk_07 has GenericAll on the group Helpdesk_Tier1; that group has delegated rights to reset passwords for Tier1 users. A service account, svc_sql, has an SPN and its password was last set 3 years ago. The ADCS CA publishes a template named WebServer with ENROLLEE_SUPPLIES_SUBJECT enabled; Domain Users can enroll. There is also a constrained delegation from WEB01 to FILE01 for HTTP. The client asks whether you can reach Domain Admin tonight. Their SOC monitors 4624/4625 and alerts on more than five failures per account in ten minutes. You have four hours of testing time; no ransomware-like behavior; credential dumping on DCs is out of scope.
1. Rank the available paths by likelihood and operational risk. Justify the top choice.
Read the worked answer
Rank: (1) Kerberoast svc_sql - offline, no lockout, low SOC noise; crack with a targeted wordlist and hashcat. If the password falls, check svc_sql's rights; it may not be DA, but it is a clean first step. (2) ADCS ESC1 - high impact but creates a CA record and a certificate; verify the template before using it. (3) GenericAll on Helpdesk_Tier1 - powerful but writes to AD and is likely to be logged and reviewed. (4) Constrained delegation - requires control of WEB01 and a service ticket, more moving parts. The top choice is Kerberoasting because it does not authenticate repeatedly, does not modify AD, and cannot lock the account. The caveat is that cracking may fail within four hours if the password is strong. If it fails, move to ESC1, not to password resets. Do not start with GenericAll; adding yourself to a group is a visible change and the SOC may treat it as an intrusion.
2. What do you verify before using the ESC1 template, and what could make it a false positive?
Read the worked answer
Verify that the template is published on the CA, Domain Users has Enroll, ENROLLEE_SUPPLIES_SUBJECT is set, the template EKU includes Client Authentication or Smart Card Logon, manager approval is not required, the CA does not enforce SAN restrictions, and strong certificate mapping (KB5014754) is not in full-enforcement mode. Also confirm you can read a DA username from LDAP and that PKINIT is available on the DC. False positives: the template is disabled, the CA is offline, enrollment requires approval, the template only allows server authentication, or the certificate cannot be used for PKINIT because the DC enforces mapping. A request that succeeds but cannot authenticate is not a path. Test with a low-privilege canary first: request a certificate for your own user with a SAN of another low-privilege user and try PKINIT. If that fails, do not burn a DA request.
3. How do you avoid tripping the SOC while confirming the path?
Read the worked answer
Use LDAP reads, not authentication storms. Query the directory once for DA members, template objects, and CA settings. Do not password-spray. For Kerberoasting, request one TGS for svc_sql from your existing session; that is a single 4769, not a failure. For ESC1, request one certificate for a canary, then one PKINIT authentication. Avoid repeated authenticated certipy find runs; use LDAP or an offline copy. If you must authenticate as a DA, do it once, from the same workstation, and do not run lateral-movement commands immediately afterward. Keep a timeline of every logon so you can explain the 4624s. The SOC threshold is five failures in ten minutes; your plan should generate zero failures. If a tool retries, stop it. The goal is to prove the path with the minimum number of events, not to complete the full attack chain.