Tor for Security Researchers: Protecting Yourself During Vulnerability Work

The Computer Fraud and Abuse Act (US) and its equivalents in other jurisdictions (UK Computer Misuse Act, EU Directive on Attacks Against Information Systems) apply to unauthorized access to computer systems. Courts have interpreted authorization broadly - accessing systems in ways not explicitly permitted by the owner, even if publicly accessible and technically possible, can constitute unauthorized access in some jurisdictions. Notable cases: Aaron Swartz (JSTOR access), weev/Andrew Auernheimer (AT&T API), and multiple bug bounty reporters who faced legal threats despite disclosing through official channels. Security researchers conducting vulnerability research from identifiable IPs create a clear attribution trail - the target system's logs show their IP accessing specific vulnerability-indicating endpoints. Tor anonymizes this access, reducing the ability to link the researcher's real-world identity to specific research activities.

For web application and API vulnerability research: use Tor Browser or a Tor-routed tool (curl via torsocks) for manual vulnerability testing. Each request from Tor appears to originate from a different exit node (when using New Identity) or a consistent exit (when maintaining circuit). For automated scanning: route scanning tools (nikto, nuclei, sqlmap) through Tor's SOCKS proxy: torsocks nikto -host target.com or configuring the tool's proxy settings to 127.0.0.1:9050. Considerations: automated scanning through Tor is slow (Tor circuits limit throughput) and may affect other Tor users sharing exit capacity - do not run aggressive scans through the Tor public network. For permission-based research (authorized penetration tests): use dedicated infrastructure, not Tor public network, to avoid consuming shared Tor resources for commercial work.

Bug bounty platforms (HackerOne, Bugcrowd) require account registration, linking bug submissions to a researcher identity. For researchers who want to maintain anonymity from bug bounty programs (to avoid targeted harassment, to separate professional reputation from specific disclosures, or in countries where the research may be legally ambiguous): create bug bounty accounts using purpose-built email addresses (ProtonMail over Tor), accessed exclusively via Tor Browser. The platform will know the account's email and IP history (Tor exit IPs), but cannot link the account to your real identity without the email account's records. For direct disclosure without a bug bounty platform: contact security teams via PGP-encrypted email from a pseudonymous account over Tor. Include proof-of-concept details encrypted to the target's published security PGP key.

Security research infrastructure - scanning servers, test environments, proof-of-concept code - should not be linked to the researcher's personal identity. For cloud-hosted research infrastructure: provision VPS instances using privacy-respecting providers that accept Monero payment, accessed via Tor, without real identity verification. The infrastructure's IP range then becomes linked to the research activities rather than the researcher's home IP or institutional identity. For code repositories hosting proof-of-concept exploit code: use .onion Gitea with an anonymous account rather than GitHub, which links repositories to verified real-world accounts. Operational security for research: develop clear procedures for what information to include in disclosure reports (sufficient for reproduction but not revealing your research methodology in ways that could expose other researchers following similar approaches).

Responsible disclosure involves notifying the affected vendor or CERT (Computer Emergency Response Team) before public disclosure, allowing time for patching. Coordinated vulnerability disclosure via Tor: use ProtonMail over Tor or a .onion-accessible secure drop submission system for initial disclosure. Many organizations accept vulnerability reports via email and do not require real-name disclosure for initial contact - the disclosure report's technical content is more important than the reporter's identity. For following up with CERTs (US-CERT, CERT/CC, national CERTs): most accept PGP-encrypted email and will work with anonymous reporters if the vulnerability documentation is credible and complete. Public interest disclosure (when vendors fail to patch after reasonable time): submitting to journalism outlets with SecureDrop (accessed via Tor) creates an independent record of the disclosure attempt and protects the researcher through journalistic source protection.