Ethical Hacking Essentials: Authorization, Methodology, and Evidence
Ethical Hacking Essentials (EHE) tests the disciplined execution of authorized security testing. The exam emphasizes written authorization and scope, reconnaissance, scanning and enumeration, vulnerability analysis, exploitation, post-exploitation restraint, cleanup, and reporting. Technical tools matter, but methodology and legality decide whether an action is ethical hacking or an incident.
Core rules and concepts
- Authorization first: obtain written permission and defined rules of engagement before testing. Scope must name target ranges, domains, applications, accounts, testing windows, prohibited actions, and emergency contacts.
- Phases: reconnaissance (passive and active), scanning, enumeration, vulnerability analysis, exploitation, post-exploitation, cleanup, and reporting. Each phase feeds the next, but testing can loop back when new evidence appears.
- Passive vs. active recon: passive methods use public sources without touching the target; active methods send traffic and are more detectable.
- Validation: a scanner finding is a lead, not proof. Confirm manually, distinguish false positives, and record reproducible evidence.
- Risk rating: CVSS base scores describe technical severity, but environmental and business context affect prioritization. A high score on an isolated test host may be less urgent than a medium flaw on an internet-facing authentication service.
- Restraint: prove impact with the minimum necessary action. Avoid destructive payloads, data exfiltration beyond agreed proof, persistence, or testing out-of-scope third-party services.
- Reporting: include scope, methodology, findings, evidence, business impact, remediation, and retest status. Raw tool output alone is not a report.
Worked example
An authorized web-application test permits a staging environment but prohibits denial-of-service and production data access. A scanner reports SQL injection on a login parameter. The tester reproduces it manually with a benign boolean condition, confirms different responses, and captures the request and response. They do not dump tables or use time-delay payloads that could stress the server. The finding is reported as confirmed SQL injection with the affected parameter, evidence, likely impact, and a parameterized-query remediation. The reasoning: authorization limits the environment and methods; manual validation removes scanner ambiguity; minimal proof preserves availability and avoids unnecessary data exposure.
Traps that cost marks
Do not assume a signed contract covers every host, subdomain, or cloud service. Do not confuse a vulnerability with an exploit or a proof of concept with weaponization. Do not report unvalidated scanner output as confirmed. Do not continue testing after scope, safety, or legal boundaries are unclear; stop and escalate. Do not omit cleanup, evidence handling, or retest guidance from the report.