Ethical Hacking Lesson 4 – Hacking Methodologies | Dataplexa

Ethical Hacking

I. Foundations & Hacking Mindset
1. What is Ethical Hacking 2. Hacker Types & Motivations 3. Legal & Ethical Considerations 4. Hacking Methodologies 5. Cyber Kill Chain 6. Footprinting & Reconnaissance 7. Passive vs Active Recon 8. Information Gathering Tools 9. Hacking Lab Setup 10. Kali Linux Overview
II. Reconnaissance & Scanning
11. DNS Enumeration 12. Whois & Network Enumeration 13. Google Dorking 14. Nmap Scanning 15. Port Scanning 16. Service Enumeration 17. Vulnerability Scanning 18. Nessus & OpenVAS 19. Banner Grabbing 20. Recon Best Practices
III. System & Network Attacks
21. Password Cracking 22. Brute Force Attacks 23. Credential Harvesting 24. Exploiting Misconfigurations 25. Linux System Attacks 26. Windows System Attacks 27. Privilege Escalation 28. Malware Concepts 29. Backdoors & Trojans 30. Network Sniffing 31. MITM Attacks 32. DoS Attacks 33. Wireless Attacks 34. Covering Tracks 35. Attack Mitigation
IV. Web Hacking & Real World
36. Web Architecture 37. OWASP Top 10 38. SQL Injection 39. Cross-Site Scripting (XSS) 40. Authentication Attacks 41. Session Hijacking 42. File Upload Vulnerabilities 43. API Security 44. Tools Summary 45. Mini Project – Ethical Hacking Lab
Foundations & Hacking Mindset · Lesson 4

Hacking Methodologies

A professional pen tester doesn't just open a tool and start clicking. Every serious engagement follows a structured process — a methodology that keeps the work focused, repeatable, and defensible. This lesson breaks down the frameworks that real security teams actually use.

Structure is what separates a pro from a script kiddie

Anyone can download a scanning tool and run it against an IP address. What makes a penetration tester genuinely valuable — and what justifies the fees they charge — is the ability to run a complete, structured engagement that covers every possible attack surface in a logical order, documents everything cleanly, and produces findings a client can actually act on.

That structure comes from methodology. A methodology is essentially a roadmap — it tells you what to do first, what to do next, what information you need before moving forward, and what the final output should look like. Without one, engagements become inconsistent, things get missed, and the report ends up incomplete.

The industry has several well-established frameworks. They differ slightly in terminology and emphasis, but they all describe the same fundamental process. Understanding them gives you a mental model you can carry into any engagement regardless of the target or the tools you are using.

The five phases that every engagement is built around

Before looking at named frameworks, it helps to understand the universal phases that almost every methodology is built around. The names and exact boundaries vary between frameworks, but the underlying logic stays the same.

PENETRATION TEST — PHASE FLOW
1

Reconnaissance

Gather as much information as possible about the target before touching any of their systems. This includes publicly available data — domain records, employee names, IP ranges, technologies in use, social media footprints. The goal is to understand the target's landscape so the rest of the engagement is focused and efficient.

2

Scanning & Enumeration

Actively probe the target's systems to map what is running — open ports, live hosts, running services, software versions, and operating systems. This phase moves from passive observation to direct interaction with the target environment. Everything found here feeds the next phase.

3

Gaining Access

Use the information gathered to exploit vulnerabilities and gain entry to the target system. This is what most people imagine when they think of hacking — but it is actually the third phase, not the first. Rushing to this stage without proper reconnaissance produces poor results and missed opportunities.

4

Maintaining Access

Demonstrate that an attacker could maintain persistent access to the compromised system — not just pop in and pop out. This phase shows the client what long-term damage would look like if a real attacker had been inside their network. In a professional engagement, this is done carefully and always documented.

5

Reporting

Document everything found — vulnerabilities, methods used, evidence, business impact, and remediation recommendations. The report is the deliverable the client pays for. It needs to be clear enough for a developer to act on and accessible enough for an executive to understand without a technical background.

Notice the order. Reconnaissance always comes first. Reporting always comes last. Everything in between builds on what came before. Skipping a phase or rushing through it almost always causes problems later in the engagement.

Three frameworks you will actually use on the job

Several formal frameworks exist that codify these phases into repeatable, auditable processes. Clients in regulated industries — banking, healthcare, government — often require that engagements follow a specific framework. Here are the three you will encounter most frequently.

PTES

Penetration Testing Execution Standard

Most Commonly Used

A community-driven standard that covers every aspect of a penetration test from the initial client communication all the way through to the final report. It defines seven phases: pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting.

Best for: General penetration testing engagements across any industry or target type.

OWASP Testing Guide

Open Web Application Security Project

Web Applications

Specifically focused on web application security testing. OWASP provides a comprehensive testing guide that covers authentication, session management, input validation, business logic flaws, and much more. The OWASP Top 10 — a list of the most critical web application vulnerabilities — is referenced in almost every web security engagement.

Best for: Web application penetration tests. Covered in depth in Section IV of this course.

NIST SP 800-115

National Institute of Standards and Technology

Government / Compliance

A technical guide published by the US government for information security testing and assessment. Widely referenced in government contracts and compliance-heavy industries. More formal and documentation-heavy than PTES, but highly respected in regulated environments.

Best for: US federal contractors, healthcare organisations, financial institutions under regulatory oversight.

Black box, white box, grey box — how much you know before you start

Beyond the methodology framework, every engagement also has a testing style — which determines how much information the tester is given about the target before they start. This is one of the first things agreed on during the planning phase and it significantly changes how the test is run.

TESTING STYLES — COMPARISON

Black Box

No prior knowledge of the target. The tester starts from scratch — just like a real external attacker would. Closest to a realistic attack simulation.

Grey Box

Partial knowledge — typically a standard user account and some basic network information. Simulates an insider threat or a compromised employee account.

White Box

Full knowledge — source code, network diagrams, credentials, architecture details. Allows the most thorough coverage. Often used for code reviews and compliance audits.

Time Required

Longest

Time Required

Moderate

Time Required

Shortest

Most real-world engagements use grey box testing. It balances realism — the tester doesn't have full knowledge of everything — with efficiency. Pure black box testing is the most realistic but also the most time-consuming, since the tester has to discover everything from scratch. White box is the most thorough for finding vulnerabilities but does not test whether an external attacker could discover the same issues themselves.

The full engagement timeline mapped from kickoff to report delivery

Here is what a complete engagement timeline looks like mapped out — from the first client conversation to the final report delivery. This is the process you will be executing by the end of this course.

ENGAGEMENT TIMELINE — START TO FINISH

Client Kickoff Call

Understand the client's goals, agree on scope, sign the NDA and Rules of Engagement. No testing happens yet.

Passive Reconnaissance

Research the target using only public sources — no direct contact with their systems. Domain records, employee data, technology stack, public-facing infrastructure.

Active Scanning

Probe the target directly — port scans, service enumeration, vulnerability scanning. All within the agreed scope and testing windows.

Exploitation

Attempt to exploit confirmed vulnerabilities. Gain access, escalate privileges where possible, demonstrate what a real attacker could reach inside the environment.

Post-Exploitation & Cleanup

Demonstrate persistence and lateral movement within scope. Then clean up — remove any tools or payloads placed during the test. Leave the systems exactly as found.

Report Delivery & Debrief

Deliver the written report. Walk the client's team through the findings in a debrief call. Answer questions. Agree on a retest timeline once vulnerabilities are patched.

The debrief at the end is something many new testers overlook. Handing over a PDF report and disappearing is not how professional engagements end. Clients expect a conversation — a chance to ask questions, understand priorities, and get clarity on what to fix first. That call is part of the deliverable.

Threat modelling — thinking like the attacker before you start

One phase that sits between reconnaissance and scanning — and that gets underused by less experienced testers — is threat modelling. It is the process of mapping out who is most likely to attack this specific client, what they would be after, and which entry points they would most logically pursue first.

A pharmaceutical company facing nation-state espionage threats needs a completely different test than a retail website facing opportunistic ransomware gangs. The vulnerabilities might overlap, but the priority order, the attack simulations, and the recommendations all change based on the realistic threat actor. Threat modelling is how you make that determination before a single scan runs.

Four Questions Every Threat Model Answers

1

What are we protecting? — The assets that matter most to this client. Customer data, intellectual property, financial systems, operational continuity.

2

Who would realistically attack this client? — Script kiddies, ransomware gangs, competitors, nation-states, disgruntled insiders.

3

How would they get in? — Phishing, unpatched software, exposed credentials, supply chain, physical access.

4

What would success look like for that attacker? — Data exfiltration, ransomware deployment, service disruption, reputation damage.

Teacher's Note: Methodology is not something you memorise and recite in an interview. It is something you internalise until it becomes instinct. By the end of this course, you will have followed this process enough times in practice that the phases feel natural — not like a checklist you have to look up.

Practice Questions

Scenario:

A financial company hires your firm for a penetration test. During the planning call, the client says: "We want to simulate what would happen if one of our employee accounts got compromised. We'll give you a standard user login and the basic network diagram, but nothing else." Based on how much prior knowledge you are being given, what type of testing style is this engagement using?


Scenario:

Before running a single scan, your team spends half a day answering four questions about the client: what are their most valuable assets, who is most likely to target them, how would that attacker realistically get in, and what would they do once inside. This work shapes the entire engagement plan that follows. What is this process called?


Scenario:

A new client asks your team to follow a community-driven framework that covers everything from the initial client communication through to intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting. They want a methodology that works across any industry and any type of target. Which framework are they asking for?


Quiz

Scenario:

A junior pen tester is eager to demonstrate results on a new engagement. On day one, they skip straight to running vulnerability scans against the target's live systems. Two days later they realise they missed an entire subdomain — one that turned out to contain the most critical vulnerability in the environment. Which phase of the methodology did they skip, and why does it matter?

Scenario:

A healthcare company needs to pass a compliance audit. Their security team asks for a penetration test that gives the tester full access to their application source code, internal network diagrams, all system credentials, and their full infrastructure documentation. The goal is to find every possible vulnerability — not to simulate what an outside attacker would discover. What type of testing is this?

Scenario:

Your team has successfully completed the exploitation and post-exploitation phases of an engagement. You have demonstrated full access to the client's internal network and shown that sensitive data could be reached. The client has confirmed they have seen enough. Before writing the report, what is the next step that must happen inside the target environment?

Up Next · Lesson 5

Cyber Kill Chain

A military-inspired framework that maps out every stage of a real attack — and shows exactly where defenders can intervene to stop it.

← Previous Course Index Next →