Skip to content
Book a demo
All posts
News

Fortinet path traversal flaw tied to FortiGate implant in telecom intrusion

Palo Alto Networks reports that a threat actor exploited multiple Fortinet vulnerabilities against a telecommunications organization, exfiltrating a configuration archive covering more than 500 managed FortiGate firewalls. CISA has added CVE-2025-61624 to its Known Exploited Vulnerabilities list.

Published
Reading
3 min
By
Kairo

Palo Alto Networks reports that a threat actor exploited multiple Fortinet vulnerabilities in an attack against a telecommunications organization. The intrusion occurred in September 2024 and resulted in long-term access to the victim's environment.

What happened

The management layer was the target, not a single firewall. A fresh report from Palo Alto Networks shows that the same intrusion also involved , a path traversal vulnerability affecting multiple Fortinet products.

For anyone running Fortinet management infrastructure, the public listing of that flaw is the practical signal to act.

On Friday, the US cybersecurity agency CISA added to its Known Exploited Vulnerabilities (KEV) list, urging federal agencies to patch it immediately.
SecurityWeek

How it was done

As part of the observed attack, FortiJump was exploited to access a central FortiManager instance. A rogue Virtual FortiGate appliance was then registered against that instance.

From there a configuration archive was exfiltrated, containing details on FortiManager, more than 500 managed FortiGate firewalls, and the victim's network. A configuration archive of that kind is a map of the estate, which is why access to a management server matters more than access to any one device.

What to check

If you run Fortinet management infrastructure, work through these in order.

  1. Patch across every affected product

    Build an inventory of Fortinet products in scope, then compare installed firmware against the fixed versions in the vendor advisory. Treat the CISA Known Exploited Vulnerabilities entry as the deadline. Any device still on a pre-fix build after your patch window is a finding.

  2. Review every device registered to FortiManager

    Open Device Manager and list all managed devices, including virtual ones, with their serial numbers and registration dates. Reconcile that list against your asset inventory. A device you cannot map to a purchase order or a deployment ticket should be quarantined and investigated.

  3. Pull registration and authentication logs for the management server

    In FortiManager, export the event log for device registration, admin login and ADOM changes, then search for unattended registrations and logins from unexpected source addresses. Correlate against VPN and jump host records. Unmatched source IPs or out of hours activity are the markers to chase.

  4. Confirm the management plane is not reachable from the internet

    Scan your public ranges for the FortiManager management ports, for example with nmap from an external host, and check cloud security group and edge firewall rules. Any response from outside your administrative network means the exposure needs closing before anything else.

  5. Treat stored configuration data as compromised credentials

    Configuration backups usually carry shared secrets, VPN pre-shared keys, SNMP strings and local admin hashes. Identify every copy, including off box archives and ticket attachments, and rotate the secrets they contain. Leaving old keys valid is the common gap after this kind of event.

  6. Look for outbound transfers from management hosts

    Query netflow or proxy logs for large egress from your FortiManager host over the retention period you hold. Sort by bytes sent and destination. Sustained transfers to destinations outside your backup and vendor ranges warrant a full forensic review of the host.

Keep reading

More from the team
that verifies every change.

All posts

See what your application allows before an attacker does.