TFTHREATFADE
ProductDetectionHow it worksIntegrationsResearchSecurityDocsPlaygroundPricingEnterprise
GitHub
ProductDetectionHow it worksIntegrationsResearchSecurityDocsPlaygroundPricingEnterprise
Evidence-first detectionv0.9.0-dev

Detect when attackers go quiet.

ThreatFade is an evidence-first detection and investigation platform for adversarial activity that becomes intentionally less observable.

View on GitHubUnderstand detection
Apache 2.0Open sourcePython / FastAPIEvidence + ATT&CK
Behavioral signal lab

Illustrative telemetry patterns grounded in supported ThreatFade scenarios. Not a live detection result.

Research surface
baseline / observable activitybehavioral change
Signal interpretation

A communication pattern becomes less observable over time.

Observed change
signal reduction
Scenario family
C2
Next step
Inspect evidence
Detection → evidence → disposition
The problem

Reduced observability can itself be worth investigating.

ThreatFade is built around a specific detection thesis: adversarial activity can become less observable on purpose. The system models changes in network or signal behavior instead of treating a reduction in activity as automatically benign.

That produces an investigation path rather than a black-box verdict: prioritize the deviation, inspect structured evidence, pivot through context, disposition the case and hand off to existing security operations.

Detection pipeline

From observable traffic to operational evidence.

01

Traffic

PCAP, live signals and supported telemetry sources enter the detection boundary.

02

Signal extraction

ThreatFade extracts observable signal features, including rolling entropy and statistical behavior.

03

Behavioral analysis

Detection rules evaluate changes such as C2 quieting, LOTL fade and GNSS signal disruption.

04

Anomaly

Deviation and optional ML anomaly analysis help prioritize behavior that warrants inspection.

05

Evidence

Structured evidence, confidence and context are preserved for analyst review.

06

ATT&CK

Detections can carry MITRE ATT&CK context before operational handoff.

07

Integration

Results can move through JSON, Sigma-compatible, STIX 2.1-compatible and SIEM/FusionOps paths.

See the architecture
Choose your path

One engine. Different reasons to evaluate it.

Run / inspect / contribute

Developers

Start with the open-source engine, understand the detection surface and contribute against real implementation.

Open GitHub
Methodology / evidence

Researchers

Follow the detection methodology, deterministic validation and research boundary without confusing project evidence with independent assurance.

Explore path
Detect / investigate / handoff

SOC teams

Evaluate evidence-backed detections, analyst workflow, ATT&CK context and operational interoperability.

Explore path
Architecture / security

Enterprise

Review identity, tenancy, audit, deployment boundaries and the evidence-versus-assurance distinction.

Explore path
Why trust it
Trust boundary

Repository evidence

Tests, benchmarks, controls and documented validation are inspectable in the source repository.

Project validation

Published validation is explicitly scoped; it is not presented as a universal accuracy guarantee.

External assurance

Certifications, independent testing, contractual SLAs and customer-scale guarantees require separate evidence.

Start with the source

Inspect it. Run it. Challenge it.

The engine repository contains the detection engine, API, analyst console, validation framework and interoperability layer.

View engine