How should I use these Introduction to Ethical Hacking practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Introduction to Ethical Hacking questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Introduction to Ethical Hacking domain.

CEH · topic practice

Introduction to Ethical Hacking practice questions

Domain 1 of the CEH exam covers hacking phases, hacker classes (white/black/gray hat), attack types, and testing methodologies. Questions test reconnaissance vs. scanning vs. gaining access, black-box vs. white-box vs. gray-box assessments, and tool usage such as Netcat, Nmap, and footprinting utilities. Expect scenario-based items requiring you to identify attack type, tester role, or correct command sequence.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

17 questionsDomain: Introduction to Ethical Hacking

Practice 10 questions Browse domain →

What the exam tests

What to know about Introduction to Ethical Hacking

You must classify a scenario as black-, white-, or gray-box, name the correct hacking phase or attacker type, and order Netcat reverse-shell steps. The single most important thing: match the tester's stated knowledge level to the correct box type before answering.

Black-box, white-box, and gray-box testing scopes and tester knowledge levels

Reconnaissance vs. scanning vs. gaining access vs. maintaining access vs. covering tracks

Hacker classifications: white hat, black hat, gray hat, script kiddie, hacktivist

Netcat reverse shell setup order and basic Nmap footprinting usage

Watch out for

Common Introduction to Ethical Hacking exam traps

▸Confusing gray-box (partial knowledge) with black-box (zero knowledge) when the scenario mentions some internal documentation or credentials.
▸Mixing up passive reconnaissance (no direct target contact) with active scanning that sends packets and may be logged.
▸Reversing Netcat listener and target order, or forgetting the -l -p flags on the listening host before connecting.

Practice set

Introduction to Ethical Hacking questions

17 questions · select your answer, then reveal the explanation

Question 1mediummulti select

Read the full Introduction to Ethical Hacking explanation →

Which TWO of the following are recognized phases of the Ethical Hacking process? (Select TWO.)

Trap 1: Cracking

"Cracking" is a specific technique, primarily associated with password guessing, brute-forcing, or cryptographic attacks, rather than a distinct, overarching phase of the ethical hacking methodology. While cracking passwords or breaking encryption might be employed during the "Gaining Access" or "Maintaining Access" phases to escalate privileges or access protected data, it is a tool or method utilized within those broader phases, not a separate, high-level stage in the penetration testing lifecycle.

Study all Introduction to Ethical Hacking common traps →

A
Maintaining Access
Maintaining Access is a critical phase following successful exploitation, where the ethical hacker focuses on establishing persistent control over the compromised system. This involves deploying backdoors, rootkits, or other persistent mechanisms to ensure re-entry is possible even if initial vulnerabilities are patched or system reboots occur. The primary objective is to retain control for future exploitation, data exfiltration, or further network pivoting without needing to re-exploit the initial entry point.
B
Scanning
While crucial for information gathering, Scanning is not recognized as a standalone primary phase within the standard ethical hacking methodology. It is a key sub-phase of Reconnaissance, specifically active reconnaissance, where tools like Nmap or vulnerability scanners are employed to identify live hosts, open ports, services, and potential vulnerabilities on the target network. Its purpose is to gather detailed technical information that directly informs subsequent exploitation attempts during the Gaining Access phase.
C
Reconnaissance
Reconnaissance is the initial and foundational phase of ethical hacking, involving the systematic gathering of information about the target system, network, or organization. This phase can be passive, utilizing open-source intelligence (OSINT), or active, involving direct interaction like network scanning, to understand the target's infrastructure, technologies, and potential vulnerabilities. It sets the strategic groundwork and informs all subsequent phases of the penetration test.
D
Hiding Evidence
"Hiding Evidence" is not the formally recognized term for this phase within the standard ethical hacking methodology; the correct and more comprehensive term is "Covering Tracks" or "Clearing Tracks." This phase involves systematically removing all traces of the penetration test, such as log entries, temporary files, and modified system configurations, to prevent detection. The goal is to restore the target system to its original state and mimic a real attacker's attempt to evade forensic analysis.
E
Cracking
Why it fails: "Cracking" is a specific technique, primarily associated with password guessing, brute-forcing, or cryptographic attacks, rather than a distinct, overarching phase of the ethical hacking methodology. While cracking passwords or breaking encryption might be employed during the "Gaining Access" or "Maintaining Access" phases to escalate privileges or access protected data, it is a tool or method utilized within those broader phases, not a separate, high-level stage in the penetration testing lifecycle.

Full breakdown with real-world context →

Question 2mediummatching

Read the full Introduction to Ethical Hacking explanation →

Match each network protocol to its well-known port number.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

443

3389

Trap 1: FTP: 22

FTP (File Transfer Protocol) primarily uses TCP port 21 for its control connection, not port 22. Port 21 manages commands and authentication, while data transfers occur over separate data ports, often port 20 or dynamic ports. Port 22 is specifically reserved for the Secure Shell (SSH) protocol, which provides secure remote access and command execution.

Trap 2: SSH: 21

This option is incorrect as SSH (Secure Shell) operates on TCP port 22, not port 21. SSH establishes secure, encrypted connections for remote command-line access, remote file transfer (SFTP), and tunneling services, offering a robust alternative to insecure protocols. Conversely, port 21 is the well-known port assigned to the control channel for the File Transfer Protocol (FTP).

Study all Introduction to Ethical Hacking common traps →

A
HTTP: 80
HTTP, the foundational protocol for data communication on the World Wide Web, exclusively utilizes TCP port 80 for unencrypted client-server interactions. This well-known port facilitates the transfer of HTML pages, images, and other web content, making it the default for standard web browsing. Without specifying a different port, web browsers automatically attempt to connect to port 80 when accessing an HTTP URL.
B
HTTPS: 443
HTTPS, the secure version of HTTP, encrypts web traffic using SSL/TLS protocols over TCP port 443. This dedicated port ensures that all data exchanged between a web browser and a server, including sensitive information like login credentials and financial details, remains confidential and protected from eavesdropping. Its use is critical for secure online transactions and privacy.
C
FTP: 22
Why it fails: FTP (File Transfer Protocol) primarily uses TCP port 21 for its control connection, not port 22. Port 21 manages commands and authentication, while data transfers occur over separate data ports, often port 20 or dynamic ports. Port 22 is specifically reserved for the Secure Shell (SSH) protocol, which provides secure remote access and command execution.
D
SSH: 21
Why it fails: This option is incorrect as SSH (Secure Shell) operates on TCP port 22, not port 21. SSH establishes secure, encrypted connections for remote command-line access, remote file transfer (SFTP), and tunneling services, offering a robust alternative to insecure protocols. Conversely, port 21 is the well-known port assigned to the control channel for the File Transfer Protocol (FTP).
E
DNS: 53
The Domain Name System (DNS) correctly utilizes port 53 for its critical function of translating human-readable domain names into machine-readable IP addresses. DNS queries typically use UDP port 53 for faster, connectionless lookups, while TCP port 53 is employed for zone transfers between DNS servers and for larger responses. This port is fundamental for virtually all internet communications.

