无忧传媒

Network defenders are racing to counter multiple threat actors determined to exploit the Log4j vulnerability () known as Log4Shell. And longer term challenges are likely to arise due to the breadth of Java software, and the associated Log4j logging library, being deeply embedded across the enterprise. As the most popular development language for enterprise applications, Java exists in the components powering numerous web apps and unseen backend systems. Here we highlight short- and long-term steps organizations can take to protect themselves. While these steps will solve issues, the Log4j vulnerability shows the importance of moving to persistent hunt operations.

There is no single solution to all the challenges posed by this vulnerability. Several Log4j patches have been issued (including versions 2.15, 2.16, and 2.17) because initial patches introduced further problems. The Log4j vulnerability is a reminder that simply blocking indicators of compromise (IOC) is insufficient for effective security operations. Moreover, when enterprise software libraries are impacted, and organizations have been forced into a cost versus benefit approach to security information and event management (SIEM) licensing, the SIEM cannot be the end-all-be-all to the organization鈥檚 security operations.聽

Part of what鈥檚 needed to address such vulnerabilities in the future is a new effort to improve software security and supply chain risk management with a software bill of materials (SBOM). An SBOM is a list of software components in a digital product. Universally mandated SBOMs would empower all players in the digital ecosystem to reduce risk and increase security and competition. While many improvements are still needed to increase product security, a universal SBOM mandate is one step with the power to incentivize industry to develop secure software.

Universally mandated SBOMs would also provide consumers the transparency they need to comparison shop on the vulnerability of software components. Currently, consumers cannot determine what software is included with the products they buy. As a list of all components used to make a software product, an SBOM would reveal which open source or proprietary code objects are embedded in the software. Knowing this would allow end users to better understand how bad actors might target new software by attacking old code elements that harbor unpatched vulnerabilities.

Much data has been shared since the Log4j vulnerability was made public and there鈥檚 no doubt organizations are overwhelmed trying to search for systems, patch vulnerable servers, block malicious activity, and ensure they conduct a full assessment, all while also supporting day-to-day activities.聽A graphic by the Swiss Government CERT 鈥溾�� can help organizations better understand the attack.聽

Here are steps that organizations should have already completed or should plan to complete very soon:

1)听听听 Implement Sensor Blocks聽鈥� Web Application Firewall (WAF), Intrusion Detection System (IDS), and firewall blocks should have been implemented on all perimeter and internal devices. While your options may vary by vendor, has been created to provide vendor-specific guidance and links to the most updated KBs.

2)听听听 Disable Log4j聽鈥� In cases where Log4J logging can be disabled, placing a property string within the src folder will disable the Java Naming and Directory Interface (JNDI). Under src/main/resources, create or edit spring.properties and add spring.jndi.ignore=true to the file. This will disable Log4j from running.

3)听听听 Identify and Patch Vulnerable Versions聽鈥� An update for the log4j vulnerability . When possible, an update should be applied from or (Before applying, don鈥檛 forget to verify PGP and SHA512 signatures). It鈥檚 incredibly important that security teams ensure version 2.17 is the patch applied. Version 2.16 completely removed the JNDI library. Version 2.15 is vulnerable to the same exploit as 2.14 and .

4)听听听 Disable JNDI Lookups 鈥� In the case where applications need JNDI to run, organizations should consider disabling JNDI lookups from hitting the LDAP servers. LDAP serves an important aspect within enterprises of providing direction to data鈥攈owever, in this case, attackers can exploit JDNI lookups to further enumerate networks, collect data, and discover traversal paths.

To disable JNDI lookups, first disable all Java Services on your respective system, then, Disable Logging in System Properties for both the client and server components for versions >=2.10 by either

a.聽聽聽聽 Add聽-Dlog4j2.formatMsgNoLookups=true聽to the startup scripts of Java programs.

b.聽聽聽聽 Set the :听尝翱骋4闯冲贵翱搁惭础罢冲惭厂骋冲狈翱冲尝翱翱碍鲍笔厂=鈥漷谤耻别鈥�.

c.聽聽聽聽 Alternatively, disabling the JndiLookup class from the classpath will also work. To do so, a command such as zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class聽will remove the class from the log4j-core.

5)听听听 Disable Remote Codebases 鈥� Log4Shell is possible due to how the JNDI library uses LDAP to load remote Java classes. Disabling the remote calls to Java libraries is ideal鈥攈owever, as always, this should be tested and observed closely, as this may break some legacy Java applications.

6)听听听 Perform Scan with Updated Vulnerability Management Templates聽鈥� Ensure that vulnerability scanners have credentialed access to scan as some may not pick up the vulnerability without it. Some organizations may be able to use a few open-source tools such as and . Both are trusted tools from Anchore but may require the installation of Go. Scan for evidence.

7)听听听 Perform Searches and Analysis of All Security Logs for Evidence of Enumeration or Compromise聽鈥� Leverage other security tools and look beyond the SIEM if logs are not being aggregated or consolidated into an enterprise log management solution. A conscious effort should be made to consolidate logs not going to SIEM into a central location if possible.

Special

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

Emerging Threats maintains a list of Suricata rules, including .

Many attempts may involve obfuscated code and are not easily searchable by simply searching files. Tools such as consider the obfuscation attempts. Organizations should consider writing/moving logs to a central location and cron-ing the Python script. An example may be 鈥�5 * * * *聽 -a source/file/path new/file/path鈥� should help keep files in sync then 鈥� 5 * * * * /path/to/python3 log4shell-detector.py 鈥攄efaultpaths >> .log4shelloutput.log鈥�.

