Lockbit 2.0 affiliate’s new SonicWall exploit bypasses MFA

Increasing Capabilities of LockBit 2.0 Gang Per Our Incident Response Experience in Q1 2022 Impacts Over One Hundred Hong Kong and Macau Organisations; Exploit Acknowledged by SonicWall as CVE-2022-22279

In the first quarter of 2022, DarkLab responded to several ransomware incidents impacting organisations in the financial services, real estate, and manufacturing sectors across Hong Kong, China and Asia Pacific. In all such incidents, the presence of the LockBit executable file, .lockbit extension files, and the StealBit malware suggests that affiliates of the cybercriminal group that operates the LockBit 2.0 Ransomware-as-a-Service (RaaS) was likely behind the incidents.

LockBit 2.0 RaaS is a well-documented group with established tactics, techniques and procedures (TTPs) that has been active since 2019.[1] During our incident response investigations, we found LockBit affiliates exploiting two victims’ SonicWall Secure Remote Access (SRA) Secure Sockets Layer Virtual Private Network (SSLVPN) appliance to establish a foothold in their networks. In the first instance, the affiliate exploited a known SQL injection (SQLi) vulnerability to obtain valid usernames and passwords. Given the multi-factor authentication (MFA) access control was not enabled, they were able to achieve initial access relatively easily. In the second instance, the affiliate performed follow-up actions to retrieve the time-based one-time password (TOTP) which enabled the circumvention of the MFA access control.

In this blog post we will report on their novel technique to exploit SonicWall SSLVPN appliances and bypass MFA. According to results from open source internet search engines, over one hundred Hong Kong and Macau organisations may be susceptible to this exploit based on their reported use of potentially vulnerable appliances. This exploit disclosed by DarkLab has since been acknowledged by SonicWall as CVE-2022-22279.

A second blog post will then outline the LockBit affiliates’ TTPs as observed in our incident response experience. The final blog post will explore the potential factors that enables the LockBit RaaS group to continue innovating at a rapid pace and cement their position as a major player in the ransomware threat landscape.

Initial Access

The typical modus operandi of LockBit 2.0 affiliates is to gain access to a victim network by exploiting known vulnerabilities of public-facing services, including vulnerable SSLVPN. In particular, CVE-2018-13379 [2] has been the preferred vulnerability in many incidents, including those DarkLab responded to in January and February 2022. The vulnerability is several years old, and LockBit 2.0 affiliates were still able to capitalise on the exploit that allows for unauthenticated users to download system files through crafted HTTP resources requests. Other affiliates have been reported to gain initial access by conducting Remote Desktop Protocol (RDP) brute forcing[3] or through purchasing access to compromised servers via underground markets.[4]

However, in two incidents that DarkLab responded to in March 2022 we observed a new infection vector.  Affiliates were observed to exploit a known but relatively obscure SQLi vulnerability – either CVE-2019-7481 [5] or CVE-2021-20028 [6] – in a novel manner to retrieve user session data stored in the SonicWall SSLVPN appliance to the affiliate’s local endpoint. Retrieved data included valid usernames, passwords, and the TOTP. In doing so, the affiliates could circumvent the MFA access control, impersonate any user to gain initial access, and subsequently deploy ransomware.

Figure 1 – LockBit’s initial attack chain

The latter incidents we responded to in March 2022 were noteworthy for two reasons. First, LockBit affiliates were not reported to have exploited SonicWall SSLVPN products in the past. Second, this was the first publicly observed instance that the known SQLi vulnerability could be exploited by threat actors to extract the TOTP SHA-1 tokens of onboarded users. Affiliates could then generate the QR code containing the required information to generate one time passwords (OTP) in an authenticator app of their choice.[7] This proved to be an innovative way to circumvent the existing MFA access controls. The observation of the exploitation suggests the affiliates of LockBit now have additional tools in their arsenal, and indicates the importance they place in continuous improvement as the group looks to differentiate itself from competitors.

Impact to Hong Kong and Macau

DarkLab replicated and verified the novel exploitation method of the post-authentication vulnerability through internal testing of several known impacted SonicWall SSLVPN firmware. We have shared all relevant details, including the technical exploit code, with the SonicWall Product Security Incident Response Team (PSIRT) in March 2022 to ensure organisations are protected. We will not publicly disclose exact exploitation details to avoid replication by malicious actors.

