Vous Ne Pouvez Pas Annuler un Secret Déjà Lu

Imaginez un coffre-fort contenant une propriété intellectuelle précieuse. Un espion engagé l'ouvre, photographie les documents qu'il contient, le referme et repart. Le lendemain matin, le coffre-fort a exactement la même apparence que la veille au soir : même porte, même combinaison, rien n'a bougé. Il n'y a rien à remettre en place, car, dans les termes que comprend un outil de récupération, rien n'a été pris. La perte a déjà quitté le bâtiment sous forme de copie.

C'est la forme dérangeante que prend une grande catégorie d'attaques contre Active Directory, et c'est pourquoi le récit défensif préféré du secteur comporte une faille en son cœur.

Depuis une décennie, le marché de la sécurité Active Directory se joue sur un seul axe : la rapidité avec laquelle vous pouvez annuler une modification malveillante. Détecter l'écriture malveillante, générer une alerte, puis revenir à un état sain connu. Le suivi des modifications inviolable et le rollback automatisé constituent toute la proposition. En tant que récit de récupération, c'est un bon récit, et la récupération compte réellement. Mais il concède le point qui compte vraiment. La modification a déjà eu lieu, et certaines modifications, une fois survenues, ne peuvent plus être défaites.

Les attaques Active Directory qui se terminent avant que vous puissiez les annuler

Regardez comment se déroulent réellement les attaques AD les plus rapides. Des groupes de ransomware enchaînent des failles comme noPac, la paire d'usurpation de sAMAccountName à l'origine de CVE-2021-42278 et CVE-2021-42287, pour passer d'un compte ordinaire à la domination totale du domaine en quelques minutes. Une fois que l'attaquant a atteint cette position, les techniques qui suivent ne sont pas du vandalisme bruyant que l'on peut nettoyer après coup. Ce sont des lectures et des usurpations d'identité qui achèvent leur travail avant qu'un rollback n'ait quoi que ce soit à récupérer.

DCSync en est l'exemple le plus clair, et le parallèle direct avec l'histoire du coffre-fort. En détournant le propre protocole de réplication de l'annuaire, l'attaquant demande à un contrôleur de domaine les hachages de mots de passe des comptes et les reçoit comme le ferait un autre contrôleur. Aucun objet modifié ne reste dans l'annuaire pour qu'un outil de récupération puisse le repérer et l'annuler. La modification, telle qu'elle est, est une copie de vos identifiants qui est déjà partie. Vous pouvez réinitialiser tous les mots de passe ensuite, et vous devriez le faire, mais à ce stade, vous nettoyez après un vol plutôt que de l'arrêter.

DCShadow agit dans l'autre sens. Il enregistre un contrôleur de domaine illégitime et malveillant, puis injecte dans l'annuaire des modifications choisies par l'attaquant via le canal de réplication, contournant ainsi le chemin d'écriture habituel surveillé par vos contrôles. Ici, le contrôle efficace rejette la réplication frauduleuse à l'instant même où elle est tentée, de sorte que la modification injectée n'entre jamais dans l'annuaire et qu'il n'y a donc rien à annuler.

Prenez maintenant une modification malveillante d'un objet de stratégie de groupe (GPO), du type qui distribue une charge utile de ransomware à chaque machine qui lit la stratégie, ou un ajout discret à un groupe à privilèges. Annulez l'objet, et l'état de l'annuaire est restauré. Pourtant, la stratégie a déjà été distribuée et la charge utile qu'elle transportait a déjà été exécutée. Restaurer l'objet ne change rien au rayon d'impact déjà créé.

C'est là que le récit de la récupération arrive au bout de ses possibilités. Pour toute cette catégorie, la détection et le rollback arrivent, de par leur structure même, trop tard, et la prévention n'est pas une version plus rapide de la même idée : c'est une discipline différente. La détection confirme que quelque chose de dangereux a déjà atteint l'annuaire. La prévention arrête l'opération avant que l'annuaire ne l'accepte.

Détection contre prévention : une attaque GPO, envisagée des deux façons

Supposons qu'un attaquant modifie un GPO lié à vos serveurs pour déployer une charge utile lors de la prochaine actualisation de la stratégie. Raisonnez d'abord selon le modèle de récupération. Le paramètre malveillant est détecté et annulé, et le GPO revient à son état antérieur ; sur le papier, l'incident est clos. Dans la pratique, chaque machine ayant récupéré la stratégie dans la fenêtre entre la modification et l'annulation a déjà exécuté la charge utile, et aucune restauration de l'objet ne peut défaire cette exécution.

Raisonnez maintenant dans l'autre sens. L'écriture sur ce GPO est évaluée de façon inline et rejetée avant qu'Active Directory ne la valide (commit). La stratégie ne change jamais, elle n'est donc jamais distribuée, et il ne reste aucune exécution de charge utile à examiner. Même attaque, deux modèles défensifs, et un seul des deux ne vous laisse rien à nettoyer.

Pourquoi le mot juste est prévention, et non détection rapide

Ce second résultat n'est possible que pour un contrôle situé dans le chemin d'écriture lui-même. C'est le mécanisme derrière Netwrix Threat Manager : il évalue les opérations de façon inline (modifications d'objets critiques et de GPO, modifications de groupes à privilèges et demandes de réplication) et les bloque à la source, avant qu'Active Directory ne valide l'écriture. Il capture également ces événements à leur point d'origine, même lorsque la journalisation native a été désactivée ou effacée, de sorte qu'un attaquant ne peut pas aveugler le contrôle en effaçant d'abord les journaux. C'est ce qui mérite le mot prévention, plutôt qu'une détection rapide habillée d'un vocabulaire plus fort.

Rien de tout cela ne signifie que la prévention remplace la détection. Certaines attaques ne peuvent être repérées et traitées qu'après coup, et prétendre le contraire ne résiste pas à la première question directe que posera tout RSSI compétent. Trop promettre attire la réponse que cela mérite. La position défendable est plus étroite et plus solide qu'un slogan : la prévention en priorité pour les modifications que l'on peut bloquer de façon déterministe, la détection et la réponse pour tout le reste.

Il y a, en dessous de tout cela, une vision cohérente. Insister pour bloquer une modification dangereuse au moment même où elle est tentée est le pendant, côté résilience, d'insister pour savoir qui détient un accès au moment où il l'utilise. Les deux insistent sur le fait d'agir à l'instant de l'action, plutôt que dans le nettoyage qui suit.

Ce qui nous ramène au coffre-fort qui semblait intact. Le rollback est une promesse : vous pouvez défaire les dégâts rapidement. La prévention est une garantie : il n'y avait aucun dégât à défaire. Pour les attaques Active Directory qui copient un secret, usurpent l'identité d'un contrôleur ou se déclenchent avant que vous ne puissiez les annuler, une seule de ces deux promesses est celle que le mécanisme peut réellement tenir, et c'est celle du contrôle qui n'a jamais laissé la modification être validée (commit).