Posted by Virus Bulletin on Sep 11, 2014
Aditya K. Sood and Rohit Bansal study the malware's behaviour when ran on a physical machine.
Last week, we published the first part of the paper 'Prosecting the Citadel botnet - revealing the dominance of the Zeus descendent'. In it, researchers Aditya K. Sood and Rohit Bansal looked at the design and implementation of the infamous Citadel botnet, as well as the admin panel used by Citadel's botheders.
Today, we publish the second part of the paper. In it, Aditya and Rohit analyse a new sample of the malware. Obtaining suh as sample wasn't trivial, as the malware targets only certain countries and regions and they had to try various VPN servers in different locations before they were successful.
Then they allowed the malware to install, initially in a virtual environment. However, this failed: rather than connecting to the real command and control server, Citadel made various bogus DNS requests in an attempt to confuse researchers. This behaviour is common in today's malware; we wrote about it in much detail a few weeks ago, when we previewed James Wyke's VB2014 paper.
Although far more cumbersome, there is always the option to run the malware on a physical machine. Once they had done that, the researchers were able to capture the traffic the malware made to its C&C server to download the configuration file, after first making sure it was allowed to do so.
In a move which is not uncommon for modern malware, Citadel contains a separate dropper that removes itself once the actual malware is installed. The malware creates an entry in the registry to maintain persistence following reboots. It performs API hooking to conduct its primary function: man-in-the-browser attacks to steal and alter HTTP requests and responses.
The paper concludes with a signature for the Snort IDS, that should help administrators detect Citadel infections on their network, based on the C&C traffic.