Deux SOC, deux issues : le red team de la CISA met à mal les défenses de deux infrastructures critiques

Le 25 août 2026, la Cybersecurity and Infrastructure Security Agency (CISA) a publié un avis comparant deux évaluations offensives menées en parallèle. Les résultats montrent un fossé profond : l'une des deux organisations n'a détecté aucune activité malveillante, tandis que l'autre a identifié et isolé les tentatives initiales, contraignant le red team à opérer en mode « assume breach ». Dans les deux cas, cependant, les attaquants simulés ont obtenu un accès complet au domaine, à des systèmes d'entreprise sensibles et à des ressources cloud. L'avis ne comprend ni CVE ni indicateurs de compromission : il s'agit d'un rapport d'évaluation, pas d'un bulletin portant sur une vulnérabilité unique.

Deux organisations, secteurs critiques, même objectif

La CISA a mené deux évaluations de type red team simultanément. La première a concerné une organisation du Government Services and Facilities Sector (Organisation A), la seconde une organisation du Water and Wastewater Systems Sector (Organisation B). Un red team simule les techniques de vrais acteurs malveillants pour évaluer les capacités de détection, d'investigation et de réponse d'une organisation. L'objectif est d'obtenir et de maintenir un accès persistant au réseau d'entreprise et aux systèmes d'entreprise sensibles sélectionnés par l'organisation elle-même. Ces systèmes, appelés SBS, sont des applications, des magasins de données ou des composants d'infrastructure dont la compromission aurait un impact matériel sur les opérations, les finances ou les données des clients.

L'assistance de la CISA est autorisée en vertu de 6 U.S.C. §§ 652(c)(5) et 659(c)(6). Le rapport utilise le framework MITRE ATT&CK for Enterprise, version 19, pour cartographier les tactiques et techniques observées. Les versions exactes des produits concernés n'ont pas été divulguées : l'analyse se concentre sur des configurations et des technologies courantes telles qu'Active Directory, les services de certificats Active Directory (ADCS), System Center Configuration Manager (SCCM), AWS IAM et les outils de détection et de réponse sur les terminaux (EDR).

Organisation A : compromission complète sans aucune alerte

Dans le cas de l'Organisation A, le red team a obtenu une compromission complète du domaine et l'accès à plusieurs SBS et ressources cloud sans que les défenseurs ne détectent ni ne contiennent l'activité. Le parcours a commencé par la reconnaissance : une application web avec des identifiants par défaut pour plusieurs comptes intégrés a été repérée, ce qui permettait d'envoyer des e-mails depuis une adresse e-mail interne. Cette adresse a été utilisée pour des campagnes de phishing ciblées, conduisant à un accès initial sur quatre postes de travail.

Depuis les postes de travail compromis, le red team a exécuté un collecteur BloodHound modifié, personnalisé pour contourner les signatures statiques de l'EDR. L'outil a interrogé Active Directory en collectant des informations sur les utilisateurs, les ordinateurs, les groupes, les listes de contrôle d'accès, les unités organisationnelles et les objets de stratégie de groupe (GPO). Un des postes de travail avait une Machine Account Quota (MAQ) par défaut égale à 10 : cette valeur permet à des utilisateurs non privilégiés d'ajouter jusqu'à 10 comptes d'ordinateur au domaine. En combinaison avec des modèles ADCS mal configurés selon la technique connue sous le nom d'ESC1, l'équipe a pu créer un compte d'ordinateur et demander des certificats pour n'importe quel compte d'utilisateur ou d'ordinateur. À partir de là, le déplacement latéral est devenu systématique.

Après avoir obtenu des privilèges élevés sur le domaine, le plan pour accéder aux SBS prévoyait d'utiliser les données d'Active Directory pour identifier les utilisateurs et les groupes liés aux systèmes sensibles, d'interroger les serveurs SCCM pour énumérer les relations utilisateur-dispositif et d'identifier les postes de travail attribués. Le déplacement latéral du serveur SCCM vers les postes de travail des utilisateurs cibles a permis de rechercher des identifiants. Pour le premier SBS, une base de données, des identifiants en clair ont été trouvés sur le poste de travail d'un utilisateur administrateur. Pour la deuxième base de données, la recherche s'est concentrée sur les fichiers connections.json et product-preferences.xml d'un outil de développement SQL : une fois déchiffrés, ils ont révélé le mot de passe en clair de la base de données. Pour le troisième SBS, un système de traitement automatisé, des identifiants utilisateur AWS Identity and Access Management (IAM) statiques à longue durée de vie ont été récupérés, enregistrés dans des fichiers de configuration dans les répertoires personnels des utilisateurs cibles. L'organisation n'avait pas configuré d'expiration ni de rotation pour ces identifiants.

Aucune alerte n'a été déclenchée. L'accès aux SBS a également été étendu aux bureaux virtuels, qui limitent l'accès aux sessions actives et interactives des utilisateurs et ajoutent des contrôles tels que la segmentation des réseaux des systèmes sensibles. Même cela n'a pas arrêté le red team.

Organisation B : détection précoce, mais le « assume breach » accorde quand même l'accès

L'Organisation B a montré une posture défensive très différente. Elle a rapidement identifié les tentatives de compromission initiales, mis en quarantaine les systèmes concernés et contraint le red team à passer à un modèle « assume breach ». Dans ce modèle, les agents de confiance de l'organisation (trusted agents, TA) ont fourni un accès à un hôte qui reproduisait le niveau d'accès que le red team aurait eu si les défenseurs n'avaient pas détecté l'activité initiale.

Depuis cet hôte, le red team a élevé ses privilèges, s'est déplacé latéralement vers les SBS, les ressources cloud et un hôte bastion dans la DMZ OT. Là, les défenseurs ont de nouveau détecté l'activité et isolé le système. L'accès au réseau OT a été démontré sans exécution réelle sur les systèmes OT. Malgré la double détection et l'isolement, le modèle assume breach a tout de même permis de démontrer l'accès aux SBS, au cloud et à la DMZ OT. La résilience de l'Organisation B a ralenti l'attaquant mais n'a pas éliminé le risque.

Les techniques derrière la compromission : ADCS, MAQ, SCCM et identifiants statiques

Le rapport mappe les activités avec plusieurs identifiants du framework MITRE ATT&CK v19, notamment T1589.001 (identification de la victime), T1566 (phishing), T1087.002 (découverte de comptes), T1018 (découverte de systèmes distants), T1069.002 (découverte de groupes de permissions), T1615 (découverte de stratégies de groupe), T1136.002 (création de comptes de domaine), T1649 (vol ou falsification de certificats), T1033 (découverte du propriétaire du système), T1552 (identifiants non protégés) et T1552.001 (identifiants dans des fichiers).

La combinaison d'une Machine Account Quota par défaut et de modèles ADCS vulnérables à ESC1 est particulièrement dangereuse. La MAQ permet à un utilisateur normal de créer des comptes d'ordinateur ; ESC1 permet de demander des certificats pour n'importe quel compte, y compris ceux qui viennent d'être créés. Le résultat est un chemin d'élévation de privilèges difficile à détecter si l'EDR n'est pas calibré. Le collecteur BloodHound modifié a contourné les signatures statiques, démontrant que la protection basée uniquement sur des signatures connues ne suffit pas contre des outils offensifs personnalisés.

Les identifiants statiques AWS IAM à longue durée de vie représentent une autre faille grave. Sans expiration ni rotation, une fois volés, ils restent valables indéfiniment. Les fichiers connections.json et product-preferences.xml de l'outil de développement SQL contiennent des mots de passe chiffrés avec des algorithmes faibles ou réversibles : quiconque les trouve peut les déchiffrer et obtenir un accès direct à la base de données.

Pourquoi les défenseurs échouent : silos, bruit et cloud sous-estimé

La comparaison entre les deux organisations met en évidence des problèmes récurrents. Des outils de détection non calibrés conduisent à des menaces non détectées. Sans base de référence définie et sans filtrage des alertes, les faux positifs et les notifications de routine surchargent les défenseurs réseau, qui finissent par ignorer les signaux réels. Dans l'Organisation A, cela a permis à l'attaquant de se déplacer sans être inquiété pendant des heures, voire des jours.

Les silos organisationnels et les obstacles bureaucratiques empêchent une réponse efficace aux incidents. Une communication fragmentée, des responsabilités mal définies et une autorité limitée des défenseurs entravent la réponse aux incidents même lorsque des alertes sont générées. Dans l'Organisation B, bien que la réponse initiale ait été rapide, la nécessité de passer au modèle assume breach indique que les processus internes auraient pu ralentir ou compliquer la réaction à une attaque réelle.

Les environnements cloud sont souvent un risque sous-estimé. Il manque des contrôles de sécurité spécifiques et des processus pour répondre à une compromission cloud. Les identifiants IAM statiques et les jetons d'accès non renouvelés représentent un vecteur d'attaque de plus en plus exploité, mais de nombreuses organisations ne disposent pas de procédures pour détecter et révoquer ces éléments en cas d'incident.

Les recommandations de la CISA pour réduire le risque

L'avis énumère quatre actions clés. Premièrement, établir et maintenir en continu une base de référence et réduire le bruit des alertes grâce à un réglage fin. Deuxièmement, abattre les silos et responsabiliser les défenseurs réseau, en attribuant une autorité et des canaux de communication clairs. Troisièmement, mettre en œuvre des politiques d'accès conditionnel pour les identités de charge de travail et surveiller les autorisations excessives ou inutilisées. Quatrièmement, établir et réviser régulièrement des procédures complètes pour détecter, corriger et révoquer les jetons d'accès et de rafraîchissement en cas de compromission cloud.

Les destinataires incluent les agences du Federal Civilian Executive Branch, les gouvernements d'État, locaux, tribaux et territoriaux, ainsi que les infrastructures critiques. Les rôles concernés vont des administrateurs système aux intervenants en incident, des analystes défensifs en cybersécurité aux analystes de vulnérabilités, des opérateurs réseau aux responsables de systèmes de sécurité. Le message est clair : les mauvaises configurations et les identifiants statiques sont la porte d'entrée préférée des attaquants, et un SOC qui ne parvient pas à filtrer le bruit ne voit même pas les attaques réussies.