Локальное повышение привилегий в Windows 11 через функцию Microsoft Recall
#Windows #LPE #RCE #EoP #TotalRecall

До января 2026 года в Windows 11 (даже при отключенной функции Microsoft Recall) висела запланированная задача \Microsoft\Windows\WindowsAI\Recall\PolicyConfiguration, выполняемая от имени NT AUTHORITY\SYSTEM. Через COM-интерфейс IFileOperation задача рекурсивно удаляла директории в профиле пользователя по пути: %USERPROFILE%\AppData\Local\CoreAIPlatform.00\UKP\{GUID}. При этом не выполнялась корректная проверка симлинков, junction points и финального разрешенного пути. Это открывало возможность link following атаки.

♾️Эксплуатация♾️

Для атаки достаточно профиля пользователя с минимальными правами.

▪️Низкопривилегированный пользователь создает в своем профиле директорию в целевом пути Recall (GUID-имя).
▪️Через симлинки или junction points + oplock перенаправляет операцию удаления на системный путь (C:\Config.Msi и т.п.).
▪️Обновляет соответствующее состояние WNF, что инициирует выполнение задачи.
▪️Во время удаления oplock позволяет выполнить манипуляцию путем, операция в контексте SYSTEM применяется уже к перенаправленному объекту.
▪️Удаление C:\Config.Msi инициирует MSI rollback, в ходе которого исполняется контролируемый атакующим код от имени SYSTEM.

♾️Статус♾️

В январском обновлении Microsoft переработала логику удаления: отказалась от использования IFileOperation, перешла на низкоуровневые NT API (NtCreateFile, GetFinalPathByHandle, SetFileDispositionInformation) и добавила корректную проверку финального канонического пути перед удалением. В новых версиях задача корректно разрешает реальный путь объекта и блокирует атаки через симлинки, junction points и oplock-манипуляции.

🔗Источник и PoC

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Как безобидные ennoscriptments для JIT превратить в примитив обхода macOS-защиты
#macOS #JIT #AppSec #EndpointSecurity

В macOS механизм Hardened Runtime ограничивает выполнение неподписанного кода и изменение прав страниц памяти. Однако для поддержки легитимной динамической генерации кода (JIT в браузерах, Electron и т.п.) Apple ввела специальные ennoscriptments, такие как com.apple.security.cs.allow-jit, разрешающие использование JIT-памяти.

Это создает контролируемое исключение из общей модели W^X: обычные процессы не могут свободно создавать исполняемую память или переключать страницы в RX/RWX, но приложения с соответствующими ennoscriptments получают доступ к механизму MAP_JIT. В результате процесс с такими привилегиями может использовать их не только для JIT-компиляции, но и для выполнения произвольного кода в памяти.

♾️Эксплуатация♾️

▪️Найти подходящее приложение: выбрать процесс с ennoscriptment com.apple.security.cs.allow-jit (или аналогичными allow-unsigned-executable-memory, disable-executable-page-protection).
▪️Получить выполнение кода внутри процесса: через макросы Office, уязвимость в приложении, инъекцию или иной вектор, допустимый в контексте процесса.
▪️Выделить JIT-память: вызвать mmap(..., PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_JIT, ...) и получить регион, разрешенный для записи.
▪️Записать шеллкод: скопировать произвольный код или reflective loader в выделенный регион.
▪️Переключить режим защиты: вызвать pthread_jit_write_protect_np(1) — регион становится RX (исполняемым), запись запрещается.
▪️Запустить код: выполнить переход на адрес шеллкод или создать поток через pthread_create(...). Код выполняется с привилегиями текущего процесса.

Произвольный код исполняется полностью в памяти без записи исполняемых файлов на диск и без нарушения механизма code signing, используется легитимный JIT-механизм.

♾️Защита♾️

