Detecting T1569 System services

How T1569 System services shows up in intrusions and how to detect it

T1569 System services is an Execution technique (TA0002) that abuses the service managers built into operating systems to run adversary-controlled content. Its three sub-techniques cover Windows services, systemctl on Linux and launchctl on macOS, and each one turns a legitimate administrative mechanism into a way to start code under a service context. For a SOC lead, the difficulty is that the same events are produced by patching tools, configuration management and backup agents every day, so a detection that simply alerts on service creation or start will be noisy. The useful question is whether the service, its binary path, its account and its timing match an approved change. This page targets Enterprise ATT&CK 20.0. Confirm the sub-technique list, the data component references and the detection strategy identifiers against the version your SIEM rules cite, because ATT&CK releases can rename, deprecate or revoke techniques. The MITRE ATT&CK updates page lists the release history, and the enterprise-attack 20.0 STIX bundle in the mitre-attack/attack-stix-data repository is the machine-readable source for the mappings used here. Start the work with an inventory rather than a rule. Record which service managers your fleet uses, which accounts are permitted to create or modify services, and which software vendors install services as part of normal operations. Then build a baseline from your own Process Creation and Windows Registry Key Modification telemetry over a representative period. Confirm with your platform and endpoint teams which of these sources your agents actually collect, because coverage for service creation and unit file changes differs by agent and configuration.

Which telemetry reveals service-based execution

This table maps each telemetry source to the signal it can reveal for T1569 System Services and the open-source collector that gathers it. Read it as a coverage checklist: a row is only useful if the collector named in it is deployed on the hosts where services are created. Process Creation and service registration events carry most of the weight, with file and registry telemetry as supporting evidence.

Telemetry source	Signal to look for	Open-source collector
Process Creation (DC0032) on Windows	Service control utility or service host launched by an unexpected parent process, or a service started from an interactive user session	Sysmon or Windows event forwarding, read through the Wazuh agent
Windows Registry Key Modification	New service key created or an existing service's image path changed to point at a binary outside expected system directories	Sysmon registry events or Windows event forwarding, read through the Wazuh agent
File Creation (DC0039) on Windows	New executable dropped into a system directory shortly before a service is registered, especially with an unsigned or unfamiliar name	Sysmon file creation events, collected by the Wazuh agent
Process Creation (DC0032) on Linux	systemctl or init script invoked by a non-administrative account, or a service manager spawning an unexpected child shell	auditd rules forwarded to Wazuh, or osquery for process and launch state queries
File Creation (DC0039) on Linux	New or modified unit file in a system service directory, often followed by a daemon reload	auditd file watch rules or Wazuh file integrity monitoring
Process Creation and launch items on macOS	New launch daemon or agent property list written to a system launch directory, or a launchctl load outside change windows	osquery launchd tables, with the Wazuh agent for central review
Network Connection Creation (DC0082)	Service-launched process opening outbound connections it does not normally make, used only as added context	Zeek connection logs, where network context helps confirm a host-level finding
Parent-child relationship review	Service host or init process with an unusual parent, indicating a service was started from a user process rather than the service manager	Sysmon process trees or osquery process queries, correlated in Wazuh

Detection ideas for service creation and modification

Service creation and modification is where T1569 System services shows up most often in day-to-day telemetry. The ideas below pair each signal with the logic, the thresholds to tune and the benign activity that will trigger it, so analysts can separate change from abuse. Write each rule in Sigma, and name the ATT&CK version it targets so mappings stay correct across releases.

New service outside change windows

Alert when a Windows service is registered through the Service Control Manager, or when a new service-related registry key appears, outside an approved change window or outside the host's normal install schedule. Start with Process Creation and Windows Registry Key Modification telemetry, then join the event to your change calendar. Tune by host group, so domain controllers and jump hosts alert on any new service while build agents tolerate more churn. Expected false positives include software installers, endpoint agent updates and patch tooling that register services during maintenance. Confirm each exception against a named package or change ticket rather than a broad allowlist.

Service binaries in user-writable paths

