文章总结： ghostsurf工具解决了ntlmrelayx在浏览器代理中的关键问题，通过mutex锁解决并发冲突、cookie机制选择session、保留HTTP头等改进，支持通过SOCKS5代理以中继身份访问NTLM认证的Web应用。研究发现并绕过Windows内核认证机制，提出探测策略解决IIS内核模式认证重置问题。工具适用于CyberArk、Passwordstate等企业系统的渗透测试，需注意单TCP连接性能限制。 综合评分： 87 文章分类： 渗透测试,红队,内网渗透,WEB安全,安全工具

---

ghostsurf：从 NTLM Relay 到浏览器会话劫持

haidragon haidragon

安全狗的自我修养

2026年4月7日 12:14 湖南

在小说阅读器读本章

去阅读

官网：http://securitytech.cc

ntlmrelayx 的 SOCKS 代理对 SMB 和 MSSQL 很好用， 但当你试图用浏览器通过它访问 Web 应用时就会失败。

👉 我深入分析原因，发现它在 HTTP 处理上有多个根本性问题

👉 我构建了 ghostsurf 来解决这些问题

👉 同时还发现并绕过了一些未公开的 Windows 内核认证行为

👉 ghostsurf 可以让你通过 SOCKS5 代理，以“被中继的用户身份”浏览支持 NTLM 的 Web 应用（比如企业密码库），即使无法窃取 cookie。

工具： https://github.com/senderend/ghostsurf

---

🧭 起点（Where This Started）

在一次渗透测试中：

目标环境使用 CyberArk Privileged Access Manager

用户/管理员流程：

• 访问内部 Web 页面
• 自动使用 Windows 登录会话认证
• 从浏览器复制密码

我们：

• 控制了一个 relay 位置
• 捕获了一个高权限域账号的 NTLM（不可破解）

👉 如果能用这个用户访问 CyberArk：

就能获取所有该账号权限范围内的秘密

---

❗ 问题

ntlmrelayx 提供 SOCKS 代理功能：

• 可以通过已认证会话转发流量

👉 对 SMB / MSSQL 非常好用

但当我们：

👉 用浏览器通过 SOCKS 访问 Web

结果：

• 出现 Basic Auth 弹窗
• 页面卡住
• 响应损坏
• 页面加载失败

👉 没人有解决方案

---

🔍 于是我开始读源码

我直接去看 ntlmrelayx 的 HTTP SOCKS 插件代码

👉 然后事情开始变得有意思了

---

📊 当前 ntlmrelayx 浏览器支持现状

先启动 ntlmrelayx：

---

成功 relay 后：

• 完成 NTLM 握手
• 保存会话
• 每 30 秒 keepAlive
• 打开 SOCKS5

---

🌐 浏览器测试

配置 Firefox + FoxyProxy（127.0.0.1:1080）

访问目标：

👉 出现 Basic Auth

---

❗ 问题

这个弹窗和：

👉 未认证访问时完全一样

👉 很多人会以为攻击失败

---

🧪 实验：输入正确凭证

👉 居然失败

---

🤯 再试一次（用 /）

👉 居然成功

---

🎉 进入系统（但…）

👉 页面严重错乱

---

💥 很快崩溃

👉 会话丢失

---

❓ 为什么会这样

总结一句话：

👉 ntlmrelayx 根本不是为浏览器设计的

---

🧠 根本原因（Why Browser Proxy Broken）

核心问题：

👉 ntlmrelayx 假设：

• 单连接
• 顺序请求

👉 但浏览器不是这样工作的

---

⚠️ NTLM 特性

NTLM HTTP 认证：

👉 绑定 TCP 连接（有状态）

👉 不能用 cookie 替代

---

❗ ntlmrelayx 限制

• 每个 session 只有一个 TCP socket
• 所有请求必须走这个 socket

---

💥 浏览器行为

浏览器会：

• 开多个 TCP 连接
• 并发请求资源

👉 结果：

• 请求互相覆盖
• 数据流损坏
• 页面加载失败

---

🚫 inUse 锁问题

ntlmrelayx 使用 inUse 标志：

• 防止并发访问

👉 结果：

• 浏览器 6 个连接 → 5 个被拒

---

🤯 为什么会出现 Basic Auth

👉 不是 Web 服务器的

👉 是 ntlmrelayx 自己的！

---

📌 原因

ntlmrelayx 支持多个 session

👉 需要你选择用哪个

👉 用 Basic Auth header 来传

---

❗ 问题

浏览器看到：

👉 和正常认证完全一样的弹窗

👉 但其实是在选 session

---

🤡 更离谱

• 必须用 domain/user（正斜杠）
• 但 Web 要求 domain\user

👉 完全冲突

---

🚀 解决方案：ghostsurf

---

🧠 核心改进

1️⃣ 并发问题

👉 用 mutex 锁代替 inUse

流程：

• 获取锁
• 发送请求
• 完整读取响应
• 释放锁

👉 所有请求被序列化

---

结果

• 浏览器可以开多个连接
• 不会冲突
• 数据不会损坏

---

2️⃣ session 选择

• 单 session → 自动选
• 多 session → 页面选择

👉 用 cookie 绑定

---

---

3️⃣ 保留 HTTP 头

ntlmrelayx 会删 header

ghostsurf：

• 保留 User-Agent
• 保留 cookie
• 保留其他头

---

🧬 内核认证研究（重点）

测试真实软件时发现新问题：

👉 Passwordstate 会突然重新认证

---

📊 现象

• 前 30~50 请求正常
• 然后突然 401

---

🔍 原因

IIS 启用了：

👉 Kernel Mode Authentication

👉 认证在 HTTP.sys（内核）完成

---

---

📌 关键发现

访问顺序：

1. 认证资源 ✅
2. 匿名资源 ✅
3. 再访问认证资源 ❌（401）

---

🧠 推测机制

内核模式下：

👉 认证状态像开关

访问匿名资源：

👉 重置为 Anonymous

---

---

🛠 解决方法

ghostsurf 使用：

👉 探测策略（probe-first）

---

📌 逻辑

1. 先用匿名请求
2. 如果返回：

• 401 → 需要认证 → 走 relay
• 200 → 公共资源 → 直接返回

---

---

📌 优化

• 结果缓存
• 后续无开销

---

⚙️ 使用方法

./ghostsurf -t https://target -k-r

• -k

  ：内核认证绕过

• -r

  ：允许多用户

---

---

📌 浏览器配置

• Firefox + FoxyProxy
• SOCKS5 → 127.0.0.1:1080

---

📌 查看 session

ghostsurf> socks

---

📌 浏览访问

---

⚠️ 使用 -k 场景

适用于：

• IIS 默认配置
• CyberArk
• Passwordstate
• SCCM 等

👉 不确定就开

---

🔍 进一步用途

ghostsurf 可以：

👉 用浏览器真实交互

👉 帮你分析复杂 Web 应用

👉 开发新攻击模块

---

⚠️ 限制

• 单 TCP → 性能有限
• 不支持 WebSocket

---

🍪 为什么不能直接偷 cookie？

情况 1：匿名 + Windows Auth

👉 有 session cookie → 可以复用

---

情况 2：仅 Windows Auth

👉 每次请求都要 NTLM

👉 cookie 没用

---

✅ 结论

👉 必须用代理（ghostsurf）

• 公众号:安全狗的自我修养
• vx:2207344074
• http://gitee.com/haidragon
• http://github.com/haidragon
• bilibili:haidragonx

#

• 

#

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全狗的自我修养 haidragon haidragon《ghostsurf：从 NTLM Relay 到浏览器会话劫持》