TL;DR: A hidden service was built to be hard to find and harder to fake. That promise rests on one secret. New attention to how Tor load balancers handle that secret shows a worrying pattern: put the master key in the wrong place, and someone else can copy the address that proves you are you.
What Happened?
Security researchers and operators have been examining how Tor v3 onion service load balancers handle key material. The tools in question, including OnionBalance and its Go ports, spread traffic across several backend servers so a busy .onion site stays up under load.
Here is the catch. To publish a valid address, the balancer instance holds the master identity key for the .onion. That key is the whole identity. Once an attacker is on the box, no password prompt or second factor protects it. Compromise the instance that stores it, and you walk away with the one secret that defines the service.
The attack is not some exotic cryptographic break. It is a theft. An attacker who lands on the balancer through weak credentials, an unpatched flaw, or a misconfigured host reads the key off disk and leaves. From there, the original operator has no alarm and no lock to change.
What’s the Impact?
With the key in hand, an attacker owns the address. Three moves follow, and none of them require fooling the victim into clicking a strange link.
First, they stand up a copy of the hidden service at the exact same .onion address. Same string, same trust, different owner. Second, they reroute visitors to that copy, a classic man-in-the-middle, and watch everything that passes through. Third, they serve whatever they want: a cloned login page that harvests credentials, or malware dressed up as a normal download.
The most exposed people are those who rely on the address as proof. Marketplaces, forums, secure drop sites for journalists and whistleblowers, and any service where users paste a .onion and assume the string guarantees the destination. On the dark web, the address is the brand. Clone it, and you inherit the brand’s reputation for as long as the theft goes unnoticed.
Roughly 100% of that trust transfers to the attacker on day one, because nothing on the user’s end looks wrong.
How to Avoid This
No published indicators of compromise exist for this activity, so detection must rely on behavior, not a blocklist.
- Keep the master key off the load balancer wherever the design allows, and run each service on a dedicated instance instead of handing key material to a shared balancer.
- Rotate the .onion identity key and move to a patched build if your balancer ever stored it on an exposed host.
- Watch your Hidden Service Directory descriptors. A second descriptor published for your address, from infrastructure you do not control, is the strongest signal that someone else is now publishing as you.
- Treat the balancer host like a crown jewel: lock down access, patch fast, and alert on any read of the key file or any new process touching it.
- Pull load balancing up to the application layer where you can, so the Tor daemon, and its key, sits behind that layer rather than inside it.
Before an attacker finds your exposed key, you should
Onion service key theft is first an exposure problem. The key sits on a reachable host, and no one went looking for it until it was gone.
- See what is exposed the way an attacker does: probe your external footprint for key-holding and reachable hosts.
- Validate which of those exposures is actually reachable and usable, so you fix the real path, not a long list of maybes.
- Turn each finding into a fix with a clear owner, then retest to confirm the hole is closed.
- Keep a record of what was found, what was changed, and who approved it, so the proof is ready when an auditor or board asks.
- Do it in a loop, because exposure isn’t a one-time scan. Attack. Harden. Prove. Repeat.
