La CISA (Cybersecurity and Infrastructure Security Agency) a publié un avis qui met en lumière un point souvent sous-estimé : deux défenses peuvent subir le même type d’attaque et pourtant produire des résultats radicalement différents. Dans le cadre de deux évaluations de red team menées en parallèle, l’agence a utilisé, selon ses propres termes, des tactiques de red team similaires contre deux organisations d’infrastructures critiques.
Les deux cibles ont été compromises au niveau du domaine et la simulation a également permis d’atteindre des systèmes sensibles et des ressources cloud. Pourtant, l’une n’a déclenché aucune détection utile, tandis que l’autre a rapidement stoppé la progression en isolant le poste touché. L’avis, daté du 25 août 2026, est référencé AA26-237A et s’intitule “A Tale of Two SOCs” (un récit de deux SOC).
Deux évaluations simultanées, mêmes ambitions
La CISA explique que les deux exercices ont été conduits simultanément en appliquant une approche comparable, “en utilisant ce que l’agence décrit comme un tradecraft similaire”. Concrètement, les équipes ont cherché à obtenir un point d’entrée, à escalader leurs privilèges, puis à se déplacer vers des ressources plus critiques.
La première organisation, désignée comme Organisation A, appartient au secteur Government Services and Facilities. La seconde, Organisation B, relève du secteur Water and Wastewater Systems.
Dans les deux cas, la compromission a atteint des systèmes d’intérêt, y compris des éléments cloud. Toutefois, la différence majeure observée par la CISA se situe dans la qualité des réponses défensives et dans la capacité des équipes à transformer des alertes en actions.
Organisation A : l’intrusion passe, les alertes se noient
Sur l’Organisation A, la simulation démarre par une prise de contact via l’identification d’une application web exposant des comptes configurés par défaut. Ces identifiants permettent d’envoyer des e-mails de phishing depuis une adresse interne, puis d’atterrir sur quatre postes de travail.
Après ce premier succès, l’équipe de test passe à l’escalade de privilèges en combinant deux leviers : d’une part, l’abus d’un Machine Account Quota laissé par défaut, et d’autre part, une mauvaise configuration d’un modèle lié à Active Directory Certificate Services (AD CS). Cette combinaison correspond à la classe de dérive de modèles de certificats identifiée comme ESC1. La CISA cite également un lien conceptuel avec une exploitation de type Certighost récemment divulguée, fondée sur l’abus de templates.
Une fois les privilèges augmentés, l’équipe accède à trois systèmes sensibles via des identifiants stockés en clair. Parmi les données récupérées : des fichiers de configuration de base de données déchiffrés et des clés d’accès AWS statiques configurées pour ne jamais expirer.
Le cloud : token volé et applications sur-permises
Dans l’environnement cloud, la progression ne s’arrête pas. Le scénario décrit le vol d’un Primary Refresh Token, puis l’abus d’applications Entra ID disposant de permissions élevées. Objectif : lire la messagerie de l’équipe sécurité et vérifier si les défenseurs étaient déjà au courant de l’activité.
La CISA souligne que l’Organisation A n’a détecté aucun des éléments de cette activité. Selon l’avis, ce manque de détection s’explique par plusieurs facteurs organisationnels.
- Des milliers d’alertes faux positifs issus des opérations normales, dont beaucoup sont classées à une sévérité élevée.
- Plusieurs SOC et outils d’endpoint employés sans visibilité partagée.
- Des analystes qui ne disposent pas de procédures d’escalade claires et qui ont un pouvoir d’action limité.
- Un cas où une alerte “réelle” liée à l’activité du red team sur un serveur SCCM a été rejetée comme faux positif, faute de capacité des défenseurs à identifier le propriétaire du système.
En bref, même lorsque des signaux apparaissent, l’organisation peine à filtrer le bruit et à donner suite aux événements qui comptent.
Organisation B : arrêt rapide et réduction de l’impact
À l’inverse, sur l’Organisation B, la simulation suit un schéma d’attaque de style comparable. La différence intervient dès le point d’entrée : le SOC détecte les charges utiles du phishing au moment où elles s’exécutent et isole les postes concernés en 2 à 20 minutes.
Cette action a un effet concret : la CISA indique que l’isolation a coupé la communication C2 avant que l’intrusion ne s’étende davantage. Autrement dit, le “foothold” a été rompu assez vite pour empêcher la progression attendue.
Une bascule vers un modèle “assume-breach”
Comme le red team ne pouvait pas obtenir les mêmes relais en environnement réel, CISA décrit que des agents de confiance au sein de l’organisation ont exécuté une charge utile sur un hôte non privilégié désigné. L’objectif est de répliquer l’accès que le red team aurait normalement obtenu, en basculant l’exercice vers un modèle d’“assume-breach”.
À partir de là, l’équipe retrouve des problèmes sous-jacents similaires, notamment :
- Des identifiants en clair pour un compte de service de domaine stockés dans un fichier de configuration associé à SCCM.
- Des droits permettant d’accéder à des éléments au niveau du contrôleur de domaine.
- Un usage menant à une attaque DCSync et à la récupération du secret krbtgt.
OT et bastion : blocage du canal C2
Le scénario décrit aussi une tentative d’atteindre un bastion dans une zone OT (Operational Technology) démilitarisée. Cependant, l’hôte bloque l’accès sortant vers Internet. Résultat : aucun canal C2 n’est établi, et l’équipe n’entre pas dans les systèmes OT eux-mêmes.
La CISA conclut que l’écart entre les deux histoires tient davantage aux personnes, processus et procédures qui soutiennent les outils qu’aux outils eux-mêmes.
Les faiblesses identifiées dans les deux cas
Pour l’Organisation A, la CISA met en avant plusieurs éléments qui ont facilité la compromission. Ces points servent aussi de repères utiles, car ils reviennent dans la logique générale de l’exercice sur l’autre cible.
- Machine Account Quota laissé par défaut, permettant à n’importe quel utilisateur du domaine d’ajouter des comptes machines.
- Templates AD CS mal configurés, permettant des demandes de certificats pour tout utilisateur (ESC1).
- Identifiants en clair pour des comptes de service et de base de données stockés sur des systèmes accessibles.
- Clés cloud statiques définies sans expiration et sans mécanisme de révocation de jetons.
- Des applications Entra ID trop permissives, capables de lire le courrier de tous les utilisateurs.
Pour l’Organisation B, la CISA observe notamment l’importance de la détection et de l’isolement rapide, mais elle souligne aussi que les risques “structurels” demeurent. Même quand l’attaque est freinée au départ, certaines faiblesses peuvent rester suffisamment exposées pour être exploitées dans un scénario reconstitué.
Ce que les SOC peuvent apprendre : détection utile plutôt que bruit
L’avis de la CISA insiste sur une idée simple : la performance ne se résume pas à disposer d’outils. La détection et la réponse exigent une organisation capable de traduire une alerte en décision.
La CISA cite explicitement : “Detection tools are only as effective as the people, processes, and procedures supporting them.” Autrement dit, le “taux de succès” dépend autant des réglages techniques que de la façon dont les équipes filtrent, priorisent, documentent et escaladent.
Dans le cas d’Organisation A, la CISA décrit un environnement où des faux positifs massifs et une fragmentation de la visibilité ont fait perdre du temps et de la clarté. Dans le cas d’Organisation B, la détection des charges utiles au moment de leur exécution, puis l’isolement rapide, ont limité la propagation et réduit la surface d’attaque.
Conclusion : des résultats opposés, un même message
Cette étude de la CISA montre que les tactiques de red team ne sont pas le seul levier à auditer. Deux organisations peuvent être exposées à des faiblesses comparables, mais l’impact réel dépend fortement de la manière dont les équipes utilisent leurs outils : qualité des alertes, coordination entre équipes, capacité d’escalade, et vitesse d’action.
Si vous cherchez à renforcer votre posture, l’enseignement clé est d’investir autant dans les processus et la gouvernance opérationnelle que dans la technologie. Une bonne détection doit mener à une réponse concrète — sinon, le bruit finit par masquer l’essentiel.
Source: https://thehackernews.com/2026/08/cisa-red-team-compromised-two-critical.html
