Stop Wasting Agent Tokens on ATT&CK Lookups

tl;dr

Most AI CTI workflows are badly designed.

They burn tokens doing work that should have been solved before the prompt even started.

Instead of giving the model a clean retrieval layer, they ask it to:

remember ATT&CK from training data
guess which CWE fits a bug report
infer CAPEC mappings from a paragraph of text
search broadly, summarize loosely, and hope for the best

That is expensive, slow, and unreliable.

CTI Butler fixes a big part of that problem.

It gives agents:

a stable vocabulary for CTI work
real objects instead of mushy web-search approximations
relationships cleanly enough to build multi-step workflows
current framework data, which matters a lot when the alternative is letting the model freestyle

If you are building AI-assisted CTI workflows, this is the difference between an agent that looks smart in a demo and one analysts actually keep using.

This post does two things:

explain why CTI Butler is such a good fit for agentic workflows
show how to turn it into a Claude Code skill that can take a messy analyst prompt and recommend likely ATT&CK, ATT&CK Mobile, ATT&CK ICS, CWE, CAPEC, D3FEND, DISARM, Location, and Sector mappings

The second part matters more, because the real value is not “Claude can look up T1190”.

The real value is “Claude can take some scrappy notes from an analyst and turn them into structured CTI pivots backed by CTI Butler”.

AI Knowledgebase Retrieval

Agents waste time on solved CTI problems

Analysts do not need an AI model to be creative about ATT&CK lookup.

They need it to be fast, accurate, and grounded.

Yet a lot of agent workflows still do the dumb version of the task:

take messy analyst input
ask the model to remember the right framework objects
ask it to guess the best mapping
ask it to explain itself afterward

That is backwards.

Framework retrieval should be the easy part.

Reasoning should be the expensive part.

CTI Butler flips that the right way around.

That is why CTI Butler is such a strong foundation for agent workflows: one API, current data, standard objects, and much less ambiguity.

1. It shrinks the hallucination playground

Left alone, a model will answer CTI questions with great confidence and varying levels of truthfulness. Sometimes it gets it right. Sometimes it blends:

ATT&CK techniques with CAPEC attack patterns
current framework content with outdated framework content
real relationships with suspiciously plausible sounding nonsense

CTI Butler narrows the problem down to something much safer.

Instead of asking Claude to “know cyber threat intelligence”, you can ask it to:

retrieve candidate objects
compare them
explain the best matches
suggest the next pivots

That is the right division of labor.

Let the API be the memory.

Let the model be the interpreter.

2. It gives agents IDs, versions, and objects instead of vibes

Humans are quite comfortable with fuzzy labels.

Wasn't there an ATT&CK thing for brute forcing cloud passwords?

Agents are much more useful when they can move from that fuzziness into stable identifiers.

For example:

T1110 for Brute Force
T1110.003 for Password Spraying
CWE-79 for Cross-site Scripting
CAPEC-242 for Code Injection

Once an agent has a real object ID, everything gets easier:

summarizing
version comparison
relationship lookups
report normalization
downstream automation

This is where CTI Butler stops being a lookup service and starts becoming agent infrastructure.

3. It makes the retrieval step visible

One of the most annoying things about AI workflows is trying to debug why the model said what it said.

If the answer is “it probably searched around and inferred something”, that is not operationally satisfying.

With CTI Butler, the retrieval path is inspectable:

which endpoint was called
which search terms were used
which framework matched
which version was returned
which relationships were pulled next

That makes the workflow not only smarter, but debuggable.

In practice, debuggable beats magical nearly every time.

4. It keeps the context window focused

A lot of bad agent design comes from shoveling too much source material at the model.

Huge framework dumps.

Random PDFs.

A scraped web page, a spreadsheet, three markdown notes, and a prayer.

CTI Butler gives you something cleaner:

one object
one relationship list
one bundle
one version diff

That keeps prompts tight and makes the model do reasoning rather than document wrestling.

5. It is naturally chainable

This is the part that makes the whole thing useful.

CTI Butler is not just useful for one-shot lookup.

It is useful for workflows that unfold in stages.

For example:

