An EDR solution detects a process loading an unsigned DLL from the user's %TEMP% directory. The process is a legitimate Windows application. What attack technique does this indicate?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — DLL side-loading or DLL search order hijacking is what you're seeing because the attacker placed a malicious DLL where a legitimate signed app loads it instead of the real one. That lets the attacker's code inherit the legitimate process's trust and reputation.
Full Explanation
The DLL side-loading or DLL search order hijacking answer is correct because DLL side-loading exploits the DLL search order; placing a malicious DLL with the expected name in a directory that appears earlier in the search path, like %TEMP%, causes a legitimate signed process to load the attacker's code, inheriting the legitimate process's trust and reputation. The kernel rootkit installing a malicious driver option is wrong because kernel rootkits load drivers through the kernel's driver loading mechanism, not through user-space DLL loading from %TEMP%. The legitimate Windows application caching its DLLs for performance in the temp directory option is wrong because legitimate Windows applications do not cache production DLLs in %TEMP%; they load them from their installation directory or System32. The Windows update package deploying a DLL before installation option is wrong because Windows updates deploy files through the Windows Update service to proper system paths, not unsigned DLLs to user temp directories.