Jack Crook DFIR Challenge - Part 2 - ENG-USTXHOU-148

This is the second part of my breakdown of the @jackcr DFIR challenge.  You can find part one here.

If you remember from the pcap analysis, the C2 client at 58.64.132.141 was communicating with 172.16.150.20 and after decoding the Gh0st traffic we were able to discern that the localhost name was ENG-USTXHOU-148, so that's where we will pick up.

Loading the memdump.bin file into Volatility's imageinfo module confirms what we saw in the Gh0st data; this machine is running Windows XP Service Pack 3.

vol.py -f memdump.bin imageinfo

Taking a look at the output of connscan, you can see the connection to the C2 client at 58.64.132.141.  The process using that connection has a PID of 1024.

vol.py -f memdump.bin --profile=WinXPSP3x86 connscan

Output of pstree show the process with the PID 1024 is svchost.exe  so obviously we've got some trouble here.  You also see that svchost.exe is the parent process of wc.exe which we saw in part one.

vol.py -f memdump.bin --profile=WinXPSP3x86 pstree

Let's dig into svchost a little more by running the dlllist module against it.  We see there is an abnormal dll named 6to4ex.dll listed

vol.py -f memdump.bin --profile=WinXPSP3x86 dlllist -p 1024

You can dump the suspect file out using the dlldump module.

vol.py -f memdump.bin --profile=WinXPSP3x86 dlldump -p 1024 --dump-dir ./dumpout -r 6to4ex

We'll then get the md5 of the file...

...and see if VirusTotal has seen this before.

Apparently so!  Ok, so we've found our backdoor.  Running strings against the file also reveals a couple of instances of "Gh0st" to further confirm our suspicions.

So how did this machine become compromised in the first place?  I ran the entire memdump.bin file through strings and then grepped that output to look for instances of "58.64.132.141".  Adding the -C flag to your grep command will give you x lines of context before and after any occurrences detected.  There are several hits, but the most interesting one is listed below.

strings memdump.bin | grep -C 30 58.64.132.141

What you see above is the phish that the users callb, amirs, and wrightd received.  The sender address, isd@petro-markets.info, is designed to look familiar to the end users.  At the end of the email we see the trojan, Symantec-1.43-1.exe.

We were also given a timeline file and we can see both the execution of the trojan and creation of 6to4ex.dll A little further on, we see the same activity that we saw in the pcap file.

Now we have lots of indicators to go on.  I'll be making another post soon about using this information to create an IOC signature with Mandiant's IOC editor.

Jack Crook DFIR Challenge - PCAP

I've been working on a DFIR challenge put out there by @jackcr over at his HandlerDiaries site and thought I would make a few posts about it for my reference more than anything else.

The challenge consists of a pcap file and the memory dumps of four potentially infected machines and the objectives are as follows:

1. Determine which machines are compromised
2. Identify the who, what, when , where, and how
3. Determine whether or not the incident is contained

The initial breadcrumb you are given to work from is:

An ids alert initially triggered on ENG-USTXHOU-148 for an established port 80 connection to a known bad ip address.

Ok, so we have an established session over port 80 to a known bad.  Let's open up the pcap and take a look.

We see the three-way handshake and then the forth packet destined to port 80 on the known bad.  Looking at the payload, it's obvious that this isn't normal HTTP traffic.  Looking at other packets you notice the same header in the payload of the packet: Gh0st.  A quick google search confirms that this repeated header is a tell-tale sign of the Gh0st RAT trojan.  Michael Spohn has a great breakdown of Ghost RAT at https://www.mcafee.com/us/resources/white-papers/foundstone/wp-know-your-digital-enemy.pdf 

Essentially, the data used in the communication between the C2 server and client is broken out like so:

1. First 5 bytes contain the header Gh0st

2. Next 4 bytes contains the length of the payload in bytes (payload is compressed in zlib format)

3. Next 4 bytes contains the length of the uncompressed payload in bytes 

4. The actual payload (zlib compressed)

Now that we know how the data is structured, how do we pull all the data out of the pcap and uncompress it?  I'm sure there are numerous ways to write scripts that will do this.  As a matter of fact I had begun digging into using scapy or Impacket to do just that when I hit the Google lottery.  I found a program written by the folks over that MITRE called Chopshop.  Chopshop is a protocol decoder framework, which basically means, they do all the heavy lifting of getting to the actual data, you just write the module to decode it.  Ever better for me though is that they had already written a Gh0st RAT protocol decoder

.

The command above runs the pcap through the chopshot gh0st_decode module and dumps the output to a text file.

You can see in the top line where the TOKEN: LOGIN command was issued from the C2 client to eng-ustxhou-148.  Let's see what else we can see.   Below are my rough notes.

DROPS
****************************************************
c:\WINDOWS\webui
c:\WINDOWS\ps.exe 381816
c:\WINDOWS\webui\gs.exe 303104
c:\WINDOWS\webui\ra.exe 403968
c:\WINDOWS\webui\sl.exe 20480
c:\WINDOWS\webui\wc.exe
c:\WINDOWS\webui\netuse.dll
 netuse.dll
  ipconfig /all
  net view
  net localgroup administrators
  net sesssions
  net share
  net start
  sl.ese -bht 445,80,443,21,1433 172.16.150.1-254
  gs -a
  
C:\WINDOWS\webui\system5.bat

RUNS
******************************************************
ScanLine 1.01 Foundstone
sl.exe
 -b Banner Grab
 -h hide systems with no open ports
 -t scan specified TCP ports

gs -a

WCE v1.3beta Windows Credential Editor
wc.exe -l ====> List logon sessions and NTLM credentials
wc.exe -w ====> Dump cleartext passwords stored by the digest authentication package

ps.exe \\172.16.50.10 -u petro1-market\callb -p Mar1ners@4655 - accepteula cmd /c ipconfig ====> PSEXEC to run ipconfig on 172.16.50.10(DC-USTXHOU) FAILED
ps.exe \\172.16.223.47 -u petro1-market\callb -p Mar1ners@4655 - accepteula cmd /c ipconfig ====> PSEXEC to run ipconfig on 172.16.223.47(IIS-SARIYADH) FAILED

wc.exe -s sysbackup:current:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyyyyyyyyyyyyyyy  =====> Changes NTLM credentials of current logon session

ps.exe \\172.16.50.10 -u sysbackup -p T1g3rsL10n5 - accepteula cmd /c ipconfig ====> PSEXEC to run ipconfig on 172.16.50.10(DC-USTXHOU) FAILED
ps.exe \\172.16.223.47 -u sysbackup -p T1g3rsL10n5 - accepteula cmd /c ipconfig ====> PSEXEC to run ipconfig on 172.16.223.47(IIS-SARIYADH) FAILED - Error copying ipconfig.exe to remote system

net use z:\\172.16.223.47\z  ====> Share named z.  Previously compromised? Check for webui directory on IIS-SARIYADH
copy z:\system.dll . ====> Copies system.dll from 172.16.223.47 into c:\Windows\webui\
copy z:\svchost.dll . ====> Copies svchost.dll from 172.16.223.47 into c:\Windows\webui\
copy z:\https.dll . ====> Copies https.dll from 172.16.223.47 into c:\Windows\webui\
copy z:\netstat.dll . ====> Copies netstat.dll from 172.16.223.47 into c:\Windows\webui\


net time ===> Current time at \\DC-USTXHOU is 11/26/2012 7:25 PM
system5.bat ==> at 7:30pm today run: wc.exe -e -o h.out  ===>  List login sessions NTLM credentials infefinitely and write to file

net start ==> List started services
  
  
DOWNLOADED to C2 Client
*********************************************************
netuse.dll
system.dll  -> From IIS-SARIYADH-03
svchost.dll  -> From IIS-SARIYADH-03
https.dll  -> From IIS-SARIYADH-03
netstat.dll  -> From IIS-SARIYADH-03

PINGS
*********************************************************
DC-USTXHOU - dc-ustxhou.petro-market.org - 172.16.150.10
IIS-SARIYADH-03 - IIS-SARIYADH-03.petro.market.org - 172.16.223.47

Looks like mostly information gathering.  Things that I want to look for in the memory dumps are the wc.exe process and relevant output files, and the attacker was able to connect to a "z" share on IIS-SARIYADH that leads me to believe that it was compromised previously.  Need to do some more digging...

Small business security on the rise

"...small businesses believe they are immune to attacks targeted at them. However, money stolen from a small business is as easy to spend as money stolen from a large business. And while small businesses may assume that they have nothing a targeted attacker would want to steal, they forget that they retain customer information, create intellectual property, and keep money in the bank. While it can be argued that the rewards of attacking a small business are less than what can be gained from a large enterprise, this is more than compensated by the fact that many small companies are typically less careful in their cyberdefenses. Criminal activity is often driven by crimes of opportunity. With cybercrimes, that opportunity appears to be with small businesses."

- Page 4, Symantec Internet Security Threat Report 2013

Just like I've always said, just because you don't have as much gold in the vault, doesn't mean you can leave it wide open.

Basic malware analysis with Cuckoo Sandbox

Being short-handed at work, most of my time is spent putting out one fire or another.  When we have a machine get compromised we rebuild it and get it back into service. Having time to spend analyzing the malware is a luxury that, more times than not, we just don't have.  I came across a slidedeck about Cuckoo Sandbox that was put together by Cory Kennedy for a talk last year that looked interesting and if implemented just might give me the ability to do some basic analysis.

What is Cuckoo Sandbox?  From their website:

In three words, Cuckoo Sandbox is a malware analysis system.

What does that mean? It simply means that you can throw any suspicious file at it and in a matter of seconds Cuckoo will provide you back some detailed results outlining what such file did when executed inside an isolated environment.

A typical scenario that I've been using it is like this.

1. Computer is infected with some kind of malware
2. Image the PC and get it back into service.
3. Review the IDS logs and pcaps from Security Onion for the affected machine.
4. Extract the relevant executables, scripts, or URLS
5. Run them through Cuckoo to get more details that will assist in future detection/prevention


I've been seeing a lot of the Windows 7 Security Cleaner malware the last couple of weeks.  Due to the literal in your face nature of it, I normally get notified pretty quickly after the user clicks "Run".  (Why VIPRE missed it and the users continue to click run after repeated training are part of life's great mystery.)  Since I'm collecting full pcap data from Security Onion and I have a narrow window in which the infection most probably occurred, it is easier to find and extract the executable by pivoting to NetworkMiner from sguil than to crawl through the image.  I can then push the executable, security_cleaner.exe, up to Cuckoo for some basic analysis.

To get Cuckoo up and running make sure to check out the official documentation.  I found a really great write-up on how to get it going over at Santiago Bassett's blog. He lists step by step how to install and configure all the parts and pieces.

So let's fire up Cuckoo.  While the image below doesn't show it, I found that like to use the debug option (-d) for a better view on what's going on.

 #sudo python cuckoo.py -d

Then in a new terminal window, feed in the malware sample.  In this instance a Black Hole Exploit Kit sample.

#sudo python ./utils/submit.py privacy.exe

The Cuckoo server will accept the sample, spin up the VM that you designated, copy over the sample, run it, analyze the results, and generate a report.  AUTOMAGICALLY!  All kidding aside, this is very cool and very useful.

The report includes all sorts of useful information like DNS requests made, processes started, files created, registry changes.  It submits the sample to VirusTotal for analysis and includes those results too.

Another of the neat features is that it will take periodic screenshots of the VM and include them in the report.

Although I've just started to scratch the surface, Cuckoo Sandbox has already become a valuable tool in the toolbox.

Security Onion is a boon for small business

Let me be direct.  Doug Burks' Security Onion distribution is nothing short of amazing.

Working for a smaller organization inevitably means you end up wearing numerous hats and time to focus on any one project, much less one that management doesn't see any direct benefit from (i.e. network monitoring), can be scarce.  

In the past, I've had various installs of Snort, OSSEC, and OCS Inventory setup to monitor the network.  But inevitably, these projects got pushed to the back-burner, became outdated, and eventually got mothballed.

A year or so ago I tried Security Onion, but due to some memory issues, was never really able to make it sing.  That all changed when I recently got time to try again with Security Onion 12.04.  I'm still having to use it on some older hardware, but it is working wonderfully.

You will find tons of information on the Security Onion website, but in summary, it is a customized Linux distro built for network security monitoring.  There are tons of tools built in, but so far the ones I use the most are:

• Snort - The de facto standard IDS
• Squil - Swiss army knife for digging into your Snort and OSSEC alerts
• Snorby - Good looking web based dashboard for Snort alerts
• Bro - Logs HTTP session data
• NetworkMiner - Great way to extract files from logged pcaps
• daemonlogger - Logs full packet capture data

Small business security is notoriously poor due to small budgets, low staffing, and lack of knowledge.  It should come as no surprise that businesses under 250 employees are getting battered.  While I may have the skills and patience to get some of these tools put in place, the time to do so is ever fleeting.

That's why I think the Security Onion project is so good for small business.  In under 30 minutes, the typical Windows sysadmin can "Next,Next, Finish" their way to a very powerful NSM.

Check out Doug's talk at last years Derbycon for more details.

No WANG in my NOOP

A fresh IDS install is always noisy, especially on a network with lots of Windows hosts.  On of the main alerts I've seen on networks with multiple sites is: GPL SHELLCODE x86 inc ebx NOOP.    Should I be alarmed?  Let's see.

Let's take a look at the rule that tripped this signature:

alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"GPL SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; fast_pattern:only; classtype:shellcode-detect; sid:2101390; rev:7;)

After a little analysis you notice that the vast majority of the alert traffic is ICMP between domain controllers, but the packets are relatively large at around 2000 bytes.

Ok, so let's dig a little further. if you check out the payload, you'll notice the string that triggered the rule.

But what's up that WANG2.....JFIF at the top. Maybe a dubious JPEG attempting to spread?  Not quite.

Pivoting from Sguil to NetworkMiner, you are able to extract the image and see that it's a simple logo from Microsoft.  Apparently, this type of traffic is used  in Slow Link Detection between clients and domain controllers when applying group policy. 

Ok, so we've established that it's a false positive so let's tweak the rule a little by exempting traffic containing the string WANG2 in the payload like so.  I added the following to my local.rules file and disabled the original rule.

alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"GPL SHELLCODE x86 inc ebx NOOP"; content:!"WANG2"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; fast_pattern:only; classtype:shellcode-detect; sid:90000000; rev:1;)