DripDropper Linux Malware

Red Canary entdeckte einen Angreifer, der CVE-2023-46604 in Apache ActiveMQ ausnutzte, um sich dauerhaften Zugriff auf Cloud-Linux-Systeme zu verschaffen. Nachdem er sich anfänglichen Zugriff verschafft hatte, um seinen Fußabdruck zu sichern und einer Entdeckung zu entgehen, wurde die ausgenutzte Schwachstelle gepatcht.

Es mag kontraintuitiv erscheinen, dass ein Angreifer ein kompromittiertes System nach dem Zugriff aus der Ferne „repariert“, aber in vielen Szenarien kann die Motivation zweifach sein. Es ist eine großartige Möglichkeit, potenzielle Gegner auszuschließen und sicherzustellen, dass der eigene Einflussbereich exklusiv bleibt. Es kann auch die anfängliche Zugriffsmethode des Angreifers verschleiern.

Das Bedrohungsinformations-Team von Red Canary beobachtete eine Häufung von Aktivitäten, die genau dies auf Cloud-Linux-Servern taten, was die Möglichkeit bot, mehr über Post-Exploitation-Taktiken, -Techniken und -Verfahren (TTPs) auf Cloud-Linux-Systemen zu erfahren.

Verdeckte Cloud-Persistenz

Red Canary hat festgestellt, dass ein Angreifer auf Dutzenden von Cloud-basierten Linux-Endpunkten, die für eine kritische Remote-Code-Schwachstelle (CVE-2023-46604) in Apache ActiveMQ anfällig sind, einem weit verbreiteten Open-Source-Message-Broker, der in Java geschrieben ist, Erkundungsbefehle ausführte.

Sicherheitsforscher haben zuvor festgestellt, dass Angreifer CVE-2023-46604 ausnutzen, um Malware zu verbreiten, darunter die Ransomware TellYouThePass, Ransomhub und HelloKitty, sowie Kinsing, ein Malware-Typ, der bekanntermaßen Linux-Systeme angreift, um Krypto-Miner zu verbreiten.

Red Canary beobachtete, wie der Angreifer auf einigen Endpunkten bösartige Aktivitäten durchführte. Nachfolgende Tools zur Steuerung und Kontrolle (C2) des Gegners variierten je nach Endpunkt und umfassten Sliver und Cloudflare Tunnels, um die verdeckte Steuerung und Kontrolle langfristig aufrechtzuerhalten.

In einem Fall, nachdem sie den Endpunkt ausgenutzt und das Sliver-Implantat installiert hatten – wodurch der Angreifer uneingeschränkten Zugriff auf das System erhielt – modifizierten sie die bestehende sshd-Konfigurationsdatei, um die Anmeldung als root zu ermöglichen. Diese Einstellung ist in modernen Linux-Distributionen standardmäßig in der Regel so konfiguriert, dass der Root-Login über SSH verweigert wird. Das Zulassen von Root-Logins ermöglicht dem Angreifer Fernzugriff mit den höchsten Berechtigungen. Unter einer neuen, von sshd gestarteten Sitzung lud der Angreifer einen bisher unbekannten Downloader herunter und führte ihn aus, den wir DripDropper genannt haben.

Was ist DripDropper?

DripDropper ist eine verschlüsselte PyInstaller-ELF-Datei (Executable and Linkable Format). Es benötigt ein Passwort zum Ausführen, was die Sandbox-Analyse behindert. Es kommuniziert mit einem von einem Angreifer kontrollierten Dropbox-Konto unter Verwendung eines fest codierten Bearer-Tokens. Die genauen Informationen, die an oder von Dropbox übertragen werden, sind nicht bekannt, führen aber üblicherweise zur Erstellung von zwei bösartigen Dateien.

Name und Speicherort der ersten abgelegten Datei hängen von den Argumenten ab, die während der Ausführung von DripDropper angegeben werden. Die Aktionen dieser Datei variierten von Instanz zu Instanz und reichten von der Prozessüberwachung bis zur Kontaktaufnahme mit Dropbox für weitere Anweisungen. DripDropper wird die dauerhafte Ausführung der abgelegten Datei sicherstellen, indem die in jedem /etc/cron.*/-Verzeichnis beobachtete Datei 0anacron modifiziert wird.

