Inside FortiBleed: Reverse Engineering the CyberStrike Harvester Behind a Global FortiGate Credential Factory

Summary

FortiBleed is a large-scale credential compromise campaign that targets internet-facing Fortinet FortiGate firewalls and SSL VPN gateways. The campaign does not depend on a malware payload; instead, it uses a credential pipeline that utilizes credential stuffing, password spraying, configuration harvesting, offline cracking, and post-authentication capture processing.

While investigating this campaign, we reverse-engineered a recovered CyberStrike Harvester binary and connected it to the broader FortiBleed operator workflow, showing how FortiGate access becomes multi-protocol credential extraction, hash cracking, VPN-bound AD/SMB access, and file-share exfiltration.

The risk level is severe; however, note that the available evidence does not confirm a live Fortinet CVE exploit as the primary access path. We assess this operation is likely an initial-access brokerage and credential-monetization effort with supporting access operation, or a hybrid model in which credential harvesting enables selective high-value collection.

We have not attributed this campaign to a known threat actor, and as of publication it has not been publicly attributed to one. The available anchors to link this campaign to a threat actor identity, including tool branding (CyberStrike), an operator handle (@Clarksome) observed in the Telegram bot, and Russian-language UI/status strings lead us to assess with low confidence that the operators are Russian-speaking, but they are not sufficient to name a specific actor.

Weaponization and Technical Overview

Technical Analysis

Context

Initially discovered by cybersecurity researcher Volodymyr “Bob” Diachenko, FortiBleed surfaced publicly in mid-June 2026 as a credential compromise campaign affecting Fortinet/FortiGate devices. Public reporting describes different snapshots of the scale involved: tens of thousands of compromised or exposed device entries, with some reporting approximately 73,932 URLs and others reporting 86,644 device entries across 194 countries. (These public figures should be treated as source-specific snapshots rather than a single unified count.)

Threat actor tools we recovered and analyzed align with public descriptions of the exposed operational environment. This environment contains a CyberStrike-branded harvester, sniffer-panel code, capture logs, credential-cleaning utilities, Hashcat/Hashtopolis orchestration, Telegram bot code, GPU-worker setup, virtual machine (VM) lab setup scripts, target-enrichment scripts, Kerberos correlation tooling, and post-access AD/SMB/DFS utilities. This tooling setup demonstrates a closed-loop workflow for converting noisy perimeter-device access and traffic captures into validated internal credentials and file-share collection.

As part of our investigation, we statically analyzed the original harvest_orig binary and distinguished three evidence tiers: recovered-file confirmed findings, public-reporting supported campaign-scale claims, and analyst assessments such as language or attribution indicators.

Technical Key Findings:

• Operators provision a seven-VM Kali/CyberStrike lab, run a FortiGate Sniffer panel to capture and convert traffic, process pcap/pcapng/FortiGate text with CyberStrike Harvester v1.5, clean noisy credential output, crack NetNTLM, Kerberos, FortiGate, and other hashes using Hashcat, a Hashtopolis-managed vast.ai GPU cluster, HashPanel, and a Telegram bot, then correlate results back to source folders, domains, IPs, countries, and revenue-enriched targets.
• Static analysis of the original harvest_orig binary confirms a Go-based Linux x86_64 ELF credential processor with multi-protocol parsing, Kerberos/NTLM hash formatting, session-token extraction, and reporting logic.
• Where credentials enabled network access, operators used openfortivpn tunnels and pivot-bound Impacket tools for Active Directory enumeration, Kerberos validation, SMB authentication, admin-share checks, SMB share spidering, and DFS/SMB collection.
• A recovered exfiltration log records a completed 121.43 GB file-share collection run.

What is FortiBleed?

FortiBleed is the campaign name used by researchers and vendors for a large-scale Fortinet/FortiGate credential compromise operation. Threat actors have been systematically extracting configuration files from internet-facing FortiGate devices and cracking the stored credential hashes. The campaign combines mass credential testing, configuration-file harvesting, offline cracking, passive capture processing, and post-access internal validation.

Its defining feature is the credential feedback loop: successful perimeter access creates configuration or traffic artifacts; those artifacts produce more credentials and crackable hashes. Cracked credentials feed VPN, Kerberos, SMB, and share-access validation, and validated access then supports further collection and exfiltration.

Does FortiBleed Use AI?

