发现疑似php2shell入侵后，先控制扩散、固定证据，再从干净的可信环境恢复业务，换掉所有可能泄露的凭据。光删掉可疑php文件、只打补丁，没法证明主机已经完全清理干净。
先定性：这是补丁工单，还是入侵事件
系统版本老旧属于常规待修补风险；如果出现陌生管理员账号、异常对外连接、来历不明的可疑文件，或是凭据被盗用的情况，就要按正式安全事件走流程。
先登记清楚发现时间、业务影响、涉事主机和对应责任人，别看到一条告警就直接坐实入侵，也不能因为网站还能正常访问就直接把事件闭环。
PHP2Shell涉及运行时内存处理与跨请求状态，部分路径早于业务代码执行。成功利用后的操作权限通常受Web工作进程身份约束，但这个账号可能读取数据库口令、写入站点目录或访问内部服务，因此影响范围不能只按上传目录估算。
立即学习“PHP免费学习笔记（深入）”；
执行隔离操作前，先捋清楚业务依赖关系和可用的管理通道。遇到攻击者持续搞破坏、敏感数据往外传这类紧急情况，优先阻断危害；如果要保全容易丢失的易失性证据，得由有正式授权的响应人员决定先采证还是先隔离，别死板硬套“先重启再看情况”的操作。
第一阶段：控制入口，同时保护调查材料
把可疑节点从负载均衡集群里摘出来，或者在独立的边界网关限制它的访问，同时留好可信的运维入口。所有操作要记录变更时间和规则覆盖范围，别把攻击流量导流到还没打补丁的备用节点上。
留存好访问日志、错误日志、进程状态和网络连接上下文；云环境要走正式授权流程保存磁盘快照和对应的审计记录。注意哪怕是取证采集命令也会改动原始现场，所有操作全程留痕，别在疑似被攻陷的主机上随便装扫描工具。
把所有取证得到的副本转存到受控的安全位置，登记清楚采集人、源路径、采集时间和文件校验值。日志里很可能包含个人信息和敏感凭据，对外分享的时候要按调查需求做脱敏处理，别直接上传到公开论坛。
下面的示例仅用来演示取证清单的结构。真实场景下的取证，还需要可靠的采集方式、完整的时间记录和证据交接链，哈希值一致只能说明两份文件的字节内容完全相同，没法证明来源可信，更不能证明系统里没有后门。
<?php
// 教学数据：演示证据清单的哈希记录，不读取或清理真实服务器。
$samples = ['access.log.copy'=>"sample request record
",
'service-info.txt'=>"runtime inventory sample
"];
$manifest = [];
foreach ($samples as $name=>$content) {
$manifest[] = ['artifact'=>$name, 'bytes'=>strlen($content),
'sha256'=>hash('sha256',$content), 'origin'=>'embedded teaching sample'];
}
echo json_encode(['manifest'=>$manifest,
'verified_clean'=>false, 'note'=>'hashes identify copies, not absence of compromise'],
JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
将代码保存为audit.php，在隔离的分析环境运行下列命令。本地使用macOS上的PHP 8.5.10 WebAssembly运行时验证输出，输入完全是教学样本，未连接生产服务器。
php audit.php
第二阶段：用可信基线恢复，别边删边猜
条件允许的话，优先用干净的可信镜像重建整个运行环境，再部署经过校验的应用和依赖组件。恢复业务数据之前，单独核对备份的生成时间和内容，别把可疑主机上的可执行文件、计划任务和全部配置原封不动搬到新环境里。
| 场景 | 恢复方式 | 需要补齐的证据 |
|---|---|---|
| 可快速重建 | 可信镜像加已核验数据 | 镜像来源、补丁及业务回归 |
| 暂时无法重建 | 保持隔离并开展专业清理 | 持久化排查、范围评估、后续迁移期限 |
如果短期内只能在原机器上处理，要先把所有证据存完，再逐一排查异常账号、启动项、定时任务、SSH密钥和Web目录的改动。用可信基线做全量文件比对，比只搜某个后门函数要靠谱得多，但哪怕这么做，也不能凭一次扫描结果就保证“已彻底清理”。
第三阶段：修补运行环境，重置可能泄露的信任关系
PHP上游本次修复版本为8.2.35、8.3.36、8.4.27和8.5.12；发行版回补包应按供应商完整包号核验。更新必须进入实际承载请求的工作进程，不能只依据命令行版本或磁盘文件时间验收。
从干净的可信管理终端，轮换所有可能泄露的数据库、云服务、部署账号和管理账号凭据，同时同步撤销所有旧令牌和相关会话。先清完所有旧的访问路径和权限，再配置新密钥；不要把新凭据写到还可能被攻击者控制的机器上。
恢复业务流量要分阶段逐步放开，逐一核对动态页面、登录功能、上传接口、后台任务和所有副本节点的状态。之后要留足观察窗口，持续监控异常外连、账号操作和文件改动；全程没告警只能说明当前监控没发现问题，不能作为系统没被入侵的证明。
交接前检查四个容易遗留的问题
- 排查时只删了一个可疑文件：补查持久化后门入口、其他关联节点和相关账号，别直接把事件闭环。
- 重启完才想起没做取证：先记录下已经发生的现场改动，由响应人员评估还能找回哪些有效证据。
- 从备份恢复的时候把旧漏洞环境也带回来了：分开核对业务数据和可执行环境，别把之前的旧漏洞也一起恢复上线。
- 改完密码还是出现异常登录：逐一检查旧令牌、历史会话、应用密钥和部署通道的权限有没有全部撤销。
最终的事件交接材料，要写清事件影响范围、证据索引、恢复来源、补丁生效情况和业务验收记录，同时列明所有还没排除的疑点。如果涉及核心重要数据或者攻击者还在持续入侵，要联系专业的安全响应团队，别把本文的教学内容直接当成取证工具或者自动清理程序用。
