Backdoor an S3 Bucket via its Bucket Policy - use of an account ID linked to AWS

[m4wk]

It appears the account ID used in this attack (193672423079) is used by AWS for RedShift logs. Some tools use lists like the one from Cloudmapper (https://github.com/duo-labs/cloudmapper/blob/main/vendor_accounts.yaml) to exclude known vendors which limits detections sourced from Stratus.

Is it possible to use a new randomly generated accountID?

[christophetd]

Thanks for reporting! That's a good point, we'll look into fixing it. I would need to check if the bucket policy requires specifying a valid AWS account - if yes, we'll need to use a "real AWS account" that's not listed in cloudmapper's list. If not, we can simply use 111111111111

[m4wk]

Yes it needs a valid principal unfortunately. Maybe Datadog can create an account used solely for external account testing for s3 bucket policies, IAM policies, etc. This can be used by the community (Cloudmapper, Cloud Custodian, etc.) for detection rule testing. Otherwise 111111111111 works fine.

[craSH]

AWS uses the account ID 123456789012 throughout their documentation and code examples, so it may be a safe option. I can't find any definitive source stating that it is reserved for example use, however.

[christophetd]

same issue/question for implementation of #469 in #478