Inside a Telegram Session Stealer: How a Pastebin-Hosted PowerShell Script Targets Desktop and Web Sessions

By Sukant Kumar, Cybersecurity Researcher 

A PowerShell script titled “Windows Telemetry Update” sounds like the kind of routine system process most users would never question. This is exactly what the threat actor author was counting on. Flare flagged this Pastebin-hosted script as a high-severity threat, and our analysis revealed a purpose-built Telegram session stealer that targets desktop session data, exfiltrates it through the Telegram Bot API, and shares infrastructure with a separate web-based session capture tool. 

What makes this case instructive is not the sophistication of the tooling (it is minimal) but what the artifacts reveal: two collection mechanisms at different stages of development, hardcoded credentials that exposed the operator’s entire bot history, and a clear debugging trail from a broken first version to a functional second one. This is a capability caught in the validation phase, before operational deployment, offering a rare window into how session-stealing tools are built and tested.

Methodology

We analyzed a Pastebin-hosted PowerShell script disguised as “Windows Telemetry Update” that steals Telegram Desktop session data via Telegram bot API exfiltration. The script collects host metadata including username, hostname, and public IP via api.ipify[.]org, then checks for Telegram Desktop and Telegram Desktop Beta tdata directories. If found, it terminates the Telegram process to release file locks, archives session material into `TEMP\diag.zip`, and uploads the archive to the attacker-controlled operator chat via the Telegram Bot API sendDocument endpoint.

The research analyzed two script variants published on Pastebin, with the fixed version (v2) correcting a broken multipart upload implementation found in the initial version (v1). Hardcoded bot tokens in both the scripts enabled direct Telegram API response analysis and message history extraction via Matkap, revealed several bot messages documenting a separate web-based Telegram session capture capability sharing the same C2 infrastructure.

Key Intelligence Assessments

• Development State: The capability has passed functional validation but has not moved to scaled operational deployment.
  • Primary indicators from the Pastebin scripts: no obfuscation, clear-text credentials, broken v1 upload mechanism corrected in v2, no persistence. Corroborated by bot telemetry: local collector address (192.168.137.131:5000) referenced in web stealer notifications, sourced from bot message body text in Matkap export.
• Infrastructure Linkage: Two distinct session theft mechanisms (a PowerShell desktop stealer and a browser-based web stealer) share a common Telegram bot channel (`afhbhfsdvfh_bot`). No evidence of architectural integration beyond shared exfiltration infrastructure. 

Initial Discovery of Telegram‑Focused Stealer on Pastebin

Our initial intelligence lead originated from a Pastebin post titled “Windows Telemetry Update – Fixed version,” which Flare flagged as a “High” severity malicious PowerShell script masquerading as a Windows Update that is designed to steal Telegram application data. 

