Wir präsentieren den Mitigant Threat Catalog: Von statischen Beschreibungen zu dynamischen Ausführungen

Wer in der Cloud-Sicherheit arbeitet, kennt das Gefühl: Man starrt auf eine MITRE ATT&CK-Technik, zum Beispiel T1562.008 (Abwehrmechanismen beeinträchtigen: Cloud-Protokolle deaktivieren), und weiß, dass sie wichtig ist. Die Beschreibung besagt, dass Angreifer die Cloud-Protokollierung deaktivieren könnten, um einer Entdeckung zu entgehen. Schön und gut. Aber wie sieht das in Ihrer AWS-Umgebung konkret aus? Welcher API-Aufruf löst das aus? Was erscheint in CloudTrail? Welchen Befehl würde ein Angreifer exakt ausführen? Und welche verschiedenen Vorgehensweisen kann ein Angreifer unter dieser einen Technik nutzen? Das Stoppen eines CloudTrail-Trails ist ein Weg, aber was ist mit dem vollständigen Löschen des Trails, dem Einschränken von Ereignis-Selektoren zum Ausschluss bestimmter API-Aufrufe, dem Entfernen von VPC Flow Logs oder dem Deaktivieren der S3-Serverzugriffsprotokollierung? Jedes Vorgehen entspricht einem anderen API-Aufruf, einem anderen CloudTrail-Ereignis und einer anderen Möglichkeit zur Erkennung.

Am Ende durchforstet man zahlreiche Quellen, setzt Blogbeiträge zusammen, vergleicht CloudTrail-Ereignisnamen und versucht, eine echte Angriffskette auf CLI-Ebene nachzubilden. Genau auf diese Lücke sind wir immer wieder gestoßen – nicht nur als Verteidiger, sondern auch als Entwickler einer Plattform für Angriffsemulation. MITRE ATT&CK ist brillant, um Angreiferverhalten zu kategorisieren. Es ist bewusst abstrakt gehalten. Doch diese Abstraktion bedeutet, dass immer noch jemand die mühsame Arbeit leisten muss, T1562.008 in aws cloudtrail stop-logging --name production-trailzu übersetzen.

Dieser Jemand sind meistens Sie. Und wahrscheinlich fangen Sie jedes Mal wieder bei Null an.

Wir beschäftigen uns schon seit Jahren mit dieser Lücke

Wenn Sie den Mitigant-Blog oder mein LinkedIn-Profil verfolgt haben, werden Sie bemerkt haben, dass wir kontinuierlich Wissen zu diesen Herausforderungen teilen. Als Version 14 erschien, schrieben wir über temporären privilegierten Cloud-Zugriff und das Management von Cloud-Geheimnissen. Als Version 16 veröffentlicht wurde, wir haben uns intensiv mit LLMjacking über Amazon Bedrock und den Missbrauch von Conditional Access Policies befasst. Als Red Canary den Threat Detection Report 2025 veröffentlichte, haben wir die am weitesten verbreiteten Cloud-Angriffstechniken analysiert und aufgezeigt, was Verteidiger konkret dagegen tun können. Außerdem habe ich einen tiefen Einblick in die neu eingeführten Detection Strategies von ATT&CK v18 gegeben und eine Analyse der Bedrohungen geteilt, die Amazon Detective nach einer von uns durchgeführten Adversary-Emulation erfolgreich erkannt hat.

Darüber hinaus haben wir mit Sekoia an der Erkennung von Scattered Spider und mit Cado Security an Cloud-Forensik und -Untersuchungengearbeitet; dabei haben wir festgestellt, dass dieselben Schwachstellen sowohl die Adversary-Emulation als auch die Bedrohungserkennung und forensische Untersuchungen betreffen.

‍

Die Resonanz auf diese Beiträge, sowohl in Blogposts als auch auf LinkedIn, hat immer wieder bestätigt, dass diese Lücke real ist. Verteidiger suchen aktiv nach solch praxisnahen Details auf Technik-Ebene. Das hat uns gezeigt: Ein Blogpost ist hilfreich, aber was Anwender wirklich brauchen, ist eine dauerhafte, strukturierte Referenz.

Die MITRE ATT&CK-Matrix liefert das „Was“. Das fehlende Bindeglied ist die praktische Umsetzung: die tatsächlichen Befehle, realistische Ausgaben, CloudTrail-Ereignisnamen – alles an einem Ort. Der AWS Threat Technique Catalog leistet hervorragende Arbeit, indem er AWS-spezifische Kontexte für viele Techniken bereitstellt, und ist eine Ressource, auf die wir regelmäßig zurückgreifen. Wir wollten diese Arbeit ergänzen, indem wir die ausführbare Ebene hinzufügen: CLI-Befehle zum Ausführen, YAML-Definitionen zum Laden und Erkennungs-Mappings, die Sie direkt in Ihre Workflows integrieren können.

Cloud Attack Language

Als wir die Mitigant Attack Builderhaben wir Sicherheitsteams eine Möglichkeit gegeben, Cloud-Angriffe ohne Programmierung zu erstellen: Wählen Sie Ihre MITRE ATT&CK-Technik aus, konfigurieren Sie AWS CLI-Befehle mit Auto-Vervollständigung, verketten Sie mehrere Schritte und führen Sie diese in Ihrer Umgebung aus. Der Attack Builder ist jetzt allgemein verfügbar, und das Feedback unserer Beta-Gruppe von über 20 Nutzern hat maßgeblich dazu beigetragen, was wir heute vorstellen.

Was wir immer wieder hörten und selbst erlebten, ist, dass die Kenntnis der einzelnen AWS-Befehle nur die halbe Miete ist. Die größere Herausforderung besteht darin, diese Befehle in mehrstufige Angriffsketten zu strukturieren, die teamübergreifend geteilt, in der Versionskontrolle gespeichert und in CI/CD-Pipelines integriert werden können. Mit anderen Worten: Attack-as-Code.

Atomic Red Team hat die Idee populär gemacht, Angriffstests in einem einfachen, gemeinsam nutzbaren YAML-Format zu definieren. Ihr Atomics-Schema ist einer der wichtigsten Beiträge für die Offensive-Security-Community und leistet für die Cloud bereits vieles richtig: Plattform-Scoping, parametrisierte Eingaben und Bereinigungsbefehle. Wir wollten das Rad nicht neu erfinden; daher haben wir das Atomic Red Team-Schema als Grundlage genommen und es zu dem weiterentwickelt, was wir Cloud Attack Languagenennen. Die wichtigsten Änderungen: Wir haben AWS-Service-Tagging hinzugefügt (sodass Sie Techniken nach IAM, S3, GuardDuty usw. filtern können) und das Ausführungsmodell von einem einzelnen Executor-Block auf explizite, mehrstufige Definitionen umgestellt, die für die Verkettung von Cloud-Angriffssequenzen ausgelegt sind. Zudem haben wir das Schema selbst vereinfacht; da CAL-Techniken in einer verwalteten Ausführungsumgebunglaufen, werden Dinge wie Executor-Typ, Abhängigkeitsprüfungen und Berechtigungs-Flags von der Plattform gehandhabt, anstatt sie pro Technik definieren zu müssen. Das YAML bleibt übersichtlich und konzentriert sich auf das Wesentliche: die Angriffslogik. Das Format bleibt offen und lesbar; Sie können jede Definition im Threat Catalog einsehen und sie nach Belieben verwenden.

Dies ist eine Spezifikation, die sich ständig weiterentwickelt. So sieht eine Technik heute aus:

‍


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}

Einführung des Mitigant Threat Catalog

Heute machen wir den Mitigant Threat Catalog öffentlich zugänglich: einen interaktiven, offenen Katalog von Cloud-Angriffstechniken, der abstrakte Beschreibungen in ein interaktives Format umwandelt, einschließlich:

AWS CLI-Befehle. Tatsächliche AWS CLI-Befehle mit realistischen Parametern und simulierter Ausgabe, die dem entspricht, was Sie in einer Live-Umgebung sehen würden.

Definitionen der Cloud Attack Language. Jede Technik wird mit einer vollständigen YAML-Definition geliefert, die Sie direkt in den Attack Builder laden und in Ihrem Browser ausführen oder als YAML in Ihre eigenen Workflows integrieren können.

CloudTrail-Event-Mapping. Die spezifischen Event-Namen, die Ihre Erkennungsregeln auslösen sollten. Wenn Sie Sigma-Regeln schreiben oder Ihr SIEM optimieren, ist diese Information wichtig.

Anleitungen zur Erkennung und Risikominderung. Praxisnahe Empfehlungen für jede Technik, keine allgemeinen Best Practices auf hoher Ebene.

Wir sind mit 30 Techniken gestartet, die 12 der 14 ATT&CK-Taktiken abdecken und 20 AWS-Dienste umfassen: von IAM-Zugangsdatenmissbrauch (T1078) über S3-Ransomware mittels SSE-C-Verschlüsselung (T1486.A001) bis hin zur Manipulation von AWS Organizations (T1666).

‍

Warum kostenlos und öffentlich?

Weil bedrohungsorientierte Verteidigung nicht hinter einer Bezahlschranke versteckt sein sollte. Jeder Blogbeitrag, den wir geschrieben haben, jede MITRE-Analyse, jede Zusammenarbeit – alles öffentlich und darauf ausgerichtet, Cloud-Security-Experten auszustatten , um sich besser verteidigen zu können. Der Mitigant Threat Catalog ist eine natürliche Erweiterung dieser Arbeit.

Wie geht es weiter?

Der Mitigant Threat Catalog ist ein lebendiger Katalog. Wir werden kontinuierlich neue Techniken hinzufügen, die Abdeckung der AWS-Dienste erweitern und mit neuen ATT&CK-Releases sowie AWS-spezifischen Entwicklungen Schritt halten – während sich AWS-Dienste weiterentwickeln und neue APIs neue Angriffsflächen schaffen. Die Cloud Attack Language wird sich parallel dazu weiterentwickeln. Wenn Sie Vorschläge für hinzuzufügende Techniken haben oder etwas sehen, das verbessert werden könnte, schreiben Sie uns an contact@mitigant.io. Wir stehen erst am Anfang.

Katalog erkunden: threats.mitigant.io

‍