渗透技巧——通过 HTTP 协议获得 Net-NTLM hash

Question

0x00 前言

在之前的文章 《Windows 下的密码 hash——NTLM hash 和 Net-NTLM hash 介绍》 、 《渗透技巧——利用 netsh 抓取连接文件服务器的 NTLMv2 Hash》 和 《渗透技巧——利用图标文件获取连接文件服务器的 NTLMv2 Hash》 曾介绍了通过 SMB 协议获得登录用户 Net-NTLM hash 的方法，利用的前提是客户端通过界面使用 SMB 协议连接服务器时，默认先使用本机的用户名和密码 hash 尝试登录。

对于 HTTP 协议，也同样支持 NTLM 认证。那么，通过 HTTP 协议能否同样获得当前登录用户的 Net-NTLM hash 呢？限制条件有哪些？如何防御？本文将要逐一介绍。

0x01 简介

本文将要介绍以下内容：

• NTLM Over HTTP Protocol 简介
• 找出利用前提
• 如何具体利用
• 防御思路

0x02 NTLM Over HTTP Protocol 简介

• 官方文档： https://msdn.microsoft.com/en-us/library/cc237488.aspx
• 参考资料： https://www.innovation.ch/personal/ronald/ntlm.html

使用 HTTP 协议的 NTLM 认证流程：

1. 客户端向服务器发送一个 GET 请求，请求获得网页内容
2. 服务器由于开启了 NTLM 认证，所以返回 401，提示需要 NTLM 认证
3. 客户端发起 NTLM 认证，向服务器发送协商消息
4. 服务器收到消息后，生成一个 16 位的随机数（这个随机数被称为 Challenge),明文发送回客户端
5. 客户端接收到 Challenge 后，使用输入的密码 hash 对 Challenge 加密，生成 response，将 response 发送给服务器
6. 服务器接收客户端加密后的 response，经过同样的运算，比较结果，若匹配，提供后续服务，否则，认证失败

直观的流程图，如下图

注： 图片截取自 https://www.innovation.ch/personal/ronald/ntlm.html ，具体的消息格式可查看链接中的介绍

实际测试

服务器：

• OS: Server2012 R2
• IP: 192.168.62.136
• 安装 IIS 服务

客户端：

• OS: Win7 x86
• IP: 192.168.62.134

1、服务器开启 NTLM 认证

进入 IIS 管理页面，如下图

选择 Authentication

关闭其他认证，只开启 Windows Authentication

添加 Provider : NTLM

配置如下图

2、服务器运行 Wireshark，进行抓包

只提取 HTTP

3、客户端访问服务器

弹框提示输入用户名密码，如下图

此时服务器抓取的 HTTP 数据包如下图

对应流程 1 和 2

4、客户端输入正确的用户名密码

此时服务器抓取的 HTTP 数据包如下图

对应流程 3-6

5、使用 Hashcat 对该 Net-NTLM hash 进行破解

NTLMv2 的格式为：

username::domain:challenge:HMAC-MD5:blob

通过数据包获得 challenge，如下图

通过数据包获得 username、domain、HMAC-MD5 和 blob

如下图

拼接格式，使用 hash 破解即可

详细细节可参考：

《Windows 下的密码 hash——NTLM hash 和 Net-NTLM hash 介绍》 中的 0x03 部分

0x03 利用分析

经过以上的测试，可以看到 HTTP 协议的破解同 SMB 协议类似，那么在利用上是否相同呢？

我们知道，使用 SMB 协议通过界面操作连接服务器时，默认先使用本机的用户名和密码 hash 尝试登录，而刚才的测试没有发现 HTTP 协议也具有这个特性

也就是说，只要用户不输入正确的用户口令，服务器就无法获得正确的 Net-NTLM hash，无法进一步利用

并且，Responder 和 Inveigh 的 HTTP 认证拦截功能也提到能够获得用户的 hash，地址如下：

• https://github.com/SpiderLabs/Responder
• https://github.com/Kevin-Robertson/Inveigh

这个功能该如何使用？能够获得哪种 hash？能不能获得客户端当前登录用户的 hash？

我在 IE 浏览器的配置中找到了答案

打开 IE 浏览器，找到如下位置：

工具 -> Internet 选项 -> 安全 -> 自定义级别 -> 用户验证

如下图

默认情况下，用户认证的登录方式为 Automatic logon only in Intranet zone

所以接下来需要做两个测试

测试一

将登录方式修改为 Automatic logon with current user name and password

重启 IE 浏览器，再次测试

客户端通过 IE 访问服务器，弹出登录验证框，此时查看服务器的抓包情况

如下图

发现客户端自动先使用本机的用户名和密码 hash 尝试登录，这时我们就能够通过进一步破解还原出用户口令，同 SMB 的利用思路一致

测试二

改为域环境，其他不变

客户端也会先使用本机的用户名和密码 hash 尝试登录

至此，我们找到了限定条件，通过 HTTP 协议获得当前登录用户的 Net-NTLM hash 适用于以下两种情况：

1. 客户端用户认证的登录方式为 Automatic logon with current user name and password
2. 用户认证的登录方式默认不变，客户端同服务器需要在同一 Intranet zone

同样，这也是 Responder 和 Inveigh 支持 HTTP 协议用户 hash 获取的利用前提

0x04 具体利用方法

1、Intranet zone 下使用 Responder 和 Inveigh

如果是在工作组环境下，无法获得当前登录用户的 Net-NTLM hash，可在域环境下使用

2、已获得客户端权限，修改用户认证方式

对应注册表 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 下的键 1A00

• 0 表示自动使用当前用户名和密码登录
• 10000 表示用户名和密码提示
• 20000 表示只在 Intranet 区域自动登录，默认值
• 30000 表示匿名登录

如果将客户端用户认证的登录方式修改为 Automatic logon with current user name and password ，那么客户端在访问任何需要登录验证的网站都会先使用本机的用户名和密码 hash 尝试登录

0x05 防御

结合利用思路，在此提出防御建议：

用户认证方式应禁止设置为 Automatic logon with current user name and password ，对应注册表键值禁止被修改为 0

查询命令如下：

REG QUERY "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" /v 1A00

否则，很有可能被破解出客户端当前登录用户的口令

0x06 小结

本文介绍了通过 HTTP 协议获得客户端当前登录用户 Net-NTLM hash 的方法，找到限制条件(Intranet zone 下或者用户认证方式被修改为 Automatic logon with current user name and password )，限制条件同样适用于 Responder 和 Inveigh 的 HTTP 认证拦截功能，最后给出防御建议： 用户认证方式应禁止设置为 Automatic logon with current user name and password。