Computer Security Spring4Shell Abused in Campaign Pushing Mirai

Spring4Shell Abused in Campaign Pushing Mirai

Java-based implementations seem to be the gift that keeps on giving. With occasional reports of ongoing efforts to exploit Log4j, the vulnerability that was on everyone's mind in winter, now news is coming in for active exploitation of the latest significant vulnerability discovered in the Spring Core Java library.

Weaponized Mirai malware used in campaign

The attack campaign using Spring4Shell is being monitored by two separate security research firms. Now the research teams are spotting an old acquaintance being used to exploit the Spring4Shell vulnerability.

Both security companies noticed that a weaponized version of the Mirai malware, commonly associated with botnet use, was being used to actively exploit the Spring4Shell flaw.

When examining systems vulnerable to the new campaign pushing Mirai to abuse Spring4Shell, researchers spotted a number of traits found in systems susceptible to exploitation. These include the presence of the Spring framework, running patches prior to 5.2.20 and the JDK updated to versions 9 or newer. The Spring4Shell flaw is known not to affect platforms running older Java Development Kit, such as JDK 8.

Apache Tomcat and specific configurations of Spring parameter binding, set to use a non-basic parameter type, are among the features specific to vulnerable systems as well.

First attempts to abuse the flaw and push Mirai date to late March

Researcher-operated honeypots detected the first attempts at intrusion on the last day of March 2022.

The attacks deploying weaponized Mirai malware on systems vulnerable to Spring4Shell were mostly focused on targets located in Singapore and the region.

Researchers are expecting attacks attempting to exploit the Spring4Shell vulnerability to only increase in volume over the next months, as the flaw has been documented well and the details are out there for threat actors to pick up on as well. Patching remains as essential as ever, but similar to the case of Log4j, the issue here is not patching but the sheer number of systems running vulnerable code. In that sense, even 1% of unpatched systems out of millions is a significant number of potential targets for the exploit.

Loading...