🎉 Результаты розыгрыша:

🏆 Победители:
1. . (@kkrya2019)
2. Дмитрий (@rifmipunchi)
3. я (@atamagai)

✔️Проверить результаты

Два победители уже подтвердили, что придут. От третьего ожидаю

Один битый пакет против 4G: разбор CVE-2023-37017
#telecom #4G #LTE #DOS

Open5GS — open-source реализация ядра мобильной сети, которую используют в лабораториях, private LTE/5G и исследовательских стендах. В LTE за подключение базовых станций к ядру отвечает компонент MME, а обмен между базовой станцией и MME идет по интерфейсу S1-MME и протоколу S1AP. Когда базовая станция поднимается, она отправляет S1SetupRequest: служебное сообщение, в котором сообщает ядру свои параметры.

В этом сообщении есть IE, то есть information element — отдельное поле протокола. Один из обязательных IE называется Global-ENB-ID: это идентификатор базовой станции. По стандарту 3GPP он должен присутствовать, но сетевой код не может считать стандарт гарантией безопасности. Любое входящее сообщение остается недоверенным вводом, особенно если оно приходит по сетевому протоколу от внешнего компонента.

На Habr разобрали CVE-2023-37017 в Open5GS: MME в версиях до 2.6.4 можно уронить одним S1SetupRequest, если убрать из пакета обязательный Global-ENB-ID. Код Open5GS полагался на наличие этого поля как на инвариант: после разбора списка IE он доходил до ogs_assert(Global_ENB_ID). Если поле отсутствует, переменная остается NULL, assertion завершает процесс open5gs-mmed.

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

По практическому риску не стоит преувеличивать: до S1-MME обычно нет прямого сетевого пути из интернета, а коммерческие ядра операторов проходят отдельное тестирование. Но для private LTE, лабораторных EPC/5GC, промышленных сетей и форков Open5GS такой класс багов прикладной: атакующему достаточно оказаться в позиции базовой станции или получить маршрут через скомпрометированную фемтосоту/IPsec-контур.

🔗Источник

🌚 @poxek | 🌚 @poxek_ai | 📲 MAX | 📺 YT | 📺 RT | 📺 VK

BYOVD против LSASS: почему старые драйверы обходят современные EDR
#EDR #bypass #AD

В статье показывается цепочка для Windows 11 25H2: загрузить подписанный, но уязвимый драйвер, через kernel read/write primitive снять PPL с LSASS, затем получить дамп не прямым чтением процесса, а через clone + MiniDump callback + XOR перед записью на диск. Автор утверждает, что тестировал это на обновленной системе с включенными стандартными защитами Windows, а выбранный PDFWKRNL.sys еще не ловился Microsoft Vulnerable Driver Blocklist.

♾️Механика♾️

Ключевой элемент - BYOVD: атакующий приносит легитимно подписанный драйвер с уязвимостью, который дает доступ к kernel memory. В статье выбран PDFWKRNL.sys; для него разбирается IOCTL 0x80002014, который приводит к memmove(dst, src, size) с параметрами из usermode-буфера. По разбору автора, драйвер не делает нормальную валидацию: нет ProbeForRead/ProbeForWrite, проверки canonical address и bounds check. Это превращает IOCTL в примитив чтения и записи kernel memory.

Дальше цепочка переходит к LSASS. Код проходит по списку процессов через EPROCESS, находит нужный PID и перезаписывает байт Protection. Для конкретного билда автор использует offsets вроде UniqueProcessId = 0x1D0, ActiveProcessLinks = 0x1D8, ImageFileName = 0x338, Protection = 0x5FA. После записи 0x00 PPL-барьер для LSASS снимается.

Вторая часть отвечает за дамп. Вместо прямого дампа lsass.exe используется NtCreateProcessEx: создается clone процесса, и уже он передается в MiniDumpWriteDump. Запись перехватывается callback-механизмом: IoWriteAllCallback складывает chunks в RAM-буфер, файловым handle выступает NUL, а перед записью на диск дамп XORится ключом 0x55. Так закрываются типовые точки детекта: прямой handle к LSASS, cleartext minidump на диске и сигнатуры вроде MDMP.

♾️Влияние♾️

Смысл техники не в одной уязвимости драйвера, а в зазоре между моделью доверия Windows к подписанным kernel drivers и скоростью обновления blocklist. Если конкретный vulnerable driver hash или версия еще не попали в блоклист, администраторская привилегия может стать kernel-level примитивом, а PPL перестает быть жесткой границей для защиты LSASS.

Для защитников это меняет фокус проверки. Нельзя смотреть только на факт включенного PPL или наличие EDR. Нужно отдельно контролировать загрузку драйверов, актуальность vulnerable driver blocklist, HVCI/Memory Integrity, WDAC-политики и события вокруг DeviceIoControl к нестандартным device objects. Шум возникает не обязательно там, где его ждут: дамп может появиться уже после RAM-перехвата и XOR-обфускации.

♾️Ограничения♾️

Источник не доказывает универсальный обход всех EDR. Это демонстрация лабораторной цепочки с конкретным драйвером, IOCTL, Windows build offsets и выбранной техникой дампа. Offsets завязаны на билд ядра, blocklist может обновиться, загрузка драйвера требует соответствующих прав, а поведение EDR зависит от продукта и политики. XOR 0x55 не является криптографической защитой; это простая сигнатурная маскировка.

♾️Как защищаться♾️

Минимальная защитная мера из статьи - WDAC deny policy для проблемного драйвера. Автор показывает подход через New-CIPolicyRule -Level FilePublisher -Fallback SignedVersion,Publisher,Hash -Deny, сборку .cip и обновление политики через CiTool.exe --update-policy.

Для рабочей среды это стоит превратить в процесс: инвентаризация загружаемых драйверов, контроль версий и publisher metadata, быстрый deny для BYOVD-кандидатов, проверка HVCI, тесты на загрузку известных LOLDrivers и мониторинг попыток открыть device interface вроде \\.\Global\PdFwKrnl.

Вывод: LSASS hardening нельзя считать завершенным, пока signed third-party drivers остаются неуправляемым исключением. PPL защищает процесс на уровне модели Windows, но уязвимый kernel driver переводит задачу в плоскость kernel memory write, где защитная граница уже зависит от driver control policy.

🌚 @poxek | 🌚 @poxek_ai | 📲 MAX | 📺 YT | 📺 RT | 📺 VK

RoguePlanet: новый публичный PoC для Windows Defender

MSNightmare (тот самый) выложил RoguePlanet — C++ PoC для локального повышения привилегий через race condition в Windows Defender. По README, автор проверял его на Windows 11 в обычном и Canary-каналах, а также на Windows 10 с июньскими патчами 2026 года. При успешном срабатывании PoC открывает shell от SYSTEM.

Технически цепочка ближе к abuse Defender remediation workflow, чем к обычному AV bypass. Код дергает MpClient.dll и Defender RPC-интерфейсы (MpScanStart, MpCleanStart), готовит файл wermgr.exe, монтирует ISO, использует reparse point/junction, oplock и наблюдение за изменениями директорий. В финале задействуется задача \Microsoft\Windows\Windows Error Reporting\QueueReporting, после чего процесс, уже запущенный как LocalSystem, открывает консоль в пользовательской сессии через named pipe.

Ограничения существенные. Автор прямо пишет, что exploit — hit or miss: на части машин получалась стабильность, на других — нет. Для Windows Server текущий PoC не работает, потому что стандартный пользователь не может смонтировать ISO; утверждение о применимости к Server пока остается заявлением автора, а не готовой эксплуатацией из репо.

Для blue team это сигнал смотреть не только на факт запуска бинаря, но и на цепочку вокруг Defender remediation: обращения к MpClient.dll, подозрительные wermgr.exe в %TEMP%, ISO без буквы диска, junction/reparse point операции, oplock-паттерны и ручной запуск WER-задач. Пока нет официального advisory/CVE в самом репозитории и вряд ли появится из-за войны MSNightmare и Microsoft.

🔗Источник: MSNightmare/RoguePlanet

🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

