Пять секунд CSS — и лучший ML-детектор фишинга слепнет полностью

Представьте: вы построили систему обнаружения фишинга на нейросетях. Она показывает 100% accuracy на бенчмарках. Публикуете статью, получаете признание. А потом кто-то добавляет на фишинговую страницу пятисекундную задержку отрисовки логотипа — и detection rate падает до абсолютного нуля. Не до 80%, не до 30%. До нуля.

Именно это продемонстрировали исследователи в работе, принятой на IEEE European Symposium on Security and Privacy. Целевая жертва — PhishIntention, один из самых продвинутых визуальных антифишинговых pipeline.

🔍 Как работают визуальные ML-детекторы? Схема простая:

1. Headless-браузер открывает подозрительную страницу и через фиксированный интервал делает скриншот
2. Нейросеть ищет на скриншоте логотипы и формы ввода, сравнивает с базой из 277 известных брендов
3. Если нашла совпадение с брендом, а домен не тот — фишинг

Вся конструкция держится на одном допущении: скриншот корректно отражает содержимое страницы. И именно это допущение оказалось ложным.

⏱ PhishIntention делает снимок через 2 секунды после начала загрузки. Среднее время полной загрузки веб-страницы — 7.2 секунды. Разница в 5.2 секунды — это timing gap, окно, в которое атакующий может спрятать всё самое важное.

Атака выглядит так: логотип и брендинг загружаются в DOM сразу, но визуально скрыты через clip-path с нулевой видимой областью. Через 5+ секунд setTimeout запускает плавное раскрытие. Детектор к этому моменту уже сделал снимок пустой страницы, не нашёл совпадений с брендами и пометил её как безопасную. А реальный пользователь видит полноценный клон PayPal или Google и спокойно вводит пароль.

🎯 Что делает эту атаку особенно опасной:

• Не нужно знать архитектуру детектора — работает в black-box режиме
• Не нужна серверная логика — хватает пары строк CSS и JS
• Не нужны adversarial perturbations — никаких модификаций пикселей
• Пользователь ничего не замечает — страница выглядит нормально

Самое интересное: систематический обзор литературы показал, что ни одна предыдущая работа по adversarial robustness фишинг-детекторов не рассматривала timing-вектор. Все исследователи предполагали, что скриншот захватывается корректно. Никто просто не подумал, что атакующий может сыграть на секундомере.

Фикс кажется очевидным — увеличить время ожидания перед снимком. Но это создаёт новую проблему: при массовом сканировании тысяч URL каждая лишняя секунда ожидания превращается в часы простоя pipeline.

Полный разбор обеих стратегий отложенного рендеринга и возможных контрмер — в статье на форуме.

https://codeby.net/threads/obkhod-ml-detektorov-fishinga-cherez-otlozhennyi-rendering-ot-100-k-0-detektsii.93724/

Почему ядро Android не понимает, что делают приложения — и как eBPF решает это без патчей

Представьте: приложение отправляет SMS с вашего телефона. Ядро Linux в этот момент видит только ioctl(fd, BINDER_WRITE_READ, &bwr). Тот же самый вызов, что и при запросе версии ОС. Или при чтении контактов. Или при получении GPS-координат. Для ядра всё это — одинаковые байты в Binder-транзакции.

Это и есть семантический разрыв — фундаментальная проблема аудита Android, над которой бьются больше десяти лет. В отличие от десктопного Linux, где sendto() прямо говорит аудитору «тут отправка данных», на Android всё проходит через цепочку: приложение → libbinder.so → ioctl → Binder-драйвер → system_server. И на уровне системных вызовов любое действие выглядит одинаково.

🔍 Существующие решения делятся на два лагеря, и оба проигрывают:

• Модификация ОС (ClearScope и аналоги) — хуки внедряются прямо в Binder-драйвер и framework. Устойчиво к обходу, но каждое обновление Android требует ручного переноса патчей. Архитектурный тупик для реальных деплоев.
• User-space инструментация (BPFroid, Frida) — не трогает ядро, но обходится. Приложение с native-кодом может дёрнуть ioctl() на /dev/binder напрямую, минуя все хуки. Малварь так и делает.

Исследователи из TU Darmstadt и Athens University разорвали эту дихотомию проектом WOOTdroid. Идея: eBPF-программы загружаются в ядро без его пересборки, цепляются к стабильным tracepoints и перехватывают Binder-транзакции на уровне драйвера. Но в отличие от сырой трассировки, WOOTdroid ещё и декодирует содержимое — имена методов, типизированные аргументы, целевые сервисы.

📊 Цифры с Pixel 9 на Android 16 впечатляют: eBPF-трассировщик перехватил на 33% больше системных вызовов, чем штатный ftrace. При этом overhead по Geekbench — не выше 3.6%. Никаких патчей к ядру, никакой пересборки AOSP, никаких инъекций в процесс приложения.

Почему это важно на практике? Потому что малварь всё чаще использует native-код для обхода user-space мониторинга. Формирует Parcel вручную, вызывает ioctl() напрямую — и Frida, и BPFroid пропускают транзакцию полностью. WOOTdroid сидит в ядре и видит всё, независимо от того, как именно приложение сформировало вызов.

⚡ Отдельно интересен контринтуитивный момент: eBPF-программы работают в sandbox внутри ядра, проходят верификацию перед загрузкой и не могут уронить систему. По сути — kernel-level аудит с user-space безопасностью деплоя.

Полный разбор архитектуры, механики Binder-декодирования и результатов бенчмарков — в развёрнутой статье на форуме.

https://codeby.net/threads/wootdroid-audit-android-binder-ipc-bez-semanticheskogo-razryva.93727/

🔬 Шпион внутри корпуса: как один чиплет крадёт секреты другого

Представьте: атакующему больше не нужен физический доступ к устройству. Ему не нужен EM-пробник, осциллограф или тепловизор. Потому что он уже внутри микросхемы — в буквальном смысле.

Исследователи экспериментально доказали: RF-чиплет, встроенный в гетерогенную 2.5D-упаковку, способен захватывать электромагнитный сигнал, коррелированный с криптографической активностью соседнего вычислительного кристалла. Без единого пробника на поверхности корпуса. Это принципиально новая модель угроз, которой в русскоязычном пространстве пока не посвящено ни одного материала.

⚡ Почему это работает?

В 2.5D-архитектурах несколько кристаллов размещены горизонтально на общем кремниевом интерпозере. И вот ключевой момент: этот интерпозер — не инертная подложка, а полупроводниковая среда с конечным сопротивлением и паразитными ёмкостями. Когда вычислительный die выполняет раунд AES, токи потребления создают падение напряжения на паразитных элементах PDN. Эти колебания распространяются по общей подложке и наводят напряжения на проводниках соседнего чиплета.

Инженеры по signal integrity десятилетиями боролись с этим эффектом — substrate coupling — ради целостности сигналов. Теперь тот же механизм работает на атакующего.

В 3D-стеках ситуация ещё острее. Кристаллы уложены вертикально и соединены через TSV — медные столбы диаметром 5–10 мкм, пронизывающие кремний. При расстояниях между слоями порядка 50 мкм паразитная ёмкостная связь достигает единиц фемтофарад — на частотах сотен мегагерц этого хватает для наблюдаемой утечки.

🎯 Три канала утечки, которых нет в монолитных SoC

• Substrate coupling — через общую подложку интерпозера (ёмкостная и резистивная связь)
• TSV coupling — через взаимную индуктивность вертикальных переходников в 3D-стеках
• RF/EM coupling — через ближнее электромагнитное поле при наличии антенного элемента на одном из чиплетов

Самое тревожное — модель угроз. Современные чиплетные системы собираются из компонентов разных вендоров. Вычислительный die от одного производителя, память от другого, коммуникационный чиплет от третьего. Достаточно скомпрометировать один элемент в supply chain — и вредоносный чиплет становится внутренним сенсором, который снимает side-channel трассы с расстояния в сотни микрон. Это на порядки ближе, чем любой внешний пробник.

🛡️ UCIe-интерконнект между чиплетами тоже под ударом: сигналы физически покидают кристалл, проходят через интерпозер и имеют значительно бо́льшую амплитуду, чем внутренние on-chip сигналы. Каждый такой переход — наблюдаемая поверхность атаки.

В полной статье разобрали физику утечек, формальную модель угроз и практический workflow корреляционного анализа трасс.

https://codeby.net/threads/side-channel-ataki-na-chiplety-novaya-fizicheskaya-poverkhnost-ataki-v-2-5d-3d-sistemakh.93732/

80% времени на подготовку, 20% — на сами уязвимости: почему мобильный пентест так устроен

Знакомая ситуация: вы запускаете Frida-скрипт с CodeShare, ждёте трафик в Burp Suite — а там пусто. Приложение использует OkHttp3 с CertificatePinner, плюс кастомную проверку целостности APK при старте. Стандартный скрипт молча отваливается, а вы даже не понимаете почему.

Именно так начался один из пентестов e-commerce маркетплейса. Четыре часа ушло на декомпиляцию в jadx, поиск конкретного класса с пиннингом и написание точечного хука. После этого IDOR в платёжном API нашёлся за 15 минут. Вся суть мобильного пентеста в одном примере.

🔧 Вот что ломается чаще всего на старте:

• Версия frida-server не совпадает с frida-tools — причина ошибки «Failed to spawn» в каждом втором обращении на форумах. Проверяйте через frida --version и качайте сервер строго той же версии.

• Образ эмулятора с надписью «Google Play» — production-сборка, root недоступен в принципе. Нужен образ с Google APIs, но без Google Play. Классическая ловушка, в которую попадают все хотя бы раз.

• На Android 7+ пользовательские CA-сертификаты не доверяются приложениями по умолчанию. Даже без SSL pinning трафик не пойдёт через Burp, пока сертификат не окажется в системном хранилище /system/etc/security/cacerts/.

📱 Отдельная боль — эмулятор-детекция. Приложение проверяет ro.hardware, ro.product.model, ищет QEMU-артефакты и отказывается работать. Решение — физический Pixel с unlocked bootloader и Magisk. На практике удобно держать оба варианта: эмулятор для статического анализа, физическое устройство — когда эмулятор не проходит проверки.

Лайфхак с Magisk: вместо десяти команд для установки сертификата Burp в системный раздел — поставьте модуль MagiskTrustUserCerts. Устанавливаете сертификат штатно через настройки безопасности, модуль перемещает его в системное хранилище при перезагрузке. Три клика вместо десяти команд.

🎯 Главное, что стоит помнить: APK — это обёртка, цель — серверное API. Root-detection, anti-tampering, SSL pinning — всё это клиентские защиты категорий MASVS-RESILIENCE и MASVS-NETWORK. Они усложняют тестирование, но серверные уязвимости никуда не деваются. Сервер остаётся дырявым вне зависимости от того, проверяет ли клиент наличие su-бинаря.

В полной статье — пошаговая настройка окружения, конкретные команды для каждого этапа и разбор случаев, когда стандартный tooling молча ломается. Всё, что нужно, чтобы дойти от чистого эмулятора до перехваченного трафика.

https://codeby.net/threads/pentest-android-prilozhenii-ot-nastroiki-okruzheniya-do-obkhoda-root-detection-i-ssl-pinning.93723/

43% MCP-серверов уязвимы к инъекциям команд. А ваш разработчик только что поставил ещё один

За последние полгода MCP-серверы стали стандартной частью рабочего окружения разработчиков. Cursor, Claude Desktop, кастомные прокси к внутренним API — всё это подключается за минуту и получает прямой доступ к файловой системе, переменным окружения и сетевым ресурсам хоста. Проблема в том, что эти серверы почти никогда не проходят security review.

🔍 По данным Equixly, картина такая: 43% протестированных MCP-серверов содержат command injection, 30% — SSRF, 22% — path traversal. И это не экзотика — это серверы, которые разработчики ставят добровольно и используют каждый день.

Почему это опасно? MCP-сервер по сути — неаутентифицированный API с доступом к shell-командам. Спецификация предлагает OAuth 2.0, но на практике большинство серверов запускаются без авторизации вообще. Валидация параметров — на совести разработчика. А главное: MCP-сервер можно вызвать напрямую, минуя LLM. Кто добрался до эндпоинта — шлёт JSON-RPC-запросы к инструментам без какого-либо контроля.

⚡ Свежий пример — три CVE в официальном mcp-server-git. Одна из них (CVE-2025-68143) позволяла через инструмент git_init превратить любую директорию в git-репозиторий, а затем читать из неё файлы через git show. Решение от мейнтейнеров? Полностью удалили инструмент из кодовой базы. Другая (CVE-2025-68144) — argument injection: параметры git_diff и git_checkout передавались в CLI без санитизации. Значение вроде --output=/etc/passwd интерпретировалось как опция командной строки.

Каждая уязвимость по отдельности — CVSS 6.3–6.5, средний уровень. Но в цепочке с prompt injection импакт возрастает кратно: вредоносная инструкция в README репозитория заставляет LLM вызвать уязвимый инструмент, а разработчик жмёт «Разрешить» на автопилоте — десятки раз в день.

🎯 С точки зрения kill chain MCP-серверы закрывают сразу несколько этапов:

• Initial Access — удалённый сервер на Streamable HTTP без аутентификации
• Execution — command injection через tool-параметры
• Credential Access — чтение .env, SSH-ключей, API-токенов
• Collection — path traversal к исходникам и конфигам CI/CD

Самый реалистичный сценарий — внутренний пентест или red team с доступом к сегменту разработки. Машина разработчика с MCP-сервером — это одновременно точка входа, источник креденшалов и плацдарм для lateral movement.

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

https://codeby.net/threads/uyazvimosti-mcp-serverov-rce-ssrf-i-in-yektsii-cherez-odin-post-zapros.93746/

$28.50 за компрометацию Active Directory — но сколько стоят галлюцинации?

LLM-агент Excalibur ломает четыре из пяти хостов в AD-лаборатории за $28.50 в API-кредитах. RapidPen получает shell за 200–400 секунд при стоимости меньше доллара. Впечатляющие цифры из бенчмарков 2026 года. Но вот что происходит, когда ту же модель просят разобрать реальную функцию парсинга на C: она уверенно диагностирует use-after-free в коде, который вообще не работает с динамической памятью.

🎯 Между рекламными бенчмарками и реальным аудитом кода — пропасть из галлюцинаций, потери контекста и ложных срабатываний. Вопрос не в том, работают ли LLM для поиска уязвимостей, а в том, где именно в цепочке аудита их ставить и как не утонуть в шуме.

Ключевой инсайт: LLM — не замена SAST-сканеру и не замена ручному разбору. Это прослойка между ними. Статический анализатор отработал, нашёл подозрительные паттерны, а вы ещё не начали вручную раскручивать call chain'ы. Вот тут модель реально полезна.

⚡ Практический workflow выглядит так:

• Прогоняете semgrep с правилами p/security-audit и p/owasp-top-ten — получаете JSON с координатами подозрительных мест
• Строите граф зависимостей через tree-sitter или cscope, чтобы понять, какие файлы связаны с находками
• Выделяете attack surface — HTTP-хендлеры, парсеры, десериализаторы идут первыми
• Скармливаете LLM конкретные файлы с контекстом вызовов и типов, а не весь репозиторий

Скармливать модели весь codebase — антипаттерн. Даже 128K токенов — это порядка 300–400 страниц кода. Средний open-source проект сильно больше. Модель подавится и выдаст generic-ответ из учебника.

🔑 Ещё одна ловушка — промпты. «Найди уязвимости в этом коде» — прямой путь к мусору на выходе. Рабочий промпт строится по блокам: роль и ограничение, конкретный контекст проекта, тип уязвимости, который ищете, формат ответа и требование обосновать каждый вердикт ссылкой на строку кода. Без структуры модель галлюцинирует.

Где LLM реально хорош: внутренний пентест с доступом к исходникам и bug bounty по open-source целям. Публичный код плюс история коммитов дают модели максимум контекста. Где плохо: аудит бинарей без исходников — декомпилированный код теряет семантику, и модель плывёт.

🛡️ Важный момент для NDA-проектов: код, отправленный в облачный API, покидает ваш контур. Для таких задач — только локальные модели через Ollama с DeepSeek Coder или CodeLlama.

В полной статье — детальный разбор каждого шага workflow, готовые шаблоны промптов и конкретные примеры с реальным кодом.

https://codeby.net/threads/llm-dlya-poiska-uyazvimostei-v-kode-prakticheskii-workflow-ot-sast-do-poc.93750/

$5,9 млн за одну утечку — почему банки проигрывают хакерам ещё до первого алерта

Вот что меня цепляет в статистике IBM по финансовому сектору. Не сама сумма — а то, как банки узнают о взломе. Большинство — не из алертов собственного SOC, а из звонка регулятора или поста в Telegram. Между моментом, когда атакующий зашёл в сеть, и моментом, когда об этом кто-то догадался, проходят недели. Иногда — месяцы.

За это время группировки вроде Cobalt и Silence успевают пройти полный kill chain — от фишингового письма до управления SWIFT-терминалом.

🔍 Как это выглядит на практике? Четыре фазы, каждая из которых — окно для обнаружения. И каждая — провал большинства защитных команд.

Фаза 1 — точка входа. Целевой фишинг или эксплуатация публичного сервиса. По данным ФинЦЕРТ за 2024 год, фишинг — около 8–9% зарегистрированных атак на финсектор. Кажется мало? Но в red team-проектах поддельное письмо «от Центробанка» остаётся самым результативным вектором. Люди верят бланкам.

Фаза 2 — сбор учёток и перемещение. Дамп LSASS, брутфорс сервисных аккаунтов, кейлоггеры. Дальше — Pass the Hash, легитимные учётные записи. Самое болезненное: горизонтальное перемещение часто идёт через сегменты, которые формально изолированы. Но на практике маршрут через management-VLAN существует. Формально — нельзя. Фактически — пожалуйста.

Фаза 3 — цель. SWIFT-терминал, процессинг, АБС (Diasoft, ЦФТ), HSM. К этому моменту у атакующего уже привилегии доменного администратора.

💸 Фаза 4 — вывод денег. Формирование платёжных поручений, манипуляция лимитами, переводы через скомпрометированные АРМ-ы КБР. Именно здесь большинство банков впервые замечают проблему. Когда деньги уже ушли.

И это только kill chain. А ведь есть ещё атаки на банковские API, jackpotting банкоматов, обход антифрод-систем, трояны вроде Casbaneiro, уязвимости мобильного банкинга. Каждый вектор — отдельная дисциплина со своими техниками и слепыми зонами защиты.

⚡ Что объединяет все эти направления? Три вещи:

• Сегментация сети, которая существует на бумаге, но не в реальности
• SOC, который мониторит периметр, но слеп внутри критичных сегментов
• Регуляторный комплаенс (ГОСТ Р 57580, PCI DSS), который выполняется формально, а не по сути

Мы собрали всё это в одну карту — 11 направлений с детальными разборами: от конкретных команд пентеста до SIEM-правил и IOC. Полный гайд ждёт в статье на форуме.

https://codeby.net/threads/kiberbezopasnost-bankov-vektory-atak-tekhniki-pentesta-i-zashchita-bankovskoi-infrastruktury.93756/

☀️ Скидка 20% на подписку HackerLab!

Летом наконец есть время порешать задачки в удовольствие - полный доступ к заданиям, курсам и про-лабораториям.

Промокод: Summer2026

Только до 14 июня — не упусти
👉 https://hackerlab.pro/subscription

🔧 Обсуждай задачи и переписывайся прямо в HackerLab

Встроили форум-виджет Codeby прямо на страницы тасков — теперь обсуждение, подсказки и личка живут там же, где само задание.

Что умеет виджет:
— Тред с обсуждением рядом с задачей
— Скриншоты, файлы, реакции, онлайн-статусы
— Автообновление без перезагрузки страницы

Личные сообщения внутри виджета:
— Пишешь напрямую, не уходя с платформы
— Бейдж непрочитанных, поиск по имени, редактирование

Авторизация через Codeby ID. Работает на мобильном.

CTF — это не только решить в одиночку. Вовремя спросить или подсказать растит быстрее 🚀

Попробуйте и расскажите, чего не хватает 👇
🔗 https://codeby.net/threads/obsuzhdai-zadachi-i-perepisyvaisya-pryamo-v-hackerlab-vstroili-forum-i-lichnyye-soobshcheniya.93938/

🔍 Неделя 2: Virtual Server — Service Enumeration через SSH и FTP

Серия «Сетевая разведка за 30 дней» продолжается.

Открытые порты — это только начало. На этой неделе учимся читать сервисы: выжимать версии, баннеры, конфиги и файлы до первой попытки эксплуатации.

Цель: VDS, где SSH и FTP настроены «потом исправлю»

Инструменты: — nmap -sV + скрипты ftp-anon, ssh-auth-methods — anonymous FTP: конфиги, бэкапы, исходники — ssh-audit — слабые алгоритмы и разрешённые методы — nc для сырого banner-grab + searchsploit по версии

⏱️ Старт: 8 июня, 20:00 МСК 🏁 Дедлайн: 14 июня, 23:59 МСК

До дедлайна — обсуждаем подходы, не флаги. После — writeup'ы открыты.

👇 Задание и обсуждение: 🔗 https://codeby.net/threads/nedelya-2-virtual-nyi-server-service-enumeration-cherez-ssh-i-ftp.93753/