Triage Order After a Credential-Exposure Advisory: What to Fix First on Fortinet Edge Devices

On 18 June 2026, the Australian Cyber Security Centre (ACSC) published an alert titled "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways" [1]. The alert is aimed at all Australians and Australian organisations that use Fortinet devices, and it describes a malicious campaign that is reported to be widespread, largely using exposed credentials and credential-based attacks against Fortinet firewalls and VPN gateways. The ACSC states that this activity can lead to potential compromise and further credential exposure.

The advisory is explicit about the consequence it is concerned with: leveraging these credentials could enable a malicious actor's remote access to the devices and connected networks, as well as allow changes to various settings, including security controls [1]. That is the risk model. It is not a story about a newly disclosed software vulnerability being exploited. The ACSC describes credential-based attacks against internet-facing edge devices. The alert does not name a CVE, does not publish an affected version list, and does not state how many devices or organisations were affected [1]. Those omissions matter for triage, because they mean the scope of the event cannot be bounded from the advisory alone.

The alert's mitigation advice is a list: rotate all admin and VPN credentials immediately; ensure devices are patched against older-firmware vulnerabilities; restrict management interface exposure so that firewall admin and management interfaces are not internet accessible unless necessary; enforce MFA on all external interfaces; store credentials with PBKDF2 hashing, logging back in to admin accounts after updating so that encryption changes to PBKDF2; and examine authentication and access logs for abnormal logins or changes [1]. An update to the alert notes that Fortinet released a blog post and additional guidance, and directs affected organisations to review and monitor that post [1][2].

Read as a checklist, that list invites parallel execution. Read as a risk-sequencing problem, it implies an order. The four main workstreams - credential rotation, firmware currency, management-plane restriction, and MFA enforcement - have different effort profiles, different operational risk, and different dependencies. Running them in the wrong order can either waste effort or create new exposure.

Why the order is not arbitrary

Credential rotation is the only control on the list that directly addresses the reported attack path. If credentials are the vector, then changing them removes the vector for the accounts that are changed. It is also the control with the shortest time-to-effect and, in most environments, the lowest dependency on change windows. That combination argues for doing it first, and the ACSC says to do it immediately [1].

The caveat is that rotation is only durable if the other controls follow. Rotating a credential on a device whose management interface is internet-accessible and whose MFA is absent simply resets the clock. The new credential is exposed to the same collection path as the old one. This is why rotation first does not mean rotation alone.

Firmware currency is the next consideration, but it is not the same kind of control. The advisory asks organisations to ensure devices are patched against older-firmware vulnerabilities [1]. That is a general hardening step, not a response to a named vulnerability in this campaign, because no CVE is named. Patching is higher effort and higher risk than rotation: it can require maintenance windows, it can interrupt VPN service, and it can introduce regressions. It should be planned and executed deliberately, not rushed into the same window as credential rotation unless the environment is small and the change is well understood.

Management-plane restriction is the control that changes the attack surface rather than the credential. If the admin interface is not reachable from the internet, credential-based attacks against that interface lose their transport. The ACSC frames this as a conditional: management interfaces should not be internet accessible unless necessary [1]. The word "unless" is doing real work. Some organisations have a genuine operational need for remote management, and for them the answer is not to remove access but to constrain it - source restrictions, jump hosts, or a VPN that is itself protected by MFA. This work is often slower than rotation because it touches network architecture and change control, but it is more durable than rotation alone.

MFA enforcement on all external interfaces is the control that raises the cost of a stolen credential. It is listed separately from management-plane restriction, and it applies to external interfaces generally, not only to admin access [1]. MFA is high-value but also high-friction: it depends on identity infrastructure, it can break service accounts and automation, and it requires enrolment and support. In a triage order, MFA is the control that should be sequenced after the immediate exposure is reduced, because it is the one most likely to be rolled back under pressure if it is rushed.

PBKDF2 hashing and log review sit at different points again. The PBKDF2 instruction is specific: store credentials with PBKDF2 hashing, and log back in to admin accounts after updating so that encryption changes to PBKDF2 [1]. That is a configuration change with a verification step, and it belongs with the credential workstream rather than as a separate project. Log review is detective rather than preventive, and it should start early and continue, because it is how an organisation learns whether the preventive controls are holding.

A defensible sequence

The order that follows from the advisory's own framing is: rotate, then reduce exposure, then raise authentication cost, then patch on a planned cycle, with log review running throughout. Rotation first because it is immediate and directly relevant. Management-plane restriction next because it removes the transport for the reported attack. MFA next because it protects the credentials that remain in use. Firmware currency on a planned schedule because it is a general hardening measure and carries the most operational risk. PBKDF2 and log review woven into the credential and detection workstreams respectively.

This is a sequence, not a schedule. The point is dependency and risk, not elapsed time. An organisation with a small number of devices and a maintenance window available may compress the sequence. An organisation with a large estate and complex change control may run management-plane restriction in parallel with rotation for different device groups. What the advisory argues against is treating the list as unordered, because the controls are not interchangeable.

Using ZoomEye to scope the estate

Triage needs an inventory. The ACSC alert does not provide an affected version list or a victim count, so an organisation cannot use the advisory to determine whether it is in scope [1]. It has to determine that from its own asset data.

ZoomEye can be used here as an asset-identification and exposure-review input, not as a compromise detector. A query for app="FortiGate" returned an exact count of 983996 internet-observable assets, observed on 2026-09-23 [3]. That figure is the number of internet-observable assets matching that query. It is not a count of compromised devices, not a count of vulnerable devices, and not a count of victims. ZoomEye does not detect compromise, and nothing in this article should be read as claiming that it does.

What the figure is useful for is measurement hygiene and jurisdiction scoping. It establishes the scale of internet-observable FortiGate presence as a population, which is a denominator against which an organisation can compare its own externally visible footprint. If an organisation runs the same query restricted to its own address space, or reviews its own external attack surface, it can identify which of its devices are observable from the internet at all. That is the first question in management-plane restriction: which management interfaces are reachable? The ZoomEye count does not answer that question for a specific organisation, but it frames why the question matters at population scale.

The same query can support continuous monitoring. Re-running an exposure query over time and comparing results is a way to detect changes in what is observable, which is relevant to the management-plane restriction workstream. Again, this is exposure review, not compromise detection.

What the evidence does not establish

The advisory is a reported campaign, not a completed incident report. It does not name a CVE, does not list affected versions, and does not give a victim count [1]. The ZoomEye figure is an observation of internet-observable assets, not an incident metric [3]. Any triage plan built on this evidence should be explicit about those limits. The controls are defensible because they reduce credential-based risk generally, not because they map to a published indicator set.

References

[1] ACSC, "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways", published 2026-06-18T07:18:43Z, updated 22/06/2026. https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/reported-widespread-credential-exposure-affecting-fortinet-firewalls-and-vpn-gateways

[2] Fortinet PSIRT blog, "Analysis of reported credential compromise of FortiGate devices". https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices

[3] ZoomEye query app="FortiGate", exact_count=983996, observed 2026-09-23T17:14-17:15Z. https://www.zoomeye.org/searchResult?q=app%3D%22FortiGate%22