Author Topic: CCleanup: A Vast Number of Machines at Risk 1of2  (Read 690 times)

Offline javajolt

  • Administrator
  • Hero Member
  • *****
  • Posts: 35122
  • Gender: Male
  • I Do Windows
    • windows10newsinfo.com
CCleanup: A Vast Number of Machines at Risk 1of2
« on: September 18, 2017, 11:18:50 PM »
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. The Nyetya worm that was released into the wild earlier in 2017 showed just how potent these types of attacks can be. Frequently, as with Nyetya, the initial infection vector can remain elusive for quite some time. Luckily with tools like AMP the additional visibility can usually help direct attention to the initial vector.

Talos recently observed a case where the download servers used by software vendor to distribute a legitimate software package were leveraged to deliver malware to unsuspecting victims. For a period of time, the legitimate signed version of CCleaner 5.33 being distributed by Avast also contained a multi-stage malware payload that rode on top of the installation of CCleaner. CCleaner boasted over 2 billion total downloads by November of 2016 with a growth rate of 5 million additional users per week. Given the potential damage that could be caused by a network of infected computers even a tiny fraction of this size we decided to move quickly. On September 13, 2017 Cisco Talos immediately notified Avast of our findings so that they could initiate appropriate response activities. The following sections will discuss the specific details regarding this attack.

TECHNICAL DETAILS
 
CCleaner is an application that allows users to perform routine maintenance on their systems. It includes functionality such as cleaning of temporary files, analyzing the system to determine ways in which performance can be optimized and provides a more streamlined way to manage installed applications.


Figure 1: Screenshot of CCleaner 5.33

On September 13, 2017 while conducting customer beta testing of our new exploit detection technology, Cisco Talos identified a specific executable which was triggering our advanced malware protection systems. Upon closer inspection, the executable in question was the installer for CCleaner v5.33, which was being delivered to endpoints by the legitimate CCleaner download servers. Talos began initial analysis to determine what was causing this technology to flag CCleaner. We identified that even though the downloaded installation executable was signed using a valid digital signature issued to Piriform, CCleaner was not the only application that came with the download. During the installation of CCleaner 5.33, the 32-bit CCleaner binary that was included also contained a malicious payload that featured a Domain Generation Algorithm (DGA) as well as hardcoded Command and Control (C2) functionality. We confirmed that this malicious version of CCleaner was being hosted directly on CCleaner's download server as recently as September 11, 2017.

In reviewing the Version History page on the CCleaner download site, it appears that the affected version (5.33) was released on August 15, 2017. On September 12, 2017, version 5.34 was released. The version containing the malicious payload (5.33) was being distributed between these dates. This version was signed using a valid certificate that was issued to Piriform Ltd by Symantec and is valid through 10/10/2018. Piriform was the company that Avast recently acquired and was the original company who developed the CCleaner software application.


Figure 2: Digital Signature of CCleaner 5.33

A second sample associated with this threat was discovered. This second sample was also signed using a valid digital certificate, however the signing timestamp was approximately 15 minutes after the initial sample was signed.

The presence of a valid digital signature on the malicious CCleaner binary may be indicative of a larger issue that resulted in portions of the development or signing process being compromised. Ideally this certificate should be revoked and untrusted moving forward. When generating a new cert care must be taken to ensure attackers have no foothold within the environment with which to compromise the new certificate. Only the incident response process can provide details regarding the scope of this issue and how to best address it.

Interestingly the following compilation artifact was found within the CCleaner binary that Talos analyzed:

        S:\workspace\ccleaner\branches\v5.33\bin\CCleaner\Release\CCleaner.pdb

Given the presence of this compilation artifact as well as the fact that the binary was digitally signed using a valid certificate issued to the software developer, it is likely that an external attacker compromised a portion of their development or build environment and leveraged that access to insert malware into the CCleaner build that was released and hosted by the organization. It is also possible that an insider with access to either the development or build environments within the organization intentionally included the malicious code or could have had an account (or similar) compromised which allowed an attacker to include the code.

It is also important to note that while previous versions of the CCleaner installer are currently still available on the download server, the version containing the malicious payloads has been removed and is no longer available.

MALWARE INSTALLATION AND OPERATION

Within the 32-bit CCleaner v5.33 binary included with the legitimate CCleaner v5.33 installer, '__scrt_get_dyn_tls_init_callback' was modified to call to the code at CC_InfectionBase(0x0040102C). This was done to redirect code execution flow within the CCleaner binary to the malicious code prior to continuing with the normal CCleaner operations. The code that is called is responsible for decrypting data which contains the two stages of the malicious payload, a PIC (Position Independent Code) PE loader as well as a DLL file that effectively functions as the malware payload. The malware author had tried to reduce the detection of the malicious DLL by ensuring the IMAGE_DOS_HEADER was zeroed out, suggesting this attacker was trying to remain under the radar to normal detection techniques.

The binary then creates an executable heap using HeapCreate(HEAP_CREATE_ENABLE_EXECUTE,0,0). Space is then allocated to this new heap which is where the contents of the decrypted data containing the malware is copied. As the data is copied to the heap, the source data is erased. The PE loader is then called and begins its operation. Once the infection process has been initiated, the binary erases the memory regions that previously contained the PE loader and the DLL file, frees the previously allocated memory, destroys the heap and continues on with normal CCleaner operations.

The PE loader utilizes position independent coding practices in order to locate the DLL file within memory. It then maps the DLL into executable memory, calls the DLLEntryPoint to begin execution of the DLL being loaded and the CCleaner binary continues as normal. Once this occurs the malware begins its full execution, following the process outlined in the following sections.

CBkrdr.dll

The DLL file (CBkdr.dll) was modified in an attempt to evade detection and had the IMAGE_DOS_HEADER zeroed out. The DLLEntryPoint creates an execution thread so that control can be returned to the loader. This thread is responsible for calling CCBkdr_GetShellcodeFromC2AndCall. It also sets up a Return Oriented Programming (ROP) chain that is used to deallocate the memory associated with the DLL and exit the thread.
CCBkrdr_GetShellcodeFromC2AndCall

This function is responsible for much of the malicious operations that Talos observed while analyzing this malware. First, it records the current system time on the infected system. It then delays for 601 seconds before continuing operations, likely an attempt to evade automated analysis systems that are configured to execute samples for a predefined period of time or determine whether the malware is being executed in a debugger. In order to implement this delay functionality, the malware calls a function which attempts to ping 224.0.0.0 using a delay_in_seconds timeout set to 601 seconds. It then checks to determine the current system time to see if 600 seconds has elapsed. If that condition is not met, the malware terminates execution while the CCleaner binary continues normal operations. In situations where the malware is unable to execute IcmpCreateFile, it then falls back to using Sleep() to implement the same delay functionality. The malware also compares the current system time to the value stored in the following registry location:

        HKLM\SOFTWARE\Piriform\Agomo:TCID

If the value stored in TCID is in the future, the malware will also terminate execution.


Figure 3: Delay Routine

The malware then checks to determine the privileges assigned to the user running on the system. If the current user running the malicious process is not an administrator the malware will terminate execution.


Figure 4: Privilege Check

If the user executing the malware does have administrative privileges on the infected system, SeDebugPrivilege is enabled for the process. The malware then reads the value of 'InstallID' which is stored in the following registry location:

        HKLM\SOFTWARE\Piriform\Agomo:MUID

If this value does not exist, the malware creates it using '((rand()*rand() ^ GetTickCount())'.

Once the aforementioned activities have been performed, the malware then begins profiling the system and gathering system information which is later transmitted to the C2 server. System information is stored in the following data structure:


Figure 5: CCBkdr_System_Information Data Structure

Once the system information has been collected, it is encrypted and then encoded using modified Base64. The malware then establishes a Command and Control (C2) channel as described in the following section.

source