Réseaux et infrastructures
Particuliers et entreprisesCompromission d’objets connectés
IoT compromise
Une caméra, un routeur ou un autre objet connecté est piraté et sert d’accès ou de relais.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Une caméra connectée conserve un ancien logiciel et un accès distant mal protégé. Un tiers peut en prendre le contrôle, observer ce qu’elle voit ou l’utiliser pour envoyer du trafic vers d’autres cibles.
Comment cela fonctionne
Une caméra, un routeur ou un équipement domotique est un petit ordinateur connecté au réseau, parfois aussi à un compte en ligne. L’attaquant peut passer par l’objet, son application, son service cloud ou ses identifiants. Tous ces appareils ne reçoivent pas les mêmes mises à jour. Comme ils fonctionnent souvent sans qu’on les regarde, leurs anomalies peuvent passer plus facilement inaperçues que sur un ordinateur.
- Un objet possède un accès fragile
Compte, logiciel ou service distant.
- Un tiers en prend le contrôle
Capteurs, réglages ou calcul.
- L’objet devient un point d’appui
Surveillance, trafic ou accès au réseau.
Les signes qui doivent attirer l’attention
- Un appareil communique fortement ou à des horaires inhabituels.
- Des réglages, comptes ou ouvertures réseau changent.
- L’accès distant se comporte différemment ou un fournisseur annonce une faille.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Changez les mots de passe initiaux et activez les mises à jour de vos objets. Désactivez les accès distants inutiles et séparez ces appareils du réseau de travail lorsque possible.
Si vous êtes responsable du service ou de l’organisation
Inventoriez les objets, leurs comptes cloud et leur durée de support. Isolez les équipements non maintenus en tenant compte de leur fonction et des risques physiques.
Si la faiblesse reste présente après la réinitialisation, l’appareil peut être piraté à nouveau.
À vous de décider
La caméra a été réinitialisée, mais son compte cloud est toujours compromis. Est-elle à l’abri ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Le compte cloud peut encore ouvrir l’accès aux images ou permettre de reprendre la main. Sécurisez l’appareil, son application et les comptes associés.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un équipement connecté communique avec une destination inconnue
La caméra cam17 envoie un volume inhabituel vers une destination externe, puis tente de joindre le réseau interne sur le port 23. Ces deux observations justifient une vérification. Le volume ne suffit pas à prouver un vol de vidéo : une mise à jour, des données de fonctionnement ou le service cloud du fabricant peuvent aussi produire du trafic.
Les équipements connectés fournissent souvent peu de journaux. Les traces du commutateur, du pare-feu, du DNS et du serveur DHCP deviennent alors essentielles pour attribuer une communication au bon appareil. Tenir compte des changements d’adresse et conserver le modèle, la version du micrologiciel et les paramètres de gestion.
Une vulnérabilité connue ne suffit pas à établir qu’elle a été exploitée sur cet appareil. Chercher les modifications de configuration, les nouveaux comptes et les communications apparues pendant la période. Pour limiter les conséquences, séparer le réseau des équipements des postes et serveurs, restreindre leurs sorties et fermer les accès d’administration inutiles. Une réinitialisation doit être suivie d’une configuration sûre et, si disponible, d’un micrologiciel fiable.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Flux vidéo attendu
Objet cam17 vers Services internes
Trace référentiel métier
- Action
Connexion externe
Objet cam17 vers Pare-feu IoT
Trace 84 Mo sortants
- Action
Flux autorisé
Pare-feu IoT vers Destination externe
Trace contenu inconnu
- Action
Tentatives latérales
Objet cam17 vers Pare-feu IoT
Trace ports et destinations
- Refus / blocage
Refus de communication
Pare-feu IoT vers Services internes
Trace journal de blocage
- Action sur place
Collecte avant redémarrage
Objet cam17
Trace configuration et uptime
- Action
Quarantaine contrôlée
Pare-feu IoT vers Objet cam17
Trace fonction physique préservée
Comment repérer cette attaque
Indices à rechercher
Repérer les destinations, ports et volumes inhabituels pour l’usage de l’équipement, les communications latérales et les accès d’administration inattendus.
Quelles informations comparer
Comparer les nouveaux flux aux changements de firmware et aux interventions planifiées. Distinguer ce qui sort effectivement de l’objet des tentatives bloquées par le réseau.
Ce que ces indices ne permettent pas de conclure
Une caméra peut envoyer beaucoup de données pour son usage normal. Sans capture ou trace applicative, un volume sortant ne révèle pas s’il contient une vidéo légitime ou des données détournées.
Comment réagir
Placer l’objet dans un segment de quarantaine compatible avec les besoins physiques, préserver la configuration puis restaurer depuis une source vérifiée. Renouveler les secrets partagés et vérifier les accès à l’enregistreur. Documenter les objets non maintenables et organiser leur remplacement.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- Vérifier que la caméra conserve uniquement ses flux vidéo, temps et maintenance approuvés.
- Tester le refus d’accès aux réseaux utilisateurs depuis le VLAN objets.
- Contrôler la version et l’intégrité du firmware après restauration, puis observer le comportement sur une période représentative.
À vous de raisonner
Une caméra émet beaucoup de données vers une destination inconnue. Quels éléments manque-t-il pour parler d’exfiltration vidéo ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Vérifiez l’attribution de l’adresse au bon appareil sur la période, la destination et les usages du fabricant, puis les changements de configuration. Le volume peut correspondre à une mise à jour ou un service cloud. Une tentative vers le réseau interne renforce le besoin d’investigation, sans identifier le contenu transmis.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
baseline- Profil de référence mesuré avant l’incident, à ne pas fabriquer après coup à partir du seul trafic suspect.
blocked- Tentative empêchée dans le scénario, pas preuve d’un déplacement réussi vers un autre équipement.
Inventaire et flux sortants
JournalLes octets indiquent la direction mesurée par le pare-feu ; la destination est une adresse de documentation.
asset=cam17 model=M2 firmware=3.4 vlan=cameras owner=batiment-A
baseline destinations=ntp.local,video.local,vendor-update.example
flow src=cam17 dst=198.51.100.24 dst_port=443 bytes_out=84000000 bytes_in=12000
flow src=cam17 dst=10.20.4.8 dst_port=23 result=blocked
flow src=cam17 dst=10.20.4.9 dst_port=23 result=blocked
change_ticket firmware_update=none maintenance_window=falsePréparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Sonde réseau Zeek — conn.log
- Où les trouver
- Sur une sonde déjà placée sur le trajet du trafic, ou dans le collecteur de ses journaux conn.log. Identifier le point d’observation, notamment avant ou après traduction d’adresses.
- Quoi relever
- Depuis le segment de la caméra ou de l’objet, relever destinations, ports et volumes, puis comparer à son profil habituel. Associer l’IP à l’équipement à l’heure des faits via l’inventaire et les baux DHCP.
- Accès et prérequis
- La sonde doit avoir vu le trafic. uid, adresses, ports, orig_bytes et resp_bytes décrivent les échanges observés ; les octets réseau ne sont pas le contenu d’un document ni son destinataire humain.
Pare-feu pfSense — journal Firewall
- Où les trouver
- Status → System Logs → Firewall, ou export distant : interface, règle, action, adresse et port source, adresse et port de destination.
- Quoi relever
- Chercher les tentatives vers d’autres segments, en particulier les règles de refus. Vérifier si les flux autorisés étaient également journalisés.
- Accès et prérequis
- Seules les règles configurées pour journaliser produisent ces traces. Un refus décrit un paquet bloqué ; ce journal n’est pas à lui seul un relevé exhaustif des volumes de transfert.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Dans l’administration de l’équipement ou sa collecte syslog si elle était activée, demander connexions d’administration, changements de configuration et mises à jour. Les possibilités dépendent du modèle et du firmware.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- RéseauOpérateurs de Mirai
Des objets connectés transformés en armée de machines
Les opérateurs de Mirai utilisent des caméras, des routeurs et des enregistreurs piratés pour envoyer un trafic massif vers des services et les submerger. Après la diffusion du code du logiciel, d’autres acteurs en créent et utilisent des variantes.
Ce qu’établit la source. Trois créateurs et opérateurs de la variante initiale ont plaidé coupable en 2017. Mirai désigne un logiciel et ses réseaux de machines, pas un groupe unique derrière toutes les variantes.
Consulter le rapport Charges and Guilty Pleas in Three Computer Crime Cases Involving Significant DDoS AttacksU.S. Department of Justice · Publié le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
- Isolez l’objet suspect si cela ne crée pas de danger physique.
- Sécurisez aussi le compte cloud et l’application associés.
- Restaurez selon les instructions du fabricant ou remplacez un appareil qui ne peut plus être maintenu.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- ETSI — Consumer IoT security — etsi.org
- MITRE ATT&CK — Network Denial of Service — attack.mitre.org
- NIST — capacités de cybersécurité IoT — csrc.nist.gov
- OWASP — IoT Security Testing Guide — owasp.org
