Shadow IT & OT 2026 : Détection Wireshark [Guide Terrain]

La détection du Shadow IT et Shadow OT via Wireshark est devenue en 2026 une compétence pivot des équipes audit cybersécurité. Contrairement aux scans actifs qui peuvent provoquer l'arrêt d'un automate ou d'un capteur industriel sensible, la capture réseau passive permet d'inventorier un réseau IT/OT sans aucune perturbation. Ce guide terrain — testé sur des environnements industriels réels et Wireshark 4.x — détaille la configuration des buffers, la rotation des fichiers, les filtres avancés et l'analyse de protocoles industriels (Modbus, EtherNet/IP, PROFINET) pour identifier équipements non déclarés, dérives de configuration et risques inconnus.

---

Introduction : le Shadow IT tue plus vite en OT qu'en IT

Définitions — ce qu'on chasse vraiment

Le Shadow IT désigne tout équipement, application ou service connecté au réseau de l'organisation sans validation formelle de la DSI ou du responsable sécurité. Ce n'est pas forcément malveillant — c'est souvent un employé qui branche son NAS personnel pour "aller plus vite", un prestataire qui installe un accès TeamViewer sans en parler, ou un responsable commercial qui connecte son iPhone en partage de connexion parce que "le Wi-Fi est lent".

Le Shadow OT est la variante industrielle : un automate ajouté à la ligne de production sans mise à jour du schéma réseau, un écran HMI connecté directement sur le réseau corporate pour "simplifier la maintenance", un routeur 4G installé dans une armoire électrique par un intégrateur pressé, un capteur IoT bon marché branché sur le réseau SCADA parce qu'il "offrait des statistiques sympa".

La différence critique entre les deux : en IT, un équipement non déclaré compromet des données. En OT, il peut arrêter une ligne, déclencher une alerte de sécurité physique, ou ouvrir une porte vers votre réseau industriel à n'importe quel acteur malveillant.

Pourquoi les méthodes classiques échouent en OT

La réponse instinctive d'un ingénieur réseau face au Shadow IT est de lancer un scan Nmap. Sur un réseau IT bureautique, c'est raisonnable. Sur un réseau OT, c'est une faute grave :

• Les automates programmables (PLC) Siemens, Schneider Electric, Allen-Bradley sont souvent incapables de gérer un SYN flood — un simple scan de ports peut les resetters ou les mettre en mode défaut
• Les équipements de mesure (flowmètres, capteurs de pression) tournent sur des OS embarqués sans pile TCP robuste — un ping répété peut les rendre inopérants
• Les switchs industriels non managés n'ont aucune protection contre les tempêtes de broadcast générées par des scans agressifs
• Toute interruption même brève d'un équipement en production peut coûter des dizaines de milliers d'euros

La capture passive avec Wireshark résout ce problème fondamentalement : le poste d'analyse génère zéro trafic sur le réseau. Il écoute, sans jamais parler. Du point de vue du réseau, il est invisible.

Ce que Wireshark voit que personne d'autre ne voit

Un équipement réseau — même non déclaré, même sans nom dans votre DNS, même avec une IP statique hors DHCP — émet inévitablement des trames dès qu'il est allumé :

• ARP gratuit au démarrage pour annoncer son IP/MAC
• Broadcasts DHCP s'il cherche une adresse
• mDNS / SSDP pour se faire découvrir par d'autres équipements
• Keepalives, heartbeats vers son serveur ou son contrôleur
• Requêtes DNS vers des destinations externes ou internes
• Trames de protocole OT (Modbus, EtherNet/IP, PROFINET) en multicast ou broadcast

Il suffit d'être au bon endroit sur le réseau pour tout voir. C'est exactement ce que Wireshark fait.

---

Comprendre les enjeux est nécessaire mais ne suffit pas. La détection du Shadow IT et du Shadow OT passe par un prérequis technique souvent sous-estimé : se positionner physiquement au bon endroit du réseau. Sans ce positionnement, votre poste Wireshark ne verra que son propre trafic — et tout le travail qui suit sera inutile. La section qui vient détaille les quatre options disponibles sur le terrain, leurs avantages, leurs coûts et leurs limites, avec un schéma de topologie qui sert de référence dans toute la suite du guide.

Architecture de capture : se positionner correctement

Avant de configurer quoi que ce soit, il faut résoudre le problème fondamental des réseaux commutés : un switch n'envoie les trames qu'au destinataire. Votre poste Wireshark ne voit que son propre trafic — sauf si vous vous connectez sur le bon point.

Les quatre options terrain

Mirror port / SPAN port (Switch Port ANalyzer)

La solution la plus répandue. Vous configurez le switch pour copier le trafic d'un ou plusieurs ports (ou d'un VLAN entier) vers un port dédié où est branché le poste Wireshark. Zéro coût matériel supplémentaire, mais nécessite un switch managé et un accès à la configuration.

Limitation : sur les switchs bas de gamme ou très chargés, le SPAN peut introduire de la perte de paquets si le volume copié dépasse la capacité du port de destination.

TAP réseau (Test Access Point)

Un TAP est un équipement matériel qui se branche en coupure sur le câble réseau et copie optiquement ou électriquement tout le trafic vers vos ports de capture. Il ne traite pas les trames — il les copie bit pour bit. Résultat : zéro perte, zéro latence ajoutée, zéro impact sur le réseau.

En environnement OT critique, c'est la seule solution fiable. Un TAP passif optique continue même sans alimentation électrique. Prix : 150–800 € selon le débit.

Agrégation de liens (agrTAP)

Certains TAPs proposent deux ports de capture (un pour chaque sens du lien) ou un port agrégeant les deux sens. Pour Wireshark, préférez l'agrégation — vous voyez le flux complet dans un seul fichier pcapng.

Hub legacy

Sur les segments 10/100 Mbps half-duplex encore présents dans certains environnements industriels anciens, brancher un hub crée un domaine de collision visible par tous les ports. Solution de dernier recours, ne fonctionne pas en full-duplex.

Topologie typique IT/OT sans VLAN

[Internet]
    |
[Firewall]
    |
[Switch Core IT] ←── Mirror port ──→ [Poste Wireshark]
    |        |
