Startup, tasks & persistence review
Examine automatic execution mechanisms without treating every startup entry as malicious.
Question & scope
Persistence examination asks what is configured to run again, under which account, and after which trigger. Game launchers, anti-cheat components, update agents, and peripheral utilities often install legitimate automatic execution mechanisms. Inventory an entry’s action, path, arguments, account context, trigger, and file identity before drawing a conclusion.
Autoruns can enumerate multiple startup locations. Task Scheduler provides another view of configured tasks. These tools expose configuration; they do not alone establish that an entry executed successfully during the disputed match. Preserve available logs and referenced files to investigate that separate question.
What to collect
| Source | Retain and examine |
|---|---|
| Startup entry | Source location, configured action, arguments, and user context. |
| Task configuration | Task path, triggers, actions, account, and relevant settings. |
| Referenced file | Content hash, signature information, and exact release context. |
| Execution sources | Available task, service, process, and game-session records. |
Examination workflow
- Record the existing configuration before disabling, deleting, or running any entry.
- Use a documented viewer and keep complete paths and arguments, including environment-variable references.
- Resolve the target file and compare it with the correct vendor or project release.
- Separate task registration, configured triggers, and evidence of actual execution.
- Correlate relevant activity with session time, collection activity, and the applicable user context.
Interpretation & false positives
A task’s name is a label, not an authenticated statement about its purpose. A familiar name can hide a changed target; an unfamiliar name can belong to a legitimate updater. An entry pointing to a missing file may be stale rather than evidence of current capability.
Configured persistence is distinct from use. A task can exist without its trigger firing, and an action can fail. Services and machine-wide tasks may run in a different account context from the player. Avoid attributing every automatic action to an interactive click.
Worked scenario
A task appears to be a launcher updater, but its action points to a user-writable temporary location. Collect the configuration and target bytes before classifying it. Examine file identity, installation context, and available execution records. Report the unexpected target first; explain the behavioral conclusion only if the evidence supports it.
Report checklist
- Configuration is preserved before modification.
- Names and target identity are assessed separately.
- Registration, trigger, and execution are distinct observations.
- Account and collection context are included.
Sources & further reading
The workflow and scenario are authored investigation guidance. Confirm source-system and parser support for the build you examine.