Research

What attacks thedecoys, and how.

I run internet-exposed honeypot sensors — SSH, FTP, telnet, MySQL, VNC, and email — and analyze what comes at them. The sensors produce a free public blocklist. The captures produce the writeups below.

01
RedTail brings its own key
RedTail no longer uploads its binaries. It writes a private key onto the machine it broke into and has the victim pull the installer from the botnet's own server over SFTP. 296 sessions, one key, three servers in ten weeks, and a correction to the capture below.
Read →
02
Kill everything that deleted itself
A seven-line script typed in hex kills every process whose program file no longer exists. It clears out rival bots, which delete themselves after starting, and on a patched server it would also kill every service waiting for a restart.
Read →
03
A download server inside ip6.arpa
A loader sent infected devices to a host name in the IPv6 reverse-DNS tree, where nothing is registered and no domain reputation applies. Fifteen hours later the same server handed out the same script with a raw IP address.
Read →
04
Three builds in twenty hours
One address served the same x86-64 bot three times in twenty hours, and each build carried more exploits: three, then six, then eight, ending with Confluence and WebLogic. The bot logs every attempt by CVE number.
Read →
05
One login, one dropper
A telnet session that lasted seconds fetched a shell dropper for fourteen CPU architectures and left. Below any volume floor, so the address never made the blocklist. The capture, the dropper's one-second liveness trick, and the loader tier the feed gained because of it.
Read →
06
Clean logs by design
A phishing redirector whose tracking identifier lives in the URL fragment — the one part of a link that is never sent to a server. The hosting stays clean while the campaign runs, so the abuse report you file against it describes nothing happening. The mail itself passed SPF, DKIM and DMARC, because the mailbox sending it was genuinely compromised rather than spoofed.
Read →
07
A self-propagating Go ransomware worm
A stripped, obfuscated Go binary that carries its own scanner, SSH brute-forcer, encryptor and ransom-note generator in one file. It reads known_hosts to pick targets and builds passwords from the account names it finds. Static analysis only — nothing was executed.
Read →
08
RedTail: one dropper, every architecture
Four UPX-packed ELF binaries delivered inside the same minute, one per architecture, on the theory that one of them will run. A study in how little the operator knows about the box they just got into — and in why the attacker's own filenames turned out to be better evidence than my string analysis.
Read →

Incident casework

Four enterprise incidents I worked in early 2026, written up at the time and published here with the organization, sector, roles, dates and third-party victims anonymized. Attacker infrastructure, hashes and indicators are shown as observed. These are not honeypot captures; they are what the same discipline looks like when a real user has already clicked.

Scope

What this operation does

  • Passive collection on infrastructure I own and control
  • Static analysis of captured samples — structure, strings, embedded configuration
  • Log correlation across sensors to reconstruct delivery and intent
  • Published indicators and a CC0 blocklist that ages entries out after 30 days

What it does not do

  • No detonation. Samples are not executed, not made executable, not unpacked live on a sensor.
  • No callbacks from me. I do not contact attacker infrastructure, and I do not use keys or passwords attackers leave behind. The decoys do retrieve what an attacker's own command asks for; that is how payloads are captured. Corrected 2026-10-23: this line used to say a sensor never fetches an attacker-supplied URL.
  • No offensive activity, against anyone, for any reason.
  • No attribution beyond infrastructure. A rented VPS identifies a box, not a person.

Handling policy

Outward-facing actions about third-party infrastructure — abuse reports, sample submissions to public multiscanners, blocklist inclusion — have consequences for people who cannot see this site and did not agree to be studied. They are made deliberately, by a named person, and reversibly where reversal is possible.

  • Samples are not uploaded to public multiscanners by default. Uploading a file makes it downloadable by any paid subscriber of that platform. Hash lookups are the safer default; even those are visible to the platform.
  • Abuse reports are filed against sustained activity, not single events. A short incident is not a pattern, and reporting it as one is a claim about a stranger I cannot support.
  • Blocklist entries expire after 30 days of inactivity. A short honest list you can drop into a firewall beats a large stale one that punishes today's innocent reassignee.
  • Delisting contact is published and answered. If your address is on the list and should not be, say so and it comes off.

Corrections

Findings here get corrected in place, with the correction left visible rather than the error quietly deleted. The first three captures carry one.

In the first, I read three upload retries as a human at a keyboard. The client fingerprint contradicted it and I was wrong; the correction is in the text where the original claim was. In the second, the family attribution comes from the attacker's own filenames rather than from my analysis, and it is labelled that way — strong evidence, not forensic proof.

In the third, I wrote that the sensor never fetches attacker URLs, that no hash lookups were made, and that a private key and SSH config left on a decoy were persistence staging rather than a botnet loader. All three were wrong. The decoy had retrieved the dropper itself and its hash was checked automatically, and the key was RedTail's loader, which became its own writeup. The corrections are in the text where the claims were.

Separately, and not in either writeup: I once asserted that a report filed from this sensor had cost a host their hosting. I had not verified it, and on going back to the correspondence it was not true — the thread had closed with a thank-you from the operator. The argument I was making did not depend on that harm being real, and inflating it was exactly the failure the rule was meant to catch. It is recorded here because an analysis operation that never publishes a retraction is not careful, it is unaudited.

The data

The sensors publish a live IP blocklist, refreshed hourly, in plain text, JSON and CSV under CC0. Every address on it attacked a decoy service, at volume or by delivering a payload. Nothing is inferred, scraped, or aggregated from third-party feeds.

Honeypot blocklist and methodology →

All forensic audits and investigations, with investigator verification →