⚔️ WAF в режиме мониторинга — это просто дорогой логгер

Разворачиваешь пентест внешнего периметра — и снова видишь знакомую тройку: PT Application Firewall перед вебом, UserGate или Континент на границе сети. Маркетинговые даташиты обещают «полную защиту от OWASP Top 10». Реальность — другая.

🔍 Первое, что нужно понять: WAF и NGFW — принципиально разные инструменты, и обходятся они по-разному. WAF — прокси уровня приложений (L7), который разбирает HTTP-запрос на атомы: заголовки, URI, параметры, тело. NGFW работает на уровнях L3–L7, но «широко», а не «глубоко». Для атакующего это прямая развилка: WAF обманывают через семантику HTTP — мутируют payload, играют с кодировками, эксплуатируют парсерные дифференциалы. NGFW обходят туннелированием через разрешённые протоколы или фрагментацией пакетов. Смешивать подходы — терять время и плодить лишние следы в логах.

🏗 PT Application Firewall разворачивается как обратный прокси: терминирует TLS, полностью разбирает запрос, нормализует его и только потом отправляет на бэкенд. Это означает, что часть техник обхода, построенных на разнице между тем, как WAF и бэкенд по-разному читают одни и те же байты, здесь работает иначе. Сигнатурный движок стабильно ловит классические SQLi и XSS в стандартных параметрах. Но атаки в глубоко вложенных JSON/XML-структурах или с нестандартным Content-Type — уже сложнее.

Реально сильная сторона PT AF — виртуальный патчинг: при интеграции с PT Application Inspector продукт закрывает конкретные уязвимости без изменения кода приложения. Ни один NGFW этого не умеет.

Слепое пятно — атаки на бизнес-логику: IDOR, mass assignment, race conditions. Сигнатурами они не ловятся в принципе. Поведенческий ML-модуль теоретически может заметить аномалию, но только после обучения на нормальном трафике. На практике его нередко отключают — команда ИБ устаёт разгребать false positives.

🔒 UserGate NGFW — не WAF. Его задача — контроль трафика между сегментами и защита периметра. DPI-модуль идентифицирует приложения по сигнатурам и применяет политики. Для инспекции зашифрованного трафика используется TLS-инспекция (SSL bump) с подменой сертификата. Стандартный подход, но с важным следствием: его обычно настраивают выборочно, и в зонах без инспекции туннелирование через разрешённые протоколы работает предсказуемо.

💡 И самый важный практический вывод, который подтверждает опыт аудитов в финансовом и госсекторе: значительная часть российских WAF работает в режиме мониторинга, а не блокировки. Причина банальна — тюнинг политик под конкретное приложение требует ресурсов, которых у команды ИБ просто нет. Полный разбор архитектуры всех трёх продуктов, конкретные техники обхода и выводы по Континент — в статье на форуме.

https://codeby.net/threads/rossiiskiye-waf-i-ngfw-sravneniye-pt-af-usergate-i-kontinent-glazami-pentestera.92901/

🛠 Kali из коробки — это заготовка, а не рабочий инструмент

Звучит банально, но именно это понимаешь после первого реального проекта. Более 600 предустановленных утилит — а на живом пентесте реально нужны от силы два десятка. Остальное — балласт, который занимает место и создаёт иллюзию готовности.

Первые полчаса после установки уходят не на «взлом», а на превращение дистрибутива в нормальное рабочее место. Дефолтный shell без алиасов, пустая домашняя директория, никакой структуры проектов. Если ты работаешь в VM и не настроил гостевые дополнения до обновления системы — после apt full-upgrade получишь сюрприз: новое ядро сломает интеграцию с VirtualBox, и ты окажешься в консоли с разрешением 800x600 без буфера обмена.

🔄 Правильная последовательность спасает от этого:

1. Сначала ставишь гостевые дополнения (virtualbox-guest-utils или open-vm-tools-desktop для VMware)
2. Проверяешь, что экран, буфер обмена и drag-and-drop работают
3. Делаешь snapshot в гипервизоре
4. И только потом запускаешь sudo apt full-upgrade

Откат к snapshot — секунды вместо переустановки. Это не паранойя, это гигиена.

⚖️ Отдельный вопрос — Kali или Parrot? Большинство гайдов говорят «ставь Kali» и не объясняют почему. Разница есть, и она практическая. Parrot в режиме ожидания потребляет на 300–400 МБ RAM меньше — ощутимо, если у тебя 4 ГБ и параллельно крутятся Burp Suite с браузером. Плюс встроенный AnonSurf для анонимизации трафика без дополнительных настроек.

Но если ты учишься по TryHackMe, Hack The Box или любому платному курсу — почти все гайды написаны под Kali. Адаптировать команды под Parrot придётся вручную, и на старте это лишнее трение. Оба дистрибутива — Debian с набором пакетов, и всё, что работает на одном, работает на другом. Выбор — вопрос комфорта, а не возможностей.

🔐 Ещё один момент, который игнорируют новички: не работай постоянно из-под root. Случайный rm -rf в привилегированной сессии — и результаты сканирования исчезли. Создай отдельного пользователя командой sudo useradd -m -s /bin/zsh pentester, добавь в группу sudo и работай из-под него. Это базовая гигиена, которая однажды спасёт важные данные.

Про инструменты: не ставь kali-linux-large сразу — это ~15 ГБ дополнительного места. Начни с точечных метапакетов под задачу: kali-tools-web для веба, kali-tools-passwords для брутфорса, kali-tools-information-gathering для разведки. Полный список — apt-cache search kali-tools.

📖 Полный чеклист настройки, кастомизация shell и организация структуры проектов — в статье на форуме.

https://codeby.net/threads/nastroika-kali-linux-dlya-pentesta-kastomizatsiya-instrumenty-i-optimizatsiya-okruzheniya.92927/

В апреле команда HackerLab ездила на международный Cyber Range в Астану. Формат боевой: Active Directory, Red Team, Bug Bounty по OWASP Top 10, цепочки раскрутки уязвимостей на живой инфраструктуре.

После первого дня стояли в топ-10.

На второй день в 16:00 тиммейт нашёл критичный Risk во внутрянке, сдал отчёт — прилетело +4000 баллов. Команда вышла на первое место. Все вокруг уставились в рейтинг.

17:00 — стоп. Первое место.

17:30 — финальная проверка отчётов. Первое место.

Потом команда из Узбекистана сообщила организаторам, что их отчёт на 5000 баллов пролежал необработанным с первого дня. Орги подтвердили и приняли — уже после стопа. Первое место стало вторым.

Решение осталось за организаторами. Второе место на международном турнире — это второе место на международном турнире.

Приз — 500 000 тенге.

Полный отчёт с техническими деталями: что искали, как делили работу внутри команды, что стоит взять в практику — на codeby.net: https://codeby.net/threads/aitu-ctf-cyber-range-2026.92931/

Почему скорборд падает на 40-й минуте — и как это не допустить

🔥 300+ участников, динамический скоринг в CTFd, и база данных — SQLite по дефолту. Именно так выглядит рецепт катастрофы на реальном Jeopardy. Скорборд лёг через сорок минут после старта: динамический скоринг пересчитывал стоимость тасков при каждом сабмите, а SQLite просто не справился с нагрузкой. Итог — перезапуск, миграция на PostgreSQL, потеря двух раундов и час разборок в чате. Одна конфигурационная ошибка, которую тест за 10 минут поймал бы ещё до старта.

Организация CTF — это инженерная задача, а не «закинул таски на платформу и открыл регистрацию». Каждая деталь имеет значение.

⚙️ Три формата — три разных уровня боли

Jeopardy — самый доступный старт. Команды решают независимые таски из категорий web, crypto, pwn, reverse, forensics и других, сдают флаги вида flag{s0m3_t3xt} и получают очки. Масштабируется от 10 до 1000+ команд без изменения инфраструктуры. Главная трудность здесь — не сервера, а сами задания. Каждый таск нужно проверить на unintended-решения: один реальный кейс — таск по crypto за 500 очков решался командой strings на бинарнике, потому что автор забыл убрать дебаг-вывод. Второй автор нашёл бы это за минуту.

Attack-Defense — совсем другая история. Каждая команда получает идентичный уязвимый сервер (vulnbox) и одновременно атакует противников и защищает себя. Игра идёт по тикам — раундам длиной 1-5 минут. Отошёл на обед — потерял 20 тиков. Классическая ловушка: команда блокирует все входящие соединения через iptables -P INPUT DROP и радуется, что её «не сломают». Через тик gameserver фиксирует DOWN — и SLA-очки улетают в ноль. Нельзя просто выключить сервис и стать неуязвимым: в этом и есть главный баланс формата.

🛡 Скоринг: где ошибаются чаще всего

Статический скоринг прост: 100 очков за easy, 500 за hard. Но если организатор ошибся в оценке сложности и «хард» решили 80% команд — баланс турнирной таблицы рушится. Динамический скоринг решает эту проблему: чем больше команд решило таск, тем меньше он стоит. Но именно здесь живёт та самая история с SQLite — при большом потоке сабмитов база данных просто не выдерживает. Мигрируй на PostgreSQL до старта, а не во время.

💡 Хочешь разобрать полную механику скоринга, античит и выбор инфраструктуры — читай статью целиком.

https://codeby.net/threads/organizatsiya-ctf-sorevnovanii-formaty-skoring-i-antichit-na-praktike.92940/

🔥 Как я заблокировал релиз на два дня и чему это научило о DevSecOps

Однажды я добавил SAST-сканер в продовый пайплайн без настройки порогов. Через час в Slack прилетело сорок уведомлений: мёрж заблокирован, двести находок, из которых сто восемьдесят — false positives. Релиз сдвинулся на два дня, а слово «безопасность» стало ругательным в командном чате на три недели.

Это классический антипаттерн DevSecOps: взять инструмент, включить на максимум, сломать процесс. Но проблема глубже, чем просто «неправильно настроили».

⚠️ CI/CD-пайплайн — это вектор атаки

Большинство статей о shift left security останавливаются на тезисе «лови баги раньше». Но за ним прячется неочевидная вещь: незащищённый пайплайн — полноценный инструмент для атаки на всю организацию.

В матрице MITRE ATT&CK задокументированы конкретные техники против CI/CD:
• Poisoned Pipeline Execution — внедрение кода через конфиг пайплайна
• T1195.001 — компрометация зависимостей и инструментов сборки
• T1552.001 — секреты, забытые прямо в конфигах

SolarWinds в 2020-м — не абстрактный кейс. Вредоносный код внедрили в процесс сборки, и он разлетелся через легитимное обновление на тысячи организаций. Это происходит, когда безопасность в пайплайне — просто галочка, а не процесс.

🛠 Минимальный стек, который реально работает

Не нужно прикручивать десять сканеров за один спринт. Четыре инструмента закрывают четыре разных вектора:

1. Gitleaks — ловит захардкоженные секреты до того, как они осядут в git-истории навсегда
2. Semgrep — SAST с читаемыми правилами, стартуй с p/owasp-top-ten, не с полным аудитом
3. Trivy — CVE в зависимостях и контейнерах, работает с package-lock.json, requirements.txt, Dockerfile
4. OWASP ZAP — DAST на staging, ловит то, что видно только в рантайме

Ни один из них не заменяет остальные. Именно поэтому — стек, а не один сканер.

💡 Главный урок после трёх провалов

Начинай с allow_failure: true. Везде. Сканеры показывают находки, но не блокируют мёрж. Разработчики видят результаты, привыкают к инструменту, доверие не рушится. Убираешь эту настройку в первый день — получаешь бунт. Блокирующие правила вводи постепенно, начиная только с severity: ERROR и только после того, как команда перестала воспринимать сканер как врага.

Ещё один контринтуитивный момент: секрет, попавший в git-историю, остаётся там даже после удаления файла. git log помнит всё. Поэтому Gitleaks запускают с флагом GIT_DEPTH: 0 — иначе shallow clone просто пропустит старые коммиты со всеми их сюрпризами.

Полный roadmap с конфигами для GitLab CI и GitHub Actions, примерами правил Semgrep и разбором реальных кейсов — в статье на форуме.

https://codeby.net/threads/devsecops-vnedreniye-s-nulya-kak-vstroit-bezopasnost-v-ci-cd-i-ne-slomat-razrabotku.92943/

APT28 готовит эксплойт за две недели до патча: как устроена кампания PRISMEX

12 января 2026 года группировка APT28 регистрирует WebDAV-домены. 26 января Microsoft выпускает внеочередной патч для CVE-2026-21509. 28 января — фишинговая рассылка уже в разгаре. Между подготовкой инфраструктуры и массовой атакой — 16 дней. Между патчем и атакой — 48 часов.

🎯 Масштаб впечатляет: 29 писем, девять стран, 72 часа. Но главное — письма шли не с поддельных доменов, а с реально скомпрометированных государственных почтовых ящиков Румынии, Боливии и Украины. Цели — министерства обороны, логистические хабы, дипломатические миссии. В Польше били по железнодорожной логистике, в Словакии и Чехии — по цепочкам поставок боеприпасов.

Что делает эту кампанию особенной технически?

⚙️ Цепочка заражения полностью автоматическая. Жертва открывает RTF-документ, и дальше всё происходит без единого дополнительного клика. Через OLE-механизм инстанциируется COM-объект Shell.Explorer.2, который инициирует соединение к WebDAV-серверу атакующего и подтягивает LNK-файл. Никаких макросов. Protected View обходится. Стандартные OLE-предупреждения — тоже.

Загруженный LNK эксплуатирует вторую уязвимость — CVE-2026-21513 в MSHTML Framework (CVSS 8.8). Через вложенные iframe и манипуляцию trust boundaries вызывается ShellExecuteExW за пределами браузерного sandbox. Итог: открыл документ → полная компрометация.

🔬 Дальше — ещё интереснее. Малварный набор PRISMEX использует три приёма, которые серьёзно усложняют детектирование:

• Стеганография в PNG — payload прячется внутри обычных картинок. Антивирус видит легитимное изображение, а внутри — код.
• Fileless-исполнение — вредоносный код живёт только в памяти, на диск ничего не пишется.
• Облачный C2 через Filen.io — управляющий трафик маскируется под обычное обращение к легитимному облачному сервису.

Отдельная деталь для аналитиков: серверная фильтрация. Если вы пытаетесь скачать образец из нецелевой страны или с неподходящим User-Agent, сервер отдаёт чистый ответ. Классический sandbox-evasion на уровне инфраструктуры.

Почему это важно для SOC прямо сейчас? Потому что между раскрытием CVE-2026-21513 и выходом патча прошло 11 дней подтверждённой zero-day-эксплуатации в дикой среде. А CERT-UA зафиксировал атаки на более чем 60 почтовых аккаунтов центральных органов Украины через ту же связку.

В полной статье — конкретные YARA-правила, Sigma-запросы, IoC и detection-логика, которую можно внедрить в SIEM уже сегодня. Разобраны оба варианта цепочки (MiniDoor и Covenant Grunt), COM hijacking, техники по MITRE ATT&CK и рекомендации по hardening.

Читайте полный разбор на форуме.

https://codeby.net/threads/apt28-kampaniya-prismex-analiz-tsepochki-zarazheniya-oblachnyi-c2-i-detection-dlya-soc.92951/

$13,7 млн испарились за ночь: что взлом Grinex говорит о реальной безопасности криптобирж

15 апреля 2026 года криптобиржа Grinex встала колом. Около 1 млрд рублей вывели в неизвестном направлении. Площадка публично обвинила «западные спецслужбы» — и не предоставила ни единого индикатора компрометации. Ни хеша, ни IP, ни CVE. Ничего.

Для любого Threat Intelligence-аналитика это красный флаг: громкая атрибуция без технических деталей означает, что реальный вектор компрометации либо не исследовали, либо результаты слишком неудобны.

🔍 Контекст делает картину ещё интереснее. Grinex — фактический наследник санкционированной Garantex. После того как OFAC заморозил активы Garantex в марте 2025-го, средства клиентов перетекли на Grinex через рублёвый стейблкоин A7A5, который обработал десятки миллиардов долларов за год. Санкционное давление нарастало волнами — OFAC, Великобритания, ЕС, блокировка на Uniswap. И на этом фоне — кибератака. Совпадение? Возможно. Но паттерн показательный.

⚙️ Что мы знаем о вероятных техниках? Если разложить атаку по MITRE ATT&CK, типовая kill chain для криптобирж в 2026 году выглядит так:

• T1078 Valid Accounts — компрометация ключей подписи транзакций через фишинг оператора или инсайдера. По статистике TRM Labs, это главный вектор финансовых киберинцидентов прямо сейчас
• T1190 Exploit Public-Facing Application — API биржи, особенно если кодовую базу унаследовали от предшественника без полного аудита
• T1657 Financial Theft — прямая кража с hot wallet, не ransomware, не шифрование, а вывод средств on-chain

Обратите внимание: Grinex не опубликовала postmortem. А T1070 (очистка логов) — стандартная практика атакующих, которая объясняет, почему IOC так и не появились.

📊 И это лишь один инцидент на фоне масштабной картины. За 2025 год в открытый доступ попали более 767 млн записей персональных данных российских пользователей. Q1 2026 продолжил тренд — десятки миллионов строк на андеграундных форумах и в Telegram. Оборотные штрафы за утечки перестали быть теорией, а supply chain атаки начали бить по самим инструментам защиты.

Что с этим делать SOC-аналитику? Как минимум — мониторить аномальные вызовы к signing-сервисам, отслеживать нетипичные объёмы транзакций с hot wallet и проверять целостность CI/CD-пайплайнов.

В полной статье — детальный маппинг TTPs по MITRE ATT&CK, хронология от Garantex до Grinex и готовый detection-чеклист для SOC. Разбираем всё.

https://codeby.net/threads/utechka-dannykh-kriptobirzhi-v-rossii-2026-vzlom-grinex-na-13-7-mln-razbor-ttps-i-detection-cheklist-dlya-soc.92947/

🔓 Патч закрыл RCE, но оставил кражу хешей: как CVE-2026-32202 обманывает Windows Shell

Представьте: вы добросовестно накатили февральский Patch Tuesday, закрыли активно эксплуатируемую zero-day с CVSS 8.8, проверили — код через вредоносный .lnk больше не выполняется. Всё хорошо? Нет. Ваша машина по-прежнему отправляет Net-NTLMv2-хеш на сервер атакующего. Просто потому, что пользователь открыл папку с ярлыком.

Именно это обнаружили исследователи Akamai, тестируя фикс для CVE-2026-21510. Патч убрал обход SmartScreen и заблокировал RCE, но не тронул механизм аутентификации. Так появился CVE-2026-32202 — zero-click уязвимость Windows Shell, которую CISA 29 апреля добавила в каталог Known Exploited Vulnerabilities с дедлайном до 12 мая.

⚙️ Как это работает

Когда Windows Explorer открывает папку, он автоматически парсит все .lnk-файлы внутри — чтобы отрисовать иконки и метаданные. Если ярлык указывает на UNC-путь вроде \\attacker.com\share\payload.cpl, Shell пытается его резолвить. А резолвинг UNC-пути — это SMB-соединение с удалённым сервером и отправка NTLM-хендшейка.

Ключевой момент: всё это происходит до проверок SmartScreen и Mark of the Web. Исследователи называют это «gap between path resolution and trust verification» — окно между разбором пути и проверкой доверия. Функция ShellExecuteExW резолвит путь и инициирует соединение раньше, чем любые защитные механизмы успевают вмешаться.

Итого — цепочка атаки:

• Атакующий создаёт .lnk с UNC-путём на свой сервер
• Доставляет через фишинг, шару или USB
• Жертва просто открывает папку — даже не кликает по файлу
• Windows Shell автоматически отправляет NTLM-хеш
• Атакующий ловит хеш через Responder и делает relay или offline-брутфорс

🎯 Почему CVSS 4.3 — это обманка

Microsoft оценила уязвимость как MEDIUM (CVSS 4.3). Формально — «частичная утечка конфиденциальных данных, целостность не нарушена». Но в реальной доменной среде перехваченный Net-NTLMv2-хеш — это входной билет. NTLM Relay даёт доступ к соседним сервисам без подбора пароля. Offline-брутфорс через hashcat при слабых паролях занимает минуты. А главное — APT28 уже использовала предшественника этой уязвимости в кампаниях против Украины и стран ЕС.

Получается парадокс: неполный патч превратил критическую RCE (CVSS 8.8) в «среднюю» spoofing-уязвимость (CVSS 4.3). Стало безопаснее, но не безопасно.

Если вы администрируете Windows-инфраструктуру с NTLM — проверьте, что апрельский патч установлен. А полный разбор механики, хронологию от первой CVE до попадания в каталог KEV и рекомендации по защите читайте в полной статье.

https://codeby.net/threads/cve-2026-32202-uyazvimost-windows-shell-zero-click-krazha-ntlm-kheshei-cherez-lnk-faily.92952/