Условия и исходный вопрос
Отделите вопрос «какой процесс пытался связаться» от вопросов «сервер принял запрос» и «данные действительно переданы». Для первого подходит телеметрия конечного устройства, для остальных нужны дополнительные свидетельства. Запишите источник адреса назначения, период, устройство и точку наблюдения. Убедитесь, что Defender for Endpoint поставляет данные в доступную вам таблицу. Если исходная зацепка пришла от межсетевого экрана, сохраните исходные адреса до и после трансляции: их нельзя молча считать адресами, которые видел локальный процесс.
Чтение и отбор
Начальная выборка ограничена одним устройством, UTC-интервалом и учебным удалённым адресом. Запрос не меняет политику, не блокирует узел и не посылает соединение. Замените значения параметров и сначала посмотрите полный набор подходящих ActionType. Дополнительный фильтр только на успешное соединение может скрыть предшествующие отказы. При временном имени или прокси проверьте исходную гипотезу: точный IP-фильтр не найдёт обращения к другому адресу той же службы. Рабочее уточнение должно опираться на известные сетевые условия.
Как читать пример
Локальный порт 51024 относится к устройству edr-lab-01, удалённый 443 — к указанному адресу сервера. Это направление описано с позиции источника EDR. Инициатор — msedge.exe с указанными PID и временем создания. Имя portal.example.test и командная строка помогают проверить контекст, но не являются полным содержимым зашифрованного запроса. Поле ActionType в иллюстрации опущено; в рабочей выборке сначала установите его значение. Даже успешное сетевое соединение не доказывает, что пользователь вошёл на сайт или получил нужный документ. В таблице для таких прикладных результатов нет универсального подтверждающего поля.
Проверка связей и альтернатив
Перейдите к записи создания процесса на том же устройстве. Сопоставьте PID, время создания, образ и временной порядок, затем сравните родительскую цепочку с ожидаемым запуском браузера. Одно имя msedge.exe не отличает обычную работу от злоупотребления штатным приложением. Если время или пользователь расходятся, сохраните обе версии и проверьте синхронизацию часов, перезапуск процесса и границы экспорта. Не объединяйте одинаковые PID с разных узлов. При наличии прокси его журнал может показывать другую сторону соединения, что само по себе не противоречие.
Что проверить дальше
Для сетевого отказа сопоставьте событие с решением FW/NGFW и параметрами соединения. Для вопроса об обращении к конкретному ресурсу найдите журнал приложения или веб-сервера. Сетевая телеметрия Zeek/IPFIX может дать независимую точку наблюдения, но её идентификаторы не равны идентификаторам Defender. Рабочий вывод должен перечислять, какие этапы подтверждены: процесс, сетевое событие, серверный запрос, прикладной результат. Указывать один общий «успех» на всю цепочку недостаточно.
Если таблица пуста
Проверьте правильность DeviceId/имени, времени, прав и наличие данных службы. Затем исследуйте, не изменились ли адрес назначения, DNS-ответ или маршрут через прокси. Повторите чтение без точного адресного ограничения в пределах того же устройства и периода. Срок хранения, доставка и неполнота сенсора также ограничивают результат. Не считайте пустую выдачу подтверждением блокировки или отсутствия обмена. Зафиксируйте проверенные ограничения и запросите у владельца сети или endpoint-источника конкретные недостающие данные. Если запрос завершился ошибкой доступа к таблице или устройству, сохраните текст ошибки и уточните доступ на чтение данных этого устройства в Defender RBAC у владельца сервиса. Ошибка доступа и успешно выполненный запрос с нулём строк — разные результаты.