The SYSVOL Script With Server Local Admin
You have valid credentials for CORP\helpdesk1, a low-privileged domain user, after a single password-spray attempt against the VPN portal. You have local administrator on WS-042, helpdesk1's workstation, but no domain admin. While enumerating SYSVOL you find the script map-drives.ps1, readable by Authenticated Users. The script contains a hardcoded credential for CORP\svc_deploy. You verify the credential once against FS01 over SMB. Group Policy shows svc_deploy is a member of the local Administrators group on 11 of 14 member servers; the three domain controllers and three Tier 0 servers are excluded. LAPS is deployed on workstations only. EDR generates a high-severity alert on LSASS access, and the SOC reviews alerts within 15 minutes. You have 75 minutes remaining. The engagement scope permits privilege escalation but not destructive actions or domain controller modification.
1. What is the most defensible next action with svc_deploy, and how do you confirm local admin on a target without sweeping the estate?
Read the worked answer
With 75 minutes and a 15-minute SOC review, I would pick one target, not sweep 11 servers. The best target is a member server likely to hold Tier 1 admin sessions or credential material, such as a backup, file, or management server, but not a DC or Tier 0 host. I would authenticate once with svc_deploy to that host over SMB or WinRM, then confirm local admin membership with a single query such as net localgroup administrators or a remote registry read if the tooling allows. I would not run a port scan of the server VLAN, because that is noisy and unnecessary. If the account is local admin, I would look for readable configuration files, scripts, and scheduled-task definitions before touching LSASS. The key judgement is blast radius: svc_deploy is powerful on 11 servers, but using it everywhere creates 11 alerts and may burn the engagement. One controlled host gives a defensible pivot and preserves time for credential access.
2. The obvious path is to dump LSASS on a server where a domain admin is logged in. Why might you reject that, and what alternative credential-access path do you prioritize?
Read the worked answer
LSASS dumping is the obvious move and the wrong first move here. EDR alerts on LSASS access at high severity, the SOC reviews within 15 minutes, and Credential Guard may be present on servers even if not confirmed. A dump would also create a clear evidence trail and could force incident response before I get value. Instead, I would use local admin to read credential-bearing artifacts that do not require process memory access: unattend.xml, PowerShell history, service account passwords in scripts, scheduled-task XML with stored secrets, IIS web.config, and backup job configurations. I would also check whether svc_deploy can read SYSVOL or NETLOGON for more scripts. If I need a domain admin credential, a better path may be to find where Tier 1 admins log on and collect from a lower-detection source, but that is a separate decision. The report should note that LSASS access was intentionally avoided to reduce detection, not because it was impossible.
3. How do you report the SYSVOL credential finding and what immediate remediation do you recommend?
Read the worked answer
The SYSVOL script is a critical finding: a hardcoded credential readable by Authenticated Users, and that account is local admin on 11 of 14 member servers. The blast radius is server tier, not just one workstation. I would report the exact file, the readable ACL, the account name, the 11 servers from GPO, and the one successful authentication used to validate. Remediation order: rotate svc_deploy immediately; remove the credential from SYSVOL; replace it with a gMSA or a managed secret; audit local Administrators membership and remove standing local admin where possible; restrict SYSVOL script ACLs; and review logs for use of the account. Longer term: tiered administration, LAPS on servers, and monitoring for credential use from workstations. Because the engagement is time-boxed, I would not change the script myself. The report should distinguish the vulnerability from the exploitation step so the client can fix the cause, not just the symptom.