Malware Forensics practice questions

During a malware investigation, an analyst discovers a suspicious file with a hash value that matches known malware. However, the file fails to execute and does not exhibit any malicious behavior in a sandbox. What is the most likely reason for this discrepancy?

Trap 1: The file is a false positive and is actually benign

A false positive would mean the file was incorrectly flagged as malicious, but here the analyst matched the file's cryptographic hash against known malware samples. Hash matching is deterministic and near-collision-free; matching a known malicious SHA-256 for the entire file content is overwhelmingly strong evidence of maliciousness, not a false positive. The sandbox's failure to exhibit behavior does not negate static certainty.

Trap 2: The sandbox is not updated with the latest signatures

Sandbox signature updates are irrelevant because the analyst already identified the file through a hash match, which does not rely on the sandbox's signature database. Even if the sandbox were outdated, the static hash ensures the binary is the same known malware, and modern sandboxes primarily use dynamic behavioral analysis rather than signature lookups. An outdated signature set cannot explain why the sandbox observed no malicious behavior when the file is genuinely malicious.

Trap 3: The file's metadata has been modified to evade analysis

Modifying metadata such as PE timestamps, version strings, or section names would alter the file's content and thus change its cryptographic hash, contradicting the observed match to known malware. Additionally, common metadata fields are not used for execution; altering them would not prevent a sandbox from running the file's code or unpacking it. For the hash to match, the file must be byte-for-byte identical to the known sample, so no metadata manipulation has occurred.

A
The file is a false positive and is actually benign
Why it fails: A false positive would mean the file was incorrectly flagged as malicious, but here the analyst matched the file's cryptographic hash against known malware samples. Hash matching is deterministic and near-collision-free; matching a known malicious SHA-256 for the entire file content is overwhelmingly strong evidence of maliciousness, not a false positive. The sandbox's failure to exhibit behavior does not negate static certainty.
B
The sandbox is not updated with the latest signatures
Why it fails: Sandbox signature updates are irrelevant because the analyst already identified the file through a hash match, which does not rely on the sandbox's signature database. Even if the sandbox were outdated, the static hash ensures the binary is the same known malware, and modern sandboxes primarily use dynamic behavioral analysis rather than signature lookups. An outdated signature set cannot explain why the sandbox observed no malicious behavior when the file is genuinely malicious.
C
The file's metadata has been modified to evade analysis
Why it fails: Modifying metadata such as PE timestamps, version strings, or section names would alter the file's content and thus change its cryptographic hash, contradicting the observed match to known malware. Additionally, common metadata fields are not used for execution; altering them would not prevent a sandbox from running the file's code or unpacking it. For the hash to match, the file must be byte-for-byte identical to the known sample, so no metadata manipulation has occurred.
D
The file is packed or obfuscated to prevent execution in a sandbox
Packed or obfuscated malware contains an unpacking stub that decodes the actual malicious payload only at runtime, and attackers often add anti-sandbox checks (e.g., VM detection, timing delays, missing user interaction) before executing that stub. In an automated sandbox, these checks may fail or time out, so the payload is never unpacked and no malicious behavior is observed. The static hash still matches known malware because packing is part of the file itself; the sample's dynamic evasion prevents behavioral confirmation without altering its identity.

Question 2easymultiple choice

A security analyst is tasked with reverse engineering a suspected malware sample. Which initial step should the analyst take to ensure safe handling and prevent accidental infection?

Trap 1: Execute the sample in a debugger on a production machine

Executing the sample under a debugger on a production machine is dangerous because the machine is not isolated and the malware may detect the debugger or immediately trigger its payload, causing file encryption, data exfiltration, or lateral movement across the network. A production system also lacks the necessary virtualized snapshots and network controls used in a proper malware lab. The analyst should first create an image and then execute the sample only within an isolated virtual machine with host network disabled and tooling such as Procmon or x64dbg.

Trap 2: Disassemble the binary using IDA Pro directly

Opening the original binary directly in IDA Pro risks breaking chain of custody and could alter the evidence if the analyst accidentally applies patches, edits bytes, or executes the file via a plugin. IDA Pro also creates an intrusive analysis database (.idb/.i64) that may write metadata to the original location, and the original file's timestamp and access time can change. To prevent any integrity violation, the analyst must work from an exact forensic copy, keeping the original safely hashed and stored.

Trap 3: Connect the sample to an isolated network to observe behavior

Connecting the sample to an isolated network without first making a forensic copy is premature because the malware might still escape containment—via ARP spoofing, USB passthrough, or VM escape—and infect the host or pivot through the same subnet. Even an 'isolated' network needs a purpose-built malware analysis lab with host virtualization, network sinks, and packet capture, not just a disconnected switch. The correct sequence is to image the sample first, then analyze statically, and finally run dynamic analysis against a copy in a controlled, monitored environment.

A
Create a bit-for-bit forensic image of the sample
Creating a bit-for-bit forensic image with a tool such as FTK Imager, dd, or Guymager ensures the original evidence remains untouched and is the mandatory first step in reverse engineering. The image retains slack space, unallocated clusters, and metadata, and a cryptographic hash (e.g., SHA-256) is computed before and after to prove integrity. This preserves a clean evidence artifact that can be analyzed, re-imaged, or tested in a sandbox without risk of altering the original sample.
B
Execute the sample in a debugger on a production machine
Why it fails: Executing the sample under a debugger on a production machine is dangerous because the machine is not isolated and the malware may detect the debugger or immediately trigger its payload, causing file encryption, data exfiltration, or lateral movement across the network. A production system also lacks the necessary virtualized snapshots and network controls used in a proper malware lab. The analyst should first create an image and then execute the sample only within an isolated virtual machine with host network disabled and tooling such as Procmon or x64dbg.
C
Disassemble the binary using IDA Pro directly
Why it fails: Opening the original binary directly in IDA Pro risks breaking chain of custody and could alter the evidence if the analyst accidentally applies patches, edits bytes, or executes the file via a plugin. IDA Pro also creates an intrusive analysis database (.idb/.i64) that may write metadata to the original location, and the original file's timestamp and access time can change. To prevent any integrity violation, the analyst must work from an exact forensic copy, keeping the original safely hashed and stored.
D
Connect the sample to an isolated network to observe behavior
Why it fails: Connecting the sample to an isolated network without first making a forensic copy is premature because the malware might still escape containment—via ARP spoofing, USB passthrough, or VM escape—and infect the host or pivot through the same subnet. Even an 'isolated' network needs a purpose-built malware analysis lab with host virtualization, network sinks, and packet capture, not just a disconnected switch. The correct sequence is to image the sample first, then analyze statically, and finally run dynamic analysis against a copy in a controlled, monitored environment.

Question 3hardmulti select

Which TWO of the following are common indicators of a rootkit infection on a Windows system?

Trap 1: High CPU usage by svchost.exe

While a rootkit could conceivably run code via a service, the svchost.exe process is a standard Windows service host. Elevated CPU usage in svchost.exe is commonly caused by benign services, third-party software, or non-rootkit malware. Rootkits typically operate in kernel mode or via stealth mechanisms that avoid blatant resource consumption, so this symptom is too generic to be a reliable rootkit indicator.

Trap 2: Unexpected open ports on the firewall

Unexpected open ports typically signify a network service or backdoor listening on the system, but they are not a defining characteristic of rootkits. Rootkits focus on stealth and privilege escalation, and they may not expose any network interface at all—often they communicate via existing traffic or kernel-level manipulation. Open ports can also result from benign applications, making this a non-specific sign.

Trap 3: Presence of unsigned kernel drivers

An unsigned kernel driver indicates the driver is not verified by Microsoft, which can introduce security risk, but it does not by itself signify a rootkit. Legitimate legacy drivers or proprietary hardware drivers may also be unsigned. A rootkit might load via an unsigned driver, but the mere presence is not sufficient evidence—modern rootkits often use signed malicious drivers or code injection to avoid this flag.

A
High CPU usage by svchost.exe
Why it fails: While a rootkit could conceivably run code via a service, the svchost.exe process is a standard Windows service host. Elevated CPU usage in svchost.exe is commonly caused by benign services, third-party software, or non-rootkit malware. Rootkits typically operate in kernel mode or via stealth mechanisms that avoid blatant resource consumption, so this symptom is too generic to be a reliable rootkit indicator.
B
System calls returning inconsistent results
Rootkits often install kernel-mode hooks or filter drivers to intercept system calls and return falsified data, such as hiding files, processes, or registry keys. This causes APIs to produce results that differ from the actual system state, a behavior signature unique to API-hooking techniques. Comparing system call output with raw reads or with another access method reveals these discrepancies.
C
Unexpected open ports on the firewall
Why it fails: Unexpected open ports typically signify a network service or backdoor listening on the system, but they are not a defining characteristic of rootkits. Rootkits focus on stealth and privilege escalation, and they may not expose any network interface at all—often they communicate via existing traffic or kernel-level manipulation. Open ports can also result from benign applications, making this a non-specific sign.
D
Presence of unsigned kernel drivers
Why it fails: An unsigned kernel driver indicates the driver is not verified by Microsoft, which can introduce security risk, but it does not by itself signify a rootkit. Legitimate legacy drivers or proprietary hardware drivers may also be unsigned. A rootkit might load via an unsigned driver, but the mere presence is not sufficient evidence—modern rootkits often use signed malicious drivers or code injection to avoid this flag.
E
Hidden processes not visible in Task Manager
Rootkits actively conceal their own code and associated processes from standard system utilities like Task Manager by hooking system calls or altering kernel data structures. This provides the attacker with persistent, invisible execution, which is a hallmark of rootkit functionality. Any process that remains hidden from standard enumeration tools while still consuming system resources is a strong indicator of kernel-level subterfuge.

Question 4mediummulti select

Which THREE of the following are best practices for conducting malware forensics in a safe and effective manner?

Trap 1: Delete the malware sample after analysis to prevent accidental…

Deleting a malware sample after analysis is a critical chain-of-custody violation because the sample is documentary evidence that may be needed for court proceedings, independent re-analysis, or further research. Preservation overrides the convenience of elimination; proper containment is achieved through encrypted, password-protected archives on isolated removable media, not through destruction. The risk of accidental infection is legitimately mitigated by using virtual machines, sandboxes, and network isolation, so deletion is both unnecessary and harmful to the investigative process.

Trap 2: Run all analysis using the same tools and versions as the attacker

Replicating the attacker's exact tools and versions is not a best practice because those tools may contain their own vulnerabilities or unknown dependencies that could compromise the analyst's machine or produce biased, irrelevant results. Forensic analysis demands a controlled, defensible environment using updated, trusted tools that are documented in the investigation report, not a recreation of the adversary's toolset. While understanding attacker methodology is important, it is achieved through malware code analysis and behavioral observation, not by deliberately adopting insecure or unpatched utilities that could corrupt evidence or introduce secondary infections.

A
Use a dedicated forensic workstation that is not connected to any network
A dedicated forensic workstation must be electrically and logically isolated from corporate and internet networks to prevent malware from propagating, beaconing, or exfiltrating data during analysis. This isolation also protects the integrity of the evidence by ensuring that the workstation's kernel, toolchain, and analysis environment remain pristine and free from external tampering. Best practice additionally requires the use of write-blockers for original media and maintaining a documented, baseline image of the workstation to validate that no forensic artifacts have been altered.
B
Delete the malware sample after analysis to prevent accidental infection
Why it fails: Deleting a malware sample after analysis is a critical chain-of-custody violation because the sample is documentary evidence that may be needed for court proceedings, independent re-analysis, or further research. Preservation overrides the convenience of elimination; proper containment is achieved through encrypted, password-protected archives on isolated removable media, not through destruction. The risk of accidental infection is legitimately mitigated by using virtual machines, sandboxes, and network isolation, so deletion is both unnecessary and harmful to the investigative process.
C
Always create a cryptographic hash of the malware sample before analysis
Computing a cryptographic hash (e.g., SHA-256) of the malware sample before any analysis establishes a trusted integrity baseline that can detect any unintentional modification during acquisition, transit, or execution. This hash also serves as a unique digital fingerprint for querying public malware repositories like VirusTotal or MalwareBazaar, enabling rapid identification of known samples and correlation with threat intelligence. Without this preliminary hashing, the analyst cannot prove that the sample under investigation is identical to the original seized artifact, undermining the forensic soundness of the entire report.
D
Use a virtual machine or sandbox for dynamic analysis
Dynamic analysis should be conducted in a virtual machine or sandbox to expose the malware's runtime behavior—such as process injection, registry modifications, and network communications—while containing its destructive effects to a disposable, easily restored environment. The sandbox must be isolated from the production network and used without shared folders, clipboard, or host drives, otherwise the malware may escape and compromise the analyst's infrastructure. Note that sophisticated malware may detect virtualized environments and alter its behavior, so a truly thorough dynamic analysis may require combining sandbox observations with hardware-virtualization-based monitoring or bare-metal execution in later phases.
E
Run all analysis using the same tools and versions as the attacker
Why it fails: Replicating the attacker's exact tools and versions is not a best practice because those tools may contain their own vulnerabilities or unknown dependencies that could compromise the analyst's machine or produce biased, irrelevant results. Forensic analysis demands a controlled, defensible environment using updated, trusted tools that are documented in the investigation report, not a recreation of the adversary's toolset. While understanding attacker methodology is important, it is achieved through malware code analysis and behavioral observation, not by deliberately adopting insecure or unpatched utilities that could corrupt evidence or introduce secondary infections.

Question 5easymulti select

Which TWO techniques are commonly used to evade detection by antivirus software in packed malware?

Trap 1: Code obfuscation

Code obfuscation transforms the control flow and data structures of a binary to make it harder for a human analyst or debugger to understand, but it does not change the executable's byte signature on each run. Because the code remains static and intact, antivirus engines can still compare it against known hashes or byte-level signatures. Obfuscation is primarily an intellectual-property protection technique, whereas detection evasion in the packing context relies on dynamically mutating or encrypting the file so that static signatures fail.

Trap 2: Anti-debugging tricks

Anti-debugging tricks, such as checking the Process Environment Block's BeingDebugged flag or invoking timing-based exceptions, are designed to thwart runtime analysis and debugging sessions. These techniques do nothing to the file at rest on disk, so they cannot hide a known malicious signature from a static antivirus scan. They are a behavioral evasion layer that activates in memory, not a static packing or mutation technique that changes the file's detectable content.

Trap 3: Anti-VM checks

Anti-VM checks detect that a program is running inside a virtualized or sandboxed environment, often through CPUID hypervisor bits, invalid-opcode probes, or latency measurements, and then alter behavior to avoid revealing malicious actions to analysts. These checks are purely environmental and do not affect the malware's file structure or signature, so an antivirus engine scanning the binary on disk will still identify it if it matches a known threat pattern. Anti-VM is a dynamic sandbox-evasion technique, not a packing or code-mutation method for evading signature-based static detection.

A
Code obfuscation
Why it fails: Code obfuscation transforms the control flow and data structures of a binary to make it harder for a human analyst or debugger to understand, but it does not change the executable's byte signature on each run. Because the code remains static and intact, antivirus engines can still compare it against known hashes or byte-level signatures. Obfuscation is primarily an intellectual-property protection technique, whereas detection evasion in the packing context relies on dynamically mutating or encrypting the file so that static signatures fail.
B
Anti-debugging tricks
Why it fails: Anti-debugging tricks, such as checking the Process Environment Block's BeingDebugged flag or invoking timing-based exceptions, are designed to thwart runtime analysis and debugging sessions. These techniques do nothing to the file at rest on disk, so they cannot hide a known malicious signature from a static antivirus scan. They are a behavioral evasion layer that activates in memory, not a static packing or mutation technique that changes the file's detectable content.
C
Polymorphic code
Polymorphic code is a core evasion technique in which the decryption/decoding routine mutates each time the malware propagates or runs, generating a new byte pattern while the underlying encrypted payload remains semantically identical. This mutation can involve instruction substitution, dead-code insertion, register reassignment, or self-modifying code, all of which prevent signature databases from maintaining a stable fingerprint of the malware. As a result, polymorphic code directly defeats signature-based detection by ensuring that no two samples share the same static code sequence.
D
Anti-VM checks
Why it fails: Anti-VM checks detect that a program is running inside a virtualized or sandboxed environment, often through CPUID hypervisor bits, invalid-opcode probes, or latency measurements, and then alter behavior to avoid revealing malicious actions to analysts. These checks are purely environmental and do not affect the malware's file structure or signature, so an antivirus engine scanning the binary on disk will still identify it if it matches a known threat pattern. Anti-VM is a dynamic sandbox-evasion technique, not a packing or code-mutation method for evading signature-based static detection.
E
Encryption with a variable key
Encryption with a variable key (rather than a hard-coded key) ensures that the malicious payload is encoded using a per-instance or per-execution key, generating completely different ciphertext even when the same payload is used. This prevents an analyst from extracting a single plaintext signature or from performing static decryption without first emulating the unpacking stub to recover the key. When combined with a polymorphic or mutating stub, variable-key encryption makes the entire packed file's byte pattern unpredictable, robustly defeating signature-based antivirus detection.

Question 6hardmulti select

Which THREE of the following are indicators of malware persistence via registry run keys? (Choose three.)

Trap 1: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows…

The TaskCache\Tasks path is the registry mirror of Task Scheduler's scheduled task database, not a Windows autostart Run key. Every scheduled task, including standard system maintenance and legitimate third-party jobs, is recorded here, so the key's presence is normal and meaningless as a standalone persistence indicator. To assess malware persistence, an investigator would examine task XML files, task triggers, and the corresponding actions folder, not treat this hive as a Run or RunOnce value. For that reason, this choice is not one of the three classic registry-run persistence indicators.

Trap 2: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

The Services key under CurrentControlSet contains the full configuration database for the Service Control Manager, including every legitimate kernel-mode and user-mode service installed on the system. Its existence is not an indicator of compromise; persistence via a malicious service is established only when a specific subkey contains suspicious ImagePath values, ServiceDLL references, or FailureCommand parameters that restart the payload. Treating this key itself as a persistence indicator creates false positives because it is the expected home of all services, not a startup Run key.

A
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Residing in the per-user hive, this RunOnce key is processed by Windows Explorer at next logon, launching the referenced executable once and then automatically deleting the value. Malware authors exploit this by pointing it at a dropper or payload so that execution happens before the user session is fully interactive, while the automatic removal helps conceal the persistence entry from casual inspection. Its existence, particularly with an unusual binary path or encoded command in the value data, is a strong indicator of one-shot persistence.
B
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks
Why it fails: The TaskCache\Tasks path is the registry mirror of Task Scheduler's scheduled task database, not a Windows autostart Run key. Every scheduled task, including standard system maintenance and legitimate third-party jobs, is recorded here, so the key's presence is normal and meaningless as a standalone persistence indicator. To assess malware persistence, an investigator would examine task XML files, task triggers, and the corresponding actions folder, not treat this hive as a Run or RunOnce value. For that reason, this choice is not one of the three classic registry-run persistence indicators.
C
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Under HKLM's Windows\CurrentVersion branch, this Run value applies system-wide and executes the specified command at every interactive logon for all users. Because it is designed for legitimate startup programs, investigators look for anomalies such as a value name that does not match the executable, paths pointing to %TEMP% or AppData, or encoded/obfuscated command lines. A persistent entry here is a classic Windows autostart indicator and is one of the first places checked during malware triage and forensic imaging.
D
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Why it fails: The Services key under CurrentControlSet contains the full configuration database for the Service Control Manager, including every legitimate kernel-mode and user-mode service installed on the system. Its existence is not an indicator of compromise; persistence via a malicious service is established only when a specific subkey contains suspicious ImagePath values, ServiceDLL references, or FailureCommand parameters that restart the payload. Treating this key itself as a persistence indicator creates false positives because it is the expected home of all services, not a startup Run key.
E
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
RunOnceEx is a less commonly inspected extension of RunOnce, storing commands under ordered numeric subkeys such as 000, 001, and 002 that Explorer processes during logon, originally for driver and setup installers. Malware can abuse it by registering a malicious DLL or executable with an '@' or '!' prefix, which suppresses error dialogs and can cause execution before the desktop becomes fully interactive. Because this key is often overlooked by forensic tools and users, an entry here is a meaningful persistence indicator, especially when it is paired with temporary folders or obfuscated command-line arguments.

Question 7mediumdrag order

Drag and drop the steps to perform a forensic analysis of email headers to trace the origin of a spam email into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Check SPF, DKIM, and DMARC authentication results, then obtain full…

Testing SPF, DKIM, and DMARC before retrieving the full header set is premature because authentication checks read critical header fields such as Return-Path, d=, and Authentication-Results that are scattered throughout the raw header block. An examiner must first preserve and extract the complete header artifact from the email file, otherwise the authentication results cannot be correlated with the actual Received relay path. Additionally, without first tracing the originating IP from Received headers, a valid DKIM signature could be misattributed to a spoofed IP, making the early authentication pass dangerously misleading.

Trap 2: Parse Received headers to identify the originating IP, then obtain…

Parsing Received headers before obtaining the complete email headers is a procedural impossibility because the Received chain is itself a subset of the full header block stored in the .eml or .msg evidence container. Starting with parsing forces the examiner to work from an incomplete or unverified extraction, which compromises the forensic integrity of the analysis and can allow a forged or truncated Received field to go undetected. This sequence also skips the necessary header acquisition step that establishes the authenticity and completeness of the evidence before any source IP conclusions are drawn.

Trap 3: Obtain full email headers, then check SPF, DKIM, and DMARC…

Obtaining the full headers first is correct, but launching straight into SPF, DKIM, and DMARC checks before parsing the Received headers ignores the fact that Authentication-Results headers are inserted by intermediate MTAs and can be stale, forged, or only valid for a specific relay. The examiner must first use the Received chain to identify the last trusted MTA and the originating IP, because that IP is the reference point against which SPF and reverse DNS must be compared. Running authentication tests too early, without the route context, risks accepting a DKIM signature generated by a later MTA and missing the actual source of the malicious message.

A
Obtain full email headers, then parse Received headers to identify the originating IP, then perform WHOIS and reverse DNS on the IP, then check SPF, DKIM, and DMARC authentication results.
This order is correct because you must first retrieve all header information, then extract the originating IP from Received headers, then trace that IP to identify the source, and finally verify email authentication to confirm legitimacy.
B
Check SPF, DKIM, and DMARC authentication results, then obtain full email headers, then parse Received headers to identify the originating IP, then perform WHOIS and reverse DNS on the IP.
Why it fails: Testing SPF, DKIM, and DMARC before retrieving the full header set is premature because authentication checks read critical header fields such as Return-Path, d=, and Authentication-Results that are scattered throughout the raw header block. An examiner must first preserve and extract the complete header artifact from the email file, otherwise the authentication results cannot be correlated with the actual Received relay path. Additionally, without first tracing the originating IP from Received headers, a valid DKIM signature could be misattributed to a spoofed IP, making the early authentication pass dangerously misleading.
C
Parse Received headers to identify the originating IP, then obtain full email headers, then check SPF, DKIM, and DMARC authentication results, then perform WHOIS and reverse DNS on the IP.
Why it fails: Parsing Received headers before obtaining the complete email headers is a procedural impossibility because the Received chain is itself a subset of the full header block stored in the .eml or .msg evidence container. Starting with parsing forces the examiner to work from an incomplete or unverified extraction, which compromises the forensic integrity of the analysis and can allow a forged or truncated Received field to go undetected. This sequence also skips the necessary header acquisition step that establishes the authenticity and completeness of the evidence before any source IP conclusions are drawn.
D
Obtain full email headers, then check SPF, DKIM, and DMARC authentication results, then parse Received headers to identify the originating IP, then perform WHOIS and reverse DNS on the IP.
Why it fails: Obtaining the full headers first is correct, but launching straight into SPF, DKIM, and DMARC checks before parsing the Received headers ignores the fact that Authentication-Results headers are inserted by intermediate MTAs and can be stale, forged, or only valid for a specific relay. The examiner must first use the Received chain to identify the last trusted MTA and the originating IP, because that IP is the reference point against which SPF and reverse DNS must be compared. Running authentication tests too early, without the route context, risks accepting a DKIM signature generated by a later MTA and missing the actual source of the malicious message.

Question 8mediummatching

Match each steganography technique to its carrier medium.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Image files (BMP, PNG)

Audio files (WAV, MP3)

GIF images

JPEG images

Plain text or documents

Trap 1: Image steganography: Hides data in audio files

Pairing image steganography with audio files mismatches the technique to the carrier medium: any hidden payload placed in a WAV or MP3 file is by definition carried in audio, and therefore falls under audio steganography. Even if the hidden data is inserted by altering binary structure using an image-style tool, the carrier format dictates the discipline. In steganography taxonomy, the medium is the primary classifier, so calling it image steganography is factually incorrect.

Trap 2: Audio steganography: Hides data in image files

Audio steganography requires a time-domain audio signal as its embedding substrate, so hiding data in an image file cannot be audio steganography. When pixels of a JPEG or PNG are modified to conceal a message, the operation is image steganography regardless of whether the payload is textual, audio-based, or arbitrary bytes. The wrong answer confuses the embedded payload's original form with the carrier medium, but steganography category depends on the carrier, not the secret's source.

