DEV Community: Scidrow666

Bypassing Enterprise Bloatware: Building a Zero-Framework Asynchronous EDR Triad in Go and Pure WinAPI

Scidrow666 — Tue, 01 Sep 2026 11:49:52 +0000

Stop wasting your hardware threads and RAM pools on corporate endpoint detection agents that consume 500MB of memory just to stream telemetry to a cloud bucket. When you secure a host at the bare-metal subsystem layer, you don't need static signature databases, heavy Electron-based dashboards, or background bloatware overhead. You need execution velocity and aggressive, multi-threaded memory isolation.Here is the architectural blueprint of a standalone, zero-signature security stack designed for low-overhead Windows environments, engineered natively across an asynchronous, dual-binary pipeline: Scidrow Hunter (Asynchronous Golang Telemetry) and Scidrow Sniper (Pure WinAPI C++ Eviction Engine). The Core Philosophy: Modular Telemetry vs. Native VaporizationGromozdkie enterprise EDR solutions fail because they chain connection sniffing, memory forensics, and process termination within a single monolithic execution thread. If a high-privilege stealer halts the main scan module, the entire telemetry loop goes down.The Scidrow Engine Architecture splits this responsibility into an interconnected asynchronous loop:[ Raw Network Wire ] ---> ( Npcap Sniffer via BPF )
|
( Golang Core: JA3 / VirtualQueryEx )
|
[ Named Pipe: \.\pipe\scidrow_edr ]
|
( C++ Core: PIPE_WAIT Kernel Sleep )
|
[ Native TerminateProcess (0XDEADC0DE) ]
Part 1: Scidrow Hunter — Asynchronous Socket & Memory Auditor (Golang)The front-line defense module operates as an independent, multi-threaded telemetry collector compiled natively in Go with completely stripped debugging tables (-ldflags="-s -w") to deter static reverse-engineering. 1. Network Telemetry at Wire LevelInstead of hooking high-level user-mode network sockets (which advanced stagers can easily bypass via direct syscalls), Hunter utilizes Npcap under a highly optimized Berkeley Packet Filter (BPF):tcp dst port 443 or tcp dst port 80 or tcp dst port 8080It performs deep, real-time JA3 Fingerprinting on active TLS Handshake Client Hello packets. If a connection footprint matches the hardcoded cryptographic signatures of known stealth command-and-control (C2) stealers (e.g., Lumma Stealer fingerprint), an instant IPC payload is generated.2. Deep Memory Inspection (VirtualQueryEx)Simultaneously, a background routine continuously maps the memory layout (MEM_COMMIT) of local target wrappers (browsers, temp-stagers). It flags any unverified shellcode allocation masks containing RWX execution privileges (PAGE_EXECUTE_READWRITE), immediately tracing the socket ownership back to its physical PID. Part 2: Scidrow Sniper — Pure WinAPI Registry & Process Vaporizer (C++)Once a threat is flagged, the mitigation must happen natively with zero execution lag. This is handled by Scidrow Sniper, a compact C++ daemon optimized aggressively via MinGW (-O3 -static) to run flawlessly even on legacy x86-64 hardware layers. 1. 0% CPU Kernel Sleep via Named PipesSniper doesn't waste CPU cycles in a continuous polling loop. The listener thread drops straight into an OS kernel-level sleep utilizing PIPE_WAIT properties on a secure Windows Named Pipe:\.\pipe\scidrow_edrThe moment the Go-based Hunter transmits a high-priority 4-byte DWORD PID, the pipe instantly wakes the eviction thread. 2. Programmatic Vaporization (0XDEADC0DE)The eviction thread bypasses standard Windows process management subroutines, targeting the malicious memory footprint directly via native TerminateProcess hooks. The daemon passes an explicit, hardcoded forensic signature 0XDEADC0DE as the exit code. This ensures that any third-party forensic tool or event log audit can trace the programmatic eviction to our security stack. 3. Registry Integrity WatchdogWhile the pipe listener sleeps, the primary thread executes a high-velocity loop targeting critical Windows user-init persistence vectors:HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ShellHKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\UserinitTo bypass WoW64 subsystem virtualization and prevent malware from manipulating hidden alternative registry views, Sniper utilizes explicit KEY_WOW64_64KEY execution flags. If an unauthorized alteration attempt is detected, Sniper instantly triggers a self-healing routine, overwriting the hive back to clean system defaults (explorer.exe), and safely recycles the scanning context via exit(0). Conclusion: True Local SovereigntyBy separating raw packet capture from low-level process termination via secure IPC channels, this dual-binary stack ensures total local host integrity with a near-zero idle footprint. You don't need cloud-heavy enterprise agent wrappers to defend your machine. Secure your endpoints at the native OS sub-layer.The source code for both independent modules is fully open-source and open for community audit:Telemetry Guard: ://github.com Forensic Vaporizer: ://github.com
To be clear: this is my personal passion project and late-night hobby. I don't build this for corporate venture capital or commercial monetization. I engineered this stack because I love pure, low-level WinAPI mechanics, and I wanted to see how far I could push real-time host isolation without the modern bloatware layers.
https://github.com/Scidrow666

How I built a lightweight standalone behavioral anti-stealer to protect my Windows environment

Scidrow666 — Wed, 15 Jul 2026 17:21:34 +0000

Hey everyone,

Tired of bloated corporate solutions eating up hundreds of megabytes of RAM just to monitor active local connections, I decided to build a lightweight, standalone behavioral anti-stealer strictly focused on stopping modern infostealers (Lumma, RedLine, etc.) from exfiltrating local browser profiles.

The project is completely open-source (GNU GPL v3) and written in pure Python (compiled to a tight ~9MB standalone executable). No heavy signature databases, no cloud telemetry. It works purely on proactive local host and socket heuristics.

How the background thread guards the perimeter every 5 seconds:

Process Lineage (Parent PID) Validation: Traces back the owner of any active LISTEN or ESTABLISHED socket. If a protected Windows system binary is spawned by an unverified process running inside temporary user directories (Temp/AppData/Downloads), it flags it as a potential hollowing/injection attempt and terminates the branch.
Cryptographic Integrity: Maintains a strict local memory dictionary cache of verified process identity indicators (SHA-256) to prevent malicious files from using whitelist name-spoofing tactics.
Protected Storage Auditing: Checks open file descriptors. If an unverified process tries to lock or read Chrome's "Login Data" or Telegram's "tdata" session paths while simultaneously establishing an external network connection, it flags it for immediate termination.
CPU Execution Check (Anti-Sleep): Catches delayed-execution malware by analyzing zeroed CPU runtime execution metrics.
I ran a 24-hour stress test on an old Phenom II setup running Windows 10, and the memory caching layer keeps overhead at a rock-solid 0-2% CPU usage. It successfully managed and isolated background telemetry agents and invasive service connections in real-time.

My main architectural questions for the community:

Is a 5-second interval safe enough, or can modern infostealers complete a full DPAPI decrypt-and-dump cycle faster than that?
What are the edge cases under Windows where process lineage tracking might cause false detections on legitimate protected OS services?
The full implementation details and compiled binary are available for audit in my repository:
https://github.com/Scidrow666/scidrow-hunter

Thanks for any performance feedback!

How I built a lightweight standalone behavioral anti-stealer to protect my Windows environment

Scidrow666 — Wed, 15 Jul 2026 14:45:55 +0000

How it works:
Zero-Signature Behavioral Analysis: It doesn't look for known malware hashes. It monitors the behavior of running processes on the hardware level.
Multi-Threaded Customs Officer: Inspects all active LISTEN/ESTABLISHED network connections every 5 seconds in a background thread.
Parent PID Validation: Traces process lineage back to its roots. If a system process (like smartscreen.exe) is spawned by an unverified binary inside Temp/AppData/Downloads, it nukes the entire branch immediately to prevent process hollowing.
Cryptographic Caching: Dynamically verifies binary integrity via SHA-256 to stop whitelist name-spoofing.
DPAPI & Tdata Interception: Monitors unauthorized file descriptor access targeting Chrome's "Login Data" and Telegram's session paths.
Anti-Sleep Countermeasure: Catches delayed-execution malware by analyzing zeroed CPU execution runtimes.
How to deployment:
For Professionals (.py): Review the clean, fully transparent Python source code in Notepad. No hidden backdoors. Requires pip install psutil.
For Casual Users (.exe): Download the standalone pre-compiled executable from the Releases page—no Python installation required.

How I built a lightweight standalone behavioral anti-stealer to protect my Windows environment

Scidrow666 — Tue, 14 Jul 2026 17:19:16 +0000

Hey everyone,

How the background thread guards the perimeter every 5 seconds:

Process Lineage (Parent PID) Validation: Traces back the owner of any active LISTEN or ESTABLISHED socket. If a protected Windows system binary is spawned by an unverified process running inside temporary user directories (Temp/AppData/Downloads), it flags it as a potential hollowing/injection attempt and terminates the branch.
Cryptographic Integrity: Maintains a strict local memory dictionary cache of verified process identity indicators (SHA-256) to prevent malicious files from using whitelist name-spoofing tactics.
Protected Storage Auditing: Checks open file descriptors. If an unverified process tries to lock or read Chrome's "Login Data" or Telegram's "tdata" session paths while simultaneously establishing an external network connection, it flags it for immediate termination.
CPU Execution Check (Anti-Sleep): Catches delayed-execution malware by analyzing zeroed CPU runtime execution metrics.

I ran a 24-hour stress test on an old Phenom II setup running Windows 10, and the memory caching layer keeps overhead at a rock-solid 0-2% CPU usage. It successfully managed and isolated background telemetry agents and invasive service connections in real-time.

My main architectural questions for the community:

Is a 5-second interval safe enough, or can modern infostealers complete a full DPAPI decrypt-and-dump cycle faster than that?
What are the edge cases under Windows where process lineage tracking might cause false detections on legitimate protected OS services?

The full implementation details and compiled binary are available for audit in my repository:
https://github.com/Scidrow666/scidrow-hunter

Thanks for any performance feedback!