NULLZEREPTOOL Uses Telegram to Control 20 DDoS Methods and Rotating Proxies

Security researchers have uncovered NULLZEREPTOOL, a Python attack framework that uses a Telegram bot to control 20 denial-of-service methods, manage rotating proxies, and report attack statistics.

Flare discovered the framework after its monitoring system flagged a Pastebin post on April 29, 2026. The post contained the complete Python source for a Telegram-controlled attack bot. A search for the embedded NULLZEREPTOOL name then revealed an earlier variant posted two days before, according to the Flare investigation.

The core DDoS engine, proxy pipeline, Telegram authentication, and key-management system contain working server-side code. However, Flare could not determine how widely operators have deployed the framework or independently measure its real-world impact through static analysis alone.

NULLZEREPTOOL Functions as a Telegram DDoS Panel

NULLZEREPTOOL resembles a low-end DDoS-for-hire panel more than a traditional self-propagating botnet. An operator must deploy the software manually and control it through commands sent to a hardcoded Telegram bot.

The code checks the sender’s Telegram user ID against a hardcoded administrator ID. It also requires a static password through the /login command before allowing access to functions such as attacks, proxy management, key generation, and stored card-data records.

Both discovered variants share the same bot token, administrator ID, password, database structure, proxy-harvesting logic, and DDoS worker functions. These similarities connect the two samples to the same codebase.

Component	Purpose	Implementation status
Telegram bot	Receives commands and returns attack statistics	Implemented
DDoS engine	Runs 20 HTTP, TCP, UDP, and amplification methods	Implemented
Proxy pipeline	Collects, tests, and rotates public HTTP proxies	Implemented
Flask backend	Registers clients and manages commands and reports	Implemented server side
Hierarchical botnet	Assigns tasks to proposed slave nodes	Client component missing
Wireless modules	Runs WiFi and Bluetooth disruption commands	Code present but operational use unconfirmed
Browser credential theft	Advertised as part of botnet tasks	Underlying theft logic absent

DDoS Engine Supports 20 Attack Methods

The framework uses a METHODS dictionary that connects 20 attack names to individual worker functions. Each worker runs in a separate thread and repeatedly performs its assigned flooding method.

The available functions cover HTTP requests, TCP connections, UDP packets, Slowloris-style connection exhaustion, and DNS or NTP amplification routines. This activity aligns with the broader MITRE ATT&CK Network Denial of Service technique.

One of the most aggressive routines, combo_worker, combines several protocols during each loop. It issues GET, POST, HEAD, and OPTIONS requests with randomized headers, sends a UDP datagram, and opens a short-lived TCP connection.

Attack category	Observed implementation
HTTP flooding	High-volume requests with randomized methods, headers, and query strings
TCP flooding	Repeated short-lived connections followed by minimal HTTP requests
UDP flooding	Repeated random datagrams sent to ports associated with HTTP or HTTPS
Slowloris	Partial HTTP requests that attempt to hold server connections open
DNS amplification	Code intended to generate reflected DNS traffic
NTP amplification	Code intended to request amplified responses from NTP services
Combined flooding	HTTP, UDP, and TCP activity within the same worker loop

Thread Auto-Scaling Attempts to Maintain Traffic

The operator selects a target request rate and initial worker count. NULLZEREPTOOL distributes the requested rate across its worker threads and applies a minimum delay to limit excessive CPU use.

The framework can start with as many as 1,000 worker threads. A separate auto-scaling routine checks performance every 15 seconds and adds threads when the measured request rate falls below 70 percent of the configured target.

The scaler can increase the total to 2,000 threads. A watchdog checks the target every five seconds and stops the session when HTTP and TCP checks indicate that the target no longer responds.

Observed Sessions Produced Mixed Results

The source and associated Telegram activity contained records of six attack sessions. One session against shopmuabancf[.]com used 100 workers and a target of 20,000 requests per second. The displayed request count increased to more than 10,000 before the operator stopped the session.

Other sessions produced little or no traffic. A run against a Bloomberg quote page configured a target of 200,000 requests per second, but its counter remained at zero before the watchdog marked the page unavailable.

These records show the framework’s control flow and reporting interface. They do not independently prove that every target suffered an outage or that the tool achieved its configured request rate.

Target shown in session	Configured method	Target RPS	Recorded request count
shopmuabancf[.]com	Combo	20,000	10,404
shopbloxfruits[.]com	Combo	2,000	6
trangchubloxfruit[.]com	Combo	50,000	132
bloomberg[.]com/quote/FRGH:SW	Combo	200,000	0
daula[.]shop	Combo	50,000	6
shoptienzombie[.]net	Combo	50,000	54

Rotating Proxy System Draws From Seven Sources

NULLZEREPTOOL collects public HTTP proxies from seven sources, including ProxyScrape, GeoNode, Free Proxy List, and four raw GitHub lists. It then checks each proxy before adding it to the active pool.

The validation process sends requests through each proxy with a five-second timeout. It retains proxies that respond within two seconds and stores them in proxy.txt as well as an in-memory list.

During an attack, the framework selects a random proxy, tests it again with a shorter timeout, and removes failed entries. The Telegram proxy-update command refreshes the source lists and rebuilds the validated pool.

Later Variant Adds WiFi and Bluetooth Commands

The second variant expands beyond DDoS attacks with WiFi scanning, saved-password extraction, handshake cracking, client deauthentication, and Bluetooth disruption routines.