8)听听听 Consolidate, Communicate, and Disseminate Updated Threat Intel Associated with Log4j 鈥� With the amount of info and intel that is being released by numerous sources it is essential that stakeholders and system owners are receiving the latest intel and applying the updated patches applicable to their applications and systems. An organization should designate a person or team to sift through all the potential disparate and extract the intel that is most relevant to their respective environment, including applications and systems.

9)听听听 Track All Remediation and Mitigation Efforts and Tasks 鈥� Related to the amount of intel being released are the associated tasks that need to be performed to remediate the vulnerability and enable additional protection mechanisms to increase the security resiliency. Organizations should be tracking in a master Log4j designated ticket or case management solution what applications and systems are being worked on, and by what teams, and any, and all issues that are preventing tasks from being completed. This helps ensure that there are no gaps in remediation and mitigation coverage that an attacker could leverage to compromise.

10)聽 聽Continue to Apply Up-To-Date Blocking Measures聽鈥� Ensure systems are receiving the most up-to-date IOCs. While IP blocking is a game of whack-a-mole a few sites like and are providing up-to-date info and helping rule out malicious attempts from benign internet scanning.

11)聽 聽Monitor LDAP Traffic 鈥� Once all immediate and short-term mitigations have been applied, organizations should monitor for malicious LDAP traffic against known/allow list traffic.

12)聽 聽Move Vulnerable Systems Behind Additional Firewalls 鈥� Finally, if systems cannot be updated at this time, all vulnerable systems should be moved behind additional protection.

While the list above may be overwhelming, we provide it as a template and not as a checklist. Organizations will need to choose the level of risk they are willing to accept that matches their objectives. New techniques to exploit this vulnerability, using techniques like command obfuscation, are being observed every day. It will be very difficult to maintain detection rules quickly enough to fully protect vulnerable assets. Also, the fact that a patch contains vulnerabilities that are being actively exploited, and there is a chance that future patches may as well, means that patching alone is not a silver bullet for protection. For these reasons, organizations need to take the position of 鈥渁ssumed breach鈥� of vulnerable assets.

Upon initial exploit, threat actors will have achieved a foothold using a myriad of available tools and can conduct the typical activities of reconnaissance, privilege escalation, lateral movement, and persistence. However, not all threat actors will do this immediately following initial exploit. It is likely that patient actors will lie in wait and avoid detection. This is why persistent hunt is necessary to detect delayed threat actor activities within the network and on previously exploited hosts.

Threat hunters should consider all previously vulnerable assets as high-risk and conduct persistent, frequent, and thorough hunt activities on all these assets. The hunt should include all networks, assets, and resources that are adjacent to the high-risk assets in an attempt to identify lateral movement, reconnaissance, persistence, or exfiltration.

Much of the activity that is being observed is the deployment of ransomware across exploited networks. These threat actors will possibly attempt to spread more quickly throughout the environment which requires threat hunters to continuously monitor for any tactics and techniques associated with typical ransomware threats. Every organization that has identified a vulnerable asset on their network should consider conducting persistent hunt operations on the previously exploitable networks.聽

Below are long-term steps to take to help mitigate the lasting impacts of this vulnerability as they relate to implementing persistent hunt.

• Continue to Monitor Java and LDAP logs 鈥� As the vulnerability relies on JNDI to execute, and the associated LDAP call, continuous monitoring of these logs should be the priority for organizations.
• Hypothesis Exploitation as an Attack Vector 鈥� Multiple sources have shared observations of attackers using the Log4j vulnerability as an attack vector for dropping malware. Vx-underground has established a site with examples of malware seen delivered using Log4j and a quick glance will show some familiar names such as Mirai. offers platform agnostic detection logic maintained by the cybersecurity community. The provides a way to view honeypot data related to Log4j exploits which can inform how to hunt. As alerts begin to filter in for newly seen behavior, root cause analysis should consider a vulnerable Java application.
• Find All Running Java Instances 鈥� Hunting for Java processes may indicate a vector for attack. Using 鈥榡ps鈥� commands, the Java Virtual Machine Process Status Tool will list all running Java processes by Process Identifier (PID) which should be verified against known and trusted processes.
• Monitor for Cobalt Strike Known Indicators of Compromise 鈥� seeing activity associated with Cobalt Strike (CS) beacons. Conducting hunts using known CS beacons can help exploited systems.

As many have stated, the effects of this vulnerability will be long term and require careful attention from security teams as adversaries are able to craft new ways to exploit vulnerable systems that defy previous countermeasures.聽

Although Log4j is the prioritized critical vulnerability of the moment, organizations should be cautious about rotating all their resources to just addressing this singular issue. An attacker can leverage the noise being created with a publicized flaw and exploit other known vulnerabilities if security operations monitoring, detection, and analysis has been put on lower priority, overlooking the hot issue of the day. Security operations should be comprehensive and holistic of all vulnerabilities and threats to the organization, and this should not be stopped despite this current vulnerability.

This blog series聽is brought to you by 无忧传媒 DarkLabs. Our聽DarkLabs聽is an elite team of security researchers, penetration testers, reverse engineers, network analysts, and data scientists, dedicated to stopping cyber attacks before they occur.

This article is for informational purposes only; its content may be based on employees鈥� independent research and does not represent the position or opinion of 无忧传媒. Furthermore, 无忧传媒 disclaims all warranties in the article's content, does not recommend/endorse any third-party products referenced therein, and any reliance and use of the article is at the reader鈥檚 sole discretion and risk.