windows protocol
  • 前言
  • Kerberos 篇
    • AS_REQ & AS_REP
    • TGS_REQ & TGS_REP
    • PAC
  • NTLM 篇
    • NTLM 基础 介绍
    • 发起NTLM 请求
    • Net- NTLM 利用
    • 漏洞概述
  • LDAP 篇
    • Active Directory简介
    • 组和OU介绍
    • 域用户和计算机用户介绍
    • 域权限上
    • 域权限下
    • 组策略
由 GitBook 提供支持
在本页
  • 0x00 前言
  • 0x01 Net-NTLM Hash的破解
  • 1. Net-NTLM v1 的破解
  • 2. Net-NTLM v2的破解
  • 0x02 Relay
  • 1. Relay2SMB
  • 2. Relay2EWS
  • 3. Relay2LDAP
  • 0x03 引用

这有帮助吗?

  1. NTLM 篇

Net- NTLM 利用

上一页发起NTLM 请求下一页漏洞概述

最后更新于5年前

这有帮助吗?

0x00 前言

在上一篇文章里面,讲了12种发起NTLM请求的方式。这篇文章接着上文,主要讲解拿到NTLM 请求之后的进一步利用。有Net-NTLM Hash的破解(v1 和 v2)以及Relay到支持NTLM SSP的协议,事实上,只要是支持NTLM SSP的协议,都可以Relay过去,本文主要讲的是几种比较常遇到,且能达到命令执行效果的,SMB,EWS,LDAP。

0x01 Net-NTLM Hash的破解

1. Net-NTLM v1 的破解

先上结论。只要获取到Net-NTLM v1,都能破解为NTLM hash。与密码强度无关。

具体操作如下。

  1. 修改Responder.conf里面的Challenge为1122334455667788(使用的 话默认是1122334455667788,但该版本已经停止更新了,建议使用,这一版本默认为Random,需要修改)

  2. 将type2里面的NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY位置0。

    如果知道发来的请求一定是SMB 协议的话,Responder里面加上--lm参数即可,

    其他协议就得去找改协议发送type2 处的代码,修改NegoFlags位。

    比如Http协议的话,需要修改packets.py里面的NTLM_Challenge类。

    原来是NegoFlags的值是\x05\x02\x89\xa2,改成\x05\x02\x81\xa2

  3. 然后获取到Net-NTLM v1。再使用里面的ntlmv1.py转换. 获取到Net-NTLM v1是win10::WIN10-1:F1586DA184365E9431C22EF206F5A2C918659E1B1FD7F64D:F1586DA184365E9431C22EF206F5A2C918659E1B1FD7F64D:1122334455667788 转化完的格式就是NTHASH:F1586DA184365E9431C22EF206F5A2C918659E1B1FD7F64D

  4. 再将转化完的格式用破解即可。

下面简要探究下原理,如果没有兴趣的可以直接跳过。看下一小节。

将 16字节的NTLM hash空填充为21个字节,然后分成三组,每组7字节,作为3DES加密算法的三组密钥,加密Server发来的Challenge。 将这三个密文值连接起来得到response。

但是在实践中发现,加密方式的表述是有点问题的,或者说是不完整的。上面的只是Net-NTLM v1的一种加密方式,Net-NTLM v1还有另外一种加密方式。我们下面来探讨下这两种加密方式以及利用

  • (1)加密方式1

就是前面提到的那种。

  1. 将 16字节的NTLM hash空填充为21个字节,然后分成三组,每组7字节

  2. 将三组(每组7字节)经过运算后作为DES加密算法的密钥

运算的细节是每组七个字节再转化为8小组,每个小组7个比特位。然后7个比特位进行奇偶校验后算出第8个比特位,刚好是1个字节,8个小组,每小组一个字节,凑成8个字节的密钥。

  1. 加密Server Challenge

  2. 将这三个密文值连接起来得到response。

    那这种加密方式存在什么问题呢。

    总共三组,每组8个字节作为key,加密Server Challenge获取response。

    每组可以分开计算,已知加密内容和加密后的密文算key。使用des算法,key是八个字节。

  3. (2)加密方式2

    跟第一种加密方式基本一样。最本质的区别就在于,第一种加密方式的加密内容是Server Challenge。而这种加密方式是拼接8字节Server Challenge和8字节Client Challenge后,求其MD5,然后取MD5值的前8字节做为加密内容。

    我们可以控制Server Challenge为固定的值,但是没法控制Client Challenge的值。也就是说我们没法控制加密的内容为固定的值。

    第一种是加密的内容为固定的1122334455667788的话,我们只需要建立从key到response的映射就行。而这种加密方式的话。加密的内容也是不固定的,计算的成本高多了。

    总而言之,这种加密方式不好破解,其实我们也可以不让客户端不用这种加密方式,就使用第一种加密方式。且看下面的分析。

在我们的Responder加上--lm的情况下获取到的Net-NTLM v1 hash是采用第一种加密方式,但是只针对smb协议有效,在我的测试中,即使加了--lm参数,收到的请求是Http协议的情况底下,拿到的Net-NTLM v1也是采用第二种加密方式,我们不好破解。所以我又去研究了下什么情况底下采用第一种加密方式,什么情况底下采用第二种加密方式。

可以很清楚的看到,当NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY位置为1的时候,加密的内容不是server challenge,而是md5 hash 运算过的server challeng+client challent的前8位。也就是说是第二种加密方式。

那NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag来自于哪里呢。我们知道ntlm分为type1,type2,type3。计算response就在type 3里面,NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag位就来自于type2。而type 2 里面的内容正常就是我们返回给客户端的。

也就是说,客户端选择加密方式1还是加密方式2,这个是由我们可以控制的。只需要我们把NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY位置为0,那么客户端就会选择加密方式1.并且Server Challenge为1122334455667788的情况下。我们用crack.sh快速免费有效得破解。获取到用户的NTLM Hash。

那怎么将NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY位置为0,我们一般都是使用现成的工具Resonder来获取Net-NTLM Hash。之前说过加上--lm参数就可以将NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY位置为0。

这个时候还有一个小问题没有解决,那就是Resonder加上--lm,为什么只针对smb 协议有效。其他协议无效。

我去读了下Responder的代码。

加上--lm参数之后,调用的模块就是SMB1LM

发现她用的是老板本的smb实现。而这个版本的实现是在smb 协商版本的时候就将challenge返回,并且将NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY置为0.

而且也仅仅是实现了smb协议,并没有实现其他协议。

但是完全可以不用老板本的smb实现。这里面最本质的地方在于NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY置为0.而这个flag位并不一定需要用到旧版本的smb才能置位。只需要修改NTLM SSP里面的flag位就行

在各个协议里面的NTLM SSP里面,修改flag位,我们找到Responder里面type2的NTLM SSP的flag位赋值的地方即可。

Responder里面的NTLM SSP实现没有通用性。比如smb部分的实现,在packets.py里面的SMBSession1Data类里面。

默认是0xe2898215(跟图里面不一样?大端小端)

NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY对应的是第13位,改为0,也就是0xe2818215

改下就行

http的话在packets.py里面的NTLM_Challenge类里面

Responder的NTLM SSP没有通用性,这个挺难受的,其他协议的话,大家自己找吧。跟下代码挺快的。

2. Net-NTLM v2的破解

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等等等等)。

主要有两种场景

  1. 工作组环境

    这个实用性比较差。在工作组环境里面,工作组中的机器之间相互没有信任关系,每台机器的账号密码Hash只是保存在自己的SAM文件中,这个时候Relay到别的机器,除非两台机器的账号密码一样(如果账号密码一样,我为啥不直接pth呢),不然没有别的意义了,这个时候的攻击手段就是将机器reflect回机子本身。因此微软在ms08-068中对smb reflect到smb 做了限制。这个补丁在CVE-2019-1384(Ghost Potato)被绕过。将在下篇文章里面详细讲。

  2. 域环境

    域环境底下域用户的账号密码Hash保存在域控的 ntds.dit里面。如下没有限制域用户登录到某台机子,那就可以将该域用户Relay到别人的机子,或者是拿到域控的请求,将域控Relay到普通的机子,比如域管运维所在的机子。(为啥不Relay到其他域控,因为域内就域控默认开启smb签名)

下面演示使用几款工具在域环境底下,从域控relay到普通机器执行命令

2. Relay2EWS

​ Exchange的认证也是支持NTLM SSP的。我们可以relay的Exchange,从而收发邮件,代理等等。在使用outlook的情况下还可以通过homepage或者下发规则达到命令执行的效果。而且这种Relay还有一种好处,将Exchange开放在外网的公司并不在少数,我们可以在外网发起relay,而不需要在内网,这是最刺激的。

配合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>
<!--
 Sub window_onload()
     Set Application = ViewCtl1.OutlookApplication
     Set cmd = Application.CreateObject("Wscript.Shell")
     cmd.Run("calc")
 End Sub
-->

</script>
</head>

