Ten Operators, One Ivanti Sentry Command-Injection Endpoint
MultipleMultiple- Observation window
- 2026-06-15 → 2026-06-20 UTC
- Author
- CYFAR / Boredchilada
- Status
- Confidence: High (full operator population captured end-to-end on controlled infrastructure)
- Published
- 2026-06-21
- ip
- ip
- ip
- ip
- ip
- ip
- ip
- ip
- ip
- ip
- url
- url
- url
- url
- url
- user_agent
- user_agent
- user_agent
- user_agent
One endpoint, ten very different visitors
A single internet-facing Ivanti Sentry management surface was exposed for five days, and ten distinct operators turned up to attack the same pre-authentication command endpoint. What each did once the injection worked is where they split apart. Sorted by depth, they form a clean five-tier ladder: at the bottom, fire-and-forget automation; at the top, a person working the keyboard one command at a time. The surface was controlled infrastructure, so nothing real was compromised, but every command each operator ran was recorded.
The constant across all ten is the vulnerability: CVE-2026-10520, a pre-authentication OS command injection in Ivanti Sentry rated CVSS 10.0 that allows unauthenticated root-level code execution. The variable is the operator behind it.
The wave that follows a public PoC
The order of events explains the breadth. Ivanti disclosed CVE-2026-10520 and a paired authentication bypass, CVE-2026-10523, on 2026-06-09. A working proof-of-concept for unauthenticated remote code execution was public the next day. By 2026-06-11 the flaw was on CISA's Known Exploited Vulnerabilities catalog with a three-day federal patch deadline, and mass exploitation was already being reported. This surface went live on 2026-06-15, after all of that. So the traffic it caught is the commodity n-day wave: the pile-on that follows a freshly public, maximum-severity bug once someone else has written the exploit.
That is why the spread is so wide. A CVSS-10 pre-auth RCE with a public PoC draws everyone from scripted scrapers to hands-on intruders, and within five days the sensor had a sample of each.
The Tor crowd that all read the same files
Three of the ten arrived inside roughly fourteen minutes of each other on 2026-06-18, every one through a Tor exit node. They ran near-identical sessions: straight to the management application's configuration and security files, then pg_hba.conf, then the Java keystore, then PostgreSQL probes with default credentials such as PGPASSWORD=changeit. One went further, querying the product's own management language to list enrolled devices and poking the local database at the raw socket level rather than through a client.
The three share a TLS fingerprint, but it is the stock python-requests fingerprint, far too common to tie anyone together. The real link is the matched timing and the identical target list. All three were confirmed as live Tor exit relays in the Tor Project's own relay directory, so the anonymisation is established rather than assumed. Whether one operator drove all three exits or three operators ran the same script cannot be resolved, and the report does not claim to.
From spraying webshells to planting a backdoor
Two operators sit in the middle of the ladder. The first to reach the surface, hours after it went live, was a webshell sprayer: it carried a PHP and a JSP webshell and copied each into every plausible Ivanti webroot, accounting for not knowing the real install path. The next was quieter and more deliberate. It created a second account with UID 0, a root-equivalent backdoor that is easy to miss in a user list, cleared its shell history, and reached out to an external host to pull a second-stage payload.
That pull is worth a caution. The external host looked like staging infrastructure, but when the URL was retrieved out of band it served a troll page rather than a payload. This has more than one reading: the payload may have expired, the host may have been repurposed, or the operator may serve different content based on request context as a way to detect out-of-band retrieval. The report flags the host as actor-referenced rather than confirmed malicious staging.
The operators who stayed on the keyboard
The top of the ladder is four interactive operators, each with a different goal. The cloud-aware one swept the cloud instance-metadata service for AWS, GCP, and Azure credentials, opened reverse shells to its own listener, and scanned the internal subnet.
A third spent 25 minutes methodically checking which download tools were available on the host, then staged a 6.2 MB self-extracting payload from temp.sh. It never executed the file through the injection channel, but the payload was recovered before the hosting link expired. Inside was a complete cryptominer deployment kit: a Go privilege-escalation tool called RootHawk that tries six CVEs (including DirtyPipe and PwnKit), an XMRig miner disguised as runnv, a process-hider that uses mount --bind to vanish from ps, a rival-miner killer, a CPU watchdog, and a cleanup stage that scrubs logs and forges file timestamps. The Monero wallet and mining pool (hashvault.pro, TLS with a pinned certificate) are in the full report's indicator set.
The deepest, and the anchor of this report, arrived on 2026-06-20 and ran 362 distinct commands in under an hour, staying entirely on the host. It began with a thorough privilege-escalation reconnaissance pass: SUID binaries, sudo rights, file capabilities, cron, and an outbound-connectivity test. Then a methodical proof that code execution and file writes actually worked, checking for each tool before using it. Then persistence: it appended its own SSH key to a service account's authorized_keys file and dropped a JSP webshell, verifying the implant afterward by re-reading and hashing it. The key it left behind, an ssh-ed25519 key with the comment "exploit", is a clean indicator a defender can hunt for directly.
A tenth operator, arriving the same evening, brought a tool no other source in the fleet has ever used: gsocket, an encrypted relay tunnel from hackerschoice. In a focused 10-minute session it iterated through five delivery methods — source compilation, a pre-built binary, and three variants of the gsocket.io installer script — all using the default shared secret MySecret. Its TLS fingerprints are exclusive to this single IP across 30 days of fleet data, making them attribution-quality indicators rather than commodity noise.
What this means for defenders
The single most important action is to patch Ivanti Sentry to R10.5.2, R10.6.2, or R10.7.1, which closes both CVE-2026-10520 and CVE-2026-10523. The MICS administrative interface on TCP/8443 should not be reachable from the internet at all; restricting it would have stopped every operator here.
Any instance that was internet-facing after the PoC went public should be treated as presumed-targeted and hunted, not assumed clean. The highest-value checks are on the host, because the injection travels inside TLS while the durable evidence sits on disk: a UID-0 account other than root, an unexpected entry in any authorized_keys file, a JSP or PHP file in a Tomcat webroot, or a recently cleared shell history. Secrets the host could reach should be rotated: the Java keystore, local database credentials, and any cloud instance-metadata credentials. The full report carries the validated detection rules and the complete indicator set.