用户注册劫持

0x00 前言

我之前在研究“使用SCT绕过应用白名单保护”的时候有一个想法：在执行regsvr32命令注册COM组件的过程中，会在注册表HKEY _类_根\CLSID\下同步创建COM组件的键值，而classid的子项InprocServer32包含了scrobj.dll的绝对路径，那么如果修改子项InprocServer32的键值，是否会劫持一些操作呢？

但是，实际修改HKCR“CLSID”下的键值需要管理员的许可，所以这个想法没有被深入研究。直到最近，Matt Nelson@enigma0x3的博客让我有了新的想法。只需要普通用户权限就可以劫持高权限系统的注册表项，这让我对userland注册表劫持有了新的认识。

0x01 简介

本文将介绍用户域注册表劫持的原理，结合实例分析其在用户域持久化和BypassUAC中的应用，并介绍一种借助进程监视器查找BypassUAC的方法。

0x02 Userland registry hijacking原理

1、键值同步

可以在HKCU:\Software\Classes\下修改键值默认名称的数据，同时在HKCR:\下修改对应键值默认名称的数据(前提是该注册表项已经存在于HKCR:\)。

例如：

编辑HKEY _当前_用户\软件\类\ mscfile \ shell \打开\命令的默认值为C:\ test \ admin.exe。

画

注：

HKEY _当前_用户\软件\类\下默认不存在mscfile \ shell \ open \命令，需要自己创建。

转到HKEY _类_根\ mscfile \ shell \ open \ command，发现默认值自动修改为C:\ test \ admin.exe。

画

注：

在HKCU:\Software\Classes\CLSID下创建不存在的新项不会更新HKCR:\CLSID的数据。

画

创建一个新的HKEY _当前_用户\软件\类\ mscfile \ shell \ open \ command \ 1。默认名称的数据被设置为1，但是HKEY _类_根\ mscfile \ shell \ open \ command不会创建一个新的子项1。

2、权限

修改HKCU下的键值只需要普通用户权限。

修改HKCR下的键值需要管理员权限。

综上所述，你只需要以普通用户权限编辑HKCU:\Software\Classes\下的键值，就可以同步修改相应管理员权限HKCR下的键值。

根据上面介绍的原理，它可以应用于Userland持久性和BypassUAC:

0x03 Userland Persistence With Scheduled Tasks

如果劫持系统某个计划任务对应的注册表键值，修改要启动的dll的绝对路径，就可以实现一个只有普通用户权限的后门。具体操作如下：

1、查看计划任务同注册表的对应关系

系统中的调度任务和注册表HKCU中的键值有对应关系：\Software\Classes\CLSID\，可以通过Matt Nelson@enigma0x3分享的脚本直接查看。

下载地址：

https://github . com/enigma0x 3/Misc-PowerShell-Stuff/blob/master/Get-scheduledtaskcomhandler . PS1

注：

通过计划任务面板查看的信息不完整。打开任务调度面板的方式是：我的电脑-右键-管理，找到任务调度，如下图所示。

ps脚本获取的部分对应如图。

获取与每个计划任务和启动的dll相对应的注册表键值的位置。

2、修改对应键值中的dll位置

找到对应关系后，需要定位具体的注册表项位置，即HKEY _当前_用户\软件\类\ clsid {clsid}。通常，该键在HKCU下不存在，因此需要手动建立。默认值被设置为要运行的测试dll的绝对路径。密钥创建后，HKCR下的密钥会同步更新，调度任务启动的dll也会相应修改。

实例：

1.检查计划任务和注册表之间的对应关系。

运行Get-ScheduledTaskComHandler找到可以劫持的dll，挑一个通用的调度任务——UserTask。详情如下：

任务名：用户任务

CLSID:{ 58 FB 76 b 9-ac85-4e 55-ac04-427593 B1 d 060 }

dll:C:\ Windows \ system32 \ dims job . dll

登录：真

IsUserContext : True

注：

这个操作需要找到HKCR下的键值，所以需要管理员权限才能得到。

2.修改dll在相应键值中的位置。

在HKEY _当前_用户\软件\类\ clsid \下创建一个新项目{ 58 FB 76 b 9-ac85-4e 55-ac04-427593 B1 d 060 }

然后在procServer32中创建一个新项目。

将值设置为c:\ test \ messagebox32.dll。

注：

注册表项{ 58 FB 76 b 9-ac85-4e 55-ac04-427593 B1 d 060 }是通用的，不同系统中的注册表项名称是相同的。

MessageBox32.dll的下载地址是：

https://github.com/enigma0x3/MessageBox

实际测试发现，https://github.com/enigma0x3/MessageBox/tree/master/bin dll在win7中失败，重新编译源代码生成的新dll可以使用。

看HKEY _类_根\ clsid { 58 FB 76 b 9-ac85-4e 55-ac04-427593 B1 d 060 } \ in proc server 32，默认值修改为c:\test\MessageBox32.dll，如图。

注销用户，再次登录，加载MessageBox32.dll，弹出框。

但是，在计划任务面板的日志中会提示错误(0x800401F9)，如图所示。

猜测导出函数的问题导致dll加载错误。使用dumpbin查看调度任务UserTask对应的原始dll的导出函数，并执行：

dumpbin/exports C:\ Windows \ system32 \ dims job . dll

注：

UserTask对应的原始dll的绝对路径是c:\ windows \ system32 \ dimsjob.dll。

得到dimsjob.dll的导出函数表，如图所示。

因此，您需要为dll添加一个新的导出函数：

DllCanUnloadNow

DllGetClassObject

DllRegisterServer

DllUnregisterServer

注：

在dll中添加导出函数的具体方法在《Code Execution of Regsvr32.exe》中有详细描述，此处省略。

添加成功后，dumpbin会看到如图所示的结果。

替换旧的MessageBox32.dll，注销用户，再次登录，加载新的MessageBox32.dll，弹出框。

查看计划任务面板日志，问题解决，操作成功完成，如图

以上操作可以通过powershell自动实现。修改UserTask的代码，如下所示：

函数调用-ScheduledTaskComHandlerUserTask

{

[cmdlet binding(SupportsShouldProcess=$ True，ConfirmImpact='Medium')]

参数(

[参数(强制=$True)]

[ValidateNotNullOrEmpty()]

[字符串]

$Command，

[开关]

$Force

)

$ ScheduledTaskCommandPath=' HKCU:\ Software \ Classes \ CLSID \ { 58 FB 76 b 9-ac85-4e 55-ac04-427593 B1 d 060 } \ in proc server 32 '

if($ Force-or((Get-item property-Path $ ScheduledTaskCommandPath-Name '(默认值)'-error action silently continue)-eq $ null)){

新项目$ ScheduledTaskCommandPath-Force |

New-ItemProperty -Name '(默认)'-Value $ Command-property type string-Force | Out-Null

}否则{

' Write-Verbose '密钥已经存在，请考虑使用-Force '

出口

}

if(测试路径$ScheduledTaskCommandPath) {

Write-Verbose“创建了劫持UserTask的注册表项”

}否则{

写警告'无法创建注册表项，正在退出'

出口

}

}

invoke-scheduledtaskscomhandlerusertask-Command ' C:\ test \ testmsg . dll '-Verbose

测试系统：Win7 x86

运行后，当用户再次登录时，加载dll，实际演示如图。

依次执行DLL_PROCESS_ATTACH()和DllGetClassObject()。由于DllGetClassObject()只作为一个框，所以后面会显示taskhost.exe错误。

注：

这里只是一个演示，具体的解决方案暂且不介绍。

至此，计划任务UserTask被劫持成功，系统启动时加载了testmsg.dll。

0x04 UACBypass

注册表中HKCR:\下的任务和键值是有对应关系的，一些权限高的程序也会调用HKCR:\下的键值，这就使得绕过UAC成为可能。

同理，HKCR下的键值：\可以通过修改HKEY _当前_用户\软件\类\下的键值来同步修改。如果高权限的程序在运行过程中调用这里修改的键值，自然会实现绕过UAC，启动我们设置的高权限的程序。

这里的难点在于找到这个权威性很高的程序。

方法：

借助进程监视器，您可以查看程序运行过程中注册表、文件、网络和进程之间的调用关系。

接下来用Process Monitor重现Matt Nelson@enigma0x3的发现过程。

1、找到高权限的exe

Matt Nelson@enigma0x3的方法是使用sigcheck查看exe的清单。

参数如下：

sigcheck.exe-m c:\ windows \ system32 \ eventvwr . exe

返回如图所示的结果。

从level=" highest available "可知eventvwr.exe的权限较高。

注：

提供一个更加直观的判断方法：

查看文件图标，如果带有UAC标志，那么一定是高权限的程序，如图

2、使用Process Monitor查看进程调用关系

启动过程监视器

运行eventvwr.exe

过程监视器选择工具-流程树，找到eventvwr.exe，右键-去参加活动，如图

仔细查看进程调用关系，如图

找到如下信息：

eventvwr.exe的权限为高的

eventvwr.exe首先查询键值HKCU软件\类\mscfile\shell\open\command，查询结果为找不到名称

eventvwr.exe接着查询键值HKCR \ MSC文件\外壳\打开\命令，结果为成功成就

3、修改测试

如果修改键值HKCU软件\类\mscfile\shell\open\command，使其查询结果为成功，会如何呢？

下面首先修改键值HKCU软件\类\mscfile\shell\open\command，值为calc.exe

再次运行eventvwr.exe，发现启动了calc.exe

使用过程监视器查看进程调用关系，如图

此时对键值HKCU软件\类\mscfile\shell\open\command的查询结果为成功成就

至此，成功通过修改HKCU软件\类\mscfile\shell\open\command，实现旁路交流，获得了高权限

calc.exe的权限为高，如图

4、更多结论

修改HKCU软件\类\mscfile\shell\open\command后，会劫持所有。人力服务委员会文件的运行，如gpedit.msc，如图

按照这个方法，我对系统32下的所有高权限可执行程序的扩展名进行了测试，尚未发现根据同样的方法利用命令键值实现的UACBypass，但是其他键值仍值得测试。

0x05 防御

Win10系统已对该处做了修复，低版本Windows操作系统操作系统系统尚未修复，防御建议：

将UAC级别设置为"始终通知"

从本地管理员组中删除当前用户

对HKCU软件\类中的新注册表项发出警报

引用自https://谜0x 3。net/2016/08/15/file less-UAC-绕过-使用-eventvwr-exe-and-注册表-劫持/

0x06 小结

计划任务中可被用作坚持的动态链接库有很多，在防御上建议对此进行监控。

通过过程监视器寻找旁路交流电（alternating current）的方法值得继续研究，一定会有新的发现。

相关学习资料：

https://谜0x 3。net/2016/08/15/file less-UAC-绕过-使用-eventvwr-exe-and-注册表-劫持/

https://谜0x 3。net/2016/05/25/userland-persistence-with-scheduled-tasks-and-com-handler-jacking/

https://博客。gdata软件。com/2014/10/23941-com-object-jacking-the-discreet-the-way-of-persistent

留下回复