AWS Abuse Pattern Detection: 10 Open Source Signals (2026)

Disclosure: I am Mariusz Gebala (AWS Solutions Architect Associate, Palo Alto PCNSA, Microsoft Azure Administrator) and the author of cloud-audit. v2.2.0 introduced the Threat Feed module described in this post (released 12 May 2026); v2.2.1 shipped the same day with two refinements following this article’s fact-check pass: TF-001 escalation logic now matches the Wiz “multiple domains” burst pattern (the earlier “single email no matching domain” rule was wrong), and TF-004 no longer flags Permiso defensive tools (CloudGrappler, DetentionDodger) which would have produced false positives when defenders run them against their own accounts. Every external citation below is linked to the original publication. cloud-audit Threat Feed is not the only OSS doing threat-related detection on AWS - Prowler (from v5), Permiso CloudGrappler, and Permiso DetentionDodger all overlap parts of this space with different approaches. The “Honest overlap” and “Where this fits” sections below break down the differences.

Bottom line: Misconfiguration scanners (Prowler, Trivy, Cloudsplaining, the original cloud-audit) tell you what is wrong. They do not tell you whether an attacker is already in the door - or whether the precursor conditions for documented attacks are present in your account. cloud-audit v2.2.0 introduces a separate threat-feed pipeline with 10 detectors mapped 1:1 to AWS abuse campaigns documented by Wiz, Datadog Security Labs, Unit 42, Permiso, The Hacker News, The Register, and BleepingComputer between September 2025 and May 2026. Honest framing: the 10 patterns are a mix - some are confirmed signals (e.g. AWS-attached quarantine policy = AWS detected a leak), some are strong heuristics (e.g. a fresh IAM role with broad compute access matches the November 2025 cryptomining footprint), some are precursors (e.g. CI/CD role configured in a way that makes the whoAMI confusion attack reachable), and some are misconfiguration-like exposures with threat context (e.g. IMDSv1 still in use). Each pattern below is tagged accordingly. Several OSS tools already cover adjacent ground (Prowler 3 behavioural CloudTrail checks, CloudGrappler 97 TTP log queries, DetentionDodger a single deep-dive on the AWS quarantine policy). The niche cloud-audit Threat Feed fills is a curated state-based incident playbook scanner - one CLI, one command, ten patterns each tied to a specific published incident.

TL;DR

Pattern ID	Severity	Signal type	Detects	Source incident
aws-tf-001	MEDIUM/HIGH	precursor	SES identity verified in last 14 days	Wiz Sep 2025 + Kaspersky/BleepingComputer May 2026
aws-tf-002	HIGH/CRITICAL	strong heuristic	Lambda Function URL with AuthType=NONE	The Register/HN Dec 2025 cryptomining campaign
aws-tf-003	CRITICAL	confirmed	AWSCompromisedKeyQuarantine* attached	AWS auto-response to credential exposure (Permiso bypass research)
aws-tf-004	CRITICAL	strong heuristic	Leaked-creds scanner UA in CloudTrail	Kaspersky/BleepingComputer May 2026
aws-tf-005	HIGH/CRITICAL	strong heuristic	Fresh IAM role + broad compute access	The Register/HN Dec 2025 cryptomining campaign
aws-tf-006	HIGH/CRITICAL	misconfig (EC2) / heuristic (AgentCore)	MMDSv1 on EC2 or AgentCore	Datadog 2025 State of Cloud + Unit 42 Apr 2026
aws-tf-007	MEDIUM	precursor	CI/CD role precondition for whoAMI	Datadog Security Labs Feb 2025
aws-tf-008	HIGH/CRITICAL	strong IR signal	CloudTrail logging stopped or delivery error	AWS Security Hub CloudTrail.1/CloudTrail.4 controls
aws-tf-009	HIGH/MEDIUM	misconfig	Roles Anywhere external CA bundle	fwd:cloudsec 2025
aws-tf-010	HIGH	misconfig (overgrant)	AmazonDataZoneFullAccess on non-admin	AWS DataZone IAM docs

Three commands, no infrastructure:

pip install --upgrade cloud-audit          # PyPI 2.2.0
cloud-audit threat-feed --list             # show 10 patterns + rules pack 2026-Q2
cloud-audit threat-feed                    # scan default profile/region

Exit code 1 when CRITICAL or HIGH detected (CI gate friendly), 0 otherwise.

What is the difference between misconfiguration scanning and active abuse detection?

Most AWS scanners encode best-practice rules: enable MFA, enforce IMDSv2, do not share S3 publicly. They do not encode the playbook of a specific attack. Prowler’s threat-detection category is the closest counterexample I am aware of - 3 AWS checks (reconnaissance enumeration, LLMjacking, privilege escalation), all behavioural threshold counters over CloudTrail events; the directory landed in the Prowler repo on 27 March 2024 and has been maintained since. The state-based incident-playbook angle - take a published incident from 2025-2026 and encode its visible AWS-side fingerprint as a single live-state check - is what cloud-audit Threat Feed v1 adds.

That gap matters because of what actually happened to AWS users in 2025-2026:

• The November-December 2025 cryptomining campaign documented across The Hacker News (16 December 2025) and The Register (18 December 2025) used stolen IAM credentials to spin up SBRMiner-MULTI on EC2 and ECS within 10 minutes of compromise. The Hacker News specifically documents the threat actor calling CreateServiceLinkedRole and CreateRole, attaching AWSLambdaBasicExecutionRole to the Lambda role, and creating a separate IAM user with AmazonSESFullAccess attached for an email-spam side hustle. TF-005 generalises this to “any fresh role with broad compute permissions” because operators in incident response usually see broader policies than the bare minimum in published writeups - same actor profile, different blast radius.
• The SES phishing campaign documented by Wiz Research on 4 September 2025 and revisited by Kaspersky via BleepingComputer on 4 May 2026 follows a verb chain: stolen creds, GetSendQuota check, then “adding multiple domains as verified identities using the CreateEmailIdentity API” (direct Wiz quote) so the attacker can send from common prefixes (admin@, billing@, sales@, noreply@) on those domains. BleepingComputer explicitly names TruffleHog as the discovery tool attackers use to validate stolen keys before this chain runs.
• The Datadog Security Labs AiTM campaign disclosure on 9 March 2026 documented an active adversary-in-the-middle phishing campaign targeting AWS Console credentials through typosquatted domains - a reminder that compromised AWS sessions are a 2026 reality, not just a 2019 one.
• The Unit 42 “Cracks in the Bedrock” research on 7 April 2026 documented two distinct AgentCore issues: a DNS-tunneling bypass of the Code Interpreter sandbox network isolation (the headline finding), and weak MMDS token enforcement on the AgentCore Runtime which allowed SSRF-style credential extraction. AWS addressed the metadata issue by making MMDSv2 the default for new AgentCore agents on 14 February 2026 (cited in the same Unit 42 article), but agents created before that date still default to MMDSv1 unless explicitly upgraded - which is what TF-006 surfaces.

Misconfiguration scanners catch the precursors (e.g. IMDSv1 enabled, CloudTrail logging optional, broad EC2 permissions exist). They do not catch the in-progress incident.

Several OSS projects already work on adjacent ground:

• Prowler added a threat-detection category in v5 (3 AWS checks - reconnaissance enumeration, LLMjacking, privilege escalation - all behavioural threshold counters over CloudTrail events).
• Permiso CloudGrappler (open source under Apache 2.0) ships 97 detection queries that match indicators of known threat actor TTPs (verified examples in the queries dataset include LLMjacking and the Gainsight supply-chain IOCs added 21 November 2025) against CloudTrail logs using Cado’s cloudgrep.
• Permiso DetentionDodger (open source, October 2024) is a single deep-dive scanner that finds principals with the AWS quarantine policy attached - the exact signal cloud-audit Threat Feed covers in TF-003.
• Matano is a security-data-lake platform (1671 stars, last push January 2025) where you write detection rules as Python code against ingested logs - powerful, but it is infrastructure, not a one-command CLI.
• Stratus Red Team (Datadog) is the inverse problem: 27 AWS attack emulations (plus Azure, GCP, Kubernetes coverage) for testing your detections, not detection itself.

Wiz Defend, Permiso ITDR, and Stream Security CloudTwin solve this commercially with runtime sensors and managed identity-graph telemetry. The OSS niche that was empty before cloud-audit v2.2.0 is a specific one: a CLI scanner that maps live AWS control plane state against a curated catalog of documented 2025-2026 incidents with one command and no infrastructure. The other OSS tools either fish through logs (CloudGrappler, Matano), threshold-count events (Prowler), drill one pattern (DetentionDodger), or test your existing detections (Stratus). Different jobs, different inputs.

The 10 patterns

Each pattern is a single Python module in src/cloud_audit/providers/aws/threat_feed/. Each produces standard Finding objects with the new Category.THREAT enum, a threat_pattern_id field (e.g. TF-003-quarantine-policy), and a references list pointing to the backing research URL. Severity is documented per pattern.

TF-001: SES phishing setup precursor (MEDIUM/HIGH) - precursor

Detects SES email or domain identities verified within the last 14 days. Severity escalates to HIGH when BOTH conditions are true: the account has production sending enabled (out of SES sandbox) AND two or more recent verifications are present in the same scan. The escalation matches the burst pattern Wiz documented in September 2025: “adding multiple domains as verified identities using the CreateEmailIdentity API” in quick succession - one identity is normal onboarding, several at once is the campaign signature. A single recent verification, even out-of-sandbox, stays MEDIUM.

cloud-audit threat-feed --pattern aws-tf-001

False-positive guidance: legitimate marketing onboarding (multiple domains added during a brand launch) will trip the burst escalation - verify the recent verifications were authorized. The CLI surfaces the identity name, age in days, source region, and the account-wide recent-verification count in the description.

TF-002: Lambda Function URL persistence (HIGH/CRITICAL) - strong heuristic

Detects Lambda functions exposed via Function URL with AuthType=NONE. Public Lambdas are a legitimate pattern (webhooks, public APIs) but they are also a recurring post-compromise persistence mechanism: a Lambda Function URL with no auth keeps working after stolen IAM keys are rotated, making it a low-effort backdoor once an attacker has API access to create one. (The Hacker News and The Register cryptomining writeups document the attackers creating Lambda functions during the campaign; they do not specify Function URL configuration, so the connection here is the broader public-Lambda persistence category, not a 1:1 mapping to that incident.) Severity escalates to CRITICAL when the function’s execution role has admin-class managed policies attached (AdministratorAccess, IAMFullAccess, AWSKeyManagementServicePowerUser, SecretsManagerReadWrite, AmazonS3FullAccess, AmazonEC2FullAccess).

The CLI calls out wildcard CORS (Access-Control-Allow-Origin: *) when present because that makes the URL trivially callable from any browser.

TF-003: AWSCompromisedKeyQuarantine policy attached (CRITICAL) - confirmed signal

AWS automatically attaches AWSCompromisedKeyQuarantineV1, V2, or V3 to IAM principals when its credential-exposure detection identifies leaked access keys (typically a public GitHub commit, paste site, or shared snapshot). The policy denies high-risk actions to limit blast radius while you rotate, but the underlying credentials are still active and may have been used by the attacker before quarantine.

Permiso published research on the bypass surface in their DetentionDodger writeup of 31 October 2024. Presence of the policy is a confirmed-leak signal, not a suspected one.

TF-004: Leaked-credentials scanner UA in CloudTrail (CRITICAL) - strong heuristic

Detects sts:GetCallerIdentity calls in the last 24 hours whose userAgent contains substrings characteristic of leaked-credentials discovery scanners (e.g. trufflehog, gitleaks, noseyparker). BleepingComputer explicitly names TruffleHog as the tool attackers run to validate stolen AWS keys before launching SES phishing.

Detection caveat: the pattern only catches scanners that surface a recognisable user-agent. Many scanner runtimes (including TruffleHog when invoked without --user-agent-suffix) fall back to default AWS SDK user-agents which look identical to legitimate boto3 / aws-cli traffic. TF-004 catches the careless attacker who let the UA leak; a careful attacker reaching the same goal will not trigger it. Treat presence as confirming, absence as unconfirming.

TF-005: Cryptomining-campaign IAM role profile (HIGH/CRITICAL) - strong heuristic / precursor

Detects IAM roles created within the last 48 hours that carry broad compute managed policies: AmazonEC2FullAccess, PowerUserAccess, AdministratorAccess, AmazonECS_FullAccess, AWSLambda_FullAccess. The Hacker News documented the related role-creation pattern in the late-2025 cryptomining campaign: the threat actor “called CreateServiceLinkedRole and CreateRole to create IAM roles for autoscaling groups and AWS Lambda” and attached AWSLambdaBasicExecutionRole to the Lambda role. The same actor also created an IAM user with AmazonSESFullAccess attached for an email-spam side hustle - which is why TF-005 escalates to CRITICAL when the same fresh role also has SES sending permissions (the mining + email-spam combo). TF-005 generalises the role-creation signal to broader managed policies than the specific HN quote - legitimate emergency response can produce the same fresh-role pattern, so treat HIGH as a strong prompt for triage and CRITICAL as a near-certain indicator.

TF-006: MMDSv1 still in use on EC2 or Bedrock AgentCore (HIGH/CRITICAL) - misconfiguration-like (EC2) / strong heuristic (AgentCore)

Detects two related conditions. First: EC2 instances where MetadataOptions.HttpTokens != "required" - the Datadog 2025 State of Cloud Security study (10 November 2025) reported only 50% of EC2 instances enforce IMDSv2. IMDSv1 has been the entry point for documented AWS breaches since the Capital One SSRF incident in 2019 and remains the easiest credential-theft path when a server-side vulnerability allows arbitrary outbound HTTP from inside the instance.

Second (CRITICAL): Bedrock AgentCore agents on metadataVersion=v1. Per Unit 42’s 7 April 2026 “Cracks in the Bedrock”, AWS made MMDSv2 the default for new AgentCore agents on 14 February 2026 specifically because the prior token-less metadata service allowed SSRF-style credential extraction from inside the microVM. Agents created before that date still report v1 unless explicitly upgraded. (Unit 42 also documented a separate DNS-tunneling sandbox bypass in the same article - related but distinct from the metadata issue.) The Hacker News cross-referenced the broader AI infrastructure flaws including Bedrock on 17 March 2026. My own lab walkthrough of AgentCore sandbox vs VPC vs PUBLIC modes is at haitmg.pl/blog/aws-bedrock-agentcore-network-modes/.

TF-007: whoAMI CI/CD precondition (MEDIUM) - precursor

Detects IAM roles trusted by CI/CD identities (codebuild service principal, GitHub OIDC, GitLab OIDC, Buildkite federation) that have a broad EC2 managed policy attached. This is the IAM precondition for the whoAMI confusion attack disclosed by Datadog Security Labs on 12 February 2025 - if your pipeline code calls ec2:DescribeImages with a most-recent filter and no --owners restriction, an attacker who publishes a malicious AMI matching the pattern can hijack the launch.

The fix lives in pipeline code, not IAM. The role is just the precondition that makes the attack reachable. Severity is MEDIUM because this is a heuristic, not a confirmed exploit.

TF-008: CloudTrail tampering precursor (HIGH/CRITICAL) - strong IR signal

Two sub-signals on existing trails:

• CRITICAL: trail with IsLogging=False. A trail that exists but is not logging is an unambiguous blind-spot regardless of cause. CloudTrail stop is a known post-credential-theft action - AWS Security Hub ships the CloudTrail.1 and CloudTrail.4 controls precisely for this. Operators who see this finding should treat it as confirmed evidence collection has been broken until they can prove the change was authorised.
• HIGH: trail with populated LatestDeliveryError. The S3 destination is broken (deleted bucket, removed bucket policy, KMS key revoked). Whether by attacker or by misconfiguration, your evidence is being dropped.

The remediation includes restore-logging, the CloudTrail lookup-events command for forensics, and an EventBridge rule template to alert on StopLogging and DeleteTrail events going forward.

TF-009: Roles Anywhere external CA trust anchor (HIGH/MEDIUM) - misconfiguration-like

Detects IAM Roles Anywhere trust anchors with sourceType=CERTIFICATE_BUNDLE instead of the recommended AWS_ACM_PCA. Anyone able to issue a chain-valid certificate from the trusted CA can call rolesanywhere:CreateSession and exchange the cert for AWS temporary credentials. The fwd:cloudsec 2025 talk “IAM Roles Anywhere now for everyone with Lets Encrypt” explored this attack class.

Severity is HIGH when the anchor is enabled, MEDIUM when disabled (re-enabling without fix re-introduces the exposure).

TF-010: AmazonDataZoneFullAccess on non-admin principal (HIGH) - misconfiguration-like (overgrant)

Detects AmazonDataZoneFullAccess attached to non-admin IAM users or roles. DataZone bridges identity, Glue catalog, and S3 storage in a single service - the full-access managed policy is the canonical onboarding shortcut that becomes a single-principal-compromise path to the entire data plane. Already-admin principals are excluded (the grant is redundant noise rather than over-permission).

What the output looks like

Real terminal output from cloud-audit threat-feed --list (no AWS credentials needed - just enumerates registered patterns):

                Registered threat patterns (rules pack 2026-Q2)
+-----------------------------------------------------------------------------+
| Pattern ID      | Check ID   | Severity | Name            | Doc             |
|-----------------+------------+----------+-----------------+-----------------|
| TF-001-ses-phi… | aws-tf-001 | MEDIUM   | SES recently    | https://docs.a… |
|                 |            |          | verified        |                 |
|                 |            |          | identity        |                 |
| TF-002-lambda-… | aws-tf-002 | HIGH     | Public Lambda   | https://docs.a… |
|                 |            |          | Function URL    |                 |
|                 |            |          | (AuthType=NONE) |                 |
| TF-003-quarant… | aws-tf-003 | CRITICAL | AWS-attached    | https://docs.a… |
|                 |            |          | credential      |                 |
|                 |            |          | quarantine      |                 |
|                 |            |          | policy          |                 |
| TF-004-truffle… | aws-tf-004 | CRITICAL | Leaked-credent… | https://docs.a… |
|                 |            |          | scanner         |                 |
|                 |            |          | user-agent      |                 |
| TF-005-cryptom… | aws-tf-005 | HIGH     | Recently-creat… | https://docs.a… |
|                 |            |          | IAM role with   |                 |
|                 |            |          | cryptomining-…  |                 |
| TF-006-mmdsv1-… | aws-tf-006 | HIGH     | EC2/AgentCore   | https://docs.a… |
|                 |            |          | using IMDSv1    |                 |
| TF-007-whoami-… | aws-tf-007 | MEDIUM   | CI/CD role at   | https://securi… |
|                 |            |          | risk of whoAMI  |                 |
| TF-008-cloudtr… | aws-tf-008 | HIGH     | CloudTrail      | https://docs.a… |
|                 |            |          | tampering       |                 |
|                 |            |          | precursor       |                 |
| TF-009-roles-a… | aws-tf-009 | HIGH     | IAM Roles       | https://docs.a… |
|                 |            |          | Anywhere trust  |                 |
| TF-010-datazon… | aws-tf-010 | HIGH     | AmazonDataZone… | https://docs.a… |
+-----------------------------------------------------------------------------+

10 patterns registered.

When a scan finds something, the table shifts to cloud-audit threat-feed (no --list flag) output:

+- Threat Feed -----------------------------------------------------+
| Scanning 10 threat patterns (rules pack 2026-Q2)                  |
+-------------------------------------------------------------------+

         Detected threat patterns (1 findings)
+----------+-----------------+--------------------+--------+----------+
| Severity | Pattern         | Resource           | Region | Refs     |
|----------+-----------------+--------------------+--------+----------|
| HIGH     | TF-010-datazone | arn:aws:iam::1234… | global | https:…  |
|          | overgrant       | …56789012:user/    |        |          |
|          |                 | data-analyst       |        |          |
+----------+-----------------+--------------------+--------+----------+

Each finding carries description, recommendation, remediation.cli, remediation.terraform, references, and a threat_pattern_id field that maps back to the documented incident. The cloud-audit threat-feed command itself renders to a table; for machine-readable output use the regular scan command with a category filter: cloud-audit scan --categories threat -o json (or -o sarif, -o html, -o markdown). All formats carry the new threat_pattern_id and references fields on each finding.

Try it on your own account

The fastest way to confirm the scanner works without changing real production posture is to simulate TF-010 with a throwaway IAM user. PowerShell:

$env:AWS_PROFILE = "your-sandbox-profile"
$env:AWS_REGION = "eu-central-1"

aws iam create-user --user-name tf-010-test
aws iam attach-user-policy `
  --user-name tf-010-test `
  --policy-arn arn:aws:iam::aws:policy/AmazonDataZoneFullAccess

# Should print one HIGH finding for tf-010-test
cloud-audit threat-feed --pattern aws-tf-010

# Cleanup
aws iam detach-user-policy `
  --user-name tf-010-test `
  --policy-arn arn:aws:iam::aws:policy/AmazonDataZoneFullAccess
aws iam delete-user --user-name tf-010-test

For the full e2e walkthrough including Lambda Function URL simulation (TF-002), see the Threat Feed feature documentation.

Honest limitations

cloud-audit Threat Feed is not a replacement for runtime detection. It reads the AWS control plane only:

• No process visibility on instances - Wiz Defend, Sysdig Secure, Falco (CNCF), and Datadog CSM runtime sensors fill that gap.
• No managed threat intelligence feed - rules pack 2026-Q2 is hand-curated from the published research listed in this post. Quarterly cadence means new attack patterns surface in cloud-audit weeks after they are published, not minutes.
• Single-account scope - multi-account scanning requires running per-account or wrapping in your own orchestration. AWS Organizations integration is in the cloud-audit “Considering” backlog (see ROADMAP.md) but is not in v2.2.x and not scheduled.
• Some patterns require larger CloudTrail permissions than a standard scan (TF-004 needs cloudtrail:LookupEvents) - principals with restricted IAM may see empty results.

The patterns are intentionally biased toward few false negatives over zero false positives. Severity tiers (CRITICAL / HIGH / MEDIUM) reflect detection confidence and let CI gates choose their own threshold.

Versioning the rules pack

THREAT_FEED_VERSION = "2026-Q2" ships with v2.2.0. New patterns added before the next quarter bump go into 2026-Q3. Operators pin a known pack via cloud-audit threat-feed --threat-feed-version 2026-Q2 so a CI gate built against the May 2026 release does not start failing in October when TF-011 to TF-020 ship.

The model is intentionally conservative: detection logic for active abuse evolves fast, but breaking a CI gate every two weeks erodes trust faster than it adds coverage.

Adding your own patterns

The architecture is one file per pattern. To add TF-011-my-detection:

1. Create src/cloud_audit/providers/aws/threat_feed/my_detection.py with a detect(provider) -> CheckResult function and the PATTERN_ID, CHECK_ID, PATTERN_NAME, PATTERN_SEVERITY, DOC_URL module constants.
2. Register the new module by appending to _PATTERN_MODULES in src/cloud_audit/providers/aws/threat_feed/__init__.py.
3. Add tests in tests/aws/threat_feed/test_my_detection.py. The existing 10 patterns ship with 9-12 tests each covering positive cases, negatives, edge cases, AccessDenied resilience, and metadata exposure - use those as templates.
4. Update THREAT_FEED_VERSION and the changelog if shipping in a release.

PRs welcome on github.com/gebalamariusz/cloud-audit.

How does cloud-audit Threat Feed compare to Prowler, CloudGrappler, and Wiz Defend?

cloud-audit Threat Feed v1 sits in a narrow niche: live AWS control plane state mapped 1:1 to a curated catalog of published 2025-2026 incidents. It is not “the only OSS active abuse detector” - that claim would be wrong. It is the only OSS CLI that runs a one-command scan against a curated incident playbook with embedded research references on every finding. Prowler covers behavioural CloudTrail counters, CloudGrappler covers TTP log queries, DetentionDodger drills the quarantine policy, Matano gives you a platform to write your own. The four are complementary, not substitutes.

A defensible stack for a security-conscious AWS operator looks like:

1. Prowler for compliance breadth and the 3 behavioural threat-detection checks
2. cloud-audit threat-feed for the 10 curated state-based incident playbooks
3. CloudGrappler when you have CloudTrail log access and want to hunt for known threat actor TTPs
4. DetentionDodger as a deep-dive when cloud-audit TF-003 fires and you need the full leaked-credential impact analysis

For the misconfiguration side of the same toolbox, see the 5 OSS IAM privesc scanners benchmark (April 2026, cloud-audit + Prowler + 3 others on 57 documented escalation paths).

Honest overlap with existing OSS

Two of the cloud-audit Threat Feed patterns overlap directly with prior open-source work, and one overlaps approach-wise. Worth flagging:

• TF-003 (quarantine policy attached) is the same signal that Permiso DetentionDodger scans for, released October 2024. DetentionDodger goes deeper - it walks the principal’s attached and inline policies and group memberships to compute blast-radius impact. cloud-audit Threat Feed gives you the flag plus a CLI rotation runbook; DetentionDodger gives you the leaked-credential impact analysis. Use both: cloud-audit during routine scans for the binary signal, DetentionDodger when the signal fires and you need full context.
• TF-004 (leaked-creds scanner user-agent in CloudTrail) uses the same approach as Permiso CloudGrappler - fish CloudTrail for known indicator strings. CloudGrappler ships 97 such queries across multiple TTPs and cloud providers; cloud-audit Threat Feed ships one focused query specifically for leaked-credentials scanner user-agents. CloudGrappler is the better tool when you want comprehensive log hunting; cloud-audit Threat Feed is the better one-command check during a triage.
• TF-005 (cryptomining-style fresh IAM role) and Prowler’s cloudtrail_threat_detection_privilege_escalation both look at privilege escalation behaviours, but from different angles. cloud-audit checks the resulting state (fresh role + broad compute policy attached) on a 48h window; Prowler counts the events (Attach*Policy, PassRole etc.) per identity over time. The two find different positives - cloud-audit catches the role even if event volume was low, Prowler catches the event burst even if the resulting state was cleaned up.

The other seven patterns (TF-001, TF-002, TF-006, TF-007, TF-008, TF-009, TF-010) do not have a direct OSS equivalent at the time of writing.

What is next

cloud-audit v3.0.0 (target June 2026) will ship the Security Graph + Blast Radius analyzer - in-memory networkx graph of resource relationships with BFS from internet nodes to high-value targets, no Neo4j required. v3.1.0 (July) adds the NHI Audit and JIT Auditor for the identity-first narrative. The full 11-release calendar through March 2027 is internal but the direction is published in the cloud-audit roadmap.

If you want help running cloud-audit Threat Feed against a production AWS estate or designing the response process when one of the CRITICAL patterns fires, I do that as paid work - see the AWS security audit service page or book a 20-minute triage call.

Frequently asked questions

What is the difference between misconfiguration scanning and active abuse detection on AWS?

Misconfiguration scanning asks “is this resource configured securely?” - Prowler, Trivy, Cloudsplaining, the original cloud-audit checks all answer that question. Abuse-pattern detection asks “did an incident already happen, or are the precursor conditions for a documented attack present right now?” The cloud-audit Threat Feed v1 covers 10 such signals from documented 2025-2026 research. Each signal is tagged with its confidence tier (confirmed / strong heuristic / precursor / misconfiguration-like) so operators know whether to treat it as evidence or as a triage prompt.

Which 2025-2026 AWS abuse campaigns does cloud-audit Threat Feed v1 detect?

Ten patterns mapped to documented incidents: SES phishing setup precursor (Wiz September 2025, Kaspersky / BleepingComputer May 2026), Lambda Function URL persistence (The Register and The Hacker News December 2025 cryptomining campaign), AWSCompromisedKeyQuarantine policy attached (AWS automated response to credential exposure, with Permiso DetentionDodger covering bypass research), TruffleHog or similar leaked-credential scanner UA in CloudTrail, fresh IAM role with cryptomining-style compute access, MMDSv1 still in use on EC2 or Bedrock AgentCore (Datadog 2025 State of Cloud Security, Unit 42 Cracks in the Bedrock April 2026), whoAMI CI/CD precondition (Datadog Security Labs February 2025), CloudTrail tampering precursor, Roles Anywhere external CA trust anchor (fwd:cloudsec 2025 Lets Encrypt for AWS Console), and AmazonDataZoneFullAccess on non-admin principals.

Does the Threat Feed replace runtime EDR, GuardDuty, or a SIEM?

No. Threat Feed reads the AWS control plane only - IAM, CloudTrail metadata, EC2 metadata configuration, SES identity inventory. It does not see processes on instances, network packets in transit, or DNS queries leaving the VPC. Wiz Defend, Sysdig Secure, Falco (CNCF), and Datadog Cloud Security Management runtime sensors fill the runtime gap. GuardDuty correlates AWS-side telemetry with managed threat intelligence. A SIEM aggregates and correlates events across sources. Threat Feed is the lightweight CLI layer that surfaces ALREADY-VISIBLE control plane signals an operator can run with one command and zero infrastructure.

How accurate are the Threat Feed patterns - any false positives?

Severity tiers reflect detection confidence and the new signal-type tags reflect what kind of evidence each pattern provides:

• Confirmed signals (TF-003 quarantine policy) - near-certain incident indicators backed by direct AWS action.
• Strong IR signals (TF-008 CloudTrail logging stopped) - unambiguous blind-spots regardless of cause.
• Strong heuristics (TF-002 public Lambda URL, TF-004 leaked-creds scanner UA, TF-005 fresh role with admin compute, TF-006 AgentCore MMDSv1) - strong signals but include legitimate setups (public Lambdas can be intentional webhooks; fresh admin roles can be emergency response; scanner UAs can come from defensive tooling against your own account).
• Precursors (TF-001 SES burst, TF-007 whoAMI CI/CD role) - necessary preconditions for documented attacks, not evidence of compromise.
• Misconfiguration-like (TF-006 EC2 IMDSv1, TF-009 Roles Anywhere external CA, TF-010 DataZone overgrant) - exposure conditions with threat context, not active abuse.

The CLI exits with code 1 when CRITICAL or HIGH detected so it works as a CI gate.

How do I install and run cloud-audit threat-feed?

Three commands. pip install --upgrade cloud-audit installs version 2.2.1 (or newer) from PyPI. cloud-audit threat-feed --list prints the 10 registered patterns and the rules pack version (2026-Q2) without touching AWS. cloud-audit threat-feed scans your default profile and region against all patterns - add --regions all to scan every enabled region, --pattern aws-tf-003 to run a single pattern, or --profile NAME for a non-default AWS profile. The CLI exits 1 when CRITICAL or HIGH findings detected and 0 otherwise, suitable for CI gates or scheduled cron jobs.

Does Prowler already detect AWS active abuse?

Partially. Prowler v5 ships a threat-detection category with 3 AWS checks: reconnaissance enumeration, LLMjacking, and privilege escalation - all behavioural threshold counters over CloudTrail events (the directory landed in the Prowler repo on 27 March 2024 and has been maintained since). cloud-audit Threat Feed covers a different angle: state-based incident-playbook checks against live AWS control plane configuration. The two are complementary - the recommended OSS stack runs both, plus Permiso CloudGrappler (97 TTP log queries) and Permiso DetentionDodger (deep-dive on the AWS quarantine policy).

What does AWSCompromisedKeyQuarantineV3 mean?

AWS automatically attaches AWSCompromisedKeyQuarantineV3 to IAM principals when its credential-exposure detection identifies leaked access keys (typically a public GitHub commit, paste site, or shared snapshot). The policy denies high-risk actions to limit blast radius while you rotate, but the underlying credentials are still active and may have been used by the attacker before quarantine. The policy version 3 was created by AWS on 21 August 2024 and last edited 16 March 2026 (per the AWS managed policy reference). cloud-audit TF-003 detects V1, V2, and V3.

Can Lambda Function URLs with AuthType=NONE be legitimate?

Yes. Public webhooks, public APIs, and serverless landing pages are all legitimate use cases for AuthType=NONE. cloud-audit TF-002 flags them at HIGH (strong heuristic, not confirmed abuse) and escalates to CRITICAL only when the function’s execution role grants admin-class permissions (AdministratorAccess, IAMFullAccess, KMS PowerUser, SecretsManagerReadWrite, S3FullAccess, EC2FullAccess) - the role profile of the November 2025 cryptomining campaign. A public Lambda with a tightly-scoped role is a legitimate pattern; a public Lambda with admin-class IAM is a backdoor candidate.

How does Threat Feed compare to Wiz Defend, Permiso ITDR, Prowler threat-detection, and CloudGrappler?

Different jobs. Wiz Defend and Permiso ITDR are paid commercial CDR platforms with eBPF runtime sensors, identity correlation across cloud and SaaS and CI/CD telemetry, and managed threat intel feeds - the right choice for 24x7 multi-account detection. On the OSS side: Prowler v5 added a threat-detection category with 3 AWS checks (reconnaissance enumeration, LLMjacking, privilege escalation - all threshold counters over CloudTrail events). Permiso CloudGrappler (open source, last update November 2025) ships 97 detection queries that match indicators of known threat actor TTPs against CloudTrail logs. Permiso DetentionDodger (October 2024) is a single-pattern deep-dive on the AWS quarantine policy - the exact signal cloud-audit Threat Feed covers in TF-003. cloud-audit Threat Feed v1 fills a different niche: live AWS control plane state mapped 1:1 to a curated catalog of published 2025-2026 incidents, one CLI command, no infrastructure, no log access required. The four OSS approaches (Prowler behavioural, CloudGrappler log TTP, DetentionDodger deep-dive, cloud-audit playbook scanner) are complementary - the defensible stack runs all four.

References

All linked URLs in this post were live and verified on 12 May 2026.

• Wiz - “Wiz Uncovers SES Abuse Campaign Using Stolen AWS Access Keys” (4 September 2025)
• BleepingComputer / Kaspersky - “Researchers report Amazon SES abused in phishing” (4 May 2026)
• The Hacker News - “Compromised IAM Credentials Power a Large AWS Crypto Mining Campaign” (16 December 2025)
• The Register - “Crypto crooks co-opt stolen AWS creds to mine coins” (18 December 2025)
• Datadog Security Labs - “whoAMI: A cloud image name confusion attack” (12 February 2025)
• Datadog Security Labs - “Behind the console: Active phishing campaign targeting AWS console” (9 March 2026)
• Unit 42 - “Cracks in the Bedrock: Escaping the AWS AgentCore Sandbox” (7 April 2026)
• The Hacker News - “AI Flaws in Amazon Bedrock, LangSmith, and SGLang” (17 March 2026)
• Permiso - “Breaking free from the chains of fate - Bypassing AWSCompromisedKeyQuarantineV2” (31 October 2024)
• Datadog - “Key learnings from the 2025 State of Cloud Security study” (10 November 2025)
• fwd:cloudsec 2025 talk summaries (Cybr Inc.)
• AWS managed policy reference - AWSCompromisedKeyQuarantineV3 (AWS, policy v3 effective 16 March 2026)

Code: github.com/gebalamariusz/cloud-audit - current release v2.2.1 (the v2.2.0 tag introduced Threat Feed; v2.2.1 same-day patch). Documentation: haitmg.pl/cloud-audit/features/threat-feed/.