[PCs IT]  [Switch OT]
              |
        [PLCs / HMI / Capteurs]

En l'absence de VLAN, tout le trafic IT et OT passe souvent par le même switch core. Un seul mirror port sur ce switch donne une visibilité complète sur l'ensemble du réseau. C'est la configuration idéale pour détecter le Shadow IT et Shadow OT simultanément.

---

Une fois le poste Wireshark correctement raccordé via mirror port ou TAP, vient la question du paramétrage. Wireshark démarré avec ses paramètres par défaut suffit à dépanner une session SSH lente ; il échoue systématiquement à détecter le Shadow IT/OT sur un réseau réel. Les sections 1 à 3 couvrent les trois réglages indispensables : buffer suffisant pour absorber les pics de trafic, rotation pour capturer en continu sans saturer le disque, et options complémentaires qui font la différence entre une capture pertinente et une capture inexploitable.

1. Augmenter le buffer de capture

C'est le réglage le plus souvent négligé sur le terrain, et celui qui cause le plus de faux négatifs. Un buffer insuffisant fait dropper silencieusement les paquets — exactement les bursts qui signalent la présence d'un équipement Shadow IT.

Chemin GUI

Capture → Options → Output → Capture buffer size (MB)

Comprendre pourquoi le buffer est critique

Wireshark reçoit les trames via l'interface réseau à la vitesse du réseau (100 Mbps, 1 Gbps, 10 Gbps). Il doit les écrire sur disque ou les traiter. Si l'écriture est plus lente que la réception — ce qui arrive lors de pics de trafic — les paquets s'accumulent dans le buffer kernel. Quand le buffer est plein, le kernel droppe les nouveaux paquets.

Les environnements OT/IT mixtes sont particulièrement sensibles car ils combinent : - Des broadcasts industriels (PROFINET cyclique, EtherNet/IP I/O) à haute fréquence - Des sauvegardes réseau nocturnes (SMB à plusieurs centaines de Mo/s) - Des mises à jour firmware d'automates (gros transferts ponctuels) - Des storms de multicast lors du démarrage simultané d'équipements

Valeurs recommandées selon le contexte

Contexte réseau	Buffer recommandé	Justification
Petit réseau bureau (< 50 postes)	128 MB	Trafic prévisible, peu de bursts
Réseau moyen (50–300 postes)	512 MB	SMB, impressions réseau, updates
Réseau chargé / IT+OT mélangés	1 024 – 2 048 MB	Multicast OT + trafic IT simultanés
Backbone / mirror port principal	2 048 – 4 096 MB ✦	Tout le trafic agrégé
Lien 10 Gbps en production	4 096 MB	Indispensable — bursts à 10 Gbps en ms

✦ Recommandation terrain : partez toujours sur 2 048 MB minimum dès qu'il y a du trafic OT. Le surcoût mémoire est négligeable, le coût d'un paquet droppé peut être une heure de débogage.

Détecter les drops — signal d'alerte

Statistics → Capture File Properties → Dropped packets

Si cette valeur est > 0, votre buffer était insuffisant et votre capture est incomplète. Sur le terrain, vérifiez aussi :

# Linux — voir les drops de l'interface en temps réel
watch -n 1 cat /proc/net/dev

# Wireshark CLI — stats de drop pendant la capture
dumpcap -i eth0 -q 2>&1 | grep -E "drop|lost"

Augmenter le buffer kernel indépendamment de Wireshark

Sur Linux, la taille du buffer socket réseau est limitée par le kernel. Pour des captures à haut débit :

# Augmenter le buffer socket de réception (temporaire)
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.rmem_default=67108864

# Permanent — ajouter dans /etc/sysctl.conf
net.core.rmem_max = 67108864
net.core.rmem_default = 67108864

---

Augmenter le buffer évite la perte ponctuelle de paquets lors des bursts, mais ne résout pas la question du temps : pour repérer un équipement Shadow qui ne se manifeste qu'une fois par jour — un automate qui pousse ses télémétries la nuit, un NAS personnel synchronisé pendant la pause déjeuner — il faut capturer en continu pendant 24 à 72 heures. C'est là qu'intervient la rotation des fichiers, qui permet de garder une fenêtre glissante sur le réseau sans saturer le stockage.

2. Activer la rotation des fichiers

Une capture Shadow IT sérieuse dure 24h à 7 jours. Sans rotation, votre fichier .pcapng grossit de façon linéaire avec le trafic réseau. Sur un réseau chargé à 100 Mbps, cela représente plusieurs centaines de gigaoctets par heure. Sans rotation : disque plein, Wireshark plante, perte de données.

Chemin GUI

Capture → Options → Output → Use multiple files

Les deux modes de rotation

Rotation par taille — adapté aux réseaux à trafic variable :

Next file every 500 MB      ← réseau peu chargé
Next file every 1 024 MB    ← réseau chargé

Chaque fichier a une durée différente selon la charge réseau. Utile quand l'espace disque est la contrainte principale.

Rotation temporelle — adapté à l'analyse forensique et à la corrélation de logs :

Next file every 3 600 s (= 1h)    ← corrélation avec logs système/firewall
Next file every  900 s (= 15min)  ← réseau très chargé, analyse rapide

Chaque fichier couvre une plage horaire précise. Idéal pour croiser avec les logs d'un firewall ou d'un SIEM : "que se passait-il entre 14h00 et 15h00 ?"

Configuration terrain recommandée — Shadow IT 24/7

✔ Use multiple files  : activé
✔ Next file every     : 1 000 MB  (ou 3 600 s)
✔ Ring buffer         : 24 fichiers
→ Fenêtre glissante de 24h sans exploser le disque
→ Au 25e fichier, Wireshark écrase le 1er

Le ring buffer est la clé : il transforme la capture en mémoire circulaire. Vous avez toujours les 24 dernières heures disponibles, automatiquement. Si un incident est signalé à 9h du matin, vos fichiers de la nuit sont encore là.

Calcul de l'espace disque nécessaire

Débit réseau moyen × durée fenêtre × facteur de compression pcapng

Exemple : 50 Mbps moyen × 24h × 0,4 (compression ~60%)
= 50 × 3600 × 24 / 8 × 0,4
≈ 216 Go

