A connection is not an exploit: what 27 days of honeypot traffic actually contained
Internet-facing services (RDP, SMB, SSH, web, VoIP)
Honeypot reports trade in enormous, frightening numbers. Across 27 days our sensor fleet logged 5.4 million events carrying a CVE label – and 99.9% of them were doorknob-rattling: brute-force logins and port scans against deliberately vulnerable-looking services, not exploitation. Strip the noise and the real signal is small and sharp: 3,572 actual exploit payloads, a hand-picked set of web vulnerabilities from 2017 to 2023, and exactly one human being – a botnet operator typing an eight-year-old SSH key by hand.
9 min read
§ 01. The number problem
Every honeypot vendor has a headline number: millions of attacks, a breach every few seconds, a map lit up like a war room. The numbers are real in the narrow sense that something arrived on a port. They are misleading in the sense that matters: almost none of it is exploitation.
Separating opportunistic scanning from real exploitation is not a new idea – GreyNoise built a business on telling who is scanning everyone apart from who is targeting you. What is new here is turning that filter on a honeypot's own CVE tallies, and measuring how far the numbers fall when you do.
Mirage runs five sensors that present the services an ordinary internet-facing organization exposes – RDP, SMB, SSH, databases, web applications, mail, VoIP – and records every interaction. Over the 27 days ending 20 July 2026 the fleet took in more than seven million events per week from over fourteen thousand distinct source addresses across 141 countries. Of those, 5,446,849 carried a CVE label. That is the number a marketing deck would print.
Here is the same number, told honestly. A connection to a baited RDP port is not a BlueKeep exploit; it is someone rattling the doorknob. A password guess against a MySQL honeypot is not CVE-2012-2122 exploitation; it is a login attempt. When you separate the knocks from the break-ins, 5.4 million collapses to this:
| Category | What it is | Events | Share |
|---|---|---|---|
| Brute-force / connections | Login floods + port scans against baited services | 5,343,917 | 98.11% |
| Vulnerability scanning | Probing for a specific web CVE, no payload delivered | 99,360 | 1.82% |
| Actual exploit payloads | A request that carries a working exploit | 3,572 | 0.066% |
§ 02. Doorknob-rattling: the 5.3 million
The overwhelming majority of the volume is password brute-force and connection spraying against old, wormable services. It is loud, relentless, and almost entirely skill-free – the same commodity botnets hitting every address on the internet. The tell is in the event type itself; these are not exploit requests, they are login attempts:
| CVE / bait | Events | Distinct IPs | What the sensor actually saw |
|---|---|---|---|
CVE-2019-0708 · BlueKeep (RDP) | 3,596,071 | 3,914 | RDP connection / brute-force (~900 per IP) |
CVE-2017-0144 · EternalBlue (SMB) | 1,292,028 | 3,427 | SMB scanning / connections |
CVE-2012-2122 · MySQL | 244,362 | 1,621 | mysql_login_attempt (password guessing) |
CVE-2019-9193 · PostgreSQL* | 166,597 | 1,447 | postgres_login_attempt (*disputed CVE) |
CVE-2011-2523 · vsftpd | 44,859 | 1,690 | ftp_login_attempt |
This is why "3.6 million BlueKeep attacks" is a number to distrust – including when it is ours. BlueKeep (CVE-2019-0708) is what the RDP sensor baits, so every brute-force connection inherits the tag. It is genuinely the loudest thing on the internet, and it is genuinely not exploitation. We keep the association as a label for context and deliberately keep it out of our exploitation metrics; a doorknob rattle counted as a break-in poisons everything downstream.
§ 03. Real exploitation: the 3,572
Strip the brute-force and the scanning, and what remains is exploitation: a request that actually carries a working exploit for a web application. It is a small, sharp, hand-picked set – a real exploit attempt roughly every eleven minutes – and it is dominated not by the newest CVE but by a five-year-old one.
| CVE | Vulnerability | Disclosed | Payloads | Distinct IPs |
|---|---|---|---|---|
CVE-2021-26855 | ProxyLogon (Microsoft Exchange SSRF) | 2021 | 1,754 | 73 |
CVE-2022-21907 | HTTP.sys RCE (Windows) | 2022 | 353 | 46 |
CVE-2020-1938 | Ghostcat (Apache Tomcat AJP) | 2020 | 312 | 65 |
CVE-2023-7028 | GitLab account takeover | 2024 | 258 | 3 |
CVE-2019-11043 | PHP-FPM RCE | 2019 | 183 | 53 |
CVE-2017-9841 | PHPUnit eval-stdin RCE | 2017 | 174 | 20 |
CVE-2018-7600 | Drupalgeddon2 | 2018 | 169 | 38 |
CVE-2017-12149 | JBoss deserialization RCE | 2017 | 158 | 37 |
CVE-2023-22515 | Confluence broken access control | 2023 | 114 | 57 |
CVE-2022-22965 | Spring4Shell | 2022 | 93 | 57 |
The single most-delivered exploit on the fleet is ProxyLogon – a 2021 Microsoft Exchange flaw, patched more than five years ago, still the busiest real payload we see. The set as a whole spans 2017 (PHPUnit, JBoss) to 2024 (GitLab), the entire useful lifetime of a web CVE arriving in the same window. Attackers do not retire an exploit because it is old; they retire it when it stops working, and these still work somewhere.
§ 04. Targeted, not just sprayed
The distinct-IP column separates a botnet from an operator. ProxyLogon arrives from 73 addresses and Spring4Shell from 57 – broad, commodity spray. GitLab account-takeover (CVE-2023-7028) is the opposite: 258 attempts from just three source IPs. That is not a botnet blanketing the internet; that is a small, focused actor working a specific target set by hand-tuned tooling. Volume tells you what is popular. The source count tells you who is paying attention.
§ 05. The one human in the room
Everything above is automation. In 27 days the fleet captured exactly one category of genuine hands-on-keyboard post-exploitation, and it belongs to Outlaw (also tracked as Dota) – a long-running Linux cryptomining botnet. After a successful SSH login, the same sequence ran verbatim, from Mexico, Vietnam and the United States, within a three-minute window on 20 July – and from at least seventeen distinct source IPs across the month:
cd ~; chattr -ia .ssh; lockr -ia .ssh # clear immutable/append-only locks
rm -rf .ssh && mkdir .ssh # evict every other key (admins and rivals)
echo "ssh-rsa AAAAB3NzaC1yc2E…oRw== mdrfckr" >> .ssh/authorized_keys
chmod -R go= ~/.ssh # satisfy OpenSSH StrictModesThe key tagged mdrfckr is not new. Its authorized_keys file was first observed on VirusTotal on 5 July 2018; one research network counted the identical key dropped by 12,913 unique source IPs in 2022. It is a shared botnet credential – the same public key reused across the entire operation – which is exactly what makes it a durable tracking beacon. Eight years on, it is still being typed into fresh servers.
One detail nobody appears to have published: the key is cryptographically odd. Decode the blob and its RSA public exponent is 37 (0x25), not the universal 65537 that OpenSSH's ssh-keygen always emits. Exponent 37 was PuTTYgen's default before version 0.75 (2021) – so the botnet's signature key was almost certainly generated with an old PuTTYgen, and definitively not with ssh-keygen. It is a forensic footnote, not a weakness – but it is a fingerprint that survives even if the operators change the comment.
| Indicator | Type | Note |
|---|---|---|
…AAAABJQ… / e=37 | SSH key fingerprint | byte-level tell of the reused key, comment-independent |
SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw | SSH public key | the mdrfckr authorized_keys entry (RSA-2048) |
chattr -ia / lockr -ia on ~/.ssh | Behavior | immutable-flag clearing before key implant |
§ 06. The fresh edge
The old does not crowd out the new; it arrives alongside it. Inside the scanning tier, 750 distinct IPs fingerprinted rsync for CVE-2024-12084 – a critical (CVSS 9.8) heap overflow disclosed in January 2025 – folding a months-old bug into the same commodity sweeps that carry the decade-old ones.
And the web scanning has grown framework-aware. The fleet captured probes built specifically for Next.js applications: base64-encoded payloads on server-rendered data routes such as /_next/data/{buildId}/page.json, each carrying a small JavaScript stub that runs a benign canary and checks the response for it:
(function(){
try {
var cmd = "echo VULN_TEST";
var result = /* run cmd, return output */ ;
} catch (e) { }
})()§ 07. How to read a honeypot number
The practical lesson is a habit, not a patch. When any report – including this one – shows you a big attack number, ask three questions. Is it a payload or a knock? A login attempt and a port scan are not exploitation. How many distinct sources? A million events from a handful of IPs is a flood; a few hundred from three is a targeted operator. And is the CVE even deliverable on that service? Half the "top CVEs" in a raw honeypot feed are just the vulnerability the port was baited with.
For defenders, the honest signal points somewhere unglamorous. The real exploitation is old, patchable web bugs – ProxyLogon, Confluence, GitLab, Spring4Shell – so patch those and audit the internet-facing apps that carry them. Keep RDP, SMB and Telnet off the public internet entirely, because the brute-force noise against them never stops. And check every user's ~/.ssh/authorized_keys for a key you did not put there; if it will not delete, clear the immutable flag first with chattr -i.
§ 08. About this report
This is the first in a monthly series. Mirage – recently launched by OffSeq – turns a distributed honeypot fleet into live threat intelligence, filtered down to the signal that actually matters: what is being exploited, by whom, with which payloads, separated from the noise that inflates everyone else's numbers. The same fleet can be deployed inside a client's own environment, so the intelligence reflects the adversaries and campaigns actually targeting that organization rather than the internet at large.
We publish a new field report every month. Follow OffSeq to get each one as it lands.
§ 09. Disclosure timeline
- 2026-06-21 Observation window opens across the Mirage honeypot fleet
- 2026-07-20 Window closes; first monthly Mirage field report compiled