Исследователи Group-IB обнаружили инфостилер для macOS с необычной механикой — вместо того чтобы красть пароль тайно, он принуждает жертву ввести его добровольно. Малварь получила имя ClickLock. Если человек отказывается вводить пароль в первом появившемся диалоговом окне, система начинает буквально разваливаться: приложения закрываются одно за другим, и это продолжается часами, пока пользователь не сдастся.
Заражение начинается со схемы ClickFix — метода, при котором жертву убеждают вставить команду в Терминал. Group-IB оценивает связь ClickLock с ClickFix с высокой степенью уверенности, но подчёркивает: именно такое применение техники аналитики видят впервые. Скрипт при запуске берёт первым аргументом некий RAY_ID и показывает поддельный баннер Cloudflare CAPTCHA поверх прогресс-бара, который прокручивает 12 статусных строк за 10 секунд. Всё это чистая театральность — ни одна из этих строк ничего не делает, задача одна: успокоить человека, который только что вставил чужой код в командную строку.
Дальше в дело вступает . Он отключает прерывания с клавиатуры, прячет курсор и подтягивает четыре payload'а с двух скомпрометированных сайтов. Два из них сразу передаются в bash через pipe, два оседают в скрытой директории $HOME/.cacheb/. Затем на экране появляется поддельное диалоговое окно запроса пароля через osascript — с загруженной иконкой Apple и реальным именем пользователя жертвы, взятым из системы. Введённый пароль малварь не отправляет вслепую: она проверяет его через dscl /Local/Default -authonly и уходит к злоумышленникам только рабочий пароль.
Если жертва нажимает «Отмена» вместо того, чтобы вводить пароль, в ~/Library/LaunchAgents/ устанавливаются два LaunchAgent-файла — com.authirity.plist и com.chromer.plist. Первый запускает цикл убийства процессов с интервалом 210 миллисекунд, целясь в Finder, Dock, Spotlight, Терминал, Мониторинг активности и основные браузеры, и может работать до 83 часов подряд, пока не будет введён пароль. Второй запускает собственный цикл с интервалом 200 миллисекунд и способен работать до 3 000 000 секунд — это около 34,7 суток. Параллельно фоновый процесс каждые полсекунды опрашивает Keychain на предмет ключа Safe Storage браузера Chrome, и этот запрос вызывает настоящее системное окно macOS с подтверждением доступа — цикл держит рабочий стол в заложниках, пока пользователь не одобрит запрос. Есть и третий цикл — он на 6 часов блокирует NotificationCenter, чтобы предупреждения Gatekeeper физически не могли отрисоваться на экране. Если у Терминала нет разрешения Full Disk Access, оркестратор сам открывает System Settings на нужной вкладке и пошагово проводит жертву через выдачу этого доступа.
После успешного ввода пароля злоумышленники получают полный набор: подтверждённый пароль входа в macOS, AES-ключ Safe Storage от Chrome и ZIP-архив с учётными данными и cookie браузеров, хранилищами расширений криптокошельков, файлами десктопных кошельков, базами менеджеров паролей, самим Keychain, историей команд шелла и сохранёнными данными для входа из FileZilla. Ключ Safe Storage здесь на самом деле важнее самого пароля — именно им шифруются сохранённые пароли и cookie Chrome на диске, и обладая им, злоумышленник может расшифровать файлы Login Data и Cookies офлайн, на своей машине, в любой момент в будущем, даже если жертва давно сменила пароли.
Отдельного внимания заслуживает бэкдор с именем goyim — примерно на 80% он копирует публичный deploy-скрипт GSocket, открытого туннельного инструментария от группы The Hacker's Choice. Используется компонент gs-netcat — зашифрованный реверс-бэкдор, которому не требуется выделенный C2-сервер, он ездит через релей. Group-IB отследила релей gsnc[.]eu:67, а сам бинарник подтягивается напрямую с . На macOS он устанавливается под именем iCloud в ~/Library/Application Support/iCloudsync, а процесс маскируется под SystemUIServerl — на одну букву отличается от легитимного SystemUIServer. В отличие от модулей стилера, goyim не самоудаляется и не подчищает за собой следы.
Инфраструктура атаки выглядит скромно: три скомпрометированных домена с чистой репутацией размещают payload'ы, один из них — взломанный сайт на WordPress. Отдельного C2 Group-IB не обнаружила вовсе — эксфильтрация данных идёт через три Telegram-бота. При этом у аналитиков есть вся цепочка payload'ов, но нет ни одной приманки — не найдена ни посадочная страница, ни домены, которые её раздают, ни то, что вообще гонит на неё трафик.
Модули самого стилера умеют заметать следы: они автоматически выгружают собственные LaunchAgent, подделывают временные метки на основе папки ~/Movies, чтобы сломать анализ временной шкалы, и удаляют себя после завершения работы. А вот goyim остаётся — это единственный компонент кампании, который сознательно не убирает за собой, оставляя постоянный реверс-шелл в системе.
По телеметрии Group-IB, зафиксировано как минимум 100 целей в 33 странах, больше половины из них — в Европе. Активность кампании прослеживается с мая. Образец малвари был загружен на VirusTotal 9 июня и на момент анализа Group-IB не детектировался ни одним антивирусом. По структуре кода аналитики полагают, что малварь ещё находится в разработке.
ClickLock — не единственная кампания такого рода. В мае Microsoft документировала SHub Stealer, использовавший ту же технику проверки пароля через dscl. К той же волне ClickFix-кампаний для macOS Microsoft относит AMOS и MacSync. В апреле Jamf Threat Labs описала родственную схему, которая вообще обходится без вставки в буфер обмена — она использует URL-схему открывающую Script Editor с уже загруженным payload'ом, что полностью обходит проверку macOS на вставку из буфера. Тиш Ксафлер (Thijs Xhaflaire) из Jamf прокомментировал это так: «Когда закрывается одна дверь, злоумышленники находят другую». ClickLock в этом смысле как раз и есть та «другая дверь» — авторы сохранили метод с вставкой команды, но обошли защиту, сыграв на человеческом факторе.
Apple действительно попыталась закрыть эту дверь в macOS 26.4, выпущенной в конце марта: система предупреждает, если Терминал фиксирует подозрительную вставку, и блокирует уже опознанную известную малварь. Microsoft называет это прямым ответом на ClickFix-подобные схемы доставки. Но у защиты есть слабые места, признанные самой Apple: предупреждение срабатывает только у тех, кто обычно не пользуется Терминалом, рядом с ним есть кнопка «Всё равно вставить», а жёсткая блокировка работает лишь тогда, когда конкретный образец малвари уже известен системе.
Про сам механизм принуждения в Group-IB высказались прямо: «Такое поведение характерно исключительно для malware, работающего через принудительное взаимодействие, и не имеет никакого легитимного применения» — это касается серий killall и pkill с интервалом меньше секунды против Finder, Dock, SystemUIServer и NotificationCenter.
Среди индикаторов компрометации, которые стоит проверять на своей машине: curl, направленный через pipe в bash, где URL заканчивается на.jpg,.txt или.css; создание LaunchAgent в ~/Library/LaunchAgents/ процессом shell в связке с командой launchctl load; упоминания в контексте передачи данных; а также сам факт отсутствия найденной приманки — домена-ловушки для этой кампании нет ни в одном отчёте.
Если атака застигла врасплох и на экране появилось окно с запросом пароля после вставки команды в Терминал — вводить его нельзя ни в коем случае. Ни одна легитимная проверка на подлинность не требует доступа к Терминалу, а проверка Cloudflare в принципе работает в браузере — в этом весь смысл такой проверки. Group-IB рекомендует зажать кнопку питания до полного выключения, затем загрузиться в Safe Mode: на Intel-Mac для этого нужно держать Shift при старте, на Apple Silicon — держать кнопку питания до появления «Loading startup options», выбрать нужный том, зажать Shift и выбрать «Continue in Safe Mode». Если пароль уже был введён, единственный разумный вариант — отозвать все активные сессии в браузерах, считать скомпрометированными абсолютно все сохранённые пароли, cookie и ключи от криптокошельков, сменить все учётные данные без исключения. И держать в уме, что даже после того как циклы убийства процессов прекратятся и рабочий стол вернётся в норму, бэкдор goyim остаётся в системе под видом SystemUIServerl и продолжает работать как реверс-шелл.
Издание The Hacker News запросило у Group-IB данные о том, какие версии macOS были у пострадавших целей — ответ пока не получен, и материал обещают обновить при поступлении информации. Отчёт также не уточняет, сталкивался ли кто-то из выявленных 100 целей именно с исходной приманкой атаки — сама посадочная страница, домены её размещения и способ привлечения трафика на неё остаются неизвестными.
Заражение начинается со схемы ClickFix — метода, при котором жертву убеждают вставить команду в Терминал. Group-IB оценивает связь ClickLock с ClickFix с высокой степенью уверенности, но подчёркивает: именно такое применение техники аналитики видят впервые. Скрипт при запуске берёт первым аргументом некий RAY_ID и показывает поддельный баннер Cloudflare CAPTCHA поверх прогресс-бара, который прокручивает 12 статусных строк за 10 секунд. Всё это чистая театральность — ни одна из этих строк ничего не делает, задача одна: успокоить человека, который только что вставил чужой код в командную строку.
Дальше в дело вступает . Он отключает прерывания с клавиатуры, прячет курсор и подтягивает четыре payload'а с двух скомпрометированных сайтов. Два из них сразу передаются в bash через pipe, два оседают в скрытой директории $HOME/.cacheb/. Затем на экране появляется поддельное диалоговое окно запроса пароля через osascript — с загруженной иконкой Apple и реальным именем пользователя жертвы, взятым из системы. Введённый пароль малварь не отправляет вслепую: она проверяет его через dscl /Local/Default -authonly и уходит к злоумышленникам только рабочий пароль.
Если жертва нажимает «Отмена» вместо того, чтобы вводить пароль, в ~/Library/LaunchAgents/ устанавливаются два LaunchAgent-файла — com.authirity.plist и com.chromer.plist. Первый запускает цикл убийства процессов с интервалом 210 миллисекунд, целясь в Finder, Dock, Spotlight, Терминал, Мониторинг активности и основные браузеры, и может работать до 83 часов подряд, пока не будет введён пароль. Второй запускает собственный цикл с интервалом 200 миллисекунд и способен работать до 3 000 000 секунд — это около 34,7 суток. Параллельно фоновый процесс каждые полсекунды опрашивает Keychain на предмет ключа Safe Storage браузера Chrome, и этот запрос вызывает настоящее системное окно macOS с подтверждением доступа — цикл держит рабочий стол в заложниках, пока пользователь не одобрит запрос. Есть и третий цикл — он на 6 часов блокирует NotificationCenter, чтобы предупреждения Gatekeeper физически не могли отрисоваться на экране. Если у Терминала нет разрешения Full Disk Access, оркестратор сам открывает System Settings на нужной вкладке и пошагово проводит жертву через выдачу этого доступа.
После успешного ввода пароля злоумышленники получают полный набор: подтверждённый пароль входа в macOS, AES-ключ Safe Storage от Chrome и ZIP-архив с учётными данными и cookie браузеров, хранилищами расширений криптокошельков, файлами десктопных кошельков, базами менеджеров паролей, самим Keychain, историей команд шелла и сохранёнными данными для входа из FileZilla. Ключ Safe Storage здесь на самом деле важнее самого пароля — именно им шифруются сохранённые пароли и cookie Chrome на диске, и обладая им, злоумышленник может расшифровать файлы Login Data и Cookies офлайн, на своей машине, в любой момент в будущем, даже если жертва давно сменила пароли.
Отдельного внимания заслуживает бэкдор с именем goyim — примерно на 80% он копирует публичный deploy-скрипт GSocket, открытого туннельного инструментария от группы The Hacker's Choice. Используется компонент gs-netcat — зашифрованный реверс-бэкдор, которому не требуется выделенный C2-сервер, он ездит через релей. Group-IB отследила релей gsnc[.]eu:67, а сам бинарник подтягивается напрямую с . На macOS он устанавливается под именем iCloud в ~/Library/Application Support/iCloudsync, а процесс маскируется под SystemUIServerl — на одну букву отличается от легитимного SystemUIServer. В отличие от модулей стилера, goyim не самоудаляется и не подчищает за собой следы.
Инфраструктура атаки выглядит скромно: три скомпрометированных домена с чистой репутацией размещают payload'ы, один из них — взломанный сайт на WordPress. Отдельного C2 Group-IB не обнаружила вовсе — эксфильтрация данных идёт через три Telegram-бота. При этом у аналитиков есть вся цепочка payload'ов, но нет ни одной приманки — не найдена ни посадочная страница, ни домены, которые её раздают, ни то, что вообще гонит на неё трафик.
Модули самого стилера умеют заметать следы: они автоматически выгружают собственные LaunchAgent, подделывают временные метки на основе папки ~/Movies, чтобы сломать анализ временной шкалы, и удаляют себя после завершения работы. А вот goyim остаётся — это единственный компонент кампании, который сознательно не убирает за собой, оставляя постоянный реверс-шелл в системе.
По телеметрии Group-IB, зафиксировано как минимум 100 целей в 33 странах, больше половины из них — в Европе. Активность кампании прослеживается с мая. Образец малвари был загружен на VirusTotal 9 июня и на момент анализа Group-IB не детектировался ни одним антивирусом. По структуре кода аналитики полагают, что малварь ещё находится в разработке.
ClickLock — не единственная кампания такого рода. В мае Microsoft документировала SHub Stealer, использовавший ту же технику проверки пароля через dscl. К той же волне ClickFix-кампаний для macOS Microsoft относит AMOS и MacSync. В апреле Jamf Threat Labs описала родственную схему, которая вообще обходится без вставки в буфер обмена — она использует URL-схему открывающую Script Editor с уже загруженным payload'ом, что полностью обходит проверку macOS на вставку из буфера. Тиш Ксафлер (Thijs Xhaflaire) из Jamf прокомментировал это так: «Когда закрывается одна дверь, злоумышленники находят другую». ClickLock в этом смысле как раз и есть та «другая дверь» — авторы сохранили метод с вставкой команды, но обошли защиту, сыграв на человеческом факторе.
Apple действительно попыталась закрыть эту дверь в macOS 26.4, выпущенной в конце марта: система предупреждает, если Терминал фиксирует подозрительную вставку, и блокирует уже опознанную известную малварь. Microsoft называет это прямым ответом на ClickFix-подобные схемы доставки. Но у защиты есть слабые места, признанные самой Apple: предупреждение срабатывает только у тех, кто обычно не пользуется Терминалом, рядом с ним есть кнопка «Всё равно вставить», а жёсткая блокировка работает лишь тогда, когда конкретный образец малвари уже известен системе.
Про сам механизм принуждения в Group-IB высказались прямо: «Такое поведение характерно исключительно для malware, работающего через принудительное взаимодействие, и не имеет никакого легитимного применения» — это касается серий killall и pkill с интервалом меньше секунды против Finder, Dock, SystemUIServer и NotificationCenter.
Среди индикаторов компрометации, которые стоит проверять на своей машине: curl, направленный через pipe в bash, где URL заканчивается на.jpg,.txt или.css; создание LaunchAgent в ~/Library/LaunchAgents/ процессом shell в связке с командой launchctl load; упоминания в контексте передачи данных; а также сам факт отсутствия найденной приманки — домена-ловушки для этой кампании нет ни в одном отчёте.
Если атака застигла врасплох и на экране появилось окно с запросом пароля после вставки команды в Терминал — вводить его нельзя ни в коем случае. Ни одна легитимная проверка на подлинность не требует доступа к Терминалу, а проверка Cloudflare в принципе работает в браузере — в этом весь смысл такой проверки. Group-IB рекомендует зажать кнопку питания до полного выключения, затем загрузиться в Safe Mode: на Intel-Mac для этого нужно держать Shift при старте, на Apple Silicon — держать кнопку питания до появления «Loading startup options», выбрать нужный том, зажать Shift и выбрать «Continue in Safe Mode». Если пароль уже был введён, единственный разумный вариант — отозвать все активные сессии в браузерах, считать скомпрометированными абсолютно все сохранённые пароли, cookie и ключи от криптокошельков, сменить все учётные данные без исключения. И держать в уме, что даже после того как циклы убийства процессов прекратятся и рабочий стол вернётся в норму, бэкдор goyim остаётся в системе под видом SystemUIServerl и продолжает работать как реверс-шелл.
Издание The Hacker News запросило у Group-IB данные о том, какие версии macOS были у пострадавших целей — ответ пока не получен, и материал обещают обновить при поступлении информации. Отчёт также не уточняет, сталкивался ли кто-то из выявленных 100 целей именно с исходной приманкой атаки — сама посадочная страница, домены её размещения и способ привлечения трафика на неё остаются неизвестными.