Kerberoast to Domain Admin With the EDR Watching
Contoso's internal Active Directory engagement covers 60 servers, 900 users, and two domain controllers. The rules of engagement prohibit LSASS memory access, any ransomware simulation, and disabling security tooling; the EDR is in blocking mode, and the client requires a phone call to the SOC the first time an alert fires. From an owned workstation you collect BloodHound data: the service account svc_sql holds the SPN MSSQLSvc/sql01.contoso.local:1433, is a sysadmin on SQL01, and has 'Password never expires.' Kerberoasting returns a TGS you crack offline in 40 minutes to a password matching the company's 2019 naming pattern. svc_backup holds GenericAll over OU=Workstations. A separate collector run from your Windows jump host was blocked by EDR within 90 seconds. The client's remediation owner says both service accounts rotate every 90 days, so 'the finding is already handled.'
1. Rank the available attack paths and justify which you pursue first.
Read the worked answer
Rank by what each path returns per unit of noise, not by what is most impressive.
Path A - Kerberoasting (already complete). Requesting a TGS is a domain controller event (4769 with RC4 encryption), not endpoint telemetry, so EDR is irrelevant to it. The cost is detection by the DC or SIEM team, which the purple-team clause covers. This is the cheapest path you have.
Path B - svc_sql on SQL01. The value is entirely in what SQL01 touches: linked servers, SQL Agent job steps running as a privileged Windows account, credentials stored in job definitions, or a service account with local admin elsewhere. Investigate the target before spending effort on the pivot; being sysadmin on an isolated database server is a much smaller result than it sounds.
Path C - svc_backup's GenericAll over OU=Workstations. This is the shortest route to broad control. GenericAll allows writing msDS-AllowedToActOnBehalfOfOtherIdentity on any computer in the OU (resource-based constrained delegation) or resetting computer account passwords. RBCD requires a controlled account with an SPN to impersonate - which the Kerberoast already gave you. Pursue this first after confirming the ACLs with a fresh, low-noise LDAP query rather than a full collector run.
Not a path: the blocked collector. That is a detection result, not an attack.
Order of execution: Path C using existing credentials and LDAP-native queries, Path B in parallel as read-only SQL reconnaissance, Path A as already-banked leverage. Never LSASS - the ROE forbids it and the ACL route does not need it.
2. Your collector was blocked by EDR within 90 seconds. What do you do next, and what does the block become in the report?
Read the worked answer
Honour the ROE immediately. Phone the SOC, state the tool, the host, the timestamp, and what fired, and confirm whether testing continues. The clause exists so the client is not chasing a ghost; skipping it is the fastest way to lose the engagement.
Then treat the block as a result. It demonstrates that the endpoint control detects and prevents that behaviour, and that the SOC responds. Document the alert name, the policy that fired, the time from execution to block, and whether the SOC contacted anyone. A validated, working control is as valuable to the client as an attack path, and it belongs in the report under defensive effectiveness rather than as a failure of the test.
Then route around the endpoint, not through it. The productive alternatives need no endpoint tooling at all: LDAP and ACL abuse for the delegation path, Kerberos ticket manipulation from the Linux attack host, and the client's own administrative tooling where its use is permitted. This is not evasion - it is choosing techniques that stay inside the authorized envelope.
Explicitly refuse: unloading or reconfiguring the agent, tampering with its policy, obfuscating payloads to slip past detection, or retrying the same blocked action repeatedly to see if it sticks. Those are out of scope and, in a production environment, reckless. If the client wants a genuine EDR-evasion exercise, propose a separate scoped test with exclusions, an abort criterion, and the vendor's cooperation.
3. The remediation owner says the 90-day rotation already handles the service-account risk. Evaluate that claim and state what would actually close it.
Read the worked answer
Rotation does not close it, for three reasons.
The cracking is offline. Once the TGS is captured, the attacker works at leisure; a new password every 90 days only resets the clock. The current password is already known and valid for up to 90 days. Rotation is predictable. The cracked password follows the company's 2019 naming pattern, so the next one is a guess, not a secret. Rotation leaves the enablers intact. The SPN, the sysadmin rights, and the RC4 ticket encryption are the actual risk, and none of them change when the password does.
What closes it:
- Migrate the workload to a group Managed Service Account: a 240-character machine-managed password rotated automatically, not crackable in any practical timeframe.
- Remove the SPN if the service does not need Kerberos authentication, which removes the roastable target entirely.
- Reduce svc_sql from sysadmin on SQL01 to the least privilege the application requires.
- Set msDS-SupportedEncryptionTypes to AES-only so issued tickets are far more expensive to crack.
- Highest value of all: remove the account from any control over privileged resources, so a compromise is not a path to domain admin.
Also flag likely credential reuse across other accounts without testing it by spraying - the lockout policy could cause an outage, and spraying is outside the ROE. Record the residual risk explicitly: a rotated human-chosen password on a privileged service identity is not equivalent to a gMSA.