Government agencies in the United States, United Kingdom, Australia, Canada, and New Zealand have issued a joint cybersecurity advisory to those affected by serious vulnerabilities, including Log4Shell, in the widely exploited Apache Log4j software library. We have issued a joint cybersecurity advisory.
This vulnerability allows attackers to remotely execute code on vulnerable systems, and is already being used by national-level organizations and ransomware groups.
Jen Easterly, Director of the U.S. Cybersecurity and Infrastructure Security Agency (CISA), described the Log4j vulnerability as the “most serious” of her career, emphasizing the global nature of the risk.
CISA is working with interagency, private sector, and international partners to understand the serious risks associated with Log4j vulnerabilities and provide actionable information so that all organizations can quickly implement appropriate mitigation measures.
This advisory expands on advice previously published by CISA and its Joint Cyber Defense Collaborative (JCDC), which focused on securing operational and industrial control systems in addition to traditional IT and cloud vendor-based networks. The focus is on securing operational and industrial control systems in addition to traditional IT and cloud vendor-based networks.
The content of the recommendation is as follows.
- 1. Identify vulnerable assets in your environment
- 2. Mitigate the risk of known and suspected vulnerable assets in your environment
- A. Treat known and suspected vulnerable assets as compromised.
- B.Patch Log4j and other affected products to the latest version.
- C. Create an inventory of known and suspected vulnerable assets and record what has been done to those assets through this process.
- D. Verify, if possible, that mitigation measures have worked.
- 3. Initiate Hunt and Incident Response.
- 4. Evaluate and apply other mitigation measures.
1. Identify vulnerable assets in your environment
Knowing where Log4j and other affected products reside in your environment is critical to protecting your network.
A. Check all assets that use Log4j’s Java library
According to published reports, attackers patch compromised assets to prevent them from being compromised by other attackers and maintain control of the assets.
To avoid missing such defense evasion, organizations need to carefully track the assets under investigation.
- Assume that all versions of Java and Log4j are vulnerable and include them in your inventory
Make sure that your inventory includes all assets, including cloud assets, regardless of functionality, operating system, or manufacturer.
- Make sure your inventory includes the following information for each asset
- Software version
- Last update date and timestamp of the updater
- User accounts for the asset and their privilege levels
- Location of the asset in the enterprise topology
B. Identify the assets in the inventory that are likely to be vulnerable.
Use CISA’s GitHub repository and CERT/CC’s CVE-2021-44228_scanner to identify vulnerable assets in Log4Shell
Additional resources for detecting vulnerable instances of Log4j are listed below, and CISA, FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK will update the source of detection rules as they become available.
Note: Due to the urgency of sharing this information, CISA, FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK have not yet verified this content.
- To identify server applications that may be affected by Log4Shell and CVE-2021-45046, please refer to TrendMicro. Log4J Vulnerability Tester
- To determine if your Java application is running a vulnerable version of Log4j
- For a list of hashes that can help you determine if your Java application is running a vulnerable version of Log4j, please see below.
- Rob Fuller’s GitHub page. CVE-2021-44228-Log4Shell-Hashes
- The NCC Group’s GitHub Page. Cyber-Defence/Intelligence/CVE-2021- 44228/.
- For PowerShell to detect vulnerable instances, see:
- PowerShell to detect vulnerable instances.
- Nathan Kula’s GitHub page. PowerShellSnippets/Invoke-Log4ShellScan.ps1
- Will Dormann’s GitHub page: checkjndi.ps1
- Canary For more information on how to test callbacks using Tokens, see Twitter thread on using Canary Tokens.
- For information on how to scan using Burpsuite Pro, see
- Silent Signal’s GitHub page: burp-log4shell
- PortSwigger’s GitHub page: active-scan-plus-plus
- For more information on how to use NetMap’s Nmap Scripting Engine (NSE), please see Divertor’s GitHub page: nse-log4shell for more information on how to use the NSE.
- Florian Roth’s GitHub page: Fenrir 0.9.0 – Log4Shell Release.
Florian Roth’s GitHub page “Fenrir 0.9.0 – Log4Shell Release” provides guidance on using Roth’s Fenrir tool to detect vulnerable instances.
2. Mitigate the risk of known and suspected vulnerable assets in your environment
A. Treat known and suspected vulnerable assets as compromised.
Suspicious assets should be quarantined until they can be mitigated and verified.
The quarantine method to be used depends on the importance of the asset. Possible quarantine methods are as follows.
- Physically remove assets from the network (e.g., unplug network cables)
- Move assets to a “jail VLAN” with enhanced monitoring and security.
- Block at the network layer (e.g. switches).
- Implement firewalls (including web application firewalls) with strict port control and logging.
- Restrict communication of assets (especially to the Internet and other corporate networks)
B.Patch Log4j and other affected products to the latest version.
- See the Apache Log4j Security Vulnerabilities webpage (as of December 22, 2021) (As of December 22, 2021, the latest version of Log4j is 2.17.0 for Java 8 and 2.12.3 for Java 7). Note: Patching or updating Java is not enough, the Log4j library itself needs to be upgraded.
- For other affected products, please see CISA’s GitHub page.
Note: If your organization is unable to immediately identify and patch a vulnerable instance of Log4j, please apply the appropriate workaround.
CISA, FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC and NCSC-UK recommend the use of vendor-provided mitigations where available.
Since the situation is changing rapidly, these workarounds should not be considered permanent, but should be applied as soon as appropriate patches become available. Additional mitigations are listed below.
However, organizations should use these mitigations at their own risk, as they may be incomplete, temporary, or cause detrimental effects such as application instability, DoS conditions, and log evasion.
- Remove Jndilookup.class from the classpath [1 ]
- Remove or rename Jndilookup.class. (Note: If you delete JndiManager, JndiContextSelector and JMSAppender will no longer function). 
- Apply the hot patch.
- NCC Group: a simple mitigation against log4j-jndi-be-gone: CVE-2021-44228 .
- Amazon AWS
- GitHub page: hotpatch-for-apache-log4j2
- Blog Hotpatch for Apache Log4j
C. Create an inventory of known and suspected vulnerable assets and record what has been done to those assets through this process.
Tracking patch application status is important because malicious groups may patch to protect their operations after a network compromise. Vulnerable assets that have been patched should be closely documented in order to identify if an attacker may have patched the asset.
D. Verify, if possible, that mitigation measures have worked.
- Scan for patched/mitigated assets using the tools and methods described in step 1.B. Use multiple methods to verify that mitigations have been successfully applied.
- Monitor the assets carefully.
- Keep an eye out for changes made by the vendor to the software on the asset. You can also check CISA’s GitHub page for known affected products and patch information. CISA will continually update this repository as patches are released by vendors.
3. Initiate Hunt and Incident Response.
In light of the widespread use of this vulnerability, CISA, FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK recommend that all organizations assume that their assets using Log4j may have been compromised and initiate a hunt procedure. .
A. Look for signs of exploitation and infringement
- Treat assets that use Log4j as suspicious and vigorously conduct forensic investigations of those assets.
- Inspect and monitor enterprise-wide accounts that reside on or are connected to assets using Log4j.
- Inspect configuration changes made after December 1, 2021 to ensure they were intended, especially on assets using Log4j.
- Use CISA’s GitHub page to detect potential exploits and breaches.
Additional resources for detecting potential exploits and compromises include:
CISA, FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK have not yet validated this content as this information is being shared urgently.
- Cisco Talos Blog. Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild
- Curated Intelligence’s GitHub page. Log4Shell-IOCs (Note: Curated Intelligence notes that “the IOCs shared in these feeds are of low to moderate reliability. We strongly recommend that you do not add them to your blocklist.”
- CVE-2021-44228 activity signature to assist in detecting activity
- Florian Roth’s GitHub page.
- Log4j RCE Exploitation Detection (Log4j RCE Exploit Detection)
- Huntress Blog. Critical RCE Vulnerability: log4j – CVE-2021-44228
- Mandiant’s blog. To Serialize or Not to Serialize – Systematically Hunting for Deserialization Exploits
- Microsoft Azure GitHub page. Azure- Sentinel/Detections/MultipleDataSources/Log4J_IPIOC_Dec112021.yaml
- NCC Group. Log4Shell: Reconnaissance and post exploitation network detection
- Sigma’s GitHub page.
B. If a breach is detected, the organization needs to do the following
- Start an incident response procedure. For guidance on hunting and investigating networks and common mistakes in incident response, see the joint ACSC, CCCS, NZ NCSC, CERT NZ, NCSC-UK, and CISA recommendation, “Technical Approaches to Uncovering and Remediating Malicious Activity. CISA, FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK have collaborated on CISA’s “Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. and Vulnerability Response Playbooks” to organizations. These playbooks, which are tailored to US FCEB agencies, provide operational procedures for planning and executing cybersecurity incident and vulnerability response activities and detail each step of the incident and vulnerability response process.
- Consider reporting the breach to cybersecurity authorities immediately. It is recommended to report in as much detail as possible, including information such as the IP address/domain used to exploit the infrastructure, the application/server exploited, the administrator’s contact information, and the start and end dates of the attack.
- US organizations should report breaches to CISA and the FBI.
- Organizations in Australia can report cybersecurity incidents by visiting cyber.gov.au or by calling 1300 292 371 (1300 CYBER 1).
- Canadian organizations can report incidents by emailing the CCCS at firstname.lastname@example.org.
- Organizations in New Zealand can report incidents by visiting NCSC.govt.nz.
- Organizations in the UK can report serious cyber security incidents at ncsc.gov.uk/report-an-incident (24-hour monitoring) or call 03000 200 973 if they need immediate assistance.
4. Evaluate and apply other mitigation measures.
A. Always be aware of changes made by vendors to the software on your assets, and if you are notified by a vendor that their product has a patch for this vulnerability, apply the update to your assets immediately. In addition, CISA’s GitHub repository contains information on known affected products and patches, and CISA will continually update this repository as vendors release patches.
B. Continue to closely monitor Log4J assets. Continue to use signatures and indicators of compromise that may indicate abuse.
- Refer to the exploit and detection resources listed in Step 3.A.(4).
- Note that there are many ways to obfuscate an exploit string. Do not always rely on a single detection method.
C. Continue to monitor Apache Log4j Security Vulnerabilities and check for new updates. Note: Because this is an evolving situation and new vulnerabilities in Log4J are being discovered, companies need to make sure that Apache Log4j is up-to-date. Please identify the software your company is using and keep abreast of updates as they may be superseded by other updates and fixes.
D. Block certain outbound TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) network traffic.
- Outbound LDAP: In most networks, LDAP is used internally, and LDAP requests are rarely routed outside the network. Organizations should either block outbound LDAP or use an allow list for outbound LDAP to known good destinations. Note: This can be difficult to detect on certain ports without a firewall that does application layer filtering.
- Remote Method Invocation (RMI): In most networks, RMI is either not used or is used for internal sources. Organizations should either block outbound RMI or use an allow list for outbound RMI to known good destinations.
- Outbound DNS: Organizations using enterprise DNS resolvers can block outbound DNS from sources other than the identified DNS resolver. At the very least, blocking direct outbound DNS from web application servers that are configured to use enterprise DNS resolvers can reduce the risk to those systems.
Note: Blocking the attacker’s Internet IP address during this event will be difficult due to the high volume of scans from non-malicious researchers and vendors. false positives for IP addresses will be high. Organizations should focus on looking for signs of successful exploits, not scans.
CISA also issued an “emergency directive” to federal agencies to address the Log4j vulnerability and announced that the Department of Homeland Security will expand its bug bounty program to include reports of related issues.