S3 ransomware isn't theoretical. Trend Micro documented the rise of S3-specific ransomware variants in 2025 — attackers who obtain valid IAM credentials, systematically enumerate your buckets, exfiltrate the data, and then delete or re-encrypt the originals. The ransom demand comes after the data is already gone.
What makes S3 ransomware uniquely dangerous isn't its sophistication. It's its invisibility to conventional tools. Every single API call in the attack chain is authorized. No signatures fire. No known-bad IPs. Just legitimate API calls with legitimate credentials — at a pace and pattern that no human analyst would ever produce.
The 4-Step S3 Ransomware Pattern
Step 1: Credential Acquisition
Attack chains almost always start outside S3 entirely: a phishing email captures an employee's SSO credentials, a leaked .env file exposes AWS access keys from a public GitHub repository, a CI/CD pipeline misconfiguration leaves long-lived credentials in build logs, or a supply chain compromise embeds credential harvesting in a widely-used npm package.
The attacker now has valid IAM credentials — access key and secret — for a principal with S3 permissions. Nothing has happened yet in CloudTrail.
Step 2: Reconnaissance (ListObjectsV2)
With credentials in hand, the attacker runs an enumeration sweep: ListBuckets across the account, then ListObjectsV2 on every bucket they can access. This maps the full data landscape — which prefixes exist, how much data is in each, which files are most recently modified (and therefore most likely to contain current, valuable data).
- In CloudTrail: hundreds of ListObjects calls across unfamiliar prefixes in rapid succession
- GuardDuty signal: none — ListObjects is a legitimate API call, no threat intel signature exists
- Entroptics signal: new prefix access (this IAM role has never touched these prefixes), unusual breadth of resource access (CardinalityDetector), off-hours timing (TimeOfDay)
Step 2 is where Entroptics fires first. The reconnaissance sweep is highly anomalous for any established IAM role — accessing hundreds of prefixes it has never touched is an immediate multi-signal alert, even before a single byte of data moves.
Step 3: Exfiltration (GetObject at scale)
Having mapped the bucket structure, the attacker downloads the data that matters. For ransomware groups, this serves dual purpose: it's the leverage for the ransom demand ("pay us or we publish your data"), and it's insurance if the victim restores from backup.
The exfiltration typically runs at machine speed — thousands of GetObject calls per minute, far beyond human-possible rates. The target is usually the highest-value prefixes identified in the reconnaissance phase: customer data, financial records, intellectual property.
- In CloudTrail: thousands of GetObject calls, high data volume, often from a new source IP (attackers' infrastructure)
- GuardDuty signal: possibly — if the source IP is on AWS threat intelligence. Otherwise, nothing
- Entroptics signal: ExfiltrationDetector (volume + velocity pattern), BatchDetector (burst rate), IPDetector (new source IP for this role), all in parallel
Step 4: Destruction or Encryption
Once data is copied, the attacker either deletes the originals (DeleteObject in bulk), disables versioning and overwrites files with encrypted versions, or both. This is the moment the ransom demand becomes effective — the organization loses operational access to its own data.
By this point in a properly configured Entroptics deployment, the incident is already open and alerts have routed to Slack, PagerDuty, and the on-call analyst. The destruction phase is when human response matters — but only if the detection happened in step 2 or 3, not step 4.
- In CloudTrail: bulk DeleteObject calls, PutObject calls overwriting existing keys, DisableVersioning on buckets
- GuardDuty signal: possibly triggers S3 policy-related findings — too late
- Entroptics signal: FileLifecycleDetector (deletion patterns), SequenceDetector (PUT→GET→DELETE pattern = data staging)
Why GuardDuty Doesn't Stop This
GuardDuty's S3 threat detection looks for known-bad signals: threat-intelligence IPs, known malware callback domains, account-wide unusual API call patterns. It's excellent at what it does. But S3 ransomware uses valid credentials, often from clean IPs, making API calls that are individually authorized.
The attack's only signature is behavioral deviation from baseline — and that's precisely what GuardDuty doesn't model. It doesn't know that this IAM role has never accessed the finance/ prefix before. It doesn't know that this role's typical throughput is 200 objects per hour, not 8,000. It has no role-level behavioral baseline.
The defense against S3 ransomware is early-stage behavioral detection — catching the reconnaissance sweep (step 2) before the exfiltration begins (step 3). By step 4, you're already in incident response mode. Entroptics is designed to fire in step 2.
Defense Recommendations
- Enable S3 Object-Level CloudTrail logging — without data events, you cannot see GetObject or DeleteObject calls
- Apply MFA Delete to critical buckets — requires MFA to delete objects or disable versioning, adding friction to step 4
- Use S3 Versioning everywhere — even after deletion, data is recoverable for 30 days
- Configure S3 Object Lock (Compliance mode) for immutable backups — ransomware cannot delete locked objects
- Deploy behavioral detection — Entroptics fires at step 2 (reconnaissance) and step 3 (exfiltration), before data is gone
- Alert on first-time prefix access by any established IAM role — this is the highest-value early indicator