Scenario practice questions

An analyst finds evidence that an attacker used steganography to hide data within image files on the suspect's computer. Which of the following tools is MOST appropriate for detecting steganography in these images?

Trap 1: Foremost

Foremost is a file carving tool that recovers deleted files by scanning raw disk images for file headers and footers, reassembling fragmented data based on known file signatures. It can extract images from unallocated space but does not inspect the content or encoding of those files for hidden messages, so it cannot determine whether steganography was used.

Trap 2: Autopsy

Autopsy is a comprehensive digital forensics platform with a graphical interface and modular ingest modules for analyzing disk images, browser history, and artifacts. Although some Autopsy modules may integrate third-party steganography detectors, the platform itself is not a dedicated steganography detection tool; Stegdetect is specifically engineered for that narrow purpose and is more directly applicable to the reported evidence.

Trap 3: Volatility

Volatility is a memory forensics framework designed to analyze RAM dumps, extracting running processes, network connections, and injected code from volatile memory. While steganographic payloads might be present in memory as loaded data, Volatility does not scan image files for steganographic signatures; its purpose is memory artifact extraction, not image content analysis.

A
Foremost
Why it fails: Foremost is a file carving tool that recovers deleted files by scanning raw disk images for file headers and footers, reassembling fragmented data based on known file signatures. It can extract images from unallocated space but does not inspect the content or encoding of those files for hidden messages, so it cannot determine whether steganography was used.
B
Autopsy
Why it fails: Autopsy is a comprehensive digital forensics platform with a graphical interface and modular ingest modules for analyzing disk images, browser history, and artifacts. Although some Autopsy modules may integrate third-party steganography detectors, the platform itself is not a dedicated steganography detection tool; Stegdetect is specifically engineered for that narrow purpose and is more directly applicable to the reported evidence.
C
Stegdetect
Stegdetect is a specialized static analysis tool that scans image files for signatures of common steganographic algorithms such as jsteg, outguess, and F5. It performs statistical tests and histogram analysis on JPEG coefficients to identify embedded payloads, making it the most direct and purpose-built choice for confirming steganographic content in a suspected image.
D
Volatility
Why it fails: Volatility is a memory forensics framework designed to analyze RAM dumps, extracting running processes, network connections, and injected code from volatile memory. While steganographic payloads might be present in memory as loaded data, Volatility does not scan image files for steganographic signatures; its purpose is memory artifact extraction, not image content analysis.

Question 2hardmultiple choice

A forensic analyst is examining a RAID 5 array consisting of three disks. One disk has failed and has been replaced. The array is rebuilt automatically. However, the analyst needs to recover deleted files that existed before the rebuild. What is the MOST significant challenge in this scenario?

Trap 1: File carving techniques do not work on RAID volumes

Carving can work if data is not overwritten, but rebuild increases overwrite.

Trap 2: The file system becomes corrupted after rebuild

RAID rebuild does not corrupt file system; it restores redundancy.

Trap 3: The RAID controller encrypts data, preventing direct disk access

RAID 5 does not inherently encrypt.

A
File carving techniques do not work on RAID volumes
Why it fails: Carving can work if data is not overwritten, but rebuild increases overwrite.
B
The rebuild process may overwrite data in slack space and previously unallocated clusters
Rebuilding RAID 5 writes new parity and data, overwriting free space and slack.
C
The file system becomes corrupted after rebuild
Why it fails: RAID rebuild does not corrupt file system; it restores redundancy.
D
The RAID controller encrypts data, preventing direct disk access
Why it fails: RAID 5 does not inherently encrypt.

Question 3easymultiple choice

Which forensic tool is specifically designed to recover lost partitions or file system structures and can also be used for data carving?

Trap 1: Sleuth Kit

Sleuth Kit analyses existing file system images and recovers deleted files within an intact structure; it does not rebuild lost partitions, which is the scenario's requirement. It is tempting because it performs file system forensics, and would be correct for examining a mounted image's directory entries and metadata.

Trap 2: EnCase

EnCase acquires and analyses disk images and recovers deleted files, but partition table reconstruction and file system repair are not its designed function. It is tempting because it is a full forensic suite, and would be correct for imaging a suspect drive and examining artefacts within an intact file system.

Trap 3: Volatility

Volatility parses memory captures for running processes, network connections and injected code; it does not rebuild partition tables or file system structures, nor carve files from unallocated space. It is tempting because it is a forensic tool, and would be correct for live memory analysis of a compromised host.

