Security Notification for CCleaner v5.33.6162 and CCleaner Cloud v1.07.3191 for 32-bit Windows users

I have latest version of CCleaner and don't have that particular key, but many others in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\

@blacknight What is the path when you click / expand that key?

 

Many other key I too.

 

I don't have key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{5DCE4767-2B66-466F-B3D1-6F1EBE9F939E} but do have SKIP UAC task (it is being used for silent privilege elevation).
You can disable it in CCleaner settings.

 

What you want to look for is any reference to this key in the registry: 5DCE4767-2B66-466F-B3D1-6F1EBE9F939E. The details within this key itself will tell you what it used for; most likely a registered .dll or service. The only scheduled tasks I have that use this format: {xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} are for pcalua.exe, Program Compatibility Assistant.

There is zip ref. to this key on my Win 10 1607 build. That doesn't mean it is not used by other Win OS vers.

 

Decades of learning from my mistakes. You should try it sometime instead of repeating them.

 

I’ve run Avira Pro, Malwarebytes, Adwcleaner, EmsifoftEmergencyKit, HitmanPro, ZemanaAntimalware on two Win 10 machines (64 bit) with CCleaner, they all found nothing. Then I finally run Eset Online scanner and it found “Win 32/Bundled.Toolbar.Google.D potentially unsafe…”

False positive? What do you think?

 

No. Eset has always classified CCleaner as a PUA, potential unsafe app, due to the bundled crap contained within the installer such as the Google Toolbar.

 

OK thanks, but it is not adware and it doesn't need to be removed...

 

Hi Osaban, ESET is flagging the installer, that's all.

Bo

 

True. In this case, I like CCleaner for how it handles cookies on my systems. How it handles cleaning of Google Chrome profiles, etc.

 

Thanks man +1

 

I know.

 

That's why I always monitor trusted apps. I wonder what type of security the affected companies were using, because if next-gen AV can't block this, it's pretty painful. Actually, behavior blockers should have been able to detect the suspicious behavior easily, unless they auto-trusted CCleaner which would be a blunder.

What the hell, I must have missed the ShadowPad attack. But it isn't anything new, years ago they also distributed a trojanized version of GOM Player, see second link.

https://securelist.com/shadowpad-in-corporate-networks/81432/
https://kc.mcafee.com/corporate/index?page=content&id=PD24966

 

There is an interesting comment to the Cisco blog posting in regards to the initial attack and backdoor analysis that I am posting below. For starters, this was a corp. installation and obviously not one of the high value corps. targeted by the second backdoor attack. Additionally, the corp. involved is an IT service provider. The poster was receiving alerts from Webroot in late June about backdoor activity originating from CCleaner by one of his client's endpoint devices. Upon examination, he found the malware on his server but CCleaner had never been installed on any of his servers.

This implies the following:

1. The attacker had access to Piriform servers much early that has been reported.
2. Suspect that the attacker was running limited "trial runs" of the malware to test it out and to determine the effectives of his backdoor code against existing detection by security products.
3. Since the malware was installed on the server, there very well might be an undiscovered worm component to this attack.

The "64 Thousand Dollar Question" is why didn't Webroot notify anyone about it?

 

I hate to be this guy but these are things I have been thinking about since before they were brought up. As an IT director and project manager at a software company... I wonder if Piriform was using source control software (I have brought this up before.) Most commercial software companies do. This wan't a simple 'some hacker' dropped a file(s) on a hacked server. Someone would have infiltrated their source code. And their source control. And if there were additional files, their install scripts as well. All in front of the digital signature being applied. And then would have had to have tested it as mentioned above. That would be an extreme level of access. Source control requires valid credentials. There would be a trail of check-ins that would be out of place. Either someone was incredibly smart and got past all of this... or this was an inside job. The level of skill it would take to pull this off as an outsider would be extreme. I regularly take builds of software made at the company I work for and test them with Process Explorer and TCPView to make sure they aren't doing anything funny. It's obviously not happening at Piriform. And if Avast had ANY idea that there was ANY kind of hack going on as they were buying this company they should have pulled all copies of the software until a full investigation had been completed. Maybe it is as simple as it is being presented. It's meant more as speculation than accusation, but too many things don't seem right to me.

 

Good points. But I would also love to know how security tools would protect against such an attack. For example, Cylance and Invincea should be able to detect trojanized versions with AI/ML. Other companies like Carbon Black, FireEye and CrowdStrike should have been able to block and/or detect suspicious behavior. It's clear that most AV's failed to detect it via signatures/heuristics, that's why behavioral monitoring is so important.

 

The only way a like attack could be detected from a trusted signed app binary as done in this attack would be firewall monitoring of all contentions made and only allowing those to known Piriform servers. Appears many corps. also got nailed by this attack which leads to the assumption they also were not doing like monitoring of CCleaner outbound connections.

As far as signature detection of the backdoor, it would only be possible if there were code patterns in the binary that matched existing known signatures. It is obvious the backdoor was coded from scratch. There is nothing difficult about coding a backdoor since it is nothing more than code to establish a remote connection.

As far as behavior detection, it is again fairly obvious all the backdoor code was contained within a signed trusted binary. A remote connection was established an any subsequent activity was done through remote execution activities. For starters, classic behavior blockers like Emsisoft need to be monitoring the CCleaner exec which they wouldn't have since it was a trusted signed process. As far as the Next Gen solutions, the only local activity they would have detected was an outbound connection from CCleaner which is perfectly normal since it performs such activities for registration validation, updating, and the like. A process such as CCleaner by its very nature does all kinds of system modification activities. As such their machine learning processing would not have detected that anything was amiss. Add to that they are as ineffective against remote code execution activities as the conventional security solutions are.

Finally if you had detailed HIPS rules in place against process modification and the like, all those would have detected is CCleaner.exe doing them which of course you would have allowed. In this regard if you had previously created like rules for CCleaner.exe, new HIPS alerts being generated would be a clue that possibly something was amiss with the recent CCleaner installation. However, this would be a user judgement call which I believe most would allow. And again, all the previous only applies to locally executed process activity.

 

Agomo... Agomo?

 

It is called CCleaner Cloud now; it was called Agomo when betas first went public.

 

Carbon Black has an article on the incident with a comment on the use of PUPS plus a few other like incidents that folks might not be aware of:

https://www.carbonblack.com/2017/09...tracks-ccleaner-ongoing-supply-chain-attacks/

 

@itman Thanks, great reading indeed.