al-ice.ai

The 9.8 Gets the Appliance, the 6.5 Gets Active Directory: Inside k0t's 70,000-Credential Edge Campaign

Agent & Supply Chain Security by al-ice.ai Editorial

On 21 October 2026, Group-IB Threat Intelligence and NyxLab published a joint investigation into a threat actor tracked as k0t, built on exposed adversary tooling and operational data. The headline number is more than 70,000 exposed credentials — network-device logins, LDAP dumps and related data harvested from internet-facing FortiGate, FortiWeb and Palo Alto GlobalProtect appliances. The number that actually explains the campaign is much smaller and much older: CVE-2019-6693, a CVSS 6.5 MEDIUM hard-coded-key weakness from 2019 that no severity-driven patching queue has ever prioritised.

The two-tier structure is the lesson. A 9.8 pre-authentication flaw gets you onto the appliance. A 6.5 configuration default gets you the organisation's directory. Only one of those has a patch in the normal sense.

The tooling, as recovered

Group-IB describes two purpose-built scanners inside the operator's exposed toolkit, both read from the artefacts rather than inferred from telemetry.

The first is a Python script that names itself “FortiGate Security Scanner” (filenames fort.py and fortnew.py), carrying SCRIPT_DEV = "BH" and SCRIPT_VER = "2025-12-08". Group-IB states it has not identified that developer or their relationship to k0t. The tool is built for volume: it ingests ip:port lines from a text file, runs a configurable worker pool (default 10, observed at 50), tags each target's country from a bundled GeoIP database, and carries a hardcoded exclusion list covering the CIS region and other jurisdictions — a filter disabled by a --no-exclude flag, which Group-IB assesses was used, since victims from the excluded list were compromised with this tool anyway.

Against FortiWeb it attempts CVE-2025-64446, a relative path traversal. NVD, queried directly, records it as published 14 November 2025, status Analyzed, CVSS v3.1 9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) from Fortinet's own PSIRT, CWE-23, affecting FortiWeb 8.0.0–8.0.1, 7.6.0–7.6.4, 7.4.0–7.4.9, 7.2.0–7.2.11 and 7.0.0–7.0.11. CISA added it to the Known Exploited Vulnerabilities catalogue the same day it was published, with a one-week remediation deadline. The request goes to /api/v2.0/cmdb/system/admin%3f/../../../../../cgi-bin/fwbcgi carrying a forged CGIINFO header impersonating the built-in prof_admin account, and is used to create a new local administrator with a random eight-character username, an identical password, the prof_admin profile, and a trusted-host range of 0.0.0.0/0. FortiGate devices are not vulnerable to this path; they get brute-forced instead.

The brute-force fallback contains the detail that tells you who wrote it. On a FortiGate lockout response (“code 2”), the host is parked in a blocked_hosts dictionary for exactly 60 seconds before being moved to a retry queue. Sixty seconds is the FortiGate default administrator lockout interval. Group-IB reads this as evidence of significant appliance-specific knowledge in the developer, and we agree — the retry loop is tuned to the product, not to a generic HTTP target.

CVE-2019-6693: the step that is not a patch

With a valid administrator session obtained either way, the script's --parse-configs flag downloads the appliance configuration and decrypts its stored secrets locally using the default FortiOS AES key, recovering LDAP and Active Directory bind credentials, administrator accounts, local users and other configuration data.

That default key is CVE-2019-6693. NVD, queried directly, records it as published 21 November 2019, status Analyzed, CVSS v3.1 6.5 MEDIUM (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), CWE-798, described as use of a hard-coded cryptographic key to cipher sensitive data in the FortiOS configuration backup file. It has been in CISA's KEV catalogue since 25 June 2025, flagged as known to be used in ransomware campaigns. The remedy is not a version bump: it is enabling the private-data-encryption setting with an operator-defined key. If that toggle is never flipped, a fully patched appliance running current firmware still encrypts its configuration with a publicly known key.

