Exploring SonicWall techSupport Exports

An investigation into a compromised SonicWall appliance turned up an unexpected discrepancy. Authentication logs showed a successful login to the VirtualOffice portal, yet there was no evidence that the configured SAML authentication flow had ever executed.

The credentials were clearly accepted. The question was how.

Investigating that question turned into a useful excuse to spend some time with SonicWall’s techSupport package— a diagnostic export that contains considerably more forensic value than its name suggests.

Authentication Flow

SonicWall exposes a number of authentication-related events, each representing a different interface or authentication path:

29 — Successful Admin Login
31 — Successful User Login
199 — Admin Login from CLI
235 — Admin VPN Login
236 — Admin WAN Login
237 — User VPN Login
238 — User WAN Login
1080 — Successful SSLVPN User Login

This is almost certainly not exhaustive, but it’s sufficient for understanding this investigation. Adrian S.’s excellent event reference has remained an invaluable resource for years:

https://gist.github.com/adriansr/d7ad20e15fca1ef2df6a4cdeb53b2989

The distinction between Events 238 and 1080 is particularly important.

Event 238 represents a successful authentication to the VirtualOffice portal. Event 1080 is emitted after a successful SSLVPN authentication, typically through NetExtender.

The observed activity generated Event 238, reported a session type of Portal, and never progressed to Event 1080. Whether the actor intentionally stopped after validating credentials or the authentication flow was interrupted is impossible to say. What wasn’t present, however, was any indication that SAML participated in the authentication process despite the appliance being configured to require it.

That raised an obvious question: was this expected behavior, a configuration issue, or something more interesting?

Anatomy of a `techSupport` Package

If you’re working a SonicWall investigation, the techSupport export should be one of the first artifacts you collect.

The archive contains configuration backups, diagnostic output, crash data, and numerous plaintext .wri files describing nearly every aspect of the appliance’s operational state. Some of the exported material may contain credentials or other sensitive configuration, so handle the package accordingly.

The .wri files themselves are plaintext despite the extension and can be opened directly in most editors.

Each file is organized into hierarchical sections:

#$SECTION : System_Start
    Status
    Licenses
    Administration
    Certificates
    ...
#$SECTION : System_End

Individual sections contain either key/value data or structured blocks introduced by subheadings such as:

--User Object Table--

On an NSA 2700 running firmware 7.3.2-7010-R9118, the primary techSupport.wri contained 134 top-level sections. The exact layout appears to vary by firmware version.

The structure isn’t especially pleasant to parse programmatically, but it’s remarkably easy to navigate interactively.

High-Value Telemetry

DHCP Configuration

The #Network : DHCP Server section contains DHCP pool configuration for interfaces managed by the appliance.

When investigating activity originating from internal addresses, this can provide useful historical context even after operational logs have rotated. It’s an easy way to determine whether an address was expected to exist on a given interface and how the appliance was configured to allocate it.

Local Groups

One of the more valuable sections is #Users : Local Groups.

This section describes local authorization objects, imported LDAP groups, and— most importantly— the relationship between them.

4, SonicWall SSLVPN Users
    Privileges:            0x1000: SSLVPN
    Members:               SUDOREM\SSLVPN Users

5, SUDOREM\SSL VPN Users
    LDAP location:         sudorem.dev/SUDOREM/Groups/Security Groups
    Privileges:            0x0: None; cumulative: 0x1000: SSLVPN
    Group Memberships:     SonicWall SSLVPN Users

Although the LDAP-backed group possesses no direct privileges, it inherits SSLVPN access through membership in the local SonicWall SSLVPN Users group.

That relationship immediately answers several incident response questions:

Which LDAP groups can access SSLVPN?
Which permissions originate locally versus LDAP?
Which Active Directory groups require review?
Which users ultimately inherit administrative or VPN access?

When authentication logs are incomplete, understanding effective authorization often becomes just as important as understanding authentication itself.

Configuration Audit

Another unexpectedly valuable section is Configuration Audit.

This contains a rolling history of administrative actions including configuration exports, firmware updates, user creation, configuration changes, and generation of the techSupport package itself.

On appliances with relatively little administrative activity, this audit history can span months, or even years, making it an excellent source of historical context after standard logs have rotated.

User Objects

Near the end of the export, the User Object Table and User Group Table provide another useful source of identity information.

Among other details, these tables expose:

Local users
Imported LDAP users
Group memberships
OTP status
Creation timestamps
Last modification timestamps

These become particularly useful when determining whether local accounts were created by an adversary, whether MFA was configured for specific users, or whether suspicious accounts remain present after an incident.

Why It Matters

The real value of the techSupport package isn’t any single section.

It captures the appliance’s configuration as a whole. Authentication settings, LDAP mappings, DHCP configuration, administrative history, user objects, certificates, routing, and dozens of other operational details all exist within a single artifact.

Whenever there’s uncertainty about how a SonicWall should behave, the answer is often somewhere inside the export.

Closing Thoughts

The original question remains unanswered.

The appliance contained valid LDAP configuration. It also contained valid SAML configuration. Yet every available artifact suggested the observed authentication bypassed the expected SAML flow entirely while still successfully authenticating the user to VirtualOffice.

Whether that’s an implementation detail, a configuration edge case, or evidence of something more interesting remains an open question.

The investigation did, however, reinforce something equally valuable: SonicWall’s techSupport package is one of the richest forensic artifacts available from the platform. Even after logs have rotated or memory has been lost, it often preserves enough operational context to reconstruct how the appliance was configured— and, just as importantly, how it was expected to behave.

Key Takeaways

Collect the techSupport package early during SonicWall investigations.
Treat the .wri files as primary forensic artifacts rather than diagnostic output.
Review Local Groups to understand effective LDAP authorization.
Use Configuration Audit to reconstruct administrative activity after logs have rotated.
User Object and User Group tables provide valuable identity and persistence telemetry.
When investigating authentication anomalies, configuration state is often just as valuable as authentication logs.

Observed signals