攻擊者拿到一台 Linux 主機後，第一步到底看什麼？

我還記得自己在 HTB 練習第一個 CTF 題目的樣子。那時候，我成功建立了 Reverse Shell，內心非常開心，想著自己很快就能取得 root 身分、拿到 Flag，漂亮地結束這回合。

想到這裡，信心突然膨脹，開始執行一堆指令，嘗試提權。然後……就沒有然後了，當時的表情如下圖。（眼神充滿睿智）

最後，我還是摸摸鼻子回去看解說，才把題目解開。這次經驗讓我開始意識到：取得 Shell 之後，我需要先了解目前的處境，才能判斷下一步該做什麼。

而『先了解處境、再決定下一步』這件事,就是今天要談的主機枚舉(Enumeration)：有目的地蒐集與比對資訊，逐步建立對環境的理解，再決定哪些地方值得深入調查。

資訊蒐集第一步：用 whoami 看看我是誰

拿到 Shell 後，可以先用一個簡單的指令確認目前身分：

whoami

whoami 會顯示目前有效使用者 ID（EUID）所對應的使用者名稱。EUID 是程序執行時，參與權限判斷的身分之一。

參考：whoami 的 Linux manual page。

不過，為什麼拿到 Shell 後，還需要確認自己是誰？

因為透過服務取得命令執行能力時，我們不一定有經過「自己選帳號、輸入密碼登入」的過程。在一般情況下，如果服務啟動 Shell，而且沒有額外切換權限，Shell 會繼承啟動它的程序身分。

因此，取得什麼身分，與被利用的服務如何運行有關。參考：Linux 程序建立機制 fork(2)。

對剛開始練習的我而言，這有點像開盲盒：不知道結果會是服務帳號、一般使用者，還是 root。但這個結果背後其實有原因，值得接著追查。

假設執行結果是：

www-data

目前可以確認的，是有效使用者名稱為 www-data。至於這個身分能讀取哪些設定檔、修改哪些目錄，還需要進一步確認。

我可以接著查看：

id

它會顯示目前程序的使用者與群組資訊，幫助我們補上 UID、GID 與群組等線索。
參考：id 的 Linux manual page。

接下來要問的是：

• 目前身分屬於哪些群組？
• 相關的應用設定檔是否可讀？
• 哪些檔案或目錄可以修改？
• 這些存取能力是否符合這個帳號原本的用途？

到這裡，我們才開始從「知道帳號名稱」，往「了解實際能力」前進。

如果結果剛好是 root，當然會很開心。但先別急著宣布破關，還有下一個問題：這個 root 身處哪個環境？

資訊蒐集第二步：確認自己在哪個環境

討論伺服器時，我們常會接觸實體主機、虛擬機與容器這三種環境。

不過，它們可以同時出現在一套架構裡。例如，實體主機上運行虛擬機，虛擬機裡再運行容器。因此，辨識環境時，也需要考慮彼此的層次關係。

為什麼這件事會影響滲透測試？

因為我們需要確認：目前看到的檔案、程序與網路，屬於哪個範圍？目前取得的權限，又能影響哪些資源？

例如，容器內顯示 root，不能單憑這個結果就認定已經控制宿主機。Linux 的 user namespace 可以讓同一個程序在內外具有不同的使用者 ID；而實際部署是否使用這項機制，也需要另外確認。

參考：Linux user_namespaces(7)。

同樣地，取得虛擬機內的管理權限，也不能直接當成取得底層虛擬化平台的管理權限。

所以，第一步是確認「我是誰」，第二步則是確認「這個身分的權限適用於哪個範圍」。

基本的身分與資源枚舉思路可以沿用，但不同環境會影響後續要驗證的安全邊界。容器相關的細節，會在後面的主題繼續研究。

資訊蒐集第三步：這台系統是什麼，又負責什麼工作？

確認身分與環境後，我會接著把問題分成兩部分：系統背景，以及主機用途。

系統背景：版本資訊能幫助我判斷什麼？

Linux 有許多發行版，例如 Red Hat Enterprise Linux、Ubuntu、Rocky Linux 與 Arch Linux。

發行版、正在運行的 Kernel，以及應用套件的版本，都是值得記錄的資訊。它們可以幫助我們了解環境，也能作為查閱安全公告的起點。

但看到版本比較舊，還不能直接認定存在可利用漏洞。

發行商可能將安全修補回補到既有版本，因此還需要比對發行商公告、套件修訂版本，以及漏洞所需的配置條件。參考：Red Hat 的安全修補回補說明。

例如，2026 年公開的 Dirty Frag 可以作為 Kernel 漏洞研究的案例；但是否影響眼前的系統，仍要根據適用條件與修補狀態判斷。參考：Red Hat Dirty Frag 安全公告。

版本資訊在這裡的用途，是幫助我們找出「需要查證的方向」。

主機用途：哪些資源值得優先調查？

除了版本，我也需要理解這台系統負責什麼工作。

它是 Web Server、應用伺服器，還是執行備份工作的主機？可以從正在運行的服務、應用目錄、設定檔與排程等資訊交叉判斷。

了解用途，可以幫助我們決定先看哪些資源。例如，面對 Web 應用環境時，可以優先確認目前身分能否讀取相關設定，以及設定中出現哪些服務依賴。

假設在一份可讀的應用設定中，看到了資料庫連線位址。

這時候，我會把判斷分成三層：

• 觀察： 設定檔中記錄了一個資料庫位址。
• 假設： 這個應用可能需要連接該資料庫。
• 驗證： 設定是否仍在使用？目前環境能否連線？存取服務需要哪些驗證與授權？

知道資料庫位址，不代表已經能登入資料庫。設定可能過期，網路可能受到限制，服務也可能要求有效憑證。

不過，這項資訊已經提供了下一個可以調查的方向。

在授權測試範圍內，已取得存取權的主機，可能讓我們接觸原本無法直接從外部連線的服務。能否進一步存取，仍取決於路由、防火牆、服務設定與授權條件。

把找到的資訊，變成下一個問題

整理到這裡，我想練習的是：每次看到一個結果，都能說明它代表什麼，以及還有哪些事情不知道。

再用一個假設情境來看：

我發現目前帳號可以修改一個備份腳本。

這是一項值得注意的發現，但還不能直接寫成「找到提權漏洞」。

我還需要確認：

• 這個腳本是否真的有人使用？
• 是手動執行，還是由排程呼叫？
• 執行它的是目前帳號，還是其他更高權限的身分？

如果它只是沒有人使用的舊檔案，就還沒有證據支持這條提權路徑；如果有高權限工作直接執行它，才值得進一步分析影響。

回頭看最初的 HTB 經驗，我當時急著嘗試提權，卻沒有先替自己建立一張環境地圖。

這次我希望練習的是，在每個動作之前，都先回答：

我想確認什麼？目前的證據支持什麼？下一步要怎麼驗證？