背景 最近在做一批历史站点的安全巡检时，遇到过几次比较典型的 Webshell 告警。实际排查下来，问题并不复杂：入口多是老旧组件、弱口令后台、历史遗留上传接口，落点则集中在可写目录、缓存目录和模板目录。 这类事件的价值不在于“发现一个木马文件”本身，而在于通过复盘把排查链路、代码审计点和后续加固动作沉淀下来。很多站点反复中招，往往不是因为攻击手法多高级，而是缺少一套稳定的处置流程。 场景与初始现象 典型告警一般来自几类信号： EDR 或主机安全产品提示 Web 目录出现可疑脚本文件。 Web 访问日志中出现异常 POST 请求，目标文件位于 upload、cache、tmp、template 等目录。 站点响应偶发异常，PHP-FPM、Java 进程或 Web Server 进程 CPU 波动。 某些业务目录出现修改时间异常的新文件，文件名伪装成图片、缓存或配置文件。 实际处置时，不建议一上来就删除文件。更稳妥的方式是先隔离、留证、确认入口，再做清理和加固。否则很容易出现“今天删、明天又出现”的情况。 排查思路 我一般按“文件、日志、进程、代码、配置”五条线并行看。这样做的好处是可以
在实际事件响应中，最难的往往不是判断一个文件“像不像木马”，而是在不扩大影响面的前提下，建立一条可复核的证据链：样本从哪里来、执行后做了什么、哪些行为可以确认、哪些只是推测，以及如何把分析结果转化为检测规则和处置建议。本文以 Windows PE 文件为例，整理一套适合实验室和企业应急场景的分析流程。重点放在样本保全、静态分析、受控动态验证和 IOC 提取，不涉及持久化、绕过防护或远程控制等攻击操作。一、分析前先定义问题收到一个可疑文件后，不建议直接双击运行，也不要一开始就沉迷于反编译细节。先明确本次分析要回答的问题：文件是否与当前告警或入侵事件有关。文件是否具备执行能力，是否存在明显的打包、混淆或自解密行为。运行后是否创建进程、文件、服务、注册表项或网络连接。是否能够提取稳定的检测特征，例如哈希、路径、互斥体、域名、文件名或行为组合。如何验证结论，并降低样本运行对分析环境的影响。一个好的分析报告应当区分“观察到的事实”“基于事实的判断”和“尚未验证的推测”。这比简单给出一个恶意或安全的结论更有长期价值。二、建立隔离且可回滚的实验环境动态分析前应准备独立的虚拟机或专用分析主机。实验环境
背景文件上传一直是 Web 安全里比较“老”的问题，但在真实环境中仍然很常见。原因不只是后端判断不严，还包括对象存储直传、反向代理转发、异步处理任务、缩略图生成、临时目录清理等多个环节。只盯着一个上传接口，往往看不到完整风险链路。前段时间复盘过一次内部演练中的 WebShell 告警，最终没有形成实际危害，但暴露出几个典型问题：扩展名校验分散、上传目录可执行、图片处理逻辑信任用户输入、日志字段不足。这里整理成一篇偏长期参考的文章，重点放在代码审计思路和防护落地，不讨论攻击利用细节。场景说明业务中有一个头像上传功能，前端限制只能上传 jpg、png，后端也做了扩展名判断，并将文件保存到本地静态目录。表面看风险不高，但实际链路如下：用户上传文件到后端接口；后端根据原始文件名截取扩展名；保存到 Web 可访问目录；异步任务读取文件生成缩略图；Nginx 将该目录作为静态资源直接对外提供。告警来自主机侧文件监控，发现上传目录下出现了非预期内容。虽然没有执行成功，但问题点已经比较明显：上传文件进入了 Web 根目录，并且校验逻辑不足以保证文件类型可信。问题代码示例下面是一段简化后的伪代码，很多项
.jpg.9e5b93ecbee2891469035a26c1fc0c39.jpg)
