Ethical Hacking — FAQ
Is running a social engineering assessment (phishing simulation, pretexting calls) against your own employees legally different from testing a technical system?
Yes, and this is worth being explicit about since it's easy to underestimate. Technical pen testing requires written authorization defining systems and scope; social engineering assessments additionally raise HR, privacy, and sometimes labor-law considerations that pure technical testing doesn't — deceiving employees, even for a legitimate security purpose, can implicate workplace policy and, in some jurisdictions, specific consent or notification requirements depending on what's actually simulated (a phishing email is generally uncontroversial; a simulated call impersonating a specific real coworker raises more questions). Rules of engagement for a social engineering assessment should explicitly cover this ground — what's simulated, how results are used (never punitively against individuals by name), and who internally (usually HR plus security leadership, not just IT) has signed off — separately from the technical scope document.
Why does CEH cover things like DoS attacks and malware analysis in detail when a "pen tester" would basically never be authorized to actually run either against a client's production systems?
Because CEH's framing is broader than "pen tester" specifically — it's meant to validate that a security professional in any number of roles (SOC analyst, security architect, incident responder, as well as pen tester) understands how these attack categories actually work well enough to recognize, defend against, and reason about them, not necessarily to execute them personally against live targets. This is exactly why this course's own certification material describes CEH as more theory/methodology-focused compared to OSCP's pure hands-on exploitation — CEH's DoS and malware domains test conceptual understanding (how does a SYN flood exhaust connection state, what distinguishes a worm's propagation from a virus's) more than "here's how you'd execute one," which is also why DoS testing in a real authorized engagement is typically scoped very narrowly if it's included at all, given the actual availability risk to production systems.
What's the actual difference between "sniffing" traffic and "man-in-the-middle" — aren't they the same attack?
They're related but not identical. Sniffing is passively capturing traffic that's already reaching your network interface — on a modern switched network, that's normally limited to your own traffic unless you've done something to redirect other traffic to yourself first. Man-in-the-middle (MITM) is the active step of inserting yourself into a communication path between two other parties (via ARP spoofing, a rogue access point, or a malicious proxy) so their traffic actually flows through you. In practice, a lot of real sniffing attacks against other people's traffic require a MITM technique first to redirect that traffic to where you can actually see it — sniffing is the capture step; MITM is often the mechanism that makes capturing someone else's traffic possible in the first place on a switched network.
Is WPA2 wireless encryption still considered secure, or should everything be WPA3 now?
WPA2 (with a strong, unique passphrase, not a weak or default one) remains reasonably secure for most purposes, but it does have known weaknesses worth knowing specifically — the 4-way handshake can be captured and subjected to offline dictionary/brute-force attacks against a weak passphrase (this is a passphrase-strength problem more than a protocol-break), and the KRACK (Key Reinstallation Attack) vulnerability affected WPA2 implementations broadly, patchable at the client/AP level rather than requiring a full protocol replacement. WPA3 is the current standard and meaningfully improves on this — its SAE (Simultaneous Authentication of Equals) handshake specifically resists offline dictionary attacks against a captured handshake, which was WPA2's biggest practical weakness. For new deployments, WPA3 is the better default where hardware supports it; for existing WPA2 networks, a strong unique passphrase plus keeping firmware patched addresses most of the practical risk in the meantime.
Why do IoT devices get singled out as a security problem so much more than regular computers or phones?
A few structural reasons specific to the category, not just "IoT is trendy to criticize": IoT devices often ship with no practical patching mechanism at all (unlike a phone or laptop with an OS update cycle), are frequently deployed by people without security expertise (facilities staff installing a smart thermostat, not IT), commonly use hardcoded or default credentials that can't always even be changed (see this course's PYQ for the specific distinction between those two problems), and are often left running for years past the point a "normal" computing device would have been retired or updated, since a functioning thermostat or camera doesn't visibly "feel" outdated the way an old unsupported laptop does. The combination of "hard to patch," "hard to secure at installation time," and "long unmonitored lifespan" is what makes the category disproportionately risky, not any single one of those factors alone.
What's the point of session timeout/expiration if session hijacking already requires stealing an active token?
Session timeout limits the window of opportunity for a stolen token to still be useful — a token stolen from an idle session that's already expired is worthless to an attacker, regardless of how it was obtained (sniffing, XSS, physical device access). This is a defense-in-depth layer that doesn't prevent the initial theft at all, but meaningfully reduces the value of a successful theft by shrinking how long the stolen credential remains valid — which is exactly why session timeout policy is usually paired with, not a substitute for, the actual token-security measures (secure random generation, httpOnly/Secure cookie flags, HTTPS-only transmission) that prevent theft in the first place.
Does "evading IDS/firewalls" as a tested skill mean ethical hackers are taught to help attackers bypass detection?
The purpose is the inverse of how it might sound — understanding evasion techniques (fragmentation, encoding, timing-based approaches) is what lets a security professional actually configure detection systems to not have those gaps, and lets a pen tester demonstrate to a client whether their existing detection investment actually catches a moderately sophisticated attacker or only catches unsophisticated, signature-obvious attacks. An organization that's never had its IDS/firewall tested against basic evasion techniques has a real blind spot in knowing whether their detection actually works under realistic conditions — this is the same logic behind why red team engagements exist at all (testing detection capability specifically), just applied at the individual-technique level rather than as a full campaign.
Is a hardware security key (like a YubiKey) actually immune to social engineering, since it can't be phished for a password?
It's dramatically more resistant, but "immune" oversells it slightly, and it's worth being precise about why. A properly implemented FIDO2/WebAuthn hardware key cryptographically binds the authentication to the specific legitimate domain it was registered for — a phishing site with a different (even visually similar) domain simply can't complete the authentication ceremony, which is what makes hardware keys resistant to the classic credential-phishing and even real-time proxy-based phishing attacks that defeat SMS/push-based MFA. What it doesn't protect against: social engineering aimed at getting someone to physically hand over or use the key on the attacker's behalf under a false pretext (a sufficiently convincing pretext could still get an employee to authenticate something they shouldn't, using their own legitimate key) — the cryptographic binding defends the phishing vector specifically, not every conceivable social engineering angle.
Why does this course keep saying "restore the system to its original state" after an authorized engagement — isn't documenting the vulnerability enough?
Because leaving any artifacts behind (uploaded tools, created test accounts, modified configurations used to demonstrate a finding) creates a real, separate risk even after the engagement officially ends — those artifacts could later be discovered by an actual attacker and mistaken for or repurposed as an existing foothold, or simply forgotten and left as unauthorized access that persists indefinitely with no one tracking it. Cleanup is a professional and ethical obligation distinct from the reporting obligation — the client authorized temporary testing access, not a permanent backdoor left "for convenience," and treating cleanup as optional once the report is written undermines the trust the entire engagement depends on.