Active exploitation of Excel vulnerability
The US-CERT has published a warning on active exploitation of a vulnerability in Microsoft Excel, described in Microsoft Security Advisory 947563. We can confirm these attacks and have been tracking several exploits over the last few days.
It should be noted that the incidents we are aware of have been limited to a very specific targeted attack and were not widespread. In total, we established approximately 21 reports of attacks using only 8 different files, from within the same two communities, so far.
Below are the md5sum’s for the individual exploits:
d03254bbcb124a20478287a77199a001
718e4ff4691f8cefcf296607b3b53b6c
3b4409efea04c003e91b38ed8b428706
2511f821af2d5bea80899bf2ce716b34
15a10055acbc901504708249848228fb
51b3d57064e182eee8a702abd4ee43fe
9983c89a4c148f8aee0a80271ad0a584
69014e152d93f4bc09ce5894d5e793aa
Throughout the incident, we worked together with various anti virus vendors to ensure coverage. Below are some of the signatures we know of that catch iterations of these attacks. Note that some are relatively generic and catch multiple other exploits as well:
Trend Micro: TROJ_MDROP.AH
AntiVir: TR/Drop.MSExcel.Agent
BitDefender: Exploit.MSExcel.Dropper
Fortinet: MSExcel/MalExcel.B!exploit
F-Secure: Trojan-Dropper.MSExcel.Agent
Ikarus: Trojan-Dropper.MSExcel.Agent
Kaspersky: Trojan-Dropper.MSExcel.Agent
McAfee: Exploit-MSExcel.p
Microsoft: Exploit:Win32/Exrec.A
NOD32: X97M/TrojanDropper.Agent.L
Symantec: Trojan.Mdropper
WebWasher: Trojan.Drop.MSExcel.Agent
We are aware that some of the samples connect back to update-microsoft.kmip.net (221.130.180.87) on port 80, to retrieve the IP address of the actual control server.
Update: Microsoft released patch MS08-014 on March 11th, that fixes the vulnerability. It was first acknowledged by Microsoft on January 15th.
--
Maarten Van Horenbeeck
Branching targeted attack execution paths outside of the code
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
Comments