DEV Community: ShadowStrike Labs

ShadowStrike Phantom: Open-Source EDR Platform

ShadowStrike Labs — Tue, 07 Apr 2026 17:48:56 +0000

We've been developing ShadowStrike Phantom since 2024 and plan to release it on Day 1 of 2027. Here's what we've accomplished so far:
Phantom Emulator - A fully X86-64 Special Emulation Engine for advanced obfuscated malwares

Phantom Cortex - Includes Cortex-Static , Cortex-Behavioral ,Cortex-Network , Cortex-Emulation and the Cortex-Memory. We have been trained 5 of those AI/ML models with the malware samples and synthetic malware samples.

Phantom Sensor - A custom Kernel minifilter driver

src/Shared_Modules/ - The Heart of Phantom EDR XDR Home products. It includes the fully Malware Hunting Engine and orchestrated with the 5 local AI/ML agents trained from scratch + Phantom Sensor and our Emulation Engine for advanced obfuscated malwares.

Mostly the Phantom EDR XDR Home products will use the same Engine but will add top of that specialized to the tiers of them. EDR/XDR will have a web console management dashboard for policies, threat intel dashboards etc. and Home will have a Local UI.

All the features are still in-development and not production-ready but we are working hard.

You can support our products by giving us stars on GitHub or by becoming a sponsor.

If you want to learn more about the architecture and interested at open-source Endpoint Security:

https://github.com/ShadowStrike-Labs/ShadowStrike

We security-audited 400,000+ lines of our own EDR code. Here's what we found.

ShadowStrike Labs — Sat, 04 Apr 2026 07:10:40 +0000

I'm building ShadowStrike Phantom — an open-source endpoint detection and response platform for Windows.
From-scratch. Custom kernel driver, behavioral analysis, exploit prevention, the whole stack.

This isn't a weekend project. PhantomSensor.sys alone is 380,000 lines of C. It's a WDM minifilter running at
altitude 385210 with 14 operation callbacks, syscall monitoring, memory protection, and a behavioral engine with
MITRE ATT&CK mapping.

Over the past few weeks, I've been doing line-by-line security audits of the user-mode shared modules — the engines
that actually make detection decisions. 12 modules so far. Here's an honest look at what I found in my own code.

The Numbers

- 12 modules audited: SignatureStore, ThreatIntel, ExploitPrevention, BehaviorBlocker, AccessControlManager,

Whitelist, FileProtection, RegistryProtection, SelfProtection, and more
- 400+ issues found and fixed
- 60+ critical/high severity findings

The Worst Bugs

ExploitPrevention was protecting itself, not the target. SetProcessMitigationPolicy applies to the calling process.
My code was applying DEP/ASLR/CFG enforcement to the EDR agent, not to the monitored process. For existing remote
processes, most Windows mitigation policies are immutable post-creation — you can only query them. Fixed by
switching to query + report for existing processes, and PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY at creation time
for new ones.

22 declared methods with zero implementation. The ExploitPrevention header declared 35+ public methods. 22 of them
had no implementation in the .cpp file. OnTableAccess (EAF handler), OnException (SEHOP handler), EnableIAF — all
dead. The EnableIAF method was particularly bad: it returned true (success) while doing absolutely nothing.

EAF breakpoints were using wrong width. Hardware debug breakpoints (Dr0-Dr3) for Export Address Table access
monitoring had the Dr7 LEN field set wrong — 1-byte breakpoints instead of 8-byte (x64) or 4-byte (x86). An
attacker
accessing the EAT at an offset beyond byte 0 would bypass detection completely.

Deadlock: holding mutex during thread suspension. EAF protection held the EAF mutex while iterating and suspending
threads. If a suspended thread also needed that mutex → deadlock. Fixed by collecting thread IDs under lock,
releasing the lock, then suspending.

Stats struct with std::atomic made the class non-copyable. ExploitPreventionStats had std::atomic
members.
Returning it from GetStats() triggered C2280 (deleted copy constructor). Fixed by using plain uint64_t in the
public
API and internal std::atomic counters in the PIMPL, with a Snapshot() method.

