Что делать при заражении шифровальщиком: первый час — АйТи Фреш
АйТи Фреш
Информационная безопасность

Офис заражён шифровальщиком: что делать в первые 60 минут

Автор: , директор ООО «АйТи-Фреш» · · ~16 мин чтения
Отключение заражённого компьютера от сети в офисе: первый час при заражении шифровальщиком
Сначала отрезать от сети, потом разбираться: порядок действий важнее скорости.

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

Что делать при заражении шифровальщиком в первую минуту

Я занимаюсь информационной безопасностью малых офисов больше пятнадцати лет, и первый звонок об инциденте почти всегда звучит одинаково: «у нас все файлы переименовались, и лежит какая-то записка». Дальше у директора есть минут пять, чтобы либо взять ситуацию в руки, либо потерять ещё полсервера. Поэтому первое правило простое: никто ничего не перезагружает, не «лечит» и не удаляет. Один человек, обычно сисадмин или я по телефону, берёт на себя командование, остальные выполняют его просьбы. Шум в такие минуты стоит дороже любой ошибки в команде.

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

Я советую заранее распечатать этот список и положить его туда, где его найдёт не только сисадмин. Первое: отключить заражённый компьютер от сети, выдернув кабель или выключив Wi-Fi, но питание не трогать. Второе: сказать коллегам по соседству не открывать почту и не заходить на общие папки. Третье: позвонить тому, кто отвечает за ИТ, голосом, а не писать в чат, потому что чат и почта могут быть под наблюдением. Это же советует и американское агентство CISA в руководстве по реагированию на вымогатели: связываться вне сети, чтобы не спугнуть злоумышленников.

Отдельно скажу про вопрос, который задают сразу: платить ли. Моя позиция жёсткая: нет, и точно не в первый час. Платёж не гарантирует расшифровку, не лечит дыру, через которую зашли, и не отменяет утечку, если данные унесли. Сначала нужно понять масштаб и проверить, что цело. Часто выясняется, что платить просто не за что: рабочая копия лежит на отключённом диске, а на живых машинах нужно только переустановить систему. На проекте nomoreransom.org прямо написано, что общий совет такой: не платить, и я с этим согласен.

Как изолировать заражённые компьютеры: минуты 5–20

Цель этого этапа одна: остановить распространение. Порядок я использую такой. Сначала физическое отключение известных заражённых рабочих станций: кабель из розетки, Wi-Fi выключить. Затем файловый сервер, потому что именно через сетевые папки шифрование расползается лучше всего. Если вы видите, что заражено много машин и понять границы не получается, действуйте как рекомендует CISA: отключайте сеть на уровне коммутатора, вплоть до выдёргивания uplink. Работа офиса встанет, но это дешевле, чем потерянный сервер 1С. Выключать питание нужно только если отсоединить машину от сети нельзя, и об этом то же руководство предупреждает отдельно.

На файловом сервере я сначала смотрю, кто сейчас с ним работает. Это даёт список подозрительных компьютеров и пользователей. Команды для PowerShell на сервере: Get-SmbSession показывает сеансы, Get-SmbOpenFile — открытые файлы, у обоих есть поля ClientComputerName и ClientUserName. Закрыть сеанс принудительно можно через Close-SmbSession. Microsoft прямо предупреждает, что это может привести к потере данных, если клиент не успел сбросить изменения, но в нашей ситуации это приемлемая цена.

# Кто сейчас подключён к шарам сервера
Get-SmbSession | Select-Object SessionId, ClientComputerName, ClientUserName

# Какие файлы у них открыты
Get-SmbOpenFile | Select-Object ClientComputerName, ClientUserName, Path

# Принудительно закрыть сеансы заражённого компьютера (адрес из документации)
Close-SmbSession -ClientComputerName 192.0.2.57 -Force

Закрытие сеанса не спасает надолго: если вредонос ещё работает, клиент переподключится. Поэтому вторым шагом блокируем доступ. Если известна учётная запись, под которой идёт шифрование, добавляем явный запрет на шару командой Block-SmbShareAccess. Она добавляет запрещающую запись в дескриптор безопасности шары, а значит, пользователь выпадет из доступа даже при переподключении. Но это полумера. Я ставлю её только на время, пока не отключена сеть, и потом снимаю запрет командой Unblock-SmbShareAccess с теми же -Name и -AccountName. Главное решение всё равно физическое: порт коммутатора в shutdown либо кабель отдельно от компьютера.

# Закрыть доступ учётной записи к конкретной шаре (имена условные)
Block-SmbShareAccess -Name Raskroy -AccountName 'EXAMPLE\ivanova' -Force

Если у вас сервер не физический, а виртуальный на Hyper-V, есть нюанс. Выключить виртуальную машину жёстко можно командой Stop-VM с ключом -TurnOff, это аналог выдёргивания питания. Но память при этом пропадёт. Ключ -Save сохраняет состояние машины, и это лучше для разбора: потом можно разобраться, что в ней происходило. Отключить сетевой адаптер на самом сервере можно через Disable-NetAdapter, но Microsoft предупреждает: не отключайте адаптер, через который вы управляете машиной, иначе потеряете доступ и не сможете вернуть его удалённо. Поэтому на сервере, к которому вы подключены по RDP, я отключаю сеть со стороны коммутатора, а не из сеанса.

# Сохранить состояние виртуальной машины вместо жёсткого выключения
Stop-VM -Name FS01 -Save

# На консоли (не по RDP!) отключить сетевой адаптер
Disable-NetAdapter -Name 'Ethernet' -Confirm:$false
Не отключайте сетевой адаптер из сеанса RDP на том же сервере: Microsoft прямо предупреждает, что доступ после этого удалённо не вернуть. Для удалённых серверов изолируйте порт на коммутаторе или виртуальный адаптер в консоли гипервизора.

Что сохранить до любых действий: минуты 20–35

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

Журналы я вывожу штатной утилитой wevtutil. Команда epl экспортирует журнал в файл .evtx, а ключ /ow:true перезаписывает файл, если он уже существует. Экспортировать я советую журналы Security, System и Application, причём не на сетевую шару, а на отдельный внешний диск. В документации Microsoft пример именно такой: wevtutil epl System C:\backup\system0506.evtx. Если журнал безопасности на заражённой машине очищен, это само по себе признак, что у атакующих были права администратора, и важная информация для следующих шагов.

# Экспорт журналов на чистый внешний диск E:
wevtutil epl Security E:\evidence\fs01-security.evtx /ow:true
wevtutil epl System E:\evidence\fs01-system.evtx /ow:true
wevtutil epl Application E:\evidence\fs01-application.evtx /ow:true

Про образ диска и снимок памяти скажу честно: в офисе на 40 компьютеров делать это на каждой машине бессмысленно. Руководство CISA рекомендует снимать образ системы и дамп памяти на выборке заражённых устройств, и этого достаточно. Я выбираю одну рабочую станцию и один сервер, самые показательные. Для виртуальных машин проще: снимок или сохранённое состояние виртуальной машины даёт то же самое без дополнительных утилит. Если вы не уверены, как правильно снимать дамп, не делайте этого сами. Лучше оставить машину изолированной и включённой, чем испортить улики.

Теперь определение семейства. Зная название вымогателя, можно проверить, существует ли бесплатный расшифровщик. Для этого есть проект No More Ransom и его сервис Crypto Sheriff: загружаете два зашифрованных файла и текст записки (или адрес из неё), сервис подсказывает, есть ли готовый инструмент. Я бы не надеялся на такой исход: для свежих семейств расшифровщиков обычно нет. Но проверка занимает пять минут и иногда спасает. Отдельный разговор про заявление в полицию. Я рекомендую подавать его всегда, даже если не рассчитываете на результат: оно нужно для страховки, для налоговой в части списания убытков и в том случае, если позже всплывёт утечка. Копии записки и журналов пригодятся и здесь.

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

Что цело и что можно восстановить: минуты 35–50

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

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

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

Теперь учётные записи. В первый час я меняю пароли только тем администраторам, которые работали на заражённых машинах, и только с заведомо чистого компьютера, подключённого к отдельному сегменту. Сброс пароля учётки krbtgt, которая отвечает за выдачу билетов Kerberos, делать нужно, но не сейчас. Microsoft описывает процедуру так: операцию выполняют дважды, между сбросами нужно выждать минимум 10 часов, потому что это значение по умолчанию для максимального срока жизни билета пользователя и службы, и если политику меняли, ждать нужно дольше. Делать это нужно после того, как окружение зачищено, иначе вы просто сбросите пароль, который атакующие получат снова.

