Identify Log4j vulnerabilities in minutes with New Relic One and Lacework

At this point, I’m sure you’ve heard about the log4shell zero-day enough to make you consider whether you should just give up on logging entirely. And while the popularity is probably justified due to the pervasiveness of log4j, it’s a story that I don’t think needs another 101 rehash. With that in mind, I’m going to skip over the detailed explanation of what log4shell is and how it works, but if that is where you’re at in your learning, check out this recommended Lacework post for a great overview before you continue. 

Let’s get into how the New Relic and Lacework integration can help you identify and track both if you’re vulnerable to this attack and (even cooler, in my opinion) whether or not you’ve already been compromised. The first thing to consider is that this integration, and Lacework’s approach to security in general, isn’t dependent on this being a massively popular zero-day. Often when a new, scary exploit is first announced, you’ll see security vendors scrambling to add new capabilities to their tools to discover just that very specific thing.  

The challenge is that popularity doesn’t inherently equal severity. Yes, you may be running a vulnerable version of log4j and yes, the masses are out in droves looking to exploit that particular hole, but the truth is you always have something vulnerable running in your app stack. It's true whether you know it and its accepted risk, or the vulnerability just hasn’t been discovered yet. Right now, given someone has the time and the resources, you could be hacked. Lacework saw log4shell as just another potential hole into your systems. Our tools are built around finding anomalies, not finding very specific hardcoded attacks. That means our integration with New Relic One didn’t need to change or be updated to help with log4shell, it's ready to use now. We’ll continue to offer this same level of protection for whatever the next variant of log4shell ends up being. 

What you’ll need to get started 

I’m a firm believer that what it takes to set an integration up is as important as what you get for it in the end. Thankfully you need minimal setup, and it's only minutes away for existing Lacework and New Relic customers. 

Here’s what it takes to set up: 

1. Make sure you have New Relic One and Lacework accounts. 
   • Sign up for a free forever New Relic account or log in to your existing account.
   • Sign up for a free Lacework account.
2. Plumb the Lacework anomaly and prevention detections into the New Relic One database. For instructions, see the Lacework documentation about forwarding alerts to New Relic.
3. Install the Lacework Integration quickstart:
   • If you have already signed into New Relic One, you can access the quickstart directly in New Relic One.
   • Click Install this quickstart and follow the installation path.

Now you're ready to identify security anomalies with Lacework in New Relic One!

Gauging risk of log4shell exploits with Lacework

Let’s start with what most people want to know first: "Am I susceptible to this attack?" The slightly more technical version of that question is: "Am I running a Java application that is dependent on a vulnerable version of log4j and doesn’t already have mitigations in place?" There’s definitely nuance here, such as how you consider host versus container processes, check recursive dependencies, or just scan things efficiently without causing performance issues. 

But, generally speaking, the high-level algorithm for finding out whether a log4shell vulnerability is present is: 

• Find all the Java applications/containers.
• Find their list of dependencies.
• Check that list to see if any are vulnerable.
• Report that in a pretty, searchable list.

This screenshot shows the container vulnerabilities UX. I have a filter applied for a specific log4shell CVE ID (44228) which has led me to a particular container image with seven running instances (a_normal_java_service:latest). A side card shows more details about the CVE and the container. From here I’d go through each item in the list, apply the suggested mitigations or remove dependencies as needed, and then come back to confirm that the vulnerability is no longer on the naughty list.

Now that you see how Lacework can help you gauge whether you are susceptible to log4shell exploits, let’s take it one step further and determine how to identify exploits in New Relic. 

Using Lacework's quickstart in New Relic One to discover if you’ve been compromised by log4shell

This is where the rubber meets the road. Discovering whether or not you could potentially be hacked is a simple enough problem, but after discovering that you are vulnerable, how do you verify whether or not you have been hacked already?

This is where Lacework shines because as mentioned earlier, we aren’t following the standard trend of hardcoding very specific details about this very specific attack into our platform, such as looking for the jdni:// protocol prepend on network connections. Instead, Lacework is constantly baselining everything about your systems, including users, apps, connections, and more, resulting in a unique model of what’s normal for your business. We also let you know when we see something that we’ve never seen before. Because log4shell attacks are variable (they can occur on any port or contain any payload), this takes a lot of the burden off of you and your team. 

While Lacework can certainly manifest this data within our own interface or APIs, let’s also look at it through the lens of the New Relic One integration:

The Lacework Anomaly Detections dashboard, which is generated by the Lacework quickstart in New Relic One, shows you all Lacework-discovered security anomalies from within NRDB. This makes it easy to marry this data to existing observability dashboards you might have.

Next, simply use the dashboard’s standard filter capability to search across all the events that contain the term log4j over the last month.

When the software discovers a vulnerable version of log4j’s presence within an application or container, it automatically considers that information when that app does anything new. Lacework also surfaces anything extra suspicious that may have been exploited as well, showing that information in UX, alerts, and integrations.

Sure enough, this example shows three anomalies have been detected containing that specific string for this account. I can continue this high-level investigation into a contextualized space within the Lacework interface by simply clicking the event links under the Security Events table to see what the attacker did next. Powerful stuff!

The following diagram shows some of that data within Lacework. 

Everything highlighted in red was new for this particular hour. There were two instances of this container running and one was tricked into talking to this fake corpldap server and seemingly downloaded a known cryptominer (xmrig) from Github. The details of what it did are somewhat arbitrary, but the important thing to consider is that it shows up here because we identified this app as having the log4shell vulnerability present and having made unusual anomalous connections. There are many more robust details that can answer more questions, but you can experience them yourself with your own installation!

This is just an anecdotal example of how Lacework’s quickstart in New Relic Instant Observability works to help with log4shell discovery and intrusion detection. When the next zero-day in the not-so-distant future comes around, these same capabilities will be relevant because they aren’t specific to log4j but sniff out the primitive behaviors that comprise an attack such as new processes, new network connections, and more. The Lacework quickstart takes only minutes to get set up for existing New Relic and Lacework customers, so try it out. Maybe you’ll sleep a little easier when the next ‘attack of the week’ comes rearing its ugly head!