Some malware avoids infecting the system twice by looking for predefined infection markers. For instance, if a particular process, registry key or mutex object is present on the host, such malicious software will assume that another instance of itself is already active and terminate before causing further harm. We could decrease the likelihood of infection by preemptively creating markers known to be associated with malware, effectively vaccinating systems against the specimens.

Using Infection Markers for Vaccination

When teaching malware analysis at SANS Institute, I cover malicious software that doesn't properly run if it determines that it's running in a laboratory environment. On several occasions, attendees and I discussed the notion of configuring a production system to look like a malware analysis sandbox, so that some malicious software refused to execute there.

In addition to fooling malware regarding the presence of security tools, it's possible to deceive some malware regarding the existence of the specimen's infection markers on the endpoint. I came across a paper by Andre Wichmann and Elmar Gerhards-Padilla titled Using Infection Markers as a Vaccine against Malware Attacks, which examines this topic in greater detail. The authors introduce the term infection marker and propose using markers "to vaccinate systems against infections by a specific malware family."

How practical is this approach to preventing infections? Let's experiment with vaccinating a system using Backoff malware as an example.

Mutex as an Infection Marker for Backoff Malware

Software uses mutex (a.k.a. mutant) objects as a locking mechanism to serialize access to a resource on the system. If you're not familiar with this concept, take a look at my earlier article Looking at Mutex Objects for Malware Discovery and Indicators of Compromise.

Backoff malware used a mutex to avoid having more than one instance of itself running on the point-of-sale system, as discussed by SpiderLabs. We might be able to use this information to vaccinate a system against Backoff. To accomplish this, let's first understand how this specimen used the mutex. For this example, I am looking at the D0F3BF7ABBE65B91434905B6955203FE variant of Backoff.

You can use a debugger to see how the specimen uses a mutex. According to the following assembly instructions, the Backoff sample calls the CreateMutex function, supplied by Microsoft Windows, to create a mutex named "nUndsa8301nskal":

CreateMutex returns a handle to the mutex that matches the specified name. Afterwards, the specimen calls GetLastError to determine whether the handle points to the mutex that already existed:

As shown above, the code compares the return of the GetLastError function to the hex value B7. This value, according to Microsoft, corresponds to the symbolic constant ERROR_ALREADY_EXISTS. If the specimen determines that the mutex exists, it jumps to the part of the code (at offset 402E8E) that terminates its own process, deeming that another infection is not necessary.

We could preemptively create the mutex "nUndsa8301nskal" on the system to prevent it from being infected with this Backoff variant. The proof-of-concept tool rapid_env can help with this, as shown below.

Create Infection Markers Using rapid_env

Adam Kramer created rapid_env to rapidly set up "a malware analysis environment based on configuration file specified by the user." This free Windows utility accepts a text-based configuration file that defines which files, registry keys, process names and mutex objects it should generate on the host. To direct rapid_env to create the mutex used by Backoff, I specified the following in the file named backoff-mutex.txt:

mutex:nUndsa8301nskal

Then I ran rapid_env on a clean laboratory system like this:

While rapid_env remained active to maintain the desired mutex object, Backoff terminated on this host without exhibiting its normal malicious behavior. Mission accomplished!

For another rapid_env example, consider how we might fool malware into thinking that it's running in a virtual machine, which is effective against malicious software designed to evade analysis environments. For instance, the following rapid_env config file will direct the tool to create a registry key typically created VirtualBox:

registry:HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\VirtualBox Guest Additions

We can test the effectiveness of this deception using the Paranoid Fish (pafish) tool, which mimics the functionality that malicious software uses to detect the presence of virtualization.

Sure, we could have created the registry key manually, but rapid_env sped up and codified the process. (The tool's sample configuration file shows other ways of fooling Paranoid Fish.)

Overcoming Vaccination Challenges

Attempting to vaccinate systems in the manner described above is overly simplistic for most situations. Many malware samples don't use infection markers at all or generate their values dynamically, instead of hard-coding them into the malicious program. There are other limitations of the proof-of-concept method illustrated by rapid_env; for more details, see Erez Breiman's post on the topic. A tool that can simulate a variety of infection markers, even those that have dynamic attributes, would be necessary to make the concept useful in the enterprise setting. (The product that I oversee at Minerva Labs has this ability.)

Even by itself, such vaccination could be helpful in the context of a specific incident: The incident responder dealing with a marker-utilizing specimen might need a short-term solution to contain the infection. For example, the Nonficker Vaxination Tool imitated the presence of Conficker by creating the worm's mutexes on the system. Such techniques might also help in specialized environments, such as some SCADA or manufacturing systems, that are subjected to a smaller subset of malware threats. Though not applicable to all infections, vaccination can help with some global malware outbreaks and organization-specific incident response scenarios.

Determining whether a given specimen makes use of infection markers would involve performing some analysis of the malicious program in your own lab or by using an automated sandbox. In addition, you can look at the existing threat intelligence feeds and reports to assess whether any of the indicators of compromise (IOCs) mentioned in them could be used as infection markers. Lastly, an open source tool called Mystique, created by Dana Iosifovich, can automatically derive mutex-based markers by integrating with the free Cuckoo sandbox.