How Attackers Can Use KMS To Ransomware S3 Buckets

so uh hello everybody happy to be here for another year thank you Rio and Paulina for actually making this possible and thank you all for being here so today I will be talking about something that we albanians love a lot gaining money illegally and you know doing that using using ransomware so uh this uh this is actually even though I'm presenting this uh this talk this is actually a joint research that uh the whole priso uh P zero team actually contributed on so you know even though I am the one presenting it practically everyone in the team worked on that so shout out to to them first of all uh my handle is uh glasses boy my pronounce are he him my U

I am a security researcher on um on permisso cloud security researcher on permisso and uh yes you can find my blog and my uh email you know for some fishing uh so uh let's take a scenario in mind let's presume that we have a group of threat actors they are a non Nation funded group they don't have money well they have some they don't have a really put out infrastructure something that can handle a lot of data and they want to get money so they they are only financially motivated they don't care about activism they don't care about anything else they don't care about disrupting stuff they just want to get money uh the and the the best way they

want to do that they think the best way to do that is by Ransom wearing a Target because it's it's easy you run somewhere them you you get the money you you just you know you you want uh what is a ransomware in in itself R ransomware is actually uh a digital kidnapping in some way you you basically just grab the data you keep them you don't you don't give them back unless they pay you for that it's it's a it's a random and uh on a on a normal ransomware you will get access to the data you will download the data because you need them later on to uh to sell if they don't pay the The

Ransom you encrypt them you reupload them or you probably delete them and upload them somewhere else and uh you ask for the ransom if they pay you you might give them back the data uh honestly you uh so s S3 is the AWS uh online storage you know in in the most basic terms um for S3 you have to you you can think uh the ransomware on S3 basically the same way as a ransomware on a non premise server You Again download the data encrypt them upload them back and you uh you know you ask for the random the problem with this the the problem with this is actually the storage cost let's say that we're talking about a

company with hundreds thousands of terabytes of data our attackers don't have the money to to keep all this data plus it's also the the problem with the with the logging if they have uh configured logging for buckets during this whole download and it's going to take a lot of time they will have uh you know they they they might even get caught so they they have to download them they might get caught on that when they uh encryp the data and when they try to to upload it back they they will not be able to do that because they got cut so they need to find a way to to encrypt the data directly and do that

without having too much storage for for themselves they do that so what uh a good way is to use the KMS encryption KMS so uh is a service on AWS that allows uh ews to manage the encryption keys for you so uh you you don't need to create a key whether that's a symmetric or an asymmetric key you just use the service there and you can encrypt different datas one of which is S3 uh it's basically the same thing as encrypting in decrypting data for uh you know using a plain text key but in this case you are just asking the the AWS for the key and then encrypting the the data they also have something

that is called a key policy actually almost every resource in in AWS has what is called the resource policy which defines which identities have access to the resource the policies are kind of a mess even though people think they easy in AWS because AWS has what it's called the I am policy which defines what access uh an identity will have on other resources and the resource policy which defines which identi which identities will have access to this to to the specific resource uh they they have to match both of them have to match so if an identity has full access on KMS but the resource policy has denied access to this uh to this resource the identity

will not have access to the resource even though the am policy allows that so you know that's the complication on that and another thing with uh KMS policy is that if you lock the key so if you don't give anyone access or if you give just a couple identities access no other identity even the root uh the root account which is the most uh privileged uh sort of identity in AWS will not have access to that so they can use that they can just uh and yes sorry and uh of course S3 can be encrypted with with a key they you just have to to configure the S3 uh bucket to encrypt all the objects using uh S3 now uh this attack

actually helps uh the the attackers because right now they don't have to download the data anymore they can literally just configure the bucket to have the encryption and then just basically reupload the data but they they can do that one by one uh directly without having a storage internally so they don't have to have their own storage the data is directly encrypted on the bucket meaning uh right now if they create a key they lock the key they encrypt the data they literally have reached the the first part of the ransomware they can just ask for the for the uh for the ransom the problem with with this is that the key will still be

inside the company even though the uh you know the the key is locked it will still be inside the company so one identity will always have access to the key of course because that identity which is the compromised one is the one that did the uh the um the the whole encryption uh one thing you you have to to realize is that if you look the key all the identities don't even know which identity has access but you can do that you can you can literally just uh Brute Force every identity on the on the infrastructure and then find out which identity has access to that you can you can literally just get all the users get

all the roles just create uh credentials for both so for the users you create the credentials for the roles you you literally assume them and then try to access the key and the way to find the key is is that if you go to the to the ews console you will find an error there that says you don't have access to read the key so you will have the IDE of the key and that's all so you can do that you can just try to access the key and you will find the identity that has a key so the the attackers cannot run somewhere uh a target with a key that is inside their that their targets uh

