Loading story…
PE-sieve, an open-source tool maintained by hasherezade, is being highlighted as a lightweight process scanner for detecting and dumping malicious code implanted in memory. The tool scans individual processes and identifies artifacts such as replaced or injected PE files, shellcode, hooks, and in-memory patches, with documented coverage for techniques including Process Hollowing, Process Doppelgänging, reflective DLL injection, and inline hooks. The project can be built as either an executable or DLL, exposes an API in DLL form, and relies on the libPEConv library for PE loading and manipulation; related projects include HollowsHunter for broader process or system scanning.
Security researchers have also shown PE-sieve in practical malware-unpacking workflows. In one published walkthrough, analysts used it to recover an unpacked AsyncRAT payload injected into aspnet_compiler.exe, alongside alternative memory-dumping methods using Process Hacker and debugger-assisted inspection. The recovered implant required memory extraction and, in some cases, PE section-header realignment before tools such as dnSpy could parse the dumped .NET assembly, underscoring PE-sieve's role in incident response and reverse engineering of fileless or memory-resident malware.
Get the actors, campaigns, and ATT&CK mapping behind it.
5 events from the most recent confirmed update back to the earliest known activity.
The repository indicates its latest listed commit updated sig_finder, marking a subsequent code change in the project.
The repository shows a version file entry for PE-sieve 0.4.1.5, reflecting a newer project version.
The PE-sieve repository lists a release tagged v0.4.1.1, indicating a published project release.
An Embee Research article documented using PE-sieve, Process Hacker, pe-bear, and x32dbg to recover an unpacked AsyncRAT payload from memory after injection into aspnet_compiler.exe.
A WordPress page for PE-sieve appeared on hasherezade's site, providing an early public reference for the tool.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
5 references tracked. Mallory keeps watching after this page renders.
github.com
Open sourceembeeresearch.io
Open sourcehshrzd.wordpress.com
Open sourcegithub.com
Open sourcegithub.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.
A technical write-up introduced **PE-OopsSec**, a toolkit from Two Seven One Three designed to identify operational security mistakes and metadata artifacts in Windows Portable Executable (PE) files that can expose malware, payloads, or developer environments. The article details how defenders and analysts can use indicators such as subsystem settings, debug symbols, Rich Header data, `OriginalFilename` mismatches, timestamps, resource language IDs, import tables, RTTI, import hashes, fuzzy hashes, and entropy to cluster binaries, support attribution, and flag suspicious files in EDR platforms and sandboxes. The guidance frames PE metadata review as a pre-deployment checklist for red-team payloads and other Windows binaries, with mitigations including stripping debug information, using deterministic builds, disabling RTTI, dynamically resolving APIs, and reviewing hashes and entropy before release. A subsequent Reddit post amplified the article to the wider security community, positioning it as practical tradecraft for red teamers, malware reversers, and forensic practitioners rather than reporting a specific intrusion or malware campaign.
Jul 23, 2026
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
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.
Aug 15, 2026