FireEye Mandiantでは、Windows Active Directory環境で数多くのレッドチーム攻撃診断サービスを実施しています。そのため、Active Directory環境に統合されたLinuxシステムを頻繁に見ることがあります。個々のドメイン参加Linuxシステムを侵害することは、それ自体で有益なデータを入手できる可能性がありますが、最も価値のあることは、水平展開手法を容易にするKerberosチケットのようなデータを得られることです。こういったKerberosチケットをLinuxシステムから渡すことで、侵害されたLinuxシステムからActive Directoryドメインの残りの部分への水平展開が可能になります。

Kerberosチケットを保存するためのLinuxシステムの設定方法はいくつかあります。このブログ記事ではKerberosを解説し、さまざまなストレージ・ソリューションの一部を取り上げます。また、SSSD KCM（System Security Services Daemon Kerberos Cache Manager）を使用するドメイン参加システムからKerberosチケットを抽出する新しいツールについても説明します。

Kerberosとは

Kerberosは標準化された認証プロトコルで、元々は1980年代にMITによって作成されました。プロトコルは時間とともに進化し、現在、Kerberosバージョン5は、Microsoft Active Directoryを含む多数の製品に実装されています。Kerberosは元々、非セキュアなコミュニケーション回線を介してIDを相互認証するように設計されました。

Active Directory環境では、MicrosoftのKerberos実装を使用して、ドメイン（LDAP）、データベースサーバー（MSSQL）、ファイル共有（SMB/CIFS）などのさまざまなサービスに対してユーザーを安全に認証します。Active Directory内には他の認証プロトコルがありますが、Kerberosは最も一般的な手法の1つです。MicrosoftがActive DirectoryにKerberos Protocol Extensionsを実装する方法に関する技術文書は、MSDNに公開されているMS-KILE標準にあります。

Active DirectoryでのKerberos認証の簡単な例

Kerberosの動作を説明するために、ここでは一般的なシナリオを選びました。アカウントACMENET.CORP\sa_jsmithを持つユーザーJohn Smithが、サーバーSQLSERVER.ACMENET.CORPでホストされているAcme CorporationドメインのWindows SMB(CIFS)ファイル共有に対して認証を希望するというシナリオです。

Active Directoryで使用されるKerberosチケットには2つの主なタイプ、TGT（Ticket Granting Ticket）とサービス・チケットがあります。サービス・チケットは、TGS （Ticket Granting Service）から取得されます。TGTは、Active Directory内の特定のエンティティ（ユーザー・アカウントなど）のIDを認証するために使用されます。サービス・チケットは、システムでホストされている特定のサービスに対してユーザーを認証するために使用されます。有効なTGTを使用して、KDC（Key Distribution Center ）からサービス・チケットを要求することができます。Active Directory環境では、KDCはドメイン・コントローラーでホストされます。

認証フローを図1に示します。

図1：Kerberos認証フローの例

フローの要約：

1. ユーザーは、ドメイン・コントローラーからTGTを要求します。
2. 許可されると、ユーザーはTGTをドメイン・コントローラーに戻し、cifs/SQLSERVER.ACMENET.CORPのサービス・チケットを要求します。
3. ドメイン・コントローラーがリクエストを検証した後、SQLSERVER.ACMENET.CORPのCIFS（SMB）サービスに対して、ユーザーを認証するサービス・チケットが発行されます。
4. ユーザーは、ドメイン・コントローラーからサービス・チケットを受け取り、SQLSERVER.ACMENET.CORPとのSMBネゴシエーションを開始します。認証プロセス中に、ユーザーは以前に取得したサービス・チケットを含む「AP-REQ」構造内にKerberos BLOBを提供します。
5. サーバーはサービス・チケットを検証し、ユーザーを認証します。
6. サーバーがユーザーに共有へのアクセス権限があると判断した場合、ユーザーはSMBクエリを開始できます。

Kerberosの認証方法の詳細な例については、この記事の最後にある付録をご覧ください。

Linuxドメイン参加システムでのKerberos