Pour un réseau à 50 Mbps, prévoyez 250 Go d'espace disque libre.

Ligne de commande — dumpcap

dumpcap est le moteur de capture de Wireshark, sans l'interface graphique. Il est significativement plus efficace pour les captures longue durée car il n'analyse pas les paquets en temps réel — il se contente de les écrire sur disque à pleine vitesse.

Rotation horaire — 24h glissantes :

dumpcap -i eth0 \
  -b duration:3600 \
  -b files:24 \
  -w /captures/shadow_it.pcapng

Rotation par taille — 20 Go max :

dumpcap -i eth0 \
  -b filesize:1048576 \
  -b files:20 \
  -w /captures/shadow_it.pcapng

Capture ciblée sur le trafic inconnu uniquement (réduction volume) :

# Capturer tout sauf le trafic IT connu — filtrer par BPF
# Adapter 192.168.10.0/24 à votre plage IT déclarée
dumpcap -i eth0 \
  -f "not (src net 192.168.10.0/24 and dst net 192.168.10.0/24)" \
  -b duration:3600 \
  -b files:48 \
  -w /captures/shadow_suspect.pcapng

Capture multi-interface — IT et OT sur des switchs séparés :

# Interface 1 = réseau IT, Interface 2 = réseau OT
# Fusionner dans un seul fichier via mergecap après coup
dumpcap -i eth0 -w /captures/it.pcapng -b duration:3600 -b files:24 &
dumpcap -i eth1 -w /captures/ot.pcapng -b duration:3600 -b files:24 &

# Fusion après capture :
mergecap -w /captures/merged.pcapng /captures/it_*.pcapng /captures/ot_*.pcapng

---

Buffer et rotation forment le socle obligatoire. Trois paramètres complémentaires affinent ensuite la qualité de la capture — taille du snaplen, désactivation de la résolution DNS, choix du timestamp précis. Aucun n'est strictement nécessaire pour démarrer, mais leur configuration fait la différence entre une capture immédiatement exploitable et plusieurs gigaoctets de pcapng qui ralentissent l'analyse.

3. Paramètres complémentaires

3.1 Désactiver la résolution DNS pendant la capture

View → Name Resolution → décocher :
  ☐ Resolve Network Names        (résolution IP → hostname)
  ☐ Resolve Transport Names      (résolution port → service)

Pourquoi c'est critique : quand la résolution est active, Wireshark génère une requête DNS pour chaque nouvelle IP qu'il observe. Sur un réseau OT avec des centaines d'équipements aux IPs statiques non déclarées dans le DNS, Wireshark génère une tempête de requêtes DNS. Conséquences :

• Ces requêtes apparaissent dans votre capture — elles polluent l'analyse et faussent les statistiques
• Elles révèlent votre activité de capture aux équipements qui surveillent le DNS
• Elles peuvent déclencher des alertes IDS (un poste qui interroge des centaines d'IPs OT en quelques secondes, c'est suspect)
• Sur les réseaux OT, les IP statiques n'ont souvent pas de reverse DNS — chaque requête aboutit à un timeout de 2–5 secondes, ralentissant massivement l'interface Wireshark

Réactivez la résolution après la capture, lors de l'analyse hors ligne. Le fichier pcapng contient toutes les IPs — vous pouvez enrichir l'analyse a posteriori.

3.2 Snaplen — conserver les paquets complets

Capture → Options → Snapshot length (bytes) → 0  (ou 262144)

Le snaplen (snapshot length) définit combien d'octets de chaque paquet sont conservés. La valeur 0 signifie "paquet complet".

Pourquoi le snaplen complet est indispensable pour le Shadow IT :

• Protocoles OT (Modbus, EtherNet/IP) : les valeurs des registres, les ordres de commande, les états des capteurs sont dans le payload — avec un snaplen de 64 octets, vous ne voyez que les headers IP/TCP
• Transferts de fichiers suspects (SMB, FTP, HTTP) : reconstituer le fichier transféré avec File → Export Objects nécessite le payload complet
• TLS fingerprinting (JA3, JA4) : l'empreinte du client TLS est dans le Client Hello — généralement plus long que 64 octets
• Exfiltration DNS : les données exfiltrées sont encodées dans les sous-domaines — il faut voir la requête complète

Exception légitime au snaplen complet : sur un lien 10 Gbps avec très peu d'espace disque, un snaplen de 256 octets capture tous les headers et les premiers octets de payload. Suffisant pour l'inventaire, insuffisant pour l'analyse forensique.

3.3 Mode promiscuité

Capture → Options → Promiscuous mode → ✔ activé

En mode normal, une carte réseau filtre les trames au niveau hardware — elle n'accepte que celles dont l'adresse MAC de destination correspond à la sienne (ou aux multicasts/broadcasts). En mode promiscuité, elle accepte toutes les trames du segment.

Sur un mirror port : sans promiscuité, vous ne voyez que les trames adressées à votre poste. Les milliers de trames entre les autres équipements sont invisibles. La promiscuité est donc obligatoire.

Sur Linux : si la promiscuité ne s'active pas automatiquement (firewall, restrictions NIC), forcez-la :

ip link set eth0 promisc on
# Vérifier
ip link show eth0 | grep promisc

Sur Windows : certains pilotes de carte réseau désactivent la promiscuité par défaut. Si Wireshark affiche seulement le trafic local sur un mirror port, vérifiez les paramètres avancés du pilote dans le Gestionnaire de périphériques.

3.4 Précision des timestamps

Pour les analyses forensiques et la corrélation avec d'autres logs :

Edit → Preferences → Protocols → Frame → 
  Time stamp precision : Microseconds (recommandé)
  Time display format  : Date and time of day

En OT, les événements peuvent se succéder en quelques millisecondes (cycles automates de 10 ms, communication PROFINET à 1 ms). Une précision microseconde est indispensable pour reconstituer la séquence d'événements.

---

