Блог Сергея Попова
163 subscribers
95 photos
2 videos
96 links
Блог создателя codeby
Download Telegram
От инженера до директора: сколько реально стоит путь в 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/
🔥2👍1
Forwarded from Hacker Lab
🚗 Новый профиль HackerLab: прогресс, достижения и активность

Мы переработали профиль пользователя на 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 минут.

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

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 — идеальная среда для имплантации, потому что любая модификация изнутри невидима для штатной диагностики.

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/
75% вторжений в 2024 году — без единого эксплойта. Атакующие просто вошли.

Не через уязвимость. Не через 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 ловит сигнатуры, а не контекст. Атакующий, который использует валидные учётные записи и штатные инструменты вроде 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/
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/
🔓 В реальных пентестах мы чаще заходим через забытый роутер, чем через фишинг

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 часа. Большинство новичков начинают сразу со второго шага. Эта неделя — про первый.

Один инструмент, четыре режима:
📌 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
🔧 Обсуждай задачи и переписывайся прямо в HackerLab

Встроили форум-виджет Codeby прямо на страницы тасков — теперь обсуждение, подсказки и личка живут там же, где само задание.

Что умеет виджет:
— Тред с обсуждением рядом с задачей
— Скриншоты, файлы, реакции, онлайн-статусы
— Автообновление без перезагрузки страницы

Личные сообщения внутри виджета:
— Пишешь напрямую, не уходя с платформы
— Бейдж непрочитанных, поиск по имени, редактирование

Авторизация через Codeby ID. Работает на мобильном.

CTF — это не только решить в одиночку. Вовремя спросить или подсказать растит быстрее 🚀

Попробуйте и расскажите, чего не хватает 👇
🔗 https://codeby.net/threads/obsuzhdai-zadachi-i-perepisyvaisya-pryamo-v-hackerlab-vstroili-forum-i-lichnyye-soobshcheniya.93938/
🔍 Неделя 2: Virtual Server — Service Enumeration через SSH и FTP

Серия «Сетевая разведка за 30 дней» продолжается.

Открытые порты — это только начало. На этой неделе учимся читать сервисы: выжимать версии, баннеры, конфиги и файлы до первой попытки эксплуатации.

Цель: VDS, где SSH и FTP настроены «потом исправлю»

Инструменты:nmap -sV + скрипты ftp-anon, ssh-auth-methods — anonymous FTP: конфиги, бэкапы, исходники — ssh-audit — слабые алгоритмы и разрешённые методы — nc для сырого banner-grab + searchsploit по версии

⏱️ Старт: 8 июня, 20:00 МСК 🏁 Дедлайн: 14 июня, 23:59 МСК

До дедлайна — обсуждаем подходы, не флаги. После — writeup'ы открыты.

👇 Задание и обсуждение: 🔗 https://codeby.net/threads/nedelya-2-virtual-nyi-server-service-enumeration-cherez-ssh-i-ftp.93753/
🪪 У чата HackerLab теперь есть лицо!

Кликни на ник или аватарку собеседника прямо в чате — и откроется его карточка: уровень и ранг, место в рейтинге, сколько задач и CTF решено, активность на форуме. Тут же можно написать в личку, подписаться или заглянуть в полный профиль — в один клик.

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

🔗 hackerlab.pro
👍31🔥1
Пять команд в терминале вместо двадцати минут в Wireshark: как решать network-таски на CTF

Пока кто-то кликает по меню Statistics → Protocol Hierarchy в графическом интерфейсе, три флага уже улетают в скорборд. На KnightCTF 2024 пять задач из категории networking решались чистым tshark — без единого запуска GUI.

🔍 Первое действие с любым pcap-файлом — не открывать Wireshark, а набрать:

strings capture.pcap | grep -i "flag{"

Подставляешь формат флага из условия (KCTF{...}, flag{...}, ctfa{...}) и в части задач получаешь ответ за одну секунду. Флаг нередко лежит в открытом виде прямо в трафике — организаторы закладывают это намеренно.

Если не сработало — второй шаг: смотрим распределение протоколов.

tshark -r capture.pcap -q -z io,phs

На выходе — дерево с процентами. Видишь 95% HTTP и крошечную долю FTP или странные DNS-запросы? Вот туда и копай. Аномалия в протокольном распределении — почти всегда указатель на флаг.

Три главных места, где прячут флаги в HTTP-трафике:

• GET-параметры URL — что-то вроде /page.php?secret=flag{abc}
• POST-тело — формы логина, загрузка файлов
• Нестандартные заголовки ответа — X-Flag, X-Secret-Data

Отдельная история — заголовок Authorization: Basic. Встретил строку вроде dXNlcjpwYXNz? Это Base64. Декодируешь одной командой: echo "dXNlcjpwYXNz" | base64 -duser:pass. В CTF-задачах Base64 встречается повсюду: HTTP-заголовки, поддомены DNS, тело FTP-передач.

🕵️ DNS exfiltration — ещё один классический паттерн. Атакующий кодирует данные в поддоменах DNS-запросов: ZmxhZ3s.evil.com. Выглядит как обычный резолв, а на деле — канал утечки. Кстати, flag{ в Base64 выглядит как ZmxhZ3s — запомни этот паттерн, он экономит время на каждом втором соревновании.

Что касается FTP — протокол передаёт логины и пароли открытым текстом. Если в pcap есть FTP-сессия, креды достаются элементарно. Фильтруешь по ftp.request.command == "PASS" — и вот они.

📌 Минимальный набор для старта:

tshark — фильтрация, follow stream, экспорт объектов
strings + grep — быстрый поиск по бинарнику
base64 — декодирование на лету
binwalk -e — извлечение вложенных файлов (картинки, архивы, документы)

Всё это есть в любом Linux из коробки. Kali — вообще без доустановки. RAM от 4 ГБ, сеть не нужна, pcap-файлы на CTF редко превышают 50 МБ.

Когда GUI всё-таки нужен? Файлы от 500 МБ с десятками тысяч потоков, визуальный анализ ретрансмиссий и временных диаграмм. Но на типичном CTF — терминал быстрее.

В полной статье — пошаговый разбор реальных задач с KnightCTF и CTF Academy: follow stream через CLI, извлечение файлов из трафика и декодирование DNS-эксфильтрации. Забирай в закладки 👇

https://hackerlab.pro/blog/setevoy-analiz-ctf-razbiraem-http-ftp-i-dns-v-trafike-i-dostaem-flag-bez-wireshark-ekspert
👍21🔥1
🔍 Неделя 4 — Финал: Секретный кабинет

Последняя неделя серии «Сетевая разведка за 30 дней» — и сразу 500 очков.

Маршрут к цели известен. Нужен пароль. Всё, что изучали три недели — сейчас в одной цепочке:

nmap → gobuster → Burp Repeater → hydra

Разведка, directory enumeration, разбор auth-формы, брутфорс. Именно так выглядит реальный engagement.

⏱️ Старт: 23 июня, 10:00 МСК
🏁 Дедлайн: 28 июня, 23:59 МСК

Флаги до старта — в конкурсе не учитываются. До дедлайна обсуждаем подходы, не конкретные пути.

После 29 июня — финальный wrap-up серии, лучшие writeup'ы и что будет дальше.

👉 Неделя 4 — Финал: Секретный кабинет
👍1
Три символа, которые ломают авторизацию: как JWT-атаки решают CTF-задачи

На одном из CTF я потратил 40 минут на веб-задачу — перебирал эндпоинты, пробовал SQLi, ковырял параметры. А решение уместилось в три символа: none в поле alg JWT-заголовка и пустая подпись. Флаг пришёл мгновенно.

JWT — это строка из трёх частей через точку: header.payload.signature. Header говорит серверу, каким алгоритмом проверять подпись. Payload хранит данные о пользователе в открытом виде — никакого шифрования, просто base64url. Signature гарантирует, что никто не подменил содержимое. В теории.

На практике разработчики допускают ошибки в валидации, и вот три атаки, которые чаще всего встречаются в CTF:

🔓 1. alg:none — самая простая и самая недооценённая. Меняем алгоритм в header на "alg":"none", правим payload (например, "role":"admin"), убираем подпись, оставив финальную точку. Если сервер не проверяет алгоритм строго, он примет токен без подписи вообще. В jwt_tool это одна команда: python3 jwt_tool.py TOKEN -X a.

🔑 2. Брутфорс слабого секрета. Алгоритм HS256 использует один симметричный ключ для подписи и проверки. Если разработчик поставил пароль вроде secret, password123 или qwerty — его можно подобрать за секунды. hashcat с режимом 16500 и словарём rockyou.txt перебирает миллионы вариантов в секунду на GPU. Нашёл ключ — подписываешь любой payload и заходишь как admin.

3. Algorithm confusion — уровень посложнее. Сервер ожидает RS256 (асимметричная пара ключей), но атакующий переключает заголовок на HS256 и подписывает токен публичным ключом сервера как HMAC-секретом. Публичный ключ часто доступен — через /jwks.json или в исходниках. Сервер берёт тот же ключ для проверки и... подпись совпадает.

Где искать токен в задаче? Четыре места:

• Cookie — самый частый вариант (названия: jwt, token, session)
• Заголовок Authorization: Bearer ...
• Тело JSON-ответа после логина
localStorage в DevTools для SPA-приложений

Практический алгоритм на CTF: нашёл токен → декодировал header и payload → посмотрел alg → попробовал none → не сработало — запустил брутфорс секрета → проверил algorithm confusion. Три шага, которые закрывают 80% JWT-задач на соревнованиях.

По классификации OWASP, эти уязвимости попадают сразу под три категории Top 10: Broken Access Control, Cryptographic Failures и Security Misconfiguration. Не только CTF — реальные CVE тоже.

Полный разбор с командами и примерами — в статье на HackerLab.

https://hackerlab.pro/blog/jwt-ataki-ctf-ot-struktury-tokena-do-zahvata-flaga-cherez-alg-none-i-slabyy-sekret
👍21🔥1
Пустая страница Apache — и четыре минуты до флага

Представьте: вы подключаетесь к тренировочной машине на HackTheBox. Nmap показал единственный открытый порт 80, браузер — пустую страницу. Тупик. Одна команда gobuster dir со словарём common.txt — и через 35 секунд найден /robots.txt. Внутри — путь к админке. В исходном коде — забытые тестовые креды. Четыре минуты от запуска до флага. Без dirbusting эту машину можно было ковырять часами.

Перебор директорий — это первое, что делает пентестер после сетевого скана. Вы знаете, что порт открыт, но структура приложения — тёмный лес. Gobuster берёт словарь с типовыми именами путей, подставляет каждое в URL и анализирует HTTP-ответ. Просто, грубо, эффективно.

🔍 Что реально находят при dirbusting:

.env, config.php.bak, db_backup.sql — файлы с учётными данными, которые разработчик забыл убрать
• Директории .git/ и .svn/ — раскрывают исходный код проекта
• Панели phpMyAdmin без пароля, Tomcat Manager с дефолтными tomcat:tomcat
• Забытые веб-шеллы вроде cmd.php — прямой путь к RCE

По данным Verizon DBIR 2025, около 26% подтверждённых утечек приходится на атаки на веб-приложения. Немалая часть начинается именно с обнаружения эндпоинтов, которые никто не планировал показывать миру.

⚙️ Gobuster написан на Go, потребляет минимум памяти и работает быстро. В Kali Linux он предустановлен — просто набираете gobuster в терминале. Словари SecLists ставятся одной командой: sudo apt install seclists. После установки они лежат в /usr/share/seclists/.

Лайфхак из практики: если ставите через go install, сразу пропишите export PATH=$PATH:$HOME/go/bin в .bashrc. Иначе после перелогина команда «пропадёт», и вы потратите минут пять на выяснение причин.

Режим dir — основной. В CTF-контексте 90% работы — именно он. Минимальная команда требует всего два параметра: URL цели и путь к словарю. Остальные режимы (dns, vhost, fuzz, s3) решают другие задачи и в веб-задачах встречаются реже.

📌 Для тренировки поднимите OWASP Juice Shop в Docker — уязвимое приложение с десятками скрытых эндпоинтов. Идеальный полигон, чтобы прощупать Gobuster без риска что-то сломать.

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

https://hackerlab.pro/blog/gobuster-perebor-direktoriy-i-poisk-skrytyh-faylov-v-veb-zadachah-ctf
👍2