FortiBleed from the Target Side: The Corpus [Part 1/3]

Part 1 of 3 · The Corpus. What FortiBleed really is, and what 447,600 login attempts look like from the inside. Continues in Part 2: The Ecosystem and Part 3: What Stops Them .

Thesis: the FortiBleed story so far has documented the exploitation and the dumps. What almost nobody has shown is the step in between — the credential-validation phase, where automated tools test the stolen passwords to find out which ones still work, so working access can be sold. We watched that phase happen, in cleartext, from inside a FortiGate honeypot.

Audience: CISOs, SOC and MSSP teams, FortiGate operators, national CERTs.

Confidence: observed directly in honeypot telemetry, except where tagged otherwise.

The FortiBleed campaign put the credentials and configuration-derived secrets of tens of thousands of FortiGate firewalls — admin passwords, VPN user databases, service-account secrets — into the criminal economy. Public research has documented the exploitation (how the devices were broken into) and the dumps (what was stolen). What almost nobody has shown is the step in between the theft and the damage: the credential-validation phase, where automated tools systematically test the stolen passwords to find out which ones still work, so that working access can be sold.

We watched that phase happen, in cleartext, for three days, from inside a FortiGate honeypot. This is the report.

Executive summary

Confidence key — claims in this report are tagged where their basis matters: OBS = directly observed in our honeypot telemetry; EXT = externally reported by named researchers or vendors; INF = inferred from observed data (the inference is stated explicitly). Where no tag appears, the claim is OBS.

Between late May and late June 2026 we operated a single internet-facing FortiGate honeypot. Over the full month it recorded about 447,600 login attempts to the FortiGate management endpoint (POST /logincheck) from about 34,600 distinct source IP addresses — the steady background radiation of a firewall exposed to the internet.

Across the month, those attempts carried 210,683 unique username/password pairs — 137,238 distinct usernames and 107,806 distinct passwords. For a focused three-day window we additionally captured every submitted credential in plaintext. The headline numbers:

Three findings stand out.

1. It is not brute force. It is a stolen corpus being recycled. The credentials are real: tens of thousands of year-stamped passwords, company names embedded in passwords, and — decisively — FortiGate-only service accounts and FortiCloud device-registration tokens that exist only inside a device’s configuration backup. You cannot guess these; they were extracted from compromised FortiGate configs and cracked offline. The presence of long, complex corporate passwords in the spray is itself the fingerprint of GPU hash-cracking (FortiOS’s legacy SHA-256 hashing makes even strong passwords recoverable), not brute force. This is the downstream output of the FortiBleed credential-harvesting campaign.

2. It is a marketplace, not a lone actor. The same stolen corpus is being sprayed at our single honeypot by multiple operator groups across roughly a dozen infrastructure clusters — several of which collapse into one centrally-orchestrated fleet — on dedicated bullet-proof-hosting infrastructure across roughly 13 autonomous systems and using at least three distinct sprayer tools. The signal they share one source: 42.2% of all credential pairs were tested by two or more separate operators, and not just obvious ones — specific corporate credentials (a company’s own admin account with its real leaked password) show up independently from six different networks. They run in parallel, blind to each other, each working through their slice of the same dump.

3. They validate and leave — and they are bots, not browsers. Our honeypot returned an authentic-looking successful-login response to 19 different attacker IPs (25 times in all). Not one did anything with the access — no configuration download, no user enumeration, no firewall-rule query, no VPN tunnel, no session reuse. Eighteen of the nineteen never sent a single request to anything but the login endpoint (one hammered it 6,154 times and nothing else). And none of them is a real browser: zero loaded the admin interface, its JavaScript or any asset — they simply read the success response and moved to the next credential. This is the behavioral fingerprint of an Initial Access Broker (IAB) [INF]: an automated checker whose entire job is to confirm which leaked passwords still work, so the access can be sold to whoever does the actual damage.

The published reporting has documented the exploitation chain, the tools, the credential dumps and the scanning infrastructure in impressive detail. What it could not show is what happens at the target end — the validation phase as experienced by the device being sprayed. Firewall logs tell a defender that a spray happened; they do not tell them which passwords were tested, because the credentials never reach a defender in cleartext. Our honeypot captures the full submitted corpus, which lets us do three things the published reporting cannot: reconstruct the attacker’s wordlist and identify organizations whose FortiGate-related credentials appear in the spray (config-extraction confidence varies by artifact type); indicate — from the total absence of post-access behavior across 25 granted logins — that validation and exploitation are operationally separated (different teams, different infrastructure); and map the competitive ecosystem of validators spraying the same dump in parallel, including the central orchestration behind what looks like independent infrastructure.

Part I — What FortiBleed actually is

Not a vulnerability — a credential operation

