Potential Redis CONFIG SET SSH Authorized Key Injection

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Redis CONFIG SET SSH Authorized Key Injection

This rule detects attempts to abuse Redis CONFIG SET commands to inject SSH authorized keys on Linux hosts. Attackers targeting unauthenticated Redis instances issue CONFIG SET dir to an SSH directory such as /root/.ssh, set the filename to authorized_keys via CONFIG SET dbfilename, write an attacker-controlled public key via SET, and call BGSAVE to flush it to disk, establishing persistent SSH access as root.

Rule type: eql

Rule indices:

logs-network_traffic.redis*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

Domain: Network
Use Case: Threat Detection
Tactic: Persistence
Tactic: Initial Access
Data Source: Network Packet Capture
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Redis CONFIG SET SSH Authorized Key Injection

Redis’s CONFIG SET command allows runtime reconfiguration of the server, including the working directory (dir) and database filename (dbfilename). Attackers targeting unauthenticated Redis instances exploit this to redirect BGSAVE output into /root/.ssh/authorized_keys, injecting their own SSH public key and establishing persistent root shell access without credentials.

The full attack chain is: 1. CONFIG SET dir /root/.ssh — redirects the save path to the SSH directory 2. CONFIG SET dbfilename authorized_keys — sets the output filename 3. `SET key "

ssh-rsa ATTACKER_KEY

"` — writes the public key with surrounding newlines 4. BGSAVE — flushes the in-memory dataset (including the injected key) to disk

A related variant targets cron persistence (CONFIG SET dir /etc/cron.d) for cryptominer deployment, as used by the RedisRaider campaign.

Possible investigation steps

Identify the source IP and determine whether it is an expected Redis client or an external/unknown address. Any external IP issuing CONFIG SET to an SSH directory should be treated as malicious.
Check whether the destination Redis instance requires authentication (requirepass or ACL). Unauthenticated instances are the prerequisite for this attack.
Review subsequent Redis commands from the same source IP for SET (key write) and BGSAVE (flush to disk), which complete the injection chain.
Examine /root/.ssh/authorized_keys and other user SSH directories on the Redis host for unexpected or recently modified entries at or after the alert time.
Check SSH login events on the Redis host for successful logins from unknown keys or source IPs shortly after the alert.
Review outbound connections from the Redis host for lateral movement or C2 activity following a successful key injection.

False positive analysis

CONFIG SET dir is a legitimate administrative command, but pointing it to any /.ssh directory has no legitimate use case. A match on this pattern has an extremely low false positive rate.
CONFIG SET dbfilename authorized_keys has no legitimate operational use. Any match should be investigated immediately.
Automated deployment tooling (Ansible, Chef, Puppet) will never target SSH directories via Redis CONFIG SET — this combination is exclusively malicious.

Response and remediation

Immediately inspect /root/.ssh/authorized_keys and all user ~/.ssh/authorized_keys files on the Redis host for unauthorized entries and remove them.
Rotate SSH host keys and audit all active SSH sessions on the affected host.
Require authentication on all Redis instances (requirepass or ACL). Unauthenticated Redis reachable from any network is the root cause.
Restrict CONFIG SET permissions using Redis ACLs: ACL SETUSER <user> -config.
Block inbound access to Redis port 6379 from untrusted networks at the host firewall or perimeter.
Consider enabling Redis’s protected mode, which rejects connections from non-loopback addresses when no authentication is configured.

Setup

edit

Setup

This rule requires the Elastic network_traffic integration (Packetbeat via Elastic Agent) with the Redis protocol module enabled.

Enabling the Redis module

In the Elastic Agent network_traffic integration policy: 1. Add or confirm Redis in the protocols list with enabled: true. 2. Set ports to include 6379 (or the custom port your Redis instances listen on). 3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic.

TLS limitation

This rule requires unencrypted Redis traffic. Redis uses plaintext by default (port 6379). If TLS is configured, Packetbeat cannot inspect the payload without TLS decryption.

Rule query

edit

network where data_stream.dataset == "network_traffic.redis" and
  (
    (
      network_traffic.redis.query like~ "*CONFIG SET dir*" and
      network_traffic.redis.query like~ "*/.ssh*"
    ) or
    (
      network_traffic.redis.query like~ "*CONFIG SET dbfilename*" and
      network_traffic.redis.query like~ "*authorized_keys*"
    )
  )

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
Technique:
- Name: Account Manipulation
- ID: T1098
- Reference URL: https://attack.mitre.org/techniques/T1098/
Sub-technique:
- Name: SSH Authorized Keys
- ID: T1098.004
- Reference URL: https://attack.mitre.org/techniques/T1098/004/
Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Exploit Public-Facing Application
- ID: T1190
- Reference URL: https://attack.mitre.org/techniques/T1190/

« Potential Redis CONFIG SET Cron Directory Persistence (RedisRaider) Quick Assist Full Control Sharing Mode Enabled »