在對Windows 10進行深入挖掘並發現了一個非常有趣的繞過用戶帳戶控制(UAC)的方法之後(詳細信息請參閱https:/bypassing-uac-on-windows-10-using-disk-cleanup/),我決定花更多的時間來調查其他潛在的UAC繞過技術。目前,有一些開源的UAC繞過技術,其中大部分需要特權文件副本，然後使用IFileOperation COM對象或WUSA提取(Windows 7) 在一個受保護的系統位置進行DLL劫持。所有這些技術都需要向磁盤中導入一個文件(例如,將一個DLL導入到磁盤上來執行一個DLL劫持)。你可以在下面這個網址查看這些開源技術https:/hfiref0x/UACME。這篇文章中提到的技術不同於其他開源方法，而是提供了一個有用的新技術,它不依賴於特權文件副本,代碼注入,或者在磁盤上放置一個傳統的文件(如DLL)。這種技術已經在Windows 7和Windows10上進行了測試,但希望以後能夠在所有實施UAC的Windows版本上運行。
跟我在上篇文章中提到過的使用磁盤清理繞過UAC技術一樣,探查Windows加載方式的一個普遍的技術是使用進程監視器分析進程執行時的行爲。然而繼續挖掘，在用ProcMon打開Windows事件日誌時,我注意到，作爲一個高階進程，eventvwr.exe執行了一些關於HKEY_CURRENT_USER hive的註冊表查詢。
很早之前,理解HKEY_CLASSES_ROOT(HKCR)和HKEY_CURRENT_USER(HKCU)註冊表項以及它們之間是如何相互作用的就是很重要的。HKCR僅僅是HKLM:\Software\Classes和HKCU:\Software\Classes的組合(想要了解什麼是HKCR以及爲什麼HKLM和HKCU要進行合併，請點擊下面的鏈接https:/library/windows/desktop/ms724475(v=vs.85).aspx)。由於這些hive是合併的,通常可以通過在HKCU:\Software\Classes中創建一些鍵來劫持HKCR:\中的鍵。因爲在這兩個hive之間存在的這種關係,所以任何能夠作用到HKCU和HKCR的高階進程都會顯得特別有趣,因爲它可以篡改HKCU的值。作爲一個普通用戶,你將訪問鍵寫入了HKCU;如果你可以操作一個高階進程來影響這些鍵,那麼你就可能會干擾一個高度集成的進程試圖執行的行爲。
現在,有些人可能知道,有一些微軟簽署的二進制文件可以根據它們的manifest進行自動提升(更多關於這些二進制文件和manifest的信息請參閱：https:/magazine/2009.07.uac.aspx)。通過使用系統工具“sigcheck”,我證實了“eventvwr.exe”使用它的manifest進行了自動提升：
深入瞭解ProcMon輸出的時候,我注意到“eventvwr.exe”與HKCU\Software\Classes\mscfile\shell\open\command進行了交互,這導致了一個“NAME NOT FOUND”的結果。不久,eventvwr.exe又與HKCR\mscfile\shell\open\command的鍵進行了交互。當我查看HKCR\mscfile\shell\open\command時,我注意到默認值被設置爲調用mmc.exe(微軟管理控制檯程序),這個程序負責加載管理Snap-Ins：
如前所述, 一個高階進程調用HKEY_CURRENT_USER (or HKCU)是十分有趣的。這通常意味着一個提升的進程與註冊表的位置進行交互，而這個地方一箇中階進程就可以進行篡改。在這種情況下,我觀察到“eventvwr.exe”在HKCR\mscfile\shell\open\command之前查詢HKCU\Software\Classes\mscfile\shell\open\command。由於HKCU返回值爲“NAME NOT FOUND”,所以這個提升進程開始查詢HKCR的位置：
從輸出可以看到, 作爲一個高階進程，“eventvwr.exe”在查詢了HKCU和HKCR的註冊表hive之後調用了mmc.exe。mmc.exe執行之後,它打開了eventvwr.msc,這是一個微軟保存控制檯文件,導致事件查看器進行顯示。這看起來合乎常理，因爲微軟管理控制檯(mmc.exe)裝載的是微軟保存控制檯文件(.msc)。
根據這些信息,我決定創建一個“eventvwr.exe”所需的註冊表結構來成功查詢HKCU的位置而不是HKCR的位置。既然位於HKCR\mscfile\shell\open\command的默認值包含一個可執行文件,我決定只是用powershell.exe來替換這個可執行文件:
當“eventvwr.exe”運行的時候,我注意到它成功查詢/打開了HKCU\Software\Classes\mscfile\shell\open\command：
這一行動有效地用我們的新值“powershell.exe”替代了之前的“mmc.exe”值。隨着進程的繼續,我觀察到它最終調用了“powershell.exe”而不是“mmc.exe”:
查看進程管理工具,我能夠確認powershell.exe確實在以高階權限運行：
由於能夠劫持進程的啓動,所以簡單地執行你希望的任何惡意PowerShell腳本/命令都是可行的。這意味着代碼可以在一個高階進程中執行(繞過UAC)，並且沒有向文件系統中導入DLL或任何其它文件。這會顯著減少攻擊者的風險,因爲他們不用把傳統的文件導入到文件系統中,而這正是最容易被AV/HIPS檢測到的。
爲了演示這種攻擊, Matt Graeber和我構造了一個PowerShell腳本,在系統上執行的時候,會在當前用戶的hive中創建所需的註冊表項 (HKCU\Software\Classes\mscfile\shell\open\command),設置默認值爲任何你想通過command參數傳遞的值,運行“eventvwr.exe”，然後清理註冊表條目。
你可以在下面的鏈接找到這個腳本:https://*******Misc-PowerShell-Stuff/blob/master/Invoke-EventVwrBypass.ps1
在這個腳本中,我們提供了一個示例命令。這個特殊的命令使用PowerShell向“C:\ UACBypassTest”中寫入“Is Elevated: True”。這可以證明這個命令是在一個高階進程中執行的，因爲“Is Elevated”等於“True”，並且輸出文本文件被寫入的目錄中階進程沒有寫入權限。
總結及應對措施
這種方法不同於其他的開源技術，主要是有以下幾個非常方便的好處：
1.這種技術不需要導入傳統的文件到文件系統。目前大多數開源UAC繞過技術需要引入一個文件(通常是一個DLL)到文件系統，這樣做會增加攻擊者被抓的風險。由於這種技術不需要導入傳統的文件,攻擊者的風險得到了顯著減輕;
2.這種方法不需要任何進程注入,這意味着攻擊不會被監控這種行爲的安全解決方案標記;
3.不需要特權文件副本。大多數UAC繞過技術需要某種特權文件的副本來將一個惡意DLL複製到一個安全的位置，從而進行DLL劫持。而這種技術可以替代“eventvwr.exe”運行時啓動加載所需的管理單元,可以簡單地使用現有的、受信任的微軟二進制文件在內存中執行代碼。
應對措施：
1.將UAC的級別設置爲“總是通知”;
2.從本地管理員羣組中刪除當前用戶;
3.可以利用這種方法的特徵監測這種攻擊：查找HKCU\Software\Classes\中的註冊表項，或者在HKCU\Software\Classes\中創建新註冊表項。