H

NTLM Relay

HackApt-37 Team已验证会员

黑客倉庫站長

贡献: 83%

NTLM Relay​

1 NTLM 协议​

1.1 简介​

NTLM协议是Microsoft环境中使用的身份验证协议。该协议允许用户证明其对服务器的身份,以便使用服务器提供的服务。
202109240959801.png-water_print

有两个身份验证方案:
工作组环境
用户使用服务器本地帐户的密钥。由于服务器在其本地数据库中具有用户的密钥,因此它能够对用户进行身份验证。
域环境
在Active Directory环境中,用户在身份验证期间使用域帐户,在这种情况下,服务器将用户的身份验证信息发送到域控制。
在这两种情况下,NTLM身份验证均以客户端和服务器之间的“挑战/响应”机制开头。

1.2 挑战 - 响应认证机制​

挑战/响应机制的目的是允许服务器验证用户的身份,而不是通过网络传输用户密码。整个认证过程中有三个步骤。
协商 - Negotiation - type1客户端向服务器发送身份验证请求(nogotiate_message)
挑战 - Challenge - type2服务器向客户端发送64位随机值(挑战_MESSAGE)
响应 - Response - type3客户使用其用户的NT哈希值加密挑战,并将结果返回到服务器
202109241013007.png-water_print

下图显示了NTLM身份验证过程:
202109241026470.png-water_print

为了完成身份验证,服务器只需要检查客户端发送的响应的有效性即可。

1.3 认证​

NT哈希计算:
首先将用户密码转换为十六进制格式。
单座密码以十六进制格式编码。
使用MD4 Digest算法对Unicode编码数据的哈希计算
1
python2 -c'进口hashlib,binascii;打印binascii.hexlify(hashlib.new('md4','p@assword ! 123'.encode('utf-16le')).igest())'
如上所述,NTLM身份验证有两种不同的方案。

1.3.1 本地账户​

在使用本地帐户执行身份验证的方案中,服务器使用用户的密钥或用户密钥(NT Hash)的MD4哈希来对其发送给客户端的挑战。然后,它将检查其操作结果是否等于客户端的响应并证明用户的身份。
服务器需要存储本地用户的哈希值及其密码。此数据库的名称是SAM(安全客户经理)。可以在注册表中找到SAM,您可以使用PSEXEC作为系统打开它:
1
psexec.exe -i -s regedit.exe
202109241035422.png-water_print

在C: \ Windows \ System32 \ SAM下还有一个副本。
总结工作组下的认证过程:
202109241038569.png-water_print

服务器发送挑战(1),客户端使用其密钥的哈希(Hash)对挑战进行加密,然后将挑战加密使用与其用户相对应的NT哈希,并将其发送回服务器(2)。该服务器将在其SAM中查找用户密码的哈希值,加密以前与此哈希发送的挑战(3),并将其结果与用户返回的结果进行比较。如果相同的(4),用户已通过身份验证,否则,身份验证会失败。

1.3.2 域账户​

使用域帐户进行身份验证时,用户的NT哈希不再存储在服务器上,而是在域控制器上。用户想要进行身份验证的服务器将收到一条响应消息,以挑战客户端加密,但无法检查响应是否有效。因此,服务器需要委派将身份验证为域控制器的任务。
为此,当服务器与域控件通信时,使用了Netlogon服务,该服务可以与域控制器建立安全的会话,该会话称为安全通道。由于服务器知道其自己的密钥,并且域控制器知道服务器密钥的哈希,因此可以在服务器和域控制器之间牢固地交换会话密钥并牢固地通信。
客户端将netlogon_network_info发送到域控制,该控制主要包括:
1
2
3
4
5
6
7
typedef struct _netlogon_network_info {
netlogon_logon_identity_info身份;
lm_challenge lmchallenge;
字符串ntchallengesponse;
字符串lmchallengersponse;
} netlogon_network_info,
*pnetlogon_network_info;
客户端用户名(身份)
服务器发送给客户端的挑战(lmchallenge)
客户端发送到服务器的响应(ntchallengesponse)
域控制将在其数据库中查找相应的用户的NT哈希。对于域控制器,用户数据存储在ntds.dit文件中。一旦检索了NT哈希,就会计算挑战的加密值,并将结果与客户的响应进行比较。
总结域环境中的身份验证过程:
202109241107663.png-water_print

与以前的情况类似,服务器发送挑战(5),客户端JSnow与NT Hash加密,并将其及其用户名和域名(1)一起发送回服务器。服务器将使用Netlogon Service(2)将此信息发送到安全频道中的域控制器。域控制器在其NTDS.DIT数据库(3)中找到用户哈希来加密挑战,然后比较两个结果。如果是相同的(4),则已对用户进行身份验证。否则,身份验证会失败。在这两种情况下,域控制器都将信息传输到服务器(5)

2 NTLM Relay​

2.1 几种 Hash​

要避免混淆,请总结相关的哈希名词:
NT哈希和LM哈希是用户密码的哈希版本。 LM哈希完全过时,本文不会讨论。 NT哈希也通常称为NTLM哈希。此名称与协议名称NTLM相混淆。因此,在谈论用户的密码哈希时,称为NT Hash。
NTLM是身份验证协议的名称。当前有两个版本的NTLM协议。
NTLMV1响应和NTLMV2响应将用于参考客户端发送的挑战响应,并适用于NTLM协议的版本1和2。
NET-NTLMV1和Net-NTLMV2是NT Hash称为NTLM Hash时使用的伪新术语,用于将NTLM Hash与协议区分开。由于我们不使用NTLM哈希术语,因此我们不会使用这两个术语。
net-ntlmv1 hash和net-ntlmv2哈希也是避免混乱的术语,但本文也不会使用它们。

2.2 简介​

顾名思义,NTLM继电器攻击依赖于NTLM身份验证。攻击存在于以下情况下:攻击者设法位于客户端和服务器之间的中间,然后将信息从一端转发到另一端。
中间人的位置的意思是:从客户的角度来看,攻击者的计算机是他想要进行身份验证的服务器,从服务器的角度来看,攻击者是一个像其他想要对资源访问访问访问资源的客户一样的客户端。
当然,攻击者不仅要对目标服务器进行身份验证,而且还假装是受害的用户身份以控制服务器。但是,由于攻击者不知道用户的密钥,即使他听了对话,由于键从未在网络上传输,因此攻击者无法提取任何信息。那么,它如何工作?

2.3 消息中继​

在NTLM身份验证过程中,客户使用其NT Hash加密服务器提供的挑战来证明他对服务器的身份。因此,攻击者唯一需要做的就是使客户端加密,并将信息从客户端传递给服务器,并将服务器的答复传递给客户端。
攻击者将收到客户端发送到服务器的所有信息,并将其播放回真实服务器。攻击者还将接收服务器发送给客户端的所有信息,并将其转发给客户端。
202109241511048.png-water_print

实际上,从客户的角度来看,攻击者和图形左侧之间执行NTLM身份验证。客户在其第一条消息中发送了谈判请求,并且攻击者在挑战中对请求做出回应。在收到此挑战之后,客户将用其密钥构建响应,并最终发送包含加密挑战的最后一个身份验证消息。
但是,攻击者无法使用此交换做任何事情。因此,这个想法需要转到上面图片的右半。实际上,从服务器的角度来看,攻击者像其他用户一样是客户。它发送了第一条消息以索取身份验证,并且服务器对挑战做出了响应。由于有(6),真实的客户端为攻击者向真正的客户发送了这个同样的 Challenge,并以用它的密钥对这个挑战进行了加密回复。因此,攻击者可以将此有效响应发送给服务器。
这是攻击所在的地方。从服务器的角度来看,攻击者不知道将其信息重播给客户端。
因此,从服务器的角度来看,这就是发生的事情:
202109241528524.png-water_print

在这些交换结束时,攻击者使用客户端的凭据在服务器上进行身份验证。

2.4 Net-NTLMv1 and Net-NTLMv2​

这种有效的响应由3型攻击者转发,通常称为net-ntlmv1 hash或net-ntlmv2 hash。但是在本文中,如上所述,它将称为NTLMV1响应或NTLMV2响应。
确切地说,这不是挑战的加密版本,而是使用客户端密钥计算的哈希值。以NTLMV2为例,有效的响应=HMAC-MD5(UNICODE(hex(upseramame+domain)),nt hash),这种类型的哈希只能通过蛮力破裂。

3 实战​

Desktop01具有IP地址的客户端192.168.56.221和具有IP地址的Web01服务器192.168.56.211。 IP地址是192.168.56.1,是中介。攻击方案如下:
202109241543790.png-water_print

使用弹丸软件包中的ntlmrelayx进行攻击。
1
python ntlmrelayx.py -t 192.168.56.221
网络流量如下:
202109241554947.png-water_print

绿色是桌面01客户端和攻击者之间的流量,红色是攻击者和Web01服务器之间的流量。 3个NTLM消息可以清楚地看到Desktop01和攻击者之间以及攻击者和Web01服务器之间的3个消息。
为了理解继电器的概念,可以验证,当Web01向攻击者发送挑战时,攻击者将完全相同的内容发送回Desktop01。
这是Web01向攻击者发送的挑战:
202109241556604.png-water_print

当攻击者收到此挑战时,它将其发送到desktop01而不会进行任何修改。在上述过程中,挑战值是B6515172C37197B0。
然后,客户将使用其密钥来计算响应,将计算出的响应值与用户名(JSnow)和主机名(Desktop01)一起发送。在此示例中,它是域用户,因此主机名是域的域名(ADSEC)。
202109241558700.png-water_print

