Free ECCouncil 312-50v13 Practice Exam with Questions & Answers | Set: 15

According to the Certified Ethical Hacker (CEH) IDS/IPS and Evasion Techniques module, packet fragmentation is a technique attackers use to split malicious payloads into smaller fragments so that signature-based IDS sensors may fail to reassemble and inspect the complete packet.

CEH explains that anomaly-based IDS systems are more effective against fragmentation evasion because they analyze behavioral deviations rather than relying solely on known signatures. Fragmented traffic often deviates from baseline network behavior in terms of packet size, sequencing, and reassembly anomalies.

Option A is correct because anomaly-based detection can identify abnormal fragmentation behavior even if the payload itself does not match known signatures.

Option B is unreliable, as attackers do not use consistent intervals.

Option C is impractical, since legitimate traffic may be fragmented.

Option D is less effective because signature-based IDS systems can be bypassed by fragmentation techniques.

CEH recommends packet normalization and anomaly-based detection as effective countermeasures.

Security awareness and training is the most effective primary countermeasure against social engineering because these attacks exploit human trust, curiosity, urgency, and lack of familiarity with deception tactics rather than purely technical weaknesses. In CEH guidance, phishing, vishing, and baiting succeed when users fail to recognize red flags such as unexpected requests, pressure to act quickly, suspicious links or attachments, caller spoofing, or offers that seem too good to be true. A structured awareness program directly reduces the chance of disclosure by teaching employees how to identify common pretexts, verify unusual requests, and follow safe reporting procedures.

While identity verification (option B) is an important practice, employees typically perform it correctly only when they have been trained on verification steps, escalation paths, and what “good verification” looks like under pressure. Two-factor authentication (option C) helps protect accounts even if credentials are stolen, but it does not prevent employees from sharing sensitive information such as customer data, internal documents, OTP codes, or approving fraudulent requests—many social engineering campaigns aim beyond passwords. Policies and procedures (option D) are necessary, but policies alone are often ignored or misunderstood without ongoing training, reinforcement, and real-world simulations.

CEH-aligned best practice is a layered approach: start with awareness training, reinforce it with clear handling policies, require verification for sensitive requests, conduct phishing simulations, and ensure employees know how to report suspicious emails/calls immediately. This combination reduces both successful compromise and the impact of attempts, but training is the foundational priority because it directly targets the human element being attacked.

This scenario represents a Tautology-Based SQL Injection, a fundamental SQL injection technique covered under the Web Application Hacking module in the CEH v13 curriculum. The defining characteristic of this attack is the injection of a condition that always evaluates to TRUE, thereby bypassing authentication or authorization controls.

In the given example, the injected input 1 OR ' T ' = ' T ' ; -- manipulates the logical condition of the SQL query. A typical vulnerable login query may resemble:

SELECT * FROM users WHERE user_id = 1 AND password = ' input ' ;

When the attacker submits the injected payload, the resulting SQL statement becomes:

SELECT * FROM users WHERE user_id = 1 OR ' T ' = ' T ' ; -- ' ;

The expression ' T ' = ' T ' is a tautology, meaning it always evaluates to TRUE regardless of context. As a result, the database returns records without properly validating the user’s credentials, granting unauthorized access.

According to EC-Council CEH v13, tautology-based SQL injection is classified as a Boolean-based injection technique where attackers exploit improper input validation to alter the logical flow of SQL queries. This attack does not depend on database error messages (as in Error-Based SQL Injection), does not extract data using UNION statements (Union-Based SQL Injection), and does not rely on response delays (Time-Based Blind SQL Injection).

CEH v13 emphasizes that such attacks are especially effective against login forms and authentication mechanisms when developers fail to implement input sanitization, parameterized queries, or prepared statements. This attack is one of the most common and exam-tested SQL injection types because it clearly demonstrates how flawed logic can compromise application security without advanced techniques.

Understanding tautology-based SQL injection is critical for ethical hackers, as it forms the foundation for identifying and mitigating more complex SQL injection variants.

