Cet article a été réalisé en collaboration avec Bitdefender

La sécurité de vos données personnelles ne dépend pas que de vous. Découvrez comment Bitdefender Ultimate Security vous protège au-delà de votre navigation web.

Cet article a été réalisé en collaboration avec Bitdefender

Il s’agit d’un contenu créé par des rédacteurs indépendants au sein de l’entité Humanoid xp. L’équipe éditoriale de Numerama n’a pas participé à sa création. Nous nous engageons auprès de nos lecteurs pour que ces contenus soient intéressants, qualitatifs et correspondent à leurs intérêts.

En savoir plus

Dans la série "Qu'est-ce qu'on se marre avec les LLMs", des chercheurs en cybersécurité de Check Point ont tenté une expérience plutôt fun (enfin, je trouve ^^) : Demander à DeepSeek de leur coder un ransomware capable de tourner directement dans le navigateur.

Et bah croyez le ou non mais le machin l'a fait sans broncher ^^ Quand je repense à tout ce foin qu'on vient de vivre avec les américains avec Mythos et Fable 5 d'Anthropic, j'avoue je rigole quand je vois ça.

Alexey Bukhteyev et Pedro Drimel Neto, de l'équipe malware de Check Point, ont récupéré cet échantillon bricolé par l'IA, l'ont un peu peaufiné quand même, et se sont retrouvés avec une arme à 100% fonctionnelle capable de chiffrer tous vos documents depuis Chrome sans rien avoir à installer.

Le code malveillant s'appuie sur la File System Access API, une fonction qui permet à une page web de demander l'accès à un dossier de votre disque. La cible clique sur "autoriser" en pensant retoucher une image sur un site de "AI photo enhancer" bidon, et derrière la page parcourt le dossier ouvert, chiffre son contenu, et laisse une jolie demande de rançon et aucun moyen de récupérer les fichiers originaux.

Et surtout, DeepSeek a été au-delà de leurs attentes en proposant plein de fonctionnalités "cools" en plus à ce ransomware comme du vol de tokens Discord, de numéros de carte, de seed phrases crypto et de l'accès webcam. Mais en y regardant de plus près, les chercheurs ont remarqué que tout ceci avait été halluciné et ne fonctionnait pas vraiment. Le seul truc fonctionnel c'est le chiffrement du dossier qu'ils ont eux-même demandé et autorisé.

L'idée de faire un ransomware dans le navigateur n'est pas nouvelle et d'autres chercheurs l'avaient déjà théorisée à la conférence USENIX Security en 2023 sous le nom de RoB, ("Ransomware over Browsers") mais ce qui change vraiment ici, c'est que sans grandes compétences, n'importe qui peut le faire.

Mise à jour du 26 juin 2026 : Mathias Rochus, le fondateur d'AdBlock Ltd qui édite l'extension, m'a contacté pour réagir. Il souligne que cette capacité n'a jamais servi (le rapport Island le confirme) et que le scriptlet en cause, trusted-create-element, n'est pas maison : il vient de la bibliothèque open-source de scriptlets d'AdGuard que beaucoup de bloqueurs embarquent. Surtout, il annonce corriger les deux problèmes dès aujourd'hui : suppression pure et simple du scriptlet inutilisé pour qu'aucune config serveur ne puisse l'appeler, et vérification du vrai domaine youtube.com au lieu d'une chaîne posée n'importe où dans l'URL. La nouvelle version doit encore passer la revue de Google.

Une précision quand même, parce que c'est le cœur du sujet : selon le rapport Island, quand le serveur renvoie certains paramètres, l'élément créé est une balise <script> dont le contenu est fourni directement par le serveur. Autrement dit, le verrou qu'on retire servait bien à faire tourner du code venu d'ailleurs. Le correctif, lui, est une bonne nouvelle pour les 10 millions d'utilisateurs. Je reviendrai vérifier une fois la mise à jour en ligne.

Si vous avez installé une extension qui s'appelle "Adblock for YouTube" pour virer les pubs de vos vidéos, prenez deux minutes pour lire mon article.

Les chercheurs Oleg Zaytsev et Shachar Gritzman, de la boîte de sécurité Island, viennent de passer au peigne fin une de ces extensions installée par plus de 10 millions de personnes, et ce qu'ils ont trouvé dedans n'est pas très joli joli. Le truc affiche fièrement un badge "Featured" sur le Chrome Web Store, fait bien le boulot promis (il bloque les pubs), mais il embarque aussi de quoi exécuter n'importe quel bout de JavaScript sur n'importe quel site que vous visitez.

Et ça, ça craint !

Mais avant que vous fermiez l'onglet en panique, sachez tout d'abord qu'il existe plusieurs extensions qui portent ce nom. Celle qui pose problème a un identifiant précis, cmedhionkhpnakcndndgjdbohmhepckk. Donc pour vérifier, tapez chrome://extensions dans votre barre d'adresse, activez le "Mode développeur" en haut à droite, et regardez l'ID affiché sous chaque extension. Si vous tombez sur celui-là, virez-la sans réfléchir. Si c'est un autre identifiant, ce n'est pas l'extension visée par cette analyse, ce qui ne veut pas dire pour autant que tous les bloqueurs du store sont blancs comme neige, hein...

Ce qui inquiète Island, ce n'est pas une ligne de code qui vole vos données là, maintenant mais plutôt une capacité en sommeil. L'extension contient ce que les chercheurs appellent les ingrédients architecturaux pour faire tourner du code arbitraire, et la mèche peut être allumée par un simple changement côté serveur sans que cela se voit.

En clair, du jour au lendemain, le bidule pourrait se mettre à lire vos pages, aspirer vos données et à agir à votre place dans vos comptes perso, vos applis de boulot ou vos panneaux d'admin. Au moment de l'analyse, le mécanisme dormait. Il n'était pas absent.

Et le détail qui fait sourire jaune, c'est quand même ce garde-fou censé limiter l'extension à YouTube. En théorie elle ne s'active que sur le site de Google mais en pratique, elle tourne sur absolument tous les sites, avec une vérification qui regarde juste si la chaîne "youtube.com" apparaît quelque part dans l'URL.

Oui n'importe où, du coup une adresse comme bank.example.com/search?q=youtube.com passe le test sans problème donc autant vous dire que le verrou ne verrouille pas grand chose...

Cette extension traîne sur le store depuis 2014. Au départ c'était donc un bête bloqueur de pub YouTube, jusqu'à un changement de propriétaire en 2018. Les premières versions embarquaient carrément un SDK d'injection de pub baptisé Unistream, finalement retiré en juin 2024, et les chemins d'injection de script pilotables à distance sont présents depuis février 2025. 3 autres extensions de blocage de pub liées au même écosystème ont déjà été dégagées du Chrome Web Store pour cause de malware.

Toutefois, pour le moment, il n'y a aucune preuve qu'un payload malveillant ait réellement été poussé aux utilisateurs, mais c'est la combinaison de plusieurs de ces facteurs qui pue : une extension à 10 millions d'installs, un accès à tous les sites, un canal d'injection téléguidé, un passé d'injection de pub et des cousines déjà bannies. Gloups !

Donc je vous conseille vivement de faire le tour de vos extensions. CRXplorer vous aidera à débusquer celles qui sont louches, et si vous cherchez à bloquer les pubs proprement, j'avais fait le point sur les bonnes méthodes pour ça . Petit rappel au passage, sur Chrome le uBlock Origin complet a été débranché par le passage à Manifest V3, et il ne reste que sa version Lite, forcément moins fortiche.

Donc si vous voulez le vrai, c'est sur Firefox que ça se passe maintenant.

Bref, méfiez-vous des bloqueurs de pub qui réclament la lune et au moindre doute sur l'ID, désinstallez cette merde !

Source

Si vous faites un peu de reverse engineering sous Android, vous savez que les malwares modernes font absolument tout ce qu'ils peuvent pour planquer leurs mauvaises intentions, un peu comme vos parents toxiques... Code obfusqué, chargement dynamique, packing...etc, etc.

Mais c'était sans compter sur une équipe de chercheurs italiens menée par Giorgio Giacinto ont carrément changé de stratégie avec RAMwavDroid qui au lieu de désassembler le code , permet de le transformer en son et ensuite, laissent une IA l'écouter. Et cela permet d'obtenir un niveau de 98% de détection des malwares.

J'vous explique la sorcellerie de ce truc...

En effet, d'habitude, pour analyser une appli Android, on décompile l'APK et on récupère le code, notamment des fichiers smali, un équivalent lisible par un humain du code bas niveau Dalvik.

Mais avec leur RAMwavDroid, vous prenez le fichier, et chaque octet, qui vaut une valeur entre 0 et 255, devient directement une amplitude sonore. Pas de normalisation, ni de désassemblage mais simplement une forme d'onde, stockée dans un vrai fichier WAV ou MP3 + des réseaux de neurones qui apprennent à reconnaître la texture sonore d'un malware.

Le transformer utilisé, c'est Wav2Vec2, qui était même à la base entraîné sur de la voix humaine.

Comment RAMwavDroid transforme les octets d'une appli en forme d'onde

Mais alors pourquoi passer par le son ?

Hé bien parce que les antivirus classiques s'appuient sur le "sens" du programme, ses permissions, ses appels API, la structure de son code...etc. Or c'est exactement ça que les vrais malwares un peu filous brouillent pour passer entre les mailles. Alors que la texture brute des octets, elle, reste la même, peu importe l'habillage que son concepteur a donné à son malware.

Et ça, une oreille artificielle finit par le repérer.

Mais le vrai coup de génie c'est que plutôt que d'analyser le fichier au repos, RAMwavDroid lance l'appli dans un émulateur et prend un instantané de sa mémoire vive juste après le démarrage. Ça permet de parcourir les fichiers chargés en mémoire, les processus, et surtout le code que le packing a déjà déchiffré pour pouvoir s'exécuter. Cette analyse forensique de la mémoire fait alors grimper la précision de près de 94% en statique à jusqu'à 98% en dynamique.

Le spectrogramme d'une appli malveillante, vu comme un son

Sur un extrait de dataset de malwares utilisé pour leurs tests, composé de 600 applis (moitié saines moitié vérolées), RAMwavDroid tape jusqu'à 98% de bonnes réponses, avec dans sa meilleure configuration quasiment aucun faux positif.

Un faux positif, c'est quand il n'y a pas de malware, mais que l'antivirus clignote quand même en rouge, donc ça montre bien l'efficacité de leur technologie. On est au même niveau que VirusTotal qui fait bosser des dizaines de moteurs de détection en parallèle.

Bien sûr, c'est un résultat de laboratoire sur un échantillon limité d'apps, et le code source n'est pas encore disponible publiquement, donc on ne peut que les croire sur parole. Surtout que leur système fonctionne uniquement dans un émulateur (pour accéder à la RAM) et ça c'est un truc typique que les malwares sont capables de détecter... Donc bon, à voir...

En plus ce système se fait avoir par les applis bourrées de gros SDK légitimes qui noient également le signal, et par les malwares minimalistes trop simples pour faire du bruit. Bref, la robustesse face à l'obfuscation avancée, ce sera pour plus tard mais j'ai trouvé cette façon de faire plutôt originale.

Peut-être qu'à terme, les créateurs de malware mixeront leur binaire avec un MP3 de Jul ou Gims pour tromper ces futurs détecteurs audio ^^.

Source

MÀJ du 12 juin : quand j'ai publié cet article, on en était à 400 paquets vérolés. Sauf que le chiffre n'a pas arrêté de grimper dans la journée. Quelques heures plus tard on parlait de 900, puis en fin de journée la liste recensait déjà 1579 paquets touchés, et les devs d'Arch précisent eux-mêmes que cette liste contient "beaucoup, mais pas tous" les paquets concernés. Bref, le décompte bouge en permanence, et il a même été suivi d'une seconde vague d'attaque encore plus sophistiquée. Donc si vous voyez circuler 400, 1500 ou 2000, c'est juste que chacun a pris la photo à un instant différent. La bonne nouvelle, c'est que les développeurs d'Arch ont depuis supprimé tous les commits malveillants qu'ils ont identifiés et estiment l'incident sous contrôle.

Si vous tournez sous Arch Linux et que vous piochez vos paquets dans l'AUR, lâchez ce que vous faites 2 minutes et lisez mon article. Car plus de 400 paquets de l'Arch User Repository ont été vérolés ce 11 juin, et le truc qu'ils embarquent ne rigole pas du tout. En effet, des chercheurs de Sonatype ont repéré une campagne baptisée Atomic Arch où un seul attaquant a réussi à glisser un stealer (un voleur d'identifiants quoi) dans des centaines de paquets d'un coup.

