Skip to main content

ABSOLUTE NANO picoCTF 2026 Solution

You land in a restricted shell with limited commands available. Find a way to break out and read the flag.

Published: March 20, 2026Updated: September 22, 2026

Description

You have complete power with nano. Think you can get the flag?

Launch the challenge instance and SSH in.
Check what sudo permissions are available.
bash
sudo -l

Solution

Want to try it yourself first?

The guided walkthrough reveals hints one step at a time.

Walk me through it
  1. Step 1Check sudo permissions
    Observation
    The description promises complete power with nano, which points at an unusual sudo grant on a text editor. Enumerate the sudo permissions first.
    Run sudo -l. It lists what you can run as root, and shows nano with NOPASSWD here. See the linux CLI guide for more sudo enumeration patterns.
    bash
    sudo -l

    See linux CLI for CTF for sudo and shell escape recipes.

    What didn't work first

    Tried: Running 'sudo su' or 'sudo bash' directly to get a root shell

    Both commands fail with 'Sorry, user picoplayer is not allowed to execute /bin/su or /bin/bash as root'. sudo -l reveals which exact binaries are permitted - without checking first, you waste time trying commands the sudoers policy never allowed.

    Tried: Running 'cat /etc/sudoers' to read the policy instead of using sudo -l

    The sudoers file is owned by root and not world-readable, so cat returns 'Permission denied'. sudo -l is the correct way to enumerate grants because sudo itself evaluates the policy and prints only the rules that apply to your user.

    Learn more

    sudo -l lists the commands a user is permitted (and forbidden) to run as root or another user. The output comes from /etc/sudoers or drop-in files in /etc/sudoers.d/. In CTF challenges, misconfigured sudo rules often grant access to editors, interpreters, or utilities that can be leveraged for privilege escalation.

    In this challenge the output looks like:

    User picoplayer may run the following commands on challenge:
        (root) NOPASSWD: /usr/bin/nano /etc/sudoers

    NOPASSWD: means sudo will not prompt for the user's password. The path can be a single binary, an absolute path with fixed arguments, or a wildcard. Wildcards are dangerous because sudo matches them with fnmatch and deliberately lets * span /, so a rule for /var/log/*.log is satisfied by an argument such as /var/log/../../etc/shadow.log. Path restrictions only apply to the literal command - once nano runs, it inherits root privileges for everything it can spawn.

    Even after sudo nano drops you into a root editor, sudo's default env_reset behaviour scrubs most environment variables (PATH, LD_PRELOAD, IFS) so you cannot abuse those vectors. The shell escape works because nano spawns its child with a fresh shell, not because of any inherited env. The classic reference for techniques is GTFOBins (gtfobins.github.io). In real engagements, sudo -l is one of the first enumeration steps after gaining a foothold.

  2. Step 2Open /etc/sudoers as root via the restricted nano grant
    Observation
    sudo -l shows nano granted root access on exactly one file: /etc/sudoers. Opening that file is the escalation.
    The sudo rule allows nano only for /etc/sudoers. Open that file with the granted command.
    bash
    sudo nano /etc/sudoers
    What didn't work first

    Tried: Running 'sudo nano /etc/passwd' or 'sudo nano /root/.bashrc' to open a different file

    sudo rejects the command immediately with 'Sorry, user picoplayer is not allowed to execute /usr/bin/nano /etc/passwd as root'. The rule hard-codes the argument to /etc/sudoers, so nano can only be invoked on that exact path.

    Tried: Using the GTFOBins nano shell escape (Ctrl+R then Ctrl+X) to spawn a root shell inside the editor

    This is not actually a dead end: the sudo rule fixes which file nano may open, not what nano may do once it is running as root, so the execute-command prompt still spawns a root shell here. It is only unreliable, because nano started in restricted mode (rnano, or nano -R) disables that prompt entirely. Editing the sudoers file is the path that works no matter how nano was built.

    Learn more

    Because the rule is (root) NOPASSWD: /usr/bin/nano /etc/sudoers, you cannot run sudo nano on an arbitrary file. The only allowed invocation is sudo nano /etc/sudoers, which opens the sudoers policy file in an editor running as root.

  3. Step 3Edit /etc/sudoers to grant yourself full privilege
    Observation
    nano is running as root with write access to the policy file, so append a permissive rule for your own user and the narrow grant becomes unrestricted sudo.
    Inside nano, scroll to the bottom of the file and add a line that gives your user unrestricted NOPASSWD sudo access. Save with Ctrl+O, confirm the filename, then exit with Ctrl+X.
    bash
    # At the bottom of the file, add:
    bash
    picoplayer ALL=(ALL) NOPASSWD: ALL
    bash
    # Then press Ctrl+O to save and Ctrl+X to exit
    What didn't work first

    Tried: Adding '%sudo ALL=(ALL) ALL' or modifying an existing group line instead of adding a user-specific line

    Group lines require picoplayer to actually be in that group; 'groups' will confirm it is not in sudo or wheel by default. A direct user line 'picoplayer ALL=(ALL) NOPASSWD: ALL' bypasses group membership entirely and takes effect immediately on save.

    Tried: Pressing Ctrl+X without first pressing Ctrl+O, expecting nano to prompt to save

    nano does prompt to save on exit, but a wrong filename or a stray keystroke discards the edits and you start over. Saving explicitly before you exit settles it.

    Learn more

    Adding picoplayer ALL=(ALL) NOPASSWD: ALL at the bottom of /etc/sudoers overrides the previous narrow rule. sudo processes rules top-to-bottom and the last matching entry wins, so placing the permissive line at the bottom guarantees it takes effect. After saving, sudo will immediately honour the new policy without requiring any restart.

    The GTFOBins Ctrl+R Ctrl+X shell escape reaches root here too: pinning the argument to /etc/sudoers limits which file nano opens, not what the root-owned editor process can spawn. Editing the policy file is preferred only because it survives a nano started in restricted mode (rnano, or nano -R), where the execute-command prompt is compiled out.

  4. Step 4Read the flag using the new sudo grant
    Observation
    The new rule takes effect the moment the file is saved, so any command now runs as root, including reading the flag.
    With the new unrestricted sudo rule in place, read the flag directly.
    bash
    sudo cat /flag

    Expected output

    picoCTF{n4n0_411_7h3_w4y_...}
    Learn more

    You now have full sudo access, so sudo cat /flag reads the flag as root. If /flag is not present, check /root/flag.txt or run sudo find / -name flag.txt 2>/dev/null.

Interactive tools
  • Reverse Shell GeneratorGenerate reverse shell payloads (bash, nc, python, perl, ruby, php, node, powershell) and matching listeners. Set host and port once, copy any variant.
  • Regex TesterTest regular expressions against a string with live match highlighting, flag toggles, and common CTF pattern shortcuts.
  • 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{n4n0_411_7h3_w4y_...}

The sudo rule restricts nano to /etc/sudoers - edit that file to add a permissive rule for yourself, then use the new grant to read the flag.

Key takeaway

Sudo escalation comes from overly permissive rules handing a low-privilege user root access to particular binaries. Editors, interpreters, and shell utilities are the worst grants, because they spawn subprocesses or write arbitrary files, turning one narrow capability into full root. GTFOBins catalogs hundreds of these, and sudo -l is among the first things a penetration tester runs after getting a foothold.

Related reading

Useful tools for General Skills

Where to go next