“出于安全目的，默认DC会定期自动更改机器帐户密码。默认情况下，在基于Windows NT的计算机上，计算机帐户密码每隔7天自动更改一次。从基于Windows 2000的计算机开始，计算机帐户密码每30天自动更改一次，但是计算机不会在30天的窗口中同时更改所有密码”
域内本地管理员/常规域用户/域机器账号，分别属于3套不同的账号体系, 履行者不同的义务和工作。
域内常见机器间的通讯，大部分走的都是机器账号认证的体系.
只要可控机器账号/域账号外发认证，理论和理想情况下是可以实现中继或模仿域内机器间的各种正常行为的.
48位长度使用域控打印机协议特性(printerbug)，触发DC回连至我本机模拟的smb服务, 强制其从NTLMv2降级到NTLMv1
[SMB] NTLMv1 Client : 172.*.*.*
[SMB] NTLMv1 Username : BSEC\DC01$
[SMB] NTLMv1 Hash : DC01$::BSEC:21FAE6F24B*****:21FAE6F24B*****:1122334455667788
//NTHASH
NTHASH:21FAE6F24B*****
net-ntlm-hash-v1为48位长度,彩虹表爆破，30秒，即可还原32位的ntlm hash.
无论密码明文有多复杂，由于ntlm hash的机制，都可以还原，比如DC 2016机器账号密码为482位随机字符
//net-hash-v1
NTHASH:21FAE6F24B**************************************
//破解完成
b8909***************
自此，我们即获取了BSEC\DC01$机器账号的权限. hash有效期1月左右
可以看到，我们已经成功获取krbtgt的hash，同时也获取了一位域管的hash&明文密码.
检测方法
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ /v lmcompatibilitylevel
//如果键值存在，或数值为2，即存在漏洞
如图这样不受影响
知道你们只想一把梭，写的太长不会看，有详细需求的可以
私聊我一起讨论. (联系方式你应该找的到)
排查到最后，发现这是来自
8年前的一份组策略，具体操作人员已不可考察，操作意图留给读者猜测。
攻击路线分为四步
使用打印机协议恶意触发DC回调到我的445端口
该端口运行着一个python脚本，由于printerbug和域的特性，DC会使用自己的机器账户去认证
然后我代码中伪造的smb 服务，使用着旧版的NTLM协议，会促使DC的认证包加密降级。
最终获取DC机器账号的低加密强度hash，在10年前，还是很安全的。如今，彩虹表30秒，即还原出了该hash
域内hash等效于明文密码，拿到后，可以为所欲为，进而控制域内所有对象。
这里也反映出安全的一个本质是动态的，当初固若金汤的设计，一段时间后，就可能被降维打击。
一堆组策略里面(抑或工作组PC的注册表)，黑客进行了部分变更，全是域内协议层的变化，全程不碰shell, 如何去感知和防御呢?
域内不起眼的各处，是否一直埋藏着这类定时炸弹或后门呢？
人员迭代和流转中，有些漏洞是否会风水轮流转😄?
是否还有更早期/更通用的企业域内基建运行在弱加密的环境下呢?
printerbug类可控机器账号/域账号外发认证形成的组合拳，你会多少种?
SpoolSample from @tifkin_2018年10月6号
彩虹表白嫖crack.sh
关于机器账号利用之dcsync
Using Domain Controller Account Passwords To HashDump Domainsimpakcet 于 2015年9月15日左右 支持机器账号 dcsync
本文首次实战测试 2019年3月21日
mimikatz 于#zerologon爆发后新增支持mimikatz 于2020年9月16左右 支持机器账号 dcsync
本人获取的信息/进行的思考/完成的实践，肯定有欠缺或错漏，如有意见和建议欢迎私聊.
以上所有内容和操作，仅供参考，不保证对生产环境无任何不良影响，请确认和充分测试你的所有变更操作.
公众号复制markdown格式和链接会错乱, 回复加密降级获取原始格式的pdf。