We chatted with ReversingLabs Reverse Engineer Karlo Zanki about how he discovered IconBurst.

EPISODE TRANSCRIPT

PAUL ROBERTS
So welcome back. This is another episode of ConversingLabs. This is ReversingLabs podcast that brings you face to face with the top minds in threat hunting, reverse engineering, threat intelligence, software assurance. And I'm your host, Paul Roberts. Really happy to be back with you again and happy to have back with me in the studio ReversingLabs' own Karlo Zanki. Karlo, welcome back.

KARLO ZANKI
Hi Paul, glad to be back.

PAUL ROBERTS
Karlo is a reverse engineer and researcher here at ReversingLabs. Karlo, could you just tell the audience a little bit about what you do here?

KARLO ZANKI
Well, as you said, I'm a reverse engineer here ReversingLabs. My daily tasks come down to analyzing various software solutions and file formats which we get from our customers and from public repositories and looking for interesting stuff in those file packages and similar file formats.

PAUL ROBERTS
That sounds like a fun job.

KARLO ZANKI
Yeah, it has good days and it has bad days, like any other job. But it is mostly interesting. It's not boring.

PAUL ROBERTS
No, especially not these days. So Karlo, we had you in ConversingLabs, I think back in May to talk about dependency confusion attacks on npm. You had found a whole bunch of those. It ended up being kind of Friendly Fire or Red Team exercise by a German consultancy on other German firms. But today we're here to talk about another npm related supply chain, software supply chain attack. This one seems to be for real, and we wrote about it a little earlier in the month and dubbed it IconBurst. Could you tell us about IconBurst, like what it is and how you manage to come across this in the wild malicious software supply chain attack?

KARLO ZANKI
Well, first, what makes this different from the previous package we talked about is that it's not targeting developers which use the packages, but it's targeting the end users of the applications which the developers create. So it's a bit different. And what's specific about it? It's generally gathering form data from web pages, so it searches for elements with wires, types of form, text, classes or ID, however you wish to find depending on the package version. And then it collects that data and sends it to attacker controlled cross server. So how we found it? Well, as you mentioned last time I was here, we talked about Friendly Fire Red teaming tools targeting German companies. And these tools use specific type of obfuscation tool named JavaScript Obfuscator, public available tool which can be used for free. So we created behavior indicators looking for that which can be used to detect that type of behavior. So when you encounter JavaScript file on any other type of file which uses such Obfuscation, based on our detection rules, we will mark that behavior and link it to that package. So you can search the analyst packages and pinpoint which ones have that type of behavior. So what we do, we continuously monitor new packages that get published to public repositories, satellite them with our tools and look for wires behaviors, including this one. So I specifically looked continuously for that behavior and in one moment several packages secured which had this type of behavior and looking closer at them showed that they weren't as innocent as they behave, as they tried to look. Another thing that caught my eye is that all had a similar name. Most of them were named icon this, icon that, icon. So I did a bit of googling and found that this was legitimate tool published by Ionic.io, I believe and it is a popular item set for front end developers in web system. So I looked into more details and detected, as already mentioned, form stealing tools.

PAUL ROBERTS
So you started looking for this use of this obfuscator, found a bunch of packages and then you looked at those packages and realized there was a lot of similarities in just the naming of these packages. Did a little bit more research and figured out, these names are all pretty similar to a very popular icon package used in front end development. So those I guess for you as a researcher are all sort of red flags, right? The sort of what's going on, you're moving towards a conclusion as to what's going on.

KARLO ZANKI
Yeah, the first thing to notice is the obfuscation. Then okay, obfuscation on its own isn't necessarily malicious, but I would say 50% of packages is using it for legitimate purposes in npm and another half is using it for malicious purposes to hide its malicious behavior. So when you find that packages, then you get five to ten packages with this type of obfuscation you should definitely spend some time of analysis because you have good chances that you'll find something malicious. Right, okay. After that you look at package names that's the first. One popular method is typosquatting which was used in this case. So the attacker changes one or two letters and hopes that someone will mistype. Another thing that you can search is version numbers. You can see if unexpected version numbers appear and you detect that type of behavior and say okay, this is red flag, this could be malicious. So that is how we mainly find interesting things. In this case we did that.

