D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Можно бесконечно наблюдать за тремя вещами: горящим огнем, текущей водой и событиями в операционной системе. И если в Windows средства мониторинга и журналирования уже хорошо изучены пользователями и системными администраторами, то в macOS с этим не все так просто. Сегодня мы поговорим о бесплатных инструментах отслеживания событий в «маке» и их практическом применении.
Как мы привыкли к событиям Windows… С ними все понятно, в сети доступно огромное количество материалов о настройке централизованного сбора событий с использованием Windows Event Forwarding. Многие гайды предлагают пошаговые инструкции с ответами на вопросы из серии «Сколько WEC (Windows Event Collector) нужно для парка в 4000 машин?».
Однако крайне мало внимания уделяется компьютерам на базе macOS. Причины очевидны: немногие организации сейчас готовы закупать «маки» для своих сотрудников. Это дорого, непонятно, как эти машины администрировать, возникает ворох проблем с совместимостью. Кроме того, на рынке доступно не так много специалистов, которые знают, как обуздать эту операционную систему и как обезопасить ее, ведь для macOS также существуют угрозы. Однако решение проблемы с мониторингом есть, и оно уже встроено в систему, начиная с версии 10.15 Catalina.
Ранее для мониторинга событий в macOS использовалась подсистема аудита OpenBSM. Она была разработана компанией McAfee Research по индивидуальному заказу Apple в 2004 году. Позднее исходный код передали в TrustedBSD для нужд комьюнити. Этот инструмент был убран из macOS в версии Big Sur и больше не поддерживается.
Endpoint Security Framework (ESF) — это нативный компонент macOS, который служит для проактивного поиска событий и реагирования на них. Инструмент позволяет подписываться на события Notification и Authorization. Принцип его работы можно сравнить с Event Tracing For Windows (ETW). Он позволяет просматривать низкоуровневые события, связанные с процессами, файлами, немного с сетью и памятью, а также много чего еще!
В Apple это прекрасно понимали и поэтому в 2019 году (лучше поздно, чем никогда) заменили Kernel Extensions, которые работали в пространстве ядра, System Extensions, которые работают в пользовательском пространстве. Теперь у разработчиков развязаны руки. Все стало гораздо удобнее.
Хотя Kernel Extensions уже устарели, они все еще могут использоваться в современных macOS — но с оговоркой, что профиль безопасности системы должен быть сильно снижен. Добиться этого бывает очень сложно, и обычно это делается исключительно в целях разработки. Если производители не заменят кексты системными расширениями, они могут поставить под угрозу безопасность систем своих клиентов.
Существует огромное количество событий, на которые можно подписаться, чтобы получать информацию о том, что происходит в системе в реальном времени.
На сайте для разработчиков Apple есть полный список событий с описанием, какую информацию содержит каждое из них.
В настройках можно установить фильтры и подписки на конкретные типы событий.
Так выглядит событие запуска команды curl после парсинга.
Тут мы можем увидеть события, которые относятся к главному событию.
А вот процесс‑инициализатор.
Событие запуска команды curl в сыром виде.
Загрузить утилиту можно по ссылке с GitHub.
Это eslogger, утилита командной строки, она предоставляет прямой доступ непосредственно к генерируемым ядром событиям и поставляется со всеми версиями macOS выше Ventura. Этакий поисковик среди событий.
Плюсы eslogger:
Код: Скопировать в буфер обмена
Эта команда выведет нам внушительный список. Приведу примеры:
Код: Скопировать в буфер обмена
На компьютер Mac попал надоедливый вредоносный скрипт, который прописался как задача в
Файл задачи с расширением
Код: Скопировать в буфер обмена
А сам скрипт так:
Код: Скопировать в буфер обмена
Чтобы отловить этот скрипт, нам понадобится следующая команда eslogger:
Код: Скопировать в буфер обмена
Предположим, что у нас уже писались логи в момент заражения. Нам не составит труда найти событие добавления скрипта в автозапуск. Большая часть события была отброшена, оставлены только главные строки. В оригинальных событиях много информативных полей, в том числе и очень полезных для связывания событий друг с другом (btm_launch_item_add):
Код: Скопировать в буфер обмена
Далее мы найдем момент запуска скрипта (exec):
Код: Скопировать в буфер обмена
Финальный аккорд. Событие удаления файла xakep.ru-2023.log (unlink).
Код: Скопировать в буфер обмена
В общем, при наличии логов отыскать требуемое событие и получить сведения о нем довольно просто.
Например, можно создать новую учетку на компьютере и назвать ее с нижним подчеркиванием _brew, добавить привилегии, чтобы обычный пользователь не мог прибить процессы, запущенные от ее имени. Ожидается, что хакер, когда захочет узнать всех пользователей в системе, отфильтрует вывод, убирая записи с нижними подчеркиваниями, потому что так называются системные учетки для внутреннего функционирования системы. А даже если он выведет все учетные записи, _brew замаскируется под пакетный менеджер, который стоит почти на каждом «маке» программиста. Таким образом мы и защитимся от команды kill.
Ну или второй вариант — назвать _ftp_server. Это объяснит столь высокие системные полномочия у учетки.
Конкретную пошаговую инструкцию выдать не получится просто потому, что у всех разные инфраструктуры и очень по‑разному администрируются «маки», но подкинуть пару идей я могу.
Какова нагрузка на систему? Незначительная. Однако EPS может быть большим, если должным образом не настроить фильтрацию событий.
Напоминаю, что решение бесплатное и всех удобств «из коробки» не гарантирует. Фильтрация тут обязательна.
Приведем JSON в нормальный вид с помощью скрипта на Python 3:
Код: Скопировать в буфер обмена
Наполненный логами файл мы прогоним через наш нормализатор:
Код: Скопировать в буфер обмена
Нормализованный файл теперь необходимо отфильтровать. Я, например, исключу все события, связанные с процессом Finder:
Код: Скопировать в буфер обмена
Подскажу пути, которые можно (точно так же, как и Finder) исключить из захвата через eslogger, чтобы не создавать мусор. Многие из путей могут показаться важными для мониторинга. Однако в 2015 году Apple добавила механизм System Integrity Protection (SIP), а позже, в 2019-м, разделила диск на защищенный и незащищенный разделы. SIP предохраняет системные критически важные директории от вмешательства, и поэтому злоумышленник не сможет ничего изменить в них, если только ты не отключил SIP вручную. Поэтому и мониторить их не нужно. Найти список путей для исключения можно в моем репозитории.
Автор Михаил Онищенко aka tofolt
источник xakep.ru
Как мы привыкли к событиям Windows… С ними все понятно, в сети доступно огромное количество материалов о настройке централизованного сбора событий с использованием Windows Event Forwarding. Многие гайды предлагают пошаговые инструкции с ответами на вопросы из серии «Сколько WEC (Windows Event Collector) нужно для парка в 4000 машин?».
Однако крайне мало внимания уделяется компьютерам на базе macOS. Причины очевидны: немногие организации сейчас готовы закупать «маки» для своих сотрудников. Это дорого, непонятно, как эти машины администрировать, возникает ворох проблем с совместимостью. Кроме того, на рынке доступно не так много специалистов, которые знают, как обуздать эту операционную систему и как обезопасить ее, ведь для macOS также существуют угрозы. Однако решение проблемы с мониторингом есть, и оно уже встроено в систему, начиная с версии 10.15 Catalina.
СПОСОБЫ МОНИТОРИНГА
Всего существует три способа мониторинга событий в macOS:- Коммерческий EDR.
- Osquery.
- Eslogger (ESF).
Ранее для мониторинга событий в macOS использовалась подсистема аудита OpenBSM. Она была разработана компанией McAfee Research по индивидуальному заказу Apple в 2004 году. Позднее исходный код передали в TrustedBSD для нужд комьюнити. Этот инструмент был убран из macOS в версии Big Sur и больше не поддерживается.
Endpoint Security Framework (ESF) — это нативный компонент macOS, который служит для проактивного поиска событий и реагирования на них. Инструмент позволяет подписываться на события Notification и Authorization. Принцип его работы можно сравнить с Event Tracing For Windows (ETW). Он позволяет просматривать низкоуровневые события, связанные с процессами, файлами, немного с сетью и памятью, а также много чего еще!
КАК ЭТО РАБОТАЕТ?
Раньше, если какая‑то компания бралась за разработку решения Endpoint Security, ей приходилось делать так называемое Kernel Extension (модуль для ядра). Примерами таких решений служат OpenBSM, Kauth KPI, MAC Framework. Решения на базе Kernel Extension было тяжело разрабатывать и поддерживать. Незначительные баги могли привести к kernel panic, а несовершенный код пробивал новые дырки в безопасности macOS.В Apple это прекрасно понимали и поэтому в 2019 году (лучше поздно, чем никогда) заменили Kernel Extensions, которые работали в пространстве ядра, System Extensions, которые работают в пользовательском пространстве. Теперь у разработчиков развязаны руки. Все стало гораздо удобнее.
Хотя Kernel Extensions уже устарели, они все еще могут использоваться в современных macOS — но с оговоркой, что профиль безопасности системы должен быть сильно снижен. Добиться этого бывает очень сложно, и обычно это делается исключительно в целях разработки. Если производители не заменят кексты системными расширениями, они могут поставить под угрозу безопасность систем своих клиентов.
Актуальная схема работы Endpoint Security
Существует два типа событий: Notification и Authorization. Они оба предоставляют одинаковую информацию, но между ними все же есть разница.- Notification — этот тип нужен для информирования об активности. Пример: запуск бинаря.
- Authorization — этот тип нужен для блокирования активности. Пример: при наступлении события ядро стучится в System Extension антивирусного ПО для проверки, можно ли запускать процесс. Если ответа нет, то процесс прибивается на месте, так и не запустившись в пользовательском пространстве.