A
Image steganography: Hides data in image files
Image steganography operates on raster image carriers, embedding secret data by manipulating pixel brightness or color values while keeping visual artifacts minimal. The most common approach is Least Significant Bit (LSB) replacement, where the low-order bits of pixel bytes are overwritten with encoded payload bits. Techniques are tuned to image-specific properties such as palette ordering, compression schemes, and file format tolerances, so the carrier medium is definitively the image file itself.
B
Audio steganography: Hides data in audio files
Audio steganography hides information within digital audio carriers by modifying sample amplitudes in the time domain, typically through LSB substitution that creates barely audible noise. More robust methods exploit perceptual masking to embed data in inaudible frequency bands, or employ spread-spectrum and echo-hiding techniques that resist compression. Because the signal is audio, psychoacoustic models and sample rate behavior determine how safely payload bits can be inserted.
C
Text steganography: Hides data in text files
Text steganography uses plain-text or formatted-text files as the carrier, concealing messages through whitespace manipulation, variable spacing, invisible Unicode characters, or subtle font and style variations. Unlike pixel or sample-based techniques, it relies on the loose rendering rules of text layout and often produces files whose characters are visually identical to normal text. The data capacity is low, but the carrier remains the text document, not the binary pixels of an image or the waveform of an audio file.
D
Network steganography: Hides data in network packets
Network steganography embeds data in network packet streams by co-opting protocol metadata such as TCP/IP header fields, padding bytes, or unused flags, and even by modulating packet timing patterns. These covert channels ride inside legitimate traffic, which acts as the carrier medium, making them hard to detect without deep packet inspection and traffic analysis. The carrier is the sequence of packets on the wire rather than a static file.
E
Image steganography: Hides data in audio files
Why it fails: Pairing image steganography with audio files mismatches the technique to the carrier medium: any hidden payload placed in a WAV or MP3 file is by definition carried in audio, and therefore falls under audio steganography. Even if the hidden data is inserted by altering binary structure using an image-style tool, the carrier format dictates the discipline. In steganography taxonomy, the medium is the primary classifier, so calling it image steganography is factually incorrect.
F
Audio steganography: Hides data in image files
Why it fails: Audio steganography requires a time-domain audio signal as its embedding substrate, so hiding data in an image file cannot be audio steganography. When pixels of a JPEG or PNG are modified to conceal a message, the operation is image steganography regardless of whether the payload is textual, audio-based, or arbitrary bytes. The wrong answer confuses the embedded payload's original form with the carrier medium, but steganography category depends on the carrier, not the secret's source.

Question 9hardmultiple choice

An organization suspects a stealthy malware infection on a critical server. Traditional antivirus and EDR solutions have not detected anything. Which forensic approach would be most effective in identifying the malware, given that it likely resides only in memory?

Trap 1: Perform a full disk scan with updated antivirus signatures

A full disk scan with updated antivirus signatures is ineffective against stealthy fileless infections because these threats execute directly in memory, often through PowerShell or WMI, and never write a malicious executable to disk. Signature-based AV also depends on known indicators of compromise, so polymorphic or zero-day payloads that are unpacked only in RAM will evade static file scanning, leaving the live infection untouched.

Trap 2: Conduct a live analysis using built-in Windows tools like Task…

Conducting a live analysis using built-in Windows tools like Task Manager is insufficient because these utilities rely on user-mode APIs that can be subverted by rootkits through API hooking or DKOM, so the malware may simply not appear in process listings. Moreover, the act of clicking through GUI tools writes cache files, updates last-accessed timestamps, and perturbs memory, contaminating the very evidence needed for a reliable forensic examination.

Trap 3: Analyze network traffic for anomalies using a NetFlow analyzer

Analyzing network traffic for anomalies with a NetFlow analyzer is a detection technique, not a forensic acquisition, because NetFlow records contain only connection metadata such as IPs, ports, and timestamps, not the executable code or process artifacts needed to prove malware presence. Even if C2 beacons are identified, the actual payload remains in the host's memory, so network analysis must be paired with memory forensics to capture the infection itself.

A
Perform a full disk scan with updated antivirus signatures
Why it fails: A full disk scan with updated antivirus signatures is ineffective against stealthy fileless infections because these threats execute directly in memory, often through PowerShell or WMI, and never write a malicious executable to disk. Signature-based AV also depends on known indicators of compromise, so polymorphic or zero-day payloads that are unpacked only in RAM will evade static file scanning, leaving the live infection untouched.
B
Acquire a memory dump and perform memory forensics with tools like Volatility
Acquiring a memory dump and analyzing it with Volatility is the correct approach because it preserves the volatile state where fileless malware resides, capturing the actual code, injected processes, and hooked kernel structures. Memory forensics allows investigators to enumerate running processes, inspect process memory and VAD trees, and extract indicators that would be lost on reboot, providing the most direct evidence of the infection.
C
Conduct a live analysis using built-in Windows tools like Task Manager
Why it fails: Conducting a live analysis using built-in Windows tools like Task Manager is insufficient because these utilities rely on user-mode APIs that can be subverted by rootkits through API hooking or DKOM, so the malware may simply not appear in process listings. Moreover, the act of clicking through GUI tools writes cache files, updates last-accessed timestamps, and perturbs memory, contaminating the very evidence needed for a reliable forensic examination.
D
Analyze network traffic for anomalies using a NetFlow analyzer
Why it fails: Analyzing network traffic for anomalies with a NetFlow analyzer is a detection technique, not a forensic acquisition, because NetFlow records contain only connection metadata such as IPs, ports, and timestamps, not the executable code or process artifacts needed to prove malware presence. Even if C2 beacons are identified, the actual payload remains in the host's memory, so network analysis must be paired with memory forensics to capture the infection itself.

Question 10mediummultiple choice

During malware analysis, an investigator finds that a suspicious process is injecting code into a legitimate system process (e.g., explorer.exe). Which technique is being used?

Trap 1: API hooking

API hooking is a method of redirecting or monitoring the calls that an application makes to Windows API functions, typically by patching the Import Address Table or overwriting function prologues with jump instructions. However, this technique primarily intercepts execution flow and alters the behavior of existing code; it does not inherently involve writing new executable code into a running process's address space. While API hooking can be used to facilitate injection, the defining characteristic is interception, not code insertion.

Trap 2: Process hollowing

Process hollowing is a form of process replacement where a legitimate process is created in a suspended state, its original executable image is unmapped, and then malicious code is written into the now-empty address space before the process resumes. The malicious payload is placed into a fresh process that never runs its original code, rather than being inserted into an already-running process. This distinguishes it from code injection, which targets a live, executing process.

Trap 3: DLL injection

DLL injection is a specialized subset of code injection that involves loading a dynamic-link library (DLL) into a target process's memory, typically by calling CreateRemoteThread and LoadLibrary. However, the unknown intrusion description does not indicate that the inserted code is a DLL, as it could be raw position-independent code, an executable image, or other binary data. Therefore, this option is too specific to be the correct answer without additional detail.

A
API hooking
Why it fails: API hooking is a method of redirecting or monitoring the calls that an application makes to Windows API functions, typically by patching the Import Address Table or overwriting function prologues with jump instructions. However, this technique primarily intercepts execution flow and alters the behavior of existing code; it does not inherently involve writing new executable code into a running process's address space. While API hooking can be used to facilitate injection, the defining characteristic is interception, not code insertion.
B
Process hollowing
Why it fails: Process hollowing is a form of process replacement where a legitimate process is created in a suspended state, its original executable image is unmapped, and then malicious code is written into the now-empty address space before the process resumes. The malicious payload is placed into a fresh process that never runs its original code, rather than being inserted into an already-running process. This distinguishes it from code injection, which targets a live, executing process.
C
Code injection
Code injection is the correct classification because the finding that code was inserted into a running process directly matches this term. It encompasses any technique that places executable code into the virtual address space of another process and then causes it to run, often by creating a remote thread or using an asynchronous procedure call. The stem's description is a general definition of code injection, not limited to a specific delivery vector.
D
DLL injection
Why it fails: DLL injection is a specialized subset of code injection that involves loading a dynamic-link library (DLL) into a target process's memory, typically by calling CreateRemoteThread and LoadLibrary. However, the unknown intrusion description does not indicate that the inserted code is a DLL, as it could be raw position-independent code, an executable image, or other binary data. Therefore, this option is too specific to be the correct answer without additional detail.

Question 11hardmultiple choice

Refer to the exhibit. An investigator is examining a disk image using TSK. The output from 'fls' shows the directory structure. What is the significance of the entry 'V/V 113-128-1: $OrphanFiles'?

Exhibit

Refer to the exhibit.

C:\> fls -f ntfs -o 2048 image.dd
r/r 4-128-3: $AttrDef
r/r 8-128-2: $BadClus
r/r 6-128-2: $Bitmap
r/r 7-128-1: $Boot
r/r 11-128-3: $Extend
r/r 2-128-1: $LogFile
r/r 0-128-1: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure
r/r 10-128-1: $UpCase
r/r 3-128-3: $Volume
r/r 108-128-2: Users
r/r 109-128-3: ProgramData
r/r 110-128-2: Windows
r/r 111-128-1: Program Files
r/r 112-128-1: Program Files (x86)
V/V 113-128-1: $OrphanFiles
r/r 114-128-3: autoexec.bat
r/r 115-128-1: config.sys

Trap 1: It is a sign that a rootkit has hidden files in the image

The presence of $OrphanFiles is a routine artifact produced by file-system analysis tools (such as The Sleuth Kit) when they encounter file records that are not referenced by any directory entry. It reflects the state of the disk after deletion or corruption of directory structures, not any active concealment by a rootkit. Rootkit file-hiding typically relies on kernel-mode API hooking or direct manipulation of MFT attributes, which would not generate a virtual directory with that canonical name in a forensic image.

Trap 2: It indicates the location of the Master File Table (MFT) mirror

$OrphanFiles is not a pointer to or an indicator of the Master File Table (MFT) mirror. On NTFS, the MFT mirror is anchored at the file named $MFTMirr (metadata file number 1), which is a redundant copy of the first few MFT records stored near the middle of the volume. In contrast, $OrphanFiles is a conceptual virtual directory that forensic tools construct to present orphaned MFT entries, and it has no corresponding on-disk metadata file or location.

Trap 3: It is a standard NTFS metadata file that stores file permissions

$OrphanFiles is not one of the standard NTFS metadata files such as $MFT, $LogFile, or $Secure. Standard NTFS metadata files reside in the MFT with fixed record numbers and specific system-defined purposes, such as tracking security descriptors or the volume's file list. $OrphanFiles is not present on the volume at all; it is a synthetic grouping created by forensic software to aid the examiner in reviewing unlinked file records, so it does not store file permissions or any other metadata.

A
It is a sign that a rootkit has hidden files in the image
Why it fails: The presence of $OrphanFiles is a routine artifact produced by file-system analysis tools (such as The Sleuth Kit) when they encounter file records that are not referenced by any directory entry. It reflects the state of the disk after deletion or corruption of directory structures, not any active concealment by a rootkit. Rootkit file-hiding typically relies on kernel-mode API hooking or direct manipulation of MFT attributes, which would not generate a virtual directory with that canonical name in a forensic image.
B
It indicates the location of the Master File Table (MFT) mirror
Why it fails: $OrphanFiles is not a pointer to or an indicator of the Master File Table (MFT) mirror. On NTFS, the MFT mirror is anchored at the file named $MFTMirr (metadata file number 1), which is a redundant copy of the first few MFT records stored near the middle of the volume. In contrast, $OrphanFiles is a conceptual virtual directory that forensic tools construct to present orphaned MFT entries, and it has no corresponding on-disk metadata file or location.
C
It is a virtual directory that contains files with no parent directory, often from deleted files
In tools like The Sleuth Kit (tsk) and Autopsy, the virtual directory named $OrphanFiles (or displayed as 'V/V') is not a literal directory stored on the disk. It is dynamically generated to represent files whose MFT entries exist but whose parent directory references were lost, typically because the directory entry was deleted, overwritten, or corrupted while the file record itself remains in the MFT. This commonly occurs after a file is deleted, when the directory index entry is removed but the file's MFT record is not yet reused, or after a malformed directory entry prevents normal linkage in the tree.
D
It is a standard NTFS metadata file that stores file permissions
Why it fails: $OrphanFiles is not one of the standard NTFS metadata files such as $MFT, $LogFile, or $Secure. Standard NTFS metadata files reside in the MFT with fixed record numbers and specific system-defined purposes, such as tracking security descriptors or the volume's file list. $OrphanFiles is not present on the volume at all; it is a synthetic grouping created by forensic software to aid the examiner in reviewing unlinked file records, so it does not store file permissions or any other metadata.

Question 12mediummultiple choice

You are a forensic analyst investigating a suspected malware infection on a Windows 10 workstation. The user reports that the system has been slow and that unexpected pop-ups appear. You have acquired a memory dump and a disk image. During analysis, you find a suspicious process named 'svch0st.exe' running with PID 4567. The process has loaded several DLLs, including 'wininet.dll' and 'ws2_32.dll'. You also find that the process has an active TCP connection to an external IP address 203.0.113.5 on port 4444. In the disk image, you find an executable file at C:\Users\Public\svch0st.exe with a creation date that matches the start of symptoms. The file's hash is not in any known malware database. You decide to perform dynamic analysis by running the file in a sandbox. However, the sandbox environment has no network connectivity. The executable runs but does not exhibit any malicious behavior. What should you do next to determine if the file is malicious?

Trap 1: Conduct a thorough static analysis using a disassembler and…

Static analysis with a disassembler and debugger is foundational for revealing code structure, but it cannot capture behaviors that manifest only under specific runtime conditions, such as a live command-and-control (C2) channel. Malware often employs anti-analysis techniques like packing, obfuscation, and anti-debugging, or it may deliberately wait for network responses before executing its payload. Debugging can also alter timing and trigger defensive routines, so static analysis alone is insufficient to observe the full attack sequence, especially network-dependent activity.

Trap 2: Delete the suspicious file and run a full antivirus scan on the…

Deleting the suspicious file destroys probative evidence and undermines forensic integrity, while a full antivirus scan relies primarily on signature-based detection that is ineffective against unknown, polymorphic, or fileless malware. Even if the scan flags the file, it does not reveal the malware's behavior, C2 infrastructure, or impact. Proper procedure requires preserving the original sample through forensic imaging, then performing dynamic analysis in a controlled environment to understand the threat, not summarily deleting it.

Trap 3: Perform a forensic imaging of the system again and compare with the…

Performing a forensic imaging of the system again and comparing it with the original image will only show file-system changes, such as new files or altered timestamps, but it cannot reveal the malware's runtime behavior or the content of its C2 communications. Re-imaging is a preservation and evidence-integrity process, not an analytical technique for inducing or observing malicious actions. To understand the sample's network activity and payload, one must perform dynamic analysis in a sandboxed environment with controlled connectivity, not repeat forensic imaging.

A
Conduct a thorough static analysis using a disassembler and debugger to understand the code
Why it fails: Static analysis with a disassembler and debugger is foundational for revealing code structure, but it cannot capture behaviors that manifest only under specific runtime conditions, such as a live command-and-control (C2) channel. Malware often employs anti-analysis techniques like packing, obfuscation, and anti-debugging, or it may deliberately wait for network responses before executing its payload. Debugging can also alter timing and trigger defensive routines, so static analysis alone is insufficient to observe the full attack sequence, especially network-dependent activity.
B
Delete the suspicious file and run a full antivirus scan on the system
Why it fails: Deleting the suspicious file destroys probative evidence and undermines forensic integrity, while a full antivirus scan relies primarily on signature-based detection that is ineffective against unknown, polymorphic, or fileless malware. Even if the scan flags the file, it does not reveal the malware's behavior, C2 infrastructure, or impact. Proper procedure requires preserving the original sample through forensic imaging, then performing dynamic analysis in a controlled environment to understand the threat, not summarily deleting it.
C
Re-run the sample in a sandbox with simulated network connectivity or a controlled network to observe C2 communication
Re-running the sample in a sandbox with simulated network connectivity or a controlled network is the correct approach because many malware families remain dormant until they establish C2 communication, at which point they download additional payloads, exfiltrate data, or execute commands. A network-enabled sandbox provides a safe, but realistic environment where the analyst can observe DNS queries, HTTP/S connections, beaconing intervals, and the exact data exchanged with the C2 server. This dynamic analysis yields actionable indicators of compromise (IoCs) and reveals the malware's full functionality without risking real network infection.
D
Perform a forensic imaging of the system again and compare with the original image
Why it fails: Performing a forensic imaging of the system again and comparing it with the original image will only show file-system changes, such as new files or altered timestamps, but it cannot reveal the malware's runtime behavior or the content of its C2 communications. Re-imaging is a preservation and evidence-integrity process, not an analytical technique for inducing or observing malicious actions. To understand the sample's network activity and payload, one must perform dynamic analysis in a sandboxed environment with controlled connectivity, not repeat forensic imaging.

Question 13mediummultiple choice

Based on the exhibit, what is the most likely indication of malware persistence?

Exhibit

Refer to the exhibit.

C:\Users\Admin> sc query | findstr /i "service"
SERVICE_NAME: WinDefend
DISPLAY_NAME: Windows Defender Antivirus Service
STATE: 4 RUNNING

C:\Users\Admin> tasklist /svc
Image Name PID Services
================= ======== ============================================
svchost.exe 1234 WinDefend
svchost.exe 5678 BFE, MpsSvc
services.exe 4321 

C:\Users\Admin> netstat -ano | findstr :4444
  TCP    0.0.0.0:4444   0.0.0.0:0    LISTENING     4321

Trap 1: services.exe PID 4321 is a known malware process

services.exe is the Windows Service Control Manager, a legitimate system process responsible for managing services, and its PID is assigned dynamically at boot. There is no known malware variant called 'services.exe' that can be identified by PID alone; malware authors frequently reuse the same file name to blend in, so the PID does not constitute a threat indicator.

Trap 2: Windows Defender service is stopped, allowing malware to run

The exhibit displays a service state of 4, which corresponds to SERVICE_RUNNING in the Windows SCM, not a stopped state. When a service is stopped, the state code is 1 (SERVICE_STOPPED), so Windows Defender is demonstrably active in this output. Even a running antivirus does not guarantee the system is clean, but the specific assertion that Defender is stopped is contradicted by the evidence.

Trap 3: svchost.exe hosting BFE and MpsSvc indicates a firewall bypass

svchost.exe is a shared host process that loads dozens of Windows services from DLLs, and BFE (Base Filtering Engine) plus MpsSvc (Windows Firewall) are expected residents in a standard svchost instance. Their presence simply reflects normal service hosting, not a firewall bypass. A real bypass would require evidence such as disabled firewall rules, a tampered filter driver, or a malicious DLL injected into the service host, none of which appears in this exhibit.

A
services.exe PID 4321 is a known malware process
Why it fails: services.exe is the Windows Service Control Manager, a legitimate system process responsible for managing services, and its PID is assigned dynamically at boot. There is no known malware variant called 'services.exe' that can be identified by PID alone; malware authors frequently reuse the same file name to blend in, so the PID does not constitute a threat indicator.
B
Windows Defender service is stopped, allowing malware to run
Why it fails: The exhibit displays a service state of 4, which corresponds to SERVICE_RUNNING in the Windows SCM, not a stopped state. When a service is stopped, the state code is 1 (SERVICE_STOPPED), so Windows Defender is demonstrably active in this output. Even a running antivirus does not guarantee the system is clean, but the specific assertion that Defender is stopped is contradicted by the evidence.
C
services.exe is listening on TCP port 4444, indicating possible code injection
services.exe is the Windows Service Control Manager and should never expose listening TCP endpoints on its own; its normal IPC is via a named pipe used by subprocesses, not a network socket. Port 4444 is a well-known default payload port for Metasploit's meterpreter and is frequently used by backdoors, so an established listening socket on services.exe is a classic sign of injected shellcode. Because services.exe runs as SYSTEM, attackers often inject code into it to steal its high privileges and evade detection.
D
svchost.exe hosting BFE and MpsSvc indicates a firewall bypass
Why it fails: svchost.exe is a shared host process that loads dozens of Windows services from DLLs, and BFE (Base Filtering Engine) plus MpsSvc (Windows Firewall) are expected residents in a standard svchost instance. Their presence simply reflects normal service hosting, not a firewall bypass. A real bypass would require evidence such as disabled firewall rules, a tampered filter driver, or a malicious DLL injected into the service host, none of which appears in this exhibit.

Question 14hardmultiple choice

You are investigating a Windows 10 workstation that exhibits slow performance and frequent pop-ups. The user reports that the system started acting strangely after installing a 'PDF Converter' from an email attachment. You suspect malware. You have captured a memory dump using FTK Imager and a network capture during the infection. In the memory dump, you find a suspicious process 'conhost.exe' running from a non-standard location (C:\Users\Public\Temp). The process has an open handle to a file named 'config.ini' in the same directory. The network capture shows periodic HTTPS connections to 'malicious.com' on port 443 from the workstation's IP. Using Volatility, you extract the process's command line: 'conhost.exe -hidden -log C:\Users\Public\Temp\output.log'. Which of the following is the BEST immediate course of action to contain the threat and preserve evidence?

Trap 1: Delete the config.ini file and the conhost.exe executable…

Immediately deleting config.ini and conhost.exe destroys potential digital evidence, including file metadata (creation/modification times) and the actual malware code needed for reverse engineering. Conhost.exe is a legitimate Windows Console Host binary, so its presence alone is not conclusive; without preservation, you cannot determine if it is benign or injected with malicious code. Additionally, if the malware uses persistence mechanisms such as scheduled tasks or Run registry keys, these files may be recreated, and reckless deletion may trigger the malware's anti-forensics or integrity checks, causing further system damage.

Trap 2: Restore the system to a previous restore point.

System Restore only reverts protected system files and select registry keys, leaving many malware artifacts—such as executables in user directories, alternate data streams, or modified DLLs—untouched. It can also overwrite the very restore points and log files that would have documented the infection timeline, destroying critical evidence and corrupting the forensic record. Furthermore, advanced malware can survive restore operations by hiding in volumes shadow copies or by reinstalling itself upon reboot, so this action neither removes the threat nor preserves a sound evidentiary foundation.

Trap 3: Terminate the suspicious conhost.exe process and run a full…

Terminating the conhost.exe process eliminates volatile memory artifacts—such as injected code, decrypted credentials, active network connections, and in-memory payloads—that are invaluable for determining the scope and nature of the compromise. A full antivirus scan on a live, potentially infected system is unreliable because malware can subvert scanning APIs, disable the AV, or hide in memory; signature-based detection also misses unknown or polymorphic variants. Even if the scan finds threats, persistence mechanisms ensure reinfection, while the act of running AV tools alters system state and may alert the attacker, triggering destructive anti-forensic behavior.

A
Delete the config.ini file and the conhost.exe executable immediately.
Why it fails: Immediately deleting config.ini and conhost.exe destroys potential digital evidence, including file metadata (creation/modification times) and the actual malware code needed for reverse engineering. Conhost.exe is a legitimate Windows Console Host binary, so its presence alone is not conclusive; without preservation, you cannot determine if it is benign or injected with malicious code. Additionally, if the malware uses persistence mechanisms such as scheduled tasks or Run registry keys, these files may be recreated, and reckless deletion may trigger the malware's anti-forensics or integrity checks, causing further system damage.
B
Restore the system to a previous restore point.
Why it fails: System Restore only reverts protected system files and select registry keys, leaving many malware artifacts—such as executables in user directories, alternate data streams, or modified DLLs—untouched. It can also overwrite the very restore points and log files that would have documented the infection timeline, destroying critical evidence and corrupting the forensic record. Furthermore, advanced malware can survive restore operations by hiding in volumes shadow copies or by reinstalling itself upon reboot, so this action neither removes the threat nor preserves a sound evidentiary foundation.
C
Terminate the suspicious conhost.exe process and run a full antivirus scan.
Why it fails: Terminating the conhost.exe process eliminates volatile memory artifacts—such as injected code, decrypted credentials, active network connections, and in-memory payloads—that are invaluable for determining the scope and nature of the compromise. A full antivirus scan on a live, potentially infected system is unreliable because malware can subvert scanning APIs, disable the AV, or hide in memory; signature-based detection also misses unknown or polymorphic variants. Even if the scan finds threats, persistence mechanisms ensure reinfection, while the act of running AV tools alters system state and may alert the attacker, triggering destructive anti-forensic behavior.
D
Isolate the workstation from the network, then create a forensic image of the hard disk for analysis.
Isolating the workstation from the network by disconnecting the cable or disabling the NIC immediately severs Command & Control (C2) channels and halts any lateral movement to other hosts, preserving the network flow data and the current state of live connections. Creating a forensic image of the hard disk using a write-blocker and bit-for-bit imaging tools maintains the integrity of evidence, allowing recovery of deleted files, unallocated space, and file system slack that may contain residual malware or attacker artifacts. This evidence-preserving approach aligns with forensic best practices, keeps proper chain of custody, and enables thorough static and dynamic analysis in a controlled lab environment—unlike the destructive or ineffective alternatives.

Question 15mediummultiple choice

Refer to the exhibit. During a malware investigation, a forensic analyst runs the commands shown. What is the most likely conclusion?

Exhibit

Refer to the exhibit.

C:\> tasklist /svc
Image Name                     PID Services
========================= ======== ============================================
svchost.exe                   1236 CryptSvc, Dnscache, LmHosts, EventSystem
svchost.exe                   1344 W32Time, WdiServiceHost
svchost.exe                    768 BFE, MpsSvc
notepad.exe                   1456 N/A
svchost.exe                    524 SessionEnv, TermService, UmRdpService
rundll32.exe                  1500 N/A

C:\> netstat -ano | findstr :4444
  TCP    0.0.0.0:4444           0.0.0.0:0              LISTENING       1500

C:\> wmic process where processid=1500 get executablepath
ExecutablePath
C:\Windows\System32\rundll32.exe

Trap 1: Svchost.exe processes are hosting legitimate Windows services; no…

While it is true that Windows routinely runs multiple svchost.exe instances to host a variety of legitimate system services, the exhibit shows a network socket bound to port 4444, which is not a standard service port. Any process, including svchost.exe, listening on port 4444 is highly anomalous and typically indicates a backdoor or command-and-control channel. This option simply dismisses the suspicious connection, so it fails to recognize the evidence of compromise.

Trap 2: The malware has injected code into svchost.exe using a reflective…

Reflective DLL injection is a sophisticated technique that loads a malicious DLL entirely from memory into a process without touching disk, but there is no indication in the exhibit that svchost.exe has been injected in this manner. The observed suspicious traffic and listening socket are attributed to rundll32.exe with PID 1500, not to svchost.exe. Thus, this option incorrectly attributes the infection to the wrong process and misreads the network evidence.

Trap 3: The malware is using port 4444 for Windows Update communications.

Windows Update communicates over HTTP/HTTPS, typically using TCP ports 80 and 443, to reach Microsoft's servers; it never uses port 4444. Port 4444 is a common default for Metasploit payloads, EternalBlue exploits, and other remote-access Trojans. Therefore, this option is factually impossible because the port usage does not align with Windows Update's known networking behavior.

A
Svchost.exe processes are hosting legitimate Windows services; no malware is present.
Why it fails: While it is true that Windows routinely runs multiple svchost.exe instances to host a variety of legitimate system services, the exhibit shows a network socket bound to port 4444, which is not a standard service port. Any process, including svchost.exe, listening on port 4444 is highly anomalous and typically indicates a backdoor or command-and-control channel. This option simply dismisses the suspicious connection, so it fails to recognize the evidence of compromise.
B
The malware has injected code into svchost.exe using a reflective DLL injection tool.
Why it fails: Reflective DLL injection is a sophisticated technique that loads a malicious DLL entirely from memory into a process without touching disk, but there is no indication in the exhibit that svchost.exe has been injected in this manner. The observed suspicious traffic and listening socket are attributed to rundll32.exe with PID 1500, not to svchost.exe. Thus, this option incorrectly attributes the infection to the wrong process and misreads the network evidence.
C
The malware is using port 4444 for Windows Update communications.
Why it fails: Windows Update communicates over HTTP/HTTPS, typically using TCP ports 80 and 443, to reach Microsoft's servers; it never uses port 4444. Port 4444 is a common default for Metasploit payloads, EternalBlue exploits, and other remote-access Trojans. Therefore, this option is factually impossible because the port usage does not align with Windows Update's known networking behavior.
D
Rundll32.exe with PID 1500 is likely a backdoor listening on port 4444.
rundll32.exe is a legitimate Windows binary used to load and execute functions exported from DLLs, but by default it does not create network listeners. When a rundll32 process is observed listening on TCP port 4444—a port heavily associated with Metasploit and backdoor payloads—it strongly suggests that the process has loaded a malicious DLL that opens a remote command shell. The combination of an unusual process acting as a network server on a non-standard port is classic evidence of a backdoor.

Question 16easymultiple choice

You are a forensic analyst investigating a Windows workstation that shows signs of malware infection. The user reports that the system is slow, network activity is high, and several files have been encrypted with a .encrypted extension. A ransom note named README.txt has been left on the desktop demanding payment. You have acquired a memory dump using FTK Imager and a disk image using dd. You need to identify the malware family and gather indicators of compromise (IOCs). Which of the following is the MOST appropriate first step?

Trap 1: Run the malware sample in a sandbox environment to observe its…

Sandboxing the malware sample is a valid later step, but as a first action it violates basic forensic triage because the ransomware binary may not have been properly recovered, isolated, or hashed from the evidence image; running an unvalidated sample risks accidental re-infection or incomplete behavioral capture due to sandbox evasion. The ransom note, by contrast, contains non-executable textual IOCs that immediately identify the family without needing to execute unknown code. Moreover, behavioral analysis should be performed on the actual sample extracted from the memory dump or disk image, not as a substitute for reading the victim's leave-behind note, and doing so prematurely could bypass the low-risk intelligence coup the note provides.

Trap 2: Perform static analysis of the encrypted files to determine the…

Static analysis of encrypted files is largely an exercise in frustration because the ciphertext yields little to no useful information about the encryption algorithm or the key—most modern ransomware use hybrid cryptography (e.g., AES for bulk data and RSA or ECC for key wrapping), and without the private key or known plaintext, you cannot recover meaningful data or derive variant indicators from the file contents alone. The encrypted files' extensions or headers might hint at a family, but those are far less specific than the unique wallet addresses and contact data in the ransom note. The correct investigative step is to leverage the note's embedded identifiers to look up the known encryption scheme from public threat research, rather than attempting to reverse-engineer the algorithm from ciphertext.

Trap 3: Immediately disconnect the system from the network and power it off…

While disconnecting the network is a sound containment measure, immediately powering off the system is contraindicated because you have already captured a memory dump—the most volatile evidence—and a hard shutdown will destroy transitional data, such as encryption keys lingering in RAM, running process state, and open network connections, that could be crucial for decryption. A forensic analyst should perform orderly shutdown procedures only after all volatile evidence has been collected and after documenting the system state; halting the system first would also lose any ransomware artifacts still only in memory, including the in-memory malware code itself. Since the memory dump is already taken, the next logical step is not to power off but to examine easily accessible non-volatile artifacts like the ransom note to progress the investigation without evidence loss.

A
Extract the ransom note and search for known ransomware identifiers such as Bitcoin wallet addresses or contact email.
Ransom notes typically contain unique attribution artifacts—Bitcoin/cryptocurrency wallet addresses, victim IDs, Tor payment portal URLs, or contact emails—that can be cross-referenced against threat intelligence feeds (e.g., Abuse.ch, NoMoreRansom, or vendor reports) to pinpoint the exact ransomware family and, often, the specific variant and version. Extracting and parsing these identifiers is non-destructive, requires no special tooling, and gives the analyst a focused search target before investing time in malware dynamic analysis. This IOC-led approach is the fastest way to transition from an unknown incident to a known threat profile, enabling immediate acquisition of family-specific decryption tools, YARA rules, and network indicators.
B
Run the malware sample in a sandbox environment to observe its behavior.
Why it fails: Sandboxing the malware sample is a valid later step, but as a first action it violates basic forensic triage because the ransomware binary may not have been properly recovered, isolated, or hashed from the evidence image; running an unvalidated sample risks accidental re-infection or incomplete behavioral capture due to sandbox evasion. The ransom note, by contrast, contains non-executable textual IOCs that immediately identify the family without needing to execute unknown code. Moreover, behavioral analysis should be performed on the actual sample extracted from the memory dump or disk image, not as a substitute for reading the victim's leave-behind note, and doing so prematurely could bypass the low-risk intelligence coup the note provides.
C
Perform static analysis of the encrypted files to determine the encryption algorithm used.
Why it fails: Static analysis of encrypted files is largely an exercise in frustration because the ciphertext yields little to no useful information about the encryption algorithm or the key—most modern ransomware use hybrid cryptography (e.g., AES for bulk data and RSA or ECC for key wrapping), and without the private key or known plaintext, you cannot recover meaningful data or derive variant indicators from the file contents alone. The encrypted files' extensions or headers might hint at a family, but those are far less specific than the unique wallet addresses and contact data in the ransom note. The correct investigative step is to leverage the note's embedded identifiers to look up the known encryption scheme from public threat research, rather than attempting to reverse-engineer the algorithm from ciphertext.
D
Immediately disconnect the system from the network and power it off to preserve evidence.
Why it fails: While disconnecting the network is a sound containment measure, immediately powering off the system is contraindicated because you have already captured a memory dump—the most volatile evidence—and a hard shutdown will destroy transitional data, such as encryption keys lingering in RAM, running process state, and open network connections, that could be crucial for decryption. A forensic analyst should perform orderly shutdown procedures only after all volatile evidence has been collected and after documenting the system state; halting the system first would also lose any ransomware artifacts still only in memory, including the in-memory malware code itself. Since the memory dump is already taken, the next logical step is not to power off but to examine easily accessible non-volatile artifacts like the ransom note to progress the investigation without evidence loss.

Question 17mediummultiple choice

A forensic examiner is analyzing a potentially malicious Portable Executable (PE) file recovered from a compromised host. The examiner uses PEStudio to inspect the file and notices that the Import Address Table (IAT) contains only two functions: LoadLibraryA and GetProcAddress. Which of the following does this most likely indicate?

Trap 1: The file is a legitimate system component that relies on dynamic…

Legitimate system components typically import numerous functions from various DLLs, not just two. Relying solely on LoadLibraryA and GetProcAddress is unusual for normal binaries and is a hallmark of malware attempting to hide its functionality. Performance optimization does not explain such a minimal import table; such optimization would still require additional imports for core functionality.

Trap 2: The malware is written in a high-level language such as C#, which…

A .NET assembly would not have a traditional PE import table like native executables; it would have a CLR header and metadata. The presence of LoadLibraryA and GetProcAddress in the IAT suggests a native binary, not a managed .NET assembly. Thus, this option incorrectly attributes the characteristic to a .NET compilation artifact.

Trap 3: The file is packed with a commercial packer, which automatically…

While packers often obscure imports, they typically still leave a minimal set of imports needed for unpacking, which may include more than just LoadLibraryA and GetProcAddress. The presence of only these two functions is more specifically indicative of deliberate dynamic API resolution rather than a generic packer artifact. Assuming a packer here would be a premature conclusion.

A
The file is a legitimate system component that relies on dynamic linking for performance optimization.
Why it fails: Legitimate system components typically import numerous functions from various DLLs, not just two. Relying solely on LoadLibraryA and GetProcAddress is unusual for normal binaries and is a hallmark of malware attempting to hide its functionality. Performance optimization does not explain such a minimal import table; such optimization would still require additional imports for core functionality.
B
The malware uses dynamic API resolution to hide its true capabilities from static analysis tools.
When a PE file imports only LoadLibraryA and GetProcAddress, it indicates that the malware resolves other API functions at runtime. This technique, known as dynamic API resolution, evades static analysis because the actual functions used are not listed in the import table. Analysts must then resort to dynamic analysis or manual unpacking to uncover the full behavior of the sample.
C
The malware is written in a high-level language such as C#, which compiles to a .NET assembly and has a minimal IAT.
Why it fails: A .NET assembly would not have a traditional PE import table like native executables; it would have a CLR header and metadata. The presence of LoadLibraryA and GetProcAddress in the IAT suggests a native binary, not a managed .NET assembly. Thus, this option incorrectly attributes the characteristic to a .NET compilation artifact.
D
The file is packed with a commercial packer, which automatically reduces the import table to these two functions.
Why it fails: While packers often obscure imports, they typically still leave a minimal set of imports needed for unpacking, which may include more than just LoadLibraryA and GetProcAddress. The presence of only these two functions is more specifically indicative of deliberate dynamic API resolution rather than a generic packer artifact. Assuming a packer here would be a premature conclusion.

Question 18hardmulti select

A forensic analyst is investigating a malware incident on a Windows system and suspects that the malware uses process injection to execute malicious code within a legitimate process. The analyst has acquired a memory dump of the system. Which two of the following techniques should the analyst use to detect and analyze process injection? (Choose two.)

Trap 1: Analyze network traffic captures for signs of data exfiltration…

While network traffic analysis can reveal malicious communication, it does not directly detect process injection. The question asks for techniques to detect and analyze process injection from a memory dump. Network captures are separate from memory analysis and would not show the injection itself. Thus, this technique is not suitable for the specific requirement.

Trap 2: Check the Windows event logs for process creation events with…

Event logs can indicate suspicious process behavior, but they do not directly detect process injection from a memory dump. Process injection often occurs within an existing process, so it may not generate new process creation events. While parent-child anomalies can hint at malicious activity, they are not specific to injection and are not derived from memory analysis.

Trap 3: Run a full antivirus scan on the memory dump file to detect known…

Antivirus scanning of a memory dump is not a reliable method for detecting process injection because it relies on signatures that may not be present in memory or may be obfuscated. Moreover, antivirus tools are not designed to interpret memory dumps and may miss injected code that is not recognized as malicious. This approach is ineffective for the specific task of identifying process injection artifacts.

A
Analyze network traffic captures for signs of data exfiltration from the injected process.
Why it fails: While network traffic analysis can reveal malicious communication, it does not directly detect process injection. The question asks for techniques to detect and analyze process injection from a memory dump. Network captures are separate from memory analysis and would not show the injection itself. Thus, this technique is not suitable for the specific requirement.
B
Check the Windows event logs for process creation events with unusual parent-child relationships.
Why it fails: Event logs can indicate suspicious process behavior, but they do not directly detect process injection from a memory dump. Process injection often occurs within an existing process, so it may not generate new process creation events. While parent-child anomalies can hint at malicious activity, they are not specific to injection and are not derived from memory analysis.
C
Use the Volatility command malfind to identify hidden or injected code in process memory.
The Volatility plugin malfind is designed to detect hidden or injected code in process memory by scanning for memory regions with suspicious characteristics, such as executable permissions and no corresponding file on disk. It is a standard tool for memory forensics and can reveal injected code from techniques like process hollowing or DLL injection. This directly addresses the scenario.
D
Run a full antivirus scan on the memory dump file to detect known malware signatures.
Why it fails: Antivirus scanning of a memory dump is not a reliable method for detecting process injection because it relies on signatures that may not be present in memory or may be obfuscated. Moreover, antivirus tools are not designed to interpret memory dumps and may miss injected code that is not recognized as malicious. This approach is ineffective for the specific task of identifying process injection artifacts.
E
Examine the memory dump for discrepancies between the executable sections on disk and those in memory.
Process injection often involves injecting code into the memory space of a legitimate process, causing the in-memory executable sections to differ from the on-disk version. By comparing the disk image of the executable with its memory-resident image, an analyst can identify injected code or modifications. This technique is effective for detecting classic injection methods like reflective DLL injection or shellcode injection.

Question 19easymultiple choice

A forensic investigator is examining a suspicious file and wants to determine its true file type regardless of its extension. The investigator runs the 'file' command on the file and receives the output 'PE32 executable (GUI) Intel 80386, for MS Windows'. However, the file has a .txt extension. What is the most likely explanation for this discrepancy?

Trap 1: The file is a shortcut file (.lnk) that has been renamed to .txt,…

Shortcut files have a distinct structure and would not be identified as PE32 executables by the 'file' command. The 'file' command is reliable for distinguishing between .lnk and PE files. Misidentification is unlikely. Therefore, this option is incorrect; the file is more likely a true executable with a misleading extension.

Trap 2: The file is a text file that has been mistakenly identified by the…

The 'file' command identifies file types based on magic numbers and content, not extension. If it reports PE32 executable, the file contains a valid PE header, which is not typical for a text file. A text file would be identified as ASCII text or similar, not as a PE executable. Thus, this option is incorrect.

Trap 3: The file is a polyglot file that is both a valid text file and a…

While polyglot files exist, the 'file' command output indicates a PE32 executable, not a polyglot. A polyglot might show multiple types or be identified as one type depending on the tool. The scenario does not suggest polyglot behavior; the most straightforward explanation is a renamed executable. Assuming polyglot without further evidence is speculative.

A
The file is a Windows executable that has been renamed with a .txt extension to evade detection or confuse users.
Malware often uses misleading file extensions to disguise executables. The 'file' command correctly identifies the file as a PE32 executable based on its header, despite the .txt extension. This indicates deliberate renaming, a common tactic to bypass security controls that rely on extension-based filtering or to trick users into opening the file. The investigator should treat it as an executable.
B
The file is a shortcut file (.lnk) that has been renamed to .txt, but the 'file' command misidentifies it as an executable.
Why it fails: Shortcut files have a distinct structure and would not be identified as PE32 executables by the 'file' command. The 'file' command is reliable for distinguishing between .lnk and PE files. Misidentification is unlikely. Therefore, this option is incorrect; the file is more likely a true executable with a misleading extension.
C
The file is a text file that has been mistakenly identified by the 'file' command due to its content.
Why it fails: The 'file' command identifies file types based on magic numbers and content, not extension. If it reports PE32 executable, the file contains a valid PE header, which is not typical for a text file. A text file would be identified as ASCII text or similar, not as a PE executable. Thus, this option is incorrect.
D
The file is a polyglot file that is both a valid text file and a valid executable.
Why it fails: While polyglot files exist, the 'file' command output indicates a PE32 executable, not a polyglot. A polyglot might show multiple types or be identified as one type depending on the tool. The scenario does not suggest polyglot behavior; the most straightforward explanation is a renamed executable. Assuming polyglot without further evidence is speculative.