Dirk-Jan Mollema walks us through The Entra ID Cross-Tenant Vulnerability Discovery– 2025-09-22

Summary

Talkin' About [Infosec] News, Powered by Black Hills Information Security

Episode: Dirk-Jan Mollema walks us through The Entra ID Cross-Tenant Vulnerability Discovery
Date: September 25, 2025

---

Episode Overview

This episode is a deep technical and candid discussion between the Black Hills Information Security (BHIS) team and renowned security researcher Dirk-Jan Mollema. The core focus is Dirk-Jan’s discovery of a critical cross-tenant privilege escalation vulnerability affecting Microsoft Entra ID (formerly Azure AD), with wider explorations of recent infosec headlines including the Shai Hulud npm worm and supply chain attacks. The conversation blends vulnerability research, practical incident response, and the ongoing struggles of defending complex modern infrastructure—punctuated by the crew’s irreverent humor and war stories from the security trenches.

---

Featured Guest

Dirk-Jan Mollema

• Cloud exploitation researcher
• Operator of Outsider Security (pen testing and training)
• Creator/contributor to Roadtools (Azure/Entra AD recon)

[04:01] A: “Our real celebrity guest is Dirk-Jan, a cloud exploitation expert, or just hated by Microsoft maybe is your job title...”

---

Detailed Breakdown & Key Insights

1. Entra ID Cross-Tenant Vulnerability: The Discovery and Impact

• Dirk-Jan’s Big Find ([05:03], [07:57], [08:43])

  • Found a bug in Microsoft’s Entra ID cloud authentication that allowed a token acquired in one tenant to be used for privilege escalation across other tenants­—a major cross-tenant issue.
  • Microsoft initially rated the CVE as high-severity (9), but later boosted it to critical (10).
    • Dirk-Jan [05:16]: “They said, attack complexity high. And I was like, I don't think it's that high.”
  • The main vector involved manipulating authentication tokens and exploring API boundaries—an insight that only came during slide polish for Blackhat/DEFCON talks.

• Discovery Details

  • Came from a hunch—"something’s off here" and a methodical exploration of what errors and edge cases emerged when tweaking token payloads.
    • Dirk-Jan [06:09]: "Sometimes, like, when you're researching something, you just get that feeling like, hey, something's off here. Something's not right with this product or protocol. It has to be broken somehow."
  • Key moment: Trying a token on his own production tenant and unexpectedly receiving data back, proving true cross-tenant privilege.
    • Dirk-Jan [07:55]: "I changed it to my real tenant where I host my email ... I figured out it really worked and I tested it with a few other test tenants I have. And I was like, okay, this actually works cross-tenant."

• Disclosure and Timeline

  • Discovered just weeks before Blackhat/DEFCON; Microsoft silently patched before his public talks.
  • Only included cryptic teasers in his presentations, out of respect for timing and to not overshadow other content.

• Scope & Affected Systems ([10:42])

  • Though first identified in hybrid-joined setups, the vulnerability did not require hybrid join—any tenant with Exchange credentials could be affected.

• Indicators of Compromise & Logging ([11:41])

  • Little to no native logging for the legacy APIs involved; actual exploitation may be undetectable unless privilege changes (e.g., new admin users) are made.
    • Dirk-Jan: “...no API level logging yet for this API... if you want to change something, then that will result in audit logs. So I can add like a new global admin...”

• Legacy APIs & Roadtools ([13:16])

  • Debates on Microsoft’s slow deprecation of legacy APIs; Dirk is ready to move Roadtools to Graph API when forced, but “the old API is just better."
    • Dirk-Jan [14:33]: “I think [legacy API] will keep working for a while, and if not, we'll switch over to Microsoft Graph, I guess. But I like the old API more because there's more information in there.”

• Microsoft Bug Bounty & Attitude Shift ([16:17])

  • Recounts Microsoft’s shift from "by design" dismissals to now taking these issues seriously, thanks in part to public pressure and their Secure Future initiative.
    • Dirk-Jan [16:35]: “Five years ago...everything was like by design and not a problem. But they're taking things quite a bit more serious now.”

• Community Reaction & Roadtools Utility

  • Dirk is warmly thanked and credited by the pen testing community for giving the field crucial offensive tools for Azure/Entra research.

• Pressure of Fame & Sustained Research ([18:31])

  • Discussion of burnout and the unhealthy “vulnerability treadmill”
    • John Strand [18:31]: “You can get into that treadmill...where they had to find the next big vulnerability. If you're at peace with that, that's awesome.”

• Plug: Outsider Security ([19:09])

  • Dirk's solo consultancy, primarily pen testing and training on Azure/Entra AD.

---

2. Shai Hulud npm Worm & The State of Supply Chain Security

• Overview of the Threat ([20:07])

  • “Shai Hulud” worm spread through npm, exfiltrating GitHub secrets to public repos.
  • Used trufflehog for secret extraction, then published findings to new public GitHub repos and via GitHub Actions for propagation.

• Scope and Impact ([23:46])

  • Spread to hundreds or thousands of npm packages, momentarily affecting high-profile libraries (e.g., CrowdStrike’s npm packages).
  • Exploited the trust and chaos of decentralised npm package updates.

