找到乙個被掛***的站點取日誌進行分析。
分析過程：
用d盾掃瞄整個站點的存在的可疑檔案，然後再日誌中對可疑檔案進行回溯。
kindeditor檔案目錄下的後門第一次被訪問到是
202.131.82.144
，最終這個
ip發現之前的操作時在
get請求其他後門檔案，
響應碼均為
404
只有/kindeditor/attached/file/20141225/comnus.asp
響應為200
，之後就對
kindeditor
進行post
請求，沒有找到上傳點的日誌。
根據路徑/kindeditor/attached/file/20141225/comnus.asp 中的
20141225
中的資料夾日期和本地實驗判斷資料夾是根據系統時間建立的
伺服器17年遷移到新的環境，並進行過一次查殺，沒有之前的日誌。初步懷疑是之前已經被傳
shell，7
月12日又重新被利用。
繼續往前回溯日誌，發現2023年6月
20日，開始有大量的**
ip訪問該**，其中
/images/index.asp
***主頁第一次被訪問在早上6點
46分，但是返回的是
404，之後一直有大量的**
ip訪問
/images/index.asp
，都是返回
404。繼續追溯
/images/index.asp
被正常響應
200的時間是
2023年7
月12日。
202.131.82.144是對後門檔案
/kindeditor/attached/file/20141225/comnus.asp
進行post
請求後，
/images/index.asp
才能訪問成功。所以攻擊者一開始就知道有這個後門。
所以從日誌中分析可以猜測該站點在遷移前已經被上傳webshell，然後服站點交接後清除了部分
webshell
，所以才會出現攻擊者只掃瞄幾個
shell
檔案，就能準確的找到
shell
，而這次主要是利用之前上傳的
shell重新生成惡意的檔案
進行攻擊者的惡意站點的
seo搜尋優化排名。
至於/kindeditor/attached/file/20141225/comnus.asp怎麼被上傳的目前還未能排查。猜測是利用編輯器的上傳漏洞傳上去的，但是查詢當前版本的編輯器沒有找到這個版本的漏洞，所以比較困惑。
總結：
經過這次練習總結了一下整個過程。
1、找到可疑檔案，可以用d盾等工具進行尋找
2、在日誌中對可疑檔案進行回溯，尋找訪問者，請求方式。
3、尋找post請求的上傳點，了解如何上傳webshell.從而找到漏洞點。
C 分析 IIS 日誌 Log
由於最近又要對 iis日誌 log 分析，以便得出各個搜尋引擎每日抓取的頻率，所以這兩天一直在嘗試各個辦法來分析 iis 日誌 log 其中嘗試過 匯入資料庫 log parser powsershell 等等方法，最後改用的是c 讀取 iis 日誌的方法，效能最好，定製化也比較能滿足需求。讀取 1...
C 分析 IIS 日誌 Log
由於最近又要對 iis日誌 log 分析，以便得出各個搜尋引擎每日抓取的頻率，所以這兩天一直在嘗試各個辦法來分析 iis 日誌 log 其中嘗試過 匯入資料庫 log parser powsershell 等等方法，最後改用的是c 讀取 iis 日誌的方法，效能最好，定製化也比較能滿足需求。讀取 1...
如何檢視和分析IIS日誌
日誌的在iis中是很重要的，但是很多人卻忽略了，在這裡說說，日誌格式建議使用w3c擴充日誌檔案格式，這也是iis 5.0預設的格式，可以指定每天記錄客戶ip位址 使用者名稱 伺服器端口 方法 uri資源 uri查詢 協議狀態 使用者 每天要審查日誌。如圖1所示。iis 5.0的www日誌檔案預設位置...