May 6, 2013 at 10:53Rootkit Avatar: A Detailed Analysis
In February 2013, information appeared about the new Avatar rootkit , which, apparently, originates from one of the underground forums. In particular, a description of its capabilities was published on the pastebin service . Information about the new rootkit was hotly discussed in the security community, since the described features of this rootkit were really impressive. Among them, for example, the ability to download drivers without the participation of a hard disk, infection of OS boot-drivers, new botnet protection schemes and others. It also claimed to bypass several security / AV products and well-known anti-rootkits.
When we found the droppers of this rootkit, we immediately began to analyze it. I must say that we added it to the database as Win32 / Rootkit.Avatar . ColleaguesAnton Cherepanov and Alexander Matrosov performed a detailed analysis of this rootkit, its payload and basic capabilities.
In March, our anti-virus lab discovered two droppers that interacted with different C&C servers and had different compilation dates.
As mentioned in the announcement, Win32 / Rootkit.Avatar contains a driver infector, but in addition, it uses this technique twice: firstly in the dropper to bypass detection from the HIPS and secondly in the driver to survive after a reboot. In the first case, the advantage of loading the rootkit driver directly from kernel mode using the standard OS driver is used, and in the second case, the rootkit ensures its launch after reboot. Of course, this tactic has drawbacks in terms of violating file integrity and integrity control by verifying digital signatures for drivers, so the rootkit can only work on x86 systems.
Droppers
Avatar uses a multi-layer dropper approach. The first level dropper performs decompression (LZMA) for the second level dropper and driver. In fact, the second-level dropper and the driver itself are unique files generated each time when unpacking, since the initial dropper generates random names for mutexes and events that are used in their code and performs these modifications directly in the body of each module. The initial dropper uses an interesting trick as an anti-debugging tool, it is based on comparing the time from the KUSER_SHARED_DATA.InterruptTime structure (KUSER_SHARED_DATA is located on the page, accessible both in user mode and in kernel mode). Malicious code modifies an RtlDispatchException function callinside another KiUserExceptionDispatcher function . The next step generates an inclusion and control passes to the desired exception handler.
In this case, the current time for measurement is taken from KUSER_SHARED_DATA.InterruptTime and then compared at subsequent stages of execution. This mechanism allows detecting emulation and debugging of dropper code.
The second-level dropper checks the environment for virtual machines, and fairly well-known checks are used for this. Before executing the code responsible for checking on the VM, the dropper decrypts it using the “explorer” key.
In the next step, the dropper checks the OS version and current privileges. In this case, two methods of privilege escalation are used:
The process of infecting the system with a dropper is shown in the diagram below.
The exploit for the MS11-080 vulnerability uses code similar to the exploit code from the Metasploit Framework , but with some minor changes. After checking the afd.sys driver version, the dropper uses the following code for operation.
The following screenshot shows the code that, using IOCTL 0x000120BB, calls the afd! AFDJoinLeaf function to rewrite the pointer in the HalDispatchTable to the desired rootkit function.
After successful operation and transfer of control to the shell code, it initiates the download of the rootkit driver.
In fact, the rootkit driver is not stored on disk as a separate file, but is loaded from the memory buffer. Below is the call graph for the function that loads the driver.
After successfully elevating privileges, the malicious code searches for a suitable driver for infection in the% WINDIR% \ system32 \ drivers directory. After the infection has been completed, the driver entry point ( GsDriverEntry ) is modified to execute malicious code (stub). The modified entry point is as follows:
One of the main tasks of this stub is to connect to the execution process of the second level dropper and read the body of the rootkit driver into memory. The stub code is shown in the figure below.
After a successful infection, the modified driver copies itself to the% TEMP% directory and tries to load itself using standard OS mechanisms (via the service control manager or directly through ZwLoadDriver ).
Thus, the Avatar rootkit driver file is not really stored on the hard drive, but will be loaded with code that is called by using MS11-080. Such a rootkit boot method, using the system driver infection, is an effective method of circumventing HIPS and allows loading another kernel-mode module from a trusted system driver.
Driver
After the driver is successfully loaded into memory, the malicious code infects the system driver in order to ensure its survival after a reboot. A special algorithm is used to select the desired driver. At the same time, Avatar randomly selects a driver and checks its name against the blacklist specific to different versions of the OS.
The execution flow of the infected driver code occurs according to the following scenario:
1. A stub is executed at the entry point.
2. Then the Pnp Notify callback function is installed for the GUID_DEVINTERFACE_DISK class, in which the driver body will be loaded from the hidden rootkit file system. A similar technique was observed in TDL3 , TDL4, and Olmasco (MaxSS / SST).
3. The source bytes of the entry point are restored.
A rootkit driver can infect several system drivers without changing the original size of the original file.
Avatar uses an interesting trick to discover the virtual machine environment. It calls the nt! MmMapIoSpace function to read BIOS data at 0xF0000 and checks for the following lines:
Also in the code there are additional checks for KVM and Hyper-V using the already known tricks of the CPUID instruction.
Hidden FS is used to store user mode payloads and auxiliary files. All files are encrypted using a symmetric algorithm. Below is a call graph for a function that works with hidden FS.
There are special attributes for files stored on hidden FS.
Malicious code allows downloading from the network and further execution of additional payload in the form of user-mode and kernel-mode modules. This payload is also stored on a hidden FS. Win32 / Rootkit.Avatar does not store any of its components on an NTFS volume, except for an infected system driver. This combination of a hidden, encrypted FS, along with an infected system driver makes it more difficult to use conventional forensic techniques to investigate Avatar infections.
To implement the user mode payload, the KeInitializeApc function is used to initialize the APC object, which is then used to execute the required rootkit function.
Payload
The payload of the Avatar rootkit modification under study is not original. Key features:
While examining this modification of the rootkit, we noticed that the payload in the form of avcmd.dll was introduced into the svchost.exe system process. This module is responsible for working with C&C, whose IP addresses are stored in the configuration file. This file has the following structure.
Examples of decrypted configuration information from two different droppers are given below.
For botnet with identifier BTN1.
For botnet with identifier NET1.
In order to protect interactions with C&C, Avatar uses its own base64 encryption algorithm. At the same time, all network interaction in user mode is carried out using the usual WinInet API functions.
Avatar also has an additional way of communicating with C&C if you are having problems using other methods. He tries to search for messages in Yahoo groups using special parameters.
A sequence is searched based on the following parameters (in our case, these are 17BTN1 and 17NET1).
After these lines are connected, the received byte sequence is encrypted using its own algorithm using the 1024-bit key from the configuration file.
Key = BTN1 6mQ98EXP3v7TKMdk704uOUzGqvikuoHt98n8IPp4K19
a3qyZ96LoOc54sb3g9eJVyAs7VmPxQjkkM9R960ev275K24PQ550K1
9fNk8305jRDUTb4cEut4579Zg9i32qU
NET1 key = E623J5XKJ9NF4bseM5J2nkwhs1K2766DUOMUDSee3c
7xu06Q9QayV61U4fm5H89ppuNgLt9M5D2XTCLcd0aS3m9CO1aZg9h9
o2zb2EIC437IU3X1P3ec07481E0j2Tdr
After encryption is applied to the received sequence and then base64 characters are translated to the upper case, while some characters are filtered out. An example for a botnet with identifier BTN1 is shown below.
SymFilter (UpperCase (Base64 (Encrypt (17BTN1)))) = EZTFDHWP
The string EZTFDHWP is used for the subsequent search query for the Yahoo group. If such a request is successful, the next step is to check the numbers of the found group and read its description data.
The group description is then encrypted using RSA and a 1024-bit private key. Such data can be decrypted by knowing the public key stored in the configuration file. We believe that this information can be found in encrypted messages used to return control to the botnet in the absence of active C&C servers.
After finding this function, we checked possible such messages on Yahoo Groups. One group was found that matched the specified parameters (11BTN1 = EFS9KHRF). The search query looks like this:
hxxp: //groups.yahoo.com/search? query = EFS9KHRF & sort = relevance
It can be seen that the encrypted message is present in the description of this group.
We decrypted this message using the RSA-1024 key found in one of the configuration files. The key to the configuration file with the botnet identifier BTN1 was used.
dZ8FsJ4z0 :: http: //www.avatarbut.info www.avatarsbut.info
This information is similar to one of the URLs for C&C that we saw in the BTN1 configuration file itself. It seems that this group was used by cybercriminals to run around this mode of interaction, since it includes information from the configuration file itself.
Such a botnet support scheme using message in Yahoo groups provides excellent protection against botnet synching attempts, because the C&C server domain information is encrypted using an asymmetric RSA-based encryption algorithm. During the research process, the scammers can only extract the public key for decrypting messages, but this key cannot be used to encrypt new messages and create dummy groups.
Avatar Runtime Library
Malicious code Win32 / Rootkit.Avatar has a special API for developing auxiliary components. The use of this API is based on the Avatar Runtime Library and a special SDK that describes the development of additional user-mode modules. These modules can also interact with the rootkit driver. The Avatar Runtime Library includes the following APIs:
The payload storage structure that will be embedded in the processes looks like this.
After analyzing the Avatar SDK, we concluded that this project was developed by fairly qualified developers. Obviously, the developers of the malicious code have been working on the rootkit code for at least six months in order to test the basic functionality and ensure the necessary stability of the kernel mode component.
Conclusion
The Win32 / Rootkit.Avatar rootkit family contains interesting techniques for bypassing detection in terms of AV products. The Avatar rootkit, along with the Gapz bootkit, can be used to provide a long-term infection of the system. Avatar does not store its files on a regular volume, but uses its own hidden FS for this; in addition, it uses the technique of infecting standard drivers, which is a more difficult case for investigation from the point of view of conducting a forensic examination.
The threat also has additional ways to maintain control of the botnet if command C&C servers are unavailable. To completely disinfect an infected system, first of all, it is necessary to deactivate the rootkit driver and its user-mode payload and after that try to restore the infected system driver.
When we found the droppers of this rootkit, we immediately began to analyze it. I must say that we added it to the database as Win32 / Rootkit.Avatar . ColleaguesAnton Cherepanov and Alexander Matrosov performed a detailed analysis of this rootkit, its payload and basic capabilities.
In March, our anti-virus lab discovered two droppers that interacted with different C&C servers and had different compilation dates.
As mentioned in the announcement, Win32 / Rootkit.Avatar contains a driver infector, but in addition, it uses this technique twice: firstly in the dropper to bypass detection from the HIPS and secondly in the driver to survive after a reboot. In the first case, the advantage of loading the rootkit driver directly from kernel mode using the standard OS driver is used, and in the second case, the rootkit ensures its launch after reboot. Of course, this tactic has drawbacks in terms of violating file integrity and integrity control by verifying digital signatures for drivers, so the rootkit can only work on x86 systems.
Droppers
Avatar uses a multi-layer dropper approach. The first level dropper performs decompression (LZMA) for the second level dropper and driver. In fact, the second-level dropper and the driver itself are unique files generated each time when unpacking, since the initial dropper generates random names for mutexes and events that are used in their code and performs these modifications directly in the body of each module. The initial dropper uses an interesting trick as an anti-debugging tool, it is based on comparing the time from the KUSER_SHARED_DATA.InterruptTime structure (KUSER_SHARED_DATA is located on the page, accessible both in user mode and in kernel mode). Malicious code modifies an RtlDispatchException function callinside another KiUserExceptionDispatcher function . The next step generates an inclusion and control passes to the desired exception handler.
In this case, the current time for measurement is taken from KUSER_SHARED_DATA.InterruptTime and then compared at subsequent stages of execution. This mechanism allows detecting emulation and debugging of dropper code.
The second-level dropper checks the environment for virtual machines, and fairly well-known checks are used for this. Before executing the code responsible for checking on the VM, the dropper decrypts it using the “explorer” key.
In the next step, the dropper checks the OS version and current privileges. In this case, two methods of privilege escalation are used:
- Exploiting the vulnerability MS11-080 .
- COM Elevation (UAC whitelist).
The process of infecting the system with a dropper is shown in the diagram below.
The exploit for the MS11-080 vulnerability uses code similar to the exploit code from the Metasploit Framework , but with some minor changes. After checking the afd.sys driver version, the dropper uses the following code for operation.
The following screenshot shows the code that, using IOCTL 0x000120BB, calls the afd! AFDJoinLeaf function to rewrite the pointer in the HalDispatchTable to the desired rootkit function.
After successful operation and transfer of control to the shell code, it initiates the download of the rootkit driver.
In fact, the rootkit driver is not stored on disk as a separate file, but is loaded from the memory buffer. Below is the call graph for the function that loads the driver.
After successfully elevating privileges, the malicious code searches for a suitable driver for infection in the% WINDIR% \ system32 \ drivers directory. After the infection has been completed, the driver entry point ( GsDriverEntry ) is modified to execute malicious code (stub). The modified entry point is as follows:
One of the main tasks of this stub is to connect to the execution process of the second level dropper and read the body of the rootkit driver into memory. The stub code is shown in the figure below.
After a successful infection, the modified driver copies itself to the% TEMP% directory and tries to load itself using standard OS mechanisms (via the service control manager or directly through ZwLoadDriver ).
Thus, the Avatar rootkit driver file is not really stored on the hard drive, but will be loaded with code that is called by using MS11-080. Such a rootkit boot method, using the system driver infection, is an effective method of circumventing HIPS and allows loading another kernel-mode module from a trusted system driver.
Driver
After the driver is successfully loaded into memory, the malicious code infects the system driver in order to ensure its survival after a reboot. A special algorithm is used to select the desired driver. At the same time, Avatar randomly selects a driver and checks its name against the blacklist specific to different versions of the OS.
The execution flow of the infected driver code occurs according to the following scenario:
1. A stub is executed at the entry point.
2. Then the Pnp Notify callback function is installed for the GUID_DEVINTERFACE_DISK class, in which the driver body will be loaded from the hidden rootkit file system. A similar technique was observed in TDL3 , TDL4, and Olmasco (MaxSS / SST).
3. The source bytes of the entry point are restored.
A rootkit driver can infect several system drivers without changing the original size of the original file.
Avatar uses an interesting trick to discover the virtual machine environment. It calls the nt! MmMapIoSpace function to read BIOS data at 0xF0000 and checks for the following lines:
- Parallels Software
- Virtual machine
- Virtualbox
- QEMU BIOS
- VMware
- Bochs
Also in the code there are additional checks for KVM and Hyper-V using the already known tricks of the CPUID instruction.
Hidden FS is used to store user mode payloads and auxiliary files. All files are encrypted using a symmetric algorithm. Below is a call graph for a function that works with hidden FS.
There are special attributes for files stored on hidden FS.
Malicious code allows downloading from the network and further execution of additional payload in the form of user-mode and kernel-mode modules. This payload is also stored on a hidden FS. Win32 / Rootkit.Avatar does not store any of its components on an NTFS volume, except for an infected system driver. This combination of a hidden, encrypted FS, along with an infected system driver makes it more difficult to use conventional forensic techniques to investigate Avatar infections.
To implement the user mode payload, the KeInitializeApc function is used to initialize the APC object, which is then used to execute the required rootkit function.
Payload
The payload of the Avatar rootkit modification under study is not original. Key features:
- Interaction with team C&C.
- Parsing configuration information.
- Work with hidden FS.
- Interaction with the rootkit driver.
- Installing a payload into the system.
While examining this modification of the rootkit, we noticed that the payload in the form of avcmd.dll was introduced into the svchost.exe system process. This module is responsible for working with C&C, whose IP addresses are stored in the configuration file. This file has the following structure.
- Identifier (name) of the botnet.
- C&C Team Server URLs.
- 1024-bit key for the encryption algorithm.
- Public key for RSA-1024.
- The names of the processes to implement the payload.
Examples of decrypted configuration information from two different droppers are given below.
For botnet with identifier BTN1.
For botnet with identifier NET1.
In order to protect interactions with C&C, Avatar uses its own base64 encryption algorithm. At the same time, all network interaction in user mode is carried out using the usual WinInet API functions.
Avatar also has an additional way of communicating with C&C if you are having problems using other methods. He tries to search for messages in Yahoo groups using special parameters.
A sequence is searched based on the following parameters (in our case, these are 17BTN1 and 17NET1).
After these lines are connected, the received byte sequence is encrypted using its own algorithm using the 1024-bit key from the configuration file.
Key = BTN1 6mQ98EXP3v7TKMdk704uOUzGqvikuoHt98n8IPp4K19
a3qyZ96LoOc54sb3g9eJVyAs7VmPxQjkkM9R960ev275K24PQ550K1
9fNk8305jRDUTb4cEut4579Zg9i32qU
NET1 key = E623J5XKJ9NF4bseM5J2nkwhs1K2766DUOMUDSee3c
7xu06Q9QayV61U4fm5H89ppuNgLt9M5D2XTCLcd0aS3m9CO1aZg9h9
o2zb2EIC437IU3X1P3ec07481E0j2Tdr
After encryption is applied to the received sequence and then base64 characters are translated to the upper case, while some characters are filtered out. An example for a botnet with identifier BTN1 is shown below.
SymFilter (UpperCase (Base64 (Encrypt (17BTN1)))) = EZTFDHWP
The string EZTFDHWP is used for the subsequent search query for the Yahoo group. If such a request is successful, the next step is to check the numbers of the found group and read its description data.
The group description is then encrypted using RSA and a 1024-bit private key. Such data can be decrypted by knowing the public key stored in the configuration file. We believe that this information can be found in encrypted messages used to return control to the botnet in the absence of active C&C servers.
After finding this function, we checked possible such messages on Yahoo Groups. One group was found that matched the specified parameters (11BTN1 = EFS9KHRF). The search query looks like this:
hxxp: //groups.yahoo.com/search? query = EFS9KHRF & sort = relevance
It can be seen that the encrypted message is present in the description of this group.
We decrypted this message using the RSA-1024 key found in one of the configuration files. The key to the configuration file with the botnet identifier BTN1 was used.
dZ8FsJ4z0 :: http: //www.avatarbut.info www.avatarsbut.info
This information is similar to one of the URLs for C&C that we saw in the BTN1 configuration file itself. It seems that this group was used by cybercriminals to run around this mode of interaction, since it includes information from the configuration file itself.
Such a botnet support scheme using message in Yahoo groups provides excellent protection against botnet synching attempts, because the C&C server domain information is encrypted using an asymmetric RSA-based encryption algorithm. During the research process, the scammers can only extract the public key for decrypting messages, but this key cannot be used to encrypt new messages and create dummy groups.
Avatar Runtime Library
Malicious code Win32 / Rootkit.Avatar has a special API for developing auxiliary components. The use of this API is based on the Avatar Runtime Library and a special SDK that describes the development of additional user-mode modules. These modules can also interact with the rootkit driver. The Avatar Runtime Library includes the following APIs:
- aTakeProcessToken - Assign an access token from one process to another.
- aExecute - execute a module in the context of a remote process.
- aLoadDriver - load the driver from the location of the hidden FS.
- aLoadFileFromAvatarDisk - read a file from a hidden FS.
- aSaveFileOrAttrToAvatarDisk - write a file to a hidden FS.
- aSendReport - send information to a remote C&C.
The payload storage structure that will be embedded in the processes looks like this.
After analyzing the Avatar SDK, we concluded that this project was developed by fairly qualified developers. Obviously, the developers of the malicious code have been working on the rootkit code for at least six months in order to test the basic functionality and ensure the necessary stability of the kernel mode component.
Conclusion
The Win32 / Rootkit.Avatar rootkit family contains interesting techniques for bypassing detection in terms of AV products. The Avatar rootkit, along with the Gapz bootkit, can be used to provide a long-term infection of the system. Avatar does not store its files on a regular volume, but uses its own hidden FS for this; in addition, it uses the technique of infecting standard drivers, which is a more difficult case for investigation from the point of view of conducting a forensic examination.
The threat also has additional ways to maintain control of the botnet if command C&C servers are unavailable. To completely disinfect an infected system, first of all, it is necessary to deactivate the rootkit driver and its user-mode payload and after that try to restore the infected system driver.
