🔍 Российские SIEM и EDR глазами атакующего: что реально защищает, а что — только на бумаге

В 2022-м Splunk, CrowdStrike и Tenable отключили российских клиентов за одну ночь. Инфраструктура ослепла. Сейчас, три года спустя, по данным BISA, 25% субъектов КИИ уже завершили переход на отечественные СЗИ, ещё 32% обещали успеть. Но никто не отвечает на главный вопрос: а насколько новый стек реально защищает?

Три года я разворачивал российские SIEM, EDR и сканеры на Red Team проектах — запускал атаки и смотрел, что появится в консоли аналитика. Делюсь конкретными наблюдениями.

⚔️ MaxPatrol SIEM — наиболее зрелый продукт. Хорошо покрывает Discovery и Lateral Movement из MITRE ATT&CK. На одном проекте он поднял алерт, когда WMI-запросы веером пошли на десяток хостов. Но правила из коробки — лишь стартовый набор. Один заказчик потратил восемь месяцев командой из четырёх аналитиков, чтобы переписать всю логику корреляции с SPL на PDQL. При грамотном использовании LOLBins без кастомных правил MaxPatrol пропускает существенную часть активности.

🛡 KUMA от Kaspersky берёт другим: нативной интеграцией внутри экосистемы. EDR ловит подозрительный процесс, событие летит в KUMA, там обогащается данными из KSN. Бесшовно — если весь стек Kaspersky. Но на одном проекте логи с отечественного сетевого оборудования парсились криво: часть полей терялась, правила корреляции не срабатывали. Аналитик узнал об атаке из моего отчёта, а не из своей консоли.

💸 RuSIEM — бюджетный вариант с оговорками. Из коробки ловит брутфорс и очевидные сканирования. Но на одном проекте Red Team прошёл от первичного доступа до контроля домена, а RuSIEM сгенерировал единственный алерт — на начальное сканирование портов. Всё остальное утонуло в потоке.

Вот что объединяет все три продукта:

• Сертификат ФСТЭК — есть у каждого
• Правила из коробки покрывают базовые сценарии, но не продвинутые атаки
• Глубина детектирования напрямую зависит от экспертизы команды, а не от вендора

Главный вывод, который я вынес за три года: инструмент не защищает сам по себе. MaxPatrol SIEM в руках слабой команды хуже, чем RuSIEM в руках сильной. Миграция — это не замена лицензии, а переосмысление всей логики мониторинга.

❓ А какой стек у вашего SOC? Уже прошли через миграцию или только планируете? Расскажите в комментариях — интересно сравнить.

В полной статье — разбор отечественных EDR, сканеров уязвимостей и честная таблица сравнения по всем параметрам.

https://codeby.net/threads/importozameshcheniye-ib-resheniya-sravneniye-chestnyi-obzor-rossiiskikh-siem-edr-i-skanerov-glazami-pentestera.92895/

Когда антивирус молчит — это не всегда хорошая новость

Руткиты составляют менее 1% всех детектируемых вредоносов. Звучит обнадёживающе, пока не смотришь на последствия.

🔍 APT-кампания ProjectSauron пять лет жила в инфраструктурах нескольких десятков организаций — никто не замечал. Ботнет DirtyMoe за год вырос с 10 000 до 100 000 машин, пока антивирусы хранили молчание. Stuxnet физически уничтожал центрифуги иранской ядерной программы. Это и есть парадокс руткитов: самый редкий тип малвари наносит непропорционально разрушительный ущерб.

Причина проста — руткит создаётся ради одной задачи: сделать атакующего невидимым. И здесь начинается самое интересное.

⚙️ Четыре уровня привилегий — четыре разных мира

Большинство материалов до сих пор делит руткиты на «user-mode» и «kernel-mode». Это картина начала 2010-х. Реальность сейчас — минимум четыре уровня, и каждый требует принципиально другого подхода к обнаружению.

Ring 3 (пользовательский режим) — перехват API-вызовов внутри процесса. На Windows это модификация IAT/EAT и inline-hooking ntdll.dll. На Linux — подмена через LD_PRELOAD. По данным Positive Technologies, 31% проанализированных семейств работали исключительно в этом режиме, ещё 31% совмещали оба. В MITRE ATT&CK это T1055 и T1574.

