Reflective DLL Injection: How Malware Executes DLLs Directly in Memory Without Disk Files
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.
Related articles
Freshko: Open-Source Rust Tool Offers Local File and URL Scanning Without Data Upload
A developer has released Freshko, a compact 400x640 pixel desktop application built in Rust that performs quick local checks on files, folders, and URLs without sending data to external services. The tool uses YARA-X rules for file scanning, follows up to eight redirects while querying Cloudflare's filtering DNS, and scores processes for potential cryptocurrency miners based on names, arguments, and launch paths. It explicitly avoids acting as a full antivirus solution, instead providing transparent results that list any skipped items or incomplete checks. Freshko runs on macOS and Windows, keeps all scan results in memory only, and disables system proxies during URL checks to prevent DNS rebinding attacks. The project includes performance benchmarks on Apple Silicon and addresses common pitfalls such as high CPU usage false positives and incomplete disk scans. Unlike VirusTotal or Cloudflare URL Scanner, Freshko performs all file analysis locally and never makes scan reports public.
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.
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.
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.