溯源實例-從OA到某信源RCE全0day攻擊

0x01 序言

2021年國Hvv真實溯源過程，在流量設備告警能力弱的情況下，重人工介入分析整個過程總結，回顧當時整個溯源過程和0day的捕獲過程，嘗試把當時的心境和技術上的思考點梳理出來，給大家參考，批評。

0x02 溯源過程

事件起源于4月9日午后的一則來自EDR的webshell告警，如下：

馬上展開對該服務器的排查，該服務器為某信源VRV，純內網環境。說明攻擊者已經進入內網環境，分兩條線分別對攻擊入口和內網影響面進行排查。

2.1

向內溯源，確定影響面

2.1.1某信源VRV溯源

1.從日志分析

因為某信源VRV的管理后臺使用SSL協議，在協調廠商提供證書的同時，對access.log日志進行分析，嘗試找出其中的攻擊入口。

從日志尋找入口的思路：

（1）定位webshell訪問接口，確認攻擊跳板的IP

（2）對webshell訪問前后日志進行分析，確定漏洞URL

（3）將可疑URL在其他時段日志中進行搜索，找出在其他時段沒出現過的URL重點分析

（4）對POST請求的日志重點分析。

通過對日志分析，發現10.*.*.*2在對VRV服務器嘗試掃描，掃描日志符合fscan等類型內網掃描工具的流量，如下：

此時已經定位了攻擊某信源VRV的主機為10.*.*.*2，同時安排其他同事對該IP進行溯源分析。

該部分掃描無影響，然后繼續分析，發現攻擊隊成功登陸了audit賬號：

結合測試，發現audit賬戶為弱口令123456，同時在audit審計賬戶的后臺中發現system也被登錄過，同樣為弱口令。（PS：此時猜測admin用戶也是弱口令，經過測試并不是。）

時間和IP都和攻擊者路徑對得上。但audit和system賬戶權限有限，并不會直接控制終端。

此外，在審計用戶的后臺還發現，admin賬戶的密碼被修改過,操作者時admin本人，登錄IP為攻擊隊控制的跳板機，修改后密碼后，admin賬戶成功登錄。

到這得到的信息，總覺得是因為admin賬戶密碼被重置導致的整臺服務器實現（如果是admin弱口令的話，就不會存在admin修改自己密碼的操作了。）

繼續分析日志，發現在logo.aspx文件被訪問前，還曾訪問過logo.txt。

而且logo.txt的訪問中存在一次404的訪問，說明馬沒寫成功。那么比對兩次logo.txt訪問前被訪問的接口，大概率可以定位到漏洞存在點。

成功定位/VRVEIS/SystemMan/GetNavUserByNavGuid.aspx就是漏洞文件，而該文件能寫入shell，且從日志看，該路徑應該需要admin權限才能訪問。

那么問題來了，admin賬號權限咋來的？帶著疑問，先分析GetNavUserByNavGuid.aspx被訪問的日志：

成功定位/VRVEIS/SystemMan/GetNavUserByNavGuid.aspx就是漏洞文件，而該文件能寫入shell，且從日志看，該路徑應該需要admin權限才能訪問。

那么問題來了，admin賬號權限咋來的？帶著疑問，先分析GetNavUserByNavGuid.aspx被訪問的日志：

在admin用戶登錄前，已經出現了大量的接口調用和訪問，里面奇跡般的記錄了一個POST的body，把思路引向了注入（后話：最后證明pczq參數與漏洞利用無關）。

恰好如果是注入的話，也解釋的通admin賬號的來源和寫文件的操作。mssql支持堆疊注入，update操作可以改密碼，xp_cmdshell可以用于寫shell。

而在登錄admin之前，登錄audit、system賬號的行為，原因大概是因為admin用戶的密碼復雜，cmd不可解。所以先解開audit和system的密碼登錄的。

2.從流量分析

從流量分析已經是幾個小時以后的事情了，某信源廠家并不愿意提供證書對流量進行解密。但是在不經意間看到VRV根目錄下有一個cert目錄，在其中找到證書。

證書有加密，嘗試以后發現證書密碼是123。

此時終于有了明文流量了，直接搜索接口，驗證上面從日志中溯源的結論，如下：

與日志分析結論一致，且在流量中有發現修改admin的密碼。（時間久遠，找不到數據包截圖了，payload截圖如下）

3.雜記

某信源這個漏洞是0day，后來因為客戶要求，將細節給了某信源，某信源還特地發了公告：

具體漏洞分析過程見3.1

2.1.2 某信源后臺失陷的影響面

shell在上傳后，我們馬上進行了處置，從某信源服務器進行拓展是來不及的，所以我們重點從某信源后臺失陷后，攻擊者都干了些什么來確定影響面。

眾所周知，某信源是終端管控系統，其最常用的攻擊方法就是通過后臺對管控的終端進行下發文件/執行命令等方式操作進行利用。于是在日志中找到相應的接口進行分析：

根據DeviceID可以確定出被攻擊的機器具體是哪臺，最終梳理出一個表，最后使用時間都在被攻擊之前，如下：

也不敢大意，在流量側重點監控了幾個IP的流量，沒有明顯異常行為，對PC都進行了查殺、進程、啟動項、注冊表分析，確認未被攻擊者控制。此時已經凌晨3點多。

第二天與客戶溝通后發現，該VRV是用于VPN接入時進行管控的，而VPN在4月8日晚上已經關閉。

2.1.3 10.*.*.*2失陷后的影響面

該失陷主機在DMZ區，且開放對互聯網的訪問，所以大概率這就是首臺被攻破的機器了。

凌晨3點多，我同事還沒有完整的梳理出該機器的影響面，于是我參與其中一起梳理。（PS：客戶第二天一早要看到影響面，不敢怠慢）。

分析思路：

（1）以10.*.*.*2作為源IP，分析其對內網的整個訪問流程中的異常流量。

（2）分析10.*.*.*2上的木馬文件、攻擊者工具等文件，在分析影響面的同時也尋找被攻擊的點。

（3）關聯服務器分析

整個分析展開時，由于流量設備告警能力弱（可以說連SQL注入都不怎么告警），分析依靠蠻力介入的比較大。整體看下來就是掃描流量非常多，但分析是否成功實在工作量太大了。

在掃描文件的時候，發現服務器上仍存在攻擊隊未刪除的fscan掃描結果，如下：

整理后，結合流量進行分析，發現攻擊隊共計探測到28臺內網機器（含10.*.*.*2本身），其中存在漏洞的情況如下：

• 10.*.*.*2 存在MS17-010漏洞（本機），DMZ區域做了策略優化，禁止了該區域內的445訪問，所以其只能訪問自己的445。
• 10.*.*.*7 存在Druid未授權訪問漏洞，未發現流量中有利用行為。
• 10.*.*.*1 存在MySQL弱口令，未在流量中發現進一步漏洞利用。
• 10.*.*.*5 存在某信源SQL注入0day
• 10.*.*.*3 被成功登錄了數據庫

其本身情況就是這樣了，然后對其關聯的服務器進行分析，因為該應用站庫分離，用的是mssql，使用的是sa用戶，IP為10.*.*.*3，在流量中也證實該機器被成功登錄了mssql。那極有可能通過xp_cmdshell已經獲取到了數據庫服務器的權限。

通過上機排查10.*.*.*3，發現xp_cmdshell已經被激活，但未從數據庫日志里面找到xp_cmdshell被調用的記錄，無法得知攻擊隊用xp_cmdshell做了什么。

在流量側對10.*.*.*3進行分析，僅發現其與10.*.*.*2（應用）有流量交互，不存在向內網擴散的行為。

2.2

向外溯源，查找入口點

之所以把對DMZ區域的攻擊過程溯源放的比較靠后，是因為該機器出現問題后一直處于斷網狀態，所以不急著分析。

2.2.1 尋找線索，發現端倪

對于10.*.*.*2的被攻擊的路徑是一點線索也沒有，所以上去先對進程、文件、定時任務、啟動項、網絡連接進行檢查，狀況如下：

（1）定時任務、進程、啟動項里面沒有駐留的后門

（2）網絡連接只有外網訪問該應用的，并沒有由內向外的C2回連（因為不出網）

（3）文件方面只發現了fscan，竟然沒有發現webshell。

此時可以說是一頭霧水，又整理了一下手里的信息：

（1）服務器處于DMZ區，向外提供服務

（2）服務是e-mobile，當時未暴出0day（ps：溯源到的第二天細節公開了）

（3）無文件落地，可能是用了內存馬（ps：不排除攻擊過程中有文件落地）

于是，使用cop對內存馬進行檢測，如下：

果然發現了內存馬，然后找到內存馬對應的java文件，如下：

根據對樣本進行分析，發現該內存馬的特征流量為返回包的set-cookie中包含eagleeye-traceid字段，對流量中包含該特征的流量進行檢索，如下：

發現兩個IP有過webshell連接的請求，隨后對兩個IP的的流量進行分析，發現兩個IP的交互都很有目標,直接就連接了webshell，未發現其進行其他攻擊操作。

然后又開始了苦逼的分析。

2.2.2 深入分析，找到過程

通過對內存馬訪問前后流量的排查，未發現直接上傳webshell的操作（服務沒shell文件，不排除內存馬植入后刪除了木馬，所以排查了webshell上傳行為）。

想到可能是直接執行代碼將內存馬加載到內存中的，搜索關鍵字loadClass，截圖如下：

從而定位到攻擊IP和加載內存馬的過程。根據攻擊IP篩選，還原整個漏洞利用過程。

漏洞為SQL注入，通過創建別名的方式執行java代碼，將內存馬的字節碼文件寫入到tmp目錄下的tmpD591.tmp中，字節碼文件較長，所以進行了多次追加寫入，然后在最后調用java.net.URLClassLoader類將tmpD591.tmp字節碼文件加載到內存中。

隨后上機排查，在tmp目錄下發現tmpD591.tmp,截圖如下：

通過對字節碼文件進行分析，發現其中包含了一個名為resin.class的字節碼文件。

通過分析代碼，證實該文件是Resion的內存馬。至此，整個溯源過程結束，跨時2天。

0x03 漏洞分析

3.1

E-moblie注入分析

當我們在為發現兩枚0day而竊喜的時候，第二天E-moblie這個漏洞就被公開了。下面是分析過程，看官們直接跳轉，不贅述了。

https://forum.butian.net/share/84

3.2

某信源SQL注入分析

找到漏洞文件，代碼如下：

通過反編譯VRV的dll文件，找到該方法的實現：

直接從request中拿到了navGuid參數，然后帶入了GetListByNavGuid方法，跟蹤該方法：

直接將參數拼接到SQL語句中產生的注入。

0x04 總結

時隔1年多，整理手中的材料時想拿出來做分享，部分過程沒有找到相對應的截圖。各位看官將就一下。站在上帝視角，回顧整個過程，頗有收獲：

（1）DMZ區的被攻破應用的數據庫就在核心區域，而且核心區域訪問關系不清晰，沒有做嚴格的分級分域，里面全部互通。如果攻擊隊通過10.*.*.*3進行資產掃描，我們早就退場了。這也給了我以后打紅隊的啟發。

（2）在分析過程中，對于漏洞攻擊過程的追求遠大于對事件影響的排查，也慶幸在甲方的督促下，我注意到了其中的重要性。

（3）關于項目開發，某信源對0day的解釋是某項目的定制需求，定制需求還放在標準產品中，顯然是審計工作不夠充分。

（4）某信源系統多個不被人關注到的賬號，都是123456這個弱密碼。這類問題不止體現在某信源，其他產品也是，所以作為防守方應該注意這些問題。

安卓逆向優質公眾號