Отчет по анализу ClayRat

Исследование файла

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

Исследование в системе ATHENA

1. Статическое исследование

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

Во вкладке «Индикаторы» отработало одно Yara-правило и несколько статических индикаторов.

Во вкладке «Источники вердикта» строится графическая карта с источниками и их вердиктами, а также общим вердиктом по исследуемому файлу.

2. Динамическое исследование

Динамический анализ проводился в изолированной среде, созданной в системе ATHENA, на основе виртуальной машины, с OC Android 12.

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

• Управление монтированием
• Захват изображения экрана через jni
• Работа с устройствами через jni-интерфейс
• Сканирование выполняющихся процессов
• ET INFO HTTP Request to a *.top domain

C процессами, которые отработали во время исследования, можно ознакомиться во вкладке «Карта исследования» или во вкладке «Процессы».

В блоке «Ход исследования», можно наблюдать, изменения в файловой системы, наличие сетевого трафика, а также создание дампов с различными расширениями.

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

Во вкладке техники MITRE отработали следующие техники:

• SCREEN CAPTURE (MOBILE) - Сработавшие индикаторы: Захват изображения экрана через jni. ПО может производить захват изображения экрана с устройства (через MediaProjection или нативные методы/фреймбуфер)
• NATIVE API (MOBILE) - Сработавшие индикаторы: Работа с устройствами через jni-интерфейс. ПО использует JNI/нативные API для управления устройствами, вызова системных функций и доступа к низкоуровневым ресурсам.
• PROCESS DISCOVERY (MOBILE) - Сработавшие индикаторы: Сканирование выполняющихся процессов. ПО осуществляет сбор списка и свойств выполняющихся процессов (через /proc, ps или API) для разведки окружения.
• System Information Discovery (Mobile) - Сработавшие индикаторы: Сбор информации об ОС Android. ПО производит сбор сведений об ОС и аппаратной конфигурации (Build, getprop, версии, патчи, архитектура)

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

В разделе «Сетевой трафик» отображаются все подключения в интернет, зафиксированные во время динамического исследования файла. Если строки подсвечены оранжевым или красным, значит IP-адрес, к которому было подключение, с высокой вероятностью находится в блок-листе.

В разделе «Источники вердикта» представлена информация о том, какие источники классифицировали файл как подозрительный.

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

3. Детальное исследование файла

Во время динамического анализа наблюдались повторяющиеся HTTP-POST запросы от тестовой машины, которые были помечены как подозрительные в нашей системе. Поэтому начнем с анализа .pcap дампа.

После применения фильтров и просмотра HTTP-потока обнаружилось следующее:

• Клиент (Android-эмулятор, видимый по User-Agent) отправляет периодические POST-запросы на путь /newclient?id=<UUID>. Запросы повторяются с фиксированными интервалами и имеют большие Content-Length.
• Заголовок Content-Type: application/octet-stream указывает, что полезная нагрузка — бинарные данные, но в дампе тело передано как ASCII-текст.
• Тело POST — это длинная ASCII-последовательность, по структуре напоминающая base64 (латинские буквы, цифры, +, /, возможно знаки = в конце). Однако в тексте явно присутствует повторяющаяся вставка-маркер apezdolskynet через регулярные интервалы.

На стороне сервера чаще всего приходил HTTP-ответ HTTP/1.1 404 Not Found с HTML, то есть сервер либо не предназначен для приёма этих данных, либо endpoint временно недоступен. Несмотря на 404, клиент продолжает отсылать данные — поведение типично для агентов, которые «стучат» в C2 по расписанию и не зависят от успешного ответа.

Повторяющаяся вставка apezdolskynet выглядит как обфускатор, вставляемый в поток с целью «сломать» простые детекторы и мешать автоматическому парсингу base64. Это не шифрование, а именно вставка маркера.

Формат тела (base64-подобный) говорит о том, что реальная полезная нагрузка была заранее кодирована в base64 и затем отправлена в текстовом виде. Такое кодирование удобно для передачи бинарных данных в HTTP без явной chunked- или бинарной передачи.

Поведение с 404 может указывать на тестовый сервер, на переключение C2 или на то, что это зеркальный/резервный endpoint.

Предварительный статический анализ

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

1. Идентификация и базовые метаданные

Результат file подтвердил, что образец имеет формат Android application package (APK). Это указывает на то, что ранее наблюдавшаяся HTTP-активность (POST /newclient?id=...) исходила от мобильного компонента.

2. Просмотр читаемых строк

Итого были извлечены текстовые строки длиной от 6 символов. Результаты показали наличие множества системных ресурсов Android (Base.Widget.*), однако следов http, apezdolskynet или Base64-строк в открытом виде найдено не было. Это может указывать на то, что содержимое .dex-файлов упаковано или обфусцировано, а строки шифруются и расшифровываются во время исполнения.

3. Проверка на упаковку и структуру контейнера

Вывод показал наличие строки ?uPX, что свидетельствует о присутствии сигнатуры UPX или похожего упаковщика, а также стандартные разделы ZIP-архива (AndroidManifest.xml, resources.arsc, res/*).

Попытка декомпиляции через apktool завершилась ошибкой. Это типичный признак повреждения ZIP-структуры вследствие модификации упаковщиком: некоторые сегменты APK могут быть перепакованы нестандартным алгоритмом или зашифрованы.

Таким образом, апк-файл оказался частично упакован — распаковывается только статическая часть (ресурсы, иконки), а основной код (classes.dex) скрыт под обёрткой или шифрованием.

Глубокая декомпиляция и анализ приложения в MobSF

После предварительного анализа артефакт был загружен в Mobile Security Framework (MobSF) для статической декомпиляции и оценки структуры, API-вызовов и поведения. Несмотря на признаки упаковки, MobSF успешно реконструировал основной .dex и позволил провести детальный обзор активности приложения.

Первое на что стоит обратить внимание, это то, что приложение скорее всего подписано самописным сертификатом, сроком действия до 2030 года.

Далее рассмотрим AndroidManifest.xml

Манифест содержит более 25 разрешений, включая критически опасные:

• READ_SMS, SEND_SMS, WRITE_SMS, RECEIVE_SMS — полный контроль над SMS
• READ_PHONE_STATE, READ_PHONE_NUMBERS, CALL_PHONE — доступ к информации о SIM и возможность совершать звонки
• CAMERA, READ_CONTACTS, WRITE_CONTACTS — доступ к персональным данным и камере
• RECEIVE_BOOT_COMPLETED — автозапуск при включении устройства (персистентность)
• INTERNET, ACCESS_NETWORK_STATE — сетевое взаимодействие
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS — предотвращение выгрузки из памяти

Помимо этого, манифест указывает на использование компонента WebSocketForegroundService — именно он отвечает за установку постоянного соединения с сервером управления.

Также в манифесте имеется ключ - usesCleartextTraffic=true, который означает что HTTP-трафик передаётся в открытом виде (без шифрования).

Анализ APKID показал наличие Anti-VM-проверок (Build.FINGERPRINT, Build.MANUFACTURER) — приложение определяет эмулятор и прекращает активность при обнаружении виртуальной среды. Это объясняет сложности при запуске динамического анализа.

Анализ кода и API-вызовов

На этапе декомпиляции MobSF выявил обширное использование API для обработки Base64-строк, динамической загрузки классов, работы с сетью и доступом к SMS-функционалу. Это позволило локализовать ключевые участки логики, отвечающие за обфускацию и обмен данными с сервером управления.

Обнаруженные вызовы Base64 Encode / Decode

Операции кодирования и декодирования Base64 встречаются в нескольких классах. Это указывает, что Base64-обработка встроена в ядро логики приложения, а не используется точечно. Декомпилированный код показывает две характерные функции:

Функции реализуют обратимую обфускацию строк, при которой данные:

• кодируются в Base64
• инвертируются (reverse)
• каждые пять символов вставляется маркер apezdolskynet

При декодировании процесс выполняется в обратном порядке — строка очищается от маркера и разворачивается обратно.

Такой приём предназначен для скрытия конфигурации, команд и параметров соединения при статическом анализе и делает код читаемым только в runtime.

Итог исследования

Образец — Android APK, явно вредоносный клиент C2 (клиентская часть инфраструктуры).

Статические признаки:

• В коде обнаружен специфичный маркер и схема обфускации: строка-маркер apezdolskynet. Полезная нагрузка кодируется в Base64, затем разворачивается и каждые 5 символов вставляется маркер. При декодировании последовательность удаляется и строка reverse() → Base64.decode
• Набор ключевых классов/функций: org/core/engine924/websocket/WebSocketForegroundService, skynet (локальная БД sms_storage.db), dispatcher pegasus, обработчики wyvern, ifrit. Методы: сбор SMS, отправка POST с obf-пэйлоадом, приём команд
• Манифест содержит много опасных разрешений (READ_SMS, SEND_SMS, RECEIVE_BOOT_COMPLETED, CAMERA, READ_PHONE_STATE, INTERNET и т. п.) и usesCleartextTraffic=true — значит трафик может идти в открытом виде

Динамика/сеть:

• В pcap видны множественные POST к /newclient?id=... на домен allan.clayrat.top, IP 64.188.79.217. Maltrail отмечает домен как malicious
• Трафик содержит тело, похожее на base64-подобную обфускацию с маркером apezdolskynet

Поведение:

• Постоянный foreground/background сервис с WakeLock и AlarmManager — устойчивость и автозапуск
• Сбор конфиденциальных данных (SMS, список приложений, device info, камера) и отправка на C2; получение и исполнение команд от C2

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