Кибербезопасность и информационная безопасность

Sysmon Event ID 3 и 22: Сетевые подключения и DNS-запросы

7 мин чтенияОпубликовано: 5 августа 2026 г.

Профессиональная визуальная иллюстрация по Sysmon Event ID 3 и 22 в области Windows и Identity

Быстрый ответ

Sysmon Event ID 3 и 22 требует чтения всего события, а не только Event ID: время, компьютер, пользователь, Logon ID, процесс, сетевой источник и организационный контекст. Вывод формируется путем корреляции нескольких источников.

Расследование Windows и Identity основано на комбинации событий аутентификации, создания процессов, изменений разрешений, телеметрии Sysmon и организационного контекста. Одно событие почти никогда не дает полного вывода. Данная статья посвящена Sysmon Event ID 3 и 22 и предназначена для SOC-аналитиков и исследователей конечных точек. Цель состоит в том, чтобы предоставить методологию, которую можно применять на практике, в профессиональном интервью и в рабочей среде, не ограничиваясь словарным определением.

Основная проблема заключается в том, что данные почти всегда неполны. ProcessGuid, DestinationIp, DestinationPort могут указывать направление, но их значение зависит от времени, актива, пользователя и ожидаемой активности. Поэтому мы построим проверку вокруг исследовательского вопроса, необходимых доказательств и четкого критерия завершения.

Практический сценарий в статье: подключение запроса к процессу и IP на временной шкале. Все примеры представляют собой лабораторные данные или описание процессов. При работе с Penetration Testing, Web или Cloud необходимо работать только с явным разрешением, определенным Scope и возможностью остановить проверку.

Поля события 3

Важные поля не обязательно те, что отображаются в верхней части экрана. В Sysmon Event ID 3 и 22 необходимо идентифицировать стабильные идентификаторы, время, источник, назначение, результат и контекст. Полезные примеры: ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime. Цель состоит в том, чтобы обеспечить корреляцию между записями, а не только чтение одного события.

Рекомендуется создать небольшой Data dictionary: имя поля, значение, формат, источник, ожидаемые значения Null и его надежность для связи. Это позволяет различать поле отображения и исследовательский идентификатор, а также определять, когда коннектор или версия изменили схему.

Поля события 22

Подключение по ProcessGuid

Правильное внедрение начинается с требований, а не со значения по умолчанию. Определяются поддерживаемые варианты использования, объем данных, кто управляет конфигурацией и каков механизм отката. В Sysmon Event ID 3 и 22 необходимо различать настройки, которые генерируют телеметрию, и настройки, которые ее фильтруют или обогащают.

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

Идентификация доменов и необычных целей

Исследование Sysmon Event ID 3 и 22 начинается с формулирования гипотезы: какое поведение объясняет обнаруженное, и какие доказательства подтвердят или опровергнут его. Затем расширяется временное окно, проверяются сущности и ищется последовательность до и после события.

Хорошая корреляция объединяет как минимум два типа информации из ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime. Для каждой находки указывается, что она доказывает, что не доказывает и каков следующий шаг. Если данных недостаточно, указывается Unknown и отсутствие доказательств не превращается в доказательство отсутствия.

Ограничения и проверка в дополнительных источниках

На этом этапе определяются доказательства, необходимые для ответа на исследовательский вопрос. Для Sysmon Event ID 3 и 22 базовыми точками являются Event ID и Provider, Computer, User и Logon ID, Process, Parent и Command Line, Source IP, Workstation и Logon Type. Для каждого источника документируются владелец, срок хранения, часовой пояс, задержка приема и поля, которые могут отсутствовать.

Качество сбора не измеряется тем, что лог 'приходит'. Необходимо проверять Completeness, Latency, Parsing, Duplicate events и синхронизацию времени. Проверка Canary или известное лабораторное событие позволяет убедиться, что операция появилась в источнике, прошла через Pipeline и доступна для поиска в нужных полях.

Особые точки проверки

В этом вопросе рекомендуется заранее составить целенаправленную карту доказательств. Основные точки проверки: ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime, query name, response code, TTL, subdomain entropy. Список не является автоматическим контрольным списком; каждый элемент выбирается потому, что он может связывать сущность, действие и время или объяснять легитимное поведение.

