3BB Intrusion Used MeshCentral Backdoor for Root Access

Security researchers at Hunt.io have published details of an intrusion inside 3BB, a major Thai broadband provider, in which an attacker used MeshCentral, a legitimate remote management tool, as a hidden backdoor to hold administrative control of internal machines. The researchers say they found the operation because the attacker left a server open on the internet that contained the attacker's own tools and a list of machines already under their control.

Hunt.io captured the exposed server on June 3, 2026, while the operation was still live. The tools on that server had been run from a computer inside 3BB's own network, and one recovered file showed the attacker had gained full administrative control, known as root, of an internal server. To keep that access, the attacker installed MeshCentral, a free program that IT teams normally use to manage computers from a distance. The recovered settings show it was set up as a hidden backdoor: the agents reported to a control server the attacker ran at www.ayuthayatech[.]com, under a device group named TH-3BB. Hunt.io notes that attackers increasingly abuse this kind of trusted remote-management software because its activity blends in with routine administration.

A device list recovered from the server named the machines enrolled in the attacker's MeshCentral setup, and several were connected and running with root privileges when the list was made. That, according to the researchers, showed the attacker held active administrative control at that point. A separate cleanup script was written to erase logs and delete the attacker's other tools while deliberately leaving the MeshCentral agent in place so the access would survive.

Inside the network, the attacker worked to widen access. Recovered scripts sprayed passwords against more than 55 internal computers over SSH, a secure method for logging in to remote computers, and probed 3BB's internal sales portal at agent.3bb.co[.]th. The scripts also searched compromised machines for stored passwords, database logins, and SSH keys, which are digital credentials used to log in without typing a password. Other scripts could plant web shells, hidden pages that run an attacker's commands, and add SSH keys as backup ways back in.

Hunt.io said the attacker's main goal was 3BB's subscriber data. Scripts on the server were built to copy out the company's RADIUS databases, the systems that store the login credentials broadband customers use to get online. The evidence shows those databases were targeted, not that any data was taken. The same server pointed to a second target: it held a valid VPN certificate from 3BB's own systems and active login sessions for services on the Jasmine network, a company 3BB was once part of and still shares infrastructure with. Hunt.io said this suggested the attacker was working against both, though it did not confirm that Jasmine itself had been breached.

How the attacker initially gained access to 3BB is not established. The server held a full toolkit aimed at a 3BB FortiGate SSL-VPN gateway, the remote-access box at mail.3bb.co[.]th, including a complete exploit for CVE-2024-21762, a serious 2024 Fortinet flaw that lets an attacker run code on the device without logging in. The targeted gateway was running a firmware version affected by the flaw. However, nothing Hunt.io recovered shows the exploit actually worked, or that it was how the attacker got in. The FortiGate tooling was the most developed part of the kit, yet it points to the attacker's capability and intent, not a confirmed break-in through that device.

The attacker has since closed the exposed directory. Whether they still have access inside 3BB is not known, because the evidence describes the intrusion as it stood in early June, not today. The researchers said they notified the affected companies and the relevant national response team about their findings before publishing.

Hunt.io's report lists several defensive steps for organizations that run similar edge devices and authentication systems. Organizations should patch or confirm that FortiGate SSL-VPN appliances are fixed against CVE-2024-21762. Fortinet's advisory says that if you cannot patch at once, you should turn off SSL-VPN, and that turning off web mode alone is not a valid workaround. They should also check for MeshCentral agents they did not install, and for connections to management servers they do not recognize. Credentials that may have been exposed should be rotated, including SSH keys, database and RADIUS passwords, VPN certificates, and application secrets, because patching does not remove an agent that is already installed or reset a password that has already been copied. Teams should hunt for hidden ways back in, such as unexpected SUID files (programs that run with elevated permissions), web shells, changed SSH keys, and newly added remote-management software. Logs and evidence should be preserved before cleanup, because the attacker's own script was built to erase them.

For teams responsible for similar remote-access or hosting infrastructure, AEU-I offers security-first IT, infrastructure and consulting that can help review configurations and harden edge devices before they become hidden entry points.

Key indicators from the report, shown in defanged form, include the attacker's server IP address 92.63.180[.]133 (port 8888 held the open directory, port 9443 received the exploit callback), the MeshCentral control server domain www.ayuthayatech[.]com, the device group TH-3BB, persistence paths /usr/local/bin/.rc and /usr/local/mesh_services/meshagent/, and the targets mail.3bb.co[.]th (FortiGate SSL-VPN) and agent.3bb.co[.]th (internal portal). The full list of indicators is in Hunt.io's report.