Похек

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

Вирус-шпион в письме от «партнера» — и все, компании нет. Звучит дико, но это реальность современных кибератак. Ребята из Positive Technologies сняли об этом короткий фильм. За 15 минут они показали, как один неосторожный клик сотрудника запускает катастрофу и как MaxPatrol Endpoint Security ломает этот сценарий, останавливая угрозу на подлете. Смотрите сами → А 17 июня в 11:30 на Product Backstage они выкатывают новую версию продукта. Приходите на лонч, чтобы первыми узнать, как защитить свой бизнес от самых изощренных атак и спать спокойно. Зарегистрироваться

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.

Один битый пакет против 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

Третий победитель не ответил, так что билет уходит @tembitt

🎉 Результаты розыгрыша: 🏆 Победители: 1. . (@kkrya2019) 2. Дмитрий (@rifmipunchi) 3. я (@atamagai) ✔️Проверить результаты

Кажется, нейрослоп добрался до багбаунти... Видим, как отчеты, написанные ИИ, становятся все длиннее, а пользы в них все меньше. Поэтому нужен коллективный разум. Задача простая: придумайте, как Standoff Bug Bounty может защищаться от нейрослопа. Что угодно: ▪️новые механики платформы; ▪️ачивки и антиачивки; ▪️ограничения и штрафы; ▪️способы оценки качества отчётов; ▪️мемные идеи, которые почему-то могут сработать. ▪️платить за сдачу отчёта За самые интересные предложения подарим лимитированный мерч Poxek × Standoff Bug Bounty Лут можно забрать: 🎁 на Standoff Talks лично 📦 или отправим почтой 🕰 А ещё 18 июня на Standoff Talks проведу открытую Q&A-сессию про AI в пентесте. Приходите холиварить, задавать неудобные вопросы и вместе думать, как жить в мире, где уязвимости ищут нейронки, а мы ищем уязвимости в ИИ) Свои идеи оставляйте в комментариях 👇

Awesome Embedded Systems Vulnerability Research: карта входа в реверс и поиск уязвимостей embedded устройствах Нашел для вас компактный список ресурсов для vulnerability research по IoT/embedded-устройствам: Awesome-Embedded-Systems-Vulnerability-Research. В README собраны книги, YouTube-каналы, блоги, Pwn2Own райтапы, доклады, лабы и инструменты. Исследования в области встраиваемых устройств быстро разбиваются на отдельные дисциплины: извлечение прошивки, UART/JTAG, загрузчики, ARM/MIPS, эмуляция, фаззинг, декомпиляция, serial консоли, а также тематические исследования, посвящённые автомобильным зарядным устройствам и зарядным устройствам для электромобилей электричек)) Все в одном месте: "Practical IoT Hacking", "Hardware Hacking Handbook", аналитические материалы от ZDI, NCC Group, Quarkslab и Synacktiv, лаборатории, такие как DVRF и OWASP IoTGoat, а также инструменты, включая binwalk, unblob, Ghidra, IDA, QEMU, Qiling, Unicorn, AFL++ и gdb-multiarch. Я бы использовал список не как линейный курс, а как маршрутную карту: выбрать конкретный класс устройства, поднять уязвимоую лабу, пройти extraction -> static RE -> emulation/debug -> fuzz/PoC, затем читать райтапы по похожей архитектуре. Иначе легко утонуть в ссылках без практики. Важно: этот awesome-list не методология и не очень-то структурированы, но для всего и разом сойдет. Для старта в поиске уязвимостей в эмбедед устойствах он закрывает больную часть: быстро найти источники, где показаны и софтверная сторона анализа прошивок, и аппаратный доступ через serial/debug интерфейсы.

1-click угон GitHub-токенов через github.dev и баг VS Code Webview 😮 В browser-версии VS Code (github.dev) обнаружена цепочка, позволяющая украсть GitHub OAuth-токен одним переходом по ссылке на специально подготовленный репозиторий. Техника угона строится на комбинации из широких OAuth-прав токена, который GitHub выдает github.dev, бага/особенности VS Code Webview и возможности установки расширения через синтетические keyboard events. Суть бага 🔽 При открытии github.dev GitHub автоматически прокидывает в web-IDE OAuth-токен, чтобы редактор мог работать с GitHub API от имени пользователя. Этот токен не ограничен текущим репозиторием и дает доступ ко всем репозиториям, к которым у пользователя уже есть доступ, включая приватные и organization-репозитории. Webview внутри VS Code умеют пересылать keyboard events в основное окно редактора через message passing, чтобы горячие клавиши работали даже внутри iframe/webview. Эти события можно синтетически подделывать из JavaScript внутри webview. В PoC использовался Jupyter notebook (.ipynb) внутри github.dev. Атака выглядит так 🔽 ▶️ пользователь открывает ссылку вида https://github.dev/... ▶️ вредоносный notebook/webview запускает JavaScript ▶️ JS генерирует цепочку synthetic keyboard events ▶️ через них инициируется установка malicious VS Code extension ▶️ расширение получает доступ к GitHub auth/session context внутри github.dev ▶️ дальше атакующий может читать приватные репозитории, вытаскивать код и пушить изменения от имени жертвы. Если пользователь уже ранее логинился в github.dev и browser storage не очищен, атака укладывается в один клик. ➡️ Подробности и PoC #red_team

Minecraft Bedrock: 4 байта до RCE #RCE #overflow #memory #minecraft Сервер может навязать обязательный resource pack, а значит — заставить клиент скачать и распарсить изображения, звуки и анимации. Исследователи быстро вышли на stb_image.h: Minecraft Bedrock для Windows использовал старую ревизию библиотеки, а фаззинг GIF-парсера дал heap-buffer-overflow. Сам баг выглядел скромно: одна OOB-запись байта 0x01 и отдельная 4-байтовая запись сразу за выделенным буфером. Из этих 4 байт контролируются первые три, последний фиксирован как 0xff. Обычно такую находку трудно довести до удаленного выполнения кода, тем более без утечки адресов, с ASLR и Control Flow Guard. Авторы же использовали особенности Windows Segment Heap и нашли удобный heap spray через игровые таблички: сервер управляет размером, содержимым, временем жизни и количеством строковых буферов на клиенте. Затем они перешли к Molang — языку скриптов анимаций в Minecraft. Через повреждение структур Molang удалось получить произвольное чтение и запись внутри процесса, обойти ASLR уже на стороне клиента и подготовить ROP-цепочку. CFG обошли не универсальным трюком, а через специфичную только Майна поверхность: статически слинкованный OpenSSL-код без CFG-диспетча. В демо цепочка в итоге резолвит system из ucrtbase.dll и запускает cmd.exe. Вывод: не играйте в Майнкрафт игры тоже под прицелом хакеров, а обычной игрок - изи лут. А заранее понять контролирует сервер злоумышленник или нет невозможно. Старые embedded-библиотеки, resource packs, скрипты анимаций и аллокаторные детали здесь складываются в реальную RCE, а не просто в краш клиента майнкрафта. 🔗 Источник 🌚 @poxek | 🌚 @poxek_ai | 📲 MAX | 📺 YT | 📺 RT | 📺 VK

