Notifications
Clear all
Topic starter
18/08/2026 2:45 pm
TL;DR: S3 ransomware campaigns are increasingly chaining AWS-native features such as ABAC, tagging, and legitimate service calls to turn ordinary access into encryption and deletion paths, according to OFFENSAI. The lesson for identity teams is that configuration checks are not enough when attackers can exploit the permission logic already embedded in cloud infrastructure.
NHIMG editorial — based on content published by OFFENSAI: S3 Ransomware Attacks: The S3 Heist Nobody's Talking About
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
Questions worth separating out
Q: What breaks when ABAC is used without strong lifecycle governance?
A: Access decisions begin to reflect outdated roles, locations, and business relationships instead of current reality.
Q: Why do over-permissioned cloud identities create so much risk?
A: Over-permissioned identities create risk because an attacker only needs one useful permission to expand access, alter controls, or reach sensitive data.
Q: How can security teams tell whether a CSPM finding is actually exploitable?
A: They cannot tell from posture data alone.
Practitioner guidance
- Restrict who can influence authorization tags Limit write access to S3 and IAM tag fields to tightly controlled administrative identities, and separate operational tagging from policy-bearing tags such as environment or data-classification tags.
- Test ABAC paths for destructive reachability Use live-path validation to check whether tag changes, role chaining, and service creation can actually reach production buckets, not just whether the policy model looks sound on paper.
- Correlate legitimate AWS services into one incident story Tune detection to treat Lambda creation, CloudFormation stacks, Systems Manager sessions, and unusual tag edits as a single attack sequence when they occur together.
What's in the full article
OFFENSAI's full article covers the operational detail this post intentionally leaves for the source:
- The step-by-step ABAC attack chain across S3, Lambda, CloudFormation, and Systems Manager.
- The specific tag-and-policy combinations that create escalation risk in AWS environments.
- The practical validation method used to test whether IAM boundaries and SCPs stop the chain.
- The ransomware endgame details, including encryption and deletion mechanics tied to KMS control paths.
👉 Read OFFENSAI's analysis of ABAC-driven S3 ransomware attack paths →
S3 ransomware via ABAC: what IAM teams need to validate?
Explore further
18/08/2026 3:28 pm
ABAC introduces a tag-governance problem, not just an authorization pattern. Once tag values can influence access across many buckets, the security question shifts from "who has this role?" to "who can change the attributes that grant the role?" That is a classic identity governance issue expressed through cloud-native controls. IAM teams need to treat tag lifecycle, tag ownership, and policy conditions as part of access control design, not as metadata hygiene.
A question worth separating out:
Q: Who is accountable for ransomware containment when identity controls fail first?
A: Accountability sits with the teams that own identity, privilege, and directory governance together, not with endpoint security alone. If identity telemetry, PAM policy, and AD visibility are not aligned, the organisation has no reliable control boundary to stop escalation. NIST CSF and internal resilience governance should reflect that shared responsibility.
👉 Read our full editorial: ABAC-driven S3 ransomware shows the real cloud identity gap
