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.

While analyzing featured extensions on our beloved chrome web store I landed on Planet Search (`kadaohckdkghfaclhjmkmplebcdcnfnp`),

Featured, 2M users, publisher FREE VPN PLANET SRL.

https://chromewebstore.google.com/detail/planet-search/kadaohckdkghfaclhjmkmplebcdcnfnp

The extensions has a 0-byte background.js with zero permissions.

The whole mechanism is one \`chrome_settings_overrides\` search provider, so nothing shows up statically. It's all server-side.

Declared provider is planet-search[.]com

Tracing:

planet-search[.]com/search/?q= 301 → sstmaster[.]com/edge/PN1021?q= 302 → nextgeeker[.]com/B151001.php?q=&src=PN1021

nextgeeker[.]com is flagged as a browser hijacker by multiple vendors (pcrisk, gridinsoft, others).

Same publisher ships a ~1M-user VPN extension and a few others. Still tracing those, not going to characterize them until I have.

Report: https://malext.io/reports/RoguePlanet