A
Sleuth Kit
Why it fails: Sleuth Kit analyses existing file system images and recovers deleted files within an intact structure; it does not rebuild lost partitions, which is the scenario's requirement. It is tempting because it performs file system forensics, and would be correct for examining a mounted image's directory entries and metadata.
B
EnCase
Why it fails: EnCase acquires and analyses disk images and recovers deleted files, but partition table reconstruction and file system repair are not its designed function. It is tempting because it is a full forensic suite, and would be correct for imaging a suspect drive and examining artefacts within an intact file system.
C
TestDisk
TestDisk rebuilds damaged partition tables and lost file system structures, and its bundled PhotoRec component performs file carving from unallocated space. This satisfies the stem's dual requirement, whereas tools such as Autopsy or EnCase analyse acquired images rather than repairing partition structures.
D
Volatility
Why it fails: Volatility parses memory captures for running processes, network connections and injected code; it does not rebuild partition tables or file system structures, nor carve files from unallocated space. It is tempting because it is a forensic tool, and would be correct for live memory analysis of a compromised host.

Question 4mediummultiple choice

During an investigation, an analyst recovers a file from unallocated space that contains fragments of a deleted document. The file size is 512 bytes, but the cluster size of the volume is 4096 bytes. What is the term for the unused bytes between the end of the file and the end of the last cluster?

Trap 1: Volume slack

Volume slack is the unused space that exists after the logical volume's end but before the physical partition's end, created when a volume is created smaller than its partition. During file recovery, data in volume slack is not associated with a file's allocated cluster or its slack space. It is a partition-level artifact, not a per-file allocation artifact, so it cannot describe the unused bytes between the end of a recovered file and the end of its last cluster.

Trap 2: Drive slack

Drive slack is not an accepted or standardized term in forensic science; the recognized slack-space categories are RAM slack and file slack, which reside within a file's final allocated cluster. 'Drive slack' is sometimes colloquially used to refer to unallocated space or partition gaps, but those are separate storage regions, not the leftover bytes in a file's last cluster. Since it has no fixed definition, it is incorrect to select it as the specific artifact containing the remnant data.

Trap 3: RAM slack

RAM slack is specifically the small gap from the end of the file's logical data to the end of the current 512-byte sector, created when the file is written into memory buffers. This is only a tiny subset of file slack—usually less than one sector—whereas file slack continues to the cluster boundary. If the recovered data came from beyond the final sector, it would reside in the remaining file slack, not RAM slack, making RAM slack an incomplete and incorrect choice.

A
Volume slack
Why it fails: Volume slack is the unused space that exists after the logical volume's end but before the physical partition's end, created when a volume is created smaller than its partition. During file recovery, data in volume slack is not associated with a file's allocated cluster or its slack space. It is a partition-level artifact, not a per-file allocation artifact, so it cannot describe the unused bytes between the end of a recovered file and the end of its last cluster.
B
Drive slack
Why it fails: Drive slack is not an accepted or standardized term in forensic science; the recognized slack-space categories are RAM slack and file slack, which reside within a file's final allocated cluster. 'Drive slack' is sometimes colloquially used to refer to unallocated space or partition gaps, but those are separate storage regions, not the leftover bytes in a file's last cluster. Since it has no fixed definition, it is incorrect to select it as the specific artifact containing the remnant data.
C
File slack
File slack is the unused bytes from the logical end of a file to the end of the last cluster allocated to that file, and it is the correct location for recovered remnant data. It consists of RAM slack (up to the sector boundary) plus the remaining bytes in the trailing cluster, which are typically not zeroed by the filesystem. Because old data can persist there after a file is overwritten or deleted, forensic examiners regularly recover intact fragments from file slack.
D
RAM slack
Why it fails: RAM slack is specifically the small gap from the end of the file's logical data to the end of the current 512-byte sector, created when the file is written into memory buffers. This is only a tiny subset of file slack—usually less than one sector—whereas file slack continues to the cluster boundary. If the recovered data came from beyond the final sector, it would reside in the remaining file slack, not RAM slack, making RAM slack an incomplete and incorrect choice.

Question 5easymultiple choice

In network forensics, an analyst captures traffic and sees a large number of ICMP echo requests from 10.0.0.1 to 10.0.0.2 with varying payload sizes. What is the most likely scenario?

Trap 1: Network reconnaissance (ping sweep)

A ping sweep is a reconnaissance technique in which an attacker sends ICMP echo requests to multiple different destination IP addresses (or a broadcast address) to discover which hosts are alive on a network. In this capture, the traffic consists of ICMP echo requests from one source to one destination, which is a point-to-point conversation rather than a probe across many targets. The absence of varied destination addresses or sequential host probing means this is not characteristic of network reconnaissance.

