TON Connect phishing and session compromise

TON Connect was designed to remove the most dangerous patterns from a user’s life: typing a seed phrase into a browser, importing keys into a random dApp, trusting unsigned extensions. It succeeds at that goal — a bridge connection with end-to-end encryption is genuinely safer than “please enter your 24 words”. But attackers adapted quickly, and most TON-ecosystem phishing in 2026 now flows through TON Connect, precisely because the user sees a familiar pattern and lets their guard down.

This piece walks through four recurring attack shapes we observe in 2026 and lays down a defensive discipline. No named incidents or hard numbers — only structural descriptions, so you can recognise the pattern when it lands in your day.

How TON Connect works and where it is brittle

A short refresher on the connection flow, to make clear where the risk surfaces sit.

1. The dApp generates a connect request — JSON containing its manifest URL, the rights it wants, and a session identifier.
2. The user scans a QR code or opens a deep/universal link on mobile.
3. The wallet downloads the manifest from the URL the dApp specified and shows the name, icon and origin to the user.
4. The user approves. The wallet signs the response, the bridge relays it to the dApp.
5. From that point on the dApp can send sendTransaction requests; the wallet shows each one to the user and waits for approval.

The weak points are not in the cryptography. They are at the seams:

• The dApp controls the manifest URL, so the wallet displays exactly the name and icon the dApp chooses to ship.
• The dApp URL in the browser address bar is verified only by the user — the wallet never sees it.
• The signed transaction is a raw BoC with amount, payload and stateInit. Without emulation, what it actually does is non-obvious.
• Sessions live for a long time — the standard tolerates multi-day connections, and a dApp can request a signature a week after the initial handshake.

Each of those seams maps to one of the vectors below.

Vector 1: a fake dApp wearing the same logo

The most common scenario. The attacker stands up a copy of a popular interface — a DEX, an NFT marketplace, a staking dashboard. The design is pixel-for-pixel, logo identical, copy identical. Only the domain differs: instead of realdex.com the user lands on realdex-app.com, realdex.io, real-dex.com, or a homograph variant with a Cyrillic character visually indistinguishable from its Latin twin.

On the fake page you tap “Swap” or “Stake”, the TON Connect picker opens, you choose Tonkeeper. The manifest the wallet fetches is, of course, also forged — it carries the same “RealDEX” name and logo. The connection completes. The fake dApp then initiates a “swap”: the wallet shows a sendTransaction with amount X and a payload that looks like a normal swap-contract call. In reality the recipient address is the drainer’s wallet and the payload is crafted so that the wallet UI does not flag it as suspicious.

The deception works because the user did check everything within reach: the picker opened, the wallet is real, the name in the wallet matches. The browser address bar was not checked — almost nobody checks it. The only defensive move is to return to the address bar before clicking Connect and verify the domain against one you know by heart or keep in your bookmarks.

Vector 2: clipboard malware and connect-URL replacement

This vector activates when you connect a dApp on desktop via QR but keep your phone with the wallet nearby. To avoid scanning, many users copy the connect URL from the web UI and send it to themselves through Telegram or another messenger so they can open it on the phone.

That is the moment malware steps in. Clipboard stealers and clipboard replacers are a long-established class: they monitor the buffer and substitute its contents based on signatures. If the signature is tc:// or https://app.tonkeeper.com/ton-connect?, the malware rewrites the URL parameters so that the session establishes with the attacker’s dApp rather than the legitimate one. The attacker’s dApp then takes control of the session and issues signature prompts exactly as in vector one.

Visually you will see no difference: Tonkeeper opens the usual approval screen, and the dApp name matches the one you expected. Defence: either scan the QR directly without copy-paste, or after pasting take a careful look at the start of the URL and the session identifier. Any copy-paste of a TON Connect URL between devices is a window the clipboard attacker can climb through.

Vector 3: deep-link attack from a Telegram message

