IBCOURSES / СПРАВОЧНИК ИБ

Darktrace NDR: от model breach к проверяемому сетевому эпизоду

К ответу ↓

Срабатывание модели — повод проверить конкретный эпизод. Для вывода нужны исходный объект, модель на момент события, устройство и связанные соединения; score не заменяет расследование.

Например
Материалов с пояснениями: 94 · Записей реестров: 11 678

Уточнить поиск

События и журналы

Найдено: 84
Инструкция по проверке
Darktrace NDR: от model breach к проверяемому сетевому эпизоду

Срабатывание модели — повод проверить конкретный эпизод. Для вывода нужны исходный объект, модель на момент события, устройство и связанные соединения; score не заменяет расследование.

Darktrace · коннектор SOAR 1.0.4
Инструкция по проверке
Windows Security 4625 — неудачная попытка входа

Зарегистрирована неудачная попытка входа. Причину уточняют по кодам результата, типу входа и контексту запроса.

Security · Security-Auditing
Инструкция по проверке
Linux Audit USER_AUTH — попытка аутентификации

Приложение сообщило о попытке аутентификации. Это тип записи Linux Audit, а не универсальный Event ID Linux.

Linux Audit · userspace
Инструкция по проверке
Кто создал учётную запись

Сначала выберите хранилище учётной записи. Затем найдите операцию и разделите технического инициатора, созданный объект и человека.

Windows / AD / Linux / IdP
Обзор источника
Альт: источники аудита и поиск событий

Альт — семейство российских ОС на базе Linux. Здесь — паспорт чтения аудита: настройки, журналы и поиск USER_AUTH.

Альт Рабочая станция 11.1
Инструкция по проверке
UserGate: где искать подключения по VPN

Найдите сессию или отказ в журнале шлюза. Отличайте подключение, разрыв, ошибку и изменение правила.

UserGate NGFW 7.5 · VPN
Инструкция по проверке
Kubernetes: кто отправил запрос на создание Pod

API audit помогает установить инициатора запроса. Для вывода о создании нужны объект, стадия и результат.

API Audit · audit.k8s.io/v1
Инструкция по проверке
Windows Security 4720 — создана учётная запись

Создан новый пользовательский объект. Субъект запроса и новая учётная запись указаны в разных полях; локальную и доменную область определяют по роли узла и TargetDomainName.

Схема события 0
Инструкция по проверке
Windows Security 4732 — участник добавлен в локальную группу безопасности

В локальную группу безопасности добавлен участник. Для каждого участника формируется отдельная запись; название группы само по себе не показывает её эффективные полномочия.

Схема события 0
Инструкция по проверке
Windows Security 5136 — изменён атрибут объекта AD

Изменён атрибут объекта Active Directory. Обычно удаление прежнего и добавление нового значения отражаются отдельными 5136; их нужно сопоставлять, сохраняя тип операции.

Схема события 0
Инструкция по проверке
Windows Security 4624 — создан успешный сеанс входа

На целевом компьютере создан сеанс входа. Subject относится к сообщившему/служебному контексту, Target — к новому сеансу; дальнейшие действия подтверждаются отдельно.

Схема события 2
Инструкция по проверке
Windows Security 4688 — создан новый процесс

Зарегистрирован запуск процесса. Командная строка требует отдельной настройки аудита; версия события влияет на поля инициатора, целевой учётной записи и родительского процесса.

Схема события 2
Инструкция по проверке
Windows Security 4698 — создано задание планировщика

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

Схемы события 0 / 1
Инструкция по проверке
Windows Security 4663 — использовано право доступа к объекту

Зафиксировано использование конкретного права над объектом. В отличие от запроса handle это свидетельство применения права; вид операции определяется AccessMask и типом объекта.

Схема события 1
Инструкция по проверке
Windows Security 4657 — изменено значение реестра

Изменено значение реестра. Имя ключа и имя значения различаются; событие не является универсальной записью любого изменения ключа.

Схема события 0
Инструкция по проверке
Windows Eventlog 1102 — очищен журнал Security

Очищен журнал Security. Поставщик этого события — Microsoft-Windows-Eventlog; субъект находится в UserData/LogFileCleared, а не в обычном EventData.

Схема события 0
Инструкция по проверке
Sysmon Event 1 — создание процесса

Sysmon регистрирует расширенный контекст создания процесса. GUID процесса помогает связям, командная строка — интерпретации; версия и конфигурация Sysmon определяют доступную телеметрию.

Sysmon 15.22
Инструкция по проверке
PowerShell 7: 4104 — Script Block Logging

При включённом Script Block Logging PowerShell пишет содержимое обрабатываемых script blocks. Для PowerShell 7 используется PowerShellCore/Operational; Windows PowerShell 5.1 рассматривается отдельно.

PowerShell 7.5 · схема события 1
Обзор источника
systemd journal — поиск по службе, процессу и загрузке

Journal хранит сообщения и структурированные поля. Пользовательские поля отличаются от добавленных journald; доступность и хранение определяются конкретной системой.

systemd 262
Инструкция по проверке
Linux Audit EXECVE — аргументы запуска программы

Соберите SYSCALL, EXECVE и соседние записи одного события. Аргументы, контекст входа и результат exec — разные сведения; одной строки EXECVE недостаточно.

Linux Audit · Linux 6.12 / x86-64
Инструкция по проверке
Keycloak: как разобрать LOGIN и LOGIN_ERROR в нужном realm

Сначала проверьте сохранение событий в нужном realm. LOGIN/LOGIN_ERROR описывают этап входа в IdP; ответ API, серверный обработчик событий (event listener) и административный аудит — разные источники.

Документация latest
Инструкция по проверке
Keycloak — аудит административных изменений

Административный аудит описывает REST-операции управления realm. Он включается отдельно от пользовательских событий; representation зависит от настройки.

Документация latest
Инструкция по проверке
Vault audit — запрос и ответ на доступ к секрету

Записи аудита описывают API-запросы и ответы Vault. Их связывают по request.id; значения чувствительных полей могут быть преобразованы аудитом.

Онлайн-документация продукта
Обзор источника
sudo — кто запросил выполнение от другого пользователя

Журнал sudo различает пользователя, вызвавшего sudo, и пользователя предполагаемого запуска команды (runas). Сообщение о принятой команде само по себе не содержит полного результата её работы.

sudo · журнал событий
Инструкция по проверке
Intune auditEvent — изменения управления устройствами

Аудит Intune описывает административную активность и затронутые ресурсы. Actor, результат операции и изменённые свойства помогают исследовать изменение управления парком.

Microsoft Graph v1.0
Обзор источника
Astra Linux — карта системных журналов и аудита

В документации разделены системная регистрация и аудит безопасности auditd/PARSEC. Для рабочего поиска нужен паспорт установленной редакции, профиля и фактической конфигурации.

Документация latest
Инструкция по проверке
Keycloak / OIDC: на каком этапе отказал вход

Отделите проверку URI перенаправления, аутентификацию клиента и выдачу или обновление токена. Одинаковое сообщение приложения не устанавливает этап отказа или ошибку пароля пользователя.

Keycloak 26.8.1
Инструкция по проверке
Keycloak / SAML: отказ при ответе внешнего IdP

Для Keycloak как брокера внешнего SAML IdP различайте ошибки разбора ответа, проверки назначения (Destination), подписи и условий утверждения (assertion). Общее сообщение об ошибке не определяет единственную причину.

Keycloak 26.8.1
Инструкция по проверке
Windows Security 4768 — запрос TGT в Kerberos

4768 показывает выдачу TGT или часть отказов на DC. Для причин сначала прочитайте Status и версию XML; успех выдачи TGT не подтверждает вход в приложение.

