Détecter et contrer en 5 minutes la « nouvelle » technique de vol d’informations d’accès du groupe TA577

Lorsque l’on reçoit une réponse à un de nos messages avec l’historique des échanges précédents, cela à tendance à nous mettre en confiance, forcément, et notre attention risque de ne pas se porter sur l’adresse expéditrice. D’accord, le RSSI averti va trouver suspect de recevoir une pièce jointe avec un fichier JavaScript dans un zip ou un lien de téléchargement vers un Wordpress vulnérable au Chili. Mais Micheline de la compta, avec 3 messages de sa part dans l’historique de la conversation, risque de se faire piéger.

Dans un récent article publié par les équipes de Proofpoint, une « nouvelle » (en tout cas, pas encore vue de la part de ce groupe) méthode de vol d’informations de connexion est mise en avant. Observée dans deux importantes campagnes de courriels diffusés fin février, les attaquants ont remplacé les fichiers JavaScript, Excel, Word ou encore OneNote couramment utilisés pour le téléchargement d’une cochonnerie permettant aux attaquants d’obtenir un pied dans le système des machines victimes et par conséquent un point d’entrée dans le SI, par… un fichier HTML (dans un zip) ! D’après Proofpoint, les messages sont ciblés pour chaque victime, les fichiers HTML personnalisés, bref, c’est propre et efficace, comme ils savent bien le faire.

Vous allez me dire, pourquoi des fichiers HTML ? En général, comme les antivirus, on a tendance à tors, à baisser la garde en voyant arriver ce type de fichiers. On se dit, une page Web statique, ça ne représente pas un grand danger. Au pire des cas, il pourrait s’agir d’un formulaire imitant une page d’authentification au Webmail. Si l’utilisateur ne saisit pas son identifiant et son mot de passe, il n’y pas un grand-chose à craindre. Furtivité, discrétion et efficacité sont les maîtres mots de ces attaquants dont le but est de revendre, notamment à des acteurs du milieu du rançongiciel, des accès aux SI de leurs victimes.

L’idée ici est tout simplement d’utiliser une balise meta de type refresh pointant vers un serveur SMB exposé sur Internet, pour capturer le nom d’utilisateur, le domaine Active Directory et le condensat au format Net-NTLMv2 de l’utilisateur. Pourquoi s’embêter la vie et risquer de se faire détecter avec la technique du « Template Injection » dans un document Office [3] alors qu’il est possible d’obtenir le même résultat avec un simple fichier HTML bien plus discret ?

Tentons de voir comment ça fonctionne réellement en quelques minutes, en reproduisant l’attaque avec une page HTML publiée sur un serveur Web (oui ça fonctionne aussi sur une page Web en ligne et les utilisateurs n’y verront que du feu, malheureusement…) 

Étape 1 :

On insert la balise meta que l’on fait pointer vers notre serveur SMB malveillant dans la page :

Étape 2 :

On démarre un Repsonder [4] sur notre serveur exposé sur Internet écoutant sur le port 445 et avec le protocole SMB d’activé. Et on attend patiemment que notre victime consulte la page...

Étape 3 :

La victime ouvre la page dans son navigateur Microsoft implémentant par défaut l’authentification NTLM :

Rien de suspect pour la victime à première vue, mais le navigateur tente de s’authentifier sur le serveur Responder et donne gentiment les informations de connexion de l’utilisateur connecté sur la machine Windows au serveur Responder :

Après cela, l’attaquant n’a plus qu’à tenter de casser le mot de passe pour accéder à la messagerie de la victime ou à son VPN SSL donnant accès au SI de la structure.

Pourquoi cette technique ne semble pas « si nouvelle » que ça ? Parce qu’on peut observer une recrudescence des serveurs Responder exposés sur Internet depuis plusieurs mois, comme le montre le service Threat Fox d’Abuse.CH [5] :

Comment détecter facilement une attaque de ce type ? Parmi les règles de détection réseau pour Suricata [6] que je propose au sein du projet PAW Patrules [7], deux règles permettront rapidement de mettre la puce à l’oreille des défenseurs. La première met en évidence une réponse à un challenge NTLMSSP depuis un serveur exposé sur Internet, ce qui semble assez suspect. La seconde permet d’identifier une réponse émise par Responder. Pour faire court, si ça sonne chez vous, ça veut dire qu’il y a des configurations à revoir et des mots de passe à faire réinitialiser rapidement.

Comment éviter tout simplement de se faire dérober les informations de connexion de ses utilisateurs avec cette technique ? Il suffit de mettre en œuvre une stratégie de groupe (GPO) pour l’ensemble des machines de son parc, interdisant l’authentification NTLM à des serveurs externes au SI :

Vous pouvez également veiller à ce qu’aucune règle de filtrage sur vos pares-feux ne permette une sortie sur Internet via le protocole SMB (peu importe le port utilisé).
La mise en place d’une authentification à plusieurs facteurs sera la bienvenue également, pour les accès depuis Internet en priorité.

Vous avez les cartes en main, à vous de jouer !

[1] https://malpedia.caad.fkie.fraunhofer.de/actor/ta577 

[2] https://www.proofpoint.com/us/blog/threat-insight/ta577s-unusual-attack-chain-leads-ntlm-data-theft 

[3] https://attack.mitre.org/techniques/T1221/ 

[4] https://github.com/lgandx/Responder-Windows 

[5] https://threatfox.abuse.ch/browse/malware/py.responder/ 

[6] https://suricata.io/ 

[7] https://pawpatrules.fr/ 

L'auteur

Chef de projet sécurité numérique en santé - GCS e-santé Pays de la Loire Charles Blanc-Rolin est également vice-président de l’APSSIS (Association pour la promotion de la Sécurité des Systèmes d'Information de Santé)