Docker-Bilder von TeamTNT vom Netz nehmen
25. Mai 2021
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 |