Вирус-шифровальщик не всегда приговор. Одна история восстановления данных
Обращение жертвы очередного представителя ransomware (шифровальщик) в результате действий которого оказались зашифрованными пользовательские данные внутри виртуальных машин, также зашифрованы сами файлы виртуальных дисков. Вероятно атака проводилась уже после изучения сети, когда было исследовано злоумышленником как добраться до резервных копий, которые делались посредством Veeam Backup.
Владелец бизнеса попытался связаться с вымогателями, даже заплатил за декриптор заметную сумму, но на выходе получил дешифратор, который не расшифровал его данные и дальше пошла речь о новой оплате.
Анализ мелких данных показал, что они шифрованы целиком. С крупными файлами дело обстояло иначе. В крупных файлах оказались шифрованными участки с некоторым интервалом. Разумеется никакой прямой расшифровки без знания ключа провести невозможно, когда речь идёт о современных криптоалгоритмах. Прошли те времена, когда злоумышленники использовали xor операции. Хотя сегодня находится множество граждан утверждающих обратное и пользующихся тем, что пользователь обычно далек от понимания криптографии.
После комплекса анализов интерес к извлечению данных представляли частично испорченные ZIP архивы, так структура в них достаточно простая. В них достаточно проанализировать уцелевшие LFH записи и проверить данные следующие за ними. Фактически выполнить дефлейт для блока заданного размера и сравнить с CRC в LFH. Таки образом можно собрать уцелевшие объекты внутри ZIP файла. Далее либо выполнить экстракцию данных, либо скопировать в новый файл целые сегмента и составить Centar Dir для получения полноценного рабочего архива. Задача такой реконструкции достаточно хорошо известна и давно реализована в наших собственных инструментах.
Также основная надежда была на VBK файлы и VIB (инкременты), которые потенциально содержали все необходимые заказчику данные. Имена файлов были нещадно испорчены вредоносом. VMB файл, который мог кое-чего рассказать о цепочке инкрементов, увы, но уничтожен шифровальщиком.
Потому мне пришлось заняться реверс-инжинирингом самого формата хранения данных. Проведя цикл исследований удалось понять устройство начального header, подавляюще большинство параметров SnapShotSlot (0 и 1), а также уяснить формат таблицы метабанков и принцип расчета CRC, за счёт которой осуществляется контроль.
Первая часть задачи - это написание первичного сканера VBK файла в котором нет информации о положении метабанков. Для этого пришлось писать полный сканер, который ищет структуры похожие на метабанки и блоки данных. Проводит первичную валидацию структур. Анализирует все страницы метабанков и составляет перечень ключевых структур. Искать сжатые с помощью алгоритма LZ4 блоки данных так еще задачка, потому как без опоры на метаданные неизвестен размер сжатого и так просто в декомпрессор не подашь неопределенный объем данных. Благо эта подзадача имела решение еще со времен разработки инструмента глубокого анализа структур ZFS, позволяющего извлечь данные которые уже перестали быть доступны через MOS
Результат сканирования области данных и коррекция скорректированные Header, SnapshotSlot 0&1.
На основе этого можно сформировать SnapShotSlot 0 и 1 и прописать Header файла.
После реконструкции штатный распаковщик Veeam Backup Extract спотыкается на чтении одного из объектов в директории.
Сообщение об ошибке разбора директории из-за повреждения описателя объекта.
В такой ситуации приходится не останавливаться на достигнутом и переходить к полной разборе метаданных. Самый простой пусть - это использовать нижний уровень, то есть структуру, которая описывает все блоки в архиве. Она многостраничная, но с помощью ее можно выяснить какие блоки заняты, какого размера и какие участки свободны. Также сопоставить результаты построения карты всех блоков с картой фактически найденного в файле и выяснить масштаб потерь.
Построение карт блоков данных по структурам метаданных и поиск физически отсутствующих блоков.
Оценив объем потерь блоков из-за частичного шифрования файлов можно увидеть, что перспективы не самые плохие. Потерян не очень большой процент блоков. Дописав процедуру разбора деревьев, сверив правильность ассоциаций FIB через BlockID через нижний STG приступил к формированию карт объектов.
Проверив ключевые точки в создаваемой карте можно было убедиться что карта корректна и выполнить сбор.
Успешно собранная карта виртуального диска.
Сборка показала, что при таком частичном шифровании вредоносом извлеченные файлы виртуальных машин позволили получить очень высокий процент целостности небольших файлов, таких как документы, фото и т.п. Крупные файлы, такие как MS-SQL базы и их бэкапы, получились пострадавшими.
При наличии даже поврежденных резервных копий с близкой датой, шансы на восстановление самих баз данных весьма высоки.
Подведя мини итог можно сказать, не все шифровальщики одинаково страшны, пожелать всем не попадать в такие неприятные ситуации, почаще и побольше делать резервных копий и больше внимания информационной безопасности. Потому как не каждый случай восстановим и не всегда можно создать инструмент позволяющий минимизировать ущерб.
Если вдруг вы попали в такую ситуацию, то помните, что авторы-вредоносного ПО ничего вам не гарантируют, даже если показывают успешную распаковку мелких файлов. На вас они будут оказывать психологическое давление и торопить провести оплату в криптовалюте, но также не все будут спешить выполнить обещание расшифровать данные.