an analyst pastes a paragraph saying “the actor exploited a public app, dropped a web shell, and stole credentials”
Claude recommends likely ATT&CK techniques from the wording
CTI Butler returns the top candidate objects
Claude explains why each candidate fits or does not fit
CTI Butler pulls related CAPEC or CWE objects for root-cause and exploitation context
Claude turns the result into a structured summary, hunt lead, or classification suggestion

That is the sort of work agents should be doing: narrowing, comparing, and explaining.

6. It works across the workflows you already have

The same source of truth can support:

an analyst using the CTI Butler UI
a script using the REST API
a platform using TAXII 2.1
a Claude Code skill

So you do not end up building a toy AI workflow disconnected from the rest of your stack.

You build on top of the same CTI layer your people already trust.

Building a Claude Code skill

Why start with a Claude Code skill?

A Claude Code skill is a good fit here because it is:

quick to build
easy to version control
easy for analysts to understand
enough to deliver a genuinely useful workflow quickly

The practical question is simple:

Can we give analysts one genuinely helpful CTI workflow today?

With CTI Butler, yes.

The better use-case: recommendations, not just lookups

One obvious skill would be object enrichment from a known identifier, for example ATT&CK Enterprise T1078.

That is useful, but it is also a bit boring. If the analyst already knows the identifier, most of the hard thinking has already happened.

A more interesting skill is this:

An analyst gives Claude raw text, rough notes, or a sloppy question, and Claude recommends likely framework objects worth investigating.

For example:

/cti-recommend The report says the actor exploited an internet-facing app to get in, used a web shell, then dumped credentials and moved laterally with valid accounts. What ATT&CK, CAPEC, CWE, or D3FEND objects should I look at?

Now we are talking.

That workflow is useful because it sits at the messy point between:

unstructured analyst thinking
structured CTI frameworks

CTI Butler is a very good bridge between those two worlds.

What the skill should do

The skill should:

read the user’s plain-English input
identify likely concepts, actions, and vulnerabilities
search CTI Butler for likely ATT&CK, ATT&CK Mobile, ATT&CK ICS, CWE, CAPEC, D3FEND, DISARM, Location, Sector, and ATLAS candidates
rank the best matches
explain why each recommendation is plausible
suggest follow-on lookups for confirmation

The skill should behave less like a dictionary and more like a fast analyst who shows their working.

Setup

Create:

.claude/skills/cti-recommend/SKILL.md

Before using it, make your CTI Butler API key available in the shell Claude Code runs in:

export CTIBUTLER_API_KEY='REDACTED'

Then add the following skill:

---
name: cti-recommend
description: Recommend likely ATT&CK, ATT&CK Mobile, ATT&CK ICS, CWE, CAPEC, D3FEND, DISARM, Location, Sector, or ATLAS objects from plain-English analyst input using CTI Butler, then explain the best matches and next pivots.
argument-hint: [plain-text input]
disable-model-invocation: true
allowed-tools: Bash(curl:*) Read
---

Use this skill when the user gives a natural-language description of adversary behaviour, a vulnerability scenario, incident notes, a report excerpt, geopolitical context, industry context, defensive control questions, or asks which CTI Butler knowledgebase objects best fit what they are describing.

## Goal

Turn messy CTI input into a short, high-confidence recommendation list backed by CTI Butler results.

## Inputs you should handle

- Report snippets
- Incident response notes
- Questions like "what ATT&CK technique does this sound like?"
- Questions like "which CWE is closest to this issue?"
- Questions like "which D3FEND control helps here?"
- Questions like "which sector or location is most relevant?"
- Questions about influence or disinformation activity
- Short vulnerability descriptions
- Known IDs mixed with plain text

## Workflow

1. Read the user input and extract key action words, objects, or weakness clues.
2. Decide which frameworks are relevant:
   - ATT&CK Enterprise for enterprise adversary behaviour
   - ATT&CK Mobile for mobile adversary behaviour
   - ATT&CK ICS for industrial control systems adversary behaviour
   - CAPEC for attack patterns
   - CWE for software weaknesses
   - D3FEND for defensive techniques and countermeasures
   - DISARM for disinformation activity
   - Location for geographic context
   - Sector for industry context
   - ATLAS for AI-related adversary behaviour
