Skip to main content

Case Studies And Validation Examples

These examples show how to validate AdversaryGraph workflows using screenshots, reproducible demo data, and explicit boundaries. They are designed for reviewers and detection engineers, not as proof of compromise or attribution.

Case Study 1: From Logs To Report​

Goal: turn firewall and EDR-style telemetry into a reviewed investigation with IOCs, TTP leads, graph pivots, actor-overlap hypotheses, and a final report.

Investigation workspace with suspicious behavior IOCs TTPs and report workflow
Investigation workspace consolidates log analysis, suspicious behavior, IOCs, TTP leads, and report context.

Validation checks:

  • IOCs are source-tagged.
  • TTPs remain analyst-review candidates until accepted.
  • Actor comparison is treated as hypothesis generation, not attribution proof.
  • Final report includes evidence and caveats.

Related workflow: Investigation: Ransomware Intrusion.

Case Study 2: Attack Simulation To SIEM​

Goal: choose a technique, run an approved validation scenario, inspect real-time telemetry, and forward selected logs to a SIEM collector.

Attack Simulation matrix with available simulation techniques
TTP-first selection through the simulation matrix.
Real-time attacked server logs in AdversaryGraph
Real-time log review before SIEM forwarding.

Validation checks:

  • Scenario states telemetry source and event structure.
  • Real lab telemetry is separated from AI-generated telemetry.
  • SIEM destination is approved by the operator.
  • Detection feasibility depends on the receiving SIEM parser and rule logic.

Related guide: Attack Simulation.

Case Study 3: CVE To APT / TTP / IOC Correlation​

Goal: review vulnerability context without turning CVE exposure into attribution.

CVE Library showing CVSS KEV metadata and relationship detail panel
CVE Library supports CVSS/KEV review and strict evidence links to related actors, techniques, and indicators.

Validation checks:

  • CVSS and KEV fields come from synced vulnerability sources.
  • CVE-to-APT/TTP/IOC links require explicit evidence.
  • Relationship details are review material, not attribution proof.
  • Missing CPE or asset context is called out as a gap.

Related guide: CVE Library.

Case Study 4: Malware Analysis Boundary​

Goal: triage a Windows sample, extract indicators, review strings and decompilation, and keep runtime claims separate from static evidence.

Malware Analysis dashboard with case controls and analysis summary
Malware Analysis case dashboard for controlled triage.
Debugger style decompilation IDE with pseudocode and recovered APIs
Decompilation/debug-style workspace for function review and validation gaps.

Validation checks:

  • Static evidence is labeled separately from runtime claims.
  • Dynamic execution is gated and requires an isolated runtime profile.
  • AI behavior summaries are review aids.
  • Hash/feed results are contextual evidence, not final verdicts.

Related guide: Malware Analysis.

Case Study 5: Operator Readiness​

Goal: prove that the platform is healthy, authenticated, observable, and reviewable before a pilot.

Admin Panel showing users roles account enablement and reset controls
Admin Panel validates users, roles, and account management.
Observability dashboard with API metrics traces and log tail
Observability dashboard validates runtime health and operational traces.

Validation checks:

  • Auth is enabled and named admin accounts exist.
  • API health endpoint returns the current version.
  • Observability routes show recent request traces and redacted log tail.
  • CI security checks are green or documented with known exceptions.

Related guide: Observability and security validation.