PT0-002 Attacks and Exploits Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Installing an SSH authorized_key for the attacker

  Why this is correct

  Installing an SSH authorized_key for the attacker is a Linux persistence technique that involves appending the attacker's public key to the target user's ~/.ssh/authorized_keys file. This permits the attacker to authenticate over SSH without a password, even after system reboots. It is stealthy because it requires no new process or scheduled task, blending in with normal user configuration files, and remains effective indefinitely unless explicitly removed.

• ✓

  Adding a cron job that executes a reverse shell

  Why this is correct

  Adding a cron job that executes a reverse shell is a persistence method that relies on the Linux cron daemon to run the attacker's command at predefined intervals (e.g., every minute). A crontab entry or a script in /etc/cron.d/ can re-establish a reverse shell connection each time the job runs, ensuring the attacker retains access. However, this method is time-dependent and can be detected by auditing scheduled tasks, as the commands or scripts often reside in plain view.

• ✗

  Using schtasks to create a scheduled task

  Why it's wrong here

  Using schtasks to create a scheduled task is incorrect because schtasks is a Windows command-line utility for managing scheduled tasks within the Windows Task Scheduler. The compromised system is Linux, so this tool does not exist and would simply fail to execute. On Linux, equivalent persistence via scheduled execution is achieved with cron, not with schtasks.

• ✗

  Modifying the Windows Registry Run key

  Why it's wrong here

  Modifying the Windows Registry Run key is a Windows-specific persistence mechanism that sets programs to launch automatically at user login through registry entries like HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. Since the target is a Linux host, there is no Registry, and this technique is entirely inapplicable. Linux auto-start persistence would instead be achieved via systemd services, init scripts, or XDG autostart entries.

• ✓

  Creating a systemd service that runs on boot

  Why this is correct

  Creating a systemd service that runs on boot is a robust Linux persistence technique where the attacker writes a unit file (e.g., /etc/systemd/system/backdoor.service) that executes a reverse shell or other payload. Using 'systemctl enable' links the service to start automatically at boot, and it can be configured with Restart=always to keep the process alive even if killed. This method is difficult to detect if the service is given a name that mimics a legitimate system service.

Go deeper

Related to this question