CCleaner breach used to deliver backdoor trojan to selected targets

Share

Anyone downloading the Avast owned system optimisation tool, CCleaner, between 15th August and 12th September likely got more than they were bargaining for. A supply chain breach meant that two hacked versions of the application, infected with malware including a backdoor trojan, were served up instead of the genuine article.

Although some 2.27m computers are said to have been impacted by the hacked software, which collected data about the infected host and sent it to a Command and Control server, this appears to have just been the first stage of the attack and not the final goal.

Indeed, at the time of writing it is thought that the real payload, a second stage backdoor trojan, was only sent to those computers that met a strict filtering criteria. As far as we know at this point, only around 20 instances of the backdoor payload were distributed and to a highly select group of large companies in the tech sector. It was, in fact, the perfect definition of advanced attack reconnaissance.

the true number of second-stage backdoor payload infections is likely higher

When the C&C server was seized and inspected, having been operational for 31 days but only containing data from the last four days of operation as a storage space issue meant most of the database was deleted, the list of names included Epson, Google, Intel, Microsoft, O2, Oracle, Samsung, Sony and Vodafone amongst others.

Most of the cybersec pros I have spoken to think the true number of second-stage backdoor payload infections is likely higher, much higher, than 20 though. It seems that Avast would now concur, saying in a revised statement that “given that the logs were only collected for little over three days, the actual number of computers that received the 2nd stage payload was likely at least in the order of hundreds.”

Of course, targeting these companies is not the same as infecting them. It may be some time, if ever, before we learn just how successful this attack scenario has been.

It’s hard to say at this point, at least with any meaningful conclusion, who was behind the attack. Some of the backdoor code is the same as that previously used by the Chinese APT 17/Group 72 outfit. This could just as easily be a false flag to throw investigators off the scent as it could be a finger above the head of the true culprits. Not that it really matters right now, what matters is that this was a pretty sophisticated attack employing a bunch of advanced techniques from the supply chain breach through to the discovery mechanism for the backdoor payload distribution.

What’s important, made more so since 28 days of attack data was deleted from the C&C server before it could be examined, is that any business running CCleaner should take the necessary steps to ensure they have not been infected. The advice from Avast is as follows: “For consumers, we stand by the recommendation to upgrade CCleaner to the latest version (now 5.35, after we have revoked the signing certificate used to sign the impacted version 5.33). For corporate users, the decision may be different and will likely depend on corporate IT policies. At this stage, we cannot state that the corporate machines could not be compromised, even though the attack was highly targeted.”

it appears that the build process of CCleaner itself was compromised

Here’s what others in the industry have been telling us.

Marco Cova, Senior Security Researcher at Lastline: “This is an example of a software supply-chain attack, where an otherwise trusted software vendor gets compromised and the update mechanism of the programs they distribute is leveraged to distribute malware (Petya/NotPetya was another recent case where this occurred). This is sort of a holy grail for malware authors because they can efficiently distribute their malware, hide it in a trusted channel, and reach a potentially large number of users. Also notable is that it appears that the build process of CCleaner itself was compromised: that is, attackers had access to the infrastructure used to build the software itself (in addition to its distribution channel). This is very troublesome because it indicates that attackers were able to control a critical piece of the infrastructure used by the vendor. I expect that a lot of software vendors will be reviewing the security of their build and distribution channels as a consequence of this finding.”

Ofer Maor, Director of Enterprise Solutions at Synopsys: “Attacks like this are likely the result of insufficient security and quality controls by the vendor, allowing attackers to maliciously inject code while the software is being created. These insufficient controls, however, are not the result of extreme negligence. They are, indeed, the standard for many vendors. These types of attacks just demonstrate the need for the software industry to mature itself the way other engineering disciplines have been in the past. We no longer accept lack of such controls in our cars or our bridges, and as the customers, we should no longer accepts such oversights with software.”

Javvad Malik, Security Advocate at AlienVault: “The attack mirrors the NotPetya ransomware technique of compromising a software provider that is trusted by consumers. A technique that is being used more often, even targeting security companies. It is therefore important that companies deploy effective threat detection and integrity controls to be able to identify where authorised access has been attempted or code has been changed.”

Colin Domoney, Consultant Solution Architect at Veracode: “While it is unclear how the malicious code was inserted into CCleaner, it is essential that software vendors are constantly scanning their applications to ensure that they are not leaving it open to exploitation by malicious actors. Veracode’s own analysis has found that security software is the second to worst category of software for application security, perhaps explained by the fact that it is typically written in the C/C++ which has more critical vulnerabilities, such as buffer overflows and integer overflows, than more modern type-safe languages like Java, C#, or Javascript. If security software vendors are going to ask their users to trust them with higher privilege levels, to enable their services to inspect the data going to and from other applications, it is crucial that we see application security becoming a greater priority to ensure the security of their offering.”

Share