Malware Incidents practice questions

windows.netscan

Why it fails: netscan is used for identifying network connections and sockets.

windows.modules

Why it fails: modules is used for listing loaded kernel modules.

windows.vadyarascan

Why it fails: vadyarascan is used to scan memory ranges for YARA rules.

Sysmon with DNS query logging

Why it fails: Sysmon can log DNS queries made by processes on the endpoint, which is useful for identifying which process is making the queries. However, it does not analyze the content of the DNS traffic for tunneling patterns or decode exfiltrated data. It provides endpoint visibility but lacks the network analysis capabilities to detect tunneling.

Wireshark with a display filter for DNS

Why it fails: Wireshark can capture and filter DNS traffic, but analyzing DNS tunneling requires examining the payload of DNS queries and responses, which may be encoded or encrypted. While Wireshark can show the queries, it does not automatically detect tunneling patterns or decode obfuscated data. It is a general-purpose tool, not specialized for DNS tunneling detection.

A dedicated DNS tunneling detection tool like iodine or dnscat2

Why it fails: Tools like iodine and dnscat2 are used to create DNS tunnels, not to detect them. They are offensive tools used by attackers. Using them for detection would be inappropriate; they would not help in analyzing an existing tunnel unless used in a lab to understand the technique, but they are not detection tools.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Why it fails: This key defines the locations of special folders like Desktop, Start Menu, and Startup. While the Startup folder itself can be used for persistence, the Shell Folders key merely points to those folders. Modifying it could redirect folder paths, but it is not a direct persistence mechanism. Malware would more likely place a shortcut in the Startup folder rather than alter this key.

HKEY_CLASSES_ROOT\exefile\shell\open\command

Why it fails: This key defines the command used to open executable files. While malware could modify it to hijack execution, it is not a common persistence mechanism because it would affect all executables and likely cause system instability. It is more often associated with file association hijacking, not typical persistence. Standard persistence keys like Run are more frequently used.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Why it fails: The Winlogon key contains settings for the Windows logon process, including the Userinit and Shell values. Malware can modify these values to execute code at logon, which is a persistence technique. However, it is less commonly used than the Run and Services keys because it can cause system instability if misconfigured. It is a valid but not among the most common, making it a distractor here.

The user agent string presented during the TLS handshake

Why it fails: The user agent string is an application-layer HTTP header, not part of the TLS handshake, and malware can trivially modify or randomize it. Relying on a user agent for detection is fragile because attackers frequently mimic legitimate browsers, and the value is not visible in TLS metadata without full decryption.

The irregular beaconing interval observed in network flow data

Why it fails: Irregular beaconing is a behavioral characteristic that can suggest malware, but it is not a reliable indicator because legitimate applications also produce irregular traffic patterns. Without a specific destination or certificate to correlate against, irregular timing alone would generate excessive false positives across the enterprise.

The HTTPS port 443 usage and the presence of encrypted traffic

Why it fails: HTTPS on port 443 is used by virtually all legitimate web traffic, so it provides no discriminative value. Encrypted traffic is ubiquitous and cannot by itself distinguish malicious beacons from normal browsing, making this indicator far too broad to generate actionable detections without additional context.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Why it fails: Image File Execution Options (IFEO) can be used for debugging or to redirect executable execution, but it does not control DLL search order. While IFEO can be abused for persistence or execution hijacking, it is not the registry location that defines the DLL search order, so it does not apply here.

HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot

Why it fails: SafeBoot registry keys define which drivers and services are loaded in Safe Mode. They do not influence the DLL search order during normal operation. Examining this key would not help determine if a DLL is being hijacked via search order, making it an incorrect choice for this investigation.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Why it fails: The Run key is used for persistence, not for DLL search order. It specifies programs to run at startup. While malware may use it for persistence, it does not control how DLLs are loaded. Therefore, it is irrelevant for confirming DLL search order hijacking in this scenario.

tcp.port == 80

Why it fails: Port 443 beaconing is filtered with tcp.port == 443; tcp.port == 80 matches HTTP traffic instead, returning nothing relevant. It is tempting because port 80 filtering is standard for isolating cleartext web sessions, and would be correct had the beaconing used HTTP rather than HTTPS.

