Dark Web Insight
risks

How Tor Users Get Unmasked: Attack Types

Most unmaskings are browser exploits, traffic confirmation, bad relays or seized servers — not a break of onion routing. A taxonomy with documented cases.

By Dark Web Insight Research Desk8 min readUpdated

Onion routing has not been "broken" in the sense people mean when they ask that. The documented unmaskings are almost all attacks on the ends, the implementation, or the operator's other mistakes. This page sorts those attacks by surface. Human errors — reused usernames, a Gmail welcome message — live in OPSEC and threat modeling. The raid timeline lives in law enforcement operations. Here: how the technical hits worked, what they cost, and what they did not prove.

Endpoint and browser exploits

Tor Browser is Firefox with patches. A Firefox bug that reaches the network can be turned into a Network Investigative Technique: the page sends a payload, the payload makes the computer call an FBI server off Tor, and the real IP appears in that log.

The 2013 Freedom Hosting case is the public example. After the hosting operator was arrested, visitors of sites on that service received a Firefox exploit. Researchers and journalists later tied the payload to a law-enforcement NIT. The 2015 Playpen investigation used another NIT on a seized child-abuse site and reached thousands of computers; court records and later reporting put the figure above 8,000. Those operations did not decrypt onion cells. They cheated the last hop: the user's browser.

Cost to the attacker: a working browser bug, a warrant in the relevant jurisdiction, and a delivery channel (usually a seized site). Defense: current Tor Browser, Safer/Safest when you do not need JavaScript, and an OS that cannot phone home even if the browser tries — Tails or Whonix. Common Tor mistakes still lists "outdated bundle" for a reason.

Traffic confirmation and correlation

Tor's own design document says it does not protect against an observer who can see the traffic entering the network and the traffic leaving it. If Alice's guard sees a burst at 14:03:12 and an exit (or a destination) sees the same burst, a confirmation attack can tie the two. This is not reading the cells. It is matching timing and volume.

Doing it to everyone means watching a lot of the internet or running a lot of relays. Doing it to a suspect you already have a warrant on is cheaper: tap the home connection, watch the destination, compare clocks. Academic papers have demonstrated variants on live Tor; the Project has repeatedly said this class is in scope for a well-resourced state and out of scope for the threat model of "the site owner" or "the local ISP alone."

What each hop can see is the complementary chart. Confirmation is what happens when two of those rows are the same adversary.

Malicious relays and Sybil clusters

If an attacker runs the guard and the exit for the same circuit, confirmation gets easier. The 2014 "relay early" incident is the clean public case. The Tor Project's July 2014 advisory described relays that used a protocol header to tag circuits and confirm them. The Project removed the relays and patched the protocol. Separate reporting — and a 2015 Tor Project blog post asking whether the FBI paid a university to attack Tor users — linked a Carnegie Mellon / CERT-related research effort to a traffic-confirmation study that later appeared in criminal cases. CMU and the FBI disputed parts of that framing; court records confirm that a university research attack produced user identifications that the government then sought. Treat the payment claim as contested; treat the technique as real.

Cost: enough bandwidth and IP diversity to get the guard and exit flags, plus a willingness to burn those relays when the directory authorities notice. Defense is mostly on the network's side (Sybil limits, guard persistence). Users help by not rotating guards for speed and by not running unofficial "optimized" clients. Why Tor is slow is where that temptation usually starts.

Server takeover and misconfiguration

Once someone owns the onion service, they own the inbox, the password resets, the uploaded files and any clearnet admin panel the operator left attached. Silk Road's CAPTCHA, reachable outside Tor, leaked the server's real IP to investigators. Freedom Hosting's seizure produced the NIT channel above. Market databases have repeatedly contained plaintext notes, reuse of vendor names, and Bitcoin addresses that join the public graph.

This class unmasks users of a service, not "Tor." The overlay can be working perfectly while the MySQL dump is sitting on a desk in Virginia. Exit scams and seized markets add a second path: the operator, or the police running the operator's box, already has the message archive.

Metadata and behavioural correlation

Even without an exploit, people leak: posting times that match a timezone, writing style, a unique PGP key reused on a named blog, a payment that hits a KYC exchange an hour after a vendor chat. These are correlation, not cryptanalysis. They are also how most published cases actually start, which is why the OPSEC page exists.

A technical taxonomy still needs this row because analysts often label it "deanonymization of Tor" when it is deanonymization of a person who happened to use Tor. The overlay did not fail. The identity hygiene did.

What Tor does not promise

Tor hides the TCP source from the destination and the destination from the local network, against adversaries who do not sit on both ends and do not own your device. It does not hide the fact that you use Tor (your ISP sees a guard, unless you use a bridge). It does not hide you from a browser exploit. It does not hide you from a service you logged into with a recovered password. It does not hide a Bitcoin graph you attached to the same persona.

If your threat model is a global passive adversary plus a browser 0-day, you are outside the brochure. If your threat model is a website, a local ISP, or casual surveillance, the documented failures are still mostly at the edges. Install from the official site, verify the signature, keep the bundle current, and do not confuse "no one broke onion routing" with "no one can find you."

Frequently Asked Questions

Is Tor cracked?

There is no public evidence of a general break of the onion-routing design that would let a random site operator read circuits. There is ample evidence of browser exploits, confirmation attacks by well-placed observers, and service-side seizures.

Can an intelligence agency follow a Tor user?

If they can see the entry and the exit (or the destination) they can attempt confirmation. If they can deliver a NIT they can skip the overlay. Both have shown up in court. That is not the same as "they decrypt every circuit."

What reduces the practical risk the most?

A current Tor Browser on Safer/Safest, an amnesic or firewalled OS so a payload cannot phone home, bridges if the local network is hostile, and the boring identity rules on the OPSEC page. Fancy torrc paths do not address NITs.

Did Carnegie Mellon unmask Tor users?

A CMU-related research effort used a traffic-confirmation technique on the live network; identifications later appeared in US cases. The Tor Project published an angry blog post about it. Who paid whom is disputed. The technical lesson is not: the method works if you run enough relays and tag circuits.