We watched an attacker replay a stolen Telegram session in 140 milliseconds

The attack that has no login screen

Most account-takeover advice assumes there is a login to defend: a password to strengthen, a code not to share, a 2FA prompt to approve or deny. The Telegram takeover that has been draining accounts has none of that.

On Telegram Desktop, your logged-in state is stored in a folder named tdata. Inside it is the long-lived credential that proves your identity to Telegram's servers. Anyone who copies that folder copies your session. Infostealer malware, delivered through fake job interviews, trojanized meeting apps, and cracked software, does exactly this. It is a plain file in a normal user folder, so no administrator rights and no exploit are required.

When the attacker drops your session into their Telegram Desktop, Telegram does not see a new login. It sees the authorization you already created. That is why there is no warning. Password, login code, and 2FA all live at the front door, and this attacker walked in through a copied key to a door you already opened.

What we tested

To understand what a victim can actually detect, we built a lab that clones a real session and watches every field Telegram exposes about an authorization. We ran the decisive trace against an official Telegram Desktop client, the genuine desktop app, not a third-party library, because attackers use the real client to stay invisible. We then ran two sessions of the same account in parallel from two different places and recorded which signals moved.

Three findings came out of it. All three are things a defender can verify, and they sort cleanly into forgeable and not forgeable.

Finding 1: the client identity is useless as a tell

A popular idea is that you can spot a fake session by its client or API identity, because automated replay tools often use a recognizable library. That only catches lazy attackers. When we cloned the official desktop client, the client identity was identical to a legitimate session. There was nothing to flag. Any defense that leans on this looks like a bot client misses the attacker who simply uses the real app.

Finding 2: the device name is attacker-controlled text

The device and app labels you see in Telegram's Active Sessions list are not verified facts. They are fields the client reports, and an attacker can set them to match yours. A one-way attacker who changes that label can be noticed, but a careful one who copies your label cannot be told apart by name alone. Treat that list as a hint, not as ground truth.

Finding 3: two live sessions at once is the signal that cannot be faked

Here is the part an attacker cannot engineer away. When the real owner and the cloned session are both genuinely active, the account is being driven from two places at the same time. Telegram's own server-maintained liveness for each session reflects this, and it is not something the client gets to fabricate, because it is the server, not the app, that records when a session was last truly alive.

In our concurrent run, the same account was live from two distant locations at once and produced a contention pattern that no single real user could create. You cannot be in two far-apart places, both actively online, in the same instant. That impossibility is the whole point. The attacker can forge their client, forge their device name, and route through any country, but they cannot make the account stop being used in two places at once while both are live. The forgeable signals are noise. This one is signal.

The 140-millisecond number

Telegram does have a backstop for this. When two sessions sharing one key are used hard enough at the same time, Telegram eventually trips its own AUTH_KEY_DUPLICATED protection and logs both out. The catch is the word eventually. It is a blunt, delayed safeguard, and in the gap before it fires the attacker can read, message your contacts, and drain whatever the account controls.

When we validated detection of the contention signal directly, the takeover signature surfaced on the very first poll after the cloned session went live, on the order of 140 milliseconds, well ahead of Telegram's duplicate-key safeguard. The difference between a response measured in milliseconds and one measured in however long a blunt safeguard takes to notice is the difference between an attacker who gets nothing and one who gets your account for as long as it takes.

Why this matters for protecting yourself

Three practical conclusions follow from the lab data.

• You cannot rely on a login warning, because there is no login. The attack is a copy of an existing session, so the entire category of alert me about new sign-ins is blind to it.
• You cannot rely on the Active Sessions list to identify the attacker. The client identity and device name in that list are forgeable. A careful attacker looks like you in it.
• You can rely on the physics of contention. Two provably live sessions using one account at once is the one thing a takeover cannot hide, and it is detectable fast enough to act on.

The standard advice still applies and you should follow it: enable Telegram Desktop Local Passcode, keep 2FA on, and never run software from an untrusted source. But understand the limits. Local Passcode is off by default, desktop only, and only protects the folder while Telegram is locked. None of the prevention advice helps once a session is already stolen and being replayed. For that, you need something watching for the contention signature and ending the attacker's session the moment it appears.

How Sessions uses this

Sessions is a non-custodial Telegram guard built on exactly this finding. It does not depend on forgeable client details. It watches for the takeover signatures that cannot be faked, two live sessions at once and impossible movement between places, and it ends the attacker's session in real time. It runs in an attested enclave, cannot read your messages or move your funds, and publishes the code that runs it so you can check that claim rather than trust it.

If you want the practical version of what to do when this has already happened to you, read why terminating your sessions does not log the hacker out.