Self-hosted platform reference

AdversaryGraph Full-Version Guide — 31 Modules and Use Cases

Every governed workspace, explained: what each module does, what data and permissions it needs, how to operate it, what it produces, where the output goes next, and how to test that the workflow really succeeded.

Browse all modules Deploy and get started Open Threat Matrix Light View source

Read the status before the features

31governed workspaces documented
6operational module groups
v6.5.0current merged, CI-validated source release
v6.0.0latest published immutable GitHub tag

Threat Matrix Light is a public browser workspace. Private analysis, persistent records, feed synchronization, provider calls, malware workflows, active assessment, Attack Simulation, SIEM forwarding, and administration require the self-hosted platform.

How to use this guide

Start with the artefact you actually have—not with the module that looks most powerful. A report belongs in Reports / Research and AI Analysis; an observable starts in IOC Library or IOC Investigation; a known asset starts in Asset Surface or Threat Radar; a detection question starts in Threat Hunting and Query Library; rule efficacy belongs in Attack Simulation.

v6.5 source release Publication pending Self-hosted only
I have a report
Store → extract → review → map I have an IOC
Normalize → enrich → pivot → report I have an asset inventory
Normalize → assess → validate → remediate I have a sample
Hash → static triage → isolated runtime → hunt I have a hypothesis
Scope → query → external execution → findings I have a detection rule
Simulate → collect → forward → verify

Release boundary: v6.5.0 is merged and CI-validated on main, and the 31 workspaces below describe that source release. v6.0.0 remains the latest published immutable GitHub release until the protected tag workflow publishes v6.5.0.

Workspace · 1 module

Start and route the work

Use the workspace layer to verify readiness and choose the correct analyst workflow.

Intelligence · 8 modules

Collect, normalize, and prioritize intelligence

These workspaces preserve source context and turn raw intelligence into reviewable entities and priorities.

Threat Radar

v6.5 source

Connects CVE, exploit, supplier, package, breach, telemetry, and research signals to monitored companies, products, components, dependencies, and assets.

Use when
Prioritizing product-security or business-relevant signals.
Needs
A sanitized signal, company space, inventory context, source/TLP, and run_analysis.
Produces
Scored signals, cases, watchlists, asset records, and PSIRT/hunt/IR/detection handoffs.

Workflow

  1. Create or import a sanitized signal.
  2. Map it to product, component, version, dependency, asset, and owner.
  3. Review exposure, exploitability, confidence, blast radius, and score explanation.
  4. Create the correct operational handoff and track the decision.
Use case: KEV-listed VPN vulnerability

Match the CVE to the deployed product/version and internet exposure. If the version is unaffected, preserve that evidence and reduce priority; otherwise open remediation and hunt actions.

Accept when: priority is supported by version and exposure evidence, not CVSS alone.

Boundary: scoring does not prove vulnerability, exploitation, targeting, or compromise.

Current-development guideRoadmap

Reports / Research

v6.5 source

Durable storage for source reports, analysis sessions, handling markings, extracted entities, citations, and analyst-reviewed outcomes.

Use when
The starting evidence is report text, PDF, DOCX, advisory, or analyst research.
Needs
Source metadata, TLP, canonical URL or evidence reference, and file-upload authority where applicable.
Produces
Reviewed research sessions, evidence excerpts, entities, mappings, and downstream links.

Workflow

  1. Record title, publisher, date, source, and TLP.
  2. Store or upload the source in an appropriate environment.
  3. Run parsing and optional permitted AI extraction.
  4. Review every IOC, actor, technique, and claim.
  5. Save the session and hand it to Navigator, Threat Hunting, or Evidence Graph.
Use case: vendor report mentioning PowerShell

Reject T1059.001 if PowerShell appears only in defensive guidance rather than adversary behavior.

Accept when: every retained mapping has an exact supporting excerpt and human decision.

Boundary: report claims do not automatically apply to the local environment.

Report guideCompare reports

ATT&CK Group Library

v6.5 source

Joins ATT&CK group identities, aliases, campaigns, techniques, reports, source-backed IOCs, and reviewed CVE relationships.

Use when
Researching an actor or loading a source profile into Navigator/Compare.
Needs
Current ATT&CK data and optional local report/IOC sources.
Produces
Actor profile, alias set, technique layer, evidence links, and comparison input.

Workflow

  1. Search by name or alias.
  2. Confirm the ATT&CK group ID and source identity.
  3. Review techniques, campaigns, reports, IOCs, and CVEs.
  4. Load reviewed TTPs into Navigator or Compare.
Use case: MuddyWater alias review

Resolve the alias to the correct source identifier, load its TTPs, and separate common behaviors from distinctive overlap.

Accept when: identity and relationships are traceable to cited sources.

Boundary: actor/TTP/IOC overlap is an investigation lead—not attribution proof.

Group Library guideActor use case

Sector Intelligence

v6.5 source

Ranks actors and behaviors against sector, geography, technology, campaign recency, and business context.

Use when
Creating an industry-specific intelligence and detection priority list.
Needs
A defined sector/region/technology profile and current actor/campaign sources.
Produces
Ranked actors, candidate techniques, source routes, and reusable sector context.

Workflow

  1. Select sector, region, technologies, and time window.
  2. Review factors behind each relevance score.
  3. Open material sources and actor records.
  4. Move only supported TTPs into Navigator or Compare.
Use case: Israel-based technology company

Prioritize sources relevant to cloud identity, Linux production, and public APIs; retain only actor/TTP candidates supported by current reporting.

Accept when: the review queue has citations, assumptions, and a stated time window.

Boundary: sector or regional relevance does not prove targeting.

Sector brief use caseDetection roadmap

Knowledge Library

v6.5 source · RAG enabled

Searches local reports, strategy, references, entities, and reusable analyst material; current development adds governed cross-module RAG retrieval.

Use when
Finding authoritative local context or cited evidence across stored material.
Needs
Indexed content; RAG requires corpus reconciliation and permitted provider policy.
Produces
Source-backed references, citations, retrieval candidates, and advisory answers/proposals.

Workflow

  1. Search by ID, title, actor, product, technique, or keyword.
  2. Verify the canonical source, date, and lifecycle.
  3. Open every material excerpt before citing it.
  4. For RAG, review TLP, legal-sensitive labels, retrieval mode, and proposal expiry.
Use case: find evidence for T1059.001

Find source material describing PowerShell telemetry, cite the exact excerpt in a hunt, and reject stale guidance.

Accept when: every claim links to the authoritative local record.

Boundary: retrieval rank is not evidence confidence; RAG and MCP are not autonomous response mechanisms.

RAG/MCP guide1200km research

IOC Library

v6.5 source

Normalized observable storage for domains, IPs, URLs, hashes, source observations, freshness, confidence, tags, and relationships.

Use when
Searching, deduplicating, reviewing, or exporting source-backed indicators.
Needs
Feed sync, report extraction, manual import, or pipeline intake with provenance.
Produces
Normalized IOC records, source history, links, tags, and pivot actions.

Workflow

  1. Search exact value, type, source, family, TTP, tag, or freshness.
  2. Compare source observations and timestamps.
  3. Review normalization and deduplication.
  4. Pivot into IOC Investigation before operational action.
Use case: duplicate domain from two feeds

Import uppercase/lowercase representations and confirm one normalized indicator with separate observations.

Accept when: provenance is preserved without redundant operational records.

Boundary: indicator presence does not prove maliciousness, active use, targeting, or compromise.

IOC search guideCustom feed guide
AdversaryGraph IOC Library with searchable source-backed indicators
IOC Library with local source and enrichment context.

CVE Library

v6.5 source

Combines CVE records with CVSS, EPSS where present, CISA KEV, CWE, affected products, and reviewed actor/IOC/TTP links.

Use when
Prioritizing vulnerability intelligence before asset-specific validation.
Needs
Current CVE sources; asset/product/version evidence for local decisions.
Produces
CVE records, scoring context, KEV/weakness labels, and review candidates.

Workflow

  1. Search by CVE, vendor, product, severity, KEV, or CWE.
  2. Review source dates and scoring vector.
  3. Separate affected-product claims from confirmed local exposure.
  4. Send relevant records to Threat Radar or Asset Surface.
Use case: critical CVE versus exposed high CVE

Prioritize the high-severity CVE confirmed on an internet-facing asset over a critical CVE affecting an unused component.

Accept when: priority includes version, exposure, owner, and source evidence.

Boundary: CVSS/KEV do not prove patch state, reachability, exploitation, or compromise.

CVE guide

RetroHunt Signals

v6.5 source · local search

Searches historical local indicators, reports, techniques, tags, actors, and evidence for recurrence.

Use when
A new lead may have appeared in earlier local intelligence.
Needs
Collected historical records, normalized tags, source timestamps, and provenance.
Produces
Historical matches, timelines, source counts, and investigation candidates.

Workflow

  1. Start with an IOC, actor, technique, family, product, or tag.
  2. Constrain the time range and collection.
  3. Review each match reason and source.
  4. Send credible recurrence into investigation or a hunt.
Use case: hostname resurfaces after six months

Find the old report, check current DNS and shared-hosting context, then create a bounded DNS/proxy hypothesis.

Accept when: recurrence is time-bounded and source-backed.

Boundary: historical overlap is not proof of the same operator, campaign, or intent.

Evaluation guide

Analyze & Investigate · 9 modules

Turn evidence into reviewed analytical context

These modules extract, map, compare, enrich, assess, and preserve evidence without converting analytical leads into automatic verdicts.

AI Analysis

v6.5 source

Transforms stored report text or authorized uploads into reviewable ATT&CK/ATLAS, IOC, actor, summary, assumption, and gap candidates.

Use when
Structuring long report or log evidence for analyst review.
Needs
Source text, correct TLP, provider readiness, and permitted local/remote processing.
Produces
Candidate mappings, citations, observables, summary, confidence, and saved session.

Workflow

  1. Preserve source metadata and handling.
  2. Select a provider allowed by policy.
  3. Run analysis against the stored source.
  4. Verify every candidate against its excerpt.
  5. Accept, reject, or edit before handoff.
Use case: plausible TTP with wrong citation

Reject a valid-looking technique when the cited paragraph does not support the behavior.

Accept when: each retained mapping has exact evidence and a human decision.

Boundary: AI output is a lead, not report evidence or proof of local activity.

AI Analysis guideDomain guidance
AdversaryGraph AI Analysis workspace with analyst-review fields
AI-assisted extraction remains subject to analyst review.

Compare

v6.5 source

Measures overlap and gaps between the current TTP set and groups, campaigns, reports, or another actor.

Use when
Testing behavioral similarity and identifying distinctive or missing techniques.
Needs
A selected TTP set and current source profiles.
Produces
Similarity ranking, shared/exclusive TTPs, tactic distribution, and gap candidates.

Workflow

  1. Confirm domain and selected TTPs.
  2. Choose Groups, Campaigns, Reports, or Group vs Group.
  3. Run deterministic overlap analysis.
  4. Inspect shared, exclusive, missing, and source evidence.
Use case: two actors share common techniques

Add timing, tooling, source, and infrastructure evidence before prioritizing either actor.

Accept when: the output is documented as a lead rather than attribution.

Boundary: similarity is not actor probability or attribution confidence.

Compare guideGroup comparison

IOC Investigation

v6.5 source

Performs a bounded pivot around one domain, IP, URL, hash, or other supported observable.

Use when
Triage requires current enrichment, relationship context, and a preserved pivot trail.
Needs
The original alert/report reference and configured permitted providers.
Produces
Provider results, relationship graph, risk cues, TTP/actor leads, and saved investigation.

Workflow

  1. Confirm value and type.
  2. Select permitted pivot depth/providers.
  3. Run enrichment and preserve source-specific errors.
  4. Review relationships, dates, confidence, and evidence.
  5. Save only defensible findings.
Use case: domain on a shared CDN

Avoid expanding every co-hosted domain; review the feed observation and current resolution separately.

Accept when: graph scope is bounded and each relationship has provenance.

Boundary: provider errors or no results are evidence gaps—not benign verdicts.

IOC investigation guideActor IOC enrichment
IOC Investigation summary with source-specific enrichment
Source-aware IOC enrichment and review.

Malware Analysis

v6.5 source

Manages an isolated malware case across hashes, static triage, strings, imports, unpacking, decompilation, debug context, optional runtime evidence, and reviewed IOC/TTP leads.

Use when
Analyzing an authorized sample or hash-only malware lead.
Needs
MalwareGraph service; upload authority; isolated disposable infrastructure for runtime work.
Produces
Case, hashes, static/runtime findings, IOC/TTP candidates, pseudocode context, and summaries.

Workflow

  1. Record acquisition, TLP, and cryptographic hash.
  2. Run reputation/hash checks before handling the sample.
  3. Review metadata, strings, imports, and packing indicators.
  4. Use Unpacker and Debug IDE for deeper static analysis.
  5. Use Dynamic Analysis only in the isolated profile and separate observation from inference.
Use case: PowerShell string never executes

Static strings suggest PowerShell and a domain, but runtime evidence shows neither path executes. Mark them as unexecuted leads.

Accept when: observed behavior and potential code paths are clearly separated.

Boundary: static triage is not a sandbox verdict; never run samples on an analyst workstation.

Malware Analysis guideSecurity boundary
AdversaryGraph Malware Analysis dashboard
MalwareGraph-backed case workflow. Dynamic execution remains separately gated.

VirusTotal Lookup

v6.5 source

Runs an on-demand lookup for a supported hash, domain, IP, or URL and presents the provider response in local context.

Use when
A single observable needs provider-specific reputation and relationship context.
Needs
API key, connectivity, provider terms, rate capacity, and permission to send the value.
Produces
Timestamped provider record, detection summary, metadata, and leads.

Workflow

  1. Confirm type and handling sensitivity.
  2. Authorize external submission.
  3. Run lookup and preserve errors/rate limits.
  4. Review detections and relationships.
  5. Link material results to investigation evidence.
Use case: one engine flags a new domain

Record the minority result and add DNS/proxy checks instead of declaring malware.

Accept when: the conclusion reflects provider uncertainty and lookup time.

Boundary: provider consensus is not proof; do not submit private artefacts without approval.

Asset Surface

v6.5 source · authorized assessment

Normalizes CMDB, cloud, scanner, hostname/IP, and manual inventory into owned assets, exposure priorities, passive observations, scan results, and candidate ATT&CK review paths.

Use when
The starting point is organizational inventory rather than a report or IOC.
Needs
Inventory, owner/authorization, business context, and approved passive/active assessment configuration.
Produces
Saved asset records, detail pages, exposure, assessments, CVE/TTP/IOC leads, and layer export.

Workflow

  1. Import the inventory into the correct company space.
  2. Correct owner, criticality, technology, exposure, host, IP, URL, and port fields.
  3. Review passive observations and newly discovered related surfaces.
  4. Run active scanning only against explicitly authorized targets.
  5. Merge validated discoveries without duplicating normalized assets.
Use case: public website resolves to a new IP

Verify ownership, add the IP with provenance, schedule a bounded authorized assessment, and correlate only evidence-backed CVEs.

Accept when: scope authorization, asset identity, source evidence, and scan result are preserved.

Boundary: inventory inference and passive OSINT do not prove vulnerability; active scans may disrupt systems.

CapabilitiesCVE context

EMB3D

v6.5 source · self-hosted

Maps embedded-device characteristics, interfaces, update paths, deployment assumptions, and mitigations to MITRE EMB3D threats.

Use when
Threat-modelling an embedded product, firmware, interface, or deployment.
Needs
Device architecture and operational context plus current EMB3D reference data.
Produces
Applicable threat entries, mitigations, evidence notes, gaps, and export.

Workflow

  1. Describe purpose, deployment, interfaces, updates, privilege, and protections.
  2. Match characteristics to EMB3D threats.
  3. Review applicability and mitigation evidence.
  4. Record unknowns and environment-specific assumptions.
Use case: edge gateway with debug port

Model Ethernet, remote updates, signed boot, and a local debug interface; distinguish laboratory and production physical controls.

Accept when: applicability is environment-specific and evidence-backed.

Boundary: threat modelling is not firmware analysis, hardware penetration testing, or certification.

Capabilities

Evidence Graph

v6.5 source

Preserves the reasoning path from Evidence → Claim → Behavior → ATT&CK → Telemetry → Detection → Validation → SIEM Result → Analyst Decision.

Use when
An investigation or detection decision must remain reviewable and explainable.
Needs
Canonical evidence references and analysts who can approve/reject draft relationships.
Produces
Typed nodes/edges, paths, gaps, review states, and evidence exports.

Workflow

  1. Add evidence before claims.
  2. Connect claims to reviewed behavior and TTPs.
  3. Add telemetry, detection candidate, rule, and validation scenario.
  4. Record results and preserve failed paths.
Use case: false-positive validation pass

A rule matched a generic process event rather than the encoded-command field. Preserve the failed edge, correct telemetry requirements, and retest.

Accept when: the final decision is traceable through both failed and successful evidence.

Boundary: graph connectivity does not make a claim true; AI-created nodes remain drafts.

Evidence flowValidation examples
AdversaryGraph evidence relationship graph
Relationship visualization supports review; the underlying evidence remains authoritative.

Hunt & Validate · 4 modules

Build hypotheses, detections, and validation evidence

Current-development hunting workspaces record analyst-controlled work; stable Attack Simulation validates rules against approved lab telemetry.

Threat Hunting

v6.5 source

Manages falsifiable hypotheses, scope, ATT&CK context, telemetry requirements, versioned query plans, findings, outcomes, and defensive handoffs.

Use when
A report, IOC, signal, asset, or detection gap should become a bounded hunt.
Needs
Approved telemetry platform access; optional governed AI provider; run_analysis.
Produces
Versioned hunt, query checksums, findings, disposition, limitations, and export.

Workflow

  1. Define population, time range, behavior, and falsification condition.
  2. Set TTPs, telemetry, fields, expected evidence, assumptions, and false positives.
  3. Review query language and local field mapping.
  4. Run the query in the approved SIEM/EDR/data lake.
  5. Attach evidence, record findings, disposition, gaps, and handoffs.
Use case: suspicious encoded PowerShell

Map T1059.001/T1027, define process/script-block fields, generate KQL or SPL, and validate it in the destination platform.

Accept when: query version, external execution reference, searched scope, findings, and gaps are recorded.

Boundary: AdversaryGraph does not claim a stored query was executed; no matches do not prove a clean environment.

Current-development statusDetection workflow

Query Library

v6.5 source

Searchable reviewed/community detection content plus deterministic IOC-to-query drafting across Sigma, YARA-L, YARA, KQL, SPL, EQL, Lucene, SQL, osquery, and generic formats.

Use when
A hypothesis needs a source-attributed query starting point.
Needs
Indexed rule sources with URL, license, parser state, platform, tags, and ATT&CK metadata.
Produces
Reviewed/adapted query draft and direct Threat Hunting handoff.

Workflow

  1. Search by TTP, language, platform, tag, or source.
  2. Verify provenance, license, parser status, and fields.
  3. Adapt schema, index, time window, and exclusions.
  4. Validate syntax and positive/benign behavior in the destination.
Use case: Sigma rule assumes missing Sysmon fields

Translate to available EDR fields, preserve the source and changes, then validate positive and negative cases.

Accept when: local field mapping and behavior—not parser success—are proven.

Boundary: community rules may be stale or incompatible; generated content is not a validated detection.

Development statusRule sync use case

Attack Simulation

v6.5 source

Validates telemetry and detection behavior using approved lab targets, controlled scenarios, source-shaped events, and optional SIEM forwarding.

Use when
A rule, parser, or correlation path needs reproducible test evidence.
Needs
Authorized fixtures, healthy lab services, simulation permission, and forwarding permission for SIEM delivery.
Produces
Fixture logs, labelled synthetic events, attack-chain graph, delivery history, and validation result.

Workflow

  1. Select the ATT&CK technique/scenario.
  2. Confirm an approved fixture—not an arbitrary target.
  3. Configure bounded parameters and test destination.
  4. Run and inspect target-side or labelled source-shaped events.
  5. Verify delivery, parser, rule match, correlation, and benign control.
Use case: SIEM delivery succeeds but rule fails

Confirm event receipt, identify a parser field mismatch, revise the rule, rerun, and preserve both attempts.

Accept when: delivery, parsed fields, positive match, benign control, and reviewer are recorded.

Boundary: not a general exploit framework; unsupported behavior must be labelled as a telemetry gap.

Attack Simulation guideValidation evidence
AdversaryGraph Attack Simulation technique matrix
Technique-first simulation selection for controlled detection validation.

Investigation

v6.5 source

Assembles evidence, TTPs, IOCs, actor context, findings, gaps, decisions, and recommendations into an analyst handoff.

Use when
Reviewed upstream work must become a defensible report or escalation.
Needs
Scope, owner, TLP, evidence references, and export permission where required.
Produces
Analyst report, selected layer, evidence links, gaps, actions, and exports.

Workflow

  1. Record question, scope, time range, owner, and TLP.
  2. Attach canonical evidence, accepted TTPs, pivots, and findings.
  3. Separate facts, judgments, and unverified leads.
  4. Record outcome, limitations, actions, and reviewer.
  5. Export the required handoff format.
Use case: scanning IP incorrectly labelled malicious

Revise the claim to “observed scanning source,” preserve the alert, and record confidence and missing intent evidence.

Accept when: wording precisely matches evidence.

Boundary: polished export formatting does not validate the underlying analysis.

Report generationPDF export use case

Operations · 3 modules

Manage durable work and local measurements

Operations

v6.5 source

Manages durable investigations, intake, detection backlog, tracked actors, ownership, priority, state, and analyst workflow objects.

Use when
Reviewed intelligence must become assigned operational work.
Needs
Consistent object types, owners, tags, status, due date, and source links.
Produces
Investigation records, intake items, tracked actors, detection work, and tasks.

Workflow

  1. Create the correct object type.
  2. Assign owner, priority, state, and due date.
  3. Link evidence and upstream/downstream records.
  4. Close with outcome and retained history.
Use case: three reports request the same detection

Link all sources to one backlog item and maintain one validation plan.

Accept when: work is deduplicated without deleting independent evidence.

Boundary: local workflow management is not automatically an enterprise SOAR/ticketing replacement.

Operations guide

Pipeline

v6.5 source

Registers sources, validates and normalizes incoming observables/detection content, performs idempotent upserts, and builds structured starting points.

Use when
Integrating STIX/TAXII, MISP, files, sandbox behavior, Sigma, YARA, or another supported source.
Needs
Source type, license, TLP, URL/file, schedule, and credentials where applicable.
Produces
Source records, import jobs, normalized data, parser errors, audit, and rule skeletons.

Workflow

  1. Register source and metadata.
  2. Test connection or parse a fixture.
  3. Validate and normalize before import.
  4. Review duplicates, upserts, and rejected rows.
  5. Promote only supported output.
Use case: import the same STIX bundle twice

Verify that the second run reuses/updates normalized objects instead of duplicating them.

Accept when: intake is deterministic, idempotent, and auditable.

Boundary: successful parsing does not prove source accuracy, license compatibility, or rule quality.

Pipeline guideTAXII/STIX use case

Statistics

v6.5 source · self-hosted

Describes local actors, reports, sectors, TTPs, CVEs, IOCs, sources, tags, confidence, and telemetry coverage.

Use when
Measuring local dataset coverage, distribution, and quality.
Needs
Normalized records and a stated filter/denominator.
Produces
Local totals, distributions, ranked entities/techniques, and pivot links.

Workflow

  1. Select datasets and filters.
  2. Set row limits.
  3. Review charts and ranked tables.
  4. Pivot outliers into authoritative modules.
  5. Record filter and timestamp in reports.
Use case: T1059 dominates one chart

Filter by source and unique report to discover that one bulk import caused the apparent dominance.

Accept when: the metric includes scope and denominator.

Boundary: frequency is not risk, prevalence, attribution, or detection coverage.

Validation guide

Platform · 3 modules

Operate sources, health, identity, and access

Feeds Management

v6.5 source

Configures, synchronizes, and diagnoses ATT&CK, ATLAS, IOC, CVE, malware, report, OpenCTI, STIX/TAXII, MISP, and detection sources.

Use when
Libraries need fresh data or a source is degraded.
Needs
manage_feeds, URLs, credentials, licenses, schedules, and connectivity.
Produces
Sync jobs, counts, timestamps, errors, and normalized downstream records.

Workflow

  1. Separate enabled/configured from live readiness.
  2. Test or run one source.
  3. Inspect last success, count, errors, and degraded state.
  4. Verify one imported record in its destination library.
  5. Reconcile RAG when required.
Use case: OTX temporarily unavailable

Preserve existing indicators and last-success time, mark the source degraded, and avoid claiming a current sync.

Accept when: data freshness and dependency state are transparent.

Boundary: “configured” does not mean reachable, authorized, current, or complete.

Sync APIThreatFox use case

Observability

v6.5 source

Exposes health, readiness, redacted logs, request traces, route metrics, audit signals, and Prometheus-compatible metrics.

Use when
Diagnosing failed/slow routes, dependency readiness, or deployment regressions.
Needs
view_audit, writable logs, and configured metric collection where used.
Produces
Health state, traces, route metrics, redacted logs, and audit evidence.

Workflow

  1. Start with API/dependency health.
  2. Filter failed/slow routes and capture correlation context.
  3. Review redacted logs and traces.
  4. Apply the smallest remediation.
  5. Rerun the exact functional action.
Use case: browser shows network error but API is healthy

No request reaches the route; correct the frontend proxy and verify an end-to-end trace.

Accept when: the user action succeeds—not just when containers are green.

Boundary: metrics and redacted logs are diagnostic evidence, not complete forensics.

Observability guide

Administration

v6.5 source · SOC group RBAC

Manages named users, SOC groups, module/action grants, passwords, MFA state, sessions, authentication configuration, and audit history.

Use when
Onboarding users, applying least privilege, revoking sessions, or reviewing authentication events.
Needs
manage_users, manage_auth, or view_audit and a recovery administrator path.
Produces
Persistent identities/groups, effective grants, sessions, resets, revocations, and audit events.

Workflow

  1. Create a named user with a policy-compliant password.
  2. Assign the smallest suitable SOC group.
  3. Confirm effective modules/actions.
  4. Test access and denials in a private session.
  5. Review sessions/audit and maintain two recovery admins.
Use case: SOC Tier 1 onboarding

Allow IOC Investigation and Reports; verify Administration and Attack Simulation are denied in both UI and direct API calls.

Accept when: intended access works, prohibited access fails, and audit events exist.

Boundary: menu hiding is not security; backend enforcement is. Native project auth is not multi-tenant isolation.

Authentication guideSecurity guide

Learn & Support · 3 modules

Train, orient, and recover safely

DFIR Examples

v6.5 source · synthetic training

Provides public or synthetic inputs, expected outputs, and reproducible workflows for demonstrations and regression checks.

Use when
Training analysts or evaluating workflows without private evidence.
Needs
A bundled example and its expected evidence/limitations.
Produces
Reproducible sample reports, layers, mappings, and regression evidence.

Workflow

  1. Choose an example matching the target module.
  2. Read expected evidence and output.
  3. Run the documented steps.
  4. Compare actual/expected and explain deviations.
Use case: model upgrade regression

Confidence changes but supported IDs remain stable; classify model variability separately from deterministic export correctness.

Accept when: criteria are explicit and results are reproducible.

Boundary: demo output is not customer evidence or production validation.

Case studiesUse-case library

Help / Local Guide

v6.5 source · self-hosted

In-application orientation for local commands, module selection, outputs, tips, and direct workspace links.

Use when
Onboarding or choosing the correct module.
Needs
A loaded frontend; no external provider is required.
Produces
Operator commands, workflow orientation, and module routes.

Workflow

  1. Confirm local start/update and service health.
  2. Find the module guide.
  3. Review when-to-use, workflow, outputs, and tips.
  4. Open the module and use this page for the detailed case.
Use case: report mistakenly opened as IOC investigation

Help routes the analyst to Reports / Research and AI Analysis, preserving a coherent evidence model.

Accept when: the work starts in the correct module.

Boundary: concise help does not replace endpoint, security, and production documentation.

IntroductionPlatform guide

Troubleshooting

v6.5 source

Bounded diagnostics for Docker, API, database, Redis, storage, feeds, authentication, providers, and module-specific failures.

Use when
An action, source, provider, or dependency is degraded or failing.
Needs
Exact symptom, timestamp, route, status, self-test result, and operator shell access where required.
Produces
Diagnostic evidence, recovery steps, and a verified or escalated state.

Workflow

  1. Preserve error/correlation context.
  2. Check container/API health before changing data.
  3. Run the smallest relevant diagnostic.
  4. Apply one reversible change.
  5. Rerun the failed action and Self-test.
Use case: /system/selftest network error

Check API health, frontend proxy target, container state, and browser request path before rebuilding or deleting anything.

Accept when: the exact route succeeds and the root cause is documented.

Boundary: never delete persistent volumes as a first response; preserve backups and change control.

Troubleshooting use caseObservability guide
AdversaryGraph Troubleshooting module
Operator diagnostics should lead to a functional retest, not only a green health indicator.

Cross-module casebook

Six end-to-end use cases

Each journey preserves a source, a reviewed decision, a handoff, and acceptance evidence.

1. Report → detection candidate

  1. Store report and TLP.
  2. Extract/review in AI Analysis.
  3. Inspect accepted TTPs in Navigator.
  4. Create Evidence Graph chain.
  5. Adapt Query Library content.
  6. Run externally and record hunt findings.

Accept: exact excerpts, mapping decisions, query revision, execution reference, findings, and reviewer.

2. IOC alert → bounded escalation

  1. Review freshness in IOC Library.
  2. Run permitted IOC pivots.
  3. Search RetroHunt recurrence.
  4. Review actor context without attribution.
  5. Run a scoped DNS/proxy hunt.
  6. Report explicit disposition.

Accept: original alert, provider times, relationship reasons, scope, evidence, and outcome.

3. Asset inventory → assessment

  1. Import authorized inventory.
  2. Correct ownership/criticality/exposure.
  3. Review passive discoveries.
  4. Check CVE applicability.
  5. Run bounded authorized assessment.
  6. Track remediation.

Accept: authorization, normalized identity, source evidence, scan parameters/result, affected-version proof, and owner.

4. Sample → behavior-led hunt

  1. Create malware case and hash.
  2. Run static triage.
  3. Treat strings/code as leads.
  4. Collect isolated runtime evidence.
  5. Map observed behavior.
  6. Build and execute a hunt externally.

Accept: acquisition, hashes, isolation boundary, observed events, rejected leads, query scope, and findings.

5. Rule → simulation evidence

  1. Select TTP in Navigator.
  2. Document telemetry in Evidence Graph.
  3. Adapt a reviewed rule.
  4. Run approved lab scenario.
  5. Verify SIEM delivery/parser/rule.
  6. Record positive and benign controls.

Accept: rule revision, fixture authorization, event sample, delivery receipt, parsed fields, match/control result, and reviewer.

6. Platform failure → recovery

  1. Preserve route/error.
  2. Check Discover/Self-test.
  3. Inspect Observability traces.
  4. Apply one troubleshooting step.
  5. Check feeds/permissions only if indicated.
  6. Rerun the same action.

Accept: before/after result, correlation evidence, one documented change, and successful functional retest.

Questions and boundaries

Is Threat Matrix Light the complete AdversaryGraph platform?

No. It is a public browser-only ATT&CK workspace. The full workflows on this page require self-hosted services, local persistence, permissions, and configured integrations.

Which version is current?

v6.5.0 is the current merged, CI-validated source release described by this guide. v6.0.0 remains the latest published immutable GitHub release until the protected v6.5.0 tag workflow completes.

Does AdversaryGraph run hunt queries in my SIEM?

No. It stores and reviews query plans. The analyst executes reviewed queries in an approved telemetry platform and attaches evidence from that execution.

Can AI or RAG output be accepted automatically?

No. AI mappings, RAG answers, Navigator proposals, query drafts, summaries, and relationships require source review and a human decision. Restricted data may be local-only under operator policy.

Can Asset Surface scan any IP or website?

No. Active assessment must be restricted to owned or explicitly authorized inventory targets, with scope, rate, and audit controls. Passive data still requires ownership and applicability validation.

Does a high actor overlap score prove attribution?

No. Similarity is a hypothesis-generation signal. Attribution requires corroborated behavioral, temporal, infrastructure, source, and contextual evidence.

Get started with the full deployment Open all documentation Browse more use cases Return to product page