frame.len > 1000

Why it fails: frame.len filters by total frame size, which is unrelated to destination port or IP, so it would not isolate the beaconing flows. It is tempting because large frames can suggest data transfer, but the reliable filter here is tcp.port == 443 combined with ip.addr == the external IP, matching the actual traffic characteristic described.

http.request

Why it fails: http.request matches HTTP request methods, but port 443 beaconing is typically TLS-encrypted, so Wireshark cannot decode it as HTTP and the filter returns nothing. It is tempting because HTTP analysis is common, yet the correct approach filters on tcp.port == 443 and the external IP address to isolate the beaconing traffic.

Injecting code into explorer.exe

Why it fails: Modifying the Run key achieves persistence via logon execution; it does not inject code into explorer.exe. Process injection writes into another process's memory space using APIs such as CreateRemoteThread. The Run key would be the correct answer when the observed intent is surviving reboots.

Escalating user privileges

Why it fails: Writing to the Run key establishes persistence, causing the malware to execute at user logon; it does not elevate privileges. Privilege escalation exploits vulnerabilities or misconfigured permissions to gain higher rights. This key would be the correct answer when the observed intent is maintaining execution across reboots.

Disabling the Windows Firewall

Why it fails: The Run key launches programs at logon; it does not alter firewall settings. Firewall tampering typically modifies the Windows Firewall service or its policy registry subkeys, such as disabling profiles. The Run key would be the correct answer when the intent is persistence, not network access control.

Scan the backup media with the same AV used previously

Why it fails: Scanning backup media with the same AV that failed to detect the original infection cannot confirm the backups are clean, since that engine already missed the malware. It is tempting because scanning backups sounds prudent, but it would be correct only if the AV signatures were known to detect the specific strain.

Reboot the domain controllers

Why it fails: Rebooting domain controllers neither removes the malware's persistence nor validates backup integrity, and it can disrupt authentication needed for recovery. It is tempting because rebooting feels like clearing an active infection, but it would be the right step only to evict a confirmed resident threat, not before restoring encrypted shares.

Change all user passwords

Why it fails: Changing all user passwords does not address encrypted data or infected backups, and the malware may persist through other mechanisms. It is tempting because credential rotation is standard after a breach, but it would be the right step only where credential theft is confirmed, not as a prerequisite for restoring shares.

condition: $a + $b

Why it fails: The + operator performs arithmetic or string concatenation on values, not logical disjunction, so it cannot combine two match conditions. YARA requires the OR keyword to satisfy either pattern. Addition would be the correct construct when summing numeric values or concatenating strings inside a condition, not for boolean matching.

condition: $a != $b

Why it fails: The != operator tests inequality between two string identifiers, returning true only when their match states differ; it cannot express disjunction. YARA's OR keyword combines match conditions. The != form would be relevant when you specifically need to assert that one pattern matched while another did not.

condition: $a && $b

Why it fails: The && operator requires both $a and $b to match, so files containing only one string are missed; the stem demands OR, which is written with the || operator. It is tempting because && is the natural conjunction for combining conditions, and would be correct if the rule needed files containing both strings simultaneously.

Shut down the computer immediately

Why it fails: Shutting down clears volatile memory, destroying RAM-resident evidence such as running processes and network connections that forensics require. It is tempting as instant isolation, but network isolation via firewall or cable removal preserves memory while containing the host.

Delete the suspicious files

Why it fails: Deleting suspicious files destroys volatile and disk evidence and does nothing to sever the host's live network connections, so the attacker keeps access. It is tempting because removing malware feels like neutralising the threat, but it is an eradication step performed after containment.

Run a full antivirus scan

Why it fails: A full antivirus scan leaves the workstation connected and running, so the attacker retains network access and volatile memory is altered by the scan itself. It is tempting because scanning identifies additional malware, which is useful during later eradication rather than immediate containment.

Brute-forcing system credentials

Why it fails: Process hollowing injects malicious code into a legitimate suspended process so it executes under a trusted image name, evading detection. Brute-forcing credentials is a separate credential-access technique involving repeated authentication attempts, unrelated to memory injection or process replacement.

Encrypting local user files

Why it fails: Process hollowing unmaps a legitimate process's memory and injects malicious code so the payload runs under a trusted image, evading detection; it does not touch user files. Encryption of local files describes ransomware's impact stage, which would be the answer if the stem asked about file-locking extortion rather than stealthy code execution.

Creating a hidden user account

Why it fails: Process hollowing replaces a legitimate process's in-memory code with a malicious payload to masquerade as trusted software; it creates no account objects. Hidden account creation is persistence via directory or SAM manipulation, the correct answer if the stem described an attacker establishing durable credentialed access rather than evading process-level detection.

Use the 'Find Handle or DLL' search bar for the file name

Why it fails: Find Handle or DLL locates which processes hold a named handle or loaded module, useful for tracking file locks or injected DLLs. It returns handle owners, not file reputation. VirusTotal integration, reached via the process's Image properties, is the reputation-checking mechanism.

Right-click the process and select 'Verify Signature'

Why it fails: Verify Signature confirms the embedded digital signature's validity and publisher, proving file integrity and origin but saying nothing about whether the file is known malicious. Reputation requires VirusTotal lookup, available through Options > VirusTotal.com, which queries multi-engine detection results.

Navigate to View > Lower Pane View > Handles

Why it fails: The Handles lower pane lists kernel objects a process has open, such as files, registry keys and mutexes, aiding detection of suspicious resource access. It does not query reputation. VirusTotal submission through the process properties is the mechanism that returns detection verdicts.

Opening a network socket

Why it fails: CreateRemoteThread injects a thread into another process's address space, so the objective is code injection or execution hijacking, not socket creation. It is tempting because remote access implies networking, and socket APIs do feature in malware, but network communication is achieved via Winsock functions such as connect or send, not thread creation.

Deleting files on disk

Why it fails: CreateRemoteThread launches a thread within another process for code injection, not file deletion. It is tempting because destructive malware does erase files, yet that is performed through DeleteFile or similar file APIs; thread creation in a remote process serves execution, not disk modification.

Modifying system time

Why it fails: CreateRemoteThread spawns a thread inside a target process to run injected code; it does not alter the system clock. It is tempting because malware often tampers with time to hinder forensic analysis, but that requires SetSystemTime or SetLocalTime, whereas CreateRemoteThread concerns cross-process execution.

Running a commercial vulnerability scanner

Why it fails: A commercial vulnerability scanner is third-party software, not a built-in operating system utility, so its execution does not constitute LotL. It is tempting because scanners run on hosts, but this would be the correct answer when the question asks about authorised security assessment tooling rather than adversary tradecraft.

Installing a custom rootkit driver

Why it fails: A custom rootkit driver is attacker-installed malware, not a pre-existing signed system binary, so it contradicts the LotL definition of abusing native trusted tools. It is tempting because rootkits are stealthy, but this option would be correct when describing a kernel-level persistence technique rather than LotL.

Downloading an EXE from an unknown site

Why it fails: Downloading an external executable introduces new attacker-supplied code, whereas LotL relies on binaries already present on the host. It is tempting because it is clearly malicious activity, but this option would be correct when the scenario describes a dropper or second-stage payload delivery rather than abuse of native tools.

Wireshark

Why it fails: Wireshark captures network packets traversing an interface, so it cannot acquire volatile memory contents such as running processes, injected code or encryption keys. It is tempting because it is the standard tool for packet-level forensic analysis, and it would be correct when the investigation requires reconstructing network traffic.

Windows Task Manager

Why it fails: Task Manager's memory dump captures only a single process's user-mode address space, not the full physical memory image incident response requires for malware and rootkit analysis. It is tempting because it is built into Windows and needs no installation, and it would suffice for troubleshooting one crashing application.

Event Viewer

Why it fails: Event Viewer displays Windows log records; it captures no process memory, so volatile evidence such as injected code and open network connections is lost. It is used for log review, not acquisition. A dedicated memory-imaging tool is required.

