Проверка после шифровальщика важнее восстановления

Восстановленные файлы еще не означают, что инцидент закончен. Пока команда не нашла точку входа, не отозвала захваченные сеансы, не убрала скрытый автозапуск и не доказала чистоту резервной копии, она возвращает в работу среду, к которой злоумышленник может подключиться снова.

Я видел, как восстановление объявляли победой сразу после запуска файлового сервера. Через несколько дней шифрование повторялось: пароль сервисной учетной записи не сменили, задача в планировщике пережила перезагрузку, а VPN продолжал принимать старые данные входа. После шифровальщика нужно вести расследование и восстановление как две связанные работы. Первая отвечает, что произошло и что еще доступно атакующему. Вторая возвращает сервисы из проверенного источника.

Сначала сохраните следы, потом меняйте среду

Сначала изолируйте затронутые узлы и сохраните недолговечные данные, а уже потом удаляйте файлы, переустанавливайте системы и массово меняйте настройки. Отключение сетевого порта или перевод устройства в карантин обычно лучше выключения питания: при выключении пропадает содержимое памяти, активные соединения и часть следов работающего вредоносного кода.

Руководство CISA #StopRansomware прямо советует снять образ диска и дамп памяти хотя бы с образцов затронутых рабочих станций, серверов, виртуальных и облачных машин. Там же отдельно названы журналы Windows Security и буферы межсетевых экранов, срок хранения которых может быть коротким. Это разумный минимум, но собирать один «самый зараженный» компьютер недостаточно. Нужны образцы разных ролей: первый замеченный узел, контроллер домена, сервер резервного копирования, шлюз удаленного доступа и система, с которой началось массовое изменение файлов.

Назначьте один момент отсечения и переведите все времена в UTC. Для каждого артефакта запишите имя узла, источник, время сбора, хеш файла и сотрудника, который его получил. Оригиналы сделайте доступными только для чтения, а анализ ведите на копиях. Даже если судебная экспертиза не планируется, такая дисциплина не дает команде перепутать след атаки с изменением, которое внес администратор во время восстановления.

Не запускайте подозрительный исполняемый файл и не отправляйте его во внешний анализатор без согласования. Образец может содержать конфиденциальные данные, а автоматическая отправка способна раскрыть сведения об инфраструктуре. Сначала посчитайте хеш и проверьте его по разрешенному процессу.

Минимальная карточка инцидента должна содержать:

• кто и когда заметил шифрование;
• какие узлы изолированы и каким способом;
• какие учетные записи временно заблокированы;
• где лежат неизменяемые копии журналов и образов;
• кто разрешает каждое действие по возврату в сеть.

С этого момента обычный рабочий чат тоже нельзя считать доверенным. CISA предупреждает, что оператор атаки может следить за коммуникациями жертвы. Для координации используйте заранее подготовленный независимый канал и не обсуждайте в скомпрометированной почте, какие доступы еще не закрыты.

Точку входа ищут от первого надежного события

Искать точку входа нужно назад от самого раннего подтвержденного вредоносного события, а не от времени появления записки с требованием выкупа. Шифрование часто завершает цепочку, перед ним могли быть дни доступа через VPN, почту, уязвимый внешний сервис или удаленное администрирование.

Соберите единую шкалу времени из источников, которые не зависят друг от друга: журналов контроллеров домена, VPN, почтовой системы, EDR, DNS, прокси, межсетевых экранов, гипервизора и панели резервного копирования. Сверяйте не только имена пользователей. Связывайте IP-адрес, имя устройства, идентификатор сеанса, процесс, родительский процесс и время. Если часы на части узлов расходились, зафиксируйте смещение, а не исправляйте старые отметки вручную.

Начните с четырех вопросов. Какой узел первым выполнил подозрительный процесс? Какая личность дала ему права? Откуда эта личность вошла? Как атакующий перешел на следующий узел? Ответ «фишинг» слишком общий. Нужны письмо, вложение или адрес, учетная запись, конечное устройство, первый процесс и дальнейшая команда. Ответ «RDP» тоже не закрывает расследование, пока не известны внешний адрес, шлюз, тип входа, учетная запись и причина, по которой этот доступ был разрешен.

Для Windows полезно выгрузить опорные события в CSV, не пытаясь читать тысячи строк в оснастке. Команду запускают на копии журнала или на изолированном узле с правами, которые разрешены процедурой расследования:

$start = Get-Date "2026-07-20T00:00:00Z"
$ids = 4624,4625,4648,4672,4688,4697,4698,4720,4728,4732,1102
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=$ids; StartTime=$start} |
  Select-Object TimeCreated, Id, MachineName, Message |
  Export-Csv .\security-timeline.csv -NoTypeInformation -Encoding UTF8

В результате получится таблица с временем, номером события, именем компьютера и сообщением. Событие 4624 означает успешный вход, но само по себе не доказывает атаку. Смотрите тип входа: 3 указывает на сетевой доступ, 10 обычно связан с удаленным интерактивным входом. Событие 4720 фиксирует создание пользователя, 4728 и 4732 добавление участника в группы, 4698 создание запланированной задачи, а 1102 очистку журнала аудита. Отсутствие события ничего не доказывает, если соответствующий аудит не был включен или журнал успел перезаписаться.

Проверьте внешние сервисы по всему периоду вероятного проникновения, включая дни до первого сигнала EDR. Ищите успешный вход после серии отказов, вход в необычное время, новый клиент VPN, эксплуатацию уязвимости, загрузку веб-оболочки и выполнение команды дочерним процессом веб-сервера. Если точку входа установить не удалось, честно обозначьте этот пробел и сохраните более жесткие ограничения. Нельзя превращать предположение в установленный факт ради красивого отчета.

Пароль меняют вместе с доверием к учетной записи

Скомпрометированную учетную запись нужно лишить всех способов вернуться, а не только нового пароля. Блокируйте вход, отзывайте активные и обновляемые токены, меняйте пароль, удаляйте неизвестные способы многофакторной аутентификации, проверяйте делегированные права и только затем возвращайте владельцу доступ с доверенного устройства.

Сначала разберите учетные записи по радиусу поражения. В первую очередь идут доменные и локальные администраторы, операторы резервного копирования, сервисные учетные записи, учетные записи гипервизора, VPN, почты, облачной панели и средств управления. Следом проверяйте пользователей, которые входили на зараженные узлы, потому что их пароли, хеши или билеты могли оказаться в памяти. Наконец, ищите новые учетные записи и тихое расширение членства в привилегированных группах.

Сброс пароля без отзыва сеансов оставляет открытым украденный токен. Microsoft в руководстве по устранению риска Microsoft Entra перечисляет для подтвержденно захваченной личности отдельные действия: заблокировать пользователя, отозвать refresh-токены, отключить скомпрометированные устройства и при необходимости отозвать access-токены. Этот порядок полезен и вне конкретного продукта: пароль, сеанс, устройство и второй фактор образуют разные границы доверия.

Проверьте у пользователя правила пересылки почты, делегатов ящика, согласия приложениям, новые ключи доступа, пароли приложений и зарегистрированные методы MFA. У сервисной учетной записи выясните, где хранится секрет и какие службы перестанут работать после ротации. Сначала подготовьте замену, затем смените секрет во всех зависимостях и отключите старый. Общий пароль локального администратора на нескольких машинах требует ротации на каждой из них, иначе один уцелевший хеш снова откроет весь парк.

Не заставляйте всех сотрудников менять пароли одновременно, если у вас нет признаков массовой кражи и безопасного канала для смены. Такая кампания перегружает поддержку, провоцирует предсказуемые пароли и может затереть полезные сигналы. Масштаб определяют по местам входа, дампам учетных данных, доступу к контроллерам домена и журналам аутентификации. Если контроллер домена полностью захвачен, обычной ротации пользовательских паролей недостаточно: нужен отдельный план восстановления каталога и последовательной смены секретов доверия.

Перед снятием блокировки получите от владельца подтверждение последних входов и действий, но не считайте человеческую память источником истины. Сопоставьте ответ с журналами. Атакующий может пользоваться привычным IP через захваченный сеанс или корпоративный VPN.

Автозапуск проверяют шире папки Startup

Проверка автозапуска должна охватывать задачи, службы, драйверы, WMI, ключи Run и RunOnce, сценарии входа, подписки событий и изменения групповых политик. Просмотр одной вкладки диспетчера задач создает опасное чувство чистоты.