Существует огромное количество событий, на которые можно подписаться, чтобы получать информацию о том, что происходит в системе в реальном времени.
На сайте для разработчиков Apple есть полный список событий с описанием, какую информацию содержит каждое из них.
RED CANARY MAC MONITOR
Одна из немногих компаний, которая занимается в том числе и безопасностью macOS, — Red Canary. В мае 2023 года она выпустила утилиту под названием Mac Monitor. Эта программа отлично подойдет для демонстрации того, как вообще выглядят события ESF и как с ними можно работать. Также она будет очень полезна тем, кто проводит live response в системе.В настройках можно установить фильтры и подписки на конкретные типы событий.

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

Тут мы можем увидеть события, которые относятся к главному событию.

А вот процесс‑инициализатор.

Событие запуска команды curl в сыром виде.

Загрузить утилиту можно по ссылке с GitHub.
Только для live response
Для реализации полноценного мониторинга Red Canary Mac Monitor нам не подойдет по следующим причинам:- Это приложение придется раскатывать по всем системам.
- Хакер может легко прибить этот процесс.
- Его, как приложение, проблематично замаскировать и поставить в бэкграунд.
- Утилита собирает далеко не все типы событий и многое упускает из виду.
НУ И КАК ЖЕ МОНИТОРИТЬ?
Перейдем к нативным средствам. Утилиты вроде Red Canary Mac Monitor используют Endpoint Security API и делают упор на визуализацию и красоту. Решение, которое мы запряжем в наш SOC, ориентируется на нативность, полноту и безопасность.Это eslogger, утилита командной строки, она предоставляет прямой доступ непосредственно к генерируемым ядром событиям и поставляется со всеми версиями macOS выше Ventura. Этакий поисковик среди событий.
Плюсы eslogger:
- уже есть на каждой macOS Ventura;
- не грузит систему при использовании;
- выдает лог в текстовом формате, а не бинарном;
- дает отличную видимость активности.
Код: Скопировать в буфер обмена
sudo eslogger --list-events
Эта команда выведет нам внушительный список. Приведу примеры:
Код: Скопировать в буфер обмена
Код:
НАЗВАНИЕ ПОЛНОЕ НАЗВАНИЕ ФУНКЦИИ
create es_event_create_t Создание файла
open es_event_open_t Открытие файла
write es_event_write_t Запись в файл
unlink es_event_unlink_t Удаление файла
utimes es_event_utimes_t Изменение параметров access time и modification time файла
exec es_event_exec_t Запуск процесса
uipc_connect es_event_uipc_connect_t Подключение через сокет
kextload es_event_kextload_t Загрузка Kernel Extension
btm_launch_item_add btm_launch_item_add Создание нового объекта входа (Launch Item)
ПРАКТИКА
Переведем наши упражнения в практическую плоскость и применим их для решения конкретной задачи. В директории Logs лежит файлxakep.ru-2023.log
. Туда записываются чрезвычайно важные данные.На компьютер Mac попал надоедливый вредоносный скрипт, который прописался как задача в
/Library/LaunchAgents/
и постоянно, каждые пять минут, удаляет лог, который лежит в директории Logs. Надоел уже!Файл задачи с расширением
.plist
выглядит так:Код: Скопировать в буфер обмена
Код:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.hacker.annoying.task</string>
<key>ProgramArguments</key>
<array>
<string>/bin/sh</string>
<string>/Users/tofolt/Downloads/DeleteLogFile.sh</string>
</array>
<key>StartInterval</key>
<integer>300</integer>
</dict>
</plist>
Код: Скопировать в буфер обмена
rm -f "/Users/tofolt/Logs/xakep.ru-2023.log"
Чтобы отловить этот скрипт, нам понадобится следующая команда eslogger:
Код: Скопировать в буфер обмена
sudo eslogger exec open unlink btm_launch_item_add >> result.json
Предположим, что у нас уже писались логи в момент заражения. Нам не составит труда найти событие добавления скрипта в автозапуск. Большая часть события была отброшена, оставлены только главные строки. В оригинальных событиях много информативных полей, в том числе и очень полезных для связывания событий друг с другом (btm_launch_item_add):
Код: Скопировать в буфер обмена
Код:
{
"event": {
"btm_launch_item_add": {
"executable_path": "/bin/sh",
"instigator": {
"signing_id": "com.apple.xpc.smd",
"ppid": 1,
"tty": null,
"start_time": "2023-07-09T10:17:55.546995Z",
},
"item": {
"item_url": "file:///Library/LaunchAgents/com.hacker.annoying.task.plist",
}
}
},
"time": "2023-07-09T14:08:03.326637707Z",
}
Код: Скопировать в буфер обмена
Код:
{
"event": {
"exec": {
"script": {
"path": "/Users/tofolt/Downloads/DeleteLogFile.sh",
},
"executable": {
"path": "/bin/sh",
},
"start_time": "2023-07-09T14:33:56.804354Z",
"is_platform_binary": true,
"group_id": 22017,
"audit_token": {
"asid": 100005,
"pidversion": 49567,
"ruid": 503,
"euid": 503,
"rgid": 20,
"auid": 503,
"egid": 20,
"pid": 22017
},
},
"args": [
"/bin/sh",
"/Users/tofolt/Downloads/DeleteLogFile.sh"
],
},
"time": "2023-07-09T14:33:56.814464013Z",
"action": {
"result": {
"result": {
"auth": 0
},
"result_type": 0
}
}
Код: Скопировать в буфер обмена
Код:
{
"event": {
"unlink": {
"target": {
"path": "/Users/tofolt/Logs/xakep.ru-2023.log",
},
"parent_dir": {
"path": "/Users/tofolt/Logs",
}
}
},
"time": "2023-07-09T14:34:57.713064962Z",
"executable": {
"path": "/bin/rm",
},
"ppid": 22069,
},
"start_time": "2023-07-09T14:34:57.704093Z",
}
KILL THEM ALL
Как обезопаситься от того, что хакер просто прибьет процесс eslogger командой kill?Например, можно создать новую учетку на компьютере и назвать ее с нижним подчеркиванием _brew, добавить привилегии, чтобы обычный пользователь не мог прибить процессы, запущенные от ее имени. Ожидается, что хакер, когда захочет узнать всех пользователей в системе, отфильтрует вывод, убирая записи с нижними подчеркиваниями, потому что так называются системные учетки для внутреннего функционирования системы. А даже если он выведет все учетные записи, _brew замаскируется под пакетный менеджер, который стоит почти на каждом «маке» программиста. Таким образом мы и защитимся от команды kill.
Ну или второй вариант — назвать _ftp_server. Это объяснит столь высокие системные полномочия у учетки.
ИСПОЛЬЗОВАНИЕ В ИНФРАСТРУКТУРЕ
Как все это разворачивать?Конкретную пошаговую инструкцию выдать не получится просто потому, что у всех разные инфраструктуры и очень по‑разному администрируются «маки», но подкинуть пару идей я могу.
- У тебя наверняка есть ПО для управления Mac по типу Jamf Pro. Ты можешь создать запланированную задачу, запускающую скрипт пересылки данных из файла собранных логов.
- Если у тебя есть какой‑то агент на компьютерах, то проверь, не может ли он собирать дополнительно и файл логов.
- Обязательно нужно настроить ротацию файла с логом, чтобы после пересылки, например, в SIEM, он чистился, иначе он может довольно быстро вырасти до существенных размеров.
Какова нагрузка на систему? Незначительная. Однако EPS может быть большим, если должным образом не настроить фильтрацию событий.
Напоминаю, что решение бесплатное и всех удобств «из коробки» не гарантирует. Фильтрация тут обязательна.
НОРМАЛИЗАЦИЯ И ФИЛЬТРАЦИЯ
Сразу уточню, что предложенный ниже вариант лишь вариация на тему «как это можно делать». Итак, для нормализации будем использовать инструмент под названием fx. Для фильтрации возьмем другой инструмент — jq.Приведем JSON в нормальный вид с помощью скрипта на Python 3:
Код: Скопировать в буфер обмена
Код:
import sys
out: str = "["
lines = sys.stdin.readlines()
for index, line in enumerate(lines):
if index == len(lines)-1:
out += "{}".format(line)
else:
out += "{}{}".format(line, ",")
out += "]"
print(out)
Код: Скопировать в буфер обмена
cat eslogger_output.json | ./normalizer.py | fx . > better_eslogger_output.json
Нормализованный файл теперь необходимо отфильтровать. Я, например, исключу все события, связанные с процессом Finder:
Код: Скопировать в буфер обмена
cat better_eslogger_output.json | jq '[.[] | select(.process.signing_id == "com.apple.finder" )]' > eslogger_final.json
Подскажу пути, которые можно (точно так же, как и Finder) исключить из захвата через eslogger, чтобы не создавать мусор. Многие из путей могут показаться важными для мониторинга. Однако в 2015 году Apple добавила механизм System Integrity Protection (SIP), а позже, в 2019-м, разделила диск на защищенный и незащищенный разделы. SIP предохраняет системные критически важные директории от вмешательства, и поэтому злоумышленник не сможет ничего изменить в них, если только ты не отключил SIP вручную. Поэтому и мониторить их не нужно. Найти список путей для исключения можно в моем репозитории.
ВЫВОДЫ
Мы рассмотрели работу ESF, узнали о решениях, которые дают доступ к низкоуровневым событиям в системе, а также об особенностях работы с ними. Хоть утилита eslogger и классная, но она не лишена недостатков. Приходится применять заплатки, чтобы это заработало в масштабах SOC, но зато eslogger не требует денег и не уступает в 90% случаев коммерческим EDR-решениям (видимость сетевых подключений там, конечно, гораздо лучше).Автор Михаил Онищенко aka tofolt
источник xakep.ru