Discord and Telegram Bot Tokens Security Guide: Protecting Bots and Spotting Abuse Channels

A Discord or Telegram bot token is a full credential for the bot account: whoever holds it can read what the bot can read, post as the bot to every community it serves, and in Telegram's case take over its webhook, and the same platforms are routinely used by malware to receive stolen data. Organisations meet these tokens from two directions. Community, support and engineering teams run bots for customers, alerts and ChatOps, often with tokens in a repository or a hobby server. Security teams find attacker bot tokens and webhook URLs inside infostealers and backdoors that send data to Telegram chats or Discord channels. This guide covers both: how bot identity and permissions work on each platform, how to scope, store and rotate tokens, how to secure webhooks, and how to detect your own leaked tokens and the abuse of these platforms as exfiltration and command channels. It is written for application owners, community platform teams, secrets management teams and SOC analysts. It follows the same pattern as the Slack Tokens Security Guide, applied to consumer messaging platforms.

Key takeaways

• Bot tokens have no scopes. On both platforms the token is the bot: limits come from Discord permissions and gateway intents, or from Telegram privacy mode and group admin rights, not from the token.
• Webhook URLs are secrets. A Discord webhook URL embeds its token and needs no other authentication; a Telegram webhook should be protected with secret_token.
• Ownership is a control. Put Discord applications in a team with 2FA-enforced members, and treat Telegram ownership transfer as irreversible, because the new owner gets the bot's messages.
• Detection is uneven. GitHub secret scanning has push protection and validity checks for Discord bot tokens, but Telegram bot tokens are detected only in private repositories with GitHub Advanced Security and without push protection.
• Egress to these APIs from servers is a signal. ATT&CK records the Telegram Bot API and Discord webhooks being used for exfiltration and command and control, so unexpected traffic to them from corporate hosts deserves investigation.

How identity and access work on Discord and Telegram

On Discord a bot is installed with scope=bot and a permissions integer, and applications.commands is included by default. The "Public Bot" setting controls whether anyone with the install URL can add it to a server. Three gateway intents are privileged: GUILD_PRESENCES, GUILD_MEMBERS and MESSAGE_CONTENT. They must be switched on in the portal, a connection that requests one without approval is closed with code 4014, and apps in 100 or more servers need verification to use them. These intents decide whether a stolen token can read message content and member lists, so they are the closest thing Discord has to token scope.

On Telegram, privacy mode means a bot in a group receives only commands addressed to it, replies to its messages and a few service messages; a bot that is a group admin, or has privacy mode disabled, receives every message. Telegram's guidance is to disable privacy mode only when absolutely necessary. A Telegram token stolen from a bot that is admin in internal groups therefore exposes those groups' history going forward.

Admin roles and privileged access

• Use Discord teams, not personal apps: 2FA is required to create or join a team, members get access to every app the team owns (up to 75 apps), and transferring an app to a team cannot be reversed, which also stops a leaver taking the bot with them.
• Treat Telegram ownership as a single point of failure: the owner account controls the token, and a transfer gives the new owner full control including access to the bot's messages. Hold it on an organisation account with strong login protection, and record who can use it.
• Validate in the backend: Telegram warns not to rely on command scope, because updates do not say which scope a command came from and users can send commands that do not exist. Authorise every command against the sender's ID server side.

Integrations, API tokens and service accounts

Storing and scoping bot credentials

• One bot per purpose and environment: production, staging and personal test bots should be separate applications or BotFather bots. Telegram recommends testing with a separate bot.
• Secrets manager, not code: inject the token at start-up. Discord also treats the OAuth2 client secret as private and warns against putting it in source code. See the Secrets Management Guide.
• Minimal Discord permissions and intents: build the install URL with only the permissions the bot uses and enable privileged intents only when needed; slash commands and interactions often remove the need for MESSAGE_CONTENT.
• Private by default: turn off "Public Bot" for internal Discord bots and disable "allow groups" in BotFather (/setjoingroups) for Telegram bots that should only talk one to one.
• Watch the session limit: Discord allows 1,000 IDENTIFY calls per 24 hours; exceeding it terminates all sessions and resets the token, with an email to the owner. A crash-looping deployment can therefore rotate your token for you, and a reset email you did not expect may also indicate the token is running somewhere else.

Webhooks

Discord channel webhooks have URLs of the form /webhooks/{id}/{token}. Discord's documentation says webhooks do not require a bot user or authentication: anyone with the URL can post messages with any username and avatar, read and edit messages sent through it, rename it or delete it. Store webhook URLs exactly as you store tokens, never paste them into front-end code or public CI logs, and delete and recreate a webhook that has leaked. ATT&CK notes that TeamPCP Cloud Stealer (S9041) searches compromised systems for Slack and Discord webhook URLs. The Webhook Secrets Security Guide covers the general pattern.

For Telegram webhooks set a secret_token (1 to 256 characters of letters, digits, underscore and hyphen) in setWebhook; Telegram then sends it in the X-Telegram-Bot-Api-Secret-Token header of every update, and your endpoint should reject requests without it. Webhooks must use HTTPS on port 443, 80, 88 or 8443. Because getUpdates and webhooks are mutually exclusive, an attacker with your token can call setWebhook to redirect your bot's updates to their server; getWebhookInfo shows the current URL, pending updates and recent delivery errors, so check it routinely. If you run Telegram's local Bot API server, call logOut before moving the bot to it and put a TLS-terminating proxy in front.

Logging and detection

Your own tokens

• Bot behaviour: log commands received, messages sent, guilds or chats joined and left, and permission changes. A bot joining servers or groups you do not know is a strong sign of token theft.
• Platform signals: unexpected Discord token reset emails, Telegram getWebhookInfo showing a URL you did not set, or polling conflicts because another client is calling getUpdates.
• Repository and build output: scan images, logs and notebooks, not only Git. See the Git Secret Scanning Guide.

Attacker use of these platforms

MITRE ATT&CK v20 documents these platforms as attacker infrastructure. InvisibleFerret (S1245) uploads stolen data to Telegram using the Telegram API with a bot token, and APT38 (G0082) exfiltrated stolen credentials through the Telegram Bot API, both under T1567 Exfiltration Over Web Service. Sandworm Team (G0034) and Small Sieve (S1035) used the Telegram Bot API for two-way command and control (T1102.002 Bidirectional Communication), and PureCrypter (S9019) reports infection status to Telegram or a Discord webhook. Several families host payloads on Discord's content delivery network. For defenders this means:

• Baseline egress: servers, build agents and most workstations have no business reason to call api.telegram.org or Discord webhook endpoints. Alert on them from proxy, DNS and EDR telemetry, and allowlist the few systems that run sanctioned bots.
• Use extracted tokens in response: attacker bot tokens and webhook URLs recovered from malware are indicators. Share them through your threat intelligence process and report abuse to the platform rather than interacting with the attacker's bot.
• Connect to infostealer response: a host that sent data to a Telegram bot should be handled as an infostealer case, with all credentials from that host rotated. See the Infostealer Logs Monitoring and Response Guide.

Metrics: share of bots owned by a team or organisation account; bots with Administrator or privileged intents they do not use; webhook URLs and tokens found by scanning per month; time from leak alert to token reset; number of hosts with unexplained Telegram or Discord API egress.

Hardening baseline

1. Inventory: list every Discord application and Telegram bot the organisation runs, its owner account, where its token is stored, what servers or groups it is in, its permissions or admin rights, and its webhooks.
2. Move ownership: transfer Discord apps into a team with named roles; move Telegram bots to organisation-controlled owner accounts. Plan this carefully because both transfers are permanent.
3. Reduce privilege: regenerate install links with minimal permissions, remove Administrator, disable unused privileged intents, and remove bots from groups where they do not need admin rights. Test in a staging server or group first.
4. Rotate and relocate secrets: reset each token, store the new one in a secrets manager and recreate any webhook whose URL has been shared widely. Roll back by redeploying with the previous configuration; the old token cannot be restored, so stage the new secret before you reset.
5. Protect webhooks: set Telegram secret_token, check getWebhookInfo on a schedule, and keep Discord webhook URLs in the vault.
6. Turn on detection: push protection and pre-commit scanning with custom patterns, bot activity logging, and egress alerts for Telegram and Discord APIs.

Small communities with one bot should at least use a team or organisation account, keep the token out of code and avoid Administrator. Organisations that run customer-facing bots should treat them as production services with change control, and decide centrally whether Telegram and Discord are sanctioned destinations at all on corporate networks.

Leak response

1. Reset the token (Discord Reset Token, Telegram /token) and deploy the new one.
2. On Telegram, check getWebhookInfo and re-set your webhook with a new secret_token; on Discord, review webhooks the bot created and recreate any exposed ones.
3. Review the servers or groups joined, messages sent and permission changes since the earliest possible exposure, and warn community members if the bot posted malicious links.
4. Find the source (repository, image, log, laptop) and remove it; if the token came from an infected device, follow the infostealer playbook for that device.

Framework mapping

Common misconfigurations

• Administrator on the bot: one leaked token can delete channels, change roles and ban members across every server the bot is in.
• Bot owned by a former employee's personal account: the organisation cannot reset the token or prove control when it leaks.
• Discord webhook URLs in client code or public CI logs: they need no other credential to post as your brand.
• Telegram webhook without secret_token: anyone who learns the endpoint can send forged updates.
• Privacy mode disabled by default: the bot, and its token, sees every message in every group.
• No egress policy: malware can send data to a Telegram bot from a server and blend in with "normal" HTTPS.

Practitioner checklist

• Inventory all Discord apps and Telegram bots with owner, token location, permissions and webhooks.
• Move Discord apps into a team and Telegram bots to organisation-controlled owner accounts.
• Remove Administrator and unused privileged intents; keep Telegram privacy mode on unless required.
• Store tokens, client secrets and webhook URLs in a secrets manager; never in code.
• Set a Telegram secret_token and check getWebhookInfo on a schedule.
• Enable push protection and add custom patterns for Telegram tokens and Discord webhook URLs.
• Alert on unexpected egress to Telegram and Discord APIs from servers and build agents.
• Rehearse a token reset, including redeploying the bot and re-setting webhooks.

Standards and references

• Discord Developer Docs: API reference and authentication
• Discord Developer Docs: Gateway and privileged intents
• Discord Developer Docs: Teams
• Discord Developer Docs: Webhook resource
• Telegram: Bot API
• Telegram: Bot features and BotFather
• GitHub Docs: Supported secret scanning patterns
• MITRE ATT&CK: T1567 Exfiltration Over Web Service

Related NHI Mgmt Group resources: Slack Tokens Security Guide · Webhook Secrets Security Guide · Infostealer Threat Guide · Collaboration Tool Security Guide