Ransomware 3.0 and Multi-Stage Extortion: Defence, Detection, and Recovery

Problem

Ransomware in 2020 was straightforward: encrypt the victim’s files, demand payment for the decryption key. If you had backups, you could recover without paying.

Ransomware in 2026 is a multi-stage extortion operation:

1. Data theft first. Before encrypting anything, the attackers spend days or weeks exfiltrating sensitive data: customer records, source code, financial documents, employee data, legal communications. This happens silently while the attacker has persistent access.
2. Encryption second. After exfiltration is complete, the attackers deploy the encryption payload. By this point, restoring from backups solves the encryption problem but not the data exposure problem.
3. Extortion layers. The attackers demand payment under multiple simultaneous threats: publish the stolen data, sell it to competitors, report regulatory violations to authorities, notify affected customers directly, and launch DDoS attacks against the victim’s infrastructure to increase pressure.
4. Professionalized operations. Ransomware-as-a-Service (RaaS) groups operate like businesses: affiliate programmes recruit operators, dedicated negotiation teams handle victim communication, support desks assist affiliates, and pricing is calibrated to the victim’s revenue and insurance coverage.

This means backups alone are no longer sufficient. You need:

• Controls that prevent data exfiltration (the first stage)
• Detection that identifies pre-encryption behaviour (the dwell time)
• Immutable backups that survive even if the attacker has admin access
• A recovery plan that works without paying and accounts for data exposure

Threat Model

• Adversary: RaaS affiliate or direct operator. Access typically obtained via phishing (AI-generated), exploited vulnerability, or purchased credentials from initial access brokers. Dwell time before encryption averages 5-14 days.
• Access level: Domain admin or equivalent. The attacker escalates privileges during the dwell period to ensure encryption reaches the maximum number of systems and backups.
• Objective: Multi-stage extortion. Primary: payment of ransom (typically 1-5% of victim’s annual revenue). Secondary: data sale if ransom is not paid. Tertiary: DDoS and customer notification to increase pressure.
• Blast radius: The entire organisation. Encryption targets all reachable file systems, databases, and backup storage. Data exfiltration targets the most sensitive data the attacker can find. DDoS targets public-facing services.

The key shift: Ransomware is no longer a malware problem. It is an intrusion problem with a malware finale. The encryption payload is the last thing that happens. If you detect the intrusion during the dwell period (5-14 days), you can prevent both the exfiltration and the encryption.

Configuration

1. Detect the Dwell Period: Pre-Encryption Behaviour

Ransomware operators follow a predictable pattern during the dwell period: reconnaissance, privilege escalation, lateral movement, data staging, and exfiltration. Detect these behaviours before the encryption payload deploys.

Detect data staging (large file creation and compression):

# falco-ransomware-staging.yaml
- rule: Large Archive Creation
  desc: >
    A process created a large archive file. Ransomware operators stage
    stolen data as compressed archives before exfiltration.
  condition: >
    ((evt.type = open and evt.arg.flags contains O_CREAT)
     or evt.type = openat)
    and fd.name endswith_any (.tar.gz, .zip, .7z, .rar, .tar.bz2, .tar.xz)
    and not proc.name in (backup-agent, restic, borgbackup, tar)
    and not proc.pname in (cron, systemd, backup-agent)
  output: >
    Archive file created by unexpected process (possible data staging)
    (file=%fd.name process=%proc.name parent=%proc.pname
     user=%user.name container=%container.name pod=%k8s.pod.name)
  priority: WARNING
  tags: [ransomware, data-staging]

- rule: Mass File Read
  desc: >
    A single process is reading a large number of files rapidly.
    This matches both data exfiltration staging and pre-encryption
    scanning by ransomware.
  condition: >
    open_read
    and container
    and proc.name != find
    and not proc.name in (grep, rg, fd, locate, updatedb, backup-agent, restic)
  output: >
    Rapid file reads by unexpected process
    (process=%proc.name parent=%proc.pname file=%fd.name
     container=%container.name pod=%k8s.pod.name)
  priority: NOTICE
  tags: [ransomware, reconnaissance]

Detect mass encryption (the payload itself):

# falco-ransomware-encryption.yaml
- rule: Mass File Rename with Known Ransomware Extensions
  desc: >
    Files are being renamed with extensions commonly used by ransomware.
    This is a high-confidence indicator that encryption has begun.
  condition: >
    evt.type in (rename, renameat, renameat2)
    and evt.arg.newpath endswith_any (.encrypted, .locked, .crypt, .enc, .ransom)
  output: >
    RANSOMWARE ENCRYPTION DETECTED - files being renamed with ransom extension
    (new_name=%evt.arg.newpath process=%proc.name parent=%proc.pname
     user=%user.name container=%container.name pod=%k8s.pod.name)
  priority: CRITICAL
  tags: [ransomware, encryption, active-attack]

- rule: High Volume File Write Operations
  desc: >
    A single process is writing to a large number of files rapidly.
    This matches ransomware encryption behaviour.
  condition: >
    evt.type in (write, pwrite64, writev)
    and container
    and evt.rawres > 0
    and not proc.name in (rsync, cp, dd, restic, borgbackup, backup-agent, tar)
  output: >
    High-volume write operations by unexpected process
    (process=%proc.name parent=%proc.pname
     container=%container.name pod=%k8s.pod.name)
  priority: WARNING
  tags: [ransomware, encryption]

2. Prevent Data Exfiltration

The first stage of modern ransomware is data theft. Block or detect large data transfers to external destinations.

Detect large outbound transfers:

# prometheus-exfiltration-detection.yaml
groups:
  - name: exfiltration-detection
    interval: 1m
    rules:
      # Alert on sustained large outbound data transfer
      - alert: LargeOutboundTransfer
        expr: >
          rate(container_network_transmit_bytes_total[5m])
          > 10 * 1024 * 1024
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Sustained outbound transfer >10MB/s from {{ $labels.pod }}"
          description: >
            Pod is transmitting data at >10MB/s for more than 10 minutes.
            May indicate data exfiltration. Verify against known backup
            and replication schedules.

      # Alert on outbound transfer to a new destination
      - alert: OutboundToNewDestination
        expr: >
          rate(container_network_transmit_bytes_total[5m]) > 1024 * 1024
          unless on (pod, destination)
          rate(container_network_transmit_bytes_total[5m] offset 7d) > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Data transfer to new destination from {{ $labels.pod }}"

Restrict egress with network policies:

# egress-restriction.yaml
# Database pods should never make outbound connections to the internet.
# If ransomware compromises a database pod, it cannot exfiltrate data.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-egress-restrict
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Egress
  egress:
    # Only allow connections to replication peers and monitoring
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

3. Deploy Immutable Backups

Ransomware operators target backup systems to prevent recovery. Immutable backups cannot be modified or deleted, even by an attacker with admin access.

Configure immutable backups with Restic to S3-compatible storage:

#!/bin/bash
# backup-immutable.sh
# Backup to S3-compatible storage with object lock (immutable).

RESTIC_REPOSITORY="s3:s3.amazonaws.com/company-backups-immutable"
RESTIC_PASSWORD_FILE="/etc/restic/password"

# Backup databases
pg_dumpall -U postgres | restic backup --stdin --stdin-filename db-dump.sql

# Backup configuration
restic backup /etc /opt/configs

# Backup application data
restic backup /data

# Verify backup integrity
restic check

# Prune old backups (retention policy)
# Object lock prevents deletion before the retention period
restic forget --keep-daily 30 --keep-weekly 12 --keep-monthly 12

Configure S3 bucket with Object Lock (immutable retention):

# Create S3 bucket with Object Lock enabled
aws s3api create-bucket \
  --bucket company-backups-immutable \
  --region eu-west-1 \
  --create-bucket-configuration LocationConstraint=eu-west-1 \
  --object-lock-enabled-for-bucket

# Set default retention policy: 30 days compliance mode
# Compliance mode: NO ONE can delete objects before retention expires,
# not even the root account. This is critical for ransomware defence.
aws s3api put-object-lock-configuration \
  --bucket company-backups-immutable \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 30
      }
    }
  }'

# Restrict bucket access to backup service account only
aws s3api put-bucket-policy \
  --bucket company-backups-immutable \
  --policy '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {"AWS": "arn:aws:iam::123456789012:role/backup-agent"},
        "Action": ["s3:PutObject", "s3:GetObject", "s3:ListBucket"],
        "Resource": [
          "arn:aws:s3:::company-backups-immutable",
          "arn:aws:s3:::company-backups-immutable/*"
        ]
      },
      {
        "Effect": "Deny",
        "Principal": "*",
        "Action": ["s3:DeleteObject", "s3:PutBucketPolicy"],
        "Resource": [
          "arn:aws:s3:::company-backups-immutable",
          "arn:aws:s3:::company-backups-immutable/*"
        ],
        "Condition": {
          "StringNotEquals": {
            "aws:PrincipalArn": "arn:aws:iam::123456789012:role/security-admin"
          }
        }
      }
    ]
  }'

Automate backup verification:

#!/bin/bash
# verify-backups.sh
# Weekly backup verification: restore a backup and validate it.

RESTIC_REPOSITORY="s3:s3.amazonaws.com/company-backups-immutable"
RESTIC_PASSWORD_FILE="/etc/restic/password"
RESTORE_DIR="/tmp/backup-verify-$(date +%s)"

mkdir -p "${RESTORE_DIR}"

# Restore the latest database backup
restic restore latest --target "${RESTORE_DIR}" --include "db-dump.sql"

# Verify the database dump is valid
pg_restore --list "${RESTORE_DIR}/db-dump.sql" > /dev/null 2>&1
RESTORE_STATUS=$?

if [ ${RESTORE_STATUS} -eq 0 ]; then
  echo "BACKUP VERIFICATION: PASS - database restore successful"
else
  echo "BACKUP VERIFICATION: FAIL - database restore failed"
  # Send alert
fi

# Clean up
rm -rf "${RESTORE_DIR}"

# Schedule weekly verification
# /etc/cron.d/backup-verify
0 3 * * 0 root /opt/scripts/verify-backups.sh >> /var/log/backup-verify.log 2>&1

4. Automated Containment

When ransomware encryption is detected, automated containment limits the blast radius.

# falcosidekick-ransomware-response.yaml
# Automated response for confirmed ransomware indicators.

# Quarantine pod: apply deny-all network policy
- action: kubernetes
  parameters:
    event_severity: Critical
    rule_name_regex: ".*RANSOMWARE ENCRYPTION.*"
    action: label
    labels:
      quarantine: "true"
    # A NetworkPolicy matching quarantine=true blocks all traffic

# Send immediate alert to incident response team
- action: webhook
  parameters:
    event_severity: Critical
    rule_name_regex: ".*RANSOMWARE.*"
    url: "https://hooks.slack.com/services/WEBHOOK_URL"
    payload: >
      {
        "text": "RANSOMWARE ALERT: {{ .Rule }} detected in pod {{ .OutputFields.k8s.pod.name }}
        in namespace {{ .OutputFields.k8s.ns.name }}.
        Process: {{ .OutputFields.proc.name }}
        IMMEDIATE ACTION REQUIRED."
      }

# quarantine-network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: quarantine-deny-all
  namespace: production
spec:
  podSelector:
    matchLabels:
      quarantine: "true"
  policyTypes:
    - Ingress
    - Egress
  ingress: []
  egress: []

5. Recovery Procedure

#!/bin/bash
# ransomware-recovery.sh
# Recovery procedure for ransomware incident.
# Run AFTER containment and forensic evidence preservation.

set -e

echo "=== RANSOMWARE RECOVERY PROCEDURE ==="
echo "Time: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo "Operator: $(whoami)"
echo ""

echo "Step 1: Verify backup integrity"
restic check
restic snapshots

echo ""
echo "Step 2: Identify latest clean backup"
echo "Select a snapshot BEFORE the estimated compromise date."
restic snapshots
read -p "Enter snapshot ID to restore: " SNAPSHOT_ID

echo ""
echo "Step 3: Restore to clean infrastructure"
echo "IMPORTANT: Restore to NEW infrastructure, not the compromised systems."
echo "The compromised systems may still contain persistence mechanisms."

# Restore database
restic restore "${SNAPSHOT_ID}" --target /tmp/restore --include "db-dump.sql"
echo "Database backup extracted to /tmp/restore/db-dump.sql"

echo ""
echo "Step 4: Post-restoration checklist"
echo "[ ] Rotate ALL credentials (database, API keys, service accounts)"
echo "[ ] Rotate ALL SSH keys and certificates"
echo "[ ] Revoke ALL active sessions and tokens"
echo "[ ] Re-deploy applications from clean container images (rebuild, do not reuse)"
echo "[ ] Verify restored data integrity"
echo "[ ] Update DNS to point to new infrastructure"
echo "[ ] Monitor for re-infection (the attacker may still have initial access)"
echo ""
echo "Step 5: Address data exposure"
echo "[ ] Identify what data was exfiltrated (from forensic analysis)"
echo "[ ] Notify affected parties per regulatory requirements"
echo "[ ] Engage legal counsel for data breach notification obligations"
echo "[ ] File law enforcement report"

Expected Behaviour

• Dwell period detection: Data staging (archive creation), mass file reads, and privilege escalation trigger alerts within minutes. Expected dwell period detection coverage: 80%+ of known ransomware TTPs.
• Exfiltration prevention: Egress network policies prevent database pods from reaching the internet. Large outbound transfers to new destinations trigger alerts.
• Immutable backups: S3 Object Lock in compliance mode prevents backup deletion for 30 days, even by root. Weekly backup verification confirms restorability.
• Automated containment: Confirmed encryption triggers immediate pod quarantine (network isolation) and incident response notification within 2 minutes.
• Recovery: Clean infrastructure deployed from immutable backups within 4-8 hours. All credentials rotated. Applications rebuilt from source (not restored from compromised images).

Trade-offs

Failure Modes

When to Consider a Managed Alternative

Transition point: Ransomware defence requires 24/7 monitoring, sub-minute containment, immutable backup management, and incident response capability. Self-managed detection and response is viable for small teams (under 10 engineers) with limited infrastructure. Beyond that, the SOC requirements exceed what most engineering teams can staff.

• Sysdig: Runtime ransomware detection for containers and Kubernetes. Drift detection identifies when a running container has been modified from its image (binary dropped, files encrypted). Managed Falco rules updated for emerging ransomware TTPs.
• CrowdStrike Falcon: Endpoint and cloud workload protection with ML-based ransomware prevention. Detects and blocks encryption behaviour in real time. Managed threat hunting identifies dwell-period activity that automated detection misses.
• Backblaze B2: S3-compatible object storage with Object Lock support at significantly lower cost than AWS S3. Immutable backup storage for ransomware-resilient backup architecture.

Premium content pack: Ransomware defence templates. Falco rules for dwell-period detection (staging, encryption, exfiltration). Immutable backup configuration scripts for AWS S3, GCP Cloud Storage, and Backblaze B2. Automated containment configurations. Recovery procedure checklists. Incident response playbook for multi-stage extortion.

Related Articles

• Identity Abuse and Credential Compromise: Defending Against Attackers Who Log In Instead of Break In
• Detecting AI-Generated Attacks: Moving from Signatures to Behavioural Baselines
• AI-Adaptive Malware: How Modern Payloads Change Behaviour Based on Their Environment and How to Defend Against Them
• How AI Is Compressing the Attacker Timeline: What Defenders Need to Change Now
• Lateral Movement Detection: Network Patterns, Authentication Anomalies, and Alert Correlation