We would like to update our customers and the general public on the latest findings regarding the investigation of the recent CCleaner security incident. As published in our previous blog posts (here and here), analysis of the CnC server showed that the incident was in fact an Advanced Persistent Threat (APT) attack, targeting specific high-tech and telecommunications companies. That is, despite the fact that CCleaner is a consumer product, the purpose of the attack was not to attack consumers and their data; instead, the CCleaner customers were used to gain access to corporate networks of select large enterprises.

Today, we are going to disclose new facts about the incident that we received since the last public update.

Introduction

As we already know, the CnC server contained important evidence in terms of the exact list of hosts with which the CnC server communicated, and the list of hosts to which it actually sent the 2nd stage payload (i.e. which actually became compromised in the sense that they could execute malicious code sent by the attacker). The problem was that due to a crash of the database, there were only about 3.5 days’ worth of data. Our hypothesis was that this occurred because of the server running out of disk space on September 10, leading the operator to a full rebuild of the database.

However, further investigation revealed that the attackers backed up the data from the crashed CnC server to another server before rebuilding the database.  Thanks to the continued work of the Avast Threat Labs team and the help from US law enforcement personnel. The server’s IP address was 216.126.225.163, it featured the same self-signed SSL certificate (issued for speccy.piriform.com) and stack-wise, had a typical “LAMP” configuration: CentOS release 6.9 with Apache 2.2.15,  PHP 5.3.3, but most importantly, a MySql database that turned out to contain data going back to August 18. Access to this backup server allowed us to assemble what we believe is the complete database (the only missing piece is a 40-hour window between 2017-09-10 19:03:18 and 2017-09-12 9:58:47 UTC, i.e. between the crash of the original CnC DB and the creation of the new one; it is not clear how the CnC server behaved in that period).

The main findings from the complete database are as follows:

• The total number of connections to the CnC server was 5,686,677.
• The total number of unique PCs (unique MAC addresses) that communicated with the CnC server was 1,646,536.
• The total number of unique PCs that received the 2nd stage payload was 40.

PCs and Companies that received the 2nd stage payload

The most important piece of information is the content of the “OK” table in the database, which lists the machines that successfully received the 2nd stage payload and were therefore really “infected” with potentially malicious code (although we haven’t been able to isolate that code yet, as it probably came from additional layers which are still the focus of additional investigation).

Here is the complete list of companies / domains affected, together with the number of impacted PCs:

We have reached out to all these companies, with the aim of providing them with detailed information about the incident, list of impacted computers, and additional IOCs that can be used to detect the infection and take corrective actions.

Worth noting is that about 40 PCs out of 2.27M had the compromised version of CCleaner product installed, i.e. 0.0018% of the total -- a truly targeted attack.

The list of companies (domains) evolved over time, and the detailed logs found on the SQL database server suggest that the bad actors were trying to identify suitable hosts not just by a pre-determined list, but also by looking into what kind of PC hosts have actually been available to them in the sense that they had PCs with CCleaner connecting to the CnC. Following is a list of targets that were of potential interest, but were not attacked by the 2nd stage payload:

Clearly, the logs also indicate that the attackers were looking for additional high-profile companies to target, some of them potentially leading to additional supply-chain attacks (Carriers / ISPs, server hosting companies and domain registrars).

Interestingly enough, the two corporations with the highest number of impacted PCs (cht.com.tw and nsl.ad.nec.co.jp) were actually missing in the list of targeted domains on the CnC server at the time it was taken down. This suggests that the attackers actively removed these companies from the list after the payload had been delivered. 

Origin of the attacker

In the previous post, we talked about the fact that there were multiple clues suggesting that the attack may be originating from China, including multiple instances of PHP code found on the CnC server, the myPhpAdmin logs, and the similarity of certain code snippets to a previous APT attack attributed to China.

The problem with all these indications is that they are all very easy to forge: they might have been added simply to make investigation more difficult and to hide the true origin.

So, during our investigation, we tried to take a slightly different approach. We noticed that there have been a relatively large number of operator connections to the CnC server; the server apparently required a lot of manual maintenance work. In total, the operator connected to the server 83 times (plus 17 more times to the backup server), to do various things from installing and setting up the systems to monitoring it and resolving respective issues, such as to fix the crashed database. Which made us think that this was in fact someone’s ‘day job’. The hypothesis was further supported by the fact that there were many fewer connections to the server on Saturdays, and almost no connections on Sundays.

Now, with that hypothesis in place, the obvious thing to do was to plot the operator connections to the server in a chart and try to determine the time zone in which the attacker resided.

The result looked like this:

There is a clear pattern, which is in fact quite typical for IT workers: an 8-hour working day, followed by 4-5 hours of inactivity in the afternoon/evening and then additional connections during a 5-hour block in the evenings.

Given the typical working day starts at 8AM or 9AM, this leads us to the most likely location of the attacker in the time zone UTC + 4 or UTC + 5, leading us to Russia or the eastern part of Middle East / Central Asia and India. Furthermore, given the clear lack of traffic on Saturdays and Sundays, it would indicate that it wasn’t an Arabic country.

Another possible explanation is that there were multiple people involved in the operation, each working from a different time zone.

It is worth noting that, despite there being a large number of tech / telco companies in China, Russia and India, there are no companies from these countries on the list of companies targeted by this attack.

Investigation process and next steps

We are continuing our investigation of the incident:  working with law enforcement, partner companies and a professional firm specializing in incident response operations to move quickly in the right direction.  Our security team has reached out to all companies proven to be part of the 2nd stage, and we’re committed to working with them to resolve the issue fully. Obviously, the fact that the 2nd stage payload has been delivered to a computer connected to a company network doesn’t mean that the company network has been compromised. However, proper investigation is in order and necessary to fully understand the impact and take remediation actions. From our side, we continue working on getting access and analyzing the additional stages of the payload (post stage 2). We will post an update as soon as we learn more.

IOCs

The following is an updated list of IOCs.