Die zweite Datei hat einen zufällig generierten, achtstelligen alphabetischen Namen und wird ebenfalls Dropbox für zusätzliche Befehle kontaktieren. Es modifizierte in der Regel bestehende Konfigurationsdateien im Zusammenhang mit SSH, einschließlich der Änderung der Standard-Login-Shell für das Benutzerkonto „games“ auf /bin/sh. Diese Aktion bereitete das System vermutlich auf zusätzlichen, dauerhaften Zugriff über das Spielekonto vor, über das der Angreifer Shell-Befehle ausführen konnte. Es ist unklar, ob die erstellten Dateien denselben Bearer-Token wie DripDropper verwenden.

Die Nutzung öffentlicher Plattformen wie Discord, Telegram und Dropbox für die C2-Kommunikation hat sich als effektive Technik zur Tarnung erwiesen und wird von verschiedenen Angreifern und Malware-Familien wie CHIMNEYSWEEP, Mustang Panda und WhisperGate eingesetzt.

Schließlich nutzte der Angreifer curl, um zwei ActiveMQ-JAR-Dateien von repo1[.]maven[.]org herunterzuladen, einer Domain, die zu Apache Maven gehört. Diese beiden JAR-Dateien stellen einen legitimen Patch für CVE-2023-46604 dar. Durch das Löschen und Ersetzen der bestehenden JAR-Dateien hat der Angreifer das bereits kompromittierte System effektiv gepatcht. Wir gehen davon aus, dass der Angreifer dies tat, um die Entdeckung durch gängige Methoden wie Schwachstellenscanner zu erschweren und die Wahrscheinlichkeit, von Verteidigern entdeckt zu werden, effektiv zu reduzieren, da ein anderer Angreifer bei dem Versuch, die Schwachstelle auszunutzen, entdeckt werden könnte. Gegner haben diese Technik auch bei anderen CVEs eingesetzt. Das Schließen der Sicherheitslücke beeinträchtigt ihre Operationen nicht, da sie bereits andere Mechanismen zur Aufrechterhaltung des Zugriffs eingerichtet haben.

Absicherung von Webservern in Cloud- und Linux-Systemen

Anfällige Webserver gehören zu den häufigsten Einfallstoren für den Zugriff auf Linux-Systeme. Angesichts der Verbreitung von *NIX-basierten oder Unix-ähnlichen Systemen in modernen Infrastrukturen, insbesondere in schnell wachsenden Cloud-Umgebungen, ist deren Schutz unerlässlich. Dies erfordert die Entwicklung spezialisierter Strategien zur Reaktion auf Vorfälle, die auf die Komplexität von Cloud-Architekturen und Linux-Umgebungen zugeschnitten sind, und die Sicherstellung, dass Verteidiger mit wirksamen, umsetzbaren Anleitungen ausgestattet sind, um diese kritischen Vermögenswerte zu schützen.

Obwohl die hier in ActiveMQ ausgenutzte kritische Sicherheitslücke fast drei Jahre alt ist, nutzen Angreifer die Schwachstelle immer noch aus, um Nutzlasten wie Godzilla Webshell und Ransomhub-Ransomware auszuführen, was laut EPSS-Score zu einer Wahrscheinlichkeit von 94,44 % führt, dass sie in den nächsten 30 Tagen ausgenutzt wird.

Die Absicherung von Cloud- und *NIX-basierten Umgebungen erfordert einen mehrschichtigen Ansatz, beginnend mit einer robusten Härtung auf Host-Ebene. Verteidiger sollten ein richtlinienbasiertes Management für sshd implementieren und dabei Tools wie Ansible oder Puppet nutzen, um sichere Konfigurationen auf allen *NIX-Systemen durchzusetzen. Durch die Durchsetzung von richtlinienbasierten Kontrollen können Systeme Fehlkonfigurationen, die Angreifer vornehmen, nach kurzer Zeit automatisch beheben. Ein gutes Beispiel für ein Ansible-Playbook, mit dem Organisationen Root-Logins für SSH automatisch deaktivieren können, wird von Datadog hier veröffentlicht: https://docs.datadoghq.com/security/default_rules/def-000-k5c/.

Es ist wichtig, Webdienste so zu konfigurieren, dass sie mit Nicht-Root-Rechten laufen, um die potenziellen Auswirkungen eines Sicherheitsverstoßes zu minimieren, und eine obligatorische Authentifizierung durchzusetzen, um unbefugten Zugriff zu verhindern. Aufmerksame Linux-Administratoren werden einwenden: „Aber für Webserver werden Root-Rechte benötigt, um die Ports 80 und 443 zu verwenden!“ Diese Anforderung kann durch spezifische Webserver-Konfigurationen (wie die Apache User-Direktive) oder hostspezifische Einstellungen umgangen werden.

Besondere Aufmerksamkeit sollte der Behebung von Sicherheitslücken und der Absicherung anfälliger Dienste gewidmet werden, insbesondere solcher, die für kritische Schwachstellen wie CVE-2023-46604 anfällig sind. CISAs Liste bekannter ausgenutzter Schwachstellen (KEV) ist eine hervorragende Ressource zur Priorisierung von Patches. Administratoren sollten sorgfältig prüfen, ob die Patches implementiert wurden, und nachfragen, wer dies getan hat, anstatt lediglich zu bestätigen, dass die Sicherheitslücke geschlossen wurde. Der Wechsel von einer reaktiven Denkweise („Ist das Problem behoben?“) zu einer proaktiven Denkweise („Wer hat es behoben und warum?“) ist für ein erfolgreiches Sicherheits- und Vorfallreaktionsprogramm unerlässlich. Diese Fragen lassen sich oft anhand von Dokumentationen beantworten, die aus einem soliden Change-Management-Ansatz hervorgehen.

Über das reine Patchen hinaus sollten interne Dienste zur Begrenzung der Netzwerkexposition durch die Konfiguration von Eingangsregeln auf vertrauenswürdige IP-Adressen oder VPNs beschränkt werden. Öffentlich zugängliche Dienste, egal ob lokal in Ihrem Netzwerk oder in der Cloud, sollten eine Richtlinie der minimalen Berechtigung mit Kontrollen verwenden, die von der Host-Firewall bis zu den Netzwerkeinstellungen der Cloud-Umgebung reichen. Selbst wenn eine Anwendung über das Internet verfügbar sein muss, können Sie dennoch einschränken, ob jeder auf der Welt Zugriff benötigt.

Es ist auch wichtig, eine angemessene Protokollierung für Cloud-Umgebungen zu konfigurieren. Dies kann die Erkennung unterstützen, wie im Red Canary-Leitfaden „Wie man die AWS-Transparenz erhöht und die Cloud-Sicherheit verbessert“ beschrieben, und Verteidigern im Falle eines Vorfalls wichtige Ermittlungsansätze liefern.

Warum ist das wichtig?

Da Cloud-Umgebungen und Containerisierung zu einer Zunahme von Linux-Umgebungen geführt haben, haben sich Angreifer angepasst, indem sie ihre Angriffe und ihre Methoden für Linux verstärkt haben. Die Behebung der Sicherheitslücke, um Wettbewerbsnachteile zu verhindern, unterstreicht, wie weit verbreitet Ausnutzung sein kann. Es verdeutlicht die Risiken, die mit der Annahme verbunden sind, dass ein sauberer Schwachstellenscan ein sicheres System bedeutet. Es ist auch eine Erinnerung daran, dass die Implementierung von Patches gut dokumentiert und zeitnah erfolgen sollte, um das Risiko zu vermeiden, dass ein Angreifer dies für Sie erledigt. Obwohl sich die Details zur Schadensbegrenzung und -erkennung unterscheiden, verfolgen die Angreifer unter Linux die gleichen Ziele. Sie erreichen Persistenz durch systemgeplante Ausführung, mischen ihre Dateinamen und Standortwahlen so gut wie möglich und wählen C2-Kanäle, die im legitimen Datenverkehr üblich sind.

Red Canary detected an adversary exploiting CVE-2023-46604 in Apache ActiveMQ to gain persistent access on cloud Linux systems, patching the exploited vulnerability after securing initial access to secure their foothold and evade detection.

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 which hinders 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 8-character alphabetical name, and will also contact Dropbox for additional commands. It typically modified 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. It is unclear if the created files utilize 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 webservers in cloud and Linux systems

Vulnerable webservers 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% 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, beginning with robust 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. A good example of an Ansible playbook organizations can use to automatically disable root logins for SSH is published by Datadog here: https://docs.datadoghq.com/security/default_rules/def-000-k5c/.

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 theApache User directive) or host-specific settings.

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.

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.

It is also important to configure appropriate logging for cloud environments. This can aid detection as outlined in Red Canary’s guide „How to increase AWS visibility and improve cloud security“ and provide defenders critical investigative leads in the event of an incident.

Why does it 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 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.