An attacker uses the technique of 'reflective DLL injection' to load a malicious DLL into a process without touching the disk. What makes this technique particularly effective at evading traditional defenses?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — you're right because reflective injection maps the payload straight into process memory from a buffer, such as a network socket or another process, so there's no file on disk for antivirus or forensics to catch.
Full Explanation
The correct answer is that the malicious DLL is loaded entirely in memory from a network socket or another process, bypassing file-based antivirus scanning and leaving no file artifact on disk for forensic analysis. Reflective DLL injection implements its own loader inside the payload, mapping it into process memory from a buffer without writing it to disk, evading file-based AV and file system monitoring. The signed Windows DLL claim is wrong because reflective injection uses a malicious custom DLL, not a legitimate signed DLL. The 32-bit-only claim is wrong because it works on both 32-bit and 64-bit processes, and modern EDR monitors both. The kernel-driver claim is wrong because reflective injection operates in user-space via Windows API calls and does not require kernel driver access.