Themida снята через unlicense — но динамический анализ не живёт.

ScyllaHide падает в Fatal Error 0x00005c, KsDumper молчит, TitanHide крашит процесс. Патч от третьих лиц через MinHook непонятным образом проходит проверку контрольной суммы импортов и переводит приложение с Dongle-проверки на сверку лицензии с файлом в папке. Алгоритм генерации этого файла — внутри. Но добраться до него не получается: защищённые .dll, замусоренный трейс после MinHook_Initialise_Hook, и приложение ещё и детектит VM.

🎯 Что уже стоит на столе у автора:
• Unlicense отработал, IAT и OEP восстановлены — есть unpacked_.exe для статики
• MinHook в чужом патче почему-то проходит CRC-проверку импортов/экспортов — и это само по себе вопрос
• Динамика умерла: 64dbg + ScyllaHide = Violation Access, чем больше опций включено, тем стабильнее краш
• Подозрение, что оригинальный алгоритм генерации затёрт, а рабочий спрятан в injected DLL — тоже под Themida

🔍 У человека конкретные три вопроса: как отличить hooked-функцию от динамически подгруженной из уже пропатченных библиотек, стоит ли дальше копать динамику через обход debugger detection, и как снимать защиту с .dll если она под VMProtect сверху. Если кто-то воевал с Themida на .dll или разбирался с injected MinHook-патчами без исходников — загляните, человек не новичок, но застрял на 4-й день.

https://codeby.net/threads/vopros-khuk-vytashchit-algoritm-generatsii-themida.92760/

57% Patch Tuesday — это повышение привилегий. Совпадение?

Получить reverse shell — полдела. Обычный пользователь не даст дампа LSASS, отключения EDR или нормального persistence. Нужен SYSTEM — и первое полугодие 2026-го выдало рекордный урожай LPE-уязвимостей.

🔥 Главная история — BlueHammer и CVE-2026-33825. Исследователь слил PoC через 12 дней после раскрытия. Механика: цепочка из пяти легитимных компонентов — Defender, VSS, Cloud Files API, Oplocks и Symbolic Links — по отдельности не сломан ни один. В связке дают чтение SAM-файла, NTLM-хеши и SYSTEM на полностью пропатченных Win10/11.

🎯 Вторая — CVE-2026-21533 в Remote Desktop, уже в каталоге CISA KEV. Из RDP-сессии рядового пользователя — прямой путь к сессиям доменных админов.

Полный разбор, энумерация и путь до SYSTEM:

https://codeby.net/threads/privilege-escalation-windows-2026-razbor-svezhikh-cve-iz-patch-tuesday-i-tekhniki-lpe-ekspluatatsii.92750/

79% атак — без единого файла малвари. Как это работает?

Медианное время от первого доступа до горизонтального перемещения — 48 минут. Рекорд — 51 секунда. Без единого файла, который спалит EDR.

🔍 Windows сама даёт атакующему всё необходимое: WMI, PowerShell Remoting и DCOM — легитимные механизмы, которые админы используют ежедневно. Именно поэтому детект буксует.

Три вектора из статьи:

• WMI — создаёт процесс на удалённом хосте без копирования файлов; wmiprvse.exe как родитель cmd.exe — главный артефакт
• PSRemoting — WinRM по TCP 5985/5986, Kerberos и NTLM; Pass-the-Hash через Evil-WinRM
• DCOM — движение через COM-объекты, dcomexec.py из Impacket

⚙️ Для каждой техники — команды, сетевые артефакты и почему одни подходы проходят мимо SOC, а другие детектятся мгновенно.

https://codeby.net/threads/lateral-movement-v-windows-bez-malvari-wmi-psremoting-i-dcom-na-praktike.92753/

Одна цифра в запросе — и чужие паспортные данные у тебя в браузере

Именно так работает IDOR. Меняешь `1234` на `1235` в API-запросе — сервер отдаёт чужой документ. WAF молчит, сканер ничего не нашёл, разработчик уверен, что всё защищено.

🎯 Почему это золотая жила в bug bounty:

• Автоматика IDOR не ловит — нужен ручной анализ бизнес-логики
• Одна уязвимость = от $200 до $5000+
• Цепочка IDOR → Account Takeover — гарантированный P1 и максимальная выплата

Разница между $300 и $3000 за ту же технику — в классификации импакта. Читаешь чужие данные — одна цена. Захватываешь аккаунт — совсем другая история.

По кейсам от Deteact: только за несколько IDOR-находок выплатили более $25 000.

Методология, инструменты и структура репорта на P1:

https://codeby.net/threads/idor-uyazvimost-v-bug-bounty-kak-nakhodit-i-reportit-dlya-maksimal-nykh-vyplat.92767/

Burp Suite + OWASP Top 10: какой плагин ставить и зачем

Один extension на каждую категорию OWASP:

• A01 Broken Access Control → Autorize: вставил cookie низкопривилегированного юзера, браузишь как админ — красный «Bypassed!» = готовый IDOR
• A03 Injection → ActiveScan++: добавляет XXE, SSTI, улучшенный SQLi
• A04 Insecure Design → Turbo Intruder: race conditions на промокодах — тысячи req/sec
• A07 Auth Failures → JWT Editor: атаки alg:none, weak secret, key confusion из Repeater
• A10 SSRF → Collaborator Everywhere: браузишь приложение, extension инжектирует заголовки и ловит out-of-band callbacks

Плюс Param Miner (до 65 000 параметров за запрос) и Retire.js для уязвимых JS-библиотек.

https://codeby.net/threads/burp-suite-extensions-shpargalka-po-owasp-top-10-2025-kakoi-plagin-stavit-i-zachem.92768/

За апрель на форуме вышло 111 материалов. Мы посмотрели Метрику и увидели закономерность, которую не покажет ни один рейтинг «по просмотрам».

Самая читаемая статья месяца, разбор реальных техник применения LLM в атакующих операциях (569 уникальных читателей). Без хайпа про «ИИ заменит пентестера»: конкретные сценарии разведки, генерация payload под редкий таргет, и та самая граница, за которой модель начинает галлюцинировать и портить операцию.
https://codeby.net/threads/ii-v-penteste-real-nyye-tekhniki-ispol-zovaniya-llm-v-atakuyushchikh-operatsiyakh.92644/

Но интереснее смотреть не на трафик, а на глубину. Техническая статья про kernel rootkit в Linux, перехват syscall table, модификация VFS, сокрытие процессов через /proc, собрала «всего» 280 посетителей. А среднее время чтения 1:37. Для kernel-level материала это аномалия: обычно такие вещи смотрят по диагонали и закрывают на второй странице листинга. Те, кто пришёл, сидели с кодом.
https://codeby.net/threads/kernel-rootkit-linux-perekhvat-syscall-table-modifikatsiya-vfs-i-sokrytiye-protsessov-ot-koda-do-detektirovaniya.92640/

То же самое с апрельским Zero-Day в Telegram (ZDI-CAN-30207, CVSS 9.8). 413 посетителей и показатель отказов 11%, читатели уходили только после того, как дочитывали разбор вектора до конца.
https://codeby.net/threads/zero-day-v-telegram-zdi-can-30207-razbor-uyazvimosti-telegram-zero-day-s-otsenkoi-cvss-9-8.92557/

А вот что неожиданно: сравнение OSCP, CEH, eJPT и PNPT, казалось бы, «попсовая» тема про серты, дала средний retention 3:06. Потому что без маркетинга: стоимость, формат экзамена, что реально спрашивают на собеседованиях в РФ, какая серта открывает двери, а какая висит красивым PDF.
https://codeby.net/threads/sertifikatsiya-po-pentestu-oscp-vs-ceh-vs-ejpt-vs-pnpt-chestnoye-sravneniye-ot-praktika.92610/

И единственная статья из топа, которая уже собирает органику из Яндекса (CTR 7.7%), roadmap в пентест от практика. Без «выучите тысячи инструментов», с привязкой к реальным вопросам на собесах в 2026.
https://codeby.net/threads/kak-stat-pentesterom-s-nulya-roadmap-ot-cheloveka-kotoryi-proshel-etot-put.92680/

Что из этого следует: на форум приходят не за «новостями из мира ИБ», а за материалом, который можно применить в понедельник на работе. Кто-то дочитывает про rootkit до последнего листинга, кто-то разбирается с сертификацией под конкретную вакансию, кто-то ищет, как устроен CVSS 9.8 изнутри.

А вам что из апрельского зашло сильнее, и что применили в работе?

Charming Kitten не взламывает системы — они взламывают людей

Недели переписки в WhatsApp, легитимные PDF, приглашения на реальные конференции. И только потом — ссылка. Ни малвари, ни эксплойтов. Просто украденная сессия и полный доступ к Microsoft 365.

APT42 (Charming Kitten, IRGC-IO) работает иначе:

• Фейковые аккаунты журналистов и организаторов конференций выстраивают доверие неделями
• Фишинговые киты перехватывают TOTP-код в реальном времени — MFA не спасает
• Инфраструктура на Google Sites и Cloudflare Workers не триггерит блокировки

Стандартный SOC заточен под вредоносные вложения и подозрительные домены. APT42 не даёт ни того, ни другого — атака идёт на личный Gmail, где корпоративная защита не работает.

Полный kill chain с маппингом на MITRE ATT&CK и примерами детектирования в SIEM:

https://codeby.net/threads/apt42-sotsial-naya-inzheneriya-kak-irgc-khakery-obkhodyat-mfa-i-kradut-uchetnyye-dannyye-bez-malvari.92779/

Хакер думает, что взломал живой сервер. А он разговаривает с языковой моделью.

Классический Cowrie раскусывается за секунды: захардкоженные команды, одинаковая файловая система. Mirai-ботнеты знают эти паттерны наизусть.

🎯 LLM honeypot меняет правила: языковая модель генерирует уникальный ответ на каждую команду. Атакующий расслабляется и сливает свои TTPs. По данным HoneyGPT (arXiv:2406.01882), подход увеличивает длину сессии и фиксирует тактики, маппящиеся на MITRE ATT&CK.

🔧 В статье — сборка на Linux:
• nftables REDIRECT для приёма трафика на все 65535 портов
• Prompt manager с «личностью» системы и сессионным контекстом
• Rate limiting против API-разорения
• Логирование в JSON для ELK

Локально через Ollama или облако — разбор компромиссов внутри.

📖 Полный разбор с кодом:

https://codeby.net/threads/llm-honeypot-stroim-primanku-na-baze-yazykovoi-modeli-dlya-monitoringa-vsekh-65535-portov.92787/

Атакующие сидели в SD-WAN с 2023 года — и никто не заметил

CISA дала 48 часов на патч CVE-2026-20127 (CVSS 10.0) вместо стандартных 14–21 дней — это паника регулятора.

🔍 Sigma-правила из SigmaHQ здесь бесполезны. Группировка UAT-8616 не загружала малварь — только NETCONF, SSH и легитимные механизмы обновления. Living off the land на сетевой инфраструктуре: каждый шаг неотличим от работы администратора.

Почему стандартные детекты не работают:
• На vManage и vSmart нельзя поставить EDR-агент
• service: sdwan в SigmaHQ отсутствует
• Без форвардинга syslog в SIEM — visibility равен нулю

Атака: rogue-пир в control plane, даунгрейд прошивки до root, зачистка wtmp, lastlog, bash_history.

Разбор с готовыми Sigma-правилами и pipeline-маппингом:

https://codeby.net/threads/sigma-pravila-detektsii-cisco-sd-wan-pishem-detekty-na-cve-2026-20127-i-lateral-movement-cherez-netconf.92785/

CVSS 9.8 — и ты уже строишь эксплойт? Зря

Большинство джуниор-пентестеров читают CVE неправильно: сначала описание, потом скор — и либо паникуют от «CRITICAL», либо пропускают уязвимость без готового эксплойта.

🎯 Реальный анализ начинается не с текста и не с числа:
1. CWE — класс уязвимости, сразу даёт ментальную модель атаки
2. CVSS-вектор — строка, а не скор: нужен ли доступ, нужна ли жертва, выходит ли атака за границы компонента
3. References — есть ли патч или vendor advisory

Follina (CVSS 7.8) имеет Local-вектор — и активно использовалась в ransomware-кампаниях. Log4Shell (CVSS 10.0) — сеть, без аутентификации, без действий пользователя. Разница между ними важнее, чем разница в числах.

⚡ После февраля 2024 года 93% новых CVE в NVD выходят без CVSS и CPE. NVD — стартовая точка, не финишная.

https://codeby.net/threads/analiz-cve-uyazvimostei-ot-strochki-v-nvd-do-rabochei-gipotezy-ekspluatatsii.92794/

Фаззер лёг. Что дальше?

Большинство материалов по эксплуатации памяти заканчиваются на теории стека или запуске чужого PoC с Exploit-DB. Дальше — «ну вы поняли». Полного цикла на русском почти нет.

🔍 Разбор идёт от первого краша до рабочего PoC:

• Триаж — 10 минут в отладчике решают, стоит ли вообще браться. !analyze -v в WinDbg или context в pwndbg сразу покажут класс бага
• Offset — циклический паттерн через msf-pattern_create даёт точное смещение до EIP/RIP без угадывания
• Митигации — checksec до начала работы, иначе ты вслепую: NX, PIE, Canary влияют на весь дальнейший путь

💡 На примерах реальных CVE — включая UAF в win32k, эксплуатировавшийся APT-группами, и CVSS 10.0 в PAN-OS GlobalProtect.

Полный разбор с командами и инструментами:

https://codeby.net/threads/razrabotka-eksploita-dlya-cve-primer-polnogo-tsikla-ot-crash-do-rabochego-poc.92804/

Почему Nmap без kill chain — просто сканер портов

Каждый раз, когда я веду воркшоп для начинающих, первый вопрос всегда один: «Какие инструменты установить?» И каждый раз я отвечаю встречным: «А на каком этапе атаки ты сейчас находишься?»

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

🔍 Большинство гайдов по инструментам хакера строятся как плоский список: вот Nmap, вот Metasploit, вот Wireshark — пользуйтесь. Это примерно как дать человеку скальпель, пилу и зажим и сказать: «Теперь ты хирург». Без понимания последовательности инструменты бесполезны.

В реальном пентесте каждый шаг определяет следующий. Сначала разведка — выясняешь, что вообще живёт на периметре. Затем анализ поверхности атаки — ищешь веб-приложения, открытые сервисы, точки входа. Потом эксплуатация — превращаешь найденную уязвимость в доступ. После — повышение привилегий и перемещение по сети.

⚡ MITRE ATT&CK формализует эту логику. Каждой фазе соответствуют конкретные техники. Запускаешь Nmap — выполняешь Network Service Discovery (T1046). Пробиваешь веб-форму через SQLmap — Exploit Public-Facing Application (T1190). Перебираешь пароли Hydra — Brute Force (T1110). Такой подход делает пентест системным и позволяет писать отчёты, которые заказчик реально может использовать.

🛠 Что конкретно даёт привязка к kill chain? Возьмём типичный вывод nmap -sV -sC -p- 10.10.10.100:

• Порт 22 с OpenSSH 7.9 — проверяем на известные CVE, но скорее всего идём через веб
• MySQL на порту 3306 торчит наружу — потенциальный вектор брутфорса (зачем он вообще открыт на периметре?)
• Apache Tomcat 9.0.30 на 8080 — горячая находка: старые версии часто содержат дыры в менеджере деплоя

Это не просто список открытых портов. Это карта решений: куда идти дальше, что фаззить, что брутить, где искать CVE.

🎯 Опытные пентестеры при работе с десятками хостов комбинируют инструменты: Masscan делает быстрое первичное сканирование всех портов, а Nmap с флагом -sV точечно добивает найденное. NSE-скрипты добавляют глубину: smb-vuln-ms17-010 проверяет EternalBlue, ssl-heartbleed обнаруживает Heartbleed, а http-enum находит стандартные директории веб-серверов за один проход.

Это лишь первая фаза из десяти. Дальше — Burp Suite, SQLmap, Metasploit, Hydra, Hashcat и другие инструменты, каждый из которых привязан к конкретному этапу атаки. Читай полный разбор в статье 👇

https://codeby.net/threads/instrumenty-pentestera-top-10-s-real-nymi-primerami-v-kazhdoi-faze-ataki.92812/

🎯 Ты решаешь CTF — а первый репорт прилетает обратно со статусом Duplicate

Знакомо? Ты находишь реальную уязвимость, но кто-то успел за три часа до тебя. Или хуже — репорт закрывают как out-of-scope, потому что ты полез не на тот домен.

Переход с CTF на bug bounty — это не смена уровня сложности. Это смена дисциплины целиком.

В CTF ты ищешь флаг. В bug bounty ты доказываешь бизнес-импакт. И вот где ломается большинство.

🔍 Пять точек слома

• Scope. В CTF атакуй что хочешь. В bug bounty одна ошибка в scope — бан на платформе. Даже если нашёл реальный баг на CDN-провайдере таргета — это не твоё дело юридически.

• Импакт. Stored XSS, который стреляет только в твой аккаунт — это Self-XSS, severity "None". Тот же Stored XSS, крадущий session cookie администратора — это P2/High с выплатой от $1000. Один класс уязвимости, радикально разная ценность.

• Отчёт. В CTF достаточно вставить flag{...}. В bug bounty — документ на 300–500 слов: summary, steps to reproduce, impact, remediation. Плохой отчёт = закрытый тикет, даже если баг реальный.

• Дубликаты. На публичных программах HackerOne можно отправить 10 валидных репортов и не получить ни одной выплаты — просто потому что все эти IDOR и XSS уже нашли до тебя.

💡 Что переносится, а что нет

Хорошая новость: 60–70% CTF-навыков работают в bug bounty напрямую. Веб-эксплуатация, понимание OWASP Top 10, базовая криптография — всё это актуально.

Плохая новость: оставшиеся 30–40% — именно то, что отделяет оплаченный репорт от закрытого тикета.

Три навыка, которых CTF не даёт:

1. Recon. В CTF тебе дали URL. В bug bounty ты сам ищешь поддомены, скрытые API-эндпоинты, забытые staging-серверы. Опытный хантер тратит на разведку 70% времени.

2. Бизнес-логика. Race condition при покупке, IDOR в чужих счетах, privilege escalation через смену роли — это не технические дыры, а логические. И именно они приносят самые высокие выплаты.

3. Коммуникация. Написание отчёта, обоснование severity, общение с триаж-командой — мягкие навыки, которые CTF не тренирует. А они напрямую влияют на выплату.

🛡️ И ещё один момент, который новички часто игнорируют: легальность. Формальное участие в программе на Standoff 365 или BI.ZONE Bug Bounty защищает юридически — но только в рамках scope. Выход за пределы — это уже ст. 272 УК РФ.

В полной статье — конкретный 12-недельный roadmap с разбивкой по неделям: какие платформы выбрать первыми, как строить recon-пайплайн, как писать первый отчёт. Читай, если хочешь конвертировать CTF-скиллы в реальные выплаты.

https://codeby.net/threads/kak-nachat-bug-bounty-posle-ctf-prakticheskii-roadmap-perekhoda-na-real-nyi-pentest.92814/

🤖 82% хакеров уже используют AI — но большинство делает это неправильно

Bugcrowd опросил более 2 000 исследователей безопасности — и выяснилось, что 82% из них уже встроили AI в рабочий процесс. Звучит как революция. Но дьявол в деталях: большинство использует модели как продвинутый поиск, а не как инструмент ускорения конкретных этапов охоты за уязвимостями.

