- AN0838 · Analytic 0838 — 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 context.
- AN0839 · Analytic 0839 — 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.
- AN0840 · Analytic 0840 — 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.
AdversaryGraph public intelligence page
This page is part of Threat Matrix, the public browser workspace for the main AdversaryGraph platform. Use it for ATT&CK pivots, actor and technique context, similarity leads, detection coverage review, and analyst-ready investigation paths.
Validation disclaimer: TTP overlap, actor similarity, generated summaries, and coverage findings are investigation leads, not attribution proof or operational validation without analyst review.
Main AdversaryGraph project Documentation Malware Analysis GitHub
Reflective Code Loading
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). Reflectively loaded payloads may be compiled binaries, anonymous files (only present in RAM), or just snubs of fileless executable code (ex: position-independent shellcode). For example, the `Assembly.Load()` method executed by PowerShell may be abused to load raw code into the running process. Reflective code injection is very similar to Process Injection except that the “injection” loads code into the processes’ own memory instead of that of a separate process. Reflective loading may evade process-based detections since the execution of the arbitrary code may be masked within a legitimate or otherwise benign process. Reflectively loading payloads directly into memory may also avoid creating files or other artifacts on disk, while also enabling malware to keep these payloads encrypted (or otherwise obfuscated) until execution.
Open detection, hunting, mitigation, and evidence workspace
Detection logic
Monitor for code artifacts associated with reflectively loading code, such as the abuse of .NET functions such as Assembly.Load() and Native API functions such as CreateThread(), memfd_create(), execve(), and/or execveat(). Monitor for artifacts of abnormal process execution. For example, a common signature related to reflective code loading on Windows is mechanisms related to the .NET Common Language Runtime (CLR) -- such as mscor.dll, mscoree.dll, and clr.dll -- loading into abnormal processes (such as notepad.exe). Similarly, AMSI / ETW traces can be used to identify signs of arbitrary code execution from within the memory of potentially compromised processes. Analyze process behavior to determine if a process is performing actions it usually does not, such as opening network connections, reading files, or other suspicious actions that could relate to post-compromise behavior.
Observed actors
Correlated CTI and IR reports
Cyber Knowledge context
Use these routes to move from the ATT&CK behavior into explanation, implementation, evidence handling, validation, and defensive operations. Relevance is generated from explicit identifiers/names and governed topic mappings; it is not attribution evidence.
Android malware and mobile application behavior
Malware Analysis & Reverse Engineering · Governed topic match · 51/100Controlled dynamic behavior and differential observation
Malware Analysis & Reverse Engineering · Tactic learning route · 24/100Module 4 — Detection engineering and detection as code
Blue Team & Defensive Security · Tactic learning route · 24/100Disk, file-system, and persistence forensics
Digital Forensics & Incident Response (DFIR) · Tactic learning route · 24/100
Malware Analysis & Reverse Engineering · Governed topic match · 51/100Controlled dynamic behavior and differential observation
Malware Analysis & Reverse Engineering · Tactic learning route · 24/100Module 4 — Detection engineering and detection as code
Blue Team & Defensive Security · Tactic learning route · 24/100Disk, file-system, and persistence forensics
Digital Forensics & Incident Response (DFIR) · Tactic learning route · 24/100
MITRE mitigations
No ATT&CK mitigation relationship is published for this technique. Apply risk-based controls and verify scope.