Lundi. 9h47.

J'ai déjà l'accès domaine admin. L'ai obtenu le mois passé en sondant leur structure Active Directory. Ils ont dit à tout le monde qu'ils avaient implémenté le tiering. Ce qu'ils ont réellement fait c'était renommer quelques unités organisationnelles et l'appeler un jour. Tout le monde a les droits admin partout. J'ai trouvé un service account sur une workstation avec des credentials mis en cache. Personne ne surveillait le cache de credentials. J'avais ce que je voulais.

Aujourd'hui j'utilise cet accès pour passer à l'étape suivante.

Je compose une demande de certificat pour webmail.example.com.

Je la soumets à leur Certificate Authority.

Leur AC ne devrait pas émettre de certificats pour cet espace de noms. Il n'y a pas de serveur webmail.example.com dans leur infrastructure. Ils n'ont pas de Certificate Policy and Practice Statement qui définit pour quels espaces de noms l'AC peut émettre. Il n'y a pas de document de politique. Il n'y a pas de baseline pour ce qui est autorisé. Un administrateur qui fait vraiment son travail vérifierait la demande en premier. Il regarderait la PDP. Est-ce que l'AC permet d'émettre des certificats dans cet espace de noms? Non. Il croiserait les références avec la base de données d'infrastructure. Est-ce que ce serveur existe dans nos registres? Non. Il poserait la question évidente : pourquoi émettons-nous un certificat pour un serveur qui n'existe pas? Il n'y a pas de justification commerciale. La demande est rejetée. Je ne franchis jamais le premier portail.

Mais voici ce qui se passe réellement.

9h48.

Le certificat auto-émet soit parce que le modèle permet aux Authenticated Users de s'inscrire sans approbation requise. Ou il atterrit dans la queue d'un approbateur. L'approbateur a quarante-sept éléments en attente. Examen du budget. Approbation de fournisseur. Ticket d'incident. Préparation de réunion. Trois autres demandes de certificats empilées derrière la mienne. Il jette un coup d'œil. Demande de certificat. Ça a l'air normal. Clique pour approuver. Passe à la suite. Il n'a pas vérifié si webmail.example.com faisait partie d'un projet courant. Il n'a pas vérifié si c'est un espace de noms autorisé. Il n'a pas croisé les références avec la base de données d'infrastructure. Il a juste approuvé ça parce que ça ressemblait à une demande de certificat et il avait trop d'autres choses à faire.

À 9h51, j'ai un certificat pour un espace de noms que leur propre politique AC aurait dû rejeter.

9h50.

J'ai domaine admin. Je l'utilise pour modifier les enregistrements DNS. Je crée un enregistrement A pour webmail.example.com. Il pointe vers mon serveur. Quand des utilisateurs dans cette organisation tapent webmail.example.com dans leur navigateur, ils frappent ma box au lieu de la vraie.

9h52.

Je configure un reverse proxy. Quand les utilisateurs se connectent, ils voient le vrai formulaire de connexion webmail de leur organisation. C'est parfait. Le certificat SSL que je viens d'obtenir de leur AC se valide. Le nom de domaine est correct. Tout est légitime. Ils tapent leur nom d'utilisateur et mot de passe. Mon serveur le capture. Nom d'utilisateur. Mot de passe. Récolté. Stocké.

Ensuite mon serveur transfère les credentials au vrai serveur webmail. Si les credentials sont valides, ils se connectent normalement. Ils n'ont aucune idée que quelque chose s'est passé. S'ils ont fait une faute de frappe, mon serveur envoie l'erreur réelle de leur vrai serveur : « Mauvais nom d'utilisateur ou mot de passe. Réessayez. »

L'utilisateur pense qu'il a mal tapé. Il essaie à nouveau plus soigneusement. Même erreur. Il assume que quelque chose ne fonctionne pas avec le système et il passe à autre chose.

J'ai maintenant des credentials valides.

10h15.

admin@example.com : D7$xKm9@

Valide. Connecté. Passé.

10h42.

finance@example.com : Tr0pic$sun2024

Valide. Connecté. Passé.

11h15.

operations@example.com : SecurePass#2024

Valide. Maintenant j'ai des credentials pour l'équipe d'opérations.

À midi j'ai capturé des credentials réels et fonctionnels pour sept utilisateurs dans leur organisation. Aucun d'eux ne sait que c'est arrivé. Ils pensent qu'ils ont eu une mauvaise journée en essayant d'accéder à l'email.

11h30.