The materials we recovered show extensive automation. They do not, however, independently prove AI-based decision-making, which has been suggested by some vendors. CyberStrike branding and analyst notes do however reference “AI pentest” language. We will therefore treat CyberStrike as an automated offensive platform and avoid making AI claims beyond branding.

Figure 1: Canonical FortiBleed workflow.

Attack Vector

The operative access path is credential-centric. Public reporting and recovered tools support credential stuffing, password spraying, configuration export, offline cracking, and authenticated SSL VPN access. After authentication, the campaign operators obtained configuration and/or traffic material, then processed it offline. A sniffer panel implements pipeline phases for sniffing, conversion, harvesting, cleanup, and pause states.

The binary harvester then extracts credentials, NetNTLM and Kerberos material, cookies, tokens, sessions, email artifacts, SQL logins, RADIUS/TACACS+ data, and other authentication artifacts. This data is cleaned, cracked, correlated, and retested through Kerberos, VPN, SMB, and LDAP tooling. 

Figure 2: FortiGate sniffer frontend code showing capture, conversion, harvest, cleanup, and pause pipeline phases.

Weaponization

The toolkit does not follow a classic loader/dropper/agent malware chain. It is better understood as a pipeline of operator infrastructure, capture tooling, offline credential processing, cracking infrastructure, correlation logic, and post-access tooling.

The stages it runs through are as follows:

Stage 1: Operator lab and sniffer panel

The operator environment is reproducible: setup scripts create seven Kali Linux VMs in an isolated lab network, attach shared storage, provision cloud-init, enable VNC and SSH access, install CyberStrike, and create a tmux session with host and VM windows. This design supports parallel processing and shared operator observation. The sniffer panel is a browser-based JavaScript frontend using WebSocket and REST interactions with a backend service. It exposes pipeline controls and live capture status, meaning it functions as the operator console for the FortiGate capture-to-harvest workflow.

Stage 2: CyberStrike Harvester v1.5

Our static analysis confirms harvest_orig is a Linux x86_64 Go ELF executable, statically linked, not stripped, and built with Go 1.24.4. The binary identifies itself as CyberStrike Harvester v1.5 and contains functions for reading pcap, pcapng, and FortiGate text inputs. It also contains parser and formatter functions for NTLM, Kerberos, HTTP, FTP, mail protocols, LDAP, RADIUS, TACACS+, MSSQL, MySQL, SNMP, SSH banners, cookies, sessions, and tokens. The output filenames and embedded Hashcat guidance show that the tool writes attack-ready hash files such as NetNTLMv2, Kerberos pre-auth, AS-REP, and TGS outputs, along with cleartext credential and session reports.

Figure 3: Static verification output for the original harvest_orig binary.

CyberStrike Harvester v1.5 converts passive FortiGate-derived network captures into actionable credentials, crackable hashes, web sessions, identity intelligence, and downstream attack inputs. The actor essentially built a system to turn captured network traffic into reusable access paths.

The input-handling logic is significant. In main.readPcapFile, the binary reads the first four bytes of each candidate file and checks for standard capture-file magic values. It dispatches to classic pcap parsing when the magic value matches 0xa1b2c3d4, 0xd4c3b2a1,  0xa1b23c4d, and to pcapng parsing when the magic value matches 0x0a0d0d0a. If never standard capture format is detected, the code falls through to FortiGate text detection and can route compatible input to main.readFortiGateText.

The FortiGate-specific ingestion path is an important finding. The tool was therefore adapted to process FortiGate-derived artifacts, not only clean packet-capture files.

Figure 4: FortiGate-specific regex patterns.

Figure 5: File format magic number detection.

Classic PCAP and PCAP-Ng magic numbers are checked first. If neither matches, it falls through to FortiGate text detection.

Figure 6: FortiGate text file detection by content patterns.

CyberStrike Harvester produces Hashcat-ready outputs, directly feeding the Telegram bot, Hashtopolis, HashPanel, potfile collection, and match-correlation tools recovered elsewhere in the archive. The harvester collects both credentials and session material, meaning remediation must include session invalidation, token revocation, VPN/admin session termination, and password resets.

The embedded main.Credential type and JSON tags such as credential_type and credential_data indicate the tool normalizes recovered material into structured records.

Stage 3: Credential cleaning and quality control

The harvester output is intentionally noisy because it processes raw network captures. The actor built a multi-stage cleaning subsystem to convert that noise into attack-ready credential material. Scripts remove binary garbage, SQL injection strings, XSS payloads, JNDI artifacts, long tokens, mail-domain artifacts, session IDs, honeypot-like results, duplicate pairs, and brute-force noise. This cleaning stage is critical: it raises the quality of login/password lists before password spraying, VPN validation, SMB testing, and Hashcat recycling.

Stage 4: Cracking infrastructure

The cracking layer is carefully engineered rather than ad-hoc. A Telegram bot accepts hash input, restricts access by Telegram username, detects hash modes, requests contextual hints, schedules jobs, allocates GPUs, launches multi-stage Hashcat workflows, monitors ETA and progress, and returns cracked results. Hashcat modes include NetNTLMv2, FortiGate256, RAKP, MSSQL, and multiple Kerberos formats. Hashtopolis and a custom HashPanel provide additional distributed cracking management, while setup scripts prepare GPU workers and agent enrollment.

Figure 7: The code for the bot.py file that operates via Telegram. Note the operator name plainly visible in the Admin field.

Translation of Figure 7 (above) from Russian to English language:

Figure 8: Sanitized Telegram Hashcat bot snippet showing GPU allocation and representative hash-mode support.

Stage 5: Kerberos QA, correlation, and prioritization

The Kerberos workflow includes QA and correlation utilities. check7500.py validates KRB5PA RC4 format. deep_analyze.py diagnoses checksum and encrypted timestamp ordering for Hashcat mode 7500. collect.py extracts relevant cracked Kerberos entries from potfiles. match_7500.py, match_19900.py, and match_19900_v2.py map cracked Kerberos passwords back to harvest sessions and source folders.

Here’s where things get interesting. Domain-indexing scripts map domains to folders, source IPs, countries, and cracked/uncracked status. Revenue-enrichment scripts rank organizations by company, industry, country, and approximate revenue to prioritize cracking and follow-on operations.

Stage 6: VPN-bound AD and SMB validation

Where recovered credentials enabled access, operators used authenticated SSL VPN tunnels and pivot-bound Impacket tools. Several scripts monkey-patch socket.socket.connect to bind outbound traffic to a victim VPN-pool address. This makes LDAP, Kerberos, and SMB traffic appear to originate from inside the victim network.

ad_enum.py and ad_full_audit.py enumerate Domain Admins, roastable accounts, delegation paths, passwords in description fields, AdminCount=1 accounts, DNSAdmins, GPO counts, legacy operating systems, and other privilege-relevant AD conditions. spray_da.py, spray_admin.sh, and spray_all.sh validate credentials through Kerberos TGT acquisition. smb_test.py validates SMB authentication, checks administrative share access, and enumerates readable shares.

Figure 9: Sanitized ad_full_audit.py snippet, showing VPN-pool source binding and LDAP roastability queries.

Stage 7: SMB spidering and DFS/SMB exfiltration

After validation, the actor used SMB tools in escalating stages. spider.py rapidly searches accessible shares for secrets inside small script, text, configuration, SQL, and RDP-like files. backup_dfs.py appears to be a triage collector with a smaller share set and a file-size cap. backup_dfs2.py is the more complete collector: it walks seven shares, including administrative shares, excludes system directories, uses a maximum recursion depth, skips files already present on the remote staging host, and streams file contents over SSH without requiring local staging.

Figure 10: Sanitized spider.py snippet showing SMB share enumeration and secret-like keyword searches.

Figure 11: Code snippet from the backup_dfs2.py file responsible for uploading data to a remote server.

Figure 12: Sanitized backup_dfs2.py snippet showing SSH pipe upload and recursive SMB collection logic.

Network Infrastructure

The infrastructure spans both attacker-controlled and victim-assigned components. The local operator infrastructure includes a seven-VM Kali lab and shared CyberStrike installation paths. The “cracking” infrastructure includes Hashcat, Hashtopolis, HashPanel, Telegram bot orchestration, GPU workers, shared potfiles, dictionaries, masks, and rules.

The exfiltration path uses SSH streaming to a remote staging node. Victim-assigned VPN pool addresses appear in multiple scripts as source-binding pivots; these should be treated as contextual indicators, not globally blockable infrastructure.

Figure 13: Hashtopolis login panel discovered in the wild.