XML · схемы события 0 / 2
Инструкция по проверке
Windows Security 4769 — запрос билета службы Kerberos

4769 описывает запрос TGS на DC. Status показывает результат выдачи билета; отдельные данные приложения нужны, чтобы установить фактический доступ.

XML · схемы события 0 / 2
Инструкция по проверке

Darktrace NDR: от model breach к проверяемому сетевому эпизоду

Срабатывание модели — повод проверить конкретный эпизод. Для вывода нужны исходный объект, модель на момент события, устройство и связанные соединения; score не заменяет расследование.

Условия и граница применимости

Сначала установите, откуда получен объект: из исходного экспорта Darktrace, из SOAR или из нормализованного индекса. Зафиксируйте имя appliance, время выгрузки, продуктовую область и установленную сборку. Карточка относится к сетевому контексту NDR; похожие имена объектов в обработке почты или SaaS не делают их сетевыми свидетельствами. Маршрут описан для коннектора Darktrace 1.0.4; другие версии API могут отличаться. Перед рабочим использованием сверяйте форму ответа с документацией своей установки.

Как найти и отобрать

Получите разрешённую копию объекта и оставьте оригинал неизменным. В локальном JSON-массиве выберите нужный pbid примером jq во вкладке «Примеры». Вместе с результатом сохраните имя источника и временную границу исходной выборки. Не считайте найденный в SOAR контейнер исходным событием: интеграция могла переименовать поля, округлить оценку и добавить собственные идентификаторы. Для повторяемости запишите, каким способом получена копия и какой фильтр применён; ключи доступа в рабочую заметку не включайте.

Как прочитать синтетический результат

В примере 4242 — идентификатор одного срабатывания, 120 — устройство внутри источника. Модель и сетевое имя вымышлены; они показывают раздельные роли полей. Коннектор использует time как миллисекунды и умножает score на 100 при построении представления. Поэтому сначала проверяйте исходную шкалу, затем сравнивайте оценки. Сохраните model.then рядом с самим объектом: описание текущей конфигурации модели и её исторический контекст могут отвечать на разные вопросы. Адрес 192.0.2.20 здесь иллюстративный и не предназначен для обращения.

Интерпретация и границы вывода

Рабочий вывод на этом этапе: модель выделила эпизод, который требует проверки. Не превращайте score 0.81 в утверждение о 81-процентной вероятности взлома. Разделяйте наблюдавшееся поведение, гипотезу модели и решение аналитика. Поле acknowledged относится к обработке объекта и само по себе ничего не говорит о прекращении соединений. Для оценки серьёзности нужны роль устройства, ожидаемые партнёры обмена, расписание работ и доступные сетевые детали. Легитимная административная активность и атака могут выглядеть похоже в коротком резюме.

Следующий шаг

Откройте связанные с конкретным срабатыванием соединения читающим способом в разрешённой среде. Сопоставьте адреса, порты, протокол и время с инвентаризацией, NAT/DHCP и журналами хоста. При наличии AI Analyst найдите связанные события, сохраняя их собственные ID. В заметке отделите подтверждённые сведения от недостающих: например, «узел связался с необычным партнёром, приложение пока не установлено». Решение о реагировании оформляйте по рабочей процедуре; эта карточка не отправляет команд изоляции и не меняет отметки подтверждения.

Если записи нет

Проверьте appliance, интервал, часы, область видимости и включение именно model breaches в интеграции. В официальном коннекторе опрос этого вида объектов имеет собственный переключатель; отсутствие контейнера может быть связано с обработкой уже встреченного pbid или ошибкой сохранения. Сравните исходный экспорт с индексом назначения, затем исследуйте доставку. Если исходного объекта нет, расширьте период в согласованных пределах и проверьте сетевую видимость сенсора. Пустая выдача не доказывает отсутствия обмена: источник может не видеть сегмент или не сформировать модельное срабатывание.

