SEC504 - Hacker Tools, Techniques, and Incident Handling

SMB Share Enumeration and Credential Discovery

Solo, Lab

Focus: Network Security

Level: SEC504

Date: Jun 2026

Artifacts: Sanitized smbclient session output from the SEC504 Slingshot Linux lab against a file server at 172.30.0.22 (FLSM-NAS)

TL;DR

•smbclient enumerated shares on a NAS and exfiltrated a full home directory in a single tar command
•A stale backup.ps1.OLD hardcoded ConvertTo-SecureString 'Clippers2022' for another user (csparkes)
•Reusing that credential opened a second share holding a 33.8 MB database backup (db.backup.sql.zip)

Skills demonstrated

SMB share enumeration with smbclient (-L, user%pass)Interactive smbclient navigation and file retrievalIn-session exfiltration with smbclient tarCredential discovery in logon and backup scriptsLateral movement via credential reuse

Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.

Why this matters

SMB shares are where organizations quietly leak the material an attacker needs to move laterally: logon scripts, proxy configs, and backup scripts with credentials baked in. Nothing here was an exploit. It was a readable file share, correct permissions on one directory and not another, and a password that lived on in a .OLD file after someone did the right thing and switched the live script to Get-Credential. That last detail is the whole lesson: fixing the current file does not remove the secret from the old one.

Context

This lab walks a full SMB compromise chain against a NAS: enumerate shares with one set of credentials, read a home directory the account should not have been able to reach, find a stale PowerShell backup script with a hardcoded password, and reuse that password to reach a second share holding a full database backup. Every step uses smbclient, the point being that the whole chain runs from readable files and reused credentials, not an exploit.

Tools used

smbclientNmap 7.60tarSlingshot LinuxCLI

Steps taken

1Confirm the target and enumerate shares

nmap confirmed only 172.30.0.22 was up with 139/netbios-ssn and 445/microsoft-ds open. smbclient -L listed the shares. Passing credentials inline as user%pass avoids the prompt; the SMB1 workgroup-listing failure at the end is expected because SMB1 is disabled.

$ sudo nmap -sT -p 139,445 172.30.0.2-254
$ smbclient -L //172.30.0.22 -U tdoudney%Falsimentis123

-Llist shares

-U user%passinline credentials

2Read the IT share scripts

The IT share held logon.cmd and netssh.cmd. logon.cmd mapped drives (net use z: \\FLSM-NAS\Users), and netssh.cmd set a WinHTTP proxy to proxy.falsimentis.com:3128. Logon scripts are reconnaissance gold: they name internal hosts, shares, and the proxy an attacker would route through.

$ smbclient //172.30.0.22/IT -U tdoudney%Falsimentis123
$ get logon.cmd
$ get netssh.cmd

get <file>download from the share

logon.cmd/netssh.cmd reveal internal infrastructure

3Browse Home and check per-user ACLs

The Home share exposed csparkes, ttidmas, and tdoudney directories. csparkes was correctly protected (NT_STATUS_ACCESS_DENIED on ls), but tdoudney's own directory was readable and held backup.ps1, backup.ps1.OLD, and a ScoutSuite report.

$ smbclient //172.30.0.22/Home -U tdoudney%Falsimentis123
$ cd csparkes
$ ls
$ cd ../tdoudney
$ ls

ACCESS_DENIED on csparkes = correct ACL; tdoudney's own dir is readable

4Exfiltrate the home directory in one command

smbclient's built-in tar streamed the whole directory (16.2 MB) into a single local tarball, then extracted it. One command exfiltrates an entire share path, no per-file get loop needed.

$ tar c tdoudney-home.tar
$ # locally:
$ tar xf tdoudney-home.tar

tar ccreate archive of the current share path

Streams every file in one operation

Exfiltrate the home directory in one command

5Recover the hardcoded credential

backup.ps1 correctly used Get-Credential (interactive, no stored secret). But backup.ps1.OLD hardcoded ConvertTo-SecureString 'Clippers2022' -AsPlainText -Force for falsimentis.com\csparkes. Someone fixed the live script and left the password sitting in the .OLD copy.

$ cat backup.ps1
$ cat backup.ps1.OLD

The .OLD file still contains the plaintext password the live script no longer stores

6Reuse the credential for lateral movement

csparkes/Clippers2022 opened the CustomerDev share, which held a full web application tree (index.php, install.php, version.php, engine/, mod/) and db.backup.sql.zip at 33.8 MB. A stale password in one user's home directory became read access to another user's database backup.

$ smbclient //172.30.0.22/CustomerDev -U csparkes%Clippers2022
$ cd FS
$ ls

Reused discovered credential; CustomerDev holds the app source + db backup

Reuse the credential for lateral movement

Key findings

Home share exposed all user directories; csparkes correctly denied, tdoudney readable

backup.ps1.OLD hardcoded 'Clippers2022' for falsimentis.com\csparkes

Live backup.ps1 correctly used Get-Credential; the leak was only in the .OLD copy

csparkes/Clippers2022 opened CustomerDev, exposing db.backup.sql.zip (33.8 MB)

smbclient tar exfiltrated a 16.2 MB home directory in one command

Outcome / Lessons learned

Chained SMB share enumeration into lateral movement without a single exploit: readable logon scripts, a home directory with correct ACLs on one folder and a leaked script in another, a hardcoded credential in a stale backup file, and credential reuse into a share holding a 33.8 MB database backup.

Rotate the csparkes credential immediately and grep every share for ConvertTo-SecureString, -AsPlainText, and password patterns in .ps1/.OLD/.bak files. Move backup credentials to a managed secret store (or gMSA) so scripts never hold plaintext. Audit share ACLs so home directories are per-user private by default, and remove stale .OLD/.bak script copies. Enable SMB access auditing so mass reads like the tar exfiltration are visible.

Security controls relevant

Secret management for service and backup credentials (no plaintext in scripts)
Least-privilege share ACLs (per-user private home directories)
Removal of stale .OLD/.bak script copies
SMB access and file-read auditing
Credential rotation on discovery of exposure

What I took away from this

The single most important detail is the .OLD file. The developer did the right thing: the live backup.ps1 uses Get-Credential and stores nothing. But the previous version, with the password compiled in, was never deleted. Remediation that only touches the current file leaves the secret fully recoverable in version history, backup copies, and stale filenames. Rotating the credential is the only fix that actually works, because you can never be sure you have found every copy.

Nothing in this chain was an exploit, and that is what makes it realistic. Share enumeration, a readable logon script, a home directory, credential reuse: every step is a normal file operation that a legitimate user could perform. Defenses that wait for an exploit signature will never fire here. The controls that matter are permissions, secret hygiene, and access auditing, none of which involve a CVE.