Windows内网协议学习NTLM篇之Net-NTLM利用

原来的NegoFlags值为x05x02x89xa2，现在改为x05x02x81xa2，以获取Net-NTLM v1。然后使用ntlmv1-multi中的ntlmv1.py进行转换。得到的Net-NTLM v1是win10::WIN10-1:F1586DA184365E9431C22EF206F5A2C918659E1B1FD7F64D:F1586DA184365E9431C22EF206F5A2C918659E1B1FD7F64D:1122334455667788。

转换后的格式为NTHASH:F1586DA184365E9431C22EF206F5A2C918659E1B1FD7F64D，然后使用crack.sh进行破解。下面简要探究一下原理，如果不感兴趣可以直接跳过，看下一小节。在NTLM基础介绍中简单介绍了Net-NTLM v1的加密方式。将16字节的NTLM hash空填充为21个字节，然后分成三组，每组7字节，作为3DES加密算法的三组密钥，加密服务器发送的Challenge。将这三个密文值连接起来得到response。但在实践中发现，加密方式的表述有些问题，或者说不完整。上述只是Net-NTLM v1的一种加密方式，Net-NTLM v1还有另一种加密方式。下面我们来探讨这两种加密方式以及利用。

使用ntlmv1-multi中的ntlmv1.py进行转换，然后复制NTHASH:E0F8C5B5E45247B4175698B99DBB5557CCD9241EA5A55CFB到crack.sh进行破解，填写邮箱，等待大约一分钟就能收到ntlm hash。

(2) 加密方式2与第一种加密方式基本相同。最本质的区别在于，第一种加密方式的加密内容是Server Challenge，而第二种加密方式是拼接8字节Server Challenge和8字节Client Challenge后，求其MD5，然后取MD5值的前8字节作为加密内容。

使用ntlmv1-multi中的ntlmv1-ssp.py进行转换，然后使用crack.sh进行破解。这种方式需要付费，而且不一定能够成功破解。

总而言之，这种加密方式不容易破解，实际上我们也可以让客户端不使用这种加密方式，而是使用第一种加密方式。接下来我们来分析一下。

在Responder中加上–lm参数可以获取到采用第一种加密方式的Net-NTLM Hash，但只对smb协议有效。在我的测试中，即使加上–lm参数，收到的请求是HTTP协议的情况下，得到的Net-NTLM v1仍然采用第二种加密方式，很难破解。所以我研究了一下在什么情况下采用第一种加密方式，什么情况下采用第二种加密方式。

在这篇文章中提到，当NTLM的flag位NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY置为1时，会采用第二种加密方式，否则会采用第一种加密方式。我们可以看一下impacket中计算Net-NTLM v1的相关代码。

可以清楚地看到，当NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY位为1时，加密的内容不是Server Challenge，而是经过MD5哈希运算的Server Challenge和Client Challenge的前8位。也就是说这是第二种加密方式。

那NTLMSSPNEGOTIATEEXTENDEDSESSIONSECURITY flag位来自哪里呢？我们知道NTLM分为type1、type2、type3。计算response就在type3中，NTLMSSPNEGOTIATEEXTENDEDSESSIONSECURITY flag位来自type2。而type2中的内容通常是我们返回给客户端的。

也就是说，客户端选择使用加密方式1还是加密方式2，我们是可以控制的。只需要将NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY位设置为0，客户端就会选择加密方式1。并且在Server Challenge为1122334455667788的情况下，我们可以使用crack.sh快速免费有效地破解，获取用户的NTLM Hash。

那么如何将NTLMSSPNEGOTIATEEXTENDEDSESSIONSECURITY位设置为0呢？通常我们使用现成的工具Responder来获取Net-NTLM Hash。之前提到过，加上–lm参数就可以将NTLMSSPNEGOTIATEEXTENDEDSESSIONSECURITY位设置为0。

这时还有一个小问题没有解决，就是Responder加上–lm参数为什么只对smb协议有效，其他协议无效。我去阅读了Responder的代码。

加上–lm参数后，调用的模块是SMB1LM。发现它使用的是旧版本的SMB实现。这个版本的实现在SMB协商版本时就返回了Challenge，并将NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY位设置为0。

但完全可以不使用旧版本的SMB实现。关键在于将NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY位设置为0，并不一定需要使用旧版本的SMB。只需要修改NTLM SSP中的flag位即可。在各个协议的NTLM SSP中修改flag位，我们找到Responder中type2的NTLM SSP的flag位赋值的地方即可。Responder的NTLM SSP实现并不通用。例如，SMB部分的实现在packets.py的SMBSession1Data类中。

默认值为0xe2898215（与图中不同？大端小端）。NTLMSSPNEGOTIATEEXTENDED_SESSIONSECURITY对应的是第13位，将其改为0，即0xe2818215。修改后即可。

对于HTTP协议，在packets.py的NTLM_Challenge类中进行修改。

hashcat -m 5600  win10::TEST:1122334455667788:622DED0816CFF5A0652209F20A7CF17A:0101000000000000C0653150DE09D201532C07A7DEE654B8000000000200080053004D004200330001001E00570049004E002D00500052004800340039003200520051004100460056000400140053004D00420033002E006C006F00630061006C0003003400570049004E002D00500052004800340039003200520051004100460056002E0053004D00420033002E006C006F00630061006C000500140053004D00420033002E006C006F00630061006C0007000800C0653150DE09D2010600040002000000080030003000000000000000010000000020000067840C88904F15E659858A3CBA35EBEF61A38EC88C5E3D26B968F1C20C9ACAC10A001000000000000000000000000000000000000900220063006900660073002F003100370032002E00310036002E003100300030002E0031000000000000000000 /tmp/password.dic --force


0x02 Relay
在Net-NTLM Hash的破解里面，如果是v1的话，拿到Net-NTLM就相当于拿NTLM HASH.这个时候就没有Relay的必要性了，但是在实际中遇到的例子往往不会是v1，而是v2。这个时候密码强度高一点，基本就跑不出来了，这种情况底下，不妨试一试Relay。
1. Relay2SMB
能直接relay到smb服务器，是最直接最有效的方法。可以直接控制该服务器(包括但不限于在远程服务器上执行命令，上传exe到远程命令上执行，dump 服务器的用户hash等等等等)。
主要有两种场景
工作组环境
这个实用性比较差。在工作组环境里面，工作组中的机器之间相互没有信任关系，每台机器的账号密码Hash只是保存在自己的SAM文件中，这个时候Relay到别的机器，除非两台机器的账号密码一样(如果账号密码一样，我为啥不直接pth呢)，不然没有别的意义了，这个时候的攻击手段就是将机器reflect回机子本身。因此微软在ms08-068中对smb reflect到smb 做了限制。这个补丁在CVE-2019-1384(Ghost Potato)被绕过。将在下篇文章里面详细讲。
域环境
域环境底下域用户的账号密码Hash保存在域控的 ntds.dit里面。如下没有限制域用户登录到某台机子，那就可以将该域用户Relay到别人的机子，或者是拿到域控的请求，将域控Relay到普通的机子，比如域管运维所在的机子。(为啥不Relay到其他域控，因为域内就域控默认开启smb签名)
下面演示使用几款工具在域环境底下，从域控relay到普通机器执行命令
impacket 的底下的smbrelayx.py

impacket 的底下的ntlmrelayx.py

Responder底下的MultiRelay.py


2. Relay2EWS
Exchange的认证也是支持NTLM SSP的。我们可以relay的Exchange，从而收发邮件，代理等等。在使用outlook的情况下还可以通过homepage或者下发规则达到命令执行的效果。而且这种Relay还有一种好处，将Exchange开放在外网的公司并不在少数，我们可以在外网发起relay，而不需要在内网，这是最刺激的。
下面演示通过NtlmRelayToEWS(事实上，工具挺多的。其他的大家可以上github自己找)来实现Relay2ews


配合homepage 能够实现命令执行的效果
homepage的简易demo代码如下

<html><head><meta http-equiv="Content-Language" content="en-us"><meta http-equiv="Content-Type" content="text/html; charset=windows-1252"><title>Outlook</title><script id=clientEventHandlersVBS language=vbscript></script></head>
<body><object classid="clsid:0006F063-0000-0000-C000-000000000046" id="ViewCtl1" data="" width="100%" height="100%"></object></body></html>

放置于web服务器。在NtlmRelayToEWS里面通过-u 参数指定。


3. Relay2LDAP
不管是杀伤力巨大的8581还是1040。Relay到ldap都在里面发挥着巨大的作用。
relay 到ldap的话，能干嘛呢
这里着重介绍三种通用性比较强的利用思路。这三种在impacket里面的ntlmrelayx都有实现。(这三种通用性比较强而已，实际中这个的利用比较灵活，需要通过 nTSecurityDescriptor分析用户在域内对哪些acl有权限，什么权限。关于acl怎么深入利用,这里不再展开，后面在ldap篇会详细说明)

高权限用户
如果NTLM发起用户在以下用户组
那么就可以将任意用户拉进该组，从而使该用户称为高权限用户，比如域管

write-acl 权限
如果发起者对DS-Replication-GetChanges(GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)和DS-Replication-Get-Changes-All(1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)有write-acl 权限，那么就可以在该acl里面添加任意用户，从而使得该用户可以具备dcsync的权限
这个案例的典型例子就是Exchange Windows Permissions组，我们将在下一篇介绍8581的 时候详细说下这个用户组的权限。

普通用户权限
在server2012r2之后，如果没有以上两个权限。可以通过设置基于资源的约束委派。
在NTLM发起者属性msDS-AllowedToActOnBehalfOfOtherIdentity里面添加一条ace,可以让任何机器用户和服务用户可以控制该用户(NTLM发起者)。

0x03 引用
LM-Hash、NTLM-Hash、Net-NTLMv1、Net-NTLMv2详解
The NTLM Authentication Protocol and Security Support Provider


Responder的NTLM SSP实现并不通用，这让人有些困扰。其他协议的实现需要自行查找代码。跟进代码并不困难。

Net-NTLM v2的破解目前没有比较好用的方法，通常使用hashcat进行离线爆破明文密码，是否能够成功取决于字典中是否包含密码。

使用hashcat进行字典破解。