Меня зовут Борис Усков, я руковожу группой сетевой аналитики в «Гарде». Большая часть аномалий, которые мы видим в сети заказчика в первые дни после развёртывания NDR, — это вовсе не атаки. Это инфраструктурный долг и теневое ИТ: старые протоколы, забытые сервисные учётки, внешние DNS, нестандартные порты, торренты и прочая фоновая сетевая активность. Конечно, хорошо, что это не хакеры. Однако такой ровный белый шум помогает злоумышленникам скрывать свои действия и порой опасен сам по себе.

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

Аномалия №1. Логины и пароли в открытом виде

Один из самых неприятных сценариев во время пилота — когда NDR показывает логины и пароли, передающиеся по сети в открытом виде.

Как правило, это не результат атаки, а наследие старых интеграций или «временных» решений. Например, LDAP simple bind без TLS, FTP, старый HTTP в тестовых сегментах, самописная авторизация поверх обычного TCP или API-вызовы без сертификатов. Администраторам бывает некогда настраивать шифрование, руководство торопит: «Давайте запустим здесь и сейчас, а безопасность допилим позже». Но, как мы знаем, нет ничего более постоянного, чем временное.

Самый частый пример — работа по протоколу LDAP. И хотя заказчики знают, что его можно использовать безопаснее, скажем, через LDAPS или StartTLS, но на практике это обычно упирается в сертификаты, регламенты и страх поломать авторизацию. 

Представьте такую картину: сертификат на контроллере домена истекает в субботу, а в понедельник сотрудники приходят на работу, и авторизация не работает. «Может, и не нужна нам такая сложная система защиты?» — задумывается заказчик. 

Так и появляется тот самый «осознанный» (на самом деле не до конца) риск. Логика заказчика обычно такая: «У меня LDAP во внутренней инфраструктуре. Снаружи я закрыт NGFW и IPS, снизу — NAC и 802.1x. Чужих в сети нет, значит, открытые креды в трафике не проблема».

Этот миф о непробиваемом периметре мог бы неплохо существовать, но есть некоторые нюансы. В сети есть IoT-устройства с прошивками пятилетней давности, принтеры с MAC Authentication Bypass (где проверка идёт только по MAC-адресу, который легко подменить), подрядчики с ноутбуками в переговорных, гостевые сегменты и сотрудники, работающие удалённо. Если злоумышленник закрепился хотя бы на одном узле в таком сегменте, он может включить своё устройство в режиме прослушивания или использовать технику Man-in-the-Middle. 

В чём опасность

Открытые пароли становятся готовым материалом для lateral movement. Атакующему не нужно ломать домен сложными техниками, если часть паролей уже летает по сети в читаемом виде.

Как NDR ловит аномалию

Система отсекает заголовки IP и TCP, разбирает L7-протокол и, зная RFC, извлекает из сообщения логин и пароль. Политикой настраивается срез: собрать сессии с открытыми кредами и разложить их по парам хостов и протоколам. Через две недели у заказчика появляется понимание, что почти все пароли в инфраструктуре лежат «на блюдечке с голубой каёмочкой». Так возникает жгучее желание подумать о безопасности. 

Что делать

Первый шаг — построить карту рисков: какие пары хостов передают учётные данные в открытом виде, какие сервисы за этим стоят и какие учётки используются. Дальше — переводить LDAP на LDAPS или StartTLS, убирать simple bind без TLS, закрывать FTP, переносить тестовые HTTP-сервисы и API за TLS. 

Важно не просто выключить один протокол, а убрать сам класс ситуаций, где пароль оказывается частью открытого сетевого payload. Отдельно стоит разобрать сервисные учётные записи и ограничить источники подключения.

Аномалия №2. Забытые учётки и ошибки конфигурации

Другая частая находка — ошибки конфигурации и «потерянные» сервисные учётные записи. В большой инфраструктуре количество учёток огромное. Сотрудники увольняются, кому-то нужно временно приостановить доступ. С пользователями админы ещё как-то справляются, больше всего проблем возникает с сервисами.

Классический сценарий: заказчику привозят на пилот новое СЗИ — например, фаервол или тот же NDR. Чтобы система видела инфраструктуру, заводят сервисную учётку для интеграции с доменом. Пилот закончился, оборудование уехало, проект закрыли, а где-то на виртуалке или тестовом сервере остался агент, коннектор или скрипт, который всё ещё продолжает стучаться в контроллер домена.

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

В чём опасность

Сетевой паттерн забытого сервиса очень похож на password spraying, перебор паролей. В результате SOC получает десятки или сотни похожих событий, а реальный злоумышленник на этом фоне просто растворяется.

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

Как NDR ловит аномалию

Если протокол шифрованный, NDR не всегда видит содержимое аутентификации. Но ему это и не нужно: достаточно частоты, направления, размера сессий, повторяемости и стабильной пары «источник — контроллер домена». Система выделяет новые пары хостов, резкий рост частоты запросов, изменение расписания попыток и появление ранее неизвестных источников.

Что делать

Провести инвентаризацию сервисных учётных записей и источников аутентификации. Для каждой учётки закрепить владельца, назначение, срок жизни, допустимые источники подключения и процесс ротации. На стороне NDR важно не просто алертить факт неуспешной аутентификации, а отслеживать поведенческие аномалии. Например, новые источники, всплески активности. Тогда забытый сервис останется в списке технического долга, а новую активность будет проще расследовать.

Аномалия №3. Внешние DNS

После инфраструктурного наследия обычно всплывает теневое ИТ. Один из самых массовых примеров — хосты, которые ходят не на корпоративные DNS-серверы, а напрямую на внешние резолверы: 8.8.8.8, 1.1.1.1 и им подобные.

Причины банальны. Когда-то открыли порт на фаерволе, чтобы что-то проверить, и забыли закрыть. Или поставили IP-камеры с внешним DNS по умолчанию из слабо управляемого сегмента IoT. Корпоративный фаервол должен отлавливать такие запросы, но из-за ошибок в настройках он может их пропускать.

В чём опасность

Во-первых, обычные DNS-запросы не шифруются. Наружу могут уходить внутренние имена сервисов, домены подрядчиков, названия облачных систем, окружения вроде test, stage и prod. По этим деталям можно восстановить часть архитектуры компании.

Во-вторых, DNS — удобный канал для обхода ИБ-политик. Через DNS можно строить туннели, передавать данные маленькими фрагментами и маскировать эксфильтрацию под обычные запросы. Резкий рост DNS-трафика, длинные поддомены, большое количество NXDOMAIN-ответов и обращения к свежим доменам — повод для расследования.

Как это видит NDR

NDR легко засекает хосты, отправляющие наружу DNS-запросы. Если это обычный DNS на 53 порту, видны сами доменные имена. Если используется DoH (DNS over HTTPS) или DoT (DNS over TLS), содержимое запросов не читается напрямую, но сам факт обхода корпоративного резолвера остаётся аномалией.

Что делать

Корпоративная ИБ-политика должна быть простой: клиенты ходят только на внутренние резолверы, и наружу DNS выпускают только они. Исключения должны быть описаны, согласованы и ограничены по источникам.

В NDR полезно контролировать прямые обращения к публичным DNS, рост объёма DNS-трафика, подозрительно длинные имена, аномальную частоту запросов и появление DoH/DoT там, где их не должно быть.

Аномалия №4. Нестандартные порты

Нестандартные порты — обычное дело в любой инфраструктуре. Мы регулярно видим самописные сервисы, которые доступны не на 80, а, например, на 188 порту, или SSH, поднятый на 2022. Логика заказчика понятна: если перенести сервис со стандартного порта, его не найдёт поверхностный интернет-сканер.

Со стороны кажется, что 65 535 портов — это астрономическая цифра, огромное пространство, где легко затеряться. Но это миф, и такая защита иллюзорна: злоумышленник, который уже закрепился внутри корпоративной сети, не ограничен примитивными сканерами уязвимостей. Если он нашёл лазейку, ему всё равно, на каком порту висит сервис — главное, что тот доступен.

Чем это опасно, и как NDR помогает

«Спрятанные» сервисы часто выпадают из поля зрения. Их забывают инвентаризировать, перестают обновлять и не проверяют права доступа. NDR в этом случае помогает отличить легитимный шум от действий злоумышленника: если трафик идёт по известному шаблону самописного приложения — это одно, если же порт внезапно начал использоваться для необычных соединений — это тревожный сигнал.

