Following the FortiBleed path from VPN access to ransomware
Following the FortiBleed path from VPN access to ransomware The FortiBleed credential leak became more consequential when investigators linked it to ransomware access. BleepingComputer reported that the FBI described t
Following the FortiBleed path from VPN access to ransomware
The FortiBleed credential leak became more consequential when investigators linked it to ransomware access. BleepingComputer reported that the FBI described the attack chain as an initial entry point for ransomware affiliates, including INC, Lynx and Payload groups [4]. Earlier reporting connected the credential-theft infrastructure to INC and Lynx operations [5].
Those links do not mean every organization in the dataset was attacked. They do show why a valid FortiGate or VPN credential cannot be treated as a low-severity finding.
The initial access is often quiet
A password-authenticated VPN login can look like normal remote work. The attacker may test a credential, wait, return through a different address and establish a session before making significant changes.
The JaCIRT advisory described the risk of lateral movement into Active Directory and other internal systems after access to a FortiGate [1]. The FBI report added that attackers have created administrator accounts and removed legitimate administrative access, making recovery harder [4].
The investigation should establish a timeline from the first suspicious authentication through endpoint, directory and data-access events. Review VPN sessions, administrator logins, firewall configuration changes, domain-controller activity and endpoint logons. Preserve the original logs before rebuilding a device.
Credential loss can become persistence
An attacker with administrative access can create another account, change authentication settings, add a VPN user or alter a trusted source. These changes can survive the removal of the first credential.
That is why containment must include configuration integrity. Fortinet advised comparing the device against a known-good configuration and checking for unexpected accounts or VPN changes [3]. The review should include logging destinations, routes, certificates and integration settings, not just the account that appears in the credential list.
If the attacker reached Active Directory, the response also needs identity containment. Reset affected credentials, revoke sessions and tokens, review privileged groups and service accounts, and search for new authentication paths. The network edge and the identity system have to be treated as one access chain.
Preserve the edge evidence
The FortiGate may contain the only record of the initial source address, account, session and configuration change. Export logs and configuration before cleanup when policy allows. Record file hashes and collection times.
Do not overwrite the evidence with a factory reset or a clean configuration. If the device must be replaced, keep the original storage and logs in a controlled state for investigation.
Use exposure data for prioritization
The ZoomEye query app="FortiGate" && port="443" returned 41,734 observations on October 19, 2026 [6]. It can guide a review of externally visible FortiGate services and help identify unmanaged edge devices.
The count does not show ransomware access. It describes product exposure. Use it with authentication and configuration evidence to decide which devices demand immediate containment.
Coordinate the response
The network, identity and incident-response teams should share one timeline and one asset register. Confirm which sessions were terminated, which accounts were removed, which credentials were rotated and which persistence checks were completed.
The final decision should be based on evidence that the access path is closed and the configuration is understood. A patched firewall with an unknown administrator account is not contained.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.