CISA Sounds the Alarm: FortiBleed Exposes 74,000+ Fortinet Firewalls – Here’s How to Harden Before Attackers Pivot to Your AD + Video

By /

Listen to this Post

Featured Image

Introduction

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has issued an urgent alert following the discovery of FortiBleed – a massive credential exposure event affecting approximately 74,000 Fortinet devices worldwide, including firewalls and SSL VPN gateways. This is not a vulnerability that can be patched away; it is an active, industrialized credential harvesting campaign where threat actors possess valid administrative and VPN credentials, enabling them to bypass traditional perimeter defenses and pivot directly into internal Active Directory environments. Organizations must treat this as an active compromise risk, not a preventive maintenance issue.

Learning Objectives

  • Understand the scope and mechanics of the FortiBleed credential exposure campaign and why password complexity alone offers no protection.
  • Implement CISA’s recommended hardening actions, including session termination, credential reset, PBKDF2 enforcement, and phishing-resistant MFA.
  • Execute a structured incident response playbook – from log review and isolation to factory reset and post-recovery validation.

You Should Know

  1. FortiBleed Is Not a CVE – It’s an Industrial-Scale Credential Harvesting Operation

Unlike traditional vulnerabilities, FortiBleed has no Common Vulnerabilities and Exposures (CVE) identifier and no single patch to apply. The campaign, uncovered by security researcher Volodymyr “Bob” Diachenko, involves a Russian-speaking threat group that conducted approximately 1.16 billion credential attempts against more than 320,000 FortiGate targets. The attackers sourced credentials from two primary pools: historical Fortinet breach dumps (including the 2021 leak tied to CVE-2018-13379 and the 2022 Belsen Group drop) and infostealer logs – plaintext credentials lifted from infected endpoints.

Critically, password complexity offered no protection. Passwords of 25 or more characters, including symbols and mixed case, were found in the dataset in plaintext – not cracked, but already known from infostealer malware. The exposed dataset spans 73,932 unique FortiGate firewall URLs, 21,632 corporate domains, and covers roughly half of all internet-facing Fortinet firewalls globally.

Step‑by‑Step: Check If Your Organization Is Affected

  1. Use Hudson Rock’s free lookup tool at infostealers.com to search for your domain or IP address in the exposed dataset.
  2. Use SOCRadar’s FortiBleed Exposure Checker to query the attacker’s operational database by IP address and domain.
  3. If your domain appears, assume compromise immediately – do not wait for additional evidence.

  4. Terminate Sessions and Reset Credentials – But That’s Just the Beginning

CISA’s first and most urgent recommendation is to terminate all active SSL VPN and administrative sessions and reset all Fortinet VPN and administrative passwords, especially on internet-facing systems. However, changing credentials alone may not eliminate attacker persistence if backdoors or unauthorized accounts have been created.

Linux / FortiOS CLI Commands for Session Termination and Password Reset

 Terminate all active SSL VPN sessions
diagnose vpn ssl list
diagnose vpn ssl terminate <session_id>

Terminate all administrative sessions (via CLI)
execute session kill all

Reset admin password (FortiOS)
execute admin password <username>

Force password change at next login
config system admin
edit <username>
set force-password-change enable
next
end

Windows / Active Directory Considerations

If attackers have pivoted into AD (confirmed in at least four organizations across Japan, Taiwan, Vietnam, Iraq, and Turkey), resetting Fortinet credentials is insufficient. You must also:

 Force password reset for all domain admins
Get-ADUser -Filter {Enabled -eq $true -and PasswordNeverExpires -eq $false} | 
ForEach-Object { Set-ADAccountPassword -Identity $_.SamAccountName -Reset -1ewPassword (ConvertTo-SecureString -AsPlainText "NewComplexP@ssw0rd!" -Force) }

Force immediate password change at next logon
Get-ADUser -Filter  | Set-ADUser -ChangePasswordAtLogon $true

Review recent Kerberos ticket requests (potential lateral movement)
Get-WinEvent -LogName "Security" | Where-Object { $<em>.Id -eq 4768 -or $</em>.Id -eq 4769 }
  1. Enforce PBKDF2 for Secure Credential Storage – Remove Legacy Hashes

Fortinet migrated to the stronger PBKDF2 hashing algorithm in early 2025, but this only protects accounts whose administrators actively re-authenticated after the firmware update was applied. Many devices still store credentials using the older, weaker SHA-256 with salt, which is vulnerable to offline cracking via brute-force attacks.

Step‑by‑Step: Enforce PBKDF2 on FortiOS (v7.2.11 and later)

1. Verify current hash settings:

config system admin
show

Look for the `hash-algorithm` parameter. If it shows `SHA-256` or SHA-256-SALT, you are using the legacy method.

2. Enforce PBKDF2 globally:

config system admin
set hash-algorithm PBKDF2
end
  1. Force all administrators to re-authenticate so their passwords are re-hashed using PBKDF2: 
    config system admin
edit <username>
set force-password-change enable
next
end

4. Verify:

diagnose system admin list

Confirm that the hash algorithm shows `PBKDF2` for each account.

  1. Enable Phishing-Resistant MFA on All Remote Access and Administrative Accounts

CISA explicitly recommends phishing-resistant multifactor authentication (MFA) – not SMS-based or push-based MFA, which can be bypassed. The FortiBleed dataset includes credentials that were harvested via infostealer malware, meaning even MFA prompts can be intercepted if the session cookie is stolen.

Step‑by‑Step: Deploy Phishing-Resistant MFA on FortiGate

1. Enable FortiToken or FIDO2/WebAuthn:

config system admin
edit <username>
set fortitoken <serial_number>
set two-factor enable
next
end
  1. For SSL VPN, enforce MFA at the user group level: 
    config vpn ssl web user-group
edit <group_name>
set two-factor enable
next
end

  2. Restrict administrative access to trusted IP ranges to reduce the attack surface:

    config system admin
edit <username>
set trusthost1 <IP/mask>
set trusthost2 <IP/mask>
next
end

  3. Audit existing MFA configurations to ensure no accounts are exempt.

  4. Review Logs for Lateral Movement, Unauthorized Accounts, and Configuration Changes

CISA urges organizations to review firewall, VPN, authentication, and domain controller logs for signs of lateral movement, unusual access, suspicious accounts, or unauthorized configuration changes.

Linux / FortiOS Log Review Commands

 View recent administrative logins
execute log display | grep -i "admin login"

Check for unauthorized configuration changes
diagnose sys config-history list

Review SSL VPN login attempts (failed and successful)
diagnose vpn ssl log

Check for new or modified admin accounts
config system admin
show

Windows Domain Controller Log Analysis (PowerShell)

 Check for suspicious account creations (Event ID 4720)
Get-WinEvent -LogName "Security" -FilterXPath "[System[EventID=4720]]" | 
Select-Object TimeCreated, @{Name="User";Expression={$_.Properties[bash].Value}}

Check for lateral movement via network logon (Event ID 4624)
Get-WinEvent -LogName "Security" -FilterXPath "[System[EventID=4624]]" | 
Where-Object { $<em>.Properties[bash].Value -eq 3 -or $</em>.Properties[bash].Value -eq 10 }

Check for unauthorized service creation (Event ID 4697)
Get-WinEvent -LogName "Security" -FilterXPath "[System[EventID=4697]]"

Export all relevant logs for forensic analysis
wevtutil epl Security C:\forensics\Security_$(Get-Date -Format yyyyMMdd).evtx
  1. Reduce Attack Surface – Lock Down Management Interfaces

CISA strongly advises ensuring firewall administration is inaccessible from the public internet and restricting Fortinet management interfaces to trusted internal networks. Hudson Rock’s analysis confirmed that in a majority of cases, the FortiGate management interface was exposed to the internet on impacted devices.

Step‑by‑Step: Restrict Management Access

  1. Identify all administrative interfaces (HTTPS, SSH, SNMP, Telnet) and their current access policies: 
    config system interface
show

2. Restrict HTTPS/SSH access to trusted internal subnets:

config system interface
edit <management_interface>
set allowaccess https ssh
set trust-ip-1 <internal_subnet>
set trust-ip-2 <internal_subnet>
next
end

3. Disable unnecessary services (e.g., Telnet, HTTP):

config system interface
edit <management_interface>
unset allowaccess
next
end
  1. Implement a jump host or bastion for all administrative access, and enforce MFA on that jump host.

  2. Assume Compromise – Isolate, Factory Reset, and Validate Firmware Integrity

If you suspect or confirm a compromise, immediately isolate the device from the internet and internal network to prevent further unauthorized access or lateral movement. Changing credentials alone might not eliminate attacker persistence – especially if firmware integrity or deeper persistence cannot be validated.

Step‑by‑Step: Factory Reset and Post-Recovery Validation

  1. Save all relevant logs, configurations, and forensic artifacts before resetting, as they will be erased during the process: 
    Backup current configuration
execute backup config tftp <config_file.conf> <tftp_server>

Save logs
execute log export

2. Perform a factory reset:

execute factoryreset
  1. Re-image the device using a known-good firmware image from Fortinet’s official portal. Verify the checksum: 
    Linux: verify SHA256 checksum
sha256sum fortios_v7.4.x_image.out

  2. Before reintroducing into production, conduct a rigorous risk assessment. If trust cannot be fully restored, consider replacement.

  3. Post-recovery, apply all hardened configurations (PBKDF2, MFA, restricted management) before reconnecting to the network.

What Undercode Say

  • Key Takeaway 1: FortiBleed is a credential-based attack, not a software vulnerability. There is no patch – only operational hygiene and proactive hardening can mitigate the risk.
  • Key Takeaway 2: Password complexity is obsolete when infostealer malware is involved. The only reliable defenses are phishing-resistant MFA, PBKDF2 hashing, and restricting management interfaces from public exposure.

Analysis: The FortiBleed campaign represents a paradigm shift in how we must think about perimeter security. The attackers didn’t exploit a zero-day; they exploited credential reuse, weak hashing, and exposed management interfaces – all of which are fundamentally operational failures. With approximately 50% of all internet-facing FortiGate firewalls potentially compromised, the downstream impact is staggering: confirmed lateral movement into Active Directory, exfiltration of classified documents from a NATO defense contractor, and full compromise of at least four organizations across multiple countries. Organizations must shift from a “patch-and-forget” mindset to a “zero-trust-for-perimeter” approach, where every firewall is treated as potentially hostile until proven clean. The tools to check exposure exist – Hudson Rock and SOCRadar both offer free lookups – but checking is only the first step. The real work begins with session termination, credential reset, MFA enforcement, and – most critically – a willingness to factory reset and re-image devices when trust cannot be restored.

Prediction

  • +1 Expect a surge in demand for FIDO2/WebAuthn hardware tokens and phishing-resistant MFA solutions as organizations realize that SMS and push-based MFA are insufficient against infostealer-driven attacks.
  • +1 Fortinet and other firewall vendors will accelerate the deprecation of legacy hashing algorithms (SHA-256 with salt) and make PBKDF2 the default, non-optional standard in future firmware releases.
  • -1 The FortiBleed dataset will be actively traded on underground markets for years, leading to secondary and tertiary breaches as attackers who purchased the credentials launch delayed, targeted campaigns against high-value organizations.
  • -1 Organizations that fail to act within the next 72 hours face an elevated risk of ransomware deployment, as initial-access brokers are already packaging verified FortiGate credentials for sale to ransomware crews.
  • -1 The exposure of management interfaces to the internet will remain a persistent problem, as many organizations lack the internal network segmentation or jump-host infrastructure to fully eliminate public-facing administrative access.

▶️ Related Video (68% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Flavioqueiroz Cisa – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: