Two VB.NET modules form a paired lab that explains a full shellcode story from loader to defender. ShellcodeLoaderConcept walks through the three classic steps of in-memory code execution. ShellcodeDefenseConcept then reframes the same API sequence from an EDR point of view and marks each function call as a detection and intervention hook. Together they describe a clear offensive–defensive interaction around low-level Windows memory and thread APIs.
—
Shared threat model and execution chain
Both modules revolve around the same three-step attack pattern:
Allocate memory with read-write-execute (RWX) permissions using VirtualAlloc.
Copy payload bytes into that memory region.
Start a new thread at the start of that memory region using CreateThread.
ShellcodeLoaderConcept labels this flow as an “ATTACK FLOW DEMO” and prints each stage in sequence. ShellcodeDefenseConcept uses the same structure and treats each stage as an EDR “intervention point,” with explicit alerts when the program allocates RWX memory and when a thread begins execution in heap memory. The pair therefore exposes the same technical surface from two viewpoints: attacker behavior and defender telemetry.
—
Offensive side: ShellcodeLoaderConcept
ShellcodeLoaderConcept defines two unmanaged imports from kernel32.dll: VirtualAlloc and CreateThread. The loader code treats those functions as primary tools for process-injection style execution.
Functional flow:
1. Payload model
The module sets SafePayloadBytes as an ASCII string instead of real shellcode and explains that real attacks embed raw machine code in that array. That choice keeps the demo safe while preserving the structural logic of a loader.
2. Memory allocation
The code calls VirtualAlloc with MEM_COMMIT Or MEM_RESERVE and PAGE_EXECUTE_READWRITE. The RWX flag marks the region as both writable and executable. That combination matches a common shellcode pattern and gives defenders a simple signature. The loader reports the returned address as a hex value to show the location of the injected region.
3. Payload write
Marshal.Copy moves SafePayloadBytes into the RWX region. Comments explain that real malware writes shellcode bytes here and that the write step silently prepares the process for code execution outside any loaded module.
4. Thread creation and transfer of execution
The loader calls CreateThread with lpStartAddress set to the RWX region. That call hands the CPU instruction pointer to the payload. In a real intrusion, the thread runs real shellcode and delivers process injection, staging, or other post-exploitation logic. The module notes that safe ASCII bytes in that region normally trigger a crash, which reinforces the idea that real shellcode requires careful engineering.
The offensive module therefore captures a minimal in-process loader that any red-team toolkit or commodity malware family can embed, while still keeping payload content benign.
—
Defensive side: ShellcodeDefenseConcept
ShellcodeDefenseConcept defines the same Windows APIs plus WaitForSingleObject. Comments frame those functions as “threat signatures” that security agents monitor. The module then walks through the same three stages as the loader but speaks in the voice of an EDR sensor.
Functional flow:
1. Stage 1 – Memory allocation hook
The code calls VirtualAlloc with RWX permissions, just as a loader would. After a successful allocation, the defense logic checks the protection flags and prints an [EDR ALERT] message that flags RWX memory as a shellcode signature along with an “Intervention Point 1” where an agent terminates the process or changes protections. That message explains the analytic rule in plain language: writable plus executable heap space equals suspicious behavior.
2. Stage 2 – Conceptual payload write
Comments describe Marshal.Copy in conceptual form, without actual byte writes. The module prints an informational line that says payload bytes now occupy the allocated region. The design highlights the step for training while avoiding any unsafe code.
3. Stage 3 – Thread origin hook
The code calls CreateThread with lpStartAddress at the RWX region. After success, the module prints a second [EDR ALERT] that states a thread started in heap memory and describes “Intervention Point 2” as suspension or termination of the offending thread or process. Comments emphasize that security engines track threads that start at non-module addresses, since normal software almost always begins execution inside loaded binaries, not heap allocations.
The defense module therefore maps each low-level call to specific EDR decisions and helps analysts think in terms of hooks and response points rather than raw API names.
—
Combined capability: red–blue pairing
Viewed together, the two modules form a complete attack–defense narrative.
ShellcodeLoaderConcept demonstrates a realistic loader implementation, including RWX allocation, payload write, and thread creation, while keeping content harmless.
ShellcodeDefenseConcept demonstrates how modern security agents watch the same behavior, treat RWX allocation and heap-origin threads as strong signals, and intervene before shellcode finishes execution.
The offensive code shows exact inputs an attacker supplies to VirtualAlloc and CreateThread. The defensive code then explains how an EDR inspects those arguments during runtime and links them to a detection policy. That pairing gives defenders a mental map from raw API telemetry to higher-level judgments like “shellcode loader active in process X” and “safe intervention points exist before payload activity.”
—
Tradecraft, ATT&CK alignment, and evolution
The loader side lines up with several ATT&CK techniques:
In-memory execution and process injection through RWX heap regions and thread creation.
Defense evasion through code that never touches disk as a separate executable section, beyond the host process.
The defense side lines up with:
API monitoring and memory protection analysis as part of an EDR agent.
Early kill-chain disruption through targeted process or thread termination.
From a tradecraft standpoint, the pair models an arms race. Attackers stitch loaders around VirtualAlloc and CreateThread. Defenders watch for RWX allocations and heap-origin threads. Attackers then shift to more subtle patterns, such as VirtualAlloc with read-write only followed by VirtualProtect changes, or use of syscalls that bypass user-mode API monitoring. The modules give analysts a baseline so further evasion tricks fit into a coherent picture.
—
Intelligence and training value
The code does more than show syntax. The pair encodes a mental model:
Shellcode loaders follow a small set of mechanical steps.
Security agents inspect those steps at the API and memory level, not only at the file level.
Each step offers an opportunity for detection and disruption before higher-impact activity.
Analysts who study both modules gain a structured view of shellcode execution from two sides of the engagement. That view supports better rule writing, sharper hunt queries, and more direct questions for EDR vendors about coverage gaps around RWX allocation and heap-origin threads.
