Skip to content
Skip to main content
Cyber Incidents & Offender Methods Technical Explainer

What evidence may show malware persistence?

Malware persistence is shown when an attacker-controlled mechanism is configured to regain or retain access after an interruption, such as a restart, logout or removal of the original entry route. Finding a startup item or scheduled task is only the beginning: legitimate software uses the same mechanisms.

Persistence may be implemented through services, scheduled tasks, startup folders, registry run keys, login scripts, browser extensions, new accounts, authentication tokens, web shells, modified system components or unattended remote-management settings.

Test creation and use separately

For a suspected mechanism, establish:

  • when and under which account it was created or changed;
  • the executable, script, credential or resource it invokes;
  • its trigger and configured conditions;
  • whether the trigger occurred and the mechanism ran successfully;
  • what process, session or connection resulted; and
  • whether it survived the interruption it was intended to outlast.

A task can be created but never triggered. A service can fail to start. A token can expire. Configuration therefore supports an intention or capability, while execution records demonstrate use.

The reverse inference also needs care. Continued access does not necessarily require malware persistence: stolen credentials, a cloud session or an already-authorised remote service may explain the return.

Preserve the mechanism before changing it

Configuration, associated payloads, access-control details and relevant logs should be captured before removal where possible. Remediation can destroy the very relationship that needs to be explained, and its timing may create new file or registry timestamps. Recording each containment action allows later analysis to separate those changes from offender activity.

Creation time can help define the incident timeline but should be corroborated because timestamps may reflect installation behaviour, copying or manipulation. A confirmed persistence mechanism also does not identify its creator without supporting account, process and access evidence. Malware, an interactive offender and a compromised administrator account can produce similar configuration.

Key takeaway

Show what the persistence mechanism was, how it was created and whether it successfully ran; its presence alone proves neither continued access nor the identity of its creator.

Reference: CIM-077Cyber Incidents & Offender Methods