chrono

Description

Solution

1. Step 1List cron artifacts
   Although the flavor text references cron, the flag ends up in /challenge/metadata.json. Visiting that path is enough.
   Learn more

   Cron is the Unix task scheduler. It reads crontab files - plain text tables where each line specifies a time pattern and a command - and runs those commands at the scheduled times. System-wide crontabs live in /etc/cron.d/, /etc/crontab, and the /etc/cron.{hourly,daily,weekly,monthly} directories; per-user ones are stored in /var/spool/cron/crontabs/.

   In CTF forensics and privilege-escalation scenarios, cron is worth examining because: (1) scripts invoked by root cron jobs may be writable by a lower-privileged user, allowing code execution as root; (2) cron jobs often log artifacts (temporary files, output files) that contain sensitive data; (3) poorly written cron scripts can expose credentials or intermediate results in world-readable locations - exactly as happened here with metadata.json.

   Use crontab -l to list the current user's jobs and cat /etc/crontab to inspect system jobs. Tools like pspy can monitor process creation in real time to catch cron jobs that run without appearing in static files.

   The crontab time format has five fields before the command: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 represent Sunday). Wildcards (*) match every value; step values (*/5) run every fifth unit; ranges (1-5) specify spans. The shorthand @reboot runs a command once at startup - a common persistence mechanism in Linux malware because it survives reboots without modifying any obvious system files.

   In CTF privilege escalation, a writable cron script executed by root is a reliable escalation path. If a root cron job calls /tmp/cleanup.sh and the current user can write to /tmp/, replacing that script with a reverse shell or SUID-setting command gives root access on the next cron trigger. The tool LinPEAS automatically checks for writable cron scripts as part of its privilege escalation audit.

2. Step 2Read the flag
   Use cat or vim to read metadata.json and copy the picoCTF flag at the top.
   Learn more

   JSON (JavaScript Object Notation) is the de-facto format for structured configuration and metadata in modern software. On many CTF servers, challenge infrastructure stores per-instance data - port numbers, generated flags, expiry times - in a JSON file written by the provisioning system (often a cron job or systemd unit).

   When investigating a Linux system for flags or credentials, always check common metadata locations: /challenge/, /home/*/, /tmp/, and /var/. Files named metadata.json, config.json, or secrets.json are prime targets. The jq utility provides pretty-printing and field extraction if the JSON is complex: jq .flag metadata.json.

   Understanding how systemd-based Linux systems schedule work alongside cron is increasingly important. systemd timers are the modern replacement for cron and work in tandem with systemd service units. List active timers with systemctl list-timers --all. Timers appear in /etc/systemd/system/ or /lib/systemd/system/ and may be less obvious to inspect than a single /etc/crontab file, making them useful for both system administration and adversarial persistence.

   For CTF challenges that require reading files you don't have direct access to, world-readable flag files placed by the challenge infrastructure in paths like /challenge/ are common. Before trying privilege escalation, always enumerate what you can already read with find / -readable -name "*.json" 2>/dev/null or find / -readable -name "flag*" 2>/dev/null. Many CTF challenges are intentionally simpler than they appear - the flag is accessible to the given user without any escalation.

Flag

picoCTF{Sch3...44}

Even though cron is hinted, the flag is stored in a static JSON file.