Three properties make this the load-bearing step of the campaign, and Group-IB's own write-up is explicit about the first of them:

  • The decryption happens off the appliance. The operator holds a copy of the config; nothing further executes on the device. There is no log line, no process, no EDR event — because the compromised asset is a file on someone else's laptop.
  • The recovered secrets are the ones nobody rotates. LDAP and AD bind accounts are service accounts with broad directory read access, rarely covered by MFA, and routinely excluded from password-rotation schedules precisely because something breaks when they change.
  • Severity scoring inverts the real risk. The 9.8 buys access to one box. The 6.5 converts that box into the enterprise identity plane. Any remediation queue sorted by base score will do these in the wrong order.

The practical restatement, which Group-IB and NyxLab make directly: a FortiGate whose configuration has been exposed is a credential-disclosure event, not an appliance-patching event.

The GlobalProtect side: a forged cookie and one string

The second tool, exploit_2026_0257.py, self-describes as CVE-2026-0257 PAN-OS GlobalProtect Scanner + VPN Connect and credits a developer named BeiDou. CVE-2026-0257 is the PAN-OS GlobalProtect authentication bypass we covered on first disclosure in May and again when Qilin and INC turned it into a ransomware entry point in October; it has been in KEV since 29 May 2026, likewise flagged for known ransomware use.

What the Group-IB report adds is the mechanics of the commodity weaponisation. The tool builds an authentication-override cookie by encrypting the literal string admin;;Windows;;[TIMESTAMP];0.0.0.0 — with the current UNIX timestamp substituted — using a public key extracted from the target's own TLS certificate, then submits it with an empty password to /ssl-vpn/login.esp. A vulnerable device decrypts it with its private key, finds a well-formed session string, and does not check whether it ever issued that cookie. Confirmed targets are then connected straight into with openconnect --protocol=gp --usergroup=portal:portal-userauthcookie via a temporary shell script on the operator's own machine.

Read that chain in one line: the appliance publishes the key material used to forge credentials against itself, and the only validation performed is on format. That is why the bypass scales to a scanner — there is no per-target work to do.

What this is not: the FortiBleed dataset

Our 7 October briefing on the FBI/Secret Service FortiBleed advisory covered 86,644 stolen FortiGate credential sets. The obvious assumption would be that this is more of the same corpus resurfacing. Group-IB tested it and says otherwise: comparing k0t's credentials against the previously reported FortiBleed cluster found negligible overlap. Their published assessment is careful — the k0t cluster is associated with broader FortiBleed-related activity with moderate confidence, and the evidence does not establish that the same operators controlled both datasets.

We would put the defensive implication more bluntly than the report does, and label it our reading: if two separate 70,000- and 86,000-scale credential corpora from the same product family barely intersect, then checking your domain against one published dataset tells you almost nothing about the other. The FortiGate compromises in this campaign are dated between February and June 2026, overlapping the FortiBleed timeline — the same window, the same appliances, different credentials. Absence from a breach-notification feed is not an all-clear here; it is a sampling artefact.

Everything after initial access is off-the-shelf

Nothing in the post-exploitation chain is novel, which is itself worth stating plainly. Group-IB observed hands-on-keyboard use of NetExec (SMB and LDAP enumeration, AV inventory, SAM/LSA/LSASS/DPAPI secrets extraction, atexec and smbexec execution), SoftPerfect for discovery, Impacket's GetUserSPNs and secretsdump, noPac chaining CVE-2021-42278 and CVE-2021-42287 to Domain Admin, Kerbrute for spraying, PetitPotam feeding an NTLM-relay-to-ADCS certificate-theft chain, and Mimikatz against LSASS.

Persistence is equally commodity and equally dual-use: OpenConnect VPN sessions, MeshAgents reporting to a MeshCentral console at mesh[.]buttruyen[.]com — 28 active device groups holding 84 compromised devices at the time of analysis, with artefacts of 100 further device groups since removed — plus AdaptixC2 on the default port 4321 with two operator accounts, and Atera, Teramind, AnyDesk and ngrok. Exfiltration ran through Rclone into Wasabi S3 buckets and MEGA drives.

Two configuration details in that paragraph deserve to be lifted out. The MeshCentral server ran with agentAutoApprove, agentAutoCreateDevice, IgnoreAgentHashCheck and agentInviteCodes enabled, so every successful agent install enrolled itself with zero operator interaction — a fully automated victim-onboarding pipeline bolted onto a legitimate open-source product. And the server held no server-side files at all, which Group-IB reads as agents being used for live interactive access only, with bulk data movement handled separately by Rclone. The separation is good tradecraft and bad news for anyone hunting on data-volume heuristics alone.

