Detect Fortinet Multiple Products Improper Verification of Cryptographic Signature (CVE-2025-59718) in Elastic Security
Detects exploitation of CVE-2025-59718, an improper verification of cryptographic signature vulnerability (CWE-347) affecting multiple Fortinet products. This vulnerability, listed in CISA's Known Exploited Vulnerabilities catalog, allows attackers to bypass signature validation checks, potentially enabling unsigned firmware/software installation, man-in-the-middle attacks on update channels, or code execution with elevated privileges on affected Fortinet appliances.
MITRE ATT&CK
Elastic Detection Query
sequence by host.name with maxspan=10m
[any where event.dataset == "fortinet.firewall"
and (
message like~ "*signature*fail*"
or message like~ "*unsigned*firmware*"
or message like~ "*cert*verif*fail*"
or message like~ "*bypass*sig*"
)
] by host.name
[any where event.dataset == "fortinet.firewall"
and (
event.action in ("upgrade", "firmware-install", "update")
or fortinet.firewall.subtype in ("update", "upgrade")
)
] by host.nameCorrelates Fortinet signature verification failures with subsequent firmware update or installation events within a 10-minute window, which may indicate exploitation of CVE-2025-59718.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate firmware upgrades immediately following routine certificate expiry warnings
- Automated update processes that log signature validation steps verbosely
- Security scanning tools that simulate update requests against Fortinet management interfaces
Other platforms for CVE-2025-59718
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate Fortinet Firmware Signature Bypass via Invalid Update Request
Expected signal: HTTP 400 or 403 response from Fortinet API with error body referencing signature validation failure; corresponding event in Fortinet system logs with type=event subtype=update level=alert
- Test 2Fortinet Management Interface Signature-Related Error Log Injection Test
Expected signal: Three syslog events appearing in SIEM with Fortinet device name, event type 'update' or 'system', and messages containing 'signature verification failed', 'cert verification failed', and 'unsigned firmware'
- Test 3Network-Level Simulation of Fortinet Update Channel Interception
Expected signal: Network flow logs showing Fortinet appliance connecting to update server via proxy; Fortinet logs showing certificate validation errors or signature failures when intercepted responses are presented
Response Playbook
Triage
- Identify all affected Fortinet products in the environment by cross-referencing asset inventory against Fortinet's PSIRT advisory FG-IR-25-647. Check for FortiGate, FortiManager, FortiAnalyzer, FortiProxy, and other Fortinet appliances.
- Review Fortinet device logs for the past 30 days for events containing 'signature', 'unsigned', 'certificate verification', or 'bypass' keywords. Pay particular attention to firmware update events and their associated status codes.
- Check current firmware versions on all Fortinet appliances against the patched versions listed in FG-IR-25-647. Prioritize internet-facing appliances and those handling privileged management traffic.
- Determine if any Fortinet devices recently received firmware updates that were not initiated through authorized change management processes. Cross-reference with CMDB and change tickets.
Containment
- Immediately restrict management interface access (HTTPS/SSH) to Fortinet appliances to trusted management IP ranges only. Disable any WAN-facing management access not already restricted.
- If active exploitation is suspected, isolate the affected Fortinet appliance from the network using out-of-band management, then initiate an emergency firmware upgrade to the patched version via the Fortinet upgrade tool at https://docs.fortinet.com/upgrade-tool/fortigate.
Evidence Collection
- Export full system logs from the Fortinet appliance via FortiAnalyzer or SYSLOG, preserving all firmware update, authentication, and certificate validation events from the past 90 days.
- Capture the current running configuration (`show full-configuration`) and firmware version (`get system status`) from each affected appliance before patching, preserving these as forensic artifacts.
Escalation Criteria
- !Escalate immediately if any Fortinet appliance has received a firmware or software update that cannot be verified against a known-good hash from Fortinet's official download portal.
- !Escalate if the affected Fortinet device is a perimeter firewall, VPN gateway, or management system with access to sensitive network segments, given the KEV designation indicates active exploitation in the wild.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Fortinet system logs located at `/var/log/syslog` or exported via FortiAnalyzer, containing firmware update history and signature verification events - >
Running firmware version and build number obtainable via `get system status` CLI command on FortiGate devices - >
Network traffic captures on management interfaces (TCP 443, 8443) showing firmware download activity and any anomalous certificate negotiation - >
Fortinet configuration backups (`execute backup config ftp/tftp`) timestamped before and after suspected compromise periods
Tuning Guidance
Begin with medium-confidence thresholds and tune based on your Fortinet appliance inventory. Establish a baseline of legitimate firmware update events by reviewing change management records. Whitelist authorized update windows and source IP ranges used by your Fortinet management team. If FortiAnalyzer is deployed, use it as the authoritative log source rather than raw syslog to reduce noise. Reduce false positives from signature-related keywords by scoping queries to specific Fortinet device hostnames or IP ranges from your CMDB. For high-value perimeter devices, consider lowering alert thresholds and requiring immediate investigation of any signature validation failure.
Hunting Queries
Hunt for Fortinet devices with an unusually high frequency of firmware update events over the past 90 days, which may indicate repeated failed attempts to install unsigned firmware or an attacker probing the update mechanism.
CommonSecurityLog
| where DeviceVendor =~ "Fortinet"
| where TimeGenerated > ago(90d)
| where DeviceEventClassID has_any ("update", "firmware", "upgrade", "autoupdate")
| summarize UpdateEvents=count(), DistinctActions=dcount(Activity), LastSeen=max(TimeGenerated) by Computer, DeviceProduct, SourceIP
| where UpdateEvents > 3
| order by UpdateEvents descindex=network OR index=security sourcetype IN ("fortigate_log", "fortinet:fortigate:firewall") earliest=-90d
| where vendor="Fortinet" AND (subtype="update" OR subtype="upgrade" OR subtype="autoupdate")
| stats count AS update_events, dc(action) AS distinct_actions, max(_time) AS last_seen by host, product, src_ip
| where update_events > 3
| sort -update_eventsAtomic Red Team Tests
Simulates an attacker attempting to submit an unsigned or maliciously crafted firmware update package to a Fortinet management API endpoint to test detection coverage for CVE-2025-59718.
Command
# Lab only - against isolated/test Fortinet appliance
curl -sk -X PUT 'https://<FORTINET_LAB_IP>/api/v2/monitor/system/firmware/upgrade' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <LAB_API_TOKEN>' \
-d '{"source": "upload", "filename": "unsigned_test.out", "bypass_sig_check": true}' \
--resolve '<FORTINET_LAB_IP>:443:<FORTINET_LAB_IP>' \
-o /tmp/fortinet_upgrade_response.json
cat /tmp/fortinet_upgrade_response.jsonCleanup
rm -f /tmp/fortinet_upgrade_response.jsonExpected Telemetry
HTTP 400 or 403 response from Fortinet API with error body referencing signature validation failure; corresponding event in Fortinet system logs with type=event subtype=update level=alert
Expected Detection
Alert triggered by KQL/SPL query detecting Fortinet API update endpoint returning 4xx with signature-related error message
Generates synthetic Fortinet syslog messages containing signature bypass keywords to validate SIEM detection rules for CVE-2025-59718 without requiring a live vulnerable appliance.
Command
# Send synthetic Fortinet syslog to SIEM listener - lab environment only
LOGSTASH_IP="<SIEM_SYSLOG_RECEIVER>"
LOGSTASH_PORT=514
python3 -c "
import socket, time
messages = [
'date=2025-12-16 time=10:00:01 devname=\"FG-LAB-01\" type=event subtype=update level=alert vd=\"root\" logdesc=\"Firmware upgrade failed\" msg=\"Signature verification failed for firmware package: invalid signature detected\"',
'date=2025-12-16 time=10:00:02 devname=\"FG-LAB-01\" type=event subtype=system level=critical vd=\"root\" logdesc=\"Certificate validation error\" msg=\"cert verification failed during auto-update, attempting bypass\"',
'date=2025-12-16 time=10:00:03 devname=\"FG-LAB-01\" type=event subtype=update level=emergency vd=\"root\" logdesc=\"Unsigned firmware install attempted\" msg=\"unsigned firmware package received from 192.168.1.100, signature check bypassed\"'
]
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
for msg in messages:
sock.sendto(msg.encode(), ('$LOGSTASH_IP', $LOGSTASH_PORT))
time.sleep(1)
print('Synthetic syslog messages sent')
"Cleanup
No cleanup required; synthetic log entries will age out per SIEM retention policyExpected Telemetry
Three syslog events appearing in SIEM with Fortinet device name, event type 'update' or 'system', and messages containing 'signature verification failed', 'cert verification failed', and 'unsigned firmware'
Expected Detection
All three signature/bypass keyword patterns trigger alerts in KQL and SPL detection rules within 5 minutes of log ingestion
Uses a man-in-the-middle proxy in a lab environment to intercept Fortinet firmware update traffic and inject a modified response, testing whether the device's signature verification can be bypassed.
Command
# Lab only - requires controlled network segment with test Fortinet appliance
# Set up mitmproxy to intercept Fortinet update traffic
pip install mitmproxy 2>/dev/null
# Create interception script
cat > /tmp/fortinet_update_intercept.py << 'EOF'
from mitmproxy import http
def response(flow: http.HTTPFlow) -> None:
if "fortiguard.net" in flow.request.host or "update.fortiguard.net" in flow.request.host:
print(f"[INTERCEPT] Fortinet update request: {flow.request.url}")
if flow.response:
print(f"[INTERCEPT] Response status: {flow.response.status_code}")
# Log headers for analysis
for k, v in flow.response.headers.items():
if any(kw in k.lower() for kw in ['sig', 'cert', 'auth', 'hash']):
print(f"[HEADER] {k}: {v}")
EOF
mitmdump -p 8080 -s /tmp/fortinet_update_intercept.py --ssl-insecure 2>&1 | tee /tmp/mitmproxy_output.log &
MITM_PID=$!
echo "mitmproxy running as PID $MITMX_PID, intercepting on port 8080"
echo "Configure test Fortinet appliance to use this host:8080 as HTTP proxy"
sleep 120
kill $MITMX_PID 2>/dev/nullCleanup
kill $(pgrep -f mitmdump) 2>/dev/null; rm -f /tmp/fortinet_update_intercept.py /tmp/mitmproxy_output.logExpected Telemetry
Network flow logs showing Fortinet appliance connecting to update server via proxy; Fortinet logs showing certificate validation errors or signature failures when intercepted responses are presented
Expected Detection
Chronicle YARAL and Elastic EQL rules trigger on network anomalies combined with Fortinet certificate verification failure events; proxy logs captured in SIEM show the interception activity