▪️Не выдавать allow-jit, allow-unsigned-executable-memory, disable-executable-page-protection без необходимости.
▪️По возможности использовать более строгую модель JIT-контроля.
▪️Мониторить использование MAP_JIT, подозрительные mmap/mprotect и вызовы pthread_jit_write_protect_np.
▪️Минимизировать ennoscriptments и применять Hardened Runtime максимально строго.
▪️EDR должен выявлять reflective execution в JIT-регионах и аномальные загрузки dylib.

🔗Источник и PoC

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Весеннее обострение для CTF-еров: DUCKERZ Season & RedShift.Eclipse-3
#CTF #infosec #DUCKERZ #МИРЭА

Март стартовал, и сразу два крупных события для тех, кто не прочь поломать что-нибудь легально.

🐥 DUCKERZ - Весенний сезон
На платформе запустили сезонную механику. С 1 марта по 31 мая - новые таски, сезонный рейтинг и борьба за топ-10.
Спонсор сезона - Standoff Bug Bounty.
Призы: Raspberry Pi за первое место + мерч DUCKERZ, а топ 2-10 получат набор мерча Standoff (футболки, худи, брелоки).

👉 Страница сезона 👈

——————

🖥️ RedShift.Eclipse-3
13-15 марта пройдёт онлайн-отбор ZeroPlusCTF (task-based, команды 2-4 человека). Лучшие команды попадут в очный финал.

➡️ Регистрация: zeroplus.redshiftctf.ru
➡️ Нет команды? Ищи в чате

16 мая - финал в Москве, Defense CTF на платформе AvoidAttack. Площадка - Колледж программирования и кибербезопасности РТУ МИРЭА (1-й Щипковский пер., 23, стр. 1).
Параллельно с финалом будет очный MeetUp с докладами от спецов из ИБ-компаний. Как это выглядело раньше - тут и тут.

🔗 Подробности: redshiftctf.ru

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Кратко о влиянии запрета на использование англицизмов 😭

«Забытый» баг: TOCTOU в ClientRequest Node.js допускает HTTP request splitting
#NodeJS #HTTP #TOCTOU #CRLF #AppSec #WebSecurity

В реализации ClientRequest в Node.js обнаружен старый логический дефект — TOCTOU позволяет обойти первичную валидацию path и внедрить CRLF-последовательности в строку запроса. Проблема исторически пересекается с мерами, введенными при исправлении CVE-2018-12116 (ограничения на непечатаемые/Unicode-символы).

♾️Технические особенности♾️

При создании запроса через http.request(options) Node.js валидирует options.path (включая запрет \r и \n) для предотвращения инъекций в request line.

При этом есть несколько «но»:

▪️Проверка выполняется при создании объекта ClientRequest и далее может не повторится, зависит от версии Node.js
▪️this.path — обычное изменяемое поле JS-объекта (не заморожено), то есть хранится как обычное JS-свойство
▪️После создания объект может быть изменен сторонним кодом, например, middleware/прокси-логикой
▪️При формировании request line используется текущее значение this.path, повторная строгая валидация зависит от версии Node.js

Если между созданием и отправкой path будет изменен на строку с \r \n, эти символы могут попасть в сетевой трафик, что потенциально приведет к request splitting или header injection (в зависимости от версии).

♾️Эксплуатация♾️

▪️Приложение использует прокси-логику, где path формируется из пользовательского ввода.
▪️В URL закодированы CRLF: /proxy/something%0D%0AHost:%20evil.com%0D%0A...
▪️Библиотека декодирует %0D%0A → \r \n и перезаписывает proxyReq.path = decoded.
▪️Первичная проверка path уже пройдена на «чистом» значении.
▪️При отправке формируется строка вроде: GET /something\r\nHost: evil.com\r\n... HTTP/1.1\r\n...
▪️Downstream-сервер, в зависимости от парсера и конфигурации, может интерпретировать это как инъекцию заголовков или как несколько отдельных запросов.

♾️Импакт♾️

▪️Подмена Host или добавление своего заголовка Authorization
▪️Доступ к внутренним эндпоинтам, например, /admin
▪️Инъекция дополнительных заголовков
▪️Классическое request splitting без обязательной десинхронизации, как при smuggling

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Подкаст "Кибер Трукрайм" от Kaspersky GReAT
#podcast #kaspersky #cybercrime

