NULLZEREPTOOL: Inside a Telegram-Controlled DDoS and Multi-Function Attack Framework

By Sukant Kumar, Cybersecurity Researcher

A single Pastebin post, flagged by Flare’s paste-site monitoring on April 29, 2026, contained the full Python source code for a Telegram-controlled attack framework. That discovery led to a second, earlier variant of the same codebase and a window into the operator’s live Telegram session. What emerged is a tool with a split personality: a proven DDoS engine on one side and a growing list of wireless attack, credential-theft, and botnet features that exist only in code, never observed in use. NULLZEREPTOOL offers a case study of how low-tier Malware-as-a-Service (MaaS) tools evolve, how operators test and market them, and where defenders should focus detection efforts.

NULLZEREPTOOL is a Python-based attack framework controlled via Telegram. Two source variants were observed and analyzed: an earlier variant with a focused DDoS and proxy management feature set, and a later variant that retains all previous functionality while adding WiFi/Bluetooth attack modules, credential extraction, and a hierarchical botnet tasking structure. Both variants share the same hardcoded credentials (bot token, admin ID, password, master key). Static analysis of both source variants confirms a complete server-side implementation. The later variant’s wireless, credential, and botnet additions are implemented in code but absent from any client artifact in the analyzed set.

Key Findings About NULLZEREPTOOL: 

• The same bot token, admin ID, and static credentials appear in both code variants, establishing a direct code lineage between both variants.
• The Telegram-controlled DDoS engine (20 methods, auto-scaling, proxy rotation) is fully implemented in source: worker threads, auto-scaler, watchdog, and proxy pipeline are all present and coded to function as described in the analysis below. 
• The later variant adds WiFi discovery, password extraction (/wifipass), cracking (/wificrack), deauthentication (/deauth), Bluetooth disruption (/btdeauth), “Quantum” packet classes (standard crypto only), and a slave tasking hierarchy (BOTNET_HIERARCHY). These wireless and credential-theft features represent an atypical expansion beyond DDoS, aligning with feature creep common in low-tier MaaS tools.
• The Flask‑based botnet API (/register, /get_command, /report) is implemented in both variants, but /listbots returned “no clients connected” – no client code is present in the analysed artifact set.
• The later variant’s wireless attack, credential extraction, and botnet tasking features are implemented in server-side code only. No client binary (client.py) is present in the analyzed artifact set; end-to-end functionality of these features cannot be confirmed from the available source.

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)

Paste sites remain a common channel for malware source code distribution, and Flare monitoring these repositories routinely flags such suspicious posts. On April 29, 2026, Flare flagged a Pastebin post containing the full Python source code for a Telegram‑controlled DDoS and attack bot. 

NULLZEREPTOOL banner

Earlier variant discovery via “NULLZEREPTOOL” pivot (Flare link to post, sign up for the free trial to access if you aren’t already a customer)

The banner string inside the Pastebin post, “NULLZEREPTOOL,” became the pivot point. A keyword search across Flare using this identifier uncovered an earlier variant of the same codebase. The hardcoded credentials shared across both variants: bot token, admin ID, and password, provide a third analytical anchor confirming single-codebase lineage.

Variant Comparison and Evolution

Embedded Telegram bot credentials and version info

Both code variants share the same hardcoded credentials: BOT_TOKEN, ADMIN_ID = “7593738229”, ADMIN_PASSWORD = “7788”. Beyond these tokens, the later variant retains every function present in the earlier variant – the same DDoS worker methods, proxy harvesting logic, SQLite schema (c2.db tables: clients, attacks, reports, cvv_logs), Flask routes (/register, /get_command, /report), and key management files (keys.json, history.json). Vietnamese comments and bot response strings are consistent across both. No core function is removed; the later variant is a strict functional superset of the earlier one.

The tooling evolution is additive. The later variant introduces three new capability domains: wireless attacks, hierarchical botnet tasking, and “quantum”‑branded modules (each is discussed in detail in later sections). Defenders can rely on the same detection indicators for both variants, with additional surfaces introduced only in the later version.

Code Analysis: Implemented vs. Confirmed

Static analysis of both source variants reveals a consistent pattern: a fully implemented server-side DDoS and C2 framework, with later additions that are coded but carry unresolved dependencies or missing client components. The DDoS engine, proxy pipeline, authentication controls, and key-management system are complete. The key-management system’s single-use expiring-key design is consistent with tiered-access or resale distribution models. The system is complete in source; its operational use cannot be assessed from static analysis.

Implemented Core Capabilities

DDoS Engine: Mechanism and Observed Behavior

DDoS attack engine workflow

Methods dictionary

The attack engine uses a METHODS dictionary mapping 20 attack names to worker functions. A worker function runs in its own dedicated thread, repeatedly executing a specific attack method, for example, sending HTTP GET requests or UDP packets in a loop. Each worker calculates its own delay based on the target RPS divided by the total worker count. The attack engine spawns one thread per worker; all threads run concurrently. 

combo_worker function

The most comprehensive worker is combo_worker, in each successful pass through its main loop, it executes:

• Four HTTP requests (GET, POST, HEAD, OPTIONS) with randomized headers and query strings via a requests.Session.
• One UDP packet (1,024 bytes of random data) to the target’s port (80 for HTTP, 443 for HTTPS).
• One TCP connection (SYN handshake only, no payload sent) to the target port, which is immediately closed.

Worker delay logic

The attack orchestrator calculates each worker’s delay based on the target RPS. The formula ensures the total configured RPS is distributed across all workers, with a minimum delay of one millisecond per worker to prevent excessive CPU usage. 

Thread capping logic

The engine spawns up to 1,000 threads initially. Each thread runs the selected attack method continuously until the attack is stopped or the target becomes unreachable. The initial thread count is capped by explicit validation.

A separate auto‑scaling thread runs every 15 seconds to maintain throughput. If the observed RPS falls below 70% of the target and the current worker count is under 2,000, it calculates a new worker count (current × 1.2 + 10), caps it at 2,000, and spawns additional threads to reach the new count.

Web watchdog function

A watchdog thread checks target availability every five seconds. It sends a GET request with randomized headers and, if that fails, attempts a TCP connection to the target’s port. If the target becomes unresponsive, the watchdog stops the attack and reports “WEB ĐÃ CHẾT!” in Vietnamese, that is translated to “web is dead.”

Attack on shopmuabancf[.]com

The attack orchestrator is coded to report periodic stats back to the Telegram admin during a run, including cumulative request counts and current worker totals: The first against shopmuabancf[.]com with 100 workers and a 20,000 RPS target produced periodic stats messages showing request counts rising from 402 to 10,254 before manual stop.

Attack run on Bloomberg

Attack request termination on Bloomberg

The auto-scaler is coded to trigger every 15 seconds when observed RPS falls below 70% of target, raising the worker count by a factor of 1.2 plus 10, capped at 2,000. The web watchdog runs in parallel, checking target availability every five seconds and terminating the attack if the target becomes unresponsive.

The DDoS engine is implemented as described. Throughput in practice would be constrained by proxy pool quality, target-side defenses, and worker sleep-plus-request-time exceeding the calculated delay interval. These factors cannot be assessed from static analysis alone.

Positioning Among Similar Tools

The control pattern resembles a low‑end DDoS‑for‑hire panel (Telegram‑based configuration, live feedback). Unlike self‑propagating IoT botnets such as Mirai, this tool requires manual deployment and writes multiple files to disk, creating a larger forensic footprint. Among Telegram‑controlled tools, it sits between simple alert bots and those that use dead‑drop resolvers or domain generation algorithms.

Proxy Pipeline: Harvest to Rotation

Multi-stage proxy pipeline

Both variants implement a multi-stage proxy pipeline. Fetch_free_proxies() function collects from seven sources: api.proxyscrape[.]com, proxylist.geonode[.]com, free-proxy-list[.]net, and four other GitHub raw URLs. 

Proxy validation/health check

update_proxy_list() tests each proxy with httpbin[.]org/ip within a five‑second timeout, then measures response time and retains only those responding under two seconds. The validated set is saved to proxy.txt. get_random_proxy() selects a random entry from the in‑memory list, tests it again with a three‑second timeout, and removes failures from the in-memory pool during attack execution.

Proxy rotation is central to attack execution. The /proxy update command triggers fetch_free_proxies() and update_proxy_list() in sequence, refreshing and validating the proxy pool. This is a prerequisite step before any attack run, as get_random_proxy() draws from the validated in-memory list at execution time, confirming proxy rotation is central to attack execution. 

Telegram C2: Authentication and Control

Telegram authentication

The bot uses telebot.Telebot with the hard-coded token. The is_admin() function checks the sender’s user.id against ADMIN_ID = 7593738229. The logged_in dictionary tracks session state, reset after a successful /login 7788. Commands such as /attacks, /proxy, /key, and /cvv all check is_logged_in() before execution.

Connected client status

The Flask backend (/register, /get_command, /report) is fully coded in both source variants Tahe /listbots command queries the clients table in c2.db. No client binary (client.py) is present in the analyzed artifact set, meaning the registration flow has no counterpart in the available source. 

CVV Storage: Implemented but Dormant

CVV collection feature

Both variants implement a manual CVV storage system designed for admin to log and retrieve card data. This is not an automated harvesting mechanism. It creates a cvv_logs table in c2.db with columns cc, cvv, exp, time. The /cvv <cc> <cvv> <exp> command validates that three arguments are provided, inserts the data into the cvv_logs table with a timestamp, and confirms storage to the operator.

getcvv Command

The /getcvv command queries the cvv_logs table and returns all stored records. An empty table returns a no-data response in Vietnamese. 

This inclusion of a manual CVV storage mechanism within a DDoS-oriented tool is atypical. DDoS frameworks focus on availability disruption; storing payment card data indicates feature creep towards data theft, potentially broadening the tool’s appeal as a multi-purpose MaaS offering or centralizing the operator’s logging for separate credential-harvesting campaigns.

Key Generation System: Commercial Access Control Access Mechanism

Both code variants implement a license-style key store designed to manage and restrict access to the bot. The system supports generating, listing, and deleting access keys,  infrastructure compatible with tiered-access or resale models.

Key-management helper

Both the code variants include the same key-management helpers: load_keys(), save_keys(), generate_key(), create_key(), delete_key(), check_key(), and use_key(). generate_key() uses secrets.token_hex(10), producing a 20‑character hex string. The default max_uses=1 means each key is single‑use, it becomes exhausted after one redemption.

Administrative Commands

Sample generated key

• /key [days] – Generates a new access key.
• /keys – Lists all existing keys, showing expiry dates and usage status (used count vs. max_uses).
• /delkey <key> – Revokes a key.

The key-management system’s architecture — single-use expiring keys, generate/list/revoke commands, secrets.token_hex(10) randomness — is consistent with tiered-access or resale distribution. The system is complete in source; its operational use cannot be assessed from static analysis. 

Later Version Additions: Implemented But Unconfirmed

The later variant introduced several entirely new capability domains. While the code is present, no client binary exists in the analyzed artifact set and several features carry unresolved external dependencies.

Wireless Attack Modules: Implementation and Dependencies

Linux deauth

The later variant implements WiFi and Bluetooth attack routines with distinct Linux and Windows paths. The deauth handler on Linux orchestrates aireplay-ng with parameters for AP and target MAC addresses, while the Windows implementation uses netsh wlan disconnect. Both are simple command wrappers that depend on the presence of external tools or system utilities.

Bluetooth adapter detection

The btdeauth and btlock handlers are Linux-only, using l2ping -f for flooding and hcitool dc for disconnection. These commands require root privileges and a Bluetooth adapter, making the feature highly environment‑dependent.

WiFi password extraction is implemented as a series of OS command invocations. On Windows, the handler reads all saved profiles via netsh wlan show profiles, then extracts each password with “netsh,” “wlan,” “show,” “profile” name=<SSID> key=clear, parsing the output for the “Key Content” line. On Linux, the handler uses nmcli to query connection details and extract the PSK. The results are collated and sent back to the Telegram admin.

WiFi crack capability

WiFi cracking is implemented as a three-stage workflow: hcxdumptool captures handshakes, hcxpcapngtool converts the capture to hashcat format, and hashcat performs dictionary-based cracking. This feature depends on the presence of three external tools, a capture‑capable wireless interface, and a wordlist file.

The addition of wireless attack modules and WiFi cracking represents a significant expansion beyond NULLZEREPTOOL’s core DDoS function. DDoS frameworks typically target network or application layer resources, not physical layer wireless interfaces or credential stores. 

Hierarchical Botnet

Botnet hierarchy

The later variant implements a structured tasking model. The BOTNET_HIERARCHY dictionary tracks master nodes, slave nodes, task queues, completed tasks, and collected data. New Flask endpoints (/slave_register, /slave_get_task, /slave_report) accept slave registration and task polling. Telegram commands (/botnet_task, /botnetdata, /botnetslaves, /botnetexport) allow the admin to create tasks, view collected data, list slaves, and export JSON.

Botnet task configuration

The task configuration includes types such as wifi_scan, browser_steal, and full_steal, each referencing a list of modules. The server records task status, assignment, and completion timestamps. The server records task status, assignment, and completion timestamps. The browser_steal and full_steal tasks reference “browser_credentials” as a module.

However, we did not observe any function that read browser password stores. There is no win32crypt, no keyring, no browser‑specific database parsing. The feature exists only as a reference in the task configuration and in help banners advertising “FULL STEALER.” It is not implemented in the server‑side code. The later variant’s help banner references these capabilities, but the underlying logic to perform browser credential theft is absent. 

The server‑side implementation is complete, but the client (client.py) is absent from the artifact set; without it the registration and tasking flow cannot be exercised and end-to-end functionality cannot be confirmed.

This is a server‑side capability only. Without the client binary, its end‑to‑end functionality cannot be confirmed. Defenders who observe the Flask endpoints in network traffic should treat them as indicators of a NULLZEREPTOOL C2 server. 

“Quantum” Branding: No Novel Technology Observed

Quantum branded WiFi exploit module

The WiFi7QuantumExploit and Bluetooth6QuantumExploit classes implement methods with quantum‑sounding names: craft_pmf_bypass_packet, craft_wpa4_quantum_handshake, wifi7_mimo_flood, craft_ble6_channel_sounding_jam, craft_le_audio_bypass_packet, and ble6_aoa_spoof. But their implementations use:

• hashlib.sha3_512 for fake MIC generation and key derivation
• hashlib.pbkdf2_hmac for a “fake PMK” (Pre‑Master Key)
• os.urandom and secrets.token_hex for randomness
• struct.pack for binary assembly of MAC‑layer frame

The “quantum” naming is marketing, not the actual technology itself. The code uses standard cryptography and packet-building primitives with no quantum algorithms present. This is a common tactic in low-tier MaaS ecosystems where branding is used to inflate perceived capability. Defenders should not treat “quantum” as a novel threat; detections should focus on the underlying raw-socket and subprocess behaviors.

Observed Attack Targets

The source code defines the full attack execution path: target URL, method selection, worker count, RPS target, auto-scaler thresholds, and watchdog termination conditions. The table below summarizes the implemented parameters and expected behaviors as coded:

Actual throughput in deployment would depend on proxy pool quality, target-side defenses, and runtime environment. These factors cannot be assessed from static analysis. 

Detection and Defensive Strategies

Network Indicators (inbound to your assets)

• HTTP Floods (combo_worker, http_worker): High‑volume HTTP/S requests with randomised User-Agent, Referer, X-Forwarded-For, and query strings (e.g., ?<random>=<random>&_=<timestamp>). A mix of GET, POST, HEAD, and OPTIONS methods from the same source IPs within short time windows.
• UDP Floods (udp_worker, combo_worker): High volumes of UDP datagrams to ports 80 or 443. The combo_worker sends 1,024‑byte packets, while the udp_worker sends 2,048‑byte packets in batches of 10 per loop iteration. Detection rules should account for both sizes.
• TCP Floods (tcp_worker): High volumes of short‑lived TCP connections to ports 80 or 443. Each connection completes a full three‑way handshake and sends a minimal HTTP GET request (GET / HTTP/1.1\r\nHost: <host>\r\n\r\n) before immediate closure. Hunt for high connection rates with minimal payload.
• DNS Amplification (dns_amplification_worker): High volumes of large DNS queries (50x www.example.com repeated) sent to public DNS resolvers (8.8.8.8, 1.1.1.1, etc.) with spoofed source IPs pointing to the target. Detect via outbound DNS query rates or inbound reflected DNS response floods (typically >1,500 bytes per response.
• NTP Amplification (ntp_amplification_worker): monlist requests sent to public NTP servers (time.google.com, pool.ntp.org, etc.), causing large response floods reflected to the target. Detect via monlist packets (0x17 0x00 0x03 0x2a) or inbound NTP response flood.

Actionable Intelligence Pivots

MITRE ATT&CK Mapping

What Security Teams Can Take Away About NULLZEREPTOOL

The initial intelligence came from passive monitoring of public paste sites via Flare, which flagged the Pastebin Post (NULLZEREPTOOL). The post from April 29, 2026, combined with the earlier variant (April 27, 2026), revealed an evolving attack framework with a fully implemented DDoS core and an expanding later feature set whose end-to-end functionality cannot be confirmed from the available source artifacts. 

NULLZEREPTOOL is primarily a Telegram‑managed DDoS panel, not a demonstrated distributed botnet or wireless exploitation platform. The DDoS engine, proxy rotation, and authentication controls are fully implemented in source code. The later variant introduces features that are highly atypical for a DDoS-oriented tool: wireless de-authentication, Bluetooth jamming, WiFi cracking, and “quantum” branded modules. These additions reflect feature creep driven MaaS market dynamics, expanding from network-disruption to physical-proximity and credential-theft capabilities. However, the features in the later variant are heavily dependency‑bound and none were observed in use, suggesting the tool is still in a feature‑testing phase rather than operational maturity.

Flare’s detection underscores the value of continuous paste‑site monitoring for emerging tooling. For defenders, the hard‑coded bot token and admin ID provide immediate, actionable pivots for platform‑level intervention, regardless of the tool’s evolving feature set.

References and Sources

1. Initial Intelligence Lead: Flare Global Search – Flare
2. Pastebin Post (April 29, 2026): https://pastebin.com/ryxQ077S
3. Pastebin Post (April 27, 2026): https://pastebin.com/Rxk4VgnX