Full breakdown with real-world context →

Question 3mediummatching

Read the full Introduction to Ethical Hacking explanation →

Select all that apply: Which of the following IDS/IPS terms are correctly matched to their meanings?

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Alert on benign activity

Failing to detect an actual attack

Detects known attack patterns

Detects deviations from normal behavior

Decoy system to attract attackers

Trap 1: False positive: When the IDS fails to detect an attack

The statement incorrectly defines a false positive. A false positive occurs when an Intrusion Detection System mistakenly identifies legitimate, benign network activity or system behavior as malicious or an attack. This leads to unnecessary alerts, consumes analyst time investigating non-threats, and can desensitize security teams to actual threats if the rate is too high, impacting operational efficiency.

Trap 2: True positive: When the IDS incorrectly flags benign activity

The provided definition for a true positive is incorrect. A true positive, in the context of an IDS, signifies the successful and accurate identification of a genuine malicious activity or attack by the system. This is the desired outcome, where the IDS correctly flags an actual threat, enabling security personnel to respond promptly and mitigate the risk effectively.

Study all Introduction to Ethical Hacking common traps →

A
Signature-based IDS: Uses predefined patterns of known attacks
Signature-based Intrusion Detection Systems operate by comparing network traffic against a comprehensive database of known attack patterns, often called signatures. These signatures are specific byte sequences, header values, or command strings associated with previously identified malware or exploit techniques. This method is highly effective at detecting known threats with low false positive rates, but it is inherently incapable of identifying novel or zero-day attacks for which no signature yet exists.
B
Anomaly-based IDS: Monitors traffic and compares to a baseline
Anomaly-based Intrusion Detection Systems establish a statistical baseline of normal network behavior, encompassing typical traffic volumes, protocol usage, and user activities over time. Any significant deviation from this established baseline is then flagged as a potential security incident, indicating unusual or suspicious activity. This approach offers the advantage of potentially detecting unknown or zero-day attacks that lack predefined signatures, though it often comes with a higher rate of false positives as legitimate new behaviors might initially be flagged.
C
False positive: When the IDS fails to detect an attack
Why it fails: The statement incorrectly defines a false positive. A false positive occurs when an Intrusion Detection System mistakenly identifies legitimate, benign network activity or system behavior as malicious or an attack. This leads to unnecessary alerts, consumes analyst time investigating non-threats, and can desensitize security teams to actual threats if the rate is too high, impacting operational efficiency.
D
False negative: When the IDS fails to detect an attack
A false negative represents a critical failure of an Intrusion Detection System, occurring when an actual malicious attack or security breach successfully evades detection by the system. This means the IDS fails to generate an alert for a genuine threat, allowing an attacker to potentially compromise systems without immediate notice. Such an oversight can have severe consequences, as the organization remains unaware of an ongoing intrusion, delaying response and increasing potential damage.
E
True positive: When the IDS incorrectly flags benign activity
Why it fails: The provided definition for a true positive is incorrect. A true positive, in the context of an IDS, signifies the successful and accurate identification of a genuine malicious activity or attack by the system. This is the desired outcome, where the IDS correctly flags an actual threat, enabling security personnel to respond promptly and mitigate the risk effectively.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Introduction to Ethical Hacking explanation →

A security analyst suspects that an attacker is scanning their network. They notice a large number of TCP SYN packets being sent to various ports on a single host, but no SYN-ACK responses are returned. Which type of scan is most likely being used?

Trap 1: TCP connect scan

A TCP connect scan completes the full three-way handshake, so the target would return SYN-ACK and the scanner would send ACK. It is tempting because it needs no raw-socket privileges, making it the right choice when scanning from an unprivileged account.

Trap 2: UDP scan

A UDP scan sends UDP datagrams and interprets ICMP port-unreachable replies; the stem describes TCP SYN packets with no SYN-ACK, which indicates a half-open TCP scan against filtered or closed ports. UDP scanning is chosen when probing connectionless services such as DNS or SNMP.

Trap 3: FIN scan

A FIN scan sends TCP packets with only the FIN flag set, so the observed SYN packets contradict it. It is tempting because FIN scans probe ports while evading some stateless firewalls and IDS logging, and would be correct where stealth against such filtering matters more than reliable results.

Study all Introduction to Ethical Hacking common traps →

A
TCP connect scan
Why it fails: A TCP connect scan completes the full three-way handshake, so the target would return SYN-ACK and the scanner would send ACK. It is tempting because it needs no raw-socket privileges, making it the right choice when scanning from an unprivileged account.
B
UDP scan
Why it fails: A UDP scan sends UDP datagrams and interprets ICMP port-unreachable replies; the stem describes TCP SYN packets with no SYN-ACK, which indicates a half-open TCP scan against filtered or closed ports. UDP scanning is chosen when probing connectionless services such as DNS or SNMP.
C
SYN scan
A SYN scan sends TCP SYN packets to many ports but never completes the handshake, so no SYN-ACK is returned when ports are closed or filtered. This half-open behaviour matches the observed traffic pattern, distinguishing it from full-connect or UDP scans.
D
FIN scan
Why it fails: A FIN scan sends TCP packets with only the FIN flag set, so the observed SYN packets contradict it. It is tempting because FIN scans probe ports while evading some stateless firewalls and IDS logging, and would be correct where stealth against such filtering matters more than reliable results.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full Introduction to Ethical Hacking explanation →

During a penetration test, an ethical hacker needs to evade an IDS that detects port scans based on the number of packets per second. Which technique would be most effective to avoid detection?

Trap 1: Use random source ports

Using random source ports primarily aims to bypass stateless firewall rules that might block specific source ports or to make traffic analysis slightly more complex by obscuring the origin application. However, this technique does not alter the total number of packets sent per unit of time from the scanning host. Therefore, it is ineffective against Intrusion Detection Systems (IDS) or Intrusion Prevention Systems (IPS) that monitor and trigger alerts based on high packet rates originating from a single source IP address, regardless of the source port used.

Trap 2: Use a decoy scan

A decoy scan involves sending packets from multiple spoofed IP addresses in addition to the actual attacker's IP, making it harder for the target to identify the true source of the scan. While this technique can obscure the attacker's origin, it inherently increases the overall packet volume directed at the target. Each decoy IP, along with the real attacker's IP, contributes to the total packet rate observed by the target's IDS/IPS, potentially increasing the likelihood of triggering rate-based detection thresholds rather than evading them.

Trap 3: Use fragmented packets

