Piratage : « ConsentFix » la nouvelle évolution de « ClickFix »

La technique de piratage dite « ClickFix » a une nouvelle variante. Pour mémoire, cette technique d’ingénierie sociale consiste à berner un internaute pour lui faire exécuter une ligne de commande malveillante. Aucun système d’exploitation n’est à l’abri d’une méthode d’infection redoutablement efficace.

Push Security vient de documenter la variante. Là encore, il s’agit d’amener l’utiliser à copier-coller une ligne de commande dont l’exécution déclenchera la compromission.

La technique a été baptisée « ConsentFix » : « vous pouvez la considérer comme une attaque ClickFix native du navigateur qui hameçonne un jeton OAuth sur une application cible en amenant la victime à copier-coller une URL contenant des éléments de clé OAuth dans une page de phishing », résume le vice-président de Push Security en charge de la R&D, Luke Jennings, dans un billet de blog. 

Et de développer : « la campagne que nous avons détectée semble cibler spécifiquement les comptes Microsoft en exploitant l'application Azure CLI OAuth. Concrètement, l'attaquant incite la victime à se connecter à Azure CLI en générant un code d'autorisation OAuth (visible dans une URL localhost), puis en collant cette URL (y compris le code) dans une page contrôlée par l'attaquant. Cela crée alors une connexion OAuth entre le compte Microsoft de la victime et l'instance Azure CLI de l'attaquant ». Simple et efficace, mais redoutable.

Tout part d’une « page Web malveillante ou compromise » découverte via Google Search : « la grande majorité des sites que nous avons identifiés comme étant associés à cette campagne sont des sites Web légitimes, mais compromis, bénéficiant d'une excellente réputation de domaine et facilement accessibles via les moteurs de recherche », explique Luke Jennings.

Là, « l'attaquant avait injecté un faux Cloudflare Turnstile dans les sites Web compromis, exigeant la fourniture d'une adresse e-mail pour pouvoir continuer ». 

Subtilité : « cela fonctionnait comme une forme de chargement conditionnel qui ne se poursuivait que si une adresse e-mail et un domaine valides étaient fournis, afin d'empêcher la page d'être analysée par des robots de sécurité, des analystes et des comptes de faible valeur qui risquaient d'exposer la campagne avant que le ou les destinataires visés puissent être hameçonnés ».

Car c’est cette étape passée que le piège se referme. Un bouton se connecté est présenté : « il ouvre un nouvel onglet qui charge une URL Microsoft légitime associée au compte utilisateur/à l'adresse e-mail utilisé(e) pour accéder à la page. Si l'utilisateur est déjà connecté à Microsoft dans son navigateur, il lui suffit de sélectionner son compte dans le menu déroulant. Sinon, il devra se connecter via l'URL de connexion Microsoft légitime ».

À ce stade, tout va bien ou presque : « une fois connecté à Microsoft ou après avoir sélectionné son compte dans le menu déroulant, l'utilisateur est redirigé vers localhost [son propre ordinateur, N.D.L.R.], qui génère une URL contenant un code associé au compte Microsoft de l'utilisateur. Pour mener à bien l'hameçonnage, la victime copie l'URL et la colle sur la page d'origine ». 

Là, la partie est finie : « une fois ces étapes terminées, la victime a accordé à l'attaquant l'accès à son compte Microsoft via Azure CLI ». 

Ainsi, « l'attaquant contrôle effectivement le compte Microsoft de la victime, sans avoir jamais eu besoin de pirater un mot de passe ou de passer un contrôle MFA. En fait, si l'utilisateur était déjà connecté à son compte Microsoft (c'est-à-dire s'il avait une session active), aucune connexion n'est nécessaire ». En somme, c’est transparent pour l’utilisateur. Mais son employeur, la suite risque de l’être bien moins.