Fortinet Credential Theft: FortiBleed Turns FortiGate Firewalls into Credential Harvesting Points

Fortinet credential theft is no longer just a leaked-device-credential issue. FortiBleed research suggests compromised FortiGate firewalls were reportedly used to harvest authentication material from traffic involving VPN, directory, database, email, and remote administration services.

SOCRadar identified FortigateSniffer, a custom Golang-based tool allegedly used after attackers gained administrative access to FortiGate devices. The tool reportedly abused FortiOS’s legitimate diagnostic packet-capture feature to collect authentication data.

Fortinet says its initial analysis points to credential reuse and brute-force activity, not a new Fortinet vulnerability. Fortinet links the activity to reused credentials, weak password hygiene, missing MFA, and brute-force techniques. Separately, SOCRadar reported that compromised FortiGate devices were used to capture authentication traffic.

From Firewall Access to Identity Exposure

FortiGate devices are valuable targets because they sit where many authentication flows converge. In enterprise environments, they may handle VPN access, directory lookups, database connections, email protocols, and remote administration traffic.

That position changes the impact of compromise. Once attackers gain administrative access, they can potentially collect authentication material from traffic passing through the device.

In the FortiBleed reporting, this shift matters for three reasons:

• The exposure starts at the edge: CISA warned that leaked credentials were associated with approximately 74,000 Fortinet devices, including firewalls and VPN gateways.
• The risk moves inward: SOCRadar’s expanded research says compromised FortiGate firewalls were reportedly used with custom sniffers to harvest authentication secrets.
• The targeted data may go beyond firewall logins: FortigateSniffer reportedly targeted credentials and authentication artifacts across protocols such as Kerberos, LDAP, SMB, RADIUS, RDP, WinRM, SMTP, and database services.

This makes Fortinet credential theft more than a FortiGate administrator password problem. If a compromised firewall observes authentication traffic, the investigation should include the accounts, services, and endpoints connected to that traffic.

How FortigateSniffer Reportedly Worked

SOCRadar described FortigateSniffer as a Golang-based tool used after attackers obtained administrative access to FortiGate devices. SOCRadar reported that the tool connected over SSH and launched FortiOS’s built-in diagnostic sniffer packet functionality.

That command is legitimate. Administrators use it to troubleshoot packet flows, inspect connectivity problems, and diagnose network issues.

In FortiBleed, the same capability was allegedly used for credential collection. The reported workflow followed five steps:

• Attackers accessed FortiGate devices with administrative privileges.
• FortigateSniffer launched a packet capture against authentication-heavy traffic.
• Captured data was reconstructed into PCAP files.
• A Python-based toolkit parsed the captured traffic.
• SOCRadar says password hashes were converted into Hashcat-ready files for offline cracking.

SOCRadar reported that FortigateSniffer monitored authentication-related traffic across Kerberos, LDAP, SMB, RADIUS, RDP, WinRM, SQL database, email, FTP, and Telnet protocols.

This makes the campaign broader than VPN credential theft. If the reporting is accurate, FortiBleed may have exposed authentication material across multiple enterprise services.

What the Reported Numbers Actually Mean

FortiBleed reporting includes several figures, but they do not measure the same thing. Some describe leaked Fortinet device credentials. Others refer to scanned hosts, fingerprinted FortiGate devices, verified firewall credential records, or harvested authentication data.

These figures should not be merged into one claim. They describe separate layers of FortiBleed activity: scanning, fingerprinting, credential exposure, verified firewall access, and broader authentication harvesting. For defenders, the takeaway is clear. FortiBleed should be investigated as both an edge-device compromise risk and an identity exposure risk.

Why Kerberos, NTLM, and Service Credentials Matter

The key risk in FortiBleed is not only the number of firewalls involved. It is the type of authentication material allegedly targeted.

SOCRadar-linked reporting says FortigateSniffer extracted cleartext credentials, password hashes, Kerberos tickets, NTLM authentication material, email credentials, database credentials, and other authentication artifacts from captured traffic.

These artifacts can support follow-on compromise. A VPN password may enable remote access. A cracked NTLM hash may reveal a reusable Windows password. Email, database, or service credentials may open access to sensitive internal systems.

This does not confirm lateral movement or data theft in every affected environment. It means responders should treat FortiBleed as more than firewall cleanup. If a compromised FortiGate device processed authentication traffic, the investigation should include the services and accounts that crossed it.

Where Hexnode Fits After Edge-Device Exposure

FortiBleed is not a FortiGate detection story for Hexnode. It is a post-exposure endpoint-visibility-and-control problem.

Hexnode UEM can help teams:

• Identify managed devices that may be used to access sensitive systems
• Review compliance status across endpoints
• Enforce policies on managed devices used by administrators
• Maintain device inventory and update management across supported endpoints
• Strengthen configuration control across managed endpoints

Hexnode XDR can help teams:

• Review endpoint posture and agent status
• Track endpoint incidents and security events
• Investigate endpoint activity using telemetry
• Verify policy rollouts, pending endpoint configurations, and deployment failures

For FortiBleed response, use Hexnode UEM and Hexnode XDR alongside firewall logs, VPN logs, identity telemetry, and network monitoring. The goal is not to detect FortiBleed directly, but to improve endpoint visibility and control after credential exposure.

Featured resource

Building a cybersecurity framework for your enterprise

Understand key cybersecurity frameworks and how UEM strengthens enterprise security, compliance, and risk control.

DOWNLOAD

Conclusion

FortiBleed shows why credential theft involving edge devices can become an identity exposure problem. A firewall with administrative access does more than enforce perimeter policy. After a compromise, it may sit in the path of authentication traffic that attackers could capture and analyze.

The priority is to determine what the compromised device could see, which credentials may have crossed it, and where those credentials were used next. Firewall hardening, credential rotation, identity log review, and endpoint visibility all belong in the same response plan.