On June 18, 2026, CISA issued an urgent advisory warning that malicious cyber actors — believed to be a Russian-speaking criminal group — have compromised nearly 74,000 Fortinet firewall and VPN devices across 194 countries in a campaign now dubbed FortiBleed. The list of affected organizations spans global enterprises and, most alarmingly, a Turkish NATO defense contractor from which classified documents were successfully exfiltrated. As of this writing, independent telemetry puts the number of compromised devices at over 86,000.
CISA’s recommended actions are straightforward: terminate all SSL VPN and administrative sessions, reset credentials, enable phishing-resistant MFA, migrate password storage to PBKDF2 hashing, and restrict management interfaces from the public internet.
Good advice. But reactive. The more important question is: could your team have known these conditions existed before attackers found them?
The answer, for organizations running Forward Networks, is yes.
The campaign required no zero-day exploit. Attackers mass-scanned internet-facing FortiGate login endpoints, sprayed credentials across 25,000 simultaneous threads, and cracked intercepted VPN authentication hashes on a 45-GPU cluster. Successful passwords fed back into a 12-level recursive system that kept generating new candidates. Once inside, they sat quietly — collecting credentials from passing traffic before pivoting to Active Directory and RADIUS servers.
The conditions that made it possible — internet-exposed management interfaces, weak cryptographic configurations, insufficient segmentation — are exactly what Forward Networks surfaces continuously, before an adversary does.
1. Finding Every Internet-Facing FortiGate Device
The attack began with mass-scanning for internet-facing FortiGate login endpoints. The question every security team should be asking right now: do you have a complete, accurate inventory of which FortiGate devices in your network are reachable from the internet?
Not what your CMDB says. Not what someone’s spreadsheet says. What your network actually does.
Forward’s network digital twin builds a mathematically accurate, vendor-agnostic model of your entire network — and with that model, we can query every device that has an externally-reachable management or VPN endpoint. That includes FortiGate devices deployed years ago that may have drifted from their intended configuration, or devices sitting at the edge of a network segment that no one realized had internet exposure.
This isn’t a scan. It’s a model-based query run against the full topology. You get a definitive list, not a probabilistic one — and CISA’s directive to restrict management interfaces from the public internet becomes something you can verify continuously, not just act on once.
2. Cryptographic Resistance: Are Your VPN Configs Actually Hardened?
This is where FortiBleed gets technically important, and where Forward’s Network Query Engine (NQE) delivers direct value.
CISA specifically called out the need to migrate FortiGate admin credential storage to PBKDF2 — a modern password hashing algorithm designed to be computationally expensive and resistant to GPU-accelerated cracking. The attackers in this campaign used a 45-GPU cluster to crack intercepted VPN authentication hashes. Devices still using legacy hashing (MD5, SHA-1) or weak IKE cipher suites were crackable at scale. Devices using strong, modern cryptography were not.
Forward’s NQE lets you query device configurations fleet-wide to verify cryptographic posture across every FortiGate VPN deployment:
-
IKE Phase 1 and Phase 2 cipher suites — flag any tunnel using deprecated algorithms: DES, 3DES, MD5, SHA-1, or Diffie-Hellman groups below DH14
-
Password hashing algorithms — identify devices not yet migrated to PBKDF2
-
Authentication methods — surface any VPN endpoints using password-only auth rather than certificate-based or MFA-enforced flows
-
Lockout and rate-limiting configs — verify that brute-force protections are in place on all internet-facing endpoints
The difference between a device that gets cracked and one that doesn’t often comes down to a single configuration value. NQE makes that check automatic and continuous. Any drift from your approved cryptographic baseline triggers an alert — not a breach notification six months later.
3. VPN Inventory: Find All Devices with VPN Configured
You cannot protect what you cannot see. Before you can harden your VPN posture, you need a complete picture of every device in your network that has VPN configured — not just the ones you intended to deploy.
With Forward, you can run an NQE query to enumerate every device with VPN configuration present, categorized by type (IPsec, SSL-VPN, etc.), authentication method, and exposure profile. This gives security and network teams a single authoritative answer to: “Where is VPN running across our environment?”
For large federal networks — where infrastructure spans multiple enclaves, legacy segments, and contractor-managed environments — this kind of continuous inventory is the foundation of any meaningful VPN security posture.
4. Blast Radius: What Can a Compromised VPN User Actually Reach?
Once inside a FortiGate device, the attackers pivoted directly to Active Directory and RADIUS servers. The critical question isn’t just “how did they get in” — it’s “why could they reach those servers once they were in?”
Forward’s blast radius analysis answers this directly. Given a compromised VPN user or endpoint, we can model exactly which network destinations are reachable from that point — across all hops, ACLs, routing policies, and firewall rules — using mathematical path analysis against the full network model.
This means you can proactively answer:
-
Can a VPN user reach Domain Controllers or RADIUS servers directly?
-
Is Active Directory management traffic traversing the same segment as VPN-authenticated user traffic?
-
Which crown jewels — classified enclaves, OT networks, key infrastructure — are reachable from a compromised VPN session?
If the answer to any of those is “yes” and that wasn’t intentional, you know where to focus your segmentation work before an attacker maps it out for you.
5. Isolation Verification: Are VPN Users Actually Restricted?
Security policy says VPN users are restricted to specific network zones. But is that what the network actually enforces?
Intent and implementation diverge constantly — through config changes, routing updates, firewall rule edits, and emergency exceptions that never get cleaned up. Forward’s verified isolation checks let you continuously confirm that VPN-authenticated users cannot reach destinations they shouldn’t.
You define the policy — “VPN users must not have reachability to AD management subnets” or “Remote users must be restricted to zones A and B only” — and Forward verifies it mathematically against the live network model. Every time anything changes in the network, the check reruns. You get an alert if the isolation breaks, not a post-incident forensic report.
The Bigger Picture
FortiBleed wasn’t enabled by a sophisticated exploit. It was enabled by an accumulation of ordinary configuration debt: internet-facing devices that shouldn’t have been exposed, cryptographically weak VPN configs that hadn’t been audited, and insufficient segmentation that let attackers pivot freely once inside.
CISA’s advisory gives you the right checklist. Forward Networks gives you continuous, automated verification that the checklist stays green — across your entire environment, every time anything changes.
For government and defense networks, where a single compromised contractor can mean exfiltrated classified material and mission disruption, that continuous verification isn’t a nice-to-have. It’s a requirement.
If you’re wondering whether your FortiGate deployments are exposed to the conditions that enabled FortiBleed, let’s talk. The first step is getting your network into a digital twin — and the answers come quickly.
