It then updates a lookup table containing these domains that we will use in a follow on search. The first search utilizes regular expressions to extract the domains within the JNDI string. How can we correlate this to a successful probe? DNS to the rescue. We identified detections for JNDI strings that could indicate attempts to exploit the Log4j vulnerability. | convert ctime(earliest_time) ctime(latest_time)Ĭorrelation of JNDI Probes with DNS Queries | tstats earliest(_time) as earliest_time latest(_time) as latest_time values(All_st_ip) from datamodel=Network_Traffic.All_Traffic where All_st_port = 1389 OR All_st_port = 389 OR All_st_port = 636 AND NOT (All_st_ip = 10.0.0.0/8 OR All_st_ip=192.168.0.0/16 OR All_st_ip = 172.16.0.0/12) by All_Traffic.src_ip This search will help determine if you have any LDAP connections to IP addresses outside of private (RFC1918) address space. Here is a search leveraging tstats and using Splunk best practices with the Network Traffic data model. This could be an indication of Log4Shell initial access behavior on your network. Should outbound LDAP traffic be allowed through your perimeter firewall? Probably not. | table _time, dest_ip, alert.signature, alert.signature_idĭetecting Outbound LDAP Access on Your Network A quick search against that index will net you a place to start hunting for compromise: In this case, we are using Suricata but this holds true for any IDS that has deployed signatures for this vulnerability. Make sure you’ve updated your rules and are indexing them in Splunk. Using Splunk to Detect Potential Log4Shell (Log4j 2 RCE) Exploitation Intrusion Detection Alertsĭon’t forget about your investments in IDS across your environment. Let’s take a look at how these two data sources can help us find compromised hosts in our environment. We can use two key data sources here: Network Traffic and DNS query logs. What if you aren’t logging that information? Well, phase 3 would be a very good place to start hunting.
Most of our detections have centered around steps 1 and 2, where the adversary makes the initial JNDI request to the vulnerable server. The diagram includes some key search areas: The Swiss CERT published a helpful blog containing a diagram that outlines the various stages of this exploit. There are other areas for you to investigate to find out if your hosts have been targeted. If you haven’t already been logging everything needed to detect the initial exploitation, you are still in luck.
Splunk log4j how to#
In this blog, we provide additional guidance on how to help detect potential exploitation in your environment.
Splunk’s SURGe team provided an initial blog and security advisory for Splunk products in relation to Log4Shell, a Log4j vulnerability that’s been keeping blue teams up at night. Credit to authors and collaborators: Ryan Kovar, Shannon Davis, Johan Bjerke, James Brodsky, Dave Herrald, John Stoner, Drew Church, Mick Baccio, Jay Holladay, Lily Lee, Audra Streetman, Tamara Chacon.
For additional resources, check out the Log4Shell Overview and Resources for Log4j Vulnerabilities page.Īuthors and Contributors: As always, security at Splunk is a family business. This blog is a part of Splunk's Log4j response.
0 kommentar(er)
