Legal Case Studies
Learn from real-world legal situations in penetration testing. These anonymized and public cases highlight the importance of proper authorization, clear scope definition, and professional conduct.
Learning from History
Case 1: The Iowa Courthouse Incident (2019)
What Happened
Two penetration testers from Coalfire were hired by the Iowa Judicial Branch to test physical and cyber security at courthouses. During an after-hours physical security test, they successfully bypassed locks and entered a courthouse. Despite having authorization from the state judicial system, they were arrested by local sheriff's deputies and charged with burglary.
The Problem
- ✗ The authorization came from the state judicial branch, but the county sheriff's office wasn't informed
- ✗ Local law enforcement had separate jurisdiction over the physical building
- ✗ No "get out of jail free" letter was carried during the physical test
- ✗ Scope didn't clearly define stakeholder notification requirements
Lessons Learned
- ✓ Identify ALL stakeholders - Physical locations may have multiple authorities (owners, tenants, law enforcement)
- ✓ Carry authorization on-person - Always have a "get out of jail" letter with 24/7 emergency contacts
- ✓ Notify law enforcement - For physical tests, consider notifying local police in advance
- ✓ Clarify jurisdiction - Government entities often have overlapping authorities
Case 2: The Scope Creep Disaster
What Happened
A penetration tester was hired to test a company's external web application. During testing, they discovered a vulnerability that allowed access to an internal database server. Excited about the finding, they pivoted to the internal network and discovered additional critical vulnerabilities. The client's IT team detected the internal activity and accused the tester of unauthorized access.
The Problem
- ✗ The RoE specified "external web application only" - internal systems were out of scope
- ✗ Tester didn't stop to request scope expansion when they found the pivot point
- ✗ Internal IT security team wasn't informed of the test
- ✗ No clear guidance in the contract about what to do when finding pivot opportunities
Lessons Learned
- ✓ Never exceed scope - If you find a way to access out-of-scope systems, STOP and notify the client
- ✓ Document pivot opportunities - Note the finding in your report without exploiting it
- ✓ Include scope expansion procedures - RoE should specify how to request additional scope
- ✓ Get scope changes in writing - Verbal approval isn't enough
Case 3: The Accidental DDoS
What Happened
A tester was running an automated vulnerability scanner against a production e-commerce site during business hours. The scanner was configured with aggressive thread settings, and the client's infrastructure couldn't handle the load. The website went down for 4 hours during a major sales event, causing significant revenue loss.
The Problem
- ✗ Testing was conducted during peak business hours on production systems
- ✗ Scanner settings were too aggressive for the infrastructure
- ✗ No discussion of testing impact or rate limiting
- ✗ Tester didn't coordinate with IT team or check system load
Lessons Learned
- ✓ Test during off-peak hours - Coordinate timing with business operations
- ✓ Start with low intensity - Begin scanning with conservative settings and increase gradually
- ✓ Use staging environments - Request access to non-production systems when possible
- ✓ Have professional liability insurance - It saved the tester in this case
- ✓ Include downtime procedures in RoE - Who to call, how to stop, liability limits
Case 4: The AWS Assumption
What Happened
A tester was hired to assess a client's web application hosted on AWS. They assumed that since the client owned the application, they could test freely. The tester ran aggressive scans including port scans across the IP range. AWS detected the activity, flagged it as malicious, and suspended the client's AWS account.
The Problem
- ✗ Client authorization doesn't extend to cloud provider infrastructure
- ✗ AWS penetration testing policy wasn't reviewed or followed
- ✗ Scanning included AWS-owned IP ranges and infrastructure
- ✗ No AWS notification was submitted before testing
Lessons Learned
- ✓ Review cloud provider policies - AWS, Azure, and GCP have specific penetration testing rules
- ✓ Submit required notifications - Some providers require advance notice (though AWS no longer requires pre-approval for many tests)
- ✓ Limit scope to customer resources - Don't scan shared infrastructure or other tenants
- ✓ Document cloud infrastructure - Know what's hosted where before testing
Case 5: The Good Samaritan
What Happened
A security researcher found an SQL injection vulnerability on a local business's website while casually browsing. With good intentions, they decided to "verify" the vulnerability by extracting a few records to prove it was exploitable. They then emailed the business owner explaining the vulnerability and offering to help fix it for free. The business owner called the police, and the researcher was charged under computer fraud laws.
The Problem
- ✗ No authorization was obtained before testing
- ✗ Actually extracting data (even "just a few records") is unauthorized access
- ✗ The "help" offer looked like extortion to the business owner
- ✗ Good intentions don't provide legal protection
Lessons Learned
- ✓ Never test without permission - Even with the best intentions
- ✓ Report without exploiting - You can report a potential vulnerability without proving it works
- ✓ Use official channels - Look for security@company.com or bug bounty programs
- ✓ Consider anonymous reporting - Use CERT or other coordination centers
- ✓ Don't offer paid services in disclosure - It can be perceived as extortion
Key Takeaways
Documentation is Protection
Written authorization, clear scope, and detailed logs protect both you and your client.
Stay Within Scope
Even exciting findings don't justify exceeding authorized boundaries.
Communication is Critical
When in doubt, stop and ask. A quick call can prevent major problems.
Insurance Matters
Professional liability insurance has saved many careers.
Know Your Environment
Cloud providers, shared hosting, and third parties all have rules.
Good Intentions ≠ Legal Protection
Authorization is binary - you either have it or you don't.