retour aux outils back to tools Ducklings

Peirates

Outil de test d'intrusion Kubernetes pour la post-exploitation au sein d'un cluster : abus de tokens de service account, élévation de privilèges et évasions de pod. Kubernetes penetration testing tool for post-exploitation inside a cluster — service account token abuse, privilege escalation, and pod escapes.

↗ https://github.com/inguardians/peirates

Overview

Peirates is a Kubernetes-focused post-exploitation tool built for the scenario where an attacker already has a foothold inside a pod or cluster. It automates the abuse chain that’s normally manual and tedious — harvesting service account tokens, enumerating RBAC permissions, escalating privileges via misconfigured roles, pivoting between namespaces, and escaping to the underlying node — all from an interactive menu-driven CLI.

Common Usage

Launch Peirates from inside a compromised pod (uses in-pod service account by default)

./peirates

Point it at a specific cluster/token from outside the pod

./peirates -s https://<k8s-api-server>:6443 -t <service-account-token>

Non-interactive mode: run a single action and exit

./peirates -i=false -c list-namespaces

Typical Interactive Session

[Peirates] -> list-namespaces
[Peirates] -> get-secrets
[Peirates] -> list-service-accounts
[Peirates] -> switch-service-accounts     # pivot to a more privileged SA token found
[Peirates] -> can-i                        # check current permissions (like kubectl auth can-i)
[Peirates] -> get-pods -A
[Peirates] -> exec-into-pod                # shell into another pod
[Peirates] -> make-privileged-pod          # deploy a hostPath/privileged pod for node escape

Common Escalation Paths It Automates

Enumerate all secrets reachable with the current token

[Peirates] -> get-secrets

Check if the current SA can create pods (often => full node compromise)

[Peirates] -> can-i create pods

Deploy an attacker-controlled privileged pod to break out to the host

[Peirates] -> make-privileged-pod

Tips

Peirates assumes it’s running with at least a low-privilege service account token — the first priority is usually enumerating and pivoting to a more privileged one via list-service-accounts / switch-service-accounts.
A service account able to create pods in most default RBAC setups is a straight path to node-level compromise via a privileged/hostPath pod.
Pair findings with kubectl auth can-i --list for cross-verification when RBAC behavior looks ambiguous.

Help / Man page

Usage: peirates [options]

  -s, --server URL          Kubernetes API server URL
  -t, --token TOKEN         service account token to use
  -c, --cert FILE           client certificate for authentication
  -i, --interactive BOOL     run in interactive menu mode (default: true)
  --run-command CMD          execute a single Peirates command and exit
  -h, --help                 display this help and exit

Interactive commands include:
  list-namespaces, list-service-accounts, switch-service-accounts,
  get-secrets, get-pods, exec-into-pod, can-i, make-privileged-pod,
  get-kubernetes-secrets-from-container, mount-hostPath-volume

Vue d’ensemble

Peirates est un outil de post-exploitation axé sur Kubernetes, conçu pour le scénario où un attaquant dispose déjà d’un point d’ancrage à l’intérieur d’un pod ou d’un cluster. Il automatise la chaîne d’abus normalement manuelle et fastidieuse : récupération des tokens de service account, énumération des permissions RBAC, élévation de privilèges via des rôles mal configurés, pivot entre namespaces, et évasion vers le nœud sous-jacent, le tout depuis une CLI interactive pilotée par menu.

Utilisation courante

# Lancer Peirates depuis un pod compromis (utilise par défaut le service account du pod)
./peirates

# Cibler un cluster/token spécifique depuis l'extérieur du pod
./peirates -s https://<k8s-api-server>:6443 -t <service-account-token>

# Mode non interactif : exécuter une seule action puis quitter
./peirates -i=false -c list-namespaces

Session interactive typique

[Peirates] -> list-namespaces
[Peirates] -> get-secrets
[Peirates] -> list-service-accounts
[Peirates] -> switch-service-accounts     # pivoter vers un token de SA plus privilégié trouvé
[Peirates] -> can-i                        # vérifier les permissions actuelles (comme kubectl auth can-i)
[Peirates] -> get-pods -A
[Peirates] -> exec-into-pod                # obtenir un shell dans un autre pod
[Peirates] -> make-privileged-pod          # déployer un pod hostPath/privileged pour une évasion de nœud

Chemins d’escalade courants automatisés

# Énumérer tous les secrets accessibles avec le token actuel
[Peirates] -> get-secrets

# Vérifier si le SA actuel peut créer des pods (souvent => compromission complète du nœud)
[Peirates] -> can-i create pods

# Déployer un pod privilégié contrôlé par l'attaquant pour s'évader vers l'hôte
[Peirates] -> make-privileged-pod

Conseils

Peirates part du principe qu’il s’exécute avec au moins un token de service account faiblement privilégié : la première priorité consiste généralement à énumérer puis pivoter vers un token plus privilégié via list-service-accounts / switch-service-accounts.
Un service account capable de create pods dans la plupart des configurations RBAC par défaut constitue une voie directe vers une compromission au niveau du nœud via un pod privileged/hostPath.
Recouper les résultats avec kubectl auth can-i --list en cas de comportement RBAC ambigu.

Aide / Page de manuel

Usage: peirates [options]

  -s, --server URL          Kubernetes API server URL
  -t, --token TOKEN         service account token to use
  -c, --cert FILE           client certificate for authentication
  -i, --interactive BOOL     run in interactive menu mode (default: true)
  --run-command CMD          execute a single Peirates command and exit
  -h, --help                 display this help and exit

Interactive commands include:
  list-namespaces, list-service-accounts, switch-service-accounts,
  get-secrets, get-pods, exec-into-pod, can-i, make-privileged-pod,
  get-kubernetes-secrets-from-container, mount-hostPath-volume