Join our Newsletter — 33% off our NHI Course

When is Scheduled Job Creation logged?

Scheduled Job Creation is logged when a scheduled task or job is created, modified, or registered on a system. Attackers use scheduled jobs for persistence and repeat execution, so defenders should watch for new jobs from unusual users or processes. Audit the creation source, run frequency, command line, and account used to execute the job.

When Scheduled Job Creation Gets Logged

scheduled job creation is typically logged at the moment a task, cron entry, scheduled script, or job object is created, registered, or materially changed. The important signal is not just the first creation event, but any event that establishes or alters an execution path that will run later without a human present.

On most systems, logging also captures related state changes such as edits to the command, schedule, run-as account, or trigger. That matters because attackers often use scheduled jobs to persist, re-launch tooling, or blend execution into normal administration.

What the Log Entry Should Tell You

A useful scheduled job record should let you answer four questions quickly: who created or changed it, what command or payload it will run, when or how often it will run, and under which account it will execute. If those fields are missing or truncated, you have less visibility into whether the job is routine maintenance or a persistence mechanism.

In practice, defenders look for the surrounding context as much as the event itself. A job created by an unexpected user, a service account that never usually schedules tasks, or a process that spawns a job from an unusual parent process is more suspicious than the creation event alone.

Because scheduled jobs are often used for repeatable execution, the job definition can be more important than the initial binary or script invocation. If the command line points to an external location, launches an interpreter, or hides behind a benign-looking name, that is a strong reason to inspect the full job object and its execution history.

How to Triage Suspicious Job Creation

Start by confirming whether the creation is consistent with the system’s normal administration pattern. Compare the creator account, host, time of day, parent process, and target path against known-good automation, because legitimate enterprise schedulers can produce noisy logs that look similar to attacker activity.

Then validate whether the job is new, modified, or simply re-registered after removal. Attackers frequently tweak existing scheduled jobs to preserve access or to change the payload while keeping a familiar name, so modification events deserve the same attention as first-time creation.

For higher-confidence investigation, correlate the event with process creation, script execution, authentication, and network activity around the same timestamp. A scheduled job that appears shortly after credential use, remote administration, or suspicious script activity is more likely to be part of a broader intrusion chain than an isolated administrative action.

Risk and Threat Considerations

Scheduled job creation is a persistence control point because it can turn a one-time foothold into repeat execution with little visibility. The main risk is that a malicious job looks like routine automation while quietly re-launching payloads, re-establishing access, or changing behaviour after reboot or logoff.

Failure mechanism: An attacker with sufficient access creates or modifies a task to run under a trusted account or at a predictable interval, then uses that schedule to survive cleanup or re-entry attempts.

Impact: The environment can retain attacker execution even after the original exploit path is closed, which increases dwell time, complicates incident response, and can expose additional systems or credentials through repeated execution.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
MITRE ATT&CK T1053 — Scheduled Task/Job Scheduled job creation is a classic persistence technique in ATT&CK.
Recommendation — Map suspicious job creation to T1053 and hunt for persistence across the host estate.
NIST SP 800-53 Rev 5 AU-2 — Event Logging Job creation should be captured in audit logs for later review and correlation.
AU-6 — Audit Record Review, Analysis, and Reporting Triage depends on reviewing who created the job, when, and what it will run.
CM-3 — Configuration Change Control Scheduled jobs are configuration objects whose creation and changes need control.
Recommendation — Log scheduled job creation and modification events for review and correlation. Review scheduled job audit records for anomalous creators, commands, and execution context. Require approval and tracking for scheduled job creation and modification.
CIS Controls v8 CIS-8 — Audit Log Management This topic depends on collecting and reviewing job creation audit trails.
CIS-5 — Account Management Job creation often hinges on which account created or owns the task.
Recommendation — Centralise and review scheduled job logs for suspicious creation or change events. Limit who can create scheduled jobs and review those accounts regularly.

Practitioner Guidance

What to verify: Treat the creator identity, run-as account, command line, trigger, and creation source as the minimum evidence set. If any one of those fields is missing, deferred, or inconsistent with normal admin tooling, investigate before assuming the job is benign.

Decision rule: If the scheduled job can execute code, access sensitive data, or run with elevated privileges, prioritise containment and review of the job definition over cosmetic cleanup. Deleting the task without understanding how it was created can leave the intrusion path intact.

Practitioner takeaway: The creation event is only the starting point, the real security question is whether the job gives an identity or process durable, repeatable execution that should not exist.