September 11, 2013 at 14:02Zero without a stick?
Published in Hacker Magazine # 171 (April 2013)
Over time, some malicious programs become original brands in the cyberdegrand environment. As a rule, they are widespread in comparison with other malware and use various technological chips. These include the families of Sality, Conficker, Waledac, Zeus, TDL and many others. No matter how anti-virus companies fight such threats, as they say, sometimes they come back. The logic of using the untwisted name to attackers cannot be denied. Parsing the functionality of the next "little animals", you unwittingly ask yourself the question - when did it all start? And it turns out that neither a year nor two ago. One such family will be described later.
Start
The history of ZeroAccess (aka MAX ++) began in June 2009. It was then that a malware sample was discovered that used a path like \\? \ 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 the alternative 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 a decoy, in case the antivirus software tried to access it, ZeroAccess immediately terminated the scanning process. Afterwards,
Stepbrother TDL3
In January 2010 ZeroAccess creators began to distribute a new version of their offspring. For this, the RBN Ecatel network resources were used. A distinctive feature of the new version of ZeroAccess was an explicit borrowing of TDL3 ideas, namely, launching through a driver infection and using hidden storage for its components.
Installation on the system began with a dropper file, for example, with the name keygen.exe. For normal operation, administrator rights were necessary, which in the conditions of disguise as a keygen for a favorite toy was not a special problem. When installing on the disk, no temporary working files were extracted, all manipulations occurred in memory. To start when loading the OS, we used the boot method using the ZwLoadDriver () function. First and foremost, the victim driver existing in the system was selected, falling under several necessary signs: the driver name should be in the range from Ndis.sys to Win32k.sys, the size should be 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 started at boot, This was checked by the Start flag (0 - do not load) in the services registry branch. Choosing the appropriate driver, ZeroAccess completely rewrote it with its code, after disabling SFC. Next, a registry entry was created about a new service with a random name and parameters Type = 0x1, Start = 0x3. The trick was that ImagePath was set to \ * for the service, and for \ * using the ZwCreateSymbolicLinkObject () function, a symlink to the rewritten driver was created. The specified service started by calling ZwLoadDriver (). The launched rootkit was registered via an IoCreateDriver () call as an OS driver, to intercept the I / O operation at the IRP level of the miniport driver packages of the disk subsystem. Next, a virtual device was created with the fixed name \ ?? \ C2CAD972 # 4079 # 4fd3 # A68D # AD34CC121074, to which the previously created repository file is mounted under the name% system% \ Config \ [random symbols] .sav. Now the dropper could access his storage through a virtual device. After formatting the storage in a compressed NTFS volume using the fmifs.dll library functions, all other components, including a copy of a clean driver, were saved there. The file structure is shown in the figure.
The rootkit function was to hide the contents of the overwritten driver; when trying to read it, the rootkit demonstrated the saved source file. In addition, the rootkit initiated the launch of the B48DADF8.sys injector, which injected the main DLL module with the name max ++. 00.x86 into the address space of the browser via APC. You may notice that during the operation the direct start functions are not used at all, so as not to trigger the proactive protection of antiviruses. The main module had the functions of communicating with the command center and spoofing search results to redirect the user to malicious sites offering to download fake antivirus (FakeAV). Connection parameters were taken from files in the repository with names similar to the 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 made. 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 load the rootkit, the same start method was used via ZwLoadDriver () with minor changes. Now the drivers were selected from the range from classpnp.sys to win32k.sys, the size of which is more 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 to access the repository was of the form \\? \ ACPI # PNP0303 # 2 & da1a3ff & 0 (it could change from release to release). The storage file of 16 megabytes in size% system% \ Config \ [random symbols] this time was not compressed, but was encrypted with a 128-bit static key RC4, decryption was performed on the fly by the rootkit driver when accessing the files contained in the storage. A pronounced modular structure has appeared,
modules were loaded from a remote server. To communicate with the command center, a connection was established on port 13620. The requests and responses themselves were transmitted in encrypted form.
Work on x64 and self-defense tricks
Until April 2011, 64-bit versions of the OS were not infected by 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 operation algorithm was similar to the previous version and the rootkit worked at the kernel level. In contrast, on x64, everything worked in usermode.
As you know, starting with Vista, Windows introduced UAC, a component of the system that asks for confirmation of actions that require administrator rights. UAC, of course, slightly increased the security level of Windows, but, as always, evil hackers ruined everything. Many system programs, such as trusted ones (for example, explorer.exe) are rigidly registered in UAC, therefore the code that triggers for other applications does not work for them at the default setting. This feature was used in the ZeroAccess dropper to raise its privileges in the system to the administrator level, while the UAC window was not shown to the user (this bug was fixed over time).
To bypass the traffic monitoring tools in the HTTP HOST request header, the domain name generated in the .cn zone, generated with the help of Domain Generator Algorithm (DGA), was used; it does not really resolve to DNS servers. In response to a request with an invalid HOST header, the server returned an empty response. That is, the server generated the value in the same way and compared it with what came 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. One should only note the next change in the storage format in July, now it was not a file, but a directory of the form C: \ WINDOWS \ $ NtUninstallKBxxxxx $, where xxxxx is 5 generated digits. This name was chosen in order to disguise it as the working directory for updating the Windows OS. Access to it was blocked by creating a symbolic link from $ NtUninstallKBxxxxx $ to% systemroot% \ system32 \ config, as well as by 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.
A brief description of the components downloaded from the Internet:
@ 00000001 - backup copy of the dropper;
@ 80000000 - tracking module, designed to collect infection statistics, information about the infected system was sent to counter.yadro.ru;
@ 800000c0 - a fake mswsock.dll library for intercepting WinSocks functions, monitoring them allowed stealing FTP passwords and logins, as well as implementing JavaScript in HTML pages;
@ 000000c0 - the module implements JavaScript to change the issuance of search queries and sends the data of FTP accounts to a remote server;
@ 800000cb - the module is implemented in svchost.exe and is used to increase traffic (click fraud);
@ 800000cf - a module for communication with the command center, it is implemented in winlogon.exe, and then in the browser installed on the computer. In the address space of the browser, 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 the CLSID.
In x64 mode, no innovation was observed. The boot module was saved as% windir% \ system32 \ consrv.dll, to run it, the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ SubSystems registry branch was edited, the string "consrv: ConServerDllInitialization" was inserted into the value of the "Windows" key. To disguise their files, the Global Assembly Cache (GAC) system directory of the $ windir \ assembly type was used as storage, which is used to display installed .Net components and does not directly display its contents in Explorer, which does not work in FAR and TotalCommander. For storage, the $ windir \ assembly \ tmp directory was created, where the modules were located in encrypted form.
An interesting feature of this version of ZeroAccess is the use of fishing for live bait to break antiviruses. In addition to its main rootkit driver, ZeroAccess had an additional kernel driver for creating a “bait” - an object that anti-virus protection tools had been pecking at. 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 a rootkit. If any application tried to access it, then ZeroAccess terminated it immediately. To complete the application flow, about two hundred bytes of code that ExitProcess () called were injected into it using the APC method. But that was not all, to prevent subsequent launches of the completed application, for its executable file ZeroAccess reset ACL access rules that allowed reading and execution of the file.
Give P2P!
In order to increase survivability, developers began to use various tricks. The main emphasis was on the ability to work ZeroAccess with any access rights, as well as counteraction to the blocking of command centers. When launched in Windows Vista / Seven, an attempt was made to elevate its rights. Since the bug with bypassing UAC through the injection in explorer.exe was fixed, hijacking DLL was used to raise the rights, its essence is that the OS first looks for the necessary DLL in the current directory, and then in the system, therefore, placing a DLL with the name of the legitimate program that matches the name of one of the imported libraries, malicious code can be launched. To implement this method on board the dropper, in the embedded CAB file,
the fp.exe file was present. It was a legal online installer for Adobe Flash Player, which was also digitally signed with VeriSign. The installer was saved under the name FlashPlayerInstaller.exe in the temp directory, the msimg32.dll file, the name of which coincides with one of the imported DLLs, was previously placed in the same directory.
The x86 mode rootkit, as before, set traps in the system. Now it was a service that ran the \ systemroot \ 3439254774: 153289011.exe file, while the 3439254774 file was of zero size, and 153289011.exe was stored in ADS and was taken from wsc32.
In Windows Vista / Seven 64-bit mode, if you had administrator rights, the scheme with consrv.dll and $ windir \ assembly was used. If there were no such rights, it was not fatal, including in the XP environment. Indeed, the most important innovation is the “X” file, which implements P2P on the basis of the TCP protocol for distributing its modules, as well as the bootstrap list with the name “@”, the “U” and “L” directories, were located in places accessible for recording with user permissions:
XP -% UserProfile% \ Application Data \ [8 digit hex code];
Vista / Seven -% UserProfile% \ AppData \ Local \ [8 digit hex code].
The launch of the “X” file was registered 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 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. Anti-virus analysts note 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 IP address values, for each of which the timestamp (POSIX) of the last call was indicated. All P2P network packets were encrypted using the RC4 algorithm with a static key.
The following types of commands were supported:
"getL" - a request for a bootstrap list;
“RetL” is the response with the contents of the bootstrap list;
"GetF" - a request for a file;
“SetF” - response with the contents of the file;
"Srv?" - a request for a list of files.
By the way, the type of command is not a string, but a 4 byte word, it’s easier to compare them. The module file name of eight HEX characters was also encoded with 4 bytes.
For each node in the current bootstrap list, a getL command was sent. The remote computer should respond with the “retL” command and forward its bootstrap list. The resulting list, created on the basis of the current and sent, contained nodes with the access time closest to the current. In response to the request “srv?” A list of files was sent, each entry in the list contained two fields: a file name of 4 bytes and a timestamp for creating the file. When "fresh" files were found, they were updated with the commands "getF", "setF". Each loadable module had to contain a “33333” resource, containing a digital signature RSA with a 512-bit key. The signature was verified before running the file.
There were some implementation flaws in the P2P protocol. Having formed a bootstrap list of 256 IP with a knownly higher timestamp than the current time, it was possible to “poison” the bootstrap list of all nodes, which would make it impossible to distribute the modules over the P2P network. If you put an arbitrary file in the repository (note - the value of the milliseconds field in the time_field structure of the file should be equal to zero), it was pumped out by remote peers, although its launch was impossible due to signature verification. This allowed you to create a load on the network and thereby draw attention to the abnormal network traffic on the computer with further detection and removal of ZeroAccess. These flaws were corrected in the next P2P implementation.
Wave the rootkit with a pen
May 2012 - that’s the time when ZeroAccess included a kernel-level driver, now all the work was done in usermode. Looking at the contents of the CAB file, you can find that rtk32 and rtk64 components have disappeared from it, but w32, w64, e32, e64 have been added.
There is no rootkit component, respectively, the Windows driver in this version is not overwritten, to start when the system boots up, one of two methods can be used - the COM hijacking technique, which uses the system registry, and the modification of the services.exe file.
Using COM hijacking, a file with the name “n” (n32 or n64), which is responsible for the operation of the P2P network, is launched for execution. A dropper creates two identical “n” files 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 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}. Subdirectories “U” (for additional modules) and “L” (for temporary files), as well as the “@” file (s32 or s64) are also created in these directories.
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 the object in the branch to run the COM:
HKCU \ Software \ Classes \ clsid \ {42aedc87-2188-41fd-b9a3-0c966feabec1}.
Modification of the services.exe file was carried out 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 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 a directory with a name corresponding to the CLSID of the computer user was created. 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 “n” file, 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 P2P network operation algorithm has undergone some changes. Different ports were used depending on the OS bit: 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 separation according to the type of payload, ports 16464 and 16465 were used by the release with click fraud payload, 16470 and 16471 - 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) by TCP. The “retL” command now returned only 16 values from its bootstrap list (counteracting the “poisoning” of the bootstrap list), information about the available modules was transmitted in the same data block. The bootstrap list now indicated not the absolute value of timestamp, but the difference between the current time and the time of the last call. 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 private key of the attackers). The signature was checked for correctness upon loading and stored in the Extended Attributes file. Thus, cryptographic protection against extraneous interference was available both at the content level (as in the previous version, the “33333” resource containing a digital signature) and at the level of name, creation date and file size. The file itself was encrypted with an RC4 key during transmission. To force a change in the bootstrap list, the NewL command was introduced, which could be used when sinkhole detectors detected an anti-virus company in the peer list to restore the status quo. All these differences from the P2P implementation of the previous version were designed to eliminate the potential possibility of disrupting the botnet. which could be used when an anti-virus company detected a sinkhole in the peers list to restore the status quo. All these differences from the P2P implementation of the previous version were designed to eliminate the potential possibility of disrupting the botnet. which could be used when an anti-virus company detected a sinkhole in the peers list to restore the status quo. All these differences from the P2P implementation of the previous version were designed to eliminate the potential possibility of disrupting the botnet.
The composition of downloadable modules varies for different versions. For example, a version of click fraud with a P2P port of 16464 usually downloads three files:
800000cb. @ - module click fraud, registers a class with the name z00clicker3;
00000001. @ - dll used as a storage of resources (data for 800000cb. @);
80000000. @ - tracking module, designed to collect infection statistics, information about the infected system is sent to livecounter.co/count.php.
The bitcoin miner version used a slightly different set of modules:
000000cb. @ - click fraud module;
80000000. @ - tracking module;
80000032. @, 80000064. @ - bitcoin miner module (x32 and x64);
00000004. @, 00000008. @ - dll used as a storage of resources (data for 80000032. @ and 80000064. @).
In addition to the indicated ones, the loading of modules for redirecting search queries, spamming and downloading arbitrary files was noted.
Conclusion The
ZeroAccess example illustrates well the principle of Occam's razor - do not multiply entities unnecessarily, or in a simple way - do not complicate. Having begun as a technological development and having lost the rootkit component during its evolution, ZeroAccess, nevertheless, successfully continues to exist, and even acquired such a fashionable feature as P2P.
According to Sophos, the number of computer infections with the ZeroAccess bot at the end of August 2012 was more than 9 million, and about 1 million active bots. In the report of the Kindsight Security lab “Malware Report” for the 3rd quarter of 2012, 2.2 million infected systems are already mentioned, of which 685 thousand (31%) are in the United States. According to experts, the ZeroAccess-based botnet was the most active in 2012.
In the light of these numbers, I think there is no one left with doubts that ZeroAcces is not zero without a stick. Although Ring-0 is no longer used, Access to the computing power of unsuspecting users continues to bring a bunch of evergreen American papers by attackers. This means that antivirus companies have something to work on. Readers would like to remind once again - saving your iron friend from a Trojan adversity is entirely on your conscience, be careful.
Over time, some malicious programs become original brands in the cyberdegrand environment. As a rule, they are widespread in comparison with other malware and use various technological chips. These include the families of Sality, Conficker, Waledac, Zeus, TDL and many others. No matter how anti-virus companies fight such threats, as they say, sometimes they come back. The logic of using the untwisted name to attackers cannot be denied. Parsing the functionality of the next "little animals", you unwittingly ask yourself the question - when did it all start? And it turns out that neither a year nor two ago. One such family will be described later.
Start
The history of ZeroAccess (aka MAX ++) began in June 2009. It was then that a malware sample was discovered that used a path like \\? \ 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 the alternative 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 a decoy, in case the antivirus software tried to access it, ZeroAccess immediately terminated the scanning process. Afterwards,
Stepbrother TDL3
In January 2010 ZeroAccess creators began to distribute a new version of their offspring. For this, the RBN Ecatel network resources were used. A distinctive feature of the new version of ZeroAccess was an explicit borrowing of TDL3 ideas, namely, launching through a driver infection and using hidden storage for its components.
Installation on the system began with a dropper file, for example, with the name keygen.exe. For normal operation, administrator rights were necessary, which in the conditions of disguise as a keygen for a favorite toy was not a special problem. When installing on the disk, no temporary working files were extracted, all manipulations occurred in memory. To start when loading the OS, we used the boot method using the ZwLoadDriver () function. First and foremost, the victim driver existing in the system was selected, falling under several necessary signs: the driver name should be in the range from Ndis.sys to Win32k.sys, the size should be 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 started at boot, This was checked by the Start flag (0 - do not load) in the services registry branch. Choosing the appropriate driver, ZeroAccess completely rewrote it with its code, after disabling SFC. Next, a registry entry was created about a new service with a random name and parameters Type = 0x1, Start = 0x3. The trick was that ImagePath was set to \ * for the service, and for \ * using the ZwCreateSymbolicLinkObject () function, a symlink to the rewritten driver was created. The specified service started by calling ZwLoadDriver (). The launched rootkit was registered via an IoCreateDriver () call as an OS driver, to intercept the I / O operation at the IRP level of the miniport driver packages of the disk subsystem. Next, a virtual device was created with the fixed name \ ?? \ C2CAD972 # 4079 # 4fd3 # A68D # AD34CC121074, to which the previously created repository file is mounted under the name% system% \ Config \ [random symbols] .sav. Now the dropper could access his storage through a virtual device. After formatting the storage in a compressed NTFS volume using the fmifs.dll library functions, all other components, including a copy of a clean driver, were saved there. The file structure is shown in the figure.
The rootkit function was to hide the contents of the overwritten driver; when trying to read it, the rootkit demonstrated the saved source file. In addition, the rootkit initiated the launch of the B48DADF8.sys injector, which injected the main DLL module with the name max ++. 00.x86 into the address space of the browser via APC. You may notice that during the operation the direct start functions are not used at all, so as not to trigger the proactive protection of antiviruses. The main module had the functions of communicating with the command center and spoofing search results to redirect the user to malicious sites offering to download fake antivirus (FakeAV). Connection parameters were taken from files in the repository with names similar to the 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 made. Given the cost of such a “gift” from $ 30 to $ 100, it appears that this business was quite profitable.
The relationship between ZeroAccess and TDL3
In January 2010, a version appeared in the TDL3 family in which the payload file was not called cmd.dll, but Z00clicker.dll. It would seem, where does ZeroAccess? The thing is that the Z00clicker line was subsequently 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 the operation of TDL3 (the latest version, with names like TDL4), by deleting the cfg.ini configuration file and cmd.dll module from the TDL repository (if TDL4 were the target, cmd64.dll should also be deleted). An interesting fact, in addition to the “Kill TDL” function, is the distribution of the Z00clicker2.dll module, designed to increase website visits. The latest version of ZeroAccess contains a module responsible for click fraud, which creates a class called z00clicker3.
Some experts, such as Webroot spokesman Jacques Erasmus, say the TDL3 source code was sold to ZeroAccess developers. It happened around the end of 2009 - beginning of 2010. So it is possible that the TDL3 version with Z00clicker.dll and ZeroAcess are the results of a third-party development based on the TDL3 source code. At the same time, Kaspersky Lab employees say that there is no connection between TDL3 and ZeroAcess. According to them, rather, we can talk about reverse engineering and borrowing ideas from TDL3.
Some experts, such as Webroot spokesman Jacques Erasmus, say the TDL3 source code was sold to ZeroAccess developers. It happened around the end of 2009 - beginning of 2010. So it is possible that the TDL3 version with Z00clicker.dll and ZeroAcess are the results of a third-party development based on the TDL3 source code. At the same time, Kaspersky Lab employees say that there is no connection between TDL3 and ZeroAcess. According to them, rather, we can talk about reverse engineering and borrowing ideas from TDL3.
In 2011, an updated version appeared. To load the rootkit, the same start method was used via ZwLoadDriver () with minor changes. Now the drivers were selected from the range from classpnp.sys to win32k.sys, the size of which is more 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 to access the repository was of the form \\? \ ACPI # PNP0303 # 2 & da1a3ff & 0 (it could change from release to release). The storage file of 16 megabytes in size% system% \ Config \ [random symbols] this time was not compressed, but was encrypted with a 128-bit static key RC4, decryption was performed on the fly by the rootkit driver when accessing the files contained in the storage. A pronounced modular structure has appeared,
modules were loaded from a remote server. To communicate with the command center, a connection was established on port 13620. The requests and responses themselves were transmitted in encrypted form.
Work on x64 and self-defense tricks
Until April 2011, 64-bit versions of the OS were not infected by 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 operation algorithm was similar to the previous version and the rootkit worked at the kernel level. In contrast, on x64, everything worked in usermode.
As you know, starting with Vista, Windows introduced UAC, a component of the system that asks for confirmation of actions that require administrator rights. UAC, of course, slightly increased the security level of Windows, but, as always, evil hackers ruined everything. Many system programs, such as trusted ones (for example, explorer.exe) are rigidly registered in UAC, therefore the code that triggers for other applications does not work for them at the default setting. This feature was used in the ZeroAccess dropper to raise its privileges in the system to the administrator level, while the UAC window was not shown to the user (this bug was fixed over time).
To bypass the traffic monitoring tools in the HTTP HOST request header, the domain name generated in the .cn zone, generated with the help of Domain Generator Algorithm (DGA), was used; it does not really resolve to DNS servers. In response to a request with an invalid HOST header, the server returned an empty response. That is, the server generated the value in the same way and compared it with what came 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. One should only note the next change in the storage format in July, now it was not a file, but a directory of the form C: \ WINDOWS \ $ NtUninstallKBxxxxx $, where xxxxx is 5 generated digits. This name was chosen in order to disguise it as the working directory for updating the Windows OS. Access to it was blocked by creating a symbolic link from $ NtUninstallKBxxxxx $ to% systemroot% \ system32 \ config, as well as by 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.
A brief description of the components downloaded from the Internet:
@ 00000001 - backup copy of the dropper;
@ 80000000 - tracking module, designed to collect infection statistics, information about the infected system was sent to counter.yadro.ru;
@ 800000c0 - a fake mswsock.dll library for intercepting WinSocks functions, monitoring them allowed stealing FTP passwords and logins, as well as implementing JavaScript in HTML pages;
@ 000000c0 - the module implements JavaScript to change the issuance of search queries and sends the data of FTP accounts to a remote server;
@ 800000cb - the module is implemented in svchost.exe and is used to increase traffic (click fraud);
@ 800000cf - a module for communication with the command center, it is implemented in winlogon.exe, and then in the browser installed on the computer. In the address space of the browser, 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 the CLSID.
In x64 mode, no innovation was observed. The boot module was saved as% windir% \ system32 \ consrv.dll, to run it, the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ SubSystems registry branch was edited, the string "consrv: ConServerDllInitialization" was inserted into the value of the "Windows" key. To disguise their files, the Global Assembly Cache (GAC) system directory of the $ windir \ assembly type was used as storage, which is used to display installed .Net components and does not directly display its contents in Explorer, which does not work in FAR and TotalCommander. For storage, the $ windir \ assembly \ tmp directory was created, where the modules were located in encrypted form.
An interesting feature of this version of ZeroAccess is the use of fishing for live bait to break antiviruses. In addition to its main rootkit driver, ZeroAccess had an additional kernel driver for creating a “bait” - an object that anti-virus protection tools had been pecking at. 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 a rootkit. If any application tried to access it, then ZeroAccess terminated it immediately. To complete the application flow, about two hundred bytes of code that ExitProcess () called were injected into it using the APC method. But that was not all, to prevent subsequent launches of the completed application, for its executable file ZeroAccess reset ACL access rules that allowed reading and execution of the file.
Give P2P!
In order to increase survivability, developers began to use various tricks. The main emphasis was on the ability to work ZeroAccess with any access rights, as well as counteraction to the blocking of command centers. When launched in Windows Vista / Seven, an attempt was made to elevate its rights. Since the bug with bypassing UAC through the injection in explorer.exe was fixed, hijacking DLL was used to raise the rights, its essence is that the OS first looks for the necessary DLL in the current directory, and then in the system, therefore, placing a DLL with the name of the legitimate program that matches the name of one of the imported libraries, malicious code can be launched. To implement this method on board the dropper, in the embedded CAB file,
the fp.exe file was present. It was a legal online installer for Adobe Flash Player, which was also digitally signed with VeriSign. The installer was saved under the name FlashPlayerInstaller.exe in the temp directory, the msimg32.dll file, the name of which coincides with one of the imported DLLs, was previously placed in the same directory.
The x86 mode rootkit, as before, set traps in the system. Now it was a service that ran the \ systemroot \ 3439254774: 153289011.exe file, while the 3439254774 file was of zero size, and 153289011.exe was stored in ADS and was taken from wsc32.
In Windows Vista / Seven 64-bit mode, if you had administrator rights, the scheme with consrv.dll and $ windir \ assembly was used. If there were no such rights, it was not fatal, including in the XP environment. Indeed, the most important innovation is the “X” file, which implements P2P on the basis of the TCP protocol for distributing its modules, as well as the bootstrap list with the name “@”, the “U” and “L” directories, were located in places accessible for recording with user permissions:
XP -% UserProfile% \ Application Data \ [8 digit hex code];
Vista / Seven -% UserProfile% \ AppData \ Local \ [8 digit hex code].
P2P technology at the service of malware
Using P2P allows you to completely abandon the concept of a control center for a botnet; management or distribution of new bot versions can be done 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 the IP address. A list of a number of such computers (peers, peers, nodes, nodes) is called bootstrap list (initial initialization list). Depending on where this list comes from, partially decentralized and fully decentralized P2P networks are distinguished.
Partially decentralized P2P networks require loading the bootstrap list from previously known servers, so uTorrrent works. There is a weak point in such a system - it is enough to block access to the servers containing the bootstrap list. Therefore, malware often uses a fully decentralized scheme. A fully decentralized P2P network for malware implies that the 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 the command center, which fixes the bot's IP address. In addition to the IP address itself, botnet operators are interested in information whether the bot is located behind a gateway or a firewall. If this is not so, then the bot can act as a super peer (super peer, super node), that is, other feasts can be connected to it. As soon as the necessary number of super-peers is collected, their list is entered in the bootstrap list, and a new version of the bot with it begins to spread by attackers. 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 the neighbors. When downloading, as a rule, the digital signature of the file is checked to exclude the possibility of distribution of "extraneous" files. Thus, all bots in P2P keep themselves up to date.
Partially decentralized P2P networks require loading the bootstrap list from previously known servers, so uTorrrent works. There is a weak point in such a system - it is enough to block access to the servers containing the bootstrap list. Therefore, malware often uses a fully decentralized scheme. A fully decentralized P2P network for malware implies that the 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 the command center, which fixes the bot's IP address. In addition to the IP address itself, botnet operators are interested in information whether the bot is located behind a gateway or a firewall. If this is not so, then the bot can act as a super peer (super peer, super node), that is, other feasts can be connected to it. As soon as the necessary number of super-peers is collected, their list is entered in the bootstrap list, and a new version of the bot with it begins to spread by attackers. 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 the neighbors. When downloading, as a rule, the digital signature of the file is checked 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 registered 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 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. Anti-virus analysts note 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 IP address values, for each of which the timestamp (POSIX) of the last call was indicated. All P2P network packets were encrypted using the RC4 algorithm with a static key.
The following types of commands were supported:
"getL" - a request for a bootstrap list;
“RetL” is the response with the contents of the bootstrap list;
"GetF" - a request for a file;
“SetF” - response with the contents of the file;
"Srv?" - a request for a list of files.
By the way, the type of command is not a string, but a 4 byte word, it’s easier to compare them. The module file name of eight HEX characters was also encoded with 4 bytes.
For each node in the current bootstrap list, a getL command was sent. The remote computer should respond with the “retL” command and forward its bootstrap list. The resulting list, created on the basis of the current and sent, contained nodes with the access time closest to the current. In response to the request “srv?” A list of files was sent, each entry in the list contained two fields: a file name of 4 bytes and a timestamp for creating the file. When "fresh" files were found, they were updated with the commands "getF", "setF". Each loadable module had to contain a “33333” resource, containing a digital signature RSA with a 512-bit key. The signature was verified before running the file.
There were some implementation flaws in the P2P protocol. Having formed a bootstrap list of 256 IP with a knownly higher timestamp than the current time, it was possible to “poison” the bootstrap list of all nodes, which would make it impossible to distribute the modules over the P2P network. If you put an arbitrary file in the repository (note - the value of the milliseconds field in the time_field structure of the file should be equal to zero), it was pumped out by remote peers, although its launch was impossible due to signature verification. This allowed you to create a load on the network and thereby draw attention to the abnormal network traffic on the computer with further detection and removal of ZeroAccess. These flaws were corrected in the next P2P implementation.
Wave the rootkit with a pen
May 2012 - that’s the time when ZeroAccess included a kernel-level driver, now all the work was done in usermode. Looking at the contents of the CAB file, you can find that rtk32 and rtk64 components have disappeared from it, but w32, w64, e32, e64 have been added.
There is no rootkit component, respectively, the Windows driver in this version is not overwritten, to start when the system boots up, one of two methods can be used - the COM hijacking technique, which uses the system registry, and the modification of the services.exe file.
Using COM hijacking, a file with the name “n” (n32 or n64), which is responsible for the operation of the P2P network, is launched for execution. A dropper creates two identical “n” files 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 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}. Subdirectories “U” (for additional modules) and “L” (for temporary files), as well as the “@” file (s32 or s64) are also created in these directories.
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 the object in the branch to run the COM:
HKCU \ Software \ Classes \ clsid \ {42aedc87-2188-41fd-b9a3-0c966feabec1}.
Modification of the services.exe file was carried out 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 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 a directory with a name corresponding to the CLSID of the computer user was created. 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 “n” file, 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 P2P network operation algorithm has undergone some changes. Different ports were used depending on the OS bit: 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 separation according to the type of payload, ports 16464 and 16465 were used by the release with click fraud payload, 16470 and 16471 - 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) by TCP. The “retL” command now returned only 16 values from its bootstrap list (counteracting the “poisoning” of the bootstrap list), information about the available modules was transmitted in the same data block. The bootstrap list now indicated not the absolute value of timestamp, but the difference between the current time and the time of the last call. 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 private key of the attackers). The signature was checked for correctness upon loading and stored in the Extended Attributes file. Thus, cryptographic protection against extraneous interference was available both at the content level (as in the previous version, the “33333” resource containing a digital signature) and at the level of name, creation date and file size. The file itself was encrypted with an RC4 key during transmission. To force a change in the bootstrap list, the NewL command was introduced, which could be used when sinkhole detectors detected an anti-virus company in the peer list to restore the status quo. All these differences from the P2P implementation of the previous version were designed to eliminate the potential possibility of disrupting the botnet. which could be used when an anti-virus company detected a sinkhole in the peers list to restore the status quo. All these differences from the P2P implementation of the previous version were designed to eliminate the potential possibility of disrupting the botnet. which could be used when an anti-virus company detected a sinkhole in the peers list to restore the status quo. All these differences from the P2P implementation of the previous version were designed to eliminate the potential possibility of disrupting the botnet.
The composition of downloadable modules varies for different versions. For example, a version of click fraud with a P2P port of 16464 usually downloads three files:
800000cb. @ - module click fraud, registers a class with the name z00clicker3;
00000001. @ - dll used as a storage of resources (data for 800000cb. @);
80000000. @ - tracking module, designed to collect infection statistics, information about the infected system is sent to livecounter.co/count.php.
The bitcoin miner version used a slightly different set of modules:
000000cb. @ - click fraud module;
80000000. @ - tracking module;
80000032. @, 80000064. @ - bitcoin miner module (x32 and x64);
00000004. @, 00000008. @ - dll used as a storage of resources (data for 80000032. @ and 80000064. @).
In addition to the indicated ones, the loading of modules for redirecting search queries, spamming and downloading arbitrary files was noted.
Conclusion The
ZeroAccess example illustrates well the principle of Occam's razor - do not multiply entities unnecessarily, or in a simple way - do not complicate. Having begun as a technological development and having lost the rootkit component during its evolution, ZeroAccess, nevertheless, successfully continues to exist, and even acquired such a fashionable feature as P2P.
According to Sophos, the number of computer infections with the ZeroAccess bot at the end of August 2012 was more than 9 million, and about 1 million active bots. In the report of the Kindsight Security lab “Malware Report” for the 3rd quarter of 2012, 2.2 million infected systems are already mentioned, of which 685 thousand (31%) are in the United States. According to experts, the ZeroAccess-based botnet was the most active in 2012.
In the light of these numbers, I think there is no one left with doubts that ZeroAcces is not zero without a stick. Although Ring-0 is no longer used, Access to the computing power of unsuspecting users continues to bring a bunch of evergreen American papers by attackers. This means that antivirus companies have something to work on. Readers would like to remind once again - saving your iron friend from a Trojan adversity is entirely on your conscience, be careful.
