Отслеживаем системные события в macOS

D2

Администратор
Регистрация
19 Фев 2025
Сообщения
4,380
Реакции
0
Можно бесконечно наблюдать за тремя вещами: горящим огнем, текущей водой и событиями в операционной системе. И если в Windows средства мониторинга и журналирования уже хорошо изучены пользователями и системными администраторами, то в macOS с этим не все так просто. Сегодня мы поговорим о бесплатных инструментах отслеживания событий в «маке» и их практическом применении.

Как мы привыкли к событиям Windows… С ними все понятно, в сети доступно огромное количество материалов о настройке централизованного сбора событий с использованием Windows Event Forwarding. Многие гайды предлагают пошаговые инструкции с ответами на вопросы из серии «Сколько WEC (Windows Event Collector) нужно для парка в 4000 машин?».

Однако крайне мало внимания уделяется компьютерам на базе macOS. Причины очевидны: немногие организации сейчас готовы закупать «маки» для своих сотрудников. Это дорого, непонятно, как эти машины администрировать, возникает ворох проблем с совместимостью. Кроме того, на рынке доступно не так много специалистов, которые знают, как обуздать эту операционную систему и как обезопасить ее, ведь для macOS также существуют угрозы. Однако решение проблемы с мониторингом есть, и оно уже встроено в систему, начиная с версии 10.15 Catalina.

СПОСОБЫ МОНИТОРИНГА​

Всего существует три способа мониторинга событий в macOS:
  1. Коммерческий EDR.
  2. Osquery.
  3. 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 антивирусного ПО для проверки, можно ли запускать процесс. Если ответа нет, то процесс прибивается на месте, так и не запустившись в пользовательском пространстве.
Схема работы Endpoint Security


Существует огромное количество событий, на которые можно подписаться, чтобы получать информацию о том, что происходит в системе в реальном времени.

На сайте для разработчиков Apple есть полный список событий с описанием, какую информацию содержит каждое из них.

RED CANARY MAC MONITOR​

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

В настройках можно установить фильтры и подписки на конкретные типы событий.

Mac Monitor


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

2.png


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

3.png


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

4.png


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

5.png


Загрузить утилиту можно по ссылке с GitHub.

Только для live response​

Для реализации полноценного мониторинга Red Canary Mac Monitor нам не подойдет по следующим причинам:
  1. Это приложение придется раскатывать по всем системам.
  2. Хакер может легко прибить этот процесс.
  3. Его, как приложение, проблематично замаскировать и поставить в бэкграунд.
  4. Утилита собирает далеко не все типы событий и многое упускает из виду.
Следующий инструмент — хорошая бесплатная альтернатива вендорскому EDR. Скажу по секрету, коммерческие EDR под капотом поголовно используют ESF.

НУ И КАК ЖЕ МОНИТОРИТЬ?​

Перейдем к нативным средствам. Утилиты вроде 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",
}
Далее мы найдем момент запуска скрипта (exec):
Код: Скопировать в буфер обмена
Код:
{
  "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
    }
  }
Финальный аккорд. Событие удаления файла xakep.ru-2023.log (unlink).
Код: Скопировать в буфер обмена
Код:
{
  "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. Это объяснит столь высокие системные полномочия у учетки.

ИСПОЛЬЗОВАНИЕ В ИНФРАСТРУКТУРЕ​

Как все это разворачивать?

Конкретную пошаговую инструкцию выдать не получится просто потому, что у всех разные инфраструктуры и очень по‑разному администрируются «маки», но подкинуть пару идей я могу.
  1. У тебя наверняка есть ПО для управления Mac по типу Jamf Pro. Ты можешь создать запланированную задачу, запускающую скрипт пересылки данных из файла собранных логов.
  2. Если у тебя есть какой‑то агент на компьютерах, то проверь, не может ли он собирать дополнительно и файл логов.
  3. Обязательно нужно настроить ротацию файла с логом, чтобы после пересылки, например, в SIEM, он чистился, иначе он может довольно быстро вырасти до существенных размеров.
В eslogger может возникнуть проблема бутылочного горлышка, если подписать инструмент на слишком большое количество событий. Все они просто не будут успевать сохраняться в журнал. В интернете описывают эту проблему и рассказывают, как ее лечить.

Какова нагрузка на систему? Незначительная. Однако 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
 
Сверху Снизу