---
{
  "title": "Boot or Logon Initialization Scripts",
  "summary": "Boot and logon initialization scripts can establish repeatable execution when a machine starts or a user signs in.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1037"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1037: Boot or Logon Initialization Scripts",
      "url": "https://attack.mitre.org/techniques/T1037"
    }
  ],
  "editorialVersion": 2
}
---

## Initialization scripts are part of normal administration

Boot or logon initialization scripts run during system startup or user sign-in. They may configure an environment, map resources, start applications, or perform other administrative work. Unauthorized changes to these scripts can make malicious behavior execute repeatedly through an otherwise expected workflow.

The important distinction is that the script or its configuration becomes part of the execution path. A script's presence does not establish abuse, and its legitimate historical purpose does not guarantee that its current contents remain trustworthy.

## Investigate a changed sign-in script

At a fictional company, a sign-in script normally connects users to approved shared resources. Endpoint records show it launching an unexpected program after a recent modification. The analyst retrieves the current script, compares it with a trusted earlier version, and examines the change history and modifying identity.

The team checks whether the change belongs to an authorized deployment. A maintenance update might add a new helper program, but the approved request should match the observed path, purpose, and affected user population.

The script may be centrally distributed or stored locally. That difference changes scope: a central modification could affect many devices, while a local change may be limited to one host or profile. Confirm actual distribution rather than assuming every user received the same content.

## Review permissions and execution context

Determine who could edit the script or its referenced files and which identity executes it. A script launched with greater authority than its editors possess creates a particularly important boundary to review. The presence of a script alone does not prove that this boundary was crossed.

Track commands through to their effects. A modified line shows intent or configuration; process, file, and service records may show whether it ran successfully. Preserve both versions and the supporting events where available.

[[linux-permissions]] explains why write access to administrative material matters. [[boot-or-logon-autostart-execution]] covers the broader startup behavior, while this note focuses on initialization script content and delivery.

## Restore the intended workflow

Restrict unauthorized editing, restore a reviewed version, and investigate any artifacts or access created by the changed script. Coordinate with administrators so legitimate sign-in functions continue. Removing the entire script without understanding its purpose may interrupt access to required resources.

For practice, compare two script revisions in a paper exercise. One updates an approved resource mapping; the other adds an unexplained executable. Identify the change evidence, owner confirmation, and execution records needed to distinguish them. Then consider how your conclusion changes if modification history is missing. [[incident-reporting]] should explain both the confirmed content change and the limits of the execution evidence.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]