Mais bonne nouvelle avant de paniquer quand même, les dépôts officiels d'Arch (core, extra, multilib) ne sont pas concernés. C'est l'AUR, et uniquement l'AUR.

Si vous avez installé ou mis à jour un paquet AUR ces derniers jours, vous devez donc vérifier si vous n'êtes pas infecté. Des noms comme alvr, gnome-randr-rust ou ipfs-desktop-bin font partie de la liste, et elle est sacrément longue. Le signe qui doit vous mettre la puce à l'oreille, c'est par exemple un paquet qui n'a rien à voir avec du JavaScript et qui se mettrait pourtant à lancer un npm install durant son installation.

Pour sortir la liste de tout ce qui vient de l'AUR sur votre machine, un petit pacman -Qm fera le job, et le forum de CachyOS propose également un script qui compare vos paquets à la liste des vérolés connus. Méfiez-vous quand même, car ce script repère juste les noms de paquets piégés, et ne vérifie pas l'intégrité de votre système. Un résultat propre veut dire qu'aucun paquet connu n'est installé chez vous, mais pas que vous êtes tiré d'affaire, alors on reste concentré.

Alors comment ce malware s'est retrouvé dans autant de paquets ?

Eh bien l'attaquant n'a même pas eu besoin de pirater quoi que ce soit puisque l'AUR permet à n'importe qui "d'adopter" les paquets orphelins, c'est-à-dire ceux que leur mainteneur d'origine a laissés tomber. Il a donc récupéré la propriété de centaines de ces paquets abandonnés via la procédure normale, puis modifié leur PKGBUILD pour qu'à l'installation, un hook télécharge en douce un paquet npm piégé du genre atomic-lockfile. Ce paquet déploie ensuite un binaire baptisé deps, et ce deps, c'est une vraie saloperie.

Parce que ce deps, comme je vous le disais, c'est un voleur d'identifiants mais vraiment taillé pour cibler les développeurs. Dans le dos de la victime, il récupère vos clés SSH privées, vos tokens GitHub, vos identifiants npm, Docker et Podman, vos tokens HashiCorp Vault, les cookies et mots de passe de vos navigateurs, vos sessions Slack, Discord ou Telegram, vos configs VPN et même tout votre historique de commandes shell. En clair, toutes les clés de votre vie de dev qui, une fois dans la nature, ouvrent grand la porte vers d'autres systèmes.

Et si vous avez lancé le paquet en root, il installe en prime un rootkit eBPF qui se planque carrément dans le noyau pour masquer ses processus. Le fonctionnement même de ce truc fait alors qu'il est quasi impossible de détecter à l'œil nu si on est infecté ou pas. On est sur la même logique que le ver Shai-Hulud planqué dans des paquets , sauf qu'ici l'échelle a pris une autre dimension.

Alors que faire pour se protéger ?

Eh bien si vous avez le moindre doute, partez du principe que la machine est compromise, surtout si le paquet a tourné avec les droits root. Et supprimer le paquet ne suffira pas car le rootkit, lui, reste planté.

Donc on fait comme d'hab, on régénère tous ses secrets, nouvelles clés SSH, révocation et régénération des tokens GitHub, npm, Docker et Vault, changement des mots de passe stockés dans le navigateur et compagnie... Et pour la suite, comme d'hab, faites attention à ce que vous installez et prenez l'habitude de lire les PKGBUILD avant de valider, parce qu'un script post-install qui fait autre chose qu'un simple echo, ça doit vous faire tiquer direct.

Quoi qu'il en soit, l'AUR n'a jamais été audité, c'est même l'un des principes du truc et tout le monde le sait... mais des centaines voire plus d'un millier de paquets piégés d'un coup avec un rootkit qui vise vos accès, ça change fortement l'échelle du problème.

Bref, vérifiez vos paquets et faites tourner vos secrets aussi bien que vous faites tourner les serviettes quand c'est le jour du beaujolais au taf !

Et un grand merci à Maximilien pour le lien !

Source