FBI Warns FortiGate VPN Attacks Are Still Active

What happened

The FBI has issued a warning that the attack campaign known as FortiBleed is still active, targeting internet-exposed Fortinet FortiGate firewalls and their SSL VPN gateways. According to reporting from BleepingComputer, the attacks are locking legitimate administrators out of the very devices they depend on to manage remote access.

That last detail is the part worth pausing on. Plenty of edge-device advisories are about data theft or malware staging. This one describes attackers taking administrative control away from the owner, which means the people who would normally respond to an incident may find themselves unable to log in and fix it. Specifics beyond the FBI's warning and that reporting are still thin, so rather than guess at affected firmware builds or indicators of compromise, verify your exact model and firmware version against Fortinet's current advisories and your vendor support channel before you act.

Why this matters for Pittsburgh small and mid-sized businesses

FortiGate appliances are extremely common in the 10 to 200 employee range we work with across Allegheny, Butler, Washington, and Westmoreland counties. They are affordable, capable, and often installed years ago by whoever wired the office. That is exactly the risk profile: a competent device bought once, configured for remote access during a crunch, and then left on an aging firmware train while the business moved on to other priorities.

For a CPA firm, the timing is uncomfortable. October means extended-deadline season, staff working from home offices and client sites, and VPN usage at its annual peak. For a law firm, an edge compromise is a privilege problem before it is an IT problem, and client notification obligations follow quickly. Medical practices and billing companies face the HIPAA Security Rule's access control and audit requirements, and "the attacker changed our admin credentials" is a very hard finding to explain to an auditor or to a carrier reviewing a claim.

Defense contractors and machine shops in the Mon Valley and along the 376 corridor have a sharper exposure. If your VPN is how engineers and suppliers reach drawings, quote packages, or anything that qualifies as CUI, the boundary device is in your assessment scope. Under CMMC Level 2 and DFARS obligations, remote access controls and incident reporting are not optional, and a compromised firewall touches both. Financial services firms under the FTC Safeguards Rule are in the same boat: unauthorized access to a system holding customer information triggers response and, depending on scale, notification duties.

The practical concern for a company this size is simple. Most SMBs do not have a second administrator, an out-of-band console, or a tested configuration backup for the firewall. One device gets taken over and remote work stops cold while someone drives to the office with a serial cable.

What to do about it this week

1. Inventory what is actually facing the internet. Confirm every Fortinet device you own, its model, its firmware version, and whether SSL VPN is enabled. If no one can answer that in ten minutes, that itself is the finding. Good managed IT and RMM coverage should make this a report, not a scavenger hunt.
2. Patch to the current supported firmware, or disable SSL VPN until you can. Check Fortinet's published advisories for your specific model rather than relying on a forum post. If a device is past end of support, plan the replacement now and treat the interim as a risk you are consciously accepting.
3. Verify who holds administrative access. Review every local admin account on the firewall, delete anything stale, rotate credentials, and confirm multi-factor authentication is enforced on both admin logins and VPN user logins. Pull admin login logs and look for sessions you cannot account for.
4. Remove the management interface from the public internet. Administration should be reachable only from inside the network or through a controlled jump path. If HTTPS or SSH admin is open to the world, close it today.
5. Export and store a current configuration backup off the device. Keep it somewhere you can reach if the appliance locks you out, and document the break-glass procedure, including physical console access and who has the serial cable. Test that someone other than one person can execute it.
6. Watch the endpoints behind the firewall, not just the firewall. An edge foothold usually becomes a credential or ransomware problem next. Confirm EDR or MDR coverage is deployed everywhere, alerting to a human, and that nobody has quietly excluded a server from monitoring.
7. Decide your reporting path before you need it. Write down, in one page, who calls counsel, who calls your cyber carrier, who notifies clients, and for defense work, what your DFARS 7012 reporting steps are. Thirty minutes of planning now saves a very bad afternoon later.

Treat this as a 30-day cycle, not a one-time cleanup: by early November you should have confirmed firmware, verified MFA coverage, and tested the lockout recovery procedure at least once.

How we help

PGH Networks manages the full edge-to-endpoint stack for Pittsburgh-area firms: firewall and patch management, MFA enforcement, hardening for Microsoft 365 and hybrid environments, and layered cybersecurity monitoring that catches what a single appliance cannot. Our vCIO team folds findings like this into a technology roadmap so aging edge hardware gets replaced on a budget line instead of during an incident, with the documentation your HIPAA, SOC 2, or CMMC assessor expects. If you are not certain what your firewall is running right now, let us check it for you.

Talk to us

Call 724.888.7007 or reach us through the contact form and we will review your edge configuration and remote access controls this week.