<body>
 <object classid="clsid:0006F063-0000-0000-C000-000000000046" id="ViewCtl1" data="" width="100%" height="100%"></object>
</body>
</html>

3. Relay2LDAP

不管是杀伤力巨大的8581还是1040。Relay到ldap都在里面发挥着巨大的作用。

relay 到ldap的话,能干嘛呢

这里着重介绍三种通用性比较强的利用思路。这三种在impacket里面的ntlmrelayx都有实现。(这三种通用性比较强而已,实际中这个的利用比较灵活,需要通过 nTSecurityDescriptor分析用户在域内对哪些acl有权限,什么权限。关于acl怎么深入利用,这里不再展开,后面在ldap篇会详细说明)

  1. 高权限用户

如果NTLM发起用户在以下用户组

  • Enterprise admins

  • Domain admins

  • Built-in Administrators

  • Backup operators

  • Account operators

那么就可以将任意用户拉进该组,从而使该用户称为高权限用户,比如域管

  1. 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的 时候详细说下这个用户组的权限。

  1. 普通用户权限

在server2012r2之后,如果没有以上两个权限。可以通过设置基于资源的约束委派。

在NTLM发起者属性马上到!S-AllowedToActOnBehalfOfOtherIdentity里面添加一条ace,可以让任何机器用户和服务用户可以控制该用户(NTLM发起者)。

0x03 引用

image-20191201173245315
image-20191201174336446

之前在里面有简单介绍了下Net-NTLM v1的加密方式

在Responder如果想获取到这种加密方式的话,要加上参数--lm(仅限于smb 协议)

我们控制Server Challenge为1122334455667788,然后建立从key到response的彩虹表。就可以在知道response的情况下获取key。所幸这个网站已经帮我们弄好了,在Challenge为1122334455667788的情况下。一分钟之内就能获取ntlm hash,而且是免费的。这也是我们为啥要把Challenge设置为1122334455667788,而不是随机。

具体操作是

使用里面的ntlmv1.py转换.然后复制NTHASH:E0F8C5B5E45247B4175698B99DBB5557CCD9241EA5A55CFB到破解,填上邮箱,等到一分钟左右就能收到ntlm hash了。

在Responder默认获取到的就是这种加密方式(没有加--lm)

使用里面的ntlmv1-ssp.py转换.到破解。这种方式要钱的,而且还不一定能解的出来。

在这篇[文章]()里面有提及到,当ntlm的flag位NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY置为1的情况底下,会采用第二种加密方式,否则就会采用第一种加密方式,我们可以看下impacket里面计算Net-NTLM v1的相关代码

image-20191126132833520
image-20191126133346842
image-20191126134030335
image-20191126134218565
image-20191126134410933
image-20191126135028008
image-20191126140853639
image-20191126142621775
image-20191126135508861
image-20191201162908250

​ Net-NTLM v2 现在也没有什么比较好用的破解方式,一般就是利用hashcat 离线爆破明文密码,能不能跑出来就看字典里面有没有了。使用hashcat进行字典破解

image-20191201161335057

impacket 的底下的smbrelayx.py

impacket 的底下的ntlmrelayx.py

Responder底下的MultiRelay.py

​ 下面演示通过(事实上,工具挺多的。其他的大家可以上github自己找)来实现Relay2ews

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

image-20191129160918694
image-20191129165423234
image-20191129165352363
image-20191129164053515
image-20191129164621268
image-20191129155114943

NTLM基础介绍
crack.sh
ntlmv1-multi
crack.sh
http://d1iv3.me/2018/12/08/LM-Hash%E3%80%81NTLM-Hash%E3%80%81Net-NTLMv1%E3%80%81Net-NTLMv2%E8%AF%A6%E8%A7%A3/
LM-Hash、NTLM-Hash、Net-NTLMv1、Net-NTLMv2详解
The NTLM Authentication Protocol and Security Support Provider
Windows内网协议学习NTLM篇之发起NTLM请求
SpiderLabs版本
lgandx版本
ntlmv1-multi
crack.sh
ntlmv1-multi
crack.sh
NtlmRelayToEWS
NtlmRelayToEWS
image-20191201161721971
image-20191201162547667
image-20191201162838255
image-20191201171051773
image-20191201171244683
image-20191126122252915
image-20191126122353928
image-20191126131040382
,还成
image-20191126131242128
image-20191201160707021
image-20191126190640410
image-20191126131312228
image-20191129180841482
image-20191128171500527
image-20191128171830112
image-20191128171731605
image-20191129191508154
image-20191201181600687
image-20191129180919113
image-20191129190842538