La capture est maintenant techniquement irréprochable : buffer dimensionné, rotation active, paramètres optimisés. Reste l'étape qui transforme un fichier pcapng brut en inventaire actionnable : l'application des bons filtres. Wireshark embarque un moteur de filtrage parmi les plus puissants du marché — encore faut-il connaître les patterns spécifiques que produit un équipement non déclaré. Les trois sections qui suivent détaillent les filtres pour le Shadow IT bureautique (section 4), pour le Shadow OT industriel (section 5) et pour les comportements suspects qui transcendent les deux mondes (section 6).

4. Filtres Wireshark pour détecter le Shadow IT

La capture est configurée. Place à la chasse. Les filtres suivants couvrent l'intégralité des vecteurs de découverte du Shadow IT.

4.1 Inventaire passif complet — point de départ

Avant tout filtre, la première action est de laisser tourner la capture 30 minutes et de consulter les endpoints :

Statistics → Endpoints → IPv4

Triez par "Bytes" décroissant. Les gros émetteurs sont soit des serveurs déclarés, soit des équipements Shadow IT actifs. Exportez en CSV et comparez avec votre CMDB ou votre liste DHCP.

Statistics → Endpoints → Ethernet

La vue Ethernet vous donne les adresses MAC. Les trois premiers octets (OUI — Organizationally Unique Identifier) identifient le fabricant. Une adresse commençant par B8:27:EB est un Raspberry Pi. 00:50:56 est une VM VMware. DC:A6:32 est un Raspberry Pi 4. Ces informations sont visibles avant même d'avoir une IP.

Statistics → Protocol Hierarchy

Vue d'ensemble des protocoles détectés. Si vous voyez Modbus sur un réseau supposément 100% IT, il y a un équipement OT non déclaré. Si vous voyez WireGuard ou OpenVPN, quelqu'un a monté un tunnel.

4.2 Nouveaux équipements via DHCP

Le DHCP est le premier protocole qu'un nouvel équipement utilise. Il révèle le hostname, le type d'appareil, et parfois le vendor.

# Toutes les requêtes DHCP Discover (nouvel équipement cherche une IP)
bootp.type == 1

# Voir le hostname que l'équipement déclare (option DHCP 12)
bootp.option.hostname

# Vendor Class Identifier (option 60) — type d'appareil
# Exemples : "MSFT 5.0" = Windows, "dhcpcd-5.x" = Linux, "android-dhcp-11" = Android
bootp.option.vendor_class_id

# Paramètres demandés (option 55) — fingerprint OS
bootp.option.param_request_list

# Filtrer les équipements qui demandent une IP hors du plan d'adressage connu
bootp.type == 1 and not bootp.option.requested_ip_address[0:3] == 0a:00:01

Le DHCP fingerprinting est puissant : la combinaison du Vendor Class Identifier et des paramètres demandés permet d'identifier le système d'exploitation avec une précision de 90%+ sans jamais contacter l'équipement.

4.3 Annonces automatiques — équipements qui se révèlent seuls

Ces protocoles fonctionnent sans aucune configuration — tout équipement moderne les utilise automatiquement dès sa connexion.

# mDNS (Multicast DNS) — Apple Bonjour, Chromecast, imprimantes WiFi, IoT
# Révèle le nom de l'équipement, ses services, son OS
udp.port == 5353

# Filtrer les annonces mDNS d'un type spécifique
dns.qry.type == 12 and udp.port == 5353    # PTR records (découverte de services)
dns.qry.type == 1  and udp.port == 5353    # A records (IPs)
dns.qry.type == 33 and udp.port == 5353    # SRV records (services avec port)

Les annonces mDNS révèlent : - _airplay._tcp.local → Apple TV, HomePod - _googlecast._tcp.local → Chromecast, Google Home - _smb._tcp.local → NAS, partage réseau non déclaré - _ipp._tcp.local → Imprimante IP - _workstation._tcp.local → Poste de travail Linux

# SSDP / UPnP — smart TV, NAS grand public, box internet, objets connectés
udp.port == 1900

# Voir les réponses SSDP (équipements qui s'annoncent)
udp.port == 1900 and data contains "NOTIFY"

# LLDP — switchs, routeurs, téléphones IP (révèle modèle exact, firmware, VLAN)
lldp

# CDP — équipements Cisco non documentés (révèle hostname, modèle, plateforme)
cdp

# EDP — équipements Extreme Networks
edp

# NetBIOS Name Service — Windows, NAS Synology/QNAP, Samba
nbns

# Browser Protocol — serveurs de fichiers Windows (annonces de partage)
browser

💡 Règle terrain : tout équipement IoT grand public (caméra IP, assistant vocal, tablette Android, clé Amazon Fire) s'annonce sur mDNS et/ou SSDP dans les 30 secondes suivant sa connexion. Vous n'avez rien à faire — il vient à vous.

4.4 Shadow IT Cloud — trafic vers l'extérieur

Un équipement non déclaré qui communique avec Internet est une priorité absolue en OT.

# Toutes les nouvelles connexions TLS vers l'extérieur depuis le réseau OT
ssl.handshake.type == 1 and not ip.dst[0:3] == 0a:00:00

# SNI dans le Client Hello TLS — voir le domaine de destination
ssl.handshake.extensions_server_name

# DNS vers des serveurs non autorisés (contournement de filtrage DNS interne)
# Remplacer 10.0.0.1 par votre DNS interne
dns and not (ip.dst == 10.0.0.1 or ip.dst == 10.0.0.2)

# DoH — DNS over HTTPS (contournement total du filtrage DNS)
# Destinations connues : 8.8.8.8, 1.1.1.1, 9.9.9.9, 208.67.222.222
dns over tls ou filtrer :
tcp.port == 853 or (tcp.port == 443 and ip.dst == 8.8.8.8)

# HTTP en clair vers l'extérieur — très suspect depuis un réseau OT en 2024
http.request and not ip.dst[0:3] == 0a:00:00

# Connexions sur des ports non standards vers l'extérieur
not (tcp.port == 443 or tcp.port == 80 or tcp.port == 25 or tcp.port == 53) \
  and ip.dst != 10.0.0.0/8 and ip.dst != 192.168.0.0/16 and ip.dst != 172.16.0.0/12 \
  and tcp.flags.syn == 1 and tcp.flags.ack == 0

# Tunnels suspects — trafic non-standard à haut volume
# ICMP exfiltration (encodage de données dans les pings)
icmp and data.len > 8

# DNS exfiltration — longs sous-domaines inhabituels (> 50 chars)
dns.qry.name.len > 50

4.5 Partages réseau non déclarés — Shadow NAS

# SMB2 — partages réseau Windows, NAS
smb2

# Voir les shares accédés
smb2.filename

# NFS — partages Linux/Unix non déclarés
portmap or nfs or udp.port == 2049

# FTP — transferts de fichiers non chiffrés (souvent des équipements legacy)
ftp or tcp.port == 21

4.6 Accès distants non autorisés

# VNC — prise de main à distance non chiffrée
tcp.port == 5900 or vnc

# RDP vers des équipements non serveurs
tcp.port == 3389 and not ip.dst == 10.0.1.0/24   # adapter à vos serveurs

# TeamViewer (port spécifique)
tcp.port == 5938

# AnyDesk
tcp.port == 7070

# SSH depuis des équipements OT (inhabituel)
tcp.port == 22 and ip.src == 10.0.2.0/24   # adapter au sous-réseau OT

---

Les filtres précédents ciblent le Shadow IT bureautique : imprimantes, NAS personnels, smartphones, points d'accès Wi-Fi sauvages. Le Shadow OT obéit à une logique différente — les équipements industriels parlent leurs propres protocoles (Modbus, EtherNet/IP, PROFINET, OPC UA) et leur découverte requiert des filtres spécifiques. Bonus important : ces filtres révèlent non seulement le Shadow OT mais aussi les ponts non documentés entre les zones IT et OT, qui constituent souvent le vecteur d'attaque privilégié contre les SI industriels.

5. Filtres Wireshark pour détecter le Shadow OT

La détection du Shadow OT nécessite de connaître les protocoles industriels. Voici la liste exhaustive des protocoles que vous pourriez voir sur un réseau IT/OT convergé.

5.1 Modbus TCP — le protocole industriel le plus répandu

Utilisé par des millions d'automates (Schneider, Siemens, Omron, ABB). Communication client-serveur sur TCP/502.

# Tout le trafic Modbus
modbus

# Filtres avancés
modbus.func_code == 1    # Read Coils
modbus.func_code == 3    # Read Holding Registers
modbus.func_code == 6    # Write Single Register
modbus.func_code == 16   # Write Multiple Registers (écriture sur automate)
modbus.func_code == 43   # Read Device Identification (découverte)

# Requêtes Read Device ID — cartographie des équipements Modbus
modbus.func_code == 43 and modbus.mei_type == 14

Un équipement qui répond à Read Device Identification révèle son fabricant, son modèle et sa version firmware sans que vous ayez à lui parler — c'est lui qui répond à une requête légitime sur le réseau.

5.2 EtherNet/IP et CIP — Rockwell, Allen-Bradley, Omron

# EtherNet/IP implicite (I/O data) — UDP/2222
udp.port == 2222

# EtherNet/IP explicite (messages CIP) — TCP/44818
tcp.port == 44818

# CIP — Common Industrial Protocol (couche applicative)
cip

# Commandes CIP intéressantes
cip.service == 0x01    # Get Attributes All (inventaire complet de l'équipement)
cip.service == 0x4b    # Execute PCCC (commandes ladder Rockwell)

5.3 PROFINET — Siemens, B&R, Phoenix Contact

# PROFINET RT — couche 2 directe (pas d'IP !)
# Filtre par EtherType
eth.type == 0x8892

# PROFINET DCP — découverte et configuration
pn_dcp

# Requêtes Identify All — cartographie automatique des équipements Siemens
pn_dcp.service_id == 5 and pn_dcp.service_type == 0

# PROFINET IRT — synchronisation temps réel
pn_rt

