TechPastWeek logo
Security9 min read

A Firewall Campaign Exposed 70,000 Credentials. The VPN Sessions Are the Bigger Risk.

Group-IB and NyxLab tie the k0t campaign against FortiGate and GlobalProtect appliances to 70,000 credentials, and to VPN sessions patching cannot close.

A Fortinet FortiGate 6501F firewall chassis photographed on a carpeted floor, showing its ventilation grilles, status display and rows of network ports.
On this page

Key takeaways

  • Group-IB and NyxLab published a joint investigation on 21 October 2026 into the k0t campaign against Fortinet FortiGate and FortiWeb appliances and Palo Alto Networks GlobalProtect gateways.
  • The researchers identified more than 70,000 exposed credentials and related data, including LDAP dumps, with negligible overlap with the earlier FortiBleed credential dataset.
  • The actor, tracked as k0t with the aliases CryptoFeel, Member19 and QazWsxShop, was first seen in the wild on 22 October 2025.
  • Many FortiGate compromises date to February-June 2026; 37.6% of unique domains in the dataset were in Asia-Pacific, 31.9% in Latin America, 15.8% in Europe and 12.7% in the Middle East and North Africa.
  • Group-IB found 28 active MeshCentral device groups holding 84 compromised devices, plus artifacts for 100 more groups that had since been removed.

Group-IB and NyxLab published a joint investigation on 21 October 2026 into a campaign that harvested credentials from internet-facing firewalls and VPN portals, mainly Fortinet's FortiGate and FortiWeb line and Palo Alto Networks' GlobalProtect gateways. The Hacker News reported the findings on 23 October. The researchers attribute the activity to a criminal handle, k0t, also seen as CryptoFeel, Member19 and QazWsxShop, and count more than 70,000 exposed credentials and related data, including LDAP dumps.

Related reading: Leakers$ Hijacked Public LED Billboards in Egypt, Malaysia and Brazil · Sony's Japanese ISP Arm Says a Breach Exposed 2.6 Million Records.

The number is easy to misread. Seventy thousand is a count of credential entries, not of breached organizations, and Group-IB does not put a victim figure on the campaign at all. What matters for defenders is the sequence behind it: an appliance that can be found from a search engine, a configuration file that decrypts with a key everyone knows, and a VPN session that may outlive the credential used to open it.

What the 70,000 actually counts

The dataset described in the Group-IB and NyxLab report is operational material: credentials for network devices, plus directory dumps of the kind an appliance holds when it authenticates staff against LDAP or Active Directory. Group-IB says the set had negligible overlap with the FortiBleed credential data reported earlier in 2026, which matters because a defender who cleaned up after FortiBleed might otherwise assume this list is the same one.

It is not a victim list. Group-IB notes that victim identifiers range from public domains and email addresses to internal IP addresses, and that exact attribution cannot be verified for the whole dataset. Unique domains found in the material give a lower bound on affected organizations. The regional split of those domains is 37.6% Asia-Pacific, 31.9% Latin America, 15.8% Europe and 12.7% Middle East and North Africa. The researchers are explicit that this reflects where exposed devices were found by scanning, not a plan to target those regions.

Many of the FortiGate compromises carry dates between February and June 2026, the same window as FortiBleed. Group-IB assesses with moderate confidence that the activity belongs to the wider FortiBleed-related cluster, while saying the evidence does not establish that the same operators ran both datasets. The two figures that circulate for these campaigns also measure different things. Cryptopolitan summarized the FortiBleed count as 86,644 compromised devices, citing SOCRadar. Adding one campaign's credentials to another campaign's devices produces a bigger number and no useful picture.

A credential count is not a body count

Seventy thousand entries can describe one organization with a large directory or thousands of small ones. Group-IB does not say how many organizations were breached, how much data left, or how many of the credentials still work. Anyone quoting the figure as a company count is adding a claim the report does not make.

A scanner, not a research team

The reconnaissance explains the spread. k0t did not appear to pick victims by industry or by rumor. According to the report, the operator bought or borrowed access to attack-surface search engines, asking in a public forum for a premium FOFA account or someone who could export IP lists from FOFA, ZoomEye and Censys, and later saying he had found partners for FOFA and ZoomEye. Bulk results in ip:port format were requested so automated tools could process them.

The searches concentrated on GlobalProtect portals, filtered by login-page characteristics, response headers and certificates, first in North America and then across Europe and Asia-Pacific. FortiGate and FortiWeb systems were also in the queue, and SonicWall SMA1000 consoles, OPNsense and Cisco ISE appear in the operator's monitoring. The report says there is no evidence of a successful SMA1000 compromise.

“k0t appears to select potential targets by enumerating exposed network appliances at scale rather than researching individual organizations.” — Group-IB and NyxLab researchers, 21 October 2026

That distinction matters because exposure, not industry, decided who appeared in the dataset. The tooling matches that approach: a FortiGate scanner that ingests a text file of addresses, tags each one with a country from a bundled GeoIP database, and runs a pool of worker threads over the list. The report notes a hardcoded exclusion list for the CIS region and other jurisdictions that can be switched off with a flag, and that some victims came from the excluded countries, suggesting the flag was used. Cybersecurity News also walked through the two custom scripts behind the operation.

The default key that makes a firewall confess

Once inside a FortiGate, the tool can download the appliance configuration and decrypt it locally. The key is the default FortiOS AES key, a weakness tracked as CVE-2019-6693. Fortinet's fix was to add a private-data-encryption option. If nobody turned it on, the device keeps using the known key, and a configuration backup becomes a readable file.

A firewall configuration holds more than rules. It contains the credentials the appliance uses to bind to LDAP or Active Directory, plus administrator and local-user accounts, because the device needs those secrets to do its job. An attacker who can decrypt the file inherits the relationships those secrets authorize. No exploit is required at that point, only a download and a decryption routine.

This is the least dramatic step in the chain and probably the most consequential. An unpatched appliance is a temporary exposure that a maintenance window can close. A directory credential copied out of a configuration file stays valid until someone changes it, and the appliance gives no sign that it was read. Group-IB's defensive guidance treats a compromised edge device as a potential enterprise credential compromise for exactly this reason.

Two ways past the login

The initial access methods differ by product.

On FortiWeb, the tool exploits CVE-2025-64446, a relative path traversal that can let an unauthenticated attacker run administrative commands through crafted HTTP or HTTPS requests. The request impersonates the built-in prof_admin account with a forged header, then creates a new local administrator with a random eight-character username and the same string as its password. The new account gets the prof_admin profile and a trusted-host range of 0.0.0.0/0, which means it can log in from anywhere.

On FortiGate, where that path does not apply, the fallback is brute force against the REST API, using usernames such as admin, fortinet and sysadmin and passwords such as admin and fortigate. When the device returns a lockout code, the tool parks the host for 60 seconds and retries, which happens to match the default FortiGate administrator lockout timer. The report reads that detail as a sign the tool's author knew the product.

The Palo Alto route uses CVE-2026-0257, an authentication bypass in PAN-OS and Prisma Access GlobalProtect portals and gateways, but only where authentication-override cookies and the relevant certificate configuration are enabled. The exploit forges a cookie by encrypting a session string with a public key taken from the target's own TLS certificate, then submits it with an empty password to the GlobalProtect login endpoint. A vulnerable device decrypts it, checks the session format and does not check whether the cookie was ever legitimate. From there the tool opens an OpenConnect VPN connection. The Hacker News had already reported Qilin and INC operators attempting to exploit the same flaw.

That last step is why "patch the firewall" is an incomplete instruction. The session is already authenticated. It does not need the password again.

What the access becomes

The post-exploitation playbook is familiar, which is part of why it works. OpenConnect provides the foothold. Discovery covers Active Directory, SMB shares and installed antivirus. Persistence comes from remote-management software: MeshCentral agents, Atera, Teramind, AnyDesk, ngrok, plus AdaptixC2 as a second command channel. Privilege escalation uses NetExec, Impacket, noPac, Kerbrute, PetitPotam and Mimikatz, and exfiltration runs through Rclone into Wasabi S3 buckets and MEGA drives.

The MeshCentral numbers give a sense of scale. At the time of analysis, Group-IB found 28 active device groups holding 84 compromised devices, and artifacts for 100 more groups that had since been removed. The server held no files, which the researchers read as a sign of live interactive access, with data staged and moved separately.

Group-IB also assesses that the operators share connections with the ransomware groups Qilin and The Gentlemen, probably acting as an initial access broker or affiliate. The basis is victim overlap: many organizations in this campaign were later listed on those groups' leak sites. The report calls the relationship unconfirmed, and the caveat deserves repeating. Victim overlap is evidence that access moved, not proof of who sold it to whom.

Patching closes the door, not the session

Both CVEs have vendor fixes, and the campaign exploits known flaws and weak configurations. Neither Fortinet nor Palo Alto Networks is quoted in the report with a new statement, so there is no fresh vendor account of how many devices remain exposed.

TechPastWeek has covered two comparable edge-appliance episodes this month: the Citrix NetScaler zero-days and the FortiMail file-write flaw. Each ended with the same instruction to patch, and each left the same question about what the attacker had already taken. On the FortiBleed side, US government warnings in early October said that activity was still running, which is a poor moment to treat any single patch as closure.

The remediation list that follows from the report is longer than a patch queue:

  • Find every internet-facing FortiGate, FortiWeb and GlobalProtect portal. The report's own advice is exposure-led, not sector-led.
  • Check patch level and configuration. For GlobalProtect, the authentication-override and certificate settings decide whether CVE-2026-0257 applies. On FortiOS, private-data-encryption decides whether a stolen configuration is readable.
  • Assume stored secrets are burned if a device was accessed. Rotate directory bind credentials and local administrators, and revoke VPN sessions instead of waiting for them to expire.
  • Hunt for accounts nobody created: new local admins, changed trusted-host ranges, configuration exports, lockout-and-retry patterns and logins from unusual addresses.
  • Look for MeshAgent, Atera, Teramind, AnyDesk, ngrok and AdaptixC2 installs, and for Rclone writing to cloud storage.

The order matters. Patching first without rotating credentials leaves the intruder's easiest path open, and a session opened through a forged cookie does not care that the bug is fixed.

What remains unknown is large. Group-IB has promised an additional technical report. No victim count, no named victims and no state attribution exist in the public material, and the 70,000 figure will keep being quoted as if it supplied all three. The more useful question for a defender is smaller and answerable: which of my appliances can be found from a search engine, and what would an attacker learn from its configuration file?

Cover image: "Fortinet FortiGate 6501F.png" by Premeditated, CC BY-SA 4.0, via Wikimedia Commons. The image shows a FortiGate 6501F chassis, one of the product lines targeted in the campaign.

Tags

Frequently asked questions

What is the k0t campaign?
It is a campaign, documented by Group-IB and NyxLab on 21 October 2026, that exploited and brute-forced internet-facing Fortinet and Palo Alto Networks edge devices to steal credentials and keep remote access. The researchers linked it to more than 70,000 exposed credentials, including LDAP dumps, and to VPN and remote-management persistence inside victim networks.
Does the 70,000 figure mean 70,000 companies were breached?
No. The figure counts credential entries and related directory records held in the operators' data, not organizations. Group-IB does not publish a victim count, and says unique domains in the dataset give only a lower bound on affected organizations.
Which vulnerabilities did the campaign exploit?
Group-IB observed exploitation of CVE-2025-64446, a path traversal in FortiWeb, and CVE-2026-0257, an authentication bypass affecting GlobalProtect portals and gateways in vulnerable PAN-OS configurations. FortiGate devices are not vulnerable to that FortiWeb exploit and were attacked by brute-forcing the REST API.
Is the k0t campaign the same as FortiBleed?
No. Group-IB found negligible overlap between the two credential datasets, while assessing with moderate confidence that k0t is associated with the wider FortiBleed-related activity cluster. The evidence does not establish that the same operators controlled both datasets.
Share

Found this useful? Share it with your team.

TPW Editorial

TPW Editorial

Editorial Team

TechPastWeek's editorial team reports and edits every story we publish. We research each piece against primary and credible secondary sources, and a human editor reviews and signs off before it goes live.

Featured & most read

Keep reading