Google a annoncé le 2 juillet 2026 avoir coordonné une action avec le FBI, Lumen et d’autres partenaires contre le réseau de proxies résidentiels NetNut, également désigné Popa. Google affirme avoir désactivé des comptes et services utilisés pour le commandement et le contrôle, partagé des renseignements techniques et renforcé Play Protect contre des applications intégrant les composants concernés. La maison mère de NetNut a confirmé la saisie de certains domaines par le FBI, tout en indiquant enquêter sur une éventuelle utilisation malveillante de ses services par des tiers. La leçon pour les entreprises dépasse cette affaire : un logiciel fiable dépend aussi de ses SDK, plugins, packages, API et équipements connectés.
Ce qui s’est passé — et ce que les sources permettent réellement d’affirmer
Le 2 juillet 2026, le Google Threat Intelligence Group a annoncé une opération coordonnée avec le FBI, Lumen et d’autres partenaires contre le réseau de proxies résidentiels NetNut, que Google désigne également sous le nom de Popa.
Google indique avoir désactivé des comptes et services associés au commandement et au contrôle, partagé des renseignements techniques sur les SDK et l’infrastructure, renforcé les protections Google Play Protect et réduit de plusieurs millions le nombre d’appareils disponibles pour le réseau.
Dans un document transmis à la SEC, Alarum Technologies, maison mère de NetNut, a confirmé que certains domaines associés à NetNut avaient été saisis par le FBI. Le 3 juillet, l’entreprise précisait qu’elle n’avait pas encore été formellement contactée par les autorités et qu’elle enquêtait pour déterminer si son réseau ou ses services avaient été utilisés à des fins malveillantes, frauduleuses ou illégales par des tiers. Le 4 juillet, elle a annoncé une suspension temporaire d’une partie des services concernés afin de poursuivre ses investigations.
Une saisie de domaines, un rapport technique ou une enquête ne constituent pas une condamnation. Cet article distingue donc les actions confirmées, les observations publiées par Google et les chercheurs, ainsi que la position déclarée par l’entreprise concernée.
Chronologie synthétique
| Date | Événement public | Lecture professionnelle |
|---|---|---|
| Avant juillet 2026 | Des chercheurs documentent des SDK et infrastructures associés à des réseaux de proxies résidentiels sur des appareils grand public. | La dimension technique précède l’action des autorités. |
| 2 juillet 2026 | Google annonce son action coordonnée avec le FBI, Lumen et d’autres partenaires. | Comptes, infrastructure, protections Android et renseignements sont mobilisés. |
| 2–3 juillet | Alarum confirme la saisie de domaines associés à NetNut. | Une partie des services est perturbée. |
| 4 juillet | Alarum annonce une pause temporaire de certains services réseau. | L’entreprise poursuit son enquête et ses mesures de précaution. |
Un proxy résidentiel, c’est quoi exactement ?
Un proxy est un intermédiaire entre un utilisateur et le service Internet qu’il souhaite atteindre. Au lieu de voir l’adresse IP d’origine, le site visité voit l’adresse IP du proxy.
Dans un réseau de proxies résidentiels, les points de sortie utilisent des adresses attribuées par des fournisseurs d’accès à des foyers ou de petites entreprises. Elles ressemblent davantage à des connexions ordinaires qu’à des serveurs hébergés dans un datacenter.
Utilisateur du service proxy
↓
Infrastructure du fournisseur
↓
Appareil résidentiel utilisé comme nœud de sortie
↓
Site ou service ciblé
↓
Le service ciblé voit l’adresse IP du foyerUn proxy résidentiel peut avoir des usages légitimes : tester l’affichage d’un site depuis plusieurs régions, vérifier une campagne publicitaire ou analyser la disponibilité d’un service. Le problème apparaît lorsque les appareils sont enrôlés sans information suffisante, lorsque les clients sont mal contrôlés ou lorsque le réseau sert à masquer des opérations frauduleuses.
Un proxy résidentiel n’est pas automatiquement illégal. Le risque dépend du consentement, de la transparence, de la sécurité de l’enrôlement, du contrôle des clients et des usages réellement autorisés.
Botnet, proxyware, nœud de sortie : pourquoi les mots comptent
BotnetRéseau d’appareils commandés
Ensemble d’équipements contrôlés à distance pour exécuter des tâches coordonnées.
Exemple : lancer une attaque DDoS, envoyer du spam ou relayer du trafic.
Point clé : l’utilisateur légitime ignore souvent la participation de son appareil.
ProxywareLogiciel de partage de connexion
Composant permettant de louer ou partager la bande passante et l’adresse IP d’un appareil.
Exemple : une application propose une rémunération en échange de la connexion inutilisée.
Point clé : la transparence et le consentement sont déterminants.
Nœud de sortieDernier relais visible
Appareil depuis lequel la requête quitte le réseau proxy vers sa destination.
Exemple : le site ciblé voit l’adresse IP de la télévision ou du routeur du foyer.
Point clé : l’activité d’un tiers peut être attribuée à cette connexion.
C2Commandement et contrôle
Infrastructure utilisée pour transmettre des instructions ou configurer les composants du réseau.
Exemple : domaines indiquant aux nœuds quels relais contacter.
Point clé : perturber le C2 peut dégrader fortement le réseau.
Pour approfondir cette différence de vocabulaire, l’article Arrêtons de tout appeler « IA » : remettre les bons mots sur les bons systèmes rappelle pourquoi un bot, une automatisation et un agent IA ne désignent pas la même chose.
Comment un appareil peut-il rejoindre un réseau de proxies ?
Selon Google, les appareils peuvent être enrôlés par un logiciel préinstallé avant l’achat, une application contenant du code proxy caché ou un système de partage de bande passante présenté de manière insuffisamment claire.
Développeur d’une application
↓
Intégration d’un SDK de monétisation ou de proxy
↓
Installation sur une TV, une box ou un téléphone
↓
Démarrage du composant
↓
Connexion à une infrastructure distante
↓
Réception et relais de trafic tiers
↓
L’appareil devient un nœud de sortieLe point critique n’est pas seulement l’installation initiale. Une bibliothèque peut récupérer sa configuration à distance, changer de serveur, modifier son comportement ou être intégrée à plusieurs applications sans rapport apparent.
Pourquoi les adresses IP résidentielles intéressent-elles les attaquants ?
Les systèmes de défense savent souvent identifier les adresses issues d’hébergeurs, de VPN publics ou de réseaux anonymes connus. Une adresse appartenant à un fournisseur d’accès résidentiel peut paraître plus proche d’un utilisateur normal.
Google indique avoir observé, pendant une seule semaine de juin 2026, 316 groupes de menaces distincts utilisant des nœuds suspectés d’être liés à NetNut. Les usages observés comprenaient le masquage de l’origine de connexions, l’accès à des infrastructures et des attaques par pulvérisation de mots de passe.
| Usage possible | Pourquoi le proxy aide | Risque pour la cible |
|---|---|---|
| Password spraying | Répartir les tentatives entre de nombreuses adresses ordinaires. | Les seuils par adresse IP deviennent moins efficaces. |
| Prise de contrôle de comptes | Faire ressembler la connexion à celle d’un utilisateur local. | Les signaux réseau perdent en fiabilité. |
| Scraping massif | Changer fréquemment d’adresse et contourner certaines limitations. | Extraction de données et hausse de charge. |
| Fraude publicitaire | Générer des interactions depuis des adresses dispersées. | Mesures faussées et budgets détournés. |
| Masquage d’infrastructure | Dissimuler les serveurs réellement utilisés. | Investigation et attribution plus difficiles. |
Une connexion peut être ralentie, bloquée ou considérée comme suspecte. Google avertit également que le passage de trafic non autorisé peut exposer davantage les autres équipements présents sur le même réseau.
La vraie leçon pour les entreprises : auditer la chaîne de confiance logicielle
Peu d’entreprises écrivent seules l’intégralité de leurs applications. Un site, un logiciel ou une automatisation repose souvent sur des dizaines de composants externes :
- plugins WordPress et extensions e-commerce ;
- packages npm, Composer ou Python ;
- SDK publicitaires, analytics ou paiement ;
- API de messagerie, scraping ou intelligence artificielle ;
- images Docker et dépendances système ;
- applications installées sur des téléviseurs, tablettes ou box ;
- workflows communautaires importés dans n8n.
Cette logique rejoint l’article Assistant, automatisation ou agent IA : un prototype peut fonctionner tout en restant impossible à auditer, difficile à mettre à jour ou trop dépendant d’un service tiers.
Cas concret : une chaîne d’hôtels équipe ses chambres de téléviseurs connectés
Hôtel Lumière est une société fictive exploitant cinq établissements. Pour proposer des chaînes internationales et des applications de streaming, elle achète des téléviseurs connectés et des box Android auprès de plusieurs fournisseurs.
L’équipe informatique vérifie le Wi-Fi et les mots de passe, mais personne ne possède une liste complète des applications préinstallées, des mises à jour disponibles ou des domaines contactés par ces équipements.
| Constat | Risque | Correction |
|---|---|---|
| Applications préinstallées non documentées. | Comportement réseau inconnu. | Inventaire, suppression ou remplacement de l’image système. |
| Équipements sur le même réseau que la réception. | Exposition possible d’autres services internes. | VLAN ou réseau IoT séparé. |
| Mises à jour absentes depuis deux ans. | Failles non corrigées. | Politique de durée de support fournisseur. |
| Installations manuelles depuis des APK. | Origine et intégrité non maîtrisées. | Sources approuvées et procédure de validation. |
| Aucun suivi du trafic sortant. | Connexion anormale invisible. | DNS filtrant, journaux et alertes réseau. |
{
"asset_id": "HOTEL-AVIGNON-TV-204",
"type": "TELEVISEUR_CONNECTE",
"marque": "Exemple",
"modele": "TV-400",
"version_os": "12.3",
"reseau": "VLAN-IOT-20",
"applications": [
{
"nom": "StreamingApp",
"source": "STORE_OFFICIEL",
"version": "4.8.1",
"editeur": "Éditeur identifié",
"permissions": ["RESEAU"],
"sdk_tiers_connus": ["analytics"],
"validation": "APPROUVEE"
}
],
"domaines_sortants_observes": [
"api.editeur.example",
"updates.fabricant.example"
],
"derniere_mise_a_jour": "2026-07-20",
"fin_support": "2028-12-31",
"responsable": "Équipe informatique",
"niveau_risque": "MOYEN"
}Le but n’est pas d’interdire tous les équipements connectés. Il est de savoir ce qui est installé, ce qui communique, qui le maintient et comment isoler le risque.
La méthode d’audit en huit étapes
1. Inventorier les actifs
Recenser téléviseurs, box, caméras, routeurs, tablettes, applications, extensions et services cloud.
2. Identifier les propriétaires
Attribuer un responsable métier et technique à chaque composant important.
3. Reconstituer les dépendances
Lister les SDK, bibliothèques, plugins, images et API intégrés.
4. Observer les communications
Identifier les domaines, ports, volumes et fréquences de trafic sortant attendus.
5. Vérifier les permissions
Comparer les droits demandés avec la fonction réelle du logiciel.
6. Contrôler la maintenance
Vérifier versions, correctifs, fins de support et procédures de retrait.
7. Segmenter le réseau
Isoler les équipements IoT et limiter leurs communications.
8. Tester le retrait
Savoir désactiver rapidement une application, bloquer un domaine ou remplacer un fournisseur.
Un audit utile ne produit pas uniquement une liste de vulnérabilités. Il attribue les responsabilités, hiérarchise les risques et définit les actions réalisables.
Les questions à poser avant d’intégrer un SDK ou un service tiers
Objet : évaluation de sécurité avant intégration de votre SDK
Merci de préciser :
1. Les fonctions exactes exécutées par le SDK.
2. Les données collectées, leur finalité et leur durée de conservation.
3. La liste des domaines et services externes contactés.
4. Les permissions techniques nécessaires.
5. Les mécanismes de mise à jour du code et de la configuration.
6. Les sous-traitants et infrastructures utilisés.
7. Les contrôles appliqués à vos propres clients.
8. Les journaux disponibles en cas d’incident.
9. Votre procédure de notification de vulnérabilité.
10. La méthode de désactivation ou de retrait du SDK.
11. La durée de support et la fréquence des correctifs.
12. Les audits indépendants disponibles.Quels signaux peuvent révéler un comportement anormal ?
Aucun indicateur isolé ne prouve qu’un appareil appartient à un réseau de proxies. Plusieurs signaux combinés peuvent toutefois justifier une investigation.
| Signal | Explication possible | Action |
|---|---|---|
| Trafic sortant constant lorsque l’appareil est inutilisé. | Synchronisation, publicité, télémétrie ou relais. | Comparer avec le comportement attendu. |
| Connexions vers de nombreux domaines inconnus. | CDN légitime ou infrastructure de contrôle. | Identifier l’éditeur et la réputation. |
| Hausse inexpliquée de la consommation réseau. | Mise à jour, streaming ou trafic tiers. | Mesurer par équipement et horaire. |
| Adresse IP fréquemment bloquée ou soumise à des CAPTCHA. | Réputation dégradée par une activité inhabituelle. | Vérifier les journaux et le FAI. |
| Application inconnue ou impossible à désinstaller. | Composant système ou logiciel indésirable. | Isoler puis vérifier l’image constructeur. |
| Équipement qui ne reçoit plus de correctifs. | Fin de support. | Remplacer ou isoler fortement. |
Que faire si un appareil ou un composant semble compromis ?
Isoler l’équipement
Le retirer du réseau principal ou bloquer temporairement ses communications.
Documenter le contexte
Noter l’heure, l’adresse IP, le modèle, les applications et les changements récents.
Conserver les journaux utiles
Exporter les événements réseau, DNS, pare-feu et administration disponibles.
Révoquer les accès associés
Changer ou révoquer les identifiants et clés potentiellement exposés.
Vérifier les appareils voisins
Rechercher les mêmes applications, versions, domaines ou comportements.
Corriger ou remplacer
Mettre à jour, restaurer depuis une source maîtrisée ou retirer l’équipement.
Une réinitialisation immédiate peut effacer des éléments utiles. Lorsque des données clients ou plusieurs établissements sont concernés, il est préférable d’impliquer un spécialiste de la réponse à incident.
Quel rapport avec les projets IA, les agents et les automatisations ?
Un agent peut utiliser un navigateur distant, une API de scraping, un connecteur communautaire, une base vectorielle ou un proxy externe. Chacun de ces composants agrandit la chaîne de confiance.
Avant de connecter un agent aux outils de l’entreprise, il faut vérifier qui héberge le service, où transitent les données, quelles actions le connecteur peut réaliser, comment les accès sont révoqués, quels journaux existent et quelle solution de remplacement est prévue.
L’article Assistant, automatisation ou agent IA : choisir la bonne architecture explique pourquoi un système ne doit recevoir que l’autonomie nécessaire. L’article Une stratégie IA ne commence pas par ChatGPT rappelle que le choix d’un outil doit venir après l’analyse du besoin, des risques et des données.
La checklist à retenir pour une entreprise
Ce que l’affaire NetNut/Popa doit changer dans nos projets
Le sujet ne se résume pas à des téléviseurs transformés en relais. Il montre comment une fonctionnalité discrète, intégrée à une application ou à un appareil, peut devenir une infrastructure mondiale lorsque des millions d’installations sont connectées au même réseau.
Pour une entreprise, la leçon est simple : la confiance ne doit pas s’arrêter au nom du logiciel ou à la réussite de la démonstration. Elle doit descendre jusqu’aux composants, aux permissions, aux flux réseau, aux fournisseurs et aux procédures de retrait.
Le bon réflexe n’est pas d’interdire tous les services tiers. Il est de pouvoir expliquer pourquoi ils sont présents, ce qu’ils font et comment les arrêter.
Vos applications, automatisations ou équipements reposent sur des composants que personne n’a réellement audités ?
J’accompagne les entreprises dans l’inventaire de leurs outils, l’analyse des dépendances, la sécurisation des API et workflows, la documentation technique et la mise en place de contrôles adaptés.
Échanger sur votre environnementQuestions fréquentes
NetNut et Popa désignent-ils exactement la même chose ?
Google présente NetNut comme un réseau de proxies résidentiels également connu sous le nom Popa. Des chercheurs utilisent Popa pour désigner des composants et appareils enrôlés. Il est préférable de préciser la source de cette association.
Un proxy résidentiel est-il forcément malveillant ?
Non. Il peut exister des usages légitimes. Les enjeux concernent le consentement, la transparence, la sécurité, le contrôle des clients et les activités autorisées.
Comment savoir si ma télévision faisait partie du réseau ?
Il n’existe pas de test universel. Vérifiez les applications, les mises à jour, la provenance, les alertes Play Protect et les communications réseau. En cas de doute, isolez l’équipement et demandez une analyse.
Une application provenant d’une boutique officielle est-elle toujours sûre ?
Une boutique officielle réduit certains risques, mais ne remplace pas les mises à jour, l’analyse des permissions et la surveillance du comportement.
Pourquoi séparer les objets connectés du réseau professionnel ?
La segmentation limite les communications possibles entre un appareil compromis et les postes, serveurs ou imprimantes de l’entreprise.
Le même risque existe-t-il avec un plugin WordPress ou un package npm ?
La forme change, mais le principe reste proche : un composant tiers exécute du code dans votre environnement. Il faut vérifier sa provenance, ses permissions, sa maintenance et son retrait.
Faut-il bloquer tous les proxies résidentiels ?
La réponse dépend du service. Une entreprise peut renforcer l’authentification, limiter les tentatives et surveiller les comportements plutôt que se reposer uniquement sur l’adresse IP.
Sources et ressources
- Google Threat Intelligence Group — opération contre NetNut, 2 juillet 2026
- SEC — Form 6-K d’Alarum Technologies
- SEC — déclarations des 2, 3 et 4 juillet 2026
- KrebsOnSecurity — FBI Seizes NetNut Proxy Platform, Popa Botnet
- Google Threat Intelligence Group — opération précédente contre IPIDEA
- Department of Justice — opération SocksEscort, mars 2026
- Department of Justice — opération contre plusieurs botnets IoT, mars 2026