Codex нашёл HTTP/2 Bomb: старые баги сложились в новый DoS #llm #ai #http2 #DoS Calif опубликовали разбор HTTP/2 Bomb — удалённого DoS против дефолтных HTTP/2-конфигураций nginx, Apache httpd, Microsoft IIS, Envoy и Cloudflare Pingora. Суть атаки не в неизвестной особенности протокола. Codex скомбинировал два давно известных приёма: HPACK compression bomb и Slowloris-подобное удержание соединения. Через HPACK клиент один раз кладёт заголовок в динамическую таблицу, а дальше много раз ссылается на него почти бесплатными индексами. На проводе это байты, на сервере — реальные аллокации под заголовки. Вторая половина цепочки — HTTP/2 flow control. Клиент выставляет нулевое окно для ответа и не даёт серверу нормально завершить поток. В итоге память, выделенная под обработку запроса, не освобождается. По данным Calif, на Apache httpd и Envoy один клиент способен удержать десятки гигабайт памяти за секунды; в их демо Envoy 1.37.2 дошёл до ~32 ГБ примерно за 10 секунд, Apache httpd 2.4.67 — примерно за 18 секунд. Интересная часть — роль Codex. Модель не изобрела новый класс уязвимости, а прочитала код и патчи, увидела, что две известные техники хорошо сцепляются и собрала рабочую цепочку. Это хороший пример того, где AI-агенты уже полезны в исследованиях безопасности: не как что-то сделал и вот атака, а как ускоритель поиска комплексных багов в больших кодовых базах. Что делать операторам: обновить nginx до 1.29.8+, для Apache смотреть mod_http2 v2.0.41, а там, где патча нет, временно отключать HTTP/2 или ставить строгий лимит на число header fields, включая Cookie crumbs. Одного лимита на суммарный размер декодированных заголовков здесь недостаточно. 🔗 Источники: Calif writeup RFC 7541 HPACK / RFC 9113 HTTP/2 🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Ахой, комрады! Этот канал непотопляемый даже не смотря на мое отсутствие тут некоторое время. Оправдываться не буду, мой косяк, постараюсь вернуть стабильность. 🌚 Как АС Genshin Impact помог раскатать шифровальщик Кейс довольно старенький с середины 2022. У жертвы корректно настроенная эндпойнт защита. Причина: атакующий принёс с собой подписанный драйвер античита Genshin Impact - `mhyprot2.sys`. Сама игра на тачках не была установлена, она и не нужна. Драйвер из ring-0 убивает защиту по IOCTL-команде, после чего шифровальщик запускается беспрепятственно. Кстати, PoC включая read/write был известен еще с 2020 года, по понятным причинам он не был принят как уязвимость. Самое интересное здесь - не сам факт BYOVD, а цепочка. Разбираем по шагам. 1. Разведка С неустановленного хоста - secretsdump (Impacket) к контроллеру домена. Затем wmiexec для удалённого выполнения команд через WMI. Всё в контексте встроенного доменного админа. 2. Закрепление на DC Заход на контроллер домена по RDP под другой скомпрометированной админской учёткой. Артефакт: процесс rdpclip.exe (общий буфер обмена RDP). 3. Доставка инструментов На рабочий стол админа падают: - kill_svc.exe ставит службу драйвера и убивает AV; - mhyprot2.sys сам подписанный драйвер. 4. Подготовка масс-деплоя через GPO На шару NETLOGON положен avg.msi, замаскированный под AVG. Внутри: - logon.bat оркестратор; - HelpPane.exe маскировка под Microsoft Help, ставит драйвер и убивает службы AV; - mhyprot2.sys драйвер; - svchost.exe ransomware. 5. Первые попытки не сработали GPO-развёртывание упало. Ручная установка avg.msi (3 раза) и запуск avg.exe (3 раза) - тоже. Но антивирус был убит во всех попытках. Защита уже отключена. 6. Что сработало Атакующий бросил logon.bat на рабочий стол и запустил руками. Скрипт: 1. Запустил HelpPane.exe → драйвер в ядре, службы AV убиты. 2. Завершил процессы защиты. 3. Через bcdedit отключил Windows Recovery. 4. Очистил журналы Windows. 5. Остановил и удалил службу mhyprot2. 6. Запустил svchost.exe - шифрование пошло. 7. Массовое развёртывание Файлы mhyprot2.sys, kill_svc.exe, svchost.exe положены в шару с показательным именем «lol». Через PsExec под доменным админом по списку из ip.txt разлетелся b.bat, который копировал и запускал компоненты на каждой машине. Что внутри драйвера

NtOpenFile         → загрузка mhyprot2.sys
DeviceIoControl    → IOCTL 0x81034000 + список PID
ZwTerminateProcess → убийство процесса из ring-0

📌 Где это ловить - Запуск Impacket-тулзов (secretsdump, wmiexec) - RDP на DC под админом + rdpclip.exe - Новые файлы в NETLOGON - Event ID 7045 установка службы mhyprot2 - Sysmon Event ID 6 загрузка драйвера из user-пути - bcdedit с отключением recovery - Массовая очистка журналов Windows - PsExec под доменным админом по списку хостов

