Honey, They Breached SSL VPN Again: How Attackers Exploit Edge Devices

The internet is the wild wild west. Anything publicly exposed is susceptible to probing, analysis, and exploitation. Many breaches stem from vulnerable appliances and improperly configured edge devices, with SSL VPN appliances being a favorite target.

Blackpoint continues to see a rise in edge device compromises, including SSL VPNs, behind major breaches across our client networks. Below, we walk through a real breach our SOC contained and cover seven steps to reduce your exposure.

Why Are SSL VPN Appliances a Security Risk?

SSL VPN appliances sit at the network edge and are exposed to the internet by design, which makes them a prime target for initial access. The risk comes from two directions:

1. New vulnerabilities. SSL VPN appliances continue to generate exploitable flaws that can give attackers a foothold into the network.
2. Configuration and credential abuse. Even a fully patched appliance can become an open door if it’s improperly configured. Attackers with compromised credentials can log in through the authentication portal like legitimate users.

MFA matters here. Enforcing MFA on every SSL VPN account can help deter and prevent this type of compromise. MFA isn’t a silver bullet, but it adds an important layer of protection.

Defending these devices comes down to patching, configuration, segmentation, and a strong password policy. The seven steps below cover the specifics.

Anatomy of a Real SSL VPN Exploit: From Exposed Portal to Attempted Exfiltration

The Blackpoint SOC recently responded to a breach at a construction organization that highlights the danger of these edge devices. The organization had a SonicWall SSL VPN authentication portal publicly available on port 4433, the default port for the SonicWall SSL VPN.

When improperly configured, an SSL VPN appliance’s authentication panel can be an open door for threat actors with compromised credentials. All they have to do is log in. The caveat is whether the accounts configured to use the SSL VPN have Multifactor Authentication (MFA) enabled.

Stage 1: Initial Access Through the SSL VPN

In this breach, the Blackpoint SOC began alerting on activity stemming from the organization’s Gateway IP (10.30.254[.]1). An account called itadm was observed RDPing from the Gateway IP to a Hypervisor server. Contextual analysis found that the organization had configured its SSL VPN range so that all user traffic over the SSL VPN would source from 10.30.254[.]1.

Stage 2: Veeam Exploitation Using CVE-2024-40711

After remoting into the Hypervisor server, the user immediately created two new local accounts, “itadm” and “point,” and added them to the Remote Desktop Users group. This activity stemmed from Veeam.Backup.MountService.exe and aligns with exploitation of CVE-2024-40711, a critical (CVSS 9.8) unauthenticated remote code execution vulnerability affecting Veeam Backup & Replication versions 12.1.2.172 and below.

In this breach, the threat actor leveraged the vulnerability to add “itadm” to the local administrators group and “point” to the local administrators and Remote Desktop Users groups.

Stage 3: Network Share Enumeration With SharpShares

After exploiting Veeam, the threat actor gained access to the Veeam account and used it to run SharpShares, an open-source offensive security tool that enumerates available network shares within the domain. The flags tied to this execution show:

• /ldap:all enumerate all domain computers →
• /filter:ipc filter out ipc$ and print$ shares →
• /threads:500 set the maximum number of threads to 500 →
• /outfile:C:\ProgramData\share.txt output results to a “share.txt” file in C:\ProgramData\

This SharpShares execution ran in the context of the domain-joined Veeam account, allowing the threat actor to properly enumerate every share available in the domain.

One item to note is that this threat actor used C:\ProgramData\ as the staging directory for many of the tools and binaries they dropped to disk. Threat actors favor this directory because the path is hidden by default, letting them drop binaries somewhere most users may not know exists.

Stage 4: Lateral Movement to the Domain Controller & Hypervisor

After enumerating the network shares they had read (r) or write (w) access to, the threat actor RDPed from the Gateway IP to both the Domain Controller and the Hypervisor server. Attackers aren’t just looking to compromise the domain. They frequently go after the “crown jewels” of the environment, which are typically the Hypervisor servers or cluster management.

Stage 5: Exfiltration Attempted & Blocked by Managed Application Control

Once on both servers, the threat actor began attempting to exfiltrate data. They tried FileZilla, FileZilla Portable, and Rclone, all of which were blocked by Blackpoint’s Managed Application Control (MAC). The exfiltration attempts targeted both the Domain Controller and the Hypervisor server.

The threat actor first tried Rclone. After being repeatedly blocked by MAC, they switched to FileZilla, which was also blocked. MAC prevented any exfiltration from this network. This safeguard proactively stops unauthorized applications from running, cutting off a threat group’s exfiltration path.

Stage 6: Containment by the Blackpoint SOC

Before the threat actor had a chance to debug any of their errors, the Blackpoint SOC had already isolated all affected devices and worked with the partner to quickly disable the compromised accounts and take down the SSL VPN.

This breach illustrates how threat actors leverage SSL VPN appliances for initial access and how quickly they can move through an environment once inside.

SonicWall SSL VPN Vulnerabilities & Edge Device Risk

SonicWall SSL VPN appliances remain a target for attackers looking for initial access. Vulnerabilities, exposed VPN portals, and compromised credentials can give threat actors a way into an environment.

Blackpoint has also tracked active exploitation of a critical SonicWall vulnerability, showing how attackers can use these weaknesses to gain access through edge devices.

Read the full details on our blog about active exploitation of a critical SonicWall SSL VPN vulnerability.

How to Prevent SSL VPN Attacks: 7 Steps

Preventing SSL VPN attacks requires more than patching vulnerabilities. Organizations should also control who can access the VPN, secure credentials, limit what applications can run, and maintain continuous monitoring and response.

1. Patch SSL VPN appliances promptly. Most exploited SSL VPN vulnerabilities have patches available long before mass exploitation begins.
2. Restrict access to the authentication portal. Implement access controls, such as requiring a certificate to authenticate to the SSL VPN, so the portal isn’t an open door for anyone with stolen credentials.
3. Enforce MFA on every SSL VPN account. No exceptions. A single non-MFA account can give attackers a way in.
4. Audit the SSL VPN users’ group. Include only users who genuinely need remote access.
5. Audit service accounts with SSL VPN access. Ensure they have strong, unique passwords, and reset credentials after appliance migrations or upgrades.
6. Implement application control. Managed Application Control blocks unauthorized software from executing. In the breach above, it stopped Rclone and FileZilla from exfiltrating a single file.
7. Deploy Managed Detection and Response (MDR). Active 24/7 monitoring and response can turn an attacker inside the network into a contained incident instead of a headline.

Keep SSL VPN Access From Becoming an Open Door

SSL VPN appliances are exposed to the internet by design, which makes them a permanent target. As this breach shows, an attacker doesn’t need a sophisticated exploit to get in, a valid credential on an account without MFA is enough. From there, the movement to domain controllers and hypervisors happens fast.

What stopped this one wasn’t a single control. Managed Application Control blocked every exfiltration tool the attacker tried, and the Blackpoint SOC isolated the affected devices, disabled the compromised accounts, and took down the SSL VPN before any data left the network. Detection identified the problem; response ended it.

See what 24/7 detection and response looks like in your clients’ environments.

Request a Demo →