Наткнулся на спецсезон подкаста от Kaspersky GReAT - разбирают самые громкие кейсы в истории кибербеза. Первый выпуск про ту самую эпидемию, где уязвимость в Microsoft чуть не положила мировую инфраструктуру.

Там классная подача: уязвимость в проде, злоумышленники с непонятной мотивацией, рандомный хакер, который почти случайно все спас. Среди гипотез о том, что вообще происходило и зачем, не хватает разве что инопланетян. Серьезно.

Ведут Дмитрий Галов (руководитель GReAT в России/СНГ) и Борис Ларин (исследователь GReAT, копал Operation Triangulation). Оба в теме, слушать интересно.

🔗Слушать подкаст можно на Яндекс.Музыке, Apple Podcast или на другой удобной вам платформе.

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

От .winget до reverse shell: новая атака через легитимный менеджер пакетов Microsoft
#WinGet #DSC #InitialAccess #RedTeam #Windows

Еще один способ запуска произвольного PowerShell-кода в Windows через легитимные инструменты. На этот раз используется winget (Windows Package Manager) и его функция Desired State Configuration (на базе PowerShell DSC). При определенных условиях двойной клик по специально сформированному .winget-файлу или self-referencing LNK может позволить обойти Mark of the Web и предупреждения SmartScreen. То есть winget выступает как LOLBIN для начального доступа, загрузки и запуска вредоносного кода под видом легитимной конфигурации системы.

♾️Технические особенности♾️

Атака использует файловую ассоциацию .winget → winget.exe configure "%1" --wait, которая запускает PowerShell Desired State Configuration (DSC v3+). DSC позволяет декларативно выполнять действия через ресурсы вроде: Invoke-WebRequest (скачивание), Archive (распаковка), WindowsProcess / Script (запуск процессов или кода), изменение реестра и переменных среды. Модули DSC автоматически загружаются из PowerShell Gallery в %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules. Исполнение происходит через ConfigurationRemotingServer.exe с использованием PowerShell runtime (System.Management.Automation).

Поскольку выполнение инициируется через легитимный инструмент системы, это может снижать эффективность некоторых механизмов защиты и выглядеть как обычная конфигурация системы.

Эксплуатация

▪️Доставить ZIP с malicious LNK (например через HTML smuggling)
▪️Потенциальная жертва распаковывает архив в %TMP% или Downloads и кликает по LNK
▪️Запускается команда LNK:

cd %TMP%\*update.zip* || cd %HOMEPATH%\Downloads\update

▪️LNK извлекает встроенный конфиг:

more +1349 *.lnk > %TMP%\conf.yml

▪️Открывается decoy-документ start https://attacker/decoy.pdf
▪️При необходимости включается конфигурация winget configure --enable
▪️После этого применяется конфиг:

echo Y | winget configure -f %TMP%\conf.yml

▪️DSC скачивает, распаковывает и запускает полезную нагрузку.

♾️Импакт ♾️

Позволяет получить первоначальный доступ и закрепиться в корпоративных средах, где Microsoft Store и winget не отключены. Через DSC атакующий может загрузить и выполнить полезную нагрузку, модифицировать систему и запускать код без явного вызова powershell.exe.

♾️Защита ♾️

▪️Отключить WinGet через GPO
▪️Отключить параметр EnableWindowsPackageManagerConfiguration
▪️Удалить ассоциацию .winget или заблокировать ее через AppLocker / WDAC
▪️Применить WDAC / Application Control для блокировки winget configure

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Android без -fstack-check: неограниченная рекурсия через Binder RPC + LPE из shell в system_server
#Android #LPE #stackoverflow#BinderRPC

В Android нативный код системных компонентов компилируется без защиты от stack clash, поэтому при глубокой рекурсии указатель стека может перепрыгнуть guard-страницу и попасть в отображенную память ниже стека. В результате стек фактически продолжает расти за пределами охраняемой области, что позволяет обойти защиту при вызове функций с большим стековым фреймом, например, android::incfs::MountRegistry::Mounts::loadFrom(), где используется локальный буфер ~128 КиБ.

Атакующий из контекста shell может использовать вложенные синхронные Binder RPC, чтобы неограниченно увеличивать глубину стека одного потока system_server. После этого вызывается функция с крупным стековым выделением, что приводит к перезаписи сохраненных данных в stack frame, захвату управления и потенциальному LPE из shell в system_server.

♾️Эксплуатация♾️

▪️Из shell запускаются команды вроде am dumpheap или trace-ipc stop, что приводит к вызову ShellCallback.openFile в system_server.
▪️В реализации openFile рекурсивно инициируются дополнительные shell-команды, углубляя стек до нужного размера.
▪️Ниже текущего положения стека спреятся контролируемые данные (например через Bitmap и IClipboard.setPrimaryClip) в shared memory.
▪️Далее триггерится функция с большим стековым фреймом (например цепочка incremental_service → isFileFullyLoaded → loadFrom()).
▪️Большая аллокация стека перепрыгивает guard region и перезаписывает сохраненный link register (LR) до его восстановления → происходит захват PC (часто наблюдается краш с PC = 0xaaaaaaaa).
▪️Эксплуатация повторяется до успеха (race condition, вероятность ~5–10% на попытку).

Вероятность успешной эксплуатации относительно низкая из-за рандомизации размещения стеков потоков и памяти.

Эксплойт из исследования подтвержден на конкретной сборке Pixel 7 (Android 16).

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Закрепляемся в macOS через баги в IPVanish VPN
#IPVanishVPN #macOS #LPE #XPC #PrivilegeEscalation

Приложение IPVanish VPN для macOS содержит критическую уязвимость повышения привилегий, позволяющую любому непривилегированному локальному процессу выполнить произвольный код от имени root. Для эксплуатации достаточно локального доступа к системе, на которой установлен клиент IPVanish.

♾️Технические особенности♾️

Основная проблема заключается в отсутствии аутентификации XPC-клиентов в привилегированном вспомогательном инструменте com.ipvanish.osx.vpnhelper. Любой локальный процесс может установить соединение с этим хелпером и отправлять ему команды.

Уязвимость усиливается двумя дополнительными проблемами:

▪️Параметр OpenVPNPath — указывает бинарный файл, который хелпер запускает от имени root через GCDTask. Значение параметра принимается напрямую из XPC-сообщения без проверки пути или подписи кода, что позволяет запускать произвольные файлы от имени root.

▪️Ошибка проверки подписи кода — хелпер-инструмент проверяет подпись только для исполняемых файлов. Неисполняемые скрипты можно скопировать в каталог, принадлежащий root, после чего хелпер меняет им права и выполняет их через механизм OpenVPN hook --up, создавая дополнительный путь выполнения кода.

♾️Эксплуатация♾️

▪️Создать вредоносный shell-скрипт /tmp/ipvanish_exploit.sh с правами 0644 (неисполняемый), чтобы обойти проверку подписи.
▪️Установить XPC-соединение с com.ipvanish.osx.vpnhelper без аутентификации клиента.
▪️Отправить XPC-сообщение с VPNHelperCommand = VPNHelperConnect, указав параметр
OpenVPNPath = /tmp/ipvanish_exploit.sh.
▪️Установить параметры OpenVPNUpScriptPath и OpenVPNCertificatePath на /tmp/ipvanish_exploit.sh, что приводит к вызову copyHelperTool.
▪️Вспомогательный инструмент копирует скрипт в каталог /Library/Application Support/com.ipvanish.osx.vpnhelper/ пропуская проверку подписи (из-за неисполняемого состояния файла) и затем устанавливает права 0500.
▪️После этого хелпер запускает /tmp/ipvanish_exploit.sh от имени root через GCDTask, а затем повторно выполняет его через OpenVPN hook --up.
▪️В качестве доказательства эксплуатации скрипт может создать файл /tmp/ipvanish_pwned_root.txt принадлежащий root.

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK