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

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

[[264480]]

一、主體思路

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

常規(guī)出現(xiàn)的、容易被用戶感知的異常點舉例如下：

• 網(wǎng)頁被篡改、被掛上了黑鏈、web文件丟失等
• 數(shù)據(jù)庫被篡改、web系統(tǒng)運行異常影響可用性、web用戶密碼被篡改等
• 主機出現(xiàn)運行異常反應(yīng)卡頓、文件被加密、主機系統(tǒng)出現(xiàn)其他用戶等
• 主機流量層出現(xiàn)大量異常流量

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

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

二、web系統(tǒng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、主機系統(tǒng)

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

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

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

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

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

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

當(dāng)然了一些腳本執(zhí)行完了之后往往最后會清除日志比如下面這樣的往往就加大了難度，日志被清除了往往就更顯得異常了?？梢灾攸c看一下還剩下那些日志、或者關(guān)注一下網(wǎng)絡(luò)層面是不是還有其他的安全設(shè)備可以在流量層進行溯源分析的。

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

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

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

通過系統(tǒng)內(nèi)部的日志來判斷是否是惡意進程的運行狀態(tài)。

通過對logontype的數(shù)值確認就可以確認到底是通過什么協(xié)議進行暴力破解成功的。相對的數(shù)值關(guān)系如下：

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

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

Windows系統(tǒng)的補丁相對重要一些，一些關(guān)鍵的補丁沒有打很容易遭受到攻擊成功的事件。重點就關(guān)注一些常見的比如ms17-010 ms08-067 ms16-032等安全補丁都是內(nèi)網(wǎng)滲透常用的攻擊包?？梢酝ㄟ^sysintemfo可以查看到當(dāng)前系統(tǒng)當(dāng)中已經(jīng)安裝的補丁。

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

四、其他常用系統(tǒng)

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

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

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

Linux平臺下面的redis也很熱門，就一個幾年的默認安裝后的未授權(quán)訪問的問題卻流傳的相對廣泛。比如最近一段事件相對比較熱門的DDG挖礦、WatchDog挖礦等病毒都主要利用redis未授權(quán)訪問執(zhí)行命令，從互聯(lián)網(wǎng)拉取挖礦程序?qū)懭雜sh的公鑰等功能。

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

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

五、總結(jié)

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

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