AWS Security Digest

Monday,
April 21, 2025

🥖 Palette Cleanser

Happy Easter, chocolate lovers.

It's been an intense week of cybers. First, a really spicy whistleblower disclosure was published, showing actors in Russia had access to DOGE engineers' accounts at the US National Labor Relations Board (NLRB) about 15 minutes after those accounts were created. The interesting thing for me is just how much one person's determination to keep pulling threads resulted in these discoveries. This is consistent with my career experience. Unexpected downtime and hero investigators hold more of the internet together than we would hope.

Then MITRE warned its board members of a funding gap that could have caused issues with the Common Vulnerabilities and Exposures (CVE) program. We cloud professionals rely on the program to do our jobs, whether we know it or not. Almost immediately, CISA came to the rescue, securing another 11 months of funding for the contract, "to ensure there will be no lapse in critical CVE services."

It wasn't all drama, though. In fact, maybe my favorite AWS security tool ever was released this week by Liad Eliyahu of Miggo. I've always maintained that most AWS security issues are either already documented by Amazon or are documented as soon as they are disclosed. It's just been difficult to find them and track them — until now. The AWS Security Docs Change Engine regularly pulls all AWS documentation and compares it to the last version fetched to precisely and accurately show what was updated. It then does some analysis using AI magic and makes it all available for anyone to search. Give it a go — search for "account isolation" and you might discover that there are some confused deputy issues in how ELB logs are delivered to S3. If all goes well, we'll have a new documentation changes section in next week's ASD issue!

Have feedback about AWS Security Digest? Tell us here. This issue is also available to share online.

📋 Chef's selections

Securing a SaaS Company's AWS Environment After a Breach by Chandrapal Badshah

More detection and response consultants should publish anonymized post-breach reports. You can't really put "The production account was also the AWS Organization’s management account" or "All RDS databases were on public subnets with public IPs" in your own post-incident report, but it doesn't make it any less true. If you have awful cloud security practices at your company, send your boss this post.
clusterf*ck: attack sims on k8s clusters by Bilal S

I can't vouch for Bilal's tool as I haven't run it myself, but the premise is cool. Bilal has created a multi-stage attack simulation for k8s environments, and named it with puntastic precision. It does everything from container escape, to kube token theft, AWS credential theft, and even a little crypto mining at the end. It's a great way to test your Kubernetes controls and detection capability.
IAM Role Trust Policies: Misconfigurations Hiding in Plain Sight by Eliav Livneh

In 2016, I did a presentation to a closed group of security leaders in the US. One of the slides read something like, "The next big breach will start because of AssumeRole trust relationships." I was clearly wrong. But many of the points still stand, like the ones outlined by Eliav in his blog. Trusting entire accounts is a horrible default.

Bonus: Overwriting a File in S3 Does Not Require DeleteObject Permissions

🥗 AWS security blogs

🍛 Reddit threads on r/aws

💸 Sponsor shoutout

Have you got a long list of AWS security issues you could fix but no idea how bad any of it really is?

Instead, start a free trial with Plerion. Focus on the 1% of risks that matter & achieve better security outcomes.

🥖 Palette Cleanser

📋 Chef's selections

🥗 AWS security blogs

🍛 Reddit threads on r/aws

💸 Sponsor shoutout

🤖 Dessert

🧁 IAM permission changes

🍪 API changes

🍹 IAM managed policy changes

☕ CloudFormation resource changes

🎮 Amazon Linux vulnerabilities

📺 AWS Security Bulletins