MITRE ATT&CK Framework
for Penetration Testing
Learn the process of mapping pentest findings to adversary tactics and techniques to improve security detections and translate vulnerabilities into behaviours.
MITRE ATT&CK is a publicly available, versioned knowledge base of adversary tactics and techniques based on real-world observations, maintained by MITRE. In penetration testing, ATT&CK is the common language that converts raw findings into adversary behaviour, giving you a clear view of the "why" and "how" behind a vulnerability rather than just a list of weaknesses.
What Is MITRE ATT&CK Mapping
in Penetration Testing?
ATT&CK mapping is the process of translating the results of a penetration test, such as a brute-forced account or a specific exploit, into the standardised tactics and techniques an adversary would use to achieve that result. The framework provides a clear vocabulary: a tactic is the adversary's objective (the "why"), a technique is the method used (the "how"), and a sub-technique offers a more specific breakdown of that method, identified by a suffix (e.g., T1xxx.xxx).
For most penetration testing contexts, the Enterprise matrix is the default classification system. MITRE maintains Cloud and Mobile matrices for environment-specific tests, but the Enterprise matrix is what providers use to map findings to a broad range of IT infrastructure and application behaviours.
Tactics & What a
Pentest Typically Exercises
Understanding the full set of attack techniques, known as TTPs (Tactics, Techniques, and Procedures), is the first step to interpreting a report. Crucially, a technique ID classifies behaviour, not severity.
| Tactic | What a Pentest Typically Exercises |
|---|---|
| Reconnaissance | Active or passive information gathering about the target, such as scanning for open ports and identifying services. External tests exercise this heavily before any exploitation begins. |
| Resource Development | Establishing infrastructure or accounts to support an operation. Pentesters typically simulate this rather than build real infrastructure, so coverage here is usually light or absent. |
| Initial Access | Exploiting a vulnerability or using valid accounts to gain a foothold in the target environment. This is a primary focus for external and web application tests. |
| Execution | Running malicious code or commands on a compromised system, such as exploiting a remote code execution flaw or using command-line interfaces for post-exploitation activity. |
| Persistence | Maintaining a presence in the system. Pentesters may create new user accounts, install services, or modify startup items to prove the risk, then remove them before the report is delivered. |
| Privilege Escalation | Gaining higher-level permissions through kernel exploits, misconfigured services, or token manipulation. Internal tests commonly validate this to show the realistic impact of a low-privilege foothold. |
| Defense Evasion | Techniques used to avoid security controls, like disabling security tools, using process injection, or exploiting trusted system processes to blend in with normal activity. |
| Credential Access | Stealing account names and passwords, often through credential dumping from memory (e.g., LSASS), or by capturing keystrokes and hashes during post-exploitation. |
| Discovery | Exploring the environment to understand what systems, users, and data are accessible. Internal tests exercise this with built-in OS commands such as net view or AD enumeration tools. |
| Lateral Movement | Moving from one compromised system to another, often using pass-the-hash, remote desktop services, or administrative shares. This tactic is a core deliverable of internal network tests. |
| Collection | Gathering data of interest from the compromised environment, such as accessing sensitive files, databases, or email stores. This is often simulated to demonstrate data exposure risk. |
| Command and Control | Communicating with a compromised system to control it. Pentests may simulate C2 traffic to test network detection, but full infrastructure deployment is typically a red team activity. |
| Exfiltration | Stealing data from the network. This is often constrained to simulated activity or excluded entirely from standard engagements due to the risk of handling real data. |
| Impact | Manipulating, interrupting, or destroying systems and data. This is usually deliberately limited for operational safety; destructive or ransomware-style activity is outside a standard pentest's remit. |
For a penetration tester, the two most valuable fields in a technique record are the procedure examples, which provide a template for describing how a finding was realised, and the detections field, which offers a checklist of what the SOC should look for to see that behaviour in action. A well-written finding borrows the language of procedure examples to say what was done, and the language of detections to say what should have been seen.
The core value of this approach is that ATT&CK acts as a reporting language, not just a threat-intel reference. Your findings are mapped into the framework, which makes them comparable over time, chainable into attack narratives, and immediately consumable by defensive teams. The direction matters: you start with what your tester actually did and find the label that fits, rather than starting with a threat group's playbook and looking for matching symptoms.
A Worked Example: Mapping a Pentest Finding
to Tactic, Technique ID and Detection
The following illustrative example shows how a single raw finding is transformed into a mapped chain. This is a hypothetical scenario, not a client engagement, but it demonstrates the exact output format you should expect from a well-mapped report. Notice how each raw finding is not just labelled but also given a concrete detection implication that your SOC can act on.
| Raw Finding | Tactic | Technique ID | What the SOC Should Have Seen |
|---|---|---|---|
| Insecure external remote access service exposed on the perimeter. | Initial Access | T1133 - External Remote Services | Anomalous connections to a remote access service from external IPs, possibly outside business hours. Look for repeated authentication attempts to the VPN gateway or RDP endpoint. |
| Brute-force attack against the remote access service. | Credential Access | T1110 - Brute Force | Multiple failed authentication attempts followed by a successful login from a single source. The SOC should alert on a login that follows a burst of failures. |
| Credentials harvested from the memory of a compromised jump host. | Credential Access | T1003.001 - LSASS Memory | Use of tools like Mimikatz or suspicious access to the LSASS process on a critical host. The SOC should monitor for lsass.exe access from non-system processes. |
| Use of stolen credentials to access multiple internal servers. | Lateral Movement | T1021.001 - Remote Desktop Protocol | Administrative logons from a single non-admin host to multiple servers via RDP, a classic sign of lateral movement. The SOC should flag impossible travel or a single-source host initiating RDP to many targets. |
Read this as an attack chain, not four isolated labels. The tester did not just find a misconfiguration; they turned it into a full attack path: they gained initial access, stole credentials, and then moved laterally across the network. Each row's detection column feeds the next step, which is why the chain is more useful to a defender than a list of CVEs. If the report stops at the tactic name or omits the detection question, you have not received a fully mapped finding.
How to Map Pentest Findings to ATT&CK:
The Step-by-Step Process
Analyse the Raw Finding
Identify the underlying behaviour. Distinguish between what the tester did and the weakness that allowed it.
Determine the Primary Tactic Objective
Identify the goal the action achieved, such as Initial Access or Privilege Escalation. If a single action served two purposes, choose the dominant one and note the secondary in the chain.
Select the Most Specific Technique
Choose the technique or sub-technique that describes the behaviour. Start broad, then narrow to a sub-technique only if the evidence supports it.
Verify the Technique ID
Check the official technique record on attack.mitre.org, as the framework is versioned and updated. A revoked ID is a red flag in a provider's report.
Note the Detection Implication
Identify the specific log source or alert rule that would have identified the behaviour. If you cannot state one, the mapping is incomplete.
Repeat & Assemble into Chains
Repeat for each finding, then assemble the findings into attack chains that tell the story of the breach rather than a flat bullet list.
How Deep to Map
Map to the sub-technique level only when the evidence from the test clearly supports that level of detail. For example, you might know the exact mechanism of credential dumping was LSASS memory access, which justifies T1003.001. If the evidence only shows credentials were harvested without confirming the source, map to the parent technique T1003 and state that the confidence is at the technique level. This declared honesty is a marker of a high-quality report and prevents over-claiming in front of your SOC.
What Doesn't Map
ATT&CK describes adversary behaviours, not every security weakness. A pure misconfiguration, such as an expired TLS certificate or a missing security header, is a hygiene weakness without a corresponding adversary behaviour. These should be reported using severity frameworks. You only map the exploitation act, if one occurred. For example, a missing MFA control is not itself a technique, but a successful account takeover via a brute-force attack against that account maps to T1110.
A note on automation: Be aware that analyst-performed mapping is more reliable than automated tagging. Automated tools can provide a starting point, but they often lack the context needed to select the correct technique or build a realistic chain. Ask your provider which approach they use. An analyst who can explain why one technique was chosen over a similar alternative demonstrates a higher level of rigour than a tool that simply pattern-matches.
Where ATT&CK Mapping Fits
in the Penetration Testing Process
Both the 5-step and 7-step pentesting conventions circulate in the industry, and neither is canonical. However, regardless of how you divide the work, ATT&CK mapping fits into the process as a classification layer over the exploitation and post-exploitation phases. The mapping itself is not a phase; it is an analytical pass that runs alongside the technical work.
| Pentest Phase | Tactics the Phase Naturally Exercises | Example Technique Family |
|---|---|---|
| Scoping/Rules of Engagement | Resource Development (planning) | N/A (Planning and preparation) |
| Reconnaissance | Reconnaissance | Active Scanning (T1595) |
| Enumeration | Discovery | System Information Discovery (T1082) |
| Exploitation/Initial Access | Initial Access, Execution | Exploit Public-Facing Application (T1190) |
| Post-Exploitation | Persistence, Privilege Escalation, Credential Access, Lateral Movement, Collection | Credential Dumping (T1003) |
| Reporting | N/A (Synthesis and communication) | N/A |
| Remediation/Retest | N/A (Verification of fixes) | N/A |
ATT&CK is a classification language, not a methodology. The two run in parallel. The matrix layout is a conceptual arrangement of tactics, not a strict chronological attack sequence, so avoid assuming an attacker will follow the matrix from left to right. A real intrusion might bounce between Discovery, Credential Access, and Lateral Movement several times before the objective is reached.
To get the best results, agree on the mapping depth and tactic scope during the scoping phase, not after the report is written. This ensures that the ATT&CK coverage is planned, not incidental. Furthermore, the known TTPs of adversary groups can inform the test scope, which is known as threat-informed scoping. If a specific threat actor is a concern for your sector, the tester can prioritise the techniques that actor is known to use.
Which ATT&CK Tactics Your Test Scope
Can Realistically Evidence
Different test scopes naturally exercise different parts of the ATT&CK matrix. The table below sets out typical expectations, but the final scope is always agreed per engagement. Understanding this before you buy prevents disappointment when a report does not show the tactic coverage you assumed.
| Scope Type | Tactics Typically In Play | Tactics Usually Excluded or Constrained |
|---|---|---|
| External/Infrastructure | Reconnaissance, Initial Access, Execution, some Discovery | Credential Access (often limited to the compromised host), Lateral Movement, Collection, Exfiltration, Impact. A purely external test usually stops at the perimeter. |
| Internal/Network | Initial Access (often simulated), Execution, Persistence, Privilege Escalation, Credential Access, Discovery, Lateral Movement, Collection | Exfiltration (often constrained to simulated), Impact (deliberately limited). Internal tests are where full attack chains are usually demonstrated. |
| Web Application | Initial Access (via web vulnerabilities), Execution | Lateral Movement, Persistence, Impact (unless scope allows). A web app test covers the application layer, not the internal network behind it. |
| Cloud | Initial Access (via exposed APIs or misconfigs), Privilege Escalation, Lateral Movement (within cloud tenant) | Impact (usually limited), Exfiltration (often constrained). Cloud tests cover the tenant, not the on-premises estate, unless the scope explicitly includes hybrid identities. |
The key takeaway is that ATT&CK coverage is driven by scope. If a report does not include Exfiltration, it is often a scope decision, not a quality failure. Likewise, an Impact technique like data destruction is rarely tested because the operational risk outweighs the evidence value. This is why it is critical to align your expectations with the provider before the test begins. Ask what tactics the proposed scope will realistically evidence, and record that answer in your scoping notes.
Four ATT&CK Mapping Anti-Patterns
That Reveal a Weak Report
These are the failure modes to look for when reviewing a provider's report. If you spot them, the mapping is weak.
Tactic-Only Tagging
How to spot it: The report labels findings as "Initial Access" or "Lateral Movement" but never identifies a specific technique or technique ID. The tactic is a category, not a finding. Without the technique, the SOC does not know what behaviour to look for.
ID Wallpaper
How to spot it: Every finding has a technique ID, but there are no chains, no rationale for the selection, and no detection implications. It's just a list of IDs that adds no analytical value over a standard CVE list. The presence of an ID alone is not evidence of quality mapping.
Aspirational Mapping
How to spot it: The report claims a technique that the scope never actually exercised. For example, an external test claiming a detailed Lateral Movement technique without the internal access to do so. This often stems from automated tagging that patterns-matches a finding to a broad range of techniques, overstating what was done.
Severity Drift
How to spot it: The report uses an ATT&CK ID as a proxy for severity. A technique ID is not a CVSS score, and a high-impact finding is not always the most likely to be exploited. A low-severity misconfiguration that enables a high-value technique is more behaviourally significant than the raw CVSS number suggests.
What Good ATT&CK Mapping
Looks Like in a Pentest Report
Use the following criteria as a checklist when evaluating a sample report or the quality of a delivered engagement. All of these points should be visibly present. If a provider cannot show you a sample that meets these criteria, treat that as a risk signal.
Findings carry technique IDs at the most precise defensible level, whether that is a technique or sub-technique. The report states which level applies.
Each mapping includes a procedure narrative that explains how the tester did it, which mirrors ATT&CK's own procedure-example convention. This narrative should be specific enough for a detection engineer to act on without a call.
Mappings are chained into attack paths, not presented as isolated labels, showing how a tester moved from one tactic to the next. The chain should tell a coherent story.
Detection implications are stated for each mapped technique, telling the SOC what to look for. This converts the mapping from a label into a testable hypothesis.
Ambiguous mappings explain the rationale for the choice, and where a finding could map to multiple techniques, the report discusses the possibilities rather than silently picking one.
Unmappable findings are explicitly flagged as such, without trying to force them into a technique. A finding that does not map is not unimportant; it is just outside the behavioural taxonomy.
Mapping depth and confidence level are declared within the report, showing you whether it's technique-level or sub-technique-level certainty.
The mapping is analyst-performed, and the methodology is available on request. Automated tools may be used as a starting point, but an analyst must sign off on the final selection.
Heatmaps or ATT&CK layer visualisations are useful report appendices for a quick overview, but they do not replace narrative chains. A heatmap shows which tactics were hit but not how they connect. If you are assessing a provider, verify that any technique IDs cited in sample material are current against attack.mitre.org, as the framework is updated regularly. A citation to a revoked ID indicates the report was not verified against the live framework.
Questions to ask providers before you buy: Ask for a sample report to review its mapping quality, request their mapping methodology, and confirm whether the tagging is manual or automated. If they cannot produce a sample with detection implications and chained attack paths, ask why not. These questions separate providers who treat mapping as a reporting feature from those who treat it as an analytical discipline.
What to Do With Mapped Findings:
From Report to Detection Improvement
A mapped report is only the beginning. The next step is to annotate each mapped technique to decide what your organisation did, or should have done, about it. Apply the "detected / prevented / missed" annotation to each technique. This converts the report from a list of problems into a set of detection engineering tasks.
| Technique ID | What We Did | What a SOC Would See | Detection/Log Gap |
|---|---|---|---|
| T1003.001 - LSASS Memory | Ran Mimikatz on a compromised host. | Access to LSASS, use of suspicious debugging tools. | No alerting on LSASS access from non-admin processes. |
| T1110 - Brute Force | Attempted 500 passwords against a VPN account. | Repeated authentication failures from one source IP. | Account lockout threshold set too high; no alert on burst of failures. |
| T1021.001 - Remote Desktop Protocol | Used stolen credentials to RDP to three servers. | RDP logons from a non-admin host to multiple servers. | No alert on single host initiating RDP to multiple targets. |
Detected
The behaviour was seen by your current controls. This is a validation of your detection stack. Record which alert fired so you can confirm it would fire again under similar conditions.
Prevented
Your controls blocked the action. This is a validation of your prevention stack. Record which control blocked it so you know what to preserve in future architecture changes.
Missed
The behaviour was not seen. This is your detection gap, and it is the row that requires action. Prioritise these before the detected and prevented rows.
For every "miss," convert it into a concrete detection requirement. Which log source would you need, or which rule would have turned that miss into a detection? This is the definition of a detection gap analysis. The output is not a longer report but a shorter list of specific rules to build or buy.
The goal is to check that the technique IDs in your report align with what your SOC or SIEM already tracks. This is a core part of purple teaming, where offensive findings are handed to the defensive team to improve detection coverage. The mapped report also becomes your baseline, which you can compare against future engagements to see if your defenses have improved. A retest that shows the same technique succeeding again tells you your detection gap remains open.
ATT&CK-Mapped Pentesting vs Red Teaming:
Where One Ends and the Other Begins
A penetration test maps the behaviours that the tester actually realised within an agreed scope. A red team engagement emulates a broader set of adversary tradecraft to test your detection against behaviours a penetration test might never touch. The distinction is not just about depth or duration; it is about what gets mapped and why.
| Attribute | Pentest Mapping | Red Team Mapping |
|---|---|---|
| What gets mapped | Realised findings from the specific test | Emulated attack paths based on a threat profile |
| Breadth of adversary behaviours | Limited to the vulnerabilities and scope of the test | Broad, designed to test a wide range of TTPs |
| Typical duration | 1 to 3 weeks | Several weeks to months |
| Detection-testing value | Validates specific findings | Validates detection across a wider attack surface |
The core distinction is simple: a pentest is not an adversary emulation exercise. You should not expect a standard pentest to imitate a named threat actor with precision. A pentest maps the behaviours a tester can realise with the vulnerabilities present; a red team emulates a defined threat profile to see if your detection would catch behaviours you did not know to look for. Upgrading to a red team assessment makes sense if your mapped pentest report shows a thin spread of techniques across the tactics, you have a SOC that needs validation against a wider set of behaviours, or you have a specific requirement to emulate named adversary behaviours rather than opportunistic ones. For a deeper exploration of these advanced scenarios, consider red team assessments that emulate adversary behaviours beyond a pentest's realised findings.
MITRE ATT&CK vs the Cyber Kill Chain,
CVSS and OWASP
ATT&CK, the Cyber Kill Chain, CVSS, and OWASP answer fundamentally different questions. Understanding these differences prevents you from forcing one framework to do the job of another. A good pentest report may use all four, but it will not present them as interchangeable.
| Framework | What It Answers | Role in a Pentest Report |
|---|---|---|
| MITRE ATT&CK | Adversary behaviour taxonomy. What did the adversary do, and how? | Classifies the behaviour of the attack, providing the narrative and detection context for each finding. |
| Cyber Kill Chain | A stage model of an intrusion, from reconnaissance to actions on objectives. | Useful for strategic overview and executive summaries, but less granular than ATT&CK for specific behaviours and detection. |
| CVSS/CVE | Vulnerability severity and identification. How bad is the flaw? | Prioritises vulnerabilities for patching based on technical severity. CVSS is a scoring system, not a behavioural taxonomy. |
| OWASP | Application security weaknesses and standards, particularly for web apps. | Identifies the class of weakness in the application, such as injection or XSS, and is used for remediation guidance in web app tests. |
Critical distinction: ATT&CK IDs are not severity ratings. A low-severity finding, such as a single instance of sensitive data exposure via an unprotected share, can be evidence of a high-value technique like Collection (T1560), which could be part of a larger attack chain. Severity and behavioural significance are independent axes. A finding with a low CVSS score can still be the pivot point for a full domain compromise, which is why the chain matters more than the score.
Is ATT&CK-Mapped
Penetration Testing Worth It?
Implementing ATT&CK-mapped reporting is a worthwhile investment for organisations planning to use the findings to improve their security posture over the long term. It is not a universal requirement, and the honest answer is that some buyers will not benefit from it. Use the conditions below as a decision gate.
ATT&CK-Mapped Reporting Makes Most Sense If:
- Your organisation runs or is building a Security Operations Centre (SOC) or a dedicated detection function. Without a team to consume the detections pass, the mapping has less immediate utility.
- Findings need to be communicated upward to the board or risk committee in a shared, structured risk language. ATT&CK gives you a taxonomy that non-technical stakeholders can learn once and reuse.
- You need to compare the effectiveness of your security controls over time, to track improvements against a baseline. Mapped reports let you see whether the same techniques keep succeeding.
- You plan to validate your detection coverage, not just fix individual vulnerabilities. The detected/prevented/missed exercise requires mapped findings as its input.
- Your estate is large enough to benefit from the operational discipline this approach requires. If you have a single server and no dedicated security staff, the overhead may not pay for itself.
For Smaller or Less Mature Estates
For a small, unmanaged estate with no internal technical team, a standard findings report may be sufficient. The extra effort of mapping adds little if there is no one to act on the detection implications. In that context, a clear CVE list with prioritised patching guidance is a better use of the provider's time and your budget.
Objection 1: "ATT&CK was built for defenders, so why use it in a pentest?" Because it is the perfect bridge between the two. It takes offensive output and translates it into a language the SOC and SIEM already understand. The framework is maintained with real-world intrusion data, so the labels carry meaning for both sides of the fence.
Objection 2: "This is just report embellishment." Mapping is worth paying for when it meets the quality criteria listed in this guide. If the report shows "ID wallpaper" or does not go beyond the tactic level, you are paying for buzzwords and should challenge the provider on it. This structured approach also aids UK organisations in translating technical findings into board and audit-consumable risk language, supporting better governance without replacing your specific compliance obligations.
For London and UK-based organisations, adopting this approach positions your reporting to meet the expectations of investors and regulators who increasingly demand to see a direct line between a technical test and business risk. The structured taxonomy makes it easier to evidence that security testing is informed by real-world adversary behaviour rather than a generic vulnerability checklist.
Frequently Asked
Questions
Translate vulnerabilities
into adversary behaviours.
Discuss your scope directly with a senior CREST-certified consultant. Receive analyst-mapped findings with detection implications your SOC can act on. Fixed-price quotes delivered within 24 hours.