Un plan de récupération d'Active Directory (AD) devrait être une priorité de votre plan de détection et de réponse aux menaces d'identité (ITDR). Après tout, nous vivons dans un monde fédéré d'identités hybrides, de connexion sans contact et de travail distribué. Dans ce paysage numérique, tout est connecté. Pour la plupart des organisations, AD est au cœur de l'authentification des travailleurs afin qu'ils puissent utiliser des applications et des services connectés à l'échelle mondiale. Si AD n'est pas sécurisé, rien ne l'est.
Toutes les organisations préfèrent prévenir une attaque AD plutôt que de se remettre d'une telle attaque. Pourtant, de nombreuses tentatives d'attaques AD aboutissent. Selon un rapport d'Enterprise Management Associates, 50 % des organisations ont subi une attaque AD au cours des deux dernières années, et plus de 40 % d'entre elles indiquent que l'attaque AD a été couronnée de succès. Une autre statistique du rapport donne à réfléchir : Les testeurs de pénétration ont indiqué qu'ils ont réussi à exploiter les expositions AD dans 82 % des cas.
Téléchargez dès aujourd'hui votre rapport d'enquête gratuit sur l'évaluation de l'ITDR.
Sécuriser AD est important, mais la capacité à récupérer AD après une cyberattaque - la composante "réponse" de l'ITDR - est primordiale compte tenu de la prolifération des attaques sophistiquées qui ciblent AD. Voyons comment AD est devenu un vecteur d'attaque privilégié pour les cybercriminels et examinons un scénario réel qui illustre le processus complexe de récupération d'Active Directory.
Pourquoi faut-il un plan de récupération d'Active Directory ?
Malheureusement, Active Directory est souvent le maillon faible de la chaîne de sécurité des identités. Le problème n'est pas AD lui-même. Lorsqu'il est correctement configuré et déployé, AD peut être incroyablement polyvalent. Malheureusement, AD peut être mal configuré d'autant de façons qu'il est déployé.
Et les acteurs de la menace le savent. C'est pourquoi 90 % des attaques étudiées par la société de conseil en cybersécurité Mandiant impliquaient l'AD sous une forme ou une autre. Dans ces cas, AD était le vecteur d'attaque initial, il était ciblé pour obtenir une persistance, ou il était utilisé pour obtenir des privilèges et permettre un mouvement latéral à travers le réseau.
Le problème est double :
- Tout d'abord, les faiblesses systémiques d'AD en font une cible facile. Comme l'identité dans le nuage s'étend à partir d'AD, c'est une cible de choix pour l'abus d'informations d'identification, une tactique impliquée dans 80 % de toutes les violations de données.
- Deuxièmement, le modèle de confiance zéro pour l'accès au réseau comporte une lacune : il suppose implicitement que les systèmes sur lesquels il est appliqué, y compris AD, conservent leur intégrité.
C'est pourquoi AD est souvent un élément essentiel de la chaîne d'exécution des cyberattaques. Les acteurs de la menace utilisent l'AD pour tout faciliter, des techniques de persistance à l'escalade des privilèges en passant par l'évasion des défenses.
Un scénario catastrophe dans le monde réel
Nous avons récemment constaté de visu l'ampleur des dégâts que les acteurs de la menace peuvent causer en compromettant une instance d'Active Directory.
L'un de nos partenaires de la région EMEA nous a contactés au début du mois de janvier. Une infrastructure critique d'un client du Moyen-Orient avait été compromise. Notre partenaire était en plein déploiement d'un système de détection et de réponse (EDR) lorsqu'il a découvert des logiciels malveillants sur les contrôleurs de domaine du client. Non seulement plusieurs clients et serveurs étaient déjà sous le contrôle des intrus, mais la forêt AD était complètement compromise et contrôlée par les malfaiteurs.
Ils nous ont donc fait venir.
Pour aider la victime à survivre, il a fallu une opération de verrouillage et de récupération coordonnée et bien orchestrée entre le client et Semperis. La première chose que nous avons faite a été de créer un filet de sécurité via notre outil Active Directory Forest Recovery ( ADFR). Nous avons commencé par créer une sauvegarde d'AD du client, découplée de son système d'exploitation. Cela nous a permis d'éviter les mauvaises surprises telles que les rootkits et les portes dérobées intégrées dans le système d'exploitation du client.
À cette fin, nous avons également mis en quarantaine tout ce qui se trouvait dans la politique de groupe, ce qui a permis d'arrêter les tactiques malveillantes qui utilisent l'injection de scripts, comme le ransomware Ryuk. Nous avons également veillé à respecter les directives de Microsoft relatives à la récupération des forêts. Nous avons effectué deux rotations du ticket Kerberos afin de prévenir les attaques de type "Golden Ticket".
Notre filet de sécurité mis en place, nous sommes passés à l'étape de l'analyse, où nous avons cherché à répondre à plusieurs questions fondamentales :
- Comment les acteurs de la menace sont-ils entrés ?
- Comment ont-ils compromis l'AD ?
- Comment ont-ils acquis les références du domaine ?
- Pourraient-ils utiliser des expositions supplémentaires pour retrouver l'accès ?
- Y a-t-il eu des portes dérobées à fermer ?
- Quel était le niveau de sécurité de base du client ?
- Quelles sont les meilleures pratiques mises en place par le client ?
Pendant ce temps, le client - un opérateur d'infrastructures critiques - poursuivait ses activités comme si de rien n'était. Un temps d'arrêt prolongé n'était tout simplement pas envisageable. L'organisation devait continuer à fournir des services à ses propres clients, alors même que nous sondions ses systèmes à la recherche de signes d'acteurs menaçants.
Évaluer la cause première
Nous avons rapidement découvert que le client était attaqué dans plusieurs directions et par plusieurs attaquants, chacun indépendant des autres. Il y avait au moins quatre attaquants, chacun à un stade différent de la chaîne d'exécution. Certains possédaient déjà des comptes de domaine, d'autres tentaient de pulvériser des mots de passe.
Nous étions confrontés à un cauchemar en matière de cybersécurité.
Pour détecter les failles du système, telles que les liens entre les objets de stratégie de groupe (GPO) et les mots de passe réversibles, nous avons utilisé le logiciel Purple Knight. Nous avons également appliqué des scripts supplémentaires, des vérifications manuelles et des solutions en fonction de la situation.
Nous avons trouvé plusieurs comptes d'utilisateurs, y compris des comptes d'administrateurs, avec des SPN définis : des cibles de choix pour le Kerberoasting. Nous avons également constaté que les ordinateurs du domaine n'avaient pas la capacité de définir un certificat dans le système. Enfin, nous avons trouvé un compte d'assistance qui pouvait réinitialiser tous les mots de passe du système, y compris ceux des administrateurs du système.
Récupération d'Active Directory
Nous n'avions jamais été confrontés à un tel scénario. Régler le problème revenait à se faire tirer dessus de toutes parts alors que nous essayions de changer les pneus d'une voiture qui roulait sur l'autoroute à 100 miles à l'heure.
Finalement, nous avons décidé que la meilleure solution était de diviser pour mieux régner. L'équipe EDR a continué à déployer ses EDR sur les serveurs, tout en recherchant et en neutralisant les centres de commande et de contrôle. Nous avons passé une journée et demie à renforcer Active Directory. Nos actions ont consisté à
- Introduction d'un modèle de hiérarchisation (les administrateurs se connectaient à leur courrier électronique sur des postes de travail ordinaires).
- Création de comptes entièrement nouveaux en utilisant le groupe d'utilisateurs MS Protected
- Identifier et supprimer les cibles potentielles de Kerberoasting
- Configuration des autorisations des unités d'organisation (OU) et des adaptations des GPO
La dernière étape a été la plus difficile. Nous devions préserver le cœur du déploiement de cette organisation d'infrastructure critique, ce qui s'apparentait à une transplantation de cœur numérique.
Nous avons attendu le week-end, lorsque le trafic serait réduit au minimum, et nous nous sommes mis au travail pour tout mettre hors ligne.
Trente minutes plus tard, nous avions replanté un système AD propre et renforcé dans le système. ADFR s'est occupé des détails, tels que les pools RID et les tickets Kerberos, tandis que l'équipe EDR s'est occupée de 20 systèmes de commande et de contrôle et a bloqué des centaines d'adresses IP. Un redémarrage rapide plus tard, il ne restait plus qu'un déploiement AD entièrement fonctionnel et sécurisé, activé avec Azure AD Passthrough for Office 365.
Retiré du feu
Active Directory est incroyablement polyvalent, mais il peut aussi représenter une menace considérable pour la sécurité s'il est mal configuré. Notre client l'a appris à ses dépens. Heureusement, il avait mis en place des solutions qui lui ont permis de rectifier le tir, sans interruption de service notable.
Bien que la récupération d'Active Directory dans cette situation ait demandé beaucoup d'efforts à toutes les personnes impliquées, la récompense pour avoir repoussé les attaquants était inestimable. Comme le dit souvent Mickey Bresman, PDG de Semperis, notre mission est d'être une force pour le bien. Notre équipe de préparation et de gestion des violations et incidents (BP&IR) prend cette responsabilité au sérieux, comme nous tous chez Semperis. En ce début d'année, notre résolution est de continuer à aider les organisations du monde entier à repousser les cyberattaques en renforçant leur position ITDR et d'utiliser toutes les ressources disponibles pour vous aider à récupérer Active Directory si le pire devait se produire.
Pour en savoir plus, consultez les ressources suivantes et téléchargez gratuitement notre rapport d'enquête sur l'évaluation de l'ITDR.
En savoir plus
- Mise à jour des plans de reprise après sinistre avec les experts du groupe HIP London
- Comment nous avons récupéré Active Directory de l'enfer des cyberattaques
- Active Directory Forest Recovery Introduction d'un nouvel outil de provisionnement du système d'exploitation
- Active Directory Forest Recovery