CONTACT US
forrester wave report 2023

Close your ransomware case with Open NDR

SEE HOW

ad-nav-crowdstrike

Corelight now powers CrowdStrike solutions and services

READ MORE

ad-images-nav_0013_IDS

Alerts, meet evidence.

LEARN MORE ABOUT OUR IDS SOLUTION

ad-images-nav_white-paper

5 Ways Corelight Data Helps Investigators Win

READ WHITE PAPER

glossary-icon

10 Considerations for Implementing an XDR Strategy

READ NOW

ad-images-nav_0006_Blog

Don't trust. Verify with evidence

READ BLOG

video

The Power of Open-Source Tools for Network Detection and Response

WATCH THE WEBCAST

ad-nav-ESG

The Evolving Role of NDR

DOWNLOAD THE REPORT

ad-images-nav_0006_Blog

Detecting 5 Current APTs without heavy lifting

READ BLOG

g2-medal-best-support-spring-2024

Network Detection and Response

SUPPORT OVERVIEW

 

Spotting Log4j traffic in Kubernetes environments

Editor’s note: This is the latest in a series of posts we have planned over the next several weeks where we explore topics such as network monitoring in Kubernetes, using sidecars to sniff and tunnel traffic, show a real-world example of detecting malicious traffic between containers, and more! Please subscribe to the blog, or come back for more each week.

In the first blog post in this series (Deeper visibility into Kubernetes environments with network monitoring) we showed how network monitoring solutions can overcome the security visibility blind spots in Kubernetes environments and in blog 2 (Sidecars for network monitoring) we looked at a specific example of using a sidecar-sniffer to sniff container-container traffic.

In this post, we demonstrate how the visibility of network traffic passing between pods and containers within the K8s network, can be utilized to detect a log4j exploit that occurred from a vulnerable Apache web application. 

This use case was adapted from the POC exploit found here: https://github.com/cyberxml/log4j-poc. The architecture of the log4j demo environment is as follows:

The demo environment contained 4 K8s pods.  Those pods where network traffic monitoring is required, have two containers, the service itself and vxlan.  The vxlan container encapsulates all network traffic to and from the pod into a vxlan and forwards that traffic to the sensor-core pod.  This traffic forwarding could also take place to an external network sensor.  

 

When the exploit starts, the attacker uses the web application, hosted on the Apache web app pod, to send the exploit string:

Screen Shot 2022-05-04 at 12.58.38 PM 

to the log4j POC listener.  

Screen Shot 2022-05-04 at 1.00.26 PM

In this scenario, a special listener was created that had vulnerabilities built in and would perform the ldap lookup using the ldap server pod.  Under normal circumstances, the traffic between the pods (ldap traffic in this case) would not be visible above the container system itself (e.g. to a higher level network sensor).  Having the per pod sensor in place forwarding all traffic to the sensor-core, we were able to detect the exploit and generate a zeek notice.log entry on the sensor-core pod.

Screen Shot 2022-05-04 at 1.01.48 PM

When this exploit succeeded, the call back from the ldap server provided a shell back to the attacker and the attacker was able to issue commands on the exploited pod.

Screen Shot 2022-05-04 at 1.02.26 PM

The C2 communications from the shell created during the exploit were also captured and logged within the  conn.log by the sensor-core pod.

Screen Shot 2022-05-04 at 1.03.03 PM

By Stan Kiefer, Corelight Security Product Researcher

 

Recent Posts