Условия и область наблюдения
Уточните, какой агент наблюдал путь и когда этот путь был включён в контроль. Разделите удаление отдельного файла, замену при обновлении и действие над каталогом: рабочая зацепка может описывать их одним словом «пропал». Сохраните alert и фактический режим FIM на момент события. Для who-data требуется доступный системный механизм аудита; отсутствие таких полей в обычном alert нельзя компенсировать догадкой. Зафиксируйте версии агента, manager, ОС и ruleset. Поддержка конкретной сборки этой инструкцией не подтверждена, настройки здесь не изменяются.
Как получить выборку
Фильтр jq читает прямую JSONL-форму manager alerts.json и выбирает deleted-события заданного агента. Сначала просмотрите доступные пути, затем уточните нужный объект и период. Для Windows учитывайте фактическую форму разделителей и регистра в полученном экспорте; не переносите текст из заявки без сверки. В индексном экспорте объект может находиться в _source, поэтому адаптацию оболочки необходимо выполнить явно. Сохраните строку до любых преобразований. Совпадение только по номеру правила недостаточно, если в организации настроены дочерние правила или менялся ruleset.
Чтение примера
В иллюстрации удалён учебный c:\lab\demo.txt на агенте hids-win-lab. Режим whodata добавляет explorer.exe и учётную запись analyst.demo в контекст. Это синтетическая запись, а не наблюдение реального пользователя. Отдельно сохраняйте путь удалённого объекта, имя процесса и пользователя: это разные сущности. Если в полном deleted-alert присутствуют атрибуты с суффиксом after, их нельзя автоматически считать доказательством существования файла после удаления. Смысл таких полей нужно сопоставить с типом события и формой экспорта конкретного релиза.
Интерпретация и альтернативы
Минимальный подтверждённый вывод относится к удалению контролируемого пути в наблюдаемой системе. Он не определяет, сохранились ли копии, остался ли объект в резервной копии, можно ли его восстановить и зачем выполнена операция. Удаление может сопровождать штатное развёртывание или ротацию, а может требовать расследования; версию выбирают по контексту, а не по severity алерта. Проверьте ожидаемый жизненный цикл объекта, согласованные изменения и роль узла. Учётная запись из who-data не исключает автоматизированное действие от её имени и не подтверждает физическое присутствие конкретного человека.
Следующий шаг
Свяжите процесс с записью запуска на том же устройстве и в подходящий момент. Сверьте полный путь, параметры и родительский контекст; один PID может использоваться повторно. Если нужно оценить потерю данных, обратитесь к владельцу приложения и каталогу резервных копий, сохранив отдельно факт удаления и доступность восстановления. Для массовых изменений расширьте обзор на соседние пути и агенты обоснованно, не объединяя разные устройства только по имени файла. Итог должен содержать подтверждённые объекты, известный контекст исполнителя и оставшиеся вопросы, а не автоматический диагноз «удаление следов».
Если записи нет или нет автора
Проверьте охват пути, исключения, исходное состояние, расписание, работоспособность агента и доставку на manager. Затем проверьте правила, порог регистрации и путь в indexer: отсутствие в интерфейсе не локализует сбой. Если удаление видно, но audit.user/process отсутствуют, выясните фактический режим и состояние системного аудита. Не присваивайте операцию владельцу файла или последнему вошедшему пользователю. Зафиксируйте ограничение атрибуции и запросите независимые журналы. Включение who-data задним числом не создаст историческое свидетельство, которого не было в доступном наборе. Ошибка чтения файла, отказ в доступе или ошибка разбора JSON не являются пустой выборкой. Для этого шага нужны права чтения выданной копии; при их отсутствии запросите доступную копию у владельца источника, сохранив сообщение об ошибке.