Data Destruction and Ransomware Investigated using Claude Code

Series: Agent-Driven Workflows - CrowdStrike Detection Triage. Post 3 of 5. Originally published on LinkedIn. Previous in series: Cloud Defense Evasion.

Detection Context

Impact detections sit at the end of an attack chain. By the time MITRE T1485 (Data Destruction) or T1486 (Data Encrypted for Impact) fires, the adversary has already completed initial access, persistence, and likely lateral movement. The triage goal is containment, blast radius assessment, and recovery scoping. Every minute of delay is data lost or encrypted.

This post covers detections across cloud and endpoint surfaces.

Cloud (Falcon Cloud Security):

• AWS Unusual RDS Database Deletion - MITRE ATT&CK T1485
• S3 Bucket Versioning Disabled - MITRE ATT&CK T1485
• Data Encrypted for Impact - MITRE ATT&CK T1486

Endpoint (Automated Leads):

• ProcRansomware - MITRE ATT&CK T1486
• DoubleExtensionWritten - MITRE ATT&CK T1486

These techniques are frequently executed in parallel by the same actor to maximize pressure on the victim.

Scenario

The alert queue contains multiple impact detections split across RDS deletion alerts in a single AWS account, S3 versioning suspension events across multiple buckets, and endpoint ransomware indicators spread across workstations in two offices. Something was actively running.

Situations like this - where a large volume of alerts needs to be reviewed on an expedited basis - are great candidates for processing by agentic workflows.

The RDS alerts carried skipFinalSnapshot values that could not be parsed at a glance without pulling CloudTrail. The S3 events needed immediate remediation regardless of intent - versioning disabled means any object deletion becomes permanent. The endpoint alerts needed process trees and network connections captured before considering isolation, because isolating before capturing the C2 destination IP means losing the key retrieval endpoint.

Three parallel prompt chains let the agent do the first-pass triage.

Prompt Chain

Prompt 1 - Cloud Alert Extraction and RDS Decision

You are a cloud security triage agent. I have a CrowdStrike Falcon alert for AWS Unusual RDS Database Deletion.

Pull the alert using: GET /alerts/entities/alerts/v2

Extract these fields: display_name, event_name (expect DeleteDBInstance), aws_recipient_account_id, source_account_name, resource_gcrn, aws_access_key_id, source_ip_address, first_timestamp.

Then pull CloudTrail for the same time window: aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteDBInstance

Parse skipFinalSnapshot from each event. Check for an open Jira ticket: POST /rest/api/3/search/jql body: { "jql": "created >= -2h AND text ~ \"<aws_access_key_id>\"" }

Check backup state: aws rds describe-db-snapshots --db-instance-identifier <resource_id> aws backup list-recovery-points-by-resource --resource-arn <resource_gcrn>

Apply the decision matrix and return a structured triage result with verdict, evidence, and recommended action.

Prompt 2 - S3 Versioning Remediation and Object Loss Assessment

Alerts indicate S3 bucket versioning has been disabled or suspended on one or more buckets.

For each affected bucket from the alert (field: resource_gcrn):

1. Re-enable versioning immediately: aws s3api put-bucket-versioning --bucket <bucket_name> --versioning-configuration Status=Enabled
2. Check for objects deleted after first_timestamp: aws s3api list-object-versions --bucket <bucket_name> - filter for DeleteMarkers with LastModified >= first_timestamp
3. Report: bucket name, versioning re-enabled (true/false), count of DeleteMarkers found, earliest deletion timestamp, and whether any objects are unrecoverable.

Return a table with one row per bucket.

Prompt 3 - Endpoint Ransomware Triage and Isolation Decision

We have ProcRansomware and DoubleExtensionWritten detections on multiple hosts.

For each affected host:

1. Pull the process tree: GET /incidents/queries/behaviors/v1 (filter by device.hostname), GET /incidents/entities/behaviors/GET/v1. Identify: ransomware binary path, parent process, grandparent process.
2. Check network connections from the ransomware process. Capture destination IP before any isolation action - this is the C2 key retrieval endpoint.
3. Determine blast radius via RTR: list mapped drives, check UNC paths accessible from the host.
4. Isolate the host: POST /devices/entities/devices-actions/v2 body: { "action_name": "contain", "ids": ["<device_id>"] }
5. Check spread across the environment: GET /alerts/queries/alerts/v2 filter: SHA256HashData = <ransomware_binary_hash>

Return: hostname, binary path, C2 IP captured (true/false), mapped drives count, isolation status, other hosts with matching hash.

Agent Workflow

Step 1 - Pull and Enrich Cloud Alerts

The agent calls GET /alerts/entities/alerts/v2 for all cloud alerts (RDS + S3). Key fields extracted per alert:

Field	RDS Alert Value	S3 Alert Value
display_name	AWS Unusual RDS Database Deletion	S3 Bucket Versioning Disabled
event_name	DeleteDBInstance	PutBucketVersioning
aws_recipient_account_id	123456789012	123456789012
source_account_name	prod-data-west	prod-data-west
resource_gcrn	arn:aws:rds:…	arn:aws:s3:…
aws_access_key_id	AKIA…	AKIA…
source_ip_address	185.220.101.x	185.220.101.x
first_timestamp	2026-09-13T07:14:32Z	2026-09-13T07:16:48Z

Same source IP across RDS and S3 alerts. Same access key. This is one actor, one session.

Step 2 - CloudTrail Pull and skipFinalSnapshot Parse (RDS)

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteDBInstance \
  --start-time <window-start> \
  --end-time <window-end> \
  --region us-west-2

The agent parses requestParameters.skipFinalSnapshot from each event. Result: the vast majority of deletions had skipFinalSnapshot=true. No final snapshots taken. Recovery depends entirely on automated backup state.

Step 3 - Backup Verification (RDS)

aws rds describe-db-snapshots \
  --db-instance-identifier <instance_id> \
  --snapshot-type automated

aws backup list-recovery-points-by-resource \
  --resource-arn <resource_gcrn>

The agent checks each deleted instance. Most have recovery points within the backup retention window. A handful do not - these are the critical loss items that need to be communicated immediately.

Step 4 - Jira Ticket Check (RDS)

POST /rest/api/3/search/jql
{
  "jql": "created >= -2h AND text ~ \"AKIA...\"",
  "maxResults": 10
}

Zero matching tickets. No authorized change request for this access key. Combined with external source IP and skipFinalSnapshot=true: escalate immediately.

Step 5 - Mass Deletion Hunt (CQL)

#repo=search-all eventSource="rds.amazonaws.com" eventName="DeleteDBInstance"
| select([eventTime, userIdentity.arn, userIdentity.accessKeyId,
          requestParameters.dBInstanceIdentifier,
          requestParameters.skipFinalSnapshot, sourceIPAddress])
| groupBy([userIdentity.accessKeyId],
          function=[count(as=deletion_count),
                    collect([requestParameters.dBInstanceIdentifier]),
                    min(eventTime, as=first_deletion)])
| sort(deletion_count, order=desc)

Result: a single access key responsible for the full set of deletions, all from one session. No other keys involved.

Step 6 - S3 Versioning Disabled Hunt and Remediation (CQL + AWS CLI)

Hunt first to scope the full bucket list:

#repo=search-all eventSource="s3.amazonaws.com"
(eventName="PutBucketVersioning"
  requestParameters.VersioningConfiguration.Status="Suspended")
OR eventName="DeleteBucketVersioning"
| select([eventTime, eventName, userIdentity.arn, userIdentity.accessKeyId,
          requestParameters.bucketName, sourceIPAddress])
| sort(eventTime, order=desc)

The agent re-enables versioning on every affected bucket in sequence:

aws s3api put-bucket-versioning \
  --bucket <bucket_name> \
  --versioning-configuration Status=Enabled

Then checks each bucket for DeleteMarkers after first_timestamp:

aws s3api list-object-versions --bucket <bucket_name>

Step 7 - Endpoint Ransomware Process Tree

GET /incidents/queries/behaviors/v1?filter=device.hostname:'WORKSTATION-042'
GET /incidents/entities/behaviors/GET/v1

The agent identifies the process tree per host:

Level	Process
Grandparent	explorer.exe
Parent	cmd.exe (spawned from phishing attachment)
Ransomware Binary	svchost32.exe (C:\Users\Public\svchost32.exe)

SHA256 captured for the lateral spread check.

