Похек

🎉 Результаты розыгрыша: 🏆 Победители: 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

❗️GitLab вслед за GitHub забанил исследователя Nightmare-Eclipse. Ресёрчера ждут крупные 👮неприятности. Конец мая 2026 года запомнится индустрии кибербезопасности как время открытого противостояния одиночки и огромной корпорации. Как уже говорилось ранее, в центре пристального внимания ИБ-блогов и СМИ оказался исследователь под псевдонимом Nightmare-Eclipse. Он начал публично выкладывать в сеть рабочие эксплойты нулевого дня для операционных систем Windows. Сначала платформа GitHub забанила исследователя, а затем к бану присоединился GitLab. International Cyber Digest решили попробовать в 👀 OSINT, дабы раскрыть личность возмутителя спокойствия Microsoft. Утверждается, что под маской Nightmare-Eclipse скрывается известный ИБ-исследователь Windows Абдельхамид Насери* из 🇩🇪Германии. В прошлом он использовал никнеймы KLINIX5, halov и halove23. Сообщество хорошо знает его по событиям 2021 года. Тогда он обнаружил элегантный способ обхода официального патча Microsoft для уязвимости повышения привилегий установщика Windows. Насери имеет огромный опыт работы с платформами HackerOne и Zero Day Initiative. Судя по его профилю в профессиональной сети, он даже числился исследователем Microsoft до июля 2025 года. Связь между старыми и новыми аккаунтами подтвердилась множеством цифровых следов. Анализ видеороликов с демонстрацией уязвимостей выявил совпадения, включая идентичное стандартное имя пользователя ОС на записях. Также на рабочем столе был замечен специфический каталог zdi, указывающий на многолетнее сотрудничество исследователя с Zero Day Initiative. Мотивы хакера оказались весьма прозрачными и вытекают из долгого конфликта с корпорацией. Насери годами критиковал качество выпускаемых обновлений безопасности. В какой-то момент, по его утверждениям, Microsoft без объяснения причин удалила его аккаунт на портале MSRC для отправки отчетов об ошибках. Затем компания публично заявила о нарушении им правил скоординированного раскрытия информации при публикации уязвимости YellowKey. Cобытие стало точкой невозврата. Исследователь несколько раз менял никнеймы в социальной сети X: с Abdelhamid Naceri на Eiriel, затем превратился в Nightmare-Eclipse. После банов аккаунтов на GitHub (23 мая) и GitLab (26 мая) Nightmare-Eclipse решил нанести максимальный репутационный ущерб Microsoft. Исследователь продолжил публикацию материалов через собственный блог DEADECLIPSE//_BINARIES и резервные зеркала. Автор сопроводил файлы комментариями о попытках цензуры со стороны Microsoft. Исследователь мог бы легко продать эти уязвимости на сером или чёрном рынке за огромные деньги, но вместо этого он выбрал путь публичного раскрытия. В обсуждениях энтузиасты открыто насмехаются над попытками корпораций удалить эти файлы из сети и делятся адресами резервных блогов. Сегодня сообщество разделилось на два лагеря. Одни считают Абдельхамида Насери героем и бескомпромиссным борцом за безопасность. Другие называют его злодеем из-за публикации готового цифрового оружия. Однако нельзя отрицать очевидный факт: талантливый исследователь с многолетним опытом устал от кулуарных споров и перевел свою войну в публичную плоскость. 👆🤔 Примечательно, что вчера Microsoft Security Response Center опубликовал развернутое заявление, где корпорация категорически осудила публикацию PoC в открытом доступе. Корпорация не намерена ограничиваться исключительно техническими мерами защиты. Сотрудники отдела по борьбе с цифровыми преступлениями Digital Crimes Unit уже готовят судебные иски. Процессуальные действия будут направлены как против ресёрчеров подобных утечек, так и против пособников. Для привлечения виновных к ответственности Microsoft планирует координировать усилия с 👮правоохранительными органами по всему миру. * Выводы об идентификации исследователя Nightmare-Eclipse под именем Абдельхамид Насери основаны исключительно на результатах OSINT-расследования. Пока это только гипотеза, а не подтверждённый факт. ⚠️Результаты расследования IntCyberDigest решили удалить по неизвестной причине. ✋ @Russian_OSINT

ёPRSTCON всё еще продолжается

Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️   Уже 4 июня, ровно в 14:00, мы прольем свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел». В этот день вы сможете вместе с нами:   🚩раскрыть все аномалии в сети; 🌥увидеть, как детектирование переходит на заоблачный уровень; 🦾запечатлеть, как «расстановку сил» меняет автоматизированное реагирование.   Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:   1) Отменить все свои планы на 4 июня в 14:00 2) Зарегистрироваться на онлайн-запуск по ссылке 3) С нетерпением ждать встречи вместе с нами   Увидимся уже скоро! Такие дела.

Щелчок и я уже на ёPRTCON

GhostTree: как NTFS junction мешает EDR-сканированию Varonis Threat Labs описали приём GhostTree: злоупотребление NTFS junction points, которые в Windows создаются через mklink /J <link> <target>. По документации Microsoft, ключ /J создаёт directory junction, а junction в NTFS реализованы через reparse points. Идея простая: пользователь с правом записи создаёт junction из дочерней папки обратно в родительскую. Для ОС это остаются валидные пути к одному и тому же файлу, но для рекурсивного сканера дерево начинает разрастаться. В варианте GhostBranch путь повторяет одну ветку; в GhostTree несколько junction дают комбинаторный взрыв. Varonis приводит оценку: при глубине около 126 уровней две ветки дают 2^126, примерно 8.5 × 10^37 возможных путей. Главный практический риск связан с поведением инструментов, которые доверчиво обходят каталоги рекурсивно. По данным Varonis, такой каталог может подвесить сканирование папки, а файл рядом с junction-структурой останется непроверенным. Исследователи проверили обход на Windows Defender; Microsoft сначала закрыла тикет с формулировкой, что обход Defender не пересекает security boundary, но затем проблему всё равно исправила. Защита тут скучная, но полезная: не считать EDR-сканирование единственным контролем, логировать создание junction/reparse points в пользовательских директориях, ограничивать права записи там, где запускаются исполняемые файлы, и тестировать антивирусные/EDR-агенты на циклические структуры каталогов. Для защитной команды это хороший регрессионный тест: сканер должен уметь видеть цикл, а не бесконечно верить файловой системе. 🔗Источники: Varonis GhostTree Microsoft mklink Microsoft Hard Links and Junctions 🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK