It may seem counterintuitive for an adversary to “fix” a compromised system after gaining remote access but in many scenarios the motivation can be twofold. It’s a great way to potentially lock out other adversaries, ensuring their foothold remains exclusive. It can also obscure the adversary’s initial access technique.

The Red Canary Threat Intelligence team observed a cluster of activity that did just this on cloud Linux servers, providing an opportunity to learn more about post-exploitation TTPs on cloud Linux systems.

Covert cloud persistence

Red Canary detected an adversary executing discovery commands on dozens of cloud-based Linux endpoints vulnerable to a critical remote code vulnerability (CVE-2023-46604) in Apache ActiveMQ, a widely used, open source message broker written in Java.

Security researchers have previously identified adversaries exploiting CVE-2023-46604 for malware deployment, to spread TellYouThePass, Ransomhub and HelloKitty ransomware, along with Kinsing, a malware strain known for targeting Linux systems to spread cryptominers.

Red Canary observed the adversary carry out malicious activity on a handful of the endpoints. Follow-on adversary command and control (C2) tools varied by endpoint and included Sliver, and Cloudflare Tunnels to maintain covert command and control over the long term.

In one instance, after exploiting the endpoint and installing the Sliver implant—granting the adversary unrestricted access to the system—they modified the existing sshd configuration file to enable root login. This setting is usually set to deny root login over SSH by default in modern Linux distributions. Allowing root logins enables the adversary remote access with the highest level of privilege. Under a new session started by sshd, the adversary downloaded and executed a previously unknown downloader that we have named “DripDropper.”

What is DripDropper?

DripDropper is an encrypted PyInstaller ELF, or Executable and Linkable Format, file. It requires a password to run, hindering sandbox analysis. It communicates with an adversary-controlled Dropbox account using a hardcoded bearer token. The exact information passed to or from Dropbox is not known but commonly results in the creation of two malicious files.

The name and location of the first file dropped are dependent on arguments provided during the execution of DripDropper. The actions of this file changed from instance to instance, ranging from process monitoring to contacting Dropbox for further instructions. DripDropper will establish persistent execution for the dropped file by modifying the 0anacron file observed in each /etc/cron.*/ directory.

The second file possesses a randomly generated eight-character alphabetical name, and will also contact Dropbox for additional commands. It typically modifies existing configuration files related to SSH, including altering the default login shell for user account games to /bin/sh. This action presumably prepared the system for additional persistent access via the games account where the adversary could issue shell commands.

We were unable to determine if the created files leverage the same bearer token as DripDropper.

The usage of public platforms like Discord, Telegram, and Dropbox for C2 communications has proven to be an effective technique for blending in and is utilized by various adversaries and malware families, such as CHIMNEYSWEEP, Mustang Panda, and WhisperGate.

Finally, the adversary used curl to download two ActiveMQ JAR files from repo1[.]maven[.]org, a domain belonging to Apache Maven. These two JAR files constitute a legitimate patch for CVE-2023-46604. By deleting the existing JAR files and replacing them, the adversary effectively patched the already compromised system. We assess the adversary likely did this to reduce detection via common methods, such as vulnerability scanners, and to effectively reduce the likelihood of being spotted by defenders due to another adversary being detected when attempting to exploit the vulnerability. Adversaries have employed this technique with other CVEs. Patching the vulnerability does not disrupt their operations as they already established other persistence mechanisms for continued access.

Securing web servers in cloud and Linux systems

Vulnerable web servers are one of the most common initial access vectors to Linux systems. Given the prevalence of *NIX-based, or or Unix-like, systems in modern infrastructure, particularly in rapidly expanding cloud environments, ensuring they’re protected is essential. This requires the development of specialized incident response strategies tailored to the complexities of both cloud architectures and Linux environments and ensuring defenders are equipped with effective, actionable guidance to safeguard these critical assets.

Even though the critical vulnerability exploited in ActiveMQ here is nearly three years old, adversaries are still exploiting the vulnerability to execute payloads such as Godzilla Webshell, and Ransomhub ransomware, resulting in a 94.44 percent likelihood of being exploited in the next 30 days, according to its EPSS score.

Securing cloud and *NIX-based environments demand a multi-layered approach.

Host-level hardening

Defenders should implement policy-based management for sshd, leveraging tools like Ansible or Puppet to enforce secure configurations across all *NIX systems. By enforcing using policy-based controls, systems can automatically heal misconfigurations adversaries make after a short period of time. Datadog published a good example of an Ansible playbook organizations can use to automatically disable root logins for SSH.

It’s important to configure web services to run as non-root accounts, minimizing potential impact from compromise, and enforce mandatory authentication to prevent unauthorized access. Eagle-eyed Linux admins will point out, “But root privileges are needed for web servers to use ports 80 and 443!” This requirement can be worked around using specific web server configurations (like the Apache User directive) or host-specific settings.

Proactive patching

Immediate attention should be given to patching and securing vulnerable services, especially those susceptible to critical flaws like CVE-2023-46604. CISA’s Known Exploited Vulnerabilities (KEV) is a great resource for prioritizing patches. Administrators should perform due diligence in verifying that patches have been implemented and ask who did so instead of simply confirming the vulnerability has been patched. Shifting from a reactive “is the problem fixed?” mindset to a proactive “who fixed it and why?” is essential when it comes to a successful security and incident response program. These questions can often be answered with documentation from a healthy change management approach.

Configuring ingress rules

Beyond patching, when it comes to restricting network exposure, internal services should be limited by configuring ingress rules to trusted IP addresses or VPNs. Public-facing services whether local to your network or in the cloud should use a policy of least privilege with controls ranging from the host firewall through the cloud environment network settings. Even if an application must be available over the Internet, you can still restrict whether everyone in the world needs access.

Monitoring cloud logs

It is also important to configure appropriate logging for cloud environments. This can aid detection and provide defenders critical investigative leads in the event of an incident.

Why does this matter?

As cloud environments and containerization have led to an increase in Linux environments, adversaries have adapted by increased attacks and tradecraft development for Linux. The patching of the vulnerability to prevent competition underscores how prevalent exploitation can be. It highlights the risks of assuming that a clean vulnerability scan means a secure system.

It is also a reminder that patch implementation should be well-documented and occur in a timely manner, to avoid the risk of an adversary doing it for you. While mitigation and detection details differ, adversaries have the same objectives on Linux. They achieve persistence through system scheduled execution, blend their filenames and location choices as much as possible, and choose C2 channels that are common in legitimate traffic.

Special thanks to Senior Malware Analyst Tony Lambert for contributing to this research.