FortiBleed from the Target Side: What Stops Them [Part 3/3]

Part 3 of 3 · What Stops Them. The only control that works, the detections that do not, and the IOCs that are already stale. Read Part 1: The Corpus and Part 2: The Ecosystem first. Companion: Detection Brief .

Part 1 proved the spray is a recycled stolen corpus. Part 2 mapped the marketplace and the orchestrated fleet behind it. This part is what to do about it — and the uncomfortable finding that most of the reflexes a SOC reaches for miss this ecosystem by design.

Part IX — What defenders should do

If your organization runs FortiGate

Assume your credentials are in circulation. If a FortiGate of yours ran an affected FortiOS version at any point during the 2025 exploitation window, its configuration may have been extracted. Patching stopped the bleeding; it did not retract what was stolen.

Rotate everything in the config — not just admin. Every local user account, every service account, every FortiCloud registration token, every RADIUS/LDAP secret. The spray we observed tests org-specific accounts and the default admin account with each organization’s leaked password, on the bet that even if a user account was deleted, the admin password was never changed.

Enable the weak-hash lockout — re-login alone is not enough. On FortiOS 7.2.11+ / 7.4.8+ / 7.6.1+ the PBKDF2 scheme is available but does not activate automatically, and the old SHA-256 hash can persist in the hidden old-password field even after an admin re-logs in — until you enable the lockout. The fix is to enable the branch-specific weak-hash lockout under config system password-policy — login-lockout-upon-downgrade on 7.2/7.4 (confirmed on a live 7.4.12 device) and login-lockout-upon-weaker-encryption on 8.0 and current 7.6.x; Fortinet renamed the option within the 7.6 branch (7.6.1 shipped -downgrade), so verify the exact token on your version’s CLI reference [EXT]. Until it is on, treat every admin password as crackable and rotate accordingly; the exposure includes admins who have re-logged in, not just dormant ones.

Put MFA on the management interface. A second factor (FortiToken, or RADIUS-backed MFA) neutralizes credential spraying outright — a stolen password is worthless without it.

Get the management interface off the internet. FortiGate HTTPS management on port 443 should never face the open internet. Use a management VPN, a trusted-host allowlist, or both. Every operator we observed targets only that exposed surface; removing it from the internet removes the attack.

Do not rely on IP reputation alone

We checked every active sprayer IP against IP-reputation data. The result should worry anyone who blocks by reputation feed: roughly half of them — including several that successfully validated the admin account — carried a threat score of zero and appeared on no abuse feed at all. Only the loudest, highest-volume scanners had accumulated a reputation. The credential validators on fresh bullet-proof-hosting allocations are effectively invisible to reputation-based blocking, because the IPs rotate faster than feeds can label them.

That invisibility is not an accident of timing. Several of the most effective operators — those that actually landed working credentials — run from small autonomous systems registered to individuals rather than companies, a long-standing bullet-proof-hosting signature, on freshly allocated address space that no reputation feed has had reason to flag. Three such operators alone account for more than half of every authentic-looking success the honeypot granted. The hosts that matter most are precisely the ones a blocklist has never heard of.

We enriched every operator IP against a commercial threat-intelligence feed, and the result generalizes the warning across all three reflexes of IOC-based defense. The scores are inverted: the addresses that actually landed working credentials carried near-zero threat scores, while the only IPs flagged as known-bad were burned-out volume sprayers with zero successes — block on threat score and you stop the harmless noise while waving through every effective validator. The geography lies: for several operators, two independent geolocation sources disagreed by whole continents — one placing the host in Western Europe, another in the former USSR — because the address space is announced from one jurisdiction and physically hosted in another, a deliberate bullet-proof routing trick that makes country-blocking meaningless. And almost none of it hides behind Tor or residential proxies: the operators run from dedicated infrastructure rather than anonymizing. Reputation feeds, geo-blocks and Tor-exit lists each miss this ecosystem by design.

An allowlist on the management interface (only your own admin IPs may connect) is worth more than any blocklist, because it fails closed against an unknown source instead of failing open. Block the behavior — off-allowlist admin auth, one source trying many usernames — not just the known-bad IP.

Why standard SOC rules miss this

