In June 2026, security researcher Volodymyr “Bob” Diachenko surfaced a dataset that the press quickly dubbed “FortiBleed.” It contains valid SSL-VPN credentials – usernames, emails, and in many cases plaintext passwords – for 73,932 internet-facing Fortinet FortiGate firewalls across 21,632 domains in 194 countries, roughly half of every FortiGate exposed to the internet.
SpyCloud obtained a copy of the underlying data and parsed it against our breach-record schema, and what we found expands the story: the original 73,932-device figure corresponds to a single exported credential catalog for FortiGate VPNs.
However, the broader collection reveals the working data of a live, multi-server initial access operation that was brute-forcing not only Fortinet VPN logins, but also gaining access to other accounts and edge devices including Synology NAS devices, Sophos firewalls, and MSSQL servers.
The operators also appear to have taken the intrusions further for select organizations – we also observed tools for additional credential harvesting, including dumping encrypted credentials from the Active Directory and cracking them using a tool called Hashtopolis. The threat actor infrastructure we analyzed appears to be operated by multiple individuals working together using a combination of off-the-shelf tooling and custom tools developed using AI-assisted coding.
Based on the data obtained from the threat actor’s servers, we assess that this actor is likely an initial access broker (IAB) using spray-and-pray techniques (in this case, mass-scanning and bruteforcing) to gain access to networks, then monetize that access by selling it to other threat actors. SantaAd, an IAB active on Exploit, has also implied responsibility for this activity. They posted a link to a cybersecurity blog about FortiBleed as bona fides and subsequently raised their prices.
Key points
- The credential leak that raised the initial alarm: The "FortiBleed" dataset contains valid credentials for 73,932 Fortinet firewalls across 21,632 domains.
- Broad targeting: Beyond Fortinet, the actors targeted Synology NAS, Sophos firewalls, and MSSQL servers using automated brute-forcing.
- AI-enhanced attacks: Threat actors utilized AI-based code editors (Cursor) and agentic pentesting frameworks (CyberStrike) to develop custom tools and automate intrusions.
- Financial motivation: Evidence points to a Russian-speaking initial access broker (IAB), likely "SantaAd," selling access on underground forums.
- High-impact exfiltration: Over 105 GB of sensitive military data was exfiltrated from a Turkish defense contractor during the campaign.
That data and attacker infrastructure
We identified three main servers being operated as part of this campaign, each with a distinct role. Two did the heavy lifting, and the third cracked hashes. All three servers contained targeting and credential data from different stages of the attack chain.
01
The Brute-Forcing Server: n5a7729 (193.8.*.*)[1]
This server ran the brute-forcing. The logs left behind by its scanning tools show what it was for: validating credentials at scale against FortiGate, Sophos, and MSSQL targets. The credential generator’s log records it producing 1,167,307,503 host/credential combinations (320,777 hosts against 3,639 credentials) to feed the FortiGate runs, while a separate MSSQL checker logged around 2.1 billion attempts of its own.
This is also where the file behind the public reporting came from – the FortiGate credential set covering 73,932 URLs across 21,632 domains. This server was still running when the data was initially captured by researchers.
02
The Operator Workstation: ncb3e3f (193.8.*.*)
We’ve dubbed this one the operator workstation. Its VM-routing config ties it to the brute-forcing server highlighted above, and where n5a7729 ground through credentials, this is the box the operators drove by hand: writing code, running a virtual machine lab, and moving into victim networks. The server’s bash history shows a mix of their own custom scripts and off-the-shelf tooling, including CyberStrike, an AI-powered penetration-testing framework, and OpenConnect, which they used to replay captured VPN session cookies. From a lab of seven Kali VMs hosted here, they used impacket to access victim Active Directories, exfiltrating Group Policy data, live Kerberos tickets, and NTLM hashes.
Their code development appears to have been done using Cursor, an AI-based code editor. The Cursor account appears to have been created on May 19, and the token sat on a headless server with no desktop, suggesting that the actors used a remote SSH session to access the box and issue Cursor prompts.
03
The Hashtopolis Server: 85.11.*.*
The third server houses their “Hashtopolis” password cracking rig. Hashtopolis is an open-source tool used for cracking passwords using parallel processing. Their agent configs point GPU workers at this server’s IP address, suggesting that it is a password cracking server fed by GPUs rented by the hour from vast.ai. It appears to crack the authentication hashes the harvester pulled in from Active Directories on compromised networks; we recovered roughly 143,000 Kerberos and 33,000 NetNTLM hashes that were being processed through their password-cracking pipeline. The actors didn’t stand up this password-cracking infrastructure until 12 days into their campaign using this infrastructure, once they finally had some hashes to crack.
Campaign targeting and victimology
What we know about the targets
A preliminary analysis by SpyCloud Labs researchers of data parsed from the two main servers indicates a spray-and-pray mentality on the part of the operators.
The verticals don’t point to deliberate selection: while IT services companies top the list with almost 2,000 victims, this does not appear to correspond to any intentional targeting of just IT services companies. Instead, it likely corresponds to a sector that is large, growing rapidly, and is comprised of many small to medium enterprises that are likely more vulnerable to these types of scanning-based attacks.
The operators also appear to have broken their victims down into revenue tiers, which they designate for 21,561 of the “validated” targets.
Analyzing by revenue, targets overwhelmingly fell within the SMB band, with 59% of targets specified as falling within the $10-50 million annual revenue range.
Geographic distribution of targets reveals that while India topped the list with 2,700 targets indicating an India-based headquarters, the United States was not far behind, with 2,392 entries on the list.
Analysis by industry shows a relatively broad and unconcentrated spread as opposed to a vertical play. The only possible outlier – IT services – could be explained by that sector being more likely to run on-premises Fortinet VPN/firewall appliances, which were the targets of this part of the campaign. This distribution only reinforces the opportunistic nature of the FortiGate harvesting.
Geographic distribution of targets reveals that while India topped the list with 2,700 targets indicating an India-based headquarters, the United States was not far behind, with 2,392 entries on the list.
But how did the operators collect this business intelligence data? From our analysis, it’s not entirely clear. The script references a local ipgeo.csv file, which does not appear in either server image, potentially indicating a file that once existed for the purpose of associating IP addresses to country codes but which was removed after the process completed. A script named merge_revenue.py contains a hardcoded list of pipe-delimited mappings of values to domain names, but it is not comprehensive to the output data. Comments written in Russian –
“Собираю revenue из результатов агентов (вставлю вручную ключевые)” – within the script make reference to a process collecting revenue numbers from an agent (presumably an AI agent) which were then hand-merged into the Python file.
The only field whose enrichment process is clear from the data is that of the domain field, which was extracted from the FortiCloud account email registered to the device, which lives in the device config.
Not just Fortinet; Synology, Sophos, and MSSQL targeted too
FortiGate was the largest single target set present on the brute-forcing server, but it still accounts for less than a third of the internet-facing endpoints these operators scanned. The same methodology used to create the headline Fortinet credential list, scan for a product, and then brute-force it, was also pointed at several other appliances, including Synology, Sophos, and MSSQL.
The operators collected 336,583 Synology DSM login portals, every one on port 5001, the default for a Synology NAS console. That’s almost as many as the FortiGate set, but targeting consumer and small-business storage boxes rather than enterprise firewalls. Importantly, the available data did not include credentials for these portals, so it is unclear whether the attackers progressed past the initial scanning phase of this part of the operation.
Sophos came next, at 247,584 firewall user-portal URLs, which is the page that a remote worker hits to start a VPN session. Like the Synology portals, no lines were accompanied by a credential, so it is unclear if any follow-on compromises took place.[2]
The actor also appears to have targeted database servers – a dedicated MSSQL checker worked through 163,650 servers across roughly 2.1 billion login attempts. It surfaced two hits, both with the sa administrator account, on live SQL servers:
Threat actor activity, techniques, and tooling
Timeline
The earliest timestamped indicator within the dataset shows the FortiGate-targeted “capture cycle,” which kicked off at 10:52 AM EDT on May 19, 2026. Each capture cycle appears to have generally involved iterating through a list of identified sockets with a list of test credentials. Log data created by this script shows a daily cycle of scanning followed by a static sleep of 20 minutes. The script does indicate that the actors used a rotating pool of proxy IPs, but we could not identify any other messages in the log file that indicate any additional attempts to obfuscate the credential capture activity. Individual IPs appear to have been tested tens of thousands of times without refusing connections.
The same day, one of the operators created a Cursor account that appears to have been used to write some of the custom tooling. The Cursor account ID is a ULID, which carries its creation time embedded in the first ten characters; decoded, it resolves to 2026-05-19 06:30 UTC, a few hours before that first capture cycle. It’s not clear based on the available data whether all of the actors’ custom scripts were written using this Cursor account and infrastructure, or if some code was pre-staged and deployed.
The hash cracking infrastructure wasn’t stood up until May 31, at least 12 days into the campaign. Presumably, it was spun up at this point to begin cracking the Kerberos and NTLM hashes that the actors had begun accumulating. Notably, the capture process was not interrupted while this new infrastructure was being spun up, indicating that the actors were occupying themselves with other pursuits while patiently allowing the capture process to complete.
Starting on June 7, we also start to see evidence that some operators began to conduct more hands-on intrusion activity. They appear to have captured a live FortiGate session cookie, which can be replayed to bypass authentication without a password:
The operators used OpenFortiVPN to connect to a victim organization’s FortiGate gateway and access the internal network. From inside, they reached a file server over SMB using an administrator account and copied the share back to the C2. While the log file doesn’t include an exfiltration date, it did record that over 12,000 files amounting to 105 GB of data were exfiltrated from the victim’s network. We did not directly observe any actual exfiltrated files in any of the attacker infrastructure.
Both SMB shares belonged to a single Turkish defense contractor, and file names indicated the actors were able to exfiltrate sensitive military information including maintenance and repair manuals for fielded systems, a radio CAD model, radio crypto-information documents, firmware and config-backup dumps. There were also thousands of dated field photos and videos of KORKUT, HISAR, SARP and other systems being serviced in Ukraine through mid-2026, complete with fault diagnostics and a firing record, as well as identification cards and other documents belonging to staff members of the firm.[3]
The last significant time marker that we can observe is June 13, which is when the threat actors’ activity pivoted to what we believe to be the first steps in a cashout scheme. Around this date, the operators began focusing on data enrichment – adding notes about each organization’s revenue, company size, and industry vertical to validated credential captures. They used this data to create files that were formatted in a way consistent with other initial access broker sales posts that SpyCloud Labs has observed in the past.
How AI helped the attackers
AI-assisted code development: The operators built their tooling with an AI code editor. The clearest indicator of this is a Cursor session credential holding both access and refresh tokens for an AI-editor account, all living on the operator workstation server. On the box itself, hands-on vim editing touched a single network-config file, so the code was written somewhere else and reached the server over a remote session, which is how Cursor’s remote-development mode works.
What that account produced is sizable for criminal infrastructure: a Telegram-controlled cracking bot labeled “Cracker v10,” plus a run of Active Directory audit and hash-correlation scripts. The code carries common hallmarks of machine-generated code, including emoji status messages, unicode box-divider comments, numbered “Step 1 / Step 2 / Step 3” scaffolding, and long explanatory docstrings. None of those characteristics proves AI authorship, but their density across file after file, alongside the confirmed Cursor session, makes AI-assisted development the obvious read.
Agentic pentesting tools: The operators also appear to be installing and using an open source AI-enabled pentesting tool called CyberStrike. CyberStrike is an open source agentic penetration testing tool that allows users to bring their own API key for any of the major LLM models. It has specialized agents for different red team assessment types, like “web-application” or “internal-network.” These types of agentic red teaming tools lower the barrier-to-entry of conducting a network intrusion even further than user-friendly C2 frameworks like Cobalt Strike or Sliver, making it that much easier for beginners to successfully compromise networks.
What we know about the operators
While we can’t yet definitively tie these operations to any real-world identities, we can make several assumptions about the makeup and background of the operators using the breadcrumbs they did leave on the servers:
- This is an access-broker economy. The single most telling artifact is the hand-maintained spreadsheet of victims annotated with company name, industry, revenue, and headcount, used to sort nearly 22,000 compromised domains by value. The inclusion of the revenue information is probably the most telling, and strongly suggests a financially-motivated actor set, as opposed to someone focused solely on the collection of information.
- The crew is Russian-speaking and built to be operated by more than one person. The tooling's working language is Russian throughout – the cracking bot's interface, the brute-forcer's prompts, the inline code comments are all written in Russian. The system seems to have been designed for collaboration, with evidence suggesting at least two users with different skill levels operating on the same machine. There are per-operator accounts across a lab of virtual machines that drop each user into a shared terminal session, governed by an authorized-user model with a single administrator.
- Their tradecraft is modern and relies heavily on open source off-the-shelf tooling; custom tools appear to have been written with the assistance of AI. The heavy lifting runs on off-the-shelf and commodity tooling, relying on an established offensive framework for the harvesting and command-and-control impacket for interfacing with Active Directory, hashcat and Hashtopolis for password cracking, OpenConnect for VPN session abuse, and a KVM lab for compartmentalization. The operator-written tooling that exists on the servers was written with an AI code editor, likely using a dedicated account, which was then used to produce a versioned Telegram-controlled cracking bot and a set of AD and data-processing scripts. The actors also rented GPU horsepower by-the-hour to crack passwords.
- Targeting was opportunistic, and the actors cast a wide net. The breakdown of identified victim organizations reflects initially indiscriminate targeting, skewing toward small and mid-market organizations worldwide rather than a curated list of marquee names. After a broadly-focused initial phase, the operators appear to have used open-source intelligence to gather industry and revenue information on affected organizations. Then they focused their time on specific victims for subsequent actions.
Additionally, an access broker selling Fortinet access on Exploit has implied responsibility for the campaign, linking directly to a Hudson Rock blog about FortiBleed and doubling the price of his auction.
One June 12, SantaAd, a Russian speaking account, opened an auction for access to nearly 7,000 Fortinet devices, priced starting at $25K USD. The account then posted an increased price on June 16. The following day, Hudson Rock posted a blog about “FortiBleed,” which claimed that a threat actor had collected credentials for nearly 75,000 compromised firewalls. Later the same day, SantaAd posted an update to their sale post, increasing the start price to $60K and referencing the Hudson Rock blog as apparent proof of their dataset’s value.
Takeaways for your team
The threat actor group behind “FortiBleed” was not just targeting FortiGate VPNs. By examining the infrastructure they used to launch the “FortiBleed” campaign over the course of the last month, we found that they were actually targeting a range of different internet-facing appliances with a standard spray-and-pray attack chain that relies mostly on mass scanning and brute-forcing logins. Once the operators have gained access to corporate networks, they are more selective about their targets, pivoting into select internal networks to try and harvest additional credentials. Data from their operational infrastructure appears consistent with a financially-motivated initial access broker operation.
Keep up with the latest research from SpyCloud Labs.
FAQs
“FortiBleed” is a dataset containing valid SSL-VPN credentials for 73,932 internet-facing Fortinet FortiGate firewalls across 21,632 domains in 194 countries, representing roughly half of every FortiGate device exposed to the internet.
The operators appear to be a Russian-speaking initial access broker group using spray-and-pray techniques to compromise networks and sell access to other threat actors, with SantaAd on the Exploit forum implying responsibility for the activity.
The attackers scanned 336,583 Synology NAS devices, 247,584 Sophos firewall portals, and 163,650 MSSQL servers.
The operators used Cursor, an AI-based code editor, to write custom tooling and deployed CyberStrike, an AI-powered penetration testing framework, to conduct network intrusions with lower technical skill requirements.
The attackers exfiltrated over 12,000 files totaling 105 GB from a Turkish defense contractor, including military maintenance manuals, radio crypto-information, firmware dumps, and field photos of weapons systems serviced in Ukraine through mid-2026.
The operators used Hashtopolis, an open-source password cracking tool, fed by GPU workers rented by the hour from vast.ai to process roughly 143,000 Kerberos and 33,000 NetNTLM hashes harvested from compromised Active Directories.
IT services companies topped the victim list with almost 2,000 compromised organizations, though this appears to reflect opportunistic targeting of a large, rapidly-growing sector rather than deliberate industry selection.
SantaAd initially auctioned access to nearly 7,000 Fortinet devices starting at $25,000, then increased the price to $60,000 after public reporting about the breach surfaced.
The credential generator produced 1,167,307,503 host/credential combinations for FortiGate targets alone (320,777 hosts against 3,639 credentials).
[1] As of the time of publication, one server remains online and active, with plaintext credential data easily accessible. As our editorial ethics prohibit actions which could reasonably result in additional victimization, we will not be publishing the full IP addresses of the servers used in this attack.
[2] IP addresses and other victim information has been redacted to avoid re-victimizing targeted organizations while they seek to remediate potential exposures.
[3] SpyCloud has chosen to not list specific files or details due to their sensitivity and apparent association with the war in Ukraine.
Keep reading
