3 minutes
Highlights from fwd:cloudsec 2025
(Updated on November 9, 2025)
Introduction
The 7th edition of fwd:cloudsec was held in Denver, CO, this year, and it was filled with numerous engaging talks, vendor demos, discussions, and catch-ups. Here are some of the talks that I found particularly interesting:
ECS-cape – Hijacking IAM Privileges in Amazon ECS
Malicious ECS task on EC2 instances can access credentials for all the other ECS tasks running on the same host
- TL;DR: During normal operations, the ECS container agent sends a SigV4 web socket request to a polling endpoint (E.g.,
https://ecs-a-1.<region>.amazonaws.com) using theecs:Pollpermission (whichAmazonEC2ContainerServiceforEC2Rolerole has). This endpoint returns credentials (Access Key ID, Secret Access Key, Session Token, etc. of the task roles) for all ECS tasks running on that EC2 instance. A malicious ECS task can make this same web socket request by leveraging the EC2 IMDS endpoint. - Talk, Write-up
- Highlights: After the researcher reached out to AWS, AWS added warnings to docs:
For EC2 and External Container Instances on ECS, there is no task isolation (unlike with Fargate) and containers can potentially access credentials for other tasks on the same container instance
- Action Item Disable IMDS access for ECS tasks running on EC2 instances (as the docs now explicitly recommend). For a deep dive into how to do that effectively, checkout my post: ECS on EC2: Covering Gaps in IMDS Hardening.
- Resources: If you want to learn more about IMDS, check out this Latacora blog post: Remediating AWS IMDSv1.
whoAMI: Discovering and exploiting a large-scale AMI name confusion attack
Victims can end up executing malicious AMIs on their EC2 instances due to a very common IaC misconfiguration
- TL;DR: Most IaC configs that spin up EC2 instances don’t leverage the
owner/owner-aliasattribute in AMI data source. This could fetch unverified public AMIs and unsuspecting victims would be running these images on their instances. - Talk, Write-up
- Highlights:
- Hashicorp actually identified this vulnerability back in 2018 and patched it by making
ownerattribute a required field. But due to user request, this was again made optional in 2022. - The presenter (Seth Art) also released a VirusTotal like scanner for public AWS AMIs: https://investigator.cloud/. I have just poked around for a bit, but I already like the
Full LineageandUnique File Hashesfeatures.
- Hashicorp actually identified this vulnerability back in 2018 and patched it by making
- Resources: Seth also released a scanner to look through your AWS accounts for this misconfiguration: https://github.com/DataDog/whoAMI-scanner. The overarching fix for organizations here is to maintain a list of allowed AMIs to ensure that only AMIs from known owners are being used. Check out this cool blog for more details: Defending Against the whoAMI Attack with AWS Declarative Policies.
Not So Secret: The Hidden Risks of GitHub Actions Secrets
Exposing Secrets through GitHub Actions
- TL;DR: Repository-level secrets can be exfiltrated by contributors with write permission by means of running a malicious workflow on their own custom branch. So, branch protection rules and PR approval requirements don’t protect against this. One remediation step is to use environments instead.
- Talk
- Further Reading: If you want to learn more about securing GitHub Actions, check out this insightful post by Wiz.
Inviter Threat: Managing Security in a New Cloud Deployment Model
Securing Bring Your Own Cloud (BYOC) deployments
- TL;DR: Tips and how-tos about doing BYOC deployments. The presenter (Meg Ashby) shared her experience with BYOC deployments, what orgs should focus on and can get right, as well as the trade-offs.
- Talk
Resources
- Playlist: https://www.youtube.com/watch?v=p8PZiqXoVTc&list=PLCPCP1pNWD7M-hHBOymDR5vkPib0tkZd9&index=1
- Summary: Christophe Limpalair of Cybr compiled summaries of all talks here: fwdcloudsec-2025-summaries