はじめに――パソコンではなく「ネットワークそのもの」が狙われる
サイバー攻撃と聞いたとき、多くの人が思い浮かべるのは、パソコンへ侵入するマルウェアや、企業のデータを暗号化して身代金を要求するランサムウェアではないでしょうか。
しかし、今回取り上げる攻撃は少し違います。
攻撃者が狙っているのは、私たちが普段使っているパソコンだけではありません。
- 通信を運ぶルーター
- ネットワーク管理者を認証するシステム
- 多数のコンピューターやネットワーク機器を管理するサーバー
つまり、企業や組織が「こちら側は信用できる」と考え、その上に情報システムを構築してきたITインフラそのものです。
そのような攻撃活動を続けている脅威アクターが、Fire Ant（ファイア・アント）です。
2026年8月27日、サイバーセキュリティ企業Sygnia（シグニア）は、Fire Antについて新たな調査報告を公開しました。
Sygniaによれば、Fire Antは2025年に確認された活動からさらに攻撃範囲を拡大し、2026年にはCisco IOS XR（シスコ・アイオーエス・エックスアール）を搭載したルーター、TACACS（タカックス）認証基盤、Linux（リナックス）管理ホストなどへ侵入していました。
しかも、その目的は単に機器を壊すことではありません。
侵害したルーターを通信の収集拠点として利用し、認証情報を集め、秘密裏にアクセスを維持し、さらには攻撃者自身の活動を示すログや表示情報まで操作していたことが確認されています。
そして、侵害した環境を足掛かりとして、その先につながっている価値の高いネットワークへの到達経路を探っていたとSygniaは分析しています。
これは、かなり重要な意味を持っています。
Fire Antとは何者なのか
Fire Antは、Sygniaが追跡しているサイバー脅威アクターの名称です。
ここでいう“Threat Actor（スレット・アクター／脅威アクター）”とは、サイバー攻撃を実行する個人、集団、あるいは組織的な主体を指します。
SygniaはFire Antを中国との関連性が指摘される“China-nexus threat actor（チャイナ・ネクサス・スレット・アクター）”として扱っています。
さらに、Google傘下Mandiant（マンディアント）が追跡してきた中国系サイバー諜報活動グループ“UNC3886（ユー・エヌ・シー・スリー・エイト・エイト・シックス）”との間に、活動手法などの強い重複があると評価しています。
ただし、ここは注意が必要です。
現時点で公開されている情報だけから、「Fire Ant＝UNC3886」と断定するべきではありません。
重要なのは名前ではなく、彼らが“どこを狙っているのか”です。
Fire Antが2025年に注目されたとき、攻撃対象となっていたのはVMware ESXi（ヴイエムウェア・イーエスエックスアイ）やvCenter（ブイセンター）などの仮想化基盤でした。
“Hypervisor（ハイパーバイザー）”とは、一台の物理コンピューター上で複数の仮想コンピューターを動かすための基盤です。
一般利用者が毎日操作するような場所ではありません。
だからこそ重要なのです。通常のパソコンに導入されるEDR（イー・ディー・アール／Endpoint Detection and Response）の監視から外れやすい一方、その上では多数のサーバーや業務システムが動いている可能性があります。
Fire Antは、こうした“「多くのシステムから信用され、高い権限を持ち、それでいて一般的な端末監視からは見えにくい場所」”を狙ってきました。
そして2026年、その考え方がさらに拡大します。
標的となったのは…
- ルーター
- 認証サーバー
- Linux管理ホスト
- アクセスを管理する装置
つまり、「通信する」「認証する」「接続する」「管理する」ための基盤です。
Sygniaはこれを“Trusted Infrastructure（トラステッド・インフラストラクチャ／信頼されたインフラ）”への攻撃として位置付けています。
なぜ、この攻撃は怖いのか
ここで一度、技術用語から離れて考えてみます。
銀行の建物に泥棒が侵入したとしましょう。
金庫から現金を盗めば、それだけでも重大事件です。
しかし…
- その泥棒が金庫を盗むのではなく、
- 監視カメラを操作し、
- 警備員の身分証明システムを掌握し、
- 建物の出入口を自由に操作し、
- 警備記録を書き換え、
- さらに、その銀行と地下通路でつながっている別の施設への経路まで調べていた
…としたらどうでしょうか。
今回Fire Antが行っていた活動は、技術的にはまったく同じではありませんが、問題の構造を理解するには、このように考えると分かりやすいでしょう。
- ルーターを支配すれば、通信の流れを見ることができます。
- 認証基盤を支配すれば、管理者の認証情報を狙えます。
- 管理サーバーを支配すれば、さらに多くのシステムへ接近できます。
- そしてログや管理画面に表示される情報まで操作できれば…
防御側は、「自分たちが見ている情報そのものが正しいのか」というところから疑わなければならなくなります。
Sygniaが今回確認した活動では、Fire AntはCisco IOS XRルーターを単なる侵入先としてではなく、秘密通信、トラフィック収集、コマンド出力の操作、ログ抑制などを行う“Operational Platform（オペレーショナル・プラットフォーム／攻撃活動の実行基盤）”として利用していました。
本来、企業を守り、通信を支えるためのITインフラが、攻撃者によって別の目的に利用される。
言い換えれば、「守る側のシステム」が「攻撃する側のシステム」へと反転してしまうのです。
ここにFire Antの恐ろしさがあります。
なぜCiscoのルーターなのか
ここでCisco（シスコ）が登場します。
Cisco Systemsは、企業や通信事業者などが利用するネットワーク機器・ネットワーク技術を世界規模で提供しています。
今回Fire Antの侵害が確認されたのが、Cisco IOS XRを搭載したルーターでした。
IOS XRは、大規模なネットワーク環境などで利用されるCiscoのネットワークOSです。
“OS（オーエス／Operating System）”という言葉なら、Windows、macOS、Linuxを思い浮かべる人も多いでしょう。
ルーターにも、その装置を制御するOSがあります。
Cisco IOS XRもその一つです。
ここで非常に重要なのは、「Ciscoがサイバー攻撃を受けた」という話ではないということです。
今回Sygniaが報告しているのは、Ciscoという企業そのものへの侵入ではなく、ある侵害環境に存在していたCisco IOS XRルーターなどがFire Antによって掌握されていた事案です。
そして現時点では…
Fire Antが最初にどのような経路で対象環境へ侵入したのかは明らかになっていません。
したがって、「Cisco製品に脆弱性があったからFire Antが侵入した」と現段階で結論付けることもできません。
2026年9月にはCiscoがIOS XRについて複数の脆弱性を修正するSecurity Hardening Release（セキュリティ・ハードニング・リリース）を公開していますが、この事実とFire Antの侵入経路を証拠なしに結び付けてはいけません。
Ciscoが9月に公開したアドバイザリーには複数のCVEが記載されていますが、それは今回のFire Ant事案の初期侵入原因を意味するものではありません。
では、Fire Antがルーター内部へ侵入した後、いったい何をしていたのでしょうか。
Sygniaの調査は、非常に奇妙な現象から始まります。
「存在しないはずのトンネル」が動いている
Cisco IOS XRルーターを調査していたインシデントレスポンスチームは、ある異常を発見しました。
ルーター上で…
GRE（ジー・アール・イー／Generic Routing Encapsulation）
…を利用したトンネルインターフェースが動作していたのです。
GREとは、簡単にいえば…
既存のネットワークの中に、別の仮想的な通信経路――「トンネル」を作るための技術
…です。
GREそのものは攻撃技術ではありません。
企業ネットワークでも利用される正規のネットワーク技術です。
問題は、そのトンネルが存在している理由を説明できなかったことでした。
管理者が確認する“Running Configuration（ランニング・コンフィギュレーション／現在有効になっている設定）”には、そのトンネルを説明する設定がありません。
さらに…
Commit History（コミット・ヒストリー／設定変更の履歴）
…を調べても、なぜそのトンネルが作られたのかを説明できませんでした。
ところが――
トンネルは実際に動いている。
つまり…
「管理者から見える設定」と「ルーター内部で実際に起きていること」が一致していなかった
のです。
これは単なる設定ミスとは意味が違います。
ネットワーク管理者は通常、設定情報、ログ、コマンドの出力などを見ながら、「この機器はいま、どのような状態なのか」を判断します。
しかし、その情報そのものを攻撃者が操作できるとしたらどうでしょう。
Fire Antの侵害を追っていくと、この疑問はさらに深刻になります。
なぜなら攻撃者は、単に見えないトンネルを作っていただけではなかったからです。
Fire Antは、Cisco IOS XRというルーターの内部へ深く入り込み…
ログを抑制し、管理者が実行するコマンドの出力を操作し、通信を収集し、さらに外部との秘密の通信経路を維持するための専用ツール群まで持ち込んでいました。
ここから、この事件は単なる「ルーターへの不正アクセス」という説明では足りなくなります。
攻撃者は、ルーターが正常に動いているように見せながら、自分たちのためにも働かせようとしていたのです。
次に、そのCisco IOS XR内部でFire Antが何を仕掛けていたのかを、一つずつ見ていきます。
ルーターの内部でFire Antは何をしていたのか
前章で確認した「存在しないはずのGREトンネル」
これは、Fire Antの活動を追跡する入口にすぎませんでした。
調査を進めたSygniaは、Cisco IOS XRルーターの内部で、通常とは異なるプロセスやファイル、通信収集、ログ抑制など、複数の不審な活動を確認していきます。
ここで重要なのは、Fire Antがルーターを破壊しようとしていたわけではないことです。
むしろ逆です。
ルーターには正常に働き続けてもらう必要がありました。
通信を運び続け、管理者から見ても大きな異常がないように見える。
その裏側で、攻撃者自身のための処理も動かす。
これは、ランサムウェアのように被害を顕在化させる攻撃とは性質が大きく異なります。
Fire Antに必要なのは「破壊」ではなく、
Persistence（パーシステンス／永続化）――侵入した環境へ長期間とどまり続けること
でした。
「acpid」に偽装した不審なプロセス
Sygniaが確認した重要な痕跡の一つが、acpid（エーシーピーアイ・ディー）という名前で動作するプロセスでした。
Linuxに触れたことのある人なら、この名前を見ても、それほど不自然には感じないかもしれません。
一般にACPI（エーシーピーアイ／Advanced Configuration and Power Interface）は、コンピューターの電源管理などに関係する仕組みです。
そのため「acpid」という名前そのものは、いかにもシステム内部に存在していそうに見えます。
ところがSygniaがCisco IOS XR環境で確認したacpidは、正規のシステムプロセスではありませんでした。
Fire Antが持ち込んだ不正なELFバイナリだったのです。
“ELF（エルフ／Executable and Linkable Format）”とは、LinuxなどのUnix系OSで広く利用される実行ファイル形式です。
Windowsでいう「.exe」に近いもの、と考えると分かりやすいでしょう。
ここにもFire Antの特徴が表れています。
「いかにも怪しい名前」のプログラムを動かすのではなく、
正規のシステムプロセスに見えそうな名前を使う。
管理者がプロセス一覧を確認しても、一見しただけでは異常と判断しにくくするためです。
これは“Masquerading（マスカレーディング／偽装）”と呼ばれる考え方です。
攻撃者がファイル名、プロセス名、配置場所などを正規のものに似せ、発見されにくくする手法です。
しかし、このacpidが行っていたことは、電源管理とはまったく異なっていました。
Sygniaの解析によると、この不正バイナリには、攻撃者がCisco IOS XR内部で活動するための複数の機能が組み込まれていました。
その一つが、Unix Domain Socket（ユニックス・ドメイン・ソケット）を利用した内部通信です。
ソケットとは、プログラム同士が情報をやり取りするための「通信口」のようなものです。
通常インターネット通信ではIPアドレスとポート番号を使いますが、Unix Domain Socketは同じシステム内部のプロセス同士が通信する際に利用できます。
つまりFire Antは、外部との通信だけでなく、
ルーター内部でも、自分たちの処理を連携させる仕組みを作っていた
ことになります。
管理者が見る「コマンドの結果」にまで手を伸ばす
ここから、さらに厄介になります。
ネットワーク管理者がルーターの状態を確認するとき、CLI（シー・エル・アイ／Command Line Interface）を利用します。
文字でコマンドを入力し、機器から返ってきた情報を見ながら状態を確認する操作画面です。
例えば…
- 「どのインターフェースが動いているのか」
- 「どのような設定が入っているのか」
- 「どのプロセスが動作しているのか」
…といった情報をコマンドで調べます。
インシデントが疑われれば、当然ながら管理者や調査担当者もCLIを使います。
ところがFire Antは、ここにも手を伸ばしていました。
Sygniaは、Cisco IOS XR上でコマンドの出力内容を操作するための仕組みを確認しています。
これは極めて重要です。
なぜなら…
管理者が正しいコマンドを入力しても、攻撃者に都合の悪い情報が結果から取り除かれていれば、管理者は「異常なし」と判断してしまう可能性があるからです。
例えば警備員が監視カメラを確認したとします。
映像には誰も映っていない。
しかし…
「誰も侵入していない」のではなく、
侵入者自身が、自分の姿だけ映像から消していた
…としたらどうでしょう。
Fire Antが行ったことを理解するうえで、この違いは非常に重要です。
単に監視を避けるのではありません。
監視するために使われる情報そのものへ干渉する。
攻撃者が一段深い場所へ入り込んでいることを意味します。
ログに「沈黙」させる
もう一つ、攻撃者にとって邪魔になるものがあります。
“Log（ログ）”です。
ログとは、コンピューターやネットワーク機器で「何が起きたのか」を記録するデータです。
- 誰がログインしたのか
- どのような操作が行われたのか
- どのサービスが起動したのか
- どのようなエラーが発生したのか
インシデント発生後の調査では、このログが非常に重要な証拠になります。
Fire Antは、この記録にも干渉していました。
ここで登場するのが、syslog（シスログ）です。
syslogは、Unix/Linux系システムやネットワーク機器などで広く使われているログ記録・転送の仕組みです。
企業ではネットワーク機器からsyslogサーバーへログを集約し、
SIEM（シーム／Security Information and Event Management）
などで監視している場合もあります。
SIEMとは、さまざまな機器から集めたログやセキュリティ情報をまとめて分析し、異常を発見するための仕組みです。
ところが、攻撃者がログの生成や転送そのものを抑えられるとどうなるでしょう。
SIEMがどれほど高性能でも、届いていない情報を分析することはできません。
Fire AntはCisco IOS XR上でsyslogを抑制し、自らの活動がログとして残りにくくなるよう操作していました。
これは、Defense Evasion（ディフェンス・イベージョン／防御回避）と呼ばれる攻撃行動の典型です。
防御システムを正面から破壊するのではなく、
「防御システムから見えない状態」を作る。
これがFire Antの活動を理解する重要なキーワードです。
ルーターを「通信の観測所」に変える
しかし、Fire AntがCisco IOS XRルーターへ深く潜伏した理由は、隠れることだけではありません。
ルーターには、攻撃者にとって非常に大きな価値があります。
通信がそこを通るからです。
Sygniaは、侵害された複数のCisco IOS XRルーターで、Fire Antがネットワークトラフィックを収集していたことを確認しています。
ここで登場するのが、PCAP（ピーキャップ／Packet Capture）です。
インターネットや企業ネットワークを流れるデータは、
Packet（パケット）と呼ばれる小さな単位に分割されて送受信されます。
PCAPとは、そのパケットを取得して記録したデータのことです。
ネットワーク障害の解析やセキュリティ調査にも使われる正規の技術であり、PCAPそのものが危険なものではありません。
問題は、誰が、何の目的で取得しているのかです。
ネットワークの中心を通過する通信を攻撃者が取得できれば、その中から価値のある情報を探すことができます。
Sygniaの調査では、Fire Antが侵害したCisco IOS XRルーター上でPCAPを取得し、そのデータを外部のFTPインフラへ転送していたことが確認されています。
“FTP（エフ・ティー・ピー／File Transfer Protocol）”は、ネットワーク経由でファイルを転送するためのプロトコルです。
つまり…
通信を運ぶために設置されたルーターが、攻撃者のために通信を収集する観測拠点へ変えられていた
…ことになります。
ここで重要なのは、すべての通信内容がそのまま読めるという意味ではないことです。
HTTPSやSSHなどで適切に暗号化された通信であれば、その内容をPCAPとして取得しただけで直ちに平文を読めるわけではありません。
しかし、それでも通信元・通信先などのメタデータや、暗号化されていない通信、認証情報につながる通信など、攻撃者にとって価値を持つ情報が含まれる可能性があります。
さらに攻撃者にとって重要なのは、「誰と誰が通信しているのか」というネットワーク構造そのものを知ることです。
- どのサーバーが重要なのか
- どこに管理ネットワークがあるのか
- どの機器から別のネットワークへ到達できるのか
つまりPCAPは、情報を盗むだけでなく、次にどこを攻撃するべきなのかを調べるための地図にもなり得ます。
ここまででも、まだ攻撃の半分にすぎない
ここまで確認したFire Antの活動を並べてみます。
- 正規プロセスに見せかけた不正バイナリ。
- GREによる秘密の通信経路。
- CLI出力への干渉。
- syslogの抑制。
- PCAPによるネットワークトラフィックの収集。
- 外部インフラへのデータ転送。
これだけでも、かなり深刻な侵害です。
しかし、Sygniaの調査で明らかになったFire Antの活動は、Cisco IOS XRルーターだけでは終わりませんでした。
攻撃者は、さらに重要な場所へ進んでいました。
「誰をネットワーク管理者として信用するのか」を決めるシステムです。
そのシステムが、TACACS+（タカックス・プラス）です。
ルーターを掌握した攻撃者は、今度は「通信」から「認証」へと手を伸ばします。
そして、そこで発見されたのが、TacTap（タックタップ）と呼ばれるツールでした。
ここからFire Antの攻撃は、さらに深い領域へ入っていきます。
次に狙われたのは「誰を信用するか」を決める場所
Cisco IOS XRルーターへ深く入り込んだFire Ant…
- 通信を収集する
- 自分たちの活動をログに残りにくくする
- 管理者が確認する情報にまで干渉する
- そして秘密の通信経路を維持する
…ここまででも十分に深刻です。
しかし、Fire Antの活動はそこで止まりませんでした。
次に攻撃者が入り込んでいたのは、「この人物にネットワーク機器を操作させてもよいのか」を判断するための認証基盤でした。
ここで登場するのが…
TACACS+（タカックス・プラス／Terminal Access Controller Access-Control System Plus）
…です。
名前だけを見ると難しそうですが、その役割から考えれば理解しやすくなります。
企業には多数のルーター、スイッチ、ファイアウォールなどのネットワーク機器があります。
それぞれの機器に管理者アカウントを個別に作り、別々に権限を管理していたら、機器が増えるほど管理は複雑になります。
そこで、ネットワーク機器へアクセスする管理者の認証や権限管理を集中して行う仕組みが利用されます。
TACACS+は、その代表的なプロトコルの一つです。
そして、その考え方を理解するうえで重要なのが、AAA（トリプル・エー）です。
AAAは…
- Authentication（オーセンティケーション／認証）
- Authorization（オーソライゼーション／認可）
- Accounting（アカウンティング／操作記録）
…の頭文字を取った言葉です。
簡単に言えば…
- 「あなたは誰ですか」
- 「あなたには何をする権限がありますか」
- 「あなたは何をしましたか」
…を管理する仕組みです。
例えばネットワーク管理者がルーターへログインしようとします。
TACACS+を利用している環境では、ルーター側だけでその人物を判断するのではなく、認証を担当するサーバーへ問い合わせます。
「このユーザーを通してよいか」
「この操作を許可してよいか」
そして操作内容を記録する。
つまりTACACS+の認証基盤は、ネットワーク管理の世界における“身分証明所兼、入退室管理室”のような存在だと考えると分かりやすいでしょう。
では、その「誰を信用するのか」を判断する場所そのものへ、攻撃者が入り込んだらどうなるでしょうか。
TacTap――認証情報を狙うための仕掛け
Sygniaは、Fire Antが侵害したTACACS+サーバー上で、TacTap（タックタップ）と呼ばれる不正な仕組みを確認しました。
TacTapの目的は極めて明確です。
TACACS+の認証情報を取得すること。
ここで少し技術的に踏み込みます。
Sygniaによる解析では、TacTapはTACACS+サーバー上で認証処理に関係するデータへアクセスし、認証情報を取得するために使われていました。
つまりFire Antは、「管理者がログインした後の端末を攻撃する」だけではなく、管理者が本人確認を受ける、その瞬間を狙える場所へ入り込んでいたことになります。
ここで登場する重要な言葉が、Credential（クレデンシャル／認証情報）です。
ユーザー名やパスワード、トークンなど、「自分が正規の利用者である」と証明するために使われる情報を総称してCredentialと呼びます。
そして攻撃者が認証情報を狙う行動は、Credential Access（クレデンシャル・アクセス／認証情報へのアクセス）と呼ばれます。
なぜFire Antはこれほど認証情報を欲しがるのでしょうか。
答えは単純です。
正規の管理者になりすますことができれば、攻撃者自身が不正な侵入口を作らなくても、正規の入口から入れる可能性が生まれるからです。
これは非常に厄介です。
ファイアウォールを突破する通信。
未知の脆弱性を悪用する攻撃。
怪しいマルウェア。
こうしたものなら、防御側にも「異常」と判断する材料があります。
しかし、
正しいユーザー名。
正しい認証情報。
正規の管理経路。
を利用してアクセスされた場合、その通信だけを見れば、
「いつもの管理者がログインした」ように見える可能性があります。
攻撃者にとって認証情報とは、単なるパスワードではありません。
正規利用者として振る舞うための“身分証”なのです。
ルーターと認証基盤――二つを同時に考える
ここで、これまで見てきた二つの侵害をつなげてみましょう。
Fire AntはCisco IOS XRルーターへ入り込んでいました。
そこでは通信を観測できます。
そしてTACACS+認証基盤にも入り込んでいました。
そこでは管理者の認証に関係する情報を狙えます。
つまり攻撃者は、「ネットワークを流れる通信」と、「そのネットワークを管理する人間の信用」という二つの重要な場所へ手を伸ばしていたことになります。
これを単独の侵害として見ると、本質を見失います。
ルーターが侵害された。
認証サーバーも侵害された。
それぞれ別の問題――ではありません。
両者を組み合わせたとき、攻撃者が何をできるようになるのか。
そこを見る必要があります。
- ネットワークの構造を調べる
- 通信先を把握する
- 重要なサーバーを探す
- 管理者の認証情報を狙う
- 正規の管理経路を利用する
- さらに別の機器へ移動する
攻撃者が侵入した一台のコンピューターから、別のコンピューターやサーバー、ネットワークへ移動していく行動を、Lateral Movement（ラテラル・ムーブメント／横展開）と呼びます。
Fire Antの活動を理解するうえで、この言葉も重要です。
侵害した機器そのものが最終目的とは限らないからです。
一つの侵害を、次の侵害のための足場にする。
さらに、その足場から次の足場へ進む。
この連鎖を考えなければなりません。
なぜ、これほど執拗なのか
ここまで読んできた方なら、Fire Antという脅威アクターの性格が少しずつ見えてきたのではないでしょうか。
彼らの活動には、一貫した特徴があります。
- 派手に壊さない
- すぐには姿を現さない
- 目立つマルウェアだけに頼らない
- ネットワークの奥へ入り込む
- 監視されにくい場所を選ぶ
- 認証情報を集める
- ログを抑える
- 管理者が見る情報に干渉する
- そして、さらに次の標的を探す
これは短時間で金銭を奪って逃げるタイプの犯罪とは、かなり異なる動きです。
攻撃者にとって重要なのは、「長く、深く、見つからずに存在すること」だと考えると、一連の行動がつながって見えてきます。
2025年にFire Antが狙っていたVMware ESXiやvCenterなどの仮想化基盤。
そして2026年に確認されたCisco IOS XRルーター、TACACS+認証基盤。
一見すると別々の製品です。
しかし共通点があります。
どれも、企業や組織のIT環境を“管理する側”に存在するシステムなのです。
だからこそFire Antの活動は、一台のルーターへの侵入という視点だけでは理解できません。
そして「管理するコンピューター」へ
ここまでで…
通信する場所――Cisco IOS XR
信用を確認する場所――TACACS+
…が侵害されていました。
では、そのネットワーク機器を実際に管理するために利用されているコンピューターはどうだったのでしょうか。
Sygniaの調査では、そこにもFire Antの痕跡がありました。
Linux（リナックス）管理ホストです。
ここで再び攻撃の構造が広がります。
- ルーター
- 認証基盤
- 管理ホスト
Fire Antは、一つの製品だけを狙っていたわけではありません。
ネットワークを構成する“「信用の連鎖」そのもの”をたどるように侵害範囲を広げていたのです。
そしてLinux管理ホストの調査から、Fire Antがどのようにアクセスを維持し、どのように別の環境へ到達しようとしていたのかが、さらに見えてきます。
ここから先は、いよいよ今回の調査報告の核心です。
攻撃者は何を盗んだのか――だけではありません。
攻撃者は、私たちが「信用できる」と思っていたインフラを、どこまで信用できないものへ変えてしまったのか。
その問題へ踏み込みます。
Linux管理ホスト――「管理する側」も安全ではなかった
Cisco IOS XRルーター。
TACACS+認証基盤。
Fire Antの侵害範囲を追ってきた私たちは、もう一つの重要な場所へたどり着きます。
Linux（リナックス）管理ホストです。
管理ホストとは、その名の通り、ネットワーク機器やサーバーなどを管理するために利用されるコンピューターです。
企業のネットワークでは、管理者が自分の普段使いのパソコンから、重要なルーターやサーバーへ直接アクセスするとは限りません。
管理専用のホストを経由させることで、重要なシステムへのアクセス経路を限定し、セキュリティを高める設計が行われることがあります。
このような役割を持つシステムには…
Jump Host（ジャンプ・ホスト）
Bastion Host（バスティオン・ホスト／踏み台となる管理用ホスト）
…などと呼ばれるものもあります。
本来なら、重要なネットワークへ到達するための「関所」です。
しかし、その関所そのものを攻撃者が突破していたらどうなるでしょうか。
Sygniaの調査では、Fire AntはLinux管理ホストにもアクセスし、そこからさらに活動を続けていました。
つまり、ルーターを管理するための場所まで、攻撃者の活動領域に含まれていたことになります。
SSH――正規の管理手段が攻撃者にも利用される
ここで重要になるのが、
SSH（エス・エス・エイチ／Secure Shell）
です。
SSHは、ネットワークを経由して別のコンピューターへ安全に接続し、遠隔操作するために広く利用されている仕組みです。
Linuxサーバーの管理では非常によく使われます。
SSHそのものは、もちろん攻撃技術ではありません。
むしろ暗号化された安全な遠隔管理を実現するための重要な技術です。
しかし、サイバー攻撃では、正規の管理ツールが、そのまま攻撃者の道具になることがあります。
もし攻撃者が正規の認証情報やSSH Key（エス・エス・エイチ・キー／SSH鍵）を取得すれば、新しいマルウェアを大量に持ち込まなくても、もともと存在する管理経路を利用して別のシステムへ接続できる可能性があります。
こうした考え方は、
Living off the Land（リビング・オフ・ザ・ランド）
と呼ばれる攻撃手法にも通じます。
これは、侵入先にもともと存在する正規の機能、コマンド、ツールなどを悪用して攻撃活動を進める考え方です。
攻撃者専用の道具を大量に持ち込めば、それだけ検知される材料も増えます。
しかし…
- 管理者もSSHを使う
- 攻撃者もSSHを使う
- 管理者も正規のコマンドを使う
- 攻撃者も正規のコマンドを使う
となれば、防御側は単純に、「このツールが使われたから攻撃だ」とは判断できません。
重要になるのは、誰が、いつ、どこから、何の目的で使ったのかという「行動」を見ることです。
攻撃者は「その先」を見ていた
そしてSygniaの調査で非常に重要なのが、Fire Antが侵害した環境だけを見ていたわけではないことです。
攻撃者は、そこから接続可能な別のネットワークや重要なシステムへの到達可能性を探っていました。
ここで、今回の報告を理解するための重要な言葉が登場します。
The Target Behind the Target（ザ・ターゲット・ビハインド・ザ・ターゲット）
直訳すれば、「標的の背後にある標的」です。
これはどういう意味でしょうか。
例えば、ある企業Aが侵害されたとします。
従来なら…
- 「企業Aのどのパソコンが侵害されたのか」
- 「どのデータが盗まれたのか」
- 「どうやって侵入されたのか」
…を調査します。
もちろん、それらは重要です。
しかし企業Aが、企業Bのネットワークへ管理アクセスできる立場だったらどうでしょう。
あるいは企業Aが、多数の顧客企業のネットワーク機器を管理していたら。
あるいは通信事業者、クラウド事業者、ITサービス事業者など、他組織のシステムへ正規の接続経路を持つ組織だったら。
攻撃者にとって、
企業Aそのものが最終目的とは限りません。
企業Aが持っている「信用」を利用して、
その先にいる企業Bへ進む。
さらに企業Bから企業Cへ進む。
こうした可能性を考える必要があります。
Fire Antが狙ってきたTrusted Infrastructure（トラステッド・インフラストラクチャ／信頼されたインフラ）が危険なのは、このためです。
攻撃者が奪おうとしているのは、一台の機械だけではありません。
その機械に与えられている…
- 「この機械から来た通信なら信用できる」
- 「この管理者なら信用できる」
- 「このサーバーなら接続を許可できる」
…という、ネットワークの中に構築された“Trust（トラスト／信頼）”そのものなのです。
ここで、すべてをつなげてみる
これまで確認してきたFire Antの活動を、もう一度並べてみましょう。
最初に見つかったのは、設定上は説明できないGREトンネル。
その後…
- Cisco IOS XR内部へ持ち込まれた不正なELFバイナリ。
- 正規プロセスに見せかけるMasquerading（マスカレーディング／偽装）。
- CLI出力への干渉。
- syslogの抑制。
- PCAPによるネットワークトラフィックの収集。
- 外部インフラへのデータ転送。
さらに…
- TACACS+認証基盤への侵害。
- TacTapによる認証情報の取得。
そして、
- Linux管理ホストへのアクセス。
- 正規の管理経路を利用した活動。
- 接続された別のネットワークへの到達可能性の探索。
一つ一つを別々に見ると…
- 「マルウェア」
- 「認証情報窃取」
- 「パケットキャプチャ」
- 「ログ改ざん」
…といった個別の攻撃手法に見えます。
しかし、すべてを一枚の図として眺めると、別の姿が見えてきます。
Fire Antは、企業のネットワークを構成する「信用の仕組み」を一つずつ利用しながら、その内部へ入り込んでいるのです。
「見えているから安全」という前提が崩れる
ここで、サイバーセキュリティにおける非常に重要な考え方へ進みます。
Observability（オブザーバビリティ／可観測性）です。
可観測性とは簡単にいえば、システム内部で何が起きているのかを、外部から得られる情報によって把握できる状態を意味します。
- ログ
- ネットワークテレメトリ
- プロセス情報
- 認証記録
- 設定情報
- コマンドの実行結果
こうした情報を組み合わせることで、防御側は、「このシステムでは何が起きているのか」を判断します。
ここで、Telemetry（テレメトリ）という言葉も押さえておきましょう。
テレメトリとは、システムや機器の状態・動作などを継続的に収集し、監視や分析に利用するデータです。
現代のサイバー防御では非常に重要です。
- EDR
- SIEM
- NDR
- ログ監視
- ネットワーク監視
これらは形こそ違いますが、「システムから得られる情報を観測し、異常を発見する」という考え方の上に成り立っています。
しかしFire Antの活動は、その前提に疑問を突きつけます。
- ログが抑制されていたら。
- CLIの表示が操作されていたら。
- 設定情報と実際の動作状態が一致していなかったら。
- 監視対象となる機器そのものが侵害されていたら。
その機器から送られてくるテレメトリを、どこまで信用できるのでしょうか。
ここで問題になるのは、「攻撃を見つけられなかった」というだけではありません。
もっと根本的な問題です。
「見つけるために使っていた情報そのものが、正しいとは限らない」のです。
Making the Infrastructure Lie――インフラそのものに「嘘」をつかせる
Sygniaは今回のFire Antの活動を説明する中で、非常に印象的な表現を使っています。
Making the Infrastructure Lie（メイキング・ジ・インフラストラクチャー・ライ）
直訳すれば、「インフラに嘘をつかせる」です。
もちろん、コンピューターが意思を持って嘘をつくわけではありません。
意味しているのは…
管理者がシステムへ問いかけたとき、システムから返ってくる情報が、実際の状態を正しく反映しなくなる
…ということです。
- 管理者が、「このトンネルは存在するか」と確認する。
→設定上は見つからない。 - 「怪しいプロセスは動いているか」と確認する。
→表示から隠される。 - 「異常な操作は記録されているか」とログを見る。
→必要な記録が抑制されている。
すると管理者には、「問題は見当たらない」ように見えます。
→しかし実際には、攻撃者が存在している。
これは、防御側にとって極めて厄介です。
なぜなら、「監視できている」という認識そのものが誤っている可能性を考えなければならないからです。
だから、一つの情報源だけを信用してはいけない
ここから防御側への重要な教訓が見えてきます。
- ルーター自身が出すログだけを見る。
- ルーター自身が表示する設定だけを見る。
- 管理サーバー自身が残す記録だけを見る。
- それでは、侵害された機器が「自分自身について語っている情報」だけを信用することになります。
そこで重要になるのが、複数の独立した観測点から状態を確認することです。
例えば…
- 機器自身のログ。
- 外部のログサーバー。
- ネットワーク上の通信記録。
- 認証サーバー側の記録。
- 別セグメントから取得したテレメトリ。
- 構成管理システムに保存された過去の設定。
…これらを突き合わせる。
すると、「ルーターは正常だと言っている。
→しかし外部から見ると説明できない通信がある」という矛盾を発見できる可能性があります。
サイバーセキュリティでは…
Single Source of Truth（シングル・ソース・オブ・トゥルース／唯一の信頼できる情報源）という考え方が使われることがあります。
しかし、侵害調査では少し違った視点も必要になります。
その“Truth”を語っているシステム自体が侵害されていないか。
Fire Antは、その問いを防御側へ突きつけています。
「EDRを入れているから大丈夫」ではない
そして、もう一つ重要な教訓があります。
EDR（イー・ディー・アール／Endpoint Detection and Response）は、現代のサイバー防御において非常に重要な技術です。
パソコンやサーバー上で発生するプロセス実行、ファイル操作、通信などを監視し、不審な挙動を検知します。
しかしFire Antが狙ってきた場所を思い出してください。
- VMware ESXi。
- vCenter。
- Cisco IOS XRルーター。
- TACACS+認証基盤。
- Linux管理ホスト。
こうした場所すべてを、一般的なエンドポイント向けEDRだけで同じように監視できるわけではありません。
つまり、「社員のパソコンは監視している」だけでは足りないのです。
攻撃者は、防御側がよく見ている場所を避け、見えにくい場所へ移動することができます。
Fire Antの活動は、その現実を非常に分かりやすく示しています。
本当に守らなければならないものは「信用の連鎖」
ここまで来ると、今回の事件を単なるCisco IOS XRへの侵害として扱うべきではない理由が見えてきます。
問題なのは、Ciscoのルーターが一台侵害されたことだけではありません。
- そのルーターが何を信用していたのか。
- 誰がそのルーターを管理していたのか。
- どの認証基盤につながっていたのか。
- その管理ホストから、さらにどこへ接続できたのか。
そして、その組織を信用していた別の組織は存在しないのか。
そこまで見なければなりません。
これこそ、The Target Behind the Target――標的の背後にある、本当の標的という考え方です。
Fire Antが示したのは、一つの非常に厄介な現実です。
現代のネットワークは、「信用」の積み重ねによって動いています。
だからこそ攻撃者にとって、その信用そのものが攻撃対象になるのです。
そして一度、その信用を奪われれば、攻撃者は「侵入者」としてではなく、正規のネットワーク、正規の管理経路、正規の認証情報を利用する存在として、さらに奥へ進んでいく可能性があります。
Fire Antが狙っているのは、単なる一台のコンピューターではありません。
私たちが安全だと信じて構築してきた、ネットワークの“信頼構造”そのものなのです。
おわりに――「信用している場所」こそ疑う必要がある
ここまでFire Antの活動を追ってきました。
- Cisco IOS XRルーター。
- TACACS+認証基盤。
- Linux管理ホスト。
- 通信の収集。
- 認証情報の取得。
- ログの抑制。
そして、管理者が確認する情報への干渉。
一つひとつを見ると異なる攻撃手法ですが、全体を通して見るとFire Antの狙いが見えてきます。
彼らが狙っているのは、単なる一台のコンピューターではありません。
企業や組織が「ここは信用できる」と考えている場所です。
だからこそ、今回の事案を「Ciscoのルーターがハッキングされた」という一言だけで理解するべきではありません。
Ciscoという企業そのものが侵害された事案でもなければ、現時点でFire Antの初期侵入経路がCisco製品の脆弱性だったと確認されているわけでもありません。
重要なのは、その先です。
通信を支える機器が侵害される。
認証を支えるシステムが侵害される。
管理するためのコンピューターが侵害される。
そして、その機器自身が出すログや表示まで信用できなくなる。
ここまで来ると、防御側が考えなければならないのは、
「侵入されたかどうか」だけではありません。
「自分たちが安全を確認するために見ている情報を、本当に信用してよいのか」
という問いです。
Fire Antの活動から得られる教訓は、意外に単純なのかもしれません。
一つの機器だけを信用しない。
一つのログだけを信用しない。
一つの認証だけを信用しない。
そして異常が疑われたときには、機器自身が語る情報だけではなく、別の場所から得られるログや通信記録、設定履歴などと照合する。
「見えているから安全」ではなく、「別の場所から見ても同じ状態なのか」を確認する。
これが重要になります。
Fire Antという名前を覚える必要はないかもしれません。
GREやTACACS+、PCAPといった技術用語を、一度読んだだけですべて理解する必要もありません。
しかし、一つだけ覚えておいてほしいことがあります。
私たちが便利で安全なネットワークを作るために積み重ねてきた“「信用」そのものが、攻撃者にとって価値のある標的になっています。”
だからこそ、Sygniaが示した言葉が重く響きます。
The Target Behind the Target（ザ・ターゲット・ビハインド・ザ・ターゲット）――「標的の背後にある、本当の標的」。
侵害された一台だけを見るのではなく、
その一台を誰が信用しているのか。
その一台から、さらにどこへ行けるのか。
そこまで見る必要があります。
Fire Antが私たちに突きつけた問題は、まさにそこにあるのだと思います。
では、私たちはどう守ればよいのか
ここまで読んで、
「こんなところまで侵入されたら、もう防ぎようがないのではないか」
と思われた方もいるかもしれません。
しかし、対策がないわけではありません。
Fire Antの攻撃から見えてくる重要なポイントは、一つの防御システムを信用しすぎないことです。
① ネットワーク機器そのものを監視対象にする
パソコンやサーバーだけではなく、ルーター、スイッチ、ハイパーバイザー、認証基盤、管理ホストも重要な監視対象です。
設定変更、管理者ログイン、異常な通信、通常存在しないトンネルやプロセスなどを継続的に確認する必要があります。
Fire Antが狙ったのは、まさにこうした“「重要なのに監視が薄くなりやすい場所」”でした。
② ログを機器の外へ保存する
侵害された機器の内部にログだけを保存していると、攻撃者に消去・抑制・改変される可能性があります。
そこで重要なのが、「その機器自身だけに記録を任せない」ことです。
ログを外部のsyslogサーバーやSIEMなどへ転送しておけば、機器内部の記録と外部に残された記録を比較できます。
ルーターが「異常なし」と言っている。
しかし外部の監視システムでは異常な通信が確認されている。
この食い違いそのものが重要な侵害の兆候になります。
③ 「設定」と「実際の動作」を照合する
今回、非常に象徴的だったのがGREトンネルです。
設定上は説明できない。
しかし実際には動いている。
だからこそ、
Configuration（コンフィギュレーション／設定状態）
だけではなく、
Operational State（オペレーショナル・ステート／実際の動作状態）
を確認する必要があります。
「どう設定されているか」と「実際に何が動いているか」。
この二つが一致しているかを、別々の観点から確認することが重要です。
④ 認証基盤を「最重要資産」として守る
TACACS+の侵害が示したように、認証基盤を奪われると攻撃者が正規利用者になりすます可能性が生まれます。
そのため…
- 管理者権限を必要最小限にする。
- 管理ネットワークへの接続経路を限定する。
- 不要なアカウントを残さない。
- 認証サーバーへのアクセスそのものを監視する。
- 一つの認証情報を奪われただけで広範囲へ移動できない構造にする。
…これは非常に重要です。
⑤ 「信用する。しかし確認する」から、さらに一歩進む
Fire Antの攻撃は、現代のネットワーク防御に根本的な問いを投げかけています。
信用している機器が侵害されていたらどうするのか。
信用している認証基盤が侵害されていたらどうするのか。
信用しているログが正しくなかったらどうするのか。
だからこそ重要なのは、「一つの情報だけで安全だと判断しない」ことです。
- 機器自身の情報。
- 外部ログ。
- ネットワーク通信。
- 認証記録。
- 設定履歴。
複数の独立した情報を突き合わせることで、一つの監視点が攻撃者に欺かれていても、別の場所から異常を発見できる可能性が高まります。
高度な攻撃者との戦いでは、「絶対に侵入させない」だけを目標にすることには限界があります。
侵入される可能性も考え…
- 侵入されても横展開させない。
- 信用を連鎖させない。
- 異常を別の観測点から発見する。
- そして、できるだけ早く封じ込める。
…こうした多層的な防御が必要になります。
Fire Antが徹底的に「信用」を利用してくるのであれば、防御側もまた、その信用が本当に正しいのかを、継続的に検証する仕組みを持たなければならないのです。
コメント