Wazuh MITRE ATT&CK Mapping and Detection

What MITRE ATT&CK Is and Why It Matters

MITRE ATT&CK is a curated, continuously updated knowledge base of adversary behaviour observed in real intrusions. It is organised into tactics (the adversary's goal at a stage of the attack, such as Initial Access, Persistence, Privilege Escalation, Lateral Movement, Exfiltration) and techniques (the specific methods used to achieve each goal, each with an identifier like T1059 for Command and Scripting Interpreter).

Its value is that it gives the whole industry a shared vocabulary. Instead of describing a detection as 'that PowerShell thing', you describe it as T1059.001, and any analyst anywhere knows exactly what you mean. Threat reports, detection rules, red-team plans and SOC coverage can all be expressed in the same terms, which makes them comparable and composable.

For a SOC, ATT&CK answers the question that raw alert counts never can: not 'how many alerts did we get' but 'which attacker behaviours can we actually see, and which could happen in our environment undetected'. That reframing, from alert volume to behavioural coverage, is what makes ATT&CK the backbone of modern detection engineering.

Wazuh's Native ATT&CK Mapping

Wazuh integrates ATT&CK directly into its ruleset. A large share of the built-in rules carry a <mitre> block listing the technique identifiers they correspond to. When such a rule fires, the resulting alert is already tagged with its ATT&CK technique, so the mapping from detection to attacker behaviour is automatic rather than something an analyst has to look up.

This means that out of the box, without any extra work, your Wazuh alerts carry behavioural context. An alert is not just 'rule 92052 fired'; it is 'this corresponds to T1543, Create or Modify System Process, a Persistence technique'. That context is invaluable during triage because it immediately tells the analyst what stage of an attack they may be looking at.

Wazuh also ships the ATT&CK reference data, so the dashboard can resolve technique ids to their full names, descriptions and parent tactics. The framework data is kept reasonably current with the evolving ATT&CK matrix, though as with all reference data it is worth confirming the version in use during any coverage assessment.

The native mapping is a starting point, not a finished coverage statement. The built-in rules tag the techniques they were written to catch, but they do not cover the entire matrix, and the tags reflect the rule author's intent rather than a guarantee that every variant of a technique is detected. Treat the stock mapping as a strong foundation you then extend and validate, rather than as a complete account of what your environment can see. The sections that follow build on it by tagging custom rules and testing whether the supposedly-covered techniques really fire.

The MITRE ATT&CK Dashboard

The Wazuh dashboard includes a dedicated MITRE ATT&CK module that aggregates your tagged alerts into a coverage and activity view. You can see which techniques have fired, how often, on which agents, and over what time period, and you can pivot from a technique to the underlying alerts or from an agent to the techniques observed on it.

Two distinct readings come from this view. The first is operational: during an active incident, seeing techniques light up across multiple tactics (say, Initial Access followed by Execution followed by Persistence) is a strong signal of a real intrusion progressing through its stages, far more telling than the same alerts viewed in isolation.

The second reading is strategic: over a longer window, the dashboard shows which techniques your environment detects at all. A technique that has never fired is either never attempted or, more worryingly, never detectable. Distinguishing those two cases is the start of genuine coverage analysis, which the next sections address.

Tagging Your Custom Rules with ATT&CK

As you extend Wazuh with custom rules (and every real deployment does), those rules start out with no ATT&CK context. If you leave them untagged, your coverage map silently understates reality: you may be detecting a technique through a custom rule, but the dashboard does not know it, so the technique shows as cold.

The fix is to tag custom rules in local_rules.xml with the same <mitre><id> structure the built-in rules use. When you write a rule to detect a specific behaviour, identify which ATT&CK technique it corresponds to and add the tag. This is light work at authoring time and keeps the coverage map honest, which is the whole point of having one.

Good detection engineering treats ATT&CK tagging as part of the definition of done for any new rule. A rule without a technique tag is a rule whose contribution to coverage is invisible. Codesecure tags every custom rule it writes during client engagements precisely so the resulting coverage view reflects the real detection estate rather than only the stock ruleset.

Finding and Closing Coverage Gaps

The strategic payoff of all this mapping is gap analysis. Lay your fired-technique data over the full ATT&CK matrix and the cold cells (tactics and techniques with no detection) stand out. Those are the behaviours an attacker could perform in your environment without tripping a single alert. That picture, of where you are blind, is far more actionable than any list of alerts you did receive.

Not every gap is worth closing, which is where prioritisation comes in. You weight techniques by how relevant they are to your environment and your likely adversaries: a Linux-heavy shop weights Linux techniques, a fintech weights techniques used by the threat groups that target financial services. Threat-intelligence input (which ATT&CK supports through its group and software mappings) helps focus the effort on what is actually likely to be used against you.

Closing a gap means engineering a detection for the missing technique: a new log source, a new rule, sometimes a new agent capability, then tagging it so the matrix turns warm. Done repeatedly this becomes a continuous improvement loop: measure coverage, find the most important gap, build detection, re-measure. Codesecure runs this loop as an annual ATT&CK coverage assessment within managed SOC, so clients can show, in attacker terms, exactly how their detection capability improves over time. ISO/IEC 27001:2022 certified delivery.

Using ATT&CK Honestly: Coverage Is Not the Same as Protection

ATT&CK coverage is a powerful management tool, but it can mislead if treated as a score to maximise. A technique showing as 'covered' means you have at least one rule that can fire on at least one variant of it. It does not mean you detect every variant, that the detection is tuned and reliable, or that an analyst would correctly action the alert. A warm cell is a claim that deserves validation, not a guarantee.

This is why coverage analysis pairs with testing. Atomic tests and red-team exercises that actually execute techniques confirm whether your supposedly-covered detection really fires, and whether the alert reaches an analyst who acts on it. Coverage tells you where to test; testing tells you whether the coverage is real. The two together produce trustworthy assurance; either alone can flatter you.

Used honestly, ATT&CK keeps a SOC focused on the right question and gives leadership a defensible way to discuss detection maturity in attacker terms rather than tool features. Used as a vanity metric, it produces a colourful matrix and false confidence. Codesecure uses ATT&CK as a map to drive detection engineering and validation work, not as a number to inflate, which is what makes it genuinely improve a client's security posture.