Ethical Hacking and Penetration Testing: A Technical Guide with Worked Examples

Ethical hacking is a broad practice of examining systems from an adversary’s perspective with permission. A penetration test is a bounded assessment that attempts to demonstrate exploitable weaknesses against agreed objectives. A vulnerability assessment usually prioritizes identifying and classifying weaknesses; a penetration test adds controlled validation and, where authorized, attack-path analysis. These activities overlap, but neither a scanner report nor a certification alone establishes that a complete penetration test has occurred.

Before sending traffic, obtain written authorization and rules of engagement. Identify permitted addresses, applications, identities, dates, techniques, and third-party restrictions. Agree on prohibited actions, sensitive-data handling, emergency contacts, and stop conditions. Cloud tenancy does not automatically authorize testing the provider’s infrastructure. A useful objective is specific: “Determine whether a standard user can read another user’s invoices,” rather than “hack the application.” Define the evidence needed and the acceptable operational impact before selecting tools. Authorization should also identify who can approve scope changes when an unexpected host or dependency appears.

Effective penetration testing methodology begins with a model of the system. Sketch users, applications, identity providers, databases, network segments, and administrative interfaces. Mark trust boundaries: places where data or identities cross between components with different privileges. In a web service, TLS protects traffic in transit, but it does not determine whether a logged-in user may access a particular record. Similarly, a firewall permitting HTTPS says little about whether the application correctly validates requests.

Protocol knowledge makes observations interpretable. TCP connection establishment indicates reachability, not application health; an HTTP 403 can reflect an application decision or a reverse proxy; DNS results may expose multiple delivery layers rather than a single origin server. Consider an application behind a proxy that accepts a client-supplied identity header. If the backend trusts that header without ensuring it came from the proxy, the boundary between external input and authenticated identity has failed. The test hypothesis is therefore about provenance and enforcement, not simply whether a particular product version appears old.

Network enumeration establishes what is reachable and what services appear to be available. Start with owner-provided inventories, then compare them with observations from the approved testing location. For a single isolated lab host, `nmap -sT -sV -p 22,80,443 192.0.2.10` illustrates a TCP connect scan with service detection on three ports. The address is reserved for documentation; substitute only your assigned lab target. Service detection sends application probes and is not passive. Even narrow scans need approved timing and monitoring when applied to operational systems.

Suppose the scan finds HTTPS and SSH. Record the target, port, observation time, tool version, and supporting output. Then verify what each service actually exposes: an SSH banner is a clue, while an HTTPS certificate may help identify the intended hostname. Name-based routing can produce different results when accessed by IP address versus hostname. Avoid treating banners as definitive vulnerability evidence because vendors may backport fixes without changing the upstream version string. Correlate observations with configuration, package information supplied by administrators, and behavior-based checks. The inventory should distinguish confirmed facts from hypotheses.

Vulnerability verification asks whether a suspected weakness is present, reachable, and consequential under the actual configuration. Start with a baseline request, change one relevant variable, and compare the result. For a local SQL injection exercise, imagine an application constructing `SELECT id FROM users WHERE username = '` plus untrusted input plus `'`. Input such as `alice' OR '1'='1` changes the predicate rather than remaining ordinary data. In a deliberately vulnerable training database, compare the returned rows with those from a normal username. Do not extend the experiment to extracting unrelated data: altered query behavior already supplies the relevant proof.

The root cause is mixing executable query structure with untrusted values. The durable repair is a parameterized query, such as `cursor.execute("SELECT id FROM users WHERE username = ?", (username,))` with Python’s sqlite3 interface. Placeholder syntax varies by driver. Retest with the original input and confirm it is handled as a literal value. This illustrates a broader rule for ethical hacking tools: scanner alerts generate hypotheses, not verdicts. Error messages alone may be ambiguous; pair positive evidence with a negative control, and document prerequisites, affected endpoints, and confidence. Never assume that a public proof of concept is safe merely because it is widely available.

Many important web application security failures concern authorization rather than complex payloads. In an approved lab, create two ordinary users, Alice and Bob, each with a synthetic invoice. Authenticate as Alice and request Alice’s invoice, for example `GET /api/invoices/101`. Then request Bob’s invoice identifier while keeping Alice’s session unchanged. If Bob’s invoice is returned, the application may have broken object-level authorization. Authentication proves who Alice is; authorization must separately prove that Alice may read the selected invoice. An unpredictable identifier can reduce guessing but does not replace that check.

Capture a minimal request-and-response pair, redact session secrets, and retain only synthetic records. Confirm that shared access was not intentionally granted before reporting a defect. A robust fix enforces the authorization policy server-side for every relevant operation, ideally constraining the database lookup by both object identity and the caller’s permitted scope. Retest reads and modifications separately because one endpoint may be protected while another is not. A useful regression matrix includes an unauthenticated visitor, an unrelated user, the owner, and an explicitly authorized administrator. Test both expected denials and legitimate access so that remediation does not simply disable the feature.

Exploitation demonstrates that a weakness crosses a security boundary; post-exploitation examines the access resulting from that crossing. In an authorized lab, gaining execution as a restricted service account does not automatically mean controlling the host. Determine the effective identity, relevant permissions, and whether the agreed objective has already been met. If the objective is to prove access to a protected directory, reading an owner-provided marker file is usually preferable to opening business documents. Privilege escalation, credential access, persistence, and lateral movement require explicit permission, not an assumption that initial access grants unlimited testing scope.

Attack-path analysis connects weaknesses while preserving these limits. For example, an application flaw might expose a synthetic service credential, and an overly broad network rule might permit that account to reach a test database. The finding is stronger when it explains each prerequisite and where a control could break the chain. Establish a checkpoint before every additional step: expected evidence, likely side effects, rollback, and stop criteria. After testing, remove created accounts and artifacts, invalidate test credentials, and verify cleanup with the owner. Avoid claiming that logs, backups, or all traces have disappeared; retention systems may preserve legitimate assessment evidence.

A useful report gives engineers enough information to reproduce and repair the issue without unnecessarily exposing secrets. Include scope, methodology, limitations, affected components, preconditions, reproduction steps, evidence, impact, and remediation. Separate demonstrated impact from plausible but untested consequences. Severity should account for exploitability and business context, not just a tool’s rating; when using CVSS, include the version and vector. An internet-exposed weakness affecting sensitive records differs from the same behavior in an isolated training system. During retesting, repeat the original experiment and inspect adjacent paths, then record whether the weakness is fixed, partially fixed, or still reproducible.

For CEH preparation, combine conceptual study with lab notes organized around enumeration, vulnerability analysis, exploitation, network security, and reporting. The Erudex course’s stated focus on adversarial methodologies and protocol-level flaws is most useful when learners repeatedly connect a failed security assumption to observable behavior and a durable fix. Treat the CEH v12 tag as a curriculum-version reference, not proof that it matches the current exam. Verify the applicable blueprint, eligibility requirements, and assessment format directly with the certification provider. Accreditation claims concern a specific certification program and scope; they do not automatically accredit a preparatory course. Course completion and earning a certification remain separate achievements.