Programmes malveillants

Particuliers et entreprises

Minage clandestin

Cryptojacking

Quelqu’un utilise la puissance de vos machines pour gagner de l’argent à vos frais.

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

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

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 utilise vos ressources sans autorisation pour miner des cryptoactifs. Il peut toucher un ordinateur, un serveur, un conteneur ou un compte cloud. Vous pouvez subir une hausse de consommation, des ralentissements ou une interruption de service. L’accès utilisé par l’attaquant reste aussi un problème : arrêter le calcul ne suffit pas si sa clé d’accès ou la faille fonctionne encore.

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.

Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver 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.

Un point à vérifierUne idée reçue à corriger

Un logiciel de minage découvert peut révéler une intrusion plus étendue que le seul ralentissement de la machine.

À vous de décider

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

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Il faut retrouver ce qui relance les machines : une tâche planifiée, un contrôleur ou un accès cloud piraté. Arrêter la première machine ne supprime pas ce mécanisme ni les droits qui le permettent.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

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

Le compte Kubernetes web:runner lance une tâche avec une image non approuvée. Le conteneur utilise 7,8 cœurs et joint une destination associée au calcul distribué. L’ensemble fait soupçonner un détournement de ressources. Une charge élevée seule ne suffirait pas : un calcul scientifique ou une compilation peut aussi occuper 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.

Quelles informations comparer

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.

Ce que ces indices ne permettent pas de conclure

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

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

  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 ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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

Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.

  1. à
    GroupeTeamTNT

    Des ressources cloud utilisées pour miner

    Unit 42 décrit le vol d’identifiants cloud puis l’installation de mineurs de cryptomonnaie dans les systèmes compromis. Les attaquants détournent les accès et utilisent une puissance de calcul dont la victime paie la facture.

    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

Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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

Sur des sujets proches

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