はじめに
Microsoft では、ITDR ソリューションとして Microsoft Defender for Identity (以後、MDI) を提供しています。
本記事では、MDI が検出する多数のアラートから、資格情報アクセス アラートに分類される以下アラート(攻撃) にフォーカスして説明します。
- AS-REP ロースト攻撃の疑い
- Kerberos SPN の公開の疑い
- DCSync 攻撃の疑い (ディレクトリ サービスのレプリケーション)
ちなみに、何故これらのアラートに絞ったかというと、これら攻撃への予防策自体は比較的設定が簡単なためです。もし環境内で該当する設定がある場合には、本当に必要な設定であるか今一度ご確認頂ければと思います！
MDI の資格情報アクセス アラートについて
MDI が検出するアラートは、一般的なサーバーキルチェーンのフェーズに則り以下のカテゴリに分類されます。
- 偵察と検出アラート
- 永続化と特権のエスカレーション アラート
- 資格情報アクセス アラート
- 横移動アラート
- その他のアラート
"資格情報アクセス" はその名前の通り、ID やパスワード等のクレデンシャルを盗み出す攻撃を指します。
各アラートのほとんどは MITRE ATT&CK の攻撃手法と紐づいていますので、併せて確認頂ければと思います。
(補足) Kerberos 認証のおさらい...
アラート内容の説明において Kerberos 認証の概要が分かっていると、攻撃のイメージや予防策の効果が理解しやすくなります。
昨今では多くの方が Kerberos 認証を説明する記事を執筆されていますので、ここでは全体の説明はしませんが、次に案内するアラートの理解に必要な "Kerberos 認証で利用される暗号鍵" と "事前認証" のみ簡単に説明します。
Kerberos 認証で利用される暗号鍵について
以下は、クライアントがファイルサーバーに接続する際の Kerberos 認証の流れを上から順に記載しています。
<Kerberos 認証の流れ>
実際にはセッションキーやPAC、認証情報等も構成要素として存在しますが、出来る限りシンプルにするため本図からは省いています。
観点としては、どのキーがどのアカウントのパスワードを元に生成されているのか、またそのキーが何を暗号化するために利用されているかを確認頂ければと思いますが、Service Key だけ補足します。
図に記載の通り、Service Key は、アクセス先リソース (サービス) に紐づくアカウントのパスワードをもとに生成されます。少々文言が分かりにくいですが、例えばファイルサーバーであれば、ファイル共有の機能を持つServer サービスが、"サービス"となります。この Server サービスは既定で Local System Account が実行アカウントとなっており、つまりコンピューター自身がサービスに紐づくアカウントとなります。
サービスに紐づくアカウントが何であるかは、SPN (Service Principal Name 属性) で定義されます。SPN というと、コンピューターアカウントに紐づいているもの...というイメージがありますが、例えば、IIS の実行アカウントをユーザーアカウントに設定する場合にはサービスに紐づくアカウントはユーザーであり、SPN を定義する対象はそのユーザーオブジェクトということになります。
そのため、Service key がユーザーのパスワードを元に生成されるケースが存在しますが、この点がKerberos SPN の公開の疑い (Kerberoasting) における重要なポイントとなります。
事前認証について
<AS Request> では、事前認証情報 (タイムスタンプ) を認証するユーザーのパスワードを元に生成された鍵で暗号化し、ドメイン コントローラーに送信します。
ドメイン コントローラーでも、当然同じ鍵を保持しているため、同じ鍵で復号し、タイムスタンプに大きなずれが無いかを確認し問題が無ければ、<AS Response> として TGT を返送します。この確認を事前認証と呼びますが、仮にここでクライアント側が入力したパスワードに誤りがあれば当然復号に失敗するため、事前認証は、パスワードが一致しているか (復号することが出来るか) をチェックしているものと考えて問題ありません。
この事前認証の流れをもう少し厳密に見ると実際には以下のような流れで行われています。
初回の <AS Request> では、ユーザー名などの情報のみ送信し、ドメイン コントローラーから "KDC_ERR_PREAUTH_REQUIRED" の応答を受けて初めて、事前認証情報を含む <AS Request> を送信する動作になります。
その後は上述の通り <AS Response> にて TGT を返しますが、併せて TGS Session Key という鍵を、User Key で暗号化したものを返します。
この TGS Session Key は <TGS Request> で必要となる鍵ですが、ドメイン コントローラーが保持する User Key で暗号化されている...という点が "AS-REP ロースト攻撃" における重要なポイントとなります。
1. Kerberos SPN の公開の疑い
本アラートが検出された場合、Kerberoasting 攻撃が疑われます。
Kerberoasting は SPN を持つ脆弱なサービスアカウント (ユーザーアカウント) のサービスチケットを取得して、
オフラインでパスワードをクラックする攻撃手法です。
以下の黒丸で囲まれているサービスチケットが対象となります。
権限の低い一般ユーザーで合っても TGT さえ持っていれば、任意のサービスチケットを取得すること自体は基本的に可能です。もちろん認証が通っても認可 (アクセス権) が無ければ、該当サービスを利用することはできません。
SPN を持つサービスアカウントが狙われる理由としては、比較的高権限であること、Kerberos チケット(Service Key) の暗号化タイプが RC4 である可能性が高いためと想定されます。
※ 通常、サービスアカウント (ユーザーオブジェクト) は、msDS‑SupportedEncryptionTypes 属性がnull のため、この場合特にドメイン コントローラー側で制御していない限り、RC4 が利用されます。
予防策
有効な予防策としては以下辺りが考えられます。
- SPN を持つサービスアカウント (ユーザーオブジェクト) の内不要なアカウントを削除する
- 必要なサービスアカウントはgMSA に移行することを検討する
- Kerberos 暗号化タイプ (msDS‑SupportedEncryptionTypes 属性) を AES に変更する
2. AS-REP ロースト攻撃の疑い
本アラートが検出された場合、AS-REP ロースト攻撃が疑われます。
AS-REP ロースト攻撃は、事前認証が無効化されたアカウントを悪用し AS Response に含まれる、User Key で暗号化された TGS Session Key をオフラインでパスワードをクラックする攻撃手法です。
以下の黒丸で囲まれているキーが対象となります。
事前認証が有効であれば、正しいパスワードを入力しない限り AS Response は返りませんが、事前認証が無効な場合、AS Request に対して暗黙的に AS Response を返します。
先ほど、『事前認証とはパスワードが一致しているか (復号することが出来るか) をチェックしている』と記載しましたが、『事前認証が無効化されているなら、どんなパスワードでもKerberos 認証出来るということ？』と思われるかもしれません。結論から言うとそれは No です。誤ったパスワードを入力している場合、AS Response が返ってきたとしても、正しい User key (正しいパスワード) で暗号化されたTGS Session Key を復号することが出来ないため、クライアント目線で見ると、結局は Kerberos 認証が失敗します。
つまり、事前認証が無効化されていると、どのようなパスワードであれ、正しい User key (正しいパスワード) で暗号化された TGS Session Key が取得できるという点が狙われるということになります。
予防策
- 事前認証が無効化されているアカウントを列挙し、有効化を検討する
3.DCSync 攻撃の疑い (ディレクトリ サービスのレプリケーション)
本アラートが検出された場合、DCSync 攻撃が疑われます。
DCSync 攻撃は、Active Directory の複製権限を悪用し、ドメイン内全アカウントのパスワードハッシュ含むすべてのデータベース情報を取得する攻撃手法です。
対象の権限は「ディレクトリの変更をすべてにレプリケート (Replicating Directory Changes All)」と、「ディレクトリの変更のレプリケート (Replicating Directory Changes)」 となりますが、既定でこれら権限は Domain Admins やEnterPrise Admin,Domain Controllers 等、特権アカウントのみが持っています。
そのため、一般アカウントなどに当該権限が意図せず付与されている場合、大きなリスクがあると言えます。
予防策
- ドメインオブジェクトに対する当該権限をチェックし、意図しないアカウントに付与されていないことを確認する。
※"フルコントロール" 権限にもご注意ください。