TWEAKOS Uncovered: A Telegram-Driven Stealer and C2 Ecosystem for Discord and Telegram Tokens

By Sukant Kumar, Cybersecurity Researcher

Most credential stealers stop at theft, but TWEAKOS keeps going: it steals the account, prices it, discounts it 5% a day until someone buys it, and settles the sale in Telegram Stars, all inside the same Telegram bot that received the stolen data in the first place. Theft, inventory, and checkout run in one process, under one bot token. This is the first documented case of a stealer and its own storefront running inside the same bot process.

TWEAKOS is a Telegram-native credential theft and monetization workflow composed of two co-designed Python components:

• a Windows-oriented stealer (v1) that harvests Discord tokens and creates Telegram session files
• a single-process Telegram bot (v2) that stores part of the resulting data, exposes it to operators, and sells compromised accounts through Telegram Stars

The stealer establishes local persistence, scans Discord, Discord PTB, and Chrome’s default-profile Local Storage LevelDB directories, and applies a Discord-token regex to .log and .ldb files in those paths. It validates candidate tokens against the Discord API, drives an interactive Telethon sign-in flow, and exfiltrates validated Discord tokens and, if present, the resulting Telegram session file to two hardcoded admin IDs through a shared Telegram bot token. The Chrome path is limited to Local Storage LevelDB and is used to search for Discord-token-pattern matches; the code does not access Chrome’s saved-password database, cookie store, or browser encryption-key material.

The backend uses the same bot token and admin IDs to run a long-lived bot process that manages victims, products, orders, buyers, and admin logs in a SQLite database, with a shop that sells “telegram” and “discord” accounts under the TWEAKOS brand. Shared configuration constants and consistent branding strongly support assessment of the two files as co-designed components of a single operation. The recovered code also shows incomplete integration around victim record creation and Discord token persistence, but those gaps affect backend visibility rather than the demonstrated theft, operator access, or monetization flow.

Key Takeaways About TWEAKOS

• TWEAKOS is a two-part operation composed of a Windows-oriented stealer and a single-process Telegram bot that handles ingestion, victim management, and credential sales under one bot token.
• The strongest co-design indicators are the shared bot token and admin IDs, plus the fact that the stealer’s Telegram message format is explicitly parsed by the bot’s receiving logic.
• The Telegram theft path is operationally stronger than a passive session grabber because it creates a fresh Telethon session in real time from victim-supplied credentials and then transmits the resulting .session file to operators.
• The backend (v2) combines buyer tracking, order history, time‑decay pricing, and Telegram Stars settlement inside a single runtime – a level of commercial design that is notable for this sophistication tier (medium confidence).
• The recovered VBScript locker (generate_blocker_script()) provides high-confidence evidence of targeted coercion: it delivers a per-victim modal loop with vbSystemModal and a coercive message.
• The referenced WindowsSecurityChecker.exe indicates intent to deliver a follow-on payload, but the binary was not recovered; its functionality remains unconfirmed.
• Russian-language prompts, comments, and UI strings indicate a Russian-speaking operating context and probable Russian or CIS victim orientation, but they do not support attribution to a specific actor or state.

Initial Discovery on Pastebin

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)

The TWEAKOS stealer investigation began with the usual monitoring of public paste sites via Flare. A Pastebin post containing the TWEAKOS stealer source code was flagged as high severity. The initial Pastebin post exposed a hardcoded Telegram bot token and two hardcoded admin IDs, immediately indicating that Telegram was being used as the operator control and exfiltration channel.

C2 Counterpart Discovery: Bot token pivot via Flare (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

Pivoting on the Telegram bot token across Flare surfaced a second and substantially larger Python component (v2) using the same Telegram bot token and admin IDs. That second component implemented the receiving, storage, and management, and sales side of the same operation.

A limited, read-only validation request to the Telegram Bot API using the exposed token returned no usable bot response at the time of analysis. No messages were sent and no bot state was modified. The associated bot channel was also inaccessible. These observations establish that the exposed token and channel were unusable during the investigation.

Co-design and Operational Pipeline

Shared Configuration

Stealer configuration (v1)

Backend configuration (v2)

Both the Pastebin hosted codes hardcode the same Telegram bot token and admin ID list, and the backend immediately instantiates a Telebot using that token. The stealer never communicates with the backend by direct import or network call; instead, it uses the shared bot identity and the admin IDs as its exfiltration targets. This configuration overlap is the base layer of co-design evidence.

Telegram Field Alignment

Telegram account messages (v1)

Telegram field parsing (v2)

For Telegram, the stealer sends formatted messages containing the phone number, username, and Telegram ID, and either a “new password” field or a “password already existed” note. The backend’s handle_virus_data() function searches inbound non‑admin text for the phone field and a Новый пароль: (new password) value, extracting phone and cloud_pass accordingly. Emojis, Russian field labels, and backtick formatting align exactly for the “new password” case. This field-level compatibility is the strongest co-design evidence in the recovered codebase, showing that the stealer and backend were built around a common Telegram message format.

Session File Handling

Session file exfiltration (v1)

Session file ingestion (v2)

The stealer expects a Telethon session file named {phone}.session and, if present, sends it to the admins as a document via sendDocument. The text message and the file are transmitted as separate API calls: the text via sendMessage (with parse_mode=’Markdown’) and the file via sendDocument (with only chat_id in data; the code does not attach a caption to the document). The backend treats non‑admin documents as session submissions, saves them as session_{uid}.session keyed on the sender’s Telegram chat ID, updates the session_file field in the victims row (if it exists), and forwards the session file to each admin with caption “Сессия Telegram от {uid}”. This pairing confirms that both samples treat .session files as the core takeover artifact and route them via the shared bot channel, but the actual flow direction differs: v1 (stealer component) pushes outbound to admins, v2 (C2 counterpart) ingests inbound from non‑admins.

Discord Field Misalignment

Discord message template (v1)

Discord parsing attempt (v2)

For Discord, the stealer sends a message labeled “Discord” containing the token, user tag, and account ID. The backend attempts to parse a token from messages containing DISCORD in uppercase, followed by Токен: (token) and a backticked token value (e.g., Токен: `{token}`). Because the stealer emits *Discord* with only the initial capital and never uses all‑caps DISCORD, this case‑sensitive regex fails in practice, and discord_token remains empty even for valid Discord messages. This defect matters for victim visibility, but does not affect the stealer’s theft and exfiltration of tokens to admin.

Architectural Decoupling: Outbound vs Inbound

Outbound exfiltration (v1)

Inbound ingestion handler (v2)

v1 and v2 share bot credentials, admin IDs, and deliberately aligned message structures, but their data paths are architecturally decoupled. In v1, send_to_admin() exfiltrates stolen text and files directly to the hardcoded admin chat IDs via the Telegram Bot API, including {phone}.session and formatted Discord-token messages. In v2, handle_virus_data() is an inbound handler restricted to non-admin text and documents; it saves uploaded session files as session_{uid}.session, updates victims.session_file (only if the row exists), and forwards the file to admins.

This reveals shared infrastructure and design intent for structured ingestion, but not a demonstrated runtime path from stealer exfiltration into backend victim storage. Compromises reach operator chat logs, not the victims table. Defenders should prioritize acquiring Telegram chat logs over the C2 database for complete victim visibility.

Stealer Component: Capabilities and Execution Flow

Persistence and Windows Targeting

Persistence logic (v1)

The stealer’s persistence logic is Windows-specific and operates entirely in user context, with two distinct mechanisms depending on how the payload is delivered. In packaged-binary mode (sys.frozen), it copies its executable into the user Startup folder as SystemHelper.exe, ensuring execution at logon. In script mode, it writes a SystemHelper value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run, pointing to the script path (__file__). Both mechanisms are user-scoped and do not attempt privilege escalation. For defenders, these are separate persistence paths: the frozen build leaves a file in the Startup folder, while the script build leaves a registry Run key.

Discord Token Discovery and Validation

Discord token theft logic (v1)

Token validation logic (v1)

The stealer enumerates three LevelDB locations, covering Discord, Discord PTB, and Chrome’s default profile, and uses a regex that matches the standard token pattern and multi‑factor tokens starting with mfa. It scans .log and .ldb files in those directories, aggregates matches, and deduplicates them. Each candidate token is then validated by calling discord[.]com/api/v9/users/@me with the token in the Authorization header; only tokens returning HTTP 200 responses are exfiltrated. The exfiltration message includes the token and the user tag, confirming that the operator receives both the credential and the contextual account identity.

Interactive Telethon Sign‑in and Session Theft

Telethon credential capture

The Telegram path is a live credential‑capture and session‑creation flow. The script prompts for a phone number (Введите номер Telegram (+7…): “enter Telegram phone number”), uses Telethon to send a login code, prompts for that code, and if Telegram requires a cloud password, prompts for and uses that password to complete sign‑in. This creates a new authorized Telethon session even where no desktop session previously existed.

Password-state inspection without password change

After sign‑in, the script retrieves account metadata via get_me() and inspects cloud‑password state using GetPasswordRequest(). If no password exists, it generates a random new_pass and reports it, but explicitly notes: (не установлен технически, но сессия украдена) “Not technically established, but the session has been hijacked.” No SRP or password‑update logic is present. If a password already exists, the script reports it was not changed. The outcome is session theft, not password change.

Session-file Discovery and exfiltration trigger

Separate text and file API calls

The script then checks for a Telethon session file named {phone}.session and exfiltrates it to the hardcoded admin IDs if present. Text and file transfer are split across two Bot API requests: sendMessage carries the contextual status text, while sendDocument uploads the .session file with only chat_id supplied and no caption attached. The .session file is a reusable takeover artifact that allows the operator to impersonate the victim via Telethon.

Combined Execution Flow

Combined execution flow function

The main() function chains persistence, Discord token theft and validation, and Telegram session theft into one execution path. The Telegram routine is invoked unconditionally after the Discord loop, so every normal run enters both the Discord and Telegram branches, even though Discord exfiltration occurs only when candidate tokens validate successfully. The absence of obfuscation and complex staging makes the behavior clear in recovered source code, and all observed actions: persistence, token access, Telethon sign‑in, and session exfiltration, are directly supported by the code.

C2 Counterpart: Architecture and Operator Interface

Bot Structure and Role Separation

C2 Bot configuration

The backend is a single long-lived TeleBot process using the shared bot token and listening via bot.infinity_polling() for inbound updates. It multiplexes buyers, admins, and inbound victim submissions primarily through ADMIN_IDS checks, text matching, callback routing, and content-type handlers. Shop, payment, delivery, victim management, and ingestion logic all execute inside this single bot identity and process.

Database Schema and Victim Storage

Database schema

Victim data storage logic

The backend stores state in tweakos_data.db. The victims table includes Telegram user_id, username, phone, cloud password, Discord token field, session file path, blocked state, virus‑sent state, and first/last timestamps. save_victim_data() uses INSERT OR REPLACE, writing the current time to both first_seen and last_seen – this binds records to Telegram user_id, allows single‑call replacement, and resets first_seen on replacement rather than preserving the earliest observation.

Victim list and detail query logic

The admin victim list and detail views, populated via get_all_victims() and get_victim_by_id(), expose these fields for records in the victims’ table.

Shop Schema, Buyers, and Logs

Products and orders schema

Buyers and admin logs schema

The backend’s shop is backed by:

• products: accounts for sale with type (Telegram or Discord), identifier (phone or login), a password or token field, base price, timestamps, and status
• buyers: shop users, tracking purchase time, paid price, and delivered credentials strings
• orders: completed purchases, tracking purchase time, paid price, and delivered credentials strings
• admin_logs: operator actions, storing time, admin ID, action name, target ID, and truncated details for recent activity

Together these give the operator visibility into both victims and revenue without any external infrastructure.

Time‑Decay Pricing and Catalogue

Time‑decay pricing logic

Discount capping logic

The shop treats accounts as inventory with explicit time‑dependent value decay. get_current_price() calculates account age in days from added_ts, applies a 5% daily discount capped at 70%, and enforces a minimum price of 1 Star. get_available_products() uses that function to compute current prices for all available products, ensuring that both Telegram and Discord accounts show reduced prices over time. This algorithmic pricing reflects a commercial understanding that stolen credentials lose value as they age.

Stars Invoices and Delivery

Payment and delivery flow

The bot generates Telegram Stars invoices (“XTR” currency) for each purchase, describing the account type and showing the discounted price relative to the base price. After successful payment, it marks the product as sold, inserts an orders row with delivered_data containing the account type, login, and password/token, and sends the formatted credential string to the buyer chat. Admins receive a notification that includes the product ID and amount paid. The code therefore implements a commerce workflow within the same bot identity that also handles victim-data ingestion.

Victim Ingestion Failures and Limitation

Inbound handler logic

The bot’s handle_virus_data() is only invoked for inbound messages from non‑admin users. Therefore, the parsing defects described below would only matter if such messages were received. In the current codebase, the stealer’s exfiltrated data never triggers this handler, so these defects are secondary to the missing inbound path.

If the handler were invoked with v1‑formatted messages, the following blind spots would occur.

• Discord regex mismatch: discord_match expects uppercase DISCORD, but v1 uses *Discord*. discord_token remains empty.
• 2FA victims: When v1 sends “Пароль уже был, не меняли” (“There was already a password; it wasn’t changed”), no Новый пароль (“New password:”) field is present, so cloud_pass is empty. Combined with empty discord_token, the gate if cloud_pass or discord_token fails, so save_victim_data() is not called.
• Session file UPDATE: If a victim row does not exist, the UPDATE in the document branch affects 0 rows. The session file is still saved locally and forwarded to admins, but not linked to a database record.

These defects match the code, but they are secondary. The primary reason v1 compromises are missing from victims is that v1’s outbound messages never enter the inbound handler.

Admin Panel, Broadcasts, and Coercion

Admin panel and broadcasts

Admins access statistics (Статистика), victim lists (Список жертв), “virus” sending, Windows blocking, unblocking, shop admin mode, broadcast messaging (Рассылка), and logs (Логи). The statistics view calls get_stats(), which counts victims, blocked victims, victims with non‑null session_file, total orders, and total Stars earned. Broadcasts send a Markdown message to every row returned by get_all_victims() and log the action in admin_log.

VBScript coercion locker

The blocker script blocker_{uid}.vbs implements a per‑victim coercion mechanism. It loops indefinitely, showing a critical modal dialog “ВАШ КОМПЬЮТЕР ЗАБЛОКИРОВАН! Обратитесь в Discord: https://discord[.]gg/tweakos” (“YOUR COMPUTER IS BLOCKED! Contact us on Discord: https://discord[.]gg/tweakos”) with the caption “TWEAKOS,” using vbSystemModal to keep it on top.

victim_action() block branch

Admins send this script to a victim via the “block” action, and the backend deletes the local script file afterwards.

Invalid invite error

When discord[.]gg/tweakos was manually visited during analysis, the link returned an “invite invalid” error, indicating the referenced invite or server is no longer active.

WindowsSecurityChecker[.]exe reference

The “virus” path attempts to send a local WindowsSecurityChecker.exe file to a victim with the caption “Критическое обновление безопасности. Запустите.” (“Critical security update. Run it”). If the file is missing, the admin receives an alert. The binary is not present in v2, so its actual behaviour is unknown; the code unambiguously shows intent to deliver a follow‑on payload via the bot channel.

Operational Design Patterns and Consequences

TWEAKOS stands out among Telegram‑abusing credential theft tooling and simple reseller bots in several ways. Two features are especially notable in TWEAKOS’s design: live Telethon session creation and time‑decay pricing.

• Live session creation over passive scraping: Unlike stealers that copy existing session files, TWEAKOS builds a fresh Telethon session from victim‑supplied credentials. This guarantees a working session but requires active victim interaction and leaves authentication logs and console prompts as forensic artifact.
• In‑platform monetization over external infrastructure: The shop processes payments via Telegram Stars (“XTR”), keeping browsing, checkout, and delivery inside Telegram. This reduces operational overhead and buyer friction but ties monetization to Telegram’s platform policies and visibility.
• Automated inventory management over manual pricing: While many shops rely on static pricing, get_current_price() applies a 5% daily discount capped at 70%, with a floor of 1 Star. This removes operator discretion and moves stale inventory, but assumes a linear depreciation model that may not reflect real‑world credential value. The commercial intent is clear; the pricing sophistication is limited.
• Exfiltration over backend fidelity: The stealer sends data outbound to admin chats; the bot’s inbound ingestion is incomplete and fragile. The formatting alignment between both the codebases proves design intent for structured ingestion, but the runtime ingestion path is incomplete – handle_virus_data() exists but only processes inbound non‑admin messages, and its regex/gating logic can fail to capture the data emitted by v1. Successful theft and delivery to operators takes precedence over centralized database normalization.
• Targeted coercion over generic destruction: The VBScript locker is per‑victim, ephemeral, and operator‑triggered. This enables targeted coercion but requires operator action for each victim. The design is consistent with human‑driven abuse rather than automated ransomware.

Indicators of Compromise and Pivotable Infrastructure

The most useful TWEAKOS indicators are the stable values that link both samples and persist across execution paths. These are organized below by category for operational use.

Network and Infrastructure IOCs:

Host‑Based IOCs:

MITRE ATT&CK Mappings

Detection and Defensive Strategies for Security Teams

TWEAKOS is not a sophisticated framework. It is a functional, commercially oriented credential theft operation built around Telegram as the central infrastructure layer. Its strengths, live session theft, automated pricing, and in‑platform payments, are offset by weak integration, incomplete victim tracking, and a single point of failure in the bot token.

The operator prioritized theft efficacy and monetization convenience over stealth, integration quality, or data durability. The architectural gaps are not bugs; they define how the operation functions: data reaches operators via raw chat messages, not through a centralized database.

For defenders, the most valuable insight is not the capabilities themselves, but the visibility gaps they reveal. The stealer exfiltrates directly to admin chat logs, while the backend’s structured ingestion is incomplete and fragile. The operation leaves traces in persistence artifacts (SystemHelper.exe, Run‑key entries), LevelDB access logs followed by Discord API call, and Telegram API traffic (send message/sendDocument), .session files, blocker_*.vbs with coercive content. These are the hunting surfaces that matter. Below are actionable steps for security practitioners.

Endpoint Detection

• Monitor for SystemHelper.exe creation in %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\, which add_to_startup() uses when the executable is running in frozen form.
• Alert on writes to HKCU\Software\Microsoft\Windows\CurrentVersion\Run where the value name is SystemHelper.
• Hunt for .session files matching phone number patterns (\+?\d{10,15}\.session) or session_\d+\.session, particularly when followed by Telegram Bot API traffic.
• Track processes that read Discord or Chrome LevelDB directories then call discord[.]com/api/v9/users/@me.
• Detect short-lived blocker_\d+\.vbs creation and deletion, and flag files containing ВАШ КОМПЬЮТЕР ЗАБЛОКИРОВАН! or discord.gg/tweakos.

Network Detection

• Inspect outbound HTTPS to api.telegram.org, especially sendMessage and sendDocument requests associated with local session-file creation, Run-key writes, or LevelDB access.
• Hunt for discord.com/api/v9/users/@me requests from non-browser processes that also accessed LevelDB storage.

Identity and Account Security

• Treat unsolicited console prompts for a Telegram phone number, login code, or cloud password as high risk; steal_telegram() depends on that interaction path.
• In incident response, prioritise Telegram session invalidation and review for exfiltrated .session files, because v1 checks for {phone}.session and sends it to admin if present.
• For Discord, assume validated tokens have been exfiltrated. Immediately revoke and regenerate Discord tokens for affected users, and enforce multi‑factor authentication (MFA) to mitigate future token‑based access.

What We Can Learn from the First Documented Case of a Stealer and Storefront in One

TWEAKOS demonstrates that implementation complexity and operational capability are not the same. A single Telegram bot identity links credential exfiltration, operator administration, victim tracking, account inventory, Telegram Stars payment handling, and buyer delivery into one Telegram-centered workflow. Rather than implementing a custom C2 or custom payment infrastructure, the operation combines Telegram’s Bot API and Stars payments with Telethon-based session creation and Discord API token validation. The recovered source is largely unobfuscated, yet it implements Discord-token validation, Telegram session-file exfiltration, SQLite-backed product and order management, time-decay pricing, and buyer-facing account delivery.

The integration gaps do not negate those capabilities. Case-sensitive Discord parsing, conditional victim-record creation, and the separation between admin-bound exfiltration and non-admin inbound handling reduce backend visibility into some compromises, even where credentials and session files are sent directly to operators. For defenders, the key lesson is to investigate this activity as a connected workflow rather than isolated Telegram abuse: correlate local token-store access, Discord token-validation traffic, Telethon session artifacts, Telegram Bot API requests, Stars payment events, and coercive payload delivery.

References and Sources

• Initial Intelligence Lead: Flare Global Search – Flare.io
• Telegram Stars: telegram.org/blog/telegram-stars