Thailand’s 3BB Broadband Network: Breached Through MeshCentral Backdoor Exploit

17

Thailand's 3BB Broadband Network Breached Using Hidden MeshCentral Backdoor

An unknown attacker infiltrated 3BB, one of Thailand's largest broadband providers, using a legitimate remote management tool as a hidden backdoor to gain root access and target millions of subscriber credentials, threat intelligence firm Hunt.io revealed on September 14, 2026.

The intrusion represents a growing trend of attackers weaponizing trusted IT management software to blend malicious activity with routine network administration. For Thailand's broadband customers and enterprise security teams across Southeast Asia, the breach exposes critical vulnerabilities in how internet service providers protect the authentication systems that customers depend on daily.


How the Attacker Built a Hidden Foothold Inside 3BB

Hunt.io's researchers discovered the operation after identifying an exposed server the attacker had carelessly left open on the internet. The server, captured on June 3, 2026 while the operation was still active, contained the attacker's own tools and a list of machines already under their control.

Tools recovered from the server showed activity originating from a computer inside 3BB's own network. A recovered file confirmed the attacker had achieved root access — full administrative control — over an internal server. To maintain that control, the attacker deployed MeshCentral, a free and widely trusted remote management tool used legitimately by IT teams worldwide.

The MeshCentral installation was configured as a concealed backdoor. Agents were set to report to a control server operated by the attacker at www.ayuthayatech[.]com, under a device group labeled TH-3BB. Several compromised machines appeared connected and running with root privileges at the time the device list was captured.

In a calculated move recalling the methodical persistence of fictional hackers like Mr. Robot's Elliot Alderson, the attacker also deployed a cleanup script designed to erase logs and remove other tools — while deliberately leaving the MeshCentral agent intact. The access would survive the cleanup entirely. This is a textbook example of how attackers use trusted software as camouflage: by blending the backdoor into tools that security teams already recognise as legitimate, detection becomes exponentially harder.

Why MeshCentral Makes an Effective Backdoor

MeshCentral is an open-source, self-hosted remote management platform widely deployed by IT administrators for legitimate device management. Its network traffic patterns are indistinguishable from authorised use, and many security monitoring tools are configured to whitelist known remote management software by default. When an attacker controls the management server rather than the agent, the compromise is invisible to anyone not specifically hunting for unauthorised agent registrations. Understanding the risks and controls around remote network access is essential for any organisation operating distributed infrastructure — because the same tools that enable legitimate administration can be turned against you with minimal modification.


Subscriber Credentials and Lateral Movement Across the Network

Once inside, the attacker worked systematically to expand their reach. Recovered scripts revealed the attacker sprayed passwords across more than 55 internal computers via SSH and probed 3BB's internal sales portal at agent.3bb.co[.]th. Additional scripts searched compromised machines for stored passwords, database logins, and SSH keys.

Hunt.io identified subscriber data as the attacker's primary target. Scripts on the server were specifically built to extract 3BB's RADIUS databases — the systems that store the login credentials broadband customers use to authenticate and connect to the internet. The evidence confirmed those databases were targeted, though Hunt.io stopped short of confirming that data was actually exfiltrated.

The Jasmine Network Connection

The attacker's reach appeared to extend beyond 3BB itself. The exposed server held a valid VPN certificate from 3BB's systems and active login sessions for services on the Jasmine network, a company 3BB was once affiliated with and continues to share infrastructure with. Hunt.io said this suggested the attacker was working against both organisations but did not confirm that Jasmine had been breached.

The attacker's server operated from IP address 92.63.180[.]133, with port 8888 hosting the exposed directory and port 9443 receiving exploit callbacks.

Why RADIUS Database Targeting Matters

