Короткий ответ

Неизвестный процесс на host.example или WS-042: зафиксируйте PID, родителя, командную строку, путь, SHA-256, владельца, сеть. Не kill -9 / Stop-Process -Force до этого — потеряете дерево и сокеты. Не копируйте бинарь на прод-шару. Изоляция узла — если есть сеть наружу/шифр/привилегии, параллельно сбору.

Дальше: слушатель, трафик, троян, артефакты.

Симптомы и как отличить

  • Мониторинг: новый процесс svcupdate.exe из C:\Users\ivan.petrov\AppData\Local\Temp.
  • Linux: /tmp/.x или kthreadd с пользовательским UID (подделка имени).
  • 4688: родитель winword.exe → powershell.exe.
  • Служба 7045, которой нет в эталоне.
ПроцессСкорее легитимныйПроверка
MsMpEng.exeDefenderпуть C:\Program Files\Windows Defender
sshdпакетdpkg -S $(readlink /proc/PID/exe)
Ваш агент мониторингаinventoryподпись/пакет
python в /opt/appприложениеunit-файл, владелец сервиса

Возможные причины

  1. Malware после фишинга/трояна.
  2. Админский скрипт без заявки.
  3. Обновление ПО, которое мониторинг ещё не знает.
  4. Криптомайнер (CPU + сеть).
  5. Остаток отладки (nc, tcpdump забыли).
  6. Редко: руткит, прячущий exe — тогда расхождение ps vs ss, нужна память.

Диагностика

Сохраняйте вывод в IR-каталог.

1. Windows

Get-CimInstance Win32_Process | Where-Object { $_.ProcessId -eq 4242 } |
  Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine, CreationDate, CSName
Get-Process -Id 4242 | Select-Object Id, Path, Company, StartTime, CPU
Get-FileHash -Algorithm SHA256 -Path (Get-Process -Id 4242).Path
Get-AuthenticodeSignature -FilePath (Get-Process -Id 4242).Path
Get-NetTCPConnection -OwningProcess 4242 -ErrorAction SilentlyContinue
Get-CimInstance Win32_Process | Where-Object { $_.ParentProcessId -eq 4242 }

4688 (если аудит процесса включён):

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-24) } |
  Where-Object { $_.Message -match '4242|Temp\\svcupdate' }

Поднимите дерево вверх по ParentProcessId до services.exe/explorer.exe/winword.exe.

2. Linux host.example

ps -fp 4242
pstree -sp 4242
sudo ls -l /proc/4242/exe
sudo sha256sum /proc/4242/exe
tr '\0' ' ' < /proc/4242/cmdline; echo
tr '\0' ' ' < /proc/4242/environ | head -c 500; echo
sudo ss -tpn | grep 4242
sudo lsof -p 4242 | head
dpkg -S "$(sudo readlink /proc/4242/exe)" 2>/dev/null || rpm -qf "$(sudo readlink /proc/4242/exe)" 2>/dev/null

dpkg -S пустой на файл в /tmp — не пакет.

3. Сетевой след

Куда ходит: внутренний DC vs внешний IP. Внешний неизвестный + неизвестный бинарь = изоляция. Свой backup-порт — трафик.

Решение

Сценарий A. Явный чужой бинарь, сеть есть

  1. Изолировать узел (сеть), процесс пока можно оставить для дампа памяти, если IR так решит.
  2. Скопировать файл на IR-носитель (не шару пользователей).
  3. После копии — остановка процесса штатно (Stop-Process, systemctl stop, затем kill если не умер).
  4. Persistence: задачи, cron, службы.
  5. Переустановка/эталон для рабочей станции; для сервера — решение владельца.

Сценарий B. Похоже на своё ПО

Владелец сервиса подтверждает hash и путь. Внести в baseline мониторинга. Процесс не убивать.

Сценарий C. Уже умер, PID нет

Остаются Prefetch/Amcache, 4688, journalctl, файлы в Temp по mtime. Не объявляйте «само прошло».

Подпись, пакет и расхождение имени

После hash сверьте Get-AuthenticodeSignature / dpkg -S. Пустой Publisher и путь в C:\Users\ivan.petrov\AppData\Local\Temp на WS-042 — не «инсталлятор 1С». На host.example бинарь в /dev/shm или /var/tmp с сетевыми сокетами на 10.0.10.55 как dest — изоляция, не nice. Сохраните /proc/PID/maps (короткий head) если подозреваете injected thread: это улика, не инструкция injection.

Командная строка длиннее 2–3 КБ с -enc в PowerShell — фиксируйте, не запускайте decode на проде. Родитель services.exe vs winword.exe меняет класс инцидента. Если процесс уже (deleted), скопируйте /proc/PID/exe на IR-диск немедленно: после kill файла не будет.

Не убивайте сразу MsMpEng / rsyslog / ваш агент мониторинга «потому что CPU»: сначала путь. Ложный IR по собственному агенту хуже, чем лишние 10 минут, но неизвестный путь важнее чувства.

Как проверить, что проблема устранена

  • PID нет, бинарь в карантине/удалён после копии hash.
  • Автозапуск чист.
  • Нет повторного старта того же SHA-256.
  • Сеть узла соответствует решению (изолирован или возвращён).
  • Тикет содержит дерево PPID и hash.

Зафиксируйте integrity level / UID: процесс пользователя ivan.petrov vs SYSTEM/root меняет радиус ротации секретов. Сетевой dest 10.0.10.55 занесите в IOC, не пингуйте его с прод- hop «проверить, жив ли C2».

Если не помогло

  • Процесс перезапускается — systemd/задача/WMI, не один PID.
  • /proc/PID/exe = (deleted) — копируйте из /proc/PID/exe сразу, потом kill.
  • Имя как у ядра, UID не 0 vs 0 — смотрите exe path.
  • На всех серверах один hash — массовый деплой malware или забытый пакет; не лечите один узел.

Профилактика

  • Application control / подписанные бинари где зрелость есть.
  • Аудит 4688 хотя бы на серверах.
  • Запрет интерактива DA на серверах приложений.
  • Мониторинг процессов не из пакета (dpkg -V, инвентарь).
  • Temp не исполняемый (noexec) на Linux, где приложение позволяет. Хеш неизвестного PID всегда в тикет до kill. Не копируйте бинарь на пользовательскую шару «для коллег».

FAQ

Можно ли сразу удалить файл?

После hash и копии — да, если это не единственный образец и процесс остановлен. До hash — нет.

Task Manager «End task» на WS-042 пользователем

Для пользовательского adware иногда ок. Для сервера — нет, пока нет снимка.

Hash совпал с внутренним установщиком

Сверьте путь. Установщик в Temp после деплоя бывает. Командная строка и родитель решают.

Нужен ли полный RAM dump

Сервер / подозрение на ручной доступ / процесс прячется — да. Случайный onedrive.exe на ПК — обычно нет.

Процесс слушает 0.0.0.0

Это уже порт, не только PID.