MITRE ATT&CK for Pentesters: A Practical Guide

If your mental model of Enterprise ATT&CK is a fourteen-tactic grid, it is already out of date. MITRE ATT&CK v19, released on 28 April 2026, split the long-standing Defense Evasion tactic into two — Stealth (TA0005) and Defense Impairment (TA0112) — taking Enterprise ATT&CK to 15 tactics, 222 techniques, and 475 sub-techniques.

Most write-ups treat that as blue-team housekeeping. We read it differently. The split formalises a distinction every operator already feels in the field: staying quiet is not the same job as blinding the defender. That is the theme of this guide — MITRE ATT&CK for pentesters as an offensive instrument, not a wall chart. Used well, it changes how we scope an engagement, how we take notes while we hold a shell, and how the report reads when it lands on the client’s desk.

ATT&CK from the attacker’s seat

You already know the vocabulary, so we will keep this short. Tactics are the why — the adversary’s immediate goal. Techniques are the how. Sub-techniques sharpen the how into something specific. Procedures are what we actually typed: which tool, in which environment, at which hour.

The v19 change worth internalising is that Defense Evasion split. Stealth (TA0005) is about reducing visibility and suspicion; Defense Impairment (TA0112) is about degrading or disabling a protective capability outright. For roughly six years those behaviours shared one bucket, which let reports quietly paper over a real operational choice: did we slip past the EDR, or did we tamper with it? Those are different risks, different detections, and different conversations to have with a client. The taxonomy now makes us say which.

If you want the framework’s history, its relationship to the Cyber Kill Chain, and the defensive reading, we cover that in our Cyber Kill Chain and MITRE ATT&CK explainer. Here we stay on the offensive side of the table.

Why an ATT&CK-mapped pentest is worth more

A raw pentest report is a pile of findings: a weak service account here, an unpatched host there, an over-privileged share down the hall. All true, all worth fixing — and all disconnected. What a finding list rarely answers is the question the client actually loses sleep over: what could a real attacker do with all of this, end to end?

Mapping the engagement to ATT&CK answers that. When we tie an action to OS Credential Dumping (T1003) and then to Remote Services (T1021), we have stopped listing weaknesses and started narrating an intrusion the defender can recognise. That does three things a flat finding list cannot:

• It gives us a shared language with the blue team. A SOC analyst, a detection engineer, and our operator can argue about the same technique ID instead of talking past one another.
• It makes findings adversary-grounded. A privilege-escalation bug means more once the client sees it sat between initial access and lateral movement, rather than floating in isolation.
• It makes the work repeatable. A well-mapped sequence becomes next quarter’s regression test or a purple-team session — not a story only the tester remembers.

For the person signing the purchase order, that is the difference that justifies the spend. Buyers rarely care how many findings fill a PDF; they care which ones move an attacker closer to the crown jewels. An ATT&CK-mapped penetration test separates the merely interesting from the genuinely dangerous, and hands security leadership something they can take to the board.

ATT&CK across the engagement lifecycle

Scoping: choose behaviour, not just assets

ATT&CK earns its keep before we touch a target. It turns a fuzzy brief — “simulate ransomware”, “test our detection” — into a concrete behavioural plan. We start from relevant threat behaviour: an ATT&CK Group profile, a cluster of techniques tied to an intrusion set known to hit the client’s sector, or simply the handful of tactics the client most fears. A mature engagement is threat-led — it picks adversaries that plausibly target this organisation. A tighter pentest just agrees which techniques are in and out of scope.

The questions ATT&CK helps us settle up front:

• Are we emulating an opportunistic smash-and-grab, or a patient, targeted operator?
• Do we prioritise credential access and lateral movement, or cloud persistence and collection?
• Broad coverage across many techniques, or deep testing of a few likely ones?

That last trade-off quietly decides the value of the whole engagement, and we will come back to it. This behaviour-first scoping is also the backbone of threat-led penetration testing, where the scenario has to reflect a credible, named adversary rather than a generic one.

Execution: map as we operate

The worst time to map to ATT&CK is the night before the report is due, reconstructing it from memory. The cleanest engagements map as they go. That does not mean pausing to annotate every command — it means our working notes carry the technique alongside the action: the foothold gained through Valid Accounts (T1078), code run via the Command and Scripting Interpreter (T1059), secrets pulled with OS Credential Dumping (T1003), hosts enumerated through Remote System Discovery (T1018), the hop sideways over Remote Services (T1021). When the procedure changes mid-operation, the mapping changes with it.

Live mapping buys two things. Accuracy — we can state exactly which techniques were attempted, which landed, and which the controls blocked. And honesty about choices: sometimes the most valuable line in a debrief is “we could have done X but chose not to, because it would have been loud, out of scope, or unnecessary.” That context is gold for the client and for any later purple-team replay.

Reporting: show coverage and gaps

Reporting is where ATT&CK is most visible — and most abused. Dumping a table of technique IDs and calling it maturity helps nobody. A good report uses ATT&CK to explain what happened, what we proved, and what we deliberately left untouched.

The practical instrument here is ATT&CK Navigator. A coverage layer can colour the techniques we tested, achieved, attempted-but-blocked, and left out of scope — one picture that tells the client more than any appendix. Pair it with gap analysis: which controls saw us coming, which behaviours sailed past unseen, which tactic areas we under-tested because the objective did not call for them.

This is the hand-off that makes offensive work pay defensive dividends. Give the blue team the mapped behaviours and they can replay them, build detections around them, and measure themselves against them. For clients who run a defensive programme, this is where our offensive report meets their side of the house — the counterpart to the defensive ontology we covered in our MITRE D3FEND guide — while staying anchored in what we actually did, not what a matrix says we might have.

The pentester’s ATT&CK toolkit

Three open-source tools turn ATT&CK from a reference into a workflow.

ATT&CK Navigator is the planning and reporting workhorse. Build a layer before the test, mark coverage during it, present outcomes after. It executes nothing — it visualises and communicates. We reach for it whenever we need to compare the emulation we intended against the activity we actually ran.

Atomic Red Team is a library of small, portable, per-technique tests. For us it shines in two moments: quickly checking whether a single technique is even feasible in the target environment, and giving the blue team a clean, repeatable way to replay a behaviour after we leave. It is no substitute for manual tradecraft — it is a fast way to exercise one technique in isolation.

MITRE CALDERA is where we go for automated adversary emulation: repeatable chains of ATT&CK-mapped behaviour. It suits longer red-team operations and mature internal programmes better than a one-week pentest, but when the goal is to run an emulation plan, rerun it, and watch whether the client’s visibility improves over time, CALDERA is the tool.

The natural flow: Navigator to design and communicate, Atomic Red Team to validate discrete behaviours, CALDERA to automate the repeatable ones.

From pentest to adversary emulation

Not every ATT&CK-flavoured engagement is adversary emulation, and the difference is worth stating plainly. A standard pentest is usually vulnerability-led: what can we break, exploit, or escalate here? Adversary emulation is behaviour-led: how would a relevant threat actor operate against this environment, and how far would they get?

ATT&CK is what makes the second question tractable — it is the behavioural reference that turns “test this network” into “emulate this class of adversary.” It is also what produces genuine purple-team value: document what we did in ATT&CK terms, and the defenders can tune detections against it and prove whether their telemetry improved. The report stops being a one-way document and becomes a reusable test.

The limits of mapping everything to ATT&CK

A caveat we hold to: ATT&CK is a map, not a score.

That is where weak ATT&CK practice falls down. Counting techniques becomes theatre — more coloured cells do not mean a better engagement or a safer client. Plenty of real findings refuse to map cleanly: architecture flaws, business-logic abuse, the specific way one application over-trusts another. Forcing those into a technique ID makes the report worse, not better. And breadth is not depth — brushing fifty techniques lightly is not the same as testing one realistic attack path to the floor.

We use ATT&CK to structure and communicate the work. We will not let it pad a coverage number, and we are happy to tell a client when a finding sits outside the matrix entirely.

Putting ATT&CK to work: a practical checklist

1. Scope from threat behaviour, not just an asset list.
2. Pick the tactics and techniques that match the client’s most credible attack scenarios.
3. Decide up front: broad-coverage pentest, or deeper adversary emulation.
4. Build a baseline ATT&CK Navigator layer before execution.
5. Map actions to technique (or sub-technique) IDs while you operate — never from memory afterwards.
6. Record blocked attempts and deliberate non-actions, not only successes.
7. Use Atomic Red Team for quick, repeatable single-technique checks.
8. Reach for CALDERA when repeatable, automated emulation adds value.
9. Report with behaviour sequences, a coverage layer, and detection gaps — not a flat finding list.
10. Treat ATT&CK as a communication and planning aid, not a score to maximise.

Frequently Asked Questions

Is MITRE ATT&CK different from the Cyber Kill Chain for offensive work?

Yes. The Cyber Kill Chain is a high-level, largely linear model of how an attack progresses. ATT&CK is a far more detailed behavioural library. For offensive work the two are complementary: the Kill Chain helps frame the stages of an operation, while ATT&CK lets us choose, execute, and report the specific behaviours inside each stage. We unpack both models in our Cyber Kill Chain and MITRE ATT&CK explainer.

Do we need ATT&CK if we already run thorough pentests?

You do not need ATT&CK to find vulnerabilities. You need something like it if you want to express those findings as adversary behaviour, improve repeatability, and give the blue team a cleaner basis for validation and replay. It raises the ceiling on what a report communicates, not the floor on what a tester finds.

Is ATT&CK only useful for red teams, or for standard pentests too?

Both. Red teams and adversary-emulation exercises lean on it more heavily, but even a standard pentest benefits from mapping its key actions and findings to ATT&CK when the goal is a report the client’s defenders can actually act on.

What changed in MITRE ATT&CK v19?

MITRE ATT&CK v19 was released on 28 April 2026. Enterprise ATT&CK now contains 15 tactics, 222 techniques, and 475 sub-techniques. The headline change is the split of the old Defense Evasion tactic into two: Stealth (TA0005) and Defense Impairment (TA0112).

Conclusion

Treated as an operational framework rather than a reference poster, ATT&CK changes the shape of an engagement: sharper scoping, precise notes, and a report that defenders and buyers can both use. Used well, it turns a penetration test from a list of weaknesses into a structured account of what an attacker did, what you caught, and what to test next.