Speaker 0: Going live. Woo hoo.

Speaker 1: We are live.

Speaker 0: We're live, Yasmin. Yep. Welcome to preshow.

Speaker 2: How much do you think like, how much internal debate do you think there was for adding the sad face to the Microsoft blue screen? Like, do you think they fought about that, or do you think someone just rolled that out?

Speaker 0: No. That was that shit just rolled. Really? I p if they if they went anywhere near PR illegal, they're like, woah.

Speaker 1: Woah. Woah. Woah. That sad face goes way back to, like, 95.

Speaker 2: That really didn't I thought they added it in Windows 10 or Windows 8.

Speaker 3: Oh, now it's old. No. It's sad faces

Speaker 2: around that. Yeah.

Speaker 4: Yeah. I saw the proposal for that to, like, for drivers that cause that type of blue screen that it should fetch from a database or company logos and put that logo there love that idea.

Speaker 1: Face. That's cool. That's what the

Speaker 4: world that's what

Speaker 5: the world needs

Speaker 1: right now. Not not love, sweet love, but that. It's, like, this is It's like, this is a particular this blue screen brought to you by CrowdStrike.

Speaker 4: Absolutely. Stop all

Speaker 2: It wasn't added until Windows 8. Positives. Yeah. I I just wanna set the record straight. The sad face did not appear until Windows 8.

Speaker 1: Oh my god. I thought the sad face predated. I I

Speaker 0: I remember I remember, like, XP never having

Speaker 2: XP was just fatal system error. You're just No.

Speaker 0: I'm like, goddamn it. Like, there goes StarCraft.

Speaker 5: Yeah.

Speaker 2: Sad face is new. That's what I'm saying. Who do you think added it? You think they got a big bonus, or was there a big debate about is a sad face admitting guilt? They're probably like,

Speaker 0: we're gonna remove Clippy.

Speaker 5: Too much

Speaker 1: like that.

Speaker 5: We're gonna have this.

Speaker 1: I've actually got a picture of me with the guy who killed Clippy, from Microsoft.

Speaker 2: You mean, Copilot?

Speaker 6: What what an epithet. The guy who killed Clippy. Yeah.

Speaker 2: I see you're trying to make a Chad GPT clone. I'd like to help. Do you need any help?

Speaker 1: Yeah. I don't know. I've gotta find it, but I have a picture with that guy. He was in one of my classes, and he was the deciding, Like, they had a a a vote in a room, and he was the deciding vote. It was 5050, and he was the one to kill it, and he was the one that killed Clippy.

Speaker 0: I put that on my resume.

Speaker 1: Well, we need to get going. Let's bring out a crooked finger. Alright. Here we go. Hello, and welcome to another edition of Black Hills Information Security talking about news.

And I assure you, we truly have some stories this week that don't involve CrowdStrike.

Speaker 2: Let's talk about CrowdStrike. Square.

Speaker 1: We'll get to those stories later.

Speaker 2: Alright. John, John, I will pay you $10 if we don't talk about CrowdStrike.

Speaker 4: Done.

Speaker 0: Just throw up your Venmo. Throw up your Venmo if you want

Speaker 1: So everyone's everyone that works for Black Hills Information Security is like, dude, our boss just got bought off for $10. I think the company I think the company is in trouble here. I think we've got I think we've got some issues. But, no, I mean, so there's been all kinds of weird things. Wasn't there, like, a fake CrowdStrike update manual that actually was, like, how to install malware on your system?

I think we need to start with that, and I need to lose the bet for the $10 because we called it last week when this happened that there was gonna be attacks coming out, you know, using this. And the domains that were registered, it was kind of crazy. So can we bring that story up, or do we have that handy? Yeah. Here we go.

Fake CrowdStrike repair manual pushes info stealer malware. It's like, yeah. We couldn't see that coming.

Speaker 0: And there it is.

Speaker 1: That's the story. Mhmm. Are we per I get the impression we're burnt out on CrowdStrike.

Speaker 2: You take my money, John. You take it. We don't talk about CrowdStrike. I

Speaker 1: mean, let's

Speaker 0: let's let's let's let's

Speaker 5: just talk out. You don't talk.

Speaker 2: Okay. 1 Just

Speaker 4: like the first real fight book.

Speaker 2: Okay. One real thing we have. We have a victim here. Kelly, tell us about your experience. Did you blue screen at any point?

What does that feel like?

Speaker 3: Well, Corey, that's a very personal question.

Speaker 1: Personal question. I think that's an HR infringement.

Speaker 3: I have blue screened. I blue screened at about 3:30 when my caffeine goes bye bye. So I need to re up. But, yes, I was caught in Delta's little CrowdStrike shenanigans, and my flight out of Salt Lake City was canceled. And, I think the issue is really more about Delta customer service than it is necessarily about CrowdStrike.

But I hear your question, and I've got a question for you. That article about fake malware and fake fix manuals, Who do you think those articles are targeted at? Because we already know that there's fake stuff going around. Is that for junior or new sysadmins, or is that for executives? What are those articles?

What are they for?

Speaker 1: Oh, that's interesting. Is this just some type of fear? Because, yeah, that did happen. Right? I mean but,

Speaker 2: because what does that mean for the downstream

Speaker 1: impacts on that? Are people literally gonna be like, don't trust user manuals anymore?

Speaker 2: I think it's just for IT people, and it's an exercise in if you put the cart before the horse and you don't establish a procedure and you just send people off to go try to fix things, it's gonna end badly. You have to have a plan for how IT people are gonna fix things and not just have every individual person googling how to fix CrowdStrike blue screen.

Speaker 1: Yeah. Yeah. Well, okay. Let let me let me back this up. So there was a huge, there was a huge conversation that came out of a mailing list that I am associated with, like, I'm still on from an organization that I'm no longer associated with.

But the but the thread was huge, like like dozens and dozens and dozens of people going back and forth asking whether or not this is a security incident. And the two breakdowns were, yes, this impacts in the CIA triad confidentiality, integrity, and availability. This impacts availability. Then there's a bunch of people who are like, well, we don't treat every single random DOS or failure as a security incident. And then there was questions of whether or not intent was part of a security incident, and it went back and forth.

And there were some really great nuanced conversations around that. So I got a question. Is this in fact a security incident?

Speaker 5: I I know I know the list that you were talking about because I was watching that list, and I think my comments sort of got lost in this in the center of it all. My my question and the way that I look at it is, are all the companies that are affected by it going to be filing with that are public gonna be filing with the SEC per the regulations for a security incident?

Speaker 0: If they if they're

Speaker 5: not if if this is not a security incident, they don't have to.

Speaker 3: Well, if if the

Speaker 0: computer's down, it's not available and you can't hack it. Therefore, it's not a security incident.

Speaker 3: Well but it affects the materiality of an organization's bottom line, and that's what the SEC cares about. So if you ain't got no computer, you ain't got no business in some cases.

Speaker 2: So wait. Has anyone reported it to the SCC at all?

Speaker 5: I've not I've not seen any reports on it, and they're supposed to report within 4 days according to SEC regulations.

Speaker 3: But but there's a national security clause, so they may have exercised that national security clause and said, nope. And so they get a bit of waste time as they work with the FBI. That may be why you're not seeing it yet.

Speaker 5: I this question is is how many of these companies are working with the FBI at this point in time over something that is a known quantity that is not effect it's not directly attacking them.

Speaker 1: Despite fight.

Speaker 5: Yes. It's okay.

Speaker 2: I do it. Here's here's okay. John, first of all, you owe me $10 now. I do. I do.

Basically, the my here's my take. If we take the spirit of what a security incident is, aka an impact to availability, whatever. I think it is a security incident. I think if you take the legal definition of a security incident, then no. And I would say it comes down to, for each company, who handles disaster recovery, IT or security.

Some places it's both, some places it's one or the other. Most companies, the security team's getting involved when x number of systems are blue screening. So I would say it's security incident, but not from a legal perspective. It's, like, kind of a, you know, get out of jail free card, but

Speaker 7: Oh. Does anybody have

Speaker 1: a faulty counter take?

Speaker 2: I don't think companies are gonna report this to the SEC and claim, oh, we're investigating with the FBI. Like, everyone knows what happened. It's not I don't know. Anyway

Speaker 0: I think if you claim if you claim it was that and you do tell the FBI, then it, like, puts you on the naughty list and everyone's like, well, they did have a security incident. Right? Like, then Totally.

Speaker 1: I I I let's get some let's get some let's get some of the hot takes from our listeners as well. See if anybody has a take on this other than just GIFs of cute fat cats fighting. Security incident doesn't require a malicious actor or software, though. Is that true? Satral said.

Speaker 2: You could argue that the kernel driver was malicious. It wasn't intentionally malicious, but it was still malicious. It it doesn't have to be

Speaker 0: an issue. Now we're gonna have to define malicious, though. Yeah. Like, is malicious and intentfully, like, bad, or did it just do something bad on accident? Right.

And as someone who has to write reports every day about, is this malicious or not, this can go deep real quick. Like, is it malicious? Is it suspicious or is it just a benign positive? Right? Like, did it do that?

Speaker 2: I mean, how would you

Speaker 0: describe this as malicious? But but then how does it mean they did it on purpose? You did so then it was

Speaker 2: then how would you what would you classify this as then if it's not malicious?

Speaker 0: I think this is the IP image. I don't think this is a security incident. I will go there.

Speaker 2: I love the shit.

Speaker 5: You guys So it's not malicious. It's I'm trying to remember.

Speaker 2: It's defective. It's defective product.

Speaker 0: Yeah. Yeah. It's a defective product that you did on somebody, though.

Speaker 6: But if you kill somebody, but it isn't you didn't intend to kill them, you can still be prosecuted. I don't I'm not a lawyer.

Speaker 0: For manslaughter. Homicide. It depends.

Speaker 2: It depends. Okay. So

Speaker 6: but still, you've got somebody who's dead. So Under manslaughter.

Speaker 1: There's still

Speaker 2: great Bronwyn. In this

Speaker 6: case, whether CrowdStrike intended it to be malicious or not, millions, millions of people were impacted. So I would say it's still a security incident.

Speaker 2: I think Cyberman Fox is the only one that's

Speaker 4: been running. By the way, links to the actual 8 k filing that, CrowdStrike put in with the SEC. Yeah.

Speaker 3: Oh, Marky. There you go being all serious.

Speaker 4: No. Someone's gonna I'm sorry. I I know I'm I'm I'm mister paperwork over here.

Speaker 5: Job. Here's another here's another way of looking at it, though. For CrowdStrike, it can be a security incident where they're filing their 8 k. For their customers, it might not be a security incident. It's in the IT incident because it's their IT department's dealing with it.

So you could have it both ways.

Speaker 2: Alright.

Speaker 4: But it impacted the AMUS was down. Would you file that incident? Yeah. That's one of the questions.

Speaker 1: Love this is the CIA triad is dumb.

Speaker 2: This thing is

Speaker 1: completely predicated on the fact that we're just going to take what the ISC squared said as at face value, that at face value that, you know, oh, computer security is confidentiality, integrity, and availability. Any impact on any of those different three things is going to be a security incident. And and I love that. But I but I love how all the arguing that we're doing is assuming that. Right?

Like, we're all assuming that that is a starting point, for this entire conversation. So I wanna put this out there I wanna put this out there as a thought for everybody, because I've watched that that thing go back and forth. I do believe insofar as security teams in an incident it is because we're talking about it. Security teams are dealing with it. It is a security problem that we're going to have to deal with.

However, we're gonna actually stick to definitions and terms it's not. It was a security event, not an incident. And there's a difference between these two things. An event is a security occurrence that happens in an organization that absolutely can impact CIA. An incident means that there's some type of malicious act.

There's actually a threat actor associated with that. Now this absolutely can be part of a security incident. In a couple of examples, example number 1, a whole bunch of ransomware groups putting out different user manuals that are using this, trick to get people to use the user manual that install Infostealer logs. And example number 2, domains that are being registered associated with this particular event that are used to spread malware, ransomware, and various attacks. That is a security incident.

This is an event that feeds into those other security incidents. Also, if your organization is seriously thinking about ripping and replacing CrowdStrike because of this, it went from an event to a security incident because at that point, it's going to impact the overall security of the organization. I'm using this because, once again, the organization I used to teach with that shall not be named, this is what we drilled into people's heads, that there is a difference between an event and there is a difference between that and an incident. This is absolutely an incident if your organization is looking to rip and replace. This is absolutely an incident if you are dealing with incoming spear phishing attacks with the domains that are using this event to further their attacks.

So with that type of clarification, it is absolutely an event that can be a security incident when the certain, like, criteria apply or not. Does that help clear thing clear things up at all?

Speaker 2: I think you nailed it. I feel

Speaker 5: that's fair. You scattered right on the front

Speaker 0: of the like that. Was that in a circle that came

Speaker 1: in? Caught that.

Speaker 2: But I still like cyber manslaughter better. Anyway, so

Speaker 3: I'll add one thing.

Speaker 1: Everything I just said, somebody just said, did you just drop into Sam's explaining? It's like the string got pulled in my back. And were you just saying explaining slide 24. It's like slide 24, day 1, the incident handling day. What is the difference between an incident and an event?

So, so

Speaker 3: Let me add

Speaker 1: Go ahead.

Speaker 3: Let me add Go

Speaker 2: ahead, Kelly.

Speaker 3: What you said was was brilliant. I agree with it. So we talk you mentioned we went from an incident, I'm sorry, an event to an incident, and let's not forget the b word. We have most compliance shops will talk about exactly what a breach is. Our legal team will tell us what a breach is.

I don't think the CrowdStrike situation was a breach, but, just to take your analogy one step further, we go from an event to an incident to a possible breach.

Speaker 1: Yes. I would agree with that. I would agree with that because an incident doesn't necessarily mean there was a successful attack. It means that there was an intent to harm the organization, and that intent can be successful or it may be unsuccessful, both of which would be considered to be security incidents. So

Speaker 0: What if the intent wasn't to harm?

Speaker 2: Cyber manslaughter. They already covered that slaughter.

Speaker 1: Are you just effing with me, Wade?

Speaker 4: Like, what?

Speaker 6: Yes.

Speaker 1: Yeah. I I I I I got nothing for you, Wade, on that one. It's like, yeah.

Speaker 7: I don't know.

Speaker 6: Okay. But that tracks because the event triggered a whole bunch of collateral incidents, like the 83 year old man who disappeared for a week, like all of these these other incidents that have have happened that were a direct result of the outage and and the failures of systems around the world.

Speaker 1: Great point. We have 12 RZA said a breach does not mean, no. No. Wait. Hold on.

Things are moving really, really fast.

Speaker 2: Does breach

Speaker 5: not mean data leakage?

Speaker 1: No. And how is CrowdStrike a breach? Once again, we're conflating terms. Right? Let's set up some very clearly defined terms.

An event is an observable occurrence that happens in an organization, like a logon sequence, somebody going to a website. That would be an event. Those events can be basically analyzed, and it can become an incident. Are any of those events potentially malicious? So that mean that goes to, like, somebody's intent to cause harm.

A breach would be when an incident leads to successful compromise of the confidentiality and integrity of an organization dealing with the intent of it. So you have an event, you have an incident, and then you would have a breach. There are 3 completely separate things, and, hopefully, that that explains it. And, by the way, I also wanna go through all of this, like, I don't think we've ever in the history of computing had an event lead to so many different breaches or incidents because, yes, this is absolutely being used by malicious attackers to launch addition attack additionally.

Speaker 3: John, I'd

Speaker 5: like to ask one

Speaker 1: Go ahead, Kelly.

Speaker 3: Just one quick little clarification. Usually, I know, John, I heard you say this leads to a breach. I like to say that, engineers and handlers don't declare a breach. A breach is declared by by the attorneys, or the incident commander. And so once it's declared, it becomes a capital b breach.

Speaker 1: Absolutely. And for the record, Kelly is a 100% correct 101% correct, which is technically not possible, but it is. The other thing is when you're working a potential incident, never ever put the word breach in an email until it has been declared by people who have the authorization to do so. Because if you're working something and then all of a sudden, like, a line analyst says, I think we have a breach. This is a breach.

That is something that can come back to haunt you later on in legal proceedings.

Speaker 0: Did did anybody else wish that just this just happened to Teams so we didn't have to use Teams anymore and everyone moved the Slack? No.

Speaker 2: No. I hate Slack.

Speaker 0: Yeah. Compared to Teams? Oh my god. Alright.

Speaker 2: Teams is Yeah. Teams is inevitable. It's like Thanos.

Speaker 3: Shecky, what were you gonna say?

Speaker 5: Oh, I was just gonna say based on the whole event to incident thing, you're gonna start seeing, if we haven't already, a lot more security events that'll lead around bad patches, bad updates, non actual security functions where company where the threat actors are gonna go ahead and put out more of these bad manuals, bad fix it. I think that's something that's been around, but I think it's gonna be more prominent going forward,

Speaker 1: and we're gonna

Speaker 5: see innocent I hate to use the word innocent, but standard IT breakdowns turning into more security events and incidents going forward from here, and that's something that we're all gonna have to keep an eye on.

Speaker 1: Agreed. And this gets into a question, Mike, that somebody asked. Like, somebody said, John, why do you hate the CIA triad so much? Well, when I was a very young boy, it touched me in very inappropriate ways.

Speaker 5: I hate it because of hurricanes.

Speaker 1: I hate it because of hurricanes, but I I absolutely hate the reason why I hate this stuff is it it lacks nuance. Right? And that's one of the reasons why I love the spirited conversations around these things because it's allowing us to kind of identify what the edges of definitions are, and that's really, in in my world, that's a lot of fun. I think that that's just great. But no.

I I don't really like things like the CIA triad. I think it's a useful tool for people getting started in computer security. But then we get into a situation where people that have been in this industry for a long time become beholden to it, and they try to win arguments based on that alone. And that's one of the concerns that I have is it is a useful tool for getting started, but we start getting into something like this and all of a sudden now it's really, really a nightmare. And the reason why I like this stuff is because I've been in court.

I've seen conversations that have literally started picking apart the terms that we use in computer security, and this is just one recent example. Now people are just ripping on burn Teams to the ground. Okay. That's cool.

Speaker 2: Yeah. We may have started on heat. We may have started a

Speaker 4: we we may have

Speaker 2: a little bit of a holy war.

Speaker 6: Teams, the new dumpster fire.

Speaker 2: Yeah. Yeah. Teams. Chime in with your

Speaker 6: I'm sorry. Dumpster fire,

Speaker 0: folks. O g g. You mean Skype?

Speaker 1: Skype. Uh-huh. Right?

Speaker 3: No. Is there any other news? Yeah.

Speaker 5: I think we need to find

Speaker 6: out that story. Of other news.

Speaker 1: I want to bring one up because we have Michael Allen here. But the the story is multifactor authentication is not enough to protect cloud data. And this is this is, like, really, really, really a concern for me, and this is something I feel like we need to talk a little bit about. So we we do continuous pen testing at BHIS, and one of the kind of, like, the starting, like, guarding, like, guiding north stars of continuous pen testing was to do things that a traditional penetration test cannot do, and that has to do with time and resources and things of that nature. And we kind of ran an engagement, and Corey and Michael, if you guys could Michael, if you wanna talk a little bit about what was the ruse that we used and what was the success associated with that, I think that this feeds into the problems that we run into with cloud computing.

Can you kinda set up a high level? Because we wanna do a full webcast and write up on this, but can you talk a little bit about that with Corey, about what was this recent engagement that we just did and why our continuous pen testing team isn't sleeping very much, the past couple of weeks.

