EDR shows a validly signed vendor executable in a user's temp folder loading an unsigned DLL sitting next to it. How do you analyze it?
Short answer
Treat it as probable DLL side-loading. The signature covers the executable, not the DLL that Windows resolves from the application's own folder, so a trusted binary can be made to run attacker code. Analyse the DLL itself (hash, exports, imports, behaviour), confirm the process normally lives elsewhere, hunt for other copies of the pair, and don't clear the alert on the EXE's reputation.
The trap in this scenario is the word "signed". A valid signature on an executable is evidence about that file only.
Why side-loading is the likely explanation
MITRE ATT&CK describes DLL side-loading as planting a malicious payload next to a legitimate application and then invoking that application so it executes the attacker's code. Microsoft documents why this works: when an unpackaged app loads a DLL without a full path, the loader checks (after redirection, API sets, SxS manifest redirection, the loaded-module list and known DLLs) the folder the application loaded from before the system folder. Microsoft also warns that if an attacker controls one of the searched directories, they can place a malicious copy of the DLL there. A copy of a signed vendor EXE dropped in a user-writable folder with a DLL beside it fits exactly.
Triage steps
- Isolate and preserve the pair and note the full path; a vendor tool normally lives under a trusted install location.
- Analyse the DLL: hash, signature (or lack of one), compile time, exports compared with the genuine library, imports, strings, and what it spawns or connects to in a sandbox.
- Check the process tree and timeline: how did both files arrive (archive, email, download)?
- Hunt for the same hash, filename pair or path pattern across the fleet.
Mitigations to mention
MITRE lists application control that blocks suspicious DLL loads, hardening with hash values in manifests, and keeping safe DLL search mode enabled.
Why the distractors fail
- "Inherits trust" and "reputation of the EXE" both judge the wrong file.
- "Delete and restart" destroys evidence and leaves the delivery path and other copies unexamined.
What interviewers want
Recognition that signed does not mean safe in context, plus a disciplined path: DLL analysis, path and provenance, fleet hunt.
Likely follow-ups
- Which directories does Windows search before the system folder, and what are KnownDLLs?
- How would you confirm the DLL's exports mimic the legitimate library while adding malicious code?
- What detections would you write for a signed binary running from a user-writable path?