The cybersecurity landscape was recently disrupted by reports surrounding a large-scale credential-compromise campaign dubbed FortiBleed. Targeting internet-facing Fortinet FortiGate firewalls and Secure Sockets Layer (SSL) Virtual Private Network (VPN) gateways globally, the campaign initially generated sensational headlines implying a catastrophic zero-day vulnerability. However, deep-dive forensic telemetry indicates that FortiBleed is not a software vulnerability, nor does it rely on a newly weaponized exploit. Instead, it is the operational designation for a highly coordinated, multi-stage credential harvesting and brute-force initiative. By combining automated password spraying, offline cryptographic hash cracking, and systemic credential reuse, a sophisticated threat group successfully collected and validated thousands of edge device credentials.

The inner workings of this operation came to light due to a severe operational security (OPSEC) failure by the adversaries. The threat group left their primary backend infrastructure server exposed to the public internet via an unauthenticated open directory running on port 9999 at the IP address 85.11.187.8. This exposure allowed threat intelligence teams to capture the threat group’s entire operational environment. Recovered files included specialized automation scripts, active command histories, distributed cracking configurations, target enrichment databases, and live access profiles. This technical analysis provides an exhaustive deconstruction of the data, tooling, and infrastructure discovered within the open directory, separating real enterprise risk from inflated marketing disclosures.

Architectural Breakdown of the Exposed Open Directory

A comprehensive analysis of the exposed threat actor repository revealed a collection of 319 unique files. Rather than operating with a single monolithic tool, the adversaries engineered a modular, script-driven pipeline designed to ingest raw internet scan data, filter out deceptive elements, orchestrate distributed high-performance cracking, enrich target metadata for commercialization, and automate post-exploitation network enumeration. The contents of the open directory can be programmatically categorized into six primary structural layers:

• Scanning & Validation Layer: Comprising scripts such as panel.js, check.js, and panel_final.js, this module managed the initial validation of internet-facing management interfaces and verified the execution of automated connection sequences.
• Cracking Infrastructure Layer: Centered around bot.py (a specialized Telegram control mechanism), a localized installation of the Hashtopolis framework, and the historical log file hashpanel.log.
• Credential & Target Datasets: Storage files containing raw and processed target lists, including corps.txt, fsd_sort.txt, creds_with_pass.txt, and targets_300M_plus.txt.
• Enrichment & Attribution Tooling: Python-driven workflows including match_corps.py, merge_revenue.py, build_report.py, and build_full_map.py used to cross-reference victim assets with commercial corporate databases.
• Quality Control & Deception Filtering: Automation binaries such as clean_honeypots.py paired with fake_ips.txt to eliminate researcher-controlled decoy networks.
• Post-Exploitation & Access Management: Tools like ad_enum.py and spray_admin.sh along with a live, functional SSL VPN profile named vpn5.conf, confirming active, weaponized access into a live corporate victim environment.

While the attacker’s main open directory infrastructure has since been deactivated at the primary IP address, threat analysts have confirmed that the associated Hashtopolis instances remain active across various hosting providers.

Distributed Cracking Infrastructure and GPU Orchestration

The cryptographic cracking architecture engineered by the FortiBleed operators shows how modern threat groups bypass physical hardware limitations by leveraging distributed, on-demand cloud resources. At the core of their processing cluster was a Hashtopolis version 0.14.3 instance deployed at 85.11.187.8:8443, an open-source distributed hash-cracking framework that manages distributed cryptographic cracking workloads across ephemeral computing agents. Historical indexing data shows this instance was publicly exposed and indexed by the FOFA scanner on June 15, 2026, days prior to broader public disclosure.

Analysis of the operational logging file, hashpanel.log, along with persistent Secure Shell (SSH) welcome banners, confirmed that the adversaries did not invest in capital-intensive physical hardware. Instead, they rented cloud-based GPU compute instances via the vast.ai platform. The cracking cluster consisted of 6 distinct worker nodes: three workers configured with 4 enterprise GPUs each, and three workers configured with 8 enterprise GPUs each, compiling a net compute capacity of 36 cloud GPUs.

