Why NDR is essential to protecting your cloud workloads

How Corelight Open NDR secures cloud workloads beyond runtime security tools.

Introduction: NDR in the cloud

Cloud security tools often come wrapped in acronyms—CSPM, CWPP, CNAPP—that can feel overwhelming to navigate. Each category tackles a distinct challenge: CSPM solutions focus on misconfigurations in your cloud control plane, CWPP offerings protect workloads such as containers and virtual machines at runtime, while CNAPP platforms aim to unify both posture management and workload protection under one umbrella. Despite their strengths, these tools rely heavily on cloud API data, host-level monitoring, and configuration checks, which can leave blind spots in monitoring actual network traffic.

Because malicious actors still rely on the network to move laterally, exfiltrate data, or communicate with external systems, many attacks go undetected if you’re only watching the control plane or host-based telemetry (A recent CISA advisory about over-reliance on EDR tools emphasized this reality). This is where Network Detection and Response (NDR) steps in with deep, packet-level visibility and threat detection capabilities that complement and extend existing cloud security stacks. Even if attackers circumvent runtime agents or exploit misconfigurations that slip past your CSPM scans, they cannot hide from network-level monitoring.

Why Network Detection and Response (NDR) is critical in the cloud

The cloud, like on-premises deployments, benefits from combining NDR data with container runtime visibility and logs such as CloudTrail to achieve defense-in-depth. By analyzing actual network traffic, security teams can address critical gaps not captured by typical cloud or container logs, and ultimately gain a more comprehensive understanding of what transpired within the environment.

Corelight collects detailed network metadata (e.g., HTTP headers, DNS queries, SSL certificates and ciphersuites, bytes transferred) and tracks network sessions, bridging blind spots between container runtime events. Corelight also enriches cloud traffic observed with additional metadata through our Cloud Enrichment and cloud app ID packages:

In a situation in which a Network TAP isn’t available, cloud VPC flow logs can be ingested by Corelight. Because these tools often only capture minimal network information (such as the 5-tuple), Corelight’s enriched data helps investigators correlate suspicious or anomalous traffic with specific cloud actions, account movements, and container processes—leading to faster, more accurate threat detection and response.

Example: Detecting container runtime security tool bypasses with NDR

In Kubernetes, Role-Based Access Control (RBAC) is a critical security feature used to regulate access to cluster resources. Properly configured RBAC policies ensure that users and applications have only the permissions they need, minimizing the risk of unauthorized access. However, misconfigurations in RBAC can lead to privilege escalation, allowing attackers to gain unauthorized administrator rights. Once an attacker gains administrative privileges, they can manipulate critical components, including security configurations and monitoring tools.

Container runtime security tools like Falco are often deployed as DaemonSets across Kubernetes clusters. For those that may be unfamiliar with them, a DaemonSet in Kubernetes ensures that a specific pod (containerized application) runs on every node (or a subset of nodes) in the cluster. These tools monitor node-level activity, detecting anomalies and potential threats by inspecting system calls and other low-level operations within containers. This approach allows a single container per node to collect the necessary telemetry, avoiding the overhead of running security tools in every individual container. Without a DaemonSet, scaling applications rapidly could lead to significant resource overhead as each instance would require its own monitoring container.

However, just as Endpoint Detection and Response (EDR) agents can be blinded on endpoints using tools like EDRSilencer, container runtime security tools can be bypassed. A malicious actor with administrative privileges can modify or disable the DaemonSet configurations in your cluster, effectively preventing these security tools from monitoring workload runtime activity.

How NDR mitigates RBAC gaps and misconfigured Kubernetes environments

Overly permissive RBAC settings — such as granting the cluster-admin role to default service accounts — can open the door for attackers to exploit vulnerabilities within a Kubernetes environment.

An attacker who gains access to a compromised pod can manipulate network policies or namespace settings to suppress the outbound communication of security tools deployed as DaemonSets. This effectively blinds the runtime security tools, preventing them from sending alerts or logs to monitoring systems.

Sophisticated runtime tools do allow you to see traffic even from new containers spun up by an attacker, providing visibility into malicious activities that might otherwise go unnoticed. Attackers can disable logging by exploiting misconfiguration. But because they can't wipe out what is happening in your network, NDR can provide visibility into malicious activities by monitoring network-level interactions. It provides a critical complement to runtime security tools by offering an additional layer of detection, similar to its role in on-premise environments.

Deep dive example: Anatomy of a cloud workload attack

Let’s illustrate these points through the lens of an older, but notable, vulnerability: CVE-2018-1002105, which allowed unauthorized users to escalate privileges within Kubernetes clusters. Attackers could leverage such vulnerabilities to manipulate namespaces in managed Kubernetes environments.

Attack execution scenario

In this scenario, an attacker may start by compromising a container in your cluster through a vulnerable application or a supply chain attack. Once inside, they exploit misconfigured RBAC policies to escalate privileges. For example, if a service account has excessive permissions, the attacker can use it to gain cluster-admin rights:

1. Identify Service Account Tokens. The attacker searches for service account tokens mounted in the pod:

    
     

ls /var/run/secrets/kubernetes.io/serviceaccount/
    
  

2. Access the API server. They use the token to interact with the Kubernetes API server.

    
     
 
export TOKEN=$(cat
/var/run/secrets/kubernetes.io/serviceaccount/token); curl -k -H
"Authorization: Bearer $TOKEN"
https://kubernetes.default.svc.cluster.local
 
    
  

3. Create a ClusterRoleBinding. They apply a new ClusterRoleBinding to grant themselves cluster-admin privileges. The below would be run on the compromised container:

    
     
 
kubectl apply -f - <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
metadata:
   name: attacker-binding
subjects:
    - kind: User
    name: attacker
    apiGroup: rbac.authorization.k8s.io
roleRef:
    kind: ClusterRole
    name: cluster-admin
    apiGroup: rbac.authorization.k8s.io
EOF
 
    
  

4. Abuse Kubernetes namespaces to blind Falco. With elevated privileges, the attacker manipulates network policies or Kubernetes namespaces to isolate security DaemonSets like Falco from the rest of the cluster. By altering the network configuration, they prevent Falco from receiving or transmitting the necessary data to monitor container activities.

(For example, the attacker might alter the network policies to restrict traffic to and from the Falco pods, effectively silencing them.)

Modifying Kubernetes namespace configurations. The attacker can also alter Kubernetes namespace settings to isolate Falco from other namespaces, preventing it from accessing necessary system resources or communicating with the rest of the cluster.

    
     
 
apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
  metadata:
   name: block-falco-traffic
   namespace: falco-namespace
  spec:
   podSelector:
    matchLabels:
     app: falco
    policyTypes:
    - Ingress
    - Egress
    ingress: []
    egress: []
 
    
  

5. Deploy malware/attack tools. Once Falco is blinded, an attacker deploys malware to run within your cluster, such as XMRig or other cryptominers.

By applying such configurations, the attacker effectively silences Falco, preventing it from sending alerts or logs to monitoring systems and hindering its ability to detect malicious activities.

However — similar to an on-premise situation — deploying network detection and response solutions in the cloud provides multiple potential detection opportunities, even when runtime security tools are blinded.

For example, in a supply chain attack involving container images, Sysdig found that coinminers are among the most common types of malicious content. The nature of coinmining requires the malware to communicate the results of its mining to the rest of the mining pool. This makes it detectable on the network, as a surprisingly large amount of XMR and other coinmining traffic happens in the clear, as seen in the image below:

If the traffic is encrypted, monitoring indicators such as the TLS Server Name Indication (SNI) for known cryptomining pool domains, or DNS requests made to get the addresses to the mining pool servers (as seen above) can still reveal the coinmining.

At the time of writing, Corelight has over 100 rules to detect activity just like this, such as the examples below:

    
     
 
ET INFO DNS request for Monero mining pool
ET MALWARE Observed CoinMiner Domain (pool .supportxmr .com in TLS SNI)
ET MALWARE Observed CoinMiner Proxy Domain (xmrminingproxy .com in TLS SNI)
    
  

When combined, CloudTrail and Corelight logs allow security teams to form a complete picture:

• CloudTrail reveals any unauthorized changes to container deployments (e.g., launching new, potentially malicious container images) or cloud infrastructure (e.g., security group modifications to allow inbound connections).
• Corelight uncovers the actual traffic patterns, pinpointing signs of cryptomining or other malicious communications that indicate a successful compromise, regardless of whether runtime monitoring tools like Falco have been disabled.

By correlating CloudTrail events with Corelight’s network-level data, defenders can quickly identify who initiated the suspicious activity and how that activity manifested on the wire. This layered approach ensures that even if attackers succeed in blinding your runtime security tools, you still have robust visibility into anomalous network behavior, keeping your cloud environment both transparent and secure.

Conclusion

As demonstrated, monitoring the network traffic within your cloud environment is just as crucial as monitoring your on-premises systems. Attackers can exploit namespace misconfigurations and RBAC weaknesses to blind runtime security tools like Falco, leaving your cluster vulnerable to malicious activities.

By implementing robust network security monitoring solutions, such as Corelight’s Open Network Detection and Response platform, you can gain essential, comprehensive visibility into your Kubernetes clusters.