RADIUS — Remote Authentication Dial-In User Service — is the backbone authentication system used by ISPs to verify that customers are who they claim to be before granting internet access. A breach of RADIUS databases does not just expose usernames and passwords; it potentially exposes the authentication architecture of an entire subscriber base. For millions of broadband customers, that means credentials used daily to connect to the internet could be harvested and exploited long before any breach notification reaches them. Implementing robust identity and access management controls at the database layer is one of the most effective defences available — reviewing identity and access management best practices for enterprise environments provides a practical framework for organisations that manage sensitive authentication infrastructure at scale.


A FortiGate Exploit Kit Points to Attacker Capability — But Not Confirmed Entry

How the attacker initially gained access to 3BB's network remains unknown. The exposed server contained a complete toolkit targeting a 3BB FortiGate SSL-VPN gateway at mail.3bb.co[.]th, including a full exploit for CVE-2024-21762 — a critical 2024 Fortinet vulnerability that allows unauthenticated remote code execution on affected devices.

The targeted gateway was confirmed to be running firmware vulnerable to that flaw. However, Hunt.io recovered no evidence proving the exploit was successfully used or that it served as the initial point of entry. The FortiGate toolkit was the most technically developed component of the attacker's arsenal and signals clear capability and intent, but not a confirmed breach through that specific vector.

Fortinet's Advisory and the Patching Gap

Fortinet's guidance on CVE-2024-21762 is unambiguous: disabling SSL-VPN entirely is the only valid interim workaround, and disabling web mode alone is insufficient. This distinction matters because many organisations believe partial configuration changes constitute adequate protection. They do not. Edge devices — SSL-VPN gateways in particular — have become the highest-value initial access targets in 2026 campaigns precisely because they sit at the perimeter, are frequently under-patched, and provide direct pathways into internal networks without requiring any interaction from a user.

The attacker subsequently closed the exposed directory. Whether they retain active access inside 3BB's network as of publication is unknown, as the evidence reflects the state of the intrusion in early June 2026. Hunt.io said it notified the affected companies and the relevant national cybersecurity response team before publishing its findings.

For further context on how attackers exploit unpatched systems and what organisations can do to reduce their exposure, CISA's Known Exploited Vulnerabilities catalogue provides a continuously updated reference that security teams should monitor as a standard operational practice.

What Security Teams Should Do Now

For security teams responding to this disclosure, Hunt.io outlined a clear remediation path. The following steps address both the confirmed threat vectors and the broader lessons this intrusion illustrates.

  • Patch FortiGate SSL-VPN appliances immediately. Verify that CVE-2024-21762 has been remediated. Fortinet's advisory is clear that disabling web mode alone is not sufficient — SSL-VPN must be disabled entirely as an interim workaround if patching cannot be completed immediately.
  • Audit for unauthorised MeshCentral agents. Search all endpoints and servers for MeshCentral installations and verify that each agent reports to a management server your organisation controls. Connections to unrecognised servers should be treated as active compromises.
  • Rotate all credentials without exception. SSH keys, RADIUS passwords, VPN certificates, and database logins must all be rotated — because patching alone does not remove an already-installed agent or recover a credential that has already been copied.
  • Hunt before you clean. Search for web shells, unexpected SUID files, and altered SSH keys before running any cleanup process. As this case demonstrates, attacker-authored cleanup scripts are specifically designed to erase the forensic evidence defenders need most.

Patching and credential rotation address the symptoms. Sustained protection requires a systematic approach to preventing network intrusions before attackers establish a foothold — one that treats edge device hygiene, access control, and monitoring as continuous operational disciplines rather than one-time remediation tasks.

How Readers and Security Professionals Can Act on This Information

  • ISPs and network operators should audit RADIUS database access logs and verify whether MeshCentral or similar remote management agents are present on systems where they were never installed.
  • Enterprise IT teams can use the published indicators of compromise — including the attacker's IP, domain, and persistence paths — to search their own environments for matching activity.
  • Security decision-makers should treat unpatched edge devices, particularly SSL-VPN gateways, as the highest-priority remediation target given their role as confirmed attacker objectives in this and multiple related 2026 campaigns.
You might also like