Before talking about “TreasureHunter” itself, I think it’s worth to give you a background about mutex and as Microsoft says:
“For example, to prevent two threads from writing to shared memory at the same time, each thread waits for ownership of a mutex object before executing the code that accesses the memory. After writing to the shared memory, the thread releases the mutex object.”
For a malicious program, this means that we can check for names of mutex objects if we had already examined an infected system.
As Lenny Zeltser , the original author of the original article said:
” Malware authors who wish to employ mutex objects need a predictable way of naming those objects, so that multiple instances of malicious code running on the infected host can refer to the same mutex,”
Zeltser also stated:
“A typical way to accomplish this has been to hardcode the name of the mutex. 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.
“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.”
What was incredible in my point of view is that if you run “TreasureHunter” in different systems you get different mutex objects, making it virtually impossible to detect.
One proof for this is the submitted samples in “Virustotal” and “VxStream Sandbox” where you get a different mutex name.
This new approach used by the malware developed of “Treasure Hunter”, opens the door to new ways of having malware running undetected on systems for much more time.
It will be interesting to see if there will be an evolution of this method.
About the Author Elsio Pinto
Published by Pierluigi Paganini
(Security Affairs – malware, mutex object)