Some malware avoids infecting the system twice by looking for predefined 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.
Using Infection Markers for Immunization
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.
I recently discovered 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.”
This approach, when it works, carries minimal performance overhead, but is it practical? Let’s experiment with this technique 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 uses 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 immunize a system against Backoff. To accomplish this, let’s first understand how this specimen uses the mutex. For this example, I am looking at the D0F3BF7ABBE65B91434905B6955203FE variant of Backoff.
You can use a debugger such as OllyDbg 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 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:
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. For instance, the following rapid_env config file will direct the tool to create a registry key typically created VirtualBox:
registry:HKEY_LOCAL_MACHINESOFTWAREOracleVirtualBox 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.)
Dynamic Marker Identification for Better Immunization
Attempting to immunize 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. However, this approach could be used in conjunction with other anti-malware methods to strengthen security.
Even by itself, such immunization 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.
A more reliable immunization approach could entail anti-malware software that automatically identifies and generates potential infection markers on the fly. The tool could examine suspicious executables using emulation, static analysis or behavior analysis techniques and create the markers before allowing the programs to run. This approach would be useful when the tool is uncertain whether the examined file is malicious. Blocking it unnecessarily could disrupt and annoy the user; however, creating markers just in case the program turns out to be malicious offers a low rate of false positives. In an enterprise environment, the analysis could be performed away from the initially-infected system, with the hope of deploying markers to other hosts before they got infected.