Honey they breached the SSL VPN again 

The internet is the wild wild west. Anything publicly exposed on the internet is susceptible to probing, analysis, and exploitation. Many breaches stem from the exploitation of vulnerable appliances as well as the abuse of improperly configured edge devices. Specifically, threat actors continue to target SSL VPN appliances. SSL VPN appliances continue to generate new vulnerabilities that can provide an attacker the means to gain a foothold into the network. These SSL VPN appliances, when improperly configured, also provide a mechanism for a threat actor to utilize compromised credentials for initial access. Blackpoint continues to see a rise in the compromise of edge devices, including SSL VPN, for major breaches throughout our client networks. The continued exploitation and abuse of these edge devices illustrates the need to ensure proper patching, configuration, segmentation of these appliances and the importance of a strong password policy.  

The Blackpoint SOC recently responded to a breach within an organization within the construction vertical, which highlights the danger of these edge devices. This specific organization had a SonicWall SSL VPN authentication portal publicly available on port 4433, which is the default port for the SonicWall SSL VPN.  

Figure 1: Screenshot showing SSL_VPN port exposed on public IP 

The authentication panel for these SSL_VPN appliances are an open door, when improperly configured, for threat actors that have compromised credentials. All a threat actor must do is login to the SSL VPN appliances using the compromised credentials. The caveat is whether the accounts configured to utilize SSL VPN have Multifactor Authentication (MFA). MFA is not the end all be all, however it does help deter and prevent these types of compromises.  

Figure 2: Screenshot depicting SonicWall SSL_VPN authentication panel  

In the case of the breach within the construction organization, the Blackpoint SOC began alerting to activity stemming from the Gateway IP of the organization (10.30.254[.]1). An account called itadm, was observed RDP’ing from the Gateway IP to a HyperVisor Server. Contextual analysis found that this organization setup their SSL_VPN range so that all user traffic utilizing the SSL VPN would source from 10.30.254[.]1. 

Figure 3: Admin RDP alert for the itadm account from Gateway IP to HyperVisor Server 

Once this account remoted onto the Hypervisor server, this user began immediately creating two new local accounts “itadm” and “point”, which were added to the Remote Desktop Users group. This activity stemmed from Veeam.Backup.MountService.exe and aligns with the exploitation of CVE-2024-4071. This vulnerability affects Veeam Backup & Replication versions 12.1.2.172 and below and is an unauthenticated remote code execution. In this specific breach, the threat actor leveraged it to add the “itadm” account to local administrator group and the “point” account to the local administrator group and remote desktop users’ group.  

Figure 4: Screenshot depicting exploitation of CVE-2024-4071 

After the exploitation of Veeam, the threat actor then gained access to the veeam account, which they leveraged to run SharpShares. SharpShares is an open-sourced offensive security tool that enumerates available network shares within the domain. The flags tied with this tool illustrate that 

• /ldap:all -> enumerate all domain computers 
• /filter:ipc$, print$ -> filter out ipc$ and print$ shares 
• /threads:500 -> setting max number of threads to 500 
• /outfile:C:\ProgramData\share.txt -> output results to a “share.txt” file in C:\ProgramData\ 

This specific SharpShares execution was ran in the context of the domain joined “veeam” account. The threat actor leveraged this domain joined account to execute this command so that they could properly enumerate all the available shares within this domain.  

An item to note is at this specific threat actor was utilizing C:\ProgramData\ as the staging directory for many of the tools and or binaries they dropped to disk. Threat actors leverage this directory due to this path being hidden by default. A hidden directory / path help threat actors drop binaries to a path on disk that most users do not know exist.  

Figure 5: Screenshot showing SharpShares enumeration 

After enumerating all available network shares that this threat actor had read (r) or write (w) access to, they then RDP’d from the Gateway IP to both the Domain Controller and Hypervisor server.  

Figure 6: Threat Actor RDP’ing from Gateway to Domain Controller + Hypervisor Servers 

Once the Threat Actor remotes onto both servers, they then began to attempt to exfiltrate data out. This threat actor attempted to use FileZilla, FileZilla portable, and Rclone, which were all blocked by Blackpoint’s Managed Application Control (MAC). The exfiltration attempts were done on both the Domain Controller and Hypervisor server. 

The threat actor first attempted to utilize Rclone to exfiltrate files out, however after continuing to be blocked by MAC, they then swapped to FileZilla. FileZilla was also blocked by MAC which prevented any exfiltration from this network. The blocking of both FileZilla and Rclone illustrates the importance of Managed Application Control / Application control within your network. This safeguard proactively prevents unauthorized applications from running and can stop attempted exfiltration by a threat group.   

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

Figure 7: Screenshot showing attempted exfiltration attempts via FileZilla, FileZilla portable, and Rclone 

 This breach illustrates how threat actors leverage these SSL VPN appliances for initial access and how quickly they move throughout an environment. Not only are they looking to compromise the domain, but they are also frequently targeting the “crown jewels” of the environment, which is typically the Hyper Visor servers / Cluster Management.  

Figure 8: Screenshot showing observed kill chain  

7 Steps for Prevention 

1. Ensure all SSL VPN appliances are patched and up to date 
2. Implement access controls to restrict unauthorized access to the SSL VPN authentication portal 
3. An example includes requiring a certificate to authenticate to the SSL VPN 
4. Ensure all SSL VPN users have MFA enabled 
5. Audit users in the SSL VPN users’ group and ensure that only required users are present within this group 
6. Audit any service accounts within the SSL VPN user group and ensure they have secure passwords 
7. Implement Application Control (Managed Application Control) to thwart the execution of unauthorized software 
8. Implement Managed Detection and Response (MDR) to actively monitor and action any unauthorized activity 

Author: Nevan Beal, Sr. MDR Analyst