- Apr 25, 2013
- 5,355
A new approach based on windows products IDs for dynamic mutex could allow the creation of new malware running undetected on systems for much more time.
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.
Virustotal:
C:\DocumentsandSettings\<USER>\ApplicationData\3ed1ed60c7d7374bf0dd76fc664b39cd\jucheck.exe
VxStream Sandbox:
C:\Users\PSPUBWS\AppData\Roaming\3ac22cadc45e0558cad697d777f6c3d3\jucheck.exe
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.
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.
Virustotal:
C:\DocumentsandSettings\<USER>\ApplicationData\3ed1ed60c7d7374bf0dd76fc664b39cd\jucheck.exe
VxStream Sandbox:
C:\Users\PSPUBWS\AppData\Roaming\3ac22cadc45e0558cad697d777f6c3d3\jucheck.exe
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.
