::%16777216 в RDP-логах: почему вместо IP появляется "пустота" и что с этим делать
В журналах RDP-подключений иногда встречается на первый взгляд бессмысленная строка - `::%16777216`. Она попадает в поле, где обычно ожидаешь увидеть понятный IPv4/IPv6-адрес клиента. Этот артефакт не новость: его упоминают в отчётах и разборках инцидентов уже несколько лет, особенно в сценариях, где RDP "протягивают" через туннель. Чаще всего рядом всплывает ngrok, но объяснение природы значения обычно остаётся за кадром - как будто это несущественная деталь. На практике же такая "мелочь" напрямую влияет на аудит RDP подключений и качество расследований.
Где именно появляется аномалия
Речь о событии EventID 1149 в журнале:
Microsoft → Windows → TerminalServices-RemoteConnectionManager → Operational.
Оно фиксируется уже после установления сетевого соединения с RDP-службой (до полноценного интерактивного сеанса). В типичной ситуации EventID 1149 содержит три ключевые части: домен/пользователь, указанные клиентом, и адрес источника. И именно адрес иногда превращается в `::%16777216` - причём и в обычном представлении, и внутри XML события. То есть это не каприз интерфейса просмотра логов и не "кривой парсер".
Во многих инцидентах такая запись встречается при подключениях через туннель (в частности, через ngrok): злоумышленник поднимает внешний вход в туннель, а дальше "подкладывает" RDP-трафик на внутренний хост. В итоге при RDP логи анализ дают странное ощущение: подключение было, учётка указана, но кто инициатор - будто бы "никто".
Почему это не "нестандартная запись IP"
Первая логичная мысль: может, Windows просто записала IP в необычном формате.
С IPv4 действительно есть свобода: это 32-битное число, и помимо привычной записи через точки встречаются варианты в виде одного целого, шестнадцатеричного или восьмеричного представления - многие сетевые библиотеки исторически принимают такие формы.
С IPv6 вариантов ещё больше. Адрес можно сокращать (двойное двоеточие для цепочек нулей), а в Windows есть и "литеральная" форма для ситуаций, где двоеточия неудобны (например, в UNC-путях): двоеточия заменяются на дефисы, а в конце добавляется суффикс `.ipv6-literal.net`.
Но всё это плохо объясняет главный маркер: знак процента.
Ключ к разгадке - zone index (scope id)
Процент в IPv6-строке обычно означает zone index / scope id - индекс зоны (интерфейса), который помогает ОС понять, к какому сетевому интерфейсу относится адрес, если адрес link-local или вообще требует уточнения области видимости. В повседневной жизни это выглядит как `fe80::1%12`, где `12` - номер интерфейса (условно).
И вот здесь `::%16777216` начинает выглядеть не как "IP-адрес", а как комбинация:
- `::` - unspecified address (неопределённый IPv6-адрес, фактически "пустое место");
- `%16777216` - какой-то scope id, причём подозрительно большой для обычного индекса интерфейса.
То есть Windows по какой-то причине записывает не реальный удалённый адрес, а "неопределённый IPv6 + числовой идентификатор зоны". В нормальном сетевом мире это почти никогда не то, что хочется видеть в поле "Client IP".
Что именно "ломает" адрес при туннелировании
На практике такие артефакты чаще проявляются, когда между клиентом и целевым хостом появляется прослойка, которая меняет модель соединения: прокси, туннель, ретранслятор, порт-форвардинг. При ngrok и подобных инструментах удалённый адрес, который видит RDP-служба на целевой машине, может перестать быть "настоящим адресом клиента" и превратиться в адрес узла-ретранслятора или вообще в адрес локального участка цепочки.
Дальше вступают в игру особенности стека Windows и конкретного компонента журналирования RDP: в некоторых сценариях он получает структуру адреса так, что в лог уходит не корректно заполненный IP, а комбинация `::` и scope id. Результат - `::%16777216`. С точки зрения расследования это неприятно, но важно понимать: это не "маскировка" как таковая, а побочный эффект того, как в цепочке обрабатываются адреса и как RDP-компонент затем сериализует их в событие.
Если вам нужно быстро свериться с практическими наблюдениями и контекстом SOC-расследований, полезно держать под рукой материал про мониторинг RDP подключений и типовые следы туннелирования в Windows-среде.
Почему это важно для SOC и корреляций
`::%16777216` ломает привычные правила детекта:
- нельзя нормально обогащать событие геолокацией;
- не работают списки запрещённых подсетей и "неожиданных стран";
- трудно связать попытку входа с сетевыми телеметриями (NDR/Firewall/Proxy), где IP может быть виден иначе;
- растёт доля "неатрибутируемых" событий, которые тонут в потоке.
Поэтому в SOC приходится компенсировать этот пробел другими сигналами - и именно здесь особенно полезна SIEM для Windows RDP, которая умеет собирать несколько типов событий и клеить их в единую цепочку.
Что делать: практические шаги в детекте и расследовании
1) Не полагаться только на EventID 1149.
Для расследований дополняйте картину событиями успешной/неуспешной аутентификации (например, 4624/4625), событиями терминальных служб, а также журналами безопасности и сетевыми данными. Даже если в 1149 адрес "сломался", в соседних событиях он может сохраниться иначе.
2) Строить корреляции "туннель → RDP".
Для защита от RDP атак полезны правила, которые ищут не только RDP-события, но и признаки самого туннеля: необычные исходящие соединения, DNS-активность к доменам туннельных сервисов, подозрительные процессы/службы на хосте, появление новых автозапусков.
3) Сегментировать и ограничивать RDP.
Классика, но работает: RDP должен быть доступен только с jump-хостов/админских подсетей, под MFA/Conditional Access (если применимо), с NLA, с жёсткими firewall-правилами. Тогда даже при туннелировании злоумышленнику будет сложнее "приземлиться" на нужный порт.
4) Отдельно помечать `::%16777216` как риск-маркер.
В потоке логов такая строка - повод повышать приоритет проверки. Это не стопроцентный индикатор ngrok, но отличный триггер для углублённого аудит RDP подключений: кто логинился, в какое время, с какой частотой, были ли параллельно неуспешные попытки, откуда стартовали процессы и т. п.
5) Нормализовать обработку в SIEM.
В правилах парсинга стоит учитывать, что поле "IP" может содержать IPv6 со scope id. Для отчётности и поиска удобно сохранять это значение в отдельное поле (как "raw_client_address"), а также выделять `%zone` в дополнительный атрибут - так проще делать фильтрацию и статистику.
Ещё один практический разбор того, как SOC-команды подходят к таким аномалиям и выстраивают цепочки событий, хорошо ложится в канву материалов про SIEM для Windows RDP - особенно когда "чистого" клиентского IP в одном конкретном событии может не оказаться.
Итоги
`::%16777216` - не магия и не "тайный IP", а симптом того, что в конкретной точке журналирования Windows вместо нормального адреса оказалась IPv6-заглушка `::`, дополненная scope id. Чаще всего это всплывает в сценариях туннелирования, где реальный адрес клиента теряется или искажается на промежуточных узлах. Для SOC это означает простое правило: при RDP логи анализ нельзя опираться на один-единственный лог, а детект стоит строить на связке событий, сетевой телеметрии и контекстных индикаторов - тогда даже такие "пустые адреса" не помешают расследованию и укрепят защита от RDP атак.