La découverte d'un mineur de cryptomonnaie par Claude Code révèle un paradoxe de sécurité plus vaste

Claude Code aurait détecté un mineur de cryptomonnaie consommant 1 175 % du CPU alors qu’il aidait un développeur à enquêter sur un Mac ayant atteint 112 degrés Celsius.

Cette découverte d’un mineur de cryptomonnaie par Claude Code ressemble à une victoire nette pour l’IA agentique. L’agent de codage a suivi des relevés de température suspects, identifié un processus XMRig et proposé de supprimer les fichiers qui l’exécutaient.

Pourtant, l’incident révèle aussi une contradiction inconfortable. Le système s’est avéré utile parce qu’il pouvait inspecter des processus et proposer des modifications du système, soit les mêmes capacités qui rendent les agents de codage risqués.

Le récit provient de l’utilisateur Reddit UntilHEX, et non d’une enquête médico-légale publiée. Les captures d’écran disponibles et les commentaires de suivi étayent une séquence plausible, mais ne permettent pas d’établir comment le logiciel est arrivé là.

Cette lacune de vérification est importante. Claude Code semble avoir repéré un véritable problème opérationnel, mais les lecteurs ne devraient pas confondre un rapport viral isolé avec une évaluation validée de logiciels malveillants.

Claude Code a suivi la chaleur jusqu’à XMRig

L’élément le plus notable de cette histoire n’est pas que Claude Code ait reconnu XMRig. C’est que l’agent a enquêté sur un signal physique inattendu.

UntilHEX a indiqué avoir demandé à Claude Code de créer une application de surveillance de température pour Mac. L’application a affiché des valeurs brutes de capteurs qui semblaient anormalement élevées, incitant l’agent à examiner l’activité du CPU.

Selon le récit Reddit original, Claude a identifié un processus xmrig consommant environ 1 175 % du CPU. L’agent a interprété cette valeur comme l’équivalent d’environ 12 cœurs fortement sollicités.

Des pourcentages supérieurs à 100 sont normaux dans les rapports de processus de macOS lorsqu’un logiciel utilise plusieurs cœurs logiques. Un processus occupant près de 12 cœurs peut donc apparaître autour de 1 200 %.

La documentation d’Apple explique que Moniteur d’activité affiche la consommation CPU des processus actifs tout en montrant l’utilisation globale du système sur l’ensemble des cœurs. Des relevés soutenus de cette ampleur indiquent une charge de travail intensive, même si leur interprétation exacte dépend du Mac.

Claude aurait associé le processus à des températures culminant à 112 degrés Celsius. Ce chiffre provient de la sortie de surveillance de l’utilisateur et n’a pas été reproduit de manière indépendante.

L’agent a ensuite identifié ce qui semblait être un mécanisme de démarrage. Les captures d’écran examinées dans la couverture originale suggéraient que des fichiers associés avaient été configurés pour relancer le mineur au démarrage du Mac.

Claude a décrit la situation sans détour : l’ordinateur exécutait un mineur de cryptomonnaie que l’agent affirmait ne pas avoir installé. Il a proposé d’arrêter le processus, de désactiver son entrée de démarrage et de mettre en quarantaine les fichiers associés.

L’utilisateur a ensuite déclaré que Claude avait effectué la majeure partie du nettoyage. Un fichier aurait nécessité une suppression manuelle, car l’agent ne disposait pas des autorisations nécessaires.

UntilHEX a ensuite exécuté Malwarebytes comme vérification secondaire. Le récit public ne comprend pas de rapport d’analyse complet, d’échantillon de logiciel malveillant, de hachages de fichiers, d’indicateurs réseau ou d’analyse médico-légale indépendante.

Ces omissions limitent les conclusions possibles. Elles empêchent les chercheurs d’identifier avec précision la famille de logiciels malveillants, le vecteur d’installation, le mécanisme de persistance ou la destination du minage.

XMRig n’est pas intrinsèquement malveillant. Sa documentation officielle le décrit comme une application open source légitime de minage sur CPU et GPU, disponible sur plusieurs systèmes d’exploitation.

La question de sécurité dépend de l’autorisation. Exécuter XMRig sur une machine avec l’accord de son propriétaire relève du minage de cryptomonnaie ordinaire. L’installer ou l’exploiter secrètement constitue du cryptojacking.

Cette distinction est essentielle, car l’identification d’un processus xmrig ne prouve pas quel installateur l’a placé là. Elle ne permet pas non plus de déterminer si le binaire a été modifié, inclus avec d’autres logiciels malveillants ou dissimulé sous des noms de fichiers associés.

L’histoire virale permet donc une conclusion plus restreinte. Claude Code a repéré une utilisation extrême des ressources et l’a reliée à un logiciel associé au minage de cryptomonnaie.

Cela reste un résultat utile. Cela n’établit pas que Claude a identifié l’intrusion d’origine ni supprimé tous les composants responsables.

Pourquoi la découverte d'un mineur de cryptomonnaie par Claude Code est importante

Claude Code ne semble pas avoir commencé par une tâche de détection de logiciels malveillants. Il est parvenu à cette découverte de sécurité en vérifiant si l’ordinateur correspondait à la sortie de son propre logiciel.

Cette séquence distingue cette histoire d’une alerte antivirus classique. L’agent aidait à créer un outil de surveillance lorsque les données des capteurs l’ont conduit à remettre en question l’environnement qui l’entourait.

Les logiciels traditionnels s’arrêtent souvent à la limite de leur fonction assignée. Un utilitaire de température peut afficher un chiffre sans déterminer pourquoi ce chiffre est anormal.

Un agent peut explorer l’écart. Il peut inspecter les processus en cours d’exécution, comparer l’utilisation des ressources, examiner les entrées de persistance et proposer des actions correctives dans un même flux de travail conversationnel.

Ce comportement représente l’attrait pratique des agents de codage. Ils peuvent relier le code, l’état du système d’exploitation, les journaux et l’intention de l’utilisateur sans exiger une interface distincte pour chaque étape.

Dans ce cas, les symptômes physiques ont fourni l’indice. Le Mac chaud et lent a créé un élément de preuve que l’application en cours de développement ne pouvait pas expliquer à elle seule.

L’agent serait passé de la validation des capteurs au diagnostic des processus. C’est un petit exemple de ce que les systèmes agentiques font différemment des outils de complétion de code.

Un assistant de complétion de code prédit ou génère du texte dans un éditeur. Un agent peut recueillir des éléments de preuve supplémentaires et utiliser des outils pour agir sur un ordinateur.

La pression s’exerce d’abord sur les flux de dépannage traditionnels. Un développeur ouvrirait normalement Moniteur d’activité, trierait les processus par CPU, enquêterait sur le processus suspect et inspecterait manuellement les emplacements de démarrage.

Claude Code a condensé plusieurs de ces étapes dans un dialogue. L’utilisateur conservait la décision finale, mais l’agent a assemblé une explication plausible et un plan de nettoyage.

Cela ne rend pas Moniteur d’activité obsolète. Apple l’intègre depuis longtemps à macOS, et il peut révéler le même type de demande CPU soutenue sans abonnement à une IA.

La différence concerne l’initiative et la synthèse. L’utilisateur aurait demandé une application de température, tandis que Claude a étendu l’enquête lorsque les données obtenues semblaient erronées.

Cette initiative est précieuse pour les développeurs confrontés à des systèmes inconnus. Elle peut aussi aider lorsque les symptômes traversent les frontières entre le code d’application, la configuration système et la sécurité.

Cette histoire ressemble davantage à un travail d’observabilité qu’à une détection antivirus conventionnelle. L’observabilité part des signaux système et les utilise pour déterminer pourquoi le comportement diffère des attentes.

Claude n’avait pas besoin d’une signature affirmant qu’un fichier était malveillant. Il aurait remarqué que la température et l’activité du processeur ne correspondaient pas à la charge de travail prévue.

Cette approche a ses limites. Une utilisation élevée du CPU peut provenir de la compilation, du rendu vidéo, de modèles locaux, de processus de navigateur, de l’indexation ou d’un minage légitime.

