Persistence
Look for access that survives the first cleanup action.
Access that survives the first interruption
Persistence is the ability to retain or regain access after events that might otherwise interrupt it, such as a reboot, a sign-out, or removal of one malicious process. It can involve startup configuration, scheduled execution, new credentials, modified applications, or other mechanisms that make unauthorized access repeatable.
Persistence is broader than a file on disk. In cloud and identity systems, an unauthorized application grant, additional credential, or newly created account can provide continuing access without an endpoint startup entry. Investigators should examine the mechanisms relevant to the environment rather than applying one device-centered checklist everywhere.
Investigate the repeatable path
In a fictional workstation case, responders stop a suspicious process. The same behavior returns after the user signs in again. The team examines startup and logon configuration, recent changes, process lineage, and the files or commands referenced by those settings.
The recurring process is a useful clue, but the team must establish which mechanism causes it to run. A scheduled task, a service, and an application extension have different configuration and ownership records. Removing the process repeatedly treats the symptom while leaving the trigger intact.
Boot or Logon Autostart Execution and Scheduled Task/Job illustrate different execution paths. Create Account illustrates a persistence path based on identity rather than recurring code execution.
Distinguish configuration from abuse
Operating systems and applications legitimately maintain startup entries, services, extensions, and scheduled jobs. An unfamiliar entry is not automatically malicious. Check its creator, purpose, referenced artifact, permissions, deployment history, and relationship to the observed incident.
A familiar name is not sufficient reassurance either. An actor can choose a plausible service name or alter an existing configuration. Compare the actual target and behavior with an approved baseline where one is available.
Remove the mechanism and its enabling access
Preserve the configuration and related evidence before cleanup where practical. Then address the unauthorized trigger, the artifact it launches or authority it grants, and the original access that allowed its creation. Otherwise the actor may recreate the same mechanism.
Coordinate changes with the service owner because deleting a legitimate startup component can break normal operation. Verify that the expected service still works and that the unwanted behavior does not recur under the conditions that previously triggered it.
For practice, create a paper timeline where one account creates a scheduled job and later loses access. Explain why the job may still matter, which records would establish its execution, and what evidence is needed before deleting it. Eradication and recovery turns that reasoning into readiness checks, while Incident reporting and handover preserves the distinction between confirmed mechanisms and suspected ones.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
MITRE ATT&CK: Get startedMITRE ATT&CK: Persistence tactic