Понедельник, 9:15. SOC получает DLP-алерт: менеджер отдела продаж экспортировал клиентскую базу CRM в CSV и отправил архив на личную почту. Заявление об увольнении подано в пятницу. DLP зафиксировал отправку письма - финальное звено цепочки. А на рабочей станции уже лежат артефакты двухнедельной подготовки: история подключений USB-накопителей, следы массового копирования файлов, автоматический форвард корпоративной почты на внешний ящик. Всё это нужно изъять и задокументировать до переустановки ОС.
По данным опроса Anti-Malware.ru, 54% организаций сталкиваются с утечками через почту, мессенджеры и облака, а 41% фиксируют саботаж перед увольнением. С учётом оборотных штрафов за утечку персональных данных по ФЗ-152 стоимость незафиксированного инцидента может исчисляться десятками миллионов рублей. И чем слабее доказательная база - тем выше потери. Финансовые и юридические.
Три фазы инсайдерской операции и маппинг на MITRE ATT&CK
Инсайдер редко действует спонтанно. Типичная операция по выносу данных укладывается в три фазы, каждая оставляет характерные артефакты. Задача цифровой криминалистики при расследовании инсайдерских инцидентов - пройти по этой цепочке в обратном порядке.Фаза 1 - сбор и промежуточное хранение (Collection). Сотрудник начинает аккумулировать данные: экспортирует отчёты из CRM, копирует файлы из сетевых шар в локальную папку, собирает вложения из корпоративной почты. По MITRE ATT&CK это Local Data Staging (T1074.001), Local Email Collection (T1114.001) и Data from Removable Media (T1025). На этом этапе объём файловых операций растёт, появляются нехарактерные обращения к папкам вне должностных обязанностей. Поведенческий анализ UEBA может зафиксировать аномалию - если baseline установлен корректно (NIST CSF DE.AE-01).
Фаза 2 - вынос данных (Exfiltration). Собранное покидает периметр: копируется на USB-накопитель (T1052.001), загружается в личное облако (T1567.002), пересылается через настроенное правило форварда - Email Forwarding Rule (T1114.003). Последняя техника описана MITRE для облачных почтовых платформ (Office 365, Google Workspace), тесты Atomic Red Team существуют только для Office 365, но артефакты правил обнаруживаются и в on-premise Exchange. Именно здесь чаще всего срабатывает DLP. Проблема в том, что к этому моменту часть данных уже могла уйти другими каналами.
Фаза 3 - заметание следов (Defense Evasion). Подготовленный инсайдер пытается уничтожить улики: меняет временные метки файлов - Timestomp (T1070.006), очищает журналы событий, удаляет историю PowerShell. Для компьютерной форензики эта фаза наиболее критична: если артефакты антифорензики не распознать, расследование теряет доказательную базу.
Форензика рабочей станции: артефакты Windows при расследовании инсайдерских угроз
Требования к окружению для расследования
Прежде чем лезть в образ - подготовьте станцию аналитика и инструментарий:- ОС аналитика: Windows 10/11 или Linux (Ubuntu 22.04+)
- RAM: минимум 16 ГБ, рекомендуется 32 ГБ для timeline-анализа крупных образов
- Диск: SSD с двукратным запасом от размера исследуемого образа
- Снятие образа: FTK Imager (бесплатный, Exterro) или
dd(Linux) - Парсинг артефактов: Eric Zimmerman's Tools (EZTools - свободно распространяемый набор; версии 2.0+ на .NET 6 доступны для Linux/macOS, но GUI-утилиты ShellBagsExplorer и TimelineExplorer остаются Windows-only)
- Анализ образа: Autopsy (open source, активно поддерживается)
- Удалённый сбор: Velociraptor (open source, поддерживает hunt-запросы на парке машин)
- Суперхронология: Plaso/log2timeline (open source)
- Сеть: offline-режим допустим для всех инструментов, кроме Velociraptor (требует агента на целевой машине)
После получения образа - разбор ключевых артефактов.
Prefetch-файлы (
C:\Windows\Prefetch\*.pf) фиксируют факт запуска программ с точностью до секунды. В формате Prefetch v30 (начиная с Windows 8) хранятся 8 последних временных меток запуска и счётчик запусков. Если инсайдер использовал 7z.exe для архивации данных перед выносом - Prefetch покажет когда именно и сколько раз. PECmd.exe из EZTools парсит Prefetch в CSV за секунды.LNK-файлы (ярлыки) создаются автоматически при открытии файлов через проводник. Хранят полный путь к файлу, включая букву диска USB-накопителя, серийный номер тома и MAC-время создания. Файл удалён с флешки - а LNK-файл спокойно лежит в
%AppData%\Microsoft\Windows\Recent\. Парсинг - LECmd.exe.ShellBags - записи в реестре (
NTUSER.DAT и UsrClass.dat), фиксирующие каждую папку, которую пользователь открывал в проводнике. Включая папки на внешних носителях и сетевых шарах. Удаление папки или отключение USB не удаляет запись ShellBags - Windows так не работает. ShellBagsExplorer покажет полное дерево навигации с временными метками.USN Journal (
$UsnJrnl:$J) - журнал изменений NTFS, фиксирующий создание, переименование и удаление файлов с наносекундной точностью. При расследовании утечки данных USN Journal показывает массовое создание файлов в одной папке (staging-директория) или массовое удаление после копирования. Парсинг через MFTECmd.exe.Jump Lists - списки последних документов для каждого приложения. Если инсайдер открывал файлы через Excel или Word, Jump Lists покажут полные пути, включая UNC-пути к сетевым ресурсам.
Все эти артефакты объединяются в суперхронологию через Plaso/log2timeline: один таймлайн из десятков источников. По нему видна полная картина действий пользователя - по минутам.
Анализ USB-активности при расследовании утечек
USB-артефакты - одни из самых информативных при расследовании инсайдерских инцидентов. Windows фиксирует подключение каждого USB-устройства в нескольких независимых местах, и инсайдеру крайне сложно вычистить все следы одновременно.Реестр USBSTOR. Ветка
HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR содержит записи о каждом когда-либо подключённом USB-накопителе: производитель, модель, серийный номер, метка тома. Серийный номер позволяет однозначно идентифицировать конкретную флешку. Если в ходе расследования удастся изъять носитель - его серийник сопоставляется с записью в реестре:
Код:
reg query HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR /sNTUSER.DAT пользователя (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2) показывает, какие тома монтировались конкретным пользователем, с привязкой GUID тома к букве диска. Если на машине работают несколько сотрудников - MountPoints2 привязывает USB к конкретному аккаунту.setupapi.dev.log (
C:\Windows\INF\setupapi.dev.log) содержит timestamp первого подключения USB-устройства к системе. Флешка впервые подключена за день до увольнения? Это существенный индикатор в контексте расследования утечки информации сотрудником.Корреляция с Event Log. Windows фиксирует подключение устройств в нескольких журналах:
Microsoft-Windows-Kernel-PnP/Configuration, Microsoft-Windows-Partition/Diagnostic (Event ID 1006 - VBR, серийный номер), Security Event ID 6416 (A new external device was recognized by the System). Последний требует включения подкатегории Audit PNP Activity в Advanced Audit Policy - по умолчанию отключена.Журнал
Microsoft-Windows-DriverFrameworks-UserMode/Operational по умолчанию отключён в Windows 10/11 и требует ручного включения. Без этого он будет пуст.Для отслеживания файловых операций на USB нужна предварительно настроенная политика аудита Object Access: Event ID 4663 фиксирует попытки доступа к объектам, Event ID 4660 - факт удаления. Оба события требуют включения аудита Delete в SACL объекта. Без предварительной настройки этих политик данные просто не генерируются. И это основная проблема, с которой DFIR-команды сталкиваются постфактум. Приходишь расследовать - а логов нет.
Печать как канал утечки. Про этот вектор часто забывают. Инсайдер может распечатать конфиденциальные документы и унести их физически. Windows хранит данные о заданиях печати в
C:\Windows\System32\spool: файлы .SPL содержат данные печати, .SHD - метаданные с именем документа, аккаунтом и настройками. После завершения задания файлы удаляются, но восстанавливаются методами file carving из образа диска. В Event Log раздел Microsoft-Windows-PrintService/Operational фиксирует Event ID 307 (документ распечатан) и Event ID 800 (документ помещён в очередь). Канал PrintService/Operational тоже по умолчанию отключён.Email-форензика и форензика облачных хранилищ при инсайдерских утечках
Email: локальный сбор и правила форварда
Два вектора утечки через email по MITRE ATT&CK требуют разного подхода к расследованию.Local Email Collection (T1114.001) - инсайдер экспортирует почтовый ящик целиком. На диске ищите файлы
.pst и .ost (Outlook), обращая внимание на нестандартные расположения: PST-файл на рабочем столе или в папке Downloads - почти наверняка ручной экспорт. Метаданные файла из USN Journal и $MFT покажут точную дату создания.Email Forwarding Rule (T1114.003) - более скрытный вектор анализа email при инцидентах. Инсайдер создаёт правило автоматической пересылки входящей почты на внешний адрес. Проверка в Exchange / Microsoft 365:
Код:
Get-InboxRule -Mailbox user@company.com |
Where-Object {$_.ForwardTo -or $_.ForwardAsAttachmentTo} |
Select-Object Name, ForwardTo, Enabledgmail.com, yandex.ru, mail.ru - личные ящики сотрудника. В Exchange Admin Audit Log фиксируется создание правила с timestamp и IP-адресом.Облачные хранилища: артефакты sync-клиентов
Утечка через облачные хранилища - Data from Cloud Storage (T1530) и Exfiltration to Cloud Storage (T1567.002) - оставляет следы и в клиентских приложениях, и в браузере.OneDrive: логи синхронизации в
%LocalAppData%\Microsoft\OneDrive\logs\. Файлы SyncDiagnostics.log и база SyncEngine содержат записи о загруженных файлах с путями и временными метками.Google Drive / Dropbox: оба клиента используют локальные SQLite-базы для кэширования метаданных. Dropbox хранит
filecache.dbx в %AppData%\Dropbox\, Google Drive - базы в %LocalAppData%\Google\DriveFS\.Браузерная история как дополнительный источник для форензики облачных хранилищ. Если инсайдер использовал веб-версию хранилища без установки клиента - следы остаются в браузере. Firefox хранит историю в
places.sqlite по пути C:\Users\<Username>\AppData\Roaming\Mozilla\Firefox\Profiles\<Profile Name>\, Edge - в C:\Users\<Username>\AppData\Local\Microsoft\Edge\User Data\Default\. Базы SQLite открываются через DB Browser for SQLite и содержат URL облачных хранилищ с временными метками посещений.Для полноты картины запросите у администратора облачного сервиса аудит-лог: Microsoft 365 Compliance Center, Google Workspace Admin Console или Dropbox Business Admin покажут, какие файлы загружались и к каким предоставлялся доступ. В рамках insider threat forensics это необходимый элемент доказательной базы.
Обнаружение антифорензики при расследовании инсайдерских инцидентов
Подготовленный инсайдер попытается уничтожить следы. Но вот в чём штука: сам факт антифорензики - мощное доказательство умысла. Задача DFIR-аналитика - его распознать.Timestomp (T1070.006). Инсайдер меняет временные метки файлов, чтобы скрыть факт их недавнего создания. Ключевой индикатор: NTFS хранит метки с точностью до 100 наносекунд. Файл с подозрительно «круглой» меткой вроде
2023-10-10 10:10:00.000:0000 - явный признак timestomping, потому что такая точность при обычной работе крайне маловероятна. Дополнительно сопоставляйте атрибуты $STANDARD_INFORMATION и $FILE_NAME в $MFT: при timestomping обычно меняется только $SI, а $FN сохраняет реальную дату. Это ловушка, в которую инсайдеры попадают регулярно.Очистка журналов событий. Event ID 1102 фиксирует факт очистки Security Event Log и содержит SID, имя и домен аккаунта, выполнившего очистку. Этот аккаунт - рядовой менеджер, а не администратор? Однозначный красный флаг.
Удаление истории PowerShell. Файл
ConsoleHost_history.txt по пути C:\Users\%username%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ автоматически записывает все команды PowerShell. Если файл отсутствует или его дата создания свежее первого логона пользователя - это указывает на удаление и автоматическое пересоздание системой. Попытка сокрытия выполненных команд.Удаление локального аккаунта. Event ID 4726 фиксирует удаление учётной записи Windows. Инсайдер может удалить аккаунт, чтобы уничтожить профиль вместе со всеми артефактами. Удаление без разумного обоснования - антифорензика.
Неожиданное выключение. Event ID 41 (Kernel-Power) регистрируется при следующей загрузке и указывает на некорректное завершение предыдущей сессии. Event ID 1074 - штатное выключение. Принудительное отключение питания уничтожает содержимое RAM (ключи шифрования, открытые документы, артефакты в памяти), делая memory acquisition невозможным. Event ID 41 может также указывать на BSOD, сбой питания или перегрев - антифорензикой это считается только в корреляции с другими индикаторами: timing относительно DLP-алерта, состояние BitLocker, наличие unsaved work.
Detection-чеклист: правила корреляции инсайдерских угроз для SIEM
Чеклист ниже - правила, которые можно реализовать в SIEM (MaxPatrol SIEM, KUMA, Splunk, Elastic SIEM) для раннего обнаружения инсайдерской активности. Каждое правило привязано к фазе атаки и конкретному источнику анализа журналов событий.Каждое правило при срабатывании должно генерировать incident в SIEM с автоматическим обогащением данных о пользователе: должность, дата приёма, наличие заявления об увольнении (интеграция с HR-системой), уровень доступа. Контекст HR-данных превращает технический алерт в actionable intelligence для DLP-расследования инцидентов.
Расследование инсайдерских инцидентов - область, где избыток доказательств лучше их недостатка. В большинстве кейсов, с которыми приходилось работать, расследование могло бы занять пару дней - если бы базовые политики аудита были настроены заранее. Вместо этого DFIR-команда тратила недели на восстановление данных, которые ОС давно перезаписала.
Непопулярная позиция: DLP без forensic readiness - иллюзия безопасности. DLP ловит финальное действие - отправку письма, копирование на флешку. Но если нет логов Object Access, нет истории USB-подключений, нет аудита Exchange Inbox Rules - доказать цепочку действий инсайдера в суде не получится. А без судебной перспективы сотрудник уходит с данными и без последствий.
Forensic readiness - это не покупка нового продукта. Это настройка того, что уже есть в Windows и Exchange: SACL на критичных папках, централизованный сбор Event Log через SIEM (чтобы инсайдер не мог удалить локальные логи), политика хранения логов минимум 180 дней, whitelist USB-устройств с блокировкой неизвестных.
Проверьте прямо сейчас: включён ли у вас аудит PNP Activity? Генерируются ли Event ID 4663 на папках с конфиденциальными данными? Если нет - у вас та же проблема, что и у 90% организаций, где мы видели инсайдерские кейсы. Если строите forensic readiness процесс или адаптируете аудитные политики под расследование инсайдерских кейсов - на codeby.net коллеги делятся конкретными конфигурациями и разбирают реальные кейсы в профильном треде.
