CEH v13 Readiness Diagnostic - 15-Question Gate

Exam code: 312-50 (CEH v13, EC-Council) Format: 15 scenario-weighted MCQs. 4 options (A-D), single best answer unless stated. Time target: ~30 min (2 min/Q - slightly faster than live exam). Purpose: Cross-references Sets A/B/C (125 questions already taken). This is the go / no-go gate before booking the EC-Council exam slot.

Scoring bands (out of 100):

≥ 80 → READY. Book the exam this week.

65-79 → BORDERLINE. One more focused week on the weak domains printed below.

< 65 → NOT READY. Two more weeks of structured practice; re-take the diagnostic before booking.

How to use: Sit down, no notes, no Sets A/B/C in view. Answer all 15. Tally points using the band at the bottom, then read the Why lines for every miss (not just your wrong ones - CEH is sneaky with “BEST” wording). The diagnostic intentionally overlaps with Sets A/B/C by ~60 %; if you got it right because you saw it before, treat it as a half-credit in your own ledger.

Domain 1 - Information Security Threats & Attack Vectors

Q1. Nmap flags (5 pts)

A penetration tester is scanning a single external host on a stable, low-latency link. The blue team’s IDS only logs complete TCP three-way handshakes to keep alert volume low. The tester needs a TCP scan that completes a full handshake so the IDS sees the same artefacts as any legitimate client - the goal is enumeration that blends into the existing baseline. Which Nmap flag combination is the best fit?

A. nmap -sS -p 22,80,443 -T4 target B. nmap -sN -p 22,80,443 -Pn target C. nmap -sT -p 22,80,443 -T4 target D. nmap -sI zombie:80 -p 22,80,443 -Pn target

Points: 5 | Domain: 3.A Recon (Nmap scan-type selection)

Answer: C Why: -sT performs a full three-way handshake via the OS connect() syscall, so every probe is indistinguishable from a benign client on a handshake-only IDS. -sS (A) is half-open / SYN-only and leaves an unfinished handshake in the IDS. -sN (B) is a NULL stealth scan that gets RST from any Windows port (including open ones), so results are unreliable on heterogeneous estates. -sI (D) is an idle/zombie scan - completely different goal (hiding source IP), and overkill for a handshake-only IDS. https://nmap.org/book/synscan.html · cross-ref Set A Q8, Q9, Q11.

Q2. OWASP Top 10 - scenario (10 pts)

A fintech’s loan-origination API accepts a JSON document containing a redirect_url field. The server-side code does HttpClient.GetAsync(userSuppliedUrl) to “warm” the URL before the user lands on it. An attacker submits a callback pointing at http://169.254.169.254/latest/meta-data/iam/security-credentials/. The application is running on AWS EC2 with an attached instance role named loan-app-prod. The endpoint returns STS credentials that the attacker exfiltrates via a second callback to their server. Which OWASP Top 10 (2021) category best describes the root cause, and what is the minimum AWS control that would have prevented the credential leak?

A. A03:2021 Injection; control = parameterised queries B. A10:2021 Server-Side Request Forgery (SSRF); control = enforce IMDSv2 (require PUT + token) and block 169.254.169.254 in egress firewall C. A05:2021 Security Misconfiguration; control = enable CloudTrail in all regions D. A01:2021 Broken Access Control; control = enforce per-route IAM policies

Points: 12 | Domain: 3.C Web/Cloud (OWASP + Capital-One-class SSRF)

Answer: B Why: OWASP A10:2021 (SSRF) explicitly covers the “fetch a user-supplied URL” failure mode. The canonical example is the 2019 Capital One breach, where an SSRF in a WAF reached 169.254.169.254, the v1 EC2 Instance Metadata Service returned STS credentials unauthenticated, and the over-broad role (ISRM-WAF-Role with list/read on 700+ S3 buckets) exfiltrated ~30 GB / 106 M records. AWS shipped IMDSv2 in November 2019 in direct response: the metadata service now requires a PUT to obtain a session token, then the token must accompany every GET, defeating SSRF (the attacker can’t easily PUT through an HTTP client they don’t fully control). Egress filtering on 169.254.169.254 is the second-layer fix. CloudTrail (C) is logging-only; per-route IAM (D) doesn’t address the SSRF root cause. https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ · https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html · cross-ref Set A Q37, Q44; Set B Q74.

Q3. Kill Chain phase (5 pts)

A SIEM alert fires: a single endpoint just opened an outbound TCP/443 connection to a never-seen-before IP, downloaded a 12 MB binary named update.exe, wrote it to %APPDATA%\Microsoft\Updates\, and immediately spawned it. The binary then injected shellcode into explorer.exe and reached out to a hard-coded C2 over HTTPS on port 443 with a 60-second beacon. Which Lockheed Martin Cyber Kill Chain phase was the first one this incident satisfies?

A. Phase 2 - Weaponization B. Phase 3 - Delivery C. Phase 4 - Exploitation D. Phase 6 - Command & Control (C2)

Points: 5 | Domain: 1.A Threats (Lockheed Martin Kill Chain)

Answer: B Why: The Kill Chain’s seven phases are: 1 Reconnaissance, 2 Weaponization, 3 Delivery, 4 Exploitation, 5 Installation, 6 Command & Control, 7 Actions on Objectives. The first observable here is Delivery - the user (or a prior phish) pulled the payload into the environment via HTTP download. Weaponization (A) happened earlier (the attacker coupled the dropper with an exploit before sending it) and is invisible to the defender. Exploitation (C) would be the moment code execution happens - but the first signal a defender sees is the inbound delivery. C2 (D) is correct for the beacon but it’s not the first phase satisfied - by definition you satisfy phases in order. CEH v13 explicitly tests “which phase does this first satisfy” to catch students who pick the most-severe phase instead of the chronologically-earliest. https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html · cross-ref Set B Q52.

Q4. MITRE ATT&CK tactic (5 pts)

A SIEM correlates three events on the same Linux host over 90 seconds: (1) a process reads /etc/shadow; (2) the same process spawns find / -perm -4000 -type f 2>/dev/null; (3) it then execs sudo -l and inspects the result. The host has no prior compromise indicators. Which MITRE ATT&CK Tactic is the attacker operating in?

A. TA0007 - Discovery B. TA0008 - Collection C. TA0004 - Privilege Escalation D. TA0001 - Initial Access

Points: 5 | Domain: 1.A Threats (ATT&CK Tactic mapping)

Answer: A Why: The three events - reading /etc/shadow, enumerating SUID binaries with find -perm -4000, and listing sudo rights - are textbook Discovery techniques: T1083 File and Directory Discovery, T1518 Software Discovery (SUID scan is a sub-technique of looking for privesc vectors), and T1059-adjacent recon. Collection (B) is aggregating target data for exfiltration - the attacker hasn’t exfiltrated yet. Privilege Escalation (C) is doing the privesc, not enumerating the path. Initial Access (D) is entry into the environment, which already happened. CEH v13 distinguishes between enumerating privesc vectors (Discovery, TA0007) and successfully elevating (Privilege Escalation, TA0004). https://attack.mitre.org/tactics/TA0007/ · cross-ref Set A Q1, Q24.