域内渗透手法 Ⅰ
域内用户名枚举
域内用户名枚举可以在无域内有效凭据的情况下,枚举出域内存在的用户,并对其进行密码喷洒攻击,以此获取域内的有效凭据。
原理
在Kerberos协议认证的AS-REQ阶段,请求包cname对应的值是用户名。当用户状态不同时,其返回的AS-REP包不相同。可以利用这一点进行用户名枚举。
工具
kerbrute
是一款使用Go语言编写的域内用户名枚举和密码喷洒工具
下载地址:
具体命令如下
相关参数的含义:
pyKerbrute
一款使用python编写的域内用户名枚举和密码喷洒工具,可以通过TCP和UDP两种模式进行工作
下载地址:
具体命令如下:
MSF
使用auxiliary/gather/kerberos_enumusers模块也可以进行域内用户名枚举
具体命令如下
防御
由于域内用户名枚举是通过发送大量的AS-REQ包,根据返回包的内容筛选出存在的域用户,那么有以下方法进行检测。
流量层面,可以检测同一IP在短时间内是否发送了大量的AS-REQ包来进行判断。
日志层面,默认情况下域内用户名枚举并不会对不存在的用户发起的AS-REQ包产生日志,因此不太好通过日志来进行判断。
域内密码喷洒
原理
域内密码喷洒攻击一般与域内用户名枚举一起使用。
在kerberos协议认证的AS-REQ阶段,请求包cname对应的值是用户名。当用户名存在时,在密码正确与错误的情况下,AS-REP的返回包不一样。所以可以利用这一点对域用户名进行密码喷洒攻击。
工具
kerbrute
具体命令如下:
相关参数的具体含义
DomainPasswordSpray.ps1
这个未能复现成功,应该是本身脚本就有些问题。
该脚本需要在域内的机器上执行,在默认情况下该脚本是利用LDAP从域中导出用户列表,然后去除被锁定的用户,再用指定的密码进行喷洒攻击。
防御
AS-REP Roasting
AS-REP Roasting是一种对用户账号进行离线爆破的攻击方式。但是该攻击方式利用比较局限,因为其需要用户账号设置 "**Do not require Kerberos preauthentication(不需要kerberos预身份验证) **" 。而该属性默认是没有勾选上的。
预身份验证是Kerberos身份验证的第一步(AS_REQ & AS_REP),它的主要作用是防止密码脱机爆破。默认情况下,预身份验证是开启的,KDC会记录密码错误次数,防止在线爆破。
原理
当关闭了预身份验证后,攻击者可以使用指定用户去请求票据,此时域控不会作任何验证就将 TGT票据 和 该用户Hash加密的Session Key返回。因此,攻击者就可以对获取到的 用户Hash加密的Session Key进行离线破解,如果破解成功,就能得到该指定用户的密码明文。
获取Login Session Key
当前主机在域内
由于该工具需要git clone下后自己编译,且对于编译环境较为严格,故在github上找到了已经编译好的包,且会持续更新
该工具会自动搜索域内勾选了"不要求kerberos预身份验证"选项的用户,并以该用户身份发起AS-REQ请求以获取login session key
可以看到,搜索到了"不要求kerberos预身份验证"选项的用户liukaifeng01,并将返回的login session key保存为hash.txt文件
当前主机不在域内
当拥有一个有效的域账户和密码,可以先进行筛选符合"不要求kerberos预身份验证"选项的用户(可选,可以使攻击更加具有针对性,成功几率更高)
获取login session key
如果没有有效的域账户和密码,那就在user.txt中写入大量用户名,盲爆,看运气了。
爆破 Login Session Key
john
将获取到的john格式的login session key 保存为hash,使用john进行破解
hashcat
如果想用hashcat进行破解,需要简单修改获取到的John格式的login session key

在此处添加$23即可
执行命令进行破解
防御
主要就是检测是否设置了"不要求kerberos预身份验证"选项
在日志层面进行检测,重点关注事件ID为4768且预身份验证为0的日志
Kerberoasting
原理
其发生在TGS_REP阶段,KDC的TGS服务返回一个由服务hash加密的ST给客户端。由于该ST是用服务Hash加密的,因此客户端在拿到该ST后可以用于本地离线爆破。若字典够强大,则很有可能爆破出SPN链接用户的明文密码。如果该服务以高权限运行,则攻击者有可能接管整个域。
整个核心在于,与KDC协商ST加密时,协商为RC4_HMAC_MD5算法,该算法较容易被破解。
攻击流程概述

在第二步中,指定加密算法为RC4_MHAC_MD5算法。
第三步中,无论攻击者提供的域账户是否有权限访问指定SPN服务。KDC均查找哪个账户在ServicedPrincipaName属性中注册了所请求的SPN。然后用该用户的Hash以RC4_MHAC_MD5加密类型加密ST并在TGT-REP包中发送给攻击者。
注意:Kerberoasting攻击一般只针对注册在用户下的SPN,因为机器账户的密码是随机生成的128位字符
那么在实战中主要分为以下几步:
查询域内注册于域用户下的SPN
请求指定SPN的ST
导出请求的ST
对导出的ST进行离线破解
SPN的发现
RiskySPN
RiskSPN是一个脚本集合,主要用于检测与SPN相关的账户是否滥用。该脚本可以帮助我们自动识别弱密码凭据,根据用户账户过期时间来查找最容易包含弱密码的票据。且该脚本会自动过滤注册于krbtgt下的kadmin/changepw的SPN
具体命令如下:

可以看到,在test账户下注册了SPN
GetUserSPNs
在kerberoast工具集中查询注册于域内用户下的SPN脚本,该脚本会查询域内所有注册于用户下的SPN,包括注册于krbtgt下的kadmin/changepw。其有两种实现方法,分别是vbs脚本与powershell脚本。
具体命令如下:

可以看到,在test账户下注册了SPN
powerView.ps1
是powerspolit(在kali中已集成)中recon目录下的一个powershell脚本。
具体命令如下:
请求服务票据
使用Impacket请求
getuserspns脚本可用于请求注册用户下的所有SPN的服务票据,也可以请求注册于指定用户下的SPN服务票据。
注意。该脚本同时实现了"SPN的发现"与"请求服务票据"两个步骤
具体命令如下:
使用Rubeus请求
rubeus中的Kerberoast支持对所有用户或特定用户执行kerberoasting操作,他的原理在于先用LDAP查询域内所有注册在域用户下的SPN(排除kadmin/changepw),再发送TGS包,直接输出能使用John或者Hashcat爆破的hash。
注意。该脚本同时实现了"SPN的发现"与"请求服务票据"两个步骤
具体命令如下:
使用mimikatz请求
使用mimikatz请求的服务票据将保存在内存中
注意。该脚本仅实现了"请求服务票据"一个步骤
具体命令如下:
,具体步骤如下:
查看内存中的票据

此时可以确认,已经成功请求到了票据并保存在了内存中
使用mimakatz导出票据
执行完成后会在当前目录下导出.kribi格式的票据文件
离线破解服务票据
.kribi格式的破解
kerberoast
使用kerberoast工具集合中的
tgsrepcrack.py可以对mimakatz导出的.kribi格式的票据进行爆破
这个工具我没有测试,这里仅给出执行代码
hashcat或john格式的破解
使用impacket及rubeus请求的服务票据为hashcat或john格式,可以使用以下命令
这里我使用john破解失败了,暂不清楚什么原因🥲
防御
委派
委派是指将域内用户的权限委派给服务账户,使得服务账户能以用户权限访问域内的其他服务。
在域中,只有主机账户和服务账户具有委派属性。
委派的分类
域内委派主要有三种类型:
非约束性委派
约束性委派
基于资源的约束性委派
非约束性委派
对于非约束性委派,服务账户可以获取被委派用户的TGT,并将TGT缓存到LSASS进程中,从而服务账户可以使用该TGT模拟该用户访问任意服务。
非约束性委派的设置需要SeEnableDelegationPrivilege特权,该特权默认仅授予域管理员和企业管理员。
注意:域控默认配置了非约束性委派
其基本流程如下图:

从攻击者的角度来看,如果获取了service 1的权限,则攻击者可以诱骗域管理员来访问service 1,然后攻击者可以在service 1的机器上获取域管理员的TGT,从而可以使用缓存的TGT模拟管理员访问任意服务,包括域控。
约束性委派
对于约束性委派,服务账户只能获取该用户对指定服务的ST,从而只能模拟该用户访问特定的服务。
配置了约束性委派账户的msDS-AllowedToDelegateTo属性会指定对哪个SPN进行委派。约束性委派的设置需要SeEnableDelegationPrivilege特权,该特权默认仅授予域管理员和企业管理员。
其基本流程如下:

从攻击者的角度来看:只要我们获得约束委派的服务权限,那么通过这个服务就可以直接来进行攻击可以访问的相关服务。如果可以访问的服务是域控的CIFS,那么就可以直接访问到域控的CIFS,相当于控制了域控。
基于资源的约束性委派
基于资源的约束性委派不需要域管理员权限去设置,而是把设置属性的权限赋予了机器自身。基于资源的约束性委派允许受信任的账户委派给自身。
配置了基于资源的约束性委派账户的msDS-AllowedToActOnBehalfOfOtherIdentity属性的值为被允许委派账户的SID。
这种约束委派的风格与传统约束委派非常相似,但配置相反。
具体如下图所示:

其基本流程如下:

在第二步中为什么会返回不可转发的ST1呢?其原因为在S4u2self协议中,返回的ST可转发的一个条件是服务A配置了传统的约束性委派。而基于资源的约束性委派是在服务B上配置的,服务B的
msDS-AllowedToActOnBehalfOfOtherIdentity值为服务A的SID,当KDC检查服务A的msDS-AllowedToDelegateTo字段时,发现并没有配置,故不会返回可转发的ST1。
谁具有配置基于资源的约束性委派的权限?
域管理员等高权限用户
机器自身
将机器加入域的域用户
查询具有委派属性的账户
查询非约束性委派的主机或服务账户
PowerShell脚本
利用PowerSploit下
recon目录中的PowerView.ps1脚本查询ADfind
利用ADfind过滤samAccountType和userAccountControl属性
Ldapsearch
利用Ldapsearch过滤samAccountType和userAccountControl属性
查询约束性委派的的主机或服务账户
PowerShell脚本
Adfind
Ldapsearch
查询基于资源的约束性委派或服务账户
Adfind
Ldapsearch
委派攻击
非约束性委派攻击
其重点在于拿到TGT
环境:
查询域内非约束性委派的主机账户
可以看到STU机器有非约束性委派
典型利用
诱使域管理员访问机器
为表示演示,这里我们手工进行访问
导出票据
此时,在STU机器的lsass.exe内存中就会有域管理员Administrator的TGT,我们在STU上以管理员权限运行mimikatz,执行以下命令以导出内存中的票据
将票据导入内存
此时就可以成功访问域控
结合打印机漏洞攻击
在典型利用中,还需要管理员主动连接配置了非约束性委派的主机,才能从该主机上获取到域管理员的TGT,实战中意义不大。
我们也可以利用打印机服务漏洞来强制域控连接了配置了约束性委派的主机,也能从该主机上抓到域控机器的TGT。
利用Windows打印系统远程协议(MS-RPRN)中的一种旧的但是默认启用的方法,在该方法中,域用户可以使用MS-RPRN
RpcRemoteFindFirstPrinterChangeNotification(Ex)方法强制任何运行了Spooler服务的计算机以通过Kerberos或NTLM对攻击者选择的目标进行身份验证。使用rubeus以管理员权限每隔一秒监听来自OWA主机的票据
在STU上使用打印机服务漏洞攻击域控OWA,使其强制回连认证STU主机
很遗憾,这里我复现失败
在rubeus上可以接受到来自OWA的base64的TGT
Rubeus 导入获取到的 TGT 票据
这时候管理员权限运行 mimikatz 就可以获取域内所有用户的 NTLM hash,内存中也有了域管的 TGT 也可以直接 PTT。
域机器账户不能用于登录,但是具有DCSync权限,所有可以用于导出域用户Hash
约束性委派攻击
服务用户只能获取某个用户(或主机)的服务的 ST,所以只能模拟用户访问特定的服务,是无法获取用户的 TGT,如果我们能获取到开启了约束委派的服务用户的明文密码或者 NTLM Hash ,我们就可以伪造 S4U 请求,进而伪装成服务用户以任意账户的权限申请访问指定服务的 ST。
环境:
查询约束性委派账号
我们获取了STU主机的权限,该主机当前登录用户为
god\\liukaifeng01,其密码为qazx123@发现用户
liukaifeng01被赋予了约束性委派属性,并且委派的SPN是cifs/OWA.god.org使用kali攻击
在kali中编辑hosts文件(若域控不能与kali通信,则此方法无效,需要结合隧道+代理实现)
将192.168.52.138与OWA.god.org进行绑定
执行以下命令
使用拿下的主机进行攻击
待写。。。
基于资源的约束性委派攻击
最后更新于
这有帮助吗?