Speaker 7: Yeah. Absolutely. So the the ruse for this, test that we did against our continuous pen testing customers, was that we we picked 20, employees from each company that we targeted, and we went out online, used open source, sources like Fast People Search to find employees' home addresses. So we we found the employees just on LinkedIn. We went and got you know, generated a list of, employees of each organization off of LinkedIn, use their names and cities off of LinkedIn to I who've been identify their addresses.

And then we used an online service that prints, like, postcards and greeting cards. We print up some custom postcards for us that were branded with the company's name, and branded with the Amazon logo or the company's logo, I should say, and then the Amazon logo. And, and the ruse that was printed on the postcards was that the individual employees had each, been nominated for a peer recognition award by someone at work, and, as a result, they were receiving a $50 Amazon gift card. And we looked up the real, head of HR for each of those organizations, and we signed every one of those postcards with the real head of HR for their organization. And there was a QR code on the on the postcard that the employee is supposed to scan with their mobile phone in order to receive the Amazon gift card.

So when they scan that QR code with their mobile phone, there's a little few little instructions at the bottom of this postcard to tell them they're just gonna have to log in with their company email and password, and then they're gonna receive that $50 Amazon gift card. So, this this particular ruse one reason I love this ruse is because it walks completely around a bunch of security controls that most organizations have in place, like endpoint defensive products, endpoint, you know, like web filtering proxies or anything like that that's gonna affect something on an endpoint. It's not gonna affect them scanning something on a mobile phone most of the time, visiting that site on a mobile phone. So by sending them a QR code, we, 1, make sure that they aren't able to, you know, use their security awareness training to take a look at that URL we're sending them to very easily without scanning it first and see where that's going. So we're, you know, avoiding scrutiny.

We're having them open it on a mobile device. We have a high level of certainty they're opening it on a mobile device. We're mailing it to their home address, so we have a high level of certainty that they're gonna be opening it either on their home Wi Fi or on their mobile network, and not at the company network. So all network based controls at the company are out of the game at that point. And then, they're they're visiting our adversary in the middle server is what's happening whenever they scan that QR code.

So when they type in their username and password, they get their usual multifactor prompt. And unless they're using something that is, adversary in the mult adversary in the middle of resistant, like a FIDO 2 type of a multifactor token, we will then capture their session cookie, and we will be able to hijack that session and and access their portal. So in this case, we, targeted the the single sign on portal of all of our customers. So for some, that was Microsoft 365. For some, that was Okta.

For some, it was Duo or ADFS. And we were then able to just get access to everything. We we have access to that single sign on portal, and we we, you know, can access it just like we are the real, employee themself. And in exchange for all of that, this is my favorite part. We give them a real $50 Amazon gift card.

They get that real Amazon gift card. They don't normally get that from a fishing exercise. Most fishing exercises have a, you know, an empty promise of some kind, you know, like, complete this employee survey, and we'll enter you in a drawing for an iPad or some crap. And they never get whatever it is they're promised. So when we give them what they're promised, we close the loop on that, that they are happy.

Now they've received positive reinforcement for, doing those actions that they did for us. And, and we got access to their account. It's a small price to pay for an attacker, $50 to get access to one of the biggest companies, you know, in the country or in the world. And this was a massive success on all of our CPT customers that opted into this. Almost all of our customers did opt in.

Some of them wanted to just take the assumed compromise route and see if we could just do the adversary in the middle of phishing and didn't want us to, like, be so mean to their users. But we've been we've had our hands full for a few weeks now doing post exploitation on so many accounts, and, we've had a lot of lessons learned. It's been a really good experience. So, yeah, multi factor is definitely not enough, it on its own, for sure, especially if they're using weak multi factor tokens. You know, that's that's the first thing right there.

Speaker 1: Let's talk about the MFA for just a second. I I know it did not work against U2FA. Right? But if people were using traditional 2FA, it did. Correct?

Speaker 2: Yeah. So, basically, security keys like Ubiquis or, you know, universal two factor actually cryptographically verify where the credentials are being sent and so they won't we can't capture session tokens when we're capturing in the middle. But everything else, every other MFA factor works. We can capture sessions. And this campaign has led to so many clients just face palming, for so many different reasons.

I'll just give some highlights. Number 1, one company, the day it, got delivered, someone reported it, and they sent an email and text message to the entire company saying this is fraudulent. Do not scan this. And people still did?

Speaker 1: They also they also said report it to the United States postal services.

Speaker 2: Oh, yeah. Don't do that. But basically

Speaker 7: Unfortunately, no one's shown up at my door yet.

Speaker 2: Yeah. We haven't no one has gotten we haven't yeah. We haven't gotten coal fired yet. Will we? Who knows?

But, basically so even though they said not to scan it, people still did it. So security awareness might not always you know, people will give up their accounts for $50. Second of all, we found tons of instances where customers thought they had closed, conditional access gaps and they haven't. Because we're using the exact when we go to take over these sessions, we're using the exact user agent, the exact like, everything is the exact same as it would be on this person's device. And we're discovering that a lot of places are just letting people in as long as they're an iPhone.

Like, that's a thing now. So conditional access needs to be hardened, and there's tools that we've published and other people have published as well that that does for that kind of thing. But the other crazy thing is that users like, one user actually, like, self reported that it happened, changed their password, but then logged in again to see if they could get another gift card. So they, like, compromised their credentials. They compromised their credentials again, and then it screwed up incident response because they looked at the time stamps and said, well, the Caesar changed their password after the attack, so we're just not gonna mess with it.

But we still had access. So it's, like,

Speaker 0: it's like 2 did you give them 2 gift cards?

Speaker 2: No. Alright. No. But then after the after the second time, the gift card didn't work. They didn't change their password again.

It's just kind of fun.

Speaker 1: We've got people asking what was the percent success rate on this.

Speaker 7: Honestly, I don't I don't know. We have not figured up an overall percent rate success across all customers. But, I mean, it's it's pretty much a 100% success as far as, like, on a how many customers do we get some level of access to? Like, one lesson learned from this was if I if I had this kind of campaign to do over again, I would not send 20, postcards per target company. When when I've done this before on

Speaker 5: a red

Speaker 7: team, I only sent out, like, 10. 20 was overkill. I I just wanted to be on the stage. I was afraid to see

Speaker 0: some of

Speaker 7: the 20 per customer is excess.

Speaker 2: Yes. 20 per customer was too many. We should have done, like, 5 that

Speaker 7: I would say like, 5. Yeah.

Speaker 2: Yeah. Just shooting from the hip, I'd say 40%. At least 40%. So at every customer, that's, like, almost 10 sessions that we're trying to triage. Another

