说到内网渗透不知道大家有没有一种感觉越往后打拼的越不是漏洞利用的骚操作而是对“信任”二字的利用程度。我这两年参加过几次攻防演练也在客户现场处理过一些终端告警发现向日葵这类远程控制软件反复出现在事后的分析报告里。而杀软这边往往一开始并没有直接拦截直到后面做深度排查时才发现攻击者早就在用它的合法身份在目标内网里行动了。这个现象挺值得拿出来聊聊——它不是某个工具的问题而是一种典型的“可信工具滥用”思路。借着一次实战演练的复盘场景我把整个思考链路和处置过程整理了出来。内容不涉及具体工具怎么实现绕过也不讨论任何恶意代码细节重点讲清楚攻击者为什么偏爱向日葵这种软件、防守方该怎么从日志和告警里把它盯出来以及事后如何收敛这一类风险。如果你是刚接触安全运营、又在企业里负责终端管控的同学这篇应该能给你省不少事。1. 告警复盘向日葵为什么会出现在攻击链里先说那次让我印象深刻的演练复盘。某天下午终端管控平台弹出一条中危告警一台办公区的Windows主机上出现了陌生版本的向日葵进程而且该进程存在外联行为。当时第一反应是有员工自己装了远程软件但查了软件分发系统之后发现这台机器并不在向日葵的授权安装名单里。这时候就有意思了。顺着进程链往上追启动它的父进程是一个早就结束的文档阅读器进程这基本可以断定不是员工主动双击安装的而是有程序通过漏洞利用或者脚本下发带起来的。再看这台主机的登录日志前一天的深夜有过一次来自内网其他网段的远程登录记录账号是某位已经离职同事的遗留账号。到这里整条攻击链的雏形已经出来了。很多人会问为什么攻击者不直接用原生的恶意远控工具偏偏要搞一个向日葵出来答案其实就藏在企业自身对软件的管理习惯里。向日葵这类工具有几个天然优势首先是分发面极广几乎每家企业都有人装过管理员和杀软都不敢轻易把它一刀切其次它的核心功能就是远程控制穿透内网、绕过边界防火墙这件事对它来说是本职业务最后它的进程名、签名、行为特征在安全人员眼里太熟悉了容易出现“审计疲劳”。这些特性叠加在一起它在攻击者的工具清单里排得很靠前几乎成了继常用渗透框架之后的首选跳板。换句话说攻击者并不需要造一把没人见过的刀他只需要把大家每天都在用的刀捡起来。所谓“帮我干掉了杀软”本质不是把杀软进程干掉了而是让杀软很难在第一时间判定它是恶意的。严格讲这属于利用合法工具规避检测的思路比直接对抗杀软更常见、也更难防。防守方真正要解决的不是“向日葵不能出现”而是“它为什么出现在不该出现的位置以及出现之后我们能不能看见”。2. 熟悉带来的盲区可靠签名和常驻进程让告警变成了噪音我见过不少安全管理员第一次看到向日葵进程时的反应看一眼签名是正常的再看一眼业务部门确实有人在用然后就放行了。这恰恰是攻击者想要的效果。向日葵的进程会常驻会监听本地端口会定期向外发起连接这些行为单独摘出来每一项都跟正常使用没区别。但它一旦跑在攻击者控制的上下文中意义就完全不同了。这里要展开说一下“白身份”为什么可怕。杀软也好EDR也好判定一个程序是否可疑核心看三件事文件是否来自可信来源、运行后的行为是否符合该类软件的预期、以及它在这个环境里有没有合理的使用场景。前两点向日葵都完美符合唯独第三点需要结合资产归属、使用记录、登录日志去判断而这恰恰是很多终端防护产品不太擅长的。规则引擎往往只能回答“这是什么”回答不了“这个环境里它该不该出现”。我当时在复盘过程中专门查了那台主机的安全日志发现向日葵安装完成之后第一时间就有进程尝试读取本机的浏览器保存的凭证随后又通过计划任务建立了自启动项。这些行为如果单独发生在恶意程序身上告警早就该炸了但因为父进程是向日葵部分规则直接走了放行或者低优先级。这不是产品缺陷而是规则设计时一定会遇到的互相矛盾既要防滥用又不能因为误杀影响所有正常用户。所以真正的问题不是杀软不行而是我们过度依赖了杀软的单点识别能力忽略了日志关联分析。要想把这个盲区补上必须把进程视角调整到“上下文视角”。这也是我在后面几个部分想重点展开的。3. 一条告警的排查链路怎么从日志和进程链里盯出异常如果你在值班时也遇到类似的“合法远程控制软件”告警我建议不要急着点“允许”或“隔离”按照下面的链路把信息捞出来大多数情况下能直接看清是不是有问题。3.1 先看进程链和启动方式拿到告警之后第一件事不是看进程本身而是看它的父进程。打开任务管理器或者EDR的进程树确认向日葵是由用户直接双击启动还是被其他进程拉起。常见的可疑场景包括父进程是文档阅读器、脚本宿主、浏览器子进程或者父进程早已结束只剩一个孤儿进程。这些都不符合正常安装后手动打开的逻辑。然后是安装时间。对比一下向日葵的安装目录创建时间、服务创建时间、机器开机时间。如果是攻击者投递的这些时间往往高度集中可能都在同几分钟内还会伴随若干临时目录的生成。正常的员工安装软件不会在凌晨三点一口气创建这么多文件。3.2 再查网络连接和关联域名向日葵这类软件工作的时候必然有外部连接。EDR或防火墙会话日志里可以查这条进程的连接记录重点看目标IP和端口。正常的远程控制一般连到它自己的服务器端口固定且流量特征相对稳定。但如果是被攻击者利用你可能会看到连接的目标既包括官方服务器也包括内网其他主机的管理端口甚至还会出现直连某个未知IDC机房的IP这就非常说明问题了。我处理的那次告警向日葵除了连它自己的服务器还在几分钟内主动连接了同一网段里另外三台主机的高位端口。顺着这三台主机反查果然都出现了相同的进程和服务。这就不是“装了个软件自己用”能解释的了这是一条已经在横向扩散的链路。3.3 对照登录日志和账号活动进程层面有疑点之后进入系统日志把时间窗口拉出来。用下面这张表可以作为排查的参考基线每一项都对应一个“为什么可疑”的判断依据排查项正常现象可疑特征安装时间工作时间、分散凌晨集中出现父进程用户资源管理器手动运行文档类程序、脚本宿主外联目标官方服务器固定IP夹杂内网IP和未知机房登录账号该设备正常使用者离职账号、服务账号对应计划任务无或用户自建高权限计划和自启动项把这几项汇总之后基本就能对这台机器的状态有一个明确判断。需要注意的是单独某一项异常不一定说明就是攻击但多个维度同时命中就要果断进入下一步处置流程。不要等到杀软弹窗告诉你“这是恶意软件”那就已经晚了。4. 处置与取证让受控设备“离线”不是终点还原入口才算闭环确定一台主机存在可疑的远程控制行为之后最常见的错误是第一反应就是断网重装。这样干净是干净但入口没找到攻击者明天还能换个方式再进来。我一般建议按下面的顺序处理。第一步是隔离而非直接关机。保持进程运行状态通过防火墙策略把主机的所有外部通信拦截掉只保留到安全取证网段的通道。这个做法的目的是尽量保住内存里的证据包括已经建立的连接、进程注入痕迹、加载的DLL列表等等。一旦直接强制关机很多关键证据就留在磁盘的页面文件里提取难度会大不少。第二步才是进程和持久化排查。在隔离状态下导出进程列表、网络连接、计划任务、服务列表、注册表自启动项。重点看向日葵的安装目录下有没有额外的DLL或驱动文件被释放以及有没有同名进程并存——我之前遇到过攻击者把恶意模块改名放进向日葵目录下的情况表面上看还是那个软件实际加载的东西早就换了。第三步是顺着时间线还原入口。远程登录日志从哪台机器发起、账号是什么时候被创建或启用的、文件是通过什么渠道落地到这台主机的这三件事必须问清楚。在我参与的那次演练里最终溯源结果是通过某台互联网暴露的测试服务器被拿下攻击者用其中的一个脚本拿到了域内账号再通过该账登录了多台办公机。向日葵只是他部署在办公网里的一把“钥匙”入口其实在外面。对这一类事件的处置结论我倾向于把它定义为一次成功的“可信软件滥用”而不是简单当成恶意软件清除。清除恶意文件只是治疗了症状入口和账号的收敛才是治本。如果复盘到最后发现入口没有定位到建议先不要急于关闭事件工单至少要把该收敛的账号清掉、把暴露面降下来否则大概率过几周还会爆一次类似的事件。5. 收口与加固把“远程控制工具”变成可管可控的资产事件处置完之后接下来要解决的是长期问题。很多企业不是没有杀软也不是没有防火墙而是对远程控制类软件缺乏统一管理策略。别人装了一个你为了安全直接全网禁止业务那边立刻不乐意可如果完全放任就会出现上面这种被利用的场面。这里分享几个我在落地时验证过有效的做法。5.1 先盘点再收敛不搞一刀切第一步是把全网的远程控制类工具扫出来识别维度包括但不限于进程名、签名、安装路径、注册表卸载项、占用的本地端口。把扫描结果按照部门和用途打标签哪些是IT运维专用、哪些是业务协作需要、哪些完全没人申报。针对无人申报的可以直接在管控台上创建规则逐步下线。针对有需要的记录使用人和使用时间段做到每台机器上的远程软件都能对应到负责人。这个过程别用“装了就违规”的思路去推会引发很大的反弹。比较顺滑的沟通方式是先出一份常用软件台账找各部门确认用途再更新终端管控策略。真正异常的情况往往只占少数重点盯住这部分就行。5.2 出方向网络策略和端口收敛远程控制软件要工作必须有出方向连接。既然它必须连接到外部那就不能让它连得过于随意。建议在边界防火墙上对这类软件的外联IP段做白名单只放行其官方服务节点其他地址一律阻断。同时在本机防火墙上限制它监听所有网卡只允许绑定到特定接口减少被内网其他主机访问的面。端口层面也是同理向日葵默认占用的那组端口如果当前业务没用到可以在主机防火墙里直接禁掉。攻击者就算把它带进来了也会发现连接建不起来。很多情况下这一步就能阻断一大半的滥用场景因为后续脚本往往会因为连不上而失败。5.3 杀软和EDR规则要加“上下文”选项最后才是规则优化。不建议简单加一条“发现向日葵进程即告警”那是制造噪音。更好的思路是组合告警向日葵进程创建时如果父进程不是用户资源管理器或者该机器不在远程软件授权名单里或者存在跨网段横向连接则触发中高危告警。这样既能保留下正常使用场景又能把可疑行为单独拎出来。还有一点容易被忽略定期检查账号体系。那次演练里真正让攻击者畅通无阻的是多个长期未启用的账号仍然保持有效状态。账号不清理再强的杀软和EDR都是挡不住合法登录的。把账号生命周期管理纳入和终端管理同等重要的位置你会发现很多“杀软失效”的疑难杂症其实出在身份层面。6. 一点个人经验与建议复盘过几次这类事件之后我自己最大的感受是当攻击者选择用一款正常的远程控制软件干活时单靠杀软的“认识恶意文件”能力已经不够用了。我们需要意识上的转变——安全运营的核心竞争力正在从“识别坏东西”变成“理解好东西在环境里是否合理”。向日葵本身不是恶意的但它出现在不该出现的位置配合上异常的登录和连接行为就构成了完整的风险信号。如果你所在的团队还没有形成这种基于上下文的排查习惯建议先从一次小范围演练开始让值班同学用一台测试机模拟装一次未经审批的远程软件再对照我上面说的几个排查步骤走一遍。这个过程不需要真实攻击场景很快就能让团队建立对“可信工具滥用”这一类事件的敏感度。安全这件事提前把手感练出来真正遇到问题的时候才不至于慌。 
长河君 · 2026/10/20 5:59:25 · 阅读 1.2k 可信工具滥用：向日葵如何成为内网渗透的跳板与防御策略
说到内网渗透不知道大家有没有一种感觉越往后打拼的越不是漏洞利用的骚操作而是对“信任”二字的利用程度。我这两年参加过几次攻防演练也在客户现场处理过一些终端告警发现向日葵这类远程控制软件反复出现在事后的分析报告里。而杀软这边往往一开始并没有直接拦截直到后面做深度排查时才发现攻击者早就在用它的合法身份在目标内网里行动了。这个现象挺值得拿出来聊聊——它不是某个工具的问题而是一种典型的“可信工具滥用”思路。借着一次实战演练的复盘场景我把整个思考链路和处置过程整理了出来。内容不涉及具体工具怎么实现绕过也不讨论任何恶意代码细节重点讲清楚攻击者为什么偏爱向日葵这种软件、防守方该怎么从日志和告警里把它盯出来以及事后如何收敛这一类风险。如果你是刚接触安全运营、又在企业里负责终端管控的同学这篇应该能给你省不少事。1. 告警复盘向日葵为什么会出现在攻击链里先说那次让我印象深刻的演练复盘。某天下午终端管控平台弹出一条中危告警一台办公区的Windows主机上出现了陌生版本的向日葵进程而且该进程存在外联行为。当时第一反应是有员工自己装了远程软件但查了软件分发系统之后发现这台机器并不在向日葵的授权安装名单里。这时候就有意思了。顺着进程链往上追启动它的父进程是一个早就结束的文档阅读器进程这基本可以断定不是员工主动双击安装的而是有程序通过漏洞利用或者脚本下发带起来的。再看这台主机的登录日志前一天的深夜有过一次来自内网其他网段的远程登录记录账号是某位已经离职同事的遗留账号。到这里整条攻击链的雏形已经出来了。很多人会问为什么攻击者不直接用原生的恶意远控工具偏偏要搞一个向日葵出来答案其实就藏在企业自身对软件的管理习惯里。向日葵这类工具有几个天然优势首先是分发面极广几乎每家企业都有人装过管理员和杀软都不敢轻易把它一刀切其次它的核心功能就是远程控制穿透内网、绕过边界防火墙这件事对它来说是本职业务最后它的进程名、签名、行为特征在安全人员眼里太熟悉了容易出现“审计疲劳”。这些特性叠加在一起它在攻击者的工具清单里排得很靠前几乎成了继常用渗透框架之后的首选跳板。换句话说攻击者并不需要造一把没人见过的刀他只需要把大家每天都在用的刀捡起来。所谓“帮我干掉了杀软”本质不是把杀软进程干掉了而是让杀软很难在第一时间判定它是恶意的。严格讲这属于利用合法工具规避检测的思路比直接对抗杀软更常见、也更难防。防守方真正要解决的不是“向日葵不能出现”而是“它为什么出现在不该出现的位置以及出现之后我们能不能看见”。2. 熟悉带来的盲区可靠签名和常驻进程让告警变成了噪音我见过不少安全管理员第一次看到向日葵进程时的反应看一眼签名是正常的再看一眼业务部门确实有人在用然后就放行了。这恰恰是攻击者想要的效果。向日葵的进程会常驻会监听本地端口会定期向外发起连接这些行为单独摘出来每一项都跟正常使用没区别。但它一旦跑在攻击者控制的上下文中意义就完全不同了。这里要展开说一下“白身份”为什么可怕。杀软也好EDR也好判定一个程序是否可疑核心看三件事文件是否来自可信来源、运行后的行为是否符合该类软件的预期、以及它在这个环境里有没有合理的使用场景。前两点向日葵都完美符合唯独第三点需要结合资产归属、使用记录、登录日志去判断而这恰恰是很多终端防护产品不太擅长的。规则引擎往往只能回答“这是什么”回答不了“这个环境里它该不该出现”。我当时在复盘过程中专门查了那台主机的安全日志发现向日葵安装完成之后第一时间就有进程尝试读取本机的浏览器保存的凭证随后又通过计划任务建立了自启动项。这些行为如果单独发生在恶意程序身上告警早就该炸了但因为父进程是向日葵部分规则直接走了放行或者低优先级。这不是产品缺陷而是规则设计时一定会遇到的互相矛盾既要防滥用又不能因为误杀影响所有正常用户。所以真正的问题不是杀软不行而是我们过度依赖了杀软的单点识别能力忽略了日志关联分析。要想把这个盲区补上必须把进程视角调整到“上下文视角”。这也是我在后面几个部分想重点展开的。3. 一条告警的排查链路怎么从日志和进程链里盯出异常如果你在值班时也遇到类似的“合法远程控制软件”告警我建议不要急着点“允许”或“隔离”按照下面的链路把信息捞出来大多数情况下能直接看清是不是有问题。3.1 先看进程链和启动方式拿到告警之后第一件事不是看进程本身而是看它的父进程。打开任务管理器或者EDR的进程树确认向日葵是由用户直接双击启动还是被其他进程拉起。常见的可疑场景包括父进程是文档阅读器、脚本宿主、浏览器子进程或者父进程早已结束只剩一个孤儿进程。这些都不符合正常安装后手动打开的逻辑。然后是安装时间。对比一下向日葵的安装目录创建时间、服务创建时间、机器开机时间。如果是攻击者投递的这些时间往往高度集中可能都在同几分钟内还会伴随若干临时目录的生成。正常的员工安装软件不会在凌晨三点一口气创建这么多文件。3.2 再查网络连接和关联域名向日葵这类软件工作的时候必然有外部连接。EDR或防火墙会话日志里可以查这条进程的连接记录重点看目标IP和端口。正常的远程控制一般连到它自己的服务器端口固定且流量特征相对稳定。但如果是被攻击者利用你可能会看到连接的目标既包括官方服务器也包括内网其他主机的管理端口甚至还会出现直连某个未知IDC机房的IP这就非常说明问题了。我处理的那次告警向日葵除了连它自己的服务器还在几分钟内主动连接了同一网段里另外三台主机的高位端口。顺着这三台主机反查果然都出现了相同的进程和服务。这就不是“装了个软件自己用”能解释的了这是一条已经在横向扩散的链路。3.3 对照登录日志和账号活动进程层面有疑点之后进入系统日志把时间窗口拉出来。用下面这张表可以作为排查的参考基线每一项都对应一个“为什么可疑”的判断依据排查项正常现象可疑特征安装时间工作时间、分散凌晨集中出现父进程用户资源管理器手动运行文档类程序、脚本宿主外联目标官方服务器固定IP夹杂内网IP和未知机房登录账号该设备正常使用者离职账号、服务账号对应计划任务无或用户自建高权限计划和自启动项把这几项汇总之后基本就能对这台机器的状态有一个明确判断。需要注意的是单独某一项异常不一定说明就是攻击但多个维度同时命中就要果断进入下一步处置流程。不要等到杀软弹窗告诉你“这是恶意软件”那就已经晚了。4. 处置与取证让受控设备“离线”不是终点还原入口才算闭环确定一台主机存在可疑的远程控制行为之后最常见的错误是第一反应就是断网重装。这样干净是干净但入口没找到攻击者明天还能换个方式再进来。我一般建议按下面的顺序处理。第一步是隔离而非直接关机。保持进程运行状态通过防火墙策略把主机的所有外部通信拦截掉只保留到安全取证网段的通道。这个做法的目的是尽量保住内存里的证据包括已经建立的连接、进程注入痕迹、加载的DLL列表等等。一旦直接强制关机很多关键证据就留在磁盘的页面文件里提取难度会大不少。第二步才是进程和持久化排查。在隔离状态下导出进程列表、网络连接、计划任务、服务列表、注册表自启动项。重点看向日葵的安装目录下有没有额外的DLL或驱动文件被释放以及有没有同名进程并存——我之前遇到过攻击者把恶意模块改名放进向日葵目录下的情况表面上看还是那个软件实际加载的东西早就换了。第三步是顺着时间线还原入口。远程登录日志从哪台机器发起、账号是什么时候被创建或启用的、文件是通过什么渠道落地到这台主机的这三件事必须问清楚。在我参与的那次演练里最终溯源结果是通过某台互联网暴露的测试服务器被拿下攻击者用其中的一个脚本拿到了域内账号再通过该账登录了多台办公机。向日葵只是他部署在办公网里的一把“钥匙”入口其实在外面。对这一类事件的处置结论我倾向于把它定义为一次成功的“可信软件滥用”而不是简单当成恶意软件清除。清除恶意文件只是治疗了症状入口和账号的收敛才是治本。如果复盘到最后发现入口没有定位到建议先不要急于关闭事件工单至少要把该收敛的账号清掉、把暴露面降下来否则大概率过几周还会爆一次类似的事件。5. 收口与加固把“远程控制工具”变成可管可控的资产事件处置完之后接下来要解决的是长期问题。很多企业不是没有杀软也不是没有防火墙而是对远程控制类软件缺乏统一管理策略。别人装了一个你为了安全直接全网禁止业务那边立刻不乐意可如果完全放任就会出现上面这种被利用的场面。这里分享几个我在落地时验证过有效的做法。5.1 先盘点再收敛不搞一刀切第一步是把全网的远程控制类工具扫出来识别维度包括但不限于进程名、签名、安装路径、注册表卸载项、占用的本地端口。把扫描结果按照部门和用途打标签哪些是IT运维专用、哪些是业务协作需要、哪些完全没人申报。针对无人申报的可以直接在管控台上创建规则逐步下线。针对有需要的记录使用人和使用时间段做到每台机器上的远程软件都能对应到负责人。这个过程别用“装了就违规”的思路去推会引发很大的反弹。比较顺滑的沟通方式是先出一份常用软件台账找各部门确认用途再更新终端管控策略。真正异常的情况往往只占少数重点盯住这部分就行。5.2 出方向网络策略和端口收敛远程控制软件要工作必须有出方向连接。既然它必须连接到外部那就不能让它连得过于随意。建议在边界防火墙上对这类软件的外联IP段做白名单只放行其官方服务节点其他地址一律阻断。同时在本机防火墙上限制它监听所有网卡只允许绑定到特定接口减少被内网其他主机访问的面。端口层面也是同理向日葵默认占用的那组端口如果当前业务没用到可以在主机防火墙里直接禁掉。攻击者就算把它带进来了也会发现连接建不起来。很多情况下这一步就能阻断一大半的滥用场景因为后续脚本往往会因为连不上而失败。5.3 杀软和EDR规则要加“上下文”选项最后才是规则优化。不建议简单加一条“发现向日葵进程即告警”那是制造噪音。更好的思路是组合告警向日葵进程创建时如果父进程不是用户资源管理器或者该机器不在远程软件授权名单里或者存在跨网段横向连接则触发中高危告警。这样既能保留下正常使用场景又能把可疑行为单独拎出来。还有一点容易被忽略定期检查账号体系。那次演练里真正让攻击者畅通无阻的是多个长期未启用的账号仍然保持有效状态。账号不清理再强的杀软和EDR都是挡不住合法登录的。把账号生命周期管理纳入和终端管理同等重要的位置你会发现很多“杀软失效”的疑难杂症其实出在身份层面。6. 一点个人经验与建议复盘过几次这类事件之后我自己最大的感受是当攻击者选择用一款正常的远程控制软件干活时单靠杀软的“认识恶意文件”能力已经不够用了。我们需要意识上的转变——安全运营的核心竞争力正在从“识别坏东西”变成“理解好东西在环境里是否合理”。向日葵本身不是恶意的但它出现在不该出现的位置配合上异常的登录和连接行为就构成了完整的风险信号。如果你所在的团队还没有形成这种基于上下文的排查习惯建议先从一次小范围演练开始让值班同学用一台测试机模拟装一次未经审批的远程软件再对照我上面说的几个排查步骤走一遍。这个过程不需要真实攻击场景很快就能让团队建立对“可信工具滥用”这一类事件的敏感度。安全这件事提前把手感练出来真正遇到问题的时候才不至于慌。