How can a system service provide persistence?¶
A system service can start code automatically and run it under a defined, sometimes highly privileged, account. Services are essential operating-system components, so background operation is not itself suspicious.
Examine configuration rather than appearance¶
Preserve the service's stable identifier, display name, binary path, arguments, startup type, service account, creation and modification times. A malicious service may imitate a trusted product, while a legitimate binary can be misused through altered arguments or configuration.
Identify the creator account and process. Remote administration or command execution may create the service, meaning later background activity should not be attributed to the local device user.
Service-control and process records show whether it started, stopped or failed. Follow successful launches into related files, child processes and network activity. Presence proves capability, not execution or purpose.
Compare with authorised change¶
Installers and management systems routinely create services. Match the timing, binary, configuration and target device with deployment records and organisational baselines.
Preserve evidence before deletion because removal can erase how the command, privilege and automatic-start behaviour were configured. Record responder changes so they do not become confused with offender activity.
Key takeaway
Establish who created or changed the service, exactly what it launched, its privilege and its execution history before calling it malicious persistence.
