Вредоносы

С ноября 2020 года участились случаи похищения аккаунтов у популярных Telegram-каналов. Недавно эксперты CERT-GIB установили тип вредоносной программы, с помощью которой хакеры пытались угнать учетку у Никиты Могутина, сооснователяпопулярного Telegram-канала База (320 тысяч подписчиков). В той атаке использовался стилер Hunter, который Могутину прислали под видом рекламы образовательной платформы. Сам стилер нацелен на устройства под управлением ОС Windows, поэтому атакующие так настойчиво просили журналиста открыть архив на рабочем компьютере, а не с iPhone, чего он и правильно делать не стал. Hunter "умеет" автоматически собирать учетные записи на зараженном компьютере, затем отсылает их злоумышленнику и раньше его, к примеру, часто использовали для кражи учетных данных у игроков GTA. Никита Карпов, младший вирусный аналитик CERT-GIB, провел анализ вредоносного файла и рассказал об особенностях киберохоты на популярные Telegram-каналы .

Кейс Базы

Стилер написан на C++ и рассылается владельцам каналов под видом предложения рекламы. Например, экземпляр, разбираемый в этой статье, маскировался под рекламу от GeekBrains.

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

Функционал

Функционал стилера реализован в методах, представленных ниже:

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

Полученные временные файлы помещаются в архив внутри памяти процесса и затем удаляются.

Discord

Для похищения сессии Discord стилер ищет папку \discord\Local Storage\leveldb\ и копирует содержимое каждого файла во временный файл.

В архиве файлы записываются в папку с названием приложения и сохраняют изначальное имя файла Application\File.name.

Для примера была создана папка \discord\Local Storage\leveldb\ с файлом T.token.

Скриншот рабочего пространства

Для получения длины и ширины экрана используется win API GetSystemMetrics(). GetDC(0) используется, чтобы получить handle всего экрана, и с помощью CreateCompatibleBitmap() создается bitmap-объект, который сохраняется в файл Desktop.png.

Сбор файлов

Стилер получает путь USERPROFILE = C:\Users\USERNAME и собирает все файлы с расширениями из списка:

• .txt

• .rdp

• .docx

• .doc

• .cpp

• .h

• .hpp

• .lua (скрипты для GTA SAMP)

Steam

Для стилера интересны файлы с расширением .ssfn в папке Software\Valve\Steam\ssfn и все файлы из папки Steam/config/.

Для обхода защиты Steam Guard и доступа к аккаунту необходимо, чтобы пароль был сохранен в Steam-клиенте (галочка Запомнить пароль). Также нужны файлы с компьютера жертвы, которые собирает стилер:

• файл с расширением .ssfn

• config.vdf

• loginusers.vdf

• SteamAppData.vdf

Telegram

Стилер проверяет наличие Telegram среди процессов и получает расположение исполняемого файла "Telegram.exe". Далее программа проверяет, есть ли passcode в папке key_datas, и, если он установлен стилер начинает похищать данные других приложений. Если же Telegram не защищен passcodeом, то стилер похищает из папки \tdata\ файл, начинающийся с D877F783D5D3EF8C (в конце может быть любой символ), и файл, находящийся в \tdata\ D877F783D5D3EF8C и начинающийся с map (в конце может быть любой символ). Этих двух файлов будет достаточно для похищения сессии Telegram.

GTA SAMP

Данный стилер изначально ориентирован на игроков в GTA SAMP и похищение их аккаунтов. Об этом говорят файлы, собираемые с компьютера жертвы (скрипты, которые могут относиться к игре) и файлы, собираемые из \Documents\GTA San Andreas User Files\SAMP\. Для стилера интересны следующие файлы:

• USERDATA.DAT хранит информацию о серверах, записывается в SAMP\servers.fav

• chatlog.txt записывается в "SAMP\chatlog.txt"

Браузеры

Учетные данные пользователей браузера Mozilla Firefox стилер похищает из файла logins.json, который ищет в \Mozilla\Firefox\Profiles. Из браузеров Google Chrome и Chromium собираются:

• данные о местоположении

• учетные данные от аккаунтов на ресурсах

• данные для автозаполнения форм

• данные карт

• cookies

• аккаунты Facebook

Данные криптокошельков

Для всех криптокошельков алгоритм одинаковый:

• Расшифровывается путь, связанный с кошельком:

  • Atomic \Atomic\Local Storage\leveldb\

  • Electrum \Electrum\wallets

  • Ethereum \Ethereum\keystore

  • Zcash \Zcash\

  • Exodus \Exodus\exodus.wallet\

• Содержимое всех файлов переносится во временные файлы и помещается в архиве в папку с именем кошелька:

Бот нашел тестовый файл в папке.

И переместил его в архив.

Отчет

После сбора всех пользовательских данных создается файл "readme.txt", содержащий информацию о похищенных данных.

Для всех приложений в отчете отмечается, получилось ли похитить данные.

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

Все собранные файлы помещаются в архив и отправляются на CnC.

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

Адрес командного центра также находится в зашифрованных строках:

Сетевое взаимодействие происходит через IPv6 или, если он недоступен через IPv4 по протоколу TCP. Для отправки архива с похищенными данными открывается сокет с портом 0x8AE = 2222.

В виде админ-панели выступает Telegram-бот, который находится на VDS (Virtual Dedicated Server). Похищенные данные изначально попадают к владельцу сервера, а затем отправляются клиенту через Telegram-бота.

В дампе трафика, полученного из отчета модуля THF Polygon, видим передачу архива.

Шифрование

Алгоритм шифрования, используемый для защиты строк:

• На вход функции дешифровки подаются три параметра:

  • XOR-константа для данного слова

  • константа для инициализации KSA (Key Scheduling Algorithm)

  • длина строки

• Для генерации ключа используются два последовательных KSA. Первый ключ генерируется по длине нужной строки из константы и ключа размером 32 байта, который генерируется алгоритмом MurMurHash2 по 4 байта. Второй получает результат работы первого и еще один сгенерированный через MurMurHash2 ключ.

• Для каждого символа ключа, полученного из второго KSA, выполняется операция XOR с константным значением.

Противодействие анализу

Для противодействия анализу используются следующие методы:

• шифрование строк, разобранное выше

• определение наличия отладки через win API-вызов IsDebuggerPresent()

Продавец и разработчик

В объявлениях на форумах продавец Hunter указывает свой контакт в Telegram как @NoFex228. К этому аккаунту привязан профиль Александра ХХ. во ВКонтакте, где обнаружено несколько постов, связанных с различными стилерами и продажей аккаунтов из GTA SAMP. Telegram-аккаунт разработчика указан во всех отчетах бота как @karelli. К нему привязан телефонный номер, связанный со страницей "ВКонтакте" некоего Анатолия ХХ.

Заключение

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

Если у владельца Telegram-канала не включен код-пароль приложения, то злоумышленникам не составит труда восстановить сессию и сменить владельца канала. Так что вывод прост: не открывать подозрительные сообщения, архивы и ссылки и не пользоваться ОС, где стилеры чувствуют себя как дома.

Что делать, если заражение уже произошло?

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

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

