A threat runs only in memory with no file on disk. How do you analyze it?
Short answer
Fileless malware lives in process memory (injection, reflective loading, LOLBins), so acquire and analyze a memory image to find the injected code, suspicious modules, and process relationships. A disk AV scan and a clean disk tell you nothing about an in-memory implant. The recycle bin is irrelevant. Memory forensics is the right tool when there's no file to triage, and you should capture before the host is rebooted.
Fileless threats are designed to defeat the disk-centric instincts of weaker analysts. The interviewer is checking whether you know where the evidence actually lives when there's nothing to copy off the filesystem — and that you act before it evaporates.
Why memory capture and analysis is correct
By definition the malicious code never lands as a file on disk. Instead it runs in process memory via techniques like process injection, reflective DLL loading, or living-off-the-land binaries (LOLBins) such as PowerShell and WMI. The only place to find it is RAM, so you acquire a memory image of the affected host and analyze it: hunt for injected code in legitimate processes, in-memory modules with no backing file on disk, anomalous process trees (e.g., Office spawning a script interpreter), network connections, and command lines. Because memory is volatile, you capture it before rebooting — a shutdown erases your only artifact. This is exactly what memory forensics exists for.
Why the other options are wrong
- Run a disk AV scan and trust it. A disk scan can't see code that isn't on disk. A clean scan here is a false reassurance — the implant is sitting in RAM, untouched.
- Conclude nothing is wrong because the disk is clean. This is the trap the malware is built to spring. "Disk clean" is meaningless against a fileless threat; absence on disk is evidence of the technique, not of safety.
- Check the recycle bin. The recycle bin holds deleted files. There is no file involved, so this is pure wasted motion while volatile evidence drains away.
What interviewers look for
The senior signal is naming the collection ordering and the technique set: capture memory first because it's volatile, then look for injection, reflective loading, and LOLBin abuse in the process tree. Strong candidates connect this to EDR telemetry and live-response tooling, and they explicitly call out that rebooting the host to "fix" it would destroy the only evidence — a mistake a junior under pressure often makes.
Likely follow-ups
- What injection techniques (process hollowing, reflective DLL, APC) would you look for in the memory image, and how do they appear?
- Why does rebooting or shutting the host down destroy your best evidence here, and how do you preserve it?
- Which LOLBins or living-off-the-land patterns commonly enable fileless execution, and how would you detect them?