12 из 20 новичков пришли с BlackArch — и это была ошибка

На одном воркшопе для начинающих пентестеров случилась показательная история. Большинство участников принесли флешки с BlackArch — логика простая: «там же больше всего инструментов». Первый час группа воевала с pacman и отсутствием графического окружения, пока остальные с Kali уже сканировали учебные цели через nmap. К обеду трое переставили систему, двое ушли. А один человек с Parrot OS тихо работал весь день без единой проблемы.

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

🔍 Вот что реально отличает три главных дистрибутива 2026 года:

• Kali Linux — Debian Testing, пакетный менеджер apt, курированный набор из 600+ инструментов. Offensive Security тестирует каждый пакет перед включением. Xfce по умолчанию, потребление в idle — 800–1200 МБ RAM.

• Parrot OS — тоже Debian, но с MATE и заметно меньшим аппетитом: 400–700 МБ в idle. Из коробки идут AnonSurf для маршрутизации через Tor, встроенное шифрование, и есть Home Edition — полноценная повседневная ОС без пентест-арсенала.

• BlackArch — репозитории поверх Arch Linux, pacman, rolling release. Тысячи пакетов, но конфликты зависимостей — полностью ваша головная боль. GUI из коробки может вообще отсутствовать.

⚡ Практический момент, который мало кто проговаривает. Разница между apt и pacman — не синтаксис. Это разные последствия ошибок. Когда в три ночи на внешнем пентесте hashcat отказывается запускаться после обновления, в Kali вы откатите пакет за минуту. В BlackArch придётся разбираться с цепочкой зависимостей от пяти минут до часа. В три ночи час — это очень много.

💡 Конкретный кейс с железом: ThinkPad X230, 4 ГБ RAM, HDD. Parrot не тормозил при одновременном Burp Suite и Firefox с десятком вкладок. Kali на том же железе ощутимо задумывался при переключении между приложениями. Если у вас старый ноутбук — Parrot объективно комфортнее.

И ещё важный маркер. Половина дистрибутивов из «топ-10 для хакинга» — мертвы. Cyborg Linux, DEFT, Bugtraq — всё это не обновлялось годами. Если в обзоре 2026 года вы видите эти названия — перед вами копипаста из 2019-го.

В полной статье — decision tree для выбора, детальные системные требования и разбор инструментов по категориям. Читайте и выбирайте осознанно.

https://codeby.net/threads/luchshii-distributiv-dlya-pentesta-kali-linux-vs-parrot-os-vs-blackarch-chestnoye-sravneniye-2026.93771/

Три радиопротокола — три незакрытых вектора: почему Wi-Fi — лишь верхушка айсберга

На свежем Red Team-проекте для розничной сети в документации значился WPA3, на площадке стоял Cisco WLC. Казалось, беспроводной периметр закрыт. На деле все точки доступа работали в WPA3 Transition Mode — параллельно принимая WPA2-подключения. Три минуты hcxdumptool без единого deauth-фрейма, 40 минут hashcat с правилами — и PSK подобран. К обеду пентестер уже сидел в корпоративном VLAN.

Но самое интересное началось дальше.

🔓 14 BLE-замков на складских дверях — без аутентификации на GATT-запись. Подошёл, отправил команду — дверь открылась. ZigBee-датчики температуры с дефолтным ключом шифрования висели в том же сегменте, что и СКУД. Один объект — три протокола — три точки входа.

И это типичная картина в 2025 году. Компании вкладываются в защиту Wi-Fi, а Bluetooth и ZigBee остаются слепой зоной.

📡 Почему PMKID-атака — главный вектор через Wi-Fi

Классический перехват handshake требует подключённого клиента и deauth-фрейма, который палит вас перед WIPS. PMKID-подход работает иначе: точка доступа сама отдаёт нужный хеш в первом сообщении 4-way handshake. Клиенты не нужны, deauth не нужен — для системы мониторинга вы практически невидимы.

Дальше — офлайн-перебор. И тут критична разница в железе: RTX 3060 выдаёт ~400 тысяч хешей/с для WPA2, встроенная графика ноутбука — десятки тысяч. Поэтому на объекте запускайте только захват, а брутфорс гоните удалённо.

🔑 На что обращать внимание при разведке

• WPA3 Transition Mode в airodump-ng отображается как WPA2 WPA3 в колонке ENC. Если видите это — WPA2-часть атакуема стандартными методами
• Скрытые SSID — не защита. Probe request клиента содержит имя сети в открытом виде. Достаточно дождаться переподключения
• WPS включён — проверяйте через wash -i wlan0mon -C. Иногда Pixie Dust — самый быстрый путь внутрь

📱 BLE и ZigBee — забытый фронт

BLE-устройства в корпоративной среде — это замки, трекеры, датчики. Многие из них не требуют аутентификации на уровне GATT. Ubertooth One остаётся единственным доступным инструментом для полного BLE-сниффинга на link layer — проекту уже пять лет, альтернатив нет.

ZigBee-сети автоматизации зданий часто используют дефолтные ключи шифрования. zbstumbler из KillerBee покажет PAN ID и координаторы, а дальше — перехват и replay.

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

https://codeby.net/threads/besprovodnoi-pentest-v-2025-ataki-na-wi-fi-bluetooth-i-zigbee.93711/

Ваши средства защиты вообще работают? Как проверить — и не обмануть себя

Восьмизначный бюджет на NGFW, EDR, SIEM, WAF — а реальной атакой всё это никто не проверял. Знакомо? По данным Picus Red Report 2026, объём атак с шифрованием упал на 38% за год. Атакующие больше не ломятся напролом — они тихо выкачивают данные через легитимные облачные API и доверенные протоколы. Ваш файрвол даже не моргнёт.

Именно поэтому в 2026 году ключевое слово — валидация безопасности. Не «настроено ли по стандарту?», а «остановит ли это реальную атаку прямо сейчас?». Можно пройти аудит, повесить сертификат на стену — и при этом пропустить Kerberoasting в Active Directory без единого алерта. Compliance и реальная защищённость — это два разных мира.

🔍 Сегодня существуют три ключевых метода валидации, и каждый закрывает свой участок:

• BAS (Breach and Attack Simulation) — платформа непрерывно прогоняет сотни известных техник по MITRE ATT&CK через ваши контроли. Работает 24/7, безопасна для прода (эмулирует, но не эксплуатирует). Отвечает на вопрос: «Видит ли SIEM эту технику? Блокирует ли EDR?». Стоимость — от $30K в год.

• Автоматизированный пентест — не просто сканер, а инструмент, который строит полные цепочки атак. Нашёл уязвимость → проэксплуатировал → двинулся дальше по сети. Показывает, как далеко пройдёт атакующий. Запускается периодически — раз в неделю или месяц.

• Ручное тестирование — живой Red Team, который находит то, что автоматизация в принципе не увидит: уязвимости бизнес-логики, социальную инженерию, нестандартные цепочки через доверенные отношения между системами. Самый глубокий, но и самый дорогой метод.

⚡ Главный инсайт: ни один из этих методов не работает в одиночку. BAS покажет, что SIEM-правило не срабатывает на конкретную технику. Автоматизированный пентест покажет, что через эту дыру можно дойти до контроллера домена. А ручной тестировщик найдёт путь, о котором ни одна автоматика даже не подозревала — например, через скомпрометированную сервисную учётку, которая выглядит абсолютно легитимно.

📊 Что касается бюджета: BAS стартует от $30K/год, автоматизированный пентест — от $40K, ручной проект — от $20K за разовый engagement. Зрелые команды комбинируют все три и добавляют Purple Team — совместные учения атакующих и защитников, где каждый найденный gap закрывается в реальном времени.

Разобрали все методы, платформы и decision tree для построения программы с нуля — в полном руководстве.

https://codeby.net/threads/validatsiya-bezopasnosti-v-2026-godu-bas-avtomatizirovannyi-pentest-i-ruchnoye-testirovaniye-polnoye-rukovodstvo.93720/

Пять секунд 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/