Redis RCE via CONFIG Command Abuse: Detection and Mitigation

Threat Overview: The Persistent Risk of Unprotected Redis

Redis, an open-source in-memory data structure store, is frequently utilized as a database, cache, and message broker. However, its historical design priority on performance over security has led to a recurring TTP where attackers exploit misconfigured instances. According to SANS ISC, unprotected Redis instances remain a primary target for attackers seeking to gain RCE by abusing the built-in configuration capabilities of the service.

While newer versions of Redis include a ‘protected mode’ that prevents external connections when no password is set, many administrators disable this feature for development convenience or during cloud migrations, inadvertently exposing the service to the public internet. When an instance is exposed without a password, an attacker can connect using the standard redis-cli tool and gain full control over the database, which often serves as a stepping stone for Privilege Escalation on the host operating system.

Technical Breakdown: Redis CONFIG Command Security Risks

The primary mechanism for this attack involves the abuse of the CONFIG SET and CONFIG GET commands. These commands allow a user to modify the behavior of the Redis server dynamically without restarting the process. In a typical exploitation scenario, the attacker follows a specific sequence to achieve file system persistence:

1. Memory Clearing: The attacker may use FLUSHALL to clear existing data, though this is not strictly necessary for the exploit.
2. Payload Injection: A key is created containing a malicious payload, such as an SSH public key or a reverse shell script formatted for a cron job.
3. Directory Redirection: The attacker uses CONFIG SET dir /root/.ssh/ or CONFIG SET dir /var/spool/cron/crontabs/ to change the working directory where Redis saves its database file.
4. Filename Manipulation: The CONFIG SET dbfilename authorized_keys (or root) command changes the output filename to a sensitive system file.
5. Persistence Execution: The SAVE command is issued, forcing Redis to write the in-memory data—including the malicious payload—to the specified system path.

This method bypasses traditional EDR signatures that look for binary exploits, as it utilizes legitimate service features to perform unauthorized file writes. Once the file is written, the attacker can achieve Lateral Movement by logging in via SSH or waiting for the cron job to execute their C2 beacon.

How to detect Redis RCE exploit attempts

Defenders should prioritize visibility into the Redis command log. If the SIEM is ingestings Redis logs, security teams should alert on any occurrence of the CONFIG command being executed from an external IP address. Specifically, monitoring for CONFIG SET dir or CONFIG SET dbfilename is a high-fidelity IoC for an ongoing attack. Furthermore, the SOC should look for unexpected file modifications in /root/.ssh or /var/spool/cron attributed to the redis user account.

Utilizing MITRE ATT&CK framework mapping, this activity aligns with Technique T1059.003 (Command and Scripting Interpreter: Windows Command Shell) or T1053.003 (Scheduled Task/Job: Cron), depending on the persistence mechanism chosen. Regular auditing of the redis-server process using tools like auditd can reveal when the service attempts to write to directories outside of its expected database storage path.

Remediation: Securing Redis 7.0 Instances from Unauthorized Access

To effectively defend against these threats, organizations must move away from default configurations and adopt a Zero Trust approach to internal service exposure. Even though this attack does not rely on a specific CVE, its impact is equivalent to a critical vulnerability.

1. Rename Dangerous Commands: In the redis.conf file, use the rename-command directive to obfuscate or disable the CONFIG, FLUSHALL, and SAVE commands. For example: rename-command CONFIG "" entirely disables the command.
2. Enforce Authentication: Always use the requirepass directive to enforce strong password authentication, even for internal traffic.
3. Network Isolation: Bind Redis to 127.0.0.1 or a private VPC subnet. Never expose port 6379 to the public internet.
4. Filesystem Permissions: Ensure the Redis process runs under a dedicated service account with minimal permissions, preventing it from writing to /root or /etc even if the service is compromised.

By implementing these controls, administrators can ensure they are properly securing Redis 7.0 instances from unauthorized access and mitigating the risk of configuration-based remote code execution.