J'ai domaine admin. Je l'utilise pour vérifier le système de email. Spécifiquement, je cherche quelle boîte aux lettres a le trafic le plus sensible. Finance? Exécutif? Opérations? J'identifie le gestionnaire des finances. Sa boîte aux lettres aurait des informations de budget, des négociations de fournisseurs, des discussions d'acquisition. Tout ce que j'ai besoin de comprendre les vraies priorités et vulnérabilités de cette organisation.

Je me connecte en utilisant les credentials que je viens de capturer de cet utilisateur.

Je configure une règle de transmission de courrier. Chaque email qui arrive dans ce compte se transfère à mon serveur. Mais j'ai pas fini.

11h45.

Voici la chose avec leur MFA : ils utilisent des OTPs basées sur email. Quand tu dois t'authentifier à quelque chose, ils envoient un mot de passe unique à ton email.

C'est du security theater si ton attaquant contrôle l'email.

Je vérifie la règle de transmission. Ça fonctionne. Chaque email entrant se transfère à mon serveur en temps réel.

Un OTP arrive. Destiné à l'authentification de quelqu'un d'autre. J'ai maintenant cet OTP avant eux.

12h30.

J'ai tout.

Un certificat légitime de leur AC pour un espace de noms que leur propre politique aurait dû rejeter. Des credentials capturés pour plusieurs utilisateurs. Accès complet à la boîte aux lettres du gestionnaire des finances. Capacité d'interception des OTPs en temps réel. La capacité de recevoir n'importe quel code d'authentification destiné à n'importe qui dans l'organisation avant qu'il le voit.

J'ai domaine admin depuis le mois passé. J'ai accès à l'email depuis aujourd'hui. J'ai leur infrastructure d'OTP compromise.

J'ai l'accès organisationnel complet. Pas via des techniques sophistiquées. Via une série de défaillances opérationnelles qui se sont composées parfaitement.

Ce qui aurait dû arriver

Maintenant laisse-moi te montrer ce qui aurait dû arriver à chaque étape.

La demande de certificat arrive. Le système devrait vérifier : cette demande est-elle associée à un projet? Y a-t-il un ticket de changement? Y a-t-il une justification commerciale? Il n'y en a pas. La demande devrait être signalée pour un examen supplémentaire. Un approbateur devrait poser la question : pourquoi émettons-nous un certificat pour webmail.example.com? Quel besoin commercial cela sert-il? Il n'y a pas de besoin commercial légitime. La demande est rejetée. Je ne franchis jamais le premier portail.

Mais ça ne s'est pas passé parce qu'il n'y a pas de suivi de projet pour les demandes de certificats. Il n'y a pas de Certificate Policy and Practice Statement. L'AC n'en a pas. Il n'y a pas de document définissant ce que l'AC est supposée faire. Quels espaces de noms il peut émettre. Quelle validation est requise. Quelle justification commerciale est nécessaire. Comment le processus d'approbation doit fonctionner. Sans une PDP, il n'y a pas de politique à enforcer. Il n'y a pas de standard. Il n'y a pas de contrôle. Une demande de certificat est juste un artefact technique. L'approbateur n'a pas de baseline à vérifier. Il n'a aucun moyen de savoir si ce certificat sert un but commercial réel ou est une tentative de compromission.

Donc la demande auto-émet ou se fait tamponner.

L'AC devrait avoir une Certificate Policy and Practice Statement qui définit explicitement pour quels espaces de noms elle est autorisée à émettre des certificats. Pas tous les espaces de noms. Des espaces de noms spécifiques et approuvés. Quand une demande arrive pour webmail.example.com, le système devrait vérifier : est-ce que cet espace de noms est dans la PDP? Est-il autorisé pour l'émission? Il ne l'est pas. La demande est rejetée automatiquement. L'AC refuse d'émettre un certificat pour un espace de noms non autorisé peu importe qui l'a demandé ou quelle approbation ils avaient.

Mais ça ne s'est pas passé parce qu'il n'y a pas de PDP. Sans elle, l'AC n'a pas de politique définie limitant l'émission. L'AC permet d'émettre pour n'importe quel espace de noms dans le domaine de l'organisation. Il n'y a pas de whitelist explicite d'espaces de noms autorisés. Il n'y a pas de document de politique à enforcer. Il n'y a pas de check empêchant les certificats pour les espaces de noms que l'organisation n'utilise pas réellement.

Donc j'obtiens le certificat.

