What Ethical Hacking Is
Ethical hacking is the authorized practice of probing systems, networks, and applications for security weaknesses using the same techniques an adversary would — but with explicit permission, a defined scope, and the goal of improving defenses. The output is not exploitation for gain; it is a report that helps an organization reduce risk. The single trait that separates an ethical hacker from a criminal is authorization.
This page frames offensive concepts as methodology plus defense. Everything here is intended for systems you own, lab environments you build, or targets that have granted you written permission (including public bug bounty programs). Learning to think like an attacker is what lets you defend like one.
Legality: read this first
Only test systems you own or have explicit written permission to test. Unauthorized access — even "just scanning" or "just looking" — can be a crime under the US Computer Fraud and Abuse Act (CFAA), the UK Computer Misuse Act, and similar laws worldwide. Before any engagement, secure a signed scope document, defined rules of engagement (RoE), and an authorization letter (often called a "get-out-of-jail" letter) naming the systems, time window, and permitted techniques. No paperwork, no testing.
Authorization, Scope, and Rules of Engagement
Before touching a target, three documents must exist and be signed by someone with authority to grant it:
- Scope — exactly which IP ranges, domains, applications, and accounts are in and out of bounds. Anything not explicitly in scope is out of scope.
- Rules of Engagement (RoE) — permitted techniques (e.g., is social engineering allowed? DoS testing? physical access?), test windows, rate limits, data-handling rules, and emergency stop / point-of-contact procedures.
- Authorization letter — a signed statement that you are permitted to perform the work, kept on hand during testing in case activity is questioned.
Scope creep is a trap
If you discover an interesting host that is not in scope, stop and ask before touching it. "It was connected to the target" is not authorization. Document it, report it, and get written approval to extend scope.
Penetration Testing Methodology
Structured testing follows a repeatable methodology. The classic cyber kill chain describes the phases of an intrusion; a pentest mirrors them in a controlled, authorized way. Understanding each phase also tells a defender where to place controls.
The Phases
| Phase | Goal (attacker view) | Defensive control |
|---|---|---|
| Reconnaissance | Gather information about the target (OSINT, DNS, employees) | Minimize public exposure, attack-surface management |
| Scanning / Enumeration | Identify live hosts, open ports, services, versions | Firewalls, network segmentation, IDS/IPS |
| Gaining Access | Exploit a vulnerability to obtain a foothold | Patching, input validation, least privilege |
| Maintaining Access | Establish persistence to return later | EDR, integrity monitoring, log review |
| Covering Tracks | Remove evidence of the intrusion | Centralized/immutable logging (SIEM), alerting |
In an authorized engagement, "covering tracks" is inverted: you preserve full evidence and hand it to the client. You never destroy logs on a real system.
Standard Frameworks
Reputable testing follows a published standard so results are consistent and defensible:
| Framework | Focus |
|---|---|
| PTES | Penetration Testing Execution Standard — seven-phase end-to-end process |
| OSSTMM | Open Source Security Testing Methodology Manual — measurable, metrics-driven testing |
| NIST SP 800-115 | Technical guide to information security testing and assessment |
| OWASP WSTG / MITRE ATT&CK | Web app testing guide; adversary tactics/techniques catalog |
Types of Testing
By Knowledge Given to the Tester
| Type | Tester knows |
|---|---|
| Black box | Nothing — simulates an external attacker with no inside knowledge |
| Grey box | Partial info (e.g., a low-privilege account) — realistic and efficient |
| White box | Full access to source, architecture, and credentials — deepest coverage |
By Team Color
Red team emulates real adversaries against defenders who may not know a test is underway. Blue team is the defense — detection, response, hardening. Purple team is collaborative: red and blue work together in real time so every attack technique is mapped to a detection improvement.
Reconnaissance: Passive vs Active
Passive recon gathers information without touching the target directly — public DNS records, certificate transparency logs, WHOIS, search engines, social media, and job postings. Because you never interact with target infrastructure, it is low-risk and often out of the target's view. This is the core of OSINT (open-source intelligence).
Active recon interacts directly with the target — port scanning, banner grabbing, service enumeration. It generates traffic that can be logged and detected, so it must be inside your authorized scope and time window.
Enumeration with nmap (Lab Context)
The Nmap project runs scanme.nmap.org specifically so people can practice scanning legally (light scanning only; do not hammer it). Otherwise, scan your own VMs. A typical enumeration flow moves from broad host discovery to targeted service and version detection:
# Host discovery on a lab subnet you own
nmap -sn 192.168.56.0/24
# Fast TCP scan of the top 1000 ports
nmap -T4 scanme.nmap.org
# Service + version + default scripts on specific ports
nmap -sV -sC -p 22,80,443 scanme.nmap.org
# Full TCP port sweep, then version-detect only what's open
nmap -p- -T4 -oA fullscan 192.168.56.101
nmap -sV -p 22,80,3306 -oN services.txt 192.168.56.101
# OS detection + traceroute (needs root/CAP_NET_RAW)
sudo nmap -A 192.168.56.101Enumeration then drills into what was found: whatweb and gobuster for web content, enum4linux-ng for SMB, and manual review of banners and versions against known CVEs. Always correlate a version to a CVE before assuming exploitability.
Reporting: Writing a Finding
The report is the actual deliverable. A finding is only useful if the reader can understand the risk and fix it. Each finding should include a clear title, a severity backed by a CVSS score, exact reproduction steps, business impact, and concrete remediation.
## Finding: Reflected XSS in search parameter
Severity: High (CVSS 3.1: 7.4 / AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N)
Affected: https://app.lab.local/search?q=
Discovered: 2026-09-12
Summary
The `q` parameter is reflected into the HTML response
without output encoding, allowing arbitrary script execution
in a victim's browser session.
Steps to Reproduce
1. Navigate to /search?q=<script>alert(1)</script>
2. Observe the payload executes in the response context.
Impact
Session theft, credential harvesting, and actions performed
as the victim within the application.
Remediation
- Context-aware output encoding on all reflected input.
- Content-Security-Policy to restrict inline script.
- Framework auto-escaping (do not disable it).
References
CWE-79, OWASP WSTG-INPV-01Bug Bounty & Responsible Disclosure
Bug bounty programs (via HackerOne, Bugcrowd, Intigriti, or self-hosted) give you pre-authorized permission to test in-scope assets and often pay for valid findings. Always read the program's scope and policy first — it defines exactly what is allowed. Responsible / coordinated disclosure means reporting privately to the vendor, giving reasonable time to fix, and not going public until the issue is patched or a disclosure timeline is agreed.
A bounty is authorization, not immunity
Testing outside a program's stated scope, using excluded techniques, or accessing other users' data is still unauthorized — even on a platform that hosts bounties. Stay strictly within the published rules.
Legal Frameworks to Know
Laws criminalize unauthorized access to computer systems. In the US the CFAA is the primary statute; in the UK it is the Computer Misuse Act 1990; the EU has the Directive on attacks against information systems, and most countries have equivalents. Data-protection laws (GDPR, etc.) also apply to any data you handle during testing. When in doubt, get legal review and written authorization — good intentions are not a legal defense.
Practice Exercises
- Build a legal home lab: install VirtualBox (or VMware), add a Kali/Parrot attacker VM and an intentionally vulnerable target such as Metasploitable 2/3 or a VulnHub box, on a host-only network isolated from the internet.
- Perform passive OSINT on a domain you own, then run active recon (
nmap -sV -sC) againstscanme.nmap.orglightly, documenting every command and result. - Complete two beginner rooms on TryHackMe or the Starting Point track on Hack The Box, taking notes in the kill-chain phase structure.
- Write a full finding report for one vulnerability you discover in your lab, using the finding template above (title, CVSS vector, repro, impact, remediation).
- Practice CVSS 3.1 scoring: take three sample vulnerabilities, build vectors with the official calculator, and justify each metric choice.
- Register on a public bug bounty platform, pick one program, and read its scope and policy end to end — write a one-paragraph summary of what is and is not permitted before ever sending a request.