Minage de cryptomonnaie sur un compte AWS : réagir vite
Instances GPU, facture qui explose, région inutilisée : confirmer un minage sur AWS via CloudTrail et les flow logs, le contenir et trouver le point d'entrée.
En bref. Le minage de cryptomonnaie est généralement la dernière étape d'une intrusion, pas la première. Confirmez-le par des RunInstances de types d'instances GPU ou de grande taille dans des régions que vous n'utilisez pas, souvent précédés de RequestServiceQuotaIncrease, CreateKeyPair et d'un groupe de sécurité ouvert sur 0.0.0.0/0 ; puis par des VPC Flow Logs montrant des connexions sortantes de longue durée vers des ports de pools de minage. Confinez dans toutes les régions (snapshot, puis arrêt définitif), désactivez l'identifiant qui a lancé les instances et remontez jusqu'au point d'entrée : la même clé a probablement aussi créé un utilisateur backdoor.
Une alerte de coûts un dimanche matin : c'est ainsi que l'on découvre bon nombre de compromissions AWS. Le minage est bruyant par nature : il lui faut de la puissance de calcul, beaucoup, et le plus longtemps possible. MITRE ATT&CK le classe sous T1496 Resource Hijacking, avec T1496.001 Compute Hijacking comme sous-technique.
À quoi ressemble le minage dans CloudTrail
La séquence de lancement est courte et répétitive :
| Ordre | Événement | Ce qu'il faut lire |
|---|---|---|
| 1 | ec2:DescribeRegions, DescribeInstances sur plusieurs régions | L'attaquant cherche des régions inutilisées |
| 2 | servicequotas:RequestServiceQuotaIncrease | quotaCode pour les familles vCPU / GPU, desiredValue |
| 3 | ec2:CreateKeyPair ou ImportKeyPair | Un accès SSH à ce qui va suivre |
| 4 | ec2:CreateSecurityGroup, AuthorizeSecurityGroupIngress | Port 22 ouvert sur 0.0.0.0/0 |
| 5 | ec2:RunInstances | instanceType (familles p*, g*, ou tout simplement le plus gros type disponible), minCount, userData |
| 6 | Parfois ec2:RequestSpotInstances, CreateLaunchTemplate, CreateAutoScalingGroup | Montée en charge et résilience |
Il existe des variantes (tâches ECS ou Fargate, Lambda, SageMaker, Batch), mais EC2 dans une région inutilisée reste le grand classique.
Deux détails à connaître :
RunInstancesenregistreuserDatasous la forme<sensitiveDataRemoved>dans CloudTrail : vous n'y verrez donc pas le script d'installation du mineur. Récupérez-le depuis l'instance (DescribeInstanceAttribute --attribute userData) avant de la supprimer.- Les régions lancées après le 20 mars 2019 sont à activation volontaire (opt-in) et désactivées par défaut (documentation AWS) ; un appel
EnableRegionémis par l'attaquant est en soi un signal.
À quoi ressemble le minage sur le réseau
Avec des VPC Flow Logs sur le VPC de l'attaquant (souvent le VPC par défaut de la région inutilisée, où personne n'a activé les flow logs : vérifiez), le minage se manifeste par :
- des connexions sortantes stables et de longue durée depuis chaque nouvelle instance vers les mêmes quelques adresses publiques ;
- sur des ports de pools couramment utilisés par les logiciels de minage (3333, 4444, 5555, 7777, 14444 et similaires), même si des pools sur le port 443 existent ;
- de petits volumes réguliers dans les deux sens (les parts de travail, ou shares), et non des transferts massifs ;
- une connexion SSH entrante depuis l'adresse de l'attaquant peu après le démarrage.
GuardDuty dispose de types de détections dédiés lorsqu'il est activé dans la région concernée, comme CryptoCurrency:EC2/BitcoinTool.B et CryptoCurrency:EC2/BitcoinTool.B!DNS (types de détections EC2). Les attaquants le savent, c'est pourquoi la suppression des détecteurs précède souvent le lancement.
Le confinement, dans l'ordre
- Désactivez l'identifiant qui a appelé
RunInstances(clé ou session de rôle). Sinon, l'attaquant relance des instances aussi vite que vous les supprimez. - Inventoriez toutes les régions.
aws ec2 describe-instancesrégion par région, ou la vue globale EC2 (EC2 Global View) dans la console. Incluez les requêtes Spot, les modèles de lancement, les groupes Auto Scaling, les services ECS et les fonctions Lambda créés pendant la fenêtre de l'incident. - Préservez, puis supprimez. Faites un snapshot du volume d'une instance représentative et récupérez ses user data pour le dossier d'investigation ; supprimez le reste.
- Démontez l'échafaudage. Paires de clés, groupes de sécurité, modèles de lancement ; retirez les demandes de quota en attente que vous n'avez pas faites.
- Contactez le support AWS au sujet de l'utilisation et des frais non autorisés. Les recommandations re:Post sur l'activité non autorisée décrivent ce qu'AWS attend que vous ayez fait avant de le solliciter.
- Interdisez les régions inutilisées au moyen d'une stratégie de contrôle des services si vous utilisez AWS Organizations.
Estimer les dégâts
La direction financière vous demandera un chiffre avant même la fin du confinement. Construisez-le à partir des journaux plutôt que d'attendre la facture :
- Heures d'instance. Pour chaque instance, l'événement
RunInstancesdonne l'heure de lancement et le type ; l'événementTerminateInstances(le vôtre) donne la fin. Multipliez par le prix à la demande du type dans cette région. - Tout le reste. Transfert de données sortant, volumes EBS, adresses IP Elastic et tout ce qui a été créé pendant la fenêtre. Cost Explorer, regroupé par région et par service et filtré sur les jours de l'incident, montre ce que les journaux ont pu manquer.
- Les demandes en attente. Une augmentation de quota approuvée après le confinement peut être exploitée à nouveau si l'identifiant n'a pas été révoqué partout.
Conservez ces chiffres avec leurs sources dans le dossier d'investigation ; le support AWS vous demandera les identifiants de ressources et les horaires lorsque vous signalerez les frais non autorisés.
Remonter jusqu'au point d'entrée
Les instances ne sont que le symptôme. Pivotez sur le principal des événements RunInstances :
- S'agit-il d'un utilisateur créé par l'attaquant ? Retrouvez alors son
CreateUseret l'identifiant qui l'a créé ; voir persistance IAM et élévation de privilèges. - S'agit-il d'une clé à long terme utilisée depuis une nouvelle adresse ? C'est alors une investigation sur une clé d'accès divulguée.
- S'agit-il d'un rôle d'instance ? Le point d'entrée était alors une charge de travail, et l'investigation se poursuit sur l'hôte (et, pour EKS, dans le journal d'audit Kubernetes : kubernetesforensics.com).
Vérifiez aussi ce que le même principal a fait avant de lancer les instances : le minage va souvent de pair avec un vol de données, car l'attaquant a déjà fait l'effort d'entrer.
Dans l'analyseur
AWS Forensics signale les lancements d'instances GPU (familles p et g) par région, les demandes d'augmentation de quota, l'activité dans une région sans activité pendant le premier jour couvert par les journaux, les groupes de sécurité ouverts sur Internet, les paires de clés créées et, à partir des flow logs, les connexions sortantes acceptées vers des ports de pools connus. La checklist de remédiation liste les identifiants d'instances et les régions à nettoyer. Le déroulé d'un incident fictif se termine précisément sur ce schéma.