RuntimeDefault не обязательно включён по умолчанию

В Linux seccomp ограничивает системные вызовы процесса. В Kubernetes профиль RuntimeDefault можно запросить явно. Фрагмент спецификации Pod:

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault

Так профиль запрашивается на уровне Pod.

Если профиль не указан, решает конфигурация kubelet. При включённом seccompDefault используется RuntimeDefault, иначе документированный вариант по умолчанию — Unconfined, без seccomp-ограничений.

Есть два существенных ограничения:

— Профиль определяет container runtime. Набор разрешённых вызовов может различаться между runtime и версиями. Рабочая нагрузка способна сломаться, если нужный syscall запрещён.
— Контейнер с privileged: true работает как Unconfined. Назначением seccomp-профиля это не исправить.

Включение node defaulting не дописывает поле в YAML Pod. Для проверки фактически применённого профиля документация предлагает смотреть runtime specification через crictl inspect. Начните с части узлов и проверьте рабочие сценарии перед расширением внедрения.

Kubernetes: профили seccomp и RuntimeDefault

Библиотека хакера

#cheat_sheet

capa: от совпадения к ручной проверке

HTTP, XOR, создание процессов: capa ищет в программе признаки таких возможностей по набору правил. При статическом анализе это ещё не доказательство, что файл выполнил каждое действие.

Флаг -vv показывает, какие признаки совпали с правилом и по каким адресам их искать при ручном разборе. Для просмотра результатов есть Explorer Web и standalone HTML для локальной работы.

Упаковка и обфускация могут скрыть признаки, а установщики и рантаймы — усложнить трактовку. На скриншоте — исходный пример Explorer с capa 7.0.1 от 2024 года. Это иллюстрация интерфейса.

Репозиторий и примеры
#tool_of_the_week

Библиотека хакера

Replay включён. Куда уйдёт незаписанный запрос?

Если mitmproxy не нашёл подходящий сохранённый ответ, по умолчанию запрос уйдёт на настоящий сервер. У server_replay_extra значение forward.

Для лаборатории, где такой выход не нужен, задайте server_replay_extra=kill. Несопоставленные запросы будут прекращаться. Это поведение server-side replay, не гарантия полной изоляции стенда.

Есть ещё два важных значения по умолчанию: server_replay_reuse=False и server_replay_refresh=True. Ответы не переиспользуются, а временные заголовки и сроки cookie обновляются. Учитывайте это при анализе исходных временных значений.

Работайте с разрешённым лабораторным трафиком. Сохранённые потоки могут содержать секреты.

Server-side replay
#cheat_sheet

Библиотека хакера

Offline collector: endpoint работает, связи с сервером нет

Offline collector Velociraptor запускается на работающей ОС. Он выполняет заранее выбранные VQL и artifacts, затем сохраняет результаты, лог и метаданные в ZIP-контейнер. Это сбор без обычного client-server канала, не анализ выключенного диска.

Набор artifacts выбирают до передачи коллектора. Права на чтение данных всё равно нужны. Шифрование ZIP настраивают отдельно: фиксированный пароль можно извлечь из конфигурации. Документация рекомендует X.509 со случайным паролем, защищённым сертификатом.

На скриншоте другой параметр: Generic Collector. Он отделяет конфигурацию и tools от подписанного бинарника. На macOS используют этот вариант, потому что встраивание config нарушает подпись.

Устройство и настройка collector
#resource_drop

Библиотека хакера

Миграция с VMware, домашний кластер, выросший из одного ноутбука, и ИИ для работы с инцидентами

Всё это на митапе Deckhouse User Community 12 ноября в Москве.

В программе три доклада:
— опыт НИУ «МИЭТ»: как университет переходит с VMware на виртуализацию Deckhouse — от пилота до миграции ВМ и резервного копирования;
— 13 лет домашней инфраструктуры: от одного ноутбука до геораспределённого кластера из нескольких квартир и дата-центров;
— IncidentGPT на практике: от участия в Open Source-проекте до внедрения в компании, а заодно переход с Prometheus на Deckhouse Prom++ ради экономии памяти.

Нетворкинг после основной программы тоже будет. :)

Где: People Loft, 1-я улица Энтузиастов, д. 12 (метро и D3 «Авиамоторная»).
Когда: 12 ноября, начало в 19:00. Сбор в 18:15, приходите! Возьмите с собой паспорт или водительское удостоверение.

Митап пройдёт только офлайн. Для участия зарегистрируйтесь на Timepad и дождитесь письма-подтверждения.

YARA-X строже проверяет фигурные скобки

При переносе правил с YARA 4.x обратите внимание на литерал { в регулярных выражениях. В YARA-X вне оператора повторения его нужно экранировать:

/abc{/ → /abc\{/

Строгая проверка помогает поймать и опечатку {1:5} вместо {1,5}. YARA 4.x могла принять ошибочную конструкцию за буквальный текст.

Флаг --relaxed-re-syntax ослабляет проверку. Он не превращает такую опечатку в нужное повторение. Есть и другие различия: строка с модификатором base64 должна содержать минимум 3 символа.

После компиляции проверьте правила на положительных и отрицательных образцах. Успешная компиляция ещё не означает, что правила находят те же совпадения.

Различия YARA и YARA-X
#patch_notes

Библиотека хакера

Уязвимый магазин для своей лаборатории

OWASP Juice Shop специально содержит уязвимости для обучения и CTF. В исходном ролике авторов видны магазин и Score Board с заданиями.

Локальный запуск из README:

docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Затем откройте http://localhost:3000. Привязка порта к loopback нужна, чтобы заведомо уязвимый стенд не слушал внешние интерфейсы. Для занятия выберите одну задачу и сравните поведение приложения до и после её решения.

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

README и варианты запуска
#ctf_challenge

Библиотека хакера

Для Sigma в EVTX нужен mapping

Chainsaw ищет по журналам событий Windows без развёртывания SIEM. Для Sigma нужны правила и mapping, который указывает поля журнала для сопоставления.

В примере авторов:

./chainsaw hunt EVTX-ATTACK-SAMPLES/ -s sigma/ --mapping mappings/sigma-event-logs-all.yml

Все три пути должны существовать. Начиная с версии 2 Sigma и EVTX samples не включены как submodules. Их берут отдельно либо используют подходящий all-in-one release.

Проверьте в выводе, сколько правил загрузилось. В примере README часть правил не загрузилась. Переданный каталог ещё не означает, что проверены все правила. Совпадение требует разбора контекста. Пустой результат не доказывает, что endpoint чист.

Примеры Chainsaw
#tool_of_the_week

Библиотека хакера

Пункт ASVS: номер вместе с версией

Номер требования может измениться между выпусками. Поэтому в отчёте или задаче полезнее запись v5.0.0-1.2.5, чем просто 1.2.5: она привязывает требование к конкретной версии ASVS.

Это рекомендуемый авторами формат. В примере ASVS 5.0.0 пункт относится к защите от OS command injection. На карточке разобраны части идентификатора.

Для проверки по конкретному выпуску берите стабильный tag v5.0.0. Ветка master содержит рабочие изменения. В репозитории есть и CSV с требованиями, если нужно перенести их в собственный чек-лист.

ASVS задаёт требования безопасности приложений и сервисов. Выполнение одного пункта не означает соответствия всему стандарту и не заменяет проверку остальных требований.

Зафиксированный выпуск ASVS 5.0.0
#resource_drop

Библиотека хакера

Что именно сообщает secret-scanning alert

GitHub различает три типа уведомлений о секретах. Они отличаются причиной срабатывания и получателем.

— User alert: в репозитории найден поддерживаемый секрет. Повтор одного секрета несколько раз в одном файле даёт один alert.
— Push protection alert: участник обошёл push protection репозитория. Такие события можно найти фильтром bypassed: true. При обходе только персональной защиты alert не создаётся, если защита самого репозитория выключена.
— Partner alert: GitHub уведомил провайдера из партнёрской программы об утечке в публичном репозитории или npm-пакете. В Security and quality репозитория это уведомление не показывается.

Сам alert ещё не доказывает, что найденные учётные данные действуют или что ими воспользовались. GitHub предупреждает, что среди generic- и AI-alerts может быть больше ложных срабатываний и секретов из тестов.

Типы alerts и границы обнаружения в GitHub Docs

Библиотека хакера

SF в Zeek: нормальное завершение TCP-соединения

В TCP-записи conn.log статус SF в поле conn_state означает нормальное установление и завершение соединения. В примере документации обе стороны закрыли его через FIN. О безопасности переданных данных этот статус ничего не говорит.

Выбирайте поля записи под вопрос расследования. id.orig_h и id.resp_h показывают стороны, порты уточняют конечные точки, duration — длительность. orig_bytes и resp_bytes описывают объём полезной нагрузки по направлениям, а поля с ip_bytes — объём на IP-уровне.

Не смешивайте service и ip_proto. Первое — распознанный прикладной протокол. Второе — номер IP-протокола, в том числе для потоков вроде OSPF. Поле появилось в Zeek 7.1.

Дальше берите uid и ищите связанную активность в других журналах Zeek. Выводы ограничены пакетами, которые видел сенсор. Для UDP тот же SF трактуется иначе, чем для TCP.

Разбор TCP- и UDP-записей в Book of Zeek
#cheat_sheet

Одного ingress-разрешения для Pod может быть мало

Ingress-политика целевого Pod разрешает соединение от клиента, но этого может быть недостаточно. Проверьте egress исходного Pod. Если оба направления изолированы политиками, разрешение нужно с обеих сторон.

Ingress и egress независимы. Пока Pod не выбран политикой для конкретного направления, ограничения NetworkPolicy в этом направлении не действуют. Ответный трафик разрешённого соединения допускается неявно.

Разрешения всех применимых политик объединяются. Добавление ещё одной политики с узким списком не отменяет более широкое разрешение из другой. Порядок политик этого не меняет.

Всё это работает только с сетевым плагином, реализующим NetworkPolicy. Поведение для hostNetwork зависит от реализации. Схема показывает обычное соединение Pod → Pod при изоляции обеих сторон.

Модель NetworkPolicy и её ограничения
#cheat_sheet

Команда PT ESC IR Positive Technologies выпустила ежегодное исследование по итогам 140+ проектов по расследованию инцидентов и ретроспективному анализу за период с IV квартала 2025-го по III квартал 2026 года.

Главные итоги

• Более чем в половине проектов злоумышленникам удалось нарушить работу компаний. В 21,2% проектов эксперты выявили разведывательную деятельность и кибершпионаж, а в 20% — выгрузку конфиденциальной информации.

• Следы известных APT-группировок обнаружили в 49,3% исследованных компаний. Всего идентифицировали 17 таких групп.

В некоторых организациях эксперты нашли следы одновременного присутствия двух и более группировок, а в одном госучреждении — сразу четырех. Самый длительный инцидент в выборке тоже выявили в госучреждении: злоумышленники оставались незамеченными 1398 дней — почти четыре года.

• Чаще других встречалась группировка PhantomCore, на втором месте — IAmTheKing. С шестью группировками команда столкнулась впервые в своей практике. Три из них — APT10051, StingyBasilisk и Chewbacca — ранее не были известны и были обнаружены специалистами PT ESC IR.

• Приложения на периметре по-прежнему являются главными исходными векторами проникновения (50,8% инцидентов).

• Промышленность вышла на первое место по числу обращений (22,5%). На госучреждения пришлось 17,6% проектов против 24% годом ранее.

Что помогало развивать атаки

Среди основных проблем — устаревшие ОС и ПО (30%), отсутствие 2FA (25%) и недостаточная сегментация сети (24%). Больше половины уязвимостей, которые встретились в атаках, к тому моменту были известны уже два года и дольше (и никак не пропатчены).

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