Статья Форензика macOS: артефакты, которые сдают пентестера — Unified Log, FSEvents, Spotlight, Keychain и APFS-снапшоты

SOC-аналитик поднимает алерт: процесс security на MacBook финансового директора обращается к Keychain с нетипичным PPID. Позже на столе полный таймлайн - PID, родительская цепочка, список файловых операций за 72 часа и три APFS-снапшота, в которых сохранились файлы, удалённые атакующим. Источник - штатные механизмы macOS, без единого стороннего агента.

Этот кейс с внутреннего пентеста разрушил мне один устойчивый миф: Mac-флот - слепое пятно для SOC. Нет. macOS пишет на тебя досье с наносекундной точностью, просто большинство blue team об этом не знает (а red team - надеется, что не знает).

С ростом корпоративных Mac-парков и оборотных штрафов за утечки ПДн, которые требуют доказательной базы, навык цифровой криминалистики macOS перестаёт быть нишевым. Он нужен и при реагировании на внешние атаки, и при расследовании insider threat. Ниже - разбор каждого источника артефактов macOS с двух сторон: что оставляет атакующий и как это находит аналитик.

Unified Log macOS: центральный источник следов​

Unified Log - единая система логирования macOS, работающая с версии 10.12 (Sierra). Данные живут в /var/db/diagnostics/ и /var/db/uuidtext/ в формате tracev3. Консолидирует записи ядра, системных демонов и приложений с наносекундными метками времени.

По MITRE ATT&CK здесь пересекаются две техники: атакующий изучает логи для понимания среды - Log Enumeration (T1654, Discovery; техника описана для Windows, macOS и GNU/Linux, но публичные тесты Atomic Red Team пока существуют только для Windows), а затем пытается зачистить следы - Clear Linux or Mac System Logs (T1685.006, Defense Evasion).

Что фиксирует Unified Log:

• Запуск и завершение процессов с полным путём бинаря и аргументами командной строки
• Сетевые соединения через subsystem com.apple.network
• Аутентификацию и авторизацию (subsystem com.apple.Authorization)
• Обращения к Keychain (subsystem com.apple.securityd)
• Монтирование внешних устройств и образов

Что ищет аналитик в потоке Unified Log​

Основной инструмент - log show с предикатными фильтрами. Для incident response на macOS это аналог Get-WinEvent в Windows, только мощнее (и неудобнее - привыкайте).

# Обращения к Keychain за последние 24 часа
log show --predicate 'subsystem == "com.apple.securityd"' --last 24h --style compact
# Запуск LaunchAgents/LaunchDaemons через launchd (НЕ ловит произвольные exec - только managed jobs)
# Для полного process execution telemetry нужен ESF-клиент (EDR или собственный)
log show --predicate 'subsystem == "com.apple.xpc.launchd" AND eventMessage CONTAINS "spawned"' --last 48h

Требования к окружению: macOS 10.12+, права администратора для полного доступа к /var/db/diagnostics/. На forensic-образе - монтирование и парсинг через log collect или mac_apt / Axiom.

Ограничения: retention по умолчанию - от нескольких дней до двух недель в зависимости от уровня лога (Default, Info, Debug). Debug-записи могут жить часы. CrowdStrike Falcon for Mac и SentinelOne macOS agent перехватывают часть событий через Endpoint Security Framework (ESF), но не дублируют весь Unified Log. Прямой доступ к /var/db/diagnostics/ остаётся необходимым для полноты картины при IR.

Для SOC: настройте форвардинг subsystem com.apple.securityd и com.apple.Authorization в SIEM. Это даёт видимость обращений к секретам и повышения привилегий без зависимости от EDR-агента. На практике - именно эти два subsystem закрывают 80% вопросов при разборе инцидента.

FSEvents: форензика файловых операций​

FSEvents - механизм macOS для отслеживания изменений файловой системы. Записи хранятся в скрытой директории /.fseventsd/ на каждом томе. Каждый файл внутри - gzip-сжатый бинарный лог операций: создание, удаление, переименование, изменение атрибутов.

MITRE ATT&CK: FSEvents фиксирует активность, релевантную для File and Directory Discovery (T1083, Discovery) и Hidden Files and Directories (T1564.001, Defense Evasion). Создал скрытую директорию с точкой в имени или разместил payload в /tmp - FSEvents это записал. Без вариантов.

Форматы DLS и инструменты парсинга​

Формат записей FSEvents менялся вместе с файловой системой:

• DLSv1 - HFS+, старые релизы macOS
• DLSv2 - появился с переходом на APFS (macOS 10.13 High Sierra), текущий формат на современных Mac

(Классификация версий DLS в публичных источниках неоднозначна - FSEventsParser и mac_apt поддерживают актуальные варианты формата, так что на практике проблем нет.)

