當PHP伺服器被黑客入侵了該怎麼辦？

前情提要

我最近處理了一個Linux Web伺服器被入侵的案子，事情的起因是客戶發現Web伺服器上出現了一個新的PHP文件，它與運行在伺服器上的WordPress應用程序和特定的用戶代理無關，所有的流量都被重定向到另一個站點。

本文並不是一個詳細的取證指南，也不是一個詳盡的安全事件響應手冊。寫作的目的是想為您提供一些思路，碰到需要處理這類Linux伺服器被黑的Case時候，你應該作何考慮？實施那些行為？需要準備哪些常用的工具？

***在閱讀本文之前，請注意有一個WordPress官方提供的常見問題解答：《當你的伺服器被黑客攻擊時，你該怎麼做》，感興趣的可以查閱：https://codex.wordpress.org/FAQ_My_site_was_hacked，雖然這裡邊的某些細節已經不再適用了，但總體思路、方法和結論仍然有效。

1．開始

當管理員第一次發現伺服器被入侵後，立即清理了所有發現的惡意文件，修復了重定向的問題，認為一切都已經復原了，直到不久之後伺服器再次被入侵。管理員又做了修復工作，這次還更新了系統，在決定將應用程序轉移到一台新伺服器上之前，他們決定請其他人員檢查以下，於是，我就上場了。

擺在我眼前的待取證對象是：

仍在生產環境中運行的系統

至少遭遇了兩次入侵

管理員進行對系統進行了實質性的修改

這些條件都不算理想，甚至可以說是不適宜的，提前聲明：我的目的不是去創造一個合法有效的監測鏈，而是要做混合取證，在儘可能的不終端運行中的服務的情況下，進行事件響應和修復被損壞的東西。我的目標是：

確定系統是否仍然處於危險狀態（如果是的話，刪除或阻止與此相關的所有內容）

檢測是否存在被修改的文件，以避免將已被感染文件遷移到新的伺服器上

理想情況下，找出初始的入侵向量，並確保它已被阻止。

在獲得域名、IP和SSH憑證之後，我就開始工作了。

2．收集證據

在連接到伺服器之前，我記錄了自己的IP，確保以後能夠在日誌中識別出它。

然後我通過SFTP命令連接到了伺服器上。由於伺服器的磁碟已經被載入並且正在運行，因此我無法獲得鏡像，所以我下載了所有感興趣的、能得到的日誌文件。我拷貝了整個/var/log目錄和存儲Apache日誌文件的特定目錄，複製了受損的PHP應用程序，以及在事件發生後不久所採取的一些備份。不幸的是，第一次被入侵和管理員做出更改之間沒有進行系統備份，因此一些關鍵文件可能已經被修改了。

開啟了Kali，針對伺服器啟動Nmap埠掃描和wpscan掃描。由於伺服器運行了一個老舊的WordPress實例，而且這個實例曾執行過惡意的重定向，所以WordPress很可能是入侵的初始點。然而，由於WordPress在被入侵後已經更新過了，wpscan沒有在當前的版本中找到任何漏洞。Nmap埠掃描的結果是開放了FTP，SSH，HTTP和HTTPS埠，這對於一個Web伺服器來說有點多餘，攻擊者也可能從其中一項服務進行突破。然而，管理員的報告里說所有的shell都是在wp-content目錄下被發現的，這在某種程度上暗示了攻擊者可能入侵了WordPress應用程序。

我還使用VirusTotal檢查了該站點是否有傳播惡意軟體的記錄，但似乎一切都很好。

我決定通過控制台登錄系統。由於不確定伺服器上的二進位文件是否被感染了，所以為了減少影響，我使用了自己的靜態鏈接二進位文件。從BusyBox下載了coreutil二進位文件並上傳到伺服器上，同時還上傳了chkrootkit工具和SLEUTH工具包中的一個名為mac-robber的工具。

用靜態二進位文件檢查系統，得到運行中的進程和cronjobs等的列表信息，你可以使用

netstat-tulpen

命令得到一個監聽（TCP和UDP）進程的列表（我沒有覆蓋所有掃描到的埠，所以得到的輸出可能是有趣的）。可以使用

netstat-taupn

命令顯示從伺服器中輸出的活動的連接（TCP和UDP）。然而，這兩個清單都沒有發現可疑的活動。

Rootkit檢測工具chkrootkit也什麼都沒發現，使用rkhunter和ClamAV也沒有什麼收穫（這不意味著什麼，不幸的是，ClamAV錯過了PHP shells和Windows木馬）。

我開始手工尋找一些不同尋常的事物，但目前為止一切似乎都很乾凈：沒有不尋常的開放埠、沒有不尋常的進程在運行。我用一個管理員賬戶驗證了FTP和ssh帳戶，它們看起來不錯。在這個層面上似乎沒有入侵的跡象。

mac-robber工具幫助我收集了伺服器上創建和修改的文件的信息（稍後可被用於創建事件的時間線）：

./mac-robber />/root/forensics/timeline.txt

現在，我發現了：

伺服器上被創建的文件及時間的信息

各種日誌文件，其中包括Apache日誌

被入侵的網站一些元代吧，包括一些（被修改過的）shell文件

第一次和第二次被入侵之間的備份

總的來說，還算有所收穫。當然，您可能認為這些日誌數據不能被信任，因為它們可能被攻擊者修改過了。但我卻沒有理由期待攻擊會這麼複雜。

3.深度檢查

管理員已經確定了一些被攻擊者上傳的webshells文件。我開始檢查這些文件，發現大部分文件的名字都比較隱蔽，如Xjrop.php，Nwfqx.php或Rwchn7.php（首字母都是大寫的），這些文件是完全相同的，分散在正常的應用程序文件之間。然而有一個名為up.php的文件，與上述幾個文件的源代碼不同，功能也稍有差別。可以使用diff命令比較兩個文件：

diffXjrop.phpNwfqx.php

或者比較它們的MD5值：

md5sumXjrop.php

md5sumNwfqx.php

還有2個文件的名字比較奇怪，bjrnpf.php和jemkwl.php，全部是小寫這兩個文件是相同的，但有別於其他文件。一個可疑的可執行文件被命名為windoze.exe，我懷疑一些惡意軟體可能已經從該主機傳播出去了。使用md5sum計算這個文件的哈希值，在VirusTotal進行檢查，（注意上傳到VirusTotal的文件可以被其他研究人員看到，是公共的，所以最好不要上傳可能含有保密或敏感信息的東西，可以首先使用哈希值進行分析）。VirusTotal的分析結果確定該文件為木馬程序。因此我將它保存下來以備後續的分析。

分析這些PHP shell樣本，發現某些文件中包含如下信息：

注意它們的標題「404-server!!」。用搜索引擎搜索胰腺癌，發現了其他一些可能受感染的伺服器信息：

還有一些可疑文件中，包含了一些看似無用的代碼：

這一行代碼的含義是正則匹配「saft」字元串中的小寫字母「pageerror」，將其替換成$_POST變數「mkf3wapa」。由於返回值被忽略，所以我不知道這個代碼片段具體的作用是什麼。

然而，使用Google搜索，發現一大堆的查詢結果，表明這段代碼與黑客上傳的「404-Server!!」shell腳本有聯繫，它們同時出現在被入侵的伺服器上。因此，如果您在伺服器上找到此代碼，它可能存在被感染的威脅，您應該對伺服器做進一步的檢查。

審查包含「404-Server!!」的shell文件的源代碼，發現它們提供了上傳／查看／刪除文件以及調整許可權的功能。

檢查文件的所有者和用戶組，發現它們都是用PHP進程的所有者創建的，所以它們很可能是由被入侵的PHP應用程序創建的。

另一個被感染的文件名為way.php，它只是包含了來自另一個伺服器的一個文件，源代碼如下所示：

這段代碼中指向的惡意伺服器向我們展示了一個有趣的消息：

可能是因為我沒有使用正確的referer頭，或者是伺服器不提供惡意負載了。

在一個HTML文件中，發現如下代碼：

尋找更多的Shells

管理員提供的可疑的Shell文件是因為它們有比較特殊的、奇怪的命名，接下來，我開始通過應用程序代碼來尋找更多的可疑文件，尤其是，您可能希望查找在伺服器上執行命令的函數，如：

passthru

exec

shell_exec

eval

system

使用以下命令搜索所有包含這些函數的文件：

egrep -rin"system|passthru|exec|shell_exec|eval"/var/www/vhosts/xyz/ > ~/forensics/results_shell_grep.txt

