Malware modularization and AV detection evasion
Share |
Published: 2010-05-26,
Last Updated: 2010-05-26 05:41:55 UTC
by Bojan Zdrnja (Version: 1)
6 comment(s)
Modularization of malware is something we have been seeing for quite some time already. Authors of malware often build various modules that allow them to extend functionality of malware but also to make analysis more difficult. The rationale behind this is pretty simple – if this particular infected machine does not need the module that, for example, attacks a certain bank it will not be downloaded and installed. This makes it more difficult for the AV vendors to collect all samples of various modules as the attackers can target them. One example of such highly modular (and heavily protected) malware is certainly Clampi – you can see a series of articles about this malware family posted on Symantec's web site.
The attackers can also use modularization to rapidly change fingerprints of malware – if only one module is detected by an AV vendor, the attacker only has to modify that particular module. And if you've been following our diaries you already know how the AV vendors are lagging behind the attackers.
One very simple malicious file was submitted to us couple of days ago by our reader Tim. He found the file in the /Windows/SysWOW64 directory on his Windows 7 machine. The file was named netset.exe and it wasn't signed, so it immediately looked suspicious to Tim.
However, online malware scanners all happily declared the file safe – when it was initially submitted to VirusTotal it resulted in 0 detections (yes – 0 out of 40 AV programs on VirusTotal, see the report here).
After we received the file, one of the things I normally first use is Anubis, a service for analyzing malware available at http://anubis.iseclab.org/. However, Anubis also said that this file is safe and that it did not do anything suspicious. At that point in time I knew I had to dig manually into the file and this is what it is doing.
While not terribly malicious (meaning, it's not a trojan that will communicate with a C&C), the file is obviously part of another malware. The sole purpose of this binary was to check if the user is running certain AV programs on his machine and, if yes, return that result as the exit code so presumably that other malicious program knows what to do. But the sneakiness around this was interesting.
First of all, the malware has to be started with a command line parameter – it can be any parameter that starts with the letter "s" or "t". If that character was not found, the malware will delete some files (dtnet.exe, plang.enu, dsten.log) and just exit. The code that checks the argument can be seen in the picture below:
If the correct parameter was found, the binary opens the HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Uninstall registry key which holds all installed applications on the system. It then goes through all the subkeys and compares them to the following list: avast, avg, avira, nod32, kaspersky, norton, mcafee, trend micro, comodo. It is now pretty obvious what it does. For any of these, an internal counter is incremented. Finally, when the binary exits the counter is used as the return code so, as I said above, I presume that some other piece of malware uses this to check if there is an AV program running on the machine.
This code is shown below too:
While this file is relatively simple, we can see on this example that the attackers are using those simple tricks to make automated analysis more difficult. Since even emulators such as Anubis, which execute the malware in an isolated environment, will not know which argument it needs, the file will appear to be benign. And judging by the VirusTotal results they have no problems with evading signature based scanning either.
--
Bojan
INFIGO IS