本文講的是<b>一次伺服器被攻擊的應急行動</b>，
如果你的PHP伺服器被黑客入侵時該怎麼辦?這是我最近處理linux web伺服器發現的一個問題。PHP伺服器被黑時，會出現新的PHP檔案，這與運作在伺服器上的wordpress應用程式和特定的使用者代理沒有任何關系，所有的流量都被重定向到另一個站點。
應急準備
在第一次被攻擊之後，我已經禁用了所有他所檢測到的惡意檔案，并修複了重定向，直到伺服器再次被黑客攻擊。
為此，要将這些應用程式轉移到新的裝置進行分析，我必須在原系統上對下列3個線索進行驗證：
不過要說明的是，我的目的不是要建立一個合法有效的保護機制，而是要确定:
在獲得域名、IP和SSH證書後，我就開始收集被黑的證據了。
收集證據
在連接配接到伺服器之前，我注意到我的IP，以確定以後能夠在日志中把它區分開。
然後通過SFTP連接配接，由于伺服器的磁盤安裝和運作，我無法進行映像。是以我下載下傳了所有我可以得到的日志檔案以及其他感興趣的檔案。我複制了整個/ var/log/目錄，并從虛拟主機根文檔所在的目錄中複制了Apache特定的日志檔案。我複制了被黑的PHP應用程式，以及在事件發生後不久的一些備份。不幸的是，我沒有對管理者所做的更改進行備份，是以一些關鍵的檔案可能已經被修改了。
我啟動了Kali并運作了一個具有portscan端口掃描器程式的Nmap掃描，另外我還安裝WPScan。因為伺服器運作的是一個舊的Wordpress執行個體，而且這個執行個體也執行了重定向，是以Wordpress看起來很可能是攻擊的初始點。然而，自從Wordpress在黑客攻擊後已經更新，WPScan沒有發現任何目前的漏洞。portscan為FTP、SSH、HTTP和HTTPS提供了開放端口，而這在web伺服器上是不可能的。然而，我在wp – content目錄下發現了所有的shell，在某種程度上，這意味着Wordpress應用程式已經被破壞。
我還檢查了VirusTotal，看看網站是否傳播了惡意軟體，但一切似乎都很正常。
于是我決定通過控制台登入系統，但前提是我不知道伺服器上的二進制檔案是否被感染了，是以為了減少驗證的影響，我帶來了我自己的靜态連結二進制檔案。我從busybox下載下傳了二進制coreutil，并将它們上傳到了伺服器上。我還通過SLEUTH Kit上傳了chkrootkit和一個叫做mac-robber 的工具。
我使用靜态二進制檔案來檢查系統，得到一個運作流程清單，cronjob……
為了得到一個監控清單(tcp和udp)程序，我沒有涵蓋portscan中的所有端口，是以這裡的輸出可能很有趣。
從伺服器顯示活動的傳出連接配接(tcp和udp)，然而，這兩個清單都沒有顯示可疑的活動。
對 chkrootkit進行rootkit檢測，也沒有找到任何東西。rkhunter和clamav也沒有産生任何異常。ClamAV（Linux防毒軟體）也沒有檢測到php shell和windows木馬程式。
雖然我很努力，但到目前為止還沒有發現異常打開的端口，異常的程序運作。于是，我和一個管理者核實了FTP和ssh 帳号，這些賬号看起來也很正常。
但我并沒有放棄，在使用了mac-robber工具後，我收集了在伺服器上建立和修改的檔案資訊(稍後可以用來建立事件的時間軸):
截至目前，我收集的證據包括:
分析證據
由于已經發現了攻擊者放置的一些webshell，在經過分析後。我認為，這些檔案很像Xjrop.php, Nwfqx.php 或Rwchn7.php，并且很可能駐留在正常應用程式檔案。然而，也有一個up.php檔案被調用，它提供了一個相似的目的，但有其他的源代碼。而Xjrop.php, Nwfqx.php和Rwchn7.php是一樣的, up.php是另一種具有略微不同功能的shell。用diff 指令，比較檔案：
或者通過比較他們的md5sum比較:
還有2個檔案—— bjrnpf.php和jemkwl.php，這些都是相同的，但不同于其他檔案。一個可疑的可執行檔案被命名為windoze，我懷疑是一些惡意軟體可能是從這個主機分發的。我建構了這個檔案的md5sum，并檢查了VirusTotal的哈希值，注意，在VirusTotal上上傳的檔案可以被其他研究人員看到，是以是公開的。VirusTotal認為這個檔案是木馬，為了以後的分析，我儲存了它。
一些PHP shell看起來如下所示:
你可能注意到了“404-server! !”的标題，利用谷歌搜尋的結果可能是其他受感染的伺服器:
有更多可疑的檔案包含了看似無用的代碼:
這行替換了字元串“saft”中的一個小寫字母“saft”中的每一個比對，并使用$ _POST變量mkf3wapa的内容。傳回值被忽略，是以我不确定該代碼片段的用法應該是什麼。
然而，谷歌搜尋結果顯示，這段代碼與404-server有關聯! !上傳shell并出現在相同的受損伺服器上。是以，如果你在伺服器上發現了這個代碼，它可能是一個被攻擊的辨別，你應該進一步檢查。
檢查“404-Server!!“源代碼使我得出結論，黑客提供了一個檔案浏覽器，它具有上傳、檢視和删除檔案以及調整權限的功能。
通過檢查這些檔案的背後組織和開發者，我發現它們都是由PHP程序的所有者建立的，是以它們非常像PHP應用程式所建立的。
另一個被攻擊的檔案叫做way.php，它隻是包含了來自另一個伺服器的檔案:
是以，這基本上是一種将外國html/javascript代碼包含在該域下的方法。然而，惡意伺服器向我展示了一個有趣的資訊:
這可能是因為我沒有使用正确的引用頭，或者伺服器不再為其惡意負載服務。
在一個html檔案中，我發現:
它隻是用iframe方法插入了way.php的輸出。
進一步尋找shell
以上這些檔案因為它們異常的檔案名被識别後，我開始通過應用程式代碼來查找更多可疑的檔案。特别是，你可能希望查找在伺服器上執行指令的函數，例如:
并grep所有這些函數的檔案:
你經常看到人們隻grep*.php檔案，但這可能會遺漏很多資訊，php檔案可以有其他擴充，當隻檢查 *.php擴充時，就可能會忽略*.php5*， *.php4 或*.phps 。是以，如果條件允許，你最好能在所有檔案中進行grep，或者在任何其他檔案結束時提前搜尋。也可能存在帶有任意擴充的惡意檔案，這些檔案由更正常的php檔案加載，是以你也應該嘗試檢測這些檔案。
但是，請注意，由于這些檔案沒有直接執行代碼，是以不會檢測到混淆的檔案和上傳的shell。你可能會擴充你的搜尋範圍，減少一些可疑的函數。
如果你有一個粗略的想法，當攻擊發生的時候，你可能也想要尋找在那個日期之後被建立或修改的檔案。
根據在伺服器檔案上發生的正常更改，你可以很容易地以這種方式檢測到更多的shell。
如果你已經發現了一些惡意檔案，那麼還可以使用檢測到的檔案的某些特性來尋找進一步的變體，比如，檢查所有檔案的字元串“404-Server!!”。
除了傳統的防毒軟體掃描器外，還有一種方法是使用基于yara的掃描器，比如OWASP中的WebMalwareScanner。這些基本上是掃描檔案，并以檢測惡意代碼的yara規則檢查它們。為此，你需要在git中安裝yara、python binding和WebMalwareScanner。在我的例子中，運作webmalewarescanner，可以在被破壞的PHP應用程式的源代碼上産生了很多結果，我花了一些時間，但也正确地識别了三種類型的webshell中的兩種。
此外，還有一些wordpress插件試圖檢測出攻擊方案，比如sucuri。我不想在已經損壞的系統上安裝額外的插件，是以我沒有嘗試這個。
根據我的經驗，在尋找webshell時，你應該始終結合不同的技術。有些有些檔案很難識别，乍看上去合法的檔案也可能有惡意的功能。你越了解被破壞的系統，就越容易檢測到異常檔案。
禁用攻擊檔案
收集完所有這些資訊後，不要忘記将惡意檔案渲染成無用的。我已經删除了所有使用者的閱讀和執行權限，但在系統運作了一段時間後，我将删除它們。系統中不應該留下任何損壞的檔案，以防有人不小心将它們重新激活。
建立一個攻擊時間表
在前面提到的mac-robber 工具之前，我已經檢索了檔案資訊，我用mactime建立了這個資訊的時間軸。
然後你會得到一長串看起來像以下的條目:
這是伺服器上所有檔案的非常有用的清單，包括所有者id、組id以及檔案修改、通路和更改的時間戳。
請注意，在unix上，通常會獲得檔案通路時間、檔案更改時間和檔案修改時間(atime,ctime,mtime)。這些是在檔案大小之後的mactime時間線檔案中顯示的，例如上面示例中的第二行中的m.c.。這意味着給定的日期會顯示檔案修改和更改時間。
是以，mtime在檔案最後寫入時向我顯示。但是，我不能确定它是否與檔案建立日期相比對。不幸的是，這裡無法重新構造，是以我不能确定這是上傳的時間，但是我可以确定，在周五，Jul 07檔案已經在系統上了。在linux上，你可以使用工具stat來顯示單個檔案的這些資訊。
還有一些與檔案系統，檔案通路，建立時間有關的副标題。首先，如果你的檔案系統安裝了noatime選項(你可以通過運作mount指令來解決這個問題)，則不需要編寫通路時間。雖然這能增加驗證速度，但顯然非常複雜。
檢查我的時間線，我可以知道第一個惡意的shell何時出現在系統上。
檢查日志
我可以在日志中找到一些對這些工具的調用，主要來自亞洲IP位址，但由于POST資料沒有被記錄，我無法找到從apache日志中上傳這些shell的檔案。
尋找初始攻擊向量
然而，在事件發生當天或之前，沒有可疑的sql注入或lfi/rfi活動，可能會與其中一個可疑檔案發生關系。
注意，腳本沒有檢查主題或wordpress核心漏洞，這也可能包含嚴重的漏洞。
總結
1.該系統已經被破壞了幾個星期。在apache日志的shell中，最早的可見通路是在7月初；
2.我識别了各種受損的php檔案和一個windows惡意軟體；
3.至少有三種類型的shell被發現是攻擊的名額；
4.windows惡意軟體可能還沒有傳播；
5.伺服器沒有顯示出明顯的更深的感染迹象，從使用者帳戶來看，沒有找到rootkit；
6.攻擊可能被限制在webserver使用者上。對于其他使用者，我還沒有任何攻擊的迹象；
7.最初的攻擊可能是過時的wordpress系統中最不安全的漏洞之一。
8.沒有迹象表明其他使用者通過shell通路了資料庫或資料庫憑據。但是，我不能排除有可能通路資料庫的可能性。
9.一些可能是來自亞洲IPs的惡意活動(shell通路)
除了清理系統中的惡意檔案,我也應用一些優化手段，比如更改密碼和證書，安裝一個主機id，執行定期掃描，主動監測伺服器……。不過，你永遠不會得到100%的安全性。特别是當你的伺服器已經被破壞時，你所能做的最好的事情就是檢查每一個來自非官方的備份或腳本。
原文釋出時間為：2017年9月18日
本文作者：luochicun
本文來自雲栖社群合作夥伴嘶吼，了解相關資訊可以關注嘶吼網站。.
<a href="http://www.4hou.com/technology/7653.html" target="_blank">原文連結</a>