Many IDS reassemble communication streams; hence, if a packet is not received within a reasonable period, many IDS stop reassembling and handling that stream. If the application under attack keeps a session active for a longer time than that spent by the IDS on reassembling it, the IDS will stop. As a result, any session after the IDS stops reassembling the sessions will be susceptible to malicious data theft by attackers. The IDS will not log any attack attempt after a successful splicing attack. Attackers can use tools such as Nessus for session splicing attacks.
Did you know that the EC-Council exam shows how well you know their official book? So, there is no
"Whisker" in it. In the chapter "Evading IDS" -> "Session Splicing", the recommended tool for performing a session-splicing attack is Nessus. Where Wisker came from is not entirely clear, but I will assume the author of the question found it while copying Wikipedia.
https://en.wikipedia.org/wiki/Intrusion_detection_system_evasion_techniques One basic technique is to split the attack payload into multiple small packets so that the IDS must reassemble the packet stream to detect the attack. A simple way of splitting packets is by fragmenting them, but an adversary can also simply craft packets with small payloads. The 'whisker' evasion tool calls crafting packets with small payloads 'session splicing'.
By itself, small packets will not evade any IDS that reassembles packet streams. However, small packets can be further modified in order to complicate reassembly and detection. One evasion technique is to pause between sending parts of the attack, hoping that the IDS will time out before the target computer does. A second evasion technique is to send the packets out of order, confusing simple packet re-assemblers but not the target computer.
NOTE: Yes, I found scraps of information about the tool that existed in 2012, but I can not give you unverified information. According to the official tutorials, the correct answer is Nessus, but if you know anything about Wisker, please write in the QA section. Maybe this question will be updated soon, but I'm not sure about that.

DNS hijacking occurs when attackers manipulate DNS responses to redirect traffic to malicious servers. CEH v13 clearly identifies DNSSEC (Domain Name System Security Extensions) as the primary defense against such attacks.
DNSSEC adds cryptographic signatures to DNS records, enabling clients to verify authenticity and integrity of DNS responses. Without DNSSEC, attackers can spoof DNS responses even if servers are fully patched.
Changing IP addresses and using LAMP do not address DNS trust. Patching is essential but does not prevent DNS spoofing.
CEH v13 explicitly recommends DNSSEC for preventing cache poisoning and DNS hijacking attacks, making Option C the correct answer.

https://en.wikipedia.org/wiki/Network_Time_Protocol
The Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks.
NTP is intended to synchronize all participating computers within a few milliseconds of Coordinated Universal Time (UTC). It uses the intersection algorithm, a modified version of Marzullo's algorithm, to select accurate time servers and is designed to mitigate variable network latency effects. NTP can usually maintain time to within tens of milliseconds over the public Internet and achieve better than one millisecond accuracy in local area networks. Asymmetric routes and network congestion can cause errors of 100 ms or more.
The protocol is usually described in terms of a client-server model but can easily be used in peer-to-peer relationships where both peers consider the other to be a potential time source. Implementations send and receive timestamps using the User Datagram Protocol (UDP) on port number 123.

In CEH v13 Cloud Computing, APIs are identified as the primary control plane for managing cloud resources. A vulnerability in a cloud API can allow attackers to bypass authentication, escalate privileges, and manipulate resources.
Unauthorized access may lead to:
* Data exposure
* Resource abuse
* Account takeover
* Lateral movement within the cloud environment
Physical security (Option A) and encryption at rest (Option D) are unrelated to API flaws. DDoS attacks (Option C) are possible but not the primary risk of API vulnerabilities.
Thus, Option B is correct.