Eight months after the cybersecurity community was sent scrambling by Log4j, organizations have begun to reflect on the vulnerability that took the world by surprise. The logging library found in many Java applications became the center of discussion amongst the cybersecurity community in early December 2021 due to a zero-day vulnerability it possessed. The remote code execution vulnerabilities (CVE-2021-44228 and subsequently CVE-2021-45046 and CVE-2021-45105) targeted organizations by executing arbitrary code on a vulnerable host allowing bad actors, without authentication, to gain entry into an organization’s network through a variety of channels including search boxes, chat boxes, login forms, and many other input-controlled avenues. 

These vulnerabilities, also known as Log4Shell, capitalized on the logging library’s ubiquity and presence in software across a variety of consumer and enterprise services, websites, and applications in a number of industries, including communications, media, technology, financial services, and health and public services. It also called into question supply chain vulnerabilities, as many organizations use third-party products and systems that added a significant layer of complexity as they attempted to determine their vulnerability to this particular threat. 

While the Cybersecurity and Infrastructure Security Agency (CISA) originally estimated the zero-day vulnerabilities resulted in over 100 million instances of infected software and technology, that number has likely continued to rise based on the agency’s newest joint advisory with the United States Coast Guard Cyber Command (CGCYBER) on June 23, 2022. 

According to the information in the latest advisory, multiple threat actors have continued to exploit Log4Shell on unpatched, public-facing VMware Horizon and UAG servers since December 2021. These threat actors implanted loader malware on compromised systems with embedded executables, enabling remote command and control (C2). In one confirmed compromise, these advanced persistent threat (APT) actors were even able to move laterally inside the network, gain access to a disaster recovery network, and collect and exfiltrate sensitive data.

This serves as a strong reminder of the need for security practitioners to continue to stay vigilant against and learn from events like Log4j and SolarWinds. Below, we’ll discuss some of the lessons learned from the Log4j situation and identify key takeaways security leaders can use to better understand their level of vulnerability and strengthen the maturity of their network security posture in preparation for a similar attack.

Lessons Learned 

• Visibility equates to speed in the time of a potential crisis. Having full visibility into your environment when vulnerabilities like Log4j are discovered is paramount when time is of the essence. Being able to immediately access your network and know exactly where to look for certain tools, technologies, attributes, and software can be the difference between a breach and a successful defense. Specifically with regard to Log4j, organizations who had a high level of visibility into their environment were able to understand how it would handle a Log4j attack and then subsequently identify and block any attempts to exploit the vulnerability.   
• Understanding the exploit chain is critical. Vulnerabilities are often successfully breached through a series of exploits, as was the case with Log4j. First, attackers had to send bad data to Log4j. Once the vulnerable Log4j library received the input, it had to interpret the data in a way that caused the affected server to go out and retrieve a malicious payload. Finally, once the payload was successfully downloaded, the vulnerable server then had to execute it back in the environment. If an organization is able to understand this chain of exploits, they are much more likely to be able to sever the chain and effectively protect against the attack.
• Validation of security resilience is imperative. Understanding an organization’s ability to withstand an attack against a specific vulnerability requires validation of resilience. This type of validation is only achieved through a full simulation of an attack on the vulnerability based on known TTPs. In the case of Log4j, many mechanisms were identified by CISA, including communication with a real malicious server exploiting CVE-2021-44228/CVE-2021-45046/CVE-2021-45105 using LDAP, communication with a server vulnerable to Log4j using HTTP, and remote exploitation of Apache Log4j vulnerability. Validating such attack mechanisms through an attack simulation—enabled by breach and attack simulation (BAS) technology—can help organizations better understand their level of vulnerability in order to take proactive remedial action. 
• Board confidence requires empirical validation against high-alert vulnerabilities. When a vulnerability like Log4Shell makes national news, board members will invariably want assurances about their organization’s ability to withstand such an attack. In order to provide this level of assurance, CISOs and security teams need the ability to quickly validate their vulnerability resistance (as noted above) and then provide empirical data to inform strategy decisions. BAS technology provides both the validation and data necessary to enable security teams to confidently, and quickly, report to the board and key stakeholders about an organization’s level of preparedness.  
• Input/output validation minimizes the attack surface. There is endless traffic in and out of an organization’s network and applications. Validating these data inputs and outputs can help to minimize risk and enhance an organization’s ability to sanitize and test the data. For example, Log4j sends a malformed input to the logging library, but if input/output validation was effectively applied and performed across the environment, the maliciously formed input would be blocked from entering the environment. This type of precaution would proactively end the necessary exploit chain to attack this and other similar vulnerabilities.
• Egress filtering can help block malicious requests. Blocking communications that are not expected in a system plays an important role in minimizing an organization’s attack surface. In reflection of Log4j, egress filtering could have gone a long way in protecting organizations from attacks by blocking the server from reaching out to get the malicious content requested by Log4j. If the server is blocked from reaching out, it effectively disables this type of exploit from being able to take place as the content cannot be downloaded.  
• A strong patching strategy is not optional. As vulnerabilities become known in software and applications, it is imperative that organizations are given the resources they need to remediate the vulnerabilities before they have the chance to be exploited. In reflection of Log4j, patches for the applications with the logging library were released as soon as time allowed. Unfortunately, the timeliness of the patch release means nothing if organizations are unable to dedicate the time or resources to apply the patch or are altogether unaware that they need the patch (e.g., with unknown supply-chain vulnerabilities). As seen in CISA’s latest advisory, attackers will continue to exploit Log4j vulnerabilities until security teams patch them.
• Basic cyber hygiene prevents the majority of vulnerabilities. Organizations that ascribe to a simple cyber hygiene practice, as cited by security frameworks such as NIST and ISO, are significantly more prepared to fend off attacks that leverage vulnerabilities like Log4j. Aligning to a framework to provide a baseline of acceptable cybersecurity capabilities can go a long way in helping organizations remediate most risks associated with such attacks.  

SafeBreach’s Response to Log4j

As demonstrated above, there is a lot we can learn from Log4j as a cybersecurity community. One key outcome is that many organizations are carefully reevaluating their cybersecurity programs to ensure they are better prepared for similar events in the future—and SafeBreach is no different. We have used Log4j as an opportunity to reevaluate our commitment to continuously improving and enhancing the user experience of our platform by introducing features and capabilities that not only make it more powerful, but also easier to use. As a result, we have: 

• Improved and expanded our continuous security validation capabilities with the addition of agentless web application security validation, which unlocks an organization’s ability to view the web application security attack surface in the context of the full attacker kill-chain. Organizations can then understand how specific choke points impact the ability of an attack to achieve their goals.  
• Dramatically expanded the coverage provided by our Hacker’s Playbook by: 
  • Updating our 24-hour service-level agreement on incorporating newly identified threats from US-CERT alerts to now include FBI Flash alerts as well. Adding rapid coverage of these newly identified TTPs and IOCs allows customers to proactively validate their security controls against the rapidly evolving threat landscape.
  • Adding the ability to validate deployed security controls against the Top 16 TTPs as seen in the MITRE ATT&CK framework. These TTPs, which made up 90% of the observed techniques from April 2019 to July 2021, have been mapped across our entire attack playbook so customers can now run coverage scenarios for their vertical/industry to test their preparedness against these advanced threats.
• Continued to invest in our world-class research team, who actively monitor the hacker underground and source intelligence feeds to ensure our Hacker’s Playbook is the largest, most comprehensive collection of attacks in the world. They also conduct original research that is shared with the broader security community and are regularly asked to present at leading conferences, such as Black Hat, RSA, and DEFCON.

While these types of attacks are inevitable, we believe there are key takeaways from the Log4j experience that can help organizations better understand their level of vulnerability and strengthen their security posture in preparation for future attacks. This includes understanding the exploit chain and implementing other basic cyber hygiene practices like input/output validation, egress filtering, and a solid patching strategy. 

It also includes investing in technology, like BAS, that can simulate attacks to proactively test the effectiveness of all layers of an organization’s security independently and provide unmatched visibility into how their security stack responds at each stage of the defense process. To learn more about how the SafeBreach BAS platform helps leading companies—like CVS, PayPal, Netflix, and Experian—augment their continuous security validation programs, schedule a customized demo today.