zeroxjf — небольшой, но плотный блог про iOS security research: ядро, SEP, IOKit, jailbreak/tweak-инфраструктуру и практическую реверс-инженерию

Главная страница работает как индекс работ: рядом лежат PoC для Apple kernel/SEP багов, заметки по Cyanide и практический разбор Metal в vphone. Материалы полезны тем, кто хочет смотреть не только на итоговый CVE, а на конкретный путь ресерча, race window, panic signature, ограничения окружения и минимальный код для воспроизведения.

Топ-5 материалов:

1. CVE-2026-20637: AppleSEPKeyStore Use-After-Free — UAF в AppleKeyStore/AppleSEPKeyStore через гонку между IOConnectCallMethod и IOServiceClose; протестировано на iOS/macOS 26.1-26.2, патч заявлен в iOS/iPadOS 26.3.
2. SEP Exhaustion Kernel Panic — детерминированный SEP firmware panic через AppleKeyStore selector 2 и open type 0x2022; около 41 вызова приводят к стабильной crash signature в SKS.
3. CVE-2026-20687: AppleJPEGDriver startDecoder Timeout UAF — deferred kernel panic в AppleJPEGDriver: async decode оставляет stale queue node, а последующий sync decode через Camera добивает UAF на обходе очереди.
4. Cyanide: Writing Tweaks — developer reference по Cyanide tweaks: RemoteCall-сессии, remote_objc API, минимальный tweak, Settings-интеграция и портирование с Theos/Substrate без SpringBoard dylib-хуков.
5. Patching Metal Graphics into vphone — clean-room shim для Metal compiler plugin в vphone: проблема в PCC dyld shared cache и сломанных relocations, решение — ~230 строк C++ с runtime symbol resolution.

Если вы занимаетесь сесурити ресерчем ядра iOS или хотите понять, как выглядят воспроизводимые баги вокруг IOKit/SEP, zeroxjf стоит добавить в закладки: тут ценность что всё нужное в одном месте и сразу.

🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

❕❗️❕Задали вопрос в формате:

я разработчик фул стак, работаю в компании и ещё какие-то свои проектики пробую запускать. На работе пихают AI, в проекты тоже вроде надо внедрить. Но вот читаю тебя и не понимаю как обезопасить свою работу и свои пет проектики. Чё посоветуешь?

Для базово входа со стороны разраба советы будут такие:

1. Начни с OWASP Top 10 for LLM Applications и OWASP Top 10 for Agentic Applications и OWASP Large Language Model Security Verification Standard (LLMSVS)
2. Опиши модель угроз: что чат-бот или LLM агент умеет, какие данные видит, какие действия или тулы (tools) может вызвать.
3. В промпте жестко раздели системные инструкции и не доверенный контент: user messages, RAG docs, web pages, tool outputs.
4. На серверной стороне создай белый список для тулов/действий чатбота. Модель не должна сама решать, что ей “можно”. Это не панацея, но самая дешёвая и простая митигация.
5. Логируй ВСЁ. Промпт свой и пользователя, ответы, tool calls, ивенты блокировки, сработки гардрейла.
6. Подготовь данные для регрессионных тестов. Это может быть набор из 20-50 атак: prompt override, system prompt leak, encoded input, multilingual attack, RAG injection, tool misuse.
7. Прогоняй его через свою реальную сетевую инфру, не напрямую в Openrouter/Другой API провайдер.
8. После каждого изменения промпта/модели/тула запускай эти тесты снова.
9. Пробуйте сами похекать своего агента/чатбота.
- Promptfoo
- HiveTrace Red
- PyRIT
- Garak
- OpenAI
10. Нашёл обход? Возвращайся к пункту 5 и усиливай тесты.

Будет ли это достаточно? Нет. (не)Безопасность никогда не останавливается, поэтому каждый час будут новые способы обхода X защиты и на следующий день будет появляться защита от этого

HallWatch: usermode-ловушка для indirect syscalls
#windows #blue_team