LinuxシステムがActive Directoryドメインに統合されている場合、Kerberosチケットを使用して、Windows Active Directoryドメイン上のサービスにアクセスする必要もあります。Linuxでは、異なるKerberos実装を使用します。Linuxでは、Windows形式のチケット（通常はKIRBI形式と呼ばれる）の代わりに、MIT形式のCCACHEファイル（Kerberos Credential Caches）を使用します。

Linuxシステム上のユーザーがファイル共有などのKerberos認証による遠隔サービスにアクセスしたい場合、同じ手続を使用して、TGTおよび対応するサービス・チケットを要求します。古い、従来の実装では、Linuxシステムはほとんどの場合、/tmpディレクトリにクレデンシャル・キャッシュ・ファイルを格納します。ファイルはロックダウンされており、読み取り不可能ですが、Linuxシステムへのrootアクセスを持つ悪意のあるユーザーがKerberosのチケットのコピーを入手し、それを再利用することは当然でしょう。

Red Hat Enterprise Linuxの最新バージョンおよびその派生ディストリビューションでは、SSSD（System Security Services Daemon）を使用して、ドメインに参加したシステムでKerberosチケットを管理します。SSSDは独自の形式のKCM（Kerberos Cache Manager）を実装し、システム上のデータベース内のチケットを暗号化します。ユーザーがTGTまたはサービス・チケットにアクセスする必要がある場合、チケットはデータベースから取得されて復号され、リモート・サービスに渡されます。

デフォルトでは、SSSDはデータベースのコピーをパス/var/lib/sss/secrets/secrets.ldbに保持します。対応する鍵は、パス/var/lib/sss/secrets/.secrets.mkeyに隠しファイルとして保存されます。デフォルトでは、鍵はroot権限を持つ場合にのみ読み取り可能です。

ユーザーがこれらの両方のファイルを取り出し可能な場合、ファイルをオフラインで復号し、有効なKerberosチケットを取得できます。FireEyeはSSSDKCMExtractorという新しいツールを公開しました。これは、SSSDデータベース内の関連する秘密鍵を復号し、クレデンシャル・キャッシュKerberosのBlobを取り出します。このBlobは、使用可能なKerberos CCacheファイルに変換でき、Mimikatz、Impacket、smbclientなどの他のツールに渡すことができます。CCacheファイルは、Kekeoなどのツールを使用してWindows形式に変換できます。

復号されたKerberos Blobを、pass-the-cacheおよびpass-the-ticket操作に使用可能なクレデンシャル・キャッシュ・ファイルに変換することは、読者の皆様への演習として残しておきます。

SSSDKCMExtractorの使用は簡単です。SSSD KCM データベースおよび鍵の例を図2に示します。

図2：SSSD KCMファイル

--databaseおよび--keyパラメータを指定してSSSDKCMExtractorを呼び出すと、図3に示すように、データベースが解析され、秘密鍵が復号されます。

図3：Kerberosデータの抽出

取得されたデータの処理後、図4に示すように、smbclientでCCACHEを使用できます。この例では、ドメイン・アドミニストレーター・チケットが取得され、ドメイン・コントローラーのC$共有へのアクセスに使用されました。

図4：抽出されたチケットを使用したドメイン・コントローラーの侵害

Pythonスクリプトと使い方の説明はFireEye Githubからダウンロードできます。

結論

ドメイン参加Linuxシステムへの特権的アクセス権を得ることによって、多くの場合、水平展開に有用なKerberosチケットを取得することができます。これらのチケットは通常、/tmpディレクトリにありますが、最近では、SSSD KCMを使用する最新のLinuxシステムからも取得することができるようになりました。

適切なKerberosチケットを使用すると、Active Directoryドメインの残りの部分への水平展開が可能になります。権限のあるユーザーが侵害されたLinuxシステムを認証し（ドメイン管理者など）、チケットを残したままにすると、そのユーザーのチケットを窃取したり、Active Directoryドメインで特権的権限を取得したりすることができます。

付録：Active DirectoryでのKerberos認証の詳細な例

Kerberosの動作を説明するために、ここでは一般的なシナリオを選びました。アカウントACMENET.CORP\sa_jsmithを持つユーザーJohn Smithが、サーバーSQLSERVER.ACMENET.CORPでホストされているAcme CorporationドメインのWindows SMB(CIFS)ファイル共有に対して認証を希望するというシナリオです。

Active Directoryで使用されるKerberosチケット・タイプには2つの主なタイプ、TGT（Ticket Granting Ticket）とサービス・チケットがあります。サービス・チケットは、TGS （Ticket Granting Service）から取得されます。TGTは、Active Directory内の特定のエンティティ（ユーザー・アカウントなど）のIDを認証するために使用されます。サービス・チケットは、ドメイン参加システムでホストされている特定のサービスに対してユーザーを認証するために使用されます。有効なTGTを使用して、KDC（Key Distribution Center ）からサービス・チケットを要求することができます。Active Directory環境では、KDCはドメイン・コントローラーでホストされます。

ユーザーがリモート・ファイル共有への認証を希望する場合、Windowsはまず、ユーザーのワークステーション上のメモリに有効なTGTが存在するかどうかを確認します。TGTが存在しない場合、AS-REQリクエストのフォームで、ドメイン・コントローラーから新しいTGTが要求されます。パスワード・クラッキング攻撃（AS-REP Roasting）を防ぐために、デフォルトでは、Kerberos事前認証が最初に実行されます。Windowsはタイムスタンプを作成し、タイムスタンプをユーザーのKerberos鍵で暗号化します（注：ユーザーKerberos鍵は暗号化タイプによって異なります。RC4暗号化の場合、ユーザーのRC4 Kerberos鍵はユーザーのアカウント・パスワードから直接派生します。AES暗号化の場合、ユーザーのKerberos鍵は、ユーザーのパスワードと、ユーザー名とドメイン名に基づくソルトから派生します）。ドメイン・コントローラーはリクエストを受け取り、ユーザーのKerberos鍵を検索してタイムスタンプを復号します。AS-REQパケットの例を図5に示します。

図5：AS-REQ

事前認証が成功すると、ドメイン・コントローラーは、さまざまなメタデータ・フィールド、TGT自体、および「Authenticator」を含む、AS-REPレスポンス・パケットを発行します。TGT内のデータは機密と見なされます。ユーザーがTGT内のコンテンツを自由に変更できる場合、ゴールデンチケット攻撃で実施されたように、ドメイン内のすべてのユーザーを偽装できます。この偽装が容易に発生しないように、TGTはドメイン・コントローラーに保存されている長期Kerberos鍵で暗号化されます。この鍵は、Active Directoryのkrbtgtアカウントのパスワードから派生されます。

ユーザーが盗まれたTGT Blobを使用して別のユーザーに偽装しないようにするため、Active DirectoryのKerberos実装では、ユーザー、ドメイン、サービス間の相互認証に使用されるセッション・キーを使用します。TGTが要求されると、ドメイン・コントローラーはセッション鍵を生成し、TGT自体（krbtgt鍵で暗号化され、エンドユーザーには読み取り不可能）と、Authenticatorと呼ばれる別の構造体の、2つの場所に保存します。ドメイン・コントローラーは、ユーザーの個人用Kerberos鍵を使用してAuthenticatorを暗号化します。

Windowsは、ドメイン・コントローラーからAS-REPパケットを戻されると、TGTチケットデータ自体をメモリにキャッシュします。また、ユーザーのKerberos鍵を使用してAuthenticatorを復号し、ドメイン・コントローラーが生成したセッション鍵のコピーを取得します。Windowsは、このセッション鍵を将来の使用のためにメモリに保存します。この時点で、ユーザーのシステムには有効なTGTがあり、これを使用してドメイン・コントローラーからサービス・チケットを要求できます。AS-REPパケットの例を図6に示します。

図6：AS-REP