Этим постом мы начинаем двухсерийный технодетектив, в котором встретились "священная триада" доменов: putin, kremlin, crimea и "крысы" программы удаленного доступа (RAT), а также шпион AgentTesla. Началась история с того, что в конце мая 2020 года сетевой граф Group-IB, наша автоматизированная система анализа инфраструктуры, начал детектировать домены с интересным паттерном *kremlin*.duckdns.org, к которым подключались различные вредоносные файлы. Аналитики Group-IB Threat Intelligence & Attribution исследовали эти домены и установили три кампании по распространению различных RAT. Они шли с 2019 года и были нацелены на пользователей из Польши, Турции, Италии, Украины, России, Казахстана, Болгарии, Беларуси, Греции и Чехии. В ходе расследования была установлена связь между обнаруженными доменами и остальной используемой инфраструктурой, а заодно и с конкретным человеком, который стоит за распространением AgentTesla и других вредоносных программ. Итак, обо всем по-порядку.

Кампания лета 2020 года

В начале список доменов, который привлёк наше внимание, выглядел так:

• crimea-kremlin.duckdns.org

• kremlin-afghan.duckdns.org

• kremlin-crimea.duckdns.org

• kremlin-turbo.duckdns.org

Данные домены были зарегистрированы на один IP-адрес 79.134.225.43 15 июня 2020 года. По данным сетевого графа Group-IB, только с этими четырьмя доменами связанно порядка 30 различных вредоносных файлов. Судя по документам-приманкам, данная кампания была нацелена на пользователей из Польши, Турции, Италии, Германии и Болгарии.

Дальнейший анализ показал, что в основном файлы были залиты в публичные источники, начиная с 25 июня 2020 года. Самые распространенные имена Potwierdzenie transakcji.xls, lem makbuzu, WACKER - 000160847.xls, Potwierdzenie operacji.xls. Один из таких файлов, SHA1: 95A6A416F682A9D254E76EC38ADE01CE241B3366, является документом-приманкой на польском языке и якобы отправлен от Bank Polski.

Заражение

После активации макросов в этом документе выполняется PS-скрипт для извлечения команды второго этапа из файла lab.jpg, размещенном на удаленном сервере:

В файле lab.jpg содержится обфусцированная в BASE64 команда, которая после декодирования выглядит следующим образом:

Данный код считывает содержимое файла http://officeservicecorp[.]biz/rnp.txt, в котором и находится полезная нагрузка.

В результате выполнения данной последовательности PS-скриптов загружается и выполняется популярный NetWire RAT, который и производит подключение к своему C&C-серверу kremlin-crimea[.]duckdns.org на порт 3396.

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

Интересно, что те файлы, которые подключались к office-service-tech[.]info, также производили сетевое подключение к ahjuric[.]si. Пример таких файлов SHA1 a3816c37d0fbe26a87d1cc7beff91ce5816039e7. Это документ-приманка на турецком языке с логотипом государственного банка Турции.

Данный документ также содержит вредоносный макрос, исполняющий PS-скрипт, который считывает Code.txt с удаленного сервера и запускает цепочку обфусцированных PS-скриптов.

Результатом выполнения обфусцированного PS-скрипта будет выполнение еще одного обфусцированного в Base64 скрипта, который в конечном счете и выполнит полезную нагрузку в виде Netwire Rat из office-service-tech[.]info/pld.txt.

C&C-сервером данного образца является crimea-kremlin.duckdns[.]org.

Также мы обнаружили файлы, которые производят сетевое подключение одновременно к kremlin-turbo.duckdns[.]org и wshsoft[.]company. Название домена относит нас к WSH RAT, который основан на коде Houdini. Один из таких файлов SHA1: b42a3b8c6d53a28a2dc84042d95ce9ca6e09cbcf. Данный образец RAT отправляет на C&C-сервер kremlin-turbo.duckdns[.]org:3397 запросы вида /is-ready, а в качестве UA у него указан WSHRAT.

На этом этапе важно отметить, что часть используемых доменов в этой кампании была зарегистрирована на почту tetragulf@yahoo.com.

Кампания весны 2020 года

Изучая всю остальную связанную инфраструктуру, мы обратили внимание на домены, зарегистрированные на asetonly@yahoo.com. С начала 2020 года на эту почту были зарегистрированы следующие домены:

1. nitro-malwrhunterteams.com

2. office-data-labs.com

3. putin-malwrhunterteams.com

4. kremlin-malwrhunterteam.info

5. skidware-malwrhunterteams.com

6. screw-malwrhunterteams.com

7. screw-malwrhunterteam.com

8. office-services-labs.com

9. office-cloud-reserve.com

10. office-clean-index.com

11. office-cleaner-indexes.com

Мы собрали более 130 различных образцов вредоносных программ из различных источников, связанных только с этими доменами. Судя по названиям и содержимому данных образцов, кампания весны 2020 года была нацелена на пользователей из Европы и стран СНГ мы обнаружили документы-приманки на украинском, белорусском, казахском, русском и греческом языках.

Первые файлы данной кампании были загружены на публичные песочницы 23 марта 2020 года. Один из таких файлов Аналз проекту.docx SHA1-d8826efc7c0865c873330a25d805c95c9e64ad05 распространялся в качестве вложения к письму Електронна розсилка_ Змнене замовлення.eml SHA1-7f1fdf605e00323c055341919173a7448e3641fb, которое было загружено на VirusTotal через веб-интерфейс из Украины.

Заражение

Содержимое самого документа не вызывает интереса и выглядит как отсканированный лист со счетом. Однако сам документ во время запуска эксплуатирует уязвимость CVE-2017-0199. В результате выполняется команда, которая загружает полезную нагрузку в виде http://office-cloud-reserve[.]com/hydro.exe.

Загружаемой полезной нагрузкой является программа-шпион AgentTesla (почитать о ней вы можете тут, тут и тут). В качестве сервера для эксфильтрации данных используется ftp.centredebeautenellycettier[.]fr легитимный домен, который, по всей видимости, был скомпрометирован.

Другой исследуемый файл SHA1- 19324fc16f99a92e737660c4737a41df044ecc54, который называется Байланыс орталытары.img, распространялся в качестве вложения через электронное письмо SHA1- 403c0f9a210f917e88d20d97392d9b1b14cbe310 на казахском языке c темой, относящейся к COVID-19.

Данное вложение является .iso-образом и в некоторых случаях называется Байланыс орталытары.img. Файл монтируется в систему как образ, в котором находится лишь один обфусцированный VBS-файл SHA1: fd274f57e59c8ae3e69e0a4eb59a06ee8fd74f91 под названием Денсаулы сатау бойынша анытамалы жне деректер базасы.vbs. Данный файл по сути является загрузчиком, который выполняет обфусцированный PS-код. При его открытии происходит считывание файла http://office-cleaner-indexes[.]com/loud.jpg.

В результате происходит загрузка и выполнение AgentTesla, который также производит эксфильтрацию данных через ftp.centredebeautenellycettier[.]fr.

Другой документ SHA1: c992e0a46185bf0b089b3c4261e4faff15a5bc15 под названием 060520.xls распространялся через письмо на греческом языке, а его содержимое выглядит так же, как и все другие в этой кампании, только на греческом языке. Его полезная нагрузка в виде NanoCore Rat подключается к screw-malwrhunterteams[.]com.