company even though it is it is locked another one is looking for cloud uh Cloud logs if they have configured logs they will not which uh which identity has access because they will look at the logs now again continuing that let's say that they have access to stop the the logs presumably and they they can create the the next part the the identity part is uh solved by creating uh an identity with a very complicated name and uh AWS is very generous to people it allows a 64 characters username with a lot of characters you know allowed so you can make a a username that is I wouldn't say impossible to break but it's very hard

to break encrypt then delete the user by doing that the com the target will not know which identity did that because it will not be inside the company it will not be on the logs because you sto the logs and you uh it will not they will not be able to know which identity has access to the key because they don't can't see the the key content again we have another issue first of all for the cloud trail even if you stop them there is something called uh an event history on uh on AWS which is uh it keeps the logs for the uh last 90 days even if cloud trail is is disabled it will still

keep the logs for 90 days meaning you will still have the logs there and aside from that aside from that deleting a user this one was strange actually but if you create a user you allow uh the KMS to to have uh the you allow the identity have to have access to the key you delete the user you recreate the user with the same name they will not have access I don't know why that is probably it's some sort of backend ID that will be autogenerated but it's very strange that you come to that and at this point you will reach data distraction but you will not be able to re uh decrypt them so this is again a a noo for the uh for

for the attackers what they can do is use something called uh kmsk key uh cross account share so onws uh and I guess this is for go uh for um compliance uh measures you can create a key on one account and then use it on the on the other account and uh you know only this account will have access to this and every identity that will be allowed on the second account they will be the only ones that will have access to the to the key and that is done using the ks policy meaning the attacker can create an AWS account they can allow the target account to have access with the KMS policy they can use the compromised

key to encryp the uh the data they can change the KMS policy and right now if they rechange the the uh the C policy they will be they will allow the identity to decrypt but as long as they don't change it they will not allow so basically you are locking a door with someone else's key which is yeah now uh uh there is there is an a problem with this tack though if you configure a bucket to encrypt all the objects using a KMS key the uh the identity that uploads the data to the bucket will not be able to upload the data anymore because they cannot upload the data unless they are uh encrypted and they

don't have access to encryp the data so right now they are stuck because uh they they they cannot uh get other future data so if they if they attack a company before sensitive data is being uploaded to to a bucket or before the so before other sensitive data is being uploaded they will not be able to get them uh that can be solved by what is called the object uh encryption configuration so instead of encrypting the whole bucket you encrypt each file with a specific key right now and uh the target will be able to upload files but the previous files will be encrypted so they they will be able to upload new unencrypted files and uh the attacker

can can create a schedule script that will always just reencrypt the data reencrypt reencrypt until they get caught or they just you know stop and then start to ask for the ransom which is a very very very well uh thing because it also allows the attacker to also put a ransom uh note inside the bucket which is unencrypted contrary to the to the other scenario they again suffer bottleneck uh they presumably of course uh are uh targeting an account which is part of of an organization and the organization does not allow any resource to be to be accessed which is outside this organization and of course the attacker account is outside this organization meaning they will not be

able to do that if they want to so they will need to find a way to bypass this and still encrypt the data without using a key inside the the targets uh account and they do that using practically the you know the the equivalent of the first ransomware scenario that we said they can create a key on their own account they can get each file encrypted uploaded deleted right now they don't have to have have um they do not have to have the uh the data stored in their own storage they can just download the file encrypt it put it back delete it and they will still have access to to decrypt the data because the key is in

their own account but the attack will not the the key will not be accessed by an identity which is on the target's account meaning uh the target account will only download and upload the data which is totally normal they can do that even with the uh scps and the attackers account will only just encryp the data and later on when needed they will decrypt the data and just you know put them back right now they they have reached the uh you know they have reached the goal they have encrypted they have access to the key uh the target do not have access to the key and uh they have done that on a company that

does not allow access to another organization's uh resources there is the again a catch uh S3 allows uh so has has a form of you can call it a data loss prevention which is called versioning basically if you create uh if you override or delete an object on an S3 a copy of it is still kept there and uh the the copying is uh is infinite or at least it's it's a very large number because I've tried it with about 50,000 C is of the same object and it still is kept there meaning if the attacker will try to encrypt them and upload them back the original copy will still be there so the the defender can

just grab the copy and you know they will not have to pay the The Ransom again this can be bypassed of course there are two ways to do that the first one is just disable disable the versioning and the second one is literally just go and delete all the other versions so upload the encrypted version then delete every other one except the encrypted version uh you can delete a version and if you delete the version a copy of it will not be kept so they can do the second one just upload the encrypted one delete every other version of the file and the only one the only version that that will be left there is the encrypted one so the

