DavRelayUp
A quick and dirty port of KrbRelayUp with modifications to allow for NTLM relay from webdav to LDAP in order to streamline the abuse of the following attack primitive:
- (Optional) New machine account creation (New-MachineAccount)
- Force start the WebClient service
- Start webdav relay server (GoRelayServer - a golang DLL that is embeded in DavRelayUp using Costura.Fody)
- Local machine account auth coercion (SharpSystemTriggers)
- NTLM relay to LDAP
- Add RBCD privs and obtain privileged ST to local machine (Rubeus)
- Using said ST to authenticate to local Service Manager and create a new service as NT/SYSTEM. (SCMUACBypass)
This is essentially a universal no-fix local privilege escalation in domain-joined windows workstations where LDAP signing is not enforced (the default settings).
Usage
DavRelayUp - Relaying you to SYSTEM, again...
Usage: DavRelayUp.exe [-c] [-cn COMPUTERNAME] [-cp PASSWORD | -ch NTHASH]
RBCD Options:
-c (--CreateNewComputerAccount) Create new computer account for RBCD. Will use the current authenticated user.
-cn (--ComputerName) Name of attacker owned computer account for RBCD. (default=DAVRELAYUP$)
-cp (--ComputerPassword) Password of computer account for RBCD. (default=RANDOM [if -c is enabled])
-ch (--ComputerPasswordHash) Password NT hash of computer account for RBCD. (either -cp or -ch must be specified)
-i (--Impersonate) User to impersonate. Should be a local administrator in the target computer. (default=Administrator)
KrbSCM Options:
-s (--ServiceName) Name of the service to be created. (default=KrbSCM)
-sc (--ServiceCommand) Service command [binPath]. (default = spawn cmd.exe as SYSTEM)
General Options:
-p (--Port) Port for WebDAV Server (default=55555)
-d (--Domain) FQDN of domain. (Optional)
-dc (--DomainController) FQDN of domain controller. (Optional)
-ssl Use LDAP over SSL. (Optional)
-n Use CreateNetOnly (needs to be on disk) instead of PTT when importing ST (Optional)
-v (--Verbose) Show verbose output. (Optional)
-h (--Help) Show help
Known Issues
If DavRelayUp gets stuck at one of these stages - try using a different port by specifying [-p] flag
DavRelayUp - Relaying you to SYSTEM, again...
[+] WebClient Service started successfully
[+] Starting Relay Server on Port 55555
[+] Coercing System Authentication
DavRelayUp - Relaying you to SYSTEM, again...
[+] WebClient Service started successfully
[+] Starting Relay Server on Port 55555
[+] Coercing System Authentication
[+] WebDAV Request: No Authorization header
[+] WebDAV Response: Sending 401 Unauthorized with "WWW-Authenticate: NTLM" header
Examples
DavRelayUp.Demo.mp4
Building
- Build GoRelayServer (already built and ready in this repository but in case you want to do it yourself)
This will build the GoRelayServer DLL and save it in "DavRelayUp\DavRelayUp\Costura64\GoRelayServer.dll" -> This is the folder from which Costura.Fody will embed it in the final DavRelayUp.exe executable.
PS C:\Tools\DavRelayUp> cd GoRelayServer PS C:\Tools\DavRelayUp\GoRelayServer> go build --buildmode=c-shared -ldflags="-s -w" -o "../DavRelayUp/Costura64/GoRelayServer.dll" main.go
- Open KrbRelayUp.sln in Visual Studio 2019
- Make sure that Solution Configuration is set to Release and hit build (CTRL+SHIFT+B)
TODO
- Add ShadowCred attack as a RELAY method
- Add U2U support to allow for the attack without the need for a machine account
Mitigation & Detection
- Enforce LDAP Signing and LDAP Channel Binding to mitigate the relay of the machine account auth to LDAP. This can be configured via the "Domain Controller: LDAP server signing requirements" GPO. (Thank you Will Dormann for your tweet on this matter)
- Make the attack requirements harder to obtain by setting the MS-DS-Machine-Account-Quota attribute in AD to 0, thus removing the ability of any user to add a new machine account to the domain. This is a dangerous default setting in AD - make sure you change it.
- Setting the flag "Account is sensitive and cannot be delegated" on all admin accounts (or put them in protected users) would make it so there is no account with the privileges required that can be delegated in order to complete the attack path. (Thanks to Christoph Falta for this tweet)
- Resources for possible monitoring and detection rules:
- https://github.com/tsale/Sigma_rules/blob/main/windows_exploitation/KrbRelayUp.yml (@Kostastsale)
- https://twitter.com/SBousseaden/status/1518976397364056071 (@SBousseaden). Mainly the rule about authentication to Service Manager via Kerberos from 127.0.0.1, Great Work!.
- https://www.linkedin.com/posts/john-dwyer-xforce_threathunting-threatdetection-blueteam-activity-6924739962131140608-py45/ (John Dwyer @TactiKoolSec)
Acknowledgements
- James Forshaw for figuring out how to use Kerberos Service Tickets for LOCAL authentication to Service Manager which was the missing piece of the puzzle in order to make this attack primitive local only (before that, we had to export the ST to a remote machine in order to use it and gain privileged access to our target machine).
- Kevin Robertson for his New-MachineAccount functionality which was used in this project.
- Cube0x0 for his SharpSystemTriggers functionality (specifically SharpEfsTrigger) which was used in this project.
- Elad Shamir for his research on RBCD - Wagging the Dog
- Will Schroeder and everyone who contributed to Rubeus which we all know and love. Basically all the RBCD-S4U functionality was taken from there.
- Orange-Cyberdefense for their work on GOAD, the Active Directory research lab I am using which you can see in the demo video and images.
- Shantanu Khandelwal for his cool blog post on Red Team: How to embed Golang tools in C#
- GoRelayServer was built upon the work done on go-ldap which I modified to allow for the webdav-to-ldap NTLM relay. Also thanks for Mariusz Banach for SharpWebServer which I used to learn how webdav NTLM authentication works and implemented it as the server listener in GoRelayServer.