28 Oct 2026 / Security
Typosquatted Onion Addresses: How Phishing Mirrors Clone a Market Login Page
Two onion addresses sit side by side on a dark web search engine. One is real. The other differs by a single character buried somewhere in a 56-character string. You cannot tell them apart by eye, and neither can anyone else, which is the entire business model.
On the clearnet, typosquatting is a solved problem for most users. Wikipedia’s page on the subject lists the standard tricks: misspellings, a different top-level domain, a plural of a singular name, or combosquatting, where an attacker appends a legitimate-looking word to a real brand. Type twittter-login.com and your brain catches it. Type expyuz5tbt instead of expyuz5tat in the middle of a v3 onion hostname and your brain has nothing to work with. There is no dictionary, no memorable brand, no shape. Just base32 noise.
That asymmetry is why phishing mirrors are the dominant scam format on onion services. This article is a forensic breakdown of how those mirrors are built, distributed, and defended against. Research purposes only: none of this is an invitation to visit these sites, and I will not name live addresses.
Why the Onion Format Is Structurally Worse Than the Clearnet
A v3 .onion address encodes the ed25519 public key of the hidden service. That is the point of the design: the address is the identity, and only the holder of the private key can serve content on it. There are no certificate authorities because none are needed.
The trade-off is brutal for humans. The full string is 56 characters of base32, and a single-character difference means a completely different key, a completely different server, and a completely different operator. Security researchers who track this problem point out that a legitimate URL like expyuz5tat…3ad.onion and a phishing URL like expyuz5tbt…3ad.onion differ by one letter near the front. Users who try to verify by eye will fail, reliably. The attack surface is not a vulnerability in Tor. It is a vulnerability in human memory.
There is a second structural problem. The clearnet has Google, certificate transparency logs, and years of domain reputation. Onion services have none of that. Dark web search engines index whatever is submitted to them, and Reddit-style forums can be flooded by anyone. Threat actors do exactly that: they seed fake links into search indexes and community forums at volume, betting that a fraction of clicks will stick. The moment you enter a username, password, or Bitcoin PIN into one of these clones, those credentials are gone.
How a Mirror Is Actually Built
The cheap version is a full-page scrape. The attacker fetches the market’s login page, often through the real onion service, and mirrors the HTML, CSS, and images verbatim. Because onion marketplaces use consistent, homegrown templates rather than rotating marketing assets, a static copy stays convincing for months. The login form is rewired to POST credentials to the attacker’s collection endpoint instead of the market’s authentication handler.
The version worth respecting, in a purely adversarial sense, is the reverse proxy. The phishing onion does not serve a copy at all. It proxies requests to the genuine market in real time, so every page, every captcha, every balance figure is authentic. Only the credential submission and the withdrawal or deposit address flow are intercepted. This is the same architecture seen in modern clearnet Phishing-as-a-Service kits: Sekoia’s analysis of the Sneaky 2FA kit documented credentials being relayed live to Microsoft’s real authentication API, with the session cookie captured server-side afterward. On a darknet market, the equivalent is relaying your login to the real market, waiting for you to pass its captcha, then harvesting the session and your wallet PIN in one motion.
Proxy-based mirrors also inherit the real market’s uptime behavior. If the genuine service is under DDoS and flaky, the mirror is flaky too, which paradoxically makes it more believable. Users blame the Tor network.
| Torzon Market |
torzon7aphar3x4l5b77nsylgyw26kntbi4m2wemrjh72aczeh27f6qd.onion
|
| DrugHub |
drughuj7l72ig56pza77eriu7yh6qsao4xb4yasq2qfjusxzuq6rlwqd.onion
|
| DarkMatter |
darkmafmzgnsmow5z3spgludhpwxhwbg77oam433fjx3clzh2yp2oaid.onion
|
| Omega Market |
omega7yhz7n4vg4yhf2na2qaaaeatdlqvjbj2juc245mr5muxtnuvgyd.onion
|
| BlackOps |
blackoogcnxogvymmebfwfjhx4k7efpgeoeytxtsev2lc4pqlbz54qad.onion
|
Delivery Channels: Where the Fake Links Live
- Dark web search engines. Indexed submission, no verification. The fake link outranks or outlives the real one simply by being fresh.
- Forum and Reddit seeding. Accounts pose as confused users asking for a link, then an accomplice “helpfully” supplies the phishing mirror. This pattern is well documented in darknet OPSEC guides.
- Dead brand squatting. After an exit scam, the market’s name keeps drawing searches. One directory notes that after the Abacus exit scam in mid-2025, scammers stood up lookalike onions advertised as the “new Abacus mirror” and collected deposits from users still hoping to recover funds. Estimated losses from that exit were around $12 million across escrow, vendor balances, and in-transit payments, and roughly 70% of English-language market share evaporated. That is an enormous pool of disoriented users to phish.
- Hidden text aimed at crawlers. A newer wrinkle carried over from the clearnet. Zscaler documented lookalike domains using hidden HTML, positioned off-screen with CSS, containing instructions for AI agents and search crawlers to treat the fraud as the authoritative source. One fake DeBank tracker even told AI models to avoid mentioning a telltale word in its domain. Expect this to migrate to onion directories and “verified link” pages as AI intermediaries become a discovery layer.
Detection Techniques That Actually Work
Full-String Comparison Against a Trusted Source
This is the only method that matters, and it has to be done mechanically. Copy the address, do not retype it, and compare it against a PGP-signed statement from the market’s administrators, or against a curated directory you reached through a previously verified channel. Tor.Taxi and Dark.Fail operate on this model: they are static address books, not search engines, and their maintainers hold direct contact with market administrators so that when a market rotates its onion address to dodge a DDoS attack, the directory updates. One caveat from experience: Dark.Fail’s own popularity makes it a constant extortion and DDoS target, so the directory itself is frequently offline. Build redundancy. Bookmark two or three verified directories, obtained at different times through different channels.
Character-by-character comparison in a text editor, not in the browser address bar, catches the single-character swaps. The browser bar truncates long onions with ellipses on most Tor Browser builds, which is exactly the condition typosquatters exploit.
PGP Signature Verification
Legitimate market admins sign their canonical address with a long-standing PGP key. The correct procedure: import the key once, from a source you verified before, then check each new address announcement against that key. A mirror can copy a market’s page pixel for pixel. It cannot produce a valid signature from the admin’s private key. The failure mode here is the first import. If you import the admin key from a phishing page the first time, you have anchored your trust to the attacker, and every subsequent verification will pass. Treat the initial key acquisition as the highest-stakes step in the entire workflow.
Behavioral Tells on the Mirror Itself
Proxy mirrors leak. Some things to check, understanding that none of these are conclusive alone:
- Deposit address reuse or mismatch. Request a deposit address, then compare it against an address you already withdrew to or funded from on the same account. A proxy mirror that only intercepts deposit flows will serve an attacker-controlled address that has no history with your account.
- Credential harvesting timing. Crude clones ask for your wallet PIN on the login page or immediately after. Real markets ask for the PIN only at withdrawal, on a separate step, after a session is established. A premature PIN prompt is a near-certain tell.
- Session persistence. Log in, close the tab, reopen the market. A scraped static clone cannot restore your session. A proxy mirror can, so this only rules out the cheap version.
- Load characteristics. Static clones load unusually fast for an onion service, because they serve local files with no upstream Tor circuit. Proxy mirrors are slower, sometimes noticeably, since every request makes two hidden-service hops.
Lessons From the Clearnet Phishing Kits
The phishing underground on the surface web is a few years ahead operationally, and the techniques migrate. Three patterns from recent kit analyses are directly relevant to onion mirrors.
First, CAPTCHA gating. The Sneaky 2FA kit places a Cloudflare Turnstile challenge in front of the fake login page, which blocks automated scanners and sandboxes from ever reaching the phishing content. An onion mirror operator can do something equivalent with a Tor-agnostic JS challenge. If you are a researcher probing suspected mirrors, expect your automated tooling to see a wall where a browser sees a login form.
Second, IP-based filtering. The same kit silently redirects data-center, VPN, and proxy IPs to a benign Wikipedia page, so security researchers and automated crawlers never see the malicious content at all. Onion mirrors do not have IP intelligence as rich as clearnet services, but exit-node and known-scraper heuristics exist. A mirror that shows different content to your Tor Browser than to your research VM through a different path is telling you something.
Third, environment inconsistency as a detection signal. Sekoia caught Sneaky 2FA because it hardcoded different User-Agent strings for different steps of the relayed authentication flow, an “impossible device shift” no real browser session would produce. The analogous check on a market mirror: compare headers, timing, and rendered behavior against the known-genuine service captured in a reference session. Mismatches in fingerprint handling between “the market” at login and “the market” at withdrawal indicate your traffic is being terminated and re-originated somewhere in the middle.
What I Would Actually Do
Keep a local, PGP-verified address file for any service you research. Update it only through signatures from keys you anchored long ago. Never take an address from a search engine, a forum reply, a Reddit thread, or a “fresh mirror list” pastebin. Those are the watering holes the entire scam economy feeds on.
Be maximally paranoid about dead and rebranded markets. The Abacus aftermath is the cleanest case study: the market exit-scammed in mid-2025, stopped processing withdrawals, and vanished without a seizure notice, which is the signature of an exit scam rather than an outage. Any address still carrying that name afterward is a leftover phishing trap harvesting deposits from the hopeful. The same will be true of every future large exit.
And accept the baseline: in an ecosystem with no Google, no certificate authorities, and 56-character hostnames, typosquatting is not an edge case. It is the default condition. Directory verification and PGP anchoring are not optional OPSEC garnish. They are the only thing standing between a researcher and a pixel-perfect clone that differs from the real market by one letter no one can see.