Les attaques de ransomware contre les entreprises sont de plus en plus fréquentes et complexes. De nombreux acteurs du secteur de la sécurité pensent que WannaCry et NotPetya n'étaient qu'un échantillon de ce qui nous attend. De plus en plus, Active Directory (AD) est au centre des cyberattaques, avec des wipers comme MBR-ONI qui utilisent AD pour maximiser la portée de l'attaque et, dans certains cas, des wipers comme NotPetya qui détruisent complètement AD. Cette série de blogs explore des histoires réelles d'attaques de wiper, leur impact sur AD et ce que vous pouvez faire pour que votre organisation soit mieux préparée à la prochaine vague d'attaques.
Faire face à un virus Wiper : Quand NotPetya attaque
Près d'un an s'est écoulé depuis le déclenchement de l'attaque wiper NotPetya et, au cours de cette période, j'ai eu plusieurs conversations avec des analystes système dont les organisations ont été touchées par le malware wiper. Semperis étant une société de protection des services d'annuaire, la plupart de mes conversations portent sur les services d'annuaire et sur l'impact des attaques dans le contexte d'AD. Dans chaque conversation que j'ai eue, nous avons parlé de ce qui s'est passé et de l'impact sur l'organisation d'un point de vue post-mortem. Nous avons ensuite discuté de ce qui a été fait pour atténuer l'impact de l'attaque et des leçons apprises. J'ai donc pensé qu'il pourrait être bénéfique pour d'autres d'entendre certaines de ces histoires afin d'être mieux préparés pour de futures attaques.
La première histoire que je souhaite partager à propos de NotPetya est celle d'un grand fabricant d'Europe occidentale, comptant environ 10 000 employés, dont l'ensemble de l'Active Directory a été chiffré à la suite de NotPetya. Ce qui est étonnant dans cette histoire, c'est qu'à partir du moment où le wiper a commencé à se propager, il lui a fallu moins de 10 minutes pour chiffrer tous les contrôleurs de domaine (DC) et les serveurs de fichiers (FS) de l'entreprise, le chiffrement se propageant globalement à tous les sites distants.
Malheureusement, les serveurs de sauvegarde et de récupération étaient également cryptés et ont dû être reconstruits à partir de zéro. L'attaque a complètement paralysé l'organisation et, après avoir examiné l'évaluation initiale des dommages, les équipes informatiques ont réalisé que cette attaque ne ressemblait à rien de ce qu'elles avaient vu auparavant.
Le processus de restauration qui a suivi l'attaque a été long et complexe. L'équipe a d'abord dû prendre quelques décisions cruciales :
- Qu'est-ce qui doit être restauré en premier ?
Il s'agissait notamment de dresser la carte des applications essentielles à l'entreprise et des composants d'infrastructure nécessaires sur lesquels elles s'appuient. - Pour chaque site, quel est le nombre minimum de DC à restaurer ?
En outre, une attention particulière a dû être accordée à la restauration des serveurs situés dans des endroits à faible bande passante.
La première étape du processus de récupération a consisté à reconstruire les serveurs de sauvegarde et de récupération, puis à restaurer les autres serveurs à partir de bandes, un processus qui a duré plusieurs jours avec l'aide des ingénieurs de Microsoft sur place.
La restauration des DC cryptés était un processus fastidieux qui devait être exécuté à partir de zéro. L'équipe informatique a commencé par créer une nouvelle machine virtuelle avec un système d'exploitation propre, en installant l'agent de restauration, en effectuant une restauration de l'état du système, en nettoyant le contrôleur d'interface réseau virtuel (NIC) et en résolvant d'autres problèmes liés aux pilotes après la restauration de l'état du système.
Bien que l'équipe ait suivi les protocoles de restauration appropriés, la restauration initiale d'Active Directory a échoué en raison d'un problème de retour en arrière du numéro de séquence de mise à jour (USN) qui a empêché AD de se répliquer. Le problème des retours en arrière USN est qu'ils sont très difficiles à identifier et qu'il peut y en avoir des milliers, sans qu'aucune erreur ne soit consignée nulle part.
S'attendre à l'inattendu dans le processus de rétablissement
Ce qu'il faut retenir de cette histoire, c'est que la récupération d'un environnement crypté est un processus incroyablement complexe, avec de nombreux éléments mobiles à prendre en compte.
Même lorsque vous pensez être vraiment préparé, il est difficile de prévoir certains des problèmes que vous pourriez rencontrer lors de la restauration. Voici quelques moyens de mieux protéger votre organisation contre les effets d'un virus wiper :
- Toujours se préparer au pire scénario - Même si cela semble peu probable, vous devez vous préparer à une situation où tous vos serveurs, y compris les serveurs de sauvegarde/récupération, ont disparu. Mettez en place une procédure dans laquelle la récupération des serveurs de sauvegarde/récupération est la première étape.
- Cartographier les applications critiques et les dépendances de leur infrastructure - Il est très probable que vos applications métier reposent sur Active Directory, mais il est important de savoir quels autres composants doivent être restaurés pour que l'application puisse fonctionner.
- Assurez-vous de disposer d'un plan éprouvé pour restaurer votre Active Directory - Disposer d'une sauvegarde est une excellente première étape, mais vous devez être conscient que la restauration n'est pas un processus simple et que les choses peuvent se compliquer très rapidement. Microsoft propose un service de préparation à la restauration de l'Active Directory, appelé ADRES, qui peut vous aider à vous préparer à une situation désastreuse avec votre Active Directory.
La récupération de NotPetya : un jeu d'enfant
Bien qu'il soit essentiel de prendre certaines mesures pour protéger votre infrastructure contre les attaques de wiper, la mise en place d'un solide plan de reprise après sinistre est le seul moyen de minimiser réellement la complexité du processus de reprise. La solution Active Directory Forest Recovery (ADFR) de Semperis automatise entièrement l'orchestration du processus de reprise après sinistre d'Active Directory et réduit considérablement le temps de restauration. En exploitant l'intelligence interne, ADFR est capable de prendre des décisions qui résolvent une variété de problèmes qui peuvent survenir au cours du processus de récupération AD DR (par exemple, l'utilisation de points de distribution pour surmonter le problème de la faible bande passante du réseau). Pour plus d'informations sur la reprise après sinistre d'Active Directory, vous pouvez consulter notre webinaire sur l'automatisation de la reprise après sinistre d'AD et notre webinaire sur les considérations relatives à la sauvegarde d'AD.
Restez à l'écoute pour le prochain blog de la série, où je parlerai un peu plus du virus ONI et de ses effets sur Active Directory.