ユーザーのために有効なTGTを取得した後、Windowsは、リモート・システムSQLSERVER.ACMENET.CORPでホストされているファイル共有サービスのサービス・チケットを要求します。要求には、サービスのサービス・プリンシパル名（「SPN」）を使用します。この例では、SPNはcifs/SQLSERVER.ACMENET.CORPとなります。Windowsは、サービス・チケット・リクエストをTGS-REQパケットに構築します。TGS-REQパケット内では、Windowsはドメイン・コントローラーから以前に取得したTGTのコピーを保存します。今回、Authenticatorは、事前にドメイン・コントローラーから取得したTGTセッション鍵で暗号化されます。TGS-REQパケットの例を図7に示します。

図7：TGS-REQ

ドメイン・コントローラーはTGS-REQパケットを受信すると、リクエストからTGTを抽出し、krbtgt Kerberos鍵で復号します。ドメイン・コントローラーは、TGTが有効であることを確認し、TGTからセッション鍵フィールドを抽出します。次にドメイン・コントローラーは、セッション鍵を使用してTGS-REQパケット内のAuthenticatorの復号を試みます。いったん復号されると、ドメイン・コントローラーはAuthenticatorを検査し、コンテンツを検証します。この工程が成功すると、ユーザーはドメイン・コントローラーによって認証されたと見なされ、要求されたサービス・チケットが作成されます。

ドメイン・コントローラーは、cifs/SQLSERVER.ACMENET.CORPに対して要求されたサービス・チケットを生成します。サービス・チケット内のデータも機密と見なされます。ユーザーがサービス・チケット・データを処理できる場合、シルバーチケット攻撃で実施されたように、サービスに対するドメイン上のユーザーに偽装できます。これを容易に発生させないように、ドメイン・コントローラーはユーザーが認証しようとするコンピュータのKerberos鍵でサービス・チケットを暗号化します。Active Directory内のドメイン参加コンピュータはすべて、コンピュータとドメイン・コントローラーの両方が認識している、ランダムに生成されたコンピュータ・アカウント資格情報を持っています。また、ドメイン・コントローラーは、サービス・チケットに固有の第2のセッション鍵を生成し、暗号化されたサービス・チケットと新しいAuthenticator構造体の両方にコピーを保存します。このAuthenticatorは、最初のセッション鍵（TGTセッション鍵）で暗号化されます。サービス・チケット、Authenticator、メタデータはTGS-REPパケットにバンドルされ、ユーザーに戻されます。TGS-REPパケットの例を図8に示します。

図8：TGS-REP

Windowsがcifs/SQLSERVER.ACMENET.CORPのTGS-REPを受信すると、Windowsは、パケットからサービス・チケットを抽出し、それをメモリにキャッシュします。また、新しいサービス固有のセッション鍵を取得するために、TGT固有のセッション鍵でAuthenticatorを復号します。両方の情報を使用して、ユーザーがリモート・ファイル共有に対して認証できるようになりました。WindowsはSQLSERVER.ACMENET.CORPとのSMB接続をネゴシエートします。Kerberos Blobを「ap-req」構造体に保存します。このKerberos Blobには、ドメイン・コントローラーから受信したサービス・チケット、新しいAuthenticator構造体、およびメタデータが含まれます。新しいAuthenticatorは、ドメイン・コントローラーから以前に取得したサービス固有のセッション鍵で暗号化されます。認証処理を図9に示します。

図9：SMBへの認証（AP-REQ）

ファイル共有サーバーは、認証リクエストを受信すると、まずKerberos認証Blobからサービス・チケットを抽出して復号し、その中のデータを検証します。また、サービス・チケットからサービス固有のセッション鍵を抽出し、それを使用してAuthenticatorの復号を試みます。この工程が成功すると、ユーザーはサービスに対して認証されていると見なされます。サーバーは、サービス固有のセッション鍵で暗号化された最終的なAuthenticatorをユーザーに送り返すことで、認証に成功したことを確認します。この動作で、相互認証プロセスが完了します。レスポンス（「ap-rep」構造体内に含まれる）を図10に示します。

図10：最終のAuthenticator（相互認証、AP-REP）

認証フローの図を図11に示します。

図11：Kerberos認証フローの例

本ブログは、米FireEyeが公開した April 01, 2020「Kerberos Tickets on Linux Red Teams」（英語）の日本語抄訳版です。

日本語版：Reviewed by Toru Tanimura