Инструменты парсинга:

• FSEventsParser (Nicole Ibrahim) - Python-скрипт, поддерживает DLSv1/v2/v3, вывод в CSV/SQLite
• fsevents_dump - утилита для быстрого дампа с фильтрацией по пути и временному диапазону
• mac_apt (ydkhatri/mac_apt) - начиная с релизов 2020+ поддерживает DLSv3; берите последнюю стабильную версию из репозитория

Что FSEvents даёт аналитику при расследовании:

• Полный путь к созданным и удалённым файлам, включая /tmp и /var/folders/
• Хронологию операций с payload атакующего - даже после удаления файла
• Цепочку действий: скачал, распаковал, переместил, удалил оригинал

Ограничения: FSEvents не хранит содержимое файлов - только факт операции и путь. Retention зависит от объёма дисковых операций: на активной системе логи перезаписываются за дни, на малоактивной - живут месяцами.

Insider threat: FSEvents особенно ценен при расследовании утечек - видно, когда сотрудник копировал файлы на внешний носитель или в облачную директорию, даже если файлы потом были удалены. Для red team это значит одно: каждое cp в /Volumes/USB_DRIVE/ оставляет след, который переживёт сам файл.

Spotlight: метаданные, пережившие удаление файлов​

Spotlight - поисковый индексатор macOS. Хранит метаданные проиндексированных файлов в /Volumes/<DriveName>/.Spotlight-V100/. Ключевой форензик-артефакт - store.db: имена файлов, даты создания и изменения, тип контента, фрагменты текстового содержимого.

Критическое различие, которое стоит зафиксировать:

• mdfind (штатная CLI-команда Spotlight) показывает только текущие записи индекса - файлы, которые существуют на диске прямо сейчас
• Для извлечения метаданных удалённых файлов нужен offline-парсинг store.db через spotlight_parser (ydkhatri) - инструмент достаёт записи, которые Spotlight ещё не вычистил из базы

Разница между ними - как между dir и восстановлением из теневой копии. Первое показывает что есть, второе - что было.

MITRE ATT&CK: Spotlight как артефакт релевантен для Data from Local System (T1005, Collection) - атакующий использует mdfind для поиска файлов с паролями, SSH-ключей, конфигураций, и эти запросы оставляют следы в Unified Log.

Что даёт offline-парсинг store.db​

Через spotlight_parser аналитик извлекает:

• Записи о файлах, которых уже нет на диске
• Метаданные: kMDItemFSCreationDate, kMDItemContentType, kMDItemFSSize
• Для документов - kMDItemTextContent (фрагменты текстового содержимого)
• Для скачанных файлов - kMDItemWhereFroms (URL источника загрузки)

kMDItemWhereFroms - находка при IR: если payload скачан через Safari или curl, Spotlight-метаданные могут сохранить URL C2-сервера. Я видел случай, когда атакующий подчистил историю браузера и bash_history, но URL стейджера остался в store.db. Классика.

Ограничения: индексация зависит от mdutil. Команда mdutil -i off / отключает индексацию тома. Но уже накопленные записи в store.db остаются до физической перезаписи.

Anti-forensics detection: мониторьте вызовы mdutil -i off и mdutil -E (стирание индекса) в Unified Log - явный индикатор зачистки следов. В корпоративной среде легитимных причин отключать Spotlight нет. Если прилетает такой алерт - кто-то заметает следы.

Keychain: форензика доступа к секретам macOS​

Keychain - системное хранилище паролей, сертификатов, токенов Wi-Fi и ключей шифрования. Пользовательский Keychain: ~/Library/Keychains/login.keychain-db. Системный: /Library/Keychains/System.keychain.

MITRE ATT&CK: T1555.001 (Keychain). Техника специфична для macOS - атакующий извлекает сохранённые учётные данные из Keychain.

Стандартный вектор - утилита security из состава macOS:

# Дамп generic-паролей (с -d запрашивает GUI-промпт Allow на КАЖДЫЙ элемент - десятки диалогов)
# Для скрытного offline-анализа используют chainbreaker (n0fate)
security dump-keychain -d ~/Library/Keychains/login.keychain-db
# Извлечение пароля Wi-Fi по имени сети
security find-generic-password -ga "CorpWiFi_5G" 2>&1 | grep password

Detection: мониторинг обращений к Keychain​

Что фиксируется при работе с Keychain:

• Unified Log записывает вызовы к securityd с PID и PPID процесса
• Запрос на разблокировку генерирует системный диалог, и факт запроса логируется
• Системный Keychain требует root-прав для модификации; обращения к нему через securityd логируются в Unified Log

Insider threat: при расследовании инсайдерских инцидентов Keychain-артефакты показывают, к каким ресурсам сотрудник имел сохранённые пароли - VPN-подключения, внутренние веб-сервисы, Wi-Fi-сети. По данным Magnet Forensics, извлечение и анализ Keychain - один из ключевых этапов insider investigation на macOS.

Ограничение для SOC: если атакующий имеет активную сессию пользователя с разблокированным Keychain, пароли извлекаются без дополнительных промптов. CrowdStrike Falcon for Mac и SentinelOne macOS agent детектируют массовый дамп Keychain, но точечное извлечение одного-двух паролей может пройти ниже порога алерта. Это тот случай, когда EDR видит взрыв, но не замечает тихий выстрел.

Detection-правило: алертите на security dump-keychain и security find-generic-password через форвардинг Unified Log subsystem com.apple.securityd. Коррелируйте с PPID - легитимное использование идёт от Finder или Safari, не от Terminal/iTerm/python/osascript.

Для Red Team: T1555.001 - техника, где минимизация следов macOS практически невозможна. Любое обращение к securityd логируется. Даже использование API SecItemCopyMatching из собственного бинаря вместо CLI оставляет trace в Unified Log. По документации Apple - обращения к Keychain анонимны. На практике - каждое залогировано с PID.

APFS-снапшоты: артефакты, которые нельзя подчистить​

APFS использует copy-on-write архитектуру. Снапшоты - point-in-time состояния тома: файлы, метаданные, структура каталогов. macOS создаёт их автоматически.

MITRE ATT&CK: попытка удаления снапшотов - Inhibit System Recovery (T1490, Impact). Вызов tmutil deletelocalsnapshots на корпоративном Mac с MDM-политиками - основание для немедленной эскалации.

Локальные снапшоты Time Machine как форензический таймлайн​

Когда диск Time Machine не подключён, macOS создаёт локальные снапшоты на внутреннем накопителе. Пользователь о них не знает - и атакующий часто тоже. Вот это и бьёт.

Что это означает для IR:

• Файл, удалённый с live-системы, может сохраниться в одном или нескольких локальных снапшотах
• Документ с модификациями имеет предыдущие версии в снапшотах
• Активность, зачищенная из текущего состояния файловой системы, может быть восстановлена

# Список локальных снапшотов с датами
tmutil listlocalsnapshots /
# Монтирование снапшота read-only для анализа (macOS 10.15+, требует root)
# Сначала определите device node Data-тома: diskutil apfs list
mount_apfs -o nobrowse -s com.apple.TimeMachine.2025-01-15-091500.local /dev/disk<N>s<M> /tmp/snapshot_mnt

Требования к окружению: macOS 10.13+ (APFS), root-доступ для монтирования. Анализ снапшотов лучше проводить на этапе acquisition, а не после. Как подчёркивает SUMURI в исследовании APFS-снапшотов: подход "снять образ, потом разбираться" для APFS неэффективен - требуется реконструкция контекста, который при нативном подходе доступен сразу.

Ограничения: количество и глубина снапшотов зависят от свободного места - macOS автоматически удаляет старые при нехватке пространства. Атакующий с root-доступом может удалить снапшоты через tmutil deletelocalsnapshots, но факт удаления фиксируется в Unified Log. Удалил снапшот - создал алерт. Не удалил - оставил улику. Выбирай.

Detection-чеклист: корреляция артефактов macOS в SOC​

Готовый чеклист для настройки мониторинга Mac-флота - забирайте и адаптируйте под свой стек.

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

macOS фиксирует атакующего плотнее, чем принято думать. Unified Log с наносекундной точностью, FSEvents с историей каждой файловой операции, Spotlight с метаданными файлов, которых уже нет на диске, securityd-логи обращений к Keychain и APFS-снапшоты с состояниями, которые атакующий считал стёртыми - всё это работает против Red Team по умолчанию.

Настоящая проблема в другом: большинство SOC-команд эти артефакты не собирают. Mac-флот висит на EDR, который покрывает часть событий, а Unified Log subsystem, FSEvents, Spotlight - не форвардятся в SIEM. Я видел компании с сотнями MacBook, где при инциденте аналитик открывал Console.app и вручную листал логи. В 2025 году.

Чеклист выше - отправная точка, а не финальная конфигурация. Адаптируйте под свой стек и проверьте на реальном алерте. Возьмите любой Mac из парка, запустите security find-generic-password -ga "WiFi_Name" и посмотрите, прилетит ли алерт в SIEM. Если нет - у вас та же проблема. Если хотите сверить подход к сбору macOS-артефактов с опытом других IR-команд - на codeby.net коллеги разбирают конкретные кейсы с Mac-артефактами и делятся конфигурациями форвардинга под разные SIEM-стеки.