3. Build short keyword searches for each relevant framework.
4. Search CTI Butler object endpoints with those keywords.
5. Review the returned candidates and pick the strongest matches.
6. When a recommendation looks strong, retrieve that object's detail endpoint.
7. When helpful, retrieve the relationships endpoint for the top 1 to 3 recommendations.
8. Return ranked recommendations with a short explanation for each.

## Endpoint patterns

- ATT&CK Enterprise search:
  `https://api.ctibutler.com/v1/attack-enterprise/objects/`
- ATT&CK Mobile search:
  `https://api.ctibutler.com/v1/attack-mobile/objects/`
- ATT&CK ICS search:
  `https://api.ctibutler.com/v1/attack-ics/objects/`
- CAPEC search:
  `https://api.ctibutler.com/v1/capec/objects/`
- CWE search:
  `https://api.ctibutler.com/v1/cwe/objects/`
- D3FEND search:
  `https://api.ctibutler.com/v1/d3fend/objects/`
- DISARM search:
  `https://api.ctibutler.com/v1/disarm/objects/`
- Location search:
  `https://api.ctibutler.com/v1/location/objects/`
- Sector search:
  `https://api.ctibutler.com/v1/sector/objects/`
- ATLAS search:
  `https://api.ctibutler.com/v1/atlas/objects/`

- Detail endpoint:
  `https://api.ctibutler.com/v1/<FRAMEWORK>/objects/<ID>/`
- Relationships endpoint:
  `https://api.ctibutler.com/v1/<FRAMEWORK>/objects/<ID>/relationships/`

## How to search well

- Prefer several short searches over one giant search string.
- Use the most concrete nouns and verbs first.
- Use the `text` query parameter for ATT&CK Enterprise, ATT&CK Mobile, ATT&CK ICS, CAPEC, CWE, D3FEND, DISARM, and ATLAS.
- Use `name` for Location and Sector.
- For ATT&CK Enterprise, Mobile, and ICS, search for behaviour words such as `credential`, `dump`, `web shell`, `exploit`, `phishing`, `valid accounts`, `lateral movement`, `mobile`, `android`, `ios`, `plc`, `engineering workstation`, `ics`, `scada`.
- For CWE, search for weakness words such as `input validation`, `authentication`, `deserialization`, `cross-site scripting`, `injection`.
- For CAPEC, search for the exploit pattern or attack behaviour.
- For D3FEND, search for the defensive outcome, control, or hardening action the user is asking about.
- For DISARM, search for narrative manipulation, impersonation, social amplification, or other disinformation activity terms.
- For Location and Sector, search for explicit country, region, city, industry, or vertical names.
- If the user mentions AI systems, prompt injection, model evasion, or training data abuse, include ATLAS.

## Curl template

Use this pattern for search:

`curl -sS -G -H "accept: application/json" -H "API-KEY: $CTIBUTLER_API_KEY" --data-urlencode "<QUERY_PARAM>=<TERM>" "<ENDPOINT>"`

Use `text` for ATT&CK Enterprise, ATT&CK Mobile, ATT&CK ICS, CAPEC, CWE, D3FEND, DISARM, and ATLAS. Use `name` for Location and Sector.

For object detail:

`curl -sS -H "accept: application/json" -H "API-KEY: $CTIBUTLER_API_KEY" "<DETAIL-ENDPOINT>"`

## Output format

Use this structure:

### Recommended ATT&CK
- `<ID> <Name>`: why it matches the user's input

### Recommended ATT&CK Mobile
- Only include this section when relevant.

### Recommended ATT&CK ICS
- Only include this section when relevant.

### Recommended CWE
- `<ID> <Name>`: why it matches the user's input

### Recommended CAPEC
- `<ID> <Name>`: why it matches the user's input

### Recommended D3FEND
- Only include this section when relevant.

### Recommended DISARM
- Only include this section when relevant.

### Recommended Location
- Only include this section when relevant.

### Recommended Sector
- Only include this section when relevant.

### Recommended ATLAS
- Only include this section when relevant.

### Best next pivots
- List 3 to 5 concrete object IDs or API paths to inspect next.

### Confidence notes
- State where the evidence is strong, weak, or ambiguous.

