Intelligence Insights: September 2024

We share VPN hardening guidance to cut through the FOG (ransomware) in this month’s edition of Intelligence Insights

Highlights from August

ChromeLoader remains at the top of our most prevalent threat list for the third month in a row, and with SocGholish staying in the number 2 spot, it seems that browser-related trickery continues to have a major impact.

LummaC2 saw a wave of activity in August, claiming 4th place and tying with its highest ranking to date when it debuted on the list in November 2023.

Gootloader and XMRig are both back in the top 10 after a couple of months out of the rankings, landing in 7th and 9th places respectively. Also tied for 9th is AsyncRAT—returning to the list for the first time since April 2024—and Ippedo and Shlayer, each squeaking onto the list for the first time in over a year.

In late August we observed ransomware campaigns leveraging VPNs for initial access and for gaining further access into victims’ environments. This is not a new technique nor exclusive to ransomware actors, so we decided to dig into VPN hardening in this month’s insight. You can read more hardening guidance and recommendations below.

This month’s top 10 threats

To track pervasiveness over time, we identify the number of unique customer environments in which we observed a given threat and compare it to what we’ve seen in previous months.

Here’s how the numbers shook out for August 2024:

⬆ = trending up from previous month ⬇= trending down from previous month ➡ = no change in rank from previous month

*Denotes a tie

Ransomware affiliates abusing VPNs for initial access

At the end of August 2024, Red Canary observed ransomware incidents that leveraged virtual private networks (VPN), both as an initial access vector and to facilitate further access within organizations. Some of the activity we saw shares significant overlaps with activity tracked by Microsoft as Storm-0844. Historically tied to Akira ransomware, Storm-0844 has recently made a switch to deploying FOG ransomware. Reporting on Akira and FOG emphasizes the consistent targeting of VPN software—notably Cisco ASA—for initial access, both in recent cases and in previous attacks from more than a year ago. Akira and FOG are not the only threats that use VPNs during their attacks. 

Some fast-acting steps

There are steps you can take to rapidly respond to adversaries abusing VPN appliances during incidents. Even when these incidents begin on the appliances, adversaries must move further into the network to continue their operations. If your VPN controls allow for it, disable layer 2 (East-West) visibility to VPN clients, which will reduce what a threat actor can do. 

To improve your visibility, deploy endpoint detection and response (EDR) sensors across all systems capable of running them. Deploying sensors across your enterprise increases the likelihood of earlier detection. Unmonitored endpoints provide a blind spot for adversaries to operate and make detection far more difficult.

Guidance for hardening VPN appliances

It’s important to recognize that VPN appliances, while necessary, are high-value targets for adversaries looking to gain access to networks. To minimize the risk of adding these appliances, there are multiple configuration and architecture options to consider. If your organization uses a VPN, particularly if that VPN is a Cisco Adaptive Security Appliance (ASA), here are some suggestions for hardening your VPN attack surface.

Protocols

SSL/TLS VPN or IPSec/IKEv2? That’s the question.

Organizations that protect critical infrastructure, including CISA and Norway’s NCSC, recommend choosing IPSec/IKEv2 over SSL/TLS VPN protocols. This is largely due to IPSec being an open standard and SSL/TLS VPNs having implementation-specific changes between vendors, leading to more vulnerabilities. SSL/TLS VPNs often expose web applications on the VPN appliances to the public internet, leading to additional risk. Favoring IPSec/IKEv2 over SSL/TLS protocols decreases the services running on VPN appliances and reduces the overall surface area of the appliances.

Protocol selection is an organization-specific decision. and your organization may require SSL/TLS VPN protocols for various reasons. For example, public networks like those in libraries and restaurants often don’t support IPSec protocol as it hinders network traffic inspection.

No matter which protocol you use, we recommend taking extra precautions to harden VPN appliances where possible. These include:

•  applying updates to the appliances
• requiring certificate-based authentication
• requiring multi-factor authentication (MFA)
• segmenting their management interfaces away from public internet traffic

Applying updates

Vulnerabilities have affected multiple VPN providers in the past, and in each case the vulnerabilities were addressed through updates. We recommend applying the latest updates for your VPN appliances as they become available. If your organization already has VPN appliances that are not updated, consider prioritizing updates for vulnerabilities that have appeared in CISA’s Known Exploited Vulnerabilities catalog.

If your organization uses VPN devices that are unsupported by their vendor, we recommend moving to supported versions to obtain the latest updates and configuration options.

Authentication

Adversaries have often conducted password-spray attacks against VPN appliances, targeted login accounts with weak passwords, and leveraged accounts unprotected by MFA. Where possible, we recommend requiring client certificates for authentication or requiring strong passwords. To protect against password spraying or brute-force attacks, consider using account lockout periods for VPN users instead of allowing unrestricted bad password attempts.

No matter how you authenticate, MFA is a must-have for remote access. Multi-factor authentication prevents unauthorized access to valid accounts effectively and can stop adversaries in their tracks.

Network segmentation

VPN appliances are network devices that can allow users to join different network segments, and it’s important to make network segmentation decisions with the appliances in mind. Specifically, the management interfaces for VPN appliances should NOT be exposed to public internet traffic. Doing so prevents unauthorized access to the console of VPN appliances and it also prevents exploitation attempts against SSH services on the appliances. Management interfaces for these devices should be accessible only from internal network segments, and preferably only from specific segments related to IT management.

For organizations that want additional protection of layer 2 and 3 network traffic while connected to a VPN, you can also explore Network Access Control (NAC) solutions that manage and minimize the risk posed by devices that connect to the VPN.

While VPN appliances don’t support EDR sensors, there are endpoint detection opportunities for actions taken by adversaries during phases of their attacks. For example, use of follow-on tools like Impacket—which can be used for lateral movement from VPNs to Windows systems—gives us a detection opportunity.

Detection opportunity: Impacket secretsdump.py execution

This pseudo detection analytic identifies Impacket’s secretsdump.py script execution. secretsdump.py is remotely run on an adversary’s machine to steal credentials. The command is commonly executed by svchost.exe, which loads regsvc.dll and allows the export of credentials from the victim’s registry. The output is redirected to an eight-character TMP file within the System32 directory–svchost.exe does not usually write temp files to System32.

process == (svchost)

&&

module_name == (regsvc.dll)

&&

filemod_path_includes == (/(?i)windows\\system32\\\w{8}\.tmp$/' || '/(?i)windows\\temp\\\w{8}\.tmp$/)

Threat Detection Report midyear update

You've read about the top threats of the last month, how about for the last six months? Our midyear update to the Threat Detection Report provides in-depth analysis and actionable guidance.