My next class:

Malware modularization and AV detection evasion

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:

Argument test

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:

AV test

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

 

 

6 comment(s)
My next class:

Comments

With respect to "AV vendors lagging behind attackers", in http://www4.symantec.com/Vrt/wl?tu_id=SUKX1271711282503126202 (PDF) on page 48 one can read:

"Signature-based detection is lagging behind the creation of malicious threats - something which makes newer antivirus technologies and techniques, such as behavioral-based detection, increasingly important."

(Source: http://lists.grok.org.uk/pipermail/full-disclosure/2010-May/074555.html).

Does anyone know of an overview/comparison of white-listing software that integrates with MS Windows?
Actually, this "component" arguably should not be flagged, as by itself it has no malicious intent.

Perhaps it is a utility distributed by you ISP that is used to warn you if you have no virus checker installed?

I certainly would not want a virus checker to remove a file just because it was once part of a virus. The virus author may have got "borrowed" the component from some other legitimate source.

Flagging it as an unsigned binary in a Windows system directory seems like a great idea. But I wonder how many false positives this would generate?
Greg, while the file is not extremely malicious, it does automatically try to delete 3 files (dtnet.exe, plang.enu, dsten.log - as I wrote in the diary).

So, I still believe that AV vendors should detect it. Also, if it was a part of any other malware, I believe that, when cleaning, AV programs should remove *all* components.
I agree with Bojan. BTW very nice analysis of this issue/scenario. Thanks for sharing.
Can you get the other binaries and see what the whole package might do? sneaky little anti-analysis/anti-debugging routine there. I'd be more impressed if it encrypted those files before deleting them, making recovery tougher.
I've asked the reader to send the whole package if he manages to acquire it -- if we get it I'll certainly analyze it and post another diary if I find something interesting and diary worthy :)

Diary Archives