Меня зовут Борис Усков, я руковожу группой сетевой аналитики в «Гарде». В первые часы после развёртывания NDR большая часть событий связана с уязвимостями сетевого трафика и ошибками конфигурации. В инфраструктурах 90% заказчиков мы видим одни и те же проблемы: инфраструктурный долг и теневое ИТ — старые протоколы, забытые сервисные учётные записи, внешние DNS-серверы, нестандартные порты, торрент-трафик и прочая фоновая сетевая активность. Каждая такая находка — это потенциальная возможность для злоумышленника, которая может годами оставаться незаметной в инфраструктуре.
Под катом — типовые уязвимости в сети и мисконфигурации. Для каждого случая разберу, как это выглядит в трафике, почему возникает, чем грозит и что с этим делать.
Уязвимые протоколы. Логины и пароли в открытом виде
Один из самых неприятных сценариев во время пилота — когда 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. Отдельно стоит разобрать сервисные учётные записи и ограничить источники подключения.
Забытые учётки и ошибки конфигурации
Другая частая находка — ошибки конфигурации и «потерянные» сервисные учётные записи. В большой инфраструктуре количество учёток огромное. Сотрудники увольняются, кому-то нужно временно приостановить доступ. С пользователями админы ещё как-то справляются, больше всего проблем возникает с сервисами.
Классический сценарий: заказчику привозят на пилот новое СЗИ — например, фаервол или тот же NDR. Чтобы система видела инфраструктуру, заводят сервисную учётку для интеграции с доменом. Пилот закончился, оборудование уехало, проект закрыли, а где-то на виртуалке или тестовом сервере остался агент, коннектор или скрипт, который всё ещё продолжает стучаться в контроллер домена.
Пароль у сервисной учётки давно сменили или саму учётку отключили, но забытый агент или коннектор об этом не знает. Он получает отказ, ждёт и повторяет попытку. Так может продолжаться неделями.
В чём опасность
Сетевой паттерн забытого сервиса очень похож на password spraying, перебор паролей. В результате SOC получает десятки или сотни похожих событий, а реальный злоумышленник на этом фоне просто растворяется. Кроме того, забытые учётки часто имеют избыточные права, непонятного владельца и неочевидный жизненный цикл.
Если такая учётка внезапно станет успешной точкой входа, расследовать инцидент будет сложно: никто не помнит, кто её создал и зачем.
Как NDR ловит уязвимость
Если протокол шифрованный, NDR не всегда видит содержимое аутентификации. Но ему это и не нужно: достаточно частоты, направления, размера сессий, повторяемости и стабильной пары «источник — контроллер домена». Система выделяет новые пары хостов, резкий рост частоты запросов, изменение расписания попыток и появление ранее неизвестных источников.
Что делать
Провести инвентаризацию сервисных учётных записей и источников аутентификации. Для каждой учётки закрепить владельца, назначение, срок жизни, допустимые источники подключения и процесс ротации. На стороне NDR не просто алертить на факт неуспешной аутентификации, а отслеживать поведенческие отклонения. Например, новые источники, всплески активности. Тогда забытый сервис останется в списке технического долга, а новую активность будет проще расследовать.
Внешние 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 там, где их не должно быть.
Нестандартные порты
Нестандартные порты — обычное дело в любой инфраструктуре. Мы регулярно видим самописные сервисы, которые доступны не на 80, а, например, на 188 порту, или SSH, поднятый на 2022. Логика заказчика понятна: если перенести опубликованный сервис со стандартного порта, его не найдёт поверхностный интернет-сканер. А ещё для запуска сервиса на стандартном порту (ниже 1024) может потребоваться привилегированная учётная запись. Для тестового сегмента бывает проще запуститься на временном нестандартном порту. Но, как я уже говорил ранее, ничего не бывает более постоянного, чем временное.
Со стороны кажется, что 65 535 портов — это астрономическая цифра, огромное пространство, где легко затеряться. Но это миф, и такая защита иллюзорна: злоумышленник, который уже закрепился внутри корпоративной сети, не ограничен примитивными сканерами уязвимостей. Если он нашёл лазейку, ему всё равно, на каком порту висит сервис — главное, что тот доступен.
Чем это опасно, и как NDR помогает
«Спрятанные» сервисы часто выпадают из поля зрения. Их забывают инвентаризировать, перестают обновлять и не проверяют права доступа. NDR в этом случае помогает отличить легитимный шум от действий злоумышленника: если трафик идёт по известному шаблону самописного приложения — это одно, если же порт внезапно начал использоваться для необычных соединений — это тревожный сигнал.
Ситуация, когда на стандартном разрешённом порту живёт совсем не тот протокол, который ожидает фаервол, — тоже не лучше. Если сервис использует нестандартный зашифрованный протокол и межсетевой экран не умеет его распознавать, то фаервол видит «порт разрешён» и пропускает трафик, а реальная прикладная логика остаётся вне контроля.
Что делать
Помогает DPI (Deep Packet Inspection). Для SSH, TLS и других зашифрованных соединений, помимо DPI, можно использовать анализ метаданных, профилей клиентов, частотности, объёма, направления и отклонений от baseline. Главное — обеспечить прозрачность: у любого нестандартного порта должен быть владелец, назначение и описание в CMDB (Configuration Management Database) или аналогичной системе учёта.
Криптоактивность: от бирж до майнеров
Самая необычная для заказчиков находка — криптоактивность в корпоративной сети. Казалось бы, серьёзный бизнес, всё легитимно, откуда вдруг взялся майнинг? Но здесь важно не смешивать разные вещи.
Приложение криптобиржи на смартфоне в гостевом Wi-Fi — это, скорее всего, ложная сработка или нарушение политики использования гостевой сети, но не атака. А вот принтер из офисного сегмента, который обращается к инфраструктуре майнинга, — это уже прямой сигнал тревоги.
В чём опасность
В самом безобидном варианте это нарушение политики. В более серьёзном — признак компрометации. Например, майнинг на рабочей станции может быть следствием установки пиратского софта. Майнер на сервере — результат эксплуатации уязвимости. Майнер на принтере, камере или другом устройстве, на которое невозможно установить полноценный EDR, — сигнал о том, что устройство скомпрометировано.
Как это видит NDR
NDR сопоставляет сетевые соединения с TI-фидами по DNS-именам, IP-адресам и SNI в TLS (если он виден).
Что делать
Сначала классифицировать источник подозрительного трафика и проанализировать риски. Дальше — проверить сегментацию, правила выхода наружу, соответствие DHCP/MAC/IP-данных друг другу, наличие подмены устройства и историю обращений. Проанализировать запущенные процессы на подозреваемом устройстве. Если криптоактивность идёт от корпоративного актива, это инцидент или нарушение политики, которое нужно разбирать вместе с владельцем устройства.
P2P-активность и нежелательное ПО
BitTorrent в корпоративной сети — тоже довольно распространённое явление и, как правило, плохой сигнал. Не потому, что сам P2P-протокол обязательно вредоносный, а потому, что он может быть связан с пиратским софтом, неучтёнными загрузками и заражёнными дистрибутивами.
В чём опасность
Сценарий обычно такой: сотрудник скачал «нужную утилиту», «крякнутый редактор» или «портативную версию» через торрент. Внутри оказался лоадер, который позже скачивает payload, обфусцирует его, кладёт в память легитимного процесса или запускает цепочку команд для обхода хостовой защиты. Антивирусы не дают стопроцентной гарантии, особенно если код приходит частями и выполняется в памяти. Поэтому скачивание чего-либо из непроверенных источников лучше детектировать и запрещать превентивно. А ещё Bittorent отлично занимает каналы связи: кто-то начал качать дистрибутив на 10ГБ — у всего офиса замедлился доступ в интернет.
Похожие проблемы могут возникать при использовании Tor или программ удалённого доступа (например, TeamViewer, AnyDesk и им подобных), через которые тоже могут организовываться каналы управления и которые могут стать вектором проникновения вредоносного ПО.
Как это видит NDR
NDR выявляет приложения (Bittorent, TeamViewer, AnyDesk и другие) за счёт DPI и сигнатур, а также ловит события по множеству однотипных соединений и большому количеству внешних пиров.
Что делать
BitTorrent и другие подобные P2P-протоколы в корпоративных сегментах должны быть запрещены или жёстко ограничены. Но важно не превращать всё в охоту на пользователя, который «что-то скачал». Стоит сконцентрироваться на поиске хостов, у которых после P2P-активности появляется новая внешняя периодика, обращения к доменам с малой репутацией или нетипичные TLS-сессии.
Странные бинарники
Практически в любой инфраструктуре мы видим передачу exe-файлов, DLL, PDF, документов Word или Excel с макросами. В большой сети такие передачи происходят постоянно: администраторы раскладывают установщики, системы обновлений распространяют агенты, разработчики передают сборки.
За передачей исполняемых файлов внутри периметра тоже важно наблюдать, так как они потенциально могут нести исполняемый код.
Чем это опасно, и как NDR помогает
Тревогу должна вызывать передача исполняемых файлов между пользовательским сегментом или сегментами, в которых установка ПО обычно не предусмотрена. Например, в направлении принтеров, терминалов, IoT-устройств и технологических зон (АСУ ТП, SCADA-системы).
NDR — не антивирус, он не должен решать, вредоносный файл передаётся или легитимный. Но система фиксирует сам факт передачи исполняемого файла и помогает восстановить маршрут движения файла: откуда файл пришёл, через какие узлы прошёл и где оказался.
NDR может отследить передачу по HTTP, FTP, SMB, почте (SMTP) или другому протоколу, если содержимое доступно для анализа. В случае шифрования видимость ограничена, но остаются метаданные: кто кому передавал, как часто, в каком объёме и направлении.
Что делать
Построить карту передачи файлов между сегментами. Нормальные пары хостов, системы обновлений, файловые серверы и репозитории ПО должны быть описаны. Всё, что не укладывается в эту карту, нуждается в проверке. Особого внимания требуют сегменты без хостовой защиты.
Вместо вывода
В первые часы после развёртывания NDR обычно подсвечивает не APT и не сложную постэксплуатацию, а инфраструктурный долг, теневое ИТ и позабытые костыли. В этом смысле NDR полезен не только как средство защиты, но и как инструмент наблюдения: он помогает увидеть, как сеть ведёт себя на самом деле.
LDAP без TLS, забытые сервисные учётки, внешние DNS, нестандартные порты, торренты, исполняемые файлы в неожиданных сегментах — всё это может годами накапливаться и не выглядеть как срочная проблема. Но именно такой фон расширяет поверхность атаки и мешает распознавать настоящие инциденты.
Думаю, у каждого, кто разбирал ложные срабатывания, есть своя любимая уязвимость. Расскажите в комментариях: какая находка съела у вас больше всего нервных клеток?
