Microsoft Edgeに関する情報として確認している場合、まず注意したいのは、今回の「From edge appliance to enterprise compromise: Multi-stage Linux intrusion via F5 and Confluence」はMicrosoft Edgeブラウザーの機能変更や設定変更を案内する記事ではないという点です。ここでの「edge」は、企業ネットワークの境界に置かれるF5 BIG-IPなどのエッジアプライアンスを指します。
2026年5月23日前後に確認されたMicrosoft Security Blogの公式情報では、外部公開されたF5 BIG-IPから侵入し、内部のConfluenceサーバーへ横展開、さらに認証情報の窃取やKerberosリレーを試みたLinux環境を含む多段階攻撃が解説されています。管理者が見るべきポイントは、Microsoft Edgeのポリシー変更ではなく、境界機器、Linuxサーバー、Confluence、Active Directory、Microsoft Defenderの監視・防御設定です。Microsoft公式記事上では、記事日付はMay 22、Microsoft Defender Security Research TeamによるResearch記事として掲載されています。(Microsoft)
Microsoft Edgeの情報として見る前に確認すべき「edge」の意味
今回のテーマ名には「edge appliance」という表現が含まれています。日本語で「Edge」と聞くとMicrosoft Edgeブラウザーを連想しがちですが、この記事で扱われているのはブラウザーではありません。
Microsoft公式情報で説明されているのは、インターネットに公開されたF5 BIG-IPのようなエッジアプライアンスが侵害され、そこから内部ネットワークへ侵入が広がった事例です。記事では、ファイアウォールやVPNゲートウェイなどの境界機器が、外部公開され、監視が薄く、社内からは信頼されやすいことから、攻撃者の初期侵入点になりやすいと説明されています。(Microsoft)
そのため、Microsoft Edgeを管理しているIT担当者も、この記事を「ブラウザーの更新情報」として処理するのではなく、次のように読み替える必要があります。
| 誤解しやすい見方 | 正しい見方 |
|---|---|
| Microsoft Edgeブラウザーに新機能や脆弱性対応が入った | ブラウザーではなく、ネットワーク境界のエッジ機器が攻撃起点になった事例 |
| Edgeのポリシーや拡張機能設定を見ればよい | F5、Linux、Confluence、AD、Defenderの検知設定を確認する |
| Windows端末だけを見ればよい | Linuxサーバー、SaaS連携、内部Webアプリ、認証基盤まで確認する |
| 外部公開サーバーだけが危険 | 内部限定のConfluenceも、侵入後の横展開先になる |
公式情報で示された攻撃の流れ
Microsoftの説明では、攻撃は単発のマルウェア感染ではなく、複数のシステムをまたいで段階的に進んでいます。要点を整理すると、次の流れです。
| 段階 | 攻撃者の動き | 管理者が見るべきポイント |
|---|---|---|
| 初期侵入 | F5 BIG-IPとみられるエッジアプライアンスからLinuxホストへSSH接続 | 外部公開機器のバージョン、EOL、管理ポート公開範囲 |
| 偵察 | Nmap、gowitness、各種SMB/LDAP系ツールで内部ネットワークを調査 | Linux上のスキャン挙動、未知ツールの実行、横方向の通信 |
| 内部アプリ侵害 | 脆弱なConfluenceサーバーを見つけ、リモートコード実行を試行 | 内部Webアプリのパッチ状況、Javaプロセスからの不審コマンド |
| 認証情報窃取 | Confluenceの設定ファイルから認証情報を取得 | server.xml、confluence.cfg.xmlなどのアクセス監視 |
| 認証悪用 | KerberosリレーやWindows認証基盤への攻撃を試行 | SMB署名、LDAP署名、EPA、NTLM制限、AD監視 |
| 検知・防御 | Microsoft Defenderが一部のペイロード実行をブロック | LinuxサーバーへのDefender展開範囲、リアルタイム保護、XDR連携 |
特に重要なのは、攻撃者が最初からドメインコントローラーに直接到達したわけではない点です。境界機器を足場にし、Linuxホストを使い、内部のConfluenceを侵害し、そこから認証情報を得て、Active Directory側へ攻撃を広げようとしています。
これは、従来の「外部公開サーバーだけ守ればよい」「Windows端末だけEDRを入れればよい」という考え方では対応しきれない攻撃です。
何が変わるのか：管理の重点がブラウザーから境界・ID・Linuxへ広がる
今回の公式情報から読み取るべき変更点は、製品アップデートのような「ボタンの位置が変わる」「設定項目が増える」といった話ではありません。変わるのは、企業のセキュリティ管理で優先すべき視点です。
エッジアプライアンスをTier-0相当として扱う必要がある
Microsoftは、インターネットに面したエッジアプライアンスをTier-0資産として扱い、ライフサイクル管理とパッチ管理を徹底するよう促しています。公式記事では、初期の足場になったF5 BIG-IPが15.1.201000であり、このバージョンが2024年12月31日にEOLを迎えていたことも示されています。(Microsoft)
Tier-0とは、侵害されると組織全体の認証基盤や重要システムに影響し得る最重要資産を指す考え方です。ドメインコントローラーだけでなく、VPN、ロードバランサー、ファイアウォール、ID連携機器もこのレベルで管理する必要があります。
実務では、次のような確認が必要です。
| 確認項目 | 判断基準 |
|---|---|
| F5 BIG-IPなどの境界機器のバージョン | サポート終了済み、既知悪用脆弱性あり、長期未更新なら優先対応 |
| 管理画面の公開範囲 | インターネット全体から到達可能なら危険度が高い |
| SSHや管理ポートの接続元 | 特定IP、踏み台、VPN経由に限定されているか |
| 証明書・認証情報の保持状況 | 機器内にサービスアカウントや秘密鍵が残っていないか |
| ログ取得 | 管理ログ、認証ログ、通信ログがSIEMやXDRに連携されているか |
「境界機器はネットワークチームの管理」「EDRは端末チームの管理」と分断されている組織では、この種の攻撃を見逃しやすくなります。
内部限定のConfluenceも重要な攻撃面になる
公式情報では、攻撃者が内部ネットワーク内のAtlassian Confluenceサーバーを発見し、未修正の脆弱性を悪用してリモートコード実行を試みたと説明されています。Confluenceは外部公開されていなくても、攻撃者が一度内部に入れば到達可能な攻撃対象になります。(Microsoft)
これは多くの企業で見落とされがちなポイントです。
「社内からしか見えないから急いでパッチを当てなくてよい」
「開発部門だけが使うWikiなので優先度は低い」
「古いプラグインがあるが、外部公開していないので大丈夫」
こうした判断は、侵入後の横展開を前提にすると危険です。ConfluenceやJira、GitLab、Redmine、社内ポータル、CI/CDツールは、認証情報、APIトークン、接続先情報、構成メモが集まりやすい場所です。外部公開の有無だけで優先度を決めるのではなく、保存されている情報の価値と他システムへの接続権限でリスクを評価する必要があります。
LinuxサーバーもMicrosoft Defenderの監視対象にする必要がある
今回の攻撃では、Linuxホスト上でSSH接続、ファイル列挙、ネットワークスキャン、シェルスクリプト実行、ELFペイロードの配置などが行われています。Microsoft公式記事では、Microsoft Defender for EndpointがLinux上の不審なファイルやプロセス、Confluenceサーバーでのペイロード実行を検知・ブロックしたことが示されています。(Microsoft)
Windows端末だけにEDRを導入している環境では、攻撃者がLinuxを足場にした瞬間に可視性が落ちます。特に次のようなLinuxサーバーは優先的に監視対象へ入れるべきです。
- インターネットまたはDMZから到達できるサーバー
- Confluence、Jira、GitLab、Jenkinsなどを動かしているサーバー
- AD、LDAP、SAML、OIDCなどの認証連携を持つサーバー
- データベースやファイルサーバーへ接続できる中継サーバー
- sudo権限を持つ運用アカウントで管理されているサーバー
「Linuxは安定しているから後回し」ではなく、「Linuxは攻撃者にとって静かに動ける足場になりやすい」と捉えるべきです。
影響範囲：誰が確認すべきか
今回の情報は、Microsoft Edgeブラウザーだけを管理している担当者よりも、企業インフラ全体を管理する担当者に強く関係します。ただし、Microsoft 365やDefender、ID管理と連携している環境では、部門横断で確認が必要です。
| 対象者 | 確認すべきこと |
|---|---|
| 情報システム部門 | 外部公開機器、Linuxサーバー、Confluence、ADの棚卸し |
| セキュリティ運用担当 | Defender XDRの検知、アラート相関、Advanced Huntingクエリ |
| ネットワーク管理者 | F5 BIG-IP、VPN、ファイアウォールのEOL・脆弱性・管理ポート |
| サーバー管理者 | LinuxのEDR導入、SSHログ、sudo権限、不要ツールの有無 |
| 開発・DevOps担当 | Confluenceなど内部アプリのパッチ、設定ファイル内の秘密情報 |
| ID管理担当 | NTLM、Kerberos、LDAP、SMB署名、サービスアカウント運用 |
| Microsoft Edge管理者 | ブラウザー更新ではなく、用語の誤認を避けて関係チームへ共有 |
Microsoft Edgeの管理コンソールやブラウザーポリシーだけを確認して終わると、今回の公式情報の本質を取り逃がします。むしろ、Edgeという単語をきっかけに、境界防御とID防御の見直しへつなげることが重要です。
管理者がまず確認すべき設定と運用ポイント
ここからは、実際に管理者がどこから確認すべきかを整理します。すべてを一度に完璧に直すのは難しいため、攻撃経路に沿って優先順位を付けるのが現実的です。
外部公開されているF5 BIG-IPやVPN機器を棚卸しする
最初に行うべきは、外部から到達できる境界機器の棚卸しです。資産台帳上は存在していても、実際の公開状態、管理画面の到達性、稼働バージョンが一致していないことは珍しくありません。
確認すべき項目は次のとおりです。
| 項目 | 確認内容 | 優先度が高い状態 |
|---|---|---|
| 製品名・用途 | F5 BIG-IP、VPN、WAF、ロードバランサーなど | 誰が管理しているか不明 |
| バージョン | ベンダーサポート内か、EOLではないか | EOL、長期未更新、緊急修正未適用 |
| 管理画面 | インターネットから到達できるか | 全世界からHTTPS/SSHで到達可能 |
| 認証方式 | MFA、証明書、IP制限があるか | ID/パスワードのみ |
| ログ連携 | SIEM、Defender、Syslog等に送っているか | ローカル保存のみ、保存期間が短い |
| 接続先 | 内部Linux、AD、SaaS連携の有無 | 高権限アカウントを保持している |
特にEOLの機器は、脆弱性の修正が提供されない、または提供範囲が限定される可能性があります。すぐに更新できない場合でも、管理ポートの公開停止、接続元IP制限、監視強化、仮想パッチ、代替機への移行計画を同時に進めるべきです。
LinuxへのSSH接続とsudo権限を見直す
公式記事では、攻撃者がF5 BIG-IPとみられる機器からLinuxホストへSSH接続し、特権アカウントを使って活動したとされています。明示的な永続化をしなくても、既存の高権限アカウントがあれば攻撃を継続できる点が問題です。(Microsoft)
確認すべきポイントは明確です。
| 確認項目 | 見直しの方向性 |
|---|---|
| SSH接続元 | 境界機器、踏み台、管理端末以外からの接続を制限する |
| rootログイン | 原則無効化し、必要な場合も例外管理する |
| sudo権限 | 個人別アカウントに分離し、共有アカウントを減らす |
| 鍵管理 | 退職者・異動者・古いCI/CD鍵を削除する |
| ログ | sshd、auth.log、sudoログを集中管理する |
| アラート | 短時間の横断ログイン、深夜の初回接続、未知IPからの接続を検知する |
失敗しやすいのは、「パスワード認証を無効にしているから安全」と考えることです。秘密鍵が古い端末やCI環境に残っていれば、鍵認証でも侵害されます。鍵の棚卸し、接続元制限、権限分離をセットで行う必要があります。
Confluenceなど内部Webアプリのパッチ優先度を上げる
今回の事例では、内部にあるConfluenceが攻撃者に悪用されました。内部アプリは、外部公開システムよりもパッチ適用が後回しになりやすい一方で、認証情報や構成情報が集まりやすいという弱点があります。
管理者は、Confluenceについて次の点を確認してください。
| 確認項目 | 具体的な確認内容 |
|---|---|
| バージョン | Atlassianのサポート対象内か、既知脆弱性が未修正でないか |
| プラグイン | 不要プラグイン、更新停止プラグイン、権限過大なプラグインがないか |
| 設定ファイル | DBパスワード、サービスアカウント、APIキーが平文で残っていないか |
| 実行ユーザー | Confluenceプロセスが過剰なOS権限を持っていないか |
| ネットワーク | ConfluenceからAD、DB、ファイルサーバーへ広く到達できないか |
| ログ | Javaプロセスからのcurl、wget、chmod、base64、bash実行を検知できるか |
公式記事では、攻撃者がConfluence関連の設定ファイルから認証情報を取得しようとしたことが示されています。対象として挙げられているのは、/opt/atlassian/confluence/conf/server.xml や /var/atlassian/application-data/confluence/confluence.cfg.xml です。(Microsoft)
これらのファイルには、環境によってデータベース接続情報やサービス連携情報が含まれる場合があります。ファイルの権限、参照ログ、秘密情報の保管方法を見直すことが重要です。
NTLM、Kerberos、LDAP、SMBのリレー対策を確認する
攻撃者は、取得した認証情報を使ってWindows認証基盤に対するKerberosリレーや横展開を試みています。Microsoftは、NTLMを可能な範囲で最小化または無効化し、SMB署名、LDAP署名とチャネルバインディング、Extended Protection for Authenticationを適用することを防御策として挙げています。(Microsoft)
実務では、いきなりNTLMを全面無効化すると業務システムが停止する可能性があります。次の順序で進めると安全です。
| 手順 | 実施内容 | 注意点 |
|---|---|---|
| 現状把握 | NTLM利用状況、LDAP simple bind、SMB署名なし通信を洗い出す | まず監査モードで影響範囲を確認する |
| 優先順位付け | ドメインコントローラー、ファイルサーバー、重要アプリから対策 | 低影響なサーバーから試すと本番影響を抑えやすい |
| 署名・保護強化 | SMB署名、LDAP署名、LDAPチャネルバインディング、EPAを段階適用 | 古いOSや古いアプリの互換性を確認する |
| アカウント分離 | Confluenceなどアプリ用アカウントに不要な権限を持たせない | ドメイン管理者権限の使い回しは避ける |
| 継続監視 | 認証失敗、強制認証、異常なサービスチケット要求を監視 | XDRやSIEMで相関分析できる状態にする |
ポイントは、認証情報が漏れた場合でも、すぐにドメイン全体へ波及しない設計にすることです。サービスアカウントを「便利だから」と広い権限で使い回している環境ほど、被害範囲が大きくなります。
Microsoft Defenderで確認すべき検知・展開ポイント
今回の公式情報では、Microsoft Defender for EndpointやMicrosoft Defender XDRによる検知・防御が複数示されています。特に、Linux上でのHackTool検知、Confluenceサーバーでの不審なJavaプロセス、認証強制攻撃などが観測対象として挙げられています。(Microsoft)
Linuxサーバーでリアルタイム保護が有効か確認する
公式記事では、侵害が発生した環境においてリアルタイム保護が有効だったホストでは、ペイロード実行がブロックされたと説明されています。逆に言えば、LinuxサーバーへのDefender展開が一部にとどまっていると、攻撃経路の途中で可視性が途切れます。(Microsoft)
管理者は次の観点で確認するとよいでしょう。
| 確認項目 | 見るべき状態 |
|---|---|
| Defender for Endpointの導入範囲 | 重要Linuxサーバーがオンボード済み |
| リアルタイム保護 | 有効化され、除外設定が過剰でない |
| クラウド保護 | 組織ポリシーに沿って有効化されている |
| アラート転送 | Defender XDR、Sentinel、SOC運用に連携されている |
| 除外設定 | /tmp、/dev/shm、アプリディレクトリ全体を安易に除外していない |
| 対応手順 | 隔離、調査、認証情報ローテーションの手順が決まっている |
特に /tmp や /dev/shm は、攻撃者が一時的なペイロード配置に使うことがあります。業務アプリの都合で除外する場合でも、ディレクトリ全体ではなく、必要最小限に限定するべきです。
Advanced Huntingで攻撃の痕跡を探す
公式記事では、SSHログイン、Confluenceからの認証情報探索、ペイロード配送などを探すAdvanced Huntingの例が掲載されています。たとえば、F5デバイスからLinuxホストへのSSH成功ログオンや、ConfluenceのJavaプロセスが設定ファイルを参照する挙動を検出する考え方が示されています。(Microsoft)
自社環境で確認する場合、まずは次のような観点で検索条件を調整します。
| 探す痕跡 | 具体例 |
|---|---|
| 境界機器からのSSH | F5、VPN、ロードバランサーのIPからLinuxへのログイン成功 |
| 内部スキャン | Nmap、gowitness、enum4linux、smbclient、ldapsearchなどの実行 |
| 一時領域への配置 | /tmp、/dev/shm へのELF、スクリプト、base64デコード |
| Confluence経由のコマンド | Javaプロセスを親に持つcurl、wget、bash、chmod |
| 認証情報探索 | server.xml、confluence.cfg.xml、setenv.sh の参照 |
| 認証悪用 | Kerberos、NTLM、LDAP、SMB周辺の異常な認証試行 |
公式クエリをそのまま使うだけでなく、自社のホスト名、IP体系、Confluenceのインストールパス、F5のバージョン情報に合わせて条件を調整することが大切です。
開発者・DevOps担当が確認すべき移行・展開上の注意点
この事例は、インフラ管理者だけでなく、開発者やDevOps担当にも関係します。Confluence、CI/CD、社内API、サービスアカウントは、攻撃者にとって次の足場になりやすいからです。
設定ファイルに秘密情報を残さない
アプリケーションの設定ファイルにDBパスワードやAPIキーを置く設計は、運用上よくあります。しかし、攻撃者がアプリサーバーに到達した場合、そのファイルが認証情報の宝庫になります。
すぐに確認すべきファイルや場所は次のとおりです。
| 対象 | 確認内容 |
|---|---|
| Confluence設定ファイル | DB接続情報、サービスアカウント、平文パスワード |
.env ファイル | APIキー、クラウド資格情報、Webhookシークレット |
| CI/CD変数 | 本番DB、SaaS、クラウド管理権限が含まれていないか |
| バックアップファイル | 古い設定ファイルや圧縮ファイルに秘密情報が残っていないか |
| Wiki・手順書 | パスワード、初期認証情報、内部URLが記載されていないか |
理想は、秘密情報を専用のシークレット管理基盤に集約し、アプリケーションには必要な範囲だけを渡す構成です。すぐに移行できない場合でも、ファイル権限、参照ログ、ローテーション手順を整備するだけでリスクを下げられます。
サービスアカウントを最小権限にする
ConfluenceやJiraなどの内部アプリは、LDAP、AD、メール、データベース、ストレージと連携していることがあります。ここで使うサービスアカウントに広すぎる権限があると、1つのアプリ侵害が組織全体の侵害に近づきます。
見直しの基準はシンプルです。
| 見直し対象 | 避けるべき状態 | 改善例 |
|---|---|---|
| AD連携アカウント | ドメイン管理者や広範な読み書き権限 | 認証・検索に必要な最小権限 |
| DB接続アカウント | 複数DBに共通、DDL権限あり | アプリ専用、必要なテーブル権限のみ |
| APIキー | 退職者・旧環境・検証環境と共通 | 環境別に分離し、定期ローテーション |
| CI/CDトークン | 本番・検証・開発を横断可能 | 環境ごとに分離、短命トークンを活用 |
| Wiki内の共有ID | 複数人で使い回し | 個人アカウント、監査ログで追跡可能にする |
権限を削る作業は後回しにされがちですが、侵害時の被害範囲を決める重要な作業です。移行や展開のタイミングでまとめて見直すと、業務影響を抑えながら改善できます。
Microsoft Edge管理者が取るべき現実的な対応
今回の情報はMicrosoft Edgeブラウザーの直接的な変更ではありません。それでも、Microsoft Edgeを管理している担当者が何もしなくてよいわけではありません。企業内では、ブラウザー、ID、Defender、条件付きアクセス、プロキシ、SaaS利用がつながっているためです。
Microsoft Edge管理者は、次の対応を行うと実務上有効です。
| 対応 | 目的 |
|---|---|
| 関係チームへ情報共有 | 「Edgeブラウザーの更新」ではなく「エッジ機器侵害の事例」として正しく伝える |
| SaaSアクセス経路の確認 | Confluenceなど社内SaaS・Wikiへのアクセス制御を見直す |
| Microsoft 365/Entra ID担当と連携 | 条件付きアクセス、MFA、セッション制御、危険なサインイン検知を確認する |
| Defender担当と連携 | Linuxサーバーや内部Webアプリの監視対象漏れを確認する |
| ブラウザー側の基本対策確認 | 管理対象ブラウザーで危険サイト対策、拡張機能制御、プロファイル分離を維持する |
ここで大切なのは、Microsoft Edgeだけで完結しないことです。Microsoft Edgeの管理画面で設定を探し続けるよりも、F5、Confluence、Defender、Entra ID、ADを担当するチームに正しくエスカレーションする方が効果的です。
すぐに実施したい確認チェックリスト
最後に、管理者が今日から確認できる項目を優先度順に整理します。
| 優先度 | 確認項目 | 完了の目安 |
|---|---|---|
| 高 | 外部公開されているF5 BIG-IP、VPN、WAF、ロードバランサーを一覧化する | 製品、IP、バージョン、管理者、公開範囲が分かる |
| 高 | EOLまたは緊急脆弱性未対応の境界機器を特定する | 更新、移行、公開制限の計画がある |
| 高 | Linux重要サーバーにDefender for Endpointを展開し、リアルタイム保護を確認する | 主要LinuxがXDRに表示される |
| 高 | Confluenceなど内部Webアプリのバージョンと脆弱性対応状況を確認する | 未修正の重大脆弱性がない |
| 高 | Confluence設定ファイル内の認証情報と権限を見直す | 不要な高権限・平文秘密情報を削減できている |
| 中 | SSH接続元、sudo権限、共有アカウントを見直す | 管理経路と権限が説明できる |
| 中 | NTLM、SMB署名、LDAP署名、EPAの現状を確認する | 監査モードまたは段階適用の計画がある |
| 中 | Advanced HuntingでF5からのSSH、Java経由コマンド、内部スキャンを調査する | 過去ログに不審な痕跡がないか確認済み |
| 中 | サービスアカウントの権限と使い回しを調査する | アプリ単位・環境単位で分離されている |
| 低 | Microsoft Edge管理者向けに社内共有文を作成する | 誤解なく関係チームへ展開できる |
まとめ：Microsoft Edgeの更新情報ではなく、境界機器からID侵害へ広がる攻撃事例として対応する
「From edge appliance to enterprise compromise: Multi-stage Linux intrusion via F5 and Confluence」は、Microsoft Edgeブラウザーの新機能やポリシー変更を説明する情報ではありません。Microsoftが示したのは、外部公開されたF5 BIG-IPのようなエッジアプライアンスを起点に、Linuxホスト、内部Confluence、認証情報、Kerberosリレー、Active Directoryへ攻撃が広がる多段階侵害の実例です。
管理者が次に取るべき行動は、Microsoft Edgeの設定画面を探すことではなく、境界機器のEOL・脆弱性確認、LinuxサーバーへのDefender展開、Confluenceのパッチ適用、サービスアカウントの最小権限化、Windows認証基盤のリレー対策を進めることです。
特に、外部公開機器と内部アプリを別々に管理している組織では、攻撃者がその境界をまたいで動く前提でログと権限を見直す必要があります。まずは外部公開機器と重要Linuxサーバーの棚卸しから始め、見つかったEOL機器、未修正のConfluence、過剰権限のサービスアカウントを優先的に潰していきましょう。
コメント