Archives par mot-clé : infy

Infy : Prince of Persia persiste et signe

En février 2017, l’Unit42, unité de recherches de Palo Alto Networks a observé une évolution du malware “Infy” que nous avons appelée « Foudre ». Les acteurs concernés semblent avoir tiré les enseignements suite à notre démantèlement et notre sinkholing (redirection vers un serveur que nous contrôlons) de leur infrastructure de commande et de contrôle (C2). En effet, Foudre intègre désormais de nouvelles techniques anti-démantèlement censées éviter que ses domaines C2 ne soient détournés vers un site sinkhole comme nous l’avions fait en 2016.

L’Unit42 a documenté ses travaux de recherche originels sur cette campagne vieille de dix ans en utilisant le malware Infy en mai 2016. Un mois après la publication de ces travaux, l’Unit42 a donné une description détaillée de notre démantèlement et de notre sinkholing des serveurs C2 de l’acteur. En juillet 2016, au congrès Blackhat U.S.A, Claudio Guarnieri et Collin Anderson ont présenté des preuves montrant qu’un sous-ensemble des domaines C2 redirigés vers notre sinkhole avaient été bloqués par falsification DNS et filtrage HTTP par la Telecommunication Company of Iran (AS12880), empêchant l’accès depuis le territoire national iranien à notre sinkhole.

Voici les modifications apportées au malware dans ce blog post dédié, quelques informations et précisions ci-dessous. L’Unit42 en profite également pour mettre en avant certaines erreurs courantes, et explique comment elle les a exploitées pour en savoir plus sur cette campagne.
Cartographie des victimes

L’Unit42 avait prévu l’un des noms de domaine DGA et l’avait enregistré avant que l’adversaire ne puisse le faire.

Les victimes ont tenté de se connecter à un C2 dans ce domaine, mais, ne possédant pas la clé privée RSA, l’Unit42 n’a pas pu vérifier son domaine auprès d’elles. Cependant, elle a pu établir une cartographie géolocalisant les victimes à l’aide de GeoIP (voir pièce jointe).

On remarque la prépondérance des victimes sur le territoire national iranien, ce qui rappelle fortement les campagnes d’Infy. Les attaques menées contre les États-Unis et l’Irak sont aussi familières. Ici encore, le très petit nombre de cibles fait penser à une motivation non financière.

L’une des victimes en Irak utilise une adresse IP dans le même réseau de classe C que l’une des victimes Infy déjà observées, ce qui laisse à penser que l’adversaire cible la même organisation, voire le même ordinateur.

Même si, en l’absence de la clé privée RSA, l’Unit42 n’a pas réussi à établir la communication avec les victimes, elle a découvert qu’en envoyant un fichier de signature non valide à la victime, du fait de l’absence de validation en entrée du contenu/de la taille de ce fichier, elle arrive à faire échouer le processus rundll32 qui exécute la DLL malveillante de Foudre. Cela permet de désactiver l’infection jusqu’à ce que la victime réinitialise sa machine.
Conclusion

Dans son post, blog Prince of Persia, l’Unit42 avait indiqué que cette campagne durait depuis au moins une dizaine d’années. Ainsi, elle a poursuivi le sujet avec son blog Prince of Persia: Game Over, qui documente son démantèlement et son sinkholing de l’infrastructure C2 de l’adversaire.

En ce qui concerne les actions de la Telecommunication Company of Iran en vue d’empêcher les C2 d’être redirigés vers notre sinkhole, Guarnieri et Anderson font observer que « la politique de filtrage indique que les autorités iraniennes sont intervenues spécialement pour bloquer l’accès aux domaines de commande et de contrôle d’une campagne d’intrusion visant l’État, au niveau national. »

L’Unit42 s’attend à voir Infy faire son retour : dans les grandes lignes, ce sera toujours le même malware, ciblant les mêmes victimes.

Les acteurs ont compris qu’ils avaient besoin d’une infrastructure C2 plus robuste pour empêcher l’infiltration et le démantèlement. L’algorithme DGA apporte une dose de résilience, mais n’est pas invulnérable à un démantèlement.

Toutefois, l’utilisation de la signature numérique constitue un dispositif de défense contre un C2. Sans accès aux clés privées, il n’est pas possible d’usurper l’identité d’un C2 même si un domaine DGA est enregistré par un chercheur. Il se peut que les clés privées résident localement sur le serveur C2, mais sans accès au C2, nous ne pouvons pas confirmer cette vulnérabilité potentielle de leur infrastructure.

Décidément, Prince of Persia persiste et signe.