Trap 2: A man-in-the-middle attack

A man-in-the-middle (MITM) attack requires an attacker to actively intercept, relay, and potentially alter communications between two legitimate parties, often using techniques such as ARP spoofing, DNS spoofing, or session hijacking. ICMP echo requests are simple network-layer probes that do not carry application data or involve a relayed session between two hosts. Seeing a flood of ICMP echo requests provides no evidence of interception, modification, or an inserted third party, so this scenario cannot be classified as MITM.

Trap 3: A DNS amplification attack

A DNS amplification attack relies on an attacker sending small, spoofed DNS queries to open resolvers, which then send large DNS response messages to the victim's IP address, creating a reflected and amplified flood. The traffic in this scenario is explicitly ICMP echo requests, not UDP/TCP DNS queries or responses on port 53, and the pattern is a single source sending to a single destination rather than many resolvers responding to a spoofed victim. Therefore, the observed ICMP flood does not match the mechanics or signature of DNS amplification.

A
Network reconnaissance (ping sweep)
Why it fails: A ping sweep is a reconnaissance technique in which an attacker sends ICMP echo requests to multiple different destination IP addresses (or a broadcast address) to discover which hosts are alive on a network. In this capture, the traffic consists of ICMP echo requests from one source to one destination, which is a point-to-point conversation rather than a probe across many targets. The absence of varied destination addresses or sequential host probing means this is not characteristic of network reconnaissance.
B
A man-in-the-middle attack
Why it fails: A man-in-the-middle (MITM) attack requires an attacker to actively intercept, relay, and potentially alter communications between two legitimate parties, often using techniques such as ARP spoofing, DNS spoofing, or session hijacking. ICMP echo requests are simple network-layer probes that do not carry application data or involve a relayed session between two hosts. Seeing a flood of ICMP echo requests provides no evidence of interception, modification, or an inserted third party, so this scenario cannot be classified as MITM.
C
A DoS attack using ICMP floods
A large volume of ICMP echo requests (ping) from a single source to a single destination, especially with varying payload sizes, is a classic signature of an ICMP flood DoS attack. The sheer volume of packets consumes the target's bandwidth and processing resources, and the varied payload sizes are often used to defeat filters that block only fixed-size pings. This pattern is distinct from reconnaissance or protocol-specific abuse because it intentionally overwhelms the victim with raw ICMP traffic.
D
A DNS amplification attack
Why it fails: A DNS amplification attack relies on an attacker sending small, spoofed DNS queries to open resolvers, which then send large DNS response messages to the victim's IP address, creating a reflected and amplified flood. The traffic in this scenario is explicitly ICMP echo requests, not UDP/TCP DNS queries or responses on port 53, and the pattern is a single source sending to a single destination rather than many resolvers responding to a spoofed victim. Therefore, the observed ICMP flood does not match the mechanics or signature of DNS amplification.

Question 6easymultiple choice

An Android phone is seized, and the forensic examiner needs to acquire the device in a forensically sound manner. The phone is running Android 12 and has USB debugging enabled. Which acquisition method provides the most complete data without physically modifying the device?

Trap 1: File system acquisition via Cellebrite UFED

Cellebrite UFED's file system acquisition extracts only allocated files and file-system metadata via a higher-level protocol, skipping unallocated space, deleted file remnants, and slack space that often harbor critical evidence. A physical acquisition, by contrast, images the entire flash memory at the block level, so while UFED file system extraction is useful for targeted data triage, it cannot provide the comprehensive evidentiary coverage required for a thorough Android forensic examination.

Trap 2: Logical acquisition through ADB backup

Logical acquisition through ADB backup relies on the Android Backup API and only retrieves application-specific data and system settings that applications choose to expose, typically excluding low-level system partitions, raw user data, and any deleted content. Many apps declare disallowed backup or store data in protected directories, and the resulting archive is not a full file system image, so it cannot recover evidence from unallocated space or validate the integrity of the entire device, significantly limiting its forensic scope.

Trap 3: Manual extraction using screen captures

Manual extraction using screen captures is the least forensically sound method because it relies on an examiner visually scrolling through the device's user interface to photographically record what is displayed, which inherently omits hidden, metadata, and deleted data. It lacks cryptographic hashing or standardized acquisition workflows, so the evidence cannot be authenticated as complete or unaltered, and its reliance on human detail makes it unsuitable for any case requiring a reproducible, defensible chain of custody.

A
File system acquisition via Cellebrite UFED
Why it fails: Cellebrite UFED's file system acquisition extracts only allocated files and file-system metadata via a higher-level protocol, skipping unallocated space, deleted file remnants, and slack space that often harbor critical evidence. A physical acquisition, by contrast, images the entire flash memory at the block level, so while UFED file system extraction is useful for targeted data triage, it cannot provide the comprehensive evidentiary coverage required for a thorough Android forensic examination.
B
Physical acquisition via ADB with appropriate exploit
Physical acquisition via ADB leverages a custom recovery or a privilege-escalation exploit to execute a low-level block device read, such as dd if=/dev/block/mmcblk0 of=/image.dd, yielding a complete bit-for-bit replica of the flash storage. This preserves deleted files, unallocated clusters, file system slack, and application remnants that are absent from logical or file-system extractions, making it the most comprehensive and forensically defensible approach for Android devices when feasible.
C
Logical acquisition through ADB backup
Why it fails: Logical acquisition through ADB backup relies on the Android Backup API and only retrieves application-specific data and system settings that applications choose to expose, typically excluding low-level system partitions, raw user data, and any deleted content. Many apps declare disallowed backup or store data in protected directories, and the resulting archive is not a full file system image, so it cannot recover evidence from unallocated space or validate the integrity of the entire device, significantly limiting its forensic scope.
D
Manual extraction using screen captures
Why it fails: Manual extraction using screen captures is the least forensically sound method because it relies on an examiner visually scrolling through the device's user interface to photographically record what is displayed, which inherently omits hidden, metadata, and deleted data. It lacks cryptographic hashing or standardized acquisition workflows, so the evidence cannot be authenticated as complete or unaltered, and its reliance on human detail makes it unsuitable for any case requiring a reproducible, defensible chain of custody.

Question 7hardmultiple choice

You are a forensic investigator responding to a suspected data breach at a financial institution. The incident response team has isolated a Windows 10 workstation used by a former employee. The system is still powered on, and the login screen is displayed. Your task is to acquire forensic evidence in a defensible manner. The following actions are available:

A. Immediately pull the power cord to perform a cold acquisition of the hard drive. B. Capture volatile data (RAM, network connections, running processes) using a trusted tool on a USB drive, then shut down normally and remove the hard drive for imaging. C. Boot the system from a forensic live CD and create a forensic image of the hard drive while the system is running. D. Use the built-in Windows backup to create a system image to an external drive.

Which action is the most appropriate first step in this scenario?

Trap 1: Use the built-in Windows backup to create a system image to an…

The built-in Windows Backup (e.g., 'Backup and Restore' or 'File History') is a backup utility, not a forensic acquisition tool. It does not create a bit-for-bit copy of the disk; instead, it copies files and system images using Windows' own file system APIs, which can alter access timestamps and fail to capture deleted data, slack space, and unallocated clusters. Running it also writes to the system drive and changes the state of the evidence before any forensic preservation, making it inherently unsound for legal proceedings.

Trap 2: Boot the system from a forensic live CD and create a forensic image…

Booting from a forensic live CD is a common approach for dead acquisition, but doing it *while the system is running* or as a response to a live system is problematic. The boot process itself overwrites RAM (destroying volatile data) and writes temporary files to the disk, changing timestamps and potentially overwriting evidence in unallocated space. Furthermore, if the system is compromised, the live CD may not have a trusted kernel or may be subject to rootkit interference, and imaging a mounted or in-use filesystem can result in an inconsistent, non-forensic image.

Trap 3: Immediately pull the power cord to perform a cold acquisition of…

While a hard power-off (cold acquisition) is sometimes used to preserve disk state when the system is already off or when malware might destroy evidence, it is not the initial step in a live response. Pulling the power cord instantly terminates all running processes and destroys volatile memory, losing critical evidence such as encryption keys, network connections, and active malware in RAM. It also risks filesystem journaling inconsistencies and may trigger write-caching data loss, potentially leaving the disk in an unclean state that complicates analysis and damages the integrity of the acquired image.

