AWS KMS Ransomware Hunt: When Your Encryption Keys Become the Attacker’s Weapon

Ransomware in the cloud no longer needs to drop a malicious binary. It only needs to convince AWS Key Management Service that the attacker’s key is the new owner. This hunt playbook covers the four KMS-mediated ransomware patterns observed in 2025-2026 incidents and ships the detection logic to surface them.

The cloud ransomware story has shifted. Earlier in-cloud ransomware required the attacker to deploy an encryption binary into the victim environment — a noisy operation with many detection opportunities. KMS-mediated ransomware bypasses that entirely. The attacker uses the cloud’s own key management plane to re-encrypt data under their key, modify key policies to lock out the legitimate owner, or create grants that survive credential rotation.

This article catalogues the four KMS ransomware patterns that have emerged in incident response engagements over the past 18 months, the CloudTrail events that surface each one, and the detection logic SOC teams should ship this week. Part 2 of the AWS Threat Hunting series.

01 · Why this hunt matters

KMS is uniquely dangerous as a ransomware vector for three reasons. First, KMS operations are control-plane operations that look indistinguishable from legitimate administrative activity until the impact materialises. Second, KMS data-plane operations (Encrypt, Decrypt, GenerateDataKey) often are not logged by default in many trail configurations, meaning the actual encryption step is invisible to defenders. Third, KMS key policies grant the policy authority to modify the policy itself — a self-referential control loop that an attacker who briefly compromises a key admin can permanently subvert.

The operational impact of a successful KMS ransomware event is severe. Re-encrypted data is unreadable to the legitimate owner. Key policies modified to grant exclusive control to the attacker survive even after the initial intrusion vector is closed. The standard ransomware response — rotate credentials, eject the attacker, restore from backups — does not work when the encryption keys themselves are the target.

02 · Adversary tradecraft

Pattern 01 — Customer-managed key policy modification

The attacker, having compromised an identity with KMS administrative privileges, issues PutKeyPolicy against a customer-managed key. The new policy grants the attacker’s external principal exclusive administrative control and removes the legitimate organisation’s principal. The legitimate organisation can no longer decrypt data encrypted with the key. The ransom demand follows.

Pattern 02 — Re-encryption with attacker-controlled key

The attacker creates a new KMS key in their own account (or in a region the victim does not monitor), grants the victim’s identity Encrypt permission on the new key, and then runs a copy-and-re-encrypt operation on S3 objects or EBS snapshots using the new key. The originals are deleted; only the re-encrypted versions remain.

Pattern 03 — Grant token persistence

The attacker issues CreateGrant operations against existing keys with a long retiring-principal lifetime. Grants survive most credential rotations and provide stealth access to KMS operations. Defenders who rotate IAM credentials without auditing grants leave the access path intact.

Pattern 04 — Key deletion ransom

Rather than re-encrypting data, the attacker schedules existing keys for deletion (ScheduleKeyDeletion). The waiting period creates a ransom window during which the attacker demands payment to cancel the deletion before the keys are destroyed and the data becomes permanently inaccessible.

03 · Telemetry needed

The telemetry stack to detect KMS ransomware patterns:

• CloudTrail management events capturing PutKeyPolicy, CreateGrant, ScheduleKeyDeletion, DisableKey, and CreateKey.
• CloudTrail data events on KMS capturing Encrypt, Decrypt, GenerateDataKey, and ReEncrypt. These are not enabled by default; turn them on for production keys.
• S3 Server Access Logs or data events for buckets storing ransomable data — to correlate copy-and-re-encrypt operations.
• IAM identity baseline — which principals legitimately call which KMS APIs in normal operations.

The single highest-yield telemetry investment for this hunt is enabling CloudTrail data events for KMS in the regions where production keys are stored. The cost is modest; the detection coverage gain is the entire pattern surface.

04 · Hunt queries

Hunt query 01 — Anomalous PutKeyPolicy operations

SELECT eventTime, userIdentity.arn AS principal, sourceIPAddress, awsRegion,
       requestParameters.keyId AS key_id,
       requestParameters.policy AS new_policy
FROM cloudtrail_logs
WHERE eventName = 'PutKeyPolicy'
  AND eventTime BETWEEN '2026-06-08' AND '2026-06-14'
  AND userIdentity.arn NOT IN (SELECT principal FROM kms_admin_allowlist)
ORDER BY eventTime DESC;

Hunt query 02 — Grant token creation with long-lived retiring principal

SELECT eventTime, userIdentity.arn AS principal, sourceIPAddress,
       requestParameters.keyId AS key_id,
       requestParameters.granteePrincipal AS grantee,
       requestParameters.retiringPrincipal AS retiring_principal,
       requestParameters.operations AS operations
FROM cloudtrail_logs
WHERE eventName = 'CreateGrant'
  AND eventTime BETWEEN '2026-06-08' AND '2026-06-14'
  AND (requestParameters.granteePrincipal NOT LIKE 'arn:aws:iam::ACCOUNT_ID:%'
       OR requestParameters.retiringPrincipal NOT LIKE 'arn:aws:iam::ACCOUNT_ID:%')
ORDER BY eventTime DESC;

Hunt query 03 — Scheduled key deletion

SELECT eventTime, userIdentity.arn AS principal, sourceIPAddress, awsRegion,
       requestParameters.keyId AS key_id,
       requestParameters.pendingWindowInDays AS pending_days
FROM cloudtrail_logs
WHERE eventName = 'ScheduleKeyDeletion'
  AND eventTime BETWEEN '2026-06-08' AND '2026-06-14';

05 · Sigma rule

title: KMS Key Policy Modified by Non-Allowlisted Principal
id: 5a2b3c44-6d7e-4f12-8a9b-0c1d2e3f4a5b
status: experimental
description: |
  Detects KMS PutKeyPolicy operation from a principal not in the
  organisation's allowlist of authorised key administrators. Surfaces
  KMS ransomware Pattern 01.
author: HackForLab
date: 2026/06/16
references:
  - https://hackforlab.com/aws-kms-ransomware-hunt-2026/
tags:
  - attack.impact
  - attack.t1486
  - attack.privilege_escalation
  - attack.t1098
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName: 'PutKeyPolicy'
    eventSource: 'kms.amazonaws.com'
  filter_allowlist:
    userIdentity.arn|expand: '%KMS_ADMIN_ALLOWLIST%'
  condition: selection and not filter_allowlist
fields:
  - userIdentity.arn
  - awsRegion
  - requestParameters.keyId
  - sourceIPAddress
falsepositives:
  - Allowlisted key administrators not yet enrolled
level: critical

06 · Ship as a production detection

Production deployment requires two engineering investments. First, build and maintain a KMS administrator allowlist as an explicit data source consumed by the rule. Every principal authorised to modify key policies must be enumerated. The allowlist is reviewed monthly by the cloud-security team. Second, instrument the response automation to immediately quarantine the affected key — revoke session credentials of the principal that issued the change, and snapshot the previous key policy from CloudTrail history for restoration. — or pull pre-mapped clusters from HuntIntel

Map this detection chain to T1486 (Data Encrypted for Impact), T1098 (Account Manipulation), and T1485 (Data Destruction). The chained-rule approach (PutKeyPolicy followed by CreateGrant followed by Encrypt) is higher-confidence than any single event in isolation.

07 · False-positive considerations

The dominant false-positive source is initial KMS key setup during onboarding of new applications, which legitimately produces a burst of PutKeyPolicy operations from an administrator who may not yet be on the allowlist. Mitigation: integrate the detection with the change-management system so that PutKeyPolicy events linked to an approved change ticket are auto-suppressed; events without ticket linkage fire normally. Other minor FP sources include infrastructure-as-code deployment pipelines (allowlist the deployment role) and break-glass administrative actions (require these to be approved through a dedicated workflow that ages out the suppression after 24 hours).

08 · Response actions

KMS ransomware response is time-sensitive. Within minutes: revoke the session credentials of the principal that modified the key policy or created the grant. Snapshot the prior key policy from the CloudTrail history and prepare a restoration policy. Within hours: audit all KMS keys for unauthorised grants and policies modified in the same window. Cancel any pending ScheduleKeyDeletion operations. Within days: rotate any credentials that may have been used by the same principal across other AWS services, audit any data encrypted with the affected keys, and update the KMS administrator allowlist with the lessons learned. — Sign in to huntintel.hackforlab.com to pull the live catalogue and pivot on the cluster directly.

09 · FAQ