CyberWire Daily - A Google Chrome update that just didn't feel right. [Research Saturday]

Episode Date: September 11, 2021

Guest Jon Hencinski from Expel joins Dave Bittner to discuss his team's recent work on "Expel SOC Stops Ransomware Attack Aimed at WordPress CMS via Drive-By Download Disguised as Google Chrome Update." In July, 2021, Expel's SOC stopped a ransomware attack at a large software and staffing company. The attackers compromised the company’s WordPress CMS and used the SocGholish framework to trigger a drive-by download of a Remote Access Tool (RAT) disguised as a Google Chrome update. In total, four hosts downloaded a malicious Zipped JScript file that was configured to deploy a RAT, but we were able to stop the attack before ransomware deployment and help the organization remediate its WordPress CMS. Jons walk us through what happened, how they caught it, and provide recommendations on how to secure your WordPress CMS.  The research can be found here: Expel SOC Stops Ransomware Attack Aimed at WordPress CMS via Drive-By Download Disguised as Google Chrome Update Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. Hello everyone and welcome to the CyberWire's Research Saturday. I'm Dave Bittner and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. It was about three o'clock in the morning,

and our SOC analyst picked up an endpoint detection and response alert for a suspicious zipped JScript file that's basically Microsoft's implementation of JavaScript. That's John Hensinsky. He's director of global operations at Expel. The research we're discussing today is titled Expel SOC Stops Ransomware Attack Aimed at WordPress CMS via Drive-By Download Disguised as Google Chrome Update. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs. Yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops

attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered Thank you. Learn more at zscaler.com slash security. When we were looking at the alert, it was using a name that was attempting to masquerade itself as a Google Chrome update. And when we were looking at the alert, something just didn't feel right, you know, because the thought that we had is, hey, you know, Google Chrome updates don't typically come down in this fashion. Why is an employee attempting to kind of manually install these if they are legitimate updates? And then what we noticed was like the endpoint detection response tool was actually blocking execution of that malicious JScript file. So we thought to ourselves,

was actually blocking execution of that malicious JScript file. So we thought to ourselves, hey, we better investigate how this ended up on the hosting question. And so to make a long story short, we did some additional digging. We looked at the employee's Google Chrome history. And what we found was that that malicious zipped JScript file actually came down from the company's WordPress CMS site. So that led to some additional investigation. And the rest of the investigation unravel WordPress CMS site. So that led to some additional investigation and the rest of the investigation unraveled from there. Well, let's walk through that together. I mean, as you say, you know, you get this odd file, which piques your curiosity. What happens next? Yeah. So when we get a file like that, it's about asking a series of questions. The first one is

like, well, how did it get there? And okay, it came from the company's WordPress site. So okay, why would the company's WordPress site be serving a malicious JScript file potentially? Then the next question that we're going to ask ourselves is, okay, what does the file do? So what that consists of is we'll actually acquire a copy of the file and we'll detonate it in an internal sandbox just to kind of see what happens after running that. And then our analysis, analysis what we found it was the first component of a variant of the wasted locker family of ransomware basically this would be the first step in a particular system or organization eventually being ransomed and the variant in question was was of the wasted locker family of malware. So it's basically

step one in attempting to ransom an organization by compromising the organization's WordPress CMS site. Well, take us through the infiltration on the WordPress site itself. I mean, how do you suppose this got there? And that first hosting question, what we did is we pulled the user's Google Chrome history and we found that one particular WordPress page was serving the malicious payload. And so when that happens, what we're going to do is we're going to look at the source code of the page that's serving the malicious file. And when we kind of look at the source code, what we found was like an evil malicious inline script that was somehow injected into the page.

Well, things got a little bit more exciting from there because remember, when the investigation started, it's three o'clock in the morning Eastern time, and we've got one host. That's the scope of this. So what happened is more users started to wake up, excuse me, more employees woke up and started to start their day. More and more systems were starting. We're starting to get more and more alerts of this activity from different hosts in question. And we repeat, yeah, we repeated our investigative process. And what really started to frighten us was we're seeing multiple pages on the company's

