Мы, специалисты PT Expert Security Center, регулярно отслеживаем угрозы ИБ, в том числе как ранее известные, так и впервые обнаруженные вредоносные программы. Во время такого мониторинга в нашу песочницу PT Sandbox попал любопытный образец вредоносного ПО. Согласно первым результатам анализа трафика, он походил на RedLine — самый популярный инфостилер в киберпреступных каналах и чатах в Telegram за последние три года. Однако дальнейшее исследование показало, что пойманный вредонос — BlueFox. Это свежий инфостилер, который хоть и недавно появился в хакерской среде, но уже успел засветиться за рубежом.

Чем примечателен BlueFox, читайте в нашем разборе. Забегая вперед, отметим, что эта история ярко иллюстрирует преимущества совместной работы сетевых аналитиков и реверс-инженеров.

Как был обнаружен BlueFox

В ходе анализа поступающего сетевого трафика были обнаружены подключения к внешним серверам. Распределение пакетов (см. рис. 1) в соединениях существенно коррелировало с распределением пакетов известного ранее похитителя учетных данных RedLine. Энтропия в этих соединениях была значительно выше, чем у RedLine, который использует MC-NMF (.NET Message Framing Protocol). В результате было выдвинуто предположение: это новая версия RedLine, поддерживающая шифрование без обертки в протокол. Наши инструменты поиска похожего трафика среагировали на последовательность нескольких этапов обмена данными с сервером, типичных для RedLine, однако исследуемые передаваемые данные были зашифрованы.

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

Второй этап — отправка сервером клиенту задания на сбор данных. Оно содержит шаблоны имен файлов и пути расположения похищаемой информации.

Третий этап — непосредственно эксфильтрация клиентских данных в соответствии с заданием сервера.

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

Нам предстоял этап написания сетевых правил для поиска злоумышленников в высоконагруженных сетях наших клиентов. Прежде чем мы смогли обеспечить максимальную защиту от угрозы, был проведен реверс-инжиниринг нескольких образцов, попавших в PT Sandbox.

Извлечение образца для анализа

Образец представляет собой исполняемый файл большого размера — результат работы неизвестного упаковщика (см. рис. 2). Анализировать образец в таком виде бесполезно, поэтому его нужно распаковать.

Чтобы получить распакованный файл, мы запустили исходный образец на виртуальной машине и извлекли его из памяти при помощи программы pd64.exe (см. рис. 3).

В секции .data (см. рис. 4) распакованного образца стилера в открытом виде находился еще один исполняемый файл с символами MZ в первых двух байтах (см. рис. 5). Запустив его отдельно, мы выяснили, что именно этот исполняемый файл создает нужный нам трафик. Поэтому далее будем работать только с ним, к тому же в остальных файлах больше нет интересной для анализа информации.

Определение семейства вредоносной программы

Первым делом мы обратили внимание на файлы ресурсов образца, а именно на version.txt (см. рис. 6). Большая часть информации в нем не несет какого-либо смысла, но есть название программы BlueFox2.0.8.exe.

Поиск по названию привел к статье с похожими по структуре, размеру и поведению образцами (пример на сайте VirusTotal).

Описание BlueFox

Стилер BlueFox распространяется по схеме MaaS (malware as a service): автор программы продавал ее на форумах XSS, BHF и в даркнете.

Первая версия BlueFox появилась в декабре 2021 года и продавалась по цене 150 $ в месяц, но не снискала популярности. Скорее всего, помешала конкуренция: в то время был взлет популярности RedLine, который продавался по той же цене. Вторая версия появилась в сентябре 2022 года по цене 350 $. Она оказалась успешнее для злоумышленников: автор закрыл продажи, так как набрал достаточную клиентскую базу.

Описание стилера показано на рисунке 7. Автор подает ВПО как универсальное решение для получения и обработки большого количества информации с личным сервером и собственным протоколом связи.

Функциональные возможности программы не отличаются оригинальностью, другие стилеры (RedLine, Raccoon и т. п.) имеют похожие характеристики (см. рис. 8).

Однако доступная только из даркнета панель управления BlueFox вызывает интерес. Ее описание показано на рисунке 9.

Панель вредоноса имеет удобный информативный интерфейс со статистикой, поиском и большим количеством параметров (см. рисунки 10–13).

Автор стилера также показал пример собранной и обработанной информации, среди которой есть характеристики компьютера, страна, IP-адрес и расположение файлов с паролями (см. рисунок 14).

Анализ образца BlueFox

Анализируемый образец сильно обфусцирован, что затрудняло его исследование (см. рис. 15).

Для устранения обфускации использовалась программа NETReactorSlayer. Она помогла частично распутать код и облегчила нам дальнейший анализ (см. рис. 16).

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

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

Для наглядности на рисунке 19 показан типичный сетевой пакет. Красным выделена длина полезной нагрузки сообщения — в этом случае 0x30, а зеленым — флаг-индикатор. Все остальные байты — полезная нагрузка. Так как флаг равен 1, полезная нагрузка в сообщении зашифрована.

Рассмотрим также первый пакет клиента, так как он пригодится для обнаружения стилера. Вся полезная нагрузка – это число 0x19 (см. рис. 20).

Большой смысловой нагрузки этот пакет не несет, число 0x19 — простая константа для этой версии стилера (см. рис. 21–22). В предыдущих версиях она равна 0x18 (см. рис. 23).

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

В обоих случаях используется симметричный алгоритм блочного шифрования AES (Advanced Encryption Standard) в режиме ECB (electronic code book) с дополнением PKCS7.

Ключ для AES и его длина передаются в первом сообщении от сервера (см. рис. 26). Красным выделена длина ключа — 0x18 (192 бита), зеленым — сам ключ (081B5A91C24799F374F8F24D03BE7A964EEA4316F0B6AF25).

Зная алгоритм и ключ шифрования, можно расшифровать весь имеющийся трафик. Дешифруем полезную нагрузку из сообщения, показанного на рисунке 19 (см. рис. 27). Видно, что был передан UUID, который используется для идентификации компьютера жертвы на сервере.

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

Образец проходит по элементам списка из конфигурации, проверяет наличие файла в системе и, если он есть, читает и обрабатывает файл (см. рис. 29).

Попытка получить доступ к файлу из конфигурации в песочнице ANY.RUN показана на рисунке 30. В зависимости от потребностей владельца сервера эта конфигурация может изменяться как в большую, так и в меньшую сторону.

Образец открывает каждый существующий файл, полностью загружает его в память, считывает данные по определенным смещениям в файле (см. рис. 31–32) и передает обработанные данные следующей функции.

Стилер сохраняет полученные ранее данные в списке, шифрует его и отправляет на сервер (см. рис. 33).

Чтобы подтвердить результаты анализа, расшифруем сетевой пакет от устройства жертвы, который был отправлен после получения конфигурации. Сообщение содержит описанный выше UUID и эксфильтрованные данные в формате SQLite, о чем говорит строка SQLite format 3 (см. рис. 34).

Эксфильтрованные данные показаны в приложении для просмотра баз данных, чтобы можно было увидеть их структуру (см. рис. 35).

Самой интересной кажется таблица с учетными данными: в ней должно находиться большинство украденных сведений (см. рис. 36).

На рисунке 37 показаны учетные данные, которые смог украсть стилер.

Сервер обрабатывает эту базу данных и формирует журналы. Имея на руках украденные данные в удобном формате, злоумышленник, владелец сервера, мог с легкостью их использовать или перепродать третьим лицам.

После отправки данных программа удаляет себя с компьютера жертвы следующей командой:cmd.exe /C timeout 5 & del "$PATH

Выполняем сетевой детект

Информация в сетевом трафике расшифрована, теперь покажем значимые для детектирования пакеты. Их два: первый сетевой пакет и второй, сгенерированный клиентом. Детектирование будем выполнять только для клиентского потока данных двумя правилами, по одному на каждый клиентский пакет. Почему именно два правила? Дело в том, что контент в информационной части пакетов не подходит для одиночных правил, основанных на поиске зашифрованного контента, в связи с его изменчивостью. В этом случае необходимо использовать цепочку из двух связанных между собой правил, объединяющих обнаруживаемые пакеты, которые содержат небольшие фрагменты служебной части сообщений от стилера. 

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

Количество байтов во втором сетевом сообщении — 53: пять байтов служебной части и три блока AES по 16 байтов каждый. Но искать в сетевых потоках высоконагруженных систем анализа трафика все пакеты с длиной 53 байта и с небольшим количеством контента — не лучшая идея. Поэтому, учитывая первый пакет длиной 9 байтов, мы можем точно позиционировать второй пакет в клиентском потоке, объединить правила в цепочку и приправить небольшим количеством контента. Правило для детектирования второго клиентского пакета выглядит следующим образом:

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

Дополнительные функции вредоноса

В дополнение рассмотрим функциональные возможности образца, не продемонстрированные им при анализе в песочнице, но доступные владельцу сервера (см. рис. 39).

На рисунке 40 показан алгоритм создания снимка экрана, после чего снимок отправляется на сервер.

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

Мы обнаружили один примечательный случай, когда BlueFox скачивал артефакты, которые использовал другой стилер — Raccoon (индикаторы Raccoon, анализ BlueFox). Адреса, с которых стилер загружал артефакты, показаны на рисунке 42.

При тестировании Raccoon в песочнице ANY.RUN появились те же адреса (см. рис. 43).

Один из артефактов — стилер Vidar. Иными словами, стилеры BlueFox и Raccoon скачали и запустили другой стилер:

• cсылка на ANY.RUN,

• cсылка на VirusTotal,

• ссылка на Triage.

Вывод

На этом примере можно наглядно убедиться в преимуществе совместной работы сетевых аналитиков и реверс-инженеров. Аналитики выдвигают гипотезы, обнаруживают актуальные угрозы, а команда реверс-инженеров классифицирует их и собирает данные для точного детектирования в сети. В описанном случае мы провели анализ и подтвердили ранее принятую гипотезу о принадлежности исследуемых образцов классу похитителей учетных данных. Это позволило нам определить сетевые пакеты, необходимые для обнаружения стилера. Профит.

Авторы:

• Евгений Биричевский, младший специалист отдела обнаружения вредоносного ПО, экспертный центр безопасности Positive Technologies

• Евгения Устинова, ведущий специалист отдела обнаружения вредоносного ПО, экспертный центр безопасности Positive Technologies