Create or Modify System Process

Every mainstream operating system has a way to register a program that the system itself starts and keeps running, independently of any logged-in user. On Windows those are services, managed by the Service Control Manager. On Linux they are typically systemd units. On macOS they are launch daemons and launch agents. The tooling and the vocabulary differ by platform; the property they share is what this technique is about.

Whatever the platform calls it, a registered system process generally starts without anyone logging in, runs in an elevated context, and is restored automatically after a reboot. That combination is why this technique carries both Persistence and Privilege Escalation: an attacker who can register or alter one of these has usually obtained both at once.

The pattern holds across platforms even though the commands do not. An attacker with sufficient rights either registers a new unit pointing at their own payload, or edits an existing one so that a trusted, already-present entry now runs something else. The second is consistently harder to find, because the inventory of units looks unchanged.

Which sub-technique applies is a question of platform and mechanism rather than of intent, so the per-platform pages carry the specific evidence. Read this page for the shape that is common to all of them, and the sub-technique page for the fields that actually identify it on the host in front of you.

Data source: The operating system's own record of a system process being registered or reconfigured, alongside endpoint process-creation telemetry for the tool that performed the change

At this level the question is the same on every platform: what does the registered unit actually run, who registered it, and was it expected? A unit pointing at a binary in a writable or temporary location, registered outside a change process, is worth pursuing anywhere.

The second question, and the one most detection misses, is whether an existing unit was altered rather than a new one added. Alerting built only on creation will not see a hijacked Windows service, a rewritten systemd unit, or a modified property list. Establish what the expected inventory of auto-starting processes looks like for each platform in the estate, then investigate changes to that inventory rather than only additions to it.

Legitimate software registers system processes constantly, on every platform. Installers, update mechanisms, security agents and configuration-management tooling are all expected sources, and a recently built or patched host will show many of them close together.

Volume alone therefore proves nothing. The useful discriminators are whether the registering process is one that normally does this, whether the target binary is signed and in a location that software normally occupies, and whether the change lines up with known maintenance. Those questions are answered with platform-specific fields, which is why the sub-technique pages carry that detail.

• MITRE ATT&CK: T1543 Create or Modify System Process

No range covers this technique yet; the write-up above landed first. Ranges are added continuously; the ones live today are on the training ladder.