MacSync под микроскопом: новые способы доставки и полезная нагрузка

MacSync — это относительно молодое, активно развивающееся семейство крипто-/инфо-стилеров. Реклама первых версий под именем Mac.c появилась в даркнете в 2025 году, позже злоумышленники переименовали его в MacSync. Первые версии были реализованы в виде скриптов AppleScript и во многом похожи на семейство стилеров AMOS, однако со временем MacSync обрел свои отличительные черты, в том числе модуль бэкдора. В этом отчете мы расскажем о новой, претерпевшей большие изменения по сравнению с предыдущими модификациями цепочке заражения, впервые обнаруженной нами в дикой природе в сентябре 2026 года.

Ключевые моменты:

• авторы семейства пересмотрели свой подход к доставке вредоносной нагрузки, заменив скриптовые дропперы на бинарные;
• основная вредоносная нагрузка теперь состоит из модулей на Objective-C и Swift;
• на одном из этапов заражения злоумышленники используют инфраструктуру iCloud для доставки следующего этапа.

Решения «Лаборатории Касперского» детектируют описанные ниже угрозы со следующими вердиктами.

• HEUR:Trojan.OSX.MacSync.*
• HEUR:Trojan-PSW.OSX.MacSync.*
• HEUR:Trojan-Dropper.OSX.MacSync.*
• HEUR:Trojan-Downloader.OSX.MacSync.*

Технические детали

Цепочка заражения

MacSync — это инфостилер, распространяющийся по модели MaaS (Malware-as-a-Service), поэтому конкретный способ доставки первого этапа цепочки заражения ложится на плечи операторов. Последние публичные отчеты о MacSync в основном акцентировали внимание на модулях, доставляемых посредством социальной инженерии и атак типа ClickFix, однако и тогда, и до сих пор зловред распространяется в том числе под видом бесплатных или взломанных версий известных приложений, а также под видом нового ПО. Например, мы обнаружили MacSync, распространяющийся под видом несуществующего криптокошелька Toria, причем злоумышленники не только создали для него отдельную веб-страницу, но и продвигали ее через соцсеть X и мессенджер Telegram:

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

Стоит сразу отметить, что почти на всех этапах MacSync демонстрирует общие черты:

• все временные файлы размещаются в директории /tmp. В ней же создаются файлы *.lock, призванные защитить от повторного выполнения вредоносной нагрузки;
• после выполнения своей задачи модуль уничтожает следы: временные файлы, свои логи и т. д.;
• все бинарные файлы представлены в формате Fat Mach-O и нацелены на устройства под управлением процессоров как Apple, так и Intel.

Загрузчик, календарь и два дроппера

В рамках этой цепочки заражения вредоносная нагрузка в образе диска представляет собой .APP-приложение. При запуске оно первым делом проверяет наличие у всего бандла расширенного атрибута карантина com.apple.quarantine, и, если обнаруживает его, выполняет команду xattr -cr <app_name> для удаления всех атрибутов. Далее он извлекает из своего оверлея зашифрованный по алгоритму XOR URL и расшифровывает его при помощи ключа 73 6f 6e 6f 6d 61 62 6c 64 07. После зашифрованных данных расположены 8 байт, обозначающие длину шифртекста, а затем магическое слово SONOMAC1. Стоит отметить, что зловред читает оверлей задом наперед: сначала находит магическое слово, затем считывает размер данных, а затем по размеру определяет границы блока данных, содержащего шифртекст.

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

Содержимое загружаемого календаря

Получив файл календаря с сервера, загрузчик создает анонимный канал, запускает интерпретатор в режиме чтения команд из стандартного потока ввода (zsh -s), указывает в качестве стандартного потока ввода созданный канал и перенаправляет в него построчно содержимое календаря. Поскольку календарь в норме не является командой, интерпретатор будет воспринимать строки как невалидные команды до тех пор, пока не дойдет до вредоносной нагрузки после строчки DESCRIPTION:. Это команды, которые в итоге приведут к загрузке с iCloud архива в формате tar.gz, содержащего .APP-бандл. Загрузчик удаляет у него атрибут карантина, подписывает локальной подписью и выполняет.

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

Загруженное приложение является дроппером. Вредоносная нагрузка, которую он извлекает, представляет собой сжатый алгоритмом zlib исполняемый файл, зашифрованный AES в режиме CBC со следующими ключом и вектором инициализации.

Дроппер расшифровывает его, разархивирует и помещает по пути /tmp/.sys-<16-digit random value>.

Внутри — еще один дроппер, однако в отличие от предыдущих этапов он содержит защиту от отладки. В частности, он проверяет, не запущен ли он на виртуальной машине, путем выполнения запросов sysctl с параметрами kern.hv_vmm_present и machdep.cpu.brand_string, а также выставляет PT_DENY_ATTACH флаг с помощью ptrace, запрещая подключение отладчика к процессу. Полезная нагрузка — шелл-скрипт, зашифрованный с помощью AES в CBC-режиме со следующими ключом и вектором инициализации.

Вредоносная нагрузка второго дроппера

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

Еще парочка скриптов

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

• Главная функция в скрипте имеет имя daemon_function.
• Загрузка украденных данных на управляющий сервер происходит посредством PUT-запросов. Данные в запросах отправляются блоками по 90 мегабайт. В предыдущих версиях размеры блоков отличались.
• Один из способов закрепления в системе — внедрение вредоносной команды в .zshrc — конфигурационный файл интерпретатора ZSH, содержащий команды, которые должны выполняться при каждом старте интерпретатора.
• URL-путь, по которому на управляющем сервере лежит исполняемый файл бэкдора, начинается с директории /loader/.

Скрипт выполняет следующие задачи:

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

Стоит отметить интересную деталь — вместо привычных алгоритмов шифрования (XOR, AES и т. д.) для доставки вредоносных модулей на этом этапе злоумышленники прибегли к иному подходу,в котором принимает участие созданная ими утилита pkgunpack, реализующая две команды: genkey и decrypt. Расшифровка вредоносной нагрузки выполняется следующим образом.

1. Зловред генерирует публичный и секретный ключи шифрования при помощи команды genkey из pkgunpack — функция генерации использует открытую реализацию протокола Диффи — Хеллмана на эллиптической кривой Curve25519 — curve25519_donna.
2. Публичный ключ кодируется в base64 и отправляется на управляющий сервер вместе с одноразовым кодом, генерируемым командой $(date +%s)-${RANDOM}-$$.
3. В ответ сервер возвращает следующий JSON.
   
   { "ok": true, "dek_wrap_b64": <base64_encoded_encrypted_key> , "build_pub_b64": "pFSxn/Uwg9bS45aVKCzA+8exSMfDHXpbpHC/f7G472w=", "crypto": "v2.5" }

   1 2 3 4 5 6

   {     "ok": true,     "dek_wrap_b64":  <base64_encoded_encrypted_key> ,     "build_pub_b64": "pFSxn/Uwg9bS45aVKCzA+8exSMfDHXpbpHC/f7G472w=",     "crypto": "v2.5" }

   
   Здесь build_pub_b64 — публичный ключ сервера, который также заранее задан в самом скрипте, а dek_wrap_b64 — это закодированная в base64 строка, в которой содержится ключ шифрования полезной нагрузки. Этот ключ зашифрован на стороне сервера общим секретом, вычисленным на основе публичного ключа, полученного в результате генерации с помощью pkgunpack на устройстве жертвы.
4. Далее вызовом команды decrypt из pkgunpack происходит расшифрование ключа.
   1. На основе заранее известного публичного ключа сервера и приватного ключа для текущей сессии вычисляется общий секрет с помощью той же реализации схемы обмена ключами ECDH Curve25519, что использовалась для генерации ключей.
   2. Полученный общий секрет конкатенируется со строкой sn-dek-wrap-v1, и от результата вычисляется хэш SHA-256.
   3. Далее декодируется полученный с сервера блок dek_wrap_b64. Он имеет следующую структуру.
      1. Первые 5 байт — дополнительные имитозащищаемые данные (AAD)
      2. Следующие 12 байт — вектор инициализации (IV)
      3. Далее — шифртекст
   4. Шифртекст расшифровывается посредством AES в режиме GCM с помощью полученного ранее ключа, IV и AAD.
      

      Декодированный блок dek_wrap_b64

