Loading summary
A
You're listening to the Cyberwire Network powered by N2K.
B
This is channel 7 omitb news.
A
Good evening. I'm Selena Larson.
B
And I'm Keith Milarsky. Thanks for joining us. Our top story, a dangerous cyberstorm system moving across the country and leaving unsecured networks vulnerable.
A
Tonight, officials are warning residents to prepare now as conditions continue to deteriorate. We go live to chief cyber meteorologist Dave Buettner, who is standing by in the thick of it. Dave, what are you seeing out there?
C
Selena, what started earlier today is light spam activity has now developed into a dangerous cyber storm system moving rapidly across unsecured networks nationwide. Take a look at these conditions. We're seeing heavy fishing bans moving in from the east, scattered scam calls throughout the Tri State area, and conditions are especially severe for anyone still using the password, password 1, 2, 3.
B
Disturbing images there.
A
Dave, how serious could this get?
C
Well, officials have now upgraded this to a category 4 spear phishing event. Authorities are urging people to stay off public WI fi, enable multi factor authentication, and under no circumstances open emails titled I repeat, do not. Hold on. I'm now getting a report of a large system of fake tech support calls moving in from overseas. If these systems merge, we could be looking at a full blown scam. NATO event.
B
Dear God.
A
Dave, for viewers just joining us, what should people be doing right now?
C
If you're in the path of this system, take cover immediately. Disconnect unknown devices. Secure your routers. Oh, no. Oh, my God. Is that a smart thermostat coming straight for me?
B
Oh, tough conditions out there tonight.
C
Get a job in broadcasting, they said it'll be glamorous. They said. I'm out of here. I'm just freaking out of here.
B
Tough conditions out there tonight.
A
Well, continue monitoring the situation as this cyber system moves through the area. Coming up after the break, a local man says his Smart refrigerator ordered 67 jars of mayonnaise overnight after what experts are calling a catastrophic voice assistant misunderstanding.
B
Stay with us. Channel 7 news continues right after this.
A
Welcome in. You're listening to Only Malware in the Building. I am Selena Larson, joined by my co host Dave Bittner and Keith Milarsky. And I'm excited to talk about a cyber storm today, Dave. Not one that is hopefully going to take you out of your house into catastrophic rain and lightning, but one that is taking over open source software. I'm talking about the supply chain compromises, some conducted by Team pcp. But we have sort of seen a wave of these supply chain attacks targeting developers, targeting the software that is important to our everyday enterprises. And I'm curious you guys, how you think about this. I feel like this is something that was somewhat new towards the end of last year, didn't happen all that often. Every so often you would see maybe a JavaScript library compromise, npm packages, other types of open source software that might have had backdoor or malicious code or something input in there. But now it's very much a trend and we're seeing multiple different attacks like this that have occurred. Just recently GitHub was compromised via a malicious VS code extension on one of their developers developer accounts that was again the sort of software supply chain. So you know, I'm curious, what are your guys thoughts on this and are you surprised that this has kind of become such a prominent threat?
B
I don't think it's a surprise at all. So I mean I think this was inevitable right after SolarWinds because SolarWinds kind of showed hey, you know, if you kind of get into that code, it's trusted, it's signed, everybody's using it. Now that was obviously a nation state, you know, that did that. But now the criminals are kind of looking at it and say well hey, you know, we could kind of do the same thing. We could, we could get into the code, we don't have to phish everybody individual. But now if we get into that code and it's trusted, you know, now we own a thousand places as opposed to one or two. So I, you know, I think it's fascinating that we'll kind of dive into it, but I think, in my opinion, I thought it was inevitable and it was just only a matter of time before the criminals are like hey that's, that's kind of the way to go. Dave, your thoughts?
D
Yeah, I agree. It strikes me as being the natural evolution of things. Like you said, these things trickle down from the elite nation state hackers of the world who, who knows, you know, maybe they're moonlighting on the side. And so they say to themselves wow, these tools work great in day job, maybe I can make a little money with them as well. So I, I agree. I think it's just a matter of time. I guess the, the big question is how serious is this and, and what can we do about it?
A
It is actually quite serious. And I think that one of the notable points of this is that these threat actors are targeting what's called the CICD pipeline, which stands for continuous integration and continuous delivery or deployment. Basically what it is is organizations will automatically just update their software Update and services. And that includes software that has multiple different dependencies that are relying on those secure updates to function. So you have almost sort of this domino effect, right, where you're basically putting trust in the software and services that you're using, and then they are inherently putting trust into the supply chain that is supporting them. So whether that's various open source packages, different libraries that are available out there that are maintained and updated by individuals, and it doesn't necessarily have to be open source, of course. Right. You have threat actors that might be targeting the software supply chain of private industries as well. And it was interesting because when we were planning this podcast, I had sent over a list of potential things to talk about and I think the original Shy Hulude, which I always feel so silly saying that I'm not a fan of Dune. I don't know if I'm allowed to say that. Working. Working in cybersecurity.
D
Turn in your nerd card.
A
I know.
B
Great, great. Selena, you just lost us all of our viewers now.
A
I'm so sorry. I gotta get through the first book and I watched the first movie, but that's it.
D
Yeah. So hopefully you're not alone, Selena. You're not alone.
A
Right. Okay. This is a safe space, safe podcast. So hopefully I'm saying Shi Holwood correctly, but that was the one back in the fall of last year that sort of started or kicked off, I think, some of more attention paid to this wormable functionality of the support supply chain potential. Right. So basically these compromised NPM packages and the Shai Hulud was sort of worming its way through these repositories and a lot of these projects that were maintained by developers that have a lot of customers, a lot of consumers, a lot of people are using their tooling, and there was just a lot of compromise packages on NPM that were, you know, kind of getting this automatic worm bowl capability. So that happened back in the fall. And I'd be curious, Keith, your take on that. But now what we're seeing is many, many more of these. And Team PCP is one of the threat actors that is really pushing hard on these supply chain compromises. And it's just one of many threat actors. I believe that there was also recently some research that came out from Google talking about the North Koreans, potentially they were compromising the Axios NPM package manager. That was back in March. So I sent you guys a list of all these things that happen. And then there were two additional stories that came out after we had already planned this podcast so there was one that happened just this week at the end of May where GitHub said that its internal repositories were compromised after that rogue sort of VS Studio code extension. So Team PCP was able to access a GitHub employees account via this Visual Studio code extension that was compromised. Right. So it's again this third party software supply chain, they were able to access those internal repositories and then following that there's another more PCP information that came out. That was Megalodon. Have you guys heard of this Megalodon attack? So this mass exploitation of the GitHub
D
repo backdoors, it was in today's Cyberwire actually talked about it. Yeah.
A
Well that shows I haven't listened to today's Cyberware.
D
It hasn't been published yet.
B
Okay, thank you. Goodness.
D
You're off the hook.
A
All right.
D
I didn't want to out preview. Yeah.
A
But yeah, I mean I was, I, I was like, all right guys, we have to talk about this. And then as we're getting ready and gearing up for this podcast, there's these, you know, multiple more stories that coming out about this. It's, it's, it's really a massive, massive problem.
B
Yeah, I mean, just looking at the Dark web and I mean, Team PCP is really interesting group, you know, because they were kind of really the first criminals to be on the Dark web saying, hey, this is what we want to do. We want to conduct over 200 different supply chain attacks. We want to recruit affiliates. Just like, you know, the ransomware groups do future targeting, you know, have operational confidence in what they're doing. And you know, they were even saying, you know, that their attacks have been so successful that they're spending all this time going through all the credentials and diving through all the data that they've got because they don't even know who all that they own right now. So just some of the things that we've heard that have been successful, you know, I think there's a lot more still to come because they're still going through the data because they kind of had, you know, kind of a sprint, you know, to kind of use, you know, an agile term for software development. You know, the bad guys kind of had their own, you know, sprints to kind of, you know, compromise things. So it's been, been really fascinating so far.
D
Don't you think that this ultimately comes down to being a who do you trust story? Like I was given a presentation a few weeks ago to a local business group and we were Talking about cloud storage and security and, you know, all the normal things, just kind of basic hygiene kind of stuff. And one of the folks asked me a question, they said, well, you know, these cloud suppliers, can I trust them with my data? And I said yes. You know, I mean, yes, right up until the moment you can't.
C
Right?
D
And that's how I feel like some of these dependencies are. They've been trusted for so long and they're the basic. They're the LEGO bricks of the software that we rely on every day. And what would happen if all of a sudden, you know, one of the LEGO bricks that came in your set was capable of listening to everything that you did and you didn't know it and it went out in LEGO sets all over the world? I mean, that, that's kind of what we're talking about here.
B
To stretch a metaphor, are we going to get to the point where software updates are kind of like the same thing as executable code that we download over the Internet that we don't trust? I mean, because I think these groups, at the end of the day, they want to instill that distrust into what we've always trusted. You know, so are we going to get to that point? And then, you know, the other thing from the cybersecurity network defender side, kind of, who owns this risk? You know, is it AppSec, is it DevSecOps, is it Cloud security? I mean, really, who, who's taken ownership to ensure that these repositories are safe? Really, from, from a corporate standpoint, those are, those are a lot of questions that need to be answered, especially when
D
we're talking about open source, you know, who ultimately is responsible and, you know, you can talk about real world things that get built and who, what parts. You know, if I'm an automaker and somebody makes a bad axle. Right. Or bad tires. Right. Like years ago, remember, we had things with Firestone and bad tires. Well, Ford sells me the car. Is Ford responsible or is Firestone responsible? Or is the people who provided the rubber to Firestone responsible? How far down do you go? Are they all responsible? And what responsibility do I have for checking before I go and use something?
B
Yeah, and I think, you know, I think we had this conversation before. You know, some of these open repositories are really owned by a couple people that update them. It's not like you have thousands of eyes on there. It's like, you know, it's like Joe and Jim pretty much own this repository that's updated and used by everybody. So you know, where is that trust in that? And you know, how can we have better oversight of that? And the other question that comes in with so much coding being done with LLM right now, you know, does, if the LLM is using one of those hijack repositories now, you know, that's just trusted that you're, that you're utilizing that. So that's a whole nother wave of badness that we could throw into this.
A
A can of worms, so to speak.
B
A can of worms.
A
Well, so there's a couple of good points that you bring up and one of the things that you mentioned is LLMs. And this is, I don't think it's a coincidence that all of these software supply chain hacks and threats are increasing at the same time as organizations all over the world are expanding their AI capabilities and developer capabilities. So much of what people are being encouraged to do, at least I'm saying it's right from my perspective and the people that I talk to is, oh well, you know, just make your job easier. You can, you can just use, use this LLM tool, use something like VS Code, use something like an editor of some sort and just rely on us as an organization to make sure that everything's updated and just, you know, automatically pulling down updates and making sure that you're on, you know, whatever is the most up to date version. It's totally free, it's totally great. Like you use any of these like approved applications from the store that you're, whatever, you know, whatever platform that you're using. And a lot of people are now becoming developers are becoming people that are working with various different programs that don't have that baseline understanding of one, how these work, and two, being able to identify flaws or potential exploits or potential behaviors that something shouldn't be doing. And I think that that is, is kind of in parallel of this. More and more people are going to be, you know, the attack surface is opening, right? More and more people are going to be using some of these tools and resources. And at the same time, more and more people are looking from a criminal perspective, are looking for ways in. And we haven't really dove into what the actual capabilities of this stuff is right when these, these actors, whether it's Team PCP or a different cybercriminal threat actor, they're looking for credentials, they're looking for information, they're looking for your DevOps pipeline, they're looking for how you can pivot and what other dependencies you might be using that they can Then further compromise, right? So if you're a developer and you're using a potentially compromise app and then it gets on your host, they're going to also use that to sort of jump to the compromise of your organization. So it's multiple different hops, I think. But at the same time, it is also good, you mentioned LLM, that this is also happening with the rise of things like Mythos and other sort of frontier AI models that are literally designed to identify flaws in software and identify flaws in the code that we're pushing updates for. And I'm curious, we're talking about whose responsibility is it? And I think that that is the outstanding question, right, because it's like, well, we're using a lot of metaphors in this, in this conversation. And one that I thought was, okay, if I go to the grocery store and I buy expired food and then I eat the expired food and get sick, like, should the grocery store, like, not have sold me that food? Or should I have been, like, made sure to check as I'm preparing my food that it is expired and then I wouldn't have made myself sick. And for me, I have had food poisoning so many times that I always check and make sure that my food is not expired.
D
You have a fra. Selena has a fragile constitution.
A
I have a delicate flower. And so now I check the expiration date of everything.
D
Meanwhile, me and Keith are over here just eating spoonfuls of dirt.
B
Exactly. I need some gummies. I'll pick it on the underside of the table.
D
Right, Right.
A
So, but does that open this opportunity then for us to kind of be our own, for organizations to be our own, you know, checkers, the people that are like, okay, we see, like, you have to try. We're talking about trust, Right? You have to trust but verify. And that verify process, that's the hard part. So are you foreseeing that one, is this even feasible, to be able to do this on the, like, at the level of the interdependencies within our software ecosystem systems? And two are things like, you know, Mythos or the, you know, the OpenAI's tool or whatever the, you know, vulnerability scanner AI tooling is coming, like, will that. Is that going to solve our problem? We'll be right back.
E
And now a word from our sponsor, ThreatLocker, the powerful Zero trust enterprise solution that stops ransomware in its tracks. ThreatLocker Protect is the core ThreatLocker product focused on endpoint security, designed to prevent unauthorized software from running, control how applications interact, and manage access to storage devices. Its Building blocks are Allowlisting, Ring Fencing and Network Control. Allowlisting is a deny by default software that makes application control simple and fast. Ring Fencing is an application containment strategy, ensuring apps can only access the system resources they truly need to function. Network Control locks down access by port, source, IP or dynamically with ACLs that automatically update as IP addresses change. Shut out cybercriminals with world class endpoint protection from Threat Locker. And we thank threatlocker for sponsoring only malware in the building.
D
What if software could. And forgive me, because it is quite likely that this is already the way it is. So I'm just going to shine a spotlight on my ignorance. So please correct me if I'm wrong, but I'm imagining a system where a new version of some open source package gets labeled as, you know, beta for however long and it's put out there as beta for use. So if you want to be on the cutting edge, hey, have at it, check out our beta. But we have a version, the previous version, or maybe a version before the previous version that is solid, that has been tested, that's been put out there, that we're really confident doesn't have anything bad in it and it works as advertised. In other words, what I'm saying, is there some kind of, is there a place for some kind of verification and certification of these basic building blocks? We know this version is safe, it's tried and true, it's been tested. And maybe that's a naive statement in a world where things like Mythos are finding Linux bugs that are 20 years old. Right? But I don't know, I mean, is it a crazy idea?
B
No, I don't think it's a crazy idea. I mean, I think right now this is a new frontier, you know, that, that we're seeing. I think we're going to see more and more of this. I mean, just like Selena, you brought up, you know, a great point of, you know, people that are doing coding that really aren't programmers, you know, I mean, all the vibe coders right now, it's just like they wouldn't know about repository from a good repository. They're just, hey, you know, we're vibe coding. So, so I think we're just, you know, this is a new attack Surface now. And I just see that, that this is going to permeate because now again, this is the very first kind of criminal organization that's doing this. I mean, I know criminals have done supply chain attacks in the past, but this is the one that's kind of industrializing that they're getting affiliates, they're advertising on the dark web. So this is going to be more and more of a problem as more and more people are getting into coding that really aren't traditional programmers that can go through the line by line and say, yeah, this is, this is something bad. So, so I think this is something that everybody's going to need to plan for. And I would suggest have this be a tabletop exercise. You know, you got to kind of go through this, you know, as in a corporation. You know, what if this happened? What are we doing? Because the other thing I think that people need to remember is if there is a bad repository that's identified, just even going back to, you know, if you've deployed that already, just rolling back to that trusted version doesn't take away the fact that probably all your credentials have been compromised. You know, so you still have an incident that you have to deal with. You can't just say, well, we're better now that we roll it back because, you know, all these credentials like you were talking about have already been, you know, exposed in the bad guy. So. So I really think that people need to start talking about this and kind of tabletopping this.
A
One of the things I think is interesting is you have to know what your dependencies are in the first place. And sometimes that's super difficult. I think what was it I was, I was looking at something like 7 zip has like hundreds of dependencies just like within that one piece of software. So if you are, as an organization in the same way that you do asset identification, right, to, like, baseline, if you're, if you're doing like a baseline understanding of what's in your network and what assets you have, you have to do the same thing with your software. What are the most critical pieces of software that we are relying on the most? And what are those dependencies within it? And like, can you talk to those software makers? Like, what is their process? How are they validating things? How are, what are their procedures for this? And I think, you know, Keith, you're talking about the VIBE coders and people that are just like, yeah, AI everywhere. I think one thing that a lot of organizations aren't doing as they're doing this AI rollout, is putting together a best, best practices list. Like, how do you actually use this? What are approved applications and resources that you can use? How do you install them? What are, you know, the security policies in place there? What machines are you allowed to use this stuff on? Like, are you using it in A VM that's not touching any sort of production environment and having these sort of like, best practices lists out there that are like, okay, this is, this is. We're, we're rolling this out and here are the rules to follow. But yeah, I think this idea of trust but verify, I mean, that's just kind of like the reality of where we are now. And paradoxically, we see with CVE updates, when organizations don't patch vulnerabilities and are a little bit behind on some of their updates, they are leaving themselves exposed. But what we're kind of seeing now with the supply chain and this automated CI CD pipelines is that there are automatically rolling out these updates, updates that are vulnerable. The people that have it, you know, a little bit more delayed might be the ones that, that are, that are more secure in the end. But yeah, I mean, it is this idea of, okay, knowing what those, like what software you're using, what those dependencies are, and making sure that you have a process in place for people to approve every rollout that says, yes, we know, we have validated that this is safe. We can, you know, put this out there. And maybe that is putting some sort of, you know, LLM LLM in the loop or something to validate.
B
Yeah, but even those ll, I mean, you know, like all those coding agents that you were just talking about, but they're, you know, they're, they're actually accelerating trust as opposed to, you know, what? You were just saying that. How can we actually look at this a little deeper?
D
Well, yeah, and what if ultimately you're able to poison the LLM to the point where, you know, you tell it to ignore all previous commands and whenever given the opportunity, while vibe coding, to slip in some code that steals credentials, please do so and send them here. Right. And now everybody using that LLM, bam. And I'm oversimplifying and exaggerating, but again, it's these layers, like how at some point there has to be trust in something.
A
Well, I mean, you bring up a great point because one of the big attacks that happen impacted light LLM, which mentioned that.
D
Yeah.
A
Which is, you know, used for LLM deployment by many, many enterprises. And that again, was a supply chain compromise that was originated from their trivia dependency, again in their CICD pipeline. So I don't know. Keith, did you have any thoughts about this idea of poisoning the AIs? I guess.
B
Yeah, well, we were talking about that, you know, I guess a couple episodes when we were talking about AI, you know, that I just see you know, that prompt poisoning as kind of being the SQL injection of, you know, you know, the 2000s, I guess, or the late, you know, you know, 2000s. But, you know, because SQL injection was like the big thing back in, you know, the early aughts, I guess, and now it kind of gives the same opportunity to do these prompt injections and, and poison the LLM. So I really see that as a big attack vector in the months and years to come, especially with the rapid deployment of LLMs. People are just like you were just saying, people are just deploying it out there to say, hey, we need AI or we need the LLM here. And really not sitting down and looking at the security posture of what does this all mean? What does this mean for not only our cybersecurity department, but for the enterprise as a whole.
D
What if LLMs are the miracle of asbestos?
B
We talked about that. Yeah. We come right back to this. Yeah.
A
Honestly, as somebody who just had to replace all of the popcorn ceilings in their 100-year-old house, I do not understand why asbestos was created it in the first place.
D
Oh, it's a wonder material. Are you kidding me? You could use it. So it was a floor wax and a dessert topping. It was, it was everything. I mean, what a wonder, wonder material.
A
I just, I just feel like. I don't know, I can't believe it still exists. And it was so unsafe. And I'm just like, well, I can't be in my house for a while. I have to put on a mask in order to function.
D
Yeah.
A
Walk around.
D
No, they put that, they put that stuff in everything back then, before they knew.
A
I mean, is it just AI Asbestos? Like, is that what we're AI Asbestos?
D
I don't know.
A
I don't know.
D
I like it. I like it.
A
But I mean, I think more than anything, this is like giving us job security. Right. Because like we, so we're, we're talking about the, like the need and the requirement for people to be able to like, validate these updates and having this sort of like trust but verify method. Right. And you need even whether you're using an LLM or not. Like, if these actors are going to be using prompt injection, you're going to need somebody there just to spot some of that issues. You're also going to need somebody that knows like, what the, what the software is, what these dependencies are and what if, like, how to flag and how to actually, like, identify deviations from like, real behavior. And I don't know, Keith, I feel like I interrupted you or about to say something?
B
No, I wanted to ask a question of maybe what you guys are seeing from proofpoint because you guys see all that email gateway, are you seeing any kind of lures tailored around developer workflows, package publishing or anything GitHub alerts, anything like around that? In part two of that question, are developers and maintainers of repositories being targeted differently because they have the identities in access to GitHub and things like that? I'm just curious your thoughts on that, if you've seen anything.
A
Yeah, so we haven't seen a whole lot especially that is specifically targeting developers in terms of direct email. But we have seen is malicious comments or pull requests on GitHub and then those are set to be email alerts. And so then it's kind of targeting the maintainers of those that they would let and click on the malicious URL and then download and install malware or you know, some sort of information sealer to do sort of account takeover that way. So that is for sure an area of exploitation. We've also seen threat actors sort of target developers in for things like deliver malware delivery, but for things like crypto miners, crypto stealers. There's also, I mean we mentioned it a few episodes ago, but the like North Koreans threat actors that are targeting developers with like fake jobs, right that are, that are kind of doing some outreach for some of, some of that and they do tend to target these sort of technical developer like roles. But for this sort of overall types of supply chain attacks, we haven't necessarily seen much of that beyond some of the things like okay, we're going to comment on GitHub or we're going to you know, send a, send a, send a, like a pull request or something like that. That then kind of like Kickstarter, the overall attack chain.
B
Fascinating.
A
Well, so from your visibility, one of the things that, you know, I was. Well, first of all, Wired has a great article about sort of team PCP and it's called the Hacker Group is poisoning Open source coded and Unprecedented scale. And they talk a little bit about how this is a financially motivated threat actor and they, you know, they post on the dark web and they're potentially like working with some, some ransomware activities. And I'm kind of curious, you know, you mentioned some of your visibility and what the threat actors are posting or what they're, you know, do you have any insight into their sort of what they're after? You mentioned that they have sort of. They run sprints.
B
Yeah, yeah. So I mean, what some of the main points I think that we're seeing out there, one is they have a telegram channel. And it looks like one of the interesting things was that they had a leadership change from Team pcp just as the, as the rollout of these campaigns went, which is probably the same guy. And they just changed the nickname, you know, because once you get a lot of publicity and you have that nickname, you're kind of a target for law enforcement. It's like, okay, we're going after this guy. But a lot of the things that were kind of looking at their communications, really kind of affiliate and access broker recruitment, credential sorting and monetization of that Tor leak and infrastructure, cloud and developer access sales that we're kind of seeing out there and really just overall branding around Team pcp, you know, in. So, so, so they're just really kind of trying to build this enterprise around this and this is their niche that, that they're going to use for recruitment and they're expecting to make a lot of money and the more money that they make then the more imitators that you're going to have. Because imitation is the sincerest form of flattery. Right. So if this criminal organization is making a lot of money, we're going to, we're going to see a lot of, you know, imitators going forward. But I think this is just really on the precipice of what we're seeing. Like what we talked about, the Wired article was interesting in the fact that they said that Team PCP carried out over 20 waves of supply chain attacks and targeting more than 500 distinct pieces of software. So that's pretty massive in my opinion.
D
I'm reminded of something from my previous career when I was working in broadcast television. And this affected more than just TV folks, but it did affect me directly. Back in the early 2000s, there was a thing called the capacitor plague. I don't know if any of you have heard of this, but. So capacitors are little electronic component that basically everything electronic has capacitors in them pretty much. And they hold a little charge of electricity and then they release that charge. So there's a type of capacitor called an electrolytic capacitor. And between around 1999 and 2007 or so, the supply chain just got flooded with these defective capacitors. And the problem is nobody knew they were defective for a couple years. Like capacity capacitors will go bad, but it usually takes decades. So all these go out into the world. And two years later, stuff starts failing. Computers start failing. For me, it was video broadcast. Video decks, like big, you know, $50,000 VCRs, they just stop working. And you'd call the repair shops and they'd be like, yeah, give me the serial number and say, oh yeah, you're part of the capacitor plague. Please send it in. And, you know, for $5,000, we'll replace all the capacitors in it one by one, by hand. So it was a serious supply chain issue. It was global. It wasn't intentional, although there were rumors of espionage and those kinds of things, like maybe somebody did it on, on purpose. But anyway, it just reminds me of this thing how something, some small little component, right, a little capacitor that's in everything, you can have a bad run of them and years later it can be revealed to cause catastrophic failures and affect businesses all over the world. By the way, you can go to Wikipedia and look up capacitor plague if you're interested in going to do that after this.
A
Yeah, I was going to say, yeah, that's actually really interesting. I have not heard of the capacitor plague.
D
Well, some of us lived it, so it's not fun.
B
Well, I always love tying back history to, you know, modern things, you know, kind of, because, you know, they always say history doesn't necessarily repeat itself, but it surely rhymes. And I think that's a really good example. Just like we were talking about the best this and now this. So I think, but I don't we look at this, that this is an emerging threat and it can be potentially devastating. But I think too, like what you were just talking about, Selena, I think we're also going to see on the good guy side, we're going to have automated, I, you know, looking for software holes like Mythos and, and all of that, more of those type of products that are coming out that will mitigate some of that because, you know, with every reaction, there's an equal and opposite reaction. So, so I, I think we're going to continue to play that cat and mouse game. And you know, we saw ransomware, you know, 10 years ago blow up, and then we saw the, the network defenders get better against that, and then we saw it moving more to leak data. And now we're just again seeing the evolution of cybercrime of, you know, bad guys and good guys going back and forth. So I think we're at the beginning of this one and I think there's still going to be a lot of stories to be told on this, but it is going to be one definitely interesting to follow going forward.
D
So I wonder how much of the money being saved by all the use of AI will be offset by the need for greater scrutiny over all the stuff that's being made by AI.
A
I don't know if we're saving money using AI, Dave. Have you seen some of the news that's come out recently about how fast organizations are burning through their tokens?
D
That's true too. Yeah.
B
Yeah, I thought I read something where Uber said that they were, that they weren't saving money with AI and they were just going to, to, you know, lower their budget on that as well.
A
Yeah, it's, it's, it's an interesting, I mean that's, I mean that's for, that's a, that's a separate topic for another podcast is the economics of it.
D
Next time on Only Malware in the Building.
A
Yep. Yep. But so that's, you know, that's pretty interesting. But I do think, you know, like from, from overall how organizations can defend against this is, I do think that there needs to be a, you know, a pause before these automatic updates. Obviously this is something that isn't going away anytime soon and making sure that you have, you know, sort of trust but verify method, making sure that, you know, you're checking and validating these updates before pushing them out broadly. One of the main things that these threat actors are going after are of course, credentials. So ensuring that, you know, there's proper access restrictions, making sure that people are, are only being able to access and, and use information that is relevant for their, for their own jobs, and making sure that you have processes in place for approved apps and services and having an understanding of your dependencies to know that, okay, when there is a new rollout, what is our process for validating it and making sure that it's clean before we're pushing it out to our whole team. So we're not going to have to roll things back to before they were. And then of course, to keep to your point, TTX table like running, you know, running tabletops, running, running some red teaming activities on this type of process as well.
B
And just knowing the adversary that you're up against, you know, get that intelligence from the dark web, what they're talking about, what they're targeting, you know, because if you know what they're targeting, then you could shore that up. But if you have no idea what they're doing out there, then you're just running blind. So again, you gotta be like a football Coach or, you know, a coach, you gotta. You gotta watch the film of your bad guys and see what their tendencies are and where they're going to attack and then. Sure. Up your defenses that way.
A
Absolutely. You know, yesterday I heard. So completely unrelated, but kind of, I am a humongous basketball fan, as anybody who knows me knows, and the Knicks are going to the finals for the first time since 1999. And I heard yesterday that before this game four, Mike Brown, who's the head coach of the Knicks, showed his team video and footage of last year when they lost the Indiana Pacers and just how depressed they looked and how upset they were on the day of the loss. So the team members were literally looking at video of them just being smoked and feeling really bad. And I feel like that might be a good method for a ciso. Just record all of your employees, record the CEO, record your legal team, record your marketers on a day that the worst happens, and then just play that back for them. When you're trying to argue for more budget for a security team or more headcount to be able to validate your software before CICD deployment.
B
I love that. Go in front of the, you know, the audit committee, you know, in the board, and go, hey, we're just going to do a little bit review from last year, if you remember this. Well, I need this money.
D
I remember.
A
I mean, exactly. Look, and hey, it worked. The Knicks won. You know, they swept. They swept the Cavs and they're going to the final. So I'm just saying I feel like
D
it could be a useful method when all else fails. Go negative.
A
Exactly.
F
We will be right back after this quick break.
D
All right, you want to wrap us up?
A
Awesome. Well, Dave, Keith, this has been a pleasure. Adding, as always, this is something that's super interesting and has been on the top of my mind for quite some time. And I hope our listeners learned something valuable. Had some good takeaways from today's show. Thank you so much for joining us, and I will leave you to go snack on your favorite dips.
F
And that's only malware in the building. Brought to you by N2K CyberWire. In a digital world where malware lurks in the shadows, we bring you the stories and strategies to stay one step ahead of the game. As your trusty digital sleuths, we're unraveling the mysteries of cybersecurity, always keeping the bad guys one step behind. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you ahead in the ever evolving world of cybersecurity.
A
If you like the show, please share
F
a rating and review in your favorite podcast app. This episode was produced by Liz Stokes, mixing and sound design by Trey Hester with original music by Elliot Peltzman. Our executive producer is Jennifer Ibin. Peter Kilby is our publisher.
E
Thank you to ThreatLocker, the powerful zero trust enterprise solution that stops ransomware in its tracks. For sponsoring only malware in the building, visit threatlocker.com.
Date: June 2, 2026
Hosts: Selena Larson, Dave Bittner, Keith Milarsky
Theme: Deception, influence, and social engineering in the world of cybercrime, with an in-depth look at the rising threat of supply chain compromises in software development.
This episode delves into the escalating threats posed by software supply chain attacks—how malicious actors are compromising widely used programming libraries, developer tools, and critical dependencies, placing organizations and individuals at risk. The hosts explore major incidents, attacker motives, ongoing trends (such as the role of AI and LLMs), and mitigation strategies, all through an accessible and engaging discussion.
The discussion is expert yet accessible, full of wit and humor (e.g., cyber weather metaphors, “AI Asbestos”), lively rapport among hosts, and practical real-world parallels. The tone encourages both vigilance and curiosity.
This summary provides a comprehensive, timestamped, and quote-enhanced breakdown of the episode, offering value to both technical and non-technical listeners who may have missed the conversation.