A security incident that we have recently found in CCleaner version 5.33.6162

 

A security incident that we have recently found in CCleaner version 5.33.6162 and CCleaner Cloud version 1.07.3191. A suspicious activity was identified on September 12^th, 2017, where we saw an unknown IP address receiving data from software found in version 5.33.6162 of CCleaner, and CCleaner Cloud version 1.07.3191, on 32-bit Windows systems. Based on further analysis, we found that the 5.33.6162 version of CCleaner and the 1.07.3191 version of CCleaner Cloud was illegally modified before it was released to the public, and we started an investigation process. We also immediately contacted law enforcement units and worked with them on resolving the issue. Before delving into the technical details, let me say that the threat has now been resolved in the sense that the rogue server is down, other potential servers are out of the control of the attacker, and we’re moving all existing CCleaner v5.33.6162 users to the latest version. Users of CCleaner Cloud version 1.07.3191 have received an automatic update. In other words, to the best of our knowledge, we were able to disarm the threat before it was able to do any harm.

Technical descriptionAn 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.

At this stage, we don’t want to speculate how the unauthorized code appeared in the CCleaner software, where the attack originated from, how long it was being prepared and who stood behind it. The investigation is still ongoing.

http://www.piriform.com