Le contexte transforme une anomalie en avertissement significatif. Ici, l’utilisateur créait un moniteur léger, et n’exécutait pas intentionnellement une charge de travail de cryptomonnaie soutenue.

Ce cas met par conséquent sous pression les éditeurs de logiciels de sécurité et les créateurs d’outils pour développeurs de différentes manières. Les produits de sécurité doivent expliquer clairement leurs résultats, tandis que les agents de codage doivent prouver qu’ils peuvent enquêter sans créer de nouvelles expositions.

Il modifie aussi les attentes des utilisateurs. Une fois qu’un agent peut inspecter l’état réel du système, les développeurs s’attendront à ce qu’il repère les conflits évidents affectant la tâche.

Cette attente va au-delà des logiciels malveillants. Les agents pourraient détecter un stockage saturé, des services d’arrière-plan défaillants, des ports en conflit, une pression mémoire ou des identifiants placés dans des fichiers non sécurisés.

Les équipes adoptant ces outils auront besoin de registres consultables de ce qu’un agent a observé et modifié. Une base de connaissances d’ingénierie structurée peut préserver ces décisions pour un examen ultérieur.

L’affirmation de détection de logiciels malveillants par Claude Code est donc intéressante malgré ses limites probatoires. Elle montre comment une tâche de codage peut devenir une enquête opérationnelle lorsqu’un agent reçoit suffisamment de contexte local.

L’agent utile et l’autorisation dangereuse sont une seule et même chose

Le renversement central est simple : Claude Code a aidé parce qu’il disposait d’une visibilité système importante, mais cette visibilité définit aussi son risque de sécurité.

Un agent de codage incapable d’inspecter les processus, de lire les fichiers du projet ou d’exécuter des commandes de diagnostic aurait eu du mal à remonter jusqu’au Mac en surchauffe.

L’octroi de ces capacités élargit ce que l’agent peut accomplir. Il élargit aussi les conséquences d’une commande erronée, d’une instruction malveillante, d’une dépendance compromise ou d’une approbation négligente.

Les propres conseils sur le sandboxing d’Anthropic décrivent cette tension. Claude Code utilise des autorisations et des limites du système d’exploitation pour contrôler l’accès aux fichiers et au réseau.

Anthropic indique que Claude Code est en lecture seule par défaut et demande une confirmation avant la plupart des commandes qui modifient l’état. Les commandes sûres peuvent recevoir un traitement différent, tandis que les opérations sensibles exigent une approbation.

L’entreprise a introduit le sandboxing afin de réduire les invites répétées sans accorder un accès sans restriction. Un sandbox définit les emplacements où l’agent peut écrire et les ressources réseau qu’il peut atteindre.

Anthropic a indiqué que le sandboxing avait réduit de 84 % les invites d’autorisation lors d’une utilisation interne. Ce chiffre communiqué par l’entreprise mesure la friction du flux de travail, et non la protection contre toutes les attaques.

Cette distinction est importante, car les utilisateurs optimisent souvent les agents pour la commodité. Des approbations répétées peuvent engendrer de la fatigue et encourager les personnes à approuver des commandes sans en examiner les conséquences.

Supprimer entièrement les invites crée un autre problème. L’agent peut agir plus vite, mais un plan défaillant peut atteindre davantage de fichiers et de services avant l’intervention de l’utilisateur.

L’incident du Mac illustre pourquoi les autorisations doivent rester visibles. Claude aurait proposé d’arrêter le mineur et de déplacer les fichiers plutôt que de les supprimer silencieusement.

Cette hésitation est une fonctionnalité. Un nom de processus seul ne suffit pas à prouver que chaque fichier associé est malveillant, surtout lorsque XMRig peut être utilisé légitimement.

La mise en quarantaine est plus sûre qu’une destruction immédiate, car elle préserve les preuves et permet la récupération. Elle peut aussi faciliter une analyse ultérieure si les fichiers sont traités de manière sécurisée.

Cependant, laisser un système d’IA effectuer une remédiation exige toujours un jugement humain. Un modèle de codage n’est pas un moteur de détection d’endpoint de confiance simplement parce qu’il peut appeler des commandes shell.

Il peut mal comprendre une arborescence de processus, mal interpréter un fichier de configuration ou supprimer un élément de démarrage appartenant à un logiciel légitime. Il peut aussi négliger un composant de persistance distinct.

La sécurité des agents de codage IA dépend donc de contrôles superposés. Le raisonnement du modèle constitue une couche, tandis que les restrictions du système d’exploitation, les règles d’approbation, la journalisation, les sauvegardes et la protection des endpoints en fournissent d’autres.

Apple décrit trois couches dans ses défenses contre les logiciels malveillants de macOS : empêcher l’exécution, bloquer les logiciels malveillants connus et remédier aux logiciels qui ont été exécutés.

Gatekeeper vérifie les logiciels téléchargés au regard des exigences de signature et de notarisation. XProtect utilise des signatures et une analyse comportementale pour détecter et supprimer les logiciels malveillants connus ou suspects.

Ces mécanismes ne garantissent pas que tous les programmes malveillants seront arrêtés. De nouvelles variantes, des binaires modifiés, l’abus d’outils légitimes et des exécutions approuvées par l’utilisateur peuvent compliquer la détection.

Le rapport ne permet pas d’établir si Gatekeeper ou XProtect ont échoué. Il ne révèle ni la version de macOS, ni la configuration de sécurité, ni la source de l’installateur, ni les actions ayant précédé l’infection.

Il serait tout aussi prématuré d’attribuer à Claude le contournement d’une faille dans les défenses d’Apple. Les éléments publics ne permettent pas de savoir si XProtect avait évalué les fichiers concernés.

L’agent est également intervenu après que les symptômes sont devenus graves. Une machine consommant près de 12 cœurs et atteignant la température signalée indiquait déjà un problème majeur.

Il ne s’agissait pas d’une détection discrète et préventive. C’était un diagnostic réactif, après que le mineur présumé est devenu suffisamment visible pour dégrader l’ordinateur.

Le même accès qui a permis ce diagnostic mérite des limites strictes. Les développeurs ne devraient pas réagir en accordant à chaque agent de programmation un contrôle illimité sur les fichiers personnels, les identifiants ou les services système.

Une configuration plus sûre limite l’agent au répertoire de travail chaque fois que possible. Les destinations réseau et les commandes privilégiées doivent faire l’objet d’un examen distinct.

Les développeurs devraient aussi éloigner les agents des secrets non liés à leur tâche. Les dépôts de code source coexistent souvent avec des identifiants cloud, des clés de signature, des sessions de navigateur et des configurations de production.

Une commande de diagnostic apparemment utile peut exposer ces ressources si sa sortie entre dans le contexte du modèle ou dans les journaux de session. Le risque existe même lorsque l’agent n’a aucune intention malveillante.

La leçon de cette histoire n’est pas qu’un accès plus large produit toujours une meilleure sécurité. Elle montre plutôt qu’un accès contrôlé peut permettre aux agents de relier des éléments que des outils isolés laissent éparpillés.

Une détection virale n’est pas un rapport d’expertise forensique

L’affirmation reste suffisamment crédible pour être analysée, mais trop incomplète pour prouver que Claude a supprimé une infection complète par malware.

Les éléments initiaux se composent principalement d’une publication Reddit, de captures d’écran, de commentaires d’utilisateurs et d’une couverture médiatique ultérieure. Aucun chercheur indépendant ne semble avoir examiné la machine ou les fichiers.

Les chiffres centraux proviennent également de ce témoignage. Les journalistes n’ont pas reproduit la lecture de 1 175 % de CPU ni vérifié indépendamment le pic signalé de 112 degrés.

Tom’s Hardware a justement présenté l’incident comme une découverte rapportée par un utilisateur. Son récit publié note que le nombre de cœurs du Mac non identifié était inconnu.

Cette incertitude influe sur l’interprétation. Le processus était clairement décrit comme exigeant, mais les informations publiques n’identifient ni le modèle exact de Mac ni la méthode de mesure thermique.

