Red Teaming Made Easy with Exchange Privilege Escalation and PowerPriv

TL;DR: A new take on the recently released Exchange privilege escalation attack allowing for  remote usage without needing to drop files to disk, local admin rights, or knowing any passwords at all.  Any shell on a user account with a mailbox = domain admin.  I wrote a PowerShell implementation of PrivExchange that uses the credentials of the current user to authenticate to exchange.  Find it here: https://github.com/G0ldenGunSec/PowerPriv 

The Exchange attack that @_dirkjan released last week (https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin) provides an extremely quick path to full domain control on most networks, especially those on which we already have a device that we can run our tools on, such as during an internal network penetration test.  However, I saw a bit of a gap from the point of a more red-team focused attack scenario, in which we often wouldn’t have a box on the internal client network that we can run python scripts on (such as ntlmrelayx and PrivExchange) without either installing python libraries or compiling the scripts to binaries and dropping them to disk to run.  Additionally, we may not have a user's plaintext or NTLM hashes to run scripts with remotely via proxychains.   

Trying to find a more effective solution for this scenario, I wrote a PowerShell implementation of PrivExchange called PowerPriv that uses the credentials of the current user to authenticate to the Exchange server.  This gets around the problem of needing credentials, as we’ll now just use the already-compromised account to authenticate for us.  However, this was really only a first step as it still required that we relay to the domain controller through ntlmrelayx, meaning that we would still need a box on the network running Linux / need to install Python / etc.  To put the rest of the pieces together, I used a bunch of the great tunneling functionality that comes in Cobalt Strike to set up a relay for the inbound NTLM authentication request (via HTTP) from the Exchange server, through our compromised host system, to the Cobalt Strike server, and back out to the target domain controller (via LDAP).  At a high level, this is what we’re doing: 

 

So, in more depth, what are we actually doing here?  To begin, let’s get a ‘compromised’ system and check who the local admins are:

Cool, we’re running as ‘tim’, a user who is not currently an admin on this system, but that shouldn’t matter.  Next, let's get our forwarding set up using the 'socks' + 'rportfwd' commands in Cobalt Strike and the /etc/proxychains.conf file:

We’re doing a few things here, setting up a reverse port forward to send traffic from port 80 on the compromised system to port 80 on our attacker system, and then setting up a SOCKS proxy to forward traffic back out through the compromised system over port 36529 on our box (the specific port used doesn’t matter).  

Once we've configured these, we can use proxychains to forward traffic through our SOCKS proxy set up on port 36259.  To perform the relay, we'll run ntlmrelayx, forwarding traffic through proxychains in order to get it back to the target environment. 

After this is up and running, we are ready to kick off the attack.  I’m using the PowerShell implementation of PrivExchange that I wrote called PowerPriv to authenticate using Tim's credentials.  In this example, all we need are the IPs of the Exchange server and the system which we currently have a shell on, since our compromised system will be relaying the incoming request to our attack server:

After this, we sit back and wait a minute for the NTLM authentication request to come back from the remote Exchange server:

Looks like our attack succeeded. Let's see if Tim can now perform a dcsync and get another user’s NTLM hash, even though Tim is only a lowly domain user:

A resounding success!  All without ever needing to know what Tim’s password is, perform any poisoning attacks, or drop files onto his system.   As to why we’re using the Cobalt Strike dcsync module vs secretsdump – in this scenario we do not have a plaintext password or NTLM hash for Tim (or any user), which would be required if we want to run secretsdump from our box via proxychains.  If you do have credentials, you can definitely use whichever method you prefer.

A few gotchas from during this process:

Make sure to use an appropriate type of malleable profile for your beacon. Don’t try and be fancy and send data over URIs or parameters.  Due to the nature of the relayed authentication we need to be able to quickly get the authentication request and forward it back out.  I also completed all testing using an interactive beacon, a 5-minute sleep isn’t going to work for this one.

I was initially having issues getting the dcsync working when using an FQDN (vs. the netbios name) of my target domain.  This was likely due to how I configured my naming conventions on my local domain, but something to be aware of.

In this example, my Cobalt Strike teamserver was running on the same box as my Cobalt Strike operator console (I was not connecting to a remote team server).  If you have a remote team server, this is where you would need to set up your relay, as this is where the the reverse port fwd would be dumped out to. (May need further testing)

Notes and links:

@_Dirkjan’s blog which covers the actual Exchange priv esc bug that he found in greater depth: https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

Github Repo for PowerPriv: https://github.com/G0ldenGunSec/PowerPriv

Github Repo for ntlmrelayx: https://github.com/SecureAuthCorp/impacket

Cobalt Strike resources on port fwd’ing and SOCKS proxies: https://www.youtube.com/watch?v=bwq0ToNPCtg

https://blog.cobaltstrike.com/2016/06/01/howto-port-forwards-through-a-socks-proxy/ 

*This technique was demonstrated in the article with Cobalt Strike.  However, this same vector is possible using other agents that support port forwarding and proxying, such as Meterpreter.