パスワードスプレー攻撃は、不正アクセスを狙う攻撃者が多くのユーザーアカウントに対して少数のパスワードを繰り返し試す手口としてよく知られています。Azure AD(現Microsoft Entra ID)で日々発生する認証ログを見ていると、パスワード誤りが続くケースに加え、特定のポリシーが原因でブロックされたような痕跡を確認することがあります。こうしたログイン失敗が何を意味するのか、具体的に解説していきます。
Azure ADにおけるパスワードスプレー攻撃の概要
Azure ADで運用するクラウド環境は世界中で利用者が多く、攻撃者にとっても魅力的な標的となりやすいことが現実としてあります。パスワードスプレー攻撃は、そのアカウントの多さに乗じて効率的にアカウント情報の一致を探る攻撃手法です。
実際に企業や組織でAzure ADのサインインログを見たとき、「不正な認証情報(パスワード誤り)」が大量に記録されている場合、このパスワードスプレーを疑うことが一般的です。
パスワードスプレーの基本的な仕組み
パスワードスプレーとは、攻撃者が特定のパスワードを広範囲のユーザーアカウントに対して同時・あるいは時間をずらしながら試行する攻撃手法です。
| 攻撃種別 | 概要 |
|---|---|
| パスワードスプレー | 同一または少数のパスワードを複数ユーザーで試す。ロックアウトを避けるために時間を置きながら反復 |
| ブルートフォース | 単一または限定的なアカウントに対して、総当たり的に多数のパスワードを試す |
企業や組織でありがちな共通パスワード(例：Spring2023!、Welcome123!など)が該当ユーザーにヒットすると、攻撃者は正しいパスワードを手に入れたことになります。MFAによる二段階認証を導入していれば、すぐにアクセスを許すことはありませんが、パスワードの漏えいや危険な使い回しにつながる恐れがあります。
多要素認証(MFA)があっても狙われる理由
MFAを設定していても、パスワード自体の管理が甘ければ最初の認証を突破されるリスクが残ります。特にAzure ADでは、パスワードが合っていればMFAや条件付きアクセスのステップへ進むため、攻撃者は正しいパスワードを突き止めるだけでも価値があるわけです。
パスワードスプレーによる大量認証試行の中で、一部のユーザーがパスワード使い回しをしていた場合、条件付きアクセスやMFAを迂回する新たな手段を攻撃者が探し当てることも懸念されます。
Azure ADサインインログで確認される主なログイン失敗の理由
Azure ADのサインインログを見ると、「パスワードが誤っている」という明確なエラーのほかに、いくつか特徴的な失敗理由が記録されることがあります。代表的なものに以下が挙げられます。
- ユーザーが許可された時間外にログオンを試行した(ADで指定された利用可能時間外)
- 条件付きアクセス ポリシーによりアクセスがブロックされた
これらは、しばしば「パスワードが正しいのにポリシーで拒否されたのか」あるいは「そもそもパスワードが間違っていたのか」が分かりづらい部分です。ここでは、それぞれのメカニズムをもう少し深掘りします。
時間外ログオンがブロックされたケース
Azure AD(現Microsoft Entra ID)とオンプレミスのActive Directoryを同期している環境の場合、オンプレミスで設定した「ログオン時間の制限」がクラウドにも反映されるケースがあります。
仕組みとステップ
- ユーザーがAzure ADへサインインを試みる
- ユーザー名とパスワードの照合が行われる
- 資格情報が正しい場合、次にオンプレミスのドメインポリシーや条件付きアクセスなどのステップで、ログインの可否を判定
- 許可時間外であれば、エラーが発生しブロックされる
この流れから、時間外ログオンのエラーが出るということは「少なくともパスワード照合が正しく通った」可能性が高いと推定できます。
ただし、システムの構成によっては、ログが作成されるタイミングや同期の状態によって完全にそう言い切れない場合もあります。誤ったパスワードであっても、なんらかの理由で時間外ログオンエラーとして記録される稀な事例も報告されています。結論としては、「多くの場合は正しいパスワードが入力されている」シナリオが高いものの、確証を得るにはAzure ADのサインイン詳細を調べる必要があります。
条件付きアクセスがブロックしたケース
条件付きアクセスポリシーはAzure ADで認証成功後、指定の条件(ユーザーリスク、デバイス、IPアドレス、アプリケーション等)を満たすかどうかを判定して、許可・ブロック・追加認証などを制御する仕組みです。
正しい資格情報が入力されている可能性
条件付きアクセスが「ブロックしました」というログは、多くの場合、ユーザー名・パスワードの認証をパスした上で、次の評価ステップでNGとなったことを意味します。もしパスワードが誤っていれば、そもそもそのユーザーとして認証が成立しないため、条件付きアクセスに進む前に「パスワード誤り」の段階でログイン失敗となるのが一般的です。
これらの特徴から、条件付きアクセスによってブロックされたログが大量に記録されているならば、攻撃者が何度も正しいパスワードを用いてアクセスを試みている恐れがあり、早急な対策が必要と考えられます。
正しいパスワードが入力されている場合のリスク
パスワードスプレー攻撃の試行を受け、実際に「時間外ログオン」や「条件付きアクセスがブロック」のログが多発している場合、そのアカウントは正しいパスワードを知られている可能性があります。ここで主に懸念すべきは、パスワードの使い回しによるアカウント侵害リスクです。
パスワード使い回しの問題
社内サービスや他のクラウドサービスで同一パスワードを使い回していた場合、他サービスがMFAを導入していなかったり、セキュリティが甘かったりすると、攻撃者がそこへ不正アクセスを仕掛ける可能性が高まります。
また、万一他社のサービスやWebサイトでパスワード漏えいが起き、それがAzure ADのアカウントのパスワードと同じだった場合、スプレー攻撃やリスト攻撃によって瞬時に突破されるリスクもあります。
調査と対応の優先度
万一、疑わしいログを発見した場合は、該当アカウントのユーザーにヒアリングし、直近でパスワードを変更したか、使い回しをしていないかを確認するとともに、速やかにパスワードを強力なものにリセットすることが求められます。さらに、Azure ADの「サインイン詳細」を精査して、実際に認証が成功しそうになった際のログのIPアドレスやデバイス情報、ブラウザ(ユーザーエージェント)などをチェックすると、より正確な状況把握が可能です。
Azure ADサインインログを活用した原因究明の手順
次に、サインインログをもとに原因を特定する手順と、運用のコツを整理します。
1. サインインログの詳細を確認
Azureポータルから「Azure Active Directory」→「サインイン」を選択し、対象のユーザーや時刻範囲でログを絞り込むと、該当の失敗ログを一覧できます。各イベントをクリックすると詳細が表示され、失敗理由やMFAのステータス、条件付きアクセスの評価結果などが確認可能です。
以下はPowerShellでGraph APIを使い、サインインログを取得するサンプルコード例です。
# Install MSGraph PowerShell module if not already installed
# Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "AuditLog.Read.All"
$startDate = (Get-Date).AddDays(-7).ToString("o") # 過去7日分
$endDate = (Get-Date).ToString("o")
# フィルタ条件を指定 (サンプル: ユーザー名や失敗イベントを絞り込み)
$query = "createdDateTime ge $startDate and createdDateTime le $endDate"
$signInLogs = Invoke-MgGraphRequest -Uri "/auditLogs/signIns?`$filter=$query"
foreach($log in $signInLogs.value) {
# ログの失敗理由や条件付きアクセス関連を出力
Write-Host "User: " $log.userPrincipalName
Write-Host "Status: " $log.status.errorCode
Write-Host "Failure Reason: " $log.status.failureReason
Write-Host "Conditional Access Policies: " $($log.appliedConditionalAccessPolicies | Select-Object -ExpandProperty displayName)
Write-Host "-----------------------------------"
}これによって、エラーコードや失敗理由、適用された条件付きアクセスポリシーなどの情報を一括取得できます。大量のログを調べる際には非常に便利です。
2. エラーコード・失敗理由を切り分ける
次に、具体的なエラーコードや失敗理由を分類し、どれがパスワード誤りによるものか、どれが時間外ログオンによるものか、あるいは条件付きアクセスやMFA関連かを可視化します。
よくある失敗理由の例を簡単にまとめると、以下のようになります。
| 失敗理由 | 意味 |
|---|---|
| Invalid username or password | ユーザー名またはパスワードが間違っている |
| User tried to sign in outside of allowed hours | オンプレミスAD等で設定されたログオン可能時間帯を外れているためブロック |
| Blocked by Conditional Access | 条件付きアクセスポリシーが適用されブロックされた |
| Access has been blocked by Multifactor Authentication | MFAが有効な状態で追加認証に失敗、もしくは強制的に拒否された |
| Password expired or needs to be changed | パスワードの有効期限切れや強制変更フラグが有効のためログインできない |
これらを可視化することで、どの失敗理由が多いのかを一目で把握できますし、パスワードが正しくても他のポリシーでブロックされている割合がどの程度かも把握しやすくなります。
3. IPアドレス・地理情報をチェック
サインインログにはIPアドレスやおおよその地理的位置が記録されます。もし普段アクセスしない国や地域からの大量試行が確認された場合、それは明らかに不正な攻撃であり、さらにパスワードが成功しかけている場合は重大なリスクシナリオとなります。
地理的に不審な地点からのアクセスは条件付きアクセスでブロックしておくか、Azure AD Identity Protectionのリスクベースポリシーを活用して対処することが推奨されます。
4. 疑わしいアカウントのパスワード変更と使い回し防止
もし特定のアカウントが何度も「時間外ログオン」あるいは「条件付きアクセスによるブロック」と表示されるようであれば、パスワードが合っている可能性を疑うべきです。速やかに当該ユーザーにパスワード変更を促すとともに、使い回しをしていないか確認します。
さらに、全社的にパスワードポリシーを強化し、定期的なパスワード変更や使い回しを防止する啓蒙活動を行うことが望ましいでしょう。
追加の対策と運用のポイント
Azure ADでパスワードスプレー攻撃を検知・対策するうえで、以下のような運用を検討してみてください。
リスクベースの条件付きアクセスやMFA強化
Azure AD Premiumライセンスを利用している場合、Identity Protectionの機能を用いると、異常なサインイン試行を自動で検知しリスクレベルに応じたポリシーを適用できます。例えば、リスクが高いサインインに対してはMFAを強制したり、アクセスをブロックしたりといった高度な制御が可能です。
ログイン試行をリアルタイムで監視
Azure MonitorやSentinelなどを活用し、サインインログを自動的に監視する仕組みを構築すると、パスワードスプレーと思われる大量認証失敗や、特定IPアドレスからの集中攻撃をリアルタイムで捕捉しやすくなります。
また、SIEM(Sentinelなど)と連携すれば、アラートを受信した瞬間に自動でアカウントをロックしたり、管理者に通知する仕組みを作ることも考えられます。
テストアカウントでの挙動検証
「時間外ログオン」や「条件付きアクセスブロック」の判定が正しく行われているかを、テスト用アカウントで実際に試してみることは非常に重要です。
- わざと誤ったパスワードを入力する
- 正しいパスワードを入力して時間外にログインしてみる
- 特定の条件付きアクセスポリシーが当たる状況を意図的に作る
こうしたステップを踏むことで、実際のログがどのように記録されるかが確認でき、誤認や設定ミスを防ぎやすくなります。
まとめと今後の展望
「ユーザーが許可された時間外にログオンを試行した」や「条件付きアクセスポリシーによりアクセスがブロックされた」というサインインログの失敗理由は、多くの場合、正しいパスワードを入力した後でポリシーによって拒否された可能性が高いと言えます。ただし、システム構成やログのタイミングによっては例外もあり得るため、Azure ADのサインイン詳細や実環境でのテスト結果から総合的に判断することが大切です。
もし正しいパスワードが外部に知られている場合は、パスワード使い回しや他サービスへの不正アクセスリスクが生じます。パスワードポリシーを強化し、MFA導入やリスクベースの条件付きアクセスを活用することで、攻撃の成功率を大幅に下げることができます。
今後は、パスワードレス認証やFIDO2などの利用が広がることで、パスワードを軸にした攻撃リスクは減少するかもしれません。しかし当面は、パスワードスプレー攻撃の脅威が依然として残るため、運用者としてはログのモニタリングやポリシーの適切な設定を継続的に行い、組織のセキュリティレベルを高め続けることが欠かせません。
コメント