Archives par mot-clé : logiciel espion

Android, APT, backdoor, Cybersécurité, Espionnage Spy, Smartphone

Google renforce l’enquête anti-espionnage sur Android

Google déploie sur Android un journal d’intrusion pensé pour documenter les attaques, préserver les traces et aider les enquêtes cyber sur smartphones compromis.

Le nouveau dispositif de journalisation intégré à Android vise un enjeu longtemps critique : comprendre précisément comment un téléphone a été ciblé, compromis ou fouillé. Intégré au mode de protection avancée, il s’adresse d’abord aux profils exposés, notamment journalistes, militants, défenseurs des droits humains et autres utilisateurs à risque. Les journaux collectent des événements techniques pouvant signaler une intrusion, puis les protègent par chiffrement avant transfert vers le compte Google de l’utilisateur. L’objectif est clair : empêcher qu’un logiciel espion efface simplement les indices locaux et donner aux chercheurs une base exploitable pour reconstituer une attaque.

Android veut garder la mémoire des attaques

Sur un smartphone, l’attaque ne se résume pas toujours à un écran suspect ou à une application inconnue. Elle peut passer par une connexion distante, une extraction discrète, une manipulation de débogage ou l’ouverture d’un serveur malveillant. Jusqu’ici, sur Android, beaucoup de ces signaux disparaissaient vite. Les journaux système n’étaient pas pensés pour une investigation d’intrusion, ils étaient régulièrement écrasés, et ne conservaient pas toujours les éléments nécessaires à une analyse solide.

Google introduit donc une fonction dédiée à cette zone grise de l’enquête mobile. La journalisation des intrusions collecte un ensemble séparé d’événements capables d’indiquer une compromission, une tentative de piratage ou une opération de dissimulation. Elle est intégrée au mode de protection avancée, conçu pour les utilisateurs dont le métier, l’engagement ou l’exposition publique augmente le risque de surveillance ciblée.

Le mécanisme repose sur une logique simple : conserver des traces utiles avant qu’elles ne disparaissent. Une fois par jour, Android rassemble ces journaux, les chiffre, puis les envoie vers le compte Google associé au téléphone. Selon Google, l’entreprise ne peut pas lire leur contenu. Le déchiffrement reste entre les mains de l’utilisateur, qui peut ensuite choisir de les transmettre à des chercheurs chargés d’examiner une attaque possible.

Cette architecture répond à un problème central du renseignement numérique : lorsqu’un logiciel espion a déjà pris pied sur un appareil, les preuves locales deviennent fragiles. Un outil suffisamment avancé peut tenter d’effacer ses traces, de masquer ses communications ou de supprimer les éléments compromettants. En déplaçant régulièrement des journaux chiffrés hors du téléphone, Google cherche à réduire cette capacité d’effacement.

La fonction a été développée avec l’aide d’Amnesty International. L’organisation a souligné une difficulté récurrente dans les enquêtes sur Android : l’analyse d’un appareil était souvent plus complexe que celle d’un iPhone, précisément parce que les traces disponibles étaient moins adaptées aux investigations sur intrusion. Pour des chercheurs, cette différence peut déterminer la qualité d’un diagnostic. Sans chronologie fiable, il devient difficile d’identifier le vecteur d’attaque, la période de compromission et les actions réalisées sur le terminal.

Les nouveaux journaux enregistrent plusieurs catégories d’actions. Ils peuvent conserver les déverrouillages du téléphone, les installations et suppressions d’applications, les connexions à des sites web ou serveurs, l’usage d’Android Debug Bridge, ainsi que les tentatives de suppression des journaux eux-mêmes. Ce dernier point est particulièrement sensible : vouloir effacer ces données peut constituer un indice d’obstruction ou de camouflage après compromission.

Pour les enquêteurs, la valeur de ces informations tient à leur combinaison. Un événement isolé peut sembler banal. Une séquence, elle, peut raconter une attaque. Un déverrouillage inhabituel, suivi d’une connexion à un serveur suspect, d’une installation d’application et d’un accès via Android Debug Bridge, forme une piste beaucoup plus solide qu’un simple soupçon.

Un outil utile, mais encore encadré

Cette journalisation peut aussi aider à documenter des scénarios très concrets. Les données recueillies peuvent montrer si le smartphone a été relié à un outil d’extraction comme Cellebrite. Elles peuvent également révéler des tentatives de récupération de données, la présence d’un logiciel espion, l’installation d’un logiciel de harcèlement ou l’ouverture de domaines et serveurs utilisés dans une opération malveillante.

L’enjeu dépasse donc la réparation technique. Il touche à la preuve. Pour un journaliste, un défenseur des droits humains ou un militant, démontrer qu’un téléphone a été attaqué peut avoir des conséquences professionnelles, judiciaires et politiques. Dans ces dossiers, l’incertitude profite souvent à l’attaquant. Plus la chronologie est précise, plus l’analyse devient exploitable.

La fonctionnalité n’est toutefois pas automatique. L’utilisateur doit activer manuellement le mode de protection avancée, puis la journalisation des intrusions. Ce choix limite l’exposition involontaire, mais réduit aussi la couverture immédiate. Les personnes les plus ciblées devront connaître l’existence du dispositif, comprendre son intérêt et accepter de l’utiliser avant un incident.

Autre restriction importante : le déploiement concerne actuellement les appareils Pixel disposant de la mise à jour Android 16 de décembre ou ultérieure. Le téléphone doit aussi être associé à un compte Google. Dans l’état actuel, le dispositif ne couvre donc pas l’ensemble de l’écosystème Android, très fragmenté selon les fabricants, les modèles et les calendriers de mise à jour.

La question de la confidentialité demeure centrale. Ces journaux peuvent contenir l’historique de connexions et des éléments liés à l’activité de navigation. Même chiffrés, ils restent sensibles dès lors qu’un utilisateur envisage de les partager avec des chercheurs. Le choix final lui appartient : transmettre ces données peut aider à établir une attaque, mais cela implique aussi d’exposer une partie de son activité numérique à une analyse externe.

Google tente ici un équilibre délicat. Trop peu de traces, et l’enquête échoue. Trop de collecte, et l’outil devient lui-même une source d’inquiétude. Le chiffrement et le contrôle donné à l’utilisateur répondent à cette tension, sans l’effacer totalement. Dans les affaires d’espionnage mobile, la confiance ne repose pas seulement sur la technologie, mais aussi sur la clarté du consentement.

Pour Android, cette évolution marque un changement d’approche. La sécurité ne consiste plus seulement à bloquer l’attaque au moment où elle survient. Elle doit aussi permettre d’en comprendre les mécanismes après coup. Cette capacité d’analyse post-incident est essentielle face aux logiciels espions, aux outils forensiques intrusifs et aux opérations ciblées.

En matière de cyber-renseignement, la bataille se joue désormais autant dans la conservation des traces que dans la détection de l’attaque.

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.