WordPress site with the same inline injection. Now, luckily, the EDR technology was blocking execution of the malicious file. But keep in mind, this is a WordPress site that's accessible to anyone. So not only can the employees of the organization access that, but anyone with an internet connection could potentially be victimized from a result of visiting this particular, any of those web pages. So there is a level of urgency there. And it wasn't just one page, it was multiple pages. So we're thinking, okay, we've got to move really, really quickly here. So our investigation pretty much looks works like this. Let's, let's look at the source code of all the compromise pages. And then the first step, it's pretty basics from there. It's like, okay, what version of WordPress is the organization

running? And what we've got some third party tools that can just get us, you know, the version of the WordPress version that's running. And we found that it was running a legacy version. So at that point, we said to ourselves, okay, listen, there's some type of vulnerability that's being exploited here. And we kind of look at the totality of what's happening. We stumbled across some open-source research that attributed this to potentially being a SOC goal-less framework. And basically, that's a framework used by attackers to spot vulnerable WordPress sites and inject pages with a malicious script that ultimately will serve something like a zip.js script file posing as a fake update with the intent of gaining access to systems to eventually

conduct a ransomware attack. to systems to eventually conduct a ransomware attack. So for the user themselves, I mean, you're someone who's browsing around on this company's website, on their WordPress site, as you say. Is this a situation where something pops up and says, hey, time to update Chrome? Yeah, and that's what makes this a little bit more scary. Because imagine your employee visiting the WordPress site for the organization you work for. You're using Google Chrome, and then after visiting the WordPress site, you get a pop-up that says, hey, it's time to update Google Chrome. You're most likely going to say, yeah, I'm going to download that, and I own organization's WordPress sites, and being thrown fake Google updates, which could potentially lead to the first component of a ransomware attack.

And what can you tell us about the specific vulnerability here in this version of WordPress? Any notion of how this code was being injected? Yeah, so we weren't able to confirm which specific vulnerability was being exploited. That's kind of one of the challenges when you're working with a SOC as a service. You have to move fast. When we were working with this particular customer, it was more critical for us to help them get a handle on it versus, okay, can I get web access logs to determine which specific

vulnerability? The guidance that we gave the specific customers was to say, listen, we know that something's being exploited here. We believe it's a WordPress application. We believe that based upon preliminary evidence, we can't determine which specific vulnerability is exploited, but let's go ahead and just update to the most recent version and get this off of the site because I think that's the most critical thing. So in this particular case, speed was more important than identifying which specific vulnerability is exploited because we wanted to move fast and fix this issue for the customer. Can you explain to us what did the customer have in place that was blocking the execution of this rogue file?

That's a really good question. In this particular case, the customer is running endpoint detection and response and agent. And basically that agent was just looking for malicious processes. So in this case, the EDR agent had a signature or detection that says, okay, if you see this type of zip J script file attempt to be executed on the box, go ahead and block the process. So which is really good because when the employee attempted to run that J script file, EDR was blocking it. But if we had just stopped our investigation there, we would have missed a really big piece in our investigation that, oh, by the way, the company's WordPress site is actually the system serving this and there's a much bigger problem.

Yeah. What's your recommendation for folks who are out there running WordPress? And there's a lot of folks out there who run WordPress for a lot of good reasons. But I think this example really shows that sometimes organizations have all the best intentions, but for one reason or another, you don't keep things up to date. Yeah, absolutely. So before I jump into WordPress, I'll provide your listeners some context. We do respond to a lot of incidents where a public facing web application or server is exploited, but oftentimes it's using an older vulnerability,

meaning that vulnerability is one, two, maybe even three years old at times. Now that's not to say we're not responding to incidents where it's a zero day or one day, but more often than not, we're responding to internet facing systems where an older vulnerability was exploited to get remote code execution on the box. But to talk about WordPress specifically, you know, WordPress security and its ecosystem has improved over the years, but like it's still an attack vector. Obviously, keeping up to date on patches is key. But a couple other things that folks can consider is run trusted and well-known WordPress plugins. What I mean by that is like, don't just look at the plugin, look at the vendor that's developing the plugin. Consider executing a third-party assessment against the vendor

