Update 7-8-14: Part 2 can be found here
This is part one in a two-part series due to the sheer amount of data we found on this threat and threat actor. This particular attack was a combined spearphishing and exploit attempt. As we’ve seen in the past, this can be a very effective combination.
In this specific example the attackers targeted a feature within Microsoft Word — Visual Basic Scripting for Applications. While basic, the Office Macro attack vector is obviously still working quite effectively. When the victim opens the Word document, an On-Open macro fires, which results in downloading an executable and launching it on the victim’s machine. This threat actor has particularly lavish tastes. This threat actor seem to target high-profile, money-rich industries such as banking, oil, television, and jewelry.
Discovering the threat
The VRT has hundreds of feeds of raw threat intelligence, ranging from suspicious URLs, files, hashes, etc. We take that intelligence data and apply selection logic to it to identify samples that are worthy of review. Using various methods from machine learning to dynamic sandbox analysis, we gather details about the samples – producing indicator of compromise (IOC), and alerts made up of multiple IOCs.
During our analysis we took the last 45 days’ worth of samples, and clustered them together based on a matching set of alert criteria. This process reduced over a million detailed sample reports to just over 15 thousand sample clusters that exhibit similar behavior. Using this pattern of similar behavior, we were capable of identifying families of malware. This led us to discover a Microsoft Word document that downloaded and executed a secondary sample, which began beaconing to a command and control server.
The Malicious Word documents & Associated Phishing campaign
The attacks we uncovered are an extremely targeted spear phish in the form of an invoice, purchase order, or receipt, written specifically for the recipient. For instance, the following is an example message we observed that purportedly came from “Maesrk”, the shipping company.
The message is a fairly simple phish email which includes a fake name and an attached Microsoft Word document. However, this was simply the outer layer of the onion so it’s best, we think, to start from the beginning.
This particular phishing attempt was noticed in our email corpus due to the email attachment’s poor block rates at most AV engines. For the duration of this campaign there is one thing that remained consistent: at best, a few antivirus engines may have generically detected the attached malware but more often than not coverage was provided by a single vendor, or no coverage was provided at all. The company targeted by this specific spear phishing attack focuses on research and manufacturing.
The malicious Word file used in the attack is:
File name: 2014-05.doc
During execution, the malicious executable downloaded by the Word macros contacts several domains:
This allowed us to link this threat to other, similar pieces of malware our FireAMP system detected in previous attack campaigns:
2014-05.doc (2 different samples)
The threat actor used the cloud-based file-sharing service offered by Dropbox to host four separate pieces of the payload for the exploit. We reported these links to the Dropbox security team who confirmed that they disabled the file share links. We believe the londonpaerl.co.uk and selombiznet.in domains act as command and control servers. After execution of each piece, a small encoded string is submitted via HTTP POST back to the command and control server.
Chaining details of the domain whois and passive DNS information show this threat actor has been in operation since at least 2007.
Discovering historical infrastructure
Now, we will be looking at techniques that can be used to identify the threat actors’ domain and IP infrastructure, and how this information ultimately can help us identify other attacks perpetrated by the same group.
Upon examination of the two command and control domains selombiznet.in and londonpaerl.co.uk we observed something interesting.
We now had some additional pieces of information, an email address and a reused address phrase: “2 close medical/medicle road”. In addition to this, there were many examples of whois information that was not consistent with itself (for example an address in London listing a U.S. city and state). The postal codes and phone numbers were also frequently inconsistent. We then linked this information to several other domains, which led to even more information:
Realizing this actor had fairly poor operational security (opsec), we decided to search for the weird bit at the end of the first address, specifically the “number 2 close off medical road london”. This led us to even more domains, some of which we could even confirm had been involved in malicious activity in the past. In this particular case, the information had to be obtained from historic whois data.
This led us to even more domains and indicators of the threat actor. As we’ve been peeling back the layers of the onion on this actor, we’ve associated the following set of email addresses, domains, and registering organizations.
It is interesting to note, on May 26, we blocked five backdoor components coming from londonpearl-uk.co on 5/26. All of these attacks were directed at a single customer, on the same day, within a 90-minute period. The customer targeted was involved in the industrial manufacturing vertical.
During the investigation, we identified several different campaigns believed to be associated with this threat actor involving many other pieces of malware. Many of the domains appear to be suspended presumably due to past malicious activity. In fact, during the investigation the threat actor changed the information on some of the domains several times. Luckily, if you monitor whois history you can still view all of this information, including the evasion attempt. While we were performing the investigation, items like addresses, email addresses, and such were changed, literally, in between browser refreshes. All of the domains we’ve associated with this threat have been blocked for web security customers since their discovery. We will continue to monitor the situation.
Interestingly, if you search for the right things you can also associate some of these contact addresses from the malicious domains to other domains using privacy protection services. Here is one example:
We discovered an information leakage leading us to the threat actor in some domain SOA records — the domain “hostmaster” contact address (highlighted in blue):
In this part of the blog series, we have looked at the malware we found in our telemetry and used it to identify a group of attacks by the same threat actor. We also examined ways to link the infrastructure of the threat actor to expose their network. It is important to keep in mind that some of these machines may not be voluntary participants, public services may be being abused or they may be compromised themselves. In part 2 of this blog series, we will take a technical deep dive into the malware itself and examine the various obfuscation techniques.