Journal de red team : d’un simple e-mail de phishing à l’administrateur de domaine en six jours

Engagement représentatif. Détails du client anonymisés et éléments spécifiques modifiés sous NDA.

Un seul utilisateur a cliqué sur un lien un mardi après-midi. Le lundi suivant, nous contrôlions leur Active Directory, nous avions lu l’export de la paie et une capture d’écran de celui-ci se trouvait dans notre dossier de butin. Personne, de leur côté, ne l’a remarqué avant le cinquième jour.

Ce client était fier de son périmètre, et honnêtement il avait de bonnes raisons de l’être. VPN durci, EDR sur chaque ordinateur portable, MFA partout. Alors quand il a cadré cette évaluation red team, la consigne était sans détour : arrêtez de nous traiter comme un scan de vulnérabilités. Traitez-nous comme un adversaire qui veut quelque chose de précis. Partez de zéro accès, atteignez l’administrateur de domaine, et voyons qui s’en aperçoit.

Voici le journal, jour après jour. Les noms et les chiffres ont été changés. Le chemin est exactement celui que nous avons parcouru.

Points clés à retenir

• Un seul identifiant récupéré par phishing suffit généralement à atteindre le réseau interne. Le périmètre exposé sur Internet est rarement ce qui vous sauve.
• Le chemin le plus rapide vers l’administrateur de domaine n’est presque jamais un exploit. Ce sont des erreurs de configuration empilées : comptes surprivilégiés, mots de passe d’administrateur local réutilisés et délégation Active Directory faible.
• Qu’un EDR intercepte une charge utile n’est pas la même chose que votre SOC qui y réagit. Nous faisons souvent beaucoup de bruit et restons pourtant sans réponse pendant des jours.
• Le Kerberoasting, les identifiants d’administrateur local partagés et les sessions privilégiées laissées ouvertes sont les trois constats que nous rapportons sur presque chaque engagement interne.
• Une évaluation red team mesure la détection et la réponse, pas seulement l’existence d’une faille. C’est ce qui la distingue d’un test d’intrusion classique.

Qu’est-ce qu’une évaluation red team, et pourquoi ne pas simplement faire un pentest ?

Une évaluation red team est une simulation guidée par un objectif d’un véritable attaquant, menée à la fois contre vos personnes, vos processus et votre technologie. L’objectif n’est pas de “trouver chaque bug de cette application”. C’est quelque chose qu’un criminel voudrait réellement : lire la boîte mail du directeur financier, exfiltrer la base de données clients, pousser une modification en production. Nous choisissons un chemin et avançons discrètement vers lui.

Un test d’intrusion répond à la question de savoir où sont les trous. Une red team répond à ce qui se passe quand quelqu’un en franchit un. Les deux ont leur place. Mais si vous avez déjà mené quelques pentests et que votre conseil d’administration se demande si vous survivriez à une intrusion ciblée, le pentest a cessé d’être le bon outil. Il vous faut quelqu’un qui joue pour gagner, avec un chrono qui tourne, pendant que vos défenseurs ignorent le calendrier.

Jour 1 : l’e-mail sur lequel on a cliqué

Nous n’avons pas arrosé des milliers de messages. Le phishing red team ciblé est discret par nature. Le premier après-midi a été consacré à de la reconnaissance en sources ouvertes : LinkedIn, le blog de l’entreprise, une conférence donnée par l’un de leurs ingénieurs, quelques adresses présentes dans d’anciennes fuites de données. Cela nous a livré la convention de nommage des e-mails ([email protected]) et assez de contexte pour rédiger quelque chose qu’un ingénieur débordé ouvrirait sans réfléchir.

Le prétexte était un document partagé au sujet d’une migration d’outillage interne, visant l’équipe plateforme. Pas le CEO. Les ingénieurs ont un accès plus large et cliquent sur davantage de liens. La page de destination était un clone soigné de leur page de connexion Microsoft, servie depuis un domaine ressemblant que nous avions enregistré et laissé vieillir pendant deux semaines pour qu’il ne paraisse pas fraîchement créé. Nous l’avons exploitée derrière un reverse proxy de type evilginx, ce qui signifie que nous avons capturé le mot de passe et le cookie de session. Ce cookie passe directement au-delà du MFA.

Deux clics dans la première heure. Une connexion menée à terme. Nous détenions désormais une session valide et des identifiants valides d’un ingénieur de niveau intermédiaire. Cela correspond proprement à MITRE ATT&CK T1566 (Phishing) et T1078 (Valid Accounts), et c’est là que commencent réellement la plupart de nos engagements.

Jour 2 : prendre pied et regarder autour

Des identifiants volés, c’est bien. L’exécution de code sur un hôte interne, c’est mieux. Nous avons utilisé la session pour atteindre leur portail VPN, avons atterri dans une position à faibles privilèges et pris pied sur le poste de travail de l’ingénieur. Cela change toute la donne. Nous pouvons maintenant énumérer le domaine depuis l’intérieur.