that's actually producing the WordPress plugin that you want to run. And there's also really good WordPress hardening guides or even WordPress security plugins that might be right for particular organizations as well. I think the other things to consider is, you know, MFA everything and all users. Like if you have folks that are authenticating into the WordPress admin panel, make sure you're using multi-factor authentication. And then finally, this is a really good recommendation. Consider running an IR tabletop exercise where the initial entry point is your WordPress site. Why I think that's so key is like more often than not, your WordPress site

is going to be managed by a third party. So really even asking the question, hey, our WordPress site was just compromised. Who do we contact? How quickly do they have to get back to us? If we needed to shut down the application or shut down and kind of retain a copy of the data, how does that even work? And I think, you know, a really effective security program would ask that what-if question. And by asking that what-if question, you develop the muscle memory to say, I know exactly who we have to call, and I know exactly how quickly they're going to get back to us. So by asking that question through an IR tabletop exercise, you'll be more prepared in the event that you do experience an incident from a WordPress site attack.

in the event that you do experience an incident from a WordPress site attack. You know, it strikes me that because of this organization's foresight to have a system in place to be able to scan files as they were coming to their users' endpoints, they were able to mitigate this. And so that in itself is a happy ending. I imagine for some of the folks who might have visited their site, they might not have been that lucky. And I suppose the organization, it seems to me, correct me if I'm wrong, they were unaware that they were serving up this potentially malicious information from their own site. sort of thing where some sort of behavioral monitoring could have helped along the way that

they could have been saying, wait a minute, we sure are serving up a lot of executables here from our WordPress site. What's that about? Do you follow my line of thinking? No, I do. So I'll kind of answer that with two key points. We knew EDR for the organization was blocking the zip trace file now. We needed to move really quickly because what if they changed the payload that was being served or changed the file that was being served to employees and suddenly EDR was no longer blocking it? But you're absolutely right.

The other component of that is like, we wanted to move really, really quickly because you're right, there are potential folks visiting that site that we don't have visibility into that were being served that file. And what we were really, the reason we wanted to move so quickly is we were focused on minimizing any potential

collateral damage from folks not associated with the organization visiting that site. Now, your question regarding monitoring of those, the particular WordPress pages, now that's a really interesting concept. In this particular situation, we didn't have direct visibility into the WordPress site because in this situation, it was managed by a third party. So if you do have direct access to your WordPress site, monitoring for changes for those pages might be one more to explore. But I guess the best guidance I give it is follow the recommendations that we've outlined

in terms of staying up to date, running trusted plugins, following a hardening guide, MFA everything in all users, and then run that IR tabletop exercise. And that's probably going to be your best way to prevent, you know, an attack on your WordPress site. I mean, in the aftermath of this event itself, which, you know, for the organization sounds like they, you know, they were able to escape with minimal impact here. Were there any changes made to their own policies? Was it a bit of a wake-up call for them? Yeah, so obviously we're running the most up-to-date version of WordPress today, and we've confirmed that, and they'll update their patching procedure relative to their WordPress applications.

update their patching procedure relative to their WordPress applications. And then this organization is also going to explore implementing or updating their content security policies, which basically says what JavaScript can run on my particular web applications. So that's one of the things I love about working as a SOC as a service is we use these incidents to help organizations improve their security strategy and their security posture. So this is a good wake-up call and say, hey, we've got to keep our WordPress sites up to date. We're going to explore our content security policies and kind of consider some other strategic changes. And I really hope, you know, they didn't have to run an IR tabletop because we got to run that with them.

But, you know, consider running additional IR tabletops for some other scenarios is also up for consideration as well. Our thanks to John Hensinsky from Expel for joining us. The research is titled Expel SOC Stops Ransomware Attack, aimed at WordPress CMS via drive-by download disguised as Google Chrome Update. We'll have a link in the show notes. Cyber threats are evolving every second, and staying ahead is more than just a challenge. It's a necessity.

That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely. Visit ThreatLocker.com today to see how a default-deny approach can keep of cybersecurity teams and technologies. Our amazing CyberWire team is Thanks for listening. We'll see you back here next week.