McAfee Labs Threat Advisory W32/Xpaj

May 11, 2012

Summary W32/Xpaj is a polymorphic file infector virus that uses several methods of code obfuscation and encryption to hide its presence in the infected file. It is able to infect .exe, .dll, .sys, and .scr files. The infection of a file typically increases the file size between 150 KB to 280 KB. It is also able to connect to a command and control server to receive further instructions as part of a botnet. Detailed information about the worm, its propagation, and mitigation are in the following sections:

• Infection and Propagation Vectors • Characteristics and Symptoms • MBR Rootkit Characteristics and Symptoms • Restart Mechanism • Getting Help from the McAfee Foundstone Services team

More information about the malware can be found in the links below:

• W32/Xpaj: Know Your Polymorphic Enemy. http://blogs.mcafee.com/mcafee-labs/w32xpaj-know-your-polymorphic-enemy

• W32/Xpaj Botnet Growing Rapidly

http://blogs.mcafee.com/mcafee-labs/w32xpaj-botnet-growing-rapidly

• Parasitics: The Next Generation. – EICAR http://www.eicar.org/files/eicar_parasitics.pdf

Also known as:

• W32/Xpaj (McAfee) • W32/Xpaj.c (McAfee) • virus:win32/xpaj.a (Microsoft) • W32.Xpaj (Norton)

Infection and Propagation Vectors Virus Propagation As a file infector, W32/Xpaj propagates through infected files copied from one machine to the other. This propagation vector is particularly efficient in corporate networks which often use remote shares to store applications run by its users, and which may allow write access to these shares by the users. It is also capable of spreading through Autorun functionality by creating an Autorun.inf file on removable drives that points to an infected sample copied to the same drive. The most recent variant has been seen spreading through malicious file distributed through file sharing websites. The Trojan files come disguised as a key generator for popular applications, and when executed start infecting files and also install a MBR rootkit in order to persist even a complete cleaning of the machine.

Parasitic Infection W32/Xpaj is one of the most complex parasitic virus found in the wild, often more complex than more well-known parasitic viruses like W32/Virut or W32/Sality. It implements a polymorphic virtual machine that interprets a block of encrypted instructions that in turn are used to decrypt and execute its payload. W32/Xpaj is capable of infecting any EXE, SYS or DLL in the system, including system files and drivers. In order to infect files, W32/Xpaj scan all connected drives looking for files with .exe, .dll, .sys and .scr extensions and perform the following steps:

1. Create a temporary file in %TEMP%. 2. Read the file target file to memory and infect it. 3. Write the infected file to the temporary file (created in step 1). 4. Move the target file to some other temporary name in %TEMP%. 5. Move the infected temporary file (created in step 1) to the original name. 6. Delete the temporary file created with the original file (created in step 4).

As can be seen above, Xpaj does not directly infect the file, but a copy of it, replacing the original file with the infected copy. If the original file is in use, this replacement will be delayed until the moment the file is not locked anymore, usually after reboot. W32/Xpaj is also very aggressive, infecting files as fast as it can read them from disk. This means that it can be very difficult to clean the infection because while the scan and cleaning is being performed, the virus could be still infecting files. Unlike normal file infectors, W32/Xpaj does not steal the Entry Point of infected files. Is also does not add its code to the end of the file changing the Entry Point to its own code like some viruses tend to do. Instead, W32/Xpaj uses a random code block integration technique to infect files. W32/Xpaj builds several code blocks responsible for different functionalities and moves them into random locations throughout the code section of the infected file.

Figure 1: This is what the original code looks like

Figure 2: The same block of code after infection by W32/Xpaj

Its polymorphic decryptor is represented by a number of code blocks linked by unconditional jumps. Once executed, the polymorphic decryptor gains control and performs different tasks:

• Saving the original state of the infected application and preserving all the registers used by the virus • Changing the protection flags of the memory where the virus body is located • Decrypting the virus body • Jumping to the decrypted virus body, etc.

Each task may be located in a separate block of code or combined in one large block. Once decryption is done, control passes to the main virus body, usually located in a different section. Its authors decided to use register-based jumps instead of relative jumps. The following images illustrate two of these functions -- one to add two values, and another to execute an external call that is used by the virtual machine to call API functions and also the virus payload once it’s decrypted:

Figure 3: W32/Xpaj VM code to add two values

Figure 4: W32/Xpaj VM code to call an external function

The stolen code is then stored in an encrypted form (using simple XOR encryption) inside the virus payload block. This virus payload block is then encrypted again using a rolling XOR encryption, explained further down in the document. Because it replaces random functions in the code, there is a chance that this code will never be triggered by normal execution of the application. In order to prevent that, W32/Xpaj then replaces random CALL instructions throughout the code, pointing them to its own code. This increases the chances of the malicious code being executed, but does not completely prevent it. There are some occasions where the virus code will never be executed. It also means that sometimes the virus will only be executed when a specific function inside the application is executed (for example when a menu is accessed or a button is pressed). This random nature of the infection process, together with the polymorphic code and heavy encryption used, makes it very difficult even to identify files that have been infected by the virus. Once the virus virtual machine code is executed, it will decrypt the virus payload, which is usually located in another section of the file. The virus will read the VM instructions from this data block, and use this information to create a block of code that is in fact a second level decryptor. Once this decryptor is created, it will be called and will decrypt the entire block with the virus payload. This encryption uses a “rolling XOR” algorithm where the XOR key is combined with a second constant key for each iteration of the decryption. The image below describes this code:

Figure 5: W32/Xpaj second level decryptor

Once the decryptor finishes, control is passed to the virus payload, which will implement the malicious features described in the ‘Characteristics and Symptoms’ section below, such as:

• File Infection • Command and control server communication • Download further malware • Click Hijacking from user navigation • Autorun spread

The table below depicts the Xpaj payload organization:

VIRUS PAYLOAD

STOLEN CODE TABLE

VIRTUAL MACHINE BYTECODES

2ND LEVEL DECRYPTOR

Figure 6: W32/Xpaj payload structure

The stolen code table contains information about the original location of the code, the type of code that has been stolen (code block of function call), its size, and the encryption key used to decrypt it:

.data:1003B374 dd 0E5D6F2h ; Table entry key

.data:1003B378 dd 0E5D6ACh ; Table entry size

.data:1003B37C dd 0E4A937h ; offset Start

.data:1003B380 dd 0E4A904h ; offset End

.data:1003B384 dd 0E5D6CCh

.data:1003B388 dd 0E5D6F2h ; key

.data:1003B38C dd 0E5D6ACh ; size

.data:1003B390 dd 0E5D6D2h ; EOR marker

.data:1003B394 dd 62F63671h ; Stolen code starts .data:1003B398 dd 62AF1E7Bh

Once its payload has been executed W32/Xpaj will execute the original function that was replaced by the virus code. This code is encrypted with another layer of encryption, but this time it’s a simple XOR encryption. One big difference from W32/Xpaj compared to other file infecting viruses is the fact that it never restores the original code to its original position in order to execute it. W32/Xpaj relocates the code to its own payload area, and executes the code from there. Any relative references within this code, like relative jumps and calls and address pointers to data, are also changed to point to their original destinations. This makes it a big challenge to clean files infected with W32/Xpaj, because the original code is only available after all the encryption layers have been removed. It is also a challenge because the relocations done by W32/Xpaj needs to be reverted, changing the code to point to relative jumps and calls at their original positions. Finally, the relocation table for the entire executable needs to be rebuilt to return the file to a consistent state, and the header must be updated to reflect any changes in import and export table locations. It has come to our attention that recent variants of this malware have been implementing another layer of encryption over the ones described above. This new variant was discovered in the wild in March 2012 in the Asian-Pacific area.

Figure 7: Xpaj infections

Mitigation W32/Xpaj infections are difficult to remove due to the aggressiveness with which the virus infects files. In order to attempt to avoid infections, the following mitigation measures may be helpful:

• Disable Autorun features on windows, especially in mission critical servers • Restrict remote shares to read only for normal users whenever possible. In case write access must be

given, restrict this access to folder which does not contain executable files • Avoid using the Administrator user for normal day to day operation. Although this might not avoid

infections, it may contain the infections to some user files only, avoiding a more complex infection of system files.

• Enable VSE rules to avoid execution of files from the %TEMP% folder. This will avoid Xpaj copying executable files to the %TEMP% folder.

The following VSE rules can also be enabled to help avoiding infections on McAfee files:

• Ensure that Access Protection is enabled • Ensure that the option to ‘Prevent McAfee Services from being stopped’ is enabled • Enable McAfee-specific options in the ‘Common Standard Protection’ rule categories • Prevent modification of McAfee files and settings • Prevent modification of McAfee Common Management Agent and settings • Prevent modification of McAfee Scan Engine files and settings

To assist with creating rules in the VirusScan 8.5i or later console to protect your systems against autorun infections, here are three articles in our Knowledgebase:

• How to use Access Protection policies in VirusScan 8.5i or later to prevent malware from changing folder options (KB53356)

• How to use Access Protection policies in VirusScan 8.5i or later to protect against viruses that can disable Regedit (KB53346)

• How to use Access Protection policies in VirusScan 8.5i or later to protect against viruses that can disable Task Manager (KB53355)

Use the existing VirusScan Access Protection Rules to stop autorun worms.

• In the VirusScan console – Access Protection – category: Common Maximum Protection. Enable this rule to block: Prevent Programs registering to Autorun.

• In the VirusScan console – Access Protection – category: AntiVirus Standard Protection. Enable this rule to block: Prevent remote creation of Autorun files.

Once an infected machine is identified, it might be difficult to completely clean it. In order to improve the chance of cleaning quickly, the following actions may help:

• Enable user-defined rules in VSE to deny writing access to any EXE, DLL, SYS and SCR files in the file system. Put exclusions to enable VSE to clean files

• Enable rules to avoid creation of files with .TMP extension in “\windows\temp” and “\documents and settings\username\local settings\temp” or equivalent folder in other windows versions. Put exclusions to enable VSE files to be able to clean files in TEMP

• Disable System Restore prior to executing the On Demand Scan • Perform an On Demand Scan, followed by another On Demand scan, to enable the cleaning of files in use.

Reboot immediately after the second ODS. DISCLAIMER: The rules above restrict the system to avoid Xpaj infecting new files while the scan is being executed. They may cause issues with normal Windows operation, so they must only be used in case of an outbreak, and only during the cleaning process. Please disable the rules as soon as the system is confirmed clean.

Characteristics and Symptoms Description Upon execution, the virus will start a thread to infect files and another to perform its botnet operations. In order to avoid multiple infected files from running the malicious code at the same time, the virus will perform the following actions:

• It injects a monitoring thread in svchost.exe and explorer.exe

• It creates the following files which are markers of infection:

C:\WINDOWS\icw.ifs

C:\WINDOWS\sqd.cxr

• It may create one or more mutexes with random names like the one below:

\BaseNamedObjects\gxdbeazrjj

It has been observed that W32/Xpaj uses the privileges of the current user during infection. As a result in some cases file privileges were modified rendering files unusable. The reason for this is the infection process of W32/Xpaj. W32/Xpaj typically creates a copy of the target file in the %TEMP% folder (the file it intends to infect). It would then infect the copy, following which it would replace original file with the infected copy. Since it creates a new copy of the original file, the copied file inherits the privileges of the infector process (which may be different from that of the original target file). After infection, once the original file is replaced with the copy (also now infected), the file has modified privileges as compared to its original settings. As a result, users may not have rights to access the file anymore and the next time the file is attempted to load or run, it may complain that the file does not have the correct privileges or may deny access to the file. The image below illustrates a case where Internet Explorer files were infected and had their permissions changed. We can see that the permission that allow common users to access the files were removed, rendering the files inaccessible to any user on the system, even the Administrator:

Figure 8: Differences in ACL permissions for infected file

