Недавно был опубликован исходный код банковского трояна Pegasus. Несмотря на упоминание группы Carbanak в названии архива, исследователи из компании Minerva Labs опровергли причастность трояна к этой группе и доказали причастность к группе Buhtrap (Ratopak). Внутри архива находится краткое описание работы трояна, его исходные коды, описание системы банковских платежей и данные сотрудников многих российских банков.
Архитектура исходного кода этого вредоноса достаточно интересна. Функциональность поделена на модули, собираемые в единый “binpack” на этапе компиляции. Процесс компиляции также включает в себя подпись исполняемых файлов сертификатом из файла tric.pfx, который отсутствует в архиве.
Не менее любопытна и сетевая активность Pegasus, который, после заражения, пытается распространиться внутри домена и умеет проксировать данные между машинами, используя пайпы и транспорт Mailslot. Мы сфокусировались на изучении особенностей сетевой активности трояна и оперативно добавили детекты для Pegasus в продукт PT Network Attack Discovery. Это позволит всем его пользователям своевременно обнаруживать активность этого трояна и его модификаций в своей сети. В этой статье я дам подробное описание механизмов распространения по сети и взаимодействия между копиями Pegasus.
Попав на машину, главный модуль InstallerExe внедряет код в svchost.exe при помощи техники Process Hollowing и, после инициализации главных модулей, Pegasus запускает несколько параллельных процессов:
Одна из подсистем в Pegasus отвечает за горизонтальное распространение (Lateral Movement) в Windows сети. Распространение делится на два важных этапа:
Обнаружение соседних машин в домене осуществляется через два 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:
На Windows Server 2012:
Не обнаружив 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, а только потом при помощи Service Control Manager (SCM). Делается это по той причине, что SCM оставляет больше следов в журналах Windows. В планах создателей Pegasus были и другие методы распространения — Wsh Remote, Powershell remoting, Task Scheduler, а модуль для исполнения команд через RDP находился в стадии разработки.
Как было упомянуто выше, после успешного запуска дроппер проверяет и открывает пайп на прослушивание и передает управление на пришедшую полезную нагрузку.
Поскольку код Pegasus инжектируется методом Process Hollowing в процесс svchost.exe, на диске не должно остаться ни первоначального модуля InstallerExe в случае первичного заражения, ни дроппера RSE в случае распространения. Если дроппер всё ещё доступен по известному пути, Pegasus удаляет его собственным способом:
После успешного заражения процесс распространения Domain Replication начинается снова.
После того, как Pegasus получит доступ к данным учетных записей либо от другой копии Pegasus, либо от модуля mod_LogonPasswords, он начнет широковещательную рассылку данных УЗ по домену. Рассылка осуществляется при помощи основанного на SMB механизма Mailslot, который позволяет осуществить однонаправленную широковещательную рассылку небольшой порции данных по домену. Рассылка происходит по случайно сгенерированному имени слота и, чтобы все зараженные машины в домене могли отправлять и получать данные по единому имени, псевдослучайный генератор для имен инициализируется от переменной TARGET_BUILDCHAIN_HASH, задаваемой в конфиге при билде.
Поскольку механизм Mailslot накладывает ограничение на максимальный размер пакета, рассылается за раз только одна УЗ по принципу последнего времени рассылки: среди всех имеющихся УЗ по домену рассылается та, чья дата последней рассылки самая старая.
Данные в Mailslot-ах передаются не в открытом виде, а обернутые тремя слоями XOR-шифрования, причем ключи передаются вместе с данными. Первый слой данных это конверт NetMessageEnvelope с проверкой целостности данных алгоритмом SHA1, используемый для всех данных передаваемых по локальной сети. 4 байта данных в начале пакета являются ключом, который изменяется битовыми сдвигами на 5 бит вправо за цикл. Внутри конверта содержится XOR кодированная структура данных с непосредственно полями УЗ и датой их добавления. 8и байтовый ключ также находится в начале структуры, но применяется без сдвигов. После декодирования структуры УЗ останется лишь десериализовать отдельные поля из структурах ENC_BUFFER такие как имя компьютера, имя домена, пользователя и его пароль. Шифрование этих полей осуществляется 8и байтовым ключом со смещениями. Скрипт для расшифровки пакета Mailslot и пример такого пакета можно найти тут: скрипт, PCAP.
Период рассылки Mailslot сообщений в релизной версии колеблется от 20 секунд до 11 минут.
Кроме обмена учетными записями, механизм Mailslot используется для поиска зараженной машины с доступом в интернет и анонсирование доступа в интернет. Конверт NetMessageEnvelope хранит в себе тип рассылаемого сообщения. Сам обмен данными между машиной без доступа и машиной с доступом в интернет осуществляется через пайпы.
Для двусторонней связи или передачи больших объёмов данных копии Pegasus используют пайпы в качестве канала общения. Имя пайпа, хоть и тоже генерируется псевдослучайным генератором, но зависит от имени машины и билда и, тем самым, позволяет клиентской и серверной части использовать одно и то же имя.
При одностороннем общении, например, передаче binpack во время репликации на другую машину, данные не шифруются и передаются в открытом виде. Binpack начинается со структуры SHELLCODE_CONTEXT длинной 561 байт.
Во время двусторонней передачи, например, проксирования данных между копией Pegasus без доступа в интернет и CnC сервером, используется та же структура конверта NetMessageEnvelope с XOR шифрованием, как и в случае Mailslot, т.к. она позволяет различать разные типы сообщений в поле id.
Архитектурно проксирование данных выполняется через запрос на передачу порции данных (PMI_SEND_QUERY), получения id запроса в ответ и опроса состояния задачи по id (PMI_CHECK_STATUS_QUERY). Как правило, в качестве нагрузки передается другая Envelope структура, добавляющая различные функциональные возможности и ещё один слой шифрования.
Кроме того, работа с пайпами не заканчивается на взаимодействии между зараженными машинами. Модуль mod_KBRI_hd инжектит в процессы cmd.exe код, перехватывающий вызовы MoveFileExW и анализирующий все копируемые данные, поскольку это часть механизма проведения платежей. Если копируемый файл содержит интересные злоумышленникам данные — данные с платежами, нотификация об этом отправляется на CnC сервер. Общение между инжектируемым в cmd.exe модулем mod_KBRI и копией Pegasus осуществляется внутри зараженной машины через пайп, имя которого не генерируется, а жестко задано в исходном коде:
В функциональность модуля также входит подмена данных счетов на лету по шаблону. Пример паттернов для поиска на скриншоте.
За непосредственный обмен данных с CnC сервером отвечает отдельный поток, который раз в несколько минут проверяет очередь чанков данных от внутренних процессов или от других копий вредоноса и отправляет их на сервер.
Во время инициализации модуля mod_NetworkConnectivity он проводит многоступенчатую проверку работоспособности сетевого подключения:
1) Обнаружение настроек прокси сервера и попытка соединения с www.google.com:
2) Проверка соединения с серверами обновлений Microsoft и возвращаемых данных (authrootseq.txt, authrootstl.cab, rootsupd.exe)
3) Тестирование HTTPS соединений с одним из 6и адресов:
Только по прохождении всех проверок Pegasus считает, что имеет необходимый доступ во внешнюю сеть и может анонсировать это по домену Mailslot сообщением. Причем Pegasus может маскироваться и общаться с CnC сервером только в рабочие часы — с 9 до 19и часов по местному времени.
Чанки данных, обернутых в конверт с подсчетом хеш суммы, Pegasus посылает в зашифрованном виде с использованием DES шифрования в режиме CRYPT_MODE_CBC/PKCS5_PADDING. Ключ шифрования зависит только от переменной во время компиляции, и таким образом мы можем расшифровывать трафик между зловредом и сервером зная только его BUILDCHAIN_HASH. В исходных кодах внутри архива эта переменная имела значение 0x7393c9a643eb4a76. Скрипт для расшифровки отстука (Check-in) на сервер и пример такого пакета можно найти тут: скрипт, PCAP.
Такой контент (структура INNER_ENVELOPE) он передает на CnC сервер во время Check-in, либо вместе с какими-либо данными. Вначале находятся 28 байт конверта с полем длины и SHA1 суммой.
Те же самые данные передаются между машинами во время проксирования через пайпы, но завернутые внутрь известного нам конверта NetMessageEnvelope с хэш суммой и XOR шифрованием.
Оператор CnC может рассылать команды для исполнения на копии Pegasus и сообщения с командами или другими данными, например EID_CREDENTIALS_LIST могут содержать свои собственные слои шифрования полей, как мы уже видели на примере широковещательной рассылки учетных записей.
В первую очередь нас интересовало обнаружение активности Pegasus в сети и, после тщательного изучения исходных кодов и запуска в тестовом окружении, мы обнаружили те сетевые аномалии и артефакты, которые явно говорят о присутствии этого сложного вредоноса в сети. Pegasus действительно можно назвать разносторонним — он активно использует протокол SMB для рассылки сообщений и установления связи с другими копиями, распространяется на другие машины и коммуницирует с CnC сервером на свой особый лад. Устанавливая одноранговую сеть в домене, копии Pegasus прокладывают путь до внешней сети и общаются с CnC сервером проксируя трафик через друг друга. Использование сертификатов для подписи исполняемых файлов и обращение к ресурсам компании Microsoft и Mozilla во время проверки соединения затрудняет выявление его активности и обнаружение на хосте.
Проект исходного кода Pegasus достаточно хорошо структурирован и описан, поэтому в скором будущем можно ожидать заимствование частей его кода другими вредоносными программами и появления модификаций.
Многие из механизмов удаленного исполнения команд и поиска данных учетных записей остались нереализованными, разработчики также собирались добавить возможность изменения шеллкода во время внедрения в процесс на лету. И это не все их задумки.
Мы разработали несколько сигнатур для PT NAD и IDS Suricata, позволяющих выявить специфичную для Pegasus активность в сети на разных стадиях, начиная с самых первых секунд его активности. Найти открытые сигнатуры для Suricata IDS можно на нашем github и Twitter, они автоматически попадут к вашей Suricata, если вы используете механизм обновлений suricata-update.
То, как срабатывают сигнатуры на активность Pegasus можно посмотреть на скриншоте ниже. Это наш новый продукт PT Network Attack Discovery, выявляющий инциденты и помогающий в их расследовании:
Кроме того, для обнаружения можно использовать следующие индикаторы компрометации (IC):
Автор: Кирилл Шипулин из команды @attackdetection, Twitter | Telegram
Архитектура исходного кода этого вредоноса достаточно интересна. Функциональность поделена на модули, собираемые в единый “binpack” на этапе компиляции. Процесс компиляции также включает в себя подпись исполняемых файлов сертификатом из файла tric.pfx, который отсутствует в архиве.
Не менее любопытна и сетевая активность Pegasus, который, после заражения, пытается распространиться внутри домена и умеет проксировать данные между машинами, используя пайпы и транспорт Mailslot. Мы сфокусировались на изучении особенностей сетевой активности трояна и оперативно добавили детекты для Pegasus в продукт PT Network Attack Discovery. Это позволит всем его пользователям своевременно обнаруживать активность этого трояна и его модификаций в своей сети. В этой статье я дам подробное описание механизмов распространения по сети и взаимодействия между копиями Pegasus.
Intro
Попав на машину, главный модуль InstallerExe внедряет код в svchost.exe при помощи техники Process Hollowing и, после инициализации главных модулей, Pegasus запускает несколько параллельных процессов:
- Domain Replication — занимается разведкой внутри сети и попытками распространиться на другие Windows машины.
- Mailslot Listener слушает широковещательные mailslot сообщения, при помощи которых Pegasus рассылает добытые учетные записи. Имя слота генерируется во время компиляции.
- Pipe Server Listener слушает Windows Pipe с именем, генерируемым от имени машины. Эти пайпы используются в основном для обнаружения других копий Pegasus в сети и их взаимодействия
- Logon Passwords периодически раз в несколько минут пытается сдампить данные учетных записей модулем из Mimikatz.
- Network Connectivity отвечает за связь с CnC сервером и периодический обмен сообщениями.
// 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 сети. Распространение делится на два важных этапа:
- Обнаружение соседних машин.
- Попытка репликации на машину.
Обнаружение соседних машин в домене осуществляется через два 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, а только потом при помощи Service Control Manager (SCM). Делается это по той причине, что SCM оставляет больше следов в журналах Windows. В планах создателей Pegasus были и другие методы распространения — Wsh Remote, Powershell remoting, Task Scheduler, а модуль для исполнения команд через RDP находился в стадии разработки.
Как было упомянуто выше, после успешного запуска дроппер проверяет и открывает пайп на прослушивание и передает управление на пришедшую полезную нагрузку.
Поскольку код Pegasus инжектируется методом Process Hollowing в процесс svchost.exe, на диске не должно остаться ни первоначального модуля InstallerExe в случае первичного заражения, ни дроппера RSE в случае распространения. Если дроппер всё ещё доступен по известному пути, Pegasus удаляет его собственным способом:
- перезапись содержимого файла случайными данными;
- перезапись пустыми данными (нулями);
- переименование файла;
- удаление файла.
После успешного заражения процесс распространения Domain Replication начинается снова.
Mailslot works
После того, как Pegasus получит доступ к данным учетных записей либо от другой копии Pegasus, либо от модуля mod_LogonPasswords, он начнет широковещательную рассылку данных УЗ по домену. Рассылка осуществляется при помощи основанного на SMB механизма Mailslot, который позволяет осуществить однонаправленную широковещательную рассылку небольшой порции данных по домену. Рассылка происходит по случайно сгенерированному имени слота и, чтобы все зараженные машины в домене могли отправлять и получать данные по единому имени, псевдослучайный генератор для имен инициализируется от переменной TARGET_BUILDCHAIN_HASH, задаваемой в конфиге при билде. Поскольку механизм Mailslot накладывает ограничение на максимальный размер пакета, рассылается за раз только одна УЗ по принципу последнего времени рассылки: среди всех имеющихся УЗ по домену рассылается та, чья дата последней рассылки самая старая.
Данные в Mailslot-ах передаются не в открытом виде, а обернутые тремя слоями XOR-шифрования, причем ключи передаются вместе с данными. Первый слой данных это конверт NetMessageEnvelope с проверкой целостности данных алгоритмом SHA1, используемый для всех данных передаваемых по локальной сети. 4 байта данных в начале пакета являются ключом, который изменяется битовыми сдвигами на 5 бит вправо за цикл. Внутри конверта содержится XOR кодированная структура данных с непосредственно полями УЗ и датой их добавления. 8и байтовый ключ также находится в начале структуры, но применяется без сдвигов. После декодирования структуры УЗ останется лишь десериализовать отдельные поля из структурах ENC_BUFFER такие как имя компьютера, имя домена, пользователя и его пароль. Шифрование этих полей осуществляется 8и байтовым ключом со смещениями. Скрипт для расшифровки пакета Mailslot и пример такого пакета можно найти тут: скрипт, 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 без доступа в интернет и CnC сервером, используется та же структура конверта NetMessageEnvelope с XOR шифрованием, как и в случае Mailslot, т.к. она позволяет различать разные типы сообщений в поле id.
Архитектурно проксирование данных выполняется через запрос на передачу порции данных (PMI_SEND_QUERY), получения id запроса в ответ и опроса состояния задачи по id (PMI_CHECK_STATUS_QUERY). Как правило, в качестве нагрузки передается другая Envelope структура, добавляющая различные функциональные возможности и ещё один слой шифрования.
Кроме того, работа с пайпами не заканчивается на взаимодействии между зараженными машинами. Модуль mod_KBRI_hd инжектит в процессы cmd.exe код, перехватывающий вызовы MoveFileExW и анализирующий все копируемые данные, поскольку это часть механизма проведения платежей. Если копируемый файл содержит интересные злоумышленникам данные — данные с платежами, нотификация об этом отправляется на CnC сервер. Общение между инжектируемым в cmd.exe модулем mod_KBRI и копией Pegasus осуществляется внутри зараженной машины через пайп, имя которого не генерируется, а жестко задано в исходном коде:
\.\pipe\pg0F9EC0DB75F67E1DBEFB3AFA2
В функциональность модуля также входит подмена данных счетов на лету по шаблону. Пример паттернов для поиска на скриншоте. CnC traffic
За непосредственный обмен данных с CnC сервером отвечает отдельный поток, который раз в несколько минут проверяет очередь чанков данных от внутренних процессов или от других копий вредоноса и отправляет их на сервер.
Во время инициализации модуля 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 соединений с одним из 6и адресов:
- safebrowsing.google.com
- aus3.mozilla.org
- addons.mozilla.org
- fhr.data.mozilla.com
- versioncheck-bg.addons.mozilla.org
- services.addons.mozilla.org
Только по прохождении всех проверок Pegasus считает, что имеет необходимый доступ во внешнюю сеть и может анонсировать это по домену Mailslot сообщением. Причем Pegasus может маскироваться и общаться с CnC сервером только в рабочие часы — с 9 до 19и часов по местному времени.
Чанки данных, обернутых в конверт с подсчетом хеш суммы, Pegasus посылает в зашифрованном виде с использованием DES шифрования в режиме CRYPT_MODE_CBC/PKCS5_PADDING. Ключ шифрования зависит только от переменной во время компиляции, и таким образом мы можем расшифровывать трафик между зловредом и сервером зная только его BUILDCHAIN_HASH. В исходных кодах внутри архива эта переменная имела значение 0x7393c9a643eb4a76. Скрипт для расшифровки отстука (Check-in) на сервер и пример такого пакета можно найти тут: скрипт, PCAP.
Такой контент (структура INNER_ENVELOPE) он передает на CnC сервер во время Check-in, либо вместе с какими-либо данными. Вначале находятся 28 байт конверта с полем длины и SHA1 суммой.
Те же самые данные передаются между машинами во время проксирования через пайпы, но завернутые внутрь известного нам конверта NetMessageEnvelope с хэш суммой и XOR шифрованием.
Оператор CnC может рассылать команды для исполнения на копии Pegasus и сообщения с командами или другими данными, например EID_CREDENTIALS_LIST могут содержать свои собственные слои шифрования полей, как мы уже видели на примере широковещательной рассылки учетных записей.
Detection
В первую очередь нас интересовало обнаружение активности Pegasus в сети и, после тщательного изучения исходных кодов и запуска в тестовом окружении, мы обнаружили те сетевые аномалии и артефакты, которые явно говорят о присутствии этого сложного вредоноса в сети. Pegasus действительно можно назвать разносторонним — он активно использует протокол SMB для рассылки сообщений и установления связи с другими копиями, распространяется на другие машины и коммуницирует с CnC сервером на свой особый лад. Устанавливая одноранговую сеть в домене, копии Pegasus прокладывают путь до внешней сети и общаются с CnC сервером проксируя трафик через друг друга. Использование сертификатов для подписи исполняемых файлов и обращение к ресурсам компании Microsoft и Mozilla во время проверки соединения затрудняет выявление его активности и обнаружение на хосте.
Проект исходного кода Pegasus достаточно хорошо структурирован и описан, поэтому в скором будущем можно ожидать заимствование частей его кода другими вредоносными программами и появления модификаций.
Многие из механизмов удаленного исполнения команд и поиска данных учетных записей остались нереализованными, разработчики также собирались добавить возможность изменения шеллкода во время внедрения в процесс на лету. И это не все их задумки.
Мы разработали несколько сигнатур для PT NAD и IDS Suricata, позволяющих выявить специфичную для Pegasus активность в сети на разных стадиях, начиная с самых первых секунд его активности. Найти открытые сигнатуры для Suricata IDS можно на нашем 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
