jperezduerto.info
← all walkthroughs

Scanned

Linux· Insane· Credential Access· Privilege Escalation
owned
2026-07-15
time to own
24m54s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

Scanned exposed only SSH and an nginx-hosted malware-analysis application. The web application accepted uploaded binaries, ran them inside a seccomp-filtered chroot, and returned a syscall report. Its downloadable source disclosed both the sandbox restrictions and the chroot layout. That knowledge made it possible to build a small binary that stayed inside the permitted syscall set while reading a credential file and writing its contents into the scanner's output.

The recovered credential authenticated over SSH as clarence. Local enumeration did not reveal a conventional sudo path; the decisive escalation reused the sandbox design. A SUID program crossed into the chroot and loaded a shared library from a location the sandbox could influence. Replacing that library with a constructor payload created /tmp/rootbash as a SUID-root binary. Executing it with privilege preservation produced an effective UID of root and access to the final objective.

Attack path — how the box was taken

Map the small exposed surface, read the published MalScanner source, model the seccomp and chroot boundaries, use the scanner itself to disclose the SSH credential, establish a shell as clarence, then turn the SUID program's chroot library lookup into root code execution.

1ReconnaissanceNetwork service enumeration (T1046)
Reduced the exposed surface to SSH and the MalScanner web application
A focused version scan confirmed OpenSSH 8.4p1 on TCP 22 and nginx 1.18.0 on TCP 80. With no other externally reachable service in the retained scan, the web application became the primary attack surface.
The retained banner scan identified OpenSSH 8.4p1 Debian 5 and nginx 1.18.0.
Exact commands 2
Bind the retired instance address locally.
export TARGET="<retired-instance-ip>"
Confirm the two retained service banners.
nmap -Pn --host-timeout 20s --max-retries 1 -sV -p22,80 $TARGET
2EnumerationUnauthenticated source disclosure
Downloaded and reviewed the MalScanner application and sandbox source
The landing page offered the application's source without authentication. The archive contained the web front end and the program responsible for launching uploaded binaries. Reviewing those files exposed the sandbox's seccomp policy, its chroot setup, and how scan output was returned to the browser. The exact download path was not preserved, so no command is reconstructed here.
3AnalysisSeccomp and chroot boundary analysis
Mapped the permitted syscalls and the chroot-visible credential path
Source review showed that the sandbox allowed a narrow set of file and output operations while placing the uploaded program inside a predictable chroot. The important combination was not a forbidden syscall bypass: the permitted open, read, and write behavior could reach a sensitive file inside the sandbox's visible filesystem and return its contents through the scanner's normal report channel. The retained record does not contain the exact source filenames or credential path.
4ExploitationSandbox file-read disclosure (T1552.001)
Used a syscall-constrained binary to return the SSH credential in the scan report
A compact binary was built around the allowed file operations: open the credential file identified during source review, read it into memory, and write the bytes to standard output. MalScanner executed the upload inside the chroot and copied that output into its response. The result disclosed clarence's SSH password, represented here as [REDACTED: clarence SSH password]. Because the exact source path and final exploit source were not retained, no substitute code is presented.
5FootholdValid accounts (T1078)
Authenticated over SSH as clarence and captured the user objective
The credential returned by MalScanner was valid for password-based SSH. Authentication established a stable shell as clarence, with UID and GID 1000, and the user objective was readable from the account's home directory.
id returned uid=1000(clarence) gid=1000(clarence) groups=1000(clarence); user.txt returned [REDACTED: user flag].
Exact commands 2
Bind the recovered password without exposing it in the walkthrough.
export CLARENCE_PASSWORD="[REDACTED: clarence SSH password]"
Confirm the foothold and read the user objective.
sshpass -p "$CLARENCE_PASSWORD" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 clarence@$TARGET 'id; cat /home/clarence/user.txt'
6Privilege EscalationDynamic linker hijacking (T1574.006)
Reused the chroot boundary to hijack a SUID program's library load
Local enumeration identified a SUID program whose execution crossed into the scanner's chroot and resolved a shared library from a location writable through that environment. A replacement library used a constructor to copy /bin/bash to /tmp/rootbash and set mode 4755. Triggering the SUID program loaded the replacement at elevated privilege, leaving the backdoor owned by root. The retained record proves the resulting file's ownership and mode, but not the exact SUID binary or library path, so those commands are intentionally omitted.
7Full CompromiseSetuid execution (T1548.001)
Executed the SUID-root shell and captured the root objective
The final retained command first checked the backdoor's owner and mode, then launched Bash with -p so the effective UID was preserved. The shell returned euid=0(root) and could read the root objective.
/tmp/rootbash was owned by UID/GID 0 with mode 4755; the preserved shell returned euid=0(root) and root.txt returned [REDACTED: root flag].
Exact commands 2
Bind the recovered credential if this is a fresh shell.
export CLARENCE_PASSWORD="[REDACTED: clarence SSH password]"
Verify the artifact, preserve the effective UID, and read the root objective.
sshpass -p "$CLARENCE_PASSWORD" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 clarence@$TARGET 'stat -c "%u:%g %a %y %n" /tmp/rootbash 2>&1; /tmp/rootbash -p -c "id; cat /root/root.txt" 2>&1'

Attack patterns used

The transferable techniques behind the compromise.

Source-assisted attack-surface analysisDiscovery · Analysis

What it is

Published application source turns black-box testing into a code-review problem. Here it revealed the sandbox policy, filesystem boundary, and report channel that formed the initial-access chain.

Why it works

Source disclosure becomes dangerous when production paths, trust boundaries, or secrets differ from the assumptions made by the developer. Remove deployment artifacts from the web root and audit all downloadable archives.

Seccomp-aware sandbox file readCredential AccessT1552.001

What it is

The payload did not need a general sandbox escape. It used operations the policy already allowed to read a chroot-visible credential file and returned the bytes through the intended output channel.

Why it works

A syscall allowlist is only one boundary. The sandbox also needs a minimal filesystem, no sensitive mounts, and strict control over what output is returned to an untrusted caller.

Valid-account reuse over SSHInitial AccessT1078

What it is

A password recovered from the application environment was accepted by the operating system's SSH service, converting a transient file-read primitive into a stable interactive shell.

Why it works

Shared credentials collapse service boundaries. Use distinct secrets for applications and system accounts, rotate exposed values, and disable SSH password authentication where practical.

SUID chroot library hijackingPrivilege EscalationT1574.006

What it is

A privileged program entered a filesystem boundary influenced by an unprivileged user and loaded a shared object from that boundary. Constructor code in the replacement library therefore ran with the program's elevated identity.

Why it works

SUID execution and writable library paths must never intersect. Keep every executable, dependency, and chroot path in the privileged load chain root-owned and non-writable, and remove unnecessary SUID bits.

Findings

MalScanner exposed a chroot-visible credential through attacker-controlled executionCritical
Public source disclosed the sandbox contract, while permitted file operations and unfiltered process output allowed an uploaded binary to read and return an SSH credential.
A SUID program trusted a writable shared-library path inside the chrootCritical
The privileged loader crossed into a user-influenced filesystem and executed replacement library code as root, producing a persistent SUID-root shell.

Exposed services

22/tcp
80/tcp

Operational notes

The source code was the map
The smallest useful path was to stop broad service probing once only SSH and HTTP were confirmed, then treat the downloadable source as the primary enumeration target.
The allowed syscalls were enough
The initial exploit succeeded by composing permitted file operations rather than defeating seccomp itself. Sandbox reviews must consider reachable data and output channels alongside the syscall policy.
The first SUID artifact did not cross the root boundary
An early payload produced a mode-4755 shell owned by the sandbox account, which preserved only that account's effective UID. Ownership, mount options, and the exact privileged load path had to be verified before the successful root-owned artifact was accepted.
Evidence gaps stay visible
The record preserves the successful SSH and final root commands, but not the exact source-download URL, credential path, SUID filename, or library destination. Those steps are therefore documented at technique level without reconstructed commands.