Detecting CDK Attacks with Kubernetes Audit Logs: Practical Rules and Pitfalls

Introduction

Container‑focused penetration testing tools such as github.com/cdk-team/CDK automate information gathering, lateral movement, privilege escalation and persistence in Docker/Kubernetes environments. Because container exploitation is inexpensive, security teams should complement runtime detection with API‑server audit logging to identify early signs of intrusion.

Kubernetes Audit Logging Overview

Kubernetes audit logs record chronological events generated by users, service accounts or system components. Typical fields include requestURI, verb, userAgent and responseStatus.code.

Enabling Audit Logging

Add the following flags to the kube-apiserver command line (or to the static pod manifest /etc/kubernetes/manifests/kube-apiserver.yaml):

--audit-policy-file=/etc/kubernetes/audit/audit-default-policy.yaml
--audit-log-path=/data/log/audit/audit.log
--audit-log-maxbackup=10
--audit-log-format=json
--audit-log-maxage=10
--audit-log-maxsize=500

Detecting Attack Behaviors

Analysis Flow

When an attacker obtains a container shell, CDK performs reconnaissance against the API server, then proceeds to exploitation, privilege escalation and persistence. Monitoring audit logs can reveal:

Information‑collection requests

Exploitation attempts (privileged pod creation, secret access, etc.)

Privilege‑escalation actions

Persistence mechanisms (DaemonSet, CronJob, shadow API‑server)

Information Collection

CDK typically issues three API‑server requests during reconnaissance:

GET /

GET /apis

GET /api/v1/namespaces

Example audit entry for the root request:

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "stage": "ResponseComplete",
  "requestURI": "/",
  "verb": "get",
  "user": {"username": "system:anonymous","groups": ["system:unauthenticated"]},
  "sourceIPs": ["172.18.0.2"],
  "userAgent": "Go-http-client/1.1",
  "responseStatus": {"status": "Failure","reason": "Forbidden","code": 403},
  "requestReceivedTimestamp": "2023-02-02T08:29:12.189459Z",
  "stageTimestamp": "2023-02-02T08:29:12.189553Z"
}

Key detection fields: userAgent = Go-http-client/1.1, responseStatus.code = 403, requestURI = /.

Exploitation Modules

Container Escape : Privileged pod creation leaves audit entries such as requestURI: /api/v1/namespaces/.../pods, verb: create, with securityContext.privileged = true or capabilities.add = ["SYS_ADMIN"].

Network Scanning : No API interaction, therefore no audit logs.

Data Theft : Access to /api/v1/secrets, /api/v1/configmaps or /apis/policy/v1beta1/podsecuritypolicies. Typical entries show responseStatus.code = 403 when using an anonymous account.

Privilege Escalation : RBAC bypass attempts generate requestURI: /api/v1/namespaces/kube-system/pods with verb: create and either 403 (denied) or 201 (created) depending on the service account rights.

Persistence :

DaemonSet backdoor – audit fields include objectRef.name: cdk-backdoor-daemonset, responseObject.spec.template.spec.volumes.hostPath.path: /, and privileged security context.

CronJob backdoor –

requestURI: /apis/batch/v1beta1/namespaces/kube-system/cronjobs

, verb: create, objectRef.name: cdk-backdoor-cronjob.

Shadow API‑server – detectable via objectRef.name: *-shadow-* and command arguments such as --secure-port=9444.

Detection rules often combine userAgent, responseStatus.code and specific requestURI patterns.

API Utilization (kcurl)

The kcurl module uses a high‑privilege service account to list resources. Example audit entry for a successful node list:

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "requestURI": "/api/v1/nodes",
  "verb": "list",
  "user": {"username": "system:serviceaccount:test:default"},
  "userAgent": "Go-http-client/1.1",
  "responseStatus": {"code": 200},
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"defaultadmin\" ..."
  }
}

Rule example: flag entries where userAgent = Go-http-client/1.1 and responseStatus.code = 403 (unauthorized) or 200 with an allow annotation (potential misuse).

Beyond CDK

CVE‑2022‑3172 (Kubernetes Aggregation API SSRF)

The Aggregation API can redirect client requests to arbitrary URLs, leaking credentials. Detect redirection via audit fields responseObject.code = 301 or 302.

Use of Unapproved Images

Monitor requestObject.spec.containers.image for images pulled from public registries when only private registries are expected.

Pod Exec Commands

Audit entries with objectRef.subresource = exec or attach indicate kubectl exec usage; combine with userAgent for richer context.

Practical Pitfalls

Inconsistent field types cause indexing errors in Elasticsearch; consider shallow parsing or alternative storage (e.g., HDFS) for heterogeneous objects.

High log volume can overload the API server I/O. Tune the audit policy to exclude noisy resources such as node/status, pod/status and coordination.k8s.io/leases.

Conclusion

API‑server audit logs provide reliable evidence of CDK‑style attacks. By defining concise detection rules around userAgent, requestURI and responseStatus.code, security teams can automate alerts and optionally apply machine‑learning models for higher accuracy. Strengthening baseline controls—limiting privileged service accounts, enforcing image policies, and deploying runtime intrusion detection—remains essential for robust Kubernetes security.