У топ-менеджера есть макбук. Он ездит с ним в командировки, работает из отеля или ресторана. СЗИ на периметре не могут его защитить, SOC иногда даже не мониторит этот актив. А ведь ОС от Apple совсем не иммунна к угрозам. Что надо делать, чтобы учётка или секрет не нашлись однажды в даркнете?
- 1. Введение
- 2. macOS часто находится вне корпоративной модели угроз
- 3. Хосты на macOS часто имеют повышенные привилегии
- 4. Использование macOS в dev-средах увеличивает риск горизонтального перемещения
- 5. Многие средства защиты macOS работают в режиме «best effort»
- 6. Инциденты на macOS часто выявляются постфактум
- 7. Отсутствие глубокой телеметрии усложняет расследование
- 8. macOS остаётся «серой зоной» между ИТ и кибербезопасностью
- 9. Защита macOS требует организационных мер и зрелого EDR-решения
- 10. Выводы
Введение
Разговоры о защите корпоративных инфраструктур почти всегда сводятся к двум платформам: Windows, которая стала историческим стандартом, и Linux, куда активно переезжают серверы и рабочие станции. Однако во многих компаниях давно обосновалась и третья операционная система — macOS. Макбуки разработчиков, дизайнеров, аналитиков и топ-менеджеров годами работают рядом с доменной инфраструктурой. При этом защищённость таких устройств чаще держится на встроенных средствах, чем на полноценном мониторинге.
По данным BI.ZONE SOC, почти у 28 % компаний хотя бы раз срабатывали алерты на устройствах под управлением macOS. Обычно таких машин в инфраструктуре немного, но риски это не снижает. Чтобы проникнуть в инфраструктуру и закрепиться в ней, атакующему достаточно одной незащищённой конечной точки. К тому же за компьютерами Mac нередко работают сотрудники с доступом ко критически важным ресурсам. Давайте разберём, почему macOS выпадает из корпоративной модели угроз и чем это опасно.
macOS часто находится вне корпоративной модели угроз
Существует устойчивый миф, что macOS почти не подвержена атакам. Пока доля платформы на рынке была сравнительно невелика, интерес злоумышленников к ней был заметно ниже, чем к Windows. Но за последние годы изменилась сама структура угроз, что сделало macOS куда более привлекательной целью. Доминирующим классом вредоносов стали стилеры. По данным Threat Zone 2026, из десяти образцов вредоносных программ, которые чаще всего распространялись через фишинговые рассылки, пять оказались стилерами. Статистика кросс-платформенная, но и macOS этот класс угроз стороной не обошёл.
Показателен пример Banshee — стилера под macOS, который продавался на одном из теневых форумов. Он похищал с устройства логины и пароли, cookie-сессии браузеров, содержимое связки ключей и данные криптовалютных кошельков, а собранное отправлял оператору в Telegram. По данным анализа теневых площадок за 2024 год и первую половину 2025-го, подписка на стилер стоила 1500 долларов в месяц. Однако с распространением устройств на macOS порог входа для компрометации со временем снижался. Исходный код Banshee Stealer утёк в конце 2024 года, после чего на его основе стали появляться производные версии. Под macOS известны и другие стилеры, в частности Atomic Stealer, MacStealer и Poseidon Stealer.
Угрозы для Mac давно перестали быть экзотикой, а вот подход к защите macOS во многих компаниях за это время не изменился.
Хосты на macOS часто имеют повышенные привилегии
Парадокс в том, что при скромной доле в общем парке устройств ценность отдельного macOS-хоста для атакующего выше средней. За компьютерами на macOS работают топ-менеджеры с доступом к финансовой и стратегической информации, разработчики, DevOps-инженеры, администраторы облачных сервисов, маркетологи с правами в рекламных кабинетах и корпоративных соцсетях. Вдобавок такие устройства почти всегда оказываются ноутбуками, которые половину времени проводят вне корпоративной сети. На них работают из дома и кафе, в командировках из других городов, оставаясь за пределами периметра и его сетевых средств защиты.
Добавляет риска и техническая специфика. Первая учётная запись в macOS по умолчанию получает права администратора, а не обычного пользователя. В отличие от Windows-станций, эти права редко забирают. В связке ключей Keychain хранятся пароли, токены и сертификаты, в домашних каталогах лежат SSH-ключи, kubeconfig-файлы и активные сессии облачных утилит. Именно эти данные и становятся целью современных стилеров.
Отдельного внимания заслуживает приём злоумышленников, который делает наличие прав администратора ещё рискованнее. Через штатный интерпретатор AppleScript киберпреступник выводит на экран окно, похожее на системный запрос пароля от связки ключей. Пользователь вводит настоящий пароль, и тот достаётся атакующему в открытом виде. Эксплойт для повышения привилегий при этом не нужен. Пароль локального администратора, полученный через поддельное окно, позволяет выполнять привилегированные операции от имени пользователя.
Использование macOS в dev-средах увеличивает риск горизонтального перемещения
Классические техники горизонтального перемещения через Active Directory и SMB на macOS встречаются реже и хуже покрыты правилами детектирования. Привычных Windows-паттернов SOC почти не видит, и это создаёт ложное чувство безопасности. Украденные с устройства токены, ключи и сессии дают злоумышленнику легитимный доступ к репозиториям, CI/CD и облачным средам. Оттуда атака распространяется на производственную инфраструктуру и далее в цепочку поставок. Разработчику приходится хранить эти секреты локально, потому что без них не работают ни git, ни kubectl, ни консольные клиенты облаков. Поэтому лежат они в предсказуемых местах и остаются на диске постоянно.
Тот же сценарий работает и на уровне взаимодействия между компаниями. По данным Threat Zone 2026, компрометация подрядчиков стала причиной 9 % случаев получения первоначального доступа. Злоумышленники пользуются тем, что уровень защиты у подрядчика обычно ниже, чем у его заказчика. Непокрытый мониторингом ноутбук разработчика и есть та точка, с которой такая цепочка начинается.
Так, например, троян XCSSET заражает проекты Xcode, и разработчик сам распространяет вредоносный код вместе со своим. В прошлом этот зловред умел обходить TCC (систему контроля доступа приложений к конфиденциальным ресурсам). В 2021 году XCSSET эксплуатировал уязвимость «нулевого дня» CVE-2021-30713, подставляя легитимное приложение с уже выданными правами, и так получал доступ к защищённым ресурсам без запроса к пользователю. Apple закрыла уязвимость в macOS 11.4.
Сценарии, перечисленные в этом разделе, объединяет одно: атака рано или поздно проявляется на самом устройстве, когда вредоносный процесс обращается к ключам и токенам, закрепляется в системе и открывает канал наружу. На периметре этого не видно, украденные доступы выглядят легитимными, а привычных сетевых следов атака почти не оставляет. Поэтому один скомпрометированный Mac с доступом к CI/CD может стоить компании всей инфраструктуры, а вендору — репутации. Значит, видеть нужно не только периметр, но и то, что происходит на самом устройстве.
Многие средства защиты macOS работают в режиме «best effort»
У Apple действительно сильная базовая защита. Gatekeeper проверяет подпись приложения и наличие выданного компанией нотариального тикета. XProtect работает как встроенный антивирус. System Integrity Protection защищает системные файлы и процессы от изменений, даже если атакующий получил права рута. Механизм TCC контролирует доступ приложений к конфиденциальным ресурсам. Эти инструменты хорошо сдерживают поток массовых угроз, но не предназначены для обнаружения целевых атак.
По сути, это кибергигиена платформы, рассчитанная на широко распространённые вредоносные программы. От прицельной атаки на конкретную инфраструктуру такая защита оберегает лишь в той мере, в какой злоумышленник не учёл эти механизмы в своих планах.
Обход защиты чаще всего идёт через установщик приложения, и такие техники описываются отдельными правилами детектирования. Одно из них нацелено на установку из DMG-образа, при которой из временной директории, куда macOS помещает приложение перед первым запуском, стартует скриптовый интерпретатор.
Другое правило описывает пакет PKG, где модуль расширения установщика может подменить метод закрытия главного окна и скрыть само окно, чтобы полезная нагрузка не завершилась, когда пользователь попробует закрыть установщик. Неподписанная нагрузка тогда выполняется в обход основных системных проверок и наследует права системного установщика пакетов. Действуют на macOS и классические схемы заражения. Офисный документ с макросом запускает посторонний процесс от Word, Excel или PowerPoint ровно так же, как это происходит в Windows.
Существуют и более простые способы обойти встроенную защиту. Один из них — техника ClickFix: пользователь попадает на поддельную страницу, которая имитирует сообщение об ошибке или запрос подтверждения «Вы не робот». Страница предлагает «решить проблему» с помощью готовой команды, уже скопированной в буфер обмена. Жертве остаётся вставить её и выполнить. На такие страницы ведут вредоносная реклама и поддельные сайты в поисковой выдаче. Команда автоматически адаптируется под операционную систему жертвы: для macOS создаётся отдельный вариант, в котором пользователю предлагают выполнить строку в Terminal.
Gatekeeper в этой цепочке не участвует, так как пользователь сам запускает код, и до недавнего времени этому ничто не препятствовало. В macOS 26.4 (март 2026 года) Apple добавила проверку команд, вставляемых в Terminal, но атакующие быстро адаптировались и переключились на Script Editor и на схему «applescript://», которая позволяет выполнить код в обход приложения Terminal. Группа анализа угроз BI.ZONE зафиксировала кампании ClickFix на российском рынке, пока что с несомой нагрузкой под Windows. macOS-вариации уже активно применяются за рубежом, так что их появление в России — лишь вопрос времени.
Рисунок 1. ClickFix-приманка (реконструкция)
Для противодействия таким техникам необходимы более совершенные средства, чем встроенная защита. Обнаружить и остановить целевую атаку помогают решения класса EDR (Endpoint Detection and Response). Они выявляют угрозы и реагируют на них прямо на конечных точках, оценивая не подпись приложения, а его поведение. Например, обращение к связке ключей и криптокошелькам или запрос на неизвестный внешний адрес явно указывали бы на атаку.
Встроенные механизмы успешно блокируют массовый поток вредоносного кода, но неспособны противостоять целевой атаке, спланированной под конкретную инфраструктуру и заведомо учитывающей штатные проверки.
Инциденты на macOS часто выявляются постфактум
Как следствие из предыдущего пункта, компрометацию macOS обычно замечают не в момент атаки, а по её последствиям. При этом сигнал приходит не с самого устройства, а со стороны. Обычно срабатывают средства защиты на сетевом периметре (межсетевой экран, IDS или веб-шлюз), всплывают утёкшие в даркнет учётные данные, появляются аномальные входы в облачные сервисы. При таком сценарии обнаружение может занять дни и даже недели.
Насколько EDR ускоряет обнаружение угроз и реагирование на них, хорошо видно по цифрам, даже собранным по разным платформам. По данным BI.ZONE SOC, среднее время обнаружения инцидента при мониторинге силами SIEM-системы без EDR составляет три часа, а среднее время реагирования доходит до суток. С EDR эти показатели снижаются до полутора часов и тридцати минут соответственно.
При этом современным атакам не требуется много времени: стилер собирает и выгружает данные за минуты, после чего может удалить себя с диска. Обнаруживать и пресекать такую активность нужно в момент выполнения вредоносного кода. Когда Keychain и сессии уже у злоумышленника, реагирование превращается в тотальную смену паролей и отзыв токенов по всей компании.
Отсутствие глубокой телеметрии усложняет расследование
Даже подтверждённый инцидент на macOS трудно расследовать задним числом, и причина — в устройстве телеметрии. С выходом macOS Catalina в 2019 году Apple объявила устаревшим механизм расширений ядра (kernel extensions, kext) для сторонних средств защиты. Эти модули загружались непосредственно в ядро ОС и давали максимальную глубину видимости. Однако теперь их использование ограничено: на устройствах с Apple Silicon загрузка kext требует снижения уровня безопасности системы и последующей перезагрузки.
Основным источником данных стал фреймворк Endpoint Security — официальный API Apple для получения событий в настоящем времени. Через него можно отслеживать запуск процессов, файловые операции, работу с правами, аутентификации. Сетевые соединения через него не отдаются, для этого нужен отдельный фреймворк Network Extension. Глубина видимости на платформе теперь определяется тем, насколько полно разработчик СЗИ реализовал возможности этих API.
Для ручного расследования постфактум инструментов тоже немного. В macOS есть единый журнал (unified log), в который все компоненты операционной системы записывают события. Записей в этом журнале много, но глубина хранения ограничена несколькими днями, после чего старые данные вытесняются новыми. Централизованному анализу он поддаётся плохо, а часть данных по умолчанию скрыта как приватная и недоступна без дополнительной настройки.
Классическая подсистема аудита OpenBSM начиная с macOS 11 объявлена устаревшей, а в версиях начиная с macOS 14 она отключена по умолчанию. Документация Apple прямо предупреждает, что подсистема будет удалена в одной из следующих версий (но конкретная не называется), и отсылает разработчиков к той же Endpoint Security. Утилита «eslogger», консольный инструмент Apple для вывода событий Endpoint Security, появилась в macOS 13. Она подходит для разовой диагностики на конкретном хосте, но не для постоянного мониторинга всего парка устройств. Штатного аналога Sysmon — бесплатной утилиты Microsoft, ставшей стандартом де-факто для хостового мониторинга на Windows, — в macOS не предусмотрено.
Если телеметрия не собиралась до инцидента, восстановить хронологию атаки чаще всего невозможно. Дерево процессов, файловые операции и сетевые соединения не воспроизводятся задним числом. Единственный работающий подход состоит в том, чтобы собирать эти данные непрерывно и до инцидента. Это и обеспечивает EDR-агент на устройстве.
macOS остаётся «серой зоной» между ИТ и кибербезопасностью
Свою роль в формировании этой слепой зоны сыграл и рынок средств защиты. В российских компаниях основное внимание традиционно уделялось Windows и Linux (включая отечественные дистрибутивы), тогда как macOS оставалась на периферии. Спрос на её защиту был ниже, зрелые продукты появлялись позже. Сейчас ситуация меняется: вендоры наращивают функциональность агентов под macOS и адаптируют их как к новым версиям ОС, так и к меняющемуся ландшафту угроз.
У всех перечисленных проблем одна общая причина — организационная. Устройства на macOS во многих компаниях всё ещё не считаются управляемым активом. В лучшем случае их заводят в MDM (систему централизованного управления устройствами), нередко они используются в формате BYOD (личные устройства сотрудников, применяемые для работы).
Политики безопасности исторически писались под Windows, и Mac-устройства во многих организациях так и не попали в контур мониторинга SOC. В результате возникает разрыв ответственности. ИТ полагается на встроенные механизмы XProtect и FileVault, а служба кибербезопасности рассматривает такие устройства как находящиеся вне периметра мониторинга и, следовательно, вне зоны её ответственности.
Дальше срабатывает опасная логика: нет агента — нет алертов — нет инцидентов. Отчётность выглядит чистой, а риск при этом никуда не исчезает.
Стоит учитывать и то, что развернуть защиту на macOS технически сложнее, чем на Windows. Агенту нужны системное расширение и полный доступ к диску. При большом парке устройств эти разрешения удобно раздать централизованно через MDM, на небольшом — выдать вручную. Ни то ни другое не мешает защите работать, но требует, чтобы ИТ и кибербезопасность действовали заодно, а не считали Mac чужой зоной ответственности.
Закрыть слепую зону можно в два этапа: сначала организационно, потом технически.
Защита macOS требует организационных мер и зрелого EDR-решения
Чтобы включить устройства Mac в контур мониторинга, первыми шагами должны стать организационные, без которых любые практические инструменты бесполезны:
- Провести инвентаризацию. Как правило, Mac-устройств в парке компании больше, чем принято думать. Часть заведена в MDM, часть используется как BYOD, а часть не учтена вовсе. Пока нет полного списка, говорить о защите преждевременно.
- Включить macOS в модель угроз. Платформу нужно рассматривать как полноценную цель атак наравне с Windows и Linux, а не как экзотическое исключение.
- Добавить macOS в зону мониторинга SOC. Устройства должны попадать в поле зрения центра мониторинга, а требования к обнаружению угроз и реагированию на них нужно распространить на macOS в том же объёме, что действует для остальных операционных систем.
- Проверить полноту детектирования. Стоит провести учения по техникам из матрицы MITRE ATT&CK для macOS, чтобы понимать, какие атаки SOC реально видит, а какие нет.
Второй этап — технический. Парк устройств на macOS должен быть полностью покрыт зрелым EDR-решением, а не формальными агентами «для галочки». Такое решение должно уметь:
- Собирать телеметрию через Endpoint Security Framework. В состав собираемых данных должны входить запуск процессов с полным деревом и аргументами, файловые операции, сетевая активность, аутентификации и входы в систему, подключение внешних носителей. Сетевую активность нужно собирать через Network Extension.
- Выявлять угрозы непосредственно на устройстве. Для этого необходимы поведенческие правила под техники MITRE ATT&CK для macOS, проверка индикаторов компрометации, сканирование YARA-правилами (гибкими правилами для поиска характерных признаков угроз в файлах и памяти) и корреляция событий на конечной точке.
- Работать автономно. Обнаружение инцидентов и автоматическое реагирование на них не должны зависеть от связи с сервером, ведь устройства значительную часть времени находятся вне корпоративной сети.
- Изолировать скомпрометированное устройство от сети. По команде аналитика или автоматически агент должен обрывать сетевые соединения хоста, сохраняя при этом канал управления. Реагировать на угрозу и проводить расследование можно удалённо.
- Инвентаризировать систему и проверять конфигурации. В частности, EDR-агент должен собирать данные об установленном ПО, точках автозапуска LaunchAgents и LaunchDaemons (механизмы автозапуска программ в macOS), статусе SIP, Gatekeeper и FileVault (шифрование диска), небезопасных настройках.
- Реагировать, а не только оповещать. Решение должно уметь завершать вредоносные процессы, удалять файлы и механизмы закрепления, а также предоставлять инструменты для расследования прямо на хосте.
- Работать в единой консоли с агентами для Windows и Linux. Аналитик должен видеть кросс-платформенную атаку целиком, а не три несвязанных потока событий.
И, конечно же, надо своевременно поддерживать новые версии macOS. Агент не должен переставать работать после каждого крупного обновления системы от Apple.
Выводы
Современная корпоративная инфраструктура гетерогенна по определению. Windows, Linux и macOS в ней сосуществуют, и это нормально. Ненормально, когда уровень зрелости защиты на этих платформах кардинально различается. Злоумышленник ищет не самую распространённую систему, а наименее защищённую точку входа.
Поэтому правильный вопрос к EDR-вендору сегодня — не «есть ли у вас агент под macOS?», а «что именно он умеет и какие реальные угрозы под эту платформу закрывает?». Слепых зон в инфраструктуре быть не должно, на какой бы операционной системе они ни возникали.
Прежде чем оценивать вендора, полезно честно ответить на несколько вопросов о собственном парке устройств:
- Сколько машин на macOS реально работает в инфраструктуре и все ли они учтены?
- Собирается ли с них телеметрия, и если да, то насколько она глубока?
- Реализованы ли на macOS те же возможности обнаружения угроз и реагирования на них, которые вы считаете обязательными на других платформах?
Если хотя бы на один вопрос нет уверенного ответа, непокрытый участок у вас, вероятно, уже есть, и его пора закрыть.
