Comment
Author: Admin | 2025-04-28
Pty3 was executed right after it was dropped on the Pod. To follow what pty3 is doing, we used the open source tool, Sysdig Inspect, to visualize system calls.Let’s see the activities performed by the malware in detail.#3.1 Checking network tools running in the PodAs the first action, the malware checks if network dump tools are in execution in the Pod. The two binaries checked are tcpdump and strace.This is a typical process to discover and identify new targets to infect with the malware, using system binaries in the process or GTFOBins.#3.2 Persistence phaseTo make sure the Muhstik malware will be rerun if the process dies or the machine is restarted, the malware needs to spread itself in the Pod and perform some actions.In this case, the pty3 binary performed special measures to achieve persistence in the machine.First of all, the pty3 started copying itself in different directories for persistence purpose:/tmp/pty3/dev/shm/pty3/var/tmp/pty3/var/lock/pty3/var/run/pty3Then, it tried to execute crontab, although the crontab binary wasn’t available inside the Pod. It succeeded instead of executing persistence via /etc/inittab, adding the following lines.Using the respawn function ensures that if the process dies, it will be respawned automatically without losing the compromised host/Pod.The Muhstik malware also added itself in the rc.local file for the same purposes as shown in the following screenshot.#3.3 Establishing C&C communication with the BotnetAt this point, the malware needs to communicate and send instructions to the zombie Pod. In the following image, we can see the PING / PONG communication between the process ggop6b5pqkmfrfd and the webserver.It resembles other malware and C&C protocols, capturing information about the target and communicating back with updated attack payloads.Let’s stop for a moment to summarize the activities done so far by the malware dropped:Spawn a new process to connect to the botnet.Check tools running inside the host/Pod to discover new Pods to infect.Replicate itself in different locations for persistence.Run crontab by creating and editing /etc/inittab to get persistence.#4 Crypto miners in actionThe goal of the Muhstik botnet, after infecting the victim, is to monetize the resources it infects. Muhstik malware downloads two binaries in the Kubernetes Pods it controls, and starts cryptomining.#4.1 xmrig64 binary downloaded and executed on the PodOnce the malware infection is complete, after having connected the Pod to the botnet, the attacker uploaded and executed the xmrig64 binary using the PHP web shell.From the screen below, using Inspect, we can detect the miner connecting to the IP pool 186.86.148.14 with port 8081 and start sharing information.#4.2 xmra64 binary behaviorUsing the ggop6b5pqkmfrfd process running in the Pod, the Muhstik botnet downloaded the crypto miner binary xmra64 from the IP 178.62.105.90 executing the wget and curl commands.Once downloaded, ggop6b5pqkmfrfd prepared the binary for execution. We can see how it used chmod to set the execution bit.We uploaded this xmra64 binary again and the report was very similar. It is a well-known crypto miner.Two crypto miner pools were specified when launching the crypto miner binary:185.165.171.78185.86.148.14From the following screen, we can see the miner started communicating with the
Add Comment