FortiBleed is not a new vulnerability. In mid-June 2026, researcher Volodymyr “Bob” Diachenko and Hudson Rock disclosed an exposed attacker server holding a verified database of working FortiGate administrator and SSL-VPN credentials. SOCRadar named the campaign FortiBleed; Kevin Beaumont (DoublePulsar), Arctic Wolf, SpyCloud, Bitsight and others corroborated the findings. As of late June 2026, confirmed scope was estimated at roughly 74,000–86,000 devices across 194 countries — about half of all internet-facing FortiGates — with operators reported to have targeted 430,000+ devices and harvested 110 million+ credentials. These numbers were evolving daily at the time of writing; readers should follow the ongoing public reporting for current figures. Fortinet’s own position — in its June 2026 PSIRT analysis “Analysis of Reported Credential Compromise of FortiGate Devices” — is that the activity involves threat actors reusing credentials from previous incidents (FG-IR-26-060, FG-IR-25-647) plus brute force against weak-password, no-MFA devices, and is not a fresh exploit or a compromise of Fortinet’s own products.

The technical core: legacy password hashing

The engine behind the campaign is a weakness in how FortiOS stored administrator passwords. Historically, FortiOS used salted SHA-256 — a fast, general-purpose hash that is trivially crackable on commodity GPUs. Fortinet migrated to the deliberately slow PBKDF2 scheme in FortiOS 7.2.11, 7.4.8 and 7.6.1, but the migration carried a trap: upgrading does not automatically re-hash existing passwords. A post-upgrade login converts the visible password to PBKDF2, but by default FortiOS retains the legacy SHA-256 in a hidden old-password field (for downgrade compatibility) — visible in any super-admin configuration backup, identifiable by the SH2 line prefix versus PB2 for PBKDF2 — until the branch-specific weak-hash lockout is enabled. A device that looks “patched” can still be carrying a crackable hash. Once configuration backups were obtained, the operators cracked the hashes offline on a reported ~45-GPU Hashtopolis cluster. This is why even long, complex corporate passwords appear in the validated credential set — they were not guessed, they were cracked.

How the configs were obtained — the open question

How configuration backups were extracted at this scale is the central open question. The likely sources are a combination: historical FortiGate vulnerabilities (CVE-2022-40684, CVE-2023-27997, CVE-2024-55591), the 2022 Belsen Group config dump, endpoint infostealer logs from underground markets, and on-device traffic sniffers deployed after initial access. The most relevant recent vector is CVE-2026-24858 — a FortiCloud SSO SAML authentication bypass (Critical, CVSSv3 9.4–9.8 depending on source, January 2026, in CISA’s KEV catalog) that produced rogue admin accounts on fully patched devices. We make no claim that any single CVE is “the” FortiBleed vulnerability; the campaign is a credential operation that consumed the output of years of accumulated FortiGate exposure.

The published architecture

Published analysis (SOCRadar, LeMagIT, Arctic Wolf, SpyCloud) describes a multi-operator, russophone Initial Access Broker (IAB) group — referred to as SantaAd on the Exploit forum — operating a segmented pipeline: Masscan for port discovery, a custom FortiProbe-fast tool to classify targets as FortiGate or not, Shodan_Recon to enrich with organizational metadata, credential stuffing and brute force against SSL-VPN portals, a passive Golang sniffer called FortigateSniffer deployed on compromised devices to harvest additional credentials from transit traffic (reported still active on 19,000+ devices), and offline cracking via Hashtopolis/Hashcat — all orchestrated via Telegram bots. The resulting dataset was organized by sector, revenue and headcount — an inventory packaged for ransomware buyers.

Where our honeypot fits

All of that published work analysed the attacker’s exposed infrastructure and the resulting dataset — the output. Our honeypot watched the step that produces that dataset: the credential-validation spray, in cleartext, from the perspective of a target. That is the contribution of this report.

One critical note on timing: our honeypot began recording FortiBleed validation traffic on June 3, 2026 — thirteen days before the public disclosure on June 16–17. The campaign was already running while the world had not yet heard the name.

Our behavioral data shows something the publications could not observe from the server side: the validators do nothing with a working login. They do not deploy FortigateSniffer. They do not pivot to Active Directory. They log the result and move on. Validation and exploitation are operationally separated — different teams, different infrastructure, different timing. The sniffer deployment (SOCRadar’s central finding) happens later, on a subset of validated high-value targets. Our honeypot was validated but not (yet) selected for instrumentation — which is exactly what the triage step looks like from the target end.

Part II — What an internet-facing FortiGate actually faces

Before the targeted FortiBleed activity, it helps to understand the ambient noise. A FortiGate management interface left reachable from the internet is under continuous, automated assault.

Over the full month our honeypot was online, it logged about 447,600 POST requests to /logincheck from about 34,600 distinct source IPs — the bulk of it generic combolist credential-stuffing from broad scanning infrastructure. Network-layer sensors recorded the expected opportunistic scanners on top of this: inbound Zmap-fingerprinted mass scanning and a trickle of Mirai-variant user agents probing the surface.

A single autonomous system accounts for almost the entire IP count. One disposable fan-out / botnet-like substrate (AS200373) supplied on the order of 34,000 of those about 34,600 distinct source IPs — each address used sparingly (about five attempts on average before rotating out; the later admin-metronome sub-campaign is the one that uses each IP exactly once). That is the headline “34,600 IPs” demystified: it is not 34,600 operators, it is overwhelmingly one operator’s disposable-IP fabric wrapped around a far smaller core of persistent validators. The interesting traffic lives in that core — around a hundred IPs in roughly a dozen dedicated hosting allocations — and the rest of this report is about it.

Against that backdrop, the FortiBleed credential-validation traffic is quieter and more deliberate. It does not hammer a single account with a dictionary. It walks a curated list at a measured cadence, one credential per connection, and it carries dramatically more authentic corporate material than the combolist noise around it. The contrast between opportunistic mass-spray and targeted IAB validation is visible directly in the data: same endpoint, completely different payload quality.

One observation worth underlining for defenders: a large share of the probing is content-blind. The same exploitation attempts — including traversal probes characteristic of the older CVE-2018-13379 and auth-bypass attempts characteristic of CVE-2022-40684 — arrive constantly, fired indiscriminately at anything that looks like a FortiGate. If your device answers on port 443 to the internet, it is being tested against the full historical catalog of FortiGate vulnerabilities, every day, by tools that neither know nor care whether the specific box is patched. The FortiBleed validation traffic sits on top of this noise, quieter and more targeted — which is precisely what makes it harder to spot and more dangerous.

Part III — Our vantage point

A honeypot facing credential sprays has a dilemma. If it rejects every login, it sees that an attempt happened but learns nothing about the password — the attacker submits a credential, receives a failure, and moves on. If it accepts every login, it is trivially identified as fake; no real FortiGate grants admin access to every password.

Our FortiGate honeypot is instrumented to resolve this differently. It is an instrumented FortiGate-like target: every submitted credential is captured in cleartext, and on a controlled, infrequent basis the honeypot presents a success response so that post-access behavior can be observed. We deliberately withhold the implementation details; what matters here is the data it produces and what that data shows. To the validators we observed, it presented as an ordinary internet-facing FortiGate.

This gives us three things ordinary defenses do not have:

• Every password tested, in cleartext — including the ones that failed. The credential capture runs continuously across the full observation window (30 days), not only during the focused three-day period highlighted in Part IV. The three-day window is where we concentrate the detailed analysis; the 30-day aggregates (210,683 pairs, 137,238 usernames) come from continuous capture.
• The attacker’s reconstructed wordlist, which reveals which organizations have FortiGate-related credential material in the spray — config-extraction confidence varies by artifact type.
• Post-access behavior — or, as it turned out, the conspicuous absence of it — which tells us what role the operator plays in the criminal chain.

A note on what would have constituted exploitation: a granted login lands in an environment that behaves like a genuine FortiOS device, and the FortiGate admin, API, VPN and egress paths are instrumented — any action on those surfaces, and any outbound connection, would have been observable. No post-access action appeared on that monitored surface. The absence of post-access behavior described in Part 2 is an observed absence from an instrumented surface, not an inference from a gap in coverage.

Everything below comes from that captured data.

Part IV — The cleartext corpus: not brute force, a leak being recycled

Over the full month the spray carried 210,683 unique username/password pairs (137,238 distinct usernames, 107,806 distinct passwords); in a focused three-day window we captured 56,845 submissions in plaintext (43,527 usernames, 18,950 passwords). Several independent properties of that corpus prove it is harvested from real device configurations, not generated by a dictionary.

The structure betrays a stolen list, not brute force

The most telling property is structural, not cosmetic: 88% of the distinct usernames were tested with exactly one password each. Brute force does the opposite — it hammers one account with thousands of guesses. Testing 137,000 different usernames with a single password apiece is only possible if the username→password pairing was already known — read out of stolen device configurations. Reinforcing this, 93% of the usernames are organization-specific — company accounts, personal firstname.lastname logins, corporate email addresses — not the generic admin/user/root of a wordlist, and tens of thousands of passwords embed the account’s own username or company name, the characteristic corporate “company-name + year + symbol” pattern that does not appear in generic wordlists.

We are careful about one thing: the list is not purely corporate. Folded in among the leaked pairs is a layer of generic defaults — 123456, admin/admin, P@ssw0rd — sprayed opportunistically across many accounts. Taken over the whole month, that dilutes raw password complexity to about half three-or-four-character-class passwords, rather than the four-in-five seen in the corporate-heavy stretches. But the defaults are the garnish; the body of the list — by every structural measure — is pre-paired, organization-specific, leaked credentials.

