3BB Attacker Used MeshCentral Backdoor for Root Access, Targeted Subscriber Credentials

Swati KhandelwalSep 14, 2026Network Security / Cyber Attack

An attacker was operating inside the network of 3BB, one of Thailand's largest broadband providers, and maintained remote control of internal machines using a legitimate management tool called MeshCentral, threat intelligence firm Hunt.io said.

The company uncovered the intrusion by examining a server the attacker had left open on the internet, which held the attacker's own tools and a list of machines already under their control.

The researchers captured the exposed server on June 3, 2026, while the operation was still live. The tools on it had been run from a computer inside 3BB's own network, and one recovered file showed the attacker gaining full administrative control, known as root, of an internal server.

To maintain that access, the attacker installed MeshCentral, a free tool that IT teams typically use to manage computers remotely. The recovered settings show it was configured as a hidden backdoor, with the agents reporting to a control server that the attacker ran at www.ayuthayatech[.]com, under a device group named TH-3BB.

Attackers increasingly abuse this kind of remote-management software because it is trusted and its activity blends in with routine administration.

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 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.

Inside the network, the attacker worked to widen their access. 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.

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.

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 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.

What Defenders Should Do

The recovered toolkit points to a clear set of steps for organizations running similar edge devices and authentication systems:

• 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.
• Check for MeshCentral agents you did not install, and for connections to management servers you do not recognize.
• Rotate credentials that may have been exposed, including SSH keys, database and RADIUS passwords, VPN certificates, and application secrets. Patching does not remove an agent that is already installed or reset a password that has already been copied.
• Hunt for hidden ways back in, such as unexpected SUID files, web shells, changed SSH keys, and newly added remote-management software.
• Preserve logs and evidence before cleaning up, because the attacker's own script was built to erase them.

Key indicators from the report, shown in defanged form:

• IP address: 92.63.180[.]133, the attacker's server (port 8888 held the open directory, port 9443 received 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)

The full list of indicators, along with the technical details, is in Hunt.io's report.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.