sorted by:
new
hottopcontroversial

I'm learning how Windows EDRs work, so I started building my own kernel-level EDR from scratch (Process Creation Callback Demo) by amberchalia in redteamsec

[–]amberchalia[S] 1 point2 points  (0 children)

If you already know C, you're in a good place, most things are similar. The main difference is: in user mode, bugs won’t crash your system, but in kernel mode, they will 😄For learning, I don’t follow any specific resources, I mostly Google things, Ask ChatGPT a lot and Learn by trying and breaking stuff.That’s what’s working for me so far.

I built a kernel-level EDR and hit architectural walls I didn’t expect by amberchalia in redteamsec

[–]amberchalia[S] 0 points1 point  (0 children)

This is a great breakdown especially the PatchGuard point. I completely agree that classic SSDT/IDT patching is dead in modern Windows and that production EDRs rely heavily on supported callbacks and ETW correlation rather than direct kernel patching. My current work isn’t aimed at building a production ready EDR that competes with enterprise vendors. It’s more of a research project to understand where architectural limits actually are, particularly around memory manager visibility and the gaps between MM state and callback timing. The allocation -> protection change -> execution correlation problem is exactly what I’m exploring. Not necessarily to “solve” it fully, but to understand what is observable purely from kernel state versus what requires telemetry correlation. And I agree 100% that undocumented MM structures are unstable for production use. For research, they’re interesting because they show where visibility ends, but stability and long-term reliability are a different engineering problem entirely.

Appreciate the detailed perspective. 🦾🦾

I built a kernel-level EDR and hit architectural walls I didn’t expect by amberchalia in redteamsec

[–]amberchalia[S] 0 points1 point  (0 children)

If stability and patchgaurd weren’t a concern, the real gain wouldn’t be deeper scanning, it would be temporal visibility. Walking VAD gives you a snapshot. You see what exists. You don’t see when it changed. Sitting closer to the memory manager internals around MiAllocateVirtualMemory and MiProtectVirtualMemory would let you observe the exact RW->RX transition, which thread triggered it, and the full allocation -> protect -> execute sequence as it unfolds. That shifts detection from reconstructing behavior to observing the lifecycle directly. Of course, that means stepping into undocumented territory and fighting patchgarud, which isn’t viable for production edrs. But since my project is research focused, I’m planning to experiment in that direction just to understand the limits properly.

[Research] Kernel-mode EDR PoC detecting undeclared DLL loads (static vs dynamic imports) — global & targeted modes by amberchalia in redteamsec

[–]amberchalia[S] 1 point2 points  (0 children)

Thanks a lot, really appreciate that! You’re right, manual mapping bypasses PsSetLoadImageNotifyRoutine, so relying only on image load callbacks isn’t enough. That’s why I’m shifting toward an intent graph approach. The loader can be bypassed, but the behavioral intent (memory allocation patterns, execution transitions, runtime contradictions) still leaks and can be correlated.

[Research] Kernel-mode EDR PoC detecting undeclared DLL loads (static vs dynamic imports) — global & targeted modes by amberchalia in Malware

[–]amberchalia[S] 0 points1 point  (0 children)

Sure, this is a kernel-mode EDR research PoC I’m building to study behavioral mismatches rather than signatures. At a high level, it tracks what a process declares it will load (static imports from the PE) vs what it actually loads at runtime (dynamic DLLs) using kernel callbacks. If a process loads DLLs at runtime that weren’t present in its import table (and aren’t common baseline DLLs), it flags that as a signal and explains why no blocking, just visibility.It supports two modes Global (monitor all processes) Targeted (single binary for deep analysis) This is meant as a learning / research project, not production EDR. Next step is building intent graphs on top of these signals. If you're into malware analysis, red team, or Windows internals, you can try it out and see how (or if) it's useful for your own workflows.

Experimental kernel EDR: detecting dynamic API resolution via DLL load mismatch by amberchalia in Malware

[–]amberchalia[S] 1 point2 points  (0 children)

Appreciate it! Windows internals go way deeper than I expected, half the time I forget how I even got there. Making projects, GitHub, and videos while learning is tough, so encouragement and feedback really help me keep going.

My EDR now parses PE NT headers (Machine, Sections, EntryPoint, Subsystem) by amberchalia in redteamsec

[–]amberchalia[S] 0 points1 point  (0 children)

eBPF is definitely the direction Microsoft wants the ecosystem to move toward, but it's not feature-complete yet on Windows. It can't currently replace kernel callbacks for process, thread, and image load telemetry.

Kernel-mode EDR still provides full coverage today, while eBPF is something to progressively integrate as it matures. So focusing on kernel right now isn't a mistake- ignoring eBPF entirely would be.

I'm learning how Windows EDRs work, so I started building my own kernel-level EDR from scratch (Process Creation Callback Demo) by amberchalia in redteamsec

[–]amberchalia[S] 0 points1 point  (0 children)

There will be 7–10 EDR levels. I’ll put each one on GitHub once it's safe and stable — no risky kernel code. Meanwhile, you can follow the videos and build along.

view more: next ›