“企業應急響應和反滲透”之真實案例分析
0x05 案例之 500 錯誤日志引發的血案
首先看下圖

一天 QA 發來郵件詢問一個比較異常的事情,某測試業務出現多條狀態碼為 500 的日志,QA 懷疑是有黑客攻擊,我們開始介入進行分析。
500 錯誤代表文件真實存在過并且被人訪問執行過,但是現在文件已經被刪除了,通過文件名可以判斷并非是業務需要的文件,被黑的可能性比較大,然后找來 TOMCAT 和前端 Nginx 日志查看的確被上傳了 webshell。

根據攻擊者 IP 和時間等線索通過分析 nginx 和 tomcat 的日志可以確定攻擊者是通過 tomcat 的管理后臺上傳的 webshell,并且通過 webshell 做了許多操作

但是tomcat 帳號密碼并非弱密碼,how?我們接下來對全網的 tomcat 進行了排查,發現在其中一臺內網服務器存在 tomcat 弱口令,并且帳號配置文件中含有攻擊者使用的帳號和密碼,只是這臺服務器較早之前下線了公網 IP,只保留內網 IP,并且通過分析這臺服務器的日志,能夠判斷攻擊者之前就已經通過弱口令拿到了服務器權限,并且收集了服務器上的用戶名和密碼等信息。
我們想看看攻擊者到底想干什么,對之前收集的攻擊者 IP 進行反滲透,用“黑客”的方法拿到香港,廊坊多臺攻擊者肉雞權限,肉雞上發現了大量黑客工具和掃描日志,在其中一臺肉雞上發現我們內網仍有服務器被控制。
下面兩張圖片可以看到攻擊者通過 lcx 中轉了內網的反彈 shell


那么到目前為止我們做了哪些事情呢?
清理后門
清理全網 tomcat
梳理全網 web 目錄文件
修改業務相關帳號密碼
修改業務關鍵代碼
加強 IDC 出口策略
部署 snort
做了好多事情?可是事實上呢?事情并沒有我們想的那么簡單。
之前的安全事件剛過不久,IT 人員反饋域控服務器異常,自動重啟,非常異常。登錄域控進行排查原因,發現域控被植入了 gh0st 后門。

域控被控制,那域控下面的服務器的安全性就毫無保障,繼續對辦公網所有的 windows 服務器排查,發現多臺 Windows 服務器被植入后門,攻擊的方法是通過域控管理員帳號密碼利用 at 方式添加計劃任務。
能夠知道攻擊者是如何入侵的域控服務器比較關鍵,對域控服務器的日志進行分析發現下面可疑的日志:
2011-11-10,14:03:47,Security,審核成功,登錄/注銷 ,540,*\*,PDC,”成功的網絡登錄:
用戶名: *.ad
域: *
登錄 ID: (0x0,0x1114E11)
登錄類型: 3
登錄過程: NtLmSsp
身份驗證數據包: NTLM
工作站名: CC-TEST-V2
登錄 GUID: -
調用方用戶名: -
調用方域: -
調用方登錄 ID: -
調用方進程 ID: -
傳遞服務: -
源網絡地址: 192.168.100.81
源端口: 0
2011-11-10,3:13:38,Security,審核失敗,帳戶登錄 ,680,NT AUTHORITY\SYSTEM,PDC,"嘗試 登錄的用戶: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
登錄帳戶: QM-*$
源工作站: CC-TEST-V2
錯誤代碼: 0xC000006A
"
2011-11-10,3:13:38,Security,審核失敗,帳戶登錄 ,680,NT AUTHORITY\SYSTEM,PDC,"嘗試 登錄的用戶: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
登錄帳戶: QM-*$
源工作站: CC-TEST-V2
錯誤代碼: 0xC000006A
結合之前的信息能夠鎖定 192.168.100.81 是攻擊源,遂對這臺服務器進行確認,結果有點令人吃驚:
這是一臺虛擬機,運行在一臺普通的 PC 機上,這臺 PC 機就放在業務部門同事的腳底下,這臺虛擬機本身啟用了 3389,存在弱口令,我們之前在對內網安全檢查時,這臺虛擬機處于關機狀態。由于這臺虛擬機上面跑的有測試業務,域控管理員曾經登錄過。
綜合我們之前得到的信息可以確定這臺虛擬機是攻擊者入侵我們辦公網的第一臺服務器,通過把這個虛擬機作為跳板攻擊辦公網其他服務器,至于這臺虛擬機是如何被入侵的,我們后面也確定是因為上次的攻擊事件,攻擊者通過 IDC 進入到的辦公網。
我們又做了什么?
排查所有 windows 服務器
對之前確定被入侵的服務器重裝,包括域控
snort 上加了 gh0st 的特征
snort 加上 gh0st 的特征后不久我們就發現我們辦公網還有服務器被控制

對這臺服務器進行清理后,我們仍然沒有放棄對攻擊者的反滲透,這次我們發現攻擊者還有美國的 IP,對其滲透,最終通過 c 斷進行 cain 嗅探到 3389 的密碼。
登錄到這臺美國 IP 的服務器后,發現上面運行著 gh0st 的控制端,我們內網仍然有一臺服務器處于上線狀態。

其實到這里這次事件就能告一段落了,關于攻擊者我們在這臺美國的服務器上發現了攻擊者的多個 QQ 和密碼,登錄郵箱后找到了攻擊者的簡歷等私人信息,還有就是我們之前也獲取到攻擊者在國內某安全論壇帳號。其實到這里我們能夠確定攻擊者是誰了。



責任編輯:大云網
-
發電電力輔助服務營銷決策模型
2019-06-24電力輔助服務營銷 -
繞過安卓SSL驗證證書的四種方式
-
網絡何以可能
2017-02-24網絡