Nocturne is a research-oriented Windows x64 shellcode loader built around a single goal: producing clean, fully backed call stacks that are indistinguishable from legitimate Windows threads — even under manual forensic inspection with WinDbg.
Modern EDR solutions and manual analysts rely on call stack integrity as a primary detection signal. Unbacked return addresses, misaligned frames, and dynamic function table artifacts are all strong indicators of malicious activity. Traditional stack spoofing techniques address some of these, but they break under Intel CET (Control-flow Enforcement Technology) shadow stack validation, where the hardware maintains a separate, read-only copy of return addresses that must match the software stack.
Nocturne solves this by taking a fundamentally different approach: instead of fabricating fake frames, it injects code into a legitimate module's .text section and registers a RUNTIME_FUNCTION entry with real donor unwind metadata from that module. The Windows unwinder then walks the stack using genuine unwind info, producing frames that point back to a signed, backed DLL (windows.storage.dll). Because the code physically resides within the module's address range and the unwind chain is structurally valid, both software-based stack walks and CET hardware validation see a legitimate call chain.
The loader is built entirely CRT-free (/NODEFAULTLIB) with a custom entry point, custom memset/memcpy intrinsics, and HeapAlloc/HeapFree operator overrides — no C runtime dependency in the final binary. All Win32 and NT API resolution happens at runtime through compile-time DJB2 hashing (constexpr): the hash values are computed during compilation and embedded as immediate constants, while the actual function pointers are resolved at runtime by walking PEB loader data structures. This means zero API name strings exist in the binary, and the IAT contains only benign camouflage imports.
Important
The payload exits immediately after execution, so short-lived shellcode (e.g. calc.exe launcher) will terminate before you can inspect the call stack. To properly analyze the spoofed stack, use a persistent payload such as an msfvenom reverse shell or a long-lived beacon — anything that keeps the thread alive long enough for manual inspection with WinDbg or Process Hacker.
All Win32/NT APIs are resolved at runtime by walking the PEB loader data structures and matching export names against precomputed DJB2 hashes. The hashes are generated at compile time using constexpr evaluation — the compiler computes each hash and embeds it as an immediate constant in the binary. At runtime, the resolver iterates the target module's export table and compares each export name's hash against the embedded constant. This eliminates IAT entries that would otherwise reveal the loader's true capabilities to static analysis tools, and ensures no API name strings are present in the binary.
The Import Address Table is populated exclusively with benign USER32.dll imports (MessageBoxA, RegisterClassW, IsWindowVisible, etc.) placed inside an unreachable code branch. Static analysis tools see a harmless GUI application rather than a loader.
Clean IAT — only benign USER32.dll imports and heap management functions
This is Nocturne's core technique. The stack spoofing pipeline:
- Sacrificial DLL Loading —
windows.storage.dllis loaded as the donor module - Code Cave Injection — Payload + ShadowGate stub are injected into
.textsection slack space - Dynamic Function Table Registration —
RtlAddFunctionTableregisters aRUNTIME_FUNCTIONentry pointing to donor unwind info, making the injected code appear as a legitimate function within the module - Inverted Function Table Collapse — The internal
RtlpInvertedFunctionTableentry for the donor module is collapsed so the dynamic table takes priority during unwinding - Cache Invalidation — Both the function table cache and function entry cache are flushed to force the unwinder through the manipulated lookup path
- Type=0 WinDbg Bypass — The dynamic function table entry type is patched from
RF_CALLBACKtoRF_SORTED, preventing WinDbg from resolving it as dynamic .pdataSuppression — The donor module's.pdatasection protection is set toPAGE_NOACCESS, forcing all unwind lookups through the controlled dynamic table
The result: every frame in the call stack resolves to windows_storage!<function> — a legitimate, backed module.
Process Hacker call stack — all frames resolve to windows.storage.dll
WinDbg stack trace showing legitimate windows_storage frames
The dynamic function table entry is invisible to WinDbg's forensic commands. Type patching and .pdata suppression ensure that debugger analysis cannot distinguish the spoofed frames from real ones.
WinDbg bypass — .fnent shows donor unwind info, no dynamic table artifacts
While the payload sleeps, the loader's entire image is encrypted in memory using a ROP chain built from RtlRegisterWait and NtContinue. The chain is executed on a dedicated worker thread and follows this sequence:
- WaitForSingleObjectEx — Gate: waits for the trigger event
- VirtualProtect — Changes the image to
PAGE_READWRITE - SystemFunction040 — Encrypts the image in-place (RtlEncryptMemory)
- NtGetContextThread — Backs up the current thread's context
- NtSetContextThread — Replaces it with a spoofed context captured from a legitimate thread (stack duplication)
- WaitForSingleObjectEx — Sleeps for the configured timeout
- NtSetContextThread — Restores the original context from backup
- SystemFunction041 — Decrypts the image back (RtlDecryptMemory)
- VirtualProtect — Restores
PAGE_EXECUTE_READ - SetEvent — Signals completion
During sleep, if an EDR calls GetThreadContext, it sees the duplicated stack of a legitimate Windows thread — not the loader's real context. Combined with BYOUD stack spoofing during execution, the thread appears clean both while running and while sleeping.
Before the image is encrypted, all busy heap allocations across every process heap (except the default process heap) are XOR-encrypted with a per-cycle random key. This prevents EDR memory scanners from finding decrypted strings, shellcode fragments, or configuration data in heap memory while the loader sleeps. The same key is used to decrypt after wakeup — the operation is fully symmetric.
Export Address Filtering (EAF) uses hardware breakpoints to detect when untrusted code reads the export tables of critical modules like ntdll.dll and kernel32.dll. Nocturne bypasses this using a gadget-based read primitive: instead of directly dereferencing export table pointers, all reads are routed through a MOV RAX, [RAX]; RET gadget found inside ntdll.dll itself. Since the actual memory read occurs within a signed Microsoft module, EAF's hardware breakpoints see a legitimate caller and do not trigger.
The ShieldedRead assembly stub accepts a target address and an optional gadget pointer. If a gadget is provided, it jumps to the gadget to perform the read; otherwise it falls back to a normal dereference. The LdrShieldedSymbolResolveByHash resolver uses this for every export table access — PE header parsing, name array iteration, ordinal lookup, and function address resolution all go through the gadget.
The entire project compiles with /NODEFAULTLIB and a custom entry point. Memory management uses HeapAlloc/HeapFree through operator overrides. memset and memcpy are implemented as custom intrinsics. This eliminates CRT dependencies that would inflate the binary and add unnecessary attack surface.
Shellcode is XOR-decrypted at runtime and executed through the ShadowGate assembly stub, which sets up the spoofed stack frame before transferring control.
Reverse shell established with fully spoofed call stack
Open Nocturne.sln in Visual Studio and build for x64 Release or x64 Debug.
| Configuration | Description |
|---|---|
| Debug x64 | Console output enabled, DEBUG preprocessor defined |
| Release x64 | Silent execution, no debug output |
Both configurations use
/NODEFAULTLIB, static CRT (/MT), no buffer security checks, and no C++ exceptions.
Note
For production use, make sure the DEBUG preprocessor definition is removed from your build configuration. The Debug x64 preset defines it by default — switch to Release x64 or manually remove _DEBUG and DEBUG from Project Properties → C/C++ → Preprocessor Definitions to disable all console output.
Nocturne/
├── include/
│ ├── Common.h # Global API struct & function declarations
│ ├── IatCamouflage.h # IAT camouflage with benign imports
│ ├── InitializeAPI.h # Runtime API resolution
│ ├── Primitives.h # Hash functions & utility macros
│ ├── Structs.h # NT structures & custom types
│ └── Debug.h # Debug console & print macros
├── src/
│ ├── Main.cpp # Entry point & orchestration
│ ├── StackSpoofing.cpp # Stack spoofing pipeline
│ ├── Unwind.cpp # Unwind info parsing & manipulation
│ ├── Context.cpp # Spoof context tracking & rollback
│ ├── Resolver.cpp # PEB walking & hash-based API resolution
│ ├── StackUtils.cpp # Stack origin & cookie detection
│ ├── Proxy.cpp # Thread pool proxied API calls
│ ├── Zilean.cpp # Sleep obfuscation, heap masking & stack duplication
│ ├── Intrinsic.cpp # Custom memset/memcpy
│ ├── Debug.cpp # Debug console allocation
│ ├── ShadowGate.asm # Payload execution stub
│ ├── StackSearch.asm # Stack scanning primitives
│ ├── SetRegister.asm # Register manipulation
│ ├── Unguard.asm # EAF bypass gadget-based read primitive
│ └── ApiStub.asm # Indirect syscall stubs
└── docs/
└── screenshots/
- klezVirus — Original author of the BYOUD technique that Nocturne's stack spoofing is built upon
- klezVirus/BYOUD — Bring Your Own Unwind Data — the foundational research behind runtime function table manipulation
- BYOUD Blog Post — Detailed technical writeup of the BYOUD technique
- MalDev Academy — Malware development techniques and methodology
- Microsoft x64 Exception Handling — Official documentation on x64 unwind info,
RUNTIME_FUNCTION, and the exception handling ABI - Stack Spoofing — Black Hat Talk — Presentation on advanced stack spoofing techniques
- Hiding in Plain Sight — Thread stack spoofing and call stack manipulation research
This project is intended for authorized security research and educational purposes only. The author is not responsible for any misuse. Always obtain proper authorization before testing on systems you do not own.
If you find this project useful or interesting, consider leaving a ⭐
Your support motivates further research and development.