The Lab handles tens of thousands of suspicious binaries every day. The only way a relatively small group of human researchers can handle such volume is of course with automation. Each sample that is imported into our malware sample management system is scanned, classified, and executed in a virtual environment. Observations are made and we humans analyze collections of like samples.
Malware authors know that antivirus vendors use automation and virtualization to attack the lifespan of their latest variants. (A reason why they produce such a large number of variants each day.) In addition to volume, many malware variants also include virtual machine detection and anti-debugging code, in order to inhibit our research and avoid detection for as long as possible.
Sometimes their anti-debugging efforts are too aggressive to the point of being counterproductive.
Last week I was analyzing a Zbot (aka ZeuS) variant that used multiple methods to detect the presence of a debugger. If a debugger is detected, ExitProcess is called immediately and no malicious code is executed. The anti-debug tricks used in the sample have been known for years but one of them has an interesting side effect.
Here's the assembly code:
First, the RDTSC (Read Time-Stamp Counter) instruction is executed. The timestamp counter is incremented on each clock cycle. The high-order 32 bits of the counter are loaded into EDX and pushed onto the stack. Then Sleep(0x7D0) is called which suspends the execution for two seconds. Finally, RDTSC is executed again and the high-order 32 bits is compared to the value that was saved to the stack. If the values are equal, i.e. EDX gets the same value on both times RDTSC is executed, the sample thinks a debugger must be present. This is based on the assumption that at least 2^32 clock cycles happen during the two seconds so the value in EDX should get incremented.
What all this means is that the sample assumes the CPU runs at over 2GHz. In other words, with a CPU below 2GHz the sample acts as if it is being debugged, aborts execution and does not infect the system. I tested the sample on an IBM T42 (1.86 GHz) notebook and the system was slow enough to avoid being infected.
Another interesting side effect of this Zbot's anti-debugging defense is that any computers it does manage to infect will result in a premium collection of bots. Perhaps the Zbot pusher has discriminating tastes?
It is not impossible for a computer slower than 2GHz to be infected. The slower the CPU, the less likely the infection. Faster than 2GHz is a sure thing. Thanks to @ju916 for the follow up!
