Speaker Spotlight - Megg S. - Anatomy of a Sandworm: A Deep Dive into the Shai-Hulud Attacks

[music] Hey everyone, I'm Steve Pellerin, a volunteer director at large with the Vancouver Island Security Research Society. We're getting ready for BSides Vancouver Island, an accessible, community-driven cybersecurity conference happening Friday, September 25th at the Victoria Conference Centre. This year is our fifth anniversary and for the first time we'll have two talk tracks with even more great content for the community. Today, I'm joined by Meg, one of the speakers who will be helping us look at a particularly unsettling kind of software supply chain attack. Her talk is titled Anatomy of a Sandworm, a deep dive into the Shai Hulud attacks. When most people hear about a compromised software package, they probably imagine a poisoned update reaching unsuspecting users. Shai Hulud was something different. It acted more

like a new kind of beast, a self-propagating worm that could use developer environments, stolen credentials, and trusted accounts to keep spreading through the software ecosystem. It was also remarkably loud. Rather than relying entirely on stealth, it stole secrets, created repositories, abused legitimate tools, and in later versions included a destructive payload. Meg is an application security engineer with a background in web development. She works closely with software teams to make security part of the development process without making that process impossible to use. She also enjoys sharing knowledge, especially when the subject is both educational and just a little frightening. Meg, welcome. Before we get into the details, could you introduce yourself and give us a preview of what attendees can expect from your deep dive into

Shai Hulud? Yeah, so I'm Meg Sage. I'm a senior product security engineer at PagerDuty. And so for this talk, I'm going to go into the basically a lot the evolution of the Shai Hulud attacks. So we'll start with the first one and then go all the way through to the most recent ones. The first couple were really the kind of had a lot of uh sort of publicity around them in the industry because they were very new. It was a new kind of attack. So we're going to go into those and show how they worked and how they defied defied various conventions that we typically saw with these attacks, the new worm behavior that was very very effective and it was something that we

hadn't seen in any any NPM supply chain attacks. So I'm going to go into all of that and then also into how the attacks evolved over the past year cuz they've they've changed a lot from when they first started and how the different iterations are defeating different protections that are being put in place because GitHub, NPM community have done a lot to try to protect against these these attacks and try to defeat them and yeah, the attacks seem to still keep defeating the different protections that we put in and they're still seeming to be very effective basically a year later. That's a great overview. The Shai Hulud attacks raised important questions about trust, software dependencies, and how quickly a compromise can move through modern

development environments. Let's start with what made this campaign so unusual, our first question. Supply chain attacks are not new, but Shai Hulud behaved like a self-propagating worm and was unusually loud about what it was doing like we mentioned. What made this cam- campaign different from the supply chain compromises that security teams were more accustomed to seeing? So previously most of the supply chain attacks you would see it would be targeting like a specific maintainer or specific like a company that puts out a package and you would see all of their packages infected or you would see completely different types of attacks where it's attackers are publishing completely new packages that have malicious code in them. Those ones are

generally speaking a lot easier to avoid but with attacks where the like legitimate packages have been compromised, those are the ones that tend to be more effective and previously those attacks had all been fairly siloed. They would be you would see like one maintainer, one company compromised. You would never see it spread into other packages and so with shai hulud that was something completely completely different. It would harvest NPM tokens and use them to publish new versions of other packages that it had infected. And the other part about how allowed this was was very interesting because typically when an attack happens we don't have a lot of insight into the victims because it's all about like who discloses that they were a victim of an

attack and the data that attackers exfiltrate often goes off into their own infrastructure. It's not somewhere public. With shai hulud it was the data that was being stolen and was published to GitHub. It's published in public GitHub repos so we could actually see the number of victims to to an extent not necessarily per se everyone that was affected but it gave a lot of insight into the the victimology in this case. Absolutely. Thank you for Thank you for that. Um next question. The worm evolved between iterations changing its tools, tactics, and even its JavaScript runtime. What did those changes reveal about the attacker's objectives and their ability to adapt when defenders closed off earlier paths? I think it showed a lot about that the attackers

were paying attention to how the community was responding and trying to stay stay ahead of all the different protections. So, they were finding ways to defeat them or render them less effective. And again, it was so And some of them, I don't necessarily want to go too far into the details. It was like Please don't. things the community had really touted as being like, "Yeah, this is going to protect us all. This will be a great indicator." And yet, some of the attacks were still able to defeat those. So, it's really interesting to see how it has evolved over the over time and how the different things have been defeated. Yes, keep absolutely those details for

the talk. We'll have to come. Last big question for developers and security teams working with NPM, GitHub, and modern software pipelines. What are the most important practical lessons from Shai Halud? And what is one action that they can take right away to reduce their exposure? So, the biggest the biggest thing that can be done is ensuring that you're when you're using any kind of dependencies, and this isn't just specific to NPM, is pinning to the exact version. Previously, the recommendation had always been like, "Okay, we'll pin to a major version or a minor version." So, these make up security updates easier and you don't have to worry about doing that. But, that's sort of what these attacks rely on. These attacks rely on people not being pinned to exact versions.

So, if you are pinned to an exact version and a malicious update comes out, you're not going to just automatically get that without knowing. Your risk would be a lot smaller because it would require you to actually go in and be bumping that that dependency while the malicious version is out there. Great. Final bonus question, if you want. How can application security teams build stronger supply chain protections without making development workflows so painful that teams work around them. I think with um with these kinds of attacks, first off, there's the pinning to exact versions. And yes, this does mean people need to be more explicit about updating their dependencies, but when you compare it to the risk, I feel like a lot of developers do understand it.

Because at the end of the day, their dev machines are they going to likely be the first victim. Because if they're installing dependencies and updating depends and pulling in new dependencies on their dev machines, which they're likely to do before it even goes into a CI/CD system, it's their machines that are being compromised. So, like I don't really see why developers wouldn't want to be on board with something that's also protecting protecting their machines from getting compromised. It's probably going to be a big headache if that happens to them. The other piece of this is really with any tooling that you put in place, work with developers and ensure that it's not going to how you implement it and how it's supposed to be used actually makes sense

with how they work and you're not just implementing something and just being like, "Okay, well, this is how it is now." without working with them and getting their feedback first. Meg, thank you so very much for joining us and giving us this insightful preview of your session. shaihalud is a powerful reminder that the tools developers trust every day can also become part of the attackers path through the software supply chain. Your talk will help attendees understand how this worm spread and how development and security teams can think more clearly about preventing and responding to attacks like this in the future. And thanks to everyone watching and listening. We hope this conversation has given you a taste

of what you can expect at BSides Vancouver Island. To see Meg's full session and join us in Victoria, Visit bsidesvi.com to get your tickets. And if you purchase those tickets before Monday, August 24th, you'll receive an exclusive custom-designed black hacker-esque BSides Vancouver Island t-shirt in the size of your choice, while supplies last. You can also find our podcast and links to all of our social channels at bsidesvi.com. Follow along, join the conversation, and use #BSidesVI in your post. Thanks again for watching and listening. We'll see you Friday, September 25th in Victoria. Meg, thank you again for your time. Thank you. [music]