Locking the Locks: How “RansomWhen” Unmasks the Identities Hijacking Your AWS S3 Buckets

[pastacode lang=”markup” manual=”%7B%0A%20%20%20%20%22Create%20Locked%20Key%20and%20Encrypt%20Bucket%20using%20CopyObject%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%22kms%3ACreateKey%22%2C%0A%20%20%20%20%20%20%20%20%22s3%3APutBucketEncryptionConfiguration%22%2C%0A%20%20%20%20%20%20%20%20%22s3%3ACopyObject%22%0A%20%20%20%20%5D%0A%7D” message=”” highlight=”” provider=”manual”/]

Each scenario will be listed as:

• allowed, for cases when all the events in a scenario are allowed
• partially, for cases when at least 1 event in the scenario is allowed
• denied, for cases when no event on the scenario is allowed

Attach Custom KMS Key Store
Create Locked Key and Encrypt Bucket using CopyObject
Create Locked Key and Encrypt Bucket using Get/Put Object
Create Role, Add Inline Policy and Delete
Create Role, Attach Inline Policy and Delete
Create User, Add Inline Policy and Delete
Create User, Attach Inline Policy and Delete
Delete CloudTrail Trail
Stop Logging
Stop Logging using KMS
Update Current Custom KMS Key Store
Update Key Policy to Lock Key and Encrypt Bucket using CopyObject
Update Key Policy to Lock Key and Encrypt Bucket using Get/Put Object

Finding malicious events

As far as finding identities with malicious events, the tool will look into the JSON Blob scenarios/events.json. That file can also be configured, with a format as below, where each event will have its information set to either null or a value, just as it is supposed to be saved on the CloudTrail Logs.