Book a Demo
Back to blog

Evidence Aurora Operation Still Active: Supply Chain Attack Through CCleaner

Written by
No author image
Jay Rosenberg

Check out our follow up blog here: Evidence Aurora Operation Still Active Part 2: More Ties Uncovered Between CCleaner Hack & Chinese Hackers

Recently, there have been a few attacks with a supply chain infection, such as Shadowpad being implanted in many of Netsarang’s products, affecting millions of people. You may have the most up to date cyber security software, but when the software you are trusting to keep you protected gets infected there is a problem.  A backdoor, inserted into legitimate code by a third party with malicious intent, leads to millions of people being hacked and their information stolen.

Avast’s CCleaner software had a backdoor encoded into it by someone who had access to the supply chain.  Through somewhere that had access to the source code of CCleaner, the main executable in v5.33.6162 had been modified to include a backdoor. The official statement from Avast can be found here

The Big Connection:

Costin Raiu, director of Global Research and Analysis Team at Kaspersky Lab, was the first to find a code connection between APT17 and the backdoor in the infected CCleaner:

Using Intezer Analyze™, we were able to verify the shared code between the backdoor implanted in CCleaner and earlier APT17 samples. The photo below is the result of uploading the CCBkdr module to Intezer Analyze™, where the results show there is an overlap in code. With our technology, we can compare code to a huge database of malicious and trusted software — that’s how we can prove that this code has never been seen before in any other software.

Technical Analysis:

A deeper analysis leads us to the functions shown below. The code in question is a unique implementation of base64 only previously seen in APT17 and not in any public repository, which makes a strong case about attribution to the same threat actor.

This code connection is huge news. APT17, also known as Operation Aurora, is one of the most sophisticated cyber attacks ever conducted and they specialize in supply chain attacks. In this case, they probably were able to hack CCleaner’s build server in order to plant this malware. Operation Aurora started in 2009 and to see the same threat actor still active in 2017 could possibly mean there are many other supply chain attacks by the same group that we are not aware of. The previous attacks are attributed to a Chinese group called PLA Unit 61398.

Technical Analysis:

The infected CCleaner file that begins the analysis is from 6f7840c77f99049d788155c1351e1560b62b8ad18ad0e9adda8218b9f432f0a9

A technical analysis was posted by Talos here (http://blog.talosintelligence.com/2017/09/avast-distributes-malware.html).

The flow-graph of the malicious CCleaner is as follows (taken from the Talos report):

Technical Analysis

Infected function:

Infected function

Load and execute the payload code:

Load and execute the payload code

After the embedded code is decrypted and executed, the next step is a PE (portable executable) file loader. A PE file loader basically emulates the process of what happens when you load an executable file on Windows. Data is read from the PE header, from a module created by the malware author.

The PE loader first begins by resolving the addresses of imports commonly used by loaders and calling them. GetProcAddress to get the addresses of external necessary functions, LoadLibraryA to load necessary modules into memory and get the address of the location of the module in memory, VirtualAlloc to create memory for somewhere to copy the memory, and in some cases, when not implemented, and memcpy to copy the buffer to the newly allocated memory region.

The PE loader

After the module is copied to memory, to load it properly, the proper loading procedure is executed. The relocation table is read to adjust the module to the base address of the allocated memory region, the import table is read, the necessary libraries are loaded, and the import address table is filled with the correct addresses of the imports. Next, the entire PE header is overwritten with 0’s, a mechanism to destroy the PE header tricking security software into not realizing this module is malicious, and after the malicious code begins execution.

The main module does the following:

1. Tries an anti-debug technique using time and IcmpSendEcho to wait

2. Collect data about the computer (Operating system, computer name, DNS domain, running processes, etc)

3. Allocates memory for payload to retrieve from C&C server

4. Contacts C&C server at IP address 216.126.225.148

a. If this IP address is unreachable, uses a domain generation algorithm and uses a different domain depending on the month and year

5. Executes code sent by C&C

By the time of the analysis, we were unable to get our hands on the code sent by the C&Cs.

If you would like to analyze the malware yourself, you may refer to my tweet.

No author image
Jay Rosenberg

In this article

Share this article
Recommended Blogs
5MIN READ

AI SOC for teams outgrowing MDR

For teams that have outgrown their MDR, the answer isn’t a better MDR. It’s a different operating model.
3MIN READ

Intezer’s 2025 momentum reflects rapid adoption of AI SOC in global enterprise 

Enterprises are adopting AI SOC as the new model for running security operations. This shift is reflected clearly in Intezer’s momentum over the past year.
8MIN READ

Alert fatigue is costing you: Why your SOC misses 1% of real threats

Our 2026 AI SOC Report, based on the analysis of more than 25M security alerts across live enterprise environments, reveals a critical disconnect between how security teams prioritize alerts and where real threats actually originate.