Introduction

Talos recently published a technical analysis of a backdoor which was included with version 5.33 of the CCleaner application. During our investigation we were provided an archive containing files that were stored on the C2 server. Initially, we had concerns about the legitimacy of the files. However, we were able to quickly verify that the files were very likely genuine based upon the web server configuration files and the fact that our research activity was reflected in the contents of the MySQL database included in the archived files.

In analyzing the delivery code from the C2 server, what immediately stands out is a list of organizations, including Cisco, that were specifically targeted through delivery of a second-stage loader. Based on a review of the C2 tracking database, which only covers four days in September, we can confirm that at least 20 victim machines were served specialized secondary payloads. Below is a list of domains the attackers were attempting to target. Not all companies identified in the targets .php file were seen communicating with a secondary C2 or had a secondary payload deployed.

Interestingly the array specified contains Cisco's domain (cisco.com) along with other high-profile technology companies. This would suggest a very focused actor after valuable intellectual property.

These new findings raise our level of concern about these events, as elements of our research point towards a possible unknown, sophisticated actor. These findings also support and reinforce our previous recommendation that those impacted by this supply chain attack should not simply remove the affected version of CCleaner or update to the latest version, but should restore from backups or reimage systems to ensure that they completely remove not only the backdoored version of CCleaner but also any other malware that may be resident on the system.

Technical Details

Web Server

The contents of the web directory taken from the C2 server included a series of PHP files responsible for controlling communications with infected systems. The attacker used a symlink to redirect all normal traffic requesting 'index.php' to the 'x.php' file, which contains the malicious PHP script.

In analyzing the contents of the PHP files, we identified that the server implemented a series of checks to determine whether to proceed with standard operations or simply redirect to the legitimate Piriform web site. The contents of the HTTP Host header, the request method type, and the server port are checked to confirm that they match what is expected from beacons sent from infected systems.

The PHP contains references to the required table for information storage within the 'x.php' variables as defined:

Within 'init.php' the $db_table is declared to allow insertion into the required database on the attacker infrastructure. This is 'Server' as defined below.

The web server also contains a second PHP file (init.php) that defines core variables and operations used. Interestingly, this configuration specifies "PRC" as the time zone, which corresponds with People's Republic of China (PRC). It’s important to note that this cannot be relied on for attribution. It also specifies the database configuration to use, as well as the filename and directory location to use for the variable $x86DllName.

The following information is gathered from infected systems, which is later used to determine how to handle those hosts. This includes OS version information, architecture information, whether the user has administrative rights, as well as the hostname and domain name associated with the systems.

The system profile information was rather aggressive and included specific information such as a list of software installed on the machine and all current running processes on the machine with no surprise that 'CCleaner.exe' was a current running process on the victim machine. The system profile information is then stored in the MySQL database.

There is also functionality responsible for loading and executing the Stage 2 payload on systems that meet the predefined requirements, similar to functionality that we identified would be required in our previous analysis of Stage 1. While there is shellcode associated with both x86 and x64 PE delivery, it appears that only the x86 PE loading functionality is actually utilized by the C2 server.

And below is the shellcode associated with the x64 version of the PE Loader.

The PHP script later compares the system beaconing to the C2 to three values: $DomainList, $IPList, and $HostList. This is to determine if the infected system should be delivered a Stage 2 payload. Below is condensed PHP code that demonstrates this:

The use of domain-based filtering further indicates the targeted nature of this attack. While we have confirmed that the number of systems affected by the backdoor was large based upon beacon information stored within the MySQL database, the attackers were specifically controlling which infected systems were actually delivered a Stage 2 payload. While it was reported that no systems executed a Stage 2 payload, this is not accurate. In analyzing the database table storing information on the systems that were delivered a Stage 2 payload, we identified 20 unique hosts that may have been affected by this payload. The functionality present within Stage 2 is documented in the "Stage 2 Payloads" section of this post.

MySQL Database

The C2 MySQL database held two tables: one describing all machines that had reported to the server and one describing all machines that received the second-stage download, both of which had entries were dated between Sept. 12th and Sept. 16th. Over 700,000 machines reported to the C2 server over this time period, and more than 20 machines have received the second-stage payload. It is important to understand that the target list can be and was changed over the period the server was active to target different organizations.

During the compromise, the malware would periodically contact the C2 server and transmit reconnaissance information about infected systems. This information included IP addresses, online time, hostname, domain name, process listings, and more. It's quite likely this information was used by the attackers to determine which machines they should target during the final stages of the campaign.

The main connection data is stored in the "Server" table. Here is an example of one of Talos' hosts in that database table:

In addition, the compromised machines would share a listing of installed programs.

A process list was also captured.

When combined, this information would be everything an attacker would need to launch a later stage payload that the attacker could verify to be undetectable and stable on a given system.

A second database table, separate from the 'Server' database table, contained an additional information set that was associated with systems that had actually been delivered the Stage 2 payload. This table contained similar survey information to the 'Server' database table, the structure of which is shown below:

In analyzing this second database table 'OK', we can confirm that after deduplicating entries, 20 systems were successfully delivered the Stage 2 payload. Talos reached out to the companies confirmed affected by this Stage 2 payload to alert them of a possible compromise.

Based on analysis of the 'Server' database table, it is obvious this infrastructure provides attackers access to a variety of different targets. Given the filtering in place on the C2 server, the attackers could add or remove domains at any given time, based upon the environments or organizations they choose to target. To provide additional perspective regarding the types of systems that the attackers could choose to further compromise, the screenshot below shows the number of total entries that were contained within the database table used to store system profile information:

The following screenshot shows the number of affected government systems around the world.

Likewise, looking at compromised systems belonging to domains containing the word 'bank' returns the following results:

This demonstrates the level of access that was made available to the attackers through the use of this infrastructure and associated malware and further highlights the severityand potential impact of this attack.

Stage 2 Payloads

The stage 2 installer is GeeSetup_x86.dll. This installer checks the OS version and then drops either a 32-bit or 64-bit version of a trojanized tool. The x86 version is using a trojanized TSMSISrv.dll, which drops VirtCDRDrv (which matches the filename of a legitimate executable that is part of Corel) using a similar method to the backdoored CCleaner tool. The x64 version drops a trojanized EFACli64.dll file named SymEFA which is the filename taken from a legitimate executable that is part of "Symantec Endpoint". None of the files that are dropped are signed or legitimate.

Effectively, they patch a legitimate binary to package their malware. Additionally, the setup put an encoded PE in the registry :

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

The purpose of the trojanized binary is to decode and execute this PE in registry. This PE performs queries to additional C2 servers and executes in-memory PE files. This may complicate detection on some systems since the executable files are never stored directly on the file system.

Within the registry is a lightweight backdoor module which is run by the trojanized files. This backdoor retrieves an IP from data stegged into a github.com or wordpress.com search, from which an additional PE module is downloaded and run. The stage 3 payload also reaches out to "get.adoble.net"

Code Reuse

Talos has reviewed claims from Kaspersky researchers that there is code overlap with malware samples known to be used by Group 72. While this is by no means proof in terms of attribution, we can confirm the overlap and we agree that this is important information to be considered.

On the left: 2bc2dee73f9f854fe1e0e409e1257369d9c0a1081cf5fb503264aa1bfe8aa06f (CCBkdr.dll)

On the right: 0375b4216334c85a4b29441a3d37e61d7797c2e1cb94b14cf6292449fb25c7b2 (Missl backdoor - APT17/Group 72)

Conclusion

Supply chain attacks seem to be increasing in velocity and complexity. It's imperative that as security companies we take these attacks seriously. Unfortunately, security events that are not completely understood are often downplayed in severity. This can work counter to a victim's best interests. Security companies need to be conservative with their advice before all of the details of the attack have been determined to help users ensure that they remain protected. This is especially true in situations where entire stages of an attack go undetected for a long period of time. When advanced adversaries are in play, this is especially true. They have been known to craft attacks that avoid detection by specific companies through successful reconnaissance techniques.

In this particular example, a fairly sophisticated attacker designed a system which appears to specifically target technology companies by using a supply chain attack to compromise a vast number of victims, persistently, in hopes to land some payloads on computers at very specific target networks.

Coverage

Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Indicators of Compromise (IOCs)
Below are indicators of compromise associated with this attack.

Installer on the CC: dc9b5e8aa6ec86db8af0a7aa897ca61db3e5f3d2e0942e319074db1aaccfdc83 (GeeSetup_x86.dll)

64-bit trojanized binary: 128aca58be325174f0220bd7ca6030e4e206b4378796e82da460055733bb6f4f (EFACli64.dll)

32-bit trojanized binary: 07fb252d2e853a9b1b32f30ede411f2efbb9f01e4a7782db5eacf3f55cf34902 (TSMSISrv.dll)

DLL in registry: f0d1f88c59a005312faad902528d60acbf9cd5a7b36093db8ca811f763e1292a

Registry Keys:

• 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
  

Stage 2 Payload (SHA256):

dc9b5e8aa6ec86db8af0a7aa897ca61db3e5f3d2e0942e319074db1aaccfdc83