人們經常會使用*.php的後綴來搜索可疑的PHP文件，但PHP文件其實還有其他的擴展名，如*.php5、*.php4或*.phps，如果只檢查可能*.php的話，可能會錯過很多。所以，如果條件允許的話，可以搜索一下上述所有擴展名的文件。也有一些惡意文件使用任意擴展名，由更規則的PHP文件載入，因此也應該嘗試檢測一下這類文件。

注意，目前還沒有檢測那些既沒有混淆也不存在上傳Shells情況的文件，因為這些沒有不直接執行代碼。另外，您可能還會搜索一些不太可疑的函數，這樣做也許還會得到太多的結果，例如：

fputs

fwrite

fopen (特別是攜帶URLs的)

chmod

socket_*

curl_*

base64_decode

gzinflate

如果你有一個大致的想法，當入侵事件發生時，你可能會想到搜索一下在那個日期之後被創建或修改的文件，如：

find-mtime -2/directory

您可以遞歸地識別出／目錄下在前2天內或更早時間之前修改過的所有文件。根據伺服器文件上文件修改的規律，您可以很容易地通過這種方式檢測到其他的Shells文件。

如果你已經確定了一些惡意文件，也應該根據一些發現的特徵尋求更多的變種，如在本例中檢查字元串「404-server!!」，可能會發現更多可疑的文件信息。

除了傳統的防病毒軟體之外，還有另一種方法，即使用OWASP出品的基於YARA規則的WebMalwareScanner掃描儀，要做到這一點，你需要安裝YARA、Python綁定並從Github上下載WebMalwareScanner。在處理這件事情時，我在另一台Linux機器上運行了WebMalwareScanner對被感染的PHP應用程序的源代碼進行檢測，花了一些時間，不過得到了很多結果，正確識別了一些webshells。

root@DESKTOP-XXX:~# cat webmalwarescan_results.txt |grep"webshell"[2017-08-0109:24:56] Scan resultforfile /path/to/up.php : webshelliMHaPFtp2[...]

另外，有些WordPress插件也是被入侵的目標，需要被檢測，不過我不想在已經被破壞的系統上安裝額外的插件，所以這一次沒有嘗試這種方式，下次可能就會這麼做了。

根據我的經驗，最好能夠結合不同的技術去尋找webshells。它們有時很難識別，乍看之下一些看似合法的文件也可能具有惡意功能。你越了解被入侵的系統，就越容易檢測到不應該存在的文件。

禁止被感染的文件

收集完所有這些信息後，不要忘記把惡意文件清理掉。我已經移除了這些可疑文件的所有用戶的讀取和執行許可權，系統運行一段時間後，沒有明顯的問題，將它們刪除。別把可疑的文件殘留在系統中，以防有人不小心激活了它們。

創建一個時間線

前邊提到使用mac-robber工具檢索到了創建和修改文件的信息，現在我用mactime創建了一個時間線：

mactime-btimeline.txt2017-06-01>timeline_output.txt

得到了一個長長的條目列表，如下所示：

Fri Jun30201715:51:55308m.c. -rw-r--r--100001004/var/www/vhosts/xyz/httpdocs/way.php

Fri Jun30201716:07:4731m.c. -rw-r--r--100001004/var/www/vhosts/xyz/httpdocs/newmessage.html

這是一個與伺服器上的所有文件有關的非常有用的列表，包括了文件的owner id、group id，以及文件被修改、訪問和更改的時間戳。

注意，在UNIX系統上，一般情況下可疑獲得文件的訪問時間、更改時間和修改時間（atime，ctime，mtime），以常見的mactime輸出為例：

a代表一個文件被訪問的時間（atime）

c代表一個文件的內容或許可權被更改的時間（ctime）

m代表文件內容被更改的時間，而不是所有者或許可權被更改

b代表文件被創建的時間，不過你通常不會看到這個

所以，mtime顯示了文件最後被寫入的時間。然而，我們不能確定這是否與文件的創建日期相吻合，遺憾的是這裡無法重建，所以不能肯定這就是文件被上傳的時間，但可以肯定的是，上星期五，即7月07，該文件就已經存在於系統上了。在Linux系統上，您可以使用stat命令顯示單個文件的詳細信息。

關於這文件系統和文件的訪問／創建時間的問題，請允許我再多說一點。首先，你的文件系統在載入時如果啟用了noatime選項，那麼就意味著不會記錄對磁碟的訪問時間，這樣做可以提高訪問速度，但顯然並不利於取證分析。不過，某些文件系統依然可以找出文件創建時間，大多數Linux伺服器上的ext4格式的文件系統就支持這一功能，但沒有簡易的展示工具，mactime並不適用。

Linux下使用debugfs可以查詢文件的創建日期。

檢查時間線，可以計算出第一個惡意shell出現在系統上的時間，結果顯示是在事件被發現的幾周之前，這不是一個好兆頭。

檢查日誌文件

從日誌中查看調用這些腳本工具的信息，發現幾個主要來自於亞洲的IP地址，但由於apache日誌里沒有記錄POST數據的嘻嘻，因而無法確認通過這些Shells上傳了哪些文件。

尋找初始攻擊向量

為了定位初始的攻擊向量，我使用了apache-scalp工具，雖然它有點舊了，但依然有效。但仍在工作。通過正則表達式它基本上能Apache日誌中匹配出已知的攻擊向量。

/opt/apache-scalp/scalp# python scalp.py -l /path/to/logs/access_log.processed.1_plain-f /path/to/default_filter.xml -a lfi,rfi,sqli,dt -p"25/Jun/2017;05/Jul/2017" --output /root/scalp --html

然而，沒有發現可疑的SQL注入或LFI / RFI漏洞利用的情況，事發前一天也沒有能夠與可疑文件相關聯的可疑事件發生。

檢查WordPress插件表明，至少有一個SEO插件包含了一個嚴重的文件上傳漏洞，這個插件是一個月前安裝的。因為應用程序安裝了許多插件，因此我寫了一個小腳本來檢查WordPress插件目錄，比對wpvulndb.com已公布的漏洞（不過該系統好幾年沒更新過了）。

事實證明，存在很多的嚴重的安全漏洞，如果沒有足夠的日誌信息，很難追蹤初始向量。

注意，這個腳本不檢查主題或WordPress核心的漏洞，它們也可能包含嚴重的漏洞。

做完上述事情之後，我決定花足夠的時間為客戶提供一份初步報告，並展開進一步的行動。

4．結果

現在，我們都知道哪些情況了呢？

該系統已經被入侵幾個星期了。Apache日誌顯示shells最早的訪問時間是7月初，也就是說大約3個星期之前。

發現了各種被感染的PHP文件和一個Windows惡意軟體。

至少有3種類型的shells和其他一些文件是入侵的指標（IoCs）。

Windows惡意軟體可能還沒有蔓延，這是好事。

伺服器沒有顯示明顯的更深層次的感染的跡象，因此攻擊者可能沒有升級本地許可權。用戶帳戶看起來沒有問題，沒有後門可尋，除了我們最初確定的之外，沒有發現進一步被感染的文件。

妥協可能受Web伺服器用戶/組的限制，沒有其他的用戶/服務被入侵的跡象。

入侵的初始向量可能是過時的WordPress系統中的眾多漏洞之一。

資料庫或資料庫憑據沒有被其他用戶通過shell訪問過的跡象，但也不能排除資料庫被訪問過的可能性。

有些惡意活動（shell訪問）源於亞洲的IPs。

除了從系統中將惡意文件中清除之外，我們還使用了一些安全加固措施，如更改密碼和證書、安裝了一個主機入侵檢測系統（IDS）、執行定期掃描、主動監視了伺服器長達一周的時間……

不過，你知道的，從來沒有100%的安全。尤其是當你的伺服器已經遭到入侵時，最好的做法就是仔細檢查你無法從乾淨的備份或官方資源中恢復的每一個腳本。

事實上，初步分析之後，這個故事持續了很長時間。因而最好讓你的伺服器保持最新狀態，這比事後處理入侵事件要容易得多，工作量也少。

【更多資料】

本文中所提到的所有的工具和相關資料信息，羅列如下：

https://wpscan.org

https://www.virustotal.com

https://busybox.net/downloads/binaries/

https://github.com/maxlabelle/WebMalwareScanner

https://wiki.sleuthkit.org/index.php?title=Mactime

http://moiseevigor.github.io/software/2015/01/30/get-file-creation-time-on-linux-with-ext4/

https://github.com/nanopony/apache-scalp

https://github.com/mhelwig/wp_check_plugin_dir

https://www.wpvulndb.com

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！