Telegram Bot API Abuse

Telegram’s Bot API is now a common covert channel for threat actors, from phishing kit operators to state-linked activity. Its structural appeal is clear: a simple HTTPS interface, strong domain reputation, and no attacker-controlled infrastructure required. Many implementations embed recoverable bot tokens and chat identifiers in HTML, JavaScript, or binary payloads.

Using Netlas, we searched for web infrastructure that combines API interactions with a Telegram bot with executable delivery mechanics. This approach found two main clusters: Xeno-branded download pages impersonating or using the Xeno name to deliver malicious payloads, and an Adobe-themed fake update kit distributing ZIP, MSI, and EXE files. Both clusters were identified using the same behavioral query pattern.

Both clusters show consistent technical patterns. These include browser-side victim profiling, sendMessage-based telemetry, and countdown-delayed executable delivery. Such behaviors are stable detection anchors. They persist across infrastructure changes and help defenders find malicious activity, even without file hashes, domains, or other temporary indicators.

Introduction

Multiple independent studies document how actors abusing the Telegram Bot API sustain continued growth in both phishing and malware campaigns.

Forescout’s analysis of phishing infrastructure between 2020 and 2025 identified thousands of domains incorporating Telegram Bot APIs, with a sharp increase in campaigns combining these APIs with front-end hosting platforms such as r2, Vercel, and Netlify. The same study observed notable reuse of bot tokens across domains, indicating infrastructure reuse and campaign continuity.

A Cofense report shows that Telegram is common in malware and credential-phishing activity. This is frequent among infostealers and keyloggers, where it serves as an exfiltration or control channel.

These findings confirm that adversaries use Telegram Bot API as a persistent and growing component of their tradecraft, not as an isolated or opportunistic technique.

Why “api.telegram.org/bot” is the Primary Hunt Surface?

Every Telegram Bot API interaction follows a consistent structure:

api.telegram.org/bot<TOKEN>/METHOD

This pattern is embedded directly in phishing kits’ JavaScript, stealer configurations, scripts, and compiled binaries, typically accompanied by bot tokens and chat identifiers that define the operator’s collection channel.

Because the API operates over standard HTTPS to Telegram-controlled infrastructure, outbound communication blends with legitimate traffic and often bypasses controls that rely on domain reputation or allowlisting.

Importantly, api.telegram.org/bot is not a typical indicator of compromise but a stable behavioral artifact of Telegram-based operations. While bot tokens can be regenerated, they are frequently reused in practice, making the pattern persist across kit variants and campaign iterations. As a result, it can be reliably recovered from multiple telemetry sources, including HTTP response bodies, proxy logs, network captures, and static code analysis.

Telegram Bot API as an Offensive Primitive

Telegram exposes two distinct interfaces. MTProto handles messaging between Telegram clients over Telegram’s native protocol and infrastructure. The Bot API is a separate HTTPS-based REST interface hosted at api.telegram.org, accessible to users who register a bot and obtain a token via @BotFather. Interactions such as sending messages, uploading files, or polling for commands are performed through authenticated HTTPS requests of the form:

https://api.telegram.org/bot<TOKEN>/METHOD_NAME

This design removes the need for attacker-controlled infrastructure. No custom protocol or dedicated server is required. In typical usage, there is no certificate management overhead. Any environment capable of issuing HTTPS requests — such as browser-based JavaScript, PowerShell scripts, Python code, or compiled binaries — can use the Bot API as an exfiltration or command channel.

Because communication ends at Telegram-controlled infrastructure, attackers blend their malicious traffic with legitimate flows and inherit the trust of a widely used platform, instead of relying on attacker-operated domains.

Structural OPSEC Weakness: Hard-coded Tokens

The Bot API requires a token in each request, most commonly embedded directly in the request URL. In observed phishing kits and malware, bot token and chat identifier values are exposed in plaintext within HTML, JavaScript, or compiled payloads. For example, Forcepoint’s analysis of a Cloudflare R2-hosted kit shows BOT_TOKEN and CHAT_ID defined as static JavaScript constants, while NVISO documents the same pattern across Raven Stealer, DeerStealer, and XWorm. This is not an incidental implementation detail — it is a direct consequence of the API design interacting with low-friction attacker tooling.

This creates the following practical opportunities for defenders:

• Token extraction enables clustering: The extracted tokens can be used to hunt malicious infrastructure sharing the same token even when domains and hosting rotate.

  Forescout’s analysis of phishing infrastructure shows that a substantial portion of extracted tokens are reused across multiple domains, reflecting an operational tradeoff where persistence and convenience outweigh strict token rotation. In practice, this makes the token a durable pivot: a single recovered value can link otherwise unrelated infrastructure and provide continuity across campaign iterations.

• Second, token interrogation provides limited but actionable context. Sending requests to the getMe API method checks whether the token is valid and returns information about the bot itself, while using the getUpdates API method may reveal identifiers for chats the bot is in or recent messages, depending on the bot’s current status and when the request is made.

Weaponized API Methods and Their Roles

Three Bot API methods account for all documented malicious Bot API usage, each mapping to a distinct phase of the attack lifecycle.

Method combinations provide a useful triage signal. sendMessage-only presence maps to phishing kits and download logging. sendDocument added indicates stealer archive upload. getUpdates in the mix indicates bidirectional C2, not just outbound exfiltration.

Telegram Bot API Abuse Observed in Real-World Operations

Phishing and HTML-based credential theft are the most common abuse patterns. Forcepoint documents a Cloudflare r2-hosted phishing kit where client-side JavaScript validates submitted credentials, enriches them with IP address and browser metadata, and forwards the payload to a Telegram bot via AJAX. In some cases, a secondary bot is used in parallel to collect visitor telemetry. Forescout reports that campaigns frequently leverage free hosting platforms such as *.r2.dev, *.vercel.app, and *.netlify.app, minimizing reliance on attacker-controlled infrastructure beyond the Telegram channel. Cofense observes credential phishing pages exfiltrating data directly via sendMessage requests, with collection and transmission occurring entirely client-side.

Stealer and RAT ecosystems extend this model across post-compromise activity. NVISO research highlights multiple malware families — including DeerStealer, Raven Stealer, Lumma Stealer, and trojanized XWorm builders — using the Bot API for execution beaconing, credential exfiltration, and tasking. Techniques include command polling via getUpdates, file exfiltration via sendDocument, and HTTP-based API interaction from native binaries or scripts. Cofense reporting further indicates that commodity malware such as Agent Tesla and WSH RAT increasingly incorporates Telegram-based exfiltration alongside traditional channels, with some variants triggering operator notifications at key execution points. Additional samples demonstrate the use of Telegram-hosted or Telegram-referenced content within multi-stage delivery chains.

Recommended Reading

Hannibal Stealer: A Deep Technical Analysis

State-linked operations apply similar mechanisms at higher levels of targeting and operational control. Unit 42’s documentation of IRRAT and TeleRAT establishes early use of the Bot API for command dispatch and data exfiltration in mobile malware campaigns, combining sendMessage, getUpdates, and sendDocument in a structured workflow. More recent public reporting has linked APT42-associated tooling, including the TAMECAT PowerShell backdoor, to Telegram-based C2 patterns involving encrypted data exfiltration. A March 2026 FBI FLASH further describes Telegram bot usage in operations attributed to MOIS-linked actors targeting dissidents and journalists, with reported objectives including intelligence collection and data exposure.

Across these cases, the underlying API usage remains consistent, demonstrating that Telegram Bot API abuse is not confined to a specific threat tier but represents a shared operational pattern across both opportunistic and targeted activity.

Case Study: Xeno Executor Discovery

Figure 1. Xeno-themed delivery page

The following Netlas query was used to hunt for pages that combine Telegram Bot API calls and serve as malware-delivery infrastructure.

http.body:"api.telegram.org/bot" AND http.body:("setTimeout" OR "setInterval") AND http.body:("download" OR "href=") AND http.title:("Download")

The query isolates the convergence of the following behaviors: Telegram-based communication, staged execution via timing functions, and user-facing download mechanisms. This combination is designed to surface client-side delivery infrastructure where telemetry and payload distribution are likely coupled within a single execution flow.

The query returned two IPs: 144.31.238[.]243 and 144.31.221[.]235 (Figures 2 and 3).

Figure 2. Netlas results for 144.31.238[.]243

Figure 3. Netlas results for 144.31.221[.]235

Both served Xeno-branded download pages that contained hardcoded Telegram tokens and chat identifiers.

IP address: 144.31.238.243
Bot token: 834778 7865:AAFH6B85-y4nqgW_YtkSaeEJY_VKF7ZpQ1A
Chat ID: -1003829867581
Domain: xeno.rest
CAPTCHA: Cloudflare Turnstile

IP address: 144.31.221.235
Bot token: 8233552495:AAEfbL0sZvJEXjVgptIOvtkEyU3mIzZl6dk
Chat ID: -1003611197863
Domain: None identified
CAPTCHA: None

Infrastructure Analysis

The two hosts present the same Xeno-themed lure but behave like separate builds rather than a shared deployment.

144.31.238[.]243 is logically linked to xeno[.]rest via hardcoded references in page source. The page source hardcodes const SITE_URL = "xeno.rest". Telegram notifications also reference the same domain string. At the time of collection, xeno.rest had 14/94 detections while the IP itself was still clean (Figures 4, 5, and 6).

Figure 4. VirusTotal detections for xeno[.]rest

Figure 5. Bot token pivot for 144.31.238[.]243

Figure 6. VirusTotal score for 144.31.238[.]243

144.31.221[.]235 doesn’t carry any of that branding. No og:url tag/metadata, no SITE_URL, no external references. The implementation is also stripped down: no Turnstile challenge, no session timing, no screen resolution capture, no localStorage counters. It resolves IP and geo in a single step via ip-api.com and pushes the result straight to Telegram. Functionally, it does the same job, just with less instrumentation (Figures 7 and 8).

Figure 7. Bot token pivot for 144.31.221[.]235

Figure 8. VirusTotal score for 144.31.221[.]235

Both hosts embed bot tokens directly in client-side code and use them immediately on interaction. The tokens differ across the two, and a pivot on each did not return additional infrastructure in Netlas at the time, which supports treating them as separate instances rather than a shared cluster (Figures 9 and 10).

Figure 9. Token pivot results for 144.31.238[.]243

Figure 10. Token pivot results for 144.31.221[.]235

Code Level Behavior

144.31.238[.]243

Figure 11. Source code view for 144.31.238[.]243

• The page is fronted by a Cloudflare Turnstile challenge. Content is present in the DOM but not exposed until the callback fires, so anything scraping without executing the widget won’t see the delivery logic. There’s no conditional branching behind it — just basic gating to keep scanners out (Figure 11).
• Telegram is wired directly into the page script. Bot token and chat ID are hardcoded and used as-is; no encoding or indirection. Everything runs client-side.
• On click, the page collects a minimal but sufficient set of context before doing anything else. It pulls an IP via api.ipify, enriches with ipapi, then builds out the rest from the browser — UA, language, screen, referrer, plus a simple session timer. Nothing unusual in isolation, but the sequencing matters: collection happens before delivery every time.

Figure 12. Victim-tracking logic for 144.31.238[.]243

• There’s also some light client tracking via localStorage (xeno_downloads, xeno_today). It’s basic counters with date reset logic (Figure 12).
• Telegram Exfiltration: Once the data is assembled, it’s sent straight to the Bot API (/sendMessage) as a GET request. The message includes the victim context and the local counters, so the operator gets immediate visibility into who clicked and from where. No backend involved — Telegram is the only sink.
• Payload Delivery: After that, the download fires. The script creates an anchor pointing to /newfiles/Xeno-v1.3.25b.exe and triggers it programmatically. There’s no delay, no redirect chain — telemetry goes out, then the binary is served immediately from the same host.

Using the hardcoded bot token and chat ID extracted from the page, the message interception was performed via Matkap. This provided direct visibility into messages received by the operator (Figures 13 and 14).

Figure 13. Matkap interception view for 144.31.238[.]243

Figure 14. Intercepted Telegram messages for 144.31.238[.]243

The observed messages align with the client-side telemetry logic. Each interaction with the page generated a structured notification containing:

• Source site reference (xeno[.]rest).
• Delivered payload filename (Xeno-v1.3.25b.exe).
• External IP and geolocation information.
• Browser, OS, referrer information.
• Total number of downloads.

144.31.221[.]235

• No access gating — page content and logic are fully exposed in the initial response.

Figure 15. Victim-tracking logic for 144.31.221[.]235

• On user interaction, the page collects basic victim context (IP, country, browser, OS, language, referrer) and transmits it to the Telegram Bot API via a POST request (Figure 15).
• Payload delivery is tied to the same interaction. After telemetry is sent, the script triggers a redirect to: /downloads/Xeno-v1.3.25b2.exe using a short (~1.8s) delay before execution.

A similar Matkap message interception analysis was performed using the extracted hardcoded token and chat ID. Retrieved messages confirm active telemetry aligned with the delivery infrastructure (Figure 16).

Figure 16. Matkap interception view for 144.31.221[.]235

The message content is framed as an execution/installation event (УСТАНОВЛЕН), with trigger point not observable from analyzed telemetry.

Compared to 144.31.238[.]243:

• No referrer or source attribution.
• No session timing or interaction counters.
• Reduced telemetry scope (basic host context only).
• Consistent use of Cyrillic formatting.

Network Analysis of Xeno[.]rest Domain

Figure 17. DNS telemetry linking xeno[.]rest and xeno[.]onl

The network telemetry associated with xeno[.]rest shows DNS requests to xeno[.]onl and www.xeno[.]onl domains, indicating a linked domain cluster rather than an isolated deployment (Figure 17).

Figure 18. VirusTotal score for xeno[.]onl

Pivoting on xeno[.]onl surfaces multiple communicating files to the same naming convention observed in the delivery pages (Figures 18 and 19).

Figure 19. Files linked to xeno[.]onl in telemetry

Notably, Xeno-v1.3.25b.exe and Xeno-v1.3.25b2.exe appear in VirusTotal telemetry. Xeno-v1.3.25b.exe is classified by multiple engines under Salat stealer families (e.g., TrojanPSW/Salat variants; Figure 20).

Figure 20. VirusTotal classification for Xeno-v1.3.25b.exe

These filenames directly match the payload references embedded in the response bodies of 144.31.238[.]243 and 144.31.221[.]235, establishing a concrete linkage between:

• Delivery infrastructure (bare IP hosts).
• Branded domain layer (xeno.rest).
• Secondary distribution domain (xeno.onl).
• Payload artifacts observed in the wild.

The detection disparity between the two samples, combined with consistent naming and shared distribution surface, indicates iterative payload versioning under active development rather than static commodity malware reuse.

MITRE ATT&CK Mapping — Xeno Executor Delivery Infrastructure

Case Study: Adobe Impersonation Using a Telegram-Instrumented Delivery Kit

Initial discovery came from a brand-constrained query combining Telegram Bot API usage with common lure themes:

http.body:"api.telegram.org/bot" AND http.body:"sendMessage" AND http.title:(docusign OR adobe OR invoice OR payment OR dhl OR fedex)

The query results surfaced 64.89.163[.]64. Response body inspection revealed a fully functional Adobe Reader impersonation delivery page with Telegram exfiltration infrastructure present in source — but with the bot token and chat ID fields left empty and enabled: false. The Telegram integration is present but not operational. Despite this, the full telemetry routine is implemented — device fingerprinting (user-agent, platform, screen resolution, timezone), external IP resolution via api.ipify.org, and structured message formatting for sendMessage. The absence of active credentials indicates either an incomplete deployment or the reuse of a template in which Telegram configuration is injected later (Figures 21 and 22).

Figure 21. Netlas query results for 64.89.163[.]64

Figure 22. VirusTotal score for 64.89.163[.]64

Pivoting to the same pattern using the following query surfaced a second host, 38.240.57[.]3, a structurally similar Adobe impersonation page with fully configured Telegram exfiltration (token dead at time of analysis).

http.body:"api.telegram.org/bot" AND http.body:"sendMessage" AND http.body:"adobe"

Delivery is automated via a timed trigger (setTimeout ~5s), which initiates the download of Adobe_Update_V32-38.zip followed by a redirect. OS-based filtering is enforced via navigator.userAgent, restricting execution to Windows systems and suppressing non-target environments (Figures 23 and 24).

Figure 23. Netlas pivot results for 38.240.57[.]3

Figure 24. VirusTotal score for 38.240.57[.]3

Telemetry is executed on page load — IP is resolved (api.ipify.org / ipapi.co fallback), geolocation is enriched via ip-api.com over HTTP, and a formatted message containing IP, location, URL, filename, and timestamp is sent via sendMessage. This occurs before payload delivery, providing immediate operator visibility into victim interaction.

Infrastructure

The two hosts share a common kit template — identical lure texts and the identical “Access Restricted / This resource is only available for Windows devices” mobile block message — but run on separate server stacks with independent deployment timelines.

64.89.163[.]64

Payload:

RFQ__9bbe0906198a4d108e620daf422379fe.exe

Body SHA256:

0901af26f5f05184d233032d09325874153cf27848d4e77e2c6b568cacaa5c88

38.240.57[.]3

Payloads:

Adobe_Update_V32-38.zip
Adobe_Reader_V62-38-28.msi

Body SHA256:

e460d6962b259d9a58b2b9695d633165e5cfa57fc722f290539609ddbb29d2eb

The enabled: false configuration on 64.89.163[.]64 has two plausible interpretations: the operator has not yet activated this deployment, or the tokens/chat ID were removed after the initial setup for OPSEC — leaving the delivery infrastructure live while decoupling it from the exfiltration channel. Either way, the Telegram infrastructure code in the source confirmed the intended collection mechanism and made the host discoverable via http.body search despite the channel being inactive (Figures 25 and 26).

Figure 25. Dead Telegram token check

Figure 26. Matkap view for the inactive Telegram token

The dead token on 38.240.57[.]3 exhibits the same pattern in reverse: the exfiltration channel was active and has since been shut down, but the delivery page remained live and indexed.

Book Your Netlas Demo

Chat with our team to explore how the Netlas platform can support your security research and threat analysis.

Pick a Time

Proactive Infrastructure hunting with Netlas

Reputation-based tooling was unlikely to surface this at the time of discovery. Both delivery IPs (observed in Xeno case study) were clean (0/94 on VirusTotal), and neither had prior submissions — passive coverage provided no signal.

What enabled discovery here is that Netlas indexes HTTP response bodies at internet scale without requiring a predefined target. The relevant logic in these pages — including hardcoded bot tokens, client-side telemetry collection, and delivery mechanisms — is exposed directly in static page source. This makes the http.body field a direct content-based query surface against the operator’s implementation pattern, independent of domain reputation or IP history.

Once the initial hosts were identified, the same surface supports pivoting on extracted bot tokens and shared JavaScript patterns, enabling identification of related deployments and redeployments ahead of reputation-based detection.

Query Design Principles

The query design here is anchored to the Bot API string, which appears verbatim in the page source. Starting point was:

http.body:"api.telegram.org/bot"

That alone pulls back a wide set of results, but it’s noisy unless you strip out Telegram-owned infrastructure (telegram.org, t.me). What’s left is almost entirely third-party pages embedding the API directly.

From there, method strings can help with triage. Adding sendMessage, sendDocument, or getUpdates methods provides a hint at how the bot is being used. In practice, sendMessage shows up across everything — phishing kits, loaders, basic telemetry. getUpdates is less common and worth prioritizing when it appears, but still needs validation.

The real reduction comes from layering context. Titles and body fragments cut this down quickly — anything referencing downloads, updates, or executables alongside timing functions (setTimeout, setInterval) consistently surfaces delivery pages. Domain patterns help as well: highly-abused TLDs (e.g., .xyz, .top, .online, .site) and free hosting platforms (e.g., *.r2.dev, *.pages.dev, *.vercel.app, *.netlify.app) show up repeatedly, but they’re supporting signals, not anchors.

Net effect is a three-step filter: anchor on the API string, use method names to prioritize, then apply context to isolate delivery infrastructure. That sequence is what surfaced both hosts without relying on reputation or prior indicators.

Netlas Hunt Queries To Explore

The following queries can provide a starting point for identifying and exploring Telegram Bot API-driven adversary infrastructure in Netlas.

Query 1:

http.body:"api.telegram.org/bot" AND http.body:"sendMessage" AND http.body:"chat_id"

Detects: Common pattern observed in Telegram-based phishing kits and telemetry scripts, where credentials or victim context are sent via sendMessage using a chat_id parameter.

Query 2:

http.body:"api.telegram.org/bot" AND http.body:("getClientIP" OR "ipify.org" OR "ip-api.com" OR "ipapi.co")

Detects: Identifies pages performing client IP resolution and geolocation enrichment — commonly observed in phishing kits.

Query 3:

http.body:"api.telegram.org/bot" AND http.body:"navigator.userAgent" AND http.body:"Windows"

Detects: Windows-specific malware distribution with OS restriction checks. navigator.userAgent is the JavaScript property for browser detection.

Query 4:

http.body:"[api.telegram.org/bot](http://api.telegram.org/bot)" AND (http.title:"Adobe" OR http.title:"Microsoft" OR http.title:"Update")

Detects: Brand-based phishing lures (Adobe, Microsoft, etc.)

Query 5:

http.body:"api.telegram.org/bot" AND http.headers.server:"cloudflare"

Detects: Cloudflare-proxied phishing infrastructure hiding origin servers.

Detection and Response Strategies

Network / Proxy Layer: Monitoring proxy logs for api.telegram.org/bot is a primary detection method. Separately, watch for outbound HTTP (port 80) to services like ip-api.com. These are used for IP enrichment before exfiltration and are consistently present across samples. Blocking them doesn’t break the flow, but it removes useful context from the operator side.

Endpoint / EDR: Bot API calls may originate from either client-side code (browser JavaScript in phishing pages) OR native processes (malware, scripts). Monitor both browser network activity and scripting engine connections to api.telegram.org.

Bot Tokens (Operational Use): Tokens exposed in page source are usable as-is. getMe confirms the bot, getUpdates pulls message history. That gives you direct visibility into what’s being collected and when. Treat this as controlled access — it’s effectively stepping into the operator’s channel. Recommended: Report to Telegram (@notoscam) for revocation.

Blocking: If Telegram isn’t needed, block it outright at the perimeter. If it is, restrict access and monitor Bot API usage specifically. The traffic pattern is distinct enough to separate from normal Telegram use.

Proactive Hunting: The patterns hold across variants — Bot API string in body, some form of IP lookup, and a delivery trigger. Running content-based queries against those elements consistently surfaces new nodes. This is where Netlas is useful — you’re querying the implementation, not waiting on reputation.

Conclusion

Across the hosts we analyzed spanning two distinct clusters, the delivery architecture is consistent: Windows-only session filtering, client-side telemetry collection, setTimeout-gated payload delivery, and Telegram Bot API infrastructure embedded in static page source — with minor implementation variation between deployments. The Xeno and Adobe clusters differ in their lure themes, target audiences, and payloads. The underlying kit structure does not.

That consistency defines the hunting surface. api.telegram.org/bot appears directly in page source regardless of lure context, and the surrounding logic — IP resolution, sendMessage dispatch, and timed delivery — is observed consistently across deployments, enabling behavioral queries independent of domain names, hashes, or IP reputation. The two Xeno hosts had clean VT scores at discovery; the Adobe hosts had VT scores of 6/94 and 2/94, respectively, below operational detection thresholds. The hosts were identified via http.body search prior to meaningful reputation coverage at the IP layer and would be unlikely to surface through feed-dependent controls at that stage.

This pattern extends beyond the observed nodes. Various threat intelligence reports document the same Bot API–driven mechanism across phishing, stealer delivery, and command-and-control workflows, reinforcing that api.telegram.org/bot in response body content represents a consistent detection and hunting surface across multiple threat contexts.

I can show you how deep the Internet really goes

Discover exposed assets, infrastructure links, and threat surfaces across the global Internet.

Request Free Trial Explore Free Plan