Форум информационной безопасности - Codeby.net

🛠 Пентест веб-приложений 2026: не очередной «топ-10», а реальный workflow с engagement'ов

Каждый год одни и те же подборки: Burp первый, Nmap второй, sqlmap третий. Копипаста с 2018-го. А между тем Caido на Rust уже дышит Burp в спину, Nuclei из сканера вырос в полноценный фреймворк, а AI-driven DAST начинает находить IDOR и chained SSRF, которые классические сканеры в упор не видят.

В статье — честное сравнение Burp Suite Pro vs Caido, практические YAML-шаблоны Nuclei для поиска IDOR, связка ffuf + nuclei для автоматизации от разведки до подтверждения уязвимости, тонкая настройка sqlmap для обхода WAF и полный пошаговый воркфлоу: subfinder → httpx → ffuf → nuclei → Burp Repeater → отчёт. Без маркетинга — только то, что реально находит баги.

Практическое руководство для пентестеров, которые хотят обновить арсенал и перестать тратить время на рутину.

Recovery Denial: почему ваши бэкапы — первое, что уничтожит шифровальщик

Ежедневное копирование на Veeam, еженедельный вынос на tape, правило 3-2-1 — всё по учебнику. А потом ransomware отработал за 47 минут: репозиторий зашифрован, каталог tape удалён, VSS-снимки стёрты ещё за двое суток до запуска payload. Сначала сожгли спасательные шлюпки — потом подожгли корабль.

В статье — полный разбор тактик Recovery Denial по MITRE ATT&CK (T1490, T1485, T1489): от удаления теневых копий и компрометации Veeam через доменные учётки до тихой подмены retention policy. Внутри — Sigma-правила для SIEM, PowerShell-скрипты аудита backup-заданий, hardening через immutable storage (S3 Object Lock, Linux Hardened Repo) и пошаговый план восстановления после атаки.

Практическое руководство со стратегией 3-2-1-1-0 и чеклистом hardening — для тех, кто не хочет узнать о проблемах с бэкапами в момент инцидента.

Взлом Signal без единого эксплойта: как QR-код крадёт ваш аккаунт целиком

Вы сканируете QR — думаете, это приглашение в группу. А на самом деле только что привязали свой Signal к чужому устройству. Все сообщения теперь читают двое.

