Jared Stroud
Cloud Security Researcher – Lacework Labs 

Die Erkenntnisse

• TeamTNT zielt auf ungeschützte Docker-API, um bösartige Bilder zu verbreiten.
• Docker-Bilder, die Malware von TeamTNT enthalten, werden mittels Kontoübernahmen in öffentlichen Docker-Repositories gehostet. 
• TeamTNT nutzt ungeschützte Geheimnisse aus dem Docker-Hub in GitHub aus, um bösartige Docker-Bilder zu verbreiten.
• Die folgenden MITRE ATT&ACK-Techniken wurden beobachtet: Deploy Container (T1610), User Execution: Malicious Image (T1204.003), Unsecured Credentials: Credentials In Files (T1552.002), Implant Internal Image (T1525) und Valid Accounts: Cloud Accounts (T1078.004).

 

Zusammenfassung

TeamTNT verbreitete unter Verwendung eines legitimen Docker-Hub-Kontos bösartige Bilder auf Docker Hub. Die Zugangsdaten für das Docker-Hub-Konto wurden versehentlich einem öffentlichen GitHub-Repository übergeben, wo sich TeamTNT unserer Einschätzung nach erstmals Zugang zu dem Konto verschaffte. Lacework Labs benachrichtigte Docker Security und den Besitzer des anvisierten Kontos (megawebmaster), der schnell handelte und die von TeamTNT verbreiteten Docker-Container aus Docker Hub entfernte.

 

Gefangen im Honeypot

Das Forschungsteam von Lacework Labs setzt eine Reihe verschiedener Honeypots ein, um Daten über gängige Services zu sammeln, die für Cloud-Umgebungen bereitgestellt werden. Dieser "Farm-to-Table"-Ansatz ermöglicht es uns, auf natürliche Weise opportunistische Angriffe gegen ungeschützte Mock-Infrastruktur zurückzuverfolgen. Der Docker-API-Honeypot von Lacework Labs fing die folgende Anfrage ab, bei der die Erstellung eines Container-Bilds mit dem Namen "dockgeddon" über Megawebmaster-Konto aufdeckte (T1610). 

 

Docker Honeypot – Anfrage zur Erstellung von Containern

Bei der Inspektion dieses Docker-Bilds wurden TeamTNT-Programme in Containern auf dem Docker-Hub-Konto „Megawebmaster“ identifiziert. Im obigen Bild rot hervorgehoben sind das entsprechende Bild (megawebmaster/dockgeddon) sowie die Host-Mount-Bind-Konfiguration, die das Stammverzeichnis des Hosts innerhalb des Containers in /host einbindet. Der Netzwerkmodus wird auf den Host gesetzt, und der Container versucht, als privilegierter Container eingesetzt zu werden. Das Docker-Hub-Konto von MegawebMaster enthält zahlreiche öffentliche Bilder, von denen fünf TeamTNT-Programme mit einer beträchtlichen Anzahl von Downloads aufweisen. Zu diesen fünf Bildern gehören dockgeddon, docker, tornadopw und dcounter (T1204.003).

Hosting bösartiger Bilder auf dem Docker Hub

 

Unter dem Benutzernamen „Megawebmaster“ wurde ein GitHub-Konto entdeckt, das eine Konfigurationsdatei mit Docker-Hub-Geheimnissen enthielt (T1552.001). Es wird vermutet, dass TeamTNT diese Konfigurationsdatei nutzte, um bösartige Docker-Bilder auf das Docker-Hub-Konto dieses Benutzers hochzuladen (T1525). Lacework Labs kontaktierte den Besitzer des GitHub-Kontos sowie Docker Security, um sowohl die ungeschützten Docker-Zugangsdaten als auch die bösartigen Docker-Bilder zu entfernen.

 

Erkunden der Docker-Bilder

Das Open-Source-Programm „Dive“ erlaubt die Untersuchung jeder einzelnen Ebene eines Docker-Bilds. Dies ermöglicht eine schnelle Triage, um zu verstehen, welche Dateien zu welcher Ebene hinzugefügt wurden. Für jedes unten aufgeführte Docker-Bild nutzte Lacework Labs Dive, um die gewünschten Dateien zu identifizieren, und kopierte dann die Dateien aus dem Docker-Container, um weitere Triagen durchzuführen.

 

Docker-Bild – Dockgeddon

Im „dockgeddon“-Bild wurden drei bösartige Programme identifiziert. Dazu gehörten eine Variante des IRC-Bots Tsunami (TNTfeatB0rg), ein Banner-Grabbing-Programm (zgrab) sowie ihr Verbreitungsprogramm init.sh. Das Bild unten zeigt das Dive-Programm, das diese Dateien und deren Lage im Docker-Bild anzeigt.

Dive inspiziert ein Docker-Bild

Nachdem die Binärdatei TNTFeatB0RG aus dem Docker-Bild extrahiert und in Ghidra analysiert wurde, konnten bekannte IPs und Domains in Verbindung mit TeamTNT identifiziert werden. 

Ghidra-Analyse von TNTFeatB0RG

 

Zusätzliche Änderungen an TNTFeatB0RG beinhalteten die Ausführung von base64-Befehlen innerhalb der Binärdatei über Funktionsaufrufe (system). Bei der eingebetteten base64-Payload handelt es sich um ein Bash-Skript, mit dem AWS-Zugangsdaten vom AWS-Metadatenservice gestohlen werden, der unter 169.254.169.254 gehostet wird (T1078.004). 

Ghidra – Ausführung von base64 

 

Eingebettetes Base64-Secret-Stealer-Skript für AWS 

 

Das Programm init.sh lädt XMRig herunter, um mit dem Mining von Monero auf dem Opfer-Host zu beginnen. Die zugehörige Wallet zeigt mehrere Arbeiter, die derzeit eingesetzt werden, um das illegale Mining von TeamTNT voranzubringen. 

Status der Monero-Wallet

Docker-Bild – „small“

Das Docker-Bild mit dem Namen „small“ enthielt die drei Dateien „dockerd“, „kernel“ und „init.sh“. Bei der Binärdatei „kernel“ handelte es sich um eine weitere Tsunami-Variante, die sich mit den gleichen IRC-Servern von TeamTNT in Verbindung setzte, die auch in Dockgeddon zu sehen waren. Diese Variante gehört jedoch zum Kanal „#DockerAPI“, während Dockgeddon Teil des IRC-Kanals „#masspwn“ ist. Beide teilen den Prozessnamen „kworker/08:15-events”

 

Ghidra-Dekompilierung des Docker-Bilds „dockgeddon“ im Tsunami IRC-Bot (links) und des Docker-Bilds „small“ im Tsunami IRC-Bot (rechts) 

Ein weiterer Unterschied der Tsunami-Variante im Vergleich zu Dockgeddon war das Fehlen von eingebetteten base64-Payloads. Die dekompilierte Ausgabe von Ghidra unten zeigt, wie sich die Tsunami-Varianten von TeamTNT unterscheiden. Diese kleinen Veränderungen an den Tsunami-Bots zeigen, wie TeamTNT seine TTPs kontinuierlich weiterentwickelt.

Ghidra – Unterschied der Hauptfunktion der Tsunami-Bots  

Bei der Binärdatei „dockerd“ handelt es sich um eine UPX-verpackte Ezuri-Binärdatei, die wiederum eine XMRig-Binärdatei herunterlädt. Diese läuft dann als „kworker/13:37“ und nutzt dieselbe Wallet, die sich im „dockgeddon“-Bild befindet.

XMRig-Konfiguration von TeamTNT

 

Das init.sh-Skript ist ein Wrapper für das Scope-Programm von WeaveWorks, das üblicherweise für die Verwaltung einer Container-Umgebung verwendet wird (T1613). Die Nutzung von Scope ermöglicht über die WeaveWorks-Benutzeroberfläche einen Fernzugriff auf die Umgebung des Opfers.

TeamTNT nutzt den Scope von WeaveWorks

Docker-Bild – „dcounter“

Im „dcounter“-Bild wurde nur ein Skript (init.sh) identifiziert. Dieses Skript nutzt den kostenlosen Service iplogger.org, der die Verfolgung von Endbenutzern ermöglicht, wenn diese auf eine bestimmte Ressource zugreifen. In diesem Szenario wird er von TeamTNT als Benachrichtigungsdienst genutzt. Jedes Mal, wenn ihr Docker-Container „dcounter“ ausgeführt wird, wird auf diese Ressource zugegriffen, wodurch die IP des Opfers aufgezeichnet wird. Darüber hinaus hostet die TeamTNT-Infrastruktur auch etwas, bei dem es sich nach Einschätzung der Forschungsteams von Lacework Labs um einen Endpunkt-Protokollierungsdienst an der IP-Adresse handelt, die in der Abbildung unten aufgeführt ist.

 

Tracking-Skript von TeamTNT

 

Docker-Bild – „tornado“

Das Docker-Bild „tornado“ enthält ein Skript mit dem Namen „tornado.sh“. Dieses Programm nutzt Massscan und Zgrab, um basierend auf dem Ziel-IP-Bereich und den Ports, die dem Container übergeben wurden, eine Erkundung durchzuführen. Falls eine Schlüsselphrase in „Home page – Select or create a notebook“, „Kubeflow Central Dashboard“, „Jupyter Lab“ oder „JupyterLab“ erkannt wird, filtert das Programm „jq“ die IP-Adresse dieser Übereinstimmungen heraus, die dann zu einem Array von „rndstr“ hinzugefügt werden. Die Ergebnisse dieser Daten werden dann an eine von TeamTNT kontrollierte IP gesendet. Lacework Labs bewertet diese Ergebnisse mit mittlerer bis hoher Sicherheit als Ziel für weitere Angriffe. 

Scanning-Skript von TeamTNT

Fazit

TeamTNT continues to target cloud infrastructure in order to gain access, perform Cryptojacking operations and exfiltrate cloud secrets. Ensuring cloud environments are not running exposed unauthenticated endpoints is critical in avoiding opportunistic attackers from gaining access to your environment. Understanding your deployed container/Kubernetes attack surface and cloud workloads attack surface is paramount in today’s changing cloud landscape. All IOCs can be found on the Lacework Labs GitHub. Also, please follow @LaceworkLabs Twitter  or LinkedIn to keep up with our latest research.

 

 

 

IOCs

 

File	Hash
tornado.sh	c8ed6a70790ae58a1e10debb92a9ec4f864153fc1599431fb8b3a03b7edc8641
x	e85ab365fe239373669c08ad9d18b1cae95565e6767415a51aacdb8abe7e2315
docker.sh	94da4e21def0c6390879a838b5e64b9edabd5d7cf525ec2edfbe478ce7b0b4a7
init.sh	d4c7ee2acd9b59c2add80cfb61e8efba663b7917537fa0f356b2545c43e956b4
TNTfeatB0rg	9504b74906cf2c4aba515de463f20c02107a00575658e4637ac838278440d1ae
init.sh	b8e4f8b3d43c7864ad1a05ff82612ac5721d1c62ef6a2c5fef82dc301a6f4e31
kernel	ea0ed7cbc0fefb534a26c6c6b8412c9fb843da8d09a507cbb160916eac25441b
dockerd	84078b10ad532834eb771231a068862182efb93ce1e4a8614dfca5ae3229ed94
init.sh	d0bc3b8a8a5da1d14dfb16297d825d7f40a065d64aae96645062905f4c90008e
wallet	46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCmAUrFd3H