Ethical Hacking & Penetration Testing Advanced

Ethical hacking is the practice of probing systems for weaknesses with the owner’s explicit permission, in order to find and fix flaws before a malicious attacker does. A penetration test (pentest) is a structured, time-boxed engagement that simulates a realistic attack against an agreed target.

The only thing that separates an ethical hacker from a criminal is authorisation. The exact same network probe can be a lawful security assessment or a felony, depending entirely on whether the owner agreed to it in writing. This course teaches the methodology, concepts, and defences at a conceptual level — not weaponised, step-by-step attack recipes.

• Goal: reduce real-world risk by discovering exploitable weaknesses first.
• Output: a prioritised report of findings plus remediation advice.
• Mindset: think like an attacker, act like a professional, document everything.

Defence link: every offensive concept below is paired with the control that stops it. A pentest is worthless unless its findings make the defenders stronger.

Before any testing begins, you need signed, written authorisation from someone with the authority to grant it (the asset owner, not just a friendly sysadmin). Testing without it can breach laws such as computer-misuse and unauthorised-access statutes, regardless of good intentions.

The authorisation letter — informally called the get-out-of-jail-free letter — typically states who is authorised, what systems are in scope, the time window, and an emergency contact. Testers often carry it during on-site work in case they are challenged.

• Authority to grant: only the legal owner can authorise testing of an asset.
• Third parties: cloud providers and SaaS vendors usually require separate permission.
• Stay in scope: the letter protects you only for what it explicitly covers.

Defence link: organisations should keep a register of who may authorise security testing, so that unsanctioned "tests" are easy to distinguish from real attacks.

The Rules of Engagement (RoE) and scope documents turn permission into a precise plan. They define exactly what may be tested, how, and when — protecting both the client and the tester.

• In-scope / out-of-scope: specific IP ranges, domains, applications, or accounts. Anything not listed is off-limits.
• Allowed techniques: e.g. whether denial-of-service or social engineering is permitted.
• Testing window: dates, times, and any blackout periods (e.g. business-critical hours).
• Escalation path: who to call immediately if a live system is destabilised or real evidence of a prior breach is found.
• Handling of sensitive data: rules for what may be accessed, copied, or must be left untouched.

Defence link: clear scope means the blue team can correlate alerts with the engagement and avoid wasting an incident-response effort on the testers — while still staying alert to real intrusions happening in parallel.

Engagements differ by how much information the tester is given up front. More knowledge means deeper coverage in less time; less knowledge more closely mimics an outside attacker.

• Black box: the tester gets little or no internal information — closest to an external attacker’s view, but slower and may miss deep flaws.
• Grey box: partial information (e.g. a low-privileged account or basic architecture). A common, efficient middle ground.
• White box: full disclosure — source code, credentials, diagrams. Maximises depth and is ideal for thorough assurance.

Tests are also framed by vantage point:

• External: simulates an attacker on the public internet hitting internet-facing assets.
• Internal: simulates a threat that is already inside — a malicious insider or a foothold gained via phishing.

Defence link: a mix of perspectives over time gives the most complete assurance, because external hardening and internal segmentation are different problems.

Most pentests follow a recognisable lifecycle. Naming varies, but the classic phases are:

1. Reconnaissance: gather information about the target.
2. Scanning & enumeration: identify live hosts, services, and details.
3. Gaining access: demonstrate that a weakness is genuinely exploitable.
4. Maintaining access: show whether a foothold could persist (in authorised tests only, and cleaned up afterward).
5. Covering tracks / analysis: attackers hide; ethical testers instead document everything and restore the environment.

A key ethical distinction: where a criminal "covers tracks" to evade detection, the ethical hacker records every action for the report and works with defenders to ensure logs reveal what an attacker would do.

Defence link: each phase maps to a control — recon to information minimisation, scanning to network monitoring, access to hardening and patching, persistence to endpoint detection, and tracks to robust, tamper-resistant logging.

Several frameworks give structure and shared vocabulary to security testing. You should understand them at a high level.

• PTES (Penetration Testing Execution Standard): a methodology describing phases from pre-engagement interactions and intelligence gathering through threat modelling, exploitation, post-exploitation, and reporting.
• Cyber Kill Chain: a model (originated by Lockheed Martin) describing an intrusion as a sequence of stages such as reconnaissance, weaponisation, delivery, exploitation, installation, command-and-control, and actions on objectives. Breaking any link disrupts the attack.
• MITRE ATT&CK: a large, community knowledge base of real-world attacker tactics (the why) and techniques (the how), organised into a matrix. It is widely used to map detections and measure defensive coverage.

Defence link: ATT&CK lets defenders ask "which techniques can we actually detect?" and find gaps; the kill chain encourages layered controls so that no single failure leads to full compromise.

Reconnaissance is information gathering. It comes in two flavours:

• Passive recon: collecting information without directly touching the target — using public sources. Because nothing is sent to the target, it is stealthy and very low-risk.
• Active recon: directly interacting with the target (e.g. connecting to services). It yields richer data but is detectable and must be within scope.

OSINT (Open-Source Intelligence) is the discipline of gathering information from publicly available sources: search engines, public DNS records, certificate transparency logs, job postings (which reveal technologies in use), and social media. Conceptually, attackers build a profile of an organisation from data it has already published.

Defence link: reduce your attack surface by minimising what you publish — avoid leaking internal hostnames, technology stacks, or employee details that aid targeting. Awareness training helps staff avoid oversharing.

Once recon is done, testers map the live attack surface. Scanning discovers which hosts are up and which network ports and services are reachable; enumeration then extracts details such as software versions and exposed shares.

nmap is the classic network-mapping tool. Conceptually, it is used to discover live hosts, identify open ports, and fingerprint the services and versions listening on them — building an inventory of what is exposed. It is a discovery and mapping tool, not an exploit.

A simple, read-only host-discovery sweep on an authorised, in-scope range looks like the command below. It only identifies which hosts respond — it does not attack anything.

Beginners often confuse two distinct activities:

• Vulnerability scanning: automated tools compare discovered software and configurations against databases of known issues and report potential weaknesses. This is breadth-first and largely non-intrusive, but produces false positives.
• Exploitation: a tester carefully and manually proves that a specific weakness is genuinely exploitable in this environment. This confirms real risk and removes false positives — but is riskier and must stay within scope.

A scanner might flag "outdated service, possibly vulnerable"; only validation tells you whether it is truly exploitable here. Frameworks such as Metasploit are commonly described as exploitation frameworks used (in authorised tests) to safely validate findings — used responsibly to confirm risk, never to cause harm.

Defence link: run your own regular vulnerability scans and patch what they find; do not wait for an annual pentest to learn about known, fixable issues.

Most real-world compromises trace back to a handful of recurring weakness categories. Understanding them conceptually helps you both find and fix them.

• Misconfiguration: default settings, unnecessary services, overly permissive access, exposed admin panels. Defence: hardening baselines and configuration reviews.
• Weak or default credentials: guessable, reused, or never-changed passwords. Defence: strong unique passwords, MFA, and removing defaults.
• Unpatched software: known vulnerabilities left unfixed. Defence: timely patch management and asset inventory.
• Injection flaws: untrusted input treated as commands or queries. Defence (conceptual): validate input and use parameterised, safe APIs so data can never be interpreted as code.

This is intentionally high-level and defensive: the value is in recognising the class of flaw and the control that neutralises it, not in any specific attack string.

Web applications are a huge part of most attack surfaces. The OWASP Top 10 is a widely referenced, regularly updated awareness document listing the most critical categories of web-application security risk — a shared checklist for testers and developers alike.

Recurring categories (described conceptually) include broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, and insufficient logging and monitoring.

Burp Suite is commonly described as an intercepting web-proxy and testing platform: it lets an authorised tester observe and analyse the HTTP traffic between a browser and an application to understand how it behaves. It is an inspection and analysis tool, used within scope.

Defence link: developers should map their controls to each OWASP category — enforce access control server-side, encrypt sensitive data, validate input, and log security-relevant events.

Credentials remain a top route to compromise. At a conceptual level, attackers may try guessing common passwords, reusing credentials leaked in prior breaches (credential stuffing), or attempting many candidates offline against stolen hashes. We focus on understanding the threat to build defences — not on cracking workflows.

The strongest defences are well established:

• Multi-factor authentication (MFA): even a stolen password is not enough by itself.
• Long, unique passphrases: length beats complexity; a password manager makes uniqueness practical.
• Strong password hashing: store credentials with slow, salted algorithms designed for the purpose, so stolen hashes resist offline guessing.
• Lockout / rate limiting: slow down online guessing.
• Breached-password checks: reject passwords known to be exposed.

Defence link: MFA plus unique, well-hashed credentials neutralises the majority of password attacks at once.

An initial foothold is rarely the end goal. Two concepts describe how an intruder expands reach:

• Privilege escalation: moving from limited rights to higher rights on the same system — for example from a normal user to an administrator. Vertical escalation gains more power; horizontal escalation accesses another user’s data at the same level.
• Lateral movement: using a compromised host as a stepping stone to reach other systems across the network, often by reusing harvested credentials.

Conceptually, attackers exploit excessive permissions, weak internal trust, and shared credentials. Understanding this motivates layered internal defences.

Defence link: apply least privilege (grant only what is needed), network segmentation (limit which systems can talk to each other), and strong internal monitoring so a single foothold cannot quietly become full domain compromise.

Social engineering targets people rather than technology — manipulating someone into revealing information or taking an unsafe action. Common concepts include phishing (deceptive messages), pretexting (a fabricated scenario), and tailgating (following staff through a secure door).

In an ethical engagement, social engineering is only performed when explicitly authorised in the scope, with careful boundaries to avoid harming or unfairly singling out individuals. The aim is to measure organisational resilience and improve training — never to embarrass employees. Results are reported in aggregate where possible.

Defence link: the strongest mitigations are security-awareness training, clear procedures for verifying requests, easy ways to report suspicious messages, and technical controls such as MFA and email authentication that limit the damage even when someone is fooled.

After demonstrating access, the tester’s job is to safely show impact, then leave the environment exactly as they found it. Post-exploitation answers business questions: what could a real attacker reach, what data is at risk, and how far could the breach spread?

• Demonstrate impact, minimise harm: prove access to sensitive resources without exfiltrating real data or disrupting operations.
• Document everything: record actions, timestamps, and evidence so findings are reproducible and the blue team can verify their logs.
• Cleanup: remove any test artefacts — accounts, files, tools, or persistence created during the test — and confirm systems are back to normal.

This is the ethical inverse of an attacker’s "maintain access and hide" stage: the tester proves the risk, then carefully restores the environment and hands over a clear trail.

Defence link: strong endpoint detection, integrity monitoring, and reliable logging let defenders spot exactly the post-exploitation behaviours the test demonstrates.

The report is the real deliverable — a pentest exists to make the organisation safer, and that only happens if findings are clearly communicated and fixed.

A good report typically contains:

• Executive summary: business-level risk in plain language for leadership.
• Methodology and scope: what was tested and how, for context and repeatability.
• Findings: each weakness with a clear description, evidence, and a severity rating based on likelihood and impact.
• Remediation guidance: concrete, prioritised advice on how to fix each issue.

After the client remediates, a retest verifies that the fixes actually work and did not introduce new problems. This closes the loop: find → report → fix → verify.

Defence link: prioritise remediation by severity, track fixes to completion, and feed lessons back into secure development and configuration baselines so the same class of issue does not recur.