What evidence may show when persistence was created?¶

The creation time of persistence can help place it within the incident sequence.

Avoid the dangerous assumption¶

The dangerous assumption is that one timestamp gives a precise and reliable creation time.

It may not.

Useful evidence may include:

• account-creation logs
• task or service creation
• file-system metadata
• registry or configuration changes
• application consent
• browser-extension installation
• web-server uploads
• process activity
• administrative audit logs
• security alerts.

Investigators should compare several records.

A file timestamp may show copy or modification rather than original creation.

An imported task may retain earlier metadata.

A restored system or deployment process may reproduce an old timestamp.

An offender may also alter timestamps deliberately.

Look for the event that caused the mechanism to appear.

Which account or process created it?

What command or API call was used?

What happened immediately before and after?

Where several clocks are involved, preserve the original time zones and any known drift.

If exact timing cannot be established, report a supported window.

Creation timing may link persistence to a particular session, account or exploit.

It does not automatically identify the person responsible.

Also preserve the system or provider records showing when the relevant logging source itself became active. A missing earlier record may reflect absent logging rather than prove that persistence was created later.

A creation window may therefore be more defensible than an exact second.

State that limitation clearly in the final investigative report.

Operational takeaway¶

Correlate creation, process, account and audit records to establish a supported creation window rather than relying on one timestamp.