Authorization and Scope

Learning Objectives

• After this, students can explain why written authorization is what separates a security professional from an attacker, even for “just research.”
• After this, students can list the documents that define an engagement (contract, scope, rules of engagement, authorization letter) and what each one does.
• After this, students can write a basic OSINT scope that covers targets, people, techniques, sources, and data handling.
• After this, students can recognize gray-area findings and know when to stop and ask the client.
• After this, students can describe the legal, contractual, and professional consequences of going out of scope.

Why Authorization Comes First

From the outside, an attacker doing reconnaissance and a penetration tester doing reconnaissance look identical. They run the same searches, read the same LinkedIn profiles, and pull the same DNS records. The difference is authorization: the tester has a signed agreement from someone who has the right to approve the work, and the attacker does not.

OSINT can feel like it doesn’t need permission because much of it is passive. Reading a public web page isn’t hacking. But authorization still matters for three reasons:

1. OSINT rarely stays passive. Recon findings usually feed into something active: a phishing simulation, a pretext phone call, a password spray against a login page, a port scan. Those steps absolutely require permission, and the scope decided up front controls what you’re allowed to do with what you find.
2. Collection itself has limits. Even purely passive work touches personal data about real people. Privacy law (covered in 2.2-computer-crime-and-privacy-laws.md) and basic ethics (covered in 2.4-ethics-and-harm.md) say you should collect only what a legitimate purpose requires. The scope is that purpose, written down.
3. It protects you. If something goes wrong (a target notices you, a finding turns out to be sensitive, or someone questions why you had certain data), the written scope is your proof that you were doing authorized work.

Who can actually authorize the work?

Authorization only counts if it comes from someone with authority over the thing being tested. This trips people up in several ways:

• Third-party systems. A client can authorize testing of systems it owns. It generally cannot authorize you to test its cloud provider, its SaaS vendors, its web host, or its ISP. Those companies have their own rules (many publish penetration testing policies) and their own consent is needed.
• Employees’ personal lives. A company can authorize research into its own organization. It cannot consent on behalf of employees for their personal social media accounts, their homes, or their families. Whether you look at those at all is a scope decision, and the answer is usually “only what’s needed, and only what’s public.”
• Split ownership. Subsidiaries, franchises, shared buildings, and government bodies can have confusing ownership. Confirm who owns what before you start.

Case to discuss: In 2019, two penetration testers from the firm Coalfire were arrested during a contracted physical security test of the Dallas County Courthouse in Iowa. The state court administration had hired them, but county officials disputed that the state had authority to approve testing of the county-owned building. The charges were eventually dropped, but the testers spent a night in jail and the case became a well-known lesson about confirming that the person signing your authorization actually has the authority to grant it. (verify details before class)

The Documents That Define an Engagement

Professional engagements usually involve several documents. Names vary between companies, but the functions are consistent.

The Penetration Testing Execution Standard (PTES) treats this as the “Pre-engagement Interactions” phase. Its topics include the scoping meeting, questionnaires, scope creep, specifying start and end dates, specifying IP ranges and domains, dealing with third parties, defining acceptable social engineering pretexts, emergency contact information, and rules of engagement. Even though PTES was written for penetration testing broadly, every one of those topics applies to OSINT work.

What an OSINT Scope Should Specify

A network penetration test scope can be as simple as a list of IP ranges. OSINT scopes need more detail because the “targets” include people. A good OSINT scope answers these questions:

1. Objective
- What question is the client trying to answer? (“What could an attacker learn about us before phishing our finance team?”)
- The objective limits everything else: if a piece of information doesn’t help answer it, you probably don’t need it.

2. Organizations and assets
- Legal entities, subsidiaries, and recent acquisitions
- Domains, brands, product names, and known IP ranges
- Physical locations, if relevant

3. People
- All employees, specific departments, or specific roles (e.g., executives, IT staff, finance)
- Whether former employees and contractors are included
- Whether executives’ public personal presence (e.g., a personal X account where they discuss work) is included

4. Personal accounts, family, and homes
- Are employees’ personal social media accounts in scope at all? If so, only public content? Only content related to the company?
- Family members and minors should almost always be explicitly out of scope.
- Home addresses are usually out of scope unless there is a specific, justified objective (e.g., executive protection work) and the client has thought through the privacy implications.

5. Techniques
- Passive only?
- Semi-passive (normal browsing of the client’s public sites) allowed?
- Active techniques (scanning, directory brute forcing) allowed, and against which assets?
- Social engineering (pretext calls, phishing, direct messages) allowed? With what pretexts?
- Sock puppet accounts allowed? (See 2.3-terms-of-service.md for the platform-rules problem.)
- Any interaction with real people allowed?

6. Sources
- Breach and leak data: may you check it, search it, or retrieve it? (See 2.4-ethics-and-harm.md.)
- Dark web intelligence platforms (see Module 6): allowed, and which ones?
- Paid data brokers and people-search sites: allowed?

7. Data handling
- Where findings are stored and how they’re encrypted
- How long data is kept and when it’s deleted
- What goes in the report (e.g., “confirm that a password was exposed, never include the password itself”)
- Who receives the report

8. Communication and escalation
- Primary point of contact and emergency contact
- What to do if you find evidence of an active breach, a crime, or a threat to someone’s safety

9. Time window
- Start and end dates; data collected outside the window may be out of scope

Example scope excerpt (fictional)

ENGAGEMENT: External OSINT Assessment — CompanyX, Inc.
OBJECTIVE: Identify information an external attacker could use to
           target CompanyX employees with phishing or pretext calls.

IN SCOPE
  Organizations: CompanyX, Inc. and CompanyX Labs LLC
  Domains:       companyx.com, companyxlabs.com (and subdomains)
  People:        Current employees, as listed on public professional
                 profiles and company-owned sites
  Techniques:    Passive collection only. Normal browsing of
                 companyx.com permitted.
  Sources:       Public web, search engines, public professional
                 profiles, certificate transparency, DNS, public
                 code repositories, breach-notification services
                 (existence of exposure only)

OUT OF SCOPE
  - Employees' family members, and any person under 18
  - Home addresses and personal phone numbers
  - Employees' personal social media, except public posts that
    reference CompanyX
  - Any interaction with employees (messages, connection requests,
    calls, emails)
  - Sock puppet accounts
  - Retrieving or storing leaked passwords or breach files
  - Third-party vendor systems

DATA HANDLING
  Findings stored in the encrypted engagement share only.
  All collected data deleted 30 days after report delivery.
  Report must not contain plaintext credentials.

ESCALATION
  Stop and contact J. Doe (Security Lead) within 24 hours if you
  find evidence of an active compromise, illegal content, or a
  threat to anyone's safety.

Gray Areas: Practicing Scope Decisions

Real findings rarely line up neatly with the scope document. The table below shows common gray areas and how to reason about them using the example scope above.

A useful habit: whenever you find yourself thinking “I could also look at…”, check the scope before you do.

When to Stop and Ask

Stop collecting, document what you have, and contact your point of contact when:

• You find evidence of an active compromise (e.g., the client’s credentials being sold, an internal document on a leak site).
• You encounter illegal content of any kind. Do not download, screenshot, or share it; see Module 6 for dark web safety.
• You find information suggesting someone is in danger (threats, self-harm, stalking).
• A finding involves sensitive categories (health, sexual orientation, religion, political views) or minors.
• The next step would require interacting with a person or touching a system you haven’t been cleared to touch.
• Ownership is unclear (vendors, subsidiaries, shared infrastructure).
• You catch yourself asking “Should I?” If you have to ask, ask the client.

When you escalate, write down what you found, where, when, and how you found it, and don’t keep digging while you wait. Get the answer in writing (an email is fine).

What Happens When You Go Out of Scope

Going out of scope is not a paperwork problem. It can lead to:

• Criminal exposure. Authorization is often the element that separates lawful testing from a computer crime (see 2.2-computer-crime-and-privacy-laws.md). Work outside your authorization may not be protected.
• Civil liability. The target of out-of-scope work (a vendor, an employee, a family member) can sue. Your contract may also make you or your employer liable for damages.
• Breach of contract. The client can terminate the engagement, refuse payment, or pursue damages.
• Insurance problems. Professional liability insurance may not cover work outside the agreed scope.
• Career damage. Firms fire testers for scope violations, and professional certification bodies have codes of ethics that can lead to losing a certification.
• Harm to people. Out-of-scope collection about employees or their families can lead to real-world harm if the data leaks or is misused.
• Unusable results. Evidence gathered outside scope may be excluded from a legal case or disregarded by the client.

Real cases: when authorization is missing

Connor Moucka (Snowflake customer breaches, 2024–2026)
- What happened:
- Moucka, a 26-year-old from Kitchener, Ontario, admitted taking part in a 2024 campaign that used stolen login credentials to access data held by at least 165 customers of a US cloud software provider (the Snowflake breaches covered in Module 6).
- Prosecutors say the stolen data was tied to at least 100 million people and included call and text records, financial and payroll data, and identity documents.
- The group demanded ransoms, receiving more than $2.5 million (at least $495,000 went to Moucka). It also advertised stolen data on cybercrime forums and Telegram.
- How it ended:
- The FBI worked with the Royal Canadian Mounted Police and authorities in four other countries.
- Moucka was extradited to the US in July 2025.
- On August 5, 2026, he pleaded guilty to four counts: computer fraud, wire fraud, aggravated identity theft, and conspiracy. The aggravated identity theft count carries a mandatory minimum of two years.
- Sentencing was scheduled for October 27, 2026 (check for updates before class).
- Lesson: a password that works is not permission. Logging in with someone else’s credentials is unauthorized access, however easy the target made it (the affected accounts didn’t require MFA).

