start	end	text
0	4580	My name is Spencer Geetson, and today I'm going to be talking about ransomware in the cloud.
6320	12020	So, I'm a huge cloud nerd, so instead of the traditional Who Am I slide, I did an AWS
12020	21980	STS Git Caller Identity slide, which basically says what Jaren just shared. My name is Spencer
21980	26800	Geetson. I'm a cloud security researcher at CrowdStrike. I previously was a penetration
26800	33120	tester at Rhino Security Labs, and I've got an interest in technical writing, gaming,
33120	41320	and programming. So first I want to start off with an agenda. We'll talk about AWS basics,
41320	47540	just kind of a TLDR of the services and resources I'm going to go over. Ransomware in the cloud,
47540	52620	simple storage service for AWS S3, we're going to talk about ransomware techniques,
52620	58900	prevention, detection, and indicators. And then the same thing for DynamoDB techniques,
58900	64380	prevention, detection, and indicators. And then at the end, we're going to talk about
64380	70160	other potential targets, so other AWS services, other clouds, those kind of things, cloud provider
70160	75640	intervention, and other takeaways from the presentation, and then just some additional
75640	85780	resources and references at the end. So AWS basics. I imagine there's a wide range of skill
85780	93200	set in the audience, so you may know this, you may not. AWS S3 is just object storage in the
93200	100200	cloud. It's their offering. There's S3 buckets, which basically hold all your buckets of objects.
100200	106560	Objects are essentially files that are stored in buckets, and then there are bucket policies
106560	113840	which determine the access permissions and conditions that apply to a bucket and the
113840	121620	objects within it. And we'll get more into that later on. DynamoDB, this one's pretty simple for
121620	129040	our needs. It has tables. It's a NoSQL database offered by Amazon, and it has tables that hold
129040	134500	data. That's as much as you really need to know if you're not familiar with the service right now,
134500	141720	at least. Then there's KMS, Key Management Service. It has keys, which could be asymmetric
141720	148860	or symmetric keys, depending on your use case, and they're typically AWS managed.
149320	154940	They have key policies, which define who can use keys and what they can be used for,
154940	160720	etc. And that's kind of the rundown of the different resources and services that I'll be
160720	168140	talking about today. Ransomware in the cloud. I'm going to be comparing the state of ransomware
168140	175840	today to soon, essentially. Right now, there's traditional ransomware like Locky,
176680	183720	WastedLocker, things like those that target traditional infrastructure.
184260	191780	Cloud-native ransomware is on the way. There's none yet, or none publicly. We don't know what's
191780	197300	going on behind the scenes or in breaches that haven't been made public. But it's better to
197300	205220	get ahead of these things before it becomes a problem. It's better to be ready for them.
205840	210580	So traditional ransomware typically targets servers and workstations,
210580	215140	while cloud ransomware would be targeting cloud-native resources.
216340	220780	Traditionally, they're operating system dependent. Primarily, windows and active
220780	225320	directory environments are being targeted. Where in the cloud, it's going to be cloud
225320	230400	provider independent. We're focusing on AWS for this presentation, but all the concepts
230400	238260	can be applied to other cloud providers like Google Cloud and Microsoft Azure and others.
238800	243980	And then traditionally, they exploit zero-day or known vulnerabilities to spread and infect
243980	248820	their targets. Where in the cloud, it's none of that. It's just feature abuse. There's no
248820	255440	vulnerability abuse. It's just using features the way they were designed, essentially,
255440	262840	in a little bit of a malicious way. So with that, we'll dive into S3. There's three techniques
262840	266560	I'm going to cover. It doesn't mean they're the only three techniques, but these are three
266560	272980	notable ones, at least. Local encryption is the first technique. It's very slow compared to the
272980	280100	others, but it's got a critical impact. The detection likelihood, I rate it as likely.
280100	286100	But this is only if you have monitoring in your environment. If you aren't monitoring
286660	291000	what's going on in your environment, you're not going to catch this. This is for kind of a security
291000	297320	mature organization that it would be likely to detect. And so some of the defenses I'll go over
297320	303320	will help certain companies reach that point to where they can feel like they are going to detect
303320	310380	these attacks. Second method is cross-account KMS encryption. It's fast-ish, depending on the
310380	316220	size of the bucket you're targeting. It's got a high impact, and then it's unlikely to be detected
317000	325720	based on my rating. And the last, and probably the best method, as an attacker, from my point of
325720	332060	view, is the KMS key policy lockout method. It's instant because it's a single API call.
332060	338080	It's got high impact, and it's very unlikely to detect because it's a single API call. You might
338080	341780	be able to detect it after it's happened, but you're not going to be able to prevent it if you
341780	351000	don't have the correct defenses in place. So for the first method, local encryption,
352060	357240	obviously we're going to locate a target bucket. We're going to download each file in the bucket,
357240	362420	and we're going to locally encrypt each of those files with something like AES-256,
362420	368320	you know, if you're going to be basic. Upload each of those encrypted files back to the bucket.
368620	373680	Or, in theory, you could just delete all the files from the bucket and keep your local copies,
373680	381540	depending on the size of the bucket, because by the time you have access, you could just release
381540	385580	it rather than encrypt it or something like that as the attacker. So there's a lot of different
385580	391720	routes here, but for this route, essentially we're just downloading from a bucket, as you can see
391720	398700	here, AES-256 encrypting, and then re-uploading over the top of the original file. So I wrote a
398700	406480	one-liner command here to demonstrate the concept. It looks a little convoluted, but highlighted some
406480	412080	of the important parts here. Essentially, in red, we're exporting an environment variable bucket
412080	419380	equal to our target bucket. Then we're using the AWS CLI, so list objects for that bucket. We're
419380	425320	getting a list of all the objects that are stored in there. We're piping that list into jq, which is
425460	431120	a JSON parser, and essentially it's just grabbing the names of all those objects. We don't care
431120	436520	about the rest right now, but the rest of their properties. We're piping all those names into
436520	444120	xrs. We're saying each name should run this... the following command should be run for each name,
444120	449040	and then wherever there's an open-close bracket in the following command, it should be replaced
449040	455560	with the current object name. So essentially, we're running sh-c, here's this open quote, and
455560	462640	at the very end is the close quote. We're running this entire thing for each name of an object in
462640	470800	the bucket. In the red, it's going to be awss3cp, which is copy. We're copying it from our target
470800	478920	bucket at the current key, object key, into standard in. Now we're piping the result of that into openssl,
478920	486640	which we're using to aes256 encrypt the data, and then base64 encoding it. We're piping that data
486640	495560	into another awss3 copy command, but this time it's from standard in into s3, or at that bucket,
495560	500400	at that object. So we're just overriding the original object with an encrypted version of the
500400	507760	object. So now even if the target user has s3 permissions to read those objects, they're going
507760	512300	to get access denied because they don't have access... or well, I guess they won't get access
512300	516620	denied. They just won't be able to read the contents because it's encrypted with your password.
517420	521500	So essentially they would have to pay the ransom, and you give them the password,
521500	523140	and then they can decrypt all their data.
525540	529200	So the next method is cross-account KMS encryption.
532360	538540	Essentially you need an attacker AWS account for this one. You create a KMS key in that attacker
538540	546140	AWS account. You modify the key policy to allow cross-account access to your target account,
546640	553660	but only the encrypt permission and nothing else. So not the decrypt permission, especially.
553860	559640	Next we're going to locate a target bucket, and we're going to use the s3 copy command to copy
559640	566480	each object from itself to itself, which also s3 batch allows you to do at a greater scale
567400	572640	without having to automate it yourself. And we're going to be specifying the KMS encryption key as
572640	578240	the key we just created in step one. So I wrote another one-liner for this one. Again,
578240	582280	it's a little convoluted, but this one's a little easier to understand.
583400	588600	Pretty much everything is the same. We're getting the list of objects, the name of those objects,
588600	594960	passing that into xargs in this shell command. But the shell command this time is AWS s3 copy
595660	601320	from the s3 bucket of that object to the s3 bucket of that object. So basically just on top
601320	609020	of itself. We're passing in SSE KMS key ID, and we're giving it our malicious key ID. So it's
609020	613520	just encrypting each object in the bucket with our key instead of whatever it's currently encrypted
613520	620220	or not encrypted with. And lucky for us, this is done on the server side, this copy, because it's
620220	626040	s3 to s3, so we don't need to worry about our own upload and download speed like we would with the
626770	631940	local encryption method. So this might be a better method for when there's larger files
632470	636840	in the bucket that you don't want to be downloading terabytes of data to your
636840	646050	system. You probably can't even. So the third method is KMS key policy lockout.
646230	654470	This is my favorite method and probably the scariest method. So I'll get into why shortly.
655290	659330	In this we're going to need our own attacker account again. This time we're going to allocate
659330	667270	an elastic IP in there, and this is because there are a lot of restrictions on cross-account actions
667270	673470	for KMS keys. So you can't update the policy of a KMS key cross-account, you can't disable a key
673470	680490	cross-account, and you can't delete a key cross-account. So we have to do some trickery with
680490	687450	conditions in the KMS key policy to actually lock the owner out. And again, I say the owner
687450	693570	because we're targeting a key that our target owns. It's not our attacker key or anything like that.
695310	701610	So we'll locate a target bucket and our target has to have a customer master key assigned to it
701610	706290	as the default encryption method, or at least the objects in the bucket have to be encrypted
706290	713470	with a customer master key. It can't be the default S3 KMS key and it can't be unencrypted
713470	719570	because we're targeting the actual key behind the encryption which requires it to be a customer
719570	725870	master key. Otherwise we can't mess with the policy. We're going to update the key policy
725870	733590	of that KMS key to deny access to anything about it unless it's originating from your elastic IP
733590	741910	address. So essentially no one can use the key unless they have control of the elastic IP address
741910	749930	which you have control of the attacker. Then you demand ransom plus you know keys to unlock so you
749930	755250	could have them give you keys that have put key policy on the key and you could use your elastic
755250	763070	IP to restore their key policy or you can transfer them the IP allocated. It's a little risky because
763070	767150	you would have to unallocate it in your own account then they would have to request it to be
767150	771790	allocated in their account which if the timing doesn't match up they might miss it and another
771790	779490	customer might randomly get it in AWS and at that point who knows what would happen.
781550	785530	So another one-liner, this one doesn't look very simple because it's got a whole bunch of JSON in
785530	793870	it but it's just a single command. So AWS CLI KMS put key policy pass in the target key ID for
793870	799490	the key we want to target obviously. The policy name is always going to be default
800690	806210	and then we're passing in a JSON policy which I have formatted to make it a little bit easier to
806210	814630	read. For those of you who aren't aware of how policies work or the structure of them in AWS
814630	820350	I'll kind of go over this. So there are two statements that are declaring something about
820350	828830	the key. The first one is deny access to this principle which is everyone. Deny anyone from
828830	835850	doing any KMS action on any resource under the condition that they're not coming from
835850	842450	our Elastic IP address. So essentially if you aren't coming from our IP deny access to everything.
843250	849770	Then the next statement is saying allow access to our target account's root user
850340	855950	to do any KMS action on any resource under the condition that they're coming from our Elastic IP
855950	861590	address. So overall this is saying if you're not coming from our Elastic IP you're blocked from
861590	868170	everything. If you are and you're coming from the target account then you have access to do things.
868710	874430	So what this means is because we have access or because we own the Elastic IP it's up to us to
874430	880850	grant access to the target account where then they can update the policy and essentially gain access
880850	886910	to their data again because this will deny them from using the decrypt permission which they need
886910	893030	to obviously decrypt any data. Another reason this is kind of scary is because this could
893030	900310	go across to multiple S3 buckets. In theory the same KMS key could be applied to three or four
900310	906330	different S3 buckets. So if you ransom the key policy you've hit all of those buckets with it
906330	918210	with one API call. So it's suddenly a very much more valuable attack for you. So S3 defenses.
918210	924070	We're going to talk about prevention and detection. They're both very important. In terms of
924070	930010	prevention, easy one is just follow the principle of least privilege. This applies to KMS key
930010	935730	policies, S3 bucket policies, and the IAM privileges you're granting to your users and
935730	943510	roles for those specific services. Off-site backups. So of course online backups are good.
943510	949450	Maybe cross account or something like that. But off-site is good because even if you get
949450	954190	ransomware and you lose access to your data, you can just restore from something completely
954190	960570	unrelated. Organization service control policies are important. They're going to be customized
960570	964730	to your environment. So I'm not going to go over any specific examples, but they can be used to
964730	972510	enforce specific conditions and restrict certain permissions that may prevent or at least help
972510	982530	detect a ransomware attack. S3 object versioning with MFA delete. It's very important. So object
982530	988210	versioning makes it so that instead of your files getting overwritten when a new one with the same
988210	994550	name is uploaded, it creates a new version. So if the attacker tried to do a local encrypt attack
994550	1000630	and uploaded their encrypted version over the top of an existing version, both versions would still
1000630	1004890	exist and the defender could just delete the latest version, which is the encrypted version,
1005250	1009610	and then restore the original version and still have access to all their data.
1010350	1016970	But this is why MFA delete is important because an attacker could also just delete object versions
1016970	1021730	if they had the permissions to do so. So they delete the old version and the only version left
1021730	1027950	is the encrypted version. But with MFA delete, it requires you to have an active MFA device to
1027950	1033510	delete objects and to disable object versioning. So in both cases, the attacker is going to be
1033510	1040590	locked out. In most cases, they're not going to have access to an active MFA device,
1040590	1045730	even if they've already bypassed MFA in the console or something along those lines.
1048010	1052690	Another good defense is a bucket policy that enforces a specific KMS key. This will prevent
1052690	1059230	the cross-account KMS encryption method. Here's an example bucket policy. We're denying anybody
1059810	1067090	from using S3 put object to our bucket under the condition the encryption key is not this one here.
1067090	1073470	So if someone tries to upload an object to our bucket and they specify an encryption key that is
1073470	1078650	not this one that we've whitelisted, it's going to get access denied. And so this will prevent the
1078650	1082750	cross-account attacker key from getting applied to any of our objects.
1084630	1091770	In terms of detection, there's going to be S3 access logging and CloudTrail S3 data event logging.
1091770	1096610	These are both pretty similar and give you visibility into the actual actions taking
1096610	1102550	place within a bucket versus on a bucket. So this is like object level activity, essentially.
1103130	1108010	They have slight differences, so it's worth looking into the comparison between the two
1108010	1115250	and seeing which one you want or both, maybe. Another important thing is CloudTrail management
1115250	1121610	event logging. You can hopefully trace the attack path through your environment and maybe
1122470	1127070	kick them out before they start ransoming your buckets or something like that.
1127710	1132490	CloudTrail KMS event logging is good, too, because you can see when maybe there's a high amount of
1132490	1138430	decrypts going on, you can take that as an indicator that someone is reading lots of objects
1138430	1144470	or something along those lines, which could be them downloading to locally encrypt and maybe
1144470	1152230	you stop them before they re-upload. GuardDuty with S3 ingestion enabled. S3 ingestion was just
1152230	1159150	released last week, I believe, and it is a great feature that's been added. It'll allow you to
1159150	1165570	catch things like a Tor IP address interacting with your S3 buckets, so it'll make it easier to
1167130	1174030	pull out malicious activity from your buckets compared to traditional activity or normal activity.
1175810	1183430	In terms of indicators for S3, STS get caller identity, kind of like my Who Am I slide. This is
1183430	1191350	Who Am I of the cloud, and you don't necessarily need to alert on this call because there are a lot
1191350	1198330	of legitimate use cases, like EKS pods won't use it, I believe HashCorp Vault uses it, and then
1198330	1205650	sometimes developers just need to do it themselves, but attackers will often use this, too, to identify
1205650	1212250	who they are before expanding into the environment. So if you can create a baseline of what's normal
1212250	1219310	and then alert on what's abnormal, this would be a good one to look into. Another obvious one is S3
1219310	1224570	list all my buckets. That's going to be used legitimately all the time, but if you could somehow
1224570	1228510	identify when it's being used maliciously, it's going to be a really good one because
1229510	1234750	this will probably be run before any ransomware attack unless they already have a bucket name,
1234850	1239350	a target, or something along those lines. Maybe you pair it up with get caller identity,
1239350	1244670	so you see get caller identity and then shortly after list all my buckets, that could
1244670	1251870	be somewhat of an indicator and at least worth looking into. Attempts to disable object versioning
1251870	1258510	on an S3 bucket and attempts to delete object versions in a bucket. An attacker could do this
1258510	1263610	if they identified a bucket that has versioning enabled, they could disable it, and then they
1263610	1268450	could go in and delete all the old versions and then make it so that the latest version
1268450	1275310	is their encrypted file or encrypted object so it'd be just the same as if versioning was disabled.
1276810	1283170	Attempts to disable S3 access logging to remove your visibility into the HTTP requests
1283170	1290250	that are going on within your bucket. KMS key policy modifications. If it's the last
1290250	1296390	KMS key policy lockout method, this is going to, or alerting on these modifications,
1296390	1302450	it's going to be too late, but better late than never, I would say. You want to know
1302450	1309190	when this stuff happens even if you weren't able to prevent it. S3 bucket policy modifications
1309190	1315550	and S3 bucket ACL modifications. You want to know when your bucket gets granted cross-account access
1315550	1321530	or public access, of course, but then if you're enforcing a specific KMS key in your policy
1321530	1326970	for object uploads, an attacker could identify that and delete the bucket policy so that they
1326970	1331990	can use their cross-account key. So this might be somewhere, again, where service control policies
1331990	1337170	come into place and can prevent that kind of activity if you know you're not going to need
1337170	1347450	that to be going on. High volume of S3 object downloads and uploads. If it's above your baseline,
1347450	1351990	it might be worth looking into. Maybe someone's exfiltrating all the data in your bucket or
1351990	1358750	they're downloading it for local encryption or something along those lines. A typical S3 batch
1358750	1365110	usage. So like I talked about before, S3 batch could be used for the cross-account KMS key method.
1366070	1371090	And so if you don't use S3 batch at all and then all of a sudden you see some jobs kicked off,
1371090	1375670	that could be alarming and maybe you can stop those jobs before they complete and fully
1376190	1383270	take control of your data. Guard duty alerts, again, those are great to look into and just
1383870	1387690	great in general in terms of identifying compromise in your environment.
1388870	1396370	So with that, we're going to be diving into DynamoDB. We'll cover three techniques again,
1396370	1402570	and it doesn't mean they're the only three techniques, but maybe surprisingly or not,
1402570	1408290	they're the same three methods. Local encryption, cross-account KMS encryption, and key policy
1408290	1414490	lockout. They're a little bit different. They're done a little bit differently though.
1414870	1421950	So for local encryption, we've got located the target table. We're going to export the entire
1421950	1429630	table using the scan API, which is essentially just scan the table for data and download it.
1430190	1434770	But we need to be careful hitting the read capacity of the table because we may cause
1434890	1440410	a denial of service in the environment if we use up the read capacity, and that could trigger some
1440410	1445550	alerts that then get us kicked out of the environment before we've actually downloaded
1445550	1451310	any data or much data. Then we're going to locally encrypt the downloaded data with something like
1451310	1457470	AES-256 again. We're going to overwrite the table's data with the encrypted data. So you can see
1458070	1463910	target table, we scan it, locally encrypt it, and then use batch write item to write it back into
1463910	1470010	the table. Alternatively, we could use get item and put item to encrypt items one at a time,
1470010	1474990	but that would likely be much slower and there would be many more events for your actions than
1474990	1483330	otherwise. Not so simple one-liner. I didn't write a one-liner for this one because the scan API
1483330	1490750	returns a maximum of one megabyte of data per call. So that means you have to paginate the results,
1490750	1498350	but essentially that's hard to do on the CLI. It's done a little bit funky and so
1499070	1504750	I just didn't write one for this. It would be much easier to just write a quick Python
1504750	1508330	script or something along those lines if you were going to try and abuse this method.
1510230	1516890	So the next method for DynoDB is the cross-account KMS encryption method. We're going to create KMS
1516890	1522210	key in our own attacker account like we did before for S3. We're going to configure that key policy
1522210	1529030	to grant full access to the key cross-account to our target account. It's not going to let us apply
1529030	1533890	the key to that table, to our target table essentially, unless you perform this step
1533890	1538310	because there are a few different permissions that are required to successfully apply the key.
1542790	1550250	So then you locate your target table. You modify the table and change the KMS key that's applied
1550250	1555750	to it to be the key that you just created. It takes a minute to update, so you just wait for
1555750	1561350	that for it to finish updating. Then you go into your own account and modify the KMS key policy
1561350	1570690	to remove that cross-account access. So now, in theory, their DynamoDB database table has
1570690	1578270	your encryption key applied to it and they don't have decrypt permission for that key. So if they
1578270	1582810	try to view their table or the data within it, they're going to get non-authorized, as you can
1582810	1590770	see here. Additionally, if they try and change the KMS key that's applied to the table, they're
1590770	1595990	going to get access denied because it requires you to be able to decrypt the data of the table to
1595990	1600570	then re-encrypt it with something else. So you essentially have full control of the table until
1602150	1603920	you grant them access again.
1606830	1613230	So the third method, KMS key policy lockout, is essentially the exact same method as S3.
1613370	1619690	And it's another reason why this technique is even more risky than we talked about before,
1619690	1626290	because like I said, it could be applied to multiple S3 buckets at once, but then also,
1626290	1632510	in theory, it could be applied to one or more DynamoDB tables. So a single key policy ransom
1632510	1638190	attack could hit, you know, three, four, five DynamoDB tables and a bunch of S3 buckets.
1638390	1641330	Not that that's good practice, they should be applied to all those, but
1641930	1648590	not everyone follows best practices. And so it's something to be aware of and hopefully prevent.
1650850	1655850	In terms of defenses for DynamoDB, we'll do prevention and detection again.
1656590	1662930	And again, the easy one, follow the principle of least privilege for KMS, key policies, and then
1662930	1668130	IAM permissions for DynamoDB and KMS applied to your users and roles.
1669610	1676550	AWS backups. So you want to use the backup feature of DynamoDB to create snapshots of your
1676550	1685170	data, essentially, on some time period that you've set up. Offsite backups, those are important
1685170	1690770	too, because an attacker, in theory, could just delete all your backups that are in AWS and then
1690770	1695730	delete the database itself, and then there's no data anymore. Offsite backups could help prevent
1695730	1702270	that, because you can just restore. And again, organization service control policies. I love
1702270	1706950	these. There's lots you can do with them. And if you're not familiar, I really highly suggest
1707470	1712490	looking into them and applying them to your organization. But again, they're going to be
1712490	1720410	very customized. Use VPC endpoints for access. So essentially require your users to be within
1720410	1727910	your VPC to access your DynamoDB tables. So that means an attacker would need to compromise your
1727910	1734150	network prior to ransoming a DynamoDB table, which if they can do that, you're going to have
1734150	1742070	far greater problems anyways. So it's a good practice to do this. And don't just let the
1742070	1749590	entire internet access your table if they're aware of it. Point-in-time recovery. This is one I did
1749590	1754710	have on here as a prevention, but as I did further testing, I found out it didn't actually work.
1754710	1762130	So point-in-time recovery keeps snapshots over time in your database. And essentially,
1762130	1768070	it allows you to go back to a specific time in the past. But what I found is if you enable it,
1768070	1775230	and then you wait a little while, maybe mess with the data, then you apply a ransom KMS key to it,
1776510	1781950	then you use point-in-time recovery to recover before that key was applied, it still doesn't
1781950	1788350	work. It seems to be successful, and it starts creating the restored database, but then it just
1788350	1794670	disappears from the console, and there's no trace of it. So my guess is that it just can't get to
1794670	1800150	the data because it encrypted it all with the new key instead of the key that was present at the
1800150	1807890	time. For detection, Cloud Trail Management event logging, again, very useful. KMS event
1807890	1814370	logging, very useful. Guard duty, always very useful. CloudWatch alarms, you can use these to
1814370	1819550	monitor the read and write capacity of your tables, so you know if there's a huge amount of reads or
1819670	1827310	a huge amount of writes to your tables and could alert off of that. DynamoDB streams, scan, get
1827310	1832330	item, and put item, and I think some others are not, or they're considered data events, so they're
1832330	1840270	not logged by Cloud Trail. So you can use DynamoDB streams to stream those data events to a
1840270	1846070	Lambda function and respond to them however you want, so that can be a way to monitor that
1846070	1852730	data level activity. And maybe you can use AWS config to track changes to your tables, but usually
1852730	1860310	this will be too late by the time it alerts you of anything. Indicators to look out for, again,
1860310	1867470	STS get caller identity, KMS key policy modifications, high volume of table reads and writes,
1868090	1874630	attempts to delete backups, guard duty alerts, attempts to increase the table's read capacity.
1874630	1879870	If they find a large table that has a low read capacity, they might increase the read capacity
1879870	1885210	so that they can run parallel queries and download the entire database quickly without causing a
1885210	1892130	service in the environment. And that's kind of it for DynamoDB. I'm running out of time,
1892130	1898350	so I'm trying to speed through a couple of these. Other potential targets, so there could be Elastic
1898350	1904590	Walkstore and AWS, you can encrypt volumes or snapshots, relational database service,
1904590	1910210	or RDS database and snapshots, Lambda function code and environment variables,
1910210	1918730	secrets manager secrets, SNS topics, SQS queues, ECR repositories and images, which just got
1918730	1925570	released last week, I believe, EFS file systems, and more. And then you can even do it for other
1925570	1929550	cloud providers, but like I said earlier, we didn't dive into that, but something like Google
1929550	1936470	Storage could be done the same way as S3. So cloud provider intervention and other takeaways.
1936470	1940910	We don't know what a cloud provider could do to help you if you got targeted, so you can't rely
1940910	1946590	on them for that. So you need to act as if they would not be able to help you under any condition.
1946730	1949510	They can't help you with the local encryption anyways, because they're not going to know the
1949510	1955110	password to your encrypted data. This means you need to evaluate your own defenses. You need to
1955110	1961630	take care of your environment, monitor it, respond to things. You can't rely on the unknown,
1961630	1965210	essentially. Can you keep attackers out of your environment? Can you prevent
1965210	1970250	attackers from doing things once they're in your environment? Can you detect when they're
1970250	1976170	doing things once they're in your environment? Can you match those detections to patterns?
1976610	1981330	Can you tell that maybe a ransomware attack's coming because of these few API calls made in
1981390	1986330	a row or something along those lines? And additionally, you need to ask,
1986330	1991170	can I get back online after an attack? Am I ready? Do I know what to do if I got hit with
1991270	1994650	a ransomware attack? If the answer is no, then you've got some work to do.
1995610	2000330	And then how fast? Is it going to be fast enough before there's a major business impact?
2000510	2004550	How much money are you going to lose in the meantime? It's a big, big question.
2005070	2010290	And finally, the last big takeaway is, what if the attacker never decrypts your data?
2010950	2014690	For some reason, what if you just can't get access? I mean, they are criminals.
2014690	2018390	You can't necessarily trust them. Just because you pay them doesn't mean they're going to
2018390	2023890	decrypt your data. So could you handle that? Are you going to go out of business?
2024870	2028150	What's going to happen? That's something you need to think about.
2029050	2034490	That kind of wraps things up. I have a slide here just of some additional resources and references.
2035790	2040610	First one I always want to talk about is AWS documentation. I read that like it's the Bible.
2041750	2045030	There are so many great things in there, and it's an easy way to learn
2045430	2051770	in-depth about features of AWS that you might not know otherwise. So I'm constantly reading that.
2051830	2056070	And then I wrote two blog posts on S3 ransomware in particular,
2056070	2059150	while I ran a security labs. You can check those out.
2060010	2064790	I want to give a special thanks to my team at CrowdStrike, just for helping with the
2064790	2071910	presentation and the research, and giving me some feedback on that. Houston Hopkins from Capital One
2071910	2078510	for some help with the one-liner commands and some cool tricks with the AWS CLI. And
2078510	2084430	Rhino Security Labs for that previous research into ransomware and just AWS security in general.
2085370	2090650	In the bottom right, you can see my Twitter handle there for if there's not sure how much time left
2090650	2095090	we have for questions, but if there are any that don't get answered, feel free to reach out to me
2095090	2100670	on there. But for that, I'll go ahead and just kind of open up and answer any questions that
2100670	2106510	might be in the chat. Is object versioning and MFA delete good enough, or were you saying that
2106510	2114130	you need to implement and do all five of those things? I think that object versioning and MFA
2114130	2123130	delete are good for a couple of methods, but if you think of it like a local encryption method,
2123130	2128290	if you downloaded the objects from the bucket, their threat could be we're going to release all
2128290	2135710	this data. And so then versioning and MFA delete wouldn't do it. I like to always just follow
2135710	2143050	defense in depth and implement as much as you can. Then it's hard to take into account
2143050	2149730	the cost though, and then the work and changes that applies to your environment. But there's
2149730	2153970	some of the best defenses, but it definitely won't protect you from everything essentially.
2154570	2161130	Got it. And the second question from Skybound, I think you touched on this a little bit towards
2161130	2168050	the end. For recovery in cases where decryption keys are within AWS, would AWS be able to help
2168050	2174610	with their recovery and deal with the attacker? For example, with the KMS policy, basically
2174610	2181250	expecting AWS to adjust the KMS policy so that the customer can get access back.
2181890	2188970	So that's kind of where I was touching on. We don't know for sure. And then it brings up
2188970	2195790	the question of how fast, you know, maybe it takes a support case and then a day or two goes by or
2195790	2202010	something like that. And it's already, there's already a huge impact. I would say until there's
2202010	2206750	an official statement or something along those lines, not that there needs to be one necessarily,
2206750	2212590	but implementing your own defenses and detections is the way to go instead of relying
2212590	2216310	on them to take care of you in the event that something goes wrong.