D3-SJA Scheduled Job Analysis: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It

A scheduled job gives an attacker code that runs again and again without anyone logging on, often as SYSTEM or root, which makes job schedulers one of the most common persistence and remote execution paths on any host. MITRE D3FEND names the defence D3-SJA Scheduled Job Analysis (synonym: Scheduled Job Execution). It is a Detect tactic countermeasure under Operating System Monitoring (D3-OSM), defined as analysis of source files, processes, destination files, or destination servers associated with a scheduled job to detect unauthorised use of job scheduling. This card covers the artefact it analyses, the ATT&CK techniques D3FEND relates it to, the telemetry to collect on Windows, Linux and Kubernetes, and how to prove the analysis works. It is written for detection engineers, endpoint owners and incident responders.

Key takeaways

• The artefact is the job schedule. D3FEND defines a Job Schedule as the specification of tasks to be executed at particular times or intervals, stored under C:\Windows\System32\Tasks or the registry on Windows and in /etc/crontab on Linux.
• Analyse what the job points at, not only that it exists. D3FEND's article checks the job's source files, processes, destination files and remote servers against signatures, allowlists or reputation sources.
• Two inferred ATT&CK relations. D3FEND relates D3-SJA to Scheduled Task/Job (T1053) and Masquerade Task or Service (T1036.004) because both modify the Job Schedule artefact.
• Creation events beat command lines. Watching schtasks.exe (MITRE CAR-2013-08-001) misses tasks created through APIs or by dropping files; Windows Security event 4698 records the full task XML whatever the method.
• Schedulers are everywhere. Task Scheduler, at, cron, systemd timers and Kubernetes CronJobs all need coverage, and D3FEND notes that jobs can be scheduled in many creative ways.

D3-SJA at a glance

How it works

D3FEND's description has two stages. First, identify the details of a scheduled job: the files it runs, the process that created it, files it writes and servers it reaches. Second, compare those details against an anti-malware signature database, an allowlist or a reputation server; on a match against a bad list, execution is denied and an alert raised. The McAfee patent D3FEND cites does this by intercepting access to the task scheduler with hooking or file filters and checking the entity that tried to create the job.

D3FEND also extends the scope beyond classic schedulers: triggers that run a command after a system event, such as WMI Event Subscriptions on Windows, are part of the same problem. WMI subscriptions are their own ATT&CK technique (T1546.003, Windows Management Instrumentation Event Subscription), but a D3-SJA programme that ignores them leaves an obvious gap. Sysmon Event IDs 19, 20 and 21 record WMI filter, consumer and binding activity.

In practice, implementations combine three checks on every new or changed job:

• Action check: the command or binary path, its hash, signature and prevalence across the fleet, and whether it sits in a user-writable directory.
• Principal check: who created the job and which account it runs as. A task running as SYSTEM created by a standard user session is a priority.
• Location and naming check: where the definition lives and whether its name imitates a legitimate vendor task, which is the Masquerade Task or Service pattern.

ATT&CK techniques D3FEND relates to D3-SJA

Relationship type: inferred, not a direct mapping. D3FEND marks these relations as inferred and experimental: the techniques modify the Job Schedule artefact that D3-SJA analyses. They show relevance, not guaranteed coverage. Each ID was checked against ATT&CK v20.

The T1053 sub-techniques show where the schedule lives: At (T1053.002), Cron (T1053.003), Scheduled Task (T1053.005), Systemd Timers (T1053.006) and Container Orchestration Job (T1053.007). CAR-2013-08-001 rates moderate coverage of T1053.005. For attacker behaviour and mitigations, see the T1053 Scheduled Task/Job Defensive Guide and the T1036 Masquerading Defensive Guide; this page does not repeat them.

Where it is implemented

Product classes that implement D3-SJA include endpoint detection and response agents (job creation alerts and scheduler hooks), SIEM analytics over Windows and Linux logs, file integrity monitoring, and Kubernetes admission and audit tooling. Event 4698 is the richest single source on Windows: Microsoft's documentation shows its TaskContent field carries the full task XML, including the principal, logon type and the <Exec><Command> action, and recommends watching for tasks created in the Task Scheduler Library root. See the Windows Event Log Guide, the Sysmon Guide and the Linux Logging and auditd for Defenders Guide.

A systemd timer activates the service with the same name by default, or the unit named in Unit=. Analysing the timer alone tells you when something runs but not what: always resolve and inspect the activated service's ExecStart=.

Where identity fits

Scheduled jobs are a quiet home for credentials. Microsoft's event 4698 guidance recommends alerting when TaskContent contains <LogonType>Password</LogonType>, because the account's password is then stored and can be extracted by an administrator. Cron entries and job scripts often carry tokens or passwords in arguments. Record the run-as account for every job, prefer managed service accounts, and see How to Find credentials in cron jobs and scheduled tasks. Kubernetes CronJobs run under a service account named in the pod template, so a new CronJob is also a new use of that identity.

Implementation steps

1. Turn on the events. Enable Audit Other Object Access Events on Windows endpoints and servers so 4698 to 4702 are written, and forward them centrally. Add Sysmon or EDR process and WMI telemetry.
2. Cover Linux paths. Watch /etc/crontab, /etc/cron.d/, /var/spool/cron/ and systemd unit directories for writes, using file integrity monitoring or audit rules.
3. Baseline per image. Export the task list, crontabs and timers from a clean build of each image. Store task name, action path, hash, signer and run-as account.
4. Write the analytics. Alert on: new tasks in the library root; actions in user-writable paths such as user profile, Temp or ProgramData; jobs running as SYSTEM or root created from a non-administrative session; remote creation (the /s flag CAR-2013-08-001 highlights); tasks with names that copy vendor tasks but point at unsigned binaries.
5. Enrich with reputation. Hash the action binary or script and check it against your allowlist and reputation source, as D3FEND describes. See the D3-FHRA File Hash Reputation Analysis.
6. Pilot in alert-only mode. Run two weeks on one business unit, record the cause of every alert, and add suppressions keyed on hash, signer and change ticket, never on task name alone.
7. Decide on blocking. D3FEND's description includes denying execution on a match. Only enable prevention after the pilot shows a low false positive rate, and keep a documented rollback (switch the rule back to alert).

How to verify it works

• Windows unit test: CAR-2013-08-001 gives a test: create a one-off task with schtasks /Create /SC ONCE that launches calc.exe, confirm the analytic fires, then delete it with schtasks /Delete. Also create a task through the Task Scheduler user interface and confirm event 4698 still alerts, which proves you are not relying on the command line only.
• Linux test: add a harmless entry in /etc/cron.d/ and a test timer, confirm both alerts arrive, then remove them.
• Masquerade test: create a task under a vendor-like folder name pointing at an unsigned test binary in a user directory; the path and signer checks should fire.
• Kubernetes test: in a test namespace, create a CronJob with an unapproved image and confirm the audit log analytic flags it.

The thresholds you set for these metrics are local choices; the metrics above are examples, not a standard.

Limits, bypasses and failure patterns

• Command line only: detecting schtasks.exe misses tasks registered through the COM API, PowerShell cmdlets or file drops. Use creation events as the primary signal.
• Audit policy not set: 4698 is not written unless the subcategory is enabled. Check policy on every host class, not only domain controllers.
• Ignoring updates: a task that is modified (4702) to point at a new action is as dangerous as a new task. Track changes, not only creation.
• Timer without service: inspecting a systemd timer without the service it activates, or a CronJob without its pod template, misses the actual payload.
• Name-based suppression: allowlisting by task name lets a masquerading task through. Suppress by action hash and signer.
• Missing other triggers: WMI subscriptions and other event triggers sit outside the scheduler but give the same outcome, as D3FEND's considerations note.

Framework mapping

The NIST mapping is NHI Mgmt Group's view, not part of D3FEND. For the mitigations, see M1047 Audit and M1026 Privileged Account Management.

Related countermeasures

Siblings under Operating System Monitoring cover adjacent persistence state: D3-SICA System Init Config Analysis, D3-USICA User Session Init Config Analysis, D3-SDM System Daemon Monitoring and D3-SFA System File Analysis (whose child is D3-SBV Service Binary Verification). When a job launches an interpreter, D3-SEA Script Execution Analysis and D3-PSA Process Spawn Analysis take over.

Practitioner checklist

• Enable Audit Other Object Access Events and forward 4698 to 4702 from every Windows host class.
• Monitor cron files, cron directories and systemd timer and service units on Linux.
• Collect Kubernetes audit events for CronJob create and update.
• Baseline jobs per image with action hash, signer and run-as account.
• Alert on jobs in the library root, actions in user-writable paths and privileged jobs from non-administrative sessions.
• Flag tasks that store passwords and move them to managed service accounts.
• Include WMI event subscriptions in scope.
• Run planted job tests monthly on each platform and track the pass rate.

Standards and references

• MITRE D3FEND: Scheduled Job Analysis (D3-SJA)
• MITRE CAR: CAR-2013-08-001 Execution with schtasks
• MITRE CAR: CAR-2013-05-004 Execution with AT
• MITRE ATT&CK: T1053 Scheduled Task/Job
• Microsoft Learn: 4698 A scheduled task was created
• Microsoft Learn: Sysmon
• Linux man-pages: crontab(5)
• freedesktop.org: systemd.timer

Related NHI Mgmt Group resources: MITRE D3FEND Guide · T1053 Scheduled Task/Job Defensive Guide · How to Find credentials in cron jobs and scheduled tasks · D3-SICA System Init Config Analysis