Flag services whose image path points into user profiles, temporary folders, public download locations or other directories that standard users can write to. The check is on the ImagePath value and the file's location, and it should run both at service creation and on later registry changes to existing services. Set a short, explicit list of trusted service directories and alert on anything else. Expected false positives include legacy vendor tools installed under user profiles and per-user developer utilities, so record each one as a documented exception with an owner.

Service host spawning unexpected children

Monitor parent-child relationships where a service host process, such as services.exe or a svchost instance, starts a command interpreter, scripting engine or unfamiliar binary. Process Creation telemetry with parent image and command line fields gives the strongest signal. Tune by excluding known service-owned children and alerting on shells and script hosts first. Expected false positives include installers that run post-install scripts, backup and endpoint agents that call helper executables, and management tools that restart services with scripts. Ask each agent vendor which child processes its service is documented to start.

Linux unit files created by unexpected accounts

On Linux, watch for new or changed systemd unit files under system and user service directories, and for enable or start actions taken by accounts that do not normally administer services. File Creation and File Modification events on unit directories, combined with the account that made the change, are the core signals. Tune by allowing configuration management service accounts and package managers, and alert on unit files written by interactive users or by service accounts outside their role. Expected false positives include configuration management runs, container runtime setup and package upgrades that rewrite units. Confirm the expected writer for each host class before enabling the rule.

macOS launch item changes

Track creation or modification of launch daemon and launch agent property list files, and alert when a new item points to an executable outside standard application locations. Pair File Creation events on the launch directories with Process Creation of the loader that activates the item. Tune by hardware class and user role, since developer laptops change launch items far more often than managed kiosks. Expected false positives include endpoint management agents, software updaters and developer tools that register background helpers. Ask your MDM and endpoint vendors which launch items they install, and version those lists with the rule.

How to confirm the T1569 detection fires

This sequence proves, in a private cyber range, that the T1569 System Services detections fire on Windows, macOS and Linux with the expected telemetry and fields. It ends with a documented record of latency, alert quality and gaps that the security team can review before relying on the rules.

Agree scope and rules of engagement
The security lead, the SOC manager and the range operator agree in writing which platforms, hosts, accounts and time windows are in scope, and which actions the test harness may perform. They also name who can halt the exercise and how production systems are kept out of the run. The step is done when the signed scope document lists the Windows, macOS and Linux hosts under test and the ATT&CK version being validated, so every later result can be traced back to a defined boundary.
Prepare the approved test harness
The range team configures an approved emulation harness and confirms that it is allowed to create only benign, service-style artifacts on each platform, such as harmless named service entries or launchd and systemd unit files that point to inert test content. Each artifact is tagged with an exercise identifier so it can be found and removed afterward. The step is complete when the harness inventory lists every artifact type per platform and the cleanup procedure has been reviewed by the range owner.
Create benign service artifacts on each platform
The operator runs the agreed harness actions on each Windows, macOS and Linux host in the range, one platform at a time, and records the exact time and host for every action. The goal is to produce the activity the detection strategies describe, not to test any attack technique in the wild. The step closes when the exercise log shows a timestamped entry for every planned artifact on every host, with no unplanned changes outside the scope.
Confirm telemetry reaches the SIEM
The detection engineer checks that Process Creation, File Modification and Windows Registry Key Modification events (where the platform produces them) arrive in Wazuh or the chosen SIEM with the expected timestamps, host names and user context. Gaps in logging policy, agent health or parsing are logged as defects and fixed before rule testing continues. The step is done when every planned event type appears for every tested host, or when each missing source is recorded as a known gap with an owner.
Check each rule fires and fields populate
For each Sigma or native rule mapped to T1569 and its sub-techniques, the detection engineer compares the expected alert against what the SIEM produced. They confirm the rule fired once per planned artifact, that the required fields such as host, user, process, file path and service name are populated, and that no unrelated alerts were generated by the benign activity. The step closes with a rule-by-rule result sheet showing fired, not fired, or fired with missing fields for each platform.
Record latency, alert quality and gaps
The SOC analyst measures the interval between each artifact creation and the alert appearing in the SIEM, and rates each alert for clarity, context and triage usefulness. Any missing coverage, noisy false positives or unsupported platform is written into a gap register with a remediation owner. The step is complete when the report lists latency observations per rule and platform, the alert quality rating, and the open gaps, ready for review at the post-exercise meeting.
Clean up and state the validated scope
The range team removes every exercise-tagged artifact, confirms by inventory that the hosts match their pre-exercise baseline, and archives the logs and result sheets. The final report states that the detection is validated only for the platforms, rule versions and ATT&CK version that were tested, and that the detection must be retested after any change to the rules, platforms or ATT&CK release. The step is done when the cleanup checklist is signed and the validated-scope statement is attached to the detection record.