PAUL ROBERTS
And just to sort of frame this for the viewers, how widespread was this attack, how widely used? Obviously there are a lot of open source modules out there. Most of them are not widely distributed or don't have a lot of dependencies. What about in this case with these IconBurst modules?

KARLO ZANKI
Yeah, in this case well, typically when you look at npm packages you want to see how often it's downloaded and if packages download, let's say one of it versions is download 50, 60 times, that is usually just mirroring sites collecting that packages to their hosting places. So if you have a package with download count about 50, it's not very popular package. But in this case one of the packages had more than 7000 downloads. So that's quite a number because that 2 zeros more than usual default download rate. You can tell by the download number count if it was from 17 different users or anything. But you can expect that if you have 17,000 downloads, that good part of it will be instant downloads, not knowing that this is actually malicious. If you have 100 downloads, okay, you can expect these are pentesting...

PAUL ROBERTS
People like you basically. 

KARLO ZANKI
Yeah, 7000 you have a broader community which is using this package in any way.

PAUL ROBERTS
You're talking about 17,000 downloads. Is that, in your mind? Again, developers looking for this ionic icon package and just searching quickly, you know, the malicious package is coming up in their search results and they're just grabbing it just kind of mistaken identity.

KARLO ZANKI
Well, there are many ways you can get to specific package on npm. One is searching on npm, but usually what people do, they listen to some public teaching sessions and they see that someone mentions that framework and they go using it on their own and mistakenly google it or anything and land upon the malicious package. But in this case, the attacker constantly knowingly copied the entire description of the legitimate icon package and put it into his description. He also copied the name, as we already said, modified it just a little bit the domains used inside the malicious code were also mimicking the legitimate domain used by ionic.io. So the developer even put face made the homepage on the same domain looking the same as the official web page of ionic.io. So developer put a lot of effort to mimic and impersonate...

PAUL ROBERTS
Yeah, we did a blog post on this back when you first disclosed it earlier in the month and included the screenshots of the pages for the ionic.io.com page, which was the malicious page, and the ionic.io page, which was the page for the legitimate company that makes the icon package. And they look identical, slightly different wording, but unless you are really paying attention, it would be very difficult to realize that you're at the wrong on place. Interesting for development organizations out there that are tuning into this, what should their orientation be or their position be on this issue of we've got open source modules here that we're using, that we're relying on and whether or not they have obfuscated code. Should it be just a hard line like don't mess around with anything using obfuscated code or, bears... It's something that should make you look a little deeper and figure out what's going on, but not forbid it altogether.

KARLO ZANKI
Well, me as a reverse engineer looking at a large number of threats, my opinion is that you should never use anything that's open source package without looking what's inside of it. Because pushing malicious behavior has become very common. It's not just malicious actors. Legitimate developers get frustrated at some point in their life, their lives and decide to do some bad stuff that can happen. And you don't wish to try your luck with using something freely available without looking at how that works. I know that sometimes you need to have specific knowledge to see what some code does. But let's say I give you a present, no, some pill and tell you "you go drink it, it's okay." Would you really want to do that?

PAUL ROBERTS
I would totally do that. If you gave me the pill Karlo, I'd do it.

KARLO ZANKI
It's okay. I wouldn't buy. Why would buy it? If you see obfuscation, that is a sign that you need to look at it better because you don't want to, somebody tried to make something hard to see. So there is, I believe, 50% chance today that it's on purpose, especially if they put it into an open source repository and before putting it there, made it obfuscated. Why would you do that? Why would you put something public available? And there are legitimate cases, but most developers which put push code up to public repositories wish to share it. They don't wish to hide their functionality. So if you come across obfuscated package, anything in it, obfuscated, check it. See, generally when you tried to find a module that you can use for your purpose, don't go rushing. Okay, I see this, it says it does this and that. Okay, I'll download it, I'll try. No, don't do that. Check first and then try to use it. Because there are a lot of modules that have post-install scripts and they perform some action immediately after you install them. So you don't need to actually use them in your project. They can already create some damage to you. So before you use it, double check it, because security should become everyday hygiene in your development process.

