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.

‍

As principais conclusões da análise são que o número de 21.632 que gerou as manchetes é a contagem de entradas na base de dados de atribuição de e-mail FortiGuard do atacante, um catálogo de registo de dispositivos, não uma lista de violações verificadas. Quando rastreado através das próprias ferramentas do atacante, apenas 918 organizações mostram evidências de tráfego Kerberos capturado de dentro das suas redes, o que significa que os operadores realmente alcançaram a infraestrutura interna

do Active Directory em menos de 5% dos casos atribuídos. Dessas 918, apenas 148 (~0,68% do número divulgado) representam comprometimentos confirmados onde os hashes Kerberos foram totalmente quebrados e as credenciais do AD foram verificadas. Nenhuma das vítimas de destaque mencionadas na reportagem original aparece nessa lista confirmada.

A lista do Active Directory com 899 entradas (all_domains.txt) conta a mesma história de um ângulo diferente. Dessas 899 áreas Kerberos capturadas, 46% terminam em sufixos internos não roteáveis: .LOCAL (316), .LAN/.LCL (47), .CORP/.INT/.YEREL (13) que existem apenas dentro de redes privadas e não podem ser associados a nenhuma organização pública através de registos externos. Outros 4,3% são nomes genéricos de palavra única (ADMIN, AD, DC) que são sem sentido sem contexto adicional. Apenas 484 entradas 53.8% usam nomes de domínio roteáveis que, em princípio, poderiam ser atribuídos a uma organização nomeada, e mesmo essas atribuições dependem da mesma correspondência de e-mail FortiGuard ruidosa discutida acima.

Conclusão

O diretório exposto não deixa dúvidas de que o FortiBleed é uma operação real e capaz. A cadeia de ferramentas funciona de ponta a ponta: a varredura localizou interfaces FortiGate expostas, hashes foram quebrados em um cluster Hashtopolis de ~45 GPUs, e credenciais validadas foram usadas para pivotar em redes e enumerar o Active Directory — tudo alimentando um catálogo classificado por receita, construído para vender acesso. Qualquer organização que execute uma interface de gestão FortiOS exposta deve considerar as suas credenciais de perímetro como comprometidas e agir de acordo com as mitigações acima.

Mas os números divulgados estão longe do que as evidências suportam. Rastreado através das próprias ferramentas dos operadores, o número de ~21.000 domínios se resume a aproximadamente 918 organizações com qualquer tráfego interno capturado, e apenas cerca de 148 — menos de um por cento — a comprometimentos confirmados. Nenhuma das marcas de destaque da reportagem original aparece nessa lista. A conclusão para os defensores é simples: aparecer no conjunto de dados é um motivo para investigar, não uma prova de comprometimento. Proteja qualquer interface Fortinet exposta, altere as credenciais de perímetro e trate os números divulgados como um limite superior.

Mitigações:

1. Remova as interfaces de gestão de firewall Fortinet e SSL VPN da exposição direta à internet pública, restringindo o acesso de administrador a redes internas confiáveis.
2. Altere imediatamente todas as credenciais de administrador e VPN, priorizando contas de longa duração e quaisquer que não tenham sido alteradas desde incidentes anteriores.
3. Aplique MFA em todas as contas administrativas e de acesso remoto para neutralizar senhas de texto simples roubadas.
4. Atualize o FortiOS para uma versão que suporte hashing PBKDF2, depois force cada administrador a fazer login uma vez para acionar o re-hashing e remover hashes SHA-256 legados residuais.
5. Altere quaisquer credenciais LDAP, RADIUS ou de contas de serviço que possam ter sido armazenadas em configurações de dispositivos exportadas.
6. Assuma o comprometimento em dispositivos com logins de administrador bem-sucedidos e desconhecidos — audite por contas de backdoor e controles alterados, e substitua o dispositivo em casos graves.

Referências

• *Fonte de inteligência e confiabilidade da informação - Wikipedia
• ^#Protocolo de Semáforo - Wikipedia
• Kevin Beaumont (DoublePulsar) — FortiBleed: 75 mil firewalls Fortinet tiveram senhas de administrador comprometidas
• https://www.linkedin.com/posts/vdyachenko_executive-summary-based-on-my-investigation-share-7472221359629185024-ISun/
• HKCERT — Alerta de Segurança: Incidente de Vazamento de Credenciais FortiBleed
• https://www.s-rminform.com/latest-thinking/cyber-threat-advisory-fortibleed-campaign-against-fortigate-firewalls-requires-urgent-remediation

‍