The Tor incident did not affect a single operator or server. Public directory analysis counted 377 relays across 59 operators. The researcher found 333 exits redirecting SSH. One relay family, Quetzalcoatl, accounted for a large share of the affected hosts, and the analysis found a high concentration of policy changes among relays hosted at FranTech Solutions. Those patterns do not prove a provider-level compromise, but they show why fleet-level review matters.
An operator who examines one host at a time may miss shared management paths. A password, SSH key, configuration tool, backup account, or provider console can provide access to many relays. The operator needs a view that connects relay identity, host ownership, network location, and administrative access. That view is different from a list of public IP addresses.
Build a family-level inventory
Start with relay fingerprints grouped by operator, family, and hosting provider. Add the public exit policy, flags, first and last observation dates, and the host's management account. For each group, identify the systems that can change torrc or restart the Tor service. Include configuration management servers, backup systems, jump hosts, and provider APIs.
The inventory should show where common credentials are used. A reused password on a management server can affect every relay that server controls. A shared backup passphrase can expose configuration and keys. A single administrative SSH key can become a fleet-wide trust problem. Record the scope of each credential and rotate it if the host that held it is suspect.
Use public data to find clusters
The directory analysis compared policy changes across relays. That method revealed clusters that individual host checks might not have shown. An operator can perform a similar review with its own historical configuration data: group relays by policy hash, family, provider, and change time. Look for groups that changed together or adopted a policy outside the approved template.
The source reporting also noted that many affected relays were hosted on one provider while others were distributed. The concentration is a reason to ask questions about shared infrastructure, not a conclusion about the provider. An investigation should examine customer accounts, management interfaces, and provider-side controls for evidence before assigning responsibility.
Add an external inventory
ZoomEye can provide an outside view of Tor and SSH services. The all-asset app="Tor" query returned 106,423 observations on October 31, 2026. A team can compare those observations with its relay list to find a visible host that is absent from inventory, or a host in inventory that has moved to an unexpected network.
The query cannot identify family membership or compromise. It can, however, expose a host that is still reachable after its relay was removed from the consensus. That observation is useful during recovery because an operator may have stopped the relay service while leaving the server and its management path online.
Coordinate the response
Assign one incident owner for the fleet and separate owners for each host group. The fleet owner tracks shared credentials, network changes, provider contacts, and the overall timeline. Host owners preserve evidence, inspect configuration, and report findings. A clean check on one host should not close the investigation for the whole family.
Use a common evidence format across hosts. A consistent record makes it possible to compare file hashes, login times, process names, policy changes, and network observations. It also makes clear which relays were cleared, which require rebuilding, and which remain unknown.
Recovery across a relay family
If a shared management path was compromised, assume that every relay it could modify may need credential rotation. Rebuild suspect hosts rather than attempting a partial clean. Generate new relay identities when old keys may have been stolen. Recheck DNS, firewall rules, provider accounts, and backup access before returning the family to service.
The Tor Project's bad-relay process can limit the use of suspicious relays while the investigation continues. Operators should report the relevant fingerprints and behavior, preserve evidence, and coordinate re-entry after remediation. The goal is to restore a trusted network role, not merely to bring the process back online.
Measure the fleet after recovery
Repeat the external query and compare the visible population with the approved inventory. Check that retired hosts are no longer reachable on expected ports and that new hosts have the intended configuration. Keep the query timestamp and scope with the result.
The value of ZoomEye in this scenario is fleet visibility. It helps an operator see assets that may be outside the configuration system and measure whether recovery changed the public surface. It does not replace evidence from the hosts or the directory. A sound response uses both views and documents where they disagree.