The Telegram orchestration daemon, bot.py, was designed to auto-detect available host compute resources via the nvidia-smi binary, programmatically capping tasks assigned to “big” workers and defaulting to ten threads if driver communication faltered. Further infrastructure analysis mapped several alternative IP addresses hosting identical, parallel Hashtopolis setups, alongside a dedicated operational jumpbox located at 193.8.187.2 which served as the interactive transit node for routing into compromised environments.

Data Enrichment, Telemetry Mapping, and Attribution Flaws

A critical component of the open directory was corps.txt, a master credential database that mapped successful device logins to corporate identities. This file was processed using enrichment scripts like match_corps.py and merge_revenue.py, appending financial metadata—such as annual revenue figures, employee headcounts, and geographic coordinates—directly to compromised credential strings. However, deep inspection of these entries reveals a major technical discrepancy in how target attribution was calculated.

Many high-profile corporate profiles inside corps.txt contained only one or two valid credentials for a single edge device. The associated brand names were frequently attached via Domain Name System (DNS) reverse-lookups, TLS certificate fields, or FortiGuard registration strings. In reality, these regional IP spaces belonged to third-party IT contractors, local integration resellers, or regional subsidiaries rather than the network infrastructure of the core parent company.

This attribution flaw is further highlights by fsd_sort.txt, an enriched target database sorted by the specific email address provided during FortiGuard device licensing. Because Fortinet’s FortiGuard platform does not enforce strict domain-ownership validation during the registration process, these emails map directly to the entity that deployed or managed the asset—frequently a Managed Service Provider (MSP) or localized system integrator—rather than the victim enterprise itself.

Furthermore, searching the corps.txt database highlights a widespread reliance on default or weak credentials across separate corporate ecosystems. Plaintext password strings such as ITAdmin@888, F0rt!n3tS3cur3!, fortiAdmin1qaz2wsx, and Admin@123 appeared repeatedly across hundreds of unrelated companies and geographic jurisdictions. This pattern confirms that the initial compromise vector relied significantly on automated password spraying against poorly managed edge gateways.

The Dual-Layer Cryptographic Landscape: FortiOS vs. Kerberos Hashes

A crucial technical distinction within the open directory—one that was frequently mischaracterized in early mainstream reporting—is that the FortiBleed operators handled two entirely different layers of cryptographic data, each carrying distinct forensic implications:

Layer 1: FortiOS Gateway Configurations

This dataset consists of administrative credential hashes extracted directly from FortiOS configuration file backups (.cfg), which the threat group downloaded after gaining access to exposed management interfaces. These files contained user credentials in both the legacy salted-SHA256 format and the modern, computationally demanding PBKDF2 format. Because these hashes represent administrative accounts bound strictly to the perimeter firewall interface, mapping them to a corporate parent depends entirely on noisy FortiGuard registration emails and external IP space categorization. This makes Layer 1 the weakest link in asserting that a full corporate breach has occurred.

Layer 2: Internal Kerberos Pre-Authentication Tokens

This dataset represents a much more severe level of network penetration. Captured by deploying specialized network sniffing tools inside corporate networks that the operators had already breached, these hashes appear in formats such as krb5pa$18200 and krb5pa2323 23. Crucially, these cryptographic tokens contain internal Active Directory (AD) Kerberos realm identities drawn directly from the victim’s internal directory infrastructure. The presence of Layer 2 hashes within the open directory provides definitive, un-forgeable proof that the adversaries successfully bypassed the perimeter firewall and moved laterally into the internal domain space.

Quality Control Mechanics: Honeypot Evasion and Multi-Vendor Ingestion

