然后丢给hashcat 跑
hashcat -m 18200 hash.txt pass.txt
注意这里的pass.txt是自己的明文字典…之前我还一直以为是爆破出来的结果.
原来是一个一个的用明文字典去爆破。
委派攻击域委派域委派是一种域内主机的行为，使某个服务可以以访问的用户的身份去访问另外一个服务。
为什么需要域委派呢，比如现在有web服务器和文件服务器，当用户A访问web服务器去请求某个资源时，web服务器上本身并没有该资源，所以web服务器就会从文件服务器上调用这个资源，其中发生的过程若以域委派的形式进行，那么就是：
用户A访问web服务器，服务器再以用户A的身份去访问文件服务器。
发生域委派的服务一般为机器账户和服务账户。
域委派分为三种：非约束性委派，约束性委派，基于资源的约束性委派
非约束性委派的原理是：用户想访问服务A，于是向KDC提交认证，KDC发现A是非约束性委派，于是会把TGT放在ST中一并给用户。然后用户用这个ST去访问服务A，服务A就相当于获得了用户的TGT，把TGT放入lsass进程，然后就可以拿着用户的TGT以用户的身份去访问所有用户权限能够访问的服务了。
非约束性委派的启用：
为某账户启用 信任此计算机来委派任何服务 即开启非约束性委派。
开启后在该用户的 ACL属性会多出一个 flag : WORKSTATION_TRUSTED_FOR_DELEGATION (图截不完，反正这个flag就在箭头所指处的后面)
非约束委派的设置需要SeEnableDelegation 特权，该特权通常仅授予域管理员
这里说个题外话，域控主机默认是非约束性委派
非约束性委派是很不安全的（因为控制了开启非约束性委派的机器，就相当于获得了上面的所有其他用户的TGT），所以更安全的约束性委派诞生了。
约束性委派多了两个委派协议，S4U2SELF S4U2PROXY，并且限制了被设置委派的服务的访问范围：仅能被委派到被指定的服务。
约束性委派的大致流程：
用户访问开启约束性委派的服务A
（情况一：无S4U2SELF参与）首先需要经过KDC认证，KDC发现服务A开启了约束性委派，于是在TGS_RES返回给用户ST1（可转发ST），用户拿着ST1访问服务A，服务A先与KDC进行身份验证获得一个有效TGT，然后拿着ST1经过S4U2PROXY协议向KDC发起TGS_REQ，KDC返回ST2（用户身份的ST），然后服务A拿着ST2访问指定服务。
（情况二：有S4U2SELF参与）用户通过其他方式（如NTLM认证，表单认证等）获取了服务A的信任，但是此时服务A并没有来自用户的ST1，按情况一中的流程，服务A就不能完成委派。所以这个时候服务A会以自己的身份向KDC发起申请获取一个可转发TGT（获取KDC信任），然后用这个TGT发起TGS_REQ获得指定用户的ST1，既然获取了ST1，就继续情况一中的流程即可了。
也就是说S4U2SELF是用户通过非kerberos协议完成认证的情况下，自动向KDC获取ST1的一个协议。
而S4U2PROXY则是将ST1发给KDC，使其变现为成自己可用的 ST2 的一个协议。
启用方法:
其中被添加的服务则是允许被委派到的服务
若启用的是 仅使用kerberos，那么useraccountcontrol属性仅有 workstation_trust_account.
若启用任何身份验证协议，就会有 TrustedToAuthenticationForDelegation