## Rules

- Do not invent objects or relationships.
- Make it explicit when a recommendation is tentative.
- If multiple ATT&CK techniques look similar, include the top candidates and explain the difference.
- If the user provided an exact ID, prioritize detail retrieval for that object before searching broadly.
- If no good match is found, say that clearly and suggest better search terms rather than forcing a bad recommendation.

Test the API before invoking the skill

Before throwing Claude at it, test one search manually.

For example:

curl -sS -G \
  -H 'accept: application/json' \
  -H "API-KEY: $CTIBUTLER_API_KEY" \
  --data-urlencode 'text=credential dump' \
  'https://api.ctibutler.com/v1/attack-enterprise/objects/'

Then test an endpoint that uses name instead:

curl -sS -G \
  -H 'accept: application/json' \
  -H "API-KEY: $CTIBUTLER_API_KEY" \
  --data-urlencode 'name=energy' \
  'https://api.ctibutler.com/v1/sector/objects/'

If those work, the skill has what it needs.

Using the skill in Claude Code

Now an analyst can do something more natural than hunting for IDs manually.

For example:

/cti-recommend The actor exploited a public-facing app, deployed a web shell, dumped credentials, and reused valid accounts to move laterally. Recommend ATT&CK and CWE mappings.

And Claude can return something like:

### Recommended ATT&CK
- `T1190 Exploit Public-Facing Application`: matches the initial access behaviour described.
- `T1505.003 Web Shell`: strongly fits the reported post-exploitation implant.
- `T1003 OS Credential Dumping`: aligns with the credential dumping activity.
- `T1078 Valid Accounts`: fits the use of legitimate credentials for follow-on access.

### Recommended CWE
- `CWE-287 Improper Authentication`: plausible if the entry point involved bypassing or abusing authentication logic.
- `CWE-79 Improper Neutralization of Input During Web Page Generation`: worth considering if the public-facing compromise involved web input handling.
- `CWE-89 Improper Neutralization of Special Elements used in an SQL Command`: worth checking if exploitation appears injection-driven.

### Recommended CAPEC
- `CAPEC-242 Code Injection`: plausible if the compromise involved injection into a public-facing application.
- `CAPEC-35 Leverage Executable Code in Non-Executable Files`: worth reviewing depending on how the web shell was introduced.

### Best next pivots
- `/v1/attack-enterprise/objects/T1190/`
- `/v1/attack-enterprise/objects/T1505.003/relationships/`
- `/v1/attack-enterprise/objects/T1003/bundle/`
- `/v1/cwe/objects/CWE-287/`
- `/v1/capec/objects/CAPEC-242/`

### Confidence notes
- The ATT&CK recommendations are strong because the user described specific behaviours.
- The CWE recommendations are weaker because the root software weakness was not explicitly stated.

That is much more useful than a pure “lookup this one ID” workflow.

It helps the analyst think.

It speeds up classification.

And because the recommendations are grounded in CTI Butler, the workflow stays inspectable.

Why this beats a pure prompt workflow

You could ask Claude something like:

What ATT&CK techniques and CWEs does this report sound like?

Yes, of course.

And sometimes the answer will be decent.

But you lose the important parts:

you do not know which framework version the model had in mind
you do not know whether it is leaning on memory, guesswork, or retrieval
you cannot reliably chain the answer into the next step
you cannot easily inspect the candidate objects it considered

Once CTI Butler is in the loop, the workflow gets much tighter.

The model is still doing something useful, but it is no longer improvising without a map.

Other useful follow-ons

Once you have /cti-recommend, you can spin off a whole family of practical skills:

/attack-diff: given an ATT&CK object, compare how it changed across versions and explain whether the change matters for detections or internal content.
/cti-pivot: given a top recommendation, pull relationships and suggest the next most useful analyst pivots.
/report-normalize: given a rough report excerpt, recommend framework mappings and return a normalized list of candidate objects to review.
/ai-threat-map: given an AI-related incident description, search ATLAS through CTI Butler and recommend likely ATLAS techniques and defensive pivots.

At that point, CTI Butler becomes something more interesting: the structured retrieval layer behind a whole set of agent workflows.