The correct answer is A. Design Flaws because the weaknesses originate from fundamental development-time decisions in how the application was architected—specifically (1) selecting or creating a weak custom encryption algorithm and (2) implementing session validation in a way that allows requests to bypass access controls. In CEH-aligned vulnerability classification, design flaws are problems embedded in the application’s design and logic, not merely bugs from implementation mistakes, misconfiguration of a server setting, or missing vendor patches. They are often systemic: even if the code is “working as intended,” the intent itself is insecure.

The prompt explicitly states the issues are “traced back to flawed system logic and poor encryption design decisions made during the development phase.” That description maps directly to design flaws: using “homegrown crypto” instead of vetted cryptographic primitives and protocols is a classic design error because it typically lacks proper peer review, threat modeling, and proven resistance to cryptanalysis. Likewise, session validation that permits bypassing access controls indicates the application’s authorization/session model was designed incorrectly (for example, trusting client-side state, failing to enforce server-side checks consistently, or allowing unauthenticated endpoints to access privileged operations).

Why the other options are less accurate: Application flaws is a broad label that can include coding bugs, but the question is asking for the best category given that the root cause is architectural decisions rather than a narrow coding mistake. Misconfigurations/weak configurations usually refer to insecure settings in deployment (default credentials, permissive headers, weak TLS configuration), not a custom crypto algorithm and flawed session logic baked into the app. Poor patch management concerns failing to update known vulnerable components; here, the weakness is custom logic, not an unpatched third-party vulnerability.

Therefore, the most accurate category for these development-phase encryption and session/authorization weaknesses is Design Flaws.

The CEH Footprinting and Reconnaissance module describes DNS interrogation as a valuable technique for extracting publicly available infrastructure information such as A records, MX records, NS records, and subdomains.

DNS can reveal:

Subdomains (via zone transfers, brute forcing, or enumeration)

Mail server IP addresses (MX records)

Server locations inferred from IP geolocation

However, DNS does not store authentication credentials. Usernames and passwords are protected within authentication systems and directories, not DNS records.

Therefore, option A is correct.

CEH clearly states that DNS reconnaissance is limited to infrastructure metadata, not sensitive user credentials.

The correct answer is C. MITRE ATT & CK. In CEH v13-aligned security operations and threat intelligence concepts, MITRE ATT & CK is used to understand and map adversary behavior during cyberattacks. ATT & CK stands for Adversarial Tactics, Techniques, and Common Knowledge. It organizes attacker actions into tactics, techniques, and sub-techniques, helping security teams understand what an attacker is trying to achieve and how the attacker may perform each step. Tactics represent the attacker’s objective, such as initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, command and control, exfiltration, and impact. Techniques describe the specific methods used to achieve those objectives. NIST CSF 2.0 is a cybersecurity risk management framework, not a detailed adversary TTP framework. ISSF is not the standard CEH answer for adversary behavior mapping, and ISC 28901 is not used for cataloging cyberattack TTPs. Therefore, MITRE ATT & CK is the best answer.

The requirement is specifically for a framework that explains how to identify, assess, and treat information security risks within the context of an Information Security Management System (ISMS). The ISO standard dedicated to information security risk management is ISO/IEC 27005. It provides guidance on establishing a risk management process aligned with the ISO/IEC 27000 family and supports the ISMS by describing risk context, risk identification, risk analysis, risk evaluation, risk treatment, risk acceptance, and ongoing risk communication and monitoring.

This focus on the “how” of risk management is what distinguishes ISO/IEC 27005 from the other options. ISO/IEC 27001:2022 is the standard that specifies the requirements to establish, implement, maintain, and continually improve an ISMS. It requires that risk assessment and treatment be performed, but it is not primarily a detailed methodology standard for conducting those activities. ISO/IEC 27002:2022 is a code of practice that provides a catalog of security controls (the “what” controls you can select), rather than a risk assessment/treatment methodology. ISO/IEC 27701:2019 extends ISO/IEC 27001/27002 to privacy information management (PIMS) and focuses on privacy controls and requirements—not the general information security risk management lifecycle.

Because the question asks for a standard that addresses identification, assessment, and treatment of information security risks as part of an ISMS, ISO/IEC 27005 is the best match. It complements ISO/IEC 27001 by giving organizations practical guidance for building and running the risk management process that ISO/IEC 27001 requires, ensuring risk decisions are systematic, repeatable, and suitable for governance and continual improvement.

