タイトル：Kerberos認証のためのいくつかの攻撃方法の概要

Kerberos認定プロセス

序文

この記事では、主にドメインでのKerberos認定に関する最近学んだ攻撃方法の一部を共有しています。それは主に自己理解に焦点を当てており、原則の理解から基本的なツール利用に至るまで、それを説明します。個人的な理解と分析は比較的長続きします。長すぎると思われる場合は、ジャンプして見ることができます。私を許してください。エラーがある場合は、修正を行うようにマスターに依頼してください

Kerberos認証プロセスは単純な説明であり、PAC、S4U2Self（委任）、S4U2Proxy（委任）など、説明されていない多くの詳細があります。

この記事の主な環境はvulnStack、Hongri射撃場です

ドメインコントロールOWA WIN2008R2 192.168.52.138ドメインホストSUT1 WIN7 192.168.52.130ドメイン外ホストK0UAZ Win7（ドメインコントロールにアクセス可能）192.168.52.162 KDCと呼ばれるキーディストリビューションセンターは、ASおよびTGSAuthentication Service Authentication Servicesを含むデフォルトでドメインコントロールにインストールされます。ASと呼ばれる、KDC認証チケット付与サービスチケット助成サービスに使用されます。TGSと呼ばれます。クライアントクライアントはユーザーを参照します。サーバー側は、コンピューターアカウントまたはサービスです。

プロセスと原則

上記の図には、クライアントとKDCの時点で、クライアントとKDCのTG、クライアントとサーバーの3つのリクエスト返品プロセスが含まれます。詳細なリクエスト応答は次のとおりです

AS-REQ：クライアントはKDC（AS）への認証要求を開始します。要求された資格情報は、クライアントのNTLMハッシュによって暗号化されたタイムスタンプと、その他のID情報です。 AS-REP：AS ASは、復号化にクライアントNTLMハッシュを使用します。検証が正しい場合は、KRBTGTハッシュで暗号化されたTGTチケットを返します（これはTGS-REQのTGSに送信され、STと交換に使用されます）。 TGTにはPACTGS-REQが含まれています：クライアントはTGTキャッシュをローカルで取得し（復号化できません）、STチケットをTGSと交換するために、対応するサービスTGS-REPにアクセスできます。結果が正しい場合は、サービスを提供するサーバーのサーバーハッシュ（マシンユーザーハッシュ）によって暗号化されたST（サーバー）を返します。チケット）AP_REQ：クライアントは、取得したSTをサーバーに持ち込み、リソースAP_REPを要求します：サーバーは独自のハッシュを使用してSTを復号化します。復号化が正しい場合は、取得したPACを使用してKDCにアクセスして、クライアントがアクセス許可を持っているかどうかを判断します。 PACを復号化した後、KDCはユーザーSIDとグループの情報を取得し、Access Control Table（ACL）に基づいて裁判官の許可が取得されます。それが満たされている場合、サーバーはリソースをクライアント

Kerberos関連のセキュリティ問題

に返します

キー（ハッシュ）

ハッシュ

パスハッシュは、NTLM認証とKerberos認証にも適しています。ドメインの外側だけでなく、ドメイン内でも使用できます。 Kerberos Authenticationでは、AS-Reqがクライアントハッシュ暗号化関連情報を介して送信されます。したがって、クライアントのNTLMハッシュを取得すると、ハッシュを通過すると他のホストへのアクセス許可を水平に取得できます。

使用

ここでは、ドメインパイプNTLMハッシュが取得され、特定のドメインマシンにログインされると仮定します。

PTHの次のツール

Mimikatzを使用して、資格情報をLSASSに注入するために必要であるため、Sedebugを有効にするにはローカル管理者の権利（bypassuac）が必要です。インジェクション後、このユーザー資格情報を使用して、WMICEXEC（PYまたはEXEの両方）からPTHを使用してドメイン内のホストにアクセスできます。管理者の権利は必要ありません。 CMEを使用してPTHなどをバッチバッチするコマンドの直接リモート実行に適しています。ここでは、Mimikatzは例として使用されます。ハックユーザー（STU1のローカル管理者グループのメンバー、ドメインユーザー）

ドメインコントロール共有ディレクトリにアクセスする許可なし

資格情報を注入した後のMimikatz Mimikatz 'Privilege:3:Debug' 'sekurlsa:pth /user:a /domain:god.org /rc43:b44444189f93621A

キーを渡します

ミミカッツ情報のヒント

NTLMハッシュは、XP/2003/VISTA/2008および2008R2/8/2012 KB2871997（AESが利用できないか交換可能）で必須です。 AESキーは、8.1/2012R2または7/2008R2/8/2012でKB2871997でのみ置き換えることができます。この場合、NTLMハッシュを避けることができます。

キーはドメインでのみ使用できます。 AES暗号化をサポートするバージョンには、KB2871997パッチがインストールされたWin8.1/2012R2またはWin7/2008r2/8/2012が含まれます

使用

AESキーを取得します

次に、sekurlsa:3360pthモジュールmimikatz 'privilege:3360debug' 'sekurlsa:pth /user:administrator /domain:god.orgを使用します/AES256:BF723755BC5F72A377BDA41CA58FD925DF7EE45DF9A026AC5CD3201020202E33 '

Win7ホストにパッチが適用されないため、パスは自然に失敗します。実用的な環境では、PTHがRC4暗号化をサポートしていない場合、保護されたユーザーグループにある可能性があります。この時点で、AES128およびAES256暗号化をPTKに試すことができます

リモートデスクトップ（制限付き管理モード）でハッシュを渡します

2014年、MicrosoftはKB2871997パッチをリリースしました。これは、主にWindows 8.1およびWindows Server 2012 R2の強化されたセキュリティ保護メカニズムをカバーしています。したがって、Windows 7、Windows 8、Windows Server 2008R2、Windows Server 2012などの過去には、このパッチを更新して、上記のセキュリティ保護メカニズムを取得することもできます。

——3——3————335433333333333————————3354 ——3——3————335433333333333————————3354

制限付き管理者RDPモードリモートデスクトップクライアントサポート：

この更新の前に、RDPログインは、ユーザーがユーザー名とパスワードを提供した後にのみアクセス可能なインタラクティブログインでした。この方法でRDPホストにログインすると、ユーザーの資格情報がRDPホストのメモリに配置され、ホストが脅かされている場合、盗まれる可能性があります。このアップデートにより、RDPはネットワークログインをサポートできます。ここでは、ユーザーの既存のログイントークンの認証をRDPアクセスのために渡すことができます。このログインタイプを使用して、ユーザーの資格情報がRDPサーバーに保存されていないことを確認します。したがって、資格情報を保護します

上記の説明を通して、このモードはRDPを使用してログインしたユーザーの資格情報を保護することであることを理解できます。ネットワーク検証のログイン方法により、RDPサーバーはユーザーの資格情報を保存しません。

使用

Win8.1およびWin2012R2以上の制限された管理モードモードをサポートすると、Win8.1およびWin2012R2がデフォルトで有効になっています。

条件：クライアントは制限付き管理モードモードをサポートし、サーバーは制限付き管理モードモードを有効にします

Win2012R2が手元にないため、ここでは2つのWindows10がリモートデスクトップでハッシュを渡すために使用されます

最初にNTLMハッシュを取得します

Mimikatzを使用してNTLM Hash（Privilege:3:Debugを最初に挿入してデバッグ許可を有効にします。Sekurlsa3:3:pth /usekurlsa3:3:pth /user:administrator /domain:192.168.226.137 /NTLM:9C3767903480E04C089090D27123EAF9 '/RUN:MSTSC.EXE /RECTINTEDADMIN'

/ドメインコンピューター名またはIPを指定します

ここでは、常に資格情報を必要とすることを選択しないでください

制限付き管理モード

レジストリを介して開きます（0がオン、1はオフ、完全な管理者の特権が必要です）、そしてRDP接続が再度実行されます 'hklm \ system \ currentControlset \ control \ lsa' /v無効化

リモートホストで制限付き管理モードが有効になった後、RDP接続はに成功しました

ハッシュがメモリに注入されているのを見ることができます

次に、管理者アカウントK0UAZを使用したため、リモートデスクトップを使用してハッシュをパスするには、ターゲットのローカル管理者許可のみが必要です。

ただし、リモートデスクトップユーザーに参加するだけで、Administratrosグループに参加していない場合、このメカニズムは制限された管理者向けであるため、成功しません。

as-repロースト

原理

AS_REPで、KDCはユーザーNTLMハッシュによって暗号化されたセッションキーを返します（セッションキーは、クライアントとTGS間の通信のセキュリティを確保するために使用されます））

RC4_HMAC暗号化モードでは、同じ暗号化プロセスを使用してプレーンテキストパスワードを暗号化し、暗号化の結果を比較して、ciphertextが同じかどうかを評価してブラスト結果を決定できます。

上記の図に返されたユーザーによって暗号化されたユーザーNTLMハッシュのセッションキー暗号文は、AES256を介して暗号化されていますが、ここで暗号化ダウングレード方法を使用することもできます（以下のKerberoastは、AES暗号化とRC4_HMACタイプのデータを返すためにAES暗号化とRC4_HMACタイプのデータを返します。 as_repでciphertextの暗号化方法がRC4_HMACであるように、プレーンテキストパスワードをクラックできるようにします。

