文件哈希全正常，PoisonedRefresh仍把Web Shell藏进内存

SophosLabs于9月7日发布的样本分析 揭示了一种与失陷F5 BIG-IP Access Policy Manager（APM）环境相关的Linux植入程序：PoisonedRefresh会在Apache加载libphp后接管特定文件的打开与内存映射过程，把PHP Web Shell加入进程看到的脚本副本，而不必改写磁盘上的原始PHP内容。

现有证据所指向的是使用Apache、libphp和APM webtop组件的BIG-IP APM环境，不是所有Apache或PHP服务器。9月8日的独立报道 交叉核对了三个目标脚本、内存注入、本地UNIX套接字和Shell执行机制；因此，即使这些脚本相对可信基线的哈希全部正常，也不能据此认定运行中的Apache进程没有被操纵。

磁盘文件与进程副本可以同时呈现两种结果

PoisonedRefresh改变的是PHP取得脚本内容的路径，而不是直接把最终Web Shell写进脚本。植入程序通过自定义加载逻辑取得早期执行机会，再Hook Apache Portable Runtime的apr_dso_load，等待Apache加载libphp后修改该模块中的调用路径。

它读取/proc/self/maps定位libphp的地址范围，临时把相关内存页从RX改为RWX，重写open、mmap及文件状态查询等调用，再恢复原有权限。当PHP打开apm_css.php3、full_wt.php3或webtop_popup_css.php3时，程序记录文件描述符，并在mmap阶段把嵌入式PHP载荷置于合法内容之前。

结果是，磁盘扫描器读取的仍是原始脚本，Apache执行的却是增加了Web Shell的内存映像。如果可信基线与磁盘内容一致，这三个目标文件的哈希可以全部通过校验。标题中的“全正常”仅指这种情况下的目标PHP文件，不能外推为httpd、umount、启动配置或设备上的其他文件也没有变化。

内存Web Shell之外还有不开放TCP端口的通道

注入的PHP载荷从请求原始正文读取数据，核对特定标记，解密后续内容并交给PHP执行。成功交互会返回HTTP 201，并把内容类型设置为text/css; charset=utf-8，使通信表面上接近webtop样式资源；但单独一次201响应或CSS内容类型并不足以证明感染。

同一植入体系还Hook了apr_time_now，以延迟启动负责本地后门的线程。该线程在/run/bigtlog.pipe绑定AF_UNIX套接字，通过固定认证检查后重定向标准输入、输出和错误流，并执行/bin/bash。它不需要对外监听TCP端口，因此外部端口扫描可能看不到这条交互通道。

样本中没有连接该套接字的客户端代码，也没有证据表明攻击者一定通过HTTP Web Shell访问它。当前能够确定的是两项能力同时存在：一项通过被改写的PHP内存映像提供HTTP代码执行，另一项在设备本地提供交互式Shell。

补丁状态不能代替失陷评估

9月9日发布的技术梳理 列出相关分支的修复版本：17.5.1.3、17.1.3、16.1.6.1和15.1.10.8。F5将其追踪的c05d5254活动与受CVE-2025-53521影响的系统关联；该漏洞适用于在虚拟服务器上配置了访问策略的BIG-IP APM，但单一样本的逆向结果并未还原每起PoisonedRefresh入侵的初始访问过程，不能据此断言所有感染均由该漏洞直接造成。

安装修复版本解决的是相关入口风险，不会自动回答设备此前是否已经失陷。安装与传播组件可感染/usr/sbin/httpd、修改SELinux配置，并处理BIG-IP升级或安装映像中的文件。因此，最终Web Shell虽不必落入三个PHP脚本，攻击链更早阶段仍可能留下磁盘改动。

处置时需要把三项工作分开：先判断设备版本与配置是否处于相关暴露范围；若怀疑已经失陷，在重启或升级前保全Apache进程内存、映射权限、进程关系、打开的UNIX套接字以及HTTP和审计日志；随后再完成完整性检查、修补、重建或可信恢复。补丁状态回答“相关入口是否已修复”，失陷评估回答“攻击者是否进来过”，易失性证据则用于解释运行中的进程究竟执行了什么。

排查重点是同一进程链上的信号组合

这些行为指标都应作为调查线索，而不是单项定论。诊断程序也可能读取/proc，正常应用也可能返回HTTP 201；更有价值的是在相近时间窗口内，把Apache、libphp、目标端点和本地Shell的行为关联起来。

• Apache工作进程读取/proc/self/maps后，libphp映射随即出现RWX到RX的权限变化、重定位修补或对可执行区域的写入。
• /run/bigtlog.pipe被Apache相关进程创建并绑定，随后同一进程树重定向标准流并启动/bin/bash。
• 三个APM webtop的.php3端点收到结构重复或正文大小异常的POST请求，并返回HTTP 201及CSS内容类型。
• /usr/sbin/httpd或/usr/bin/umount相对同版本、同工程热修复级别的可信副本出现哈希、大小或时间戳差异，或者sys-eicheck因相关文件变化而失败。
• 目标PHP脚本的进程内映像比磁盘副本多出无法由正常加载解释的PHP内容，即使磁盘哈希仍与基线一致。

这里必须区分“目标PHP脚本没有落盘变化”和“系统文件都没有变化”。三个脚本原本就是APM webtop组件，它们存在本身不是入侵证据；相反，它们的哈希正常也只能证明磁盘副本未变，不能证明Apache看到的内存副本相同。

完整入侵路径仍未公开

目前已经查明的环节包括分阶段结构、Apache与libphp运行时Hook、三个目标脚本的内存注入方式，以及本地套接字连接/bin/bash的能力。受害者身份与攻击组织归属仍未公布，攻击者实际如何到达本地套接字也不清楚。

PoisonedRefresh并不意味着文件完整性检查失去价值，而是说明这种检查只能覆盖磁盘层。对相关BIG-IP APM设备作出未失陷判断，还需要让版本与补丁状态、关键二进制完整性、Apache进程内存、进程派生、UNIX套接字和HTTP行为彼此印证；在这些证据完成关联之前，正常的PHP文件哈希不能等同于干净的运行时环境。