Восстановление файлов после трояна-шифровальщика
рис. 1
Последующие попытки запуска рабочей среды 1С также не увенчались успехом. Бухгалтер связалась с компанией, обслуживающей вычислительную технику их организации, и запросила техническую поддержку. Специалистами обслуживающей организации выяснено, что проблемы куда более масштабные, так как кроме того что файлы базы 1С Бухгалтерии 7.7 были зашифрованы и имели расширение «BLOCKED», зашифрованными оказались и файлы с расширениями doc, docx, xls, xlsx, zip, rar, 1cd и другие. Также обнаруживался текстовый файл на рабочем столе пользователя, в котором сообщалось, что файлы зашифрованы с использованием алгоритма RSA 2048, и что для получения дешифратора необходимо оплатить услуги вымогателя. Резервное копировании 1С баз осуществлялось ежедневно на другой жесткий диск установленный в этом же ПК в виде создания zip архива с папкой 1С баз, и копия архива помещалась на сетевой диск (NAS). Так как ограничения доступа к резервным копиям не было, то вредоносное программное обеспечение имело доступ и к ним.
Оценив масштаб проблемы, специалисты обслуживающей организации выполнили копирование только шифрованных файлов на отдельный накопитель и произвели переустановку операционной системы. Также из почтового ящика бухгалтера были удалены письма, содержащие вредоносное ПО. Попытки расшифровки с использованием популярных дешифраторов антивирусных компаний на тот момент результата не дали. На этом обслуживающая организацию компания закончила свои работы.
Перспективы начать с ввода первичной документации в новую 1С базу, не сильно радовали бухгалтеров. Посему были рассмотрены дальнейшие возможности восстановления шифрованных файлов.
К сожалению, не были сохранены оригинальное тело вредоносного ПО и сообщение вымогателя, что не позволило дизассемблировать тело и установить алгоритм его работы посредством анализа в отладчике. Так же не было возможности проверить, встречался ли он различным антивирусным компаниям.
Поэтому сразу приступаем к анализу файлов, структуры которых хорошо известны. В данном случае удобно использовать для анализа DBF файлы из базы 1С, так как структура их весьма предсказуема. Возьмем файл 1SENTRY.DBF.BLOCKED (журнал бухгалтерских проводок), размер данного файла 53 044 658 байт
рис. 2
Рассматривая шифрованный DBF файл, обращаем внимание на то, что первые 0×35 байт не зашифрованы, так как присутствует заголовок, характерный для данного типа файлов, и наблюдаем часть описания первого поля записи. Произведем расчет размера файла. Для этого возьмем: WORD по смещению 0×08, содержимое которого равно 0×04C1 (в нем указан размер заголовка DBF файла), WORD по смещению 0×0A, содержимое которого равно 0×0130 (в нем указан размер одной записи в базе), DWORD по смещению 0×04, содержимое которого равно 0×0002A995 (количество записей), и 0×01 — размер конечного маркера. Решим пример: 0×0130*0×0002A995+0×04C1+1=0×0032965B2 (53 044 658) байт. Размер файла, согласно записи файловой системы, соответствует расчетному на основании информации в заголовке DBF файла. Выполним аналогичные проверки для нескольких DBF файлов и удостоверимся, что размер файла не был изменен вредоносным ПО.
Анализ содержимого DBF показывает, что небольшие файлы начиная со смещения 0×35 зашифрованы целиком, а крупные нет.
рис. 3
Номера счетов, даты и суммы изменены, чтобы не нарушать соглашения о конфиденциальности в том числе и в зашифрованном участке.
Начиная со смещения 0×00132CB5 обнаруживаем отсутствие признаков шифрования до конца файла, выполнив проверки в иных крупных файлах подтверждаем предположение, что целиком шифруются только файлы менее 0×00132CB5 (1 256 629) байт. Многие авторы вредоносного ПО выполняют частичное шифрование файлов с целью сокращения времени искажения пользовательских данных. Руководствуются вероятно тем, чтобы их вредоносный код за минимальное время нанес максимально возможный ущерб пользователю.
Приступим к анализу алгоритма шифрования
рис. 4
На рис. 4 на месте заголовков полей DBF файла присутствуют почти одинаковые последовательности из 16 байт (смещения 0×50, 0×70, 0×90), также видим частичное повторение последовательностей из 16 байт (смещения 0×40,0×60,0×80), в которых есть отличия только в байтах, где должно прописываться имя поля и тип поля.
На основании этого наблюдения, имея небольшое представление об алгоритмах работы криптографических алгоритмов вроде AES, RSA, можно сделать однозначный вывод, что данные не шифрованы с использованием этих алгоритмов. То есть, информация об алгоритме шифрования, поданная заказчиком, недостоверна. Недостоверной она может быть как из-за неких ошибочных выводов заказчика, так и являться следствием обмана автором вредоносной программы. Проверить это мы не можем, так как нам доступны только зашифрованные файлы.
Исходя из особенностей строения заголовков DBF файлов и изменений байт в последовательностях, можно сделать предположение, что шифрование выполнено посредством XOR операции над данными с неким паттерном. Также можно сделать предположение, исходя из длины повторяющихся последовательностей, что длина паттерна 16 байт (128 бит). Заголовок базы равен 0×04C1 байт, размер описания одного поля в заголовке 0×20 (32) байт. Из этого следует, что заголовок данного DBF файла содержит (0×4C1–0×21)/0×20=0×25 (37) описаний полей. На рис. 4 подчеркнуты красным фрагменты записей двух полей начиная со смещения 0×10, которые в случае 1С как правило имеют нулевые значения, кроме самого 0×10 (так как по этому смещению указывается размер поля), на основании этого можно полагать, что уже имеем 15 из 16 байт ключа шифрования 0×97 0×99 0xE6 0xBF 0×4B 0×6C 0×77 0×76 0×3A 0×80 0×0B 0xXX 0xAF 0×45 0×6A 0xB7.
Для нахождения последнего байта в ключе возьмем другой фрагмент этого же DBF файла.
рис. 5
На рисунке 5 обратим внимание на нулевой столбец, точнее на его нешифрованную часть, и видим, что там преобладает значение 0×20 (код пробела согласно ASCII таблицы). Соответственно, и в шифрованной части столбца будет преобладать некое одинаковое значение. Легко заметить, что это 0xFA. Для получения оригинального значения недостающего байта ключа необходимо выполнить 0xFA xor 0×20=0xDA.
Подставив полученное значение на недостающую позицию, получим полный ключ 0×97 0×99 0xE6 0xBF 0×4B 0×6C 0×77 0×76 0×3A 0×80 0×0B 0xDA 0xAF 0×45 0×6A 0xB7.
После выполнения процедуры xor операции с полученным ключом над шифрованными участками получили оригинальное содержимое файла
рис. 6
Для окончательного контроля проведем операцию расшифровки zip архива, затем распакуем архив. Если все файлы извлеклись и не возникало ошибки CRC для какого-либо файла, то можно окончательно подтвердить корректность ключа. И финальным этапом будет распаковка остальных файлов согласно технического задания.
Данный пример говорит о том, что вероятно не все высказывания авторов вредоносного программного обеспечения правдивы. И нередко можно решить задачу восстановления пользовательских данных посредством анализа измененных данных.
Наряду с подобными простыми случаями встречаются трояны-шифровальщики, которые действительно будут использовать современные криптографические алгоритмы и в случае их атаки подобное простое решение в принципе невозможно. Посему будьте предельно осторожны при открытии любых файлов, полученных по электронной почте даже от доверенных источников. Регулярно обновляйте антивирусное ПО и делайте резервное копирование таким образом, чтобы ваши данные во всех копиях не были доступны кому-либо единовременно.
Комментарии (2)
Harrix
29 апреля 2017 в 17:20
+1↑
↓
Надеюсь теперь задача резервного копирования решена немного по другому?
hddmasters
29 апреля 2017 в 17:29
0↑
↓
Клиенту были даны рекомендации, а прислушались к ними или нет не могу знать.