What I Learned

Writing security software means your code is under double scrutiny — it must be correct and it must resist active
attempts to break it. Every unimplemented method is a gap. Every wrong parameter is a bypass. Every deadlock is a
denial of service against your own protection.

The audits also forced proper kernel ↔ user-mode wiring. Before the audits, FilterMessageType_MemoryAlert was a
logging-only stub — the kernel would send memory anomaly alerts and the user-mode agent would log "got an alert"
and
do nothing. Now it routes through ExploitPrevention::OnKernelMemoryAlert() for actual analysis.

Current Status

- Kernel driver: complete, Coverity
 0.25 defect/KLoC, Driver Verifier passed
- User-mode: 76% complete, security audit phase
- Beta target: 2027 (moved up from 2028-2029)
- Next: on-device ML integration, product splits (Home/EDR/XDR)

Everything is AGPL-3.0. Every commit is public.

GitHub: github.com/ShadowStrike-Labs/ShadowStrike (https://github.com/ShadowStrike-Labs/ShadowStrike) Website:
shadowstrike.dev (https://shadowstrike.dev)

If you're interested in open-source endpoint security, give us a star or follow the project. We're building this in
public because security software shouldn't be a black box.

ShadowStrike Phantom EDR/XDR Platform Kernel Sensor (WDK/C)

ShadowStrike Labs — Thu, 19 Mar 2026 12:05:23 +0000

I've been building an open-source kernel-mode EDR/XDR sensor called Phantom Sensor for about
two years now as a solo project. It just hit a milestone I'm pretty
excited about - the driver loads cleanly on Windows 11, passes Driver
Verifier with all standard flags enabled, and survives normal use
without crashing.

The kernel sensor (PhantomSensor) is a WFP+minifilter driver sitting
at altitude 385210. It's written in C targeting the WDK, roughly 370k
lines across 70+ modules. Some of what it does:

ObRegisterCallbacks for process/thread handle stripping (anti-injection, anti-debug)
Minifilter callbacks with stream contexts for file monitoring, ransomware backup engine, section object tracking
WFP callouts for network inspection - TCP stream reassembly, DNS monitoring, C2 beacon detection, TLS fingerprinting
PsSetCreateProcessNotifyRoutineEx / PsSetLoadImageNotifyRoutine for behavioral analysis
ETW provider + consumer for kernel telemetry
Registry callback for persistence detection (Run keys, services, scheduled tasks)
Process hollowing detection via VAD analysis + PE header comparison
Syscall table monitoring, direct syscall detection, Heaven's Gate detection , Halo's Gate detections + Hell's Gate detections
Lookaside lists for hot-path allocations, rundown protection for safe teardown, reference-counted object lifetimes

The behavioral engine tracks attack chains and maps to MITRE ATT&CK
techniques. Thread protection module does per-process activity tracking
with hash-bucketed trackers and rate limiting - had a fun use-after-free
in there (refcount off-by-one on newly inserted trackers, InsertTailList
caught the corrupted list entry - classic).

It's been a long road of analyzing dump reports using kd.exe(kernel debugger) windbg x64 and finding the errors that triggered the BSOD.Here are some: WORKER_INVALID from double-queuing
IO_WORKITEM on periodic timers. Stack overflows from 4KB structs in
image load callbacks. IRQL_NOT_LESS_OR_EQUAL from ERESOURCE without
KeEnterCriticalRegion. Each one taught me something.

The codebase is AGPL v3. But understand it is still not completed(There is not only kernel-sensor) we have a Beta 2028 target for the full product especially 3 products(Phantom XDR Phantom EDR and Phantom Consumer solutions below the ShadowStrike brand.

If you want to support or follow the journey of developing a Kernel-driver and a user-mode agent for the ShadowStrike Phantom products:

Join us on Github: https://github.com/ShadowStrike-Labs/ShadowStrike
If you want to give a support: https://github.com/sponsors/ShadowStrike-Labs
Site: https://www.shadowstrike.dev/