Deux SOC compromis : l’un réagit en 2 minutes, l’autre ne voit rien
Le 25 août 2026, la CISA a publié les résultats de deux évaluations simultanées menées par sa red team contre des organisations d’infrastructures critiques. Dans les deux environnements, elle a obtenu une compromission complète du domaine et atteint des systèmes métiers sensibles ainsi que des ressources cloud, selon l’avis officiel AA26-237A. Le SOC de l’organisation B a toutefois isolé trois postes compromis après 10, 2 et 20 minutes, tandis que l’organisation A n’a ni détecté ni contenu l’opération.
Les cibles, restées anonymes, relevaient respectivement des services gouvernementaux et des installations pour l’organisation A, et du secteur de l’eau et de l’assainissement pour l’organisation B. Il s’agissait d’exercices autorisés, non de deux intrusions criminelles. Le contraste ne tient pas à la seule présence d’outils de sécurité: la qualification des alertes, la coordination entre équipes et l’autorité permettant d’isoler immédiatement un actif ont produit deux réponses opposées.
Organisation A: des signaux noyés, puis une compromission sans entrave
La red team a d’abord trouvé une application web dont plusieurs comptes intégrés utilisaient encore leurs identifiants par défaut. Elle s’en est servie pour envoyer des messages d’hameçonnage depuis une adresse interne et exécuter ses charges sur quatre postes. Elle a ensuite combiné le quota permettant aux utilisateurs du domaine de créer des comptes machines avec un modèle Active Directory Certificate Services mal configuré, exploitable selon le scénario ESC1.
L’équipe a récupéré des identifiants en clair dans des fichiers de configuration et des clés AWS statiques réglées pour ne jamais expirer. Elle a ainsi atteint trois systèmes métiers sensibles. Dans Entra ID, le vol d’un Primary Refresh Token et les permissions excessives d’applications lui ont permis de lire les messages de l’équipe de sécurité et de vérifier si ses activités avaient été repérées; la reconstitution de The Hacker News confirme cette chaîne et l’absence de confinement.
L’organisation disposait pourtant de télémétrie. Des alertes de sévérité faible ou moyenne liées à l’exercice ont été masquées par des milliers de faux positifs, parfois mieux classés. Plusieurs SOC et outils de protection des terminaux fonctionnaient sans visibilité partagée; une alerte réelle sur un serveur SCCM a finalement été classée comme faux positif lorsque les analystes n’ont pas pu identifier son propriétaire. L’absence de procédure d’escalade et leur autorité limitée ont empêché une intervention rapide.
Organisation B: l’accès initial coupé, puis un scénario de compromission supposée
Dans l’organisation B, les charges d’hameçonnage ont été détectées pendant leur exécution. Les analystes ont isolé manuellement les trois postes concernés en 10, 2 et 20 minutes, interrompant leurs communications de commande et de contrôle. Cette réponse a supprimé le point d’appui avant que la red team puisse poursuivre normalement.
La compromission complète obtenue ensuite ne résulte donc pas d’un échec de ce confinement. Pour continuer à évaluer les contrôles internes, l’exercice est passé à un scénario assume breach: des agents de confiance de l’organisation ont exécuté une charge sur un hôte non privilégié désigné, recréant le point d’accès que le SOC venait d’éliminer.
Depuis ce nouveau point de départ, la red team a trouvé dans un fichier XML de SCCM le mot de passe en clair d’un compte de service disposant de droits sur un contrôleur de domaine. Ces droits ont permis une attaque DCSync, la récupération du secret du compte krbtgt et la création de tickets Kerberos. L’équipe a aussi atteint un bastion de la zone démilitarisée OT, mais le blocage des connexions sortantes y a empêché l’établissement d’un canal de commande et de contrôle; aucune entrée dans les systèmes OT eux-mêmes n’est documentée.
Dans les deux organisations, l’identité cloud rouvre le chemin
La réponse efficace sur les postes n’a pas supprimé les faiblesses de l’identité hybride. Dans l’organisation B, la red team a exploité Seamless SSO et des comptes synchronisés sans MFA, puis une application Entra dotée de droits étendus sur les messageries. Elle a ainsi obtenu la capacité de récupérer depuis Internet les courriels des utilisateurs du tenant.
Les deux organisations ne disposaient pas de politiques d’accès conditionnel pour les identités de charge de travail et leurs procédures de détection, de correction et de révocation des jetons compromis étaient insuffisantes. l’analyse d’Expert Insights confirme que des permissions applicatives excessives et des contrôles faibles sur les identités non humaines ont contribué à l’accès aux deux environnements Entra ID malgré l’écart de maturité des SOC.
L’organisation B possédait néanmoins des détections cloud supplémentaires. Des règles portant sur des propriétés de connexion inhabituelles et un trafic API suspect ont signalé certaines activités; les événements ont été transmis aux équipes compétentes et l’activité a été bloquée. Le résultat montre que le confinement EDR ne couvre pas, à lui seul, les sessions, applications et jetons encore valides dans le cloud.
Sept contrôles directement vérifiables après les deux exercices
La comparaison ne démontre pas qu’un produit supplémentaire aurait empêché les compromissions. Elle permet en revanche de vérifier si les contrôles existants bloquent les mêmes enchaînements et si une alerte peut réellement provoquer une action:
- Recenser les modèles AD CS qui autorisent le demandeur à fournir l’identité du certificat, restreindre leurs droits d’inscription et tester qu’un utilisateur standard ne peut pas demander un certificat pour un compte privilégié.
- Vérifier la valeur de Machine Account Quota et la ramener à zéro lorsque les utilisateurs ordinaires n’ont aucune raison de créer des comptes machines.
- Rechercher les mots de passe et secrets accessibles dans SCCM, les fichiers de configuration, les partages et les serveurs métiers; traiter les infrastructures d’administration comme des actifs critiques.
- Inventorier les clés AWS statiques, supprimer celles qui ne sont plus nécessaires et remplacer les identifiants permanents par des accès temporaires lorsque l’architecture le permet.
- Examiner les propriétaires et les permissions Microsoft Graph des applications Entra ID, ainsi que les ajouts de secrets clients, les réactivations de comptes synchronisés et l’activité inhabituelle des principaux de service.
- Appliquer des politiques adaptées aux identités de charge de travail et tester la révocation des jetons d’accès et d’actualisation après le confinement d’un poste ou d’un compte.
- Mesurer le délai entre l’alerte, l’identification du propriétaire de l’actif et l’isolement. Les analystes doivent savoir à l’avance qui peut couper un poste, un compte, un segment ou un accès cloud.
Ce que le résultat permet de conclure
Les organisations restent anonymes et aucune activité n’est attribuée à un acteur malveillant réel. L’évaluation établit qu’une détection correctement réglée, une escalade rapide et une autorité d’isolement peuvent casser l’accès initial. Elle montre également que ce succès ne suffit pas lorsque des certificats, comptes de service, applications cloud ou clés permanentes offrent un autre chemin vers le domaine et les données.
Le point encore ouvert n’est pas l’identité des deux opérateurs, que l’avis ne révèle pas, mais l’application effective des mesures correctives. Pour distinguer un contrôle documenté d’un contrôle opérationnel, les organisations devront démontrer lors de nouveaux exercices qu’un signal comparable est attribué au bon actif, transmis au bon responsable et transformé en confinement avant le passage de l’attaquant vers une autre couche.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.