Страницы

понедельник, 30 июля 2018 г.

Анализ поведения трояна Pegasus в сети

Недавно был опубликован исходный код банковского трояна Pegasus. Несмотря на упоминание группы Carbanak в названии архива, исследователи из компании Minerva Labs опровергли причастность этой группы к трояну и доказали его связь с группой Buhtrap (Ratopak). Внутри архива находится краткое описание работы трояна, его исходный код, информация о системе банковских платежей и данные сотрудников многих российских банков.

Архитектура исходного кода Pegasus довольно интересна. Функциональность поделена на модули, собираемые в единый binpack на этапе компиляции. Процесс компиляции также включает в себя подпись исполняемых файлов сертификатом из файла tric.pfx, который отсутствует в архиве.

Не менее любопытна и сетевая активность трояна: после заражения он пытается распространиться внутри домена, умеет проксировать данные между машинами, используя пайпы и транспорт Mailslot. Мы сфокусировались на изучении особенностей сетевой активности трояна и оперативно добавили детекты для Pegasus в продукт PT Network Attack Discovery. Это позволит всем пользователям PT NAD своевременно обнаружить активность этого трояна и его модификаций в своей сети. В статье я дам подробное описание механизмов распространения по сети и взаимодействия между копиями Pegasus.

Попав на машину, главный модуль InstallerExe внедряет код в svchost.exe при помощи техники process hollowing, и после инициализации главных модулей Pegasus запускает несколько параллельных процессов:
  1. Domain replication занимается разведкой внутри сети и пытается распространиться на другие Windows-машины.
  2. Mailslot Listener слушает широковещательные mailslot-сообщения, при помощи которых Pegasus рассылает добытые учетные записи. Имя слота генерируется во время компиляции.
  3. Pipe Server Listener слушает Windows Pipe с именем, генерируемым от имени машины. Эти пайпы используются в основном для обнаружения других копий Pegasus в сети и их взаимодействия.
  4. Logon passwords раз в несколько минут пытается сдампить данные учетных записей модулем из Mimikatz.
  5. Network connectivity отвечает за связь с C&C-сервером и периодический обмен сообщениями.
// start transports which links data with our CB-manager
pwInitPipeServerAsync(dcmGetServerCallback());
mwInitMailslotServer(dcmGetServerCallback());
...
// start broadcasting creds to other machines
cmStartupNetworkBroadcaster();

Domain replication

Одна из подсистем в Pegasus отвечает за горизонтальное распространение (lateral movement) в Windows-сети. Распространение делится на два важных этапа:
  1. обнаружение соседних машин,
  2. попытка репликации на машину.
Обнаружение соседних машин в домене осуществляется через два API-вызова — NetServerEnum, требующий для работы сервис Browser и вызовы WNetOpenEnum/WNetEnumResource.

Все обнаруженные в домене машины подлежат проверке, если они уже заражены. Pegasus опрашивает сгенерированное имя пайпа раз в 200 миллисекунд более чем 20 раз подряд. Такое аномальное поведение было использовано нами в качестве одного из индикаторов активности Pegasus в домене. Не обнаружив признаков заражения, зловред переходит к следующему шагу — попытке репликации.

Репликация происходит следующим образом. При помощи найденных учетных записей (УЗ) на хосте Pegasus предпринимает попытку авторизоваться на машине по протоколу SMB к шарам IPC$ и ADMIN$. Если доступ к IPC$ есть, а к ADMIN$ нет, то Pegasus делает вывод о том, что прав учетной записи недостаточно и их необходимо пометить как невалидные. Получив доступ к шаре ADMIN$, что является алиасом для папки %windir%, вредонос пытается определить архитектуру машины, чтобы в дальнейшем использовать подходящий модуль.

Алгоритм определения архитектуры основывается на заголовках PE-файлов на удаленной машине. В качестве такого файла Pegasus пытается прочитать первые 4 килобайта notepad.exe из папки %windir%. Неочевидный недостаток такого метода заключается в том, что на Windows Server 2012 блокнот находится по пути %windir%\System32.

Местоположение notepad.exe на Windows 7:

C:\Users\Administrator>where notepad.exe
C:\Windows\System32\notepad.exe
C:\Windows\notepad.exe

На Windows Server 2012:

C:\Users\Administrator>where notepad.exe
C:\Windows\System32\notepad.exe

Не обнаружив notepad.exe, Pegasus не может заразить сервер, даже имея данные учетной записи с необходимыми правами. Простое отсутствие блокнота в %windir% может остановить распространение Pegasus на Windows Server 2012. Использование regedit.exe в этом плане более надежно.

После успешного определения архитектуры целевого сервера Pegasus загружает небольшой дроппер RSE (Remote Service Exe) размером около 10 килобайт, задача которого загрузить binpack из модулей от Pegasus через пайп в открытом виде и передать управление на модуль shellcode. Имя дроппера составляется псевдослучайным образом и состоит из строки шестнадцатеричных символов длинной от 8 до 15 символов. Псевдослучайный генератор инициализируется в зависимости от имени целевой машины и будет одинаковым между запусками, чтобы избежать возможное засорение %windir% прошлыми копиями дроппера.