Using fragmented packets involves splitting a single packet into multiple smaller fragments, forcing the target system to reassemble them. This technique is primarily effective against signature-based IDS/IPS that might fail to properly reassemble or inspect fragmented packets, thus missing specific attack signatures. However, fragmentation does not reduce the total number of packets sent over the network; in fact, it increases it for a given amount of data. Consequently, it offers no benefit against rate-based detection mechanisms that simply count the volume of packets arriving from a source within a specific timeframe.

Study all Introduction to Ethical Hacking common traps →

A
Use random source ports
Why it fails: Using random source ports primarily aims to bypass stateless firewall rules that might block specific source ports or to make traffic analysis slightly more complex by obscuring the origin application. However, this technique does not alter the total number of packets sent per unit of time from the scanning host. Therefore, it is ineffective against Intrusion Detection Systems (IDS) or Intrusion Prevention Systems (IPS) that monitor and trigger alerts based on high packet rates originating from a single source IP address, regardless of the source port used.
B
Use a decoy scan
Why it fails: A decoy scan involves sending packets from multiple spoofed IP addresses in addition to the actual attacker's IP, making it harder for the target to identify the true source of the scan. While this technique can obscure the attacker's origin, it inherently increases the overall packet volume directed at the target. Each decoy IP, along with the real attacker's IP, contributes to the total packet rate observed by the target's IDS/IPS, potentially increasing the likelihood of triggering rate-based detection thresholds rather than evading them.
C
Slow down the scan rate
Slowing down the scan rate directly reduces the number of packets sent per second (PPS) or connections attempted per minute. This strategic reduction keeps the scanning activity below the predefined thresholds set by rate-based Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS), which are designed to detect anomalous traffic volumes. By maintaining a low packet rate, the ethical hacker can conduct reconnaissance without triggering alerts that would otherwise flag the activity as a potential port scan or denial-of-service attempt, thus evading detection.
D
Use fragmented packets
Why it fails: Using fragmented packets involves splitting a single packet into multiple smaller fragments, forcing the target system to reassemble them. This technique is primarily effective against signature-based IDS/IPS that might fail to properly reassemble or inspect fragmented packets, thus missing specific attack signatures. However, fragmentation does not reduce the total number of packets sent over the network; in fact, it increases it for a given amount of data. Consequently, it offers no benefit against rate-based detection mechanisms that simply count the volume of packets arriving from a source within a specific timeframe.

Full breakdown with real-world context →

Question 6easymultiple choice

Read the full Introduction to Ethical Hacking explanation →

A company wants to test the security of its web application by simulating attacks from an external perspective. They have no prior knowledge of the internal network or application architecture. Which type of test should they perform?

Trap 1: White-box test

A white-box test involves the tester having complete access to the application's internal workings, including source code, design documents, and infrastructure details. This comprehensive knowledge allows for in-depth analysis of code logic, configuration files, and potential internal vulnerabilities that might be missed by external testing. While thorough for identifying deep-seated flaws, it does not simulate an external attacker's perspective, which is what the company primarily seeks for web application security.

Trap 2: Red team engagement

A red team engagement is a comprehensive, goal-oriented adversarial simulation designed to test an organization's overall security posture, including people, processes, and technology, against a specific objective (e.g., data exfiltration). Unlike a focused web application test, it often involves multiple attack vectors, social engineering, and physical penetration, aiming to mimic a sophisticated, persistent threat actor across the entire enterprise. It's a broader, more extensive exercise than simply testing a single web application's security.

Trap 3: Gray-box test

A gray-box test is conducted with some limited knowledge of the application's internal structure or credentials, such as user accounts or API documentation, but not full source code access. This approach balances the realism of a black-box test with the efficiency of a white-box test, allowing testers to simulate an insider threat or a privileged user. However, for a company wanting to test its web application's security from an *external* attacker's perspective, a gray-box test provides too much initial information.

Study all Introduction to Ethical Hacking common traps →

A
Black-box test
A black-box test simulates an external attacker with no prior knowledge of the target system's internal architecture, source code, or credentials. Testers interact with the web application solely through its public interfaces, mimicking real-world threat actors attempting to exploit vulnerabilities from the outside. This approach is ideal for assessing the effectiveness of perimeter defenses and identifying externally exploitable flaws, directly aligning with a company's goal to test its web application's security from an external perspective.
B
White-box test
Why it fails: A white-box test involves the tester having complete access to the application's internal workings, including source code, design documents, and infrastructure details. This comprehensive knowledge allows for in-depth analysis of code logic, configuration files, and potential internal vulnerabilities that might be missed by external testing. While thorough for identifying deep-seated flaws, it does not simulate an external attacker's perspective, which is what the company primarily seeks for web application security.
C
Red team engagement
Why it fails: A red team engagement is a comprehensive, goal-oriented adversarial simulation designed to test an organization's overall security posture, including people, processes, and technology, against a specific objective (e.g., data exfiltration). Unlike a focused web application test, it often involves multiple attack vectors, social engineering, and physical penetration, aiming to mimic a sophisticated, persistent threat actor across the entire enterprise. It's a broader, more extensive exercise than simply testing a single web application's security.
D
Gray-box test
Why it fails: A gray-box test is conducted with some limited knowledge of the application's internal structure or credentials, such as user accounts or API documentation, but not full source code access. This approach balances the realism of a black-box test with the efficiency of a white-box test, allowing testers to simulate an insider threat or a privileged user. However, for a company wanting to test its web application's security from an *external* attacker's perspective, a gray-box test provides too much initial information.

Full breakdown with real-world context →

Question 7hardmultiple choice

Read the full Introduction to Ethical Hacking explanation →

Refer to the exhibit. An ethical hacker runs the shown Nmap scan against a target. Which port state indicates that the port is reachable but no service is listening?

Exhibit

Refer to the exhibit.
```
$ nmap -sS -T4 -p 22,80,443 192.168.1.10
Starting Nmap 7.80 ( https://nmap.org )
Nmap scan report for 192.168.1.10
Host is up (0.0012s latency).

PORT    STATE    SERVICE
22/tcp  open     ssh
80/tcp  open     http
443/tcp closed   https

Nmap done: 1 IP address (1 host up) scanned in 2.45 seconds
```

Trap 1: open

An 'open' state signifies that a target port has an application actively listening for incoming connections. Nmap successfully completed a full TCP three-way handshake or received an expected response for UDP, confirming that the port is accessible and a service is ready to accept communication. This indicates a potential entry point for further enumeration and vulnerability assessment, but it is not the state depicted in the exhibit for the relevant port.

Trap 2: filtered

A 'filtered' state occurs when Nmap cannot definitively determine if a port is open or closed because a firewall, router, or other network security device is actively preventing the probe packets from reaching the target or blocking the response. This often results in Nmap receiving no response at all, or an ICMP unreachable error, indicating that the probe was dropped. This state suggests the presence of a protective mechanism, hindering direct port status assessment.

