Zero without a wand?
Published in magazine Hacker # 171 (April 2013)
Over time, some malicious programs become peculiar brands in the environment of cybrandegrand. As a rule, they are widespread in comparison with other malware and use various technological chips. These include the Sality, Conficker, Waledac, Zeus, TDL, and many others. No matter how hard the anti-virus companies struggle with such threats, as they say - sometimes they come back. In the logical use of the untwisted name attackers can not refuse. Analyzing the functionality of the next "little animals", you unwittingly ask yourself the question - and when did it all start? And it turns out that neither a year nor two years ago. One such family will be described below.
Start
The history of ZeroAccess (aka MAX ++) began in June 2009. It was then that a sample of a malicious program was found that used the path of the form \\? \ Globalroot \ Device \ __ max ++> \ [8 digit hex code] .dll, and in the kernel driver it had the string "f: \ VC5 \ release \ ZeroAccess.pdb" . So the name ZeroAccess is copyright. But, as you know, some antivirus vendors resist calling malware according to the authors' idea, therefore MAX ++ is also known as Smiscer and Sirefef. The 2009 version hid its binary code in alternate streams (Alternate Data Streams - ADS) of the NTFS file system under the names win32k.sys: 1 and win32k.sys: 2, which were registered in the system as services. The first of these files was bait, in case antivirus software tried to access it, ZeroAccess immediately terminated the scanning process. Subsequently, the use of tracking techniques for specially created objects of the OS to "kill" antiviruses, became its distinguishing feature.
')
TDL3 Step Brother
In January 2010, the creators of ZeroAccess began to distribute a new version of their offspring. For this, the resources of the Ecatel network of the RBN company were used. A distinctive feature of the new version of ZeroAccess, was the obvious borrowing of the ideas of TDL3, namely, launching the driver through infection and using hidden storage for its components.
Installation into the system began with a dropper file, for example, with the name keygen.exe. Administrator rights were necessary for normal operation, which in the conditions of disguise as keygen for a favorite toy was not a particular problem. When installing to the disk, no temporary working files were extracted, all manipulations took place in memory. To start when booting the OS, the boot method was used using the ZwLoadDriver () function. First of all, the victim driver existing in the system was chosen, which falls under a few necessary signs: the driver name must be in the range from Ndis.sys to Win32k.sys, the size is more than 0x4C10 bytes, IMAGE_OPTIONAL_HEADER-> Export Table.RVA is set to NULL ( the driver does not export anything). Also, the driver should not have been launched when the system was booted, this was checked using the Start flag (0 - do not load) in the services registry branch. After selecting the appropriate driver, ZeroAccess completely rewritten it with its code, having previously disabled the SFC. Next, an entry was created in the registry about a new service with a random name and the parameters Type = 0x1, Start = 0x3. The trick was that the ImagePath for the service was set to \ *, and for \ * using the ZwCreateSymbolicLinkObject () function, a symlink was created for the overwritten driver. The specified service and started by calling ZwLoadDriver (). The launched rootkit was registered via a call to IoCreateDriver () as an OS driver, to intercept an I / O operation at the IRP level of the disk subsystem miniport driver packages. Next, a virtual device was created with a fixed name \ ?? \ C2CAD972 # 4079 # 4fd3 # A68D # AD34CC121074, to which the previously created storage file was installed as% system% \ Config \ [random symbols] .sav. Now the dropper could access its storage through a virtual device. After formatting the storage into a compressed NTFS volume using the functions of the fmifs.dll library, all other components were saved there, including a copy of the clean driver. The file structure is shown in the figure.
The rootkit's function was to hide the contents of the overwritten driver; when trying to read it, the rootkit showed the saved source file. In addition, the rootkit initiated the launch of the injector B48DADF8.sys, which injected the main module DLL with the name max ++. 00.x86 into the address space of the browser via APC. It can be noted that during the operation, the direct launch functions are not used at all, so as not to trigger the anti-virus proactive defense. The main module had functions of communication with the command center and substitution of search results for redirecting users to malicious sites offering to download a fake anti-virus (FakeAV). Connection parameters were taken from files in the repository with names similar to CLSID, for example {49B474EB-92D0-464f-B1DD-1F37AABF9D95}. According to Symantec, between July 1, 2009 and June 30, 2010, about 43 million installations of fake antiviruses were produced. Given the cost of such a "gift" from $ 30 to $ 100, it appears that this business was quite profitable.
In 2011, an updated version appeared. To download the rootkit, we used the same launch method via ZwLoadDriver () with minor changes. Now the drivers were selected from the range from classpnp.sys to win32k.sys, larger than 0x7410. In the dropper code, there was a check for execution in a 64-bit environment; in this case, execution was immediately completed. The name of the device for accessing the repository was \\? \ ACPI # PNP0303 # 2 & da1a3ff & 0 (it could change from release to release). The 16 megabyte% system% \ Config \ [random symbols] storage file was not compressed this time, but was encrypted with a 128-bit static RC4 key, decrypted on the fly by the rootkit driver when accessing files stored in the storage. There was a pronounced modular structure,
modules loaded from a remote server. To communicate with the command center, a connection was established to port 13620. The requests and responses themselves were transmitted in encrypted form.
Work in x64 and self defense tricks
Until April 2011, 64-bit OS versions were not infected with ZeroAccess. In May, this annoying omission was corrected, but not to say that it would be very technological. The fact is that for x86 the algorithm of operation was similar to the previous version and the rootkit worked at the kernel level. In contrast to this, in the x64 environment everything worked in usermode.
As you know, in Windows, starting with Vista, UAC appeared - a component of the system that requests confirmation of actions requiring administrative rights. UAC, of ​​course, slightly increased the security level of Windows, but, as always, the evil hackers spoiled everything. In UAC, many system programs are hardcoded as trusted (for example, explorer.exe), so the code that triggers for other applications does not work for them in the default setting. This feature was used in the ZeroAccess dropper in order to raise its privileges in the system to the administrator level, while the UAC window was not displayed to the user (this bug was eventually fixed).
To bypass the traffic monitoring tools in the HTTP HOST header, the domain name in the .cn zone generated using the Domain Generator Algorithm (DGA) was used, it really is not resolved by the DNS servers. In response to a request with an incorrect HOST header, the server returned an empty response. That is, the server also generated the value in the same way and compared it with the one received from the bot. These actions were a kind of pseudo-authentication system that protected the server, for example, from scanning by search robots.
Since the installation procedure for x86 has already been described (driver infection), we will not focus on it. It is only worth noting the next change in the storage format in July, now it was not a file, but a directory of the type C: \ WINDOWS \ $ NtUninstallKBxxxxx $, where xxxxx is 5 generated digits. This name was chosen to disguise under the working directory of the Windows OS update. Access to it was blocked by creating a symbolic link from $ NtUninstallKBxxxxx $ to% systemroot% \ system32 \ config, as well as setting ACL rules. Each file inside the directory was encrypted with RC4, the key was not defined in the code, but was generated using some OS parameters.
Brief description of components downloaded from the Internet:
@ 00000001 - backup of the dropper;
@ 80000000 - tracking module, designed to collect statistics on infections, information about the infected system was sent to counter.yadro.ru;
@ 800000c0 - the fake mswsock.dll library for intercepting WinSocks functions, monitoring them allowed to steal FTP passwords and logins, as well as embed JavaScript in HTML pages;
@ 000000c0 - the module injects JavaScript to change the output of search queries and sends FTP account data to a remote server;
@ 800000cb - the module is embedded in svchost.exe and is used to cheat attendance (click fraud);
@ 800000cf - communication module with the command center, embedded in winlogon.exe, and then into the browser installed on the computer. In the address space of the browser, a code is executed that communicates at fixed IP addresses and port 13620 with the command center. The IP list is in a file with a name similar to CLSID.
In x64 mode, no innovation was observed. The boot module was saved as% windir% \ system32 \ consrv.dll, the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ SubSystems registry key was set to run, the string "consrv: ConServerDllInitialization" was inserted into the "Windows" key. To mask their files as storage, the Global Assembly Cache (GAC) system directory of $ windir \ assembly was used, which is used to display the installed .Net components and does not directly show its contents in Explorer, which does not roll in FAR and TotalCommander. The directory was created for storage $ windir \ assembly \ tmp, where the modules were placed in an encrypted form.
An interesting feature of this version of ZeroAccess is the use of live bait technology for breaking off antiviruses. In addition to its main driver-rootkit, ZeroAccess had an additional kernel driver to create a "bait" - an object on which anti-virus protection tools "pecked". This driver created the device \ Device \ svchost.exe and saved the fake PE file as \ Device \ svchost.exe \ svchost.exe, access to which was monitored by the rootkit. If any application tried to access it, ZeroAccess would immediately terminate it. To terminate the application stream, about two hundred bytes of code that called ExitProcess () were injected into it using the APC method. But this was not all that would prevent subsequent launches of the completed application, for its executable file ZeroAccess reset the access rules ACL, allowing the reading and execution of the file. Thus, once hooked, the antivirus could no longer start.
Give P2P!
In order to improve vitality, the developers began to use various tricks. The main focus was on the ability of ZeroAccess to work with any access rights, as well as countering the blocking of command centers. When launched in Windows Vista / Seven, an attempt was made to improve their rights. Since the UAC bypass bug through explorer in explorer.exe was fixed, the hijacking DLL was used to raise the rights, its essence - the OS first looks for the necessary DLL in the current directory, and then in the system directory, therefore, placing the DLL in the directory of the legitimate program that matches the name of one of the imported libraries, you can get the launch of malicious code. To implement this method on board the dropper, in the embedded CAB file,
The file fp.exe was present. It was a legal online Adobe Flash Player installer, which was also digitally signed with VeriSign. The installer was saved under the name FlashPlayerInstaller.exe in the temp directory, in the same directory previously placed file msimg32.dll, whose name matches one of the imported DLL.
Rootkit x86 mode, as before, placed in the trap system. Now it was the service that started the file \ systemroot \ 3439254774: 153289011.exe, while the file 3439254774 was of zero size, and 153289011.exe was stored in ADS and was taken from wsc32.
In 64-bit Windows Vista / Seven mode, if there were administrator rights, a scheme with consrv.dll and $ windir \ assembly was used. If there were no such rights, it was not fatal, including in the XP environment. After all, the most important innovation is the “X” file, which implements P2P based on the TCP protocol for distribution of its modules, as well as the bootstrap list with the name “@”, the “U” and “L” directories, were placed in places accessible for recording with custom rights:
XP -% UserProfile% \ Application Data \ [8 digit hex code];
Vista / Seven -% UserProfile% \ AppData \ Local \ [8 digit hex code].
The launch of the “X” file was prescribed in the Shell parameter of the HKEY_CURRENT_USER \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon branch. Thus, the functioning of ZeroAccess was supported from under an account with limited rights, even if it was without rootkit functions.
According to Sophos, the active distribution of the P2P TCP-based version began in September-November 2011, while the first samples appeared in late July. Antivirus analysts point out that this version downloaded two main types of payload - click fraud and spambot, which are easy to identify by the ports used (21810, 22292 and 34354, 34355, respectively).
The Bootstrap list contained 256 values ​​of IP addresses, for each of which a timestamp (POSIX) was specified for the last call. All P2P network packets were encrypted using the RC4 algorithm with a static key.
The following command types were supported:
“GetL” - request for bootstrap list;
"RetL" is the response with the contents of the bootstrap list;
"GetF" - a request for a file;
"SetF" - the answer with the contents of the file;
"Srv?" - request for a list of files.
By the way, the type of command is not a string, but a 4-byte word, it is easier to compare them. The name of the module file of eight HEX characters was also encoded in 4 bytes.
For each node in the current bootstrap list, a “getL” command was sent. The remote computer had to respond with the “retL” command and send its bootstrap list. The resulting list, created on the basis of the current and the one sent, contained nodes with the access time closest to the current one. In response to the “srv?” Request, a list of files was sent, each entry in the list contained two fields: the file name of 4 bytes and the timestamp for creating the file. When “fresh” files were detected, they were updated by the “getF”, “setF” commands. Each loadable module had to contain the resource “33333” containing the RSA digital signature with a key of 512 bits. The signature was checked before running the file.
There were some implementation flaws in the P2P protocol. Having formed a 256 IP bootstrap list with obviously larger timestamp values ​​than the current time, it was possible to poison the bootstrap list of all nodes, which would make it impossible to distribute modules over the P2P network. If an arbitrary file was placed in the repository (note — the value of the milliseconds field in the time_field structure of the file should have been zero), it was pumped out by remote peers, although its launch was impossible due to signature verification. This made it possible to create a load on the network and thereby draw attention to the anomalous network traffic on the computer with further detection and removal of ZeroAccess. These deficiencies were corrected in the next implementation of P2P.
Wave the rootkit
May 2012 - that's when the time ended when the nuclear-level driver was part of ZeroAccess, now all the work was done in usermode. Looking into the contents of the CAB file, you can find that the rtk32 and rtk64 components have disappeared from it, but w32, w64, e32, e64 have been added.
The rootkit component is not present, respectively, the Windows driver in this version is not overwritten, one of two methods can be used to start at boot time - the COM hijacking technique, which uses the system registry, and modification of the services.exe file.
Using COM, hijacking launches a file called “n” (n32 or n64), which is responsible for the operation of the P2P network. A dropper creates two identical files “n” in the following two places:
% Windir% \ installer \ [UID];
% UserProfile% \ local settings \ application data \ [UID] (for XP and below) or% UserProfile% \ AppData \ Local \ [UID] (for Vista and above).
Here, the UID is the value generated by the dropper based on the MD5 hash from the time the system disk was created and formatted to look like a CLSID, for example {e051c979-bddd-5d1f-8953-4b8c940e9b4d}. The specified directories also create subdirectories “U” (for additional modules) and “L” (for temporary files), as well as the file “@” (s32 or s64).
One “n” file uses the hijacking COM object associated with WMI, and the following registry key is modified: HKCR \ CLSID \ {F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1} \ InprocServer32.
Another file "n" uses to start a COM object in the branch:
HKCU \ Software \ Classes \ clsid \ {42aedc87-2188-41fd-b9a3-0c966feabec1}.
The services.exe file was modified in an interesting way: a small shell-code (w32 or w64) was inserted into the file, which by calling the ZwQueryEaFile () function loaded the tail of the malicious code (e32 or e64) from the Extended Attributes file previously saved there using the ZwSetEaFile () The functionality of the PE files in the e32 and e64 components was identical to n32 and n64.
Later versions hide their files inside C: \ $ Recycle.Bin or C: \ RECYCLER,
where the directory was created with the name corresponding to the CLSID of the computer user. If there were administrator rights, another directory was created with CLSID S-1-5-18 (LOCAL_SYSTEM). Inside, a subdirectory was created with a random name formed by MD5 hashing of the current time. To start each of the two copies of the file “n”, the following COM objects were created:
HKCU \ Software \ Classes \ clsid \ {fbeb8a05-beee-4442-804e-409d6c4515e9} - for a user with limited rights;
HKCR \ CLSID \ {5839FCA9-774D-42A1-ACDA-D6A79037F57F} - for a user with administrator rights.
The algorithm of the P2P network has undergone some changes. Depending on the bitness of the OS, different ports were used: 16464 and 16470 for x32, 16465 and 16471 for x64. Thus, 4 independent P2P networks were organized, each of which used its own RSA key, the length of which was increased from 512 to 1024 bits. As before, there was a division by type of payload, ports 16464 and 16465 were used with the release with click fraud payload, 16470 and 16471 - with the release with bitcoin miner payload.
If earlier P2P used only TCP, now the list of IP addresses was requested via UDP, and the list of files (modules) via TCP. The “retL” command now returned only 16 values ​​from its bootstrap list (counteraction to the “poisoning” of the bootstrap list), in the same data block information about the available modules was transmitted. The bootstrap list now did not indicate the absolute timestamp value, but the difference between the current time and the time of the last access. Information about the modules used was transmitted in the form of a header consisting of the fields File name, Timestamp, Size. A digital signature was attached to the header (MD5 hash, encrypted with the malicious key of the attacker). The signature was checked for correctness at boot time and saved in the Extended Attributes file. Thus, cryptographic protection against outside interference was present both at the content level (as in the previous version, the “33333” resource containing a digital signature), and at the level of the name, creation date, and file size. The file itself was encrypted with the RC4 key during transmission. To force the change of the bootstrap list, the NewL command was introduced, which could be used when the attackers detected the antivirus company’s sinkhole in the peer list to restore the status quo. All of these differences from the previous version of P2P implementation were designed to eliminate the potential for disrupting the botnet.
The composition of loadable modules varies for different versions. For example, the click fraud version with a P2P 16464 port usually downloads three files:
800000cb. @ - click fraud module, registers a class named z00clicker3;
00000001. @ - dll used as a resource storage (data for 800000cb. @);
80000000. @ - tracking module, designed to collect statistics on infections, information about the infected system is sent to livecounter.co/count.php.
The version with bitcoin miner used a slightly different set of modules:
000000cb. @ - click fraud module;
80000000. @ - tracking module;
80000032. @, 80000064. @ - module bitcoin miner (x32 and x64);
00000004. @, 00000008. @ - dll, used as a resource storage (data for 80000032. @ and 80000064. @).
In addition to these, the loading of modules for redirecting search requests, sending spam and downloading arbitrary files is noted.
Conclusion
The ZeroAccess example well illustrates the principle of Occam's razor - do not multiply entities unnecessarily, or in a simple way - do not complicate. , , ZeroAccess, , , , P2P.
Sophos ZeroAccess 2012 9 , 1 . Kindsight Security «Malware Report» 3 2012 2.2 , 685 (31 %) . , ZeroAccess 2012 .
, , , ZeroAcces — . Ring-0 , «Access» . , . — , .
Over time, some malicious programs become peculiar brands in the environment of cybrandegrand. As a rule, they are widespread in comparison with other malware and use various technological chips. These include the Sality, Conficker, Waledac, Zeus, TDL, and many others. No matter how hard the anti-virus companies struggle with such threats, as they say - sometimes they come back. In the logical use of the untwisted name attackers can not refuse. Analyzing the functionality of the next "little animals", you unwittingly ask yourself the question - and when did it all start? And it turns out that neither a year nor two years ago. One such family will be described below.
Start
The history of ZeroAccess (aka MAX ++) began in June 2009. It was then that a sample of a malicious program was found that used the path of the form \\? \ Globalroot \ Device \ __ max ++> \ [8 digit hex code] .dll, and in the kernel driver it had the string "f: \ VC5 \ release \ ZeroAccess.pdb" . So the name ZeroAccess is copyright. But, as you know, some antivirus vendors resist calling malware according to the authors' idea, therefore MAX ++ is also known as Smiscer and Sirefef. The 2009 version hid its binary code in alternate streams (Alternate Data Streams - ADS) of the NTFS file system under the names win32k.sys: 1 and win32k.sys: 2, which were registered in the system as services. The first of these files was bait, in case antivirus software tried to access it, ZeroAccess immediately terminated the scanning process. Subsequently, the use of tracking techniques for specially created objects of the OS to "kill" antiviruses, became its distinguishing feature.
')
TDL3 Step Brother
In January 2010, the creators of ZeroAccess began to distribute a new version of their offspring. For this, the resources of the Ecatel network of the RBN company were used. A distinctive feature of the new version of ZeroAccess, was the obvious borrowing of the ideas of TDL3, namely, launching the driver through infection and using hidden storage for its components.
Installation into the system began with a dropper file, for example, with the name keygen.exe. Administrator rights were necessary for normal operation, which in the conditions of disguise as keygen for a favorite toy was not a particular problem. When installing to the disk, no temporary working files were extracted, all manipulations took place in memory. To start when booting the OS, the boot method was used using the ZwLoadDriver () function. First of all, the victim driver existing in the system was chosen, which falls under a few necessary signs: the driver name must be in the range from Ndis.sys to Win32k.sys, the size is more than 0x4C10 bytes, IMAGE_OPTIONAL_HEADER-> Export Table.RVA is set to NULL ( the driver does not export anything). Also, the driver should not have been launched when the system was booted, this was checked using the Start flag (0 - do not load) in the services registry branch. After selecting the appropriate driver, ZeroAccess completely rewritten it with its code, having previously disabled the SFC. Next, an entry was created in the registry about a new service with a random name and the parameters Type = 0x1, Start = 0x3. The trick was that the ImagePath for the service was set to \ *, and for \ * using the ZwCreateSymbolicLinkObject () function, a symlink was created for the overwritten driver. The specified service and started by calling ZwLoadDriver (). The launched rootkit was registered via a call to IoCreateDriver () as an OS driver, to intercept an I / O operation at the IRP level of the disk subsystem miniport driver packages. Next, a virtual device was created with a fixed name \ ?? \ C2CAD972 # 4079 # 4fd3 # A68D # AD34CC121074, to which the previously created storage file was installed as% system% \ Config \ [random symbols] .sav. Now the dropper could access its storage through a virtual device. After formatting the storage into a compressed NTFS volume using the functions of the fmifs.dll library, all other components were saved there, including a copy of the clean driver. The file structure is shown in the figure.
The rootkit's function was to hide the contents of the overwritten driver; when trying to read it, the rootkit showed the saved source file. In addition, the rootkit initiated the launch of the injector B48DADF8.sys, which injected the main module DLL with the name max ++. 00.x86 into the address space of the browser via APC. It can be noted that during the operation, the direct launch functions are not used at all, so as not to trigger the anti-virus proactive defense. The main module had functions of communication with the command center and substitution of search results for redirecting users to malicious sites offering to download a fake anti-virus (FakeAV). Connection parameters were taken from files in the repository with names similar to CLSID, for example {49B474EB-92D0-464f-B1DD-1F37AABF9D95}. According to Symantec, between July 1, 2009 and June 30, 2010, about 43 million installations of fake antiviruses were produced. Given the cost of such a "gift" from $ 30 to $ 100, it appears that this business was quite profitable.
Relationship between ZeroAccess and TDL3
In January 2010, a version appeared in the TDL3 family in which the payload file was called not cmd.dll, but Z00clicker.dll. It would seem, where does ZeroAccess? The thing is that the line Z00clicker was later mentioned several times in connection with this family of malware. First, in August 2010, the distribution of the desktop.ini module for ZeroAccess was revealed. This module blocked TDL3 (the latest version, with names like TDL4) by deleting the cfg.ini configuration file and the cmd.dll module from the TDL storage (if the target was TDL4, then cmd64.dll would also have to be deleted). An interesting fact, in addition to the “Kill TDL” function, is the distribution of the Z00clicker2.dll module, designed to cheat up visiting sites. The latest version of ZeroAccess contains in its composition a module responsible for click fraud, which creates a class with the name z00clicker3. So think after that, there is a connection between ZeroAccess and TDL3, or not.
Some experts, such as Webroot spokesperson Jakes Erasmus (Jacques Erasmus), say that the source TDL3 codes have been sold to ZeroAccess developers. It happened around the end of 2009 - the beginning of 2010. So it is possible that the TDL3 version with Z00clicker.dll and ZeroAcess are the results of third-party development based on the TDL3 source code. At the same time, Kaspersky Lab employees state that there is no connection between TDL3 and ZeroAcess. According to them, rather, we can talk about reverse engineering and borrowing ideas TDL3.
Some experts, such as Webroot spokesperson Jakes Erasmus (Jacques Erasmus), say that the source TDL3 codes have been sold to ZeroAccess developers. It happened around the end of 2009 - the beginning of 2010. So it is possible that the TDL3 version with Z00clicker.dll and ZeroAcess are the results of third-party development based on the TDL3 source code. At the same time, Kaspersky Lab employees state that there is no connection between TDL3 and ZeroAcess. According to them, rather, we can talk about reverse engineering and borrowing ideas TDL3.
In 2011, an updated version appeared. To download the rootkit, we used the same launch method via ZwLoadDriver () with minor changes. Now the drivers were selected from the range from classpnp.sys to win32k.sys, larger than 0x7410. In the dropper code, there was a check for execution in a 64-bit environment; in this case, execution was immediately completed. The name of the device for accessing the repository was \\? \ ACPI # PNP0303 # 2 & da1a3ff & 0 (it could change from release to release). The 16 megabyte% system% \ Config \ [random symbols] storage file was not compressed this time, but was encrypted with a 128-bit static RC4 key, decrypted on the fly by the rootkit driver when accessing files stored in the storage. There was a pronounced modular structure,
modules loaded from a remote server. To communicate with the command center, a connection was established to port 13620. The requests and responses themselves were transmitted in encrypted form.
Work in x64 and self defense tricks
Until April 2011, 64-bit OS versions were not infected with ZeroAccess. In May, this annoying omission was corrected, but not to say that it would be very technological. The fact is that for x86 the algorithm of operation was similar to the previous version and the rootkit worked at the kernel level. In contrast to this, in the x64 environment everything worked in usermode.
As you know, in Windows, starting with Vista, UAC appeared - a component of the system that requests confirmation of actions requiring administrative rights. UAC, of ​​course, slightly increased the security level of Windows, but, as always, the evil hackers spoiled everything. In UAC, many system programs are hardcoded as trusted (for example, explorer.exe), so the code that triggers for other applications does not work for them in the default setting. This feature was used in the ZeroAccess dropper in order to raise its privileges in the system to the administrator level, while the UAC window was not displayed to the user (this bug was eventually fixed).
To bypass the traffic monitoring tools in the HTTP HOST header, the domain name in the .cn zone generated using the Domain Generator Algorithm (DGA) was used, it really is not resolved by the DNS servers. In response to a request with an incorrect HOST header, the server returned an empty response. That is, the server also generated the value in the same way and compared it with the one received from the bot. These actions were a kind of pseudo-authentication system that protected the server, for example, from scanning by search robots.
Since the installation procedure for x86 has already been described (driver infection), we will not focus on it. It is only worth noting the next change in the storage format in July, now it was not a file, but a directory of the type C: \ WINDOWS \ $ NtUninstallKBxxxxx $, where xxxxx is 5 generated digits. This name was chosen to disguise under the working directory of the Windows OS update. Access to it was blocked by creating a symbolic link from $ NtUninstallKBxxxxx $ to% systemroot% \ system32 \ config, as well as setting ACL rules. Each file inside the directory was encrypted with RC4, the key was not defined in the code, but was generated using some OS parameters.
Brief description of components downloaded from the Internet:
@ 00000001 - backup of the dropper;
@ 80000000 - tracking module, designed to collect statistics on infections, information about the infected system was sent to counter.yadro.ru;
@ 800000c0 - the fake mswsock.dll library for intercepting WinSocks functions, monitoring them allowed to steal FTP passwords and logins, as well as embed JavaScript in HTML pages;
@ 000000c0 - the module injects JavaScript to change the output of search queries and sends FTP account data to a remote server;
@ 800000cb - the module is embedded in svchost.exe and is used to cheat attendance (click fraud);
@ 800000cf - communication module with the command center, embedded in winlogon.exe, and then into the browser installed on the computer. In the address space of the browser, a code is executed that communicates at fixed IP addresses and port 13620 with the command center. The IP list is in a file with a name similar to CLSID.
In x64 mode, no innovation was observed. The boot module was saved as% windir% \ system32 \ consrv.dll, the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ SubSystems registry key was set to run, the string "consrv: ConServerDllInitialization" was inserted into the "Windows" key. To mask their files as storage, the Global Assembly Cache (GAC) system directory of $ windir \ assembly was used, which is used to display the installed .Net components and does not directly show its contents in Explorer, which does not roll in FAR and TotalCommander. The directory was created for storage $ windir \ assembly \ tmp, where the modules were placed in an encrypted form.
An interesting feature of this version of ZeroAccess is the use of live bait technology for breaking off antiviruses. In addition to its main driver-rootkit, ZeroAccess had an additional kernel driver to create a "bait" - an object on which anti-virus protection tools "pecked". This driver created the device \ Device \ svchost.exe and saved the fake PE file as \ Device \ svchost.exe \ svchost.exe, access to which was monitored by the rootkit. If any application tried to access it, ZeroAccess would immediately terminate it. To terminate the application stream, about two hundred bytes of code that called ExitProcess () were injected into it using the APC method. But this was not all that would prevent subsequent launches of the completed application, for its executable file ZeroAccess reset the access rules ACL, allowing the reading and execution of the file. Thus, once hooked, the antivirus could no longer start.
Give P2P!
In order to improve vitality, the developers began to use various tricks. The main focus was on the ability of ZeroAccess to work with any access rights, as well as countering the blocking of command centers. When launched in Windows Vista / Seven, an attempt was made to improve their rights. Since the UAC bypass bug through explorer in explorer.exe was fixed, the hijacking DLL was used to raise the rights, its essence - the OS first looks for the necessary DLL in the current directory, and then in the system directory, therefore, placing the DLL in the directory of the legitimate program that matches the name of one of the imported libraries, you can get the launch of malicious code. To implement this method on board the dropper, in the embedded CAB file,
The file fp.exe was present. It was a legal online Adobe Flash Player installer, which was also digitally signed with VeriSign. The installer was saved under the name FlashPlayerInstaller.exe in the temp directory, in the same directory previously placed file msimg32.dll, whose name matches one of the imported DLL.
Rootkit x86 mode, as before, placed in the trap system. Now it was the service that started the file \ systemroot \ 3439254774: 153289011.exe, while the file 3439254774 was of zero size, and 153289011.exe was stored in ADS and was taken from wsc32.
In 64-bit Windows Vista / Seven mode, if there were administrator rights, a scheme with consrv.dll and $ windir \ assembly was used. If there were no such rights, it was not fatal, including in the XP environment. After all, the most important innovation is the “X” file, which implements P2P based on the TCP protocol for distribution of its modules, as well as the bootstrap list with the name “@”, the “U” and “L” directories, were placed in places accessible for recording with custom rights:
XP -% UserProfile% \ Application Data \ [8 digit hex code];
Vista / Seven -% UserProfile% \ AppData \ Local \ [8 digit hex code].
P2P technology in the service of malware
Using P2P allows you to completely abandon the concept of a control center for a botnet; you can manage or distribute new versions of a bot from any infected computer. P2P (peer-to-peer, peer-to-peer network) consists of a large number of computers, each of which contains some information about other such computers, in particular, an IP address. The list of a certain number of such computers (peers, peer, node, node) is called the bootstrap list (initial initialization list). Depending on where this list comes from, there are partially decentralized and fully decentralized P2P networks.
Partially decentralized P2P networks assume that the bootstrap list is loaded from previously known servers, this is how uTorrrent works. In such a system there is a weak spot - just block access to servers containing the bootstrap list. Therefore, malware often uses a fully decentralized scheme. A fully decentralized P2P network applied to malware means that distribution will take place in two stages. At the first stage, a bot is distributed with an empty bootstrap list or no P2P functions at all; it periodically calls on the command center, which records the bot's IP address. In addition to the IP address itself, the botnet operators are interested in information whether the bot is behind the gateway (gateway) or firewall. If this is not the case, then the bot can act as a super peer (super peer, super node), that is, other peers can connect to it. As soon as the required number of superpirs is typed, their list is entered into the bootstrap list, and the new version of the bot with it begins to be distributed by intruders. After distribution, all bots exchange information about their neighbors and form their own bootstrap list. The result is a P2P network. It is resistant to the disappearance of a certain number of bots, as the list of neighbors is constantly changing. During the exchange, bots also exchange information about their version. If the bot detects that it or its modules are “out of date”, a new version is downloaded from one of its neighbors. When downloading, as a rule, the digital signature of the file is checked in order to exclude the possibility of distribution of "extraneous" files. Thus, all bots in P2P keep themselves up to date.
Partially decentralized P2P networks assume that the bootstrap list is loaded from previously known servers, this is how uTorrrent works. In such a system there is a weak spot - just block access to servers containing the bootstrap list. Therefore, malware often uses a fully decentralized scheme. A fully decentralized P2P network applied to malware means that distribution will take place in two stages. At the first stage, a bot is distributed with an empty bootstrap list or no P2P functions at all; it periodically calls on the command center, which records the bot's IP address. In addition to the IP address itself, the botnet operators are interested in information whether the bot is behind the gateway (gateway) or firewall. If this is not the case, then the bot can act as a super peer (super peer, super node), that is, other peers can connect to it. As soon as the required number of superpirs is typed, their list is entered into the bootstrap list, and the new version of the bot with it begins to be distributed by intruders. After distribution, all bots exchange information about their neighbors and form their own bootstrap list. The result is a P2P network. It is resistant to the disappearance of a certain number of bots, as the list of neighbors is constantly changing. During the exchange, bots also exchange information about their version. If the bot detects that it or its modules are “out of date”, a new version is downloaded from one of its neighbors. When downloading, as a rule, the digital signature of the file is checked in order to exclude the possibility of distribution of "extraneous" files. Thus, all bots in P2P keep themselves up to date.
The launch of the “X” file was prescribed in the Shell parameter of the HKEY_CURRENT_USER \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon branch. Thus, the functioning of ZeroAccess was supported from under an account with limited rights, even if it was without rootkit functions.
According to Sophos, the active distribution of the P2P TCP-based version began in September-November 2011, while the first samples appeared in late July. Antivirus analysts point out that this version downloaded two main types of payload - click fraud and spambot, which are easy to identify by the ports used (21810, 22292 and 34354, 34355, respectively).
The Bootstrap list contained 256 values ​​of IP addresses, for each of which a timestamp (POSIX) was specified for the last call. All P2P network packets were encrypted using the RC4 algorithm with a static key.
The following command types were supported:
“GetL” - request for bootstrap list;
"RetL" is the response with the contents of the bootstrap list;
"GetF" - a request for a file;
"SetF" - the answer with the contents of the file;
"Srv?" - request for a list of files.
By the way, the type of command is not a string, but a 4-byte word, it is easier to compare them. The name of the module file of eight HEX characters was also encoded in 4 bytes.
For each node in the current bootstrap list, a “getL” command was sent. The remote computer had to respond with the “retL” command and send its bootstrap list. The resulting list, created on the basis of the current and the one sent, contained nodes with the access time closest to the current one. In response to the “srv?” Request, a list of files was sent, each entry in the list contained two fields: the file name of 4 bytes and the timestamp for creating the file. When “fresh” files were detected, they were updated by the “getF”, “setF” commands. Each loadable module had to contain the resource “33333” containing the RSA digital signature with a key of 512 bits. The signature was checked before running the file.
There were some implementation flaws in the P2P protocol. Having formed a 256 IP bootstrap list with obviously larger timestamp values ​​than the current time, it was possible to poison the bootstrap list of all nodes, which would make it impossible to distribute modules over the P2P network. If an arbitrary file was placed in the repository (note — the value of the milliseconds field in the time_field structure of the file should have been zero), it was pumped out by remote peers, although its launch was impossible due to signature verification. This made it possible to create a load on the network and thereby draw attention to the anomalous network traffic on the computer with further detection and removal of ZeroAccess. These deficiencies were corrected in the next implementation of P2P.
Wave the rootkit
May 2012 - that's when the time ended when the nuclear-level driver was part of ZeroAccess, now all the work was done in usermode. Looking into the contents of the CAB file, you can find that the rtk32 and rtk64 components have disappeared from it, but w32, w64, e32, e64 have been added.
The rootkit component is not present, respectively, the Windows driver in this version is not overwritten, one of two methods can be used to start at boot time - the COM hijacking technique, which uses the system registry, and modification of the services.exe file.
Using COM, hijacking launches a file called “n” (n32 or n64), which is responsible for the operation of the P2P network. A dropper creates two identical files “n” in the following two places:
% Windir% \ installer \ [UID];
% UserProfile% \ local settings \ application data \ [UID] (for XP and below) or% UserProfile% \ AppData \ Local \ [UID] (for Vista and above).
Here, the UID is the value generated by the dropper based on the MD5 hash from the time the system disk was created and formatted to look like a CLSID, for example {e051c979-bddd-5d1f-8953-4b8c940e9b4d}. The specified directories also create subdirectories “U” (for additional modules) and “L” (for temporary files), as well as the file “@” (s32 or s64).
One “n” file uses the hijacking COM object associated with WMI, and the following registry key is modified: HKCR \ CLSID \ {F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1} \ InprocServer32.
Another file "n" uses to start a COM object in the branch:
HKCU \ Software \ Classes \ clsid \ {42aedc87-2188-41fd-b9a3-0c966feabec1}.
The services.exe file was modified in an interesting way: a small shell-code (w32 or w64) was inserted into the file, which by calling the ZwQueryEaFile () function loaded the tail of the malicious code (e32 or e64) from the Extended Attributes file previously saved there using the ZwSetEaFile () The functionality of the PE files in the e32 and e64 components was identical to n32 and n64.
Later versions hide their files inside C: \ $ Recycle.Bin or C: \ RECYCLER,
where the directory was created with the name corresponding to the CLSID of the computer user. If there were administrator rights, another directory was created with CLSID S-1-5-18 (LOCAL_SYSTEM). Inside, a subdirectory was created with a random name formed by MD5 hashing of the current time. To start each of the two copies of the file “n”, the following COM objects were created:
HKCU \ Software \ Classes \ clsid \ {fbeb8a05-beee-4442-804e-409d6c4515e9} - for a user with limited rights;
HKCR \ CLSID \ {5839FCA9-774D-42A1-ACDA-D6A79037F57F} - for a user with administrator rights.
The algorithm of the P2P network has undergone some changes. Depending on the bitness of the OS, different ports were used: 16464 and 16470 for x32, 16465 and 16471 for x64. Thus, 4 independent P2P networks were organized, each of which used its own RSA key, the length of which was increased from 512 to 1024 bits. As before, there was a division by type of payload, ports 16464 and 16465 were used with the release with click fraud payload, 16470 and 16471 - with the release with bitcoin miner payload.
If earlier P2P used only TCP, now the list of IP addresses was requested via UDP, and the list of files (modules) via TCP. The “retL” command now returned only 16 values ​​from its bootstrap list (counteraction to the “poisoning” of the bootstrap list), in the same data block information about the available modules was transmitted. The bootstrap list now did not indicate the absolute timestamp value, but the difference between the current time and the time of the last access. Information about the modules used was transmitted in the form of a header consisting of the fields File name, Timestamp, Size. A digital signature was attached to the header (MD5 hash, encrypted with the malicious key of the attacker). The signature was checked for correctness at boot time and saved in the Extended Attributes file. Thus, cryptographic protection against outside interference was present both at the content level (as in the previous version, the “33333” resource containing a digital signature), and at the level of the name, creation date, and file size. The file itself was encrypted with the RC4 key during transmission. To force the change of the bootstrap list, the NewL command was introduced, which could be used when the attackers detected the antivirus company’s sinkhole in the peer list to restore the status quo. All of these differences from the previous version of P2P implementation were designed to eliminate the potential for disrupting the botnet.
The composition of loadable modules varies for different versions. For example, the click fraud version with a P2P 16464 port usually downloads three files:
800000cb. @ - click fraud module, registers a class named z00clicker3;
00000001. @ - dll used as a resource storage (data for 800000cb. @);
80000000. @ - tracking module, designed to collect statistics on infections, information about the infected system is sent to livecounter.co/count.php.
The version with bitcoin miner used a slightly different set of modules:
000000cb. @ - click fraud module;
80000000. @ - tracking module;
80000032. @, 80000064. @ - module bitcoin miner (x32 and x64);
00000004. @, 00000008. @ - dll, used as a resource storage (data for 80000032. @ and 80000064. @).
In addition to these, the loading of modules for redirecting search requests, sending spam and downloading arbitrary files is noted.
Conclusion
The ZeroAccess example well illustrates the principle of Occam's razor - do not multiply entities unnecessarily, or in a simple way - do not complicate. , , ZeroAccess, , , , P2P.
Sophos ZeroAccess 2012 9 , 1 . Kindsight Security «Malware Report» 3 2012 2.2 , 685 (31 %) . , ZeroAccess 2012 .
, , , ZeroAcces — . Ring-0 , «Access» . , . — , .
Source: https://habr.com/ru/post/193320/
All Articles