GPEN Domain Escalation and Persistence Practice Question
During a penetration test on a Linux system, you have gained root access and want to ensure that your backdoor survives system reboots. Which of the following methods is the most reliable and commonly used for this purpose?
⚠ Common exam trap
The trap here is assuming that legacy methods like rc.local or cron @reboot are universally reliable, when in fact systemd is the standard on most current Linux systems and provides more consistent startup execution.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create a systemd service unit that runs your payload at startup.
Creating a systemd service unit is the most reliable method for ensuring a backdoor runs at system startup on modern Linux distributions. Systemd is the standard init system, and service units are executed automatically during boot. This method is persistent, can run with root privileges, and is less likely to be disabled by default than legacy mechanisms like rc.local or cron @reboot.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a systemd service unit that runs your payload at startup.
Why this is correct
Systemd is the default init system on most modern Linux distributions, and creating a service unit ensures your payload runs at system startup. It is reliable, persistent across reboots, and can be configured to run as root. This method is commonly used by attackers and is less likely to be removed accidentally. It provides a robust backdoor that starts early in the boot process.
- ✗
Add your payload to the /etc/rc.local file.
Why it's wrong here
The /etc/rc.local file is a legacy method that is not present or enabled by default on many modern systemd-based distributions. It may require manual creation and executable permissions, and it runs late in the boot process. Its absence on many systems makes it unreliable for persistence. It also may be overwritten by system updates or configuration management tools.
- ✗
Add a cron job with @reboot schedule that executes your payload.
Why it's wrong here
A cron job with @reboot is a valid persistence method, but it depends on the cron daemon being installed and running. Some minimal Linux systems may not have cron installed, and the @reboot directive may not be supported in all cron implementations. It also runs as the user who owns the crontab, which may not be root if not configured properly. This makes it less reliable than other methods.
- ✗
Modify the root user's .bash_profile to execute your payload on login.
Why it's wrong here
Modifying .bash_profile only executes the payload when the root user logs in interactively, not at system boot. It does not survive reboots unless the root user logs in, which may not happen automatically. This method is unreliable for ensuring persistence after a reboot, as it depends on user interaction. It also only affects interactive login shells, not system services.
About these practice questions
One of 298 original GPEN practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GPEN practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GPEN exam.