Как Minecraft-мод Meowcraft оказался дроппером для стилера Eric Parker разобрал модпак Meowcraft: к нему пришли через взломанный аккаунт знакомого, без грубой "срочности" и типичных красных флагов. После запуска у жертвы вылетела сессия Minecraft, а игра начала вести себя странно. По разбору в видео, модпак для Fabric 1.21 выглядел подозрительно бедно: один маленький мод, пачка конфигов под отсутствующие моды, без ресурсов и шейдеров. При запуске мод поднимал Minecraft как ширму: создавал в %TEMP% файл, замаскированный под javaw.exe, запрашивал права администратора и уже после этого давал игре открыться. Удобный трюк на отвлечение: пользователь видит Minecraft и думает, что всё нормально. Дальше хуже. Процесс порождал cmd, прогонял антианализ и запускал большой PowerShell-скрипт, закодированный в base64. Статический разбор свел схему к простому дропперу: мод скачивает и исполняет внешний файл. В Any.Run Parker увидел поведение стилера: проверка пользователя и IP, скрытый перезапуск, завершение браузеров, попытки украсть браузерные данные, Minecraft-сессию и Discord. Discord тут не просто лут, а через захваченные аккаунты помогают рассылать мод дальше от имени живых людей. По внешнему контексту кейс не выглядит единичным: Kaspersky уже описывал кампании, где Minecraft-тематика, моды и особенно читы использовались как приманка для загрузчиков и стилеров. Поэтому практический вывод скучный: Java-мод в Minecraft — это обычный код с правами процесса игры, а не просто набор шейдейров итекстур. Если мод пришел в личку, даже от знакомого, и просит запуск или админку, относиться к нему надо как к исполняемому файлу из мутного архива. Проверять стоит не описание, а происхождение, содержимое JAR, сетевые вызовы и поведение в песочнице. 🔗 Источник: оригинальное видео 🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

сейчас бот точно ожил, можете тыкать у кого днём не работал мини-апп

💉 ASSUME BIRCH MEETUP #6 💉 #митап 📆Когда: 18.06.2026 🕰Начало: 18:30 📍Локация: Москва. Точная локация будет указана в приглашении. ❓Какие будут доклады? В этот раз программа плотная: Secure Boot и проверка загрузчиков умных устройств, реагирование на реальные атаки, уязвимости шеринговых зарядных станций, пивотинг через веб-серверы, LDAP-мониторинг. Из фаст-трека: туннель через веб-звонок, побег из PAM с найденным 0day, путь до админа домена через патч известной утилиты, Mythic Bind TCP Agent, восстановление доступа к планшету и RCE в IoT-коробке без превращения её в кирпич. ⚡️Как получить проходку? Следить за новостями в канале Assume Birch. Спросить у друга, а может у него +1. У меня его забрали аж за неделю до самого анонса ивента)) Розыгрыш: 3 проходки у меня. Просьба тыкать только тех, кто реально придёт. Если вы не ответите в течение 24 часов как я вам напишу в ЛС, то проходка будет передана другому человеку. Жду тебя на встрече 18 июня!

CIFSwitch: Linux LPE через подмену cifs.spnego ключей и namespace confusion #Linux #LPE #CIFS Это не универсальная, но весьма эффективная техника локальной эскалации привилегий в Linux, возникающая на стыке ядра CIFS, keyring subsystem и userspace-хелпера cifs.upcall. ♾️Технические особенности♾️ Уязвимость затрагивает механизм обработки SPNEGO/Kerberos-аутентификации для CIFS/SMB-монтирований. ▪️Ядро использует request_key() для получения ключа cifs.spnego при необходимости Kerberos-аутентификации. Описание ключа (key description) формируется CIFS-кодом ядра и содержит чувствительные поля: pid, uid, creduid, upcall_target, информацию о namespace и другие параметры. ▪️Userspace-хелпер /usr/sbin/cifs.upcall, запускаемый от root через request-key, до исправления доверял содержимому description. ▪️ Ядро до фикса не проверяло происхождение description для ключей типа cifs.spnego. Из-за этого непривилегированный пользователь мог самостоятельно вызвать request_key("cifs.spnego", fake_description, ...) и передать поддельное описание, имитирующее внутренний CIFS-запрос. ♾️Пайплайн атаки♾️ ▪️Непривилегированный атакующий формирует поддельное описание cifs.spnego, содержащее целевой pid и upcall_target=app. ▪️Вызывается request_key() с фейковым description, что приводит к запуску root-хелпера cifs.upcall в namespace-контексте атакующего процесса. ▪️До окончательного сброса привилегий cifs.upcall обращается к NSS/glibc-функциям, что позволяет через подмену nsswitch.conf и собственный libnss_*.so.2 внутри mount namespace добиться загрузки нужной библиотеки. ▪️В результате атакующий получает выполнение произвольного кода и полноценный root shell. ♾️Затронутые системы♾️ Под угрозой находятся Linux-системы с установленным cifs-utils, доступным модулем CIFS и включенными user namespaces. Практическая эксплуатация также зависит от конфигурации LSM, доступности unprivileged user namespaces и особенностей hardening в дистрибутиве. Но в первую очередь затронуты системы с cifs-utils 6.14+ или более старыми сборками с бэкпортом поддержки upcall_target. 🔗Источник 🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

С первым днём лета!!!

ThinkPad firmware reverse engineering Вышел длинный writeup о тулчейне для анализа прошивок ThinkPad: он берет публичные BIOS-пакеты Lenovo, извлекает ACPI/UEFI/EC-части и превращает их в структурированные данные для портов coreboot, OpenCore, GPIO-аудита и диффов исправлений безопасности. Ценность тут в структуриванности исследования. У Lenovo BIOS обычно лежит как Windows .exe с WinFlash, .fl1/.fl2/.cap, readme и microcode .PAT. Если сначала отфильтровать настоящие BIOS-пакеты, потом прогнать их через innoextract/7z/binwalk, uefiextract и iasl, на выходе появляется повторяемый корпус: DSDT/SSDT, список UEFI-модулей, changelog с CVE/LEN advisory и данные для дальнейшего разбора. Самый интересный слой — GPIO. На AMD/Qualcomm ThinkPad пин часто лежит прямо в DSDT. На Intel DSDT может дать только GNUM(GFPI), а реальное значение во время загрузки кладет AcpiPlatform в GNVS. Тулчейн склеивает DSDT, записи AcpiPlatform и таблицы PlatformInit PADCFG, чтобы превратить «прерывание fingerprint reader» в именованный SoC pad вроде GPP_A22 и проверить mode/direction/lock. Отсюда уже растут статические вопросы безопасности: линии камеры, микрофона, fingerprint, SMI-routable inputs и GPIO приватности, которые может подделать привилегированный софт. Для CVE-части readme-майнер собирает CVE/LEN ID и подсистемы, module diff хеширует UEFI files между версиями, а fw_secdiff.py предлагает, где именно мог лечь фикс. В примере r0buj24ww → r0buj26ww изменились 66 из 546 модулей, включая SMM/TPM-связанные. Границы тоже названы честно: firmware-only путь не знает runtime-вариант платы, SPD/FSP могут отсутствовать, а для точности всё равно нужен live capture. Но как стартовая точка для реверса, coreboot/OpenCore-портов и аудита прошивок это сильная вещь: дешёвый воспроизводимый first pass до ручного копания в конкретном ThinkPad. p.s. вообще я читал про синкпады, т.к. думаю какой купить. А потом натнулся на это золотце)) 🔗Источник 🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

Картирование ботнет-операций через бэкенд-инфраструктуру и сетевые fingerprints #botnet #apache #CVE #TI #honeypots Нашел гайд по анализу ботнет-операций, использующих старый Apache-эксплойт. Автор показывает, как по переиспользуемой бэкенд-инфраструктуре и устойчивым TLS/HTTP/SSH-отпечаткам можно собрать из разрозненных событий цельную картину кампаний. Главная мысль — для корректной атрибуции ботнетов важно уходить от IP-адресов к менее изменчивым маркерам. ♾️Технические особенности♾️ Ключевой объект анализа — серверы, с которых дропперы загружают следующий этап, и устойчивые сетевые отпечатки клиентов (JA4, JA4H, HASSH). Сенсоры фиксируют факт подключения, HTTP-запросы и параметры TLS-рукопожатия, что позволяет восстанавливать staging-URL и цепочки загрузки пейлоадов даже при обфускации через base64 и shell_exec в PHP-скриптах. На основе этих данных формируется граф: ▪️узлы — атакующие IP и staging-хосты, ▪️ребра — факты доставки пейлоадов; ▪️связи между серверами строятся по общим delivering-IP, что позволяет выделять устойчивые кластеры операций. ♾️Результаты эксперимента♾️ ▪️Автор выделяет кластер из 1 001 IP в сотнях сетей и десятках стран, связанных с восемью staging-серверами и входящих в одну операционную экосистему. ▪️Эксплуатация строится на CVE-2021-41773 и обфускации через %%32%65, нацеленной на /cgi-bin/.../bin/sh по 80/443. ▪️Самораспространяющийся шелл apache.selfrep превращает скомпрометированные хосты в новые scanning- и delivery-узлы. ▪️Дополнительный анализ JA4/JA4H показывает совпадающие редкие сетевые отпечатки у сотен IP, что указывает на общий инструментарий или схожую реализацию сканера. 🔗Источник и подробности 🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK

ClickOnce Hijacking: скрытое выполнение shellcode через подмену неподписанных DLL и Thread Hijacking #ClickOnce #RedTeam #ThreadHijacking #InitialAccess Метод позволяет создать простой загрузчик shellcode, эксплуатируя доверенные ClickOnce-приложения и отсутствие подписи у отдельных сборок (DLL Hijacking + Manifest Manipulation + Thread Hijacking). ♾️Суть техники♾️ ClickOnce проверяет криптографическую подпись манифестов, при этом не верифицирует сборки на этапе загрузки, если разработчик изначально их не подписал. Атакующий берет легитимное подписанное ClickOnce-приложение (например, ReaderConfiguration.exe от MagTeK), через декомпилятор (тот же dnSpy) находит вызов функции из неподписанной DLL и заменяет эту DLL на свою версию с внедренным вредоносным C# кодом. Чтобы ClickOnce успешно загрузил модифицированный пакет, необходимо обновить хэши и манифесты. ▪️После замены DLL пересчитываются SHA-256 хэши измененных файлов, обновляются соответствующие элементы dsig:DigestValue и атрибуты size в манифесте исполняемого файла (.exe.manifest). ▪️Подпись полностью вычищается из обоих манифестов (.exe.manifest и .application): удаляются элементы publisherIdentity и Signature, а значение publicKeyToken обнуляется до 0000000000000000. Это сообщает механизму ClickOnce, что проверять подпись больше не нужно. В самой подмененной DLL shellcode хранится как Embedded Resource и зашифрован простым 3-байтовым XOR-ключом (для обхода EDR-движков, которые брутфорсят 1-байтовые ключи). ▪️В рантайме происходит расшифровка пейлоада и скрытое разрешение Windows API через кастомный класс (API Hashing) путем парсинга PEB без использования стандартных P/Invoke. ▪️Запускается легитимный процесс wmiprvse.exe в состоянии CREATE_SUSPENDED. ▪️Выделяется память (VirtualAllocEx с правами RWX), shellcode записывается в память (WriteProcessMemory), выполняется hijacking главного потока (GetThreadContext → перезапись регистра RIP для x64 или EIP для x86 → SetThreadContext), и поток возобновляется вызовом ResumeThread. ♾️Пайплайн атаки♾️ ▪️Сборка вредоносного ClickOnce-пакета (подмена DLL, пересчет хэшей, зачистка элементов подписи в манифестах) ▪️Доставка пакета и его установка в пользовательскую директорию (AppData) ▪️Загрузка модифицированной DLL легитимным приложением, расшифровка shellcode из ресурсов ▪️Инъекция и выполнение shellcode через Thread Hijacking в созданный suspended-процесс wmiprvse.exe ♾️Импакт и обнаружение♾️ Техника позволяет обойти SmartScreen и AppLocker, так как изначальный запуск производится в контексте легитимного приложения. В ходе тестов она также хорошо себя показала против Cortex и SentinelOne, CrowdStrike был обойден после искусственного увеличения размера файла загрузчика. Bitdefender и Microsoft Defender for Endpoint обнаружили активность, преимущественно на этапе сканирования памяти процесса или при создании жертвенного процесса wmiprvse.exe. 🔗Источник 🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK