Внезапная атака вируса-вымогателя — один из самых опасных сценариев для любой информационной системы. Особенно критично, когда под удар попадают базы данных 1С (файлы с расширением .1cd) и все доступные резервные копии. В этой статье мы подробно разберем, как устроен вирус-шифровальщик семейства Dharma (CrySis) с расширением .wiki, почему стандартные инструменты восстановления 1С оказываются бессильны, какие шаги необходимо предпринять немедленно для спасения данных и как настроить систему резервного копирования, защищенную от будущих атак.
При попытке запустить тестирование и исправление поврежденной базы данных с помощью стандартной утилиты chdbfl.exe или открыть файл через Tool_1CD, системные администраторы часто сталкиваются со следующими ошибками:
chdbfl.exe сообщает, что база данных повреждена, и мгновенно завершает работу без результатов.Tool_1CD выдает ошибку о том, что размер файла не кратен 4096 байтам или структура файла повреждена.Выясним причину такого поведения программ. База данных 1С формата .1cd состоит из структурированных блоков данных размером 4096 байт. В самом начале файла расположен заголовок базы, содержащий системные таблицы, описания схем, метаданные и указатели на физическое расположение таблиц документов и справочников.
Шифровальщики семейства Dharma работают по гибридному алгоритму. Чтобы зашифровать терабайты данных максимально быстро (пока администратор не заметил активность), зловред не шифрует весь файл целиком. Он перезаписывает стойким алгоритмом AES-256 только начальный блок файла (от нескольких килобайт до нескольких мегабайт) и дописывает в конец файла зашифрованный ключ сессии. В результате структура заголовка полностью разрушается. Утилиты chdbfl.exe и Tool_1CD считывают первые байты файла, не находят там валидной сигнатуры и структуры СУБД 1С, после чего аварийно завершают работу.
Если вы обнаружили, что файлы баз данных получили расширение вида .id-B081B0A2.[bitlocker@foxmail.com].wiki, действуйте по строгому алгоритму. Паника в первые минуты может привести к полной потере шансов на восстановление.
Шаг 1. Изоляция зараженного узла. Немедленно отключите сервер от локальной сети и интернета (выдерните сетевой кабель). Это остановит распространение вируса на соседние компьютеры и сетевые хранилища.
Шаг 2. Сохранение оперативной памяти (Дамп). Не перезагружайте компьютер! Вирусы-шифровальщики используют сессионные ключи, которые во время работы процесса шифрования находятся в оперативной памяти устройства. Проанализируем ситуацию: если процесс вируса еще активен или завершился недавно, ключ можно извлечь из дампа памяти. Используйте диспетчер задач или специализированные утилиты (например, Process Explorer) для создания дампа подозрительного процесса или всей оперативной памяти целиком.
Шаг 3. Анализ теневых копий. Вирус Dharma пытается выполнить команду удаления теневых копий:
vssadmin delete shadows /all /quiet
Однако в некоторых конфигурациях из-за нехватки прав или сбоя скрипта вируса эта команда выполняется некорректно. Запустите утилиту Shadow Explorer или воспользуйтесь штатными средствами Windows, чтобы проверить наличие точек восстановления, созданных до момента атаки. Если они уцелели, вы сможете извлечь чистую копию файла базы данных.
Шаг 4. Обращение к вирусным аналитикам. Сделайте резервную копию зашифрованного файла базы (даже в зашифрованном виде!). Обратитесь в сертифицированную лабораторию (например, Лабораторию Касперского или Dr.Web). Если у вас есть действующая лицензия на антивирусное ПО, аналитики бесплатно проверят ваши файлы на предмет возможности дешифровки. Иногда ключи шифрования попадают в открытый доступ в результате ликвидации серверов злоумышленников правоохранительными органами.
Поскольку вирус шифрует только заголовки файлов, само «тело» базы данных (таблицы с проводками, справочниками и документами) остается физически нетронутым в глубине файла .1cd.
Рассмотрим подробнее, как это можно использовать. Существуют узкоспециализированные сервисы и Hex-аналитики, которые выполняют низкоуровневое восстановление баз данных. С помощью Hex-редактора они анализируют структуру уцелевшей части файла, определяют смещения таблиц, воссоздают заголовок базы с нуля (используя структуру чистой аналогичной конфигурации) и монтируют данные в новую СУБД. Настоятельно не рекомендуется выполнять эти действия самостоятельно в Hex-редакторе без глубоких знаний структуры файлов 1С, так как это может окончательно уничтожить оставшиеся данные.
Главная ошибка, из-за которой пострадал автор темы на форуме — хранение резервных копий на том же сервере или в общей сетевой папке, куда у сервера был полный доступ на запись и удаление. Вирус, запущенный с правами администратора, шифрует абсолютно все доступные диски, включая сетевые шары.
Разберем две надежные схемы резервного копирования, которые гарантируют сохранность бэкапов даже при полном заражении рабочего сервера.
Смысл этого метода заключается в том, что рабочий сервер 1С может только отправлять новые файлы бэкапов на удаленный сервер, но не имеет прав на их изменение или удаление. Проанализируем этот процесс:
STOR / APPE). Права на удаление (DELE) и перезапись/модификацию для этой учетной записи полностью блокируются на уровне конфигурации FTP-сервера.Даже если злоумышленник получит полный контроль над сервером 1С и украдет учетные данные от FTP, запущенный им шифровальщик не сможет уничтожить или зашифровать ранее созданные архивы бэкапов на удаленном сервере.
Большинство администраторов используют Push-модель: рабочий сервер сам инициирует копирование и «толкает» файлы на бэкап-сервер. Это небезопасно. Намного надежнее использовать Pull-модель, при которой инициатором выступает изолированный сервер резервных копий.
Посмотрим на пример реализации такой схемы:
При такой схеме рабочий сервер 1С вообще не знает о существовании бэкап-сервера и не имеет к нему никаких сетевых доступов. В случае компрометации 1С-сервера злоумышленники физически не смогут дотянуться до бэкап-сервера.
Столкновение с вирусом-шифровальщиком — тяжелый урок для любого ИТ-специалиста. Помните, что безопасность данных держится на трех столпах: своевременное закрытие уязвимостей (никогда не оставляйте порт RDP 3389 открытым во внешний мир, используйте VPN), разграничение прав доступа и строгое соблюдение правила резервного копирования «3-2-1» (3 копии данных, на 2 разных носителях, 1 копия вне офиса/в облаке).