Two firewalls in a small business are usually the only thing standing between the internet and everything else. A campaign described this week treated thousands of them as a bulk target list.
What happened
Group-IB and NyxLab published a joint investigation into an operator tracked as k0t, describing large-scale exploitation and brute forcing of internet-facing network devices. The dataset contains more than 70,000 exposed credentials tied to network devices and LDAP dumps, separate from the earlier FortiBleed cluster.
Initial access comes from a custom tool the authors call FortiGate Security Scanner. Against FortiWeb it exploits CVE-2025-64446, a relative path traversal rated 9.4 that lets an unauthenticated attacker run administrative commands. The tool forges a header to pose as the built-in prof_admin account and creates a new local administrator with a random eight-character name, unrestricted trusted hosts and full profile rights. FortiGate itself is not vulnerable to that flaw, so the same tool falls back to brute forcing the REST API with common Fortinet username and password pairs, pausing 60 seconds when lockout is detected, which matches FortiGate's default lockout timer.
After a successful login the operator downloads the appliance configuration and decrypts the stored secrets offline using Fortinet's default AES key, recovering LDAP and Active Directory bind credentials, local users and administrator accounts. That weakness is tracked as CVE-2019-6693, and Fortinet's fix is the private-data-encryption setting, which does nothing on devices where nobody switched it on.
Persistence is ordinary: MeshCentral agents, Atera, AnyDesk and ngrok, plus AdaptixC2, with data pushed out through Rclone to cloud storage. Group-IB notes overlaps between compromised organisations and victims later listed by Qilin and The Gentlemen, and assesses a possible initial access broker role, though the relationship is unconfirmed.
Who is affected
- Organisations with FortiGate or FortiWeb management interfaces reachable from the internet
- FortiGate devices still on default or shared admin credentials, or with admin accounts using weak passwords
- Firewalls whose configuration backups decrypt under the default key because private-data-encryption was never enabled
- Networks where the firewall holds LDAP or Active Directory service credentials in its configuration
What to do now
Get management off the internet, enable private-data-encryption, and rotate every credential the firewall can see.
- Restrict HTTPS and SSH administration to trusted source addresses or a VPN, and remove any admin account with trusted hosts set to 0.0.0.0/0.
- Audit FortiWeb for the CVE-2025-64446 patched releases and confirm no unexpected local administrator accounts exist.
- Enable private-data-encryption on FortiGate, then re-save the configuration, and treat every credential stored in the old config as exposed.
- Change the LDAP and Active Directory service account passwords held by the firewall, and review domain accounts for logins from the appliance.
- Hunt for MeshCentral, Atera, AnyDesk or ngrok appearing on hosts where nobody approved them.
What this means for South African businesses
The local pattern that makes this dangerous is remote support convenience: a FortiGate 40F or 60F with HTTPS admin open to the world so the provider can log in from anywhere, on a shared admin account, with a config backup sitting on a NAS. In our judgment the single highest-value fix for a South African SME this week is closing management access and enabling private-data-encryption, because it removes the credential harvest that turns one firewall login into domain-wide access. If a FortiGate here has ever been reachable on 443 from the internet with weak admin credentials, assume its stored LDAP credentials need rotating rather than auditing.
Source: Group-IB, Stray Cat, Open Doors.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.