DC0012: Scheduled Job Modification
Changes made to an existing scheduled job, including modifications to its execution parameters, command payload, or execution timing.
Analyst context for executives and security teams
Scheduled Job Modification matters because scheduled jobs often run trusted, recurring business and administrative tasks. A change to an existing job can alter what runs, when it runs, or which command payload is executed, making this data component useful for validating whether routine automation has been tampered with. For leaders, the value is not the job itself but whether the organization can prove that changes to scheduled execution are authorized, logged, reviewed, and explainable during an incident or audit.
Executive priority
Prioritize this as an evidence and control-validation area for operational resilience and incident response readiness. Security leaders should ask: Which systems rely on scheduled jobs for business operations or administration? Are modifications logged centrally? Can teams distinguish approved maintenance from suspicious changes? Because ATT&CK provides no platform, tactic, or detection detail for this object, local environment knowledge is required to determine risk and monitoring priority.
Technical view
SOC and IR teams should validate visibility into modifications of existing scheduled jobs, specifically changes to execution parameters, command payloads, and execution timing. Since no platform or detection guidance is supplied, detection engineering should begin by inventorying where scheduled jobs exist in the environment, identifying authoritative logs or configuration records for job changes, and correlating modifications with approved change activity, administrator identity, and nearby execution events.
Likely telemetry
- Scheduled job configuration change records
- System or application logs showing job modification events
- Administrative audit logs tied to the account making the change
- Configuration management or change-management records
- Job execution history showing timing, command, or parameter changes
Detection direction
- Validate that scheduled job modifications are collected, not just scheduled job executions.
- Alert or review changes to command payloads, execution parameters, or timing when they lack an approved change record.
- Tune for expected administrative maintenance to reduce false positives, especially in environments with frequent automation changes.
- Correlate modification time, modifying identity, and subsequent job execution behavior during investigations.
- Document blind spots where scheduled jobs exist but modification telemetry is unavailable or not centrally retained.
Mitigation priorities
- Maintain an inventory of scheduled jobs that support administrative or business processes.
- Require change control for modifications to important scheduled jobs.
- Restrict who can modify scheduled jobs according to least privilege.
- Centralize and retain logs or configuration evidence for job modifications.
- Periodically review high-value or sensitive scheduled jobs for unauthorized command, parameter, or timing changes.
Analyst notes and limits
This object is a data component, not a technique. It describes the kind of evidence defenders may collect: changes made to existing scheduled jobs. No ATT&CK relationships were supplied, so this take does not map the component to specific tactics, techniques, platforms, or adversary behaviors.
Official detection text, platforms, tactics, and relationship context were not provided. Any practical implementation depends on the operating systems, schedulers, logging sources, identity model, and change-management practices in the local environment.
Scheduled Job Modification
Changes made to an existing scheduled job, including modifications to its execution parameters, command payload, or execution timing.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | b4e25dd5bb4e… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0012Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.