This post is about techniques to transfer databases between AWS accounts for penetration testing purposes.
If you gain access to the AWS console you are usually a very happy hacker. No doubt you have a number of ways to gain access to the critical information you are after and extract it. What you usually want though is the fastest way. The clock is ticking as soon as you are in, especially if alerts are set up for potential malicious actions.
One technique that is fairly fast and reliable is simply sharing a database backup or snapshot from the compromised account to an external account controlled by the attacker.
This takes about 4 clicks and will give you a full copy of the entire database that you can snapshot yourself and save for later. do note that there are standard security alerts written for this action in CloudTrail, so be prepared to be burned very quickly after initiating an action like this
To see how to share an RDS snapshot to an external account follow steps here.
What happens when you find yourself in a situation with a high privileged AWS user account and AWS console access but the database is encrypted? As outlined above you can prepare for the transfer of an unencrypted DB fairly quickly, but things get complicated when encryption is involved. You might assume what I think most people assume, that encryption is adequate protection against stealing the DB via transfer. However, with some time pressure, desperation, and intense documentation reading an alternative solution has been found.
AWS has several options for management of CMK’s (Customer Master Keys). These are the keys that customers use to encrypt their data (and databases!).
AWS has great documentation so if you want to read it straight from them you can get a good overview here: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html
I’m going to give a simplified overview that gives the relevant info for our situation.
CMK’s can be divided into 3 categories. I’ve conveniently listed them in order of ease of hacking along with the basic instructions on how to decrypt the database.
Customer Managed Keys - Edit the key policy yourself to grant your account access to the key
AWS Managed Keys - Create a new key (customer managed) in a different region and then create a snapshot copy in that region encrypted with your newly created key
AWS Owned Keys (unknown- haven’t looked into this)
Below I’ll expand on detailed steps and explanation of each technique.
note you must have access to a fairly high permissioned account that can manage keys
AWS KMS (Key management service) keys are Regional constructs. So, to copy a snapshot to another Region, you first must create a KMS key in the destination Region. Use this new key to encrypt the snapshot in the destination Region.
Hope this helps you on your final steps of operation success!
Special thanks to @mangopdf for locating the sacred texts required for these techniques in amazon’s documentation!tags: