Long Arrow Right External Link angle-right Search Send Times Loader chevron-down thumb-up thumb-down Spinner angle-left
Go to ThreatLocker

Log4J Vulnerability

View in Browser

Updated: Friday, December 17, 2021

ThreatLocker has created a custom report that you can run to check your Applications to see if they contain any of the vulnerable Log4j files.  

Please note: Having any of these Log4j files does not automatically mean that they are exploitable. In order to be exploited, attackers would need to be able to interface with the vulnerable Application.

Running the ThreatLocker Report that scans for any Applications that contain the vulnerable Log4j files 

  • From the ThreatLocker Portal, navigate to the Reports Page.    
  • In the Category dropdown, select Log4j.
  • In the Report dropdown, select 'Applications containing old Log4j files'.
  • Click the 'Generate' button. A list of Applications that contain the old, vulnerable Log4j files will be populated.

Applications that are found to contain any of the vulnerable old Log4j files can have their Policies set to Ringfence interaction with PowerShell, Command Prompt, File Access, and Internet Access. When setting up a new Ringfencing Policy, you need to set the Policy to 'Monitor Only'. Failure to set the Policy to Monitor Only can cause the Application to stop working and can create work blocks. For more information on applying Ringfencing to an existing Application, see our associated article: https://threatlocker.kb.help/ringfencing-a-new-application.

If you would like assistance in configuring policies for any affected Applications to the least privilege possible, please click the 'Get Help From a Cyber Hero' button.

Updated: Tuesday, December 14, 2021

The Log4j vulnerability disclosed on December 9, 2021, potentially allows an attacker to run remote code if they can write a single log file.

ThreatLocker recommends that all applications that use Log4j or Log4Shell be updated immediately.

ThreatLocker does not use Log4j or Log4Shell in ANY internal or public-facing systems. We are working with our vendors for non-critical infrastructure to ensure that they are not using these systems.  

ThreatLocker's team is currently working to replicate exploits to better understand how Ringfencing and Application Whitelisting may prevent or limit exploits from using the vulnerability to cause additional damage.

Our current understanding is if Java and IIS are Ringfenced, the damage caused by the vulnerable applet will be limited by the Ringfencing Policy. If you need assistance with setting up Ringfencing Policies, please reach out to Cyber Hero Support.

There is no reason to believe that computers secured with Default Deny policies in place can run applications that are not permitted, regardless of whether those applications come from the vulnerability or not.

ThreatLocker will continue to update this article with more information as it becomes available. Our team is here to help partners identify potential issues and ensure configurations are the most secure.  

Please feel free to reach out to Cyber Hero Support if you have any questions.

Did this answer your question?
Thanks so much for your feedback!
%s of people found this helpful.