Investigate a Ransomware Attack in AWS using Splunk

What this lab covers

You investigate a ransomware incident in an AWS environment using Splunk over CloudTrail data, establishing what the attacker did, in what order, and what was actually lost.

The lab teaches scoping rather than detection. The event has already happened, and the work is answering the questions an executive and a regulator will ask, which is a distinct skill from writing alerts.

It is rated intermediate and suits incident responders and security operations engineers.

How cloud ransomware differs from endpoint ransomware

Traditional ransomware executes on hosts and encrypts files, which is why endpoint detection is the usual control. Cloud extortion does not need to do that, because an identity with sufficient permissions can act on data directly through service APIs.

The attacker's preparation is therefore about permissions and recovery rather than payloads. They obtain an identity that can act on data, then remove the paths that would let you recover: deleting backups, disabling versioning and soft delete, removing snapshots and changing lifecycle rules.

That preparation is the most detectable phase and it happens before impact. By the time data is destroyed the decision has already been made, so the configuration changes that precede it are where response has any leverage.

How to detect this in your own environment

Alert on the destruction of recovery capability. Deleting backups, disabling versioning, removing snapshots and changing retention are all control plane events, they are rare, and they precede the impact.

Watch for bulk operations against data. Mass deletion or modification has a rate signature quite unlike normal application behavior, and it is visible in data events where those are enabled.

Track identity behavior rather than file behavior. In cloud extortion the malicious actor is an authenticated principal doing permitted things, so the anomaly is which identity is acting and how broadly, not what a process is doing on a host.

How to prevent it

Put backups outside the blast radius. A backup in the same account with the same access controls is not a backup for this threat model, and a separate account with independent credentials is the baseline.

Use object lock and immutability where the data justifies it, so retention cannot be shortened even by an administrator. This is the control that survives full control plane compromise.

Constrain deletion permissions and require multi-factor authentication for destructive operations, so the identity an attacker obtains is less likely to hold the ability to remove your recovery path.

Real-world context

Extortion targeting cloud data has grown as organizations moved data into managed services, and reporting on cloud-focused actors describes exfiltration and destruction through platform APIs rather than endpoint encryption.

The regulatory dimension makes the timeline reconstruction essential rather than optional. Notification regimes ask which data was affected and when, and an organization that cannot answer precisely usually has to notify more broadly than the facts require.

The pattern maps to MITRE ATT&CK T1485 Data Destruction, T1490 Inhibit System Recovery and T1567 Exfiltration Over Web Service.

Applying this at work

• Confirm your backups live in a separate account with credentials that a compromise of the primary environment would not yield.
• Enable object lock or immutability on data whose loss would be material.
• Alert on backup deletion, versioning changes and retention policy modification.
• Run a tabletop where the question is what was taken and when, not whether an alert fired.
• Check whether any single identity in your environment can both access data and destroy the means of recovering it.

Frequently asked questions

Does cloud ransomware involve malware?

Often not. An identity with sufficient permissions can delete, encrypt or exfiltrate data through the platform's APIs, so endpoint-focused controls may see nothing at all while the incident proceeds.

What is the earliest reliable signal?

Destruction of recovery capability. Deleting backups, disabling versioning and shortening retention are control plane events that precede the impact and are rare enough to alert on individually.

Why does the timeline matter so much?

Because breach notification requires knowing which data was affected and when. Without a reconstructed timeline organizations typically over-notify, which is more costly and more damaging than the precise answer.

Do I need my own AWS account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.