::%16777216 — так что же ты такое?Известно, что в ходе атак злоумышленники могут использовать
туннелирование. Например, прокинуть обратный туннель со взломанного Windows-хоста в глубине сети организации, чтобы с его помощью легко подключиться интерактивно по RDP к этому же хосту.
Методы выявления такой активности также известны. Например, стоит обязательно обращать внимание на наличие в логах IP-адресов
127.0.0.1 или
::1 в качестве источника — именно с таких адресов в пределах атакованной системы могут устанавливаться подключения к целевым сервисам.
😳 Много лет специалисты, расследовавшие взломы, отмечали и описывали в отчетах, что когда в подобных атаках для туннеля использовался ngrok, при подключении по RDP в логах вместо IP-адреса источника заносилось странное значение —
::%16777216.
С одной стороны, это отличный артефакт, который легко искать: он вряд ли встречается в нормальной активности и поэтому его наличие служит хорошим и довольно точным индикатором атаки.
Но, с другой стороны, нигде не было понятного объяснения, что это за «магическое число», почему именно оно возникает в логах и всегда ли это признак использования именно ngrok.
😎 Мы решили разобраться, и нам удалось получить ответы:🔴 ::%16777216 появляется в логах в событии
1149 (а еще
4778 и
4779) вместо IP-адреса
::1 в результате ошибки в Windows.
🔴 Ошибка не связана с наличием какой-либо уязвимости, а вызвана несогласованной интерпретацией данных в памяти разными модулями протокола RDP
🔴 Ошибка возникает не только с адресом
::1, но и в любом другом случае, когда происходит подключение к RDP с использованием протокола IPv6 (например, вместо адреса
fe80::6e1d:980d:9401:719b вы увидите в логах строку
0:0:fe80::6e1d:980d%2607874452)
🔴 Проблема чаще всего связывалась с утилитой ngrok, так как в ходе туннелирования она создает подключение на узле с использованием IPv6 по умолчанию, в отличие от многих других утилит, которые используют IPv4.
🔴 Адрес в логах «портится» не безвозвратно, его можно восстановить:
1. Взять значение из лога:
0:0:fe80::6e1d:980d%26078744522. Часть после
% перевести в HEX:
2607874452 dec = 9b710194 hex3. Убрать слева два нуля, дописать справа полученные цифры с учетом обратного порядка байт:
fe80::6e1d:980d:9401:719bОшибка существовала как минимум начиная с Windows Server 2012 R2 во всех версиях Windows. В начале лета 2025 года мы направили информацию об этом в Microsoft, и результаты недавних тестов показывают, что в актуальных версиях (с майскими обновлениями 2026 года) ошибка была исправлена (ответа о факте исправления мы не получили).
А о нюансах исследования, интересных подробностях представления IP-адресов и подходах к проведению экспериментов, которые помогли найти объяснение, автор рассказал в докладе на прошедшей в мае конференции ËPRSTCON — запись доклада, презентацию и расшифровку ищите
на сайте конференции.
И что же теперь делать? 😨1️⃣ В старых версиях Windows, которые уже не получают обновлений, продолжать обращать внимание на
::%16777216 в логах.
2️⃣ В актуальных версиях Windows, где, возможно, были установлены обновления, дополнительно проверять на наличие
::1 там, где такого адреса не должно быть в норме.
3️⃣ Учитывайте, что есть множество различных утилит для создания туннелей, и подобный индикатор никак не подтверждает использование именно ngrok.
0️⃣ По желанию — доработайте свой парсинг логов так, чтобы восстанавливать нормальный IP-адрес: это поможет учитывать адрес в корреляционных правилах и получать больше релевантных результатов при ретроспективном поиске событий или тредхантинге.
P.S.: и не забывайте обращать внимание на появление
127.0.0.1 в неподходящих местах.
P.P.S.: и не только
127.0.0.1, а любого адреса из сети
127.0.0.0/8: все эти адреса соответствуют интерфейсу
localhost согласно
RFC5735, и это работает во всех популярных ОС. Использовать как источник адрес типа
127.0.13.37 у злоумышленника вряд ли легко получится, а вот указывать в качестве назначения подобные адреса для подключения к процессам на локальном хосте — вполне.
#tip #win@ptescalator 