🔴 Red Team против Blue Team: не хайп, а разный образ мышления
Есть стереотип: Red Team — это крутые хакеры, Blue Team — скучные ребята за мониторами. На деле всё ровно наоборот.
80% времени Red-тимера — это написание отчётов, а не взломы. Методология, документация, воспроизводимость атаки. Голливудский образ «хакера в капюшоне» разбивается о реальность уже на первом пентесте.
А Blue Team? Когда в три часа ночи в
💡 Ключевое различие между командами — не инструменты, а асимметрия задачи. 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/
Есть стереотип: 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/
Forwarded from Codeby
Семь из десяти корпоративных сетей ломаются за 48 часов. Вот что за этим стоит
Звучит как кино, но это статистика из реальных пентестов. Семь из десяти корпоративных сетей оказывались скомпрометированы ещё до истечения двух суток — и каждая атака начиналась с одного и того же места: терминала Linux.
🖥 Не потому что это «хакерская ОС из кино». А потому что именно здесь цепочка от
Но здесь начинается главная ловушка для новичков: большинство русскоязычных материалов застряли в бесконечных сравнениях 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. Пропустите разведку — будете стучаться в запертую дверь, когда окно рядом открыто настежь.
Пассивная разведка начинается до отправки первого пакета к цели.
🎯 Дальше — активное сканирование, повышение привилегий через
Всё это разобрано в полном руководстве: от первого
https://codeby.net/threads/linux-dlya-pentestera-polnoye-rukovodstvo-po-instrumentam-tekhnikam-i-avtomatizatsii.92899/
Звучит как кино, но это статистика из реальных пентестов. Семь из десяти корпоративных сетей оказывались скомпрометированы ещё до истечения двух суток — и каждая атака начиналась с одного и того же места: терминала 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/
🔍 Российские SIEM и EDR глазами атакующего: что реально защищает, а что — только на бумаге
В 2022-м Splunk, CrowdStrike и Tenable отключили российских клиентов за одну ночь. Инфраструктура ослепла. Сейчас, три года спустя, по данным BISA, 25% субъектов КИИ уже завершили переход на отечественные СЗИ, ещё 32% обещали успеть. Но никто не отвечает на главный вопрос: а насколько новый стек реально защищает?
Три года я разворачивал российские SIEM, EDR и сканеры на Red Team проектах — запускал атаки и смотрел, что появится в консоли аналитика. Делюсь конкретными наблюдениями.
⚔️ MaxPatrol SIEM — наиболее зрелый продукт. Хорошо покрывает Discovery и Lateral Movement из MITRE ATT&CK. На одном проекте он поднял алерт, когда WMI-запросы веером пошли на десяток хостов. Но правила из коробки — лишь стартовый набор. Один заказчик потратил восемь месяцев командой из четырёх аналитиков, чтобы переписать всю логику корреляции с SPL на
🛡 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/
В 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
Ring 0 (режим ядра) — драйвер или LKM с привилегиями ОС. DKOM-манипуляции со структурой
🧬 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. Инструменты не взаимозаменяемы: то, что поймает
Именно поэтому «антивирус ничего не нашёл» — не ответ. Это только начало расследования.
Полная карта техник, матрица MITRE ATT&CK и методология обнаружения каждого уровня — в статье.
https://codeby.net/threads/tekhniki-rutkitov-polnaya-klassifikatsiya-matritsa-obnaruzheniya-i-protivodeistviye.92911/
Руткиты составляют менее 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-провайдеры (
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-хуки на ключевые функции
Direct Syscalls обходят это через вызов системных функций напрямую инструкцией
📖 Полная методология тестирования, разбор лабораторной среды и конкретные техники обхода — в статье на форуме.
https://codeby.net/threads/obkhod-edr-rossiiskiye-resheniya-pt-sandbox-kaspersky-edr-i-sekoia-testiruyem-s-pozitsii-red-team.92906/
Большинство «обзоров» отечественных 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-чипе лежат нетронутыми. По сути —
🗂 Что конкретно выживает после сброса?
• 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 или
Характерный пример команды для разведки структуры дампа:
На выходе — ext4-разделы, SQLite-базы в
⚠️ Кто в зоне риска?
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/
Представь: ты купил подержанный электромобиль, нажал «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 и одновременно сохраняет текст в системную
⚙️ Как это работает изнутри
Путь входящего сообщения выглядит так:
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-бекапу. Никаких специальных привилегий, никакого взаимодействия пользователя — устройство в состоянии
Патч вышел 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/
Четыре месяца. Именно столько времени сообщения из 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 программе автор нашёл поддомен
Это не экзотика. Это системная проблема любой организации, которая регулярно создаёт и удаляет облачные ресурсы.
🔍 Как возникает уязвимость
Компания создаёт CNAME-запись
Атакующий находит такую запись, регистрирует ресурс с тем же именем у облачного провайдера — и получает полный контроль над содержимым поддомена жертвы. Никаких эксплойтов, никакого брутфорса. Просто регистрация свободного имени.
💀 Что получает атакующий
Захваченный поддомен — это не просто дефейс. По классификации OWASP и данным Microsoft, через него открываются:
• Фишинговая страница на легитимном домене организации — антифишинговые фильтры молчат
• Перехват session cookies, если они установлены с атрибутом
• Площадка для XSS, CSRF и обхода CORS
• При NS takeover — полный контроль над DNS-зоной, включая MX-записи и перехват почты
Причём
🛠 Как искать: инструменты и подход
Стандартный пайплайн выглядит так:
1. Passive enumeration — собираем поддомены без единого пакета к цели.
2. Amass запускаем параллельно — пересечение с subfinder даёт 60–70% совпадений. Оставшиеся 30–40% уникальных поддоменов — главная причина запускать оба инструмента.
3. Резолвинг через dnsx — вытаскиваем CNAME-записи массово:
На выходе — строки вида
Важный нюанс: некоторые bug bounty программы запрещают active enumeration на ранних этапах. Шаги с
⚡️ Интересный момент по 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/
На 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 от внедрённой
Путь до позиции директора по ИБ в российских реалиях занимает 7–12 лет при целенаправленном движении. Западные источники называют 15–20 лет — но там другая корпоративная иерархия. В российском финтехе и e-commerce переход быстрее, если не застрять на уровне «вечного инженера».
📍 Три этапа, которые реально работают:
1. Специалист по ИБ (0–3 года) — строите техническую базу. Не просто закрываете тикеты, а копаете глубже: почему инцидент произошёл и какой бизнес-процесс допустил уязвимость. Вилка в Москве — 150 000–280 000 руб./мес.
2. Руководитель отдела (3–7 лет) — перестаёте настраивать
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/
Средняя зарплата директора по информационной безопасности в Москве — 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 команды — и чекер, который каждые два тика возвращает
🏗 Три кита 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
Критический элемент — NAT masquerading. Game router делает SNAT на весь игровой трафик: все входящие пакеты на vulnbox выглядят приходящими от одного адреса, независимо от реального источника. Без этого команды могли бы просто заблокировать чужие IP через
🔍 Что происходит под капотом 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/
Восемь часов соревнований, 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-путь вроде
Ключевой момент: всё это происходит до проверок SmartScreen и Mark of the Web. Исследователи называют это «gap between path resolution and trust verification» — окно между разбором пути и проверкой доверия. Функция
Итого — цепочка атаки:
• Атакующий создаёт .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/
Представьте: вы добросовестно накатили февральский 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/
🔥2👍1
Forwarded from Hacker Lab
Мы переработали профиль пользователя на HackerLab.
Теперь это не просто страница с базовой статистикой, а полноценная карта прогресса: какие задания уже решены, в каких направлениях пользователь силён, где есть зоны роста и куда двигаться дальше.
— общий прогресс по заданиям, курсам, пентест-машинам и PRO-лабам
— компетенции по направлениям
— сильные стороны и зоны роста
— история активности
Достижения открываются за конкретные шаги на платформе: первое решённое задание, новые рубежи, стабильное движение по таскам.
Теперь прогресс не растворяется в общей статистике - он остаётся в профиле и показывает путь пользователя на платформе.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Дымовой датчик с отключённой сиреной: почему 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 минут.
Минимум для любого проекта:
•
•
• Главный 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/
Пятница, вечер, деплой уходит в прод. Один 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/
❤1👍1🔥1
Бэкдор, который выживает после обновления прошивки — разбираем механику FIRESTARTER
Представьте: федеральное ведомство США, Cisco Firepower на периметре. Обнаружена компрометация — накатили патчи, обновили прошивку, перезагрузили устройство. Всё по процедуре. Через шесть месяцев атакующие снова внутри. Без эксплуатации новых уязвимостей. Устройство считалось чистым.
Группировка UAT-4356 (Storm-1849) использовала имплант FIRESTARTER — и его механика персистентности заслуживает отдельного разговора.
🔥 Как это работает
FIRESTARTER — ELF-бинарь, живущий внутри LINA-процесса (ядро ASA: инспекция пакетов, VPN, firewall-правила). Монолитная архитектура LINA — идеальная среда для имплантации, потому что любая модификация изнутри невидима для штатной диагностики.
Весь трюк построен на файле
• Перехватывает SIGTERM через callback-функции
• Копирует себя в резервную локацию, замаскированную под штатный лог платформы
• Дописывает себя в
• После загрузки — восстанавливает оригинальный файл, убирая следы
Артефакт в конфигурации существует только между выключением и загрузкой. После 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 года, дедлайн на патч — один день.
🔍 На диске всего два артефакта:
Что из этого следует? Обновление прошивки без 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/
Представьте: федеральное ведомство США, 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/
❤2
Каждая пятая компания из субъектов КИИ признала: к сроку не успеем
Опрос BISA за 2024 год — только 7% организаций полностью выполнили требования указа №166. Ещё 8% «планировали успеть». Остальные — кто в частичном соответствии, кто честно разводит руками. И это не абстрактная статистика — за ней стоят реальные SOC-команды, которые прямо сейчас пытаются пересадить боевую инфраструктуру со Splunk и CrowdStrike на отечественные аналоги.
Мы собрали полную карту импортозамещения в ИБ на 2025–2026 годы и вот что бросается в глаза.
🔹 Три указа — три разных дедлайна. Указ №166 запрещает использование иностранного ПО на значимых объектах КИИ с 1 января 2025. Указ №250 добавляет персональную ответственность руководителей и запрет на СЗИ из недружественных стран. А указ №309 расширяет круг субъектов, обязанных взаимодействовать с ГосСОПКА. Путаница между ними — ошибка, которую допускают даже опытные ИБ-руководители.
🔹 Рынок вырос до 191,7 млрд рублей. Solar, Bi.Zone, Positive Technologies скупили стартапы и сформировали собственные стеки. Три года назад российские продукты закрывали от силы 60% нужных функций. Сегодня разрыв сократился, но между маркетинговыми обещаниями и поведением на боевой инфраструктуре по-прежнему пропасть.
🔹 Штрафы и уголовка — не абстрактная угроза. Административка по ст. 13.12 КоАП — до 500 тысяч рублей. А если инцидент произошёл из-за нарушения правил эксплуатации значимого объекта КИИ, ст. 274.1 УК РФ предусматривает до 10 лет лишения свободы. Персональная ответственность теперь лежит на первом лице организации.
Что важно для практика прямо сейчас:
• SIEM — MaxPatrol SIEM и KUMA стали основными претендентами на замену Splunk и QRadar. Но миграция правил корреляции — это не «экспорт-импорт», а полноценная переработка логики под другую архитектуру.
• EDR — PT Sandbox, Kaspersky EDR тестируются с позиции Red Team, и результаты отличаются от того, что обещают даташиты.
• Сканеры уязвимостей — MaxPatrol VM, RedCheck, ScanFactory закрывают разные ниши. Универсального решения нет, и выбор зависит от масштаба инфраструктуры.
• WAF и NGFW — PT AF, UserGate, Континент конкурируют, но у каждого свои слепые зоны, видимые только при пентесте.
Отдельная боль — сертификация ФСТЭК и ФСБ. Класс защиты СЗИ привязан к категории информационной системы, и ошибка в выборе класса может обнулить весь проект миграции.
В полной статье — навигационная карта по каждому классу решений с детальными разборами и сравнениями на реальной инфраструктуре.
https://codeby.net/threads/importozameshcheniye-v-informatsionnoi-bezopasnosti-polnaya-karta-rossiiskikh-siem-edr-skanerov-i-waf-dlya-praktika.93019/
Опрос BISA за 2024 год — только 7% организаций полностью выполнили требования указа №166. Ещё 8% «планировали успеть». Остальные — кто в частичном соответствии, кто честно разводит руками. И это не абстрактная статистика — за ней стоят реальные SOC-команды, которые прямо сейчас пытаются пересадить боевую инфраструктуру со Splunk и CrowdStrike на отечественные аналоги.
Мы собрали полную карту импортозамещения в ИБ на 2025–2026 годы и вот что бросается в глаза.
🔹 Три указа — три разных дедлайна. Указ №166 запрещает использование иностранного ПО на значимых объектах КИИ с 1 января 2025. Указ №250 добавляет персональную ответственность руководителей и запрет на СЗИ из недружественных стран. А указ №309 расширяет круг субъектов, обязанных взаимодействовать с ГосСОПКА. Путаница между ними — ошибка, которую допускают даже опытные ИБ-руководители.
🔹 Рынок вырос до 191,7 млрд рублей. Solar, Bi.Zone, Positive Technologies скупили стартапы и сформировали собственные стеки. Три года назад российские продукты закрывали от силы 60% нужных функций. Сегодня разрыв сократился, но между маркетинговыми обещаниями и поведением на боевой инфраструктуре по-прежнему пропасть.
🔹 Штрафы и уголовка — не абстрактная угроза. Административка по ст. 13.12 КоАП — до 500 тысяч рублей. А если инцидент произошёл из-за нарушения правил эксплуатации значимого объекта КИИ, ст. 274.1 УК РФ предусматривает до 10 лет лишения свободы. Персональная ответственность теперь лежит на первом лице организации.
Что важно для практика прямо сейчас:
• SIEM — MaxPatrol SIEM и KUMA стали основными претендентами на замену Splunk и QRadar. Но миграция правил корреляции — это не «экспорт-импорт», а полноценная переработка логики под другую архитектуру.
• EDR — PT Sandbox, Kaspersky EDR тестируются с позиции Red Team, и результаты отличаются от того, что обещают даташиты.
• Сканеры уязвимостей — MaxPatrol VM, RedCheck, ScanFactory закрывают разные ниши. Универсального решения нет, и выбор зависит от масштаба инфраструктуры.
• WAF и NGFW — PT AF, UserGate, Континент конкурируют, но у каждого свои слепые зоны, видимые только при пентесте.
Отдельная боль — сертификация ФСТЭК и ФСБ. Класс защиты СЗИ привязан к категории информационной системы, и ошибка в выборе класса может обнулить весь проект миграции.
В полной статье — навигационная карта по каждому классу решений с детальными разборами и сравнениями на реальной инфраструктуре.
https://codeby.net/threads/importozameshcheniye-v-informatsionnoi-bezopasnosti-polnaya-karta-rossiiskikh-siem-edr-skanerov-i-waf-dlya-praktika.93019/
75% вторжений в 2024 году — без единого эксплойта. Атакующие просто вошли.
Не через уязвимость. Не через zero-day. Через дверь — с валидным логином и паролем. Среднее время от входа до латерального перемещения по сети — 62 минуты, а рекорд — 51 секунда. Identity стала главным вектором атак, и вот почему это касается каждого.
🔑 Мы привыкли думать, что MFA решает проблему. Но в реальности второй фактор — это замедлитель, а не стена. AiTM-прокси вроде
⚡️ Цепочка атаки выглядит как лестница из четырёх ступеней:
1. Учётные данные — credential stuffing из утёкших баз, password spraying, покупка логов у инфостилеров. По Verizon DBIR 2025, 38% утечек начинаются именно так.
2. Обход MFA — AiTM-фишинг, перехват OTP, push-бомбинг.
3. Токены и билеты — OAuth-токены, Kerberos TGT/TGS, Primary Refresh Token в Azure AD. Всё это работает без пароля и без MFA. Pass-the-Ticket, Pass-the-Cookie, token replay — атакующий действует от имени легитимного пользователя.
4. Закрепление — Golden Ticket, долгоживущие refresh tokens, скомпрометированный Identity Provider. Сброс пароля жертвы на этом этапе уже ничего не даёт.
🎯 Отдельная боль — Kerberos. Протоколу больше 30 лет, но он по-прежнему ядро аутентификации Active Directory. Kerberoasting не требует привилегий Domain Admin. Любой доменный пользователь запрашивает сервисный билет, зашифрованный хэшем пароля сервисной учётки, и крекает его офлайн. KDC при этом видит абсолютно легитимный запрос. AS-REP Roasting ещё проще — для аккаунтов с отключённой преаутентификацией доменная учётка даже не нужна.
И ещё одна цифра, которая должна не давать спать спокойно: медианное время исправления утёкшего секрета на GitHub — 94 дня. Три месяца API-ключ или токен лежит в открытом доступе. Понятие «учётные данные» давно вышло за рамки логина и пароля — теперь это JWT, API-ключи, CI/CD-секреты, сервисные аккаунты облаков.
🛡 Что делать прямо сейчас? Проверьте AD на Kerberoastable-аккаунты и учётки без преаутентификации. Внедрите FIDO2 вместо SMS и push. Мониторьте аномальные запросы TGS-билетов. Это минимум, который закрывает самые массовые векторы.
В полной статье — детальная карта атак на identity с разбором каждой техники, инструментов и методов детекта.
https://codeby.net/threads/ataki-na-autentifikatsiyu-polnyi-razbor-tekhnik-komprometatsii-oauth-mfa-kerberos-i-identity-infrastruktury.93646/
Не через уязвимость. Не через zero-day. Через дверь — с валидным логином и паролем. Среднее время от входа до латерального перемещения по сети — 62 минуты, а рекорд — 51 секунда. Identity стала главным вектором атак, и вот почему это касается каждого.
🔑 Мы привыкли думать, что MFA решает проблему. Но в реальности второй фактор — это замедлитель, а не стена. AiTM-прокси вроде
Evilginx2 перехватывают сессионные cookie в реальном времени, пока жертва вводит свой одноразовый код. Push-усталость заставляет человека нажать «Подтвердить» в три часа ночи, лишь бы уведомления прекратились. SIM-свопинг вообще убирает телефон из уравнения.⚡️ Цепочка атаки выглядит как лестница из четырёх ступеней:
1. Учётные данные — credential stuffing из утёкших баз, password spraying, покупка логов у инфостилеров. По Verizon DBIR 2025, 38% утечек начинаются именно так.
2. Обход MFA — AiTM-фишинг, перехват OTP, push-бомбинг.
3. Токены и билеты — OAuth-токены, Kerberos TGT/TGS, Primary Refresh Token в Azure AD. Всё это работает без пароля и без MFA. Pass-the-Ticket, Pass-the-Cookie, token replay — атакующий действует от имени легитимного пользователя.
4. Закрепление — Golden Ticket, долгоживущие refresh tokens, скомпрометированный Identity Provider. Сброс пароля жертвы на этом этапе уже ничего не даёт.
🎯 Отдельная боль — Kerberos. Протоколу больше 30 лет, но он по-прежнему ядро аутентификации Active Directory. Kerberoasting не требует привилегий Domain Admin. Любой доменный пользователь запрашивает сервисный билет, зашифрованный хэшем пароля сервисной учётки, и крекает его офлайн. KDC при этом видит абсолютно легитимный запрос. AS-REP Roasting ещё проще — для аккаунтов с отключённой преаутентификацией доменная учётка даже не нужна.
И ещё одна цифра, которая должна не давать спать спокойно: медианное время исправления утёкшего секрета на GitHub — 94 дня. Три месяца API-ключ или токен лежит в открытом доступе. Понятие «учётные данные» давно вышло за рамки логина и пароля — теперь это JWT, API-ключи, CI/CD-секреты, сервисные аккаунты облаков.
🛡 Что делать прямо сейчас? Проверьте AD на Kerberoastable-аккаунты и учётки без преаутентификации. Внедрите FIDO2 вместо SMS и push. Мониторьте аномальные запросы TGS-билетов. Это минимум, который закрывает самые массовые векторы.
В полной статье — детальная карта атак на identity с разбором каждой техники, инструментов и методов детекта.
https://codeby.net/threads/ataki-na-autentifikatsiyu-polnyi-razbor-tekhnik-komprometatsii-oauth-mfa-kerberos-i-identity-infrastruktury.93646/
Forwarded from Codeby
57% компаний узнают о взломе не от своего SOC. Почему?
Mandiant M-Trends 2025 фиксирует неприятную реальность: больше половины организаций получают новость о компрометации от внешней стороны — партнёра, регулятора, иногда журналиста. Не от собственного SIEM, не от EDR, не от аналитика на смене.
🔍 Медиана присутствия атакующего в сети до обнаружения — 11 дней. Звучит как исторический минимум, и формально так и есть. Но за 11 дней злоумышленник проходит полный kill chain: фишинг → закрепление → боковое перемещение → выгрузка данных или шифрование инфраструктуры. Когда вы узнаёте об атаке, ущерб уже нанесён.
Почему так происходит? Потому что SIEM ловит сигнатуры, а не контекст. Атакующий, который использует валидные учётные записи и штатные инструменты вроде
📊 Ещё одна цифра от IBM X-Force 2025: самый распространённый тип малвари сегодня — инфостилеры (32%), они обогнали шифровальщиков. А среднее время между публикацией CVE и устранением уязвимости в организации — 29 месяцев. Два с половиной года. Атакующим не нужны zero-day, когда окно открыто настолько широко.
⚙️ Расследование кибератаки — управляемый процесс с чёткими фазами. Два основных фреймворка — NIST SP 800-61 и SANS — описывают одну и ту же логику разными словами:
1. Подготовка — IR-план, playbook, инструменты наготове
2. Обнаружение и анализ — triage алерта, определение скоупа
3. Сдерживание — изоляция хоста, сегмента, учётки
4. Устранение и восстановление — очистка, пересоздание, возврат в продакшн
5. Разбор полётов — отчёт, timeline, IOC-приложения
Ключевое различие: NIST объединяет шаги 3-4, потому что на практике они идут параллельно. Вы изолируете один сегмент и тут же чистите соседний. SANS разбивает их последовательно, что удобнее для команд, которые строят процесс с нуля.
Но выбор фреймворка вторичен. Критично другое — сам факт наличия документированного плана. Без него каждый инцидент превращается в импровизацию, где теряются артефакты, затираются логи и уничтожаются доказательства.
🎯 Практический чеклист на первые 30 минут:
• Подтвердить алерт — это true positive?
• Определить скоуп — один хост или сегмент?
• Изолировать, не выключая — сохранить содержимое RAM
• Зафиксировать время — таймлайн начинается сейчас
Мы собрали полную карту Incident Response — от первого алерта до финального отчёта, с разбором форензики, анализа памяти, threat hunting и реальных кейсов. Все детали — в полной статье.
https://codeby.net/threads/rassledovaniye-kiberataki-polnaya-karta-incident-response-ot-obnaruzheniya-do-otcheta.93680/
Mandiant M-Trends 2025 фиксирует неприятную реальность: больше половины организаций получают новость о компрометации от внешней стороны — партнёра, регулятора, иногда журналиста. Не от собственного SIEM, не от EDR, не от аналитика на смене.
🔍 Медиана присутствия атакующего в сети до обнаружения — 11 дней. Звучит как исторический минимум, и формально так и есть. Но за 11 дней злоумышленник проходит полный kill chain: фишинг → закрепление → боковое перемещение → выгрузка данных или шифрование инфраструктуры. Когда вы узнаёте об атаке, ущерб уже нанесён.
Почему так происходит? Потому что SIEM ловит сигнатуры, а не контекст. Атакующий, который использует валидные учётные записи и штатные инструменты вроде
powershell.exe или wmic, не триггерит стандартные правила корреляции. Он выглядит как легитимный администратор.📊 Ещё одна цифра от IBM X-Force 2025: самый распространённый тип малвари сегодня — инфостилеры (32%), они обогнали шифровальщиков. А среднее время между публикацией CVE и устранением уязвимости в организации — 29 месяцев. Два с половиной года. Атакующим не нужны zero-day, когда окно открыто настолько широко.
⚙️ Расследование кибератаки — управляемый процесс с чёткими фазами. Два основных фреймворка — NIST SP 800-61 и SANS — описывают одну и ту же логику разными словами:
1. Подготовка — IR-план, playbook, инструменты наготове
2. Обнаружение и анализ — triage алерта, определение скоупа
3. Сдерживание — изоляция хоста, сегмента, учётки
4. Устранение и восстановление — очистка, пересоздание, возврат в продакшн
5. Разбор полётов — отчёт, timeline, IOC-приложения
Ключевое различие: NIST объединяет шаги 3-4, потому что на практике они идут параллельно. Вы изолируете один сегмент и тут же чистите соседний. SANS разбивает их последовательно, что удобнее для команд, которые строят процесс с нуля.
Но выбор фреймворка вторичен. Критично другое — сам факт наличия документированного плана. Без него каждый инцидент превращается в импровизацию, где теряются артефакты, затираются логи и уничтожаются доказательства.
🎯 Практический чеклист на первые 30 минут:
• Подтвердить алерт — это true positive?
• Определить скоуп — один хост или сегмент?
• Изолировать, не выключая — сохранить содержимое RAM
• Зафиксировать время — таймлайн начинается сейчас
Мы собрали полную карту Incident Response — от первого алерта до финального отчёта, с разбором форензики, анализа памяти, threat hunting и реальных кейсов. Все детали — в полной статье.
https://codeby.net/threads/rassledovaniye-kiberataki-polnaya-karta-incident-response-ot-obnaruzheniya-do-otcheta.93680/
🎯 Карьерный навигатор в кибербезопасности 2026
Пять треков, реальные зарплаты, конкретные точки входа — без воды и мотивационных речей.
Каждую неделю в личку форума прилетает одно и то же: «С чего начать в инфобезе?» или «Год в SOC L1 — куда дальше?». Вместо того чтобы отвечать в личку 50 раз — собрали всё в одном треде.
🔬 Пять треков, между которыми нужно выбирать:
• Pentester / Offensive Security — от 100K junior до 400K+ senior • SOC Analyst — от 90K на L1 до 450K руководитель SOC • DFIR — от 140K trainee до 600K forensic lead • AppSec / Secure Development — от 150K до 800K в финтехе • Red Team — входной билет от 200K, потолок 700K+
Цифры — медиана по Москве на 2026, данные hh.ru, SuperJob, Habr Career.
⚙️ Для каждого трека внутри: необходимые навыки, инструменты, сертификации, точка входа и ссылки на профильные гайды форума.
Отдельный блок — для тех, кто уже junior и упёрся в потолок: три конкретных действия за год, которые меняют финальный оффер на 30–50%.
💬 В конце — открытый опрос и живое обсуждение. Пишите, на каком вы этапе и что мешает следующему шагу — отвечаем лично каждому.
👉 https://codeby.net/threads/misen-kar-yernyi-navigator-v-kiberbezopasnosti-2026-treki-zarplaty-tochki-vkhoda.93738/
Пять треков, реальные зарплаты, конкретные точки входа — без воды и мотивационных речей.
Каждую неделю в личку форума прилетает одно и то же: «С чего начать в инфобезе?» или «Год в SOC L1 — куда дальше?». Вместо того чтобы отвечать в личку 50 раз — собрали всё в одном треде.
🔬 Пять треков, между которыми нужно выбирать:
• Pentester / Offensive Security — от 100K junior до 400K+ senior • SOC Analyst — от 90K на L1 до 450K руководитель SOC • DFIR — от 140K trainee до 600K forensic lead • AppSec / Secure Development — от 150K до 800K в финтехе • Red Team — входной билет от 200K, потолок 700K+
Цифры — медиана по Москве на 2026, данные hh.ru, SuperJob, Habr Career.
⚙️ Для каждого трека внутри: необходимые навыки, инструменты, сертификации, точка входа и ссылки на профильные гайды форума.
Отдельный блок — для тех, кто уже junior и упёрся в потолок: три конкретных действия за год, которые меняют финальный оффер на 30–50%.
💬 В конце — открытый опрос и живое обсуждение. Пишите, на каком вы этапе и что мешает следующему шагу — отвечаем лично каждому.
👉 https://codeby.net/threads/misen-kar-yernyi-navigator-v-kiberbezopasnosti-2026-treki-zarplaty-tochki-vkhoda.93738/
Forwarded from Hacker Lab
🔍 Сетевая разведка за 30 дней — 4 недели практики на HackerLab
80% реальных пентест-engagement'ов начинаются с nmap и gobuster, а не с экзотических эксплойтов. Кто умеет читать вывод сканера — находит уязвимости. Кто пропускает recon — стоит на брутфорсе вечно.
С 1 по 28 июня — бесплатная серия из 4 задач на hackerlab.pro. Одна неделя = один инструмент, сложность растёт:
📌 Неделя 1 — nmap: port scan + banner grabbing
📌 Неделя 2 — nmap -sV, ssh-audit: service enumeration
📌 Неделя 3 — gobuster, ffuf, wfuzz: web recon, directory + vhost
📌 Неделя 4 — nmap + Burp + hydra: полная цепочка recon → exploitation
Всё решается прямо на платформе — никаких VPN, регистраций, скачиваний.
⚙️ Каждый понедельник — новый weekly-тред с intro, ссылками и discussion prompts. До дедлайна обсуждаем подходы и ошибки без спойлеров, после — открываем writeup'ы.
🎁 Топ-3 первых solver'ов каждой недели — мерч от Codeby + упоминание в рекапе. Лучшие writeup'ы закрепляются в треде.
Подходит всем уровням: от первого запуска nmap до «code review» recon-привычек для middle.
К концу июня — свой чеклист «что делать, когда увидел новый IP» и публичные writeup'ы в портфолио.
📅 Старт — 1 июня. Первая машина — «Кто там?»
👉 https://codeby.net/threads/misen-setevaya-razvedka-za-30-dnei-4-nedeli-praktiki-na-hackerlab.93740/
80% реальных пентест-engagement'ов начинаются с nmap и gobuster, а не с экзотических эксплойтов. Кто умеет читать вывод сканера — находит уязвимости. Кто пропускает recon — стоит на брутфорсе вечно.
С 1 по 28 июня — бесплатная серия из 4 задач на hackerlab.pro. Одна неделя = один инструмент, сложность растёт:
📌 Неделя 1 — nmap: port scan + banner grabbing
📌 Неделя 2 — nmap -sV, ssh-audit: service enumeration
📌 Неделя 3 — gobuster, ffuf, wfuzz: web recon, directory + vhost
📌 Неделя 4 — nmap + Burp + hydra: полная цепочка recon → exploitation
Всё решается прямо на платформе — никаких VPN, регистраций, скачиваний.
⚙️ Каждый понедельник — новый weekly-тред с intro, ссылками и discussion prompts. До дедлайна обсуждаем подходы и ошибки без спойлеров, после — открываем writeup'ы.
🎁 Топ-3 первых solver'ов каждой недели — мерч от Codeby + упоминание в рекапе. Лучшие writeup'ы закрепляются в треде.
Подходит всем уровням: от первого запуска nmap до «code review» recon-привычек для middle.
К концу июня — свой чеклист «что делать, когда увидел новый IP» и публичные writeup'ы в портфолио.
📅 Старт — 1 июня. Первая машина — «Кто там?»
👉 https://codeby.net/threads/misen-setevaya-razvedka-za-30-dnei-4-nedeli-praktiki-na-hackerlab.93740/
🔓 В реальных пентестах мы чаще заходим через забытый роутер, чем через фишинг
18,8 миллиарда IoT-устройств подключены к сети прямо сейчас. У большинства из них последнее обновление прошивки было единственным — заводским. А окно от публикации критической уязвимости до первого рабочего эксплойта сжалось до 24–72 часов. Задумайтесь: ваш роутер, IP-камера или NAS — это, возможно, уже чья-то точка входа.
Почему так происходит? Потому что на роутере нет ни антивируса, ни логов, ни человека, который за него отвечает. Это идеальная мишень.
⚡️ Какие уязвимости эксплуатируют чаще всего?
Анализ каталога CISA KEV за 2024 год рисует чёткую картину. Вот топ проблем в сетевом оборудовании:
• Command Injection (CWE-78) — абсолютный лидер. CGI-бинарь в веб-интерфейсе роутера берёт параметр из HTTP-запроса и передаёт его напрямую в
• Дефолтные и жёстко зашитые пароли (CWE-287) — классика, которая никуда не делась. Камеры, NAS, SOHO-роутеры — полный доступ к устройству одним запросом.
• Out-of-bounds Write (CWE-787) — переполнение буфера в сетевых сервисах. Реальный пример: уязвимость в Captive Portal PAN-OS позволяла получить root-шелл на файрволе Palo Alto.
• Path Traversal (CWE-22) — чтение произвольных файлов через веб-панель управления. Конфиги, ключи, хеши — всё как на ладони.
🛡 Отдельная история — персистентность. Бэкдор FIRESTARTER на Cisco ASA показал, что даже после установки патча вредонос может пережить обновление. Патч закрывает дыру, но не выкидывает того, кто уже внутри. Это меняет саму парадигму патч-менеджмента для embedded-систем: мало обновить, нужно ещё убедиться, что устройство чисто.
📋 Что проверить прямо сейчас:
1. Telnet и HTTP на ваших роутерах — отключены? Если нет, у вас открытый вход без шифрования.
2. Прошивка — когда обновлялась последний раз? Если ответ «не помню» — это и есть проблема.
3. UPnP, SSDP, debug-порты — всё, что не нужно, должно быть закрыто.
Мы собрали полную карту атак на IoT: от классификации уязвимостей и разбора реальных CVE до готового чеклиста аудита и стратегии патч-менеджмента для устройств, которые обычно никто не патчит. Подробности — в полной статье.
https://codeby.net/threads/uyazvimosti-iot-ustroistv-kriticheskaya-karta-atak-i-patch-menedzhment.93797/
18,8 миллиарда IoT-устройств подключены к сети прямо сейчас. У большинства из них последнее обновление прошивки было единственным — заводским. А окно от публикации критической уязвимости до первого рабочего эксплойта сжалось до 24–72 часов. Задумайтесь: ваш роутер, IP-камера или NAS — это, возможно, уже чья-то точка входа.
Почему так происходит? Потому что на роутере нет ни антивируса, ни логов, ни человека, который за него отвечает. Это идеальная мишень.
⚡️ Какие уязвимости эксплуатируют чаще всего?
Анализ каталога CISA KEV за 2024 год рисует чёткую картину. Вот топ проблем в сетевом оборудовании:
• Command Injection (CWE-78) — абсолютный лидер. CGI-бинарь в веб-интерфейсе роутера берёт параметр из HTTP-запроса и передаёт его напрямую в
system() или popen(). Без фильтрации. Вообще. Результат — RCE от имени root.• Дефолтные и жёстко зашитые пароли (CWE-287) — классика, которая никуда не делась. Камеры, NAS, SOHO-роутеры — полный доступ к устройству одним запросом.
• Out-of-bounds Write (CWE-787) — переполнение буфера в сетевых сервисах. Реальный пример: уязвимость в Captive Portal PAN-OS позволяла получить root-шелл на файрволе Palo Alto.
• Path Traversal (CWE-22) — чтение произвольных файлов через веб-панель управления. Конфиги, ключи, хеши — всё как на ладони.
🛡 Отдельная история — персистентность. Бэкдор FIRESTARTER на Cisco ASA показал, что даже после установки патча вредонос может пережить обновление. Патч закрывает дыру, но не выкидывает того, кто уже внутри. Это меняет саму парадигму патч-менеджмента для embedded-систем: мало обновить, нужно ещё убедиться, что устройство чисто.
📋 Что проверить прямо сейчас:
1. Telnet и HTTP на ваших роутерах — отключены? Если нет, у вас открытый вход без шифрования.
2. Прошивка — когда обновлялась последний раз? Если ответ «не помню» — это и есть проблема.
3. UPnP, SSDP, debug-порты — всё, что не нужно, должно быть закрыто.
Мы собрали полную карту атак на IoT: от классификации уязвимостей и разбора реальных CVE до готового чеклиста аудита и стратегии патч-менеджмента для устройств, которые обычно никто не патчит. Подробности — в полной статье.
https://codeby.net/threads/uyazvimosti-iot-ustroistv-kriticheskaya-karta-atak-i-patch-menedzhment.93797/
👍1
Forwarded from Сергей Попов
🔍 Неделя 1 — nmap: Recon начинается со стука
Стартовала первая неделя серии «Сетевая разведка за 30 дней». Задача — «Кто там?» на HackerLab, 200 очков.
На эксплойт уходит 30 минут, на recon с нуля — 2 часа. Большинство новичков начинают сразу со второго шага. Эта неделя — про первый.
Один инструмент, четыре режима:
📌
Запоминаем не команды, а что делает каждый флаг. Команды можно нагуглить, понимание — нельзя.
⚙️ В weekly-треде обсуждаем подходы и ошибки без спойлеров. После дедлайна — открываем writeup'ы.
🎁 Топ-3 первых solver'ов — мерч от Codeby.
⚠️ Участвовать могут только те, кто ранее не решал это задание.
📅 Начало 1 июня в 20:00. Дедлайн — воскресенье, 7 июня, 23:59 МСК
👉 https://codeby.net/threads/nedelya-1-kto-tam-port-scan-i-banner-grabbing-na-nmap.93752/
Стартовала первая неделя серии «Сетевая разведка за 30 дней». Задача — «Кто там?» на HackerLab, 200 очков.
На эксплойт уходит 30 минут, на recon с нуля — 2 часа. Большинство новичков начинают сразу со второго шага. Эта неделя — про первый.
Один инструмент, четыре режима:
📌
nmap -sS — TCP SYN scan, быстрее полного соединения 📌 nmap -p- — все 65535 портов, чтобы не пропустить нестандартные сервисы 📌 nmap -sV -sC — детект версий + дефолтные NSE-скрипты 📌 nmap -O — fingerprint ОС для выбора цепочки эксплуатацииЗапоминаем не команды, а что делает каждый флаг. Команды можно нагуглить, понимание — нельзя.
⚙️ В weekly-треде обсуждаем подходы и ошибки без спойлеров. После дедлайна — открываем writeup'ы.
🎁 Топ-3 первых solver'ов — мерч от Codeby.
⚠️ Участвовать могут только те, кто ранее не решал это задание.
📅 Начало 1 июня в 20:00. Дедлайн — воскресенье, 7 июня, 23:59 МСК
👉 https://codeby.net/threads/nedelya-1-kto-tam-port-scan-i-banner-grabbing-na-nmap.93752/
❤2👍1🔥1