A general ability to predict what domain names could be used by any given variant of Srizbi at any given date could potentially lead to blocking those domains from registration so that the authors of Srizbi would be left out of control of their botnet.
Considering the number of variants of Srizbi and the complexity of its obfuscation technique used by its kernel mode driver, it'd be nice to have a helper tool to get the domain list quicker – so let's get to business.
As Julia mentioned in her post, FireEye analyzed hundreds of Srizbi samples and came up with 55 different "magic numbers" used by all those samples.
That "magic number" is a 4-byte value, which can be considered a unique key for every Srizbi botmaster, a buyer of Srizbi kit, or just a unique key for every new release of Srizbi generation/build, depending on its business model. Every key will produce a different set of domain names. Thus, it allows one botmaster with one key to keep his Srizbi segment independent from the segments controlled by other botmasters.
It's not clear yet if the domain generation algorithm itself varies from one generation to another. For simplicity, let's assume that the algorithm stays the same.
If the algorithm is consistent, it means that it can be replicated in the form of a domain name calculator. All it would have to take on its input is a key (the "magic number") and it would then generate on its output all possible domain names for the different dates – the same way the real Srizbi sample does if it has the same key.
Before we go into the calculation algorithm itself, let's refresh a few approaches that might help to obtain the key from a given Srizbi sample.
Srizbi infection starts from a dropper that creates and then loads a kernel mode driver. As its pretty common these days, the driver uses severely obfuscated code – if you choose to debug it, then it might be a long-long way to get it anywhere near. Once loaded, the driver hides its own file and the associated registry entries via a set of hooks in the kernel structures. For start, it could be easier to run the dropper in the virtual environment of your choice and then locate and dump its driver from kernel memory.
The following image demonstrates how the Rootkit Unhooker tool can be used to locate and dump Srizbi driver (it fails to copy the file because of the hooks).
Please note that Srizbi driver can be found by its name (2-3 random letters, followed by 2 random digits, followed by "sys") and by filesize (about 350Kb).
The dumped driver can now be loaded into the disassembler. It might help to load it as a binary file (not a PE-file) with the loading offset specified as the base address reported by Rootkit Unhooker (e.g. 0xF9686000).
Once the dump is loaded and disassembled, its domain generation algorithm can now be found easily - it's not obfuscated anymore as the driver has deobfuscated itself already.
In order to comment those variable pointers that have their addresses outside the dump, it might help to get back to Rootkit Unhooker and dump relevant memory region as shown below:
On the picture above, an unknown pointer at the address 0xF789C82C in the listing contains the value 0x817863B0 – that address is beyond the scope of the driver dump (it was populated during run-time). By dumping the 32Mb memory region from kernel starting from 0x80000000, and loading it into a hex-viewer, the dump file contents can now be referenced by file offset, e.g. by going to its offset at 0x017863B0 one would clearly see a string "qwerty.." at that offset, thus the string pointer in the assembler listing can now be renamed into a meaningful alias.
Note: the double frame in the picture above indicates the key ("magic number") we’re after.
Having full domain generation algorithm at hand, it can now be copy-pasted into a newly created VC++ project with inline assembler code.
This new code can now be compiled and run in order to generate domain names the same way Srizbi does. The benefit it provides is that it can conveniently be stepped through and studied, it can be modified to use different parameters such as dates and the key itself.
Full source code of such calculator is provided here. It can be compiled with any VC++ builder (from 6.0 and up).
When run, the calculator will generate domain names for all dates in 2008 and 2009. The user of this code can then extend the dates or replace the hard-coded key with a variable controlled by a command-line switch.
Now, let's have a look at the partial listing produced by the tool.
Since 25 till 27 November 2008, there are 4 generated domain names:
- yqsqsqyg.com
- aqiqiqaf.com
- qqrqrqqd.com
- yqgqgqys.com
Let's take a random date in the future – e.g. 15 December 2008. For that date, the domain names in the listing are:
- aqueufor.com
- yqdtdswu.com
- qqrurppp.com
- aqpopied.com
All we have to do now is to black-box Srizbi with the active sniffer on to see what DNS queries it generates in reality.
System date: 27 November 2008:
System date: 15 December 2008:
For both dates the results are consistent with the tool.
It is interesting that the domain name yqsqsqyg.com is already registered to:
Registrant:
Ulugbek Asatopov
Bestekar sokak, 29
ka, 06080
Ankara, AN ---
TR
+9 312 419 90 01
Domain Name: YQSQSQYG.COM
Record last updated 11-27-2008 06:32:39 PM
Record expires on 11-24-2009
Record created on 11-24-2008
Domain servers in listed order:
NS0.DIRECTNIC.COM 69.46.233.245
NS1.DIRECTNIC.COM 69.46.234.245
Thus, someone has registered the domain one day before all Srizbi bots with the same key (which could be an entire segment of Srizbi) started querying it for new SPAM templates. The domain record was last updated on 27 November - the last day when Srizbi bots were still using this domain name. Compelling accuracy, isn't it?
