Skip to main content
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

Investigate an exposed network share and chain together clues to authenticate as a valid user and retrieve the flag.

Published: March 20, 2026Updated: September 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 1Enumerate shares and read the public share anonymously
    Observation
    This follows the earlier Printer Shares over SMB, so start the same way: enumerate shares without credentials and see what the more secure server still hands to a guest.
    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
    prompt OFF
    bash
    mget *
    bash
    exit
    bash
    # Read the notification file:
    bash
    cat notification.txt

    Expected output

    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 while still allowing null sessions. -N skips authentication rather than submitting a credential, and many CTF SMB servers accept only that path. Supplying a guest username produces a logon failure that makes a public share look closed.

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

    enum4linux and smbmap work well on the standard port and need coaxing, or fail quietly, on a non-standard one. smbclient takes the port directly. enum4linux wraps several tools whose port handling can misreport accessibility, making a populated server look empty.

    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 2Brute-force joe's password against the restricted share
    Observation
    notification.txt in the public share names the user joe and says his default password was never changed. That is a wordlist attack against the restricted share.
    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 pass a custom port through reliably and often falls back to 445 regardless of the flag, so every attempt hits the wrong endpoint and is refused. NetExec wires the port through cleanly, which is why this step calls for it rather than the more commonly recommended tool.

    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 without naming the product, so there is no single obvious guess. A handful of manual attempts will not beat rockyou.txt, which holds nearly every common default in frequency order. Manual guessing can also trip a lockout policy and block the real run afterwards.

    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 3Connect as joe and retrieve the flag
    Observation
    NetExec marks one attempt as a success and names the password. Those credentials open the restricted share.
    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

    With the password cracked it is tempting to revisit the public share, and the connection does succeed, since joe can read it too. But the directory holds the same notification file and decoys. The flag is only in the restricted share.

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

    mount.cifs wants root and a local mount point, and its non-standard port syntax hides in the options field where it is easy to get wrong. The interactive smbclient path is faster and needs no sudo. mount.cifs also struggles with older SMB dialects that smbclient negotiates on its own.

    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{5mb_pr1nter_5h4re5_5ecure_...}

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.

Key takeaway

An authenticated share is only as strong as the credentials guarding it, so a world-readable file naming an account and admitting its default password is still in use collapses the whole boundary. Anonymous recon, then information disclosure, then a credential attack, then authenticated access: that is a textbook lateral-movement chain in real breaches. Deny anonymous reads, keep internal notes out of open shares, and enforce strong passwords with lockout.

Related reading

Useful tools for General Skills

Where to go next

Try these next