Mitigation To fix the permissions issue described above, the user may perform a manual operation to restore the file permissions. The following are some options. Remediation

o Manual instructions to restore the file’s permissions are as follows: 1. The On-Access or On-Demand logs will contain a list of files that have been detected as infected

by W32/Xpaj. Use this list to identify possible files with file permission problems. 2. Open Windows Explorer as Administrator and right-click the icon for the affected file(s). 3. Click into “Properties” to access the file properties. 4. Under the “Security” tab, click “Advanced”, then “Owner”. 5. Choose the Administrator as Owner (or some user with Administrator privilege). 6. Click OK when prompted to apply changes. 7. Return to the Security tab under “Properties” again. 8. Click “Advanced”, and select “Inherit from parent the permissions entries that apply to child

objects”. 9. Click OK when prompted to apply changes.

Reboot the infected machine to restart all critical services.

o Additionally, a custom Stinger tool is provided by McAfee Labs upon request to restore modified NTFS permissions. You must run the Stinger tool with a user account with Administrator privileges. It will restore the original NTFS permissions to allow programs to be loaded.

Network-based infection W32/Xpaj is able to spread over network shares by exploiting open shares with null password. Once the infection of local computer is complete, W32/Xpaj will search the local network for any computer with shares. In order to do that, it will connect to the $ADMIN share of the target computer, and will enumerate the shares in the remote system. For each share available, W32/Xpaj will attempt to access the content in read/write mode. If the folder is shared with read/write access and enabled for any user to connect remotely, W32/Xpaj will start to infect all possible files in the remote system. It is important to remember that even computers that does not have visible shares may have administrative

shares like $C which are created automatically by the system. Mitigation

• Ensure that network shares are set to read only whenever possible. • For machines that do not need to share files in the network, disable the File and Printing service. • Ensure only authenticated access is enabled for network shares.

Command and Control Connections W32/Xpaj uses a Random Domain Generation algorithm to generate the domain names it will contact in order to receive instructions. Due to the nature of this algorithm there would be no merit in listing the domains previously observed because they are generated based on the current time. An example of the domains used in the past is listed below. Please be aware that this is not and extensive list, but just a small example of how random the domain names may appear:

• srcrwybsfh.com • yrgdvp.com • rsspurprzt.com • evnneaor.com • mtepfol.com • aukortmv.com • pydhqeqzlr.com • qkdtyzzeucu.com • vbwnmg.com • qdmjwq.com • njdouxhzdix.com • fbmzwmt.com • kcqelsvtufw.com

There are some domains however that are contacted first to report the infection and receive the initial instructions:

• infoserv52.com • updateserv74.com • nortiniolosto.com

The following IP addresses have been observed resolving to the DNS names used by W32/Xpaj:

• 92.242.132.8 • 184.22.118.16 • 174.132.193.90 • 207.46.232.182 • 207.46.197.32 • 208.91.198.30

The HTTP requests sent to these servers might look like the examples below:

GET /RpF0qM6fv?hwcaaRhsTMBsSsnG=JjsGPMDwvwOepXe&dPbUEsQTWJWMglng HTTP/1.1 Host: azonos.com User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Pragma: no-cache Cache-Control: no-cache Connection: close

POST /G50M02io?bYpYjXdnUwgEkrSA=MOnFCiSdYQjrmF HTTP/1.1 Host: azonos.com Content-Length: 414 Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727) Pragma: no-cache

Cache-Control: no-cache filename=ybb.pok&data=<encrypted data>

Once the command and control served is reached, W32/Xpaj will download instructions on which activity it must perform. It is known that W32/Xpaj works as part of a click-fraud scheme, using the infected machines to generate traffic at pay-per-click websites in order to generate cash for the botnet owners. It is capable of downloading and executing other malware files downloaded from different locations. This might enable the botnet owner to compromise the machine further with other malware. It has been observed that the latest variant of W32/Xpaj is downloading a PWS-Zbot variant known as Citadel to infected machines. More information about PWS-Zbot can be found in the URL below:

• https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/23000/PD23030/en_US/McAfee_Labs_Threat_Advisory_PWS_ZBot.pdf

It is also capable of sending information about the machine back to its owner like OS and machine information and data about the logged on user. Mitigation Block network communication to the above mentioned IP addresses and domains using a firewall.

MBR Rootkit Characteristics and Symptoms Description The most recent variant of W32/Xpaj came with a new feature which made it more complex than before. The malware is being distributed through a trojanized key generator distributed in file sharing websites. One of the Trojan files we have seen have the following icon:

We detect the Trojan files as W32/Xpaj.dr.a and W32/Xpaj.dr.b. The rootkit infection is detected as W32/Xpaj!rootkit. Once executed, the Trojan will try to elevate its privileges if not running as Administrator. It is able to bypass the Consent.exe application used in Windows 7/Vista that ask the user for permissions to run the application as Administrator. This way, the user is unsuspecting that the application is run at elevated privilege. After gaining the privileged access, the Trojan will install an MBR rootkit which allows it to survive reboots and even a reinstall of the Operating System. Once the rootkit is installed, the Trojan will start to infect files with the new W32/Xpaj variant as explained before. It is important to understand that the Trojan file itself is not infected with the virus, but contain a standalone code to start the infection. The standalone code uses the same code structure as W32/Xpaj, which points to the same author for both cases. In order to infect the MBR, the rootkit will make a copy of the current MBR to the last minus 1 sector of the disk. The original MBR will then be replaced with the malicious code. The rootkit also create some files in this area at end of disk, and store there a copy of the dropper along with some configuration files. This allows it to restart the infection in case the machine is cleaned. The disk structure would look like this:

INFECTED MBR

DISK CONTENT

“ARCH” marker + encrypted content

… …

“ARCH” marker + encrypted content

ORIGINAL MBR LAST SECTOR

The rootkit files stored at the end of the disk are encrypted and they start with a magic marker with the text “ARCH”. They contain the rootkit configuration files, and a copy of the dropper. The rootkit code will be executed during boot time, and will wait for Windows kernel to be loaded before hooking some important routines in the kernel. The following routines are hooked during boot time and can be detected by analysis tools like GMER:

• PAGE ntkrnlpa.exe!NtReadFile 80570618 5 Bytes CALL 89C4E158 • PAGE ntkrnlpa.exe!NtWriteFile 805710B6 5 Bytes CALL 89C4E24A

Other API functions are hooked during the system use, but they are unhooked as soon as they are not needed anymore. This makes the rootkit very stealthy to detect. The two functions that are hooked persistently are used to protect the virus files stored at the last sectors, to avoid any application from accessing or overwriting them. After hooking the Windows kernel, the rootkit will extract a copy of the dropper from its encrypted area, and execute it, starting the infection process again. Mitigation The following mitigation measures may help avoid infection by this threat:

• Avoid running any unknown application, especially software download from non-official locations, cracks, keygen or other pirated software.

• Enable hardware protection for MBR. Some motherboard BIOS allow the user to mark the MBR as read-only. This may protect against MBR rootkits like this.

Restart Mechanism Description Like any file infector, all infected files are capable of infecting other files upon execution. This includes files in remote shares or removable drives, which may help W32/Xpaj to spread to other machines in the same network. W32/Xpaj is also capable of creating autorun.inf files in removable drives, pointing to an infected file in the same drive. The new functionality for MBR infection is also a restart mechanism Mitigation A Stinger is available for detecting infected files in cases where the machine cannot run the On Demand scan. Please restore infected files from a backup until cleaning is provided.

Getting Help from the McAfee Foundstone Services team This document is intended to provide a summary of current intelligence and best practices to ensure the highest level of protection from your McAfee security solution. The McAfee Foundstone Services team offers a full range of strategic and technical consulting services that can further help to ensure you identify security risk and build effective solutions to remediate security vulnerabilities.

You can reach them here: https://secure.mcafee.com/apps/services/services-contact.aspx

© 2011 McAfee, Inc. All rights reserved.