В начале марта 2019 года новый образец вредоносного ПО для macOS от группы OceanLotus был загружен на VirusTotal, популярный онлайн-сервис мультисканирования. Этот исполняемый файл типа backdoor обладает теми же функциями, что и предыдущий вариант для macOS, который мы рассматривали, но его структура изменилась, и его стало труднее обнаружить. К сожалению, мы не смогли найти дроппер, связанный с этим образцом, поэтому нам неизвестен вектор первоначального заражения.

Мы недавно опубликовали подробное обновление об OceanLotus и о том, как его операторы используют широкий спектр методов для выполнения кода, обеспечения постоянства и минимизации следов на системе Windows. OceanLotus также известен своим вредоносным компонентом для macOS. Эта статья подробно описывает изменения по сравнению с предыдущей версией для macOS, проанализированной Trend Micro, и объясняет, как при анализе кода этого варианта можно автоматизировать расшифровку строк с помощью IDA Hex-Rays API.

Анализ

В следующих трех разделах этой статьи описан анализ образца с SHA-1 хэшем E615632C9998E4D3E5ACD8851864ED09B02C77D2. Файл называется flashlightd и обнаруживается продуктами ESET как OSX/OceanLotus.D.

Антиотладка и анти-песочница

Как обычно для бинарных файлов OceanLotus для macOS, образец упакован с помощью UPX, но большинство инструментов идентификации упаковщиков не распознают его таковым, вероятно, потому, что они в основном включают сигнатуру, основанную на наличии строки «UPX», а подписи Mach-O встречаются реже и обновляются не так регулярно. Эта особенность затрудняет статическое обнаружение. После распаковки интересно то, что точка входа находится в начале секции __cfstring в сегменте .TEXT. Эта секция имеет атрибуты флагов, показанные на Рисунке 1.

Рисунок 1. Атрибуты секции MACH-O __cfstring

Как видно на Рисунке 2, тот факт, что код находится в секции __cfstring, обманывает некоторые инструменты дизассемблирования, заставляя их отображать код как строки.

Рисунок 2. Код бэкдора определяется IDA как данные

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

• пытается отсоединить любой отладчик, вызывая ptrace с параметром запроса PT_DENY_ATTACH
• проверяет, открыты ли некоторые порты исключений, вызывая функцию task_get_exception_ports
• проверяет, присоединен ли отладчик, как показано на Рисунке 3, проверяя, установлен ли флаг P_TRACED в текущем процессе

Рисунок 3. Проверка подключения отладчика через функцию sysctl

Если сторожевой таймер обнаружит наличие отладчика, вызывается функция exit . Кроме того, образец затем проверяет свою среду, выполняя следующие две команды:
ioreg -l | grep -e «Manufacturer» и sysctl hw.model
и сравнивает возвращаемое значение с жестко закодированным списком строк известных систем виртуализации: oracle, vmware, virtualbox или parallels. Наконец, команда:
system_profiler SPHardwareDataType 2>/dev/null | awk ‘/Boot ROM Version/ {split($0, line, «:»);printf(«%s», line[2]);}
проверяет, является ли машина одной из следующих: «MBP», «MBA», «MB», «MM», «IM», «MP» и «XS». Эти коды представляют собой модель системы. Например, «MBP» означает MacBook Pro, «MBA» — MacBook Air и так далее…

Основные обновления

Несмотря на то, что команды бэкдора не изменились с момента статьи Trend Micro, мы заметили несколько других модификаций. C&C серверы, используемые для этого образца, довольно новые, так как дата их создания — 2018-10-22.

• daff.faybilodeau[.]com
• sarc.onteagleroad[.]com
• au.charlineopkesston[.]com

Используемый ресурс URL изменен на /dp/B074WC4NHW/ref=gbps_img_m-9_62c3_750e6b35.

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

Помимо этого изменения конфигурации, данный образец не использует библиотеку libcurl для сетевой эксфильтрации. Вместо этого он использует внешнюю библиотеку. Чтобы найти ее, бэкдор пытается расшифровать каждый файл в текущем каталоге с помощью AES-256-CBC с ключом gFjMXBgyXWULmVVVzyxy , дополненным нулями. Каждый файл «расшифровывается» и сохраняется как /tmp/store , и предпринимается попытка загрузить его как библиотеку с помощью функции dlopen. Когда попытка расшифровки приводит к успешному вызову dlopen, бэкдор извлекает экспортированные функции Boriry и ChadylonV, которые, по-видимому, отвечают за сетевое взаимодействие с сервером. Поскольку у нас нет дроппера или других файлов из расположения исходного образца, мы не смогли проанализировать эту библиотеку. Кроме того, поскольку компонент зашифрован, правило YARA, основанное на этих строках, не будет соответствовать файлу, найденному на диске.