Speaker 7: lesson learned for me was pretty funny. So OPSEC lesson learned for me was one of the people who I sent a gift card to I did not know that there was the ability to do this. Whenever a person types in the gift card code into Amazon, even if all they have is that code, they have the ability to click a button and tell the sender thank you. And that actually discloses the sender's, name. And I had sent I purchased these gift cards from my personal Amazon account.

So

Speaker 5: they they

Speaker 7: sent a thank you message back to my personal account, and that like, they had no idea that they that they still like, that user did never figured out that their account was compromised.

Speaker 1: I feel like there's a take backseize coming up shortly.

Speaker 2: Yeah. I mean, if we were APTs, we would be going to jail soon. So let's be glad we're doing this as simulated, but yeah.

Speaker 1: Yep. So I wanna use that. Right? And then let's go back to the article. Multifactor authentication is not enough to protect cloud data.

And if we bring up this particular article, they're talking about Shiny Hunters or Scattered Spider, all of these different things and data leaks and these breaches. And they have some recommendations and I wanted to talk about the recommendations. Let's go down to recommendation 1. Recommendation 1, start with MFA then go beyond. There's a lot of room for growth in the adoption of MFA.

64% of workers, 90% of administrators use MFA. More than 6 out of every 10 organizations have at least one route user user administered without MFA. Businesses need to be a consistent verifiable 100% co founder chief technology officer, Matiga. Company should make MFA enforced and required if using single sign on. Make sure to use, make sure non SSO log on is disabled.

So alright. And then they say turn on additional security measures, such as device or hardware based u 2FA is what they're talking about there. So let's start with this group. Like, I I think that this is I think that this is a good recommendation. Like, if you're gonna do MFA, do it right and turn it on everywhere.

Like, you need to make that be your policy. I don't think there's much disagreement about that. But what are the practical implement implications or, like like, you would run into with trying to do U2FA everywhere?

Speaker 7: There's potentially costs. Like, if they're by having to buy a YubiKey for every employee or something like that. Yep. So one one lesson we learned from the postcard phish also was the importance of well, from our point of view as attackers, I mean, this ruse was pretty convincing. So we actually were able to convince some admins to log in as well.

So at a bare minimum, we would say the admins should be using those, you know, stronger forms of multifactor authentication. Those people should be using passkeys or YubiKeys or something like that along those lines, where maybe the less privileged employees, if an organization has a concern about how much it's gonna cost either in terms of effort or in terms of, you know, actual monetary cost to roll that out to everybody in the organization, then, you know, they could just roll it out to their admins. And that's a really good start as long as they have, you know, like you were saying, multifactor enforced everywhere because that's the very first thing that we do when we get creds. If we didn't weren't able to, capture a session for some reason, is we start using every, tool and every endpoint that we can find to try and authenticate with single factor auth. And sometimes we get in.

We found, 1 or 2 customers where there were some exceptions where we were able to get in with single factor authentication.

Speaker 1: Alright. Next one. Number 2. Use access control lists to limit authorized IP addresses. Organizations should also put access control lists in place restricting where users can access a cloud service or at least enabling reviews of access logs on a daily basis.

And this comes from Jake, another instructor at Anti siphon. This further limits the ability of cyber attackers and it says, really, for pretty much any cloud infrastructure, it's best to practice to restrict what IP addresses folks can come from. If you can't, then access reviews are more important to make sure that people aren't coming from some place you don't expect. And I agree with that, except whenever we're talking about Office 365 and mobile. Right?

Like, whenever we're talking about these cloud services that people are using on their phones, that all of a sudden gets a lot more difficult. And I I'd like to get everyone's take on this. Like, I know where Jake's coming from on this. Like, we really should have especially certain SaaS services. We should have those things locked down from specific locations.

But is that feasible for all of these apps?

Speaker 2: I think not. Number 1, it's absolutely possible to do it in Microsoft 365, and they actually make it not that hard. And it I mean, for Microsoft, not that hard. For anyone else, it's kinda hard, but it it's possible, and it's also what what a lot of what the more secure companies are doing is is they're basically requiring you to enroll with MDM to be able to like, that that's the simple thing. Like, you oh, you wanna get to your email on your phone?

Well, we don't know what IP you're coming from, so you have to be on MDM to get to it. Right? Like, that's the simple bypass. But I think that the recommendation kind of is a little bit confusing about what cloud means. And if we're looking at the breaches, the breaches are, are SaaS products.

Like you said, John, they're not cloud service providers like Amazon or Azure. These are like Snowflake. Right? It's like a cloud service provider that gives you convenient access to things. And I'm not saying logging is impossible, but I'm guessing that every SaaS product out there, getting that to go into your SIM, is a month's long IT or security project.

Like, you can't just connect everything into the SIM and expect it to work perfectly. That's all takes integration. Let alone I mean, the reason this is all Steeler logs. That's all it is. And with the with the like, let's say Snowflake, for example.

The use case that we observed or that has been observed in, there's, like, 200 something companies, so it's this is generalizing, but it's a lot of the times offshore or contractors who have access to it. And while it's not impossible, it's kind of a business limitation to say, alright. We have 10 contractors who are taking a look at our data in Snowflake. We need to get their home IP addresses and, like, it just I I mean, it's like, come on. It's not really super feasible to do that at scale.

If you have a large company that has thousands of contractors logging in to look at their data, that's still cloud. It's still Snowflake cloud, but it's not like Snowflake cloud has an IP white list and you just enable it 1 per contractor. Like, it's just not gonna scale. That's the thing about, like, cloud means more than just AWS, Entre, whatever. It means also, like, Salesforce cloud, Oracle cloud services, Snowflake, you know, your printing service, like Michael said.

Like, all those things are cloud products, and they're not necessarily they don't always have logs, and they don't always have IP whitelisting capabilities.

Speaker 5: So A lot

Speaker 4: of them don't, actually. Yeah. I can speak from experience on the other side of the fence from, you know, when I was back over on on the business side of things, and we actually the company I was with, we actually tried to get a number of SaaS providers to do explicit limitations on where either all of our accounts or certain accounts could actually access services from. And most of them, they're like, no. No.

Yeah. Flat out no. It was there wasn't even negotiation. It was just like, you're crazy. Nobody else wants this.

Yeah. This is not a feature we're implementing just for you.

Speaker 0: Go away. So the one thing with that though is you can enable SSO with some of those features. Right? And then you can log the SSO, and then they you have login, and usually you have location and time and everything like that. So you can get some

Speaker 2: log in. And you should. And actually, like, there's an argument there's 2 arguments to be made. Right? 1 is, like, I will say doing this post x, having customers that have multiple SSOs and multiple different local logins does make our jobs harder, but it also makes things centrally managed.

