Preparing your learning space...
86% through Ethical Hacking tutorials
Rules of Engagement (RoE) are the detailed operational guidelines that govern how a security test will be conducted. While Scope (Tutorial 5) defines what is tested, RoE defines how, when, and under what conditions the testing happens.
RoE is a formal, signed document that both the tester and client agree to before any testing begins.
Think of RoE as the "ground rules" — they prevent misunderstandings, protect both parties, and ensure the test is safe, controlled, and effective.
| Aspect | Scope | Rules of Engagement |
|---|---|---|
| Answers | What is tested? | How is it tested? |
| Focus | Assets, IPs, domains, apps | Methods, timing, communication, stop conditions |
| Legality | Defines authorization boundary | Defines operational boundaries within that boundary |
| Example | "Test app.example.com" | "Testing only between 9 PM — 6 AM; report critical findings within 1 hour" |
| Reason | Explanation |
|---|---|
| Safety | Prevents accidental damage to production systems |
| Legal Protection | Demonstrates the tester had explicit permission for each specific action |
| Clarity | Both parties agree on procedures before testing — no surprises |
| Professionalism | Shows the engagement is run by professionals, not cowboys |
| Incident Prevention | Defines clear stop conditions and emergency procedures |
| Evidence | In case of a dispute, the RoE is the reference document |
When testing can happen — often the most operationally critical detail:
| Component | Example | Why It Matters |
|---|---|---|
| Start Date | July 20, 2026 | Cannot start before this date |
| End Date | July 24, 2026 | Must stop by this date (extensions require renegotiation) |
| Testing Window | 9:00 PM — 6:00 AM (off-peak) | Avoids impacting business operations |
| Weekend Testing | Friday 9 PM — Sunday 6 PM only | More aggressive testing when fewer users are active |
| Emergency Stop | Any time if business needs arise | Client can halt testing immediately for any reason |
| Time Zone | Eastern Time (ET) — client's business hours | Avoids time zone confusion |
Why time restrictions matter: An aggressive
masscanat 100,000 packets/sec during peak business hours can crash a production router. Testing in off-peak windows is a standard safeguard.
| Role | Responsibility | Example |
|---|---|---|
| Primary Contact | Day-to-day coordination, status updates, scope questions | tech.lead@examplecorp.com |
| Emergency Contact | Available 24/7 — called if something goes wrong | +1-555-0100 (Jane Doe, 24/7) |
| Authorizing Official | Signed the contract; can approve scope changes | cso@examplecorp.com |
| Legal Contact | Handles contractual, compliance, and liability issues | legal@examplecorp.com |
| Tester Lead | Lead security professional — makes technical decisions | John Smith, OSCP |
Contact Information Must Include:
☑ Port scanning (nmap, masscan) — up to 5,000 packets/sec
☑ Service enumeration
☑ Vulnerability scanning (Nessus, OpenVAS, Nikto)
☑ Web application testing (Burp Suite, OWASP ZAP)
☑ Credential testing — password spraying (max 5 attempts/account/day)
☑ Manual exploitation (non-destructive PoC only)
☑ SSL/TLS configuration review
☑ DNS enumeration
☑ Directory busting (gobuster, dirb)
☑ API testing (as documented)
🔶 Social engineering (phishing, pretexting)
🔶 Physical security testing (tailgating, lock picking)
🔶 SQL injection on INSERT/UPDATE/DELETE queries
🔶 Cross-Site Scripting (XSS) with stored payloads (affects other users)
🔶 Denial of Service (even limited, slow-rate)
🔶 Password cracking — offline (hashcat, John)
🔶 Password spraying beyond 5 attempts/account/day
🔶 Privilege escalation techniques that modify system files
🔶 Use of automated exploitation tools in "aggressive" mode
✗ Data exfiltration of real customer/PII/PHI data
✗ Modification or deletion of production data
✗ Installing malware, ransomware, or persistent backdoors
✗ Attacks on third-party systems (vendors, partners, cloud providers)
✗ Actions reasonably expected to cause service outage
✗ Testing outside the defined scope
✗ Social engineering targeting non-employees (family, customers)
✗ Physical damage to equipment
✗ Use of stolen or leaked credentials not obtained during the test
✗ Cryptocurrency mining or other resource abuse
How and when findings are communicated:
| Communication Type | Frequency | Method | Response Expected |
|---|---|---|---|
| Daily Status | Daily at 5 PM | Encrypted email | Acknowledgment within 4 hours |
| Critical Finding | Immediate (<1 hour) | Phone call + encrypted email | Immediate acknowledgment |
| High Finding | Within 4 hours of discovery | Encrypted email | Acknowledgment within 2 hours |
| Medium Finding | End of each testing day | Written summary | Next business day |
| Low Finding | In final report | Final report | During closeout meeting |
| Emergency | Immediate | Phone call to emergency contact | Immediate action |
⚠️ CRITICAL FINDING REPORT — IMMEDIATE ATTENTION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Report ID: CF-2026-001
Tester: John Smith
Client: ExampleCorp Inc.
Date/Time: 2026-07-20 14:30 ET
Finding ID: PT-2026-001
VULNERABILITY: SQL Injection — Unauthenticated
Systems: app.example.com:443 (production)
CVSS: 9.8 (Critical)
CVE: N/A (custom application)
IMPACT:
An unauthenticated attacker can extract all database
contents including customer PII and financial records.
EVIDENCE:
Username: admin' OR '1'='1' --
Response: 200 OK (authenticated as admin user)
ACTION TAKEN:
☑ Testing on this endpoint paused
☑ Evidence preserved
☑ No data exfiltrated
RECOMMENDED IMMEDIATE ACTION:
1. Disable the /login endpoint if possible
2. Contact development team for emergency patch
3. Implement WAF rule to block SQL injection patterns
TESTER STATUS:
☐ Continuing other in-scope testing
☑ Paused all testing pending client response
| Data Type | Handling Policy | Retention | Destruction Method |
|---|---|---|---|
| System data (OS, versions, configs) | Include in report with context | Destroy 90 days post-engagement | Secure delete / shred |
| Credentials discovered | Encrypt in report; change password; do NOT reuse | Report only — no local copy | Delete after report delivery |
| Customer/PII data | Do NOT view, copy, or exfiltrate | Not applicable | N/A — should never be collected |
| Screenshots | Redact any PII before including in report | Destroy with report after 90 days | Secure delete |
| Evidence files (PCAPs, log excerpts) | Encrypted at rest; password-protected archive | 30 days post-report | Cryptographic shred |
| Source code | View only as needed for vuln validation | Delete immediately after engagement | Secure delete |
| Work notes (tester's personal notes) | Encrypted; not shared | 30 days post-engagement | Secure delete |
1. SERVICE DEGRADATION OR OUTAGE
- Website is down or returning 5xx errors
- Application becomes unresponsive
- Network connectivity is lost (to the target)
2. SYSTEM CRASH OR UNEXPECTED REBOOT
- Server goes offline unexpectedly
- Service crashes and cannot restart
3. DATA LOSS OR CORRUPTION
- Data is deleted or modified unintentionally
- Database errors observed
4. DISCOVERY OF ILLEGAL CONTENT
- Child exploitation material
- Stolen data from another breach
- Evidence of criminal activity
5. CLIENT REQUESTS A STOP
- For any reason, at any time
- No explanation required
6. SCOPE VIOLATION
- Testing crosses into unauthorized systems
- Third-party infrastructure touched
[INCIDENT OCCURS]
│
▼
[IMMEDIATELY STOP TESTING]
• Close all sessions / reverse shells
• Stop all automated tools
• Do NOT delete anything yet
• Note the exact time (time-stamp for logs)
│
▼
[NOTIFY CLIENT EMERGENCY CONTACT]
• Call primary emergency contact
• If no answer in 5 min → call secondary contact
• Brief summary: What happened, what systems affected
• Do NOT speculate on cause yet
│
▼
[PRESERVE EVIDENCE]
• Save logs from the tester's machine
• Save screenshots of the incident
• Save any tool output related to the incident
• Do NOT alter the target system's state if possible
│
▼
[JOINT INVESTIGATION (CLIENT + TESTER)]
• Client investigates their logs (server, network)
• Tester provides their logs and timeline
• Determine together: Was the test the cause?
• If yes: Is the system recoverable?
│
▼
[ROOT CAUSE ANALYSIS]
• What exactly caused the incident?
• Was it the scanning rate? A specific exploit?
• Could it have been prevented?
• Document the RCA for both parties
│
▼
[RESUME TESTING (IF AGREED)]
• Adjust tools/methods based on RCA
• Implement safeguards for the specific risk
• Get written approval to resume from client
• Document the incident in the final report
A protocol for immediate, unambiguous cessation of testing:
| Term | Meaning | Who Can Say It |
|---|---|---|
| "RED" | Stop all testing immediately | Client or Tester |
| "YELLOW" | Pause the current activity; await instructions | Client only |
| "GREEN" | Resume testing (after RED or YELLOW) | Client only |
| "TIMEOUT" | Tester needs a clarification before proceeding | Tester only |
These safewords should be defined in the RoE document and agreed upon before testing begins.
Some findings require escalated handling:
| Finding Type | Immediate Action | Notification |
|---|---|---|
| PII/PHI Exposure | Stop testing; do NOT access/view the data | Report immediately to client + legal |
| Active Backdoor | System may already be compromised by a real attacker | Report immediately — this is an incident |
| Legal Violation | Evidence of crime (fraud, child exploitation, etc.) | Report to client legal; preserve evidence; may need law enforcement |
| Zero-Day Discovery | Vulnerability in third-party software (not client's code) | Coordinate disclosure with client and vendor (see Tutorial 4) |
| Credential Exposure | Passwords in source code, config files, or accessible storage | Report immediately; recommend credential rotation |
| RoE Element | Typical Setting |
|---|---|
| Schedule | After hours or agreed window |
| Duration | 1-5 days |
| Stealth Required | No |
| Social Engineering | No (unless separately agreed) |
| Physical Testing | No |
| Exploitation | Proof-of-concept only |
| Persistence | Simulated only (document how) |
| Data Exfiltration | Never |
| RoE Element | Typical Setting |
|---|---|
| Schedule | 24/7 — no restrictions |
| Duration | 2-6 weeks |
| Stealth Required | Yes — evade detection |
| Social Engineering | Yes (phishing, pretexting) |
| Physical Testing | Yes (tailgating, lock picking, badge cloning) |
| Exploitation | Full — establish foothold |
| Persistence | Yes — maintain long-term access |
| Data Exfiltration | Sometimes (simulated or with synthetic data) |
| RoE Element | Typical Setting |
|---|---|
| Schedule | Business hours + testing windows |
| Duration | 1-2 weeks |
| Stealth Required | No (Blue Team knows it's happening) |
| Social Engineering | Usually not |
| Exploitation | Yes — demonstrate attack chain |
| Data Exfiltration | Simulated only |
| Focus | Red Team attacks, Blue Team detects and responds |
| Collaboration | Real-time feedback between Red and Blue |
| RoE Element | Typical Setting |
|---|---|
| Schedule | 24/7 (self-paced) |
| Duration | Continuous (program-dependent) |
| Scope | Publicly defined on program page |
| Reporting | Via platform (HackerOne, Bugcrowd) |
| Exploitation | Minimal PoC — do NOT harm |
| Data Exfiltration | Never — this gets you banned |
| Payout | Per vulnerability, based on severity |
The RoE should reference the Non-Disclosure Agreement (NDA) or include confidentiality clauses:
| Clause | What It Covers |
|---|---|
| Confidential Information | All findings, data, reports, screenshots, notes |
| Permitted Use | Only for the purposes of the security test |
| Disclosure Restrictions | Cannot share findings publicly (see Responsible Disclosure) |
| Data Return or Destruction | All client data returned or destroyed within X days |
| Breach Notification | If tester's systems are breached, client must be notified |
| Publication Approval | Tester cannot publish about this engagement without client consent |
┌─────────────────────────────────────────────────────────┐
│ RULES OF ENGAGEMENT AGREEMENT │
│ [ENGAGEMENT NAME / ID] │
│ CONFIDENTIAL │
└─────────────────────────────────────────────────────────┘
1. ENGAGEMENT INFORMATION
Client: ExampleCorp Inc.
Tester: SecureTest Solutions
Type: Internal Network Penetration Test
Period: July 20, 2026 00:00 ET → July 24, 2026 23:59 ET
2. TESTING SCHEDULE
Mon-Fri: 6:00 PM — 6:00 AM ET (after hours)
Weekends: 24 hours (Saturday 00:00 ET → Sunday 23:59 ET)
Holidays: No testing on observed holidays
3. PERMITTED TECHNIQUES
- Port scanning (nmap, masscan) — max 5,000 pps
- Service enumeration
- Web application testing (Burp Suite, OWASP ZAP)
- Password spraying — max 5 attempts/account/day
- Manual exploitation — non-destructive PoC only
- Vulnerability scanning (Nessus)
4. RESTRICTED TECHNIQUES (Prior Approval Required)
- SQL injection on INSERT/UPDATE/DELETE
- Stored XSS with persistence
- Offline password cracking
- Physical security testing
5. PROHIBITED TECHNIQUES
- Denial of Service
- Data exfiltration of real data
- Social engineering
- Modifying or deleting production data
- Installing persistent backdoors
- Testing out-of-scope systems
6. COMMUNICATION
Daily Status: 5:00 PM ET, encrypted email
Critical: Phone call + email, within 1 hour
Emergency: Phone call, immediately
7. EMERGENCY CONTACTS
Client (Primary): Jane Doe, +1-555-0100, jane@examplecorp.com
Client (Backup): Bob Smith, +1-555-0101, bob@examplecorp.com
Tester (Lead): John Smith, +1-555-0200, john@securetest.com
Tester (Backup): Sarah Lee, +1-555-0201, sarah@securetest.com
8. STOP WORDS
"RED" → Stop all testing immediately
"YELLOW" → Pause current activity
"GREEN" → Resume testing
"TIMEOUT"→ Tester needs clarification
9. DATA HANDLING
- No PII data may be copied or exfiltrated
- All findings encrypted at rest (AES-256) and in transit (TLS)
- Evidence destroyed 90 days post-engagement
- Screenshots redacted of any PII
10. INCIDENT RESPONSE
- Stop → Notify → Preserve evidence → Investigate → Resume
11. REPORTING
- Final report due: August 1, 2026 (5 business days post-test)
- Format: PDF, encrypted, password-protected
AGREED AND ACCEPTED:
Client Signature: ____________________ Date: ________
Print Name: __________________________ Title: _______________
Tester Signature: ____________________ Date: ________
Print Name: __________________________ Title: _______________
| Mistake | Consequence | Solution |
|---|---|---|
| Vague testing windows | "Test during off hours" — but what are "off hours" for a 24/7 operation? | Specify exact times with timezone: "Mon-Fri 9PM-6AM ET" |
| No emergency contact | Something crashes and nobody can be reached | Provide 24/7 contact with phone number |
| Unclear prohibited actions | Tester does something the client considers out of bounds | List explicit "Restricted" and "Prohibited" techniques |
| No data handling rules | Tester stores customer PII on a personal laptop | Define data policies: encryption, retention, destruction |
| No stop criteria | Testing continues even as systems crash | Define specific "stopping conditions" |
| Testing window too short | 8 hours to test a complex environment | Realistically estimate: 2-5 days per application |
| Single point of contact | Contact is unavailable during critical moment | Always provide primary + backup contacts |
| No scope boundary | RoE refers to the scope document but doesn't summarize it | Include a scope summary in the RoE itself |
The RoE document is legally binding:
| Legal Function | Explanation |
|---|---|
| Part of the contract | The RoE is incorporated by reference into the master services agreement |
| Evidence of authorization | If the tester's actions are questioned (by law enforcement, regulators, or the client), the RoE proves authorization |
| Proof of agreed methodology | "You said you'd test SQL injection but not DoS" — the RoE shows what was agreed |
| Protection for both parties | Defines responsibilities clearly; protects client (clear boundaries) and tester (clear authorization) |
| Insurance requirement | Professional liability insurance policies require documented RoE for claims |
Never start testing without a signed RoE document. Even if you have a contract and scope document, missing RoE creates ambiguity about how testing is supposed to happen. In the event of an incident, an unsigned RoE is as good as no RoE.
| Region | Key Consideration | How RoE Should Address It |
|---|---|---|
| EU / EEA | GDPR — personal data protection | Explicitly prohibit viewing/storing personal data; limit data flows |
| Germany | Strict privacy laws, §202a StGB | Ensure testing is explicitly authorized; avoid any interception of communications |
| UK | Computer Misuse Act 1990 | RoE must provide explicit defense of "authorized access" |
| Switzerland | Banking secrecy laws | Extra caution around financial data; separate agreements may be needed |
| Middle East | Varies — some countries criminalize "hacking tools" | Tester may need to justify tool possession to customs/authorities |
| Cross-Border | Data sovereignty — data may not leave the country | RoE should specify where data is processed and stored |
A penetration tester discovered an SQL injection vulnerability in a production database. The exploit could have dumped the entire customer database. However, the RoE clearly stated: "Report SQL injection immediately — do not attempt exploitation on production databases."
The tester immediately reported the finding (under "Critical Finding — Report within 1 hour"). The database was patched within 4 hours. Because the RoE was clear, the tester knew exactly what to do and the client knew exactly what to expect.
Result: No data compromised, client impressed, tester paid.
A tester was contracted to test a web application. The RoE was vague: "Test during appropriate times." The tester ran
masscanat default speed (100,000 packets/sec) against the production server during peak business hours (10 AM Tuesday).The legacy server's network stack crashed under the scan rate, causing a 4-hour outage for 50,000+ users. The e-commerce platform was down — estimated loss: $2.4 million in revenue.
Result: Tester's contract terminated immediately. Engineering firm sued for damages ($2.4M). Tester's professional liability insurance denied the claim because the RoE didn't specify scanning rates or testing windows.
Lesson: A vague RoE doesn't protect anyone. Specify scanning rates, testing windows, and stop conditions in detail.
Save your progress and earn XP for completing tutorials.
Technology
Cyber Security & Networking
Lesson group
Ethical Hacking
Progress
86% complete