Reputation Risk

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

Posted on by darklabhk

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 [darklab dot cti at hk dot pwc dot com] for any further information.

Smells SMiShy to me…

Posted on by darklabhk

Macau SMS Phishing Unveils Threat Actor Close to Home

On 2 March 2022, Darklab observed SMS phishing (smishing) activity targeting mobile users in Macau. The message masqueraded as the courier service DHL delivering a package to the victim. The intended purpose was to steal victims’ credentials, personally identifiable information (PII), and credit card details.

Smishing campaigns via the fraudulent use of the DHL brand is far from uncommon.[1] Indeed, the Macau Polícia Judiciária issued a notice on 24 February 2022 to warn citizens about fraudsters masquerading as counterfeit courier companies to trick victims into providing their personal information.[2]

However, we were interested in this case as the threat actor behind it had also registered several fake domains masquerading as other reputable companies in Hong Kong and Singapore, such as Hongkong Post and Singapore Post. While we are used to phishing and smishing campaigns globally, when this happens in our virtual backyard it draws our attention as it can pose a real threat to users in Hong Kong, Macau, and Singapore.

Smishing Incident in Macau

The initial malicious SMS message came from a sender named INFO. Recipients are requested to click the provided hyperlink to reschedule the package pick-up date and time as the previous attempt was not delivered successfully.

Figure 1 – Initial SMS phishing message sent to the victim
Figure 2 – Image displaying the fraudulent delivery status

Once the victim has opened the link, a page appearing to be the Hong Kong DHL Express displays a phony delivery schedule page with free text fields that the recipient is supposed to complete to schedule a delivery time. Information requested includes user’s full name, contact number, residential address, city, and postal code.

Figure 3 – image of the phony page requesting the victim into inputting their credentials

After inputting the personal information and clicking the submit button, the victim is redirected to another page that requires them to select their preferred delivery option.

Figure 4 – fraudulent DHL HK page asking victims to proceed to the payment card page

Upon selecting the preferred delivery option, the fraudulent DHL HK site requests for the victim to input financial information, including name, credit card number, expiration date, and CVV number. Once in possession of users’ payment card details, criminals can resell them online or conduct financial fraud themselves.

Figure 5 – Final page designed to capture the victims’ credit card details

Something Smelt Smishy…

The risk of smishing has increased at an alarming rate as a result of the Covid-19 pandemic. While this is not entirely a new trend, we observed that the messages are becoming increasingly deceptive as they look to trick victims into providing their personal information.

What threw us off was the fact that the URL within the smishing text redirected users to the URL hongkong-post[.]net/918srx, which was a Russian IP address – 31[.]28[.]27[.]151 – hosting the fake DHL site. The same IP address also hosted the domain dhl-post[.]hk.  Both malicious domains and their associated SSL certificates were created after 28 February 2022, just a few days before the beginning of the smishing campaign.

Additionally, hongkong-post[.]net had mail exchanger (MX) records, which suggested the threat actors’ intent to send and/or receive emails.[3] We also saw MX records for another domain, singapore-post[.]com, hosted on the same IP address and created on 7 March 2022. Overall, the existence of young domains with MX records mimicking legitimate brands is a strong indication of likely phishing intent, which security teams should be monitoring for.

The historical WHOIS lookup for the domains revealed that the registrar company is NiceNIC INTERNATIONAL GROUP CO., LIMITED (NiceNIC.NET) based in Hong Kong.[4] While pivoting through the Registrar Name and NiceNIC.NET’s Chinese company name “耐思尼克國際集團有限公司”, we observed 21 additional domains associated with this registrar as of 8 March 2022. At least four of the domains (xjam[.]hk, canadahq[.]hk, kaddafi[.]hk, and aij[.]hk) were flagged by security scanners as likely malicious. Furthermore, there were newly registered domains (aididas[.]com[.]hk) that were not yet flagged by security scanners, though strongly looked like a fraudulent website.

