Fortinet SSL VPN Brute Force Attacks in 2026: What’s Changed

By ThreatListPro Security Team · Published March 14, 2026 · Last verified: March 14, 2026

The 2025–2026 Fortinet VPN Attack Surge

Fortinet SSL VPN has become the number-one target for VPN brute force campaigns worldwide. A perfect storm of critical vulnerabilities, massive install base, and easily discoverable login portals has made FortiGate the preferred target for credential-based attacks—even on fully patched devices.

The numbers tell the story. VPN brute force attacks targeting FortiGate devices surged 300% between 2024 and early 2026. In February 2025, security researchers documented a massive botnet scanning campaign involving over 24,000 IP addresses specifically targeting FortiGate SSL VPN endpoints. The campaign used coordinated credential-stuffing techniques across rotating residential and cloud IPs, making traditional rate limiting almost useless.

Multiple critical CVEs accelerated the targeting. CVE-2024-21762 (CVSS 9.6, out-of-bound write in SSL VPN) and CVE-2023-27997 (CVSS 9.2, heap buffer overflow in SSL VPN pre-authentication) put FortiGate in the spotlight. Even after organizations patched these vulnerabilities, their FortiGate devices remained on attacker target lists. Patching closes the exploit, but it does not stop credential-based brute force attacks that require no vulnerability at all.

Why FortiGate Is Disproportionately Targeted

FortiGate is not the only VPN platform under attack—Palo Alto GlobalProtect, Cisco AnyConnect, and SonicWall all face brute force campaigns. But FortiGate takes a disproportionate share of the attacks for several specific reasons:

• Massive install base: Fortinet has shipped over 500,000 FortiGate devices globally. This makes it the single largest addressable attack surface for VPN brute force campaigns. Attackers optimize for volume—writing a bot that targets FortiGate reaches the most potential victims with the least development effort.
• SSL VPN often enabled by default: Many FortiGate deployments have SSL VPN enabled even when the organization does not actively use it. A default-on feature means thousands of devices expose a VPN login page to the internet without the admin ever consciously choosing to do so.
• Login page is easily identifiable: The FortiGate SSL VPN login page at /remote/login has distinct response headers and HTML patterns that automated scanners identify instantly. An attacker scanning the entire IPv4 space can build a list of FortiGate targets in hours.
• Historical CVEs create a target-rich environment: CVE-2024-21762, CVE-2023-27997, CVE-2022-42475, and CVE-2024-23113 generated massive media coverage. Every CVE announcement triggers a wave of scanning as attackers race to find unpatched devices. Even after patching, these devices remain on target lists used for credential attacks.
• FortiOS version fragmentation: Organizations running older FortiOS versions may lack security features available in newer releases, creating an uneven defense landscape that attackers exploit.

Attack Anatomy: How FortiGate VPN Brute Force Works

Understanding how these attacks operate is essential for defending against them. Here is the typical attack chain targeting FortiGate SSL VPN:

Step 1: Discovery

Botnets continuously scan the IPv4 address space on ports 443 and 10443 (the default FortiGate SSL VPN ports), looking for the /remote/login path. When a FortiGate SSL VPN portal responds, the bot fingerprints it by examining HTTP response headers, HTML content, and TLS certificate details. This scan runs 24/7 and discovers new FortiGate instances within hours of them going online.

Step 2: Identification

Once a FortiGate is discovered, the bot confirms the target by checking response characteristics specific to FortiOS. It may also attempt to determine the FortiOS version to identify potential CVE vulnerabilities. The target IP, port, and version information are added to a centralized target database shared across the botnet.

Step 3: Credential Attack

The botnet launches credential attacks from rotating IPs—often hundreds or thousands of different source addresses. A typical campaign involves:

• 5,000 to 50,000 login attempts per day against a single FortiGate
• Credential stuffing using username/password pairs from dark web breach databases
• Password spraying using common passwords (e.g., “Summer2025!”, “Welcome1”, “VPN@company”) against enumerated usernames
• IP rotation every 5–20 attempts to evade per-IP rate limiting
• Timing variation to avoid triggering simple threshold-based detections

Step 4: Persistence

These campaigns do not stop after a few hours. Botnets maintain target lists and return repeatedly—daily, weekly, sometimes for months. Even if no credentials are compromised, the sustained attack causes account lockouts, log noise, helpdesk overload, and authentication infrastructure strain.

Immediate Defenses

Here are the most effective defenses for FortiGate SSL VPN brute force, ranked by how quickly you can deploy them:

1. IP Blocklist via External Threat Feed (5 Minutes)

