TI-2026-098 — Who Scans the Scanners: The Attack Surface of the Machines That Attack Us

Classification: HIGH · Forensic threat intelligence · Reverse-recon vector · Series: Counter-Recon

Every dossier in this program reads what the attackers do to the sensor. This one turns the sensor's own instruments around and looks at the attackers themselves — not their behaviour, but their machines. When a source hammers the honeypot hard enough, the honeypot scans it back, quietly, through Tor, and records what it finds. Do that six thousand times and a picture forms that overturns the usual mental image of "the attackers." They are not, mostly, a cloud of throwaway cameras. They are servers — exposed, unpatched, running full stacks — and a striking number of them are not the attacker's property at all. They are somebody's compromised box, attacking us from behind its own open front door.

1. The Lens, Reversed

The honeypot does not only receive. When an attacking IP crosses a threat threshold, an automated reconnaissance job fires against it — a port and service scan, profiled quick, standard, or full depending on how aggressive the source was (reason: threat=100 hits=42 profile=full). Over 2026-06-06 to 07-23 it ran 6,206 such scans (5,042 completed) against 1,676 distinct attacker IPs.

Two design choices make this defensible and worth describing before any finding. First, it is attack-triggered: the sensor only looks at machines that are already attacking it, and only to characterise them. Second, every scan is routed through Tor — the recent-scan log shows exit nodes 45.13.225.69, 188.68.41.191, 5.255.123.164 — so the honeypot never discloses its own address to the source it is examining. This is counter-reconnaissance: the same dual-use exposure map an attacker buys from a scanning service (TI-2026-085D), pointed back at the attacker, from behind a mask, in self-defence.

What comes back is a census of the attackers' own attack surface.

2. Not Bots — Servers

The first surprise is how many of the attackers are reachable at all. Of 1,676 scanned, 627 (37%) expose at least one service — 1,522 services across just 20 ports. And the shape of those ports is the tell:

That is not the fingerprint of a Mirai swarm of IP cameras. It is the fingerprint of servers — web hosts, mail servers, database boxes, VPS instances. SSH and web dominate, but the long tail is databases (MySQL, PostgreSQL, Redis), full mail stacks (SMTP + IMAP + POP3 + their TLS variants), FTP, DNS, and remote-desktop. The machines attacking the honeypot are, in large part, running the same service stack as the machines the honeypot is pretending to be.

3. What the Version Strings Confess

Service-version fingerprinting turns the census from a port list into a set of portraits, and the portraits are damning. A representative walk through the retained scan results:

• 51.68.126.146 — the twelve-service hosting box. It exposes SSH, FTP, DNS, a full mail stack (SMTP/IMAP/IMAPS/POP3/POP3S), MySQL, and web on three ports. The 8443 service announces itself as "HTTP Server Test Page powered by CentOS-WebPanel.com" running Apache/2.4.34 (Unix) OpenSSL/1.0.1e-fips — OpenSSL 1.0.1e shipped in 2013 and reached end-of-life years ago; it is the Heartbleed-era branch. Beside it, nginx/1.14.2. This is a shared-hosting control-panel box, fully exposed, on crypto a decade past its grave, and it is attacking us.

• 202.29.232.244 and 202.29.240.250 — the Thai sites. Both serve Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_fcgid/2.3.9 PHP/5.4.16 with Bootstrap, jQuery, and Thai-language page titles. PHP 5.4.16 reached end-of-life in 2015. These read as legitimate institutional Thai websites — the kind of long-lived, under-maintained server that gets compromised and quietly enrolled as an attack node.

• 90.230.168.26 — the router. Its web page title is "Teltonika Networks" — the admin interface of an industrial LTE router. 49.124.149.20 — the camera. Port 8080 serves "M51C-IPC" under the product IpcWeb — an IP-camera web UI. These are the textbook IoT victims, attacking the sensor from their own hijacked management panels.

• 103.57.224.219 — the open database. A default "Welcome to nginx!" page sits beside an exposed Redis on 6379 and MySQL on 3306. An open Redis is one of the most reliably-abused exposures on the internet, and here it is on a machine that is itself mid-attack.

• 192.169.201.223 — eleven services behind a disguise. It presents an Apache page titled "Just a moment..." — the visual signature of a Cloudflare challenge, here served locally — while exposing MySQL, a full mail stack, DNS, FTP, and SSH beneath it.

The pattern across all of them is the same: the machine attacking us is exposed, unpatched, and frequently not the attacker's own hardware.

4. The Attacker Is the Victim