⚠️ PROFINET RT fonctionne en couche 2 uniquement (pas d'IP). Si vous ne capturez qu'au niveau IP, vous le manquez entièrement. Assurez-vous de capturer au niveau Ethernet.

5.4 DNP3 — SCADA, secteur énergie, eau, gaz

# DNP3 sur TCP/20000
dnp3 or tcp.port == 20000

# Voir les points de données DNP3
dnp3.al.obj == 1     # Binary Input
dnp3.al.obj == 30    # Analog Input
dnp3.al.obj == 12    # Binary Output (commande !)

Un équipement DNP3 non déclaré dans le secteur énergie est une urgence sécurité absolue.

5.5 BACnet — building automation, HVAC, contrôle accès

# BACnet/IP — UDP/47808
bacnet or udp.port == 47808

# BACnet Who-Is — broadcast de découverte (équipement qui cherche ses pairs)
bacnet.service == 8

# BACnet I-Am — réponse d'identification (équipement qui se déclare)
bacnet.service == 0

BACnet est très courant dans les bâtiments intelligents. Un équipement BACnet sur un réseau IT révèle soit une convergence IT/OT non documentée, soit un Shadow OT de type GTB/HVAC.

5.6 OPC-UA — supervision industrielle moderne

# OPC-UA sur TCP/4840
opcua or tcp.port == 4840

# OPC-UA Discovery
tcp.port == 4840 and opcua.transport.type == "MSG"

5.7 Autres protocoles industriels

# HART-IP — capteurs de terrain intelligents
udp.port == 5094

# IEC 60870-5-104 — SCADA Europe, secteur énergie
iec104 or tcp.port == 2404

# IEC 61850 — sous-stations électriques
mms or tcp.port == 102

# FINS — Omron
tcp.port == 9600 or udp.port == 9600

# Ethernet/IP over UDP multicast — broadcast industriel
udp.dst == 239.192.1.0/24

# FL-net — Fanuc, Yokogawa (Japan)
udp.port == 55000

5.8 Protocoles de configuration réseau industrielle

# EtherNet/IP ListIdentity — cartographie automatique du réseau
udp.dst == 255.255.255.255 and udp.port == 44818

# PROFINET DCP Identify All — broadcast Siemens
eth.dst == 01:0e:cf:00:00:00

# LLDP spécifique OT — PROFINET LLDP
lldp and lldp.chassis.subtype == 4

---

Au-delà du Shadow IT et du Shadow OT légitimes mais non déclarés, certains équipements sur le réseau présentent des comportements qui dépassent la simple absence d'inventaire : exfiltration via DNS tunneling, balayage de ports interne, communications avec des C2 connus, beaconing régulier. Cette section dresse la liste des filtres qui repèrent ces signaux et qui transforment l'exercice d'inventaire en première étape d'un audit de sécurité actif.

6. Filtres pour les comportements suspects et les menaces internes

6.1 Reconnaissance réseau

# ARP scan — quelqu'un découvre le réseau
# Signe : un poste envoie des ARP Request vers des dizaines d'IPs différentes en peu de temps
arp.opcode == 1

# Flood SYN — scan de ports ou attaque DoS
tcp.flags.syn == 1 and tcp.flags.ack == 0

# ICMP sweep — ping scan de plage d'adresses
icmp.type == 8

# UDP scan — tentative de découverte de services UDP
udp and ip.dst != ip.src and udp.length == 8

# Filtrer la source d'un scan probable (adapter l'IP)
arp.opcode == 1 and arp.src.proto_ipv4 == 10.0.0.99

6.2 Mouvement latéral — équipement qui attaque depuis l'intérieur

# Tentatives d'accès SMB vers de nombreuses cibles (pass-the-hash, worm)
smb2 and smb2.cmd == 1 and ip.src == 10.0.0.99

# Connexions RDP multiples depuis un même poste
tcp.port == 3389 and ip.src == 10.0.0.99

# NTLM relay / responder — réponse à des requêtes LLMNR/NBT-NS malveillantes
llmnr or udp.port == 5355 or udp.port == 137

6.3 Exfiltration de données

# Transferts importants vers l'extérieur (filtrer selon votre réseau)
ip.len > 1400 and not ip.dst[0:3] == 0a:00:00 and not ip.dst[0:3] == c0:a8:00

# Upload FTP vers l'extérieur
ftp.request.command == "STOR"

# Email avec pièce jointe volumineuse (SMTP)
smtp and data.len > 100000

# Exfiltration ICMP — données cachées dans des pings
icmp.type == 8 and data.len > 100

6.4 Tempêtes et boucles réseau

# Broadcast storm — signe de boucle STP ou équipement défaillant
eth.dst == ff:ff:ff:ff:ff:ff

# Multicast flood anormal
eth.dst[0] & 1 == 1 and not (eth.dst == ff:ff:ff:ff:ff:ff)

# Voir l'IP source d'une tempête de broadcast
eth.dst == ff:ff:ff:ff:ff:ff and ip

---

Détecter ne suffit pas : le travail consiste ensuite à qualifier chaque adresse découverte — équipement légitime non inventorié, prestataire en mission, employé qui a branché son matériel personnel, ou intrusion réelle. La méthodologie d'analyse post-capture décrite ci-dessous est celle utilisée sur le terrain, en environnement client, pour produire un livrable d'audit défendable et actionnable.

7. Analyse post-capture : qualifier et documenter le Shadow IT

La capture est terminée. Voici une méthodologie structurée pour en extraire la valeur.

7.1 Construire l'inventaire complet des équipements

Étape 1 — Export des endpoints

Statistics → Endpoints → IPv4 → Copy → CSV
Statistics → Endpoints → Ethernet → Copy → CSV

Étape 2 — Enrichissement OUI (fabricant par MAC)

Les 3 premiers octets de l'adresse MAC identifient le fabricant avec une précision de 100%. Base de données publique, mise à jour régulièrement par l'IEEE :

# Télécharger la base OUI officielle
curl -O https://standards-oui.ieee.org/oui/oui.csv

# Chercher un fabricant pour une MAC donnée
grep -i "b8:27:eb" oui.csv
# → Raspberry Pi Foundation

# Script bash pour enrichir un CSV d'endpoints
while IFS=, read mac rest; do
    vendor=$(grep -i "${mac:0:8}" oui.csv | cut -d, -f3 | head -1)
    echo "$mac,$vendor,$rest"
done < endpoints_ethernet.csv > endpoints_enriched.csv

Étape 3 — TTL fingerprinting OS

Le TTL initial d'un paquet IP révèle l'OS sans aucun scan actif :

# Filtrer une IP suspecte et observer le champ TTL
ip.src == 10.0.0.XX

TTL observé	OS probable
64	Linux, Android, iOS, macOS, FreeBSD
128	Windows (toutes versions)
255	Cisco IOS, équipements réseau, certains RTOS
60	Siemens S7, certains PLCs
32	Très ancien Windows (98/NT)
30	Équipement réseau très ancien

Étape 4 — Corrélation DHCP/DNS pour retrouver le hostname

# Chercher le hostname DHCP d'une IP suspecte
bootp.option.hostname and bootp.ip.your == 10.0.0.XX

# Chercher dans les réponses DNS
dns.a == 10.0.0.XX

7.2 Analyser un protocole OT inconnu — Follow Stream

Pour un équipement Modbus suspect identifié à l'étape précédente :

1. Filtrer modbus and ip.src == 10.0.0.XX
2. Clic droit sur un paquet → Follow → TCP Stream
3. Dans la fenêtre Stream, chaque ligne correspond à un échange. Le format Modbus est lisible avec le dissecteur : vous voyez les numéros de registres lus/écrits, les valeurs, les adresses d'esclaves
4. Comparez avec votre documentation process : est-ce que ces registres correspondent à quelque chose dans votre installation ?

Un registre inconnu lu ou écrit en dehors des plages documentées = équipement non déclaré qui sonde votre installation.

7.3 Reconstituer un transfert de fichier suspect

File → Export Objects → SMB → sauvegarder le fichier
File → Export Objects → HTTP → sauvegarder les fichiers HTTP

Si un équipement Shadow IT a transféré des données via SMB, Wireshark peut reconstituer le fichier byte pour byte — à condition que le snaplen soit complet (voir section 3.2).

7.4 Automatiser l'analyse avec tshark

Pour les équipes sécurité qui veulent industrialiser la détection :

# Inventaire complet des IPs et MACs — format CSV
tshark -r capture.pcapng -T fields \
  -e ip.src -e eth.src -e ip.dst -e eth.dst \
  -E separator=, -E header=y \
  | sort -u > inventaire_complet.csv

# Extraire tous les hostnames DHCP
tshark -r capture.pcapng -Y "bootp.option.hostname" \
  -T fields -e ip.src -e bootp.option.hostname \
  | sort -u > hostnames_dhcp.txt

# Lister tous les protocoles OT détectés
tshark -r capture.pcapng -T fields -e frame.protocols \
  | tr ':' '\n' | sort | uniq -c | sort -rn \
  | grep -E "modbus|enip|pn_|bacnet|dnp3|opcua|cip" > protocoles_ot.txt

# Détecter les annonces mDNS et extraire les noms de services
tshark -r capture.pcapng -Y "udp.port == 5353 and dns.flags.response == 1" \
  -T fields -e ip.src -e dns.resp.name \
  | sort -u > services_mdns.txt

# Détecter les connexions vers l'extérieur depuis le réseau OT
tshark -r capture.pcapng \
  -Y "ip.src[0:3] == 0a:00:02 and not ip.dst[0:3] == 0a:00:00 and tcp.flags.syn == 1" \
  -T fields -e ip.src -e ip.dst -e tcp.dstport \
  | sort -u > connexions_externes_ot.txt

# Score de suspicion par IP (nombre de protocoles différents)
tshark -r capture.pcapng -T fields -e ip.src -e frame.protocols \
  | awk '{split($2,a,":"); for(i in a) print $1, a[i]}' \
  | sort | uniq | awk '{count[$1]++} END {for(ip in count) print count[ip], ip}' \
  | sort -rn > score_suspicion.txt

7.5 Workflow de qualification par équipement suspect

Pour chaque IP non reconnue dans l'inventaire, appliquez cette séquence :

1. MAC → Fabricant (OUI lookup) — donne le type d'équipement probable
2. TTL → OS — affine l'identification
3. DHCP hostname — souvent le nom configuré par l'utilisateur
4. mDNS/SSDP — services annoncés par l'équipement lui-même
5. Protocol Hierarchy filtré sur l'IP — quels protocoles utilise-t-il ?
6. Conversations filtré sur l'IP — avec qui parle-t-il ? Vers l'extérieur ?
7. Follow Stream sur le protocole principal — que dit-il exactement ?

À l'issue de ce workflow, vous avez pour chaque équipement : fabricant probable, OS probable, nom probable, services utilisés, destinations contactées. Suffisant pour une décision d'isolation ou de régularisation.

---

Une campagne ponctuelle de capture-analyse-qualification donne une photographie instantanée du réseau. C'est suffisant pour un audit éclair ou un état des lieux initial. Pour une posture défensive durable, il faut passer en mode surveillance continue : capture permanente, analyse périodique automatisée, alertes sur nouveaux équipements. Les outils présentés dans cette section permettent de bâtir cette chaîne sans budget significatif.

8. Automatisation et surveillance continue

Une capture ponctuelle révèle l'état au moment de la capture. Pour une surveillance continue du Shadow IT, il faut automatiser.

8.1 Alertes tshark en temps réel

#!/bin/bash
# Alerte en temps réel sur les nouveaux équipements DHCP
tshark -i eth0 -Y "bootp.type == 1" \
  -T fields -e frame.time -e ip.src -e bootp.option.hostname -e bootp.option.vendor_class_id \
  -l | while IFS=$'\t' read time src hostname vendor; do
    echo "[$(date)] Nouvel équipement DHCP: IP=$src Hostname=$hostname Vendor=$vendor"
    # Envoyer une alerte Slack/mail ici
done

#!/bin/bash
# Alerte sur détection de protocoles OT sur le réseau IT
tshark -i eth0 \
  -Y "modbus or (tcp.port == 44818) or pn_rt or dnp3 or bacnet" \
  -T fields -e frame.time -e ip.src -e ip.dst -e frame.protocols \
  -l | while read line; do
    echo "[ALERTE OT] $line" | tee -a /var/log/shadow_ot_alerts.log
done

8.2 Intégration avec un SIEM

Les fichiers pcapng peuvent être analysés en batch et les résultats envoyés vers un SIEM (Elasticsearch, Splunk, Wazuh) :

# Extraire les événements en format JSON pour Elasticsearch
tshark -r capture.pcapng -T json \
  -Y "bootp.type == 1 or udp.port == 5353 or lldp or pn_dcp" \
  | jq '.[] | {
      timestamp: ."_source".layers.frame."frame.time",
      src_ip: ."_source".layers.ip."ip.src",
      src_mac: ."_source".layers.eth."eth.src",
      protocol: ."_source".layers.frame."frame.protocols",
      hostname: ."_source".layers.bootp."bootp.option.hostname"
    }' > events_siem.json

8.3 Passer à Zeek pour la surveillance continue

Wireshark est l'outil idéal pour l'investigation et l'apprentissage. Pour la surveillance continue en production, Zeek (anciennement Bro) est plus adapté : il génère des logs structurés (JSON) en temps réel, consomme moins de ressources, et ne conserve pas les paquets bruts.

# Zeek — démarrer une analyse sur un fichier pcapng existant
zeek -r capture.pcapng

# Résultat : fichiers de logs structurés
# conn.log      — toutes les connexions TCP/UDP
# dhcp.log      — requêtes DHCP avec hostname et vendor
# dns.log       — requêtes DNS
# notice.log    — alertes automatiques (scans, brute force, etc.)
# protocols/    — logs spécifiques par protocole (modbus.log si plugin OT)

---

Toutes les briques précédentes se rassemblent dans une configuration finale unique, testée sur des environnements clients et reproductible. Cette section condense les paramètres optimaux pour un audit Shadow IT/OT typique sur réseau plat sans VLAN — durée de capture, taille de buffer, filtres prioritaires, livrable attendu. À utiliser comme checklist pour démarrer un audit en quelques minutes.

9. Configuration finale recommandée — IT + OT sans VLAN

Paramètre	Valeur	Bénéfice
Buffer	2 048 MB	✦ stabilité — absorbe les bursts OT et IT simultanés
Snaplen	0 (complet)	✦ visibilité maximale — forensique et reconstitu­tion possible
Multiple files	activé	✦ capture longue durée sans perte
Rotation	1h	✦ corrélation temporelle avec logs firewall/SIEM
Ring buffer	24 fichiers	✦ fenêtre glissante 24h, disque maîtrisé
Promiscuous mode	activé	✦ trafic tiers visible sur mirror/SPAN port
Name resolution	désactivée	✦ capture propre, analyse offline enrichie
Timestamp precision	Microseconds	✦ corrélation événements OT à la ms
Point d'écoute	TAP ou mirror port core	✦ visibilité complète IT+OT

