Skip to main content

​
Overview

scan4all is a powerful security scanning tool designed for authorized security testing. This guide outlines ethical practices, legal considerations, and responsible disclosure procedures.
IMPORTANT: Only scan systems you own or have explicit written permission to test. Unauthorized scanning may be illegal in your jurisdiction.

​
Authorization Requirements

Before conducting any security scan:
  1. Obtain written permission from the system owner
  2. Define scope clearly - specific IP ranges, domains, and systems
  3. Set time boundaries - when scanning is permitted
  4. Establish communication channels - emergency contacts if issues arise
  5. Review applicable laws - understand regulations in your jurisdiction

​
Regulatory Frameworks

Be aware of relevant laws and regulations:
  • Computer Fraud and Abuse Act (CFAA) - United States
  • Computer Misuse Act - United Kingdom
  • GDPR - European Union (data protection implications)
  • Local cybercrime laws - Vary by country and region
Consult with legal counsel before conducting security assessments, especially in unfamiliar jurisdictions.

​
Authorized Testing Scenarios

​
Bug Bounty Programs

Many organizations offer bug bounty programs with defined rules: Before scanning:
  1. Read the program’s scope and rules thoroughly
  2. Respect out-of-scope assets and testing methods
  3. Follow rate limiting and non-disruptive testing requirements
  4. Register and submit findings through official channels
Recommended scan4all configuration for bug bounties: 
# Enable comprehensive discovery
export ParseSSl=true
export EnableSubfinder=true

# Use gentle scanning to avoid disruption
priorityNmap=false
./scan4all -l inscope.txt -rate-limit 50

​
Penetration Testing Engagements

For formal penetration testing: Documentation requirements:
  • Signed contract or statement of work
  • Rules of engagement document
  • Contact information for technical and management escalation
  • Timeline and testing windows
  • Incident response procedures
Scanning approach: 
# Full-scope authorized testing
./scan4all -l targets.txt -ceyeapi <your-key> -ceyedomain <your-domain>.ceye.io

​
Personal/Owned Infrastructure

When testing your own systems:
  • Still notify your hosting provider - Automated abuse systems may flag activity
  • Avoid scanning shared infrastructure - May affect other users
  • Test in isolated environments when possible

​
Ethical Scanning Practices

​
Minimize Disruption

Rate limiting: 
{
  "nuclei": {
    "rate-limit": 50,
    "bulk-size": 10
  },
  "httpx": {
    "rate-limit": 50,
    "threads": 25
  }
}
Scan during maintenance windows:
  • Off-peak hours for production systems
  • Scheduled maintenance periods
  • Development/staging environments first

​
Avoid Data Exfiltration

Do not:
  • Download sensitive data during testing
  • Extract customer information
  • Compromise user privacy
  • Pivot to out-of-scope systems
Do:
  • Take screenshots as proof of concept
  • Record minimal evidence needed
  • Stop immediately upon discovering critical vulnerabilities
  • Document findings without exploiting further

​
Respect Honeypot Systems

Enable honeypot detection to avoid wasting resources: 
export EnableHoneyportDetection=true
./scan4all -l targets.txt
If you identify a honeypot:
  1. Document it in your notes
  2. Move to next target
  3. Inform the client if on engagement

​
Vulnerability Disclosure

​
Responsible Disclosure Timeline

Typical disclosure process:
  1. Discovery (Day 0)
    • Document vulnerability thoroughly
    • Gather proof of concept evidence
    • Do not publicly disclose
  2. Initial Report (Within 24-48 hours)
    • Report through appropriate channel
    • Provide clear, detailed description
    • Include reproduction steps
    • Specify severity assessment
  3. Vendor Response (Within 7 days)
    • Confirmation of receipt
    • Initial triage and validation
    • Assignment of tracking identifier
  4. Remediation Period (30-90 days)
    • Vendor develops and tests fix
    • May request additional information
    • Coordinate disclosure timeline
  5. Public Disclosure (After fix deployed)
    • Coordinated announcement
    • CVE assignment if applicable
    • Credit to researcher

​
Critical Vulnerability Handling

For severe vulnerabilities (RCE, authentication bypass, data exposure): Immediate actions:
  1. Stop testing immediately
  2. Document exactly what was found
  3. Report within 24 hours
  4. Provide temporary mitigation recommendations
  5. Do not share with third parties
Reporting template: 
Vulnerability Title: [Brief description]
Severity: [Critical/High/Medium/Low]
Discovered: [Date]
Affected Systems: [Specific scope]

Description:
[Detailed explanation]

Reproduction Steps:
1. [Step by step]

Proof of Concept:
[Screenshots, minimal exploit code]

Impact:
[What an attacker could accomplish]

Recommended Remediation:
[Suggested fixes]

Discovery Method:
[Tool used: scan4all vX.X.X]

​
Finding the Right Contact

​
Preferred Channels

  1. Security.txt - Check /.well-known/security.txt
  2. Bug bounty platform - HackerOne, Bugcrowd, etc.
  3. Security email - [email protected]
  4. CERT/CC - For coordination assistance
  5. General contact - As last resort

​
Security.txt Example

Contact: mailto:[email protected]
Expires: 2026-12-31T23:59:59.000Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

​
Data Protection

​
Secure Storage of Findings

Protect scan results: 
# Encrypt output files
tar czf results.tar.gz results/
openssl enc -aes-256-cbc -salt -in results.tar.gz -out results.tar.gz.enc
rm results.tar.gz

# Secure Elasticsearch
# Use authentication and encryption
Access control:
  • Store findings on encrypted drives
  • Use password managers for credentials
  • Implement need-to-know access
  • Secure delete when no longer needed

​
Elasticsearch Security

When storing results in Elasticsearch: 
# config/nuclei_esConfig.yaml
username: scan4all_user
password: <strong-password>
ssl: true
ssl_verification: true
Network isolation: 
# Bind Elasticsearch to localhost only
docker run --restart=always -p 127.0.0.1:9200:9200 \
  -d --name es hktalent/elasticsearch:7.16.2

​
Privacy Considerations

​
Logging and Telemetry

scan4all integrates various tools that may have telemetry: Disable external logging:
  • Review config/config.json for telemetry settings
  • Use self-hosted infrastructure (Elasticsearch, DNS)
  • Avoid third-party DNS resolution services for sensitive targets
Personal DNS services: 
# Use your own DNS monitoring
./scan4all -l targets.txt -ceyeapi <your-key> -ceyedomain <your-domain>.ceye.io

​
Target Information Protection

scan4all includes log4j-scan integration that blocks target information from being sent to third-party DNS log servers, protecting vulnerability data.
Built-in protections:
  • Target data not sent to external DNS log servers
  • Results stored locally or in your Elasticsearch instance
  • No default cloud telemetry

​
Community Engagement

​
Reporting Tool Issues

For scan4all bugs or false positives: Public issues (non-security): Security issues in scan4all:
  • Contact maintainer privately
  • Do not disclose publicly until patched

​
Contributing Improvements

Enhance the tool responsibly:
  • Submit POCs through pull requests
  • Share fingerprints for better detection
  • Document use cases and scenarios
  • Respect responsible disclosure for new vulnerability types

​
Red Team Considerations

For authorized red team operations:

​
Operational Security

Minimize detection: 
# Disable aggressive scanning
priorityNmap=false

# Lower thread counts
# Edit config/config.json
{
  "nuclei": {"threads": 10},
  "httpx": {"threads": 10}
}
Proxy configuration:
  • Route traffic through authorized infrastructure
  • Use dedicated testing networks
  • Maintain proper attribution in logs

​
Rules of Engagement

Always within approved scope:
  • Define explicit in-scope targets
  • Respect out-of-scope restrictions
  • Establish emergency stop procedures
  • Maintain communication with blue team

​
Incident Response

​
If Something Goes Wrong

Service disruption:
  1. Stop scanning immediately
  2. Contact technical point of contact
  3. Document what occurred
  4. Assist with recovery if needed
  5. Update rules of engagement if necessary
Unintended discovery:
  • Found vulnerability outside scope: Report immediately, do not explore
  • Discovered sensitive data: Document minimally, report, do not extract
  • Identified criminal activity: Consult legal counsel, consider law enforcement

​
Compliance Checklist

Before scanning:
  • Written authorization obtained
  • Scope clearly defined and documented
  • Legal review completed (if required)
  • Emergency contacts established
  • Rate limits configured appropriately
  • Data protection measures in place
  • Disclosure process understood
  • Incident response plan prepared
  • Honeypot detection enabled (if applicable)
  • Results storage secured

​
Additional Resources

  • NIST SP 800-115: Technical Guide to Information Security Testing
  • OWASP Testing Guide: Web application testing methodology
  • PTES: Penetration Testing Execution Standard
  • Bug Bounty Platforms: HackerOne, Bugcrowd, Intigriti
  • CVE Program: https://cve.mitre.org/
  • CERT/CC: https://www.kb.cert.org/vuls/
Remember: The goal of security testing is to improve security, not to cause harm. Always act with integrity and within the bounds of authorization.

Build docs developers (and LLMs) love

Get started for freeTalk to us