Torhoo onion mirror : torhoocc3yugradvhrppml2fin4xob7kgg7uf42s4xk7p6r5vzy62ead.onion

How to jump ship without getting exposed : OpSec | Torhoo darknet markets

This post in reference to recent DNM busts due to the issue, it is relevant to anyone operating with a hiddenservice in a jurisdiction where their actions are illegal.

Migrating a live onion service under active attack is tricky, because your Tor daemon; not just your key builds long‐lived circuits “guards” that, if observed at the HSDirs or by a threat actor on the network, can expose the IP of the machine hosting your service.
From my personal experience and knowledge here are some preventative measures to keep yourself from getting clapped:

Always have a backup instance thats completely disconnected from your project or service.

/u/asfaleia ⚔️ασφάλεια⚔️

2 points

3 weeks ago

No need to go into details. The weapon is made of pieces put in place perfectly, fitting each other. Same with the OpSec. You cannot take one piece and say that it will make you safe. It won't. The context of your situation, operation, jurisdiction.... are the key factor. From that situational awareness you build the OpSec, step by step.

If one fails in this basic security exercise, facing the top intel agencies with more-less unlimited funding, equipment and resources, he will DEFINITELY and INEVITABLY fail. It is all that simple. And in this context DEAD simple.

/u/datarape

1 points

3 weeks ago

This post in reference to recent DNM busts due to the issue, it is relevant to anyone operating with a hiddenservice in a jurisdiction where their actions are illegal.

This is one of the most overlooked failure points in DNM OPSEC—especially when you're facing state-level adversaries like LE or intel agencies.

1. Guard Node Reuse = Signature

[] Tor's long-lived guards are meant to defend you—but if copied carelessly, they become a fingerprint for them.
[] If LE has already identified your guard set (or even some of it), reusing it bridges your “new” hidden service to the “old” one, even if you moved it to a different server in a different country.
[*] Feds can monitor HSDirs and log descriptor activity for correlation attacks.

→ Guard fingerprint reuse has busted multiple actors in the past. This is not hypothetical.

2. Descriptor Timing Analysis

[] If both the old and new instances are online simultaneously—even for minutes—observers watching the DHT and HSDirs can detect a handoff.
[] When you push new descriptors while the old ones are still active, it creates a temporal overlap that can be used to infer continuity.
[*] Timing + small metadata (descriptor size/hash diffs) can confirm linkability.

→ Feds with access to high-bandwidth relays or passive taps (yes, that happens) can do this easily.

Your Procedure Is Close to Solid — But Add This:

Use ephemeral Tor data from scratch. Never reuse state, cached-microdesc-consensus, or guard metadata.
Change everything except your hs_ed25519_secret_key if you want to preserve the hidden service address.
Consider delaying descriptor publishing for 24–48 hours minimum. Let the network forget your last fingerprint.
Rotate intro points immediately after publication. Use the HiddenServiceNumIntroductionPoints to reduce potential correlation.
Use a throwaway relay to burn in your new instance for a few hours before pushing it to your production node.

Extra Consideration:

[] Run a decoy service temporarily to mimic uptime while the real one relocates.
[] Consider using a bridge or obfs4 inbound if you suspect your guard list is compromised.
[*] If you're under direct targeting: nuke Tor state every time you rotate.

Jumping ship is useless if you tow the same anchor.

→ For a full migration, you’re not just rotating keys you’re rotating fingerprints, state, and metadata trails.

/u/[deleted] 📢

1 points

3 weeks ago

Amazing comment, hats off to you sir.