Suspicious OpenSSL and setcap activity on AKS node

We recently observed a suspicious sequence of process executions on one of our AKS nodes and would like guidance on determining whether this is part of legitimate system or monitoring activity, or a potential compromise attempt.

Event Details

Date/Time (UTC): November 7, 2025, 03:41:58

Cluster / Node: aks-sharedpool-29290947-vmss00000X

Process observed:

openssl s_client -quiet -connect 10.136.5.208:10250

Parent process:

wget --server-response https://10.136.5.208:10250/stats/summary \
--no-check-certificate \
--header="Authorization: Bearer <token>"

Subsequent activity (within seconds):

setcap cap_sys_ptrace,cap_dac_read_search+ep /usr/bin/ruby
cat /var/run/secrets/kubernetes.io/serviceaccount/token

The OpenSSL call appears immediately after the wget request to the kubelet stats endpoint. Soon after, the Ruby binary was modified to grant system-level capabilities (SYS_PTRACE and DAC_READ_SEARCH), followed by access to a service account token.

These actions were traced to the following pod context:

Namespace: kube-system

Pod: ama-logs-rs-5c4c5975b5-87cp4

Service account: ama-logs

GreyMatter (our monitoring platform) flagged this as suspicious since this behavior could potentially indicate privilege escalation or service account token exposure.

Questions

• Could these activities be part of any legitimate AKS or Azure Monitor (ama-logs) operations?
• Does the ama-logs or azuremonitoragent DaemonSet ever invoke openssl s_client or modify binary capabilities?
• What is the best practice to verify if this originated from a compromised pod versus a legitimate process?