Windows应急响应实战：WebShell入侵排查与后门清除全记录

接到这套Windows应急响应靶机Web3的告警时我正坐在工位上整理前一天的排查记录。告警内容很简短内网一台Windows业务服务器出现异常外联Web服务响应时快时慢疑似被入侵。这里要先说清一点标题里的Web3不是区块链那个Web3而是靶机管理方对第三个Web攻击场景的编号。整台机器模拟的是某公司一台被打穿内网边界的Web服务器前段是常见的IISPHP组合后端连着一个业务数据库攻击者通过Web漏洞拿到了入口后续做了一系列权限维持和痕迹清理操作。靶机里没有特别夸张的0day但把真实应急中常见的WebShell、命令执行、计划任务后门、隐藏账号这些点都埋了进去。这种靶机很适合刚入门的蓝队人员拿来练手也能让有几年经验但没完整做过应急的人重新梳理自己的排查顺序。我在上面完整跑了一遍从告警响应、证据固定、异常排查、溯源到清除加固的流程过程中踩了不少坑也发现了几个平时文档里很少被提到的细节。下面把这些内容原原本本记录下来给需要的人做个参考。1. 场景识别与响应准备1.1 先判断这是哪种攻击面拿到靶机之后不要急着开杀软扫盘第一步是搞懂这台机器在业务里扮演什么角色。通过查看监听端口和服务进程可以快速确认机器上跑着IIS、PHP-CGI另外还有数据库服务端口在监听。这个信息非常关键因为它直接告诉我攻击面大概率在Web层优先排查顺序就应该是Web访问日志、网站目录文件、数据库执行记录。同时还要建立“业务基线”。也就是说先搞清楚这台机器正常情况下会有哪些端口对外开放哪些进程是必须存在的哪些外联是正常的。很多应急响应新手看到任何外联IP都觉得可疑结果追了半天发现是正常的云监控或软件升级流量。在我处理的这台靶机上基线其实很清晰80和443端口对外提供Web服务数据库端口只对内网开放系统本身不应该主动向外网发起大量连接。明确了基线后面用netstat查异常外联时才有判断依据。另外要明确应急响应的边界。应急响应不是第一时间格式化重装而是在保留现场的前提下做证据固定和入侵分析。优先级永远是先止损、再取证、后清除、最后复盘加固。这四步顺序不能乱一旦乱掉比如先清了后门再分析攻击路径就很难还原报告也没法写。1.2 应急工具箱与证据固定顺序我自己的习惯是维护一个只读U盘的应急工具箱目录结构固定包含Process Explorer、Autoruns、Everything这类按名字快速索引文件的工具、日志分析工具和数据库客户端等。所有工具都提前拷贝好U盘在开始排查前设置为只读挂载避免排查过程在靶机上留下新的痕迹这一点在严肃取证场景下尤其重要。证据固定的顺序也有讲究。先做内存镜像再做磁盘镜像。内存里有攻击者正在运行的进程、网络连接、明文命令等信息一旦关机或重启就可能丢失磁盘镜像则是完整的现场快照后续任何分析都在副本上进行绝不在原机上反复折腾。在没有镜像的情况下至少要先把系统时间、当前进程列表、网络连接状态记录下来这些都是最容易被后续操作覆盖的痕迹。动手敲命令之前我还会把当前时间和系统时间做个对比记录时区信息。因为服务器日志很多以UTC存储本地时间与UTC可能相差8小时如果不先换算后面做攻击时间线时所有时间点都会偏。这个细节看似不起眼却直接影响溯源的准确性。2. 初检阶段进程与网络连接排查2.1 用netstat拆出异常外联完成准备后第一步是看网络连接。命令行直接执行netstat -ano | findstr ESTABLISHED netstat -ano | findstr LISTENING把结果里非业务端口、非内网IP的会话全部标出来。我在这台靶机上发现一个PID为3321的进程对外网某IP的443端口保持着TCP链接状态是ESTABLISHED。这个外联本身不一定有问题因为很多合法软件也会走443真正有问题的是对应进程的身份。用tasklist /fi PID eq 3321查看时显示的名称极其接近系统进程但仔细看是svch0st.exe中间用的是数字0而不是字母o。这种混淆手段在真实对抗中经常出现。随后用wmic process get ProcessId,ParentProcessId,CommandLine /format:list拉出完整命令行发现进程路径在C:\Users\Public\下启动参数里还带了一段访问外部地址的PowerShell命令。到这里基本可以断定这台机器已经被攻击者植入了一个远控后门。判断一个外联是否异常我自己的经验是看五个维度目标IP和端口是否属于业务范畴、发起进程的路径和签名、进程的父进程链、连接创建的时间、以及是否存在周期性规律。如果进程无签名、路径在临时目录或用户公共目录、连接非业务端口同时命中两条以上就应当高度怀疑。2.2 进程链路与计划任务排查找到可疑进程后不要立刻杀掉先顺着进程树往上追。攻击者获取命令执行权限后通常会通过Web服务进程比如w3wp.exe或php-cgi.exe拉起一个子进程来运行命令。用wmic process get name,parentprocessid,processid,commandline /format:list可以发现异常进程的父进程正是Web服务进程这直接证明攻击是从Web入口进来的。继续排查计划任务。执行schtasks /query /fo LIST /v重点看登录触发、空闲触发、重复执行的任务以及执行命令里是否带有PowerShell下载或加密解码特征。我们在这台机器上找到了一个名为“WindowsUpdate”的计划任务触发器是“登录时执行”执行的命令是powershell.exe加一大串Base64参数。Base64解码后是一个远程下载并执行脚本的动作这明显不是正常的Windows更新任务。计划任务是非常常见的持久化手段攻击者用它来做重启后的权限维持应急时如果只看进程和启动项往往会漏掉这条。这里特别提醒一点计划任务里看到的命令可以伪装得和系统更新一模一样不要只看任务名称一定要看完整的操作命令和上次运行时间。有些攻击者甚至会把任务XML里的命令执行参数写得极其隐晦所以执行记录和计划任务XML都需要留存下来作为溯源证据。3. Web攻击面分析与攻击路径还原3.1 Web日志定位注入与上传行为确认Web服务是入口后重点转移到Web层。IIS的日志默认放在C:\inetpub\logs\LogFiles\W3SVC*Apache在/apache/logs/access.logNginx可能在/var/log/nginx/access.logWindows下也不例外。这台靶机是IIS所以我直接打开W3SVC日志目录按文件时间倒序查看。日志分析不是把所有内容读一遍而是先过滤异常特征。我在文本工具里做了几个关键搜索POST请求且URI包含上传关键字、请求中包含%27或..%2f等编码特征、返回状态码集中在200但访问路径明显是探测行为。很快定位到一条关键记录攻击者对某个上传接口发送了POST请求参数里带了一长串Base64内容。紧接着后面的日志里同一个IP开始访问一个网站目录下从未出现过的PHP文件访问频率相当规律像是WebShell的连接行为。把这几个请求按时间排序后一条攻击链逐渐清晰先探测到上传接口的文件类型校验缺陷再上传一个伪装成图片的PHP脚本然后通过WebShell执行系统命令最后下载远控木马。这正好解释了进程排查阶段看到的现象。3.2 WebShell定位、确认与清理挖出WebShell是Web应急的核心动作。WebShell的特征通常包括文件修改时间明显比其他文件新、文件名刻意模仿正常文件比如logo.php、css.php、内容包含eval、assert、base64_decode、call_user_func、system等高危函数、文件权限和同目录文件不一致。用Everything按修改时间倒序搜索网站目录下的.php文件很快就能发现可疑对象。注意打开WebShell文件时不要直接用浏览器访问使用文本编辑器或者type命令看内容即可避免在分析过程中触发里面的恶意代码。我找到的木马是一句话木马变种内容被编码过外部调用时再解码执行平时静态扫描很难识别出来。确认WebShell后不能只删掉这个文件就算完。要认真检查同目录下是否存在变种我采用的办法是把网站目录下所有脚本文件的修改时间集中在攻击时间窗内的文件全部导出逐个检查内容和文件头。同时还要溯源WebShell是怎么上传进来的回到上传接口的代码确认是否存在只校验文件Content-Type而没校验扩张名、或者允许.php.jpg被解析的缺陷。这个修复点会写进加固报告否则清完一个WebShell下次攻击者又能原路打进来清理便没有意义。3.3 数据库侧痕迹核验很多Web攻击最后都会落到数据库要么通过SQL注入读取数据要么通过数据库命令执行写文件。第3.1节的日志中已经出现了类似SQL注入的探测请求所以在Web目录之外我还检查了数据库侧痕迹。如果开启了数据库通用日志或审计功能直接查询危险命令记录。以MySQL为例可以通过general_log表看到所有执行的SQL语句SQL Server则可通过扩展事件或默认Trace记录。对于未开启日志的情况只能通过文件修改时间和数据库备份时间交叉判断。实际操作中我会做四件事确认是否存在注入点、检查敏感表是否被读取、检查数据库账号权限是否被改动、检查是否执行过into outfile、xp_cmdshell、sp_oacreate这类高危险命令。在这台靶机上数据库账号多了一个从未见过的只读用户名字和业务账号极其相似不仔细看根本发现不了。另外还发现一条select ... into outfile执行记录把WebShell写到了网站目录和Web日志中的上传记录形成了证据闭环。到这里攻击路径已经从Web入口串到了数据库出口整个攻击链条完整还原了。4. 持久化后门排查4.1 注册表Run键与启动文件夹排查攻击者进来后绝不会只在C盘丢一个WebShell通常还会做持久化保证系统重启后仍然能获得权限。排查持久化时第一步是看注册表运行键reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run reg query HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run三个位置都要查因为64位系统上32位程序的启动项写在WOW6432Node节点里只查前两个会漏。我在这台靶机的HKCU运行键下发现一个名为“OneDriveUpdate”的项路径指向C:\Users\Public\OneDriveUpdate.exe。正常的OneDrive不会装在Public目录文件名大小写也刻意混淆了。顺着路径去查Public目录下确实躺着一个伪装成文档图标的可执行文件结合进程外联行为确认这是第二个后门入口。启动文件夹也值得看一眼C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup和C:\Users\用户名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup。另外还可以检查Image File Execution Options里的Debugger键攻击者可能通过这个键把某个系统进程的执行转到恶意程序上。4.2 服务、计划任务与WMI事件订阅排查服务是另一个高频持久化点。排查时用sc query type all state all | findstr /i SERVICE_NAME wmic service get name,displayname,pathname,startmode | findstr /i temp public正常系统服务要么路径在System32下要么在Program Files下如果一个服务路径在Temp、Public或者奇怪的用户目录那基本有问题。在这台机器上发现了一个服务名称叫“AppHostSvc”的服务名称仿得很真但PathName指向了Public目录下的另一个exe而且启动类型是自启动。服务用sc delete删除前先把服务状态、可执行文件都留好存档避免后患。计划任务第2.2节已经排查过但WMI事件订阅是更容易被忽略的持久化方式。WMI事件订阅可以做到文件不落地完全在内存中以WMI类形式存在普通杀软很难发现。用PowerShell查询Get-WmiObject -Namespace root\Subscription -Class __EventFilter Get-WmiObject -Namespace root\Subscription -Class CommandLineEventConsumer Get-WmiObject -Namespace root\Subscription -Class __FilterToConsumerBinding如果发现Filter和Consumer是成对出现且命令行中带有PowerShell下载执行逻辑极其可疑。这个靶机为了降低难度没有埋WMI持久化但真实场景中还是很常见的不能因为这次没遇到就跳过不查。5. 登录日志与账户后门核查5.1 安全日志中的登录事件进程、网络、持久化都看完了回到系统自身痕迹。安全日志是还原入侵过程的黄金证据重点关注以下事件ID事件ID含义作用4624登录成功定位攻击者使用的账号与来源IP4625登录失败辅助判断是否存在暴力破解4672特权登录判断是否有管理员权限登录4720创建新用户发现新增账户后门4732将成员添加到安全组发现提权操作7045安装新服务结合服务路径排查后门服务使用wevtutil epl Security将安全日志导出到本地分析优先筛选4624登录成功事件和4720用户创建事件。在这台靶机上发现一条来自内网某IP的RDP登录成功记录登录时间与Web日志中上传木马的时间高度吻合。进一步查看该用户登录后执行的进程记录可以通过4624登录会话ID关联进程创建事件4688可以看到该账号登录后执行了PowerShell命令随后创建了计划任务。时间线到这里已经完全串起来了。注意日志里的时间格式安全日志默认是UTC时间在写报告前要把时区换算回本地时间。前后相差8小时如果不处理会误导攻击发生时刻的判断。5.2 隐藏账号与权限异常检查用net user查看本地用户列表时很多时候不会直接暴露异常账号但管理员组成员一眼就能看出端倪。net user net localgroup administrators如果发现管理员组里有不认识的账户就要警惕隐藏账号和克隆账号。隐藏账号一般是在用户名后面加$符号net user里默认看不到需要结合注册表SAM或者wmic useraccount get name,sid来做检查。克隆账号的特征更隐蔽它通过修改注册表将某个普通账号的F值关键SID信息替换成管理员账号的值表面上看起来只是一个普通账号实际权限却是管理员。这台靶机里埋了一个伪装成“sqlservice”的账号SID后面几位明显是新建用户的特征而且这个账号不在任何normal业务脚本的白名单里。配合第3.3节发现的数据库只读账号攻击者相当于同时控制了系统层和应用层两套凭据。对这类账号的处理是确认无业务使用后立即禁用修改相关密码并排查该账号是否通过RDP登录过其他内网机器防止横向扩散。6. 清除、加固与复测闭环6.1 清理操作规范化清除动作必须建立在完整证据固定的基础上。我在清理前做了两件事一是把确认的恶意文件复制一份到证据目录二是记录所有待清理对象的路径和属性。随后按以下顺序处理删除WebShell文件及其变种同时修复对应上传漏洞代码删除异常计划任务使用schtasks /delete /tn 任务名 /f停止并删除异常服务使用sc stop 服务名和sc delete 服务名删除注册表Run键里的恶意启动项清理Temp和Public目录下的攻击者工具修改遭波及的系统口令、数据库口令和管理员口令在防火墙出站规则中限制不必要的端口外连。清理过程中最重要的原则是“可回溯”。每删一个对象都记录时间、对象名称、证据备份路径。这样即使后续发现误删或需要恢复也能快速定位。另外一个容易被忽略的点是内存马如果攻击者在内存中加载过恶意模块清理完磁盘文件后需要重启重启后再次检查80和443端口是否还有异常进程连接。6.2 加固与复测要点清理只是应急流程的一步加固做不好系统永远是敞开的门。针对Web3这台靶机的场景加固至少要覆盖三条线Web服务器层修复上传接口文件类型校验禁止上传目录执行脚本删除不必要的Web管理接口对Web日志接入集中存储和告警定期扫描WebShell。数据库层关闭不必要的危险存储过程重建低权限账号并设置强口令限制数据库管理端口只对特定IP开放开启数据库审计日志。系统层关闭不必要的服务端口对管理员组账号做最小化授权开启Windows安全日志与进程创建审计安装EDR或主机入侵检测产品定期做安全基线核查。复测时不能只看“有没有查到马”而是把上次排查的动作完整再做一遍检查进程、网络连接、计划任务、服务、启动项、Web目录文件、最近新增账号确认全部清零。同时用自动化或手工方式做一次Web漏洞扫描确认上传接口已无法利用。最后从日志中还原攻击时间线写成报告包括攻击源IP、漏洞点、每个节点的动作、发现的病毒木马MD5、清除动作和加固建议。报告不是给系统看的是给之后的人看的要让拿到报告的人不用再重新做一遍分析。7. 常见问题与实操心得实录7.1 应急排查中最常见的坑这次靶机流程跑下来我整理了新手最容易踩的坑也见过不少同事在这些地方翻车。一是上来就拔网线。日志还没导出来、内存镜像还没做网线一拔正在进行的攻击会话当场中断远端C2的指令和内存中的明文信息可能直接丢失。正确做法是先抓取网络连接和进程快照再考虑断网隔离。二是看到可疑进程立即结束掉。进程一结束它的命令行参数、父进程关系、网络连接信息就全部变成了历史记录后续很难再追溯。正确做法是先记录再处置记录的内容包括进程名、PID、完整路径、启动参数和网络连接。三是只清WebShell不查持久化。删除一个木马文件很简单但如果计划任务、服务、注册表启动项里的后门还在过一会儿攻击者又会被拉回来。Web应急的起点是WebShell终点却是系统级的所有持久化点。四是被文件时间欺骗。攻击者完全可以伪造文件时间timestomp比如把WebShell的修改时间改成系统安装日期。只依赖文件的修改时间是不可靠的我一般会结合创建时间、访问时间和文件内容特征来交叉判断。必要时用MFT主文件表分析工具看真实的时间戳记录。五是不换算时区导致时间线错位。前面反复提到IIS日志和安全日志都可能是UTC不换算就直接写报告攻击时间点可能整体偏移8小时严重时甚至会把攻击时间判断成在事发前或事发后。7.2 值得反复强调的排查习惯最后分享几个我在实际工作中沉淀下来的习惯算不上高深技巧但很顶用。排查顺序一定要固定。我个人的固定顺序是网络、进程、日志、文件、持久化、账号、清除验证。这个顺序保证从最不稳定的证据出发逐步向稳定证据推进不容易遗漏。一旦确定顺序就要像肌肉记忆一样执行不管多着急都不能跳步。命令结果随时留档。应急时打开一个本地日志窗口把所有执行过的命令和输出一并保存再配合截图整个响应过程就会有完整的审计记录。报告需要复现任何一条结论时都能直接找到当时的依据。千万不要低估基础命令的价值。这次靶机里用到的全是netstat、tasklist、wmic、schtasks、reg query这类最基础的Windows命令没有什么高级神器。很多时候排查不清不是因为工具不够强而是因为思路不够清晰或者干脆跳过了某个基础步骤。把基础命令组合成一个固定的Checklist比临时学几个高级工具要可靠得多。复盘这段靶机经历我自己最有感触的一个点是应急响应真正考验的不是单一技巧而是能不能把所有细小的痕迹串成一个完整的攻击故事。Web3这台机器从WebShell到远控进程、从计划任务到隐藏账号环环相扣每一步都对应着前一步的入口。把每个基础动作做到位按顺序把事实记录下来再难看的入侵也都能还原出清晰的路径。希望这篇记录能帮到正在练手或者准备考核的人少走一点弯路。