What should be preserved before persistence is removed?¶
Before removing persistence, preserve the mechanism, its configuration and the evidence linking it to the wider incident.
Avoid the dangerous assumption¶
The dangerous assumption is that deleting the mechanism is evidentially harmless.
It may remove:
- files
- task definitions
- service configuration
- account records
- token or consent details
- browser data
- web-shell content
- timestamps
- execution history
- linked identifiers.
Preserve:
- the full mechanism
- name and stable identifier
- creation and modification records
- creator account or process
- trigger or startup condition
- privilege level
- target file or command
- execution or use history
- network and account activity
- screenshots or exports where appropriate.
Where a live process or session is involved, specialist support may be required before termination.
Record who authorised removal, when it happened, what method was used and what effect followed.
Do not assume removing one persistence route ends the incident.
Check for linked accounts, tokens, applications, scheduled tasks, services, remote tools and other footholds.
Where operational risk requires immediate removal, document what could not be preserved and what alternative records remain.
Containment may also cause the offender to use another route, creating further evidence.
Where the mechanism contains credentials, tokens or commands, preserve them securely and restrict unnecessary exposure. The evidential value lies in the configuration and linkage, not in distributing live access material.
Also record whether removal required restart, account revocation or provider action, because each may alter additional evidence.
Preserve those consequential changes as part of the response timeline.
Operational takeaway¶
Capture the mechanism, configuration, creator and use evidence before removal, then document the containment action and check for additional footholds.