---
{
  "title": "Create or Modify System Process",
  "summary": "Creating or modifying a system process establishes execution through services or daemons.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1543"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1543: Create or Modify System Process",
      "url": "https://attack.mitre.org/techniques/T1543"
    }
  ],
  "editorialVersion": 2
}
---

## Services can provide repeatable execution

Creating or modifying a system process establishes execution through operating-system services, daemons, or comparable managed components. These mechanisms support normal background functions and can run automatically or under a defined service identity. Unauthorized configuration can make unwanted behavior repeat or execute with authority different from an ordinary user application.

The investigation must identify the service mechanism, configuration, referenced executable, account, and trigger. A new service is not automatically malicious, and a familiar service name does not establish that its target or settings remain approved.

## A service points somewhere new

In a fictional endpoint case, a service that previously launched an approved support component now references a different executable. The analyst preserves the current configuration and compares it with a trusted baseline, deployment history, and any available change records.

A legitimate product upgrade could explain the new path. The team checks whether the version, package source, timing, and service owner match the approved change. They also examine the permissions on the service configuration and referenced file.

Configuration and execution are separate evidence stages. A modified service definition shows a changed path; process or service state records may show whether the target actually ran. If the service failed to start, describe that result rather than assuming the intended behavior completed.

## Review authority and reach

Determine which identity modifies the service and which identity runs it. If a less-trusted account can change code later executed by a privileged service, the permission relationship deserves careful review. The specific platform and configuration determine whether such a path exists.

[[system-services]] covers execution through the service mechanism. [[file-and-directory-permissions-modification]] helps explain how altered permissions can enable changes to relevant artifacts. [[persistence]] connects recurring service execution to retained access.

## Restore the service safely

Preserve the definition, artifact metadata, and related events before cleanup where practical. Restore a reviewed configuration and trusted executable, investigate the access that allowed modification, and check for other changes made under the same authority.

Coordinate with the service owner. Deleting a background component without understanding its business purpose can disable essential management or application functions. Define how legitimate operation will be tested after remediation.

For practice, compare a new approved monitoring service with a fictional modification that redirects an existing service to an unexplained program. Identify the change history, file provenance, permissions, and execution records needed for a decision. Write one conclusion supported by configuration alone and a stronger conclusion that requires runtime evidence. [[incident-reporting]] should preserve that distinction.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]