«Крякающий» шифровальщик

Тема в разделе "Борьба с типовыми зловредами", создана пользователем thyrex, 1 ноя 2014.

  1. thyrex
    Оффлайн

    thyrex Команда форума Супер-Модератор Ассоциация VN/VIP

    Сообщения:
    2.488
    Симпатии:
    3.101
    Наконец-то нашлось время проанализировать один из распространенных в настоящее время шифровальщиков Trojan-Ransom.Win32.Cryakl по классификации Лаборатории Касперского (Trojan.Encoder.567 по классификации DrWeb - обращаю внимание на изменение номера). За это время произошла эволюция в работе вируса. Автор наваял версию 4, которой было уделено внимание в статье https://securelist.ru/blog/issledovaniya/24070/shifrovalshhik-cryakl-ili-fantomas-razbushevalsya. Пока же аналитики вирлаба Лаборатории Касперского слегка поверхностно исследовали экземпляр этой версии, автор придумал версию 5, в которой алгоритм шифрования приобрел некие черты полиморфизма (используется 10 алгоритмов модификации содержимого файлов).

    Сразу хочу отметить, что автор самого вируса позиционирует себя только с тремя почтовыми адресами, на которые можно писать по поводу дешифратора:
    Все остальное - другие распространители, прикупившие себе исходник, и модифицировавшие (и то это слишком громко сказано) под себя, зачастую даже с нарушением функционала (например, ресурса с картинкой вымогателя нет, а процедура по ее излечению и установке на компьютер в качестве обоев осталась; в некоторых версиях и ответ от сервера не проверяется).
    Некоторые из покупателей специализируются на шифровании данных только на серверах, доступ к которым получен предварительно путем подбора паролей от RDP.
    Да и сам автор, модифицировав детище, не позаботился об усовершенствовании конструктора для его создания, о чем я упомяну в своем исследовании :)

    По мере эволюции автор отказался от использовании работы на основе службы (я ошибочно полагал, что она завязана на использовании svchost.exe, на самом деле файл используется для других целей - об этом ниже). Кроме того, если первые разновидности еще как-то можно было расшифровать утилитами от ведущих российских вирлабов, то на данный момент такой возможности нет, что говорит о проделанной автором работе над ошибками. Хотя какую-то работу в этом направлении вирлаб DrWeb все же ведет, но количество случаев успешной расшифровки незначительно (практически нулевое, я достоверно знаю лишь об одном случае успешного подбора пароля к версии 4).

    Основные особенности работы шифровальщика, не вдаваясь в подробности, описаны в упоминавшейся выше статье от Лаборатории Касперского. Хочу отметить, так же следующие особенности шифровальщика:
    - запускается без показа главной формы, но не скрывается в списке процессов;
    - проводит работу по определению разрядности системы, версии операционной системы и в результате работа осуществляется в соответствии с особенностями версий Windows (например, с соблюдением прав пользователей, старт копий от имени пользователей с правами администратора);
    - некоторые строковые величины (например, имена папок для записи копии, адреса серверов для передачи идентификатора зараженного пользователя и пароля) лежат в зашифрованном виде;
    - для усложнения исследования некоторые операции осуществляются замудреными способами;
    - работа с файлами осуществляется с помощью технологий прошлого века без использования Win API, что может привести к тому, что размер файла, превыщающего 4Гб, определяется неверно (актуально для файлов с образами дисков, а также, возможно, для баз 1С), вследствие чего запись информации для расшифровки будет осуществляться не в конец файла :);
    - автор не заботится о том, что код во многих случаях повторяется, т.е. ни о какой красоте программирования и минимализации использования памяти речи не идет (как в советском мультфильме, персонаж которого произносил "и так сойдёт" :)).

    А теперь переходим непосредственно к анализу. Т.к. первый запуск осуществляется из произвольного месторасположения, то вирус создает папку для своей копии на системном диске (определение буквы диска опять идет экзотическим способом) в папке Program Files (или Program Files (х86) - на х64-системах). Далее идет проверка наличия прав администратора. Как ни странно, принципиальной разницы в том, есть они или нет, я не заметил. Всё равно вызов процедуры шифрования есть в любом случае. В созданную папку побайтно (и снова прошлый век) копируется тело вируса, после чего запускается вторая копия из нового месторасположения, а первая завершает свою работу. Пока никакого шифрования (при работе первой копии) нет. Это выполняет уже следующая копия. Ах да, время создания файла вирус устанавливает таким же, как у системного svchost.exe (такая вот примитивная маскировка под легитимный файл). Кроме того, с целью маскировки имя файла вируса совпадает или с именем одной из системных программ (svchost.exe, explorer.exe), или с именем вполне легитимных сторонних программ (winrar.exe).

    Вторая копия (запущенная уже из правильного месторасположения) начинает с того, что проверяет, не запущена ли она с параметром /install (это или раритет из предыдущих модификаций, или лазейка для отмены запуска при ручном старте). Если это так, то она завершает работу, иначе создает запись реестра для автостарта вируса после каждой перезагрузки (причем никакой проверки на наличие записи в реестре снова нет - опять "и так сойдёт"). Управление передается процедуре, внутри которой будет вызов шифрования.

    Для начала происходит проверка наличия конфигурационного файла.
    - пока идет процесс шифрования (продолжается после рестарта системы), в нем хранится идентификатор зараженного компьютера и в кодированном виде 40-символьный случайный идентификатор. Исследователи из Лаборатории Касперского ошибочно посчитали, что это параметры шифрования для согласования работы после перезагрузки;
    - когда процесс завершен, там записано {CRYPTFULLEND} в кодированном виде

    Если файла нет:
    - генерируется уникальный идентификатор зараженной системы (состоит из 36 прописных латинских букв, текущих даты-времени и случайного числа от 0 до 999999).

    Если файл есть:
    - читаются оба идентификатора. Если второй из них в кодированном виде содержит {CRYPTFULLEND}, обои на Рабочем столе меняются на картинку с сообщением вымогателя.

    Далее:
    - генерируется 100 символьная строка из латинских цифр (мастер-ключ), вычисляется MD5-хэш 40 блоков по 5 символов, который вместе с идентификатором отправляется на сервера злоумышленника (проверка наличия интернета осуществляется обращением к трем серверам - ожидает ответ от сервера);

    - генерируется 40 символьная строка из латинских букв - случайный идентификатор;
    - оба идентификатора записываются в конфигурационный файл;
    - далее идет работа по созданию текстового сообщения вымогателя (раритет - остался от первых версий);
    - готовится список проверяемых типов файлов;
    - происходит поиск (настолько экзотический, что разбираться в нем не было желания) файлов, подлежащих шифрованию файлов.
    Хочу отметить, что:
    - шифрование подходящих типов файлов (уникальный для каждого файла ключ шифрования - MD5-хэш из строки, содержащей 40 символов случайной выборкой из мастер-ключа + случайная цифра от 0 до 9);
    В плюс автору здесь стоит отнести то, что после шифрования идет проверка сигнатуры {CRYPTANDBLACKDC} в конце файла. Только при ее наличии исходный файл удаляется.
    - в конфигурационный файл записывается {CRYPTFULLEND} в кодированном виде, что означает окончание шифрования. Теперь без обращения к злоумышленникам файлы не восстановить;
    - создается и запускается bat-файл, который должен был удалить шифровальщика и самого себя (не срабатывает :))

    О самом шифровании
    Как уже писали в статье от Лаборатории Касперского, первые версии шифровали всего лишь 29 байт в заголовке файла. И потому первые версии успешно расшифровывались декрипторами ЛК и DrWeb.
    Теперь же шифруются 3 блока (один в начале файла - максимальная длина 255 байт, два других в середине файла). Причем в версии 4.0, как минимум в дешифраторе, я видел проверку на невозможность хотя бы частичного пересечения шифруемых блоков. В шифровальщике версии 5.0 этого уже нет. Надеюсь автор учел это в своем дешифраторе :)
    При работе с размерами и смещением блоков автор для чего-то снова эмулирует стандартную для Delphi функцию IntToStr, причем ее вариант для чисел типа Int64. Нужды в этом нет (причина опять же кроется в прошлом веке при работе с файлами).
    Кроме того, в версии 5.0 автор добавил запись в файл блока мусорной информации максимальным размером в 4999 байт (записывается перед информацией, необходимой для расшифровки).

    На этом разрешите откланяться. Конструктивная критика приветствуется ;)

    P.S. Автор шифровальщика обязательно увидит статью.
     
    Последнее редактирование: 1 ноя 2014
    SNS-amigo, petr-ru, -SEM- и 7 другим нравится это.
  2. petr-ru
    Оффлайн

    petr-ru Пользователь

    Сообщения:
    62
    Симпатии:
    31
    Данный зловред ковырял совсем немного и в процессы "байт туда, байт сюда" не углублялся. Есть пара уточнений по ресерчу:

    У меня есть предположения, что имеется под этим (речь о встроенных делфийских функах), но все-таки прошу уточнить, а также подумать о более корректной формулировке, раскрывающей эту мысль.

    Лично я не шибко уверен из-за прошлого века это или сделано намеренно, ведь куда проще дернуть одну функу апи/языка для копирования, чем городить велосипед с побайтным копированием.


    Например? Может мудреность нескоторых действий заключается в криворукости авторов или в попытах обойти поведенческие детекты от ЛК?


    А есть предположение почему так назвали? (крякл). У меня есть предположение, но оно не толерантно
     
    Последнее редактирование: 5 ноя 2014
    Dragokas нравится это.
  3. thyrex
    Оффлайн

    thyrex Команда форума Супер-Модератор Ассоциация VN/VIP

    Сообщения:
    2.488
    Симпатии:
    3.101
    Даже функции Delphi для работы с файлами бывают разные. Здесь, действительно, старый век времен Паскаля

    Скорее всего для затруднения анализа при беглом осмотре тушканчика

    К примеру, поиск буквы системного диска после получения пути папки
    Windows. В новой версии автор исправил это дело (для данного примера)
     
    Dragokas нравится это.
  4. petr-ru
    Оффлайн

    petr-ru Пользователь

    Сообщения:
    62
    Симпатии:
    31
    Значит собирался зловред копипастом аля гугл "записать бинарный поток в файл делфи" :Acute:
     
  5. Heler
    Оффлайн

    Heler Активный пользователь

    Сообщения:
    27
    Симпатии:
    27
    C\C++ библиотека, Delphi, Pascal - это только "прослойки", которые в результате всё равно вызовут WinAPI функции.

    По той причине, что только ОС предоставляет возможность работы с файлами.

    Так о каких технологиях прошлого века без использования WinAPI идет речь?

    Или Вы просто имели в виду, что использовалась "прослойка", а не прямой вызов WinAPI функций в коде?
     
    Последнее редактирование: 5 ноя 2015

Поделиться этой страницей