A Post-Incident Verification Plan for Tor Relay Operators
Removing a malicious relay from the consensus ends only one part of the incident. The operator still has to determine what happened on the host, rotate credentials, restore a trusted relay identity, and verify that the replacement behaves as intended. The October 2026 Tor relay case offers a practical sequence because the public notice names several checks and the incident reporting shows why a superficial cleanup is insufficient.
The source reports that affected relays were flagged as bad exits and that no relay with the attacker's policy remained in the consensus by October 5. It also describes at least two servers with Ebury 1.8.3, including one where the implant survived a reboot. The network response was fast, but host recovery remains the operator's responsibility.
Freeze the incident record
Before taking action, record the relay fingerprint, nickname, family, IP address, current exit policy, public flags, and the time of each observation. Export relevant directory data and preserve screenshots of the relay search. Save torrc and included files, package hashes, running process details, network rules, authentication logs, and any suspicious files.
Do not rely on a single timestamp. The incident window ran from October 1 through October 5, but the public analysis counted policy changes beginning October 1 and the researcher's scan occurred October 2. Host logs may use a different timezone or source clock. Normalize times and keep the original values.
Decide whether to isolate or investigate first
If active malicious behavior is suspected, remove the relay from service to prevent more traffic from being carried. If evidence preservation is incomplete, coordinate the isolation with the platform owner so volatile data can be captured. The Tor Project's notice recommends taking a suspected relay offline, preserving disk and logs, reinstalling rather than cleaning, generating a new relay identity, and rotating every credential on the host.
The reporting also warns that a clean package check is not enough. Ebury used a setuid library whose name resembled the system library, and package verification could pass because the packaged file was untouched. A process or file name that looks normal should be verified against ownership, hash, path, and behavior.
Rebuild the host and identity
Rebuild from a trusted image or installation source. Do not reuse the old disk, configuration, SSH keys, backup passphrase, or relay cryptographic identity if compromise is credible. Create a new relay identity and update the operator's inventory. Change every password, API token, SSH key, and recovery credential that was present on the host or its management path.
Check other hosts that shared the same management account or credential. A rotation on one server does not fix a reused password on a fleet controller. Review provider accounts, DNS records, firewall rules, and backup access before the new relay begins carrying traffic.
Verify the public configuration
After the relay restarts, confirm the intended ExitRelay and ExitPolicy settings, family membership, contact information, and nickname. Compare the public descriptor with the local configuration. Watch the first consensus appearances and confirm that the relay does not receive an unexpected flag.
ZoomEye can provide an external view of the host during this period. An all-asset app="Tor" query returned 106,423 observations on October 31, 2026. The operator can use the query as a repeatable baseline and check whether retired addresses or unintended services remain visible. A match is not a trust decision, and absence from a scan is not proof of remediation.
Report and monitor
Send the bad-relays team the relay fingerprint, IP address, behavior, and supporting evidence. If an address was blocked during the incident, follow the reporting guidance before requesting review. Keep a post-incident record of the rebuilt relay, credential rotations, and verification checks.
Monitor configuration drift after recovery. Compare the public policy with the approved template and alert when a relay changes role outside a planned window. Review the management path that could make the change. The goal is to catch a repeat before it becomes another active interception.
Close with evidence
A relay is ready to return when the host is rebuilt, credentials are rotated, the new identity is documented, the public policy matches the intended configuration, and the operator has a monitoring path for future changes. Those steps address different risks. A successful network re-entry alone does not prove the host is clean.
The incident shows why recovery needs both service and security checks. Tor Metrics can show that a relay is visible in the network. ZoomEye can show that an address has an external Tor or SSH service. Host evidence explains whether that service is trustworthy. Operators should use all three where available and state which one supports each conclusion.
Top comments (0)