AccuKnox embodies robust container security and forensic capabilities, leveraging KubeArmor’s
continuous monitoring and policy enforcement. It provides detailed insights, real-time alerts, and an
audit trail for proactive identification and mitigation of security threats within Kubernetes environments.

Attack Scenario: Unauthorized Data Access Attempt

• Objective: An external attacker gains unauthorized access to the Kubernetes cluster and attempts to exploit vulnerabilities within any pod to access sensitive files across the cluster.
• Attack Steps:
  a. Initial Access: The attacker gains access to the Kubernetes cluster, potentially through a compromised user account or exploiting a vulnerability in a service.
  b. Pod Identification: The attacker looks for vulnerable pods across the cluster to exploit. They scan for pods that might have misconfigured security settings or outdated software susceptible to exploitation.
  c. File Access Attempts: Within the compromised pod(s), the attacker attempts to access sensitive files or directories across the cluster. They might try to access /etc/passwd, /var/log , or other critical system files to gather sensitive information.
  d. Network Reconnaissance: The attacker tries to establish unauthorized network connections or initiate network scans from within the compromised pod(s) to explore the cluster’s network architecture, potentially looking for other vulnerable pods or services.
  e. Process Manipulation: Unauthorized execution of processes or commands within compromised pods to gain further control, escalate privileges, or perform malicious activities.
• Detection and Forensic Analysis:
  1. Continuous Monitoring: The Kubernetes environment is continuously monitored. Alerts are triggered for any suspicious activities or violations, such as unauthorized file access, unusual network connections, or prohibited processes executed within pods.
  2. Aggregated Logging: Logs from various pods across the cluster are aggregated and monitored for deviations from expected behavior, indicating potential security breaches.
  3. Forensic Analysis: Security analysts or forensic experts analyze the aggregated logs and triggered alerts to identify the attacker’s actions, determine the extent of the compromise, and assess the potential impact on the cluster’s security.
• Alert and Response:
  1. Policy Violation Alerts: Alerts are generated for any policy violations detected, such as unauthorized file access, unauthorized network connections, or prohibited processes running within pods.
  2. Response Actions: The security team investigates the alerts, isolates compromised pods, assesses the scope of the breach, applies necessary security patches, or rolls back affected pods to a secure state.
• Outcome and Learnings:
  1. Resolution: The security incident is addressed, unauthorized access is revoked, and necessary security measures are reinforced to prevent similar attacks in the future.
  2. Lessons Learnt: The incident underscores the significance of continuous monitoring, policy enforcement, and forensic analysis to detect, respond to, and recover from security breaches within Kubernetes clusters, emphasizing the importance of securing all pods uniformly.

This scenario illustrates an attack where an adversary gains access to the Kubernetes cluster and
attempts to exploit vulnerabilities within pods, leading to unauthorized file access, network
reconnaissance, and process manipulation across the cluster. The response involves forensic
analysis, containment, and remediation to secure the compromised environment.

To continuously monitor the configuration drift o your application and get aggregated summary of your application behavior (network connections, system calls)

Application logs can be seen for every pod and the same can be seen in the following way

By using the following command:

karmor logs –logFilter=all -n default

Files accessed:

ClusterName: default
HostName: cybersec
NamespaceName: default
PodName: ubuntu-64779dc6dd-nssmr
Labels: app=ubuntu
ContainerName: ubuntu
ContainerID: 820ba60d12dc858242fc3cc7a21deeb02e676697ebd78254226d5d58b140fcb7
ContainerImage: docker.io/library/ubuntu:xenial@sha256:1f1a2d56de1d604801a9671f301190704c25d604a416
Type: ContainerLog
Source: /bin/bash
Resource: /bin/cat full
Operation: Process
Data: syscall=SYS_EXECVE
Result: Passed
HostPID: 94795
HostPPID: 93473
Owner: map[Name:ubuntu Namespace:default Ref:Deployment]
PID: 207
PPID: 7
ParentProcessName: /bin/bash
ProcessName: /bin/cat
UID: 0

Network Connections Application is making

ClusterName: default
HostName: cybersec
NamespaceName: default
PodName: ubuntu-64779dc6dd-nssmr
Labels: app=ubuntu
ContainerName: ubuntu
ContainerID: 820ba60d12dc858242fc3cc7a21deeb02e676697ebd78254226d5d58b140fcb7
ContainerImage: docker.io/library/ubuntu:xenial@sha256:1f1a2d56de1d604801a9671f301190704c25d604a416
Type: ContainerLog
Source: /bin/ping google.com
Resource: sin_addr=10.43.0.10 sa_family=AF_INET sin_port=53
Operation: Network
Data: syscall=SYS_CONNECT fd=4
Result: Passed
HostPID: 95533
HostPPID: 93473
Owner: map[Name:ubuntu Namespace:default Ref:Deployment]
PID: 378
PPID: 7
ParentProcessName: /bin/bash
ProcessName: /bin/ping
UID: 0

Processes that are executed:

ClusterName: default
HostName: cybersec
NamespaceName: default
PodName: ubuntu-64779dc6dd-nssmr
Labels: app=ubuntu
ContainerName: ubuntu
ContainerID: 820ba60d12dc858242fc3cc7a21deeb02e676697ebd78254226d5d58b140fcb7
ContainerImage: docker.io/library/ubuntu:xenial@sha256:1f1a2d56de1d604801a9671f301190704c25d604a416
Type: ContainerLog
Source: /bin/bash
Resource: /usr/bin/dircolors -b
Operation: Process
Data: syscall=SYS_EXECVE
Result: Passed
HostPID: 93482
HostPPID: 93481
Owner: map[Name:ubuntu Namespace:default Ref:Deployment]
PID: 16
PPID: 15
ParentProcessName: /bin/bash
ProcessName: /usr/bin/dircolors
UID: 0

These logs can be further investigated to determine the processes, files, and connections made by
the attacker, aiding in forensic analysis and facilitating root cause identification.