Chaque enquête sur une brèche cloud qui commence par un identifiant exposé ou un bucket S3 ouvert se termine de la même manière : quelqu'un trouve un fichier .tf, ou un terraform.tfstate dans un bucket S3, ou un pipeline CI qui a exécuté terraform apply avec des clés admin intégrées dans une variable d'environnement. Terraform n'est pas intrinsèquement non sécurisé, mais les schémas qui le rendent rapide à utiliser sont précisément ceux qui créent la plus grande surface d'attaque. Les secrets en dur survivent dans l'historique Git après suppression. Les fichiers d'état stockent chaque attribut de ressource en clair, y compris les mots de passe, clés privées et chaînes de connexion, que vous les ayez marqués sensibles ou non. Ce ne sont pas des risques hypothétiques, ce sont les conclusions littérales de chaque engagement IR cloud majeur des cinq dernières années.

Votre chaîne d'approvisionnement logicielle est déjà à l'intérieur du périmètre de votre réseau. Chaque fois qu'un développeur pousse un commit, votre pipeline CI/CD s'authentifie auprès de votre fournisseur cloud, extrait des secrets de votre coffre-fort, compile et signe des artefacts, et pousse du code directement en production, le tout sans qu'un humain n'approuve la moindre étape. Les attaquants l'ont compris en 2020 avec SolarWinds, l'ont affiné avec la brèche Codecov en 2021, l'ont opérationnalisé à grande échelle avec les compromissions 3CX et XZ Utils en 2023-2024, et en août 2025, UNC6395 l'a utilisé pour compromettre le compte GitHub de Drift, voler des jetons OAuth et accéder aux environnements Salesforce de centaines d'organisations, sans jamais toucher directement le réseau d'une seule victime. La surface d'attaque n'est pas une mauvaise configuration que vous pouvez corriger. C'est le pipeline lui-même.

Au moment où le rançongiciel commence à chiffrer les fichiers, l'attaquant a déjà gagné. L'événement de chiffrement qui déclenche votre alerte EDR, votre ticket SOC et votre contrat de réponse à incident n'est pas l'attaque, c'est l'étape finale d'une opération commencée des jours ou des semaines plus tôt, durant laquelle l'acteur de la menace a cartographié tout votre Active Directory, est passé Domain Admin, a exfiltré vos données les plus sensibles vers un bucket de stockage cloud, a tué vos sauvegardes et a confirmé que chaque cliché instantané de chaque serveur a disparu. Le chiffrement lui-même prend quelques minutes. Tout ce qui le rend dévastateur le levier, l'irréversibilité, l'ampleur a été assemblé pendant la période de latence où votre SIEM ne générait aucune alerte.

L'attaquant est dans votre réseau depuis six jours. Vous n'avez pas de capture de paquets. Vous n'avez pas de sonde IDS sur le trafic est-ouest. Votre licence NDR ne couvre que le périmètre. L'EDR sur l'hôte compromis a été désactivé au deuxième jour. Ce que vous avez : les journaux de requêtes du serveur DNS, les enregistrements de baux DHCP, le NetFlow de vos commutateurs cœur de réseau, et les journaux de sécurité Windows de vos contrôleurs de domaine. C'est suffisant si vous savez exactement quoi chercher, dans quel ordre, et comment corréler des sources qui n'ont jamais été conçues pour communiquer entre elles.

Un analyste signale une alerte suspecte de mouvement latéral. Vous consultez la chronologie de l'enquête. Il y a un écart de 47 minutes dans les événements de création de processus d'un serveur critique exactement dans la fenêtre où l'attaquant s'est déplacé. L'EDR ne montre rien. Le SIEM ne montre rien. L'analyse forensique post-incident sur la machine locale révèle 6 800 événements qui n'ont jamais quitté le terminal. Le journal d'événements de sécurité s'est réécrit sur lui-même. L'abonnement WEF avait un bug de filtre. Le serveur WEC était sous charge. Personne ne l'a remarqué parce que personne ne mesurait. Ce scénario n'est pas hypothétique c'est la cause racine la plus fréquente des lacunes de détection trouvées lors des revues post-incident, et il est presque entièrement évitable.

Vous fixez une alerte EDR à 23h47. Un document Word a lancé PowerShell. Au moment où votre analyste prend en charge le ticket à 00h09, l'attaquant a déjà une balise qui appelle son C2, a exécuté BloodHound sur tout votre AD, extrait les identifiants de LSASS, et s'authentifie sur votre contrôleur de domaine avec un hash d'Administrateur de Domaine. Le "temps de présence moyen de 200 jours" que vous avez cité lors du comité de direction du trimestre dernier va bientôt devenir une note de bas de page. Cette intrusion se terminera en quatre heures.

Catégorie : Renseignement sur les Menaces · Temps de lecture : 25 min · Audience : Analystes SOC, Ingénieurs de Détection, Intervenants sur Incidents

Pour qui : Les analystes sécurité qui veulent comprendre les mécaniques d'attaque précises, et les RSSI qui ont besoin de savoir pourquoi leur EDR leur donne une fausse confiance face à cette classe de menaces. Chaque technique présentée ici a été observée dans des intrusions réelles pas de théorie creuse.

Votre utilisateur vient de compléter le MFA. Il a saisi son code d'authentification correctement. Microsoft l'a accepté. Votre stratégie d'Accès Conditionnel a été évaluée et validée. Et l'attaquant assis derrière un serveur dans un autre pays vient de recevoir un jeton d'accès OAuth valide pour 60 à 90 minutes, un jeton d'actualisation valable 90 jours, et un accès à l'intégralité de votre environnement Microsoft 365. Pas de page de phishing. Pas de faux formulaire de connexion. Aucune information d'identification volée. Le MFA a été le mécanisme utilisé par l'attaquant pour s'authentifier au nom de la victime. Ce n'est pas une menace future. Elle est activement exploitée depuis au moins mi-2024, et les campagnes ont fortement augmenté fin 2025.