В статье — полный разбор техник, которые APT-группы уже применяют в реальных операциях: подмена URI в инвайт-ссылках (sgnl://linkdevice вместо sgnl://signal.group), фишинговые страницы с QR-кодами под видом уведомлений Signal Security и извлечение БД переписки через WAVESIGN и PowerShell-скрипты. С MITRE ATT&CK-маппингом и конкретными мерами защиты.

Практическое руководство для тех, кто считает Signal неуязвимым — и для тех, кто проверяет это на практике.

CVSS 9.8 в Telegram: zero-click RCE через стикер, который вы даже не открывали

Вам прислали стикер. Вы его не открывали. Вы даже не заходили в чат. Но код уже выполнился — Telegram распарсил медиа в фоне, и этого хватило.

В статье — полный технический разбор ZDI-CAN-30207: декомпозиция CVSS-вектора, реконструкция kill chain через медиа-парсеры (libwebp, rlottie, libvpx), анализ поверхности атаки по платформам и разбор спора между ZDI и Telegram, который отрицает наличие бага. Внутри — готовые Sysmon-конфиги, YARA-правила для кеша стикеров, Frida-хуки для перехвата парсинга и Wireshark-фильтры.

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

[size] Сколько защиты нужно мобильному приложению, чтобы его не разобрали за один вечер? Вопрос неприятный, но очень прикладной. Если клиент после релиза слишком хорошо читается, спокойно цепляется во время выполнения и без особой боли ставится под сетевое наблюдение, дальше его уже начинают разбирать по слоям.

В тексте собран нормальный защитный контур для мобильного клиента: модель угроз, проверки на root и jailbreak, обфускация, контроль целостности, RASP, pinning, работа с хранилищем и самопроверка. Без воды и без иллюзий про одну волшебную защиту, которая всё закроет.

По пути разберём, где приложение обычно сыпется под нормальным разбором, почему отдельные меры часто живут слишком недолго и как собрать защиту так, чтобы клиент не слишком охотно объяснял, как он устроен, что проверяет и где у него слабые места.[/size]

Ловушка для разработчика: как фейковые AI-инструменты крадут ваши ключи и секреты

Набрали в Google «скачать Claude Code» — и первые три ссылки ведут на дроппер Lumma Stealer. Поставили MCP-сервер из npm — а за ним стоит сеть фейковых GitHub-аккаунтов с накрученными звёздами.

В статье — разбор трёх реальных векторов атак на разработчиков: malvertising через рекламу AI-инструментов, supply chain через троянизированные npm/PyPI-пакеты и фейковые «утечки» Claude Code с инфостилером внутри. С полной MITRE ATT&CK-матрицей, YARA/Sigma-правилами и KQL-запросами, которые можно раскатить на EDR уже завтра.

Практический чек-лист защиты + готовые детект-правила для security-инженеров и пентестеров.

В HackerLab запускается сертификация. На текущий момент сертификат доступен участникам, успешно завершившим курс SQL Injection Master и сдавшим итоговый экзамен.

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

Это не просто «галочка», а результат, подтверждённый практикой.

В честь запуска сертификации дарим промокод на скидку 20% для подписки PRO. Действует до 30 апреля: PRO20

Нажмите, чтобы раскрыть...

Подробности и программа курса

Linux post-exploitation давно живёт не на "чудо-обходах", а на штатной механике системы. `bash`, `systemd`, `cron`, `ssh-agent`, `procfs`, память процесса, eBPF - всё это выглядит нормально для хоста, и именно поэтому вокруг этих зон у EDR начинаются самые неприятные провалы в наблюдаемости.

Мы рассказали, почему Living off the Land на Linux до сих пор работает, где защита теряет уверенность, как начинают расходиться `bash_history`, журналы, временные метки и process telemetry, и почему продвинутая пост-эксплуатация всё чаще упирается не в "невидимость", а в доверенный контекст и глубину видимости сенсора.

Отдельно пройдём по самым неудобным зонам: `SSH_AUTH_SOCK`, `/proc/[pid]/mem`, eBPF, `cron`, `systemd`, `LD_PRELOAD`, SUID и fileless-логике. Без лишней воды, с упором на то, где на Linux реально ломается простая детекция и почему эту тему уже нельзя разбирать на уровне одного IOC или одного suspicious process.

В этом материале разберём, как Kyverno встраивается в admission pipeline Kubernetes и где именно он становится последним фильтром между kubectl apply и etcd. Без абстракций - mutating и validating webhook'и, failurePolicy, background scan и реальные сценарии, где политика либо спасает кластер, либо валит тебе деплой в самый неподходящий момент.

Пройдёмся по production-настройке: Helm values, таймауты вебхуков, HA, отчёты, PolicyReport, mutate/generate/validate политики и типовые запреты вроде privileged, hostNetwork, :latest, отсутствующих requests/limits. С прицелом не на лабораторию, а на живой кластер, где у политик есть цена ошибки.

В финале сведём всё к практическому результату: как сделать так, чтобы Kyverno не был декоративным YAML над кластером, а реально держал дисциплину, помогал аудиту и ловил мусор ещё до того, как он доедет до production.

В этом материале разберём, почему CNI в Kubernetes - это не вспомогательная сеть, а часть доверенной базы кластера. Пройдём путь от kubelet и CNI-вызова до datapath в ядре, чтобы стало понятно, где именно рождаются задержки, дыры в сегментации и сетевые сбои.

По косточкам разложим Cilium и Calico: архитектуру агентов, eBPF и iptables dataplane, L3/L4 и L7-политики, Hubble, BGP, GlobalNetworkPolicy, особенности observability и поведение под реальной нагрузкой. Без маркетингового тумана - только то, что влияет на прод.

В финале сведём всё к практическому выбору: когда брать Cilium, когда Calico, где упрёшься в ядро, где - в BGP, а где - в командную зрелость. Плюс бенчмарки, миграция с rollback-планом и список граблей, которые обычно всплывают уже после запуска.