Veille Cyber #2 : CISA, MFA et IA en SOC • Lenaick Sorimoutou

J’avoue que j’ai souri jaune en lisant la première actualité de la semaine. L’agence américaine chargée d’expliquer aux autres comment sécuriser leurs systèmes vient d’exposer ses propres identifiants cloud. C’est le genre de moment qui rappelle quelque chose d’essentiel : personne n’est immunisé. Même pas ceux qui font la police. Cette semaine : secrets cloud, contournement de MFA et IA en SOC.

🔍 La CISA expose ses propres secrets AWS#

Schéma montrant les trois chemins classiques par lesquels un secret AWS peut être exposé accidentellement : dépôt Git public, log applicatif, variable d'environnement mal configurée

La CISA (Cybersecurity and Infrastructure Security Agency), l’agence fédérale américaine de cybersécurité, a subi une fuite exposant des identifiants AWS GovCloud . Des parlementaires ont demandé des explications officielles. L’agence, connue pour publier des guides de durcissement et gérer le catalogue KEV, s’est retrouvée dans la position inconfortable de l’élève qui rate son propre examen.

Pourquoi c’est important ? Les secrets cloud (clés d’accès, jetons API, mots de passe de service) sont l’un des points faibles les plus courants en production. Ils finissent dans des fichiers de configuration, des logs, des dépôts publics ou des variables d’environnement mal protégées. Quand une organisation comme la CISA est touchée, le message est clair : ce problème ne concerne pas que les petites structures.

Honnêtement, ce qui me frappe ce n’est pas tant la faille que le contexte. En SOC, les alertes pour des secrets exposés dans Git font partie du quotidien. Le réflexe correctif existe : rotation de clé, révocation immédiate, audit de l’étendue de l’accès. Mais il faut l’avoir automatisé avant l’incident, pas après. La vraie question c’est : est-ce que vous sauriez détecter une clé cloud exposée dans votre code ce soir ?

Source : KrebsOnSecurity ↗.

Note (Le mot à retenir)

Secret cloud : clé, jeton ou identifiant donnant accès à des ressources cloud. S’il est exposé dans un fichier public ou un log, n’importe qui peut l’utiliser pour lire, modifier ou supprimer des données, souvent sans laisser de trace immédiate.

🔍 Kali365 : quand la double authentification ne suffit plus#

Schéma du mécanisme AiTM de Kali365 : la victime valide sa MFA normalement mais le proxy intercepte le jeton de session en temps réel

Le FBI alerte sur Kali365 , une plateforme de phishing vendue comme service (PhaaS). Elle cible les comptes Microsoft 365 et contourne la double authentification via une technique dite AiTM (Adversary-in-the-Middle). Un faux site Microsoft joue le rôle d’intermédiaire : la victime entre ses identifiants et valide sa MFA normalement, mais l’attaquant récupère le jeton de session en temps réel. Il peut ensuite se connecter sans avoir eu besoin du code à six chiffres.

Pourquoi c’est important ? La MFA reste essentielle. Mais comprendre ses limites l’est tout autant. Les MFA par SMS ou par code TOTP (Google Authenticator) sont vulnérables à l’AiTM. Arriver en entretien avec cette nuance en tête, c’est déjà se démarquer de la majorité des candidats.

La vraie question c’est : quelle MFA résiste vraiment ? Les clés physiques FIDO2 (type YubiKey) vérifient le domaine du site lors de l’authentification. Si le site est un faux, la clé refuse. Pas parfait dans tous les contextes, mais nettement plus robuste face à ce type d’attaque. C’est pour ça que les organisations les plus exposées migrent vers FIDO2.

Source : BleepingComputer ↗.

Note (Le mot à retenir)

AiTM (Adversary-in-the-Middle) : l’attaquant se place entre vous et le vrai service. Il relaie vos actions en temps réel et intercepte votre jeton de session, celui qui prouve que vous venez de vous authentifier. Il peut ensuite se connecter à votre compte sans avoir eu besoin de votre mot de passe ni de votre code MFA.

🔍 L’IA rédige des rapports d’incident SOC : bilan mitigé#

Comparaison côte à côte du flux de rédaction SOC sans IA et avec IA, l'étape de relecture humaine étant mise en avant

Cisco a expérimenté l’IA générative pour produire des rapports d’incident dans ses équipes SOC. Le résultat est nuancé : les rapports sortent plus vite, mais les analystes ont relevé des imprécisions, un manque de contexte technique et des formulations trop génériques pour être directement exploitables.

Pourquoi ça compte ? Si vous visez un poste SOC, la question est directe : l’IA va-t-elle remplacer les analystes ? La réponse de Cisco est non, pas sans supervision humaine. L’IA peut prendre en charge la structure de base, mais quelqu’un doit valider et apporter le contexte que l’outil n’a pas.

Je dois dire que c’est l’actualité qui me parle le plus cette semaine. En SOC, les rapports d’incident prennent du temps, surtout en fin de nuit. Si l’IA génère un premier jet et que l’analyste se concentre sur la partie critique, c’est un gain réel. Déléguer sans relire, c’est là que ça se complique.

Source : The Register ↗.

Note (Le mot à retenir)

SOC (Security Operations Center) : l’équipe chargée de surveiller les systèmes en temps réel, détecter les incidents et y répondre. Un analyste SOC passe une part importante de son temps à rédiger des rapports pour chaque alerte traitée, ce qui fait de la rédaction assistée un cas d’usage IA très concret.

Conseil (💬 La question qu'on pourrait vous poser en entretien)

“La double authentification suffit-elle à protéger un compte ?”

Pourquoi on vous la pose : le recruteur teste votre capacité à nuancer plutôt qu’à réciter une réponse toute faite. Savoir qu’un outil a des limites, c’est preuve de maturité technique.

Comment y répondre : La MFA réduit très significativement le risque de compromission et reste indispensable. Mais les techniques AiTM permettent de contourner les MFA classiques (SMS, TOTP) en interceptant le jeton de session après authentification réussie. Les implémentations résistantes au phishing, notamment FIDO2, offrent une protection bien plus robuste car elles vérifient le domaine du site. Bonne réponse : recommander la MFA systématiquement, tout en précisant que le type d’implémentation change tout.

Note (📌 Pour aller plus loin)

GitGuardian : gitguardian.com ↗
Outil de détection de secrets exposés dans vos dépôts Git, gratuit pour les projets publics. Utile pour comprendre concrètement comment les clés et tokens se retrouvent dans le code, et pour développer le réflexe de scanner ses dépôts avant de pousser. Directement lié à l’actualité CISA de cette semaine.

À vendredi prochain. D’ici là, un réflexe simple : si vous avez un projet sur GitHub, scannez-le pour des secrets exposés. Vous seriez surpris de ce qui traîne depuis des mois. Lénaïck