Entre mai et juillet 2026, 148 paquets malveillants ont été publiés sur le registre npm sous des noms comme "charlie-kirk", "ilovefemboys", et "miguelphonk". Ces paquets distribuaient une application proxy web habillée sous le nom "Lucide" et stylisée comme des pages d'accueil de services de tutorat fictifs ("Riverbend Tutoring" ou "Northstar Tutoring"). En surface, les paquets ressemblaient à de l'adware classique : publicités popunder, scripts de monétisation tiers, et tracking Google Analytics. En réalité, JFrog et SafeDep ont découvert deux modules cachés sous cette couche d'adware qui transformaient silencieusement le navigateur de chaque visiteur en une arme DDoS capable de générer environ 10 240 tentatives de connexion par seconde.
La cible principale du botnet était cdn.caan.edu, le réseau de diffusion de contenu d'une école de sciences infirmières à Matteson, Illinois, qui recevait des inondations HTTP d'environ 2 mégaoctets par seconde par navigateur actif. SafeDep a catalogué 141 paquets lors d'une première vague en mai, et une deuxième vague le 8 juillet 2026 a porté le total à 148. Au 14 juillet 2026, des versions actives du paquet "charlie-kirk" restaient encore accessibles sur le registre npm.
Le registre npm est l'un des dépôts de paquets open source les plus grands et les plus utilisés au monde, avec des millions de paquets hébergeant du code JavaScript consommé par des applications web, des serveurs Node.js, et des outils de développement. La publication de paquets sur npm est ouverte à tous et rapide : un compte développeur, une commande, et un paquet est disponible pour tous les consommateurs du registre.
Cette ouverture fait de npm un vecteur attrayant pour des utilisations malveillantes qui ne ciblent pas les développeurs qui installent les paquets mais les utilisateurs finaux des applications distribuées via npm. Dans le cas de la campagne "Lucide", les attaquants n'essayaient pas d'infecter les machines des développeurs qui auraient installé ces paquets en tant que dépendances. Ils utilisaient npm comme plateforme d'hébergement gratuite et à forte disponibilité pour distribuer une application web côté serveur qui servirait leur payload DDoS à tous les visiteurs de leur service proxy.
Cette distinction est importante pour la compréhension du risque. La sécurité de la chaîne d'approvisionnement npm est généralement discutée dans le contexte des packages installés comme dépendances dans des projets de développement. Cette campagne exploite npm différemment : non pas comme un vecteur d'infection de la chaîne de développement, mais comme une infrastructure d'hébergement gratuite et fiable pour une application malveillante côté serveur. npm n'a pas vocation à héberger des serveurs web en production, mais il fournit des mécanismes qui permettent de le faire, et les attaquants ont exploité ces mécanismes.
JFrog a déobfusqué le bundle d'entrée de 5,4 mégaoctets qui composait l'application Lucide et identifié deux modules cachés sous la couche d'adware apparente. Le premier module, que les chercheurs ont désigné G2, est un chargeur de script distant. G2 récupère du JavaScript depuis une branche mutable d'un dépôt GitHub via le CDN jsDelivr, sans vérification d'intégrité de sous-ressource (Subresource Integrity). Une fois ce script chargé et exécuté dans le navigateur du visiteur, il dispose d'un accès complet aux cookies, au stockage local, et aux endpoints de même origine de la page. Cette capacité va bien au-delà de ce dont un adware a besoin : elle représente un niveau d'accès qui permettrait d'exfiltrer des données de session ou de réaliser des actions au nom de l'utilisateur sur les pages qu'il visite.
Le deuxième module, désigné I2, est le générateur de flood WebSocket. I2 ouvre 30 connexions WebSocket simultanées vers un endpoint proxy Wisp hébergé sur lunaron[.]top et envoie des trames Wisp CONNECT et CLOSE toutes les 100 millisecondes, ciblant le port localhost:1. À pleine capacité, un seul navigateur actif sur une connexion internet standard peut générer environ 10 240 tentatives de connexion par seconde. La multiplication par le nombre de visiteurs simultanés du service proxy donne une mesure de la puissance DDoS agrégée : même avec un nombre modeste de visiteurs simultanés, le botnet peut générer un volume de trafic significatif contre une cible unique.
L'utilisation du protocole Wisp comme vecteur du flood est un choix technique délibéré. Wisp est un protocole utilisé par des services de proxy web étudiants pour tunneliser du trafic TCP arbitraire via des connexions WebSocket depuis un navigateur, permettant à des étudiants de contourner des filtres réseau en renvoyant le trafic internet via un serveur proxy externe. Les services proxy basés sur Wisp sont courants dans le contexte des réseaux scolaires et universitaires. Les opérateurs de la campagne Lucide ciblaient à la fois les visiteurs de leurs propres services proxy (dont les navigateurs exécutaient le module I2) et les serveurs Wisp des services proxy concurrents, qui recevaient le flood de connexions des modules I2.
Le Centre d'Apprentissage Accéléré en Nursing (CAAN) à Matteson, Illinois, est une école de formation infirmière dont le CDN a reçu des volumes de trafic anormaux générés par le botnet de la campagne Lucide. La cible peut sembler inhabituelle : une école de formation médicale dans une ville de banlieue de Chicago n'est pas le type d'organisation typiquement citée dans des rapports sur les attaques DDoS de grande échelle. Mais dans le contexte d'un botnet opéré par des acteurs dont le profil suggère une jeunesse plutôt qu'une organisation criminelle structurée, le choix de la cible peut refléter un conflit personnel ou une provocation plutôt qu'une motivation financière ou politique.
Les 93 noms d'hôte de déploiement qui ont effectué des requêtes vers la configuration Wisp entre le 21 et le 30 mai 2026 se résolvaient à 90% vers une seule adresse IP chez G-Core Labs (92.38.177[.]17), ce qui suggère que la majorité des instances du service proxy Lucide partageaient la même infrastructure backend pendant la phase de déploiement initiale. Cette concentration facilite le blocage au niveau IP pour les cibles du botnet, mais elle indique aussi que les opérateurs n'ont pas investi dans une infrastructure C2 distribuée ou résiliente pour leur opération DDoS.
JFrog a réalisé un travail de regroupement d'infrastructure qui a fourni plusieurs éléments d'attribution. L'organisation GitHub "lucideproxy" était associée à des comptes créés à quelques secondes d'intervalle, suggérant une création automatisée ou coordonnée. L'email de commit enregistré pointait vers le domaine geeked[.]wtf. Un script de publication automatique avait été oublié dans les tarballs des paquets, révélant le processus d'automatisation utilisé pour déployer les paquets à grande échelle. Un commentaire dans le service worker mentionnait "TY WAVES + CHATGPT ILY", une expression de remerciement informelle qui combine un pseudonyme et une référence à l'outil utilisé pour écrire du code. Un seul compte a poussé 116 paquets en moins de 35 minutes lors d'une session de publication.
Ces indices pointent vers des individus relativement jeunes opérant dans un contexte ludique ou compétitif plutôt qu'une organisation criminelle professionnelle. L'utilisation de noms de paquets comme "charlie-kirk" et "ilovefemboys" est cohérente avec la culture de certaines communautés en ligne. Cela ne réduit pas la sérieux de l'impact : un botnet DDoS est dangereux indépendamment de la sophistication ou de la maturité de ses opérateurs, et les 148 paquets représentent une infrastructure de botnet fonctionnelle distribuée via un canal de confiance.
Suite aux rapports de SafeDep et JFrog, npm a remplacé la majorité des paquets malveillants par le placeholder standard "0.0.1-security", qui indique qu'un paquet a été retiré pour des raisons de sécurité et remplacé par un stub vide. Ce processus de retrait est la réponse standard de npm aux paquets malveillants découverts sur le registre, et il est généralement efficace pour limiter la distribution supplémentaire du paquet une fois qu'il a été identifié.
Cependant, les chercheurs ont noté qu'au 14 juillet 2026, les versions 2.0.0 et 3.0.1 du paquet "charlie-kirk" restaient actives sur le registre npm. La deuxième vague de paquets déployée le 8 juillet 2026, sous un nouveau compte, avait supprimé la couche d'adware visible des builds pour produire des paquets plus propres en apparence, mais le module DDoS restait accessible via un simple changement de commit dans la branche mutable du dépôt GitHub. Cette architecture de "payload-as-a-branch" illustre comment le code malveillant peut être séparé du paquet distribué de façon à rendre la détection par analyse statique du paquet lui-même plus difficile : le paquet est "propre" au moment de la soumission, et le module malveillant est chargé dynamiquement depuis une source externe.
La campagne npm Lucide soulève des questions importantes sur la sécurité des applications web qui chargent du JavaScript depuis des dépôts publics. Le module G2 exploitait spécifiquement l'absence de Subresource Integrity (SRI) dans l'application Lucide. SRI est un mécanisme de sécurité web qui permet aux développeurs de spécifier une empreinte cryptographique (hash) du contenu d'un script externe attendu : le navigateur refuse de charger le script si son contenu ne correspond pas au hash. Si l'application Lucide avait utilisé SRI pour le script chargé depuis jsDelivr, la modification du contenu de la branche GitHub n'aurait pas pu produire d'effet : le navigateur aurait détecté la discordance et refusé l'exécution.
L'absence de SRI dans les applications web qui chargent du contenu depuis des CDN ou des dépôts publics est répandue, même dans des contextes où la sécurité est une préoccupation affichée. La campagne Lucide illustre concrètement le risque que cette absence représente : un attaquant qui contrôle le dépôt source d'un script chargé sans SRI peut modifier le comportement de toutes les instances de l'application qui chargent ce script, sans aucune modification visible du code de l'application elle-même. La cyber threat intelligence sur ce type de campagne permet aux équipes de sécurité d'anticiper les vecteurs d'attaque qui ciblent leur stack technologique et d'implémenter les contrôles préventifs, comme SRI, avant qu'ils ne soient exploités.
L'absence de Subresource Integrity dans l'application Lucide est le vecteur technique central que le module G2 exploite. Il est utile de comprendre pourquoi SRI est absent de nombreuses applications web malgré ses avantages de sécurité évidents. SRI impose que le développeur connaisse à l'avance la valeur de hachage exacte du contenu qu'il va charger depuis une URL externe. Pour un fichier statique qui ne change jamais, c'est simple : on calcule le hash une fois et on le fixe dans la balise script. Mais pour du contenu chargé depuis des branches mutable de dépôts Git, des CDN qui servent des versions "dernière" d'une bibliothèque, ou des endpoints qui génèrent du contenu dynamiquement, SRI est incompatible avec la façon dont le contenu est servi.
Les applications qui veulent pouvoir mettre à jour leur code frontend sans modifier le code source de la page principale choisissent souvent de charger leurs scripts depuis des URLs qui pointent vers une version "courante" plutôt qu'une version fixe. Cette architecture sacrifie la sécurité de SRI pour la flexibilité opérationnelle. La campagne Lucide exploite précisément cette architecture : le script chargé via jsDelivr depuis la branche GitHub peut être modifié côté serveur à tout moment, et tous les navigateurs qui chargent la page récupéreront et exécuteront le nouveau contenu sans aucune vérification d'intégrité.
La leçon défensive est que les applications web qui dépendent de scripts chargés depuis des dépôts Git ou des CDN devraient utiliser des références à des commits ou des versions spécifiques plutôt que des références à des branches ou des "dernières versions", et devraient implémenter SRI sur ces références spécifiques. Une application qui charge son script depuis "github/lucideproxy/main/script.js" (une branche mutable) est vulnérable à toute modification du fichier dans cette branche. Une application qui charge depuis "github/lucideproxy/abc1234def567/script.js" (un hash de commit immuable) avec un attribut SRI correspondant est protégée contre toute modification non autorisée du contenu chargé.
La campagne Lucide soulève une question de politique pour l'écosystème npm : dans quelle mesure le registre npm devrait-il être responsable de surveiller les paquets qui, bien qu'ils ne contiennent pas de code malveillant au moment de leur inspection, hébergent des applications web qui servent des payloads malveillants à leurs visiteurs ? La distinction entre "paquet npm malveillant" (un paquet qui infecte le développeur qui l'installe) et "paquet npm hébergeant une application malveillante" (un paquet qui infecte les visiteurs de l'application) n'est pas clairement adressée dans les politiques de sécurité npm actuelles.
Les outils de détection automatisée de npm sont principalement optimisés pour détecter les paquets qui exécutent du code malveillant lors de l'installation (via des scripts postinstall) ou qui contiennent du code malveillant dans leur propre codebase. Un paquet qui distribue une application web "propre" qui charge dynamiquement un module malveillant depuis une source externe après déploiement est techniquement propre au moment de l'analyse statique. C'est ce que la deuxième vague de paquets Lucide déployée le 8 juillet a exploité : les builds de la deuxième vague avaient supprimé même la couche d'adware, ne laissant que l'application proxy "propre", pendant que le module DDoS restait accessible via un changement de commit dans la branche GitHub externe.
Cette limitation des outils d'analyse statique pour les paquets qui chargent du contenu dynamique depuis des sources externes est structurelle et difficile à résoudre au niveau du registre. npm ne peut pas analyser ce que fait une application en cours d'exécution dans un contexte de navigateur visiteur. La réponse plus prometteuse est au niveau des navigateurs et des politiques de sécurité des contenus (Content Security Policy), qui peuvent restreindre les origines depuis lesquelles une page est autorisée à charger des scripts.
L'école de sciences infirmières de Matteson, Illinois (CAAN) n'est pas une organisation avec une équipe de sécurité dédiée ou les ressources pour absorber et analyser une attaque DDoS. C'est précisément pourquoi elle peut avoir été choisie : une cible qui ne peut pas déployer rapidement des contre-mesures contre un flood DDoS est une cible qui souffrira plus longtemps et plus visiblement de l'attaque. La nature du botnet de navigateur signifie que le trafic d'attaque provient de nombreuses adresses IP différentes (celles des visiteurs du service proxy), ce qui rend le blocage basé sur l'IP de l'attaquant impossible. La cible ne peut pas bloquer "l'attaquant" parce que l'attaquant est en réalité une multitude d'utilisateurs innocents dont les navigateurs ont été transformés en arme à leur insu.
Pour les petites organisations qui sont dans une position similaire à celle de CAAN, c'est-à-dire des organisations avec une présence web publique mais sans ressources de sécurité dédiées, la protection contre les attaques DDoS par botnet de navigateur passe par des services de mitigation DDoS tiers plutôt que par des mesures défensives propres. Des services comme ceux proposés par Cloudflare, Akamai, ou des équivalents régionaux proposent des niveaux gratuits ou peu coûteux qui peuvent absorber des volumes de trafic significatifs avant qu'ils n'atteignent l'infrastructure d'hébergement de la cible. La mise en place de ces protections ne nécessite pas d'expertise en sécurité interne : c'est essentiellement une configuration DNS qui redirige le trafic web entrant via l'infrastructure de mitigation.
Pour les utilisateurs qui ont accédé à des services de proxy web dans un contexte scolaire ou universitaire, identifier si le service utilisé était un proxy Lucide compromis n'est pas trivial. Les services Lucide se présentaient comme des services de tutorat légitimes, avec des interfaces professionnelles qui n'indiquaient pas visuellement leur nature malveillante. Les indicateurs qui permettraient à un utilisateur averti de suspecter un problème incluent la présence de nombreuses fenêtres popup ou publicités agressives (caractéristique de la couche adware), des connexions WebSocket inhabituelles visibles dans les outils de développement du navigateur, et des volumes de trafic réseau anormalement élevés pendant l'utilisation du service.
Les utilisateurs qui ont accédé à l'un des proxies Lucide et qui veulent vérifier si leur navigateur a exécuté le module DDoS peuvent examiner l'historique des connexions WebSocket dans les outils de développement de leur navigateur (onglet Réseau, filtré sur WebSocket). Des connexions vers lunaron[.]top ou des volumes élevés de connexions WebSocket vers des endpoints inconnus pendant la période d'utilisation du service sont des indicateurs de participation involontaire au botnet. Si ces indicateurs sont présents, les utilisateurs devraient vider le cache de leur navigateur, supprimer les cookies, et examiner si des extensions de navigateur inhabituelles ont été installées pendant ou après l'utilisation du service, bien que l'architecture de Lucide ne nécessitait pas l'installation d'extensions pour exécuter le module DDoS, celui-ci fonctionnant entièrement dans la page web elle-même.
La connaissance des indicateurs de compromission s'applique ici dans un contexte inhabituel : les "victimes" ne sont pas les organisations ciblées par le DDoS mais les utilisateurs innocents dont les navigateurs ont été utilisés comme arme. Pour ces utilisateurs, la compromission est passive et ne leur cause pas de dommage direct au-delà de la consommation de leur bande passante, mais il est important qu'ils comprennent leur rôle involontaire dans l'attaque pour éviter de continuer à utiliser des services similaires à l'avenir.
Les attaques comme celles décrites dans cet article rappellent pourquoi la surveillance proactive de votre exposition externe ne peut pas rester optionnelle. Quand des identifiants sont volés, quand des agents IA sont manipulés, ou quand des données d'organisation circulent dans des canaux souterrains, les dégâts sont souvent déjà faits au moment où votre équipe les détecte.
Defendis surveille le dark web, les forums criminels et les marchés souterrains pour remonter les preuves d'exposition de votre organisation avant que les attaquants ne passent à l'action. Si des identifiants ou des données liés à votre organisation apparaissent dans un log de stealer ou une annonce de broker, Defendis les remonte avec le contexte complet : l'individu concerné, les données exposées, et comment la compromission s'est probablement produite.
Réservez une démo pour voir Defendis en action.