Дроппер проверяется на целостность и возможное удаление антивирусом, после чего запускается одним из двух реализованных механизмов — SCM или WMI. Причем в первую очередь Pegasus предпринимает попытку запуска RSE через механизм WMI, а только потом при помощи SCM (Service Control Manager). Делается это по той причине, что SCM оставляет больше следов в журналах Windows. В планах создателей Pegasus были и другие методы распространения (WSH Remote, PowerShell Remoting, Task Scheduler), и модуль для исполнения команд через RDP находился в разработке.

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


Поскольку код Pegasus инджектируется методом process hollowing в процесс svchost.exe, на диске не должно остаться ни первоначального модуля InstallerExe в случае первичного заражения, ни дроппера RSE в случае распространения. Если дроппер все еще доступен по известному пути, Pegasus удаляет его собственным способом:


  1. перезапись содержимого файла случайными данными,
  2. перезапись пустыми данными (нулями),
  3. переименование файла,
  4. удаление файла.


После успешного заражения процесс распространения Domain replication начинается снова.

Mailslot works

После того как Pegasus получит доступ к данным учетных записей либо от другой копии Pegasus, либо от модуля mod_LogonPasswords, он начнет широковещательную рассылку данных УЗ по домену. Рассылка осуществляется при помощи основанного на SMB механизма Mailslot, который позволяет осуществить однонаправленную широковещательную рассылку небольшой порции данных по домену. Рассылка происходит по случайно сгенерированному имени слота, и, чтобы все зараженные машины в домене могли отправлять и получать данные по единому имени, псевдослучайный генератор для имен инициализируется от переменной TARGET_BUILDCHAIN_HASH, задаваемой в конфиге при билде.

Поскольку механизм Mailslot накладывает ограничение на максимальный размер пакета, рассылается за раз только одна УЗ по принципу последнего времени рассылки: среди всех имеющихся УЗ по домену рассылается та, чья дата последней рассылки самая ранняя.

Данные в мейлслотах передаются не в открытом виде, а обернутые тремя слоями XOR-шифрования, причем ключи передаются вместе с данными. Первый слой данных — это конверт NetMessageEnvelope с проверкой целостности данных алгоритмом SHA1, используемый для всех данных, передаваемых по локальной сети. Четыре байта данных в начале пакета являются ключом, который изменяется битовыми сдвигами на пять бит вправо за цикл. Внутри конверта содержится кодированная посредством XOR структура данных с полями УЗ и датой их добавления. Восьмибайтовый ключ также находится в начале структуры, но применяется без сдвигов. После декодирования структуры УЗ останется лишь десериализовать отдельные поля из структур ENC_BUFFER, такие как имя компьютера, имя домена, имя пользователя и его пароль. Шифрование этих полей осуществляется 8-байтовым ключом со смещениями. Скрипт для расшифровки пакета Mailslot и пример такого пакета можно найти на GitHub и PCAP.

Период рассылки Mailslot-сообщений в релизной версии колеблется от 20 секунд до 11 минут.

// some random wait before making next step
DbgPrint("going to sleep");
#ifdef _DEBUG
// debug - 2-5 s
Sleep(rg.rgGetRnd(&rg, 2000, 5000));
#else
// release - 20 - 650 s
//Sleep(rg.rgGetRnd(&rg, 2000, 65000) * 10);
Sleep(rg.rgGetRnd(&rg, 2000, 15000));
#endif

Кроме обмена учетными записями, механизм Mailslot используется для поиска зараженной машины с доступом в интернет и анонсирование доступа в интернет. Конверт NetMessageEnvelope хранит в себе тип рассылаемого сообщения. Сам обмен данными между машиной без доступа и машиной с доступом в интернет осуществляется через пайпы.

Pipe works

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

При одностороннем общении (например, передаче binpack во время репликации на другую машину) данные не шифруются и передаются в открытом виде. Binpack начинается со структуры SHELLCODE_CONTEXT длинной 561 байт.


Во время двусторонней передачи (например, проксирования данных между копией Pegasus без доступа в интернет и C&C-сервером) используется та же структура конверта NetMessageEnvelope с XOR-шифрованием, как и в случае Mailslot, так как она позволяет различать разные типы сообщений в поле id.

Архитектурноe проксирование данных выполняется через запрос на передачу порции данных (PMI_SEND_QUERY), получения id-запроса в ответ и опроса состояния задачи по id (PMI_CHECK_STATUS_QUERY). Как правило, в качестве нагрузки передается другая Envelope-структура, добавляющая различные функциональные возможности и еще один слой шифрования.

Кроме того, работа с пайпами не заканчивается на взаимодействии между зараженными машинами. Модуль mod_KBRI_hd инджектит в процессы cmd.exe код, перехватывающий вызовы MoveFileExW и анализирующий все копируемые данные, поскольку это часть механизма проведения платежей. Если копируемый файл содержит интересные злоумышленникам данные — данные с платежами, — нотификация об этом отправляется на C&C-сервер. Общение между инджектируемым в cmd.exe модулем mod_KBRI и копией Pegasus осуществляется внутри зараженной машины через пайп, имя которого не генерируется, а жестко задано в исходном коде:

\.\pipe\pg0F9EC0DB75F67E1DBEFB3AFA2

В функциональность модуля также входит подмена данных счетов на лету по шаблону. Пример паттернов для поиска на скриншоте.


C&C-трафик

За непосредственный обмен данными с C&C-сервером отвечает отдельный поток, который раз в несколько минут проверяет очередь чанков данных от внутренних процессов или от других копий вредоноса и отправляет их на сервер.
Во время инициализации модуля mod_NetworkConnectivity он проводит многоступенчатую проверку работоспособности сетевого подключения:

1) Обнаружение настроек прокси-сервера и попытка соединения с www.google.com:

  • в ветке реестра \\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings;
  • через WPAD (вызов WinHttpGetProxyForUrl);
  • через конфигурацию прокси-сервера для текущего пользователя (вызов WinHttpGetIEProxyConfigForCurrentUser).

2) Проверка соединения с серверами обновлений Microsoft и возвращаемых данных (authrootseq.txt, authrootstl.cab, rootsupd.exe).

3) Тестирование HTTPS-соединений с одним из шести адресов:

  • https://safebrowsing.google.com
  • https://aus3.mozilla.org
  • https://addons.mozilla.org
  • https://fhr.data.mozilla.com
  • https://versioncheck-bg.addons.mozilla.org
  • https://services.addons.mozilla.org

Только по прохождении всех проверок Pegasus считает, что имеет необходимый доступ во внешнюю сеть и может анонсировать это по домену Mailslot-сообщением. Причем Pegasus может маскироваться и общаться с C&C-сервером только в рабочие часы — с 9:00 до 19:00 по местному времени.

Чанки данных, обернутых в конверт с подсчетом хеш-суммы, Pegasus посылает в зашифрованном виде с использованием DES в режиме CRYPT_MODE_CBC/PKCS5_PADDING. Ключ шифрования зависит только от переменной во время компиляции, и таким образом мы можем расшифровывать трафик между зловредом и сервером, зная только его BUILDCHAIN_HASH. В исходных кодах внутри архива эта переменная имела значение 0x7393c9a643eb4a76. Скрипт для расшифровки «отстука» (check-in) на сервер и пример такого пакета можно найти на GitHub и PCAP.

Такой контент (структура INNER_ENVELOPE) он передает на C&C-сервер во время check-in, либо вместе с какими-либо данными. В начале находятся 28 байт конверта с полем длины и SHA1-суммой.


Те же самые данные передаются между машинами во время проксирования через пайпы, но завернутые внутрь известного нам конверта NetMessageEnvelope с хеш-суммой и XOR-шифрованием.

Оператор C&C может рассылать команды для исполнения на копии Pegasus и сообщения с командами или другими данными (например, EID_CREDENTIALS_LIST) могут содержать свои собственные слои шифрования полей, как мы уже видели на примере широковещательной рассылки учетных записей.

Detection

В первую очередь нас интересовало обнаружение активности Pegasus в сети. После тщательного изучения исходных кодов и запуска в тестовом окружении мы обнаружили те сетевые аномалии и артефакты, которые явно говорят о присутствии этого сложного вредоноса в сети. Pegasus действительно можно назвать разносторонним: он активно использует протокол SMB для рассылки сообщений и установления связи с другими копиями, распространяется на другие машины и взаимодействует с C&C-сервером на свой особый лад. Устанавливая одноранговую сеть в домене, копии Pegasus прокладывают путь до внешней сети и общаются с C&C-сервером, проксируя трафик друг через друга. Использование сертификатов для подписи исполняемых файлов и обращение к ресурсам компаний Microsoft и Mozilla во время проверки соединения затрудняет выявление его активности и обнаружение на хосте.

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

Многие из механизмов удаленного исполнения команд и поиска данных УЗ остались нереализованными. Разработчики в том числе собирались добавить возможность изменения шелл-кода на лету, во время внедрения в процесс.

Мы разработали несколько сигнатур для PT NAD и IDS Suricata, позволяющих выявить специфичную для Pegasus активность в сети на разных стадиях, начиная с самых первых секунд его активности. Найти открытые сигнатуры для IDS Suricata можно на нашем GitHub и Twitter — они автоматически попадут к вашей Suricata, если вы используете механизм обновлений suricata-update.

То, как срабатывают сигнатуры на активность Pegasus, можно посмотреть на скриншоте ниже. Это наш новый продукт PT Network Attack Discovery, выявляющий инциденты и помогающий в их расследовании.



Кроме того, для обнаружения можно использовать следующие индикаторы компрометации (IC):

MAILSLOT\46CA075C165CBB2786 
pipe\pg0F9EC0DB75F67E1DBEFB3AFA2

hxxp://denwer/pegasus/index.php
hxxp://mp3.ucrazy.org/music/index.php
hxxp://support.zakon-auto.net/tuning/index.asp
hxxp://video.tnt-online.info/tnt-comedy-tv/stream.php

Автор: Кирилл Шипулин из команды @attackdetection, Twitter | Telegram

Комментариев нет:

Отправить комментарий