In the past weeks I published several posts describing malware analysis tools and approaches at other blogs:
Also, on my own blog I took a look at Cylance’s Accelerify tool for speeding up the lab system’s clock for malware analysis.
Some organizations have encountered Advanced Persistent Threat over 5 years ago—earlier than most of us. Because of the types of data they process, these initial APT victims were exposed to carefully-orchestrated, espionage-motivated attacks before they spread to a wider range of targets.
Now, half a decade later, might the time to look at the attacks that the initial APT victims are fighting nowadays to forecast the threats that will eventually reach other companies. I am wondering:
It’s hard to answer these questions without first-hand access to the companies that witnessed the first wave of APT attacks. Furthermore, the dilution of the term APT by marketing departments makes it harder to differentiate between reliable APT insights, such as what Mandiant has been publishing, from generic APT-themed sales collateral peppered throughout the web.
Based on public information and observations, I suspect the threat landscape over the next few years will involve:
These are just conjectures. I don’t have the answers to the questions I posed above; however, I thought I’d at least ask them and explore the idea of looking at early APT targets’ current state to anticipate advanced threats that will later affect other organizations.
Related articles you might like:
In the field of IT in general and digital forensics in particular, you become obsolete the moment you stop learning. Here are several free webcasts related to reverse-engineering and malware analysis that will help you keep your skills up to date.
Upcoming live malware forensics webcasts:
Previously-recorded malware forensics webcasts:
The need to define custom, incident-specific signatures is slowly gaining traction in the mainstream enterprise. A few years ago this concept, often called Indicators of Compromise (IOCs), was mostly discussed by government organizations and defense contractors who were coming to terms with Advanced Persistent Threat (APT) attacks.
Madiant began popularizing the term IOC around 2007. Kris Kendall’s paper Practical Malware Analysis mentioned IOCs in the context of malware reversing at Black Hat DC 2007. For a precursor to this, see Kevin Mandia’s Foreign Attacks on Corporate America slides from Black Hat Federal 2006. At the time, few organizations saw the need to go beyond antivirus-based detection by analyzing the adversary’s artifacts to define custom host-level signatures.
Now, several years later, the term IOC is pretty well-known in the infosec industry. More companies are adding malware and related analysis skills to incident response teams. As Jake Williams put it, such firms know how to examine new malware and extract IOCs. “These are then fed back into the system and scans are repeated until no new malware is found.” Automated analysis products from vendors such as Norman, Mandiant, FireEye and HB Gary are being increasingly positioned as IR triage-enablers.
That said, the knowledge and skills for deriving and using IOCs is far from being mainstream. Anton Chuvakin highlighted the distinction between security haves and have-nots along the lines of this capability. The haves know how to reverse-engineer malware to “extract the IOCs FAST (or get those IOCs shared with you by trusted friends) and then look for them on other systems.”
IOC techniques haven’t entered the mainstream just yet. But we’re heading in that direction, as more people attain forensics skills and as more tools become available for defining and making use of such custom, incident-specific signatures.
To learn how to define and make use of IOCs, take a look at:
Think you know malware? I created a new fun quiz to see whether you can recognize the 10 malware specimens you should probably know by name. Test your knowledge and learn something along the way.
If you like this approach to learning, here are two more quizzes I put together:
— Lenny Zeltser
I had the pleasure of speaking with Jake Williams, my colleague at SANS Institute, about his perspective on various malware analysis and reverse-engineering topics. You can read the interview in three parts:
Jake is highly experienced in this space and shared helpful insights in the interview above. Jake will be teaching FOR610: Reverse-Engineering Malware on several occasions at SANS this year.
Be doubly vigilant after a physical break-in. Don’t just look for what’s missing, but what might have been left behind.
One of the most effective methods of compromising computer security, especially as part of a targeted attack, involves emailing the victim a malicious Microsoft Office document. Even though the notion of a document originally involved non-executable data, attackers found ways to cause Microsoft Office to execute code embedded within the document. Below are 4 of the most popular techniques used to accomplish this.
Support for executing code that’s embedded as a VBA macro is built into Microsoft Office. Once the victim opens the document and allows macros to run, this code can run arbitrary commands on the user’s system, including those that launch programs and interact over the network. The penetration testing tool Metasploit makes it relatively straightforward to generate payload that attackers could embed in an Office file as a VBA macro. (See one example by Chris Patten.)
Such macros can be included in “legacy” binary formats (.doc, .xls., .ppt) and in modern XML-formatted documents supported by Microsoft Office 2007 and higher. In either case, Office will present the user with a security warning, stating that macros have been disabled and offering to “enable content.” Social engineering techniques can persuade the victim to click the button that will allow the embedded macro to run and infect the system.
Payload of a Microsoft Office Exploit
Another way to execute malicious code as part of an Office document involves exploiting vulnerabilities in a Microsoft Office application. The exploit is designed to trick the targeted application into executing the attacker’s payload, which is usually concealed within the Office document as shellcode.
In this case, Microsoft Office has to be exploited to execute the attacker’s code. This is in contrast to the previous scenario, where the attacker takes advantage of macros, supported by Microsoft Office as a feature. For instance, vulnerability CVE-2012-0141, announced in May 2012, could allow the attacker to craft a malicious Excel file to include an exploit that would “take complete control of an affected system.”
Embedded Flash Program
Embedding a Flash program inside an Office document provides attackers yet another way to run malicious code on the victim’s system. In this case, the code within the Flash object run as soon as the victim opens the document without any warnings and without relying on exploits. This code is till subject to security restrictions imposed by Flash Player, so to perform escalated actions the code would need to exploit a vulnerability in Flash Player.
One example of this attack has been described by Mila on the Contagio blog. The malicious Word document “DOC Iran’s Oil and Nuclear Situation.doc” was sent to a victim as part of a targeted attack. The document contained a Flash object, as seen below. (See steps to manually embed a Flash object in an Office document.)
Attackers can embed Flash objects in Office documents using automated tools. manual steps to do this the Flash object instructed Flash Player to download and play an MP4 file that was designed to exploit the CVE-2012-0754 vulnerability in Flash Player, announced in February 2012. This allowed the attacker to infect the victim’s system with a malicious Windows executable (trojan).
In the case of this Word document, the downloaded Flash file was crafted to exploit the CVE-2012-0779 vulnerability in Flash player, announced in May 2012.
These are some of the techniques that intruders have used to execute code in Microsoft Office documents to compromise the system. The attacker could directly take advantage of a vulnerability in the targeted Office application. In other cases, the attacker uses functionality provided by Microsoft Office to either trick the user into allowing the malicious code to run (VBA macros) or to use a weakness in Office settings to run code that exploits vulnerabilities in other applications (Flash Player).
PDF files designed for infecting computer systems can include a malicious Flash/SWF program that’s designed to aid in exploiting a vulnerability in Adobe Reader or Flash Player. In an earlier article I explained how to extract SWF object from a PDF file using PDF Stream Dumper and pdf-parser. A new tool SWF Mastah, by Brandon Dixon, can assist with this process as well.
SWF Mastah makes use of Brandon’s PDF X-RAY framework and Jose Miguel Esparza’s Peepdf tool and to handle complex PDF files even in situations where pdf-parser might fail at locating or extracting the SWF object. Here’s a quick example, which uses the malicious PDF file “The Obama Administration and the Middle East.pdf” that was documented on Contagio Malware Dump.
SWF Mastah (a.k.a. swf_mastah.py) can scan the PDF file, automatically locate a Flash object and extract it, all in one step:
The screen shots above show SWF Mastah running on the REMnux v3 distro, which I am planning to release shortly. For another example of SWF Mastah in action, see Brandon’s blog posting in which he introduced the tool to the world.