picoCTF Solutions
picoCTF 2026General SkillsHard

Printer Shares 3 picoCTF 2026 Solution

Published: March 20, 2026

Description

I accidentally left the debug script in place... Well, I think that's fine - No one could possibly access my super secure directory.

Setup

Launch the challenge instance and note the host and port.

This is the third Printer Shares challenge (see also Printer Shares 2) - focus on the debug script mentioned in the description.

bash
sudo apt install smbclient

Solution

Walk me through it
  1. Step 1Connect to the SMB share anonymously
    Even with the directory locked down in the developer's mind, the share itself accepts null sessions. The -N flag asks for no password and the server hands over a session anyway.
    bash
    smbclient -L //<HOST> -p <PORT_FROM_INSTANCE> -N
    bash
    smbclient //<HOST>/shares -p <PORT_FROM_INSTANCE> -N
    Learn more

    Null sessions exist at the protocol level. The original SMB/CIFS spec lets a client request a session with an empty username and an empty password. The server never issues a challenge, never validates anything, and replies with a tree connect handle anyway. It was added so machines could enumerate shares and browse the network neighbourhood before authenticating. The result: anonymous access is not a misconfiguration of one knob, it is the default semantics of an empty SessionSetup request unless restrict anonymous is set.

    The description says "no one could possibly access my super secure directory" - this is security through obscurity. The developer locked one folder while leaving the share root anonymous. Kerckhoffs's principle is the right counter: assume the attacker can enumerate every path. Access control must work at the file/directory ACL level, not on the assumption that a path is secret.

    Modern Windows Server disables null sessions by default, but many Linux Samba builds, embedded NAS devices, and printer firmware still ship with them on. See networking tools for CTF for the broader enumeration playbook.

  2. Step 2Recursively browse and find the secure directory
    Turn on recursion, list everything, then batch-download with prompt off. Once everything is local, grep filenames for the kinds of artifacts the developer would have left behind.
    bash
    smb: \> recurse ON
    bash
    smb: \> ls
    bash
    smb: \> prompt OFF
    bash
    smb: \> mget *
    bash
    smb: \> exit
    bash
    # Locally, find the secure directory by scanning filenames
    bash
    ls -R
    bash
    find . -type f \( -name '*.sh' -o -name '*.key' -o -name '*.env' -o -name '*.conf' -o -name '*.bak' \)
    bash
    grep -ril 'flag\|password\|secret' .
    Learn more

    recurse ON makes ls walk every subdirectory instead of just printing the top level. prompt OFF combined with mget * mirrors the entire share to disk without asking yes/no per file. Together they turn smbclient into a one-shot dump tool, which beats clicking through interactive prompts when the "super secure directory" could be five levels deep.

    Debug and dev artifacts left in production are one of the highest-yield findings in real engagements. Exposed .git/, debug.php, config.php.bak, install scripts with hardcoded creds, deploy keys checked into a deploy folder. The recurring pattern: a developer scopes ACLs to one path while the surrounding share is wide open.

    The hunt order is: recursive ls -R for shape, find -name for known-bad extensions (*.sh, *.key, *.pem, *.env, *.sql, *.conf), then grep -ril across file contents for keywords like password, secret, flag. The debug script will pop on the first or second pass.

  3. Step 3Read the debug script for the flag
    The debug script contains hardcoded credentials, paths, or directly echoes/prints the secret. Inspect it locally to extract the flag.
    bash
    cat debug.sh
    bash
    # The flag or credentials to the secure area are inside the script
    Learn more

    Hardcoded credentials and secrets in scripts are one of the most common findings in security audits. Shell scripts used for administration, database setup, or deployment frequently contain passwords, API keys, or other secrets embedded as variables or arguments. When these scripts are accidentally exposed (committed to a public git repo, left on an accessible share, included in a Docker image), the secrets are instantly compromised.

    Even if the debug script doesn't contain the flag directly, it may contain credentials that unlock access to the "super secure directory." The attack chain then becomes: anonymous SMB access → find debug.sh → extract credentials from script → use credentials to access the restricted area → read the flag. This multi-step lateral movement is typical of real intrusions.

    Modern secret management practices (HashiCorp Vault, AWS Secrets Manager, environment variables injected at runtime) avoid embedding secrets in scripts. Static analysis tools like truffleHog, gitleaks, and detect-secrets scan codebases and scripts for accidentally committed credentials - essential CI/CD pipeline security controls.

Flag

picoCTF{pr1nt3r_shar3s_3_d3bug_...}

Despite claims of security, the SMB share allows anonymous access. A debug.sh script was accidentally left in the share - it contains hardcoded credentials or the flag itself.

Want more picoCTF 2026 writeups?

Browse picoCTF 2026Full library

Useful tools for General Skills

Related reading

What to try next