After this lesson, you will be able to: Internalise the laws, contracts, and norms that distinguish legitimate penetration testing from computer crime, before learning any technique.
This lesson is mandatory and intentionally comes first. Penetration testing techniques are illegal when used against systems you don't own or have explicit written permission to test. You must understand the legal frame before learning a single tool, because the same Nmap scan is research on TryHackMe and a federal crime against a stranger's network.
Every technique you will learn in this sub-track, port scanning, password spraying, exploitation, post-exploitation, is illegal in most jurisdictions when used without authorization. The Computer Fraud and Abuse Act (CFAA) in the United States, the Computer Misuse Act in the UK, and equivalent laws elsewhere criminalise unauthorized access regardless of intent. Many of the news stories you've read about 'hackers being arrested' involved technically curious people who didn't get explicit permission first. The risk is real.
The CFAA (18 U.S.C. § 1030) makes it a federal crime to access a computer 'without authorization' or 'in excess of authorization'. Penalties range from misdemeanour to 10+ years in federal prison depending on the system, the data, and any financial damage. Crucially: 'I didn't mean any harm' is not a defence. Curiosity, learning, or even a security improvement motive does NOT excuse unauthorized access. Outside the US the laws are different but the principle is identical: written authorization is the line.
A written authorization (often called Rules of Engagement, ROE) signed by someone with authority to grant it. An explicit scope: what assets are in-scope (IPs, domains, applications), what tests are allowed (no DoS, no social engineering of employees outside scope), what hours testing can occur. A point of contact at the target organisation, plus an out-of-band channel to reach them if you trip an alert and they think it's a real attack. A retention and destruction agreement for any data you find during testing. Bug bounty programs are a special form of pre-authorization: the program scope IS the written authorization, but only for the in-scope assets.
If you find a vulnerability outside any authorisation (in software you use, a website you visit, anywhere), you have two safe options: Use the vendor's responsible disclosure process if they have one. Report through a coordination body (CERT/CC, your country's equivalent, or a public bug bounty platform like HackerOne if the vendor has a program). Never publish a 0-day with working exploit code before the vendor has had time to patch. The industry standard is 90 days, but most modern coordinated disclosure agreements run 30-180 days depending on severity and complexity.
Before any other lesson in this sub-track, make sure you're set up to practise legally.
Sign up for HackTheBox, TryHackMe, PicoCTF, and PortSwigger Academy (free tiers are enough)
Download Kali Linux as a VM (cs-intro-01 step) and snapshot a clean install
Set up Metasploitable 2, DVWA, or OWASP Juice Shop in Docker or VirtualBox on a host-only network
Write a personal rules sheet: 'I will test only on HTB, TryHackMe, PicoCTF, my own VMs, or programs with explicit written authorization.' Sign and date it; revisit before every session.
If you ever feel tempted to test something outside this list, treat it as a hard stop and ask a tutor or community before proceeding
Scanning your roommate's laptop on the same Wi-Fi 'just to learn'. They might own the device but if you don't have permission, this is unauthorized access. Assuming Bug Bounty scope covers a company's parent or sister organisations. It usually doesn't; treat each company's scope as a strict allowlist. Testing a vulnerable service you found 'in the wild' without checking if it's a deliberate honeypot. Some honeypots are run by law enforcement. Documenting everything in a personal repo, including credentials you found during a real engagement. Engagement data has retention rules; follow them. Forgetting that out-of-band proof-of-impact (uploading a file, modifying data) often exceeds your authorisation even if the initial access didn't.
Pick the one that doesn't risk a federal charge.
Sign in and purchase access to unlock this lesson.