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
6f7840c77f99049d788155c1351e1560b62b8ad18ad0e9adda8218b9f432f0a9
1a4a5123d7b2c534cb3e3168f7032cf9ebf38b9a2a97226d0fdb7933cf6030ff
36b36ee9515e0a60629d2c722b006b33e543dce1c8c2611053e0651a0bfdb2e9

DGA Domains
ab6d54340c1a[.]com
aba9a949bc1d[.]com
ab2da3d400c20[.]com
ab3520430c23[.]com
ab1c403220c27[.]com
ab1abad1d0c2a[.]com
ab8cee60c2d[.]com
ab1145b758c30[.]com
ab890e964c34[.]com
ab3d685a0c37[.]com
ab70a139cc3a[.]com

IP Addresses
216[.]126[.]225[.]148

Reference:
http://www.piriform.com
http://blog.talosintelligence.com

Leave a Reply