Un VPN sans double authentification a suffi à Akira pour entrer, le mode sans échec pour désarmer la protection

Huntress, société de détection et réponse aux incidents, a publié le 12 août le déroulé d'une attaque du rançongiciel Akira observée le 4 août. BleepingComputer et SiliconANGLE en ont confirmé les détails le lendemain. L'intérêt n'est pas la nouveauté du groupe Akira, actif depuis plusieurs années, mais la manière dont l'attaque s'est déroulée : ni faille logicielle à l'entrée, ni contournement sophistiqué de l'antivirus à la sortie. Un mot de passe, et une fonction Windows présente sur tous les postes.

L'entrée : un mot de passe, pas de second facteur

À 3h45 UTC, le pare-feu SonicWall de la victime a enregistré une rafale d'échecs de connexion depuis plusieurs adresses IP externes, signe d'une attaque par dictionnaire de mots de passe. Sept minutes plus tard, à 3h52, un compte valide s'est connecté avec succès au VPN SSL. Selon Huntress, ce VPN n'était pas protégé par une double authentification.

C'est le point à retenir avant tout le reste : aucune vulnérabilité n'a été exploitée. Un mot de passe deviné ou réutilisé a suffi, parce que rien d'autre ne venait le vérifier.

La suite : le mode sans échec comme interrupteur général

Une fois dans le réseau, l'attaquant a forcé le redémarrage d'un poste en mode sans échec avec prise en charge réseau, via msconfig.exe. Le mode sans échec ne charge que les pilotes et services jugés essentiels par Windows : la plupart des logiciels tiers, y compris les outils de sécurité, restent éteints. L'agent Huntress et la protection en temps réel de Microsoft Defender se sont arrêtés du même coup. L'attaquant en a profité pour ajouter AnyDesk, un outil d'accès à distance légitime, à la liste des programmes autorisés à démarrer en mode sans échec, s'assurant un accès qui survit même après un retour au mode normal.

Huntress qualifie cet épisode de première observation, dans ses propres données, d'un affilié Akira utilisant cette méthode pour neutraliser une détection.

Le raté : le chiffrement a planté

Le mode sans échec limite aussi la mémoire disponible. Quand l'attaquant a tenté de lancer l'exécutable de chiffrement, Windows a renvoyé des erreurs de mémoire virtuelle insuffisante et le chiffrement a échoué. Une analyse planifiée de Defender a ensuite détecté et mis en quarantaine l'exécutable une fois la machine repassée en mode normal.

Il s'agit d'un incident technique côté attaquant, pas d'un mécanisme de défense côté victime, et il serait imprudent d'en tirer une garantie pour la prochaine attaque. Huntress précise que l'ensemble de l'attaque, de l'accès initial à l'échec du chiffrement, a duré moins de cinq heures, dont une fenêtre d'environ dix minutes où ni l'antivirus ni l'agent de détection n'étaient actifs. Le vol de données, lui, a réussi : l'attaquant est reparti avec des identifiants et des fichiers, utilisés pour une extorsion basée sur la menace de publication plutôt que sur le chiffrement.

Ce qu'il faut vérifier aujourd'hui

1. Le VPN de l'entreprise, quel qu'en soit l'éditeur, doit exiger une double authentification pour toute connexion. C'est la première chose à activer si elle manque encore.
2. Un compte qui échoue plusieurs dizaines de fois à se connecter en quelques minutes doit déclencher un blocage temporaire ou une alerte, pas seulement un journal que personne ne consulte.
3. Si l'entreprise dispose d'un antivirus ou d'un agent de détection géré par un prestataire, demandez-lui explicitement comment ces outils se comportent en cas de redémarrage en mode sans échec : c'est une question que peu de contrats couvrent par défaut.
4. AnyDesk et les autres outils d'accès à distance légitimes sont utiles à un prestataire IT autant qu'à un attaquant qui a pris pied sur le réseau. Une liste des outils d'accès distant autorisés, connue du prestataire, aide à repérer un ajout qui ne devrait pas être là.