HowTo: Malware Detection, pt I
This post is NOT about malware analysis. This post addresses malware detection during dead box analysis. Malware detection is pretty expansive, so to really address the topic, I'm going to spread this one out across several blog posts.
Malware Detection
Malware detection during dead box analysis can be really easy, or it can be very hard. I say this because we can mount an image as a read-only volume and run several (or more) AV scanners against the volume, and keep track of all the malware found. Or, we can run several AV scanners against the volume, and they will all find nothing - but does that mean that there isn't any malware on the system?
This post is the first of several that will write, in an attempt to fully address this issue.
Characteristics
Before we start digging into the guts of detecting malware during dead box analysis, it is important to understand the four characteristics of malware, specifically the initial infection vector, the propagation mechanism, the persistence mechanism, and artifacts of the malware. I originally developed these characteristics as a way of helping new analysts develop a confident, professional demeanor when engaging with customers; rather than reacting like a deer in the headlights, my hope was to help these new analysts understand malware itself to the point where they could respond to a customer request in a professional and confident manner. Understanding and applying these characteristics enables analysts to understand, detect, locate, and mitigate malware within an infrastructure.
Initial Infection Vector
The initial infection vector (or IIV) refers to how the malware originally made it's way on to the system. Worms like SQL Slammer took advantage of poor configuration of systems; other malware gets on to systems as a result of exploiting vulnerabilities in browsers.
Understanding malware IIV mechanisms not only provides us with a starting point for beginning our investigation, but also allows analysts to go from "I think it got on the system..." or "..if I had written the malware...", to actually being able to demonstrate, through empirical data, how the malware ended up on the system. Too many times, the IIV is assumed, and that assumption is passed on the customer, who uses that information to make critical business decisions, possibly even validating (or, invalidating) compliance.
Also, keep in mind that many of the more recent malware samples appear on systems as a result of a multi-stage delivery mechanism. For example, a user may open an email attachment, and the document will contain embedded malicious code that will exploit a vulnerability in the target application, which may reach to a server with additional instructions, and then the second stage will reach out to another server and download the actual malware. As such, the malware does not simply appear on the system, and the IIV is actually much more complex than one might expect.
Determining the IIV can be an important factor in a number of exams. For example, PCI exams require that the analyst determine the window of compromise, which is essentially the time from when the system was first compromised or infected, to when the incident was discovered and taken offline. While this is done for fairly obvious reasons, other non-PCI cases ultimately have similar requirements. Being able to accurately determine when the system was first infected or compromised can be a critical part of an exam, and as such should not be left to speculation and guesswork, particularly when this can be determined through the use well-though-out processes.
Propagation Mechanism
This characteristic refers to how the malware moves between systems, if it does. Some malware doesn't move between systems on it's own...instead, it infects one system and doesn't move on to other systems. For example, RAM scrapers found during PCI cases don't infect one system and then propagate to another...rather, the malware is usually placed on specific systems by an intruder who has unrestricted access to the entire infrastructure.
Some malware will specifically infect removable devices as a means of propagation. Worms are known primarily for their ability to propagate via the network. Other malware is known to infect network shares, in the hopes that by infecting files on network shares, the malware will spread through the infrastructure as users access the infected files.
It's important to note that the malware propagation mechanism may be the same as the IIV, but analysts should not assume that this is the case. Some malware may get onto a system within an infrastructure as a result of a spear-phishing campaign, and once on the internal infrastructure, propagate via network or removable drives.
Artifacts
According to Jesse Kornblum's Rootkit Paradox, rootkits want to remain hidden, and they want to run. The paradox exists in the fact that by running, there will be ways to detect rootkits, even though they want to remain hidden. The same is true with malware, in general, although malware authors are not as interested in remaining hidden as rootkit authors. However, the fact is that as malware interacts with it's environment, it will leave artifacts.
Self-Inflicted Artifacts
As malware interacts with it's environment, artifacts will be created. These artifacts may be extremely transient, while others, being created by the environment itself, may be much more persistent.
One of the issues I've seen over the years when AV vendors have produced technical reports regarding malware is that there are a number of self-inflicted artifacts; that is, artifacts are created as a result of how the malware is launched in the testing environment. One of the best examples of this occurs when the IIV of a malware sample is a multi-stage delivery mechanism, and the analyst only has a copy of the executable delivered in the final stage. When this occurs, the malware report will contain artifacts of the analyst launching the malware, which will not show up on a system that was infected in the wild.
As malware interacts with it's environment, artifacts will be created. These artifacts may be extremely transient, while others, being created by the environment itself, may be much more persistent.
One of the issues I've seen over the years when AV vendors have produced technical reports regarding malware is that there are a number of self-inflicted artifacts; that is, artifacts are created as a result of how the malware is launched in the testing environment. One of the best examples of this occurs when the IIV of a malware sample is a multi-stage delivery mechanism, and the analyst only has a copy of the executable delivered in the final stage. When this occurs, the malware report will contain artifacts of the analyst launching the malware, which will not show up on a system that was infected in the wild.
Looking for malware artifacts is a lot like using those "expert eyes" that Chris Pogue talks about in his Sniper Forensics presentations. When malware executes, it interacts with it's environment, and the great thing about the Windows environment is that it records a lot of stuff. In that way, it's a lot like using 'expert eyes' to look for deer on the Manassas Battlefield park...as deer move through the park, they leave signs or 'artifacts' of their presence. They're grass eaters, and they leave scat that is different from fox, dogs, and bears (as well as from other grass eaters, like our horses). They leave tracks, whether it's in the mud, sand, soft dirt or snow. When they move through tall grass, they leave trails that are easily visible from horseback. When they lay down for the night, they leave matted grass. Sometimes the bucks will leave velvet from their horns, or if a couple of bucks are sparing, you may actually find a horn or two (we have a couple hanging in the barn). My point is that I don't have to actually see a deer standing in a field or along a stream to know that there are deer in the area, as I can see their "artifacts". The same thing is true for a lot of the malware out there...we just need to know what artifacts to look for, and how to look for them. This is how we're able to detect malware during dead box analysis, particularly when that malware is not detected by AV scanners.
Some of the more popular locations where I've found artifacts include AV logs, and on Windows XP systems in particular, within the Windows firewall configuration. I've seen a number of instances where malware has been detected by AV, but according to the logs, the AV was configured to take no action. As such, as strange as it may seem, the malware infection is clearly visible in the AV logs. In another instance, I was reviewing the on-demand scan AV logs and found an instance of malware being detected. A closer examination of the system indicated that malware had originally been created on the system less than two days prior to the log entries, and I was able to verify that the malware had indeed been quarantined and then deleted. About six weeks later, a new variant of the malware, with the same name, was deposited on the system, and throughout the course of the timeline, none of the subsequent scans detected this new variant. Previously-detected malware can provide valuable clues of an intruder attempting to get their malware on to a system.
In other instances, the malware infection process creates a rule in the Windows firewall configuration to allow itself out onto the network. Finding a reference to a suspicious executable in the firewall configuration can point directly to the malware.
In another instance, the "malware" we found consisted of three components...a Windows service, the "compiled" Perl script, and a utility that would shuttle the collected track data off of the system to a waiting server. The first time that the malware components were installed on the system, within two days, an on-demand AV scan detected one of the components and removed it from the system (as indicated by the AV logs and subsequent lack of Perl2Exe temp folders). Several weeks later, the intruder installed a new set of components, which ran happily...the installed AV no longer detected the first component. This can happen a lot, and even when the system has been acquired, AV scans do not detect the malware within the mounted image. As such, we very often have to rely on other artifacts...unusual entries in autostart locations, indirect artifacts,
The use of artifacts to detect the presence of malware is similar to the use of rods and cones in the human eye to detect objects at night or in low light. Essentially, the way our vision works, we do not see an object clearly at night by looking directly at it...rather, we have to look to the side of the object. AV scanners tend to "look directly at" malware, and may not detect new variants (or in some cases, older variants)
Persistence Mechanism
The persistence mechanism refers to the means that malware utilizes to survive reboots. Some persistence mechanisms may allow the malware to launch as soon as the system is booted, while others will start the malware until a user logs in, or until a user launches a specific application. Persistence mechanisms can be found in Registry locations...during the 2012 SANS Forensic Summit, Beth (a Google engineer) described writing a web scraper to run across an AV vendor's web site, and around 50% of the Registry keys she found pointed to the ubiquitous Run key. Persistence can also be achieved through a variety of other means...locations within the file system, DLL Search Order parsing, etc. Determining the persistence mechanism can be a very valuable part of gaining intelligence from your examination, and detecting new persistence mechanisms (to be covered in a future post) can been equally important.
Mis-Identified Persistence
Sometimes when reading a malware write-up from a vendor, particularly Microsoft, I will see that the persistence mechanism is listed as being in the HKCU\..\Run key, and the write-up goes on to say, "...so that the malware will start at system boot. This is incorrect, and can be critical to your examination; for example, if a user context on a system is infected, but when the system is rebooted another user logs in, the malware is not active.
Sometimes when reading a malware write-up from a vendor, particularly Microsoft, I will see that the persistence mechanism is listed as being in the HKCU\..\Run key, and the write-up goes on to say, "...so that the malware will start at system boot. This is incorrect, and can be critical to your examination; for example, if a user context on a system is infected, but when the system is rebooted another user logs in, the malware is not active.
As you may already see, the persistence mechanism of malware is also an artifact of that malware; persistence is a subset of the artifact set. In many ways, this can help us to a great extent when it comes to detecting malware, particular malware missed by AV scanners.