ForumsExploitsAI-Assisted Threat Actor Hits 600+ FortiGate Devices — Amazon TI Report

AI-Assisted Threat Actor Hits 600+ FortiGate Devices — Amazon TI Report

MalwareRE_Viktor 2/21/2026 USER

Hey everyone,

Just came across the latest findings from Amazon Threat Intelligence regarding a financially motivated, Russian-speaking actor leveraging commercial GenAI to compromise FortiGate devices.

The interesting part here is that the report indicates no exploitation of FortiGate vulnerabilities (CVEs) occurred. Instead, the actor is likely using AI to automate credential stuffing or brute-forcing operations with a sophistication that bypasses standard rate-limiting defenses. Between January 11 and February 18, 2026, they successfully compromised over 600 devices across 55 countries.

Since this isn't a patchable software flaw, we need to rely heavily on configuration hygiene and monitoring.

Detection & Mitigation:

  • Audit Admin Access: Ensure local admin accounts are disabled or strictly controlled.
  • Geo-blocking: If your business doesn't operate in specific regions, lock down management interfaces via firewall policies.
  • Log Hunting: Look for successful admin logins followed immediately by config changes.

For those running a SIEM, you might want to run a hunt for anomalies in action=login events combined with configuration backups:

# Example log grep for FortiGate

grep "action=login" /var/log/fortigate.log | awk '{print $4, $7}' | sort | uniq -c | sort -nr | head -20

Has anyone else observed indicators of this campaign in their environment, or are we all just scrambling to enable MFA on legacy VPN appliances now?

VP
VPN_Expert_Nico2/21/2026

We actually saw a similar spike last week on a client's HA pair. The source IPs were rotating constantly, suggesting a botnet, but the login attempts were varying the username casing and special characters in a way that felt 'human'—or rather, generative.

We blocked access to the management interface from the WAN entirely. If you need remote management, set up a jump host with strict key-based auth. Don't leave port 443 or 10443 open to the world anymore.

MF
MFA_Champion_Sasha2/21/2026

This is exactly why I've been pushing back against vendors removing 'complexity' from security management. AI lowers the barrier to entry for these script kiddies. They don't need to know how FortiOS works; they just ask the LLM to 'write a script to check for default creds on FortiGate port 443'.

We deployed a Sentinel-One watcher for our Fortinet estate, but this behavioral stuff is tricky. Does Amazon Threat Intelligence share the specific IOCs or just the high-level TTPs?

RA
RansomWatch_Steve2/21/2026

From a pentester perspective, this is terrifyingly efficient. I've used LLMs to help fuzz parameters, but using it for credential automation at scale is a game changer. It effectively renders simple CAPTCHA or basic rate-limiting useless if the model can adapt to the responses.

Make sure you check your sys_user table on the devices. In this specific campaign, they reportedly created new local users instead of just hijacking existing ones. If you see a user you don't recognize, assume you're pwned.

IA
IAM_Specialist_Yuki2/22/2026

Since standard rate limits are failing, we need identity-based heuristics. I've had success detecting distributed AI attempts by looking for single users authenticating from numerous unique IPs over short windows. If you're using Azure Sentinel, this KQL query helps catch that specific pattern:

FortiDeviceLogs
| where action == "vpn-login"
| summarize dcount(src_ip), makeset(src_ip) by user, bin(timestamp, 10m)
| where dcount_src_ip > 5

Beyond detection, enforcing FIDO2/WebAuthn remains the only reliable defense against automated credential stuffing.

CL
CloudSec_Priya2/22/2026

Great insights, especially regarding the identity-based heuristics. Since standard rate limiting is failing, we need to shift to dynamic blocking strategies. On FortiOS, you can automate this using the automation-action feature to temporarily ban source IPs after multiple failed attempts. This is aggressive but necessary against AI-speed attacks.

Here’s a quick example CLI snippet:

config system automation-action
  edit "ban_ip"
    set action-type ban-ip
    set ip-address-type src-ip
    set duration 3600
  next
end

Has anyone had success tuning the 'failed-login' trigger threshold without impacting legitimate remote users?

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created2/21/2026
Last Active2/22/2026
Replies5
Views155