MFAとアカウントロックで防げること・防げないこと

SHORT ANSWER

結論

アカウントロックは、パスワードを繰り返し推測するログイン試行を抑えます。MFAは、パスワードを知られても追加の本人確認なしでログインされることを防ぎます。一方、偽サイトへの入力や端末からの盗難、認証済みセッションの悪用には、それぞれ別の対策も必要です。MFAを維持しながら、認証方式・適用範囲・端末保護を確認することを勧めます。

GSS事案から、認証の役割を考える

GSSの公表資料には、保守運用担当者のアカウントによるファイルアクセスが記載されています。ただし、パスワードが盗まれたのか、MFAを突破されたのかは、公表資料だけでは分かりません。この記事では今回の手口を推測せず、認証対策の一般的な役割を説明します。[1][2]

パスワードを知られることと、ログインされることは別

アカウントロックはログイン時のパスワード推測を抑え、MFAは追加で本人確認します。端末・セッションの保護は認証後の悪用にも備えます。MFAは有効ですが、偽サイトや端末からの盗難には別の対策も必要です。 — 一般的な対策の説明であり、GSS事案の認証情報の取得方法やMFAの利用状況を示すものではありません。

アカウントロックはログイン時の推測を抑え、MFAは追加の本人確認を行います。端末・セッションの保護は、本人確認を済ませた後の悪用への備えです。それぞれが守る場面を理解して組み合わせます。

アカウントロックは、認証先で発生する失敗などを基に働きます。Microsoft Entraのスマートロックアウトも、パスワード推測や大量試行への対策です。正しいパスワードそのものを別の場所から盗まれる経路を、ロック設定だけで塞ぐことはできません。[3]

何度もログインに失敗せず、パスワードを知られる経路

偽サイトで本人に入力させる

本物そっくりの画面へ誘導され、本人がパスワードを入力すると、その内容が攻撃者へ渡ることがあります。本人はいつものログイン操作のつもりなので、会社側に大量の失敗ログが出るとは限りません。

端末や保存情報から盗み取る

端末が侵害されると、入力内容や、保護が不十分な場所へ保存された認証情報を盗まれる可能性があります。WindowsのCredential Guardは認証情報の一部を保護しますが、キーロガーなど保護対象外の経路もあります。端末の更新・マルウェア対策・権限管理を併せて考えます。[7]

盗んだ照合用データを、自分のPCで調べる

サーバーからパスワードの照合用データ「ハッシュ」が盗まれた場合、攻撃者が自分の環境で候補を計算して照合することがあります。会社のログイン画面へ入力していないため、会社側のロックや試行回数制限が働きません。これをオフライン攻撃と呼びます。[4]

ただし、ハッシュから必ず元のパスワードが分かるわけではありません。パスワードの長さや予測しにくさ、保存時の処理によって難しさが変わります。複雑なパスワードでも、そのまま入力内容を盗まれる場合はあるため、推測と盗難の両方へ備えます。

MFAを済ませた後の情報が悪用される場合もある

MFAが適用される通常のログインでは、パスワードだけを知っていても追加の本人確認を通過できなければ利用できません。これは、パスワードが漏れた後の被害を抑える重要な役割です。

一方、攻撃者が偽サイトを通じて認証を中継し、本人にMFAも完了させて、認証済みの情報を取得する攻撃があります。Microsoftは、こうしたAiTMフィッシングでセッションCookieが盗まれ、その後のなりすましに使われた事例を報告しています。[5]

「ログイン済み」の入館証も守る

セッションCookieは、毎回ログインし直さなくてもサービスを使えるようにする情報の一つです。盗まれた情報が再利用できるかは、有効期限や端末との結び付きなどに左右されます。Cookieを盗めば常に全サービスへ入れる、という意味ではありません。

確認したいのは、MFAの方式・範囲・その後

設定済みから、実際に保護される状態へ
観点	確認する内容
方式	重要なアカウントでは、FIDO2セキュリティキーやWindows Hello for Businessなど、フィッシングに強い方式を利用できるか。
適用範囲	登録しただけでなく、対象のサービスでMFAが要求されるか。例外アカウントや別のログイン経路は把握されているか。
端末	会社が管理する端末を使い、更新と脅威対策が動いているか。不要な管理者権限を持たせていないか。
復旧	不正利用時にパスワードの変更、セッションの失効、不審な認証方法の削除を確認できる担当者がいるか。

Microsoft Entraでは、認証強度を使って、機密性の高いサービスにフィッシングに強い方式を要求できます。対応する方式やライセンスを確認したうえで、小さな対象から検証します。通常のプッシュ承認やSMSと、FIDO2等を同じ耐性として扱わないことがポイントです。[6]

例えば、管理者アカウントから強い認証へ移行する会社では、端末紛失時の本人確認と予備の認証手段も先に決めます。保守会社が接続する環境では、個人別アカウント、利用期限、接続対象を確認します。業務を止めない復旧手順とセットで進めます。

自社で確認する5つの質問

管理者・一般利用者・保守担当者ごとの認証方式を説明できますか。
MFAの対象外になっているアカウントやサービスを把握していますか。
端末の更新と脅威対策が、実際に動いていることを確認していますか。
本人確認なしで認証方法を再登録できるなど、復旧手順に抜け道はありませんか。
不正利用時に、既存のセッションや追加された認証方法も確認できますか。

AZWorkなら、登録状況と実際のログインを照合します

「全員がMFAを登録済み」という一覧に加え、どのサービスでどの認証方法が要求されているかを確認します。例外と復旧手順を整理し、強い認証・端末管理・通知を運用できる範囲から組み合わせる方針です。

よくある質問

MFAがあってもパスワードは盗まれますか。

偽サイトへの入力や端末の侵害などで盗まれる可能性があります。MFAは、そのパスワードだけでログインされることを防ぐためにも有効です。

パスワードを変更すれば不正利用は止まりますか。

変更に加え、サービスに応じて既存セッションの失効や不審な認証方法の削除、端末の調査も必要です。パスワード変更だけですべてのアクセスが直ちに止まるとは限りません。

フィッシングに強いMFAなら、端末対策は不要ですか。

端末対策も必要です。認証方式を強化しても、侵害された端末上の操作や、認証後の情報の悪用まで一律に防げるわけではありません。

一次情報・参考資料

確認日：2026年9月13日。事案の公表内容と一般的な技術解説・AZWorkの提案を区別しています。調査や製品仕様の更新により内容が変わる場合があります。