悪意のあるサインイン試行を追跡するのは容易ではない
最近、Azureパスワードレス認証が設定された環境で、不審な挙動があったため調査しました。調査のきっかけは、複数のユーザーが予期せぬAuthenticatorアプリのプロンプトを表示されたことでした。信用できることに、どのユーザーも策略にはまらず、攻撃者を侵入させることはありませんでした。
MFA疲労として知られるこの種の事象は、大小の組織で日常的に発生し、予想されている。攻撃者はこのソーシャル・エンジニアリングのテクニックを活用し、ユーザーを騙してプッシュ認証のプロンプトを受け入れさせようとする。）
このシナリオは、失敗したパスワードなしのプロンプトに関連するログ記録のため、調査するのが独特に困難であることが判明した。
ロギング機能の制限が調査を複雑にする
悪意のあるサインイン試行を追跡することは、クラウド環境を保護するために非常に重要であり、利用可能なクラウドログを監視することによってのみ可能である。マイクロソフトと他のクラウドプロバイダーはログのスキーマを公開し、記録配信のサービス・レベル・アグリーメント (SLA) を提供しているが、クラウドログを悩ませるいくつかの問題がまだある：
- レコード・イベントのタイプはよく文書化されていないことが多く、まったく文書化されていないこともある。
- ログに記録される値やIDの中には、クラウドプロバイダー内部のものもあり、その意味は不明である。
- 新しいログ記録タイプが追加され、記録タイプが廃止され、記録フォーマットが消費者に通知することなく変更される。
このすべてが、インシデントの監視とレスポンス を複雑にし、クラウド消費者がログ記録の完全性について確信が持てないまま、予告なしの変更に対してキャッチアップをすることになる。
Azureにおけるパスワードなしサインインの失敗を発見し、緩和するための詳細な考察
パスワードレス認証
馴染みのない人のために説明すると、パスワードレス認証は、ユーザーが安全でないパスワードを作成するリスクを軽減するための強固なオプションである。Azureでパスワードレス認証を有効にするには、いくつかの方法がある。調査した環境では、Microsoft Authenticator Appを使用した。
パスワードレス認証に登録するには、エンドユーザーは以下の詳細な設定手順に従う。この方法で登録が完了したら、Azureのサインインプロンプトにユーザー名を入力し、「代わりにアプリを使う」オプションを選択することができる：
その後、ユーザーはモバイルアプリに入力する番号を与えられ、手続きを完了する：
番号が一致すれば、ユーザーは認証される。それなりに安全である一方、この方式では、ユーザーはもはや良いパスワードを作ったり覚えたりする必要がないため、使い勝手が大幅に向上する。
調査
過去には、Microsoft Authenticator を第 2 要素として使用したパスワードレス・サインインなど、Azure で MFA を設定するさまざまな方法を監視してきました(つまり、ユーザーが正しいパスワードを入力した後、アプリでプロンプトが表示される場合）。Microsoft Authenticator を第 2 の要素として使用する場合、Authenticator プロンプトが放棄されるか、コードが正しくない場合、ログに次の 2 つのエラーのいずれかが記録されます：
- 50074 強力な認証が必要です。
- 500121 強力な認証要求中に認証に失敗しました。
その結果、これらのエラーコードを探すために、検知とハンティングのクエリーが設定された。
しかし、Microsoft Authenticatorアプリが、パスワードレス認証の場合のようにシングルファクターとして設定されている場合、プロンプトが放棄されると、次のようなエラーが表示された。
- {"errorCode":1003033,"failureReason":"The remote NGC session was denied."}
このエラーコードは斬新で、これまで見たこともなく、インターネットを検索してもその原因に関する情報はほとんどない。エラーメッセージも不可解で、"NGC "が何であるかの説明もない。検索した結果、「PIN Credential Provider」として記録されているGUID D6886603-9D2F-4EB2-B667-1971041FA96Bに対応することがわかりました。
ログの記録を調べると、他にもいくつかの矛盾点が見つかった(下のスクリーンショットを参照）：
- 場所とデバイスの詳細(赤色）は入力されていません。
- アプリとリソース情報(青字）が欠落している。
- ユーザー情報（紫色）が制限されています。UserPrincipalNameとUserDisplayNameには、期待される値（ユーザの電子メールアドレスとフルネーム）が入力されていません。代わりに、UserIdの値が3つのフィールドすべてにあります。
異常なエラーコードとログ記録の欠落データにより、このような事象に対するアラートや適切な調査が難しくなっている。
緩和
このインシデントを調査することが困難であったため、私たちは収集した詳細をセキュリティ・コミュニティと共有し、セキュリティ実務者がこの状況を捕捉するためにハンティング・クエリを調整できるようにしたいと考えました。私たちVectra は、このシナリオをカバーするために、すでに製品をアップデートしました。
ハンティングクエリは、過去30日間に失敗したパスワードなしログインをすべて検索する以下のKustoスニペットのように単純なものでよい：
SigninLogs | where TimeGenerated > ago(30d) | where ResultType == 1003033
NGCに関連する他のエラーコードも参考になるだろう：
収穫：
- 環境に新しい認証方法を導入する場合、これらの新しいメカニズムとのやり取りから生じるログを評価する。監視とアラートのために考慮する必要があるかもしれない、新しいエラー・コードとログ・レコード・タイプを探す。
- パスワードなしでのサインイン失敗を監視する組織は、ハンティング・クエリにコード1003033を追加することを検討すべきである。このレコードで利用可能な情報は限られていることに注意してください。UserPrincipalNameや、サインイン・ログ・レコードで通常利用可能なその他の情報を使用することはできません。
- クラウドプロバイダー (マイクロソフトを含む) への呼びかけ：ログを、多くのアクターが依存している重要なセキュリティ機能として扱ってください。ログの記録を徹底的に文書化し、ログから欠落している情報を補い、変更を加える場合はそれを発表してください。そうすることで、顧客やセキュリティ・ベンダーが、すべての人の安全を守るために戦うことができるようになります。
ピーター・シャウプとレイ・バレロに感謝の意を表したい。