🔍 ::%16777216 — это не ngrok-артефакт. Это баг Windows.

Если ты занимаешься DFIR или threat hunting'ом - ты наверняка встречал в логах Windows Event ID 1149 (TerminalServices-RemoteConnectionManager) адрес источника вида ::% 16777216 и думал, что это след ngrok или другого туннелирующего инструмента. Так вот - это не так. Точнее, не совсем так.

🐛 Что происходит на самом деле
Это баг в Windows, существующий как минимум с Windows 8 / Server 2012 и не исправленный вплоть до Windows 11 24H2 build 26100.8457.
Суть: при RDP-подключении через IPv6 termsrv.dll передаёт в GetNameInfoW (ws2_32.dll) указатель на структуру WTS_SOCKADDR - но читает её как sockaddr_in6. Проблема в несоответствии: WTS_SOCKADDR содержит 4 байта паддинга после sin_family, из-за чего IPv6-адрес клиента сдвигается на 4 байта вправо. В результате вместо реального адреса в лог пишется ::% 16777216, где 16777216 = 0x01000000 - это значение sin6_scope_id, которое интерпретируется как zone index от сдвинутого ::1 (localhost IPv6).

⚙️ Структуры для понимания
WTS_SOCKADDR:

USHORT sin_family;   // 2 байта
// padding            // 2 байта  ← вот виновник
union { ... }        // от offset 4

sockaddr_in6:

short  sin6_family;  // 2 байта
u_short sin6_port;   // 2 байта
u_long sin6_flowinfo;// 4 байта
struct in6_addr ...  // 16 байт
u_long sin6_scope_id;// 4 байта

rdpcorets.dll записывает IPv6-адрес клиента в WTS_SOCKADDR с одной структурой. termsrv.dll читает это как sockaddr_in6 с другой - смещение на 4 байта, адрес уезжает в sin6_scope_id, который и попадает в лог как % 16777216.

🧪 Как воспроизвести
Любой туннелинг через IPv6 на localhost (ssh -L, devtunnel, ngrok, localtunnel) → RDP-подключение → в Event ID 1149 будет ::% 16777216.
Это происходит не только с ngrok. Любое RDP-подключение через IPv6 localhost даст этот артефакт.

📋 Где проявляется
Event IDs: 1149, 4778, 4779 Журналы: TerminalServices-RemoteConnectionManager\Operational, Windows Logs\Security

🔧 Как восстановить реальный IPv6-адрес
Если в логе: 0:0:fe80::6e1d:980d%2607874452
Берём число после %: 2607874452
Конвертируем в HEX: 9B 71 01 94
Разворачиваем (little-endian): 94 01 71 9B
Дописываем к адресу справа: fe80::6e1d:980d:9401:719b
Реализуемо в любом SIEM через enrichment-правило.

📌 Выводы для DFIR
::% 16777216 - всегда признак RDP-подключения по IPv6 через туннель (localhost → порт 3389). Это остаётся валидным IoC для детекта reverse tunnel, независимо от того, ngrok это или ssh -L.
Значение само по себе не несёт информации о реальном клиенте - адрес нужно восстанавливать по алгоритму выше.
Microsoft квалифицировал как Moderate / Tampering, CVE не присвоен, патч не обещан (ответ от 08.11.2025). Исправлено тихо в Windows 11 24H2 build 26100.8457+ и 26H1.

🔗 Слайды: ёPRSTCON 2026, автор - Константин Грищенко, Positive Technologies.

🐦‍⬛ DFIR Father

🤖 AI нашел, а доказывать тебе.
Наткнулся на пост Бретта Шейверса (Brett Shavers), который зацепил. Если ты в DFIR и хоть как-то приглядываешься к AI - читать обязательно.
Если коротко: он собрал AI-ready машину, поднял локальную LLM, прогнал ее по тестовым данным и CTF. А результат его удивил и испугал одновременно.

⚡️ Что реально круто
Скорость. Модель пробегает данные, суммаризирует, группирует, вытаскивает аномалии - быстрее, чем человек руками. Бретт прямо говорит: кто делает вид, что эта штука не изменит DFIR, тот обманывает сам себя. И тут он прав.

☠️ А вот где засада
Как только он ушел от широкого обзора данных к вопросам уже по сути расследования, на естественном языке - посыпались фейлы. И фейлы не тупые, а правдоподобные.
Он специально скармливал модели плохие промпты и тянул ее к неверным выводам. Ответы он знал заранее, так что видел, где она врет. И она не подвела - уверенно шла в неправильную сторону, выдавая связные, убедительные ответы.
Вся проблема в том, что LLM заточена быть "helpful" и удобной, а не правдивой. Она дает тебе "ответ" и будет его защищать, даже когда он мимо.
С обычной автоматизацией (карвинг, фильтрация) ты на автомате идешь перепроверять, потому что данные сами по себе - еще не вывод. А LLM подает готовый вывод на блюде. Вот здесь и начинается опасность для дела и для карьеры.

🧠 Главная мысль
Знаешь дело, доказательную базу и пределы данных - AI разгонит тебя. Не знаешь, как примерно должен выглядеть правильный ответ - никогда не поймешь, повел он тебя верно, ошибся или просто подыграл, чтобы ты почувствовал себя умнее.
Это не "AI плохой". Это про порядок: сначала форензика, потом AI. Инструмент работает только в руках того, кто сам понимает, к чему он должен прийти.

📌 Что забрать в работу
• Не отдавай LLM решения по расследованию. Используй для ускорения там, где контекст у тебя уже в голове.
• Любой вывод модели - это гипотеза, а не факт. Подтверждай артефактами.
• Не можешь объяснить, почему AI прав - значит, в casework это тащить нельзя.
• Качай investigative mindset вне зависимости от тулзов. Инструменты меняются, данные меняются, AI меняется. Базовый навык - нет.

🔗 https://www.brettshavers.com/brett-s-blog/entry/forensics-first-ai-second

🐦‍⬛ DFIR Father

Текстовик в Windows 11, который палит запуск даже удаленных файлов 🔥
Иногда самые полезные артефакты лежат не в хитром бинарнике, который надо парсить три часа, а просто в текстовике, который никто не догадался открыть. Вот один из таких. Андреа Фортуна недавно напомнил про него, и для кейсов на 11 винде это очень актуально.

📂 Что это и где лежит
Начиная с Windows 11 22H2 Microsoft прикрутила к сервису Program Compatibility Assistant (тот самый PcaSvc, который живет еще со времен Vista) персистентную запись запусков в обычный текст:
C:\Windows\appcompat\pca\PcaAppLaunchDic.txt
Внутри - строки вида "полный путь к exe | UTC-таймстамп". Никакого проприетарного формата, никакого декодинга. Все читается глазами:

C:\Users\Alice\Downloads\Quarterly_Review.pdf.exe|2026-03-15 09:42:11.000
C:\Temp\tool.exe|2026-03-15 09:43:05.000
D:\AUTORUN\payload.exe|2026-03-15 09:44:22.000

Делалось это как обычно под compatibility-задачи, а не под форензику. Но как обычно бывает - фича для одного, а ценное доказательство для другого. 😙

🔍 Чем это интересно для форзы
Файл ловит запуски программ через Explorer - то есть когда юзер двойным кликом открыл файл. А это огромный пласт реальной малвари: распаковал ZIP, открыл "счет" из директории "Загрузки", оператор кинул тулзу в C:\Temp руками и запустил, техник прогнал утилиту с флешки.

Три жирных плюса:
• Отвечает на простой, но важный вопрос - этот exe реально запускали на хосте, или только скачали?
• Связывает алерт с активностью юзера.
• И главное - запись остается даже после удаления самого файла.
Третья строка в примере выше ⬆️:
D:\ - это съемный диск. То есть доставка через USB видна по одному только префиксу пути, без всякого пивотинга.

☠️ Anti-forensic значимость
Вот тут самое вкусное. Вся типовая чистка следов заточена под известные артефакты: чистят Prefetch, сносят LNK, вайпят recent items, гоняют коммерческие анти-форензик тулзы. А малоизвестные артефакты остаются нетронутыми просто потому, что атакующий о них не знает.
Представь кейс: подозрение на фишинг. Вложение удалено, скачанный файл удален, юзер божится что "только посмотрел документ и ничего не запускал". EDR дал слабый сигнал, Prefetch неинформативен из-за шума и ретеншена. Открываешь PCA - а там:
C:\Users\Alice\Downloads\Quarterly_Review.pdf.exe|2026-03-15 09:42:11.000
Одна строчка доказывает запуск (а не просто скачивание), путь с палевным двойным расширением .pdf.exe, и UTC-таймстамп, который коррелируется с почтой, браузером, DNS и process creation.

🛠 Как снимать и читать (Сам файл в UTF-16 LE, если что)
Быстрый триаж через PowerShell:

Get-Content -Path "C:\Windows\appcompat\pca\PcaAppLaunchDic.txt" -Encoding Unicode |
  Select-String -Pattern "Temp|Downloads|AppData|\\Users\\"

В KAPE путь уже есть в таргете !SANS_Triage. Заодно тащи соседей - они дополняют картину ошибками совместимости и завершениями процессов:

C:\Windows\appcompat\pca\PcaAppLaunchDic.txt
C:\Windows\appcompat\pca\PcaGeneralDb0.txt
C:\Windows\appcompat\pca\PcaGeneralDb1.txt

Для парсинга в пайплайне Харлан Карви запилил PCAParse.

⚠️ Важные оговорки
• Scope. Ловятся запуски ТОЛЬКО через Explorer. Стартанули из cmd, PowerShell, WMI, PsExec, шедулера или сервиса - в этом файле ничего не будет.
• Наличие записи сильно намекает на запуск через Explorer. Отсутствие записи не доказывает что не запускали. Это один источник в общей доказательной базе, а не истина в последней инстанции.

🎯 Плейбучим?
Лучшее время выучить новый артефакт - до того, как он понадобится в живом кейсе. Сейчас большинство анти-форензик тулз его не трогают. Советую потыкать на Win11 самому, прогнать запуск через Explorer, cmd, PowerShell, USB и сетевую шару, посмотри что и сколько хранится. Ну и если было полезно, то закинуть C:\Windows\appcompat\pca\ в свой таргет-коллект.

🔗 https://andreafortuna.org/2026/03/19/windows11-pca-artifact/
🔗 https://www.sygnia.co/blog/new-windows-11-pca-artifact/
🔗 https://windowsir.blogspot.com/2024/02/pcaparse.html

🐦‍⬛ DFIR Father

🆕 RoguePlanet - свежий 0-day в Microsoft Defender. Что там с точки зрения DFIR?)

🔥 Буквально вчера исследователь под ником Nightmare Eclipse выкатил PoC нового 0-day для Microsoft Defender - RoguePlanet. Он бьет по полностью пропатченным Windows 10 и 11, включая системы с июньскими апдейтами (KB5094126). На выходе - cmd.exe с правами SYSTEM. Как я понял, релиз - часть затяжного конфликта автора с Microsoft по поводу их практик disclosure и bug bounty.
Нам как форзерам это интересно не тем, КАК эксплуатировать, а тем, КАКОЙ след оно оставляет и как это детектить. 🔍

⚙️ Что под капотом?
• Это Time-of-Check to Time-of-Use в движке Defender (mpengine). Автор сам пишет, что на одних машинах 100% успех, на других не заводится вообще.
• Изначально это была RCE: жертву надо было заманить открыть .vhd(x) с удаленной SMB-шары, дальше Defender перезаписывал собственные файлы - и привет, выполнение кода 👀
• Второй сценарий RCE - открытие SMB-шары при включенной обработке симлинков.
• В середине мая MS тихо захарденил Defender, пропатчив mpengine!SysIO* и прикрыв junction-атаки. После этого RoguePlanet, по словам автора, возможно скатился до LPE.
• ThreatLocker подтвердили, что воспроизвели эксплойт на полностью пропатченной Win11. Application allowlisting его блокирует.
• Ключевой момент для нас: MsMpEng.exe (движок Defender) крутится под SYSTEM. Гонка в том, как он обрабатывает файлы / симлинки / reparse-поинты во время сканирования, позволяет заставить его действовать по контролируемому атакующим пути с правами SYSTEM. Отсюда перезапись файлов и эскалация.

🔍 Теперь, самое интересное, где это палится?
1️⃣ Аномальные дочерние процессы MsMpEng.exe. Движок Defender в норме НЕ порождает cmd.exe / powershell.exe / conhost. Если в Sysmon EID 1 видишь ParentImage, заканчивающийся на MsMpEng.exe, а в детях интерактивный шелл - это практически нулевой false positive. Первое, что надо завести в детект.
2️⃣ Монтирование VHD/VHDX из недоверенных мест.
• Microsoft-Windows-VHDMP/Operational - события attach/surface образа.
• Открытие .vhd(x) с UNC-пути, WebDAV или SMB-шары - смотри командные строки и Explorer-активность.
• Коррелируй с Microsoft-Windows-SMBClient/Connectivity и логами доступа к шаре. VHD(x) с удаленной шары + следом активность Defender = красный флаг под этот сценарий.
3️⃣ Целостность каталога Defender. Перезапись собственных файлов Defender - часть механики. Ставь file integrity monitoring на: C:\ProgramData\Microsoft\Windows Defender\Platform\. Неожиданные модификации/перезаписи бинарей платформы не-Defender-процессом - повод копать.
4️⃣ Reparse points / junctions как индикатор. Создание junction/symlink в путях, которые сканирует Defender, с последующими быстрыми файловыми операциями - поведенческий признак TOCTOU. Sysmon FileCreate + аномальная плотность операций по таймстампам.
5️⃣ Краши и рестарты mpengine
• WER-отчеты по MsMpEng.exe.
• Рестарты сервиса Defender, ошибки в Microsoft-Windows-Windows Defender/Operational. Гонка штука нестабильная - неудачные попытки часто роняют или дергают движок, и это само по себе сигнал.

🧰 Триаж-чеклист на хосте
• Дерево процессов вокруг MsMpEng.exe (родитель/дети) за окно инцидента.
• VHDMP/Operational + SMBClient логи на предмет remote VHD(x).
• Таймлайн модификаций в ...\Windows Defender\Platform\.
• Шелл из-под SYSTEM с подозрительным parent.
• Новые админ-аккаунты, сервисы, задачи планировщика сразу после получения SYSTEM (стандартный post-exp, ну и дальше по цепочке).

📌 Самый дешевый и надежный детект - дочерний шелл от MsMpEng.exe, думаю можно заводить прямо сейчас. А остальное (remote VHD, целостность Platform, краши движка) идет вторым контуром под корреляцию.

🔗 https://www.bleepingcomputer.com/news/microsoft/microsoft-defender-rogueplanet-zero-day-grants-system-privileges/
🔗 https://github.com/MSNightmare/RoguePlanet

🐦‍⬛ DFIR Father

❗️❗️❗️ GreatXML - второй 0-day за месяц от Nightmare Eclipse. На этот раз BitLocker
"I may have just made the Greatest XML in all of XML history. Two zerodays this month, hope I can do more next month" - Nightmare Eclipse

🤪 Помните вчерашнего исследователя, который выкатил RoguePlanet?)
Так вот, он не стал ждать следующего месяца. Второй публичный 0-day - GreatXML. 😳
И это уже BitLocker bypass. Полностью через unattend.xml в разделе восстановления.

⚙️ Как это работает (*FOR EDUCATIONAL PURPOSES*)
Механика элегантно простая - без эксплойтов в классическом смысле, чистая злоупотреблением легитимным механизмом Windows:
1. Копируешь unattend.xml и папку Recovery в корень раздела восстановления (WinRE).
2. Ребутишь машину в WinRE через Shift + Restart.
3. Если на машине когда-либо запускался Defender Offline Scan - логин не нужен вообще. Машина сразу уязвима.
4. На выходе - шелл с неограниченным доступом к BitLocker-тому. Шифрование фактически не защищает данные.
❗️ Ключевой момент: unattend.xml - это легитимный файл автоматизации установки Windows (Unattended Setup). WinRE его подхватывает и обрабатывает с привилегиями, достаточными для обхода BitLocker. Microsoft не считает это проблемой на уровне своих текущих критериев - и поэтому патча пока нет.

🔍 Чем это полезно для форзеров?
Для нас тут несколько интересных вещей:

1️⃣ Первое - физический доступ, но с нюансом. Классический аргумент "если у атакующего физический доступ к машине, игра окончена" тут работает, но с оговоркой: вектор через Defender Offline Scan делает машину уязвимой даже если сам атакующий не инициировал scan. Достаточно что его когда-либо запускал пользователь или администратор.

2️⃣ Второе - артефакты в WinRE. Если атака произошла, следы будут именно там. После эксплуатации смотреть на:
• Раздел WinRE на предмет посторонних файлов - unattend.xml и папка Recovery в корне раздела восстановления там быть не должны в штатной конфигурации.
• Логи переходов в WinRE: Microsoft-Windows-Diagnostics-Performance/Operational, события загрузки в System лог.
• Если был физический доступ - смотри на временные метки файлов в разделе восстановления и коррелируй с последним временем работы системы.

3️⃣ Третье - BitLocker-том был смонтирован. После получения доступа к тому атакующий мог читать/копировать файлы. Индикаторы на уровне файловой системы: временные метки последнего доступа к файлам (Last Accessed), артефакты подключения внешних носителей (если данные копировались), USN Journal на предмет операций чтения/копирования в интересующем временном окне.

4️⃣Четвертое - Defender Offline Scan как пре-условие. Факт его запуска фиксируется: Microsoft-Windows-Windows Defender/Operational, Event ID 2050 (scan started). Если в ходе расследования ты видишь что Offline Scan запускался - машина потенциально была уязвима к этому вектору в любой момент после этого.

🛡 Что делать прямо сейчас
• Проверить конфигурацию WinRE на прод-тачках - в разделе восстановления посторонних XML и папок быть не должно.
• Убедиться что физический доступ к машинам ограничен (банально, но именно здесь и решается).
• Включить BitLocker PIN при загрузке (не только TPM) - это усложняет вектор через WinRE, так как требует дополнительной аутентификации до этапа где отрабатывает уязвимость.
• Если Secure Boot + UEFI password настроены - это дополнительный барьер против загрузки в модифицированный WinRE.

⁉️ Два 0-day за месяц от одного исследователя - это уже заявка. Причем оба без CVE и без патча на момент публикации. MS закрыл GreenPlasma и YellowKey (предыдущая серия), но GreatXML и RoguePlanet пока висят открытыми. Nightmare Eclipse прямо говорит что продолжит - ну следим, чо)

Ну и с вас реакция за реактивный разбор уязы (на момент написания поста прошло 13 часов с момента публикации) 🙊

🔗 https://github.com/MSNightmare/GreatXML

🐦‍⬛ DFIR Father