Why complex passwords are in the spray

A natural question: if these are real corporate passwords, why would they appear in a spray — shouldn’t they be hard to crack? The answer is in how FortiOS stored them. Until recently, FortiOS hashed administrator credentials using salted SHA-256 — a fast, general-purpose algorithm that a modern GPU cluster can brute-force at billions of guesses per second. The FortiBleed operators are reported to have run a ~45-GPU Hashtopolis cluster for exactly this purpose. Passwords that look complex but follow predictable templates — company name plus year plus symbol, keyboard patterns, vendor-themed defaults — are trivially crackable despite their length, because SHA-256’s speed lets an attacker walk through template-shaped guesses in minutes rather than centuries. Fortinet has since moved to PBKDF2, but the migration does not re-hash existing passwords automatically — a post-upgrade login converts the visible hash to PBKDF2, yet FortiOS retains the legacy SHA-256 in a hidden old-password field (for downgrade compatibility) until the branch-specific weak-hash lockout is enabled.

This explains the bimodal complexity we observe: the complex half (corporate passwords with year-stamps, company names, high entropy) are cracked SHA-256 hashes from extracted device configurations; the simple half (numeric sequences, defaults, keyboard walks) are brute-force guesses and infostealer output. Two credential pools, merged into one spray list — exactly the structure described in published analysis of the FortiBleed dataset.

Year stamps that date the breach

Tens of thousands of passwords carry explicit year stamps, and the distribution is telling: a strong peak in 2020 (~4,100 passwords) matching the COVID-era VPN build-out and the FortiGate exploitation timeline, sustained high counts through 2022–2023, and a fresh peak in 2024–2025 (~4,300 stamped 2025 alone) — and the refresh has not stopped: 447 distinct passwords already carry a 2026 stamp, and over a dozen are forward-dated to 2027 — indicating the credential list is actively maintained and refreshed in real time rather than a stale one-time dump. Geographic markers appear too — passwords containing city, country and regional identifiers from South Asia, the Middle East and Latin America, consistent with the regions where FortiGate holds dominant market share. The username mix tells the same story: alongside admin (the single most-tested account), the corpus is heavy with administrador and usuario (Spanish), pointing to the Latin American concentration the victim data confirms.

The smoking gun: FortiGate-only accounts

A handful of captured usernames correspond to accounts that exist only inside a FortiGate’s configuration file and cannot be obtained any other way:

• FortiCloud device-registration tokens. A whole family of config-only service accounts (forti-devsync, forti-netproxy, forti-agentctl, forti-alertsvc…) all carrying the same base registration token, replayed as a block — you cannot independently guess a shared secret across that many accounts; it was lifted wholesale from one device’s config dump.
• A Fortinet TAC support account carrying a 20-character random password. This account is auto-provisioned during vendor RMA/support sessions; it exists only in a full device configuration backup. Its presence is decisive: the credential source is config backups, not harvested logins.
• Logging and authentication integration service accounts — the kind of FortiAuthenticator / logging-integration accounts that live inside the device config and nowhere else.

No brute-force tool produces these. No phishing kit captures them. They are extracted from stolen .conf files. This is the forensic proof that ties the spray directly to config-level compromise. Fortinet’s own remediation guidance reinforces the point: the post-incident advisories tell operators to hunt for exactly these configuration-resident service accounts — names such as forticloud, fortiuser, fortinet-support and fortinet-tech-support — the same account types we recovered from the spray.

Caught mid-traversal: the alphabetical tell

One of the more striking behavioral details: in the three-day cleartext window, the most-tested usernames cluster by initial letter — a run through the “G”, “H” and “I” band — g…-prefixed corporate logins, then a cluster of sector-specific admin accounts (a hospitality chain, an agricultural producer, a hotel), then i… personal firstname.lastname logins. Over the full 30-day window the alphabetical drift is weaker (the list appears to be sorted primarily by organization, with accounts from the same company grouped together, which creates a secondary alphabetical effect). What we caught in the cleartext window was one cluster’s pass through its assigned segment of a very large, organization-sorted credential dump — not a strict A-to-Z traversal, but a segmented, parallel pass. The admin account dominates everything (tested with a vast number of distinct passwords) because every FortiGate has one and every stolen config contains its password — but the long tail is unmistakably real corporate account names.

Continue to Part 2: The Ecosystem — one dump, many operators, and a heartbeat that proves central control. A companion Detection Brief ships with Part 3: What Stops Them .

OHIIHO Research tracks targeted threat campaigns and APT-grade attackers through high-intensity, intelligence-grade honeypot infrastructure worldwide. Organizational identifications derive solely from credentials captured in transit; no victim system was accessed. Contact: research@ohiiho.com .