Detect and Stop Spring4Shell Exploitation

A critical zero-day vulnerability known as Spring4Shell (CVE-2022-22965) has been discovered in Java Spring Core, a widely used open-source development kit present in numerous Java applications including the Apache Tomcat framework. The vulnerability allows for remote code execution that can enable an attacker to gain full network access. Scanning activity for Spring4Shell has been observed and exploitation—if not already underway—is imminent.

The vulnerability is currently thought to affect Java development kit versions 9.0 and above, affecting Spring Framework versions 5.3.17, 5.2.0, and 5.2.19. While the details of the vulnerability were leaked online prior to its disclosure, a patch for this zero-day has been released and suggested workarounds have been posted for those that are unable to update to the latest version.

Spring4Shell Risk Assessment

Like the Java-based utility Log4j, in which the critical Log4Shell vulnerability exists, Java Spring Core is a ubiquitous part of the software supply chain. In addition to the Apache Tomcat framework—an extremely common open-source web server container which ExtraHop research indicates is present in more than 75% of environments—it's not currently known exactly how many Java-based applications are affected, making the supply chain attack especially concerning.

Most businesses have hundreds of vendor-provided software applications in their environments that may or may not be running Spring Core, often with no access to the source code, making it difficult to determine risk. It may not be the case that millions of applications are vulnerable, but just one common application built with Spring Core (such as Apache Tomcat) translates into a huge opportunity for attackers.

Mitigating Spring4Shell with NDR

Details of the exploit were leaked online on March 29, before Spring could create a formal disclosure or release a patch. This increases the risk of opportunistic attackers having already gained access to vulnerable environments. Because the Spring framework is deeply engrained in the software supply chain, patches to vulnerable applications may lag, making post-compromise detection critical to stopping attacks.

It's also important to note that Spring4Shell can be accessed over HTTPS, giving attackers the ability to hide activity behind encryption, similar to the Log4Shell vulnerability. The use of encrypted protocols by attackers has become increasingly common while, for many organizations, the ability to detect signs of malicious activity in encrypted traffic has not. Even after patches are applied, it is extremely important for organizations to carefully monitor all network traffic—including encrypted protocols—for signs of compromise.

How to Detect Spring4Shell with Reveal(x)

For Reveal(x) customers, a detector and a Threat Briefing for Spring4Shell are already available to help teams identify risk and detect any exploit attempts associated with this zero-day. While Reveal(x) by default detects east-west traffic associated with this exploit, custom records are being generated to allow users to identify all exploit attempts against their environments, including scans. In addition, Reveal(x) 8.8 allows users to view any north-south scan attempts via the Spring4Shell Threat Briefing.

While many organizations are running third-party and commercial applications that contain Spring Core, it is difficult to determine which applications are vulnerable without access to the source code. Because of this, all organizations are advised to pay close attention to Reveal(x) threat detections that involve production web servers and any third-party and commercial applications. Application teams that use Spring Core and Apache Tomcat should immediately update to the latest version of Spring.

ExtraHop is continually monitoring the situation and will provide updates as more details are known about how the Spring4Shell exploit is being used and what applications may be affected. The ExtraHop Threat Research team has also conducted a deep technical analysis of the vulnerability, which you can read here. Additionally, our security team can confirm that ExtraHop products are not vulnerable to the Spring4Shell vulnerability (CVE-2022-22965).