Loading story…
Security research detailed a Windows code-injection technique that abuses Portable Executable (PE) sections marked readable, writable, executable, and shared (RWX-S) to place shellcode into another process without relying on common cross-process memory operations such as WriteProcessMemory. The method takes advantage of PE shared sections so that changes made in one process can be reflected in another process loading the same image in the same session, potentially reducing visibility to kernel-observed telemetry sources such as Microsoft-Windows-Threat-Intelligence ETW and ObRegisterCallbacks.
The research said attackers could patch a host binary whose entry point resides inside an RWX-S section, causing shellcode to execute when the remote process loads the binary. Using VirusTotal Retrohunt and YARA to identify candidate files, the author found more than 10,000 unsigned matches overall, including 99 unsigned x64 samples, along with roughly 15 uniquely signed binaries with valid Authenticode signatures, only five of them x64. Microsoft PE format documentation provides the structural context for how such shared sections are defined, while the findings suggest these binaries are uncommon enough to give defenders a relatively high-fidelity detection opportunity despite their offensive value.
Get the actors, campaigns, and ATT&CK mapping behind it.
4 events from the most recent confirmed update back to the earliest known activity.
A blog post published by Bill Demirkapi described a code-injection technique that abuses RWX-S PE sections to place shellcode into a remote process without direct process-memory operations such as WriteProcessMemory. The article also highlighted the technique's implications for evading common kernel-visible telemetry while noting that loading the host binary remains detectable.
The article states that Microsoft discussed shared sections as a security hole in 2004, providing historical context for abuse of PE shared sections.
Using a second YARA rule and a Python script to download low-detection samples and verify signatures, the author identified about 15 unique binaries with valid Authenticode signatures. Only 5 of those uniquely signed RWX-S binaries were x64.
The author created YARA rules and used VirusTotal Retrohunt to search files submitted over the previous 12 months for PE images with readable, writable, executable, and shared sections. The search found more than 10,000 unsigned matches, including 99 unsigned x64 samples.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
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.
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
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 newly published Windows process-injection technique, described as **console named-pipe injection**, places payload bytes into an interactive console child process through its standard-input named pipe rather than using the heavily monitored `VirtualAllocEx` and `WriteProcessMemory` APIs. The proof of concept launches a console application, sends bytes through standard input with `WriteFile`, identifies the resulting in-process buffer, changes its protection using `VirtualProtectEx`, and redirects a thread to execute the payload. The technique is presented for authorized red-team and penetration-testing use, with no reported vulnerability, threat actor, malware campaign, or confirmed in-the-wild exploitation. Defenders should assess detections for remote `VirtualProtectEx` activity and unusual named-pipe read/write behavior involving console processes—particularly commonly abused binaries such as `netsh.exe` and `nslookup.exe`—rather than relying solely on alerts for cross-process memory allocation or `WriteProcessMemory`.
Sep 28, 2026