Detecting T1543 Create or modify system process

How T1543 create or modify system process keeps an attacker in place

A SOC lead needs to assume that a persistence foothold can survive a reboot. T1543 Create or modify system process is one of the ways an adversary can do that by creating or changing a service, daemon or launch item so that attacker-controlled code starts again each time the host or container starts, without the attacker having to reconnect. Under MITRE ATT&CK, the Persistence tactic (TA0003) describes the adversary's aim as maintaining its foothold. In plain terms, T1543 is about the operating system's own service and init mechanisms being used as the restart point, which is why alerts on ordinary process activity alone often miss it.

The technique matters because it blends with normal administration. Installing a service, registering a daemon or loading a launch agent are routine actions for IT and platform teams, so the question for a responder is rarely whether such a change happened but whether it was authorized, who made it, and what the new entry runs. The technique has 5 sub-techniques, so a single detection rule will not cover it. Coverage needs to be planned per platform: container and Linux hosts, macOS, and Windows each expose these changes through different components and logs.

Decide now which ATT&CK version your detection mappings target. These pages use Enterprise ATT&CK v20, and a mapping written against one version should be re-checked when MITRE releases a new one, because releases can rename, deprecate or revoke techniques and sub-techniques. Before writing rules, confirm with your own platform team which service managers, container orchestrators and endpoint agents are in scope, and whose change records should explain legitimate service creation. Those answers determine which telemetry you must collect to tell a sanctioned change from a foothold.

Which telemetry reveals T1543 and which open-source tool collects it

This table maps the data components most often tied to T1543 detection (Process Creation, Command Execution, File Modification and File Creation) to the platforms where they matter and the open-source collectors that can supply them. Read each row as a starting point for your own sensor inventory, then confirm coverage in your environment before relying on any single source.

Platform	Signal to look for	Open-source collection	Confirm in your environment
Windows	Creation or change of a service entry, or a new service binary path pointing outside expected install directories, recorded as Process Creation or Registry changes under the services hive	Sysmon process and registry events forwarded through Wazuh agents, plus Windows Security events if service auditing is enabled	Whether service installation and change events are logged on every host class, and whether Sysmon configuration covers service-related registry keys
Linux	New or modified systemd unit files, or unit files that reference unexpected executables, recorded as File Creation or File Modification in system unit directories	auditd file watch rules or Wazuh file integrity monitoring on unit directories, with Velociraptor artifacts for hunting across hosts	Which unit directories are watched, whether writes from package managers are separated from manual changes, and retention of audit logs
macOS	New or changed launch daemon or launch agent property lists, or a new service loaded by launchd, recorded as File Creation or File Modification in system and user launch directories	Wazuh agent file integrity monitoring on launch directories, with Velociraptor artifacts for collecting property lists and loaded job lists	Whether the Wazuh agent version and macOS version in use support the monitoring you intend, and whether endpoint tooling already writes to these paths
Containers	Changes to init processes, entrypoint scripts or service definitions inside running containers, recorded as Command Execution or File Modification within the container runtime	Wazuh container monitoring where supported, host auditd for container runtime paths, and Falco-style runtime rules if your team has adopted them	Whether container file writes reach the host sensor at all, and whether ephemeral containers leave enough history to investigate
Process telemetry (all platforms)	Service management commands or init control commands run from an unexpected parent process, or by an account that does not normally administer services	Process Creation events from Sysmon on Windows and auditd execve records on Linux, collected centrally by Wazuh	Whether command-line arguments are captured, since the parent process and account are often needed to separate administration from abuse
Network context (where relevant)	Traffic from a newly created service to unexpected destinations shortly after its creation, which can corroborate a process-level finding	Zeek connection logs and Suricata alerts correlated with host events in Security Onion	Whether sensors see east-west traffic from the hosts in scope, since many service-based persistence events never cross a network boundary
Hunting and triage	Inventory differences between a known-good baseline and current services, daemons or units across a fleet	Velociraptor artifacts run on a schedule or on demand, with results stored for comparison	Who owns the baseline, how often it is refreshed after approved changes, and how much endpoint load your team accepts

Detection logic for T1543 that SOC teams can tune

T1543 detections work best when they start from a known baseline of system services, daemons and container runtimes. The cards below pair each signal with the threshold idea, the baseline to build first and the false positive sources that usually flood the queue. Sigma is a practical format for expressing these as portable rules, and each should be tuned against your own change records.

New or changed service definitions

Alert when a new service or daemon unit appears, or an existing one changes its executable path, start type or run-as account, outside an approved change window. On Windows this maps to Process Creation and Windows Registry Key Modification telemetry, and on Linux to File Creation and File Modification under the service manager's unit directories. Build a baseline of normal service inventory per host group first. Expect false positives from package managers and configuration management tools, which legitimately install and restart units, so suppress by known installer parent and change ticket where your tooling supports it.

System processes from unusual parents

Flag system-level processes, such as service host or init-managed daemons, whose parent is an interactive shell, a user-writable directory or a script interpreter. The useful threshold is parentage combined with the account context rather than a raw count of events. Establish which parent-child pairs are normal on each server role before alerting. Configuration management agents and backup agents will produce expected pairs, so record them explicitly. Use the Process Creation and Command Execution data components as the anchor, and keep the rule scoped to hosts where the pair is known to be abnormal.

Writes to service configuration locations

Watch for file modifications in service configuration paths, such as unit files, init scripts and registry service hives, especially when the writer is not the expected package or management process. The signal is strongest when a write is followed by a service reload or enablement within a short window. Tune by excluding paths and writers that change routinely during patching. Confirm your File Modification coverage includes the directories you care about, because many default agents monitor only a subset.

Container runtime and orchestration changes

In containerized environments, look for new privileged containers, changed restart policies, or host namespace mounts introduced outside the deployment pipeline. Container runtime daemon configuration edits and new system-level workloads deployed by a non-pipeline identity deserve review. Build a baseline of approved images, manifests and service accounts first. Common false positives come from GitOps controllers, node management tooling and scheduled cluster maintenance, so match on the controller identity and the deployment source. Confirm which audit and admission logs your platform actually emits before writing the rule.

Validate rules against change records

Each rule needs a documented expected-benign list and a review cadence, because the software estate changes faster than detection content. Tie suppressions to named change records and expire them automatically where the platform allows. Track the ATT&CK version each rule targets, since detection strategy and data component mappings can change between releases. Ask your SOC to report the suppression count per rule each month, so an exclusion that hides real activity becomes visible.

How to validate that a T1543 detection fires

This sequence proves that a detection for T1543 Create or Modify System Process fires as intended, from an authorized test on a non-production host through to a recorded result. It produces evidence the team can review, a list of gaps, and tuning changes tied to the ATT&CK version being targeted.

Agree the sub-technique scope in writing
The detection owner, the SOC lead and the system owner agree which of the five T1543 sub-techniques are in scope for this exercise, such as the Linux or Windows service paths that match the environment. They also confirm the ATT&CK version the detection maps to, because releases can rename or revoke techniques and sub-techniques. The output is a signed scope note that names the detection strategy and data components expected to fire, for example Process Creation and File Modification. The step is done when every in-scope sub-technique has a named detection and a named owner.
Obtain written authorization and set the logging record
Before any test, the asset owner and the security leadership approve the exercise in writing, naming the non-production host, the test window, the people allowed to perform the test and the people who will observe it. The team also confirms that the test activity itself will be logged in the change or ticketing record so that the events can be matched later to a known, approved action. Authorization is complete when the approval is filed with the scope note and the operators confirm they can stop the test at any time.
Run a controlled test on a non-production host
A trained operator performs a bounded, pre-agreed action on an isolated non-production host that is designed to resemble the T1543 behavior in scope, such as creating or changing a service definition in a controlled way. The operator follows the approved test plan rather than improvising, and a second person observes the action. The output is a timestamped record of what was changed, where and by whom. The step is done when the change is reverted and the host is returned to its baseline state, with the revert recorded.
Confirm the raw event reaches the SIEM
The detection engineer checks that the telemetry produced by the test, such as process creation or file modification events, arrives in the SIEM from the test host without loss or excessive delay. They compare the event fields with the data component named in the detection strategy and confirm that the host name, user and timestamp are present and parsed. If the event is missing, the engineer records whether the cause is the agent, the collector, the parser or the forwarding path. The step is done when the expected raw events are visible and their parsed fields match the rule's expectations.
Check the rule fires within the expected window
The detection engineer confirms that the Sigma or native SIEM rule for each in-scope sub-technique generates an alert, and that the alert arrives inside the response window the SOC has defined for this use case. They record the time between the test action and the alert, and whether the alert carries enough context for triage. Where the window is not defined yet, the team should agree it now and document it rather than assume one. The step is done when each in-scope rule has a recorded alert or a documented failure.
Record results, gaps and expected false positives
The team writes a results record for each sub-technique showing the test action, the raw events seen, the alerts produced, the timing and the triage outcome. The record also lists gaps, such as a sub-technique with no matching telemetry, and noisy administrative activity that could cause false positives. Each gap is assigned an owner and a follow-up. The output is a versioned report that names the ATT&CK version and the rule versions tested. The step is done when every in-scope sub-technique has a pass, partial or fail outcome with evidence attached.
Tune rules and retest after changes
The detection engineer applies the tuning changes agreed from the results, such as adding a data source, narrowing a condition or adding an allowlist for approved administrative activity with a documented reason. The team then reruns the same controlled test to confirm that the change fixed the gap without suppressing the alert. The output is an updated rule with a change log and a retest result. The step is done when the retest matches the expected outcome and the change is approved and stored with the detection content.

Preventive controls that reduce T1543 exposure

T1543 succeeds when the wrong identity can register or alter a service, daemon or launch agent that the operating system starts with elevated rights. The cards below cover the two ATT&CK mitigations named for this technique and the related controls that decide who can make those changes in the first place.

Audit (M1047) as a control

Audit is the mitigation that makes system process changes visible, so an unexpected service or launch item can be traced to an account and a time. For T1543, confirm that creation and modification events for services, daemons and launch agents are enabled on every platform in scope, including Windows service installation events and Linux or macOS service manager changes. Check that these logs reach a central store that the administrators who make routine changes cannot edit. Without this, detection content has nothing reliable to match.

Privileged Account Management (M1026)

Privileged Account Management limits which accounts can install or change system-level processes, and it is the main way to keep a standard user or compromised low-privilege account from creating a service that runs as root or SYSTEM. For T1543, inventory the groups and roles allowed to manage services and daemons, remove standing rights that are not needed, and require approval and separate logging for elevation. Review these assignments on a fixed schedule and after staff changes.

Restrict who can write service paths

Many T1543 changes depend on write access to the directories where service binaries, unit files or launch definitions live. Restrict File and Directory Permissions (M1022) may apply here, so check that only installers and administrators can write to these locations on each host type. Confirm the exact directories and permission model for your platforms rather than assuming defaults, because container images and managed hosts often differ from standard server builds.

Change control for system processes

Routine service and daemon installs should follow a documented change path, so any unplanned entry stands out. Set up a baseline of approved service definitions per host group, and alert on additions that do not match a ticket or deployment pipeline run. This control depends on Audit being in place, and it works best when configuration management is the only route for legitimate changes.

Mitigation applicability by platform

Mitigations map to T1543 across Containers, Linux, macOS and Windows, but how they apply differs on each. Ask your platform team to confirm, for each platform, which mitigation controls can be enforced, which need an agent or an added feature, and which are procedural. Record the answers in your control matrix so auditors can see the coverage decision and its owner.

Triage steps when a T1543 alert fires

The first decision on a T1543 alert is whether the new or changed service, daemon, launch agent or Windows service was authorized, and that question is answered by change records before any host is touched. Pull the change ticket, the deployment pipeline log and the configuration management history for the host and the time window in the alert. Confirm which account made the change, from which source address and through which management path. A service created by an unexpected account or outside a change window is treated as suspicious until proven otherwise. Record the answer in the case file, because the rest of the triage depends on whether the change was planned.

Next, establish the scope of the change on the affected host. Identify the account that created or modified the service and whether that account is a human administrator, a service account or a deployment identity, and check whether it logged on to other hosts around the same time. Then compare the new definition (the unit file, plist, service binary path, start type and run-as account) against a known-good baseline from your configuration management or golden image. Hash the referenced binary and check its signature and location. Where the baseline is missing, say so in the case notes rather than guessing. If the change is malicious, isolate the host through your endpoint or network controls, but keep it powered on and connected to your collection channel so volatile evidence is not lost.

Preserve evidence before remediation. Collect the service definition, the referenced binary, the relevant event or journal logs, and the process tree for the service, using a collection tool such as Velociraptor or an equivalent that your team has tested in advance. Keep a record of what was collected, when and by whom. Then check for other persistence on the same host, including scheduled tasks, autostart entries and any other T1543 sub-technique, because adversaries often keep more than one foothold. Confirm with your incident response lead and your legal or compliance contact what must be retained and for how long, since those requirements vary by sector and jurisdiction. Remediate only after the evidence is captured and the blast radius is documented.

Rehearsing T1543 detection in a private cyber range

The Linux and container range should be built inside the client's own infrastructure or an isolated lab, with a representative set of hosts, a container runtime and an orchestrator if the client uses one. The facilitator plans injects that change service definitions and init configuration, and that create or alter container workloads through approved change paths, so the team can see whether Process Creation, Command Execution and File Modification events reach the SIEM with enough context to be useful. Good detection links a changed unit file or workload definition to a process start, a user and a change ticket. Good response means the on-call engineer can confirm or reject the change within the agreed triage window and document the rollback.

Range environment: Two or three Linux hosts plus a small cluster, each shipping audit and host telemetry to Wazuh or a comparable collector.
Injects to plan: A service definition change outside a change window, and a workload image or manifest update that the change record does not mention.
Detection check: Confirm that the file path, the actor and the parent process are present in the event, not only the file name.
Response check: Verify that the playbook includes isolating the host or workload, comparing the definition against version control and recording the timeline.
Evidence: Export the alert, the timeline and the rollback record for the exercise report.

Check that each inject maps to a named detection strategy in the ATT&CK version your team targets.

Questions SOC leads and detection engineers ask about T1543

How do I tell a legitimate service install from a malicious one?

Start from the installer, not the service name. A legitimate service install usually comes from a known software deployment path, a signed binary from a known publisher, and a change ticket or configuration management run. Build an allowlist of expected service creations per host group from your deployment tooling, then alert on service creations that fall outside it. Review the binary path, the account the service runs under, the signing status and the parent process. Services that run from user-writable directories, use unfamiliar names that imitate system services, or run as highly privileged accounts deserve priority review. Expect a tuning period, and record each exception with an owner and a reason so the allowlist stays auditable.

What should I do when a container image changes unexpectedly?

Treat an unexpected image change as a question about provenance before you treat it as an incident. Compare the image digest against the one your pipeline built and signed, check which pipeline or identity pushed it, and confirm whether a deployment record explains it. In a Kubernetes or container platform, also review changes to workload specifications, since a modified deployment can create or alter a process that runs at every restart. Your telemetry should cover image pulls, image pushes and workload updates in the orchestrator audit log. Confirm with your platform team which of these your runtime and registry actually emit, because coverage differs between products and versions.

What should I do when Sysmon or auditd coverage is only partial?

