🔄 Topic

Turning every MITRE ATT&CK technique ID scattered across my study vault into a real, sourced reference library instead of a bunch of bare T#### mentions.

🎯 Goal

Stop treating ATT&CK IDs as decoration in my notes and start treating them as claims that need to be checked against the actual MITRE data — then make every mention clickable.

🛠 What I Did

I scanned every Markdown note in my Obsidian study vault for T#### and T####.### patterns, then pulled the current official MITRE ATT&CK STIX 2.1 data (Enterprise, Mobile, and ICS) and matched each ID against real attack-pattern objects instead of assuming my own numbering was correct.

Main areas covered:

  • pattern-matching technique IDs across the whole vault
  • downloading and caching official ATT&CK STIX data locally
  • generating one explanatory note per confirmed technique, with tactic, platform, and source URL
  • building a single index to browse the library from
  • linking every valid mention in my existing notes back to its technique note
  • flagging IDs that were not legitimate ATT&CK techniques instead of silently linking them

🔗 Key Cybersecurity Connections

This is the same discipline a detection engineer needs when a rule references a technique ID: you don’t get to trust the label, you verify it against the authoritative source. Two of my vault’s IDs turned out to be revoked (T1562 → replaced by T1685, T1574.002 → replaced by T1574.001), and a handful of others (T0001–T0010) weren’t official ATT&CK IDs at all — they were my own custom detection numbering that happened to look like technique IDs.

🔍 Investigation Questions

  • Is this technique ID still active, or has MITRE revoked/replaced it?
  • Does the note’s context actually match the technique’s real definition?
  • Which of my “ATT&CK” references were actually custom IDs wearing ATT&CK’s clothing?
  • Are tactic and platform metadata attached, or just a bare ID?
  • Can every generated note be traced back to an official source URL?

🚨 Detection Opportunities

Potential monitoring ideas — applied here to my own knowledge base instead of a live environment:

  • notes citing a revoked technique ID without a status warning
  • custom internal IDs that collide with real ATT&CK ID formatting
  • technique references with no tactic/platform metadata attached
  • links pointing to a technique note that no longer exists (broken reference)
  • new vault content introducing an ID that was never validated against MITRE data

Example:

project=mitre-attack-library
change_type=technique_reference_validation
risk_area=stale_or_fabricated_id
triage=diff_against_cached_stix_data

🧭 MITRE ATT&CK Techniques

Confirmed through this pass, not guessed:

  • T1078 — Valid Accounts
  • T1059 — Command and Scripting Interpreter
  • T1105 — Ingress Tool Transfer
  • T1566.001 — Phishing: Spearphishing Attachment
  • T1562 — Impair Defenses (revoked, replaced by T1685)
  • T1574.002 — DLL Side-Loading (revoked, replaced by T1574.001)

🗺 Visual Investigation Diagram

Vault scan for T#### patterns
    ↓
Match against official STIX data
    ↓
Flag revoked / fake IDs
    ↓
Generate sourced technique notes
    ↓
Link every valid mention

⚠ Challenges

The hardest part wasn’t the matching, it was resisting the urge to “clean up” the six custom IDs (T0001–T0010) into real ATT&CK numbers just to make the library look complete. Leaving them alone and documenting them as non-standard was the more honest call.

📚 What I Learned

I learned that a personal knowledge base can accumulate the same kind of drift a SOC’s detection content does: labels get copied forward, nobody re-checks them against the source, and eventually a revoked or fabricated ID looks exactly as credible as a real one until someone diffs it against the authority.

➡ Next Steps

  • Add one personal lab example under each high-frequency technique (T1078, T1105, T1059, T1046, T1110)
  • Consider building separate tactic-level hub notes that group techniques by tactic
  • Re-run the validation pass whenever MITRE publishes a new ATT&CK release

🧠 Reflection

Building this felt less like organizing notes and more like running a small integrity audit on my own study material — which is exactly the mindset a defender needs before trusting any reference data.

🧩 Lessons Learned

What worked

Caching the official STIX data locally and matching against it instead of trusting memory or prior notes.

What broke

Nothing broke, but the process surfaced IDs that were quietly wrong or non-standard.

Why it broke

Custom detection numbering and stale ATT&CK IDs are indistinguishable from valid ones unless checked against a current source.

Fix / takeaway

Treat every reference ID in a knowledge base as unverified until it’s checked against the authoritative dataset.

📈 Skill Progression Context

This supports my cybersecurity progression because validating technique references against source data — and being willing to flag what doesn’t hold up — is a smaller version of the same discipline detection engineers need when building or maintaining ATT&CK-mapped content.

😄 TL;DR

Sixty-four ATT&CK IDs in my notes, checked against the real thing — two were revoked, six were never MITRE’s to begin with.