⚠️ Authorised Engagements Only. Persistence mechanisms must only be deployed in authorised penetration testing or red team engagements with explicit written scope. Establishing persistence on systems without authorisation constitutes unauthorised computer access under most jurisdictions’ computer crime laws. All labs in this course use isolated local virtual machines.
Getting initial access is the exciting part. What happens next determines whether an engagement is successful or just a one-time foothold that disappears the moment the session drops. Persistence is the unglamorous but critical post-exploitation phase: I need to ensure access survives reboots, logoffs, and the inevitable loss of a shell when a session times out. In real red team engagements, I establish at least two independent persistence mechanisms before doing anything else on a compromised host — because I’ve lost access to critical targets mid-engagement more times than I can count. Today I’m covering the core Windows and Linux persistence techniques, how each one works under the hood, how defenders detect them, and why understanding detection is as important as understanding the technique itself. This is the dual-use nature of ethical hacking: the persistence knowledge that makes me effective on an authorised red team is the same knowledge that makes me better at hunting for persistence during incident response.
🎯 After Day 37
Establish Windows scheduled task persistence at boot and on schedule triggers
Add registry Run key persistence at both user and system levels
Install a persistent Windows service and configure restart behaviour
Set up Linux persistence via cron jobs and systemd service units
Enumerate and detect all persistence mechanisms using Autoruns and manual audit techniques
On Day 36 I covered pivoting and tunnelling — maintaining network connectivity through compromised hosts. Today I’m addressing what happens when that connectivity drops: persistence mechanisms that re-establish access after system reboots or session terminations. These aren’t optional post-exploitation steps — on a red team engagement, persistence is the difference between maintaining a 3-week foothold and losing access on day one.
Why Persistence Matters in Red Team Operations
A reverse shell gives me a session. Persistence gives me a foothold that survives beyond the current session. The distinction matters enormously: without persistence, every reboot, logoff, or network interruption loses the access it took potentially days to establish. With persistence, the compromised host reconnects to my command-and-control infrastructure automatically.
My persistence strategy on a real engagement considers three dimensions: privilege level (user vs SYSTEM vs service account), trigger (boot, logon, schedule, event), and detectability. High-privilege SYSTEM-level persistence is powerful but generates more detectable events. User-level persistence is more stealthy but limited in capability. I establish both: SYSTEM-level for capability, user-level as a backup that survives password changes. The backup is the one that saves the engagement when the primary gets cleaned.
Scheduled Task (SYSTEM) Admin req Boot/sched High (Evt 4698)
Scheduled Task (user) User Logon/sched Medium
Registry HKLM Run key Admin req User logon High (reg audit)
Registry HKCU Run key User User logon Medium
Windows Service Admin req Boot High (Evt 7045)
Startup Folder (user) User User logon Low
WMI Event Sub Admin req Event-based Low-Medium
DLL Hijack Varies App launch Low
🧠 EXERCISE 1 — THINK LIKE A HACKER (20 MIN · ANALYSIS)
Select the Optimal Persistence Strategy for a Scenario
⏱️ 20 minutes · No tools required
Before setting up persistence mechanically, I want you to think through the strategy decisions that shape which mechanism to use. A persistence mechanism chosen without considering detection and operational context gets the engagement caught unnecessarily.
SCENARIO: You’ve compromised a Windows 10 workstation used by a finance
department employee at a financial services firm. You have local admin
privileges. The firm runs a mature SOC with Splunk SIEM, CrowdStrike EDR,
and a security team that reviews Autoruns alerts.
OBJECTIVE: Maintain access for 3 weeks while conducting an authorised
red team engagement simulating a nation-state APT.
QUESTION 1 — Primary Persistence
What is your primary persistence mechanism and why?
Consider: privilege needed, trigger needed, how long before detection?
a) Windows service running as SYSTEM
b) Scheduled task as SYSTEM on boot
c) Registry HKCU Run key as current user
d) WMI event subscription
QUESTION 2 — Backup Persistence
What backup mechanism would you establish?
It should use a different trigger and method than your primary.
Which mechanism would the SOC be least likely to detect?
QUESTION 3 — Persistence Payload
What would you use as the payload?
a) Meterpreter reverse shell executable on disk
b) PowerShell one-liner in registry (fileless)
c) Legitimate LOLBins (living off the land) with malicious arguments
Which minimises the EDR detection risk?
QUESTION 4 — Operational Security
What time would you execute the persistence installation?
a) 9 AM — during normal business hours, lots of activity noise
b) 11 PM — after hours, quiet period on endpoints
c) Immediately after gaining initial access, regardless of time
What difference does timing make for SIEM alert triage?
QUESTION 5 — Recovery
If your primary persistence is discovered and cleaned on day 5,
how does your backup ensure you maintain the engagement?
What’s your procedure for re-establishing the primary?
✅ The optimal answer to Question 1 depends on the engagement’s stealth requirements. For a long-term APT simulation against a mature SOC, the HKCU registry Run key is often the right primary — it requires only user privileges (no admin event generation), triggers on logon, and is lower-signal than service installation. The WMI event subscription (Question 2) is the best backup: it’s widely missed by basic monitoring and triggers on system events rather than time. The LOLBins approach (Question 3) minimises EDR detection by using signed Microsoft binaries. This strategic thinking applied before touching any persistence command is what separates methodical red teamers from noisy ones.
📸 Write your complete persistence strategy decision and share in #ethical-hacking.
Windows Scheduled Task Persistence
Windows Task Scheduler is one of the most powerful and commonly used persistence mechanisms because it provides fine-grained control over triggers (boot, logon, specific times, system events) and runs with configurable privilege levels. Creating a scheduled task requires either user-level access (for user-triggered tasks) or Administrator (for boot-trigger and SYSTEM-level tasks).
WMI Subscriptions Get-WMIObject __EventFilter -Namespace root/subscription Often missed
📸 Windows persistence locations with detection signal strength. Scheduled tasks and services generate Windows Event Log entries that well-configured SIEMs alert on (high detection signal = red). Registry Run key detection depends on registry auditing being enabled. Startup folder additions and WMI subscriptions are frequently missed by organisations without comprehensive EDR coverage (low detection = green for the attacker). Autoruns enumerates all of these locations in one tool.
Registry Run Key Persistence
Registry Run keys are one of the oldest and most commonly used Windows persistence mechanisms because they’re simple to set up and don’t require creating files in obvious locations. HKCU Run keys require only user privileges; HKLM keys require Administrator. Both execute their configured payload every time a user logs on.
# Autoruns shows all Run key entries with VirusTotal check
Windows Service Backdoors
Windows services are the most privileged persistence mechanism — by default they run as SYSTEM, operate without a user session, survive reboots, and can be configured to restart automatically on failure. The privilege and persistence combination makes services the preferred mechanism for long-term access on a compromised server. The cost: service creation requires Administrator privileges and generates Event ID 7045 in the System event log.
WINDOWS SERVICE BACKDOOR — INSTALLATION & DETECTION
# Create a service (requires admin)
sc.exe create “WindowsUpdateManager” binPath= “C:\Windows\Tasks\update.exe” start= auto
sc.exe description “WindowsUpdateManager” “Manages Windows Update scheduling”
Get-Service | Where-Object {$_.StartType -eq “Automatic”} | Sort-Object Name
sc.exe query type= all state= all
Linux Persistence — Cron, Systemd, and RC
Linux persistence mechanisms parallel Windows in concept but differ in implementation. I use three primary approaches depending on the privilege level achieved: user crontab for user-level persistence, /etc/crontab or /etc/cron.d/ for system-level (root required), and systemd service units for the Linux equivalent of a Windows service backdoor.
LINUX PERSISTENCE MECHANISMS
# User crontab — runs as current user, survives reboots
⚙️ EXERCISE 2 — SETUP LAB (25 MIN · WINDOWS VM REQUIRED)
Establish and Detect All Three Persistence Mechanisms on a Windows VM
⏱️ 25 minutes · Windows VM (local lab only — never on systems you don’t own)
This lab establishes all three primary Windows persistence mechanisms in sequence and then hunts them using Autoruns. The objective is to see what each mechanism looks like both from the attacker side (creating it) and the defender side (finding it).
PREREQUISITE: Windows 10/11 VM (local lab) with admin access
Download Autoruns: download.sysinternals.com/files/Autoruns.zip
SETUP: Create a dummy executable to use as the payload
echo @echo off > C:\Windows\Tasks\svc.exe
Note: In a real lab, this would be a Meterpreter payload
PERSISTENCE 3 — Windows Service:
sc.exe create “TestPersistSvc” binPath= “C:\Windows\Tasks\svc.exe” start= auto
Verify: sc.exe query TestPersistSvc
Check Event Viewer: Windows Logs → System → Filter by Event ID 7045
DETECTION — Run Autoruns:
Run Autoruns.exe as Administrator
Screenshot: Logon tab (shows Run keys and scheduled tasks)
Screenshot: Services tab (shows new TestPersistSvc)
Notice: How does Autoruns highlight non-Microsoft entries?
✅ The Autoruns enumeration at the end is the most instructive part. When you run it after creating all three persistence mechanisms, you see exactly what a defender sees when hunting for compromise on a Windows system. Notice that Autoruns colour-codes non-Microsoft binaries in yellow — that’s the first filter defenders use. The Event Log checks confirm the detection telemetry each mechanism generates: 4698 for scheduled task, 7045 for service. Understanding this detection side shapes how you’d approach stealth on a real engagement.
📸 Screenshot your Autoruns Logon tab showing all three persistence entries. Share in #ethical-hacking.
Detection — Finding and Removing Persistence
Persistence detection is the incident responder’s side of this knowledge. When I’m brought in for an IR engagement, my first task is enumerating all persistence mechanisms on compromised systems. My toolkit for this is Autoruns (Windows) and a manual checklist of Linux persistence locations.
PERSISTENCE HUNTING — DETECTION COMMANDS
# Windows: Autoruns (most comprehensive)
autorunsc.exe -a * -s -nobanner -csv > autoruns-output.csv
⚡ EXERCISE 3 — KALI TERMINALLAB ADVANCED (20 MIN · LINUX VM)
Establish and Hunt Linux Persistence on a Practice VM
⏱️ 20 minutes · Linux VM (Kali or Ubuntu) — local lab only
This lab establishes all four Linux persistence mechanisms in sequence, then conducts a full persistence hunt using the detection commands. The goal is to build the muscle memory for both sides: establishing persistence as a red teamer and finding it as an incident responder.
✅ Running both the establishment and the hunt in the same exercise builds the dual-use understanding that makes you effective as both a red teamer and an incident responder. When you run the hunt phase and see all four persistence mechanisms appear in the output, you understand what a compromised Linux system looks like from the defender’s perspective. The cleanup phase is operationally important — on a real engagement, unplanned persistence left after the engagement window is a serious finding against the red team and potentially a legal issue.
📸 Screenshot your hunt phase output showing all 4 persistence entries. Share in #ethical-hacking. Tag #Day37
Scheduled tasks, registry Run keys, Windows services, Linux cron and systemd persistence, and the full detection methodology using Autoruns and manual hunt commands. The dual-use framing — establishing persistence as a red teamer, detecting it as an incident responder — is the core of how I approach every post-exploitation technique. Day 38 digs deeper into registry persistence specifically, covering COM hijacking, Boot Execute entries, and the less-monitored registry locations that avoid basic Autoruns detection.
🧠 Quick Check
During an incident response engagement, you’re tasked with finding all persistence mechanisms on a compromised Windows 10 workstation. Which single tool gives you the most comprehensive enumeration of Windows persistence locations?
Persistence mechanisms ensure continued access to a compromised system across reboots, logoffs, or session interruptions. Common Windows methods: scheduled tasks, registry Run keys, services, startup folders, WMI event subscriptions. Linux: cron jobs, systemd services, SSH authorised keys, rc.local. Understanding persistence is essential for both red team simulation and incident response forensics.
What is the difference between user-level and system-level persistence?
User-level (HKCU registry, user crontab, startup folder in user profile) runs with user privileges at logon — lower privilege but no admin events generated, harder to detect without user-level monitoring. System-level (HKLM registry, Windows service, system cron, /etc/rc.local) runs at boot with elevated privileges — more powerful but requires admin to establish and generates higher-signal detection events.
What Windows Event IDs indicate persistence was established?
4698 — scheduled task created; 4702 — scheduled task updated; 7045 — new service installed (System event log); 4657 — registry value modified (if registry auditing enabled); 4688 — process creation showing schtasks.exe, sc.exe, or reg.exe with suspicious arguments. These are the primary events SIEMs monitor for persistence detection.
How does Autoruns help detect persistence?
Autoruns enumerates every Windows auto-start location — registry Run keys, scheduled tasks, services, browser extensions, boot execute entries, known DLL paths, and more. It colour-codes unsigned binaries and allows VirusTotal integration and baseline comparison. Running Autoruns before and after suspected compromise shows exactly what persistence was added.
Is persistence allowed in bug bounty programs?
No — establishing persistence mechanisms is almost universally out of scope in bug bounty programs. Bug bounty covers vulnerability discovery, not post-exploitation. Persistence techniques belong in authorised red team engagements with explicit written scope. Document the vulnerability that would enable persistence without actually deploying it.
What is the most detectable persistence mechanism?
Windows service installation (Event ID 7045) and scheduled task creation (Event ID 4698) are highly detectable on properly configured SIEMs. WMI event subscriptions and DLL hijacking are least detectable by basic monitoring. For red team engagements against mature SOCs, user-level HKCU registry persistence and WMI subscriptions generate the least detection telemetry.
← Previous
Day 36: Pivoting & Tunneling 2026
Next →
Day 38: Registry Persistence — COM Hijacking & Boot Execute
📚 Further Reading
Day 36 — Pivoting & Tunneling 2026— The network connectivity phase that precedes persistence. Pivot channels through compromised hosts enable C2 communications that persistence mechanisms maintain across reboots.
Day 38 — Registry Persistence Advanced— Day 38 covers the advanced registry persistence locations: COM hijacking, Boot Execute, AppInit DLLs, and Image File Execution Options — the less-monitored mechanisms that evade basic Autoruns detection.
Privilege Escalation Hub— Privilege escalation techniques that provide the elevated access needed for system-level persistence mechanisms — services, HKLM registry, system cron — that user-level access cannot establish.
MITRE ATT&CK — Persistence Tactic— The authoritative reference for persistence techniques used by real threat actors. Every technique covered in this series has a corresponding MITRE ATT&CK ID used by defenders for detection rule mapping and threat intelligence correlation.
Microsoft Sysinternals — Autoruns— The official download and documentation for Autoruns, the most comprehensive Windows persistence enumeration tool. Essential reading for both red teamers establishing persistence and defenders hunting it.
ME
Mr Elite
Owner, SecurityElites.com
My first red team engagement where I deployed persistence across an Active Directory environment taught me two things. First: establish multiple independent persistence mechanisms across multiple systems before doing anything noisy. Second: the cleanup procedure is as important as the establishment procedure. I left a scheduled task running on a server after the engagement ended — the client’s IR team found it three weeks later during an unrelated audit and called the engagement back in to explain it. Now my engagement procedure includes a mandatory cleanup verification step: I rerun Autoruns on every system I touched and compare against my establishment notes. Leaving persistence unaccounted for in a report damages trust and, in some jurisdictions, constitutes a legal problem. The technical skill is the easy part. The operational discipline is what makes an ethical hacker trustworthy.
