How T1547 boot or logon autostart execution keeps an intruder in place
When an intruder already has a foothold, the question for the SOC lead is whether that access survives a reboot or a user logon. T1547 Boot or logon autostart execution is the MITRE ATT&CK technique that answers that question for the adversary: it describes configuring a system so that code runs automatically when it starts or when someone signs in, without the intruder needing to be present. The technique sits under the Persistence tactic, TA0003, which ATT&CK defines as the adversary trying to maintain their foothold. This page targets Enterprise ATT&CK version 20.0, and T1547 covers 14 sub-techniques spanning Windows, Linux, macOS and network devices.
Autostart mechanisms show up across intrusions because they are built into the operating system and are used legitimately every day, so a foothold can be re-established without the attacker repeating its initial access. Defenders see the effects as changes to startup locations, service or login configuration, and recurring execution that begins shortly after a restart or a new session. Because the list of places to check differs by platform, the first decision is scope: which of your Windows, Linux, macOS and network device fleets are in the detection and response plan, and who owns the baseline for each. Confirm that version 20.0 is the ATT&CK release your detection mappings reference, since releases can rename or deprecate techniques and sub-techniques.
The practical check for the SOC lead is whether you can list, for each in-scope platform, the autostart locations that are expected to change and the ones that should never change without a change ticket. Ask your endpoint and log platform vendors which of these locations they collect by default and which need explicit configuration, and record the gaps as risks. The MITRE ATT&CK tactic page for Persistence is the natural starting point for mapping those gaps to the sub-techniques your environment can actually observe.
Which telemetry reveals autostart persistence and which open-source tool collects it
This table maps the data components ATT&CK uses for autostart persistence to the telemetry they produce, the open-source collectors that gather them, and their blind spots. Read each row as a question to answer for your own estate: can we see this source, and what would it miss? Data component IDs are used because data source names were deprecated in ATT&CK v18.
| Data component | What it reveals for T1547 | Open-source collection | Blind spots |
|---|---|---|---|
| Process Creation (DC0032) | Processes started by logon or boot helpers, such as shell profile loaders, service launchers and login hooks, including parent-child relationships | Wazuh agent on Linux, macOS and Windows; Sysmon-style Windows event collection; auditd execve rules on Linux | Misses activity that runs in-process, from a trusted signed binary, or where command-line auditing is disabled |
| File Modification (DC0061) | Changes to autostart locations such as init scripts, cron or systemd unit directories, login item stores and Startup folders | Wazuh syscheck (FIM) on monitored paths; auditd file watch rules; Velociraptor artifacts that hash or list autostart paths | Scheduled scans miss short-lived changes; attribute-only or timestomped edits may not alter content hashes |
| File Creation (DC0039) | New files dropped into autostart directories, including new unit files, launch agents and Startup shortcuts | Wazuh FIM with real-time monitoring enabled; Sysmon file create events on Windows; auditd on Linux | Does not show what the file does; files created outside monitored paths or on unmanaged hosts are not seen |
| Windows Registry Key Modification (DC0063) | Writes to Run, RunOnce and Winlogon-related keys that trigger execution at logon | Sysmon registry events forwarded to Wazuh; Velociraptor registry artifacts for point-in-time review | Requires configured registry auditing scope; only covers Windows, and key coverage depends on the Sysmon configuration in use |
| Application Log Content (DC0038) | Evidence from network device and application logs, such as configuration change messages on routers, switches and firewalls | Syslog forwarding into Wazuh; Zeek or Suricata for network-observable configuration traffic where protocols are visible | Depends on the vendor logging level and retention; many devices do not log autostart-style configuration changes by default |
| Network device configuration logs (illustrative mapping) | Changes to boot scripts or startup configuration on network platforms, which ATT&CK places under Network Devices | Syslog and configuration backup comparison collected by Wazuh; Zeek or Suricata for management-plane traffic where visible | Vendor-specific formats; confirm with the device vendor which configuration events are emitted |
Detection logic for autostart changes on each platform
Autostart detection works best when each platform's persistence points are mapped to a specific change signal and a known baseline. The cards below describe the logic for Windows, Linux, macOS and network devices, along with the tuning and false positive sources that analysts should expect on each.
Windows run keys and service autostart
Run-key and service-related autostart locations are written by installers, updaters and management agents as well as by adversaries, so raw change events are noisy. Alert on new or modified entries in these locations where the writing process is not a signed, known installer or the configuration management agent. Tune by building an allowlist per fleet image and reviewing new publishers weekly. Expect false positives from software updaters and endpoint agents that rotate their own entries. Pair new autostart entries from unsigned or unfamiliar binaries with process creation telemetry to see what launched first.
Linux init and systemd changes
Persistence on Linux usually appears as a new or modified init script, systemd unit, timer or login hook created outside package manager activity. Watch file creation and modification in the standard unit and init directories, and correlate with the package database and change management tickets. Tune by suppressing changes made during scheduled patch windows and by alerting on units that run from temporary or user-writable paths. Configuration management runs are the most common benign source, so record the agent identity on every change so analysts can separate it quickly.
macOS login and launch items
On macOS, login items and launch agents and daemons are the main autostart points. Detection logic should flag new property list files in these locations, especially those that reference executables in user-writable directories or that are unsigned. Set thresholds so that a single new item on a managed Mac triggers review, while mass changes across a fleet trigger a higher severity. Common false positives include productivity suites, VPN clients and endpoint security tools that register their own launch items during updates. Confirm the expected list of items per device group before go-live.
Network device startup configuration
On routers, switches and firewalls, the equivalent autostart is the startup configuration, scheduled scripts and boot-time commands. Detect changes by comparing configuration hashes and version counters against an approved baseline, and alert when the startup configuration differs from the running configuration without a matching change record. Tune by setting a short review window after approved maintenance and by grouping devices by role. Firmware upgrades, automated backup jobs and configuration templating produce expected changes, so tag those events before they reach analysts.
Cross-platform false positive sources
Software updaters, installers, configuration management runs and scheduled backups account for most benign autostart changes on every platform. Build a shared suppression register that records the process, signer, host group and change window for each known source, and review it at each quarterly change cycle. Keep suppressions narrow so that a trusted updater that starts writing from an unexpected path still alerts. Ask your vendor and your SOC to confirm which change sources they log by default before you rely on this register.
How to confirm the autostart detection fires before you trust it
This sequence proves that a T1547 detection produces the expected alert, fields and timing in a controlled environment before anyone relies on it in production. It turns a rule that looks correct on paper into evidence that the telemetry actually arrives and the alert is actionable.
Agree the lab scope in writing
The detection owner, the platform team and the cyber range lead agree in writing which non-production host will be used, which autostart locations are in scope and which sub-techniques the test covers. The agreement also names who may make the test change, who watches the alert queue and how the test is stopped. The step is done when all three parties have signed off the scope document and the host is confirmed as isolated from production identity, backup and logging paths.
Map expected telemetry to each data component
Before any change is made, the team writes down what each relevant data component should show for the chosen autostart location. Process Creation, File Modification and File Creation are the usual starting points for T1547 on Linux, macOS and Windows, and Windows Registry Key Modification applies where the chosen location is a registry run key. For each one, the expected event source, the host it should come from and the fields that must be present, such as the actor, the target path and the time, are recorded. The step closes when this expectation table is reviewed by the detection engineer and stored with the test plan.
Tag the detection to ATT&CK 20.0
The detection rule is recorded with the ATT&CK version it targets, which for these pages is Enterprise ATT&CK 20.0, along with the technique and sub-technique IDs it claims to cover. The team checks the current technique page for T1547 and the relevant sub-technique in that version, because releases can rename, deprecate or revoke techniques. The step is complete when the rule metadata names the version, the IDs and the data components it depends on, and that record matches the mapping in the detection inventory.
Run the benign autostart change
A named tester makes a harmless, pre-agreed change to one autostart location on the non-production host, such as a marker entry that does nothing when the system starts. The change time, the account used and the exact location are logged by the tester in the test record, not left to memory. The step is done when the change is confirmed on the host by a second person and the time window is noted so that telemetry can be matched to it later.
Measure time to alert and field completeness
The team compares the events that arrived in the SIEM or Wazuh manager against the expectation table from the earlier step. They record the time between the change and the alert, whether each expected field was populated and whether any fields were empty, renamed or parsed incorrectly. Gaps between the log source and the detection are noted separately from gaps in the rule logic. The step closes when a completed results sheet exists for each data component, with a clear pass or gap note.
Record false positives from normal activity
The rule is run over a defined baseline period on the same host class, including routine software updates, administrator logins and legitimate startup entries, to see what else it fires on. Each alert is classified as a true test hit, a benign match or an unexplained match, and the benign matches are grouped by cause. The team states the false positive rate in terms of its own sample, not as a general figure. The step is done when the classifications are reviewed and each recurring benign cause has either an approved exclusion or an open tuning item.
Revert the change and verify cleanup
The tester removes the benign autostart entry and the team checks that the host returns to its baseline state. They confirm that the removal itself generated the expected telemetry and that no leftover file, registry value or service entry remains. Any residue is recorded as a finding against the test, not quietly fixed. The step is complete when the cleanup check is signed and filed with the test record.
Tune, then re-test under the same version tag
Changes to the rule, field mappings or exclusions are made only after the results review, and each change is recorded against the ATT&CK 20.0 tag. The original benign change is replayed on the same host so the team can compare before and after results, and the baseline false positive sample is run again. The sequence is considered finished when the re-test shows the expected alert with complete fields and the revised benign match count is documented, and the detection is only moved to production after that evidence is accepted.
Preventive controls that shrink the autostart attack surface
Autostart persistence depends on an attacker being able to write somewhere the operating system will later read and run. The controls below work on that condition from different angles: who holds privileged rights, which locations are writable, what gets logged, which software is allowed to run, and who owns each setting. Confirm each mapping against the ATT&CK STIX bundle for the version you target, because sub-technique coverage varies.
Disable or remove unneeded features
Mitigation M1042 reduces the number of mechanisms that can launch code at boot or logon. Remove or disable services, startup hooks, login extensions and scheduled initializers that the business does not need, then record what remains as the approved baseline. Ownership sits with the platform team for servers and images, and with endpoint management for workstations. Check that the baseline is reviewed whenever a new platform component is adopted, since each one can add an autostart path.
Limit privileged account use
Mitigation M1026 matters because many autostart locations, such as system-wide services and boot configuration, require administrative rights to change. Restrict those rights to named administrators, separate administrative accounts from daily user accounts, and require approval for changes to system-level startup. Review who holds local administrator and root rights on each platform, and confirm that the owner of the identity system, not the application team, controls those grants.
Audit autostart configuration changes
Mitigation M1047 is the control that turns a silent change into a reviewable event. Enable auditing on the autostart locations that matter for your platforms, such as service definitions, run keys, init files and login item lists, and forward those events to your monitoring stack. The security operations team owns the audit policy and retention, while system administrators own the local configuration. Confirm that audit settings survive image rebuilds and that the logs cannot be altered by the accounts being monitored.
Restrict file and directory permissions
Mitigation M1022 limits who can write to the directories and files that the operating system or a service reads at startup. Set ownership so that only administrative or service accounts can create or modify entries in boot and logon paths, and remove write access for ordinary users and broad groups. Ownership belongs to the system administrators, and the access model should be documented per platform. Verify permissions with an automated baseline check rather than relying on the original build.
Manage user account lifecycle
Mitigation M1018 addresses the account side of autostart persistence. Accounts that can write to startup locations, or that run services at logon, should be created through a controlled process, reviewed on a schedule, and removed when people change roles or leave. Identity and access management owns provisioning and deprovisioning, and the application owners confirm which service accounts need which rights. Ask whether dormant or shared accounts exist on the platforms in scope.
Enforce code signing on startup binaries
Mitigation M1045 helps the operating system or an endpoint control refuse to run unsigned or altered code at boot or logon. Define which publishers and signing authorities are trusted for startup components, enforce the policy where the platform supports it, and treat any exception as a documented risk with an owner and expiry. Code signing policy is typically owned by the security team with input from the software packaging team. Confirm with each vendor which startup components are signed and how signature validation is enforced on your versions.
Triage steps when an autostart detection fires
The first goal of triage is to decide whether the autostart change is a sanctioned modification or an adversary keeping a foothold. Start by confirming the artifact still exists and still points where the alert says it does, because autostart entries are often short-lived or rewritten by the software that created them. Then compare the entry against the change calendar and your configuration management baseline for that host group. If a deployment, patch window or package update explains the change, record the change identifier and close the alert with that evidence attached. If no approved change matches, treat the entry as suspicious until proven otherwise, and identify the account that made the change, the host, the time window and the parent process or session that wrote it.
Preserve the artifact and its context before anyone edits or removes it. Capture a copy of the autostart file or registry value, its hash, owner, permissions and modification times, along with the surrounding logs for the same session. On Linux, that usually means the systemd unit, cron entry or profile script and the related audit records. On Windows, it means the Run key or scheduled task definition and the process creation events that wrote it. Scope the search by looking for the same file path, key name or hash on other hosts managed under the same image or configuration policy. Keep your queries read-only at this stage. Avoid rebooting the host or running clean-up scripts, since both can erase the state you need to explain how the entry was created. Avoid tipping off the actor by keeping investigative activity quiet and on channels the suspected account cannot see. Restrict who knows about the alert, use an out-of-band channel for coordination, and avoid sending broad notifications to the owners of the affected host. Decide on containment in advance: isolating the host at the network layer or restricting the suspect account may be appropriate when the change is unexplained and the account is shared or privileged, but confirm the playbook owner and the decision authority first. Hand off to incident response as soon as the change is unexplained and touches a privileged account, a server or a host holding regulated data, or when lateral activity appears in the scoping results. Confirm your own escalation thresholds and retention periods with your incident response team.
Rehearsing T1547 detection in a private cyber range
The Windows range should include a small domain with a domain controller, a few workstations and a server, each forwarding Sysmon-style process creation and registry or file events to a Wazuh or Security Onion collector. Place the range on an isolated segment with no route to production, and snapshot every host so each exercise starts from a known state. Schedule benign injects that touch the same autostart surfaces an adversary would, such as a sanctioned software update that writes a Run key, a scheduled task created by an administrator, and a startup folder change made by a help desk script. These injects test whether analysts can separate routine change from suspicious change.
- Telemetry coverage: Confirm that registry value writes, new scheduled tasks and startup folder file creations reach the SIEM with the parent process, user and command context intact.
- Alert window: Agree in writing the time within which an alert must reach the queue after an inject, and record misses as findings.
- Context quality: Check that each alert names the autostart location, the writing process, the account and the host, so the analyst does not need to pivot to answer the first question.
- Triage handoff: Verify that the alert reaches the on-call responder with a ticket that lists the evidence and the suggested next step.
- Response: Rehearse isolating the host, reviewing the autostart entry, and restoring the benign state, then confirm the timeline is recorded.
Before the exercise, ask the range provider to confirm which Windows event sources are enabled by default and which need configuration.
The Linux and macOS range should mirror the production mix, with a few Linux servers running systemd and cron, and a macOS workstation that uses launch agents and login items. Forward authentication logs, audit records and file integrity events to the collector, and keep a file integrity baseline on the autostart directories so changes are visible. Benign injects can include a package install that adds a service unit, a developer who adds a login item, and a configuration management run that rewrites a boot script. These show the analysts what normal change looks like on each platform before any hostile-looking change appears.
- Telemetry coverage: Confirm that changes to the service manager configuration, cron tables, shell profile files and macOS launch directories generate events the SIEM can read.
- Alert window: Agree in writing the time from inject to alert, and track any exercise where the platform produced no signal.
- Context quality: Check that the alert identifies the unit or agent name, the file path, the writing user and the process that made the change.
- Triage handoff: Confirm the handoff includes the host owner, the change record if one exists, and a clear question for the application team.
- Response: Rehearse disabling the entry, preserving a copy of the file for review, and checking whether the same change appears on other hosts.
Ask the platform team to confirm which audit rules and file integrity tools are in use, since coverage on these hosts often depends on local configuration.
The network device range should include a representative switch or router, a firewall, and a syslog or flow collector, all in a lab segment with management access restricted to the range team. Autostart on network devices usually means startup or boot configuration, scheduled jobs, or image and firmware loading, and the vendor documentation determines which of these can be observed. Benign injects might include a planned configuration save, a scheduled backup job, and an authorized firmware staging step. These let responders see how legitimate boot-time changes appear in logs and configuration backups.
- Telemetry coverage: Confirm which configuration change logs, syslog messages and configuration archive events the device can emit, and whether they reach the collector.
- Alert window: Agree in writing the time from inject to alert, and note whether detection depends on a backup comparison that runs on a fixed schedule.
- Context quality: Check that the alert shows the device, the changed configuration element, the administrator account and the source address of the session.
- Triage handoff: Confirm that the network team receives the configuration diff, the change window and the peer device comparison in one ticket.
- Response: Rehearse restoring the known good configuration from a verified backup and confirming the restored state matches the baseline.
Before the exercise, ask the device vendor or your network team to confirm which boot-time and startup configuration events are logged, because capability varies by platform and version.
Questions SOC leads and detection engineers ask about T1547
How do I separate autostart changes from normal patching?
Tie every autostart change to a known change record, and filter the rest by who made it and through which process. Patching tools, configuration management and package managers write to many of the same locations that adversaries use, so a file change alone is a weak signal. Build an allowlist of expected writers by host group, record the parent process and the package or patch identifier, and alert only when a new autostart entry appears outside an approved maintenance window or comes from an unexpected parent. Confirm with your patch and configuration tooling which artifacts it generates, because those names change between product versions.
What should I do about sub-technique coverage gaps in T1547?
Map each of the 14 sub-techniques to the telemetry you actually collect, then rank the gaps by what your estate runs. T1547 spans Linux, macOS, Windows and network devices, so a single data source rarely covers it. Start with the platforms and sub-techniques that matter most to your environment, document which ones have no visibility, and record the compensating controls, such as file integrity monitoring on autostart paths or periodic configuration baselines. Gaps you accept should be written down with an owner and a review date, not left implicit.
How should I version detections when ATT&CK changes?
Record the ATT&CK version each detection targets and review mappings whenever MITRE publishes a release. ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques, and v18 changed how detections are described by moving to detection strategies and analytics. Keep detection content in version control, tag each rule with the ATT&CK version it was written against, and diff the Enterprise STIX bundle for each new release to find affected IDs. Confirm the current release and its changes on the ATT&CK updates page before you start a review.
Which data components should I prioritize for T1547 detection?
Prioritize Process Creation and File Modification, then File Creation and Windows Registry Key Modification where Windows hosts are in scope. ATT&CK detection strategies for Persistence techniques most often reference Process Creation (DC0032), Command Execution (DC0064), File Modification (DC0061), File Creation (DC0039) and Windows Registry Key Modification (DC0063). Process Creation shows who wrote an autostart entry, File Modification shows what changed, and registry telemetry covers Windows run keys and services. Confirm which of these your agents and log pipeline actually emit before writing rules that depend on them.
How can I test T1547 detections without affecting production?
Replay the detection in a private cyber range that mirrors your build images, logging pipeline and agent versions. Use a controlled, approved exercise plan that describes the expected telemetry, the detection that should fire and the response steps, without running anything on production hosts. Measure whether the expected events arrive in your SIEM, whether the rule matches them, and whether the alert reaches the right queue. Keep a record of each test, then rerun the same set after every rule change or agent upgrade so regressions surface early. DeployOpen designs and runs these exercises in client-controlled environments as part of its security testing and cyber range work, with scope agreed in writing before work starts.
Can my own team build T1547 detection without outside help?
Yes, many teams can build a baseline themselves if they have engineers who know their operating systems and logging stack. The work breaks into three parts: confirming telemetry coverage, writing and tuning rules, and rehearsing response. Teams usually struggle most with the first and third parts, because coverage depends on agent configuration across many host types and rehearsal needs a safe environment. Ask whether your team has time for ongoing tuning, since rules need review after each ATT&CK release and each platform upgrade. A fixed-scope engagement can cover a defined set of platforms and sub-techniques, with deliverables agreed in writing before work starts.
What does ongoing T1547 detection work cost to maintain?
Cost depends on the number of platforms, the telemetry you already pay for, and how often your estate changes. The one-time parts are initial coverage mapping, rule development and the first cyber range rehearsal. The recurring parts are rule tuning, ATT&CK version reviews, agent and log pipeline upgrades, and periodic exercises. Costs rise with more operating systems, more sub-techniques in scope and stricter evidence requirements. When requesting a quote, ask for the platforms and sub-techniques covered, the telemetry assumed, the number of exercises and whether ongoing support is included. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen builds T1547 detections and range scenarios
DeployOpen plans T1547 Boot or logon autostart execution detection work as fixed-scope engineering on the client's own stack, with the scope, deliverables and timelines agreed in writing before any work starts. The first step is an inventory of where autostart mechanisms actually matter in the environment: Linux systemd units and cron entries, macOS launch agents and daemons, Windows Run and RunOnce registry keys and startup folders, and any network device configuration that reloads at boot. The team then confirms which of those sources the client already collects, such as Process Creation, File Creation, File Modification and Windows Registry Key Modification, and where the Wazuh, Security Onion, Zeek or Suricata pipeline has gaps. Clients should confirm log retention, time synchronization and ownership of the detection rules before the scope is signed, because those decisions determine whether an autostart alert can be investigated at all.
Detection content is then written against the ATT&CK version the client targets, since releases can rename or deprecate sub-techniques. Each rule is tested on the client's own telemetry, tuned for known administrative tasks such as software updates and configuration management runs, and documented with its data sources, false positive notes and response steps. DeployOpen runs purple team exercises against scenarios the client approves in advance, so the blue team sees the expected telemetry and the red team stays within agreed boundaries. For rehearsal, DeployOpen builds private cyber range scenarios that recreate autostart persistence on representative Linux, macOS and Windows hosts, which lets the client test alerts, triage and containment without touching production systems.
Evidence produced during this work, such as rule inventories, test records, exercise reports and change logs, is prepared for independent auditors, who decide what it proves. DeployOpen does not issue audit reports or certifications. Because autostart locations drift as software and administrators change, DeployOpen offers ongoing tuning as a retainer, covering rule review, new scenarios and re-testing after major platform upgrades. Clients should ask for a written list of deliverables, the ATT&CK version used, and the criteria that end the fixed-scope phase before signing.
