Mapping Adversary Behaviors to MITRE ATT&CK Techniques

Hello. In the previous lesson, you defined what an authorized operation may touch, what it must avoid, and when it must stop. Those boundaries remain in force even when an adversary has used a method that would be interesting to test.

This lesson addresses a different planning question: which observed adversary behaviors are relevant to the exercise, and how can you describe them precisely? You will build a compact threat profile using MITRE ATT&CK. The aim is not to copy every action attributed to a group. It is to select documented behaviors, map them to techniques with evidence, and distinguish a credible scenario from an unauthorized imitation.

Read ATT&CK as a description of behavior

ATT&CK organizes reported adversary behavior at several levels. A tactic describes an immediate technical goal, such as discovering accounts or collecting data. A technique describes a way to achieve that goal; a sub-technique narrows the method further. A procedure is what an adversary reportedly did in a particular instance. A named tool may feature in a procedure, but the tool name alone is not a substitute for describing the behavior.

Watch the relevant portion of FIRST’s Workshop: MITRE ATT&CK Fundamentals for this distinction and for the Enterprise matrix that we will use.

For example, “discover domain accounts” identifies a behavior more precisely than “perform discovery.” ATT&CK records Account Discovery: Domain Account (T1087.002) for that method. If reporting also says the actor used PowerShell, that detail belongs in the description of the observed procedure; it does not change the account-discovery behavior into a different technique. A single reported action can sometimes support both an account-discovery mapping and a scripting-interpreter mapping, but each claim needs evidence.

The matrix is not a required route through an intrusion. Its columns organize goals, not compulsory phases in a fixed order. A useful threat profile preserves the context of individual observations rather than assembling every technique associated with a group into one imagined attack.

Map the report before choosing the scenario

A group page offers useful leads, but the underlying reasoning runs from reported action to ATT&CK mapping. Start with what the report says was done: the action, its object, the environment, and any stated purpose. Then check the tactic and the most specific technique supported by those details. If the source only says that an actor sought credentials, it does not establish whether they guessed passwords, stole browser-stored credentials, or used another method.

CISA’s Best Practices for MITRE ATT&CK Mapping provides a disciplined process for making that distinction. Read its steps for finished reports and its short discussion of mapping errors.

Three checks make this process practical:

1. Could you point to the reported behavior? A domain, file hash, or malware name may help locate a report, but it does not, by itself, establish how the actor operated.
2. Does the chosen ID describe the observed method? Use a sub-technique when the evidence warrants its detail. Otherwise retain the parent technique or record that the reporting is too thin to map confidently.
3. Are you quietly adding a second claim? Access through a VPN supports External Remote Services (T1133). Add Valid Accounts (T1078) if the reporting also establishes use of legitimate credentials; do not infer that merely from the word “VPN.”

A profile should also record uncertainty. “Not reported” means the source does not tell you; it does not mean the adversary never performed the action.

Bound a profile to an adversary and a body of reporting

We will use APT29 as a worked example because its ATT&CK group page contains behavior descriptions linked to reporting, and it identifies individual campaigns. This is a choice of well-documented source material, not a claim that APT29 is the most likely threat to the hypothetical finance workflow from earlier lessons.

The group page spans different years and operations. To avoid constructing a fictional single intrusion from that entire history, focus the example on behaviors the page associates with the SolarWinds Compromise. A campaign boundary helps you say where a behavior was reported; it still does not prove that every listed behavior occurred against the same victim.

The group is the subject of the profile; the campaign provides context for the selected observations; and the techniques classify particular reported behaviors. Keep those three levels separate. A group’s complete technique inventory is a record of reporting across operations, not an approved operator runbook.

Turn observations into a usable threat profile

A working profile needs more than IDs. For each selected behavior, record its source context, what the actor reportedly did, the mapping, and why it matters to the intended test. Here is a compact profile derived from the selected APT29 page descriptions:

These rows are selected observations, not a reconstructed timeline. They do not assert that a single operator performed them in this order or that each was necessary to collect email. That distinction protects the profile from a common failure: turning a catalog of associations into an invented, highly specific campaign narrative.

The first row also shows why technique and procedure serve different purposes. T1195.002 describes the class of behavior. The trojanized update is the reported instance that explains the mapping. Repeating the software supply-chain compromise is neither necessary nor appropriate merely to make an exercise “APT29-like.”

Separate threat relevance from permission

Now apply the previous lesson’s RoE to the hypothetical exercise: a supplied test account, a named finance workflow, a seeded marker, and no permission to touch other services, change accounts, collect real records, or impair controls.

The profile raises several potentially interesting questions, but most cannot be executed under those rules. Domain-account enumeration would leave the named workflow. Adding cloud credentials would change an identity. Mailbox collection would target data and services outside the agreed marker. Audit impairment contradicts the prohibition on changing security controls. A software supply-chain compromise would implicate systems and parties not authorized by this exercise.

The Valid Accounts behavior may offer a limited, scope-compliant abstraction: use the supplied test account through the approved path and measure whether it can reach the marker. Be precise about the limitation. A supplied account is not a compromised credential, and reaching the finance marker is not equivalent to reproducing APT29’s reported remote-access procedure. The exercise tests an identity-and-access question informed by the profile; it does not reproduce the historical campaign.

This distinction produces a better planning decision than either extreme—trying to imitate every reported action or labeling any use of an account “APT29 emulation.” If the approved environment cannot represent a behavior faithfully, mark it not tested, explain why, and seek a separately approved scenario if testing it is important. ATT&CK classification never expands authorization.

Make the profile legible to the next planner

A visual layer can help a team see selected techniques across the Enterprise matrix. HackerSploit’s Developing An Adversary Emulation Plan shows how a group’s ATT&CK information and Navigator can support that selection.

The image below illustrates the older Navigator-style matrix view. Its columns group techniques by tactic, while colored cells distinguish selections or annotations in a layer. Color alone does not tell you whether a technique was observed, approved for testing, or detected; the layer’s purpose and legend must supply that meaning.

For this lesson’s profile, a useful layer would distinguish reported in the selected campaign context, candidate for the authorized test, and excluded by the RoE. Keep a short written record beside it. Each entry should contain the technique ID and name, the reported behavior and source context, the reason for the mapping, its relevance to the business question, and its permission status. That record remains understandable even if ATT&CK’s layout or technique inventory changes.

Conclusion

A defensible threat profile starts with documented actions, maps each to the most specific ATT&CK technique the evidence supports, and states what remains uncertain. The APT29 example shows why a group page is a starting point rather than a ready-made operation: reported behaviors can span different contexts, and even well-supported mappings may be unsuitable for a particular engagement.

You now have a bounded set of threat-informed behaviors and a clear distinction between observed, relevant, and authorized to test. Next, you will use that discipline to build an operational-security risk register covering identities, infrastructure, communications, and evidence handling.