Malware Analyst / Reverse Engineer interview questions

No. The EICAR test file is a deliberately harmless 68-byte ASCII string that every AV vendor agrees to detect, so you can safely verify detection and alerting without touching real malware. A hit means your AV is working — not that you are infected. It is not a virus and does nothing if executed. Mistaking an EICAR test detection for a real infection is a common early-career gotcha.

The SOC needs to act, so deliver structured, actionable detection content: network IOCs, hashes, host artifacts like the mutex, and behavioral or YARA signatures they can deploy to hunt and block. An exhaustive API narrative isn't directly operational. A single hash is trivially changed by attackers. Speculative attribution isn't something the SOC can defend with. The goal is detections the SOC can ship today.

Detonate only in a disposable, isolated VM with snapshots and a controlled network (e.g., simulated services or tightly monitored egress) so the malware can't reach production or the internet uncontrolled. AV on your laptop won't reliably contain live malware. A production server risks real systems. A colleague's machine just moves the danger. Isolation and revertable snapshots are the core of a safe malware lab.

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.

Family identification drives decisions: from the note, extension, and IOCs you can flag whether a free decryptor exists, the group's typical TTPs (including data theft for extortion), and the likely blast radius, feeding the IR team. Reformatting destroys evidence and scope information. Note grammar isn't actionable. Recommending negotiation is a business and legal decision, not the analyst's first move. Identify first, then enable IR.

Use simulated network services or a tightly monitored, attributable-safe egress so you can study C2 behavior without revealing your real IP to the attacker or letting the host be tasked with harmful commands. Interacting from the corporate IP tips off the operator and risks real harm. Bridging the sandbox to the LAN invites spread. Disabling logging throws away the analysis data. Control the network so you observe without exposing or being weaponized.

Packing hides the real code, so high entropy plus stripped imports is a sign to unpack — detect the packer and dump the unpacked image from memory once the loader has executed, then analyze the real payload. Unreadable strings are evidence of evasion, not of being benign. Calling it a false positive or renaming the extension ignores an actively obfuscated sample. The obfuscation itself is a strong malicious indicator worth investigating.

Malware commonly checks for VM/sandbox artifacts, short run times, or user interaction and stays dormant when it sees them. Disguise and harden the analysis VM, lengthen execution, or move to bare metal, and pull behavior from a memory image of the live host. Assuming it's broken or that the host was wrong ignores a sample proven malicious in the wild. A reboot changes nothing because the evasion logic still fires every run.

Begin with static triage in an isolated environment: compute hashes, pull strings, inspect PE headers and imports, and check reputation, so you understand the sample before risking execution. Running it on your own workstation can infect you and the network. Uploading client samples with identifying names leaks sensitive data to third parties. Deleting it destroys the evidence and the chance to build detections.

Persistence is how malware survives reboots and logoffs. The staples on Windows are registry Run/RunOnce keys (HKLM and HKCU), scheduled tasks, and Windows services, plus startup folders, WMI event subscriptions, and DLL hijacks. You hunt them with autoruns/Sysinternals, Sysmon, and event logs — looking for unsigned binaries, odd paths like %AppData%, and entries created right after initial compromise.

Process injection runs attacker code inside the memory space of a legitimate process so the activity blends in and inherits that process's trust. Classic techniques include DLL injection (CreateRemoteThread + LoadLibrary), process hollowing (start a benign process suspended, unmap it, write malicious code), and APC injection. Defenders detect it via EDR API hooks, anomalous parent/child or memory regions (RWX, unbacked executable memory), and Sysmon CreateRemoteThread events.

Static analysis examines a sample without executing it — hashes, strings, imports, headers, and disassembly — so it is safe and complete in coverage but defeated by packing and obfuscation. Dynamic analysis detonates the sample in an isolated sandbox and observes real behavior — files, registry, processes, network — which cuts through obfuscation but only reveals what runs in that session and can be evaded by sandbox-aware malware. Analysts combine both.

You classify by what the sample is built to do, observed from its behavior and capabilities. A dropper carries and writes a payload to disk; a loader fetches or injects the next stage, often only in memory; a RAT gives an operator interactive remote control; a wiper destroys data or boot records with no recovery intent; ransomware encrypts files and demands payment. Real samples often combine roles — a loader that deploys a RAT — so you describe the capability chain rather than forcing one label, and you map each behavior to ATT&CK techniques.

A disassembler like Ghidra or IDA gives you the full static map: cross-references, decompiled pseudocode, and every code path whether or not it runs. A debugger like x64dbg lets you execute the sample under control — set breakpoints, inspect registers and memory, watch decryption happen, and follow the path the code actually takes with real inputs. You read structure and intent statically, then attach the debugger to resolve what static analysis cannot: runtime-decrypted strings, dynamically resolved APIs, packed payloads, and which branch a condition takes. The two together close each other's gaps.