Même si la validation de projet et de l'espace de noms avait échoué, l'approbateur devrait toujours vérifier la demande. Il devrait vérifier : est-ce que ce serveur est dans notre infrastructure? Est-ce que cette demande est attendue? Est-ce que cet espace de noms est légitime? S'il ne peut pas répondre à ces questions avec confiance, il devrait la rejeter et demander une clarification.

Mais ça ne s'est pas passé parce que l'approbateur est surchargé. Il a trop de demandes dans sa queue. Il prend des décisions sous pression. Il approuve sans valider. Il tamponne plutôt que de revoir.

Donc j'obtiens le certificat.

L'organisation devrait surveiller les changements DNS. Nouveaux enregistrements A, enregistrements CNAME, n'importe quoi. Quand un nouvel enregistrement apparaît pour webmail.example.com pointant vers une adresse IP inattendue, une alerte devrait se déclencher. L'équipe DNS enquête. Elle trouve que quelqu'un avec l'accès domaine admin a créé un enregistrement DNS pointant vers un serveur externe. Elle le corrige immédiatement. Elle enquête sur comment l'attaquant a obtenu le domaine admin en premier lieu.

Mais ça ne s'est pas passé parce qu'il n'y a pas de surveillance des changements DNS. Les changements se font silencieusement. Personne ne remarque que webmail.example.com pointe maintenant vers l'infrastructure d'un attaquant.

Donc je redirige DNS.

L'organisation devrait surveiller les patterns d'authentification. Plusieurs échecs de connexion depuis la même IP. Patterns de connexion bizarres utilisant des credentials réels mais avec un comportement suspect. Quand les utilisateurs commencent à recevoir des erreurs de mauvais mot de passe et essaient à nouveau depuis la même IP, c'est suspect. Une alerte devrait se déclencher. L'équipe de sécurité enquête. Elle trouve que les utilisateurs s'authentifient au serveur contrôlé par l'attaquant. Elle bloque l'infrastructure. Elle invalide les credentials compromis.

Mais ça ne s'est pas passé parce qu'il n'y a pas de détection d'anomalie d'authentification. Les connexions échouées sont loggées mais pas analysées. Un pattern d'échecs de connexion suivi de connexions réussies a l'air normal. Personne ne remarque le pattern qui indique la récolte de credentials.

Donc je récolte des credentials.

Chaque règle de transmission de courrier qui est créée devrait déclencher une alerte. Qui l'a créée? Quelle est la destination? Est-ce attendu? Pour le gestionnaire des finances, qui ne transfère jamais le courrier, une nouvelle règle soudainement transférant vers une adresse externe devrait lever des drapeaux immédiats. La règle est désactivée. Le compte fait l'objet d'une enquête pour compromission. L'utilisateur est notifié.

Mais ça ne s'est pas passé parce que les règles de transmission de courrier ne sont pas auditées. Elles peuvent être créées sans déclencher d'alertes. Un attaquant avec des credentials compromis peut configurer des règles de transmission et personne ne remarque jusqu'à ce qu'un audit de conformité se produise des mois plus tard.

Donc je configure la transmission.

L'organisation utilise le MFA. OTP basée sur email. C'est intrinsèquement faible parce que si l'email est compromise, le MFA est compromise. La bonne approche est le MFA ne devrait jamais dépendre de l'email comme mécanisme de livraison. Tokens matériels. Apps d'authentification. Notifications push vers une app séparée. N'importe quoi qui ne dépend pas de l'email.

Si l'OTP basée sur email est inévitable, au moins surveille les patterns impossibles. Si le même OTP d'une personne est utilisé depuis deux emplacements géographiquement impossibles à la même minute, c'est suspect.

Mais ça ne s'est pas passé parce que l'OTP basée sur email est le seul mécanisme MFA. Il n'y a pas de détection pour les patterns de réutilisation d'OTP. Un attaquant interceptant l'email voit chaque OTP avant l'utilisateur.

Donc j'intercepte les OTPs.

L'organisation devrait avoir implémenté le vrai tiering. Les domaine admins ont des comptes et workstations séparés des utilisateurs réguliers. L'accès admin n'est pas mis en cache sur les workstations utilisateurs. Les service accounts sont rotatés régulièrement. Un attaquant ne peut pas obtenir des credentials domaine admin en trouvant simplement un service account mis en cache sur une workstation régulière.

Mais ça ne s'est pas passé parce que l'organisation a dit qu'elle avait implémenté le tiering. Elle a renommé quelques unités organisationnelles. Elle a appelé ça un jour. En réalité, tout le monde a les droits admin sur la plupart des systèmes. Les credentials des service accounts sont assis dans le cache de credentials sur les workstations. Un attaquant avec une seule workstation compromise peut escalader vers domaine admin en minutes.

