This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject

NetWitness Community

  • Home
  • Products
    • NetWitness Platform
      • Advisories
      • Documentation
        • Platform Documentation
        • Known Issues
        • Security Fixes
        • Hardware Documentation
        • Threat Content
        • Unified Data Model
        • Videos
      • Downloads
      • Integrations
      • Knowledge Base
    • NetWitness Cloud SIEM
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Detect AI
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Investigator
    • NetWitness Orchestrator
      • Advisories
      • Documentation
      • Knowledge Base
      • Legacy NetWitness Orchestrator
        • Advisories
        • Documentation
  • Community
    • Blog
    • Discussions
    • Events
    • Idea Exchange
  • Support
    • Case Portal
      • Create New Case
      • View My Cases
      • View My Team's Cases
    • Community Support
      • Getting Started
      • News & Announcements
      • Community Support Forum
      • Community Support Articles
    • Product Life Cycle
    • Support Information
    • General Security Advisories
  • Training
    • Blog
    • Certification Program
    • Course Catalog
      • Netwitness XDR
      • EC-Council Training
    • New Product Readiness
    • On-Demand Subscriptions
    • Student Resources
    • Upcoming Events
    • Role-Based Training
  • Technology Partners
  • Trust Center
Sign InRegister Now
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
NetWitness Community Blog
Subscribe to the official NetWitness Community blog for information about new product features, industry insights, best practices, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
  • NetWitness Community
  • Blog
  • Apache Log4j (‘Log4Shell’): Background and Detection Rules

Apache Log4j (‘Log4Shell’): Background and Detection Rules

Will_G
Moderator Will_G Moderator
Moderator
Options
  • Subscribe to RSS Feed
  • Mark as New
  • Mark as Read
  • Bookmark
  • Subscribe
  • Printer Friendly Page
  • Report Inappropriate Content
‎2021-12-11 09:02 PM

Apache Log4j (‘Log4Shell’): Background and Detection Rules

What We Know

 

It is important to recognize and understand that this vulnerability and the circumstances related to is exploitation globally are dynamic. As the NetWitness Threat Intelligence Team learns more about the threat(s) associate with Log4Shell, we shall update and share recommendations with our customer here, on this blog. Special thanks go out to our peer organization, the NetWitness Incident Response Team for their perseverance and dedication in serving our customers and sharing their insights with us as work toward providing the best recommendations and content for our customers worldwide. 

On December 09, a new vulnerability was disclosed and written about extensively by Apache that impacted the projects Log4j offering. MITRE created and published CVE-2021-44228 (the vulnerability was elevated to zero-day status and has a CVSS Score of 10 or ‘CRITICAL’), and the world waited with bated breath as reports of exploitation and attacks began appearing online. Credit for the discovery of the vulnerability in question was given to Chen Zhaojan, of the Alibaba Cloud Security Team. At the of initial publication, the vulnerability was thought to impact at least two versions of the code set – 2.0beta9 and 2.14.1, respectively. When exploited successfully, an attacker may succeed in achieving remote code execution (RCE)[i] thus enabling them to begin advance their efforts within the target and its environment. Post publication of the CVE by MITRE, Apache acted appropriately in addressing the vulnerability through publishing a patch in version 2.15.0 of Log4j. And despite the efforts of the Apache Project team work to mitigate the threats posed by the vulnerability, reports began flowing online within the threat research and incident response community, in addition to the press and world began mustering in order to brace itself and address threats known and unknown moving forward.

 

Global Impact

 

At the time of this update, we simply do not know just how many organizations worldwide, applications, packages, or platforms are at risk. However, we do know that due to the nature of the vulnerability (recall that the execution of arbitrary remote code is possible by an attacker is possible they successfully exploit the vulnerability), and the myriad number of interdependencies associated with, and related to log4j, the threat is real, and the gravity will likely not be fully realized for some time to come. Many are comparing this to the infamous ‘Heartbleed’ vulnerability (CVE-2014-0160) from April 7, 2014 (which maintains a base CVSS Score of 7.5 or ‘High’). However, it would appear that given the number of well known and heavily utilized applications and platforms impacted by Log4Shell, this is not a fair comparison and Log4Shell may be far worse in the long run. Here is a concise list of impacted applications, platforms, and vendors to illustrate that point:

  • Various Apache projects (e.g., Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark, Struts, Tapestry, Wicket)
  • Elastic Search and LogStash
  • GrayLog2
  • Neo4j
  • Various VMWare products
  • Minecraft client and server
  • And many more

 

What You Can and Should Do to Address and Mitigate Threats Related to CVE-2021-44228

 

The first place to begin with respect to addressing CVE-2021-44228 involves identifying any/all assets within your organization that may be susceptible to exploitation of this vulnerability. Begin by expediting the identification and analysis of all assets while making a concerted effort to identify shadow IT that may be susceptible to exploitation but not accounted for in traditional asset inventories and CMDBs. Once organizations who believe they may be impacted by the Log4j vulnerability have identified their assets, they should initiate the patching cycle. This should be done in observance of industry and organizational best practices for patching while adhering to guidance provided by vendors who produce applications and platforms impacted by the Log4j vulnerability. Additional attention should be given to communications from the Apache Project about updates to the Log4j project.

Furthermore, impacted organizations may wish to pursue the following courses of action in respect to their defensive strategies:

  • Update Firewall rules
  • Update IDS/IPS rules
  • Update any/all host-based endpoint protection platform solutions where appropriate
  • Block outbound connections from public facing servers, including DNS resolution of public domain names. This recommendation is a best practice that applies to this threat and other future threats. If there is a business need for these servers to communicate outbound it should be done via a whitelist of destinations.

 

How NetWitness Can Help You Detect for the Presence of the Log4j vulnerability and Log4Shell

 

NetWitness Network for Detection and Response Packets User Environments

 

The NetWitness Threat Intelligence and Product teams crafted and published three (3) application rules on Saturday, December 11, 2021. For customers using NetWitness Network for Packets, the following rules were designed to detect outbound communications associated exploitation of the Log4j vulnerability, especially when complimented with SSL interception technology for inbound/outbound traffic.

Application Rules

  • Rule Number 1: Application Rule for Detection of Outbound LDAP (Lightweight Directory Access Protocol) Communications
    • direction='outbound' && service=389

These two rules have been deprecated and are no longer recommended for use (please see the sentence directly below them for more information):

  • Rule Number 2: Application Rule for Detection of Outbound LDAPS (Lightweight Directory Access Protocol over SSL) Communications
    • direction='outbound' && service=636
  • Rule Number 3: Application Rule for Detection of Outbound RMI Registry Service Provider Communication
    • direction='outbound' && service=1099

As of today, Monday, December 13, 2021 rules 2 and 3 have been deprecated and are no longer being recommended due to questions related to their efficacy and potential performance.

In addition to these rules, we are attaching SNORT signatures and YARA rules developed by the team SOC PRIME team (SIGMA Rules Repository). These signatures will aid in detecting scans used by attackers in order to identify assets that are susceptible to the exploitation of the Log4j vulnerability using the original Proof of Concept.

Moreover, we recommend that impacted organizations look for and pay attention to suspicious behavior associated with impacted servers if a successful exploitation has occurred.  Behaviors to look for include but are not limited to the following:

  • Suspicious outbound connections from servers
  • Usual patterns of behavior associated with lateral movement including:
    • Reconnaissance
    • Credential Dumping and Privilege Escalation
    • Gaining Access

Additionally, two legacy NetWitness Packet Parsers have been augmented in order to provide our customers with broader detection capabilities related to the Log4j vulnerability/ Log4Shell exploits while a third new Packet Parser has been added to aid our customers in their hunts, detections & responses: 

  • DynDNS
    • Additional domains were included that have been associated with beaconing from compromised hosts/systems 
  • LDAP
    • Add ports commonly used by Oracle to hopefully detect more LDAP sessions: 1389, 1636, 4444, and 8989. Prior to this change, this parser only looked for sessions on ports 389 and 636.
  • RMI (Java Remote Method Invocation) 
    • Identifies Java Remote Method Invocation protocol

NetWitness Endpoint for Detection and Response User Environments

The NetWitness Threat Intelligence team recommends the application of the following endpoint rules for organizations impacted by the Log4j vulnerability:

  • HTTP Daemon Runs Reconnaissance Tool
  • HTTP Daemon Writes Executable
  • HTTP Daemon Runs Command Prompt
  • HTTP Daemon Runs PowerShell
  • Suspicious running processes on the affected servers

As we learn more, we will update this blog and share more insight and content with the community. If you have further questions, please feel to reach out to william.gragido@netwitness.com. 

Update(s):

  • Addition of a list of pointers to SNORT IDS Signatures that address CVE-2021-4428 
  • Attachment of three (3) packet parsers - two of which are legacy and have been augmented to address Log4j exploitation and one that is net new to address JRMI
  • Addition of a new app rule to useful in the detection of log4j exploit attempt that can lead to RCE(CVE-2021-44228) available in the 'Community' section of RSA NetWitness LIVE

Endnote(s): 

[1] this occurs when an attacker who has control of log messages or log parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. According to Apache this behavior is now disabled by default in version 2.15.0)

 

ldap.zip
dyndns.zip
rmi.zip
Labels:
  • Resources
  • Apache Log4j
  • Content
  • Detections
  • incident response
  • Threat Intelligence
  • Zero-Day
Preview file
17 KB
Preview file
102 KB
ldap.zip
dyndns.zip
rmi.zip
7 Likes
Share
6 Comments

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

  • Comment
Latest Articles
  • Microsoft Azure Log Analytics workspace integration with Netwitness
  • Cryptonite Ransomware
  • Deployment Inventory (Serial Numbers)
  • The History of APT10
  • Integration of Symantec Endpoint Security with Netwitness Platform
  • JAMF Protect Integration with Netwitness
  • Zscaler Integrations with Netwitness
  • FirstWatch Threat Spotlight: Truly Asynchronous AsyncRAT
  • File Activity Alert Optimization in Multi-EPS Deployment
  • Threat Profile Series: An Introduction to Royal Ransomware
Labels
  • Announcements 60
  • Events 7
  • Features 10
  • Integrations 11
  • Resources 63
  • Tutorials 27
  • Use Cases 24
  • Videos 116
Powered by Khoros
  • Blog
  • Events
  • Discussions
  • Idea Exchange
  • Knowledge Base
  • Case Portal
  • Community Support
  • Product Life Cycle
  • Support Information
  • About the Community
  • Terms & Conditions
  • Privacy Statement
  • Acceptable Use Policy
  • Employee Login
© 2022 RSA Security LLC or its affiliates. All rights reserved.