It's unclear why the resource couldn't widthstand attack, maybe it had known vulerable software, a weak password, I'm not sure it's been published, but something happened.
Whatever it is was able to assume the *-WAF-Role which had an amazing amount of access.
Given the name of the role and the stupid amount of access, I'd wager it was some shitty security product, but who knows. Maybe we'll find out.
Why a WAF role needed so much access to data is something that's hard to explain, and would suggest a major fuckup by the teams involved.
Something commercial that was bought by a ciso or security person who has no common sense, that asks to specifically be configured with access to that much data.
That's my bet.
But actually, giving a hacked product access to all data forever is a terrible practice, thus you ask what would the motivation be of doing so.
So either, it's epic fail for being so open with the role, or the role is for a product that asks for all data so it can scan and scrub, for example. i.e. Shitty security product.
Also, sure, it's up to them, but should it be if they can't secure other peoples data?
Probably lots of vulnerable setups out there unless C1 brewed its own, which doesn’t sound like it’s the case.
That being said, breaking into an instance with a bad S3 role is a foregone conclusion once on that EC2 instance. It will be interesting to learn details.
Common mistake is allowing S3 policies and other IAM policies in general from any was account ID not just "yours" which might explain the TFA and other threads here that indicate the accused somehow has data from other companies not just C1.
Maybe instead of waf:* for the action, it was just * ?
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "waf:*" ], "Resource": [ "arn:aws:waf::444455556666:webacl/112233d7c-86b2-458b-af83-51c51example" ] } ] }