Step 8 - C2 IP Capture Before Isolation

The agent reads active network connections for the ransomware process before issuing contain. The destination IP is logged - this is the C2 endpoint used for key retrieval. Captured and handed to threat intelligence before the host is cut off.

Step 9 - Blast Radius via RTR

The agent runs RTR commands to enumerate mapped drives and UNC paths accessible from each affected host. Some hosts had mapped network shares. Those shares are flagged for immediate review - any files written after ransomware execution time are potential collateral encryption.

Step 10 - Host Isolation

POST /devices/entities/devices-actions/v2
{
  "action_name": "contain",
  "ids": ["<device_id_1>", "<device_id_2>", ...]
}

All affected endpoints contained in one API call.

Step 11 - Lateral Spread Check (CQL)

#repo=search-all event.simpleName=ProcessRollup2
SHA256HashData="<hash_from_step_7>"
| select([ComputerName, UserName, ImageFileName, CommandLine,
          ParentImageFileName, timestamp])
| sort(timestamp, order=desc)

A few additional hosts found with the matching hash that had not yet triggered ProcRansomware. Added to the isolation batch.

Step 12 - Endpoint Ransomware Broad Hunt (CQL)

#repo=search-all
event.simpleName=DoubleExtensionWritten OR event.simpleName=ProcRansomware
| select([event.simpleName, ComputerName, UserName,
          FileName, FilePath, CommandLine, SHA256HashData, timestamp])
| groupBy([ComputerName],
          function=[count(as=event_count), collect([FileName])])
| sort(event_count, order=desc)

Confirms the known affected hosts. No additional hosts found outside the already-identified set.

Output and Decision

RDS Deletion - Decision Matrix

skipFinalSnapshot	Jira Ticket	Source IP Type	Verdict	Action
false	Yes	Internal	Monitor	Log and close
false	No	Internal	Investigate	Validate with IAM owner
true	No	External	Escalate Immediately	Incident response
true	Any	Any	Verify Recovery Point	Confirm backup before closing

Verdict: True Positive - Active Incident. The overwhelming majority of RDS deletions had skipFinalSnapshot=true, no Jira ticket, and an external source IP. Immediate escalation triggered. A subset of instances confirmed unrecoverable from backup.

S3 Versioning - Verdict

True Positive. Versioning re-enabled on all affected buckets. DeleteMarker analysis in progress across all buckets to determine object loss. No buckets had point-in-time recovery configured independently of versioning.

Endpoint Ransomware - Verdict

True Positive. Affected hosts isolated. Additional hosts identified via hash hunt and contained before triggering detections. C2 IP captured. Blast radius mapped to a small number of network shares. Recovery scoping handed to the IR team.

Prerequisites

Access required:

System	Scope
CrowdStrike Falcon API	Alerts read/write, Incidents read, RTR active responder
AWS CloudTrail	Lookup events, read access across affected regions
AWS RDS	describe-db-snapshots, restore access
AWS S3	put-bucket-versioning, list-object-versions
AWS Backup	list-recovery-points-by-resource
Jira API	Token with project read, JQL search
Slack Webhook	Incident notification channel

Context the agent needs:

• Falcon Alerts API reference (v2 schema, filter syntax)
• Incidents and Behaviors API reference (process tree retrieval)
• RTR command reference (drive enumeration, UNC path checks)
• CQL and LogScale syntax reference
• CloudTrail event schemas for RDS and S3 (field names, nested parameter paths)
• AWS Backup and RDS snapshot API reference
• MITRE T1485 and T1486 technique context (actor patterns, tool signatures)

Impact detections reward agents that can work in parallel and move fast. The cloud destruction and endpoint ransomware workflows are independent enough to run concurrently - the agent does not need the RDS result to start isolating endpoints. Once the workflows are codified as a prompt chain, the first-pass triage runs in a fraction of the time it takes to work through a large alert set manually.

The audit trail is the other payoff: every API call, every CloudTrail lookup, every isolation action is logged with the alert ID it corresponds to, which makes the post-incident timeline reconstruction considerably less painful.

---

Next in series: Remote Access Abuse and Reverse Shells - triaging RMM abuse and reverse shell detections.

---

Want automated incident response playbooks for your cloud environment? See how 543HQ builds agentic security workflows.