RansomEXX Attack On Indian Banking Infrastructure: CloudSEK Analysis
The attack had reportedly prevented customers of around 300 small-sized lenders across the country from accessing payment services like withdrawing cash at ATMs or using UPI.
The RansomEXX group has been identified as behind the ransomware attack on Wednesday that disrupted India's banking ecosystem, affecting banks and payment providers, according to a report by cyber intelligence company CloudSEK.
The attack had reportedly prevented customers of around 300 small-sized lenders across the country from accessing payment services like withdrawing cash at ATMs or using UPI.
The attack was initiated through a misconfigured Jenkins server at Brontoo Technology Solutions, a collaborator with C-Edge Technologies Ltd., which is a joint venture between Tata Consultancy Services Ltd. and the State Bank of India.
This situation is still evolving, with negotiations ongoing with the ransomware group, and the data has yet to be published on their PR website.
CloudSEK released a report dissecting the attack chain and identifying adversary tactics.
Key Report Findings:
Attack Origin: The attack chain began with a misconfigured Jenkins server, exploiting a vulnerability (CVE-2024-23897) to gain unauthorised access. CVE-2024-23897 is a local file inclusion vulnerability in Jenkins that allows attackers to gain secure shell access.
Ransomware Group: The attack has been attributed to RansomEXX v2.0, a variant of the RansomEXX ransomware group known for targeting large organisations with substantial ransom demands. This group operates as part of a broader trend where ransomware developers continuously evolve their malware to bypass security defences and maximise their impact.
Infection Vectors And Tactics: Common vectors include phishing emails, exploiting vulnerabilities in remote desktop protocols and leveraging weaknesses in VPNs and other remote access services. After initial access, the group employs tools like Cobalt Strike, Mimikatz and other administrative tools to move laterally within a network. It then utilises known exploits and credential theft to gain higher privileges within the compromised environment.
Payload And Encryption: RansomEXX v2.0 uses strong encryption algorithms, such as RSA-2048 and AES-256, making file recovery without the decryption key virtually impossible. It targets critical files and backups, rendering them inaccessible, and often exfiltrates data before encryption to use it as leverage (double extortion).
Ransom Notes: Victims receive detailed ransom notes with instructions for payment, typically in Bitcoin or other cryptocurrencies. RansomEXX is known to engage in negotiations, sometimes lowering ransom demands based on the victim's response and perceived ability to pay.
Notable Targets: RansomEXX has targeted a range of high-profile organisations across sectors, including government agencies, healthcare providers and corporations. Some of the group’s earlier targets have been the telecommunications services of Trinidad and Tobago, Ministry of Defence of Peru, Kenya Airways, Ferrari and Viva Air.
Impact And Response: The attacks have resulted in significant operational disruptions, data breaches, and financial losses. Many victims have resorted to paying the ransom to restore operations quickly.
Adaptive Techniques: RansomEXX v2.0 continues to evolve, incorporating new techniques to bypass security measures. Recent reports indicate the use of stolen digital certificates to sign malware, increasing trust and reducing detection rates.
Takeaways: According to CloudSEK, the attack highlighted a significant vulnerability within current enterprise systems and threat modelling practices. While large organisations with strong cybersecurity are challenging to breach, attackers exploit the path of least resistance, with supply chain attacks becoming increasingly prevalent.
The report suggested that organisations must strengthen their security postures by regularly updating and patching systems, especially those involving critical infrastructure. While the primary organisation should maintain an updated Jenkins server, all critical vendors must also ensure their servers are up to date.