T1620
Reflective Code Loading
Linux · macOS · Windows1 piece on this siteT1620 on attack.mitre.org
Adversaries may reflectively load code into a process in order to conceal the execution of malicious payloads. Reflective loading involves allocating then executing payloads directly within the memory of the process, vice creating a thread or process backed by a file path on disk (e.g., Shared Modules).
Read
Analyses, case studies, guides, references and interview questions.
ReferenceCONSTRUCTED
Memory forensics cheat sheet: acquisition order and the Volatility 3 plugins that answer real questions
What to capture before you touch anything else, how to check the image is usable, and the Volatility 3 plugins grouped by the question they answer, with what each one cannot tell you.
T1620
how MITRE says to see it
Detection Strategy for Reflective Code Loading
- Detect anomalous chains of memory allocation and execution inside the same process (e.g., VirtualAlloc → memcpy → VirtualProtect → CreateThread). Unlike process injection, reflective code loading does not perform cross-process memory writes , the suspicious activity occurs entirely within the process’s own PID...
- Monitor for in-process mmap + mprotect + execve/execveat activity where memory permissions are changed from writable to executable inside the same process without a corresponding ELF on disk.
- Suspicious calls to dlopen(), dlsym(), or mmap with RWX flags in processes that do not typically perform dynamic module loading. Monitor anonymous memory regions executed by user processes.