Kerberoasting Versus a Fragile Legacy Server
You have a foothold as low-privileged CORP\j.smith on a workstation in the CORP.LOCAL domain. BloodHound shows a path to Domain Admin through svc_backup, a Kerberoastable account with SPN MSSQLSvc/sql01.corp.local. A TGS request is stealthy, and the hash cracks offline in about four minutes to 'Backup2024!'. Separately, FILE01 is a Server 2008 R2 host with confirmed MS17-010, 12 TB of archived patient records, 800 days of uptime, and no current backups verified. The client says FILE01 is 'business critical; do not reboot.' BloodHound also shows svc_backup has WriteDACL on the domain object. You have six hours left, and the sponsor wants 'Domain Admin with minimal disruption.' The SOC monitors for service creation and new admin logons but has not alerted on Kerberos service ticket requests.
1. Which path to Domain Admin do you choose and why?
Read the worked answer
I choose Kerberoasting, not MS17-010. The decision is risk versus reliability.
- Kerberoasting is non-destructive. A TGS request does not change the target, does not reboot it, and cracking happens offline. The SOC has not alerted on service ticket requests, and the hash cracks in four minutes.
- MS17-010 on FILE01 is high-risk. The host is unpatched Server 2008 R2 with 800 days of uptime, 12 TB of patient records, no verified backups, and a client instruction not to reboot. Known exploit modules can bugcheck that platform; even a successful exploit could trigger a reboot or data loss.
- Time. The Kerberoast path is seconds to request, minutes to crack, and then ACL abuse. The exploit path adds payload delivery, AV/EDR uncertainty, and potential recovery time.
I would document FILE01 as a critical finding and validate MS17-010 with a non-exploiting scanner, not by running an exploit.
2. BloodHound shows svc_backup has WriteDACL on the domain object. Outline the least disruptive escalation to Domain Admin.
Read the worked answer
After cracking svc_backup, authenticate as that account and use the WriteDACL to grant DCSync rights to a controlled account or to svc_backup itself. With PowerView, that is Add-DomainObjectAcl -Rights DCSync. Then run secretsdump.py -just-dc-user krbtgt and -just-dc-user Administrator to obtain the hashes needed for proof. This avoids service creation on a DC, avoids new admin logons to FILE01, and avoids a reboot.
I would request only the krbtgt and Administrator hashes, not the full domain dump, to minimize data handling. Afterward I would remove the ACE and document the change with timestamps. DCSync generates 4662 events, so I would tell the client what to look for. A golden ticket is unnecessary unless the client explicitly asks for persistence proof; creating one adds risk without improving the finding.
3. The client insists on running EternalBlue on FILE01 to 'prove' it is vulnerable. How do you handle it?
Read the worked answer
I would recommend against exploitation and offer a non-exploiting validation: the Metasploit auxiliary/scanner/smb/smb_ms17_010 check, an SMB dialect probe, or a patch/config review. These show exposure without triggering the bugcheck risk. I would explain that a crash on an 800-day-uptime Server 2008 R2 host with 12 TB of records and unverified backups could cause data loss and outage, and that 'proof' does not require exploitation when the scanner result plus patch level is sufficient.
If the client still insists, I would require written authorization from the authorized signer, a maintenance window, verified backups, a rollback plan, and an explicit risk acceptance. I would still advise no. If they accept, I would run the least disruptive module, log everything, and stop at the first sign of instability. The decision and the client's acceptance go in the report.