Meanwhile, we also observed that canadahq[.]hk had relation resolutions to a known bad Russian IP address 185[.]178[.]208[.]186, which hosted files to download the Trojan “Win32.Trojan.Raasj.Auto”. This Trojan was first observed in 2017 per various open source threat exchange platforms[5], and there are various web posts elaborating the various impacts to the victim.

In one instance, the Trojan is elaborated to have performed as the spyware that steals sensitive information such as credit card details and passwords for sale and profitability.[6] On the other hand, the Trojan was deemed to have been altered and linked to the “Trojan-Ransom.Win32.Shade.Ino” ransomware that cybercriminals deliver via phishing emails to conduct online frauds. The ransomware ciphers documents on the hard drive and prevents normal access to the victim’s workstation, with a ransom note locatable on the local drive upon reboot that demands payment to decipher the data.[7] A third web post noted that the “Win32.Trojan.Raasj.Auto” Trojan would hijack victims’ web browser to cause web redirection issues, and slow down the overall System and Network performance speed.[8]

Overall, the links to relatively low level malware suggests a financially motivated campaign spanning multiple years and only recently focusing on Hong Kong and South East Asian targets.

Figure 6 – Pivoting out from 耐思尼克國際集團有限公司 to identify further known-bad malicious domains and IP addresses, along with the Trojan “Win32.Trojan.Raasj.Auto”

Conclusion

Through a Macau smishing campaign, we were able to uncover a wider campaign targeting Hong Kong, Macau, and Singapore and involving a network of malicious Hong Kong domains registered by the same local registrar. A specific domain had a resolution history to a Russia-based IP address reportedly linked to Trojans used since at least 2017, suggesting it was likely rented by or associated with multiple cybercriminal threat actors. Our assessment is reinforced by the fact that the original domain exploited for smishing, dhl-post[.]hk, was hosted by a Russian server, which is a relatively rare occurrence in Hong Kong.

Recommendations

While phishing and smishing abusing legitimate brands will remain a problem, companies can take action to mitigate and prevent the threat they pose.

  • Organisations should update their email security solution and network devices (including external firewall, web proxies) to detect for potential inbound/outbound connections from the known-bad domains and IP addresses in this post.
  • Users should remain wary of the legitimacy of webpages and their branding, and access websites via the global webpage as opposed to the URL shortened link if in doubt. Impacted companies should issue circulars and alerts as necessary when impersonation attempts are detected.
  • Organisations should conduct young domains monitoring and alert against potentially suspicious domains for further action. This task is typically conducted by our Security Operations Centre for subscription clients. We have already informed both DHL and Hongkong Post to investigate, and if necessary perform takedown of fake domains dhl-post[.]hk and hongkong-post[.]net.
  • Registrars should enhance their onboarding due diligence to reduce the risk of provisioning of domains impersonating legitimate brands, and should regularly reviews activities of those domains to ensure their use for ethical and non-malicious activities.

MITRE ATT&CK TTPs Leveraged

  • Initial Access: Phishing (T1566)
  • Initial Access: Phishing: Spearphishing Link (T1566.001)
  • Execution: User Execution (T1204)
  • Credential Access: Input Capture – Web Portal Capture (T1056.003)
  • Collection: Input Capture (T1056)
  • Collection: Browser Session Hijacking (T1185)
  • Exfiltration: Automated Exfiltration (T1020)
  • Impact: Data Encrypted for Impact (T1486)
  • Impact: Account Access Removal (T1531)
  • Impact: Endpoint Denial of Service (T1499)

Indicators of Compromise (IOCs)

• hxxps://hongkong-post[.]net/e/authID=UEjJc/tracking.php?sessionid=4g3ihd1ej09+6b+27fc58arSZF+27+5p9Ba8+D6Y+Gg3ok+4+1uIEOgCLfMSPmNKwbHwTAaX+J42951997505
• dhl-post[.]hk
• hongkong-post[.]net
• singapore-post[.]com
• xjam[.]hk
• canadahq[.]hk
• kaddafi[.]hk
• aij[.]hk
• aididas[.]com[.]hk
• 31[.]28[.]27[.]151
• 185[.]178[.]208[.]186

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