The most “social” of the four vectors. The user receives a Telegram message — sometimes from an unknown account, sometimes from a hijacked friend’s account, sometimes posted in a chat as an apparent project announcement. The text promises an airdrop, an NFT mint, bonus TON for “verification”, access to a private staking pool. Attached is a button or link, and that link is a ready-made TON Connect deep link that immediately opens the wallet with a pending connection request.

The hazard is that the user often does not register what just happened. Tap the button, the wallet takes over, the screen reads “Connect to AirdropClaim?”, muscle memory kicks in, Confirm. Session established. Seconds later the dApp dispatches a sendTransaction request with a polite “claim reward” label. The user signs — and the signed transaction goes to the attacker.

Address-bar verification does not save you here because you were never in a browser. The defence is a rule: never connect to a dApp you arrived at through an unsolicited message. If somebody pings you about an airdrop, go to the project’s official site yourself through search or a bookmark and check whether the airdrop is real. Nine times out of ten it is not.

Vector 4: persistent session abuse (the forgotten connection)

The sneakiest vector, because the attack can land weeks after the initial handshake. The user once connected to a throwaway dApp — to test an airdrop page, look at an NFT mint, try a new DEX. The connection went through, no transactions were signed, the page was closed, the whole thing forgotten.

The session, however, lives on inside the wallet as active. Days or weeks later a sendTransaction request surfaces from a dApp the user can no longer place. Surprise plays a role here: the user sees the notification, assumes it is some background wallet process, and taps Confirm without reading. If the dApp was malicious from the start, or its infrastructure was compromised later, it now collects a free signature at the moment the victim was least prepared.

The same bucket holds half-legitimate projects that later changed hands, sold their userbase, or were breached outright. A connection opened with one team works for whoever ends up holding the keys.

Defence: URL verification, revoke unused sessions, hot/cold split

A four-rule discipline that closes off most of what we just walked through.

1. Verify the dApp URL in the address bar before tapping Connect, especially when you arrived from a messenger or search results. Better still, bookmark the dApps you use regularly and always open them from there.
2. Do not copy-paste TON Connect URLs between devices. Scan the QR directly — that is the one path clipboard malware cannot intercept.
3. Clean the active-session list in your wallet monthly. In Tonkeeper it lives under “Active Sessions”; in MyTonWallet under “Connected dApps”. Anything you have not actively used in the last two weeks, revoke.
4. Segregate wallets by risk. One wallet is cold, holds your main funds, never connects to experimental dApps. A second wallet is hot, holds a small operating balance, expendable in the worst case. Connect only the hot wallet to airdrop pages and new projects.

What to do if you already signed something bad

Rollback is impossible — TON is a final chain. Damage control, however, is possible if you act in the first minutes.

1. Revoke every active session in the wallet immediately. It will not stop the transaction already on its way, but it prevents the attacker from finishing the job through follow-up prompts.
2. Create a fresh wallet from a new seed on a clean device. Moving the remaining balance there is priority one; do it before you start investigating how the attack worked.
3. Do not engage with any “recovery service”. Every message offering to retrieve stolen funds is the second wave of the same scam. Genuine recovery tools for final blockchains do not exist.
4. Document the incident: save the URL of the fake dApp, the transaction hash of the drain, screenshots of the announcement or DM. This feeds community scam-address lists and warns others.
5. Audit your other accounts. If a clipboard stealer or a Telegram phishing session was involved, check that the same malware did not also pick up credentials to other services.

Closing thoughts

TON Connect is a good protocol, but it secures only the cryptography of the connection — not the discipline of the user. The signature still belongs to a human, and attackers target precisely that Confirm tap. The four vectors above exploit no flaw in the protocol itself; they exploit inattention, habit, and trust in a familiar interface.

A few minutes a month to revisit your active sessions, a habit of checking the URL, a hot/cold wallet split, and a rule against inbound-link connections shut down most of what we see in the wild today. That is far cheaper than rebuilding your on-chain life from a brand-new seed.