LockBit Group Claims Ransomware Attack Against Southeast Asian Bank
Executive Summary
- On May 8, the LockBit ransomware group claimed an attack against a major state-owned bank in Southeast Asia.
- The SecurityScorecard Threat Research, Intelligence, Knowledge, and Engagement (STRIKE) Team collected and analyzed data from internal and external sources to enrich the available information about the attack.
- STRIKE Team researchers identified possible evidence of multiple stages of a ransomware attack, including credential theft, remote access to the bank network, and data exfiltration.
- Researchers further identified a Russian IP address from which some of the malicious traffic appeared to originate.
Background
On May 8, the LockBit ransomware group claimed an attack against a major state-owned bank in Southeast Asia.
Images 1-2: LockBit added an entry for the bank to its data leak site on May 8.
LockBit is a ransomware-as-a-service (RaaS) group, a ransomware operation in which ransomware developers and leak site operators pay affiliates who access target systems and deploy the group’s titular strain of malware to them a percentage of the ransoms collected. LockBit has operated since 2019. The group rebranded as LockBit 2.0 in January 2021 and then as LockBit 3.0 or LockBit Black in Spring 2022.
A July 2022 analysis of a LockBit sample noted similarities between it and the BlackMatter and DarkSide strains of ransomware (the DarkSide group’s responsibility for the May 2021 Colonial Pipeline attack attracted a lot of attention to the group). This report further identified spear phishing as the initial access technique employed during the incident that yielded the analyzed malware sample. Similarly, in December 2022, research observed LockBit spreading through malicious documents (maldocs), which attackers often distribute through phishing.
More recently, in March 2023, the Cybersecurity and Infrastructure Security Agency (CISA) issued a #StopRansomware alert about the group in which it identified remote desktop protocol (RDP) compromise, drive-by compromise, phishing, abuse of valid accounts, and exploitation of public-facing applications as initial access techniques observed in LockBit attacks. The alert also noted that the group has used a custom tool, Stealbit, and web services for data exfiltration.
Methodology
To identify network activity that could yield further insights about the attack, STRIKE Team researchers leveraged SecurityScorecard’s unique access to network flow (NetFlow) flow data to collect a sample of traffic involving the IP addresses SecurityScorecard’s ratings platform attributes to the bank. They then searched the resulting sample for traffic indicating that attackers had remote access to bank resources by searching for traffic over ports 22 and 3389 (the standard ports for SSH and RDP communications, respectively) and for large transfers of data, which could reflect exfiltration.
Researchers then consulted SecurityScorecard’s Attack Surface Intelligence module and public cybersecurity information-sharing platforms VirusTotal and Scamalytics for additional information on the non-bank IP addresses involved in this traffic. They then collected additional samples of traffic involving selected suspicious IP addresses that appeared in the bank’s traffic sample to derive further insights about them.
Researchers additionally searched VirusTotal for recently-uploaded files containing the bank’s domain, which could provide additional insights into malicious activity targeting the bank.
Findings
Researchers collected a traffic sample containing 994,785 data transfers involving bank IP addresses occurring from March 9 to May 8. This sample, and the results available in VirusTotal, reflected attempts to access a bank server via SSH and a possible malware infection beginning in March. They further detected spyware likely impersonating the bank’s mobile banking application (which could have compromised employee credentials) by April 10-12, along with communication between bank-attributed IP addresses and others previously linked to malicious activity, which could reflect possible data exfiltration and RDP compromise, in late April and in early May.
A collection of flows between a bank-attributed IP address and 46.255.225[.]8, an IP address located in Czechia, may reflect a malware infection. 189 transfers occurred between these IP addresses over port 25 on March 9. Two malicious files, which vendors have observed exfiltrating data via SMTP, which normally uses port 25, communicate with 46.255.225[.]8. Vendors have additionally linked one of these files to the Tofsee strain of malware, which can distribute spam or phishing messages either to propagate itself or deliver malicious secondary payloads over port 25.
Given that these transfers also used port 25, they could reflect the operation of either of these files (or another similar to them) and could reflect the early stages of a compromise that later resulted in the deployment of ransomware.
An IP address that appears to be a bank mailserver, where Attack Surface Intelligence indicates port 22 is open, and one that Attack Surface Intelligence has previously linked to SSH brute force attacks, 170.210.208[.]108, communicated over port 22 throughout March.
Similarly, another bank-attributed IP address where port 22 is open, 37.44.244[.]93, and another known to target SSH services, 154.68.232[.]20, communicated throughout April and into early May.
Images 3-6: Attack Surface Intelligence indicates that port 22 is open at bank IP addresses that communicated with other IP addresses it links to attacks against that port.
Two files with VirusTotal detections identifying them as belonging to the SpyNote or SpyMax malware family, which first appeared on April 10 and 12, contain a bank subdomain. SpyNote and SpyMax are a variety of Android malware and are, as their names suggest, spyware. They can surveil and steal data, including login data (such as username and password combinations and two-factor authentication codes) from infected Android devices. They typically impersonate financial institutions’ mobile banking applications to target customers’ account information. Their use of a bank subdomain suggests that these files impersonated the victim bank’s mobile banking application. Although malware families like these typically target bank customers rather than employees, in light of LockBit’s claim and knowing that ransomware groups sometimes leverage credentials initially exposed in an infection of an employee’s personal device with information-stealing malware to access target systems, it appears possible that these files (or others like them) yielded employee credentials later used for initial access.
Hypothetically, a bank employee who is also a bank customer could have downloaded one of these files believing them to be the bank’s legitimate Android app, with threat actors subsequently realizing that the person using the infected device was also a bank employee (they could, for example, have noticed that the credentials stolen from the infected device included an email address containing a bank domain), which would enable a LockBit affiliate to subsequently leverage those credentials for initial access. While VirusTotal users first uploaded those files on April 10 and 12, they may have circulated (and possibly compromised bank credentials) for some time before detection and submission to VirusTotal.
The available NetFlow data may further indicate that threat actors accessed the bank’s network via remote desktop protocol (RDP) on or around April 27; RDP compromise is a fairly common initial access method in ransomware attacks. On that date, at 04:00:20 UTC, a potentially malicious IP address, 46.101.164[.]225, contacted a bank-attributed IP address hosting an Imperva web application firewall (WAF) via port 3389 (the standard port for RDP communications). Upon accessing the WAF, attackers could have moved further within the bank’s network. Subsequent traffic may reflect these later stages of the compromise.
On April 30, another bank-attributed IP address hosting an Imperva WAF communicated with 70.39.90[.]165, an IP address that an anti-fraud service has identified as belonging to an anonymizing virtual private network (VPN). Given that threat actors often use anonymizing VPNs to conceal the origins of their traffic, this traffic could reflect additional threat activity.
Upon observing the suspicious RDP traffic, researchers returned to the NetFlow data to identify additional suspicious traffic that may reflect targeting of the same IP address. A series of transfers on April 19 may reflect data exfiltration. On that date, the bank IP address and 23.253.253[.]26, a public proxy that vendors have previously linked to malicious or suspicious activity and which appears in other ransomware victim traffic samples collected by the STRIKE Team, communicated a total of seventy times and exchanged approximately 26.36 GB in the course of this communication. Large data transfers, especially to an IP address with a recorded history of malicious behavior, are likely to reflect threat actor exfiltration of victim data.
Researchers investigated 23.253.253[.]26 further by collecting a separate traffic sample involving it. This traffic sample showed frequent RDP communications between it and 192.162.241[.]126, a Russian IP address. Considering that many ransomware groups operate out of Russia, this may suggest that threat actors accessed 23.253.253[.]26 from 192.162.241[.]126 and then used that remote access to communicate with bank resources through 23.253.253[.]26.
Considering that exfiltration is usually a later stage of an attack, researchers next sought further evidence of exfiltration by identifying the largest data transfers to occur in the week leading up to the LockBit group’s claim on May 8. Seventeen transfers larger than 10 MB, representing an exchange of approximately 11.71 GB, occurred between May 1 and May 6. These involved three bank-attributed IP addresses, 103.28.218[.]103, 103.28.218[.]2, and 45.223.162[.]70, and nine non-bank IP addresses. An external anti-fraud service has determined eight of those nine IP addresses, all of which belong to a U.S. cloud service provider, to represent high fraud risks because they are US-based commercial servers that could be proxying malicious traffic from other locations. While the particular service making this assessment focuses on fraud, these same IP addresses could serve as proxies for other malicious activity, like data exfiltration. Large transfers to commercial servers could represent expected behavior (like data backups). However, in light of the LockBit group’s claims of data theft, communication between bank assets and these IP addresses, which are available in an appendix below, merit further investigation.
Researchers subsequently collected additional NetFlow data that included traffic occurring after the date of LockBit’s claim (May 8), revealing additional suspicious traffic between May 8 and May 12, which could reflect continued threat activity. Additional large data transfers resembling those discussed above took place. Eight flows of 100 MB or more occurred between May 8 and May 12 and involved additional U.S-based cloud service IP addresses (listed in an appendix below). If the larger transfers to the cloud service IP addresses reflect exfiltration, the timing of these particular flows would indicate that data theft continued after the attackers’ initial claim on May 8.
This second traffic sample also revealed five additional instances of communication via RDP between May 6 and 9. An IP address that five vendors have linked to malicious activity, 64.226.86[.]7, communicated with a bank IP address via RDP on May 6. This flow also involved a large data transfer (10.32 MB). Another bank-attributed IP address and 192.140.224[.]44 communicated via RDP three times on May 8. While ransomware attacks often involve RDP, these particular transfers are less likely than the others to reflect malicious activity. 192.140.224[.]44 is located in the same country as the bank IP address and has no detections in VirusTotal. Finally, 167.71.14[.[236, an IP address that six vendors have linked to malicious activity communicated with a bank IP address on May 9.
Conclusion
The above findings indicate plausible stages of a ransomware attack; the malware samples containing a bank subdomain could have furnished employee credentials that attackers later used for remote access to the bank network, which the communication between suspicious IP addresses and a bank WAF may reflect.
After accessing the bank’s network, attackers could have exfiltrated data, as indicated by the large data transfers to suspicious IP addresses. While, in broad strokes, this data appears to reflect a ransomware attack, it does not necessarily confirm the specific details of LockBit’s claims (for example, that the group stole a total of 1.5 terabytes of data or all of the passwords for its internal and external services). It may, however, offer further insights into the LockBit group’s operations by identifying IP addresses that appear to have been involved in the group’s attack.
Appendices
U.S.-Based Cloud Service IP Addresses Involved in Large Data Transfers Between May 1 and 6
- 173.203.187[.]1
- 173.203.187[.]2
- 146.20.161[.]1
- 146.20.161[.]2
- 184.106.54[.]2
- 184.106.54[.]1
- 72.32.45[.]112
- 108.166.43[.]1