A Google Chrome update that just didn't feel right.

Dave Bittner: Hello everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this 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.

Jon Hencinski: It was about three o'clock in the morning, and our SOC analysts picked up an endpoint detection and response alert for a suspicious Zipped JScript file – that's basically Microsoft's implementation of JavaScript.

Dave Bittner: That's Jon Hencinski. 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."

Jon Hencinski: 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 is, like, the endpoint detection and response tool is actually blocking execution of that malicious JScript file. So we thought to ourselves, hey, we better investigate how this ended up on the host in question.

Jon Hencinski: And so, to make a long story short, we did some additional digging, we looked at the employees 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 unraveled from there.

Dave Bittner: 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?

Jon Hencinski: 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 OK, it came from the company's WordPress site. So, OK, why would the company's WordPress site be serving a malicious JavaScript file, potentially? Then the next question that we're going to ask ourselves is, OK, 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.

Jon Hencinski: And in our analysis, what we found, it was the first component of a variant of the WastedLocker 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 of the WastedLocker family of malware. So, it's basically step one in attempting to ransom an organization by compromising the organization's WordPress CMS site.

Dave Bittner: Well, take us through the infiltration on the WordPress site itself. I mean, how do you suppose this got there?

Jon Hencinski: On that first host in 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. 

Dave Bittner: Hmm. 

Jon Hencinski: 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. 

Dave Bittner: Wow.

Jon Hencinski: 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 in-line injection. Now, luckily, the EDR technology was blocking execution of the malicious file, but keep in mind, this 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, you know, victimized from a result of visiting this particular – any of those web pages. So there was a level of urgency there. And it wasn't just one page, it was multiple pages.

Jon Hencinski: So we're thinking, OK, we've got to move really, really quickly here. So our investigation pretty much looks works like this. Let's look at the source code of all of the compromised pages, and then the first step, it's pretty basic from there. It's like, OK, what version of WordPress is the organization running? And we've got some third-party tools that can just get us 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, OK, listen, there's some type of vulnerability that's being exploited here, and we kind of look at the totality of what's happening.

Jon Hencinski: We stumbled across some open-source research that contributed this, to potentially being the SocGholish framework. And basically, that's a framework used by attackers to spot vulnerable WordPress sites, and injects pages with a malicious script that ultimately will serve something like a Zipped JScript file posing as a fake update with the intent of gaining access to systems to eventually conduct a ransomware attack.

Dave Bittner: So for the user themself, 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?

Jon Hencinski: 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 popup 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'm going to run that. And that's what's exactly happening. So the real – the scary part is, like, users running Google Chrome, visiting their own organization's WordPress sites, and being thrown fake Google updates, which could potentially lead to the first component of a ransomware attack.

Dave Bittner: 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?

Jon Hencinski: 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 the SOC-as-a-service – it's kind of, you have to move fast. When we were working with this particular customer, it became more – it was more critical for us to help them get a handle on it, versus, OK, can I get web access logs to determine which specific vulnerability? The guidance that we gave the specific customers was 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's 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's exploited because we wanted to move fast and fix this issue for the customer.

Dave Bittner: Can you explain to us, what did the customer have in place that was blocking the execution of this rogue file?

Jon Hencinski: That's a really good question. In this particular case, the customer is running an endpoint detection and response agent. And basically that agent was just looking for malicious processes. So in this case, the EDR agent had a signature or a detection that says, OK, if you see this type of Zipped JScript file attempt to be executed on the box, go ahead and block the process. Which is really good, because when the employee attempted to run that JScript file, EDR was blocking it. But if we had just stopped our investigation there, we would have missed a really, 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.

Dave Bittner: Mm-hmm. Yeah. What's your recommendation for folks who are out there running WordPress? And I mean, 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.

Jon Hencinski: Yeah, absolutely. So, before I jump into WordPress, I'll provide your listeners some context. Like, 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.

Jon Hencinski: 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 of 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 that might be right for particular organizations as well.

Jon Hencinski: 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 multifactor authentication. And then finally, this 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, we're 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 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.

Dave Bittner: 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, you know, coming to their users endpoints, they were able to mitigate this. And so, you know, 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, I mean, 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 is – is this the 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?

Jon Hencinski: No, I do. So, I'll kind of answer that with with two key points. We knew EDR for the organization was blocking the Zipped JScript file now. We needed to move really quickly, because what if they change the payload that was being served, or change 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're really – the reason we wanted to move so quickly is we were we were focused on minimizing any potential collateral damage from folks not associated with the organization visiting that site.

Jon Hencinski: Now, your question regarding monitoring of those – the particular WordPress pages. Now, that's 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, you know, monitoring for changes for those pages might be one more to explore. But it gets the best guidance I give it is follow the recommendations that we've outlined in terms of staying up-to-date, writing trusted plugins, following a hardening guide, MFA everything and 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

Dave Bittner: 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?

Jon Hencinski: Yeah. So, obviously they'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. And then this organization is also going to explore implementing or updating their content security policies, which basically says, you know, 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 was a good wake-up call in saying, 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 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.

Dave Bittner: Our thanks to Jon Hencinski 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. 

Dave Bittner: The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Tre Hester, Elliott Peltzman, Puru Prakash, Justin Sabie, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Gina Johnson, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Rick Howard, Peter Kilpe, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.