DEV Community

Cover image for Network Persistence 2026 — Scheduled Tasks, Registry Persistence & Service Backdoors | Hacking Course Day37
Mr Elite
Mr Elite

Posted on • Originally published at securityelites.com

Network Persistence 2026 — Scheduled Tasks, Registry Persistence & Service Backdoors | Hacking Course Day37

📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.

Network Persistence 2026 — Scheduled Tasks, Registry Persistence & Service Backdoors | Hacking Course Day37

🛡️ ETHICAL HACKING COURSE

FREE

Part of the 100-Day Free Ethical Hacking Course

Day 37 of 100 · 37% complete

⚠️ 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

⏱️ 45 min read · 3 labs · Day 37 of 100 #### ✅ Before You Start - Day 36: Pivoting & Tunneling — complete this first. The tools and concepts from that session are assumed here. - Windows 10/11 VM with admin access for persistence labs. Sysinternals Autoruns downloaded. Kali Linux for Linux persistence labs. ### 📋 Day 37 — Network Persistence 1. Why Persistence Matters in Red Team Operations 2. Windows Scheduled Task Persistence 3. Registry Run Key Persistence 4. Windows Service Backdoors 5. Linux Persistence — Cron, Systemd, and RC 6. Detection — Finding and Removing Persistence 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.

PERSISTENCE MATRIX — WINDOWS MECHANISMS OVERVIEWCopy

Persistence mechanisms by privilege and trigger

MECHANISM PRIVILEGE TRIGGER DETECTABILITY
──────────────────────────────────────────────────────────────
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?


📖 Read the complete guide on SecurityElites

This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →


This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.

Top comments (0)