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

5 comments:

  1. Hey, very cool, thanks for sharing this!

    ReplyDelete
  2. Awesome! netsh is very useful and in new OS version have new cool features like this. Thank you for the trick!

    ReplyDelete
  3. I found the NETSH and IEXPRESS tricks both useful. Thanks.

    ReplyDelete
  4. Great, thank you for sharing Chris.
    Ekin

    ReplyDelete