5. Полученный результат — ключ для расшифрования загруженной вредоносной нагрузки. Она, в свою очередь, также содержит в своем заголовке AAD и IV и зашифрована с помощью AES GCM. Утилита расшифровывает ее и завершает свою работу.

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

Как упоминалось ранее, на этом этапе скрипт загружает всего два модуля — инфостилер и бэкдор. Оба после расшифрования представляют собой архивы в формате .tar.gz, содержимое которых распаковывается, очищается от всех расширенных атрибутов (таких, как com.apple.quarantine) и подписывается локальной подписью. В первую очередь запускается модуль инфостилера — он собирает интересующие его данные, помещает их во временную папку и сжимает в архив .tar.gz, который скрипт затем отправит на сервер злоумышленников. Далее перед запуском бэкдора скрипт обеспечивает для него закрепление в системе, а также создает его резервную копию. Резервная копия вместе с остальными необходимыми для работы файлами располагается в $HOME/Library/Application Support/System. Такой директории в macOS не существует — ее создает скрипт. Бэкдор маскируется под приложение Finder и закрепляется в системе следующими способами:

• использование агента автозапуска (LaunchAgent) с именем com.apple.finder.agent;
• внедрение команды, запускающей скрипт .repair-run при запуске интерпретатора ZSH из .zshrc;
• внедрение похожей команды, тоже запускающей скрипт .repair-run, в глобальные хуки GIT pre-commit и post-checkout.

Скрипт .repair-run проверяет существование файлов бэкдора, восстанавливает их из бэкапа в случае отсутствия, заново создает и перезагружает агент автозапуска, при этом убивая системные процессы BTMNotificationAgent, NotificationCenter и BackgroundTaskManagementAgent, чтобы предотвратить уведомления от системы о добавлении нового агента автозапуска.

Последнее, что стоит отметить в работе скрипта на этом этапе, — использование кастомного HTTP-заголовка X-Upload-Token, без которого управляющий сервер будет отвечать на запросы ошибками. В рамках исследования мы видели использование следующих токенов: b8b4b88205a8f594b95a841bc37342898f34cad8a5a9e4a22ce69a31a1208650 и ff3ab9ef841630364818396f62e696b72aed162cf0b895b6643ef25dad79b51d. Эти же токены в дальнейшем применяет и бэкдор для общения с управляющим сервером.

Инфостилер

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

Поддельные всплывающие окна стилера

Интересно, что вместо характерного для большинства семейств вредоносного ПО для macOS способа проверить правильность введенного пароля — через утилиту dscl — злоумышленники воспользовались API подключаемых модулей аутентификации (PAM). Это довольно новая техника для macOS-зловредов, впервые использованная в дикой природе в июле 2026 года в семействе Pam Stealer. По всей видимости, она заинтересовала авторов вредоносного ПО, и в перспективе мы можем сталкиваться с нею чаще.

Проверка пароля с использованием PAM

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

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

Набор собираемых стилером данных немного расширился по сравнению с предыдущими версиями. Обобщенный список выглядит следующим образом:

• информация из браузеров — история, cookie-файлы, данные расширений криптокошельков, сохраненные логины и пароли, файлы Local State;
• данные приложений криптокошельков;
• данные Telegram;
• логин и пароль от устройства;
• файл связки ключей;
• информация о системе: список установленных приложений и запущенных процессов, модель устройства, железо, UUID и т. д.;
• файлы конфигурации SSH, ZSH, AWS, Kubernetes, GIT и других служб/программ;
• история команд интерпретаторов ZSH и Bash;
• аватар текущего пользователя.

