Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
A technical article demonstrated a custom C++ implementation of LoadLibrary using ntdll.dll functions RtlInitUnicodeString and LdrLoadDll, then used it to load a sample DLL and resolve exported functions. The author described the technique as useful for malware development and AV evasion, while presenting it as an educational demonstration tested on Windows 10 x64.
Microsoft published documentation for the Win32 LoadLibraryA API, including security guidance warning that unsafe DLL path resolution and SearchPath usage can enable malicious DLL loading and DLL hijacking.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
2 references tracked. Mallory keeps watching after this page renders.
Map 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.
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.
Aug 15, 2026
A public technical walkthrough detailed **module stomping**, a Windows code-injection technique that executes shellcode by overwriting the `.text` section and entry point of a legitimate sacrificial DLL instead of allocating new executable memory. The write-up showed how an attacker can map a DLL as a `SEC_IMAGE` section with native APIs such as `NtCreateSection` and `NtMapViewOfSection`, confirm that the payload fits between the DLL entry point and the end of the code section, replace the entry point with shellcode, and launch execution with thread-creation APIs including `NtCreateThreadEx`. The material also described a remote variant in which a DLL such as `shell32.dll` is loaded into another process, its entry point is located with process-memory and Toolhelp APIs, and that entry point is overwritten before execution is triggered with `CreateRemoteThread`. Examples cited `combase.dll` and `shell32.dll` as sacrificial modules and noted that manual mapping may help avoid **Control Flow Guard** issues that can arise with `LoadLibrary`, making the published proof of concept directly relevant to defenders tracking stealthy malware tradecraft on Windows.
Jul 29, 2026
Security researchers have highlighted advanced methods for analyzing and manipulating Windows binaries, focusing on both dynamic binary instrumentation (DBI) and DLL hijacking techniques. The use of open-source frameworks like DynamoRIO enables analysts to perform runtime analysis, reverse engineering, and security auditing of executables without access to source code. These tools are essential for malware analysis and can evade anti-analysis techniques, providing transparency and low performance impact during execution. Step-by-step guides and sample code are available to help researchers build their own DBI tools for Windows 11, demonstrating practical applications in security research. In parallel, researchers have explored persistence and privilege escalation techniques involving DLL hijacking in Windows accessibility features. By exploiting the way Narrator.exe loads specific DLLs, attackers with local administrator access can execute arbitrary code by placing malicious DLLs in targeted directories. This method, which has persisted despite being known for over a decade, allows code execution within the context of system processes, although it may require additional steps to suppress unwanted side effects such as the accessibility feature's voice output. These findings underscore the ongoing need for vigilance in monitoring both binary instrumentation and DLL loading behaviors on Windows systems.
Jun 29, 2026