In early November, several reports described the exploitation of ActiveMQ vulnerability CVE-2023-46604 to deploy HelloKitty ransomware. Proofs of Concept and Metasploit exploitation modules were published at the beginning of November. All these factors led us to deploy a vulnerable Linux version of ActiveMQ as honeypots to monitor the exploitation of this vulnerability.
Our honeypots were soon under attack by Kinsing. While the vulnerability has also been exploited to deploy some reverse shell, Kinsing remains the only major intrusion set (IS) based on our observation.
This blogpost aims at presenting a technical analysis of the exploitation of the
CVE-2023-46604
vulnerability by
Kinsing
as well as a more detailed analysis of this IS, including its infrastructure and its cryptocurrency assets.
Exploitation of CVE-2023-46604
Exploitation details
Disclosed on 27 October 2023 and then associated with a CVSS3 score of 9.8, this vulnerability affects the OpenWire module. It allows an unauthenticated attacker to execute arbitrary code. Several PoCs are publicly available and easy to use for the average threat actor.
The primary cause of this vulnerability is a lack of validation in the deserialization process. Input data passes through a process called unmarshalling, whose function is to transform binary data into a usable format.
ActiveMQ has several unmarshalling components called
DataStreamMarshallers
. The system selects the component according to the
Data_Structure_Type
accompanying the data. The vulnerability in
ExceptionResponseMarshaller
arises from its failure to validate the classes it creates from the
ExceptionResponse
data. An attacker can create a weaponized throwable class and trick the system into using it to execute arbitrary code.
ClassPathXmlApplicationContext
is used to configure Spring applications via an XML file passed as a parameter at class instantiation. Through this vulnerability, an attacker can instantiate the
ClassPathXmlApplicationContext
class and pass it a weaponized xml file, enabling him to execute code on the machine.
The various PoCs available, like the Metasploit module, work in the same way. Using the vulnerability affecting the deserialization process, they instantiate
ClassPathXmlApplicationContext
class and pass it a weaponized xml file as parameter. This implies that the target can access this xml file via HTTP. In the vast majority of cases, attackers use this vulnerability either to execute a payload on the machine, or to obtain a reverse shell.
Actually, this vulnerability is exploited by instantiating the
ClassPathXmlApplicationContext
class, but it is quite possible to exploit it in a different way. As the lack of validation in the input stream deserialization process allows any class to be instantiated, there are many other methods of exploitation, as vulncheck rightly reminds us in a
blogpost
.
On 28 October 2023, ActiveMQ
released patches
, we strongly advise you to update to versions:
5.15.16, 5.16.7, 5.17.6 or 5.18.3
.
If updating is not possible, cutting off access to OpenWire from the Internet limits the risk of exploitation. However, it is still important to plan a migration to a patched version.
Honeypots overview
We deployed two honeypots as a Docker image in two different countries. We used ActiveMQ version 5.17.5. The host machine is monitored with the Sekoia Linux endpoint agent, and Suricata IDS is also used to detect exploits of the vulnerability. Logs are sent to our XDR to benefit from Sekoia’s
detection rules
and Threat Intelligence.
Within 24 hours of going online, our honeypots were compromised by Kinsing. During the time they were active, the vulnerability was exploited on average five to six times a day. In the majority of cases, it was Kinsing. In other cases, we detected :
Our honeypots were deployed on 9 November 2023. The first Kinsing intrusion was recorded two days later, on 11 November. From 12 November 2023, between two and three Kinsing intrusions are recorded daily on each honeypots. We noticed that all these attacks systematically originate from two different IP addresses :
109.237.96[.]124
and
78.153.140[.]30
. Of note, the IP address 109.237.96[.]124 was already used by Kinsing to exploit the Metabase vulnerability CVE-2023-38646 (information from previous honeypots and documented in a report send to our customers).
Kinsing’s exploitation is very similar to the various PoCs available. An xml payload is hosted on a web server controlled by Kinsing. The attacking IP exploits the vulnerability so that the victim downloads this xml file and executes the instructions contained in it.
Remove competitors
:
the script removes malware processes that may already be present on the machine using various commands. To do this, it checks for strings in current processes with the ps and netstat commands. It also checks for cron jobs and disables those associated with competitors;
Download and execute
: the script then downloads
kinsing
(32-bits or 64-bits version, depending on the system architecture), and executes it. Of note, it checks for the presence of curl or wget utilities on the machine to use the one available. If ran with root permissions, the script copies/drops the available binary to the /etc folder, else in /tmp;
Establish persistence
: for that, the script uses two mechanisms: adding a cron job (
T1053.003
) and a systemctl (
T1543.002
) service launching the malware at startup;
Remove firewall rules
: the script flushes firewall rules with the command “iptables -F” (
T1562.004
).
The malware code is not obfuscated, and contains over 60 functions. One of them, named
getActiveC2Url
, allows us to retrieve Kinsing C2s and connect to them. Payloads are stored encrypted using RC4 in a variable. The function retrieves this field and decrypts it using the
2abd6e2c1akl
encryption key. By applying the reverse logic, we can extract the C2s configured in the payload.
The malware then establishes HTTP connection with one of the C2s. System information, such as CPU architecture and core count, OS version, RAM size and a UUID set during malware execution, are sent in the HTTP header. All HTTP requests use the hardcoded User-Agent “
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36”
. Data exchanged between the malware and C2 are also encrypted via RC4 using a different key:
764153446b61
.
Traffic analysis reveals 3 areas of interest:
massscan
: On C2’s command, this function drops and executes a script stored in the Kinsing payload. This script downloads a payload and saves it under the name firewire. It ensures that the downloaded payload is compliant by comparing its MD5 with a hardcoded value. This hash is known to the various threat intelligence platforms and corresponds to the massscan network scanner. From our observations, attackers did not use this malware capability.
redisBrute
: As the name suggests, this is a function for brute forcing authentication on Redis server. To do this, C2 gives a list of target IP addresses and Kinsing will attempt to authenticate using a list of hard-coded credentials. From our observations, attackers did not use this malware capability either.
The cryptominer deployed is a version of XMRig packed with UPX containing configuration information. After decompression, some configuration snippets can be found in the payload strings, including a Monero wallet:
46V5WXwS3gXfsgR7fgXeGP4KAXtQTXJfkicBoRSHXwGbhVzj1JXZRJRhbMrvhxvXvgbJuyV3GGWzD6JvVMuQwAXxLZmTWkb
and a
nanopool.org
URL (one of main public Monero mining pool). Various CTI reports link this wallet to Kinsing. However, based on Nanopool monitoring, this wallet is no longer active since November 2019.
Traffic emanating from one of the infected honeypots reveals the use of another Wallet:
44MtPEErzyDNHfggtup49m4zwGm7zjYp5jWKWRc3go6LN5fxetsHtVhdEetL9jhZedNAwG7YGLpR1azK5Ch69cdGPgVj5wA
The IP addresses correspond to a stratum proxies for Monero that aim to aggregate connections from different miners in order to reduce connections to the mining pool. This is a prerequisite for using the hashvault service. We also found the URLs for the various public mining pools, as well as the wallet seen in the PCAP. This configuration is the same for all payloads (arm or x86). Of note, the x86 version uses the pass identifier, whereas ARM uses pass_a.
Kinsing financial overview
The websites of various mining pools provide interesting information about the Kinsing wallet
44MtPEErzyDNHfggtup49m4zwGm7zjYp5jWKWRc3go6LN5fxetsHtVhdEetL9jhZedNAwG7YGLpR1azK5Ch69cdGPgVj5wA
.
Hashvault
Hashvault website provides the most real-time information, including:
Based on the monitoring of this mining pool, Kinsing wallet grows by on average
0.11 Monero per day
(around €15 at November 2023 exchange rate). Since 26 September 26 2022, the date of the first payment on this service,
Kinsing has obtained in total 21.2286 Monero
(€3,198.3 at November 2023 exchange rate) for its mining activity.
The platform distinguishes between two workers, Sekoia assumes that worker called
pass
corresponds to the worker for
x86
cpu and worker
passa
to that for
ARM
.
Over the period observed, based on Hashvault tracking, there were around 900 active miners daily. Compared with the number of machines potentially vulnerable to CVE 2023 46604 and other vulnerabilities actively exploited by Kinsing (notably CVE-2023-32315 and CVE-2023-38646), this number seems low. Sekoia proposes several hypotheses:
With regard to the troughs observed, we note that they occur during working hours. We can assume that some machines are cleaned up by administrators during working hours when they notice the compromise.
The platform logs also give an indication of the location of these miners. The platform logs also give an indication of the location of these miners. It’s difficult to make detailed use of this data, but it does highlight the very diverse origins of these miners. The locations show miners present in the US, Europe (UK, Germany, France), Brazil, Mexico, Indonesia, Japan, Russia, China and Africa (Kenya). This shows that Kinsing is not targeting a country, or a company, but resources.
Others pools
The other two platforms, monerohash and moneroocean, gave much less information about the Kinsing wallet. The hashrate is significantly lower, suggesting that hashvault is used as the main mining pool. The earnings obtained via these two platforms are therefore much lower:
This wallet is associated with an XMRig configuration file that points to the nanopool.org mining pool. The pool’s web site provides interesting information on this wallet. We identified that this wallet is no longer used on this pool since November 30, 2019. In total, it would have obtained 8,236.43 Monero, approximately 486 000 euros at the share price in Novembre 2019, for its mining activity between 29 September 2018 and 30 November 2019. These significant earnings contrast sharply with those of Kinsing’s active wallet.
Conclusion
Our honeypots went into production around ten days after the release of the proof of concept code, and were very quickly compromised by Kinsing. This shows how quickly this IS exploits new exploits at scale.
Kinsing has a consistent and stable infrastructure which results in high hosting costs. Analysis of the cryptominer, gives an idea of the number of machines compromised by Kinsing, but above all of the gains obtained. The latter seems rather low in view of the probable costs incurred by the intrusion, notably for its infrastructure. Sekoia assumes that the group has other sources of revenue, probably crypto-currency miners associated with other wallets.
The numerous compromises resulting from the exploitation of this vulnerability are a reminder of the importance of applying security patches as they are issued, and of the importance of controlling the perimeter of the vulnerability, in particular related to dockerized services.
