HTB Redeemer — Reading an Agent's Memory

Part of the OSAI Prep series → — HTB writeups mapped to OWASP LLM Top 10.

Machine Summary

Reconnaissance

Initial port scan:

nmap -sC -sV -oN nmap.txt 10.129.136.187

The scan reveals Redis running on port 6379. Redis is an in-memory key-value store most commonly used for caching, session management, and message queuing. In production it should require authentication. Here, it doesn’t.

We connect directly using the Redis CLI:

redis-cli -h 10.129.136.187

No password prompt. We’re at the Redis command line with full access. We confirm the version:

We enumerate what’s stored:

INFO keyspace

Four keys in the keyspace. We retrieve all key names:

KEYS *

Returns: Numb, Temp, Stor, Flag. We extract the flag:

GET Flag

Done. Unauthenticated access to the store gave us everything — no exploitation, no escalation, just enumeration.

Privilege Escalation

Not required. Direct Redis access was sufficient.

Root Cause

Redis 5.0.7 running on port 6379 with no requirepass directive. Any client that can reach the port gets full read/write access — no username, no password, no authentication of any kind. Default configuration, never hardened.

The AI Equivalent

OWASP LLM Top 10 Mapping: LLM06 — Sensitive Information Disclosure (secondary risk: LLM01 — Prompt Injection via agent memory)

Redis is one of the most common backing stores for LLM agent systems — it holds conversation history, retrieved document chunks, tool call results, and session state between turns. An unauthenticated Redis instance in an agentic deployment doesn’t just leak cached data; it exposes the agent’s entire working memory.

The four keys on Redeemer — Numb, Temp, Stor, Flag — map directly to what you’d find in a production agent’s Redis store: a session token, a temporary scratchpad, a retrieved document, and a sensitive output. Running KEYS * and GET gives an attacker the same information the agent has, in real time.

The secondary risk is more serious: with write access, the attacker can inject false context into active sessions. The agent reads its Redis memory on the next turn and acts on data the attacker planted. That’s LLM01 — prompt injection — but executed through the memory layer rather than the input layer, which means most prompt injection defenses don’t catch it. You’re not manipulating the prompt; you’re manipulating what the agent remembers.

This is the attack surface that gets missed in AI security reviews. Teams audit the model inputs, the system prompt, the tool definitions. Nobody checks whether the Redis instance backing the agent’s memory is sitting open on port 6379.

Lessons Learned

• Always set requirepass in Redis. One line in redis.conf fixes this. There is no excuse for a production Redis instance without a password.
• Bind Redis to localhost or a private interface. Redis should never listen on a public IP. Use bind 127.0.0.1 and access it through an SSH tunnel or private network.
• Use Redis ACLs for fine-grained access control. Redis 6+ supports Access Control Lists — read-only users don’t need write access. Separate credentials per service, minimum privilege per role.
• Treat agent memory stores as high-value targets. If Redis holds session data for an AI agent, it holds everything the agent knows about its users and its current task. Protect it with the same rigor as your primary database — because in agentic systems, it effectively is your primary database.