Marquis Sues SonicWall, Alleging Vendor's Breach Led to Ransomware Attack on 74 Banks
Fintech Firm Marquis Sues SonicWall, Blaming Vendor for 2025 Ransomware Attack
Impact Scope
Affected Companies
Industries Affected
Geographic Impact
Related Entities(initial)
Organizations
Full Report(when first published)
Executive Summary
Marquis Software Solutions, a provider of data analytics tools for financial institutions, has filed a lawsuit against cybersecurity vendor SonicWall, alleging that a security failure at SonicWall was the root cause of a ransomware attack against Marquis. The complaint, filed on February 25, 2026, claims that a 2025 breach of SonicWall's MySonicWall cloud service exposed sensitive configuration data for Marquis's firewall. This data, including unencrypted MFA scratch codes, was allegedly used by attackers to bypass security controls and execute a ransomware attack in August 2025. The attack caused significant disruption for 74 of Marquis's banking clients. This lawsuit represents a critical test of vendor liability in the context of supply chain security.
Threat Overview
The lawsuit outlines a complex supply chain attack. The core allegation is that a vulnerability in SonicWall's systems led to the compromise of Marquis, one of its customers.
- Vendor Breach: In February 2025, an API code change by SonicWall allegedly created a vulnerability in its
MySonicWallcloud backup service. - Data Exposure: Threat actors exploited this flaw to access and steal sensitive backup files belonging to SonicWall customers, including Marquis. These backups contained firewall configurations, encrypted credentials, and, critically, unencrypted MFA emergency passcodes (scratch codes).
- Customer Compromise: In August 2025, attackers used the stolen configuration data and MFA scratch codes to bypass Marquis's own security defenses, which included an up-to-date SonicWall firewall and MFA.
- Ransomware Attack: Once inside the network, the attackers deployed ransomware, leading to service disruptions for dozens of banks.
Marquis accuses SonicWall of gross negligence for storing MFA scratch codes in an unencrypted format and for failing to notify them that their firewall's security posture had been compromised by the vendor's own breach.
Technical Analysis
This incident is a prime example of a Trusted Relationship attack (T1199), where an organization is compromised by exploiting its reliance on a third-party vendor. The key technical failures alleged in the lawsuit are:
- Insecure Credential Storage: Storing unencrypted MFA scratch codes alongside firewall backups is a severe security misstep. It provided attackers with a direct way to bypass a critical security control.
- API Vulnerability: The initial vector was an insecure API, a common target for attackers seeking access to cloud-based services and data.
- Lack of Transparency: The alleged failure to notify customers of a breach that exposed their security configurations prevented Marquis from taking proactive defensive measures.
Impact Assessment
The impact of this supply chain attack is multi-faceted and severe:
- For Marquis: The company has suffered "significant commercial and reputational harm." It is now the defendant in numerous class-action lawsuits from its affected clients, seeking millions in damages. The cost of incident response, recovery, and legal battles is substantial.
- For Marquis's Clients: 74 U.S. banks experienced service disruptions, impacting their operations and potentially their customers.
- For SonicWall: The company faces significant legal and reputational risk from the lawsuit. If the allegations are proven, it could set a precedent for vendor liability in similar incidents.
- For the Industry: This case highlights the systemic risk inherent in the cybersecurity supply chain. Organizations are not just responsible for their own security but are also deeply affected by the security posture of their vendors.
IOCs
No specific technical IOCs related to the ransomware attack itself have been disclosed in the legal filings.
Detection & Response
- Vendor Breach Monitoring: Organizations must have a process for monitoring security news and breach notifications related to their critical vendors.
- Anomalous MFA Usage: Security teams should monitor for and alert on the use of emergency MFA scratch codes, as this is an infrequent and high-risk event. This can be a key indicator of an account takeover attempt.
- Firewall Configuration Audits: Regularly audit firewall configurations for unauthorized changes. A sudden, unexplained change could be a sign that an attacker with access to backup data is modifying rules to facilitate their attack.
Mitigation
- Third-Party Risk Management (TPRM): Implement a robust TPRM program that includes thorough security vetting of all vendors, especially those providing security products. This should include reviewing their security practices, certifications (e.g., SOC 2), and incident notification policies.
- Defense in Depth: Do not rely on a single vendor or product for security. Implement layered controls so that the failure of one component (like a firewall) does not lead to a full compromise. This is a core principle of D3FEND's
Platform Hardening (D3-PH). - Assume Breach Mentality: Operate under the assumption that any part of your infrastructure, including security tools from trusted vendors, could be compromised. Implement strong monitoring, segmentation, and incident response capabilities to detect and contain threats quickly.
- Contractual Obligations: Ensure that vendor contracts include clear language regarding security standards, liability, and timely breach notification requirements.
Timeline of Events
Article Updates
February 27, 2026
New details emerge on SonicWall API flaw, revealing attackers guessed serial numbers to download unauthenticated backups with plaintext MFA codes. Marquis now faces 36 class-action lawsuits.
Update Sources:
MITRE ATT&CK Mitigations
Third-party Software
Implementing a strong Third-Party Risk Management (TPRM) program to vet the security practices of all vendors is critical.
Multi-factor Authentication
Ensuring that vendors implement MFA securely, without insecure fallback mechanisms like unencrypted scratch codes.
Mapped D3FEND Techniques:
D3FEND Defensive Countermeasures
This incident highlights a catastrophic failure in configuration management by the vendor. For SonicWall and other service providers, this means implementing strict hardening standards for how customer data is stored. Sensitive information like MFA scratch codes must never be stored in plaintext. They should be encrypted at rest, and access should be tightly controlled and logged. For customers like Marquis, this means demanding transparency from vendors about their data handling practices. Organizations should ask vendors specifically how their configuration backups are secured and what protections are in place for sensitive elements like credentials and recovery codes. If a vendor cannot provide satisfactory answers, alternative solutions should be considered.
To detect the abuse of stolen MFA codes, organizations should implement authentication event thresholding and alerting. The use of an emergency scratch code is a high-risk, low-frequency event that should immediately trigger a high-priority alert to the security team for investigation. The alert should contain context such as the user account, source IP address, and time of access. This allows the security team to quickly verify the legitimacy of the action with the user. If the user did not initiate the access, it is a clear sign of an account takeover in progress, enabling a rapid response to lock the account and invalidate the session before the attacker can cause further harm.
To defend against the misuse of legitimate-seeming access, organizations should analyze resource access patterns. In this case, even if the attacker used a valid MFA code to authenticate, their subsequent actions would likely deviate from normal administrative behavior. A UEBA (User and Entity Behavior Analytics) system could detect that an account, after authenticating from an unusual location, immediately began modifying critical firewall rules or attempting to access sensitive network segments. By baselining normal administrative activity for the SonicWall firewall, any significant deviation—such as a series of rapid, unusual rule changes—would be flagged as suspicious, providing another opportunity for detection beyond the initial authentication event.
Sources & References(when first published)
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats