[Music]
thank you
[Music]
all right
foreign
because I can look at all my friends in
the audience but for those of you who I
don't know
uh my name is Kat Traxler I'm the
principal security researcher at a
company called Vector AI focusing on
threats as they exist within AWS and gcp
not Azure don't talk to me about azure
so I work in the r d of the product
working to improve our capabilities of
detecting attacker behaviors on the
cloud control plane very cool stuff I
really enjoyed my job is is working in
the threat
the threat intersection between identity
and the cloud that's where I get to hang
out all day long and I love it
I was reflecting on my infosec career
last night and it came to the conclusion
that my career might sound a little
chaotic to some thinking about some of
the jobs that I've had in-house pen
testing
done a fair amount of capsic work
testing those in-house ppis and web apps
writing tickets and working with Dev
teams I've done a lot of security
architecture in the cloud for a Fortune
50 company and I worked on a security
architecture and engineering team
building the guardrails to support a
company's acceleration to the cloud and
then finally last year I made this
switch over from the proactive
preventative control side of the house
to the detective side
of the house where
partly because I I become a little
disillusioned with preventative controls
in the cloud
um I saw that those preventative
controls only took you so far they were
bound to fail so if you look at my talks
online you can see a lot of talks on
this limiting of the I am blast radius
I've done a ton of talks on permissions
and privilege escalation but now I'm
really focusing on
two
what happens when despite your best
efforts everything has failed and you
really really must detect what's
happening
so in my research I did focus on a set
of permissions that would allow an
attacker to acquire the ability to
perform certain behaviors I just went
right for what the business impact might
be and then what recovery steps might
happen
um
I should say
um don't be concerned if you didn't
catch anything the first time in this
talk
um the slides for this presentation will
certainly be made available but I also
published a white paper a few days ago
where all of this content is in this
white paper all this content and more
um that you could ever want to throw
swipe papers so you can find all of that
on my Twitter nightmare.js
um please feel free to take a look at
that and I'll publish a link to that
right after
the sock
so here's a perfectly reasonable
question
um that I think is healthy for all of us
to ask
um why would ransomware the
classroom
will it
have had appointments
to ask the questions
and I want to tell you how I've been
thinking about it
um I I look at ransomware clearly as a
financially motivated crime with the
goal to inhibit Business Systems in
order to extract The Ransom payment so
historically there's been plenty of
money to be made in ranciding data on
traditional on-prem systems
so for me the question is more about
will there be evolutionary pressure on
attackers to force them to evolve their
captives
um I'm not sure if there's a reason that
malware authors would need to redesign
their their malware if if the old ways
of doing
um but as I observe
um the volume and speed with which
Enterprises are undergoing Cloud
migrations
I mean they're they're full on ditching
the data center
I don't see how ransomware could not
become a larger problem for businesses
with Cloud hosted data
um so my thesis on the subject is that
wherever the the business critical data
goes
ransomware without
so when there's the moment that there's
the critical mass of business data in
the cloud this is when it makes
Financial sense for the attackers to
evolve their tactics to Target the
on-prem cloud I'm sorry to Target the
cloud versus on-prem systems
we can't think that attackers are going
to just leave money on the table
just because that you know your
organizations in the middle of a massive
Cloud migration and the attacker's old
you know word doc exploit isn't going to
work in the cloud anymore
um they're not going to just walk away
from the money
so this is kind of where my research
came into play
um
when I ask the question how should we
think about the characteristics of an
attack in the cloud
and then how can we compare and contrast
it to an on-prem event
attackers on the cloud plane
they don't have any Windows processes to
manipulate they don't have any
typically have any hosts to exploit
they don't have any unpatched exchange
servers
so what does this mean for an attacker
to gain control of a cloud native
application
in the cloud the available tools that
developers and customers need to
accomplish the everyday tasks
these are built-in Services they're
offered as features by the cloud service
providers
pools
to overcome security controls avoid
detection and accomplish specific goals
teachers with with ill intent is often
referred to as teachers
where future abuse is rather the
misuse of cloud native tools and the
apis created by the hard-working
developers at AWS at gcp
this this strikes me as not entirely
dissimilar to an on-prem attack where
malware is using
the utilities that spines right on its
infected systems to advance and spread
so living off the land techniques the
the LOL binaries in the cloud
they're not your sticky keys they're
they're the cloud apis themselves
feature Rich public open
in contrast to the windows executables
which can be uninstalled
as superfluous
AWS Cloud apis they're always on
they're open they're Cloud native and it
makes them very attractive for abusers
to misuse
not with your old crusty data warehouses
though those tried and true data
warehouses that many organizations are
rapidly running away from
you know these these on-prem servers are
typically full full stack environments
physical hosts
um however these these full stack
environments while they have a broad
attack surface
um they're generally secured by you know
20 years of understanding on how to
secure these environments
the decrease in the hands of a corporate
Network
they're heavily monitored by asian-based
tools
there's a corpus of understanding on how
to handle these Legacy systems
is this while there are
a large attack surface there's also a
large understanding on how we handle
threats face
[Music]
but this on-prem approach just a curing
traditional data centers your a host
based agents your you know
network based controls it doesn't
necessarily translate to the cloud
and I'm saying it they probably
shouldn't actually translate to the
cloud we should try to shoot hornet in
data was migrated to the cloud resides
in systems where the end users
including malicious actors
they're going to have limited curated
access to the Android
generally everybody just lives at layer
seven and this is a curated experience
from the CSP
this means that cloud data stores have
these dramatically different attack
services
and each of the major Cloud providers
has a ubiquitous cloud data store
S3 Azure blob gcp buckets but today on
my research I really focus on the AWS
S3 buckets
but
the attack the attacks I'm going to be
describing are not
unique to AWS
rather they're going to be
um pretty applicable to any Cloud where
you have a system
a data store
that could be encrypted and those
encrypted Keys encryption keys can be
restricted by some sort of conditional
access
that's the recipe that we're going to be
following
all right this is the point of my talk
where people's eyes might Blaze over I
appreciate we have to do a little
cryptography today a little bit just a
little bit
and
yeah in an effort to like compare and
contrast on-prem malware with
um cloud of rainforter and I thought
like what are the steps what are the
Hoops that
on-prem ransomware has to go through
necessarily
to perform their actions right
so ranting my targeting on-prem systems
they're going to have to use this hybrid
approach this hybrid encryption speaking
leveraging Both Worlds leveraging both
symmetric and asymmetric encryptions to
work around the limitations the
limitations of both asymmetric and
symmetric encryption so
where asymmetric encryption is really
slow
symmetric encryption is really fast yes
we want that
mother
symmetric encryption uses both the same
key though for encryption and decryption
so if you have just a purely symmetric
encryption strategy for encrypting your
targeted data right it might make it
easier by forensics teams to recover
that key if they're doing some some
forensics
so the strategy that ransomware authors
use to kind of work around this
limitation and these are the same
techniques that
your in-house cryptographic operators
your your crypto guys are going to use
day in Day Out
so whether for a benevolent or
malevolent intent key hierarchies are
used
um to derive one set of keys from
another to encrypt the symmetric keys
it's not necessary for this is necessary
not necessary for the cloud
infinite hacker leverages your csps Key
Management Service
these Cloud providers have done the
heavy lifting for you they're
maintaining secure routes of trust
and there's really no reason for
attackers not to piggyback on the
um the cryptographic niceties that are
provided by a CSP
all right so we're talking a lot about
KMS AWS KMS and it's a service that
allows AWS customers to generate keys
control access to these Keys using
perform cryptographic operations signing
verify
managing envelope encryption and
interestingly enough is also the process
for managing the keys that are used for
server-side encryption
ns3
so what I'm going to Showcase to you is
that just a really quick demo of two
buckets
you'll see an attacker who has gained a
significant permissions in an AWS
account
they're going to copy objects from one
bucket which I'll call the victim bucket
this is the bucket that they're
targeting for encryption they're going
to copy those objects to a staging
bucket
the object in the second bucket are
encrypted with a KMS key
that KMS key is under the attacker's
control
not available for use in the victims
account
so when he copies the objects over to
the second staging bucket
staring in KMS are going to server-side
encrypt those objects with the KMS key
that's controlled by the attacker
and I just wanted to show you briefly
what this looks like what the user
experience looks like
specifically when
when a customer no longer has access to
the underlying backing key when objects
are server-side encrypted with KMS
I was just looking at the bucket that um
yeah I'm sure case in here is that an
attacker has copied over objects to the
staging bucket again with a key that
only they control are our victim design
control
[Music]
I'm going to switch users over here to
our our victim account
somebody who doesn't have access to the
underlying backing key and I just want
to highlight to you the effect on
availability
okay they're going over to the staging
bucket
I tried to download an object yeah
there we go
access denied
it's hard to see you there let me see if
I can zoom in nope can't zoom in anyways
access and I
so our our victim account
very well may have to access the objects
very well they had access to the buckets
but that backing key they no longer they
don't have access to
um and AWS dutifully is not going to
give them access to those objects
okay so so what what happened here
um why
why was why were the keys unavailable
um
one of the mechanisms for controlling
access to these Keys is by defining a
resource-based policy
on the key
and as such defining a policy on the key
defining who is allowed and who is
denied access
that leaves our attacker the opportunity
to affect availability on the key and
effect availability on the objects
my research here and as I'll go more
into it it's really focusing on a key
policy lockout technique that was very
first described in 2020
by a gentleman called Spencer dietzen
from Rhino security so I highly
recommend you take a look at his talk
from well coming up on two years ago
where it goes into this specific
key policy a lockout technique on S3 and
also some other mechanisms for affecting
availability on dynamodb
uh so to recap the KMS key in the Target
account would
somehow need to become under the control
of an attacker either by the creation of
a new key as I described or maybe an
attacker has gained the ability to
update the resource policy and can
affect availability on an existing key
potentially
both of these mechanisms whether the key
is new whether the key is existing they
have the same lockout effect you are the
victim is locked out of their data
so we can expect these access denied
responses from AWS where requests
originate from callers that lack
explicit permissions to access both S3
objects and the KMS keys
one explicit denied permission on the
object or the key
S3 is not going to serve the data
uh the behavior that we saw in the
little in the demo there was something
that I call deny except when allow only
when
uh bring this out to two different
stages on a key policy deny all actions
on the KMS key
except
when the source IP addresses is mine the
attacker controlled IP
well and also by the way allow
only when
The Source IP is for my attacker
controlled IP
um so when updating the resource based
key policy attached to the KMS key
this is a pattern that you could
potentially see in
an attacker attempting to affect the
availability of any resource
and it would affect even the root user
even the user would be able unable to
access
the KMS key and thus the data
so this resource-based policy this is
actually the one that I use for my demo
and
I'm sure he's in the use of the IP
address condition to restrict access to
the canvas resource but you can imagine
there's some other conditions that might
be leveraged by our ransomware operator
looking to employ this pattern
um some other conditions they might use
Maybe
the AWS principal arm saying you can't
access this KMS key unless you're coming
from this specific AWS principle hard
and oh by the way that's an attacker
controlled principal account condition
Source VPC restriction or Source ABC
employee restriction
the lesson here is that any condition in
a policy where the value
is required by the caller
it's Unique and it's attacker controlled
that's when it can be leveraged to lock
out a customer from resource
so just like we can't presume to know
what
uh ransomware would look like in the
cloud what it would look like to impact
resources we can't presume to know what
the relinquishing of data would look
like
um what passing over that decryption key
would look like in the cloud so in the
cloud turning over the keys
to encrypted data would look just as
different as
techniques used for impact
so in the scenario that I laid out that
I demoed only callers from
the attacker-controlled account can
access the KMS key
right that locks up availability
but
to update that key policy again to
relinquish control
it can only it cannot be performed
cross-account so you're locked you're
stuck
now well authors are going to need a
real-time a viable mechanism for
returning control to the victim
and it can't involve updating that key
policy again it can't involve
bid hacker updating this policy across
account because that's just not allowed
in AWS
today I think of another way fortunately
I did for them okay uh
kmstagrams
um
so how might how about an attacker
um you know complete the life cycle
and and return data to the victim
um chemistry grants his possibilities so
it's an alternative Access Control
mechanism for KMS keys
use the delegate cryptographic
operations just because I've denied
access to the key and key policy
does it mean that somebody can generate
a
a key Grant token to say you know
oh actually by the way you can use the
key to encrypt or decrypt or sign or
verify or whatever
um
so
um
I can't miss key Grand would allow the
victim to access
their KMS key and begin the decryption
process without having to update that
key policy cross account which is
disallowed
I'm not psychic but I feel like
a few people in here have been wondering
what where where is AWS and all of this
like where could they have helped me
um
I think that's very valid I think we
should start talking about all of this
out loud if for nothing else but to
force their hand and saying what they
could or could not help us with
um
where's the shared responsibility in
fact where's the shared responsibility
model how does it factor in we don't
really know
um there's three potential
um scenarios that stand out for me and
that I think are worth talking out loud
about
the first scenario is
for an AWS intervention hypothesizes
that what if AWS could just go into
their data center go into their HSN and
break out that key material you need and
give to you
this feels like an absolutely ridiculous
thought
um you know
AWS KMS is a very serious service
created by very serious people and the
thought that that would be even
technically feasible
um you know I feel a little guilty even
hypothesized me about but I think it's
worth saying in case I was in anybody's
thoughts
um AWS has gone to Great Links to ensure
that no person
no system could retrieve that key
material
um and they make Earnest public
statements to that effect so I think the
first possibility is out of the question
[Music]
the next scenario is for an AWS
intervention are like much more of an
open question to me
um the First Avenue for assistance would
involve AWS
having the ability to change the victims
and
um
there's no evidence that ews Henry verse
a maliciously applied key policy
um
so restoring access to a KMS key there's
no indication that they can do that
there's no indication that they have
this this hand of God that they can
reach in and update
um and key policy and there's honestly
not much incentive
to publicly admit that they they could
if they did
the final the final bit of assisted
remediation that we've kind of ponder
um
is the idea that you know would ews have
the ability to commandeer
an account which the malicious actors
are operating out of
um
like the trustless AP team at AWS they
will quarantine accounts they will close
row accounts if they're violating in
terms of service
but quarantining
close accounts is much different than
seizing control of an account and you
would fully need to seize control over
that account and the resources and you
need to take over that account
um and there's there's actually some
evidence to suggest that they can do
that that they the that ability
technically exists
um so if anybody's familiar with the
mechanism to change the root email
address for your account change their
email address if you've forgotten the
password and MFA if anybody's ever been
lucky enough to be in that position yeah
AWS I own this account you have your own
email no do you have the root password
no do you have the root MFA sorry
um there is actually a process for
recovering your account if if all hope
seems to be lost
um you have to
um submit an affidavit notarize
affidavit to PWS
um in my experience it takes a couple
months they process it and they verify
that you own it and then they will
change the root email address to
something that you have control over
so this internal process
suggests that AWS does have the power to
seize control over our accounts not just
simply close them but restore
to access the resources house with them
with some sort of you know admin
capabilities
but similar to the hand of God Theory
it just tells you that they have a lot
of incentive to publicly admit this
from and and from a defender's point of
view
um from a GRC point of view from a legal
point of view from everybody in the
world point of view
um without a clear documented process
for assisted recovery from AWS
without guaranteed slas on a process
like any theoretical remediation
assistance from AWS is just not useful
so planning for response planning for
recovery from a ransomware event it
should not be centered
on the idea that ews
can help you
thumbs up we got some thumbs up we're
here we're there yes PWS cannot help you
know
Okay so
rooted in the understanding that it's
unlikely AWS could help during a
ransomware event we turn our sights to
the bread and butter of all Security
Programs preventative controls
and detection is Landscaping families
um
I'll start by underscoring that these
controls I'm going to go through
they are unlikely to be
compatible with highly transactional
data
but they could be feasible if you're
looking to secure your backups
you know secure your you know off sites
if your off-site backups are in the
cloud these are some controls that you
might want to look at nope but knowing
where your data is
and knowing which data you need to
secure
is the first step for enforcing any of
these Bucket Level controls so it goes
back down to asset manage
[Music]
um okay SV bucket configurations
because they said not all S3 buckets can
be configured to be a fortress
but it's worth noting the controls
available in S3 which can add to the
overall Ransom resiliency strategy
kind of a trifecta here of controls
S3 object lock
does exactly what you would imagine you
can't delete an object a big versioning
instead of
um
you know every time a new version of an
object is updated you don't replace the
old object you just create a million
versions of it so it can prevent
some delicious encryption and rewriting
your existing data and then the final
one I'll touch on is mfa's Elite so FFA
delete is a setting that says okay if
you really have to delete this data
you have to be using the root user and
that root user has to be using an MFS
so pretty high bar across in order to
delete some data
um kind of an architect at heart so I
kind of went overboard and talking about
the defense of architectural patterns
here
um mitigations via sap service control
policy
these are different require a certain
level of maturity
in your Cloud security program
so it doesn't mean that We should strive
for these goals but I fully don't expect
that everybody's going to be there on
day one
so a couple things we can
potentially create a bespoke SCP policy
that says
these are the only keys that are allowed
to perform cryptographic operations on
your keys
naming these specific keys and being
able to know which those which specific
Keys those are
that's a good start in preventing
cognitive ransomware
oftentimes oftentimes this type of
SCP is coupled with an architectural
pattern that like will Corral all of
your KMS Keys into a single account
this sort of creates this Fort Knox
approach to Key Management it creates
this
all of your eggs in one basket approach
but it also says all of your controls in
one basket all of your eyes in one
basket
so a centralized key management account
allows your security organization to a
force the principle of these privilege
and just the most extreme sense in a
very concentrated place it says that
here are here's the location where all
my keys live
yes it's a massive Target but yes we're
going to monitor the heck out of it and
do these privilege like we've never done
before right here
and it also allows for things like you
know bespoke sap to say
only keys out of this account can
perform good for graphic operations can
be pattern
some people hate it
it's fine
all right
have we miss remiss if I tend to leave
with some some signals you could latch
onto in your
um
in your environment to try to track down
someone's Behavior
the scenario I laid out had a threat
actor using a key policy lockout method
on a new KMS key
but also recognize is the possibility of
using that same motorcycle round eye on
an existing key
or even
maliciously encrypting S3 data with an
external key I didn't touch on that but
that's absolutely a possibility
um
so let's take a look at each three of
these scenarios
and talk about you know what what you
could find in cloud trail
that might tip you off to some unusual
behavior and might warrant investigation
okay
a key policy lockout with a new key
so if a threat actor employs this
technique there's a couple a couple
critical
pivot Points
that you could be alerted on and respond
to during this exploitation phase
um when when you're looking at a new key
so first off if your key if your
organization has a clear view into the
approved keys and all of a sudden a key
that's not approved or not known or out
of a weird account
alarm
Additionally the updating of the key
key policy to include one of these you
know
deny except when allow only when
conditional
patterns that's another potential point
for alerting
um
key policy lockup mechanism with an
existing key a little bit more tricky
because potentially if there's a
scenario where
you know you've done everything right
with your defensive architectural
patterns you have this list of approved
keys
and your attacker needs access to update
the policy with one of those approved
keys at that point what you're really
gonna kind of latch onto is the updating
of that key policy to
um a condition which would log out the
organization of their access in that
conditional lab
and then finally in another scenario
where you potentially encrypt data with
an external key
um you know security operations teams
would want to be notified when
um
these keys are being used that are
external
you know this really relies on you
having a fundamental idea on what is
external to your organization
um how do you how do you know it's
external and how do you know it's weird
if an external AWS account pops up
especially in the in the construct of a
KMS key
that requires
okay
in conclusion everything's on fire
that sort of
customers providers make available
services and apis which can be misused
and used and potentially leveraged by
ransomware gangs
as successful ransomware campaigns in
the cloud use cloud data services to
encrypt data that can affect
availability you can affect availability
with just built-in Access Control
mechanisms
no fancy key hierarchies required
drafting these these central fort
knox-like approaches to Key Management I
think is a good step
um to preventing Valor
um so it's it's Additionally the
organization's responsibility even in
those most highly restricted
environments to plan for the day when
there are these privileged guardrails
fail
um as such detecting if your Cloud also
data is impacted by ransomware it should
be a priority these detection techniques
Can Depend subtly depending on what
variant
of you know Cloud native ransomware
you're looking at whether or not they're
using an existing key a new key an
external key
it's all rooted under the understanding
that we need to know what's external to
your account and you need to know what
conditional policies would prevent you
from accessing a resource at a given
time
um if you need more on cloud native
ransomware there's
not a lot out there but what there is
out there is really really Choice it's
really foundational
um Scott Piper put together just this
comprehensive list on S3 mitigations
most of my
bits on
bucket configurations were from his blog
about a year ago so I highly recommend
checking out Scott Piper's blog
um and then I also gave Spencer a shout
out
um Spencer's talk uh the Cod Village in
2020.
um he talks a lot about
just keep policy lockout mechanism also
encrypting
um Sue data with client-side mechanisms
also affecting time in my DDP
dramatically dramatically change the
subject here
does anybody know what this is
safer cons use speaker badge
here um just want to let everybody know
the speaker badge is up for auction
for a good cause all benefits uh go to
the mcgizzy foundation
um uh charity in Minneapolis that
benefits youth uh in Minneapolis you can
go to that URL
and put in your auction auction ends at
the end of safer cons so I think
bidding's up to 250 last I checked so
this is a steal
fantastic cube right
I have a couple of minutes for questions
Commons concerns
stays concerned about Esther Vance Meyer
I will definitely take that no okay
thank you appreciate it
[Applause]
thank you
[Music]