T1543: Create or Modify System Process
Adversaries may create or modify system-level processes to repeatedly execute malicious payloads as part of persistence. When operating systems boot up, they can start processes that perform background system functions. On Windows and Linux, these system processes are referred to as services.[1] On macOS, launchd processes known as Launch Daemon and Launch Agent are run to finish system initialization and load user specific parameters.[2]
Adversaries may install new services, daemons, or agents that can be configured to execute at startup or a repeatable interval in order to establish persistence. Similarly, adversaries may modify existing services, daemons, or agents to achieve the same effect.
Services, daemons, or agents may be created with administrator privileges but executed under root/SYSTEM privileges. Adversaries may leverage this functionality to create or modify system processes in order to escalate privileges.[3]
Analyst context for executives and security teams
Create or Modify System Process matters because services, daemons, agents, and container service components are trusted startup mechanisms. If an adversary can add or alter them, malicious code may survive reboots and may run with root or SYSTEM-level privileges. For leaders, this is a control-validation issue: can the organization prove who is allowed to create persistent system processes, whether those changes are logged, and whether SOC/IR teams can quickly distinguish approved administration from suspicious persistence?
Executive priority
Prioritize this technique where business-critical Windows, Linux, macOS, and container environments depend on reliable service startup and privileged process control. The business risk is not just malware execution; it is loss of confidence in system integrity after an incident. Executives should ask whether privileged account management, file and directory permissions, OS/software hardening, software installation restrictions, endpoint behavior prevention, code signing, and audit evidence are consistently enforced and reviewable across platforms.
Technical view
ATT&CK lists this technique under persistence and privilege escalation for Containers, Linux, macOS, and Windows. The related sub-techniques provide the platform-specific validation paths: Launch Agents and Launch Daemons on macOS, systemd services on Linux, Windows Services on Windows, and container/container-cluster services for container environments. Because the object has no official detection text, detection engineering should use the related detection strategy DET0571 as a starting point and validate coverage for new or modified service definitions, daemon/agent configuration files, service executable paths, startup/recovery commands, privilege context, and unexpected changes by administrative or service accounts.
Likely telemetry
- Endpoint process creation and parent/child process telemetry around service, daemon, agent, and container service management activity
- Operating system audit logs for service creation, modification, enablement, startup, and privilege context
- File integrity or configuration monitoring for service definitions, launchd property list files, systemd unit files, and comparable startup configuration locations
- Registry or service configuration change telemetry on Windows where service configuration is stored
- macOS launchd/Launch Agent/Launch Daemon configuration evidence
Detection direction
- Baseline approved services, daemons, agents, and container service components, then alert on new entries or material changes to executable paths, arguments, startup settings, or recovery commands.
- Correlate service/process modifications with privileged account activity; false positives are common during patching, endpoint management, software deployment, and administrator maintenance.
- Tune separately by platform using the sub-technique context: Windows Services, Linux systemd services, macOS Launch Agents/Daemons, and container services have different configuration stores and normal administrative workflows.
- Investigate modifications that cause execution at boot, login, or repeatable intervals, especially where the configured binary or script is newly introduced, unsigned, unexpected, or located outside normal administrative paths.
- Confirm audit depth, not just alert presence: IR teams need the prior value, new value, actor account, host, timestamp, and referenced executable to determine persistence scope.
Mitigation priorities
- Start with privileged account management and user account management: limit who can create or modify system-level processes and require accountable administrative use.
- Restrict file and directory permissions on service, daemon, agent, and startup configuration locations so ordinary users and unauthorized processes cannot write to them.
- Harden operating system and software configurations to reduce unnecessary services and disable unused features where appropriate.
- Limit unauthorized software installation so unapproved services or agents are harder to introduce.
- Use endpoint behavior prevention and audit controls to detect or block suspicious creation or modification behavior where supported.
Analyst notes and limits
This object is a parent technique. The most useful operational content comes from its sub-techniques: T1543.001 Launch Agent, T1543.002 Systemd Service, T1543.003 Windows Service, T1543.004 Launch Daemon, and T1543.005 Container Service. Related mitigations are broad control families rather than one-click fixes, so validation should be evidence-based: who can change startup processes, what changes are logged, and how quickly suspicious changes can be triaged.
MITRE provides no official detection text for this object in the supplied fields. The take therefore avoids specific detection logic and relies on official platforms, tactics, descriptions, sub-technique relationships, mitigations, and the related DET0571 detection strategy name. Local operating system versions, endpoint tooling, container architecture, administrative workflows, and logging configuration are required to determine actual coverage.
Create or Modify System Process
Adversaries may create or modify system-level processes to repeatedly execute malicious payloads as part of persistence. When operating systems boot up, they can start processes that perform background system functions. On Windows and Linux, these system processes are referred to as services.[1] On macOS, launchd processes known as Launch Daemon and Launch Agent are run to finish system initialization and load user specific parameters.[2]
Adversaries may install new services, daemons, or agents that can be configured to execute at startup or a repeatable interval in order to establish persistence. Similarly, adversaries may modify existing services, daemons, or agents to achieve the same effect.
Services, daemons, or agents may be created with administrator privileges but executed under root/SYSTEM privileges. Adversaries may leverage this functionality to create or modify system processes in order to escalate privileges.[3]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1543.004 | Launch Daemon Sub-technique | Launch Daemon subtechnique of this object. |
| Enterprise | T1543.005 | Container Service Sub-technique | Container Service subtechnique of this object. |
| Enterprise | T1543.001 | Launch Agent Sub-technique | Launch Agent subtechnique of this object. |
| Enterprise | T1543.002 | Systemd Service Sub-technique | Systemd Service subtechnique of this object. |
| Enterprise | T1543.003 | Windows Service Sub-technique | Windows Service subtechnique of this object. |
Groups, software, and campaigns
S1152: IMAPLoader
IMAPLoader is a .NET-based loader malware exclusively associated with CURIUM operations since at least 2022. IMAPLoader leverages email protocols for command and control and payload delivery.[1]
S1194: Akira _v2
S1184: BOLDMOVE
BOLDMOVE is a type of backdoor malware written in C linked to People’s Republic of China operations from 2022 through 2023. BOLDMOVE includes both Windows and Linux variants, with some Linux variants specifically designed for FortiGate Firewall devices. BOLDMOVE is linked to zero-day exploitation of CVE-2022-42475 in FortiOSS SSL-VPNs.[1] The record for BOLDMOVE only covers known Linux variants.
S0401: Exaramel for Linux
Exaramel for Linux is a backdoor written in the Go Programming Language and compiled as a 64-bit ELF binary. The Windows version is tracked separately under Exaramel for Windows.[1]
S9015: BRICKSTORM
BRICKSTORM is a cross-platform backdoor with variants written in Go and Rust that facilitates command and control, the ingress transfer of other malware, and the exfiltration of data.[1][2][3][4] BRICKSTORM has also been created from a .NET application using ahead-of-time (AOT) compilation to blend in within victim environments.[1] BRICKSTORM was first observed in April 2024.[5] BRICKSTORM has previously been leveraged by People's Republic of China (PRC) state-nexus actors identified as UNC6201, UNC5221, WARP PANDA, PunyToad, and SYLVANITE.[6][7][1][8][9][10][3][4]
S1121: LITTLELAMB.WOOLTEA
LITTLELAMB.WOOLTEA is a backdoor that was used by UNC5325 during Cutting Edge to deploy malware on targeted Ivanti Connect Secure VPNs and to establish persistence across system upgrades and patches.[1]
S1142: LunarMail
LunarMail is a backdoor that has been used by Turla since at least 2020 including in a compromise of a European ministry of foreign affairs (MFA) in conjunction with LunarLoader and LunarWeb. LunarMail is designed to be deployed on workstations and can use email messages and Steganography in command and control.[1]
All related ATT&CK context
Mitigation direction
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 | 1.2 | Current bundle | 4fd24989d068… |
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]
TechNet Services
Microsoft. (n.d.). Services. Retrieved June 7, 2016.
Open source URL -
[2]
AppleDocs Launch Agent Daemons
Apple. (n.d.). Creating Launch Daemons and Agents. Retrieved July 10, 2017.
Open source URL -
[3]
OSX Malware Detection
Patrick Wardle. (2016, February 29). Let's Play Doctor: Practical OS X Malware Detection & Analysis. Retrieved November 17, 2024.
Open source URL -
[4]
mitre-attack T1543Open 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.