Les outils de température peuvent aussi nommer les capteurs différemment. Un pic signalé peut représenter un cœur particulier, un capteur de puce, un point chaud ou une valeur interprétée, plutôt qu’une température CPU universelle.

Rien de cela ne réfute le témoignage. Cela trace simplement la frontière entre un récit convaincant fondé sur des captures d’écran et des preuves techniques reproductibles.

Le chemin d’infection constitue une lacune encore plus importante. UntilHEX n’a pas publiquement établi quel téléchargement, installateur, script, extension ou paquet compromis a introduit le mineur.

Sans cette réponse, les autres utilisateurs ne peuvent pas déterminer s’ils partagent la même exposition. Les chercheurs en sécurité ne peuvent pas non plus créer des indicateurs fiables à partir du seul rapport.

Le nom XMRig n’offre qu’un point de départ. Les opérateurs de malwares abusent couramment de logiciels de minage légitimes, car ils effectuent déjà le travail informatique coûteux dont ils ont besoin.

D’anciens malwares sur Mac illustrent ce précédent. Malwarebytes a documenté le malware BirdMiner, qui utilisait XMRig via un émulateur Linux et consommait les ressources informatiques de ses victimes.

Cet exemple historique n’identifie pas le logiciel présent sur le Mac d’UntilHEX. Il montre seulement que XMRig est déjà apparu dans des opérations de minage non autorisées sur Mac.

La différence entre identifier un mineur et nettoyer une infection est considérable. Une enquête complète examinerait la persistance, les processus parents, les fichiers téléchargés, les connexions réseau, les comptes et les actions administratives récentes.

Elle préserverait également les hachages et les horodatages avant toute suppression. Ces détails peuvent montrer si un apparent programme de mise à jour appartient à la même opération ou représente autre chose.

Supprimer le mineur visible peut arrêter la consommation actuelle de CPU tout en laissant un téléchargeur en arrière-plan. Un mécanisme de persistance survivant pourrait réinstaller la charge utile plus tard.

L’exposition des identifiants soulève une autre préoccupation. Un malware ayant accès au compte d’un développeur pourrait atteindre des jetons, des données de navigateur, du code source, des éléments SSH ou des fichiers d’environnement.

Le compte Reddit ne dit pas qu’un tel accès a eu lieu. Toutefois, mettre fin au processus de minage ne peut pas démontrer que les identifiants sont restés intacts.

Une réponse professionnelle traiterait l’hôte comme potentiellement compromis jusqu’à ce que le mécanisme de persistance et le point d’entrée soient compris. La réponse appropriée dépend du rôle et du niveau de sensibilité de la machine.

Un ordinateur personnel de test et un poste de travail contenant des identifiants de production présentent des risques différents. Le second cas peut justifier une rotation des mots de passe, une révocation des jetons, un examen forensique approfondi ou une reconstruction à partir d’un système de confiance.

L’aide de Claude au nettoyage ne devrait donc pas devenir la preuve finale de sécurité. L’analyse Malwarebytes de suivi effectuée par l’utilisateur était une vérification secondaire judicieuse, mais la publication publique n’en fournit pas les résultats.

La réponse sceptique s’applique aussi aux affirmations concernant les performances de l’IA. Un seul succès ne permet pas de mesurer la précision de détection des malwares par Claude Code, ses faux positifs ou sa fiabilité face à diverses attaques.

Une véritable évaluation utiliserait un ensemble contrôlé de machines saines et infectées. Les chercheurs compareraient les résultats aux outils établis et répéteraient les tests avec des autorisations documentées.

Cette étude devrait mesurer les menaces manquées et les remédiations nuisibles, pas seulement les détections réussies. Un agent qui détecte un mineur mais supprime des services de démarrage légitimes ne serait pas fiable.

Pour l’instant, il vaut mieux considérer l’événement comme un cas de dépannage frappant. Il montre un agent établissant un lien utile, tout en laissant les affirmations de sécurité plus larges non prouvées.

Ce que devront démontrer les prochains cas de sécurité Claude Code

Les prochains éléments utiles proviendront d’enquêtes reproductibles, de relevés d’autorisations et de preuves que la remédiation résiste à un redémarrage.

