Executive Summary

CloudSEK’s threat intelligence team is tracking FortiBleed, an active, large-scale credential-compromise campaign targeting internet-facing Fortinet FortiGate firewalls and SSL VPN gateways worldwide. Despite the name, FortiBleed is not a software vulnerability and is not linked to any newly disclosed Fortinet flaw or zero-day. 

It is the label given to a verified dataset of working device credentials that a threat group assembled through credential reuse, brute force, and offline hash cracking against exposed devices.

The campaign came to light only because the operators left their own back-end server exposed to the internet with an open, browsable directory. That server held not only a database of validated credentials but also the group’s tooling, automation scripts, connection strings, scheduled jobs, and operator command histories. 

Examining the Directory

The exposed server held 319 files of the operators' complete working environment, from the scanners that found targets to the catalogues that packaged results for sale. Rather than rely on the figures the operators advertised, we reconstructed the campaign from these primary artefacts. The files fell into a few groups:

• Scanning & validation — panel.js, check.js, panel_final.js
• Cracking infrastructure — bot.py (Telegram control), Hashtopolis, hashpanel.log
• Credential & target datasets — corps.txt, fsd_sort.txt, creds_with_pass.txt, targets_300M_plus.txt
• Enrichment & attribution — match_corps.py, merge_revenue.py, build_report.py, build_full_map.py
• Quality control — clean_honeypots.py, fake_ips.txt
• Post-exploitation toolkit — ad_enum.py, spray_admin.sh, spray_da.py, pass_* wordlists
• Live access — vpn5.conf (working SSL VPN into a victim network)

At the time of writing this report the attacker infrastructure has been deactivated at the source although we can confirm the presence of Hashtopolis instance on the same IP still being active

Cracking Infrastructure

The operators did not run a single monolithic cracking server. The directory reveals a layered architecture confirmed by both internal logs and external indexing

The coordination layer is a Hashtopolis 0.14.3 instance running on 85.11.187.8:8443, indexed by FOFA on 15 June 2026 days before this report.  Hashtopolis is an open-source distributed hash cracking framework: the server breaks jobs into chunks and distributes them to GPU worker agents. The agents in this case were rented vast.ai GPU instances, confirmed by SSH welcome banners in the operator's own logs. Six workers were active three at 4 GPUs each and three at 8 GPUs each totalling 36 GPUs. Upon more research we found more IPs addresses, hosting similar infrastructure.

We also identified the attacker's jumpbox the staging server used to relay into compromised networks. Its exposure mapped the final link between the operators' cracking infrastructure and their victims.

Credential Database and Brand Mapping — corps.txt

‍

The master credential database text file maps each device login to a brand domain with revenue, employee count, and geography. Inspection shows most high-profile brand entries are one or two credentials for a single device, with the brand attached via DNS, certificate, or registration email frequently a contractor, reseller, or subsidiary in a regional IP range, not the named parent.

 The FortiGuard ID Attribution Field — fsd_sort.txt

The enriched high value target database groups entries by the email domain in the device's FortiGuard ID and the contact email supplied at FortiGuard registration. Brand, sector, and global revenue are attached per group. Because FortiGuard registration has no domain-ownership verification, this email identifies whoever registered the device (MSP, integrator, distributor, contractor), not necessarily the device owner

Credential Reuse Across Organisations — corps.txt

Searching the credential database for individual passwords reveals heavy reuse: a small set of strings each appears across dozens of otherwise unrelated brands and geographies. Passwords such as ITAdmin@888, F0rt!n3tS3cur3!, fortiAdmin1qaz2wsx, and Admin@123 recur far too often to represent independently chosen credentials at separate organisations.

Internal AD Realm Names - all_domains.txt, build_full_map.py

The widely repeated "~21,000 affected domains" figure does not represent twenty one thousand compromised companies. The directory's domain list is dominated by internal Active Directory realm names entries ending in non-routable, organisation-internal suffixes such as .LOCAL, .LAN, .LCL, .CORP, .INT, and .YEREL, alongside bare single word domains (ADMIN, AD, and similar) that cannot be tied to any specific organisation at all. These are not domains that can be looked up or attributed externally.

The "21,632" figure itself traces to Kerberos realm groupings produced by build_full_map.py  In other words, it counts post-exploitation hash groupings, not distinct breached firewalls or companies. A large share of these realms also belong to small and mid market organisations no reader would recognise, which is very different from the implication that thousands of major brands had their internal directories compromised.

Attribution based on a FortiGuard licence registration email is not attribution, it is a starting point for an investigation that was never conducted. Publishing it alongside a free domain lookup tool, without that caveat, conflates marketing with disclosure

Two Hash Layers — FortiOS & Kerberos

A crucial distinction the directory makes clear — and one collapsed in most reporting — is that the campaign produced two fundamentally different kinds of data, with very different evidential weight.

Layer 1 is FortiOS credential data, extracted from device configuration exports pulled off exposed management interfaces. These hashes (in both the legacy salted-SHA256 format and the newer PBKDF2 format) identify firewall administrators. Their attribution to a company depends entirely on the FortiGuard-email and IP-matching problems described above, which makes Layer 1 the weakest link in any claim that a named organisation was breached.

Layer 2 is Kerberos pre authentication data, captured by deploying network sniffers inside networks the operators had already pivoted into. These hashes appear in formats such as `krb5pa$18200` and ` krb5pa2323 23` and, critically, carry embedded internal Active Directory domain names drawn from the victim's own infrastructure.

Honeypot Filtering - clean_honeypots.py

The operators were aware their scanning would sweep up honeypot decoy systems run by defenders and researchers to attract and study attackers and wrote clean_honeypots.py to remove them. The script's logic is revealing: it flags as a honeypot any host that accepts more than three distinct credential pairs, on the reasoning that a real device would not validate many different logins while a decoy designed to bait attackers will accept almost anything.

Non Fortinet Devices in the Dump - creds_with_pass.txt

The raw credential file shows that the operators' scanning was never Fortinet-specific. Mixed in among the FortiGate logins are credentials for entirely unrelated hardware networking equipment from other vendors, power-management and infrastructure appliances, and similar internet-facing devices along with malformed entries containing injection style payloads rather than real credentials.

This tells us the scanners were harvesting any device exposing a web login, then funnelling everything into the same dataset. The implication for the numbers is direct: a count presented as "compromised Fortinet firewalls" includes devices that are not Fortinet firewalls at all. Every non Fortinet entry that remains in the totals inflates a figure that is being marketed as Fortinet-specific

Post-Exploitation AD Tooling - ad_enum.py, spray_admin.sh

The directory contains a substantial post-exploitation toolkit that operates well beyond the firewall. ad_enum.py and related scripts use the impacket library to enumerate internal Active Directory environments over LDAP — pulling domain administrators, kerberoastable and AS-REP-roastable accounts, the machine-account quota, and credentials carelessly stored in account-description fields. Companion scripts such as spray_admin.sh and spray_da.py run Kerberos and SMB password spraying against internal domain controllers, while others test SMB access and spider network shares.

The Cracking Cluster - bot.py, hashpanel.log

Reporting characterised the operation's cracking power as a large, dedicated GPU cluster. The configuration in the directory tells a more modest story. bot.py, the Telegram bot that manages the cracking work, auto-detects the available GPU count and caps how many it will treat as "big" workers, falling back to a default of ten if nvidia-smi fails to report. The operator log, hashpanel.log, lists the actual deployment: six rented Vast.ai instances totalling roughly 36 GPUs, not a single purpose-built cluster.

Access for Sale - targets_300M_plus.txt, vpn5.conf

The purpose of the entire pipeline becomes unambiguous at its output stage. targets_300M_plus.txt is a revenue-sorted catalogue of remote-access targets SSH and VPN endpoints paired with working credentials and ordered by company revenue formatted exactly the way initial-access brokers package product for sale on underground markets. The directory also contains at least one live SSL VPN configuration file pointing into a victim network, confirming that the operators held usable, active access, not merely a list of cracked passwords.

Operator Origin - pass_* Wordlists

Attribution of the operators to a specific origin is, on the evidence in the directory, unresolved. Parts of the tooling carry Russian-language artefacts in comments and naming, which is the basis for the "Russian-speaking group" characterisation in some reporting. But the password-spraying wordlists complicate that picture: a large set of them are named after Persian and Arabic given names pass_ahmad, pass_reza, pass_hossein, pass_mohammad, and many more which is at least as consistent with a Persian-speaking operator targeting or sourcing credentials from that linguistic region

‍

Victim Analysis

India leads the attributed device count at 9,629 more than the United States (6,355) and Taiwan (3,637) combined. The top five countries alone (India, US, Taiwan, Mexico, Turkey) account for 54% of all attributed entries, yet the geographic spread runs to 194 countries, confirming this was an indiscriminate internet wide sweep rather than a targeted campaign against specific regions or sectors.

‍

The concentration in India, Mexico, Colombia, and Southeast Asia is consistent with the Telmex and Airtel credential reuse finding covered earlier telecom and ISP operators in these markets routinely manage Fortinet gateways for large SMB customer bases under shared credentials, producing geographic clusters that inflate individual country counts significantly.

‍

The central findings of the analysis is that the 21,632 figure that generated the headlines is the count of entries in the attacker's FortiGuard  email attribution database, a device registration catalogue, not a verified breach list. When traced back through the attacker's own tooling, only 918 organisations show evidence of Kerberos traffic being captured from inside their networks, meaning the operators actually reached internal

Active Directory infrastructure in fewer than 5% of attributed cases. Of those 918, only 148 ~0.68% of the headline figure represent confirmed compromises where Kerberos hashes were fully cracked and AD credentials were verified. Not one of the headline victims named in the original reporting appears in that confirmed list.

The 899 entry Active Directory list (all_domains.txt) tells the same story from a different angle. Of those 899 captured Kerberos realms, 46%end in non-routable internal suffixes .LOCAL (316), .LAN/.LCL (47), .CORP/.INT/.YEREL (13) that exist only inside private networks and cannot be matched to any public-facing organisation through external records. A further 4.3% are generic bare word names (ADMIN, AD, DC) that are meaningless without additional context. Only 484 entries 53.8% use routable domain names that could in principle be attributed to a named organisation, and even those attributions depend on the same noisy FortiGuard email matching discussed above.

Conclusion

The exposed directory leaves no doubt that FortiBleed is a real and capable operation. The toolchain works end to end: scanning located exposed FortiGate interfaces, hashes were cracked on a ~45-GPU Hashtopolis cluster, and validated credentials were used to pivot into networks and enumerate Active Directory  all feeding a revenue-sorted catalogue built to sell access. Any organisation running an exposed FortiOS management interface should treat its perimeter credentials as compromised and act on the mitigations above.

But the headline numbers drift far from what the evidence supports. Traced through the operators' own tooling, the ~21,000-domain figure resolves to roughly 918 organisations with any captured internal traffic, and only about 148  under one percent to confirmed compromises. None of the marquee brands from the original reporting appears in that list. The takeaway for defenders is simple: appearing in the dataset is a reason to investigate, not proof of compromise. Secure any exposed Fortinet interface, rotate perimeter credentials, and treat the headline numbers as an upper bound.

Mitigations:

1. Remove Fortinet firewall and SSL VPN management interfaces from direct public internet exposure, restricting admin access to trusted internal networks.
2. Immediately rotate all administrator and VPN credentials, prioritising long-lived accounts and any unchanged since earlier incidents.
3. Enforce MFA on every administrative and remote-access account to neutralise stolen plaintext passwords.
4. Upgrade FortiOS to a release supporting PBKDF2 hashing, then force every admin to log in once to trigger re-hashing and remove residual legacy SHA-256 hashes.
5. Rotate any LDAP, RADIUS, or service-account credentials that may have been stored in exported device configurations.
6. Assume compromise on devices with unfamiliar successful admin logins — audit for backdoor accounts and altered controls, and replace the device in severe cases.

References

• *Intelligence source and information reliability - Wikipedia
• ^#Traffic Light Protocol - Wikipedia
• Kevin Beaumont (DoublePulsar) — FortiBleed: 75k Fortinet firewalls have admin passwords cracked
• https://www.linkedin.com/posts/vdyachenko_executive-summary-based-on-my-investigation-share-7472221359629185024-ISun/
• HKCERT — Security Alert: FortiBleed Credential Leak Incident
• https://www.s-rminform.com/latest-thinking/cyber-threat-advisory-fortibleed-campaign-against-fortigate-firewalls-requires-urgent-remediation

‍