NULLZEREPTOOL : Au cœur d’une infrastructure d’attaques DDoS et multifonctionnelles contrôlée par Telegram

Par Sukant Kumar, chercheur en cybersécurité

Un simple message Pastebin, repéré par le système de surveillance des sites de partage de contenu de Flare le 29 avril 2026, contenait l'intégralité du code source Python d'un framework d'attaque contrôlé par Telegram. Cette découverte a permis d'identifier une seconde version, plus ancienne, du même code source et d'observer la session Telegram en direct de l'opérateur. Il en est résulté un outil à double personnalité : d'un côté, un moteur DDoS éprouvé ; de l'autre, une liste croissante de fonctionnalités d'attaques sans fil, de vol d'identifiants et de botnets, présentes uniquement dans le code et jamais observées en fonctionnement. NULLZEREPTOOL offre une étude de cas illustrant l'évolution des outils Malware-as-a-Service (MaaS) de bas niveau, leurs méthodes de test et de commercialisation, et les axes de détection prioritaires pour les équipes de défense.

NULLZEREPTOOL Il s'agit d'un framework d'attaque basé sur Python et contrôlé via Telegram. Deux variantes du code source ont été observées et analysées : une première variante axée sur les attaques DDoS et la gestion de proxy, et une seconde variante conservant toutes les fonctionnalités précédentes tout en ajoutant des modules d'attaque Wi-Fi/Bluetooth, l'extraction d'identifiants et une structure hiérarchique de tâches pour un botnet. Les deux variantes partagent les mêmes identifiants codés en dur (jeton du bot, identifiant d'administrateur, mot de passe, clé principale). L'analyse statique des deux variantes confirme une implémentation entièrement côté serveur. Les ajouts relatifs au Wi-Fi, à l'extraction d'identifiants et au botnet dans la seconde variante sont implémentés dans le code, mais absents de tout artefact client dans l'ensemble analysé.

Principales conclusions concernant NULLZEREPTOOL : 

• Le même jeton de bot, l'identifiant d'administrateur et les mêmes informations d'identification statiques apparaissent dans les deux variantes de code, établissant ainsi une filiation directe entre les deux variantes.
• Le moteur DDoS contrôlé par Telegram (20 méthodes, mise à l'échelle automatique, rotation des proxys) est entièrement implémenté dans le code source : les threads de travail, l'autoscaler, le watchdog et le pipeline de proxys sont tous présents et codés pour fonctionner comme décrit dans l'analyse ci-dessous. 
• La version ultérieure ajoute la découverte Wi-Fi, l'extraction de mots de passe (/wifipass), le craquage (/wificrack), la désauthentification (/deauth), la perturbation Bluetooth (/btdeauth), les classes de paquets « Quantum » (cryptographie standard uniquement) et une hiérarchie des tâches esclaves (BOTNET_HIERARCHY). Ces fonctionnalités sans fil et de vol d'identifiants représentent une extension atypique par rapport aux attaques DDoS, s'inscrivant dans la tendance à l'ajout de fonctionnalités courante dans les outils MaaS bas de gamme.
• L'API botnet basée sur Flask (/register, /get_command, /report) est implémentée dans les deux variantes, mais /listbots a renvoyé « aucun client connecté » – aucun code client n'est présent dans l'ensemble d'artefacts analysés.
• Dans la variante la plus récente, les fonctionnalités d'attaque sans fil, d'extraction d'identifiants et de déploiement de botnets sont implémentées uniquement côté serveur. Aucun fichier binaire client (client.py) n'est présent dans l'ensemble d'artefacts analysés ; le fonctionnement complet de ces fonctionnalités ne peut donc être confirmé à partir du code source disponible.

Découverte initiale sur Pastebin

Événement de haute gravité signalé sur Flare (Flare (Lien vers l'article ; inscrivez-vous à l'essai gratuit pour y accéder si vous n'êtes pas déjà client.)

Les sites de partage de code restent un canal fréquent de diffusion de code source de logiciels malveillants, et Flare, qui surveille ces dépôts, signale régulièrement les publications suspectes. Le 29 avril 2026, Flare a signalé une publication Pastebin contenant le code source Python complet d'un bot d'attaque DDoS contrôlé par Telegram. 

Bannière NULLZEREPTOOL

Découverte antérieure de variantes via le pivot « NULLZEREPTOOL » (Flare (Lien vers l'article ; inscrivez-vous à l'essai gratuit pour y accéder si vous n'êtes pas déjà client.)

La bannière à l'intérieur du message Pastebin, « NULLZEREPTOOL », C'est devenu le point central. Une recherche par mots-clés sur Flare L'utilisation de cet identifiant a permis de découvrir une version antérieure du même code source. Les identifiants codés en dur et communs aux deux versions (jeton du bot, identifiant d'administrateur et mot de passe) constituent un troisième point d'ancrage analytique confirmant l'origine unique du code source.

Comparaison et évolution des variantes

Informations d'identification et de version du bot Telegram intégré

Les deux variantes de code partagent les mêmes identifiants codés en dur : BOT_TOKEN, ADMIN_ID = « 7593738229 », ADMIN_PASSWORD = « 7788 ». Outre ces jetons, la variante la plus récente conserve toutes les fonctionnalités de la variante la plus ancienne : les mêmes méthodes de traitement DDoS, la même logique de récupération de proxy, le même schéma SQLite (tables c2.db : clients, attacks, reports, cvv_logs), les mêmes routes Flask (/register, /get_command, /report) et les mêmes fichiers de gestion des clés (keys.json, history.json). Les commentaires en vietnamien et les chaînes de réponse du bot sont identiques dans les deux versions. Aucune fonction essentielle n’est supprimée ; la variante la plus récente est un sur-ensemble fonctionnel strict de la variante la plus ancienne.

L'évolution des outils est additive. La dernière variante introduit trois nouveaux domaines de capacités : les attaques sans fil, la gestion hiérarchique des tâches des botnets et les modules de type « quantique ». (Chacun est abordé en détail dans les sections suivantes)Les défenseurs peuvent s'appuyer sur les mêmes indicateurs de détection pour les deux variantes, les surfaces supplémentaires n'étant introduites que dans la version ultérieure.

Analyse du code : Implémenté vs. Confirmé

L'analyse statique des deux variantes du code source révèle une structure cohérente : un framework DDoS et C2 côté serveur entièrement implémenté, auquel s'ajoutent ultérieurement des fonctionnalités codées mais présentant des dépendances non résolues ou des composants client manquants. Le moteur DDoS, le pipeline proxy, les contrôles d'authentification et le système de gestion des clés sont complets. La conception du système de gestion des clés, basé sur l'expiration d'une clé unique, est compatible avec les modèles de distribution à accès hiérarchisé ou de revente. Le système est complet dans le code source ; son utilisation opérationnelle ne peut être évaluée par une simple analyse statique.

Capacités de base mises en œuvre

Moteur DDoS : mécanisme et comportement observé

Flux de travail du moteur d'attaque DDoS

Dictionnaire des méthodes

Le moteur d'attaque utilise un MÉTHODES Un dictionnaire associe 20 noms d'attaques à des fonctions de traitement. Chaque fonction s'exécute dans un thread dédié et répète une méthode d'attaque spécifique, par exemple l'envoi en boucle de requêtes HTTP GET ou de paquets UDP. Chaque fonction calcule son propre délai en fonction du nombre de requêtes par seconde (RPS) cible divisé par le nombre total de fonctions. Le moteur d'attaque crée un thread par fonction ; tous les threads s'exécutent simultanément. 

fonction combo_worker

Le travailleur le plus complet est travailleur combiné, à chaque itération réussie de sa boucle principale, il exécute :

• Quatre requêtes HTTP (GET, POST, HEAD, OPTIONS) avec des en-têtes et des chaînes de requête aléatoires via une requests.Session.
• Un paquet UDP (1 024 octets de données aléatoires) vers le port cible (80 pour HTTP, 443 pour HTTPS).
• Une connexion TCP (uniquement une prise de contact SYN, aucune charge utile envoyée) vers le port cible, qui est immédiatement fermée.

logique de délai des travailleurs

L'orchestrateur d'attaques calcule le délai de chaque nœud de calcul en fonction du nombre d'opérations par seconde (RPS) cible. La formule garantit que le RPS total configuré est réparti entre tous les nœuds, avec un délai minimal d'une milliseconde par nœud afin d'éviter une utilisation excessive du processeur. 

logique de limitation des threads

Le moteur lance initialement jusqu'à 1 000 threads. Chaque thread exécute la méthode d'attaque sélectionnée en continu jusqu'à l'arrêt de l'attaque ou jusqu'à ce que la cible devienne inaccessible. Le nombre initial de threads est limité par une validation explicite.

Un thread d'autoscaling distinct s'exécute toutes les 15 secondes pour maintenir le débit. Si le nombre de requêtes par seconde (RPS) observé chute en dessous de 70 % de la valeur cible et que le nombre actuel de processus est inférieur à 2 000, il calcule un nouveau nombre de processus (nombre actuel × 1.2 + 10), le plafonne à 2 000 et crée des threads supplémentaires pour atteindre ce nouveau nombre.

Fonction de surveillance Web

Un processus de surveillance vérifie la disponibilité de la cible toutes les cinq secondes. Il envoie une requête GET avec des en-têtes aléatoires et, en cas d'échec, tente d'établir une connexion TCP avec le port de la cible. Si la cible ne répond plus, le processus de surveillance interrompt l'attaque et signale l'incident. “WEB ĐÃ CHẾT!” En vietnamien, cela se traduit par « Le web est mort. »

Attaque contre shopmuabancf[.]com

Le programme orchestrateur d'attaque est programmé pour transmettre des statistiques périodiques à l'administrateur Telegram pendant une exécution, notamment le nombre cumulé de requêtes et le nombre total de processus en cours : La première tentative contre shopmuabancf[.]com avec 100 travailleurs et un objectif de 20 000 RPS a produit des messages statistiques périodiques montrant que le nombre de requêtes passait de 402 à 10 254 avant l'arrêt manuel.

Attaque contre Bloomberg

Demande de cessation d'attaque sur Bloomberg

Le système de mise à l'échelle automatique est programmé pour se déclencher toutes les 15 secondes lorsque le RPS observé descend en dessous de 70 % de la valeur cible, augmentant ainsi le nombre de nœuds de calcul d'un facteur 1.2 plus 10, avec un plafond de 2 000. Le système de surveillance web fonctionne en parallèle, vérifiant la disponibilité de la cible toutes les cinq secondes et interrompant l'attaque si la cible ne répond plus.

Le moteur DDoS est implémenté comme décrit. En pratique, le débit serait limité par la qualité du pool de serveurs proxy, les défenses côté cible et le temps de réponse des nœuds de calcul (temps d'attente + temps de requête) dépassant l'intervalle de délai calculé. Ces facteurs ne peuvent être évalués par une simple analyse statique.

Positionnement parmi des outils similaires

Son mode de contrôle s'apparente à celui d'une plateforme de gestion de DDoS bas de gamme (configuration via Telegram, retour d'information en temps réel). Contrairement aux botnets IoT à propagation automatique tels que Mirai, cet outil nécessite un déploiement manuel et enregistre plusieurs fichiers sur le disque, générant ainsi une empreinte numérique plus importante. Parmi les outils contrôlés par Telegram, il se situe entre les simples bots d'alerte et ceux qui utilisent des résolveurs de boîtes aux lettres mortes ou des algorithmes de génération de domaines.

Pipeline proxy : de la récolte à la rotation

Pipeline proxy multi-étapes

Les deux variantes implémentent un pipeline de proxys à plusieurs étapes. La fonction Fetch_free_proxies() collecte les proxys à partir de sept sources : api.proxyscrape[.]com, proxylist.geonode[.]com, free-proxy-list[.]net et quatre autres URL brutes GitHub. 

Vérification de l'état du proxy

La fonction `update_proxy_list()` teste chaque proxy avec `httpbin[.]org/ip` dans un délai de cinq secondes, mesure le temps de réponse et ne conserve que ceux répondant en moins de deux secondes. L'ensemble validé est enregistré dans `proxy.txt`. La fonction `get_random_proxy()` sélectionne une entrée aléatoire dans la liste en mémoire, la teste à nouveau avec un délai de trois secondes, et supprime les proxys défaillants de la liste en mémoire pendant l'exécution de l'attaque.

La rotation des proxys est essentielle à l'exécution d'une attaque. La commande `/proxy update` déclenche successivement les fonctions `fetch_free_proxies()` et `update_proxy_list()`, actualisant et validant ainsi le pool de proxys. Cette étape est indispensable avant toute attaque, car `get_random_proxy()` sélectionne un proxy dans la liste validée en mémoire lors de l'exécution, confirmant ainsi le rôle crucial de la rotation des proxys. 

Telegram C2 : Authentification et contrôle

Authentification Telegram

Le bot utilise telebot.Telebot avec le jeton intégré. La fonction is_admin() vérifie l'identifiant utilisateur de l'expéditeur par rapport à ADMIN_ID = 7593738229. Le dictionnaire logged_in suit l'état de la session et est réinitialisé après une connexion réussie (/login 7788). Les commandes telles que /attacks, /proxy, /key et /cvv vérifient toutes is_logged_in() avant leur exécution.

État du client connecté

Le backend Flask (/register, /get_command, /report) est entièrement codé dans les deux variantes du code source. La commande /listbots interroge la table des clients dans c2.db. Aucun binaire client (client.py) n'est présent dans l'ensemble d'artefacts analysés, ce qui signifie que le processus d'inscription n'a pas d'équivalent dans le code source disponible. 

Stockage CVV : implémenté mais inactif

Fonction de collecte CVV

Les deux variantes utilisent un système de stockage manuel des CVV conçu pour permettre à l'administrateur d'enregistrer et de récupérer les données des cartes. Il ne s'agit pas d'un mécanisme de récupération automatisé. Un tableau cvv_logs est créé dans c2.db avec les colonnes cc, cvv, exp et time. La commande vérifie que trois arguments sont fournis, insère les données dans la table cvv_logs avec un horodatage et confirme l'enregistrement à l'opérateur.

Commande getcvv

La commande /getcvv interroge la table cvv_logs et renvoie tous les enregistrements stockés. Une table vide renvoie une réponse « nodata » en vietnamien. 

L'intégration d'un mécanisme de stockage manuel du CVV dans un outil dédié aux attaques DDoS est atypique. Les frameworks DDoS privilégient la perturbation de la disponibilité ; le stockage des données de cartes de paiement indique une dérive vers le vol de données, ce qui pourrait élargir l'attrait de l'outil en tant qu'offre MaaS multifonctionnelle ou centraliser la journalisation de l'opérateur pour des campagnes distinctes de récupération d'identifiants.

Système de génération de clés : Mécanisme de contrôle d'accès commercial

Les deux variantes de code utilisent un système de gestion de clés de type licence pour contrôler et restreindre l'accès au bot. Ce système permet de générer, de lister et de supprimer les clés d'accès, et son infrastructure est compatible avec les modèles d'accès à plusieurs niveaux ou de revente.

Assistant de gestion des clés

Les deux variantes de code incluent les mêmes fonctions de gestion des clés : `load_keys()`, `save_keys()`, `generate_key()`, `create_key()`, `delete_key()`, `check_key()` et `use_key()`. `generate_key()` utilise `secrets.token_hex(10)`, produisant une chaîne hexadécimale de 20 caractères. La valeur par défaut `max_uses=1` signifie que chaque clé est à usage unique ; elle est épuisée après une seule utilisation.

Commandes administratives

Exemple de clé générée

• /clé [jours] – Génère une nouvelle clé d'accès.
• /clés – Liste toutes les clés existantes, en indiquant les dates d'expiration et l'état d'utilisation (nombre d'utilisations par rapport au nombre maximal d'utilisations).
• /delkey – Révoquer une clé.

L'architecture du système de gestion des clés (clés à usage unique et à durée de vie limitée, commandes de génération/liste/révocation, et génération aléatoire de secrets.token_hex(10)) est compatible avec une distribution à accès hiérarchisé ou une revente. Le système est complet dans son code source ; son fonctionnement ne peut être évalué par une analyse statique. 

Ajouts pour les versions ultérieures : implémentés mais non confirmés

La variante ultérieure a introduit plusieurs domaines de fonctionnalités entièrement nouveaux. Bien que le code soit présent, aucun binaire client n'est présent dans l'ensemble d'artefacts analysés et plusieurs fonctionnalités présentent des dépendances externes non résolues.

Modules d'attaque sans fil : implémentation et dépendances

Déconnexion Linux

La variante la plus récente implémente des routines d'attaque WiFi et Bluetooth avec des chemins d'accès distincts pour Linux et Windows. Le gestionnaire de déconnexion sous Linux orchestre aireplay-ng avec des paramètres pour les adresses MAC du point d'accès et de la cible, tandis que l'implémentation Windows utilise la commande netsh wlan disconnect. Les deux sont de simples interfaces de commande qui dépendent de la présence d'outils externes ou d'utilitaires système.

Détection de l'adaptateur Bluetooth

Les gestionnaires btdeauth et btlock sont exclusivement disponibles sous Linux et utilisent l2ping -f pour l'inondation et hcitool dc pour la déconnexion. Ces commandes nécessitent les privilèges root et un adaptateur Bluetooth, ce qui rend cette fonctionnalité fortement dépendante de l'environnement.

L'extraction du mot de passe WiFi est implémentée sous forme d'une série d'appels de commandes système. Sous Windows, le gestionnaire lit tous les profils enregistrés via la commande `netsh wlan show profiles`, puis extrait chaque mot de passe avec `netsh`, `wlan`, `show`, `profile`. La commande `key=clear` analyse la sortie à la recherche de la ligne « Key Content ». Sous Linux, le gestionnaire utilise `nmcli` pour interroger les détails de connexion et extraire la clé pré-partagée (PSK). Les résultats sont compilés et renvoyés à l'administrateur Telegram.

capacité de piratage WiFi

Le craquage de réseaux WiFi s'effectue en trois étapes : hcxdumptool capture les échanges de données, hcxpcapngtool convertit la capture au format hashcat, et hashcat effectue le craquage par dictionnaire. Cette fonctionnalité nécessite trois outils externes, une interface sans fil compatible avec la capture et un fichier de mots de passe.

L'ajout de modules d'attaque sans fil et de piratage WiFi représente une extension significative par rapport à la fonction DDoS de base de NULLZEREPTOOL. Les frameworks DDoS ciblent généralement les ressources de la couche réseau ou application, et non les interfaces sans fil de la couche physique ni les gestionnaires d'identifiants. 

Botnet hiérarchique

Hiérarchie des botnets

La dernière variante implémente un modèle de tâches structuré. Le dictionnaire BOTNET_HIERARCHY gère les nœuds maîtres, les nœuds esclaves, les files d'attente de tâches, les tâches terminées et les données collectées. De nouveaux points de terminaison Flask (/slave_register, /slave_get_task, /slave_report) permettent l'enregistrement des esclaves et l'interrogation des tâches. Les commandes Telegram (/botnet_task, /botnetdata, /botnetslaves, /botnetexport) permettent à l'administrateur de créer des tâches, de consulter les données collectées, de lister les esclaves et d'exporter des données au format JSON.

configuration des tâches du botnet

La configuration des tâches inclut des types tels que wifi_scan, browser_steal et full_steal, chacun faisant référence à une liste de modules. Le serveur enregistre l'état, l'attribution et l'horodatage d'achèvement des tâches. Les tâches browser_steal et full_steal font référence à « browser_credentials » comme module.

Nous n'avons toutefois observé aucune fonction permettant de lire les gestionnaires de mots de passe du navigateur. Il n'y a ni Win32Crypt, ni trousseau de clés, ni analyse de base de données spécifique au navigateur. Cette fonctionnalité n'est mentionnée que dans la configuration de la tâche et dans les bannières d'aide. « VOLEUR À VOLONTÉ » Cette fonctionnalité n'est pas implémentée côté serveur. La bannière d'aide de la version ultérieure fait référence à ces fonctionnalités, mais la logique sous-jacente permettant le vol d'identifiants de navigateur est absente. 

L'implémentation côté serveur est terminée, mais le client (client.py) est absent de l'ensemble d'artefacts ; sans lui, le flux d'enregistrement et d'attribution des tâches ne peut être mis en œuvre et la fonctionnalité de bout en bout ne peut être confirmée.

Cette fonctionnalité est exclusivement côté serveur. Sans le binaire client, son fonctionnement de bout en bout ne peut être confirmé. Les équipes de sécurité qui détectent des points de terminaison Flask dans le trafic réseau doivent les considérer comme des indicateurs d'un serveur C2 utilisant NULLZEREPTOOL. 

Stratégie de marque « quantique » : aucune technologie nouvelle observée

Module d'exploitation WiFi de marque Quantum

Le Exploitation quantique du WiFi7 et Exploitation de Bluetooth6Quantum Les classes implémentent des méthodes aux noms évocateurs de la physique quantique : craft_pmf_bypass_packet, craft_wpa4_quantum_handshake, wifi7_mimo_flood, craft_ble6_channel_sounding_jam, craft_le_audio_bypass_packet et ble6_aoa_spoof. Mais leurs implémentations utilisent :

• hashlib.sha3_512 pour la génération de faux MIC et la dérivation de clés
• hashlib.pbkdf2_hmac pour une « fausse PMK » (Pre-Master Key)
• os.urandom et secrets.token_hex pour l'aléatoire
• struct.pack pour l'assemblage binaire du cadre de la couche MAC

L'appellation « quantique » relève du marketing et ne désigne pas la technologie elle-même. Le code utilise des primitives de cryptographie et de construction de paquets standard, sans aucun algorithme quantique. Cette pratique est courante dans les écosystèmes MaaS bas de gamme, où le marketing sert à surestimer les capacités perçues. Les équipes de défense ne doivent pas considérer « quantique » comme une menace nouvelle ; la détection doit se concentrer sur le comportement des sockets et des sous-processus sous-jacents.

Cibles d'attaque observées

Le code source définit le déroulement complet de l'attaque : URL cible, sélection de la méthode, nombre de processus, RPS cible, seuils de mise à l'échelle automatique et conditions d'arrêt du système de surveillance. Le tableau ci-dessous récapitule les paramètres implémentés et les comportements attendus tels que définis dans le code :

Le débit réel lors du déploiement dépendra de la qualité du pool de proxys, des défenses côté cible et de l'environnement d'exécution. Ces facteurs ne peuvent être évalués par une analyse statique. 

Stratégies de détection et de défense

Indicateurs de réseau (entrants vers vos actifs)

• Inondations HTTP (combo_worker, http_worker) : Requêtes HTTP/S à volume élevé avec des chaînes User-Agent, Referer, X-Forwarded-For et de requête aléatoires (par exemple, ? = &_= ). Un mélange de méthodes GET, POST, HEAD et OPTIONS provenant des mêmes adresses IP sources dans des intervalles de temps très courts.
• Inondations UDP (udp_worker, combo_worker) : Un volume important de datagrammes UDP est envoyé vers les ports 80 ou 443. Le processus combo_worker envoie des paquets de 1 024 octets, tandis que le processus udp_worker envoie des paquets de 2 048 octets par lots de 10 à chaque itération de la boucle. Les règles de détection doivent prendre en compte ces deux tailles.
• Inondations TCP (tcp_worker) : Volumes élevés de connexions TCP de courte durée vers les ports 80 ou 443. Chaque connexion effectue une poignée de main complète en trois étapes et envoie une requête HTTP GET minimale (GET / HTTP/1.1\r\nHost : \r\n\r\n) avant une fermeture immédiate. Recherchez des débits de connexion élevés avec une charge utile minimale.
• Amplification DNS (dns_amplification_worker) : Un volume important de requêtes DNS volumineuses (50 répétitions de www.example.com) est envoyé à des serveurs DNS publics (8.8.8.8, 1.1.1.1, etc.) avec des adresses IP sources usurpées pointant vers la cible. La détection s'effectue via le débit des requêtes DNS sortantes ou les inondations de réponses DNS entrantes (généralement > 1 500 octets par réponse).
• Amplification NTP (ntp_amplification_worker) : Des requêtes monlist sont envoyées à des serveurs NTP publics (time.google.com, pool.ntp.org, etc.), provoquant un important flux de réponses renvoyé à la cible. Ce phénomène est détecté via les paquets monlist (0x17 0x00 0x03 0x2a) ou le flux de réponses NTP entrantes.

Pivots de renseignement exploitables

Cartographie MITRE ATT&CK

Ce que les équipes de sécurité peuvent retenir de NULLZEREPTOOL

Les renseignements initiaux provenaient d'une surveillance passive des sites de partage de contenu public via Flare, qui a signalé le message Pastebin (NULLZEREPTOOL). Le message du 29 avril 2026, combiné à la variante précédente (27 avril 2026), a révélé un cadre d'attaque en évolution avec un noyau DDoS entièrement implémenté et un ensemble de fonctionnalités ultérieures en expansion dont la fonctionnalité de bout en bout ne peut être confirmée à partir des artefacts sources disponibles. 

NULLZEREPTOOL est avant tout un panneau de contrôle DDoS géré par Telegram, et non une plateforme de botnet distribué ou d'exploitation de réseaux sans fil. Le moteur DDoS, la rotation des proxys et les contrôles d'authentification sont entièrement implémentés dans le code source. La dernière version introduit des fonctionnalités atypiques pour un outil DDoS : désauthentification sans fil, brouillage Bluetooth, piratage Wi-Fi et modules « quantiques ». Ces ajouts reflètent la dynamique du marché des solutions MaaS, caractérisée par une prolifération de fonctionnalités, passant de la perturbation de réseau à la proximité physique et au vol d'identifiants. Cependant, ces fonctionnalités sont fortement dépendantes et aucune n'a été observée en fonctionnement, ce qui suggère que l'outil est encore en phase de test plutôt qu'en phase de maturité opérationnelle.

Flare de La détection de ces outils souligne l'importance d'une surveillance continue des sites de partage de contenu pour les outils émergents. Pour les équipes de défense, le jeton du bot et l'identifiant d'administrateur, intégrés au code, offrent des points d'appui immédiats et exploitables pour une intervention au niveau de la plateforme, indépendamment de l'évolution des fonctionnalités de l'outil.

Références et sources

1. Responsable initial du renseignement : Flare Global Search – Flare
2. Poste Pastebin (29 avril 2026) : https://pastebin.com/ryxQ077S
3. Poste Pastebin (27 avril 2026) : https://pastebin.com/Rxk4VgnX