Как вытащить файлы базы данных MS SQL Server (MDF и LDF) при заражении системы шифровальщиком

Ситуация, когда сервер подвергается атаке вируса-шифровальщика, является критической для любого бизнеса. В данной статье мы разберем специфический случай заражения вирусом Ryuk, при котором операционная система и большинство файлов оказались зашифрованы, однако файлы базы данных MS SQL Server остались нетронутыми благодаря механизмам защиты самой СУБД. Проанализируем, как можно спасти данные в такой ситуации, какие инструменты использовать и как избежать окончательной потери информации.

Почему шифровальщики не всегда могут уничтожить базы SQL

Рассмотрим техническую причину, по которой автору темы удалось спасти данные. В MS SQL Server реализован механизм, называемый Exclusive Lock (эксклюзивная блокировка). Когда служба SQL-сервера sqlservr.exe активна и база данных находится в работе, операционная система блокирует доступ к файлам .mdf и .ldf для любых сторонних процессов на уровне файловой системы. Пока работает процесс сервера, вирус-шифровальщик не может получить права на запись в открытый поток файла, так как файл занят другим приложением.

Однако стоит учитывать особенности поведения современных вирусов, таких как Ryuk. Разберем их тактику:

1. Остановка служб: Вирус первым делом пытается остановить более 40 различных служб, включая SQLServer, SQLWriter и службы антивирусной защиты.
2. Удаление теневых копий: Выполняется команда vssadmin.exe Delete Shadows /All /Quiet, что делает невозможным стандартное восстановление через точки отката Windows.
3. Шифрование: Только после остановки служб и высвобождения файлов вирус приступает к их модификации.

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

Шаг 1: Первоочередные действия при обнаружении атаки

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

• Изоляция сервера: Немедленно отключите сервер от локальной сети и интернета. Это предотвратит распространение вируса на другие машины и не позволит хакерам управлять процессом шифрования удаленно.
• Запрет на перезагрузку: Ни в коем случае не перезагружайте сервер через стандартное меню Windows. Многие шифровальщики прописывают себя в автозагрузку или в службы, которые при старте системы первым делом завершают работу SQL-сервера и дошифровывают то, что не успели ранее.
• Физическое выключение: Если вы понимаете, что вирус продолжает активность прямо сейчас, самым безопасным вариантом будет «выдернуть шнур из розетки». Это приведет к аварийному завершению работы SQL, но сохранит файлы в том виде, в котором они были на момент отключения питания.

Шаг 2: Использование Live CD для извлечения данных

Выясним, почему этот метод оказался самым эффективным. Когда мы загружаемся с внешнего USB-носителя (Live CD/USB) с операционной системой (например, WinPE или Linux), основная зараженная ОС остается неактивной. Вирус не запускается, а значит, не может препятствовать копированию файлов.

Порядок действий:

1. Подготовьте загрузочную флешку (Live CD) на заведомо чистом компьютере.
2. Загрузите зараженный сервер с этой флешки. Проверьте, видит ли загрузочная ОС ваши диски (особенно если используется RAID-контроллер, могут потребоваться специфические драйверы).
3. Найдите файлы базы данных. По умолчанию они располагаются по пути: C:\Program Files\Microsoft SQL Server\MSSQL.x\MSSQL\DATA\
4. Скопируйте все файлы с расширениями .mdf (данные) и .ldf (лог транзакций) на чистый внешний жесткий диск.

Шаг 3: Проверка целостности и восстановление базы

После того как файлы извлечены, их необходимо подключить к другому, чистому экземпляру MS SQL Server. Посмотрим на возможные проблемы. Так как мы копировали файлы «на горячую» или после резкого отключения сервера, база данных может оказаться в состоянии Inconsistent (несогласованном).

При попытке подключения (Attach) в SQL Server Management Studio (SSMS) вы можете увидеть статус Recovery Pending или Suspect. В этом случае нам помогут команды DBCC CHECKDB.

Разберем пример кода для проверки и исправления базы:

-- Переводим базу в однопользовательский режим для восстановления
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- Проверяем базу на ошибки
DBCC CHECKDB ('Имя_Вашей_Базы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

-- Если найдены ошибки, используем исправление с возможной потерей данных
-- (использовать только если нет другого выхода!)
DBCC CHECKDB ('Имя_Вашей_Базы', REPAIR_ALLOW_DATA_LOSS);
GO

-- Возвращаем многопользовательский режим
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
GO

Шаг 4: Конвертация в формат 1С (.dt)

Если ваша база данных используется для работы с 1С:Предприятие, после успешного подключения к SQL-серверу рекомендуется выполнить выгрузку в файл конфигурации .dt. Рассмотрим, зачем это нужно:

• Это окончательно подтверждает, что логическая структура 1С не повреждена.
• Это позволяет развернуть базу в файловом варианте, если сервер SQL пострадал слишком сильно.
• Это гарантирует отсутствие «вирусного хвоста» внутри таблиц базы данных (хотя SQL-таблицы редко заражаются самим кодом вируса).

Альтернативные методы защиты (Suspending)

Если у вас нет возможности немедленно выключить сервер, проанализируем метод «заморозки» процессов. Вместо того чтобы убивать процесс вируса (что может вызвать ответную реакцию системы), можно использовать утилиту Process Explorer.

1. Найдите процесс шифровальщика в списке.
2. Нажмите правую кнопку мыши и выберите пункт Suspend.
3. Процесс останется в памяти, но его выполнение будет приостановлено процессором. Это даст вам время на создание бэкапа штатными средствами SQL Server.

Профилактика и защита в будущем

Чтобы не допустить повторения ситуации, разберем ключевые настройки безопасности:

1. Закройте RDP: Большинство атак Ryuk происходит через проброшенный порт 3389. Используйте VPN для доступа к серверу.
2. Изолированные бэкапы: Храните резервные копии на устройствах, к которым у сервера нет прав на удаление (например, NAS с поддержкой WORM или облачные хранилища с версионностью).
3. Минимальные права: Служба sqlservr.exe должна запускаться от имени специально созданной учетной записи с минимальными правами в системе, а не от имени LocalSystem или администратора домена.
4. Двухфакторная аутентификация (2FA): Внедрение 2FA для административных учетных записей значительно снижает риск успеха брутфорс-атак.

Важное напоминание: В случае с 1С всегда старайтесь иметь актуальную копию в формате .dt на внешнем носителе. Как показала практика, именно связка MDF + Live CD + конвертация в DT спасла работу бухгалтерии и избавила от необходимости ручного ввода данных за целый год.