I will say, like, with the SSOs, those have to be secured too. One thing we do is, like, let's say they have Okta. We'll launch every application from Okta. So, like, we'll go in Okta. We will launch every single app this person has in their Okta Tiles.

Not all those apps we launched. So when we launched it, it does an authentication with Okta and says, okay, here's your token. Sometimes those tokens don't expire. So, like, I still have a session on Oracle Cloud that was launched, like, 2 weeks ago. Because, like, this the Okta session has been invalidated.

The user's credentials have been changed. I can't get in there, but the session that was brokered between the SSO and this target cloud site is still valid. And we see that a lot. We're like, these timeouts have to be configured for every different SaaS product. After launching, you have to go and triage and potentially do, like, 20 or 30 sessions.

Speaker 0: I've found in my experience that the people setting up SSOs for these for, like, particular services usually aren't security people. Right? They're usually Usually, yeah. They're they're it's yeah. It's usually some and they're not thinking about that.

So I have seen that as well a lot.

Speaker 2: Yeah. We've also seen, like, some people in Okta just have infinite time out. Like, you can you can make it so that there's no hard end to an Okta session, and a lot of companies do that because convenience, I guess. I don't know. So, basically, like, SSO is great, but just like anything else, you have to lock it down and monitor it.

So yeah. I mean Alright.

Speaker 1: So that brings in, the number 3. We've kind of touched on some of these, but I wanna get to this. It's maximized visibility into cloud services. Correct me if I'm wrong, but one of the things we did post exploitation is we ran Graph Runner on some of our customers. Right?

Speaker 7: Yeah. We did.

Speaker 1: Yeah. And how many of the customers and for those of you that don't know, we'll put a link to Graph Runner in the chat. But so, Michael, do you wanna talk a little bit about what Graph Runner does? And then could you talk a little bit about how many customers actually detected that activity? Because Graph Runner is not a subtle stealthy tool

Speaker 2: once you There's, like, blogs that are like how to detect Graph Runner.

Speaker 7: Yeah. Yeah. And that's that's not the only tool of its kind that we ran for post exploitation, but, yeah, that's one of the things that we did for post exploitation. After doing some initial things, when we would get into any user's Microsoft tenant account, you know, like in a Microsoft 365 environment, Once we're logged into that user account, we can either we can pull tokens out of the traffic that's going from the browser to the API on the back end if we wanna do it that way. Or if if the, organization's tenant allows it, we can do what's called device code authentication, where we it's it's the same authentication that you use whenever, say, you're you're authenticating your smart TV to Netflix, and it says, visit this URL on your phone or on your tablet and enter this 6 digit or 6 character code.

And then all of a sudden, now your TV has access to your Netflix account, Microsoft 365 and Azure, the Microsoft Graph API supports the exact same thing. So, after obtaining access to user's account, we then do that type of authentication. Since they're already logged in, they're not required to put in their password again. Just like when you're authenticating your smart TV, you're not required to put in your password again if you're already logged in on your tablet browser or your phone's browser or whatever. So at that point, now we can run all kinds of, using the tokens that we've, established with the Microsoft Graph API.

We can now run all kinds of queries against the, the Azure API and Microsoft Graph API and other Microsoft APIs, depending on what type of token we have and what kind of token we refresh to, to do all sorts of things like, in you create a guest account in the organization. That's one of our go to methods for a little bit of persistence. We can enumerate all of the users. We can, enumerate all the groups, look for all sorts of security vulnerabilities in an automated way. So the GraphRunner, John asked what, you know, if it, what it is in general.

It's a generally a post exploitation toolkit for the Microsoft Graph API and other Microsoft APIs, using authentication mechanisms like device code authentication and just token, token based authentication in general. So we can we can also do things like, granting, access to an account with a malicious app that's deployed, through Microsoft. So we we run tools like Graph Runner. We we also ran Azure hound using the exact same type of tokens. We just refresh to the correct token type.

I forget which it was for Azure how that things might be MS Graph token or something. But, yeah, we refresh our token to the type that's required by Azure hound, and Azure Hound just grab grabs all kinds of data about the users or the, the customer's Azure environment. And then that allows us to identify all sorts of, you know, privilege escalation opportunities, other vulnerabilities, resources that are available to us. Everything is very similar to Bloodhound for, active directory environments.

Speaker 1: Alright. So how many of the customers detected us doing those things inside of their cloud infrastructures?

Speaker 2: 0.

Speaker 7: Yeah. None of them.

Speaker 1: There we get into a problem.

Speaker 2: And we have secure customers. I will say it's funny, because the customers who we couldn't fish are probably the ones who would have detected it.

Speaker 5: Yeah.

Speaker 2: The customers the customers with u two f are also the ones who would have detected it, so it's kind of like a selection bias thing, but Yeah.

Speaker 7: Yeah. All of our our CPT customers are generally like, as a whole, they're generally very secure environments. And, you know, we have a lot of trouble getting payloads to execute, on inside these environments because they've got, you know, really strong kind of traditional on the network controls like EDR products and and finely tuned EDR products and things like that. But there's just a lot of lack of visibility and lack of monitoring in those cloud services in a lot of environments right now.

Speaker 1: Yep. I

Speaker 2: think I think a big part of it is just there's a lack of subject matter expert in Yeah. For sure. Securing in securing cloud environments. Like, I genuinely think that most companies have strong endpoint security. People who know, like, endpoint security front to back, back to front.

I think if you ask the average security blue teamer, like, hey. How do I monitor for risky sign ins without you know? Or how do I, use conditional access to only let iPhones do this, that, or how do I getting a lot of people would be like, I don't know how to detect graph run. I mean, there are blogs for it and it requires, you know, like, Microsoft licensing. That's another thing is a lot of it is paywalled.

Like, the whole cloud is paywalled pretty much when it comes to security features, which makes it a lot harder too because then it's, like, security person figures out how to do it eventually, and then they say, alright. Let's go do it. And they go to do it, and it's, like, this is gonna cost us $40,000 extra a year.

Speaker 0: I think another big part of that is most security people like myself, right, usually have access to an endpoint. So I can at least do the testing, do all the stuff, run some simulations on my own internal host, and do attacks. But I don't have access to our cloud production cloud environment to the point where I could do that exact same thing, and nor will they give it to me. So it's a lot harder for me to go out there and be like, poke around, figure it out, and to test because, yeah, the money type of thing.

Speaker 1: That's and that's one of the things we're talking about vendors. Some people were asking about vendors in this space. And there's a ton of super shady vendors out there, and I'm not gonna, like, poop on any of those vendors. But a ton of them, they aren't actually detecting any of the stuff that we talked about. Right?

