SonicWall Credential Attacks

The current trigger is credential abuse, not a new SonicWall exploit: five IPs achieved unauthorized logins during a three-day campaign affecting 30 organizations.¹

The practical backup-to-network pivot is: steal the .EXP file, decode the readable configuration, map the exact exposed VPN and trust paths, combine that knowledge with separately usable credentials or trust material, establish a permitted firewall/VPN session, and inherit that session's authorized routes into the on-premises network. The backup improves targeting; it does not by itself prove password decryption or MFA defeat.^{2, 3, 4}

Configuration theft could make later attacks more targeted, but public evidence does not prove it supplied the July credentials or connect the campaign to Akira.^{2, 9, 7}

SonicWall firewalls and VPNs are the gatekeepers between the internet and internal business systems. On July 25–27, 2026, Huntress observed attackers testing stolen or reused credentials at scale and successfully logging into SonicWall services at 30 organizations. Because the activity used working accounts rather than a demonstrated software exploit, installing the latest firmware alone does not answer whether access occurred.¹

The credential source is unknown, but the separate 2025 MySonicWall incident explains why a cloud backup can matter to an on-premises firewall. SonicWall says an .EXP backup is a full device snapshot. Its general configuration becomes readable after simple decoding and can expose the exact appliance, enabled internet-facing services, VPN policies, accounts, authentication servers, routes, network objects, and peer relationships. Passwords and keys remain individually encrypted, so possession is not the same as having every secret. Even so, the file removes much of an attacker's reconnaissance work and identifies precisely which credentials, portals, shared secrets, and trust paths are worth targeting. SonicWall's unusually broad reset matrix—local users, TOTP bindings, LDAP/RADIUS/TACACS secrets, IPSec keys, APIs, routing and management credentials—reflects that risk. No retained source proves these backups supplied the July 2026 credentials.^{2, 3}

The next step requires usable access material or a weak path. An attacker can combine the configuration map with a separately stolen or reused password, unchanged VPN/shared secret, active session, or other configured trust. Rapid7 documented one concrete apparent-MFA-bypass mechanism in separate Akira cases: an attacker with a valid username and password could reach a publicly exposed Virtual Office portal and bind the attacker's own TOTP before using SSLVPN. SonicWall also warns that default LDAP-group configuration can authorize users more broadly than intended. Thus a fully patched appliance with 'MFA enabled' can still admit an attacker when the actual login path allows hostile enrollment, session reuse, over-broad authorization, or a service outside the expected MFA policy. Once the firewall grants the session, it can legitimately route that attacker toward the internal systems allowed for the identity or tunnel.^{4, 6, 3}

Do not collapse the evidence into one Akira story. Akira has supported historical use of SonicWall SSLVPN and valid-account conditions, but the July credential-stuffing campaign is unattributed. SonicWall described the MySonicWall actor as state-sponsored, while the public evidence reviewed does not connect that incident to Akira. The INC/SMA1000 zero-day campaign affects a different SonicWall product and remains separate.^{1, 4, 7, 8}

The decision is to treat successful authentication as a potential incident. Preserve logs, identify every affected account and session, complete the vendor credential-reset matrix, rebind TOTP, validate local and directory authorization, review configuration and internal access, and document whether the evidence supports attempts only, perimeter access, downstream compromise, data loss, or ransomware.^{1, 3}