Posts tagged malware
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).
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.
Assigning Descriptive Names to Malware - Why and How?
In addition to naming malware according to predictable formats, as I described earlier, security firms often assign descriptive names to high-profile malicious programs. The researcher who coins the name that sticks, should the specimen gain notoriety, gets bragging rights. The person’s employer might also benefit from a slight marketing boost.
It’s natural for a researcher analyzing a malicious program to want to refer to the specimen by a memorable name. Such descriptive names might be based on a file name that the program used, a registry key it created or a relatively unique string embedded in the executable.
For instance, the name of recently-discovered “Duqu” malware is, according to Symantec, based on the prefix “~DQ” that the malicious program uses when naming some of its files. The name Duqu was assigned to the specimen by The Laboratory of Cryptography and System Security (CrySyS). According to CrySyS, they
“Participated in the discovery of Duqu malware within an international collaboration. While gathering deeper knowledge about its functionality, we have confirmed Duqu is a threat nearly identical to Stuxnet. After the thorough analysis of samples we prepared a detailed report about Duqu, named by us.”
Because the origins the Duqu discovery trace back to CrySyS, rather than stemming from independent discoveries made by antivirus companies, the security community didn’t have the opportunity to develop alternative names for this malware. As the result, Duqu is the name that stuck.
As another example, consider how Conficker got its name. At one point, the variants of this malicious program were initially known as Downadup and Kido. At the end of November 2008, the program was observed to have direct associations with the domain trafficconverter.biz. One theory suggests that the name “Con-Fic-K-Er” was derived from rearranging the letters of “trafficconverter.” The use of “ficker” in the name is attributed to “a vulgar nominalized form of the German transitive verb ficken, which is common German for the English “f**k”.”
The name Conficker stuck, perhaps because it was more memorable than the alternatives. Sean Sullivan from F-Secure pointed out that the company initially “used Downadup (Kaspersky based name), but kept getting asked about Conficker.” So they switched.
The marketing advantage in the case of Conficker belonged to whichever company began using the name that stuck first, because the public may have perceived that firm as being the first to research this specimen and also because web searches for “Conficker” may have led more visitors to that company’s website. (Despite this, I still don’t know which firm or individual actually coined the name. Do you?)
I’m fascinated by onomastics, and wish I had the time to perform a more comprehensive study of the descriptive names that have been assigned to popular malware samples in the short history of the antivirus industry. Digging into the details, including interviews with the people who examined the specimens and picked the names could provide an interesting context to such stories. Perhaps someone else can take on that quest.
— Lenny
How Security Companies Assign Names to Malware Specimens
There have been several attempts to standardize the conventions used to name malware samples. Yet, picking malware names in a consistent manner is harder than one might assume. Security companies tend to assign names to malware according to variations of the CARO naming scheme. CME was another effort for assigning identifiers to malicious programs; this project focused on high-profile malware and is no longer active.
The CARO Naming Scheme
The security community benefits when security companies agree on a name when referring to a particular malware specimen, For instance, a single name can act as a tag to the relevant information resources as tools, so that individuals can quickly locate them when responding to malware infections. While agreeing on a single name for a particular sample is hard to accomplish in most cases, companies can agree on the general approach to assigning names to malware specimens.
A naming scheme that came the closest to being adopted by antivirus firms is CARO. According to Dr. Vesselin Bontchev,
“The fundamental principle behind the CARO Malware Naming Scheme is that malware should be grouped into families, according to its code similarity. The other fundamental principle is that malware names should be unique - that is, every different malware variant, no matter how minor, should have a different name from that of any other malware.”
The resulting format follows the pattern “[<type>://][<platform>/]<family>[.<group>][.<length>].<variant>[<modifiers>][!<comment>]”, where the tags in square brackets are optional.
Though CARO wasn’t universally adopted directly, security companies base their naming conventions on CARO for the most part. For instance, Microsoft Malware Protection Center names malware like this:
(The diagram above was created by Microsoft.)
The Common Malware Enumeration (CME) Initiative
Even when companies use a CARO-based naming scheme, the firms might differ in how they name identical malware specimens, for instance by using different approaches to selecting the Family Name component. To aid companies in referring to a popular malware specimen by a common name, MITRE launched the Common Malware Enumeration (CME) initiative.
According to the FAQ, the goals of CME were to:
“Reduce the public’s confusion in referencing threats during malware incidents.
Enhance communication between anti-virus vendors.
Improve communication and information sharing between anti-virus vendors and the rest of the information security community.”
The CME effort is no longer active. According to the CME website, CME identifiers were meant to be assigned to “high-profile threats.” However,
“The changed nature of the malware threat since late 2006—away from pandemic, widespread threats to more localized, targeted threats—greatly reduced the need for common malware identifiers to mitigate user confusion in the general public.”
It’s unfortunate that CME is no longer being maintained, but I understand the realities that make efforts such as CME impractical. Yet, there is still plenty of popular malware that affects a lot of people, and we could benefit from assigning common names to malicious programs that catch the public’s eye. Instead, security companies tend to assign various eye-catching names to popular specimens, as I’ve discussed in a follow-up post.
How Antivirus Software Works: 4 Detection Techniques
Though endpoint antivirus tools may differ in their implementation of malware-detection approaches, the tend to incorporate the same 4 essential techniques. In an article for SearchSecurity, I described at a high level how these techniques function, covering:
- Signature-based detection
- Heuristics-based detection
- Behavioral detection
- Cloud-based detection
Read the full article to more about these aspects of antivirus tools running on endpoint systems. If you’re not a member of the SearchSecurity website, you can scroll past the initial footer of the page to read the full article.
Capabilities and Limitations of Enterprise Antimalware Suites
Standalone antivirus products have matured to encompass a variety of tools for securing endpoints in an enterprise setting. As the threats associated with malicious software increase in sophistication, so do the capabilities of antimalware tools. Understanding the capabilities and limitations of components that form such a suite is critical to selecting the right product and deriving value from it.
My recent article for the Information Security Magazine explains what components are typically incorporated into enterprise antimalware suites, discussing the following:
- Traditional antivirus protection
- Capabilities for spyware and rootkit protection
- Host firewall and intrusion prevention
- Securing the web browser
- Safeguarding email communications
- Cloud aspects of antimalware suites
- Centralized management capabilities
- Deployment considerations
Read the full article to understand what to expect from a modern antimalware suite in an enterprise setting. If you’re not a member of the SearchSecurity website, you can scroll past the initial footer of the page to read the full article.
Looking for Infected Systems as Part of a Security Assessment
There are many types of information security assessments. These projects typically look for security weaknesses, so that the organization can address the issues in a prioritized manner. The results of the assessments, especially those focused on identifying internal IT infrastructure vulnerabilities are often the same: the organization lacks critical security patches, which puts its data at risk.
Considering that the results of many traditional security assessments can be predetermined without actually conducting the assessment, how should the scope or approach to such projects change to provide more value? One option is to include tasks that examine the environment for the presence of malware or other signs of a compromise. Assessing the infrastructure for the presence of malware could also be a standalone project.
Techniques for identifying the signs of malware or compromise in an enterprise setting include the following:
- Identify at-risk systems, such as those not being centrally managed by the IT group or those without the properly-configured antivirus/endpoint security tools.
- Analyze autorun entries (registry keys, services, browser add-ons, etc.) to identify anomalies, such as references to programs that are present on only some systems in the enterprise.
- Examine outbound network traffic to identify systems that attempt to communicate with known bad IP addresses, domain names or network blocks. Using a DNS sinkhole may assist with this task.
- Scan file system contents for suspicious files, such as those that include obfuscated JavaScript or those that appear to be packed.
The data for some of the tasks above can be collected using authenticated vulnerability scans. Others involve placing a network sniffer in the environment or examining network, firewall and DNS logs. In some cases, the assessor may need to run tools on the assessed systems to capture additional data. There is also an opportunity for security vendors to license their tools in a per-project basis to make them useful for such malware assessments. One example of this is the consultant-friendly licensing option of Damballa Failsafe; I expect more vendors to position their tools in a similar manner, if they aren’t doing this already.
Hand-picked related items:
The bad guys could be badder, but most chose not to be.
NetworkMiner for Analyzing Network Streams and Pcap Files
NetworkMiner is a free Windows utility for analyzing network traffic. It can examine live traffic that the system is sniffing off the wire. It can also explore contents of previously-captured traffic saved in the pcap format. The tool is designed to only display the details most relevant to network forensics. It is especially useful for carving packet captures to extract the files they contain, so you can further analyze the files that might be malicious.
One Use-Case for NetworkMiner
Consider a scenario where you’re analyzing a suspicious website, wishing to understand the way that it might try attacking its visitors. One way to approach this challenge is to browse the website using a Windows laboratory system designated for this type of work. In this case, your hope might be to have the system attacked and infected, so you can understand the nature of the threat.
There are several tools that could capture relevant details about the attack, so you can analyze them to understand what transpired. For instance, CaptureBAT can capture not only process-level activity on the laboratory system, but also create a pcap file of the observed network traffic. You can also run a dedicated network sniffer, such as tcpdump or Wireshark’s dumpcap, or use the sniffer built into NetworkMiner.
NetworkMiner in Action
For a quick demonstration of NetworkMiner, I’ll use the pcap file I created for the network forensics puzzle called Ms. Moneymany’s Mysterious Malware. (Though that context is over, you may want to download its files and experiment with them if you haven’t done so already.)
After you load the pcap file into NetworkMiner, it parses the file and presents several tabs with various aspects of the traffic and its contents. These include:
- The observed hosts, including their DNS names, IP addresses and ports used during the monitored period
- HTTP parameters sent to web servers as part of the observed session
- Clear-text ASCII contents extracted from the network streams, including a separate tab for any captured credentials
- The files exchanged between the hosts during the monitored period
NetworkMiner automatically carves out the files found in the network stream, saving them to a local folder. One of the reasons for using an dedicated laboratory system when using the tool in this capacity is that the files might be malicious, and you may get infected if you don’t handle them carefully.
To view the extracted file, right-click on the file of interest in NetworkMiner’s Files tab, then select open folder.
To experiment with the pcap file I mentioned in this write-up, read and consider solving the Ms. Moneymany’s Mysterious Malware network forensics puzzle. Also check out my follow-up malware analysis challenge. For more ways of using NetworkMiner, look over to the NETRESEC Network Security Blog.
Update: Though NetworkMiner is designed to work on Windows, you can get it to run on Linux, including BackTrack.
Process Hacker as an Alternative to Process Explorer
Process Hacker is an open source replacement not only for the built-in Windows Task Manager, but also for the popular Process Explorer tool. Process Hacker implements many of the same features that Process Explorer has for examining local processes, and adds a number of unique capabilities that are especially useful when examining an infected system or analyzing malware.
Like Process Explorer, Process Hacker can display the listing of running processes in a tree-like fashion, showing you the parent-child relationship between the processes. Both tools color-code the entries based on the processes’ characteristics:
Process Hacker can visually identify processes that are being debugged, those are associated with services and those that were packed. You can see the legend and change color assignments by selecting Hacker > Options > Highlighting:
Process Hacker includes a separate tab for listing active services, and a tab showing active network connections. The tab shows local and remote IP and port details and identifies the local process that owns the connection:
Process Hacker shines in the number of capabilities it offers for analyzing and manipulating a particular process. For instance, right-clicking the process presents you with various menu options:
Selecting Properties gives you several tabs. One of the most useful ones is Memory, which lets you the ability to view contents of the process’ memory, extract strings, search based on regular expressions and even modify memory contents.
Other capabilities of Process Hacker include the ability to locate some hidden processes, inject a DLL into a process, create a service, locate file handles and DLLs, and many others. The best way to become familiar with the tool is to experiment with it. Give it a try, then be sure to share with others what you have learned.
- 3 Free NirSoft Tools for Malware Analysis
- Process Monitor Filters for Malware Analysis and Forensics
- Using Netsh for Easier Network Setup in a Malware Lab
Just so you know, I teach the malware analysis course at SANS Institute.
- Page 1 of 8
- Next »
