picoCTF Solutions
PathPart of the Advanced General Skills path · Step 5 of 5: Modern Security Tooling
picoCTF 2026General SkillsHard

Printer Shares 2 picoCTF 2026 Solution

Published: March 20, 2026

Description

A Secure Printer is now in use. I'm confident no one can leak the message again... or can you?

Setup

Launch the challenge instance and note the host and port.

This is a follow-up to Printer Shares - the server is 'more secure' but still uses SMB.

bash
sudo apt install smbclient

Solution

Want to try it yourself first?

The guided walkthrough reveals hints one step at a time.

Walk me through it
  1. Step 1
    Enumerate shares and read the public share anonymously
    Observation
    I noticed the challenge is an SMB-based follow-up to Printer Shares, which suggested starting with the same unauthenticated share enumeration step to see what the 'more secure' server still exposes to guest connections.
    Start by listing all SMB shares without credentials. The server exposes two shares: a public 'shares' folder (guest-accessible) and a restricted 'secure-shares' folder for internal use only. Connect anonymously to the public share and list its files. You will find several text files, including notification.txt.
    bash
    # List all shares (no credentials needed):
    bash
    smbclient -L //<HOST> -p <PORT_FROM_INSTANCE> -N
    bash
    # Connect to the public share as guest:
    bash
    smbclient //<HOST>/shares -p <PORT_FROM_INSTANCE> -N
    bash
    # Inside smbclient, list and download all files:
    bash
    ls
    bash
    mget *
    bash
    exit
    bash
    # Read the notification file:
    bash
    cat notification.txt

    Expected output

    SMB  <HOST>  <PORT_FROM_INSTANCE>  [+] joe:password123 (Pwn3d!)
NOTICE: Secure printer share updated.
User: joe
Please remind joe to update his default password.
    What didn't work first

    Tried: Trying smbclient with -U guest or -U '' to authenticate instead of using -N for a null session

    Some servers reject the literal username 'guest' even though they allow null sessions. The -N flag skips authentication entirely rather than submitting a guest credential, and many CTF SMB servers only accept the unauthenticated null session path. Using -U guest or -U '' may produce an NT_STATUS_LOGON_FAILURE error and appear to block access even though the share is public.

    Tried: Using enum4linux or smbmap to enumerate shares instead of smbclient

    enum4linux and smbmap work well on standard port 445 but often require extra flags or fail silently when the server runs on a non-standard port. smbclient accepts -p directly and is the most reliable choice here. enum4linux in particular wraps several tools and its port-forwarding behavior can misreport share accessibility, making it seem like no shares exist.

    Learn more

    SMB (Server Message Block) is a network protocol for file and printer sharing. It supports multiple authentication levels: null sessions (no credentials), guest access, and authenticated users. A server can expose some shares publicly while keeping others restricted - but placing sensitive information in a public share defeats the purpose of the restriction.

    Information disclosure is one of the most common and underappreciated vulnerability classes. notification.txt reveals the username "joe" and hints that his default password is still in use. This is a classic operational security failure: internal communications left in a world-readable location hand attackers exactly the recon they need.

    The -N flag tells smbclient to skip authentication entirely (null session). mget * with prompt OFF downloads every file in the current directory without asking for confirmation per file.

  2. Step 2
    Brute-force joe's password against the restricted share
    Observation
    I noticed that notification.txt in the public share disclosed the username 'joe' and stated his default password had not been changed, which suggested a wordlist brute-force attack against the restricted share using a common password list like rockyou.txt.
    notification.txt tells you the username is 'joe' and that he is still using a default password. Standard tools like Hydra struggle with non-standard ports here, but NetExec (nxc) handles it cleanly. Run nxc with the rockyou.txt wordlist against the SMB service using joe's username. The password will be found after a few minutes of brute-forcing.
    bash
    # Install NetExec if needed:
    bash
    sudo apt install netexec
    bash
    # Brute-force joe's password (takes ~10 min against rockyou):
    bash
    nxc smb <HOST> --port <PORT_FROM_INSTANCE> -u 'joe' -p /usr/share/wordlists/rockyou.txt --ignore-pw-decoding
    bash
    # Look for a line marked [+] in the output - that line shows the cracked password.
    What didn't work first

    Tried: Using Hydra instead of NetExec to brute-force SMB on a non-standard port

    Hydra's smb module does not reliably pass a custom port to the underlying SMB library and often falls back to port 445 regardless of the -s flag, meaning every attempt hits the wrong endpoint and returns connection refused. NetExec's --port flag wires the custom port through cleanly, which is why the step explicitly calls for nxc rather than the more commonly recommended hydra.

    Tried: Skipping the wordlist and trying common defaults like 'password', 'joe', '123456' manually with smbclient before running a full brute-force

    The notification says 'default password' but does not say which product or system joe's account belongs to, so there is no single obvious guess. Manually trying a handful of passwords is unlikely to hit before rockyou.txt does - rockyou contains nearly all common defaults and dictionary words in order of frequency. Guessing manually may also trigger a login lockout policy before the real password is found, blocking the nxc run afterward.

    Learn more

    NetExec (nxc) is the actively maintained successor to CrackMapExec. It supports SMB, WinRM, RDP, SSH, and other protocols and handles non-standard ports via the --port flag. The --ignore-pw-decoding flag prevents crashes when rockyou.txt contains non-UTF-8 byte sequences.

    Credential brute-forcing against SMB is noisy in real networks (failed logins fill event logs and can trigger lockouts), but effective when a user genuinely has a dictionary password. The "default password still in use" hint in notification.txt almost guarantees the password is near the top of rockyou.txt, keeping the runtime manageable.

    If nxc is unavailable, Metasploit's auxiliary/scanner/smb/smb_login module also accepts a custom RPORT and wordlist, and is a reliable fallback for non-standard ports.

  3. Step 3
    Connect as joe and retrieve the flag
    Observation
    I noticed that NetExec marked a login attempt with [+] and identified joe's cracked password, which indicated I now had valid credentials to authenticate against the restricted 'secure-shares' share and retrieve flag.txt.
    With joe's cracked password in hand, connect to the restricted 'secure-shares' share using smbclient with explicit credentials. List the directory, download flag.txt, and read it locally.
    bash
    # Connect to the restricted share as joe:
    bash
    smbclient //<HOST>/secure-shares -p <PORT_FROM_INSTANCE> -U 'joe'
    bash
    # Inside smbclient (enter the cracked password when prompted):
    bash
    ls
    bash
    get flag.txt
    bash
    exit
    bash
    # Read flag.txt
    bash
    cat flag.txt
    What didn't work first

    Tried: Connecting to the 'shares' public share as joe instead of the 'secure-shares' restricted share

    After cracking joe's password it is tempting to re-connect to the familiar public share with the new credentials, but the flag lives exclusively in 'secure-shares'. Connecting as joe to 'shares' will still succeed (joe can read the public share too) but the directory only contains the same notification.txt and other decoy files - flag.txt is not there.

    Tried: Attempting to mount the share with mount.cifs rather than using smbclient interactively

    mount.cifs requires root privileges and a local mount point, and the syntax for non-standard ports uses the options field (port=XXXX) rather than a direct flag, which is easy to get wrong. On many CTF environments the smbclient interactive approach is faster and does not require sudo. mount.cifs also tends to fail when the server uses an older SMB dialect that smbclient negotiates automatically.

    Learn more

    SMB access control lists (ACLs) restrict share access per user. The "secure-shares" share denies anonymous and guest connections but allows authenticated users in the printer group. Once joe's credentials are valid, smbclient authenticates normally and the share behaves identically to any other.

    This challenge teaches a critical lesson: locking down a share with authentication only raises the bar if the credentials themselves are strong. Weak or default passwords combined with information disclosure (notification.txt naming the account) reduce the "secure" share to one wordlist run away from full exposure. The attack chain - anonymous recon, information disclosure, credential brute-force, authenticated access - is a textbook lateral movement pattern in real enterprise breaches.

Interactive tools
  • Hex ViewerView text or raw hex bytes as a xxd-style hex dump with byte offset, hex columns, and ASCII sidebar. Highlights printable characters and null bytes.
  • Strings ExtractorPull printable text from any binary, library, or image. ASCII and UTF-16 detection, configurable minimum length, flag-like highlight, no command line needed.

Flag

Reveal flag

picoCTF{pr1nt3r_shar3s_2_...}

The flag is inside flag.txt in the secure-shares share, accessible only after brute-forcing joe's password from the username hint in notification.txt.

Related reading

Want more picoCTF 2026 writeups?

Browse picoCTF 2026Full library

Useful tools for General Skills

What to try next