CEH Enumeration and System Hacking Practice Question
After gaining initial access to a Linux server, a penetration tester wants to maintain persistence by creating a backdoor. The tester decides to replace a common system binary with a trojanized version. Which of the following techniques is MOST likely to evade detection by file integrity monitoring (FIM) systems?
⚠ Common exam trap
Candidates often choose Option A, mistakenly believing that matching file size and timestamp is sufficient to evade FIM, but FIM relies on cryptographic hashes, not metadata, to detect changes.
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
✓
Use a kernel-level rootkit that intercepts read operations to present the original binary's content
A kernel-level rootkit can intercept system calls (e.g., open, read) used by FIM tools to verify file integrity. When the FIM queries the trojanized binary, the rootkit returns the original, unmodified content, so the hash or checksum matches the baseline. This subverts detection at the kernel layer, bypassing user-space integrity checks entirely.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Replace the binary with a modified version that has the same file size and timestamp
Why it's wrong here
File Integrity Monitoring (FIM) systems are designed to detect unauthorized changes by calculating and comparing cryptographic hashes (e.g., MD5, SHA256) of monitored files. While an attacker might manipulate file size and timestamp metadata to match the original, altering the binary's content, even slightly, will inevitably result in a different hash value. This hash mismatch is precisely what FIM solutions are configured to flag as an integrity violation, making this method ineffective for evasion.
- ✗
Place the backdoor in a directory that is excluded from FIM monitoring
Why it's wrong here
FIM policies are meticulously configured to monitor critical system directories, such as executable paths like `/bin`, `/usr/bin`, `/sbin`, and configuration directories like `/etc`. While an attacker might attempt to place a backdoor in an unmonitored or excluded directory, such exclusions are usually for non-critical, dynamic data paths (e.g., `/tmp`, log directories) or specific application data. Placing an executable backdoor in such an unusual or excluded location would likely raise suspicion during manual security audits or behavioral analysis, even if FIM doesn't directly alert on the file's presence.
- ✗
Use steganography to hide the backdoor inside an image file
Why it's wrong here
Steganography is a technique for concealing data within other non-secret files, such as images or audio, making its *existence* undetectable to casual observation. However, a backdoor binary must be extracted and executed to function. FIM systems monitor the integrity of *executable* files and critical system components. Hiding a binary within an image does not make the *executable* itself invisible to FIM once it's extracted and placed in an executable path, or if the image file itself is modified and monitored for integrity.
- ✓
Use a kernel-level rootkit that intercepts read operations to present the original binary's content
Why this is correct
A kernel-level rootkit operates within the operating system's kernel, granting it the highest level of privilege and control. By hooking system calls, specifically `read()` operations, the rootkit can intercept requests from the FIM agent to read the compromised binary. Instead of returning the modified, malicious content, the rootkit presents the *original*, untampered content of the binary to the FIM system. This sophisticated deception ensures that the FIM system calculates the expected hash, thus reporting no integrity violation, while the malicious binary continues to execute its payload.
Go deeper
Related to this question
About these practice questions
This CEH question is part of Courseiva's 870-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CEH practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CEH exam.