はじめに
ネクストリードでは企業の Microsoft 365 のセキュリティ運用を総合的に支援をしていますが、その中で、かなりの頻度で顧客のパスワード漏えいを検知し、その都度パスワード リセットの案内をしています。
パスワード漏えいは多くの人が思っているよりも頻繁に発生しており、身近な問題です。
パスワード漏えいを検知するマイクロソフト標準の機能としては、Entra ID のリスク検出 漏洩した資格情報 (Leaked credentials) がありますが、今回は Entra ID サインイン ログの分析によって自社に最適化した独自のパスワード漏えい検知の仕組みを作るための方法を紹介したいと思います。
前提条件
本ブログで紹介する方法は Entra ID のサインイン ログからパスワード漏えいを検知する方法です。
下記の前提条件を満たしている企業は同じ方法を試すことができます。
- Entra ID P1 もしくは P2 のテナント
- サインイン ログを Microsoft Sentinel (もしくは Log Analytics) に転送している
なぜパスワードは漏えいするのか
本題に入る前に、そもそもなぜパスワードは漏えいしてしまうのかを整理します。
結論としては、主に下記の 3 つの経路でパスワードが漏えいしていると考えられます。
- パスワード スプレー
- フィッシング
- 利用サービスのハッキング
1. パスワード スプレー
Entra ID のサインイン ログを見ていると、失敗したサインイン ログが多数出力されていることに気づくと思います。
これらのサインインの一部は自動化された攻撃によるもので、攻撃ツールにアカウント リストとパスワード リストの 2 つを読み込ませて自動的にサインイン試行しているものです。
よく使われるパスワードや容易に推測できるパスワードを使用している場合には、パスワード スプレーによってパスワードが漏えいします。
これは推測ですが、最後が数字のパスワードなどは数字を変えて試行するくらいのことはやっていると思います。(パスワード変更後にまたすぐに突破されるような場合、ヒアリングをするとだいたい数字を変えただけだったりします。)
2. フィッシング
主に成りすましメールを送って攻撃者の Web ページのリンクを踏ませ、Microsoft 365 やその他のクラウド サービスのサインイン画面に似せたページに入力されたパスワードを窃取します。
パスワード スプレーは推測が困難なパスワードを使用していれば防ぐことができますが、フィッシングはどんな複雑なパスワードでも漏えいしてしまいます。
最近では攻撃者側でプロキシ サーバーを構築し本物のログイン ページとユーザーのやり取りを中継することで、パスワードやトークン、Cookie を窃取するタイプのフィッシングもあり、このような攻撃を特に Adversary in the middle (AITM) と呼びます。AITM は MFA をバイパスできる攻撃としてもよく紹介されています。
3. 利用サービスのハッキング
会社のパスワード (AD や Entra ID のパスワード) を外部システムやアプリケーションで使いまわしている場合、その外部システムやアプリケーションが攻撃者にハッキングされることでパスワードが漏えいします。
認証システム側でパスワードを保管する際にパスワード ソルティング (※) などの対策をしていれば仮にハッキングされても平文のパスワードは漏えいしませんが、そのような対策をとっていない (あるいは甘い) とパスワードが平文で漏えいします。これについてはユーザーにパスワードを使いまわさないように教育するくらいしか打ち手がありません。
パスワード ソルティング
"ソルト" と呼ばれるユーザー毎にユニークな文字列をパスワードに追加した上でハッシュ化してデータベースに保存することで攻撃者がレインボーテーブルなどの方法で平文のパスワードを入手できなくする方法
上記以外でもマルウェアによってデバイス上に保存された資格情報が盗られたり、ショルダーハックされたり、ソーシャル エンジニアリングで聞き出されたりなどの他の経路も考えられます。
このように様々なパターンでパスワードは漏えいするため、「パスワードを漏れないようにする」と考えるのではなく、「パスワードが漏えいすることはしょうがない」と認めた (諦めた) 上でどのような対策をとれるかを考えるマインドが企業のセキュリティ担当者に求められると思います。
パスワード漏えいの検知方法
それでは、パスワード漏えいの検知方法を具体的に説明していきます。
1. パスワード突破されたエラー コードを知る
Entra ID のサインイン ログには ResultType というフィールドがあり、サインインのエラー コードが記録されています。
例えば、0 は成功、50126 はパスワード間違い、53003 は条件付きアクセスでブロック、などです。
Entra ID のエラー コードのリストは下記を参照してください。
https://learn.microsoft.com/ja-jp/entra/identity-platform/reference-error-codes
先に挙げた 50126 と 53003 はどちらもサインインが失敗したことを示していますが、意味的には大きな違いがあります。
条件付きアクセスは 1 段階目のパスワードの認証が通った後、2 段階目で評価されます。つまり、攻撃によるサインインが 2 つあったとして、エラー コードがそれぞれ 50126 (パスワード間違い) と 53003 (条件付きアクセスでブロック) だった場合、後者だけがパスワードが突破されていることになります。
53003 以外でもパスワードによる認証が通った後の処理によって記録されるエラー コードはありますので、自社のログを分析して前述の URL を参考に調べてみましょう。
1 段階目のエラー コードの代表例として 50126 や 50053 があり、2 段階目で評価された例として 53003 や 50140 などがあります。
2. 攻撃によるサインイン ログを知る
ネクストリードで過去に実施したアセスメントでは、たった 1 か月分のログ分析だけでも約 75% の企業で「明らかな攻撃」によるサインイン ログが確認され、そのうち約 37% ではパスワード漏えいを検知しています。
上記の「明らかな攻撃」を識別するにはある程度経験が必要ですが、おおよそ下記のような状況できます。
- 普段ユーザーが使用しているサインイン傾向と大きく異なる
- IP アドレスのロケーション
- ユーザー エージェント (OS やブラウザ、アプリケーション)
- 認証プロトコル (レガシー認証)、など
- 様々な国から同一ユーザー エージェントで同一アプリケーションにサインインしている
- 数年前の古いバージョンのブラウザからのサインイン
- 一般ユーザーがあまりサインインせず攻撃ツールで良く使用されるアプリケーション
- O365 Suite UX
- Microsoft Azure PowerShell
- Azure Active Directory PowerShell、など
- エラー コードが 50053 で説明が "Sign-in was blocked because it came from an IP address with malicious activity" となっている
上記の観点でログ分析をして、その企業に来ている攻撃を識別するための Kusto クエリを作成します。
ほとんどの攻撃は失敗していると思いますので、クエリを作成する際、ResultType を 50126 と 50053 に限定して分析すると攻撃を見つけやすいと思います。
同様に、ほとんどの攻撃は社外ネットワークから来ていると思いますので、ネットワークを社外ネットワークに限定したり、デバイス ID がある (デバイスが識別できる) ログは除外するとさらに通常のサインインを除外して分析を進められます。
この段階では、サインインが成功しているか失敗しているかは気にせず、「明らかな攻撃」と思われるログを精度よく識別するための条件をつくることにフォーカスします。
3. 上記の組み合わせて検知する
前述の 2. の方法で自社に対する攻撃を識別する Kusto クエリが完成したら、そのクエリに前述の 1. のエラー コードを条件として付加すれば、パスワード漏えいを検知するクエリが完成します。
下記はクエリのサンプルですが、4 行目に 1. のエラー コードを評価する条件を追加しています。実際には攻撃を検出しながら通常のサインインを結果から除外するための複数の条件を付加する必要があります。
いったんクエリが出来れば、Sentinel の分析ルールを作成してアラート化するなどの方法でパスワード漏えいを素早く検知出来るようになります。
これまで説明した方法では、クエリ作成部分が最も難しく肝になる部分ですが、悩ましいのが誤検知の排除です。
網羅性と誤検知率に関してはトレードオフの関係になるのですが、それでもログ分析とクエリ チューニングによって検知精度を向上させることは可能です。ここに関してはどこまで時間をかけるか・・という世界になってきます。
また、精度を維持するには、クエリを作成して終わりというわけにもいかず、定期的にハンティングを実施してクエリをチューニングすることも必要になります。
この辺は知見が蓄積されている外部サービスの利用を検討しても良いと思います。
おわりに
パスワード漏えいの検知と対応は、その後に続くはずだったさらなる侵害を未然に防いだと評価してもいいくらいだと思っています。逆に、「条件付きアクセスでブロック出来ているから」と放置する (もしくは気づかない) ことで、条件付きアクセスの穴をつかれたり (実際、条件付きアクセスの設定漏れを検索する攻撃ツールも存在します)、社内ネットワークに侵入する別の脆弱性との組み合わせで突破されたりといった具体的な被害に繋がることもあり得ます。
パスワード漏えいを検知したらすぐに対応する習慣をつけることで、攻撃者にとって「コスパが悪い」企業になり、自社が攻撃の標的になりにくくなるといった効果もきっとあると思いますので、パスワード漏えいを検知する仕組みづくりにチャレンジしてみましょう！私たちにお手伝いできることがあればぜひお声かけください。
また、本ブログの趣旨からは離れますが、そもそもパスワードはそれ自体が構造的欠陥があるため「パスワードを使わない運用が出来ないか」と模索することも重要な発想です。
私たちが支援している企業でも SSO やインフラ整備を一つ一つ進めることによりパスワードレスの準備がほぼ完了し、パスワードのランダム化 (パスワードは技術的に削除できないのでユーザー自身も分からない状態にすることでパスワードを使わない状態を実現します) まであと一歩に迫るところも出てきました。
パスワードレスになればフィッシングや不正サインインのリスクは限りなくゼロにできますので、認証セキュリティの観点では技術的に出来ることとしてはほぼ完成形になると思います。(Assume breach の原則により、それでもサインイン ログの監視は必要です。新しい攻撃手法も次々に見つかっています。)
パスワードレスの展開についても別の記事にこれまでの支援から得たエッセンスをまとめたいと思います。
パスワード漏えいに目を光らせながら、次の施策としてパスワードレスへの道を模索していきましょう。