Detect Create or Modify System Process by watching for suspicious process launches or tampering with service, driver, or scheduled task configurations. Alert on privileged processes started from unusual parents, unsigned binaries, command-line abuse, and changes to persistence objects. Correlate endpoint telemetry, service control activity, and administrative actions to distinguish normal maintenance from attacker behaviour.
What “Create or Modify System Process” detection should focus on
This technique is best detected as a combination of process creation anomalies and persistence or configuration tampering. Security teams should look for privileged processes launched from unusual parents, binaries that do not match the normal software lineage, and command lines that create or alter services, drivers, or scheduled tasks. The key question is whether the action is consistent with approved administration or whether it is being used to establish execution at startup or after reboot.
Coverage should include both the immediate process event and the object being changed. A benign admin action often has a clear change ticket, known tooling, and expected parent-child relationships. An attacker will often pivot through Persistence Techniques Guide patterns such as service configuration changes, run keys, scheduled task creation, or similar autostart mechanisms, so the detection logic should treat persistence-oriented modification as part of the same threat chain rather than as a separate low-priority event.
Endpoint telemetry is strongest when it can tie the process, the user context, and the resulting system change together. A service control event, registry or task change, and an administrative session occurring close together may be normal during maintenance, but the same pattern becomes suspicious when the binary is unsigned, the parent process is a script host or office application, or the command line attempts to hide the target, add persistence, or replace a trusted executable.
Signals that separate maintenance from abuse
Good detections rely on context, not just on the fact that a process was created. Focus on unusual parent processes, one-off utilities running with elevated rights, service binaries launched outside their normal management path, and changes made by accounts that do not usually touch host configuration. Look for modifications to persistence objects that are rare in day-to-day operations, especially when they happen outside a patch window or from an interactive session that should not be managing infrastructure.
Command-line inspection matters because many malicious actions are visible only in the arguments. Attackers commonly use installer-like syntax, service creation flags, task scheduling switches, or direct registry edits to make the change look routine. Correlating that command line with signer reputation, file path, hash prevalence, and the usual baseline for that host gives analysts a practical way to distinguish expected configuration work from a covert attempt to plant execution.
Where available, hunt for the follow-on effect as well. If a process claims to create or modify a system process, there should usually be a corresponding change in service state, task metadata, driver installation records, or persistence inventory. If the action has no obvious operational owner or no matching change record, it deserves escalation even when the initial process tree looks superficially administrative.
How to operationalize this detection in a SOC
Start with alert logic that joins endpoint events with administrative logs and service control activity, then tune it against known-good maintenance workflows. Use allowlists carefully: approved deployment tools, software distribution systems, and patch agents often create legitimate noise, but those exceptions should be narrow enough that they do not hide ad hoc use of shell, script, or remote administration tooling. This is where MITRE ATT&CK Enterprise Matrix is useful for mapping the technique to adjacent tactics such as persistence, privilege escalation, and execution.
Detection engineering should also account for the object being modified, not only the process that made the change. Service creation, driver installation, scheduled task registration, and startup configuration changes should each be watched as separate but related indicators. If your tooling can enrich events with signer status, parent lineage, user privileges, and change ticket metadata, analysts can triage quickly instead of treating every configuration change as equally suspicious.
For broader control alignment, teams can map the monitoring requirement to NIST Cybersecurity Framework 2.0 detect and response outcomes, and to NIST SP 800-53 Rev 5 Security and Privacy Controls for audit logging, configuration management, and integrity monitoring. Those controls help turn a raw event into evidence that can support both investigation and containment.
Risk and Threat Considerations
This technique is high value for attackers because it can convert a one-time execution foothold into durable persistence or a trusted system change. If defenders only alert on malware hashes or obvious scripting patterns, the attacker can hide inside legitimate administration channels and make the host look self-managed while quietly changing the execution path.
Failure mechanism: A malicious actor uses a privileged process or management utility to alter a service, driver, or scheduled task, then relies on that change to survive reboot, re-establish execution, or disguise later activity as routine maintenance.
Impact: The environment may gain persistent attacker execution, harder-to-reverse system tampering, and a broader blast radius if the change is pushed through shared administrative tooling or fleet management processes.
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 CSF 2.0, 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 | T1543 — Create or Modify System Process | Directly matches the technique and its persistence-oriented system process changes. |
| Recommendation — Map service, task, and driver tampering to T1543 and hunt for abnormal execution lineage. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Activities | Continuous monitoring is needed to spot suspicious process launches and configuration tampering. |
| Recommendation — Correlate endpoint and administrative telemetry to detect unauthorized system process changes. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Audit correlation is central to separating normal maintenance from attacker-driven tampering. |
| CM-6 — Configuration Settings | The technique abuses changes to system configuration objects that should be controlled. | |
| Recommendation — Review correlated audit records for unexpected service, task, or driver changes. Restrict and monitor changes to services, drivers, and scheduled tasks. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Log correlation is required to detect and investigate process and persistence abuse. |
| Recommendation — Centralize and review logs for service, task, and process modification events. | ||
Practitioner Guidance
What to verify: Confirm whether the process launch, the parent-child chain, and the resulting configuration change all belong to the same approved operational workflow. If any one of those three is unusual, treat the event as suspicious until you can tie it to a known deployment, patch, or infrastructure task.
Common mistake: Teams often tune only on known malware names or suspicious child processes and miss the quieter step where a trusted admin tool is used to create the persistence mechanism. That blind spot is especially costly when the attacker uses an allowed binary with unusual arguments.
Practitioner takeaway: The most reliable signal is not “a process was created,” but “a process created or changed something that should only change during controlled administration.”