F5 BIG-IP→Confluence→Active Directory多段侵入｜Microsoft公開の攻撃チェーンとEDR検知ポイント

2026年5月22日、Microsoft Threat Intelligenceが「エッジ機器から企業全体侵害へ：F5とConfluenceを介した多段Linux侵入」と題する詳細なインシデント分析を公開しました。
インターネットに公開されたF5 BIG-IPロードバランサ1台の侵害から、内部Confluenceサーバ、最終的にActive Directory（AD）ドメインコントローラまで攻撃が及んだ事例の全攻撃チェーンを、防御側目線で公開した内容です。

本記事では、Microsoftが公開した攻撃チェーンを段階ごとに分解し、SOC・EDR運用側で何を検知ポイントに置けば本件と同種の侵入を早期に止められたかを整理します。
F5機器・Atlassian Confluence・Windows AD のいずれかを運用している組織にとって、平時の防御設計を見直す格好の材料になる事案です。

事件のサマリー：エッジ機器1台が企業侵害の起点になる構造

Microsoftが公開した攻撃チェーンは、典型的な「エッジ→内部→アイデンティティ」の3段階で構成されています（出典: Microsoft Security Blog）。

・第1段（初期侵入）: Azure上に展開されていたF5 BIG-IP Virtual Edition（バージョン15.1.201000）にSSH経由で侵入
・第2段（横展開）: F5を踏み台に内部Linuxサーバへピボット
・第3段（クレデンシャル奪取）: 未パッチの内部Confluenceサーバを侵害、設定ファイルから認証情報を抽出
・第4段（AD侵害）: Kerberos relay攻撃とCVE-2025-33073悪用でドメインコントローラを攻略

各段階で攻撃者は異なるツール群を組み合わせており、シグネチャベース検知だけでは捉えきれない「ふるまい連鎖」が攻撃チェーンの本質です。

第1段：F5 BIG-IP のEOLバージョンが踏み台になった

侵入の起点となったF5 BIG-IP Virtual Edition 15.1.201000は、2024年12月31日でEnd-of-Life（EOL）を迎えたバージョンです（出典: Microsoft Security Blog）。
EOLバージョンは公式パッチが提供されない状態にあり、本件の侵入時点ではすでに5か月以上、サポート切れのまま運用されていたことになります。

このパターンが組織内に潜むメカニズムは典型的です。クラウド上にARMテンプレートやTerraformモジュールで自動展開したVEは、ライフサイクル管理が手動運用と分離されがちで、運用主体が曖昧なまま放置されることが多いのが実態です。
EOL機器の存在は「アセット管理台帳の鮮度」と「ライフサイクル管理プロセスの実効性」で防ぐべき領域であり、後追いの脆弱性スキャンでは間に合わないケースが本件のような結果につながります。

侵入後、攻撃者はF5から内部ネットワーク向けにSSHアクセスを試みました。BIG-IPはネットワーク機器でありながらLinuxシェル機能を持つため、いったん侵害されると単なる「ロードバランサ」ではなく「内部ネットワークに足を持つLinuxサーバ」として悪用されます。

第2段：内部偵察で使われたツール群

攻撃者はF5を踏み台に、以下のツール群で内部偵察を行いました（出典: Microsoft Security Blog）。

このツール構成は、ペネトレーションテスターやレッドチームが日常的に使うものと重複が大きい点が厄介です。「ツールが使われた」だけで悪性と断定できず、文脈（実行者・対象・時間帯・成功率）の組み合わせで判定する必要があります。
だからこそ、運用側にとってEDR/XDRが提供するふるまい検知と、SIEM上のクロス相関ルールの精度が問われます。

第3段：Confluence侵害とクレデンシャル設定ファイルの落とし穴

攻撃者は内部偵察の結果、未パッチのRCE脆弱性を持つ内部Confluenceサーバを発見しました。
このConfluenceはインターネットに直接公開されていないサーバでしたが、F5からピボットした攻撃者にとっては内部ネットワーク経由でアクセス可能な状態にありました（出典: Microsoft Security Blog）。

ここで重要なのは、「インターネット非公開だからパッチ運用は緩くてもよい」という発想が成立しなくなるという現実です。エッジ機器が侵害されれば内部ネットワーク全体が攻撃面になり、内部Webアプリの未パッチ状態は致命的になります。
Confluence侵害後、攻撃者は `server.xml` と `confluence.cfg.xml` の設定ファイルからクレデンシャルを抽出しました。これらの設定ファイルにはDB接続情報・サービスアカウント認証情報・連携用のAPIキー等が記載されていることが多く、攻撃者にとって「内部展開のためのゴールドマイン」です。

設定ファイル中のクレデンシャル管理は、本来Secret Manager（HashiCorp Vault、AWS Secrets Manager、Azure Key Vault等）に分離すべきものですが、多くの組織で設定ファイル直書きが運用上残ったまま放置されています。本件は、その慣習が「内部侵入後の急速な権限拡大」を許してしまう構造を改めて示しています。

第4段：Kerberos relayとCVE-2025-33073によるAD侵害

Confluenceから得たクレデンシャルを携えて、攻撃者はAD侵害の最終段階に進みました。
ここで使われた中核技術は「Kerberos relay攻撃」と「CVE-2025-33073」の組み合わせです（出典: Microsoft Security Blog）。

Kerberos relayは、ターゲットからの認証要求を攻撃者がプロキシ的に中継し、攻撃者側の意図する別ターゲットに対して認証を成立させる中間者攻撃の一種です。
本件では、netexecとPetitPotam coercionを組み合わせ、ターゲットコンピュータに対して「攻撃者の指定する宛先に認証してこい」という強制呼び出しを行い、その認証フローを別の特権サービスに対して中継しました。

CVE-2025-33073はKerberos認証の検証ロジック側の脆弱性で、本来防げるはずのrelay攻撃を成功させる引き金になりました。DNSマニピュレーションも組み合わせて、ドメインコントローラに対して特権コンテキストでのアクセスを成立させた、と公開資料からは読み取れます。
最終的に攻撃者はドメイン管理者相当の権限を獲得した可能性が指摘されており、AD侵害が確定した時点で「環境全体の再構築」を視野に入れざるを得ない深刻度に達しました。

EDRが防衛線を引いた一点：Confluenceホストでのリアルタイム保護

本事例で唯一の救いは、Microsoft Defender for EndpointのリアルタイムプロテクションがオンになっていたConfluenceホスト上で、ELFペイロードを実行段階でブロックできた点です（出典: Microsoft Security Blog）。
ハッシュ値 `4a927d031919fd6bd88d3c8a917214b54bca00f8` と `710a9d2653c8bd3689e451778dab9daec0de4c4c` を持つカスタムマルウェアが、自動でブロックされました。

逆に言えば、EDRが入っていなかったり、リアルタイム保護がオフになっていたりするLinuxサーバが社内に1台でもあれば、本件は完全成功していた可能性が高い構造です。
WindowsだけにEDRを入れている組織が多い現状で、本件はLinux EDR導入の重要性を改めて突きつけました。

SOC・EDR運用側がいま実装すべき検知ルール

1. エッジ機器のEOL監視と即時アラート

F5 BIG-IP、Fortinet、Citrix、PAN-OS等のエッジ機器はベンダーごとにEOLポリシーが異なり、社内のアセット管理台帳と照合した「EOL接近・到来アラート」を自動化しておくのが理想です。
クラウド上に展開した仮想アプライアンスは特に見落としやすく、IaC（Terraform/ARM/CloudFormation）の状態ファイルを定期スキャンしてバージョンと公式EOLリストを突き合わせる仕組みが効きます。

2. エッジ機器→内部SSHのふるまい検知

本来エッジ機器（ロードバランサ・WAF・VPNゲートウェイ）から内部へのSSHは、運用通信以外では発生しません。
これを検知ルールに落とすには、ネットワーク側のフローログ（NetFlow / VPC Flow Logs / Azure NSG Flow Logs）で「エッジセグメントから内部セグメントへの新規SSH接続」をアラート対象にします。

3. 内部ネットワークからの偵察ツール挙動の検知

Nmap、gowitness、enum4linux、netexec、smbclient といった偵察ツールの実行は、運用者の正常作業との切り分けが課題です。
EDR側で「短時間に多数IPに対する大量SYN」「大量のSMB nullセッション試行」「失敗認証のバースト」をふるまいルールとして組み込み、誰が・どのホストから・何分間で実施したかをセットで可視化するのが現実解です。

4. Linux EDR/XDRの全台導入とリアルタイム保護の確認

本件で示された通り、Linux側のEDR導入は「あればよい」ではなく「必須」のフェーズに入っています。
Microsoft Defender for Endpoint、CrowdStrike Falcon、SentinelOne、Wazuh（OSS）など複数選択肢があり、組織規模と予算に応じて選定可能です。導入後はリアルタイム保護機能のオン状態をコンプライアンスチェックで継続監視してください。

5. Kerberos relayとPetitPotam対策の徹底

Microsoftが推奨している以下の3点は、AD環境では即実施が望ましい対策です（出典: Microsoft Security Blog）。

・SMB署名の有効化: SMB Signing required を強制し、署名されていないSMB通信を拒否
・LDAP署名の有効化: LDAP Server Signing Requirements を Require signing に設定
・Extended Protection for Authentication（EPA）の有効化: HTTPS終端の認証に対するrelay耐性を強化
・NTLMの段階的廃止: Kerberos優先で運用、NTLMは監査ログを取りながら段階的に停止

これらは1日では完了しない長期施策ですが、AD侵害の構造的リスクを下げる本質的な対策です。中小企業であっても、まずは現状のSMB/LDAP署名要件を確認することから始められます。

クラウド／オンプレ混在環境特有の落とし穴

本件はAzure上のF5 VEから始まり、最終的にオンプレADまで到達した「クラウド・オンプレ混在環境」の典型事例です。
この種の環境では、エッジ機器・内部サーバ・AD のそれぞれを別チームが運用しているケースが多く、攻撃チェーン全体を俯瞰できる「責任者」が組織内に存在しないリスクがあります。

