Анализ CPL malware, часть 1
CPL malware представляет из себя особый вид вредоносного ПО, который распространяется в виде динамических DLL библиотек, выступающих в роли расширений элементов панели управления Windows (Windows Control Panel). Такой тип вредоносных программ особенно популярен у злоумышленников в Бразилии и используется для распространения даунлоадера Win32/TrojanDownloader.Banload и банкера Win32/Spy.Banker.T.
Каждый CPL-файл представляет из себя динамически подключаемую библиотеку. Сама DLL, по своей модели, хранит исполняемый код и данные, которые могут быть использованы другими исполняемыми PE-файлами через механизм экспортов DLL. Однако, исполнение библиотеки напрямую пользователем невозможно, поскольку она может быть использована только через исполняемый файл и созданный для него процесс.Динамические библиотеки CPL могут быть исполнены через вызов исполняемого файла control.exe, который и представляет из себя панель управления Windows. Для этого DLL должна удовлетворять специальным требованиям, одним из которых является наличие экспортной функции с именем CPlApplet. Ниже указан ее прототип на Delphi.
Рис. Прототип функции CPlApplet на Delphi.
Видно, что функция принимает на вход четыре аргумента: hwndCPl, который представляет из себя дескриптор главного окна приложения; uMsg представляет из себя идентификатор сообщения, которое отправляет DLL исполняемый файл панели управления; lParam1 и lParam2 представляют из себя аргументы, которые являются специфическими для конкретного сообщения. Отправляемые исполняемым файлом панели управления сообщения являются основным механизмом работы с CPL библиотекой.
Рис. Базовая структура функции CPlApplet.
Динамические библиотеки простых апплетов панели управления располагаются в директории %WINDIR%\System32. Злоумышленники используют иное расположение для хранения своих вредоносных CPL-файлов, которые также будут исполнены с использованием Windows Control Panel (control.exe). Обычно авторы размещают вредоносный код в той секции функции CPlApplet, которая отвечает за обработку сообщения CPL_DBLCLK.
Для распространения этого типа вредоносного ПО, злоумышленники используют фишинговые сообщения электронной почты. Пользователю может быть предложен для прочтения поддельный документ, открыв который он заражается вредоносной программой. Следующие темы электронных сообщений используются злоумышленниками для усыпления бдительности пользователей:
документ со счетом или квитанцией об оплате чего-либо; документ с информацией о состоянии банковского счета или другой банковской информацией; документ с информацией об электронных методах оплаты счетов, которые популярны в Бразилии; документ с различными изображениями и фотографиями, которые относятся к пользователю. Ниже на рисунке приведена типичная схема атаки на пользователей с использованием CPL malware в Бразилии. Цепочка компрометации пользователя начинается с распространения злоумышленниками файлов вредоносной программы через сообщения электронной почты. Такое сообщение может включать в себя вложение, либо содержать в тексте гиперссылку на файл, расположенный на удаленном сервере. Как правило, сама вредоносная DLL упакована в ZIP-архив (вложение сообщения электронной почты).
Рис. Жизненный цикл атаки с использованием CPL malware.
Выше мы упомянули типичную структуру основной функции CPlApplet, на скриншоте ниже представлена аналогичная функция вредоносной программы в дизассемблере. Важно упомянуть, что большинство проанализированных нами образцов такого вредоносного ПО написано на Delphi, исключение составляют лишь небольшое количество семплов с собственными упаковщиками, которые написаны на Microsoft Visual C.
Рис. Функция CPlApplet одного из семплов вредоносного ПО.
Эта функция имеет схожую структуру с той общей формой, которая была указана выше. Видно, что в ней присутствует большое количество условий, которые указывают на обработку различных типов сообщений. На скриншоте видны различные фрагменты кода, ответственные за обработку четырех сообщений.
Мы упоминали, что CPlApplet вызывается в различных ситуациях и является основной функцией, которая реализует логику работы CPL библиотеки в памяти. Схема исполнения этих функций и их связь с системными библиотеками Windows указана ниже на рисунке.
Рис. Поток вызовов функций CPlApplet.
На рисунке видно, что первой функцией CPL библиотеки, которая будет вызвана, является DllMain. Это точка входа в библиотеку, которая выполняет первичную инициализацию своих данных и структур. Функция DllMain вызывается API LoadLibrary в библиотеке shell32.dll, после того как библиотека загружена в память. Логично было бы предположить, что вся логика работы вредоносной программы может быть сразу размещена в этой функции, поскольку она выполняется еще до вызова CPlApplet. Этот вопрос мы рассмотрим ниже.
После инициализации DLL, т. е. исполнения ее функции DllMain, осуществляется последовательный вызов функции CPlApplet с различными сообщениями. Порядок вызова функции с соответствующими сообщениями указан цифрами от 1 до 7. Сообщение CPL_DBLCLK является основным, поскольку там располагается основной код вредоносной программы. В случае этого семпла, там располагается полезная нагрузка (payload), на которую передается управление при обработке этого типа сообщения.
Код полезной нагрузки, наблюдавшихся нами образцов CPL malware, имеет определенную структуру и его можно разбить на следующие части:
инициализация;
построение URL-адресов для загрузки вредоносного содержимого;
исполнение загруженных файлов.
Рис. Фрагмент вредоносного кода полезной нагрузки.
Как видно на графе вызовов функций полезной нагрузки, ее исполнение довольно линейно, на рисунке указан фрагмент функции инициализации. В самом начале этой функции происходит инициализация стека нулевыми значениями в цикле, далее поток исполнения функции засыпает на 30 сек., после чего он сохраняет путь к директории %APPDATA% в буфере памяти. Отметим, что наблюдавшиеся нами образцы в функции инициализации выполняли и иные действия, например, не вызывали функцию Sleep, получали путь к другим системным директориям. Тем не менее, вышеприведенная схема является довольно общей для многих образцов. Ниже показан фрагмент кода, в котором происходит конструирование URL-адресов и загрузка файлов.
Рис. Фрагмент кода вредоносной программы, который отвечает за загрузку файлов с удаленного C&C-сервера.
На скриншоте выше видно, что для каждой зашифрованной строки вызывается функция расшифровки decipher_str. Затем на основе этих строк формируется конечный URL-адрес, с которого будет осуществлена загрузка исполняемого файла. Видно, что загружаемый файл замаскирован под файл изображения с расширением .png. Он будет сохранен в расположение %APPDATA%\Desk.exe. Функция download_URL осуществляет непосредственную загрузку файла с использованием обычных API вызовов Windows.
Отметим, что не все обнаруженные нами образцы CPL malware используют зашифрованные строки. Нам часто попадались образцы, в которых строки представлены открытым текстом. В таких образцах отсутствует функция расшифровки decipher_str, которую мы упоминали выше.
Рис. Пример вредоносного файла CPL malware со строками в форме открытого текста.
Последний фрагмент кода полезной нагрузки отвечает за исполнение загруженных с удаленного сервера файлов с использованием стандартной API-функции ShellExecute. Наш анализ показал, что действия, выполняемые CPL malware, являются простыми и достаточно эффективными для компрометации системы пользователя. Вредоносная программа не устанавливается в систему, а лишь специализируется на загрузке и установке в систему других вредоносных программ, т. е. выступает как загрузчик или даунлоадер (downloader). Таким образом, сам загрузчик в системе обнаружить сложно, поскольку он не оставляет там следов, например, разделов реестра или других индикаторов.
Рис. Фрагмент кода, который отвечает за исполнение загруженного файла.
Многие из файлов такого вредоносного ПО, которые мы анализировали, являются вариантами семейства вредоносного ПО Win32/TrojanDownloader.Banload и специализируются на установке банковских троянов в систему.
Большинство образцов CPL malware используют механизмы расшифровки строк на основе операций SUB и XOR. Ключ расшифровки жестко зашит в коде самой функции, которая занимается расшифровкой. Вредоносная программа использует т. н. «расширенную форму Бэкуса-Наура» (Extended Backus–Naur Form, EBNF) для хранения зашифрованных строк и ключа.
В форме регулярного выражения это выглядит так:
Видно, что зашифрованные строки (cipher_string) состоят как минимум из двух пар шестнадцатеричных символов (в верхнем регистре), причем количество символов всегда будет четно. Ключ состоит из, по меньшей мере, одного буквенно-цифрового символа также в верхнем регистре. Мы также наблюдали в составе ключей такие символы как »@» и »!», которые мы не включили в регулярное выражение выше для простоты.
На следующем рисунке показан пример алгоритма дешифрования. На первом этапе символы зашифрованной строки будут подвергнуты шифрованию дважды, поскольку каждая пара рассматривается как шестнадцатеричное, байтовое значение. То же самое можно сказать о ключе, последовательность ASCII-символов рассматривается как шестнадцатеричный байтовый поток.
Рис. Первый этап алгоритма расшифровки.
Рис. Второй этап алгоритма расшифровки.
На первом этапе алгоритма видно, что в операции расшифровки пропускается первая пара символов зашифрованной строки, она будет использоваться на втором этапе в качестве вычитаемого значения от результата, полученного на первом этапе работы алгоритма. Уже на этом этапе, результат вычитания рассматривается в качестве ASCII-символа. В нашем примере ASCII код представляет букву «h». Отметим, что в том случае, когда результат операции вычитания дает отрицательное число, значение 0xFF прибавляется к самому вычитаемому перед тем, как происходит операция вычитания. На рисунке ниже указано каким образом происходит операция расшифровки для семи первых символов зашифрованной строки.
Рис. Расшифровка первых семи символов зашифрованной строки CPL malware.
На скриншоте ниже показана основная часть функции расшифровки в IDA Pro. Функция считывает из памяти два первых символа зашифрованной строки, сохраняет их и начинает процесс расшифровки. В цикле функция берет очередные два символа строки и пару символов ключа, выполняя операцию XOR. Далее над полученным значением (первый этап) выполняется операция вычитания (SUB), при этом из него вычитается значение первой пары символов, которые были сохранены в памяти в самом начале функции. Полученное значение копируется в буфер памяти, хранящий расшифрованный текст. На последнем шаге происходит копирование пары символов, которые использовались в операции XOR, т. е. они становятся вычитаемым значением для операции SUB на следующей итерации. В случае, когда символы для расшифровки еще остались, а все символы ключа уже были израсходованы, символы ключа берутся с самого его начала.
Рис. Функция расшифровки строк.
