Exploitation Ethics and Scoping

Why Authorization Is Non-Negotiable

Exploiting vulnerabilities without explicit written authorization is a crime in virtually every jurisdiction. The Computer Fraud and Abuse Act (CFAA) in the United States, the Computer Misuse Act in the UK, and similar laws worldwide criminalize unauthorized access to computer systems — regardless of intent. "I was just testing" or "I found this by accident" are not legal defenses.

What Constitutes Authorization

Authorization must be:

1. Written — Verbal agreements are insufficient. Get a signed document.
2. Specific — Define exactly which systems, networks, and applications are in scope.
3. Time-bound — Specify the testing window (start and end dates).
4. Signed by the right person — Someone with authority over the target systems (CISO, CTO, or system owner).

Types of Authorization Documents

Statement of Work (SOW) — Defines the engagement scope, deliverables, and timeline. The SOW is the contract; the rules of engagement are an appendix.

Rules of Engagement (ROE) — The operational document that defines:

• Target systems and IP ranges
• Testing windows (business hours, off-hours, specific dates)
• Prohibited actions (denial of service, social engineering, physical access)
• Data handling requirements
• Escalation contacts and procedures

Permission to Test — A simpler document for shorter engagements. Still must be written and signed.

Scope Definition

Scope defines what you are allowed to test. It must be explicit:

In Scope:
- 192.168.1.0/24 (production network)
- target.example.com (web application)
- api.target.example.com (REST API)
- VPN gateway at vpn.target.example.com

Out of Scope:
- www.target.example.com (production website — no active testing)
- Third-party services (CDN, email provider)
- Physical security (lock picking, badge cloning)
- Social engineering (phishing, vishing, pretexting)
- Denial of service attacks

Timing Windows

Define when testing can occur:

Testing Window:
- Active testing: Monday-Friday, 18:00-06:00 (off-hours)
- Passive testing: Anytime
- Emergency contact: security-team@example.com

Blackout Periods:
- Month-end closing (1st-3rd of each month)
- Product launches (see calendar)

Consequences of Scope Violation

Testing outside agreed scope can result in:

• Criminal charges — Even with good intent, unauthorized access is illegal
• Civil liability — Damages from disrupted services
• Professional consequences — Loss of certifications, employment, and reputation
• Voided contracts — The authorization document becomes invalid if you violate its terms

The Hacker Ethic

Ethical hacking operates on a simple principle: you are trusted to access systems and data that would otherwise be off-limits. That trust comes with responsibility. The core ethical obligations are:

1. Do no harm — Your testing should not disrupt business operations or damage data
2. Protect confidentiality — Any data you access during testing must be handled securely
3. Act in the client's interest — Your goal is to improve their security, not to show off
4. Stay within bounds — The scope exists for a reason; respect it

Ethical Dilemmas in Practice

Scenario 1: You discover a critical vulnerability outside scope

You are testing the web application and discover that the VPN gateway (out of scope) has a known RCE vulnerability. What do you do?

• Correct action: Document the finding, inform the client immediately, and request expanded scope. Do not exploit it.
• Wrong action: Exploit it "to prove it is real" or because "the client needs to know."

Scenario 2: You accidentally access sensitive data

During testing, you discover a database containing customer PII. What do you do?

• Correct action: Stop accessing the data, document what you saw, inform the client, and follow data handling procedures.
• Wrong action: Download the data "for analysis" or share it with others.

Scenario 3: Your testing causes a service outage

An exploit you ran crashes a production server. What do you do?

• Correct action: Immediately stop testing, inform the client's emergency contact, document what happened, and assist with recovery.
• Wrong action: Continue testing or hope the client does not notice.

Data Handling During Testing

You will inevitably access sensitive data during penetration testing:

• Credentials — Usernames and passwords you discover or crack
• Personal data — Customer information, employee records
• Financial data — Payment information, transaction records
• Intellectual property — Source code, trade secrets, business plans

Data handling rules:

1. Minimize access — Only access data necessary to demonstrate the vulnerability
2. Encrypt storage — Any data you store must be encrypted at rest
3. Secure deletion — Delete all data when the engagement ends
4. No retention — Do not keep data after the engagement
5. No sharing — Never share client data with third parties

Responsible Disclosure

When you discover a vulnerability in a third-party component (e.g., a library the client uses):

1. Report to the client — They need to know their systems are affected
2. Report to the vendor — If the vulnerability is in a third-party product, report it to the vendor
3. Coordinate disclosure — Work with the client and vendor on disclosure timing
4. Do not exploit — Never exploit third-party vulnerabilities without explicit authorization from both the client and the vendor

When You Find a Critical Vulnerability

During testing, you discover a vulnerability that allows unauthenticated remote code execution on a production server. This is a critical finding that requires immediate action.

Immediate Actions

1. Stop further exploitation — Do not proceed with exploitation beyond what is necessary to confirm the vulnerability
2. Document the finding — Record the vulnerability, affected systems, and potential impact
3. Contact the client immediately — Use the emergency contact defined in the ROE
4. Provide remediation guidance — The client needs to know how to fix it, not just that it exists

Escalation Contacts

The ROE must define escalation contacts:

Primary Contact:
Name: Jane Smith
Role: CISO
Email: jane.smith@example.com
Phone: +1-555-0100

Secondary Contact:
Name: John Doe
Role: Security Manager
Email: john.doe@example.com
Phone: +1-555-0101

Emergency Contact (24/7):
Email: security-emergency@example.com
Phone: +1-555-0911

Reporting Critical Findings

When reporting a critical finding, include:

• Vulnerability description — What is the flaw and how does it work?
• Affected systems — Which servers, applications, or data are at risk?
• Business impact — What could an attacker achieve?
• Proof of concept — Minimal demonstration that the vulnerability is real
• Remediation steps — How to fix the vulnerability
• Timeline — When was it discovered and when should it be fixed?

During the Engagement

Ethical obligations during active testing:

• Monitor your impact — If your testing causes unexpected behavior, stop and assess
• Communicate proactively — If you find something serious, do not wait for the final report
• Respect business hours — Avoid testing during critical business periods
• Document everything — Your notes become the foundation of the final report

After the Engagement

Post-engagement ethical obligations:

1. Deliver the report — Comprehensive findings with remediation guidance
2. Delete all data — Remove all client data from your systems
3. Return all materials — Any documents, credentials, or access tokens provided by the client
4. Debrief — Walk the client through findings and answer questions
5. Support remediation — Be available to verify fixes and re-test

Professional Certifications and Ethics

Certifications like OSCP, CEH, and GPEN require adherence to ethical codes:

• Offensive Security Code of Conduct — Prohibits unauthorized testing and data theft
• EC-Council Code of Ethics — Requires protecting client confidentiality
• GIAC Code of Ethics — Mandates responsible disclosure and professional conduct

Violating these codes can result in certification revocation and professional blacklisting.