FortiGate Mass Compromise: Leveraging AI for config bypass & credential stuffing
Just caught the Amazon Threat Intelligence report regarding the Russian-speaking actor using GenAI to compromise over 600 FortiGate devices. What's alarming isn't just the scale, but the methodology.
The report indicates no zero-day exploits were used; instead, the actor is leveraging AI to polymorph attacks—likely bypassing standard WAF signatures and automating credential stuffing at a scale that appears human to basic rate-limiters. This is a significant shift from the usual script-kiddie brute forcing.
We've updated our detection logic to focus on behavioral baselines rather than just static signatures. If you're hunting, check for anomalies in admin login patterns and API usage. We are specifically looking for high-entropy strings in URL parameters which often indicates AI-generated obfuscation.
Here is a Python snippet to calculate Shannon entropy for log lines to help identify these polymorphic payloads:
import math
def calculate_shannon_entropy(data):
if not data: return 0
entropy = 0
for x in range(256):
p_x = data.count(chr(x)) / len(data)
if p_x > 0:
entropy += - p_x * math.log(p_x, 2)
return entropy
# Check specific log fields
log_param = "session_id=a8f7q9z2x1c4..."
if calculate_shannon_entropy(log_param) > 4.5:
print(f"Alert: High entropy detected in {log_param}")
Beyond ensuring set system admin settings enable-mgmt-access-https is strictly limited to specific IPs, has anyone had success implementing heuristic-based blocking on FortiGates specifically to catch these AI-driven attempts?
We actually started seeing this last week. The requests don't trigger standard brute-force alerts because the timing and headers are too perfect. We ended up writing a local-in policy to drop traffic from IPs that hit the API more than 5 times a minute without a prior valid login cookie. It's noisy, but it stopped the bleeding until we patch.
Great snippet on the entropy check. We're doing something similar in our SIEM using KQL. One thing to note: ensure you're checking the SSL VPN logs too, not just the admin interface. We found the actor was probing the SSL VPN portal for legacy interface bugs using those polymorphic scripts.
Solid advice on entropy checks. To harden the configuration side, ensure you aren't exposing the admin interface broadly. Restricting Trusted Hosts to specific management subnets is often overlooked but stops credential stuffing attempts at the network layer better than WAFs against polymorphic attacks.
You can audit your current exposure with this CLI snippet:
get system admin settings
Look specifically at the access-permit fields to ensure they aren't set to 0.0.0.0 0.0.0.0.
Since the actor is bypassing basic rate limiters, MFA is your strongest defense against credential stuffing. Ensure your admin users are actually protected by checking the CLI:
get system admin
Verify the two-factor option is enabled. I’d also suggest deploying a canary token within your admin login page. If the AI scrapes the page and triggers the token, you get an immediate alert before any password attempts occur, giving you a heads-up that the automated scanner has targeted your specific IP.
Since these AI-driven attacks mimic human timing, signature-based detection is failing. Consider implementing TLS fingerprinting (JA3) checks. Automated libraries often yield distinct TLS fingerprints compared to standard browsers, even if headers look perfect. FortiOS allows blocking these anomalies via SSL inspection. You can enable built-in bot protection with this:
config firewall ssl-ssh-profile
edit "deep-inspection"
set block-bot-enabled enable
next
end
MFA is non-negotiable, but for an immediate layer against the automation, enable the built-in CAPTCHA. It disrupts the credential stuffing loop even when the timing looks human. You can enable it via the GUI or run this:
config system global
set admin-captcha enable
end
To add a detection layer, create a 'canary' admin account with a known leaked password. Any login attempt on this account is a definitive indicator of credential stuffing. This provides immediate alerts without relying on rate-limiters. You can filter for these specific events in the CLI to verify detection:
execute log filter field "user"
execute log display
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access