Re-image the computer

Why it fails: Re-imaging is an eradication step, not part of initial investigation.

Delete the file immediately

Why it fails: Deletion removes the sample and its metadata before forensic imaging or hash analysis can occur, and may trigger self-defence routines. It fits confirmed, contained malware on a disposable host. Here, the file's nature is unverified, so preserving it for examination takes precedence.

Execute the file in a debugger

Why it fails: Debugging executes the sample, altering volatile memory, registry keys and timestamps before forensic imaging captures them. It suits controlled malware reverse engineering once an isolated copy exists. Here, running the suspect file on the live system destroys the evidence the investigation needs.

Enable auto-updates for all applications

Why it fails: Auto-updates patch known vulnerabilities in installed software, but fileless malware executes in memory via trusted binaries like PowerShell, leaving no file to update. It is tempting because patch management genuinely reduces exploit surface, and it would be correct hardening against file-based malware exploiting unpatched applications.

Install an extra antivirus

Why it fails: A second antivirus adds no memory-scanning or script-blocking capability beyond the first, and conflicting real-time engines can degrade detection. It is tempting because layered AV sounds like defence in depth, and it would be correct where a single product's coverage gaps leave known file-based threats undetected.

Enable full disk encryption

Why it fails: Full disk encryption protects data at rest if a disk is lost or stolen; it does not prevent fileless malware executing in memory or abusing legitimate tools such as PowerShell. It is tempting because it hardens endpoints generally, but it would be correct when the threat is physical device theft rather than in-memory execution.

Subject line

Why it fails: The Subject line is attacker-supplied text and carries no routing information, so it cannot reveal origin. It is tempting because subjects often contain lure wording useful for classifying a phishing campaign, but header analysis for true origin relies on the Received chain, not on displayed subject content.

Message-ID

Why it fails: Message-ID is generated by the sending mail system and is trivially forged, so it does not establish origin. It is tempting because it uniquely identifies a message for correlation, which suits tracking a campaign across reports, but Received headers record the actual relay path and originating IP.

Content-Type

Why it fails: Content-Type describes the MIME media type of the body or attachments, not the sender's path. It is tempting because it helps identify attached malware payloads during triage, but establishing true origin requires the Received headers showing the originating IP and relay hops.

Spreading via local network shares

Why it fails: DGA produces algorithmically generated domain names for command-and-control resolution, not SMB or share enumeration, so it plays no part in lateral propagation. It is tempting because worm behaviour is commonly bundled with DGA malware, yet DGA would be correct only where the question concerns resilient C2 channel discovery rather than network-share spreading.

Encrypting the malware payload

Why it fails: DGA generates pseudorandom domain names for command-and-control rendezvous, so it never encrypts anything; payload encryption is handled by separate cryptographic routines or packers. It is tempting because DGA output looks like encoded text, but its actual role is resilient C2 infrastructure, making it the right answer only when the question asks how malware evades domain takedowns.

Hiding processes from Task Manager

Why it fails: DGA generates pseudo-random domain names so malware can locate rotating command-and-control servers and evade blocklists; it does not interact with the Windows process list, so it cannot hide processes. It is tempting because evasion is its goal, but process concealment is achieved through rootkit or hooking techniques instead.

TCPView

Why it fails: TCPView enumerates TCP/UDP endpoints and owning processes, not kernel synchronisation objects, so it cannot reveal mutex names. It is tempting because it does identify which process holds a port, which suits network-connection triage rather than mutex discovery, where Handle or Process Explorer is required.

Procmon

Why it fails: Procmon records file, registry, network and process activity; its default filter set excludes the process and thread events that carry mutex create and acquire operations. It is tempting because it is the general-purpose Windows behavioural tracing tool, and it would be correct when the question asks which registry key or file the malware writes during execution.

Autoruns

Why it fails: Autoruns enumerates autostart extensibility points such as Run keys, services and scheduled tasks; it does not list kernel objects like mutexes. It is tempting because it is the standard first tool for triaging persistence on an infected host, and it would be correct when the question asks which mechanism launches the malware at boot or logon.