Phishing for leeches.

Dave Bittner: 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 the threats and vulnerabilities, solving some the hard problems and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

Ashlee Benge: We have two primary research teams at ReversingLabs. 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.

Dave Bittner: That's Ashlee Benge, Director of Threat Intelligence Advocacy at ReversingLabs. The research we're discussing today is titled "Operation Brainleeches: Malcious npm packages fuel supply chain and phishing attacks."

Ashlee Benge: Anytime we see obfuscation or any crime it's usually a good tell that something's not what it seems.

Dave Bittner: And for folks who may not be familiar, npm is a popular open source repository?

Ashlee Benge: It is, yep.

Dave Bittner: Well, let's go through this together here. I mean, you--you see some red flags and you and your colleagues start digging into this, what was the process here?

Ashlee Benge: Yeah, so we looked 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 was obfuscation we worked to obfuscate that and then as we worked through the code tried to pivot through all of the possible angles to see, you know, what is this? 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 it was probably malicious. In this case, what we actually found is that within this package I was actually--the npm was being used to host phishing infrastructure which is quite novel, something that we haven't seen before just by doing quite a lot of work in the space.

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

Ashlee Benge: It was. Yeah, this 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--it contained 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 fetch and then the second malicious file is fetch and finally, the phishing landing page is actually displayed to the user, in that case, the attack is pretty similar, you know, it's phishing for a Microsoft 365 credentials, it's pretty--pretty common for phishing kits, but the infrastructure being hosted on npm was quite interesting, because we haven't seen that before.

Dave Bittner: And in what amount the second cluster here, they were targeting a different group?

Ashlee Benge: They were. It was interesting. The second group would 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 was 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.

Dave Bittner: And what was this second cluster of functionality targeting specifically here?

Ashlee Benge: Yeah, that we don't know quite for sure if they had any specific target in mind. But it's interesting to us that there was 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 with 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 may be a developer who isn't paying the most attention or happens to make a really unfortunate mistake, actually uses that in some--some code that's being sent out to other 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 just a possibility, but it's interesting that there was the two optionalities as sort of a backup plan.

Dave Bittner: So, Ashlee 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 that 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--does the code do the thing it's supposed to do, but then have this extra stuff off to the side?

Ashlee Benge: Yes, that's correct. So, often times it can vary depending on the sophistication of the actor behind it, but often times 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.

Dave Bittner: And then what triggers the malicious behavior? Is it the command and control or is it random? How do they go about that part of it?

Ashlee Benge: So, in the case of the malicious email attachment, it would function, you know, just as a regular attack would, in this case of phishing, and you know, you would also have to open this attachment--the functionality actually within the first file would go out and fetch another malicious file which may 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 email statement and that email 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 email 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.

Dave Bittner: Now, you all are using the name "Operation Brainleeches" here, is this a new group or is this related to things that you have found in the past?

Ashlee Benge: So, in this case, the "Brainleeches" 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 "Icon Burst," but ultimately that was sort of a phishing group of a phishing campaign for a different set of credentials, actually for a massive online multiplayer game called "PUBG." And so, you know, there are some similarities and it's not the first time we've ever seen the grouping of these phishing attacks with what's likely a supply chain attack. But we--we haven't seen any kind of open source package manager or repository used for actually hosting infrastructure, and so, this is a probably not the same group, but it is interesting that we've seen this sort of evolution of leveraging these open source attack vectors.

Dave Bittner: Yeah. Do you have any sense for how successful this campaign has been?

Ashlee Benge: 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.

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

Ashlee Benge: 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 then 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 WAR [assumed spelling] file within the email. And so, you know, there wasn't anything particularly novel in the WAR 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 [inaudible] 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 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 that you should--should address and there are solutions out there that can help you analyze that final package's behavior.

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

Ashlee Benge: Yeah. I can't speak for the entire development community, but I have.

Dave Bittner: Right.

Ashlee Benge: 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 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, you know, it becomes very tough to have your--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 strategy sort of come where it's very valuable to automate this however you can and take.

Dave Bittner: Right.

Ashlee Benge: A look at your final build before you actually release it so your poor developer doesn't have to go through and read all of the open source code that he's include--he or she is including it in their final package.

Dave Bittner: Our thanks to Ashlee Benge from ReversingLabs for joining us. The research is titled "Operation Brainleeches: Malicious npm packages fuel supply chain and phishing attacks." We'll have a link in the show notes.

Dave Bittner: The CyberWire "Research Saturday" podcast is a production of N2K Networks. Proudly produced in Maryland out of the startup studios of DataTribe where they're co-building the next generation of cybersecurity teams and technologies. This episode was produced by Liz Irvin and Senior Producer Jennifer Eiben. Our mixer is Elliott Peltzman. Our executor editor is Peter Kilpe and I'm Dave Bittner. Thanks for listening.