NTLM Relay
1 前言
1.1 背景介绍
NTLM继电器,中间攻击或重播攻击是相同的。B是SMB服务器,A用于身份验证。 B将A的身份验证信息转发给C。如果A的凭据成功地验证了C,则可以执行下一个操作,例如创建执行命令的服务。如果您控制域中的某些通用服务,例如Web OA系统,文件共享和其他服务,则可以尝试使用SMB继电器攻击来吸引域管理员访问它们,以实现从其他机器获得权限的目的。
2001年,它首先由动态,smbrelay实施
2004年,它发展成HTTP -SMB,Blackhat,未打开
2007年,将HTTP -SMB集成到Metasploit中
2008年,实施了HTTP -HTTP的NTLM攻击(MS08-067)
1.2 认证过程
两端模型:
三端模型:

在域环境下的 NTLM Relay 的模型:

1.3 HTTP - SMB 攻击实验
1.3.1 nmap 探测 SMB 签名
NMAP扫描:1
nmap -p445 -script=smb-security mode.nse ip-open
1.3.2 使用 ntmlrelayx.py 测试
ntmlrelayx.py脚本in帝国包装1
ntlmrelayx.py -tf hosts.txt -socks -smb2support

注意
启动攻击时,HTTP -SMB,打开端口80,并确保未占据端口。
攻击成功后,将在攻击机上本地打开1080个袜子端口,并且可以通过代理工具(例如Proxychain)控制目标机器。
1
2
#Mac Proxychain-ng
proxychains4/users/geekby/opt/anaconda3/bin/python secretsdump.py pentest.com/[email protected]

注意
执行身份验证时,将提示您输入密码。空白地使用继电器凭据进行身份验证。
1.4 Hot Potato
Hot Potage是使用NTLM继电器来控制高授权用户的经典示例。您可以参考文章“马铃薯家族力量提升分析”。1.5 NTLM Relay 防御
目前有许多NTLM重播攻击的防御措施,主要包括以下内容:SMB LDAP签名
EAP(增强保护身份验证)
LDAPS通道
服务器目标SPN验证
1.5.1 SMB LDAP 签名
完成身份验证后,应用程序服务器和客户端之间的所有流量均通过签名验证保护;用户签名的会话密钥是根据客户端的NTLM值生成的,并且应用程序服务器在Netlogon阶段的DC服务器中获取;客户端使用与DC相同的算法,并根据其自己的NTLM值生成会话密钥,因此中间攻击无法获得会话密钥
1.5.2 EAP (Enhanced Protection Authentication)
NTLM身份验证与安全通道约束。在NTLM身份验证过程中,最后一个NTLM身份验证数据包包含目标应用程序服务器的证书摘要。使用客户的NTLM值签名和保护此摘要,以防止伪造证书的攻击。1.6 关于 NTLM 协议的一些总结
NT Hash=MD4(UNICODE(HEX(passwess)))NTLMv2 Hash=HMAC-MD5(unicode(hex(upseramame+域))),nt hash)
NTProofStr=HMAC-MD5(挑战+数据,NTLMV2 HASH)
Session Key=HMAC_MD5(HMAC_MD5(NTLMV2响应+挑战,NTLMV2 HASH),NTLMV2 HASH)
MIC=HMAC_MD5(agnotiate_message +挑战_MESSAGE + AUTHENTICATE_MESSAGE,会话密钥)
2 CVE-2015-0005
2.1 原理
从用户客户端接收身份验证信息后,应用程序服务器必须依靠域服务器进行身份验证,并将接收到的身份验证信息发送到域服务器。此过程基于Netlogon协议。该协议在应用程序服务器和域服务器之间建立了安全的会话,并且根据应用程序服务器主机帐户的密码NTLM生成安全的会话共享密钥。2.1.1 NETLOGON 步骤
所有人都远程致电到身份验证服务器NetRlogonSamloginex
netrlogonsamlogonwithflags
Netrlogonsamlogon
netrlogonsamlogoff
Win10x64en $上的
2.1.2 攻击场景
用户邪恶,访问内部服务器Win2008R2 $的SMB服务,并使用NTLM身份验证方法。域服务器是Win2016-DC01 $,并且对身份验证过程总结如下:win10x64en $首先启动连接ntlm_negotiate至Win2008R2 $的SMB 445端口,并进行谈判使用NTLM身份验证;
收到Win2008R2 $后,发送NTLM挑战赛以返回Win10x64en $;
在收到NTLM挑战之后,Win10x64en $向Win2008R2 $发送NTLM身份验证消息;
WIN2008R2 $的密码NTLM在Win2008R2 $和域控制服务器之间共享,以生成会话密钥并创建NetLogon Secure Session。 win2008r2 $通过RPC调用域服务器的NetRllogonSamlogonWithFlags函数,并将Win10x64en $发送的所有身份验证信息填充前面的挑战信息作为参数;
域服务器收到信息后,它将验证身份验证信息。如果身份验证是合法的,则返回status_success;
如果NetRlogonSamLogonWithFlags呼叫成功,则应用程序服务器将返回NetLogon_Validation数据结构,该结构可能以以下结构之一结束: NetLogon_validatin_sa_fo,netlogon_validation_sam_info2,netlogon_info2,netllogon_valogon_val_sam_samivo4。该结构中有一个重要的数据,即SessionKey,用于签名,加密等。用户客户端和应用程序服务器之间。

SessionKey是根据客户端用户的密码NTLM生成的。应用服务器从DC获得。客户端用户使用相同的算法自己生成它。因此,应用程序服务器和客户端不需要与SessionKey进行交互;

第二个参数是主机名(Microsoft的说明“计算机名称:)包含netbios名称的Unicode字符串调用此方法的客户端计算机名称”)。主机名是调用该函数的客户端主机名,即应用程序服务器通过RPC远程调用的函数。因此,从理论上讲,主机名应与应用程序服务器和域服务器之间的安全会话密钥的主机帐户保持一致。

因此,只要域中的任何主机都可以获取以前的用户和应用程序服务器的身份验证信息,它就可以启动Netlogon到域服务器以获取SessionKey,以便可以在应用程序服务器和客户端用户之间建立数据签名以满足中间人的中间攻击。
2.2 实战
在Impack中使用Smbrelayx进行中间攻击。如果目标机迫使SMB签名,则该模块将使用Netlogon直接获得签名的SessionKey。环境:
攻击机(非域内主机):192.168.68.24
客户端服务器(被中间人攻击的服务器):Server-2008
目标主机、应用服务器:Windows Server 2012-172.16.147.130
信息
如果它是非域主机,则需要指定当前域中任何主机的哈希,并指定域控制IP。
1
python2 smbrelayx.py -h 172.16.147.130 -machine-account pentest-ad/SERVER-2008$ -machine-hashes bab7079288e58b875c46601f274001e6:bab7079288e58b875c46601f274001e6 -domain 172.16.147.130
您可以使用-e参数指定目标计算机执行的文件。如果未指定,则默认转储下的目标计算机的哈希(Hash),-c可以指定要执行的命令。

2.3 防御
Impact Windows Server 2012及以下,对个人PC没有影响Microsoft发布了补丁MS15-027,修补了此漏洞,检查了Computername和NetBios的两个字段,并签署了此消息身份验证块的验证。
3 CVE-2019-1019
在修补了CVE-2015-0005漏洞之后,域服务器将验证Computername和NetBios的两个字段是否一致。但是,如果丢失了Computername字段,则域服务器会接受它,并且在身份验证消息上不执行完整性验证(MIC)。3.1 原理
由于NTLM_Authentication消息中的许多信息(包括ComputerName字段信息)是从NTLM-Challenge复制并获得的,因此攻击者可以拦截应用程序服务器发送给客户端的挑战信息并删除Computername字段。在客户端收到挑战信息之后,随后的NTLM_Authentication将无法包含该字段,因为找不到Computername字段。
通过配置,NTLM可以启用完整性验证,也就是说,在身份验证消息中添加字段麦克风(消息完整性代码)。这是新版本中默认情况下启用的函数。 MIC用于保护NTLM身份验证数据包的完整性,即NTLM_Challenge。
MIC通过SessionKey Session密钥通过HMAC_MD5算法实现完整性保护。在先前的分析中,我们有能力获得此SessionKey,因此我们可以在修改后重新计算MIC。


