今天是Lame靶機系列的最後一天～開始寫報告囉！！！

撰寫報告佔一天是因為report是CPTS很看重的！

一開始我以為今天會比較輕鬆——雖然Day 1就有提到CPTS的報告要全英文撰寫且是很專業等級的（包括要寫到修補建議等）

但前幾天把 Lame 從了解服務、驗證是否存在可利用的版本漏洞，到真正利用漏洞取得 root 權限，都撐過來了...今天只是「把過程寫下來」而已，應該沒有問題吧（？）

打開 SysReptor，看著模版，心理OS 這些是什麼！！！怎麼跟我想像的完全不一樣QQ

裡面一堆 TODO……

Day1 有提到CPTS的報告不是把前幾天做的finding做整理、整理成一份報告就好。會要求我們站在「客戶」的角度，說清楚這些發現對他們有什麼意義、多嚴重、怎麼修。

雖然已有心理準備...但真正看到SysReptor的CPTS Template還是覺得不知如何下手

只能先看每個欄位，對應academy的思路，想可能報告希望我們填寫的內容跟填寫時需要注意的～一步步慢慢完成><

那～～～我們就先來好好研究CPTS模板，理解我們需要填寫的內容，再開始動手吧

先釐清一個讓我想很久的事：Academy教的跟SysReptor長得不一樣

在真正開始填之前，我想先說一個讓我困惑了一段時間的事。

Academy的Documentation & Reporting模組說報告要包含這些東西：Executive Summary、Attack Chain、Findings、Remediation、Appendix。

但打開SysReptor，我找不到任何一個叫「Attack Chain」的段落。左邊的Sections翻來翻去，就是沒有這個名字。

我當下的反應是——是我漏看了什麼嗎？還是SysReptor少了一個段落？

後來一個一個去對照，才發現它們其實是在處理很接近的概念。
Academy講的 Attack Chain，在這份 SysReptor Template 裡，可以透過 Internal Network Compromise Walkthrough 這個區塊來呈現!!!

兩個都是在說「從初始立足點一步一步到拿到最終權限的完整路徑」，只是SysReptor用了不同的描述方式~~

搞清楚這件事之後我才想起來，Academy在模組裡其實有提到：報告沒有唯一的標準格式。 它會依個人習慣、公司規範、客戶要求而改變——有些客戶只要一頁摘要就好，有些需要非常細的技術報告，有些公司有自己的模板。

Academy教的是「報告應該涵蓋哪些思路跟內容」~~~
So，看到名字不一樣不代表哪邊錯了，而是不同 Template 可能會用不同的方式來呈現這些內容><