Кампания 2019 года

Продолжая исследовать инфраструктуру, связанную с tetragulf@yahoo.com, мы обнаружили, что в 2019 году на эту почту было зарегистрировано всего четыре домена, два из которых были зарегистрированы в конце февраля и участвовали в одной кампании по распространению вредоносных документов.

Список зарегистрированных доменов (подчеркнутые точно вредоносные):

• east-ge.com

• mariotkitchens.com

• sommernph.com

• kingtexs-tvv.com

Первые файлы, связанные с этими доменами, начали загружаться в публичные песочницы 18 июня 2019 года.

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

Заражение

Один из первых документов этой кампании распространялся через электронную почту под разными названиями: CNC 0247.doc, ЧПУ 0247.doc SHA1:443c079b24d65d7fd74392b90c0eac4aab67060c.

Согласно данным из нашего графа, этот документ устанавливает подключение к http://68.235.38[.]157/ava.hta и kingtexs-tvv[.]com.

Мы заинтересовались этим хостом и обнаружили дополнительные файлы, которые устанавливали сетевое подключение к http://68.235.38[.]157. Одни из таких файлов, Estos son los documentos adjuntos de junio.doc SHA1: 02799b41c97b6205f1999a72cef8b8991d4b8092 и New Order.doc SHA1: 25abf0f75c56516134436c1f836d9db1e770ff30, эксплуатируют уязвимость CVE-2017-11882. Во время запуска они устанавливают подключение к http://68.235.38[.]157/oyii.hta.

Этот файл содержит код на Visual Basic, который выполняет обфусцированную в Base64 PS-команду на загрузку полезной нагрузки из общедоступного файлового хранилища https://m.put[.]re/Qm8He5E4.exe - SHA1: 523c5e0a1c9bc6d28f08500e96319571b57e4ba7 и сохраняет в директорию temp под именем avantfirewall.exe.

Загружаемая полезная нагрузка считывает содержимое из https://paste[.]ee/r/rSrae, вследствие чего выполняется Async RAT, который устанавливает подключение к своему C&C-серверу kizzoyi.duckdns[.]org на порт 8808.

Другой документ из данной кампании SHA1-1230acfd1f6f5b13a218ff8658a835997d1f0774 под названием таблиц.doc распространялся через письмо на украинском языке.

Из-за критически опасной уязвимости CVE-2017-11882, позволяющей выполнить вредоносный код без взаимодействия с пользователем, во время запуска этого документа происходит выполнение кода, содержащегося в OLE-объекте wd32PrvSE.wmf.

В результате выполнения кода из OLE-объектов загружается и выполняется Async RAT.

Заключение

На этой ноте мы заканчиваем первую часть исследования. Мы понимаем, что этот детектив должен закончиться чем-то логичным, и в следующей части вы с новыми силами окунетесь в развязку данной истории. Пока же можете изучить наше ежегодное исследование Hi-Tech Crime Trends или взглянуть на наши вакансии.

Рекомендации

Ниже техники атакующего и защитные техники в соответствии с MITRE ATT&CK и MITRE Shield, которые мы рекомендуем использовать для защиты и предотвращения инцидентов.

Все защитные техники реализованы в продуктах Group-IB для защиты на разных этапах атаки. Если у вас будут вопросы или подозрения на инцидент обращайтесь на response@cert-gib.com.

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

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

• используемый язык программирования;

• набор привилегий, которые доступны ПО;

• процедура предоставления удаленного доступа;

• особенности реализации программного обеспечения (если есть).

Disclamer: Статья не претендует на полноту описываемой информации и предоставляет информацию только в образовательных целях.

Вредоносное программное обеспечение и ОС

Как известно, система Android своим ядром обязана Linux. И как свой прародитель, ОС Android считалась неприступной для вредоносного программного обеспечения. По мере развития системы в нее добавлялись новые функции, которые должны были еще больше обезопасить систему. Среди них:

• песочница для каждого отдельного приложения;

• организация доступа к ресурсам ОС за счет большого количества правил SELinux подсистемы;

• использование нотификации для пользователей с перечнем необходимых для работы приложения привилегий.

Однако и это не помогло на 100% защитить систему. Почему? Наиболее распространенный способ инфицирования данной ОС использование патченного софта и социальная инженерия. Причем обычно пользователям предлагается работать с интерфейсом, который неотличим от системного то есть любое приложение ОС Android может использовать нотификации и Intent`ы, которыми пользуется сама ОС.

ВПО под Android развивается отчасти по пути open source: в сеть периодически попадают исходные коды вредоносов, которое использовалось злоумышленниками, что в свою очередь помогает менее квалифицированным вирусописателям ускорить создание своих зловредов. Попробуем раздобыть эти исходники из публичных источников.

Первым подопытным будет троян Anubis. Вот тут есть относительно свежая новость о том, с чем и как работает этот троян.

Anubis

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

Набор требуемых привилегий на самом деле зашкаливает. Приведем часть AndroidManifest:

...    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />    <uses-permission android:name="android.permission.GET_TASKS" />    <uses-permission android:name="android.permission.RECEIVE_SMS" />    <uses-permission android:name="android.permission.READ_SMS" />    <uses-permission android:name="android.permission.WRITE_SMS" />    <uses-permission        android:name="android.permission.PACKAGE_USAGE_STATS"        tools:ignore="ProtectedPermissions" />    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />    <uses-permission android:name="android.permission.CALL_PHONE" />    <uses-permission android:name="android.permission.INTERNET" />    <uses-permission android:name="android.permission.SEND_SMS" />    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />    <uses-permission android:name="android.permission.RECORD_AUDIO" />    <uses-permission android:name="android.permission.READ_CONTACTS" />    <uses-permission android:name="android.permission.READ_PHONE_STATE" />    <uses-permission android:name="android.permission.WAKE_LOCK" />    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />    <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />...

Похоже, что приложение будет системным, а также будет практически 24/7 мониторить активность пользователя и получать необходимые данные для своих целей. ОС не должна препятствовать деятельности этого приложения, если пользователь согласился с таким набором привилегий.

ВПО представляет собой троян, который может предоставлять доступ к зараженному устройству. Это осуществляется через создание сервиса, который имеет говорящее название "ServiceRAT". Регистрируется он стандартно через манифест. Часть исходника самого сервиса:

...public class ServiceRAT extends IntentService {    String botid="";    UtilsClass utilsClass = new UtilsClass();    Constants const_ = new Constants();    RequestHttp  http = new RequestHttp();    StoreStringClass storeStringClass = new StoreStringClass();...

Никаких изысков, используем http для передачи данных, и шифруем всё через RC4. Можно бы было придраться к code style, но похоже, что злоумышленники не парятся о подобном. Сам вредонос работает классически получает зашифрованные данные от сервера и выполняет:

...  UtilsClass utilsClass = new UtilsClass();        try        {            byte[] data = Base64.decode(textDE_C, Base64.DEFAULT);            textDE_C = new String(data, "UTF-8");            byte[] detext = utilsClass.hexStringToByteArray(textDE_C);            ClassRC4 rcd = new ClassRC4(key.getBytes());            return  new String(rcd.decrypt(detext));...

Если смотреть код управления устройством полностью, то глаз зацепится за вот такой фрагмент:

...responce = utilsClass.trafDeCr(responce);           utilsClass.Log("RATresponce",""+responce);           if(responce!="**"){               utilsClass.Log("RAT_command", "" + responce);               if(responce.contains("opendir:")){                   String opendir = responce.replace("opendir:","");                   opendir = opendir.split("!!!!")[0];                   if(opendir.contains("getExternalStorageDirectory"))opendir = Environment.getExternalStorageDirectory().getAbsolutePath();                   String getFileFolder = utilsClass.listFilesWithSubFolders(new File(opendir));                   ...

Похоже, у автора была 100% уверенность, что любая команда для вредоноса будет введена всегда 100% корректно. Поэтому можно не переживать о наполнении opendir и просто выполнить команду.

Вывод: данный зловред никаких интересных трюков не использует. Разрешенные действия, которые описаны полностью в манифесте подчиняют практически полностью всю ОС. Все функции реализованы в рамках стандартного использования функций ОС и её библиотек. Отсутствует code style.

Cerber

Ещё один зловред, исходный код которого утёк в сеть. Недавняя новость о его функционале. Данная малвара имеет интересную особенность: практически все функции реализованы в отдельном файле, видимо разработчик таким образом хотел вынести весь алгоритм и иметь возможность обфусцировать его автоматическими средствами. Возможно, так было бы удобнее еще добавлять дополнительный функционал, но если задуматься, вероятно это один из методов обхода механизма проверки приложений для Google Play, так как вредонос достаточно часто светится в официальном магазине.

Используемый язык программирования: Java. Набор привилегий:

...    <application        android:allowBackup="true"        android:label="module"        android:supportsRtl="true"        android:theme="@android:style/Theme.Translucent.NoTitleBar">        <activity android:name=".MainActivity">            <intent-filter>                <action android:name="android.intent.action.MAIN" />                <category android:name="android.app.role.SMS" />                <category android:name="android.intent.category.LAUNCHER" />            </intent-filter>        </activity>    </application>...

Объявления привилегий нет, у приложения всего лишь один Intent. Фрагмент исходника обработчика:

...import java.lang.reflect.Method;public class MainActivity extends Activity {    mod tt = new mod();    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);               tt.checkProtect(this);        try {            Class c = Class.forName("com.example.modulebot.MainActivity");            Method m = c.getMethod("ssss");            m.invoke(c.newInstance());        } catch (Throwable t) {        }        tt.main(this,"");    }...

Как было упомянуто ранее, основной алгоритм ВПО записан в отдельный модуль. Отследить работу алгоритма можно по объекту "tt". Автор вредоноса также не особенно переживает за поддержку данного кода, все объекты не имеют четкого именования. Видимо, данный модуль не планировали использовать долго.

Функционал вредоноса не ограничивается отправкой СМС, в нем так же есть работа с апдейтом модуля приложения:

...case "updateModule":                        utl.SettingsWrite(context, "statDownloadModule", "0");                        try {                            new File(context.getDir("apk", Context.MODE_PRIVATE), "system.apk").delete();                        }catch (Exception ex){                            utl.SettingsToAdd(context, consts.LogSMS , "(MOD5)  | updateModule " + ex.toString() +"::endLog::");                        }....

Дополнительный файл "system.apk", к сожалению, отсутствует среди исходников, но вероятно он загружался с управляющего сервера. Удаленного доступа данный вредонос не предоставляет совсем. Весь функционал реализуется на основании конфига, который автоматически выполняет операции, которые ему передал злоумышленник на этапе запуска.

Вывод: ВПО работает только с СМС, которые проксируются в лог и пересылаются на конкретный номер. Снова полное отсутствие code style.

DefensorId

Еще одно ВПО, которое распространялось на ОС Android. Относительно свежую новость о нем можно найти здесь. Снова язык программирования Java, похоже зловреды категорически не хотят использовать Kotlin.

Набор запрашиваемых привилегий:

...<uses-permission android:name="android.permission.SYSTEM_OVERLAY_WINDOW" />    <uses-permission android:name="android.permission.BIND_ACCESSIBILITY_SERVICE"        tools:ignore="ProtectedPermissions" />    <uses-permission android:name="android.permission.REQUEST_DELETE_PACKAGES"/>    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />    <uses-permission android:name="android.permission.FOREGROUND_SERVICE"/>    <uses-permission android:name="android.permission.WRITE_SETTINGS"        tools:ignore="ProtectedPermissions" />        <service            android:name=".CoreService"            android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"...

ВПО славится тем, что может работать с пользовательским интерфейсом и воровать данные пользователя. Для подобного функционала в ОС Android необходимо обладать специальными привилегиями, которые выдаются только специальному функционалу Расширенные возможности ввода (ACCESSIBILITY). Ниже приведен фрагмент кода, который старается такие привилегии запросить для возможности рисовать свой Intent поверх других приложений:

...public void overayPermission(){            if (!Settings.canDrawOverlays(this)) {                Intent myIntent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION);                startActivityForResult(myIntent, WIN_REQ_CODE);            }    }    public void AccessibilityAllow() {        AlertDialog.Builder gsDialog = new AlertDialog.Builder(this);        gsDialog.setTitle("Message");        gsDialog.setCancelable(false);        gsDialog.setMessage("please need to allow the permission");        gsDialog.setPositiveButton("OK", new DialogInterface.OnClickListener() {            public void onClick(DialogInterface dialog, int which) {                startActivityForResult(new Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS),CORE_REQ_CODE);            }        }).create().show();    }    ...

Социальная инженерия во всей красе. Если система не дала запустить приложение с возможностью помещать свой Intent поверх других приложений запросить у пользователя эту возможность. С высокой долей вероятности нотификацию от системы будет им подтверждена без подозрений. Удаленный доступ к устройству в этом ВПО не предоставляется, весь функционал обрабатывается автоматически.

Вывод: Код создавался более опытным программистом, есть осмысленное именование объектов. Функционал реализуется за счет возможностей самой ОС и применяется для социальной инженерии.

Вывод

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

Автор статьи Александр Колесников.

Статья подготовлена в рамках курсов "Android Developer. Basic" и "Android Developer. Professional".

Также приглашаем на открытый вебинар на тему Рисуем свой график котировок в Android. На занятии участники вмеcте с экспертом:
рассмотрят основные инструменты для рисования;
изучат возможности классов Canvas, Path, Paint;
нарисуют кастомизируемый график котировок и добавим в него анимаций.
Присоединяйтесь!

Pedro Tavares

Обнаруженное недавно семейство вредоносного ПО под названием Epic Manchego использует хитрый трюк для создания вредоносных файлов MS Excel с минимальной степенью обнаружения и повышенной вероятностью обхода систем безопасности. Изучая способы обхода систем безопасности, используемые злоумышленниками, можно понять, какие первоочередные меры следует предпринять для защиты систем от атак подобного рода.

Описание угрозы

Семейство вредоносного ПО "работает" с июня 2020 года и атакует организации из разных стран с применением фишинговых сообщений электронной почты, содержащих изменённый файл Excel. Чтобы фишинговые сообщения не попадали в папки со спамом и против них не срабатывали механизмы отсечения нежелательной почты, злоумышленники отправляют свои письма с официальных учётных записей организаций. Учётные данные таких организаций, как правило, попадают в руки злоумышленников в результате взлома. Злоумышленники с помощью сервиса проверки аккаунтов на утечки "Have I Been Pwned?" проверяют, были ли скомпрометированы учётные записи электронной почты, или просто взламывают такие записи до того, как приступить к вредоносной рассылке.

Согласно данным NVISO, "через VirusTotal было пропущено около 200 вредоносных документов, и был составлен список из 27 стран, ранжированных по количеству отправленных документов. В списке не делалось различие, каким способом загружались такие файлы (возможно, через VPN)".

В ходе исследования выяснилось, что наибольшему риску рассылки вредоносных файлов подвергаются такие страны, как Соединённые Штаты Америки, Чешская Республика, Франция, Германия и Китай.

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

Как работает Epic Manchego

В некоторых рассылаемых документах Office содержатся нарисованные фигуры, например прямоугольники, как это показано на рисунке 4.

Вредоносные документы Microsoft Office создаются не через Microsoft Office Excel, а с использованием .NET библиотеки EPPlus. Поскольку такие документы не являются стандартными документами Excel, они могут маскироваться и обходить защитные механизмы.

Документ на рисунке 4 содержит объект drawing1.xml (скруглённый прямоугольник) с именем name="VBASampleRect и создан с использованием исходного кода EPPLUS Wiki (справа), как это показано ниже.

Если открыть окно макросов документа, в нём не будет ни одного макроса.

Тем не менее вредоносный код существует и к тому же защищён паролем. Интересно отметить, что этот код VBA вообще не зашифрован, а представлен открытым текстом.

При открытии документа с VBA-проектом, защищённым паролем, макросы VBA будут запускаться без пароля. Пароль необходим только для просмотра проекта VBA внутри интегрированной среды разработки (IDE) VBA.

Если внести изменения в строку DPB или дешифровать пароль, можно увидеть, что при запуске вредоносного файла Office на компьютере жертвы запускается и выполняется полезная нагрузка PowerShell.

На приведённом ниже скриншоте продемонстрирован запуск полезной нагрузки PowerShell во время заражения.

Согласно результатам исследования NVISO Labs, чтобы загрузить полезную нагрузку в коде VBA, используются либо объекты PowerShell, либо объекты ActiveX, в зависимости от разновидности исходного вредоносного ПО.

Анализ завершающего этапа работы вредоносного ПО

Через вредоносный код VBA на втором этапе с различных интернет-сайтов загружается полезная нагрузка. Каждый исполняемый файл, создаваемый соответствующим вредоносным документом и запускаемый на втором этапе, выступает для конечной полезной нагрузки как носитель вируса (дроппер). После этого на втором этапе также загружается вредоносный файл DLL. Этот компонент DLL формирует дополнительные параметры и полезную нагрузку для третьего этапа, после чего запускает на выполнение конечную полезную нагрузку, которая, как правило, крадёт информацию.

Как отмечают исследователи из NVISO Labs, "несмотря на то что описанная выше схема обфускации данных применяется многими вредоносными программами, мы видим, как она усложняется, поэтому существует вероятность применения более изощрённых методик".

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

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

Чаще всего (более чем в 50% случаев) на компьютер жертвы устанавливается вредоносная программа AZORult, похищающая личные данные пользователей, программы для кражи информации называются инфостилерами. В качестве других полезных нагрузок могут использоваться трояны AgentTesla, Formbook, Matiex и njRat, причем Azorult и njRAT имеют высокий уровень повторного использования.

Обнаружение и действия

Для запуска вредоносных программ злоумышленники придумывают новые методы обхода систем обнаружения угроз и реакции на конечных точках (EDR) и антивирусных программ (AV). При использовании нового способа создания вредоносных документов Office механизмы обнаружения угроз не должны позволять вредоносному ПО переходить на следующий этап. Часто на этом этапе запускается скрипт PowerShell, который может выполняться в памяти без обращения к диску.

Обнаружение и блокирование новых способов заражения посредством создания вредоносных документов (maldoc), один из которых описывается в настоящей статье, позволит организациям оперативно реагировать на инциденты. Для предотвращения атак подобного рода рекомендуется принимать следующие меры:

• Предупредить пользователей, что они могут стать объектами социальной инженерии, и научить их правильно вести себя в случаях атак.

• Регулярно обновлять программное обеспечение, приложения и системы до последних версий.

• Использовать решения защиты конечных точек (Endpoint Protection) и обновлённое антивирусное ПО для предотвращения заражения вредоносными программами.

• Использовать системы управления уязвимостями и мониторинга для выявления потенциальных неустранённых уязвимостей и инцидентов в режиме реального времени.

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Источники:

• Epic Manchego, NVISO Labs.

• Использование библиотеки .NET для обхода антивируса, ZDNet.

В статье хотим рассказать про технологию TLS fingerprinting, про которую недостаточно материалов в русскоязычном сегменте. Попробуем это исправить. Статья частично переводит тематические материалы авторов описываемых методов (тут и тут), а также содержит описание практической реализации от Акрибии.

Не будем глубоко погружаться в детали работы SSL/TLS (далее будем говорить TLS), но кратко поясним детали.

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

Чтобы инициировать сеанс TLS, клиент отправляет пакет приветствия серверу после трёхстороннего установления связи TCP. Этот пакет и способ его создания зависят от пакетов и методов шифрования, используемых при создании клиентского приложения. Если сервер принимает соединение TLS, он ответит пакетом приветствия, тем самым продолжая согласование шифрования.

Поскольку согласование шифрования TLS передаётся в открытом виде, то можно отследить и идентифицировать клиентские приложения.

В этом и суть технологии TLS fingerprinting, если кратко. А теперь немного подробнее.

TLS fingerprinting

Суть технологии в захвате элементов пакета приветствия клиента, которые остаются статичными от сеанса к сеансу для каждого клиента. На их основе можно создать отпечаток пальца для распознавания конкретного клиента в последующих сеансах. Записываются следующие поля:

• версия TLS;

• версия записи TLS;

• наборы шифров;

• параметры сжатия;

• список расширений.

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

• алгоритмы подписи;

• алгоритм для шифрования данных;

• хэш функция для проверки содержимого.

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

Почему это круто:

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

• Можно захватывать пакеты приветствия клиента TLS с высокой степенью точности по всем портам с абсолютно нулевым требованием для захвата обоих направлений потока. Это означает, что датчики в среде с асимметричной маршрутизацией или с ограничениями ресурсов, потенциально вызывающими отбрасывание пакетов, все равно могут собирать пакеты приветствия клиента, независимо от того, были ли они скрыты из-за работы на нестандартных портах.

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

Наиболее очевидное использование TLS Fingerprinting пассивное обнаружение. Технология позволяет обнаруживать широкий спектр потенциально нежелательного трафика, не требуя доступа к конечным точкам. Можно обнаруживать как конкретные вредоносы по их поведению и/или обращениям к командным центрам, так и обычный софт, используемый не по назначению или в обход действующих правил.

Например, к серверу Exchange могут обращаться только почтовые клиенты или браузер, если используется OWA, поэтому соединение из скрипта на Python будет подозрительным.

Итого: TLS Fingerprinting предназначен для быстрой идентификации известных TLS-соединений и отслеживания неизвестных TLS-соединений. Входные данные принимаются либо посредством прослушивания трафика, либо при чтении PCAP файлов.

Есть несколько готовых реализаций, наиболее поддерживаемых комьюнити:

• пассивный метод с использованием хэшей JA3 и JA3S;

• активный инструмент снятия отпечатков пальцев с сервера TLS хэши JARM.

JA3 и JA3S

Метод JA3 используется для сбора десятичных значений байтов для следующих полей в пакете приветствия клиента: версия TLS, набор шифров, список расширений протоколов TLS, эллиптические кривые и форматы эллиптических кривых. Затем он объединяет эти значения вместе по порядку, используя символ , для разграничения каждого поля и - для разграничения каждого значения в каждом поле.

Порядок полей следующий:

TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats

Пример:

771,49196-49162-49195-52393-49161-49200-49172-49199-52392-49171-159-57-56-107-158-52394-51-50-103-22-19-157-53-61-156-47-60-10,0-23-65281-10-11-13-28,29-23-24-25,0

Если в ClientHello нет расширений TLS, поля остаются пустыми:

769,451091009836191899,,,

Эти строки затем хэшируются MD5. Пример отпечатка JA3:

c8446f59cca2149cb5f56ced4b448c8d

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

Порядок полей, следующий:

TLSVersion,Cipher,Extensions

Пример:

769,47,6528101135516

Если в Server Hello нет расширений TLS, поля остаются пустыми.

Пример:

769,47,

Эти строки затем хэшируются MD5 для создания 32-символьного отпечатка пальца.

Это отпечаток JA3S:

4835b19f14997673071435cb321f5445

JA3 и JA3S это методы снятия отпечатков TLS. JA3 отслеживает способ, которым клиентское приложение обменивается данными через TLS, а JA3S отслеживает ответ сервера. Вместе они создают отпечаток криптографического согласования между клиентом и сервером.

Теперь перейдем к описанию активного метода JARM.

JARM

JARM работает, активно отправляя 10 пакетов приветствия клиента TLS на целевой сервер и фиксируя определенные атрибуты ответов приветствия сервера. Затем агрегированные ответы сервера TLS хэшируются определенным образом для получения отпечатка JARM. JARM отправляет разные версии, шифры и расширения TLS в разном порядке для сбора уникальных ответов. Хэш JARM представляет собой гибридный нечеткий хэш, он использует комбинацию обратимого и необратимого алгоритма хеширования для создания 62-символьного отпечатка.

Отпечатки JARM можно использовать:

• убедиться, что все серверы в группе имеют одинаковую конфигурацию TLS;

• сгруппировать разрозненные серверы в сети Интернет по конфигурации, указав, например, что сервер может принадлежать Google, Yandex или Apple;

• определить приложения или инфраструктуру по умолчанию;

• выявить командные центры и других вредоносные серверы в сети Интернет.

  

Первые 30 символов состоят из шифра и версии TLS, выбранных сервером для каждого из 10 отправленных приветствий клиента. 000 означает, что сервер отказался согласовывать приветствие с этим клиентом. Остальные 32 символа представляют собой усеченный хэш SHA256 совокупных расширений, отправленных сервером, без учета данных сертификата x509. При сравнении отпечатков JARM, если первые 30 символов совпадают, но последние 32 отличаются, это будет означать, что серверы имеют очень похожие конфигурации, принимают одинаковые версии и шифры, но используют различные расширения, что не позволяет их считать полностью идентичными.

Исторически так сложилось, что индустрия кибербезопасности была сосредоточена в основном на индикаторах компрометации (IOC) и индикаторах атаки (IOA). То есть когда вредоносное ПО/хост и т.п. будут кем-то обнаружены, исследователи или вендоры платформ TI вычленяют уникальные или не очень признаки выявленного вредоноса или атаки типа IP, домена, хэша файла и т.п. и публикуют их в чёрных списках. Проблема в том, что к этому моменту вредоносное ПО уже распространено, и специалисты ИБ автоматически переходят в оборону.

Интернет-сканирование JARM в сочетании с другими метаданными и историческим анализом даёт возможность упреждающей идентификации IOC для новых вредоносов. Например, можно сканировать Интернет с помощью JARM, сопоставлять известные результаты JARM с историей домена, IP и репутацией вместе с данными сертификата для создания черного списка. Это позволяет перейти к возможности программного создания высокоточных списков блокировки до того, как первая вредоносная программа будет распространена.

Можно использовать JARM автоматически сканируя все хосты назначения, детектируемые в сети компании, для обогащения событий, и использовать сводную таблицу, чтобы не сканировать одни и те же хосты несколько раз. Затем можно запускать запросы заведомо плохих JARM или использовать список для корреляции.

Чтобы упростить процесс, можно использовать готовое решение. В настоящее время хэши JARM умеют считать продукты Palo Alto Networks и используют их API для обогащения целевого JARM.

Примеры реализации

Если нет возможности или желания использовать готовые решения от Palo Altoи пр., можно реализовать в своей инфраструктуре свое средство мониторинга трафика, например, на основе Zeek (ранее назывался Bro) популярного open-source продукта, заточенного специально для этого.

Zeek собирает огромное количество информации из первоначального согласования TLS, т.к. оно обрабатывается в открытом виде. Таким образом, хотя мы не можем видеть всё, что связано с шифрованием TLS, мы всё же можем получить общее представление о том, что происходит.

Zeek умеет выполнять снятие отпечатков TLS с помощью хэша JA3\JA3S.

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

В случае в JA3 все просто. Есть готовый инструмент, к которому можно обращаться по API для проверки выявленного хэша JA3 и принятия решения нормально это или не очень.

Хэши JA3S, соответствующие вредоносам, достать чуть сложнее. Есть, например, небольшая подборка тут, есть и еще, нужно только искать или считать самостоятельно.

С хешами JARM еще немного сложнее, если у вас нет Palo Alto, их нужно собирать по разрозненным отчетам аналитиков или считать самостоятельно и вести собственные белые и черные списки. Но на github тоже попадаются тематические подборки, например, эта. Мы ее задействуем в дальнейшем при проработке правил по JARM.

Далее приведем некоторые описания правил, которые мы реализуем у себя. Также есть неплохой доклад от Splunk с примерами алгоритмов и правил мониторинга по хэшам JA3/JA3S. Доступен здесь. Правила можно адаптировать под любую SIEM.

• Выявление признака конкретного вредоноса по хэшам JA3\JA3S. Вот, например, готовые значения для Emotet и TrickBot:

  JA3 = 4d7a28d6f2263ed61de88ca66eb011e3 (Emotet)JA3S = 80b3a14bccc8598a1f3bbe83e71f735f (C2 Server Response)JA3 = 6734f37431670b3ab4292b8f60f29984 (Trickbot)JA3S = 623de93db17d313345d7ea481e7443cf(C2 Server Response)
  

• Выявления нового хэша JA3, ранее не появляющегося в сети.

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

• Выявления хэшей JA3 не из белого списка.

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

• Выявления хэшей JA3\JA3S из чёрного списка.

Это правило нацелено на выявление хэшей заведомо вредоносного ПО.

• Выявление обращений к C&C по хэшам JARM.

При выявлении обращения к TLS-серверу, неизвестному нам или ранее не появляющемуся в логах, необходимо посчитать его JARM хэш (можно вручную, можно скриптом или с использованием SOAR), при совпадении с хэшем, соответствующим известному C&C серверу, блокируем соединение, изолируем хост и расследуем инцидент.

• Выявление JA3 хэшей, не характерных для системы.

При появлении на хостах с Windows JA3 хэшей, характерных для Linux или смартфонов (Android/IOS), стоит обратить внимание на такие хосты. Это может являться признаком работы вредоносов (ну или запущенного эмулятора/виртуалки в режиме NAT). Кейс особенно заслуживает внимание, если выявлен на рабочей станции обычного пользователя, далекого от мира IT.

• Выявление JA3 хэшей, характерных для разных браузеров одного семейства.

Сейчас достаточно сложно на один хост поставить две разные версии Firefox или Chrome (виртуальные машины в режиме NAT не в счёт). Такое выявление может свидетельствовать о том, что злоумышленники пытались адаптироваться под установленный софт, но после обновления софта не успели или забыли обновить свой Fingerprint. Хост лучше изолировать и провести расследование.

• Выявление JA3 хэшей, характерных для популярных сетевых библиотек языков программирования.

Ни для кого не секрет, что сейчас ВПО пишется не только на C/C++. Часто встречаются образцы, которые написаны на Python или Golang. Стандартные библиотеки, такие как requests (для python) или http (для Golang), имеют характерные отпечатки в рамках нескольких версий. В случае выявления такого хэша на рабочем месте разработчиков, вероятно, это нормально. Но, если хэши всплывут на рабочем компьютере рядового пользователя, то точно следует провести тщательную проверку, так как с большой вероятностью это будет свидетельством активности вредоноса. Также стоит поддерживать списки актуальных JA3 хэшей для популярных сетевых библиотек, чтобы минимизировать ложные срабатывания.

Важно: Список хэшей JARM (и JA3S тоже) необходимо регулярно пополнять новыми выявленными C&C серверами, полученную самостоятельно или от сторонних исследователей.

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

В завершении хотим подчеркнуть, что развитие и популяризация технологии TLS Fingerprinting, по нашему мнению, совсем не за горами, и способствует этому внедрение TLS 1.3.

В версиях стандарта TLS до 1.3 у клиента была возможность сообщать, к какому серверу он хочет обратиться SNI (Server Name Indication). Чаще всего в HTTPS для этого использовалось поле HOST, чтобы на одном IP и порту могли работать несколько HTTPS-сайтов. Соответственно и так, без всяких fingerprint, было видно, кто куда идет. Понятно, что речь идёт про легитимные обращения, атакующие всегда могли подделать SNI.

В стандарте TLS 1.3 появилась возможность шифровать имя запрашиваемого сайта Encrypted SNI (ESNI), и безопасники потеряли возможность видеть, куда идёт обращение.

Правда ESNI уже запретили в Китае, и были попытки блокировок в России. Однако ESNI стал часто встречаться, в том числе в инструментах злоумышленников, и без TLS fingerprinting становится сложно понимать, куда происходят обращения в сети.

Авторы статьи:

Михаил Кравченко, SOC-аналитик;

Александр Минин, руководитель направления Threat Intelligence @AAMinin;

Анна Шестакова, руководитель направления мониторинга ИБ.

С 18 по 21 мая 2021 года на киберполигоне The Standoff прошло очередное противостояние между атакующими и защитниками. Бои проходили в вымышленном городе FF, представляющем собой обширную инфраструктуру, моделирующую технологические и бизнес-процессы компаний в промышленности, энергетике, на транспорте, в финансах и других секторах.

В этот раз в кибербитве участвовали тридцать команд атакующих, жаждущих воспроизвести очередной бизнес-риск, и пять команд защитников, всячески препятствующих действиям противоположной стороны. Кроме них, на протяжении всего времени соревнований работал security operation center (SOC), состоящий из нескольких команд PT Expert Security Center и наблюдавший за всем происходящим. Одной из таких команд, участвовавших в тщательном мониторинге, был наш отдел обнаружения вредоносного ПО. С помощью песочницы PT Sandbox мы анализировали входной поток файлов на предмет наличия вредоносного кода. Вот ее возможности:

• сканирование файлов статическими правилами нашего PT ESC,

• отслеживание вредоносной активности в результате запуска образца в изолированной среде поведенческими правилами PT ESC,

• анализ сетевого трафика внутри виртуальных машин с помощью тех же правил, что используются в PT Network Attack Discovery,

• анализ дампов памяти процессов и файловых артефактов правилами PT ESC,

• сканирование файла с помощью SDK внешних антивирусных вендоров.

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

Общая статистика

Мы провели анализ событий в песочнице за период с 18 мая 10:00 до 21 мая 14:00. Согласно регламенту проведения противостояния, 18 и 19 мая с 19:00 до 10:00 следующего дня активные действия на полигоне не проводились. За время проведения кибербитвы в песочницу поступило 67142 файла на анализ, из которых в 233 случаях было обнаружено вредоносное ПО. Файлы в систему поступали следующим образом:

• из вложений писем с почтовых серверов инфраструктуры города FF;

• из сетевого трафика, перехваченные с помощью PT Network Attack Discovery;

• через ICAP, перехваченные с помощью PT Application Firewall;

• путем загрузки вручную через веб-интерфейс специалистами SOC.

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

Мы распределили задетектированные файлы по шестичасовым промежуткам времени, в которые они поступили на анализ. Вот что получилось:

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

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

В сравнении с прошлым соревнованием в этот раз не было массовых спам-рассылок, из-за чего число обнаруженных однотипных образцов могло бы быть достаточно большим. Тем не менее, тенденция не сильно изменилась. Атакующие по-прежнему отдают предпочтение использованию фреймворков Metasploit и Cobalt Strike для создания троянов-загрузчиков в качестве нагрузки первой стадии. Используются легитимные инструменты PsExec и RemCom для запуска кода на удаленных серверах. Применяются такие инструменты, как NSSM, для закрепления в системе. Мы видели распространение майнеров криптовалюты, в том числе собственного исполнения (атакующие получали дополнительные очки за майнинговую активность).

Также отметим попытки эксплуатации уязвимостей: в топ попала уязвимость CVE-2018-4993 в программе Adobe Acrobat Reader, благодаря которой атакующие могут провести атаку NTLM-relay. Впрочем, вот список полученных эксплойтов на прочие бреши, которые использовались в меньшем количестве:

• CVE-2011-1249

• CVE-2012-0217

• CVE-2016-5195

• CVE-2020-0787

А теперь давайте изучим примеры из некоторых семейств подробнее.

Cobalt Strike

В этот раз практически в каждом втором случае в качестве полезной нагрузки использовался модуль управления компьютером от пентестерского фреймворка Cobalt Strike. Рассмотрим это семейство на примере вложения к письму с именем TechnicalDocuments2.doc

SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

Судя по расширению файл представляет собой офисный документ:

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

После запуска VBA-макрос передаст на управляющий сервер имя пользователя и имя домена машины, а полученную в ответ полезную нагрузку запустит с использованием WMI:

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

Далее снова будет загружен PowerShell-скрипт, но большего размера. Он содержит бинарные данные, которые сначала декодируются из base64, а затем расшифровываются линейным XOR с ключом KUPORIS001 без кавычек и запускаются:

Расшифрованные данные вновь представляют собой скрипт PowerShell, который декодирует и расшифровывает следующие данные, передавая на них управление кода:

В начале полученных данных находится позиционно-независимый код, который в дальнейшем произведет отраженную загрузку основного бэкдора фреймворка Beacon Cobalt Strike, с управляющим сервером по адресу 104.248.40[.]15:443.

С цепочкой заражения разобрались. Теперь давайте посмотрим, как это обнаружил PT Sandbox.

На этапе статического анализа офисного документа был выявлен макрос. Кроме того, детектирован автозапуск макроса в момент открытия документа:

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

{"count": 1,"process.id": "3176","process.name": "program files\\microsoft office\\office14\\winword.exe","detect.name": "Trojan-Downloader.Win32.Generic.a","unixtime": "1621437055.497087","_rule": "Trojan_Downloader.Win32.Generic.a","s_msg": "ET INFO PowerShell DownloadString Command Common In Powershell Stagers","correlation_name": "Trojan_Downloader.Win32.Generic.a","detect.type": "malware"}

Metasploit

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

SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

Это исполняемый файл, выдающий себя за серверную часть популярного веб-приложения Apache Server:

  Verified:UnsignedLink date:12:40 03.04.2009Publisher:n/aCompany:Apache Software FoundationDescription:ApacheBench command line utilityProduct:Apache HTTP ServerProd version:2.2.14File version:2.2.14MachineType:32-bit

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

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

Чуть дальше мы видим, как происходит извлечение адреса возврата из стека, подготовка параметров и передача управления кода на извлеченный адрес:

Далее нас ждет работа с PEB исполняемого файла: поиск нужной API функции с перебором загруженных модулей (библиотек) в адресное пространство. Сравнения при поиске происходят не напрямую: от строки имени функции вычисляется простейшая хеш-сумма на базе циклического побитового сдвига. Затем происходит сравнение результата вычисления с предварительно заданным значением. Если значения совпадают нужная функция найдена, и происходит ее вызов. В данном случае будет найдена и вызвана функция выделения памяти: VirtualAlloc.

Чуть позже в полученную область памяти будет скопирован фрагмент кода, который затем получит управление кода. Это фрагмент и представляет собой промежуточный загрузчик фреймворка Metasploit, который соединится с управляющим сервером для получения полезной нагрузки.

А что с обнаружением? При статическом анализе образца был обнаружен разобранный выше стейджер фреймворка Metasploit.

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

{"count": 1,"process.id": "3176","process.name": "users\\john\\desktop\\lolkekpohek.exe","detect.name": "Backdoor.Win32.Generic.a","unixtime": "1621417537.223409","_rule": "Backdoor.Win32.Generic.a","s_msg": "SHELL [PTsecurity] Metasploit Mettle TCP session opened: AES key exchange","correlation_name": "Backdoor.Win32.Generic.a","detect.type": "malware"}

Полезная нагрузка представляет собой инструмент Mettle, это некий аналог хорошо известного бэкдора Meterpreter.

Goagent

Мы, честно говоря, обрадовались, увидев использование этого инструмента для удаленного управления компьютером вновь. Не будем повторяться, рассказывая о возможностях бэкдора, написанного на языке Go, в некоторых случаях также упакованного UPX с испорченными именами секций, об этом вы можете подробнее почитать в нашем осеннем разборе противостояния. Вместо этого расскажем о цепочке атаки, которая имела место быть в этот раз.

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

myCV (2).doc

Офисный документ содержит VBA-макрос. В результате исполнения будет запущен подпроцесс PowerShell, который загрузит и запустит исполняемый файл по ссылке. Отметим пару интересных моментов:

1. Загруженная полезная нагрузка будет размещена в каталоге планировщика задач с именем, похожим на легитимный процесс в системе svchost.exe (атакующие убрали букву c в имени файла).

2. Имя домена управляющего сервера позволяет провести атрибуцию образца с одной из команд участниц соревнования.

   Рисунок 25. VBA-макрос в офисном документе с ссылкой на полезную нагрузку, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0

Что касается обнаружения в PT Sandbox: при статическом анализе вновь обнаруживается вредоносный код в макросе офисного документа:

{"count": 1,"process.id": "1848","process.name": "windows\\tasks\\svhost.exe","detect.name": "Trojan-Downloader.Win32.Generic.a","unixtime": "1621546131.952323","_rule": "Trojan_Downloader.Win32.Generic.a","s_msg": "REMOTE [PTsecurity] Goagent","correlation_name": "Trojan_Downloader.Win32.Generic.a","detect.type": "malware"}

А что еще?

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

beRoot.pdf

SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

19 мая в 11:43 в сетевом трафике был перехвачен файл с расширением .pdf. На самом деле это исполняемый PE-файл. В результате запуска в песочнице было обнаружено обобщенное вредоносное поведение.

Впрочем, фрагменты видеозаписи могут служить подсказкой для дальнейшего анализа:

Чуть более глубокий анализ подсказал, что образец представляет собой скомпилированную программу на языке Python с применением утилиты PyInstaller. А сама программа инструмент BeRoot, позволяющий искать недочеты в системе для подсказки, каким образом можно повысить привилегии пользователя. Впрочем, название инструмента уже содержалось в имени перехваченного образца.

Password Changing Procedure.docx

SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5

Поиск в интернете по фрагментам строк приводит к проекту unicorn (не путать с известным эмулятором бинарного кода), который предназначен для внедрения шеллкода с использованием PowerShell: в частности, промежуточного загрузчика фреймворков Cobalt Strike и Metasploit, рассмотренных ранее.

winPEASx64.exe

SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9db

Это утилита WinPEAS инструмент ищет в системе векторы для локального повышения привилегий пользователя в системе. В некотором смысле схож с ранее рассмотренным BeRoot.

SharpHound.exe

SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

/dirty

SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83f

Если есть разведка и поиск способов повысить привилегии должны быть инструменты, позволяющие этим воспользоваться. 20 мая в 13:06 в сетевом трафике перехвачен исполняемый файл под платформу Linux, который представляет собой эксплойт для уязвимости CVE-2016-5195 в ядре Linux, известной также как Dirty COW.

CVE-2018-8120.exe

SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53c

Еще один эксплойт, полученный из сетевого трафика 21 мая в 11:34. Несложно догадаться и по его названию, что это повышение привилегий в системе Windows с использованием уязвимости CVE-2018-8120 в графической подсистеме.

BitsArbitraryFileMoveExploit.exe

SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610

И напоследок пример еще одного обнаруженного эксплойта. 21 мая в 11:26 все так же, из сетевого трафика, извлечен исполняемый файл, использующий на этот раз уязвимость CVE-2020-0787 в сервисе Windows Background Intelligent Transfer Service (BITS).

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

Заключение

В качестве итога приведем диаграмму, которая отражает статистику распределения детектов при использовании нескольких технологий защиты.

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

Автор: Алексей Вишняков, руководитель отдела обнаружения вредоносного ПО компании Positive Technologies