Archives par mot-clé : logiciel espion

APT, Argent, backdoor, Banque, Base de données, Cybersécurité, Entreprise, Fuite de données, ID, Particuliers, Securite informatique, Téléphonie

Anubis : cheval de Troie bancaire décortiqué

Anubis 2 est apparu dans le « paysage des menaces » en 2017 en tant que cheval de Troie bancaire en location (disponible pour les fraudeurs dans des forums undergrounds), l’auteur et créateur du malware se surnomme « maza-in ». Si ce dernier a disparu des radars, son outil malveillant est toujours en action.

En tant que malware bancaire, Anubis incite ses victimes à fournir des informations personnelles et sensibles, telles que les logins bancaires, des codes de sécurité bancaire et même des informations de carte de crédit. Mais ce logiciel malveillant va au-delà des attaques « overlay » bien connues, utilisées par les chevaux de Troie bancaires, car il combine des fonctionnalités avancées telles que le streaming d’écran du téléphoné infecté, l’accès à tous les fichiers à distance, l’enregistrement sonore, le key-logging et même un proxy réseau, ce qui en fait un malware bancaire efficace, mais également un potentiel outil pour espionnage.

D’un point de vue opérationnel, Anubis peut être considéré comme l’un des chevaux de Troie bancaires Android les plus utilisés depuis fin 2017. En ce qui concerne les banques Françaises, les suivantes sont ciblées : Axa, Banque Populaire, BNP Paribas, Boursorama, Caisse d’Épargne, Crédit Agricole, Crédit Mutuel, LCL, Palatine ou encore la Société Générale.

L’auteur a disparu, par son code malveillant

Au cours du premier trimestre 2019, l’auteur et créateur du cheval de Troie a disparu, laissant les clients existants sans assistance ni mises à jour; mais le risque demeure et pourrait même augmenter. Les campagnes d’infection d’Anubis comptent parmi les plus importantes jamais enregistrées pour les malwares bancaires : De nombreuses victimes ne sont pas conscientes du fait que le malware ne se déguise pas comme l’app de la banque, il se déguise principalement en tant qu’application tierce et reste inaperçu par les usagers. Anubis se fait par exemple passer pour : de faux jeux mobiles, de fausses mises à jour de logiciels, de fausses applications postales, de fausses applications Flash Player, de fausses applications utilitaires, de faux navigateurs et même de fausses applications de réseau social et de communication.

Les caractéristiques du cheval de Troie en font une menace importante : Habituellement, les chevaux de Troie bancaires effectuent principalement des attaques de type « overlay » afin de collecter les informations personnelles puis volent les SMS pour acquérir les codes bancaires, mais Anubis va plus loin que ça avec la streaming de l’écran du téléphone infecté, l’accès de fichiers à distance (accès au stockage du téléphone), l’enregistrement sonore, le key-loggign et même un proxy réseau (permettant au criminel de se connecter à la banque via le téléphone infecté).

300 banques dans le monde ciblées

Les campagnes d’infection d’Anubis ciblent en moyenne, plus de 300 banques dans le monde: La liste observée dans les campagnes Anubis contient environ 360 cibles, contenant la plupart des banques les plus grandes et les plus connues dans le monde, mais également des applications de communication et de réseautage social largement utilisées, ce qui signifie que personne n’est vraiment protégée, car même si une victime ne fait pas de banque en ligne le malware abusera d’autres applications (Liste complète de cibles en Annexe du blog).

Les malware qui deviennent orphelins ne sont pas toujours un bon signe : Beaucoup de gens pourraient penser que lorsque le propriétaire / auteur du malware disparaît, les opérations s’arrêtent… Malheureusement, ce n’est pas toujours le cas, surtout pas avec Anubis. Bien que l’acteur ait disparu, le cheval de Troie est toujours actif et le pire est que son code a été divulgué/fuit, ce qui pourrait amener de nombreux autres criminels à utiliser le programme malveillant. Toute l’analyse complète à découvrir sur Threat fabric.

APT, backdoor, Communiqué de presse, Cyber-attaque, Cybersécurité, Leak, Mise à jour, Piratage, Securite informatique

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.