A sophisticated technique that allows attackers to execute malicious code directly in memory is gaining traction, posing a significant challenge to modern Endpoint Detection and Response (EDR) solutions.
This method, which involves an in-memory Portable Executable (PE) loader, enables a threat actor to run an executable within an already trusted process, effectively bypassing security checks that primarily monitor files written to disk.
According to a user with the alias G3tSyst3m, the technique highlights a critical blind spot in some security postures, allowing secondary payloads to be deployed stealthily after initial access is gained.
This “fileless” attack vector is particularly dangerous because it operates under the radar. An EDR solution may validate and approve an initial application, deeming it safe to run.
However, once that trusted process is active, it can be manipulated to download and execute another PE file, such as a remote access trojan or info-stealer, entirely within its own memory space.
Because the malicious executable never touches the file system, traditional antivirus and EDR tools that rely on file scanning and disk-based heuristics may fail to detect the threat.
In-Memory PE Loader Leveraged
The attack begins by leveraging the legitimate process to download a PE file from a remote source, such as a GitHub repository.
Using standard Windows APIs like InternetOpenUrlA and InternetReadFile, the code fetches the executable and stores it in a memory buffer.
This initial step is often mistaken for delicate network activity, allowing the payload to be smuggled onto the target system without raising alarms. Once the PE file resides in memory as a byte array, the loader meticulously reconstructs it for execution.
This reconstruction process manually emulates the functions of the Windows operating system’s own loader. At a high level, the loader performs several critical steps:
- Parses PE Headers: It reads the DOS and NT headers of the downloaded file to understand its structure, including its sections and dependencies.
- Allocates Memory: It uses
VirtualAllocto reserve a new block of memory within the host process to map the executable image. - Maps Sections: The loader copies the PE headers and sections (like
.textfor code and.datafor variables) from the buffer into the newly allocated memory space according to their virtual addresses. - Resolves Imports: It loads any required Dynamic-Link Libraries (DLLs) and resolves the addresses of external functions the PE needs to run. This is done by using
LoadLibraryAandGetProcAddress. - Applies Relocations: It adjusts any hardcoded addresses in the code to ensure they point to the correct locations in memory.
After successfully mapping the PE file and resolving its dependencies, the final steps involve adjusting memory permissions and triggering execution.
The loader uses VirtualProtect to set the appropriate permissions for each section, for instance, marking the code section as executable and the data section as readable/writable.
This mirrors the behavior of a legitimately loaded program and is crucial for the code to run without crashing the process. With the memory correctly prepared, the loader simply calls the PE file’s entry point, launching the malicious code.
This method has proven effective in red team engagements and has been observed bypassing prominent EDR solutions like Microsoft Defender for Endpoint (XDR) and Sophos XDR.
While not entirely foolproof, especially against advanced AI and machine learning-based detection that can flag anomalous process behavior over time, custom-built PE loaders remain a potent tool for evading detection.
The technique underscores the need for security solutions that can perform deep memory inspection and behavioral analysis, moving beyond a reliance on file-based threat intelligence.
Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.
The post Hackers Can Bypass EDR by Downloading Malicious File as In-Memory PE Loader appeared first on Cyber Security News.
.webp)
.webp)