ARTICLE ORIGINAL MAG212 CYBER

Attaque par ransomware à 3 h du matin dans un établissement scolaire britannique : identifiants Veeam, domaines frauduleux et suspicion de boucle d’IA

4 novembre 2026 · El Mostafa Ouchen

Bitdefender a publié une reconstitution détaillée d'une intrusion survenue en septembre 2026 dans un établissement scolaire britannique. ransomware 3AM (ThreeAM) Un affilié. Pendant plus de dix jours, l'intrus a dérobé les identifiants stockés sur les serveurs de sauvegarde Veeam de l'établissement, créé deux comptes d'administrateur de domaine dérobés, joint trois domaines Active Directory auparavant distincts avec de nouvelles approbations, volé des données financières et crypté environ 37 machines.

Bitdefender soupçonne également l'attaquant d'avoir utilisé une boucle de commandes automatisée, assistée par une IA. La leçon la plus utile pour les équipes informatiques scolaires et les fournisseurs de services gérés réside dans la manière dont l'intrusion aurait pu être détectée : presque chaque étape était bruyante et répétitive.

Faits clés

Article	Détail
Victime	Un ensemble d'établissements scolaires britanniques comprenant plusieurs domaines Active Directory distincts.
Fenêtre d'intrusion	10-19 septembre 2026 (UTC)
Rapport	Bitdefender, 3 novembre 2026
Chiffreur	ThreeAM, basé sur Rust (host.exe)
Impact	Environ 37 machines cryptées ; sauvegardes de l’état du système supprimées ; données financières exfiltrées
Accès initial	Non établi ; l'attaquant a travaillé à partir d'un hôte non géré

Comment l'intrusion s'est déroulée

Événements sélectionnés de la chronologie de Bitdefender. Le résultat de certaines étapes, comme un dump LSASS et un appel REST Veeam, est inconnu. Diagramme original MAG212 CYBER.

10-11 septembre, identifiants de sauvegarde : Un script PowerShell public modifié a lu les identifiants stockés dans la base de données de configuration Veeam sur trois serveurs de sauvegarde et les a déchiffrés à l'aide de DPAPI. Une base de données de connexion Chrome a été copiée depuis un serveur de terminal.
12-14 septembre, vol d'identifiants et reconnaissance : un téléchargement Mimikatz (renommé plus tard) sysmon64.exe), une tentative d'exclusion de Defender, des sauvegardes de la ruche du registre, une découverte de la confiance de domaine avec nltest, et SYSVOL recherche d'autres écoles.
14-15 septembre, administrateurs de portes dérobées : comptes library et svc_bkpmon Des comptes ont été créés et ajoutés aux administrateurs du domaine. Leurs noms ont été choisis pour s'intégrer à la liste des comptes de l'établissement. Les données financières ont été préparées dans les valeurs du registre et envoyées.
18 sept., domaines de confiance : Des redirecteurs conditionnels DNS et des relations d'approbation bidirectionnelles ont été créés entre trois domaines distincts, puis l'accès a été étendu à une quarantaine de machines.
19 septembre, impact : Des scripts ont tenté de supprimer la protection Sophos et Bitdefender., wbadmin Les sauvegardes de l'état du système ont été supprimées et le chiffreur a fonctionné entre 05:07 et 05:33 UTC.

Comment l'attaquant a lié des domaines distincts. Les étiquettes de domaine sont génériques ; l'appariement de confiance exact est simplifié. Schéma original MAG212 CYBER.

Une fiducie, à elle seule, n'octroie aucune autorisation. C'est pourquoi l'attaquant a ensuite exécuté un script qui a étendu l'accès du compte de porte dérobée à l'ensemble du système.

L'IA était-elle impliquée ?

Bitdefender signale des séquences de tentatives légèrement modifiées, effectuées toutes les 40 à 100 secondes, qui ressemblent à une boucle d'agent automatisée. Cependant, l'outil n'a pas pu accéder à la machine de l'attaquant. Il est donc incapable de définir un modèle, de préciser s'il a été exécuté localement ou d'exclure la possibilité d'une copie humaine des résultats entre outils. Bitdefender présente cette lecture “ hybride ”, combinant intervention humaine et agent, comme un modèle de travail et non comme un fait avéré, et la qualifie de cas isolé, et non de tendance.

