Tom and Jeb were at it again. They were in the big leagues now, with a new contract. All that remained to be done for their current mission was to raid confidential data from an electronics giant. They had failed so far to ‘Hack the Gibson’ – compromising the company’s web servers had proven to be challenging, to say the least.

They pulled up an old C compiler, grabbed the sources of a common Trojan family from a torrent, and crafted a malicious binary. It would do nothing out of the ordinary, just download a second binary from a web server. That second stage payload would then grab e-mails matching certain text patterns, and submit those through an HTTPS channel to a server under their control.

They had done their homework: after setting up a fake social networking account, they identified the people representatives their target company talked to. They studied the writing style of one of those contacts. Now, they would ship off their exploit to some people within the overall community in an otherwise innocuous e-mail, posing to be one of them.

To ensure the message reached its target, they clearly mentioned in the e-mail that recent “privacy breaches” that had been discussed on a public list frequented by the target, were an outrage, and everyone should be made aware of them.  Only a few hours later, Tom and Jeb’s message was forwarded to the target company by one of their legitimate contacts. This made the message look all the more trustworthy.

Some other recipients though, found out the code was malicious. They forwarded it on to their anti virus vendor. The vendor investigated the issue, but found the host name for the secondary payload to resolve to 127.0.0.1. They built coverage, patterns were distributed, and machines were cleaned. Tom and Jeb’s attack was brought to an abrupt halt. The security community had been victorious!

In the background, however, Tom and Jeb were sitting behind their machine, looking at the target’s confidential data flow in. Bit by bit, valuable data trickled through, allowing them to plan the next steps in their deep compromise.

What had gone wrong, you ask? The fact that most of the time we prepare for attacks that are global in nature, while in fact incident handlers need to deal with uncertainties, multiple execution paths, if you will, at every step of the way.

Tom and Jeb had set their sights on a very specific target. They accessed their target through people they trust, making it more likely for them to click on the message. Next, they had set up two views on a hacked DNS server, authorative for the domain in which their control server resided. In BIND tongue:

View “world” {
 match-clients  { all_addresses; }; }
 zone “controlserver.com” {
 type master;
 file “/resolve.localhost”; };
};

view “target” {
 match-clients { target_dns_servers; };
 zone “controlserver.com” {
 type master;
 file “/resolve.controlserverip”; };
};

Only the resolver DNS servers of the real target had seen a real IP address when looking up the hostname for the control server. All others saw 127.0.0.1. The code that was forwarded to the various anti virus vendors did not give them sufficient data to protect the target. To them, the secondary payload server was no longer ‘live’.

The above situation took place in a recent targeted attack on an NGO. When handling incidents for others at a different location, be careful. The execution path you see may not be the same as the client’s. A lot of attention in industrial espionage investigations is being spent on ensuring we covered all the execution paths within a malware specimen, but in some cases, these paths branch outside the actual code.

Seen this as well, or any comments or ideas? Write to us.

--
Maarten Van Horenbeeck