A service, daemon or container that starts with the system runs before anyone logs in, often as SYSTEM or root, which makes creating or changing one the most direct route from administrative access to permanent, privileged persistence. MITRE ATT&CK T1543 Create or Modify System Process covers Windows services, systemd services, macOS launch agents and daemons, and container services such as Docker restart policies and Kubernetes DaemonSets. In ATT&CK v20 it belongs to Persistence (TA0003) and Privilege Escalation (TA0004). This guide goes deeper than our general persistence page: it covers the service installation events and fields worth alerting on, the unit file paths and drop-ins systemd reads, how drivers and container runtimes fit, and how the service accounts these processes run as turn persistence into an identity problem. It is for detection engineers, platform and endpoint owners and incident responders; it contains no attack procedures.
Key takeaways
- Event 4697 tells you almost everything. It records the service name, binary path, service type, start type and service account, and Microsoft publishes the field values that should trigger review.
- Modification matters as much as creation. 4697 records the path at install time only; changes to an existing service's
ImagePath,ServiceDllor a systemd unit'sExecStartneed registry and file monitoring. - systemd reads many directories. Units and drop-ins in
/etc/systemd/system,/run/systemd/system,/usr/lib/systemd/system, user directories and generator output all count, so monitoring one path is not enough. - Drivers are services too. Kernel driver services (types 0x1 and 0x2) and boot or system start types are rare and high risk, and are how vulnerable signed drivers are loaded.
- Containers can persist as services. A container started with
restart=always, a rootful Docker daemon or a DaemonSet gives persistence on every node, including nodes added later.
How the attack works
ATT&CK describes T1543 as creating or modifying system-level processes "to repeatedly execute malicious payloads as part of persistence". Services are often created with administrator rights but run as root or SYSTEM, so the same step escalates privilege. Intruders either install a new service or change an existing one, frequently giving it a name that resembles a legitimate component (T1036.004 Masquerade Task or Service).
| Sub-technique (v20) | Platform | Where configuration lives | Variants ATT&CK records |
|---|---|---|---|
| T1543.003 Windows Service | Windows | Registry under HKLM\SYSTEM\CurrentControlSet\Services | Created with sc.exe, the registry or the API; malicious and vulnerable drivers loaded as services; services hidden from Get-Service and sc query by changing their SDDL with sc sdset |
| T1543.002 Systemd Service | Linux | .service unit files in system and user unit directories | New units, changed ExecStart, ExecStartPre, ExecStop or User directives, symbolic links, and units produced by systemd generators |
| T1543.004 Launch Daemon | macOS | /Library/LaunchDaemons and /System/Library/LaunchDaemons plists | Daemons need elevated rights to install and run for every user before login |
| T1543.001 Launch Agent | macOS | /Library/LaunchAgents, ~/Library/LaunchAgents plists | Plists using Label, ProgramArguments and RunAtLoad to start at login |
| T1543.005 Container Service | Containers | Docker or Podman daemon, kubelet, cluster workload specs | restart=always containers, privilege escalation through rootful Docker access, DaemonSets on all nodes, pods pinned with nodeSelector or nodeName |
Closely related techniques are T1569.002 Service Execution (starting a service to run code once) and T1574 Hijack Execution Flow, which covers weak service permissions and unquoted service paths. See the T1574 Hijack Execution Flow Defensive Guide.
Where it shows up
- Remote execution and lateral movement: tools that create a temporary service on a remote host to run a payload produce a burst of service installs across many hosts.
- Ransomware and EDR killing: drivers installed as kernel services to terminate security tools. See the Bring Your Own Vulnerable Driver and EDR Killers Guide.
- Linux cryptomining and botnets: ATT&CK lists groups such as TeamTNT and Rocke, which install systemd services to keep miners running.
- Targeted intrusions: ATT&CK also records the technique for APT41, Lazarus Group, Kimsuky, Wizard Spider and Scattered Spider among others.
- Clusters: DaemonSets give an intruder a container on every node and are a common route to node-level access. See the T1611 Escape to Host Defensive Guide.
Impact
- Privileged persistence: code runs as SYSTEM, root or a service account at every boot.
- Kernel access: driver services can disable security tools and hide activity as rootkits (T1014).
- Credential access: a malicious or modified service inherits the secrets of the account it runs as.
- Estate-wide reach: service creation through management tooling or DaemonSets affects many hosts at once.
- Hard eviction: hidden services, generator-created units and drop-ins that override legitimate units survive a superficial clean-up.
Detection
Windows service installation fields
Event 4697, "A service was installed in the system", is generated by the Audit Security System Extension subcategory. Microsoft's monitoring recommendations translate directly into rules.
| 4697 field | Values that warrant an alert | Why |
|---|---|---|
| Service File Name | Outside %windir%, Program Files and Program Files (x86); command interpreters, encoded arguments | Legitimate software installs to standard paths; logged as at creation time only |
| Service Type | 0x1 kernel driver, 0x2 file system driver, 0x8 recognizer driver | Rarely installed, start early and have broad operating system access |
| Service Start Type | 0 Boot, 1 System; 4 Disabled at install | Early start gives the widest control; a service installed as Disabled is unusual |
| Service Account | Anything other than localSystem, localService or networkService | A user account running a service needs review; if no account is given, LocalSystem is used |
| Subject | Accounts that do not normally install software, remote logons | Correlate the Logon ID with 4624 to find remote creation |
Other telemetry
| Platform | Source | What to alert on |
|---|---|---|
| Windows | System log 7045 (service installed); Sysmon 13 and 14 on the Services key | Changes to ImagePath, ServiceDll, FailureCommand or Start for existing services, which 4697 does not record |
| Windows | Sysmon 6 (driver loaded) and 1 | Unsigned or rarely seen drivers; sc.exe or PowerShell creating services from unusual parents; sc sdset on any service |
| Linux | auditd watches on unit directories, including /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, /usr/lib/systemd/system and /etc/systemd/user | New or changed .service files and .d/*.conf drop-ins outside package or configuration management activity |
| Linux | execve of systemctl enable, daemon-reload; children of PID 1 | Services enabled by web or application accounts; ExecStart pointing to /tmp, /dev/shm or hidden paths |
| Linux | User unit directories such as ~/.config/systemd/user | User services for accounts that should never have them, especially service accounts |
| macOS | Unified log and EDR file events on LaunchAgents and LaunchDaemons directories | New plists with RunAtLoad pointing to user-writable binaries |
| Containers | Docker daemon events; Kubernetes audit log | Containers created with restart policies plus privileged or host mounts; DaemonSet creation outside GitOps |
Metrics
- Coverage: share of Windows hosts with Audit Security System Extension enabled and of Linux hosts with unit directory audit rules.
- Baseline match: share of hosts whose service and unit inventory matches the approved build.
- Driver hygiene: number of driver installs per month and the share reviewed within 24 hours.
- Service identity hygiene: services running as user accounts with static passwords, trending down.
- Detection latency: time from a test service install to SOC alert in purple team exercises.
Prevention and hardening
ATT&CK maps nine mitigations to T1543, including M1018 User Account Management, M1022 Restrict File and Directory Permissions, M1026 Privileged Account Management, M1028 Operating System Configuration, M1033 Limit Software Installation, M1040 Behavior Prevention on Endpoint, M1045 Code Signing, M1047 Audit and M1054 Software Configuration.
| Control | How | Trade-off |
|---|---|---|
| Reduce who can install services | Fewer local administrators, LAPS, tiered admin accounts | Needs a supported route for software installs |
| Driver control | Microsoft vulnerable driver blocklist, application control policies that require signed drivers | Test in audit mode; some hardware vendors ship old drivers |
| Application control | Allowlist service binaries by publisher and path (M1033, M1045) | Highest prevention value, highest operational cost |
| Endpoint behaviour rules | EDR prevention for suspicious service creation and driver loads (M1040) | Tune for software deployment tools |
| Unit file integrity | Root-owned unit directories, configuration management as the only writer, FIM on drop-in directories | Package updates must be recognised as legitimate |
| Service sandboxing | systemd options such as NoNewPrivileges, ProtectSystem and dedicated User accounts | Limits what a modified service can do. See the systemd Service Hardening Guide. |
| Container runtime | Rootless runtimes, no Docker socket access for users, admission policies against privileged DaemonSets | See the Container Runtime Security Guide. |
Rollout
- Telemetry: enable Audit Security System Extension, collect 7045 and Sysmon 6, 13 and 14, and add auditd rules for every systemd load path on a pilot group.
- Baseline: export services, drivers, units and launch plists from gold images and production; give every non-standard entry an owner.
- Alert-only rules on the 4697 field values above and on unit drift, for two to four weeks while tuning deployment tools.
- Prevent: deploy the driver blocklist and application control in audit mode, then enforce by ring, starting with servers that change least.
- Roll back: keep the previous policy version deployable through the same management channel, and record each exception with an owner and expiry.
Small and large estates
Small organisations should enable the audit subcategory, alert on driver installs and services outside standard paths, and use the vulnerable driver blocklist. Large estates add application control for servers, automated baseline comparison, configuration-managed unit files and correlation of service installs across hosts, which exposes remote execution tools quickly.
Where identity fits
Every service runs as an identity: LocalSystem, a virtual account, a gMSA, a domain service account with a static password, or a dedicated Linux user. Static service account passwords are high-value targets and are often reused across servers. Prefer gMSAs and virtual accounts on Windows and dedicated, non-login users on Linux, record which identity each service uses, and alert when a service's account changes. After eviction, rotate the credentials of any account a malicious service ran as. See the Service Account Security Guide and the Linux Service Accounts and Keytab Management Guide.
Framework mapping
| Framework | Relevant items |
|---|---|
| MITRE ATT&CK v20 | TA0003, TA0004; T1543.001 to .005; related T1569.002, T1574, T1036.004, T1014, T1068 |
| MITRE D3FEND | D3-EAL Executable Allowlisting, D3-FIM File Integrity Monitoring, D3-PA Process Analysis |
| NIST SP 800-53 Rev. 5 | CM-7 Least Functionality, CM-11 User-installed Software, CM-3 Configuration Change Control, AC-6 Least Privilege, SI-4 System Monitoring |
| NIST CSF 2.0 | PR.PS-05 (unauthorised software prevented), PR.PS-01 (configuration management), DE.CM-09 (software and runtime environments monitored) |
| CIS Controls v8.1 | Control 2 Inventory and Control of Software Assets, Control 4 Secure Configuration, Control 8 Audit Log Management |
Common failure patterns
- Watching creation only: rules on 4697 and 7045 miss an intruder who repoints an existing, trusted service's binary path or DLL.
- Monitoring one systemd directory: auditing
/etc/systemd/systemalone misses drop-ins, runtime units, user units and generator output that systemd also loads. - Trusting the service name: allowlists keyed on names that imitate Windows or vendor components let masqueraded services through; key on signer, path and hash.
- Ignoring the service account: evicting the malicious service but leaving the static password it ran with unchanged leaves the intruder a credential.
- Driver installs treated as routine: kernel driver services are rare enough that every one deserves review, yet they are often filtered out as noise from hardware updates.
Practitioner checklist
- Enable Audit Security System Extension and alert on 4697 values for path, type, start type and account.
- Monitor the
Servicesregistry key for changes to existing services, not only new installs. - Alert on every kernel driver install and deploy the vulnerable driver blocklist.
- Audit all systemd unit and drop-in directories, including user and runtime paths.
- Keep unit files under configuration management and flag drift daily.
- Restrict Docker socket access and block privileged DaemonSets through admission control.
- Move services from static-password accounts to gMSAs, virtual accounts or dedicated users.
- Rotate the credentials of any account a malicious service ran as.
Standards and references
- MITRE ATT&CK: Create or Modify System Process (T1543)
- MITRE ATT&CK: Windows Service (T1543.003)
- MITRE ATT&CK: Systemd Service (T1543.002)
- MITRE ATT&CK: Container Service (T1543.005)
- Microsoft Learn: 4697 A service was installed in the system
- freedesktop.org: systemd.unit
- MITRE D3FEND: Executable Allowlisting
Related NHI Mgmt Group resources: Persistence Techniques Guide · T1053 Scheduled Task/Job Defensive Guide · T1547 Boot or Logon Autostart Execution Defensive Guide · Group Managed Service Accounts (gMSA) Guide · Linux Detection and Response Guide