Listen to this Post
Introduction:
Kubernetes (K8s) has become the de facto orchestrator for cloud-native applications, but its complex identity layer – service accounts, RBAC, and OIDC tokens – is now the primary attack vector. Threat actors exploit stolen K8s service account tokens to bypass perimeter defenses and laterally move into sensitive infrastructure, as recently uncovered by Palo Alto Networks Unit 42, which documented a 282% increase in K8s-related operations and a live cryptocurrency exchange breach where a single compromised token led to financial system compromise.
Learning Objectives:
- Detect and mitigate Kubernetes service account token leaks and abuse using runtime auditing and admission controllers.
- Exploit and patch the React2Shell vulnerability (CVE-2025-55182) to prevent command execution inside K8s workloads.
- Implement identity hardening strategies including short-lived tokens, OIDC with workload identity, and network policies to block lateral movement.
You Should Know:
- Stolen Kubernetes Service Account Tokens – How Attackers Pivot from Pod to Production
Attackers rarely break encryption; they steal keys. In the Unit 42 case, a compromised application pod leaked its mounted service account token. Since K8s automatically mounts a default token into every pod (unless explicitly disabled), an attacker achieving initial code execution can extract `/var/run/secrets/kubernetes.io/serviceaccount/token` and use it to authenticate against the K8s API server. With a token bound to a service account that had overly permissive RBAC roles (e.g., `cluster-admin` or list secrets), the attacker enumerated namespaces, discovered secrets containing cloud provider credentials, and pivoted into the cryptocurrency exchange’s core financial database.
Step‑by‑step guide – Detection and Mitigation:
Linux (master/node):
Check which service accounts have excessive permissions:
List all cluster role bindings with dangerous verbs
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name | contains("admin","cluster-admin","edit")) | {name: .metadata.name, subjects: .subjects}'
Find pods with automountServiceAccountToken: true (default)
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.automountServiceAccountToken != false) | {namespace: .metadata.namespace, pod: .metadata.name}'
Windows (using kubectl with AKS or any cluster):
Enumerate service account tokens in all namespaces kubectl get secrets --all-namespaces | Select-String "service-account-token" Simulate token extraction (from a compromised pod) kubectl exec -it <pod-name> -- cat /var/run/secrets/kubernetes.io/serviceaccount/token
Mitigation:
- Disable automatic token mounting: `automountServiceAccountToken: false` in pod spec or service account.
- Enforce short-lived tokens (max 1 hour) with rotation using TokenRequest API.
- Use OIDC with workload identity (Azure AAD, AWS IAM roles for service accounts, GCP Workload Identity) so no static tokens exist.
- Implement a dynamic admission controller (e.g., Kyverno or OPA Gatekeeper) to reject pods with default token mounts.
- React2Shell (CVE-2025-55182) – Remote Code Execution in React Server Components
Within days of disclosure, attackers weaponized CVE-2025-55182, a deserialization flaw in React’s Flight protocol (used by Next.js and other React Server Components). The vulnerability allows unauthenticated attackers to send a crafted multipart form-data request that triggers arbitrary command execution on the Node.js server hosting the K8s workload. In the Unit 42 analysis, this led to data theft from a crypto exchange’s order-matching engine pod.
Step‑by‑step – Exploitation (educational) & Patching:
Exploitation concept (Linux attacker machine):
Craft malicious payload using node-serialize or custom prototype pollution
curl -X POST https://victim-app.com/api/flight \
-H "Content-Type: multipart/form-data" \
-F 'payload={"then":"$1:<strong>proto</strong>:constructor:constructor:require('child_process').execSync('cat /etc/passwd')"}'
Detection of exploitation attempts:
Search Node.js logs for suspicious Flight protocol errors (Linux) grep -i "FlightServer" /var/log/app/error.log | grep -E "Unexpected token|deserialization" Real-time monitoring with Falco rule falco -r /etc/falco/rules.d/react2shell.yaml
Patch process:
- Upgrade React to version 19.0.3+ or Next.js to 15.1.4+ (if using server components).
- For air-gapped clusters, manually patch the `react-server-dom-webpack` package:
npm install [email protected] kubectl rollout restart deployment <react-app> -n <namespace>
- Apply a temporary network policy to block external access to the Flight endpoint (e.g., `/flight` or
/_flight):apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: block-flight-external spec: podSelector: matchLabels: app: react-app policyTypes:</li> <li>Ingress ingress:</li> <li>from:</li> <li>podSelector: {} allow only internal pods ports:</li> <li>port: 3000
- Lateral Movement via Compromised Cloud Identity – From K8s to Core Financial Systems
After obtaining a K8s service account token with access to cloud provider secrets (e.g., AWS `secretsmanager` or Azure Key Vault), attackers retrieved database connection strings for the crypto exchange’s ledger database. They then used `kubectl port-forward` to tunnel traffic through the cluster and exfiltrated 2 GB of transaction data.
Step‑by‑step – Hardening Cloud Identity & Network Segmentation:
Linux – Block kubectl port-forward at network level:
Use Calico global network policy to deny port-forward traffic (e.g., TCP 10250 kubelet API) calicoctl apply -f - <<EOF apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: block-kubectl-forward spec: selector: all() ingress: - action: Deny protocol: TCP destination: ports: [10250, 10255, 6443] egress: - action: Deny protocol: TCP destination: ports: [10250, 10255, 6443] EOF
Windows (Azure AKS) – Disable cloud secrets from being mounted:
Assign Azure AD Pod Identity only to specific pods, disable default az aks update -g myRG -n myAKS --disable-pod-identity Then use Workload Identity with explicit selector kubectl annotate serviceaccount my-sa "azure.workload.identity/client-id=$CLIENT_ID"
Cloud Hardening (AWS):
– Enforce IAM roles for service accounts (IRSA) with least privilege – never attach `secretsmanager:GetSecretValue` to a frontend pod.
– Use VPC endpoint policies to restrict secrets access to only the required secret ARN.
– Implement egress network policies to deny traffic to cloud metadata endpoints (169.254.169.254, 169.254.170.2).
- Continuous Auditing of Kubernetes RBAC and Token Usage
Unit 42 recommends real-time auditing of API server requests. Many breaches go undetected because service account tokens are logged but not correlated with anomalous API calls (e.g., listing secrets from a pod that normally only reads configmaps).
Step‑by‑step – Enable Audit Logs and Anomaly Detection:
Enable audit policy on K8s API server (Linux control plane):
/etc/kubernetes/audit-policy.yaml apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse resources: - group: "" resources: ["secrets", "configmaps"] - group: "rbac.authorization.k8s.io" resources: ["rolebindings", "clusterrolebindings"] - level: Metadata verbs: ["list", "get", "watch"]
Forward logs to SIEM (using Falco + fluentd):
Install Falco with K8s audit log support helm install falco falcosecurity/falco --set falco.jsonOutput=true --set falco.auditLog.enabled=true
Detect suspicious token usage – Linux command:
List service account tokens used in last hour from audit log
jq '. | select(.user.username | contains("system:serviceaccount")) | {user: .user.username, verb: .verb, resource: .objectRef.resource}' /var/log/kubernetes/audit.log | grep -E '"verb":"list"|"verb":"get"'
- Automated Response – Using OPA Gatekeeper to Quarantine Leaked Tokens
Instead of waiting for SOC, you can implement dynamic admission control that checks token reputation. If a token appears in a public GitHub leak or exceeds normal request volume, automatically revoke it and label the pod as compromised.
Step‑by‑step – OPA Constraint to Revoke Token on Suspicious Activity:
Create a constraint that blocks API calls from pods with high request frequency:
template.yaml
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
name: ratelimitbytoken
spec:
crd:
spec:
names:
kind: RateLimitByToken
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package ratelimit
violation[{"msg": msg}] {
input.review.userInfo.username == "system:serviceaccount:default:compromised-sa"
count(input.review.operation) > 10 in 1s
msg := "Token suspected leaked – revoke immediately"
}
Apply and automate token revocation via Kubernetes job:
kubectl create -f constraint.yaml Use a cronjob to check for constraint violations and delete the secret kubectl delete secret <service-account-token-secret> -n default
What Undercode Say:
- Key Takeaway 1: Identity is the new perimeter – 282% increase in K8s identity attacks proves that focusing on network firewalls while ignoring service account permissions leaves your cloud infrastructure wide open. The cryptocurrency exchange breach succeeded because a pod token had unnecessary `secrets` access.
- Key Takeaway 2: Zero-trust for Kubernetes means no implicit trust – even within the cluster. Disable default token mounts, rotate tokens every 60 minutes, and enforce mutual TLS (mTLS) with SPIFFE to ensure every workload authenticates before accessing any API.
- Analysis: The React2Shell (CVE-2025-55182) disclosure-to-exploit window of “days” mirrors Log4Shell’s velocity. Attackers now automate scanning for React Flight endpoints because server-side rendering is ubiquitous. Mitigation requires immediate patching, but more importantly, shifting left with static analysis of deserialization sinks in CI/CD pipelines. The combination of stolen K8s tokens and application-level RCE creates a devastating chain – attackers get code exec via React2Shell, extract the mounted token, then pivot to cloud secrets. Defenders must segment at both layers: network policies between namespaces and application firewalls (e.g., ModSecurity for Node.js).
Prediction:
Within 12 months, we will see the first major ransomware group exclusively targeting Kubernetes identity misconfigurations, bypassing EDR entirely because there is no agent inside the control plane. Cloud providers will respond by deprecating long-lived service account tokens by default, forcing adoption of workload identity federation. However, the real game-changer will be AI-driven runtime detection – models trained on normal API call sequences from each service account will flag anomalies (e.g., a frontend pod suddenly listing all `Secret` objects) in milliseconds, enabling automated token revocation before lateral movement completes. Organizations that do not implement continuous RBAC auditing and short-lived tokens will face breaches as catastrophic as the 2025 crypto exchange heist, with losses exceeding $500M.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Our Research – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