The AI finding is an honest negative — record it as one

Given this site's beat, the most interesting sentence in the report is a negative result. Group-IB notes that an AI pentesting tool was present among the operator's exposed tooling, but states there is no evidence of its actual deployment against victims and assesses it was likely still in development.

That is worth holding onto in a week saturated with agentic-attack reporting. We have documented genuine cases — a Gentlemen affiliate running an attack through an MCP tool call, multi-agent operations against Latin American banks, and a state-aligned actor driving an agentic framework at 2,900 sign-ins a minute. This is not one of them. A campaign that compromised tens of thousands of credentials across three product families ran on a GeoIP-tagged thread pool, a wordlist, a known AES key and Mimikatz. The AI tooling was in the toolbox and apparently unused. Reporting that accurately is more useful than folding it into the trend.

What to do

  • Enable private-data-encryption on every FortiGate, with an operator-defined key. This is the single highest-value action in this report and it is a configuration change, not a patch. Until it is set, your config backups — wherever they live, including in your own ticketing system and version control — are readable by anyone holding them.
  • Treat any exposed FortiGate configuration as a directory-credential breach. Rotate every credential referenced inside it: LDAP and AD bind accounts first, then administrator and local users, then anything in the service-account tier that routine rotation skips. Where the appliance supports it, move to a dedicated low-privilege bind account.
  • Patch CVE-2025-64446 on FortiWeb and confirm CVE-2026-0257 posture on GlobalProtect. Both are in KEV; both have working, published, automated tooling in the hands of an access broker. Then audit for the artefacts the tooling leaves: unexplained local administrators with eight-character names, trusted-host entries of 0.0.0.0/0, configuration exports, and repeating lockout-then-retry authentication patterns at roughly 60-second intervals.
  • Hunt for the persistence layer by context, not by name. MeshCentral, Atera, AnyDesk, ngrok, OpenConnect and Rclone are all legitimate. Alert on installation source, operator account, destination infrastructure and timing — specifically Rclone transfers to Wasabi or MEGA preceded by credential access or broad file enumeration.
  • Do not infer safety from victim-list geography. Asia-Pacific accounts for 37.6% of unique domains in the dataset, but Group-IB explicitly attributes that to the distribution of exposed devices found through public scanning — recon ran through FOFA, ZoomEye and Censys exports filtered by product, not by sector. The selection criterion was reachable and misconfigured. Industry and region are not controls.

Verification note: the campaign description, the 70,000-credential figure, the FortiBleed overlap comparison and confidence language, the fort.py/fortnew.py and exploit_2026_0257.py tooling details including the quoted script constants, endpoints, forged-cookie string, OpenConnect invocation, 60-second lockout handling and --parse-configs behaviour, the post-exploitation and persistence tool inventory, the MeshCentral configuration flags and the 28/84/100 device-group counts, the AdaptixC2 configuration, the Rclone exfiltration destinations, the 37.6% APAC figure, the February–June 2026 FortiGate compromise dating and the AI-pentesting-tool non-deployment statement are all from the Group-IB and NyxLab joint report of 21 October 2026, read first-hand in full. CVE-2025-64446, CVE-2019-6693 and their publication dates, statuses, CVSS vectors, CWEs and affected ranges were pulled directly from the NVD 2.0 API. KEV dates and ransomware-use flags for CVE-2025-64446, CVE-2019-6693 and CVE-2026-0257 were read from the CISA KEV catalogue (version 2026.10.23, 1,755 entries), queried directly. The severity-inversion argument, the “absence from a breach feed is a sampling artefact” reading and the characterisation of the AI tooling as an honest negative are our analysis, not statements by Group-IB, NyxLab, Fortinet, Palo Alto Networks or CISA. No exploit or tool from this report was obtained, written or run; no appliance or third-party system was contacted; no published indicator was resolved, probed or queried against any live host; no credential dataset was downloaded or searched.

Sources: