NEW: Group Profiler — instant APT intel lookup.Try it →

SOC analyst workflow

Use ATT&CK group profiles during triage

Turn documented threat-group techniques into testable hunting hypotheses, check original references and export an ATT&CK Navigator layer.

Download the plain-text checklist ·All analyst guides

A threat-group profile helps organise reported behaviour. It is useful for choosing what evidence to look for; it cannot identify an actor from a single technique or turn a technique count into a detection coverage score. Begin with a concrete investigation question and your available telemetry.

1. Resolve the name and read the original references

Open the ATT&CK group directory and find the group or alias mentioned in your report. The static APT28 profileis a useful walkthrough example. Compare the profile's aliases, MITRE identifier, dataset version and cited reports before assuming two publishers mean exactly the same activity cluster.

Follow the original references for dates, scope, platforms and procedure details. ATT&CK records documented activity; a profile is neither an exhaustive list of everything a group can do nor proof of current targeting. Two groups sharing techniques is expected and does not demonstrate a common operator.

2. Turn one reported behaviour into a testable hypothesis

Choose a technique relevant to systems you operate. Distinguish the technique from the concrete procedure: a broad command-execution technique describes a class of behaviour, while the report may name a particular process chain, command, file path or execution context.

  1. Write the expected observable sequence in plain language, with its source and observation date.
  2. Identify the logs needed to see it: endpoint process records, authentication events, cloud audit events, DNS or proxy logs, as appropriate. Confirm these logs are actually retained for the search period.
  3. State legitimate alternatives such as software deployment, scheduled administration or a security test. Plan how to distinguish them using context rather than the technique label alone.
  4. Run a bounded search in your authorised environment. Preserve query text, timezone, fields, time bounds, result identifiers and collection gaps in your internal case system.

Example hypothesis

A report describes script execution launched by an unexpected application. Your question is whether that parent-child process relationship occurred on the relevant endpoints during your incident window. Correlate command line, file identity, user context and subsequent activity. A script interpreter running by itself is too broad to support attribution or an incident conclusion.

Open the interactive Group Profiler, select the group, and use its matrix and export controls to create an ATT&CK Navigator layer. With multiple groups selected, inspect shared techniques to compare research scope. Treat a highlighted technique as a documented association, not proof that your environment can detect it.

Open the layer with a compatible official ATT&CK Navigator deployment approved by your organisation. Check the ATT&CK domain and version against the dataset shown in ThreatFilter. Do not upload internal incident details, private detection names or sensitive notes to a public application without approval. Keep an unmodified copy of the exported layer so your research selection can be reconstructed.

4. Record what the evidence supports

Keep actor attribution separate. A relevant match may justify investigation without identifying who performed it. If you use family-linked indicators as supporting leads, check their original reporting and dates using the IOC validation workflow.

The ATT&CK triage worksheet records the group identifier, dataset version, reference, hypothesis, telemetry, alternatives and outcome.

Primary references