Ransomware in Amazon S3: Detect the Burst, Not the Ransom Note

Ransomware on AWS rarely looks like ransomware on a laptop. There is no binary to scan and no endpoint agent to raise an alarm. An attacker with valid credentials can encrypt or delete your data using the same S3 API your applications use every second. The first visible sign is often a text file named README_RESTORE.txt in an empty bucket.

The good news: the attack is loud. It needs thousands of API calls in a short time, and each call is an event you can count. This article explains how to detect it in the first minutes, and how to stop it without disrupting legitimate workloads.

How an S3 ransomware attack works

A typical attack has five steps:

1. Get credentials. A leaked access key, a compromised CI role, or an over-permissive instance profile on an exposed server.
2. Enumerate. List buckets, then list objects and object versions to find valuable data and check whether versioning can save the victim.
3. Remove the safety net. Suspend bucket versioning, add lifecycle rules that expire old versions, or change the bucket policy.
4. Encrypt or destroy. Either copy each object onto itself with an encryption key the attacker controls (CopyObject with SSE-C or an attacker-owned KMS key), or download the data and then delete it (GetObject followed by DeleteObject / DeleteObjects).
5. Leave the note. One PutObject with payment instructions.

Steps 2 and 4 generate volume. Step 3 generates rare, high-value events. Good detection watches both.

Prerequisite: turn on S3 data events (selectively)

Bucket-level actions such as PutBucketVersioning are CloudTrail management events and are logged by default. Object-level actions — GetObject, PutObject, CopyObject, DeleteObject, ListObjectsV2 — are data events, and CloudTrail does not log them unless you enable it.

Data events are billed per event (at the time of writing, $0.10 per 100,000 events). A bucket that serves a busy website can produce a large bill. Do not enable data events on every bucket. Enable them on the buckets that would hurt to lose: backups, customer uploads, data lake raw zones, financial exports.

The signals and the thresholds

Use counts over a sliding window, per identity. These starting values work well for most environments; tune them with your own baseline.

Detection	Events counted	Starting threshold	Why
Enumeration	ListBuckets, ListObjectsV2, ListObjectVersions	60 calls across 5+ distinct buckets in 5 min	Applications usually list the same one or two buckets; attackers sweep
Mass write / re-encryption	PutObject, CopyObject	50 in 5 min	Encryption-in-place is a CopyObject per object
Mass delete	DeleteObject, DeleteObjects	50 in 5 min	Destroy phase
Bulk read	Object read events	Anomalous volume in a short window	Exfiltration before deletion
Versioning tampering	PutBucketVersioning	Any	Rare in normal operation; high value
Public access block removed	PutBucketPublicAccessBlock, DeleteBucketPublicAccessBlock, account-level equivalents	Any	Often precedes exfiltration
Backdoor bucket policy	PutBucketPolicy granting an external principal or *	Any	Persistence or exfiltration path
KMS tampering	DisableKey, ScheduleKeyDeletion, PutKeyPolicy	Any	Makes your own encrypted data unreadable

Why these numbers? Speed. At 50 objects in 5 minutes, an automated response contains the identity after a few hundred objects at most. Without it, a script running at full speed can touch millions of objects before a human reads the first alert.

The false positive problem

Every S3-heavy organization has legitimate jobs that look exactly like ransomware: nightly backups that write thousands of objects, ETL jobs that copy whole prefixes, retention jobs that delete old logs. If your first containment rule blocks the backup role at 02:00, you will not get a second chance to automate.

Handle this with scope, not with higher thresholds:

• Exclude known job identities from write and delete rules by principal ARN, and give those roles narrow permissions so that their exclusion is not a blind spot.
• Scope rules to protected buckets. Apply the strict mass-write rule to backup and data lake buckets, not to a scratch bucket that a build system churns all day.
• Gate on resource context. For example, only act if the bucket carries a data-classification tag, or has versioning enabled. If the context lookup fails, the rule should still fire — a missing inventory snapshot must never suppress a real detection.

A safe rollout plan

Week 1 — observe. Enable all the detections above as notify-only. Review every match. For each false positive, add a scope rule, not a threshold increase.

Week 2 — contain on destruction. Add automatic containment to the mass-delete and mass-write rules for the protected buckets. Keep enumeration notify-only; enumeration alone does not destroy data, and legitimate tools do it too.

Week 3 — human-in-the-loop for the rest. Add a one-click containment link to the enumeration and bulk-read alerts, so the on-call engineer can contain from a phone without logging in.

Every automated containment must be reversible. If the rule contains a legitimate role, you want to release it in one click and tune the scope, not open a ticket with the IAM team.

Containment is not recovery

Containing the identity stops the attack. It does not bring back data. Recovery depends on controls you set up before the incident:

• Versioning on every critical bucket, with an alert when it is suspended.
• S3 Object Lock (retention mode) on backup buckets, so that even an administrator cannot delete protected versions during the retention period.
• Replication to a separate account that the production identities cannot write to.
• MFA delete or restrictive bucket policies on the replication target.

Test a restore at least once. A backup that has never been restored is a hypothesis.

Checklist

• Data events enabled on critical buckets only
• Enumeration, mass write, mass delete and bulk read rules per identity
• Alerts on versioning, public access block, bucket policy and KMS changes
• Known job roles excluded by ARN; rules scoped to protected buckets
• One week in notify-only mode before containment
• Automatic, reversible containment on mass write and mass delete
• Versioning, Object Lock and cross-account replication for recovery

How AWS Cloud Governance helps

AWS Cloud Governance ships every detection in the table above as a pre-built template, and runs them inside your own AWS account:

• Threshold-window templates for ransomware enumeration, mass write, mass delete and S3 data exfiltration, plus field-match templates for versioning tampering, public access block removal, backdoor bucket policies and KMS key tampering.
• Rules scoped by account, region, resource and filter, with overridable thresholds and an inventory-based resource gate that fails open.
• Runbooks that notify, contain the principal automatically, or send a one-click containment link — and an execution history that shows exactly which rule fired and what it did.
• Reversible actions. Every containment appears in the Actions log with a Rollback button.

Start a free 3-month trial at https://trustpartners.tech.