What is known about the CCleaner supply chain attack
An attack on a supply chain or an attack with the exploitation of trust in a third-party organization (supply-chain attacks) is a very effective way to spread malware to target organizations. This is due to the fact that in attacks on the supply chain, attackers take advantage of the trusting relationship between the manufacturer / supplier and the client to attack organizations and individuals for various reasons. The Petya / Nyetya / NePetya worm, which was released on the network in early 2017, showed how massive these types of attacks are. Often, as in the case of Petya, the initial attack vector may remain hidden for some time.
Recently, Talos researchers noticed a case where the download servers used by the development company to distribute a legitimate software package were used to download malware to computers of unsuspecting victims. For some period, the version of CCleaner 5.33 distributed by Avast contained a multi-stage malicious load. 5 million new users download CCleaner per week. Given the potential damage that could be caused by a network of infected computers of a similar size, it was decided to act quickly. On September 13, 2017, Cisco Talos notified Avast. The following sections will discuss specific details regarding this attack.
CCleaner is a utility that includes features such as cleaning temporary files, analyzing the system, identifying ways to optimize performance, as well as a more simplified way to manage installed applications.
Figure 1: Screenshot of CCleaner 5.33
On September 13, 2017, after beta testing customers with new exploit detection technology, Cisco Talos detected an executable file that was identified as malware. This was the CCleaner v5.33 installer from the legitimate CCleaner download servers. Talos conducted an initial analysis to determine what causes the security system to block CCleaner. They determined that although the downloaded executable was signed using a valid Piriform digital signature, CCleaner was not the only application that was downloaded. During the installation of CCleaner 5.33, the 32-bit CCleaner binary also contained a malicious load with the ability to use the domain generation algorithm (DGA), as well as command and control (Command and Control - C2) functions.
When viewing the version history page on the CCleaner download site, it turned out that version (5.33) was released on August 15, 2017. On September 12, 2017 , version 5.34 was released. The version containing the malicious load (5.33) was distributed between these dates. This version was signed using a valid certificate that was issued for Piriform Ltd, which was recently acquired by Avast, Symantec, and is valid until 10.10.2018.
Figure 2: Digital Signature of CCleaner 5.33
A second installer sample was also discovered associated with this threat. This sample was also signed using a valid digital certificate, however, the time stamp was approximately 15 minutes after the initial assembly was signed.
The presence of a valid digital signature in the CCleaner malicious binary may indicate a significant problem that caused violations during the development or signing process. Ideally, this certificate should be revoked. When creating a new certificate, you must ensure that attackers are not in an environment in which the new certificate could be compromised. It was only during the investigation that it was possible to collect detailed information about the extent of this problem and how to best solve it.
The following compilation artifact was found in the CCleaner binary:
S: \ workspace \ ccleaner \ branches \ v5.33 \ bin \ CCleaner \ Release \ CCleaner.pdb
Given this compilation artifact and the fact that the binary was digitally signed using a valid certificate, it is likely that an attacker from outside compromised part of the development or assembly environment and used this access to insert malicious code into the CCleaner assembly, which was issued by the organization. It is also possible that an insider who had access to development or assembly environments within the organization intentionally turned on malicious code or had a compromised account that allowed an attacker to modify the code.
It is important to note that although previous versions of the CCleaner installer are currently available on the download server, the version containing the malicious files has been removed and is no longer available.
Virus installation process
'__scrt_get_dyn_tls_init_callback' has been modified to run CC_InfectionBase (0x0040102C) code to redirect the code execution thread to malware before continuing with normal CCleaner operations. The called code is responsible for decrypting data that contains two levels of malicious load: a PIC loader (position-independent program code) and a DLL file.
Using HeapCreate (HEAP_CREATE_ENABLE_EXECUTE, 0,0), an executable heap is created. The content of decrypted data containing malware is copied to the heap, the original data is erased. Then the PE loader is called and its work begins. As soon as the infection process has begun, the binary code erases the memory areas that previously contained the PE loader and the DLL file, frees the previously allocated memory, destroys the heap, and continues to execute with normal CCleaner operations.
The PE loader uses position-independent coding techniques to find the .dll file in memory. Then it transfers the DLL to the executable memory and calls DLLEntryPoint to start its execution.
CCBkrdr_GetShellcodeFromC2AndCall is responsible for many of the malicious operations detected by Talos while analyzing this malware. Firstly, it records the current system time. Then it delays the execution of malicious code for 601 seconds, probably with the aim of evading automated analysis systems that are configured to scan for viruses in the debugger for a predetermined period of time. To implement this delay function, the malware calls a function that attempts to ping 18.104.22.168 using the delay_in_seconds timeout set to 601 seconds. He then determines the current system time to see if 600 seconds have passed. If this condition is not met, the virus terminates while CCleaner continues to be executed. In situations when malware cannot execute the IcmpCreateFile, it reverts to using the Sleep () function to implement the same delay function. The malware also compares the current system time with the value stored in the following registry key:
HKLM \ SOFTWARE \ Piriform \ Agomo: TCID
If the time stored in the TCID has not yet arrived, the virus will also stop execution.
Figure 3: Delay Procedure
The privileges assigned to the user are then checked. If the current user is not an administrator, the malware will stop executing.
Figure 4: Privilege check
If the user who runs the malware has administrator rights, SeDebugPrivilege is activated on the infected system. The malware then reads the “InstallID” value, which is stored in the following registry key:
HKLM \ SOFTWARE \ Piriform \ Agomo: Muid
If this value does not exist, the malware creates it using '((rand () * rand () ^ GetTickCount ( )) '.
Once the above actions have been completed, the virus begins collecting system information, which is later transmitted to the C2 server. System information is stored in the following data structure:
Figure 5: CCBkdr_System_Information data structure
After collecting information about the system, it is encrypted and encoded using a modified Base64. The malware then establishes communication with the command server (C2), as described in the next section.
Command and Control (C2)
As soon as the previously mentioned system information was collected and prepared for transmission to the C2 server, an attempt to transfer it using the POST HTTPS request to 216 [.] 126 [.] 225 [.] 148 begins.
Data received from the C2 server is checked to confirm that it is in the correct format for use in CCBkdr_ShellCode_Payload. An example is shown below:
Figure 6: CCBkdr_ShellCode_Payload data structure
After installing the virus, the usual CCleaner operations continue. The following is a diagram that describes the operation of this malware at a high level:
Figure 7: Diagram of the process of launching a malicious load
Domain Generation Algorithm
In situations where the main C2 server does not return a response to the HTTP POST request described in the previous section, the malicious program uses the DGA algorithm. In this case, it is time-based and can be calculated using the values of the current year and month. The following is a list of DGA domains:
Figure 8: generating domains for 12 months The
malware will initiate a DNS lookup for each domain generated by the DGA algorithm. If the DNS lookup does not return the IP address, this process will continue. The malware executes the DNS query of the active DGA domain and expects to receive two IP addresses from the domain name server. Then the malicious program will calculate the secondary server C2 by performing a series of bit operations with the received IP addresses and combining them to determine the new actual address of the command server. The diagram showing this process is shown below:
Figure 9: Determining the
Cisco Talos Command Server Address during the analysis determined that the DGA domains were not occupied, so they were registered and blocked so that attackers could not use them for their own purposes.
The impact of this attack can be serious, given the extremely large number of possible systems. CCleaner claims that as of November 2016, it has more than 2 billion downloads worldwide and is reported to have an increase of 5 million new users per week.
Figure 10: CCleaner statistics
Systems on which CCleaner was installed during the spread of the virus should be restored to its state on August 15, 2017 or reinstalled. Users must also upgrade to the latest CCleaner available to avoid infection. At the time of writing this version was version 5.34. It is important to note that, according to the CCleaner download page, the free version of CCleaner does not provide automatic updates, so this must be done manually.
When analyzing Cisco Umbrella telemetry data about the domains associated with this attack, Talos identified a significant number of systems that made the corresponding DNS queries. Since these domains have never been registered, it is reasonable to conclude that the only cause is this virus. Only domains related to August and September (which correlates with the time when this threat was active) show significant activity.
Figure 11: July DGA domain activity
As mentioned earlier, the CCleaner version that included this malware was released on August 15, 2017. The following graph shows a significant increase in DNS activity associated with the DGA domain used in August 2017:
Figure 12: Activity for the domain in August 2017
Figure 13: Activity for the domain in September 2017
After accessing Avast, it was noticed that the default C2 server became inaccessible to infected systems. As a result, we saw a significant increase in the number of requests directed to DGA domains.
Figure 14: Traffic after a server shutdown
It is also worth noting that as of September 18, antivirus detection of this threat remains very low (1/64).
Figure 15: Virus Detection Check
Later, during our research, we were provided with an archive containing files stored on the C2 server. Our research activities were reflected in the contents of the MySQL database included in the archive files, which confirmed the authenticity of the data.
When analyzing the code from the C2 server , a list of organizations that the second-level bootloader delivery was aimed at immediately stands out . Based on a review of the C2 tracking database, which covers only four days in September, we can confirm that at least 20 victim machines were infected with specialized malware. The following is a list of domains that attackers tried to target. Not for all companies identified in the .php file, an exchange with a C2 server was noticed.
A PHP script compares system beacons received from an infected machine for three values: $ DomainList, $ IPList and $ HostList. This is necessary to determine if the infected system should deliver the Stage 2 malicious load. The following is a compressed PHP code that demonstrates this:
The C2 database contained two tables: one describing all the machines that “communicated” with the server, and a description of all the cars that received the Stage 2 download. Moreover, both of them were dated from September 12 to September 16. Over this period, more than 700,000 machines were sent to the C2 server, and more than 20 machines received Stage 2 load. It is important to understand that the target list can be changed and was changed during the period when the server was active to infect target organizations.
During the compromise, malware periodically contacted the C2 server and transmitted information about infected systems. This information included IP addresses, time, hostname, domain, process lists, and more. This information was probably used by cybercriminals to determine which vehicles to target in the final stages of an attack.
The main connection data is stored in the Server table. Here is an example for one of the Talos nodes in this database table:
As well as a list of installed programs.
And the list of processes.
The second database table contained an additional data set associated with the systems to which the Stage 2 load was actually delivered. This table contained similar information, the structure of which is shown below:
Based on the analysis of the table, it is obvious that this infrastructure provides attackers with access to many different goals. Given the filtering on the C2 server, attackers can add or remove domains at any given time depending on the environment or organizations they are targeting. The screenshot below shows the number of records that were contained in the database table used to store system profiles:
The following screenshot shows the number of affected government systems around the world.
Vulnerable systems with a domain containing the word “bank”:
This demonstrates the level of access for attackers obtained by using this infrastructure, and also emphasizes the seriousness and potential impact of this attack.
Talos examined applications from Kaspersky Lab researchers that the code matches the malware samples that are known to be used by Group 72 . Although this is in no way evidence, we can confirm the agreement and agree that this is important information.
Left: 2bc2dee73f9f854fe1e0e409e1257369d9c0a1081cf5fb503264aa1bfe8aa06f (CCBkdr.dll)
Right: 0375b4216334c85a4b29441a3d37e61d7797c2e1cb94b14cf6292449fb25c7b2 (Missl backdoor - APT17 / Group 72)
Supply chain attacks are growing in speed and complexity. In this particular example, the attacker developed a system that appears to be specifically targeted at technology companies in order to compromise a huge number of machines. This reinforces concerns about these events and also confirms the recommendation that users who download CClenaer during the infection should not only delete the infected version of CCleaner or upgrade to the latest version, but also must restore data from backups to ensure complete removal of malware.
The following are indicators of compromise associated with this attack.
ab6d54340c1a [.] Com
aba9a949bc1d [.] Com
ab2da3d400c20 [.] Com
ab3520430c23 [.] Com
ab1c403220c27 [.] Com
ab1abad1d0c2a [.] Com
ab8cee60c2d [.] Com
ab1145b758c30 [.] Com
ab890e964c34 [.] Com
ab3d685a0c37 [.] com
[.] ab70a139cc3a com
[.] [.] 216 126 225 148 [.]
Installer on the CC: dc9b5e8aa6ec86db8af0a7aa897ca61db3e5f3d2e0942e319074db1aaccfdc83 (GeeSetup_x86.dll)
64 trojanized binary bit-
32 trojanized binary bit-: 07fb252d2e853a9b1b32f30ede411f2efbb9f01e4a7782db5eacf3f55cf34902 (TSMSISrv.dll)
DLL in registry: f0d1f88c59a005312faad902528d60acbf9cd5a7b36093db8ca811f763e1292a
HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ WbemPerf \ 001
HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ WbemPerf \ 002
HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ WbemPerf \ 003
HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ WbemPerf \ 004
HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ WbemPerf \ HBP