Donc j'avais domaine admin au départ.

La timeline

9h47 : Demande de certificat soumise.

9h51 : Certificat émis. Soit auto soit tamponné.

9h52 : Enregistrement DNS créé pointant vers le serveur de l'attaquant.

10h15 : Premiers credentials utilisateurs récoltés.

11h30 : Compte email compromis via credentials récoltés.

11h45 : Premier OTP intercepté.

12h30 : Accès organisationnel complet atteint. Domaine admin. Accès email. Interception des OTPs.

Temps total : 2 heures 43 minutes. Zéro détection. Compromission complète.

Comment arrêtes-tu cette attaque?

Tu demandes la validation de projet pour chaque demande de certificat. Chaque certificat doit être associé à un projet ou ticket de changement. Il doit y avoir une justification commerciale. Un approbateur ne peut pas approuver un certificat sans comprendre ce que c'est et pourquoi c'est nécessaire.

Tu définis et enforces la politique de l'espace de noms. L'AC a une Certificate Policy and Practice Statement qui liste explicitement pour quels espaces de noms elle émettra des certificats. N'importe quelle demande pour un espace de noms en dehors de cette liste est rejetée automatiquement.

Tu valides contre l'inventaire d'infrastructure. Avant l'approbation, le système vérifie : est-ce que ce serveur existe dans notre base de données d'infrastructure? Est-il enregistré? Est-il autorisé? Si non, la demande est signalée ou rejetée.

Tu surveilles les changements DNS. Chaque création ou modification d'enregistrement DNS est loggée et alertée. Les enregistrements A inattendus pointant vers des adresses IP externes déclenchent une enquête immédiate.

Tu surveilles les patterns d'authentification. Les connexions échouées sont analysées. Un pattern de multiples connexions échouées suivi par des réussites depuis la même IP indique une interception de credentials. Alerte. Enquête. Blocage.

Tu audites la transmission de courrier. Chaque création de règle de transmission de courrier est loggée et alertée. La transmission vers des adresses externes demande approbation. Les règles de transmission sur les comptes sensibles déclenchent des alertes automatiquement.

Tu utilises le MFA basé sur le matériel. L'OTP basée sur email est intrinsèquement faible si l'email est compromise. Utilise les tokens matériels, les clés FIDO2, ou les apps d'authentification. N'importe quoi qui ne dépend pas de l'email.

Tu implémentes le vrai tiering. Pas du renommage d'unité organisationnelle. Le vrai tiering. Les domaine admins ont des comptes et workstations séparés. Les credentials admin ne sont pas mis en cache sur les machines utilisateurs. Les service accounts sont rotatés. L'accès privilégié est surveillé.

Tu utilises un outil opérationnel qui force ces validations à arriver peu importe si l'approbateur est occupé ou non.

Où Truvald s'insère

Truvald fait ça au niveau du certificat. Il valide chaque demande contre l'association du projet, la politique de l'espace de noms, et le croisement d'infrastructure. Il affiche une décision : approuver ou rejeter.

Je n'obtiens pas le certificat à 9h51. La demande est rejetée à 9h48.

La cascade de défaillances ne se produit jamais parce que la première défaillance est prévenue.

Huit défenses, toutes absentes

Cette attaque a fonctionné parce que huit défenses séparées ont échoué simultanément. Pas parce qu'elles étaient toutes terribles. Parce qu'elles étaient toutes absentes ou inefficaces.

La demande de certificat aurait dû être rejetée au niveau du modèle, du niveau d'approbation, du niveau DNS, du niveau d'authentification, du niveau email, et du niveau MFA. Elle n'a été rejetée à aucun de ces niveaux.

Une organisation avec même trois de ces contrôles en place aurait attrapé cette attaque à midi. Une organisation avec les huit n'aurait jamais atteint 9h51.

Tu n'as pas besoin de sécurité parfaite. Tu as besoin de sécurité en couches qui fonctionne réellement. La plupart des organisations ont les couches dessinées sur un diagramme. Peu d'organisations les implémentent réellement opérationnellement.

Truvald rend une de ces couches opérationnelle par défaut. Ça force la validation du projet, la validation de l'espace de noms, et le croisement d'infrastructure.

Mais le vrai fix est l'organisation qui fait son travail : implémente le reste des couches, les opère constamment, surveille les gaps quand ils échouent.

Parce que si ces gaps existent, un attaquant comme moi les trouvera. Et à midi, j'aurai tout.

Hiro out.