Ниже выгрузка автозапуска с подозрительного хоста Windows — определите механизмы закрепления.
Вы разбираете рабочую станцию Windows, на которую утром сработало правило детектирования.
Ограничения:
- Судите только по выгрузке ниже — хост всё ещё включён и не тронут.
- Назовите каждую враждебную запись, доказательства и то, что вы сделаете до удаления.
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: Microsoft
Сформулируйте вердикт и первое действие реагирования.
Враждебны две записи. Значение Run с именем OneDriveUpdate запускает неподписанный svchost.exe из профиля пользователя — имя системного бинарника в записываемом каталоге. Задача SystemCheck каждые 30 минут запускает скрытый закодированный PowerShell.
- ✗Принимать имя системного бинарника за доказательство, что это системный файл
- ✗Удалять записи закрепления до того, как сохранены улики
- ✗Считать снятие закрепления концом инцидента
- →Какой волатильный артефакт вы снимете до того, как тронете эти записи?
- →Как проверить, есть ли такая же запланированная задача на других хостах?
Хост скомпрометирован, и это видно по двум записям.
OneDriveUpdate -> svchost.exe в AppData\Roaming, подписи нет
настоящий svchost.exe живёт только в System32
имя записи маскируется под обновление OneDrive
SystemCheck -> powershell.exe -w hidden -enc, интервал 30 минут
подпись Microsoft относится к powershell.exe,
а не к тому, что он выполняет
Slack -> подписан вендором, путь ожидаемый — легитимен
ScheduledDefrag/Spooler -> штатные компоненты Windows
Ключевая ловушка — колонка подписи. У задачи SystemCheck подписан интерпретатор, а не полезная нагрузка, поэтому запуск через доверенный системный бинарник не делает запись безопасной.
Порядок действий: сначала снять образ памяти и сохранить копии обеих записей и файла из AppData как улики, затем изолировать хост от сети, и только после этого снимать закрепление. Дальше — поиск по флоту: та же задача или тот же путь на других машинах покажут масштаб. Само по себе удаление записей ничего не доказывает: закрепление часто дублируется, а вход в систему остаётся.