ただし、ここで解決する必要がある問題の1つは、認証前の問題です。 AS_REQでは、クライアントハッシュ暗号化を備えたタイムスタンプが生成され、KDCに送信されます。 KDCは、暗号文を復号化することによりタイムスタンプを取得します。復号化が成功し、タイムスタンプが5分以内にある場合、事前認証は成功します。 KDCは、この方法を使用して、ブルートフォースの亀裂を効果的に防ぐために、クライアントのアイデンティティを検証します。

AS_REQがデフォルトで2回送信される理由については、Harmj0yの記事から得られた説明は、クライアントが事前にサポートされている暗号化方法を知らないということです（クライアントは、事前認証のタイムスタンプの暗号化方法を知らないことに固有のものだと思います）。

したがって、事前認証をオフにすることで、徹底的な爆破を実行して、プレーンパスワードをクラックすることができます

事前認証を終了した後、2番目のAS_REQはありません。唯一のAS_REQには、NTLMハッシュ暗号化タイムスタンプCiphertext 3が含まれません。

使用

LDAPを介してKerberos Prauthentication属性を必要としないドメインユーザーをクエリすることができます

特定のクエリ条件は、useraccountcontrol:1.2.840.113556.1.4.803:=4194304です

ここでルベウスはサンプルrubeus.exe asreproast /nowrap /format:hashcat として使用されます

Hashcat Decrypt Hashcat -M 18200 Hash.txt Passwords.Dict - Force

Rubeus AsReproast原理分析

トラフィックのワイアシャーク分析を通じて、このモジュールの原則は、LADPを介して属性機能のドメインユーザーを照会し、バッチでAS_REQリクエストパケットを送信し、ハッシュカットブラストに適したフォーマットと出力のためのリターンパケットのNTLMハッシュ暗号化部分を抽出することであることがわかります。

LDAPクエリ

サポートされている暗号化タイプはRC4_HMAC のみであることを指定します

返された暗号文は、RC4_HMACを使用して暗号化されています（したがって、徹底的に爆破できます）

ゴールドノート

機能

DCと通信する必要があります（ASと対話する必要はありませんが、TGSする必要はありませんが、TGSする必要はありません）。暗号化してTGTを生成します。 KRBTGTのNTLM-HASH値を取得した場合、TGTを偽造できますか？ KRBTGTはドメインコントローラーでのみ利用可能であるため、ゴールドの資格情報を使用すると、以前にドメインコントローラーでアクセス許可を取得したことがあり、金の資格情報はバックドアとして理解できます。

原理

1。ドメイン名

2。ドメインのSID値

3.ドメインのKRBTGTアカウントパスワードハッシュ

4.偽装されたユーザー名は任意の場合があります（TGTのサービス寿命は20分以内であり、ドメインコントローラーKDCサービスはTGTのユーザーアカウントを確認しません）

Krbtgtのハッシュを取得したら、それを使用してゴールドノートを作成できます

DCSYNCの攻撃方法（以下で説明および練習）を通じてKRBTGTのハッシュを取得したとします

条件1：SPNをスキャンしてドメイン名God.org を取得する

条件2：whoami /すべてドメインユーザーSIDを取得し、ドメインSID の最後の文字列を削除します

条件3：KRBTGTアカウントHASH58E91A5AC358D86513AB24312314061

条件4：Forgeユーザー名管理者

条件

MIMIKATZ KERBEROS:3:GOLDEN FORGED TGTを使用します

ゴールデンチケットデフォルトグループ：

ドメインユーザーSID：S-1-5-21ドメイン-513

ドメイン管理SID：S-1-5-21ドメイン-512

アーキテクチャ管理者SID：S-1-5-21ドメイン-518

エンタープライズ管理者SID：S-1-5-21ドメイン-519（フォレッドルートドメインに鍛造チケットが作成された場合にのみ有効ですが、ADフォレスト管理者の許可に使用/SIDSパラメーターを追加）

グループポリシー作成者の所有者SID：S-1-5-21ドメイン-520

mimikatz.exe 'kerberos:3360golden /domain:god.org /sid3:s-1-5-21-2952760202-1353902439-2381784089 /usersistrator /KRBTGT:58E91A5AC358D86513AB24312314061 /TICKET:K0U.KIRIBI '出口

TIP:は、請求書の有効期間と更新請求書の最大妥当性期間を変更するために、追加/endin:xx /rengingmax:xxを追加できます。 Mimikatzはデフォルトで10年です

生成されたチケットは、他のドメインマシンにインポートできます。または、TGTを /PTTを使用してメモリに直接注入できます。

最初にチケットキャッシュKlist Purge をクリアします

次に、mimikatzkerberos:ptt k0u.kiribi 経由でキャッシュされた請求書に注入します

KLISTはチケットキャッシュをチェックし、偽造されたTGTを見ることができます