The one vendor that is an exception that I will talk about because, well, 1, they're awesome, but, 2, because they're helping the pay what you can initiative is, SaaS alerts. And they came up and they started talking to me, and I'm like, crap. It's another vendor that wants me to say good things about their product. And they're like, so what we've been doing is, basically, when BOW releases tool, we make sure that we can detect those things. And I'm like, wait a minute now.

This is now relevant to my interests, doing, like, crowdfunding and

Speaker 2: things like that.

Speaker 1: But, yeah, check out SaaS alerts. But then again, SaaS alerts does have to have the appropriate logging to be able to detect these attacks, and that's that's a big deal. I really do go back to, I I think you should there should absolutely be no, like, there should be no upcharge for logs. Like, to get the logs to detect attacks, it shouldn't be like, well, that's gonna be tier 5, and that's dog shit. Like, if if we need those logs for day to day security, it should be part of the lowest tier package of everything that we get.

You shouldn't be, like, holding, you know, security over someone's head for more money.

Speaker 2: I know. And I'd like to remind everyone why did we make Graph Runner? We went we made Graph Runner because when the storm whatever attacks targeting the state department happened, and we talked about it on this show, and we said some attackers just got root keys into the cloud environment for the US State Department. How can we simulate this attack against our customers? And Bo is like, hold on.

I'm going to my cave. And he came back in, like, 2 weeks with Steve and was, like, alright. Here you go, Graph Runner. And it's basically what it is. It's, like, that whole attack was the state department hack, and yet what has changed since then?

It's the same thing. How has Microsoft not been required to I know they did kinda, like, e 3 gets logs now or whatever, but, like, I I still am just, like, how is how is this not more of a thing where, like, if it happened to the state department and it's happening, like, business email compromise, let's also talk about that. It ain't just about sexy hacking and graph runner. It's also about emails. Like, that's what that's where the money goes is business email compromise is not, you know, that APTs or whatever.

So I don't know. It blows my mind that, like, this kind of stuff doesn't get good logging and good, like, it's just I don't know. It's it is what it is, but I don't love it.

Speaker 0: That's the reason I have a job. Alright.

Speaker 1: It's the reason why we have a job.

Speaker 2: We're giving way we're giving way job security.

Speaker 1: Alright. Now this gets into yet another one that I this is, number 5. Check your 3rd parties.

Speaker 6: This

Speaker 1: whole thing when we're talking about Snowflake, when we're talking about what was it? God. There was another story I wanted to talk about that was it was a breach of a breach of a breach. Oh, here we go. It was the, data pilfered from Pentagon IT supply supplier Leidos.

So if you're reading this article, basically Leidos data was compromised through a company by the name of Diligent Corporation And if you scroll down, the Diligent Corporation appears to have been a breach from a company by the name of Steel Compliance Solutions. So

Speaker 2: So, okay, is this just the you know, the degrees of Kevin Bacon? This is that, but for breaches.

Speaker 1: This is like that, but for breaches. So I don't know if we got that Here, let me share that article so Ryan can get it out if he doesn't have it out yet.

Speaker 6: I just did.

Speaker 1: Okay. Awesome. There he goes. He's got it up. And, or he's getting it up here in a second.

But, you know, whenever people are talking about supply chain security, one of the things that's kinda pissing me off in the industry is whenever people talk about this, and this ties to the MFA thing, as though it's super easy to do. Right? Like, oh, well, we just gotta verify our supply chains for things like Snowflake or Kaseya or Leidos who's bought by Steel Compliance Solutions or, like, it it it's it there's such an inception of cloud products and vendors out there that I really, really do feel it's almost impossible for us to develop a good solid bill of materials, especially whenever we're talking about cloud solutions. Right? You know, we were talking about, well, we just need to make sure there's a bomb for all the security products so we know what's in that, so we know the security associated with it.

And I think that this last point in this article about MFA and this article from the register security just highlights, like, how effing hard this is actually going to be. And if anybody is, like, you know, at a keynote at RSA or anything like that, it's like, we need to make sure we're securing the supply chain. Those words are super easy to, like, get out your flappy lips, but the reality of it is it is incredibly difficult because you literally have cloud solution providers, the 6 degrees of a breach. You literally have cloud providers that are using other cloud providers that are using other cloud providers. And literally, when you hit one of them, sometimes it can lead to a data breach across multiples.

Or am I reading too much into this? Do you guys think that this is in fact easier than John, you're you're done.

Speaker 2: No. You're you're right. Spot on. Well, and I We talked about it last week. That's great.

Speaker 1: I'm so happy you all agree with me. Now I remember that you all I pay all of you.

Speaker 2: Yeah. You pay all of us. Yeah.

Speaker 5: Well, couple of times, we have to pay all

Speaker 4: of us. Yeah. Well, couple of times,

Speaker 1: like, number of you wait.

Speaker 3: Okay. So Yeah. Let's look at the CIS controls. For those of you who aren't familiar with them, we do have a control, control number 15, that talks about server pro provider management. And to those people who say it's difficult and it's hard, start with a darn spreadsheet and just start making an inventory of your service provider.

2nd of all, do you have a server per servers provider policy? You know, I look at organizations where they allow individual departments or business units to contract with cloud providers, that should be centrally managed within IT. So I think we can eat this elephant one bite at a time, John.

Speaker 1: Well, and I also think it goes back to contracting. Right? If you wanna know all your SAS programs that you're paying for, go back and pull your accounting records. One company that I was interviewing, I wanna say it was last week, Friday. They sat down, and they were doing an inventory of all the different SaaS products that were allowed into their environment, and they were comparing that to accounting, what they were paying for, and they realized they had, like, 4 enterprise Zoom accounts to 4 different people within the company.

Right? Now that's just highlighting a cost to an organization. But whenever you're looking at all your SaaS products that you're using, the best place that you can go is start with accounting. And then just like you said, Kelly, actually go to your vendors and ask them if they have a letter of attestation, that they were tested. We you know, you start with the elephant one bite at a time or a chainsaw, but I also think that we have to start pushing our cloud providers, our SaaS providers, to kind of start asking these questions from a compliance risk perspective.

And this sounds scary, but getting attorneys involved and making sure that these legal contracts that we have do at least have that language that they can communicate to us their bill of materials, possibly,

Speaker 2: maybe. Well, I'm dreaming

Speaker 1: of unicorns at this point, but we gotta start somewhere because this is just going to get worse. Right?

Speaker 6: Yeah. And this I was, like, I was looking over the articles earlier today and and going through and realizing we've gotten to a point that I don't think anyone really envisions 30 odd years ago when the Internet started going mainstream and that all of these digital services aren't just conveniences. They've become so enmeshed with our daily operations that they've moved on to the point of becoming utilities. Now granted, we suck at securing our utilities too, but this is this is a paradigm shift that I think a lot of people haven't quite grasped is that okay, you're gonna add on a new provider. How is that going to affect the holistic environment of what you're doing, of what you're trying to accomplish?

