MuzzyBox: Practising Injection and Linux Privilege Boundaries

Challenge overview

I created MuzzyBox as a CTF for practising web testing and following injection flaws through to their consequences. The original introduction covers NoSQL injection, Python code injection, server-side template injection, and Linux privilege escalation.

The aim is to understand the application's behavior and its trust boundaries. Running a familiar payload is only useful if I can explain which component interpreted it and what access it provided.

The machine is listed on VulnHub. My GitHub repository links the original VM download and walkthrough material.

My old post was an introduction to the challenge. It did not contain a complete service inventory, exploitation transcript, or flag. I preserve that scope rather than adding a fictional solve.

Prepare the lab

I import the VM into a compatible hypervisor and connect it to an isolated network shared with my testing machine. I take a snapshot before changing anything.

I check the assigned address from the lab environment instead of assuming the VM uses the same IP as a previous run. If I cannot reach it, I check the network adapter mode and guest boot state before treating the problem as part of the challenge.

Recon

I begin with an initial service scan:

nmap -sV -oN muzzybox-services.txt LAB_VM_IP

LAB_VM_IP is a placeholder for the imported machine's actual lab address. The default port selection is a starting point; follow-up coverage depends on the results.

For each web entry point, I save a baseline request and response. I note accepted content types, parameters, error handling, and any difference between unauthenticated and authenticated behavior.

I keep a simple record of what I know and what I am guessing. A Python-looking error can suggest an implementation detail, but it does not establish a working code-injection path by itself.

Foothold

NoSQL injection

I look for places where request-controlled values can change a database query's structure. The distinction is between supplying a value and controlling an operator or expression.

Before testing that boundary, I check how the application parses the request. JSON objects, form fields, and plain strings can reach the database differently. A payload copied from another format may test the request parser rather than the database query.

A credible finding needs the baseline request, the changed input, and a repeatable difference in behavior. The original introduction did not include those details.

Python code injection

I investigate whether input reaches Python evaluation or another execution primitive. This is different from simply finding an application written in Python.

I start with a harmless observation that can distinguish interpreted input from literal data. If that succeeds, I document the execution context before testing further impact.

Escalation or solve

Server-side template injection

For SSTI, I check whether input becomes template source. A small expression can help establish evaluation, but the engine and exposed objects determine what is possible next.

The original post identified SSTI as a challenge theme without recording a complete payload chain. I do not assume that it is interchangeable with the Python code-injection stage or that either automatically grants root.

Linux privilege escalation

Once a genuine shell or equivalent execution context exists, I record the account and permissions before looking for an escalation path:

whoami
id

The useful explanation is the permission boundary that failed. It might involve a privileged operation or configuration, but the original article did not identify which one. I leave that detail open rather than attaching a generic Linux exploit to this machine.

Flag

No flag value or retrieval command was included in the original notes.

Dead ends and lessons

I keep each injection hypothesis separate until the responses establish a connection. Query manipulation, Python evaluation, and template evaluation can look similar from the outside while requiring different fixes.

When I return to this machine, I want my notes to show the path from an input to a parser, from that parser to a capability, and from that capability to a new privilege. That is the part of a CTF that transfers to application reviews.