Going live. Woo hoo.
We are live. We're live, Yasmin. Yep. Welcome
to preshow.
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? No. That was that shit just
rolled.
Really? I
p if they if they went anywhere near
PR illegal, they're like, woah. Woah. Woah. Woah.
That sad face goes way back to, like,
95.
That really didn't I thought they added it
in Windows 10 or Windows 8. Oh, now
it's old. No. It's sad faces around that.
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. Face. That's cool. That's what
the world that's what the world needs 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.
Absolutely.
Stop all 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.
Oh my god. I thought the sad face
predated. I I I remember I remember, like,
XP never having XP was just fatal system
error. You're just No. I'm like, goddamn it.
Like, there goes StarCraft. Yeah. 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, we're gonna remove Clippy. Too much
like that. We're gonna have this. I've actually
got a picture of me with the guy
who killed Clippy,
from Microsoft.
You mean, Copilot?
What what an epithet. The guy who killed
Clippy.
Yeah.
I see you're trying to make a Chad
GPT clone. I'd like to help. Do you
need any help?
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.
I put that on my resume.
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.
Let's talk about CrowdStrike.
Square.
We'll get to those stories
later. Alright. John, John, I will pay you
$10 if we don't talk about CrowdStrike.
Done. Just throw up your Venmo.
Throw up your Venmo if you want
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.
And there it is.
That's the story. Mhmm. Are we per I
get the impression we're burnt out on CrowdStrike.
You take my money, John. You take it.
We don't talk about CrowdStrike. I mean, let's
let's let's let's let's just talk out. You
don't talk. Okay. 1 Just like the first
real fight book. 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?
Well, Corey, that's a very personal question. Personal
question. I think that's an HR infringement.
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?
Oh, that's interesting. Is this just some type
of fear? Because, yeah, that did happen. Right?
I mean but,
because what does that mean for the downstream
impacts on that? Are people
literally gonna be like, don't trust user manuals
anymore?
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.
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?
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? If they if they're
not
if if this is not a security incident,
they don't have to.
Well, if if the computer's down, it's not
available and you can't hack it. Therefore, it's
not a security incident.
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. So wait. Has anyone reported
it to the SCC
at all? I've not I've not seen any
reports on it, and they're supposed to report
within 4 days
according to SEC regulations. 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.
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.
Despite fight. Yes. It's okay. 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 Oh. Does anybody have a faulty
counter take? 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
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. 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.
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 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? I mean,
how would you describe this as malicious? But
but then how does it mean they did
it on purpose? You did so then it
was then how would you what would you
classify this as then if it's not malicious?
I think this is the IP image. I
don't think this is a security incident. I
will go there. I love the shit. You
guys So it's not malicious. It's I'm trying
to remember.
It's defective. It's defective
product. Yeah. Yeah. It's a defective product that
you did on somebody, though.
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. For manslaughter.
Homicide. It depends. It depends. Okay. So but
still, you've got somebody who's dead. So Under
manslaughter. There's still
great Bronwyn.
In this
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.
I think Cyberman Fox is the only one
that's been running. By the way, links to
the actual 8 k filing that,
CrowdStrike put in with the SEC.
Yeah. Oh, Marky. There you go being all
serious.
No. Someone's gonna I'm sorry. I I know
I'm I'm I'm mister paperwork over here. 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.
Alright. But it impacted the AMUS was down.
Would you file that incident?
Yeah. That's one of the questions. Love this
is the CIA triad is dumb.
This thing is 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? I think you nailed it.
I feel that's fair. You scattered right on
the front of the like that. Was that
in a circle that came in? Caught that.
But I still like cyber manslaughter better. Anyway,
so I'll add one thing. 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 Let me add Go ahead. Let me
add Go ahead, Kelly. 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.
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 What if the intent wasn't
to harm?
Cyber manslaughter. They already covered that slaughter. Are
you just effing with me, Wade? Like, what?
Yes.
Yeah. I I I I I got nothing
for you, Wade, on that one. It's like,
yeah. I don't know. 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. Great point.
We have 12 RZA said a breach does
not mean, no. No. Wait. Hold on. Things
are moving really, really fast. Does breach not
mean data leakage?
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. John, I'd like
to ask one
Go ahead, Kelly.
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.
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.
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. No. I hate Slack.
Yeah.
Compared to Teams? Oh my god. Alright. Teams
is Yeah. Teams is inevitable. It's like Thanos.
Shecky, what were you gonna say? 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,
and we're gonna 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. 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.
I hate it because of hurricanes.
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. Yeah.
We may have started on heat. We may
have started
a we we may have a little bit
of a holy war. Teams, the new dumpster
fire.
Yeah. Yeah. Teams. Chime in with your I'm
sorry. Dumpster
fire,
folks. O g g. You mean Skype?
Skype.
Uh-huh. Right? No. Is there any other news?
Yeah.
I think we need to find out that
story. Of other news. 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. 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. 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? 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? They also they
also said report it to the United States
postal services. Oh, yeah. Don't do that. But
basically Unfortunately, no one's shown up at my
door yet. 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, it's like
2 did you give them 2 gift cards?
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. We've got people asking what
was the percent success rate on this. 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 a red team, I only
sent out, like, 10.
20 was overkill. I I just wanted to
be on the stage. I was afraid to
see some of the 20 per customer is
excess. Yes. 20 per customer was too many.
We should have done, like, 5 that I
would say like, 5. Yeah. 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 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 they they 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. I feel like
there's a take backseize coming up shortly.
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. 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?
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.
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?
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. So A lot
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. 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 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.
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. 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. 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?
Yeah. We did. 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 once you There's, like, blogs that are
like how to detect Graph Runner.
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.
Alright. So how many of the customers detected
us doing those things inside of their cloud
infrastructures?
0. Yeah. None of them.
There we get into a problem. 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.
Yeah. 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. 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. Yep. I 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. 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. 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 things like that.
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.
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. That's
the reason I have a job. Alright. It's
the reason why we have a job. We're
giving way we're giving way job security.
Alright. Now this gets into
yet another one that I
this is, number 5.
Check your 3rd parties.
This
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
So, okay, is this just the you know,
the degrees of Kevin Bacon? This is that,
but for breaches. 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. I just did. 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. No. You're you're
right. Spot on.
Well, and I We talked about it last
week. That's great. I'm so happy you all
agree with me. Now I remember that you
all I pay all of you.
Yeah. You pay all of us. Yeah. Well,
couple of times, we have to pay all
of us. Yeah. Well, couple of times,
like, number of you wait. 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.
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,
maybe. Well, I'm dreaming of unicorns at this
point, but we gotta start somewhere because this
is just going to get worse. Right? 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.
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. Yeah.
Yeah. 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 pay attention
to stuff when it impacts
them. Well but you're absolutely right. 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.
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 Oh,
yeah. 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.
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.
Speaking of supply chain
attacks,
can can we please talk about North Korea?
You have one minute. Go. You have one
minute. 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
Feel like we might be missing some steps
there, Wade. Great job, Matt. So that we
hit all the details. Bring up 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.
That's brave. That's true. And
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. Let's take it.
Go with the puns. Alright. Release the puns.
With that that let's close it out on
a win. Thank you so much for joining,
and we will be back next week.