Ситуация, когда на стандартном разрешённом порту живёт совсем не тот протокол, который ожидает фаервол, — тоже не лучше. Если сервис использует нестандартный зашифрованный протокол и межсетевой экран не умеет его распознавать, то фаервол видит «порт разрешён» и пропускает трафик, а реальная прикладная логика остаётся вне контроля.

Что делать

Помогает DPI (Deep Packet Inspection). Для SSH, TLS и других зашифрованных соединений, помимо DPI, можно использовать анализ метаданных, профилей клиентов, частотности, объёма, направления и отклонений от baseline. Главное — обеспечить прозрачность: у любого нестандартного порта должен быть владелец, назначение и описание в CMDB (Configuration Management Database) или аналогичной системе учёта.

Аномалия №5. Криптоактивность: от бирж до майнеров

Самая необычная для заказчиков находка — криптоактивность в корпоративной сети. Казалось бы, серьёзный бизнес, всё легитимно, откуда вдруг взялся майнинг? Но здесь важно не смешивать разные вещи.

Приложение криптобиржи на смартфоне в гостевом Wi-Fi — это, скорее всего, ложная сработка или нарушение политики использования гостевой сети, но не атака. А вот принтер из офисного сегмента, который обращается к инфраструктуре майнинга, — это уже прямой сигнал тревоги.

В чём опасность

В самом безобидном варианте это нарушение политики. В более серьёзном — признак компрометации. Например, майнинг на рабочей станции может быть следствием установки пиратского софта. Майнер на сервере — результат эксплуатации уязвимости. Майнер на принтере, камере или другом устройстве, на которое невозможно установить полноценный EDR, — сигнал о том, что устройство скомпрометировано.

Как это видит NDR

Проблемы с такими устройствами зачастую можно выявить только по аномальной сетевой активности. NDR сопоставляет сетевые соединения с TI-фидами, DNS-именами, IP-адресами и SNI (если он виден).

Что делать

Сначала классифицировать источник подозрительного трафика и проанализировать риски. Дальше — проверить сегментацию, правила выхода наружу, соответствие DHCP/MAC/IP-данных друг другу, наличие факта подмены устройства и историю обращений. Если криптоактивность идёт от корпоративного актива, это инцидент или нарушение политики, которое нужно разбирать вместе с владельцем устройства.

Аномалия №6. P2P-активность и нежелательное ПО

BitTorrent в корпоративной сети — тоже довольно распространённое явление и, как правило, плохой сигнал. Не потому, что сам P2P-протокол обязательно вредоносный, а потому, что он может быть связан с пиратским софтом, неучтёнными загрузками и заражёнными дистрибутивами.

В чём опасность

Сценарий обычно такой: сотрудник скачал «нужную утилиту», «крякнутый редактор» или «портативную версию» через торрент. Внутри оказался лоадер, который позже скачивает payload, обфусцирует его, кладёт в память легитимного процесса или запускает цепочку команд для обхода хостовой защиты. Антивирусы не дают стопроцентной гарантии, особенно если код приходит частями и выполняется в памяти. Вредоносная активность всплывает именно в сетевых индикаторах.

Похожие проблемы могут возникать при использовании Tor или программ удалённого доступа (например, TeamViewer, AnyDesk и им подобных), через которые тоже могут организовываться каналы управления и которые могут стать вектором проникновения вредоносного ПО.

Как это видит NDR

NDR выявляет приложения (Bittorent, TeamViewer, AnyDesk и другие) за счёт DPI и сигнатур, а также ловит аномалию по множеству однотипных соединений и большому количеству внешних пиров.

Что делать

BitTorrent и другие подобные P2P-протоколы в корпоративных сегментах должны быть запрещены или жёстко ограничены. Но важно не превращать всё в охоту на пользователя, который «что-то скачал». Стоит сконцентрироваться на поиске хостов, у которых после P2P-активности появляется новая внешняя периодика, обращения к доменам с малой репутацией или нетипичные TLS-сессии.

Аномалия №7. Странные бинарники

Практически в любой инфраструктуре мы видим передачу exe-файлов, DLL, PDF, документов Word или Excel с макросами. В большой сети такие передачи происходят постоянно: администраторы раскладывают установщики, системы обновлений распространяют агенты, разработчики передают сборки.

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

Чем это опасно, и как NDR помогает