Le premier signal à surveiller est la publication par UntilHEX ou un chercheur en sécurité d’indicateurs techniques issus de ce cas. Les hachages de fichiers, chemins, entrées de lancement et destinations réseau rendraient une analyse indépendante possible.

Si ces détails permettent d’identifier une famille de malwares reconnue et une chaîne de persistance confirmée, le témoignage devient bien plus solide. Si aucun artefact n’émerge, il reste une anecdote instructive mais non vérifiée.

Le deuxième signal concerne la durabilité du nettoyage. Un processus supprimé devrait rester absent après déconnexion, redémarrage et nouvelle analyse.

Sa réapparition montrerait que Claude a traité un symptôme plutôt que le mécanisme complet. Son absence continue renforcerait l’affirmation selon laquelle la remédiation proposée a atteint les fichiers de persistance concernés.

Même dans ce cas, l’absence seule ne prouverait pas qu’aucun identifiant ni fichier non lié n’a été affecté. Elle ne validerait que le résultat plus limité du nettoyage.

Le troisième signal concerne la manière dont les fournisseurs d’agents exposent les actions locales. Les développeurs ont besoin de relevés plus clairs des commandes exécutées, des fichiers modifiés, des accès refusés et de l’origine des éléments de preuve.

La poursuite des travaux d’Anthropic sur les autorisations et le sandboxing sera importante ici. Les agents utiles ont besoin d’une autonomie suffisante pour enquêter, tandis que les organisations ont besoin de limites applicables et de journaux auditables.

Les fournisseurs de sécurité ont également une opportunité. Ils peuvent alimenter les flux de travail des agents avec des résultats de terminaux vérifiés sans demander à un modèle de langage de décider seul si un processus est malveillant.

Cette organisation combine des atouts différents. Les outils de protection des terminaux apportent des signatures, de la télémétrie et des contrôles de remédiation, tandis que les agents expliquent les preuves et coordonnent les étapes approuvées.

La découverte signalée d’un mineur de cryptomonnaie par Claude Code s’inscrit dans ce modèle hybride. L’agent a remarqué une anomalie et rassemblé du contexte, tandis qu’un logiciel de sécurité établi fournissait une étape de validation distincte.

Les développeurs devraient préserver cette séparation dès aujourd’hui. Laissez l’agent aider à interpréter les symptômes et à rédiger un plan de réponse, mais confirmez la découverte avec les outils du système d’exploitation et de sécurité.

Ils devraient également examiner chaque action privilégiée. Un agent qui demande l’autorisation de supprimer, désactiver ou mettre quelque chose en quarantaine présente une proposition, et non un verdict vérifié.

L’incident ne justifie pas de paniquer à l’idée que XMRig apparaisse sur chaque Mac. Il donne toutefois une raison d’enquêter sur une chaleur persistante, de mauvaises performances, des entrées de démarrage inattendues et une demande CPU inexpliquée.

Il remet aussi en question une hypothèse courante sur les agents de programmation. Leur valeur ne s’arrête pas lorsque le code généré compile.

La capacité la plus intéressante est leur aptitude à comparer la sortie logicielle avec l’état réel de l’ordinateur. Cela peut révéler des problèmes d’environnement que la demande initiale n’avait jamais mentionnés.

Le compromis reste inévitable. Davantage de contexte favorise un meilleur diagnostic, tandis qu’un accès plus large augmente les dommages qu’un agent erroné ou manipulé peut causer.

Quiconque expérimente la détection de malwares avec Claude Code devrait commencer avec des autorisations limitées, des journaux conservés et un scanner indépendant. Les machines sensibles méritent des limites plus strictes et un processus de réponse aux incidents documenté.

La prochaine fois qu’un agent détecte un processus suspect, posez trois questions avant de vous réjouir : quelles preuves l’identifient, comment a-t-il persisté et qu’est-ce qui prouve qu’il est resté supprimé ? Les réponses détermineront si l’agent a trouvé un désagrément, contenu une intrusion ou simplement produit une histoire convaincante.