Loading story…
Security research and malware-development writeups detailed a Windows evasion technique that avoids standard loader APIs such as GetProcAddress and GetModuleHandle by manually walking the Process Environment Block (PEB) and parsing DLL export tables. The approach resolves modules like kernel32.dll and user32.dll at runtime, including from encrypted strings, to reduce obvious API references in binaries and make static or behavioral detection more difficult. Microsoft’s documentation for GetProcAddress provides the baseline behavior that these custom implementations are designed to replace.
One proof of concept showed a custom GetProcAddress implementation that located MessageBoxA dynamically on Windows 10 x64, while another demonstrated finding kernel32.dll in assembly-style code and resolving exports by hash before allocating memory and launching a benign payload with CreateThread. The authors framed the method as malware and red-team tradecraft, linked it to MITRE ATT&CK T1027, and noted similarities to techniques seen in Conti ransomware source code, underscoring how manual API resolution can help malicious code lower its detection footprint.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
A follow-up tutorial published a custom GetProcAddress implementation that manually parses a module's export table and pairs it with a custom GetModuleHandle routine that walks the PEB. The sample resolved user32.dll and MessageBoxA from encrypted strings at runtime as an AV-evasion technique on Windows 10 x64.
A tutorial published a custom GetModuleHandle implementation that walks the PEB loader module list to locate loaded DLLs without calling the WinAPI directly. The Windows 10 x64 PoC decrypted user32.dll and MessageBoxA at runtime, resolved the function with GetProcAddress, and displayed a message box as an AV-evasion demonstration.
A tutorial presented a malware-relevant Windows technique for locating kernel32.dll via the PEB and resolving exports by hash, then using the resolved APIs to allocate memory and execute a benign message-box shellcode payload. The post said the trick had been observed in Conti ransomware source code and was demonstrated on Windows 10 x64.
A technical lab demonstrated how Windows x86 shellcode can traverse the TEB and PEB loader structures to find kernel32.dll in memory, manually parse its export table, resolve WinExec, and invoke it to launch calc.exe. The article presented the technique as a foundational method for resolving APIs such as GetProcAddress and LoadLibrary at runtime.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
6 references tracked. Mallory keeps watching after this page renders.
docs.microsoft.com
Open sourcecocomelonc.github.io
Open sourcecocomelonc.github.io
Open sourcecocomelonc.github.io
Open sourceired.team
Open sourcelearn.microsoft.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Multiple public research reports detailed how attackers can evade Windows security monitoring by abusing native APIs, loader behavior, and application logging. White Knight Labs and XPN documented techniques to suppress or bypass **Event Tracing for Windows (ETW)** visibility in .NET and Windows processes, while separate research showed that access-mask-based detections can be defeated with `DuplicateHandle` by first requesting only `PROCESS_DUP_HANDLE` and then cloning a more privileged handle to targets such as **LSASS** or **winlogon**. Microsoft documentation for `CreateProcessA` also appeared in the reference set because process creation remains central to many payload chains, including shellcode that ultimately launches command shells or follow-on tooling. Additional reports showed how attackers can blend execution into legitimate Windows behavior and trusted software. iPurple described **EntryPoint Hijacking**, in which a loaded DLL's entry point is overwritten so malicious code runs during normal thread creation or loader activity, reducing obvious injection signals and complicating EDR detection. NVISO separately analyzed Metasploit reverse-shell shellcode that walks the **PEB** and resolves APIs such as `LoadLibraryA`, networking functions, and `CreateProcessA`, while Hunt & Hackett showed that **ConnectWise Control/ScreenConnect** can be used for intrusion activity and that its own event logging can be disabled by patching `ScreenConnect.Core.dll`. Together, the reports underscore that defenders must validate loader integrity, monitor low-visibility handle requests and memory writes, and avoid relying on a single telemetry source such as ETW or application-generated event logs.
Aug 15, 2026
A technical walkthrough demonstrated how to load a Windows DLL without calling the standard `LoadLibrary` API by invoking the undocumented `ntdll.dll` routine `LdrLoadDll` from a C++ program. The example used a sample `pet.dll`, then resolved exported functions with `GetProcAddress`, showing that the DLL could be loaded and executed successfully on Windows 10 x64. The technique was presented as a malware-development and AV-evasion method, illustrating how attackers or red teams can bypass more obvious API usage while preserving normal DLL functionality. Microsoft's documentation for `LoadLibraryA` underscores the broader security implications of DLL loading, warning that unsafe path handling and incorrect assumptions about the DLL search order can enable malicious DLL loading and hijacking. The guidance notes that developers who rely on insecure search behavior, including the current working directory or `SearchPath`, may expose applications to attacker-controlled libraries, making DLL loading behavior a persistent abuse point for both stealthy execution and privilege abuse on Windows.
Aug 15, 2026
Windows malware and offensive tradecraft increasingly rely on **direct system calls**, **NTDLL unhooking**, and related userland-hook bypass methods to evade antivirus and EDR monitoring during code injection and process manipulation. Public research describes replacing high-level WinAPI calls with `Nt*` syscalls such as `NtAllocateVirtualMemory`, `NtWriteVirtualMemory`, and `NtCreateSection`, often through custom assembly stubs or frameworks like **SysWhispers**, to avoid hooks placed in `ntdll.dll`. Other documented techniques include restoring clean `.text` sections of loaded DLLs from disk, dynamically invoking APIs without standard imports, and abusing TLS-based reentrancy checks in inline hooks so security products skip behavioral inspection. These methods are reflected in real malware analyses. **WikiLoader** was observed using indirect syscalls via `ntdll.dll` to change memory protections, inject code into `bingmaps.dll`, and later inject shellcode into `explorer.exe` with `ZwOpenProcess`, `ZwAllocateVirtualMemory`, and `ZwWriteVirtualMemory`. An **XWorm** loader used direct `Nt*` syscalls for section-based payload injection into legitimate processes while checking for JMP opcodes on `Nt` functions as an anti-hooking measure. A separate **APT29-linked Dropbox loader** resolved direct syscalls through hashed lookups and restored DLL code sections from disk to remove user-mode hooks before maintaining persistence and exchanging encrypted payloads through Dropbox-based command and control.
Aug 15, 2026