1. 一次诡异的网络故障揭开的不是硬件问题而是恶意软件先说一下事情的背景。当时我们某内部网络整体做了一次设备升级从核心交换机到接入层全部换新终端也重新做了一批系统镜像。本以为这套环境怎么也能平稳用上一阵子结果升级完没几天整个办公网开始反复出现间歇性卡顿隔一段时间就会有一波明显的网络延时飙升丢包率也忽高忽低。一开始我们按老思路排查怀疑是交换机环路、广播风暴、或者是某台终端网卡故障。抓包看了一阵子确实发现大量异常广播报文但一直没有定位到真正的源IP因为每次抓到的来源都不一样今天这一波是这几台机器明天又是另外几台。当时整个现象非常像ARP攻击但换了网关、清了ARP表之后问题依旧。后来我把样本流量拖出来做深度分析才发现一个陌生的进程在系统里频繁创建网络连接并且会不断地向不同IP段发起扫描。那个进程的名字对当时我们来说并不算陌生但在那之前我从没在真实的生产环境中正面碰到过——pnscan一个非常经典的自动化传播型蠕虫病毒。这段时间的排查和处置过程我踩了不少坑也积累了一套完整的应对方案。这篇文章就把整个过程从头到尾拆开来讲包括这个病毒到底做了什么、怎么判断是否中招、应急响应应该先做什么后做什么、以及事后怎么把系统彻底加固回来。如果你负责的公司网络或者服务器集群还没经历过这类事件我建议你认真看看尤其是内网用户量大、终端权限管控不严、密码策略偏弱的场景这一类病毒几乎是早晚会碰到的。2. pnscan是什么为什么它能这么顺利地在内网扩散2.1 先搞清楚病毒的身份和行为逻辑pnscan本质上是一个基于TCP端口扫描进行传播的网络蠕虫。它的攻击核心路径非常直白探测存活主机、尝试与特定端口建立连接、对暴露出来的服务做弱口令爆破、成功后把恶意Payload投递过去再重复这个流程。它主要盯着的端口往往是135、139、445这三个也就是Windows环境下的NetBIOS和SMB相关服务端口。为什么这三个端口最容易被盯上因为它们在传统Windows局域网里是默认开放的核心通信端口文件和打印机共享依赖它们跑起来。很多单位的内网为了图省事Windows防火墙策略常年关闭或者只设置了非常宽松的入站规则导致这些端口几乎裸露在整个内网里。这就相当于大门的锁只是象征性挂在那pnscan连撬锁都不用试推一下就开了。我在分析样本时看到它的扫描逻辑也很“暴力”按IP段逐段遍历同一时刻能发起大量并发连接。这个特性决定了它的横向扩散速度非常快。如果内网里有几十台机器具备相同特征——同样的账号口令、同样的防火墙策略——那么只要有一台被突破剩下的机器就只是时间问题。2.2 弱口令和端口裸露是病毒蔓延的两大靠山pnscan传播成功的首要前提是能成功登录远程主机的管理员共享。我们在复盘时发现被感染的终端里本地管理员账户密码几乎都设置成了同一个复杂度很低的弱口令这个口令在域环境下遍地都是。有些机器甚至启用了Guest账户或者存在空密码的本地账号。这种内网密码管理方式基本上等同于给pnscan发了一张全域通行的门禁卡。第二个靠山是端口裸露。中招的终端里相当一部分没有开启Windows Defender防火墙或者虽然开了但入站规则允许了来自任意地址的445端口访问。一般业务部门为了方便局域网互传文件会直接把防火墙关掉。一旦被病毒利用反而成了它横向移动的高速公路。第三个加速条件是内网缺少分段隔离。整个办公网处在一个二层大广播域里所有部门机器都在同一个网段。正常网络架构里即使终端感染了横向传播型病毒只要做了网段隔离它能触及的范围就有限。但我这次遇到的环境刚好是扁平化设计病毒几个小时之内就把能扫到的主机全部扫了一遍业务影响面一下就炸开了。3. 从发现异常到确认中招完整排查链路记录3.1 第一反应是先止血而不是先查根因故障开始影响业务后我的第一反应是先把受损范围控制住。好几个网卡流量冲到450Mbps以上核心交换机CPU负载居高不下。这时候如果还逐台排查时间上完全来不及流量风暴会把整个网络彻底拖死。所以第一步动作就是断开核心交换机上的主要业务端口让内网暂时跟外网断开同时把服务器区域与办公网区域的互联临时阻断。这里有个关键点千万别只断一两台交换机这种病毒是全网扩散任何一台漏网的机器都可能成为新的感染源。先把二层广播域物理切开把病毒的网络活动限制在小范围内后面才有条件慢慢查。同时我安排另一路同事直接在防火墙上做了紧急策略封锁外部到内网的445、139端口入站流量。虽然这不解决内部传播问题但至少能防止内部信息被外部控制端继续调取也给后续排查争取了时间。3.2 用抓包和进程排查锁定位病毒本体在隔离措施生效之后我从核心交换机镜像口拉了一份部分时段的流量样本。这里有个经验抓包的时候不要只抓几秒钟至少抓持续3到5分钟的高峰期数据然后把TCP SYN包的源IP和目的IP做统计排序。pnscan连接特征非常明显SYN包数量异常高目的端口集中在445、139、135源IP会在不同的IP之间快速跳变因为它是逐段扫描的。在这个阶段我使用了网络取证分析工具确认了几个高频扫描源IP。随后在对应终端上排查进程很快就看到一个异常进程——可执行文件名是随机字符串运行路径在临时目录下CPU占用率不高但网络连接数非常多。后来用进程排查工具进一步检查它的网络连接发现它会同时向多个不同IP段的445端口发起连接请求状态都是SYN_SENT这个行为特征完全可以实锤了。再配合检查计划任务和自启动注册表项确认了病毒在系统里做了多处持久化。也就是说单纯杀掉进程或者删除那个临时可执行文件下次重启病毒还是会自己跑起来这就是为什么网上很多用户只杀毒不清理持久化配置结果过几天病毒又回来的原因。3.3 联动安全设备确认传播路径找到终端上的证据后我回到核心网络层面做交叉验证。把防火墙的会话日志调出来筛选目的端口445、139相关记录可以看到同一源IP对大量目的IP发起的连接尝试时间线非常密集。这些日志配合终端上的进程证据整个攻击链路就很完整了某一台上网终端先被感染然后向外扫描碰上了弱口令的机器把自身拷贝过去后者再加入扫描大军。这里务必注意如果你们单位有终端管理软件最好把全网机器的Windows日志也集中收一发重点看登录类型3网络共享登录的失败记录。大量来自不同IP但对同一个管理员账号的失败登录日志拼接起来基本就是病毒横向移动的完整轨迹。4. 清除与恢复一份可以直接抄作业的处置清单4.1 终端侧的清理顺序不能乱清理终端的第一个原则是断网再清。不管你在哪一步只要确认某台机器中招先把它的网线拔掉或者直接禁用网卡。否则你刚把病毒文件删掉还没等你改完密码它可能又通过内网其他机器传回来。这听起来像是废话但在实际操作中很多人真的会忘。第二步是在隔离状态下结束异常进程。这里推荐不要直接双击进程结束任务可能触发自我保护机制。正确处理方式是用命令行工具查看全路径后强制结束进程并且同时结束掉关联的子进程和计划任务进程。第三步就是处理持久化配置。这一步是整个清理环节最容易出问题的。很多新手清完病毒文件就以为万事大吉结果系统日志里照样有恶意计划任务的触发记录。建议顺序是查看计划任务服务里是否存在可疑任务、清理自启动注册表Run与RunOnce项、检查服务列表和驱动加载项。每处理完一项就拍照记录方便后续确认。4.2 全盘杀毒加上手工核查才能不留死角处理完持久化配置后用主流安全软件做一次全盘扫描同时手工排查每个磁盘根目录下有没有异常隐藏文件。pnscan变种有时会把副本写在不同分区光靠杀毒引擎有时扫不全尤其是遇到白加黑或加壳变体时杀软检出率不能说百分百可靠。手工核查IPC$共享列表也很关键中招机器往往开了默认共享需要立即关闭这部分共享。然后是账号口令排查。重点检查本地管理员组成员是否有异常新增账号guest账号是否处于启用状态所有账号密码策略是否满足复杂度要求。建议直接对全公司范围内所有终端统一重置管理员密码并且不要给多台机器设置完全相同的密码。一台一台改确实麻烦但这道坎跨不过去病毒分分钟就能二次入侵。4.3 服务器与网络设备侧怎么配合处理如果病毒蔓延到了服务器区域处理逻辑跟终端一样但优先级和严谨度要求更高。数据库和应用服务器千万不要直接重启先停止相关服务的加载再进行病毒清除。我见过一个真实的场景运维同事发现数据库服务器中了同类病毒直接重启服务器结果启动自启项把恶意进程重新拉起同时又因为数据库服务没正常停止导致数据文件损坏整个恢复变成了一场灾难。网络设备层面的清理重点是检查ACL策略里有没有异常放行条目确认交换机的端口安全配置是否失效。在病毒爆发期间为了方便排查而临时放开的端口事后一定要逐条确认和回收。同时建议对所有设备的管理密码强制更换一轮毕竟内网被渗透期间不排除攻击者已经拿到了设备登录凭据。5. 事件复盘之后我才弄明白的几件关键事5.1 端口该不该全关防火墙到底该怎么配很多刚接触这类事件的人都会问是不是把445端口关闭就能彻底避免实际上在现代办公网络环境下SMB不是没有存在价值关键是看你的使用场景。如果确实需要局域网文件共享建议不要拿445裸奔而是把共享服务放到专门的文件服务器上终端侧除非有明确业务诉求否则一律关闭SMB的入站访问。Windows防火墙不是装了就完了默认规则覆盖范围有限。正确的做法是在系统镜像阶段就把防火墙策略定制好对入站流量做显式禁止只放行业务必须的端口。对出站流量也建议做统一白名单只允许终端访问内部资源以及指定域名和IP段。pnscan这类病毒本质上依赖外连把控制指令传回如果出站流量管控到位即便机器中毒也能大幅降低被远程控制的风险。5.2 内网分段不是网络部门自找麻烦在事件没发生前我也觉得内网分段是一件“理论上要做但实际上不好推”的事。但经过这次教训我的态度完全变了。你可以不把每个部门单独划VLAN但至少要保证服务器网段、办公网段、无线访客网段相互隔离。办公网内最多割成几个中小型广播域每个域之间通过防火墙做访问控制。即便某一台机器中了横向传播型病毒它能失控的范围也就局限在自身所在的域里核心服务器不至于一次暴露。最经济的做法是先把服务器区单独隔离这是性价比最高的一道防线。办公网段暂时不分也能忍受但服务器和数据库的暴露面一定要先压下来。5.3 密码策略和账号管理是网络安全里最硬的地板这次事件最让我惊讶的是病毒爆破账号的成功率远比我预想的高。事后我们抽了几台中招机器做日志复盘发现大部分是被同一个弱口令打穿的。如果你问我安全建设投入的优先级我一定这么说先管好账号密码再谈防火墙、入侵检测、态势感知。再贵的防护设备也架不住内部管理员密码是公开的秘密。建议有条件直接上域环境或者轻量的终端统一管理方案强制密码周期轮换同时针对管理员账号开启双因子认证。没有条件上全套体系的至少要保证所有内网设备的Administrator密码是随机生成的高强度密码且每台机器不同。这个成本很低但收益绝对立竿见影。6. 常见问题与排查技巧实录6.1 病毒排查期间容易踩的坑最典型的坑是抓到了扫描源IP就认为找到了感染源。pnscan是横向传播型病毒扫描源IP指的是上一步被感染的机器而不是最早的传染源。你要是只盯着扫描源IP去清理清理完这台机器另一台又开始扫描永远处于被动应对状态。正确做法是沿着感染链往回查把最早受感染的那几台机器找出来一块处理掉。第二个坑是处理完就恢复业务不做观察期验证。我的建议是恢复业务前先让网络再单独运行6到12小时观察异常扫描行为是否还存在。这个环节很多人嫌耽误时间直接跳过结果第二天又爆发问题重新排查的成本远高于这段观察期的等待成本。第三个坑是忽略了移动介质和外联设备。某些终端中招可能不是通过网络传播的而是通过U盘或移动硬盘带入的。如果清理完所有网络设备后某个点位再次中招很有可能是本地介质里的病毒源还没清干净。6.2 Windows日志应该重点盯着哪些事件事件ID 4625表示账号登录失败这类日志爆炸式增长是爆破型攻击的典型信号值得重点关注。事件ID 4720表示创建了新用户账号这个要特别小心很多恶意软件会创建新的本地账号做后门持久化。事件ID 7045表示服务安装如果看到来源不明的服务在大量主机上同时出现基本就是恶意负载投递成功的结果。事件ID 4698表示创建了计划任务恶意软件经常借助计划任务实现定时拉活。建议日志不要只存在本地最好通过日志服务器集中保存至少90天不然出了事连排查依据都没有。6.3 没有专业安全团队的小单位怎么做兜底如果你所在的单位规模不太大没有专职安全运维人员我的建议是至少做好三件事。第一是备份重要的文件服务器、数据库服务器务必有自动备份机制且备份存储和主存储物理或逻辑隔离。第二是终端统一管控现在很多轻量级终端管理工具都自带基础防病毒功能和违规外联监控功能。第三是定期做弱口令扫描手写一段简单的检查脚本周期性扫描内网各网段是否存在简单的口令爆破风险在病毒找上门之前自己先发现问题。7. 恢复上线前别急着松劲最后一道防线要补上整个事件处理完并不是终点恢复正常办公状态前的最后一波操作直接决定了你几周后会不会再把同样的流程从头走一遍。第一件事是确认全网IP地址和MAC地址绑定关系没有异常。病毒爆发期间有些操作会改动终端的网络配置或者攻击者在机器上配置了备用IP地址这些如果不清干净后续出问题很难定位。第二件事是对核心服务器做一次基线配置核查重点确认远程管理端口是否暴露、管理口访问来源是否受限、共享目录权限是否维持最小化原则。我在实际恢复过程中还做了一步额外操作把曾经中招机器的系统日志等级调整为详细模式开启针对进程创建和网络连接的安全审计策略。这样如果修复后仍有漏网之鱼日志上会有迹可循不至于又重新靠猜来排查问题。这里说句真心话很多单位处理完病毒事件就急着恢复生产力安全加固方案永远排在业务需求后面。但这类蠕虫型病毒不会只来一次只要网络里仍然存在弱口令、裸露端口、缺乏分段这些老问题第二次中招只是时间问题。所以哪怕领导催着恢复业务也一定要把关键加固动作全部落地之后再回头不要在这种时候将就。7.1 上线后的前两周是观察期不是稳妥期恢复业务后的前两周我的建议是每天都花10分钟看一下核心交换机上的异常连接统计尤其关注445端口和139端口的外部连接以及异常登录行为。平安无事跑两周基本上就能说明清理是彻底的。这个阶段不要做大的网络策略变更也不要调整防火墙规则保持环境稳定给监控数据一个干净的参考基线。另外这个事件过去之后建议顺手做一份详细的事件复盘文档不用写太多几页纸就够了把时间线、受影响主机范围、根因、处置过程、后续加固清单全部写清楚。这类文档是灾难恢复演练最好的输入下次再遇到类似事件团队能够按照文档快速定位而不是靠一两个人拍脑袋临场发挥。