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