CEH v13 distinguishes between vertical and horizontal privilege escalation. Vertical escalation occurs when an attacker moves upward in the hierarchy of privileges-such as from a regular user to an administrator or root-by exploiting vulnerabilities, misconfigurations, or insecure privilege boundaries. This allows the attacker to perform tasks that were previously restricted, such as modifying system settings, accessing sensitive data, installing malware, or controlling the entire environment. Horizontal escalation, on the other hand, involves accessing another user's resources at the same privilege level, which the other options describe. Exploiting unquoted service paths or weak access controls may facilitate privilege abuse, but they do not inherently elevate the user to a higher privilege tier unless they specifically lead to administrative execution. The scenario that aligns perfectly with the CEH definition of vertical privilege escalation is the escalation from regular user to administrator.

The scenario describes exploiting HTTPS compression by analyzing differences in encrypted response sizes to infer sensitive data such as authentication values. This matches the CRIME attack, which leverages compression side-channel information leakage within secure communication channels.

A bootkit is the rootkit type that best matches the described behavior because it compromises the system boot process and executes before the operating system fully loads, often before many security controls, drivers, and monitoring services start. CEH materials describe bootkits as a highly persistent class of malware that targets components such as the Master Boot Record, Volume Boot Record, or bootloader. By gaining execution at boot time, a bootkit can load malicious code very early, then hook or tamper with OS loading routines, kernel initialization, or security mechanisms. This early execution is exactly what the scenario emphasizes: the payload runs "before any system-level drivers or services are active," enabling covert control while evading traditional user-mode detection.
This also explains why administrators see suspicious network activity but forensics do not easily find malicious user-level artifacts. Bootkits can hide by manipulating what the OS and security tools can see after startup, including concealing files, processes, registry keys, or even redirecting reads so scanners receive
"clean" data. Because the malicious component is anchored in the boot chain, it can survive reboots and remain present even if many OS-level indicators are cleaned.
A kernel-mode rootkit operates within the OS kernel but typically loads after the OS begins booting and drivers initialize. A hypervisor rootkit relies on virtualization to sit beneath the OS at runtime, but the scenario specifically highlights boot-time execution prior to drivers and services. Firmware rootkits persist in BIOS
/UEFI or device firmware, which is possible, but the most direct match to "boot process compromise below the OS" in CEH terminology is a bootkit.

In CEH v13 Module 14: Cryptography, Serpent is detailed as one of the finalists in the Advanced Encryption Standard (AES) competition, known for its strong security characteristics.
Key Features of Serpent:
128-bit block size, and key sizes of 128, 192, or 256 bits.
Uses 32 rounds of substitution and permutation.
Operates on four 32-bit words per block.
Employs 8 different S-boxes, each with a 4-bit input and 4-bit output.
Designed to provide high security and resistance against differential cryptanalysis.
Option Clarification:
A). TEA: Uses a Feistel structure with simple operations, but not 32 rounds with S-boxes.
B). CAST-128: Has 64-bit block size and fewer rounds.
C). RC5: Variable block and key sizes but doesn't use 32 rounds with fixed S-box design.
D). Serpent: Matches all given features.
Reference:
Module 14 - Symmetric Algorithms and AES Candidates
CEH eBook: AES Finalists - Serpent, Rijndael, RC6, Twofish

The correct answer is B. Launching SQL Injection Attacks because the scenario describes moving beyond merely locating inputs or detecting error behavior and into actively sending injection payloads that successfully alter query logic and change returned results. In a typical CEH-aligned SQL injection workflow, testers begin by identifying where user-controlled input enters the application (forms, URL parameters, cookies, headers), then perform basic tests to detect whether inputs affect backend SQL processing. Once a suspected injection point is found, the next step is to launch SQL injection attempts using crafted inputs designed to manipulate the query and demonstrate impact.
In this case, you "craft and submit multiple malicious inputs," and one payload "successfully manipulates the backend query," causing the application to return "additional appointment data that was not intended to be displayed." That outcome is a clear indicator that exploitation is underway: the injection is not hypothetical- it is functioning and changing the application's behavior in a way that reveals unauthorized data. This is characteristic of executing an SQL injection attack (in-band exploitation), such as using boolean logic manipulation (e.g., conditions that expand result sets) or other query-altering techniques. The emphasis is on the successful manipulation and unauthorized data exposure, which aligns with the attack execution phase.
Why the other options are less correct: Identifying Data Entry Paths would be earlier, when you locate the patient search field as a candidate parameter. Information Gathering and Vulnerability Detection generally refers to discovering and confirming the presence of weaknesses (often via initial probes, errors, or abnormal responses) rather than a confirmed payload that already returns unauthorized data. Database Enumeration is typically the follow-on step once exploitation is confirmed, where the tester extracts metadata such as database names, tables, columns, users, and versions. Here, you are demonstrating the injection's ability to retrieve extra records, which is the exploitation/attack-launch stage, not full enumeration yet.
Therefore, the step being performed is Launching SQL Injection Attacks.