Recently I spent some time exploring the available configuration options for AWS Backup Vault Locks, to ensure backups and restore points are immutable, which could be leveraged to help protect data stored in AWS from malicious actors and ransomware attacks.
There are 2 options for vault lock policies within the AWS Backup service:
- Governance Lock: Locks are applied to a backup vault, but they can be removed or changed at a later date. Items that the governance lock was applied to before being deleted remain locked for the specified duration of the lock.
- Compliance Lock: Locks are applied to the backup vault, with a cooldown period of a minimum of 3 days. Once the cooldown period has expired there is no way to remove the vault lock.
“There is no way for AWS or any other user to alter or remove it.”
“A vault lock in Compliance mode cannot be altered or deleted by any user or by AWS.”
What might an immutable denial of wallet attack look like?
With traditional denial of wallet attacks, it’s a little primitive and chaotic. The tactics are usually centred around creating as many expensive resources as possible before the account owner notices, resulting in potentially significant financial loss. Whereas with AWS Backup Vault Locks, we can assume from the AWS docs that there is no way to rectify an attack targeting immutable backups, besides potentially nuking the account and everything in it.
The compliance lock option sounds like a great opportunity for a malicious actor, who manages to gain unauthorised access to an AWS account, to inflict an immutable denial of wallet attack.
Due to the minimum cooldown required of a compliance lock, it makes sense to start by creating this within the account. It needs to be associated with an AWS Backup vault, and you get one out of the box with the service, so there is no need to risk detection creating your own. Simply use the default.
Once the cooldown has expired, and if the compliance lock hasn’t been detected, you can start to add resources and a backup policy which triggers frequently, or find the biggest resources which already exist in the account to avoid setting off any alarms.
The best options are probably large S3 Buckets, because they are a fully-managed resource type in AWS Backup, which means there is very minimal configuration required beyond ensuring versioning is enabled, and they can contain huge amounts of data, to rack up the costs of the immutable backups you’ll be creating.
You could even make this recursive, by backing up a CloudTrail S3 Bucket which then stores the backup events for each object within the S3 backup.
How realistic is the threat?
I performed a quick search and couldn’t find any resources discussing this, so maybe it’s something and maybe it’s nothing.
If an AWS account is compromised, this is not the lowest hanging fruit, and so an attacker probably wouldn’t focus their attention here. It is an interesting idea though, and maybe someone smarter than me could make it a worthwhile option.
In reading through the docs all suggestions from AWS point towards not being able to remove a compliance lock. In reality, I would guess that AWS say they can’t remove a compliance lock to prevent the support tickets which might come off the back of people making ill informed decisions. But, in the event of an attack like this I’m sure they would quietly find a way to shut it down.
On the scale of potential outcomes it probably falls closer to an inconvenience than causing bankruptcy, but who knows, and I’m not willing to put it to the test.
Maybe it’s not a legitimate threat, but it can’t hurt to monitor and alert on this kind of anomalous activity, and maybe GuardDuty has a rule for it - although I couldn’t find one. Also, I couldn't find management events in CloudTrail for actions taken in regards to AWS Backup Vault Locks.
I’ll try to remember to return to this post at a later date and provide mitigations. It does seem like there’s a missing MFA delete style option for Vault Locks, which might make more sense than the all or nothing compliance lock option.
Reference Documents
https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html