客户端将NTLM_NEGOTITE启动到应用程序服务器,并由重播攻击者捕获
攻击者将ntlm_negotiate转发到真实的应用程序服务器,这是我们的攻击目标
应用程序服务器将NTLM_Challenge返回到攻击者
重播攻击者删除NTLM_Challenge中的Computername字段,并将其转发给客户
客户端接收修改后的NTLM_Challenge,并基于此信息构造NTLM_Authenticate,将身份验证信息发送给播放攻击者。目前,身份验证消息已经包含麦克风
重播攻击者将Netlogon会话请求启动到域服务器。由于身份验证消息中缺少ComputerName字段
重播攻击者重新计算麦克风并将新的NTLM_Authenticate发送到应用程序服务器
应用程序服务器接收NTLM_Authenticate之后,它将检查麦克风,然后启动Netlogon会话请求到域服务器。域服务器返回一个成功的身份验证响应,该响应包含会话密钥,该响应与步骤6中的会话密钥相同。
重播攻击者成功建立了与应用程序服务器的签名会话,并在应用程序服务器上获得了客户端用户的访问权限。如果客户端用户是管理员,并且应用程序服务器是域服务器,则重播攻击者在域服务器(Application Server)上具有管理员权限(客户端)。
3.2 实战
使用ntlmrelayx.py infacket中使用-emove-target参数执行中间攻击。
1
python3 ntlmrelayx.py -H 172.16.147.130 -emove-target-enum-local-admins -smb2support -machine-machine-acccount pentest-ad/server-ad/server-ad/server-ad/server-2008 $ -Machine-Hashes-Machine-Hashes BAB7079288E58B875C46601F274001E63:BAB7079288E58B875C46601F274001E6 -DOMAIN 172.16.147.130.130.130.130
4 CVE-2019-1040
4.1 原理
安装CVE-2015-0005的补丁后,系统检查了NetBios的名称和NetRlogonSamlogonWithFlags函数的NetBios的名称和ComputEname参数。因此,通过修改Computername获取SessionKey的先前方法失败。但是,如果删除或消失了身份验证信息中的NetBios,则身份验证服务器将不再执行先前的名称验证,这意味着我们可以修改Computername参数以实现CVE-2015-0005脆弱性的效果并获得会话密钥。
在这种情况下,可以通过配置“服务器拒绝没有NetBios的任何请求”来阻止此类攻击。但是,在NTLMV1中,该字段在NTLM消息块结构中不可用,因此这种攻击很难通过NTLMV1场景中的策略或补丁消除,并且它仍然具有很大的脆弱性。
当客户端和服务器在NTLM中进行协商时,他们会在下图中使用协商(即MSVAVFLAGS字段)来确定是否需要MIC来保护会话的完整性,请参见下图中的“红色框标记”。

当SMB客户端获得NTLM认证时,默认设置需要麦克风进行完整性验证保护。从直觉上讲,通常有几种与麦克风斗争的方法。一种是修改麦克风,先决条件是获取会话密钥。正如我们之前看到的:如果配置了保护策略,则无法通过删除NetBios获得会话密钥;另一个是直接丢弃麦克风。目前,需要修改MSVAVFLAGS字段中的标志位以及版本信息,因为某些版本默认情况下必须具有MIC。
MSVAVFLAGS字段的定义,检查Microsoft知识库。如果是0x00000002,则意味着客户端使用MIC来保护数据包的完整性。

MSVAVFLAGS字段受用户的NTLM哈希值保护,因此无法修改MSVAVFLAG字段。实际上,这是非常神奇的。域服务器并不真正在乎是否存在麦克风和版本信息。如果存在,它将进行验证,如果不存在,它将无法进行验证。
上述攻击方法可以通过配置阻止,也就是说,如果MSVAVFLAGS字段表明存在MIC完整性验证,则必须进行MIC和验证。但是,在实际的应用程序方案中,仍然存在一些隐藏的危险,例如MacOS和Linux系统中的Firefox默认情况下不会添加麦克风。
4.2 实战
使用impacket中的ntlmrelayx.py使用- 示波器- 麦克马云惹不起马云麦克(MIC)参数来执行中间攻击。
1
python3 ntlmrelayx.py -h ldap://172.16.147.130 --remove-mic --escalate-user commonuser -smb2support -machine-account pentest-ad/SERVER-2008$ -machine-hashes BAB7079288E58B875C46601F274001E63:BAB7079288E58B875C46601F274001E6 -DOMAIN 172.16.147.130.130.130.130
5 EPA-Bypass
5.1 原理
EPA(对身份验证的增强保护)将身份验证数据包绑定到安全的频道,主要用于保护Windows Integrated Adenthication服务,例如OWA,ADFS和LDAPS。具体方法是将字段通道绑定到身份验证消息中。根据Microsoft的说明,通道绑定是MD5哈希值,代表结构GSS_CHANNEL_BINDINGS_STRUCT的MD5HASH值。