Contribution
This post adds a detection contribution: treat FortiBleed as a credential-recovery workflow that starts at a perimeter appliance but should be hunted through identity-provider and cloud audit logs. CISA and BitSight describe the Fortinet credential exposure; Sophos adds adjacent evidence that exposed remote-access services were also being tested with brute force and credential stuffing. The missing defender move is the join across VPN session termination, account reset evidence, new cloud sign-ins and post-login privilege changes.
The pattern
FortiBleed is not best read as one more perimeter-device patch story. CISA describes malicious activity against internet-accessible Fortinet devices using compromised credentials, with leaked credentials associated with roughly 74,000 Fortinet firewalls and VPN gateways. CISA's immediate guidance is practical: terminate active SSL VPN and administrative sessions, reset Fortinet VPN and administrator passwords, review firewall, VPN, authentication and domain-controller logs, require phishing-resistant MFA, restrict management access and remove unauthorised accounts. That is credential-recovery language, not ordinary vulnerability-management language.
BitSight's report gives the scale and the uncomfortable part. It describes more than 73,000 internet-facing FortiGate devices across 194 countries, and says the incident does not appear to come from a newly disclosed vulnerability. The report says credentials and configuration data have circulated through underground channels, and that older FortiOS credential handling left some administrator password material weaker than operators expected after upgrades. Fortinet's PBKDF2 guidance explains the operational trap: after an upgrade to FortiOS 7.2.11, 7.4.8 or 7.6.1, existing administrator password hashes may remain in SHA256 form until the administrator logs in or a super-admin resets the password. Configuration backups can also retain legacy old-password hash material. That makes the remediation job broader than installing firmware; teams need to prove that administrator password storage, backups and account resets actually changed.
BitSight also notes tooling seen around related Fortinet perimeter activity, including Chisel and Neo-reGeorg, which matters because a working perimeter credential can become a tunnel before anyone notices a malware payload.
Sophos adds the adjacent signal that makes this broader than one vendor's appliance estate. Its advisory says activity linked to the same public attention also hit internet-exposed Sophos Firewall services through credential brute-forcing and stuffing, especially where VPN portals, SSH or user portals were reachable without MFA. Sophos says successful compromise was very limited in its customer base and that it saw no evidence of Sophos-device vulnerability exploitation. That distinction is useful: the relevant behaviour is credential use against exposed remote access surfaces, not a product-specific exploit chain.
The common pattern is simple enough to miss. A stolen or cracked appliance credential gets tested against a remote access service. If it works, the operator may rotate the Fortinet password and close the appliance finding, but the same person, admin name, email address or password pattern may already have opened doors elsewhere. A firewall administrator may also hold Entra, Okta, AWS IAM Identity Center, M365 or cloud-console roles. The useful question is not only, 'was my FortiGate in the leaked set?' It is, 'which identities touched remote access after the exposure window, and what did those identities do in cloud systems next?'
That is the gap this article targets. None of the cited sources claims a cloud breach from FortiBleed by itself, and this post should not imply one. The defensible claim is narrower: when a perimeter credential set leaks at this scale, defenders need a repeatable method to test whether those credentials became valid-account activity in cloud and SaaS systems. The method is a correlation hunt, not a Fortinet signature.
Why it matters to cloud defenders
Cloud teams often inherit the blast radius of an edge credential leak. The Fortinet box may be owned by network engineering, but the account behind the VPN session may reach cloud consoles, source-code systems, SaaS administration panels and Kubernetes control planes. Once a legitimate remote access session exists, later events look like ordinary administration unless the SOC joins the perimeter login to identity and cloud activity.
The a13e cloud-detection audience should care for three reasons. First, remote access is a bridge between network perimeter and cloud control plane. A VPN login by a privileged engineer can precede AWS ConsoleLogin, Azure Portal access, Entra administrative changes or GCP IAM activity. If those events are analysed in separate queues, the chain is invisible.
Second, credential recovery is time-bound. CISA's actions, session termination, password reset, MFA hardening and log review, create a window defenders can query. The useful window begins before the public alert and ends after reset completion, because attackers may test credentials before the organisation knows it is exposed and again after partial rotation.
Third, this class of incident punishes patch-only reporting. A dashboard that says 'FortiOS updated' does not answer whether old VPN sessions ended, whether local administrator accounts changed, whether leaked credentials still worked against other services, or whether the same user appeared from a new ASN in cloud logs. That is where cloud detection adds value: not by claiming to detect FortiBleed directly, but by catching the account misuse that follows.
ATT&CK mapping
The entry behaviour fits T1110 Brute Force when attackers test passwords through VPN, SSH or exposed portal services. Sophos explicitly describes brute-forcing and credential stuffing against internet-exposed firewall services, and BitSight describes credential material at a scale that makes offline cracking and validation plausible. In ATT&CK terms, the credential-access step is not only the failed login storm; it is also the recovery of usable passwords from weak or exposed material.
The initial access and persistence behaviour fits T1078 Valid Accounts. MITRE describes adversaries abusing existing accounts to gain or maintain access, often through VPNs and other externally available services. FortiBleed's danger is precisely that the login can look legitimate. The device accepts a username and password, the VPN assigns access, and downstream logs show an authenticated user rather than a shell exploit.
The post-login cloud risk fits T1098 Account Manipulation if the same identity or a follow-on compromised identity adds access keys, changes group membership, creates recovery credentials or modifies roles. The cited sources do not show that full cloud chain for FortiBleed; the mapping is for the follow-on behaviour defenders should test for, not evidence that cloud persistence has already happened. CISA tells organisations to look for suspicious accounts and unauthorised configuration changes. In cloud logs, that maps to events such as AWS CreateAccessKey, AttachUserPolicy, UpdateAssumeRolePolicy, Azure role assignment writes, Entra application credential additions, Okta factor resets, GCP service-account key creation or IAM policy changes.
A full chain may also touch External Remote Services and Unsecured Credentials, but those techniques are better left in prose for this post. The three pinned techniques are enough to cover the observable chain without overstating the cloud evidence: credential testing, valid-account access, then account or privilege mutation.
Detection guidance
Start with a FortiBleed exposure set, but do not stop there. Build a time window for every Fortinet VPN or administrative account that might be affected. Include at least three markers: the earliest plausible exposure date from local Fortinet logs or threat-intel notification, the time all active SSL VPN and administrative sessions were terminated, and the time each password reset completed. Add a fourth marker for administrative hash cleanup: when each local administrator account was confirmed to use PBKDF2 and when configuration backups containing old SHA256 material were rotated or protected. For shared administrator accounts, treat the window as open until the shared account is removed or split into named identities.
The first alert should key on successful remote access after the exposure marker and before confirmed reset. For Fortinet logs, look for SSL VPN login success, administrator login success, configuration export, system setting change and account creation. Sophos names Fortinet configuration-file export to an external IP address as an early confirmed abuse pattern in its investigation, which is a good example of a high-value appliance event. A successful VPN login from a new country, ASN or hosting provider is stronger when paired with old credential material or missing MFA.
The second alert should join the remote access account to identity-provider sign-ins. Normalise usernames before the join, because the same person may appear as a Fortinet local admin, an LDAP short name, a UPN, an email address or a SAML subject. In Entra ID, join the VPN username or email address to interactive sign-ins, failed MFA prompts, new device registration, risk events and administrator role activation. In Okta, look for user.session.start, policy.mfa.attempt_bypass, user.account.privilege.grant, factor reset and new API token creation. The separating factor is context: a lone sign-in from a known admin workstation during a maintenance window is ordinary; a VPN login followed by cloud-console access from a new ASN is not.
The third alert should watch cloud-control events by the same identity family. In AWS, query CloudTrail for ConsoleLogin, AssumeRole, CreateAccessKey, AttachUserPolicy, PutUserPolicy, UpdateLoginProfile and suspicious role-session names. In Azure, query audit logs for role assignment writes, app credential additions, conditional-access changes and privileged identity activation. In GCP, query Admin Activity audit logs for SetIamPolicy, serviceAccounts.keys.create and organisation-policy changes. The join key will not always be exact. Use email address, normalised username, source IP, user agent and time proximity, then require a human review before action.
Add one negative check as well: prove that no old sessions survived reset. If the Fortinet side shows session termination at 10:00, identity-provider and cloud logs after that point should not show the same remote source continuing without a fresh MFA-backed sign-in. Session continuity after a reset is not always malicious, but it is exactly the kind of residue credential-recovery work is meant to flush out.
A useful correlation rule looks like this: a Fortinet SSL VPN or admin success for an affected identity, followed within six hours by cloud console access from a new source network, followed within twenty-four hours by privilege, credential or policy mutation. Tune out planned maintenance by change ticket, known break-glass tests and managed service provider source ranges. Do not tune out failed MFA noise too aggressively; after a credential leak, failed MFA prompts can be the best sign that password rotation lagged behind attacker testing.
The false-positive boundary is narrow if the join is strict. Network administrators do log in to VPNs and cloud consoles during incident response. They should not, without a ticket, create new cloud access keys, add application credentials, change conditional access or grant themselves broader roles immediately after a credential-exposure alert. That difference is what makes this hunt worth running.
What to do now
First, follow CISA's Fortinet hardening sequence: terminate sessions, reset Fortinet VPN and administrator passwords, move administrator credential storage to Fortinet's PBKDF2 guidance where applicable, require phishing-resistant MFA and remove internet exposure from management interfaces. Record the completion time for each control. Those timestamps become detection inputs.
Second, build an identity map for remote access accounts. Map Fortinet local users, LDAP users and SAML identities to Entra, Okta, AWS IAM Identity Center, Google Workspace, GitHub Enterprise and privileged SaaS accounts. Mark shared accounts as unresolved risk. If a shared account appears in the exposed set, rotate it, retire it and hunt under every human identity that knew it.
Third, run the three-stage hunt: remote access success, identity-provider sign-in, cloud-control mutation. Keep the chain strict enough to avoid an alert flood, but broad enough to catch reused credentials outside the Fortinet appliance. Include configuration export and administrator login events from the device, not only VPN user sessions.
Fourth, make the remediation report say what happened to credentials, not only what happened to firmware. A good close-out note says which accounts were reset, which sessions were killed, which MFA gaps were fixed, which management interfaces were removed from the internet, which cloud identities were checked and whether any post-login privilege changes were found.
FortiBleed is a perimeter event, but the useful detection work sits in the hand-off from perimeter access to cloud identity. Patch the appliance. Then prove the credentials stopped working everywhere else.