A
Use the built-in Windows backup to create a system image to an external drive
Why it fails: The built-in Windows Backup (e.g., 'Backup and Restore' or 'File History') is a backup utility, not a forensic acquisition tool. It does not create a bit-for-bit copy of the disk; instead, it copies files and system images using Windows' own file system APIs, which can alter access timestamps and fail to capture deleted data, slack space, and unallocated clusters. Running it also writes to the system drive and changes the state of the evidence before any forensic preservation, making it inherently unsound for legal proceedings.
B
Capture volatile data using a trusted tool on a USB drive, then shut down normally and remove the hard drive for imaging
This is the correct order because volatile data (RAM, running processes, network connections, open files) is lost the instant the system loses power. Using a trusted, write-protected USB tool to capture this data first ensures the most transient evidence is preserved. A graceful shutdown, unlike a hard power-off, allows the OS to flush and close file structures cleanly, reducing the risk of filesystem corruption, and then removing the drive for a forensic imaging workstation yields a defensible disk image without altering the original.
C
Boot the system from a forensic live CD and create a forensic image of the hard drive while the system is running
Why it fails: Booting from a forensic live CD is a common approach for dead acquisition, but doing it *while the system is running* or as a response to a live system is problematic. The boot process itself overwrites RAM (destroying volatile data) and writes temporary files to the disk, changing timestamps and potentially overwriting evidence in unallocated space. Furthermore, if the system is compromised, the live CD may not have a trusted kernel or may be subject to rootkit interference, and imaging a mounted or in-use filesystem can result in an inconsistent, non-forensic image.
D
Immediately pull the power cord to perform a cold acquisition of the hard drive
Why it fails: While a hard power-off (cold acquisition) is sometimes used to preserve disk state when the system is already off or when malware might destroy evidence, it is not the initial step in a live response. Pulling the power cord instantly terminates all running processes and destroys volatile memory, losing critical evidence such as encryption keys, network connections, and active malware in RAM. It also risks filesystem journaling inconsistencies and may trigger write-caching data loss, potentially leaving the disk in an unclean state that complicates analysis and damages the integrity of the acquired image.

Question 8hardmultiple choice

A forensic examiner is analyzing an Android device that has been factory reset. Which of the following artefacts is MOST likely to still be recoverable from the device's flash memory after a factory reset, assuming no overwrite has occurred?

Trap 1: The GUID Partition Table (GPT)

The GUID Partition Table is a disk partitioning scheme that defines the layout of logical partitions on the storage medium, storing entries for each partition's start, end, type, and attributes. It does not contain user files or any file-level data; it merely describes where partitions like userdata are located. A factory reset neither removes nor rewrites the GPT, so it has no bearing on recoverable user data. Thus, while GPT metadata may persist, it is not a source of recoverable photos or contacts.

Trap 2: The device's encryption keys

Android's file-based encryption (FBE) relies on per-file keys, which are randomly generated during provisioning and typically wrapped with a hardware-bound key from the Trusted Execution Environment (TEE). A factory reset commonly invokes a 'crypto erase' that discards the key-wrapping key, rendering the filesystem cryptographically unrecoverable even if the raw blocks remain intact. Therefore, the encryption keys themselves are not user data and, in fact, are usually intentionally destroyed during reset, making them a specifically wrong choice for recoverable content.

Trap 3: The Android OS system files

The system partition holds the operating system image, including framework, kernel modules, and pre-installed applications, and is mounted as read-only in normal operation. Factory resets do not format or alter the system partition; they only clear the userdata and cache partitions, leaving system files untouched and recoverable but entirely irrelevant to user-generated content. The question targets data created by the device's user, not the shipped OS components, so system files are neither wiped nor a source of recoverable personal data.

A
The GUID Partition Table (GPT)
Why it fails: The GUID Partition Table is a disk partitioning scheme that defines the layout of logical partitions on the storage medium, storing entries for each partition's start, end, type, and attributes. It does not contain user files or any file-level data; it merely describes where partitions like userdata are located. A factory reset neither removes nor rewrites the GPT, so it has no bearing on recoverable user data. Thus, while GPT metadata may persist, it is not a source of recoverable photos or contacts.
B
The device's encryption keys
Why it fails: Android's file-based encryption (FBE) relies on per-file keys, which are randomly generated during provisioning and typically wrapped with a hardware-bound key from the Trusted Execution Environment (TEE). A factory reset commonly invokes a 'crypto erase' that discards the key-wrapping key, rendering the filesystem cryptographically unrecoverable even if the raw blocks remain intact. Therefore, the encryption keys themselves are not user data and, in fact, are usually intentionally destroyed during reset, making them a specifically wrong choice for recoverable content.
C
The Android OS system files
Why it fails: The system partition holds the operating system image, including framework, kernel modules, and pre-installed applications, and is mounted as read-only in normal operation. Factory resets do not format or alter the system partition; they only clear the userdata and cache partitions, leaving system files untouched and recoverable but entirely irrelevant to user-generated content. The question targets data created by the device's user, not the shipped OS components, so system files are neither wiped nor a source of recoverable personal data.
D
User data such as photos and contacts
A factory reset in Android formats the userdata partition by deleting its ext4 or f2fs metadata and marking blocks as free, but it does not necessarily overwrite the underlying sectors on the flash storage. Forensic examiners can therefore carve files from unallocated space using techniques like file signature carving, and if the device's encryption was disabled or the cryptographic keys can be derived/reset, data like photos and contacts may be reconstructed. This is precisely why the examiner should focus on residual user data in unallocated space after a reset.

Question 9hardmultiple choice

An analyst discovers a suspicious file named 'cmd.aspx' in the web root of an IIS server. The file contains ASPX code that executes system commands. The IIS logs show a POST request to '/cmd.aspx' with a 200 status code. Which type of attack is indicated?

Trap 1: SQL injection

SQL injection arises when unsanitized input alters the structure of an SQL query, allowing unauthorized database access or manipulation, and in some configurations may even write data via database-specific file I/O. It does not, by itself, produce a standalone executable .aspx file in the web tree; any file created as a side effect would be a database artifact, not a generic command shell. The observed cmd.aspx artifact is a direct file upload, so the root cause is not query injection.

Trap 2: Cross-site scripting (XSS)

Cross-site scripting (XSS) relies on injecting client-side JavaScript or HTML that executes in a victim's browser, typically to steal credentials, hijack sessions, or deface pages. Because it runs in the browser, XSS cannot execute system commands on the web server, and it produces no server-side executable file. A .aspx file is server-run code controlling the HTTP response, which places it in a completely different category than a stored or reflected XSS payload.

Trap 3: Directory traversal

Directory traversal (path traversal) exploits poor validation of file paths to read files outside the intended web root, such as web.config or /etc/passwd, using sequences like ../ and encoded variants. This flaw is read-oriented and does not create a new file on the server. Even if chained with a write primitive, the attacker still needs an upload mechanism to place cmd.aspx; the defining indicator here is an uploaded executable script, not manipulation of path traversal parameters.

A
Webshell upload
The .aspx extension indicates an ASP.NET server-side script that executes within the IIS worker process. A file named cmd.aspx typically contains C# code that calls System.Diagnostics.Process to spawn system commands, effectively giving an attacker interactive command-line access over HTTP. Its presence in the web root without a correlated legitimate upload points to an uploaded webshell, not an attack that injects ephemeral code or manipulates path parameters.
B
SQL injection
Why it fails: SQL injection arises when unsanitized input alters the structure of an SQL query, allowing unauthorized database access or manipulation, and in some configurations may even write data via database-specific file I/O. It does not, by itself, produce a standalone executable .aspx file in the web tree; any file created as a side effect would be a database artifact, not a generic command shell. The observed cmd.aspx artifact is a direct file upload, so the root cause is not query injection.
C
Cross-site scripting (XSS)
Why it fails: Cross-site scripting (XSS) relies on injecting client-side JavaScript or HTML that executes in a victim's browser, typically to steal credentials, hijack sessions, or deface pages. Because it runs in the browser, XSS cannot execute system commands on the web server, and it produces no server-side executable file. A .aspx file is server-run code controlling the HTTP response, which places it in a completely different category than a stored or reflected XSS payload.
D
Directory traversal
Why it fails: Directory traversal (path traversal) exploits poor validation of file paths to read files outside the intended web root, such as web.config or /etc/passwd, using sequences like ../ and encoded variants. This flaw is read-oriented and does not create a new file on the server. Even if chained with a write primitive, the attacker still needs an upload mechanism to place cmd.aspx; the defining indicator here is an uploaded executable script, not manipulation of path traversal parameters.

Question 10mediummultiple choice

An investigator needs to recover a deleted partition from a disk that originally used an MBR partition table. Which tool can scan the disk for lost partitions and rebuild the partition table?

Trap 1: FTK Imager

FTK Imager is a forensic acquisition and preview tool that creates bit-for-bit disk images, mounts existing images, and exports files from filesystems, but it does not perform low-level partition table reconstruction. It can capture the entire disk or a partition as evidence, yet it relies on the partition metadata being present and valid to enumerate volumes. Consequently, after a partition is deleted, FTK Imager lacks the scanning algorithms to rediscover the lost partition boundaries and rewrite the partition structure.

Trap 2: Autopsy

Autopsy is an open-source digital forensics platform that ingests disk images and applies modules for file recovery, timeline analysis, keyword search, and hash matching, but all of these functions operate on filesystems already recognized by the underlying Sleuth Kit. It does not have a component to scan raw sectors for partition table signatures or rebuild MBR/GPT entries; instead, it assumes the partition layout is intact. Therefore, a deleted partition would be invisible to Autopsy unless the partition was recreated first with a dedicated recovery tool.

