19.1 Scheduled Tasks, Services, Accounts, and Shells
Key Takeaways
- Domain 5 Post-exploitation and Lateral Movement is 14 percent of PT0-003; objective 5.1 establishes persistence after initial access, still inside the rules of engagement, and every artifact must be removable in 5.4.
- Reverse shell means the target connects out (the usual path through NAT and egress-only firewalls); bind shell means the target listens and the tester must reach inbound — reversing those definitions is the highest-yield 5.1 trap.
- Windows persistence on the exam is scheduled tasks, service creation, and Run/RunOnce registry keys; Linux is cron, systemd-style services, and authorized_keys on an existing account.
- Adding a new local or domain account is noisy; obtaining valid account credentials, or appending an SSH key to an existing user's authorized_keys, reuses a real identity and is quieter.
- A raw shell dies with its process. Persistence is the task, service, registry value, or account that relaunches access — and the engagement log is what makes 5.4 cleanup possible.
Domain 5, Post-exploitation and Lateral Movement, is 14 percent of CompTIA PenTest+ PT0-003. Objective 5.1 is Given a scenario, perform tasks to establish and maintain persistence. Persistence is remaining on a host after initial access so you can return when the first shell dies, the user logs off, or the box reboots. Domain 4 got you on the box. 5.1 is how you stay. 5.2 is how you move. 5.3 is how data leaves. 5.4 is how you take persistence back out. CompTIA is scoring identification — scheduled task versus service, reverse shell versus bind shell, new account versus stolen credential — not a malware cookbook. This guide will not give payload source, shell one-liners, or persistence installers.
Persistence is still inside the rules of engagement (RoE). A foothold on WS-042 at corp.example.com does not authorize a domain-wide scheduled task, a new Domain Admin, or a listener on a payment VLAN. If RoE forbids persistence, you document the opportunity and stop. If RoE allows it, you install only what you can name and reverse in 5.4. Every mechanism goes in the engagement log: host, account, trigger, artifact path, and how to remove it. Exam trap: treating persistence as set-and-forget. The exam still wants cleanup. Trap two: treating 5.1 as 4.4 privilege escalation. Writable cron that escalates is 4.4. Cron that survives reboot as you is 5.1.
Scheduled tasks and cron jobs
Scheduled tasks (Windows Task Scheduler) and cron jobs (Linux) run a program later: at logon, at startup, on a timer, or when the machine is idle. The point is execution without an interactive session.
On Windows, the picture is a task that starts a callback as a named user or as SYSTEM when the host boots or when j.smith logs on. Triggers you should recognize: at startup, at logon, on a schedule, on an event. The task lives in the Task Scheduler library; defenders look there and in the Microsoft-Windows-TaskScheduler/Operational log. When you pick it: the stem wants something that comes back after reboot or logoff on Windows and does not need a new service. When you do not: you need a long-running privileged process with a service control manager (SCM) identity — that is service creation. Exam trap: calling every Windows persistence a scheduled task. Run keys, services, and new accounts are different 5.1 bullets.
On Linux, cron is the analog: a user crontab, /etc/crontab, /etc/cron.d/, or /etc/cron.hourly/ (and daily, weekly, monthly). A line that runs every five minutes as root or as www-data is persistence if the tester put it there to keep a callback. systemd timers sit in the same family on modern hosts — a unit that wakes on a calendar event — but CompTIA's named bullet is cron. When you pick cron: Linux, periodic or reboot-adjacent execution, no new daemon. Exam trap: answering 4.4 writable-cron privilege escalation when the stem already has root and only wants to remain. 4.4 abused someone else's cron. 5.1 creates the tester's own job.
Service creation
Service creation installs a program the operating system starts and restarts as a service, often at boot, often as SYSTEM (Windows) or root (Linux systemd). A service is more always-on than a five-minute cron: the SCM or systemd keeps the process up.
Windows: a new service with an auto-start type, a binary path, and an account such as LocalSystem or a service account. Linux: a systemd unit under /etc/systemd/system/ wanted by the multi-user target. When you pick it: the stem wants boot-time, always-running persistence with a service name, not a user logon Run key. When you do not: a one-shot at next logon (scheduled task or Run key), or a web-facing command page (that is a web shell in 19.2). Exam trap: treating service and scheduled task as synonyms. Tasks fire on a trigger. Services are processes the OS supervises.
Services are noisy if the name is updater in a shop that inventories services, and they are privileged if they run as SYSTEM. RoE that allows a user-level scheduled task may still forbid a new SYSTEM service. Record the service name for 5.4.
Reverse shell versus bind shell
This pair is the highest-yield 5.1 trap.
A reverse shell makes the target connect out to a listener the tester controls. The compromised host is the TCP or HTTPS client. Egress to the internet, or to the tester's jump host, is often allowed; inbound to the workstation is not. Reverse shells therefore survive network address translation (NAT) and typical host firewalls that allow outbound 443 or 80 and drop inbound.
A bind shell makes the target listen. The tester connects in. That needs a reachable inbound path: no NAT hide, a firewall hole, or a port forward. Bind shells fail on most RFC1918 workstations for that reason.
When you pick reverse: the stem mentions NAT, egress-only, callback, or a firewalled host that cannot be reached inbound. When you pick bind: the tester can already reach a listening port on the target (lab VLAN, exposed server, or an inbound hole the client opened). Exam trap: reversing the definitions. Reverse is not the tester listens on the target. Reverse is the target calls home. Trap two: treating either shell as persistence by itself. A raw reverse shell dies when the process dies. Persistence is the scheduled task, service, Run key, or account that relaunches the shell. Do not memorize payload syntax. PT0-003 wants the direction of the connection.
Add new accounts versus obtain valid credentials
Adding a new account creates an identity that did not exist: a local user in the Administrators group, a domain user, a local Linux account with a home directory, or an extra sudoer. New accounts are noisy. Security information and event management (SIEM) products watch Event ID 4720 (user created), 4732 (added to a privileged group), and the Linux equivalents (useradd in auth logs). Help desk also notices mystery users. When you pick it: RoE allows a clearly named test account that 5.4 will delete, and you need a login that does not depend on the original foothold password changing. When you do not: stealth is required, or the stem already has a valid employee hash.
Obtaining valid account credentials is using an existing identity: a password, hash, ticket, SSH key, or API token that already belongs to j.smith or a service account. The login looks like a real user. It is usually quieter than pentest_tmp. It also dies if the real account is disabled. Linux authorized_keys is the SSH-key cousin: you append a tester public key to an existing user's ~/.ssh/authorized_keys so SSH works after the shell is gone, without useradd. That is extra access on a real account, not a new account.
Exam trap: always create a new admin because it is cleaner. Cleaner for you in 5.4 maybe; louder for the SOC. Trap two: calling authorized_keys a Windows Run key. It is Linux SSH persistence on an existing account.
Registry keys (Windows)
Registry keys that auto-start programs are Windows-only persistence. CompTIA expects the Run and RunOnce family:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run— starts when that user logs onHKLM\Software\Microsoft\Windows\CurrentVersion\Run— starts when any user logs on (needs higher privilege to write)- RunOnce variants — fire once and then remove themselves; weaker persistence, useful for a single callback after reboot
Related autostart locations (Winlogon Userinit, services registry keys) sit in the same Windows-starts-this-for-me bucket. When you pick registry keys: Windows, logon-time execution, no Task Scheduler library entry. When you do not: Linux (use cron, systemd, or authorized_keys), or a boot-time SYSTEM daemon you registered with the SCM (service creation). Exam trap: RunOnce as durable persistence. Once is the word. Trap two: calling a registry Run key a scheduled task.
Document it or you cannot clean it
5.1 without a log is a 5.4 failure. Write host, OS, mechanism, path or task name, account, and the removal step you will use later. example.com's WS-042 might get a logon scheduled task as j.smith, not a new Domain Admin. A Linux intranet box might get a user crontab and an authorized_keys line, not a systemd unit as root, if RoE forbade service creation. The report later tells the client what a real attacker could have left; the engagement log tells you what to delete.
| Mechanism | Typical OS | Survives | Pick when | Exam trap |
|---|---|---|---|---|
| Scheduled task / cron | Windows Task Scheduler; Linux crontab | Reboot or logoff on a trigger | Periodic or logon/startup callback without a service | Calling 4.4 writable-cron priv-esc the same bullet |
| Service creation | Windows SCM; Linux systemd | Boot; process restart | Always-on daemon, often SYSTEM/root | Equating services with Run keys |
| Reverse shell | Either | Only while the process lives | Target must call out through NAT or firewall | Reversing bind vs reverse |
| Bind shell | Either | Only while the listener lives | Tester can connect inbound | Assuming bind works through NAT |
| New account | Either (local or domain) | Until deleted | Named test identity for 5.4 | Thinking new accounts are stealthy |
| Valid credentials / authorized_keys | Either; SSH keys on Linux | Until the real account dies | Quieter reuse of an existing identity | Calling a new admin credential reuse |
| Registry Run / RunOnce | Windows | Logon (RunOnce: once) | Logon autostart without Task Scheduler | RunOnce as permanent; registry on Linux |
Sequence on the exam: you already have access; name the OS; pick the mechanism that matches the trigger (logon, boot, timer, inbound, outbound); prefer valid credentials over noisy new accounts when stealth is the stem; write it down for 5.4.
A compromised Windows workstation sits behind NAT. The host firewall allows outbound 443 and drops inbound. The tester needs a shell. Which 5.1 statement is exam-correct?
After a foothold, the tester wants a durable login. The SOC watches new-user events. Which 5.1 account choice matches CompTIA's contrast between adding accounts and obtaining credentials?
A Windows host must relaunch a callback at every logon without a new SCM service. The Linux analogue is a user crontab, not a new daemon. Which 5.1 match is exam-correct?