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
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 →
02
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 →

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. Attacker-supplied URLs are never fetched from a sensor — requesting one identifies the sensor to its operator.
  • 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. Both writeups above 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.

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. Nothing is inferred, scraped, or aggregated from third-party feeds.

Honeypot blocklist and methodology →