/
/

How to Monitor for Log4j Files Using NinjaOne

Custom-Fields-Blog-Banner-1

With news breaking re: Log4Shell (CVE-2021-44228) and exploitation attempts becoming widespread, MSPs and IT teams have been working nonstop to scope their exposure, scan for potential IoCs, apply mitigations, and patch.

The problem is, since this vulnerability affects so many applications — and because not every vendor has been able to provide clear advisory on whether their products are affected or not (note: NinjaOne is not) — determining what systems are potentially vulnerable is a big challenge.

That problem has led quite a few security researchers and community members to create scripts and tools that can be used to scan environments for potentially vulnerable Log4j files and signs of IoCs.

Examples include:

Deciding to utilize any of the available scripts out there is entirely up to you (always test and perform appropriate due diligence first, of course), but if you do find a script that you want to try this post will walk you through an example of how to deploy it across your network by leveraging custom fields in NinjaOne.

Before we dive in, if you’re looking to get up to speed on Log4Shell, the following are great resources:

Example of how to monitor for Log4j files using NinjaOne

To setup a custom monitor that detects the presence of Log4J library files on endpoints in Ninja, you’ll need:

  1. A custom field
  2. A script to collect and store the data (example below, or you can refer to other examples cited above)
  3. A custom condition to create an alert
  4. A method for deploying the detection script

Setting up the custom field

The custom field will be used to store data returned by the detection script.

1) Add a new custom field. Since we’ll be monitoring the result of the script on all endpoints, we’ll create a global custom field.

ninja-screen-log4j

2) The custom field will be named log4j and will be set to type Multi-line. We use multi-line as each endpoint may have multiple files with vulnerabilities. Multi-line will make this information more readable.

create-field-log4j

3) We then need to configure the custom field. We will set script Script Access to Read / Write.

Note: if script access is not set to ‘Write’ or ‘Read / Write’, you will not be able to write to this field from a script.

text-log4j

This is all that is required to setup the custom field if we are setting up a global custom field.

Creating a script to pull data

For illustrative purposes, we’ll use an example script below fashioned off Kelvin Tegelaar’s script provided on CyberDrain and in the NinjaOne Community Dojo. The primary difference with Kelvin’s script is that it uses an external tool called “Everything” that can make it faster to run.

Please note that there are additional scripts circulating that you can also refer to and customize  including:

These may provide faster, more efficient results.

*** Disclaimer: Use of any of these scripts in Ninja is done at your own discretion and risk. ***

$array = @()
$Drives = Get-PSDrive -PSProvider 'FileSystem'

foreach($Drive in $Drives) {

$drivePath = $Drive.name + “:”,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
$array += gci $drivePath -rec -force -include *.jar -ea 0 | foreach {select-string “”JndiLookup.class”” $_} | select -exp Path”

You might also like

Ready to simplify the hardest parts of IT?