Avatar rootkit: detailed analysis
In February 2013, information appeared about the new Avatar rootkit, which, judging from everything, has its origin in 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 capabilities of this rootkit were really impressive. Among them, for example, the possibility of loading the driver without the participation of the hard disk, infection 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 it was added to our database as Win32 / Rootkit.Avatar . Colleagues Anton Cherepanov and Alexander Matrosov made a detailed analysis of this rootkit, its payload and basic capabilities.
')
In March, our anti-virus laboratory discovered two droppers that interacted with different C & C servers and had different compilation dates.
As mentioned in the ad, Win32 / Rootkit.Avatar contains a driver infector, but besides this, it uses this technique twice: firstly in the dropper to bypass detection from the HIPS side and secondly in the driver for survival after a reboot. In the first case, it takes advantage of loading the rootkit driver directly from kernel mode using the standard OS driver, and in the second case, the rootkit ensures its launch after a reboot. Of course, this tactic has drawbacks from the point of view of violating the integrity of the file and monitoring integrity of the digital signature verification for drivers, so the rootkit can work only in x86 systems.
Droppers
Avatar uses a dropper approach consisting of several levels. 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 they are unpacked, because the initial dropper generates random names for the mutexes and events that are used in their code and performs these modifications directly in the body of each of the modules. The initial dropper uses an interesting trick as anti-debugging, it is based on a time comparison from the KUSER_SHARED_DATA.InterruptTime structure (KUSER_SHARED_DATA is located on a page that is accessible in both user mode and kernel mode). The malicious code performs a modification of the RtlDispatchException function call inside another KiUserExceptionDispatcher function. In the next step, an exception is generated and control passes to the desired exception handler.
In this case, the current time for the measurement is taken from KUSER_SHARED_DATA.InterruptTime and then compared at subsequent stages of execution. This mechanism allows to detect emulation and debugging of the dropper code.
The second level dropper checks the environment for virtual machines, while using fairly well-known checks. Before executing the code responsible for checking the VM, the dropper decrypts it using the explorer key.
In the next step, the dropper checks the OS version and current privileges. It uses two methods of elevating privileges:
The process of system infection with a dropper is presented in the diagram below.
The exploit for MS11-080 exploits a code similar to the exploit code from the Metasploit Framework , but with some minor changes. After checking the version of the afd.sys driver, 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 the 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 successful privilege escalation, the malicious code searches for a suitable driver for infection in the% WINDIR% \ system32 \ drivers directory. After the infection has been performed, the driver entry point ( GsDriverEntry ) is modified to execute the malicious code (stub). The modified entry point looks like this:
One of the main tasks of this stub is to connect to the process of executing 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 via ZwLoadDriver ).
Thus, the Avatar rootkit driver file is not really stored on the hard disk, but will be loaded with the code that is called by using MS11-080. This method of downloading a rootkit, using the infection of the system driver, is an effective method of circumventing HIPS and allows you to load another kernel-mode module from a trusted system driver.
Driver
After the driver is successfully loaded into memory, the malicious code performs infection of the system driver in order to ensure its survival after a reboot. To select the driver you use a special algorithm. At the same time, Avatar randomly selects a driver and checks its name against a blacklist specific to different versions of the OS.
The flow of code execution of an infected driver occurs in the following scenario:
1. A stub is executed at the entry point.
2. Then the Pnp Notify callback function is installed for the class GUID_DEVINTERFACE_DISK, in which the driver's body will be loaded from the hidden rootkit file system. A similar technique was observed in TDL3 , TDL4 and Olmasco (MaxSS / SST).
3. The original 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 technique for discovering the virtual machine environment. It calls the nt! MmMapIoSpace function to read the BIOS data at 0xF0000 and checks for the presence of 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 booting from the network and further execution of additional payload in the form of user-mode and kernel-mode modules. This payload is also stored in hidden FS. Win32 / Rootkit.Avatar does not store any of its components on an NTFS volume, with the exception of the infected system driver. This combination of hidden, encrypted FS, along with an infected system driver, makes it more difficult to use conventional forensic examination methods 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 investigation is not original. Key features:
While researching this modification of the rootkit, we noticed that the payload in the form of avcmd.dll was implemented in 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 decoded configuration information from two different droppers are given below.
For botnet identifier BTN1.
For botnet ID NET1.
In order to protect interactions with C & C, Avatar uses its own base64 encryption algorithm. At the same time, all user-mode networking is done using the usual WinInet API functions.
Avatar also has an additional way to communicate with C & C, if you have problems using other methods. He is trying to search for messages in Yahoo groups using special parameters.
Sequences are searched based on the following parameters (in our case, these are 17BTN1 and 17NET1).
After these strings are connected, the resulting byte sequence is encrypted using a proprietary algorithm using a 1024-bit key from the configuration file.
BTN1 key = 6mQ98EXP3v7TKMdk704uOUzGqvikuoHt98n8IPp4K19
a3qyZ96LoOc54sb3g9eJVyAs7VmPxQjkkM9R960ev275K24PQ550K1
9fNk8305jRDUTb4cEut4579Zg9i32qU
NET1 key = E623J5XKJ9NF4bseM5J2nkwhs1K2766DUOMUDSee3c
7xu06Q9QayV61U4fm5H89ppuNgLt9M5D2XTCLcd0aS3m9CO1aZg9h9
o2zb2EIC437IU3X1P3ec07481E0j2Tdr
After encryption, base64 is applied to the resulting sequence and then the letters are converted to upper case, with some characters being filtered out. An example for a botnet with the identifier BTN1 is shown below.
SymFilter (UpperCase (Base64 (Encrypt (17BTN1)))) = EZTFDHWP
The string EZTFDHWP is used for a 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.
Further, the group description is 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 for possible such messages on Yahoo Groups. One group was found that falls under the given parameters (11BTN1 = EFS9KHRF). The search query looks like this:
hxxp: //groups.yahoo.com/search? query = EFS9KHRF & sort = relevance
It is 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 C & C URLs that we saw in the BTN1 configuration file itself. It seems that this group was used by cybercriminals to test this way of interaction, because it includes information from the configuration file itself.
Such a botnet maintenance scheme using a message in Yahoo groups provides excellent protection against botnet syncing attempts, since the information about the domains of C & C servers is encrypted using an asymmetric RSA-based encryption algorithm. In the process of research, reserchers can only extract the public key to decrypt messages, but this key cannot be used to encrypt new messages and create dummy groups.
Avatar Runtime Library
Win32 / Rootkit.Avatar malware 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 structure of the storage of the payload that will be implemented in the processes looks like this.
After analyzing the Avatar SDK, we concluded that this project was developed by quite skilled developers. It is obvious that the developers of the malicious code worked on the rootkit code for at least six months in order to test the main functionality and ensure the necessary stability of the kernel mode component.
Conclusion
The Win32 / Rootkit.Avatar rootkit family contains interesting techniques for circumventing detection from the point of view of AV products. The Avatar rootkit, along with the Gapz bootkit, can be used to ensure a long-term infection of the system. Avatar does not store its files on a regular volume, but uses its hidden FS for this, besides it uses the technique of infecting standard drivers, which is a more difficult case to investigate from the point of view of conducting a forensic examination.
The threat also has additional ways of maintaining control over the botnet if the command C & C servers are unavailable. In order to completely disinfect the 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 it was added to our database as Win32 / Rootkit.Avatar . Colleagues Anton Cherepanov and Alexander Matrosov made a detailed analysis of this rootkit, its payload and basic capabilities.
')
In March, our anti-virus laboratory discovered two droppers that interacted with different C & C servers and had different compilation dates.
As mentioned in the ad, Win32 / Rootkit.Avatar contains a driver infector, but besides this, it uses this technique twice: firstly in the dropper to bypass detection from the HIPS side and secondly in the driver for survival after a reboot. In the first case, it takes advantage of loading the rootkit driver directly from kernel mode using the standard OS driver, and in the second case, the rootkit ensures its launch after a reboot. Of course, this tactic has drawbacks from the point of view of violating the integrity of the file and monitoring integrity of the digital signature verification for drivers, so the rootkit can work only in x86 systems.
Droppers
Avatar uses a dropper approach consisting of several levels. 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 they are unpacked, because the initial dropper generates random names for the mutexes and events that are used in their code and performs these modifications directly in the body of each of the modules. The initial dropper uses an interesting trick as anti-debugging, it is based on a time comparison from the KUSER_SHARED_DATA.InterruptTime structure (KUSER_SHARED_DATA is located on a page that is accessible in both user mode and kernel mode). The malicious code performs a modification of the RtlDispatchException function call inside another KiUserExceptionDispatcher function. In the next step, an exception is generated and control passes to the desired exception handler.
In this case, the current time for the measurement is taken from KUSER_SHARED_DATA.InterruptTime and then compared at subsequent stages of execution. This mechanism allows to detect emulation and debugging of the dropper code.
The second level dropper checks the environment for virtual machines, while using fairly well-known checks. Before executing the code responsible for checking the VM, the dropper decrypts it using the explorer key.
In the next step, the dropper checks the OS version and current privileges. It uses two methods of elevating privileges:
- Exploiting MS11-080 vulnerability.
- COM Elevation (UAC whitelist).
The process of system infection with a dropper is presented in the diagram below.
The exploit for MS11-080 exploits a code similar to the exploit code from the Metasploit Framework , but with some minor changes. After checking the version of the afd.sys driver, 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 the 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 successful privilege escalation, the malicious code searches for a suitable driver for infection in the% WINDIR% \ system32 \ drivers directory. After the infection has been performed, the driver entry point ( GsDriverEntry ) is modified to execute the malicious code (stub). The modified entry point looks like this:
One of the main tasks of this stub is to connect to the process of executing 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 via ZwLoadDriver ).
Thus, the Avatar rootkit driver file is not really stored on the hard disk, but will be loaded with the code that is called by using MS11-080. This method of downloading a rootkit, using the infection of the system driver, is an effective method of circumventing HIPS and allows you to load another kernel-mode module from a trusted system driver.
Driver
After the driver is successfully loaded into memory, the malicious code performs infection of the system driver in order to ensure its survival after a reboot. To select the driver you use a special algorithm. At the same time, Avatar randomly selects a driver and checks its name against a blacklist specific to different versions of the OS.
The flow of code execution of an infected driver occurs in the following scenario:
1. A stub is executed at the entry point.
2. Then the Pnp Notify callback function is installed for the class GUID_DEVINTERFACE_DISK, in which the driver's body will be loaded from the hidden rootkit file system. A similar technique was observed in TDL3 , TDL4 and Olmasco (MaxSS / SST).
3. The original 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 technique for discovering the virtual machine environment. It calls the nt! MmMapIoSpace function to read the BIOS data at 0xF0000 and checks for the presence of 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 booting from the network and further execution of additional payload in the form of user-mode and kernel-mode modules. This payload is also stored in hidden FS. Win32 / Rootkit.Avatar does not store any of its components on an NTFS volume, with the exception of the infected system driver. This combination of hidden, encrypted FS, along with an infected system driver, makes it more difficult to use conventional forensic examination methods 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 investigation is not original. Key features:
- Interaction with team C & C.
- Parsing configuration information.
- Work with hidden FS.
- Interaction with the rootkit driver.
- Installation in the system payload.
While researching this modification of the rootkit, we noticed that the payload in the form of avcmd.dll was implemented in 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.
- URL of C & C command servers.
- 1024-bit key for encryption algorithm.
- Public key for RSA-1024.
- The names of the processes for the implementation of the payload.
Examples of decoded configuration information from two different droppers are given below.
For botnet identifier BTN1.
For botnet ID NET1.
In order to protect interactions with C & C, Avatar uses its own base64 encryption algorithm. At the same time, all user-mode networking is done using the usual WinInet API functions.
Avatar also has an additional way to communicate with C & C, if you have problems using other methods. He is trying to search for messages in Yahoo groups using special parameters.
Sequences are searched based on the following parameters (in our case, these are 17BTN1 and 17NET1).
After these strings are connected, the resulting byte sequence is encrypted using a proprietary algorithm using a 1024-bit key from the configuration file.
BTN1 key = 6mQ98EXP3v7TKMdk704uOUzGqvikuoHt98n8IPp4K19
a3qyZ96LoOc54sb3g9eJVyAs7VmPxQjkkM9R960ev275K24PQ550K1
9fNk8305jRDUTb4cEut4579Zg9i32qU
NET1 key = E623J5XKJ9NF4bseM5J2nkwhs1K2766DUOMUDSee3c
7xu06Q9QayV61U4fm5H89ppuNgLt9M5D2XTCLcd0aS3m9CO1aZg9h9
o2zb2EIC437IU3X1P3ec07481E0j2Tdr
After encryption, base64 is applied to the resulting sequence and then the letters are converted to upper case, with some characters being filtered out. An example for a botnet with the identifier BTN1 is shown below.
SymFilter (UpperCase (Base64 (Encrypt (17BTN1)))) = EZTFDHWP
The string EZTFDHWP is used for a 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.
Further, the group description is 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 for possible such messages on Yahoo Groups. One group was found that falls under the given parameters (11BTN1 = EFS9KHRF). The search query looks like this:
hxxp: //groups.yahoo.com/search? query = EFS9KHRF & sort = relevance
It is 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 C & C URLs that we saw in the BTN1 configuration file itself. It seems that this group was used by cybercriminals to test this way of interaction, because it includes information from the configuration file itself.
Such a botnet maintenance scheme using a message in Yahoo groups provides excellent protection against botnet syncing attempts, since the information about the domains of C & C servers is encrypted using an asymmetric RSA-based encryption algorithm. In the process of research, reserchers can only extract the public key to decrypt messages, but this key cannot be used to encrypt new messages and create dummy groups.
Avatar Runtime Library
Win32 / Rootkit.Avatar malware 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 for one process to another.
- aExecute - execute the 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 the file to the hidden FS.
- aSendReport - send information to a remote C & C.
The structure of the storage of the payload that will be implemented in the processes looks like this.
After analyzing the Avatar SDK, we concluded that this project was developed by quite skilled developers. It is obvious that the developers of the malicious code worked on the rootkit code for at least six months in order to test the main functionality and ensure the necessary stability of the kernel mode component.
Conclusion
The Win32 / Rootkit.Avatar rootkit family contains interesting techniques for circumventing detection from the point of view of AV products. The Avatar rootkit, along with the Gapz bootkit, can be used to ensure a long-term infection of the system. Avatar does not store its files on a regular volume, but uses its hidden FS for this, besides it uses the technique of infecting standard drivers, which is a more difficult case to investigate from the point of view of conducting a forensic examination.
The threat also has additional ways of maintaining control over the botnet if the command C & C servers are unavailable. In order to completely disinfect the 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.
Source: https://habr.com/ru/post/178639/
All Articles