前言
在对Windows 10进行深度挖掘并发现了一个非常有趣的绕过用户帐户控制（UAC）的方法之后（参考：https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10-using-disk-cleanup/）我决定花更多的时间来研究其他潜在的UAC绕过技术。
实现
目前,有一些公开的UAC绕过技术,其中大部分需要特权文件副本，然后使用IFileOperation COM对象或WUSA提取(Windows 7) 在一个受保护的系统位置进行DLL劫持。所有这些技术都需要向磁盘中导入一个文件(例如,将一个DLL导入到磁盘上来执行一个DLL劫持)。
公开技术参考：https://github.com/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://msdn.microsoft.com/enus/library/windows/desktop/ms724475(v=vs.85).aspx）。
由于这些hive是合并的,通常可以通过在HKCU:\Software\Classes中创建一些键来劫持HKCR:\中的键。因为在这两个hive之间存在的这种关系,所以任何能够作用到HKCU和HKCR的高权限进程都会显得特别有趣,因为它可以篡改HKCU的值。作为一个普通用户,你将访问键写入了HKCU;如果你可以操作一个高权限进程来影响这些键,那么你就可能会干扰一个高度集成的进程试图执行的行为。
现在,有些人可能知道,有一些微软签署的二进制文件可以根据它们的manifest进行自动提升（更多关于这些二进制文件和manifest的信息请参阅：https://technet.microsoft.com/en-us/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://github.com/enigma0x3/Misc-PowerShell-Stuff/blob/master/Invoke-EventVwrBypass.ps1
在这个脚本中,我们提供了一个示例命令。这个特殊的命令使用PowerShell向“C:\ UACBypassTest”中写入“Is Elevated: True”。这可以证明这个命令是在一个高权限进程中执行的，因为“Is Elevated”等于“True”，并且输出文本文件被写入的目录中阶进程没有写入权限。
总结
这种方法不同于其他公开的技术，主要是有以下几个方便的好处：
- 这种技术不需要导入传统的文件到文件系统。目前大多数开源UAC绕过技术需要引入一个文件(通常是一个DLL)到文件系统，这样做会增加攻击者被抓的风险。由于这种技术不需要导入传统的文件,攻击者的风险得到了显著减轻；
- 这种方法不需要任何进程注入,这意味着攻击不会被监控这种行为的安全解决方案标记；
- 不需要特权文件副本。大多数UAC绕过技术需要某种特权文件的副本来将一个恶意DLL复制到一个安全的位置，从而进行DLL劫持。而这种技术可以 替代“eventvwr.exe”运行时启动加载所需的管理单元,可以简单地使用现有的、受信任的微软二进制文件在内存中执行代码。
PS
又是一个bypass UAC的法子，测试通过win7 UAC默认
原文在：https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/
简单说一下就是eventvwr.exe在启动的时候会去检查注册表的command,恰好current_user 也在其中，
只是这个项目没有创建，当前用户可以通过在 HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command添加命令在用eventvwr.exe去执行就OK了，eventvwr.exe默认是过了UAC的，所以你被执行的命令也是过UAC
作者给的是powershell的poc，我也搞了个exe的，直接上代码：
