Points clés
- L'investigation post-incident SolarWinds (États-Unis, 2020) a révélé que les communications internes entre composants Orion et leurs serveurs de commande et contrôle (C2) utilisaient des protocoles et ports légitimes (HTTPS sur 443) — rendant le trafic malveillant indiscernable du trafic légitime dans des architectures sans inspection TLS.
- Le rapport Mandiant sur les APT (2023) indique que le temps de résidence moyen d'un attaquant dans un réseau d'entreprise avant détection est de 16 jours — pendant ce temps, les communications entre l'attaquant et les systèmes compromis transitent par le réseau interne sans être identifiées comme malveillantes.
- Uber (États-Unis, 2022) a subi une compromission via le réseau interne Slack : une fois à l'intérieur du réseau, l'attaquant a utilisé les canaux de communication internes pour cartographier l'infrastructure et accéder aux secrets stockés dans les espaces de travail collaboratifs — illustrant que les outils de communication interne sont une surface d'attaque critique.
Les communications internes sont souvent moins scrutées que les communications externes dans les architectures de sécurité : les règles de firewall sont plus permissives pour les flux est-ouest (entre systèmes internes) que pour les flux nord-sud (entre l'internet et le réseau interne). Cette asymétrie de surveillance crée une zone d'exposition que les attaquants exploitent systématiquement une fois établis sur le réseau.
La confiance implicite accordée aux communications internes est un héritage du modèle de sécurité périmétrique : "si c'est à l'intérieur du réseau, c'est sûr". Le Zero Trust remet en question ce présupposé fondamental — les communications internes doivent être soumises aux mêmes exigences de vérification et d'inspection que les communications externes.
Pourquoi les communications internes exposent autant que l'externe
Les communications internes présentent un profil de risque spécifique : (1) le volume de trafic interne est généralement beaucoup plus élevé que le trafic externe, rendant la détection des anomalies plus difficile sans modèle comportemental établi, (2) les protocoles internes (SMB, RDP, WMI, LDAP) sont particulièrement utiles pour les déplacements latéraux et la compromission d'annuaires, (3) les outils de collaboration interne (messageries d'entreprise, wikis, systèmes de tickets) stockent fréquemment des informations sensibles (identifiants, configurations) que les attaquants recherchent activement, (4) les politiques de chiffrement et d'authentification sont souvent moins strictes pour les flux internes.
Déplacement latéral : comment les attaquants utilisent le réseau interne
Après une compromission initiale, les attaquants utilisent le réseau interne pour étendre leur accès via des techniques de déplacement latéral : pass-the-hash (réutilisation de hachages de mots de passe Windows capturés pour s'authentifier sur d'autres systèmes), exploitation de relations de confiance entre systèmes (trusts Active Directory, comptes de service partagés), utilisation d'outils d'administration légitimes (PSExec, WMI, PowerShell remoting) pour pivoter vers des systèmes plus critiques.
La détection du déplacement latéral requiert une visibilité sur les communications internes : journalisation des connexions réseau latérales, détection des comportements anormaux dans les logs d'authentification (volumes inhabituels, tentatives multiples, connexions depuis des systèmes inattendus), et règles de segmentation limitant les communications directes entre systèmes qui n'ont pas de raison fonctionnelle de communiquer.
Inspection et surveillance des communications internes
L'inspection des communications internes s'appuie sur plusieurs techniques complémentaires : analyse des flux réseau (NetFlow/IPFIX) pour détecter des communications entre systèmes normalement isolés, inspection TLS pour les flux chiffrés sur les réseaux internes (inspection proxy ou décryptage dans des zones contrôlées), journalisation des accès aux partages réseau et aux systèmes d'administration, et solutions EDR (Endpoint Detection and Response) qui voient les connexions initiées par chaque endpoint.
Cas opérationnel : NotPetya — propagation via le réseau interne (International, 2017)
NotPetya est l'attaque la plus destructrice documentée par son usage du réseau interne comme vecteur de propagation. Après une infection initiale via la mise à jour corrompue du logiciel de comptabilité ukrainien MeDoc, NotPetya s'est propagé via les réseaux internes en exploitant EternalBlue (CVE-2017-0144, SMB) et en réutilisant les identifiants Windows extraits des mémoires des postes infectés (via Mimikatz). Chez Maersk, dont l'ensemble des 45 000 PC et 4 000 serveurs a été chiffré en moins de deux heures, la propagation s'est faite entièrement via le réseau interne depuis un seul point d'entrée. Les communications internes non surveillées et l'absence de segmentation entre les différentes entités mondiales du groupe ont permis une propagation globale en un temps record. Le coût pour Maersk seul a été estimé à 300 millions de dollars.
Après avoir obtenu l'accès au réseau Uber via MFA fatigue, l'attaquant a utilisé Slack pour poster des messages dans des canaux internes annonçant la compromission, et a accédé à des partages réseau contenant des scripts avec des identifiants en clair. Les communications internes Slack ont fourni à l'attaquant une cartographie de l'infrastructure et des secrets sans nécessiter de techniques avancées.
Saint-Gobain a perdu l'ensemble de ses systèmes informatiques pendant plusieurs jours suite à la propagation de NotPetya via son réseau interne mondial. Le manque de segmentation entre les filiales a permis à l'attaque de se propager depuis une filiale ukrainienne vers l'ensemble du groupe. Le coût a été estimé à 250 millions d'euros de pertes de revenus.
Panasonic a confirmé en novembre 2021 une compromission de ses serveurs internes japonais par un attaquant ayant accédé au réseau depuis l'internet et traversé les communications internes vers les serveurs de données. L'attaquant a eu accès à des informations sur les employés et des données opérationnelles pendant 4 mois avant détection — illustrant la durée de résidence possible quand les communications internes ne sont pas surveillées.