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

This article from Day 37 of a 100-day ethical hacking course teaches Windows and Linux persistence mechanisms—techniques that maintain post-exploitation access across reboots and session interruptions. It covers scheduled tasks, registry Run keys, Windows services, cron jobs, and systemd services, emphasizing that persistence is a critical red team capability and equally important for incident responders hunting compromise. The material is authorised-engagement-only, with labs demonstrating both establishment and detection using tools like Autoruns.

• Persistence as engagement differentiatorThe article argues that persistence transforms a temporary shell into a sustainable foothold. Without persistence, every reboot or session interruption loses access that may have taken days to establish; with persistence, compromised hosts automatically reconnect to command-and-control infrastructure. The author notes from real experience that maintaining a 3-week foothold versus losing access on day one depends entirely on persistence mechanisms being established before conducting other post-exploitation actions.
• Privilege-trigger-detectability strategy matrixThe article presents persistence as a tradeoff across three dimensions: privilege level (user vs SYSTEM vs service account), trigger mechanism (boot, logon, schedule, event), and detectability. High-privilege SYSTEM-level persistence is powerful but generates detectable Windows Event Log entries (4698 for scheduled tasks, 7045 for services). The optimal red team approach establishes both SYSTEM-level for capability and user-level as a backup that survives password changes—the backup is what saves the engagement when the primary gets cleaned.
• Windows scheduled task persistence mechanismsScheduled tasks offer fine-grained control via triggers: boot startup, logon, specific times, or system events. User-level tasks require only user privileges; boot and SYSTEM-level tasks require Administrator. The article shows three command examples: user-triggered at logon, SYSTEM-level at startup, and recurring every 5 minutes. Detection occurs via Event ID 4698 (task created) and 4702 (task updated), plus manual enumeration with Get-ScheduledTask. PowerShell methods use New-ScheduledTaskAction and Register-ScheduledTask, which are harder to detect by task name alone.
• Registry Run key persistence implementationRun keys in HKCU and HKLM registry hives execute configured payloads at user logon. HKCU requires only user privileges; HKLM requires Administrator. The article demonstrates syntax using both `reg add` commands and PowerShell's Set-ItemProperty. RunOnce variant executes once then deletes itself. Detection relies on registry auditing (if enabled) and tools like Autoruns. User-level HKCU registry keys are described as lower-signal and frequently preferred for stealth against mature SOCs because they don't generate admin-level event log entries.
• Windows service backdoors and restart behaviorServices run as SYSTEM by default, operate without requiring a user session, survive reboots automatically, and can be configured to restart on failure using `sc.exe failure` commands with reset intervals. Service creation requires Administrator and generates Event ID 7045 in System event logs. The article shows `sc.exe create` syntax with `start= auto` for automatic startup and describes configuring recovery actions (restart/60000 repeated). Services are the most privileged persistence mechanism but also the most detectable on properly configured SIEMs.
• Linux persistence across cron and systemdLinux persistence uses three primary mechanisms depending on privilege: user crontab (runs as current user, survives reboots), /etc/crontab or /etc/cron.d/ (requires root), and systemd service units (Linux equivalent of Windows service backdoors). The article shows user crontab syntax with pipe-to-crontab installation, system crontab drop-in files, and systemd .service file creation. SSH authorized_keys persistence is mentioned as an alternative that persists across reboots. Detection involves checking crontab -l, /etc/cron.d/, systemctl list-units, and finding unauthorized SSH keys.
• Autoruns as unified persistence enumeration toolAutoruns (Sysinternals) enumerates every Windows auto-start location: registry Run keys, scheduled tasks, services, browser extensions, boot execute entries, known DLL hijacking paths, WMI event subscriptions, and startup folders. It colour-codes unsigned binaries in yellow, integrates VirusTotal lookups, and supports baseline comparison. The article identifies Autoruns as the single most comprehensive Windows persistence detection tool, used in both red team and incident response contexts. A baseline before and after suspected compromise reveals exactly what persistence was added.
• Detection-aware strategy thinking before deploymentThe article emphasizes that selecting a persistence mechanism without considering detection context gets engagements caught unnecessarily. Exercise 1 presents a scenario against a mature SOC with Splunk, CrowdStrike EDR, and security monitoring, asking whether to use SYSTEM-level service (high detection), scheduled task (high detection), HKCU registry (lower signal), or WMI subscription (widely missed). The article argues WMI subscriptions and LOLBins-based approaches minimize EDR detection risk, and timing execution during business hours provides noise cover versus executing during quiet peri

Bottom line: Persistence is not optional post-exploitation—it determines whether a red team engagement maintains access across reboots or loses the foothold on day one; the same knowledge that enables effective red team persistence is essential for incident responders hunting compromise, making dual-use understanding of both establishment and detection techniques critical to both roles. Establish multiple independent persistence mechanisms using different privileges and triggers before conducting other post-