Explore in-depth analysis of a sophisticated campaign targeting exposed Docker APIs with new binaries and persistence mechanisms. Discover the connection to Spinning YARN and learn actionable security strategies.
Docker, a popular platform for containerizing applications, has recently become a prime target due to its widespread adoption and critical role in modern DevOps practices. SECNORA has closely monitored these developments and identified a sophisticated campaign targeting exposed Docker APIs. This campaign employs new binaries—chkstart, exeremo, and vurld—along with a persistence mechanism that modifies system services, suggesting a connection to the notorious Spinning YARN campaign.
Detailed Analysis of the New Binaries: chkstart, exeremo, and vurld
In the sophisticated campaign targeting exposed Docker APIs, the attackers have introduced three new binaries: chkstart, exeremo, and vurld. Each binary plays a specific role in the attack sequence, from initial compromise to executing malicious activities and maintaining persistence. This part delves into the technical details of these binaries, providing insights into their functionalities and how they contribute to the overall attack.
1. chkstart: Initial Compromise
The chkstart binary is the first component deployed in this attack campaign. Its primary function is to scan for exposed Docker APIs and exploit them to gain unauthorized access. Once access is obtained, chkstart deploys additional payloads to compromise the system.
Key Functions of chkstart:
- API Scanning: chkstart scans the network for exposed Docker APIs, identifying potential targets for exploitation.
- Exploitation: Upon finding an exposed API, chkstart uses known vulnerabilities to gain access. This can include exploiting misconfigurations or using specific Docker API vulnerabilities.
- Payload Deployment: After gaining access, chkstart deploys secondary payloads to establish a foothold in the system.
2. exeremo: Main Payload Execution
The exeremo binary serves as the main payload in this campaign. It is responsible for executing various malicious activities, including data exfiltration, deploying cryptominers, and launching further attacks on connected systems.
Key Functions of exeremo:
- Data Exfiltration: exeremo can collect sensitive information from the compromised system and send it to the attacker’s server.
- Cryptomining: The binary can deploy cryptomining software to utilize the system’s resources for mining cryptocurrency.
- Further Attacks: exeremo can scan the local network for additional targets and attempt to propagate the attack.
3. vurld: Persistence Mechanism
The vurld binary is designed to ensure persistence within the compromised environment. It achieves this by modifying systemd services, which allows the malicious processes to be re-launched automatically during system startup.
Key Functions of vurld:
- Systemd Modification: vurld modifies existing systemd service files or creates new ones to include commands that execute the malicious binaries.
- Persistence: By altering systemd services, vurld ensures that the malicious payloads are executed each time the system starts, making it difficult to remove the malware.
Persistence Mechanisms and systemd Service Modifications
In the ongoing campaign targeting exposed Docker APIs, one of the most critical aspects ensuring the attacker’s continued access to compromised systems is the use of persistence mechanisms. Among these, the modification of systemd services stands out due to its effectiveness in maintaining control over the infected environment. This part of the blog delves into the technical details of these persistence strategies, illustrating how attackers use systemd to their advantage and providing actionable insights for defenders.
Understanding Persistence Mechanisms
Persistence mechanisms are methods used by attackers to ensure their malicious code remains active on a compromised system, even after reboots or other disruptions. By embedding themselves deeply within the system’s core functions, these mechanisms allow attackers to maintain their foothold, continue their activities, and evade detection.
In the context of this campaign, the primary persistence mechanism involves modifying systemd service files. Systemd is a system and service manager for Linux operating systems that initializes the user space and manages system services after booting. By altering these service files, attackers can ensure their malicious binaries are executed automatically during system startup.
Modifying systemd Services
Systemd uses unit files to define services, which are stored in directories like /etc/systemd/system/ and /lib/systemd/system/. These unit files contain configurations that dictate how services should start, stop, and behave. By adding or modifying these files, attackers can integrate their malicious binaries into the system’s startup routine.
Steps Involved in Modifying systemd Services:
Creating a New Service File: Attackers can create a new service file in the /etc/systemd/system/ directory. This file includes commands to execute the malicious binary.
Fig.1- Code for creating a new service file
This script sets up a new service named “malicious_service” that runs a specified binary. The commands systemctl daemon-reload, systemctl enable, and systemctl start are used to reload the systemd configuration, enable the new service, and start it immediately.
Modifying an Existing Service File: Attackers can also modify existing service files to include their malicious commands. This can be more covert, as it leverages legitimate services to execute malicious code.
Fig.2 – code for modifying service file
This command uses sed to insert an ExecStartPre command, which runs the malicious binary before starting the actual service.
Persistence Through system Modification
The choice of system for persistence is strategic. Systemd is integral to the Linux startup process, making it a reliable way to ensure that malicious binaries are executed without fail. Here’s a closer look at why this method is effective:
- Resilience to Reboots: Systemd services are designed to run at startup, ensuring that any modifications persist across reboots.
- Integration with Legitimate Processes: By embedding malicious commands within legitimate services, attackers can blend their activities with normal system operations, making detection more difficult.
- Automated Execution: Once a system service is modified, it can automatically execute the malicious binary without user intervention, ensuring continuous operation.
Defensive Measures Against system-Based Persistence
To protect against such persistence mechanisms, organizations should implement several defensive strategies:
- File Integrity Monitoring: Use tools like Tripwire or AIDE to monitor critical system files, including those in the /etc/systemd/system/ directory. Alerts should be generated for any unauthorized changes.
- Regular Audits: Conduct regular audits of system service files to ensure no unauthorized modifications have been made. Comparing service files against known good baselines can help identify suspicious changes.
- Restrict File Permissions: Limit the ability to modify system service files to trusted users only. This can be achieved by setting appropriate file permissions and using role-based access controls.
- Logging and Monitoring: Implement comprehensive logging and monitoring of system activities. Tools like journald can capture detailed logs of service starts, stops, and errors, providing valuable information for detecting anomalies.
- Automated Scans: Use automated security tools to scan for known persistence mechanisms and potential vulnerabilities. This can help in early detection and mitigation of threats.
Linking the Campaign to Spinning YARN
The sophisticated campaign targeting exposed Docker APIs has exhibited advanced techniques and persistence mechanisms, raising concerns about its origin. Our analysis at SECNORA indicates a potential connection to the infamous Spinning YARN campaign, known for its innovative and persistent attack strategies. In this part, we explore the similarities between the two campaigns, providing a detailed comparison and real-world case studies to illustrate the link.
Similarities Between the Campaigns
- Advanced Persistence Mechanisms: Both campaigns employ advanced persistence techniques to maintain their foothold on compromised systems. As discussed in Part 3, the current campaign uses systemd service modifications for persistence. Similarly, Spinning YARN has been documented to use various persistence strategies, including cron jobs and rc.local file modifications.
- Use of Unique Binaries: The introduction of new binaries—chkstart, exeremo, and vurld—in the current campaign parallels the Spinning YARN campaign’s use of custom binaries tailored for specific attack phases. These binaries often include obfuscation techniques to evade detection and are capable of performing multiple malicious activities.
- Targeting Docker Environments: Both campaigns have a keen interest in exploiting containerized environments. Docker’s widespread use in modern DevOps practices makes it an attractive target for attackers seeking to infiltrate and control large-scale deployments.
- Network Propagation: The ability to propagate across networks and target additional systems is a hallmark of both campaigns. The current campaign’s use of exeremo to scan for and attack other vulnerable Docker APIs mirrors Spinning YARN’s strategy of leveraging compromised systems to spread further within a network.
Mitigation Strategies for Securing Docker Environments
Organizations must adopt a comprehensive security approach to effectively counter the sophisticated threats targeting Docker environments. This includes proactive measures to protect against initial compromises, mechanisms to detect and respond to ongoing attacks, and strategies to recover from security incidents. In this final part, we present actionable mitigation strategies and best practices that can help secure Docker environments against advanced attacks like those seen in the recent campaigns linked to Spinning YARN.
Fig. 3 – Mitigating Strategies
Securing Docker environments against sophisticated threats requires a multi-layered approach that combines robust configurations, continuous monitoring, and proactive defense strategies. At SECNORA, our team of cybersecurity experts is dedicated to staying ahead of emerging threats and providing cutting-edge solutions to protect your infrastructure. By implementing the strategies and best practices outlined in this blog series, organizations can significantly enhance their security posture and mitigate the risks posed by advanced attackers. However, cybersecurity is a constantly evolving field, and staying informed and prepared is crucial.
We invite you to reach out to SECNORA: https://secnora.com/ for a comprehensive security assessment of your Docker environments. Our experts are here to help you identify vulnerabilities, implement effective defenses, and ensure your systems remain secure against even the most persistent threats.
