rud.is

HMEFB: Anatomy of a Belarusian Worm

I found this story because of a re-post on Mastodon by Fritz Adalis regarding a suspicious User-Agent by Jason Callahan of SANS’s ISC. He found something odd in his DShield honeypot logs: a URI path that read /?_HELP_ME_ESCAPE_FROM_BELARUS_PLEASE_. In the User-Agent header, an email address: HelpMeEscapeFromBelarus@proton.me.

The SANS diary — isc.sans.edu/diary/33130 — laid out what Callahan found: around a dozen HTTP requests over a two-month period, from IPs scattered globally with no discernible pattern — pointing to a self-propagating bot rather than a single attacker. A Reddit thread on r/selfhosted described the same requests hitting a Traefik reverse proxy. Someone in that thread emailed the address in the User-Agent and got a reply pointing to a page on a free web hosting service.

I and Glenn Thorpe run a small fleet of honeypots in our scant spare time. After reading the SANS diary I pulled a PCAP of similar sessions our of our collector and started picking it apart. This contents of this post is what I found.

Following the link

The page that Reddit user got pointed to (it’s also in one of the user agent strings) is hmefb.fwh.is/?i=1, titled “HMEFB // PROJECT_ROOT”. It’s a manifesto from someone named Alex, a 27-year-old engineer living in Belarus. Full text is at that URL (NOTE: some “security” products flag it as unsafe). Here’s the skinny on it.

Alex describes a self-propagating worm that scans random IP addresses for open HTTP and SSH ports. On HTTP:

It scans random IP addresses for open HTTP ports (TCP 80, 8000, 8080, etc.) and SSH ports (TCP 22, 2222). If it finds an open HTTP port, it simply sends a request to the server using a random method (GET, CONNECT, or HEAD).

On SSH:

If it finds an open SSH port, it begins a password brute-force attack, but only using default combinations like admin:admin, root:root, or support:support. No exploits, no other malicious actions.

He’s explicit about the lifecycle:

The bot is also fully autonomous – it doesn’t connect to a command-and-control server and runs entirely on its own. It only reports discovered IP and login:password pairs back to a loader. Additionally, the bot has a built-in timer: six months after it starts, it self-terminates. If your device has become part of this network of spreader bots, simply reboot it (in theory, at least). The bot doesn’t establish persistence on the system and usually runs from /tmp.

Alex isn’t crafting a CVE writeup. He appears to be trying to leave Belarus. He frames the worm as a project, attempts transparency about its harm, and explicitly invites contact:

I am not interested in funding or sponsorship in any form. Please view this as a highly specific performance piece – one without parallels, as far as I’ve been able to find.

He also notes he’ll be cut off from the internet starting May 19, 2026. Keep that date in mind.

The SANS diary takes a skeptical stance on all of this, and rightly so:

Sob stories and appeals to sympathy are also a known social-engineering lever, and a URI designed to make analysts pause and read a web page rather than immediately blocklist an IP is an effective way to buy a scanner some goodwill.

Callahan’s conclusion: “treat it as an untrusted, credential-guessing scanner.” Fair. But the PCAP tells a more interesting story than either the manifesto or the SANS diary alone.

The capture

Over roughly forty days — May 10 through June 19, 2026 — our tiny fleet received the kind of probe Alex describes. The capture file I extracted has 2,167 packets, 318 KB, all TCP/IP, all HTTP, no TLS.

A quick protocol hierarchy check via tshark (the Wireshark command-line packet analyzer):

$ tshark -r belarus-sessions.PCAP -q -z io,phs
===================================================================
Protocol Hierarchy Statistics
Filter:

frame                                    frames:2167 bytes:284118
  eth                                    frames:2167 bytes:284118
    ip                                   frames:2167 bytes:284118
      tcp                                frames:2167 bytes:284118
        http                             frames: 406 bytes:147498
          data-text-lines                frames: 162 bytes: 84270
===================================================================

I focused on the HTTP requests since they’re easier to find, though I did confirm there were SSH shenanigans going on in the same time frame. The HTTP number around 205, using two distinct User-Agent strings; the remaining packets are TCP handshakes, ACKs, and response payloads.

Forty days, small packet count. That’s consistent with the worm’s described behavior: one request per open port, then move on. Not a high-volume scanner.

Two user-agent variants, two distinct campaigns

The HTTP requests split into two distinct populations based on User-Agent. The original variant – 159 requests:

Wget/1.21.4 (HelpMeEscapeFromBelarus@proton.me)

The extended variant – 46 requests:

Wget/1.21.4 ( https://hmefb.fwh.is | HelpMeEscapeFromBelarus@proton.me)

The two variants targeted different sets of ports and came from different kinds of infrastructure. That’s where it gets interesting.

Different ports, different responses

The 159 requests with the original User-Agent targeted ports 80, 81, 8000, and 8080 – exactly the ports Alex names in his description. The 46 requests with the extended User-Agent targeted a different set entirely: 82, 8002, 8088, 8090, 9000, and 9090.

The extended User-Agent variant and non-standard port probing overlapped exactly. Both came exclusively from TOR exit nodes. Both stopped May 17, 2026.

The TOR exit node revelation

Of the 44 unique source IPs in the PCAP, 31 are listed on the TOR exit node list. TOR – The Onion Router – anonymizes traffic by bouncing it through multiple volunteer-operated relays before it exits to the public internet; the destination sees the exit node’s IP rather than the original requester’s. Seventy percent of the source IPs in this capture are exit nodes.

Cross-referenced against geolocation and ASN data, the TOR exit ranges break down as:

All 31 TOR exit IPs used the extended hmefb.fwh.is User-Agent variant. None of the non-TOR sources did. That’s a deliberate OPSEC choice. Whoever ran those TOR-routed probes wanted them identifiable as a separate campaign – wanted the URL traced back to HMEFB.

The compromised hosts

The remaining 13 source IPs do not appear to be TOR exit nodes. They’re a mix residential ISPs and VPS providers across several continents:

(Counts are packets per ISP, reflecting scan volume from that operator’s range.)

These are the worm’s actual victims – exactly the kinds of hosts a low-and-slow self-propagating scanner lands on: routers, IoT devices, VPS instances, home networks running default SSH credentials. The IPs come from cable and fiber residential ranges or small-business ISP blocks (not Hetzner, DigitalOcean, AWS, etc.). The worm is living on consumer gear.

Alex confirms this reading:

That line in your logs is the work of a bot. It’s harmless by design but operates like a worm.

The timeline

The PCAP’s burst of TOR-routed probing lines up precisely with Alex’s note on the HMEFB page:

Also, starting from the 19th, I will be cut off from the outside world and likely unable to follow how the situation unfolds or respond to messages.

The TOR-routed probes stopped May 17, 2026 – two days before the date he named. Whatever was happening through TOR, it stopped on schedule.

The SANS ISC diary notes the bot was first reported to ISC in May 2026, with reports peaking shortly after the first sighting before a sharp drop — consistent with what the PCAP shows.

What the worm is, and what it isn’t

Callahan’s SANS diary concludes: “treat it as an untrusted, credential-guessing scanner.” That’s the right defensive posture. The HMEFB worm isn’t malware in the conventional sense – it’s a network scanner that propagates itself, runs from /tmp, persists for six months at most, and only attempts default SSH credentials. It doesn’t exploit anything. The only data it reports back to a loader is IP plus credential pairs – not exfiltrated files, not session tokens.

But “not malware in the conventional sense” doesn’t mean harmless. Self-propagating scanners consume bandwidth, hammer SSH daemons with failed login attempts, and embed themselves on devices that already have weak security postures. If you find it on a host you operate: kill the process, rotate any default SSH credentials, and audit whether port 22 actually needs to be publicly exposed. Rebooting (in theory) clears it – the manifesto says so, and the PCAP and SSH session behavior appears consistent with that claim. But, you never can tell with bees.

What the PCAP adds to the picture is the two-campaign structure. The worm spreading on compromised consumer gear across a dozen countries is one thing. A separate, deliberate set of probes routed through TOR exit nodes, using an extended User-Agent that points back to a named URL, hitting non-standard ports on honeypots — that’s a different kind of operation. Someone running probes through TOR and signing them with a link to their manifesto wanted those probes found and read.

The SANS diary understandably focuses on the defensive posture. The PCAP shows you can do both: block the scanner, clean the compromised hosts, and still recognize that someone out there is using a worm as a job application.

The hmefb.fwh.is page closes with:

Thank you for reading this rambling monologue. I hope I haven’t caused you any inconvenience.

[ Send A Message ]