Study guide
19.1 Scheduled Tasks, Services, Accounts, and Shells
CompTIA PenTest+ PT0-003
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current PT0-003 Exam Facts 1.2 Format, PBQs, Scoring, and Retake Policy 1.3 Recertification, CEUs, and Career Fit
2 Pre-Engagement Planning
2.1 Scope, Rules of Engagement, and Agreements 2.2 Target Selection and Assessment Types 2.3 Shared Responsibility, Legal Authorization, and Ethics
3 Collaboration, Frameworks, and Threat Modeling
3.1 Collaboration, Escalation, and Stakeholder Communication 3.2 Testing Frameworks and Methodologies 3.3 Threat Modeling: STRIDE, DREAD, and OCTAVE
4 Reporting and Remediation
4.1 Penetration Test Report Components 4.2 Findings Analysis and Remediation Recommendations
5 Information Gathering
5.1 Active vs Passive Reconnaissance 5.2 OSINT Sources and Techniques 5.3 DNS, Certificate Transparency, and Search Engine Enumeration 5.4 Network Recon, Protocol Scanning, Sniffing, and Banner Grabbing
6 Enumeration Techniques
6.1 OS Fingerprinting, Service Discovery, and Host Discovery 6.2 DNS, Directory, Share, and Account Enumeration 6.3 Secrets, Permissions, and Wireless Enumeration 6.4 WAF Enumeration, Web Crawling, and Attack Path Mapping
7 Recon Scripting and Tools
7.1 Modifying Bash, Python, and PowerShell for Recon 7.2 Recon and Enumeration Tools
8 Vulnerability Scan Types
8.1 Network, Host, Authenticated, and Wireless Scans 8.2 SAST, DAST, IAST, SCA, IaC, and Mobile Scans 8.3 Container, Secrets, and ICS Vulnerability Assessment 8.4 Core Vulnerability Scanners (Nessus, OpenVAS, Nikto)
9 Scan Analysis and Physical Security
9.1 Specialized Discovery Tools 9.2 Validating Scan, Recon, and Enumeration Results 9.3 Public Exploit Selection and Scripted Validation 9.4 Physical Security Concepts for PenTests
10 Attack Prioritization and Preparation
10.1 Target Prioritization: CVSS, CVE, CWE, and EPSS 10.2 Exploit Selection, Customization, and Attack Documentation
11 Network Attacks
11.1 On-Path, VLAN Hopping, Relay, and Multihomed Hosts 11.2 Default Credentials, Misconfigured Services, Packet Crafting, and Certificate Services
12 Authentication Attacks
12.1 Pass-the-Hash, Pass-the-Ticket, Pass-the-Token, and Kerberos Attacks 12.2 Password Attacks, MFA Fatigue, LDAP Injection, OIDC, and SAML
13 Host-Based Attacks
13.1 Privilege Escalation and Credential Dumping 13.2 Process Injection, Security Bypass, and Host Attack Tools
14 Web Application Attacks
14.1 SQL, Command, XSS, and SSTI Injection 14.2 CSRF, SSRF, Deserialization, IDOR, and Directory Traversal 14.3 LFI/RFI, Web Shells, API Abuse, JWT, and Session Hijacking
15 Cloud Attacks
15.1 IAM Misconfiguration, Metadata Service, and Exposed Storage 15.2 Container Escape, Supply Chain, and Cloud Attack Tools
16 Wireless and Social Engineering
16.1 Wireless Attacks and Tools 16.2 Phishing, Spearphishing, Whaling, Vishing, and Smishing 16.3 Physical Social Engineering and SE Tools
17 Specialized Systems
17.1 Mobile Attacks and AI Prompt/Model Attacks 17.2 OT/ICS, NFC, RFID, and Bluetooth Attacks
18 Attack Scripting and BAS
18.1 PowerShell, Python, and Bash Attack Automation 18.2 Breach and Attack Simulation (Caldera, Infection Monkey, Atomic Red Team)
19 Persistence
19.1 Scheduled Tasks, Services, Accounts, and Shells 19.2 C2, Backdoors, Rootkits, and Security-Control Tampering
20 Lateral Movement
20.1 Pivoting, Relays, and Additional Credential Capture 20.2 Remote Services: SMB, RDP, WinRM, WMI, SSH, and Others 20.3 Lateral Movement Tools and LOLbins
21 Exfiltration and Cleanup
21.1 Staging and Exfiltration 21.2 Cleanup, Restoration, and Artifact Preservation
19.1 Scheduled Tasks, Services, Accounts, and Shells
Key Takeaways Explain This Topic AI
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.
Last updated: August 2026
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 on
HKLM\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.