Mackenzie Jackson: Hello everyone. You're listening to the show where we bring the latest and greatest in cybersecurity news, research, and leaders. My name is Mackenzie Jackson and you are listening to The Secure Disclosure. We have a great show planned for you today. It's probably no surprise that we're going to kick things off with the Shai Hulud, The Second Coming self-replicating worm that yet again hit npm and GitHub. We're going to sit down with Charlie Eriksen, the researcher that first discovered this and alerted it. We're going to talk about how the mechanics of the worm actually work, how Charlie discovered it, and what this means for security in general. We're also going to be talking about a sophisticated phishing campaign that was really targeting Booking.com and specifically Booking.com's guests, a campaign called I Paid Twice. I sit down with the researchers that found them, Jérémy Sicon and Quentin Bourgue, to discuss exactly the mechanics of this and what makes this sophisticated and unique. It's going to be a wild ride. Monday, November 24th, we saw a second self-replicating worm, Shai Hulud, The Second Coming, cause havoc. Just as a reminder, this is actually the second campaign of this exact type. The first time we saw this Shai Hulud worm was in September. It was discovered by a developer that we had on the show, Daniel Pira, and we discussed with him how he uncovered it. In total, this compromised 180 npm packages, and we also saw around about 5,000 repositories get created publicly on GitHub with secrets. Well, The Second Coming was a whole lot worse. This new worm, which was extremely similar in its mechanisms. As I'm recording this, the campaign is still ongoing. We've seen about 800 npm packages get compromised. They have a total download radius of 200 million weekly downloads, and we've seen more than 30,000 GitHub repositories be created containing secrets. Some of the most significant packages that were compromised from this were npm packages belonging to Zapier, Postman, PostHog, and AsyncAPI and there are huge amounts of other organizations as well. The general mechanisms of the attack work like this. A malicious JavaScript file is created in your npm project. The malware then uses life cycle scripts basically to immediately run this malware as soon as the package is installed. It then scans the environment for secrets using a tool called Trufflehog. It then publishes those secrets publicly in GitHub repositories with the description Shai Hulud, The Second Coming. Inside these public repositories, there's usually multiple files such as environment.json, cloud.json, and these all contain secrets that have been Base64 encoded. They've been Base64 encoded twice. This isn't really much of a barrier. If we decode these, which you easily can, you get the secrets. So, now that we're kind of caught up on how it all works, I wanted to deep dive into Charlie of how he actually discovered this in the first place. Some of the most significant packages that were compromised from this was npm packages belongs to Zapier, Postman, PostHog and Async API and there is huge amounts of other organizations as well. The general mechanisms of the attack work like this. A malicious JavaScript file is created in your npm project. The malware then uses lifestyle scripts basically to immediately run this malware as soon as the package is installed. It then scans the environment for secrets using a tool called Trufflehog. It then publishes those secrets publicly in GitHub repositories with the description Shai Hulud, The Second Coming. Inside these public repositories, there's usually multiple files such as environment.json, cloud.json, and these all contain secrets that have been Base64 encoded. They've been Base64 encoded twice. This isn't really much of a barrier. If we decode these, which you easily can, you get the secrets. So, now that we're kind of caught up on how it all works, I wanted to deep dive into Charlie of how he actually discovered this in the first place. Sat down at my desk, pulled up the triage queue, saw it was quite busy and I pulled up one of the packages and I see it had triggered on our Shai Hulud rules and I was like, "Nah, surely this must be a false positive." But it was in a really big file, so I was like, "Oh no." So I pull through it. I'm like, "Sure enough, this is a variant of Shai Hulud." And then I look through, right? I start frantically posting like, "No, this is real." I find initially the Zapier packages and I see it goes PostHog and then Postman and then the AsyncAPI. I was like, "Okay, these are really big packages." Especially the AsyncAPI one. "Those are really big." It's like, "Yeah, no, this is real." And at that point I didn't even realize how deep our queue was in terms of actual packages that were in there. And when I started to really realize the impact, the actual scope, how many packages it was, like, "Yeah, this is big." We also then saw of course the GitHub repositories is like 20 some thousand. In the campaign, multiple projects including Zapier, Postman, PostHog, and AsyncAPI were all infected around about the same time, and the first being AsyncAPI. These first packages were seeded by the attackers, meaning that they had stolen credentials, and this is how they first seeded the worm. And because they were very popular packages, this is how the worm actually got kickstarted. It needs a certain amount of momentum to keep going. I wanted to understand how these attackers actually got their secrets to seed it, and it's terrifying because it's completely different to what I thought. With all of these repositories getting uploaded to GitHub, they all had the exact same description, Shai Hulud, The Second Coming, all 30,000 of them. So, an obvious place might be, "Hey, why wouldn't GitHub just prevent or automatically delete, you know, all of these repositories that are coming up?" Well, the attackers actually thought about this too. And if they are unable to post to GitHub, then they wipe all the information from your machine. Charlie explains more.credentials for both Open VSX and npm through GitHub Actions on AsyncAPI. So they use the same type of vulnerability, well, actually I think the same vulnerability to both compromise their CLI repository and the extension repository from what I can tell. So they kind of realized that they could go for both targets and spread through multiple vectors. Unfortunately, a little bit of a complicated thing because the way that GitHub Action works is complicated. I think one of the things that we saw in the first attack by this group, the Singularity attack against NX, what we observed was that they used effectively a vulnerability in one of their GitHub Action setups in a public GitHub repository where using a little bit of branching magic and using this thing called a pull request target, they are basically able to get their own code to run within the context of a GitHub Action with the full environment and credentials of the actual organization, but with the attacker code. It's called an own request, pwn request, by GitHub, and what we're seeing now, just like five minutes before we started recording, I got a message from the co-founder at PostHog sending me the postmortem that they've just pushed out, and what we're seeing also is that they confirmed it was through GitHub Actions. It was the case with AsyncAPI through GitHub Actions, and what we're seeing in terms of the metadata from Postman is that it also definitely looks like it was GitHub Actions. Now, this all gets a little bit complicated, but let me try and explain it a little bit simply. GitHub Actions, the CI/CD pipeline to GitHub can get very, very complicated. When it gets complicated, GitHub allows you to create custom scripts for it. Now usually the process goes when you have public projects like the ones that we're talking about from Zapier, from PostHog, is that anyone can actually make a pull request. This pull request sits there until it's either rejected or merged into it. But before a human reviews that pull request, it goes through the GitHub Action so that the reviewer can see what has passed and what has failed. But here's where it gets tricky. If the change that you're making is in fact to one of the custom scripts that GitHub Action is using, then you can manipulate that action to dump out, let's say, environment variables or secrets without the pull request getting accepted. In other words, you can trigger remote code execution through GitHub Actions by editing one of the custom script files for the GitHub Action. So no human actually needs to approve this. Now in order for this to happen, there's a lot of conditions that need to be met. So if you're using GitHub Actions, it doesn't necessarily mean that anyone willy-nilly can do remote code execution on you if they're editing your GitHub Actions file. It's only for specific scripts, but it is pretty terrifying. So the vulnerability in the case of PostHog was introduced back in September. And if you look at the pull request for it, you actually see that the GitHub CodeQL security scanner alerted them saying, "Hey, this is really unsafe."Charlie Eriksen: It will see if you have an npm token in your environment and then it will check if you have any packages that you have published or have publish access to. It will then try to spread itself into those, right? So copy itself into them to basically worm, right? So it will spread itself through new packages. Well, it will run Trufflehog, right? It will look for secrets. It will take all the environment variables, collect all the secrets together. It will also look for AWS, Azure cloud credentials and things like that. And then it will collect that all together. And if you have a GitHub access token in your environment, it will just populate this in your GitHub repo in your account. Now, if you don't have a GitHub access token in your environment, it will go into GitHub and it will search for the Shai Hulud repositories and it will iterate through all those repositories until it finds a valid access token to publish to. So it's basically crowdsourcing access to GitHub repositories to distribute and exfiltrate through, which is really genius because it means that you always mostly have an exfiltration mechanism unless GitHub does something. Now here's where it gets really nasty. If the environment does not have an npm token, it does not have a GitHub token, and it's not able to find a GitHub token through GitHub search, it will delete all of the user's files in the home directory. It becomes a wiper, a dead man where if GitHub was to shut them down, just prohibit the publishing and searching of these repositories, it will wipe people's machines. This is particularly nasty and it comes down to something that I can't quite wrap my head around with this attack. The attackers are using GitHub as a C2 server. There's lots of reasons why you might do this, but it is a little bit strange that they're making all of this public because what happens is when someone's secrets get leaked publicly, well, we know who the victims are. We can alert them. They know their secrets have been leaked, so they can rotate them. It would have been much more beneficial for the attackers to kind of keep this private or maybe encrypt the secrets so that only they can get access to them. So how many total secrets and everything were leaked? GG Guardian did a study and they discovered that there were thousands of valid secrets inside this. Not all secrets can be validated. So this doesn't mean that these are the only kind of active secrets, but these are secrets that were definitely valid at the time, which is kind of terrifying. So, with all of these secrets out there in the public, with all of this kind of craziness and what I can only describe as malevolence happening with these attackers, what is their goal? What are they after? Well, I asked Charlie and unfortunately, well, we don't really know. We haven't really been able to tell, right? A lot of the things that journalists will ask also about the previous attacks were, "Right? So, they've been dumping these credentials now, right? But what have they been using them for?" And we don't really know. Surely, they've used them for something, right? Because they did get a lot of credentials, but we really haven't, at least I haven't seen any reporting anywhere that has really made that connection, right? And now we've got it at a scale that is, you know, I think probably order of a magnitude larger, I would, I would estimate. What is super interesting about this case is that we really saw community spread. In the first Shai Hulud campaign, most of what we saw was that the attackers themselves were seeding the malicious packages, meaning that they had stolen credentials somehow. We'll discuss that. But then they were manually infecting the packages. Well, now we're really seeing that the worm mechanism that makes it self-propagate really sped up in this case. One other little interesting side quest in this attack is that it appears that AsyncAPI, which one of the first victims that the attack has seeded, the attackers also compromised their Open VSX extension. So, we've talked about malicious VS Code extensions a lot on the previous episode, I think on the previous episode before that, too. Only one extension was malicious at this point. There are no reports. We haven't found any other evidence. But it is interesting that the attackers are also experimenting with different environments. Majority of this attack happened on npm, but there were reports of malware being found in Maven, and we also discovered the VS Code extensions. I asked Charlie a little bit more about this. What we actually saw was that in the case of AsyncAPI, they, a couple of hours before it seems to be, they compromised their Open VSX extension and deployed that first before they actually compromised the npm packages. So in terms of like actual public spread, the Open VSX extension was kind of patient zero, but they then started seeding it through a couple of npm package, like a couple of npm organizations. So are we going to see follow-ons from this? Yes, almost certainly. Here's why. The sheer number of secrets that have been exposed publicly, I can guarantee that despite everyone's best efforts, a huge amount of these will never be rotated. In fact, they will remain valid. So this means that the attackers can use them. Yes, it also means that every other attacker in the world can also use them. Trust me when I say that there will be a huge amount of secondary attackers with no relation to this that will be collecting these credentials and using them. So whether it's from the actors that launched this brief or it's opportunistic actors, there's going to be a lot of breaches that happen because of this. So if you are watching this, there's a couple of things that you have to do. Check to see if any of the packages that were compromised are in your supply chain. They're very popular. These aren't obscure packages, so they very well could be in there. If you see that, then make sure that you check inside your repositories of your GitHub, your employees GitHub accounts to try and find something with a description of Shai Hulud, The Second Coming. Make sure you rotate all of your credentials. When in doubt, rotate. We will wrap up from the segment, but as this hasn't been a very cheery segment, I did want to leave on one funny note. There was something that happened after the first Shai Hulud campaign, and that is that Charlie actually found a bug in their workflow, and he reported it on X. Now, we did get a little bit lucky that it appears that these attackers aren't necessarily on X because they didn't fix the bug. Here's Charlie explaining. when they actually worm into a different package, they use just like the normal tar command and that does not strip out user group and time stamp information like the normal npm publish pack process does. So it's very obvious that it's been modified manually. So we can see that it was not published in a normal sort of pipeline. So that was one of the things we implemented straight off the Shai Hulud one, just like, "Hey, like we have like it's we, we, we do get some detections on it that are not Shai Hulud," but there's a very few. So when we see that the metadata in the archive is all over the place, yeah, that's, that's a good indicator. And now is a good segue to talk about the sponsor of this podcast, Aikido Security. Aikido Security have released an open-source free tool called SafeChain to help us protect us against exact attacks like this. SafeChain works as a wrapper around your package managers like npm. So when you run commands like npm install, SafeChain will first check that none of those packages are malicious. It connects to the Intel database. And just as a reminder, Aikido were the first to discover this attack. So you can be confident that this database is one of the best out there and frequently updated. Aikido SafeChain works by staying in your development environment. It's open source. It's free. So, you absolutely should check it out. Jérémy and Quentin from sekoia.io uncovered a very sophisticated phishing campaign that was specifically targeting hotel guests. What was really interesting, their investigation revealed a technique where attackers would actually infiltrate real Booking.com accounts and use the legitimate backend services to create fake payment requests for hotel guests. Today, they walk us through exactly the steps of what happened in this campaign, how the malware behind it all actually operated, and how there is an entire dark ecosystem that helps campaigns like this get off the ground. The first question that I obviously had is just for Jérémy and Quentin to explain a little bit in their words what exactly happened and how they found this. is in fact the hotel computer. So for that it starts with a classical email sent to hotel accommodation email. "We need some things for food," or, "It's possible to have another bed or something like that." When the people click the link, the malware, they go through several redirecting pages designed to hide the real source of the attack and land on a fake Booking.com page. In your case, this fake Booking.com page asks the victim to run a command with PowerShell. It's the clickfix technique. If the guest, if the victim runs the command, the infection starts with downloading a payload and next lead to the infection of the computer. And to add a detail, the malicious web page impersonates Booking.com, but also impersonates the reCAPTCHA challenge and that's, yeah, the fake page is asking for the user to solve this CAPTCHA and this is why the user is trying to execute a PowerShell command to solve this fake CAPTCHA. Something really interesting here that alludes to an entire ecosystem that most people don't know about and that is PureRAT. See, this isn't just some random malware that one of these attackers created. No, it's malware that they purchased. PureRAT is a known remote access Trojan that you can buy and you can use it. It's part of what we call ransomware as a service or malware as a service. for many malicious campaigns we are trying to uncover the infrastructure. So it's, yeah, we are doing it every time and for that we try first to understand how does the cyberattack work and what are the main steps how explained by Jérémy. Then we analyze the different stages and identify the specific characteristics associated with these stages. And last we try to pivot using this characteristic in order to discover the whole infrastructure used by the attacker. So first we have replayed the attack in lab environments, like we are victim, for both stages of the attacks. So we are monitoring the attack in our lab environment to collect some technical artifacts about the domain names, the URLs, the file and so on. And then for every step listed in the first analysis, we'll try to identify some specific characteristics for the technical artifacts. So it can be URL patterns, it can be domain names pattern or registration details or some hosting on some autonomous system and so on. And all of this allow us to uncover every, every stages of the infrastructures. And then as I said we try to pivot on the specific characteristic to unveil the all the domains used by the attackers, and we can use this, this information to detect further operation or ongoing campaigns in our customers' logs. Attribution is always difficult. It's very hard to say that this is this attack group or this person or even that they're from this country unless you've seen this style of attack before and you can identify certain fingerprints of one attack to a previous attack that has credibly been identified. Now this isn't the case in this case but there were a few clues including the fact that it seemed to be that the attackers were Russian speaking. This attack actually scratches at the surface of something really interesting and that is the dark web ecosystem that is set up for attacks like this: malware for rent, log marketplaces, credential brokers, access brokers, everything that you can imagine at the access for cyber criminals. So you don't have to be a mastermind at everything. If you want to, you can just pay other people to help you deal with this or even just sell access so that you don't have to get your hands dirty. And finally, I just asked Quentin and Jérémy to share a little bit about sekoia.io, what that company does and when it might actually be useful if you want to reach out for them.Unknown Speaker: We have uncovered a phishing operation as you say targeting hotels. This campaign impersonates booking platforms like Booking.com or Expedia and then targets the guest. The attacker first infects computers for stealing admin credentials for that and then uses this access to send messages to the guest, making this campaign extremely convincing.Mackenzie Jackson: Phishing isn't all that new. I'm sure we've all received various phishing emails, the classic message from the CEO who needs you to do something urgently or maybe even the more sophisticated ones that we've seen for npm account takeovers. This attack, however, was really quite sophisticated. It blended advanced social engineering campaigns with very sophisticated malware all of an ecosystem ready to support this malicious activity. And that's why this wasn't your standard spray and pray type phishing attack.Unknown Speaker: Yeah. The difference in this phishing operation is the professionalization and the ecosystem. The modus operandi consisting in targeting the booking platforms account is quite widespread in the wild and attackers conduct more sophisticated campaigns using recent social engineering tactics such as click-jacking or advanced techniques such as fileless execution. And moreover, cybercrime forums are full of services facilitating this modus operandi. So showing that numerous threat actors adopt this kind of phishing campaigns and you don't have to be very sophisticated to conduct this kind of phishing operations.Mackenzie Jackson: I wanted Jérémy and Quentin to take us through the technical steps of this because it was really quite amazing. The attack begins with a seemingly innocent request from a guest, but then one click from hotel staff sends them through a series of mazes that ends up in a fake Booking.com account that instructs them to use a PowerShell script which downloaded something called PureRAT, an off-the-shelf remote access Trojan virus, which then allows them to conduct their attack. I asked Jérémy and Quentin to walk us through the technical details of what actually was going on amongst this maze.Unknown Speaker: is a remote access tool sold as a malware as a service. So it's important to know that the attacker haven't developed this tool. It just rents it. This tool is very powerful like a lot of remote access tools. It permits to take screenshots, execute remote command. But in your case the main functionality is to steal credentials. So with this tool attacker could steal booking accounts and maybe other, other sensitive credentials.Mackenzie Jackson: One of the things that I was really curious about is understanding more about the infrastructure that this kind of sat on, the infrastructure that the attackers use, their domains, hosting patterns, redirects and all of the other various indicators of compromise that could be used to identify who these attackers were and what they were ultimately doing.Unknown Speaker: Yeah, attribution is very challenging and for this campaign we were not able to associate this campaign with a known threat actor already documented by other cybersecurity vendors nor with a personal active on cybercrime forums. But we assess with medium or high confidence that the attacker behind this campaign belongs to the Russian speaking ecosystem as their modus operandi is often discussed on this forum. There are many services that facilitating this kind of modus operandi and we also found I think some Russian comments in HTML codes. So yeah, there are some hints that allow us to think that the attacker is Russian speaking here.Mackenzie Jackson: So how big was this? Was this just a few hotels? Was it a limited amount of time? Was it a long amount of time? Well, this was quite interesting because this type of attack had actually been going on for a long time. And had one of sekoia.io's customers not actually reached out to them to say, "Hey, this is weird," then it probably would still be ongoing today. In fact, it actually still might be ongoing today. So, I asked Jérémy and Quentin about the scale and scope of this and when they have first and how far back they can attribute instances of this attack.Unknown Speaker: Oh, it's quite possible to know the scale of this campaign since we discovered hundreds of domains registered by this threat between April 2025 and now November 2025. So this campaign is very widespread and thanks to our products we identify some French companies that have been targeted by this campaign. But during the investigation we also discovered that some hotels in the US or in the Middle East were impersonated to target their customers, their guests. So yeah, we assess with high confidence that this campaign targets the hospitality sector worldwide and since April 2025, but I believe that this campaign was active before because we, we found evidence in April 2025 by pivoting on the adversaries infrastructure but we don't have any capability to pivot. Yeah, it's more complicated to pivot on the infrastructure of 2024 or before. So yeah, we are confident that this campaign is active since at least April 2025, but likely even years before.Unknown Speaker: Colleague from Netcraft has released a blog post about this campaign. It's very interesting because they have tracked this cluster from one year, the fishing, the banking fishing cluster, and they have highlighted more than 4,000 domains and were also able to link to several hostnames and this domain impersonates Booking, Expedia, Airbnb and other booking platforms. So it's very, very...Unknown Speaker: is a French cybersecurity vendor. We are developing and selling a SOC platform and this SOC platform is fueled with our CTI and other detection rules and anomaly based detection rules and Jérémy and I are in the threat detection and research team which is focused on tracking, analyzing and the cybercrime and also the APT, so for the national state sponsor cyber, yeah, cyber threat.Mackenzie Jackson: Well, on that cheery note, that's all that we had for you today. We'll be back next week with a brand new episode. So, make sure you subscribe to the channel and like this video. And I'll be looking forward to seeing you next week on The Secure Disclosure.
