Everest Ransomware Steals 910GB from Nissan via Stale FTP Credentials — A Third-Party Risk Wake-Up Call for Saudi Banks

The Everest ransomware group has claimed exfiltration of 910 GB of sensitive data from Nissan's North American dealership network — not by breaching Nissan's core infrastructure, but by compromising a third-party vendor's FTP servers that had been running on leaked credentials since September 2023, with no multi-factor authentication in place. For Saudi banks managing dozens of external service providers, this incident is a textbook case of why SAMA CSCC's third-party risk controls exist and why they demand continuous enforcement.

How Everest Exploited a Forgotten Vendor Pathway

According to negotiation logs published by Everest on its dark web leak site, the group gained access to GCSSD Apps (Global Customer Service & Sales Data) FTP servers that served the Nissan and Infiniti dealer network across North America. Eight unique login and password pairs for these servers had been circulating in public breach databases since September 2023 — over two and a half years before the attack materialized. Passwords were never rotated. MFA was never enforced. The servers continued processing daily full dumps of the customer database, auto loan records from Nissan Financial Services, repair orders, dealer employee data, wholesale invoices, and internal business reports.

Everest's timeline suggests they had persistent access from at least January 15, 2026, when Nissan was first notified. By April 2026, with no ransom payment forthcoming, the group escalated by publishing the full negotiation transcript — a pressure tactic increasingly common among extortion-focused ransomware operators who rely on public shaming rather than encryption alone.

Why This Is Not Just an Automotive Sector Problem

The attack pattern Everest used against Nissan requires zero sophistication. Credential reuse from publicly available breach dumps, combined with legacy file transfer protocols lacking MFA, is a vulnerability profile that exists across every sector — including Saudi financial services. Many banks and insurance companies in the Kingdom still rely on SFTP/FTP endpoints managed by third-party payment processors, document management vendors, HR outsourcers, and regional correspondents. If those vendors are not subject to the same credential hygiene and access control standards as the bank itself, they become the path of least resistance for threat actors.

Everest's operational model reinforces this concern. The group has shifted away from traditional encryption-based ransomware toward pure data exfiltration and extortion. They move quietly, establish persistence, and extract maximum data volume before making contact. By the time the victim knows, the damage is done. This mirrors the approach of groups like BianLian and Karakurt, signaling a broader industry shift that makes data-at-rest and data-in-transit controls more critical than ever.

Direct Implications for SAMA-Regulated Institutions

SAMA's Cyber Security Common Controls (CSCC) framework addresses third-party risk across multiple domains. Domain 3 (Third-Party Cybersecurity) explicitly requires financial institutions to assess, monitor, and enforce security controls across all external service providers handling sensitive data. The Nissan breach exposes failures that SAMA auditors specifically look for: credentials not rotated within policy windows, absence of MFA on external-facing services, lack of continuous monitoring on vendor data flows, and no evidence of periodic vendor security assessments.

NCA's Essential Cybersecurity Controls (ECC) reinforce this through controls on identity and access management (ECC 2-2) and external party security (ECC 2-14), both requiring organizations to enforce strong authentication and regular credential rotation for any external access point. Under PDPL, the exposure of customer financial data through a vendor's negligence triggers data controller liability — meaning the bank, not just the vendor, faces regulatory consequences if Saudi customer data is compromised through an uncontrolled third-party channel.

The Credential Hygiene Problem Is Systemic

The fact that Nissan's vendor credentials sat unchanged in public breach databases for over two years without detection points to a systemic failure in credential monitoring. Services like Have I Been Pwned, SpyCloud, and Flare Systems provide automated breach credential monitoring that can flag exposed enterprise credentials within hours of a dump appearing. Yet many organizations — including those in regulated sectors — treat credential monitoring as a one-time exercise rather than a continuous control.

For Saudi financial institutions, SAMA CSCC expects continuous vulnerability management that includes credential exposure monitoring. A bank's SOC team should be ingesting breach intelligence feeds and cross-referencing them against all service accounts, vendor credentials, and privileged access tokens. When a match is found, automated playbooks should trigger immediate password rotation and incident investigation — not a note in a quarterly report.

Practical Recommendations for Saudi Financial CISOs

1. Audit every vendor FTP/SFTP endpoint immediately. Identify all file transfer services operated by or shared with third parties. Verify that credentials have been rotated within the last 90 days and that MFA or certificate-based authentication is enforced. Legacy FTP endpoints without encryption must be decommissioned or migrated to SFTP with key-based authentication.
2. Deploy continuous credential exposure monitoring. Subscribe to breach intelligence services and integrate them with your SIEM/SOAR platform. Automate alerts for any credential matching your organization's domains, vendor domains, or service account naming conventions. Cross-reference results against your Privileged Access Management (PAM) inventory.
3. Enforce SAMA CSCC Domain 3 vendor assessments quarterly. Move beyond annual vendor questionnaires. Require evidence of MFA enforcement, credential rotation logs, and penetration test results from all vendors with access to customer data or financial systems. Include right-to-audit clauses in all vendor contracts.
4. Implement network segmentation for vendor data flows. Vendor-facing file transfer endpoints should sit in a DMZ with strict egress controls, DLP inspection, and anomaly detection. A vendor endpoint should never have lateral access to production databases or internal network segments.
5. Simulate the Everest scenario in your next tabletop exercise. Run a purple team exercise where the red team uses publicly available breach credentials to attempt access to vendor-managed endpoints. Measure detection time, response time, and containment effectiveness against your SLA targets.

Conclusion

Everest did not need a zero-day exploit, a novel malware payload, or insider access to steal 910 GB from one of the world's largest automakers. They needed a username and password that had been public for two and a half years and a vendor that never bothered to change them. For Saudi financial institutions operating under SAMA CSCC and NCA ECC, this incident is a direct reminder that your security posture is only as strong as your weakest third-party link. The controls exist in the frameworks — the question is whether they are being enforced continuously or just documented for the next audit cycle.

Is your organization prepared? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment — including a full third-party risk posture review aligned to SAMA CSCC Domain 3 and NCA ECC requirements.