The joint FBI-CISA advisory on Gunra ransomware confirms a troubling reality: patching alone won't save you. When ransomware groups exploit authentication bypass vulnerabilities in your perimeter devices, they're not just breaking in, they're embedding persistence mechanisms that survive your remediation efforts. The two Fortinet vulnerabilities (CVE-2024-55591 and CVE-2025-24472) being actively exploited represent a pattern you'll see again: legacy flaws in internet-facing infrastructure that attackers return to because organizations struggle with systematic remediation.
This guide helps you harden FortiOS and FortiProxy deployments against these specific exploits and the broader attack pattern they represent.
Why This Matters Now
Gunra actors exploit authentication bypass vulnerabilities to gain super-admin privileges on Fortinet devices, then establish persistence through modified authentication flows. They've successfully exfiltrated tens of terabytes of data from victim environments, operating between 10pm and 6am in the victim's time zone when monitoring coverage typically drops. Ransom demands start in the tens of millions, with negotiation windows of five to seven days.
The critical issue: applying patches closes the entry point but doesn't address backdoors already embedded in your authentication stack. If you patched CVE-2024-55591 or CVE-2025-24472 last month and declared victory, you may still be compromised.
What You Need Before Starting
Access and permissions:
- Super-admin access to FortiGate/FortiProxy management interface
- SSH access to the CLI
- Administrative credentials for your SIEM or log aggregation platform
- Write access to your configuration management repository
Technical prerequisites:
- Current FortiOS/FortiProxy version documentation
- Network diagram showing all Fortinet devices and their management interfaces
- List of all SSL-VPN users and their last authentication timestamps
- Backup of current device configurations (stored offline)
Information you'll need:
- Serial numbers of all upstream and downstream devices in your Security Fabric (if enabled)
- Current MFA implementation details for VPN access
- Log retention policies and current log storage locations
- Scheduled maintenance windows (you'll need at least two hours per device)
Step-by-Step Implementation
Phase 1: Verify Patch Status and Configuration Baseline
1. Check your FortiOS/FortiProxy versions
SSH into each device and run:
get system status
Cross-reference the version output against Fortinet's security advisories for CVE-2024-55591 and CVE-2025-24472. If you're running an affected version, schedule patching immediately, but don't stop there.
2. Export and archive your current configuration
execute backup full-config tftp [filename] [tftp-server-ip]
Store this backup on an air-gapped system. You'll need it for forensic comparison if you discover unauthorized changes.
3. Review authentication processing files
Gunra actors modify authentication flows to bypass MFA. Check for unauthorized changes to SSL-VPN authentication scripts:
show vpn ssl settings
diagnose debug application sslvpn -1
Compare the output against your known-good baseline. If you don't have a baseline, create one now from a device you're confident hasn't been compromised.
Phase 2: Harden Authentication Controls
4. Eliminate default credentials
List all administrative accounts:
show system admin
For each account, verify:
- Non-default username
- Strong password (minimum 16 characters, complexity enforced)
- Appropriate privilege level (principle of least privilege)
Disable or delete any account using default credentials immediately.
5. Enable and configure account lockout
The advisory notes Gunra exploited an SSL-VPN appliance where account lockout controls weren't present. Configure lockout thresholds:
config system global
set admin-lockout-threshold 3
set admin-lockout-duration 900
end
This locks accounts after three failed attempts for 15 minutes. Adjust based on your risk tolerance, but never leave this disabled.
6. Enforce MFA for all administrative access
If you haven't already:
config system admin
edit [admin-username]
set two-factor fortitoken
next
end
Critically: verify that MFA enforcement can't be bypassed through alternate authentication paths. Review your VDI authentication portal servers for unauthorized modifications to authentication processing files.
Phase 3: Restrict Security Fabric Exposure
7. Audit Security Fabric configuration
If you've enabled Security Fabric, CVE-2025-24472 allows attackers with knowledge of device serial numbers to gain super-admin privileges on downstream devices. Review your fabric topology:
diagnose sys csf device-list
Document which devices are exposed and whether their serial numbers could have been obtained through reconnaissance.
8. Implement CSF proxy request filtering
Until you've patched all devices:
config system csf
set configuration-sync disable
set fabric-connector disable
end
This breaks fabric functionality temporarily but prevents exploitation through crafted CSF proxy requests. Re-enable only after confirming all devices are patched and you've rotated credentials.
Phase 4: Enhance Detection Coverage
9. Configure comprehensive logging
Gunra actors delete system and network access logs. Enable logging to an external, write-once destination:
config log syslogd setting
set status enable
set server [syslog-server-ip]
set mode reliable
end
Configure your syslog server to reject deletion requests from the Fortinet device itself.
10. Create detection rules for off-hours activity
Since Gunra operates primarily between 10pm and 6am in the victim's time zone, configure alerts for:
- Administrative logins outside business hours
- Configuration changes during maintenance blackout windows
- Large data transfers initiated from VPN connections after hours
- SSH tunnel establishment (OpenSSH downloads to internal systems)
Example SIEM query structure (adapt to your platform):
source="fortigate" (action="login" OR action="config-change")
| where hour >= 22 OR hour <= 6
| where user!="scheduled-backup-account"
11. Monitor for Node.js websocket exploitation indicators
CVE-2024-55591 involves crafted requests to the Node.js websocket module. Enable debug logging temporarily:
diagnose debug application httpsd -1
diagnose debug enable
Look for unusual websocket connection patterns or requests attempting privilege escalation. Once you've established a baseline, create permanent detection rules in your SIEM.
Validation - How to Verify It Works
Test 1: Confirm patch application
Run vulnerability scanners against your Fortinet devices from both internal and external perspectives. Both CVE-2024-55591 and CVE-2025-24472 should return as remediated.
Test 2: Verify authentication hardening
Attempt to authenticate with:
- A default credential (should fail immediately)
- Incorrect password three times (should trigger lockout)
- Valid credentials without MFA token (should be rejected)
Test 3: Validate logging pipeline
Generate a test configuration change and verify:
- The event appears in your external syslog within 60 seconds
- You cannot delete the log entry from the Fortinet device
- Your SIEM alert triggers if the change occurs outside business hours
Test 4: Check Security Fabric isolation
If you disabled fabric features, attempt to connect between upstream and downstream devices using the CSF protocol. Connections should fail.
Maintenance / Ongoing Tasks
Weekly:
- Review off-hours authentication attempts
- Verify external log collection is functioning
- Check for new Fortinet security advisories
Monthly:
- Audit administrative account list for unauthorized additions
- Test MFA enforcement by attempting bypass through alternate paths
- Review and update your known-good configuration baseline
- Verify backup integrity (attempt a test restore to a lab device)
Quarterly:
- Conduct tabletop exercises simulating Gunra's attack pattern
- Review and update detection rules based on new threat intelligence
- Audit Security Fabric topology and device serial number exposure
- Test your ability to detect large-scale data exfiltration to services like Mega
After any configuration change:
- Export a new configuration backup
- Document the change in your configuration management system
- Verify the change didn't disable security controls
- Confirm logging continues to function
The Gunra advisory emphasizes that multiple ransomware groups exploit these same vulnerabilities. Your hardening efforts protect against an entire class of attacks, not just one threat actor. If your detection coverage drops overnight, you've created exactly the gap these groups are built to exploit.