获得响应的攻击者将完全相同的信息发送给服务器。因此,中间人假装在Desktop01上是JSnow,并且是ADSEC域的域用户。它还发送了由客户端计算的响应,在这些屏幕截图中称为NTLM响应。称此响应为NTLMV2哈希。
从流量可以看出,攻击者只是转发数据。它只是将客户端的信息转发到服务器,反之亦然,除了服务器最终认为攻击者已成功身份验证,并且攻击者可以代表ADSEC \ JSNOW在服务器上执行操作。

4 认证与会话​

上面的文章解释了NTLM继电器的基本原理。下一个问题是,在中继NTLM身份验证之后,如何在目标服务器上执行特定操作?
要回答这个问题,必须首先澄清一个基本事实。当客户端对服务器进行身份验证以执行某些操作时,必须区分两件事:
身份验证,允许服务器验证客户端是其声称的身份。
会话,在此期间,客户将能够执行操作。
如果客户端通过正确的身份验证,它将能够访问服务器提供的资源,例如网络共享,访问LDAP目录,HTTP服务器或SQL数据库等。
要管理这两个步骤,所使用的协议必须能够封装身份验证,从而交换NTLM消息。
202109241609242.png-water_print

如果所有协议都集成了NTLM技术细节,则不符合软件工程中的脱钩想法。因此,Microsoft提供了一个接口来处理身份验证,并专门开发了用于处理不同类型的身份验证的软件包。

4.1 SSPI NTLNSSP​

SSPI接口(安全支持提供商接口)是Microsoft为标准化身份验证提出的接口。不同的协议可以使用此接口处理不同类型的身份验证过程。在NTLM身份验证中,使用NTLMSSP(NTLM安全支持提供商)。
SSPI接口提供了多个功能,包括AcqureteCredentialShandle,InitializeSecurityContext和AcceptSecurityContext。在NTLM身份验证期间,客户端和服务器都使用这些功能。简要描述以下步骤:
客户端调用获取的shandle,以获得对用户凭据的间接访问。
然后,客户端调用initializeSecurityContext,该访问将创建一个类型的类型消息在第一个呼叫上协商。对于研发,这消息是什么都没关系,将其发送到服务器很重要。
接收到消息时,服务器调用AcceptSecurityContext函数。然后,此功能将创建类型Challange的2个类型数据。
当收到此消息时,客户端将再次致电InitializeSecurityContext,但此时间将挑战作为参数。 NTLMSSP负责通过加密挑战并生成最终身份验证消息来计算响应的内容。
服务器收到消息后,它还将再次致电AcceptSecurityContext以自动执行身份验证验证。
202109241619978.png-water_print

这意味着这5个步骤完全独立于客户端的类型或服务器的类型。无论使用的协议如何,只要协议具有允许以一种或另一种方式将这种不透明结构从客户端交换到服务器的内容的内容。
202109241621606.png-water_print

因此,该协议将NTLMSSP,Kerberos或其他身份验证结构用于特定字段,如果客户端或服务器在该字段中看到数据,则将其仅传递给initializeSecurityContext或AppctionSecurityContext。
应用层(HTTP,SMB,SQL等)完全独立于身份验证层(NTLM,Kerberos等)。因此,身份验证层和应用层都需要安全措施。
通过SMB和HTTP的两个示例帮助读者更好地理解。其他协议非常相似。

4.2 HTTP NTLM​

基本HTTP请求:
1
2
3
4
5
get /index.html http /1.1
HOST: www.geekby.Site
用户代理: Mozilla/5.0
接受:文本/html
接受语言: ZH-CN
此示例中所需的元素是HTTP动词(NTLMv2 Hash),请求页面(GET)的路径,协议版本(/index.html)或主机标头(HTTP/1.1)。
但是您也可以添加其他HTTP标头。最好的情况是服务器知道这些标头将存在并且知道如何处理它们。最坏的情况是直接忽略它。
正是HTTP的这一功能可以使NTLM相关信息从客户端传输到服务器。也就是说,将授权http标头添加到客户端,并在服务器中添加www-partenenticate标头。如果客户端试图访问需要身份验证的网站,则服务器通过添加www-authenticate标头来做出响应,该标头包含其支持的不同身份验证机制。对于NTLM,返回:www-authenticate: ntlm。
知道需要NTLM身份验证,客户端将在授权标题和Base64编码中发送第一个消息(因为该消息仅包含不可打印的字符)。该服务器将在www-partenticate中填充挑战,客户端将计算响应并将其放在授权标题中。如果身份验证成功,服务器通常会返回200个返回代码。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
get /index.html http /1.1
HOST: www.geekby.Site
用户代理: Mozilla/5.0
接受:文本/html
接受语言: en
http/1.1 401未经授权
www-authenticate: ntlm
内容类型:文本/html
内容长度: 0
get /index.html http /1.1
HOST: www.geekby.Site
用户代理: Mozilla/5.0
接受:文本/html
接受语言: ZH-CH
=授权: ntlm在base64中进行谈判
http/1.1 401未经授权
=www-authenticate: ntlm&
 
后退
顶部