Targets and Victimology

Public reporting describes FortiBleed as a global campaign affecting Fortinet/FortiGate devices across many sectors and geographies. The recovered tooling supports broad targeting at the harvest stage and more selective prioritization at the follow-on stage.

Domain, country, folder, cracked/uncracked hash count, and revenue-enrichment logic all appear in the recovered scripts. This means initial acquisition is broad, while operator attention is likely focused on organizations with higher-value access, better cracking yield, and more interesting internal-network outcomes.

Initial analysis indicates the following potential radius of interest:

Figure 14: FortiBleed campaign timeline.

Attribution

We have not attributed this campaign to a known threat actor, and as of publication, it has not been publicly attributed to one. The available anchors, CyberStrike tool branding, the operator handle, and Russian-language interface strings lead us to assess with low confidence that the operators are Russian-speaking, but they are not sufficient to name a specific actor.

We assess that this operation is likely an initial-access brokerage and credential-monetization effort, with supporting access operation or a hybrid model in which credential harvesting enables selective high-value collection. The revenue-ranking and broad device harvesting support monetization, while defense-sector exfiltration material reported publicly shows that the access can indeed be used for targeted data theft.

Conclusions

FortiBleed demonstrates how exposed perimeter credentials can become full internal-network exposure. The campaign does not depend on a single malware payload. It uses a credential pipeline to acquire or test credentials, export configurations or capture traffic, transform captures into hashes and cleartext credentials, crack and correlate results, validate access through VPN/Kerberos/SMB, then collect data from internal shares.

The most important finding is the engineering discipline around the workflow. The operator lab, sniffer panel, CyberStrike Harvester, cleaning scripts, Hashcat/Hashtopolis infrastructure, Kerberos QA tools, domain/folder/revenue enrichment, and SMB/DFS tools form a repeatable system. Remediation must therefore go beyond patching FortiOS.

Affected organizations must rotate credentials, invalidate sessions, audit configuration exports, review SSL VPN logins, inspect AD and SMB activity from VPN pools, and assume that passively captured internal credentials may have been exposed.

How Arctic Wolf Protects its Customers

Arctic Wolf is committed to ending cyber risk, and when active campaigns are identified, we move quickly to protect our customers. We have leveraged threat intelligence around this threat activity to enhance detections in the Aurora® Superintelligence Platform, subject to customer environment and available telemetry.

As we track this campaign and discover new information, we may further refine our detections to account for additional indicators of compromise (IOCs) and techniques leveraged by the threat group behind this malicious activity.

Remediation

The scale of this exposure demands an emergency response, not a scheduled maintenance window. For every Fortinet device in your environment, do four things this week:

• First, terminate all active SSL VPN and administrative sessions immediately.
• Second, reset every administrative and VPN credential, regardless of whether your specific device appears on the leaked list, because you cannot verify completeness.
• Third, enable phishing-resistant MFA on all administrative accounts.
• Fourth, restrict management interface access to a dedicated jump host on a management VLAN.

However, the deeper fix is structural, and it is easy to get wrong. Requiring an administrator login after every device upgrade migrates the active credential to PBKDF2, but the legacy SHA-256 hash can survive in a hidden old-password field, where it remains crackable from an exported configuration.

To actually strip it, enable the login-lockout-upon-weaker-encryption setting in the system password policy on FortiOS 7.6.x, or login-lockout-upon-downgrade on 7.2.x and 7.4.x. Then review the past 90 days of VPN session logs for authentications from unexpected geographies, especially those matching infrastructure linked to the Russian-speaking threat group described above.

Fortinet Recommendations

Fortinet has said that it is contacting all customers with potentially affected systems to assist. The company also issued a set of recommendations for any organization using an affected device, including the following advice:

• Rotate all FortiGate administrative, SSL VPN, and local appliance credentials. Remove or rename generic and default administrative accounts. Force re-authentication so any legacy exported password material is invalidated.
• Enforce MFA on all SSL VPN and management access. Restrict administrative interfaces to trusted management networks and remove public exposure wherever possible.
• Invalidate active SSL VPN sessions and monitor for token/session reuse. Review logs for abnormal session-source changes, configuration downloads, and repeated login attempts.
• Audit FortiGate configuration export events. Treat downloaded configuration files as sensitive credential material and rotate secrets present in historical exports.
• Hunt for outbound SSH transfer patterns, especially large or sustained file transfers from file servers or VPN-adjacent hosts to external infrastructure.
• Hunt AD for LDAP enumeration, Kerberos TGT spray patterns, RC4 service-ticket requests, AS-REP roastable accounts, SPN-bearing service accounts, delegation exposure, AdminCount=1 users, DNSAdmins membership, and passwords in directory description fields.
• Review SMB share access logs for bulk recursive reads, administrative share access from VPN-pool addresses, and many small reads of scripts/config/text/RDP files.

Organizations can additionally use FortiBleed asset checkers such as SOCRadar’s FortiBleed Checker or Hudson Rock’s FortiBleed Checker to see if their domains or IP addresses have potentially been compromised.

APPENDIX 1: Indicators of Compromise (IOCs)

The following table lists high-confidence core indicators. Full file-manifest hashes should remain in the case repository. Network indicators are defanged for report safety. Secrets, tokens, cookies, private keys, and victim-identifying paths are intentionally excluded or redacted.

NOTE: This report contains sensitive technical indicators intended for defensive use. Do not use these indicators or techniques for offensive purposes.

Yara Rule

rule CyberStrike_Harvester_v1_5 {
meta:
        description = "Rule to detect CyberStrike_Harvester_v1.5 using in FortiBleed incident"
        author = "Arctic Wolf"
        distribution = "TLP:CLEAR"
        version = "1.0"
        last_modified = "2026-06-22"
        sha256 = "2758f4d71a2a2dfdefab81737c2d776b2a3dafe5844fdd2157e089a28447ca98"
 
strings:
 
        $a1 = "-s HARVEST" ascii wide
        $a2 = "ENUMresultsHASHCAT%s" ascii wide
        $a3 = "(scan  MB in pacer: % CPU ( zombie" ascii wide
        $a4 = "_passwait_userNet" ascii wide
        $a5 = "EXTRACTAS-REP/KRB" ascii wide
 
 condition:

    ((uint32(0)==0x464c457f) or
    (uint32(0) == 0xfeedfacf) or (uint32(0) == 0xcffaedfe) or
    (uint32(0) == 0xfeedface) or (uint32(0) == 0xcefaedfe) )  and filesize < 8000KB and (4 of ($a*))
}

Brief MITRE ATT&CK® Information

Detailed MITRE ATT&CK® Mapping

Legal disclaimer: Attribution reflects Arctic Wolf Labs’ assessment as of the report period and may evolve with new evidence. References to threat actor identity, nexus, and intent are analytical judgments, not statements of legal fact. This alert is provided for informational purposes only and does not constitute a guarantee of detection or prevention. Defensive effectiveness varies by environment, configuration, and available telemetry.

References

1. SOCRadar: FortiBleed 2026: 86644 Fortinet Firewalls Compromised. https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised/
2. Arctic Wolf: Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries. https://arcticwolf.com/resources/blog/active-fortibleed-campaign-impacting-fortinet-devices-across-194-countries/
3. Reuters: Fortinet says credential-harvesting campaign is targeting its Firewalls and VPN devices. https://www.reuters.com/world/fortinet-says-credential-harvesting-campaign-is-targeting-its-firewalls-vpn-2026-06-17/
4. Sophos: FortiBleed credential exposure and VPN bruteforcing campaign advisory. https://www.sophos.com/security-advisories/fortinet-fortibleed-credential-exposure-and-sophos-vpn-bruteforcing-campaign
5. Recorded Future: FortiBleed Campaign Exposing Credentials for 73,932 FortiGate Systems https://www.recordedfuture.com/blog/critical-fortibleed-campaign

Additional Arctic Wolf Resources:

• Read our previous blog on FortiBleed
• Arctic Wolf’s free Threat Intelligence newsletter: ThreatPulse Community Edition
• Arctic Wolf Tech Den
• Arctic Wolf Blog

About Arctic Wolf Labs

Arctic Wolf Labs is a group of elite security researchers, data scientists, and security development engineers who explore security topics to deliver cutting-edge threat research on new and emerging adversaries, develop and refine advanced threat detection models with artificial intelligence and machine learning, and drive continuous improvement in the speed, scale, and detection efficacy of Arctic Wolf’s solution offerings.

Arctic Wolf Labs brings world-class security innovations to not only Arctic Wolf’s customer base, but the security community at large.