Malware Analysis & Forensics
Static vs dynamic analysis, fileless malware, Windows/Linux persistence artifacts, memory vs disk forensics, sandbox detonation, anti-analysis, process injection and IOC extraction.
11 questions
JuniorTheoryVery commonWhat does static malware analysis reveal, what does dynamic analysis reveal, and what does each miss?
What does static malware analysis reveal, what does dynamic analysis reveal, and what does each miss?
Static analysis reads the sample without running it — strings, imports, headers — so it is safe, but packing hides the real payload. Dynamic analysis detonates it in an isolated lab and shows real behaviour, but only on the paths that executed.
Common mistakes
- ✗Treating a clean static pass as conclusive on a packed sample
- ✗Detonating a sample outside an isolated lab because it looked inert
- ✗Assuming one detonation exercised every code path in the sample
Follow-up questions
- →Which first-pass static signals suggest that a sample is packed?
- →Why must a detonation lab be isolated from production networks and credentials?
MiddleTheoryVery commonWhy is memory captured before disk, and what evidence exists only in a memory image?
Why is memory captured before disk, and what evidence exists only in a memory image?
Order of volatility — RAM is lost at power-off, disk is not. A memory image holds what never reached disk: injected code, decrypted payloads, live connections, full command lines and loaded modules. Capture memory first, then image the disk.
Common mistakes
- ✗Rebooting or powering off a suspect host before memory is captured
- ✗Assuming a page file substitutes for a full memory image
- ✗Reading order of volatility as a legal rule rather than an evidence-loss rule
Follow-up questions
- →What are the risks of imaging memory from inside the compromised host itself?
- →Which fileless artifacts would you look for first inside a memory image?
MiddleTheoryCommonHow do you triage a Linux host for a running process whose executable is not on disk?
How do you triage a Linux host for a running process whose executable is not on disk?
Walk /proc. Compare each process's exe link against the file system — a deleted or memfd target means the binary is gone or never landed on disk. Read the memory maps for anonymous executable regions and cmdline for launch context, then capture memory.
Common mistakes
- ✗Assuming a Linux process must have a matching file on disk
- ✗Rebooting the host before its memory has been captured
- ✗Reading a missing binary as a listing glitch rather than a signal
Follow-up questions
- →What does a deleted target on the exe link tell you about the loader?
- →Which volatile artifact do you collect before the host is isolated?
MiddleTheoryCommonWhich Windows artifacts do you hunt for persistence, and which of them survive as indicators?
Which Windows artifacts do you hunt for persistence, and which of them survive as indicators?
Run keys, startup folders, scheduled tasks, services, event subscriptions. The hash and path an entry points at rotate cheaply, so what survives is the pattern — a task running hidden encoded PowerShell, or a service binary in a user-writable folder.
Common mistakes
- ✗Building the fleet-wide hunt on the sample hash alone
- ✗Checking the registry only and skipping tasks, services and subscriptions
- ✗Assuming one removed entry means the persistence is gone
Follow-up questions
- →How would you tell a legitimate scheduled task from a hostile one at fleet scale?
- →Which telemetry must exist before a behavioural persistence hunt is possible?
MiddleTheoryCommonWhat is process injection, and which host observations expose it during triage?
What is process injection, and which host observations expose it during triage?
Code running inside another process so it inherits that identity and trust. Triage signals are structural — memory that is both writable and executable, a mapped image not matching the file on disk, and a child process whose parent makes no sense.
Common mistakes
- ✗Trusting a process by its name and signature after its memory was modified
- ✗Expecting a new file on disk in every injection case
- ✗Ignoring a parent-child chain that does not match normal software
Follow-up questions
- →Which legitimate software also writes into another process's memory?
- →What does a memory image add that a live process listing cannot show?
SeniorTheoryCommonHow do you extract indicators from a confirmed sample and pivot to a fleet-wide hunt?
How do you extract indicators from a confirmed sample and pivot to a fleet-wide hunt?
Extract inside the isolated lab, and unpack first so the indicators come from the payload, not the stub. Record the brittle values — hashes, domains, addresses — but hunt on durable behaviour, because a hash is rotated far more cheaply than a technique.
Common mistakes
- ✗Extracting indicators from the packed stub instead of the unpacked payload
- ✗Uploading a customer artifact to a public scanning service
- ✗Scoping the whole intrusion on file hashes alone
Follow-up questions
- →Which telemetry must exist before a behavioural hunt can run across the fleet?
- →When do you stop analysing in-house and escalate to a specialist team?
JuniorDebuggingOccasionalAn autoruns export from a suspect Windows host is below — identify the persistence mechanisms.
An autoruns export from a suspect Windows host is below — identify the persistence mechanisms.
Two entries are hostile. The Run value named OneDriveUpdate launches an unsigned svchost.exe from the user profile — a system binary name in a writable path. The task SystemCheck runs hidden encoded PowerShell every 30 minutes. Preserve evidence first.
Open full question →Common mistakes
- ✗Reading a system binary name as proof that the file is a system binary
- ✗Deleting the persistence entries before any evidence is preserved
- ✗Treating persistence removal as the end of the incident
Follow-up questions
- →Which volatile artifact would you capture before touching either entry?
- →How would you check whether other hosts carry the same scheduled task?
MiddleTheoryOccasionalWhy does file-scanning antivirus miss fileless attacks run through PowerShell or Windows Management Instrumentation?
Why does file-scanning antivirus miss fileless attacks run through PowerShell or Windows Management Instrumentation?
Because there is no malicious file to scan. The payload lives in memory or in a registry value and runs through signed system binaries, so the evidence is behavioural — command lines, parent-child chains and script-block logs, not a hash on disk.
Common mistakes
- ✗Reading a clean antivirus verdict as ruling out an in-memory payload
- ✗Trusting a signed system binary because its signature validates
- ✗Hunting only for files when the real artifact is a command line
Follow-up questions
- →Which log sources give you the full command line of a
PowerShellchild process? - →Where can the management interface
WMIhold persistence with no file on disk?
MiddleTheoryOccasionalAn endpoint detection and response (EDR) alert flags an injection sequence — how do you tell it from legitimate software?
An endpoint detection and response (EDR) alert flags an injection sequence — how do you tell it from legitimate software?
By context, not by the call itself. Ask what the source process is, whether it is signed and normally does this, and what followed — a network connection or credential access. A document handler injecting into a system process is anomalous.
Common mistakes
- ✗Treating the API name in the alert as the verdict on its own
- ✗Downgrading an alert only because the target is a system process
- ✗Judging the alert without looking at what happened next
Follow-up questions
- →Which follow-on activity would raise an injection alert into an incident?
- →How would you baseline the legitimate injectors present in your own estate?
MiddleTheoryOccasionalWhich signals say a sample is packed, and what does that mean for your analysis workflow?
Which signals say a sample is packed, and what does that mean for your analysis workflow?
High, uniform entropy across a section, almost no readable strings, and an import table holding only a few loader functions. Packing means the static pass is reading a stub, not the payload, so unpack it or detonate it and recover the code from memory.
Common mistakes
- ✗Reading an empty strings output as evidence that the file is harmless
- ✗Treating high entropy as proof of malice rather than of compression
- ✗Continuing static analysis on the stub as if it were the payload
Follow-up questions
- →Which legitimate software also ships with packed or compressed sections?
- →How would fuzzy hashing help you group packed samples that share a payload?
MiddleTheoryOccasionalA sandbox report shows no malicious activity — why is that not proof the sample is clean?
A sandbox report shows no malicious activity — why is that not proof the sample is clean?
Because a sample can check where it runs and stay quiet when the answer is wrong — a short run window, a missing domain, no user activity, an absent file. The report says only that nothing fired there, so vary the environment or fall back to static analysis.
Common mistakes
- ✗Closing a case on a single clean sandbox verdict
- ✗Assuming a longer run in the same environment settles the question
- ✗Forgetting that static analysis still applies after an inconclusive detonation
Follow-up questions
- →Which environment differences most often keep a sample quiet inside a sandbox?
- →When would you escalate an inconclusive sample to a reverse-engineering specialist?
