An autoruns export from a suspect Windows host is below — identify the persistence mechanisms.
You are triaging a Windows workstation that a detection rule flagged this morning.
Constraints:
- Judge only from the export below — the host is still powered on and untouched.
- Name every hostile entry, the evidence behind it, and what you do before removing anything.
Autoruns export - HOST: WKS-4471 (user: jsmith)
[Registry Run - HKCU]
Slack C:\Users\jsmith\AppData\Local\slack\slack.exe signed: Slack Technologies
OneDriveUpdate C:\Users\jsmith\AppData\Roaming\svchost.exe signed: (none)
[Scheduled Tasks]
\Microsoft\Windows\Defrag\ScheduledDefrag defrag.exe -c signed: Microsoft
\SystemCheck powershell.exe -w hidden -enc <redacted> every 30 min, signed: Microsoft
[Services]
Spooler C:\Windows\System32\spoolsv.exe signed: MicrosoftState the verdict and your first response action.
Two entries are hostile. The Run value named OneDriveUpdate launches an unsigned svchost.exe from the user profile — a system binary name in a writable path. The task SystemCheck runs hidden encoded PowerShell every 30 minutes. Preserve evidence first.
- ✗Reading a system binary name as proof that the file is a system binary
- ✗Deleting the persistence entries before any evidence is preserved
- ✗Treating persistence removal as the end of the incident
- →Which volatile artifact would you capture before touching either entry?
- →How would you check whether other hosts carry the same scheduled task?
The host is compromised, and two entries show it.
OneDriveUpdate -> svchost.exe under AppData\Roaming, unsigned
the real svchost.exe lives only in System32
the entry name masquerades as a OneDrive updater
SystemCheck -> powershell.exe -w hidden -enc, every 30 minutes
the Microsoft signature covers powershell.exe,
not whatever it is told to execute
Slack -> vendor-signed, expected path — legitimate
ScheduledDefrag/Spooler -> stock Windows componentsThe trap is the signature column. On SystemCheck the signed thing is the interpreter, not the payload, so running through a trusted system binary does not make the entry safe.
Response order: capture a memory image and preserve copies of both entries and the AppData file as evidence, isolate the host from the network, and only then remove the persistence. After that, hunt the fleet — the same task name or the same path on other machines shows the scope. Deleting the entries proves nothing on its own: persistence is often duplicated, and the original access remains.
