1.背景介紹

2015年1月2日，Dell Secureworks共享了一份關(guān)于利用專用域控制器（DC）惡意軟件（名為“SkeletonKey”惡意軟件）進(jìn)行高級(jí)攻擊活動(dòng)的報(bào)告，SkeletonKey惡意軟件修改了DC的身份驗(yàn)證流程，域用戶仍然可以使用其用戶名和密碼登錄，攻擊者可以使用Skeleton Key密碼作為任何域用戶登錄

(http://www.secureworks.com/cyber-threat-intelligence/threats/skeleton-key-malware-analysis/），2015?年?1?月?17?日Benjamin Delpy更新了Mimikatz使其也能進(jìn)行Skeleton Key攻擊，我們今天分析的主要內(nèi)容也就是mimikatz的misc::skeleton功能。

2.模塊詳細(xì)分析

misc::skeleton功能模塊在kuhl_m_misc.c文件中，從該c文件開頭可以看到作者定義了一個(gè)結(jié)構(gòu)體數(shù)組用來存儲(chǔ)當(dāng)前misc模塊中具體有哪些功能，該結(jié)構(gòu)體有3個(gè)成員第一個(gè)是功能函數(shù)，第二個(gè)是啟動(dòng)該功能的參數(shù)，第三個(gè)是功能描述所以我們今天要分析的skeleton在這個(gè)kuhl_m_misc_skeleton函數(shù)中啟動(dòng)命令為misc::skeleton暫無描述，可以看到其他該misc模塊是有很多功能是日常使用中也沒有用上后續(xù)可以挖掘功能

所以我們?cè)谶@個(gè)kuhl_m_misc_skeleton函數(shù)下個(gè)斷點(diǎn)當(dāng)我們執(zhí)行misc::skeleton時(shí)就可以執(zhí)行到這里開始調(diào)試，在該函數(shù)開始前還定義一個(gè)數(shù)組存儲(chǔ)了一個(gè)字符串Kerberos-Newer-Keys，這是個(gè)很重要的字符串后續(xù)用到的時(shí)候詳細(xì)解釋

?

可以看到函數(shù)開始定義了很多變量,可以看到extensions結(jié)構(gòu)體初始化了一些值，我們查看一下這個(gè)結(jié)構(gòu)體可以發(fā)現(xiàn)該結(jié)構(gòu)體成員有4個(gè)從名稱大概可以猜出來分別為模塊，功能，替換的值，指針，這樣我們大概就可以這個(gè)結(jié)構(gòu)體數(shù)組是什么了第一個(gè)結(jié)構(gòu)體就是模塊是kernel32.dll，localAlloc函數(shù)，替換的值為0X4a4a4a4a4a,指針為NULL，從現(xiàn)在來看這個(gè)結(jié)構(gòu)體大部分內(nèi)容是沒意義的還有很多為NULL的

接下來又定義了一個(gè)結(jié)構(gòu)體exforcb來存儲(chǔ)extensions以及extensions的大小，判斷當(dāng)前Mimikatz的版本號(hào)是否小于vista系統(tǒng)的版本號(hào)這里我們的軟件版本11是大于宏定義的visita系統(tǒng)5000的或者傳入命令參數(shù)是否有l(wèi)etaes我們這里傳入的是misc::skeleton所以兩個(gè)判斷都不為真onlyRC4Stuff為0?這樣也才能進(jìn)入下面的功能操作。接著利用RtlZeroMemory函數(shù)初始化orig結(jié)構(gòu)體填充0

接下來用RtlInitUnicodeString函數(shù)計(jì)算出Kerberos-Newer-Keys字符串的長(zhǎng)度并將該字符串以及長(zhǎng)度保存在orig結(jié)構(gòu)體中

接下來傳入lsass.exe到kull_m_process_getProcessIdForName函數(shù)中用來獲取lsass進(jìn)程的pid，該函數(shù)主要通過NtQuerySystemInformationAPI函數(shù)來獲取

接下來利用openprocess函數(shù)傳入開始lsass進(jìn)程的pid來獲取lsass進(jìn)程的句柄，然后將KULL_M_MEMORY_TYPE_PROCESS,lsass進(jìn)程的句柄，&alsass.hmemory傳入kull_m_memory_open函數(shù)中，alsass也是kuhl_m_misc_skeleton函數(shù)一開始定義的結(jié)構(gòu)體里面有2個(gè)成員一個(gè)存儲(chǔ)地址的指針，另一個(gè)成員又是一個(gè)結(jié)構(gòu)體主要表示當(dāng)前句柄的類型或者內(nèi)存的屬性

跟進(jìn)這個(gè)函發(fā)現(xiàn)會(huì)根據(jù)傳入的參數(shù)走KULL_M_MEMORY_TYPE_PROCESScase該函數(shù)主要就是給alsass.hmemory結(jié)構(gòu)體賦值

接下來由于onlyRC4Stuff為0所以可以進(jìn)入里面的流程我們看到kull_m_process_getVeryBasicModuleInformationsForName傳入了3個(gè)參數(shù)開始的alsass.hmemory，kdscsvc.dll字符串，和另一個(gè)cryptinfos結(jié)構(gòu)體的引用這個(gè)結(jié)構(gòu)體主要是一個(gè)存儲(chǔ)模塊的基礎(chǔ)信息成員有模塊基地址，模塊大小，時(shí)間戳，沒有公開的函數(shù)

跟進(jìn)函數(shù)其實(shí)該函數(shù)主要是通過kull_m_process_getVeryBasicModuleInformations函數(shù)獲取kdscsvc.dll的詳細(xì)信息，kull_m_process_callback_moduleForName是個(gè)回調(diào)函數(shù)主要是用結(jié)構(gòu)體賦值的

進(jìn)入函數(shù)主要是跟內(nèi)存屬性走不同case通過peb和ldr遍歷進(jìn)程的模塊來獲取kdscsvc.dll的詳細(xì)信息

?

?

跟進(jìn)kull_m_process_peb函數(shù)可以看到根據(jù)不同內(nèi)存屬性來走對(duì)應(yīng)的case獲取peb信息，這里是通過NtQueryInformationProcessAPI獲取

由于VS是3環(huán)調(diào)試器無法讀取到內(nèi)核的信息，我們可以搭建雙機(jī)調(diào)試使用windbg讀取一下0x0000008f85514000PEB結(jié)構(gòu)體信息

函數(shù)最開始有定義一個(gè)結(jié)構(gòu)體來存儲(chǔ)peb相關(guān)信息，使用kull_m_memory_copy函數(shù)根據(jù)不同的內(nèi)存屬性調(diào)用不同的內(nèi)存拷貝函數(shù)這里調(diào)用的ReadProcessMemory函數(shù)

主要是利用PEB找到ldr以及雙向鏈表InLoadOrderModuleList來遍歷lsass進(jìn)程模塊找到kdcsvc.dll

?

可以看到確實(shí)獲取到了kdcsvc.dll的模塊信息并把信息存儲(chǔ)在cryptInfos結(jié)構(gòu)體中

接下來將Kerberos-Newer-Keys字符串指針傳遞給alocal結(jié)構(gòu)體中，剛剛獲取到kdcsvc.dll的基地址以及dll的大小傳遞到smemory結(jié)構(gòu)體中這兩個(gè)結(jié)構(gòu)體的屬性見下圖也是函數(shù)開始定義的，將2個(gè)結(jié)構(gòu)體以及字符串長(zhǎng)度傳入kull_m_memory_search函數(shù)中

跟進(jìn)這個(gè)函數(shù)首先定義了一個(gè)跟參數(shù)search一樣的結(jié)構(gòu)體并把屬性定義為了KULL_M_MEMORY_GLOBAL_OWN_HANDLE這個(gè)結(jié)構(gòu)體存的是KULL_M_MEMORY_TYPE_OWN屬性，這里因?yàn)橄旅媪鞒谈鶕?jù)參數(shù)里面的內(nèi)存屬性走了KULL_M_MEMORY_TYPE_PROCESScase然后作者就使用kull_m_memory_copy函數(shù)（里面跟進(jìn)內(nèi)存屬性走對(duì)應(yīng)的case這里使用了ReadProcessMemory函數(shù)拷貝）將search結(jié)構(gòu)體內(nèi)容都拷貝自己定義的sbuffer結(jié)構(gòu)體中然后又再次調(diào)用kull_m_memory_search函數(shù)進(jìn)入這個(gè)函數(shù)由于sbuffer結(jié)構(gòu)體成員屬性作者定義為了KULL_M_MEMORY_TYPE_OWN所以會(huì)走KULL_M_MEMORY_TYPE_OWN的case

進(jìn)入KULL_M_MEMORY_TYPE_OWNcase后利用for循環(huán)從kdcsvc.dll的首地址2c28dde0080開始查找Kerberos-Newer-Keys字符串，由于最后匹配上之后繼續(xù)執(zhí)行了一次curentPtr++后續(xù)通過currentptr--調(diào)整回來指向kdcsvc.dll中Kerberos-Newer-Keys字符串的正確地址

由于search結(jié)構(gòu)體中存儲(chǔ)了kdcsvc.dll內(nèi)容但是沒辦法直接在其內(nèi)存中搜索字符串將其拷貝到sbuffer后然后在sbuffer中找到Kerberos-Newer-Keys字符串并計(jì)算其偏移再加上kdcsvc.dll真實(shí)的首地址就獲得了該字符串的真實(shí)偏移通過windbg中查詢數(shù)據(jù)可以看到

所以到這里kull_m_memory_search目的就是找Kerberos-Newer-Keys字符串在kdcsvc.dll中的位置。

kdcsvc.dll是windowsserver系統(tǒng)上才有的dll文件如果是域控服務(wù)器的話lsass進(jìn)程會(huì)加載該dll作為kdc服務(wù)來頒發(fā)票據(jù)

ntds.dit數(shù)據(jù)庫文件有個(gè)補(bǔ)充憑證（supplementalCredentials）屬性該屬性中又包含了Kerberos-Newer-Keys屬性存儲(chǔ)了明文密碼的加密hash，kerberos-Newer-Keys可以設(shè)置各種加密屬性比如AES加密的話會(huì)涉及salt參加加密，但是RC4-HMAC加密就不涉及salt了。Kerberos新的加密類型（如AES）會(huì)要求將salt字符串（通常是用戶名）添加到密鑰派生函數(shù)中，要使不同用戶的密碼相同，需要?jiǎng)?chuàng)建不相同的加密密鑰。如果攻擊者要支持AES加密的話需要離線計(jì)算并存儲(chǔ)所有域用戶的密鑰，這需要大量?jī)?nèi)存；或?qū)崟r(shí)計(jì)算相關(guān)用戶的密鑰，這可能會(huì)導(dǎo)致DC的性能問題，但RC4-HMAC不涉及salt,所有用戶的骨架RC4-HMAC密鑰不變，所以攻擊者一般會(huì)采取RC4-HMAC加密

其中在WIN2008及其更新的版本中必須創(chuàng)建一個(gè)KERB_STORED_CREDENTIAL_NEW結(jié)構(gòu)體。然后必須將此值?與屬性名稱“Primary:Kerberos-Newer-Keys”一起放置在USER_PROPERTY結(jié)構(gòu)中才能放在補(bǔ)充憑據(jù)中使用，USER_PROPERTY如下圖

由于USER_PROPERTY結(jié)構(gòu)體中包含了Kerberos-Newer-Keys字符串所以接下來又通過kull_m_memory_search函數(shù)從kdcsvc.dll中搜索該結(jié)構(gòu)體的位置

0x7ffa33072b60就存儲(chǔ)了該USER_PROPERTY結(jié)構(gòu)體,其中屬性名稱是7ffa33066a8指向Kerberos-Newer-Keys字符串

接下來通過rtlzeromemory函數(shù)將orig結(jié)構(gòu)體置0然后通過kull_m_memory_copy函數(shù)將kdcsvc.dll中的USER_PROPERTY結(jié)構(gòu)體也置0了

調(diào)用writeprocessmemory函數(shù)將7ffa33072b60地址處16字節(jié)的數(shù)據(jù)置0

數(shù)據(jù)拷貝后內(nèi)存值可以看到Kerberos-Newer-Keys包沒有了這樣就可以保證沒辦法使用帶salt的AES加密方法了

我們可以通過ida打開kdcsvc.dll查看具體的Kerberos-Newer-Keys包的使用細(xì)節(jié)發(fā)現(xiàn)是SamIRetrieveMultiplePrimaryCredentials函數(shù)調(diào)用的

?

由于SamIRetrieveMultiplePrimaryCredentials函數(shù)是samsrv.dll的導(dǎo)出函數(shù)所以想知道具體的返回值我在samsrv.dll中進(jìn)行了分析SampExtRetrieveMultiplePrimaryCredentialsDs是其主要實(shí)現(xiàn)

我們跟進(jìn)函數(shù)然后發(fā)現(xiàn)SampLoadDsExtensionDll函數(shù)繼續(xù)跟進(jìn)分析

發(fā)現(xiàn)該函數(shù)會(huì)查詢注冊(cè)表是否有DirectoryServiceExtPt值我的域控是2016的看了一下沒有這個(gè)值

接下來會(huì)繼續(xù)嘗試加載該文件由于沒有所以走下面的else返回0xc00000BB

通過微軟官方文檔查詢報(bào)錯(cuò)值發(fā)現(xiàn)是不支持該請(qǐng)求類型的錯(cuò)誤STATUS_NOT_SUPPORTED，keberos認(rèn)證流程中客戶端會(huì)在AS-REQ中聲明自己支持的所有加密類型etype，域控會(huì)并檢查客戶端是否支持AES如果客戶端支持則域控會(huì)在AS-REP的PA-ETYPE-INFO2中響應(yīng)對(duì)應(yīng)的加密方式。但如果客戶端支持的加密類型中有AES，但DC并沒有回應(yīng)對(duì)應(yīng)的AES加密類型，并且報(bào)錯(cuò)類型是STATUS_NOT_SUPPORTED很大可能受到了skeleton攻擊

?

我這里測(cè)了一下skeleton攻擊并抓取了流量包，客戶端發(fā)送的AS-REQ請(qǐng)求存在AES加密

但是域控的響應(yīng)中卻沒有AES加密同時(shí)確實(shí)是報(bào)錯(cuò)STATUS_NOT_SUPPORTED

我們繼續(xù)看下kdcsvc.dll的流程在域控通過kdcgetuserskey函數(shù)接收到用戶的密碼后不單單是會(huì)走SamIRetrieveMultiplePrimaryCredentials函數(shù)同時(shí)會(huì)將密碼傳遞給kerbhashpassword函數(shù)最終調(diào)用cryptdll.dll的導(dǎo)出函數(shù)CDLocateCSystem選擇對(duì)應(yīng)的加密系統(tǒng)對(duì)用戶傳入的憑據(jù)進(jìn)行處理

接下來就可以看到mimikatz繼續(xù)利用kull_m_process_getVeryBasicModuleInformationsForName函數(shù)也是通過pebldr從lsass進(jìn)程中獲取cryptdll.dll的模塊信息，同時(shí)獲取了該dll的句柄保存在localaddr中

然后通過CDLocateCSystem函數(shù)找到RC4類型的加密系統(tǒng)存儲(chǔ)在pCrypt結(jié)構(gòu)體中，可以看到該加密類型的一系列函數(shù)存儲(chǔ)在結(jié)構(gòu)體中

接下來給最開始定義的extensions賦值，將cryptdll.dll!rc4HmacInitialize，cryptdll.dll!rc4HmacDecrypt函數(shù)地址傳入

接下來kull_m_remotelib_CreateRemoteCodeWitthPatternReplace函數(shù)中傳入了幾個(gè)函數(shù)名其實(shí)是傳入函數(shù)的地址

?

?

第一個(gè)參數(shù)是lsass進(jìn)程的內(nèi)存屬性，第二個(gè)是rc4_init函數(shù)的地址，第三個(gè)參數(shù)rc4_end函數(shù)地址-rc4_init函數(shù)地址代表的是rc4_init到rc4_end之間的內(nèi)存內(nèi)容其實(shí)這塊空間包含了init函數(shù)decrypt兩塊函數(shù)內(nèi)容，第四個(gè)參數(shù)是存儲(chǔ)extensions的結(jié)構(gòu)體指針，第五個(gè)參數(shù)是lsass進(jìn)程的指針

跟進(jìn)后首先通過kull_m_remotelib_GetProcAddressMultipleModules函數(shù)這個(gè)函數(shù)主要也是調(diào)用kull_m_process_getVeryBasicModuleInformations函數(shù)通過PEBldr獲取模塊信息，給RemoteExt結(jié)構(gòu)體也就是extensions結(jié)構(gòu)體數(shù)組填充對(duì)應(yīng)的值

可以看到被填充后的數(shù)據(jù)如下

這里是新創(chuàng)了個(gè)空間aLocalAddr大小跟rc4_end-rc4_init函數(shù)地址相距的大小一致,并把rc4_end-rc4_init函數(shù)地址內(nèi)存的內(nèi)容拷貝到新空間中，并將extensions[j].ToReplace的值在該空間中查找其對(duì)應(yīng)的位置，后續(xù)用extensions[j].Point的值替換該值

我們可以看到rc4_init函數(shù)到rc4_end函數(shù)內(nèi)存空間中還有rc4_init_decrypt函數(shù)其中rc4_init函數(shù)與rc4_decrypt函數(shù)中有很多函數(shù)不過名字為0x4a4a這種一串奇怪的數(shù)字，同時(shí)我們前面被填充好的extensions結(jié)構(gòu)體數(shù)組也存在這些奇怪的數(shù)字并且存在正常的模塊名稱及其對(duì)應(yīng)的函數(shù)名以及函數(shù)對(duì)應(yīng)的地址，就是通過內(nèi)存搜索這些特殊字符然后進(jìn)行對(duì)應(yīng)的替換。

?

替換后這些函數(shù)內(nèi)容應(yīng)該是這樣的

該空間內(nèi)存內(nèi)容替換為正常的函數(shù)內(nèi)容后使用kull_m_memory_alloc函數(shù)在lsass進(jìn)程中開辟了一塊可讀可寫可執(zhí)行的內(nèi)存空間并且大小也是函數(shù)rc4_int到函數(shù)rc4_end內(nèi)存空間的大小并通過kull_m_memory_copy函數(shù)將該內(nèi)容拷貝lsass進(jìn)程中拷貝到新開辟的空間中

可以看到下圖左邊是lsass進(jìn)程中新開辟的內(nèi)存空間的內(nèi)容與我們之前函數(shù)空間的內(nèi)容一致。新開辟的地址是000001f3`d4fb0000

所以函數(shù)kull_m_remotelib_CreateRemoteCodeWitthPatternReplace主要的目的就是將rc4_int,rc4_decrypt函數(shù)修復(fù)后將代碼注入到lsass空間中，后續(xù)通過kull_M_memory_copy函數(shù)將原地址7ffa3cabf628指向的是cryptdll!rc4HmacInitialize函數(shù)的指針替換為了0xc79bcdfd88地址中存儲(chǔ)的8字節(jié)的值也就是01f3d4fb0000,這塊地址指向的我們自己定義的kuhl_misc_skeleton_rc4_init函數(shù)的地址也就是hook了原始的rc4HmacInitialize函數(shù)

從下圖可以看到該地址處替換前地址是00007ffa3cab84c0，右側(cè)為替換后

?

原始的RC4_init函數(shù)被hook后，后續(xù)又開始計(jì)算自己定義的rc4_decrypt函數(shù)相較于rc4_init函數(shù)的偏移，然后ptrValue加上偏移就是指向我們自定義rc4_decrypt函數(shù)的地址指針,aLsass.address也通過偏移計(jì)算得到lsass進(jìn)程中原始的rc4_decrypt函數(shù)的地址的指針，然后通過kull_m_memory_copy函數(shù)將我們的rc4_decrypt函數(shù)替換掉原始的

可以看到又是調(diào)用WriteProcessMemory函數(shù)將原地址7ffa3cabf638指向的是cryptdll!rc4HmacDecrypt函數(shù)的指針替換為了0xc79bcdfc20地址中存儲(chǔ)的8字節(jié)的值也就是01f3d4fb016c,這塊地址指向的我們自己定義的kuhl_misc_skeleton_rc4_init_decrypt函數(shù)的地址也就是hook了原始的rc4HmacDecrypt函數(shù)

從下圖我們可以看到hook前的情況7ffa3cabf638存的是原始的rc4HmacDecrypt函數(shù)

到這里skeleton模塊函數(shù)已經(jīng)全部分析完，接下來我們來分析一下我們自定義的rc4初始化函數(shù)，在rc4init函數(shù)中首先有個(gè)kiwiKey數(shù)組我們的認(rèn)證都是傳輸?shù)膆ash這個(gè)數(shù)組正好也是32位很有可能就是skeleton的默認(rèn)密碼mimikatz的hash?通過計(jì)算mimikatz的hash發(fā)現(xiàn)這里確實(shí)就是存的skeleton的密碼hash

?

通過LocalAlloc分配了內(nèi)存指向pContext,將Key(用戶的輸入的原始密碼hash的地址)傳入rc4HmacInitialize函數(shù)中生成原始密碼的秘鑰流完成后續(xù)的rc4加密解密的操作，將生成的秘鑰流拷貝到開始分配的空間中大小為16字節(jié)，接著將kiwiKey(mimikatz字符串的hash)傳入rc4HmacInitialize函數(shù)中生成mimikatz的秘鑰流，接著又繼續(xù)拷貝到開始分配的空間中大小為16字節(jié)，最后將原始的密碼hash地址Key也拷貝到pContext空間中

我們給rc4HmacInitialize函數(shù)下斷點(diǎn)域控輸入net use \\win2016\c$/user:"test.com\administrator" "mimikatz"，斷下來后我們執(zhí)行完*(LPCVOID *) ((PBYTE) *pContext + 32)= Key這段代碼就可以看到pContext存儲(chǔ)的內(nèi)容了也就是上圖反匯編中rax指向的地址，我們查看dq rax?第一排是原始密碼生成的秘鑰流，第二排是mimikatz生成的秘鑰流，第三排前8字節(jié)是我們輸入的原始密碼hash的地址查看該地址的內(nèi)容發(fā)現(xiàn)就是mimikatz的hash，這里由于我們的原始密碼輸入的就是mimikatz所以第一排第二排的秘鑰流一致。

由于rc4的對(duì)稱算法加密與解密是一致的都是用上面的秘鑰流，解密函數(shù)中傳入了開始init函數(shù)中的pContext以及被加密的數(shù)據(jù)，首先函數(shù)里面也是先分配了一段空間buffer，將待解密的數(shù)據(jù)拷貝到buffer中，將buffer以及pContext傳入rc4HmacDecrypt函數(shù)中進(jìn)行解密，這里是利用第一次的秘鑰流解密如果解密成功的話就返回了,如果解密失敗會(huì)再次調(diào)用rc4HmacDecrypt函數(shù)使用第二次我們?cè)O(shè)置的mimikatz生成的秘鑰流解密如果成功就會(huì)改變pContext存在的原始Key改成我們?cè)O(shè)置的kiwikey的值，這樣的方式就保證了我們無論是輸入正確的密碼還是我們?cè)O(shè)置的kiwikey來走rc4初始化加密解密流程都是可以通過的。

?

?

自定義kiwikey:zhuzhuxiaoba重新編譯后認(rèn)證成功，不過當(dāng)前的mimikatz的skeleton萬能密碼只支持kerberos流程，其實(shí)在ntlm認(rèn)證流程中也是可以實(shí)現(xiàn)萬能鑰匙的早期的萬能鑰匙的惡意樣本就是這樣操作的。通過在MSV1_0.dll中定位函數(shù)MsvpSamValidate，MsvpSamValidate函數(shù)中有一個(gè)對(duì)MsvpPasswordValidate函數(shù)的調(diào)用，通過hook該函數(shù)，同樣的可以實(shí)現(xiàn)萬能密碼的功能。github上有個(gè)類似的利用筆者在win10系統(tǒng)上測(cè)了一下確實(shí)可以利用，不過在server上未能復(fù)現(xiàn)

?

3.防御方案

?

由于該攻擊是對(duì)lsass進(jìn)程進(jìn)行了注入， 從Windows 8.1（和Server 2012 R2）開始，Microsoft引入了一項(xiàng)稱為L(zhǎng)SA保護(hù)的功能。此功能基于PPL技術(shù)，它是一種縱深防御的安全功能，旨在“防止非管理員非PPL進(jìn)程通過打開進(jìn)程之類的函數(shù)串改PPL進(jìn)程的代碼和數(shù)據(jù)”。防止對(duì)進(jìn)程lsass.exe 的代碼注入，這樣一來就無法使用 mimikatz 對(duì) lsass.exe 進(jìn)行注入，相關(guān)操作也會(huì)失敗。在注冊(cè)表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

添加RunAsPPL=dword:00000001，重啟就可以開啟了PPL保護(hù)了

?

開啟后mimikatz注入lsass進(jìn)程的行為將會(huì)失敗，雖然mimikatz后面又增加了一個(gè)mimidrv.sys驅(qū)動(dòng)來繞過PPL保護(hù)，但是加載驅(qū)動(dòng)這一行為已經(jīng)有明顯的日志可以供我們進(jìn)行檢測(cè)。

windows日志4697記錄了mimidrv.sys驅(qū)動(dòng)的安裝

sysmon日志13可以很明顯看到mimidrv服務(wù)以及對(duì)應(yīng)的驅(qū)動(dòng)程序

我們可以使用zBang 工具掃描當(dāng)前的域控環(huán)境是否已經(jīng)被注入了萬能密碼。
（https://github.com/cyberark/zBang），因?yàn)镾keleton Key 是注入惡意代碼到 lsass.exe 進(jìn)程的，所以它只存在于內(nèi)存中，如果域控制器重啟，注入的 Skeleton Key 將會(huì)失效。