32-bit CCleaner 5.33, CCleaner Cloud 1.07 compromised, introduced backdoor

A mere two months ago, Czech antivirus company Avast acquired Recuva, Speccy, and CCleaner developer Piriform for an undisclosed amount of money. Apparently, CCleaner in particular has been a tad of a headache for its parent company recently.

According to an announcement on its official blog, Piriform stated that the 32-bit versions of both CCleaner 5.33.6162 - released on August 14, updated to a non-compromised version September 12 - and CCleaner Cloud 1.07.3191 - released August 24, updated to a non-compromised version on September 15 - were part of a "security incident".

Although Piriform states that it discovered some suspicious activity on September 12 and issued an update for CCleaner the same day, researchers at Cisco Talos state that they informed Avast of the issue relating to the two aforementioned programs on September 13. Regardless, perhaps a little more concerning that the mismatched timeline, the compromised executable was actually digitally signed using a valid certificate from the developer. About 2.27 million users have been affected, according to Avast CTO, Ondrej Vlcek.

The two-stage backdoor that was identified was capable of running code from "a 3rd party computer server in the USA" and to cause the transmission of "non-sensitive data (computer name, IP address, list of installed software, list of active software, list of network adapters)".

Due to the company contacting law enforcement, and the nature of the investigation, the issue hadn't been disclosed previously, however, the unauthorized server was shut down on the 15 of this month.

Hidden through "encrypted strings" and "indirect API calls", the malicious load was run just before the main application's code, specifically performing the following actions:

• 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.

However, the extent of obfuscation of this backdoor went a few steps further. All collected information was encrypted by base64 via a custom alphabet, which pinged a hardcoded IP address, signaling the delivery of the second stage of the malicious package. There was even a backup DGA (domain generation algorithm) in case the hardcoded IP address could not be reached, but since the domains generated were not controlled by the same person, Piriform deemed that they "do not pose any risk."

Source: Piriform via Graham Culey

Thanks to jrolson in the forums for the tip!