Как описано в анализе предыдущего бэкдора группы для macOS, создается clientID. Этот идентификатор представляет собой MD5-хэш возвращаемого значения одной из следующих команд:

• ioreg -rd1 -c IOPlatformExpertDevice | awk ‘/IOPlatformSerialNumber/ { split($0, line, «»»); printf(«%s», line[4]); }’
• ioreg -rd1 -c IOPlatformExpertDevice | awk ‘/IOPlatformUUID/ { split($0, line, «»»); printf(«%s», line[4]); }’
• ifconfig en0 | awk ‘/ether /{print $2}’ (получение MAC-адреса)
• неизвестная команда («x1ex72x0a«), которая ранее была «uuidgen» в предыдущих образцах

Перед хэшированием к возвращаемому значению добавляется символ «0» или «1», указывающий на привилегии root. Этот clientID хранится в /Library/Storage/File System/HFS/25cf5d02-e50b-4288-870a-528d56c3cf6e/pivtoken.appex, если код выполняется как root, или в ~/Library/SmartCardsServices/Technology/PlugIns/drivers/snippets.ecgML в противном случае. Этот файл обычно скрывается с помощью функции _chflags, а его временная метка изменяется с помощью команды «touch –t» со случайным значением.

Расшифровка строк

Как и в предыдущих вариантах, строки зашифрованы с использованием AES-256-CBC (шестнадцатеричный ключ: 9D7274AD7BCEF0DED29BDBB428C251DF8B350B92, дополненный нулями, а IV заполнен нулями) с использованием функции CCCrypt
. Ключ изменился по сравнению с предыдущими версиями, но поскольку группа по-прежнему использует тот же алгоритм для шифрования строк, расшифровка может быть автоматизирована. Вместе с этой статьей мы выпускаем скрипт IDA, использующий Hex-Rays API для расшифровки строк, присутствующих в бинарном файле. Этот скрипт может помочь в будущем анализе OceanLotus и в анализе существующих образцов, которые мы еще не смогли получить. В основе этого скрипта лежит общий метод получения аргументов, передаваемых функции. Кроме того, он ищет присвоения параметров, чтобы найти их значения. Этот метод может быть повторно использован для получения списка аргументов функции и последующей передачи их в callback.

Зная прототип функции decrypt, скрипт сначала находит все перекрестные ссылки на эту функцию, затем находит все аргументы, расшифровывает данные и помещает открытый текст в комментарий по адресу перекрестной ссылки. Чтобы скрипт работал корректно, пользовательский алфавит, используемый функцией декодирования base64, должен быть установлен в скрипте, а глобальная переменная, содержащая длину ключа, должна быть определена (в данном случае как DWORD; см. Рисунок 4).

Рисунок 4. Определение глобальной переменной key_len

В окне Function вы можете щелкнуть правой кнопкой мыши по функции расшифровки и выбрать «Extract and decrypt arguments». Скрипт должен поместить расшифрованные строки в комментарии, как показано на Рисунке 5.

Рисунок 5. Расшифрованный текст помещается в комментарии

Это удобно перечисляет расшифрованные строки вместе в окне xrefs to IDA для этой функции, как показано на Рисунке 6.

Рисунок 6. Xrefs к функции f_decrypt

Финальный скрипт можно найти в нашем репозитории Github.

Заключение

Как недавно было задокументировано в другой из наших статей, группа OceanLotus продолжает совершенствовать и обновлять свой набор инструментов, и в очередной раз она улучшила свои инструменты для атак на пользователей Mac. Код не сильно изменился, но поскольку многие пользователи Mac не используют защитное ПО на своих машинах, необходимость обходить обнаружение менее важна. Продукты ESET уже обнаружили этот файл, когда мы его нашли. Поскольку сетевая библиотека, используемая для связи C&C, теперь зашифрована на диске, точный используемый сетевой протокол остается неизвестным.

Индикаторы компрометации (IoCs)

IoCs в этой статье, а также атрибуты MITRE ATT&CK доступны в нашем репозитории GitHub.

Доменные имена

• daff.faybilodeau[.]com
• sarc.onteagleroad[.]com
• au.charlineopkesston[.]com

Ресурс URL

• /dp/B074WC4NHW/ref=gbps_img_m-9_62c3_750e6b35

Пути к файлам

• ~/Library/SmartCardsServices/Technology/PlugIns/drivers/snippets.ecgML
• /Library/Storage/File System/HFS/25cf5d02-e50b-4288-870a-528d56c3cf6e/pivtoken.appex
• /tmp/store

Техники MITRE ATT&CK

Читать полный анализ на WeLiveSecurity →