Scenario practice questions

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 wrong: 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 wrong: RAID rebuild does not corrupt file system; it restores redundancy.
D
The RAID controller encrypts data, preventing direct disk access
Why wrong: RAID 5 does not inherently encrypt.

Question 2mediummultiple 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 wrong: 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 wrong: 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 wrong: 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 3easymultiple 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 wrong: 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 wrong: 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 wrong: 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 4easymultiple 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 wrong: 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 wrong: 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 wrong: 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 5hardmultiple 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 wrong: 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 wrong: 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 wrong: 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 6hardmultiple 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 wrong: 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 wrong: 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 wrong: 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 7mediummultiple choice

In an AWS environment, a security analyst detects unusual API calls that created several IAM users with administrative privileges from an unfamiliar IP address. Which AWS service log should be examined first to identify the specific API calls and the IAM user that made them?

Trap 1: Amazon S3 access logs

S3 access logs record requests to S3 buckets, not IAM API calls.

Trap 2: AWS CloudWatch Logs

CloudWatch Logs can aggregate logs but does not itself record API calls; it would contain CloudTrail logs if configured.

Trap 3: AWS Config

AWS Config tracks resource configuration changes, not API call details.

A
Amazon S3 access logs
Why wrong: S3 access logs record requests to S3 buckets, not IAM API calls.
B
AWS CloudWatch Logs
Why wrong: CloudWatch Logs can aggregate logs but does not itself record API calls; it would contain CloudTrail logs if configured.
C
AWS CloudTrail
CloudTrail logs all AWS API calls, making it the primary source for investigating API activity.
D
AWS Config
Why wrong: AWS Config tracks resource configuration changes, not API call details.

Question 8mediummultiple 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 wrong: 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 wrong: 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 wrong: 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 9mediummulti select

Which TWO of the following are valid justifications for a first responder to power off a computer at a crime scene? (Select TWO)

Trap 1: To prevent the computer from overheating

Overheating is not a common justification; proper cooling should be arranged.

Trap 2: To save time during the investigation

This is not a valid justification; integrity is paramount.

Trap 3: The computer is actively being used to commit a crime

If actively used, you may need to capture volatile data first, not power off.

A
To prevent the computer from overheating
Why wrong: Overheating is not a common justification; proper cooling should be arranged.
B
To save time during the investigation
Why wrong: This is not a valid justification; integrity is paramount.
C
The computer is destroying evidence (e.g., running a data wiping program)
Powering off can stop the destruction, but ideally capture volatile data first if possible.
D
The computer is in a hazardous environment (e.g., flooding)
Safety risks may necessitate powering off to prevent electrical hazards.
E
The computer is actively being used to commit a crime
Why wrong: If actively used, you may need to capture volatile data first, not power off.

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 wrong: 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 wrong: 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 wrong: 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.