Partial coverage is common, so document it before you tune anything. Map each host group to the telemetry it actually produces, such as Sysmon service creation events on Windows or audit rules for service unit changes and file writes on Linux, and mark the gaps. Where a gap sits on a path that matters for T1543, such as service configuration directories or the Windows service control manager, close it first. Validate every rule against a test host to confirm that the events arrive in Wazuh, Security Onion or your chosen pipeline. Do not write a detection that depends on a data source you have not confirmed on that host. Ask your team to name the owner of each gap and the date it is reviewed.

How do I version detections against ATT&CK releases?

Record the ATT&CK version each detection targets in the rule metadata, and review mappings whenever MITRE publishes a release. MITRE's update notes show that releases can rename, deprecate or revoke techniques and sub-techniques, and that version 18 replaced technique-level detections with detection strategies and analytics and changed data components. Keep your mapping in a file that references the STIX bundle for the version you use, so you can diff changes between releases. When a release changes data components, check whether your log sources still provide the fields the analytic needs. Store the mapping in version control and tag each detection release with the ATT&CK version it was validated against.

How do I measure detection quality after a purple team exercise?

Measure outcomes per sub-technique, not as one overall score. For each planned test, record whether the telemetry arrived, whether a rule or analytic fired, how long the alert took to reach an analyst, and whether the analyst's triage matched the expected classification. Separate the failures into collection gaps, logic gaps and triage gaps, because each has a different owner and fix. Repeat the same test after tuning to confirm the change works and does not break other detections. Keep the results in a table keyed to the ATT&CK version and detection identifiers, so a later exercise can show whether coverage improved. Your cyber range is the place to repeat these tests safely.

Which telemetry should I confirm before writing T1543 detections?

Confirm the data components that ATT&CK most often references for T1543 and its sub-techniques before you write logic. These include Process Creation, Command Execution, File Modification, File Creation, Windows Registry Key Modification and Application Log Content. For each one, check the collector, the event identifiers or fields it produces, the retention period in your environment, and whether the events reach your analytics platform with consistent timestamps. Ask your vendor or platform team to confirm these details for your exact versions, because field names and default settings vary. Missing one data component usually means a detection that looks correct on paper but never fires in production.

Can my own team run T1543 detection tests, or do we need outside help?

Your team can run these tests if it has access to a lab that mirrors production logging, a clear rules of engagement document, and time to review results. Many organizations start with their own team and add outside support where they lack capacity or independent review. DeployOpen can plan, implement and document a private cyber range and run security testing inside your environment, under a written, fixed scope. Ask any partner, including DeployOpen, to state in writing which ATT&CK version the tests target, which data components are in scope, and how results will be recorded and handed over.

How DeployOpen builds T1543 detections and range exercises

DeployOpen approaches T1543 Create or modify system process as a fixed-scope piece of defensive engineering inside the client's own environment. We start from the platforms and sub-techniques that matter to the client, then build and test detections with open-source tooling in a private cyber range before anything reaches production.

How we scope

Agree in writing which operating systems, container platforms and sub-techniques of T1543 are in scope.
Confirm which telemetry sources exist today, such as process creation, file modification and service configuration logs.
Record the ATT&CK version the detection mapping targets so later releases can be compared cleanly.

How we build

Map candidate detection logic for T1543 to Process Creation, Command Execution and File Modification data components.
Build and tune rules for the client's SIEM or open-source stack, including Wazuh or Sigma-based content where it fits.
Test detections in a private cyber range against controlled exercises, recording false positives and coverage gaps.

How we hand over

Deliver detection documentation that names each rule, its data source, its ATT&CK mapping and its known blind spots.
Provide response runbooks covering triage, scoping and containment steps for suspected system process changes.
Document how the Audit and Privileged Account Management mitigations were implemented and where evidence is stored.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, sized to the agreed scope.
Re-validate T1543 detections when ATT&CK releases change technique, sub-technique or data component mappings.
Confirm with your team which support and response hours apply, since these are set in the written agreement.

T1543 Create or modify system process