クラウド側のIAM・ネットワーク設計の基礎、特にAzure NSG・AWS Security Groupの運用は、エッジから内部への侵入を構造的に難しくする最初の砦になります。
クラウドセキュリティ設計の基本については、姉妹サイトCloudMaster.JPでも継続的に取り上げています。

Linux側の堅牢化（SELinux、ファイル所有権、SSH鍵管理、auditd）の積み上げが、F5やConfluenceのような「Linuxシェルを持つアプライアンス」侵害時の被害局所化に直結します。Linuxサーバ運用の基礎は姉妹サイトLinuxMaster.JPでも詳しく解説しています。

中小企業の情シスでも実行できる現実的な第一歩

「F5やConfluenceは大企業の話で、中小企業には関係ない」と思う方もいるかもしれません。しかし、本件の教訓は機器固有の話ではなく、「エッジ機器の運用怠惰→内部侵入→AD侵害」という共通構造にあります。
中小企業の情シスでも、以下の最初の3ステップから始められます。

・ステップ1： 自社の境界機器（VPN・WAF・ロードバランサ・ファイアウォール）の一覧化とファームウェアバージョン棚卸し
・ステップ2： 各機器のベンダー公式EOLスケジュールを確認し、6か月以内にEOLを迎える機器をリストアップ
・ステップ3： 内部Webアプリ（Confluence、JIRA、GitLab、Redmine等）の最新パッチ適用状況を確認し、未パッチを解消

このリストを作るだけで、本件のような攻撃チェーンに対する組織の防御力は一段階上がります。完璧を目指すのではなく、「自社にとっての最初の1台」を確認することから始めるのが現実解です。

よくある質問（FAQ）

Q1. F5 BIG-IPを使っていません。それでもこの記事の教訓は意味がありますか？
A. 意味があります。本件の本質は「インターネット境界機器のEOL管理」と「内部ネットワークへのピボット防止」であり、これはF5固有の話ではありません。VPN・WAF・LB・FWのどれであっても同じ構造が成り立ちます。

Q2. Confluenceを内部のみで運用しているので大丈夫ですよね？
A. インターネット非公開はリスク低減になりますが、本件のように内部ピボット後の侵入経路として狙われます。「外部から見えないからパッチを後回しにしてよい」という運用は本件以降は推奨できません。

Q3. Linux サーバには EDR を入れていません。すぐ入れるべきですか？
A. 入れるべきです。本件はMicrosoft Defender for Endpoint がELFペイロードを実行段階でブロックして攻撃連鎖を遮断しました。Linux EDR は「あれば嬉しい」から「必須」のフェーズに入っています。

Q4. SMB署名・LDAP署名を有効化すると業務影響がありますか？
A. 古いシステム・古いプリンタ・一部のNAS製品で互換性問題が出る可能性があります。検証環境で先行有効化し、業務影響を測定してから本番反映するのが安全です。

Q5. CVE-2025-33073の単独パッチで本件は防げますか？
A. CVE-2025-33073のパッチは重要ですが、それだけでは不十分です。本件はエッジ機器のEOL放置・内部Confluence未パッチ・LinuxサーバEDR未導入が複合した結果であり、多層の対策が必要です。

Q6. C2 IP（206.189.27[.]39）はファイアウォールでブロックすればよいですか？
A. 即時ブロックは有効ですが、攻撃者は別IPに移ることが容易なため、IP単発ブロックは応急処置です。並行してDNS監視・プロキシログ監視で類似挙動を検知する仕組みが必要です。

Q7. 自社のADが侵害されたかどうかを後追いで確認する方法はありますか？
A. ドメインコントローラのセキュリティイベントログ（4624、4768、4769、4776）の精査、新規追加ユーザ・グループメンバ変更の差分確認、不審なサービスアカウント作成の有無、特権アカウントの異常ログイン時刻、の4点を最低限見てください。専門の侵害調査（フォレンジック）を外注するのが望ましい場合もあります。

本記事のまとめ

F5 BIG-IPからConfluenceを経由してActive Directoryに至った本多段侵入事例は、現代の企業侵害がいかに「エッジ機器の運用怠惰」「内部Webアプリの未パッチ」「Linux EDR未導入」「AD認証設計の弱さ」の組み合わせで成立するかを克明に示しました。
個別の脆弱性パッチだけでなく、組織全体でTier-0資産の捉え直しが必要です。

SOC側はLinux EDR全台導入、エッジ機器EOL監視、Kerberos relay対策（SMB/LDAP署名・EPA・NTLM段階的廃止）の3本柱を優先順位高く進めるべきです。
運用側はクラウド上の仮想アプライアンスのライフサイクル管理を見直し、IaCで展開した機器こそ専任の運用主体を明確にしてください。

「自社にF5はない」「Confluenceは内部だから安全」と思った段階で、本件と同種の攻撃チェーンを許す土壌ができてしまいます。本件を「他人事」ではなく「自社の構造を点検する材料」として活用するのが、もっとも実利のある向き合い方です。