Trap 3: PhotoRec

PhotoRec is a file carving utility that scans raw blocks for characteristic file headers and footers to reassemble files such as JPEGs, PDFs, and archives independent of any filesystem structure, but it cannot reconstruct the partition table that organizes the disk into logical volumes. Carving operates on the raw byte stream and preserves individual files, yet it does not recover the partition entry that tells the OS where a volume begins and ends. So PhotoRec could extract data after a partition is lost, but it is not a partition recovery tool.

A
TestDisk
TestDisk is a specialized partition recovery utility that scans raw disk media for the signatures of missing or deleted partition entries, then rebuilds the Master Boot Record (MBR) or GUID Partition Table (GPT) so the original logical volumes become accessible again. Unlike file carvers, it restores the partition-level addressing that the operating system needs before any filesystem or file-level analysis can proceed. This makes it the correct tool when the goal is recovering a deleted partition rather than individual files.
B
FTK Imager
Why it fails: FTK Imager is a forensic acquisition and preview tool that creates bit-for-bit disk images, mounts existing images, and exports files from filesystems, but it does not perform low-level partition table reconstruction. It can capture the entire disk or a partition as evidence, yet it relies on the partition metadata being present and valid to enumerate volumes. Consequently, after a partition is deleted, FTK Imager lacks the scanning algorithms to rediscover the lost partition boundaries and rewrite the partition structure.
C
Autopsy
Why it fails: Autopsy is an open-source digital forensics platform that ingests disk images and applies modules for file recovery, timeline analysis, keyword search, and hash matching, but all of these functions operate on filesystems already recognized by the underlying Sleuth Kit. It does not have a component to scan raw sectors for partition table signatures or rebuild MBR/GPT entries; instead, it assumes the partition layout is intact. Therefore, a deleted partition would be invisible to Autopsy unless the partition was recreated first with a dedicated recovery tool.
D
PhotoRec
Why it fails: PhotoRec is a file carving utility that scans raw blocks for characteristic file headers and footers to reassemble files such as JPEGs, PDFs, and archives independent of any filesystem structure, but it cannot reconstruct the partition table that organizes the disk into logical volumes. Carving operates on the raw byte stream and preserves individual files, yet it does not recover the partition entry that tells the OS where a volume begins and ends. So PhotoRec could extract data after a partition is lost, but it is not a partition recovery tool.

Question 11hardmultiple choice

During a forensic examination of a Windows system infected with ransomware, the analyst finds that the file timestamps (creation, modification, access) for several critical system files have been altered to match legitimate Windows files. Which anti-forensic technique is MOST likely being used?

Trap 1: Data hiding via ADS

Data hiding via Alternate Data Streams (ADS) is an NTFS feature that allows additional data streams to be attached to a file, such as 'file.txt:hidden.exe'. While this can conceal malicious payloads from casual directory listings, it does not modify file timestamps; the original timestamps remain intact. Forensic examiners can detect ADS using tools like streams.exe or through NTFS parsing, making it a distinct technique from timestamp alteration.

Trap 2: Steganography

Steganography involves embedding secret data within other benign files, such as images or audio, by altering their binary content (e.g., LSB substitution). This technique hides the existence of the data itself, but it does not touch file system metadata like MAC times (Modify, Access, Change). Timestamps are preserved unless deliberately changed, and steganalysis focuses on statistical anomalies in the carrier file, not timestamp forensics.

Trap 3: Log wiping

Log wiping specifically targets event logs, such as Windows Event Logs (e.g., Security.evtx), by clearing entries or selectively deleting records to remove traces of an attacker's actions. It does not affect file system timestamps on user files or executables; it only manipulates log files themselves. Therefore, while log wiping is an anti-forensic activity, it is not the technique for modifying file timestamps to evade analysis.

