Persistence on servers
Spot what installs itself to stay on a server (service, scheduled task, local administrator or account, cleared log) and validate what is legitimate.
An attacker who has gained a foothold on a server tries to stay there: a service, a scheduled task, an account added to the local administrators. The Persistence screen compares each server with its own baseline and reports anything that appears or changes.
Set it up
- Update the server's agent to version 2026.10.11.3 or later (see Manage agents).
- In FSI Agents, open the gear button on the agent's card and turn on the Persistence module. It is not on by default.
- The first collection arrives 2 minutes later, then every 15 minutes.
A server's first collection serves as the baseline: everything in it is marked Baseline, with no incident. Only later additions and changes are reported. On a domain controller, the administrator list is that of the domain group, and there is no local account.
The agent only reads. It changes no service, task or account.
What is collected
| Type | What you see |
|---|---|
| Services | Name, executable, account, start type, state, signature of the executable |
| Scheduled tasks | Path, actions, account, triggers |
| Local administrators | Members of the machine's Administrators group |
| Local accounts | The machine's accounts, enabled or disabled |
| Events | Service installed (7045), System log cleared (104), Security log cleared (1102) |
Tasks in the \Microsoft\ folder belong to Windows. They are hidden by default (Show \Microsoft\ tasks box) and are only reported if one of their actions runs a file located in a folder users can write to.
The tabs
Open SI-Tracer → Persistence (#/sitracer/persistance).
| Tab | Content |
|---|---|
| Overview | Monitored servers, items to validate, open incidents, late collections; one row per server with its counters by type |
| To validate | All new or changed items, with their severity and indicators |
| Tab named after the server | A server's details: items by type, filters by status, recent events over 30 days, errors from the last collection |
| Alerts | PERSIST-* incidents over 7, 30 or 90 days |
After 45 minutes without a collection, the server is counted in Late collections (> 45 min) and shown in red. This delay does not open an incident.
What opens an incident
| Rule | Trigger | Severity |
|---|---|---|
| PERSIST-SERVICE | new service, or executable or account changed | high if the executable is outside Windows and Program Files, in a user-writable folder or unsigned; otherwise medium |
| PERSIST-TACHE | new task, or actions or account changed | high if an action targets a user-writable folder or runs an interpreter with arguments (PowerShell, cmd, mshta, rundll32…); otherwise medium |
| PERSIST-ADMIN-LOCAL | member added to the local administrators | high (low for a removal) |
| PERSIST-COMPTE-LOCAL | local account created or re-enabled | medium |
| PERSIST-SERVICE-INSTALLE | event 7045 for a service that is not already waiting for validation | medium |
| PERSIST-JOURNAL-EFFACE | System or Security log cleared | critical |
Indicators appear in the Indicators column: outside Windows / Program Files, user-writable folder, unsigned, interpreter with arguments. A Microsoft service update that only changes folder, with the same signed executable and the same account, is not reported.
An item that disappears becomes Gone, with no incident. An item that changes, or comes back after disappearing, goes back to To validate and opens an incident, even if it had been approved.
Validate a legitimate item
- In SI-Tracer → Persistence, To validate tab, read the item and its indicators.
- If it is legitimate (planned installation, software update), enter a comment and click Approve. Approve selection handles several items at once.
- The item becomes Approved and joins the baseline. The matching incident is closed if it is still Open.
An incident already acknowledged or under investigation in the SIEM stays open: close it in Security Incidents. "Service installed" and "log cleared" incidents are not closed by an approval.
Validation is reserved for administrators and recorded in the audit log. The comment is optional, but it leaves a trace for later.
Frequently asked questions
"No collection received". The Persistence module is not enabled on the machine, or the agent is too old. See A security screen stays empty.
Why is nothing reported after installing the module? That is deliberate: the first collection becomes the baseline. Only later changes are reported.
A software update fills the "To validate" list. Approve its items in bulk with Approve selection, mentioning the update in the comment.
Source: · FirstSI Docs · updated 2026-10-11