Onion Mirror Verification: How to Spot a Phishing Clone URL Before You Log In

Two onion addresses can differ by one character and point to completely different servers. That is the whole phishing problem in one sentence. On the surface web you type twitter.com and a fake at twittter-login.com looks obviously wrong. On Tor, a legitimate address is a 56-character string like expyuz5tat...3ad.onion, and a phishing clone is expyuz5tbt...3ad.onion. Same length, same shape, one flipped character. You will not catch it by eye. Neither will I.

So the practical question is not “can I spot a fake URL.” You mostly cannot. The question is what process you use to establish that the address in front of you is the one the operator actually published. This is a walkthrough of that process, written for people doing research, not shopping.

Research-only note: nothing here links to live markets or tells you how to reach one. The goal is anti-phishing discipline for anyone navigating hidden services, including journalists, threat intel analysts and students studying these ecosystems.

Why the phishing problem is structural, not a skill gap

Humans cannot memorize 56-character base32 strings. That is not laziness, it is the design. Because nobody memorizes addresses, everyone searches. And the moment people search, attackers flood dark web search engines and Reddit threads with fake links. Click the wrong result and your username, password or Bitcoin PIN is gone the instant you submit the login form.

The surface-web defenses you rely on unconsciously do not exist here. No TLS padlock worth trusting. No domain registrar reputation. No Google delisting the clone. There is no certificate authority vouching for an onion service in a way a normal user can check.

The clone problem is now industrial

If you think phishing kits are amateur hour, look at what is happening on the clear web. Phishing-as-a-service kits like Sneaky 2FA serve pixel-accurate clones of Microsoft authentication pages, complete with blurred screenshots of real Outlook and OneDrive interfaces as bait. Credentials get relayed live to Microsoft’s real API so the victim completes genuine MFA, and the attacker captures the session cookie server-side.

My point is not that onion clones use the same kits. It is that the tooling to clone a login page convincingly is cheap and mature. Assume the fake market login is indistinguishable from the real one, because it probably is.

A quick detour worth knowing: the “impossible device shift”

One detail from the Sneaky 2FA analysis is genuinely useful as a detection mindset. Sekoia found the kit hardcodes different User-Agent strings for each step of the auth flow it relays, for instance Safari-on-iOS for the login step and Chrome-on-Windows for MFA. No real browser does that within one session. That inconsistency is the tell.

Translate it to onion land: consistency checks beat gut checks. A real service presents itself the same way every time. A clone usually slips somewhere, in the address, the PGP signature, the TLS behavior. Your job is to look for the slip instead of trusting the vibe.

Step one: never start from a search engine

OSINT investigators generally do not use dark web search engines to find a specific platform. They use curated directories: static address books with PGP-verified onion links, not searchable indexes.

Two names dominate. Dark.Fail is the veteran. Minimalist, text-only, and it tracks uptime of major hidden services. Its admins maintain direct contact with marketplace operators, so when a service rotates its onion to dodge a DDoS, the list gets updated. The catch is that its own popularity makes it a constant target for extortion and DDoS, so Dark.Fail is frequently offline when you need it most.

Tor.Taxi is the other. Same idea: a fixed list rather than a query box, built around the principle that you should never depend on a single point of failure. That principle matters, because if someone compromises the directory server, they can swap every legitimate link for a phishing link in one edit.

Step two: verify the PGP signature, every time

This is the part people skip, and it is the only part that actually proves anything.

Every legitimate directory and marketplace has a cryptographic identity: a PGP key. The directory publishes a message containing the current onion links and signs it with its private key. You verify that signature with the directory’s public key. If it checks out, the links came from the real administrators, not from someone who popped the box.

The logic is simple. A signature match gives you mathematical certainty about who published the link. If the signature does not match, or there is no signature, treat the link as hostile. My rule: no verified signature, no login, no exceptions, especially not for anything involving money.

One annoying part: you need the directory’s public key from somewhere you already trust, or the whole exercise is circular. First-contact key bootstrapping is the weak link in most people’s OPSEC, and I do not have a clean answer for it. If you cannot establish the key through an independent channel, you are trusting a screenshot of a fingerprint someone posted months ago. Notice how weak that feels, because it is.

Step three: read the address, character by character

Once you have a verified link, the verification does not end. Before entering credentials, compare every character against the verified source. Not skim. Compare.

• First and last characters. Phishing onion addresses often keep the head and tail of the real address, exactly like the ...at...3ad versus ...bt...3ad example. Your eye pattern-matches the edges and waves the rest through.
• Read in chunks of five or so. Grouping forces serial processing instead of gestalt recognition.
• No copying from chat logs, Reddit comments or DMs. Every one of those is an attacker-controlled channel.
• Re-verify after every redirect. A mirror that redirects to a different onion is a login form you are about to feed.

Step four: harden the browser before you touch anything

The Tor Browser runs JavaScript by default. Malicious sites use it to de-anonymize visitors, and that is a real risk independent of whether the login form is fake. Open the shield icon, go to settings, set Security Level to “Safest.”

Do not download anything a search result or a market page offers you. PDFs, Word docs, .exe files: skip them. Office documents can carry macro viruses or tracking pixels that phone home to the attacker with your IP the moment you open them locally, outside the browser sandbox. The clear-web kits above even embed phishing links in PDFs with names like “Final Lien Waiver.pdf” to get past user suspicion. File bait is file bait, whatever the network.

And do not use surface-web proxies like tor.taxi or dark.fail from your normal browser. Some are maintained by the real admins, but they offer zero privacy. Your ISP sees the visit. If you need the link list, go through Tor.

What actually makes a clone fail

From what I have seen analyzing kit infrastructure, clones fail on operational details, not on visual quality. The useful checks, ranked by how often they catch something:

• PGP. The clone does not have the operator’s private key, so it cannot produce a valid signature on the link list. This is the strongest single check.
• Address mismatch. One flipped character in the middle of 56. Only catches clones when you do the character-by-character comparison honestly.
• Behavioral inconsistency. Rotated onion addresses, TLS warnings, a login page that autofills your username from a URL parameter the way Sneaky 2FA does. Real services rarely autofill what they should not know.
• Time. A directory link that was verified last month is worthless if the service rotated since.

The honest verdict

Mirror verification is not a skill you practice until you get good. It is a ritual you follow even when you are tired, because the one time you skip it is the time you lose the account. Verified directory, PGP check, character-by-character compare, hardened browser. Four checks, two minutes, and no cleverness required.

The uncomfortable truth about trust in this niche is that the directories themselves are attack surface. Once a compromised watchlist can point every user at a clone, “verified” only means “verified as of the last signature check.” Verify, then verify again next time. Assume every unverified onion link you click is hostile until the signature proves otherwise.