MFA(多要素認証)を導入してもVPNから侵入される理由―Akiraのサイバー攻撃で露呈した「認証の死角」、RDP・Windowsログオンも確認を|セキュリティ対策Lab

投稿日時: 2026年10月15日更新日時: 2026年10月15日

企業のMicrosoft 365やSaaSで多要素認証（MFA）を導入していても、VPNや社内Windows環境まで同じ認証ポリシーで保護されているとは限りません。2026年8月、ランサムウェア「Akira」の関係者がMFA未設定のSonicWall SSL VPNへログインし、社内のActive Directoryを探索した事例が報告されています。

認証基盤の課題は「MFAを導入したか」だけでは把握できません。クラウド、VPN、RDP、Windowsログオン、管理者アカウントなど、パスワードだけで利用できる経路が残っていないかを調べる必要があります。HuntressとGoogle傘下Mandiantの調査、Microsoftおよび米国NISTの公式資料から、攻撃の実態と確認すべき項目を整理します。

MFAの設定漏れが招くリスクのサマリー

Microsoft 365などのクラウドサービスでMFAを有効化しても、独立した認証設定を持つVPN・社内システムに自動適用されるとは限りません。
2026年8月4日、Akiraランサムウェアの関係者はMFAのないSonicWall SSL VPNへのパスワードスプレーを行い、約7分後にログインに成功しました。
攻撃者は約2時間後、RDPでドメインコントローラーへ接続し、Active Directoryのユーザー・端末情報を収集しました。
この事例では暗号化は失敗しましたが、認証情報やファイル共有データの窃取が確認されています。
Mandiantの2025年のランサムウェア関連侵害調査では、初期侵入経路を特定できた事案の21%で侵害された正規認証情報が使われていました。
同調査では、約85%の侵害でRDPが横展開に使われています。両数値はMandiantの調査対象に関するもので、全企業の被害率ではありません。
対応の起点は、利用者ごとのMFA登録率ではなく「パスワードだけで入れる認証経路」と「MFA例外アカウント」の棚卸しです。

Akiraの攻撃はMFA未設定のSonicWall SSL VPNから始まった

セキュリティ企業Huntressが2026年8月12日に公表した調査によると、攻撃は8月4日3時45分ごろ（UTC）、SonicWall SSL VPNに対する複数ユーザー名へのログイン試行から始まりました。約7分後、正しい認証情報によるログインが成功しました。対象VPNアカウントにはMFAが設定されていませんでした。

攻撃者は約2時間後にRDP（リモートデスクトップ）でドメインコントローラーへ接続し、Active Directoryのアカウント情報や端末情報を収集しました。その後、ファイル共有データを圧縮して外部のクラウドストレージへ転送しています。

攻撃者はWindowsをネットワーク対応のセーフモードで起動し、EDRとMicrosoft Defenderのリアルタイム保護を停止させました。最終的にAkiraの暗号化処理はメモリ不足で失敗しましたが、データの窃取はすでに行われていました。

この事例で確認された侵入経路は、MFAが設定されていないVPNへの正規認証情報を使ったログインです。特定のSonicWall脆弱性による認証回避が侵入原因だったと確認された事例ではありません。また、VPN侵入後のRDP接続について、RDP側にもMFAが存在しなかったと断定できる情報はありません。

攻撃の技術的な経緯とセーフモードを悪用したEDR停止については、セキュリティ対策Labの既報「Akiraランサムウェア、WindowsのセーフモードでEDRを停止」で紹介しています。

Mandiant調査では認証情報の悪用が初期侵入の21%、RDPによる横展開が約85%

Google Threat Intelligence Groupが2026年3月16日に発表したランサムウェアの調査報告では、2025年に観測した侵害のうち、初期侵入経路を特定できた事案の21%で、攻撃者が侵害された正規の認証情報を利用していました。利用先は主にVPNやRDPです。

認証情報の入手経路としては、情報窃取型マルウェアのログやアンダーグラウンド市場などが挙げられています。正しいパスワードでログインが成立すると、ネットワーク機器は通常の利用者の操作として扱うため、侵入の判別にはログイン元や時間帯、直前の失敗履歴などの確認が必要になります。

また、同調査では約85%の侵害で、窃取したアカウントまたは攻撃者が作成したアカウントを使うRDP接続が横展開に利用されました。これは「85%の企業でRDPのMFAが無効だった」という意味ではなく、侵害後のネットワーク移動にRDPが頻繁に使われていたという調査結果です。

Microsoft 365のMFAが社内の認証経路に自動適用されるわけではない

Microsoft Entra Conditional Accessは、ユーザー、アプリケーション、端末、リスクなどの条件に基づいてアクセスを制御する機能です。Microsoftの公式文書には、Microsoft 365へのサインイン時にMFAを要求する設定例が示されています。

ただし、その設定が保護するのはポリシーの適用対象となる認証フローです。VPNが別の認証基盤を使っていたり、社内WindowsサーバーへのRDP接続が別経路で許可されていたりすれば、Microsoft 365に設定したMFAだけで一律に保護されるものではありません。構成によってはVPNやオンプレミスアプリケーションもIdPと連携できますが、連携の有無と適用結果を個別に確認する必要があります。

確認する認証経路	よくある見落とし	確認事項
Microsoft 365・SaaS	一部アプリ・利用者グループが条件付きアクセスポリシーの対象外	対象アプリ、例外ユーザー、認証方式、サインインログ
SSL VPN・リモートアクセス	クラウドのMFA導入とVPN側のMFA設定が別管理	VPNの全利用者・ローカルアカウント・委託先のMFA設定
RDP・RD Gateway	VPN接続後の管理用RDPに追加の制御がなく、接続可能範囲が広い	経由ゲートウェイ、接続元制限、特権アクセス、ログ
Windowsログオン・管理端末	特権端末、共有端末などでパスワード認証が残存	認証方式、端末保護、物理アクセス、管理者権限
旧システム・Active Directory連携サービス	古い認証方式や別IdPによるログインが残存	認証プロトコル、MFA連携可否、代替制御
緊急用・サービスアカウント	例外設定が長期間放置される	使用目的、権限、利用記録、厳重な保管・監視

ここではWindowsログオンやRDPへのMFA追加をすべての環境で一律に実装すべきとするのではなく、インターネットからの到達性、認証方式、特権の範囲、端末の管理状態を踏まえて認証経路ごとの対策を決めます。管理専用端末、接続元制限、踏み台・ゲートウェイ、ネットワーク分離なども組み合わせる対象です。

MFA未導入と「MFAが突破される攻撃」は別の問題

今回のAkira事例は、MFAを設定していないVPNアカウントが悪用された事案です。一方、MFAが設定されているアカウントでも、SMSや認証アプリのワンタイムコードを偽のログイン画面へ入力させる中間者型フィッシング（AiTM）などの攻撃があります。

米国NISTのSP 800-63Bは、ワンタイムコードの手入力方式について、入力先の正規性と認証情報が暗号学的に結び付いていないため、フィッシング耐性のある認証方式とは扱っていません。これに対し、FIDO2/WebAuthnは認証先ドメインに結び付く仕組みを備えています。

最初の優先課題はパスワードだけでアクセスできる経路を減らすことです。そのうえで、高リスクの管理者アカウントや重要業務アプリケーションでは、パスキーやFIDO2セキュリティキーなどのフィッシング耐性を備えた方式を検討します。

認証方式ごとの違いは「多要素認証（MFA）とは」、認証済みセッションの悪用は「AiTM攻撃とは」、FIDO2の仕組みは「パスキーとは」で整理しています。

情報システム部門が優先して確認したい5項目

外部アクセスの全経路を洗い出す。 VPN、VDI、RD Gateway、リモート管理ツール、SaaS、委託先接続を列挙し、利用アカウントと適用認証方式を対応付けます。SaaS上のMFA有効率だけを完了条件にしません。
MFAの例外とバイパス経路を把握する。 ローカル認証、旧プロトコル、サービスアカウント、緊急用アカウント、条件付きアクセスの除外設定について、現在も利用が必要か確認します。
VPNの失敗・成功ログを関連付けて調べる。 複数アカウントへの短時間の失敗後、同一送信元や関連するIP帯から成功ログインがないかを監視します。管理者以外のVPNアカウントも対象です。
VPNからRDPへの到達範囲を絞る。 VPNへ接続できるだけでドメインコントローラーや重要サーバーへRDPできないよう、接続元、管理端末、ゲートウェイ、権限を見直します。
クラウドとオンプレの監視情報を突き合わせる。 IdP、VPN、Windowsイベントログを時刻・アカウント・接続元で追跡できるようにし、不審ログイン後のRDP接続や権限変更を調査可能にします。

2026年6月には、HuntressがMicrosoft 365への8,100万回超のログイン試行を確認し、条件付きアクセスポリシーの対象外となっていた認証フローからアカウント侵害が発生したと報告しています。今回のVPN事案とは別の攻撃ですが、認証ポリシーの適用範囲を確かめる必要性という点では共通しています。詳しくは「Microsoft 365環境へ8,100万回超のログイン試行」で紹介しています。