PAUL ROBERTS
So you found this code, you dug into, de-obfuscated the code and took a look at it and just tell us a little bit about what you discovered. What was going on here that struck you as suspicious or malicious. What was this code designed to do?

KARLO ZANKI
Yeah, so I downloaded one of the packages, which I analyzed. Okay. I downloaded the publicly available the deobfuscator for this obfuscator. And what came out? Something looking like a legitimate Jquery, minify Jquery. Okay, why would someone office get legitimate Jquery? That doesn't make sense. Anyone can download Jquery. You don't need to hide functionality.

PAUL ROBERTS
It's not proprietary code. It's not something that is intellectual property that you'd want to obscure.

KARLO ZANKI
Right? Yeah. Okay. You go through, there is about two to 3000 lines of beautified Jquery. And you go down, you go down and you see everything looks like legitimate Jquery. And if you go down deep enough, you come across hex encoded strings. Okay, what are these hex encoded strings? Something is suspicious, you go decode them, and then you come across malicious behavior. So what's up in this case? Someone took in one of the packages. In some other packages, the mechanics were different, but in most of the packages they took legitimate Jquery code, hooked some of its functionality, in some cases it was and function, in some cases I don't know, several functions were depending on the package hooked and they added their behavior behind the legitimate behavior. So they didn't mimic the original and I can say they just put something else in it, in this case Jquery and modified it with the functionality which collects form data and post it to the controllers.

PAUL ROBERTS
And the rest of these packages, these packages were functional, they weren't going to break your application. They did what the legitimate packages they were modeled on were supposed to do. But they just also concerned this...

KARLO ZANKI
When in most cases they created elements, script elements because the preferred usage of ionic icons package is linking some script tags from content network systems and use it in your web page. In this case they add a script elements regular and they're all calling for their script from the same continuous networks, UN, PTG or something, whatever it was. There are other packages targeting other frameworks not ionic icons but also popular frameworks like Umbrella JS, Swiper, Cider or several other packages which were targeted and the attacker tried to mimic them also. And for example, SIDR npm package hasn't been maintained for six years but it has 500 daily or weekly downloads still it's a very popular package so it's a good target for impersonating because probably someone won't notice it because it doesn't get updated, it's been the same version for 6 years.

PAUL ROBERTS
And for developers the legitimate version would look like it's six years old, which would usually be disqualifying and the malicious version would probably have a more recent version number and date stamp on it which would make it look fresher, right?

KARLO ZANKI
Yeah, they could perform well, they could try. But in most cases in this type of attack it was just pure typosquatting. They named it a bit different.

PAUL ROBERTS
And this malicious code that you discovered, what was its purpose, what was it doing within the environments in which it was running?

KARLO ZANKI
Yeah, as I mentioned it wasn't targeted in the developer of the application but the end user. So when Jquery got loaded and everything, web page got generated functional in the browser when user visited this web page and entered trying to submit form data, username and things on that form, it collected form data and uploaded to the attacker controlled domain. So it attacked all kinds of web pages wherever the module was used, collect in some cases generally searching for or all form tags in the html page and submitting their content, serializing it and submitting it to the type of controlled server. So generally in some types modified searching for specific form data, but sometimes generally every form data present on the web page...

PAUL ROBERTS
And this would have been indiscriminate really, any page that this module was deployed on would have been a target. Wasn't any evidence that it was targeted at specific organizations or sites?

KARLO ZANKI
Well, we have found, looking by the attacker names and account names, some clues that led us to conclusion that one portion of this was script was used in phishing attacks in the beginnings. Back in December 2021, Arpan Risky, the user, published a script which was shared in some web tutorials explaining how to steal credentials and for PubG online, multiplayer game, quite popular in some Eastern Oriental countries. So that's one case where we found evidence of usage and linked it to that campaign. In my opinion, they were starting with collecting PubG login credentials, which were also used to login on the pages and later switching to npm environment, JavaScript environment and broadening the reach, trying to catch all kind of login data moving on from just PubG gameplay.