defender right now cannot re access the the original uh data so they will have to pay in order to get the the data back this is one you know uh a use sorry it's supposed to be H sorry uh another defense against uh against this is using MFA delete so uh bucket MFA delete is an extension of bucket versioning which requires an MFA key to be uh presented if you want to delete a version or if you want to uh to delete to uh deactivate the versioning so if a company has set up MFA delete the attacker has to bypass the the MFA or they have to find another way I don't know just fish the user for the MFA key

but unless they do that they will not be able to delete any version and they will not be able to deactivate the versioning so at this point the attacker has uh is stock because you know they cannot do practically anything uh also uh on perissa we also have the we also have coverage now yeah you can see that but I will share the the slides don't worry we also have uh coverage for this this type of attack starting from the creation of AC is locked up to the uh deletion of the the bucket versioning and the uh and the MF deit now conclusions from this conclusions what we understand from this is that first of

all AWS second of all second of all uh KS is and actually uh resource policies are actually a mess and it's actually the the this is one of those scenarios where you use a feature for an attack it's it's it's like they say a knife can be used to cut a knife can be used to kill uh this is one of those cases when uh a feature is used to to to attack something everything that is allowed here is allowed for a good reason starting from the ks policy not allowing even the route to access up to the uh cross account Keys all of them is allowed but an attacker can use them so you have to know how to defend your own

company meaning first of all always always check Whoever has access to the key second of all all always enable versioning on the buckets and always enable MF MFA delete if you don't do that an attacker can bypass that and the third one is always use scps and of course always use organizations don't don't don't just use one account it's you know if you do that the attacker is not able to to uh to attack the the company if you don't do that they you know we saw that they can uh also uh after actually not technically after finishing but while working on this we also saw that rhinos had done research on this part we tried

to we try to extend it a lot so they they they uh deal with the uh bucket uh the Cross Key sharing of the uh so ransomware using the uh cross account key sharing we try to extend this you know to practically show every use case that we could find on the on the attack but since they did it first shout out to them you know they deserve it in the end they do deserve to to be mentioned and yes any

questions it's really interesting talk thank you um do as you are in Google Cloud do they have are they different enough for this not to work so sorry did I did not hear um for aure and Google Cloud are they different enough uh I don't know actually I'm currently working on an Asia version of this if they are doing that and probably later on will work on a gcp1 I don't know currently if they do allow that or if they allow for a measure uh uh changing measure so no I can't can't any other

ones is there any cost for the KMS encryption because I would suppose that there is some sort of like uh alerts for the client when there's a lot of cost in like a very short period of time I mean you would be encrypted like a lot of data so if there's any cost they would be flagged I don't know something is uh I don't know but uh it depends the thing is uh there will be costs on downloading and uploading the data there will be costs on creating and maintaining the key and I'm pretty sure there will be costs on using the key for uh uh you know for encrypting the data directly on Transit uh the uh the thing with the

cost alerting is that I've never seen a company so far that uh stops a procedure because a cost is going too high especially for something that they accept and having a lot of data being uploaded yes it's a very high cost but I'm pretty sure it's something that they do accept you know it's it's something that they they accept to to to happen so they might get alerted but they I don't know if they will have time to to react to that uh to your point yes I'm pretty sure it's not the ks encryption that has the the largest cost but the downloading and uploading of data on the S3 bucket especi especially on on a really large

amount So [Music]

yeah thank you amazing presentation amazing content uh simple question like what can AWS do better or by default as a baseline security policy to protect their clients towards this okay two two things one is um now this is uh uh what they call a catch22 uh allowing the root account to change the key is actually mandatory this is one of those cases when if you allow the root account an identity that can log in as the root account will be able to to use the key so you know they they will be able to change the policy but on the other hand they will not um not at Le they will at least uh protect the its users from uh locking

the the key itself the second one is changing the part where the if the identity is deleted they don't have access to the key I don't know why they did that as I said I speculate that it's something you know in internal is some sort of generated ID that is internal that we cannot see and you know it does make sense but they have to change that because as we saw one of those attacks one of those parts could be solved just by having the identity that did the the the attack and I would say this is actually what I uh what I would recommend them and yes the third one is at least I I don't know if they

do that but at least have a good support on cases like this if somebody lcks the key accidentally or if an attacker uses uh you know uses their own key uses a key on their own infrastructure at least have some sort of support to just unlock the key and then allow the uh the target account to at least get access to the key and decrypt the data this is the the only thing they can do other than that you can't stop this especially the the cross accounting because because as I said I do understand why they are doing that they are doing that for compliance there are there are cases and many many cases when one account needs to have the

the keys and one account can only be created just to manage the keys it's like having just Just One V land just for the keys just a uh you know just it's like the red Forest on the active directory even though that's a total failure but you know uh it's I I can totally understand that and we can't ask them to stop that because I'm pretty sure a lot of of clients are using that but at least solving this other part it's actually what what they have to go for great thank you thank

you lot of lot of questions for BL does anyone have any other questions no okay then thank you B thank you very much