AWS Security Digest

BadPods Series: Everything Allowed on AWS EKS By: Kiran Dawadi Kiran Dawadi’s “BadPods” series dives into how default configurations in AWS EKS can let attackers do far more than most teams realize, turning cluster misconfigurations into full-blown compromise. 🔍 Why this is worth reading: • 🛠 Privilege escalation inside EKS — Shows how pods with default service accounts and broad RBAC permissions can pivot across the cluster. • 🔐 Network and role blind spots — Even “private” pods can exploit overly permissive network policies or cross-namespace role bindings. • 🧩 Real attack chains — Step-by-step examples of compromising workloads, extracting secrets, and escalating to cluster admin. • ⚡ Defensive guidance — Highlights how to enforce least privilege, restrict pod capabilities, and audit service accounts effectively. 👉 If you run or secure EKS clusters, this series reveals the gaps between default settings and secure practices, giving practical insights to harden your deployments. Read Here: cybersecnerds.com/badpods-series… This was first mentioned in AWS Security Digest Issue #242: awssecuritydigest.com/past-issues/aw…

European Sovereign Cloud By: Chris Farris Chris Farris breaks down what “sovereign cloud” actually means for AWS customers in Europe—and what it does not protect you from. 🔍 Why this is worth reading: • 🧩 Control vs. custody — AWS can host data in the EU, but US legal reach (like CLOUD Act) still applies to US-owned providers. • 🔐 Who controls the keys — Real sovereignty hinges on encryption, HSM ownership, and who can technically access root credentials. • 🛠 Operational reality — Patching, support, and incident response often still involve non-EU personnel and systems. • 📜 Regulatory nuance — GDPR compliance ≠ sovereign control, and the gap is wider than most marketing implies. Read Here: chrisfarris.com/post/eurosovcl… This was first mentioned in AWS Security Digest Issue #241: awssecuritydigest.com/past-issues/aw…

Introducing Pathfinding.cloud By: Seth Art Datadog’s Pathfinding.cloud is designed to help security teams visualize and analyze complex AWS attack paths, revealing how minor misconfigurations or overly broad roles can cascade into serious exposures. Why this is worth reading: • 🧩 Visual attack path mapping — Shows how users, roles, and services can interact in ways that lead to privilege escalation or lateral movement. • 🔐 IAM and resource relationships — Highlights hidden trust chains and overlooked permissions that traditional audits often miss. • 🛠 Simulation before impact — Security teams can test hypothetical attacks on their own cloud environment without executing risky commands. • 📊 Actionable insights — Helps prioritize remediation based on potential exposure and impact rather than just misconfigurations. 👉 If you manage AWS security or IAM governance, Pathfinding.cloud provides a practical, visual way to spot and fix hidden attack vectors before they’re exploited. Read here: securitylabs.datadoghq.com/articles/intro… This was first mentioned in AWS Security Digest Issue #241: awssecuritydigest.com/past-issues/aw…

AWS Privilege Escalation Techniques By: Ben Goodspeed Ben Goodspeed maps out how attackers turn small IAM mistakes into full account takeover, using both classic AWS services and newer AI-driven attack surfaces. 🔍 What makes this worth your time: • 🔑 Service‑based escalation paths — How Lambda, CloudFormation, Step Functions, and IAM PassRole can be chained to gain admin‑level access. • 🧠 Bedrock & AgentCore risks — Shows how AI agents with over‑privileged execution roles can be abused to execute actions far beyond their intended scope. • 🧩 Real attack chains — Walkthroughs that start with a low‑privileged user and end with account‑wide control using only legitimate AWS APIs. • 🛡 Defensive takeaways — Concrete guidance on locking down PassRole, scoping service roles, and monitoring privilege‑granting API calls. 👉 If you work with AWS IAM or cloud detection engineering, this is a sharp, technical look at how privilege escalation actually happens — and how to stop it before it becomes a breach. Read me: softwaresecured.com/post/aws-privi… This was first mentioned in AWS Security Digest Issue #241: awssecuritydigest.com/past-issues/aw…

🛎️ AWS Security Digest 252 is out! 1️⃣ Bucketsquatting is (Finally) Dead by Ian McKay 2️⃣ Behind the console: Active phishing campaign targeting AWS console credentials by Martin Mc Closkey 3️⃣ Visualizing AWS Relationships and Attack Paths by pathsec awssecuritydigest.com/past-issues/aw…

Goodbye to Static Credentials: Embrace Modern Identity Practice By: Eyal Estrin Eyal Estrin breaks down why static credentials are no longer viable and how modern identity strategies can drastically reduce the risk of compromise across cloud environments. 🔍 Key insights from the article: • 🛠 Short-lived and ephemeral credentials — Moving from long-lived keys to time-bound tokens limits blast radius if credentials are leaked. • 🧩 Identity as the new perimeter — Emphasizes integrating IAM, SSO, and federation for centralized access control rather than relying on network-based restrictions. • 🔐 Automated rotation and monitoring — Ensuring credentials never persist beyond their use window and continuously auditing usage patterns. • 🧠 Cultural shift — Teams must rethink access management, removing assumptions about “safe” static keys and adopting identity-first security practices. • ⚡ Practical guidance — Examples of using AWS STS, service-linked roles, and conditional policies to enforce least privilege dynamically. 👉 If you manage cloud access or security operations, this article explains how to modernize identity practices to mitigate credential risk and enforce least privilege at scale. Readme: eyal-estrin.medium.com/goodbye-to-sta… This was first mentioned in AWS Security Digest Issue #241: awssecuritydigest.com/past-issues/aw…

The Cloud’s Year-End Confessions: What Really Happened in 2025 By: McKenzie Gladney McKenzie Gladney takes a hard look at the most pressing cloud security risks of 2025, mixing data from breaches, misconfigurations, and emerging attack patterns into a year-end reality check for security teams. 🔍 Why this is worth reading: • 🧩 Identity and access dominate — Compromised credentials, misused service roles, and over-permissive IAM policies remain the leading attack vectors. • 🔐 Misconfigurations aren’t just accidental — Multi-cloud and hybrid setups amplified exposure, with S3, KMS, and Kubernetes misconfigurations leading to real-world leaks. • 🛠 Exploitation is getting smarter — Attackers are leveraging legitimate services (e.g., Lambda, SSM, CloudFront) to hide their tracks, bypassing traditional defenses. • 📊 Shift toward observability — The year emphasized that cloud visibility and telemetry, not just static security policies, are critical for defense. • 🕵️ Lessons for 2026 — Gladney highlights actionable steps: enforce least privilege, automate drift detection, audit service-linked roles, and integrate cloud-native monitoring with SIEM/SOAR. 👉 For anyone responsible for cloud security, this post is a concise yet detailed look at where risks really materialized in 2025 — and how to prepare for what’s next. Read here: orca.security/resources/blog… This was first mentioned in AWS Security Digest Issue #241: awssecuritydigest.com/past-issues/aw…

Exploiting AWS IAM Eventual Consistency for Persistence By:Eduard Agavriloae IAM doesn’t update everywhere at once — and attackers can turn that delay into a stealthy persistence mechanism. Eduard Agavriloae shows how the brief window between policy change and global enforcement can be abused to keep access even after defenders think they’ve locked things down. Here’s what makes this attack path dangerous: 🔹 Policy rollbacks aren’t instant — revoked permissions can still be honored by some AWS services for seconds or minutes, creating a race condition attackers can exploit. 🔹 Backdooring during the gap — the research shows how to create new users, roles, or access keys while security teams believe access has already been removed. 🔹 Hard to detect — CloudTrail may show the “deny” before the malicious action, making incident timelines misleading. 🔹 Perfect for persistence — attackers can plant long-lived IAM artifacts that survive cleanup efforts. Read here: offensai.com/blog/aws-iam-e… This was first mentioned in AWS Security Digest Issue #240: awssecuritydigest.com/past-issues/aw…

🛡️ Hands On with AWS Bottlerocket: Evaluating the Security of Amazon’s Hardened OS By:Terry Franklin AWS pitches Bottlerocket as a purpose-built OS for containers—but how hardened is it really? Terry Franklin goes past the marketing and tears into Bottlerocket from an attacker and defender’s point of view. Here’s what makes this analysis worth reading: 🔹 No SSH, no package manager, no shell — Bottlerocket removes entire classes of post-exploitation by design, forcing all admin access through controlled APIs and SSM. 🔹 Read-only root filesystem — malware and persistence techniques that work on Ubuntu or Amazon Linux simply don’t survive reboots here. 🔹 Minimal attack surface — the OS runs only what’s needed for Kubernetes and ECS, dramatically shrinking what an attacker can touch. 🔹 Real-world testing — Terry walks through what breaks (and what still works) when you try common container-escape and host-level attacks. The key takeaway: Bottlerocket doesn’t just reduce risk—it changes the attacker playbook. If you run EKS or ECS and assume your nodes are disposable, this OS makes that assumption far more defensible. Read Here: pitfallen.net/blog/hands-on-… This was first mentioned in AWS Security Digest Issue #240: awssecuritydigest.com/past-issues/aw…

Test S3 ABAC Locally with iam-lens By: David Kerber ABAC for S3 looks great on paper—until a single missing tag silently breaks access. This guide shows how to use iam-lens to simulate S3 authorization locally, so you can validate complex tag-based policies before they ever hit AWS. What makes this powerful: 🔹 Policy + tag simulation — Load your IAM policies, bucket policies, and object tags to see exactly why a request is allowed or denied. 🔹 Debug real failures — It exposes which condition (like s3:ResourceTag or aws:PrincipalTag) caused the decision, instead of forcing you to guess from AccessDenied. 🔹 Shift-left on IAM — Catch broken ABAC rules during development instead of discovering them after deploying to production. 🔹 Faster than trial-and-error — No need to create test buckets or roles just to understand why S3 said “no.” Read here: iam.cloudcopilot.io/posts/test-s3-… This was first mentioned in AWS Security Digest Issue #240: awssecuritydigest.com/past-issues/aw…

🛎️ AWS Security Digest 251 is out! 1️⃣ The AWS Console and Terraform Security Gap by Laurence Tennant 2️⃣ Stop Enabling Every AWS Security Service by Sena Yakut awssecuritydigest.com/past-issues/aw…

Abusing AWS Systems Manager as a Covert C2 Channel By: Atul Kishor Jaiswal This research shows how AWS Systems Manager (SSM)—a tool most orgs already trust—can be turned into a stealthy command-and-control channel that slips past network controls and egress filters. Here’s why defenders should care: 🔹 SSM Run Command as C2 — Attackers can send commands to compromised EC2 instances via SSM, so traffic stays inside AWS control planes and avoids suspicious outbound connections. 🔹 IAM is the real blast radius — A single over-permissive role (e.g., ssm:SendCommand, ssm:ListCommandInvocations) is enough to operate malware remotely with no malware beaconing. 🔹 CloudTrail blind spots — Many teams log SSM usage but don’t alert on who is sending what commands, making abuse hard to spot. 🔹 Practical detection tips — The article maps specific API calls and CloudTrail fields you should baseline to catch this technique. Read here: @atulkishorjaiswal/abusing-aws-systems-manager-as-a-covert-c2-channel-017bb13b6010" target="_blank" rel="nofollow noopener">medium.com/@atulkishorjai… This was first mentioned in AWS Security Digest Issue #240: awssecuritydigest.com/past-issues/aw… cess.

re:Invent 2025 Recap By: Chris Farris Chris Farris’ post-event re:Invent summary doesn’t just list announcements — it filters what actually matters to practitioners across security, governance, serverless, networking, and AI — and calls out the unexpected nuances behind each piece. chrisfarris.com 🔍 Top takeaways that make this worth reading: • 🔐 Security enhancements with real nuance — New tools like AWS Security Agent (preview) promise proactive app security reviews and automated pentest insights, but Farris doesn’t sugar-coat the limitations. chrisfarris.com • 🔑 IAM & access management updates — From IAM identity federation with JWTs to IAM Policy Autopilot, these changes could shift how you handle cross-account and least-privilege policies — with surprising trade-offs in enforcement and governance. chrisfarris.com • 🪶 S3 gets smarter — Organization-level block public access, attribute-based access control, and enforced encryption policy changes — including the planned deprecation of SSE-C — are subtle but security-impacting platform shifts. chrisfarris.com • 🚨 Threat detection & response upgrades — GuardDuty Extended Threat Detection and a retooled Security Hub promise more actionable signals, not just compliance noise — a key operational difference. chrisfarris.com • ☁️ CloudTrail and observability tweaks — CloudTrail’s data event aggregation and new CloudWatch delivery options tackle real pain points, even if costs and coverage remain debated. chrisfarris.com • 🌐 Network and governance tools evolve — From regional NAT gateways to enhanced configuration drift awareness in StackSets, there’s a focus on making governance and security automation scalable and reliable. chrisfarris.com • 🤖 Serverless & AI shifts — Lambda isolation modes, Bedrock enhancements, and local Step Functions testing all reflect AWS pushing execution boundaries, though Farris injects healthy skepticism about hype vs real value. chrisfarris.com Read here: chrisfarris.com/post/reinvent2… This was first mentioned in AWS Security Digest Issue #239: awssecuritydigest.com/past-issues/aw…

AWS Lambda Managed Instances: A Security Overview By: Eduard Agavriloae This article peels back the abstraction on AWS Lambda and explains what “managed” really means from a security perspective — and where responsibility still sits firmly with customers. 🔍 Why this is worth the click: • 🧩 What runs your Lambda, exactly? — Agavriloae breaks down Lambda’s managed execution environment, including how instances are provisioned, reused, and isolated across invocations. • 🔐 Isolation isn’t magic — The post explains the security boundaries between functions, containers, and microVMs, and why cold starts, warm reuse, and shared infrastructure matter for threat modeling. • 🧠 Attack surface you don’t see — While AWS owns the host OS and hypervisor, function code, dependencies, IAM roles, and environment variables remain high-risk entry points. • 🛠 Clear shared responsibility mapping — The article maps AWS-owned controls vs customer-owned controls, helping teams avoid false assumptions about what Lambda “handles for you.” • 🛡 Practical hardening guidance — Least-privilege execution roles, dependency hygiene, secrets handling, and logging practices are framed specifically for how Lambda actually runs. 👉 If you use Lambda and assume “serverless” means “no security thinking required,” this post is a grounded, technical reset on where real risks live in managed compute. Read here: offensai.com/blog/aws-lambd… This was first mentioned in AWS Security Digest Issue #239: awssecuritydigest.com/past-issues/aw…

Amazon CloudFront mTLS with an Open-Source Serverless CA By: Paul Schwarzenberger This article delivers a hands-on walkthrough of bringing mutual TLS to CloudFront without proprietary tooling, using a fully serverless, open-source certificate authority — and explains why this matters for real access control. 🔍 Why this is worth the click: • 🧠 mTLS at the edge, not just at the app — The setup enforces client certificate authentication directly at CloudFront, blocking unauthorized clients before requests ever reach origin infrastructure. • 🛠 Serverless CA architecture — Schwarzenberger demonstrates how to issue, rotate, and revoke client certs using open-source tooling backed by AWS-native services, avoiding long-lived secrets and manual cert handling. • 🔐 Fine-grained client trust — Client identity is validated cryptographically, making this approach far stronger than IP allowlists or static headers for protecting APIs, admin endpoints, or partner integrations. • ⚙️ Operational realism — The post covers certificate lifecycle management, automation tradeoffs, and CloudFront constraints — not just the happy path. • 🧩 Where this shines — Ideal for private APIs, B2B integrations, internal tools, and zero-trust-style edge access patterns. 👉 If you’ve ever wanted strong client authentication at CloudFront without heavyweight PKI, this is a practical blueprint you can actually deploy. Read here: @paulschwarzenberger/amazon-cloudfront-mtls-with-open-source-serverless-ca-f49ce2bc9874" target="_blank" rel="nofollow noopener">medium.com/@paulschwarzen… This was first mentioned in AWS Security Digest Issue #239: awssecuritydigest.com/past-issues/aw…

Privilege Escalation with SageMaker — and What’s Hiding in Execution Roles By: Daniel Grzelak This deep dive exposes how SageMaker execution roles can quietly become a privilege-escalation path — even when IAM permissions look “reasonable” at first glance. 🔍 Why this article is worth the click: • 🧩 Execution roles are more powerful than they appear — Grzelak shows how SageMaker roles often carry broad permissions (S3, ECR, CloudWatch, IAM pass-role) that attackers can chain together once they gain limited access. • 🔐 From ML access to account-wide impact — With the ability to start training jobs or processing jobs, an attacker can run arbitrary code that assumes the execution role and pivots into other AWS services. • 🧠 Hidden trust relationships — The post highlights how trust policies and service-assumed roles create escalation opportunities that are easy to miss during IAM reviews. • 🛠 Concrete abuse paths — Realistic examples demonstrate how mis-scoped execution roles can lead to data exfiltration, lateral movement, or further privilege expansion. • 🛡 Actionable defenses — Tighten execution role permissions, restrict iam:PassRole, audit trust policies, and treat ML roles with the same scrutiny as CI/CD or admin roles. 👉 If you use SageMaker or review AWS IAM regularly, this article shows why ML infrastructure deserves first-class attention in threat models — not an afterthought. Read here: plerion.com/blog/privilege… This was first mentioned in AWS Security Digest Issue #238: awssecuritydigest.com/past-issues/aw…

🛎️ AWS Security Digest 250 is out! 1️⃣ A Backdoor You Can Talk To: Persistence via Bedrock AgentCore by Adan Alvarez 2️⃣ IAM Containment That Survives Eventual Consistency by Eduard Agavriloae 3️⃣ Post-Exploitation at Scale: The Rise of AILM by Roi Nisimi awssecuritydigest.com/past-issues/aw…

🔐 AWS pre:Invent Security Highlights: What Changed and Why It Matters Adan Álvarez This was first mentioned in AWS Security Digest Issue #238: awssecuritydigest.com/past-issues/aw… This write-up cuts through pre:Invent noise and focuses on the AWS security changes that actually affect how environments are defended and monitored — especially for teams running at scale. 🔍 Key insights worth the click: • 🧩 Security posture is becoming more centralized — AWS continues pushing toward consolidated security management, reducing fragmented controls across accounts and services. • 🔐 Identity remains the main battleground — Several updates reinforce IAM, access evaluation, and permission visibility, reflecting how most real compromises still start with credential misuse or role abuse. • 🛠 Detection over configuration — New and improved capabilities lean toward continuous monitoring and context-aware signals, not just static misconfiguration checks. • 📊 Less noise, more signal — The changes aim to improve prioritization and reduce alert fatigue, helping teams focus on what’s actually exploitable rather than everything that’s technically non-compliant. • 🧠 Why this matters operationally — These updates shift how security teams design workflows, respond to incidents, and integrate AWS-native tooling into existing SOC processes. 👉 If you want a security-focused, opinionated breakdown of what pre:Invent introduced — and how it changes day-to-day cloud defense — this is a high-value read. Read here: a2secure.com/en/blog-en-2/a… This was first mentioned in AWS Security Digest Issue #238: awssecuritydigest.com/past-issues/aw…

Phishing for AWS Credentials via the New “aws login” Flow By:Adan Álvarez Vilchez This article breaks down how AWS’s new aws login CLI flow can be abused for highly convincing credential-phishing, and why even security-aware users could fall for it. 🔍 What makes this research click-worthy: • 🧠 The attack blends in with normal workflows — Instead of fake AWS Console pages, the phishing chain abuses the legitimate aws login experience, making prompts and browser redirects look exactly like what developers expect. • 🔐 Session tokens, not passwords — The focus isn’t stealing static credentials, but harvesting temporary credentials and SSO session artifacts that are immediately usable for AWS API access. • ⚙️ CLI-first threat model gap — Many orgs protect the console with strong controls but overlook how developers authenticate via CLI, where guardrails and user awareness are weaker. • 🕵️ Low-signal, high-impact — Because the flow relies on valid AWS endpoints and expected redirects, traditional phishing detection and user suspicion are less likely to trigger. • 🛡 Defensive takeaways — Álvarez Vilchez outlines mitigations like tightening SSO session policies, limiting token lifetimes, monitoring anomalous CLI authentication patterns, and educating users on unexpected login prompts. 👉 If your team relies on AWS SSO and CLI access, this post shows how modern phishing has shifted from fake login pages to abusing real auth flows — and what to do about it. Read here: @adan.alvarez/phishing-for-aws-credentials-via-the-new-aws-login-flow-39f6969b4eae" target="_blank" rel="nofollow noopener">medium.com/@adan.alvarez/… This was first mentioned in AWS Security Digest Issue #236: awssecuritydigest.com/past-issues/aw…

Enable Whichever Version of Security Hub AWS Is Supporting These Days By: Rich Mogull Rich Mogull delivers a sharp, practical take on why many AWS Security Hub deployments quietly fail — not because the service is useless, but because teams enable the wrong version or assume defaults will carry them. 🔍 Why this is worth a click: • 🧩 Security Hub versions actually matter — Mogull explains how AWS has shifted Security Hub under the hood, and how sticking with legacy configurations means you’re missing newer controls, signals, and integrations. • 🚨 “Enabled” doesn’t mean “effective” — Many accounts technically run Security Hub, but aren’t aligned with the currently supported standard, leading to false confidence and incomplete coverage. • ⚙️ Control drift is the real risk — As AWS updates supported standards, orgs that don’t revisit their setup slowly fall out of sync, weakening detections and compliance reporting. • 🛠 Clear, no-nonsense guidance — The post cuts through AWS ambiguity and gives straightforward advice: enable the version AWS is actively supporting, validate it across accounts, and stop overthinking the rest. 👉 If you rely on Security Hub for visibility, compliance, or detection — or assume it’s “already turned on” — this is a fast, valuable reality check. Read here: slaw.securosis.com/p/enable-which… This was first mentioned in AWS Security Digest Issue #236: awssecuritydigest.com/past-issues/aw…