Microsoft Sysinternals Autoruns показывает многие точки автоматического запуска, умеет проверять цифровые подписи, считать хеши и выгружать CSV. Официальное описание отдельно упоминает задачи, службы, Winlogon, расширения оболочки, AppInit DLL и конфигурацию других профилей. Опция скрытия подписанных записей Microsoft полезна для первичного разбора, но нельзя использовать ее как окончательный фильтр: злоумышленник может подменить путь, загрузить уязвимый подписанный драйвер или злоупотребить легитимным бинарным файлом.

Снимите повторяемый набор данных до удаления подозрительной записи:

autorunsc.exe -accepteula -a * -c -h -s -t > autoruns.csv
schtasks /query /fo CSV /v > scheduled-tasks.csv
sc.exe query type= service state= all > services.txt

В autoruns.csv будут категория точки запуска, имя записи, описание, издатель, путь, время и хеши. В выгрузке планировщика видны имя задачи, команда, пользователь, триггеры и время выполнения. Сравните результаты с эталоном аналогичного чистого узла той же роли и сборки. Редкая запись не обязательно вредоносна, а знакомое имя не делает файл безопасным.

Для каждой находки ответьте, кто ее создал, когда, под какой учетной записью и какой файл или интерпретатор она запускает. Затем проверьте хеш, подпись, родительский каталог, разрешения на запись и сетевые обращения. Команда powershell.exe в задаче мало что говорит без аргументов. Закодированная строка, запуск из профиля пользователя, временного каталога или общей папки требует разбора даже при безобидном названии задачи.

Сопоставьте состояние с аудитом. Событие Security 4698 фиксирует создание задачи, если аудит был включен. Для служб полезны Security 4697 и System 7045. MITRE ATT&CK относит запланированные задачи к технике T1053.005, но идентификатор техники не заменяет доказательство. Он помогает не забыть механизм и построить запросы, а решение принимают по конкретной команде, времени и контексту.

Не удаляйте находку сразу. Экспортируйте конфигурацию, сохраните исполняемый файл в контролируемом хранилище, посчитайте хеш, затем отключите механизм. Иначе вы уничтожите связь между учетной записью, командой и временем, а позже не сможете проверить другие узлы по тому же признаку.

Горизонтальное перемещение связывает узлы в одну историю

Масштаб инцидента определяют по тому, куда атакующий мог войти, а не по числу зашифрованных компьютеров. Незашифрованный контроллер домена, гипервизор или сервер резервного копирования может быть важнее десятков поврежденных рабочих станций, если на нем сохранилась скрытая точка доступа.

Постройте граф «учетная запись - исходный узел - целевой узел - способ входа - время». Для Windows сопоставляйте 4624 с типами входа 3 и 10, явное использование других учетных данных в 4648, назначение особых прав в 4672 и создание процессов в 4688. Добавьте журналы SMB, WinRM, RDP, WMI, удаленного управления, EDR и межсетевых экранов. Одинаковая команда на пяти серверах с разницей в минуты часто полезнее, чем отдельный антивирусный вердикт.

Обратите внимание на административные общие ресурсы, удаленное создание служб, запуск через WMI, PsExec-подобное поведение и входы сервисных учетных записей на рабочие станции. У штатного сервиса обычно есть стабильный маршрут. Если учетная запись резервного копирования внезапно входит интерактивно на пользовательский компьютер, это требует объяснения.

Разделите узлы на четыре состояния: подтвержденно затронут, вероятно затронут, наблюдается и проверенно чист. Последнее состояние присваивайте только после проверки критериев, а не потому, что антивирус ничего не нашел. Зафиксируйте, какие журналы подтверждают вывод и какой период они покрывают. Пробел в телеметрии должен повышать осторожность.

Приоритизируйте системы, где сходятся полномочия: контроллеры домена, центры управления, серверы виртуализации, хранилища секретов, резервное копирование и средства развертывания. Через такую систему атакующий может снова разнести инструмент уже после восстановления. Ее нельзя возвращать в сеть по тем же правилам, что обычную рабочую станцию.

Резервную копию проверяют на чистоту и независимость

Хорошая резервная копия содержит нужные данные до проникновения, не управляется захваченной личностью и действительно восстанавливается в изолированной среде. Зеленый статус последнего задания подтверждает только выполнение задания, но не чистоту точки восстановления.

Сначала сохраните журналы панели резервного копирования и историю изменений политики. Ищите удаление точек, сокращение срока хранения, отключение неизменяемости, добавление администратора, смену репозитория и необычные задания восстановления. Проверьте, не использует ли консоль тот же каталог, те же администраторские учетные записи и тот же MFA-контур, что пострадавшая среда. Копия может быть физически цела, но доступ к ней уже принадлежит атакующему.

Выбирайте точку восстановления по шкале проникновения, а не по моменту шифрования. Если первый подтвержденный доступ был 10 июля, копия от 19 июля, вероятно, вернет и оставленную задачу, веб-оболочку или измененную учетную запись. Чем раньше точка, тем больше потеря данных, поэтому данные и системное состояние иногда восстанавливают по-разному: чистую систему собирают заново, а документы возвращают после проверки из более свежей копии.

Проведите тест в сети без маршрута в производство. Восстановите хотя бы один экземпляр каждой важной роли, загрузите систему, проверьте файловую систему и приложения, просканируйте ее обновленными средствами и сравните конфигурацию с доверенным эталоном. Затем выполните прикладную проверку: откройте выборку документов, поднимите базу с проверкой целостности, выполните контрольную транзакцию, проверьте права и зависимости. Хеш архива не отвечает на вопрос, работоспособна ли база внутри него.

Для каждой критичной системы запишите результат пяти проверок:

1. Точка создана до самого раннего вероятного проникновения.
2. Репозиторий не доступен из обычного домена на запись.
3. Административные секреты хранилища заменены с доверенного устройства.
4. Восстановление завершилось в изолированной среде без ошибок.
5. Владелец сервиса подтвердил целостность и бизнес-функцию.

CISA рекомендует офлайн-копии, шифрование и регулярные тесты доступности и целостности. Я бы добавил еще одно требование: тест должен заканчиваться измеренным временем и доказательством работы приложения. Фраза «мы когда-то восстанавливали файл» ничего не говорит о том, сколько займет подъем каталога, гипервизора или крупной базы в день инцидента.

Не подключайте старый сервер резервного копирования к новой среде только ради удобства. Если доверие к его операционной системе или учетной записи потеряно, разверните чистую консоль и подключайте репозиторий по процедуре поставщика. Иначе надежная копия окажется за тем же скомпрометированным пультом.

Чистая сборка надежнее лечения на месте

Подтвержденно затронутые узлы нужно переустанавливать из доверенного образа, а не «лечить» до зеленого статуса антивируса. Средство защиты на работающей системе видит не все изменения, а администратор не может доказать отсутствие неизвестной службы, драйвера, политики или измененного системного файла.

Соберите образ из известного источника, проверьте его хеш и подпись, установите текущие обновления, включите журналирование и средство обнаружения до подключения к рабочим сегментам. Не клонируйте машину, которая просто выглядит здоровой. Эталон тоже должен иметь владельца, дату сборки, перечень пакетов и воспроизводимый процесс.

Порядок зависимостей имеет значение. Сначала восстановите управление идентификацией и временем, затем DNS, средства защиты и журналирования, управление конфигурациями, резервное копирование и только после этого прикладные сервисы. Если сначала поднять приложения, они начнут доверять старым паролям, старым сертификатам и невидимым журналам.

Данные отделяйте от исполняемого состояния. Документ, таблица и запись базы требуют проверки содержимого, но не должны возвращать старую задачу, сценарий входа или бинарный файл из системного каталога. Макросы, архивы, установщики и скрипты из пользовательских папок проверяйте строже. Разрешение «восстановить все как было» удобно только до второй атаки.

Лечение на месте допустимо для сохранения доказательств или временного получения данных, когда переустановка технически невозможна. Такой узел не получает статус чистого и не становится источником образа. Его изолируют, ограничивают срок работы и планируют замену.

Закрывайте причину, а не один индикатор

Меры после инцидента должны разорвать путь атаки, повысить цену горизонтального перемещения и сделать повтор заметным. Блокировка одного IP-адреса или хеша популярна, потому что выполняется быстро и дает закрыть пункт отчета. Она не мешает оператору сменить адрес, пересобрать файл или войти украденной учетной записью.

Для подтвержденного внешнего входа исправьте конкретную причину. Уязвимый сервис обновите или уберите из интернета, а до проверки держите закрытым. Для удаленного доступа сократите список пользователей и источников, включите устойчивую к фишингу MFA, запретите прямой RDP и журналируйте попытки. Для почты устраните правило или приложение, через которое закрепился атакующий, и проверьте аналогичные объекты во всем арендаторе.

Ограничьте административные маршруты. Администратор не должен читать почту и открывать браузер из привилегированной сессии. Сервисная учетная запись получает только нужные права и не входит интерактивно. Разные уровни администрирования используют разные учетные записи и доверенные рабочие станции. Сегментация должна запрещать неожиданный трафик, а не только рисовать зоны на схеме.

Включите аудит до следующего инцидента. Храните журналы централизованно так, чтобы администратор конечного узла не мог стереть единственную копию. Оповещения нужны на создание учетной записи, изменение привилегированной группы, новую задачу или службу, отключение защиты, очистку журнала, изменение политики резервного копирования и необычный вход в консоль управления.

NIST SP 800-61 Rev. 3 связывает реагирование с общим управлением киберриском, а не с отдельной работой после тревоги. Это практичная позиция: если владелец сервиса, сроки хранения журналов, зависимости и допустимая потеря данных не определены заранее, в ночь атаки команда будет спорить о них под давлением.

Возвращайте системы через измеримые шлюзы

Возврат в сеть разрешают по критериям, а не по усталости команды или просьбе бизнеса «хотя бы проверить». Для каждой системы владелец расследования подтверждает область компрометации, инженер подтверждает чистую сборку, владелец приложения принимает данные, а ответственный за риск понимает оставшиеся пробелы.

Удобно задать четыре шлюза. Первый допускает систему только в изолированную среду для обновления и сканирования. Второй открывает ограниченные зависимости, например DNS, время, журналирование и управление. Третий разрешает тестовый пользовательский трафик. Четвертый возвращает штатную нагрузку после периода усиленного наблюдения. На каждом этапе должен быть способ быстро изолировать узел без импровизации.

Наблюдайте за признаками, связанными с найденной цепочкой, и за общими отклонениями. Повторный вход старой учетной записи, обращение к закрытому адресу управления, создание похожей задачи или отключение агента защиты должны немедленно останавливать продвижение. Отсутствие тревог в первые часы не сокращает согласованный период наблюдения.

Смена паролей должна предшествовать подключению восстановленных устройств, иначе старый узел может снова раскрыть новый секрет. Но пароль меняют с доверенного устройства. Если пользователь вводит новый пароль на машине, которую еще не переустановили, ротация теряет смысл.

Заранее определите откат: кто принимает решение, какой сетевой доступ отключается и какая точка данных остается безопасной. Без отката команда склонна объяснять подозрительный сигнал «шумом», потому что повторная остановка кажется слишком дорогой.

Разбор инцидента должен менять архитектуру

Итоговый разбор должен превратить подтвержденные факты и неизвестные области в задачи с владельцами, сроками и проверкой результата. Хронология без решений полезна следователю, но не защищает организацию от повторения.

Разделите выводы на причины, условия и последствия. Причиной мог быть незащищенный внешний сервис. Условиями стали избыточные права учетной записи, плоская сеть и короткое хранение журналов. Последствием оказалась остановка нескольких систем. Такое разделение мешает свести работу к одному патчу и помогает увидеть, почему один вход превратился в общий инцидент.

Для каждого изменения задайте проверяемый результат. «Усилить резервное копирование» не проверяется. «Раз в квартал восстанавливать каталог и одну базу в изолированном сегменте, фиксировать время и подпись владельца» проверяется. «Включить MFA» слабее, чем перечень систем, пользователей, разрешенных методов и отчет об исключениях.

Технический долг после шифровальщика часто упирается в оборудование, которое не поддерживает актуальную ОС, изоляцию управления или требуемое время восстановления. При такой модернизации GSE.kz может подобрать и интегрировать серверную и дата-центровую инфраструктуру с учетом локального производства, цепочки поставок и дальнейшей поддержки, но критерии безопасности и приемки заказчик все равно должен зафиксировать сам.

Закройте инцидент только после проверки мер. Повторите сценарий входа в контролируемом тесте, убедитесь, что новый контроль его блокирует или обнаруживает, восстановите систему еще раз и проверьте отзыв старых учетных данных. Если точка входа осталась неизвестной, это не формальность в отчете. Это основание дольше хранить сегментацию, расширить наблюдение и не возвращать прежний уровень доверия.