In our earlier post discussing steganography, I discussed how it is now being used to hide configuration data by malware attackers. Let’s go discuss this subject another facet of this topic in this post: how actual malware code is hidden in similar ways.
Security analysts will probably throw their hands up in the air and say, “we’ve had code hiding within code for years now, that’s not steganography!”. That’s not what I’m talking about. I will talk about how steganography is used with seemingly innocuous data files that actually hide binary code. If the differences sound small to you, I don’t blame you. Hopefully these examples will make things clearer:
DarkComet dropper carries a bitmap… with data inside
This particular variant surfaced in November 2014 and is relatively simple. It’s a .NET executable with a BMP image file in the resource section. While the image has perfectly valid headers, it doesn’t really show anything meaningful. To human eyes it looks like random pixels in all manner of fancy colors. Perhaps it was a mistake on the coder’s part? No. Actually, the pixels are encrypted code, not designed to be looked at. When the file is run, DarkComet takes the image, decrypts the code, and runs it.
Figure 1. Contents of the bitmap image file
What’s the point of keeping code hidden this way? That is a fair question. As long as there is decryption code included in the malicious package – and it has to be there – antivirus software still has something to detect. How is this helping the attacker evade detection?
This scenario makes more sense if you think about the what’s hidden: an off-the-shelf keylogger. Antivirus software is capable of detecting it even as it is being created, so the cybercriminal is trying to keep a pistol with a red bullseye with neon lights under the radar. Is this something that can be accomplished with regular packing/encryption? Sure, but whoever was responsible thought this would be more inconspicuous. Alternately, he may have just learned about steganography and wanted to try out new things.
Hiding C&C commands in DNS traffic
It’s not just code that can be hidden – so can command and control (C&C) communication channels. C&C communication mainly happens through HTTP, and it’s not too difficult to spot. Sometimes attackers will come up with some small innovation that makes researchers like myself respect the technique behind it, if not the motive. A well thought-out steganography technique is usually that kind of thing. Let me show you the following example.
The Morto Trojan uses a very shrewd way of concealing its C&C traffic. Instead of using HTTP, it uses simple DNS requests looking for non-existent domain names. The queried DNS server (which is the actual C&C server) responds by providing the commands inside the response.
Figure 2. DNS records
The text being exchanged is further obfuscated by a simple Base64 encoding. This tries to prevent automated systems from spotting the contents straight away, although it does provide clues, since the payload is longer than it needs to be – and therefore, suspicious. An earlier blog post has already discussed Morto’s details.
JPG images on websites used by TDSS/Alureon for C&C communication
The now-defunct TDSS botnet also used an unusual method of C&C communication: requesting JPG images that were hosted on popular blogging sites. These images contained C&C commands that controlled the botnet. These files were very difficult to block for two reasons: they were hosted on legitimate, well-known sites, and the files themselves were still valid image files.For all intents and purposes, the Trojan was downloading real images from a blog. Let’s look at a collage of three of those images:
Figure 3. Images with commands overlaid on top (via Microsoft Technet)
When decoded and decrypted, the images contained the botnet commands shown overlaid on the image above.
ShadyRAT hides C&C communication inside HTML code
This notorious data-stealing spying Trojan also used blogging platforms as a C&C channel, except that the commands are encrypted and encoded into HTML comments, interspersed with what appears to be legitimate content. This makes the traffic look like it comes from a real user visiting a blog with a regular web browser. In fact, the page is not being displayed at all on the infected system; the Trojan just decodes the information within the comments and is able to understand the commands the attacker is sending. On a cursory look to the actual blog, a visitor would never spot any of this, since the comments are never displayed on the browser either.
This is a perfect vehicle for these attackers, who are trying to stay undetected for as long as possible. ShadyRAT was the first major targeted attack that was spotted in the wild, and this technique was possibly a contributing factor. The network traffic looks perfectly tame to any traffic observer or security device.
On top of this, ShadyRAT was also able to decrypt and decode C&C commands hidden within JPG files using the LSB technique as seen in the first entry of this series. A shady one indeed.
So far, I’ve discussed steganography being used to conceal binary code as well as C&C traffic. This is not so much to stop analysts from understanding the information being hidden; it is more to stop researchers from seeing that the information is there at all.
In my next post, I’ll take out my crystal ball (or tarot deck) and see what the future may bring in this field. Until then, stay safe.