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

Классический 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/

🎣 Как пентестеры находят пароли раньше, чем запускают первый эксплойт

На каждом втором внутреннем пентесте учётные данные обнаруживаются ещё до первой активной атаки. Не потому что заказчики халтурят с безопасностью — просто в плоской корпоративной сети достаточно перевести интерфейс в режим прослушивания, чтобы увидеть FTP-пароли, NTLM-хеши и многое другое в открытом виде.

🔍 Первые 30 минут внутреннего пентеста обычно уходят на пассивную разведку. Запускаешь tcpdump, пишешь трафик в pcap-файл, открываешь в Wireshark — и уже знаешь структуру сети лучше, чем из любого скана. Видно всё: какие VLAN есть, где принтеры с веб-интерфейсом на голом HTTP, кто ходит на внутренний портал без шифрования, какие broadcast-протоколы выдают имена хостов.

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

⚡️ Почему ARP так легко атаковать? Протокол не имеет встроенной аутентификации. Любой хост может отправить gratuitous ARP-ответ и заявить: «MAC-адрес шлюза — это я». Жертва обновит ARP-кеш и начнёт слать пакеты атакующему. Коммутатор по CAM-таблице доставит их куда надо. Весь трафик теперь проходит через нас — читаем, записываем, при необходимости модифицируем, пересылаем дальше. Жертва ничего не замечает.

🛠 Три инструмента покрывают большинство сценариев:

• tcpdump — захват на удалённых машинах без GUI, первый выбор при SSH-доступе к серверу
• Wireshark — визуальный разбор дампов, мощные фильтры, анализ сессий
• Ettercap — ARP spoofing в лабораторных условиях, перехват и модификация трафика на лету

Важный момент, который часто упускают: перед ARP-атакой обязательно включи IP forwarding командой echo 1 > /proc/sys/net/ipv4/ip_forward. Без этого трафик жертвы просто утонет на твоём интерфейсе — соединение оборвётся, жертва всё поймёт.

Отдельно стоит сказать про лабораторную среду. ARP spoofing в продакшн-сети без письменного разрешения — уголовная статья. «Я просто учился» суд не убедит. Поднимите три VM в VirtualBox с Internal Network: атакующий, жертва, шлюз. Изолированный L2-сегмент отлично имитирует плоскую корпоративную сеть, и никто не пострадает.

💡 Контринтуитивный вывод: шифрование не спасает само по себе. MITM-позиция открывает возможность для SSL stripping, подмены сертификатов и атак на протоколы согласования. HTTPS без HSTS и certificate pinning — не такая уж надёжная защита, как кажется.

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

https://codeby.net/threads/sniffing-trafika-i-mitm-ataki-wireshark-tcpdump-i-ettercap-v-real-nykh-stsenariyakh.92857/

🐧 Linux EDR не видит тебя — если знать, куда смотреть

На Windows обход защиты давно каталогизирован: ntdll-хуки, ETW-провайдеры, kernel callbacks. На Linux всё иначе. Каждый EDR-агент использует свой источник телеметрии, и у каждого — свои слепые зоны.

По данным CrowdStrike 2025 Global Threat Report, 82% детектов приходятся на malware-free активность — credential theft, living-off-the-land, identity-based атаки. Именно это Linux EDR отслеживает хуже всего. А готовые bypass-инструменты для Linux уже продаются на подпольных форумах от $300.

🔍 Что именно перехватывает агент

Телеметрия на Linux собирается тремя способами:

• auditd — старый и совместимый, но работает как очередь. Если на хосте уже крутится compliance-система, EDR конкурирует за тот же поток событий. Часть syscall'ов просто не попадает в телеметрию.

• eBPF-сенсоры — современный подход. Агент цепляет kprobes и tracepoints к kernel-функциям. Но для работы BTF и CO-RE нужен kernel, собранный с CONFIG_DEBUG_INFO_BTF=y. На RHEL 7 и CentOS 7 этого нет — и там eBPF-сенсор попросту не запустится.

• Kernel-модули — максимальная видимость, но жёсткая привязка к версии ядра и дистрибутиву.

Первый шаг на любом engagement'е — понять, какой из трёх механизмов используется. От этого зависит всё остальное.

⚙️ Прямые syscall'ы: обходим glibc-хуки

Большинство программ вызывают syscall'ы через обёртки glibc. Часть EDR-агентов ставит uprobes именно на эти обёртки или использует LD_PRELOAD. Если вызвать syscall напрямую через asm volatile("syscall"), минуя __libc_execve, — такой агент ничего не увидит.

На Linux номера syscall'ов стабильны между версиями ядра одной архитектуры. Таблица лежит в arch/x86/entry/syscalls/syscall_64.tbl и практически не меняется. Никакой SysWhispers не нужен.

Что это не обходит: kprobes на kernel-стороне, auditd с правилом -a always,exit -F arch=b64 -S execve, seccomp-BPF фильтры. Они работают на уровне входа в ядро, до любого dispatch'а.

🕳 io_uring: слепая зона другого масштаба

io_uring — асинхронный интерфейс ввода-вывода, появившийся в ядре 5.1. Операции выполняются в ядре через разделяемые кольцевые буферы, без традиционных syscall'ов на каждую операцию. Большинство eBPF-сенсоров и auditd просто не видят эти операции — они не проходят через стандартные точки перехвата.

Исследователи из ARMO показали, что через io_uring можно открывать файлы, читать данные и устанавливать соединения, не генерируя ни одного события в auditd. Falco и Tracee на момент публикации исследования не детектировали этот вектор.

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

https://codeby.net/threads/obkhod-edr-linux-syscall-evasion-io_uring-i-ebpf-ataki-dlya-pentesterov.92859/

🚨 47 алертов, тимлид ушёл, а ты один

Именно так выглядит первая смена в SOC для большинства. 23:00, три монитора с дашбордами Splunk, очередь из алертов и полное ощущение, что ты не туда попал. Через три месяца после такого старта можно триажить 80+ алертов за смену и писать корреляционные правила. Вопрос только в том, какой маршрут выбрать.

📊 Начнём с масштаба задачи. По данным Ponemon Institute, средний SOC получает около 10 000 алертов в сутки. Большинство из них — ложные срабатывания: легитимный сканер, похожий на разведку, или пользователь, трижды промахнувшийся по паролю. Работа L1-аналитика — не знать всё на свете, а выстроить дисциплинированный процесс: открыл алерт, проверил контекст, принял решение. Всё.

Карьера в SOC строится по трём уровням, и понимание этой иерархии определяет твой учебный план.

L1 — триаж и первая линия. Разгребаешь поток из SIEM, отделяешь реальные угрозы от шума, эскалируешь наверх. Срок на позиции — от полугода до двух лет. Именно здесь появляется «чутьё на аномалию» — оно не читается из книг, а приходит после пятисотого алерта, когда глаз сам цепляется за нетипичный паттерн.

L2 — расследование инцидентов. Строишь таймлайн атаки, ищешь IoC по всей инфраструктуре, маппишь артефакты на MITRE ATT&CK. Начинается форензика — дампы памяти, артефакты файловой системы, корреляция логов.

L3 — threat hunting. Проактивный поиск угроз, которые ещё не вызвали ни одного алерта. Формулируешь гипотезу и проверяешь её по телеметрии.

🔧 Три области, без которых не выжить на первом дежурстве:

• Сети. TCP/IP, DNS, HTTP/HTTPS. Если видишь трафик на порт 4444 — насторожись: это классический дефолт Metasploit, и да, атакующие до сих пор забывают его менять.
• Windows-логи. Шесть Event ID, которые покрывают 80% типичных инцидентов: 4624 (вход), 4625 (неудача), 4672 (привилегии), 4688 (процесс), 4720 (новый аккаунт), 7045 (сервис). Первые две недели держи их на стикере у монитора — все так делают.
• Linux. /var/log/auth.log, journalctl, команды ss -tlnp и ps aux — ежедневный минимум для проверки соединений и процессов.

💡 Самый контринтуитивный совет для новичка: не пытайся выучить всё до первого дежурства. Паралич от объёма материала — реальная проблема. Лучше потрать 2–3 часа на Wireshark: захвати трафик между двумя виртуалками, разбери TCP-хендшейк и DNS-запрос. Это даст больше, чем неделя чтения RFC.

Полный маршрут на первые 90 дней — инструменты, SIEM, план по неделям и то, что делать при P1-инциденте в одиночку — в статье на форуме 👇

https://codeby.net/threads/analitik-soc-s-chego-nachat-instrumenty-navyki-i-plan-vyzhivaniya-v-pervyye-90-dnei.92864/