Trap 3: unfiltered

An 'unfiltered' state is primarily observed during an Nmap ACK scan, which is specifically designed to map firewall rulesets rather than ascertain if a service is listening. This state indicates that the port is accessible and not being blocked by a firewall, as the ACK probe successfully elicited an RST response. However, it provides no information about whether an application is actually listening on that port, making it distinct from 'open' or 'closed' states in terms of service availability.

Study all Introduction to Ethical Hacking common traps →

A
open
Why it fails: An 'open' state signifies that a target port has an application actively listening for incoming connections. Nmap successfully completed a full TCP three-way handshake or received an expected response for UDP, confirming that the port is accessible and a service is ready to accept communication. This indicates a potential entry point for further enumeration and vulnerability assessment, but it is not the state depicted in the exhibit for the relevant port.
B
closed
A 'closed' port indicates that the target host is reachable and received Nmap's probe, but no application is currently listening on that specific port. For TCP scans, the target typically responds with an RST (reset) packet, confirming the port's accessibility while explicitly stating that no service is active there. This state is crucial as it differentiates between an inactive port and one that is blocked by a firewall, accurately reflecting the scenario where the host is up but the service is not running.
C
filtered
Why it fails: A 'filtered' state occurs when Nmap cannot definitively determine if a port is open or closed because a firewall, router, or other network security device is actively preventing the probe packets from reaching the target or blocking the response. This often results in Nmap receiving no response at all, or an ICMP unreachable error, indicating that the probe was dropped. This state suggests the presence of a protective mechanism, hindering direct port status assessment.
D
unfiltered
Why it fails: An 'unfiltered' state is primarily observed during an Nmap ACK scan, which is specifically designed to map firewall rulesets rather than ascertain if a service is listening. This state indicates that the port is accessible and not being blocked by a firewall, as the ACK probe successfully elicited an RST response. However, it provides no information about whether an application is actually listening on that port, making it distinct from 'open' or 'closed' states in terms of service availability.

Full breakdown with real-world context →

Question 8mediummultiple choice

Open the full VLAN trunking answer →

You are an ethical hacker hired to assess the security of a mid-sized company's internal network. The company has three departments: Sales, Engineering, and HR, each on separate VLANs. The network uses a single firewall with default-deny rules, but inter-VLAN routing is allowed for specific ports (e.g., HR needs to access Sales database on TCP 1433). During reconnaissance, you discover that the Engineering VLAN has a web server running on port 80 that is accessible from all VLANs. You also find that the Sales VLAN has a file share (SMB) on port 445 that is accessible only from HR. The firewall logs show numerous failed SSH attempts from an external IP to the Engineering web server. Which action should you recommend as the most effective immediate step to reduce the attack surface?

Trap 1: Implement a password policy requiring complex passwords for all…

Implementing a strong password policy is a fundamental security practice that enhances user authentication by making brute-force and dictionary attacks more difficult. However, this measure primarily protects against unauthorized login attempts once an attacker has already established network connectivity to the server. It does not address the underlying issue of the web server being unnecessarily exposed and reachable from all VLANs across the network, which is a network access control problem.

Trap 2: Enable two-factor authentication on the web server.

Enabling two-factor authentication significantly strengthens the authentication process by requiring a second verification factor beyond just a password, thereby mitigating risks from compromised credentials. Nevertheless, 2FA operates at the application or service login layer and does not restrict the initial network access path to the web server itself. The server remains broadly accessible from every VLAN, allowing any device to attempt connection and potentially discover other vulnerabilities before authentication even occurs.

Trap 3: Apply the latest security patches to the web server.

Applying the latest security patches is crucial for mitigating known vulnerabilities within the web server's operating system and applications, preventing exploitation by attackers. While essential for maintaining a secure posture, patching does not inherently reduce the network exposure of the server. The server would still be broadly accessible from all VLANs, meaning any potential attacker on the network could still reach it and probe for zero-day exploits or misconfigurations, even if all known vulnerabilities are addressed.

Study all Introduction to Ethical Hacking common traps →

A
Implement a password policy requiring complex passwords for all users.
Why it fails: Implementing a strong password policy is a fundamental security practice that enhances user authentication by making brute-force and dictionary attacks more difficult. However, this measure primarily protects against unauthorized login attempts once an attacker has already established network connectivity to the server. It does not address the underlying issue of the web server being unnecessarily exposed and reachable from all VLANs across the network, which is a network access control problem.
B
Enable two-factor authentication on the web server.
Why it fails: Enabling two-factor authentication significantly strengthens the authentication process by requiring a second verification factor beyond just a password, thereby mitigating risks from compromised credentials. Nevertheless, 2FA operates at the application or service login layer and does not restrict the initial network access path to the web server itself. The server remains broadly accessible from every VLAN, allowing any device to attempt connection and potentially discover other vulnerabilities before authentication even occurs.
C
Apply the latest security patches to the web server.
Why it fails: Applying the latest security patches is crucial for mitigating known vulnerabilities within the web server's operating system and applications, preventing exploitation by attackers. While essential for maintaining a secure posture, patching does not inherently reduce the network exposure of the server. The server would still be broadly accessible from all VLANs, meaning any potential attacker on the network could still reach it and probe for zero-day exploits or misconfigurations, even if all known vulnerabilities are addressed.
D
Restrict access to the Engineering web server to only the Engineering VLAN.
Restricting access to the Engineering web server solely to the Engineering VLAN directly implements the principle of least privilege at the network layer. This action significantly reduces the attack surface by ensuring the server is only reachable by authorized clients within its designated operational segment. By preventing unnecessary network connectivity from other VLANs, it drastically limits the opportunities for unauthorized reconnaissance and exploitation attempts, regardless of the server's internal security controls.

Full breakdown with real-world context →

Question 9mediummulti select

Read the full Introduction to Ethical Hacking explanation →

Which THREE of the following are essential phases in the ethical hacking methodology as defined by EC-Council?

Trap 1: Enumeration

Enumeration is a sub-phase within Scanning, not a separate phase.

Trap 2: Social Engineering

Social Engineering is a technique used within phases, not a phase itself.

Study all Introduction to Ethical Hacking common traps →

A
Maintaining Access
Maintaining Access is a phase after gaining initial entry.
B
Scanning
Scanning involves active probing of the target network.
C
Enumeration
Why it fails: Enumeration is a sub-phase within Scanning, not a separate phase.
D
Reconnaissance
Reconnaissance is the first phase, involving information gathering.
E
Social Engineering
Why it fails: Social Engineering is a technique used within phases, not a phase itself.

Full breakdown with real-world context →

Question 10hardmultiple choice

Read the full Introduction to Ethical Hacking explanation →

Based on the exhibit, what type of attack is being attempted?

