Using Known ATT&CK Techniques to Predict What Came Before and What Happens Next

tl;dr

Most teams use ATT&CK techniques like labels.

That is useful, but it leaves a lot of value on the table.

A confirmed ATT&CK technique should be treated as a pivot:

what likely happened before this?
what is likely to happen next?

That is where MITRE’s Technique Inference Engine (TIE) becomes useful.

It turns a known technique, or a small set of known techniques, into a ranked list of associated techniques you can actually investigate.

In CTI Butler, that means you can move from:

ATT&CK-tagged alert

to:

look-back hypotheses
likely next-step hunts
a tighter response plan

I want to frame the rest of this post from two roles:

the researcher building and refining threat hypotheses
the incident responder making fast decisions under pressure

Both often start with the same signal: an ATT&CK technique. For example, a detection triggers an alert tagged T1059 (Command and Scripting Interpreter).

Most teams stop at the label.

This post is about what happens when you do not.

Why single-technique mapping is not enough

Technique labels are useful for consistency, reporting, and control mapping, but incidents are not single nodes. They are chains.

If you want a deeper model for representing those chains explicitly, see Using ATT&CK Flow to Model the Procedure Layer Missing in ATT&CK.

If we only map what we already saw, we end up reactive:

detections trigger too late
hunts are too broad
response playbooks miss adjacent steps

The goal is to move from:

“We observed this technique”

to:

“Given this technique in this environment, these predecessor and successor techniques are now most probable.”

For a researcher, that creates testable hypotheses.

For an incident responder, it creates an immediate hunt plan.

Researcher view: infer what likely happened before

When a technique is observed, ask what prerequisites are usually required for it to work.

If you observe T1059, likely predecessor areas often include:

initial access (T1566 phishing, T1190 exploit public-facing app)
execution setup (T1204 user execution)
staging and delivery (T1105 ingress tool transfer)

You are not claiming certainty.

You are ranking plausible prior paths and then testing them against telemetry.

A simple researcher workflow:

Start from the confirmed technique.
Pull commonly co-occurring or prerequisite techniques.
Filter by platform and identity context in your environment.
Convert each relationship into a hypothesis and expected evidence pattern.
Hand the prioritized set to response and hunting teams.

This gives analysts a focused “look-back” plan instead of a blind search.

Incident responder view: infer what happens next

The same logic applies forward.

If scripting execution is already confirmed, likely next objectives may include:

credential access (T1003)
discovery (T1082, T1018)
persistence (T1547)
lateral movement (T1021)

If a detection with an ATT&CK tag triggers, responders can immediately use it as a branch point:

“If T1059 is true, check for T1003 and T1082 on the same host and identity”
“If discovery evidence appears, prioritize lateral movement telemetry (T1021)”
“If privilege abuse appears, escalate containment scope”

These predictions become concrete response tasks:

pre-stage detections for probable follow-on steps
prioritize log enrichment where the likely next techniques live
run short, targeted hunts before attacker progression completes

This is how technique mapping becomes operational tempo, not static documentation.

MITRE’s Technique Inference Engine

MITRE’s Technique Inference Engine (TIE) is a machine learning model for inferring associated MITRE ATT&CK techniques from previously observed techniques.

At a practical level, TIE helps by doing one thing well: it converts an observed set of techniques into a ranked list of additional techniques that are statistically associated with them.

That gives both roles immediate value:

researchers get a structured hypothesis set to test
responders get a prioritized list of “hunt next” candidates

TIE is built on ATT&CK technique observations extracted from many CTI reports. From that data, it learns which techniques frequently appear together in real intrusions.

So when you provide one or more observed techniques, TIE returns likely associated techniques with confidence scores.

One important point: this is probabilistic guidance, not deterministic truth. You still validate with telemetry in your own environment.

TIE output naturally fits the two directions you care about:

backward inference: “what likely happened before what we saw?”
forward inference: “what is likely to happen next?”

The model returns associations; your team applies sequence context to decide which are likely predecessor vs successor behaviour.

For a detailed walkthrough of how those sequences are represented in ATT&CK Flow objects, see Understanding the Structure of ATT&CK Flows to Model CTI Reports.

CTI Butler: applying TIE in live investigations

We’ve implemented technique inference in CTI Butler using MITRE’s TIE approach so analysts can move directly from ATT&CK-tagged detections to prioritized investigation paths.

Example 1: one alert, immediate forward hunt

Observed:

T1059 (Command and Scripting Interpreter) confirmed on an endpoint.

CTI Butler’s TIE returns high-probability associated techniques including Phishing (T1566), Masquerading (T1036), and Boot or Logon Autostart Execution (T1547).

These are association candidates, not guaranteed chronological next steps.

Responder actions:

Look back for potential phishing entry evidence (T1566) tied to the same user/session.
Hunt for masquerading patterns (T1036) on the affected endpoint and directly related hosts.
Prioritize persistence checks for autorun/logon artifacts (T1547) to prevent re-entry.

Outcome:

instead of waiting for a second major alert, you pivot immediately into high-value hunts suggested by real technique associations.

Example 2: backward reconstruction for scoping

Observed:

T1003 (credential dumping) triggered in a server segment

CTI Butler’s TIE suggests strongly associated techniques including Command and Scripting Interpreter (T1059), Exploit Public-Facing Application (T1190), and Data Encrypted for Impact (T1486).

For this workflow, treat T1059 and T1190 as likely look-back hypotheses, and T1486 as a high-impact behavior to actively monitor during containment.

Researcher actions:

Build a predecessor hypothesis list from associated techniques that fit timeline and tactic context.
Map each hypothesis to required evidence (mail logs, auth anomalies, exploit traces, transfer artifacts).
Run a parallel watch for destructive-impact signals (T1486) while scoping continues.
Confirm or reject each hypothesis using time-bounded queries.

Outcome:

faster reconstruction of likely entry path, better containment prioritization, and less guesswork during root-cause analysis.

Observed set:

T1059 + T1082 + T1018

When multiple observed techniques are supplied, CTI Butler’s TIE can narrow predictions to paths consistent with that combination, reducing noise compared with single-tag inference.

Responder + researcher actions:

Use top-ranked outputs as a shared hunt queue.
Split by role: researcher validates prior-path hypotheses, responder deploys controls against near-term likely techniques.
Feed confirmed findings back into detection and playbook logic.

Outcome:

higher precision hunts and faster coordination across intel, detection, and IR.

Using the MITRE ATT&CK Enterprise TIE API in CTI Butler

If you want to operationalise this in tooling, the MITRE ATT&CK Enterprise TIE endpoint in CTI Butler is:

https://api.ctibutler.com/v1/attack-enterprise/tie

The workflow is simple:

supply one or more observed ATT&CK Enterprise technique IDs
get back a ranked set of associated techniques
turn the top results into research or response actions

Workflow 1: start with one observed technique

Say your alert is tagged with:

T1059

Use the MITRE ATT&CK Enterprise TIE endpoint with a request body containing the observed technique IDs.

A minimal request will look roughly like:

{
  "technique_ids": [
    "T1059"
  ]
}

In practice, the request will look like:

curl -X 'POST' \
  'https://api.ctibutler.com/v1/attack-enterprise/tie' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'API-KEY: REDACTED' \
  -d '{
  "technique_ids": [
    "T1059"
  ]
}'

The response gives you a ranked set of associated techniques and scores.

Operationally, the next step is not “accept the whole list”. The next step is:

take the top few techniques
separate likely predecessor behaviours from likely successor behaviours
test both against your actual host, user, and time context

If the top outputs include T1566, T1036, and T1547, that immediately gives you a useful investigation split:

T1566: entry-path look-back
T1036: local evasion / execution-adjacent hunt
T1547: persistence check

Workflow 2: refine the prediction with multiple known techniques

Single-technique inference is useful, but multi-technique inference is where this gets sharper.

If you already know the intrusion includes:

T1059
T1082
T1018

submit them together to the same MITRE ATT&CK Enterprise TIE endpoint.

For example, the request shape will look roughly like:

{
  "technique_ids": [
    "T1059",
    "T1082",
    "T1018"
  ]
}

And the API call will look like:

curl -X 'POST' \
  'https://api.ctibutler.com/v1/attack-enterprise/tie' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'API-KEY: REDACTED' \
  -d '{
  "technique_ids": [
    "T1059",
    "T1082",
    "T1018"
  ]
}'

This usually reduces noise because the model is no longer trying to explain one isolated behaviour. It is trying to explain part of a sequence.

That makes the top-ranked techniques much more useful for:

narrowing hunt scope
prioritising detections to stage next
deciding which adjacent tactics deserve immediate attention

Workflow 3: turn TIE output into concrete worklists

The most practical way to use the API is to split the output into two worklists.

For every top-ranked inferred technique, ask:

does this make more sense as a predecessor hypothesis?
or as a likely next-step hypothesis?

That lets you create:

look-back validation
look-forward containment

For example, if T1003 is the confirmed observed technique and CTI Butler returns T1059, T1190, and T1486 as strong associations:

T1059 and T1190 are good candidates for look-back validation
T1486 is a strong candidate for immediate forward monitoring and containment planning

This is the point where the TIE API becomes operationally useful.

It stops being “interesting ATT&CK enrichment” and starts becoming:

a hunt queue
a scoping aid
a containment priority list

A simple Claude skill on top of the TIE endpoint

If you want a practical AI wrapper for this workflow, put the endpoint behind a Claude Code skill.

I covered the general pattern for skills in more detail in Stop Wasting Agent Tokens on ATT&CK Lookups. The same idea applies here, but the prompt is more specific: take known ATT&CK Enterprise techniques, call the TIE endpoint, and turn the output into a hunt plan.

For example:

---
name: attack-tie
description: Use CTI Butler's ATT&CK Enterprise TIE endpoint to predict likely predecessor and successor techniques from known ATT&CK techniques.
argument-hint: [ATT&CK technique ids]
disable-model-invocation: true
allowed-tools: Bash(curl:*) Read
---

Use this skill when the user provides one or more ATT&CK Enterprise technique IDs and wants to know what likely happened before or what might happen next.

## Workflow

1. Extract the ATT&CK Enterprise technique IDs from the user input.
2. Call:
   `https://api.ctibutler.com/v1/attack-enterprise/tie`
3. Authenticate with:
   `API-KEY: $CTIBUTLER_API_KEY`
4. Send the technique IDs in the JSON request body.
5. Return:
   - the top inferred techniques
   - which are better treated as look-back hypotheses
   - which are better treated as look-forward containment or hunt hypotheses
   - 3 to 5 recommended next actions

## Request body

Send JSON in this shape:

```json
{
  "technique_ids": [
    "T1059",
    "T1082"
  ]
}

Request rules

Always send technique_ids as a JSON array.
Only include ATT&CK Enterprise technique IDs.
If the user provides plain text instead of IDs, first identify the ATT&CK Enterprise techniques that best fit, then send those IDs to the endpoint.

Curl template

curl -X 'POST' -H 'accept: application/json' -H 'Content-Type: application/json' -H "API-KEY: $CTIBUTLER_API_KEY" 'https://api.ctibutler.com/v1/attack-enterprise/tie' -d '<REQUEST_BODY>' ```

That gives analysts a fast way to move from:

known technique

to:

ranked associated techniques
hunt priorities
likely predecessor and successor paths

without having to manually reason through every possible branch each time.

Conclusion

ATT&CK gives you a common language.

TIE gives you a way to turn that language into ranked, testable paths.

For researchers, that means better hypotheses.

For incident responders, it means immediate direction on where to hunt next and what to contain first.

The key habit is simple:

treat every ATT&CK-tagged detection as a pivot, then use TIE to expand that pivot into a validated attack path.

In practice, that means turning ATT&CK-tagged detections into look-back validation and look-forward containment tasks instead of stopping at the label.