Linux Red Team の Kerberos チケット

FireEye Mandiantでは、Windows Active Directory 環境内で多数のレッド チームの関与を行っています。その結果、Active Directory 環境内に統合された Linux システムに頻繁に遭遇します。ドメインに参加している個々の Linux システムを侵害することは、それ自体で有用なデータを提供できますが、最善の価値は、ラテラル ムーブメント テクニックを容易にする Kerberos チケットなどのデータを取得することです。これらの Kerberos チケットを Linux システムから渡すことにより、侵害された Linux システムから Active Directory ドメインの残りの部分に横方向に移動できます。

Kerberos チケットを格納するように Linux システムを構成するには、いくつかの方法があります。このブログ投稿では、Kerberos を紹介し、さまざまなストレージ ソリューションの一部を取り上げます。 System Security Services Daemon Kerberos Cache Manager (SSSD KCM) を利用するドメインに参加しているシステムから Kerberos チケットを抽出する新しいツールも紹介します。

ケルベロスとは

Kerberos は、1980 年代に MIT によって最初に作成された標準化された認証プロトコルです。プロトコルは時間とともに進化してきました。現在、Kerberos バージョン 5 は、Microsoft Active Directory を含む多数の製品で実装されています。 Kerberos は当初、セキュリティで保護されていない通信回線を介して ID を相互に認証するように設計されました。

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

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

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

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

図 1 の図は、認証フローを示しています。

要約すれば：

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 実装を使用します。 Windows 形式のチケット (一般に KIRBI 形式と呼ばれる) の代わりに、Linux は MIT 形式の Kerberos Credential Cache (CCACHE ファイル) を使用します。

Linux システムのユーザーがファイル共有などの Kerberos を使用してリモート サービスにアクセスする場合、同じ手順を使用して TGT と対応するサービス チケットを要求します。より古い、より伝統的な実装では、Linux システムは多くの場合、認証情報キャッシュ ファイルを /tmp ディレクトリに格納していました。ファイルはロックダウンされており、誰でも読み取ることはできませんが、Linux システムへのルート アクセス権を持つ悪意のあるユーザーは、Kerberos チケットのコピーを簡単に取得して再利用することができます。

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

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

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

復号化された Kerberos blob を pass-the-cache 操作と pass-the-ticket 操作で使用できる資格情報キャッシュ ファイルに変換することは、読者の課題として残しておきます。

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

–database パラメーターと –key パラメーターを指定して SSSDKCMExtractor を呼び出すと、データベースが解析され、シークレットが復号化されます (図 3 参照)。

取得したデータを操作した後、図 4 に示すように smbclient で CCACHE を使用できます。この例では、ドメイン管理者チケットが取得され、ドメイン コントローラーの C$ 共有にアクセスするために使用されています。

Python スクリプトと手順は、FireEye Github で見つけることができます。

結論

ドメインに参加している Linux システムへの特権アクセスを取得することで、ラテラル ムーブメントに役立つ Kerberos チケットをスクレイピングできることがよくあります。 /tmp ディレクトリでこれらのチケットを見つけることは依然として一般的ですが、SSSD KCM を利用する最新の Linux システムからこれらのチケットをスクレイピングすることも可能になりました。

適切な Kerberos チケットがあれば、横方向に Active Directory ドメインの残りの部分に移動できます。特権ユーザーが侵害された Linux システム (ドメイン管理者など) に対して認証を行い、チケットを残した場合、そのユーザーのチケットを盗み、Active Directory ドメインでの特権権限を取得する可能性があります。

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

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

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

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

事前認証が成功すると、ドメイン コントローラは、さまざまなメタデータ フィールド、TGT 自体、および「オーセンティケータ」を含む AS-REP 応答パケットを発行します。 TGT 自体のデータは機密情報と見なされます。ユーザーが TGT 内のコンテンツを自由に変更できる場合、ゴールデン チケット攻撃で実行されたように、ドメイン内の任意のユーザーになりすますことができます。これが簡単に起こらないようにするために、TGT はドメイン コントローラに保存されている長期の Kerberos キーで暗号化されています。このキーは、Active Directory の krbtgt アカウントのパスワードから派生します。

ユーザーが盗まれた TGT BLOB で別のユーザーになりすますのを防ぐために、Active Directory の Kerberos 実装では、ユーザー、ドメイン、およびサービス間の相互認証に使用されるセッション キーを使用します。 TGT が要求されると、ドメイン コントローラーはセッション キーを生成し、TGT 自体 (krbtgt キーで暗号化され、エンド ユーザーが読み取れない) と、オーセンティケーターと呼ばれる別の構造の 2 つの場所に配置します。ドメイン コントローラは、オーセンティケータをユーザーの個人用 Kerberos キーで暗号化します。

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

ユーザーの有効な TGT を取得した後、Windows は、リモート システム SQLSERVER.ACMENET.CORP でホストされているファイル共有サービスのサービス チケットを要求します。要求は、サービスのサービス プリンシパル名 (「SPN」) を使用して行われます。この場合、SPN は cifs/SQLSERVER.ACMENET.CORP になります。 Windows は、TGS-REQ パケットでサービス チケット要求を作成します。 Windows は、TGS-REQ パケット内に、以前にドメイン コントローラーから取得した TGT のコピーを配置します。今回は、Authenticator は、以前にドメイン コントローラーから取得した TGT セッション キーを使用して暗号化されます。 TGS-REQ パケットの例を図 7 に示します。

ドメイン コントローラーが TGS-REQ パケットを受信すると、要求から TGT を抽出し、krbtgt Kerberos キーで復号化します。ドメイン コントローラーは、TGT が有効であることを確認し、TGT からセッション キー フィールドを抽出します。次に、ドメイン コントローラーは、セッション キーを使用して TGS-REQ パケット内のオーセンティケーターの暗号化を解除しようとします。暗号化が解除されると、ドメイン コントローラはオーセンティケータを調べて内容を検証します。この操作が成功すると、ユーザーはドメイン コントローラーによって認証されたと見なされ、要求されたサービス チケットが作成されます。

ドメイン コントローラーは、cifs/SQLSERVER.ACMENET.CORP に対して要求されたサービス チケットを生成します。サービス チケット内のデータも機密情報と見なされます。ユーザーがサービス チケット データを操作できる場合、Silver Ticket 攻撃で実行されたように、ドメイン上の任意のユーザーになりすましてサービスを利用することができます。これが簡単に起こらないようにするために、ドメイン コントローラーは、ユーザーが認証しているコンピューターの Kerberos キーを使用してサービス チケットを暗号化します。 Active Directory 内のドメインに参加しているすべてのコンピューターは、コンピューターとドメイン コントローラーの両方が認識する、ランダムに生成されたコンピューター アカウントの資格情報を持っています。また、ドメイン コントローラーは、サービス チケットに固有の 2 番目のセッション キーを生成し、暗号化されたサービス チケットと新しいオーセンティケーター構造の両方にコピーを配置します。このオーセンティケーターは、最初のセッション キー (TGT セッション キー) で暗号化されます。サービス チケット、オーセンティケータ、およびメタデータは TGS-REP パケットにバンドルされ、ユーザーに転送されます。 TGS-REP パケットの例を図 8 に示します。

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

ファイル共有サーバーは、認証要求を受信すると、まず Kerberos 認証 BLOB からサービス チケットを抽出して解読し、その中のデータを検証します。また、サービス チケットからサービス固有のセッション キーを抽出し、それを使用してオーセンティケーターの暗号化を解除しようとします。この操作が成功すると、ユーザーはサービスに対して認証されたと見なされます。サーバーは、サービス固有のセッション キーで暗号化された 1 つの最終認証子をユーザーに送り返すことで、認証の成功を確認します。このアクションにより、相互認証プロセスが完了します。応答 (「ap-rep」構造に含まれる) を図 10 に示します。

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