Шкідливе програмне забезпечення CloudSyncD для macOS приховує фішингові облікові дані за допомогою нульової ширини Юнікоду

Резюме

CloudSyncD — це двоетапна бекдор-програма для macOS, яка розповсюджується через фальшивий інсталятор Zoom у вигляді образу диска. Перший етап краде облікові дані користувача через фальшивий запит авторизації та приховує перехоплений пароль у файлі конфігурації-приманки, використовуючи символи нульової ширини Unicode. Другий етап розгортає вбудований додаток Mach-O, який встановлює командно-контрольний зв’язок для віддаленого виконання завдань.

Дослідження

Jamf Threat Labs виявила це шкідливе ПЗ під час рутинного моніторингу виконуваних файлів, надісланих до VirusTotal. Дослідники простежили його еволюцію від ранньої стадії розробки до активного розгортання, спостерігаючи перехід від локальної перевірки облікових даних за допомогою dscl до спілкування з реальною C2 інфраструктурою. Аналітики також розкрили метод приховування паролів і відновили конфігурацію та протоколи зв’язку C2.

Пом’якшення наслідків

Користувачам слід уникати виконання ручних інструкцій, які вимагають обійти захист Gatekeeper при встановленні несподіваних додатків. Організації можуть використовувати Jamf для Mac, щоб увімкнути захист від загроз, розширені засоби контролю загроз і захист веб-сайтів для виявлення та блокування зловмисної активності. Увімкнення Захисту Цілісності Системи (SIP) також може запобігти певним технікам безфайлового виконання, які використовуються дроппером.

Відповідь

Коли виявлено активність CloudSyncD, ізолюйте уражений macOS хост, щоб зупинити подальше спілкування з C2. Дослідіть підозрілі файли у ~/.config/zoom/, ~/.local/share/cloudsync/ і тимчасовому каталозі системи. Перезавантажте облікові дані всіх облікових записів користувачів, які взаємодіяли з фальшивим запитом авторизації, оскільки їхні паролі могли бути викриті зловмисникам.

## Виконання симуляції

• Опис атаки та команди: Атакувальник постачає шкідливий інсталятор macOS, замаскований під Zoom, через фішинговий лист. Після того, як користувач виконує інсталятор (виконання користувача), дроппер (перший етап) намагається запустити другий етап зловмисного ПЗ. Під час цього процесу виникає специфічна помилка у командній строці: /dev/fd spawn не вдалося rc=13. Альтернативно, дроппер успішно запускає компонент під назвою cshelper. Симуляція виконає два різні сценарії: один, націлений на командні стрічки, і один, націлений на конкретне ім’я процесу, щоб забезпечити повне охоплення логіки правила.

• Сценарій регресійного тестування:

  #!/bin/bash
  # Скрипт симуляції CloudSyncD
  
  echo "[*] Початок симуляції CloudSyncD..."
  
  # Сценарій 1: Тригеринг через Вибір 1 і Вибір 2 (Помилка дроппера)
  echo "[*] Симуляція етапу 1 дроппера зі специфічним рядком помилки..."
  # Ми використовуємо 'logger' або хибний виконання, щоб симулювати телеметрію командного рядка, якщо не можемо фактично викликати збій файлового дескриптора
  # У реальному EDR-тесті ми виконуємо процес, який має цей рядок у своїх аргументах
  /usr/bin/echo "the app_installer dropper /dev/fd spawn failed rc=13" &
  
  sleep 2
  
  # Сценарій 2: Тригеринг через Вибір 3 (Процес cshelper)
  echo "[*] Симуляція виконання процесу 'cshelper' етапу 2..."
  # Створюємо фіктивний файл, щоб представити шкідливий бінарний файл
  touch /tmp/cshelper
  chmod +x /tmp/cshelper
  /tmp/cshelper &
  
  echo "[*] Команди симуляції відправлені."

• Команди очищення:

  #!/bin/bash
  # Скрипт очищення
  echo "[*] Очищення артефактів симуляції..."
  rm -f /tmp/cshelper
  echo "[*] Очищення завершене."