Алерт трояна: не «разрешить угрозу», а сеть долой и охота за автозапуском

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

Детект трояна Microsoft Defender / другого AV — это не закрытый инцидент, пока не проверены закрепление и сеть. Изолируйте WS-042 (или host.example), сохраните Threat ID, путь, SHA-256, журнал Operational 1116/1117. Затем проверьте persistence: Run-ключи, службы (7045), задачи (4698), WMI, cron/systemd. Не жмите «Allow» и не отключайте real-time «на час». Не считайте карантин доказательством, что C2 мёртв.

Связанные ветки: фишинговое вложение, неизвестный процесс, изоляция.

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

• Тост Defender / карточка EDR: Trojan:Win32/... на C:\Users\ivan.petrov\....
• Повтор через час — файл снова появляется (dropper жив или задача).
• На Linux: ClamAV/rkhunter находка в /tmp или в домашнем ivan.petrov.
• Исходящие соединения процесса после детекта.

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

1. Вложение/ссылка, макрос, ISO с почты.
2. Скачанный «кряк/кодек», браузер пользователя.
3. Уже скомпрометированная учётка, повторная загрузка.
4. Заражённая флешка.
5. Supply-chain своего ПО (редко) — решает владелец пакета, не «Allow».
6. Ложное срабатывание после обновления сигнатур.

Не привязывайте инцидент к выдуманному CVE. Если вендор AV назвал конкретное семейство — этого достаточно для классификации.

Диагностика

С hop-хоста после изоляции сети (консоль/RDP с jump, если ещё безопасен; иначе гипервизор).

1. Карточка угрозы

Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, IoavProtectionEnabled, AntispywareEnabled
Get-MpThreatDetection | Format-List *
Get-MpThreat | Format-List *
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 30 |
  Where-Object { $_.Id -in 1116,1117,5001,5007 }

5001 (real-time disabled) в том же окне — отдельный красный флаг: кто-то глушил защиту.

2. Persistence Windows

Get-CimInstance Win32_StartupCommand | Format-Table User, Command, Location
Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Get-ItemProperty HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Get-ScheduledTask | Where-Object { $_.State -ne 'Disabled' } | Select-Object TaskName, TaskPath, Date
Get-Service | Where-Object { $_.StartType -eq 'Automatic' } | Select-Object Name, Status
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=7045; StartTime=(Get-Date).AddDays(-7) }
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4698; StartTime=(Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue

Сверяйте пути с ThreatPath из Defender. Неизвестная служба с бинарником в Temp — persistence, не «драйвер принтера».

3. Persistence Linux на host.example

systemctl list-unit-files --type=service,timer --state=enabled
crontab -u ivan.petrov -l
sudo ls -la /etc/cron.* /var/spool/cron/crontabs 2>/dev/null
sudo ls -la /etc/systemd/system /lib/systemd/system | head
ls -la ~/.config/autostart 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls

4. Сеть и процесс

См. соседнюю статью про процесс: PID, Get-NetTCPConnection, ss. Снимите hash до карантина, если файл ещё на диске.

Get-AuthenticodeSignature -FilePath 'C:\Path\from\Defender.exe'

Неподписанный бинарь в Temp плюс 1116 — достаточный повод не возвращать ПК в VLAN до переустановки.

Решение

Сценарий A. Рабочая станция пользователя

1. Изоляция сети.
2. Копия журналов Defender + Security + задачи.
3. Карантин штатным Defender (Remove-MpThreat только после копии IOC).
4. Смена пароля ivan.petrov из другого канала — учётки.
5. Типовой исход: переустановка ОС с сохранением документов из backup, не «почистили и в прод». Persistence легко переживает «удалили exe».

Сценарий B. Сервер

Не переустанавливайте вслепую в первый час. Изоляция, артефакты, сверка служб с эталоном, решение владельца сервиса. Если троян в webroot — дефейс / WordPress спам.

Сценарий C. Ложное срабатывание

Владелец бинарника подтверждает hash и подпись. Снятие из карантина — заявка, не чат. Defender остаётся On.

На WS-042 после 1116 смотрите 4688 около того же времени и Established на 10.0.10.55, если это C2. Учётка ivan.petrov — кандидат на смену пароля, даже если «троян поймали».

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

• Get-MpThreatDetection без активных необработанных угроз и нет новых 1116 за период наблюдения.
• Run/Tasks/Services/cron сверены, неизвестное удалено или объяснено.
• Real-time Enabled, Tamper Protection не снят.
• Учётка: сессии сброшены, пароль сменён, если был риск кражи.
• Хост не в прод-сети, пока нет решения «переустановка / вернуть».
• На соседних ПК нет того же hash (поиск по имени файла/хешу в EDR или точечно).

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

• 5001 повторяется GPO — политика выключает Defender, это уже hardening, не «троян сам».
• Файла нет, 1116 есть — успели стереть; опирайтесь на журнал и persistence.
• Linux: пакетный ClamAV на системных ELF без контекста — проверьте, не сканируете ли /usr эталоном с ложными; не chmod 777 «чтобы сканер прошёл».
• После переустановки тот же троян — учётка/почта/вложение живы, чистите ящик и пароли, не только ПК.

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

• Defender + Tamper Protection + облачная сдача образцов по политике организации.
• Запрет локального админа пользователю на WS-042.
• ASR/макросы из интернета, если уже принято.
• Почта: вложения exe/iso/js.
• Алерт на 1116 + 7045 + 4698 в одном окне.

FAQ

Достаточно ли кнопки «Удалить» в тосте Defender?

Для файла — возможно. Для инцидента — нет. Нужны persistence и сессии учётки.

Можно ли оставить ПК в сети, если карантин Successful?

Нет, пока не проверены задачи и сеть процесса. C2 мог отработать до карантина.

Нужен ли полный memory dump всегда?

Если это VIP/сервер или подозрение на ручной доступ — да, по артефактам. Для типового пользовательского PUA — журналы + переустановка часто рациональнее. Решает IR, не пользователь.

Антивирус другой фирмы, не Defender

Тот же порядок: карточка детекта, изоляция, автозапуск, не отключать продукт. Команды выше — для штатного Defender на Windows 10/11 и Server 2019/2022.

Обнаружили на файловой шаре, не на ПК

Изолируйте кто писал (SMB session), не только карантин файла. Иначе dropper положит копию снова.