Programmes malveillants

Particuliers et entreprises

Minage clandestin

Cryptojacking

La puissance de vos machines est consommée pour rémunérer un tiers.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 5 min
Je pense être concerné : que faire ?
Illustration pédagogique : minage clandestin.

Comprendre et agir

À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.

Une situation concrète

La facture cloud augmente alors que les usages habituels n’ont pas changé. Des machines supplémentaires exécutent un calcul intensif. Sur un ordinateur, le symptôme peut être une consommation durable de ressources. Un tiers utilise votre capacité de calcul pour son propre bénéfice.

Comment cela fonctionne

Le cryptojacking détourne des ressources pour miner des cryptoactifs. Il peut toucher un poste, un serveur, un conteneur ou un compte cloud. Le coût n’est pas uniquement énergétique : ralentissement, indisponibilité et accès compromis doivent être pris en compte. Arrêter le calcul ne suffit pas si la clé ou la faille qui a permis sa mise en place reste utilisable.

Comment le piège fonctionne
  1. Un accès est détourné

    Machine ou compte cloud.

  2. Du calcul est lancé

    Les ressources travaillent pour un tiers.

  3. Vous supportez le coût

    Performance, énergie ou facturation.

Les signes qui doivent attirer l’attention

  • Consommation CPU ou GPU durable sans tâche attendue.
  • Création de ressources ou dépenses inhabituelles.
  • Processus et connexions vers des services de calcul non autorisés.

Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.

Ce que vous pouvez faire

Vos premiers réflexes

Une consommation durable ou une facture inhabituelle mérite une vérification. Ne concluez pas au minage sur ce seul symptôme ; relevez les tâches et ressources que vous n’avez pas lancées.

Si vous êtes responsable du service ou de l’organisation

Limitez les droits de création de ressources et suivez les alertes de coûts. Supprimez aussi le compte ou la tâche qui recrée les calculs non autorisés.

Le détail qui change toutUne idée reçue à corriger

Un mineur découvert peut être le signe visible d’une intrusion plus large, pas seulement un problème de performance.

À vous de décider

La machine suspecte est arrêtée, mais une autre apparaît. Que manque-t-il dans la réponse ?

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Le traitement du mécanisme qui la recrée : tâche planifiée, contrôleur ou accès cloud compromis. Arrêter une machine ne retire pas ces droits.

Analyser un cas technique

Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.

Étude de cas fictive

Un compte de service lance un calcul coûteux dans le cluster

Le compte Kubernetes web:runner crée une tâche avec une image non approuvée. Le conteneur consomme 7,8 cœurs et communique avec une destination associée au calcul distribué. Ces éléments orientent vers un usage abusif des ressources, mais une forte charge seule ne suffit pas : un traitement scientifique ou une compilation peut aussi utiliser tous les cœurs.

La demande CPU de 0.1 sert au placement et à la réservation ; ce n’est pas un plafond de consommation. Vérifier les limites effectivement configurées, les quotas du namespace et les autorisations du compte de service. Un compte qui n’a besoin que de lire une ressource ne devrait pas pouvoir créer librement des charges de travail.

Supprimer le conteneur ne règle pas l’incident si une tâche planifiée ou un accès cloud peut le recréer. Remonter à l’appel API, au jeton utilisé et au manifeste. Examiner les autres régions, projets et abonnements accessibles. Le surcoût aide à mesurer l’impact, mais ne dit pas à lui seul si des secrets ou des données ont aussi été consultés.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape
Identité compromiseService account
API KubernetesRBAC et admission
Workload job-xCalcul consommé
Supervision / coûtMesure d’impact
  1. Action

    Création du pod

    Identité compromise vers API Kubernetes

    Trace audit API

  2. Action

    Admission et démarrage

    API Kubernetes vers Workload job-x

    Trace UID et digest

  3. Action sur place

    Calcul intensif

    Workload job-x

    Trace 7,8 cœurs

  4. Action

    Métriques et sortie réseau

    Workload job-x vers Supervision / coût

    Trace durée et destination

  5. Action

    Identité créatrice

    API Kubernetes vers Supervision / coût

    Trace service account

  6. Action

    Suspension du contrôleur

    Supervision / coût vers API Kubernetes

    Trace recréation empêchée

  7. Refus / blocage

    Essai après correction RBAC

    Identité compromise vers API Kubernetes

    Trace création refusée

Comment repérer cette attaque

Indices à rechercher

Repérer les déploiements ou images non prévus, la consommation durable de ressources hors des travaux attendus, les destinations réseau inhabituelles et les tâches de relance.

Éléments à croiser

Relier la création autorisée par l’API au compte de service, au pod réellement lancé et au digest exécuté. Vérifier ensuite la hausse de CPU et les connexions pendant la vie de ce pod.

Limites de l’interprétation

Un calcul scientifique peut consommer les mêmes ressources. Il faut établir que le workload et son déploiement ne sont pas autorisés ; une facture seule ne désigne pas le processus responsable.

Comment réagir

Suspendre le contrôleur à l’origine du workload, révoquer l’identité compromise et corriger RBAC/admission. Conserver les manifests et audits avant suppression. Vérifier les autres ressources créées, régions cloud et mécanismes de facturation concernés.

Vérifier la correction

Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.

  1. Vérifier qu’un service account applicatif ne peut créer de workload hors de son périmètre.
  2. Tester que la suspension du contrôleur empêche la recréation du pod.
  3. Mesurer l’effet des quotas sur un batch légitime et confirmer le retour à la consommation attendue.

À vous de raisonner

Un conteneur suspect est supprimé puis réapparaît. Quelle chaîne devez-vous examiner au lieu de le supprimer en boucle ?

Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Remontez au contrôleur ou à la tâche planifiée, à l’appel API et au compte qui l’a créé. Traitez cet accès et la configuration qui recrée la charge. Examinez les limites et quotas : une faible demande de CPU ne constitue pas un plafond de consommation.

Consulter les détails techniques

Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.

Lire les extraits commentés — reconstitution fictive

Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.

cpu_cores
Mesure issue de la supervision dans le cas, absente d’un événement d’audit de l’API.
approved_job=none
Résultat de comparaison avec les déploiements approuvés, pas un verdict automatique de Kubernetes.

Workload, identité et réseau

Journal

Vue normalisée de sources distinctes ; une métrique CPU ne révèle pas à elle seule le type de calcul.

audit verb=create resource=pods namespace=jobs user=system:serviceaccount:web:runner
object pod=job-x image=registry.example/worker@sha256:DEMO privileged=false
metrics pod=job-x cpu_cores=7.8 requested_cpu=0.1 memory_mib=340
egress pod=job-x destination=pool.example port=443
inventory approved_job=none cost_delta_daily=+180
Préparer une collecte dans votre environnement

Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.

  1. Kubernetes — audit de l’API

    Où les trouver
    Dans le backend d’audit du plan de contrôle : fichier désigné par --audit-log-path ou collecteur webhook ; pour un cluster géré, demander l’export à l’opérateur.
    Quoi relever
    Chercher la création du pod ou de son contrôleur : user.username, verb, objectRef, responseStatus et auditID. Le corps contenant l’image n’est disponible que si le niveau d’audit le conserve.
    Accès et prérequis
    Une politique d’audit et un backend doivent être configurés. Le niveau de journalisation détermine les détails conservés ; les logs stdout d’un conteneur ne remplacent pas cet audit.
    Documentation : Kubernetes — audit de l’API

  2. Sonde réseau Zeek — conn.log

    Où les trouver
    Sur une sonde déjà placée sur le trajet du trafic, ou dans le collecteur de ses journaux conn.log. Identifier le point d’observation, notamment avant ou après traduction d’adresses.
    Quoi relever
    Chercher les destinations contactées depuis le nœud ou le pod selon le point de capture. Une adresse de pool présumée doit être corroborée ; le port 443 seul ne renseigne pas l’usage.
    Accès et prérequis
    La sonde doit avoir vu le trafic. uid, adresses, ports, orig_bytes et resp_bytes décrivent les échanges observés ; les octets réseau ne sont pas le contenu d’un document ni son destinataire humain.
    Documentation : Sonde réseau Zeek — conn.log

  3. Prometheus — séries de mesures

    Où les trouver
    Dans l’interface de requêtes Prometheus ou les tableaux Grafana qui l’interrogent : choisir la période, les métriques exposées et les étiquettes de l’instance, route ou pod concerné.
    Quoi relever
    Comparer CPU consommé, ressources demandées et historique du workload si ces métriques sont exportées ; dans le registre, retrouver séparément l’image et son digest. Une mesure de consommation ne révèle pas qui a créé le pod.
    Accès et prérequis
    Un exportateur et une collecte doivent avoir existé. Les noms des métriques dépendent de l’instrumentation ; une série de mesures n’est pas un journal de requêtes individuelles.
    Documentation : Prometheus — séries de mesures

Dans l’histoire des cyberattaques

Groupes et campagnes documentés

1 repère

Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.

  1. à
    GroupeTeamTNT

    Des ressources cloud utilisées pour miner

    Unit 42 documente le vol d’identifiants cloud et le déploiement de mineurs de cryptomonnaie dans des environnements compromis. Le détournement porte à la fois sur l’accès aux ressources et sur la puissance de calcul facturée à la victime.

    Ce qu’établit la source. Campagnes attribuées à TeamTNT par Unit 42. Les chercheurs distinguent les identifiants recherchés par les outils et les usages qu’ils ont effectivement observés.

    Consulter le rapport TeamTNT Operations Actively Enumerating Cloud Environments

    Palo Alto Networks Unit 42 · Publié le

    Également dans ce cas :Détournement de ressources cloud

Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.

Si vous pensez être concerné

  1. Identifiez et arrêtez les charges non autorisées selon la procédure d’incident.
  2. Révoquez les clés ou accès compromis avant de recréer les ressources.
  3. Examinez la facturation et les autres actions réalisées avec les mêmes permissions.

Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

Pour relier les mécanismes

Détournement de ressources cloud ↗Exploitation de vulnérabilités ↗Intrusion dans un système informatique ↗Toutes les fiches ECRAN →