• Detection & Response ([26:08], [31:23])

  • Discussed technical response (delaying updates, locking versions, using monitoring tools like “Chris Knife").
  • Identified difficulties in getting reliable logs due to use of public/private GitHub accounts and repo creation outside of enterprise logging.
  • F [31:23]: “You have to use something like this Chris Knife tool to go look at every single one of your GitHub accounts to see if they’ve posted a shai hulud repo.”

• Supply Chain Anecdotes & Commentary

  • Amused but apprehensive nostalgia over the return of worms—automation seen as both a throwback and a new threat vector.

• Organizational Prevention ([32:55], [38:33])

  • Strong stress on knowing your environment: what packages you use, how often you update, how your dev/account hygiene is structured.
  • Debate between automatic patching (good for security, bad if supply chain tainted) vs. slowing or validating every update (bad if manual, but potentially safer).
    • John Strand [42:11]: "...nothing ever replaces that [traditional security model] like... just understanding on some level how your software development lifecycle works is still a requirement, no matter how many tools you have."

• On Vendor Tools ([39:46], [41:40])

  • Skepticism towards solutions promising to catch everything as it lands; most tools stronger at helping clean up post-incident or catch “yesterday’s attacks."

• Fundamentals & IR Readiness ([48:45])

  • Actionable takeaway: organizations must emphasize fundamental SOC skills—log review, network monitoring, knowing your environment—over silver-bullet solutions.
    • John Strand: "If you understand the blue cards...almost every incident. If you look at play.backdoors and breaches.com... should have documented procedures..."

---

3. Steam Game Supply Chain Attack ([49:27])

• A peripheral but illustrative story: a legitimate Steam game (“Block Blasters”) was later weaponized to run a crypto drainer that stole streamer donations and crypto wallets mid-stream.
• Notably, attackers failed basic OPSEC, easily unmasked due to public Telegram group links embedded in malware.
• General advice: Separate your play machines from real assets; don’t trust any app/game store to keep you safe.
  • A [53:24]: “Don’t put anything trusted on a system that you’re just running random games on.”

---

4. Critical Dependency and Service Outage – Airport Supply Chain Attack ([54:53])

• Multi-country airport check-ins disabled by cyberattack against Muse (airline check-in SaaS), highlighting that supply chain attacks span both code and entire service layers.
• Broader discussion on physical vs. cyber-related travel disruptions and the fog of reporting after an incident.

---

Notable Quotes & Moments

• Dirk-Jan on Cross-Tenant Token Exploitation
  [07:57] “...The token was from a different tenant and I just changed the tenant ID and like this outer unsigned token. Then I changed the user ID to a valid one and I actually got back results. I'm like, no, this can't be happening…”

• On Fundamental Security
  [42:11] John Strand: "You can never replace the traditional security model of understanding your environment and locking it down to the best of your abilities."

• On Pen Testing Tools
  [15:53] A: "As a pen tester, I'm a huge fan. Like, we use RoadTX all the time and roadtools. Like, yeah, we...it's been a critical thing for us and I really appreciate your work on it."

• On Modern IR Realities
  [44:09] A: "...I don't think you need to detect this when it enters the supply chain. I think that's way too over...I think you just need tools...I just want to run this incident in eight hours or less because that's my...I just want to be able to clean it quickly and identify what's infected..."

---

Key Timestamps

• Entra Cross-Tenant Vulnerability Deep Dive
  [04:01] Introduction to Dirk-Jan and CVE
  [06:09]-[08:43] Discovery Process
  [10:42]-[15:12] Impact on Tenants & Roadtools API Choices
  [16:17] Microsoft’s Changing Attitude
  [18:31] Career and “celebrity bug finder” treadmill

• npm Worm Incident
  [20:07] Shai Hulud worm overview
  [23:46] Spread details and CrowdStrike mention
  [31:23] Detection techniques and monitoring
  [38:33] Can you or should you DIY this kind of defense?

• Supply Chain Philosophy and Incident Response Fundamentals
  [41:40], [42:11], [48:45] Sustained main-thread on process and readiness

• Steam Game Crypto Drainer
  [49:27] Details and incident lessons

• Airport Outage – SaaS Supply Chain
  [54:53] Muse SaaS check-in outage / cyberattack discussion

---

Podcast Tone

• Camaraderie & Humor: Frequent asides, jokes about fridges and chicken nuggets, and irreverent banter.
• Technical & Candid: Willingly critical of vendors, Microsoft, and the state of infosec, but practical advice prevails: “know your environment,” “don’t chase silver bullets.”
• Community-Oriented: Shoutouts to contributors, Discord chat references, and actionable tips.

---

Closing Thoughts

This episode offered an unvarnished look at both the excitement and headaches of modern security: landmark vulnerabilities, real-world incident aftermaths, and the difficulties of effective detection in dynamic, interlinked systems. The crew’s consensus: security fundamentals, rapid IR, and community tool-building are still our bedrock, even as the problem space evolves.

---

[Full episode and additional resources at: Black Hills Information Security]

Transcript

[A]

I think we're live. Hello, everyone. Hello, everybody. John, is there anything in that freezer? Got anything in. You got any, like, ice cream or what?

[B]

You want me to give you a tour of the Airbnb?

[A]

No, not the Airbnb. Just the freezer or whatever that is behind you. Maybe it's a kegerator.

[B]

I don't even know. Here we go. Nothing. It's empty. Okay, but this is weird. I didn't expect this. This is the magic of Europe, right? They have a fridge that. The door opens both directions.

[C]

Whoa.

[A]

Wow.

[B]

I know.

[C]

I live in Europe. I've never seen this.

[B]

This is new to me as a European. I've never seen this.

[C]

I need to upgrade my switch.

[B]

So this is. This is the extent of what I did for my shopping. Oat milk and milk and cheese and some yogurt.

[A]

You were like, liquid only if I have to eat solid foods about.

[B]

I. Yeah, I just needed something. So if I wake up in the middle of the night, I can have some granola or something. I don't know. But no, that door on that bridge just freaks me out. And I'm really happy John freaks you out, too, because I never trust it. I was afraid you're gonna be like, dude, everyone does that in Europe.

[C]

No, bridges aren't supposed to open both ways. It's unnatural.

[B]

It's easy to take the whole door off.

[A]

Did you do that accidentally or.

[B]

I. I. You know, it kind of popped it off, and I'm like, look at me, I'm a pen tester. I can fridges now.

[A]

Did you check if that fridge has Bluetooth? No. All right, let's move on.

[C]

No.

[B]

Oh, speaking of which, do we have the news story of Samson? Their fridges, they're gonna start serving up ads randomly at you in the middle of the day. Oh, I'm not surprised, but I don't think I saw that.

[C]

I saw that.

[A]

I can't wait.

[D]

I don't know if it's on our list.

[A]

Yeah, I didn't.

[B]

I didn't add it. I didn't see it.

[E]

You bought this $2,000 fridge. It's got a screen on it that can tell you things, and you can browse the web. And by the way, we're going to serve you ads now.

[B]

Are they using the camera that, like, takes a picture of the. Of the inside of the fridge?

[E]

It might be that model.

[B]

I have that fridge. I do. That's flex. But one of the most terrifying things ever is at Wild West Hacking Fest, we had a bunch of people having dinner at my house, a bunch of speakers and I had Mubix and Egypt and I think Steve, they were all, like, getting access to, like, the command prompt on my fridge, and I had to tell them to please effing stop because that. It's an Android tablet, actually controls the entire fridge. So if they brick it, they would have bricked my fridge.

[A]

I gotta say, John, I'm very disappointed that you bought a fridge. As the owner of a security company, you bought a fridge that has an Android tablet in it. Don't you have an Android pen testing class? Or is that why you bought the fridge?

[B]

Make me feel better that I snip all the traffic off my fridge. It sounds so bad, sniffing my fridge. All right, we need to. We need to.

[A]

All right. Your fridge smells weird. Let's roll the finger. Let's go.

[B]

You're in charge.

[A]

All right. Hello, and welcome to Blackdale's information security. IT. He's talking about news. It's September 22, 2025. It's another celebrity episode. This time we have John Strand. Wait, no, sorry, wrong celebrity. Although I will say John, you know, on a side note, I asked Chat GPT if it knows who you are, and it does not, so you're still safe from the AI overlords.

[B]

Thanks. I feel.

[F]

Yeah.

[A]

Our real celebrity guest. Our real celebrity guest is Dirk Dion. A cloud exploitation expert, I guess, or just hated by Microsoft maybe is your job title. I don't know if they love you or hate you. If I was Microsoft, I would love you.

[C]

I measure my success in, like, engineering time that Microsoft spends on my stuff.

[A]

Yeah, that's that. You. You should ask for that. Like, if they ever want, like, oh, you know, let's have a bug bounty payout or whatever. Just be like, no, I just want to know how much money I've cost you over the years. They should just print you a T shirt with that dollar amount on it every time you submit a new cve. And then you can just have, like, incrementing T shirts. Then you wear them at your talks where it just says, like, $200,000, $400,000. You know, like, it just keeps going up every time. So, yeah, I guess this one, this is a Microsoft CVE. I don't know. Was it a 10? I'm not sure what the severity of the CVE actually was, but it was pretty bad from my perspective. Do you want to run us through just at a high level? Basically, my understanding is for hybrid joined Azure tenants, you found a privilege elevation and then the token, you get back can be used on every tenant, basically.

[C]

Is the long story short, that's the nice TLDR. So they released it as a DPCS9, and then later they changed it to a 10, which I felt marked with. I didn't feel like arguing, like, is this going to be a 9 or a 10?

[B]

Wait, when they first scored it, were you hoping for a 10 and it came back a nine and you were a little disappointed because you felt like you stuck the landing. And then when they finally went back and reevaluated as a 10, where you're like, fine, yes, like, you. You've gotta have some pride on a 10.

[C]

I. I was more like, they said, attack complexity high. And I was like, I don't think it's that high. And then later, apparently they agreed. I don't know how that internal process went. At some point adds up, like, hey, it was updated and then it was.

[B]

Still that it could be turned into a metasploit module because, you know, they think anything beyond running metasploit is. Is complexity high. I guess.

[A]

I don't know what made you, as the researcher, be like, you know what, I'll try this token on other tenants, like, or did you do it on accident? Did you typo something? If. If you, if you want to lie, you can lie.

[C]

No, I did not typo it. We have quite a few security researchers here. And, you know, sometimes, like, when you're researching something, you just get that feeling like, hey, something's off here. Something's not right with this product or protocol. It has to be broken somehow. You can't explain why it is, but somehow you feel it. And then you keep digging and changing stuff just to see if it actually breaks if you keep poking at it. And I guess this was one of these things. So actually the largest part of the research, it's like last year in the summer. And then I had the hybrid parts. That was what I talked about at Blackhat and Defcon about doing hybrid lateral movements. If you start on prem, you exfiltrate certificate from exchange. They use these in the cloud. That was okay. I was hoping for a little more, I guess, when I looked at the protocols, because protocols were kind of broken to me. And I was actually preparing my slides. And usually when I prepare my slides, that's where I try all the variants. I, like, polish up my proof of concepts, try the scripts a few more times. But then I was like, oh, I can also test this for some different apps. I didn't even initially test this for this graph API I was more focused on Exchange and SharePoint. I was like, well, why would the Exchange be able to talk to the graph? And I didn't test it. And then I tested that and it worked. And then I was like, well, let's test a few other things, like, can I do this against different tenants? Because I tested that for SharePoint exchange and it didn't work. It got me all error messages and stuff. So just swapping out do guids. And then suddenly with this one, it actually gave a very weird error message, like the user not found, which makes sense because the user was from a different tenant and it didn't exist to the tenant that I changed it to.

[B]

And at this point I was like.

[C]

Wait, wait, you're saying it's not found? Does it mean that you bought my token was fine? Because it was definitely not. The token was from a different tenant and I just changed the tenant ID and like this outer unsigned token. Then I changed the user ID to a valid one and I actually got back results. I'm like, no, this can't be happening. Because I changed it to my real tenant where I host my email, because I don't put any test users in there, obviously. So I was like, did I add this user there? Did I create some relationship between my desk tenant and my pro tenant? And then I didn't. So I figured out it really worked and I tested it with a few other test tenants I have. And I was like, okay, this actually, like works cross tenant. The access.

[A]

That's amazing. That feeling had to be the weirdest feeling ever.

[B]

Was this all before your. Your black hat Def Count defcon talk? Because you were preparing Talk A and then you stumbled into this. Like, where were you? Like, when you're getting ready to go on stage? Did you know that this was coming down the pipe and you were working with Microsoft to get it fixed? And you're like presenting and you're like, this sucks so bad compared to what I'm going to drop in just a little while. Or were you still fleshing it out by like DEFCON?

[C]

No, I knew it's like 2, 3. I think it was three weeks before the talk that I found it. And I also reported and I knew it was fixed at the moment. I was doing a talk. But yeah, I had a lot of thoughts like, okay, do I change the topic for the blackout talk to this new thing? But I already had tons of content. I had to cut out a lot of slides that I actually wanted to talk about because it just couldn't fit in the schedule. I was like, well, if I just add this as this one extra thing, it's just going to take away from the rest of the talk. So it's like, okay, I'm not going to put it in there. I actually did put a teaser in both the defcon and the Black Hat slide deck, only for those who were there because I didn't post it online because I closed my talk and I said like, okay, my next talk is going to be like the title of the previous talk. But then. So the talk at Black Hat was later movement techniques from On Prem Ad to Entra. And then I changed the slide title and I said, my next talk is going to be that movement from my On Prem Ad to your entrance. That was kind of the hint for this.

[B]

That's pretty much exactly what this is.

[A]

I don't know. I feel like the most common configuration is Hybrid Join. Right? At least from my perspective, in enterprise, that's the most common setup that people use. Does this affect non. Like, does it affect native tenants? I assume?

[C]

Yeah. So I found this in Hybrid Join. In the end, you didn't need the hybrid join because you can also do this without Exchange hybrid. It's just that you need to have a credential on the exchange in your tenants, which Hybrid Join used to do or Hybrid Exchange used to do, I should say, because they changed that. But you can also do that without Hybrid Join and it affected all the tenants, so they didn't need to be Hybrid Join.

[A]

And so. Okay, a couple other technical questions. One question from the audience. Is there is. Is there any indicators of compromise to see if this has been abused in a tenant? So part of your blog says that it doesn't generate logging events. Did Microsoft. I mean, you don't have to share, you know, it's privileged information or whatever. But does Microsoft have any, like, secret logs that they could go and investigate whether it had been abused by threat actors? Or do you have any information about that, like whether that should be something people are concerned with? Or is this just a luckily you caught it before some bad guys did scenario?

[C]

I mean, Microsoft has a lot of secret logs. I know. I mean, I don't think they're secret. It's just very well known that internally they have a lot of telemetry about what's happening. I don't know what kind of logs they have, like what kind of detail. I'm assuming that they looked at, like who was requesting these specific authentication tokens I call actor tokens in the blog. I don't know if they have the detailed logging for the Azure ad graph like the Legacy API where I use this in. But if this was used on your tenant, it depends a bit what the actor did with it. So if they just read information, you won't see any logs because there's no like API level logging yet. For this API they're adding that. I don't know when that will be public. It's in very limited private preview at the moment as far as I know. But if you want to change something then that will result in audit logs. So I can add like a new global admin, but then you'll see like a new user being created, global admin role being assigned and that will leave very specific braces as I also outlined in the, in the blog, that you can detect that it was done like by this impersonation token.

[A]

Right. So the actual token issuance you can't detect but any kind of post exploitation actions with the token you would see just like you would normally. And I'm sure everyone we know has 100% logging enabled in their Microsoft graph and cloud environments and they have those logs going into all their security tools. There's, there's no gaps whatsoever. There's. Right.

[C]

And infinite retention, obviously.

[A]

And infinite retention, of course. Yeah, good point. Yeah. I mean I think the, the only other question I have is like for the, for the Legacy API, do you have like a timer in your house that's like time to the Legacy API being disabled? Like. Cause that's kind of your thing, right? With road tools that uses a Legacy API, did they delay the disablement of that API? Like I guess. What are your thoughts on that API being enabled at this point? Like is it necessary or so I.

[C]

Mean they use it internally. They use it. That's something that I'm pretty sure about. So I really wonder one that deadline hits even if they stop moving it around, I think it's in a few months now, I think it's mostly going to be blocked for customer applications. So if you have a app that you develop that still use this Legacy API, it will definitely break down. But if you're authenticating with a Microsoft app, like one of these Microsoft Project clients like Road Tools does, I think it will keep working for at least quite a while longer. I don't know if these findings in the Legacy API are kind of pushing them to deprecate it faster and to really get it done with. I wouldn't be surprised if they actually have more motivation now to just kill it off based on these Findings.

[A]

And I think it will still keep.

[C]

Working for a while, and if not, we'll switch over to Microsoft Graph, I guess. But I like the old API more because there's more information in there.

[A]

Well, there's less permissions, right? Like the default tokens just scope to user impersonation. It's like, all right, make it everything. You're good to go.

[C]

And for the Graph API, man, it's so much effort to figure out, like, oh, I need all these five tokens to actually query this data, even from a legitimate point of view.

[A]

For sure, yeah. Do you have plans? And I apologize if this is an ignorant question, but are you going to add modern Graph support to Road tools or are you going to stick it with the Legacy API?

[C]

I mean, once the Legacy API stops working, then I'll definitely move forward with the normal Graph API. Actually, there is already a pull request for that. I think I've merged it into a separate branch. I still need to review it and get everything merged in because it also changes the entire database schema and all that. But there is basically a version of Rose Recon that you use the Microsoft Graph, not even written by me. So somebody contributed that. I don't remember the name currently. You can check it out on GitHub and maybe give it a test drive, but it's there and it will be there as soon as it's needed, basically. But until they really kill off the Legacy API, I prefer to just keep using it.

[A]

Yeah, no, that's totally fair. I mean, as a pen tester, I'm a huge fan. Like, we use Rode TX all the time and road tools. Like, yeah, we. It's. It's been a critical thing for us and I really appreciate your work on it.

[C]

Yeah, no problem. Like, really the reactions from everybody from the community have been so positive, everything. So really appreciate that and definitely motivates me to keep going with research.

[B]

Very cool.

[A]

All right, last Microsoft question is, how many other bugs have you submitted to Microsoft that they said, this isn't a real bug. Can you even count?

[C]

Well, I think these days it's less.

[B]

Oh, they're gonna list.

[C]

There's been a change. So five years ago when you did research and you submitted it, then everything was like, by design and not a problem. But they're taking things quite a bit more serious now. Like last year at Blackout, there was a talk about application permissions and hidden permissions in Microsoft apps. And I told them a similar thing in 2019 and they didn't really care. They just said, yeah, this is how it works. But now they actually started removing all of these, restricting them. So they do quite a bit more hardening now and I guess they just improve their stance on security a little bit. Also because of the whole Secure Future initiative that is definitely getting steam. I think so far it's been mostly internally at Microsoft where they made a lot of changes, but we're starting to see that now also applied to the customer facing side. So they are definitely improving their stance on security and less things by design these days.

[A]

Yeah, that's awesome.

[B]

Well, you get to go to sleep. I don't. I have to stay for the rest.

[A]

Yeah. Thank you for all your work. It's awesome. We really appreciate you.

[C]

Yeah, no problem. Thanks for having me on the, on the podcast.

[B]

Congratulations on the 10. And by the way, you're welcome. Because we complained for a year about how there were no tens and then they started creating tens. So I'd like to think that we were a little bit of your team.

[C]

Or you asked them to just put this bug in there so I could find it and could be a 10.

[A]

Yeah.

[B]

That would be like the, like the reverse Easter bunning. Like an Easter bunny in a hoodie. It's like sprinkling vulnerability eggs all over the place, you know?

[A]

Yeah, we'll. We'll be pa. We'll be patiently waiting for your next blog and immediately, you know, getting excited when it's posted.

[C]

I don't think anything is going to be as exciting as this one, but I'm at peace with that.

[B]

Well, and I'm going to say, all joking aside, you know, you can get into that treadmill talking to a lot of people over the years from like Barnaby Jack or Dan Kaminsky when they were still alive. They felt like they constantly had to be on this treadmill where they had to find the next big vulnerability. Had to find the next big vulnerability to find the next vulnerability and. But yeah, if you're at peace with that, that's awesome. It's a much better place to be because the stress can start to crush you if you start looking at everything through that lens. So good on you. If you can say you're okay with that, that's awesome.

[A]

Yeah. And since you're the owner of a pen test company as well, do you want to give a quick plug before you head out?

[C]

I don't know what you want me to shout out, but I do have a. Oh yeah. So the company is called Outsider Security and that's just me, so there's no other people than me. Working there. But I do pen testing, consulting. I don't do red teaming if there's this word team in red team and I don't think you can do that all by yourself. But I do also give a lot of training. So if you want to know more about this weird thing called Entra or Azure AD or something in between, then I can also help it up.

[A]

Nice. Awesome. And you are speaking at all kinds of conferences, giving training at all kinds of conferences, mostly around Europe, is that correct?

[C]

Yes, mostly Europe. Correct.

[A]

Well, thank you so much.

[C]

Yeah, thanks for having me.

[B]

You bet.

[C]

And I'll have a great rest of the show. I'm going to try to.

[A]

Yeah, feel free to stick around if you want. You know, you're whatever, you can stick.

[B]

Around as long as you want. Because there's literally nothing else that's happened in the world of computer security over the past four days.

[C]

I think I saw a very long list of topics.

[A]

Yeah. So yeah, I mean the next thing I think to talk about is the shy hulude, the worm, the, you know, the NPM worm that hit every or not every, but thousands of NPM repos. I mean John, do you want to like give a quick nostalgic rant about worms? Real quick before we.

[B]

I was shocked that they actually like these. I was reading an article and it talked about the Al Shayud worm and it reminded me of. There was a tool that Jason Fossum wrote, I think it was for Blaster, might have even been like Nachi or something else. But whenever you ran the tool it would scan your environment looking for systems that were infected. And if you ran it in your environment and there was no worm systems or compromised computer systems, it would come back and say like something like good day, Moabdeep worm sign negative, no sign of El Shayut. And that when I saw this come up and they were talking about the worm, I was just basically like holy crap, is this like, is this an article from 2004? Because it was a little bit nostalgic with the whole warmification because we usually, we just don't see that type of automation and spreading very much anymore at all. I mean propagation. I mean I think it kind of peaked with conficker with all of the different, with all of the different exploit post exploitation privilege escalation modules that existed.

[A]

So basically to give, to bring everyone up to speed in case you don't, you haven't been following. If you live under a rock, first of all, if you live under a rock, you maybe are safe from this but maybe not. But yeah, basically this is, this is a worm with this, with a Dune theme. That's why we're talking about Dune and Shai Hulud and other, you know, Dune references. But essentially a threat actor published a worm that essentially harvests credentials. And by credentials I mostly mean GitHub secrets, GitHub CI configuration secrets and things like that. Then it uses truffle hog to harvest those, exfiltrates a bunch of data. And the way it exfiltrates the data is pretty brutal because it just creates a public GitHub repo called Shaihalud. So anyone can go and search these up and you can see some GitHub screenshots. Then it also exfiltrates data via GitHub Actions to post basically base64 encoded data publicly. So in all cases it's not sending data to a private command and control server or private threat actor controlled server, it's just posting them to GitHub and then it infects the repos that it can access and then repeats the process. That's the worming part.

[B]

And this doesn't seem like a nation state level adversary. This truly feels like a single hacker that's doing it for the love. Just the fact that it's posting it out on GitHub, I could just see somebody who was working for Russia, Israel or the nsa, they're like, great, good job. So where did you post the data, Bill? I posted it up on GitHub. But you encrypted it, right? No. Yeah, you're going to get fired.

[A]

Yeah, they just wanted an easy submission to everyone's bug bounty program. Hey, I found your secrets. They're on GitHub because I put them there.

[B]

That is one way of doing it. That's called the wrong way of doing it. But no, it managed to spread. But yes, it managed to spread it. Actually, I know that they brought the GitHub repository down. How many did it get up to before it was finally nuked?

[A]

I think it was in the hundreds. Like, I mean it's definitely an actively developing user. Hundreds or thousands of and specifically NPM packages. I think the news article that made the hot headlines more than anything was that it infected some of CrowdStrike's npm libraries that they published, which I'm not entirely sure what the point of these are. Like, who is kept saying that they.

[B]

Weren'T using it in any customer environments directly or something?

[A]

Yeah, I was kind of.

[E]

I heard them mention that it wasn't involved with Falcon specifically. So like it Must be in something else. But they didn't really want to say what.

[A]

I'm not an NPM developer, so I don't really. None of these packages, like, you know, really jump out at me. But obviously the concept here is that NPM is used widely. There was famous supply chain attacks that have affected NPM for years. It's a common target because the supply chain with NPM is particularly messy. Like developers are using NPM packages, like third party NPM packages for very basic functions like align text left or something like that. Like, there's thousands of external dependencies in npm and so it's kind of an easy target for this sort of thing.

[B]

Static Chair said, all I know about NPM is when I install it, it's like 500 gigs of downloads to run. Hello World.

[A]

That, that is, that is totally accurate. So I mean, I guess my question here, and I'm not like a. I wish we had Andrew or some like, expert on, you know, how cloud stuff and supply chains work. But my, my question is, is it normal in an NPM like supply chain to just auto use the latest version of whatever NPM package you're running? Like, is that a normal thing to just auto pull the latest version? It's tricky because on one hand for security updates you would want to do that, but on the other hand, for compatibility, I feel like you're kind of a little bit crazy if you just automatically use the latest version of whatever NPM package you're pulling. I don't know if it's just me, but.

[E]

I'm not an expert on this.

[B]

Hold on. It drops off. Wade just posted a GitHub repository for a tool to help see if you can hit. So that's in our Discord server. We'll get it posted up here, hopefully. There it is right there. Just showed up and they called it Chris Knife, which I think is a great name for it as well.

[A]

Stone, I love the Dune theme.

[B]

Good too. But at any rate, go ahead.

[E]

So what I was seeing was people talking about this and saying when you set up your npm, there is a preference. You can go in and set how long you delay between a new package being released, a new version being released, and when it actually gets incorporated into anything else. And they were like, you should set this for at least 24 hours, because that way you won't even get garbage that comes out and immediately, immediately gets fixed. And you should probably set it for 48 hours so that you have a chance to actually look at it.

[A]

Yeah, I mean, in a Perfect world, you would have it all version locked to the versions you trust, but then you'd have to potentially increment versions manually for like a thousand NPM packages depending on how your code looks. So like, I kind of get it both ways, but that's kind of the.

[B]

Question I've been getting from a lot of CISO type people is, you know, how do we make sure that we don't get hit? And one of the big concerns that I have is like, this whole NPM conversation is now bleeding into like automatic patching, right? And we've talked about this from browsers for the past few years now. Automatic patching is just now built in. And there are some organizations that are having straight up real conversations about we just need to disable automatic patching and not push anything unless we know it's a hundred percent safe. And that scares the hell out of me because that's literally going back to where we were in like 2001, 2002, 2003 time frame where people are like, we're going to wait on the patches and maybe we'll roll them out once a quarter when they're trustworthy. And it seems like anytime like this, ha, something like this happens. Like this thing that happened with npm and CrowdStrike and the automatic update that got pushed via CrowdStrike last year. Two big things from CrowdStrike. It restarts that conversation again where people are like, how are we going to handle the supply chain and the patches that are coming off of it? And I hate, I hate how the conversation starts leading down a dark path of we need to validate everything before we put it into production because, well.

[A]

Okay, so I agree with the perspective, but it's kind of a different scenario. Like, I mean the, the there's, let's say two scenarios. One is a centralized patch screws everything up. Like the CrowdStrike incident from 2024. Right. I think that's one where you can easily just argue like these are limited enough in scope and occurrence that you should just ignore that and keep patching. Right? Like, although I guess the Microsoft admins are probably like seeing, you know, smoke in the distance of like the last time they implied a patch and it broke something. But in general, I think we've moved a little bit past that mindset of like, patches break stuff. And that's all down to the trustworthiness of the people publishing the patches, right? If it's centralized, I agree with that.

[B]

But once again, the conversations that start up and trying to like split that difference becomes Very difficult with people that don't understand. And then it also. And this is different supply chain management or the. What is it? SBoM Security, Bill of materials. How do we know that the products that make up the products that we use are secure is a valid question. But it's one of those things that once you start looking into it, it'll drive you absolutely insane because, you know, literally everything is made of everything else on the Internet. Everything is made of all these different pages. And how do you tie that all together is a good question without any good answer. But there's a lot of snake oil vendors out there that like to sell you a product on that.

[A]

Well, okay, so say they're not. I mean, I'd like to highlight James Randolph's comment in Discord where he says, I'm glad we got this out of the way and NPM will be safe from now on. This could never happen again.

[B]

Problem solved.

[A]

Right? Like so. Yeah, yeah, that's. That's a joke. So.

[F]

So this is the second big NPM thing that's happened in the last month. I think three weeks. Three weeks, Right. This is gonna. I think this is gonna start being a regular site. So whatever IR process you did for this one, you better write it down and get ready to do it again.

[A]

Yeah, it's decentralized, right?

[F]

It was decentralized.

[A]

If one developer gets fished, it's all like the whole supply chain's at risk. Right. That's basically the long story short, especially.

[F]

With this one, because it was a worm and it was propagating. Right. Like, honestly, to detect this was pretty trivial just because it dropped a JSON script right off the bat.

[A]

Right?

[F]

Boom, you got a. You can detect it. The thing was, though, is it was spreading to so many libraries so quickly that we had to constantly keep checking if we had those libraries.

[A]

Right.

[F]

I think the last time.

[A]

Monitor. Yeah.

[B]

Yeah.

[F]

So. Well, first of all, you would monitor for those libraries just to make sure. But the thing is, you have to look for those libraries in both dev endpoints as well as in production to make sure, like you said, no one has any of those libraries that are updating. So things to put in place are, don't have a. Libraries that don't update daily or Update once every 24 hours or at least know your schedule so you can actually protect against it. Right. This in particular, what I thought was kind of interesting is because, like, they do exfil via a public GitHub repo. You're not going to have logs for that. All these githubs if you, if your company has say a GitHub account, but it's like the community version instead of like an enterprise version, they have access to make a public repo with their GitHub account and they don't, you won't have logs for that at all. So you have to use something account. Yeah, yeah.

[B]

Network traffic analysis at that point if you're lucky.

[F]

Right. Or you have to use something like this Chris Knife tool to go look at every single one of your GitHub accounts to see if they've posted a shy hulude repo.

[A]

Yes. That's the other thing like depending on how your hygiene works. And we definitely have, you know, we do lots of GitHub scanning for our pen test customers. Like different companies use different policies. Some people just use people's personal GitHub accounts that are added to organizations. Right. Which is like harder to detect because then what do you do? Keep a list of all your developers usernames on hand?

[F]

Well, you can, yeah, you, well you have that list if they have access to your actual organization. You have a list of every single user and you can pull it out in a CSV and then pretty much what I did. Right. And check every single one versus that saihil using that Chris knife.

[A]

Yep.

[F]

So hopefully you don't have several GitHub accounts or several organizations that you have to check.

[A]

Yeah.

[F]

One interesting part I saw was that no one mentioned building detections for truffle hog anywhere in any of these blog posts. Like if you look for ioc, it.

[A]

Does more good than harm in my opinion. Right.

[F]

Yeah, well I think that would. That's the low hanging fruit. That's one of the low hanging fruits that's you're going to see again because it's a tool that's used pretty regularly. But it was just something like the one, one outbound connection you would see was an outbound connection to truffle hogs GitHub and that that would have been a clear indicator of compromise.

[A]

Yeah. And also fun fact for those doing, if you're doing threat hunting on this, you can Pull from the GitHub API what users have committed from what emails. And so you can pull like a list of GitHub users associated with your organization even if you don't centrally use a GitHub organization because a lot of, a lot of companies probably don't. They just use private GitHub repos and people you know publish to them individually and it's not centrally tracked or managed but you can see what commits were made from a corporate email. So that's kind of a threat hunting tick tip, I guess.

[F]

Can you tell me this isn't that I worked this incident that last week or not?

[A]

Yeah, right. I mean, man. I mean it's good tips for sure.

[E]

The other thing I'd say as far as going let's hold off on everything is like there's a real critical difference between a supply chain problem because we use Chrome and Chrome has a bug. Everybody pushed the new Chrome and our upstream source that happens to be free code has some new things and we're getting the equivalent of dev pushing everything to prod immediately. There's a reason not to run on nightly builds for absolutely everything. There's a reason not to instantly load all of the stuff the second someone published it. That's different because they're different kinds of software. It's a different layer of the process. Am I dealing with code? Am I dealing with some binaries?

[F]

Yeah, but move fast, break, right? Move fast, fail often. That, that. I'm just saying that's a, that's a dev term.

[E]

That's a. I know it is not my enough times.

[B]

That's one of the things I love about it is if people have that type of attitude these days, it's great because the hackers are going to show us the error of our ways. Right. You know, we can, we can argue about it one way or the other. If people like, absolutely. There are companies out there that are move fast, break things, cutting edge, be there and they're going to get burned, they're going to get cut, that's just going to happen. You just kind of got to let that happen naturally. Somebody asked how would ACH deal with this worm? Will we be able to detect the outgoing connections to GitHub and we'd be able to look up, see the DNS lookups as well. That's probably how we would actually do it. And then I didn't know what the beacon interval once it dropped the worm on the system was. Yes.

[A]

There's no beacon.

[F]

There's no beacon. It's a little bit weird. So it uses GitHub API, creates that repo and then uses actually what's like the GitHub automated actions built in.

[A]

GitHub actions?

[F]

Yeah, that's literally what it's called. It uses that.

[B]

And it's also weird because it's not like persistent C2, it's like it does what it's supposed to do and then it moves on. Right?

[A]

Correct. A.C. hunter is not going to do anything for you on this. I mean, you're going to have to threat hunt your GitHub organization. Like you can't. I mean, you can't have an alert.

[B]

That says a user ac hunter absolutely could help you identify who's using GitHub in your organization.

[A]

Yes, that's true, but they can't differentiate between malicious activity and it's not just AC Hunter. No network threat hunting tool is going to be able to differentiate between malicious activity on GitHub or legitimate activity on GitHub. And if your organization uses GitHub, there's going to be an incredible amount of volume when it comes to that.

[B]

Well, I mean, even just posting to like a private versus a public repo, you're not going to be able to find that with network hunting. I mean, I feel like it's a valid concern that a dev just accidentally pushes something to a public repo instead of private as well. I mean that.

[A]

Yes.

[B]

That gets into the quote unquote false positiveness of it. Right. So if you try to write a detect that's at that level, you're going to be smoked every time someone does something in GitHub and then you're going to be chasing your tail, which is. I haven't had anybody say this yet, but you just know that there's organizations like we're just going to ban everybody from going to GitHub. That seems like bad place.

[A]

Well, you really should if you don't use GitHub. I mean, if you don't use GitHub, don't allow people to go to GitHub. Like if you use.

[B]

I think that that's easy to say for some smaller organizations, but once you start getting above 1500 people, you're going to have somebody that's using GitHub fairly regular. Right?

[F]

Yeah, I can see it done with using the URL.

[A]

Right.

[F]

And because the organization will be in the URL and if you say can use GitHub only using this and then.

[B]

Star after the web application firewall at.

[F]

That point, yeah, it could work. You could build some detections based on that as well. But it's still at the end of the day, like hopefully. Yeah, like you said, it's going to cause a bunch of false positives. Maybe just move to GitLab, who knows? Easy, easy.

[A]

Yeah, I mean, I don't know that many orgs that I don't, I don't think there's a lot of orgs that are using GitHub for like large software development setups. Like, I mean, I think it's more like for the medium and small companies. Like, if you're a company that is, you know, heavily dependent on your own code, you probably have internal repos, right? Like, it's more if you're a company publishing packages or publishing things for people to use intentionally. Like, you know, A.C. hunter Community Edition as a great example. Like, if you're intentionally publishing code to GitHub, then you're gonna have to use GitHub. But not everyone's doing that. Right? So depends on the use case, I guess. My other question, like, to John or others, Wade, are we at the point where we're just. You have to have something constantly scanning your, like, environment for, like, supply chain attack? Like, is this. Is this a core service in security now or is it still something you can diy? Like, is it. Is the problem too big to address without, like, a complex product?

[B]

Wade, do you want to go first on this one?

[F]

Yeah. I don't think you can DIY this. Right. The first thing I thought, to protect yourself, of course, is going to be like, artifactory, right? Or something that's scanning. Like, I know there's a couple of tools out there that will scan any package, make sure it's malicious before it gets back to your dev, which also could take some time, right?

[B]

No, it's not. Shit. I got excited there for a second.

[F]

Wait, there's. There's one particular tool that's actually a community member that I don't want to, like, sound like. Sound like I'm shrilling for them. But the funny part is I had a phone call with them literally the Monday of this attack about their tool. And then that Tuesday they sent me, like, that night they sent me a blog post. They're like, it looks like you're going to be working ir. And I'm like, great. Like that. That was true.

[B]

Yeah.

[F]

The other way I would just. It was. What was it? God. It's called OS Osprey, but it's spelled differently now. I'm going to.

[A]

I mean, there's a ton of tools in this category. I mean. Yeah, yeah. Like Aikido. Aikido, however you say this is one of the blog people. Lots of people blogged about it. Every company that has any security offering. But I mean, I think. I don't know, I kind of agree with you, Wade, I guess. John, what's your thought? Do you think this is small enough that you can address this?

[B]

Traditionally, I think that these products are really, really good at chasing things that have already happened. Right. I just think that it's a very complicated thing. Right. Once again, I think of that XKCD comic about the Internet and how all the technology that we're using today is stacked on all of this previous technology. And it shows a little bit of code that is essential and it's maintained by one lonely person in their basement, Nebraska or something like that. I think that that pretty much sums up the Internet. Right? You know, whenever we're talking about like the XZ packages, like the hell, how many of these products would have been able to detect that? There, that's the, that's the XKC in discord right there. We've got it. It's right there.

[A]

I mean, I was going to say that's definitely a modified version.

[E]

That's new.

[B]

That's new.

[A]

That's a modified version.

[B]

But, but I think that a lot of these, I think that it's, we're moving in the right direction. I think these products will mature a lot more. And once again, I'm sure I'm gonna have vendor reach out to me and like we're gonna show you a demo that'll change your mind forever, which almost never happens. But once again, I think that these products are really good at detecting yesterday's facts. And that's better than nothing, right? And over time it starts to get good. Right? But when we're looking at a lot of these different like attacks that have come out over the past few years, I don't know, it's rare to come across a product that's like, yep. That would have totally detected that particular supply chain attack that came out. And once again, I, I look at the one, that's the XY vulnerability where they dropped it into the encryption libraries and they spent years building up and contributing to that project, getting trusted by that project, got code commit rights and then they put their code in and it wasn't like overtly malicious. I, it's just, how in the hell do you detect that?

[A]

Oh, I, I think so. I basically, I have two opinions on this. One being that you can never replace the traditional security model of understanding your environment and locking it down to the best of your abilities. Like, nothing ever replaces that. Like as an example, asking your developers the questions like, how often do our packages pull from npm? How often do we commit new code? Is it nightly, is it daily, is it weekly? Like, just understanding on some level how your software development lifecycle works is still a requirement, no matter how many tools you have.

[B]

See, and that's, that's the thing, you know, once again, shilling that's the thing where I think AC Hunter can like do that and anything that's running C by the way, if you're running Zeek or you're pulling logs and telemetry off the edge of your environment, going into those logs and doing a look at seeing, you know, what do we have for NPM packages, who's using it, how is it being used, how many people are using GitHub? Not necessarily from the perspective of saying we got to shut this shit down, but just going into the awareness aspect of it just so you have an idea of how big the problem is or isn't in your organization. And I think that a lot of organizations from a threat on perspective, they're so far away from that place that there's a lot of knee jerk reactions that become problematic where the best thing you can do is go on a fact finding mission.

[F]

To start I will say the, the community has been really good about responding to these both times right? Or like the past three times we've seen besides the X Y one I haven't like has there been one one like an infection like this that has stayed for a while, right?

[B]

Has there like hasn't stayed but a long time ago there was Linux Linux bit of Linux code that was pushed where if you set up the kernel options wclone and W all together it automatically elevated your privileges to root. And initially they thought that that was a like a mistake because it was permissions became equal root instead of equal equal route. So instead of a check it was an assignment. And I think that that one, they, that one damn near made it into the Linux kernel. That was a really close one. There was also TCP dump a long, long, long time ago had a vulnerability that was a backdoor that was pushed into it for a short period of time as well. So we've seen similar things like this over time. The only other thing I would say like ah damn, I was going to say some of the quote unquote back doors that we've seen in various devices or hard coded passwords but they're not even like that. So generally we don't see a lot of these. But then that gets into the question of what are we not seeing right.

[A]

I would argue my take on this is I don't think you need to detect this when it enters the supply chain. I think that's way too over like I don't think that's really feasible. I think you just need tools. I think you just need tool. Yeah if I, if I'm a CISO or you know, even just like a regular security person. I'm not trying to detect this with some fancy tool as it enters the supply chain. I just want to run this incident in eight hours or less because that's my like, you know, if, if code enters XZ upstream and then finally ended up in my system, I just want to be able to clean it quickly and identify what's infected because I think that's really the only thing you can expect. Like you can't audit every line of code that runs in an enterprise environment, but being able to figure out, okay, what has this version of XZ installed, what operating systems are running it, where is it in my environment and then go and clean it out is the only thing that's going to keep you safe from these kinds of attacks. Um, and like in this case, I don't think the impact is actually that big from this. A bunch of code was published, a bunch of secrets will have to be rolled. A lot of work, you know, people, people like Wade's time will be wasted and spent. But I don't think it's going to lead to like another crowdstrike type incident or something because someone found it and then worked their way back. Right.

[B]

I, so I disagree with that last point. I think the biggest thing about this isn't necessarily the technical attributes of it. Even though Wade has been living in the technical attributes of it. I think it's more. It was embarrassing, right, for a lot of organizations. And the fact that this particular attack was automated is equally embarrassing. And I think that that's interesting to me for a number of reasons because either a, this is just going to be a one off or like hearkening back to the past. It's like, oh, worms, blasts from the past or attackers. Look at this. Not necessarily this exact attack methodology for npm, but looking at it from the context of what were the steps that the attacker had automated, I think that that's the scary thing is that this type of automation can still happen in 2025 in a way that we really haven't seen very much in the way of automation for a very, very, very long time.

[A]

Well, it's a feature. That's what CICD does. It automates actions. Yeah, I mean, maybe there's some kind of containerization or like there is some secrets, hygiene stuff that could save you here. Right? Like truffle hog is going to scan the local system and find stuff. If the local system is like a super clean Docker image with no secrets exposed, it's just going to exit.

[C]

Right.

[A]

It's not going to find anything vulnerable. So I mean there is a hygiene element to it. You know, keep your stuff in environment variables or use password encryption or you know like there's, there's things you can do to limit your impact from this. But also monitoring is always a discussion, right? Like there's an argument to be made that you should be monitoring anytime a new GitHub repo is created on an enterprise account and have like an informational severity alert sent to the SOC to investigate it or things like that. Like this is just like Wade said, get ready to run this incident again. It's going to happen again whether it's NPM apartment Yum, whatever it is, there's going to be a supply chain infection in the future. We saw it was starting with Solar Winds maybe was the first big one and it's just continued every couple months since then. So it's not new.

[B]

Well, and the other thing that you talked about is back to the fundamentals, right. You know, whenever we came up with backdoors and breaches as a game, one of the things that we really tried to focus on is what were the fundamentals and almost every single incident. If you understand the blue cards, if you look at play.backdoors and breaches.com, you can play it online for free. But the blue cards, as far as preparation is there's firewall log review, network security monitoring. So when we're talking about what you were talking about Corey, where it's, you're going to be doing some network threat hunting that is in that game for a reason and you should be able to look at all of those blue cards and every single one of them should have documented procedures in your organization. You should be able to new you should be no, should be able to know how to do server analysis, endpoint analysis on Windows, endpoint analysis on Linux, system SIM log analysis, like all of that stuff should be part of your standard operating procedures for your SOC. Because I agree with you 110%. Doing a full line by line analysis of everything in your environment's not going to happen. But being able to react to it appropriately is something that you can do.

[F]

Yeah, it's like making a custom, making a custom backdoors and breaches deck for your organization will be pretty fun.

[A]

Yeah, that's a really good idea. Identify your like, get the developers in the room and run this threat as a backdoors and breaches exercise. And you'll realize really quickly if you start asking questions like okay, what NPM packages do we even use? Are any of our packages affected? That question might take two hours to answer. That's too long. You know what I mean? Like, you gotta speed that up.

[B]

Exactly. Shameless Plug. Shameless Plug for free website play.backdoors.com It's a podcast.

[A]

The whole point of it is plugging. It is.

[B]

Absolutely.

[F]

So you're in San Diego, you just need to ask me and I have free decks.

[A]

Yeah. While we're on the topic of supply chain, let's talk about this Steam game infection thing real quick. Because this is another example of like House, you know, it's kind of more going the info stealer, like home user add on. Like, hopefully no one in your enterprise environment is running Steam games on their computer. You know, fingers crossed. But basically the. The scenario here is a game called Block Blasters, which is a 2D platformer, was on Steam for two months between July 30 and September 21. It was fine, like it was a Safe Game until August 30th and after which a crypto drainer component was added to the game. Basically this is, you know, unfortunately a famous streamer named Rivo Plavnics I Rasta Land tv. I'm sorry, I don't know that streamer. But basically they were doing a live stream and all the donations from that live stream were put into a crypto wallet. The crypto wallet was drained, unfortunately. And yeah, basically it's it. I mean, this is like a drainer, right? Supposedly the.

[D]

But the OPSEC fail and. Oh yeah, being able to identify the individual that did this. So that's where I was. What's flowing from. Like the automated attack like this just seems like it was it vibe coding of malware because you have the batch file that has everything in clear text. So even like VX Underground was like, guys, why is. Why does the video game contain a batch file that looks for your browser credentials and crypto wallets all in plain text? And then it's sending this out.

[A]

That's the anti cheat. Don't worry about it.

[D]

Yeah, it was like, that's the anti cheat. So they send this out with, you know, the telegram. They send the stolen data to a telegram channel that the scammers made. The OSINT nerds connected to that telegram channel using the credentials that were made, which not sure if that's OSINT to connect to something with credentials, but still. And then inside the channel, it's like it's a public telegram channel. It's like, here's the Here are the scammers, here's their telegram IDs. Let's cross check those. Oh we found their, their Instagram. Their Instagram gives a link tree. Their link tree has everything including their YouTube account, their PayPal account, their pic account, their Twitter account, etc. So it's just, it was really this whole, here's how they, they find these things. And yeah they even had, they did see on like virus total to where it's like one of the, one of the scammers that was in the Telegram channel was going to virus total and flagging the ransomware files as safe. Like they go like hey, these things are safe, these files are safe, don't worry about it. Like this is, this is all cool. I'm going to like vote this file as good as pay no attention to what the virus scan virus towards.

[A]

I mean I've said this for years but like on whatever system you're just gaming on, don't use any accounts or legitimate like don't, don't do it. Like don't put your crypto wallets on a Windows system that you're just installing random games on. Because as much as I do think Steam has a duty here, this is like telling people not to click fishes like yes, don't install games that have small numbers of reviews or whatever. But. And also you could argue, well Steam, how are you allowing games that just have batch files in them that are clearly like on first pass, pretty malicious. But like the reality is this kind of thing is never going to go away. We've seen this in app stores for how many? For 10 years plus like people can get malware into app stores. It's possible. So like it's one of those things like just isolate your gaming system, containerize it, whatever you want to do. I don't know exactly what the safest way to do this is, but don't put anything trusted on a system that you're just running random games on.

[F]

Right. You've heard it here first. Corey does not support indie games, so don't download any small rated video games.

[D]

Well, I do feel that's going to continue to be a problem as we've seen with info stealers. Is it as we said at the beginning of the story, it's not like people are playing Steam games on a work machine, but people are doing work and DevOps on a Steam machine. Like we saw that with LastPass and the Plex server. They're going, we're doing dev stuff on a Plex server because it has power and it doesn't have all those security controls. It lets me do what I need to get done. So I'm going to run everything on that. And hey, it just happened to have Steam have all these other things that are ATT and CK vectors that aren't seen by your, the IR team.

[A]

Yeah, but it's tough. I mean it's, it's one of those things like we can't have nice things anymore. We can just say that like, you know, don't, don't trust your Steam games. This isn't the first time and it won't be the last. And honestly, even if you only play AAA games, like indie games aside, if you only play AAA games, there's an argument to be made those are basically backdoors on your computer at this point. AAA games require kernel level, anti cheat UEFI backdoors and all kinds of garbage. Like it's just gotten to that point. Literally.

[B]

Yeah, that's the big thing is I don't know how you differentiate something with malware and all the games with anti cheat kernel level root kits on them.

[A]

Sorry. Exactly. Like it's cheating. Yeah, exactly. So, okay, John, you have an article you want to cover?

[B]

Yeah, Want to cover the airport stuff because that's kind of spooky. And also Jaguar is still down. I think I pronounced it. Yeah, we talked about Jaguar is still down. There's now conversations about bailouts from the UK government and Jaguar. But also it looks like most of the airports are running a lot better except for Brussels. I think they were still running into problems today. But you know, and then we also had Dallas went down and a lot of people were wondering is this completely unrelated or did Dallas go down because of like something similar? No, they definitely said it's a cyber attack. This is, I don't know, like there's not a lot of information coming out on what the details are of the compromise with the company that processes online check in.

[A]

It's called Muse. Has anyone ever heard of it?

[B]

Yeah, I've not heard of it. But this also. Okay, but this also goes into the supply chain thing, right? Supply chain isn't just packages. Supply chain is also entire services from other companies that are supporting you as well. Like I'm willing to bet for some of these airlines they're like, who? But you know, it was something that was running something critical for a lot of these airlines and they've been down and then time traveling Nerd herder, there's a lot of talk is like, is this a test run? You know don't know. We have some people saying it wasn't a cyber attack. Most of the news is it is, in fact a cyber attack. If it's not a cyber attack, that it's like some form of tech debt and it definitely impacts availability as well. But I don't know, it's. It's kind of spooky. And I think we're just going to watch the space for a little bit longer and see if we can get a little bit more news on what it is and what it isn't.

[A]

So, okay, if you're a passenger on one of these planes, would you rather be grounded because the door is about to fall off or because there was a cyber attack? Like, pick. Choose your own adventure.

[B]

I'm going to choose the door. No, no, because if the door. Look, look, look. This is easy. If they ground the plane because the door was about to fall off, the system work. They found the door problem before we went into the air. If this is a cyber attack that hit it, then at that particular situation, the system is not working. I didn't say the door fell off. They found that the door was going to fall off. That means system of inspections is doing what it's supposed to do. And it worked.

[F]

This is why I only use carry on. Never, never check luggage.

[B]

Did they find that the door.

[E]

It'll go right out the door with you.

[B]

Right?

[A]

Yes, they did, Andy. That's exactly what happened, is the door fell off on one flight and they were like, hold on. All the doors might fall off.

[B]

Somebody check all these doors quick.

[E]

Yep, yeah, Yep, Exactly.

[B]

If you check. They checked the doors, there were a bunch of them that were missing multiple screws, which, once again. So what you're saying, John, is the system worked.

[C]

Thanks, Bowie.

[B]

I just don't want to be on the point.

[E]

Not for that first one.

[B]

Not exactly. Not for that first one. I don't want that. Look, I don't think you'll understand. Boeing system, it's very complicated. We're gonna rip up Boeing now. There goes it. There goes the torque wrench.

[A]

Torque wrenches are really hard to use. All right, John, plug us. Let's get out of here.

[B]

All right.

[A]

We are a company. We do things. One of those things is training. Check out our course on digital forensics and incident response.

[B]

We do that as a service, too.

[A]

Oh, it turns out that's not what we're talking about. We do that as a service at Black Hills Information Security. Digital forensics and incident response.

[B]

That's a good. We suck it.

[C]

Oh, look, we got.

[F]

You guys got.

[A]

No one wants an active sock.

[B]

You want the anti sock, right? Is that.

[A]

Yeah, we also do pen testing. We do things and stuff. Also, I'm for the record. Hold on. I'm counting the first article we talked about before we even started the show as a chicken article.

[B]

Was there a chicken on that? What?

[A]

The fridge. Chicken goes in the fridge.

[E]

Sure, sure.

[A]

I'm just saying. I'm counting it. If I get. If I get an ad on my fridge, it better be for chicken. That's all I'm saying. Better be like, yes. It better be like, as soon as.

[B]

I get an ad on my fridge for chicken, I will record it and send it to y'.

[A]

All. So can we do a malvertizing campaign? But it just says, watch the Black Hills infosec podcast. You're out of chicken.

[B]

We can try. I actually. I actually know we might be able to do that.

[A]

And then, you know, it just says, we see you like chicken nuggets. You should join the black somehow.

[B]

In fact, something at CrowdStrike, and it's going to show up at airports all over the world.

[A]

The CEO of CrowdStrike is angrily tweeting, why does it tell me to watch.

[B]

This when I run out of chicken nuggets? Sell people chicken. Who are these people?

[A]

I. I would never hire bis because they actually.

[B]

Some kind of.

[A]

They actually invaded my privacy by saying I purchased eggs and chicken products.

[B]

Dare they say I support poultry? All right, thank you.

[A]

I'm gonna get on Samsung. Bye. Bye. Thanks, everyone. Sa.