识别 base64_decode + eval 类混淆后门需检查 eval(base64_decode(、assert(base64_decode( 等组合及 str_rot13、gzinflate 等变体，还原时须在隔离环境将 eval 替换为 echo 输出解密内容，禁止生产环境直接执行或使用在线工具，并排查数据库、.htaccess、auto_prepend_file 等隐蔽落点。
代码混淆型 PHP 后门不能靠“看起来不像后门”就放行，必须还原执行逻辑、定位真实行为、再逐文件清理——否则删了表面，留了内核。
怎么识别 base64_decode + eval 类混淆后门
这类后门最常见：用 base64_decode 解密字符串，再用 eval、assert 或 create_function 执行。它不直接写 shell 命令，但运行时动态加载恶意逻辑。
- 典型特征：
eval(base64_decode(、assert(base64_decode(、call_user_func("base64_decode"等组合 - 注意变体：用
str_rot13、gzinflate、多层嵌套（如eval(gzinflate(str_rot13(base64_decode(...） - 别信文件名或注释——攻击者常把后门塞进
wp-config.php、functions.php末尾，或伪装成缓存文件（如.cache_8a7b.php）
如何安全还原并查看混淆代码的真实行为
还原不是为了“欣赏攻击手法”，而是确认它到底干了什么：连外网？写文件？执行系统命令？必须在隔离环境操作。
- 把可疑代码复制到独立测试脚本中，把
eval换成echo或file_put_contents输出解密后的内容，例如：echo base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMF0pOz8+');→ 输出 - 遇到
gzinflate，先用gzinflate(base64_decode(...))解，再检查结果是否仍是混淆代码（可能多层） - 禁止在生产环境直接
eval还原结果；也不要用在线解密工具——部分会回传数据 - 留意变量来源：
$_SERVER、$_COOKIE、$_REQUEST都可能被用作触发条件，不只$_POST
删完还要查哪些地方容易漏掉
删掉主文件里的混淆代码只是第一步。攻击者往往留多个落点，且利用 CMS 机制隐蔽存活。
立即学习“PHP免费学习笔记（深入）”；
- WordPress 场景：检查
wp-includes/load.php、wp-settings.php开头/结尾，以及所有主题的functions.php和子主题继承链 - 检查数据库：WordPress 的
wp_options表里theme_mods_*或widget_text字段可能存 base64 编码的恶意 JS/PHP 片段 - 检查 .htaccess 是否被加了
RewriteRule转发到隐藏 PHP 文件，或添加了php_value auto_prepend_file - 检查用户级后门：PHP 的
auto_prepend_file或auto_append_file可通过.user.ini或php.ini设置，不依赖单个文件
混淆后门真正的难点不在解密，而在确认它有没有注册持久化钩子、有没有改写核心函数（如重定义 file_get_contents）、有没有监听特定 HTTP 头绕过检测——这些不会出现在明面代码里，得靠行为分析和日志回溯。
