КиберМопс

КиберМопс pinned «Скупают базы пендосов, Европа и тд, платят хорошо. @elf717 @Gilbeet62 Всем пока.»

Скупают базы пендосов, Европа и тд, платят хорошо. @elf717 @Gilbeet62 Всем пока.

День 7: Разбор полётов Мы созвали post-mortem. Вышло больно: • CI/CD не контролируется ИБ. • Нет правил по base image и их валидации. • SBOM не внедрён. • Отсутствует контейнерная политика (OPA, seccomp, AppArmor). • Разработчики администрируют staging напрямую. Никто не был виноват — но виноваты были все.

День 6: Откуда пришли Обратный анализ показал, что PR был сделан с ноутбука, где находился token с доступом к GitLab. Владелец — тот самый junior, его ноутбук был заражён после установки crack-версии редактора. Никакой MDM, никакой segment isolation — только VPN и надежда на благоразумие сотрудников.

День 5: Поверхностная безопасность Я заглянул в отчёты внешнего аудита за последние полгода. Ни один из них не затронул CI/CD. Все фокусировались на web-пентестах и конфигурации nginx. Мы привыкли закрывать “внешнюю витрину”, забывая, что цепочка поставки — это не менее критичный вектор. Особенно когда у разработчиков root-доступ в staging.

День 4: Разговор с DevOps Мы сели с DevOps-инженером, который настраивал пайплайн. Он не был в курсе, что кто-то коммитил изменения в Dockerfile. Простой git blame показал: за день до сборки один из junior-разработчиков зашёл в ветку и изменил образ. PR прошёл без ревью. Причина: в команде не было policy на контроль Dockerfile, и защита веток была настроена только для main, а билд шёл с develop.

День 3: Ошибки CI/CD Jenkins работал под сервисным пользователем, у которого были права на деплой в production namespace. Изолированности между средами не было. Мы провели экспресс-аудит: оказалось, что pipeline не валидирует Dockerfile и позволяет билды с внешними base image — без проверки подписи или SBOM. Контроль на уровне CI/CD отсутствует полностью.

День 2: Первичный анализ Образ был из внутреннего Docker Registry, собран неделю назад. Инициатор — Jenkins Pipeline, который должен был задеплоить dev-среду. В логах Jenkins — всё выглядит чисто, но в образе есть скачивание bash-скрипта с pastebin. Я выгрузил образ и начал разбор с помощью dive и trivy. Внутри — зашифрованный reverse shell и обфусцированный Python-скрипт, который связывается с внешним C2.

День 1: Инцидент В понедельник утром SOC поднял тревогу: один из внутренних сервисов начал активные исходящие соединения в необычное время. На первый взгляд — просто тестовый контейнер в OpenShift, но IP-адреса назначения попали в список вредоносных по Threat Intelligence. Я начал с базового: кто запустил этот pod, какие образы использовались, и есть ли связка с разработкой.

Channel photo updated

Channel created