Command-and-control beaconing is the implant periodically calling home for instructions. You recognize it by regular, low-volume outbound callbacks at a roughly fixed interval — often with jitter to avoid looking mechanical — to a small set of destinations, frequently over HTTP/HTTPS or DNS with encoded or encrypted payloads and a distinctive User-Agent or URI pattern. You extract indicators statically by pulling domains, IPs, URIs and keys from strings and config blocks, and dynamically by detonating the sample against a faked network and capturing the actual callbacks, then map the behavior to ATT&CK and feed the IOCs into detection.

Packing compresses or encrypts the real payload and prepends a stub that unpacks it into memory at runtime; obfuscation transforms the code or data to resist reading and signatures. You detect packing from high section entropy near 8.0, a tiny or stub-only import table, unusual or writable-executable section names like UPX0, an entry point that sits outside .text, a large virtual size versus small raw size, and detectors like Detect It Easy or PEiD. None of these is conclusive alone, so analysts weigh several signals together and confirm by observing the unpack at runtime.

A PE file starts with the DOS header and its e_lfanew pointer to the PE/NT headers, which hold the File Header and Optional Header (entry point, image base, subsystem). It is divided into sections — .text for code, .data, .rdata, .rsrc for resources — each with a virtual address and raw size. During triage you read the import table for suspicious APIs, the section table for odd names and high entropy that hint at packing, the timestamp and rich header, embedded resources, and any digital signature. Mismatches between these tell you a lot before you ever run the file.

Process injection runs malicious code inside another process to hide and to inherit trust. Classic remote injection allocates memory in a target with VirtualAllocEx, writes a payload via WriteProcessMemory, and runs it with CreateRemoteThread. Variants include DLL injection via LoadLibrary, process hollowing that unmaps a suspended legitimate process and replaces its image, APC injection that queues code to a thread, and reflective or manual-mapped loading that avoids LoadLibrary entirely. You spot them by the telltale API sequences, RWX memory in a normally-clean process, threads with no backing file on disk, and parent-child anomalies.

A safe lab isolates the malware from anything it could harm. You run samples in disposable VMs on a hypervisor, take clean snapshots so you can revert after each detonation, and cut off real network access using a host-only network with a simulated internet (INetSim or FakeNet) or an air-gapped segment. You separate the analysis machine from a controlled gateway, never analyze on your daily-driver host, harden against VM-escape, handle samples as password-protected zips, and keep tooling and indicators off the detonation VM. The goal is to observe real behavior while guaranteeing the sample cannot reach production or the internet.

Sandbox-aware malware checks whether it is being watched before it misbehaves. It looks for VM and hypervisor artifacts (drivers, MAC prefixes, registry keys, CPUID), analysis tools and debuggers (process names, IsDebuggerPresent, timing of single-stepping), and signs of a real user (few processes, no recent documents, no mouse movement, low uptime, small disk). It may stall with long sleeps or only fire on a specific date, language, or domain. Analysts counter by hardening the VM to look real, patching out the checks, fast-forwarding sleeps, simulating user activity, and confirming behavior with static disassembly.

Static tooling reads the sample at rest: PEStudio, CFF Explorer and pefile for headers and imports, FLOSS and strings for embedded text, capa for capability mapping, and Ghidra or IDA for disassembly. Dynamic tooling watches it run inside an isolated VM: Procmon and Process Hacker for host activity, Wireshark and INetSim or FakeNet for faked network, Regshot for before/after diffs, and x64dbg for controlled stepping. The workflow is triage statically, detonate dynamically, then return to the disassembler to fill behavioral gaps.

Unpacking recovers the original code the packer hid. For known packers you use the matching unpacker or an emulator. For custom packers you unpack manually: run the sample in a debugger, let the stub decompress the payload into memory, find the moment it jumps to the original entry point (often by breaking on memory that becomes executable, or on the tail jump), then dump the process image from memory and rebuild the import address table with a tool like Scylla or PE-sieve. The result is a runnable or analyzable PE containing the real payload.

A YARA rule has a meta block, a strings section (text, hex, or regex patterns, including wildcards and jumps), and a condition that combines those matches with boolean and count logic. An effective rule keys on something durable and distinctive — a unique code stub, a mutex name, a config marker, or an unusual import combination — rather than on values an attacker trivially changes like a single hash or a generic string. You balance specificity against false positives, test against a clean corpus, and document the rule so others trust and maintain it.