How an AI-Augmented Actor Breached 600+ FortiGate Devices Without an Exploit

Between 11 January and 18 February 2026, a Russian-speaking, financially motivated actor compromised more than 600 FortiGate firewall appliances across more than 55 countries — and did it without exploiting a single vulnerability in the product. Amazon Threat Intelligence, which published the investigation on 20 February 2026, says the actor found management interfaces exposed to the internet on ports 443, 8443, 10443 and 4443 and got in with commonly reused passwords on accounts with no multi-factor authentication. The device configurations it pulled out contained SSL-VPN credentials with recoverable passwords, administrator credentials, firewall policy and network topology. Commercial large language models ran through the operation, writing reconnaissance tooling and drafting attack plans; by the account of a separate researcher who found the actor's own server, one model was also configured to run offensive commands. This incident is one entry in the Orca AI Incident Archive, which carries the full record, its sourcing and its grading, alongside the neighbouring cases in the series.

What Amazon reported, and how it found out

The report, "AI-augmented threat actor accesses FortiGate devices at scale", is credited to CJ Moses, CISO of Amazon Integrated Security, and published on the AWS Security Blog on 20 February 2026. Its first substantive finding is a negative one: "No exploitation of FortiGate vulnerabilities was observed." Initial access was credential-based throughout — systematic scanning for management interfaces on the four ports above, followed by authentication attempts using commonly reused credentials.

What made the campaign visible was the actor's own operational security. Amazon says it identified infrastructure hosting the malicious tooling through routine threat-intelligence work, and that the same server held AI-generated attack plans, victim configurations and the source code for custom tooling, stored without encryption. That lapse gave Amazon a near-complete view of the methodology. "It's like an AI-powered assembly line for cybercrime," the report says.

The stolen configuration files are the pivot from the appliance to the network behind it. According to Amazon they contain SSL-VPN user credentials with recoverable passwords, administrative credentials, complete network topology and routing information, firewall policies that reveal internal architecture, and IPsec VPN peer configurations. The actor wrote AI-assisted Python scripts to parse, decrypt and organise them.

The post-exploitation, in Amazon's own words

Once inside, the actor followed a standard, well-documented path. Its operational documentation, written in Russian, describes using Meterpreter with the mimikatz module to run DCSync attacks against domain controllers and extract NTLM password hashes from Active Directory. In confirmed compromises it obtained complete domain credential databases. Amazon notes at least one case where the Domain Administrator account used a plaintext password that was either reused from the FortiGate configuration or independently weak.

From there the documented techniques are pass-the-hash and pass-the-ticket against further infrastructure, NTLM relay using standard poisoning tools, and remote command execution on Windows hosts. The actor specifically targeted Veeam Backup & Replication servers with PowerShell scripts, compiled decryption tools and attempts against known Veeam vulnerabilities — behaviour Amazon describes as "consistent with pre-ransomware operations", though the report does not record ransomware being deployed.

The actor's notes reference several CVEs, including CVE-2019-7192, CVE-2023-27532 and CVE-2024-40711. BleepingComputer, which covered the report on 21 February 2026, identifies the first as a QNAP remote-code-execution flaw and the latter two as Veeam issues. None of them was the way in. More tellingly, the same notes record repeated failures: services already patched, ports closed, exploits that did not apply to the target operating system. For one confirmed victim the actor's own assessment concluded that key infrastructure was "well-protected" with "no vulnerable exploitation vectors".

Two limits on the attribution are worth stating plainly. Amazon says the actor is "not known to be associated with any advanced persistent threat group with state-sponsored resources", and that AWS infrastructure was not observed to be involved in the campaign.

Where the AI actually sat

Amazon's account of the AI layer is specific about roles but silent on products. The actor used at least two distinct commercial LLM providers, the report says: one as the primary tool developer, attack planner and operational assistant, and a second as a supplementary planner when the actor needed help pivoting inside a particular network. In one observed instance the actor submitted a complete internal topology — IP addresses, hostnames, confirmed credentials and identified services — and asked for a step-by-step plan to reach systems its existing tools could not touch.

Amazon's evidence that the tooling was machine-written is stylistic rather than forensic. It lists redundant comments that merely restate function names, an architecture that invests more in output formatting than in function, JSON parsed by string matching rather than proper deserialisation, and compatibility shims with empty documentation stubs. The tools worked for the actor's narrow case and failed at the edges. The volume, Amazon notes, would normally imply a development team; here it came from one actor or a very small group.

What the AWS report does not contain is any model vendor, any product name, and any mention of the Model Context Protocol. Those appear in a second piece of research published the next day.

The server, and the names Amazon did not publish

On 21 February 2026 the security blog Cyber and Ramen published its own analysis of an open directory at 212.11.64[.]250:9999, hosted on AS4264 (Global-Data System IT Corporation, Zurich) — one of the two addresses Amazon lists as threat-actor infrastructure. The researcher counted 1,402 files across 139 subdirectories, including stolen FortiGate configuration backups, Active Directory mapping data, credential dumps, Nuclei scanning templates and Veeam credential-extraction tools, plus two folders named for Claude containing over 200 files of task output, session diffs and cached prompt states.

Two custom components are named in that analysis. ARXON is described as a Python Model Context Protocol server that ingests per-target reconnaissance, calls DeepSeek to generate attack plans and keeps a knowledge base that grows with each target; it also carries scripts for batch SSH-based creation of FortiGate VPN accounts and validation of Domain Admin credentials. CHECKER2 is a Go, Docker-based orchestrator for parallel VPN scanning, with logs showing 2,516 targets across 106 countries. The researcher states that no public references to either tool could be found, indicating both were built for this operation.

The same analysis describes a December 2025 exposure of the same server, this one containing a copy of HexStrike, an open-source offensive MCP framework, and a .claude settings file that pre-approved Claude Code to run Impacket tools, Metasploit and hashcat against hardcoded domain credentials belonging to an employee of a large Asian media company. By February, the researcher says, the actor had moved from that open-source starting point to ARXON and CHECKER2 — a progression of roughly eight weeks.

BleepingComputer relayed these findings in an update to its 21 February story. The distinction matters: ARXON, CHECKER2, DeepSeek and Claude Code are the researcher's reading of files, logs and settings in an unsecured directory. Amazon, which had independent access to the same infrastructure, named none of them. No model provider has confirmed any of it.

What is established, what rests on one source

Three claims stand on two independent parties. Fortinet's own blog post of 6 March 2026, "Attacks at the Speed of AI", states that Fortinet "observed no exploitation of FortiGate vulnerabilities" and that the campaign succeeded through exposed management ports and weak credentials with single-factor authentication, using password spraying. That corroborates Amazon's mechanism from the vendor's side, without either party having seen the other's evidence published.

Amazon alone is the source for the scale — more than 600 devices, more than 55 countries, the January-to-February window — and for the actor profile: Russian-speaking, financially motivated, low-to-medium technical baseline, extensive AI dependency, shallow post-exploitation depth, inadequate operational security. No third party has recounted the 600 figure.

Cyber and Ramen alone is the source for the named tooling, the model vendors, the file counts and the 2,516 scan targets. Its own evidence documents confirmed compromises at an industrial gas company in Asia-Pacific, a telecom provider in Turkey and the media company from the December exposure, with reconnaissance referencing South Korea, Egypt, Vietnam and Kenya — a confirmed victim set in at least five countries, well short of the 55 Amazon cites. The two numbers measure different things, and neither has been reconciled publicly.

Fortinet's response, and the scale it did not confirm

Fortinet's post, by Carl Windsor and dated 6 March 2026, agrees with Amazon on mechanism and diverges on magnitude. "Based on Fortinet's investigation and monitoring, a few customers were impacted by this attack," it reads. "We are in the process of notifying those organizations." It does not confirm 600 devices, does not adopt Amazon's country count, and does not name the actor.

Fortinet's framing is that the technique is old and the automation is new: password spraying against poorly protected edge devices, now driven by no-code prompt-based conversations. It states that the attack "would have been impossible with MFA in place" and "highly unlikely to succeed" with a password complexity policy enabled. It also published indicators: administrator access from 212[.]11.64[.]250 or 185[.]196.11[.]225, the creation of accounts named fortiuser, fortinet-support or fortinet-tech-support, unexpected VPN configurations or users, and scripts scheduled to run as a persistence mechanism.

This is a divergence in scope, not a dispute over whether the campaign happened. Nobody named in the record contests the intrusion; the archive grades it A, with no disputed flag, and records real harm.

What changed afterwards

There is no CVE and no patch, because there was no vulnerability. The remediation is configuration, and both organisations converged on the same list. Amazon says it shared indicators of compromise with relevant partners, collaborated with industry partners, and helped organisations take steps that reduced the actor's effectiveness; the report gives no count of notified organisations. Fortinet says it is notifying affected customers directly.

The technical guidance is consistent across both: take administrative access off internet-facing interfaces and manage through an internal or out-of-band path; enforce MFA on administrative and VPN access; apply password complexity; rotate SSL-VPN credentials on any appliance whose management interface was or may have been reachable; audit for password reuse between FortiGate VPN accounts and Active Directory; and isolate backup infrastructure, patch it, and keep immutable copies.

For detection, Amazon points at DCSync activity (Event ID 4662 with replication-related GUIDs), new scheduled tasks named to mimic legitimate Windows services, unusual remote management connections from VPN address pools, LLMNR and NBT-NS poisoning artefacts, and unauthorised access to backup credential stores. It also warns that signature-based detection has limited value here, because the tooling is built from legitimate open-source utilities — Impacket, gogo, Nuclei — that appear in ordinary penetration tests.

Why the record is a landmark

The archive marks this as a landmark entry, and the reason is visible in the contrast between what the actor achieved and what the actor could do. A single operator or very small group, assessed at low-to-medium skill, ran concurrent intrusions across dozens of countries, produced a toolkit that would normally imply a development team, and generated per-target attack plans fast enough to keep several intrusions moving at once.

The same report supplies the ceiling. The actor could not compile custom exploits, could not debug failed exploitation attempts, and could not improvise when a plan met a hardened target — so it moved on rather than persisting. Its AI-generated code broke at the edges. Its operational notes are a record of patched services and closed ports. What the models removed was labour, not judgement: reconnaissance, parsing, documentation and planning were automated; the parts that required adaptation stayed out of reach.

That is also why the open questions are dull and specific. How many organisations Fortinet actually notified would settle the gap between "a few customers" and more than 600 devices. A second examination of the ARXON directory, independent of the researcher who found it, would settle what the tooling was and which models it called. Until then, the record supports a firm conclusion about method and a much weaker one about magnitude.