Malware in a bottle
I came across this today whilst following up on a compromise; it seems to use a novel (for me) way of sneaking stuff past a network’s border controls. If anyone with better malware analysis sKillZ than me can shed any light, I’m all ears!
The sample in question is a second-stage download called install.48534.exe. Virustotal has this to say about it:
More interesting is what Anubis has to say:
For better or worse, my focus is on the sample’s network activity. Malware will almost always use the network to do things like receive commands or steal data, so it’s a good source of evidence. There’s a good bit of network activity here, and Anubis kindly lets us have it as a pcap. Let’s take a look.
There are four HTTP POSTs, each with a preceding DNS query. POSTs can be bad, because not all border defences inspect them. The user-agent in each case indicates that wget may have used, and they all seem to send what appears to be BASE64 encoded parameters. Decoding them yields little fruit; the level of obfuscation goes beyond plain BASE64. The first request is fundamentally different to the last three – speculating further, perhaps we’re looking at a hit on a C&C server followed by traces of the C&C server’s orders being carried out?
In any case, only the second POST returns a decent amount of data, which is a GIF according to Wireshark. File->Export->Objects->HTTP shows us a list of exportable objects, and we can save it off to disk.
And here it is, sanitised and converted to PNG:
Here’s where it gets interesting. The dimensions of the GIF are only 143×74, and yet it’s 266KB in size. That seems a little on the large size for an image so small. What’s bloating it out?
Wireshark is a cunning beast that can dissect not just network protocols, but certain filetypes too – GIF is one of them:
Now we can start to see where all the bulk is. Expanding the “Image” subtree shows 27 255-byte data blocks that comprise the image. After clicking around a bit more, we can see there’s a subtree titled “Extension: Comment” with many data blocks under it – here’s our anomaly.
So what is it? Well, we can start to extract it out by right-clicking on the “Extension: Comment” subtree and selecting “Export selected packet bytes”. Save it off to disk and open it up in a hex editor, because we’ve got some trimming to do.
The first thing we have to do is get rid of the first two bytes (0x21 and 0xfe) which denotes the presence of an Extension Introducer of type Comment Label. The next thing we have to do is remove all of the length indicators for each of the data blocks. Just like the image portion of a GIF file, the comment is split into a variable number of up-to-256-byte data blocks with the first byte denoting the block’s length. These length indicators are polluting our extract, and need to be removed by starting at byte zero and deleting that and every 256th byte plus the trailing 0x00. I wrote a quick C executable to do it, but I’m sure someone could knock up a little script to do the job.
Finally, we have our extracted file. I have no idea what it is or what it’s for! It could exploit a bug in some GIF parsing routine somewhere, but it looks a little large for shellcode (and don’t forget that this was downloaded by a second-stage download in the first place). It’s binary in nature, and has no discernible strings or magic bytes. If I had to guess I’d say it was an obfuscated executable of some kind, perhaps even the Hbz.exe that Anubis said got created and executed by our original sample? It certainly smells like a covert channel.
So, any ideas, anyone? Let me know if you want the pcap or the extracted comment. I’d be most grateful if anyone has some answers!
Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk