UAC（User Account Control，用户帐户控制）是微软公司为了提高Windows系统安全性而在 Windows Vista 中引入的一种新型安全技术，它要求用户在执行某些可能会影响计算机运行的操作或更改其他用户设置的操作之前，向系统申请权限或提供管理员‌密码。通过在这些操作启动前对其进行验证，UAC 可以帮助防止恶意软件和间谍软件在未经许可的情况下在计算机上进行安装或对计算机进行更改。

用户账户

Windows 中有多种不同的账户，包括：

完整性级别表示正在运行的应用程序进程和对象的可信度。它使文件系统能够使用预定义的策略来阻止较低完整性级别的进程读取或修改较高完整性的对象。从 Windows Vista 开始，进程在创建的时候，可以得到一个访问令牌（Access Token），令牌有四个完整性级别：

对应关系如下：

System 令牌是对系统完全操作的令牌，对应 SYSTEM，拥有的最高权限。提升的应用程序以 High 完整性级别运行，普通进程以 Medium 完整性级别运行，低权限进程以 Low 完整性级别运行

在 Administrators 组中，Administrator 账户和普通管理员账户要分开说。普通管理员账户下，正常启动进程使用的是继承自 explorer.exe 的 Medium 访问令牌，当进程需要提升权限时，会弹出 UAC 提示框来启动一个子进程以获得 High 令牌。而 Administrator 账户下，正常启动的进程也都获得了 High 令牌

Users 组的用户没有 High 和 System 令牌，如果要权限提升，需要输入管理员账号密码，而这时拿到的是这个管理员账号的 High 令牌

例：直接运行 CMD 和以管理员权限运行 CMD 的进程完整性级别分别为 Medium 和 High。

更多资料：

https://blog.walterlv.com/post/windows-user-account-control.html

https://blog.walterlv.com/post/requested-execution-level-of-application-manifest

那进程如何获得 High 令牌呢？UAC 提示流程又是什么样子的？

AIS 服务：处理提升请求

当出现提升程序的请求时，AIS (appinfo.dll) 将进行校验程序是否满足提升的条件，主要看一下 AiIsEXESafeToAutoApprove 函数。以下 2 种情况可能不需要弹 UAC 对话框自动提升至管理员权限：

1、程序配置为自动提升

如果程序中配置了 autoElevate 为 true，会尝试自动提升

2、白名单

判断要执行的程序是否属于白名单，在白名单之内就调用 AipIsValidAutoApprovalEXE 函数检查程序签名等信息，如果不在就基本结束这个函数了

白名单列表：

'cttunesvr.exe'、'inetmgr.exe'、'migsetup.exe'、'mmc.exe'、'oobe.exe'、'pkgmgr.exe'、'provisionshare.exe'、'provisionstorage.exe'、'spinstall .exe'，'winsat.exe'

满足这两个条件的情况可能会直接提升，先看看配置了 autoElevate 的程序。

这里有个熟悉的程序：任务管理器（Taskmgr.exe），以 High 级别运行，仔细回忆一下，启动任务管理器的过程中并没有出现 UAC 弹窗：

manifest（清单）是伴随并描述并行程序集或独立应用程序的 XML 文件。清单通过程序集的 assemblyIdentity 元素唯一标识程序集。它们包含用于绑定和激活的信息，例如 COM 类、接口和类型库，这些信息传统上存储在注册表中。以下为使用命令 mt -inputresource:Taskmgr.exe;#1 -out:taskmgr.manifest 从 Taskmgr.exe 中提取出的 manifest 文件：

但如果将 Taskmgr.exe 复制到桌面，直接运行该程序，就会发现还是会出现 UAC 弹窗。这又引出自动提升程序需要满足的一个关键条件：从受信任目录执行。无论是 manifest 文件中设置了 autoElevate true，还是白名单列表判断，都需要 v13 的第 0x16 个比特位（index 从 0 开始计算）为 1 才行，这是一个前置条件。

v13 中的值从 a4 中取到，我们可以看一下它（AiIsEXESafeToAutoApprove）的上层函数 RAiLaunchAdminProcess，在下面的逻辑里会将目标程序字符串和 g_IncludedSysDir 进行比较，利用 RtlPrefixUnicodeString 和 wcschr 函数来判断目标程序是否在 \??\C:\Windows\System32\ 或 \??\C:\Windows\SysWow64\ 目录下，这两个目录是受信任的目录，如果满足条件，才会设置 flag 的第 0x16 个比特位（0x200000）。

不过还有两种特殊情况，是 g_IncludedXmtExe 中存储的 \??\C:\Windows\System32\Sysprep\sysprep.exe 以及 \??\C:\Windows\System32\inetsrv\InetMgr.exe，如果是这两个路径下的程序，且通过 AipMatchesOriginalFileName 函数检查（通过比较文件版本信息里的 OriginalFilename 来判断程序名字是否更改过），即使它们不是直接位于 System32 或 SysWow64 目录下，也会跳转到 LABEL_364 标签，设置 flag 的第 0x16 个比特位。

文件版本信息（以 sysprep.exe 为例）：

处理示例：https://docs.microsoft.com/en-us/windows/win32/api/winver/nf-winver-verqueryvaluea

按照目前的逻辑，我们的程序从受信任目录执行，且配置了 autoElevate 为 true，就可以进入第一种流程。先编写一个简单的程序，比如弹个 CMD，使用 VS 编译程序的时候加入 manifest，指定 requireAdministrator 级别，表示需要获得权限提升，如下：

使用命令 mt -inputresource:test.exe;#1 -out:test.manifest 从 Taskmgr.exe 中提取 manifest 文件，加入 autoElevate 后使用：

加入 manifest：mt.exe -manifest test.manifest -outputresource:test.exe;1，好的，果然失败了：

虽然程序在 AiIsEXESafeToAutoApprove 函数校验中通过了，但在后续传递给 consent.exe 程序进行处理的过程中出现了问题，还是需要再分析一下~ 下次一定

——————————————— 分界线 ———————————————

下面开始介绍成熟的 Bypass 技巧

一、通过注册表劫持 Bypass UAC

参考：https://medium.themayor.tech/utilizing-a-common-windows-binary-to-escalate-to-system-privileges-c16482cced4b

目标程序：Fodhelper

注册表键值：HKCU\Software\Classes\ms-settings\shell\open\command

利用思路：添加注册表键值 HKCU\Software\Classes\ms-settings\shell\open\command，设置其 value 为需要执行的程序路径或命令；添加 HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute（修改 HKCU 下的键值只需要普通用户权限）。这样程序启动后会执行 HKCU\Software\Classes\ms-settings\shell\open\command 中的内容，从而绕过 UAC 弹窗

简单分析：

可以发现，fodhelper.exe 在 manifest 中配置了 autoElevate 为 True，并且运行之后没有弹窗。

使用 ProcessMonitor 监控，发现程序确实去访问 HKCU\Software\Classes\ms-settings\shell\open\command，不过默认情况下这个键值是不存在的，仔细看前面记录会发现 HKCU\Software\Classes\ms-settings 也是不存在的。

先创建 HKCU\Software\Classes\ms-settings\shell\open\command 项：

然后再次监控 fodhelper 运行，如果存在 HKCU\Software\Classes\ms-settings\shell\open\command，还会去查询 HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute

同样，再创建 HKCU\Software\Classes\ms-settings\shell\open\command\DelegateExecute 试一下：

可以发现，程序在成功查询到 HKCU\Software\Classes\ms-settings\shell\open\command\DelegateExecute 后会去查询 HKCU\Software\Classes\ms-settings\shell\open\command\command 或 HKCU\Software\Classes\ms-settings\shell\open\command\(Default)，事实证明它们是一样的

这里我们来设置 HKCU\Software\Classes\ms-settings\shell\open\command\command 吧，将其设置为 cmd.exe。嗯。。。Defender 会检测到，但可以写入注册表，虽然过一会儿就被删了

不过，利用这段时间启动 fodhelper 还是可以成功的 ~

如果设置的 HKCU\Software\Classes\ms-settings\shell\open\command 中不包含敏感字符，Defender 就不会检测到，不会弹出提示，也不会删除键值：

如果有时间，还可以看一下其他程序有没有类似问题 ~

C 代码：

二、通过 DLL 劫持 Bypass UAC

参考：https://medium.com/tenable-techblog/uac-bypass-by-mocking-trusted-directories-24a96675f6e

目标程序：winSAT.exe

DLL：winmm.dll

利用思路：使用 CreateDirectory API 创建 "C:\Windows \System32" 目录（"Windows" 后面有空格）绕过 Appinfo.dll (AIS) 中 RtlPrefixUnicodeString 函数中的可信目录的检查。将目标程序复制到此目录，伪造 DLL，利用 DLL 加载顺序使目标程序加载伪造的 DLL 执行任意代码，从而绕过 UAC 弹窗提示

简单分析：

先看一下 DLL 加载顺序：

下面是个简单的例子，TestLoad 加载 onlytest.dll，程序加载目录是 C:\Users\strawberry，可以发现程序在加载 DLL 的时候会从程序所在目录开始寻找，然后才会从系统目录中搜索：

AIS 要求程序从可信目录中启动，而这些目录普通用户是没办法写入的。但是可以新建 "C:\Windows \System32" 目录，将白名单程序复制到这个目录，这样劫持 DLL 就顺理成章了。

winSAT.exe 导入了 winmm.dll 中两个函数 timeBeginPeriod、timeEndPeriod，伪造的 dll 也要导出这两个函数

以下为 dll 实现，偷懒这里直接用 mshta 了（需要关掉 defender）

然后运行 winsat，然后就成功了。不过，运行的时候有个弹窗，可以通过编程隐藏窗口~

以下为最终代码，原本的版本中创建目录时使用的是 \\?\C:\Windows \System32，但经测试，直接用 C:\Windows \System32 也是可以成功的。通过 se.nShow = SW_HIDE 使程序运行时隐藏弹窗。

另外，前面分析过 RAiLaunchAdminProcess 函数在验证要启动的程序是否位于可信路径时会使用 String2 与一些路径进行比对。以下为 String2 的赋值流程，"C:\Windows \System32\winSAT.exe" 经过 GetLongPathNameW 函数处理之后得到 "C:\Windows\System32\winSAT.exe"，经过这个函数调用，"Windows " 中的空格被处理掉了，然后再调用 RtlDosPathNameToRelativeNtPathName_U_WithStatus 函数将字符串保存为以 "\??\" 开头的 UNICODE_STRING 类型的 String2。这样在后面比对的时候就可以匹配上 "C:\Windows\System32"，从而校验通过，然后就调用 RtlFreeUnicodeString 函数把它释放了。

后面在调用 AiIsEXESafeToAutoApprove 函数时，传入的参数还是 "C:\Windows \System32\winSAT.exe"，good ~

三、通过 APPINFO RPC服务 Bypass UAC

参考：https://googleprojectzero.blogspot.com/2019/12/calling-local-windows-rpc-servers-from.html

目标服务：AppInfo

相关函数：RAiLaunchAdminProcess

前置知识：如果可以在提升的 UAC 进程上启用调试并获得其调试对象的句柄，我们可以请求第一个调试事件，该事件将返回对该进程的完全访问句柄：https://googleprojectzero.blogspot.com/2019/04/windows-exploitation-tricks-abusing.html

利用思路：对于提升的进程，我们无法直接获得其调试对象句柄。但由于调试对象的句柄存储在 TEB 的保留字段中，同一个线程上创建的带有调试标志的所有进程共享同一个调试对象，可通过先创建 DEBUG_PROCESS 标志的非提升的进程，获得初始化的调试对象句柄，然后创建 DEBUG_PROCESS 标志的提升的进程，进而使用共用的调试对象句柄获得提升的进程的完全访问句柄

先按照文章上的步骤复现一下：

如下：

在这个过程中遇到过模块无法加载的问题，解决：(以管理员身份打开PowerShell 输入 set-executionpolicy remotesigned，就当是先测试下吧，实际情况下还是会用 C 或 C# 程序)。参考：https://www.jianshu.com/p/4eaad2163567

简单分析

首先回顾一下 RAiLaunchAdminProcess 函数，该函数原型如下：

经过分析可以知道，该函数通过 AiCheckLUA -> AiLaunchConsentUI -> AiLaunchProcess -> CreateProcessAsUserW 函数调用链来启动 consent.exe 进程来判断是否需要弹窗，然后通过 AiLaunchProcess -> CreateProcessAsUserW 函数调用链启动目标程序。以下为 AiLaunchProcess 函数调用 CreateProcessAsUserW 函数的过程，其中 a7 来自 AiLaunchProcess 函数的第 7 个参数：

经过回溯发现该参数来自于 RAiLaunchAdminProcess 函数的第 6 个参数 a6，由于 RAiLaunchAdminProcess 函数采用异步处理，其第一个参数对应了 PRPC_ASYNC_STATE 类型的 pAsync，因而 a6 对应的参数是 CreateFlags

在调用 CreateProcessAsUserW 函数的时候会传入CreateFlags | 0x80004，CreateFlags 对应的 flag 列表可参考：https://docs.microsoft.com/en-us/windows/win32/procthread/process-creation-flags，其中，设置 DEBUG_PROCESS 标志允许启动并调试新进程。

访问进程的调试对象句柄需要对进程句柄具有 PROCESS_QUERY_INFORMATION 访问权限，但如果是提升的进程，我们只能获得对该进程句柄的 PROCESS_QUERY_LIMITED_INFORMATION 访问权限。这种限制使我们不能简单地获取提升进程的调试对象句柄。

不过由于设置了 DEBUG_PROCESS 标志，在调用CreateProcessAsUserW 函数过程中会调用 ntdll!DbgUiConnectToDbg 函数，该函数从 TEB 中获取调试对象，如下所示：

DbgUiConnectToDbg 函数首先会判断 TEB 偏移 0x16A8 处是不是 0（+0x16a0 DbgSsReserved : [2] (null)），如果是的话，就调用 NtCreateDebugObject 函数来创建一个调试对象，相当于初始化当前线程的调试对象。如果这个线程再调试一个进程，就可以直接从 TEB 偏移 0x16A8 处获得

如果我们先创建一个普通进程并启用调试，在获得其调试句柄后分离调试器并终止进程，然后再创建一个调试的提升的进程，这样我们就有了获得提升进程的调试对象句柄的这个前提。然后就可以调用 WaitForDebugEvent 函数等待目标调试事件从而获得提升的进程句柄（NtWaitForDebugEvent 函数调用 DbgkpOpenHandles 处理 CREATE_PROCESS_DEBUG_EVENT 类型事件时，会初始化 CREATE_PROCESS_DEBUG_INFO 结构中的进程句柄），虽然获得了这个句柄，但我们缺少 PROCESS_SUSPEND_RESUME 权限，这会阻止我们将进程与调试对象分离。但由于我们具有 PROCESS_DUP_HANDLE 权限，因而可以调用 NtDuplicateObject 函数复制句柄从而获得完全提升的权限：

小结
验证某个结论往往是简单的，能自己寻找到那个点是困难且有意义的，此时发出一声哀叹，哎~ 太难了。新手上路，希望大佬们多带带菜鸡 T_T

参考链接：

https://blog.csdn.net/WPwalter/article/details/89838881

https://blog.walterlv.com/post/windows-user-account-control.html

https://blog.walterlv.com/post/requested-execution-level-of-application-manifest

https://medium.themayor.tech/utilizing-a-common-windows-binary-to-escalate-to-system-privileges-c16482cced4b

https://idiotc4t.com/privilege-escalation/bypassuac-fodhelper

https://medium.com/tenable-techblog/uac-bypass-by-mocking-trusted-directories-24a96675f6e

https://googleprojectzero.blogspot.com/2019/12/calling-local-windows-rpc-servers-from.html

https://googleprojectzero.blogspot.com/2019/04/windows-exploitation-tricks-abusing.html

http://blog.nsfocus.net/appinfo-rpc-uac-bypass/

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课