HallWatch — PoC usermode-детектора indirect syscalls для Windows. Вместо классического хука в начале Nt*-стаба он патчит первый байт инструкции syscall: пара 0F 05 превращается в CC 05, и любой путь, который реально доходит до этого адреса, получает EXCEPTION_BREAKPOINT.

Дальше VEH ловит брейкпоинт, по заранее собранной карте экспортов ntdll понимает, какому стабу принадлежит адрес, делает проверки и переводит Context->Rip на приватный trampoline. Trampoline уже выполняет настоящий syscall и возвращает управление. За счет этого ловятся сценарии, где код не вызывает экспорт напрямую, а прыгает сразу на 0F 05: Hell's Hall, Tartarus' Gate, RecycledGate и VEH syscall.

Проверки у автора практичные: return address должен вести в доверенный модуль, SSN в eax должен совпадать с SSN этого стаба, а короткий stack walk через RtlVirtualUnwind должен выглядеть как нормальный модульный стек, а не shellcode/ROP.

Hell's Gate хуже ложится на INT3-подход, потому что syscall может жить в чужой RWX-странице. Для этого HallWatch отдельным worker'ом обходит executable memory через VirtualQuery, сканирует до 64 KB региона на пары 0F 05, дедуплицирует адреса и логирует уникальные находки. Автор прямо признает, что это дорогой и грубый PoC-сканер, но он покрывает свежий RWX syscall stub и shadow ntdll. Есть и второй сканер по .text модулей: он ищет 0F 05 рядом с C3, пропуская системные модули, где такие инструкции легитимны.

Ограничения: usermode не решает kernel-level противника, allowlist покрывает не все Nt*-стабы, возможны integrity checks со стороны sample, а периодический scanner тратит CPU. Из мелких инженерных деталей стоит отметить ABI-ловушку: после INT3 в VEH Context->Rip указывает на следующий байт, поэтому обработчик должен опираться на ExceptionAddress, иначе trampoline стартует со смещением.

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

🔗Источник: Zypherion-Technologies/HallWatch

p.s. посты выходят не часто, т.к. я в запаре. Постараюсь восстановить плотной поток постов в июле

🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

MeshCentral: от XSS в агенте до RCE через админскую сессию
#web #RCE

Kev Breen разобрал MeshCentral как цель для агентного security research: поднял тестовый стенд, подключил Windows-хост, дал Claude Code проверить server-side и UI, а затем отдельно попросил проверить гипотезу про поля, которые отправляет MeshAgent и которые потом рендерятся в консоли.

Цепочка оказалась рабочей: скомпрометированный или rogue MeshAgent мог передать HTML/JavaScript в osdesc. Сервер сохранял значение без HTML-sanitization, а UI показывал его через innerHTML. Когда админ открывал детали устройства, payload выполнялся в его браузере. Дальше XSS использовал админскую сессию: открывал control.ashx WebSocket, перечислял nodes и отправлял runcommands на управляемые хосты. Для RMM это сразу меняет impact: выполнение команд идет через легитимную управляющую плоскость MeshCentral, вплоть до SYSTEM/root на агентах.

Полезен сам процесс: Claude подсветил поток agent -> DB -> UI, сгенерировал Ansible playbook для стенда, PoC-клиент, скрипт извлечения identity из MeshAgent.msh/MeshAgent.db, а затем через review-findings и report-writer помог собрать отчет для мейнтейнеров. По данным автора, вся сессия заняла 1 час 11 минут, 96 tool calls, 10 subagents и около $20.34.

Фикс тоже прошел через developer workflow: PR обернул оставшиеся unsafe render sites в EscapeHtml(...), был смержен 22 мая 2026, advisory вышел 11 июня 2026. Затронуты версии meshcentral <1.1.60, патч 1.1.60, CVSS 8.3, CVE на момент advisory нет.

Для тех кто пользуется этим ПО: обновить MeshCentral до 1.1.60+ и смотреть журналы MeshCentral — они хранят историю команд, выполненных на хостах.

🔗Источники:
TechAnarchy write-up
GitHub PR #7823
GitHub Advisory GHSA-c7hr-448w-65px

🌚 @poxek | 🌚 @poxek_ai | 📲 MAX