Разница между «AI помогает» и «AI экономит мне 3–4 часа на каждом таргете» — принципиальная. Второе требует чёткого понимания, куда именно направить модель.

🔍 Где LLM реально работает

Возьмём конкретный пример. Современный SPA генерирует JavaScript-бандлы по 200–500 КБ минифицированного кода. Опытный исследователь тратит на ручной разбор такого файла 2–4 часа. LLM справляется за секунды — если правильно сформулировать задачу.

Ключевой момент: не просите модель «найти уязвимости». Просите извлечь структурированные данные:

• все API-эндпоинты с полными путями
• хардкоженные токены и ключи
• функции, обрабатывающие пользовательский ввод
• скрытые или закомментированные параметры

Вы сами решаете, что тестировать. LLM здесь — высокоскоростной парсер, а не «хакер на удалёнке».

⚡️ Вариация payload: итерации в 3 раза быстрее

Нашли потенциальную SSTI во Flask-приложении, но стандартные пейлоады фильтруются? Описываете модели контекст — фреймворк, WAF, что именно блокируется — и получаете десяток bypass-вариаций за минуту. То же работает для XSS с кастомным WAF, SQL-инъекций и SSRF с ограничением по протоколу.

Это не замена ручного крафта — это ускорение итераций. Вместо того чтобы вспоминать все вариации обхода Jinja2-sandbox, получаете стартовый список и адаптируете под конкретный таргет.

📊 Масштаб проблемы, которую AI помогает решить

По прогнозу FIRST Vulnerability Forecast, в 2026 году ожидается около 60 000 CVE — против 50 000 в 2025-м и 40 000 в 2024-м. Рост — 25% ежегодно. Средний SaaS-таргет сегодня — это 300+ эндпоинтов, микросервисная архитектура и облачные ассеты у нескольких провайдеров. Руками всё это приоритизировать в рамках таймбокса — нереально.

Связка BBOT для сбора данных плюс LLM для ранжирования по вероятной эксплуатабельности закрывает этот разрыв. Инструменты вроде PentestGPT принимают вывод nmap, находки Burp и логи перечисления — и возвращают приоритизированный список следующих шагов с обоснованием. Не автономный пентест, а reasoning layer поверх вашего тулчейна. Думалка, а не делалка.

Где AI точно не справится сам — в логических цепочках из нескольких уязвимостей, в бизнес-контексте таргета и в нестандартных векторах, которые требуют интуиции. Об этом, а также о реальных CVE, найденных с помощью AI, — в полной статье.

https://codeby.net/threads/ai-bug-bounty-gde-llm-real-no-uskoryayet-poisk-uyazvimostei-a-gde-tratit-vashe-vremya.92826/

Пасхальная суббота, взломанная инфраструктура и CVE без патча

31 марта 2026 года сенсоры watchTowr зафиксировали активную эксплуатацию уязвимости, для которой не существовало ни advisory, ни патча. Четырьмя днями позже, в пасхальную субботу, Fortinet выкатила бюллетень. К тому моменту атакующие уже сидели внутри.

🎯 Почему праздники? SOC работает в полсилы, дежурный смотрит в потолок, а окно между компрометацией и детектом растягивается с часов до дней. CEO watchTowr сказал об этом прямо: атакующие давно поняли, что праздники — лучшее время для работы.

CVE-2026-35616 — pre-auth RCE с CVSS 9.8 в FortiClient EMS версий 7.4.5–7.4.6. Не академическая строчка из бюллетеня, а рабочий zero-day, который эксплуатировался до публикации патча.

🔍 Что такое FortiClient EMS и почему это главная цель?

FortiClient EMS — не просто сервер мониторинга. Это центральный management plane всей endpoint-инфраструктуры Fortinet. Через него проходит всё: VPN-политики, compliance-проверки, телеметрия с агентов, интеграция с FortiSandbox и FortiGate.

Компрометация EMS на red team — это джекпот. Атакующий получает:

• управление защитой на всех endpoint'ах
• возможность раскатывать произвольные пакеты через легитимный push-механизм
• доступ к телеметрии с VPN-токенами
• манипуляцию FortiSandbox-интеграцией

По данным Shadowserver, около 2000 экземпляров FortiClient EMS торчат в интернет напрямую — вопреки всем рекомендациям Fortinet. Но кого когда останавливали рекомендации.

⚙️ Почему баг вообще работает?

Вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N — это значит: удалённо, без сложных условий, без учётки, без каких-либо действий со стороны жертвы. Один запрос — один результат.

Корневая причина — отсутствие auth-middleware на конкретных API-эндпоинтах. Механизм аутентификации не взламывается и не обходится через инъекцию — он просто не применяется к определённым запросам. Разработчики добавили новый route, забыли навесить auth-декоратор — классика жанра. Такой паттерн встречается при аудите корпоративных REST API регулярно.

Отдельный момент: в русскоязычных источниках гуляет ошибка — якобы версия 7.4.6 закрывает уязвимость. Это неверно. По NVD, уязвимы обе версии — и 7.4.5, и 7.4.6. Исправление только через обновление до 7.4.7.

🔗 Параллельный вектор

CVE-2026-35616 — не изолированный случай. CVE-2026-21643 — SQL-инъекция в версии 7.4.4 с тем же CVSS 9.8 и идентичным вектором. Два разных класса уязвимостей, один и тот же критический уровень, одна и та же цель. FortiClient EMS явно требует более глубокого security-аудита.

Полная механика эксплуатации — от разведки и API bypass до lateral movement через Fortinet-инфраструктуру — в статье на форуме.

https://codeby.net/threads/cve-2026-35616-ekspluatatsiya-uyazvimosti-forticlient-ems-ot-api-bypass-do-zakhvata-fortinet-infrastruktury.92827/

Почему GPT-4o чуть не уронил базу на реальном пентесте

На внешнем пентесте банковского приложения GPT-4o сгенерировал payload для SQLi с несуществующей функцией MySQL. Запусти я его на проде — база бы легла. На том же проекте Claude за 4 минуты приоритизировал 187 находок Nuclei, на которые раньше уходило полтора часа. Один проект, одна неделя, два полярных опыта.

🤖 Автоматизация пентеста с помощью LLM — это не магия. Это инструментарий с измеримым выигрышем на одних фазах и опасными провалами на других. Разберём, где реально экономятся часы — и где AI пентест гарантированно сломается.

Разведка и приоритизация: здесь LLM работает как интеллектуальный парсер. Скармливаешь вывод nmap -sV — получаешь структурированную таблицу: порт, сервис, версия, релевантные CVE, следующий шаг. Экономия — от 40 минут до 2 часов на хост. Когда 200 находок от Nuclei нужно за час превратить в top-10 для заказчика, модель учитывает контекст: если одновременно открыт порт 3389 и обнаружена уязвимость SMB, она корректно повысит приоритет — это потенциальный lateral movement.

🔥 Генерация отчётов — стабильный выигрыш. Модель берёт сырые логи, группирует находки по severity, добавляет описания и рекомендации. На каждом проекте экономлю 2–3 часа на оформлении. Нужна только финальная вычитка — не переписывание с нуля.

⚠️ Эксплуатация — зона повышенного риска. Сгенерированный payload выглядит синтаксически корректно, но в среде с нестандартным WAF или кастомным обработчиком запросов — не работает. Хуже того: может вызвать непредсказуемое поведение на проде. При пост-эксплуатации модели теряют контекст. На 7–8 шаге эскалации привилегий Claude начинает «забывать» данные с третьего шага. В Active Directory-средах, где цепочка достигает 15–20 шагов, это критично: модель предлагает то, что ты уже делал четыре шага назад.

🛠 Практический нюанс, который большинство гайдов пропускает: нельзя просто вбросить мегабайтный XML в промпт. Модель теряет важные детали в середине. Нужна предобработка: конвертируй вывод nmap в компактный текст — только порт, сервис, версия, скрипт-output. Для Nuclei — только template-id, severity, matched-url. Это не опционально, это условие адекватного ответа модели.

Ещё один момент: данные о целевой инфраструктуре можно обрабатывать локальной моделью через Ollama — ничего не уходит в облако. Для NDA-проектов это не опция, а необходимость.

Полный workflow с промптами, bash-скриптами и разбором конкретных кейсов — в статье.

https://codeby.net/threads/ai-pentest-kak-llm-agenty-uskoryayut-poisk-uyazvimostei-keisy-prompty-i-chestnyye-ogranicheniya.92828/

54 EDR-килера, 35 драйверов, один конвейер — как BYOVD стал индустрией

Представь: ты потратил недели на идеальный имплант — indirect syscalls, обход AMSI, кастомная обфускация. Запускаешь на цели, и через три секунды агент CrowdStrike отправляет алерт в SOC. Payload здесь ни при чём. EDR-драйвер сидит в Ring 0 и видит всё ещё до того, как твой код коснулся ntdll.dll.

🔍 Ответ атакующих прост: спустись на тот же уровень. Именно для этого существует техника BYOVD — Bring Your Own Vulnerable Driver. Берёшь легитимный подписанный драйвер с уязвимостью, грузишь его в ядро через Service Control Manager, получаешь примитив записи в kernel-память — и обнуляешь callback-массивы, которыми EDR отслеживает процессы.

📊 Три года назад это выглядело как экзотика. Сегодня — это конвейер. По данным Cisco Talos и Trend Micro (апрель 2026), ransomware-группировки Qilin и Warlock встроили BYOVD в штатную фазу до шифрования. Они ведут ротируемый пул уязвимых драйверов, мониторят обновления Microsoft Vulnerable Driver Blocklist и переключаются на незаблокированные альтернативы. Их инструментарий заточен на терминацию более 300 endpoint-продуктов до запуска шифрования.

Параллельно исследователи зафиксировали 54 различных EDR-килера, эксплуатирующих 35 подписанных драйверов. Не инциденты — индустрия.

⚙️ Как выглядит цепочка на практике:

1. Атакующий получает локального админа — BYOVD не даёт первоначального доступа, только добивает защиту.
2. Подписанный .sys кладётся в C:\ProgramData или C:\Windows\Temp.
3. Через sc create с типом kernel драйвер уезжает в Ring 0 — подпись валидна, Windows не возражает.
4. Через DeviceIoControl атакующий получает write-примитив в kernel-памяти.
5. Обнуляются адреса в PspCreateProcessNotifyRoutine и соседних массивах — EDR слепнет.
6. Payload разворачивается без помех.

💡 Показательный пример — Dell dbutil_2_3.sys с CVE-2021-21551, CVSS 8.8. Драйвер для обновления BIOS, но без ACL на device object: любой пользователь шлёт IOCTL и получает чтение/запись ядра. Scope=Changed в CVSS-векторе означает буквально: уязвимость ломает всё за пределами компонента, то есть весь kernel. Попала в каталог CISA KEV — и всё равно активно используется, потому что старые версии драйвера продолжают жить на машинах.

🛡 Почему Microsoft Vulnerable Driver Blocklist не спасает? Потому что атакующие мониторят его обновления быстрее, чем он успевает распространиться. Между добавлением драйвера в список и реальным применением политики на конечных точках — окно в недели. А в пуле у атакующих десятки альтернатив.

Детальный разбор примитивов, конкретных IOCTL-кодов и методов детектирования — в полной статье на форуме.

https://codeby.net/threads/byovd-ataka-obkhod-edr-anatomiya-bring-your-own-vulnerable-driver-v-2026-godu.92840/

🔑 22 минуты от первого LDAP-запроса до хеша krbtgt — это не рекорд CTF, это реальный корпоративный пентест

Звучит как преувеличение, но именно столько времени может занять путь от учётки рядового пользователя до полного контроля над доменом. Не потому что кто-то поленился поставить патч. А потому что Active Directory изначально проектировалась для удобства администрирования, а не для противодействия атакующему с валидным доменным аккаунтом.

Один забытый SPN на сервисной учётке с паролем Summer2024! — и ты уже делаешь Kerberoasting. Одна кривая ACL, выданная «на время миграции» три года назад — и BloodHound рисует прямую линию к KRBTGT. Это не экзотика. Это типичная корпоративная инфраструктура.

🗺 Откуда берётся такой результат?

Всё начинается с разведки. Имея только учётку уровня Domain Users, атакующий через стандартные LDAP-запросы получает доступ к колоссальному объёму данных:

• Полный список пользователей и их атрибутов
• Все группы и вложенные членства
• Компьютеры с версиями ОС
• Объекты GPO и ACL на OU
• Доверительные отношения и FSMO-роли

Это не уязвимость — это штатное поведение LDAP в Active Directory. Microsoft так задумала. И именно поэтому атакующий с любым валидным аккаунтом чувствует себя в домене как дома.

🔍 Отдельная история — поле description в атрибутах пользователей. Администраторы записывают туда пароли чаще, чем хотелось бы верить. А ещё в SYSVOL нередко лежат скрипты групповых политик с паролями в открытом виде. Буквально в открытом.

После базовой разведки в дело идёт BloodHound. Он собирает сессии, членства в группах, ACL и делегирование — и строит граф атакующих путей. Типичная находка на реальных проектах: учётная запись мониторинговой службы состоит в группе IT-Admins, у которой есть GenericAll на OU с доменными администраторами. Цепочка строилась годами, по кирпичику, «временно».

⚡️ Дальше — быстрее, чем кажется

Kerberoasting → пароль сервисной учётки → lateral movement → Pass-the-Hash → DCSync → Golden Ticket. Каждый шаг логичен и предсказуем, если знать карту. А карта — это понимание того, как AD обрабатывает Kerberos-тикеты, как работают ACL-права вроде WriteDACL или GenericWrite, и почему делегирование без ограничений — это фактически «ключ от всех дверей».

Полный разбор каждого этапа — от первого LDAP-запроса до DCSync, Golden Ticket и атак на AD CS (ESC1–ESC13) — в статье.

https://codeby.net/threads/pentest-active-directory-polnyi-gaid-ot-razvedki-do-domain-admin-instrumenty-tekhniki-laboratornaya-sreda.92847/

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

Это не метафора. По данным Mandiant M-Trends 2026, между первым звонком мошенника и передачей доступа следующей группировке проходит в среднем 22 секунды. Не минуты — секунды.

📞 И пока компании инвестируют миллионы в файрволы и EDR-системы, атакующие просто звонят на хелпдеск и представляются сотрудниками. Scattered Spider — одна из самых результативных группировок последних лет — поднималась от первого звонка до доменного администратора менее чем за 40 минут. Без единой строки вредоносного кода.

Голосовой фишинг впервые обогнал email как главный вектор начального доступа. Классические фишинговые письма упали до 6% подтверждённых случаев первичного проникновения, а вишинг вырос до 11% — а в облачных инцидентах и вовсе до 23%. Тренд очевиден: технические барьеры растут, и атака смещается туда, где барьеров нет — в человека.

🎯 Почему это работает? Не потому что люди глупы. Атаки вписываются в нормальные рабочие процессы: сброс пароля, согласование платежа, обновление ПО. Каждое действие выглядит рутинным — и именно поэтому срабатывает. По данным Unit 42, 36% всех инцидентов в 2025 году начались с социальной инженерии.

Методы давно вышли за рамки «нигерийских писем». Вот как выглядит карта актуальных атак:

• Вишинг — звонок на хелпдеск, убедительная легенда, сброс MFA-токена за три минуты
• Deepfake-имперсонация — голос или видео «руководителя», который просит срочно перевести деньги
• ClickFix — браузер показывает «ошибку» и предлагает вставить команду в терминал для «исправления»
• QR-фишинг — через linked devices в Signal или Telegram, применяется APT-группировками
• Обход KYC — дипфейки и инъекции видеопотока для обмана систем идентификации

🔐 Что с этим делать? Несколько принципов, которые реально работают:

1. Верификация по второму каналу. Позвонил «руководитель» с просьбой срочно что-то сделать — перезвони ему сам по номеру из корпоративной базы.
2. Нулевое доверие к срочности. «Срочно», «немедленно», «иначе всё рухнет» — классические триггеры давления. Именно в этот момент нужно замедлиться.
3. Аппаратные ключи вместо OTP-кодов. Их нельзя «сбросить» по телефону — физический токен закрывает главный сценарий вишинга.

⚡️ Парадокс 2026 года: чем лучше технические средства защиты, тем ценнее становится атака на человека. Инвестиции в осведомлённость сотрудников — уже не «мягкий» навык, а критическая инфраструктура безопасности.

Полный разбор всех методов, техник APT-групп и практических мер защиты — в статье.

https://codeby.net/threads/sotsial-naya-inzheneriya-2026-polnaya-karta-metodov-atak-i-zashchity.92848/

🎯 Responder собирает хеши в вашей сети прямо сейчас

На каждом втором внутреннем пентесте — одна и та же картина. LLMNR включён по умолчанию, LAPS не развёрнут или покрывает только часть машин, расширенный аудит Kerberos не настроен. Итог: атакующий перехватывает хеши, вытягивает пароль локального администратора и движется по сети, не оставляя следов — всё это за первые два часа после попадания в периметр.

🔍 Разберём, почему это работает.

Когда пользователь допускает опечатку в UNC-пути — например, пишет \\DCC01 вместо \\DC01 — DNS не может разрешить несуществующее имя. Windows автоматически отправляет LLMNR-запрос мультикастом в локальный сегмент. Любой хост в этом сегменте может ответить — и ни один из этих протоколов не проверяет подлинность ответа. Атакующий с запущенным Responder говорит: «Это я, подключайся». Жертва шлёт NTLM-хеш — и NetNTLMv2 уже в руках атакующего.

Дальше — дело техники. Одна команда в Hashcat:

hashcat -m 5600 hashes.txt wordlist.txt

Модуль 5600 — это NetNTLMv2. Слабый пароль типа «Password1» ломается за секунды. Пользователь исправляет опечатку и работает дальше, не подозревая, что хеш уже утёк.

⚡️ Лично я ни разу не видел сеть, где Responder не собрал бы хотя бы пару хешей за первые 20 минут — если LLMNR не отключён.

Проверить состояние прямо сейчас можно одной командой:

Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast -ErrorAction SilentlyContinue

Если ключ EnableMulticast отсутствует или равен 1 — LLMNR активен и сеть открыта. Отключается через GPO: Computer Configuration > Administrative Templates > Network > DNS Client, параметр «Turn OFF Multicast Name Resolution» — в «Enabled». Применяете gpupdate /force — и вектор закрыт.

🛡 Отдельная история — LAPS. Без него один скомпрометированный хост открывает lateral movement по всей сети: один хеш локального администратора работает везде, где пароль не менялся индивидуально. Это классический Pass-the-Hash, и он до сих пор встречается в большинстве корпоративных сетей.

Три вещи, которые атакующий проверяет в первую очередь:

• LLMNR/NBT-NS — включены ли широковещательные протоколы
• LAPS — покрывает ли все машины или только рабочие станции
• Логирование — видит ли blue team атаки или только стандартные события

Хорошая новость: все три проблемы закрываются штатными средствами Windows, без бюджета на дорогие решения. Плохая: большинство организаций не проверяли это никогда.

📖 Полный разбор — с командами, GPO-настройками и детектированием — в статье.

https://codeby.net/threads/audit-active-directory-bezopasnost-laps-llmnr-i-logirovaniya-za-odin-rabochii-den.92854/