在開始打靶機之前，我想先搞清楚一件事情：

滲透測試從頭到尾到底在做什麼？

所以今天主要讀了 HTB Academy 的 Penetration Testing Process 模組。

在還沒看Penetration Testing Process模組前，我對滲透測試的想像是：

掃描 → 找漏洞 → 取得初始權限 → 提權 → 拿到 Root → 結束

一路往前衝，拿到 Root 就成功了!!!

但讀完這個模組之後，才發現根本沒有這麼簡單 😂

開始滲透測試前，先搞清楚一些事

讀這個模組之前，我覺得滲透測試大概就是：

找到可以利用的地方 → 想辦法打進去 → 拿到權限。

但現在才發現，真正開始測試之前，還有一件很重要的事情：

這次測試到底是為了什麼？

不同的測試目的，最後要做到的程度可能完全不一樣。

例如在前置討論時，就需要先確認：

• 這次測試想驗證什麼？
• 測試範圍到哪裡？
• 哪些系統可以測？
• 哪些行為不能做？
• 什麼情況算是達成目標？

所以不一定每次都是：

「一定要拿到 Root 才算成功。」

有些測試可能是想確認某個弱點能不能被利用，有些可能是想確認攻擊者可以取得什麼資料，還有些可能是要驗證一整條攻擊路徑。

所以滲透測試並不是：

**「想辦法存取系統。」**就算成功

而是要先知道：

「這次滲透測試的目的是什麼？」

再根據目的決定測試方式。

以前我會覺得這種比較非技術的部分，應該沒有那麼重要><

畢竟我以前想到滲透測試，頭腦浮現的就是：

掃描、找漏洞、Exploit、提權

但讀完這個模組後才發現，原來在開始測試之前，有很多事情都必須要先確認清楚~

如果一開始連測試目的、Scope、Rules of Engagement 都沒有確認清楚，後面就算技術做得再好，也可能測錯方向，甚至一不小心做了不應該做的事~

所以現在回頭看，我覺得：

非技術的部分，不代表不重要。

先把：

「為什麼測、要測什麼、可以做到哪裡」

講清楚，後面測試過程中才可減少不必要的爭議。

滲透測試的八個階段

HTB Academy 的這個模組，把滲透測試流程分成八個階段：

我一開始看到八個階段馬上OS：「蛤？太多了吧???」

但拆開來看之後，就比較能理解每一個階段在做什麼。

這八個階段比較像是一個完整的滲透測試框架，不代表每次測試都一定會用完全一樣的方式跑完~

實際測試的時候，還是會根據測試目的、Scope、取得的資訊，決定下一步!

1. Pre-Engagement

這個階段是在正式開始測試之前，先把整件事情定義清楚。

例如：

• 測試目的
• Scope
• 測試時間
• 測試範圍
• Rules of Engagement
• 聯絡窗口
• 授權與相關規則

簡單來說就是：

先確認這次到底要怎麼測。

這也是我今天覺得最容易被忽略，但其實很重要的一個階段。

因為如果連 Scope 都不知道，怎麼知道後面掃描到一台主機，到底能不能碰？

如果連測試目的都不知道，那拿到 Root 到底算不算成功？

這些都應該在測試前先講清楚。

2. Information Gathering

接下來才開始收集資訊。

在還沒讀這個模組之前，我對 Information Gathering 的想像其實滿簡單的。

就是：

「先掃 IP、Port、服務，然後把結果記下來。」

但讀完之後，我發現好像不是這麼單純。

實際上可能會去了解：

• 網域
• IP
• 主機
• 開放的 Port
• 執行中的服務
• 服務版本
• 網頁與使用中的技術
• 網路架構......等

但我覺得真正重要的不是：

「我掃了多少東西？」

而是：

「這些資訊對我接下來的判斷有什麼幫助？」

例如看到一個開放的 Port，我不應該只是把它記下來就結束。

而是可以繼續問：

「這是什麼服務？」

「是什麼版本？」

「這個資訊會不會影響我下一步的判斷？」

所以我現在會把 Information Gathering 理解成：

慢慢把目標環境的樣子拼出來。

而且這個階段也不是做完一次就結束。

後面如果發現新的資訊，可能又會產生新的問題，這時候就需要回來繼續收集。

3. Vulnerability Assessment

有了前面的資訊之後，接下來就不能只是繼續收集。

而是要開始思考：

「我看到的這些東西，代表什麼？」

這就是我目前對 Vulnerability Assessment 的理解。

例如在前面的資訊裡，可能發現：

• 某個服務版本比較舊
• 某個 Web 功能的行為很奇怪
• 某個服務設定看起來不太安全
• 某個功能可能暴露敏感資訊

