i CCleanup v5.33.6162 and CCleaner Cloud v1.07.3191 for 32-bit Windows users: A Vast Number of Machines at Risk – All things in moderation

CCleanup v5.33.6162 and CCleaner Cloud v1.07.3191 for 32-bit Windows users: A Vast Number of Machines at Risk

Supply chain attacks are a very effective way to distribute malicious software into target organizations. This is because with supply chain attacks, the attackers are relying on the trust relationship between a manufacturer or supplier and a customer. This trust relationship is then abused to attack organizations and individuals and may be performed for a number of different reasons.

On September 13, 2017, the Talos security research group (Cisco subsidiary) has tracked many of the cases in which software download servers brought malware to users. In a short span of time, CCleaner’s reliable version 5.33 software provided by Avast itself has included malware, which affects millions of computers.

The impact of this attack could be severe given the extremely high number of systems possibly affected. CCleaner claims to have over 2 billion downloads worldwide as of November 2016 and is reportedly adding new users at a rate of 5 million a week.

If even a small fraction of those systems were compromised an attacker could use them for any number of malicious purposes. Affected systems need to be restored to a state before August 15, 2017 or reinstalled. Users should also update to the latest available version of CCleaner to avoid infection.

Technical description
An unauthorized modification of the CCleaner.exe binary resulted in an insertion of a two-stage backdoor capable of running code received from a remote IP address on affected systems.
The suspicious code was hidden in the application’s initialization code called CRT (Common Runtime) that is normally inserted during compilation by the compiler. This code modification was executed by the following function calls (functions marked by red represent the CRT modifications):

This modification performed the following actions before the main application’s code:
– It decrypted and unpacked hardcoded shellcode (10 kB large) – simple XOR-based cipher was used for this.
– The result (16 kB in size) was a DLL (dynamic link library) with a missing MZ header.
– This DLL was subsequently loaded and executed in an independent thread.
– Afterwards, a normal execution of CRT code and main CCleaner continued, resulting in the thread with payload running in the background.

Illustration of patched CRT code (see the added call to a payload-decryption routine in the modified version):

The code executed within that thread was heavily obfuscated to make its analysis harder (encrypted strings, indirect API calls, etc.). The suspicious code was performing the following actions:
It stored certain information in the Windows registry key HKLM\SOFTWARE\Piriform\Agomo:
– MUID: randomly generated number identifying a particular system. Possibly also to be used as communication encryption key.
– TCID: timer value used for checking whether to perform certain actions (communication, etc.)
– NID: IP address of secondary CnC server
Besides that, it collected the following information about the local system:
– Name of the computer
– List of installed software, including Windows updates
– List of running processes
– MAC addresses of first three network adapters
– Additional information whether the process is running with administrator privileges, whether it is a 64-bit system, etc.
All of the collected information was encrypted and encoded by base64 with a custom alphabet.
The encoded information was subsequently submitted to an external IP address 216.126.x.x (this address was hardcoded in the payload, and we have intentionally masked its last two octets here) via a HTTPS POST request. There was also a [fake] reference to “Host: speccy.piriform.com” in communication.
The code then read a reply from the same IP address, providing it with the functionality to download a second stage payload from the aforementioned IP address. The second stage payload is received as a custom base64-encoded string, further encrypted by the same xor-based encryption algorithm as all the strings in the first stage code. We have not detected an execution of the second stage payload and believe that its activation is highly unlikely.
In case the IP address becomes unreachable, a backup in the form of DGA (domain name generator) activates and is used to redirect communication to a different location. Fortunately, these generated domains are not under the control of the attacker and do not pose any risk.

Some more information

File Hashes

DGA Domains

IP Addresses


Leave a Reply