Edge VPN Appliance: Zero-Day With an Active Foothold

No. The workaround only prevents future traversal attempts; it does nothing about the foothold already established. The evidence shows the attacker logged in as admin from outside the management VLAN, which means the VLAN restriction was already bypassed or the request was proxied through the appliance itself. They created an administrator, exported the configuration, and created a working VPN user who stayed connected for four hours.

A blanket shutdown is disproportionate at quarter-end, but a short controlled outage is justified. Recommended sequence:

• Restrict the admin interface at the network edge so only the internal management VLAN can reach it, rather than relying on the pattern block, which is trivially defeated with encoding variations.
• Disable every local account not backed by the identity provider, starting with helpdesk1, svc_support, and any admin account not in use - during a scheduled 30-minute window, communicated in advance.
• Enforce MFA for all SSLVPN authentications and invalidate all existing sessions and certificates.
• Rotate every secret the exported configuration contains (see next task).

Apply the workaround as defence in depth, not as the fix. Document the outage decision and its business impact.

The configuration export is the critical loss. It typically contains local account hashes, RADIUS and TACACS secrets, the LDAP bind account and password, VPN pre-shared keys, server certificates with private keys, and internal host and group mappings. Combined with appliance admin, that means the attacker can impersonate the appliance to the directory and decrypt or intercept VPN traffic captured earlier.

Hunt list:

• Internal authentication logs for the LDAP bind account in the 03:26 onward window, especially from unexpected source hosts.
• Every internal resource reached during the four-hour helpdesk1 session - VPN concentrator session logs, firewall traffic from the VPN pool, SMB and RDP authentications from that address range.
• Directory changes from 03:12 onward: new accounts, additions to privileged groups, changes to AdminSDHolder, and new service principal names.
• Appliance integrity: firmware hash versus vendor baseline, modified login pages or JavaScript (credential harvesting), new cron or scheduled jobs, and any config element not in the golden baseline.
• Outbound traffic from the appliance itself, which is otherwise unusual.

Prioritise the directory hunt: any account created after 03:12 is suspect regardless of name.

• Rebuild rather than clean. Reimage the appliance from vendor media with a hash-verified firmware version, then restore configuration from a backup predating Monday's disclosure. Restoring the current config would re-import the attacker's accounts.
• Rotate everything the export touched: RADIUS and TACACS secrets, LDAP bind credential, VPN pre-shared keys, appliance certificates, and any local account passwords. Assume the exported material is public.
• Invalidate sessions and certificates, forcing re-enrolment for the 300 users.
• Reconcile against the golden baseline line by line: local users, group membership, admin interface exposure, MFA policy, and any custom scripts. Sign off on the diff, not on the absence of alerts.
• Confirm from outside: an external scan should show no admin interface reachable from the internet, and a test traversal request should be refused at the edge.
• Monitor for 30 days with alerting on new local accounts, admin logins from non-management networks, and configuration exports.

If the directory hunt found DCSync or privileged group changes, treat domain credentials as compromised and plan a krbtgt reset before declaring closure.