Ping of Death is a classic Denial-of-Service technique in which an attacker sends oversized or malformed IP packets that exceed the maximum allowed size when reassembled. In IP networks, the maximum packet size is 65,535 bytes. Historically, attackers exploited fragmentation by sending a series of IP fragments that, when reassembled by the target, resulted in a packet larger than the permitted limit or produced an invalid buffer condition. Vulnerable systems could crash, reboot, or become unstable because the network stack mishandled the reassembly process or failed to properly validate packet length and structure.

The scenario matches this behavior precisely: Sofia transmits “oversized, malformed packets” and the server “crashes intermittently due to processing failures.” That symptom is more consistent with a malformed-packet handling flaw than with pure traffic volume. An ICMP flood and an ACK flood are volumetric or resource-exhaustion attacks that overwhelm bandwidth or connection-handling capacity, typically degrading performance rather than directly causing crashes from malformed packet parsing. A Smurf attack is an amplification-based ICMP attack using broadcast addresses to multiply traffic toward a victim; again, it is about volume, not crafted malformed packets that trigger parsing failures.

CEH guidance highlights that PoD-style attacks exploit improper packet validation and reassembly logic. Modern systems are generally patched, but poorly maintained devices, legacy OS stacks, and some embedded implementations can still exhibit instability when exposed to malformed fragmentation and reassembly edge cases.

Sherlock is the correct choice because it is specifically designed for OSINT-style username enumeration across a very large number of websites. In CEH-aligned reconnaissance, one common task is “alias correlation,” where the tester checks whether the same username exists across multiple social networks, forums, and content platforms. Sherlock automates this by querying many supported sites and reporting where an account with a given username appears to exist. This directly matches the question’s requirement: “cross-platform username correlation by scanning hundreds of social networking sites.”

The prompt also specifies what the tool does not do: it “does not natively support geolocation tracking or visualizing identity relationships.” That limitation aligns with Sherlock’s role as a focused username discovery tool rather than an analysis platform. By comparison, Creepy is associated with geolocation-focused OSINT, particularly collecting and correlating location metadata from social media posts and images, which is the opposite of the stated limitation. Maltego is well known for relationship analysis and link visualization, allowing investigators to build graphs of people, emails, domains, and social entities—again contradicting the “does not visualize identity relationships” constraint. Social Searcher is more oriented toward searching and monitoring public social media content and mentions, not primarily high-volume username existence checking across hundreds of sites in the same manner.

In CEH reconnaissance workflows, Sherlock fits early-stage enumeration to expand a target’s footprint, after which analysts may pivot into tools like Maltego for link analysis or geolocation tools when location exposure is part of the assessment.

This scenario demonstrates tailgating, which is gaining unauthorized physical access to a secure area by following an authorized person through an access-controlled entry point. Priya does not present credentials, swipe a badge, or otherwise authenticate; instead, she leverages normal human behavior and social assumptions during a busy shift change. Because employees assume she belongs there and do not challenge her, she successfully bypasses the physical access control.

Tailgating is common in workplaces with high traffic, open-plan culture, or weak enforcement of “no badge, no entry” rules. Attackers may exploit politeness, distraction, or the desire to hold doors open. It is especially effective during shift changes, deliveries, or when people are carrying items and appreciate someone holding the door. The security weakness being tested here is not the badge technology itself but the human factor: lack of challenge culture and inconsistent adherence to access policies.

Tailgating versus piggybacking: in many security references, piggybacking implies the authorized person knowingly allows the other to enter (e.g., holds the door intentionally after being asked). Tailgating typically implies the intruder enters without explicit permission, often by slipping in behind a group. In this scenario, no one confronts her and they “assume she belongs there,” indicating she is following them in without asking or being granted explicit permission—tailgating.

The other options are unrelated: shoulder surfing is visual observation of sensitive input; dumpster diving is retrieving information from trash. Therefore, the correct answer is C. Tailgating.

CEH v13 explains that reflected XSS occurs when malicious input supplied by an attacker is immediately returned in the HTTP response without sanitization. This type of XSS is typically exploited through a crafted URL containing embedded JavaScript payloads. When a victim clicks the link, the vulnerable server reflects the injected script back to the browser, executing it within the user’s session context. CEH emphasizes that reflected XSS relies on social engineering to deliver the payload, often via links sent through email, messaging platforms, or compromised pages. The goal may include stealing session cookies, redirecting users, or manipulating page content. Brute-forcing credentials (Option A) has no relation to XSS. SQL injection (Option C) targets backend databases, not client-side script execution. Directory traversal (Option D) concerns file path manipulation, not dynamic script injection. Therefore, embedding a malicious script in a URL is the correct method to exploit reflected XSS.

The most likely missing BYOD guideline is reviewing application permissions before installation. In CEH mobile security guidance, a major risk in BYOD environments is the introduction of untrusted or malicious applications that abuse the mobile permission model to access corporate data, intercept authentication tokens, read storage, capture keystrokes via accessibility services, or communicate externally. When users install apps without scrutinizing requested permissions, they may unknowingly grant excessive privileges that enable data theft or access-control bypass, especially if the app leverages OS weaknesses or misconfigurations.

The scenario states Javier “installs a malicious app that bypasses access controls” and gains access to sensitive financial data because devices “lack a specific security measure to restrict app access.” This maps directly to a policy gap around controlling and validating apps and their permission requests. CEH emphasizes that organizations should reduce attack surface by limiting app privileges, avoiding sideloading from untrusted sources, and enforcing least privilege through user awareness and enterprise controls such as MDM application allowlisting and permission governance. Reviewing permissions is the user-facing guideline that prevents employees from granting dangerous access (for example, SMS, storage, contacts, accessibility, device admin, or VPN configuration permissions) that can enable credential theft or unauthorized data access.

Option B adds an extra layer for local access but does not stop a malicious app with granted permissions from accessing corporate data. Option C helps if a device is physically stolen, but it does not prevent malicious apps already running under the user context. Option D protects data at rest, yet a malicious app can still exfiltrate data once it is decrypted and accessed by the user session. Therefore, permission review is the most directly relevant missing BYOD guideline.

CEH v13 details the standard penetration testing workflow, where confirmed critical vulnerabilities—especially those affecting core systems like database servers—should be prioritized for exploitation only after verification and when explicitly permitted by the rules of engagement. Exploiting a known vulnerability using vetted tools (e.g., Metasploit, CVE-specific exploits) provides evidence of real-world risk and validates the severity rating. Brute-forcing logins (Option B) is inefficient and often outside scope. Ignoring a critical vulnerability (Option C) violates CEH’s prioritization guidelines. A DoS attack (Option D) is never appropriate unless the engagement explicitly authorizes destructive testing, which is rare. CEH stresses that high-impact vulnerabilities should be exploited to demonstrate business risk, privilege escalation potential, data exposure, or lateral movement possibilities—making Option A fully aligned with CEH methodology.

The correct answer is RSA. CEH cryptography coverage describes RSA as a widely used asymmetric algorithm that supports encryption and digital signatures and is commonly deployed in public-key infrastructures. The question states that the transaction data is hashed, the hash is signed with the sender’s private key, and the recipient verifies the signature with the matching public key. That is the classic RSA signature model presented in CEH materials. The additional clue is that the same algorithm is said to support encryption, digital signatures, and secure communications use cases. Diffie-Hellman is mainly a key exchange mechanism and is not used for digital signatures in the way described here. DSA is designed for digital signatures, but not for general encryption. ElGamal can support encryption and signatures, but CEH exam framing most strongly associates this full combination of encryption plus digital-signature verification with RSA. CEH references repeatedly emphasize RSA as the standard asymmetric cryptosystem for confidentiality, authentication, integrity, and nonrepudiation in enterprise communications. Because the described implementation combines hashing, private-key signing, and public-key verification within a broad asymmetric framework, RSA is the most accurate answer.

Ransomware encrypts user data and extorts payment for restoration. CEH covers ransomware as a major threat in system hacking, highlighting encryption-based extortion as its defining behavior.