攻擊溯源作為安全事故中事后響應的重要組成部分，通過對受害資產與內網流量進行分析一定程度上還原攻擊者的攻擊路徑與攻擊手法，有助于修復漏洞與風險避免二次事件的發生。攻擊知識可轉換成防御優勢,如果能夠做到積極主動且有預見性，就能更好地控制后果。

說人話：被黑了就要知道為什么被黑了怎么被黑的，不能這么不明不白。

[[264480]]

一、主體思路

溯源的過程當中的時候除開相關的技術手段之外，首先還是需要確認一個整體的思路。對異常點進行一個整體的分析并根據實際環境給出幾種可能的方案，這樣處理起問題相對就可以游刃有余心里有譜，手上就不慌了。

常規出現的、容易被用戶感知的異常點舉例如下：

• 網頁被篡改、被掛上了黑鏈、web文件丟失等
• 數據庫被篡改、web系統運行異常影響可用性、web用戶密碼被篡改等
• 主機出現運行異常反應卡頓、文件被加密、主機系統出現其他用戶等
• 主機流量層出現大量異常流量

根據用戶現場的情況往往還需要做一些信息收集的工作比如，出現異常的時間點(非常重要)、異常服務器的主要業務情況、大致的一個網絡拓撲是不是在DMZ區、是否可以公網訪問、開放了那些端口、是否有打補丁、使用了怎么樣的一個web技術、最近是否做過什么變更、有沒有什么安全設備之類的。

根據收集到的信息，往往可以得出了幾種可能。一個web服務器公網可以訪問出現了被掛黑鏈的事件使用了s2框架，那么初步可以懷疑是s2-045 s2-046之類的命令執行漏洞了;如果一臺公網服務器沒有安裝補丁又沒有防火墻防護，administrator的密碼為P@sswrod那么有很大的可能性是被暴力破解成功;后面的工作主要就是收集各種資料證明這一猜想即可。

二、web系統

上次自己部署了一個web系統在VPS上面，后面看了一下access日志基本上每天都有好多的web系統掃描事件，路徑探測的、EXP掃描的、文件遍歷的什么都有篩選起來特別頭疼。

一般web類的安全事件在web日志當中一般都能發現一些端倪，清除日志這種事情畢竟不是每個黑客都會干。

常見幾個中間件的日志如下：

• apache的日志路徑一般配置在httpd.conf的目錄下或者位于/var/log/http
• IIS的日志默認在系統目錄下的Logfiles下的目錄當中
• tomcat 一般位于tomcat安裝目錄下的一個logs文件夾下面
• Nginx日志一般配置在nginx.conf或者vhost的conf文件中

日志一般以日期命名，方便后續審計與安全人員進行分析。

工欲善其事必先利其器，一般日志量都比較大。互聯網上還是有很多的日志檢測工具，個人不是很喜歡用主要工具還是notepad++ 和Sublime Text跟進收集的信息比如時間點這種情況，對時間點前后的請求日志進行分析，一般都都能發現一些異常。

為了方便的識別一些日志，github也有很多開源項目有專門去日志中找安全相關攻擊的、或者是統計的。因為現在很多掃描器也比較多，一檢查往往也會發現很多無效的攻擊，篩選起來反而感覺更麻煩。

推薦一個小工具：web-log-parser為開源的分析web日志工具，采用python語言開發，具有靈活的日志格式配置。優秀的項目比較多，蘿卜青菜各有所愛自己喜歡較好，實在不行就自己定義好規則搞一個。

連接如下：https://github.com/JeffXue/web-log-parser

在處理一些訪問訪問、網頁更改的時候、上傳路徑、源IP之類的信息都能夠較好的收集。通過對一些關鍵路徑的識別，結合一定的信息往往都能定位到入口點。

常見的一些入口點舉例如下：

• 一些CMS的EXP，比如Discuz Empire Spring 之類的一些命令執行、權限繞過邏輯漏洞等因為比較通用，網上很多都是公開的所以涉及面相對較廣。
• 編輯器的上傳漏洞，比如知名的FCK編輯器、UEditor之類。
• 功能性上傳過濾不嚴格，比如頭像上傳資料上傳界面一些過濾嚴格導致的上傳漏洞。
• Web系統的弱口令問題 admin賬戶、或者是tomcat的manager用戶弱口令 、Axis2弱口令用戶、Openfire弱口令等等

同時web系統往往容易存在一些webshell的情況，經常在一些上傳目錄里面找到一些webshell、明明是個JSP的網頁還出現了一個php的一句話。一般需要重點關注一下。推薦用D盾對web系統的目錄進行掃描。

掃描出來的webshell時間上傳時間、文件創建時間、文件修改時間往往準確性都比較高，一般不會去更改這個時間，用來在日志當中排查就相對容易的多。

三、主機系統

以前一直覺得一些蠕蟲病毒都挺逗的很多傳播方法居然只是依靠暴力破解和MS17-010之類的漏洞傳播，感覺波及面應該比較小后面才發現這個方法簡單粗暴反而最有效。

對于Linux平臺相對安全性偏高一些，常見的幾個病毒如XorDDOS、DDG、XNote系列的普遍也是依靠暴力破解進行傳播，溯源的過程中也重點考慮暴力破解。

常用的一些日志舉例如下：

/var/log/auth.log 包含系統授權信息，包括用戶登錄和使用的權限機制等信息  
/var/log/lastlog 記錄登錄的用戶，可以使用命令lastlog查看  
/var/log/secure 記錄大多數應用輸入的賬號與密碼，登錄成功與否  
/var/log/cron 記錄crontab命令是否被正確的執行 

grep,sed,sort,awk幾個命令靈活運用、關注Accepted、Failed password 、invalid特殊關鍵字一般也能輕松發現一些端倪如下：

經常一些攻擊者忘記清除日志，就很方便能查看詳細了。一個history命令，黑客的操作就一目了然。

當然了一些腳本執行完了之后往往最后會清除日志比如下面這樣的往往就加大了難度，日志被清除了往往就更顯得異常了。可以重點看一下還剩下那些日志、或者關注一下網絡層面是不是還有其他的安全設備可以在流量層進行溯源分析的。

源于Linux一切皆文件與開源的特性，在溯源的過程中也有好處也有壞處，rootkit就是最麻煩的一件事情了。由于系統一些常用的命令明文都已經被更改和替換，此系統已經變得完全不可信，在排查溯源的過程中往往不容易發覺對安全服務的人員就有較高的技術要求了。

Windows平臺下面的溯源就相對容易一些當然主要還是依靠windows的日志一般用 eventvwr命令打開事件查看器。默認分為三類：l應用程序、安全、性統 以evt文件形式存儲%systemroot%\system32\config目錄：

合理使用篩選器往往可以幫助我們更好的排查日志，比如懷疑是暴力破解入侵的篩選事件ID == 4625審核失敗的日志，后續通過對時間的排查、以及源IP地址、類型與請求的頻率進行分析來判斷是否是來源于內網的暴力破解。

通過系統內部的日志來判斷是否是惡意進程的運行狀態。

通過對logontype的數值確認就可以確認到底是通過什么協議進行暴力破解成功的。相對的數值關系如下：

local WINDOWS_RDP_INTERACTIVE = "2"  
local WINDOWS_RDP_UNLOCK = "7"  
local WINDOWS_RDP_REMOTEINTERACTIVE = "10"  
local WINDOWS_SMB_NETWORK = "3" 

如下圖就是一個典型的SMB的認證失敗情況：

Windows系統的補丁相對重要一些，一些關鍵的補丁沒有打很容易遭受到攻擊成功的事件。重點就關注一些常見的比如ms17-010 ms08-067 ms16-032等安全補丁都是內網滲透常用的攻擊包。可以通過sysintemfo可以查看到當前系統當中已經安裝的補丁。

此外windows下面還包括很多域控的安全日志，因為內容太多就不再展開敘述，溯源主要還是想還原攻擊路徑，通過windows日志搞明白訪問關系攻擊者的攻擊鏈條，給用戶一個交代就好。

四、其他常用系統

數據庫系統也是攻擊者入口點的一些重災區，常見的比如msssql server由于數據往往在window環境下安裝后具有較高的權限，一些用戶經常安裝完成之后也不會怎么去加固數據庫，基于庫站分離的原則很多mssql公網直接就可以訪問訪問控制策略比較弱，弱口令的問題尤為突出。

比如下對于mssql的sa用戶暴力破解日志，里面也記錄著客戶端的IP地址如果沒有配置相關的鎖定策略在密碼不夠嚴格的情況下容易被攻陷。

攻擊者爆破成功之后啟動xp_shell往往就可以以高權限執行系統命令，拿到了一個windows的shell豈不是為所欲為。

Linux平臺下面的redis也很熱門，就一個幾年的默認安裝后的未授權訪問的問題卻流傳的相對廣泛。比如最近一段事件相對比較熱門的DDG挖礦、WatchDog挖礦等病毒都主要利用redis未授權訪問執行命令，從互聯網拉取挖礦程序寫入ssh的公鑰等功能。

看見本地開放了6379端口的時候還是需要重點關注這個問題，多向用戶咨詢一下使用情況查看一下默認配置。

還有一些常用的系統比如mysql數據庫暴力破解提權一套裝、hadoop未授權訪問漏洞、釣魚郵件、破解軟件后門、惡意的office宏、office的代碼執行漏洞、郵箱缺陷、VPN配置缺陷等情況都可能是攻擊者的入口點具體情況需要結合用戶當前的情況具體進行排查。

五、總結

都說安全本質到最后就是人與人之間的一個較量，對于很多定向攻擊的安全事件排查起來估計就比較有意思，主機端的日志被清除掉流量層面全程隧道通信就呵呵了。

站在攻防的角度從攻擊者的思維模型去做應急，思考更多的攻擊者可能的途徑，經常利用的姿勢、漏洞與常用的攻擊手法再用數據去加以驗證，不局限在已知漏洞中而放過其他的問題，如果能夠做到積極主動且有預見性，就能更好地控制后果，說不過在過程中還能發現幾個0day也算是意外之喜了。