ProcessGuid: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
DestinationIp: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
DestinationPort: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
QueryName: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
QueryResults: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
UtcTime: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.

Если одна из точек недоступна, необходимо задокументировать пробел и выбрать альтернативу. Например, если идентификатор процесса нестабилен, можно использовать время, Host, User и Parent; если полезная нагрузка зашифрована, используются Metadata, объем, частота и TLS/DNS context.

Практический сценарий

Выбранный сценарий – подключение запроса к процессу и IP на временной шкале. Цель упражнения – не доказать способность к атаке, а отработать сбор, сравнение и документирование безопасным способом. Перед началом работы определяются смоделированные данные, временное окно и ожидаемый результат.

По завершении упражнения необходимо предоставить продукт, который может быть проверен другим аналитиком или тестировщиком: скриншот или экспорт доказательства, краткая временная шкала, первоначальное предположение, подтверждающее доказательство, ограничение и рекомендация. Если доказательств недостаточно, правильный вывод – сценарий не доказан.

Этап	Что выполняется	Результат
Подготовка	Определите Scope, время и цель. Запишите, какие поля или доказательства из ProcessGuid, DestinationIp, DestinationPort ожидаются.	Краткий план тестирования
Создание данных	Выполните безопасное и смоделированное действие, связанное с Sysmon Event ID 3 и 22, без реальной информации или влияния на производственную систему.	Контролируемое событие/запрос/поток
Сбор	Соберите необработанные доказательства и контекст из дополнительного источника. Убедитесь в правильности часового пояса, идентификаторов и целостности.	Два связанных доказательства
Анализ	Напишите, что доказывает каждое доказательство, что не доказывает и каково возможное легитимное объяснение.	Промежуточный вывод
Завершение	Выберите закрытие, эскалацию, Finding или Tuning; добавьте рекомендацию и Retest.	Документированный результат

Практический контрольный список

Проверьте и задокументируйте: Event ID и Provider.
Проверьте и задокументируйте: Computer, User и Logon ID.
Проверьте и задокументируйте: Process, Parent и Command Line.
Проверьте и задокументируйте: Source IP, Workstation и Logon Type.
Проверьте и задокументируйте: Group/Privilege changes.
Проверьте и задокументируйте: Sysmon ProcessGuid или SessionGuid.
Укажите часовой пояс, версию инструмента и время сбора.
Сохраните необработанные данные до фильтрации или изменения.
Напишите, что доказывает находка и что еще неизвестно.
Определите владельца и следующее действие с датой.

Распространенные ошибки

Полагаться на Event ID без полей.
Путать Logon с источником атаки.
Игнорировать Logon Type.
Связывать процессы только по PID.
Предполагать, что любой PowerShell вредоносен.
Закрывать событие, не проверяя Domain Controller.

Заключение и CTA

Sysmon Event ID 3 и 22: Сетевые подключения и DNS-запросы – это тема, которая связывает технические знания с рабочей дисциплиной. Начните с вопроса, соберите только релевантные доказательства, сохраните контекст и время, и выберите действие, которое можно обосновать и перепроверить.

В рамках курса Cybersecurity & AI от HPI эти принципы отрабатываются с использованием систем, логов и лабораторий. Естественным продолжением является переход к связанным статьям, выполнение лабораторного упражнения и сохранение результата как части профессионального портфолио.

Вопросы и ответы

Доказывает ли Sysmon Event ID 3 и 22 само по себе атаку или уязвимость?

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

Что делать, если часть данных отсутствует?

Задокументируйте отсутствие, проверьте альтернативный источник и снизьте уровень уверенности. Не следует дополнять поля предположениями или представлять Unknown как нормальное.

Сколько времени нужно хранить доказательства?

Время зависит от политики, регулирования, стоимости и типа события. Важно заранее определить Retention, Legal hold и возможность экспортировать доказательства в проверяемом формате.

Как тренироваться, не рискуя реальной системой?

Используйте виртуальные машины, смоделированные данные, CTF или выделенную лабораторию. При санкционированных проверках определите Scope, Stop conditions и резервное копирование перед началом работы.