I85PREP
⌘ K
OSCP study materials
OSCP study resources

SeImpersonate Blocked by AV: Choosing the Second-Best Privilege Path

OSCP · Put your knowledge to work in context.

All case studies

SeImpersonate Blocked by AV: Choosing the Second-Best Privilege Path

You land on WS01 as CORP\svc_backup through a scheduled task that stored its password in a readable XML file. The host is Windows Server 2019 build 17763, domain-joined, Defender real-time protection on, and it has no outbound internet. whoami /priv shows SeImpersonatePrivilege, SeBackupPrivilege and SeRestorePrivilege enabled; SeDebugPrivilege and SeTakeOwnershipPrivilege are absent. You have a Linux attack box with internet access but no compiler toolchain on WS01. When you transfer PrintSpoofer.exe and JuicyPotato.exe, Defender quarantines both within seconds of the write completing. The account is a local member of the Backup Operators group and nothing else.

1. You have two viable primitives. Choose one, and explain the operational reason for the choice rather than the technical one.

Read the worked answer

Choose SeBackupPrivilege, because it needs no attacker binary on disk at all.

SeImpersonate is the more elegant primitive - PrintSpoofer or GodPotato would take SYSTEM in one command on this build - but every known implementation is a file that must land on a host where Defender is quarantining exactly those files. Reflective or in-memory .NET loading is the theoretical answer, yet it still requires a loader binary or an existing .NET execution path, plus trial-and-error you cannot do offline. The operational constraint, not the vulnerability, decides this.

SeBackupPrivilege's advantage is that it is abused entirely with signed, already-present Microsoft utilities. Two routes:

  • reg save hklm\sam C:\temp\sam, same for system and security, then exfiltrate and run secretsdump offline. The privilege bypasses the ACL on the hive keys.
  • diskshadow script to expose a volume shadow copy, then robocopy /b to copy files whose ACLs you cannot read - including C:\Windows\System32\config\ and, more interestingly, any backup archives or credential files the backup service touched.

Both use binaries Defender will not touch. You exfiltrate the results over the same channel you used to get in and do the parsing on your Linux box.

2. You dump the local SAM and LSA secrets. What do you do with the output, and what is the realistic ceiling of this machine?

Read the worked answer

Parse offline, then triage by usefulness, not by novelty.

  1. Local Administrator NTLM: pass-the-hash back to WS01 to confirm it works (you may need it later for a session with different privileges), then test the same hash against other hosts. Local admin password reuse across a build image is common and turns one workstation into a spray target for the whole /24. Watch the error: STATUS_LOGON_FAILURE means no reuse; an access-denied on a share after successful auth means the account lacks rights.
  2. LSA secrets: these contain service account passwords in plaintext for any service running as a named account, plus the machine account password and cached domain credentials (mscash/DCC2) if the host cached logons. A plaintext service account password is a domain credential - that is your pivot into AD, far more valuable than the local hash.
  3. Cached domain credentials: DCC2 is slow to crack; treat it as a last resort, not a plan.

The ceiling of WS01 alone is one machine. Its real value is whatever domain credential it was trusted with: the scheduled task password you already have, any service account in LSA secrets, and any reusable admin hash. Report the local admin finding and the credential exposure separately - they are different risks and only one of them leads to the domain.