Inside W32.Xpaj.B’s infection – part 1

Xpaj.B is one of the most complex and sophisticated file infectors in the world. It is difficult to detect, disinfect and analyse. This two-part article provides a deep analysis of its infection.

Xpaj.B only infects files with DLL, SYS, EXE and SCR extensions, and excludes any file if the checksum of its filename appears on a designated list. It avoids infecting files with an overlay, protected files, and files that are no larger than 0x2800. The virus checks whether the executable and 32-bit flags are set, that the COFF magic number corresponds to a 32 bit file, and that the value in the CPU field corresponds to the Intel i386. Only under Windows XP can it infect an executable image for the Windows native subsystem – in which case it avoids infecting files if the checksum of their imported DLL name is 0x36036a24. If it wants to infect this kind of file, it makes sure that the name of the section it inserts its code into is ‘INIT’. In other cases, it avoids infecting files if the checksum of their imported DLL name is 0xE742EA43 or 0x4B1FFE8E.

When infecting a file, the virus first selects a section into which to insert its body and other data. The logic used to select the section is shown in Figure 1. To avoid infecting the same file twice, it checks for an infection marker. The marker is present if the byte sum of the data in the tail of the inserted section is no smaller than 0xfc.

Figure 1. Logic for selecting a section into which to insert code.

Once an appropriate section has been found, the virus chooses some subroutines from the entry point section, stores a copy of them in the selected section, then overwrites the subroutines with its own code. The code is a small stack based virtual machine that is used to locate the address of the ZwProtectVirtualMemory function, then call this API to modify the memory protection of the virtual memory containing the encrypted virus body. It then constructs and executes a decryptor to decrypt the virus body, and constructs and executes a jumper to execute the virus code.

Once the inserted section has been found, the virus computes the size of the space it needs (which is the increased size of the inserted section). It iterates through all the tables (such as export, resource and base relocation tables) in the PE file to be infected, and parses the relevant structures to obtain their RVAs. If the RVAs are bigger than the RVA at the end of the inserted section, it will fix them by adding the relevant size to them. It also fixes the RVAs of the data directories and the entry point if needed (as shown in Figure 2). Then it moves the content behind the inserted section to create the space needed to insert the virus body, the patch structure list, the VM operation structure array and the decryptor (or jumper). It then fills the space with random data, and writes the virus body to the position shown in Figure 3. (It may tweak the virus body prior to writing.) Note that the patch structure list and the VM operation structure array will be written later, the virus body, the patch structure list and the VM operation structure array will be encrypted, and the decryptor and jumper will be constructed by the virtual machine. Finally, the virus updates the relevant section headers and enlarges the SizeOfImage field in the PE header.

Figure 2. Fixing the RVAs of the data directories and entry point.

Figure 3. Section content after the insertion of virus code.

It uses a modified xorshift to compute the positions in order to keep them random (as shown in Figure 3). The modified xorshift is shown in Listing 1.

DWORD xorshift(DWORD given_dword){
  DWORD seed;
  DWORD key_radix;
  DWORD keep_value2;
  DWORD keep_value3;
  DWORD xor_shift_key_array[3];//it will use system time to update this array
  seed = given_dword * 100;
  key_radix = (xor_shift_key_array[0] << 11)^xor_shift_key_array[0];
  xor_shift_key_array[0] += xor_shift_key_array[1];
  keep_value2 = xor_shift_key_array[2];
  xor_shift_key_array[1] += keep_value2;
  keep_value3 = xor_shift_key_array[3];
  xor_shift_key_array[2] += keep_value3;
  xor_shift_key_array[3] = ((((keep_value3>>19)^(keep_value3))^key_radix)^(key_radix >> 8)); 
  return ((xor_shift_key_array[3]+keep_value2)%seed)/(100);
}
Listing 1: Modified xorshift.

Unlike many simple viruses, Xpaj.B doesn’t attempt to execute the virus code by hijacking control when the infected file is started [1]. Instead, it chooses a number of subroutines from the entry point section and stores a copy of them in the inserted section, then overwrites these subroutines with its own code. However, this method does not guarantee that the virus code will execute every time an infected file is opened. To improve its chances of being executed, it redirects some other unrelated calls to point to its own code.

To find suitable subroutines to be overwritten, it collects instruction and subroutine information from the entry point section. The disassembler is used to analyse the instructions of the subroutine, check whether it can be overwritten, and if it can, how many bytes can be overwritten. For the variant I analysed, the second overwritten subroutine is modified by at least 0x36 bytes, the other overwritten subroutines are modified by at least 0x24 bytes, and between two and ten subroutines are overwritten. The number of bytes to be overwritten is between 0x186 and 0x258.

At the same time, the virus saves the original bytes of the overwritten subroutines in the inserted section. It also stores the information from the base relocation table in the overwritten area and rebuilds the base relocation table for infected files to avoid corruption. It uses the structure shown in Figure 4 to log the information about the overwritten subroutines and redirected calls.

Figure 4. The patch_info structure used to log information about the overwritten subroutines and redirected calls.

Note that the subroutines overwritten by the virus are moved to the original_bytes field of the patch structure which is stored in the inserted section and executed from there. For copies to work correctly in the new location, the virus must analyse these subroutines and patch any instructions that refer to blocks of code that have moved [1].

Once the overwritten subroutines have been found, some other unrelated calls are redirected to point to the start address of the first overwritten subroutine, so the chances of the virus code being executed improve significantly. At the same time, the virus updates the patch structure list for the redirected calls.

The virtual machine will execute successfully only from the start address of the first overwritten subroutine – when calls to the first overwritten subroutine (or redirected calls) are made, the virtual machine starts to work and the virus gains control. To make sure the virtual machine can also execute correctly when other overwritten subroutines are called, the following code is added to the beginning of all the patched subroutines:

push ebp
mov  ebp,esp
push reg(random reg, esp and ebp are excluded)
call the address of first overwritten subroutine

The virtual machine’s instructions are written to the remaining space of these overwritten subroutines.

Then the virus encrypts both the patch structure list and the virus body stored in the inserted section.

The virus writes a small polymorphic stack-based virtual machine to the target subroutines. This virtual machine is highly polymorphic and we will take a detailed look at its implementation in the second part of this article, next month.