How to Monitor for Log4j Files Using NinjaOne

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:

• Huntress Log4Shell Vulnerability Tester
• Kelvin Tegelaar's Detecting Log4j Files script
• Jan Scholte's Ninja-Log4shell-Scanner
• get-log4jrcevulnerability.ps1 by Prejay Shah
• Datto Log4Shell Enumeration, Mitigation, and Attack Detection Tool
• Log4j/Log4Shell PowerShell Scan designed for use with Ninja from AshtonSolutions
• Rob Fuller's  CVE-2021-44228-Log4Shell-Hashes
• Florian Roth's log4shell-detector (which detects exploitation attempts NOT vulnerable applications

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:

• Fantastic explanation of Log4Shell by John Strand at Black Hills Information Security
  • Skip ahead to the part where he talks about mitigations here
• Good overview of Log4Shell with regular updates from Huntress
• Log4j vulnerability guidance from CISA

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.

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.

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.

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:

• Jan Scholte's Ninja-Log4shell-Scanner
• get-log4jrcevulnerability.ps1 by Prejay Shah

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
}

If ($array -ne $null) { $array += “Possible Threat Detected”}

Ninja-Property-Set log4j $array

Ninja-Property-Set is Ninja’s Powershell command to set a custom field to a specific value. The syntax is:

Ninja-Property-Set fieldName Value

In this case, we are setting the log4j field to the value stored in the variable $array.

Adding this script to Ninja is easy.

1) Navigate to ‘Configuration’ -> ‘Scripting’

2) click ‘Add a new script’

3) Copy the code above into the IDE

• If your custom field is not named ‘log4j update the field name next to Ninja-Property-Set

4) Set the script’s parameters to

• Name: Log4J Detection
• Language: PowerShell
• Operating System: Windows
• Architecture: All

5) Save the script

Setting up the monitor

Conditions in Ninja are used to monitor for state changes in an endpoint. Ninja includes the ability to monitor custom fields. We’ll setup a monitor to alert based on the results returned to our Log4J field.

1) In your policy of choice, navigate to conditions, and click ‘Add a condition’

2) Select condition type ‘Custom Fields’

3) Under ‘Custom field value must meet any conditions’ select ‘Add’ and search for ‘Log4J’

4) Set selector to ‘contains’ and add ‘Possible Threat Detected’

5) Set any severity, priority, notification channel, and ticketing settings to your preferences, and click ‘Add’.

6) If you have integrated your PSA or are using Ninja Ticketing, you can also create a ticket via the condition

Deploy the script

The final step in this process is to run the script. You can run the script:

• Ad-hoc on individual devices via the script library
• Ad-hoc across multiple online devices via the search function
• Automatically via scheduled tasks
• Automatically via policies

See what else you can accomplish by utilizing custom fields in NinjaOne

This is just one example of how using custom fields in NinjaOne can help you deploy custom monitoring and powerful automation. We're starting a new series dedicated to sharing other examples, and you can see the first post here.