Per subsequent communications with SonicWall PSIRT, we understood that the upgrades to SonicWall SMA firmware 10.2.0.7-34sv or above, and 9.0.0.10-28sv or above in February 2021 to address CVE-2021-20016 included comprehensive code-strengthening that proactively prevented malicious attackers from exploiting this vulnerability to circumvent the MFA access control.[8] On 12 April 2022, SonicWall PSIRT released the following advisory acknowledging the vulnerability CVE-2022-22279 which we had disclosed.[9]

As of the time of writing, we have not observed from our deep and dark web monitoring any specific intentions by threat actors to leverage this post-authentication vulnerability to target organisations in Hong Kong and Macau. However, we observed that Russian-speaking threat actors had been discussing this vulnerability in early February 2022, with posts from two underground forums – exploit[.]in and xss.[.]is – containing conversation details of purchasing the exploit code and outlining at a high-level the follow-up actions that can be taken to extract the TOTP from the active sessionid

Figure 2 – Screenshot of exploit[.]in underground forum
Figure 3 – Screenshot of xss[.]is underground forum

As a result of the LockBit incidents and various hacker chatter, we were concerned that local organisations may have missed SonicWall PSIRT’s advisory note; after all, we still observed compromises that resulted from the exploitation of CVE-2018-13379 on unpatched Fortinet SSLVPN appliances in February 2022. To that end, we conducted a passive, non-intrusive scan of both CVE-2019-7481 or CVE-2021-20028 on the full Internet Protocol address (IP address) range of Hong Kong and Macau. The preliminary results indicated that at least 100 organisations were vulnerable to CVE-2021-20028, with half of those also vulnerable to CVE-2019-7481.

DarkLab has since proactively contacted dozens of potentially affected organisations to alert them of the potential risks they faced. However, given there were a series of critical vulnerabilities pertaining to SonicWall SSLVPN appliances released in June 2021, it is likely that those may be exploited through other innovative methods by threat actors. For example, the Cybersecurity & Infrastructure Security Agency (CISA) listed CVE-2021-20016 as another SQLi vulnerability that allows a remote unauthenticated attacker to perform SQL query to access username password and other session related information in SMA100 build version 10.x. [10], which aligned with our communication with SonicWall’s PSIRT. We foresee that if left unpatched, this could pose a threat that adversaries may exploit to gain unauthorised access through exploitation of this vulnerability.

CVE NumberProductVulnerability NameDate Added to CatalogueShort Description
CVE-2021-20021SonicWall Email SecurityPrivilege Escalation Exploit Chain3 November 2021A vulnerability in version 10.0.9.x allows an attacker to create an administrative account by sending a crafted HTTP request to the remote host.
CVE-2021-20022SonicWall Email SecurityPrivilege Escalation Exploit Chain3 November 2021A vulnerability in version 10.0.9.x allows a post-authenticated attacker to upload an arbitrary file to the remote host.
CVE-2021-20023SonicWall Email SecurityPrivilege Escalation Exploit Chain3 November 2021A vulnerability in version 10.0.9.x allows a post-authenticated attacker to read an arbitrary file on the remote host.
CVE-2021-20016SonicWall SSLVPN SMA100SQL Injection Vulnerability3 November 2021A vulnerability in SMA100 build version 10.x allows a remote unauthenticated attacker to perform SQL query to access username, password and other session related information.
CVE-2021-20018SMA 100 AppliancesStack-Based Buffer Overflow Vulnerability28 January 2022SonicWall SMA 100 devices are vulnerable to an unauthenticated stack-based buffer overflow vulnerability where exploitation can result in code execution.
CVE-2021-20028SonicWall SRASQL Injection Vulnerability28 March 2022SRA products contain an improper neutralisation of a SQL Command leading to SQL injection.
Table 1 – CISA known exploited vulnerabilities catalogue listing various critical SonicWall CVEs that were being exploited in the wild as of 2 April 2022

The ongoing evolution of TTPs allowed LockBit’s affiliates to become the most prolific ransomware actors in 2022. Between 1 January and 31 March 2022, the group claimed 223 victims on their dark web leak site, compared to Conti’s 125. This equates to more than one-third of all known ransomware incidents for Q1 2022. To put it in another way, over the same period LockBit’s affiliates claimed almost 10 percent more victims than the other 24 known ransomware groups combined (223 compared to 164). LockBit’s reported activities have also increased over the course of the first three months of 2022. The gang claimed 112 victims in March, while it published details of 111 companies in the previous two months combined. This suggest an ongoing trend highlighting how LockBit will likely remain the most active ransomware-as-a-service offering for the coming months.

Figure 4 – Number of victims published on ransomware dark web leak sites between 1 January 2022 and 31 March 2022

Conclusion

Lockbit 2.0 affiliates work on behalf of the Lockbit group to conduct ransomware campaigns against organisations and industries across the globe. The affiliates’ abilities to conduct the intrusion and execution of Lockbit 2.0 ransomware vary, and through these incidents we observed affiliates with a diversified capability and skillset exploit a known SQLi vulnerability in a novel way to circumvent the MFA access control and obtain initial access. At least 100 organisations in Hong Kong and Macau are at potential immediate risk, and we foresee that if left unpatched, this could pose a threat that adversaries may exploit to gain unauthorised access through exploitation of this vulnerability. We will continue to monitor the situation and assist organisations as needed. In the next blog post, we will also share further details on the TTPs leveraged by LockBit affiliates as a result of our recent incident response experience with reference to the MITRE ATT&CK Framework, such that organisations can better prevent and detect malicious activities related to this RaaS group.

Recommendations

For organisations that have deployed the vulnerable versions of SonicWall SRA SSLVPN, we recommend the following actions immediately in the following order:

  • Upgrade legacy SRA SSLVPN device(s) running firmware 8.x given they are not supported by SonicWall; apply patches to the impacted versions of the 9.x or 10.x firmware.
  • Reset all user account Active Directory credentials that had previously authenticated via the SonicWall SRA SSLVPN. In particular, the Active Directory credentials that is tied to the SonicWall SRA device for authentication purpose should be changed.
  • Re-bind users’ second authentication factor (e.g., Google or Microsoft Authenticator) app with an updated TOTP, and ensure that users store their newly generated backup codes securely.[11]
  • Review the privileges granted to the Active Directory account tied to the SonicWall SRA device for user authentication purpose, and remove excess permissions where possible to adhere to the principle of least privilege. In general, Domain Administrator privilege should not be used.
  • Perform a review of access management with respect to identity and network access (e.g., removal of legacy and unused accounts, housekeeping of privileges for all accounts, and enforce network segmentation to tighten access to key servers).

Meanwhile, defending against undisclosed exploits are extremely challenging, but not impossible if organisations adopt a defense-in-depth approach. The following guiding principles should be observed:

  • Require multi-factor authentication for all services to the extent possible, especially on external remote services. 
  • Implement a robust threat and vulnerability management programme that leverages cyber threat intelligence to achieve a resilient security posture. Specifically:
    • Maintain regular cybersecurity patching hygiene practices, including a robust baseline that patched known exploited vulnerabilities and aims to reduce known attack surface. 
    • Leverage cyber threat intelligence to prioritise the remediation scale and timeline on a risk-based approach, through the incorporation of indications and warnings regarding trending threats per available proof-of-concept code, active exploitation by threat actors, and Darknet chatter.
  • Maintain “tertiary” offline backups (i.e., tertiary backup) that are encrypted and immutable (i.e., cannot be altered or deleted). This should be atop of your existing secondary data backups that should adopt security best practices, in particular network segmentation with your production and/or primary site.
  • Develop and regularly test the business continuity plan, ensuring that the entire backup, restoration and recovery lifecycle is drilled to ensure the organisation’s operations are not severely interrupted.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques elaborated from part one of the blogpost. We will expand this list as we deep-dive into the affiliates’ TTPs as observed from our incident response experience in Q1 2022.

  • Initial Access: Exploit Public-Facing Application (T1190)
  • Initial Access: Valid Accounts (T1078)
  • Impact: Data Encrypted for Impact (T1486)

Indicators of Compromise (IoCs)

We include the observed IoCs elaborated from part one of the blogpost. We will expand this list as we deep-dive into the affiliates’ TTPs as observed from our incident response experience in Q1 2022.

IndicatorType
7fcb724c6f5c392525e287c0728dbeb0MD5
adead34f060586f85114cd5222e8b3a277d563bdSHA-1
822b0d7dbf3bd201d6689e19b325b3982356c05bc425578db9aa4ce653deaaa7SHA-256
LockBit_9C11F98C309ECD01.exeExecutable File
.lockbitEncrypted Files Extension
91.219.212[.]214IPv4 Address
5.206.224[.]246IPv4 Address
51.91.221[.]111IPv4 Address
213.186.33[.]5IPv4 Address
194.195.91[.]29IPv4 Address

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

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.

Smells SMiShy to me…

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