Кого уведомить и как подать заявление: минуты 50–60 и дальше

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

Дальше юридическая сторона. Если в атакованных системах хранились персональные данные клиентов или сотрудников, и есть основания считать, что они могли утечь, у оператора возникают обязательства перед Роскомнадзором. По части 3.1 статьи 21 закона 152-ФЗ первичное уведомление об инциденте подают в течение 24 часов с момента выявления, а дополнительное с результатами внутреннего расследования в течение 72 часов. Я рекомендую не полагаться на память и сверить актуальную редакцию закона и порядок подачи на сайте Роскомнадзора. Если вы относитесь к субъектам критической информационной инфраструктуры, у вас есть отдельные требования, и их нужно изучить заранее.

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

Теперь о том, что делать дальше, когда час прошёл. В течение суток нужно найти точку входа, проверить, остались ли у атакующих доступы, и только затем восстанавливаться. Я разбираю такой путь подробно в реальном кейсе восстановления за 18 часов. Там видно, сколько занимает восстановление, когда первый час прошёл правильно.

Меры, которые снижают шанс повторения, я собрал в чек-листе защиты от шифровальщиков для офиса на 50 ПК. А эта статья про другое: про первый час, когда решения принимаются на ходу, и главное не навредить. Я специально не дублирую здесь профилактику: в первый час она уже не поможет, зато после разбора к ней нужно вернуться в первую же неделю, пока директор помнит цену простоя.

Кейс: пошивочное предприятие «АтельеПошив», 46 рабочих мест

Приведу случай условного клиента, пошивочного предприятия «АтельеПошив»: 46 рабочих мест, из них 12 в цехе у станков с ЧПУ-раскроем и принтерами этикеток, остальные в офисе, бухгалтерии и на складе. Инфраструктура обычная: один Hyper-V хост с двумя виртуальными машинами (файловый сервер и сервер 1С), домен Active Directory, бэкап ночью на сетевое хранилище и раз в неделю на внешний диск, который хранился в сейфе. До этого дня план реагирования существовал только в моей голове, и я как раз собирался распечатать его для директора.

В десять утра сотрудница отдела раскроя позвонила директору: файлы с лекалами не открываются, рядом лежит записка. Директор позвонил мне, и мы пошли по описанному выше порядку. Первые пять минут ушли на то, чтобы найти, на какой машине это началось, и отключить её от сети. Ещё пятнадцать минут — на то, чтобы сисадмин на месте закрыл сеансы к файловому серверу и отключил порт коммутатора для девяти подозрительных компьютеров. Сервер 1С мы не тронули, пока не убедились по консоли администрирования серверов 1С и Get-SmbSession, что к нему нет сеансов из заражённого сегмента.

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

Итог в цифрах: шифрование затронуло 9 рабочих станций и часть сетевых папок раскроя. Простой цеха составил один рабочий день для 12 человек, остальные работали с резервной копией. Данные на станциях не потеряли, потому что рабочие файлы хранились на сервере. Полдня правок по двум лекалам пришлось повторить вручную. Рабочие станции переустановили за два дня, пароли доменных администраторов поменяли, сброс krbtgt сделали дважды с паузой по правилам Microsoft. После этого мы внедрили то, о чём долго говорили: хранение копии вне домена и отдельный план на листе А4 на стене у администратора.

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

Частые вопросы

Можно ли выключать зараженный компьютер из розетки?

Сначала отключите его от сети кабелем или Wi-Fi. Питание выключайте, только если отсоединить от сети невозможно: так вы сохраните данные из памяти для разбора. Это согласуется с руководством CISA, где отключение питания названо крайней мерой.

Платить ли выкуп шифровальщику?

Я не рекомендую. Платёж не гарантирует расшифровку, не закрывает дыру и не отменяет возможную утечку. Сначала проверьте резервные копии и наличие бесплатного расшифровщика на nomoreransom.org, где прямо советуют не платить.

Как понять, цела ли резервная копия?

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

Когда сбрасывать пароль krbtgt?

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

Нужно ли уведомлять Роскомнадзор об атаке шифровальщика?

Если затронуты персональные данные и возможна их утечка, по части 3.1 статьи 21 закона 152-ФЗ первичное уведомление подают в течение 24 часов, дополнительное в течение 72 часов. Сверьте актуальную редакцию закона и порядок подачи перед отправкой.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи