This report was originally published for our customers on 27 November 2023.
As part of our critical vulnerabilities monitoring routine, Sekoia’s Threat & Detection Research (TDR) team deploys and supervises honeypots in different locations around the world to identify potential exploitations.
Introduction
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 ablogpost.
On 28 October 2023, ActiveMQreleased 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 :
- a reverse shell used to install hping and launch a DoS attack on a web server;
- Meterpreter reverse TCP implant but no action by the attacker on the machine;
- Sliver implant, no action by the attacker on the machine;
- execution of an XMRig installation and execution script.
As far as our honeypots are concerned, we only detected compromises based on the ClassPathXmlApplicationContext class. In all cases, the weaponized XML file was very similar to those available in the various POCs. Of note, the XML files were often named poc.xml or linux-poc.xml.
Kinsing infections details
Exploitation
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.
Figure 1. Overview of the Kinsing exploitation OpenWire traffic
The xml file contains commands executing curl to download and run a shell script. This script remains similar to those already observed in other Kinsing infections.
Kinsing infection flow
The downloaded and executed shell script is the first stage of the infection; it remains similar to those already observed in other Kinsing infections. It performs various actions such as:
- Rootkit: the script downloads a rootkit and preloads this rootkit into /etc/ld.so.preload (T1574.006);
- 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).
After infection, Kinsing downloads and installs the cryptominer, as well as a shell script named spre.sh aiming at spreading the malware inside the victim’s network through SSH. It also downloads and executes a script named cron.sh performing two actions:
- It deletes competitors in addition to what has already been done;
- It sets up a crontab that downloads and executes a script named unk.sh every minute. This script could not be recovered. Sekoia assess with medium confidence it serves as a backup backdoor.
Regarding lateralisation via SSH, the spre.sh script inspects various files, including the bash history, “/etc/hosts” and “.ssh/config”. It then builds up lists to iterate through to attempt SSH brute force. If successful, it downloads and executes the initial infection script.
Figure 2. Overview of the Kinsing exploitation OpenWire traffic
Kinsing infrastructure
The follow-up of this IS reveals a rather broad infrastructure, composed as follows:
- Attack machine: this is the machine used to exploit the vulnerability and distribute the infection script. All Kinsing compromises of our honeypots were carried out by 2 IP addresses. One of these was already used by Kinsing to exploit the Metabase vulnerability.
- Repositories: These are web servers that host the various payloads. The URLs are stable over time, having been used by Kinsing in previous compromises dating back several months. However, Kinsing and the cryptominer are separated by a dedicated server for each payload.
- Command and Control: like for repositories, we identify two dedicated infrastructures, one for Kinsing's C2s and a second for the cryptominer pool proxy, whose IP addresses also remain stable over time.
Figure 3. Overview of the Kinsing infrastructure
It is very likely that Kinsing widely scans the Internet to identify vulnerable servers. As this type of scan is very common, it blends in with the Internet noise, so this part of the “scan machine” infrastructure could not be identified.
Kinsing malware
The binary studied is the one dropped on our honeypots. It turns out to be the same payload as the one dropped when exploiting CVE-2023-38646 Metabase (information from previous honeypots and documented in a report send to our customers). It has the following characteristics:
- SHA256 hash: 787e2c94e6d9ce5ec01f5cbe9ee2518431eca8523155526d6dc85934c9c5787c
- Size: 5.69 MBytes
- File: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
- Compiler: Go1.17.13
Network functions
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.
Figure 4. Kinsing C2 decryption with CyberChef
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:
- POST on /mu: in response to this request, C2 sends a list of URLs pointing to the cryptominer payload, available for ARM;
Figure 5. Kinsing C2 order to download cryptominer – decryption with CyberChef
- POST on /ki: this request is passed on regularly, to receive from its C2 a list of processes that Kinsing must kill on the machine. The aim is to remove any competitors that may have entered the machine since it was compromised by Kinsing;
- GET on /get: C2 returns a download and execution instruction, as well as the target URL. This is how spre.sh and cron.sh scripts are downloaded and executed.
Others functions
Kinsing contains a large number of other functions commonly found in RATs. However, two functions stand out from the crowd:
- 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.
Figure 6. Masscan script content in Kinsing
- 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.
For now, Kinsing IS only uses its malware to deploy cryptominer, but it offers a much wider range of possibilities.
Cryptominer
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
Figure 7. Traffic extract between the cryptominer and the mining pool
The IPs contacted do not appear to belong to any public mining pool. However, the binary contains base64-encoded strings corresponding to the IPs contacted by the cryptominer.
Figure 8. Encoded strings
After decoding, we obtain the following values:
- stratum+tcp[://]194[.]87[.]254[.]160:80
- stratum+tcp[://]194[.]87[.]254[.]160:443
- stratum+tcp[://]193[.]124[.]33[.]22:80
- stratum+tcp[://]193[.]124[.]33[.]22:443
- stratum+tcp[://]92[.]255[.]110[.]4:80
- stratum+tcp[://]92[.]255[.]110[.]4:443
- stratum+tcp[://]185[.]156[.]179[.]225:80
- stratum+tcp[://]185[.]87[.]48[.]183:80
- stratum+tcp[://]176[.]113[.]81[.]186:80
- stratum+tcp[://]185[.]221[.]152[.]130:443
- stratum+tcp[://]pool[.]hashvault[.]pro:80
- stratum+tcp[://]monerohash[.]com:2222
- stratum+tcp[://]gulf[.]moneroocean[.]stream:10128
- 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:
- the number of active miners per worker, which in our case corresponds to the number of machines actives compromised by Kinsing;
- the average hashrate, i.e. the computing power;
- Monero gains.
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:
- segmentation: Kinsing may be using other Monero wallets;
- competition: other threat actors are exploiting these vulnerabilities to deploy cryptominer, and one of the first actions they take is very often to remove competitors.
Figure 9. Evolution of number of miners per Worker over time - source API Hashvault
The figure shows only two days' worth of data, nevertheless we observed a spike in the number of miners between 6pm and 6am.
It is difficult to explain these phenomena, Sekoia assess with medium confidence that Kinsing infects machines during non-working hours.
We found that Kinsing attacked almost simultaneously all our honeypots (located in Asia and the other in South America) at fairly fixed times, around 6a.m, 12pm and 00pm (GMT). This suggests that Kinsing operates during these hours.
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:
- On monerohash : the average hashrate is 46,62 kH/sec, compared with 790 kH/sec for hashvault. Total winnings since 24 April 2023 amount to 1.51 Monero or €226 at November 2023 exchange rate.
- On moneroocean : the average hashrate is 151.78 kH/sec, compared with 790 kH/sec for hashvault. Total winnings since 30 April 2023 amount to 1.50 Monero or €224.
In total, in just over a year, Kinsing has generated 25 Monero on this Wallet, equivalent to around 3,750 euros at the November 2023 exchange rate. These revenues seem rather low given the investment made by IS to maintain and expand its botnet.
Other wallet
As described in the Cryptominer section, another wallet is also visible in the payload strings:
46V5WXwS3gXfsgR7fgXeGP4KAXtQTXJfkicBoRSHXwGbhVzj1JXZRJRhbMrvhxvXvgbJuyV3GGWzD6JvVMuQwAXxLZmTWkb.
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.
IoCs
The list of IoCs is available on Sekoia.io GitHub repository
Thank you for reading this blogpost. We welcome any reaction, feedback or critics about this analysis. Please contact us on tdr[at]sekoia.io.
Feel free to read other TDR analysis here :
