MeshCentral Backdoor Hid Inside 3BB Network

A broadband provider's internal network, a management tool that IT teams trust, and a control server quietly answering to a device group named TH-3BB. That is the picture threat intelligence firm Hunt.io said it found after examining a server an attacker had left exposed on the internet, a server that held the intruder's own tools and a roster of machines already under their control.

The target was 3BB, one of Thailand's largest broadband providers. According to Hunt.io, the attacker was operating inside the company's network and maintained remote control of internal machines using MeshCentral, a free tool that IT departments normally use to manage computers remotely. The researchers captured the exposed server on June 3, 2026, while the operation was still live.

A Server Left Wide Open

The intrusion came to light because the attacker left a directory open on the internet. Hunt.io said it uncovered the operation by examining that server, which contained the attacker's own toolkit and a list of machines already enrolled in their control setup.

The tools on the server had been run from a computer inside 3BB's own network. One recovered file showed the attacker gaining full administrative control, known as root, of an internal server, according to Hunt.io.

The company said the evidence describes the intrusion as it stood in early June, not as it stands now. The attacker has since closed the exposed directory, and whether they still have access inside 3BB is not known.

MeshCentral as a Hidden Door

To hold onto that access, the attacker installed MeshCentral. The recovered settings show it was configured as a hidden backdoor, with the agents reporting to a control server the attacker ran at www.ayuthayatech[.]com, under a device group named TH-3BB.

The choice of tool is not incidental. Attackers increasingly abuse this kind of remote-management software because it is trusted and its activity blends in with routine administration. A management agent talking to a control server looks like ordinary IT traffic, which makes it hard to flag without knowing which servers are legitimate.

A device list recovered from the server named the machines enrolled in the attacker's MeshCentral setup. Several were connected and running with root privileges when the list was made, which the researchers said showed the attacker held active administrative control at that point.

A Script Built to Survive Cleanup

The attacker took steps to make the access durable. 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 that the access would survive.

That persistence had specific paths. Hunt.io listed /usr/local/bin/.rc, described as a hidden backdoor, and /usr/local/mesh_services/meshagent/ among the persistence locations recovered from the server.

The cleanup script's design matters for anyone responding to this kind of intrusion. A routine wipe of malicious files would remove the tools but leave the management agent running, and with it the attacker's way back in.

Spraying Passwords Inside the Network

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

Other scripts could plant web shells, hidden pages that run an attacker's commands, and add SSH keys as backup ways back in. Together, the toolkit covered several routes: brute-forcing internal hosts, harvesting credentials already sitting on compromised machines, and installing alternate access that would survive the removal of any single tool.

Subscriber Credentials in the Crosshairs

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. That distinction is central to the report. Hunt.io described scripts built to copy the databases out, and the researchers did not claim that subscriber credentials were actually exfiltrated.

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.

A FortiGate Exploit, Unproven

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.

But 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 tooling also included a callback channel. Hunt.io listed 92.63.180[.]133 as the attacker's server, with port 8888 holding the open directory and port 9443 receiving the exploit callback.

Notification and a Public Report

The researchers said they notified the affected companies and the relevant national response team about their findings before publishing. The full list of indicators, along with the technical details, is in Hunt.io's report.

Hunt.io's account is currently the only public reporting on the intrusion, and the firm's findings rest on a single exposed server rather than a broader investigation inside 3BB's network. Key indicators from the report, shown in defanged form, include:

• IP address: 92.63.180[.]133, the attacker's server, with port 8888 holding the open directory and port 9443 receiving the exploit callback
• Domain: www.ayuthayatech[.]com, the MeshCentral control server
• MeshCentral group: TH-3BB
• Persistence paths: /usr/local/bin/.rc, a hidden backdoor, and /usr/local/mesh_services/meshagent/
• Targets: mail.3bb.co[.]th (FortiGate SSL-VPN) and agent.3bb.co[.]th (internal portal)

What Defenders Should Do

The recovered toolkit points to a set of steps for organizations running similar edge devices and authentication systems. Hunt.io's recommendations begin with confirming that FortiGate SSL-VPN appliances are fixed against CVE-2024-21762. Fortinet's advisory states 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.

From there, the guidance covers checking for MeshCentral agents you did not install and for connections to management servers you do not recognize, and rotating credentials that may have been exposed, including SSH keys, database and RADIUS passwords, VPN certificates, and application secrets.

Two points in that guidance are easy to overlook. Patching does not remove an agent that is already installed, and it does not reset a password that has already been copied. Defenders should also hunt for hidden ways back in, such as unexpected SUID files, web shells, changed SSH keys, and newly added remote-management software, and preserve logs and evidence before cleaning up, because the attacker's own script was built to erase them.

Why This Matters Beyond 3BB

The mechanics here are not exotic. A trusted management tool, a leftover agent, and a cleanup script that spares the one component keeping the door open could plausibly work against any organization that runs remote-management software and edge VPN appliances, which is most of them.

The targeting of RADIUS databases is worth weighing carefully. Those systems hold the credentials broadband customers use to get online, so an intrusion that reaches them could put subscriber logins at risk if the data were copied out. Hunt.io's evidence shows the databases were targeted, and the firm has not said they were taken. But the distinction between an attempt and a theft is not much comfort to a provider that has to decide whether to force password resets for its customer base.

The unproven FortiGate exploit carries its own lesson. The presence of a working exploit for CVE-2024-21762 on the attacker's server does not establish how they entered 3BB, but it does suggest the flaw was in the toolkit for a reason. Organizations that have not patched the flaw, or disabled SSL-VPN where they cannot patch, have less room to argue they were not a candidate.

Perhaps the most practical takeaway is the cleanup script. It was written to survive exactly the response many teams would mount: delete the tools, wipe the logs, move on. The MeshCentral agent would have remained, and with it the access. For defenders, that argues for treating remote-management agents as part of the incident rather than as infrastructure, and for checking what is talking to your management servers before you declare an intrusion closed.