Собранные данные сохраняются в скрытую директорию в /tmp/.
В модуле-стилере также есть одна интересная функция, которая во всех обнаруженных на данный момент образцах выключена и, по всей видимости, находится в разработке. Ее задача — проверить, присутствует ли в ресурсах вредоносного приложения по пути <app_path>/Contents/Resources/Helpers файл KcHelper и, если он есть, запустить его с определенными параметрами. В случае отсутствия этого файла выполняется запасная функция _kc_grab_storage_item. Так как на момент исследования KcHelper в ресурсах приложения не было, мы можем только предположить о его назначении на основе анализа этой функции. В ней сначала выполняется команда, модифицирующая partition_id у записи в связке ключей для определенного сервиса так, что доступ к ней может быть предоставлен без подтверждения от пользователя и без пароля от связки ключей трем категориям приложений:

• teamid — приложение подписано сертификатом с определенным teamID (в данном случае разработчика целевого приложения);
• apple — приложение является службой Apple;
• apple-tool — приложение является консольной утилитой Apple.

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

Участок кода, ответственный за изменение доступа к сервисам в связке ключей

Бэкдор

Бэкдор представляет собой исполняемый файл Fat Mach-O, написанный на Objective-C. У него есть два режима запуска — обычный и с флагом --persist-status. Во втором случае он только проверяет, каким образом он добавлен в объекты автозапуска — через объект входа (Login Item) или агент автозапуска (LaunchAgent). В стандартном режиме перед тем как перейти к выполнению основной функциональности, бэкдор также проверяет, закреплен ли он каким-либо способом в автозапуске. Если нет — выполняется тот же механизм закрепления, что и в родительском скрипте, однако для macOS версии старше 13.0 вне зависимости от присутствия объектов автозапуска используется отдельный исполняемый файл-помощник, хранящийся в теле бэкдора. Этот помощник выполняет одну-единственную задачу — используя API CoreServices.framework, добавляет переданный ему в аргументах исполняемый файл в объекты входа.

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

• AGNT1 — магическая константа, подтверждающая, что конфигурация расшифрована корректно;
• URL управляющего сервера;
• токен доступа — такой же, как и в родительском скрипте;
• BLD-150 — номер сборки бэкдора.

Зловред также пишет логи по пути $HOME/Library/Logs/.sysnotif-agent.log и поддерживает расширенные логи при запуске с переменной окружения LAUNCHER_DEBUG. Общение с C2 происходит посредством протокола HTTP. В ответ от сервера должен прийти JSON. Ниже представлена таблица запросов к управляющему серверу и их описание:

Несмотря на то что в бэкдоре представлено несколько разных команд, их суть сводится к одному действию — извлечь из поля script_b64 в ответе сервера закодированный в base64 скрипт AppleScript и выполнить его. Отдельные обработчики команд в этом случае выполняют роль оберток над скриптами, правильно заполняющих телеметрию и выполняющих запросы к управляющему серверу. Судя по названиям команд и сообщениям, отправляемым на сервер в рамках их выполнения, мы можем восстановить их смысл, не имея на руках непосредственно скриптов. Бэкдор поддерживает следующие команды.

• deploy_ext — внедрить в браузер пользователя расширение, загруженное с сервера.
• deploy_ledger — заменить установленный кошелек Ledger на версию с сервера.
• regrab — заново собрать информацию о системе и/или конкретные файлы. В этот раз собранные данные складываются в характерный для семейства MacSync архив по пути /tmp/osalogging.zip, если иной путь не указан в поле archive_path, пришедшем вместе с командой.
• live_browser — это единственная команда, выполняемая без участия скриптов AppleScript. Бэкдор проверяет наличие файла sn_relay в своих ресурсах, при его отсутствии загружает и выполняет. Его содержимое и назначение остаются для нас загадкой, однако, судя по названию команды и сообщениям, отправляемым на сервер, мы можем предположить, что каким-то образом злоумышленники реализуют MitM-атаку на трафик, исходящий от браузера жертвы.

Участок команды regrab, где перед отправкой архива проверяется его целостность и вычисляется хэш-сумма

Заключение

