Scheduled Tasks & Cron Jobs 2026 — Creating Persistent Backdoors via Task Schedulers | Hacking Course Day 39

This article teaches offensive and defensive techniques for scheduled task and cron job persistence across Windows and Linux systems. It demonstrates how attackers establish backdoors that survive incident response cleanup by disguising malicious tasks as legitimate system maintenance, and explains the detection methods blue teams must use to find them. The article matters because scheduled task persistence is reportedly the most common persistence technique encountered in real incident response engagements where initial cleanup failed.

• Evasive naming using legitimate Windows pathsAttackers place malicious scheduled tasks in real Windows directories like MicrosoftWindowsMaintenance rather than creating new suspicious folders. By naming a task to match existing legitimate tasks (e.g., WinSAT under Maintenance), automated detection tools that exclude Microsoft paths entirely will miss the malicious task. The article demonstrates this with a task running encoded PowerShell daily at 3AM under a legitimate Windows path that blends with System Assessment Tool tasks.
• Trigger selection affects detection evasionThe article ranks persistence triggers by detectability: ONLOGON is noisy and flagged immediately by security tools; ONSTART runs before security tools initialize and is harder to detect; DAILY at 3AM is best for evasion because it occurs during a low-activity maintenance window. Event-based triggers using specific Event IDs are described as advanced and hardest to spot because they don't appear in simple task listings.
• Event ID 4698 as the primary detection signalWhen audit logging is enabled, Windows generates Event ID 4698 whenever a scheduled task is created, recording the full task XML including the exact command being executed. The article emphasizes that evasive task naming provides no protection against this event log detection—defenders monitoring 4698 can see both the task creation and its full command regardless of whether the task path appears legitimate.
• Dual-persistence chains survive single cleanup passesThe article opens with a real scenario where defenders found and deleted an obvious decoy scheduled task, then declared the system clean. The attacker's actual persistence—a second task registered under a legitimate Windows maintenance process name running obfuscated PowerShell nightly—survived because it wasn't discovered. This demonstrates why attackers layer multiple persistence mechanisms in the same namespace.
• Autoruns signature verification exposes masked tasksEven with evasive naming under Microsoft paths, Autoruns with signature verification enabled will surface malicious tasks because it compares each task's actual executable against Microsoft's signed binary list. A task under MicrosoftWindowsMaintenance running unsigned or unexpected executables (like powershell.exe with -EncodedCommand) appears unsigned in Autoruns, creating a detection signal despite the legitimate-sounding path.
• Linux cron persists across multiple unmonitored locationsLinux cron persistence can be placed in six different locations: user crontab files, /etc/crontab, /etc/cron.d/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/. Incomplete cleanup missing even one location allows persistence to survive. The article provides the command find /etc/cron* -newer /etc/passwd to detect recently modified cron files by comparing against /etc/passwd as a known baseline.
• Fileless PowerShell payload execution avoids file-based detectionThe article advocates using IEX combined with DownloadString to download and execute payloads entirely in memory rather than writing .ps1 files to disk. This technique prevents file-based indicators of compromise from appearing in forensic analysis. The payload is encoded in Base64 within the scheduled task command itself, avoiding the need for separate malicious script files.
• Cleanup order and verification matter in engagement disclosureWhen removing persistence after an authorized engagement, the order of deletion and the verification steps taken affect whether traces remain. The article stresses that investigators must verify persistence removal using the same detection commands used to find it—running all enumeration commands after cleanup to confirm no artifacts remain—rather than assuming deletion was successful.

Bottom line: Scheduled task persistence succeeds primarily through evasion via legitimate naming conventions and trigger selection, but detection always surfaces malicious tasks if defenders monitor Event ID 4698, verify executable signatures in Autoruns, or check for encoded PowerShell in task commands—defenders must implement these checks specifically rather than relying on path-based exclusion lists. Attackers layer multiple persistence mechanisms in the same namespace because basic cleanup checklists mis