PoeLLM Canto Incognito: The Botnet Hiding C2 in a GitHub Poem

PoeLLM Canto Incognito: The Botnet Hiding C2 in a GitHub Poem

Executive Summary

Lumen's Black Lotus Labs has tracked Canto Incognito, a financially motivated campaign using the PoeLLM malware to compromise more than 3,400 servers since April 2026. The campaign is unusual because its command-and-control address is encoded in four words inside a poem hosted on GitHub.

The technique is more than a curiosity. The operator can redirect infected hosts by editing the poem rather than shipping a new malware build. Most observed victims were exposed services associated with LiteLLM, Ollama, Gotenberg, and Gitea. Compromised systems were then used to scan for and exploit more vulnerable hosts, while XMRig and Iron miners monetized the access.

What happened?

Black Lotus Labs first encountered the campaign while investigating an Ivanti Sentry victim that contacted PoeLLM infrastructure. The broader operation expanded in May, when the actor began scanning for internet-facing services and turning successful compromises into additional scanning and exploitation workers.

The campaign's control mechanism is a GitHub repository containing a two-stanza poem. PoeLLM reads selected words, converts them into numbers, and combines the values into an IPv4 address. Black Lotus Labs observed the poem being changed repeatedly, allowing the operator to move command infrastructure without updating every infected server.

Lumen says the campaign reached more than 3,400 victim servers, with peak activity exceeding 800 active servers per day. The operator's infrastructure also relied on compromised routers and other vulnerable systems rather than only leased servers, complicating takedown and attribution.

Why AI infrastructure became part of the target set

The campaign repeatedly targeted exposed services used to run or connect AI workloads. Black Lotus Labs identified a LiteLLM endpoint, /mcp-rest/test/connection, as a likely exploitation path in one sample, alongside activity involving Ollama. The important defensive lesson is not that AI software is uniquely vulnerable; it is that new developer and AI services are often deployed quickly, exposed to the internet, and left with weak authentication or incomplete patch coverage.

An exposed model gateway can therefore become an ordinary server-compromise path. Once the host is controlled, the attacker can use its CPU for cryptomining, use its network location for scanning, and treat it as a disposable relay for further exploitation.

The observed infection chain

1. Discovery: the actor scans internet-facing services, including AI and document-processing deployments.
2. Initial compromise: a vulnerable endpoint is exploited and PoeLLM is installed.
3. C2 resolution: the malware retrieves the GitHub poem and derives the current control-server address.
4. Expansion: the infected host scans for additional exposed services and helps launch exploitation attempts.
5. Monetization: XMRig and Iron miners consume victim resources and connect to Kryptex mining infrastructure.

This is a botnet with a feedback loop: every newly compromised server can increase the operator's ability to find more victims. That makes exposure reduction and containment more urgent than the mining payload alone might suggest.

Detection and response priorities

1. Inventory exposed AI and developer services

Identify internet-facing LiteLLM, Ollama, Gotenberg, Gitea, and similar deployments. Confirm versions, authentication requirements, administrative interfaces, and whether the service is intended to be public at all.

2. Hunt for miner and scanner behavior

Look for unexpected XMRig or Iron processes, sustained CPU usage, outbound connections to mining infrastructure, and bursts of scanning from servers that normally make only application traffic. Review process ancestry and persistence rather than relying only on malware filenames.

3. Treat compromised hosts as pivot points

An affected server should be isolated, rebuilt from a trusted image where appropriate, and investigated for credentials, SSH keys, tokens, and lateral movement. Do not stop at killing the miner: the scanning role indicates that the host may have been active in the campaign before the payload was detected.

4. Monitor GitHub-based resolution patterns

Outbound access to a specific public repository is not automatically malicious, but defenders should flag server-side processes that repeatedly fetch mutable text from GitHub and immediately use parsed values as network destinations. Combine DNS, proxy, process, and egress telemetry to reduce false positives.

The broader lesson

Canto Incognito shows how attackers can combine ordinary weaknesses with a creative infrastructure layer. A public GitHub poem is not a magic evasion technique; it is a low-cost configuration channel that lets the operator change destinations while infected hosts keep running the same code.

For defenders, the practical response is straightforward: reduce unnecessary exposure, patch internet-facing services, enforce authentication, restrict outbound traffic, and investigate servers that become scanners or miners. The unusual C2 story should draw attention, but the durable risk is familiar—unmanaged services can become both victims and force multipliers for the next wave of compromise.

References

1. Canto incognito: tracking the PoeLLM malware
2. Cryptomining malware used poetry to infect more than 3,400 servers
3. Attackers use poem to infect thousands of servers