Boot or Logon Autostart Execution

Startup is an execution opportunity

Boot or logon autostart execution runs a program when a system starts or a user signs in. Operating systems provide these mechanisms for ordinary services and user applications. An actor can abuse them to make unauthorized behavior return after a restart or a new session.

The relevant configuration differs across platforms. Investigators should identify the actual startup mechanism and its execution context rather than treating every recurring process as the same kind of persistence. An entry affecting one user's sign-in has a different scope from a system-level component.

Explain why the process returned

In a fictional endpoint incident, an analyst terminates an unfamiliar program. It returns when the employee next signs in. The team examines startup configuration, recent changes, the referenced program, the creator identity, and the process sequence around sign-in.

A legitimate collaboration client could behave the same way. The investigator checks whether the program belongs to an approved application, whether the configured path matches the expected installation, and whether the observed network or file behavior fits its purpose.

A familiar display name is insufficient. A startup entry may use an ordinary-looking name while pointing to a different file. Conversely, an internal application may have an unfamiliar name but an approved owner and deployment record.

Separate the trigger from the artifact

The startup entry causes execution; the referenced file provides the behavior. Removing only one of them can leave an incomplete cleanup. A surviving entry may fail noisily, point to a replacement later, or indicate that other related configuration remains.

Determine who can modify the startup location and under which identity the target executes. That relationship helps explain whether the mechanism provided only repeatability or also a change in authority. Do not infer privilege escalation merely because execution occurred at startup.

Persistence describes the broader objective. Hijack Execution Flow addresses situations where code selection is redirected through a different mechanism.

Validate the cleanup

Preserve the configuration and relevant artifact information before removal where practical. Restore the approved state through an authorized process and address the access that allowed the change. Coordinate with the endpoint owner because deleting normal startup components can break expected applications.

Check behavior under the original trigger conditions: restart, sign-in, or another documented event. A quiet device immediately after removing a process does not demonstrate that the startup mechanism is gone.

For practice, compare an approved chat client startup entry with a fictional entry pointing to an unexpected user-writable location. List the evidence required before deciding which is unauthorized, and identify a remaining uncertainty if creation records are unavailable. Logs and telemetry and Incident response connect the recurring process to a defensible response decision.

Related concepts

• MITRE ATT&CK