Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
1 event from the most recent confirmed update back to the earliest known activity.
A technical blog post published examples of module stomping on Windows, showing how to overwrite the entry point of a sacrificial DLL such as combase.dll or shell32.dll with shellcode and execute it locally or remotely. The post described use of APIs including NtCreateSection, NtMapViewOfSection, NtCreateThreadEx, ReadProcessMemory, and CreateRemoteThread.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
3 references tracked. Mallory keeps watching after this page renders.
malware.news
Open sourcecocomelonc.github.io
Open sourceapp.any.run
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.
Security researchers published a proof-of-concept for **remote function stomping**, a Windows process-injection method that overwrites an existing exported API function inside another process and then runs the injected payload with a remote thread. The demonstration used `notepad.exe` as the target and selected `CallMsgFilterA` from `user32.dll`, resolving the function locally before modifying the remote process with `VirtualProtectEx`, writing shellcode through `WriteProcessMemory`, and triggering execution via `CreateRemoteThread`. The write-up said the technique depends on the target DLL already being loaded in the remote process and noted that **ASLR** can affect DLL base addresses across processes. The authors presented the material as educational for malware researchers, red teams, and defenders, but the compiled sample was reportedly flagged as **suspicious** in an ANY.RUN sandbox, underscoring the detection and abuse potential of the method.
Jul 16, 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
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