Every offensive technique in this course is for use against systems you own or have explicit written authorization to test. Unauthorized access to a computer system is a crime in virtually every country — including under the US CFAA, the UK Computer Misuse Act, and India's IT Act §43/§66 — regardless of whether any damage occurs. When in doubt, do not touch it. Get permission first, in writing.
Authorization and scope
Authorization is the single most important concept in this entire course. Before any testing begins, the system owner must grant explicit, documented permission. That permission is bounded by scope: exactly which IP ranges, domains, applications, and accounts you may test — and, just as importantly, what is out of scope. Touching anything outside the agreed scope, even by accident, can be both a contractual breach and a criminal act. Scope is not bureaucracy; it is the fence that keeps your work legal.
Rules of engagement and the authorization letter
The rules of engagement (RoE) turn the scope into operational rules: when you may test (hours, blackout windows), which techniques are permitted (is denial-of-service allowed? social engineering? physical access?), how to handle sensitive data you encounter, and who to call if something breaks or if you find an active intrusion. Alongside the RoE, a professional carries an authorization letter — informally the "get-out-of-jail-free" letter — a signed document from someone with authority to approve the test, naming the testers, the scope, and the dates. If a security guard or sysadmin challenges you, that letter is your proof you are authorized to be doing what you're doing.
Responsible and coordinated disclosure
What happens when you find a serious flaw? Responsible disclosure means you report the vulnerability privately to the owner and give them reasonable time to fix it before any public details are released. Coordinated disclosure extends this to multiple parties (vendors, CERTs, downstream users) agreeing on a timeline. The goal is to get the bug fixed while minimizing the window in which attackers could weaponize it. Dumping an unfixed exploit publicly ("full disclosure" without warning) endangers users and can expose you to legal liability. Mature programs publish a disclosure policy and often a security.txt file telling researchers exactly how to report.
The laws that bind you
- US CFAA (Computer Fraud and Abuse Act) — criminalizes accessing a computer "without authorization or exceeding authorized access." Broad and aggressively enforced.
- UK Computer Misuse Act 1990 — outlaws unauthorized access, unauthorized acts impairing operation, and making/supplying hacking tools for crime.
- EU GDPR — not a hacking law per se, but governs personal data; mishandling data you encounter during a test carries heavy penalties.
- India IT Act §43/§66 — §43 imposes civil liability for unauthorized access and damage; §66 makes dishonest or fraudulent acts a criminal offence.
Why authorization is everything
Marcus Hutchins became a hero in 2017 when he registered a domain that acted as a "kill switch," halting the global WannaCry ransomware outbreak. Yet not long after, he was arrested in the US over malware (the Kronos banking trojan) he had been involved with years earlier. His story is a stark reminder that doing good later does not erase unlawful acts earlier — and that the same person can sit on both sides of the line over a career.
The weev / AT&T case sharpened a different point. Andrew Auernheimer and a collaborator collected around 114,000 iPad customer email addresses from a publicly reachable AT&T web endpoint that required no password. He was convicted under the CFAA (the conviction was later vacated on a venue technicality, not on the merits of "was it authorized"). The lesson the industry took away: data being technically reachable is not the same as being authorized. If you weren't given permission, accessing it can be a crime — even when there's no lock to pick.
Practise reading an RoE the way a careful tester does — hunting for what is not allowed.
- Read this excerpt from a sample engagement and identify the boundaries:
Scope (in): 10.10.50.0/24, app.example-corp.test Scope (out): 10.10.99.0/24, prod payment systems, third parties Window: Mon-Fri 09:00-17:00, no weekends Prohibited: DoS/DDoS, social engineering of staff, data exfil Contact: [email protected] for any service disruption - Flag what is out of scope: which subnet must you never touch? Which systems are off-limits even if reachable?
- Spot the trap: a host at
10.10.99.14responds to your ping during a sweep. What do you do?$ ping -c1 10.10.99.14 64 bytes from 10.10.99.14: icmp_seq=1 ttl=64 time=0.4 ms # STOP — 10.10.99.0/24 is out of scope. Do not probe it. Note it and move on. - Write the one sentence you would email the contact if you discovered an active, real intrusion mid-test.
- No test begins without explicit, written authorization bounded by a clear scope.
- Rules of engagement set the operational limits; the authorization letter is your proof of permission.
- Responsible/coordinated disclosure reports flaws privately and gives time to fix before going public.
- CFAA, the UK Computer Misuse Act, GDPR, and India's IT Act all criminalize unauthorized access — reachable is not the same as authorized.