CyberWire Daily - Phishing for leeches. [Research Saturday]

Episode Date: July 29, 2023

Ashlee Benge from ReversingLabs discussing their research titled "Operation Brainleeches: Malicious npm packages fuel supply chain and phishing attacks." Researchers recently discovered over a dozen malicious packages published to the npm open source repository. These packages are targeting Microsoft 365 users and appear to target application end users while also supporting email phishing campaigns. Research supports that the malicious campaign encompassed more than a dozen files designed to steal sensitive user credentials. The research states "This most recent campaign caught our attention because of a number of features and characteristics in related npm packages that correlate with malicious intent." The research can be found here: Operation Brainleeches: Malicious npm packages fuel supply chain and phishing attacks Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWires Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the

hard problems and protecting ourselves in our rapidly evolving cyberspace. Thanks for joining us. We have two primary research teams at Reversing Labs. One of them focuses on destructive malware, and the other focuses on open source and the attacks we see leveraging open source as a vector. And in looking at packages that had behaviors indicative of malicious behavior, we noticed these primarily because they had some obfuscation within the open source NPM packages. That's Ashley Benj, Director of Threat Intelligence Advocacy at Reversing Labs.

The research we're discussing today is titled Operation Brain Leaches, Malicious NPM Packages Fuel Supply Chain and phishing attacks. Anytime we see obfuscation of any kind, it's usually a good tell that something's not what it seems. And for folks who may not be familiar, NPM is a popular open source repository? It is, yep. Well, let's go through this together here. I mean, you see some red flags and you and your colleagues start digging into this. What was the process here? Yeah, so we look through this open source library and we find that actually it's not just the one malicious package, but it's actually quite a few, found 13 in total. And we've actually grouped them into two sort of main groups with similar but different intentions.

You know, it's common when we analyze these things, in this case, this was JavaScript. If there's obfuscation, we work to deobfuscate that. this was JavaScript. If there's obfuscation, we work to deobfuscate that. And then as we work through the code, try to pivot through all of our possible angles to see what is this package, what is it trying to do? Is it doing what it says it's doing? And in this case, spoofing the name of a very popular open source package. And so again, like the obfuscation within the package, that's another good indication that this is probably malicious. In so again, like the obfuscation within the package, that's another good indication that this is probably malicious. In this case, what we actually found is that within this package, I was actually, that NPM was being used to host phishing infrastructure, which is quite novel,

something that we haven't seen before, despite doing quite a lot of work in this space. Well, let's dig into each of these. As you said, there are two sort of clusters that you all categorized here. The first one was for phishing campaigns? It was. Yeah, in the first group, what we saw was that the packages were being used to host files that were leveraged in phishing campaigns. And actually, the phishing kit that was used in this case was probably just purchased and used without any sort of modification.

And so the flow of an attack that would use this phishing kit would, first, there would be a lure. Someone would receive an email, would have a malicious attachment. Then instead of going out and calling to attacker-owned infrastructure or a domain that looks potentially suspicious, what would actually happen is that malicious email attachment would contain a reference to the NPM package, and it actually would reach out to a JavaScript file that was hosted within that package on NPM. And so we see first one malicious file fetched, and then a second malicious file is fetched.

And finally, the phishing landing page is actually displayed to the user. In that case, the attack is pretty similar. It's phishing for Microsoft 365 credentials. It's pretty common for phishing kits. But the infrastructure being hosted on NPM was quite interesting because we haven't seen that before. And what about the second cluster here? They were targeting a different group?

They were. It was interesting. The second group could also potentially be leveraged against the end users of an application that used those open source packages. And so they contained the same phishing functionality, but actually it was such that if the second group of packages were to be used in an application, probably by a developer who didn't realize

that they were using something malicious rather than the actual benign and very commonly used package, then that benign code that the developer is writing, as it was compiled and sent to the end user, that compiled code could actually exhibit the same malicious behavior as the phishing campaign that we saw that started with that malicious email attachment. And so that's quite interesting because the threat actor in that case has made the developer sort of the unwilling participant in their campaign. And what was this second cluster of functionality targeting specifically here?

Yeah, we don't know quite for sure if they had any specific target in mind. But it's interesting to us that there's the optionality. there's the optionality. You know, you have the ability to stage a sort of a common and regular phishing attack where the infrastructure could be hosted on NPM and the attack path that I mentioned earlier with the first group could still be used. Or, you know, if that doesn't work,

there's also the option that maybe a developer who isn't paying the most attention or happens to make a really unfortunate mistake actually uses that in some code paying the most attention or happens to make a really unfortunate mistake, actually uses that in some code that's being sent out to either their customers or their organization, wherever it's being used. And so we don't have any victim information,

unfortunately, in this case, to know if that were a scenario that happened or if it was just a possibility. But it's interesting that there was the two optionalities as sort of a backup plan. 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 automation. And detecting threats using AI to analyze over 500 billion daily transactions.

Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. So, Ashley, help me understand here, just so I'm clear. I mean, is the notion that a developer is working on whatever project they're working on and they know that there's a certain open source project they want to make use of. So they go and they search for that on this repository. They find what they think is that open source thing that they're looking for. They download this malicious code and then they put that in

their project. Would their project function the way that they had hoped it would? Does the code do the thing it's supposed to do, but then have this extra stuff off to the side? Yes, that's correct. So oftentimes it can vary depending on the sophistication of the actor behind it. But oftentimes these malicious repositories that are mimicking the benign repositories or packages rather, they actually just copy the existing functionality of the one that's being spoofed. And so, yes, it will do what you think it's going to do. But there's the unfortunate addition of malicious behavior that's probably not what you expected. And then what triggers the malicious behavior? Is it a command and control or is it random? How do they go about that part of it? So in the case of the malicious email attachment,

it would function, you know, just as a regular attack would in an efficient case of phishing. And, you know, you would have to open this attachment. The functionality actually within the first file would go out and fetch another malicious file, which would then go fetch another malicious file. And ultimately that file displays the landing page. And the landing pages in this case were a bit interesting. You had two options.

One is just sort of a basic login. The other is actually a blurred document that would hopefully entice someone, the victim, to put in credentials to view the unblurred document. So that's sort of a commonplace phishing. That's not something that's particularly novel or new. But in the second case, what we actually see is that within the group of packages, the malicious content is actually contained within an eval statement. And that eval is obfuscated so that the behavior is not super obvious. But if that malicious package were to be used in a supposedly benign application, then you would have this malicious eval sort of coming

along for the ride. And so as you compile this code to get to your final product, you have what you're trying to do. But also, unfortunately, you have what the attacker is trying to do as well, which is to actually go in and display a phishing landing page to the end user. a phishing landing page to the end user. Now, you all are using the name Operation Brain Leaches here. Is this a new group, or is this related to things that you have found in the past? So in this case, the Brain Leaches name comes from the name of a domain where the threat actor was actually sending the spoof credentials. But we have seen some similarities. In the case of the similar historic research that we did,

we actually saw that a supply chain attack ultimately pivoted over to a similar kind of phishing activity. And that was a campaign we called Iconverse. But ultimately, that was sort of a phishing campaign for a different set of credentials, actually for a massive online multiplayer game called PUBG. of these phishing attacks with what's likely a supply chain attack. But we haven't seen any kind of open source package manager repository used for actually hosting infrastructure. And so this is probably not the same group, but it is interesting that we've seen this sort of evolution of leveraging these open source attack vectors. Yeah.

Do you have any sense for how successful this campaign has been? So we know that these packages were downloaded about a thousand times. That doesn't unfortunately give us much indication of success. We unfortunately don't have any indication of if they were able to successfully harvest credentials, but they were downloaded. And so at that volume, I would expect that it's probably not just testing activity. There was probably at least some attempt to display that landing page

and likely get credentials out of it. Yeah. What are your recommendations then? I mean, it seems like there are two groups in play here. There's the phishing side of it, but then the developers as well. Any words of wisdom here for folks to protect themselves? Yeah, it's tough. This is a tough area to detect.

On the phishing side, it's tough to sort of do the usual detection strategies where you might block suspicious domains because this is not actually a suspicious domain, right? It's calling out to NPM and that's not really something you can block because probably your organization is using it in some benign way. So on the end user space, it's probably going to be the actual contents of that lore file within the email. And so there wasn't anything particularly novel in the lore or anything of that nature. And so the common phishing detection strategies still apply. But in the case of the supply chain threat, that is actually a little bit more difficult, I think, because to really see the malicious behavior,

the usual AppSec detection strategies are not things that are necessarily going to help you in this case. To be able to detect something like this, what you're really going to need is a tool that can inspect the actual contents of the compiled final package and understand that behavior. So before you as a developer ship that out to your end user, you're going to want to take a look at that final build and make sure that it's only

displaying the behavior that you want to display and not anything else. And in this case, that your application isn't actually displaying a phishing landing page. And so if that's not something your current security stack does, it's probably something thatishing landing page. And so if that's not something your current security stack does, it's probably something that you should address. And there are solutions out there that can help you analyze that final package's behavior. You point out in the research that obfuscated code is a big red flag here. I'm curious, you know, you're a typical developer who's out here making use of these open source packages. Do they typically use them kind of plug and play, you know, like Lego bricks in their project? Or do they go in and look at the code with any sort of scrutiny

to look for things like obfuscation? Yeah, I can't speak for the entire development community, but I have to say for my own self, I'm very guilty of just plugging and playing and not really stopping to consider whether or not I've made a mistake and maybe I've made a typo that I don't catch or maybe there's been something added to a package that I'm just not aware of.

And so I think a lot of that comes from the pressure on developers to move quickly and to release code quickly. And in a world where we're increasingly reliant on software in our everyday lives, it becomes very tough to have your development team, who probably already has limited time and resources, really take a look at every single open source package that they're using. So that's, again, where the detection strategies sort of come, where it's very valuable to automate this however you can and take a look at your final build before you actually release it so your core developer doesn't have to go through and read all of the open source code that he or she is including in their final package.

Our thanks to Ashley Bench from Reversing Labs for joining us. The research is titled Operation Brain Leaches, Malicious NPM Packages Fuel Supply Chain and Fishing Attacks. We'll have a link in the show notes. And now a message from Black Cloak. Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected

lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365, with Black Cloak. Learn more at blackcloak.io. Thank you. produced by Liz Ervin and senior producer Jennifer Iben. Our mixer is Elliot Peltzman. Our executive editor is Peter Kilby. And I'm Dave Bittner. Thanks for listening.