Commande dumpcap terrain — tout-en-un

dumpcap -i eth0 \
  -p \
  -s 0 \
  -B 2048 \
  -b duration:3600 \
  -b files:24 \
  -w /captures/ot_it_$(date +%Y%m%d).pcapng

Option	Valeur	Signification
-i eth0	interface	Adapter au nom de votre interface (ip link show)
-p	—	Mode promiscuité activé
-s 0	octets	Snaplen complet
-B 2048	MB	Buffer kernel 2 Go
-b duration:3600	secondes	Nouveau fichier toutes les heures
-b files:24	fichiers	Ring buffer 24h glissantes

Checklist terrain avant de démarrer la capture

□ Point d'écoute vérifié (mirror port actif, TAP branché en coupure)
□ Mode promiscuité confirmé (ip link show | grep promisc)
□ Espace disque disponible calculé (voir formule section 2)
□ Buffer ajusté selon le débit estimé
□ Rotation activée avec ring buffer
□ Résolution DNS désactivée
□ Snaplen à 0
□ Timestamp en microsecondes
□ Capture démarrée avec nohup ou screen (résiste à la déconnexion SSH)
□ Drops vérifiés après 10 minutes (Statistics → Capture File Properties)

Démarrer la capture en résistant à la déconnexion SSH :

nohup dumpcap -i eth0 -p -s 0 -B 2048 \
  -b duration:3600 -b files:24 \
  -w /captures/shadow_it.pcapng \
  > /captures/dumpcap.log 2>&1 &

echo "PID: $!"

---

Avant de récapituler, un dernier point méritant attention : la capture passive ne remplace pas un programme de gestion d'actifs structuré. Elle révèle l'écart entre ce qui devrait être inventorié et ce qui l'est réellement, sans pour autant constituer un substitut à la gouvernance. C'est précisément cette complémentarité qui fait sa valeur — elle alimente le programme, sans le remplacer.

Conclusion : la capture passive, première ligne de défense Shadow IT/OT

La détection du Shadow IT et Shadow OT par capture passive Wireshark présente trois avantages irremplaçables sur le terrain :

Zéro impact sur la production. Pas un seul paquet n'est injecté sur le réseau. Les automates les plus fragiles ne voient rien. Les équipements OT qui se resettent sur un scan Nmap fonctionnent normalement pendant toute la durée de la capture.

Aucun angle mort protocolaire. Tout équipement qui émet une trame est visible — Modbus, BACnet, PROFINET, IoT grand public, NAS personnel, clé 4G. La capture passive est agnostique au protocole. Si ça parle, vous l'entendez.

Evidence juridique et forensique. Les fichiers pcapng horodatés constituent une preuve numérique de première qualité. Ils permettent de reconstituer exactement ce qui s'est passé, quand, entre quels équipements, et avec quel contenu.

La configuration décrite dans ce guide — buffer 2 Go, rotation horaire, ring buffer 24h, snaplen complet, mode promiscuité — est la configuration minimale pour une détection Shadow IT/OT fiable. Elle est reproductible en 10 minutes sur n'importe quel système Linux ou Windows avec Wireshark installé.

Prochaines étapes après la détection :

1. Documenter chaque équipement trouvé : IP, MAC, fabricant (OUI), hostname, protocoles, destinations contactées, heure de première apparition
2. Qualifier : est-ce un équipement légitime non documenté ou un vrai Shadow IT ?
3. Décider : régularisation (mise à jour CMDB, ajout dans le monitoring) ou isolation réseau immédiate
4. Implémenter la segmentation VLAN : séparer IT et OT est la correction structurelle. Sans VLAN, le Shadow OT peut atteindre n'importe quelle ressource IT et vice versa
5. Déployer une surveillance continue : Zeek sur un serveur dédié, logs dans un SIEM, alertes sur les nouveaux équipements DHCP et les protocoles OT inattendus
6. Réviser la procédure de raccordement : tout nouvel équipement doit passer par une procédure de validation avant connexion au réseau

La capture passive n'est pas un outil d'investigation ponctuel — c'est une fenêtre permanente sur votre réseau. Avec les bons paramètres et les bons filtres, elle transforme votre infrastructure réseau en système de détection passif qui fonctionne sans agent, sans configuration sur les équipements surveillés, et sans perturber la production.

---

Guide terrain IT/OT — réseaux industriels et bureautiques. Testé sur Wireshark 4.x, dumpcap 4.x. Environnements réels : manufacturing, énergie, bâtiments intelligents.

Top 5 des outils de capture réseau

Wireshark est le couteau suisse de la capture réseau, mais il n'est pas toujours l'outil le plus adapté selon le contexte : capture serveur 24/7, indexation pétaoctet, surveillance temps réel ou analyse comportementale. Voici le classement 2026 — chaque outil noté sur 5 étoiles selon son adéquation à la détection Shadow IT/OT, en environnement audit ponctuel et SOC permanent.

Pour un audit Shadow IT/OT ponctuel : Wireshark + tcpdump suffisent et constituent le combo recommandé dans ce guide. Pour un déploiement permanent en SOC, ajouter Zeek (analyse comportementale) et Arkime (recherche post-incident). ntopng apporte la couche visualisation temps réel pour les opérateurs.

Pour aller plus loin

• Audit complet serveur Linux open source
• Wazuh 2026 : SIEM/XDR open source
• Durcissement Linux 2026 : Hardening CIS Benchmark
• NTLM Relay 2026 — attaques modernes
• AirCyber : audit cybersécurité aéronautique
• Notre service Audit Infrastructure IT/OT
• Documentation officielle Wireshark
• CISA — Industrial Control Systems Security