These functions largely wrap existing operating-system commands and external tools. The Linux WiFi deauthentication routine calls aireplay-ng, while the Windows version uses netsh wlan disconnect. Bluetooth functions depend on tools such as l2ping and hcitool.

Several modules require root access, compatible wireless hardware, a Bluetooth adapter, capture tools, and password-cracking software. Flare did not observe operators using these features and could not confirm their end-to-end functionality.

• WiFi scanning through operating-system networking commands
• Saved WiFi password extraction through netsh or nmcli
• Handshake capture through hcxdumptool
• Handshake conversion through hcxpcapngtool
• Dictionary attacks through hashcat
• WiFi client deauthentication through aireplay-ng
• Bluetooth flooding or disconnection through Linux utilities

Botnet Hierarchy Lacks a Client Component

The later code introduces a BOTNET_HIERARCHY structure for tracking master nodes, slave nodes, task queues, completed jobs, and collected information. It also adds Flask endpoints for slave registration, task retrieval, and result reporting.

The proposed task types include wifi_scan, browser_steal, and full_steal. However, researchers found no code for reading browser credential stores, decrypting browser passwords, or parsing browser databases.

Flare also found no client.py file in the analyzed material. Without that client component, researchers could not exercise the registration and tasking workflow or confirm that the framework operated as a distributed botnet.

“Quantum” Features Use Standard Cryptography

The later variant contains classes named WiFi7QuantumExploit and Bluetooth6QuantumExploit. Their function names advertise quantum handshakes, channel jamming, packet bypasses, and location spoofing.

The implementation uses standard Python functions such as SHA3-512, PBKDF2-HMAC, random-byte generation, hexadecimal token creation, and binary data packing. Researchers found no quantum algorithms or novel cryptographic techniques.

The names appear to serve as marketing for a possible Malware-as-a-Service offering. Security teams should focus on the code’s actual process execution, raw-socket, network, and file activity rather than its labels.

Card Storage and Licence Keys Suggest Commercial Plans

Both versions include a manual card-data logging feature. The Telegram administrator can enter a card number, CVV, and expiration date, which the framework stores in a cvv_logs table inside the c2.db SQLite database.

The framework does not automatically collect card data. Its functions only let an operator manually add and retrieve records, suggesting an unfinished or unrelated feature.

NULLZEREPTOOL also creates single-use, expiring access keys. Administrators can generate, list, and revoke keys, which could support tiered access, resale, or a DDoS-for-hire service. Static analysis cannot confirm whether the operator sold access.

How Defenders Can Detect NULLZEREPTOOL Activity

Organizations should watch for mixed HTTP methods, rapidly changing query strings, randomized User-Agent and Referer values, and repeated X-Forwarded-For headers. A short period containing GET, POST, HEAD, and OPTIONS traffic from the same sources may indicate the combo routine.

Network teams should also monitor large UDP bursts to ports 80 and 443, high rates of short-lived TCP connections, incomplete HTTP headers, reflected DNS responses, and unusual NTP traffic. These patterns also support detection of network denial-of-service activity beyond this framework.

On suspected operator or staging systems, defenders can search for the Python framework, hardcoded credentials, Telegram API connections, Flask endpoints, and its local files.

Indicator type	Indicator	Context
Telegram administrator ID	7593738229	Hardcoded administrator check
Static password	7788	Used by the Telegram login command
File	proxy.txt	Stores validated proxies
File	c2.db	Stores clients, attacks, reports, and manual card records
File	keys.json	Stores access keys
File	history.json	Tracks key usage and access history
Flask paths	/register, /get_command, /report	Core client-management endpoints
Flask paths	/slave_register, /slave_get_task, /slave_report	Later hierarchical botnet endpoints
Paste identifier	ryxQ077S	Later source variant
Paste identifier	Rxk4VgnX	Earlier source variant

Organizations Should Prepare for Proxy-Based Floods

Rotating public proxies can reduce the effectiveness of simple single-address blocking. Defenders should combine rate limits with behavioral analysis, web application firewalls, upstream filtering, content delivery networks, and dedicated DDoS protection.

The CISA DDoS response guidance recommends understanding which systems provide critical services, coordinating with internet and cloud providers, and preparing communication and recovery procedures before an attack begins.

Organizations should establish traffic baselines, confirm escalation contacts, and test failover plans. They should also preserve network records because proxy rotation may force investigators to correlate behavior across many source addresses.

• Apply per-session and per-account rate controls where appropriate.
• Use behavioral rules that identify repeated mixed HTTP methods.
• Coordinate mitigation procedures with hosting, CDN, and internet providers.
• Filter spoofed traffic and restrict unnecessary UDP services.
• Monitor unusual Telegram API access from servers and administrative systems.
• Block unneeded outbound access to public proxy lists.
• Review systems for exposed Flask management endpoints.
• Preserve firewall, load balancer, CDN, and application logs.

Defenders should not block legitimate DNS resolvers, NTP pools, proxy-list services, or websites solely because the source code mentions them. Teams should evaluate traffic context and distinguish attack infrastructure from services or targets that the framework attempted to use.

Flare characterizes NULLZEREPTOOL as a Telegram-managed DDoS panel with experimental feature expansion, not a proven multifunction botnet. Its technical analysis says the DDoS core appears complete, while the newer wireless and botnet additions remain dependency-bound and operationally unconfirmed.

Organizations can use the federal DDoS guidance to structure preparation, response, and recovery plans for this framework and other denial-of-service threats.

FAQ