Quick links
Press Enter to search, Esc to close
Attack technique
Reflective code loading is a way for malware to run a program straight from memory, without starting a new process or putting the program on disk as a normal file.
In short
Reflective code loading is a way for malware to run a program straight from memory, without starting a new process or putting the program on disk as a normal file. The payload can stay encrypted until the moment it runs. MITRE ATT&CK lists it as a Stealth technique.
Stealth · Step 7 Of 15 In The Attack Chain
MITRE says attackers can load code into a process in order to hide the execution of malicious payloads. The payload is allocated and run inside the memory of a process, instead of a thread or process that is backed by a file on disk.
The payload can be a compiled program, a file that exists only in RAM, or a small piece of position-independent shellcode. MITRE gives the .NET method Assembly.Load() run from PowerShell as one example.
It looks like process injection, but the code goes into the process’s own memory, not into another process. MITRE adds that this can slip past process-based detections, avoid files on disk, and let the malware keep its payload encrypted until it runs.
MITRE lists many users of this technique, among them Kimsuky, APT38, Lazarus Group, Cobalt Strike and PlugX. A current case comes from Symantec's researchers. In an intrusion at a naval shipbuilder, attackers ran a loader called ld.exe with an encrypted file and a key given on the command line. The loader decrypts the file in memory and calls an exported function named ExecuteLoader. The payload was not recovered, so what it did is unknown. The case is part of our HOOKEDGE backdoor profile. Symantec attributes the activity to Swallowtail, also known as APT28.
MITRE suggests looking for a chain such as allocating memory, copying data in, changing its protection and starting a thread, all inside the same process. No other process is involved, which separates it from injection.
On Linux, MITRE suggests watching a process that changes memory from writable to executable with mprotect and then calls execve or execveat, with no matching file on disk.
MITRE also lists calls such as dlopen, dlsym or mmap with read, write and execute flags, in programs that do not normally load modules this way. Anonymous memory regions that run are another sign.
DET0300, Detection Strategy for Reflective Code Loading, with analytics AN0838, AN0839 and AN0840.
This step is our own suggestion, not from MITRE. Turn on PowerShell script block logging and search event 4104 in the Microsoft-Windows-PowerShell/Operational log for calls to Assembly.Load. The Load(Byte[]) form takes an assembly from memory, so a call that passes a byte array deserves a close look.
MITRE says this technique cannot be easily mitigated with preventive controls, because it abuses normal system features.
Reflective loaders still need a way in. In the HOOKEDGE case that was a macro-enabled Word document, so Recorded Future's advice to block macros from internet-originated documents removes the first step.
A program run from a user or ProgramData folder with an encrypted file and a long key as arguments deserves a look. Symantec describes exactly this for ld.exe.
It is running a payload from the memory of a process, instead of from a file on disk or a separate process. The payload can stay encrypted until it runs.
MITRE says it is very similar to process injection. The difference is that the code is loaded into the process's own memory, not into another process.
MITRE suggests watching for memory that is allocated, filled, made executable and run inside the same process, and for unusual use of dynamic loading calls.
No. MITRE says the technique cannot be easily mitigated with preventive controls. Defenders block the delivery step and watch behavior.
Take control of your digital security with an exclusive demo of our AI-driven threat intelligence platform.