這些都可以成為進一步分析的線索。

但不能看到：

「這個版本很舊。」

就直接認定：

「這一定有漏洞。」

還是需要繼續確認：

• 這個版本有沒有已知問題？
• 這個問題需要什麼條件？目前環境有這樣的條件嗎？
• 看到這個狀況，真的代表存在漏洞嗎？如果存在，可能造成什麼影響？

這裡也可以使用自動化工具，協助快速找出已知漏洞或可能有問題的設定。

但我覺得工具比較像是幫忙找線索。

還是要自己去：

理解這些結果到底代表什麼。

所以我目前會把這個階段理解成：

看到線索 → 思考可能性 → 找更多資訊 → 驗證

有時候單獨看一個資訊，好像沒有什麼><

但把前面收集到的幾個資訊放在一起，可能就會出現新的方向。

這也是我讀到 thinking outside the box 時比較有感覺的地方。

不是所有問題都會直接告訴你：

「我是漏洞。」

有時候反而是自己把不同資訊串起來之後，才發現：

「欸？這幾個東西放在一起，好像有點不對。」

而如果分析到一半發現：

「好像還缺一些資訊。」

那也不代表要硬猜。

而是回到 Information Gathering，繼續找需要的資訊。

到這裡我才比較開始理解：

滲透測試不是把每個階段做完一次就結束，而是會一直根據新的資訊重新判斷。

4. Exploitation

找到可能的攻擊向量後，就可以進一步嘗試利用。

也就是：

想辦法驗證這個弱點到底能不能被利用!

可能會使用：

• 手動測試
• 特定工具
• Payload
• 認證繞過...等

看過 Academy 後，我發現自己的思路好像有進化了xddd

不是看到漏洞就：

「好！打！」

而是要先想：

為什麼我要測這個？

前面到底發現了什麼？

為什麼我認為這裡可能有問題？

我要怎麼驗證？

這也是我接下來打靶機時，想慢慢練起來的思考方式。

5. Post-Exploitation

成功取得系統存取權限，並不代表：

「拿到 Shell，結束！」

接下來還可以繼續了解目前取得的權限，以及這台主機裡還有哪些資訊。

例如：

• 使用者
• 系統資訊
• 權限
• 設定
• 憑證
• 敏感資訊...等

也可能進一步嘗試：

Privilege Escalation

也就是從目前的權限，嘗試取得更高權限。但提權只是 Post-Exploitation 中可能進行的其中一部分，實際上還是要看這次測試的目標。

我以前很容易把：

Initial Access → Root

想成一條直線。

但實際上，拿到權限之後，還是要先盤點目前掌握的資訊，看看有沒有達到這次的測試目標，決定下一步要做什麼。

6. Lateral Movement

如果測試範圍包含內部網路，就可能會進一步思考：

現在這台主機被拿下來了，還能不能往其他主機移動？

這就是 Lateral Movement。

例如：

主機 A 被入侵 → 找到內部資訊 → 發現主機 B → 嘗試往主機 B 移動

這時候原本拿到的資訊，可能變成下一步的重要線索。

所以我開始發現：

前面的結果，可能會影響後面的方向。

這也讓我更能理解為什麼滲透測試不是只有一種路徑。

7. Proof-of-Concept

這個階段我一開始比較容易把它跟「找到漏洞」混在一起。

但讀完Academy後，我比較能理解它是在把前面做過的事情整理成：

別人看得懂，而且可以重現的證據。

例如：

• 做了什麼
• 為什麼這樣做
• 使用了什麼方式
• 成功的結果
• 截圖
• Command

這也讓我開始理解：

筆記真的不能最後才整理~

在測試的過程中，就要隨時記錄：

自己走了哪條路、做了什麼、得到了什麼結果!

8. Post-Engagement

最後就是把整個測試結果整理、報告並與相關人員討論。

包含：

• 測試結果
• 發現的漏洞
• 證據
• 攻擊路徑
• 影響
• 修補建議
• 報告說明

也就是：

前面做的事情，最後要變成別人看得懂、可以拿去改善環境的東西。

所以我現在比較能理解：

滲透測試不是「打完就結束」。

最後還是要回到：

「這次測試原本想驗證什麼？」

然後確認：

「我們有沒有回答到這個問題？」

今天最有感，也覺得很重要的一件事

今天最有感、也覺得很重要的一個觀念：

滲透測試不是一條固定的直線。

以前我的想像可能是：

Recon → Vulnerability → Exploit → PrivEsc → Root

但實際上比較像：

做一件事情 → 得到新資訊 → 重新判斷 → 決定下一步

例如：

我在 Information Gathering 發現新的服務。

↓

開始思考這個服務可能代表什麼。

↓

做 Vulnerability Assessment。

↓

發現新的線索。

↓

回去做更多 Information Gathering。

↓

再重新判斷下一步。

甚至拿到權限之後，也可能因為發現新的資訊，而重新回頭看之前的結果。

所以：

回頭不是退步。

而是因為你拿到了新的資訊，所以現在可以做出更好的判斷。

這個觀念我覺得對我之後打 HTB 靶機滿重要的。

除了理解流程之外，今天還有一個重要任務：準備好打靶機要用的筆記工具!

我選擇使用 SysReptor。

主要是因為它有 HTB CPTS 的報告模板，讓我可以直接拿來用（懶人最大福音！

我可以在打靶的過程中，直接使用 Notes 邊做邊記錄：

• 下過哪些 Command
• 發現了什麼資訊
• 哪些地方值得注意
• 自己做了什麼假設
• 驗證結果是什麼
• 下一步想做什麼

等到整台靶機打完之後，再把真正重要的內容整理到 CPTS 報告模板裡。

也就是：

打靶機時用 Notes 快速記錄 → 使用 CPTS Template 整理重要發現並完成正式報告必要欄位 → 匯出符合考試要求的報告格式

簡直是金魚腦友善😂

而且因為我這 30 天的目標本來就是朝 CPTS 前進，所以我也希望從一開始就習慣：

不是只想著「怎麼把靶機打掉」，而是同時思考「如果今天是在考 CPTS，我要怎麼把這些過程整理成最後要交的報告」。

這也是我選擇在 Day 2 就先把 SysReptor 準備好的原因。

今天最大的收穫：原來滲透測試不是「會打」就好

以前聽同事說過，某些廠商做 DoS 的方式「很像新手」。

那時候其實沒有什麼感覺><心理OS：有找到問題、也有成功做出攻擊，不就代表測試有做到嗎？

但讀完這個模組之後，我開始比較能理解這句話背後的意思。

因為滲透測試其中一個重要目的，就是確認目標的弱點，以及這些弱點是否能被利用。

所以如果今天的目標是：

「這個服務到底有沒有弱點？」

那就應該選擇可以驗證這件事情的方法。

如果只是直接用 DoS 把服務打到不能用，最後可能只知道：

服務被打掛了。

但這不代表真的知道服務的弱點在哪裡，也沒有真正回答原本想驗證的問題。

所以我現在比較能理解，為什麼同事會說某些廠商做 DoS 的方式「很像新手」。

重點不是 DoS 不能做，而是：

測試的方法，應該要跟你想達成的目標有關。

真正重要的是：

我的目標是什麼？

我要怎麼達成這個目標？

我要怎麼確認自己真的達成了？

這也讓我開始重新想以前自己對「會用工具」的理解。

以前我比較在意的是：

「我會不會這個工具？」

但現在開始覺得，更重要的是：

「我為什麼要在這個時間用這個工具？」

甚至再往前一步：

「我現在到底想達成什麼？」

因為工具其實只是手段。

會用工具，只是知道「怎麼做」。

但知道自己的目標、知道為什麼選這個方法，以及怎麼確認結果，才開始比較接近真正的滲透測試思維。

所以滲透測試其實不是：

找到一個東西 → 打下去 → 成功 → 結束。

而比較像是：

確認目標 → 理解環境 → 建立假設 → 選擇方法 → 驗證 → 根據結果重新判斷 → 確認是否達成目標。

而且在這個過程中，如果得到新的資訊，也可能要重新回頭看前面的判斷。

所以我現在開始覺得，真正重要的不是：

「我會多少工具？」

而是：

「我知不知道自己現在要做什麼，以及為什麼要這樣做？」

這也是我覺得今天最大的收穫跟希望這 30 天可以慢慢練起來的東西。

不是只把靶機打完，而是開始知道：

「我為什麼這樣打。」

當然，如果測試目標本身就是驗證服務的可用性或 DoS 風險，那 DoS 就可能是合理的測試方法。

明天開始

明天開始要來實戰第一台靶機： Lame

終於要開始動手了~~~😂

前面花了兩天先把滲透測試的流程、思考方式跟筆記工具準備好，明天就要真的拿一台靶機來試試看了！

有點期待，也有點怕自己打開靶機後完全不知道要幹嘛🤣

希望今天的滲透測試重要思維takeout

「我為什麼要做這一步？」

「我要驗證什麼？」

「下一步要怎麼判斷？」

遇到靶機我可以真的落實！

明天見！