Reflective DLL Injection: How Malware Executes DLLs Directly in Memory Without Disk Files

Reflective DLL Injection allows malicious code to load and execute a DLL entirely in memory, bypassing traditional file-based loading mechanisms on Windows. The technique uses a custom loader inside the DLL itself to handle PE format parsing, relocations, imports, TLS, and exception handling without calling LoadLibrary. Unlike standard loading, the resulting module often resides in MEM_PRIVATE regions and does not appear in conventional module lists, complicating forensic analysis. Tools such as Meterpreter and Cobalt Strike have historically employed reflective loaders, though Beacon Object Files represent a different COFF-based approach. Investigators must examine memory regions, thread start addresses, and Sysmon events 7, 8, and 10 rather than relying solely on file artifacts. The method does not bypass DEP, Arbitrary Code Guard, or access-control restrictions and leaves detectable traces when combined with behavioral indicators. Proper detection requires correlating private executable memory with process behavior and avoiding over-reliance on simplified signatures.

SecuritylabOctober 12, 2026Translated from Russian

Read at source

Reflective DLL Injection enables attackers to execute code without placing a suspicious library on disk or registering it through normal Windows module lists. The technique prepares a full working copy of a Portable Executable image directly in process memory, skipping the standard LoadLibrary path.

In a classic reflective scheme, a small loader embedded inside the DLL performs the work normally handled by the Windows loader. It parses its own headers, maps sections, applies base relocations, resolves imports, initializes Thread Local Storage, registers exception tables, and calls entry points. The approach is named after this self-contained preparation step.

What Makes Loading Reflective

Three distinct concepts must be separated: reflective loading prepares the library, manual mapping uses an external loader, and process injection delivers code into another address space. Only the first two affect how the image itself becomes executable; injection adds separate requirements for cross-process access rights.

Ordinary LoadLibrary – Windows loader maps the file and resolves dependencies.
Reflective loading – Code inside the DLL prepares its own working copy from a memory buffer.
Manual mapping – External code performs mapping and relocation instead of the system loader.

Why Raw DLL Bytes Are Not Yet a Working Library

PE images store sections at file offsets that differ from their final RVA locations. A loader must translate between file offsets, relative virtual addresses, and actual virtual addresses while respecting SizeOfRawData versus VirtualSize. Incorrect arithmetic or failure to process relocation records of type HIGHLOW or DIR64 produces corrupted code that may crash later.

Where Simplified Implementations Usually Fail

Common omissions include proper handling of delayed imports, correct OriginalFirstThunk versus FirstThunk tables, full TLS directory processing, and registration of x64 exception unwind data. A function that returns a constant value often succeeds while the first exception or thread-local access triggers an immediate crash.

Memory Artifacts and Detection

Reflective modules frequently appear in MEM_PRIVATE executable regions without corresponding ImageLoad events. Analysts should combine memory-region provenance, thread start addresses, preserved PE headers, and surrounding process behavior. Volatility 3 plugins such as malfind help locate candidate regions, while Sysmon events 7, 8, and 10 provide timeline context when collection is enabled.

Limitations and Protections

The technique respects DEP and can be blocked by Arbitrary Code Guard when the process policy forbids converting memory to executable. It also requires appropriate access rights for cross-process injection and does not grant privileges by itself.

Cobalt Strike Steven Fewer Meterpreter Volatility 3 Sysmon Arbitrary Code Guard

ShareX Facebook LinkedIn Reddit

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Malware & Botnets

Malware & Botnets

Yoba Campaign Uses Signed ChatGPT and Claude Binaries for DLL Sideloading and XMRig Deployment

Researchers at Check Point Research have uncovered the Yoba malware campaign that distributes fake desktop clients for ChatGPT and Claude through GitHub repositories. The attackers bundle legitimate signed executables from OpenAI and Anthropic with a malicious DLL that gets loaded via classic sideloading. Once executed, the loader establishes persistence using the Windows Task Scheduler and retrieves additional payloads through Telegram, DNS over HTTPS, and the Catbox file hosting service. The campaign ultimately deploys the XMRig cryptominer, which pauses mining activity when user interaction is detected to avoid detection. No compromise of OpenAI or Anthropic infrastructure was found; the attackers simply repurpose the companies' signed binaries and reputation. The operation primarily targets home users and small-to-medium businesses with Windows systems.

AntiMalwareOct 28, 2026Translated from Russian

Malware & Botnets

uCreator Spyware Infiltrates Modified Telegram, WeChat and GCash Builds on Android

Security researcher Ovi has published a detailed analysis of uCreator, also known as YingGai, a commercial Android spyware platform designed for surveillance and remote app control. The malware intercepts messages, verification codes and account data directly inside legitimate applications without requiring root privileges. Infection vectors include tampered Telegram, WeChat and GCash APKs distributed through unofficial sources, as well as the Onion Box container that launches the target app inside a controlled environment. Once active, uCreator hooks into the host process, reads Telegram’s local message database through client interfaces, captures two-factor authentication passwords and hides its own session from the user. The operation is supported by cloud-based command panels and exposed GitLab repositories that revealed server-side code and development history. Compatibility problems have been noted on Android 17, and the total number of victims remains unknown.

AntiMalwareOct 26, 2026Translated from Russian

Malware & Botnets

Researchers Deploy Cowrie Honeypot Disguised as NVIDIA H100 Server to Study SSH Botnet Tactics

A cybersecurity team set up a realistic Cowrie honeypot on a fake server equipped with four NVIDIA H100 GPUs, 128 AMD EPYC cores, and terabytes of storage to observe what SSH brute-force bots actually do after gaining access. The trap used a custom StickyAuth module that allowed entry only after several failed attempts and locked in the successful credential pair per IP address. Over the first 12.5 hours the system recorded 1,846 connections from 126 unique IPs, 175 successful logins, and 1,524 commands executed, with the majority of activity traced to a single botnet linked to the Outlaw group. The attackers deployed SSH keys signed mdrfckr, changed the root password, killed competing processes, installed cron jobs, and downloaded a mining archive called dota3 containing an IRC backdoor and its own SSH scanner. The researchers also identified three realism issues in the base Cowrie setup—limited grep flags, outdated filesystem paths in Debian 12, and inconsistent hostname reporting—and patched them to keep sophisticated bots engaged longer. An auxiliary LLM service later summarized each session in Telegram for easier analysis.

HabrOct 25, 2026Translated from Russian