A carrier taken with a 2024 flaw and held with a management agent it did not install

An ISP entered with a 2024 flaw and held with a legitimate management agent

Hunt.io published research on 14 September 2026 describing an operator with root-level access inside 3BB (Triple T Broadband), one of Thailand’s largest fixed-line broadband providers ^[1][2]. The finding came from an exposed staging server captured on 3 June 2026 while operations were live: 298 files across 30 subdirectories, roughly 19 MB, tagged by the operator into categories including Exploit, Victim, Config and History ^[1][3].

Initial access was CVE-2024-21762, an out-of-bounds write in the FortiOS SSL-VPN daemon, used against a FortiGate 60F serving an SSL-VPN endpoint on a 3BB hostname ^[1][4]. Fortinet published the fix on 8 February 2024 in advisory FG-IR-24-015 ^[5]. The flaw was on CISA’s Known Exploited Vulnerabilities catalogue from 9 February 2024, as recorded in the Canadian Centre for Cyber Security’s alert AL24-003 ^[7]. The operator was inside a national broadband provider using a vulnerability that had been patched, publicly catalogued as exploited and nationally advised for more than two years.

The severity ratings differ and both are worth recording. Fortinet scores it 9.6 and the NVD scores it 9.8 ^[5][6]. Fortinet’s advisory says the flaw is “potentially being exploited in the wild” while its own Known Exploited field reads “No” ^[5]; CISA and the Canadian Centre both treat it as actively exploited ^[7]. The vendor’s caution and the catalogue’s conclusion have not been reconciled in two and a half years.

The objective was the subscriber authentication store

This was not an opportunistic web-shell drop. Hunt.io records that the RADIUS databases radius_corp and radiusinfo “were directly targeted for subscriber credential extraction”, via a script using hardcoded root MySQL credentials ^[1]. The toolkit also contained an OpenVPN client certificate issued by Triple T Broadband’s own PKI, and active session cookies from a system belonging to Jasmine International, with parallel targeting of Jasmine systems observed ^[1].

At a carrier, RADIUS is the asset. It is where subscriber authentication lives, which makes a compromise there a subscriber-population problem rather than a corporate one. Hunt.io does not confirm exfiltration, and neither does subsequent reporting ^[1][2]. What is documented is that the store was identified, reached and targeted.

Lateral movement was methodical and used old, well-known privilege escalation: SSH password spraying against more than 55 internal hosts, harvesting of SSH keys and database credentials, and exploitation of an internal Pentaho business intelligence server, with PwnKit (CVE-2021-4034) and Dirty COW (CVE-2016-5195) among the escalation paths ^[1]. Hunt.io also notes that the brute-force scripts contained organisation-specific passwords, “suggesting the actor had knowledge of 3BB-specific credentials. The source of that knowledge is unconfirmed” ^[1]. That is the researchers’ wording and it should stay that way; no actor is named in the research, and none is named here.

Persistence was an open-source management platform, deliberately preserved

After establishing access the operator deployed MeshCentral, an open-source remote monitoring and management platform, as the persistence layer ^[1][2]. The recovered configuration named a device group TH-3BB reporting to a purpose-registered domain over a WebSocket endpoint on port 443, with agents running as root and multiple devices showing as connected at the time of discovery ^[1]. The domain was registered on 27 January 2026 and moved behind Cloudflare on 28 June 2026, which Hunt.io reads as purpose-registered command infrastructure rather than a compromised legitimate site ^[1]. A second mesh group in the same configuration referenced an additional organisation, indicating the deployment was intended to manage more than one target environment ^[1].

The anti-forensics step is the one to read twice. A cleanup script removed auth.log, syslog, nginx logs and kern.log along with exploitation artefacts, while “deliberately preserving the installed MeshCentral agent for continued access” ^[1]. The operator destroyed the evidence of entry and kept the means of return, because a signed management agent does not look like malware and survives a cleanup that a web shell would not.

That choice is not unusual any more. Huntress reported on 11 March 2026 that chaining distinct RMM tools to fragment telemetry and distribute persistence rose 277 per cent year on year and accounted for nearly a quarter of observed incidents ^[9]. Microsoft named Mesh Agent, alongside ScreenConnect and Tactical RMM, among the tools installed by a February 2026 campaign that signed its payloads with a stolen extended-validation certificate ^[10]. Intel 471’s April 2025 analysis of RMM misuse treats MeshAgent, the MeshCentral client component, as one of three primary abused tools ^[11]. GreyNoise observed 116 unique IP addresses associated with MeshCentral over 90 days while investigating a separate exploitation campaign, and cited Censys tracking roughly 5,700 MeshCentral nodes globally ^[8].

Why this is a regional problem, not a Thai one

The appliance class is the same one MCMC-licensed operators and enterprises across Southeast Asia run at the perimeter. Shadowserver scanning counted approximately 150,000 exposed vulnerable FortiOS and FortiProxy devices in March 2024, with Japan and India among the five most affected countries after the United States ^[13]. That was the exposure at disclosure; this intrusion shows the tail persisting into 2026 on infrastructure that authenticates millions of subscribers.

3BB’s corporate group also has prior history. In January 2021 the group ALTDOS claimed a dump of around 100,000 customer records from 3BB, then a Jasmine International subsidiary, with password material stored using MD5, and Thailand’s National Telecommunications Commission required Jasmine executives to report on the incident within three days ^[12]. That was a claim reported at the time, it is a separate matter from this intrusion, and it is relevant only as evidence that carrier subscriber data in the region has been a standing target for five years.

What to do

• Verify the FortiOS build, not the marketing version. The fix boundaries are specific: 6.0.18, 6.2.16, 6.4.15, 7.0.14, 7.2.7 and 7.4.3 or above ^[5][6].
• Inventory RMM agents and enforce an allowlist tied to a known list of approved management servers. An agent reporting to an unrecognised server is an incident, not a configuration drift ^[8][9][10].
• Treat RADIUS, the subscriber database and the internal PKI as the crown jewels of a carrier estate, with their own monitoring and their own credential rotation cycle ^[1].
• Preserve logs before remediating a perimeter appliance compromise. This operator erased auth.log, syslog and kernel logs; a clean rebuild destroys what remains ^[1].
• After any SSL-VPN appliance compromise, rotate SSH keys, database credentials, VPN client certificates and RADIUS secrets. A patched appliance does not invalidate what was taken from behind it ^[1].
• Hunt for hidden SUID binaries and unexpected setuid changes as a routine control, not only after an incident ^[1].
• Check whether the escalation paths used here still work internally. PwnKit and Dirty COW are from 2022 and 2016; their presence on a 2026 estate is a patching signal in its own right ^[1].

Domain close

Nothing in this intrusion was novel. The entry point was a catalogued 2024 vulnerability with a vendor fix and a national advisory. The escalation used public exploits from 2016 and 2022. The persistence was a legitimate open-source management tool anyone can download. The only sophisticated element was sequencing and patience, and the objective was the one that matters at a carrier: the store that authenticates the subscribers. The defensive conclusion is unglamorous. Perimeter appliance patching, an RMM allowlist and credential rotation after appliance compromise would have broken this chain at three separate points, and none of the three requires a new product.