During the audit of an infected host looking for banking malware, we met a Citadel sample, identified by the folders it was stored in: “random” directory names in “C:\Documents and Settings\User\Application Data”, containing the binary, the modules or the configuration file.

However, when submitted in our sandbox, no action appeared in the report. We then suspected the packer, and began studying it, looking for possible anti-VM tricks.
It performs the following checks:

• Call IsDebuggerPresent();
• Compare the name of the main disk with the strings VIRTUAL, VBOX, VMWARE and QEMU;
• Compare the Windows serial number to known sandboxes;
• Check the presence of certain processes used in malware analysis;
• Check the loading of some DLLs used by known sandboxes.

Our sandbox cannot be detected by these methods, the packer was therefore discarded.

The problem was in fact in the malware itself. Indeed, we noticed during the execution the two following checks:

• The malware searches the GUID of the system disk, and compares it to the one present in its .data section
• Then, it also checks if it runs from “C:\Documents and Settings\User\Application Data”, in a subdirectory and with an executable name also stored in its .data section

These two conditions must be validated to analyze in a sandbox a Citadel sample recovered from an infected disk.

Funny detail, viewing the GUID of the disk in binary form in memory, we found that the GUID of internal disks in Windows XP ended with the string mario: