Most AWS breaches don't start with a zero-day exploit or some novel attack technique nobody saw coming. They start with something almost boring: a public S3 bucket, an IAM key committed to a public GitHub repo, a security group rule that was supposed to be temporary and never got removed. The attack techniques covered here aren't exotic. They're the specific, recurring ways enterprises actually get compromised on AWS, in the order we tend to see them show up in real incidents.
I want to frame this differently than the usual "best practices" list, because best-practices lists tend to describe the ideal state without explaining what actually goes wrong when reality falls short of it. This is threat-specific: here's how the compromise actually happens, and here's what specifically stops it.
*Threat: Publicly Exposed Storage *
This is still, after years of high-profile breaches making headlines specifically about this exact mistake, one of the most common ways sensitive data actually leaks from AWS environments. An S3 bucket gets created, permissions get set loosely during initial setup often because someone was troubleshooting an access issue and widened permissions to eliminate it as a variable and the bucket never gets locked back down once the immediate problem's resolved.
What actually stops this: S3 Block Public Access should be enabled at the account level as a default, not configured bucket-by-bucket where it's easy for one to get missed. Access should be verified explicitly rather than assumed private bucket policies audited regularly, not just configured once at creation and trusted indefinitely. AWS Config rules that specifically flag public bucket exposure, checked continuously rather than during periodic manual review, catch this class of mistake before it becomes a headline instead of after.
Threat: Compromised or Overly Permissive IAM Credentials
Credential compromise remains one of the most common initial access vectors into AWS environments specifically, and it's frequently made worse by IAM permissions that are far broader than the compromised credential actually needed for its legitimate function. A single compromised access key with administrative-level permissions gives an attacker essentially the same access a legitimate administrator has, immediately, without needing to do any additional work to escalate.
What actually stops this: Least-privilege IAM policies, scoped narrowly to what a role or user genuinely needs, limit the actual damage a single compromised credential can do even if compromise happens. Regular credential rotation, combined with genuinely eliminating long-lived access keys in favor of temporary credentials and IAM roles wherever technically feasible, shrinks the window during which a leaked credential remains usable at all. CloudTrail monitoring for anomalous API activity actions inconsistent with a given credential's normal usage pattern catches compromise in progress rather than only after the damage is already done and discovered downstream.
*Threat: Misconfigured Security Groups
*
Security groups configured too permissively 0.0.0.0/0 access to ports that should never be exposed to the broader internet, rules created during testing or troubleshooting that never got removed once the immediate need passed provide a direct, remarkably simple path into an environment for anyone actively scanning for exactly this kind of exposure, which happens constantly and automatically across the entire internet address space.
What actually stops this: Regular security group audits, specifically checking for overly broad rules and unused rules that have accumulated over time, close this gap directly. Infrastructure-as-code approaches, where security group configuration is defined, reviewed, and version-controlled rather than modified ad hoc through the console during a specific troubleshooting session, prevent a lot of this class of mistake from happening in the first place, because changes go through review instead of being made unilaterally in the moment under pressure.
*Threat: Insufficient Logging Preventing Effective Incident Response *
This isn't a threat that causes a breach directly, but it's a genuine threat to your ability to actually respond to one once it happens, and it shows up constantly during real incident investigations. Without comprehensive CloudTrail logging, VPC Flow Logs, and application-level logging, retained for a meaningful period, investigating what actually happened during an incident becomes difficult or in some cases genuinely impossible you know something happened, and you can't reconstruct how, which cost, and what else might have been touched.
What actually stops this: Comprehensive logging across CloudTrail, VPC Flow Logs, and relevant application layers, with retention periods long enough to support genuine investigation not the shortest window that happens to minimize storage cost, which is a decision usually made by someone who isn't the person who'll need those logs during an actual incident. Centralized log aggregation, actually reviewed regularly rather than just stored and forgotten until an incident forces someone to go looking, is what turns logging from a compliance checkbox into a genuine security capability.
*Threat: Container and Kubernetes-Specific Vulnerabilities *
For organizations running EKS or self-managed Kubernetes on AWS, container-specific vulnerabilities represent a distinct threat category that general AWS security practices don't fully cover on their own. Vulnerable container images, overly permissive Kubernetes RBAC configuration, and container escape vulnerabilities all provide potential paths to broader AWS environment compromise that start inside a container and don't necessarily stay contained there.
What actually stops this: Image scanning integrated into the CI/CD pipeline, catching known vulnerabilities before deployment rather than after. Genuine RBAC configuration, following least-privilege principles at the Kubernetes layer specifically, not just at the surrounding AWS IAM layer. Runtime security monitoring, watching for genuinely anomalous container behavior rather than just confirming containers are running and healthy, which same as with EC2 instances tells you nothing about whether something malicious is happening inside a technically healthy-looking container.
Threat: Data Exfiltration via Misconfigured VPC Endpoints or NAT Gateways
Network egress paths that aren't properly monitored or restricted provide a potential path for data exfiltration if an environment is compromised an attacker with access inside your VPC can potentially move data out through the same paths your legitimate traffic normally uses, unless those paths are specifically monitored for exactly this kind of anomalous activity.
What actually stops this: VPC Flow Log monitoring specifically for unusual outbound traffic patterns, not just general network health monitoring that would miss data volume anomalies. Egress filtering, restricting outbound traffic to genuinely necessary destinations rather than allowing broad, unrestricted internet access by default from resources that don't legitimately need it. DNS query monitoring, since data exfiltration attempts frequently attempt to use DNS as a covert channel specifically because it's less commonly monitored closely than other traffic types.
*Threat: Supply Chain Compromise Through Third-Party Integrations *
Third-party tools, integrations, and marketplace solutions connected to AWS environments introduce risk that originates entirely outside your own security controls and your own team's direct oversight. A compromised third-party integration can provide a path into your environment that bypasses your own security measures entirely, because it's operating with legitimate, already-granted access.
What actually stops this: Genuine scrutiny of third-party access before granting it, not just accepting a vendor's stated security posture as sufficient without any real verification. Regular review of exactly what access third-party integrations actually have, and whether that access still matches a real current need, not what it was originally granted for at onboarding. Least-privilege principles applied to third-party access specifically, with the same rigor applied to internal access a category that consistently gets less scrutiny than it should, precisely because it sits outside normal internal review processes and often gets set up once during onboarding and never revisited.
*Threat: Ransomware Targeting Cloud Backups Specifically *
Modern ransomware increasingly targets backup infrastructure specifically, attempting to delete or encrypt backups before triggering the main attack precisely because attackers know a working backup is what stands between an organization and having to pay a ransom, and eliminating that option first makes the rest of the attack far more effective.
What actually stops this: Immutable backup configurations, using S3 Object Lock or equivalent capability, that genuinely cannot be deleted or modified even by a compromised administrative account. Backup access controls, separated meaningfully from primary production access, so a single compromised credential can't reach both production data and the backups meant to protect against exactly this kind of compromise. Regular, genuine recovery testing, confirming backups actually work under real conditions rather than trusting that a backup process that appears to be running successfully is actually producing something restorable when it matters.
Building an Actual Threat-Informed Security Posture
Pulled together, defending against these specific, recurring threats requires:
Account-level default protections (S3 Block Public Access, for instance) rather than relying on correct configuration at every individual resource
Least-privilege IAM, genuinely enforced and regularly audited, not configured once at account setup and left static
Infrastructure-as-code for security-sensitive configuration, replacing ad hoc console changes made under time pressure
Comprehensive, adequately retained logging, actually reviewed on a real cadence, not just collected and stored
Container-specific security practices, distinct from general AWS security, for any organization running Kubernetes or containerized workloads
Egress monitoring and filtering, treating outbound traffic with the same scrutiny typically reserved for inbound
Real scrutiny of third-party access, reviewed on an ongoing basis rather than trusted indefinitely once granted
Immutable, tested backups, genuinely separated from primary production access
*The Actual Point *
None of the threats covered here require a sophisticated attacker to exploit successfully. Every one of them is a well-known, well-documented risk with a well-understood mitigation which is exactly what makes it uncomfortable when they still show up in real incidents as often as they do. The gap isn't awareness. It's consistent, ongoing implementation across an environment that keeps changing faster than any one-time security review can keep up with.
If you can't confidently say your organization has actually verified recently, not just assumed that none of these eight threat categories currently has an open gap somewhere in your AWS environment, that's genuinely worth checking before something else checks it for you.
Top comments (0)