Approving remediations: autoruns
What the autoruns remediation does on the endpoint, what it doesn't do, how to verify it cleanly, and the re-detection pattern that turns a routine approve into a containment-and-escalate call.
Autoruns are the most common persistence mechanism attackers use, and the most common remediation type approved during routine triage. The mechanism is simple: entries that make code run automatically on login, boot, or specific events. The cleanup is more than “delete the registry key,” though, and knowing what the remediation actually does is what separates click-approve-and-hope from approve, verify, move on.
What counts as an autoruns entry
“Autoruns” is borrowed from Sysinternals’ tool of the same shape: the set of mechanisms Windows (and macOS / Linux equivalents) uses to launch code automatically without the user asking. On Windows that includes Run and RunOnce registry keys, startup folders, services configured to start at boot, WMI subscriptions firing on system events, browser helper objects, Winlogon entries, image file execution options, and AppInit DLLs.
Scheduled tasks are a separate remediation type in the Huntress flow (covered next lesson), even though Sysinternals’ Autoruns tool includes them in its inventory.
Attackers favour autoruns because the persistence survives reboot. Once their code is in an autoruns entry, killing the running process doesn’t help; it will be back at next boot. That is why the SOC flags suspicious autoruns and recommends the remediation.
What the remediation does
When you approve, the Huntress agent on the endpoint executes:
- Removal of the autoruns mechanism itself (the registry key, the startup-folder shortcut, the WMI subscription, etc.).
- Removal of the backing file if the SOC has classified it as malicious and the remediation includes it.
- A re-scan to confirm the entry no longer appears in the inventory.
The remediation does not reboot the endpoint. It does not stop a currently-running process. If the malicious binary is running right now, isolation or a separate process-kill is what addresses that; the autoruns remediation removes the persistence, which is what stops the activity from coming back.
The procedure
- Confirm the autoruns remediation is in the Recommendation, not just mentioned in Evidence.
- Confirm the host is the right host in the right customer organisation.
- Approve via the portal’s recommended-action button.
- Wait for the agent to process. Typically seconds to minutes, depending on check-in cadence.
- Verify: the portal shows the remediation completed, and a re-scan confirms the autoruns entry is gone.
- Close in Huntress and the PSA. Document.
Verify
- The remediation shows completed in the portal.
- The previously-detected autoruns entry no longer appears in the endpoint’s persistence inventory.
- No re-detection within the next hour or so.
- Incident note records the remediation, the verify check, and the closure.
When to escalate
A re-detection of the same autoruns entry within an hour of a clean remediation is the signal that persistence is being re-installed by something still active on the endpoint. That is not a re-approve scenario. Approving again removes the new entry; the next re-install fires a few hours later. The right move is to isolate and bump in parallel. This is the same pattern as scheduled-task or service re-detections, and it is the Critical-recognition territory covered later in the arc.
The other escalation triggers are simpler: the remediation fails to apply after one retry, or the customer’s IT contact tells you the autoruns entry is something they set up deliberately (new signal — reply to the analyst with the user’s confirmation before approving).