3BB Breach: MeshCentral Backdoor Gave Root Access & Targeted Subscriber Credentials

A Thailand-based internet provider, 3BB, has been infiltrated by an attacker who used a legitimate remote-management tool to establish long-term control and target subscriber data. Threat analysts uncovered that the intruder installed MeshCentral software within 3BB’s network and configured it as a clandestine backdoor under a device group labeled TH-3BB. The control server used for this operation was hosted at ayuthayatech[.]com. The breach included root-level access on internal machines and manipulation of critical authentication systems. The timeline of the intrusion was confirmed to be active as of early June 2026.

Details of the Attack and Internal Escalation

The investigation revealed that the attacker exposed a server online—on June 3, 2026—that held both their tools and a list of compromised internal machines. Some of these machines had full administrative (root) control already established. To maintain persistence, a cleanup script was later used which wiped out most traces—logs and toolkits—yet intentionally left the MeshCentral agent operative.

Once inside, the attacker spread laterally via SSH across over 55 internal machines, aimed probes toward 3BB’s internal sales portal, and harvested stored credentials and SSH keys. Tools for establishing alternate access paths—web shells and hidden pages—and methods for adding SSH keys as backups were all in the toolkit. The primary target appears to have been the subscriber RADIUS databases, which store customer login credentials. Though scripts ran that were designed to exfiltrate those credentials, there’s no confirmed evidence yet that data was removed.

Another planted asset indicated the attacker may have had goals extending beyond 3BB: they discovered valid VPN certificates and active sessions for services under Jasmine, a related network operator with which 3BB shares infrastructure. However, there’s no firm proof that Jasmine itself has been compromised.

Initial Entry, Indicators, and Defensive Advice

While the exact point of entry remains undetermined, the attacker’s toolkit showed a heavy focus on a known FortiGate vulnerability (CVE-2024-21762). That vulnerability allows code execution without user authentication. The FortiGate VPN gateway in question was operating with firmware versions vulnerable to that issue. Still, there is no hard evidence confirming it was exploited to gain access.

Research exposes several indicators of compromise. These include the attacker’s control domain (ayuthayatech[.]com), IP address 92.63.180[.]133, persistence paths like “/usr/local/bin/.rc” and “/usr/local/mesh_services/meshagent/”, and targets such as mail.3bb.co[.]th and agent.3bb.co[.]th. Sensitive credentials potentially exposed include RADIUS passwords, SSH keys, database secrets, and VPN certificates. State-of-the-art defensive measures are recommended: patching FortiGate edge devices, proactively searching for unapproved management agents, rotating credentials, and uncovering hidden backdoors within system files. Organizations also need to preserve logs because attackers may use custom scripts to eliminate traces.

The incident was disclosed with early-June evidence and companies involved were notified. Whether current access remains with the attacker is unclear.

What this means: This is part of a broader trend in which threat actors abuse trusted remote management tools to hide in plain sight. The case of 3BB underscores how tools like MeshCentral, designed for legitimate administrative use, become powerful weapons in the hands of attackers who can secure root access, exfiltrate credentials, and persist undetected. Moving forward, organizations must treat remote-management infrastructure as critical security boundaries—not just convenience utilities. The attention should now shift to validating whether similar campaigns are underway elsewhere, and how widespread misuse of trusted management platforms like MeshCentral has become in global telecom infrastructure.