Malware analysts have had a measure of success using static mutex values as a fingerprint for detecting and blocking malicious code.
These values are used in programming to enable software to synchronize communication between multiple threads or processes, or to determine whether another instance of a program is running already. There’s better reliability in using a mutex object in this way than checking for the presence of a process name, which could change.
Malware writers, however, may have caught on to this fingerprinting technique.
Lenny Zeltser, a SANS Institute instructor, said a malware sample he was examining dynamically generates the name of a mutex object by using the product ID associated with the software, lessening its predictability and complicating detection.
“Given that malware analysts know to look for mutex names for ‘fingerprinting’ malicious software, it’s natural that authors of such programs will start shifting their techniques,” Zeltser said. “The technique that this malware used to generate the mutex name wasn’t especially elaborate, but it made it harder for the defenders to use this attribute for defending or investigating the system.”
Malware evasion techniques are the epitome of the cat-and-mouse game between hackers and researchers. The LogPOS point-of-sale malware is a recent example of the constant evolution on the attackers’ side. The malware makes use of a Windows technology called mailslots to create a webserver; additional code is injected into various processes and acts as a client that moves stolen credit card data to the mailslot which then sends it to the attackers’ command and control infrastructure.
Last October, academics at the University of California at Santa Barbara, made a plea for defenders to begin working on technology that spots evasive behavior. Security systems, said Giovanni Vigna, director of the Center for Cybersecurity at UCSB, must eventually elicit malicious behavior from malware before it executes.
“The dynamic of action-reaction is common in the world of information security: The defenders find a way of interfering with the attackers, the attackers adjust tactics, the defenders tweak our methods, the attackers react, etc,” Zeltser said.
The sample Zeltser studied a malware sample called TreasureHunter and today in a post on the SANS Internet Storm Center website, he describes how the malware transforms a computer’s specific Windows Product ID into a string that serves as the basis for its mutex.
Not all malware samples make use of mutex objects, but those that do until now have hardcoded the name. Backoff, probably the most notorious point-of-sale malware in the wake of the mega Target and Home Depot breaches, named their mutexes in ways that were known to incident responders, Zeltser said. This scenario simplified detection for malware analysts, enabling them to use mutex names as indicators of compromise for Backoff infections, he said.
For an attacker, the use of a static, hardcoded mutex name, also allows multiple instances of malicious code running on the infected host to refer to the same mutex, Zeltser said. TreasureHunter, he said, is the first time he’s seen malware move away from this static approach.
“The author of TreasureHunter decided to use a more sophisticated approach of deriving the name of the mutex based on the system’s Product ID,” Zeltser explained in his post. “This helped the specimen evade detection in situations where incident responders or anti-malware tools attempted to use a static object name as the indicator of compromise.”
