Jordan Kuwait Bank Everest Ransomware Steals 11.7GB of Employee Data

• .What: Everest ransomware group breached Jordan Kuwait Bank and stole 11.7GB of data.
• .Who: 1,003 JKB employees had personal records exposed.
• .Data Exposed: National IDs, salaries, employment contracts, and internal documents.
• .Outcome: Data posted on dark web leak site; no data protection law in Jordan.

On May 26, 2025, the Everest ransomware cartel published an entry on its Tor-hosted leak site listing Jordan Kuwait Bank as a new victim. The listing included a countdown timer, a description of the exfiltrated data, and a demand for payment to prevent full publication.

Everest claimed to have exfiltrated 11.7 gigabytes of internal data, including the personal records of 1,003 JKB employees.

The Everest cartel's documented operational pattern involves prolonged dwell time - days to weeks - during which affiliates conduct methodical reconnaissance of the target environment before initiating data exfiltration.

The group's preferred exfiltration tools include Rclone and MEGAsync, which upload stolen data to attacker-controlled cloud storage accounts.

The 11.7GB volume and the breadth of data types - spanning employee records, financial reporting, correspondent banking documentation, IT infrastructure diagrams, and vendor contracts - indicate the attackers had extensive access to JKB's internal file shares, email archives, and administrative databases over an extended period.

JKB did not issue a public statement confirming or denying the breach. Jordan has no dedicated Personal Data Protection Law and no data protection authority to which employees could report the exposure of their personal information.

The Central Bank of Jordan requires banks to report material operational incidents under its supervisory framework, but the details of any such reporting remain non-public.

When Everest's payment deadline expired, the group followed its standard double-extortion playbook: the data was made available for download on its leak site, accessible to any threat actor, competitor, or intelligence service with access to the Tor network.

• .Personal identification data for 1,003 employees: full names, national identification numbers, dates of birth, and home addresses
• .Employment records including job titles, departmental assignments, salary information, and employment contract terms
• .Internal corporate documentation spanning 11.7GB consistent with exfiltration of email archives, file shares, and administrative databases
• .Potentially banking credentials, system access tokens, and internal authentication data
• .Internal financial reporting, correspondent banking documentation, and inter-departmental communications
• .IT infrastructure documentation including network diagrams and vendor contracts

The Everest ransomware cartel represents one of the more persistent criminal threat actors operating in the double-extortion space since at least 2020. Its operational pattern involves prolonged dwell time within a victim's network--days to weeks--during which it conducts methodical reconnaissance.

Everest affiliates use tools including Rclone and MEGAsync for exfiltration.

Jordan's legal framework intersects criminal law, banking regulation, and constitutional privacy protections in the absence of a dedicated Personal Data Protection Law. The Cybercrime Law No. 17/2023 provides the primary legislative basis.

The Central Bank of Jordan's supervisory framework requires banks to implement risk-based security controls and report material operational incidents. Jordan's constitutional privacy protections under Article 18 provide a normative framework but not an enforcement mechanism.

An affected employee cannot file a complaint with a data protection authority--no such authority exists in Jordan.

Everest operated inside Jordan Kuwait Bank's network for an extended period, exfiltrating 11.7GB across employee records, financial reporting, correspondent banking documentation, and IT infrastructure diagrams.

The breadth of data types indicates the attackers had access to file shares, email archives, and administrative databases - not a single system, but a cross-domain compromise.

The controls that would have detected and contained this intrusion are standard components of banking cybersecurity frameworks that JKB, as a SWIFT member institution, is already expected to implement. Each recommendation below maps to a specific phase of the Everest kill chain.

Everest affiliates maintain prolonged dwell time - days to weeks - conducting reconnaissance before exfiltration. This dwell time is the detection window.

Network Detection and Response (NDR) platforms such as Darktrace, Vectra, or ExtraHop analyze east-west traffic patterns and detect the lateral movement, credential reuse, and reconnaissance scanning that characterize the pre-exfiltration phase.

Endpoint Detection and Response (EDR) from CrowdStrike, SentinelOne, or Microsoft Defender for Endpoint detects the tools Everest affiliates deploy for persistence and credential harvesting.

The combination of NDR and EDR creates overlapping detection layers - the difference between catching the attacker during reconnaissance and discovering the breach when it appears on a dark web leak site.

The exfiltration of 11.7GB to attacker-controlled cloud storage - likely via Rclone or MEGAsync, Everest's documented tools - should have triggered Data Loss Prevention (DLP) controls at the network perimeter.

DLP sensors configured to detect bulk transfers of structured data (employee records, financial documents, national ID numbers) to unauthorized external destinations would have identified the exfiltration in progress and either blocked the transfer or alerted the security operations center.

Egress filtering policies should explicitly block connections to consumer cloud storage services (MEGA, Dropbox, Google Drive) from banking network segments.

The 11.7GB transfer represents hours of sustained exfiltration activity that produced no alert because no egress monitoring was watching.

The exfiltrated data included IT infrastructure documentation - network diagrams and vendor contracts - that provides a roadmap for future attacks.

This category of data should be classified at the highest internal sensitivity level and stored in access-controlled repositories with audit logging.

Data classification programs using tools such as Microsoft Purview, Varonis, or Digital Guardian automatically identify and tag sensitive documents based on content patterns.

Access to infrastructure documentation should be restricted to specific IT roles through role-based access controls, with all access logged and anomalous access patterns flagged for review.

The exfiltration of network diagrams transforms a single breach into a persistent strategic vulnerability - every future security control JKB implements is visible to any threat actor who downloaded the leaked data.

Jordan's absence of a dedicated Personal Data Protection Law means JKB's 1,003 employees have no regulatory recourse for the exposure of their national IDs, salaries, and employment contracts.

The Central Bank of Jordan's supervisory framework requires risk-based security controls, but enforcement mechanisms are limited.

In the absence of prescriptive regulatory requirements, JKB should align its cybersecurity program to the SWIFT Customer Security Programme (CSP) mandatory controls - which it is already obligated to implement as a SWIFT member - and extend those controls beyond the SWIFT environment to the full corporate network.

The SWIFT CSP mandates privileged access management, anomaly detection, and data loss prevention controls that, if applied enterprise-wide rather than solely to the SWIFT messaging environment, would have detected and contained the Everest intrusion.

Cybernews, Falcon Feeds, Central Bank of Jordan Guidelines, Jordan Cybercrime Law No. 17/2023, SWIFT CSP Framework