The threat actors recognized that automated internet sweeps inevitably interact with security research deception grids and high-interaction honeypots. To prevent these false entries from corrupting their commercialized access databases, the operators deployed a custom cleanup script named clean_honeypots.py.

The logic embedded within this script is highly revealing: it automatically flags and removes any target IP address that successfully authenticates more than three distinct, unrelated credential pairs. The threat actors operated on the programmatic assumption that a standard enterprise edge device will only validate a small set of legitimate administrative credentials, whereas defensive honeypots are designed to accept a wide variety of arbitrary credential sprays to capture threat actor payloads and behavior.

Simultaneously, an analysis of the raw logging file creds_with_pass.txt demonstrates that the adversaries’ scanning activities were protocol-agnostic rather than vendor-specific. Mixed directly into the FortiGate access arrays were valid credentials for alternative networking equipment, uninterruptible power supplies (UPS), and smart infrastructure appliances.

The script logs also revealed various malformed web exploitation payloads instead of structured credentials. This broad intake confirms that the threat actors’ scanning infrastructure captured any responsive public-facing HTTP/HTTPS authentication form, meaning the raw telemetry figures included non-Fortinet assets, artificially inflating the campaign’s scale.

Post-Exploitation Tooling and Active Directory Enumeration

Once a perimeter gateway was validated, the adversaries deployed a targeted post-exploitation toolkit designed for rapid lateral expansion. The primary tool discovered within the open directory was ad_enum.py, a Python script built on top of the open-source Impacket library.

This script was designed to query internal domain controllers natively via the Lightweight Directory Access Protocol (LDAP), allowing the threat group to map the target environment by extracting lists of Domain Administrators, identifying Kerberoastable and AS-REP-roastable service accounts, and checking the MachineAccountQuota parameter to assess privilege escalation vectors. Furthermore, the script actively parsed the description fields of Active Directory user objects, searching for cleartext credentials left behind by network administrators.

To automate lateral progression, the toolkit included shell scripts and supplementary utilities like spray_admin.sh and spray_da.py. These modules orchestrated automated, multi-threaded Kerberos and Server Message Block (SMB) password sprays directly against internal domain infrastructure. Parallel functions within these utilities tested the network reachability of internal shares, checked administrative access levels over administrative shares (C$, ADMIN$), and programmatically scraped network volumes for sensitive documentation.

Adversarial Attribution: Evaluating Language and Origin Paradoxes

Attributing the FortiBleed campaign to a specific threat group or geopolitical entity remains complex, as the evidence within the open directory presents conflicting indicators:

• Russian-Language Suffixes and Code Comments: Several automation tools and scripts contained explicit Russian-language strings, variable assignments, and comments within the source code. This documentation forms the technical basis for early industry reporting attributing the infrastructure to a Russian-speaking cybercriminal or Initial Access Broker (IAB) collective.
• Middle Eastern Linguistic Dominance in Wordlists: This attribution is complicated by the password-spraying wordlists recovered from the environment. A significant portion of the core credential arrays were structured around common Persian and Arabic given names and phrases, such as pass_ahmad, pass_reza, pass_hossein, and pass_mohammad.

The coexistence of Eastern European programmatic frameworks alongside Middle Eastern linguistic target lists suggests a multi-layered campaign structure. It indicates either a multi-national criminal partnership, the strategic deployment of false-flag operational artifacts, or a Persian-speaking threat cell leveraging shared underground Russian post-exploitation toolsets.

Macro Victimology and Empirical Statistical Analysis

Furthermore, an analysis of the 899 unique internal Active Directory realms listed in all_domains.txt confirms this reality:

• 46% of the captured realms used non-routable, internal network suffixes: .LOCAL accounted for 316 entries, .LAN/.LCL for 47 entries, and .CORP/.INT/.YEREL for 13 entries.
• 4.3% consisted of generic single-word names (such as ADMIN, AD, and DC) that cannot be mapped to any public entity.
• Only 53.8% (484 entries) utilized routable, public-facing domain extensions that could theoretically link to a specific corporate identity, and those remained subject to the same FortiGuard registration inaccuracies described above.

Indicators of Compromise (IoC)

The following infrastructure components were identified within the exposed environment and should be blocked or investigated across enterprise network boundaries:

Indicator	Type	Value
Open Directory & Coordination Server	IP Address	85.11.187[.]8
Fortinet Credential Harvesting Node	IP Address	85.11.187[.]28
Operational Pivoting Jump Box	IP Address	193.8.187[.]2
Active Hashtopolis Cluster Instance	IP Address	185.229.26[.]83
Active Hashtopolis Cluster Instance	IP Address	213.169.49[.]142
Active Hashtopolis Cluster Instance	IP Address	38.117.87[.]37
Active Hashtopolis Cluster Instance	IP Address	198.53.64[.]194
Active Hashtopolis Cluster Instance	IP Address	175.155.64[.]221

Actionable Defensive Playbook and Technical Mitigations

To secure infrastructure assets against the methodologies demonstrated in the FortiBleed campaign, enterprise network administrators should immediately implement the following technical remediations:

1. Isolate Management Interfaces: Remove all FortiOS administrative portals and SSL VPN management interfaces from direct public internet exposure. Restrict administrative access strictly to dedicated, internal out-of-band management networks or trusted, IP-whitelisted administrative zones.
2. Enforce Multi-Factor Authentication (MFA): Mandate robust multi-factor authentication across all remote access vectors, administrative portals, and user VPN endpoints to neutralize compromised plaintext credentials.
3. Execute Administrative Password Rotations: Perform an immediate, comprehensive password rotation for all firewall administrators and VPN service accounts. Prioritize long-lived administrative accounts and any profiles unchanged since recent network reviews.
4. Upgrade Hashing Algorithms to PBKDF2: Ensure the underlying FortiOS environment is upgraded to a modern release that supports PBKDF2 cryptographic key derivation. Force a global administrative password reset post-update to re-hash legacy configurations and remove remaining salted-SHA256 strings from system configurations.
5. Rotate Integrated Service Account Credentials: Revoke and rotate any Active Directory service accounts, LDAP query credentials, or RADIUS shared secrets that were stored within edge device configuration files, as these could be extracted via configuration backups.
6. Audit System Logs for Configuration Export Telemetry: Inspect perimeter gateway event logs for unexpected configuration export commands (execute backup config). Audit the local user database for unauthorized account additions, particularly administrative variations like forticloud-*, which indicate persistent access mechanisms.

Our Opinion: Threat Inflation vs. Infrastructure Realities

The FortiBleed case exposes a systemic issue in modern threat intelligence: the sensationalization of raw data over definitive impact analysis. When the cybersecurity industry defaults to equating a leaked list of perimeter metadata with twenty-thousand active network breaches, it dilutes risk prioritization for defenders everywhere. CloudSEK’s forensic investigation into the exposed open directory reveals the vital role of validation. Deconstructing the threat actor’s automation pipeline proves that while their intention was expansive, their execution achieved localized success—breaching less than one percent of their targeted infrastructure.

However, the real technical takeaway shouldn’t be dismissed due to inflated metrics. The democratization of high-performance computing through cloud-rented GPU platforms allows minor threat groups to wield immense, weaponized cryptographic cracking power. Renting thirty-six enterprise GPUs to systematically brute-force legacy hashes swiftly turned standard firewall configuration exports into direct keys for corporate networks. This aggressive operational model seamlessly bridges the critical security gap between low-tier credential-stuffing and advanced lateral movement. For modern enterprise organizations, the defensive lesson is clear: relying on perimeter obscurity or unvalidated attribution remains an obsolete defense strategy. Strict credential hygiene, mandatory multi-factor authentication, and immediate isolation of edge management interfaces are non-negotiable architectural fundamentals in an era of on-demand algorithmic warfare.