HTB Dancing - Anonymous SMB Access and Exposed Network Shares

Target: 10.129.97.193

Dancing is one of HackTheBox's Starting Point machines, built as an introduction to SMB enumeration on Windows. It was also my first Windows-focused box after working through Linux targets like Cap, and that showed immediately in the recon: a completely different port signature, different tooling, and a different shape of vulnerability. Same workflow as the Cap writeup though: raw notes taken during the CTF, expanded into a proper post afterward with an LLM.

Recon

Full port scan first:

sudo nmap -Pn -p- --min-rate 1000 10.129.97.193

-Pn skips host discovery and treats the target as up regardless of ping response; many Windows boxes on HTB don't answer ICMP, so this avoids nmap wrongly marking the host as down. -p- scans the full 65535 port range instead of the default top 1000. --min-rate 1000 keeps the scan from slowing down unnecessarily.

The result was eleven open ports: 135 (msrpc), 139 (netbios-ssn), 445 (microsoft-ds), 5985 (wsman), 47001 (winrm), and a block of high ephemeral ports from 49664 to 49669 (msrpc). That combination, especially 135/139/445 alongside 5985, is about as clear a "this is Windows" fingerprint as nmap gives you. The ephemeral ports are just dynamically assigned RPC endpoints, normal on any Windows host.

With SMB confirmed on 445, I ran two targeted NSE scripts instead of a full -sCV pass:

nmap --script smb-protocols -p 445 10.129.97.193
nmap --script smb-security-mode -p 445 10.129.97.193

smb-protocols lists which SMB dialects the server supports; this one answered with everything from 2.0.2 up through 3.1.1, meaning it accepts both legacy and modern SMB clients. smb-security-mode is meant to report whether message signing is required, which matters for relay-style attacks, but on this run it came back with nothing beyond confirming the port was open. No extra fields returned. Not a dead end exactly, just not useful here.

Enumeration

To actually talk to the share I needed smbclient, which macOS doesn't ship by default; macOS uses its own SMB implementation rather than Samba's. Installed it with Homebrew:

brew install samba

Then connected directly to the share with no credentials at all:

smbclient //10.129.97.193/Workshares

It let me in. No username, no password, no prompt I had to bypass; just a clean anonymous login. That alone is the misconfiguration this machine is built around: a null SMB session with read access to a share that should require authentication. Once inside, help showed the available commands, and ls at the share root showed two directories named after actual users: Amy.J and James.P.

Exploitation

There's no separate exploit step here; the anonymous session already was full read access. "Exploitation" on this machine is just continuing to use the access enumeration handed me.

smb: \> cd James.P
smb: \James.P\> ls
  flag.txt                            A       32  Mon Mar 29 14:26:57 2021

smb: \James.P\> get flag.txt
getting file \James.P\flag.txt of size 32 as flag.txt

Back on the local machine:

cat flag.txt
5f61c10dffbc77a704d76016a22f1664

32 bytes lines up exactly with a 32-character hex string, so the file size was a small confirmation before even opening it.

While in the share I also checked Amy.J's directory and pulled down worknotes.txt for a closer look, since a personal notes file sitting in an open share is exactly the kind of place credentials or other sensitive details tend to surface.

smb: \Amy.J\> get worknotes.txt
getting file \Amy.J\worknotes.txt of size 94 as worknotes.txt

Conceptually this is the same family of bug as the IDOR in Cap: a missing access control check. There, the gap was an unauthenticated user being able to request another user's data by changing an ID in a URL. Here, the gap is the SMB server permitting an unauthenticated session at all. Different protocol, same root cause: nothing was checking who was asking before handing over the data.

Privilege Escalation

None required. This machine doesn't involve a shell or a privilege boundary to cross; the anonymous SMB session already provided full read access to the relevant files. Unlike Cap, there was no second stage here.

Flags

cat flag.txt
5f61c10dffbc77a704d76016a22f1664

Key Takeaways

Anonymous SMB access is still a real-world finding, not just a CTF setup. Any share reachable without authentication is reachable by anyone on the network, full stop.

The access control failure here is the same class of problem as the Cap IDOR, just enforced at the protocol layer instead of the application layer. Worth remembering that "broken access control" isn't tied to one specific technology; it shows up wherever an authorization check is assumed but never actually implemented.

A file sitting in a user's share doesn't need to be obviously sensitive to be worth grabbing. worknotes.txt is a mundane filename, and it was still worth pulling the moment I had read access.

Tooling differs across platforms in small but real ways. macOS not shipping Samba's smbclient by default is a minor friction point, but it's the kind of thing worth knowing before starting rather than discovering mid-enumeration.

The recon signature alone (135, 139, 445, 5985, 47001) was enough to know this was Windows before running a single SMB command. Worth internalizing that port pattern as a quick fingerprint going forward.