Зашифровано не значит невидимо: как искать угрозы без расшифровки

Ничего не видно: слишком удобный вывод

Долгое время сетевой анализ опирался на сведения, которые оставались открытыми даже при зашифрованном соединении. Например, имя сервера в поле SNI помогало понять, к какому ресурсу обращается узел, хотя содержимое сессии было недоступно. В TLS 1.3 часть рукопожатия уже защищена, а принятый в этом году стандарт RFC 9849 (определяет Encrypted Client Hello) дает возможность скрыть еще и SNI.

Из-за этого работа команд ИБ постепенно смещается от прямых признаков к поведению соединения. Аналитик смотрит на продолжительность, объемы, частоту обращений, сертификаты, отпечатки клиента и сервера. Но здесь легко ошибиться, если оценивать каждый параметр отдельно: легитимное приложение иногда выглядит подозрительно, а аккуратно настроенный канал атакующего почти не отличается от штатного обмена. Значение появляется, когда несколько признаков совпадают и укладываются в историю конкретного узла.

И тут возникает управленческая ловушка. В зашифрованном трафике часто можно найти следы злоумышленника, но нередко делают следующий вывод: раз содержимое не видно, анализировать соединение бессмысленно. Отсюда появляется и сомнение в самом классе NTA, который не занимается сплошной дешифровкой.

Но задача сетевого анализа и не сводится к тому, чтобы вскрыть каждую сессию. Важно понять, что делает узел, с кем он взаимодействует и насколько это похоже на его обычное поведение. Именно по таким косвенным признакам сегодня распознают трафик отдельных мессенджеров и VPN-сервисов без доступа к содержимому. На практике это особенно заметно в тех сценариях, где атака не ломает правила сети, а прячется внутри разрешенного обмена.

Что прячется внутри легитимных протоколов

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

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

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

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

Слабые признаки складываются в сильную картину

После таких сценариев главный вопрос уже не в том, виден ли вредоносный код в трафике. Чаще его как раз не видно. Важно, какие следы остаются вокруг соединения. Даже при пассивном наблюдении за TLS остаются данные рукопожатия ClientHello и ServerHello. По отпечаткам JA3/JA3S или более современным JA4+ с высокой вероятностью можно понять, какое приложение, клиент или серверный стек участвует в обмене. Дальше начинается поведенческая часть: направление сетевых соединений, объемы, частота обращений и длительность сессий.

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

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

Когда одного сетевого следа мало

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

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

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

С чего начать

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

Второй шаг — составить карту слепых зон. В любой инфраструктуре есть сегменты, трафик которых не попадает в сетевую телеметрию: удаленные площадки, подключения через VPN, отдельные облачные сервисы или подрядные зоны. Их нужно включать в контур наблюдения не только за счет сетевых сенсоров, но и через дополнительные источники данных, в первую очередь логи с узлов, приложений и средств удаленного доступа.

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

Видимость нужно закладывать до инцидента

Шифрование будет развиваться дальше, и часть признаков, доступных без расшифровки, будет постепенно уходить из поля зрения аналитика. Это не сбой и не угроза сама по себе: бизнесу нужно защищать данные, клиентов и внутренние сервисы. Просто командам ИБ придется окончательно привыкнуть к тому, что соединение все реже объясняет, что происходит внутри него.

В такой ситуации выигрывает не тот, кто пытается вскрыть все подряд, а тот, кто заранее понимает свою сеть. Где стоят точки наблюдения, какие сегменты выпадают из телеметрии, какие логи можно получить за нужный период, связаны ли события на узле с пользователем и сетевой активностью. Проверка из предыдущего шага как раз показывает, есть ли у компании такая опора или расследование начнется с пустого места. Именно на этом старте часто теряется время: команда сначала пытается понять, куда идти, какие узлы проверять глубже и какие действия могли быть частью одной цепочки. Без этой связки шифрование действительно превращается в темную зону. С ней содержимое может оставаться закрытым, но ритм соединений и изменение поведения все равно дают материал для расследования.

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