Cybersecurity-onderzoekers hebben een nieuwe cryptojacking-campagne ontdekt die zich richt op de Docker Engine API met als doel de instanties te coöpteren om zich aan te sluiten bij een kwaadaardige Docker Swarm die wordt gecontroleerd door de bedreigingsacteur.
Hierdoor konden de aanvallers “de orkestratiefuncties van Docker Swarm gebruiken voor command-and-control (C2) doeleinden”, zeiden Datadog-onderzoekers Matt Muir en Andy Giron in een analyse.
De aanvallen maken gebruik van Docker voor initiële toegang om een cryptocurrency-miner in te zetten op aangetaste containers, terwijl ook extra payloads worden opgehaald en uitgevoerd die verantwoordelijk zijn voor het uitvoeren van laterale bewegingen naar gerelateerde hosts die Docker, Kubernetes of SSH draaien.
Concreet gaat het hierbij om het identificeren van niet-geverifieerde en blootgestelde Docker API-eindpunten met behulp van internetscantools, zoals masscan en ZGrab.
Op kwetsbare eindpunten wordt de Docker API gebruikt om een Alpine-container te spawnen en vervolgens een initialisatie-shellscript (init.sh) op te halen van een externe server (“solscan(.)live”) die op zijn beurt controleert of deze draait als de rootgebruiker en tools zoals curl en wget worden geïnstalleerd voordat de XMRig-mijnwerker wordt gedownload.
Net als andere cryptojacking-campagnes maakt het gebruik van de libprocesshider rootkit om het kwaadaardige miner-proces voor de gebruiker te verbergen bij het uitvoeren van procesopsommingstools zoals top en ps.
Het shellscript is ook ontworpen om drie andere shellscripts – kube.lateral.sh, spread_docker_local.sh en spread_ssh.sh – op te halen van dezelfde server voor laterale verplaatsing naar Docker-, Kubernetes- en SSH-eindpunten op het netwerk.
Spread_docker_local.sh “gebruikt masscan en zgrab om dezelfde LAN-bereiken (…) te scannen naar knooppunten met poorten 2375, 2376, 2377, 4244 en 4243 open”, aldus de onderzoekers. “Deze poorten zijn gekoppeld aan Docker Engine of Docker Swarm.”
“Voor alle IP’s die worden ontdekt terwijl de doelpoorten open zijn, probeert de malware een nieuwe container te spawnen met de naam alpine. Deze container is gebaseerd op een afbeelding met de naam upspin, gehost op Docker Hub door de gebruiker nmlmweb3.”
De upspin-image is ontworpen om het bovengenoemde init.sh-script uit te voeren, waardoor de malware van de groep zich op een wormachtige manier kan verspreiden naar andere Docker-hosts.
Bovendien is de Docker-afbeeldingstag die wordt gebruikt om de afbeelding uit Docker Hub op te halen, gespecificeerd in een tekstbestand dat wordt gehost op de C2-server, waardoor de bedreigingsactoren gemakkelijk kunnen herstellen van mogelijke verwijderingen door eenvoudigweg de bestandsinhoud te wijzigen zodat deze naar een andere locatie verwijst. containerafbeelding.
Het derde shellscript, spread_ssh.sh, kan SSH-servers compromitteren, maar ook een SSH-sleutel en een nieuwe gebruiker met de naam ftp toevoegen waarmee de bedreigingsactoren op afstand verbinding kunnen maken met de hosts en permanente toegang kunnen behouden.
Het zoekt ook naar verschillende referentiebestanden gerelateerd aan SSH, Amazon Web Services (AWS), Google Cloud en Samba in hardgecodeerde bestandspaden binnen de GitHub Codespaces-omgeving (dwz de map “/home/codespace/”), en als gevonden, uploadt ze naar de C2-server.
In de laatste fase voeren zowel de Kubernetes- als de SSH-payloads voor laterale beweging een ander shellscript uit, genaamd setup_mr.sh, dat de cryptocurrency-mijnwerker ophaalt en start.
Datadog zei dat het ook drie andere scripts ontdekte die op de C2-server werden gehost:
- ar.sh, een variant van init.sh die iptables-regels wijzigt en logs en cron-jobs wist om detectie te omzeilen
- TDGINIT.sh, dat scantools downloadt en een kwaadaardige container op elke geïdentificeerde Docker-host plaatst
- pdflushs.sh, dat een persistente achterdeur installeert door een door bedreigingsactor gecontroleerde SSH-sleutel toe te voegen aan het bestand /root/.ssh/authorized_keys
TDGINIT.sh valt ook op vanwege de manipulatie van Docker Swarm door de host te dwingen elke bestaande zwerm waar hij deel van uitmaakt te verlaten en deze toe te voegen aan een nieuwe zwerm onder controle van de aanvaller.
“Hierdoor kan de bedreigingsactoren hun controle over meerdere Docker-instanties op een gecoördineerde manier uitbreiden, waardoor gecompromitteerde systemen effectief in een botnet worden omgezet voor verdere exploitatie”, aldus de onderzoekers.
Het is momenteel niet duidelijk wie er achter de aanvalscampagne zit, hoewel de tactieken, technieken en procedures overlap vertoonden met die van een bekende dreigingsgroep die bekend staat als TeamTNT.
“Deze campagne laat zien dat diensten als Docker en Kubernetes vruchtbaar blijven voor bedreigingsactoren die op grote schaal cryptojacking uitvoeren”, aldus Datadog.
“De campagne is gebaseerd op het feit dat Docker API-eindpunten zonder authenticatie aan het internet worden blootgesteld. Het vermogen van de malware om zich snel te verspreiden betekent dat zelfs als de kansen op initiële toegang relatief klein zijn, de beloningen hoog genoeg zijn om cloudgerichte malwaregroepen voldoende gemotiveerd te houden om doorgaan met het uitvoeren van deze aanvallen.”
De ontwikkeling komt op het moment dat Elastic Security Labs licht werpt op een geavanceerde Linux-malwarecampagne die zich richt op kwetsbare Apache-servers om persistentie via GSocket tot stand te brengen en malwarefamilies zoals Kaiji en RUDEDEVIL (ook bekend als Lucifer) in te zetten die gedistribueerde denial-of-service (DDoS) en cryptocurrency mogelijk maken. mijnbouw, respectievelijk.
“De REF6138-campagne omvatte cryptomining, DDoS-aanvallen en mogelijk witwassen van geld via gok-API’s, waarbij het gebruik van evoluerende malware en heimelijke communicatiekanalen door de aanvallers werd benadrukt”, aldus onderzoekers Remco Sprooten en Ruben Groenewoud.
