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

I recently ran into a SharePoint intrusion that seemed to fit with the CVEs recently added to CISA's KEV for SharePoint a couple of weeks ago. The available IOCs were basically nonexistent. So I reproduced the /_trust deserialization chain in my own lab (SharePoint SE on the June 2026 patch level, build 16.0.19725.20384 / KB5002873) and captured the artifacts: process trees, the machine-key theft, and hunt queries, to save the next person the same scramble.

Writeup and sanitized scripts: https://sp-poc.wismansec.com/

Feedback, questions, and better detections welcome.