Redis攻击利用总结
Redis介绍
什么是redis
Redis 是 C 语言开发一个开源高性能的 key-value 键值对存储类型的内存NoSQL数据库,且支持持久化到硬盘,广泛应用在数据集群,分布式队列,信息中间件等网络架构中。在实际渗透场景中,Redis 常常用来缓存 Session、网站页面架构、短信验证码等数据。
版本区别
冷知识:
严格来说主从同步在 2.8 之前就有了,2.8 之前触发全量复制的命令是 sync 和 psync,但是使用 sync 只能执行全量同步,2.8 之后的命令同时支持全量同步和部分同步。总而言之,2.8 之前的主从同步是有缺陷的,而且如今也几乎不可能碰到低于 3.x 版本的 redis 了,怼着这点深究没意义。
所以,主从复制并不是只有 4.x - 5.x 才有的,只是 4.x 开始才新增了自定义 so 文件模块的功能,结合主从复制把 so 文件丢过去就能 RCE。
而 6.x 也依然支持主从复制功能,只是官方新增了对 so 文件的权限校验,所以你丢个 so 文件过去也没法 RCE。具体见commit
Redis >= 2.8
1
2
3默认无密码。
新增主从同步功能,换言之,从这个版本开始攻击者可以利用主从复制实现无损文件上传。
无损文件上传为 Windows 的 Redis 利用拉开了很好的口子,因为可以无损上传 DLL、EXE、VBS、LNK 等完成劫持和写入启动项。Redis <= 3.2.0
1
默认无密码,监听 0.0.0.0,裸奔Redis > 3.2.0
1
2新增保护模式(protected-mode),该模式默认开启,该模式不允许远程连接。
默认还是无密码,但是默认监听本地 127.0.0.1,不对外开放,除非自己配置为 0.0.0.0,且把 protected-mode 改为 no。Redis 4.x - 5.x
1
默认还是无密码,且监听 127.0.0.1,新增自定义模块加载特性,结合主从复制上传so文件可利用这个可直接 RCERedis 6.x
1
2
3新增了针对Redis模块和so文件的执行权限校验,所以主从复制上传的so文件无法被执行了(https://github.com/redis/redis/pull/6257),但是主从复制传输无损文件依然可用,config写文件也依然可用。
Github Commit 标题:Modules must have execute permissions to load
redis命令行
命令行连接
1 | |
信息探测
一般关注以下信息:redis 版本、进程id、系统版本、系统架构
1 | |
漏洞利用
Linux
Linux上Redis RCE的路子主要有两种:
一种是直接写入文件,可以是ssh公钥、webshell也可以是计划任务;
另一种是Redis4.x、5.x上的主从getshell,这比写东西来的更直接方便。
计划任务
利用条件
redis 服务使用 root 账号启动
CentOS机器(在 debian、ubuntu 等环境中由于这些环境对计划任务的格式解析非常严格,所以没办法执行成功)
这个方法只能Centos上使用,Ubuntu上行不通,原因如下:
因为默认redis写文件后是644的权限,但ubuntu要求执行定时任务文件
/var/spool/cron/crontabs/<username>权限必须是600也就是-rw-------才会执行,否则会报错(root) INSECURE MODE (mode 0600 expected),而Centos的定时任务文件/var/spool/cron/<username>权限644也能执行因为redis保存RDB会存在乱码,在Ubuntu上会报错,而在Centos上不会报错
由于系统的不同,crontrab定时文件位置也会不同:
Centos的定时任务文件在
/var/spool/cron/<username>Ubuntu定时任务文件在
/var/spool/cron/crontabs/<username>
计划任务格式
1 | |
例如,下面这个是每1分钟反弹1次shell:
1 | |
计划任务写入位置
- /var/spool/cron/root(文件,且文件名得问用户名)
- /etc/crontab(文件,计划任务中得指明用户名,且程序都要用绝对路径,该文件只有root可写)
利用过程
就正常写计划任务就行,只是要在前后加上\n\n:
1 | |
**注意:**网上的 redis getshell 计划任务语句大都有问题,只有/var/spool/cron/root这条可以,核心就是要在语句的左右两边都加1个 \n 。
经笔者测试,/etc/crontab这个文件在带入 redis 脏数据后即使成功换行了也无法成功得到执行,具体原因不详,如果有朋友解决了这个可以在评论区补充。目前只能通过主从复制带入无损文件 crontab 进行利用。
注意:/etc/crontab 中的环境变量是与系统独立的,也就是说,任何程序都要写绝对路径才能成功,例如 bash 必须得写成 bin/bash,不然无法成功反弹 shell
- /etc/cron.hourly、/etc/cron.weekly、/etc/cron.mouthly、/etc/cron.daily(文件夹,且只有 root 可在里面写文件)
顾名思义,放在里面的 sh 脚本文件会被按照对应的时间(时、周、月、日)呈规律被执行,但是,脚本需要具备可执行权限(x)才可被执行,而我们通过 redis 主从同步复制进去的文件默认权限为 rw-r–r– ,所以几个计划任务路径无法通过 redis 完成利用。
如果是自己复现,可以使用下面的语句查看计划任务执行状态:
1 | |
ssh公钥
利用条件
- redis 服务使用 root 账号启动
- 服务器开放了SSH服务,而且允许使用密钥登录(服务器默认关闭 key 登录选项)
**注意:**经实战测试,阿里云机器(CentOS)的这个选项虽然是被注释掉的,但是其实只要你写key,就能直接通过 key 去连接,原因不详,测试时发现 authorized_keys 中已经有一个 key,是阿里云的,可能这是官方的需求吧。从其它笔者的文章能看出,云主机基本都是默认就可以通过key去连接。所以,只要不是管理员故意设置为 no,那么都是可以的。
1 | |
利用过程
(1)生成一对 ssh 公私钥
1 | |
(2)因为即使 flushall 了也还是有脏数据,但是幸好 Linux 对 authorized_keys 的解析是比较模糊的,通过换行不让脏数据和公钥数据挤在一行即可,所以为了保证写入的 authorized_key 能被解析,必须引入换行符 \n\n
1 | |
(3)写入 key 文件
1 | |
(4)连接
1 | |
写 webshell
利用条件
- redis 服务使用 root 账号启动
- 已知 web 绝对路径
利用过程
1 | |
主从复制配合动态库加载
利用条件
- redis 4.x或者redis 5.x
利用原理
主从模式指使用一个 redis 作为主机,其他的作为备份机,主机从机数据都是一样的,从机只负责读,主机只负责写,该功能从 redis 2.8+ 开始有。
在 reids 4.x 之后,通过外部拓展,可以通过构造 so 文件在 redis 中实现一个新的 redis 命令。在两个 redis 实例设置主从模式的时候,redis 的主机实例可以通过 FULLRESYNC 同步文件到从机上,然后在从机上加载恶意so文件,即可执行命令。
先利用主从复制把 so 文件远程复制过去,然后再通过 MODULE LOAD 来加载 so 文件即可 RCE,其过程如下:
1 | |
**注意:**由于采用的是全量传输备份,所以该利用方式会将对方所有数据库清空覆盖,很容易打草惊蛇,而且对业务可能会造成不可挽回的影响
利用过程
这里提供几种工具
第一种:n0b0dyCN/redis-rogue-server: Redis(<=5.0.5) RCE
1 | |

第二种:Dliv3/redis-rogue-server: Redis 4.x/5.x RCE
本项目为n0b0dyCN同名项目的fork, 在原项目代码基础之上修复了一些bug, 添加了一些新功能, 并针对不同漏洞利用场景做了一些优化。
1 | |
第三种:Ridter/redis-rce: Redis 4.x/5.x RCE
此仓库是 https://github.com/n0b0dyCN/redis-rogue-server 的修改版本。
1 | |
第四种:0671/RabR: Redis-Attack By Replication (通过主从复制攻击Redis)
本工具基于Ridter师傅的redis-rce进行修改。
- 本工具利用这个Redis的脆弱性,对Linux下的Redis进行module攻击、crontab写入攻击和ssh公钥写入攻击,对Windows下的Redis进行module攻击和dll劫持攻击。
- 本工具默认使用的Linux恶意模块:exp/linux/exp.so,源码来自于:rsa_keyRedisModules-ExecuteCommandrsa_key , 该模块实现了执行单条命令和反弹shell的功能,你也可以编写自己的模块。
- 本工具默认使用的crontab文件:exp/linux/exp.crontab,使用前务必根据自己实际的需求进行修改,或者直接通过命令行设置自己的crontab文件。
- 本工具默认使用的ssh公钥文件:exp/linux/exp.authorized_keys,使用前务必自己重新生成以替换,或者直接通过命令行设置自己的ssh公钥文件。
- 本工具默认使用的Windows恶意模块:exp/win/exp.dll,源码来自于:rsa_keyRedisModules-ExecuteCommand-for-Windowsrsa_key , 该模块实现了执行命令的功能,你也可以编写自己的模块。
- 本工具默认使用的用于劫持的恶意dll:exp/win/dbghelp.dll,是通过 rsa_keyDLLHijackerrsa_key + rsa_keyWinx64下的dbghelp.dllrsa_key编译生成的,该dll会执行calc,你也可以编译自己的dbghelp.dll。
- 本工具有爆破功能,默认密码字典位于pwd.txt中,也可自定义字典文件。
- 本工具在攻击前会备份目标Redis的数据,在攻击结束后会进行恢复,使用的工具为rsa_keyredis-dump-gorsa_key。默认是开启的,可以关闭。
1 | |
第五种:r35tart/RedisWriteFile: 通过 Redis 主从写出无损文件
此脚本是通过 Redis 主从写出无损文件,可用于 Windows 平台下写出无损的 EXE、DLL、 LNK 和 Linux 下的 OS 等二进制文件
或者MDUT也可以主从同步

禁用 config 命令绕过
管理员可以通过以下命令来禁用 config 命令,
1 | |
这样的话我们就无法自定义路径和文件名了,但是这并不影响主从复制的利用,我们还是可以利用主从复制把 so 文件丢过去,只是由于无法自定义路径和文件名,所以我们的 so 文件传过去后会会变为 dump.rdb,直接利用通过以下方法正常加载还是能 RCE:
1 | |
注意:/data/dump.rdb 为 redis 数据库文件默认路径
Windows
微软官方的Redis在Windows上只支持到3.2.100和3.0.504(参考microsoftarchive/redis),更高版本的Windows Redis都是第三方的,这也是实战中Windows服务器上的Redis很多是3.2.100和3.0.504的原因。
Windows上主要有下面几种打法:
| 方式 | 利用要求 | 利用方法 |
|---|---|---|
| Webshell | Administrator能直接写,普通用户看运气,Network Service权限写不了。要有web且知道路径 | 有IIS服务的情况下,可以尝试往C:/inetpub/wwwroot/写Webshell,其他Web服务要猜目录 |
| 启动项 | Administrator能直接写,普通用户需要猜用户名,Network Service权限写不了。必须要重启机器(用户登录)才能生效 | 比如往startup目录写启动项 |
| MOF | 要System权限才能写,且是win2003 | 将后门写在nullevt.mof中,默认5秒会执行一次 |
| 主从同步+动态库加载 | 无权限要求,但3.x的Redis并没有模块加载的功能,需要redis 4.x或者redis 5.x | 4.x之后的Redis允许用户加载自定义dll,可用主从复制写入恶意DLL,直接加载执行 |
| system文件劫持 | 要System权限才能写,或关掉NT6(Vista/7/8/8.1/10/11) 及以上操作系统的 UAC | 比如把cmd.exe覆写到sethc.exe / utilman.exe / osk.exe 等辅助功能程序,在RDP登录界面调出命令行 |
| DLL劫持 | 无权限要求 | 劫持dbghelp.dll,主从复制写入恶意DLL并通过Redis命令触发 |
| 其他花式 | Administrator能直接写,普通用户需要猜用户名,Network Service权限写不了 | 比如写一个exe马,再整个快捷方式伪装一下放到桌面上,等运维人员打开 |
写 Webshell
利用条件
Web目录写马条件比较苛刻,首先这台机器上要有Web,其次还要有机会泄露Web的绝对路径
这是 getshell 成功率较高的办法了。
利用过程
1 | |
写启动项
利用条件
- 用户名得爆破,且爆破成功得机率很低,而且 Administrator 用户不一定存在(大部分时候为具有 Administrator 权限的自定义用户)
- 必须要重启机器(用户登录)才能生效。所以这个利用比较鸡肋,因为 Windows Server 的话是很少关机的,如果没有 BDoS 漏洞的话,我们得等待对方重启,payload 才能执行;
利用过程
和Linux不太相同,Windows的自启动有几类:系统服务、计划任务、注册表启动项、用户的startup目录。其中前三种是无法通过单纯向某目录中写文件实现精准篡改的,因此只有startup目录可以利用
往下面目录写入 VBS、Powershell、Exe:
1 | |
如果管理员将 Redis 添加了服务项并配了一个高权限(如Administrator甚至SYSTEM),那么 Administrator 账户的路径就一定可写了。
1 | |
MOF
利用条件
- system权限
- win2003
如果目标机器是win2003那就比较幸运了,不用再被动等待人为操作了。
托管对象格式 (MOF) 文件是创建和注册提供程序、事件类别和事件的简便方法。文件路径为:
1 | |
其作用是每隔五秒就会去监控进程创建和死亡。但这个默认5秒执行一次的设定只有win2003及以下系统才会有……
例如如下脚本(WMI永久后门):
1 | |
将其保存为nullevt.mof并写入C:/windows/system32/wbem/mof路径下,而且由于win2003没有默认UAC的控制,只要权限够就可以直接写入。
写入后几秒钟脚本就会执行(反弹shell),执行成功会放在good文件夹,失败放在bad文件夹
1 | |
主从复制配合动态库加载
利用条件
- redis 4.x或者redis 5.x
Redis 3.x版本并不支持模块加载功能(主从同步RCE需要关键模块MODULE LOAD,这个是redis4.0之后才有的),因此基于主从同步进行RCE不可行——因为无法加载DLL模块。
虽然微软对 Windows 版 Redis 的更新停留在了 3.x,但是也有其它第三方团队针对 Windows 平台做了 Redis 的适配,例如这个项目,直接适配到了 5.x 版本:
所以,即使是 Windows 平台,只要版本为 4.x 或 5.x ,同样可以进行 Module Load 直接 RCE。
主从复制配合 Module Load 与 Linux 步骤一致,只是文件不能是 so 文件了,而得是 Windows 平台的 DLL,DLL 项目源码如下:
0671/RedisModules-ExecuteCommand-for-Windows: 可在Windows下执行系统命令的Redis模块,可用于Redis主从复制攻击。
利用过程
以此工具为例:r35tart/RedisWriteFile: 通过 Redis 主从写出无损文件
(1)先把 DLL 传递过去
1 | |
(2)执行命令
1 | |
system文件劫持
利用条件
- Redis 以 SYSTEM 权限运行(注意:不是 Administrator,而是要 SYSTEM)
- UAC 彻底关闭
这个利用点几乎不可能在实战中用到,因为需要管理员或者SYSTEM权限,这里主要指的是通过写文件覆盖已有的文件或劫持DLL以达到欺骗的目的,虽然还是被动等待上线(比如把cmd.exe覆写到sethc.exe / utilman.exe / osk.exe 等辅助功能程序,在RDP登录界面调出命令行),但概率明显要比等机器重启要高得多。比较通用的方法是向 system32 目录下写文件,但 NT6(Vista/7/8/8.1/10/11) 及以上操作系统的 UAC 必须关掉,或 Redis 以 SYSTEM 权限启动,否则脚本显示成功但实际上是无法写入的。
而在 Windows 中,管理员常用的,有两种方式使程序以 SYSTEM 权限运行:
- 利用 Windows 自带的任务计划程序,计划任务默认以 SYSTEM 权限运行程序
- 创建服务,以服务方式启动的程序默认都以 SYSTEM 权限运行
利用过程
比如把cmd.exe覆写到sethc.exe / utilman.exe / osk.exe 等辅助功能程序,在RDP登录界面调出命令行
1 | |
DLL劫持
DLL劫持简介:
在Windows操作系统中,动态链接库(DLL)用于存放通用代码,供多个应用程序共享使用。当一个程序需要调用DLL中的函数时,它首先会尝试从特定路径加载DLL文件。如果该程序未指定DLL的绝对路径,而是仅指定了DLL的名字,系统将按照预设的顺序搜索DLL文件的位置。这种机制为攻击者提供了机会,通过在高优先级路径放置恶意DLL来实施DLL劫持攻击。
其实和system文件劫持
标准的DLL查找顺序:
- 应用程序目录
- 系统目录(如C:\Windows\System32)
- 16位系统目录(如C:\Windows\SysWOW64)
- Windows目录(如C:\Windows)
- 当前工作目录
- 系统环境变量PATH中指定的路径
例如,如果”example.exe”尝试加载名为”example.dll”的DLL但没有提供完整路径,系统会在上述顺序中寻找此DLL。若攻击者提前在应用程序目录放置了同名的恶意DLL,该恶意DLL会被优先加载执行。
具体案例:劫持dbghelp.dll
以redis-server.exe为例,在执行bgsave操作时,它首先在其应用目录中查找dbghelp.dll。利用Redis主从复制特性,攻击者可以在应用目录中写入恶意DLL,从而实现劫持。
DLL劫持可以函数转发劫持也可以往完整DLL插入恶意代码
函数转发劫持
为了不影响目标应用的正常功能,攻击者可能会采用函数转发劫持的方式。这要求攻击者导出原始DLL的所有函数,并确保这些函数能够正确指向原DLL中的对应地址。工具如DLLHijacker可以帮助自动化这一过程,但可能需要针对一些问题进行修复,比如中文乱码、匿名函数处理以及确保正确引用原DLL的绝对路径等。
正确的DLL劫持不仅不会影响应用程序的功能,还可以重复多次实施不同的攻击策略,如上线CS或使用Metasploit Framework发起反向shell攻击。关键在于保证恶意DLL正确转发对原始DLL函数的调用请求,维持目标应用的正常运行状态。然而,若不正确地处理原DLL的路径,可能导致目标应用的功能异常,甚至无法重启。
利用过程
从本地的system32文件夹下提取出 dbghelp.dll,然后使用 dllHijack 脚本,
由于每个人的操作系统版本不一样,所以system32文件夹下面的 dbghelp.dll 可能也会有区别,但经过尝试,Windows10、Windows11的dbghelp.dll都可行
dllHijack这里最好是用这个修改过的, 原版的脚本会报错
dllHijack实际上有VS2019、VS2022两个版本,但VS2022的GitHub已经不开源了,所以这里就用VS2019的
生成dbghelp.dll的Visual Studio 2019的项目文件
1 | |
修改shellcode前,产生项目的命令必须为默认的
dbghelp,不能使用Win11dbghelp.dll等不规范的文件名,不然会失败
再用visual Studio 2019 打开项目文件
重点
请在VS2019中修改项目的属性。如果不改,那么靶机无法加载生成出来的DLL
1、设置运行库为多线程 (/MT 或 /MTd):
- 在属性页面中,导航到:配置属性 > C/C++ > 代码生成。
- 找到 “运行库”(Runtime Library)选项。
- 如果当前是 Release 配置(截图中您已选择 Release x64),设置为 “多线程 (/MT)”,这里推荐Release。
- 如果是 Debug 配置,设置为 “多线程调试 (/MTd)”。
- 确保在顶部下拉菜单中选择正确的配置(Release 或 Debug)。
2、禁用安全检查 (/GS):
- 仍在 配置属性 > C/C++ > 代码生成 页面。
- 找到 “安全检查”(Buffer Security Check)选项。
- 设置为 “禁用安全检查 (/GS-)”。
3、关闭生成清单:
- 导航到:配置属性 > 链接器 > 清单文件。
- 找到 “生成清单”(Generate Manifest)选项。
- 设置为 “否 (/MANIFEST:NO)”。
这里我直接换成release:

配置如图,别忘了点击“应用”来保存


然后打开CS 生成一个payload 输出格式为C

在VS2019中替换 dllmain.cpp 中的shellcode(ctrl+s保存)

之前已经选择了 Release x64 ,生成DLL文件即可

生成成功

下面几个项目都可以主从复制,去覆盖redis的DLL,达到劫持的效果,注意要在vps上运行,我们都试一下。
第一种:r35tart/RedisWriteFile: 通过 Redis 主从写出无损文件
把生成好的文件(在..\dbghelp\x64\Release\里)上传到 RedisWriteFile.py 同级目录下面
然后把脚本 RedisWriteFile 文件夹上传到你的VPS上(记得在安全组里面开放你vps的16379端口)
重申:不管用上面哪个脚本,一定要在vps上运行,本地是不可行的
依次执行下面几条命令:
1 | |
结果如图

第二种:0671/RabR: Redis-Attack By Replication (通过主从复制攻击Redis)
这个更方便,可以直接上线
依次执行下面几条命令:
1 | |
结果如图

然后就可以看到靶机上线CS了
CVE-2025-49844
参考文章:
CVE-2025-49844 Redis Lua 引擎 Use-After-Free 漏洞复现笔记 - hzhsec - 博客园
Redis 安全防护策略
如何防护你的 Redis 我认为可以从以下几个方面切入。
禁止监听在公网地址
将你的 Redis 监听在 0.0.0.0 的是十分危险的行为,对 Redis 的大多数攻击也都是由于管理员的大意而将 Redis 监听在了 0.0.0.0。 作为一个经常在内网中出现的应用,将 Redis 监听在 0.0.0.0 很可能导致内网横向移动渗透风险。
修改 Redis 监听端口需要在 Redis 的配置文件 redis.conf 中进行设置,找到包含 bind 的行,将默认的bind 0.0.0.0改为bind 0.0.0.0或内网 IP,然后重启 Redis。

修改默认的监听端口
Redis 默认监听的端口为 6379,为了更好地隐藏服务,我们可以在 redis.conf 中修改 Redis 的监听端口。找到包含 port 的行,将默认的 6379 改为其他自定义的端口号,然后重启 Redis。

开启 Redis 安全认证并设置复杂的密码
为了防止 Redis 未授权访问攻击以及对 Redis 密码的爆破,我们可以在 Redis 在 redis.conf 配置文件中,通过 requirepass 选项开启密码认证并设置强密码。还可以限制登录IP

禁止使用 Root 权限启动
使用 Root 权限去运行网络服务是比较有风险的,所以不建议使用任 Root 权限的何用户启动 Redis。加固建议如下:
1 | |
设置 Redis 配置文件的访问权限
因为 Redis 的明文密码可能会存储在配置文件中,禁止不相关的用户访问改配置文件是必要的,如下设置 Redis 配置文件权限为 600:
1 | |
参考文章
踩坑记录-Redis(Windows)的getshell-先知社区
Windows中redis未授权通过dll劫持上线 - 我要变超人 - 博客园