Похек
All materials published on the channel are for educational and informational purposes only. Мнение автора ≠ мнение компании, где работает автор Чат: @poxek_chat Реклама: @szybnev или https://telega.in/c/poxek РКН: https://clck.ru/3FsVhp
نمایش بیشتر📈 تحلیل کانال تلگرام Похек
کانال Похек (@poxek) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 16 957 مشترک است و جایگاه 7 815 را در دسته فناوری و برنامهها و رتبه 39 817 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 16 957 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 07 ژوئن, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 351 و در ۲۴ ساعت گذشته برابر -2 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 17.26% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 9.88% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 2 924 بازدید دریافت میکند. در اولین روز معمولاً 1 675 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 16 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند cvss, llm, cve, api, cve-2025 تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“All materials published on the channel are for educational and informational purposes only.
Мнение автора ≠ мнение компании, где работает автор
Чат: @poxek_chat
Реклама: @szybnev или
https://telega.in/c/poxek
РКН: https://clck.ru/3FsVhp”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 08 ژوئن, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
در حال بارگیری داده...
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 08 ژوئن | +14 | |||
| 07 ژوئن | +3 | |||
| 06 ژوئن | +16 | |||
| 05 ژوئن | +23 | |||
| 04 ژوئن | +36 | |||
| 03 ژوئن | +14 | |||
| 02 ژوئن | +17 | |||
| 01 ژوئن | +28 |
| 2 | Кажется, нейрослоп добрался до багбаунти...
Видим, как отчеты, написанные ИИ, становятся все длиннее, а пользы в них все меньше. Поэтому нужен коллективный разум.
Задача простая: придумайте, как Standoff Bug Bounty может защищаться от нейрослопа.
Что угодно:
▪️новые механики платформы;
▪️ачивки и антиачивки;
▪️ограничения и штрафы;
▪️способы оценки качества отчётов;
▪️мемные идеи, которые почему-то могут сработать.
▪️платить за сдачу отчёта
За самые интересные предложения подарим лимитированный мерч Poxek × Standoff Bug Bounty
Лут можно забрать:
🎁 на Standoff Talks лично
📦 или отправим почтой
🕰 А ещё 18 июня на Standoff Talks проведу открытую Q&A-сессию про AI в пентесте.
Приходите холиварить, задавать неудобные вопросы и вместе думать, как жить в мире, где уязвимости ищут нейронки, а мы ищем уязвимости в ИИ)
Свои идеи оставляйте в комментариях 👇 | 1 974 |
| 3 | 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 684 |
| 4 | 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 | 1 918 |
| 5 | 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 | 2 361 |
| 6 | 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 | 2 630 |
| 7 | Ахой, комрады!
Этот канал непотопляемый даже не смотря на мое отсутствие тут некоторое время. Оправдываться не буду, мой косяк, постараюсь вернуть стабильность. 🌚
Как АС 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 под доменным админом по списку хостов | 1 999 |
| 8 | Как 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 | 2 465 |
| 9 | сейчас бот точно ожил, можете тыкать у кого днём не работал мини-апп | 2 470 |
| 10 | 💉 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 июня! | 2 571 |
| 11 | 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 | 2 355 |
| 12 | С первым днём лета!!! | 2 411 |
| 13 | 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 | 2 570 |
| 14 | Картирование ботнет-операций через бэкенд-инфраструктуру и сетевые 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 | 2 267 |
| 15 | 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 | 2 932 |
| 16 | ❗️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 | 3 135 |
| 17 | ёPRSTCON всё еще продолжается | 3 473 |
| 18 | Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️
Уже 4 июня, ровно в 14:00, мы прольем свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел». В этот день вы сможете вместе с нами:
🚩раскрыть все аномалии в сети;
🌥увидеть, как детектирование переходит на заоблачный уровень;
🦾запечатлеть, как «расстановку сил» меняет автоматизированное реагирование.
Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:
1) Отменить все свои планы на 4 июня в 14:00
2) Зарегистрироваться на онлайн-запуск по ссылке
3) С нетерпением ждать встречи вместе с нами
Увидимся уже скоро! Такие дела. | 1 936 |
| 19 | Щелчок и я уже на ёPRTCON | 3 230 |
| 20 | 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 | 3 005 |
اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