Новая версия инфостилера MacSync достаточно сильно отличается от его ранее встречавшихся модификаций. Злоумышленники серьезно пересмотрели свой подход к выполнению основной вредоносной нагрузки стилера и бэкдора и перешли от скриптов AppleScript к полноценным исполняемым файлам, написанным на Swift и Objective-C. Также стоит отметить и усложнившуюся цепочку заражения, где вместо обфусцированных шелл-скриптов, доставляемых через атаки типа ClickFix, в этой версии использовались бинарные дропперы и загрузчики, в том числе использовавшие инфраструктуру Apple как один из промежуточных этапов доставки вредоносной нагрузки.

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

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

Загрузчик первого этапа
26a0f7cdb9f7dc5ace9a40af825b1538
2d69812584269699fade26622e6490c5
7df1049cbd56c0bfa4a3364a379b4c2c
9f15fe9c4415cd668334339f705b94d8
fb90887592655a8c989e443c640167aa
6791dad263cac6d63ebba6a4b57e7d71

Вредоносный календарь (второй этап)
3ded1d71a822b53b12c3b67bcaf633f5

Дроппер третьего этапа
781ce50001d4b449600afa347c9b0208
8e84b01d5ac9624f0b181ade0e737193
980e2134679bc0c609f7659882883d77
4203ec932bfcc0907f91732440d6d997
eb760d5c88f13f7ee0f8f86ba3407123
f9f70096aabb4d22a6657014f4853a53

Дроппер четвертого этапа
3deeed48fd38f22e369f5c3092bd68a1

Скрипт пятого этапа
f97d24212fa6a21be0c4d211e10f044c

Скрипт шестого этапа
00d12d842596bf5ee1805effb4571d30
9a0043d900a9ac78c886c59c9a328fd0

Вспомогательный скрипт .repair-run
7212229c85852c3bffaf9740002b2f39

Инфостилер
c53d0ea45dbc622afb7f16ea3eec78bc

Бэкдор
fc3ba5ed282d77127efd0b0f2403531b

Вспомогательный инструмент автозагрузки
8dc8561349d144d4661bc66f2ec49f9f

URL

hxxps://toria[.]app/
hxxps://warpcast[.]asia/Toria.dmg
hxxps://streamyard.appstore.com[.]mx/installer.sh
hxxps://slack.apple03cloudstore[.]com/installer.sh
hxxps://toria.apple03cloudstore[.]com/
hxxps://waaako.appstore.com[.]mx/installer.sh
hxxps://toria.apple03cloudstore[.]com/e3c1a6b00bc31e14/stage2.enc hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/stage2.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/CoreUpdate.pkg.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/Helper.pkg.enc
hxxps://caldav.icloud[.]com/published/2/MTk1NDMwMDMzNTUxOTU0M1aHCZ-nMxiyGzBTzPiodOf44DtKJ6PpjftAG28_ui2NCYMpL_vu4pF4ddsJ8ysg0QI7pR0VEIEbZYdilVZRw08
hxxps://gateway.icloud[.]com/caldav/1_MTk1NDMwMDMzNTUxOTU0M0pybtJB186GzhogprwCQUjY3oZNiDFHH8WVo6bmgUtI/attach/4GE4TKNBTGAYDGMZVGUYTSNJUGOAALDAFMDOJBGWNUCYJLZRNDCLCO2YMQ3I64RLGMNXVG3KYBPWQOGYIEI7MPBDDYHECFDYVENTXIYFNDCPOVRMCTYI236RCYZAE63V5U3RTUYGUMO2CO7PKCLWMCXE73M7OPTHSGRWH5DXQ4PCUQU4ELZTLW54JSTK2H7VQ6PD26WOA2R7PPIQ6RTJWDEWP34U3HB4YWMXXC6EJ6PKWILSPYRSDEVY6QGMWSIUN6PR5W35KO3D4QZE7CFPUVBAEKI/Loader.app.tar.gz/YXR0YWNoYXR0YWNoYXR0YRhrE8mQ0E-b_dTUSGStQgTQ0ULFxCanei3Ke-EuEyQL

C2
hxxps://docsend.appstore[.]com[.]mx
hxxps://toria.apple03cloudstore[.]com