ATTACK-Tools packages the MITRE ATT&CK framework into a queryable relational data model plus an emulation planning tool, aimed at defenders building authorized purple-team programs.
| Tool | nshalabi/ATTACK-Tools — utilities for the MITRE ATT&CK framework, including a relational data model and an adversary emulation planning tool |
| Category | Threat intelligence data modeling and adversary emulation planning |
| Primary Use | Querying ATT&CK techniques, groups, malware, and Red Canary ATOMIC tests via SQL, and designing adversary emulation plans with ATT&CK View |
| Safe Use | Building and querying a local ATT&CK knowledge base for authorized security assessments, purple-team exercises, and defensive research in owned lab environments |
| Telemetry Note | This is a passive planning and analysis tool; it executes nothing against networks itself, though ATOMIC test details it stores describe actions that generate endpoint telemetry when run under authorized test harnesses |
nshalabi/ATTACK-Tools is one of those quietly influential repositories that solves a structural problem rather than a flashy one: the MITRE ATT&CK framework is distributed as STIX 2.0 JSON, which is fine for tooling but awkward for analysts who want to slice and dice the knowledge base ad hoc. The project converts that graph-oriented data into a relational schema hosted in SQLite, and layers ATT&CK View on top as a planning surface for adversary emulation. With just over a thousand stars and a BSD-claimed license badge, it sits in the niche of ATT&CK enablement infrastructure rather than offensive tooling proper — you will not find payload code here, only the metadata and structure needed to reason about adversary behavior.
The repository ships two main artifacts. The first is the ATT&CK data model: a set of SQL scripts, attack_view_db_structure.sql and attack_view_db_data.sql, that respectively build the schema and load the data into a local SQLite database. The second is ATT&CK View, described by the README as a planning tool that helps defenders design adversary emulation plans, bundled with a complete emulation plan for APT3 originally developed by MITRE. That APT3 plan doubles as a worked example of how to extend the data model with additional enrichment sources, specifically Red Canary ATOMIC tests.
The schema design follows STIX 2.0 semantics closely. The central table is sdos_object, which holds all STIX Domain Objects with a discriminator type column — attack-pattern for techniques, malware, tool, and intrusion-set for adversary groups. Each object carries its full STIX identifier in the id field, such as attack-pattern--dcaa092b-... for Access Token Manipulation, and that key is the join point for everything else. External references live in a separate external_references table linked by fk_object_id, which is how you resolve a technique name to its familiar MITRE number like T1134 by filtering source_name IS 'mitre-attack'.
This normalization choice matters more than it looks. Because the model is relational rather than document-based, questions that are painful in raw JSON — which techniques apply to the Windows platform, which malware does a given intrusion set use, which tests exist for a technique — become single joins or subselects. The README demonstrates this with a platform filter using x_mitre_platforms_windows, showing how MITRE's custom STIX extensions were flattened into queryable columns. The author is explicit that the schema should be thought of as a conceptual model: nothing ties it to SQLite, and it can be ported to any RDBMS if you want ATT&CK data alongside existing analyst infrastructure.
The relationship table is where the framework's graph structure survives translation. STIX relationship objects record typed edges such as uses, connecting an intrusion-set source to the malware or tool objects it employs. The README's worked example walks through enumerating everything APT3 uses, and the result is instructive: custom implants like SHOTPUT and PlugX sit alongside the native Windows utility schtasks.exe. That mixture of bespoke and living-off-the-land capability is exactly the kind of intelligence product a queryable model makes trivially discoverable, and it is the same data that feeds detection engineering and coverage gap analysis downstream.
Enrichment is handled through three dedicated tables for Red Canary's ATOMIC test content: atomic_test maps tests to ATT&CK external IDs, atomic_attack_test holds the actual test details including executor type and command text, and atomic_input_arguments captures per-test parameters. This is a deliberate demonstration of the model's extensibility — the author shows how to bolt a third-party test library onto the core ATT&CK graph while keeping referential integrity through the external ID key. The pattern generalizes: an authorized team could equally join in detection coverage data, internal incident mappings, or CTI reporting to produce a unified analytical surface.
A representative read-only query against the local database looks like this, listing technique names with their MITRE IDs: SELECT name, external_id FROM sdos_object INNER JOIN external_references ON sdos_object.id = external_references.fk_object_id WHERE sdos_object.type IS 'attack-pattern'. Any SQLite management tool can open the resulting database file, which makes the whole corpus browsable by analysts who would never write a STIX parser. This is the core value proposition: ATT&CK as an analyst-accessible asset rather than a format only frameworks consume.
It is worth pausing on what ATT&CK View is actually for, because the README frames it carefully in defender terms. Adversary emulation planning is the discipline of translating threat intelligence — the behavior of a real intrusion set — into a structured test plan that an authorized red or purple team can execute against a scoped environment. The bundled APT3 plan from MITRE's published adversary emulation series is the canonical template. The tool's contribution is the structure: coverage mapping, plan organization, and traceability back to technique IDs, not execution itself. Note that the ATOMIC executor commands stored in the database are live test actions; they belong in dedicated emulation harnesses against systems you own, not pasted into production shells.
Defensively, this repository is a telemetry planning asset more than a telemetry source. Because ATOMIC test records describe concrete endpoint actions — service configuration changes, PowerShell invocations via native binaries — the model can be used in reverse: map your detection rules and log sources against the test corpus to estimate what an emulation would generate in your EDR or Sysmon pipeline. Nothing in ATTACK-Tools itself touches a network, leaves footprints, or requires agents; it is a planner and a database, and the only observable artifacts it produces are in whatever authorized emulation framework you subsequently drive from the plans.
The release notes also list XML conversions of the three ATT&CK matrices — enterprise-attack.xml, ics-attack.xml, and mobile-attack.xml — indicating the repository targets the full breadth of the framework, including industrial control and mobile domains that many ATT&CK utilities ignore. The repository is predominantly HTML by language breakdown, consistent with ATT&CK View being a packaged application rather than a Python library, and the README links out to supporting reading including a Royal Holloway technical report on purple team playbooks, which reinforces the intended audience.
Caveats for operators: the README itself contains a few typos and the embedded ATT&CK data reflects the point-in-time conversion, so technique numbering shown in examples (pre-revocation IDs like T1156) may not match current matrix versions — expect to refresh the data or accept the snapshot. There is no formal license file confirmed in metadata despite the badge, so commercial reuse deserves a quick check before embedding it in a product. For authorized assessment teams, detection engineers, and anyone building ATT&CK-aware internal tooling, however, nshalabi/ATTACK-Tools remains a solid reference implementation of what ATT&CK-as-data looks like when done relationally.
nshalabi/ATTACK-Tools.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.