I just I wish I knew how to get people to think about the security aspect before rather than after things go sideways.

Speaker 5: Well and I think that's always been a problem, though. We've we've been fighting from the backside of it all. And the not thinking forward for 30 year for 30 plus years.

Speaker 1: Yeah. Yeah.

Speaker 5: That that that mind shift should have taken place years ago before we even got to this ingrained portion. It should have happened when with Microsoft's trusted computing environment minimum back in the early 2000

Speaker 6: pay attention to stuff when it impacts

Speaker 1: them. Well but you're absolutely right.

Speaker 4: Even that, though, I mean, if you if you wanna be really depressed, you know, technology operations folks have been fighting the same battle from the back end on availability for as long as computing has been a thing. Like and even before we were all talking about security, I mean, how many app support teams have you ever seen where it's like, boy, I really wish you guys would talk to us at the design phase as opposed to at rollout. And it No. Security is just, in a lot of ways, another one of those. It's sad, especially given the impact, but it's not surprising.

Speaker 1: Going back to what Mike was saying, you know, I I I think that we've all felt a slippage. Right, Mike? Like, we we

Speaker 0: Oh, yeah.

Speaker 1: You know, for for 20 years, 20 4 oh, god. 26 years. Never mind. We've been do dealing with this for a long time. We can barely keep up with the technologies that keep getting thrown at us.

And whenever we throw SaaS, going back to the accounting thing, do me a favor, seriously, as a security team, go to the accounting team and see how many reoccurring expenses exist for SaaS products in your organization. Even at BHIS, we're a small company, 140 people, and of course we're very heavily focused on IT, there's literally 100 of IT services that we're using. My wife just asked me today, there's a database of SDR signals, that we have a subscription for, and she's like, what the hell is this? And I'm like, well, that's a database from SDR signals for reverse engineering of embedded devices. She's like, who the hell does this here?

And I'm like, well, that's David and and a couple of other people here. And but when we start breaking that stuff down, it is a monstrous amount of different services. Like Bronwyn was saying, these are not nice to haves. These are things that are absolutely essential, and a lot of it is driven by the VC culture, right, where you want people in subscription models. You want that reoccurring revenue model so you can keep getting that money on a treadmill again and again and again, and it just bleeds to no more on prem solutions, no on prem software, everything has to be SaaS, everything has to be in the cloud, everything has to be multi tenant, everything has to be connected and single sign on, therefore, everything becomes vulnerable.

And, you know, somebody made a snarky comment of so much for the cloud leading to things being more secure. That's a really snarky comment, but I'd like to put it out there. It kind of seems like SaaS inheritance of failure, Joseph just put out. I think that's kind of where this is starting to look. Right?

Like, it's absolutely leading to SaaS inheritance of failure.

Speaker 2: Well, hold on. Let me let me tease my up an upcoming webcast and hopefully make people feel a little bit better because something to keep in mind is that as much as these tools can SaaS tools can also be used for harm, we can also use the capabilities infrastructure, and you can monitor things today that you could never monitor 20 years ago. You can monitor I mean, you can do things in cloud products that have insane security outcomes without just check boxes or easy things, like, you know, there's many, many examples, but my upcoming webcast is talking about using 1 a really cool vendor. If you wanna monitor this and you're if you're not a CSO who can go to the accounting team and say stop all payments, if you're just a guy who would like me, you can you can like, a tool like Flare that we're gonna talk about during my upcoming webcast, you can monitor a huge part of your footprint without really having to do much work at all. You can see, like, in a tool like Flare or Spy Cloud or whatever tool you pick, you can see very far reaching security things before they happen to you, which is why there's really no excuse for someone like Snowflake not fixing this stuff.

Every CPT customer gets a spreadsheet the 1st day they sign up of, here's all your breach creds, here's all the ransomware dumps that your data's in, here's all the GitHub profiles, here's all of this. Like, you can use tools to monitor and detect this kind of stuff way further out than you could ever before. Like, you can see, oh, I was in the collab or breach from this, you know, 10 terabytes of data from this breach, and then I was in this, and then they'll OCR data, like, they'll it's just there are tools like that that make people's lives much easier of, like, I can just type in my company name, and it'll be like, hey. Your company was in this company's breach, and then it was in this company's breach. And so you can do that.

Like, you can actually follow along with some of that exposure before it hits you, and you should. Like, I think that's kind of a core thing now is, like, follow your supply chain data exposure. You might not be able to fix it on the front end, but you can at least know it's coming and it's gonna hit you. Right? I think that's part of it.

You gotta do that.

Speaker 0: Speaking of supply chain attacks, can can we please talk about North Korea?

Speaker 2: You have one minute. Go.

Speaker 1: You have one minute.

Speaker 0: I have one minute. I don't even have the pretty much, know before hired North Korea. They they found him. We got him. That's it.

No. There's a there's a lot of

Speaker 5: Feel like we might be

Speaker 1: missing some steps there, Wade.

Speaker 2: Great job, Matt. So that we

Speaker 4: hit all the details. Bring up

Speaker 0: bring up the news article so I can read it as I as I pretend to know exactly what happened. So pretty much know before was hiring, an internal IT guy, right, with this awesome cool picture right here. Went through all the proper steps, and then they actually even issued him a laptop. I believe it even says what type of laptop. I believe it was a Mac, which I'm, like, good for them for using Mac.

Like, I would hate to do that security, but anyway, that's another subject.

Speaker 1: That's brave.

Speaker 2: That's true. And

Speaker 0: so the crazy part is that picture is actually a deep fake of an actual stock picture if you go all the way down to the bottom. So this the moment this guy got his laptop, he just immediately loaded it up with malware and all sorts of good things. And their sock actually went went went to full throttle and triaged everything. And they found out, hey, this is, actually not a person working here. This is a North Korean IT actor who's trying to infect know before and then possibly as a supply chain attack go to the words of their customers.

I'm sure know before is probably at least I think they're one of the top, what, security awareness companies out there. At least I know their name and I've used them quite a lot in different organizations. So it's a pretty good one. I'd know they did get in contact with the FBI further down, but this is something we've been talking about all the time. These it's not something that's gonna happen to everyone, but I think it's actually a cool story and and a win.

And for us to end on a win is very rare.

Speaker 2: Let's take it. Go with the puns. Alright. Release the puns.

Speaker 1: With that that let's close it out on a win. Thank you so much for joining, and we will be back next week.