Pour les équipes de défense, la conclusion est la même dans les deux cas : les scripts répétitifs et auto-enregistrés laissent des traces importantes. Cette intrusion a réussi car personne n’a été alerté lors de la lecture des identifiants de sauvegarde ni lors de l’apparition de nouvelles approbations de domaine.

Que rechercher dans votre environnement

Journal de sécurité : 4720 (compte créé), 4728 (membre ajouté à un groupe global tel que les administrateurs de domaine), 4706 (nouvelle approbation de domaine), 4698 (tâche planifiée créée). Journal système : 7045 (service installé).
Comportement: reg save de SAM, SECURITY ou SYSTEM par des outils autres que ceux de sauvegarde ; netdom trust ou nltest /domain_trusts; tout processus interrogeant la base de données d'identifiants Veeam.
Artefacts spécifiques à chaque cas : tâches VEEAMPROBE et WindowsTempDiag, clé de registre HKLM\SOFTWARE\VC31, scripts grant_lib.ps1 et av_remove*.ps1. Bitdefender publie l'ensemble des indicateurs de compromission (IOC) sur GitHub. Attendez-vous à des noms différents lors d'autres intrusions ; recherchez le comportement en question.

Vérifications en lecture seule (PowerShell 5.1+ avec le module RSAT ActiveDirectory ; exécutez les requêtes d’événements et de tâches avec des privilèges élevés, sur chaque contrôleur de domaine ou serveur) :

Get-ADTrust -Filter * -Properties whenCreated | Select-Object Name,Direction,whenCreated
Get-ADGroupMember 'Domain Admins' -Recursive | Select-Object SamAccountName
$since = (Get-Date).AddDays(-60)
Get-ADUser -Filter 'whenCreated -ge $since' -Properties whenCreated |
  Select-Object SamAccountName,whenCreated
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4706,4720,4728} -MaxEvents 200
Get-ScheduledTask -TaskName 'VEEAMPROBE','WindowsTempDiag' -ErrorAction SilentlyContinue

Signalez toute confiance dont vous ne pouvez pas justifier l'utilisation, ainsi que tout administrateur ajouté en dehors du contrôle des modifications. Ces commandes ont été vérifiées par rapport à la documentation Microsoft, mais n'ont pas été exécutées sur des systèmes en production pour cet article.

Contenir, récupérer et prévenir

Isoler les serveurs de sauvegarde et faites une rotation systématique de toutes les informations d'identification stockées par le produit de sauvegarde. Considérez-les comme compromises si elles ont pu être lues.
Désactiver les comptes d'administrateur inconnus Supprimez les approbations non autorisées. Si la compromission du domaine est confirmée, réinitialisez le compte krbtgt à deux reprises, en suivant les instructions de Microsoft.
Restaurer uniquement à partir de copies immuables ou hors ligne, et seulement après que l'environnement soit propre.
Éviter les répétitions : Limitez le périmètre des comptes de sauvegarde à un domaine spécifique, isolez les serveurs de sauvegarde des réseaux d'administration généraux, soumettez les approbations et les modifications d'administrateur de domaine à un contrôle des changements et déployez un agent de point de terminaison sur chaque machine. Bitdefender recommande notamment de configurer des alertes en cas d'accès aux informations d'identification de sauvegarde et de nouvelles approbations.

Foire aux questions

Comment les assaillants sont-ils entrés ?

Bitdefender n'a pas pu établir l'accès initial. L'attaquant opérait depuis un serveur non géré par l'établissement scolaire, hors de la visibilité de Bitdefender.

Pourquoi cibler en premier les serveurs Veeam ?

Les produits de sauvegarde stockent souvent des identifiants privilégiés pour les systèmes qu'ils protègent. Leur lecture a permis à l'attaquant d'accéder rapidement à un large système, et le contrôle des sauvegardes compromet la restauration.

Les ransomwares pilotés par l'IA sont-ils désormais courants ?

D'après ces éléments, non. Bitdefender considère cela comme un cas isolé et indique que ce type de “ vibeware ” représente environ 0,071 TP3T des échantillons qu'elle collecte mensuellement.

Lire le numéro complet du MAG212 CYBER Daily d'aujourd'hui (gratuit) →

Abonnez-vous gratuitement