Тревогу должна вызывать передача исполняемых файлов между пользовательским сегментом или сегментами, в которых установка ПО обычно не предусмотрена. Например, в направлении принтеров, терминалов, IoT-устройств и технологических зон (АСУ ТП, SCADA-системы).

NDR — не антивирус, он не должен решать, вредоносный файл передаётся или легитимный. Но система фиксирует сам факт передачи исполняемого файла и помогает восстановить маршрут движения файла: откуда файл пришёл, через какие узлы прошёл и где оказался.

NDR может отследить передачу по HTTP, FTP, SMB, почте (SMTP) или другому протоколу, если содержимое доступно для анализа. В случае шифрования видимость ограничена, но остаются метаданные: кто кому передавал, как часто, в каком объёме и направлении.

Что делать

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

Аномалия №8. Аномальные всплески ICMP-трафика

NDR всегда бьёт тревогу, если видит в сети ICMP-туннель. Но не всегда передача ICMP-пакетов говорит о том, что в инфраструктуре сидит злоумышленник. У нас был такой случай: туннель строился не от заражённого компьютера к серверу хакера, а между обычным терминальным сервером и корпоративным DNS.

В моменты пиковой нагрузки корпоративный DNS-сервер начинал «тормозить» и отвечать с задержкой 5–10 секунд. Клиент (терминальный сервер) переставал ждать, закрывал соединение и отправлял запрос заново. Когда DNS-сервер наконец «просыпался» и отправлял запоздалый ответ, клиент его уже не ждал.

Срабатывал базовый сетевой стандарт (RFC 792): устройство, получившее пакет на закрытый порт, обязано вернуть отправителю сообщение об ошибке — ICMP Destination Unreachable. Внутри этого ICMP-сообщения клиент обязан запаковать кусок исходного пакета (тот самый запоздалый DNS-ответ), чтобы сервер понял, о каком ответе идёт речь. Эта «матрёшка» (пакет внутри пакета) технически является туннелем, поэтому NDR сигнализировала о его появлении.

В чём опасность

Подобная ситуация, хотя и не является атакой, создаёт мощный фон. Аналитики тратят время на разбор этого шума, а настоящая подозрительная ICMP-активность может затеряться.

Что делать

Не отключать ложноположительные алерты, а разобраться с причинами их возникновения. Предупреждения могут не иметь отношения к ИБ, но указывать на проблемы с производительностью DNS или других сервисов, которые тоже нужно чинить.

Аномалия №9. Beaconing в сетевом трафике

Теперь перейдём к тому, что уже ближе к настоящим атакам.

После проникновения злоумышленнику нужен канал управления. Имплант периодически связывается с C2-сервером, получая команды и отправляя результаты. Чтобы не шуметь, он работает маячками (beaconing): короткие обращения через заданные интервалы времени, иногда с искусственным «дрожанием» (jitter), чтобы трафик не выглядел роботизированным.

Проблема в том, что такое поведение легко маскируется под обычную сетевую активность. В любой инфраструктуре мы видим периодические взаимодействия по протоколам HTTP, DNS, DNS over HTTPS (DoH). Например, подозрительную периодику может давать автоматизированная система заказчика, которая ходит по HTTPS к подрядчику за данными.

В чём опасность

Хотя по опыту такая аномалия чаще всего оказывается легитимной активностью, выключать мониторинг небезопасно. Ведь если это всё‑таки атака, то последствия будут серьёзными.

Как это видит NDR

По открытому HTTP легко заглянуть в заголовки и понять, что это легитимная система. С DNS сложнее. Самый сложный случай — HTTPS и DoH. Когда payload зашифрован, просто прочитать команду нельзя. Однако NDR накапливает статистику по периодичности соединений, длительности сессий, объёмам данных, направлению, TLS-профилю и доменам. Мы видим параметры, совпадающие с инструментами эксплуатации, такими как Cobalt Strike, Brute Ratel и другие.

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

Отфильтровав Microsoft Update, Chrome, Mozilla, агенты мониторинга, резервное копирование и другие известные источники, в сети из пары тысяч хостов часто удаётся выделить одну–две машины, которые регулярно «отстукиваются» наружу с подозрительной частотой. Особенно подозрительны хосты, которые раньше не имели внешней периодики, а потом начали регулярно ходить на новый домен или IP.

