Hardening Kerberos
AS-REPRoasting 利用已禁用 Kerberos pre-authentication 的账户，使攻击者能够获取它们的 TGT。为了防范 ASReproasting 攻击
- 不要为用户设置禁用 Kerberos 预身份验证。某些服务账户可能需要它（旧协议），但尽可能为所有账户启用预身份验证。
- 确保对 Kerberos 使用强加密算法。弃用 RC4
- 使用强密码保护并监控服务账户，并留意这些账户的异常活动日志（访问通常不使用的文件或资源）。
1.1.1. 检查已禁用的预认证
PS C:\htb> Get-ADUser -filter * -properties DoesNotRequirePreAuth | where {$_.DoesNotRequirePreAuth -eq "True" -and $_.Enabled -eq "True"} | select Name
Carole Rose
Amber Smith
1.1.2. 设置预认证
2. Kerberoasting
由于 Kerberoasting 不需要事先与域控制器进行身份验证，它成为离线暴力破解票据哈希以获取密码的常用攻击路径。诸如 Impacket 、 mimikatz 、 PowerSploit 等工具都具备一定的能力去 Kerberoast 或获取SPN 。如果攻击者获得了 Kerberos 的 KRBTGT ，修复问题并驱逐攻击者的事件响应流程会非常复杂，且很容易导致域服务中断。因此，考虑到这一点，采取这些加固措施以确保尽可能缓解攻击是至关重要的。
- 为服务账户使用长且复杂的密码至关重要。更复杂的密码将使破解难度呈指数级增加。
- 利用组托管服务账户来维护和保护你的服务。gMSA 会负责这些账户的密码管理与轮换。默认情况下，密码轮换每 30 天进行一次。
- 限制服务账户的权限。（例如，不将服务账户加入域管理员组）
- 每 180 天至少轮换一次 KRBTGT 服务帐户密码。此操作可使攻击者已获取并正在使用的所有先前票据失效。
2.1.1. 检查 KRBTGT 属性
PS C:\htb> Get-ADUser krbtgt -Property PasswordLastSet
请记住，如果出于事件响应目的重置密码，第一次和第二次重置之间必须间隔十小时。需要两次重置才能使之前的 Kerberos 密码失效，并阻止潜在的恶意使用。确保在重置之间强制进行复制。
可以使用微软的 New-KrbtgtKeys.ps1 来“重置 krbtgt 账户密码，同时最大程度降低该操作引发 Kerberos 身份验证问题的可能性”
3. Delegation Abuse
Delegations
在利用 Kerberos 的环境中，存在三种委派类型，因此也产生了多种不同的利用场景。在一段时期内（Windows Server 2000 到 Server 2003 之间），非约束委派 (Unconstrained Delegation) 是唯一的选择，并且出于遗留原因，它在现代操作系统中仍然存在。委派中的问题使得攻击者可以滥用那些不在“受保护用户 (Protected Users)”组中且未被标记为敏感账户的用户。这使得任何控制了该服务器或服务的人，都可以使用已验证身份用户的 TGT，以该用户的身份请求访问任何其他资源。
为了解决这个问题，从 Server 2003 开始引入了 约束委派 (Constrained Delegation)。实施约束性委派是为了限制资源或服务使用这些票据的操作范围。然而，它并非万无一失。如果约束性委派配置不当，攻击者仍然可以执行与非约束性委派相同的战术和攻击。将用户放入“受保护用户”组，并启用“账户敏感且无法被委派 (Account is sensitive and cannot be delegated)”设置，可以增强防御能力，防止滥用。
下图展示了“受保护用户”安全组（绿色箭头），我们应该将账户添加到该组以防止委派滥用。红色箭头处显示了将账户设置为敏感账户的选项。
随着 Windows Server 2012 的发布，微软引入了基于资源的约束性委派 (Resource-Based Constrained Delegation)，以解决非约束性委派和约束性委派的诸多缺陷。基于资源的委派使得对 SPN（服务主体名称）的依赖变得不再重要，并允许资源通过特定的“安全描述符”而非 SPN 来决定委派。这有效地消除了为每个用户设置委派的需求，并将其转移到了服务层级。
3.1. 缓解措施
- 在可能的情况下，禁用非约束性委派。
- 在可能的情况下，将用户和服务账户放入受保护用户组。
- 对于任何不需要委派的账户，启用 账户敏感且无法被委派 设置。
- 尽可能利用最小权限原则。收紧访问权限、安全组以及用户/服务账户的设置。
4. Golden Ticket
Golden Ticket 攻击利用 krbtgt 账户的密码哈希伪造并签署 TGT
4.1. 缓解措施
- 实施最小权限访问模型
- 限制管理员账户数量，并将其设为独立的非交互式账户
- 不要向外界暴露诸如 RDP 之类的服务
- 在 OWA 和 VPN 等实现中采用多因素认证
- 终端检测与防病毒软件预防和检测 Mimikatz 等工具以及 TGT 滥用
5. Silver Ticket
通过控制服务账户，攻击者可以创建自己的票据授予服务票据来访问特定资源或主机.由于服务票据无需与密钥分发中心通信，检测其滥用行为要困难得多
5.1. 缓解措施
- 确保服务账户使用复杂度达 25 个字符或以上的强密码
- 采用托管服务账户并确保密码定期轮换
- 请勿将服务账户放置在特权组（如域管理员）中
- 将服务账户的权限限制在其运行所需的最小范围
通过从我们的主机获取用户 TGT、TGS 票据，我们可以避免操作 LSASS 并可能被检测
6.1. 缓解措施
- 监控创建和终止进程的事件
- 检查在正常操作之外请求新 TGT 或 TGS 的任何用户（在票据过期之前，而不是在重启时等）。
- 特权身份管理（最小化管理员数量以及这些账户的使用方式）。
- 使用 Sysinternals 套件中的 Pipelist 或 Pipe Monitor 等工具，监控用于直接与主机交互的命名和匿名管道。