AI-assisted FortiGate compromises (Amazon TI report) — How are you defending against polymorphic attacks?
Just caught the latest findings from Amazon Threat Intelligence regarding the campaign targeting FortiGate devices. Between January 11 and February 18, a Russian-speaking actor reportedly used commercial generative AI to compromise over 600 devices across 55 countries.
What stands out here isn't just the scale, but the methodology. The report suggests the AI was used to rapidly generate unique payloads and obfuscation techniques, effectively bypassing standard signature-based detection. It seems they aren't relying on a single CVE (like CVE-2023-27997) but rather using AI to automate the discovery and exploitation of misconfigurations or unpatched edge cases specific to each target's FortiOS version.
I've started hunting for IOCs in our environment, focusing on anomalous administrative logins and SSL-VPN spikes. If you're running FortiOS, I recommend checking your logs for unusual action="vpn-login" events originating from non-corporate geo-locations.
Here is a quick bash snippet to help aggregate recent admin logins from your logs if you have SSH access:
grep "action=admin-login" /var/log/messages | awk '{print $1, $2, $NF}' | sort | uniq -c | sort -nr
Or if you are shipping logs to Azure Sentinel, use this KQL query:
FortiDeviceLog
| where TimeGenerated > ago(30d)
| where EventType contains "login" or EventType contains "vpn"
| summarize count() by SrcIpCity, SrcCountry, User
| where count_ > 10
Is anyone else seeing indicators of this? I'm curious if standard IPS signatures are catching these AI-generated variants or if we're all flying blind until we update signatures.
We saw a similar uptick last week. Our standard FortiGuard IPS didn't flag the initial attempts, likely because the AI was slightly mutating the HTTP headers for each request. We ended up writing a custom local policy to block any SSL-VPN requests that didn't match our strict User-Agent standards, though that's a bit brittle. It's wild how fast they can iterate now compared to manual script writing.
From an MSP perspective, this is a nightmare. We have clients on various legacy FortiOS versions that can't be upgraded without hardware refreshes. We've pushed MFA for all VPN access, but I'm worried that won't be enough if they are using AI to automate session hijacking. Has anyone had success isolating the management interface completely behind a VPN as a mitigation?
Good call on the logs. Just ran your KQL query and found a handful of hits from Ukraine and Russia on a dev box we forgot to expose. This confirms that lateral movement via AI-assisted recon is real. I'm recommending we disable port forwarding and strict Geo-IP blocking on management interfaces immediately.
With polymorphic payloads bypassing IPS, don't overlook the management plane. We strictly enforce 'Local In' policies to restrict administrative access to specific jump host subnets, effectively shielding the device from direct WAN attacks even if services are exposed. You can audit your current exposure with this CLI snippet:
show system interface
It's a basic but effective layer of defense.
With signatures failing, we shifted reliance to behavioral heuristics. However, deep visibility is impossible without full SSL inspection. Many FortiGates operate in 'certificate-inspection' mode, which misses payload-level mutations. We switched to 'deep-inspection' for all internal traffic, exposing the AI-generated patterns.
Verify your current inspection level and throughput with this CLI command:
diagnose sys ssl deep_inspect_stat
With AI generating payloads this rapidly, the volume of requests is often a tell. We’ve implemented aggressive rate-limiting on the SSL VPN interface to throttle brute-force attempts before they hit deep packet inspection. It’s not a silver bullet, but it buys time. You can enforce this via CLI:
config firewall shaping-policy
edit 1
set name "RateLimitSSL"
set srcintf "wan1"
set dstintf "ssl.root"
set traffic-shaper "LimitTraffic"
next
end
Has anyone tried combining this with API-driven IP banning based on failed auth attempts?
With signatures failing, integrating FortiSandbox is crucial for behavioral analysis. It detonates unknown payloads in a VM, rendering polymorphism ineffective. We applied a dedicated AV profile to the SSL-VPN interface to forward suspicious streams:
config antivirus profile
edit 'SSL-VPN-Sandbox'
set scan-mode quick
set fortisandbox enable
next
end
This caught the obfuscated payloads that slipped past our IPS.
Since static signatures are struggling, consider deploying a decoy listener to safely capture these polymorphic payloads. We spun up a containerized honeypot to mirror our VPN interface, allowing us to analyze the AI-generated mutations in real-time and block the specific patterns at the edge.
docker run -d --name honeypot -p 10443:10443 cowrie/cowrie
This gives us actionable IOCs without risking the production gate. Anyone else seeing success with deception tech here?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access