Phishing Clones and Fake Vendor Pages: A Buyer’s Verification Routine

Most fake vendor pages don’t get taken down. They get abandoned. The URL stays live, the PGP key still resolves, the escrow badge still renders, and the only thing that changed is the wallet address in the payment field. By the time a buyer notices, the mirror is already fading and the admin has moved on to the next clone. There’s no takedown notice, no seizure banner. The page just goes quiet.

That’s the part most operational security guides skip. They tell you to verify the onion signature, check the PGP fingerprint, compare the mirrors. All necessary. None of it catches a clone that was built after the real market was already offline, seeded with cached pages, and pointed at a fresh wallet. This is a routine for that specific problem, not a general one.

Research only. Nothing here points at a live market or gives access instructions. The goal is understanding how clone detection works structurally, because the same mechanics apply to any copycat surface: phishing kits, SEO-poisoned docs, and fake vendor storefronts all share DNA.

Why clones beat mirror checks

The standard mirror verification routine (compare onion against a signed list, check the PGP signature, ignore Telegram links) works when the adversary is a single fake URL. It fails when the adversary is a pixel-perfect clone of the entire page tree, sitting on infrastructure that has never been flagged.

Look at how phishing kits are built today. The Sneaky 2FA kit uses a Cloudflare Turnstile gate in front of the fake Microsoft login. Automated scanners and sandboxes fail or skip the CAPTCHA, so they never see the actual page. Real visitors do. The kit redirects data-centre IPs, VPNs, proxies, and known-abuse ranges to a Microsoft Wikipedia page via href.li, so anyone doing a quick check from a research VPS gets a benign result (cybersecuritynews.com).

That’s the exact problem for a darknet buyer doing due diligence. If your verification traffic comes from a VPN exit or a hosting IP, you may never see what a genuine victim sees. The clone doesn’t need to fool every visitor. It only needs to fool the one who clicks Buy.

The verification routine

A few stages. Order matters, because each stage filters out a different class of clone.

1. Canonical source first, always

Before touching any URL, pull the canonical market list from a source you already trust: a signed Dread post, a PGP-signed text file, whatever your baseline is. Never accept a mirror from a vendor message, a forum reply, or a search result. This is the boring step and it’s the one that catches most clones, because clones almost never appear on the canonical list. If the URL isn’t there, stop.

Worth stating plainly: link shorteners, redirects, and “mirror” domains are all the same failure mode. The open-redirect trick in phishing kits (traffic bounces through an intermediate, then lands on the target) exists specifically to strip the “is this the real domain” question out of your head.

2. PGP signature on the listing, not just the profile

This is where most fake vendor pages break. The clone can copy the PGP public key from the real vendor’s profile. It cannot produce a new signature with the corresponding private key over content it just made up.

So: don’t just check that the vendor’s key matches a known fingerprint. Check that the listings are signed, and that the signature validates against the current content. Exit scams in the vendor class often happen after a reputation has matured, when the vendor has accumulated enough escrowed funds to make walking away profitable (Wikipedia, exit scam). A cloned page that also carries the real vendor’s signed listings is a stolen-identity exit waiting to happen: you pay, the escrow never sits where you think it does, and the “vendor” who signed those listings is not the one holding the private key.

The safe assumption: if the listing isn’t signed, treat it as unsigned. A profile key isn’t proof of authorship.

3. The HTML integrity check nobody runs

View source. Look for invisible content. The Zscaler research on SEO-poisoning campaigns found hidden text tucked inside a webpage element pushed far off screen using simple CSS positioning: invisible to a normal visitor, fully readable to crawlers and AI tools. The same campaigns stuffed JSON-LD (structured data) with instructions aimed at AI agents, framing a fake three-dollar developer licence as a routine step, pushing payment to an attacker wallet (cybersecuritynews.com).

Clone vendors do the same thing for a simpler reason: they want automated trust signals to flag the page as legitimate. A fake vendor page with hidden text or injected JSON-LD is telling you what it thinks of your due diligence. Search-page position is not evidence of authenticity, and typosquatting campaigns routinely copy social media style tags to make shared links look like they came from the real service (cybersecuritynews.com).

4. Wallet address diffing

This is the cheapest check and it gets skipped the most. If you know a vendor’s historical wallet address from a signed listing, a fresh clone will show a different one. Always. Copy whatever address is on the current page, compare it character-by-character against the signed version. If it changed and there’s no signed update explaining why, the page is compromised or cloned.

Do not verify the address by comparing it on-screen. On-screen comparison is vulnerable to homoglyph substitution and clipboard interception. Use a local diff. This is the one step that catches a clone even when every other signal is clean.

5. Behavioural signals from the page itself

A working market feels slightly wrong. Pages lag, the search does something strange, the product images are low-res stock, the “last seen” timestamps are suspiciously regular. A clone is usually too clean, too fast, too consistent. It has no live vendor chatter, no recent moderated disputes, no dead listings from vendors who left years ago. The absence of messy history is itself a signal.

I’d rather see an active market that’s visibly creaking than a frozen-perfect mirror. The creaking one has users on it right now. The clone only has the crafted page.

Where MFA-style relay logic shows up in buyer bait

The reason this matters to a buyer, not just to a security team, is that phishing infrastructure has matured into a relay model. Modern kits don’t capture your credentials and replay them later. They capture credentials and relay them live to the real backend while the victim completes real MFA against the real service. Sekoia found that the kit hardcodes a different User-Agent string for each step (Safari-on-iOS for login, Chrome-on-Windows for MFA resolution), an “impossible device shift” that no real browser produces (cybersecuritynews.com).

The darknet buyer equivalent is the mule: a fake vendor page that relays your escrow deposit live to a real wallet you don’t control, then shows you a confirmation that mirrors the market’s own UI. Same principle. You think you’re completing a purchase. The page is completing a different transaction.

One more pattern worth knowing because it’s being adapted into crypto-native scams: researchers documented a kit that shows a passkey setup screen and prompts the victim to save a recovery phrase built from BIP 39-style words, a technique borrowed from crypto wallets. The step does nothing for the account. It occupies attention while the attacker registers their own passkey in the background, and a final screen confirms the fake passkey was created (cybersecuritynews.com).

If a market asks you to save a recovery phrase at any point, on any page, stop. No legitimate market needs a wallet-style seed phrase from a buyer. That’s a direct transfer of custody.

What the routine actually buys you

The five stages above are not a guarantee. A determined clone on fresh infrastructure with a stolen vendor key and a signed-list replay will beat any routine. But most clones are cheap. They reuse page templates, skip the signature step, and hope the buyer is tired enough to click without diffing.

The routine catches that layer. It costs maybe three minutes per vendor. Do it once at the point of first interaction and again if the page ever loads faster than usual.

The failure mode I keep seeing is treating verification as a one-time gate. It isn’t. The attacker’s job is easier than yours because they only need one successful weekend. Yours is harder because you need it to hold for every purchase. Diff the wallet. Check the signature. Accept that the cleanest page in the market is usually the one that has the least history, not the most.

Research only. Nothing in this article links to or endorses any market.