CEH v13 312-50v13 Syllabus Exam Questions Answers

The attack described is spear phishing because it is a targeted phishing attempt crafted for a specific individual using personal and organizational context. In CEH social engineering coverage, spear phishing differs from generic phishing by its customization: the attacker addresses the victim by name, references the victim’s job function, and tailors the message to create credibility and urgency. Here, the email is addressed specifically to Clara and mentions her role in the accounts team, which increases the likelihood she will trust the message and comply.

The message uses classic phishing psychological triggers emphasized in CEH materials: urgency and fear. By claiming a “critical system vulnerability” and threatening account suspension, the attacker pressures Clara to act quickly and ignore verification steps. The inclusion of a link to a login page that “resembles the company’s internal portal” indicates credential harvesting, where the attacker’s goal is to capture usernames and passwords or other authentication tokens. The subtle misspelling in the sender’s domain is a common indicator of lookalike or typosquatting domains used to mimic legitimate corporate email addresses and bypass casual inspection.

The other options do not match as well. Impersonation is a broader category, but spear phishing is the specific technique using an email lure with personalization. Quid pro quo involves offering a benefit or service in exchange for information, which is not present. Vishing is voice-based phishing via phone calls, not email. Recommended defenses in CEH guidance include verifying sender domains, using out-of-band confirmation with IT, enabling email security controls like SPF, DKIM, and DMARC, and enforcing phishing awareness training and MFA to reduce credential theft impact.

The correct answer is MX. CEH reconnaissance material explains that MX, or Mail Exchange, records identify the mail servers responsible for receiving email for a domain. When a tester wants to understand how an organization handles incoming email traffic, MX records are the most relevant DNS data source because they reveal the designated mail infrastructure and often the priority order of mail servers. In this scenario, the objective is to gather passive intelligence about communication infrastructure without performing active network probing, so querying DNS records is appropriate. SOA records provide domain authority and zone administration information, TXT records often contain verification or policy-related text such as SPF details, and NS records identify authoritative name servers. While those can all contribute to broader reconnaissance, they do not directly answer which systems are responsible for receiving mail. CEH emphasizes that MX records are commonly used during footprinting to identify email infrastructure, support phishing simulations, analyze third-party mail providers, or map communication dependencies. Because the question explicitly asks for the DNS record type that reveals mail server configuration, MX is the correct choice.

Insecure communication is defined in CEH’s mobile and IoT security modules as the failure to encrypt sensitive data transmitted between a device and a server. When applications use plain HTTP instead of HTTPS, all traffic—including authentication tokens, user identifiers, and session data—can be monitored and altered by an attacker through network sniffing or man-in-the-middle attacks. CEH emphasizes that insecure transport channels represent one of the most common and critical weaknesses in mobile ecosystems, allowing attackers to harvest credentials or inject malicious commands. Security misconfiguration refers to improper server settings, while SSL pinning issues involve certificate validation bypassing. Insufficient input validation pertains to application-side data validation. None of these align as directly as insecure communication, which precisely describes the unencrypted data exposure.

The behavior described most closely matches an Eclipse attack. In an eclipse attack, an adversary isolates a victim node by controlling its peer connections so that the node communicates only with attacker-controlled (or attacker-influenced) peers. Once isolated, the attacker can feed the victim a manipulated view of the blockchain—such as withholding blocks, delaying transactions, or presenting an alternative chain history. This can enable downstream impacts like double-spending against merchants who rely on that node’s view for confirmation.

The scenario’s strongest indicators are:

The node “received blocks only from a small, fixed set of peers for several hours,” suggesting abnormal peer diversity and potential isolation.

The attacker “controlled which peers that node communicated with,” which is essentially the definition of eclipsing a node.

The node “accepted a conflicting history” and the attacker supplied “a private chain until they were ready to reveal it,” consistent with feeding the victim a tailored chain view and then releasing/realigning it to profit from reversed payments.

Why the other options are less fitting:

A Finney attack (A) involves a miner pre-mining a block containing a spend, making a payment to a merchant, and then releasing the pre-mined block to invalidate the merchant’s transaction—this doesn’t require isolating a specific node’s peers for hours.

A DeFi sandwich attack (B) is a mempool/MEV tactic on decentralized exchanges involving front-running and back-running, unrelated to isolating node peer connections or feeding a private chain.

A 51% attack (C) involves controlling a majority of network hash power/stake to rewrite history at network scale. The scenario emphasizes isolation of a particular merchant-related node via peer control rather than majority network control.

Therefore, the attack is best identified as D. Eclipse Attack.