Case Study: CCleaner

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

Video Transcription
Hi, I'm Matthew Clark and this is less than 2.9 case study for C Cleaner.
In this lesson, we'll take a look at the supply chain failure for C Cleaner.
So let's get started.
See, cleaners History. They started off as a registry cleaner. Removing old windows programs, injuries, uh, their parent company or the company that formed them was pure form lt d and they were started with two gentleman by the name of Guy Saner and Linsley Wieland. Hopefully I said those names correctly,
but the company was founded in 2014
and it was formerly named The *** Cleaner on DSO. I think they dropped the word *** and put it see cleaner
and basically cleans today cleans Windows, Macs and mobile laps and was acquired by Vast in 2017.
So let's take a look at the timeline for this supply chain attack.
There are several good articles on this, and I've included a link to the hacker news article and the references section
Be Phil, please feel free toe. Take a look at that.
Let's start with March 11th and this is 2017
threat actors. They excess access toe see cleaner developer workstation using team viewer, and this happened about 5 a.m. in the morning local time.
The threat actors may have had credentials harvest from a previous data breach, but it those details were still a little murky.
They did manage to install malware using a VB script, but it took him three times to be able to do that.
On March 12th. The next day, the threat actors moved laterally to another computer again, this curd outside of the normal office hours and presumably to reduce the threat of detection. It happened about 4 a.m. Local time.
The threat Actors opened a backdoor using rdp and dropped an older version of second stage malware, which ended up making its way toe. 40 different see cleaner users and among those victim organizations the second, the second stage
or D link. Google HTC, Lynxes, Microsoft, Samsung, Sony VM Ware,
Francisco. So some lease, um, larger companies
in March 14th, two days later, the threat actors reinfect or infected the first machine?
Um, I guess they maybe they thought, Why not? I don't know, but they did infected with the older version of the second stage Malware.
Then, in april 4th of 2017. The Threat actors compiled a custom version of malware called Shadow Pad, and this has its roots and trace back to the Chinese. A P T. 17 on Basically what this did was provided backdoor.
Then, on April 12th, the Threat actors installed a third stage payload on four computers and build sir.
Then, between April and July of 2017, really the threat actors had full run of the sea cleaner network they. During that time they created a malicious version of the C Cleaner program, and they installed key loggers and other things,
um, on the sea cleaner network.
Then, on July 18th, C cleaner was acquired by a vast
August 2nd. The threat Actors replaced the sea cleaner on the website with their version containing malware. So the original version was taken down in this malware version was was put up.
This attack affected 2.3 million users who downloaded the software updated the app. During that process,
Um, of those 2.3 million users, 1.65 million copies of the C cleaner malware phoned home to the Attackers
on September 13th, 2017. The breach was detected. The malware was removed. So the threat actors had access toe distribute this software from August the second to September the 13th, before they were caught.
So, really, what are the lessons that we can learn from this? Well, there's several. The first one is mergers and acquisitions.
You know, most mergers and acquisitions are mostly concerned with the financials. But when you acquire a company and they have a product say in the I o. T space, then you really need to perform a security analysis of that product to understand what the vulnerabilities are
and how it fits in with your existing security program.
In the I. O. T. Space, you need to be certain that you perform a review of all legacy products, you know, and integrate them. And I'm using that term legacy kind of with air quotes. Because as soon as you acquire a company all the products and materials that they've done in the past,
you tend to start thinking of them as legacy because all the new things or new updates that they're gonna make
are gonna be, you know, so much better since you have acquired them and so forth, and so that tends to be a differentiator between products, um, that are made at one point versus another point
update servers or something else to think about. These absolutely need to be protected. Update servers, especially the ones they're responsible for communicating to clients downstream, you know, are critical attack points. And this particular case study really shows that
how those updates servers could be used to perform spotting attacks with customers.
So this type of particular attack can absolutely ruin your company's reputation, not to mention it can harm people or other companies, depending on what the update services. Providing
a key take away should be to isolate your update servers from the business network, which absolutely wasn't the case here.
Code reviews is something else to think about. This is ah, you know, one of those security controls that we put in place on DWI. Think about as it relates to when we're building code and and change management and code releases and so forth. But there's another area to think about it. If
threat actors or inside your systems, and
even if they're not using your systems to develop code, they develop code elsewhere and imported in. Eventually they're going when they commit that code that should set off, Cem triggers. That should set off some automated reviews. Or somebody should be able to see periodically that this code doesn't match that code or there's been a revision
Onda. Another thing also think about is Lightning does strike once. It also strikes twice and even thrice and Mawr See Cleaner was hit with another successful attack in 2019. And this one was slightly different in nature, where the threat actors breached the internal network using temporary VPN account. Um,
but so another
lesson from this this company's absolutely need to stay vigilant. Um, And when you've been hacked one time, that's no guarantee that you're not gonna be hacked again. And even when you close all the doors and all the problems from one breach, that doesn't mean that you don't need. You can sit back and not worry about being breached differently because you absolutely have thio
stay on top of things.
So let's make sure that we point out the positives here because I don't want anyone to have a sour taste in their mouth just because we go through a case study
case studies air. There s so that we can learn from them. So we take a look at the negatives that happen and then try to point out our look for the lessons and the positives and the negatives and things that we can do and take back their own companies to improve the security. Also remember that every company has been hacked.
The only difference
are the companies that are willing to admit it, Onda willing to be transparent about it.
On dso that transparency is absolutely critical because when companies air transparent, then it enables others toe learn from their mistakes.
And many companies air absolutely silent when it comes to an attack, you know, and maybe they're that they're that way for the legal reasons.
But this particular one, you can read all about it on the S blogged. They even provide screenshots.
So all those dates and times and everything that I gave you, you know, they come from the stories and they come from the information that the company released. So
they're very transparent about this and so kudos for them. That's that's really helpful for companies that want to learn, plus on their website. When you click on security. They immediately take you to their responsible disclosure policy.
And we're gonna cover responsible disclosure policies in another lesson.
Um, but this shows you that they've taken their lessons that they've learned to heart, and they're willing to, um, Thio invest in their company and find a way to be able to take those types of vulnerabilities that may be disclosed to them, too.
Be able to better their improve their response times and better their company. So that's really good.
Um, so it's like double kudos.
So what did we learn in this video? Well, we covered a case study for C Cleaner. We took a look at what happened and discussed lessons learnt, and we were able to see the importance of supply chain security. And what happens when thread actors insert themselves into your supply chain?
Up Next
First Steps: Framework
Architecture Stages Part 1
IoT Architecture Stages Part 2
IoT Ecosystems
IoT Communications Part 1