Текстовик в 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