PAUL ROBERTS
Okay, what can organizations do to defend themselves from these types of compromises? Like you said, it's not targeting the developers directly and that is not looking to get data or information out of the developers. It's really targeting the downstream users of the code, people who are filling out these forms on websites. But of course it's doing that by way of fooling the developers into using the module. So as a development organization, maybe with a mixture of open source and proprietary modules that you're using, what's the defense against an attack like this? If you don't have somebody like Karlo Zanki on your team, what do you do?

KARLO ZANKI
Well, there are various tools which can help you detect all kinds of threats. In this case, the threat is usage of bad dependency. What you can do, you can put some level of control on the modules your development team is using. It's like configuring your local mirror of npm repository, gain some insights and ensuring that you are capable to know what dependencies are being used and then performing security analysis or those depends. There are lots of tools, some of them are better, some of them have limited capabilities. But there are ways to perform analysis of public repository contents, especially the one packages that you use. You don't need to scan the entire npm to find most packages. You just need to focus on the dependencies which are used in your application. Perform security checks, see for malicious behavior, see for known malicious detections of those dependencies, and perform regular checks on the open source modules you use. It doesn't depend if it's from npm. There are other package repositories. Their content is equally compromisable as npm. So you need to check open source code you use. Don't go around, okay, this can be used for my needs. As we said, check what you use and always you should check the final, check the final product, because there are some other places where your application inside your organization can get compromised. So you also need to check what you are delivering.

PAUL ROBERTS
Further along in the development pipeline.

KARLO ZANKI
The most important is to sanitize the open source module too.

PAUL ROBERTS
Before we go to questions, I should let people know that we are going to take questions and if you want to use the riverside chat feature you can pose a question for Karlo. It's not common to have somebody of his level of expertise at your disposal. So if you got questions on supply chain risk and attacks, use the chat feature and we will pass this along to Karlo. Karlo, since you initially discovered this, you have discovered additional packages. So two questions. First is, what happened to the first group of malicious npm packages that you discovered? Or have those been taken offline? And also tell us about what you've discovered subsequently. This IconBurst attack appears to be ongoing.

KARLO ZANKI
Well, the original set of packages which we discovered were all reported to npm security team. They removed it in less than a week or just a few days. But continuously new packages appear. The attacker creates new accounts, publishes new packages, primarily still focusing icons package. But sometimes some other JavaScript packages or functionalities get spotted. What's important is there's no easy way to prevent someone from publishing to npm because it's not hard to modify the content of JavaScript file, especially if you perform obfuscation on it. So there is no signature based detection in this case, all files are obfuscated. Someone changes, it gets obfuscated and the obfuscation can be a legitimate type of behavior as we mentioned. So it's hard to detect it by automated analysis at the publishing time. So you need to check it when you use it. This type of attack can be expected to be present for some more time. Occasionally, probably new versions of malware will be published. As we seen it last week, two new modules appeared so the end users should be aware of that threat. And as I mentioned, the easiest way to text this detection of usage of JavaScript obfuscated, that should be the first red flag.

PAUL ROBERTS
Final question what do we know about that, you said these attacks are still popping up. What do we know about the individuals or group behind IconBurst and what the objective here is?

KARLO ZANKI
We don't know much. Most of the evidence suggests that it's the work of one person. But it is possible that other malicious actors have bought these scripts from the original order. These are being distributed on various channels and it is possible that several publishers are publishing to npm. We believe that the initial offer is linked to Indonesia. There are some agents that suggest that the original campaign targeting PubG users was sourced from Indonesian territory by Indonesian speaking person. But in the meantime we have no evidence of the final number of possible publishers, to npm and their motivations, what they are looking for. But what is for sure is that they are targeting collection of user credentials.

PAUL ROBERTS
And for organizations, just that this is a type of attack and a methodology that adversaries are increasingly aware of and using to their advantage. Right, so this is something that you need to be attuned to. Let me just say I think we're ready for question and answer now, Karlo, if you're up for it.

KARLO ZANKI
Yeah.

PAUL ROBERTS
Are you sure?

KARLO ZANKI
Yes.

PAUL ROBERTS
I'm going to invite Carolynn into the studio. Carolynn is our producer. Hey, Carolynn. Welcome back.

CAROLYNN VAN ARSDALE
Hi Paul. Hi Karlo, thanks for having me. My name is Carolynn van Arsdale, I'm a producer for ConversingLabs and I do have some questions for Karlo today. So Karlo, are you ready?

KARLO ZANKI
Yeah, I'm ready.

PAUL ROBERTS
And while Carolynn is asking questions, if you are listening and you have additional questions, use the chat feature and we'll add them to the list. Go ahead Carolynn.

CAROLYNN VAN ARSDALE
First question for you Karlo is how is IconBurst different from other software supply chain attacks such as SolarWinds or CodeCov?

KARLO ZANKI
Well, in the case of SolarWinds, the attackers compromised the build infrastructure of the publisher of software and they infiltrate it through that vector. In this case, they aren't targeting the infrastructure of software developer through any offensive method. Instead they are trying to make them use modules published by the attacker. So they aren't infiltrating their network or anything like that, they're just trying to lure them to use their packages for their functionality and in that way get to the final customers of those software producers.

CAROLYNN VAN ARSDALE
Okay, great. And next question for you Karlo. What is the easiest way to search for obfuscated code in an npm module?

KARLO ZANKI
Well, I do it by usage of our tools. We are ReversingLabs have secure.software platform which is continuously improved with additional functionality helping you find threats. And in this case we created indicator of behavior which can help you spot usage of the obfuscator. Basically you should focus on behavior of the software. Behavior of the software can give you a lot of information about what you are going to use. So, is it testing file system? Is it using network ports? Is it using some known encryption algorithms? These are all known behaviors and there are tools which can help detect such behaviors. You should look for tools which provide you with this functionality. Or you should try no, you can try to write your YARA rules or something like that. There are other ways to detect it, but I believe that easiest ways to use tools which are good at it and which can help you detect it. Not to reinvent the wheel but use someone's good functionality.

CAROLYNN VAN ARSDALE
Thank you. And next question for you. Should we refuse any npm module that contains obfuscated code? Or do legitimate modules sometimes contain obfuscated code also?

KARLO ZANKI
Yeah, as I mentioned, you shouldn't refuse it, you shouldn't ban it. If you see obfuscation in some modules, you should de-obfuscate it and see what's in it. There are legitimate modules which for some reason use obfuscation in npm. But if you are using some other source for your modules, there are various third party modules which have legitimate reasons why they obfuscate their code. So banning something because it's using obfuscation isn't going to just...

PAUL ROBERTS
It's a blunt instrument.

KARLO ZANKI
Yeah, you can just go and rub everything you need to see, find out what's good, what's bad and separate.

CAROLYNN VAN ARSDALE
Okay, got it. Makes sense. Next question, and this is going to be the last question as well, are there ways to programmatically prevent typosquatting attacks like this or is it just a matter of developer education?

KARLO ZANKI
Well, there are algorithms which can help you detect typosquatting. If you Google it, you will find lots of algorithms which are good at this but they are also not perfect. If they were perfect, public repositories would detect typosquatting immediately. So you can try and use some of your instances if you have researchers to create detection for these types. But as much as I'm familiar with currently this isn't working 100% good. I believe that you can't say it's bulletproof and that if you program something to help you take this, it will probably have some blind spots where it could leak and if you rely on it too much you could get yourself in a problem.

PAUL ROBERTS
And we talked about this with the dependency confusion attacks. If you've got internally developed modules that are non-public, we were saying it probably is worth your while to pay attention to newly created modules that might be mimicking those. Right. As much as you can. Right?

KARLO ZANKI
Yes. In some cases it won't be typosquatting. There are different types of detects, so it's not always typosquatting. And I'm not sure if you wish to use your researchers for each type of attack and new attacks that will appear.

PAUL ROBERTS
Karlo Zanki, thank you so much for coming back in and speaking to us on ConversingLabs. It's been a great conversation and I'm sure we'll have you back on again.

KARLO ZANKI
Thanks Paul, for calling me, happy to see you again.

PAUL ROBERTS
And for folks who are watching, we are recording this and we'll be posting it on our website after the fact. If you want to share it around in your network or come back and watch it again, it will be on the ReversingLabs website so stay tuned for that. And thank you all very much. We'll be back sooner than you might think with some new episodes and we're going to be at the Black Hat.