On 3 June 2026, the threat intelligence firm Hunt.io found an open directory on a server in Thailand holding what it describes as 298 files, roughly 19 MB of an intrusion in progress against 3BB, the consumer brand of Triple T Broadband and one of Thailand's largest fixed-line providers. Among them, Hunt.io reports eight shell scripts named forti1.sh through forti8.sh, whose only job was to fingerprint a single SSL-VPN appliance.
Every one of those scripts needed the same thing before it could report anything useful. The appliance had to answer.
What actually happened
Hunt.io's account puts the target as a FortiGate 60F reachable on 3BB's mail hostname on port 10443, running FortiOS in the 7.2.0 to 7.2.6 range from a build dated around June 2023. The flaw aimed at it, CVE-2024-21762, is an out-of-bounds write in the SSL-VPN daemon allowing unauthenticated code execution through crafted HTTP requests, which Tenable's writeup puts at CVSS 9.6.
| Date | Event |
|---|---|
| 8 February 2024 | Fortinet discloses CVE-2024-21762 |
| March 2024 | The Shadowserver Foundation counts close to 150,000 internet-facing devices still carrying it |
| 3 June 2026 | Hunt.io records the open directory, MeshCentral agents connected and running as root |
| 15 September 2026 | Hunt.io publishes, after a TLP:AMBER advance copy to affected parties and the relevant CERT |
The recovered tooling is methodical. Hunt.io describes fingerprinting first, then a script triggering controlled crashes to confirm the condition, then a checker implementing what it identifies as a Bishop Fox detection technique to separate vulnerable builds from patched ones, and only then an exploit using heap spraying and a return-oriented programming chain to call back a reverse shell.
Coverage differs on one material point. SecurityWeek writes that the attackers deployed the exploit to achieve remote code execution. The Hacker News, on the same research, says the initial access vector is unknown and that there is no definitive proof the exploit was used successfully, only that the toolkit was present and tested. Hunt.io documents the toolkit and the live agents without stating it observed the exploit land. TODO(founder) if 3BB issues a statement.
The gap: the flaw was old and the conversation was still open
The controls here are not bad controls. They are controls waiting for an event that reconnaissance never produces.
- Authentication never engaged. The flaw sits in the SSL-VPN daemon ahead of any credential check, so there was nothing for a login to evaluate and no failed attempt to alert on.
- Patching was the right fix and had been available for over two years. It is also the control most sensitive to change windows, and a VPN concentrator at a broadband operator is not a casual reboot.
- What surfaced this was the attacker's own mistake, an exposed staging server found by an outside firm, rather than anything at 3BB.
Notice how much was learned before anything was risked. Model, firmware band, patched or not: all of it came back from a device doing what an SSL-VPN listener is built to do.
A patch removes the flaw. It does not remove the conversation in which a stranger learns which flaw you have.
What would have had to be true
Ask the narrow version. On the day those eight scripts ran, what would have had to be true for them to come back empty?
The appliance would have had to decline to answer a network nobody at 3BB was working from.
Fortinet's guidance for organizations that could not patch immediately was to disable SSL-VPN entirely, and the company said plainly that disabling web mode alone was not a valid workaround. That is honest advice and expensive advice, because SSL-VPN at a network operator is how on-call engineers reach the things they are paid to reach.
Source restriction is the option that leaves people working, and it is in the first chapter of every hardening guide these appliances ship with. It goes unused for the usual reason: a list of trusted networks decays from the moment it is written, and asymmetrically. An address left in too long is silent. An address missing is a call from an engineer who cannot log in during an outage. So the ranges widen until they are no longer a control.
Where Veribound would have fitted
Veribound is a Pre-session Edge Access Control platform and an intelligence layer, not an enforcement point. Nothing above moves. The SSL-VPN tier stays, patching stays, and the organization's own equipment keeps applying its own policy, unchanged.
Agents attest that each device is still the one the organization trusted, and a trust-scoring engine turns those attestations into a per-device decision. What reaches the edge is a trusted origin: the network that device is connecting from, in practice its public address, while the device behind it is still trusted. Those origins stay current in the address groups the policy already references, including on a FortiGate operating as the edge itself.
Applied to a remote access tier of this shape:
- The fingerprinting returns nothing, so the model, the firmware band and the patch state never leave the building.
- The vulnerability is unchanged and the upgrade is still the fix, but through the two years it went unapplied it is reachable only by people already trusted.
- Staff keep working, which is the difference between this and the vendor's own fallback of turning SSL-VPN off.
- The list maintains itself, which is the part that fails everywhere else.
What this would not have done needs care, because the reporting leaves a real gap. If the attacker entered by some route other than the SSL-VPN, which The Hacker News says has not been ruled out, an origin control on that appliance was not the thing that mattered. It would not have interrupted the MeshCentral channel once agents were installed, since outbound traffic is an egress question rather than an origin one. It does nothing about the lateral movement, credential spraying or internal databases Hunt.io describes being reached afterward, all of which followed from access already held, and nothing about the subscriber-facing systems an ISP operates for the public by definition. Veribound does not enforce any of it: the appliance makes the decision, using information it could not work out for itself.
The surviving claim is small, and it is the one the evidence supports. Before anything was exploited, something had to be learned, and it was learned by asking a device that answered.
Source: Thai Broadband Provider Targeted via FortiGate SSL-VPN and MeshCentral Persistence, Hunt.io, 15 September 2026.