🔴 Red Team против Blue Team: не хайп, а разный образ мышления

Есть стереотип: Red Team — это крутые хакеры, Blue Team — скучные ребята за мониторами. На деле всё ровно наоборот.

80% времени Red-тимера — это написание отчётов, а не взломы. Методология, документация, воспроизводимость атаки. Голливудский образ «хакера в капюшоне» разбивается о реальность уже на первом пентесте.

А Blue Team? Когда в три часа ночи в Splunk прилетает lateral movement в реальном времени — и ты понимаешь, что атакующий уже внутри — адреналин не слабее, чем от первого полученного шелла. Это не мониторинг алертов. Это охота.

💡 Ключевое различие между командами — не инструменты, а асимметрия задачи. Red-тимеру достаточно одной успешной атаки, чтобы доказать точку. Blue-тимер должен останавливать сотни атак одновременно — и не пропустить ту единственную, которая реально опасна.

Это и определяет разный характер людей в этих командах. Red-тимеры часто интроверты-исследователи, которым нравится копать глубоко в одну систему. Blue-тимеры — те, кто умеет держать в голове сразу много контекста и быстро переключаться.

🟣 А что такое Purple Team? В большинстве российских компаний это вообще не существует как штатная единица. Но именно Purple-подход — когда атакующие и защитники садятся за один стол и вместе разбирают дыры в детектировании — отделяет зрелую программу безопасности от «бумажной» ИБ.

Как это выглядит на практике: Red-тимер проводит технику из матрицы MITRE ATT&CK, Blue-тимер смотрит — сработало ли детектирование. Не сработало — пишем правило. Сработало — проверяем, нет ли ложных срабатываний. Результат фиксируется и сразу идёт в улучшение защиты. Никакого «отчёта в стол».

Как выбрать своё направление? Задайте себе один вопрос: вам интереснее сломать систему или понять, почему она не сломалась? Первое — Red. Второе — Blue. Оба варианта — Purple.

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

🗺 В полной статье — детальная карта всех специализаций: от SOC Tier 1 до Threat Hunter, от junior-пентестера до оператора Red Team. Плюс реальные зарплатные вилки, сравнение сертификаций (OSCP, CEH, eJPT), и пошаговый план — с чего начать, если вы только присматриваетесь к ИБ.

Читайте полную версию — там разобраны все развилки пути.

https://codeby.net/threads/kar-yera-v-kiberbezopasnosti-red-team-blue-team-i-purple-team-polnaya-karta-spetsializatsii-i-poshagovyi-plan-rosta.92896/

Семь из десяти корпоративных сетей ломаются за 48 часов. Вот что за этим стоит

Звучит как кино, но это статистика из реальных пентестов. Семь из десяти корпоративных сетей оказывались скомпрометированы ещё до истечения двух суток — и каждая атака начиналась с одного и того же места: терминала Linux.

🖥 Не потому что это «хакерская ОС из кино». А потому что именно здесь цепочка от nmap -sS до secretsdump.py выстраивается без единого графического клика. Полный контроль, полная автоматизация, нулевая зависимость от GUI.

Но здесь начинается главная ловушка для новичков: большинство русскоязычных материалов застряли в бесконечных сравнениях Kali против Parrot. Опытный пентестер оперирует не дистрибутивом, а конкретными инструментами на каждом этапе kill chain. Дистрибутив — это просто ящик для инструментов. Цвет ящика не важен.

🔍 Если всё-таки выбирать, вот честная картина:

• Kali Linux — промышленный стандарт. Около 600 инструментов в базовом метапакете, образы для VM, Docker, WSL и ARM, меню структурировано по категориям MITRE ATT&CK. 99% обучающих материалов написаны под Kali — главный аргумент для старта.

• Parrot Security — Debian stable в основе, Tor и Anonsurf из коробки, меньше жрёт ресурсов. Единственный пентест-дистрибутив с полноценной Home-редакцией для повседневной работы.

• BlackArch — репозиторий из 2900+ утилит поверх Arch Linux. Потребление RAM в простое — около 330 МБ. Порог входа высокий, документация минимальная, зато найдёте любой инструмент.

⚡️ Теперь про то, что реально решает исход теста: разведка. По классификации MITRE ATT&CK это этапы T1595 и T1046. Пропустите разведку — будете стучаться в запертую дверь, когда окно рядом открыто настежь.

Пассивная разведка начинается до отправки первого пакета к цели. amass enum -passive -d target.com выгружает поддомены из Certificate Transparency логов. theHarvester собирает email-адреса, поддомены и имена сотрудников из публичных источников. И всё это — без единого пакета в сторону цели.

🎯 Дальше — активное сканирование, повышение привилегий через LinPEAS, техники закрепления через cron и systemd, обход EDR через syscall evasion и eBPF-атаки. Каждый этап kill chain — отдельная дисциплина со своими инструментами и ловушками.

Всё это разобрано в полном руководстве: от первого nmap-скана до закрепления в инфраструктуре. Карта kill chain с конкретными командами, инструментами и ссылками на детальные разборы каждого этапа — в статье по ссылке.

https://codeby.net/threads/linux-dlya-pentestera-polnoye-rukovodstvo-po-instrumentam-tekhnikam-i-avtomatizatsii.92899/

⚔️ 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/