Пока в сети появляется всё больше разговоров о запрете использования Apple-техники в определённых кругах, мы хотим показать, как у нас организован мониторинг macOS с точки зрения безопасности корпоративной инфраструктуры.
Статья является продолжением первой части из микросерии аналитических статей, посвящённых тому, как мы мониторим macOS в Ozon.
Тут будут боль мемы и немного примеров инцидентов :)
Немного о себе: я работаю в Ozon Tech в отделе SOC и являюсь руководителем группы аналитиков. До Ozon я не сталкивался с мониторингом MacOS, и это стало для меня новым опытом.
План
Связка Osquery & Fleet -> SIEM
У нас в компании для конфигурации и отправки событий с endpoint-устройств используются агенты Osquery, которые управляются через сервер Fleet. События магическим образом доставляются в нашу SIEM, где уже и начинается их обработка правилами корреляции.
Какие события собираем
В результате анализа мы остановились на сборе данных типов событий.
Это так называемый must-have:
.bash_history (
shell_history);события процессов (
process_events);автозапуск (
startup_items, crontab);залогиненные пользователи (
logged_in_users);встроенные СЗИ MacOS (
disk_encryption/sip_config/gatekeeper/alf);сетевые интерфейсы (
interface_details);сетевые коннекты (
process_open_sockets/processes/users);установленное ПО (
apps).
Более подробно устройство и инфраструктура Fleet была описана в первой части, поэтому не буду сильно повторяться.
Вы правила мониторинга продаёте? Нет, просто показываем
Ещё только планируя раскатку агентов, мы понимали, что работы будет очень много ...
Сложности выбора, с чего начать...
Первые события
Первой тестовой группой, на которую был раскатан агент Osquery и с которой мы увидели события, был департамент ИБ.
Это сильно облегчило написание первых алертов, потому что аномальных действий сотрудники ИБ совершают гораздо больше, чем обычные пользователи. И, что немаловажно, могут внятно доходчиво рассказать, что конкретно они делали и какие еще действия необходимо покрыть алертами.
Кажется странным начинать поиск каких-то APT, не включив даже антивирус. Поэтому самым первым средством контроля стала настройка встроенных средств защиты macOS. Речь идёт о SIP, GateKeeper, ALF и Filevault. В случае отключения (или снижения уровня защищенности) в каком-либо из этих механизмов защиты системы, автоматически создается RISK-тикет на пользователя, в котором он рассказывает о причинах такого изменения настроек. В целевой картине, к которой мы движемся, на всех хостах активны данные механизмы защиты.
Мониторинг живости агента Osquery
Вторым был написан контроль поступления событий с хостов. Некоторые пользователи негативно отреагировали на то, что ИБ будет "следить за тем, какие фильмы по вечерам смотрят" (да-да, нам же нечем заняться) и попытались удалить агент Osquery с компьютера. Поэтому был реализован механизм контроля и переустановки (в случае проблем) агента.
Анализ MITRE ATT&CK
При анализе матрицы MITRE и определении приоритетов мониторинга основной упор был сделан на следующие этапы (тактики): Execution и Persistence.
Причина данного решения: устройства с macOS в компании используются как endpoint-устройства и не должны хранить/обрабатывать критичную информацию, поэтому для злоумышленников будут являться, скорее, промежуточной точкой с доступом в сеть компании. Именно поэтому эти два этапа так важны для нас.
Дисклеймер
Мы не говорим, что остальные этапы неважны или не мониторятся, но наиболее критичные и легко детектируемые риски относятся к данным этапам.
Мониторинг исполняемых команд и запускаемых процессов
Весомая часть мониторингов направлена на поиск IOC'ов среди команд bash_history или в командах запускаемых процессов. Чтобы не грузить SIEM каждый раз, запуская поиск по одному слову, мы подготовили следующую логику:
все поля в событиях привели к CIM;
создали Lookup (табличный список), в котором перечисляем подозрительные, по нашему мнению, IOC'и;
создали поиск, который среди событий по ключевым полям из лукапа ищет совпадения.
Пример
Поиск стандартного reverse shell через bash.
Вот так команда выглядит в Lookup'е:
А вот так выглядит условие поиска:
ищем все команды, вводимые пользователем, и процессы, порождаемые системой;
ищем совпадения с командами, перечисленными в Lookup’e;
проверяем, что нет исключений на данные команды;
обогащаем поиск данными по пользователю/хосту;
выводим информацию в целевые системы. Получаем примерно следующий результат:
Другие примеры мониторингов
Ниже перечислены некоторые базовые мониторинги для этапа закрепления, которые выстроены на основе собираемых событий.
LaunchDaemons и LaunchAgents. Перед входом в систему Launchd запускает от имени root-службы и другие компоненты, указанные в .plist-файлах из этих папок, что дает злоумышленнику возможность закрепиться в системе и потенциально повысить свои привилегии. Мы смотрим:
созданные .plist-файлы по их названиям и сравниваем с известными objective-see-сигнатурами;
связки команд curl и Launch(Agent|Daemons). Подразумеваем, что атакующий может так загружать свои .plist-файлы;
также связку команд base64 и Launch(Agent|Daemons) (суть такая же, как в пункте выше);
и ищем короткие, а также скрытые .plist-файлы.
Cron в macOS. Тут все просто: как и в других nix, по расписанию крона будут выполняться команды, которые злоумышленник пропишет в файл. Следим за добавлением новых задач и алертим в случае появления таковых. На самом деле не такое частое событие при обычной пользовательской работе.
Kexts. Расширения ядра, которые позволяют взаимодействовать в том числе с аппаратным обеспечением компьютера. Немного митигирует риски установки расширений рабочий SIP (с правильной конфигурацией), а также активный FileVault. Следим за запуском команды kextload и анализируем, что именно за модуль пытались загрузить и для чего.
Login Items. По аналогии с Cron, позволяет злоумышленнику прописать выполнение команд при входе пользователя в систему. Следим за добавлением новых задач Login Items.
LoginHooks и LogoutHooks. Данные приложения отвечают за то, какие скрипты будут выполнены/открыты до/после перезагрузки. Мониторим любое обращение к com.apple.loginwindow-плисту.
Event Monitor Daemon (emond). Определяет правила демона мониторинга событий, куда злоумышленники могут записать правило для выполнения команд при возникновении какого-то определенного события. Следим за появлением новых правил в папке
/etc/emond.d/rules/.
...
Сработавшие алерты
За несколько месяцев мониторингов было несколько интересных случаев.
Reverse Shell
Когда еще только писали правила поисков, обнаружили несколько запусков reverse shell на корпоративных ноутбуках. Конечно же, было много сработок с ноутбуков ИБ, но была и еще одна подозрительная — с ноутбука разработчика информационных систем. В ходе разбора инцидента выяснили, что это была активность по решению CTF. Попросили проводить все такие активности с личного компа.
Попытка входа по SSH
Среда, утро, приходит алерт на попытку входа SSH под УЗ root на ноутбуке. Сотрудник активность не подтвердил. Начинаем разбираться, находим на ноуте некорпоративный VPN, изымаем комп для анализа, проверяем все возможные журналы, другие установленные программы, все истории команд... Приходим к выводу, что ноутбук был подключен к стороннему VPN, и кто-то, просто сканируя сеть, попробовал войти под стандартной УЗ. В ходе расследования записали еще несколько идей для мониторинга. В частности, небезопасные браузерные плагины.
Синк заметок на Github
Сработал алерт на добавление задачи в Cron. Изучаем, что конкретно было добавлено, приходим к выводу, что это скрипт для синка заметок с рабочего компьютера в репу на GitHub. Данное действие может нести угрозу публикации чувствительной информации во внешние системы и дальнейший неправомерный доступ к ней. С сотрудником проведена беседа, скрипт удален.
Заключение
Мониторинги, описанные в статье, не отражают полную картину: о многом мы бы не хотели упоминать. Но даже такие, не самые Rocket Science-мониторинги позволяют выявлять на ранних стадиях многие инциденты ИБ, связанные с состоянием корпоративной защищенности.
Будем рады почитать идеи/предложения/личный опыт/боли про мониторинг яблочных устройств.
Stay tuned :)