Ring 0 (режим ядра) — драйвер или LKM с привилегиями ОС. DKOM-манипуляции со структурой EPROCESS, перехват SSDT, подмена callback-ов. 38% выборки Positive Technologies. Один неаккуратный указатель в коде — и вместо невидимости получаешь синий экран на весь SOC.

🧬 Ring -1 (гипервизорный уровень) — руткит загружается ниже ядра ОС, перехватывая аппаратную виртуализацию Intel VT-x или AMD-V. ОС продолжает работать, не подозревая, что полностью контролируется гипервизором атакующего. Концепт Blue Pill показал это ещё в 2006 году.

Ring -2 (UEFI/firmware) — код, исполняемый до загрузки ОС. Буткиты LoJax, MoonBounce, CosmicStrand записываются в SPI-flash и переживают переустановку ОС и замену жёсткого диска. Полное уничтожение системы не помогает. Это уже не малварь — это постоянный имплант.

🛡 Почему это важно прямо сейчас

Каждый уровень требует своего инструментария обнаружения. Против Ring 3 работают сравнение хешей системных библиотек и анализ аномалий в памяти процессов. Против Ring 0 — WinDbg, Volatility, проверка целостности SSDT. Против Ring -2 — верификация прошивки и мониторинг SPI-flash. Инструменты не взаимозаменяемы: то, что поймает rkhunter, не увидит UEFI-импланта.

Именно поэтому «антивирус ничего не нашёл» — не ответ. Это только начало расследования.

Полная карта техник, матрица MITRE ATT&CK и методология обнаружения каждого уровня — в статье.

https://codeby.net/threads/tekhniki-rutkitov-polnaya-klassifikatsiya-matritsa-obnaruzheniya-i-protivodeistviye.92911/

🔍 Российские EDR под микроскопом: где слепые пятна?

Большинство «обзоров» отечественных EDR-решений — это пересказ маркетинговых PDF со скриншотами дашбордов. Красивые графики, зелёные галочки, «99.7% детектирования». Ни слова о том, где у этих систем реальные слепые пятна.

Разберём три решения — Kaspersky EDR Expert, PT Sandbox и SEKOIA XDR — с позиции Red Team оператора.

⚙️ Как каждый из них «видит» мир

Kaspersky EDR Expert — наиболее зрелый агент из тройки. Телеметрия строится на kernel-mode callbacks, подписке на ETW-провайдеры (Microsoft-Windows-Kernel-Process, DotNET и другие) плюс предположительно userland-хуки на ntdll.dll. По независимым тестам AV-TEST (декабрь 2023 — март 2024) продукт уверенно детектирует атаки в стиле APT18 и техники группировок TA577/Turla/FIN6. Вывод практический: коробочные техники из публичных фреймворков здесь не пройдут.

PT Sandbox — другой зверь. Это прежде всего песочница для динамического анализа, а не классический endpoint-агент. Файл запускается в изолированной VM, система фиксирует API-вызовы, сетевые соединения, изменения файловой системы и реестра. Для атакующего это означает смещение акцента на anti-sandbox техники (MITRE T1497). Интересный контекст: 74% российских компаний считают себя недостаточно защищёнными от целевых атак — именно поэтому Positive Technologies строит «матрёшку» из EPP + EDR + Sandbox.

SEKOIA XDR — европейская SOC-платформа без собственного endpoint-агента. Телеметрию она получает через сторонние инструменты: Sysmon, Microsoft Defender, Wazuh. Плюс очевиден — низкая нагрузка на хосты. Минус тоже: глубина мониторинга определяется возможностями стороннего агента, а не самой платформой.

🎯 Три разных цели — три разных подхода

Для Red Team это принципиально:

• Против Kaspersky EDR — работаешь с обходом хуков и kernel callbacks
• Против PT Sandbox — фокус на anti-sandbox и anti-VM техниках
• Против SEKOIA — оцениваешь глубину телеметрии конкретного агента-поставщика и обходишь корреляционные правила

🛠 Техника прямых syscall: почему это работает

Современные EDR, включая Kaspersky, устанавливают inline-хуки на ключевые функции ntdll.dll: NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThreadEx. Каждый вызов перехватывается, параметры логируются, подозрительные комбинации блокируются.

Direct Syscalls обходят это через вызов системных функций напрямую инструкцией syscall, минуя ntdll.dll и установленные на ней хуки. Инструменты вроде SysWhispers3 генерируют ассемблерные стабы с актуальными номерами syscall для разных версий Windows. Но и здесь есть нюанс: зрелые EDR умеют детектировать прямые syscall-вызовы по характерным паттернам в стеке вызовов.

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

https://codeby.net/threads/obkhod-edr-rossiiskiye-resheniya-pt-sandbox-kaspersky-edr-i-sekoia-testiruyem-s-pozitsii-red-team.92906/

🔍 Ваш «Сброс до заводских настроек» не удаляет ничего важного

Представь: ты купил подержанный электромобиль, нажал «Factory Reset» перед сдачей в trade-in — и уверен, что данные удалены. Но что если следующий владелец за 40 минут узнает твой домашний адрес, имена 340 контактов из телефонной книги, ежедневный маршрут до офиса и Google-аккаунт с рабочим OAuth-токеном?

Именно это произошло с реальным Nissan Leaf 2019 года. Предыдущий владелец добросовестно выполнил штатный сброс. Штатный сброс не затронул примерно 60% пользовательских данных на накопителе.

💾 Почему так происходит?

Штатный сброс в большинстве head units — операция уровня приложения, а не уровня накопителя. Прошивка просто помечает разделы как «свободные», но физически данные на eMMC-чипе лежат нетронутыми. По сути — rm без shred. Стандарт eMMC предусматривает команды SANITIZE и Secure Erase для гарантированного стирания, но прошивки head units их попросту не вызывают.

🗂 Что конкретно выживает после сброса?

• SQLite-базы навигации — полная история маршрутов с координатами и временными метками. Геозоны «Дом» и «Работа» хранятся в отдельном разделе конфигурации и переживают сброс.
• Контакты и журнал звонков — при сопряжении смартфона по Bluetooth head unit получает копию адресной книги по протоколу PBAP и кеширует её локально.
• OAuth-токены и credentials — без явного logout через приложение токены от Nissan Connect, Tesla API и OnStar живут месяцами.
• Wi-Fi пароли — включая домашнюю точку доступа.
• HomeLink-коды — радиокоды гаражных ворот и шлагбаумов.

🔓 Как это извлекают?

Физический доступ к eMMC-чипу не требует экзотического оборудования. Демонтаж head unit в большинстве EV — это 4–8 винтов и один-два разъёма. Дальше — программатор, ISP-пады на плате и снятие полного дампа за 10–20 минут. Анализ ведётся через открытый Autopsy или sqlite3 прямо в терминале.

Характерный пример команды для разведки структуры дампа:

binwalk -e nissan_leaf_emmc.bin

На выходе — ext4-разделы, SQLite-базы в /data/navigation/, /data/bluetooth/ и многое другое.

⚠️ Кто в зоне риска?

Head units до 2022 года выпуска на большинстве платформ не шифруют раздел userdata по умолчанию. Это Nissan Leaf, Chevrolet Bolt, Tesla Model 3 на MCU2. Если ты продаёшь такой автомобиль — штатного сброса недостаточно. Если покупаешь — ты потенциально получаешь данные предыдущего владельца.

Второй владелец не взламывает систему. Система просто никогда не удалила то, что должна была.

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

https://codeby.net/threads/privatnost-dannykh-podklyuchennykh-avtomobilei-chto-forensics-nakhodit-v-head-unit-posle-factory-reset.92930/

🔔 Signal удалил сообщение. iOS — нет.

Четыре месяца. Именно столько времени сообщения из Signal с настроенным самоуничтожением через 30 секунд пролежали в системной базе iOS совершенно нетронутыми. Это не теория и не лабораторный эксперимент — это реальный forensic-кейс, который в апреле 2026 года превратился в федеральное судебное дело.

🏛 ФБР против Signal: где сломалась логика

В суде Техаса агенты ФБР представили в качестве доказательства входящие сообщения Signal с iPhone подсудимой. Мессенджер был удалён с устройства, сообщения настроены на самоуничтожение. Шифрование Signal-протокола не взламывали. End-to-end шифрование сработало корректно — iOS подвела в другом месте.

Проблема в том, как система обращается с уже расшифрованными данными на стороне получателя. Когда сообщение приходит через Apple Push Notification Service, iOS рендерит уведомление на Lock Screen и одновременно сохраняет текст в системную notification database. Эта база живёт за пределами песочницы приложения. Signal физически не может до неё дотянуться.

⚙️ Как это работает изнутри

Путь входящего сообщения выглядит так:

1. Сервер Signal передаёт payload в APNs.
2. Apple доставляет уведомление на устройство через защищённый канал.
3. iOS расшифровывает payload и рендерит уведомление.
4. Текст сообщения кешируется в системной SQLite-базе — для Notification History и восстановления после перезагрузки.

Шаг 4 — корень проблемы. Приложение удаляет сообщение по таймеру, но запись в системной базе остаётся. Именно поэтому ФБР восстановило только входящие сообщения, а не исходящие: отправленные сообщения идут напрямую с устройства на сервер, минуя APNs, и никакого системного следа не оставляют.

🛠 CVE-2026-28950: что за баг

Apple присвоила уязвимости оценку CVSS 6.2 и классифицировала её по CWE-359 — раскрытие персональных данных неавторизованному актору. Вектор локальный: нужен физический доступ к устройству или его iTunes-бекапу. Никаких специальных привилегий, никакого взаимодействия пользователя — устройство в состоянии AFU и стандартные forensic-инструменты типа idevicebackup2.

Патч вышел 22 апреля 2026 года в составе iOS 18.7.8 и iOS 26.4.2. Примечательно: обновление появилось сразу после публикации 404 Media о судебном деле. Apple не раскрыла, как долго данные могли храниться до патча.

💡 Что это значит для пользователя

Если у тебя включён показ содержимого уведомлений (Show Previews → Always или When Unlocked), текст входящих сообщений сохраняется в системную базу вне зависимости от настроек приватности мессенджера. Disappearing messages, сквозное шифрование, удалённый аккаунт — всё это не защищает от артефактов на уровне ОС.

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

https://codeby.net/threads/uyazvimost-uvedomlenii-ios-kak-fbr-chitalo-udalennyye-soobshcheniya-signal-cherez-push-bazu.92933/

🎯 12 минут до захвата поддомена: как работает subdomain takeover

На bug bounty программе автор нашёл поддомен staging.target.example — его CNAME указывал на удалённый три месяца назад ресурс Azure. От первого dig до подтверждённого захвата — двенадцать минут.

Это не экзотика. Это системная проблема любой организации, которая регулярно создаёт и удаляет облачные ресурсы.

🔍 Как возникает уязвимость

Компания создаёт CNAME-запись app.company.com → company-app.azurewebsites.net, разворачивает приложение на Azure, а потом сносит облачный ресурс — но забывает убрать DNS-запись. CNAME начинает указывать в никуда. Это и есть dangling DNS — «висячая» запись.

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

💀 Что получает атакующий

Захваченный поддомен — это не просто дефейс. По классификации OWASP и данным Microsoft, через него открываются:

• Фишинговая страница на легитимном домене организации — антифишинговые фильтры молчат
• Перехват session cookies, если они установлены с атрибутом Domain=.company.com
• Площадка для XSS, CSRF и обхода CORS
• При NS takeover — полный контроль над DNS-зоной, включая MX-записи и перехват почты

Причём Secure-флаг на cookie не спасёт: атакующий спокойно выпустит валидный TLS-сертификат через Let's Encrypt на контролируемый поддомен.

🛠 Как искать: инструменты и подход

Стандартный пайплайн выглядит так:

1. Passive enumeration — собираем поддомены без единого пакета к цели. subfinder -d target.com -all -o subs.txt агрегирует данные из Certificate Transparency, Shodan, VirusTotal.

2. Amass запускаем параллельно — пересечение с subfinder даёт 60–70% совпадений. Оставшиеся 30–40% уникальных поддоменов — главная причина запускать оба инструмента.

3. Резолвинг через dnsx — вытаскиваем CNAME-записи массово: cat all_subs.txt | dnsx -cname -resp -o cname_records.txt

На выходе — строки вида sub.target.com [alias.provider.com]. Это сырьё для следующего шага: fingerprinting провайдера и проверки, жив ли ресурс.

Важный нюанс: некоторые bug bounty программы запрещают active enumeration на ранних этапах. Шаги с dnsx уже отправляют DNS-запросы — уточняйте правила scope до старта.

⚡️ Интересный момент по MITRE ATT&CK: subdomain takeover покрывает сразу несколько тактик — от разведки (T1590.002) до Impact через External Defacement (T1491.002). То есть одна «висячая» DNS-запись потенциально закрывает атакующему весь kill chain.

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

https://codeby.net/threads/zakhvat-poddomena-cherez-subdomain-takeover-ot-dangling-dns-do-polnoi-ekspluatatsii.92934/

От инженера до директора: сколько реально стоит путь в CISO

Средняя зарплата директора по информационной безопасности в Москве — 500 000 рублей в месяц. В крупном финтехе или госкорпорации вилка доходит до 1,5 млн рублей плюс бонус 30–50% от годового дохода. А топовые позиции с учётом KPI — до 2 млн рублей в месяц.

Разрыв между специалистом по ИБ (230 000 руб.) и CISO уровня топ-менеджмента — шестикратный. И это не вопрос стажа. Это вопрос смены роли и мышления.

🔑 Инженер с десятилетним опытом может провалить собеседование на CISO, если не умеет говорить с CFO на языке бизнес-потерь. А руководитель отдела с пятилетним стажем — получить оффер, потому что принёс на интервью расчёт ROI от внедрённой SIEM с конкретными цифрами.

Путь до позиции директора по ИБ в российских реалиях занимает 7–12 лет при целенаправленном движении. Западные источники называют 15–20 лет — но там другая корпоративная иерархия. В российском финтехе и e-commerce переход быстрее, если не застрять на уровне «вечного инженера».

📍 Три этапа, которые реально работают:

1. Специалист по ИБ (0–3 года) — строите техническую базу. Не просто закрываете тикеты, а копаете глубже: почему инцидент произошёл и какой бизнес-процесс допустил уязвимость. Вилка в Москве — 150 000–280 000 руб./мес.

2. Руководитель отдела (3–7 лет) — перестаёте настраивать SIEM и начинаете решать, какие логи вообще собирать и сколько это стоит бизнесу. Критический момент: если в этой точке руки тянутся к консоли — так и останетесь тимлидом с завышенным титулом. Вилка — 300 000–500 000 руб./мес.

3. CISO (7–12 лет) — здесь уже нужны кейсы по КИИ, опыт прохождения регуляторных проверок (Роскомнадзор, ФСТЭК, ФСБ) и умение защищать бюджет перед советом директоров. Вилка — от 500 000 до 2 000 000 руб./мес.

💡 Рекрутеры из Selecty фиксируют: поиск подходящего CISO затягивается на 4–6 месяцев. Рынок испытывает острый дефицит кандидатов, которые одновременно разбираются в технике, управлении и регуляторике. Это означает одно: если вы целенаправленно строите такой профиль — конкуренция за вас будет выше, чем за большинство других позиций в ИТ.

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

Полный roadmap с разбором каждого этапа, реальными вилками и списком проектов для резюме — в статье по ссылке.

https://codeby.net/threads/ciso-kar-yera-roadmap-ot-inzhenera-do-direktora-po-ib-v-2026-godu.92945/

Почему ваш скорборд сломан: изнутри Attack-Defense CTF

Восемь часов соревнований, 24 команды — и чекер, который каждые два тика возвращает CORRUPT. Три человека дебажат Python прямо во время игры, пока участники в чате пишут, что скорборд сломан. Знакомо? Это не гипотетический сценарий — именно так выглядит реальная организация A/D CTF, когда инфраструктура не готова.

🏗 Три кита Attack-Defense

Любой A/D CTF держится на трёх компонентах. Убери один — рассыпается всё.

• Gameserver — мозг соревнования. Размещает флаги, запускает чекеры, принимает сданные флаги, рисует скорборд. Важный момент: он не запускает эксплойты — работает с сервисом как легитимный пользователь.
• Vulnbox — сервер каждой команды с набором уязвимых сервисов. Все команды получают идентичные конфигурации.
• Game network — сеть, через которую команды атакуют друг друга, а gameserver проводит SLA-проверки.

⏱️ Тики: сердцебиение игры

Игра делится на раунды-тики по 1–5 минут. За типичный восьмичасовой CTF с тиками по 2–3 минуты получается 160–240 раундов. Каждый тик gameserver размещает новые флаги и проверяет SLA.

Скоринг складывается из трёх частей: Attack Points (украл флаг), Defense Points (никто не украл у тебя) и SLA Points (сервис жив и отвечает корректно). SLA-баллы — то, что команды теряют чаще всего. Причина банальна: криво запатчили сервис, чекер перестал проходить — и минус очки каждый тик.

🌐 Сетевая изоляция: зачем нужен NAT

Типовая адресация: game network 10.0.0.0/16, vulnbox команды N — 10.0.0.N, submission-сервер — 10.0.13.37:1337. Команды подключаются через VPN — WireGuard или OpenVPN.

Критический элемент — NAT masquerading. Game router делает SNAT на весь игровой трафик: все входящие пакеты на vulnbox выглядят приходящими от одного адреса, независимо от реального источника. Без этого команды могли бы просто заблокировать чужие IP через iptables — и вся «защита» сводилась бы к одному правилу.

🔍 Что происходит под капотом gameserver

На примере FAUST CTF (открытый исходный код): gameserver состоит из независимых модулей на общей PostgreSQL-базе. Checker Master — самый нагруженный: при 5 сервисах и 30 командах он запускает 150 проверок за тик. Плюс Controller, Submission и Web-интерфейс — каждый модуль независим и падает отдельно (что удобно для дебага и неудобно в три часа ночи).

Минимальный стек для 20–30 команд: gameserver просит 8 vCPU и 16 GB RAM, PostgreSQL — ещё 4 vCPU и 8 GB. И это только начало списка.

Полный разбор чекеров, написания SLA-проверок и автоматизации — в статье. Читай, если планируешь организовать собственный A/D или просто хочешь понять, почему скорборд иногда врёт 👇

https://codeby.net/threads/attack-defense-ctf-organizatsiya-ot-gameserver-do-avtomatizatsii-sla.92941/

🔓 Патч закрыл 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/

Дымовой датчик с отключённой сиреной: почему smoke-тесты не спасают без обратной связи

Пятница, вечер, деплой уходит в прод. Один flaky-тест из двенадцати снова упал, но gate пропустил сборку — порог «pass if >90%». Суббота, утро — клиенты не могут оплатить заказ. Платёжный эндпоинт прятался именно за тем тестом, который все привыкли игнорировать.

Реальная история с проекта на еженедельных релизах. Smoke-набор ловил дефект. Проблема была не в тестах, а в том, что с результатами никто ничего не делал. Уведомления летели в общий канал, мягкий порог прохождения, разбор падений — «потом».

🔥 Вот ключевая мысль: smoke-тест в CI/CD — это не отчёт, а gate. Отчёт можно проигнорировать. Gate блокирует пайплайн и не пускает сборку дальше. Разница принципиальная.

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

⚙️ Что именно ловит smoke, чего не поймают юниты:

• Сервис не стартует после деплоя (сломанный Dockerfile, пропущенная миграция)
• Критические эндпоинты отдают 404 или 500
• Переменные окружения не подтянулись — секреты, feature-флаги, connection strings
• Зависимости недоступны: база, кэш, внешний API

Юниты проверяют код в изоляции. Smoke проверяет задеплоенную систему в конкретном окружении. Поэтому smoke-checkpoint ставится после деплоя в staging, а не на этапе сборки.

📍 Три точки, где smoke даёт максимум:

1. После деплоя в staging — ловит проблемы конфигурации и маршрутизации
2. Перед промоушеном в прод — go/no-go gate, потому что staging и prod всегда отличаются по инфраструктуре
3. На canary-подах при progressive delivery — до увеличения трафика

Теперь про сам набор. 5–10 проверок, не больше. Видел suite на 40 тестов, который выполнялся 12 минут. Через месяц его перестали ждать и начали скипать. Весь smoke должен укладываться в 5 минут.

Минимум для любого проекта:

• GET /health — сервис жив
• POST /auth/login — авторизация работает
• Главный read-эндпоинт — данные отдаются
• Главный write-эндпоинт — запись проходит
• DB-probe через healthcheck — миграции применились

И важный нюанс: API-проверки стабильнее и быстрее UI-тестов в smoke. Сломана кнопка, но API работает — дефект, но не smoke-level блокер.

🎯 Главный вывод: smoke без жёсткого gate и разбора падений — дымовой датчик с отключённой сиреной. Фиксирует проблему, но никто не реагирует. В полной статье — конфиги для GitLab CI и GitHub Actions, метрики качества обратной связи и антипаттерны из реальных пайплайнов.

https://codeby.net/threads/smoke-testirovaniye-i-kachestvo-obratnoi-svyazi-ot-progona-do-deistviya-v-ci-cd.92953/

Бэкдор, который выживает после обновления прошивки — разбираем механику FIRESTARTER

Представьте: федеральное ведомство США, Cisco Firepower на периметре. Обнаружена компрометация — накатили патчи, обновили прошивку, перезагрузили устройство. Всё по процедуре. Через шесть месяцев атакующие снова внутри. Без эксплуатации новых уязвимостей. Устройство считалось чистым.

Группировка UAT-4356 (Storm-1849) использовала имплант FIRESTARTER — и его механика персистентности заслуживает отдельного разговора.

🔥 Как это работает

FIRESTARTER — ELF-бинарь, живущий внутри LINA-процесса (ядро ASA: инспекция пакетов, VPN, firewall-правила). Монолитная архитектура LINA — идеальная среда для имплантации, потому что любая модификация изнутри невидима для штатной диагностики.

show version — штатная прошивка. show running-config — тишина. Syslog — тоже тишина.

Весь трюк построен на файле CSP_MOUNT_LIST — он определяет, какие компоненты монтируются и запускаются при загрузке. Вот что делает FIRESTARTER при каждом выключении:

• Перехватывает SIGTERM через callback-функции
• Копирует себя в резервную локацию, замаскированную под штатный лог платформы
• Дописывает себя в CSP_MOUNT_LIST для автозапуска
• После загрузки — восстанавливает оригинальный файл, убирая следы

Артефакт в конфигурации существует только между выключением и загрузкой. После boot — файл выглядит чисто. Транзиентная персистентность в чистом виде.

⚡️ Почему патч не помогает

При firmware upgrade устройство выполняет graceful shutdown. FIRESTARTER перехватывает сигнал завершения, сохраняется, прописывает автозапуск — и после загрузки на новой прошивке имплант снова активен. Патч закрыл дверь, а гость уже внутри.

Начальный доступ шёл через связку CVE-2025-20362 (обход авторизации, CVSS 6.5, без учётных данных) + CVE-2025-20333 (buffer overflow, CVSS 9.9, RCE от root). Первая открывает замок, вторая даёт полный контроль. Обе в CISA KEV с сентября 2025 года, дедлайн на патч — один день.

🔍 На диске всего два артефакта: /usr/bin/lina_cs и /opt/cisco/platform/logs/var/log/svc_samcore.log. Негусто для threat hunting. А на legacy-устройствах ASA 5500-X группировка использовала ещё и буткит RayInitiator — persistence через ROMMON, где даже полная переустановка не гарантирует очистку.

Что из этого следует? Обновление прошивки без forensic-анализа — не remediation, а самоуспокоение. Если на периметре стоит Firepower с exposed WebVPN, одного патча мало — нужна проверка целостности файловой системы и анализ CSP_MOUNT_LIST в момент между shutdown и boot.

Сталкивались с персистентностью на сетевых устройствах в своей практике?

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

https://codeby.net/threads/firestarter-na-cisco-asa-kak-b-ekdor-perezhivayet-patchi.92961/