High severity event flagged on Flare (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

AI Assist summary on Flare describing the true intent of the Pastebin post (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

The title mimics legitimate Windows Update and telemetry service nomenclature, consistent with a naming convention intended to reduce suspicion during casual inspection.

Original Pastebin post (v2 script)

The script hardcoded two key identifiers inside the first three lines.

Hardcoded bot tokens

We immediately recognized this as a Telegram bot token and Chat ID. That gave us two immediate investigative paths: query the Telegram Bot API directly to enumerate the bot, and pull any existing C2 telemetry from the bot’s message history using Matkap. Both proved productive.

PowerShell Desktop Stealer: Technical Analysis

Script Overview

Looking at the script’s logic, it wasn’t going after credentials or browser data. It was specifically hunting Telegram Desktop session directories. The target paths are:

• appdata\Telegram Desktop\tdata
• appdata\Telegram Desktop Beta\tdata

Telegram Desktop’s tdata directory contains authorization keys used in Telegram’s MTProto protocol to authenticate the client with Telegram’s servers. These keys are:

• Long-lived: Generated at initial login and persists until manually revoked via “Active Sessions” or invalidated by Telegram security controls.
• Device-bound: Tied to the specific Telegram Desktop installation but portable if the tdata folder is copied.
• Credential-independent: Session access does not require the account password or SMS verification after initial setup.

Execution Flow

Step 1: Infrastructure Initialization

The bot token and chat ID are hardcoded and readable in plaintext, making them trivially extractable. This enables enumeration of messages the bot sent or received via getUpdates or message extraction/interception via the Matkap tool.

Step 2: Host reconnaissance

The script collects username, hostname, and public IP via api.ipify[.]org before any theft operation. Metadata embedded in the exfiltration caption provides immediate victim profiling.

Step 3: Target enumeration and branch gate

The script checks for both stable and Beta Telegram Desktop installations under $appdata. Matching paths are appended to the $paths array.

Key function – the branch gate:

$paths.Count -gt 0 is the single condition that controls the entire script: it proceeds only if at least one tdata path exists. Otherwise triggers the “No Telegram installation found” beacon.

Step 4: Process termination

The script forcibly terminates Telegram.exe to reduce file-lock conflicts on the directory prior to archival. The two second delay allows process termination and handle release to complete before compression begins. This behavior is consistent with awareness of Telegram Desktop’s file locking behavior and improves exfiltration reliability.

Step 5: Data archival

The script creates “diag.zip” in the user’s temporary directory containing all discovered tdata folders.

Step 6: Exfiltration (corrected in the later version i.e. fixed version – v2)

The bot API endpoint is built by injecting $t (token) into api.telegram[.]org/bot$t/sendDocument, targeting Telegram’s file upload method. A $form payload is assembled containing the operator’s chat_id, victim metadata as caption (username@hostname + IP), and “diag.zip” as the document.

Invoke-RestMethod -Form fires a multipart/form-data POST — the encoding Telegram’s API requires for file delivery. If that fails, a WebClient.UploadFile() fallback ensures the archive reaches the operator regardless, sacrificing the caption but preserving the file.

Step 7: Cleanup

The script deletes diag.zip post-upload to remove the forensic artifact from disk.

Step 8: No-Telegram beacon (v2 addition)

The script sends a notification even when no Telegram installation is found. This converts the script into a “host reachability probe,” guaranteeing operator feedback on every execution regardless of outcome.

Version Evolution: Debugging Evidence

Initial Version (v1): Upload failure

The Pastebin profile that posted the PowerShell script also had an initial version (v1). The implementation was observed to be fundamentally broken. Telegram’s “sendDocument” endpoint requires “multipart/form-data” encoding to accept file attachments. Using “UploadFile” with URL query string parameters and “application/x-www-form-urlencoded” content type results in failed uploads; the “diag.zip” archive never reaches the bot.

Screenshot of Initial version of script (v1)

Fixed Version (v2): Corrections

• Fixed multipart upload: Proper “Invoke-RestMethod -Form” usage generates correct “multipart/form-data” encoding
• Error handling: “try/catch” block with WebClient fallback.
• Execution telemetry: “No-Telegram” beacon ensures operator receives feedback even on empty-host run

Screenshot of fixed version of script (v2)

Analytical Assessment: This version (v1 to v2) transition evidences active testing, failure observation, diagnosis, and remediation: a characteristic debugging cycle. The operator executed v1, observed no “diag.zip” arriving in the bot chat, identified the multipart upload defect, and published a corrected version.

Comparative Note: The sendDocument zip exfiltration patterns mirrors Raven Stealer’s documented mechanism (NVISO, 2025). The technique is established in the infostealer ecosystem; the distinction here is scope. This tooling strips away multi-stage functionality in favor of Telegram-only targeting.

Telegram Bot Infrastructure

Bot Identity (`/getMe` Response)

Notable elements:

• Bot display name: “Telegram attacker,” explicitly adversarial self-identification, rather than obfuscation as a benign service.
• Username: “afhbhfsdvfh_bot,” a random character string suggesting automated generation.
• Group capability: “can_join_groups: true,” meaning the bot can be added to group chats if the operator expands delivery or access scope.

Infrastructure State (“/getWebhookInfo” Response)

• No webhook configured (`url: ””`): Bot does not push updates to any backend server.
• Pending updates imply that the backend consuming updates is dormant or absent at the time of analysis. Original server-side logic that processed bot messages is no longer actively polling.

Web Session Stealer: Observed Capability

Captured Evidence Analysis

We pulled several bot notification messages from the operator chat 8562222339 via the Matkap tool. Each message carries a structured JSON preview of what was captured, timestamp, an incremental session counter, and, in later captures, an auth key presence flag and a VPS routing confirmation.

Captured Messages via Matkap tool

The high value material sits in “localstorage.” Across majority of the captures, the message previews contained dc3_auth_key or dc4_auth_key values – 256 byte MTProto authorization keys that are the browser side equivalent of what the PowerShell module pulls from tdata.

Captured message containing DC4 auth keys

An attacker with these keys can reconstruct authenticated sessions. The notification flags them explicitly: “Contains DC4 auth keys!”

Captured message containing “dcId” and a per-account “dc4_auth_key”

Beyond auth keys, the stealer consistently captured “account1,” a JSON object containing “dcId” and a per-account “dc4_auth_key,” mirroring Telegram Web’s internal session structure.

Local HTTP collector

The stealer pushed data through two concurrent paths. Full JSON payloads (including complete auth key values) went to a local HTTP collector at http[:]//192.168.137[.]131:5000. Truncated summary notifications went to the bot chat.

Test Environment Indicators

Analysis of the exported captured messages suggests controlled testing rather than live victim exploitation.

• Uniform user agents: The captures across all exported messages carried an identical user-agent string (Mozilla/5.0 (Linux; Android 10; Mobile) AppleWebKit/537.36 Chrome/120.0.0.0 Mobile Safari/537.36). Any real deployment surfaces device diversity within the first few captures; a uniform user-agent across the entire dataset points to one browser and one operator, running controlled sessions.
• Repeating auth keys: Within each capture wave, the same key prefixes repeated across consecutive sessions. The stealer was firing multiple times against the same authenticated browser state, not across distinct victims. The key diversity across the entire dataset was consistent with a small number of controlled test accounts, not organic victim spread.
• Unbroken session counter: The session counter incremented without interruption across the full capture run with no resets and no gaps. Victim deployments reset per host; an unbroken counter reflects one continuous operator-controlled session. Mid-run, we observed the operator issuing /sessions queries, actively inspecting captures as the run progressed. That is deliberate inspection behaviour, not passive monitoring of a live campaign.
• Local collector address: The full payload channel routed to a LAN address. The operator’s own notification labels it a “VPS,” but a private IP is not an internet-routable address. That is a local test machine, not production exfiltration infrastructure. The full payload channel local collector address (i.e. 192.168.137[.]131:5000) removed any remaining ambiguity.
• Assessment: The homogeneity of user agents, auth key consistency, small URL diversity, and private collector address are collectively inconsistent with live victim activity and consistent with closed-loop operator testing against controlled accounts

Operational Timeline Analysis

The sequence below is reconstructed from bot notification messages extracted via Matkap interception of the operator’s bot history.

Infrastructure Linkage Assessment

Shared Infrastructure

We cross-referenced the PowerShell scripts against the bot message history and found binding identifiers consistent across the recovered artifacts:

• Bot token: Hardcoded identically in both script variants; present as the active credential in every extracted bot message.
• Operator chat ID: Hardcoded in both scripts as the sole chat_id recipient for all bot output; confirmed as the destination across all extracted notifications.
• Bot identity: afhbhfsdvfh_bot, display name “Telegram attacker,” resolved via /getMe against the hardcoded token.
• Operator association: PowerShell scripts tied directly to the Pastebin account used in this case; web stealer attributed to the same operator through shared bot credentials (we did not recover a separate Pastebin post for the web stealer component).

Architectural Independence

We found no cross-references between the two tools in either direction:

• PowerShell scripts: No reference to the HTTP collector, localStorage, browser session capture, or any web stealer component. Scoped exclusively to tdata archival and sendDocument exfiltration.
• Bot message history: No reference to sendDocument, diag.zip, tdata, or any desktop module artifact across all extracted notifications.
• No “sendDocument” events appear in bot message history (desktop module not observed executing within telemetry window).
• Exfiltration pathways: Architecturally distinct. The desktop routes “diag.zip” to the Bot API via “sendDocument;” web stealer POSTs full JSON payloads to a local HTTP collector and pushes truncated summary notifications to the bot chat separately; no shared code path between them.

These are two independent collection mechanisms using a shared Telegram bot as a common notification and data relay channel. The shared infrastructure represents operator convenience or resource reuse.

Operational Maturity Assessment

The tooling demonstrates functional capability. The fixed script variant (v2) correctly implements “sendDocument” exfiltration, the web stealer ran controlled capture sessions with auth key material and bot infrastructure remained operational at the time of investigation. What it has not done is transition to operational deployment.

The indicators that establish this are not individually conclusive, but they point in the same direction without exception. The scripts carry no persistence mechanism and no obfuscation. No automated execution or delivery mechanism is present in the script. The collector infrastructure is LAN-local. Taken together, this is a capability in active validation, not active use.

Indicators of Escalation

The following would signal transition from testing to operational deployment and should be treated as collection priorities:

• Obfuscated or encoded PowerShell variants of the script
• Bot token rotation, indicating awareness of exposure and active infrastructure management
• LAN-local collector replaced by an internet facing VPS address
• Automated loaders pulling scripts from paste URLs
• User agent or geolocation diversity in the web stealer captures, first indicator of real victim traffic\
• Migration from Telegram bot exfiltration to dedicated C2 infrastructure

MITRE ATT&CK Mapping

Detection and Defensive Guidance

Endpoint Behavioral Indicators

Endpoint command-line telemetry provides the most reliable detection surface for this toolset. The analyzed scripts contain no obfuscation, and critical indicators appear directly in PowerShell command-line arguments captured by EDR.

Typical execution chain:

1. PowerShell process launch.
2. Public IP lookup via api.ipify.org.
3. Host enumeration ($env:USERNAME / $env:COMPUTERNAME).
4. $appdata\Telegram Desktop\tdata reference.
5. Stop-Process targeting Telegram.exe.
6. Compress-Archive creating TEMP\diag.zip.
7. Invoke-RestMethod / WebClient call to api.telegram.org/bot*/sendDocument.
8. Remove-Item targeting TEMP\diag.zip.

While individual steps may occur independently, their combination forms a high-confidence malicious pattern.

Connections to api.telegram.org originating from scripting environments (PowerShell, Python, curl) are extremely rare in legitimate enterprise environments and should be triaged immediately.

Network Level Controls

Environments where Telegram is not permitted:

Block the following domains at proxy and firewall layer:

• api.telegram.org
• web.telegram.org
• telegram.org

This removes both the bot API exfiltration channel and the Telegram Web attack surface.

Environments where Telegram is allowed:

Monitor for:

• Non-browser processes communicating with api.telegram.org
• Telegram.exe connecting to api.telegram.org/bot* endpoints

Detection of specific bot API operations such as /sendDocument requires TLS inspection, as request paths and POST data are encrypted.

Without TLS inspection, rely on endpoint telemetry rather than network inspection.

Incident Response Protocol

• Immediate session revocation: If you suspect this script has been executed on your system, immediately terminate all active Telegram sessions through the Telegram application settings (Settings > Privacy and Security > Active Sessions > Terminate All Other Sessions). Change your Telegram password and enable two-factor authentication if not already active.
• Account review: Monitor Telegram account for any unauthorized activity, unusual messages sent from the affected account, or changes to account settings. Consider that any sensitive information previously shared through Telegram may have been compromised and take appropriate steps to secure related accounts or notify affected parties.

What Security Teams Should Understand About the Telegram Bot

Analysis of the PowerShell scripts posted on Pastebin and associated Telegram bot telemetry identifies a two-component Telegram session hijacking capability in development. Initial indicators suggested a potentially deployed stealer, but the recovered evidence instead reflects an operator still in functional validation. The PowerShell desktop module shows iteration between versions (an incomplete upload routine in initial script version (v1) and a corrected sendDocument implemented in fixed version in v2), while bot notifications show repeated session capture events consistent with controlled testing. The associated HTTP collector remained confined to a local address rather than public infrastructure.

Both components demonstrate functional capability. The desktop module targets Telegram Desktop “tdata” session material, while the web component captures MTProto dcX_auth_key values from Telegram Web “localStorage.” Either artifact enables Telegram session replay without requiring account credentials. No victim activity was observed within the available telemetry window.

Obfuscated script variants, bot token rotation, the collector moving to a public-facing address, or automated loaders pulling from paste URLs would shift this assessment from active development to active operations.

References and Sources

1. Initial Intelligence Lead: Flare Global Search (flare.io)
2. Original flagged Pastebin post: pastebin.com/wszjwj7q
3. Initial version of the malicious script: pastebin.com/3c1Qu0Hi
4. Pastebin profile posting PowerShell script: pastebin.com/u/abihacker
5. Telegram bot message interception: matkap.cti.monster
6. Telegram Bot API: /getMe response (bot identity)
7. Telegram Bot API: /getWebhookInfo response (infrastructure state)
8. MTProto Mobile Protocol (Telegram): core.telegram.org/mtproto
9. Raven Stealer Case Study: blog.nviso.eu/2025/12/16/the-detection-response-chronicles-exploring-telegram-abuse