另外補充一點：SysReptor是HTB在CPTS考試官方頁面上直接推薦的報告工具，還提供了專屬的CPTS模板讓考生使用。所以用這個工具練習，不會讓跟考試脫鉤(放心惹><

填寫介面的名稱跟PDF報告的段落名稱不一樣

這個又困擾我了QQQ

SysReptor左邊的填寫欄位名稱，跟匯出來的PDF報告段落名稱不是一對一的。

像是：填寫時叫「Document Control」，但匯出的報告裡顯示的是「Engagement Contacts」。一開始以為自己填錯地方了，後來才發現SysReptor會自動把你填的資料整理到報告對應的位置。

還有一個更嚇人(?)的地方：報告裡的「Assessor Contact」（測試者資訊）欄，在填寫介面根本找不到對應欄位，也沒有要我們手動填!!!

開始OS我要不要換筆記軟體 這筆記軟體真的可靠嗎???

後來試著填~然後匯出後，才發現SysReptor有夠貼心

SysReptor會自動把Meta欄位裡我們填的名字、職稱、Email帶入後面的相應欄位~~~Assessor Contact SysReptor早就幫我們對應填好哩

所以如果發現某個欄位怎麼填都沒出現——先別急著新增。先把報告匯出來看，很可能它已經自動幫我們填好了><(大貼心!)

這篇文章怎麼呈現

因為填寫介面跟最終報告長得不一樣，我會這樣區分：

• 說明怎麼填 → 用填寫介面的欄位名稱解釋
• 展示成果 → 截匯出PDF的對應頁面
  這樣對照著看，比較不會搞混。

那我們就來一起看看Report怎麼寫吧～

首先，我們在Projects，勾選CPTS Exam Report，再按+(Create new)

在Create new Project頁面，我們把欄位填上我們的報告名稱(這裡我以我們的目標靶機Lame當作報告標題)，修改後按Create:

會進入這個畫面，可以開始撰寫Report

Meta 欄位怎麼填

Meta欄位決定報告封面跟頁首會顯示什麼，而且它填的內容會自動帶入報告多個地方——包含測試者資訊、客戶名稱等，不只是封面而已，所以要填正確。

來看看Meta的填寫畫面~~~

💡 真正做滲透測試時，Title欄位通常會寫「Penetration Tester, [我們的公司名稱]」，讓客戶知道是哪家公司的人做的><練習階段填職稱就好~~

填好後~~SysReptor會幫我們自動帶到對應的報告欄位~
看!!!封面的資訊變成我們填的內容哩!!!

另外 匯出報告中的Statement of Confidentiality其實沒有對應的填寫介面><

這段是什麼咧???：告訴收到報告的人這份文件是機密，不能隨意轉發或公開。是滲透測試報告的標準開頭，內容模板SysReptor已經幫我們寫好哩!!!

2. Document Control → Engagement Contacts（聯絡資訊）

填寫介面名稱：Document Control
PDF裡顯示：Engagement Contacts

這是前面說的「名稱不一樣」的例子——填寫介面叫Document Control，但匯出的PDF段落標題是Engagement Contacts><不要被名字搞混了，填在Document Control就對了!

這段是什麼咧???：列出客戶窗口跟這次測試的相關聯絡人，讓報告有明確的負責對象~

要填什麼：

客戶窗口（我們手動填）：

Name:  Sally(Lame Lab Company)
Title: Security engineer
Email: sally@lamelab.com

測試者（Assessor Contact）：

填寫介面裡找不到 Assessor Contact 這個欄位，不用手動填。SysReptor會自動把你在Meta填的名字、職稱、Email帶到報告這個位置。這也是為什麼Meta要填正確的原因之一。

填寫後，可以看到客戶聯絡人跟測試者資訊在報告上都有了

3. Executive Summary（執行摘要）

填寫介面名稱：Executive Summary

這部分要特別注意!!!

因為它不是寫給只懂資安技術的人看的。

如果今天是給非技術背景的主管看，他其實不需要知道我用了 Nmap、Metasploit 還是什麼指令><

他比較需要知道的是：

「我們現在發現了什麼問題？」

「這個問題可能造成什麼影響？」

「哪一個問題需要優先處理？」

所以這裡要把技術語言轉成比較容易理解的「實際影響」。

例如不要只寫：

Attacker obtained root access.

因為對不懂技術的人來說：

所以 root 是什麼？為什麼很嚴重？

其實還是不知道 😂

換成：

An attacker can gain complete control of the server without a username or password.

就比較容易理解這件事情代表什麼。

3.1 Approach（測試方式）

這裡主要是在說明：

我們是怎麼測的、什麼時候測、原本知道多少，以及這次測試的目的。

SysReptor 會依照我們填寫的 Meta 資料自動帶入部分內容，如果有需要再依照實際測試情況進行修改即可~~

不過這裡我沒有完全照著原本的 Template 使用，因為 Template 的情境比較偏向企業環境委外進行滲透測試，跟這次 HTB Lame 靶機的測試情境不太一樣，所以有稍微調整文字，讓內容符合這次實際的測試範圍與方式。

簡單來說，Template 是提供我們一個 Report 的架構，但實際填寫時還是要回頭確認：

「這段描述真的符合我這次的測試嗎？」

而不是照單全收><

3.2 Scope（測試範圍）

這裡就是說：

「這次到底測哪裡？」

這裡我記錄的是成功取得 Root 當天，Lame 實際分配給我的 IP。

因為我前幾天進行 Information Gathering 時，Lame 分配到的 IP 跟這一天不同，所以有時候可以看到前幾天的截圖中，Target IP 會跟這份 Report 裡的 IP 不一樣。

這是因為 HTB Labs 的靶機 IP 可能會隨著重新取得靶機而變動，並不是我測試的 Target 不同 XD

因此這份練習 Report 中，我記錄的是這次實際進行最終 Exploitation 時，Lame 所分配的 Target IP，讓 Report 中的測試環境與最後的 exploitation evidence 能夠對應起來!

3.3 Assessment Overview and Recommendations（總覽與建議）

整體發現了幾個問題、各自多嚴重、最優先做什麼。

我覺得這裡跟前面幾天的思維不太一樣。

前面比較常在想：

「這個漏洞怎麼利用？」

但到了 Report 這裡，問題變成：

「如果這個漏洞真的存在，對客戶代表什麼？」

所以這裡除了整理 Finding 的數量跟嚴重程度，我也會簡單交代這次實際測試的結果。

這次 Lame 一共確認了 2 個 Finding：

• Critical：Samba Username Map Script Remote Code Execution
• Medium：FTP Anonymous Login Enabled

其中真正進入攻擊鏈的是 Samba 的漏洞。

這次我是透過 Metasploit 利用 Samba 漏洞，成功建立 Reverse Shell，最後取得 Root-level access。

簡單來說，這次實際走過的路徑就是：

Samba 漏洞 → Metasploit Exploit → Reverse Shell → Root

而 FTP Anonymous Login 雖然也確認是個問題，但這次沒有被納入最後的攻擊路徑。

所以在這個區塊，我會先讓讀者知道：

「這次實際是怎麼攻進去的，以及最後取得了什麼權限。」

至於每個 Finding 是怎麼確認的、造成什麼影響，以及對應的 Evidence，就會放到後面的 Findings 裡~

4. Network Penetration Test Assessment Summary

填寫介面名稱：Network Penetration Test Assessment Summary

這段在說什麼：
這裡是把整份報告的 Finding 做一個總覽，讓讀者可以快速看到這次測試總共有幾個問題，以及各個 Finding 的嚴重程度。

要填什麼：
這裡的 Summary of Findings 表格會從 Technical Findings 自動抓資料，所以不用再手動輸入 Finding。

不過原本 SysReptor 的文字比較偏向企業網路環境的情境，而這次 Lame 是單一靶機、Workgroup 的測試環境，所以我有稍微調整部分描述，讓內容符合這次實際的測試範圍。

也就是說，Finding 本身填寫完成後，這個 Summary 大部分就會自動生成；需要做的是確認自動產生的內容有沒有符合這次測試情境。

5. Internal Network Compromise Walkthrough

填寫介面名稱：Internal Network Compromise Walkthrough

這段在說什麼：把從「什麼都不知道」到「拿到最高權限」的完整路徑，用說故事的方式串起來。

跟Technical Findings的差別是；Walkthrough 則是把這些發現串起來，呈現實際的攻擊路徑。

這段有三個部分~~~

• Walkthrough Summary — 給高層主管看的，可能不熟技術，所以主要讓他知道「這次是怎麼被攻進去、最後造成什麼結果」。不用放 CVE、工具名稱或指令。

  • 發現 Samba 有問題 → 成功取得整台主機最高權限
    

• High-Level Steps — 技術主管，懂技術但沒時間看細節，要能一眼看出攻擊鏈的大概。每個大動作一行，CVE可以放，工具名不用。
  

• Detailed Steps — 技術工程師，要能照著我們寫的步驟自己重現問題。工具名、設定參數、截圖我全部都要!!!
  

6. Remediation Summary（修補建議彙整）

填寫介面名稱：Remediation Summary

這段在說什麼：
這裡是把這次測試發現的問題，以及可以進一步改善整體安全性的建議，整理成一份比較容易執行的行動清單。

那跟 Technical Findings 裡的 Remediation 有什麼差別？

簡單來說：

• Technical Findings → Remediation：針對「單一漏洞」說明要怎麼修。
• Remediation Summary：把整份測試的修補方向集中整理，讓工程師或負責修補的人不用一個一個翻 Finding，就能快速了解目前應該優先處理哪些事情。

而且這裡不一定只能把每個 Finding 的 Remediation 原封不動搬過來。

像這次 Lame 的報告，我除了整理 Finding 裡面的修補方式，也有補上一些比較偏向整體安全管理與長期改善的建議，例如 Patch Management、定期 Vulnerability Assessment 等。

因為這些不一定是某一個 Finding 本身的直接修補方式，但可以用來降低之後再次出現類似問題的風險。

Template 不一定要全部照抄

這裡也是我這次寫 CPTS Report 後比較有感的一件事。

SysReptor 的 Template 本身是為了通用的滲透測試情境設計，所以不是每一段文字都要直接照原文使用。

實際撰寫時，還是要回頭確認：

「這段描述真的符合我這次的測試情境嗎？」

如果不符合，就依照這次的 Scope、測試方式與實際結果 做適度調整。

例如原本 Template 的開頭寫的是：

strengthen its internal network security

但這次 Lame 是單一靶機，而且沒有進行 Internal Network、Active Directory 或 Lateral Movement 測試。

所以我把它調整成符合這次測試情境的描述：

strengthen the security of the Lame target host and improve its overall security posture

原本：

Remediation efforts are prioritized below starting with those that will likely take the least amount of time and effort to complete.

我這次則依照實際報告中的 Short Term / Medium Term / Long Term 來調整描述，改成依照修補的緊急程度與建議時程來安排。

我覺得這也是寫報告時很重要的一個觀念：

Template 是骨架，不是每一句都一定要照著寫。

回到實際工作

我覺得這裡也滿符合實際工作上的思路。

因為找到問題之後，不是只有：

「有漏洞！」

而是還要繼續想：

「現在先做什麼？之後怎麼改善？怎麼避免類似問題再次發生？」

所以我會把它理解成：

Technical Findings 的 Remediation =「這個漏洞要怎麼修？」
Remediation Summary =「這次測完之後，整體有哪些事情建議優先處理？」

7. Technical Findings（技術發現）

填寫介面名稱：Findings（左邊選單的Findings區域，按+ ADD新增）

這段在說什麼：每個漏洞的根因、影響、嚴重程度、如何修補等資訊

CWE是什麼、怎麼知道：

CWE（Common Weakness Enumeration）是用來描述程式碼或系統架構中弱點類型或根本原因的分類系統。

跟CVE的差別是：CVE是「用來識別這個具體的漏洞」，CWE是「這個漏洞是由什麼類型的弱點造成的」。

寫Impact的技巧：不要說攻擊者做了什麼，要說受害者失去了什麼。「取得root」不夠有說服力，「攻擊者可以讀取、修改或刪除所有資料」才讓人感受到嚴重性。

Finding 1

Title:

Samba Username Map Script Remote Code Execution (CVE-2007-2447)

Severity: Critical

CWE: CWE-78

CVE-2007-2447 的 CVE 官方資料與 NVD 都沒有提供明確的 CWE 對應，因此這裡是根據漏洞的實際成因，將其對應到 CWE-78（OS Command Injection）。

撰寫 Finding 時，如果需要填寫 CWE（Common Weakness Enumeration），可以：

1. 先查 CVE 官方資料、NVD 或其他可信的漏洞研究資料。
2. 如果官方沒有提供 CWE，可以從漏洞的實際成因判斷適合的 CWE 類型。
3. 如果仍然無法確定，也可以留空，並註明官方資料未提供 CWE 對應。

以這次 CVE-2007-2447 為例：

CVE 官方資料與 NVD 都沒有提供 CWE 對應，因此我根據漏洞的成因，將它對應到 CWE-78 - Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')。

Severity: (填完CVSS EDITOR 自動計算)
CVSS（Common Vulnerability Scoring System）是一套用來描述漏洞嚴重程度的標準化評分方式。

CVSS Editor填寫畫面

為什麼我這次用 CVSS 3.1？CVSS 3.1又不是最新的
原因是.......
在實際工作、弱點掃描工具、漏洞管理平台以及許多資安報告中，仍然可以看到 CVSS 3.1 的使用。
所以對我來說，學習 CVSS 3.1 不只是為了這次 CPTS 報告，而是希望之後看到其他漏洞報告時，可以比較容易對照：「這個漏洞為什麼被評成這個分數？」
而不是只看到：Critical 9.8 好可怕! criticalㄟ
真正重要的是理解這個分數是怎麼來的。

那針對這個finding，我們怎麼填???(第一次寫Report~我們先針對必要填寫的Base Score，Temporal Score跟Environmental Score之後再一起研究)

Root Cause:

The root cause is improper handling of user-supplied input by Samba's MS-RPC functionality. When the `username map script` option is enabled, the input is not properly sanitized before being passed to the system shell, allowing shell metacharacters to be interpreted as commands.

Impact:

An unauthenticated remote attacker can execute arbitrary commands as root. 
This allows the attacker to read, modify, or delete all data on the system, 
create backdoor accounts.

Remediation:

- Upgrade Samba to a currently supported version that includes security fixes for CVE-2007-2447.
- If an immediate upgrade is not possible, review the `smb.conf` configuration and disable or remove the `username map script` option if it is not required.
- Restrict access to TCP ports 139 and 445 to trusted and authorized sources.

Finding Evidence:

在匯出的報告~Finding 1的模樣><

Finding 2

Title:

FTP Anonymous Login Enabled

CWE: CWE-287

Severity

Root Cause:

The root cause is that the FTP service is configured to allow anonymous authentication, permitting unauthenticated users to access the service.

Impact:

Anonymous access may allow unauthorized users to access files exposed through the FTP service.
Because FTP transmits authentication and data in cleartext, network traffic may also be exposed to interception.
During this assessment, anonymous access was successfully confirmed; however, no sensitive files were identified in the accessible directory.

Remediation:

Set anonymous_enable=NO in /etc/vsftpd.conf and restart vsftpd.
Replace FTP with SFTP for encrypted file transfer.
If FTP is not needed, disable the service entirely.

Finding Evidence:
FTP anonymous login successful

We can see the directory even though it is empty.

在匯出的報告~Finding 2的模樣><

Appendix（附錄）

填寫介面名稱：Appendix

這段在說什麼：放整個測試過程的原始記錄，補充前面段落沒有放完的細節。

A.2 Host & Service Discovery
我發現了哪些主機？這些主機又開了哪些 Port 和服務？

A.4 Exploited Hosts
我成功在哪台主機上完成 Exploitation？

A.5 Compromised Users
我成功取得或控制了哪些使用者帳號？
這裡要記錄的是實際被取得控制權的帳號，而不是前面 Enumeration 找到的所有使用者名稱。
例如前面透過 enum4linux-ng 找到 35 個使用者，並不代表這 35 個帳號都算 Compromised Users~
要有實際取得帳號控制權的證據，才能放在這裡!!!

A.6 Changes / Cleanup
Changes / Cleanup = 測試過程中，我們對目標環境做了哪些改變，以及測試結束後是否需要清理

💡💡 💡昨天取得 shell 後，我透過 whoami 確認目前權限為 root，因此當時把重點放在確認權限取得與留下 exploitation 證據，沒有另外整理 Flag。
回頭寫 Report 才發現，像 Flag 這類資訊其實也是 Appendix 可以整理的內容。之後練習其他靶機時，我會把這類資訊也一起記錄，讓最後整理報告時比較完整。

報告常用英文詞彙

CPTS Exam 的報告需要以英文撰寫，整理了一份起點詞彙表，之後每寫一份報告就會補充更新～

目前是請AI給我初版，讓自己對這些用語有感覺。寫多了會慢慢換成自己更熟悉的說法。

描述漏洞

描述攻擊

描述影響

描述修補

寫完這份報告的感受

以前我可能會覺得：

「靶機當下先把 Notes 整理好，Report 最後再慢慢寫。」

實際上這次 Lame 我也有整理 SysReptor 的 Notes，像是：

• Nmap 結果
• Enumeration
• 漏洞確認過程
• Exploit 過程
• 截圖

只是當下很多東西比較像是看到什麼就先複製貼上記下來。

所以到了最後真正開始寫正式 Report 的時候，不斷心理OS：

「這個細節 這個Evidence 放在哪裡啊 QQ」

不是沒有記錄，而是有記錄，但沒有按照 Report 的邏輯整理。

整個有點難找 XD

所以從下一台靶機開始，我想試著改成：

只要確認一個 Finding，就先建立到正式 Report 裡。

不用當下全部寫完～先把自己目前知道的東西在正式 Report 記下來。

一邊測 → 一邊確認 → 一邊建立 Finding → 一邊留下對應 Evidence → 最後再整理完整 Report

所以這會是我接下來做每一台靶機時的進化方向!!!

希望下一次彙整 Report 的時候，不要再慌慌張張了 QQ😂

這次 Lame 也讓我深刻體會到：

Report 其實不是測試結束後才開始的事情，而是從發現 Finding 的那一刻，就可以開始一點一點累積。

下一台開始，我要試著讓「測試」跟「寫 Report」同步進行～

發現 Finding → 建立 Finding → 留下 Evidence → 繼續驗證

希望慢慢把這個習慣養起來，之後寫 Report 就不用再跟自己大眼瞪小眼了 QQQ

終於完成我們的第一台目標機——Lame！🎉

我們從：

Port 發現 → 服務與版本確認 → 漏洞驗證 → 漏洞利用 → 撰寫報告

經歷了從機器資訊收集、服務與版本確認、漏洞驗證、漏洞利用，到撰寫報告的一次完整練習！

明天開始迎戰第二台靶機——Bashed 🎉

(我保證！每次發現 Finding，我都會趕快記到正式 Report 的 Finding 裡！！！不然真的太痛苦惹 QQQ）