Introducing the Mitigant Threat Catalog: From Static Descriptions to Dynamic Executions

If you work in cloud security, you know the feeling. You're staring at a MITRE ATT&CK technique, say T1562.008 (Impair Defenses: Disable Cloud Logs), and you know it matters. The description tells you adversaries may disable cloud logging to evade detection. Great. But what does that actually look like in your AWS environment? Which API call triggers it? What shows up in CloudTrail? What's the exact command an attacker would run? And under that single technique, what are the different procedures an attacker could leverage; stopping a CloudTrail trail is one path, but what about deleting the trail entirely, narrowing event selectors to exclude certain API calls, removing VPC Flow Logs, or disabling S3 server access logging? Each procedure maps to a different API call, a different CloudTrail event, a different detection opportunity.

You end up digging through multiple sources, piecing together blog posts, cross-referencing CloudTrail event names, trying to reverse-engineer what a real attack chain looks like at the CLI level. This is the gap we kept running into; not just as defenders, but as builders of an attack emulation platform. MITRE ATT&CK is brilliant for categorizing adversary behavior. It's deliberately abstract. But that abstraction means someone still has to do the hard work of translating T1562.008 into aws cloudtrail stop-logging --name production-trail.

That someone is usually you. And you're probably doing it from scratch, every time.

We've been chasing this gap for years

If you've followed the Mitigant blog or my LinkedIn, you'll notice a consistent effort at sharing knowledge around these challenges. When v.14 dropped, we wrote about Temporary Elevated Cloud Access and Cloud Secrets Management. When v.16 landed, we dug into LLMjacking via Amazon Bedrock and Conditional Access Policy abuse. When Red Canary published their 2025 Threat Detection Report, we broke down the most pervasive cloud attack techniques and what defenders should actually do about them. I also did a deep dive into the recently introduced Detection Strategies that came with ATT&CK v18, and shared findings from an adversary emulation exercise against AWS using Amazon Detective: 642 successful discovery actions, 22 privilege escalation actions, 377 collection actions; all mapped to MITRE ATT&CK, all validating whether our detective controls actually caught them. The takeaway was blunt: NO ASSUMPTIONS. Validate.

Furthermore, we collaborated with Sekoia on Scattered Spider detection and with Cado Security on cloud forensics; we learned that these same pain points span adversary emulation, threat detection, and forensic investigation.

‍

The engagement on these pieces, both blog posts and LinkedIn, has consistently reinforced that this gap is real. Defenders are actively searching for this kind of actionable, technique-level detail. That told us something: a blog post helps, but what practitioners really need is a persistent, structured reference.

MITRE ATT&CK matrix gives you the "what." The missing link is the connective tissue: the actual commands, the realistic output, the CloudTrail event names, all in one place. The AWS Threat Technique Catalog has done excellent work providing AWS-specific context for many techniques, and it's a resource we reference regularly. We wanted to complement that work by adding the executable layer: CLI commands you can run, YAML definitions you can load, and detection mappings you can plug into your workflows.

Cloud Attack Language

When we built the Mitigant Attack Builder, we gave security teams a way to compose cloud attacks without writing code: select your MITRE ATT&CK technique, configure AWS CLI commands with auto-complete, chain multiple steps together, and execute them against your environment. The Attack Builder is now generally available, and the feedback from our beta cohort of 20+ users shaped a lot of what we're sharing today.

What we kept hearing, and experiencing ourselves, is that knowing the individual AWS commands is only half the problem. The harder challenge is structuring those commands into multi-step attack chains that can be shared across teams, persisted in version control, and integrated into CI/CD pipelines. In other words: Attack-as-Code.

Atomic Red Team popularized the idea of defining attack tests in a simple, shareable YAML format. Their atomics schema is one of the most important contributions to the offensive security community, and it already does a lot right for cloud: platform scoping, parameterized inputs, cleanup commands. We didn't want to reinvent the wheel; so we took the Atomic Red Team schema as our foundation and evolved it into what we're calling the Cloud Attack Language. The key changes: we added AWS service-type tagging (so you can filter techniques by IAM, S3, GuardDuty, etc.) and restructured the execution model from a single executor block into explicit multi-step definitions designed for chaining cloud attack sequences. We also simplified the schema itself; because CAL techniques run in a managed execution environment, things like executor type, dependency checks, and elevation flags are handled by the platform rather than defined per technique. The YAML stays clean and focused on what matters: the attack logic. The format remains open and readable; you can inspect every definition in the Threat Catalog and use them however you see fit.

This is still an evolving spec. Here's what a technique looks like today:

‍


name: IAM Credential Persistence
attack_technique: T1078.004
description: Creates a login profile for persistence
supported_platforms:
    - iaas:aws
service-type: IAM
input_arguments:
    user_name:
        description: Option --user-name for type string
        default: john-doe
    password:
        description: Option --password for type string
        default: @3wewSwew
attack_step_definitions:
    - step: 1
      command: aws iam create-user --user-name ${user_name}
    - step: 2
      command: aws iam create-login-profile
        --user-name ${user_name} --password ${password}
      cleanup_command: aws iam delete-login-profile
        --user-name ${user_name}
    - step: 3
      command: aws iam create-access-key --user-name ${user_name}

Introducing the Mitigant Threat Catalog

Today we're making the Mitigant Threat Catalog publicly available: an interactive, open catalog of cloud attack techniques that gives you the things hardest to find on your own.

Real CLI Commands. Actual AWS CLI commands with realistic parameters and simulated output that mirrors what you'd see in a live environment.

CloudTrail Event mapping. The specific event names your detection rules should trigger on. If you're writing Sigma rules or tuning your SIEM, this is the reference you need.

Cloud Attack Language definitions. Each technique ships with a complete YAML definition you can load directly into the Attack Builder and execute in your browser, or take the YAML and integrate it into your own workflows.

Detection and mitigation guidance. Practical recommendations tied to each technique, not generic best practices.

We've launched with 30 techniques spanning 12 of 14 ATT&CK tactics and covering 15 AWS services: from IAM credential abuse (T1078) to S3 ransomware via SSE-C encryption (T1486.A001) and AWS Organizations manipulation (T1666).

‍

Why free and public?

Because threat-informed defense shouldn't be gated. Every blog post we've written, every MITRE breakdown, every collaboration; all public, all aimed at equipping cloud security practitioners to defend better. The Threat Catalog is a natural extension of that work.

What's next

This is a living catalog. We'll keep adding techniques, expanding AWS service coverage, and keeping pace with new ATT&CK releases and AWS-specific developments; as AWS services evolve and new APIs introduce new attack surfaces, the catalog will track those changes. The Cloud Attack Language will continue to evolve alongside it. If you have suggestions for techniques to add or spot something that could be improved, reach out at contact@mitigant.io. We're just getting started.

Explore the catalog: threats.mitigant.io

‍