[Music]
all right good afternoon
everybody so the talk here is the calls
coming from inside the house
authentication proxy
attacks my name is Chris Merkel I'm the
senior director of cyber defense at
Northwestern Mutual here in
Milwaukee um and and in today's talk
we're going to be discussing a uh a type
of attack that we've been tracking now
for uh just over 6
months and the content that we'll be
covering in this presentation isn't just
my original research we've got a team of
absolutely brilliant folks working in
detection response and
intelligence um who are responsible for
a lot of the content that you see here
so I wouldn't be able to be up here
talking about this if it weren't for the
the fantastic team that that I've got
supporting
me um as I've noted here um if you catch
me in Mastadon I'll post a link to the
slides if you want to catch those uh
probably within the next day or two I'll
I'll go ahead and get these
posted so let's get into
it so my first and first thing I want to
tell you is my favorite movie is
Ratatouille now I can't use copyrighted
content in in a Public Presentation but
if you've seen the movie
Ratatouille you know that that the the
main idea here is anyone can cook so
here's the thing I want all of you to be
able to take something out of this
presentation and put it in action within
your
organization so that means if if we're
saying everyone can cook I'm delivering
a sandwich a good news bad news good
news sandwich right so your organization
has you've all enabled MFA right
everything is protected by MFA you're
100% safe right uh don't raise your hand
if the answer's no
um uh but for a lot of organizations at
least for your internet facing perimeter
you've got multiactor authentication
enabled so you think to yourself and you
tell your regulator if your Auditors
anybody who comes and inspects you that
you're okay well I'm here to deliver the
bad news which is
it's not good enough
anymore well the good news is here at
cyphercon uh we're going to learn how to
cook up some new
defenses so back to the good news you
did it you've got multiactor
authentication
enabled even better maybe you even moved
away from some of the weaker
authentication methods like
SMS push to approve things like that I
don't want to denigrate MFA
because seriously if you've enabled
multiactor authentication in your
organization you're still
countering a significant portion of the
attacks uh Microsoft places this
somewhere in the realm of 99% of all
attacks that come up against Microsoft
accounts are mitigated through even the
most simple multiactor authentication
schemes that's
great so that's good news the bad news
is our attackers are uh they're
adapting and so there's new fishing kits
there's large scale campaigns and the
things that I'm going to talk about
today they're happening in uh ransomware
as a service type
schemes so these are happening at
scale and as I go through some of this
I'm probably going to cover stuff where
you know you know maybe you haven't seen
this yet but this is one of these
attacks where you got to kind of go
looking for it unless your users have
brought it to
you so when we talk about MFA what I
have to do is is kind of go through
what's good MFA and what's bad MFA
now up until this point most people have
thought to themselves
well SMS is no good why because we can
do Sim swapping attacks right okay fair
enough maybe we go push to approve well
push to approve is okay except for the
fact that our users get griefed with
prompts so they they credential stuff
and they and they they request that
approval button over and over and over
and over and what users do they click
okay
um but
cisa uh they did something kind of
cool so they created a new designation
and this is a term of
art they call it fishing resistant MFA
now what I love about this designation
is that it takes your
MFA whatever you're using today and it
puts it into one of two buckets fishing
resistant not fishing resistant now cisa
if you go look and do a Google search
for cisa uh fishing resistant
MFA they're going to come up with a like
a two page write up on uh where they
kind of rank MFA methods from weakest to
strongest I summed it up right
here if you're not doing some sort of
certificate based
authenticator so think phyto key think
uh TPM module in a laptop think uh uh
Hardware security module in your iPhone
or your pixel if you are not using that
cisa is telling telling you that you do
not have fishing resistant
MFA
so I say that not because I'm trying to
like make any of you think oh I'm not
doing a good enough job no no no not at
all this is your ammunition this is your
ammunition with your leadership and your
organization to push them ahead by
saying look the federal government has a
designation and we're not there yet
so I think that's a great
thing so why do they call it fishing
resistant multiactor authentication well
what I'm going to do is I'm going to
walk through this
attack and I'm going to kind of
demonstrate why fishing resistant MFA
works and why all other forms of MFA
simply do not okay so by way of
background the attack that I'm talking
about here is not new it's not novel
evil engine X that was released in
2018 as a as a proof of concept on how
you can steal session tokens so it's
been around uh I know a lot of red
teamers have worked with this and you
know demonstrated that it can be
used but like a lot of
attacks you don't need to do the extra
work to implement evil engine X when
good oldfashioned fishing people for
username and password just straight up
Works where you know griefing people
with push straight up works it wasn't
until uh roughly May of last year based
on what we've seen that attackers
finally shifted what they're doing and
they did so primarily because uh of the
uh uh evil proxy uh software as a
service
kit um so here's how this works uh
there's a there's a lot of lines on this
graph so I apologize in advance about
that but I'm going to walk through one
by one one so here's how this attack
works first your user receives a fishing
message and by the way the fishing
messages they're using are really cool
and novel I've got a whole sidebar about
that in just a
second so you're victim they click on a
fishing link they enter their
credentials and they complete multiactor
authentication could be a code could be
a push approval whatever it is right uh
not f02 key
okay what the attacker has done is
they've actually set up
a proxy that sits in
between your victim and your victim's
identity provider so the for for the
purposes of this presentation I'm
primarily going to talk about Azure
active
directory but these types of attacks can
happen in other uh single sign on
environments think uh OCTA ping off zero
uh you know uh identity providers such
as those
okay so so what happens is when when the
user clicks on the link they're brought
to a page that's being proxied to them
the page being proxied to them is the
page from your identity provider all
they're doing is fetching that page and
displaying it to the user that's why I
say the attacks coming in from inside
the house the attacker is not doing what
they normally do normally what an
attacker is doing is they're going out
and they're setting up a custom fishing
page and those custom fishing Pages
typically have all the Tail Signs
because they can't get the HTML right
the image looks wonky they they try to
add some text to it and and you know you
get one ad and you can tell immediately
that this is a fishing cage
right well in this attack that's not
what what's happening they're taking
your actual page and proxying it through
to
you so then what
happens when the user enters that
username password into that site that
proxy
they're forwarding it right to your
identity
provider now along the way of course
they're going to steal your credentials
why not you got an opportunity to steal
credentials now your identity provider
they have no clue that this is happening
all they see is a valid authentication
attempt so what do they do they return
your session token and session token
theft is what we're talking about
here the attack steals your session
token and the attacker if they feel like
it they'll even forward your that valid
session token back to you because in
particularly in Microsoft in Azure
active
directory they're just starting to bring
out some checks for this but by default
there's no check to see if a token is
being reused in different contexts okay
so they for the session token back the
attacker they can do the same thing so
they go ahead and pin that session token
in their browser or whatever attack
tools they're using and they are now
effectively logged in as the victim with
the same amount of uh rights that the
the victim has in in their uh 0365 Azure
tenant the user they get logged in they
just end up on a page where you know
they get to an 0365 landing page and
they think to themselves well well that
was weird but I'm back at my main page
and you know no harm no
fault and then on top of that if you
don't have MFA on uh across all of your
public facing Properties or you have
other third party Integrations well they
can go to credential stuffing after
that so I talked a bit about the deliver
examples so let's walk through
those so the they still use the dumb old
ways lookalike domains things like that
and one of the things they do a lot is
we've seen recently is they like to um
mimic message encryption tools so think
uh uh Microsoft's uh Native message
encryption uh proof Point zix those
types of things but it's just a copycat
right and with any copycat message um
there's going to be some sort of a
Telltale right uh you know if you're if
you're doing a reasonable job at
security awareness training with your
users they're going to see those
telltalenoob
uh they then can send an encrypted
message to their victims from that
person's
mailbox now the benefit of this is that
you as the organization that's a
recipient of this you don't have the
opportunity or the ability to scan the
contents of the message the message is
encrypted okay so they're doing that
through basic mailbox compromise
scenarios but a lot of times the tenants
that they're they're dealing with are
are large organizations again
organizations that have MFA turned on
it's a little harder to compromise that
mailbox of that large organization but
the message the organizations that are
really easy to get into are the smaller
companies that you do business with
people in your supply chain so what's
happening is they're not going after the
big companies to use their Rights
Management Service Microsoft pview
they're compromising small organizations
opportun un istically and seeing who
they deal with and if they receive an
encrypted message they go into the
encrypted message and they open it in
their
browser and unless you have it
configured otherwise you can basically
change the entire message you can change
who all the recipients are you can
change the subject line and you can
change the message body essentially you
have hollowed out an encrypted message
that somebody has received at that point
you put in your fishing lure and you hit
send the victims get an email that looks
like it comes from a normal reputable
large
company but it contains this fishing
payload and I'm going to take one second
to rag on Microsoft about this
because uh if you have Office
365 you have full control over your key
management environment for your users so
when somebody wants to send an encrypted
message to you you
um
uh you should be able to inspect that
message right there should be a way that
you as the tenant owner can can inspect
that message for malicious things
instead Microsoft doesn't have some sort
of sitewide signing key that can be used
for message inspection all they have are
individual user keys and this makes
things really complicated if you want to
carry out one of these
investigations because even your own
email administ rators they can't see the
contents of this these
messages now if you're using a third
party client you're going to get a
message that looks kind of like what you
see here it says click on this to open
the encrypted
message if you are in an 0365 tenant
with all the right management stuff
properly in place you don't see a
message that looks like this you see the
actual email itself but with one key
difference it has a green bar across the
top with a green check mark informing
your user that the message is
encrypted now if a user sees a green
checkbox across the
top what do they actually interpret that
to mean it's safe
exactly so we also have a ux problem on
the Microsoft side because just like you
know the old days when you used to put
that padlock in the
browser use users are still conditioned
that indicators of security are
indicators of safety in every
context and so that's what makes this
particular form of attack this message
hollowing attack so
effective it prohibits us from
inspecting the content and it sends an
implicit message to the user that what
they're about to click on is
safe and what does the victim see well
there's one Telltale if you look up in
the the browser bar
they can't mimic your exact domain they
still have to come up with something but
and and again I I work at Northwestern
Mutual this is just an example I mocked
up what comes across is one of two
things it's either the specific branding
that you've put in place for your Azure
0365
tenant or it's the generic default
Microsoft Canon now this is where the
Fatal flaw lies in this attack so I'm
going to come back to this in just a
minute so let's talk about detecting
these
attacks there's a couple of things we
can do
now as we start to talk about
detection um not every organization is
going to have the ability to do all of
these things so I'm going to run through
a whole bunch of them and my hope is
that you'll be able to do some of these
and even if you're able to do just a few
of these things I think you will be
better positioned to gain visibility
into these attacks and have a sporting
chance at stopping
them so one of the first things that we
can do is is is generally available to
most people who have an Azure ad tenant
you can turn on Impossible travel alerts
these are reasonably accurate why are
they reasonably accurate well because of
your favorite YouTubers and your
favorite YouTubers are constantly
pushing those stupid VPN services that
your users absolutely don't need this is
messaging by the way is uh sponsored by
Nord VP no sorry
um so your
users think that they're gaining some
sort of like security benefit because
they've got you know some VPN client on
their phone well great well what that
does is that's going to set off your
impossible travel alerts all the time
and um because the the the primary in
use ful purpose of these uh vpns is to
gain access to content in other
countries they go out of their way to
mask where they're coming from so uh you
know there's you're not going to like
see one IP block that's called
expressvpn IP block right they've got
all kinds of obfuscation on the
ownership of all of these these these uh
net blocks that they
use in addition to that your attackers
are pretty
smart um they they're going to look up
and see where you're headquartered so if
you're headquartered out of the Chicago
land area or the Milwaukee area or
Minneapolis that's what they're going to
do they're going to use geolocated
proxies through
residential uh infected computers to
proxy all their traffic through so
you're not going to trip so so what's
going to happen in this case is you're
going to have some false negatives
because they're using localized proxy
services and you're going to have false
positives because they're using consumer
VPN
services but this
helps now in some systems and and in
particular I'm highlighting OCTA here I
don't believe that there's an analog
quite yet uh in Azure active
directory um in Octa you can actually
block entire asns so if you have access
to a threat intelligence platform rather
than feeding in individual net blocks or
you know incredibly long list of IP
addresses uh you can basically identify
your bad neighborhoods and start to
block those with with ASN um in addition
if you have some sort of sore capacity I
strongly recommend um using that to warn
people when you see them sign in from
from places they haven't been uh
before so we talked a little bit before
about uh these geolocation based
alerts and I I kind of said well they're
good up and a point right we've got some
false positive situations we got some
false negative
situations um but if you look at these
in addition to other things going on
you're going to get a lot closer to
finding this malicious
behavior so one of the things that can
happen here is again this is an an Azure
ad specific attack um but if you see a
log on from a previously unknown IP
address and you see a change in
authenticator you know something's up
even
worse uh Azure active directory lets you
kind of sign up and register your device
as an Azure active directory join
device and that is often times the first
thing that starts uh a chain of trust
that ends in them being able to access
your corporate
resources
so all right I guess this is time number
two where I rag on
Microsoft
um when a person has stolen your your
session
token they now have the ability to go
into the Microsoft password self-service
portion of
0365 they now have the ability to add
and remove authenticators on your
account Microsoft so now now now think
about this for a second
let's say that the lure was accessing a
a SharePoint document and that your
authorization should just be scoped to
SharePoint well it's not it's you're
authenticated on that session to the
entirety of the Microsoft 365
environment so that means your attacker
with that session token can log in and
set up a new phone number they can set
up OTP basically they can give
themselves persistance because the
session token that they've gotten lasts
for about 7 days well they've got seven
days to go in here and do it now what
could Microsoft do in this case they
could require Step Up authentication for
password management
events they're working on it as far as I
understand it is not
here and uh you know once they do that
they've got the ability to log on
persistently forever why because again
like I talked about when we did the
attack overview they've got that
username and password
and would your user notice if they had a
new authenticator registered maybe maybe
not but you
can so keep an eye out for
that so in terms of detection I talked
about the end user experience I showed
what those log on pages look like and I
I pointed out the fact that they are not
faking log on pages they're delivering
your log on page to the user and I said
before that that has a fatal flaw in its
core this is what it
is your log on page has things that are
are unique either to your
organization or to the authentication
flow of your identity provider
okay so for example if you've used
custom
branding you've changed the background
color if you've changed the background
color you've picked whatever your
corporate color is blue green red and
your marketing people they don't just
like the off-the-shelf blue green and
red they like a very very specific blue
green or red and they have a style guide
possibly even published on your internet
that tells you if you're going to do
business as us you need to use this
specific hex code for blue that is the
correct corporate color of blue
corporate color of green corporate color
of red I see a few of you shake nodding
your heads um and I work at a large
company and if I run a file of custom
branding I will hear about it too right
um well that's in the Dom that's in the
HTTP stream that comes back back so if
you have the ability to inspect the
content of HTTP flows going into your
organization you have the ability to
look and see when uh those unique
elements that should only exist in your
log on page are being delivered from
domains that you do not recognize as
valid okay so now you can start
detecting that in addition Microsoft for
example they have a specific domain
called MS off.net
that domain only exists during the
course of a Microsoft authentication
transaction you should never ever ever
see that domain being called unless
authentication is happening so what you
can do is you can start to in again
using your your IDs or whatever
inspection ability you have you can look
for when those items that you've
identified as specific to you or your
log on Flow occur from unexpected places
now you might come up with a couple of
false positives you weed those out and
at that point you've got a pretty good
idea uh that this type of attack is
happening to you again why because the
thread actor is not modifying any of the
Dom on its way to being delivered to
you in addition to that you can start
looking at the the metadata from TLS
certificates um Microsoft does not use
let's en Crypt
okay lights encrypt is great I love
lights encrypt um but that is not what
is on Microsoft's log on page or octa's
log on page or ping identities log on
page okay if you see a if you have the
ability again to inspect traffic and you
see some of these Telltale indicators
that an authentication session is
occurring but the certificate metadata
doesn't match up you've got a good Alert
on your
hands
okay third rant against Microsoft and I
promise is my last okay when you're
given a
session that session token lives inside
your browser and only that instance of
that browser on the machine on which you
use it if you use a different browser on
the same machine or the same version of
a browser on a different machine you
have to reauthenticate and reestablish
another token so what that means is that
your user agent and all of the
identifiers around it should always look
the same does Microsoft check any of
this no you can just parlay that same
token with user agent strings from
chrome and Safari and Edge and
Microsoft's just like well yeah it's a
valid session token I'll let you
in but that should never happen happen
during the normal course of
use again I've heard Microsoft is
looking at this but this is still the
current state of attack you can parlay
these
things uh the user agent shouldn't
change also look for bad user agents
right your users are not using curl to
authenticate to 0365 if you see
authentication events that involve curl
you got something bad going on okay um
and and and and if nothing else
hopefully you've got a firewall log that
you can you can
inspect uh to to identify that's some
sort of a automations going
on um there's some uh Advanced methods
um just for the purpose of time I won't
get into token swaps the basic idea here
is there some there's some really cool
research on this where you can uh use an
existing token of parlay access to
things that are even outside the scope
of authorization for the token
um but I want to get into a bit about
purple
teaming so being able to detect this in
your environment is an exercise and
understanding how your environment
operates what normal is and the best way
to do that is through purple team
testing right so like I mentioned before
evil engine X has been out since
2018 uh it runs inside of a Docker
container and it is very simple to use
you do not need to be a red teamer to
set this up and try it it's pretty
straightforward it's a fun weekend
project if that's your definition of fun
weekend
project
um so start to look at what happens when
you set up that attack what looks
different in your
logs um in addition you can set up alert
thresholds so if you see a certain
amount of MFA failures um because
they've uh you know messed things up you
can look for that too um and then beyond
that uh again looking for non-typical
authentication end points uh another
Advanced thing that you can do here is
uh script canaries I love script
canaries because if you have the ability
to customize your log on page now you
can't do this with Microsoft but um
again this attack theoretically works
against any application that has an
authentication flow that results in a
session token being issued it can be a
big identity provider like I've talked
about but it can also be your
organization front-end portal your
e-commerce portal whatever web app you
have and whatever that authentication
flow looks like if you have the ability
to uh customize your login Pages check
out script canaries i' strongly
recommend embeding script canaries into
your login page to get a little more
insight into um what's going on
because um you know that if this content
is loaded it should only be loaded from
a specific domain if a script Canary is
in your page and you see it being Lo
loaded by somebody who shouldn't that's
going to set something off so uh some of
that's a little more advanced but um I'm
kind of setting the idea of script
canaries out there if you've used them
if you've worked with Canary tools um
you know that's one of these things that
that I think you can look at and decide
if you can cook with
it so now that we've talked a lot about
you know detecting some of these attacks
uh we're going to look a little bit at
an inv investigation and a few more
detection
methods um so first of all if you think
you've been affected by this um check
and see whether uh successful MFA has
occurred or not because you do need to
differentiate this attack from uh a
credential stuffing attack for
example in terms of
response if you know that somebody has
stolen a session
token do you know how to actually
invalidate session
tokens uh in in in typical
organizations when you have a
compromised
credential usually what you're going to
do is you're you're not going to want to
hurt end user experience too much so
what you're going to do is you're going
to issue what we would call a soft
password reset and that's the one that
says next time you log in you get
prompted to change your password and in
most circumstances you know that works
fine if they just you know clicked on
some you know crummy fishing link and
you know there's no MFA you know bypass
method or or things like that yeah sure
do that it's not that disruptive to your
users the problem with this is that that
softw soft password reset is really
designed to uh uh be a convenience
factor for your
users um so it doesn't invalidate their
sessions right they go back to their
browser they're still logged in like
they were even though their password's
reset maybe they'll have to authentic
again in a couple of days if you do a
hard password reset which is literally
just changing the password on the
account locking them out and forcing
them through a reset procedure with your
help desk that will invalidate most
sessions um uh despite that even in
Microsoft 365 you have such a
proliferation of end points that you can
parlay that session to you still have to
manually go in
and invalidate sessions and you can do
this through Powershell scripts
Microsoft does provide documentation on
doing it but even doing a hard password
reset alone is not enough for
this now once you know that somebody
successfully did this the question is
what did they do now hopefully you have
uh access to your Microsoft 365 logs uh
e either uh Within in uh Azure Sentinel
itself or forwarded to your
sim um you're going to want to look for
access to one drive mail forwarding
rules so that's one of their favorites
uh one of the first things they'll do is
set up a mail forwarding rule so go look
for that again look for authenticator
changes um and then these last two user
creation and exchange mail transport
rules
um if you do not have good separation
between your uh administrative accounts
and your normal user
accounts uh well figure out how to do
that
um but if they catch the right person
with the right level of administrative
access they're going to go start
creating new users or even worse uh
start compromising your your exchange
environment install ma transport rules
uh things like that so so be on the
lookout for for those types of things
I think I'll
I'll so from there we can go do a little
bit of offense here um make sure you
know all your good authentication end
points okay so you know why does this
start at Asset Management as the very
first thing you should do because
knowing your stuff is the most important
part of your job knowing what's normal
and what's good and baselining that
really is the foundation for uh being
able to to understand your environment
understand what's normal and what's
abnormal and once you know what's
abnormal you can decide whether that is
malicious or just
unexpected
um if you're a showan user you can do a
lot of hunts for evil engine X and evil
proxy
ttps uh a lot of those are
public um and then again search your
firewall logs for typo squats um there's
a there's a a python script called DNS
twist it's been around forever and it
works amazingly well at generating
lookalike domains that uh correspond to
to whatever domain you feed it right so
start looking for those things and if
you look for those lookalike domains you
can also look at it uh in addition to
the common path so for example
um in the Microsoft log on you have uh
uh you know
microsoft.com I don't know authenticate
let's just say right what you're going
to want to look for is instances where
you see your organization's log on in
one of these typo squat domains but also
contains log on authenticate or those
types of
keywords and then beyond that um if you
if you have the ability and the means um
you know keep on the lookout through
intelligence sources for uh thread
actors most likely to use that that MFA
proxy um so so I dumped a lot of
information on everybody here um and we
do have some time left but but really
where I wanted to wrap this up is is uh
you
know um oh sorry wrong slide is is to to
kind of encourage everybody here that
you may not be able to do all of this
okay so we covered a a whole lot of
different ways to detect this but you
can do some of this um so again uh you
know be on the lookout for uh uh uh
encrypted message traffic uh be on the
lookout for those typo squat domains be
on the lookout for any traffic that
looks abnormal around authentication and
you've got a good chance of identifying
these these types of attacks so uh with
with that being said um I I'll take
about uh you know maybe the next 10
minutes or so and see if anybody has any
any questions about this attack that I
can
answer it is yeah so if I
go all the way back to the beginning
here um if you follow me on Macedon I
will post a link to this in the next
year
too
[Music]
sure so the the question was what the
question kind of comes down to is in a
lot of organizations you're going to be
uh you're going to have your hands tied
a little bit around user privacy right
there are certain categories that your
law your HR department is going to say
no you cannot inspect this traffic right
um and and have we seen that absolutely
yes but the thing that we've seen more
commonly is a domain that's been
registered within the last 30 days so so
even if a domain manages to get itself
into one of those categories if you
simply take the step of implicitly
blocking access to all domains that are
less than 30 days old you're actually
going to catch a whole bunch of these
but that's a great
question
that's a great question so the question
was what about decoupling your identity
provider or your MFA Provider from your
primary directory provider so uh using
OCTA for MFA while using Azure ad for
example would that
work I don't think so I haven't tested
this but if you if you think about the
way this attack
[Music]
works well yeah the well either a Ubbi
Kei or or using the secure Enclave on
your phone yeah that's that's that's a
better answer right however um I I I'll
be the first to acknowledge that handing
out yubis is a logistical hassle if
you've been doing this long enough you
remember the bad old days of like
mailing RSA keys to people right and the
second you could do this through SMS on
your phone everybody was like yeah we're
done with this right so so yeah managing
physical second factors is a hassle um
but but to your
question I would assume that because
they're they're proxying all of your
traffic that they will have the ability
to get whatever session token is
specific to your organization now um
attackers are still uh lazy and cookie
cutter right so if they're using in you
know an existing attack tool and it's
not wired up for your specific scenario
yeah you might actually get get past
them because they're looking for this
specific value in the return stream and
they're not seeing it and so they just
don't catch it right that's POS possible
too they'd have to like custom Implement
for you and your setup so there's some
possibility of being a little more
resilient that way that's a very
insightful
question sure so the question is how do
we how do we keep up to date on ATT tax
um man a year ago I'd say Twitter was a
great resource for that uh um and and
and I and I mean that I mean that in all
seriousness um you had a large community
of of folks on infosec i i as I've
showed in my slide I've kind of moved to
Mastadon um social media is still a
great resource for that um increasingly
I'm finding YouTube um and finding a
couple of you know good good security
content creators there's a lot of bad
ones um you know kind of talking about
you know the today's attacks um podcasts
uh I still rely heavily on podcasts now
podcasts were great when I commuted
every single day to and from work uh and
I would suspect a lot of you you know no
longer have that commute so um take a
walk in the middle of the day right um
you know get out your podcast player um
podcasts I like uh Risky Business
podcast um those are those kind of big
attacks big macro Trends uh the Sans
internet Storm Center they've got a
daily podcast on every every uh you know
current attack technique and things like
that um that's us that's what I use to
to kind of stay up on these things yeah
you
bet uh so the question was do I know off
the top of my head some of those better
YouTube creators um no because I'm old
um I just personally can't sit through
YouTube videos that have 45 minutes
worth of video for something I could
have read in a blog for like 5 minutes
but my kids
[Music]
Lo so the question is what do we do
about API Keys
um I guess for for what we're seeing
here
um you know this is really around that
that normal authentication workflow
right um how do you detect if you have a
compromised API key that's that's that's
a bit challenging right
um the My go-tos for that are really go
back to baselining your expected traffic
flows right so if you know that this API
key is should only come from a specific
IP address or IP address range it should
only come from a specific type of user
agent you can at least profile that and
if you see something happening that
doesn't match that pattern that's a good
way of detecting uh API key
abuse
all right any other
questions well if not thank you so much
um I'm happy to stick around and answer
questions uh on the side here and I
appreciate your time and attention thank
[Applause]
you