DEV Community: Kennedy

Mitigant Threat Catalog: 3x Techniques, 12 AWS Services Added, and a Matrix View

Kennedy — Thu, 19 Mar 2026 17:46:59 +0000

About a month ago, we launched the Mitigant Threat Catalog, a free, interactive resource that operationalizes MITRE ATT&CK cloud techniques into executable CLI commands, CloudTrail event mappings, and Cloud Attack Language definitions. The catalog launched with 30 techniques across 20 AWS services.

We recently made a major update, and we are excited to describe these changes, including how you can contribute or send feedback. We would also discuss some interesting observations we noticed, and where the catalog is headed.

The Gap We Are Closing

Most users of the MITRE ATT&CK framework realize that it is deliberately abstract. It is designed as a framework for categorizing adversary behavior and, given its aim of universal applicability, requires end users to provide contextual interpretation. But that is exactly where a gap is introduced: translating high-level content into operational capabilities.

Consider T1078.004 (Valid Accounts: Cloud Accounts). The framework tells you that adversaries leverage stolen cloud credentials to operate under legitimate identities. What it does not tell you is the exact API call involved:
Or the specific CloudTrail event to catch (CreateAccessKey), or the sequence of events before and after the command.

The Mitigant Threat Catalog closes that gap by providing the exact commands for implementing techniques and procedures in an interactive format. This allows you to run CLI commands right in the browser. Also, you see the corresponding API calls, CloudTrail event names, and structured Cloud Attack Language definition of multi-step attacks that are typically executed before and after the exact technique.

What's New: 61 Techniques, 12 AWS Services Added, Across 11 ATT&CK Tactics

This update adds 61 techniques and 12 AWS services, bringing the catalog to 91 techniques across 32 AWS services. The techniques span across 11 MITRE ATT&CK tactics, including Lateral Movement and Privilege Escalation, which had zero coverage at launch.

Here are the 12 newly added AWS services: Amazon Cognito, Amazon CloudFront, Amazon CloudWatch, Amazon DynamoDB, Amazon EventBridge, Amazon Kinesis, Amazon VPC, Amazon WorkSpaces, AWS Config, AWS IAM Identity Center, AWS Secrets Manager, and AWS Security Hub.

Two of these deserve some mention:
IAM Identity Center controls federated access across every account in an AWS organisation. T1556.007 demonstrates how an attacker with sufficient permissions can modify user attributes to hijack an identity and create backdoor permission sets.

*Security Hub * is the detection layer that attackers want to suppress first. T1562.001 covers how adversaries disable it alongside AWS Config to eliminate the centralized view of security posture.
Both include verified CLI commands, CloudTrail events to monitor, and Cloud Attack Language YAML definitions.

The Matrix View

The original card-grid interface works well for finding individual techniques. It does not communicate the shape of coverage across the attack lifecycle.
The new matrix view addresses this, modeled after the MITRE ATT&CK Navigator. It renders all 91 techniques in an 11-column tactic grid, color-coded by tactic. Each card shows the technique ID, title, and AWS service, and clicking navigates directly to the full technique page. Both views share the same search and filter state.

What the First Month Revealed

Two practitioner patterns stood out.

IAM credential abuse is the focus for practitioners. The most visited techniques are all T1078 variants: T1078 (Valid Accounts), T1078.004 (Cloud Accounts), and T1078.A001 (IAM Users). Practitioners are not here for just the static description. They already know IAM credential compromise is the most documented initial access vector, hence they want to see the real action: how techniques can be practically executed, the output/feedback from AWS, and corresponding CloudTrail events.

Practitioners skip descriptions and go straight to execution. A significant share of readers on T1552.005 (Unsecured Credentials: EC2 Instance Metadata) skip the description entirely and head straight to loading the Attack Builder. They already know what EC2 Instance Metadata is. They want to run the technique and see what it looks like in practice. Funny enough, the specific curl command to the IMDS endpoint generates no CloudTrail event, which is precisely what makes it challenging to detect.

If you want to see the Attack Builder in action before connecting your own environment, the Mitigant demo provides a pre-configured AWS environment where you can run techniques without any setup.

Feedback Channels

Every catalog page now has a Suggest a Technique or Report an Issue link in the footer. There is also a notification signup for anyone who wants to be kept in the loop as new techniques and services are added.

What Comes Next

The vision is to cover as many cloud attack techniques as possible: AWS-specific techniques from the AWS Threat Technique Catalog, the full MITRE ATT&CK Cloud matrix, and eventually Azure and Google Cloud Platform. We want your suggestions to shape that direction.

Explore the catalog: https://threats.mitigant.io/

For the full post including analytics, usage patterns, and detailed technique breakdowns, see the complete post on the Mitigant blog: https://mitigant.io/en/blog/mitigant-threat-catalog-61-techniques-12-aws-services-added

Mitigant Threat Catalog: Turning Static Cloud Techniques to Dynamic Executions

Kennedy — Sun, 15 Feb 2026 16:55:00 +0000

The MITRE ATT&CK Framework is indispensable for understanding adversary behavior, especially in cloud environments. It provides a structured taxonomy of tactics and techniques that defenders rely on to build and validate their security architectures. As a framework, it is deliberately consistent and abstract; the techniques are intended to be interpreted and operationalized by practitioners in their specific environments.

Consider a sub-technique like T1078.004 (Valid Accounts: Cloud Accounts); the framework indicates that adversaries may obtain and abuse credentials for cloud accounts to gain initial access, establish persistence, or escalate privileges. The interpretation work, however, is where things get interesting.

There are several distinct procedures under T1078.004 that an attacker could leverage: creating a new IAM user, attaching a login profile for console access, generating long-lived access keys, or assuming cross-account roles. Each procedure maps to a different API call, a different CloudTrail event, and a different detection opportunity. Translating T1078.004 into the corresponding AWS CLI command:

aws iam create-login-profile --user-name john-doe --password @3wewSwew

requires piecing together information from multiple sources, cross-referencing CloudTrail event names, and reverse-engineering what a real attack chain looks like at the CLI level.

The AWS Threat Techniques Catalog has done excellent work in this space, not only providing AWS-specific context for existing MITRE techniques but also introducing techniques not available in the MITRE ATT&CK and increasing overall understanding of cloud attack behavior. However, there are still gaps practitioners need to address before they become productive. Given that we address this gap at Mitigant and understand exactly how we have navigated these challenges, we thought it was worth closing it by providing a resource that helps defenders be more effective. We aim to complement the existing work by adding the executable layer: actual CLI commands, detection mappings, and structured definitions that can be plugged directly into automated security workflows.

Introducing the Mitigant Threat Catalog

The Mitigant Threat Catalog was designed to close the gaps I mentioned in the last paragraphs. We recently published it as a free, publicly available resource. It is an interactive, open catalog of cloud attack techniques that operationalizes MITRE ATT&CK cloud techniques into actionable, executable formats. Each technique in the catalog is expressed in two forms:

AWS CLI Commands: Actual AWS CLI commands with realistic parameters and simulated output that mirrors what you would see in live AWS environments, along with the corresponding CloudTrail event names your detection rules should trigger on. If you are writing Sigma rules or tuning your SIEM, this information is essential.

Cloud Attack Language (CAL) Definitions. Each technique also ships with a complete YAML definition that can be loaded directly into the Attack Builder and executed in your browser, or taken and integrated into your own workflows. The Cloud Attack Language is a YAML-based schema for defining multi-step cloud attacks, built on the popular Atomic Red Team format. It adds AWS service-type tagging and explicit step chaining designed for cloud attack scenarios. A comprehensive description of CAL is available here.

Here is what CAL looks like:

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}

In addition to the AWS CLI commands and CAL definitions, each technique includes detection and mitigation guidance with practical, technique-specific recommendations.

Mitigant Threat Catalog launches with 30 techniques spanning 12 of 14 ATT&CK tactics and covering 20 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 should not be gated. I have consistently shared this kind of knowledge publicly, including MITRE ATT&CK breakdowns, collaborations with Sekoia on Scattered Spider detection, or joint work with Cado Security on cloud forensics. The goal has always been to equip cloud security practitioners with practical, actionable resources. Mitigant Threat Catalog is a natural extension of that effort.

What's Next

This is a living catalog. I will keep adding techniques, expanding AWS service coverage, and keeping pace with new ATT&CK releases as AWS services evolve and new APIs introduce new attack surfaces. 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, I would love to hear from you at contact@mitigant.io.

Explore the catalog: threats.mitigant.io

For the full deep dive, including prior MITRE ATT&CK analysis work, partner collaborations, and a comprehensive description of the Cloud Attack Language, see the complete post on the Mitigant blog.

Threat Modeling For Cloud Native Infrastructure

Kennedy — Sat, 24 Sep 2022 14:34:58 +0000

OWASP defines a threat model as a structured representation of all the information that affects the security of an application. It allows a view a view of applications and its environment through security lens. Threat models can be applied to virtually every digital system - serverless applications, cloud infrastructure, mobile and web applications.

However, threat modeling for cloud-native infrastructure requires a mindset shift ! In traditional security scenarios, heavy emphasis is made on the use of data flow diagrams, attack graphs, attack trees etc.

Realistically though, some of these approaches might hinder agility and not be easily digestible for DevSecOps teams. Developers and SRE teams use several tools and workflows for their daily work. Some of these tools & workflows would be better appreciated than the traditional threat modeling tools.

For example, observability tools like AWS X-Ray can be leveraged to understand attacker flows rather than using attack trees. If possible, both kids of visualization can be used. The key thing is empathy, the security pulse of the participants should be felt and used as a yardstick for selecting commensurate approaches.

Another really cool thing, a mix of qualitative and quantitative approaches is feasible. Cloud security solutions like Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platforms (CWPP) provide unimaginable insights into cloud infrastructure and applications. These tools can be useful for deriving info on cloud resources usage, deployment info (e.g. regions), configuration errors, vulnerabilities, security risk info e.t.c.

Furthermore, the references from OWASP e.g. the Threat Modeling document remain invaluable resources to strike a balance.

Neglecting threat modeling exercises in modern cloud environments is indeed a recipe for disaster. The sheer amount of complexity is beyond our mental models hence the need for well-structured, intentional, and pragmatic threat analysis.

Gladly though, it seems a lot of security teams are still passionate about threat modeling, the overwhelming reception I received from a related post on LinkedIn is evident! Wow 🎉

I recently went through an excellent AWS threat modeling workshop I deemed it instructive to share a few lessons I personally grabbed:

Threat modeling is interdisciplinary & cross-functional! All stakeholders need to be part of the show; they probably have better context and understanding than security teams. The security folks' main job is to coordinate the session and wear different hats (black, grey, white …).🤠
The target application or infrastructure should be split into smaller parts to enable deeper analysis. A complex AWS Connected Vehicle Solution was used in the workshop, going through the entire application in a go would not be optimal.🍕

Leverage user stories to understand different use-cases and threat vectors. 🐞🐞
Clear documentation is not optional. In the workshop a workbook is provided as a guide/template. Use your preferred documentation system e.g. Confluence. Hopefully, its the same system used by the other teams participating 😇
Take advantage of 😷 Adam Shostack's 4 Question Frame for threat modeling:👇

👉 What are we working on? Use data flow diagrams to represent features and data flows between the various elements e.g. AWS databases, S3 , API gateway.

👉 What can go wrong? - What are the threat vectors to be considered and possible impacts. - STRIDE is super useful here.

👉 What are we going to do about it? This is about risk response strategies - avoid, mitigate, transfer or accept.

👉 Did we do a good enough job? This is really tricky and difficult to measure during the session. Lessons learnt are to be taken and applied to other parts of the infrastructure.

What COVID-19 Taught the Cyber Security Industry: Security Chaos Engineering

Kennedy — Sat, 07 Aug 2021 07:27:03 +0000

Vaccinology

The COVID-19 pandemic has significantly changed our lifestyles, the impact is far-reaching and definitely unforgettable. Our view of what constitutes humanity e.g. business, education, healthcare has been redefined. Ultimately, rapid adaptation has been the ubiquitous option, paving the way for emerging and innovative solutions to gain unparalleled adoption. However, the most prominent of these innovative solutions is the ecosystem surrounding the accelerated development, testing, distribution and administration of COVID-19 vaccines.

Fig. 1 The Impact of Vaccines on Measles

Talking about vaccines, the truth is the underlying concepts of vaccinology date back to the 17th century when Buddhist monks drank snake venom to confer immunity from snake bites. However, scientific methods were first applied in the 18th century, by Edward Jenner. Since then, vaccinology has matured dramatically, highly influenced by the need to eradicate diseases. Clearly, vaccines are core fundamentals for human resilience to diseases. For example, newly born babies get a shot of hepatitis B within 12 hours after birth to increase their chances to survive (resilience) or at least lead a normal, healthy life. Through this approach and several similar related methods, several diseases e.g measles (Fig 1) have been eradicated.

Chaos Engineering

The most important lesson drawn from vaccines is that true resilience is achieved by introducing chaos (fake chaos) into a stable system to identify and mitigate the hidden problems (real chaos). This is the theory behind vaccines, by introducing non-malicious substances into biological systems, the natural immune system is boosted and hardened to overcome diseases. This simple idea that has enabled human resilience to diseases over several centuries is the fundamental theory behind chaos engineering.

Netflix pioneered chaos engineering to overcome the digital pandemic that threatened the survival of the streaming business in the aftermath of migrating to AWS. The decision to adopt chaos engineering, despite sounding crazy at that time, helped Netflix survive several AWS outages. This is indeed similar to how humanity has survived epidemics via vaccination. In recent years, chaos engineering has gained traction as enterprises face different kinds of digital pandemics on the path to digital transformation. According to Werner Vogels (CTO@ Amazon), “Failures are a given, and everything will eventually fail”, so literally failures are bound to occur, the question is when and how we prepare to prevent or minimize the resulting impact. Chaos engineering proffers options for addressing these concerns, by proactively experimenting on systems. Consequently, several chaos engineering products and services have emerged, including offerings from cloud service providers e.g. the AWS Fault Injection Simulator.

Security Chaos Engineering

Failures often manifest with security implications by impacting confidentiality, availability and integrity. Such security failures are majorly man-made aka cyber-attacks or can be due to human errors or misconfigurations. Due to the rapid adoption of digital systems, security failures are increasing at a monumental pace. The COVID-19 pandemic is further exacerbating these cybersecurity challenges as enterprises strive to be technology-driven. However, traditional cyber-security mechanisms are struggling to grapple with the emerging security challenges. On the one hand, humans operators are incapable of completely and continuously maintaining clear mental models of modern systems. This is is a prerequisite for designing efficient security systems, furthermore, these modern systems require more innovative security mechanisms due to new operating models that differ from traditional systems. The bulk of the emerging technologies are cloud-native, increasingly complex and dynamic, thus offering little or no opportunity for gate-keeping style security mechanisms. Therefore, innovative cyber security solutions are imperative to overcome these evolving security challenges.

Fig 2. Attackers view cloud-native systems as a single attack objective.

Security chaos engineering is an emerging sub-discipline, pioneered by Aaron Rinehart to potentially addresses the aforementioned challenges. It leverages fault injection techniques to detect and mitigate security vulnerabilities especially in complex systems e.g. cloud-native infrastructure. The same chaos engineering techniques are employed while focusing on security attributes. The state-of-the-art cloud-native security systems focus on multiple abstraction layers commonly referred to as the 4Cs of cloud-native security: code, containers, cluster and cloud. Most cloud-native security systems are designed to tackle security issues emerging from at least two of these layers. Effectively, these layers are treated as silos, due to the logical barriers and existing complexities, unfortunately, this viewpoint doesn’t capture or represent attackers’ view. Attackers literally see a single system (a unified attack objective) or otherwise plan to laterally move across the multiple abstraction layers regardless of the logical demarcations (Fig 2). Attacks orchestrating these kinds of multi-layered, lateral movements are becoming more commonplace in recent times.

Fig 3. Cloud-native security systems need to adopt an attacker-centric lens to have clear visibility across the 4Cs of cloud-native security.

Overcoming these security challenges requires the adoption of viewpoint, essentially, the emerging cloud-native security systems ought to enable unified visibility and operations across cloud-native systems, as illustrated in Fig.3. Security chaos engineering provides opportunities for achieving this objective, by injecting failures across the entire system, the resulting outcome enables clear visibility. The fault injection campaigns produce security insights suitable for detecting vulnerabilities, especially those with casual relationships across abstraction layers. Furthermore, unlike traditional security systems, the derived security insights are approx. 100% actionable, given vulnerabilities are detected prior to cyber attacks. Most cloud-native systems act in the opposite, due to their reactive nature, events occur before action is taken thereby affording attackers windows-of-opportunity (which can be over 200 days of attacker dwell-time). It is noteworthy that, the security insights gained via security chaos engineering campaigns can be added to other security systems to enrich intelligence, thus enhancing visibility and achieving proactiveness(Fig 4). imperative to overcome these evolving security challenges.

Fig 4. Integration of knowledge gained from Security Chaos Engineering into into a security architecture.

Final thoughts

Just as diseases are effectively tackled with vaccines, security chaos engineering offers opportunities for effectively overcoming cyber-attacks at various abstraction layers. This is one of the fundamental lessons the cybersecurity industry can derive from the COVID-19 pandemic: true resilience comes by constructive security fault injection! Security in the cloud-native era is more about adopting resilient postures than just being secure. By applying the concepts of security chaos engineering to cloud-native systems, there are opportunities for ensuring the security attributes are intact, by verifying that various security controls (predictive, detective, protective & corrective) function as expected. This approach leads to a proactive security methodology and affords security to be ahead of the game.