Notre premier geste sur tout réseau interne est une reconnaissance discrète avec BloodHound. Collecter les données de session, les ACL et les appartenances aux groupes, puis laisser le graphe nous indiquer où passe le chemin le plus court vers l’administrateur de domaine. Ce n’est presque jamais une ligne droite. Il y a presque toujours une ligne.

# Collect Active Directory data from the foothold (low and slow)
SharpHound.exe --collectionmethods DCOnly,Session --stealth

# Then in the BloodHound UI: mark our compromised user as Owned,
# and run "Shortest Paths to Domain Admins from Owned Principals"

Le graphe s’est illuminé. Notre ingénieur compromis appartenait à un groupe disposant des droits d’administrateur local sur un cluster de serveurs de build. Le genre de groupe surprivilégié dont personne ne se souvient avoir accordé l’accès et que personne n’a revu depuis. C’était notre bretelle d’accès.

Jour 3 : Kerberoasting et cassage hors ligne

Tout utilisateur du domaine peut demander des tickets de service Kerberos pour les comptes dotés d’un Service Principal Name. Ces tickets sont chiffrés avec le hash du mot de passe du compte de service. On les demande donc, on les récupère et on les casse hors ligne, là où aucune politique de verrouillage ni aucune alerte ne peut vous atteindre. C’est le Kerberoasting (T1558.003), et c’est l’astuce la plus fiable dont nous disposons sur les réseaux internes.

# Request roastable service tickets with Impacket
GetUserSPNs.py acme-corp.example/j.doe -request -dc-ip 10.10.0.5 -outputfile roast.txt

# Crack offline with Hashcat (mode 13100 = Kerberos TGS-REP)
hashcat -m 13100 roast.txt rockyou.txt -r best64.rule

Un compte de service cassé en moins d’une heure. Le mot de passe était Summer2023!, défini par un humain, sur un compte doté d’une politique sans expiration et, comme il s’est avéré, membre d’un groupe privilégié. C’est partout le même schéma : un compte de service est créé une fois, on lui accorde plus de droits qu’il n’en a besoin “par sécurité”, puis plus personne n’y touche pendant quatre ans.

Jour 4 : mouvement latéral et récolte d’identifiants

Les droits d’administrateur local sur les serveurs de build signifiaient que nous pouvions nous déplacer latéralement. Nous avons été méthodiques ici. C’est la phase où un outillage bruyant fait repérer les équipes, et où un SOC compétent aurait dû se réveiller. Nous avons évité d’écrire Mimikatz sur le disque et avons extrait les identifiants mis en cache depuis la mémoire, dans le processus, puis réutilisé le hash de l’administrateur local pour nous authentifier ailleurs.

Ce mot de passe d’administrateur local était identique sur chaque serveur du segment. Un seul hash. Pass-the-hash (T1550.002). Des dizaines d’hôtes. Sur l’un d’eux, un administrateur avait laissé une session RDP ouverte, et la récolte de ce jeton nous a offert le contexte d’un administrateur de domaine sans jamais apprendre le mot de passe. Les identifiants d’administrateur local réutilisés et les sessions privilégiées oubliées sont, d’après notre expérience, les deux choses qui transforment le plus souvent un pied dans la porte circonscrit en perte totale.

Jour 5 : administrateur de domaine, et le premier appel téléphonique

Au cinquième jour, nous détenions un jeton d’administrateur de domaine. Pour prouver l’impact sans rien casser, nous avons exécuté un DCSync contrôlé (T1003.006) afin d’extraire le hash du compte krbtgt, la clé qui permet à un attaquant de forger des golden tickets et de persister plus ou moins indéfiniment. Nous n’avons pas construit le golden ticket en production. Nous avons documenté la capacité et nous nous sommes arrêtés là.

C’est aussi le jour où le SOC a enfin appelé notre point de contact. Notre mouvement latéral de la veille avait déclenché une alerte EDR. La charge utile a été signalée. Mais l’alerte est restée dans une file d’attente la majeure partie d’une journée avant que quiconque ne la trie. La technologie a fonctionné. La réponse, non. C’est précisément cet écart qu’une évaluation red team existe pour mesurer, et qu’aucun scanner ne trouvera jamais.

Jour 6 : atteindre l’objectif

L’objectif convenu était l’accès à des données financières sensibles. Avec l’administrateur de domaine, cette partie était triviale. Nous avons monté le partage de fichiers de la finance, trouvé un export de la paie et un dossier de données personnelles clients non chiffrées, capturé des preuves, horodaté le tout, puis nous nous sommes retirés. Aucune donnée n’a quitté leur environnement. Temps total écoulé du premier clic à l’objectif : six jours, dont l’essentiel passé à avancer lentement à dessein pour tester si quelqu’un observait.

Ce que nous avons trouvé : les véritables causes profondes

Rien de tout cela n’a nécessité de zero-day. Pas une seule CVE n’était en jeu. Toute la chaîne reposait sur la configuration et l’hygiène :

• Un MFA qui n’a pas survécu au vol de session. Leur MFA tenait bien face au password spraying et était inutile face à un phishing par reverse proxy qui vole le cookie de session. Un MFA résistant au phishing avec des clés matérielles FIDO2 brise la chaîne dès le premier jour.
• Un compte de service kerberoastable avec un mot de passe faible et statique. Un secret géré de plus de 25 caractères, ou un compte de service géré de groupe (group Managed Service Account), et il cesse d’être cassable.
• Des mots de passe d’administrateur local partagés. Windows LAPS génère aléatoirement le mot de passe d’administrateur local par machine. Avec lui, notre déferlement de pass-the-hash s’arrête à exactement un hôte.
• De la détection sans réponse. L’alerte existait. Le runbook pour la traiter en quelques minutes, non.

Comment on arrête généralement cela

Voici la partie inconfortable. Dépenser davantage en outils de prévention n’aurait pas beaucoup aidé ce client. Il avait déjà de bons outils. Ce qui lui manquait, c’était l’hygiène de configuration et un processus de réponse testé sous pression. Faites tourner et coffrez les identifiants des comptes de service. Déployez LAPS. Basculez les comptes privilégiés sur un MFA résistant au phishing. Cloisonnez vos comptes d’administration par niveaux pour qu’une compromission de poste de travail ne puisse pas atteindre un jeton d’administrateur de domaine. Et surtout, menez des tests en conditions réelles contre votre SOC jusqu’à ce qu’une alerte se transforme en action plutôt qu’en entrée dans une file d’attente.

Comment CyberXplore vous aide

C’est le travail que nous menons toute l’année. Notre service d’évaluation red team réalise des simulations d’adversaire guidées par un objectif qui reflètent la façon dont opèrent les véritables intrus : phishing, prise de pied, chemins d’attaque Active Directory et mouvement latéral discret, afin que vous appreniez jusqu’où quelqu’un parvient et si votre équipe le détecte à temps. Vous obtenez un récit d’attaque comme celui ci-dessus, chaque étape cartographiée sur MITRE ATT&CK, ainsi que des remédiations que vos ingénieurs peuvent appliquer dès le lundi matin. Si vous voulez savoir comment votre environnement tient le coup, demandez un devis et dites-nous quels sont vos joyaux de la couronne.

FAQ

Combien de temps dure une évaluation red team ?

La plupart des engagements durent de trois à six semaines de bout en bout, selon le périmètre et le niveau de discrétion souhaité. L’intrusion active de ce journal a pris six jours, mais les vraies red teams avancent souvent lentement à dessein pour tester la détection dans la durée. La reconnaissance, le reporting et un atelier de débriefing s’ajoutent au calendrier.

En quoi une évaluation red team diffère-t-elle d’un test d’intrusion ?

Un test d’intrusion énumère et prouve les vulnérabilités dans un périmètre défini, généralement avec des défenseurs au courant que cela a lieu. Une évaluation red team est guidée par un objectif et furtive. Elle teste ensemble les personnes, les processus et la détection, et le succès consiste à atteindre un but comme l’administrateur de domaine ou l’exfiltration de données. Si vous n’avez jamais mené de pentest, commencez par là. Le red teaming suppose un niveau de maturité de base raisonnable.

Une évaluation red team va-t-elle perturber nos systèmes de production ?

Non. Nous travaillons selon des règles d’engagement strictes convenues à l’avance, évitons les actions destructrices et nous coordonnons avec un petit groupe de confiance de votre côté. Les étapes de preuve d’impact comme DCSync sont réalisées de manière contrôlée, et nous ne retirons jamais de données réelles de votre environnement. La sûreté et la réversibilité sont inscrites dans le périmètre.

Devons-nous prévenir notre équipe de sécurité que cela a lieu ?

En général, seule une petite “white cell” de parties prenantes de confiance connaît le calendrier, afin que la réponse du SOC soit authentique. C’est tout l’intérêt. Si les défenseurs vous guettent, vous n’apprenez rien sur la détection en conditions réelles. Nous convenons à l’avance d’un mot de sécurité et de contacts d’escalade pour que personne ne transforme une fausse alerte en crise.

Que recevons-nous à la fin ?

Un récit d’attaque complet, chaque étape cartographiée sur MITRE ATT&CK, des preuves pour chaque constat, un plan de remédiation priorisé que vos ingénieurs peuvent exécuter, et un débriefing destiné à la fois aux publics techniques et dirigeants. La valeur ne réside pas dans la liste des problèmes. Elle réside dans l’histoire de la façon dont ils se sont enchaînés et de ce qui brise la chaîne.

À quelle fréquence devrions-nous en mener une ?

Chaque année pour la plupart des organisations, ou après un changement majeur comme une fusion, une migration vers le cloud ou la mise en place d’un nouveau SOC. Les environnements dérivent, le personnel change, et les erreurs de configuration qui nous ont laissés entrer ont tendance à réapparaître. Une évaluation red team périodique maintient votre détection et votre réponse honnêtes.