Что делать

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

NDR здесь не заменяет endpoint-расследование, а даёт список машин, с которых его стоит начать. А далее уже можно проверять короткий список хостов endpoint-средствами: изучать журналы процессов, автозапуск, сетевые соединения, историю PowerShell, scheduled tasks, браузерные расширения и прокси-логи. 

Аномалия №10. DGA-домены

Ещё NDR ловит такую штуку, как DGA-домены.

Domain Generation Algorithm (DGA) — техника, которую любят использовать ботнеты и постэксплуатационные фреймворки. Имплант динамически генерирует имена доменов по алгоритму, известному только ему и серверу. Сегодня он ищет связь по адресу qwezxcasd.net, завтра — bnmpoiu.org. Атакующему достаточно зарегистрировать один из них, и имплант его «угадает».

Снаружи DGA-домен выглядит как абракадабра. Казалось бы, всё просто: настроили в NDR правило на странные имена и радуемся. Но загвоздка в том, что не всякая абракадабра — хакерский DGA.

Почему мы видим их всегда? Потому что в корпоративной инфраструктуре тоже могут быть домены, которые сгенерировал не человек. Например, балансировщик нагрузки Citrix легально генерирует технические имена узлов вида lb-type-load-0-1.segment-1344.example.com. Похожую картину дают сегменты облачных платформ и технические сервисы Kubernetes.

Это законный внутренний нейминг. Простая регулярка «заблокировать всё странное» нарушит работу легитимных узлов.

Как это видит NDR

В «Гарда NDR» для детектирования DGA используется специализированная ML-модель, обученная на более чем 10 млн доменных имён с применением градиентного бустинга. Она помогает аккуратно отделить «хороший» трафик от потенциальных зловредов, для которых нет чётких сигнатур, ориентируясь на структуру легитимных корпоративных суффиксов.

Система использует математическую модель оценки энтропии, чтобы определить, насколько последовательность букв в доменном имени похожа на естественный язык. Например, у microsoft.com энтропия низкая, у сгенерированного qwezxcasd.net — высокая. Таким образом, мы можем достаточно точно отделить вредоносную генерацию от легитимных технических имён (балансировщики, Kubernetes, CI/CD-артефакты) и снизить количество ложных срабатываний.

Сама по себе высокая энтропия — не приговор. Но в сочетании с другими факторами она становится веским поводом для проверки.

Что делать

Использовать DGA-детект не как бинарное правило, а как один из факторов в скоринговой модели. В исключениях отдельно учитывать корпоративные суффиксы, известные облачные платформы, CDN, балансировщики, Kubernetes-нейминг и домены подрядчиков.

Вместо вывода

В первые дни после развёртывания NDR обычно подсвечивает не APT и не сложную постэксплуатацию, а инфраструктурный долг, теневое ИТ и позабытые костыли. В этом смысле NDR полезен не только как средство защиты, но и как инструмент наблюдения: он помогает увидеть, как сеть ведёт себя на самом деле.

LDAP без TLS, забытые сервисные учётки, внешние DNS, нестандартные порты, торренты, исполняемые файлы в неожиданных сегментах — всё это может годами накапливаться и не выглядеть как срочная проблема. Но именно такой фон мешает распознавать настоящие инциденты.

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

Например, в «Гарда NDR» используется автоматический риск-скоринг хостов. Система рассчитывает индекс опасности для каждого устройства на основе множества детектов (DPI, IDS, поведенческий анализ, deception). Вместо анализа тысяч разрозненных событий аналитик получает список хостов, которые с наибольшей вероятностью скомпрометированы. Это не отменяет ручного разбора, но позволяет сосредоточиться на самом критичном.

Другой полезный механизм — кластеризация хостов на основе поведения. Хосты со схожим сетевым поведением автоматически группируются. Если какое-то устройство начинает действовать нетипично для своего кластера (например, использует необычный протокол или меняет направление коммуникаций), система фиксирует аномалию. Такой подход помогает замечать скрытые атаки, в том числе горизонтальное перемещение с использованием легальных протоколов (RDP, SSH).

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

---

Думаю, у каждого, кто разбирал ложные срабатывания поведенческих моделей, есть своя любимая аномалия. Расскажите в комментариях: какая сетевая аномалия съела у вас больше всего нервных клеток?