OSEP study materials
OSEP study resources

Relay Target Selection When ESC8 and SMB Signing Disagree

OSEP · Put your knowledge to work in context.

All case studies

Relay Target Selection When ESC8 and SMB Signing Disagree

You have a foothold on workstation WS-042 as a low-privileged domain user. SMB signing is disabled on member servers FS01 and FS02, but required on all domain controllers. LDAP signing is not enforced on DC01. The domain has an ADCS enterprise CA; the /certsrv web enrollment endpoint is reachable over HTTP, and EPA is not enforced on it. The print spooler service is running on DC01, and MS-EFSRPC is patched. You need Domain Admin, and the client scope allows coercion but not destructive actions. Blue team monitors for new computer accounts and unusual LDAP writes.

1. Choose between SMB relay to FS01, LDAP relay to DC01, and HTTP relay to the ADCS endpoint. Justify with preconditions and expected privilege.

Read the worked answer

Choice: coerce DC01 via the print spooler (PrinterBug) and relay the machine account's NTLM to the ADCS /certsrv HTTP endpoint (ESC8), then use the issued certificate for PKINIT.

Reasoning:

  • SMB relay to FS01 requires SMB signing to be off (it is), but the relayed identity would be a machine account or user you can coerce. The result is local admin on FS01 at best, not Domain Admin. It is a useful stepping stone, not the objective.
  • LDAP relay to DC01 is possible because LDAP signing is not enforced, but you need a relayed identity with rights to write the objects you care about. Coercing DC01 gives you DC01$, which can write to its own object, but turning that into DA usually requires RBCD or a similar delegation abuse, which is more complex and creates LDAP writes the blue team monitors.
  • HTTP relay to ADCS (ESC8) is the direct path: DC01 authenticates to your relay via the spooler, you forward the NTLM authentication to the CA web enrollment endpoint, and the CA issues a certificate for DC01$ because the machine account is a valid enrollee. With that certificate you request a TGT via PKINIT as DC01$ and perform a DCSync, which is Domain Admin-equivalent.

Preconditions to verify: spooler is reachable and running on DC01; MS-EFSRPC is patched, so use PrinterBug rather than PetitPotam; the CA template allows machine enrollment and client authentication; /certsrv is reachable from your relay host and EPA is off. The expected privilege is direct DA-equivalent, which is why this is the best use of the coercion.

2. What checks must you perform before firing the coercion to avoid breaking production?

Read the worked answer

Checks, in order:

  1. Confirm the spooler path is alive with a benign RPC query against DC01. Do not coerce repeatedly; one authentication is enough and repeated spooler calls can fill logs or destabilize the print service.
  2. Validate ESC8 with a test machine account you control. Relay your own test host's NTLM to /certsrv and confirm the CA issues a certificate that can be used for PKINIT. This proves template permissions and EPA state without touching DC01.
  3. Confirm the CA endpoint from the relay host and check whether the CA is the issuing CA for the template. A certificate from the wrong CA or a template without client authentication will not give a usable TGT.
  4. Check the time window and DC role. Coercing a DC that is mid-backup or handling replication pressure is more disruptive; use a short, single authentication during a quiet period.
  5. Confirm you can reach a DC for PKINIT with the issued certificate and that the certificate maps to DC01$.

The judgement is to prove the full chain with a test account before coercing a production DC. Coercion is allowed but not destructive, so a single spooler authentication and a controlled relay are acceptable; a failed blind attempt against DC01 is not.

3. If EPA is enforced on /certsrv, what is your next relay path?

Read the worked answer

If EPA is enforced, NTLM relay to the ADCS HTTP endpoint fails because the relayed authentication is not bound to the TLS channel. Do not keep retrying; it will only generate failed authentication events.

Next options, in order of preference:

  • Relay to LDAP on DC01 if LDAP signing remains unenforced. Coerce a machine account you can leverage and use the relayed authentication to create or modify an object you control, such as setting msDS-AllowedToActOnBehalfOfOtherIdentity on a computer you have write access to, then perform RBCD. This avoids the ADCS endpoint entirely. The tradeoff is that LDAP writes are monitored and RBCD requires an account with an SPN.
  • Relay to SMB on FS01 for local admin, then use that host as a foothold to hunt for a DA session or service account. This is slower and does not directly give DA, but it stays within the allowed coercion and avoids the blocked ESC8 path.
  • Look for another ADCS endpoint that is not EPA-protected, such as a different CA web enrollment server or the DCOM/RPC enrollment interface, if it exists in scope.

The judgement is to switch relay protocols rather than abandon the coercion. The machine account authentication from DC01 is still valuable; the question is which service will accept it. If LDAP signing is later enforced as well, the relay path collapses and you should pivot to credential access on FS01 instead.