ESCalator

::%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%2607874452 2. Часть после % перевести в HEX: 2607874452 dec = 9b710194 hex 3. Убрать слева два нуля, дописать справа полученные цифры с учетом обратного порядка байт: 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