SonicWall confirmed yesterday that configuration backups stored in some MySonicWall customer accounts were accessed without authorization in a recent security incident. The breach involves preference files containing sensitive firewall settings such as admin credentials, VPN configurations, and certificates.

The affected files were uploaded by customers using SonicWall’s cloud-based configuration backup system, which is designed to support restoration and continuity during upgrades or outages. SonicWall has since blocked the access path and begun notifying customers. The incident presents significant risk beyond exposed passwords, including potential compromise of network architecture and access controls.

This breach stems from a mix of mismanaged credentials, inherited configuration drift, insufficient separation of duties within cloud infrastructure, and unaddressed risks created by convenience-based backups.

What’s in a SonicWall Configuration File?

Configuration files in SonicWall’s ecosystem typically contain:

• VPN pre-shared keys and tunnel configurations
• Administrator credentials, often reused or inherited
• LDAP bindings and user group permissions
• Internal hostname and IP schema
• Logging, monitoring, and certificate settings

These files give attackers a complete snapshot of a network’s perimeter defenses. With access to a downloaded backup, adversaries can reconstruct network protections in a test environment, identify weak points, and simulate attacks without alerting the target organization.

Known Vulnerability, Ongoing Exposure

The attack activity appears to involve previously known issues in SonicWall’s SSL VPN features. A 2024 vulnerability allowed unauthorized access under specific conditions. Although a patch has been available, exploitation continues in environments where configurations were not fully hardened or where credentials were reused.

Many organizations migrating from Gen 6 to Gen 7 devices imported legacy configurations without resetting local user accounts. These accounts often remain active and linked to permissive SSL VPN or Virtual Office groups, making it easier for attackers to maintain access.

In addition, credentials stored in MySonicWall were not always rotated after backup uploads. The presence of those credentials in the exposed files increased the blast radius of the incident. Backup files uploaded for recovery purposes became a source of access and privilege information for attackers.

Vendor Portals as Risk Surfaces

This incident highlights the risks that can emerge from vendor-managed cloud services. The breach did not begin with a firewall exploit. It began with access to SonicWall’s MySonicWall portal, where configuration backups were stored by customers.

The specific method of access has not been fully detailed. However, the exposure appears to involve credential or session abuse rather than exploitation of vulnerabilities in the firewalls themselves. This shifts the point of failure to the vendor’s cloud infrastructure and raises concerns about oversight and isolation within multi-tenant platforms.

Backup files that remained in the portal after being uploaded created an unexpected point of exposure. Even devices that were fully patched could be at risk if their backups were not encrypted, restricted, or followed by proper credential management.

This type of cloud-based exposure allows threat actors to retrieve a complete picture of multiple environments with relatively little effort. The risk is magnified when vendor portals are treated as low-priority assets in enterprise risk inventories.

Implications for Security Teams

Security teams will recognize several core lessons from this breach:

• Backup files require the same protections as core infrastructure. Any file containing secrets, internal mappings, or access credentials must be treated as part of the threat surface. Vendor-hosted storage should not be assumed to offer complete isolation or protection.
• Configuration drift creates long-term exposure. When migrating between hardware generations or restoring from older backups, organizations must reset user accounts, rotate secrets, and validate group memberships.
• Cloud-based tools increase the potential impact of a breach. A single configuration file, when exposed in a cloud portal, has the potential to compromise not just one device but multiple systems and user groups across a network.

Standard security practices may not be sufficient when backup storage introduces new access pathways. Teams that maintained good hygiene but did not treat backups as sensitive assets are now facing new and unexpected risks.

Time to Reevaluate Firewall Governance

This breach reflects broader issues in how organizations manage configuration, trust, and vendor relationships. In many cases, security teams rely on vendor-hosted tools for convenience and assume they are secure by default. Backup policies often prioritize ease of use over access control or data minimization.

Now is the time to review core questions about firewall and infrastructure governance:

• Are backup processes aligned with your actual risk tolerance, or designed for convenience?
• Does your firewall management process include regular review of inherited accounts, user groups, and uploaded configurations?
• Are vendor dashboards treated as monitored, restricted environments, or assumed to be secure without review?

These questions help determine whether exposure stops at the perimeter or reaches into the core of how organizations operate and defend themselves.

The post SonicWall Confirms Unauthorized Access to MySonicWall Backup Files appeared first on Centraleyes.

*** This is a Security Bloggers Network syndicated blog from Centraleyes authored by Rebecca Kappel. Read the original post at: https://www.centraleyes.com/sonicwall-confirms-unauthorized-access-to-mysonicwall-backup-files/