Preventive controls that limit service abuse

Two MITRE ATT&CK mitigations shape who can install or change system services. The cards below explain how User Account Management and Privileged Account Management reduce exposure to T1569 System Services, where they overlap, and how to confirm they work on Windows, macOS and Linux.

User account management (M1018)

User Account Management (M1018) covers how accounts are created, modified, granted rights and removed. For T1569 System Services, the practical question is which standard accounts can register a new service, change an existing service path, or alter a startup script. Review those rights on Windows service permissions, systemd unit directories and launchd locations, and remove write access that business users do not need. Confirm that removed or disabled accounts also lose the ability to start and stop services.

Privileged account management (M1026)

Privileged Account Management (M1026) governs administrators, service accounts and other elevated identities. Creating or reconfiguring a system service on most platforms requires administrative or root rights, so controlling who holds those rights largely controls who can use T1569 System Services at all. Check that elevated sessions are granted only when needed, that privileged credentials sit in a controlled vault, and that shared administrator accounts are replaced by named accounts that can be traced.

Overlap with privilege controls

The two mitigations overlap heavily in practice. Most service changes are gated by local administrator or root membership, so a standard account quietly added to an administrators group undoes M1018 without anyone noticing. Review membership of the Windows Administrators group, sudo rules, polkit policies and macOS administrative groups together, and treat any change to them as a privileged event. Ask your platform team which group actually controls service configuration in each part of your estate.

Logging administrative change

Preventive controls can fail quietly, so pair them with records of who changed service configuration. Creating a service, editing a unit file or modifying a service registry key should produce an event tied to a named account and a process. Confirm that Windows audit settings record process creation and registry changes, that Linux audit rules cover unit file directories, and that macOS daemon and launch agent changes reach your central collector. These records feed the detections described on this page.

Platform-specific ownership checks

Each operating system keeps service definitions in different places, so a single policy needs platform-specific checks. On Windows, look at the services registry branch and the binaries they point to. On Linux, check unit files and drop-in directories. On macOS, check launch daemon and launch agent folders. Verify file ownership and write permissions on these locations in each build baseline, and alert when they drift from the approved state.

Validate controls in the range

Controls are only trusted after they have been tested. In a private cyber range, sign in with a standard test account, attempt to install a service, and confirm the attempt is denied and logged. Repeat the exercise with a privileged test account to confirm the expected change is recorded with the right identity. Keep the results with your change records so reviewers can see the control was tested in the range and not only described in a policy.

Triage steps when a service alert fires

Start by answering one question: is this service change authorized? Compare the alert against change records, maintenance windows and the deployment tool's history before anyone touches the host. A new or modified service that matches an approved change can be closed with a note. A service created outside any change window, or by an account with no ticket behind it, moves to active investigation. Record the service name, the host, the time of the event and the account recorded in the Windows Service Control Manager event or the systemd unit history, because those four facts drive every later step. Confirm the exact source of the alert too, since a rule keyed on a service name can fire on a legitimate installer that happens to use a common name.

Next, establish who and what. Identify the account that created or changed the service and whether it is a named administrator, a service account or a shared credential, then check whether that account logged on to the host around the event. For the binary or unit file, look at the image path or ExecStart value, the file's hash, its signature or package owner, its creation time and the directory it lives in. A service pointing to a user-writable location, a temporary folder or an unsigned binary with no package owner needs immediate escalation. Check the parent process that launched the service change, and review network connections the new service opened within minutes of starting. Note that these checks depend on the telemetry you actually collect, so confirm which data sources your Wazuh or Security Onion deployment records for this host before relying on them.

Then scope and contain. Search the fleet for the same service name, the same image path and the same file hash, since an attacker who reuses tooling tends to repeat it on neighboring systems. If the change is unauthorized, isolate the host through your endpoint or network controls, disable the service only after its binary, unit file and memory state are captured, and revoke or rotate the credentials the account used. Preserve evidence first: export the event logs, copy the binary and unit file to a case store with hashes recorded, and capture volatile data where your procedure allows. Escalate to incident response as soon as the change is unauthorized, the binary is unknown, or the same service appears on more than one host. Confirm your escalation thresholds and evidence handling steps with your incident response team in advance.

Rehearsing T1569 detection in a private cyber range

The Windows range should mirror the production domain layout as closely as the agreed scope allows, including a domain controller, a representative member server and a workstation with the same audit policy, Sysmon configuration and forwarding path used in production. Service-based execution on Windows is most often visible through service creation and configuration changes, so the range needs the Windows Registry, Process Creation and service control events to reach the SIEM with the same fields and timestamps as production. Injects should use approved benign artifacts, such as a signed test binary registered as a service in an isolated VM, so the exercise produces realistic telemetry without any real malicious payload.

Environment parity: Confirm that the same audit subcategories, event channels and Sysmon rules that run in production also run in the range, or document every difference.
Benign service injects: Use an approved test service that a scripted change registers, starts and removes, so the event trail matches the expected service lifecycle.
Detection expectation: An alert should fire in the agreed window, be enriched with the host, account, parent process and service path, and be triaged by the analyst on duty.
Response expectation: The team should scope other hosts that received the same service change, contain the affected endpoint through the agreed process, and record the lessons learned.
Log integrity check: Verify that timestamps, host names and account names match across the endpoint, domain controller and SIEM before scoring the exercise.

Before each run, ask the platform owner to confirm which Windows audit settings and Sysmon version are deployed in production, so the range reflects them.

Questions SOC leads ask about T1569 detection

How do I separate legitimate service installers from malicious service creation?

Start by building an allow list of known installers, management agents and software deployment paths, then alert on service creation that falls outside it. Legitimate installs usually come from a small set of signed binaries, run under change windows, and create services with predictable names, paths and accounts. Suspicious creation tends to involve service binaries in user-writable folders, unsigned executables, unusual parent processes, or service accounts that do not match the host's role. Correlate the service creation event with the process that requested it and with recent change tickets. Tune in a test range first, because each environment's installers differ, and document every exception with an owner and a review date.

Which logs do I need for T1569 detection on Linux and macOS?

On Linux, the core sources are process execution auditing, systemd unit activity and journal logs, plus file creation and modification events under unit directories such as the systemd configuration paths. On macOS, collect unified log entries for launchd activity and file events for the launch daemon and launch agent folders. Add authentication logs so you can see which account started or changed a service. Map these sources to the ATT&CK data components referenced for this technique, such as Process Creation and File Creation, and confirm that your agents actually capture them on each operating system version in your fleet. Ask your platform team to verify retention, because short retention windows defeat slow-moving investigations.

How often should I retune T1569 detection rules?

Retune after every significant change to your software deployment pipeline, endpoint agent set or service baseline, and also on a fixed review cycle set by your detection governance process. Review the alert volume, the false positive list and the allow list at least each quarter, and recheck them after major operating system or agent upgrades. Keep a change log for each rule so you can explain to auditors why a threshold or exception exists. Testing is the step most often skipped, so run every change against replayed or simulated telemetry in a cyber range before it reaches production.

How do ATT&CK version changes affect T1569 mappings?

ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques, and version 18 replaced technique-level detections with detection strategies and analytics, so mappings written against older material may need rework. Record the ATT&CK version each detection targets, and check the release notes for the versions you use. For this technique, confirm the sub-technique list and the referenced data components in the Enterprise ATT&CK STIX bundle for the version you have adopted. When a new release arrives, diff your coverage map against it, update the mapping record and re-validate any rule whose underlying technique changed. The ATT&CK updates page lists each release, which is the natural starting point for that review.

How can I test T1569 detections without disrupting production services?

Test in a private cyber range that mirrors your production operating systems, agents and service baselines, and keep the simulated activity isolated from production networks. Use controlled, pre-approved test services that create and modify service records in the same way your monitored hosts would, and replay recorded telemetry where a live test is not appropriate. Define success criteria before each exercise, including expected alerts, expected false positives and the response steps your analysts should take. Record the results so each rule has evidence of validation. Production validation should be limited to passive checks, such as confirming that expected log sources are arriving, unless your change process explicitly approves more.

Can my own team handle T1569 detection, or do we need outside help?

Many SOC teams can run the detection work in-house once they have the log sources, an allow list process and a repeatable test method. The work splits into three parts: building and tuning rules, validating them in a range, and maintaining mappings as ATT&CK changes. Teams with limited Linux or macOS telemetry, or without a test environment, often find the first sprint hardest. DeployOpen can plan, implement and document these controls as a fixed-scope engagement with written deliverables, or support them through a retainer. Ask any provider to confirm which operating systems, agents and data sources are in scope before agreeing on deliverables.

Keeping T1569 detections accurate over time

Pin every T1569 detection to a named ATT&CK version and review it at each release. ATT&CK v18, released October 28, 2025, replaced detections on technique pages with detection strategies and analytics, updated data components and deprecated some data sources, so a rule written against older mappings may cite a data component that no longer maps the way the rule assumes. Record the version in the rule metadata, for example in a attack.version field or a comment in the Sigma rule, and compare each new release against the T1569 entries and its sub-techniques, T1569.001, T1569.002 and T1569.003. Confirm the exact changes for v19, released April 28, 2026, and v20, released October 13, 2026, in the ATT&CK updates page before you rebase anything, because releases can rename, deprecate or revoke techniques.

Baseline legitimate service changes on each platform before you tune alerts. On Windows, the service control manager and Registry Key Modification events under the services hive produce routine noise from software installers, driver updates and endpoint agents, so build an allow list by publisher, install path and parent process rather than by service name alone. On Linux, record the unit files managed by systemd and the service definitions under the init directories that your configuration management tool writes, and separate package-manager activity from manual edits. On macOS, catalog the launch daemons and launch agents placed by MDM profiles and vendor installers. Store each baseline in version control with an owner and a review date, so that a change in the baseline is itself reviewable.

Schedule a monthly false positive review and a quarterly log coverage check. In the monthly review, sample the alerts that were closed as benign, group them by host role and change window, and decide whether each allow list entry is still justified. In the quarterly check, confirm that Process Creation, File Modification and Windows Registry Key Modification telemetry still reaches Wazuh or your SIEM from every host class, including servers that were added or rebuilt since the last check, and that the agents have not been silently disabled. Re-run a cyber range scenario for each platform after material changes, and keep the results with the rule history. Ask your auditors and internal risk owners which evidence format they expect for this review cycle before you finalize the schedule.

How DeployOpen builds T1569 detections and range scenarios

DeployOpen approaches T1569 System services as a written, fixed-scope engagement inside the client's own infrastructure. The work turns the technique's sub-techniques and platform coverage into detections, range scenarios and handover documentation that the client's own team can run and maintain.

How we scope

Confirm which platforms are in scope for T1569, including Windows, macOS and Linux hosts and the sub-techniques that apply to each.
Map available telemetry such as Process Creation, File Modification and Windows Registry Key Modification to the client's existing logging pipeline.
Record the ATT&CK version the detection mapping targets so later releases can be compared against it.

How we build

Write detection logic in open-source formats such as Sigma rules, then translate it for the client's SIEM or Wazuh deployment.
Set up the telemetry sources needed for service creation, service configuration changes and service-driven process launches on in-scope hosts.
Build a private cyber range scenario that exercises each in-scope sub-technique against test endpoints, with expected alerts defined in advance.

How we hand over

Deliver the detection rules, tuning notes and known false positive sources, such as legitimate software installers, in a documented format.
Provide the range scenario runbook, including expected telemetry, pass and fail criteria and cleanup steps for each exercise.
Document how the mitigations User Account Management and Privileged Account Management map to the client's account and service controls.

How we support

Run a validation review with the client's detection and response team to confirm alerts fire and triage steps work as written.
Offer ongoing support, detection updates and continuous testing as a retainer when the client wants changes tracked over time.
Confirm with the client's own environment and vendor documentation which logging and agent capabilities are available before committing to a scenario.

T1569 System services