This is where the census stops being a curiosity and becomes a thesis. TI-2026-019D observed it for a single botnet: a server compromised by Outlaw becomes both an attack platform and a data-exposure point — its own databases and services now reachable by the botnet operator and by anyone else who scans it. The scan-back generalises that observation into a population statistic.

A Thai university web server on dead PHP; a Teltonika field router; an IP camera; a CentOS-WebPanel shared host on Heartbleed-era OpenSSL; a box with an open Redis — none of these was built to attack a honeypot. Each is a legitimate (or once-legitimate) machine that was itself breached, and is now spending its stolen cycles brute-forcing SSH against the internet while its own front door stands open. The infrastructure attacking us is, to a large and measurable degree, the same infrastructure that got attacked first. The 37% exposure rate is not a sign of careless attackers; it is a sign that "the attackers" and "the victims" are heavily the same set of machines, one compromise deep.

That reframes the defensive picture. Blocking 51.68.126.146 stops one attack source; understanding that 51.68.126.146 is a hijacked hosting box tells you the real actor is elsewhere, riding it — and that the box's owner is also a victim who does not know it.

5. The Counter-Narrative

Steelman. "You scanned other people's machines and made a list of their open ports. That is trivially easy, ethically grey, and you found zero vulnerabilities — so you have a port scan dressed up as intelligence, and possibly a liability."

The objection deserves a direct answer on all three counts:

• "Zero vulnerabilities — so nothing." The zero is stated as the finding, not hidden. The recon confirmed 0 vulnerabilities across all 1,676 scans, and this dossier claims exposure, not exploitability. That distinction is the intellectual spine of the piece. The EOL software (OpenSSL 1.0.1e, PHP 5.4.16) is read from version strings and flagged as plain version-risk — visible, undeniable exposure — but no CVE was confirmed against any host, and none is asserted. A port scan that honestly refuses to claim exploitability is more trustworthy than one that infers it.
• "Ethically grey." Acknowledged, and bounded by design. The scan-back is attack-triggered (only machines already attacking the sensor), characterisation-only (no exploitation attempted — the zero-vuln result is consistent with that), and Tor-masked (the sensor is never exposed). Whether one runs active counter-recon at all is a real policy choice; this documents that when it is run this way, it is defensive and self-protective, not offensive.
• "Trivially easy." The technique is easy; the finding is not the technique. The finding is the population shape — 37% exposed, server-profiled, EOL-laden, and heavily compromised-legitimate. That is a statement about the nature of the attacking population, which a hundred individual port scans do not give you until you aggregate them, which is exactly what 6,206 of them do.

What is not claimed: that any scanned host is exploitable (0 vulns confirmed); that the scan-back is universally advisable (it is a policy choice, run here defensively); that every exposed attacker is a compromised victim (many are rented VPS the attacker owns) — only that a large, documented subset visibly is; or that naming these IPs endangers anyone (they are already-active attackers against the sensor, published as defensive IOCs).

Confidence: HIGH that 37% of scanned attackers expose a server-profile service stack, that the version strings show widespread EOL software, and that zero vulnerabilities were confirmed; MEDIUM that a large fraction of the attack infrastructure is compromised legitimate machines (strongly indicated by the router/camera/institutional-site portraits, but not provable host-by-host from a scan alone).

6. Defence Response

• Treat a hostile IP as a lead, not just a block. An attacking source that is itself an exposed server, a router admin panel, or a camera is very likely a compromised third party. Blocking it protects you; recognising it as a victim tells you the real operator is one hop back and that abuse-reporting to the host's owner may take the source down at the root.
• Read exposure from version strings without over-claiming. You do not need a vulnerability scanner to know that OpenSSL 1.0.1e and PHP 5.4.16 are indefensible in 2026. Product/version fingerprinting is cheap, safe, and honest — flag the EOL software as risk, and stop there unless you have a confirmed CVE.
• If you run counter-recon, run it like this. Attack-triggered, characterisation-only, and through an anonymising layer so you never hand your attacker your own address. Never escalate to exploitation; the value is the portrait, and the portrait is legal and safe to take.
• Watch your own front door. The lesson the attackers teach by example: the machine that attacks others is often the one that left an open Redis, a dead PHP, a default panel. The same census, run on your own estate, is the one worth doing first.

7. A Note on Method

Built through the honeypot's reverse-recon store — honeypot_recon_summary for the scan population, port/service census, Tor-exit routing, and the zero-vulnerability result, and honeypot_recon_services_intel for the per-host product/version portraits (CentOS-WebPanel, the Thai PHP-5.4 sites, the Teltonika router, the M51C camera, the open Redis). No SQL touched the investigation. The scans are the sensor's own defensive counter-recon; this dossier only reads their results.

8. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence