Анализ вредоносного трафика программы-вымогателя с помощью CapTipper



Дата публикации: 2020-05-07
Автор: Перевод: @sohimaster, ред. @N3M351D4
Теги: , ,

Источник: https://www.fuzzysecurity.com/tutorials/21.html

Введение

В данной статье будет проведено исследование вредоносного трафика, сгенерированного с помощью набора эксплойтов Magnitude. Для исследования будет использоваться утилита CapTipper. Это написанный на языке Python инструмент для анализа, изучения и восстановления вредоносного HTTP трафика.

CapTipper поднимает веб-сервер, который повторяет действия сервера записанные в файле с дампом трафика, и содержит внутренние инструменты с мощной интерактивной консолью для анализа и проверки найденных узлов, объектов и коммуникаций.

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

Что нам потребуется:

Первоначальный анализ

CapTipper является отличным инструментом для анализа HTTP трафика. Он может записывать запросы браузера, заголовки ответа сервера, тела ответа сервера, выполнять базовый анализ полезной нагрузки и извлекать файлы и HTTP объекты из потока трафика.

Итак, запустив CapTipper и передав ему в качестве аргумента путь к .pcap файлу мы получим список событий.Также список событий можно получить с помощью команды convs.

Получение списка событий

Список событий может дать нам представление о том, что происходило между атакующим хостом и сервером.

Следующий этап анализа вредоносного трафика ‒ группировка запросов по доменам и IP-адресам, с которыми происходил обмен данными. Сделать это можно с помощью команды hosts, после чего будет доступен следующий вывод:

Домены в запросах под индексом 0 и 1 выглядят подозрительно и, вероятно, являются вредоносными ресурсами. Каждое событие является отдельным запросом, доступным для анализа. Проведем первоначальный анализ с помощью команд info, head и req, указав в качестве аргумента индекс подозрительного запроса.

С помощью выполнения info 0 получим информацию об IP-адресе, URI, методе, статусе, типе полученного ответа и других метаданных запроса. Команда head выведет список заголовков ответа.

Сбор информации

Команда req выведет запрос, отправленный пользователем, в котором можно заметить большое количество объявленных MIME-типов, которые пользователь готов принять от сервера.

С помощью команды body выведем полученный ответ. По умолчанию вывод будет занимать 256 байт, поэтому для получения всего ответа нужно явно указать желаемый размер в байтах, либо строку all в качестве второго аргумента.

Для более удобного изучения можно воспользоваться онлайн инструментами форматирования HTML.

Исходя из полученных данных видно, что HTML страница загружает два отдельных ресурса. Объект shockwave указывает на одну из уязвимостей в Adobe Shockwave, которая позволит злоумышленнику скомпрометировать браузер пользователя и исполнить вредоносный код. Второй объект, вероятно, создается для сокрытия flash-объекта, поскольку они имеют одинаковую ширину и высоту.

Теперь мы знаем, что последующий пользовательский запрос был инициирован flash-объектом. Займемся сбором информации о нем.

Идентификация эксплуатируемой уязвимости

В заголовках запроса пользователя указана версия flash-плеера, информацию об уязвимостях которой можно найти на ресурсе cvedetails.com. Данная версия имеет большое количество уязвимостей, связанных с исполнением произвольного кода.

При получении тела запроса видим сигнатуру CWS, которая указывает на то, что это файл SWF. Сигнатуру (первые 3 байта в выводе ‒ 43 57 53 ‒ являются сигнатурой файла) можно получить с помощью команды hexdump.

Также можно посчитать найденные хеш-суммы файла для ручного поиска или анализа/отправки на Virus Total или Malwr.

Теперь мы можем сделать его дамп для последующего анализа.

Разархивируем файл и снова посчитаем его хэш-сумму.

После распаковки флэш-файл может быть декомпилирован с помощью нескольких декомпиляторов (таких как JPEXS или RABCDAsm). Для вашего удобства я приложил архив с распакованным SWF и папку с декомпилированными данными из JPEXS. Пароль для архива “infected”.

Пост-эксплуатация

В ходе анализа с помощью антивирусных решений была выявлена эксплуатируемая уязвимость, в названии некоторых сигнатур содержится ее идентификатор ‒ CVE-2015-0311.

        

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

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

Если мы посмотрим внимательнее, то увидим, что формат URL для первого запроса отличается от остальных семи последующих (он не начинается с «?»).

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

Ответ содержит в себе адреса следующих семи запросов и название файла urlmon.dll, который является легитимным Windows-dll, обеспечивающим абстракцию от вызовов API для загрузки файлов.

Шеллкод

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

В теле ответа на первый запрос содержится исполняемый файл. На остальные запросы сервер вернул только код 200. Данное поведение может быть объяснено тем, что в случае успешной загрузки исполняемого файла веб-сервер начинает игнорировать запросы на загрузку файла с IP-адреса жертвы, либо не имеет остальных исполняемых файлов.

Рассмотрим более подробно третий запрос:

Данные были переданы с ложным MIME-типом для предупреждения возможной блокировки запроса, а содержимое является исполняемым файлом.

При отправке хеша данного файла на анализ в VirusTotal было найдено 63 антивирусных вендора знающих о наличии вредоносного кода в файлах с такой хэш-суммой.

Анализ работы полезной нагрузки

Зачастую конечной целью злоумышленника является получение денег от жертвы, а для ее достижения могут быть использованы различные атаки от перехвата вызовов API для нажатия клавиш, подмены DNS для кражи паролей от банковских аккаунтов до применения различных программ-вымогателей и шифровальщиков, с которыми мы и имеем дело, о чем нам говорят названия некоторых сигнатур из отчета VirusTotal.

Вредоносный код начинает генерировать веб-трафик. Давайте подробнее рассмотрим запрос 9.

Данный запрос является обращением на домен ip-addr.es (188.165.164.184:80), который дублирует функционал ipaddr.es и предоставляет информацию о публичном IP-адресе для сбора дополнительной информации о скомпрометированном хосте.

При изучении двух последующих групп запросов мы увидим, что они были абсолютно идентичными, но все запросы на домен runlove.us вернулись с кодом 404.

Второй домен оказался более интересным ‒ ответы на 2 из 4 запросов содержат зашифрованные данные. Неизвестно, каким методом были зашифрованы эти данные (может быть AES), но расшифровать их не удалось. Скорее всего, при помощи данных запросов полезная нагрузка получает параметры конфигурации с сервера злоумышленника.

Эти данные нам не могут ничего сказать, однако это только 3 из 4 запросов. Один оставшийся запрос – 16-й, содержит изображение.

Сделаем его дамп для просмотра.

На картинке написано, что все файлы на компьютере жертвы были зашифрованы, а злоумышленник просит перейти на .onion ресурс для перевода средств.

Наконец, из записанного трафика мы можем увидеть, что жертва просматривает публичную конечную точку для домена TOR.

Давайте попробуем восстановить страницу, просмотренную жертвой. Данный запрос был сжат, на что указывает значение заголовка Content-Encoding, поэтому сначала его нужно разархивировать.

Так как CapTipper поднимает веб-сервер для эмуляции обмена данными, мы можем посмотреть, как выглядела просмотренная пользователем страница.

Для обнаружения и проверки подобного  вредоносного трафика можно также использовать набор правил Emerging Threats. Если настроить виртуальную машину и snorby в сочетании с правилами ET и запустить наш файл pcap в tcpreplay на интерфейсе, который отслеживает IDS, то, как показано на приведенном ниже снимке экрана, мы будем наблюдать предупреждения о злонамеренности трафика.

Заключение

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

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