Krypto-Mining im kompromittierten AWS-Konto: schnell handeln

Kurzfassung. Krypto-Mining ist meist der letzte Schritt eines Einbruchs, nicht der erste. Bestätigen Sie es anhand von RunInstances mit GPU- oder großen Instanztypen in Regionen, die Sie nicht nutzen – oft nach RequestServiceQuotaIncrease, CreateKeyPair und einer zu 0.0.0.0/0 geöffneten Sicherheitsgruppe – und anschließend anhand von VPC Flow Logs, die langlebige ausgehende Verbindungen zu Ports von Mining-Pools zeigen. Dämmen Sie in jeder Region ein (erst Snapshot, dann beenden), deaktivieren Sie die Anmeldedaten, mit denen die Instanzen gestartet wurden, und arbeiten Sie sich rückwärts bis zum Einstiegspunkt vor – derselbe Schlüssel hat vermutlich auch einen Backdoor-Benutzer angelegt.

Ein Kostenalarm an einem Sonntagmorgen – so werden viele AWS-Kompromittierungen entdeckt. Mining ist von Natur aus laut: Es braucht Rechenleistung, viel davon, und das so lange wie möglich. MITRE ATT&CK ordnet es unter T1496 Resource Hijacking ein, mit T1496.001 Compute Hijacking als Untertechnik.

So sieht Mining in CloudTrail aus

Die Startsequenz ist kurz und wiederholt sich:

Es gibt Varianten – ECS- oder Fargate-Tasks, Lambda, SageMaker, Batch –, doch EC2 in einer ungenutzten Region bleibt der Klassiker.

Zwei Details, die Sie kennen sollten:

• RunInstances speichert die userData in CloudTrail als <sensitiveDataRemoved>; das Installationsskript des Miners sehen Sie dort also nicht. Holen Sie es von der Instanz (DescribeInstanceAttribute --attribute userData), bevor Sie sie beenden.
• Regionen, die nach dem 20. März 2019 eingeführt wurden, sind Opt-in-Regionen und standardmäßig deaktiviert (AWS-Dokumentation); ein EnableRegion-Aufruf durch den Angreifer ist für sich schon ein Signal.

So sieht Mining im Netzwerk aus

Mit VPC Flow Logs auf der VPC des Angreifers – oft die Standard-VPC der ungenutzten Region, in der niemand Flow Logs aktiviert hat, also prüfen Sie das – zeigt sich Mining so:

• gleichmäßige, langlebige ausgehende Verbindungen von jeder neuen Instanz zu denselben wenigen öffentlichen Adressen;
• auf Pool-Ports, die Mining-Software üblicherweise nutzt (3333, 4444, 5555, 7777, 14444 und ähnliche), wobei es auch Pools auf 443 gibt;
• kleine, regelmäßige Byte-Mengen in beide Richtungen (Work Shares), keine Massenübertragungen;
• kurz nach dem Start eine eingehende SSH-Verbindung von der Adresse des Angreifers.

GuardDuty hat eigene Finding-Typen dafür, sofern es in dieser Region aktiviert ist, etwa CryptoCurrency:EC2/BitcoinTool.B und CryptoCurrency:EC2/BitcoinTool.B!DNS (EC2-Finding-Typen). Angreifer wissen das – deshalb geht dem Start häufig das Löschen der Detektoren voraus.

Eindämmung, in dieser Reihenfolge

1. Deaktivieren Sie die Anmeldedaten, die RunInstances aufgerufen haben (Schlüssel oder Rollensitzung). Sonst startet der Angreifer neue Instanzen so schnell, wie Sie sie beenden.
2. Inventarisieren Sie jede Region. aws ec2 describe-instances pro Region oder die EC2 Global View in der Konsole. Beziehen Sie Spot-Anfragen, Launch Templates, Auto-Scaling-Gruppen, ECS-Services und Lambda-Funktionen ein, die im fraglichen Zeitfenster angelegt wurden.
3. Erst sichern, dann beenden. Erstellen Sie einen Snapshot des Volumes einer repräsentativen Instanz und sichern Sie deren User Data für die Fallakte; beenden Sie den Rest.
4. Bauen Sie das Gerüst ab. Schlüsselpaare, Sicherheitsgruppen, Launch Templates; ziehen Sie offene Kontingentanfragen zurück, die nicht von Ihnen stammen.
5. Wenden Sie sich an den AWS Support wegen der unbefugten Nutzung und der Kosten. Die re:Post-Hinweise zu unbefugter Aktivität beschreiben, was AWS von Ihnen erwartet, bevor Sie anfragen.
6. Sperren Sie ungenutzte Regionen mit einer Service Control Policy, wenn Sie AWS Organizations einsetzen.

Den Schaden abschätzen

Die Finanzabteilung wird nach einer Zahl fragen, bevor Sie mit der Eindämmung fertig sind. Leiten Sie sie aus den Logs ab, statt auf die Rechnung zu warten:

• Instanzstunden. Für jede Instanz liefert das RunInstances-Ereignis Startzeit und Typ; das TerminateInstances-Ereignis (Ihres) liefert das Ende. Multiplizieren Sie mit dem On-Demand-Preis des Typs in dieser Region.
• Alles andere. Ausgehender Datentransfer, EBS-Volumes, Elastic IPs und alles, was im Zeitfenster angelegt wurde. Der Cost Explorer, gruppiert nach Region und Dienst und gefiltert auf die Tage des Vorfalls, zeigt, was den Logs womöglich entgangen ist.
• Offene Anfragen. Eine Kontingenterhöhung, die erst nach der Eindämmung genehmigt wird, lässt sich erneut ausnutzen, wenn die Anmeldedaten nicht überall widerrufen wurden.

Bewahren Sie diese Zahlen mitsamt ihren Quellen in der Fallakte auf; der AWS Support fragt nach Ressourcen-IDs und Zeitpunkten, wenn Sie die unbefugten Kosten melden.

Rückwärts bis zum Einstiegspunkt

Die Instanzen sind nur das Symptom. Pivotieren Sie auf den Principal in den RunInstances-Ereignissen:

• War es ein Benutzer, den der Angreifer angelegt hat? Dann suchen Sie dessen CreateUser und die Anmeldedaten, mit denen er erstellt wurde – siehe IAM-Persistenz und Rechteausweitung.
• War es ein langfristiger Schlüssel, der von einer neuen Adresse aus verwendet wurde? Dann handelt es sich um die Untersuchung eines geleakten Zugriffsschlüssels.
• War es eine Instanzrolle? Dann erfolgte der Einstieg über einen Workload, und die Untersuchung geht auf dem Host weiter (bei EKS auch im Kubernetes-Audit-Log – kubernetesforensics.com).

Prüfen Sie außerdem, was derselbe Principal vor dem Start der Instanzen sonst noch getan hat: Mining geht oft mit Datendiebstahl einher, denn der Angreifer hat den Aufwand für den Einbruch bereits investiert.

Im Analyzer

AWS Forensics markiert Starts von GPU-Instanzen (Familien p und g) pro Region, Anfragen zur Kontingenterhöhung, Aktivität in einer Region, die am ersten Tag der Logs keine Aktivität hatte, zum Internet geöffnete Sicherheitsgruppen, erstellte Schlüsselpaare sowie – aus den Flow Logs – akzeptierte ausgehende Verbindungen zu bekannten Pool-Ports. Die Checkliste im Tab „Bereinigung“ führt die zu beendenden Instanz-IDs und Regionen auf. Das fiktive Fallbeispiel endet genau mit diesem Muster.

Weiterführende Beiträge

• Analyse von VPC Flow Logs bei Exfiltration und Mining
• AWS Incident Response: Untersuchung eines kompromittierten Kontos