Log4j INCIDENT RESPONSE
The following post will assist you with the Log4j incident response process based on the familiar tools, mitigate options, and the information from the vendors and community.
Introduction
On Dec. 9, 2021, a remote code execution (RCE) vulnerability in Apache log4j 2 was identified as being exploited in the wild. PoC code was released, and subsequent investigation revealed that exploitation was effortless to perform. By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker can instruct that system to download and subsequently execute a malicious payload.
Like many high severity RCE exploits, thus far, massive scanning activity for CVE-2021-44228 has begun on the internet with the intent of seeking out and exploiting unpatched systems. Due to the discovery of this exploit being so recent, many servers, both on-premises and within cloud environments, have yet to be patched. We highly recommend that organizations upgrade to the latest version (2.15.0-rc2) of Apache log4j 2 for all systems.
Log4j IR Playbook
The following detection, analyze and mitigation based on Microsoft Sentinel, Microsoft XDR, and third-party tools.
Detect & Investigation
The first stage with Log4j is to know the affected system in your environment, which means you need to run and security tools, open-source tools, and event classic IT tools to map, assess and find the relevant apps and systems that use the JNDI components.
Microsoft Sentinel
Microsoft Sentinel looks at many sources (if it is connected). Hence, it could search for and find log4j components within a few minutes and, of course, can see if some elements are compromised.
The magic with Microsoft Sentinel is to run queries against the relevant connected sources and provide the results, including all information and evidence.
Below is information from the field and how Microsoft Sentinel catches the external scanning 👇
Microsoft XDR
Microsoft Defender for Endpoint (MDE) can use the following attack surface reduction rule to block or audit some observed activity associated with this threat.
Block executable files from running unless they meet a prevalence, age, or trusted list criterion due to the broad network exploitation nature of vectors through which this vulnerability can be exploited, and applying mitigations holistically across large environments will take time. We encourage defenders to look for signs of post-exploitation rather than entirely relying on prevention. Observed post-exploitation activity such as coin mining, lateral movement, and Cobalt Strike is detected with behavior-based detections.
Microsoft Defender for Cloud
Microsoft Defender for Cloud can use Inventory tools to begin investigations before a CVE number.
You can also find via the following tools inside Microsoft Defender for Cloud:
- Vulnerability assessment findings
- Software inventory
Azure Firewall
Azure Firewall Premium has enhanced protection from the Log4j RCE CVE-2021-44228 vulnerability and exploit. Azure Firewall premium IDPS (Intrusion Detection and Prevention System) provides IDPS inspection for all east-west traffic and outbound traffic to the internet.
Open-Source Tools
Source Code Scanning
- CERT CC (Carnegie Mellon) scanning for a jar, war, and ear files to search for the presence of JndiLookup.class
- Logpresso is a single binary command-line tool for CVE-2021-44228 vulnerability scanning.
- Grype – Searches libraries installed on a system and displays vulnerabilities present
- Syft – Searches for installed code and libraries and displays their versions.
Active/Dynamic Testing
- Nmap Scripting Engine checks against log4shell or LogJam vulnerabilities (CVE-2021-44228).
- FullHunt is a fully automated, accurate, and extensive scanner for finding vulnerable log4j hosts.
- Tenable Nessus Plugin is encouraging non-customer organizations to download a community license for Nessus scanner)
Contain & Mitigate
If you cannot patch the apps and system, you need to mitigate the log4j manually.
For Log4j versions >= 2.10,
Set the log4j2.formatMsgNoLookups system property to true on both client- and server-side components.
Add -Dlog4j2.formatMsgNoLookups=true to the startup scripts of Java programs; or Set the following environment variable: LOG4J_FORMAT_MSG_NO_LOOKUPS=”true”For Log4j versions from 2.0-beta9 through 2.10.0
Remove the JndiLookup class from the classpath:
-
zip -q -d log4j-core-*.jar
-
org/apache/logging/log4j/core/lookup/JndiLookup.class
Additionally, they recommend the following actions:
- Isolate systems into their restricted DMZs or VLANs
- Turn on any endpoint or network security signatures for Log4j exploitation
- Monitor networks and servers closely for suspicious or unexpected behavior
- Block all outbound network connections from servers or limit outbound network connections to trusted hosts and network ports
Exploit Detection
Open Source
References
Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation
How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228 & CVE-2021-45046) | LunaSec
Hunting Log4j With Sentinel (eshlomo.us)
Log4j LAB & Sentinel Detection (eshlomo.us)
us-16-MunozMirosh-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE (blackhat.com)