Exhibit

Refer to the exhibit.

192.168.1.10   - - [01/Oct/2023:13:55:36 -0400] "GET /index.html HTTP/1.1" 200 2326
192.168.1.10   - - [01/Oct/2023:13:55:37 -0400] "GET /admin/login.php HTTP/1.1" 404 169
192.168.1.10   - - [01/Oct/2023:13:55:38 -0400] "GET /admin/ HTTP/1.1" 403 195
192.168.1.10   - - [01/Oct/2023:13:55:39 -0400] "GET /images/..%252f..%252f..%252f..%252fetc/passwd HTTP/1.1" 200 523
192.168.1.10   - - [01/Oct/2023:13:55:40 -0400] "GET /cgi-bin/test.cgi HTTP/1.1" 200 89

Trap 1: Command Injection

Command Injection involves injecting and executing arbitrary operating system commands through an application. The provided exhibit does not contain any typical command separators like semicolons (`;`), ampersands (`&`), pipes (`|`), or backticks (`` ` ``), nor does it show common command utilities such as `ls`, `cat`, or `whoami`. Therefore, there is no indication that the attacker is attempting to execute system-level commands on the server.

Trap 2: SQL Injection

SQL Injection exploits vulnerabilities in an application's database layer by inserting malicious SQL code into input fields. The exhibit lacks any characteristic SQL syntax, such as single quotes (`'`), double dashes (`--`) for comments, or keywords like `UNION`, `SELECT`, `OR`, or `AND`, which are typically used to manipulate database queries. Without these elements, the attempt does not align with the patterns of an SQL injection attack targeting a backend database.

Trap 3: Cross-Site Scripting

Cross-Site Scripting (XSS) attacks involve injecting malicious client-side scripts, typically JavaScript, into web pages viewed by other users. The exhibit does not display any HTML tags like `<script>`, `<img>` with `onerror` attributes, or `javascript:` pseudo-protocols commonly used to embed or execute scripts within a web browser. The observed input is focused on file path manipulation rather than browser-side script execution.

Study all Introduction to Ethical Hacking common traps →

A
Directory Traversal
The exhibit clearly shows an attempt to manipulate a file path using `..%2f` sequences, which are URL-encoded representations of `../`. This technique aims to navigate outside of an intended directory and access restricted files, such as `/etc/passwd`, which stores user account information on Unix-like systems. Such an attack exploits inadequate input validation on user-supplied file paths, allowing an attacker to read or potentially write to arbitrary files on the server's file system.
B
Command Injection
Why it fails: Command Injection involves injecting and executing arbitrary operating system commands through an application. The provided exhibit does not contain any typical command separators like semicolons (`;`), ampersands (`&`), pipes (`|`), or backticks (`` ` ``), nor does it show common command utilities such as `ls`, `cat`, or `whoami`. Therefore, there is no indication that the attacker is attempting to execute system-level commands on the server.
C
SQL Injection
Why it fails: SQL Injection exploits vulnerabilities in an application's database layer by inserting malicious SQL code into input fields. The exhibit lacks any characteristic SQL syntax, such as single quotes (`'`), double dashes (`--`) for comments, or keywords like `UNION`, `SELECT`, `OR`, or `AND`, which are typically used to manipulate database queries. Without these elements, the attempt does not align with the patterns of an SQL injection attack targeting a backend database.
D
Cross-Site Scripting
Why it fails: Cross-Site Scripting (XSS) attacks involve injecting malicious client-side scripts, typically JavaScript, into web pages viewed by other users. The exhibit does not display any HTML tags like `<script>`, `<img>` with `onerror` attributes, or `javascript:` pseudo-protocols commonly used to embed or execute scripts within a web browser. The observed input is focused on file path manipulation rather than browser-side script execution.

Full breakdown with real-world context →

Question 11easymultiple choice

Read the full Introduction to Ethical Hacking explanation →

You are a penetration tester hired by a financial services company to assess the security of their external web application. The application is a customer portal hosted on a Linux server with Apache 2.4.6 and PHP 7.2. During reconnaissance, you discover that the server responds to HTTP OPTIONS requests and the Allow header includes PUT and DELETE methods. The application uses a MySQL database backend. You also find a file upload feature in the profile section that accepts JPEG images. While testing, you notice that uploading a file with a .php extension returns a '403 Forbidden' error, but uploading a file with .php5 or .phtml extension succeeds. The uploaded files are stored in /uploads/ directory. What should be your next step to escalate the attack?

Trap 1: Use the PUT method to upload a malicious file directly to the web…

While the HTTP PUT method can theoretically be used to upload files, it is frequently disabled or heavily restricted on production web servers, especially for sensitive directories like the web root. Even if the 'Allow' header indicates PUT is supported, server-side configurations often prevent arbitrary file creation, making this a low-probability initial attack vector for direct web root compromise without prior authentication or a specific vulnerability.

Trap 2: Exploit the IIS WebDAV vulnerability to execute commands.

Exploiting an IIS WebDAV vulnerability would be ineffective in this scenario because the target server is explicitly stated or implied to be running Apache, not Microsoft's Internet Information Services (IIS). WebDAV vulnerabilities are specific to the IIS architecture and its implementation of the Web Distributed Authoring and Versioning protocol, making them irrelevant for an Apache-based environment.

Trap 3: Attempt SQL injection in the login form to extract database…

While SQL injection is a critical vulnerability often found in login forms, there is no evidence provided in the question stem to suggest its presence or exploitability in this specific context. Prioritizing an unconfirmed SQL injection attempt over a known or implied file upload vulnerability, which directly leads to remote code execution, would be an inefficient and less certain approach for initial compromise.

Study all Introduction to Ethical Hacking common traps →

A
Use the PUT method to upload a malicious file directly to the web root.
Why it fails: While the HTTP PUT method can theoretically be used to upload files, it is frequently disabled or heavily restricted on production web servers, especially for sensitive directories like the web root. Even if the 'Allow' header indicates PUT is supported, server-side configurations often prevent arbitrary file creation, making this a low-probability initial attack vector for direct web root compromise without prior authentication or a specific vulnerability.
B
Upload a PHP web shell with .phtml extension and access it via the /uploads/ directory to execute commands.
This approach leverages a common file upload vulnerability bypass technique. By using a '.phtml' extension, which Apache servers often interpret as PHP, the attacker can circumvent typical blacklist filters that block '.php' files. Once uploaded to an accessible directory like '/uploads/', the web shell can be requested, allowing the attacker to execute arbitrary commands on the server, achieving remote code execution.
C
Exploit the IIS WebDAV vulnerability to execute commands.
Why it fails: Exploiting an IIS WebDAV vulnerability would be ineffective in this scenario because the target server is explicitly stated or implied to be running Apache, not Microsoft's Internet Information Services (IIS). WebDAV vulnerabilities are specific to the IIS architecture and its implementation of the Web Distributed Authoring and Versioning protocol, making them irrelevant for an Apache-based environment.
D
Attempt SQL injection in the login form to extract database credentials.
Why it fails: While SQL injection is a critical vulnerability often found in login forms, there is no evidence provided in the question stem to suggest its presence or exploitability in this specific context. Prioritizing an unconfirmed SQL injection attempt over a known or implied file upload vulnerability, which directly leads to remote code execution, would be an inefficient and less certain approach for initial compromise.

Full breakdown with real-world context →

Question 12mediumdrag order

Read the full Introduction to Ethical Hacking explanation →

Drag and drop the steps to perform a TCP three-way handshake into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Send SYN-ACK, then send SYN, then send ACK

Sending a SYN-ACK as the initial packet is fundamentally flawed because a SYN-ACK is a response, not an initiation. It signifies acknowledgment of a received SYN and synchronization request from the server. The TCP three-way handshake must always commence with an unacknowledged SYN packet from the client to propose a connection, making this sequence illogical.

Trap 2: Send SYN, then send ACK, then send SYN-ACK

This sequence is incorrect because the server's immediate response to a client's SYN packet must be a SYN-ACK, not merely an ACK. The SYN-ACK serves to acknowledge the client's synchronization request while simultaneously sending its own synchronization request to the client. Sending only an ACK would fail to establish the server's initial sequence number with the client, preventing proper connection setup.

Trap 3: Send ACK, then send SYN, then send SYN-ACK

Initiating the TCP handshake with an ACK packet is impossible, as an ACK's purpose is to acknowledge previously received data or a synchronization request. At the very beginning of a connection attempt, there is nothing to acknowledge. The first packet must be a SYN to propose a connection and establish initial sequence numbers, making this sequence logically invalid.

Study all Introduction to Ethical Hacking common traps →

A
Send SYN, then receive SYN-ACK, then send ACK
This is the correct order because the TCP three-way handshake starts with the client sending a SYN packet to initiate synchronization, the server responds with SYN-ACK to acknowledge and synchronize, and finally the client sends an ACK to confirm the connection establishment.
B
Send SYN-ACK, then send SYN, then send ACK
Why it fails: Sending a SYN-ACK as the initial packet is fundamentally flawed because a SYN-ACK is a response, not an initiation. It signifies acknowledgment of a received SYN and synchronization request from the server. The TCP three-way handshake must always commence with an unacknowledged SYN packet from the client to propose a connection, making this sequence illogical.
C
Send SYN, then send ACK, then send SYN-ACK
Why it fails: This sequence is incorrect because the server's immediate response to a client's SYN packet must be a SYN-ACK, not merely an ACK. The SYN-ACK serves to acknowledge the client's synchronization request while simultaneously sending its own synchronization request to the client. Sending only an ACK would fail to establish the server's initial sequence number with the client, preventing proper connection setup.
D
Send ACK, then send SYN, then send SYN-ACK
Why it fails: Initiating the TCP handshake with an ACK packet is impossible, as an ACK's purpose is to acknowledge previously received data or a synchronization request. At the very beginning of a connection attempt, there is nothing to acknowledge. The first packet must be a SYN to propose a connection and establish initial sequence numbers, making this sequence logically invalid.

Full breakdown with real-world context →

Question 13mediumdrag order

Read the full Introduction to Ethical Hacking explanation →

Drag and drop the steps to set up a reverse shell using Netcat into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Victim connects back first, then set up listener, then attacker…

This order is fundamentally incorrect because a victim machine cannot successfully connect to a listener that has not yet been established. The TCP handshake requires an active listening socket on the specified port to complete. Any attempt by the victim to connect before the listener is running would result in a "Connection refused" error, preventing any shell from being established.

Trap 2: Set up listener, then victim connects back, then cleanup, then…

This sequence is flawed because inserting "cleanup" immediately after the victim connects would prematurely terminate the network session. Cleanup typically involves closing the connection, which would occur before the attacker has had any opportunity to gain interactive shell access or execute a single command. The session would be closed before its intended purpose could be fulfilled.

Trap 3: Set up listener, then attacker gains shell access, then victim…

This order is incorrect because the attacker cannot "gain shell access" until the victim machine has successfully connected to the listener. The attacker's netcat listener simply waits passively for an incoming connection. Shell access is only granted when the victim actively connects and redirects its shell's input/output streams over the established TCP tunnel, not before.

Study all Introduction to Ethical Hacking common traps →

A
Set up listener on attacker machine, then victim connects back, then attacker gains shell access, then execute commands, then cleanup
This sequence correctly outlines the establishment of a reverse shell using Netcat. The attacker's machine must first set up a listener (e.g., `nc -lvnp <port>`) to await an incoming connection. Once active, the victim machine initiates an outbound connection to the attacker, piping a shell process. This establishes the communication channel, granting the attacker interactive shell access to execute commands, followed by proper session cleanup.
B
Victim connects back first, then set up listener, then attacker gains shell access, then execute commands, then cleanup
Why it fails: This order is fundamentally incorrect because a victim machine cannot successfully connect to a listener that has not yet been established. The TCP handshake requires an active listening socket on the specified port to complete. Any attempt by the victim to connect before the listener is running would result in a "Connection refused" error, preventing any shell from being established.
C
Set up listener, then victim connects back, then cleanup, then attacker gains shell access, then execute commands
Why it fails: This sequence is flawed because inserting "cleanup" immediately after the victim connects would prematurely terminate the network session. Cleanup typically involves closing the connection, which would occur before the attacker has had any opportunity to gain interactive shell access or execute a single command. The session would be closed before its intended purpose could be fulfilled.
D
Set up listener, then attacker gains shell access, then victim connects back, then execute commands, then cleanup
Why it fails: This order is incorrect because the attacker cannot "gain shell access" until the victim machine has successfully connected to the listener. The attacker's netcat listener simply waits passively for an incoming connection. Shell access is only granted when the victim actively connects and redirects its shell's input/output streams over the established TCP tunnel, not before.

Full breakdown with real-world context →

Question 14easymultiple choice

Read the full Introduction to Ethical Hacking explanation →

A junior security consultant is preparing to conduct an authorized penetration test for a retail client. Before any scanning begins, the client's legal team asks the consultant to confirm which document defines the exact IP ranges, testing window, and prohibited actions such as denial-of-service attempts. Which document should the consultant reference?

Trap 1: Statement of Work (SOW)

A Statement of Work describes deliverables, timeline, and pricing for a project, which is useful commercially but not the primary source for technical boundaries like allowed IP ranges and prohibited attack types. The SOW may reference the RoE for those details. The consultant needs the document that directly authorizes and constrains the testing activity itself.

Trap 2: Non-Disclosure Agreement (NDA)

An NDA governs confidentiality of information learned during the engagement; it does not define target IP ranges, testing hours, or which intrusive techniques are permitted. While an NDA is commonly signed alongside testing paperwork, it cannot tell the consultant what systems may be touched or when. The legal team's question about scope and prohibited actions points to a different document.

Trap 3: Master Service Agreement (MSA)

An MSA is a broad contract establishing general terms for an ongoing business relationship between vendor and client, such as payment and liability. It typically does not enumerate specific IP ranges, test windows, or banned techniques for a particular engagement. Those operational specifics belong in a per-engagement document rather than the overarching contract framework.

Study all Introduction to Ethical Hacking common traps →

A
Statement of Work (SOW)
Why it fails: A Statement of Work describes deliverables, timeline, and pricing for a project, which is useful commercially but not the primary source for technical boundaries like allowed IP ranges and prohibited attack types. The SOW may reference the RoE for those details. The consultant needs the document that directly authorizes and constrains the testing activity itself.
B
Rules of Engagement (RoE)
The Rules of Engagement is the document that scopes an authorized test: it names in-scope targets, allowed techniques, testing windows, and explicitly forbidden actions like DoS. Because the client's legal team is asking about IP ranges and prohibited actions, the RoE is the authoritative source. It protects both parties by ensuring the tester's actions stay within written authorization.
C
Non-Disclosure Agreement (NDA)
Why it fails: An NDA governs confidentiality of information learned during the engagement; it does not define target IP ranges, testing hours, or which intrusive techniques are permitted. While an NDA is commonly signed alongside testing paperwork, it cannot tell the consultant what systems may be touched or when. The legal team's question about scope and prohibited actions points to a different document.
D
Master Service Agreement (MSA)
Why it fails: An MSA is a broad contract establishing general terms for an ongoing business relationship between vendor and client, such as payment and liability. It typically does not enumerate specific IP ranges, test windows, or banned techniques for a particular engagement. Those operational specifics belong in a per-engagement document rather than the overarching contract framework.

Full breakdown with real-world context →

Question 15mediummultiple choice

Read the full Introduction to Ethical Hacking explanation →

An ethical hacker is hired to assess a hospital's network. The contract permits vulnerability discovery but explicitly forbids exploiting a flaw to access patient records. During testing, the hacker finds a SQL injection that would expose the patient database. Which action best reflects the ethical hacking principle of maintaining integrity and minimizing harm?

Trap 1: Stop testing entirely and immediately terminate the engagement…

Abandoning the assessment wastes the client's investment and leaves other vulnerabilities undiscovered. Finding a serious flaw is expected during testing; the ethical response is to document it safely and continue within the agreed scope. Terminating without notifying the client through proper channels also delays remediation of the very risk discovered.

Trap 2: Share the injection details with a public forum to pressure the…

Public disclosure of an unpatched vulnerability exposes the hospital and its patients to immediate attack by malicious actors. It also breaches the confidentiality terms of the engagement. Ethical hackers report findings privately to the client first, allowing time for remediation before any coordinated disclosure is discussed.

Trap 3: Exploit the injection fully and download a sample of patient…

Downloading patient records violates the contract and data-protection obligations, causing real harm to patients whose privacy is compromised. Even with good intent, exfiltrating protected health information exceeds authorization and could trigger legal penalties. A proof of concept does not require accessing actual sensitive records, so this action is disproportionate and unethical.

Study all Introduction to Ethical Hacking common traps →

A
Stop testing entirely and immediately terminate the engagement because a serious flaw was found.
Why it fails: Abandoning the assessment wastes the client's investment and leaves other vulnerabilities undiscovered. Finding a serious flaw is expected during testing; the ethical response is to document it safely and continue within the agreed scope. Terminating without notifying the client through proper channels also delays remediation of the very risk discovered.
B
Share the injection details with a public forum to pressure the hospital into patching quickly.
Why it fails: Public disclosure of an unpatched vulnerability exposes the hospital and its patients to immediate attack by malicious actors. It also breaches the confidentiality terms of the engagement. Ethical hackers report findings privately to the client first, allowing time for remediation before any coordinated disclosure is discussed.
C
Document the vulnerability with a non-destructive proof of concept, such as a boolean-based test, and report it without accessing patient data.
Using a non-destructive proof, such as confirming a boolean condition or extracting only database version metadata, demonstrates the flaw while respecting the contract's prohibition on accessing patient records. This satisfies the goal of proving exploitability without causing harm. It aligns with the ethical principles of minimizing impact and staying within authorized scope.
D
Exploit the injection fully and download a sample of patient records to prove the vulnerability is real.
Why it fails: Downloading patient records violates the contract and data-protection obligations, causing real harm to patients whose privacy is compromised. Even with good intent, exfiltrating protected health information exceeds authorization and could trigger legal penalties. A proof of concept does not require accessing actual sensitive records, so this action is disproportionate and unethical.

Full breakdown with real-world context →

Question 16mediummultiple choice

Read the full Introduction to Ethical Hacking explanation →

A penetration tester is reviewing the difference between a white-box, black-box, and gray-box assessment for a client's new e-commerce platform. The client wants the most realistic simulation of an external attacker with no inside knowledge, but also wants the tester to spend time efficiently rather than performing lengthy reconnaissance. Which assessment type best matches the client's stated priorities?

Trap 1: Black-box assessment

Black-box testing provides the most realistic external attacker simulation because the tester starts with no information, but it requires extensive reconnaissance that consumes time. The client wants to avoid lengthy reconnaissance, so pure black-box does not satisfy both stated priorities. Realism alone is not the only criterion here.

Trap 2: White-box assessment

A white-box assessment gives the tester full knowledge of source code, architecture, and credentials, which maximizes efficiency but does not simulate an external attacker with no inside knowledge. The client explicitly wants realism from an outsider's perspective, so full disclosure contradicts that requirement even though it saves time.

Trap 3: Double-blind assessment

A double-blind assessment keeps both the tester and the target organization's defenders unaware, which tests detection and response realism but does not reduce the tester's reconnaissance burden. It is a variation of black-box testing in terms of information provided to the tester. The client's priority of efficiency is not addressed by this approach.

Study all Introduction to Ethical Hacking common traps →

A
Black-box assessment
Why it fails: Black-box testing provides the most realistic external attacker simulation because the tester starts with no information, but it requires extensive reconnaissance that consumes time. The client wants to avoid lengthy reconnaissance, so pure black-box does not satisfy both stated priorities. Realism alone is not the only criterion here.
B
White-box assessment
Why it fails: A white-box assessment gives the tester full knowledge of source code, architecture, and credentials, which maximizes efficiency but does not simulate an external attacker with no inside knowledge. The client explicitly wants realism from an outsider's perspective, so full disclosure contradicts that requirement even though it saves time.
C
Gray-box assessment
Gray-box testing balances realism and efficiency by giving the tester partial information, such as user-level credentials or architecture diagrams, while still requiring discovery of many attack paths. This simulates an attacker with some insider knowledge and reduces wasted reconnaissance time. It matches the client's desire for realistic external simulation without the full overhead of black-box work.
D
Double-blind assessment
Why it fails: A double-blind assessment keeps both the tester and the target organization's defenders unaware, which tests detection and response realism but does not reduce the tester's reconnaissance burden. It is a variation of black-box testing in terms of information provided to the tester. The client's priority of efficiency is not addressed by this approach.

Full breakdown with real-world context →

Question 17hardmulti select

Read the full Introduction to Ethical Hacking explanation →

An ethical hacker is preparing the final report after a penetration test for a logistics company. The client's compliance officer asks which elements are essential to include so the report supports remediation and satisfies audit expectations. Which two elements are essential to include in the final penetration testing report? (Choose two.)

Trap 1: The tester's personal password vault contents used during the…

A tester's credential vault may contain unrelated client or personal secrets and has no place in a deliverable. Exposing it would violate confidentiality and could create new security incidents. Reports should reference only the specific credentials or access paths needed to explain a finding, not the tester's full tooling inventory.

Trap 2: A full packet capture of all traffic generated during the entire…

Raw packet captures are bulky and may contain sensitive data unrelated to findings, raising privacy and storage concerns. They are useful internally for analysis but are not an essential report element. Including them wholesale can obscure the actionable content and complicate handling requirements under data-protection policies.

Trap 3: The complete source code of every application tested

Source code is not always available or in scope, and reproducing it in a report is impractical and risks intellectual property exposure. Findings can be explained with targeted code snippets when relevant. A report's purpose is to communicate risk and remediation, not to archive the client's codebase.

Study all Introduction to Ethical Hacking common traps →

A
A statement of scope, methodology, and testing limitations
Documenting scope, methodology, and limitations tells the reader what was tested, how, and what remains unknown, which is essential for interpreting results correctly. Auditors rely on this context to judge coverage, and clients use it to plan follow-up work. Omitting it can make the report misleading by implying broader assurance than the engagement actually provided.
B
The tester's personal password vault contents used during the engagement
Why it fails: A tester's credential vault may contain unrelated client or personal secrets and has no place in a deliverable. Exposing it would violate confidentiality and could create new security incidents. Reports should reference only the specific credentials or access paths needed to explain a finding, not the tester's full tooling inventory.
C
A full packet capture of all traffic generated during the entire engagement
Why it fails: Raw packet captures are bulky and may contain sensitive data unrelated to findings, raising privacy and storage concerns. They are useful internally for analysis but are not an essential report element. Including them wholesale can obscure the actionable content and complicate handling requirements under data-protection policies.
D
The complete source code of every application tested
Why it fails: Source code is not always available or in scope, and reproducing it in a report is impractical and risks intellectual property exposure. Findings can be explained with targeted code snippets when relevant. A report's purpose is to communicate risk and remediation, not to archive the client's codebase.
E
A prioritized list of findings with risk ratings and supporting evidence
Findings with risk ratings and evidence let the client triage remediation and demonstrate due diligence to auditors. Evidence such as screenshots, request and response pairs, or command output makes each finding verifiable. Without prioritization, teams may fix low-impact issues first while critical exposures remain open, undermining the report's value.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Introduction to Ethical Hacking sessions

Start a Introduction to Ethical Hacking only practice session

Every question in these sessions is drawn from the Introduction to Ethical Hacking domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Introduction to Ethical Hacking questions →Mixed CEH session

Frequently asked questions

What does the CEH exam test about Introduction to Ethical Hacking?: You must classify a scenario as black-, white-, or gray-box, name the correct hacking phase or attacker type, and order Netcat reverse-shell steps. The single most important thing: match the tester's stated knowledge level to the correct box type before answering.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Introduction to Ethical Hacking questions in a focused session?: Yes — the session launcher on this page draws every question from the Introduction to Ethical Hacking domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other CEH topics?: Use the topic links above to move to related areas, or go back to the CEH question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the CEH exam covers. They are not copied from any real exam or dump site.

Introduction to Ethical Hacking only

10 questions 20 questions 30 questions 50 questions

Mixed CEH session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All CEH questions Introduction to Ethical Hacking domain overview CEH exam guide

Exam traps to avoid

▸Confusing gray-box (partial knowledge) with black-box (zero knowledge) when the scenario mentions some internal documentation or credentials.
▸Mixing up passive reconnaissance (no direct target contact) with active scanning that sends packets and may be logged.
▸Reversing Netcat listener and target order, or forgetting the -l -p flags on the listening host before connecting.

Introduction to Ethical Hacking practice questions

What to know about Introduction to Ethical Hacking

Common Introduction to Ethical Hacking exam traps

Introduction to Ethical Hacking questions

Which TWO of the following are recognized phases of the Ethical Hacking process? (Select TWO.)

Match each network protocol to its well-known port number.

Select all that apply: Which of the following IDS/IPS terms are correctly matched to their meanings?

A security analyst suspects that an attacker is scanning their network. They notice a large number of TCP SYN packets being sent to various ports on a single host, but no SYN-ACK responses are returned. Which type of scan is most likely being used?

During a penetration test, an ethical hacker needs to evade an IDS that detects port scans based on the number of packets per second. Which technique would be most effective to avoid detection?

A company wants to test the security of its web application by simulating attacks from an external perspective. They have no prior knowledge of the internal network or application architecture. Which type of test should they perform?

Refer to the exhibit. An ethical hacker runs the shown Nmap scan against a target. Which port state indicates that the port is reachable but no service is listening?

Exhibit

Which THREE of the following are essential phases in the ethical hacking methodology as defined by EC-Council?

Based on the exhibit, what type of attack is being attempted?

Exhibit

Drag and drop the steps to perform a TCP three-way handshake into the correct order.

Drag and drop the steps to set up a reverse shell using Netcat into the correct order.

Track your progress over time

Start a Introduction to Ethical Hacking only practice session

Related CEH topic practice pages

Scanning Networks and Enumeration practice questions

Wireless, IoT and Cloud Security practice questions

Vulnerability Analysis and System Hacking practice questions

Advanced Topics: Wireless, Cloud, IoT, Cryptography practice questions

Cryptography and Malware Analysis practice questions

Footprinting and Reconnaissance practice questions

Network and Web Application Attacks practice questions

Enumeration and System Hacking practice questions

Footprinting, Reconnaissance and Scanning practice questions

Social Engineering and Physical Security practice questions

Malware, Social Engineering and Network Attacks practice questions

Web Application and Injection Attacks practice questions

Frequently asked questions

Track your progress

Study resources

Exam traps to avoid