Skip to content
HackIndex logo

HackIndex

Redis enumeration with nmap and redis-cli

4 min read Jul 14, 2026

Redis on 6379 is frequently exposed with weak or no auth. Confirm auth state, pull server/config details that change your next move, then enumerate DBs and keys to extract secrets.

Service discovery and fingerprinting

┌──(kali㉿kali)-[~]
└─$ nmap -sV -p ${PORT:-6379} --script redis-info $TARGET_IP 
PORT     STATE SERVICE
6379/tcp open  unknown
| redis-info:
|   Version            2.2.11
|   Architecture       64 bits
|   Process ID         17821
|   Used CPU (sys)     2.37
|   Used CPU (user)    1.02
|   Connected clients  1
|   Connected slaves   0
|   Used memory        780.16K
|   Role               master
|   Bind addresses:
|     192.168.121.101
|   Active channels:
|     testChannel
|     bidChannel
|   Client connections:
|     192.168.171.101
|_    72.14.177.105

What you expect:

  • Redis version, uptime, role, and basic server info.

  • If redis-info returns nothing useful, still try redis-cli since some instances restrict INFO but allow basic commands.

Connect and check authentication state

Fast auth check:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} PING

Interpretation:

  • PONG means you can run commands without auth.

  • (error) NOAUTH Authentication required. means you need a password or ACL user.

If you have creds:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} -a "$PASSWORD" PING
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} --user "$USER" --pass "$PASSWORD" PING

Pull server info that changes decisions

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} INFO

What to look for:

  • redis_version, uptime_in_seconds for fingerprinting.

  • role:master|slave and replication fields for later pivot options.

  • Persistence signals: aof_enabled, rdb_last_save_time to understand whether data survives restarts.

If INFO is blocked by ACLs, you’ll see NOPERM. You can still enumerate keyspace if you can read keys.

Keyspace overview and multiple database detection

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} INFO keyspace 
# Keyspace
db0:keys=1245,expires=812,avg_ttl=3560000
db1:keys=22,expires=0,avg_ttl=0

How to use it:

  • DBs with lots of expires usually contain sessions/cache.

  • Small DBs with expires=0 often contain config, feature flags, tokens.

Configuration enumeration

Full config dump (high signal, but may be blocked by ACLs):

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} CONFIG GET '*'

High-value fields to spot immediately:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} CONFIG GET requirepass
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} CONFIG GET protected-mode
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} CONFIG GET bind
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} CONFIG GET dir
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} CONFIG GET dbfilename

Interpretation that matters:

  • protected-mode no + permissive bind usually means the instance is remotely reachable by design or misconfig.

  • dir + dbfilename identifies persistence locations and paths that matter for later write-to-disk style attacks (don’t run those in Enumeration).

If you get NOPERM on CONFIG, stop trying to brute config and move to keyspace/value extraction.

Select database and enumerate keys

Switch DB based on INFO keyspace:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} SELECT 0
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} SELECT <db_number>

Key listing (KEYS vs SCAN)

Small DB quick check:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} KEYS '*'

Safer enumeration:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} --scan
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} --scan --pattern '*token*'
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} --scan --pattern '*secret*'
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} --scan --pattern '*pass*'
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} --scan --pattern '*session*'
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} --scan --pattern '*jwt*'
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} --scan --pattern '*api*key*'

What to do next:

  • If patterns hit, pivot to extracting values by type.

  • If you only see session-like keys, focus on session contents and identifiers rather than trying to dump the entire DB.

Extract values safely by key type

Don’t guess. Identify type first:

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} TYPE "<keyname>"

Read based on type:

┌──(kali㉿kali)-[~]
└─$ # string
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} GET "<keyname>"
 
┌──(kali㉿kali)-[~]
└─$ # hash
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} HGETALL "<keyname>"
 
┌──(kali㉿kali)-[~]
└─$ # list
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} LRANGE "<keyname>" 0 200
 
┌──(kali㉿kali)-[~]
└─$ # set
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} SMEMBERS "<keyname>"
 
┌──(kali㉿kali)-[~]
└─$ # sorted set
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} ZRANGE "<keyname>" 0 200 WITHSCORES
 
┌──(kali㉿kali)-[~]
└─$ # raw serialized value (binary/serialized payloads)
┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} DUMP "<keyname>"

Interpretation:

  • GET/HGETALL often yields direct secrets: API keys, DB creds, OAuth tokens, signing keys.

  • LRANGE/SMEMBERS/ZRANGE often reveals user IDs, job payloads, session IDs, or queue contents.

  • DUMP returning unreadable bytes usually means app-specific serialization; focus on config-ish keys and hashes, or grab identifiers for later app-side decoding.

Deleting keys (intrusive)

Only if your engagement explicitly allows it.

┌──(kali㉿kali)-[~]
└─$ redis-cli -h $TARGET_IP -p ${PORT:-6379} DEL "<keyname>"

Deleting session/config keys can break running services or log users out.

References