W32.Xpaj.B is a File Infector with a Vengeance

We have recently come across a new wave of W32.Xpaj.B samples. We first met this complex file infector virus in 2009, and since then the threat has been operating and mounting an ad-clicking scam in order to generate revenue.

After a few months of rest, the threat seems to be back.
 

Figure 1. Increase in activity of W32.Xpaj.B in the wild, the spike is from January 22, 2012

It also appears to contain new weapons in its arsenal as the threat can now also perform the following actions:

This is not entirely unexpected: kernel mode code was already present in the old version of the W32.Xpaj virus, but it was inactive. In October 2011, I gave a presentation at the Virus Bulletin conference about the analysis of this file infector virus wherein I pointed out how the threat contains code that can potentially run in kernel mode. I also suggested the possibility that future versions of the virus may shift to kernel mode.
 

Figure 2. Inactive kernel mode code from the old W32.Xpaj.B variant

It is now about six months later and the malware authors have not disappointed us!

We should clarify two points:

  • no 64-bit executable or .dll has been observed to be infected
  • no 32-bit or 64-bit driver has been observed to be infected

Even if the virus targets 64-bit Windows computers, the infection seems to be limited to 32-bit executable modules only. The same goes for the drivers: the old version of the virus did not infect kernel mode drivers, nor does the new one. Therefore, the kernel mode code is not the result of infected drivers, but it is only loaded through the infected MBR, both in 32-bit and 64-bit Windows.
 

Figure 3. The presence of the virus compressed entry in the kernel memory in the top right (which contains an executable), and in the bottom you can see a hook on the kernel API NtWriteFile (this test was performed in 64-bit Windows XP)

These are only the results of a preliminary analysis, investigation is still ongoing to fully understand the new functionality of this variant.

Interesting patient zero of the pandemic

The sample we analyzed is the one that was described in BitDefender’s blog (md5: d5c12fcfeebbe63f74026601cd7f39b2). It turned out to be a pretty interesting sample: normally we receive files that are legitimate executables (or executables of any kind) that have been infected by W32.Xpaj.B. In this case though, the sample is not an infected executable, but it seems to be an executable that was created specifically to contain only the W32.Xpaj.B infector code. The difference with normal W32.Xpaj.B infections is pretty obvious:

This sample Normal W32.Xpaj.B infected sample
  1. The viral body is buried under a layer of PECompact 2 packer
  2. The viral body begins with a small loader
  3. The .exe file contains only the virus body and some fake data and strings
  1. The viral body is in the outer layers of an executable
  2. The viral body begins with a stack-based virtual machine
  3. The .exe file contains the virus body and the original executable code and data

 
So, in short: this .exe file was manually crafted in order to contain the virus body, as well as some fake strings and data that mimic some legitimate executable files. A loader was then added to the entry point of the .exe file in order to decrypt and load the virus body (and this loader is different from the one you would normally see in an infected sample). Finally, the .exe file has been packed with PeCompact 2.

Could this just be the structure of the new variant? No. Besides the fact that there is no original executable code or data aside from the virus body, once run, this sample does generate normal W32.Xpaj.B infections. This sample is one of a kind. In fact, we believe that this could be the “patient zero” of the new infection: the sample that was manually created and spread by the malware authors themselves.

Wolf changes its coat, but not its ways

The whole behavior of the virus seems to be the same as the old one: when run, it contacts the domain nort[REMOVED].com, which at the moment resolves to an IP address located in the Virgin Islands. The network communication seems to be similar to the old variant.
 

Figure 4. HTTP POST request of an old sample (top) versus one from the new sample (bottom)

The data is encrypted, the URL pages and parameter names look like randomized strings, the data begins with a string indicating a randomly name file, etc.

It is likely that the purpose of the virus is still the same: an ad-clicking money-making scam. Investigation is ongoing.