How T1037 boot or logon initialization scripts keep attackers in place
When a foothold is confirmed, the first question for the SOC lead is whether it survives a reboot or a fresh logon. MITRE ATT&CK technique T1037, Boot or logon initialization scripts, answers that question for an attacker by running a script each time a system starts or a user or device signs in, so access returns without a new exploit. ATT&CK files this technique under the Persistence tactic, TA0003, which it defines as "The adversary is trying to maintain their foothold." The mapping in this section targets Enterprise ATT&CK version 20.0, so every detection and rule reference should name that version.
T1037 has five sub-techniques, and each one uses a different place that an operating system or platform reads at startup or sign-in. At a high level, they cover logon scripts on Windows, login hooks on macOS, network logon scripts, legacy run-control scripts on Unix-like systems and startup items. ESXi and network devices follow the same pattern, where a startup configuration or boot file plays the role of the script. In intrusions, this technique usually appears after initial access has already succeeded, often on shared workstations, jump hosts or older servers where administrators have added scripts by hand over time. Confirm which of the five locations on your affected hosts were changed, because that answer shapes the rest of the response.
Start by building a known-good copy of every boot and logon script location on the affected hosts and comparable systems, then compare current state against it. The telemetry that reveals a new or altered entry is usually File Modification and Process Creation, and on Windows, Windows Registry Key Modification, which ATT&CK links to this technique through its data components. Ask your detection engineers to confirm that mapping against the enterprise-attack 20.0 STIX bundle and to state which sources your Wazuh or Security Onion deployment actually collects, since no rule can fire on telemetry you do not gather. Decide in advance who may approve a script change on a shared host and record that decision, because it determines whether an unexpected entry is a finding or routine maintenance.
Which telemetry reveals T1037 activity on each platform
This table maps the data components that ATT&CK 20.0 references for Persistence techniques to the platforms where T1037 boot or logon initialization script activity is usually examined. Use each row as a starting point for collection, then confirm which fields your collectors actually capture before writing rules. File and registry changes tend to be the strongest signals, while process and command telemetry adds context about what ran.
| Platform | Data components | Signal to look for | Open-source collector |
|---|---|---|---|
| ESXi | File Modification (DC0061), Process Creation (DC0032) | Edits to host boot or init configuration, and unexpected scripts running during host startup | Wazuh file integrity monitoring with forwarded host logs |
| Linux | File Modification (DC0061), File Creation (DC0039) | Writes to init script directories and shell profile files, plus new executable files in startup paths | Wazuh file integrity monitoring and Velociraptor hunts on init paths |
| macOS | File Creation (DC0039), File Modification (DC0061), Process Creation (DC0032) | New or changed login and startup items, and scripts launched at login | Velociraptor artifacts and Wazuh monitoring of launch and startup locations |
| Network devices | Command Execution (DC0064), Process Creation (DC0032) | Configuration changes that add commands or scripts to boot or startup settings, visible in device logs | Syslog forwarded into Security Onion, with Zeek for related network sessions |
| Windows | Windows Registry Key Modification (DC0063), File Modification (DC0061), Process Creation (DC0032) | Changes to logon script values in user or system registry keys, and scripts launched at logon | Sysmon-based pipeline into Wazuh or Security Onion, with Velociraptor registry collection |
| Baseline on all platforms | Process Creation (DC0032), File Creation (DC0039) | Known-good inventory of boot and logon scripts per host, with alerts on deviation | Wazuh inventory and scheduled Velociraptor collections |
Detection logic for T1037 that SOC teams can tune
The ideas below cover the places where T1037 scripts take effect: logon and boot script locations, shell profiles, Windows run keys, ESXi host scripts and network device startup configuration. Each one needs a baseline built from known change sources, because configuration management, patching and user activity produce legitimate changes to the same locations.
Logon and boot script locations
Alert on creation or modification of files in logon and boot script locations such as login hook paths, rc-style startup directories and shell profile files, using File Modification and File Creation telemetry from Linux and macOS hosts. Tune by building a baseline of which processes normally write these paths, such as the configuration management agent or package manager, and alert on writes from interactive shells or unexpected parent processes. Typical false positives come from configuration management runs and user dotfile edits, so route expected writers to a suppression list keyed by process and host group, not by file name alone.
New init script creation
Flag newly created init scripts or service startup units on Linux hosts, where a file appears in a boot path that did not exist in the last known-good inventory. Use File Creation telemetry from the file integrity monitoring agent and compare against the approved change record for the host. Tune with a time-window baseline so that patch windows and provisioning jobs are expected events, and treat any unplanned creation outside those windows as a priority for review. Confirm with each platform team which tooling creates init scripts, because some distributions and packages install them automatically.
Windows run key modifications
Detect writes to Windows run and run-once registry keys that launch scripts at logon, using Windows Registry Key Modification telemetry. Focus on values whose data points to a script interpreter, a user-writable path or a script file extension, and ignore values written by installed software during its normal install sequence. Tune by maintaining a list of known software publishers and their expected run values, and review changes that occur outside software deployment windows. Sigma rules can express this logic where the log source supports registry events, so check that registry auditing is enabled for these keys before relying on the rule.
ESXi host script changes
Watch for modifications to startup and host configuration scripts on ESXi hosts, such as edits to the local startup script, and for unexpected changes to host configuration files that run at boot. Collect host logs and configuration change events centrally, then compare each host against a golden configuration baseline. Tune by excluding changes made by the approved vCenter-managed or automation workflows, and alert on edits made by accounts that are not part of the hypervisor administration group. Confirm which log sources your ESXi version exposes before writing detections, because coverage differs by release.
Network device startup configuration changes
Alert when the startup configuration of a router, switch or firewall differs from the running configuration or from the last approved backup, since a script or command that runs at boot can alter behavior after reload. Use Application Log Content from the device syslog and scheduled configuration backup comparisons. Tune by suppressing changes that come from approved change tickets and by setting a short comparison interval only for devices in regulated segments. Typical false positives include vendor firmware upgrades and scheduled configuration templates, so tie every alert to a change record or an approved automation job ID.
How to validate a T1037 detection in a lab before trusting it
This sequence shows how a team proves that its T1037 detections fire on the right telemetry, with the right fields, before anyone relies on them in production. It produces a documented set of true and false positive results tied to a specific ATT&CK version.
Agree the sub-technique scope
The detection owner, a security engineer and the platform owners for each in-scope system agree which T1037 sub-techniques the lab will cover, such as logon scripts on macOS, rc scripts on Linux, or ESXi startup configuration. They write the scope in a one-page plan that names the target systems and the ATT&CK version the mappings were built against. The step is done when every platform owner has signed off on the scope in writing.
Define expected telemetry per platform
For each in-scope platform, the team writes down which telemetry should appear when the behavior occurs. This usually includes process creation, file modification and, for Windows, Windows Registry key modification, mapped to the data components referenced by the relevant detection strategies. For each source they list the fields the alert must carry, such as host, user, process, file path and parent process. The step is done when a reviewer can read the expected-telemetry table and predict the alert without seeing the rule.
Confirm log coverage before the change window
Before any emulation, the team checks that the agents, auditing settings and collectors actually deliver the expected telemetry into the SIEM for each in-scope host. They confirm that the timestamps, host identifiers and field names match the rule logic, and they note any gap as a known limitation. The check is complete when a benign test event from each platform appears in the SIEM with every required field populated.
Run the emulation in a controlled window
Platform owners and the detection engineer run the agreed emulation in a private cyber range during a scheduled change window, with a named coordinator who logs every action and its start time. Operators follow the written plan and do not improvise beyond the agreed scope. The step closes when the coordinator has a timestamped activity log that matches the plan, so each alert can later be traced to a known action.
Confirm the alert fires with the right fields
The detection engineer compares the alerts raised in the SIEM against the expected-telemetry table and the activity log. Each emulated action should produce an alert with the correct host, user, file or registry path, and ATT&CK technique and sub-technique tags. Missing alerts, wrong fields or alerts on unrelated hosts are logged separately. The step is done when every planned action has a matched alert or a documented reason for its absence.
Record true and false positive results
The team records each outcome in a validation register that lists the rule identifier, rule version, platform, sub-technique, expected result, observed result and classification as a true positive, false negative or false positive. Any benign administrative activity that triggered the rule is recorded as a false positive with its cause. The step is done when the register covers every planned action and a second engineer has reviewed the classifications.
Tune, rerun and tie results to the ATT&CK version
Where false positives appear, the engineer adjusts the rule logic or allowlists narrowly, records the change, and reruns the same emulation plan so results are comparable. The validation record names the ATT&CK version the mappings target, because releases can rename, deprecate or revoke techniques and sub-techniques. The step is complete when a rerun shows the expected true positives with the tuned rule and the register references the version it was tested against.
Preventive controls that reduce T1037 exposure
T1037 depends on an adversary being able to write to a file or setting that runs at boot or logon. The controls below narrow who can make those changes, record when they happen, and limit the accounts that could make them, so that a detection rule has fewer places to miss. Confirm each control against the platforms you actually run, since the locations differ across ESXi, Linux, macOS, Windows and network devices.
Restrict write access to script locations
Restrict File and Directory Permissions (M1022) is the most direct control for T1037. Review who can write to the boot and logon script locations on each platform, including init and profile files on Linux and macOS, logon scripts referenced from Windows Group Policy, and startup configuration on ESXi and network devices. Standard users and service accounts should not hold write access to these paths. Confirm the permissions with a recursive audit on each host, not only on the documented default paths.
Restrict registry write permissions
Restrict Registry Permissions covers the Windows Registry keys that can reference logon or startup scripts, such as those under the Winlogon and Group Policy script settings. Limit write access to these keys to administrative and tightly managed accounts. Check inherited permissions from parent keys, because a broad grant higher in the hive can override a narrow setting lower down. Confirm the effective permissions with a tool that reports the resolved access, not only the explicit entries.
Limit privileged accounts
Privileged Account Management (M1026) reduces the number of accounts that can alter boot or logon scripts in the first place. Most T1037 changes need administrative rights, so every standing administrator is a potential path. Review who holds root, domain administrator, ESXi root or network device privileged access, and remove standing rights where a just-in-time or break-glass process can replace them. Confirm that service accounts used by configuration tools are not also used interactively.
Audit changes to script paths
Audit (M1047) makes it possible to see who changed a logon or boot script and when. Enable file integrity monitoring or native audit policy on the directories and registry keys identified in the permission review, and forward those events to a central store. Without logging, a successful change leaves no evidence for investigators. Confirm the retention period and log volume with your SIEM team before enabling audit on high-churn paths, because noisy paths can hide meaningful changes.
Baseline and review startup configuration
Keep a known-good baseline of boot and logon scripts for each host class, stored under configuration management and reviewed on a schedule. A baseline lets analysts spot a new entry quickly, and a change record can confirm whether it was authorized. Compare baselines after patches, image rebuilds and administrative changes, since these events legitimately modify startup files. Confirm who approves baseline changes and how exceptions are recorded.
Triage steps when a T1037 alert fires
Start by deciding whether the change was authorized, because that answer drives every step after it. Compare the modified script against the last approved version in your configuration management repository or golden image, and check its hash against the configuration baseline for that host or device class. Then match the modification time and the account that made the change against change records. A script that differs from its baseline and has no approved change ticket is the strongest signal of unauthorized persistence. A script that matches a ticket but was edited outside the approved pipeline still needs review, because the ticket may not describe what was actually written. Record the outcome as authorized, unauthorized or unresolved before moving on.
Next, scope the change beyond the alerting system. Initialization scripts are often copied into shared golden images, VM templates, host profiles and network device configuration templates, so the same artifact may sit on systems that have not yet run it. Search File Modification telemetry and file integrity baselines across the fleet for the same path and hash, and list every image or template built or synced since the recorded change time. Ask the platform owner which pipelines consume those templates and whether any reached production. Treat each match as a separate system to triage, and track confirmed, cleared and pending systems so the scope can be reported accurately.
Preserve the evidence before containing anything. Copy the script exactly as found, and record its hash, owner, permissions, timestamps and the process record for the write. Store the copy in your case management system with a chain of custody note. Containment then follows two questions: does the script run with elevated privileges, and is the affected system production-critical? If the change is unauthorized and the script runs with elevated rights, isolate the host or device, rotate any credentials it could read, and restore the script from baseline only after the copy is secured. If the change is authorized but the content is wrong, revert it through the change pipeline. Afterwards, confirm that Restrict File and Directory Permissions (M1022) covers the script's directory and document which owner approved each decision.
Rehearsing T1037 detection and response in a private cyber range
This range models hosts where boot and logon initialization is handled by shell profiles, init configuration and login hooks. The facilitator builds a small fleet of Linux and macOS endpoints that mirror the client's build images, with central log forwarding and file integrity monitoring enabled on the locations that matter for persistence.
- Planned injects: The facilitator schedules a change to a user or system profile file at an unusual hour, followed by a change to a login or startup configuration that the baseline does not contain. Each inject has a written expected alert and a written expected case.
- Good detection: A file modification alert on the monitored profile and startup paths fires within the agreed window, and the analyst can tell from the event whether the change came from an approved change record.
- Good response: The analyst opens a case, compares the file against the golden image, and hands the host to the platform team with the diff, the process that made the change and the user context.
- Evidence capture: Hash the original and modified files, export the relevant Wazuh or Security Onion events, and record the time of each handoff.
- Confirm first: Which Linux distributions and macOS versions the range will run, and whether your endpoint agent supports the file paths you plan to monitor.
Check that every detection in this range maps to a named ATT&CK version and a named data component so results remain comparable across reruns.
This range models logon and startup behavior driven by the Windows registry, startup folders and scheduled startup entries. The facilitator uses a domain-joined test environment with Sysmon-style process and registry telemetry forwarded to the SIEM, so analysts see the same signals they would in production.
- Planned injects: The facilitator plants a registry value under a common autostart location and places a file in a user startup folder, each on a different host, with timing spread across the exercise window.
- Good detection: A Windows Registry Key Modification event and a File Creation event both appear, and a correlation rule raises one case instead of two unrelated alerts.
- Good response: The analyst confirms the registry path and the file, checks whether a Group Policy or management tool made the change, and isolates the host only if the change is unexplained.
- Evidence capture: Export the registry key value before and after, record the event IDs used in the case, and keep the hash of the planted file.
- Confirm first: Which Sysmon configuration and Windows event channels your range image uses, since detection depends on them.
The exercise should also test whether the analyst knows how to separate a legitimate software update from a planted entry, and that judgement should be recorded in the case notes.
This range models hypervisor and network appliance boot scripts, where a change may survive a reboot and be hard to see from the guest. The facilitator uses an isolated lab with a non-production hypervisor host and a lab switch or router, with configuration backups taken before the exercise starts.
- Planned injects: The facilitator alters a startup configuration on the hypervisor host and adds a boot-time command to the lab device, then records the time of each change in the exercise log.
- Good detection: Configuration change logs from the device or host reach the SIEM, and the analyst sees a diff between the stored configuration and the last approved backup.
- Good response: The analyst raises the case with the infrastructure owner, verifies the change against the change management record, and restores the device from a known good backup under supervision.
- Evidence capture: Keep the configuration backup, the diff, the device log export and the restore record, all signed off by the owner.
- Confirm first: Which logging and configuration-change features your hypervisor and device models support, because not every platform records these events by default.
Record every result against the agreed ATT&CK version so the range report can show what was detected, what was missed and what changed between rehearsals.
Questions SOC leads and detection engineers ask about T1037
How is T1037 different from T1547 boot or logon autostart execution?
T1037 covers scripts that the operating system or a platform runs at boot or logon through initialization mechanisms, while T1547 covers a broader set of autostart locations such as registry run keys, startup folders and services. The two overlap in practice, so a detection built only on one technique will miss activity recorded under the other. Map each sub-technique to the specific file, key or configuration path it abuses, then confirm in the current ATT&CK version which technique and sub-technique IDs your analytics target. Keep both mappings in your detection inventory so coverage gaps are visible rather than assumed.
Which data sources should a SOC enable first for T1037?
Start with the data components the ATT&CK detection strategies reference most for Persistence: Process Creation, File Modification and File Creation, then Windows Registry Key Modification where Windows hosts are in scope. Process Creation tells you which interpreter ran at boot or logon, File Modification shows changes to initialization scripts and profiles, and Registry Key Modification covers Windows autostart keys. Confirm the exact data components for your target ATT&CK version before you write rules, because data component IDs are updated between releases.
How should we handle ESXi and network device logs for T1037?
Treat them as a collection problem first. ESXi hosts and network devices often send fewer local events, and their logs may not reach the SIEM unless you configure remote syslog forwarding and confirm retention. Check which log levels and file-change events each platform emits, then document the gaps you cannot close. Validate the pipeline by generating a benign, approved configuration change in your cyber range and confirming it arrives in the SIEM with the expected fields and timestamps.
How do we map detections to ATT&CK 20.0 without drift?
Pin every detection to a named ATT&CK version, then record the STIX bundle version you used in the rule metadata. Re-check technique and sub-technique IDs each time MITRE publishes a release, because releases can rename, deprecate or revoke techniques. Keep a mapping file in version control that links each Sigma or Wazuh rule to its technique ID, and run a diff against the new bundle before you accept an upgrade. The MITRE updates pages list what changed in each release.
How do we measure detection quality for T1037 in a cyber range?
Measure the outcome of each rehearsed scenario rather than the number of rules deployed. For each approved test, record whether an alert fired, how long it took to reach the analyst queue, whether the alert contained enough context to act on, and whether the response runbook was followed. Track false positives from normal administrative changes separately, since they drive alert fatigue. Repeat the same scenarios after each rule change so you can see regressions.
Can our own team run T1037 detection and validation without outside help?
Yes, many teams can, provided they have staff who know their initialization paths, a SIEM with the required data sources, and a safe environment for testing. The hard parts are usually the baseline of legitimate script changes, the ESXi and network device log gaps, and keeping mappings current across ATT&CK releases. A fixed-scope engagement from DeployOpen can cover planning, implementation, detection content and range rehearsal, with the scope agreed in writing before work begins. Ask any provider to show how they will validate detections in your environment and who owns the resulting rules.
What should a response runbook for a suspicious T1037 alert include?
A useful runbook defines triage steps, the owner of each step, and the evidence to preserve before any change is made. Start by confirming whether the script change was approved, then compare the file hash and last-modified details against your configuration management records. Capture the host state for investigation, check whether the same script appears on other hosts, and decide on containment only after the scope is clear. Rehearse the runbook in the cyber range so the first live alert is not the first time the team uses it.
How DeployOpen builds T1037 detections and range scenarios
DeployOpen starts every T1037 engagement with a written scope that names the platforms in play, which of the five sub-techniques are in scope, and which telemetry the client can actually provide. For this technique that usually means the logon and boot script locations on Linux and macOS hosts, the Windows registry values and logon-related keys that run at sign-in, the startup and configuration paths on ESXi hosts, and the configuration backup or change records on network devices. The scope also states the ATT&CK version the mapping targets, because ATT&CK releases can rename or deprecate techniques. Ask the provider to confirm in writing which Enterprise ATT&CK version and which data components the detection content will reference, and which sub-techniques are excluded and why. A written scope makes later tuning decisions traceable.
Detection content is then built against the client's own telemetry rather than generic samples. Engineers review whether File Modification, Process Creation and Windows Registry Key Modification events reach the SIEM with the fields needed to identify the changed path, the writing process and the account involved. Rules are written as open-source Sigma logic and converted to the client's stack, such as Wazuh, Security Onion or Velociraptor hunts, and each rule is tuned against the client's normal change activity, including configuration management and patching jobs that legitimately touch startup files. Ask the provider how exceptions are approved, who owns them and how they are reviewed when the environment changes.
Purple team exercises then run in a private cyber range that mirrors the client's platforms, so the team can confirm that each rule fires, routes to the right queue and produces the expected alert fields without touching production. Each scenario ends with documented evidence: the rule version, the range configuration, the events observed, the gaps found and the remediation owner. DeployOpen hands this evidence to the client in a form their internal assessors can review. It supports compliance readiness with that evidence but does not issue audit reports or certifications. Confirm with the provider what the handover package contains, how often scenarios are repeated, and whether retesting is included in the fixed scope or sold as a retainer.
