u/Tax-Least

Built this around a question I kept coming back to when looking at BloodHound graphs:

The shortest path to an objective is easy to calculate, but is it actually the quietest path?

NoiseHound takes BloodHound CE data and scores attack paths against their expected detection surface rather than treating hop count as the primary optimization target.

Each supported BloodHound edge is mapped against things like Windows Security events, Sysmon, EDR/ITDR heuristics, MITRE ATT&CK techniques, audit dependencies, and an estimated noise score.

The important part is that the scores don't have to remain static.

NoiseHound supports environment profiles so things like 4662 auditing, Sysmon, PowerShell logging, MDI, or manually calibrated edge scores can change the ranking for the environment you're actually testing.

There is also a calibration harness for recording what actually fired in a detection lab and producing an environment profile from those results. The repo currently includes measured audit, Defender for Endpoint, and Elastic SIEM profiles.

Other pieces currently implemented:

• BloodHound ZIP/JSON ingestion
• live BloodHound CE / Neo4j ingestion
• k-quietest-path ranking
• detection-probability ranking
• Pareto frontier over noise/hops / P(detection)
• AD CS ESC1–8 synthesis
• Sigma rule coverage analysis
• environment-aware scoring
• text / JSON / standalone HTML reports
• defensive detection-gap mode

The defensive mode flips the same model around: given the quietest path, what telemetry or detection gap makes that path quiet, and which control would increase its score the most?

One design constraint worth calling out: these aren't presented as universal “OPSEC scores.” Detection depends heavily on audit policy, EDR, SIEM content, tooling, SOC correlation, and the environment itself. Static scores are the baseline; environment and measured calibration are intended to replace them where better evidence exists.

NoiseHound doesn't execute anything against the target—it operates on BloodHound data that has already been collected.

GitHub:
https://github.com/warpedatom/noisehound

I'm particularly interested in feedback on the edge-to-telemetry mappings and scoring model from people doing AD red teaming, detection engineering, or BloodHound research.

Built this to answer a specific detection-engineering question: when Defender pushes a definition update, does the detection boundary on your known-bad corpus move, disappear, or newly appear on something previously clean?

`Compare-OffsetThreatResult` diffs two scan results for the same file and classifies the change — NewlyDetected, NoLongerDetected, BoundaryEarlier, BoundaryLater, BoundaryUnchanged, BothClean — along with the byte delta. Running that across a corpus with `Invoke-OffsetThreatScanBatch` gives you a detection-shift matrix you can track over time across definition versions.

Boundary results report DetectionPrefixLength (prefix N-1 was clean, prefix N triggered), a confidence rating, and a ProbeLog showing how stable that boundary held across repeated probes. The tool is explicit that this identifies the earliest triggering prefix — not necessarily the complete signature, since AV decisions can depend on tokenization, surrounding context, and provider state. For files with multiple independently-detectable regions, `Invoke-OffsetThreatScanRegion` segments the file and scans each piece through AMSI entirely in memory — nothing written to disk, no real-time protection interference — bisecting each hit to an absolute file offset. Useful for understanding how much of a file's detectable content would survive targeted evasion of just the first boundary.

Scan results export to Markdown/HTML with a full per-invocation ProbeLog audit trail, intended to be attachment-ready for engagement writeups.

Composes with YARA rules (hits return offsets you pipe into context inspection), PE/imphash parsing, per-window Shannon entropy for spotting packed regions before running boundary analysis, and string extraction with byte offsets.

AMSI/Defender providers are Windows-only. Everything else is cross-platform.

GitHub: https://github.com/warpedatom/OffsetInspect

PowerShell Gallery: Install-Module OffsetInspect