This spray slips almost every common detection. The cadence is roughly 90 seconds per attempt — below most rate-limit thresholds. 88% of usernames are tried with exactly one password, so per-account “repeated failures” rules never fire. It runs 24/7 with no time-of-day pattern, so there is no off-hours anomaly to catch. The signal is per source IP, not per account, which blinds account-centric rules; the source geography is ordinary cloud hosting (no impossible-travel); and the addresses carry near-zero reputation. The only control that works is structural, not behavioral: a management-interface allowlist fails closed against every unknown source — which is why it leads the list above.

The timeline gap is the lesson

The exploitation happened in 2024–2025. The validation spray is running in mid-2026, with freshly dated passwords in the list. Organizations that patched promptly but never rotated are discovering — a year or more later — that their credentials are being actively tested right now. The window between vulnerability exploitation and credential use is measured in months, not days. “We patched” is not the same as “we are safe.”

Expect the second wave

The zero post-access behavior indicates the sprayers are not the operators who will exploit the access. They are building inventory for sale. The buyers arrive later, with validated credentials that still work. If your FortiGate password was in this spray and has not been changed, someone may already have purchased working access to your management plane.

Part X — Indicators of compromise

Network indicators (validation-spray infrastructure)

Block / monitor the following autonomous systems — small dedicated allocations actively used for FortiGate credential validation during our observation window. (Operators migrate; treat the list as a snapshot, not a permanent boundary.) We identify infrastructure at the ASN level, not individuals; ASN registrant names are deliberately withheld, and the per-CIDR network ranges are in the restricted (NDA) edition.

Observation window: 2026-06-03 through 2026-06-25. First activity from multiple clusters on June 3; last activity ongoing at time of writing. Operators rotate infrastructure; treat this table as a time-bound snapshot, not a permanent blocklist. Recommended review interval: 90 days. The same list, plus behavioral rules, is in the companion Detection Brief .

Behavioral indicators

Detection guidance for FortiGate operators

• Alert on admin-login events (success and failure) whose source IP is outside your management allowlist.
• Flag any single source IP attempting more than a few distinct usernames within an hour as a credential spray.
• Treat any successful admin login from an unrecognized IP as a compromise until proven otherwise — the validation phase produces exactly the signal of repeated failures from one source at a steady cadence, occasionally followed by a single success.

MITRE ATT&CK

Conclusion

Ordinary honeypots see brute force — random passwords from generic wordlists that tell you nothing about who got hurt. Capturing the corpus in cleartext shows you something else entirely: the real credential economy. Stolen corporate passwords, lifted from actual device configurations, being methodically validated for resale. FortiCloud tokens that prove config-level theft. Service accounts that exist only in a FortiGate’s own backup. Company names in passwords that name the victims. Year stamps that date the breach. A dozen operators working the same dump in parallel. And then, after a successful login — nothing. No exploitation. No commands. Just a silent note, logged somewhere on the attacker’s side, that this password still works, ready to be sold.

FortiBleed does not end when a vulnerable firmware version is patched. It ends when exposed management interfaces are removed from the internet, MFA is enforced, active sessions are terminated, configurations are audited against a known-good baseline, and every credential that could have lived in the device configuration — admin passwords, VPN users, service accounts, FortiCloud tokens, LDAP/RADIUS/SAML secrets — is rotated. Until then, the validators keep checking which keys still open the door.

Where the public FortiBleed story dissected the attacker’s exposed server and the resulting dataset — the output — we watched the machine that produces it: the credential-validation economy, running 24/7, from the target side. That is what we saw. It is patient, automated, industrial, and it is not finished.

Data handling and ethics

• No victim system was accessed. Every organization identification derives solely from credentials captured in transit at our sensor. We did not connect to, scan, log into, or test any third-party device.
• Victim data is held for notification, not sale. The restricted victim list (779 email-identifiable accounts / 246 domains) is reserved for CERT-to-CERT notification, with defanged passwords; it is never shared commercially.
• This public edition is ASN-only. No attacker IP or CIDR, no hosting-provider registrant names, no victim domains/emails/passwords, no sensor internals. Per-IP and registrant detail lives only in a restricted (NDA) edition.
• TLP is split by artifact, not bundled for convenience: this article (TLP:CLEAR), a restricted partner edition (TLP:AMBER, named infrastructure), and an internal evidence vault (TLP:RED, raw forensics + the re-derivation ledger).
• Every load-bearing figure is re-derived from raw telemetry, not carried from a summary.

Sources

Primary disclosure & analysis

[1] SOCRadar, “Dismantling FortiBleed: Inside an Active Fortinet Credential Harvesting Campaign,” June 2026. https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised/

[2] V. Diachenko & Hudson Rock — FortiBleed dataset disclosure and exposure checker, June 13–16, 2026. https://www.hudsonrock.com

[3] Kevin Beaumont (DoublePulsar), FortiBleed analysis, June 2026. https://doublepulsar.com

[4] Arctic Wolf, “Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries,” June 2026. https://arcticwolf.com/resources/blog/active-fortibleed-campaign-impacting-fortinet-devices-across-194-countries/

[5] Bitsight, “Security Alert: FortiBleed — Fortinet VPN Credentials and Firewall Configuration Exposed,” June 2026. https://www.bitsight.com/blog/security-alert-fortibleed-fortinet-vpn-credentials-firewall-exposed

[6] Recorded Future (Insikt Group), “FortiBleed Campaign Exposing Credentials for 73,932 FortiGate Systems,” June 2026. https://www.recordedfuture.com/blog/critical-fortibleed-campaign

Vendor & government guidance

[7] Fortinet PSIRT, “Analysis of Reported Credential Compromise of FortiGate Devices,” June 19, 2026. https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices

[8] FortiGuard PSIRT FG-IR-26-060 — FortiCloud SSO authentication bypass (CVE-2026-24858). https://www.fortiguard.com/psirt/FG-IR-26-060

[9] FortiGuard PSIRT FG-IR-25-647 — FortiCloud SSO login authentication bypass (CVE-2025-59718 / CVE-2025-59719). https://www.fortiguard.com/psirt/FG-IR-25-647

[10] CISA, “CISA Urges Hardening Fortinet Devices After Reports of Credential Exposure,” June 18, 2026 (updated June 22). https://www.cisa.gov/news-events/alerts/2026/06/18/cisa-urges-hardening-fortinet-devices-after-reports-credential-exposure

[11] Cyber Security Agency of Singapore, “Advisory on Credential Compromise of FortiGate Devices (‘FortiBleed’),” Ad-2026-007, June 2026. https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-007/

[12] CSO Online, “FortiBleed campaign exposes 75,000 Fortinet firewalls worldwide,” June 2026. https://www.csoonline.com/article/4186790/fortibleed-campaign-exposes-75000-fortinet-firewalls-worldwide.html

Additional coverage

[13] SecurityAffairs, “FortiBleed: The Broker Who Turned 73,000 Firewalls Into a Product Catalog,” June 2026. https://securityaffairs.com/194132/cyber-crime/fortibleed-the-broker-who-turned-73000-firewalls-into-a-product-catalog.html

[14] eSentire, “FortiBleed Campaign: Credentials Exposed for +80,000 Fortinet Appliances,” June 2026. https://www.esentire.com/security-advisories/fortibleed-campaign-credentials-exposed-for-80-000-fortinet-appliances

[15] Sophos, “FortiBleed Credential Exposure and VPN Bruteforce Campaign,” June 2026. https://www.sophos.com/security-advisories/fortinet-fortibleed-credential-exposure-and-sophos-vpn-bruteforcing-campaign

[16] Arctic Wolf, “Inside FortiBleed: Reverse Engineering the CyberStrike Harvester Behind a Global FortiGate Credential Factory,” June 2026. https://arcticwolf.com/resources/blog/inside-fortibleed-reverse-engineering-the-cyberstrike-harvester-behind-a-global-fortigate-credential-factory/

Analysis based on 30 days of continuous honeypot telemetry (late May – late June 2026). Our observation of credential-validation traffic began on June 3, 2026 — thirteen days before the public disclosure of FortiBleed on June 16–17. Organizational identifications are derived solely from credential content captured in transit; no victim system was accessed, and identifications may not reflect current compromise status. The restricted victim dataset is withheld from this report and can be made available to national CERTs on request.

OHIIHO Research tracks targeted threat campaigns and APT-grade attackers through high-intensity, intelligence-grade honeypot infrastructure worldwide. Contact: research@ohiiho.com . See the companion Detection Brief for SOC-ready hunting guidance.