Several Posts on Malware Analysis Tools

In the past weeks I published several posts describing malware analysis tools and approaches at other blogs:

• Installing the REMnux Virtual Appliance for Malware Analysis: Starting with version 4, the REMnux virtual appliance is available as the Open Virtualization Format (OVF/OVA) file, which can be imported into most virtualization tools, such as VMware and VirtualBox. Extra: Explore other updates in the Announcement of the REMnux v4 Release.

• Automating Static Malware Analysis With MASTIFF: MASTIFF is an open source framework for automating static malware analysis. This tool, created by Tyler Hudak, determines the type of file that is being analyzed and then applies only the static analysis techniques that are appropriate for that file type. MASTIFF offers a useful way for performing triage on a large set of suspicious files. Extra: See my MASTIFF demo as part of the What’s New in REMnux v4 for Malware Analysis webcast.

• Extracting Digital Signatures from Signed Malware: Sometimes attackers digitally sign their malicious software. Examining properties of the signature helps malware analysts understand the context of the incident. Moreover, analysts could use the signature as an indicator of compromise. Here are some tips and tools for determining whether a suspicious Windows executable has been signed and for extracting the embedded signature in a Linux environment. Extra: Check out steps to extract signatures from Apple .app files and Didier Steven’s AnalyzePESig tool.

• Tools for Examining XOR Obfuscation for Malware Analysis: There are numerous ways of concealing sensitive data and code within malicious files and programs. Fortunately, attackers use one particular XOR-based technique very frequently, because offers sufficient protection and is simple to implement. Here’s a look at several tools for deobfuscating XOR-encoded data during static malware analysis. Extra: Experiment with Thomas Chopitea’s unXOR tool.

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.

— Lenny Zeltser

Anticipating Cyber Threats Beyond APT

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:

• Will traditional APT actors eventually disengage from early APT targets, perhaps after obtaining the necessary data, finding the cost of maintaining presence too costly or deciding to focus on easier-to-attack victims? Have they done this already?
• Will APT groups remain engaged, but drastically change tactics according to new goals and in response to new defensive elements? How have these tactics changed in the recent years?
• What can we learn by treating initial APT targets as predictors of threat dynamics that will eventually affect a broader set of victims? What attacks are effective today against the organizations that had the time and skills to adapt to initial APT tactics?

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:

• A greater use of purchased non-public exploits. (See Reuters’ article on the trends in the exploits market.)
• More professional oversight of multiple aspects of attack operations and logistics to improve effectiveness and efficiency.
• Smarter mining of stolen data (“big data”) to derive intel for subsequent attacks, discover relationships and spot other valuable information.
• The adoption of the techniques seen in “military-grade” malware, such as Stuxnet, by a broader range of attack groups. (See Eugene Kaspersky’s concerns over military’s use of malware.)
• Increased use of anti-forensics and evasion techniques to conceal attackers’ capabilities and motives. (See Eugene Rodionov and Alexandr Matrosov’s overview of anti-forensics malware features.)

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:

• Mutually-Assured Destruction in Cyberspace
• Indicators of Compromise Entering the Mainstream Enterprise?
• Why I Make Fun of Advanced Persistent Threat (APT)

— Lenny Zeltser

Live and Recorded Malware Forensics Webcasts

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:

• Pwn’ing APT1 with Yara Signatures by Jake Williams, May 29, 2013

Previously-recorded malware forensics webcasts:

• Introduction to Malware Analysis on Windows: Turn Malware Inside Out! by Lenny Zeltser
• Sharper Incident Response with Protocol Reverse Engineering by Michael Cloppert
• Malware Analysis Essentials using REMnux by Lenny Zeltser
• What’s New in REMnux v4 for Malware Analysis? by Lenny Zeltser
• Memory Forensics for Incident Response by Hal Pomeranz
• Finding Unknown Malware by Alissa Torres
• 50 Shades of Hidden - Diving Deep Into Code Injection by Jake Williams

— Lenny Zeltser

Indicators of Compromise Entering the Mainstream Enterprise?

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:

• Context-Specific Signatures for Computer Security Incident Response
• Looking at Mutex Objects for Malware Discovery and Indicators of Compromise
• SANS Reverse-Engineering Malware Course

— Lenny Zeltser

Name That Malware!

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.

Take the 10-question Name That Malware! quiz.

If you like this approach to learning, here are two more quizzes I put together:

• Certified APT Nerd (CAPTN) Examination
• What’s Your Malware Analysis Prowess?

— Lenny Zeltser

Tips on Malware Analysis from Jake Williams

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:

• Part 1: Getting into digital forensics, crafting a strong malware analysis reports and making use of the analyst’s findings
• Part 2: Acting upon malware analyst’s findings and the role of indicators of compromise (IOCs) in the incident response effort
• Part 3: Various approaches to malware analysis, including behavioral, dynamic, static and memory forensics 

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.

— Lenny Zeltser

How Malicious Code Can Run in Microsoft Office Documents

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.

VBA Macros

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).

Embedded JavaScript

Another way to automatically execute code then the victim opens a Microsoft Office document involves embedding the ScriptBridge ActiveX control in the file. This control allows the attacker to embed and execute JavaScript, as was the case with the malicious “World Uyghur Congress Invitation.doc” file I obtained from the Contagio blog. This file used the “Microsoft Scriptlet Component”, implemented as the ScriptBridge ActiveX control to execute the embedded JavaScript code.

This Word file used ScriptBridge to execute embedded JavaScript code, which downloaded a malicious Flash file by from the specified URL. Microsoft Office automatically invokes embedded ActiveX controls that are marked Safe-For-Initialization, which is the case with ScriptBridge. (I’d love to better understand how ScriptBridge is being used to run JavaScript, so if you have more details, please let me know.)

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).

Related articles:

• How to Extract Flash Objects From Malicious MS Office Documents
• How to Extract Flash Objects from Malicious PDF Files
• Extracting VB Macro Code from Malicious MS Office Documents
• Analyzing Malicious RTF Files Using OfficeMalScanner’s RTFScan

By Lenny Zeltser

Extracting Malicious Flash Objects from PDFs Using SWF Mastah

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.

— Lenny Zeltser