Privnote Phishing: How Fake Clone Sites Steal Secrets

The problem

Privnote is one of the most recognised names in self-destructing message services. That recognition makes it a target. Fake Privnote clone sites have been documented extensively, including by security journalist Brian Krebs, who has covered multiple instances of phishing clones that impersonate Privnote to intercept secrets.

These clones look identical to the real Privnote. Same layout, same colour scheme, same workflow. A user who doesn't carefully check the domain has no visual cue that something is wrong. The clone captures the note in plain text, optionally modifies it, and delivers it to the recipient as if nothing happened.

How the phishing works

The attack follows a consistent pattern:

• Clone the interface. The attacker creates a site that replicates Privnote's UI pixel for pixel. The domain is similar but not identical, often using typosquatting (minor misspellings) or different TLDs.
• Drive traffic. The clone gets promoted through SEO manipulation, paid ads appearing above organic results, or direct links in phishing messages. Some clones have ranked above the real Privnote in search results.
• Capture the note. When someone creates a note on the clone, the site receives the secret in plain text. This is the fundamental weakness of server-side encryption: the server sees the secret before encrypting it.
• Deliver or modify. Some clones deliver the note to the recipient unchanged, silently logging a copy. Others modify the content before delivery. Documented cases include clones that scan notes for cryptocurrency wallet addresses and replace them with attacker-controlled addresses.

The recipient has no way to know the note was intercepted or modified. The link works. The note appears. The self-destruct behaviour functions normally. The theft is invisible.

Why Privnote is particularly vulnerable

Three properties make Privnote an effective phishing target:

• Server-side encryption. Privnote encrypts on the server, which means the note arrives at the server in readable form. A clone that mimics this architecture receives the secret in plain text by design. There's nothing to break. See Is Privnote safe? for a full analysis of the encryption model.
• Closed source. Privnote's code isn't public. Users can't verify what the server does with their data. A clone's code is equally opaque, and there's no way to distinguish the two from the outside.
• Simple interface. The minimal UI that makes Privnote easy to use also makes it easy to clone. A text box and a button. No unique visual elements that would be difficult to replicate.

The cryptocurrency angle

Some Privnote clones go beyond passive interception. They actively scan the content of every note for patterns that look like cryptocurrency wallet addresses. When a match is found, the clone replaces the address with one controlled by the attacker before delivering the note to the recipient.

The sender thinks they sent the correct address. The recipient sees what looks like a legitimate note. The funds go to the attacker. This is a man-in-the-middle attack at the application layer, made possible by the fact that the server has access to the plaintext.

How to spot a clone

There's no foolproof visual test, but these checks reduce the risk:

• Check the domain carefully. Character-for-character. Typosquatting relies on people scanning rather than reading.
• Don't follow search ad links to security tools. Type the URL directly or use a bookmark.
• Check the TLS certificate. It won't prove the site is legitimate, but a mismatch or a fresh Let's Encrypt certificate on a site claiming to be established is a signal.
• Be wary of links received in unexpected contexts. If someone sends you a Privnote link you didn't expect, verify with the sender through a different channel.

These are mitigations, not solutions. The underlying problem is architectural: when the server handles plaintext, a clone that handles plaintext looks identical.

How client-side encryption changes the threat model

With client-side encryption, the secret is encrypted in the browser before it reaches any server. The server receives ciphertext. A clone that replicates the server-side infrastructure gets ciphertext it can't decrypt.

Secret.Broker adds a further protection: domain binding. The encryption includes the current domain as additional authenticated data. Ciphertext encrypted on secret.broker can only be decrypted on secret.broker. If someone created a clone and a user encrypted a secret there, the ciphertext would be bound to the clone's domain. It wouldn't decrypt on the real site, and vice versa.

This doesn't make phishing impossible. An attacker could build a clone that uses its own client-side encryption and functions as a fully independent service. But the attacker can't passively intercept or modify secrets created on the real service. The man-in-the-middle attack on note content doesn't work when the server never sees the content.

The zero-knowledge architecture means the server is blind storage. A breach of the server, a rogue operator, or a clone that captures the encrypted blob all get the same thing: bytes they can't read.

What this doesn't solve

Client-side encryption and domain binding address the specific Privnote clone attack pattern. They don't eliminate all phishing risks:

• A convincing clone could trick a sender into creating a secret on the wrong site. The secret would be encrypted under the clone's domain, and the clone operator controls the decryption key delivery.
• Social engineering can bypass any technical control. If someone tricks you into revealing the secret through a phone call, no encryption helps.
• Link interception still matters. If an attacker gets the full link (including the URL fragment), they can decrypt the secret regardless of the architecture.

The goal isn't to eliminate all attacks. It's to make the specific, documented, at-scale phishing pattern that affects Privnote clones technically infeasible.