Attackers Target Exposed Docker Remote API Servers With perfctl Malware
Summary:
Attackers are exploiting exposed Docker Remote API servers to deploy the perfctl malware, utilizing a structured attack flow that begins with probing the vulnerable server and ends with payload execution and persistence. The attack starts with the attacker identifying an exposed Docker Remote API server through a ping request. Once the server is located, the attacker creates a Docker container using the ubuntu image. This container is configured in privileged mode with pid mode: host, allowing the processes inside the container to share the host system's process ID namespace. This means that the container's processes can interact with the host's processes, significantly increasing the attack's impact by providing the attacker with access to the host system.
Once the container is set up, the attacker executes a Base64-encoded payload using Docker's Exec API. This payload has two main components. First, the attacker uses the nsenter command to escape the container by entering the namespaces of the host system's init process (PID 1), which grants access to the host's mount, UTS, IPC, network, and PID namespaces. This escape method effectively allows the attacker to operate as if they were running directly on the host system. The second component of the payload is a Base64-encoded script that, when decoded, performs several critical functions, such as checking for and preventing duplicate processes, creating a bash script named kubeupd in the /tmp directory, and setting environment variables. The script also includes a customized __curl function to download a malicious binary if curl or wget are unavailable. This binary, disguised as a PHP extension, is saved in the /tmp directory with the name httpd to avoid detection by file-based defenses.
The attacker further ensures persistence by setting up either a systemd service or a cron job. If systemd is running, the malware creates a service linked to multi-user.target. Otherwise, the fallback mechanism involves creating a cron job, making it more difficult to remove the malware. Additionally, the malware modifies the /bin/sh binary by replacing it with a custom version (kkbush), enabling privilege escalation and ensuring continued access. The original /bin/sh file is restored after the installation of the backdoor to reduce the chances of detection. The malware also monitors processes through the /proc/ directory and checks for active TCP connections on ports 44870 or 63582. If the malicious process is not detected, it will download the binary using the custom __curl function.
Security Officer Comments:
This attack uses a variety of evasion techniques, including the use of legitimate-sounding process names and the Tor network to reroute traffic, with a confirmed Tor relay node (192.121.108.237) identified in the network traffic. The combination of container escape, environment variable manipulation, and persistence strategies demonstrates the sophistication of the attack and the lengths attackers will go to remain undetected.
Suggested Corrections:
https://www.trendmicro.com/en_us/re...-docker-remote-api-servers-with-perfctl-.html
Attackers are exploiting exposed Docker Remote API servers to deploy the perfctl malware, utilizing a structured attack flow that begins with probing the vulnerable server and ends with payload execution and persistence. The attack starts with the attacker identifying an exposed Docker Remote API server through a ping request. Once the server is located, the attacker creates a Docker container using the ubuntu image. This container is configured in privileged mode with pid mode: host, allowing the processes inside the container to share the host system's process ID namespace. This means that the container's processes can interact with the host's processes, significantly increasing the attack's impact by providing the attacker with access to the host system.
Once the container is set up, the attacker executes a Base64-encoded payload using Docker's Exec API. This payload has two main components. First, the attacker uses the nsenter command to escape the container by entering the namespaces of the host system's init process (PID 1), which grants access to the host's mount, UTS, IPC, network, and PID namespaces. This escape method effectively allows the attacker to operate as if they were running directly on the host system. The second component of the payload is a Base64-encoded script that, when decoded, performs several critical functions, such as checking for and preventing duplicate processes, creating a bash script named kubeupd in the /tmp directory, and setting environment variables. The script also includes a customized __curl function to download a malicious binary if curl or wget are unavailable. This binary, disguised as a PHP extension, is saved in the /tmp directory with the name httpd to avoid detection by file-based defenses.
The attacker further ensures persistence by setting up either a systemd service or a cron job. If systemd is running, the malware creates a service linked to multi-user.target. Otherwise, the fallback mechanism involves creating a cron job, making it more difficult to remove the malware. Additionally, the malware modifies the /bin/sh binary by replacing it with a custom version (kkbush), enabling privilege escalation and ensuring continued access. The original /bin/sh file is restored after the installation of the backdoor to reduce the chances of detection. The malware also monitors processes through the /proc/ directory and checks for active TCP connections on ports 44870 or 63582. If the malicious process is not detected, it will download the binary using the custom __curl function.
Security Officer Comments:
This attack uses a variety of evasion techniques, including the use of legitimate-sounding process names and the Tor network to reroute traffic, with a confirmed Tor relay node (192.121.108.237) identified in the network traffic. The combination of container escape, environment variable manipulation, and persistence strategies demonstrates the sophistication of the attack and the lengths attackers will go to remain undetected.
Suggested Corrections:
- Secure Docker Remote API servers by implementing strong access controls and authentication mechanisms to prevent unauthorized access.
- Regularly monitor Docker Remote API servers for any unusual or unauthorized activities, and promptly investigate and address any suspicious behavior.
- Implement container security best practices, such as avoiding the use of "Privileged" mode and carefully reviewing container images and configurations before deployment.
- Educate and train personnel responsible for managing Docker Remote API servers about security best practices and potential attack vectors.
- Stay informed about security updates and patches for Docker and related software to address any known vulnerabilities that could be exploited by threat actors.
- Regularly review and update security policies and procedures related to Docker Remote API server management to align with the latest security best practices and recommendations.
https://www.trendmicro.com/en_us/re...-docker-remote-api-servers-with-perfctl-.html