Поля и область применения

Исходное полеСмысл и ограничения
pbidИдентификатор model breach; сохранять вместе с appliance.
timeВремя в миллисекундах epoch в читаемом исходником объекте; часовой пояс отображения проверять отдельно.
scoreИсходная оценка; коннектор переводит её в проценты. Это не вероятность компрометации.
model.then.nameИмя модели в историческом контексте, используемое коннектором.
model.then.categoryКатегория модели в используемой форме; не результат сетевого воздействия.
device.didID устройства в источнике, не глобальный идентификатор актива.
device.ip / device.hostnameСетевой адрес и имя; их историческую принадлежность подтверждать отдельно.
acknowledgedОтметка обработки срабатывания; не свидетельство устранения причины.

Примеры записей

Данные в примерах условные. Состав полей зависит от версии и настроек источника.

Пример фрагмента входного JSON коннектора

Фрагмент журнала. Имена полей подтверждены официальным исходником коннектора Darktrace. Это сконструированное подмножество входного JSON, не запись с испытанного сенсора и не полная схема API. Все устройства, идентификаторы и значения модели вымышлены.

[
  {
    "pbid": 4242,
    "time": 1793772000000,
    "score": 0.81,
    "acknowledged": false,
    "model": {
      "then": {
        "name": "Device::Demo unusual connection",
        "category": "suspicious"
      }
    },
    "device": {
      "did": 120,
      "hostname": "demo-workstation",
      "ip": "192.0.2.20"
    }
  }
]

Команды и способы проверки

Укажите свой узел, путь к журналу и временной интервал. Требуемая среда указана рядом с командой.

jq 1.6+, локальная разрешённая копия JSON-массива; не запрос к Darktrace

jq '.[] | select(.pbid == 4242) | {pbid,time,score,acknowledged,model_at_event:.model.then,device}' modelbreaches.json

Первоисточники

Рассматривается подмножество JSON официального коннектора 1.0.4. Срабатывание и подтверждение аналитиком не доказывают успешную атаку или блокирование.

Связанные материалы

Как пользоваться техническим справочником

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

Словарь терминов ИБ →Атлас компетенций ИБ →Обучение для SOC-аналитиков →
Материалы по разделам

Порты и службы

Коды и ошибки

События и журналы

Два ответа рядом

Сравнение источников

Сравнение показывает различия. События и поля разных систем не считаются эквивалентными.

Выберите службу

В списке — службы, доступные с текущими условиями. Число рядом — количество записей портов, а не программ на вашем узле.

Как искать в справочнике

Введите число, код, фрагмент сообщения или вопрос. Известный идентификатор поможет найти карточку; это не анализ самого инцидента.

  1. Введите номер, код, имя или фрагмент записи. Для портов можно использовать список: 80, 443, 8000–8010.
  2. Уточните поиск фильтрами. Все условия действуют одновременно. Числа в списках показывают, сколько материалов останется при выборе варианта.
  3. Службу выбирайте из каталога: поиск внутри списка помогает найти название, а кнопка «Выбрать» применяет его.
  4. Убирайте отдельные условия кнопкой × рядом с фильтром. «Сбросить фильтры» сохраняет текст поиска и текущий раздел.
  5. В карточке сверьте источник, версию и условия регистрации, затем откройте поля, примеры и первоисточник.

/ — перейти к поиску. Прямые ссылки открывают выбранную карточку в этом же справочнике.

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

Избранное и недавние материалы хранятся в этом браузере. Запрос и фильтры сохраняются при возврате к выдаче и обновлении вкладки. Поиск работает локально.

Что есть в справочнике

От вопроса к свидетельствам: кто вошёл, что запустил, к каким данным обратился, что изменил и где искать следы.

Выберите область, чтобы посмотреть доступные источники и перейти к материалам.

Уточнить или исправить ответ

Скопируйте сообщение и отправьте его на mail@ibcourses.ru.