紅藍對抗 | 沒有痕跡該如何進行攻擊溯源

現在紅隊在獲取基于Web的權限后一般更利于用內存馬了，出發點可能是覺得反彈的流量易于識別發現；但是后滲透階段一般都會有反彈出網的場景，不論是流量轉發、云函數、代理、cdn還是域前置，更多的是類似于流量隱匿。這個就類似于Win下的白名單信譽加載，利用白流量加載灰流量。這對于藍隊的同學溯源增加了難度。

作者：竹林再遇北極熊 

原文：https://www.freebuf.com/articles/web/313394.html

資料

https://www.secrss.com/articles/34725 推薦看一下

https://www.freebuf.com/articles/network/276159.html

https://xdym11235.com/archives/52.html

https://blog.csdn.net/qq_41874930/article/details/107742843

https://www.cxymm.net/article/qq_41874930/109008708

1 應急響應或者技術人員的方法論

在敘述本次應急響應前，先把方法論的前因后果講解一下，以便可以帶著方法論進入問題處置的過程，這樣體會可能會更好一點，以便可以幫助到正在提升的我們。

因為技術人員不能只關注技術，對于客戶來說世界上只有兩種人有價值，一種是能夠做事的人，一種是能夠解決問題的人，或者兩種形態于一身的人（很少）。畢竟系關、項目很復雜，客戶/銷售想要的可能不是最想的。那么有能力解決問題的人就能夠在出現問題的時候創造出價值，從而創造渺小的介入機會。

例如我的起點比較低，只能從最低點開始往上爬，做過IDC機房/單位駐場，分保、系統集成、等保、項目經理、售前、銷售（以技術為驅動落地過兩個100+的項目，所以一定要相信自己，技術真的可以給公司帶來價值，而不是只能體現公司價值，這取決于我們該怎么發揮主觀能動性的去做），現在正在做應急、正在學滲透。這一路真不容易，機會也少，很多都是可愛的人愿意相信我愿意給我嘗試的機會，我才有涉及的可能，無數次迷茫，但都被下面這個方法論給糾正過來，否則就會是一顆不頂用的螺絲釘。（做的雜，但是很開心，因為我知道前面沒有吃的苦，只要我想做，那么這些苦都是必須得還回來的，希望還未入門的你可以少走彎路，出社會即可做自己想做的事，不需要像我這樣繞很多路）

因此我深刻體會有一個觀點或者方法論非常重要，那就是“任何節點千萬不要卡在自己這，一定要往前推進，想盡辦法往前推進，如果不行，那你也是盡力了”，適用于學習、售前、售后。項目推進不能卡在銷售自己，項目管理實施進度不能卡在項目經理等等，一旦卡住，責任必在自己，因為那是自己的職責。

那么如何套用在應急響應上，例如客戶單位發生了安全事件（例如勒索病毒、掛標語這種緊急的突發情況），客戶現場：

1.目標主機一定會有日志嗎？

2.日志被刪了一定有第三方異機備份嗎？

3.沒有第三方異機備份就一定會有流量回溯嗎？

這種情況肯定存在而且非常常見，不可能萬事俱備事事如意，不然我們怎么創造價值，那么遇到這種情況該怎么應急響應？一番技術操作后和客戶說“因為殘留痕跡較少，無法進行攻擊溯源，類似于新冠，沒有掃安康碼留下痕跡，就無法追蹤到0號病人”嗎？

是的，可以說，客戶一般也認可（我以前就這么干，深感不足），因為事實如此，巧婦難為無米之炊。

但是客戶單位的業務系統就得帶著高危漏洞暴露在互聯網：

1.客戶領導會怎么想？

2.服務單位的銷售會有什么樣的擔心？會怎么想這名技術，作為技術被銷售這么想該怎么辦？

3.作為想創造機會的安服公司銷售正在想什么？

那肯定想著是怎么拿下這個單位？系關拼不過、產品價格談不下來，...，靠什么呢，靠的就是這種你搞不定我可以搞定的機會。機會從哪來？機會源于咱們技術人員，這就是技術可以創造價值的能力。那這種情況該怎么帶著方法論進入到這個安全事件應急響應過程中呢：

“任何節點千萬不要卡在自己這，一定要往前推進，想盡辦法往前推進，如果不行，那你也是盡力了”

2 情況概述

2021年12月12日18:57:30客戶單位對互聯網開放的致遠OA被入侵，文件被加密，后綴為.locked。收到相關通知后隨即進場應急。

搜索了一下這個后綴，大部分的結果都是這個病毒都是通過smb縱橫傳播的。目標主機已禁用網卡斷網處置。

3 入侵檢查

3.1 指定時間范圍內被修改的對象

按照以前文章種敘述的方法，根據案發時間，使用dm:20211212查找了exe、jsp等關鍵字，在exe關鍵字中發現異常：

3.2 常規檢查

根據案發時間查找痕跡再無有用信息，因此常規檢查了操作系統。由于工作量大，使用之前文章中的工具進行自動化收集。同樣未發現異常，勒索程序并未運行。

3.3 檢查可攻擊范圍

由于可用信息較少，因此反向思維推理：

1.從內網橫向滲透的可能性：由于僅一臺主機被勒索，因此排除該可能性。

2.從互聯網縱向滲透：排查互聯網網關，發現僅映射業務端口，因此排除操作系統層面被入侵的可能性。

3.因此將檢查重點放在應用系統上。

3.4 檢查攻擊痕跡

沒找到，后來才發現是致遠自己寫的java程序，加載的也不是tomcat的配置文件，沒有產生日志即不會被第三方異機備份。同時也沒有流量回溯設備。

3.5 安全設備的檢查概述

安全設備中只能看到誰攻擊了，但是看不出來誰利用哪個漏洞進來的。因為黑客攻擊成功了，意味著黑客繞過了特征庫，即不會匹配規則和匹配規則中的記錄日志功能。

但是在檢查APT過程中發現了異樣（安恒還是牛滴呀）：

到這里即會發現，除了一個惡意文件，啥也沒有發現，該怎么兌現這個方法論？

“任何節點千萬不要卡在自己這，一定要往前推進，想盡辦法往前推進，如果不行，那你也是盡力了”

4 轉折點-站在攻擊者的角度

同時也算響應了"一切積累都是為了應對此類情況"這句話。

在以往可能受限于能力，可能就收場了，但是現在不一樣了，我會信息收集了。

根據關鍵字進行搜索。

根據信息收集的結果進行測試，發現存在漏洞。

ps：其實哪有這么順利，版本漏洞這塊翻遍了搜索引擎：

致遠-OA-A8-htmlofficeservlet-getshell-漏洞
致遠OA-A6-search_result.jsp-sql注入漏洞
致遠OA-A6-setextno.jsp-sql注入漏洞
致遠OA-A6-test.jsp-sql注入漏洞
致遠OA-A6-敏感信息泄露一-
致遠OA-A6-敏感信息泄露二-
致遠OA-A6-重置數據庫賬號密碼漏洞
致遠OA-A8-m-后臺萬能密碼
致遠OA-A8-m-存在sql語句頁面回顯功能
致遠OA-A8-v5-任意用戶密碼修改
致遠OA-A8-v5-無視驗證碼撞庫
致遠OA-A8-任意用戶密碼修改漏洞
致遠OA-A8-未授權訪問
致遠OA-A8-系統遠程命令執行漏洞
致遠OA-Session泄漏漏洞
致遠OA-帆軟報表組件-前臺XXE漏洞
致遠OA-ajax.d前臺未授權任意文件上傳
致遠OA系統多版本Getshell漏洞復現

6 沉住心，總結建議該怎么寫

因為并不一定是通過這個洞進去的，也有可能是通過其他沒有公開但是已在野利用的，因為服務器上并沒有痕跡為此做支撐，因此需要建議客戶：

1.開啟訪問日志記錄，例如這個洞需要用到的URI就是漏洞指紋，雖然看不到POST數據，但是訪問日志中會留下痕跡；

2.檢查補丁安裝情況，沒有公開但是在野利用的，廠商肯定清楚；

3.禁止服務器訪問互聯網，例如這個漏洞的利用就涉及目標主機是否可以主動外聯。

7 萬變不離其宗

場景、事件就和人類指紋類似，不可能一樣，那么如何應對不同場景的突發事件，唯有整理出適用于自己的一套方法論作為基礎支撐才是最適用的。

8 IOC

45.76.99.222

8abaa521a014cdbda2afe77042f21947b147197d274bf801de2df55b1e01c904