SessionSerpent phishing kit
SessionSerpent is our name for modified Telegram Web pages that collect reusable browser session state and contacts. We have matched it on 1,596 sites since 2 August.
SessionSerpent in numbers
Since 2 August, the first SessionSerpent match in our records, counted on 12 October 2026. How we count.
| Sites with SessionSerpent code | 1,596 |
|---|---|
| Sites with a match in the last 30 days | 765 |
| New sites in September | 750 |
| Sites captured since 25 September | 237 |
A working Telegram client with extra collectors
SessionSerpent is our name for Telegram Web copies that keep enough of the real client to complete a login. The visitor enters a phone number, the login code sent by Telegram and a two-step password when the account requires one. The page uses those values to authorize its browser session, then reads the session material the client created.
A captured build stores the signed-in user as user_auth. Per-data-centre entries carry _auth_key, _hash and _server_salt. The page converts the authentication key to hexadecimal and sends it with the phone number, user ID and two-step password to one collector.
It then reads contacts from Telegram's tt-data IndexedDB database. Contacts with phone numbers are sent to a second collector with their names, usernames, account IDs and status fields. The fake interface appears in English, Chinese or Vietnamese while this collection happens behind it.
Session and contact uploads take separate routes
The paired collectors are a recurring part of the family, although their paths change between deployments. Captures use routes under /api/telegram/, /customer/up/info, /prod/index/cache, /api/index/ and /telegram/. Requests can carry selected session fields, the entire local-storage object or a separate contact payload.
Some copies use ordinary JSON POST requests. Others add navigator.sendBeacon so the browser sends stored state when the page becomes hidden or closes. Agent identifiers and fields such as agentcode connect the page to its operator configuration.
WebAssembly hides the page before it opens
A later wrapper makes the initial response look like a small loading page. It contains a Base64 WebAssembly module and a second encoded byte array. JavaScript instantiates the module, copies the encoded page into its memory, calls the exported decoder and replaces the current document with the result.
After that rewrite, the browser displays the same Telegram interface and loads the session and contact collection code. This creates two useful artefacts: the WebAssembly loader in the first response and the browser-storage access in the decoded page.
Other builds restore operator-supplied session values into local storage or IndexedDB before opening the client. Those copies clear the existing browser state, write the supplied records and reload the Telegram interface around them.
What we see
| Month | New sites |
|---|---|
| September | 750 |
| October so far | 189 |
Among successful captures since 25 September, 0 of 237 SessionSerpent sites ran WordPress.
Checking a SessionSerpent page
Inspect the response body, decoded scripts, browser storage and network log. Look for:
- a Telegram Web interface served outside Telegram's domains
user_auth,_auth_key,_hash,_server_saltor thett-datadatabase in added code- separate uploads for authentication state and cached contacts
sendBeaconcalls tied to page visibility or unload events- operator fields such as
agentcodeor configuration fetched by an agent ID - a Base64 WebAssembly module that decodes bytes and rewrites the document
Remove the page and each local collection route. Review the hosting and deployment accounts and rotate their credentials.