CHFI Storage Forensics and File System Analysis Practice Question

A forensic analyst is investigating a compromised Linux server running an ext4 file system. The analyst suspects the attacker deleted critical log files (e.g., /var/log/auth.log) and wants to recover them. Which TWO techniques would be MOST effective for recovering the deleted files?

⚠ Common exam trap

The EC-Council CHFI exam often tests the distinction between file system-specific recovery tools (like `extundelete`) and generic file carving tools (like `foremost`), and candidates mistakenly choose `lost+found` thinking it stores all deleted files, when it only holds files recovered from file system corruption.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Running `extundelete` on the partition

Option A is correct because `extundelete` is a specialized utility designed for ext3/ext4 file systems that reads the journal and inode tables to locate and restore recently deleted files, making it ideal for recovering deleted logs like /var/log/auth.log on an ext4 partition. Option C is correct because `foremost` performs file carving by scanning raw disk data for known file headers and footers, which can recover deleted files even when file system metadata (inodes) has been overwritten or is unavailable. Option B is incorrect because `.Trash-1000` is a per-user trash directory used by desktop environments, not a system-wide recovery location, and root-owned logs deleted by an attacker would not be moved there. Option D is incorrect because `lost+found` is used by fsck to reconnect orphaned inodes (files with intact metadata but no directory entry), not to recover files whose inodes were freed upon deletion. Option E is incorrect because `dd` merely creates a bit-for-bit image and `strings` only extracts printable character sequences; neither reconstructs deleted files or their metadata, so this approach is not an effective recovery technique.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Running `extundelete` on the partition
Why this is correct
Running `extundelete` on the partition is the correct approach because extundelete parses the ext3/ext4 journal to locate inodes and data blocks that were marked free after deletion, enabling reconstruction of the original file content even without filesystem metadata. Since system logs are typically removed with `rm`, which bypasses any trash mechanism, the journal often retains enough information to recover them—provided the partition is unmounted or mounted read-only to prevent subsequent writes from overwriting the freed blocks. This makes extundelete the most direct and appropriate forensic recovery method for deleted log files on an ext3/ext4 Linux server.
✗
Checking the `.Trash-1000` folder
Why it's wrong here
Checking the `.Trash-1000` folder is not useful in this scenario because that directory is created by desktop environments (GNOME/KDE) to hold files deleted through the GUI file manager, with the user ID appended (e.g., `.Trash-1000` for UID 1000). On a compromised server, attackers typically delete logs using shell commands like `rm` or `unlink`, which do not move files to a per-user trash folder, and root/system processes never use desktop trash at all. Thus, this folder would be empty or irrelevant for recovering system logs deleted by administrative or attacker actions.
✓
Using `foremost` to perform file carving based on headers and footers
Why this is correct
Using `foremost` to perform file carving is also a valid recovery technique because it scans raw disk blocks for known file signatures (magic bytes, headers, and footers) and reconstructs data without relying on filesystem metadata, which makes it effective even when the journal has been overwritten or inode entries are gone. This is especially valuable for logs that may have been partially overwritten or reside in unallocated space, as carving can pull out recognizable text/file structures regardless of filesystem state. However, it may produce fragmented or incomplete files if the original data was non-contiguous, so it serves as a complementary method rather than a guaranteed complete recovery.
✗
Restoring from the `lost+found` directory
Why it's wrong here
Restoring from the `lost+found` directory is incorrect because `lost+found` is a top-level filesystem directory used exclusively by `fsck` (such as `e2fsck`) to store orphaned inodes and file fragments found during integrity checks after a crash, power loss, or filesystem corruption. Files deleted with `rm` are not moved there—their inodes are unlinked and blocks are freed immediately, so they never appear in `lost+found`. Therefore, checking this directory would only help if the filesystem had suffered an unrelated structural fault; it does not function as a trash or recycle bin for intentionally deleted log files.
✗
Executing `dd if=/dev/sda1 of=image.dd` and analyzing with `strings`
Why it's wrong here
Executing `dd if=/dev/sda1 of=image.dd` to create a bit-for-bit forensic image is a sound evidence-preservation step, but following it with `strings` analysis alone is insufficient for file recovery. `strings` merely extracts printable ASCII/Unicode sequences from the raw byte stream, discarding filesystem structure, file names, timestamps, and block relationships, so it cannot reassemble a coherent log file or reattach it to its original metadata. The resulting image should instead be processed with specialized recovery tools like `extundelete` or `foremost`, which interpret the filesystem or carve by signatures, to actually retrieve deleted log data.

Go deeper

CHFI Storage Forensics and File System Analysis Practice Question

Why each option matters

Option-by-option breakdown

Related to this question