A
Data hiding via ADS
Why it fails: Data hiding via Alternate Data Streams (ADS) is an NTFS feature that allows additional data streams to be attached to a file, such as 'file.txt:hidden.exe'. While this can conceal malicious payloads from casual directory listings, it does not modify file timestamps; the original timestamps remain intact. Forensic examiners can detect ADS using tools like streams.exe or through NTFS parsing, making it a distinct technique from timestamp alteration.
B
Steganography
Why it fails: Steganography involves embedding secret data within other benign files, such as images or audio, by altering their binary content (e.g., LSB substitution). This technique hides the existence of the data itself, but it does not touch file system metadata like MAC times (Modify, Access, Change). Timestamps are preserved unless deliberately changed, and steganalysis focuses on statistical anomalies in the carrier file, not timestamp forensics.
C
Log wiping
Why it fails: Log wiping specifically targets event logs, such as Windows Event Logs (e.g., Security.evtx), by clearing entries or selectively deleting records to remove traces of an attacker's actions. It does not affect file system timestamps on user files or executables; it only manipulates log files themselves. Therefore, while log wiping is an anti-forensic activity, it is not the technique for modifying file timestamps to evade analysis.
D
Timestomping
Timestomping is an anti-forensic technique that deliberately alters a file's timestamps—such as creation, modification, and access times—typically on NTFS by modifying $STANDARD_INFORMATION or $FILE_NAME attributes. Attackers use it to make malicious files appear old, legitimate, or to match expected system activity, thereby evading investigative timelines. Detection often relies on inconsistencies between MFT attributes, USN journal entries, or comparing timestamps against volume shadow copies and prefetch data.

Question 12mediummultiple 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 13mediummultiple choice

During a mobile forensic investigation, an examiner finds that the seized iPhone is locked with a passcode but is running iOS 11. Which acquisition method should the examiner prioritize to obtain the most data without bypassing the passcode?

Trap 1: Physical acquisition using a JTAG tool

Physical acquisition requires passcode bypass or advanced techniques like JTAG, which may not be feasible on iOS 11 without device-specific tools.

Trap 2: File system acquisition using Cellebrite UFED

File system acquisition on iOS 11 typically requires passcode bypass or jailbreak; not possible without it.

Trap 3: Manual acquisition by photographing the screen

Manual acquisition yields only visible data and is not prioritized when more comprehensive methods are available.

A
Physical acquisition using a JTAG tool
Why it fails: Physical acquisition requires passcode bypass or advanced techniques like JTAG, which may not be feasible on iOS 11 without device-specific tools.
B
Logical acquisition via iTunes backup
iTunes backup can be initiated without passcode if device is trusted, and provides access to many artefacts including SMS, contacts, and call history.
C
File system acquisition using Cellebrite UFED
Why it fails: File system acquisition on iOS 11 typically requires passcode bypass or jailbreak; not possible without it.
D
Manual acquisition by photographing the screen
Why it fails: Manual acquisition yields only visible data and is not prioritized when more comprehensive methods are available.

Question 14mediummultiple choice

During a forensic investigation, an analyst uses a tool to capture the contents of RAM from a live Linux system. Which tool is specifically designed for this purpose and can acquire memory over a network or via a local kernel module?

Trap 1: WinPmem

WinPmem targets Windows memory acquisition, not live Linux systems, and lacks the network or loadable kernel module acquisition paths described. It is tempting because it is a genuine memory acquisition tool, and would be correct when capturing RAM from a Windows host.

Trap 2: FTK Imager

FTK Imager captures disk images and static forensic snapshots, not live RAM contents; it lacks a kernel module for volatile memory acquisition and cannot operate over a network to dump memory. It is tempting because it is a widely used forensic tool for creating bit-for-bit copies of storage media, and would be correct for acquiring a hard drive image from a suspect system.

Trap 3: Volatility

Volatility analyses an existing memory image; it does not acquire RAM from a live Linux host over a network or via a kernel module. It is tempting because it is the best-known memory forensics framework, and would be the right choice for parsing and examining a capture already taken.

A
WinPmem
Why it fails: WinPmem targets Windows memory acquisition, not live Linux systems, and lacks the network or loadable kernel module acquisition paths described. It is tempting because it is a genuine memory acquisition tool, and would be correct when capturing RAM from a Windows host.
B
LiME
LiME is a Linux Memory Extractor loadable kernel module that captures RAM from live Linux systems, supporting acquisition over a network or locally. This matches the stem's requirement for a tool designed specifically for live Linux memory capture.
C
FTK Imager
Why it fails: FTK Imager captures disk images and static forensic snapshots, not live RAM contents; it lacks a kernel module for volatile memory acquisition and cannot operate over a network to dump memory. It is tempting because it is a widely used forensic tool for creating bit-for-bit copies of storage media, and would be correct for acquiring a hard drive image from a suspect system.
D
Volatility
Why it fails: Volatility analyses an existing memory image; it does not acquire RAM from a live Linux host over a network or via a kernel module. It is tempting because it is the best-known memory forensics framework, and would be the right choice for parsing and examining a capture already taken.