The fastest defense available. FortiGate natively supports External Threat Feeds (also called External Block Lists) under Security Fabric > External Connectors. You paste a blocklist URL—such as ThreatListPro’s curated VPN brute force list—and FortiGate automatically downloads and enforces it.

ThreatListPro’s blocklist contains IP addresses actively engaged in VPN brute force attacks, updated every 60 seconds. When configured as an External Threat Feed, FortiGate blocks these IPs at the perimeter before they can submit a single login attempt. No authentication load, no account lockouts, no log noise from known attackers.

2. Local-in Policy Rate Limiting (30 Minutes)

FortiGate local-in policies allow you to rate-limit connections destined for the FortiGate itself, including SSL VPN. You can set thresholds like “no more than 10 connections per minute per source IP to port 443.” This slows down brute force bots significantly but requires careful tuning—set the limit too low and you block legitimate users connecting from NAT’d networks or shared IPs.

Local-in policies are particularly effective when combined with an IP blocklist. The blocklist handles known attackers, while rate limiting catches new attackers not yet on the list.

3. FortiToken MFA (Weeks)

Multi-factor authentication is the gold standard for VPN security. FortiToken (hardware or mobile) adds a second factor that prevents credential-only access. Even if an attacker guesses a correct password, they cannot complete authentication without the token.

However, MFA rollout is a significant project. You need to procure FortiTokens, configure the FortiAuthenticator or FortiGate token server, enroll every user, handle exceptions for service accounts, and provide user support during the transition. For organizations with hundreds of users, this typically takes 4 to 8 weeks.

4. Certificate-Based Authentication (Months)

The most robust solution: require a client certificate for SSL VPN connections. Without the correct certificate, FortiGate refuses to present the login page at all—the attacker cannot even attempt a password. This completely eliminates brute force attacks against your SSL VPN.

The deployment complexity is significant. You need an internal PKI or integration with a third-party CA, an MDM solution to distribute certificates to managed devices, a process for certificate renewal and revocation, and a plan for BYOD or contractor access. Expect a 3 to 6 month deployment timeline.

FortiGate-Specific Configuration Tips

Beyond the layered defenses above, these FortiGate-specific settings reduce your attack surface immediately:

• Disable SSL VPN if not needed: If your organization uses IPsec VPN or does not need remote access VPN at all, disable SSL VPN entirely in config vpn ssl settings. This eliminates the attack surface completely.
• Restrict source IPs: If your VPN users connect from known IP ranges (e.g., specific ISPs or countries), configure a source address restriction on the SSL VPN portal. Only allowed source IPs can reach the login page.
• Enable geo-blocking: Use FortiGate’s GeoIP policies to block VPN access from countries where you have no employees or contractors. This eliminates a large percentage of botnet traffic originating from high-attack regions.
• Monitor FortiAnalyzer for brute force patterns: If you run FortiAnalyzer, create alerts for sustained authentication failures from multiple source IPs. Look for patterns like 100+ failed logins in 10 minutes or failed logins from 50+ unique IPs in an hour.
• Change the default SSL VPN port: Moving SSL VPN from port 443 to a non-standard port is not security—it is obscurity. But it does reduce noise from automated scanners that only check default ports. Use this as a supplement, not a primary defense.
• Update FortiOS regularly: Keep FortiOS on the latest stable release to ensure you have the newest security features and patches for known CVEs.

The Path Forward

Defending FortiGate SSL VPN against brute force requires a layered approach. No single solution is sufficient, but the order in which you deploy them matters enormously:

• Day 1 — IP Blocklist: Deploy ThreatListPro as an External Threat Feed on your FortiGate. This takes 5 minutes and immediately blocks known attacker IPs at the perimeter. Account lockouts drop, log noise decreases, and your authentication infrastructure gets relief.
• Week 1 — Rate Limiting and Geo-Blocking: Configure local-in policies to rate-limit SSL VPN connections. Enable GeoIP blocking for countries you do not operate in. These catch attackers not yet on the blocklist.
• Month 1–2 — MFA: Plan and begin your FortiToken rollout. MFA prevents credential compromise even if an attacker evades your perimeter defenses.
• Month 3–6 — Certificate Auth: For maximum security, deploy client certificate requirements for SSL VPN. This eliminates the brute force attack surface entirely.

ThreatListPro works alongside all of these defenses. It is not a replacement for MFA or certificate auth—it is the immediate-relief layer that protects your FortiGate while you plan and execute those longer-term projects. With blocklist updates every 60 seconds, new attacker IPs are blocked automatically without any manual intervention.