Marcus Hutchins, “MalwareTech” (2017–2019)
- What happened:
- In May 2017, Hutchins, a UK security researcher, became famous for helping stop the WannaCry ransomware outbreak.
- That August, days after attending DEF CON, he was arrested at the Las Vegas airport. He was accused of helping develop Kronos, a banking trojan first seen on Russian cybercrime forums in 2014. The indictment included a Computer Fraud and Abuse Act conspiracy count.
- OSINT angle:
- After his arrest, observers dug up old IRC chat logs tied to a username he had used as a teenager.
- Earlier, after WannaCry, tabloids had published his name and address alongside his “MalwareTech” handle.
- How it ended:
- In April 2019 he pleaded guilty to two charges related to the malware.
- In July 2019 he was sentenced to time served plus one year of supervised release. The judge noted he had turned his skills to legitimate work well before the case.
- Lesson: good work today doesn’t erase unauthorized work in the past, and your old usernames are part of your OSINT footprint (Module 8 and Module 9).

Discussion: Both men were highly skilled. What single thing would have put their work on the right side of the law?

Scope creep is the slow version of this problem: small “while I’m here” additions that each seem harmless. PTES lists scope creep as a pre-engagement topic because it happens so often. The fix is the same every time: pause, ask, and get the expansion approved in writing.

OSINT Outside of Formal Engagements

Not all OSINT happens under a pentest contract. Authorization still matters in other settings:

• Bug bounty and vulnerability disclosure programs. The program’s published policy is your authorization. Read it carefully: many prohibit social engineering, testing third-party services, or accessing other users’ data.
• Threat intelligence at work. Your employer’s policies and legal team define what you can collect and which sources (like dark web platforms) you can use.
• Academic research. University research involving people may need review by an Institutional Review Board (IRB) before you start.
• Journalism and human rights work. Professional frameworks like the Berkeley Protocol (see 2.4-ethics-and-harm.md) set expectations for lawful, ethical collection.
• This class. Only investigate yourself, classmates who consent, or instructor-provided targets. Treat the class rules as your scope document.

Key Terms

• Authorization: Permission from someone with the authority to approve work against specific systems, organizations, or data.
• Scope: The written definition of what is being assessed: organizations, assets, people, and time window.
• Rules of Engagement (RoE): The written definition of how the work may be done: allowed techniques, sources, and limits.
• Authorization letter: A signed letter confirming a tester’s permission to perform specific work, carried as proof during the engagement.
• Statement of Work (SOW): The contract document describing deliverables, timeline, and cost.
• Scope creep: Gradual, unapproved expansion of an engagement beyond its agreed scope.
• Third party: Any organization other than the client (vendors, cloud providers, ISPs) whose systems may be involved but who hasn’t consented.
• PTES: The Penetration Testing Execution Standard, a framework describing phases of a penetration test, starting with pre-engagement interactions.

Key Takeaways

• Authorization is the difference between a tester and an attacker, and it must come from someone who actually has the authority to give it.
• A client can’t authorize testing of its vendors, or consent on behalf of its employees’ personal lives.
• An OSINT scope needs more than domains: it must cover people, personal accounts, techniques, sources, and data handling.
• Family members and minors should be explicitly out of scope.
• If the next step requires interacting with a person or touching a new system, stop and check the scope.
• When in doubt: pause, document, ask, and get the answer in writing.
• Going out of scope can mean criminal exposure, lawsuits, lost contracts, and lost careers.

References

• A 26-year-old Canadian hacker breached 165 companies and exposed data linked to 100 million people, but an investigation eventually led to his guilty plea — Times of India (Sept 15, 2026)
• Black hat or white hat? Questions swirl around hero researcher’s sudden arrest — The Verge (Aug 5, 2017)
• Marcus Hutchins — Wikipedia
• Penetration Testing Execution Standard — documentation tree (Pre-engagement Interactions)
• What is the Penetration Testing Execution Standard? — RSI Security
• Penetration Testing Execution Standard (PTES): Complete Guide — SecureLayer7
• Justice Department CFAA charging policy (2022) — Greenberg Traurig summary
• Coalfire / Dallas County courthouse arrests (2019): details from general knowledge, not re-checked this session (verify before class)